Hacker News Reader

Maybe that just says something about my intelligence, or maybe the functional camp hasn't yet figured out how to write large programs in a readable way.

Haskell programmers tend not to write large programs, period. Instead, we build lots of libraries until our problem is trivial to solve.

Case in point, see the list of operators defined by the popular Lens library

Not really a fair example. Lens is not a program (large or otherwise), it is a new programming language embedded within Haskell. Viewed within that context, its bevy of operators is somewhat justified. The other thing to note about it is that lens was designed specifically to avoid clashing with variable and operator names defined in other popular libraries so that users could import it unqualified.

> Haskell programmers tend not to write large programs, period. Instead, we build lots of libraries until our problem is trivial to solve.

So, how is that different from any other language since the invention of functional/procedural decomposition? Programmers generally write libraries and then compose them, rather than writing large monolithic programs, irrespective of language.

I think he's saying that Haskell programmers do this more than other programmers. I agree.

> Haskell programmers tend not to write large programs, period. Instead, we build lots of libraries until our problem is trivial to solve.

But if the libraries that you write, taken together, are large, then you are in fact writing a large program. Calling part of it "libraries" doesn't change that. (So far as I can see, that's no different than a C programmer writing lower-level functions, or an assembly language programmer writing subroutines. Everybody does that - at least, everybody sane.)

I wanted to avoid getting into a discussion about the merits of Haskell vs other languages. I was merely making a statement about what I perceive is the common practice of Haskell programmers. Do I believe that Haskell as a language provides features which allow for greater modularity, reusability, composability and generality than most other languages? Yes. However, to explain it all in great detail would take far too long. Besides that, others have already laid much of the groundwork for explaining these advantages in a much better format than I can muster here. Here's one simple example (which happens to describe the advantages of laziness):

http://augustss.blogspot.ca/2011/05/more-points-for-lazy-eva...

> Maybe that just says something about my intelligence, or maybe the functional camp hasn't yet figured out how to write large programs in a readable way.

You make it sound like we've figured out how to write imperative large programs in a readable way.

Well, it's not too bad. I work at Google and spend a significant part of every workday reading other people's code, written in imperative/OO languages. That's not too difficult, if the code uses few abstractions and if you have good tools for reading it, like cross-referencing, version control history and code review history. But the "few abstractions" part is actually important, I can't imagine reading typical Haskell code at the same speed. When you're tracking down a bug or trying to implement a feature that touches several projects, you really need to read fast.

It really comes down to who's code you are reading.

Lens is one guy's pathological abstraction. It's a library, and it's idiosyncratic. It isn't want large Haskell systems "look like".

Cf http://ro-che.info/articles/2014-04-24-lens-unidiomatic.html

I agree that Lens is extreme, that's why I picked it as an example. However, most Haskell code I've seen also has line-noise problems, though not as extreme as Lens. Maybe I just haven't been lucky. Can you point to some good examples of readable Haskell code?

If you work with Java/C/C++ then the way you structure, compose, and think about programs is mostly entirely different from Haskell. Any of the examples I might point to as idiomatic Haskell are going to be "unreadable" ( if that words means anything ) within that worldview, because they come with an entirely different set of constraints and culture than the Java/C++ world.

It would still be nice if you (or somebody else) pointed at those examples. That would open new avenues for learning and communication.

What kind of examples are you interested in?

The most-unreadable Haskell code I've found is from Matrix.Simplex (https://hackage.haskell.org/package/dsp-0.2.2/docs/src/Matri...) :

    addart a = array ((-1,0),(n,m+n)) $ z ++ xsi ++ b ++ art ++ x
        where z = ((-1,0), a!(0,0)) : [ ((-1,j),0) | j <- [1..n] ] ++ [ ((-1,j+n),a!(0,j)) | j <- [1..m] ]
              xsi = ((0,0), -colsum a 0) : [ ((0,j),0) | j <- [1..n] ] ++ [ ((0,j+n), -colsum a j) | j <- [1..m] ]
              b = [ ((i,0), a!(i,0)) | i <- [1..n] ]
              art = [ ((i,j), if i == j then 1 else 0) | i <- [1..n], j <- [1..n] ]
              x = [ ((i,j+n), a!(i,j)) | i <- [1..n], j <- [1..m] ]
              ((_,_),(n,m)) = bounds a

One letter variable names, argh!

reminds me of algos in matlab

Eh, the list of operators is a weird artifact of the design of lens. The fundamental abstractions at the core are fairly simple, although they're exposed in a scary way.

Most of that has to do with optimizing for reuse and proper type inference. It's a cheat to expose the Haskell subtyping relation for more leverage.

A better way to understand lenses should be to consider a package like lens-family-core which keeps to its roots.

Scala had/has an issue with user-defined operators; there was a proposal that all operators should also be able to be called with an english word i.e. provide a named function.

I wouldn't mind if haskell library designers took that practice to heart.

To that end, the lens library exposes named verbs for most of the core operators and both the verbs and operators are chosen with great discretion toward consistency... if not great discretion toward not clobbering related libraries.

Is anyone not freaked out by Lens? Really, that "thing" is scarry... you realize you need something like `^.` from it because it can make life easier, but then you look at the whole jungle of what it really is and your mind explodes.

(^.) is a really simple function actually, I'd argue it's even simpler than fmap. If we look at `lens-family-core` all the machinery to derive everything you need to make lenses is very concise and would fit on a index card.

http://hackage.haskell.org/package/lens-family-core-1.0.0/do...