
Haskell Problems for a New Decade - psibi
http://www.stephendiehl.com/posts/decade.html
======
siraben

      Most undergraduates take a compiler course in which they implement
      C, Java or Scheme. I have yet to see a course at any university,
      however, in which Haskell is used as the project language. [...] The
      closest project I’ve seen to this is a minimal Haskell dialect
      called duet.
    
    

Ben Lynn has been working on such a Haskell compiler[0], self-hosting and with
IO too. It's a little unusual in its approach to compilation (targets
combinatory logic and executes via graph reduction), but it's a great example
nonetheless, from which one could build an undergraduate course.

Code generation is a difficult issue, compiling a lazy functional language to
assembly could easily fill up two semesters of classes alone.

The VM in C is really small and the compiler can be built up incrementally[1].

[0] [https://github.com/blynn/compiler](https://github.com/blynn/compiler)

[1]
[https://crypto.stanford.edu/~blynn/compiler/quest.html](https://crypto.stanford.edu/~blynn/compiler/quest.html)

~~~
omaranto
> Most undergraduates take a compiler course in which they implement C, Java
> or Scheme.

Is that true? I thought those compiler courses typically implemented some toy
language.

Maybe "in" is misplaced and the following was meant instead?

"Most undergraduates take a compiler course which they implement in C, Java or
Scheme."

~~~
leetcrew
I think you're essentially right, but the "toy language" is often a subset of
some real language. in my compilers course it was a subset of pascal, which
targeted a very friendly IR. there's no inherent reason why the same couldn't
be done for a subset of C, Java, or Scheme. in particular, Scheme has a
relatively simple syntax to parse. C is fairly difficult to parse, not sure to
what degree the grammar can be simplified by removing features.

------
pron
This post highlights my biggest problem with the language: it's about the
_how_ , not about the _why_. For example, dependent types. They add
significant complexity to the language and are intended to help with
correctness. But are they an effective way to achieve it compared to
alternatives? The fact that even current formal verification _research_ is
mostly looking elsewhere seems to suggest that the answer is likely negative,
so why focus on them now? Or algebraic effects, about which the article says,
"These effect-system libraries may help to achieve a boilerplate-free nirvana
of tracking algebraic effects at much more granular levels." But is that even
a worthwhile goal? Why is it nirvana to more easily do something that might
not be worth doing at all?

Researchers who study some technique X ask themselves how best to use X to do
Y, and publish a series of papers on the subject, but practitioners don't care
about the answer to that question because they don't care about that question
at all. They want to know how best to do Y, period. One could say that every
language, once designed, is committed to some techniques that it tries to
employ in full effect. But any product made for practical use should at least
strive to begin with the _why_ rather than the how, both in its original
design and throughout its evolution. I work with designers of a popular
programming language, and I see them spending literally years first trying to
answer the why or the what before getting to the how. So either Haskell is a
language intended as a research tool for those studying some particular
techniques -- which is a _very_ worthy goal but not one that helps me achieve
mine -- or it's intended to provide entertainment for practitioners who are
particularly drawn to its style. Either way, it's not a language that's
designed to solve a problem for practitioners (and if it is, it doesn't seem
that testing whether it actually does so successfully is a priority).

I think it's important to have languages for language research, but if that's
what they are, don't try to present them as something else. And BTW, at ~0.06%
of US market share -- less than Clojure, Elixir, Rust and Fortran, about the
same as Erlang and Delphi, and slightly more than Lisp, F# and Elm -- and
little or no growth ([https://www.hiringlab.org/2019/11/19/todays-top-tech-
skills/](https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/)), I
wouldn't call Haskell a "popular language," as this post does, just yet.

~~~
pjmlp
Which is why although I see these kind of languages quite relevant to advance
the state of the art, the industry belongs to impure multi-paradigm languages.

Like Brian Goetz puts it, it is not FP vs OOP, rather combining FP and OOP,
using the best of each to solve different kinds of problems with the same
tool.

~~~
hopia
I'm not so sure a multi-paradigm language is truly the ideal alternative.
Languages that brag being multi-paradigm, such as Python or Javascript, in the
end offer very few facilities for actual functional programming. It just
doesn't feel idiomatic with them.

FP and OOP are both well tested design patterns. Mixing them up in an
incoherent way just makes the whole software architecture somewhat
unpredictable.

~~~
mumblemumble
One could perhaps draw a distinction between languages that were designed from
the ground up as multiparadigm, such as OCaml, and languages that originally
targeted one paradigm and then became multiparadigm by katamari-ing up a bunch
of extra features, as Python did.

FWIW, I also don't know that Python officially conceives of itself as
multiparadigm so much as as a procedural language with classes. Kids these
days forget that higher-order programming has a long history in procedural
programming, too. ALGOL was doing it in the 1960s, after lisp but a good
decade before Backus published _Can Programming Be Liberated from the von
Neumann Style?_.

~~~
TheAsprngHacker
For what it's worth, despite the O in OCaml, in practice the object layer
isn't used that often. However, that's because the ML module system serves
many of the same use cases that objects and classes do in other languages.
People do use objects in OCaml occasionally if they need the dynamic dispatch.

I'd say that OCaml blends imperative and functional programming cohesively and
fairly equally, though.

------
mlthoughts2018
> “ Many of the large tech companies are investing in alternative languages
> such as Swift and Julia in order to build the next iterations of these
> libraries because of the hard limitations of CPython.”

I would be interested in evidence of this. I work at a big tech company in ML
and scientific computing, and have close peers and friends in similar
leadership roles of this tech in other big companies, FAANG, finance, biotech,
large cloud providers, etc.

I am only hearing about the adoption of CPython skyrocketing and continued
investment in tools like numba, llvm-lite and Cython. At none of these
companies have I heard any interest in Julia, Swift or Rust development for
these use cases, and have heard many, many arguments for why Python wins the
trade-offs discussion against those options.

In fact, two places I used to work for (one a heavy Haskell shop and one a
heavy Scala shop) are moving away from those languages and _to_ Python, for
all kinds of reasons related to fundamental limitations of static typing and
enforced (rather than provisioned) safety.

I mean, Haskell & Scala are great languages and so are Julia & Swift. But even
though in some esoteric corners people have started to disprefer Python, it’s
super unrealistic to suggest there’s large movement away from it. Rather
there’s a large move _to_ it.

It reminds me of the Alex Martelli quote from Python Interviews,

> “Eventually we bought that little start-up and we found out how 20
> developers ran circles around our hundreds of great developers. The solution
> was very simple! Those 20 guys were using Python. We were using C++. So that
> was YouTube and still is.”

~~~
logicchains
I work in HFT and now use Julia for all my research, and a couple of my
colleagues now do too. Personally I'd rather retire and farm goats than go
back to having to write Python professionally: there's just soo much that can
go wrong that doesn't happen in a typed language, so much unnecessary stuff
you have to keep in your head when coding. It also seems incredibly
counterproductive to use a language that's 100x slower than necessary just
because it's the only language some people know; the difference in research
speed between having to wait one second for a result and ten minutes is
massive.

Of course, HFT is a somewhat different usecase than pure ML, as we work with
data in a format that's rarely seen elsewhere (high-frequency orderbook tick
data). Python's probably less painful for working with data for which somebody
else has already written a C/C++ library with a nice API, as then you don't
need to write your own C/C++ library and interface with it. My choice is
either: write Python, and the research will take 100x longer, write Python and
C++, and the development will take 2-4 times longer, or write Julia, and get
similar performance to C++ with even faster development time than Python.

~~~
twic
Is it just performance that puts you off Python? If so, did you try writing a
native extension to accelerate it?

Where i work, we also have analysis work which involves sequentially reading
gigabytes of binary data. We came up with a workflow where a tool written in
Java runs a daily job to parse the raw data and write a simplified, fixed-
width binary version of it, then we have a small Python C extension which can
read that format. We can push a bit of filtering down into the C as well.

This has worked out pretty well! We get to write all the tricky parsing in a
fast, typesafe language, we get to write the ever-changing analytics scripts
in Python, and we only had to write a small amount of C, which is mostly I/O
and VM API glue.

The Java and C parts were both written by an intern in a month or two. He's a
sharp guy, admittedly, but if an intern can do it, i bet an HFT developer
could too.

~~~
logicchains
>Is it just performance that puts you off Python? If so, did you try writing a
native extension to accelerate it?

This is what I did originally, but it was way slower to have to write and
maintain C++ and a Python interface for it than to just write Julia.
Particularly because the some of the business/trading logic basically has to
be in the native layer (can't backtest a HFT algo without running it on HFT
data, and that volume of high frequency tick data is too slow to process in
pure Python).

------
anentropic
> If you look at the top 100 packages on Hackage, around a third of them have
> proper documentation showing the simple use cases for the library.

This is still very very poor, and one of the biggest problems faced by
newcomers to the language (speaking as one myself...)

~~~
platz
Which library in the top 100 that you used had documentation (or lack thereof)
that wasn't sufficient to understand how to accomplish the task at hand?

~~~
weavie
Some of the libraries need you to click into the docs for specific modules to
get the full documentation for them. This confused me when I first set out.

eg. Postgres Simple. This is the page you get to at first when you search for
it:

[https://www.stackage.org/lts-14.21/package/postgresql-
simple...](https://www.stackage.org/lts-14.21/package/postgresql-simple-0.6.2)

It looks like there is no documentation, just a list of modules.

Clicking on the Database.PostgreSQL.Simple module gets you to the docs:

[https://www.stackage.org/haddock/lts-14.21/postgresql-
simple...](https://www.stackage.org/haddock/lts-14.21/postgresql-
simple-0.6.2/Database-PostgreSQL-Simple.html)

~~~
whateveracct
This is pretty standard practice. The landing page for a package is never
where examples live (except for the README). Haddocks are used for examples &
tutorials, and the top-level module or a documentation-only module ending in
".Tutorial" are often provided.

~~~
weavie
Sure. It just took a bit of getting used to, but could be the reason why a lot
of casual developers looking at the language have the impression that the
documentation is poor.

~~~
whateveracct
That's fair I guess but if someone just looks at a single landing page and
draws a conclusion without even clicking around idk what to say

------
eli_gottlieb
I'm going to give the same Haskell hot-take I gave on Twitter while at NeurIPS
in December: the problem with Haskell is that you can port the awesome parts
of pure, compositional abstractions over to Python, far more quickly than you
can port really good domain-specific libraries and applications over to
Haskell. My experience was that porting some nice ADT-based machinery to
Python, using an available ADT library, took roughly one weekend, whereas
porting the major domain-specific package I needed from Python to Haskell
would take months to years.

I love Haskell. I prefer to use Haskell when I can. Haskell is a language in
which I can Achieve Enlightenment. But apparently, God help me if I need to do
some heavy graph processing or CUDA numerics in Haskell.

~~~
ashilfarahmand
So, uh, I was looking through past threads (this one in particular
[https://news.ycombinator.com/item?id=21578769](https://news.ycombinator.com/item?id=21578769))
and I came across your comment:

"I might be spat at or beaten up in the street for being Jewish - that happens
in Brooklyn or LA anyway these days."

And I was wondering, how has it been for Jews in the US in the past few years
up till now? When did things start to get noticeably worse?

I know about the rising Anti-Semitism and the particular incident in NY about
a month ago.

~~~
eli_gottlieb
If you want to talk about that, you should contact me privately. I don't want
to derail a nice thread.

~~~
ashilfarahmand
I'm totally fine doing that but I don't know how. Can we private message?

~~~
eli_gottlieb
My profile on here links to my Github Pages site, which has an email address
on it.

------
mark_l_watson
Great forward thinking wish list!

I have a strange relationship with Haskell. I love Haskell repl driven
development of pure code for playing with algorithms and ideas. I use Haskell
in this use case much like I use Common Lisp and Scheme languages. However, I
am not very good at writing impure code and the interfaces between pure and
impure code. To put it more plainly, I enjoy the language and I am productive,
but I suffer sometimes figuring out other people’s Haskell code.

------
socialdemocrat
Despite the positive tone, what really struck me in this article was that they
struggle with getting people to work on the compiler because it is too
complex.

It just confirms my main criticism against advance statically typed languages:
They are simply too complex.

It is why I have more faith in languages like Julia, because you can achieve a
tremendous amounts of power, expressiveness and performance in a relatively
simple language.

Dynamic typing gives you simplicity in the type system which is impossible to
achieve with static type checking.

Long term this has profound implications. People can keep hacking on and
expanding Julia because they can wrap their head around the language. You
don't need to be Einstein to grok it.

I think you may also see Clojure overtake Scala for the same reason. The
simplicity of Clojure may in the long run overtake Scala although Scala
benefits a lot from similarity to Java at a superficial level.

~~~
Random_ernest
> I think you may also see Clojure overtake Scala for the same reason. The
> simplicity of Clojure may in the long run overtake Scala although Scala
> benefits a lot from similarity to Java at a superficial level.

Correct me if I'm wrong, but didn't Scala overtake Clojure some years ago as
the second most popular language on the JVM (second to Java ofc). From my
point of view it rarely happens that these trends reverse.

Scala has the advantage that it allows OOP or Functional Programming, which
Clojure does not.

But I do get your point about simplicity. I tried 3 times to learn functional
programming by learning Haskell and it never clicked. Then I learned Clojure
and who would have thought, functional programming is actually not as hard as
Haskell makes it out to be.

~~~
EdwardDiego
I work in a JVM shop and I don't see Clojure making much head way. Unlike say,
Apache Spark, there's no killer app (datomic notwithstanding) that requires
Clojure over Scala.

Scala also offer the advantage of static type checking, and a less alien
syntax. Yeah, I know Clojure is just s-expressions, but all the brackets don't
help its uptake.

Oh, and Clojure stack traces make Scala stack traces look positively brief and
informative.

~~~
lonelappde
Scala's syntax for (generic) type declarations is super alien, and you can't
avoid it because it's a big part of why you'd use Scala in the first place.

------
coolplants
Big issue with Haskell adoption is the number of hoops you have to jump
through to write efficient code in it. Haskell abstracts away the idea of a
procedural VM implementing the code underneath, but you often need that
exposed to finagle your code into a form that’s efficient.

Haskell programming ethos is opposed to that, the language wants people to
focus on the semantics of computation not the method. Yet we must be able to
specify computation method if we want our programs to operate efficiently.

The truth is that the Haskell compiler will never be able to automatically
translate idiomatic Haskell code into something that’s competitive with C in
the common case. once you start finagling your haskell code to compete with C
you’ve negated the point of using Haskell to begin with.

~~~
the_af
> _The truth is that the Haskell compiler will never be able to automatically
> translate idiomatic Haskell code into something that’s competitive with C in
> the common case._

Is this something you have experience with, or are you just theorizing? I know
there are pitfalls to Haskell development, but to assert that "the common
case" has uncompetitive performance seems wrong to me.

My problem with this kind of assertions is that often -- not saying it's your
case, that's why I'm asking -- they come from people who _imagine_ how it must
be (or read it in a blog), often coming from a place of never really having
tried to solve something with the language, and this sadly percolates into
popular wisdom ("Haskell is not good for this or that"). Something similar
happened to Java's allegedly "poor" performance, way past the point Java
software sometimes outperformed C in many areas.

~~~
jerf
I think it's a common problem with almost all, if not all, languages that come
to us out of the 1990s that they are fundamentally built on the presumption
that "someday" compilers may save us. Well, "someday" is pretty much here, and
they've all failed, as far as I'm concerned. (If you're happy with 10x-slower-
than-C and substantial memory eaten to get even that fast, YMMV, but it's not
what was hoped for. No sarcasm on that, BTW; sometimes that's suitable, just
like sometimes 50x-slower-than-C is suitable. But it's not what was hoped
for.)

Haskell can do some pretty tricks with specific code if you tickle it right,
but if you just write general, normal code, it's faster than Python (a low
bar, Python _qua_ Python is nearly the slowest language in anything like
common use) but not a generally "fast" language. "Someday" is here; if it's
not "generally C-fast" today, I see no particular reason to believe it will be
in the future either, especially since GHC seems to have spent a great deal of
its design budget.

It would be interesting to see someone's take on Haskell, but where they write
the language from the very beginning to be a high-performance language.
There's probably multiple points in this design space that would be possible.
Arguably Rust is nearly one of them, and getting even closer in the next few
years.

~~~
tjalfi
You might be interested in Cliff Click’s aa[0].

It’s still under development but intended to be a high performance functional
language.

The author has substantial experience in JITs and compilers.

[0] [https://github.com/cliffclick/aa](https://github.com/cliffclick/aa)

------
thrower123
Haskell's main problem is that it is over-zealous, and built on axioms that
make it a poor fit for real people writing real code. Everything else flows
from that core issue. Functional purity and lazy evaluation are interesting,
but when you can't toss a printf debug or log statement into a function
without changing function signatures all the way up, it's not going to be
popular.

Pragmatic, sloppy languages will always be more popular, because they are more
forgiving.

~~~
cosmic_quanta
To be fair, you can printf debug anywhere (Debug.Trace module). I'm the "print
to debug" kind of guy, and I can debug in Haskell just like in Python using
this.

I think the issue you have stems from the fact that people can't transfer the
knowledge from C/C++/Python/wtv _directly_. One of the standard way to build
programs in Haskell (mtl-style) allows you to perform IO actions almost
anywhere, provided you're willing to play with monads. But this is so
different from anything most people have ever seen that I understand why it
can be frustrating.

~~~
thrower123
Any idea when this was added? I am relatively certain that it was not possible
in Haskell 98, and admittedly most of my Haskell experience is a decade old.

I have picked up three well-regarded Haskell books over the past decade trying
to get back into the language, and don't recall any mention of this
capability.

That's another issue, the dearth of anything like tutorials or books on how to
do something practical with Haskell, rather than the whirlwind tour of
language features. I keep being told that serious software is being built in
Haskell, but the knowledge of how to get from university-grade code to
production-grade code is an unmarked wilderness that everyone must apparently
navigate on their own.

~~~
vilhelm_s
Looking back on historical GHC releases, the earliest one available on the web
page is version 0.29, released in July 1995, and it already has the trace
function. I would guess has been there for a long time.

