Slow installation and lack of backward compatibility


I am having two problems with Haskell, both related to the installation of large programs. I guess that Haskell has two popular installation tools, stack and cabal. Both tools take a very long time to install, require a lot of help from the user and often end in failure, which leads me to the second problem:

It seems that Haskell developers don’t pay much attention to backward compatibility. If somebody has developed a large application through a past release of GHC, one can bet that it won’t compile with the present tool chain. I came to Haskell due to three programs, those being pandoc, the text editor yi and JHC. I will talk about my experience with these three applications.

I never had problems with installing pandoc. Besides this, the person who is developing this very useful and interesting tool started a binary distribution, which works like a breeze. So let’s take pandoc out of the discussion.

I would like to have an Emacs like editor that I could script in a language other than Emacs Lisp (elisp). I found three, which are lem (scripts in Common Lisp), remacs (scripts in Rust) and, of course, yi (scripts in Haskell). Common Lisp has two installation tools, roswell and quicklisp. These tools are very fast (a few seconds for a large package), with a very low failure rate. Therefore, I was able to install lem in a very short time. Common Lisp has many interesting packages. For example, when I decided to play planet discover, I found a Fortran-2-Lisp translator that put all vintage astronomy software into Lisp. Other programs in Common Lisp: Maxima Computer Algebra, lem text editor, ACL2 theorem prover, Cyc, PTC CAD/CAM, SKILL VLSI CAD, etc. As for Haskell, when I installed yi a couple of years ago, the installation was uneventful, in Macintosh, Windows and Linux. However, when I tried to install it with cabal two weeks ago, the process took a very long time, and ended in failure. I switched to stack, and it also ended in failure. I wrote to a stack discussion group, where Snoyman told me to use an older version of ghc, which I did, but stack could not install yi with the old compiler either.

When I came across JHC a few years ago, I thought it was interesting because it could cross compile to the iPhone. The history of the yi editor repeated itself in the case of JHC. I wonder whether the Haskell community knows of or could find a way of preventing Haskell software from becoming obsolete, as well as faster and easier to install. I imagine two ways of achieving these goals: (1) Backward compatibility; (2) An unchanged nucleus to which extensions and improvements to the language could be translated automatically, something easy to use, like Lisp macros and read-tables.


As a contributer to Yi, I can tell you that it is currently no longer maintained. So I wouldn’t put the blame on Haskell. In the time that Yi has been unmaintained, there have been some breaking changes, but those are pretty easy to resolve. Development on JHC has, according to their changelog, stopped 7 years ago.

Software just gets old. I think we should not try to have total backwards compatibility otherwise we will either end up with extremely bloated syntax or a slowdown of interesting new developments.

As for why Yi failed, Yi has some truly arcane parts, for example the built-in parser combinators: Yi has some weird performance issues, I tracked down a space leak that maybe is solved now:, but I’m not sure if that is the only problem and my solution was mostly random guessing (I was not an expert at debugging Haskell then).

Finally (and I think most importantly), there is the fact that GHC is just a very heavyweight compiler and takes a long time to compile, but the compiled code is very fast. That makes it very good for performance critical code and the type system gives some pretty good guarantees about correctness, but as you mention in this post it is not ideal for a scripting language. Maybe someone should write an implementation of a subset of Haskell that runs in an interpreter that is “good enough”. Ideally it should be possible to write performance critical part in a static core application and then allow extensions written in a scripting language.