
Reflecting on Haskell in 2017 - setra
http://www.stephendiehl.com/posts/haskell_2018.html
======
harry8
I want to see the list of applications written in haskell that are useful and
not used for programming a computer.

This list has seemed shorter than one might expect in the past given the
interest among programmers in the haskell language (this includes my own
interest fwiw). A list of applications written in haskell that are used for
something that isn't programming a is a useful datapoint that tells us
something about the strengths and weaknesses of the language - we can argue
about the subtleties of the meaning of that data point but it is useful data.

I've got

    
    
      pandoc, 
      xmonad (window manager), 
      git annexe 
    

to get things started. Let's get them down.

~~~
maxhallinan
Not trolling here: what do you mean by "not used for programming a computer"?
I'm genuinely confused because I would think that all uses of a programming
language qualify as programming a computer. Do you mean applications of
Haskell to domains that are messier than compilers and other classic computer
science problems?

~~~
workthrowaway27
OP means applications that aren't used by developers for development related
tasks. I.e. someone who doesn't know how to program could use it.

~~~
maxhallinan
This is a strange distinction to make when evaluating a programming language.
I can understand an evaluation that begins like "I need a language that is
useful for solving x problem" or even "problem of x type". But if you're
trying to evaluate Haskell in general terms, a list of the Haskell apps
targeted at a non-technical audience is a dubious heuristic.

~~~
setr
I'm pretty sure what OP is considering is that Haskell is well known for its
usage in theory heavy works (where the domain is mostly well-specified, and
possibly even _beautifully_ so), but not well known for applications where you
have to make unspecified, awkward, temporary and sometimes nonsensical updates
(anything that so much as breathes near a _layman_ ). And given haskell's
background as a research language, it makes sense for it to be biased towards
the former. So the question is, by how much?

------
Tehnix
For people that have gotten into Haskell, but struggle to get over the
intermediate level, I would warmly recommend checking out
[https://www.fpcomplete.com/haskell-
syllabus](https://www.fpcomplete.com/haskell-syllabus). As for good tips, I've
come to like the ReaderT "design pattern"[0].

For newcomers, I would recommend the Haskell Book[1], which covers everything
quite extensively.

[0] [https://www.fpcomplete.com/blog/2017/06/readert-design-
patte...](https://www.fpcomplete.com/blog/2017/06/readert-design-pattern)

[1] [http://haskellbook.com](http://haskellbook.com)

------
MBCook
> Writing Haskell is almost trivial in practice. You just start with the magic
> fifty line {-# LANGUAGE ... #-} incantation to fast-forward to 2017, [...]

This was my biggest frustration with Haskell the last time I used it, I find
it sad that it doesn’t seem like they’re trying to fix it.

~~~
tathougies
You can set all the flags in your cabal file. How is this not a fix? This is
like specifying your compiler version.

We have a fairly hefty haskell code base at work, and we never use LANGUAGE
pragmas anywhere.

~~~
MBCook
As a Java programmer, I don’t have to have the equivalent of 75 LANGUAGE
pragmas to be able to use the features in Java 8 instead of what Java 1.1
shipped with.

It’s nice there’s a way not to put them at the top of every single file but
they still exist.

There must be some reasonable subset that basically everyone uses and should
just be included in the language.

~~~
donovanm
Getting everyone to come to a consensus on what should or shouldn't be
included would be very difficult. Then there's also the issue of backwards
compatibility. At the end of the day they're opt in so you can just simply not
use them.

~~~
bunderbunder
Optimizing individually for every individual has a tendency to de-optimize the
community as a whole.

This is one of those things that seriously limits Haskell's growth. It's
something for new users to bounce off of, and that contributes to Haskell's
reputation as a write-only language.

------
darkkindness
As a semi-recent initiate to Haskell, it's really helpful to see such an
accessible compilation of important Haskell developments. Although it's easy
to find Haskell material to read, it's not as obvious to highlight what's
important.

Cheers!

~~~
kreetx
For me the main value is getting the interestin publications. This is
subjective of course, but way better than a random selection :)

------
willtim
Haskell is definately one to watch for Blockchain. IOHK have released a
currency with their codebase largely in Haskell. Both IOHK and Digital Asset
have smart contract / modelling languages based on Haskell.

~~~
spopejoy
The author also mentions his company's release Uplink
([https://github.com/adjoint-io/uplink](https://github.com/adjoint-
io/uplink)), plus there's the Pact smart contract language
([https://github.com/kadena-io/pact](https://github.com/kadena-io/pact))

------
fegu
As usual Stephen does a great job. Well worth a thorough read for any Haskell
practitioner.

------
jzb_
The back-end of www.chordify.net has been completely written in Haskell, using
cloud-haskell to keep the service scalable.

------
xvilka
I wonder, what happened with Luna[1] language project? Seems dead, no updates,
no emails on the mailing list I subscribed.

[1] [https://luna-lang.org](https://luna-lang.org)

------
mjhoy
I'm particularly excited about the prospect of linear types; not so much for
helping with space/GC efficiency (which is good of course) but for modeling
state transitions and ensuring that, for instance, some intermediate state
must get consumed once and only once. It's one of the bugs I often run into
when writing Haskell code.

~~~
kccqzy
The linear type hype is a bit overblown. As one skeptical GHC developer has
said, there’s not a single concrete example of how linear types would help
real-life code. Haskell already has great facilities to handle state
transition; linear types isn’t needed to ensure “some intermediate state must
get consumed once and only once.”

~~~
drb226
"linear types isn’t needed to ensure “some intermediate state must get
consumed once and only once.”"

If you don't use linear types to ensure this, then you're probably not
ensuring it, and it just comes down to "hopefully the programmer eyeballed it
correctly and read the docs."

~~~
kccqzy
More than 20 years ago people solved the token-that-must-be-consumed-once
problem with the IO monad. Just a secret token that gets threaded everywhere.
The monadic bind is just great syntactic sugar.

Also more than 20 years ago people figured out a way to keep separate tokens
completely independent and forbid them from interacting with each other.
That’s the phantom `s` type variable in ST.

Nowadays we have so many more complicated solutions (not all of them
worthwhile!) giving you choice how you want to make sure an intermediate state
is consumed once. Why not implement a state machine at the type variable using
DataKinds, TypeFamilies et al?

Or you know, for the case of ensuring file handles/database connections get
closed correctly, use monadic regions:
[http://okmij.org/ftp/Computation/resource-aware-
prog/region-...](http://okmij.org/ftp/Computation/resource-aware-prog/region-
io.pdf) (disclaimer: I haven’t read this paper or used this approach myself
but I heard it’s a good technique)

But more importantly, even if introducing linear types can make what’s
currently barely doable in Haskell easily doable, maybe even replacing five
language extensions with one, does it have a good power-to-weight ratio? I’m
not convinced. Is the kind of mistakes prevented by this language extension
often made by typical Haskell programmers? My answer is no.

~~~
dllthomas
> Is the kind of mistakes prevented by this language extension often made by
> typical Haskell programmers? My answer is no.

The kind of mistakes often made by Haskell programmers interacting with
objects not well managed by the Haskell garbage collector? Yes, absolutely.
Whether there's enough Haskell programmers in that situation, I am unsure;
quite possibly not, but it includes me and my colleagues, as well as those
currently doing the work.

------
js8
He writes: "Most large Haskell projects (GHC, Stack, Agda, Cabal, Idris, etc)
no longer use Haddock for documentation."

So, what do they use? How do I get (I mean, build in stack) my useful
documentation? (Actually I appreciate any tips how to build documentation for
off-line use.)

~~~
sjakobi
I'm not sure what that statement was based on. The stack project certainly
still uses haddock to document its code.

At least some of the projects he cites also use readthedocs for user guides
etc.

> How do I get (I mean, build in stack) my useful documentation?

Try

    
    
        stack haddock --open <packagename>

------
greatNespresso
Talking about recent stuff, it looks like Cardano rely on Haskell for their
PoS protocol implementation : [https://github.com/input-output-hk/cardano-
sl](https://github.com/input-output-hk/cardano-sl)

------
topogios
A quick few:

The backend, [https://github.com/kirel/detexify-hs-
backend](https://github.com/kirel/detexify-hs-backend), for Detexify,
[http://detexify.kirelabs.org/classify.html](http://detexify.kirelabs.org/classify.html).

Parts of BazQux Reader, a commercial feedreader,
[https://bazqux.com](https://bazqux.com)

Nikki and the Robots, a platformer, [https://github.com/nikki-and-the-
robots/nikki](https://github.com/nikki-and-the-robots/nikki)

------
moocowtruck
Facebook Duckling
[https://github.com/facebook/duckling](https://github.com/facebook/duckling)

rewritten from clojure, used to power smart products at facebook

------
akinsketch
Habito [0], a mortgage broker based in London, has its back end written in
Haskell.

[0] [https://www.habito.com/](https://www.habito.com/)

------
haskdev
> Not so surprisingly most people have migrated to Stack

Justice prevailed despite the futile attempts by the Haskell Committee to
prevent Stack becoming popular!

------
devit
My impression of Haskell is that the main issue is that laziness is simply
wrong, since it causes space leaks that are hard to reason about, and seems
generally less efficient than eagerness; furthermore, it seems rarely
beneficial, so it seems more appropriate to explicitly request laziness rather
than the opposite.

The next problem is that complete immutability is also wrong, because
controlled mutable aliasing with linear types (like the system available in
Rust) is what you really want since it's more general, efficient and
expressive (allows mutable data structures), and complete immutability is just
a special case of controlled mutable aliasing.

The third problem of Haskell is the weird syntax, that doesn't follow the
common C/Java/JS or Python syntaxes for no good reason, making it hard to read
and learn the language.

And if one were to change these things in Haskell, the result would
essentially be Rust (or more precisely, a future version of Rust once all the
missing abstractions like HKT, specialization, etc. are added), so I think
that's what one should use instead.

~~~
lucozade
> laziness is simply wrong

No it's not. It's not a particularly sensible default (which you allude to)
but it's not wrong. Modelling delayed resolution is very handy. For example,
you'd not get far in Rust without Result<>, Option<> or Future<> which are all
make use of delayed resolution for their value. And the more we move to
parallel models, the more important it will be.

> because controlled mutable aliasing with linear types ... is what you really
> want

Again, no. It's less restrictive than pure immutability, and Rust has shown
that statically managing some mutability is viable, which is great, but it's
not _what you really want_.

What you really want is a static checker that only prevents shared,
simultaneous mutability but admits everything else. The Rust borrow checker is
an important step in that direction but it's not it.

> The third problem of Haskell is the weird syntax

I'm not one of life's Lisp apologists. Syntax is important, though not as
important as semantics. But just because you find it difficult to read doesn't
make it objectively difficult.

And if you're implying that Rust is easy to read, for a beginner, because it
uses curly braces, I'm not entirely sure what to say.

I think Rust is an excellent language. I hope and believe it will be an
influential language as it's a fantastic combination of innovation and
pragmatism.

I'm also enormously grateful that a lot of the decisions are made in the open,
I've learnt a lot and continue so to do. But it's a good language because the
designers clearly have an appreciation of what has gone before. That's a good
way to be.

~~~
lmm
> And if you're implying that Rust is easy to read, for a beginner, because it
> uses curly braces, I'm not entirely sure what to say.

Rust is easier to read because the visually natural distinction between words
and punctuation has the same kind of meaning in Rust that it does in prose.
Reading Haskell feels like reading a paragraph without any punctuation;
there's no structure to grab onto. A lot of the time you can't tell whether
something is a type parameter or a value.

Also $ is utterly alien compared to any other remotely mainstream language, .
means something very different from what it usually does and what it usually
means is rarely used ("subject verb object" is very rare in Haskell code), the
:: type syntax is obscure, the mandatory split/duplication between function
declaration and definition feels weird...

~~~
runeks
> A lot of the time you can't tell whether something is a type parameter or a
> value.

> […] the mandatory split/duplication between function declaration and
> definition feels weird...

I believe you just answered your own critique: you can always tell whether
something is a type parameter or a value, because type and implementation are
kept separate.

~~~
lmm
They're in separate clauses but they look the same on their own. You have to
look out to a few lines of context to see which is which. At a glance it's not
even obvious which lines are function declarations and which are
implementations.

