Live data from Hacker News

God writes Haskell

hookrace.net

81–90 of 128 posts

Re: God writes Haskell

#81
post #69

Earlier quoted context omitted.

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.

>If you can reason about f and g that doesn’t mean that you can tell anything useful about f o g

I'm confused. If you can reason about f and g, there is nothing more to know about f o g -- provided f and g are pure functions. The whole thing is about making sure side-effects are properly pushed at the boundaries so that you can keep working with pure functions. Haskell just provides more help (or more constraints) to ensure that you work with pure functions. Because if you aren't, all bets are off, and indeed the case of f o g may be a haze.

Re: God writes Haskell

#83
post #75
post #48

Earlier quoted context omitted.

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

JSON is a 4 letter name too! Could replace LISP with it.

JSON isn't a programming language

Re: God writes Haskell

#84
post #58

Earlier quoted context omitted.

In 3-dimensional space you can only access O(n^3) locations in n steps (where a step corresponds to the distance between adjacent locations).

You can access infinite locations. Nothing stops you from moving diagonally in an arbitrary angle, move forward and then backwards. I'd hoped my extravagant uses of > made that clear. Reality is practically continuous not discrete.

Practically speaking, all of the things you might usefully put in that space are larger than infintesimal, thereby discretizing the volume.

Re: God writes Haskell

#85

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.

this is an interesting observation. I have various explanation on why that might be the case.

on a commercial setting there is more pressure to deliver code then to review it. combine it with the lack of our benevolent dictator for life (that has been on the project the world life cycle, not just recently), there is no one with power to actually say no to changes.

language geeks are novelty seekers. they will use every feature of their language . stronger languages have more features to abuse. so on a commercial setting you will have all the features being used without much thought an architectural design that says you that no, we shouldn't do that.

that's also why I think projects with benevolent dictators for life on the open source ward don't fall these in paths even though they use languages that are stronger.

you could restrict yourself to use languages that have only one way to be used, so python as it was originally. or use a language little abstraction power. but you will suffer in other ways. as abstraction power is genuinely useful. accidental complexity has a way of getting in by expressive means or by social means.

Re: God writes Haskell

#88
post #71

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.

I have a theory that Haskell's main applications are in teaching and academic research - both concerning theoretical computer science. It's not a practical engineering language.

I have evidence to the contrary. I have a job writing Haskell for a living doing boring, normal software. I also started a stream where I write libraries and games and build stuff in Haskell purely to disprove this theory. It's been going well: we've written a logical replication client library for Postgres, built an asteroids clone, etc. It is a very practical language.

Re: God writes Haskell

#89
With respect to the theological view of the question; this is always painful to me.— I am bewildered.— I had no intention to write atheistically. But I own that I cannot see, as plainly as others do, & as I should wish to do, evidence of design & beneficence on all sides of us. There seems to me too much misery in the Haskell world. I cannot persuade myself that a beneficent & omnipotent God would have designedly created the Haskell with recursive data structure yet leave the maximal size of tuples to arbitrary implementation details, have a restrictive typing system that would not include dependent types, or force the hand of the programmer to use the bang operator to manage memory manually to avoid consequences of laziness. Not believing this, I see no necessity in the belief that the Haskell was expressly designed.

Re: God writes Haskell

#90
post #81
post #69

Earlier quoted context omitted.

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.

>If you can reason about f and g that doesn’t mean that you can tell anything useful about f o g I'm confused. If you can reason about f and g, there is nothing more to know about f o g -- provided f and g are pure functions. The whole thing is about making sure side-effects are properly pushed at the boundaries so that you can keep working with pure functions. Haskell just provides more help (or more constraints) to…

  f  :: Integer -> Boolean

  g f n = if (f n) then (g f (n+1)) else (is_it_reachable)
Will it ever terminate (or insert any other interesting property that you wish) with f = collatz?

I know this is the atomic bomb case, but you can actually quite easily increase the complexity in realistic programs by just a few compositions, it doesn’t take much.

Post reply on HN