Live data from Hacker News

God writes Haskell

hookrace.net

61–70 of 128 posts

Re: God writes Haskell

#63
post #19

Earlier quoted context omitted.

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?

At the state of the onion address, where else?

Re: God writes Haskell

#64

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.

The key is to not write large Haskell programs. Write many Haskell libraries and compose them. This scales infinitely and is an excellent way to build software. But it's also hard to do and takes good & deliberate technical leadership if you want to get 50+ engineers doing it.

You could say that it requires God levels of discipline.

Re: God writes Haskell

#67

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.

not to argue your major point, but more entropy makes things more uniform/less complex. think of the heat death of the universe.

Re: God writes Haskell

#68

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.

not to argue your major point, but more entropy makes things more uniform/less complex. think of the heat death of the universe.

complex can be a synonym for disorder and it can also be a synonym for structure. in this instance, the clear meaning is disorder.

> become exponentially more complex

obviously this can't be read as "become exponentially more structured" given the tone of the sentence.

Re: God writes Haskell

#69

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.

The key is to not write large Haskell programs. Write many Haskell libraries and compose them. This scales infinitely and is an excellent way to build software. But it's also hard to do and takes good & deliberate technical leadership if you want to get 50+ engineers doing it.

If you can reason about f and g that doesn’t mean that you can tell anything useful about f o g, so no, this is a factually incorrect statement. Sure, if we have a separate unit of functionality, write a function for that. But that’s no silver bullet - complexity is unbounded.

Re: God writes Haskell

#70

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.

The key is to not write large Haskell programs. Write many Haskell libraries and compose them. This scales infinitely and is an excellent way to build software. But it's also hard to do and takes good & deliberate technical leadership if you want to get 50+ engineers doing it.

How is this different from any other programming language?
Post reply on HN