So uh...
When are we rewriting this in Rust?
God writes Haskell
41–50 of 128 posts
Re: God writes Haskell
#42This explains why he allows genocide. /s Oh come on, this title begs for sarcastic responses.
If no one could do bad things in the world, then there would be no free will. No free will, no genuine love. You'd love God and other people because you were programmed to do so.
Re: God writes Haskell
#43Is the universe deployed on K8s?
Re: God writes Haskell
#44[dead]
Re: God writes Haskell
#45Earlier quoted context omitted.
In any programming language where functions are allowed as arguments to functions, and most languages that are still in use allow this, you can choose lazy evaluation for any function argument. Already Algol 60 had "call-by-name", which could be used to do lazy evaluation. The only difference in Haskell and similar languages is that lazy evaluation is the default mode of evaluation, and if you do not want this it is…
In Clojure, where lazy evaluation is also the default (although only for sequences), someone recently wrote an in-depth article about the issues caused by this choice: https://clojure-goes-fast.com/blog/clojures-deadly-sin/ I haven’t read the whole article yet, but maybe it could be interesting to compare it with Haskell and see if some of the same problems occur or if Haskells compiler or overall design around (perv…
clojure does not have lazy evaluation of any form. “lazy sequences” are a hack, clojure core uses macros to thunkify sequence traversal in userland. this hack interacts badly with a few other aspects of clojure because clojure itself is not lazy, being that it is a hosted language designed to lightly cover the host platform (Java, JS, .NET, Dart) and maximize host ecosystem compatibility and therefore does not alter core platform semantics such as concurrency model or evaluation model.
Re: God writes Haskell
#46> Haskell beginners often use lists instead of arrays. You can’t do random access in a linked list, but only access the first element and then the rest of the list. The real world also doesn’t allow you random access, you are limited by the speed of light and have to go from one location to the next. You don't need arrays for random access though. Haskell trees give you access to 2^n leaves within depth n, which also…
What does it have to do with the speed of light?
Re: God writes Haskell
#47Earlier quoted context omitted.
In any programming language where functions are allowed as arguments to functions, and most languages that are still in use allow this, you can choose lazy evaluation for any function argument. Already Algol 60 had "call-by-name", which could be used to do lazy evaluation. The only difference in Haskell and similar languages is that lazy evaluation is the default mode of evaluation, and if you do not want this it is…
> I have never seen any evidence that lazy evaluation by default is better instead of worse With lazy-by-default: if you want strictness, you can simply 'evaluate something now'. With strict-by-default: if you want laziness, you have to rewrite your code, and all the libraries that your code calls. > psychological advantage for programmers who find it easier to understand programs with lazy evaluation This is entirel…
> "If you can be OK with executing either the true-branch or the false-branch of an if-statement (but not both), you can be OK with lazy evaluation. Same with boolean short circuiting."
Understanding lazy evaluation that occurs here and there in a program is not a problem for anyone.
Understanding the behavior of a program where all function arguments are evaluated lazily is something extremely different and it is notorious that even the experienced Haskell programmers frequently fail to predict correctly the requirements in time and memory of a program.
> With strict-by-default: if you want laziness, you have to rewrite your code
I agree that this is true, but in decades of programming experience I have never encountered such a case.
Discovering that you want lazy evaluation after you have already written a program means that the initial concept of the program had very serious flaws and you have started coding before thinking properly what you have to do.
Sometimes it happens that it is discovered that a program needs a rewrite because the problem that it must solve had not been understood, but in almost all cases such rewrites are needed for completely other causes than the need of some lazy evaluations.
So this argument in favor of lazy evaluation brings an advantage in some very rare cases, like also the argument that lazy evaluation by default sometimes saves work because eventually it may be discovered that the evaluation is not necessary, but this is also a relatively rare event, which must be balanced with much extra work that must be done by the CPU at each function invocation (which is a very frequent event), in order to implement lazy evaluation by default.
Re: God writes Haskell
#48I would bet that He writes Lisp. Ultimately everything is the same. Particles. Above it: particles made of particles.
God wrote in Lisp, Bob Kanefsky performed by Julia Ecklar. My favorite song.
https://www.prometheus-music.com/audio/eternalflame.mp3
Refrain (full lyrics): http://www.songworm.com/lyrics/songworm-parody/EternalFlame....
For God wrote in Lisp code
When he filled the leaves with green.
The fractal flowers and recursive roots:
The most lovely hack I’ve seen.
And when I ponder snowflakes, never finding two the same,
I know God likes a language with its own four-letter name.
Re: God writes Haskell
#49Is the universe deployed on K8s?
It has been operating without issues for the past 13 billion years, so I'd say no.
Re: God writes Haskell
#50I would bet that He writes Lisp. Ultimately everything is the same. Particles. Above it: particles made of particles.
The next ground-breaking achievement in quantum physics will be the discovery of the two smallest particles everything derives from: a left paren and a right paren.