> 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…
God writes Haskell
21–30 of 128 posts
Re: God writes Haskell
#22>He seems to enjoy writing Haskell This article gives no evidence of this. None of the concepts that the article lists out are Haskell exclusive. Thunks and linked list can be made in C too.
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…
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 entirely based what you're used to. 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.
Why should
true || error()
return true, but any [true, error(), error()]
return error?Re: God writes Haskell
#23Dumb, but it's fun hearing it from the other side. If you ever make a "Haskell is bad because it doesn't use state but the real world uses state" argument, this is what you sound like.
I mean ... state monad?
Even if you wanted to be pedantic and say the state monad is only 'simulated' state, you've still got ST, IO, and the glorious, glorious STM. Not to mention the purity and type-system that lets these things flourish, while other language designers try to implement STM and give up on it.
Re: God writes Haskell
#24Mandatory xkcd: https://xkcd.com/224/
Which makes much more sense. The first prototype was in Lisp, but at the end of the day, when you gotta deliver a universe and don't have time to faff about with a borked Emacs, you open vim and fix it in prod with a quick Perl script. -- Haskell is for humans who want to play God, carving everything from a perfect and seamless void, ignoring as much as possible the discrete, chaotic nature of matter and entropy. A r…
How can you make an onion if there's no state? Where will the state of the onion reside?
Re: God writes Haskell
#25Re: God writes Haskell
#26Re: God writes Haskell
#27Let's face facts here: God just fell asleep on the keyboard, and by a staggering coincidence, or perhaps a weird shape of the head, the first 4 letters he typed were P, E, R, L. He's still sleeping.
Re: God writes Haskell
#28I would like to add that just like in our universe, in Haskell entropy only ever increases and never goes down. I.E., add more functionality to your program and the complexity will go up. This is true for all programming languages of course, but in my limited experience larger Haskell programs seem to become exponentially more complex.
Re: God writes Haskell
#29This makes me believe simulation theory even more tbh. Quantum mechanics exist to fuse operations, altogether making simulating our universe more computationally inexpensive.
There's an even deeper way to thing about it: if you actually want to parallellize the simulation of multiple scenarios, or if you're running smth. that needs to compute smth in >4d, quantum mechanics + parallel universes" might be the computationally optimal way to do it! ...we don't think about it this way often because we'd be thinking about computational problems so huuuuge that we'd be like the quarks inside the…