Comment by zyxzevn | Hacker News Reader

Comment by zyxzevn | Hacker News Reader

Nobody quickly understands:

    A(B(C(D(E(x)))))

That is why they use the assignments.

    e= E(x)  
    d= D(e)  
    c= C(d)  
    b= B(c)  
    a= A(b)

But many people can understand:

    x-> E -> F-> C-> B-> A  
    // where -> is a pipe operator.

Now you see that you first execute E with x as input.

This shows that Functional program has some kind of problem, if it is not presented in a good way.

There are also other problems. The overuse of Currying is bad, as it hides what is going on. Then we can also have recursion mixed with lazy execution.

I think that the problem with functional programming is the bad presentation of what is really going on.

I try to overcome these problems by using a pure graphical system instead. Everything should be as simple and clear as possible. The system is still in design/development, but you can see some at http://www.reddit.com/r/unseen_programming/

The general idea is that cells like in a spreadsheet are a basis for our functions. Unlike a spreadsheet-cell they can contain multiple variables. These cells can then be combined with pipes and streams. That may already define an functional language, but for me that is just the start.

The first line seems the most easily parsed to me. The second one is the worst, and the third one only works for a tidy pipeline; if you have to combine multiple pipelines you'd need to bracket them, as in the first.

> The first line seems the most easily parsed to me. The second one is the worst, and the third one only works for a tidy pipeline;

I'd take the second over the other ones any time of the day, which clearly shows that there is no actual problem to solve here : we all see the world differently and there's nothing anyone can do about that.

The first line makes it hard to parse actual diffs in git.

You must be used to reading inside out, instead of left to right.

The parameters will mess up as soon you have multiple parameters. Especially messy if you want to reuse them. Or when you have conditions.

In a graphical system you do not need brackets, which is why I added it as a possible solution.

The first and third are both easier for me than the second.

At least in my case, it's not an inside-out or left-right thing, it's a funnel that shows the exact relationship of the data. The problem with the second one is that the multiple distinct statements require scanning up and down across them to ensure the local variables aren't used anywhere else, and then mentally reconstructing the data's flow from one function to the next.

It's also why I strongly prefer statements like this:

  A(
    B(C),
    D,
    E(F(G))
  )

The flow of data is encoded directly in the visual structure, instead of being split out across various statements using local variables that leak intermediate state and introduce accidental mental overhead.

But the second form is also more general, since you can express any computation that way, whereas you can't in the first or third forms.

For example:

    x = A(B)
    y = D(x) 
    z = C(x, E(y))

Is either an important optimization (possibly affecting asymptotic complexity in more complex cases), important for correctness (if any of the functions have side-effects), or at least more succint than the alternatives (in a lazy language like Haskell).

Reply on news.ycombinator.com