Live data from Hacker News

How it feels to join an all-Haskell startup

wagonhq.com

31–40 of 59 posts

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

#31
post #9

Earlier quoted context omitted.

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 define…

I think this is a bad comparison. If you're, say, reading music in order to play it, why would you need things like functions and renamings in order to read it? Just read it straight off - one bar at the time. There isn't any need to have some kind of "pattern" or "abstraction" that compresses 20 bars into "this one thing, more or less". And you would have to read all of it to play the piece faithfully anyway. Maybe there is some utility to be able to say "I don't care about the nuances; just show me the general structure right now". I don't know, I'm not a composer.

On the other hand, it is of course tremendously useful in programming to look at some lines of code and be able to say "Oh, so this code this and that", then moving on. If you want more details, dive into that section more. You soar over the code to get an overview and dive down for more specifics when you need to. A music piece can be read (and played) from beginning to end, but that is less useful in programming. Maybe for a late evening with a bottle of wine when you want to appreciate the beauty of a code base that you really like, I guess.

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

#32

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 is common complaint I see of the Haskell community where there is always an attempt at cleverness over clarity.

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.

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

#33
post #17

Earlier quoted context omitted.

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/feti…

You have some points which are to a point, and in general, true. But you present them in such a ridiculously hyperbolic way that it seems divorced from reality.

Applicative is a pretty standard type class which are often used in introductory resources. It is not likely to be replaced by anything any time soon. If you think that it is a fashion then you should have an idea about what it can/is likely to be replaceable by. So, please do tell.

If anything, Applicative might be less controversial than Monad. I haven't really seen much complaints about the downsides of the usages of Applicative.

"Barbarian" - of course any fairly level-headed explanation of Haskell concepts gets regarded as elitist. It's practically a cliché at this point.

Lazy evaluation - this was pretty much the whole point of the language. A fashion? It permeates the language, being the default evaluation strategy after all. But it is controversial whether it is better than strict (eager?) evaluation. If opinions change about this it might be because someone unearths some way to get more of the benefits of lazy evaluation, and less of the space leaks. And potential discoveries are kind of the point of research languages like this.

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

#34

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.

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

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

#35

Earlier quoted context omitted.

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

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.

Kind of ironic seeing as Python takes quite a few things from Haskell, like comprehensions, and zip.

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

#36
post #17

Earlier quoted context omitted.

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/feti…

Fashion? Haskell's core abstractions are not design patterns du jour. They're math. They're not going away.

The fashionistas are the programmers who want to pick up a bit of Haskell to impress their colleagues but don't want to learn the abstractions that make it a languange worth learning in the first place. They're the people who read about it on Hacker News and decide it's worth a few hours—enough that they can slap it on their résumé and garner a few more calls from recruiters—but no more. They're the people who insist there's something wrong with your code if a Javascript programmer can't immediately comprehend what's going on, and who can't be bothered to learn how and why to use applicatives.

Despite its minor vogue, Haskell as a language is, by its nature, about as far from fashionable as you can get. And, yes, that's true in part because it takes a lot of time and effort to learn it to a productive level. Haskell has never claimed Java's selling points. There's a lot to learn. But it rewards the effort you put in, eventually.

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

#37
post #9

Earlier quoted context omitted.

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 define…

Sheet music is positively packed with unfamiliar, unpronouncable, ungoogleable squiggles.

Imagin you're reading a musical score, with no fancy symbols, just a waveform of the sound you should produce. What could be simpler, you say?

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

#38
post #31

Earlier quoted context omitted.

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 define…

I think this is a bad comparison. If you're, say, reading music in order to play it, why would you need things like functions and renamings in order to read it? Just read it straight off - one bar at the time. There isn't any need to have some kind of "pattern" or "abstraction" that compresses 20 bars into "this one thing, more or less". And you would have to read all of it to play the piece faithfully anyway. Maybe…

And imagine tying to compose a 45-minute sonata, laboriously penciling one note at a time, instead of an overlay of broad strokes -- melody lines, crescendos, codas, ect.

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

#40
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?

Post reply on HN