Hacker News Reader

Comment by dmitriid | Hacker News Reader

How long does it take the “new programmers who have not worked with Haskell before” to learn and understand all the ASCII-art in the example code? How $ differs from <$ differs from & differs from .

On top of trying to remember that <> is string concatenation and >>= and <- have something to do with monads.

View on HN

I still can't understand why Perl is easily dismissed as "LOL line noise" but Haskell's apparently fine. At least dipping into Perl you can take on the line noise slowly so you have time to absorb each new technique, and you can write it just fine with hardly any of that if you want, and it won't hurt a thing—Haskell seems to dump all that on you up front, and it seems to require it, idiomatically. It's very off-putting.

Well, I had no idea what (&), but you just place the cursor on it in emacs and it will say `(&) :: a -> (a -> b) -> b` that, after you learn this language is enough to understand that `v & f` runs the function `f` with the parameter `v`.

If I was trying to discover what function does that, I'd type the `a -> (a -> b) -> b` (yes, it's that obvious) string on Hoogle, and it would show me the operator.

I have never got that experience with Perl. Every new symbol requires a query into perldoc in a new window, every time you don't know what symbol to use, you keep not knowing, because it's impossible to discover.

Besides, Haskell has a consistent value + operator + value structure, while Perl has a mess.

It's because Haskell's type system at least helps you avoid getting the line noise wrong. If you have to refactor some complicated line noise then the compiler holds your hand.

What would an error look like if I misused $ or &?

And yes, compilers hold a user’s hand in most languages (including PHP with type hints :) ).

    • Couldn't match expected type ‘([Integer] -> [Integer]) -> [b]’
                  with actual type ‘[Integer]’
    • Possible cause: ‘map’ is applied to too many arguments
      In the second argument of ‘(&)’, namely ‘map (* 2) [1, 2, 3]’
      In the second argument of ‘($)’, namely
        ‘map (+ 2) & map (* 2) [1, 2, 3]’
      In the expression: map (+ 2) $ map (+ 2) & map (* 2) [1, 2, 3]

In my opinion this doesn’t help much.

Of course not. You have to learn how the type system works to get it.

ghci is my friend. :i and :t go a long way as a backup for my memory. If Perl (or APL, another language criticized for having a vast array, you should pardon the expression, of unfamiliar operators) has something similar, I've not heard of it.

A couple of weeks in my case. It's not any more difficult than remembering that the -> is the cache-miss operator in C++.

You also don't have to learn the entire universe of Haskell before being productive in it. I still have no idea what profunctors, comonads, and other things are and I'm shipping production Haskell code.

If you follow the link to the second article of the series, you’ll see that the author does dump all upfront, hence the question.

A couple of weeks to understand the terse operators (ab)used everywhere in Haskell code is horrendously long time, if you ask me.

Two weeks, Just as much as for any other new language.

After two weeks new member can introduce simple features. After a month - relatively complex ones. Full development speed is achieved after half a year and is roughly equal to all languages because all this time people learn problem(s) domain(s) and its (their) mapping to the code.

For example, if I ask you to optimize Kaldi's HCLG-based decoder, you won't get any interesting results even after two months EVEN if you known C++ well. Just to tip you with something: you can save off about 10% of execution time just by presorting HCLG graph by BFS - it is scale-free and there are nodes which decoder will visit more often than others. To do this, you have to look at the graph, you have to know about scale-free graphs and their properties. Which are way outside of programming language scope.

> Two weeks, Just as much as for any other new language.

What?!! :) I was introducing new features within a day after switching from Java to C#.

New features within less than a week when switching to Erlang (having had little FP experience).

etc. etc.

> For example, if I ask you to optimize Kaldi's HCLG-based decoder

Why would you ask me that? Is it such a common problem?

How about: if I ask you to implement a streaming Google Dataflow job getting data from a Google PubSub and writing data to BigQuery? It’s a much more common request.

Oh, don't let me started on differences between Java and C#. You most probably won't write correct code in C# after day long introduction. Just to stop typing String with capital letter is a more than day long training.

With Erlang you have to master OTP, which is part of language and, frankly, the only reason to choose it. The supervisor tree alone worth a week to see how it will work with different failure cases.

To quote "Real Programmers Don't Use PASCAL":

My first task in the Real World was to read and understand a 2O0,OO0-line FORTRAN program, then speed it up by a factor of two.

https://web.mit.edu/humor/Computers/real.programmers

It is humor, but every joke contains some truth. Optimizing Kaldi's decoder is a critical task if you recognize several thousand voice queries per minute.

Again, to take analogy from outside world. Interpids mostly cruising in under-Mach speeds. It is their common problem. But they are designed to intercept other aircratfs who can fly at MachN speeds and to avoid missiles which are fly at MachN speeds. The difference between under- and over-Mach speeds is... critical? Wings of under-Mach speed airplanes would flatter at Mach1+ and destroy plane itself (see Mig15 wings). Wings of interpid will work on under-Mach speeds just okay.

Common problems are easy to solve if you are ready to uncommon and critical ones. Which are often lie outside of programming language realm, can be solved easily with almost any language and Haskell provides better way to solve them (EDSLs, for example).

Operators are just functions. Learning the type system is the key. You can easily check any function's type signature in the docs once you understand how the type system works.

Or, it's worth mentioning, you can do `:t (<$>)` in the repl to quickly get the type.

The exact same time it takes a programmer who has never seen Java or its close siblings like C++ to learn and understand all the keywords like "public" or "static" or "class" or "interface" or "extends" and how they work.

The only difference is that a random programmer you pick has probably already spent the time understanding Java and OOP, but not Haskell.

Reply on news.ycombinator.com