Live data from Hacker News

How it feels to join an all-Haskell startup

wagonhq.com

21–30 of 59 posts

Re: How it feels to join an all-Haskell startup

#21

Could someone explain 'applicative'? To me it seems like throwing some magic syntax at a simple usecase to make it more terse and less readable - but maybe I misunderstand and it's something every Haskell programmer knows.

There's no actual magic syntax, just some ordinary operators.

    () is infix "fmap"
    () is infix "ap"
The "fmap" function lets you apply something of the form (a -> b) to a value of the form (m a), to get something of the form (m b). Specialized to lists, it's the familiar "map" function, but there are a lot of other things it can apply to.

The "ap" function lets you apply a "wrapped" function to a "wrapped" value - "apply this list of functions to that list of values".

The way these combine, along with currying, means you get a well known pattern for applying a many argument function to many wrapped values:

     before the first argument
     before every remaining argument
It works out like this:

    let add3 :: Integer -> Integer -> Integer -> Integer
        add3 x y z = x + y + z

    (add3 5) :: Integer -> Integer -> Integer
    (add3  Just 5) :: Maybe (Integer -> Integer -> Integer)
    (add3  Just 5  Just 3) :: Maybe (Integer -> Integer)
    (add3  Just 5  Just 3  Just 9) :: Maybe Integer

Re: How it feels to join an all-Haskell startup

#22
post #9

How was that snippet an improvement to your coding style? The original was extremely clear, and now someone who reads your code has to understand what (,) and do. IMO this tendency for code golf one-upmanship is a huge detractor for anyone wanting to learn the language.

They're about equivalent IMO, which yes, means golf. However, I don't see what's so terrible about learning 3 new functions . Sorry it doesn't look like Javascript anymore.

I don't think the issue is learning 3 new functions. The author appears to be an experienced Haskeller, so I'm sure they're aware of applicative functors. I think the issue is whether the usage of applicative functors was necessary or just for the sake of being clever for no added benefit.

Re: How it feels to join an all-Haskell startup

#23

How was that snippet an improvement to your coding style? The original was extremely clear, and now someone who reads your code has to understand what (,) and do. IMO this tendency for code golf one-upmanship is a huge detractor for anyone wanting to learn the language.

This to me is the biggest barrier to reading anyone else's Haskell code. It seems like it's always full of unfamiliar, ungooglable infix operators.

Re: How it feels to join an all-Haskell startup

#24
post #23

How was that snippet an improvement to your coding style? The original was extremely clear, and now someone who reads your code has to understand what (,) and do. IMO this tendency for code golf one-upmanship is a huge detractor for anyone wanting to learn the language.

This to me is the biggest barrier to reading anyone else's Haskell code. It seems like it's always full of unfamiliar, ungooglable infix operators.

Try https://www.haskell.org/hoogle/.

Re: How it feels to join an all-Haskell startup

#26
post #23

How was that snippet an improvement to your coding style? The original was extremely clear, and now someone who reads your code has to understand what (,) and do. IMO this tendency for code golf one-upmanship is a huge detractor for anyone wanting to learn the language.

This to me is the biggest barrier to reading anyone else's Haskell code. It seems like it's always full of unfamiliar, ungooglable infix operators.

If you are hired at a company exclusively doing Haskell there is no way you haven't seen , , or (,) before.

In this case, the reason the OP didn't think of writing it with Applicative isn't because he didn't know about them (I assume), but just because he didn't think to use it in that particular case.

Re: How it feels to join an all-Haskell startup

#27
post #15

How was that snippet an improvement to your coding style? The original was extremely clear, and now someone who reads your code has to understand what (,) and do. IMO this tendency for code golf one-upmanship is a huge detractor for anyone wanting to learn the language.

The change they made was from a monad to an applicative, which is less "hands on", thus preferred. Kind of preferring map over hand-written loops. (Although the golfing is definitively there and in the community, see pointfree/pointless style https://wiki.haskell.org/Pointfree )

I prefer comprehensions over either mapping or explicit recursion. Mapping is a win for abstraction but a loss for clarity.

Re: How it feels to join an all-Haskell startup

#28
post #9

How was that snippet an improvement to your coding style? The original was extremely clear, and now someone who reads your code has to understand what (,) and do. IMO this tendency for code golf one-upmanship is a huge detractor for anyone wanting to learn the language.

They're about equivalent IMO, which yes, means golf. However, I don't see what's so terrible about learning 3 new functions . Sorry it doesn't look like Javascript anymore.

I feel that it's important to have code that is immediately readable and understandable, without requiring much context. Smalltalkers had it right:

> If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.

Imagine you're reading a musical score. Suddenly there's an unfamiliar symbol. Oh right, you need to turn to page 5 to figure out how it's defined. Oh no, it's defined in terms of more symbols. There goes your flow.

The tools that enable the most creativity are the tools that you can hold in your head completely, while you focus on the task at hand. C is a tool like that, regardless of its other drawbacks. Unfortunately, Haskell isn't quite like that, due to its culture of extracting every little thing and giving it a unique name. Now you need to memorize all these names, instead of e.g. understanding the concept of a "for loop" once and applying it forever.

Re: How it feels to join an all-Haskell startup

#29

How was that snippet an improvement to your coding style? The original was extremely clear, and now someone who reads your code has to understand what (,) and do. IMO this tendency for code golf one-upmanship is a huge detractor for anyone wanting to learn the language.

That refactor is of a common pattern (I've seen it before; I've probably written it myself) into a bog-standard use of Applicative code. This use is pretty much the introductory example for Applicative. Do you use Haskell? Because Applicative is fairly well-known, and the operators etc. aren't considered esoteric and they are not something you are likely to have to learn when you encounter them. If you don't use Haskell, on the other hand, I don't see how you are in a position to critique the readability of a refactor.

The philosophy at play here is probably not code golf as much as it is about the principle of least power[1]. Applicative is strictly less powerful than Monad. So when reading Applicative code, there is less stuff to look out for -- it is great to be able to know what an expression can't do, when reading it.

Maybe the do-notation makes it look prettier, but I don't know if it makes it more readable. Maybe more superficially look like imperative code which makes one think Oh, I get this. But it might be a false sense of safety. In any case, I guess Applicative do notation can be used (at some point).

[1] http://en.wikipedia.org/wiki/Rule_of_least_power

Re: How it feels to join an all-Haskell startup

#30
post #17

How was that snippet an improvement to your coding style? The original was extremely clear, and now someone who reads your code has to understand what (,) and do. IMO this tendency for code golf one-upmanship is a huge detractor for anyone wanting to learn the language.

It's somewhat debatable whether the refactor is an improvement, but there is at least one good argument that it is, and (in my opinion) only a much poorer argument that it makes things less clear. If the applicative code is better, it's because applicatives are strictly less powerful than monads, in the sense that everything you can do with applicatives you can also do with monads, but not vice-versa. Many Haskellers…

> at this point

Which is a huge problem. Optimizing around the current fashion is generally a mistake.

As for the rest: the argument seems to come down to "there are no junior developers in Haskell, because if you don't understand the deep and dark abstractions you're really hardly better than a barbarian anyway."

This translates to: Haskell is doomed as a production language in the real world beyond a few niche/fetish applications, because "real" Haskell devs are always going to be scarce and expensive.

This was the selling point of Java back in the day: you could hire junior Java devs to do much the same things as senior C++ devs because the language was so much safer. I saw this in action. It was impressive. It was also around the time when the current fashion in Haskell was lazy evaluation, which I've seen modern Haskell fashionistas pronounce "not really so important after all".

Fashions change, and Haskell is a highly fashion-driven langauge, which means there will be a lot of unmaintainable Haskell code out there in five or ten years.

That's my prediction at least. Let's look at the issue again in a decade and see if I'm right or wrong!

Post reply on HN