Hacker News Reader

Comment by amelius | Hacker News Reader

Unbalanced post because it doesn't address evidence against Haskell. For example:

- Performance is lower than most systems programming languages.

- Performance is also more difficult to reason about.

- If Haskell is aimed at building large and complex systems, then where is the evidence, e.g. an operating system? (A compiler is just a pipeline so doesn't count; it is of a different kind of complexity)

- The GHC compiler internals are badly documented (despite some great books about its global architecture). Why do people who pursue clean software engineering methods not follow good software engineering practices?

View on HN

I’m a bit conflicted about your point here, because they seem cherry-picked to highlight disparate aspects of Haskell that don’t make it less interesting or important.

Haskell is more often than not sued as a general purpose language, not as a systems language. Its performance is actually outstanding, usually equal to Java and often close to C. This means that Haskell can be safely used in any domain were java would be fast enough.

I find also somewhat arrogant to claim that there are no complex systems built in it. Just take a look at the webpage publishing this article. They mention several projects of great complexity. Here’s an example: https://www.tweag.io/posts/2017-03-13-linear-types.html

They are using Haskell as a prototyping language that lets the refactor and radically change the direction of their solutions at a low development cost. Haskell clearly is helping solve complexity here.

Also, where did the claim that GHC is badly documented come from, and how is it relevant to Haskell being important?

Just looking at randomly selected file in the repo, it looks actually quite well documented: https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/simp...

> they seem cherry-picked to highlight disparate aspects of Haskell

I only said that the article was unbalanced and provided some counter examples. I didn't say that Haskell does not have many good uses.

I feel you're unfairly comparing Haskell to the likes of C/C++ that it's not really a rival with. Haskell is a (very) high level language, not a procedural language to build systems on.

A more appropriate comparison would be with commonly used high level languages such as Java and Python. The comparison here is meaningful because you'd build similar software with them as you would with Haskell.

There is no such language as C/C++.

Well-written programs in C++ are very different from programs in good C. (Bad programs are all alike.) C++ programs may be easily as "high level" as Haskell ones, higher than is possible in Java. C++ is clearly the language to beat, as no mainstream production language rivals its performance or expressiveness.

Forgive my ignorance, but how can C++ programs be easily as high level as Haskell, which is declarative, garbage collected and curried by default? Does C++ even have algebraic data types, not to mention more advanced stuff like GADTs etc. that are incorporated in Haskell?

I haven't been able to get exposure to a language that is comparable in abstraction power with Haskell, except for DSLs.

"Declarative" is a means to an end. Imperative gets you there at the same rate. Garbage collection compensates for inadequate resource management facilities. Currying is a neat trick that is fun when you find a way to make it do something useful.

Algebraic data types and GADTs are clever ideas very far removed from most real problems faced by real programmers, who have problems no language helps much with, and where the best we, as language designers, can do is try to keep the hell out of the way.

C++ has lots of such stuff too, mostly in template land. They can be useful to maximize the generality of libraries -- sometimes enabling great libraries -- but for most programmers most of the time they are at best a distraction, and more typically generate mysteries that absorb unbounded time.

Mark Dominus has some of the most insightful writing on the experience of coding Haskell.

> Algebraic data types ... are clever ideas very far removed from most real problems faced by real programmers

Everything else you've said has a case that can be made for it but algebraic data types being removed from real problems is utterly false. The contortions that Python programmers (myself being one of them) have to go through in the absence of ADTs are mind boggling. There's no language without sum types that wouldn't be significantly improved by their addition.

All variables are sum types in Python.

In Haskell as in C++, they serve as an escape valve where the formal type system is too constraining. In C++, we see std::optional, std::variant, and boost::result, and don't find we need many more.

Product types are ad-hoc structs, analogous to lambdas as ad-hoc functions. They are important to enable compounding of libraries from different sources, aside from their frequent convenience. Compounding libraries is still hard for other reasons, and so not useful as often as might be hoped.

In Python you have the opposite problem of C++ and Haskell: everything could be anything, and you would like them to be guaranteed to be only one or a few things.

Naturally by "sum types" I mean "sum types plus the associated language-level conveniences that make them reasonable to work with". Perhaps case statements may be enough. Perhaps arbitrary lambdas are needed. Anyway, they're not reasonable to work with in Python. I'm not particularly familiar with C++ but I doubt they're reasonable to work with in that language either.

C++ will probably be getting an equivalent of match statements in a near-future Standard. ("Near" means "before civilization collapses".)

I think declarative is a paradigm, a way of thinking and reasoning about code, rather than a means to an end. Declarative code would obviously raise the abstraction level (as it hides implementation details that you produce with imperative code). I don't see how imperative code would hold an equal abstraction power.

As for ADTs and the like, these are very basic features used all over Haskell code, combined with pattern matching. There are much more advanced abstraction concepts that are used all over Haskell libraries.

I'm sure C++ has good facilities for abstraction. However, as it lacks many of the very advanced abstractions that Haskell has, I find it far fetched that C++ could be described as an equally high level language as the likes of Haskell. From what I understand, that's not even the intention of C++ to begin with.

Btw thanks for that reference to Mark Dominus, seems like interesting stuff!

“Real programmers don’t use x” - said by every proud programmer that don’t want to learn new concepts since the beginning of time.

Real C++ programmers use the hell out of features added because of demonstrated industrial need. Many of them were copied from ML, others Haskell entirely lacks. Haskell has some features C++ doesn't need, that would just make programs harder to understand without actually making the language more powerful.

Would be helpful if you gave some examples!

Unfortunately, without concrete examples it's hard to grasp what features you really mean.

Unbalanced comment because it doesn't address the good points of the article. Yawn.

Probably not relevant, OS written in Haskell does exists, though: https://en.wikipedia.org/wiki/House_(operating_system)

And don't forget HalVM.

Reply on news.ycombinator.com