
Why I think Haskell is the best general purpose language as of June 22 2019 - azhenley
http://www.philipzucker.com/why-i-as-of-june-22-2019-think-haskell-is-the-best-general-purpose-language-as-of-june-22-2019/
======
harry8
Today's wildly unpopular reality check for language booster-ism reminds you
that there are next to no applications written in Haskell for a purpose that
isn't programming a computer. When we do this exercise we can't get to double
figures and nobody had a meaningful explanation as to why that is the case for
a language that has been around with claims of being useful as a general
purpose programming language for more than 2 decades.

~~~
anoncake
This is just completely irrelevant. Quality and popularity are independent
concerns.

~~~
philzook
But to be fair, they should be positively correlated. Unless the world has
beaten us down into nihilism and we think merit doesn't even tend to be
rewarded.

~~~
anoncake
I'm sure they are although for programming languages that correlation seems to
be particularly weak. But judging the quality of a programming language by its
popularity causes a kind of distributed circular argument: People use a
programming language (=it is popular), so we assume it is good. We use it
which means it becomes even more popular, convincing other people it is good
etc.

When making a decision, using popularity as an easy but noisy indicator for
quality can still make sense. If you kept your choice secret, you wouldn't
even cause any negative externalities. But here, we don't make a decision so I
don't think popularity is an argument worth considering (when evaluating the
merits of the language itself, popularity does affect ease of hiring of
course).

------
bgorman
Unfortunately I think it is hard to take a "Haskell is the best" article
seriously with no comparison to Clojure or Ocaml. Personally I am skeptical
that typeclasses + an expressive type system bring more benefits than i simple
parallelism, an easy to use macro system and atoms/STM for state management.
It can take programmers months to be productive in Haskell. It should only
take a few days to be productive in Clojure. I think the cognitive overhead of
having to deal with ADTs/Monads is too easily dismissed/disregarded.

~~~
philzook
My accounting of languages was not thorough. I picked very common languages
and Haskell. I am also not sufficiently familiar with clojure to form
judgement. I am skeptical that a language without a type system will scale in
mental and project complexity well, but it might. Lisps intrigue me very much,
and any language with passionate proponents is worth looking at. I am
currently trying to learn OCaml and find it very nice. I think it may be more
pragmatic than Haskell in many respects. Strictness is easier, grabbing
mutation and side effects is easier (is it gonna hurt me later though?). I am
concerned that the community feels smaller and learning resources are scarcer.
I don't love the syntax (a quibble). I think it leads to less power of
abstraction, either as a community aesthetic or perhaps as a language
constraint. I would be perfectly content if my friends accepted OCaml. Perhaps
I will change my mind and then you will find an article labelled "I (as of X)
think OCaml is the best general purpose programming language" on my blog.
Haskell is indeed hard.

~~~
rkangel
I'm interested you think the Haskell community is bigger than the OCaml one.
Without checking any sources, I would have assumed the OCaml has a larger
community of people using it in production for a variety of things, and
therefore would have have the libraries etc. for me to build my thing.

I suppose this is my bias - the only community I care about is the engineering
side as supposed to my academic side.

Also look at ReasonML (and bucklescript). I have tinkered with it for Web
front end and been very impressed.

~~~
philzook
I haven't figured out where on the internet OCaml people live. Maybe they have
better things to do with their lives than proselytizing. There is very clear
bias in my opinions and information. Jane Street is a very prominent
industrial user for which I can't really think of a Haskell equivalent of that
company size. ReasonML is a nicer syntax. Kind of seemed like if you wanna do
ReasonML you need to know both OCaml and ReasonML though on a cursory glance.

~~~
bgorman
In my opinion the worst thing about the Ocaml/ReasonML platform is that
discovery of language features/syntax/functions is needlessly difficult. There
is no Hoogle equivalent for OCaml. Module functors are powerful, but the type
system is very strict so it can be frustrating trying to express what you
want. There are some techniques that are rarely covered by books and are
almost impossible to google for. By contract, I think Haskell's typeclasses
gives useful guard-rails to composing "complicated" logic. Overall, as someone
who has been programming full-time in ReasonML for 9 months now, there are too
many times places where I still feel like a "prisoner" of the type system for
me to advocate for it over Clojure. I need to do more projects with Haskell, I
am hopeful the built in typeclasses can reduce the time I am "stuck".

------
philzook
Author here. This is deeply amusing that among all the posts I write, the
rushed half cogent Haskell rant rehashed for the billionth time gets the most
attention. I guess that makes sense.

~~~
timClicks
I find that with anything I write. The considered post that took weeks gets no
attention, but people latch on to my 10 second tweet

------
dreamcompiler
I'm a Lisp expert. Learning Lisp (a long time ago) blew my mind. Learning
Haskell (recently) blew my mind a second time. There are some things I can
express in Haskell that I can't -- at least not easily -- in Lisp. And that
had never happened before to me, with any other language.

~~~
projectileboy
I’m intrigued - can you share an example?

~~~
dreamcompiler
Automatic currying: Haskell does it; Lisp doesn't. You can do partial
evaluation in Lisp but it's not as convenient. This makes Haskell more
functional than Lisp and eliminates one use case (or maybe more) for macros.

Laziness: You can build infinite data in Lisp but again, it's not as
convenient.

Monads: Possibly the most mind-bogglingly useful programming pattern I've
explored in the last 20 years, and you can't completely build them in Lisp.
You can get about 75% of the way toward monads in Lisp but that last 25%
requires manual one-off coding because Lisp functions don't automatically know
the types they return. Even using macros I haven't figured out a way to solve
this problem.

~~~
kazinator
On the other hand, Lisp gives you variadic functions like (list) (list 1)
(list 1 2 3 4). Lisp catches it in a straightforward way when you pass too
many parameters to a non-variadic function, or fewer than the required number
of parameters to any function. (cons 1) is a plain and simple error rather
than a correct expression that evaluates to an unintended (lambda (x) (cons 1
x)) term. Macros can provide a clear explicit syntax for partial evaluation in
which everything is visibly delimited, like (op cons 1).

~~~
dreamcompiler
I think you're highlighting the downside of ubiquitous laziness. In a lazy
world there's nothing wrong with (lambda (x) (cons 1 x)). But if you want to
call this an error earlier, I agree that Lisp defaults in that direction.

------
jes5199
Haskell people claim that combinators and monads are clear, but in practice
the code seems to be write-only. Each combinator might be simple, but that
doesn’t mean that the result can be understood easily. And monads have the
same problem, except they aren’t simple.

~~~
jsjolen
Javascript programmers seem to have no problem using a monad every day
(promises), and they are huge fans of do-notation in the from of async/await.
Imperative programmers do not seem to have an issue with the idea of
assignment, why are monads problematic?

By "combinator" do you mean combinator as in the combinator pattern?

I have no idea what value your comment brings us except a way for people who
already agree with you to give you upvotes, and what's the point in that?

~~~
dragonwriter
> Javascript programmers seem to have no problem using a monad every day
> (promises)

Using (something similar to) _a_ monad (Javascript promises do not form a
monad) successfully is different than using the monad abstraction
successfully.

> and they are huge fans of do-notation in the from of async/await.

Async / await is not monadic do-notation. Arguably, it has a somewhat similar
relationship to the underlying promise abstraction that do-notation had to the
monad abstraction, but they aren't the same thing.

> Imperative programmers do not seem to have an issue with the idea of
> assignment, why are monads problematic

Why are the two halves of this sentence connected to each other since they
have no relationship other than the proximity they've been (bizarrely) placed
in.

~~~
jsjolen
Yeah, you're right that in some manners JS's promises do extend the semantics
of a monad (notably in its impl. of return) but it is a monad though:

function bindPromise(p, f) { return p.then(f); } function returnPromise(a) {
return new Promise.resolve(a); }

Proof of the laws left as an exercise to the reader :).

But yes, you are correct that promises do quite a bit more than only being a
monad, for example because of how they treat errors.

EDIT: I concede, I am wrong! [https://buzzdecafe.github.io/2018/04/10/no-
promises-are-not-...](https://buzzdecafe.github.io/2018/04/10/no-promises-are-
not-monads)

------
jmull
Don’t take this too seriously. He essentially says in the intro he’s writing
this to troll his developer friends.

And, here’s his first reason for liking Haskell:

> The number one reason is that there is something ephemeral that I just like.
> I am not naturally inclined to analyze such things. When I like a movie or
> don’t like it, it just happens, and if forced to explain why, I’ll bullshit.

------
0815test
Haskell is nice, but it has plenty of room for improvement. The duality of
strict vs. lazy eval is not really treated in an elegant or principled way,
for example - which is one of the drawbacks OP mentions in their blogpost.
There are theoretical approaches (polarity, focusing) that might work well for
this.

~~~
philzook
Interesting, thanks! There are many exciting possibilities for the future of
programming. My point to my friends is that I actually think Haskell is a
shockingly pragmatic choice right now, despite how much my goofing around
implied otherwise.

------
viburnum
I really tried with Haskell but for me it was just impossible to refactor code
without rewriting the whole program.

~~~
Fellshard
I've been considering lately why that doesn't seem to ring quite true. I
thought this for a time, then realized that a fair bit of this concern comes
from lack of intuition.

When you started out refactoring and making changes to object-oriented
programs, how much did you have to rip out and alter each time?

How did that skill improve as your designs became more thoughtful, as you
began to see the seams and tailor your designs to fit those seams?

I believe the same would apply for Haskell: its seams are different, but the
separated concerns that come from experience and intuition should allow you to
follow those seams more closely.

------
kadblas
Qualification: I was introduced to FP a number of years ago and have finally
reached a point where I feel that I have a deep understanding of FP in
general. In my mind, Haskell is the "best" language out there ("best" in that
it provides the best overall gain when all tradeoffs are considered).

I'm no longer confident that Haskell is the "best" language anymore. I was
recently introduced to a language that might be even better than Haskell:
Dyalog APL. ([https://www.dyalog.com/](https://www.dyalog.com/)). Try it out
yourself ([https://tryapl.org/](https://tryapl.org/))

To explain why, I recommend watching Aaron Hsu's videos on Dyalog APL:

\- Does APL need a Type System?
([https://www.youtube.com/watch?v=z8MVKianh54](https://www.youtube.com/watch?v=z8MVKianh54))
- This is actually a very interesting question that is more nuanced than upon
first glance.

\- Design Patterns and Anti-Patterns in APL
([https://www.youtube.com/watch?v=v7Mt0GYHU9A](https://www.youtube.com/watch?v=v7Mt0GYHU9A))
- The main takeaway from this video for me was the principle of "Idioms over
libraries."

\- Higher Performance Tree-Wrangling, the APL way
([https://www.youtube.com/watch?v=hzPd3umu78g](https://www.youtube.com/watch?v=hzPd3umu78g))
- Or how to model Trees without using pointers by using "Inverted Tables." (An
inverted table is a table where the columns are the rows and the rows are the
columns)

------
nunez
Why does Ruby always get the shaft? It is pretty easy to learn, VERY
expressive and readable, extremely easy to write tests against and works great
with the web!

~~~
pjmlp
And slow as a snail versus anything else.

~~~
FranzFerdiNaN
Which doesn’t matter for most of the programs out there.

~~~
pjmlp
Given that one can be productive as Ruby, and still enjoy the benefits of
AOT/JIT compilation to native code, I beg to differ.

------
neonate
[https://web.archive.org/web/20190623200107/http://www.philip...](https://web.archive.org/web/20190623200107/http://www.philipzucker.com/why-
i-as-of-june-22-2019-think-haskell-is-the-best-general-purpose-language-as-of-
june-22-2019/)

------
galaxyLogic
The article makes many good points about Haskell including cons: "Very
difficult learning curve. Let’s get real. Haskell is a very confusing
programming language to get started in for common programming tasks."

I can't avoid the comparison in my mind that Haskell is like Latin, spoken by
priests, a very nice language Latin is.

------
Ice_cream_suit
"I have a tendency to joke about almost everything and have put forward that
we use many interesting but not practical languages in the same tone that I
suggest Haskell. This was a tactical mistake."

Cry wolf too often ot be an assh*le too often, and expect this....

~~~
philzook
Haskell is very, very funny. Coq brings tears of amusement to my eyes. I
couldn't and can't resist. ( _shrug_ )

------
pjmlp
Programming languages don't live in vacuum, libraries, IDEs, supported OSes,
and developer communities are also part of it.

I enjoy Haskell a lot, but trying to create a CMS, desktop GUI or a console
game in Haskell? Good luck with the existing tooling and libraries.

~~~
azhenley
What functional language would you recommend for something like a GUI
application then? I have very little experience with such languages but am
always looking forward to trying one when I get a chance.

~~~
pjmlp
There is none that can match the tooling of Delphi, C++, .NET, Java,
Swift/Objective-C for RAD UI development.

Even the languages that target the JVM or CLR are not supported on the
existing GUI tooling, forcing you to do workarounds.

So Scala, Clojure, F# can do it, but you end up having to save JavaFX or WPF
layouts, while throwing away the generated code, and load them via library
calls.

Or you write the UI layer in Java/C#/VB.NET/C++, while writing the rest as a
library.

So at the end of the day you are forced to chose between RAD productivity or
FP purity.

EDIT: I have naturally forgot Common Lisp, but for that you should make use of
Allegro or LispWorks, not Emacs + FOSS Lisp compiler.

------
iamdamian
I love Haskell.

But I can’t understand why record syntax is 1) completely necessary to write
manageable type systems and also 2) known to be half-baked.

I also wish the community was better at embracing newcomers and teaching them
one step at a time.

Other than that, I have no complaints.

------
blacksqr
"The number one reason is that there is something ephemeral that I just like."

~~~
philzook
I think this is the most honest statement in the post.

~~~
HelloNurse
Most of the mentioned C++ issues, for instance, are also Haskell issues (in a
different form).

~~~
philzook
They are similar in that they are both kind of big languages with many
features, and a reputation for difficulty. However, Haskell's reputation is
one for difficulty on how to do anything at all but once you do the angels
sing, while in C++ it is difficult to do anything right. I think the positive
lists diverge significantly, and I don't really think of the languages as
being similar at all.

~~~
HelloNurse
I didn't mean that C++ and Haskell are particularly similar, but that if the
feature set of C++ is "huge" the even more arcane Haskell language extensions
are in the same league, that legacy features that shouldn't be used in C++ are
no worse than multiple half-baked incompatible libraries for the same basic
purpose in Haskell, that if C++ is full of footguns Haskell is full of footgun
categories, that if C++ syntax is verbose Haskell syntax is bizarre and
misleading.

Evidently, being in love with a programming language is an obstacle to
comparing it honestly.

~~~
philzook
It is very, very, very difficult to be in love with a language and compare it
honestly. I don't think I've ever seen anyone successfully do so. I don't
agree that Haskell has as many footguns or as much legacy cruft, but if you've
found that to be the case, I value your opinion.

~~~
tome
> I don't agree that Haskell has as many footguns or as much legacy cruft, but
> if you've found that to be the case, I value your opinion.

And moreover, please write a blog post or even short comment about it, because
few Haskell footguns are obvious to me and I would appreciate the warning!

~~~
philzook
A short list off the top of my head:

It is very easy to get over eager and use more abstraction than you need or
can handle. This is perhaps the worst of them.

Strings shouldn't be [Char]. OverloadedStrings should be the default.

There are partial functions in base. head for example

It is easy to spring space leaks due to laziness.

Relatedly, choosing between foldr foldl foldl'

Incomplete pattern matching (which will be a warning) or sometimes default _
casing. If you add to the type, the compiler won't save you.

It is not necessarily so obvious to a beginner when you are doing tail call
recursion.

Maybe overuse of typeclasses when records work better?

Over use of Template Haskell can raise an eyebrow.

A minority of extensions are ill advised.

All in all, I think the level of footguns in Haskell is in a different
universe than C++, but I am trying to see it from the other perspective.

[http://dev.stephendiehl.com/hask/#what-to-
avoid](http://dev.stephendiehl.com/hask/#what-to-avoid)
[http://dev.stephendiehl.com/hask/#the-
dangerous](http://dev.stephendiehl.com/hask/#the-dangerous)

~~~
tome
Thanks and agreed!

However, I was more asking for HelloNurse's opinion, since I can't think of
any Python footguns that are on the same level as C++'s. The ones you cite are
more on the level of Python's.

~~~
HelloNurse
A nice article from slightly over 1 year ago [https://lexi-
lambda.github.io/blog/2018/02/10/an-opinionated...](https://lexi-
lambda.github.io/blog/2018/02/10/an-opinionated-guide-to-haskell-in-2018/) was
linked on HN today.

It explains organized _footgun management_ , with a discussion of what
language extension should and should not be enabled, and some specific library
threats (e.g. String and ByteString).

~~~
philzook
That is an excellent article. String vs ByteString is a beginner footgun in
Haskell. It won't make incorrect or crashing code, but it will show up as poor
performance on text heavy processing.

------
PopeDotNinja
Does the Haskell compiler spit out useful concise, meaningful error messages?
Compilers often have some pretty verbose output for what ended up being a
(relatively insignificant feeling) typo.

~~~
philzook
It depends. After having gotten used to it, I can usually barely glance at an
error and figure it out. I am basically satisfied with ghc errors messages,
although they could be better. Sometimes it takes real head scratching. I
think languages like Haskell give the compiler enough information to make
insanely good error messages (At compile time mind you! Unlike
python/javascript/etc). Elm apparently has some of the greatest error messages
in the world. I think it is significantly better than C++ errors.

------
dudul
"functional programming is weirder than imperative programming."

Honestly, it's hard for me to take seriously any post/comment including this.

------
adamnemecek
I think that julia is giving haskell a run for its money. I find it more
productive for numerical mathematics (maybe not formal methods or abstract
algebra).

~~~
philzook
I agree on the promise (perhaps already realized) of Julia. The library
ecosystem there is so, so incredible. The language is custom formed to it's
intended domain of numerical computation. I've been trying to ween myself off
of python for these purposes. Needless to say, my pushing of Julia also meets
with a great deal of pushback. I have also had some setbacks. The 1.0 changes
hurt my learning a bit. I don't like how it doesn't play well with brew. I
feel like it is forcing me a bit into a Jupyter notebook style, which is not
my favorite. All of these are small quibbles ultimately.

~~~
adamnemecek
Use juno. I was in the same sitch re 1.0 update, it's gotten better. Why do
you need brew interop?

~~~
philzook
A small quibble. I hate downloading binaries from websites. I hate ever going
outside my package manager. I want to be able to get the latest version. I
think many people prefer Julia the way it is.

~~~
adamnemecek
You can use brew
[https://julialang.org/downloads/platform.html](https://julialang.org/downloads/platform.html)

~~~
philzook
Welp, my apologies. I'm a doof.

------
thrower123
haha. Hahahahaha. hahahahahahahahahaha. Okay bub, here's your troll card, you
are officially a member.

~~~
dang
Posting like this will get you banned here. Will you please review
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)
and stick to the rules?

