The Haskell Elephant in the Room

Re:The Haskell Elephant in the Room by bodhiandpysics1 on Thursday July 30, 2020 @11:32AM (#23999331)

There is a certain class of computer programs that can best be described as a really big table. Basically, an input taken from a finite set, you get an output taken from a finite set. This type of program is really easy to write in Haskel because you can prove that both the conplete input set and output set are covered using the type system. In other words you can prove that you deal with every possible case (though you can't prove that you deal with every possible case correctly!!!), and that there is no ambiguity (one input has multiple correct outputs) A good example of such a program is an insurance contract (or a derivitive contract in a bank)

[ Parent | on HN ]

Re:The Haskell Elephant in the Room by CyberDildonics on Thursday July 30, 2020 @12:01PM (#23999674)

That's basically a DAG - directed acyclical graph. Data is transformed from inputs to outputs with no state or branching on the macro level of the transform. Lots of programs have parts that map to this very well. The cracks show when someone realizes this and thinks it is a silver bullet to build an architecture that ONLY does this. Then the parts that inevitably do need branching, state, and complex loops become a big problem. Combined with resource management (which can be thought of as mixing in branching and state) and the simplistic approach that seemed like a silver bullet turns into a nightmare once the realities of real software set in.

[ Parent | on HN ]

Re:The Haskell Elephant in the Room by pwm on Thursday July 30, 2020 @04:13PM (#24002384)

Hm, what's the issue with state and branching?

[ Parent | on HN ]

Re:The Haskell Elephant in the Room by CyberDildonics on Thursday July 30, 2020 @04:32PM (#24002542)

If you build a language that is based around doing everything with stateless data transformations but doesn't address state and branching, it will eventually be a problem, because the reality is that the vast majority of non trivial software needs to deal with plenty of state and branching, not to mention the state and branching that will go in to managing resources.

There are a lot of domain specific tools that are used for specific tasks where the main software is taking care of architecture, high level decisions and resources. Shaders are one example of this. Trying to write non trivial software like this is problematic because the structure you are using is so disconnected from what the software needs to do.

[ Parent | on HN ]

Re:The Haskell Elephant in the Room by pwm on Thursday July 30, 2020 @06:15PM (#24003443)

> If you build a language that is based around doing everything with stateless data transformations but doesn't address state and branching, it will eventually be a problem

I'm assuming you are referring to Haskell? It's a general purpose programming language so of course it handles state, branching, etc...

  data Tree a = Empty | Leaf a | Node a [Tree a]
    deriving stock (Show, Functor, Foldable, Traversable)

  label :: Tree a -> Tree (a, Int)
  label t = evalState (traverse f t) 0 where
    f t' = state (\c -> ((t', c), c + 1))

The above code labels nodes of a multiway tree using a counter. State and branching.

[ Parent | on HN ]

Re:The Haskell Elephant in the Room by CyberDildonics on Friday July 31, 2020 @09:24AM (#24008313)

That's not state or branching on a high level of a program. It is in some ways the opposite of what I was talking about and a good representation of the problem.

This looks like it is lazily evaluating parts of a tree, which means that you aren't controlling that state, you are hoping that everything works out when you query it with regards to resources, caching, memory layout, memory freeing, etc.

In a non-trivial program that either will need to optimize memory and cpu usage to scale or be careful about how things are structured to maintain interactivity, something like this is likely to be a big problem if that tree gets big.

[ Parent | on HN ]