HackerTrans
トップ新着トレンドコメント過去質問紹介求人

alcidesfonseca

no profile record

投稿

Why TUIs are making a comeback

wiki.alcidesfonseca.com
4 ポイント·投稿者 alcidesfonseca·2 か月前·0 コメント

Why should operating systems and websites track the user age?

wiki.alcidesfonseca.com
2 ポイント·投稿者 alcidesfonseca·4 か月前·1 コメント

Bootstrap Bio (solves health at the genetic level/promotes eugenics)

bootstrapbio.com
1 ポイント·投稿者 alcidesfonseca·5 か月前·1 コメント

コメント

alcidesfonseca
·2 か月前·議論
Fixed both issues. Thanks!
alcidesfonseca
·2 か月前·議論
What popular desktop application is written in flutter?

Asking honestly, because none of the ones I use is.
alcidesfonseca
·3 か月前·議論
Is it possible that the [x Telemetry] [x Electron] and [x Subscription] means that the app does not have those things?
alcidesfonseca
·4 か月前·議論
The next neo might have the SSDs of the current pros, making swapping less problematic.
alcidesfonseca
·5 か月前·議論
I wonder about the ethical and legal implications of this work. We've all read and watched sci-fi that warn about the implications of doing this, but biologists agree that reducing diversity within a population makes it much more at risk.
alcidesfonseca
·8 か月前·議論
Liquid Types are more limited than "full dependent types" like Lean, Rocq, Agda or Idris. In Liquid Types you can refine your base types (Int, Bool), but you cannot refine all types. For instance, you cannot refine the function (a:Int | a > 0) -> {x:Int | x > a}. Functions are types, but are not refinable.

These restrictions make it possible to send the sub typing check to an SMT solver, and get the result in a reasonable amount of time.
alcidesfonseca
·8 か月前·議論
I believe it to be historically true, but Dependent Haskell might change this (https://ghc.serokell.io/dh see unification of types and kinds).

In Lean (and I believe Rocq as well), the Type of Int is Type 0, the type of Type 0 is Type 1, and so on (called universes).

They all come from this restriction.
alcidesfonseca
·8 か月前·議論
If it taught them the core concepts of writing good software, that's a win in my book.
alcidesfonseca
·2 年前·議論
I think the (hidden) reasoning is that it is really easy to have speedups with slow interpreters. However, getting speedups in high-performance level programs is quite hard, mainly due to micro-optimisations.

That's where the comparison to Python comes from: getting speedup on slow interpreters is not very _relevant_. Now if your interpreter has the same optimisations as Python (or v8 or JVM), even a small fraction of what you show would be impressive.

Having said this, the work your team did is a really challenging engineering feat (and with lot more potential). But I do not believe the current speedups will hold if the interpreter/compilers have the level of optimisation that exist in other languages. And while you do not claim it, people expect that.