
State of the Haskell ecosystem - boothead
https://github.com/Gabriel439/post-rfc/blob/master/sotu.md
======
tel
For ML and Data Science I'd say very immature. HLearn does interesting things
but is far from providing a workable ML or Data Science workflow. We need
solid, unquestionable Matrix and Vector libs upon which the ~50 bread and
butter algorithms cans be solidly implemented. Then Diagrams needs super tight
integration and connections to "big data" systems can be built. Frames is
moving in the right direction type-wise but it'd be really nice to get HLists
(or even vinyl?) in as representations which can be transparently backed by
the aforementioned common matrix libs. Lenses could probably help a lot here
and I think Anthony is going in that direction exactly.

Neatly, the GPU story is actually quite strong and could be integrated with
this hypothetical ML and Data Science platform I'm describing quite nicely.
That'd be a not small boost to its power.

~~~
jordigh
What's the difference between ML and data science? ML has more programming?

And what's the difference between data science and statistics? Statisticians
try to come up with new mathematics, while data scientists just try to come up
with ways to apply that maths?

~~~
tel
I'll take a brief stab since I think there are important differences but this
is also holy war territory so YMMV.

ML tends to be more concerned with scale and computational efficiency as the
algorithms used are often (a) heavyweight and (b) less human interpretable.
Success is primarily measured objectively but via proxy measures like
prediction accuracy. It may require data science efforts behind the scenes in
order to succeed.

Data Science tends to be more concerned with interpretation than scale or
repetition. It sits somewhere between analyst, sataistician, and journalist.
It's also a much more interactive workflow often involving a great deal or
successive, simple models and lots of exploratory visualization. Measures of
success include discovery of human-relatable inferences from data,
substantiation or dismissal of human-relevant experimental hypotheses, and
success in communication of those ideas.

Statistics is a field of study of some of the most important mathematical
foundations of each of these roles. A statisicians skill is more generalized
but also more abstract. A statistician who learns CS and journalism could
easily head into either other field.

------
paulajohnson
Thanks for this. A couple of points:

1: I'd have rated Haskell's concurrency as "best in class" thanks to its STM
implementation. Other languages do have STM, but AFIAK only Haskell provides
both efficiency and safety thanks to its type system. Other languages have to
choose between tracking every variable (slow) and letting the programmer
declare which values are going to be rewound if the transaction aborts
(unsafe).

2: Your section on IDEs does not consider Leksah. I've just come back to this
after a long time on Eclipse and Atom, and its now a mature IDE specialized
for Haskell. You might consider bumping Haskell to "mature" based on this.

~~~
cies
I agree on concurrency. It is best in class and also offers a lot of choice
(which some other popular languages like JS and Go are not providing).

When it comes to IDEs I do think immature would also be my choice. There is a
lot of movement on this front so I have hopes this may change soon. My main
points are: 7.10 is out for a while but most editor integrations have/had
(until recently) some major issues with it. Also Stack is bocoming quite
popular, yet most editor integrations are not Stack-aware. Finally the editor
integrations are not much plug-and-play. As said, this is changing rapidly
with some necessary fixes to GHC/cabal made and projects like stack-ide and
ghci-ng.

~~~
hamishmack
> When it comes to IDEs I do think immature would also be my choice.

If you have not already logged any issues, can you please list the top few
things that bugged you about Leksah here and I will make sure they get added
to the issue tracker? Even if they are already there it will help us
prioritise to know what your pain points were.

Thanks

------
QuantumRoar
For me, it was (and still is) terribly hard to find libraries that do what I
want. Although Hackage has a large database, it's quite confusing and very
hard to figure out how a library actually works.

A few years ago, I tried to parse HTML files for a very small thing that I
wanted to do and I just couldn't find or understand whether there's actually
something out there that I could use. So, instead, I ended up learning Parsec
and writing my own crappy parser...

I really don't think that's what it should be like. And maybe it's just my own
fault. If not, there should be thousands out there who start their Haskell
journey with such a frustrating experience. There's a deep and dark abyss in
which beginners fall after an initial tutorial.

I've never had a similar experience with any other language. The upside, of
course, is that Haskell is the most beautiful language I know.

~~~
boothead
I think this is because the abstractions are so abstract. When functionality
is glued together with very general combinators and operators there's not
really much to grab hold of unless you understand the abstractions.

~~~
QuantumRoar
Well said. What always saved me is that brave and devoted individuals wrote
tutorials and published them to help me peel away the layers of abstractions.
There's no way I could have done that on my own.

~~~
boothead
Which is why I view haskell's community as one of its main, less tangible
qualities. :-)

 _edit_ clarity - Apparently my brain is too Haskelled today for writing
English

------
progman
One point is missing: the state of debugging.

Current state:
[https://wiki.haskell.org/Debugging](https://wiki.haskell.org/Debugging)

For comparison (F# and Ocaml):

    
    
      https://msdn.microsoft.com/en-us/library/ee241127.aspx
      http://oqamldebug.forge.ocamlcore.org/

------
radmuzom
This is a great and a balanced list. I have definitely enjoyed some time spent
programming in Haskell.

One frustration that I have had while dabbling in Haskell is that some
libraries in Hackage assume a GNU/Linux kind of system. For example, I was
reading Simon Marlow's book and while trying to compile the examples in a
Windows machine, a particular library could not be installed because of the
lack of 'configure' (GNU autotools? I only use Windows nowadays due to
professional reasons and have not used GNU/Linux last 11 years). I hope that
library authors do not make such assumptions unless it really necessary.

Is there an opportunity for a company to create an implementation of Haskell
which fixes some commonly mentioned problems (e.g. stop the world GC) - like
proprietary JVM vendors? Is it even technically feasible? Of course, such a
hypothetical company would also need to spend a lot of time writing useful
libraries.

~~~
kryptiskt
I'm a Haskell Windows user (and an Idris developer), and I have little trouble
installing most things (except those directly targeted at Linux). That's not
because I'm awesome, but because there's a trick to it. The trick is to
install msys2 ([https://msys2.github.io](https://msys2.github.io)), and do the
installs from there. Set up its libs and include as extra dirs in Cabal's
config. When you need some lib or build tool look for it with pacman -Ss and
install it. To start with installing make and autoconf helps you over the
configure hurdle.

And if you hit Cabal hell now and then, that happens to everybody so it's
probably not because you're on Windows, just make a sandbox and see if it
works there.

~~~
kryptiskt
My Idris installation instructions: [https://github.com/idris-lang/Idris-
dev/wiki/Idris-on-Window...](https://github.com/idris-lang/Idris-
dev/wiki/Idris-on-Windows)

It's an example of pulling down build tools and libs (well, a lib) with msys2.

------
protomyth
Although hinted at in "Mobile apps" and "Package management", I think you
might want to add "Deployment" to your list of criteria for a language. It is
often overlooked with languages and frameworks, but the ability and method of
deploying code (particularly with a running system) should not be ignored.

------
sklogic
> Haskell is an amazing language for writing your own compiler. If you are
> writing a compiler in another language you should genuinely consider
> switching.

Uhm, no, thank you, but no. Haskell is poorly equipped for implementing
compilers, because of its lack of unrestricted compile-time metaprogramming.

I'm spoiled. This is what I want from a language for implementing compilers:

1) Cheap, boilerplate-free definition for chains of slightly different ASTs
and IRs. Haskell and ML are notoriously weak in this area (see the "Expression
Problem" thing)

2) Boilerplate-free generation of various (potentially complex) visitors for
these ASTs and IRs. For Haskell, Scrap Your Boilerplate library is the closest
thing to what I want, but it is still far too clumsy.

3) I need _efficient_ embedded Prolog and Datalog (yes, both, the latter
allows some cool optimisations not possible for the former). Not feasible
without compile-time metaprogramming. Both are important for simplifying
compiler construction.

4) Parsing is not very important. But yet, it is necessary. The best Haskell
got on offer is Parsec. Sorry, not good enough for my requirements.

~~~
coldtea
So "Haskell is poorly equipped for implementing compilers" because it doesn't
fit your bizarro requirements, including "efficient embedded Prolog and
Datalog"...

~~~
sklogic
Haskell is poorly equipped for implementing compilers because writing
compilers in Haskell requires tons of boilerplate, which is not needed in the
languages that are a much better fit for this task. Kinda obvious from a
definition of what "poorly equipped" means.

And why do you call these basic requirements bizarre? For example, something
like a region inference is just a few lines of Prolog vs. dozens or even
hundreds of lines of code in Haskell.

~~~
coldtea
> _Haskell is poorly equipped for implementing compilers because writing
> compilers in Haskell requires tons of boilerplate, which is not needed in
> the languages that are a much better fit for this task._

And yet your "much better languages" are even more niche compared to Haskell,
and no major programming language has been written in them.

So, it's basically "Haskell is poorly equipment compared to my impossible
standards, as implemented by this hodge-podge of Scheme based tools that I
alone ever used together for compiler implementation".

> _And why do you call these basic requirements bizarre? For example,
> something like a region inference is just a few lines of Prolog vs. dozens
> or even hundreds of lines of code in Haskell._

Because no known programming language resorts to "a few lines of Prolog" to
save a few tens of lines for "region inference"?

~~~
sklogic
> are even more niche

Exactly. Compilers construction is a very specific problem domain, which
requires specially tailored DSLs, not a "general purpose" language. Haskell is
a way too general purpose for this task.

> and no major programming language has been written in them.

C is even more unsuitable for this than Haskell, and yet most of the compilers
are written in C. Technical superiority does not count at all in choosing an
implementation platform.

> Because no known programming language resorts to "a few lines of Prolog" to
> save a few tens of lines for "region inference"?

JFYI, a prototype implementation of SSA for GCC was written in Prolog (see the
Sebastian Pop works [1]). If embedding Prolog in C was technically feasible,
it would have stayed this way. Also, to see how much Prolog rocks, check out
Harlan [2]

In order to avoid unnecessary flame war: I give no crap to any popularity
based arguments. Got any _technical_ , well-grounded, rational arguments? Go
on, I'd be delighted to comment. Otherwise I'm not interested. And, btw.,
you're clutching to just one out of four of my points against Haskell. Nothing
to say about the other three?

[1]
[http://www.cri.ensmp.fr/classement/doc/A-381.pdf](http://www.cri.ensmp.fr/classement/doc/A-381.pdf)

[2] [https://github.com/eholk/harlan](https://github.com/eholk/harlan)

~~~
coldtea
> _C is even more unsuitable for this than Haskell, and yet most of the
> compilers are written in C. Technical superiority does not count at all in
> choosing an implementation platform._

Or maybe technical superiority is a more varied thing than what you consider
(merely a language's features and "expression" capabilities), and includes
tooling, portability, speed, direct access to hardware, existing codebase to
work upon and lots of other parameters, for which C was king or very near the
top for many decades...

> _In order to avoid unnecessary flame war: I give no crap to any popularity
> based arguments._

And from my side: I don't give a crap for "technical arguments" that focus
only on a very narrow area of technical benefits ignoring lots of others.

Even "familiarity of the team with a language" is a technical argument (in the
sense that it speaks to the capability of a teams to practically use
something).

I also don't think that "popularity" is just fluff. It might not be a 100%
solid proof, but it does point to real, battle proven, results (as oposed to
vapour-ware and hand-waving about superiority).

In the end, history and actual results are the only criteria. That's being
pragmatic and empiricist -- as opposed to mere beliefs that don't pan out in
practice.

~~~
sklogic
The features I am talking about are very platform-agnostic. The only
requirement for implementing them is a compile-time metaprogramming, which is
trivial to add to any language, including C.

The only explanation for not using this approach is a plain ignorance.
Majority of people have no understanding of compilers at all. And yet they are
writing compilers. In C or Haskell.

And, btw., teams that cannot learn a tiny DSL in an hour (or write this DSL in
a week) should not be allowed to write compilers. It's kinda obvious.

~~~
coldtea
> _The only explanation for not using this approach is a plain ignorance.
> Majority of people have no understanding of compilers at all. And yet they
> are writing compilers. In C or Haskell._

That includes people like Lars Bak, Martin Odersky, Anders Hejlsberg, Simon
Peyton Jones, etc? I wonder where the burden of proof should be placed in
these kind of arrogant arguments -- as if "compile-time metaprogramming" is
some magic bullet for compiler design...

~~~
sklogic
I am glad you did not list anyone related to GCC and LLVM, because both rely
on the static DSLs (and code generation) heavily.

As for the rest - yes, compiler construction is not their main research topic.
They can all be great language designers, but their approach to compiler
construction is needlessly overcomplicated.

A view of a compiler as a chain of stupidly trivial passes, ideally expressed
as term rewriting, is not very common among the researchers, but so far it
yields the best results.

~~~
coldtea
> _They can all be great language designers, but their approach to compiler
> construction is needlessly overcomplicated._

Actually Lars Bark and team are not "language designers". Smalltalk
(Strongtalk), Java (Hotspot), Javascript (V8), all have been designed as
languages by other people.

They are world reknowed experts in compiler design.

~~~
sklogic
JIT is a totally different beast from a simple pipeline compiler. You should
have known better. Anyway, you evidently do not know what you're talking
about. Consider you trolling unless you can show _your_ compiler code.

------
reflexer
I think the rating difference between sections "application domains" and
"common programming" illustrates clearly what is known as "academia language",
i.e. advanced, mature features and lack of real application stories and
libraries.

------
the-owlery
I've avoided Haskell, primarily because:

* hearing how difficult it is to learn, and

* recalling C++ & Java, not crazy about the idea of going back to having to specify types for everything.

But Haskell is enticing to me:

* bindings to C-libraries in general (been meaning to try GTK, and wanted to use SQLite for a small project)

* apps start-up quickly

* compiled (good performance)

What's the Haskell community like?

Is Haskell a practical language/ecosystem, or more academic-focused?

~~~
digitalzombie
> * hearing how difficult it is to learn, and

I thought it was pretty straight forward coming from Erlang.

The biggest thing for me was practice thinking in recursion.

edit: Erlang and Haskell was just side hobby. I didn't do anything major with
them. But I thought the languages were small enough, Haskell has such a clean
looking syntax.

Oh, I think you're trying to say the threshold of being good with haskell is
much higher? Cause I see that argument quite and bit.

~~~
the-owlery
> > * hearing how difficult it is to learn, and

> I thought it was pretty straight forward coming from Erlang.

> The biggest thing for me was practice thinking in recursion.

I use Clojure, generally like functional programming, and am fine using
recursion.

> Haskell has such a clean looking syntax.

I have gotten fond of Clojure's Lisp-like syntax.

> Oh, I think you're trying to say the threshold of being good with haskell is
> much higher? Cause I see that argument quite and bit.

Not sure -- haven't spent any time with Haskell. Never tried Erlang either. Do
you think it generally takes longer to become productive with Haskell than
with other functional programming languages?

------
airza
Trying to get a Haskell application deployed to the web was an exercise in
frustration. Somehow my resolution for its important package management and
binaries has become profoundly fucked up as well.

~~~
dukerutledge
Really? Deployment has always been a breeze for me. Build on a vm, scp the
binary up to my server, profit.

