Live data from Hacker News

God writes Haskell

hookrace.net

21–30 of 128 posts

Re: God writes Haskell

#21
post #15

> 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…

But Quantum entanglement seems to be traveling in God's channel, how does that happen if God is using linked lists?

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…

> 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 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

#23
post #10

Dumb, 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?

Right?

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

#24
post #19
post #9

Mandatory 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…

> 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

How can you make an onion if there's no state? Where will the state of the onion reside?

Re: God writes Haskell

#25
I 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

#27

Let'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.

Ah yes, the holy tetragrammaton.

Re: God writes Haskell

#28

I 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.

Item is not O(functionality) but O(category theory knowledge)

Re: God writes Haskell

#29

This 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…

There’s something about this that swallows its own tail, the optimal way to simulate a universe using computing theory available in that universe.

Re: God writes Haskell

#30
I want to ask God how to make my stack build process faster.. even turning off the optimization flag it still takes quite some time on my 2.6 GHz 6-Core Intel Core i7.. (or is it because I'm on a Mac? Does it build faster on Linux?)
Post reply on HN