How it feels to join an all-Haskell startup

http://www.wagonhq.com/blog/first-two-weeks-haskell-wagon

by begriffs • 11 years ago

89 55 11 years ago

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.

msie• 11 years ago

I agree. Could understand that first snippet, the second, not so much. I'm appreciating Javascript more and more because stuff like that doesn't happen there.

jonnybgood2• 11 years ago

This is common complaint I see of the Haskell community where there is always an attempt at cleverness over clarity.

ricccardo• 11 years ago

Unfortunately I think it's the language, not the community. It definitely happenes with my own code as well, no hints from external developers are required :-) I miss Python in this regard.

danidiaz• 11 years ago

The use of Applicative is actually an attempt at clarity, by restricting the kinds of things that the code can actually do.

As it name implies, Applicative is a kind of "effectful application". There have been proposals to implement a more natural syntax that makes the connection more clear.

spopejoy3• 11 years ago

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.

jonnybgood2• 11 years ago

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.

cousin_it• 11 years ago

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.

tel5• 11 years ago

I was about to try to talk about the genuine elegance of Applicatives—and I'm more than happy to defend them in general—but then, yeah. In this instance, I'm not sure I'd be able to argue that the change was such a good choice.

    liftIO (liftA2 (,) randomIO getCurrentTime)

Eh, I'm not sure I could defend it. I'd honestly probably actually do

    bid <- liftIO randomIO
    now <- liftIO getCurrentTime

dllthomas2• 11 years ago

Of course, there is always https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo

tel5• 11 years ago

It's worth noting that there's a small potential performance penalty to this if it's being called all the time and it's being lifted through a large transformer stack.

droque• 11 years ago

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)

le0n• 11 years ago

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

pash3• 11 years ago

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 prefer the abstraction that is "just powerful enough", or what's the same thing, they prefer the abstraction that is "least powerful"—that is, Haskellers try to write code in a way that lets them do what they want want to do, but at the same time in a way that doesn't allow them do things they didn't mean to do. And for just that reason: using the least powerful abstraction prevents you from introducing bugs by keeping you from writing some of the things that you didn't intend to write.

Thus the least powerful abstraction is the best abstraction, in the sense that it's the "best fit" (and, yes, also in an aesthetic sense). So if you can write what you want using applicatives rather than monads, you should prefer applicatives, the argument goes. (And if you can write it with functors, prefer functors to applicatives.) For the same reason, many Haskellers prefer to use restrictions of the IO type that limit what you can do rather than IO itself, whenever it's convenient.

Applicative style, in this case, also keeps you from having to name a couple of things, which means two fewer "hard things" (in Dijkstra's estimation) for the programmer to deal with—and just two fewer things, which means two fewer things to screw up, period.

The counter-argument, that applicatives are somehow more complicated or less clear than monads, is a poor one, I think. Haskell is not a superficial language. It's not one you're meant to be able to read and understand just because you're a competent programmer in some other, unrelated language. If you want to program in Haskell, you need to understand the languange's core abstractions—and, yes, applicative style is one of them at this point. That does mean there's more to learn. But Haskell is all about giving programmers the ability to recognize and use the right abstraction; the time spent learning is worth your while.

Further, if you're not a Haskell programmer, I think you should beware of pretending that you understand the monadic "before" code and therefore thinking that it's simpler than the applicative "after" code that you don't pretend to understand. First, because (syntactic subterfuge notwithstanding) you don't really understand the monadic code, unless you've learned the underlying concepts; and second, because it's not simpler. It's just not. There is more going on in the monadic code, not less. Now, if you're a beginner and you understand monads but not applicatives, you have an argument—the monadic code is familiar, and the applicative code isn't—but that just means you have more to learn. Go learn it. We're here to help.

tjradcliffe• 11 years ago

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!

cherry_su• 11 years ago

Of the three, I'd contend <$> is the most reasonable to do since it's very similar to $ (which is commonly used), but applied to a boxed argument (Functor).

tel5• 11 years ago

On the other hand, <*> is closer in spirit to what $ is.

thrwwy52• 11 years ago

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.

dullcrisp• 11 years ago

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

wetmore• 11 years ago

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.

jbergens• 11 years ago

That is one point of having code reviews, to get everyone in a team or an organization to write (mostly) the same type of code.

thom• 11 years ago

One of our Haskellers once tried to explain the bizarre internal consistency of the many Haskell's lens operators. It's basically just trolling in API form:

https://hackage.haskell.org/package/lens-3.8.5/docs/Control-...

Dewie33• 11 years ago

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

bgar• 11 years ago

(,) <$> and <*> are very common functions that every Haskeller knows... the revision is understandable if you write Haskell.

m_mueller• 11 years ago

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.

purescript2• 11 years ago

An Applicative functor is a type constructor which lets you lift functions of arbitrary numbers of arguments to functions whose arguments are wrapped with that type constructor.

Concretely, if you think about promises in JavaScript, for example, if you have a function A -> B -> C -> D, say, and you have three promises of types Promise A, Promise B and Promise C, you can construct a Promise of type Promise D by running the three in parallel, and applying your three-argument function when they are all done. So you've turned a function of type A -> B -> C -> D into one of type Promise A -> Promise B -> Promise C -> Promise D. If you can do that sensibly for any number of function arguments, you have an Applicative. ("sensibly" here means that there are type class laws which have to hold)

Every Monad is also an Applicative functor, since you could use do notation to compose your promises instead, but there are other interesting Applicatives which do not come from Monads.

spopejoy3• 11 years ago

In most cases (like the example), it simply allows you to call "effectful" code (often monadic, IO etc) to populate arguments of a function.

My favorite example is "I want to grab three web pages concurrently and return them in a single triple." To the haters who think this is just golf, just TRY to write this as beautifully in any other language.

  (page1, page2, page3)
     <- runConcurrently $ (,,)
     <$> Concurrently (getURL "url1")
     <*> Concurrently (getURL "url2")
     <*> Concurrently (getURL "url3")

(taken from the excellent haddocks for Control.Current.Async https://hackage.haskell.org/package/async-2.0.1.4/docs/Contr...)

doublec2• 11 years ago

Alice ML:

    val (page1, page2, page3) = (spawn getURL "url1",
                                 spawn getURL "url2",
                                 spawn getURL "url3")

The requests are concurrent. Spawn returns a future and 'page1', etc are futures immediately. When the value of 'page1', etc is requested later the requesting process either blocks until the getURL for that value is complete, or transforms into the value implicitly if it's already done.

I think it's just as nice as the Haskell example. I do agree that Haskell is a great language though.

nbouscal• 11 years ago

Applicatives are definitely something that every Haskell programmer knows. I would expect everyone on the team to understand the recommended new version, but it's less clear whether it is actually an improvement. There is a proposal to allow applicatives to use the same syntax as monads (the original code, before the change), which would render the question moot: https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo

dllthomas2• 11 years ago

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

buckie• 11 years ago

As someone who also recently joined an all haskell team, but hadn't coded professionally in haskell before, I'll add the biggest thing I've noticed to the "how it feels" list:

On a biweekly basis I'm shown something new causing my brain to melt, leak out of my ear & pool onto the floor near my desk. It's awesome[0]!

Today's was using impredicative types + `$` has a special case for dealing with it[1].

[0]: ...some number of hours later when I've collected my thoughts and think "OHHH... duh" [1]: https://ghc.haskell.org/trac/ghc/wiki/ImpredicativePolymorph...

gohrt3• 11 years ago

Love it or hate it, those 2 screenshots are life of a Haskeller:

1. ever-more compact abstractions with awkward names

2. chasing down space leaks with janky gnuplot'd reports.

suls• 11 years ago

As much as I would love to use Haskell professionally, I always wonder if teams/projects using Haskell don't also struggle with all the sociology involved in developing software ..

Sure, being able to use Applicative reduces lots of code duplication, brings in better clarity and all .. but what if the product owner still remains a jerk without a vision?

In all the teams I have been so far, I can honestly say that the _language_ itself was never _the_ problem. It was always a combination of communication, skill or product vision.

The only thing I can imagine is that by choosing Haskell you tend to get better skilled developers - so only communication and product vision remain that could ruin your project/product.

Any thoughts?

dons• 11 years ago

Habitually rewriting things in applicative and/or pointfree is a sure sign of a junior Haskell dev. One who has never had to maintain someone else's code.

There are cases where it helps (e.g. structured parsing), but all too often this is simply obfuscation. Even if motivation is good -- learning new structures -- you still have to focus on cost/benefit of each change in structure.

Keep it simple, folks.

chriswarbo4• 11 years ago

I'm generally in favour of introducing applicatives, but I don't think the code in the article is a good example:

    (bid, now) <- liftIO $ do
        b <- randomIO
        n <- getCurrentTime
        return (b, n)

    (bid, now) <- liftIO $ (,)
        <$> randomIO
        <*> getCurrentTime

The applicative code could be considered better, since it avoids one-shot variables. However, that's not the biggest smell with this code. To me, the problems are:

- Constructing-then-destructing a pair; is it really necessary?

- Use of `$`; is there a way to avoid having to alter the precedence?

- Combining two seemingly unrelated actions into one; `randomIO` should be completely uncorrelated to the current time, so why put them in the same action?

- Potential laziness issues; it looks like we're using the `(bid, now)` combination to ensure the two IO actions are executed together, but will they be? WHNF will give us `(_ , _)`; if we force `bid`, will `now` also be forced?

Not saying I have answers to these, but I would say those are more "smelly" than the do-notation with a return

tome• 11 years ago

Code review 4 lines: hundreds of comments

Code review 1000 lines: "Looks fine"

reagency• 11 years ago

How would you write it? Creating a pair does seem weird, unless those two values are going to be passed around through multiple method calls together for use in multiple locations.

How it feels to join an all-Haskell startup

Related Stories