Hacker News Reader

Comment by dpratt71 | Hacker News Reader

> which string type do I use?

I think this issue is way overblown. The reasons for choosing a particular string representation in Haskell are analogous to the reasons to choose among e.g. byte arrays, streams, string builders, etc. in mainstream programming languages.

> Which prelude?

There is a standard prelude. Unless you actively choose another one, that's the one you'll get.

> Which compiler extensions?

If you want to use certain advanced language features, enable the appropriate extensions.

> Which testing library?

Many mainstream programming platforms (e.g. .NET) have multiple popular testing libraries to choose from. Is this a bad thing?

View on HN

> Which compiler extensions?

If you want to use certain advanced language features, enable the appropriate extensions.

Your answers typify a level of comprehension of Haskell which appears to occupy the same brain space empathy would do. The whole POINT is that there are complex language features which have to be enabled if you want them: how does anyone know a priori in a new situation what to enable and what to disable? What side effects? What consequences?

I loved learning Haskell but to pretend it's syntactic simplicity translates to simple in all things is to misunderstand.

Gcc has a million compiler -W options do you think every C programmer knows them all? Do you think that every cat user knows why we joke about cat -v?

You have mastered Haskell and forgotten what lack of complete understanding means to anyone else. Mastering FORTRAN or pascal or lisp was trivial by comparison.

Mastering the underlying concepts of recursion, and tail recursion, and typing systems, and then integrating optional language features is not trivial.

There's a lot here I would like to respond to, but I'll limit myself to a couple points:

> The whole POINT is that there are complex language features which have to be enabled if you want them

Yes, "if you want them". If you value having a simpler language, don't use them. And Haskell is hardly unique in this regard. You've mentioned GCC, but I think the Babel transpiler is another good example.

> You have mastered Haskell and forgotten what lack of complete understanding means to anyone else.

I've managed to teach my daughter some Haskell, who had no prior exposure to programming languages whatsoever, so I doubt your assertion is entirely true.

The hardest programming language I ever learned was the first one. Each one after that was easier than the one before...until I got to Haskell. It was so different that I was forced to go back to a more fundamental understanding of the nature of code and computation and start from there. It felt pretty challenging, especially at first, but I think that had more to do with my perspective and experience coming into it than the language itself (and the fact that I had a family and career at that point didn't help).

These were examples of the choices one has to make when using Haskell; it is far from exhaustive. The point is that IMO Haskell undervalues consistency and standardization.

I can only directly address the examples you've given. If you disagree with how I've characterized those examples, I'd be interested to know why. If you have other examples, I'd be interested to hear them.

Haskell has its weaknesses, e.g. the lack of quality tooling available as compared to mainstream programming languages.

But I disagree that Haskell is complex, at least as a criticism. When expressing concepts of a similar complexity, I find Haskell to be particularly concise and expressive as compared to most other programming languages I am familiar with.

And if Haskell undervalues consistency and standardization, I would like to know as compared to what? The only programming languages that I know of where there are not many reasonable choices for e.g. a testing framework are those that either (a) haven't been around that long, or (b) haven't seen wide adoption.

I have never seen non-trivial Haskell that didn't enable at least 1 compiler extension. Laziness is difficult to reason about. Purity makes easy things hard in exchange for making hard things easy. You can't even make it through the standard library documentation without bumping into category theory.

Haskell is many things. Simple is not one of them.

> I have never seen non-trivial Haskell that didn't enable at least 1 compiler extension.

Language extensions are idiomatic Haskell. There is only one mainstream compiler used everywhere. Widely used extensions are a natural result when the compiler, as a testbed, can outpace the language standard.

Enabling extensions is as trivial as including a standard library package. (In fact, the extensions are often better documented than the standard library, as you hint to.)

Honestly, I’m content to agree to disagree. I’ve had this conversation too often to repeat it here. The criticisms aren’t novel; I’m sure they’re easily found elsewhere on the Internet.

Reply on news.ycombinator.com