
Haskell for a New Decade [pdf] - todsacerdoti
http://dev.stephendiehl.com/new_decade.pdf
======
quickthrower2
I think the focus on Haskell is missing the mark a bit.

Haskell is about programming language researchers and enthusiasts having a
excellent example language to try out ideas. Over the years it has turned into
a production ready platform.

As the PDF shows there are many languages spun off Haskell and it doesn't even
mention them all. Then there are language features in C# and Java, Typescript
etc. that are coming across from Haskell.

I think the problem with Haskell as a language as a mainstream thing is that
it requires a lot of upfront investment to get used to. C# -> Ruby is 10 hours
to be productive, 100 hours to be reasonable. C# -> Haskell is ten times that.

A lot of stuff to get your head around. There are complex topics from category
theory to metaprograming. Sure you can ignore it - until you want to use a web
framework that uses those concepts, then it's on you.

Instead of Haskell we should be thinking of programming language research and
how to get the best ideas into our mainstream languages. How do we make
immutability easy and ergonomic and get rid of nulls in C#? Can we have
guarantees in our program. There are even features not in Haskell proper like
Liquid Haskell that would be interesting to have in C# or Typescript.

This is what is needed if we want the Haskell ideas to be popular. That might
not be what other people want.

~~~
nh2
Counter point on "investment":

I was in a Haskell team at Google, and have trained groups at various
companies professionally. From that experience, for a normal developer with
working experience in Java, Python, or C++:

* It takes 2-3 weeks of full-time onboarding (half with a coach, half self-study) to work on a typical industrial Haskell project.

* It takes around 3 months of full-time participation in such a project to know a wide array of libraries and feel ready to tackle almost anything.

The companies involved were happy to make this time investment for increased
productivity over the time they expected their employees to stay with them.

On an individual level, it makes sense that if you're just getting into
programming, and you have the choice between investing 2 weeks into Python to
be productive, or 3 months for Haskell, you pick Python. It's rational. But
after you've been in it for a few years, and you realise you want to do it for
another 40 years, investing 3 months for life-long increased productivity
(even if it's just a few percentage points; most feel the effect is larger)
suddenly becomes a great deal.

Counter point on "complex topics":

After 6 years of industrial Haskell, I know nothing about category theory. It
has not prevented me from using web frameworks.

~~~
quickthrower2
Thanks for that.

Everything you said is from the perspective on being not only in a Haskell job
but in a Haskell team. Your 3 months is 5 years for someone trying to learn on
their own in their spare time. And then they need this to get a Haskell job
due to the competition for such job and the queue of super smart people lining
up for a Haskell job. And the pay cuts are brutal. Now you are an outlier,
working on a Haskell team for Google, the rare triad of using Haskell at work,
presumably being well paid, and having that mentorship from other team
members.

> After 6 years of industrial Haskell, I know nothing about category theory.
> It has not prevented me from using web frameworks.

As someone in as Haskell team, maybe this is possible. You don't have to try
and pick apart the online knowledge. For example a lot of libraries use Lens.
I want to understand Lens? It is not simple: check out the diagram on
[https://hackage.haskell.org/package/lens](https://hackage.haskell.org/package/lens).
"Yeah but it's just X Y Z". Great - I've been to many FP meetups, and seen a
lot of stuff online and there is no simple help for this stuff.

~~~
ArchD
> For example a lot of libraries use Lens. I want to understand Lens? It is
> not simple: check out the diagram on
> [https://hackage.haskell.org/package/lens](https://hackage.haskell.org/package/lens).

You're making it seem harder that it really is. Yes, it's hard if the package
documentation is all you have, but that's the hard way to learn. There are
other online unofficial documentation and tutorials (of diverse quality).
There's also a book ([https://leanpub.com/optics-by-
example](https://leanpub.com/optics-by-example)) that I find adequate for a
reasonable learning experience (I think I would have saved much time if I had
started learning lens using this book.). And, you don't need to know the
entire lens package to use it. The most commonly used part of lens (Lens
proper, not Prisms, Isos, etc) is only a small fraction of the whole thing.

~~~
quickthrower2
Ah OK, things have moved on in recent years. Maybe there are more resources
out there than I thought.

~~~
platz
and you can learn enough lens to be productive in 1 hours with this talk
without reading docs at all.

You can skip the theory and go straight to usage:
[https://www.youtube.com/watch?v=QZy4Yml3LTY](https://www.youtube.com/watch?v=QZy4Yml3LTY)

------
jbritton
I tried twice to get started with Haskell. I understand the language well
enough, but the standard prelude gave me problems. I forget the details, but
the first attempt involved reading ASCII strings from file. I had some issue
with the standard string type and after a bunch of searching and trying other
things, nothing worked. The second time I tried to use sockets. After a few
days, I discovered sockets were both broken and deprecated.

Haskell needs to replace the standard prelude and burn the old documentation.

I have used dozens of languages and never really had any problems.

But the simplest of tasks in Haskell immediately put up roadblocks.

I’m sure if I had sufficient reason I could get passed these problems, but
when easy things are not easy one loses interest fast.

~~~
tome
There does seem to be a issue with discoverability in Haskell. I'm cooking up
a plan to try to improve the situation:
[https://github.com/tomjaguarpaw/tilapia/issues/13](https://github.com/tomjaguarpaw/tilapia/issues/13)

> I discovered sockets were both broken and deprecated.

Just in case anyone gets the wrong end of the stick, "Haskell sockets" are
both working and supported (quotation marks because there is no single blessed
implementation: sockets are just a (few) library(ies)). When people want help
choosing a library, I point them to
[https://haskelliseasy.readthedocs.io/en/latest/](https://haskelliseasy.readthedocs.io/en/latest/),
which is an opinionated, curated list.

------
whateveracct
I've been writing Haskell professionally for 5 years now and as a hobbyist
even longer and this presentation just doesn't resonate with my experience and
view towards the future.

That said I've taken my focus off working in it professionally. It's such a
chore to have to constantly justify it to newly-externally-hired management
and inevitably get a top-down directive to rewrite. I'm done relying on
managers and corporations to drive Haskell.

My focus now is freedom & independence. I've got plenty of hugs and impactful
personal projects & Haskell advancements I'd like to undertake in the next
5-15 years, and nothing even sniffs Haskell as a tool for me building without
thinking or exerting energy. Maybe my issue is I love Haskell but I am
abjectly not a community member.

~~~
linuxlizard
What kind of production systems are a good fit with Haskell? I've wanted to
learn Haskell but keep getting distracted by other shiny things that are more
directly applicable to my job.

~~~
marcosdumay
Haskell won't give you high interactivity (on the milliseconds of response
time), or C-like performance. It will make it hard to control low level
details of your memory and execution path. It will also not bring a lot of
gain if you only have homogeneous data (like in machine learning).

If you have a problem where intermediate performance (on the level of Java and
.Net, better than Python or JS) is ok and people won't notice 100ms extra here
and there, Haskell is viable. If it's not focused on low level IO, and deals
with complicated stuff, odds are it's your best option right now.

------
nextos
Very informative slides.

I do not have real-world experience with Haskell, aside from little toy
projects, but I have a lot of experience with other functional languages in
the ML family and Scheme.

Idris 2 looks appealing, but they should have also mentioned other approaches
like Fstar, Lean and Z3. I quite like Fstar since they are delivering a big
verified code base, as implied by the name of the effort: Project Everest [1].

While theorem proving is the most general approach to verification, manual
proofs are tedious and full automation might never be completely possible in
the short term.

I would love to see someone pushing for a different approach. A toolkit where
you can create DSLs with limited expressiveness, which in turn make it easy to
build and verify things. The equivalent to Alan Kay's Viewpoints Research
Institute efforts to build a minimal computation system, but with some
verification guarantees.

[1] [https://project-everest.github.io/](https://project-everest.github.io/)

~~~
logicchains
>A toolkit where you can create DSLs with limited expressiveness, which in
turn make it easy to build and verify things.

This is a common approach in the Coq ecosystem, writing DSls for building
things, and custom automation for them. See for instance papers by Adam
Chlipala.

~~~
nextos
I know. His FRAP & CPDT books are great reads.

------
jeffdavis
"Software is Terrible and Getting Worse"

I wonder if increasing bloat is a permanent thing? Will software ever
transition to a cycle of simplification? Has it ever gone through a
simplification cycle in the past?

Physical engineering has some limits that push back on complexity. You can
only cram so many gears into a Swiss watch. An item can only have so many
parts before manfacturing becomes a nightmare.

What will push back on the complexity of software? Will it ever "break" in a
way that we just do things differently?

And it would be strange to think that something like haskell could save us,
when the compiler itself is such a beast. If something saves us, it will
probably look more like FORTH or lisp or Prolog.

~~~
yiyus
> Has it ever gone through a simplification cycle in the past?

Not as a whole, but there have been some significant attempts. Maybe the most
radical one I can think of is Chuck Moore's Forth systems. Every new version
is simpler than the previous one. Arthur Whitney has done something similar
with APL, A+ and k, constantly trying to remove non-essential features. A more
mainstream example is Unix and Plan 9, the 7th version of Unix was simpler
than previous ones, and Plan 9 was much simpler than Unix. There are also
initiatives like suckless, which try to write simpler software.

I am sure there are many more similar examples. Trying to remove bloat and
complexity is a very important goal for many developers. Unfortunately, the
real world usually gets in the way (colorForth has quite limited hardware
support, Plan 9 never included a full-featured web browser, suckless software
is not too friendly for novice users...).

------
mxschumacher
The fact that many students learn Haskell in University and then don't use it
in production isn't as much of a problem as the presentation seems to suggest.
Programming in a pure functional language is a school of thought, a way to
solve problems that's markedly different from OOP or imperative styles.

In my education as a programmer Haskell has a special place and the way I use
filter, map and reduce in production JS code is a small reflection of that.

Ideas of Haskell have cross fertilized into many other languages, e.g. you can
clearly see it in Rust.

------
pron
These slides simply assume that Haskell as-is is progress, and then bemoan the
"fashions, whims, and tastes" of the industry in being slow to relise that.
But to measure the "timescale of progress" you need to consider the duration
not from the time an idea first appears until mass adoption, but from the time
the idea is proven and market-ready. GCs were widely adopted within 5 seconds
of them having acceptable performance and not being packaged in runtimes with
other significant downsides. The adoption rate of technology -- in general and
in software in particular -- is largely consistent with what we'd expect from
traits in selective environments. Ideas that trickle slowly through fashions
(genetic drift?) are those that aren't adaptive (yet?).

------
Syzygies
"Everyone should build GHC from source at least once...You will learn a lot
about how the sausage gets made."

A decade ago a friend paid a local company to build him a many-core compute
server. I was fairly certain they'd under-spec'd the power supply. My favorite
stress test was to build 32 copies of GHC at once, daisy-chaining each new
copy to build another. Keep it running.

His computer started billowing smoke.

~~~
Tomte
That quote is misleading. The part with "how the sausage is made" refers to
reading the developer mailing list, not to building GHC.

------
frasermince
I love the clear eyed approach to what Haskell's future may look like. I look
forward to seeing the fresh ideas the programming language community continues
to bring forward in this area. Does anyone know if these slides came from a
talk that was recorded?

~~~
JoelMcCracken
Typically Steven posts the recording of the video within a couple of days.

[https://www.meetup.com/Berlin-Functional-Programming-
Group/e...](https://www.meetup.com/Berlin-Functional-Programming-
Group/events/271110609/)

------
mwcampbell
"Software is Terrible and Getting Worse"

Reminds me of this satirical post:

[https://bertrandmeyer.com/2013/03/12/apocalypse-no-
part-1/](https://bertrandmeyer.com/2013/03/12/apocalypse-no-part-1/)

------
wespiser_2018
> "The barrier to entry for GHC development remains impossibly high"

Could not agree more. I've put in a couple merge requests to the ghc Haskell
compiler, and it's very difficult to even figure out what's going on,
nevermind make a meaningful contribution.

~~~
iso8859-1
What is an easier compiler to get into? Interpreters do not count ;)

~~~
paavohtl
Rust's rustc, TypeScript's tsc and C#'s Roslyn are all developed in the open
and constantly merge patches from new contributors.

------
jeffdavis
As a database person, I think if more haskell people took an interest in
database languages, the world would be a better place.

~~~
mratsim
They surely did, and got the very unique Software Transactional Memory based
multithreading.

~~~
h91wka
I think Erlang's mnesia was the earliest implementation of STM.

------
mlthoughts2018
When will Haskell get a different spokesperson? Stephen isn’t effective in
this role. These posts have jumped the shark to the point when I see a big
Haskell post on HN and see stephendiehl.com it’s just time to tune out.

For Haskell to succeed, it has to move away from rigid commitment to various
pure functional paradigms and move to eager execution by default. But Stephen
does not help this, just preferring to instead dig in more on expecting the
reality of the rest of the world to change itself to accommodate the
strictures under false pretense that the strictures are parochially better.

Haskell’s real failure to launch is not because of complex tooling issues
between cabal & stack, not because of a big mess of compiler pragmas to get
basic String functionality, not due to complexity of understanding monads or
type classes.

The problem is that the stated benefits of pure functional programming _are
not actually benefits_ at least not when writing business software.

The slides (rather arrogantly) say we’re at the blood-letting and leeches
stage of software. Well claiming Haskell is a solution is like inventing
epicycles to explain orbits or elevate alchemy to a science. It wastes
everyone’s time with artificial complexity substituted for advanced
capability.

~~~
alexashka
The types of posts that get downvoted on here is at times maddening.

This to me, is the only reply thus far that addresses what I also perceive to
be the fundamental problem with Haskell - it doesn't provide any new
convenient tools to solve real world problems, while requiring one learns a
bunch of useless abstractions that aren't used anywhere else in industry as a
default (monads, laziness, immutability)

~~~
FullyFunctional
(It's a HN rule not to discuss down votes)

However the problem with the parent post of that it presumes Haskell isn't
useful because of X, when clearly it's useful for many and changing X would
make it not Haskell. That sort of comment isn't useful.

I think for as long as I have known Haskell (1992-) there has been interest in
and a desire for a strict variant of Haskell. In 2020 it seems there are a lot
more options for that, which is great, but they aren't Haskell.

~~~
mlthoughts2018
> “ changing X would make it not Haskell”

this seems like some version of a No True Scotsman argument.

------
infogulch
The video was posted today:
[https://www.youtube.com/watch?v=B9_xAixGlmk](https://www.youtube.com/watch?v=B9_xAixGlmk)

------
axilmar
As a seasoned C++ programmer, that occasionally plays with Haskell, here is a
question?

Has finally Haskell the problem of how to do destructive updates or not?

If it cannot do destructive updates, I am not interested. The kind of software
I am called to build always requires destructive updates for performance
reasons and secondly I am so used to assignment and all the design patterns
around it that I don't think I should bother with something that does not
provide that.

~~~
runeks
Haskell can do destructive (in-place) updates via various forms of mutable
variables (e.g. IORef).

~~~
dllthomas
And mutable arrays:
[https://hackage.haskell.org/package/array-0.5.4.0/docs/Data-...](https://hackage.haskell.org/package/array-0.5.4.0/docs/Data-
Array-MArray.html)

------
amatecha
Actual presentation should show up on this channel soon, as it's where this
talk was given: [https://www.youtube.com/channel/UCNp-
DVb8cQRIOo32sZhWgNg/vid...](https://www.youtube.com/channel/UCNp-
DVb8cQRIOo32sZhWgNg/videos)

~~~
amatecha
Ah here we go, actual presentation video has been posted:
[https://www.youtube.com/watch?v=B9_xAixGlmk](https://www.youtube.com/watch?v=B9_xAixGlmk)
:)

------
dleslie
HTTPS is busted on this site, for me:

PR_END_OF_FILE_ERROR

~~~
josephcsible
The link is to insecure HTTP. I think that site just doesn't support HTTPS.

~~~
dleslie
Ah, I use https everywhere.

------
HugoDaniel
no mention of web assembly, how is Haskell support for it ?

~~~
JoelMcCracken
Here is a recent Reddit thread on the topic.

[https://www.reddit.com/r/haskell/comments/foeyim/ask_what_is...](https://www.reddit.com/r/haskell/comments/foeyim/ask_what_is_the_state_of_haskell_targeting/)

------
deeragon
Ironic that it's a PDF.

~~~
li4ick
Care to elaborate?

------
blackrock
Why Haskell, and why not just write it in Lisp?

It appears Lisp has proven itself consistently, at solving difficult problems.

~~~
dreamcompiler
I've been paid to write Lisp most of my career. Most new languages I check out
seem like some variant of C or a dumbed-down version of Lisp. Haskell is the
only one that seems like an actual upgrade from Lisp, in that there are things
you can do in Haskell that would be quite difficult to shoehorn into Lisp
without changing Lisp in fundamental ways. (A statement I never thought I
would make before I found Haskell.) The full panoply of monads for example.
Automatic currying for another. A true lambda-functional language that _does
not need parentheses and makes no compromises for their absence_ for yet
another.

All this does not make me want to abandon Lisp for Haskell; Lisp is still more
practical for most of my needs. But if I had to write a parser I'd probably
first write it in Haskell and then translate it to Lisp, because Haskell
expands the way you think about hard programming problems -- even beyond the
realm to which Lisp expands it.

~~~
shigeo
Out of curiosity, how and how often do you make use of Haskell's laziness, and
how often does it get in your way?

And yes, the syntax of Haskell (besides unary minus) really does feel like
it's close to some kind of optimum.

------
zerr
I've heard from some long-time Haskellers that there is no point in continuing
using the language after the advent of Rust.

EDIT: I should have clarified I guess - interested to hear the opposite
arguments (as a neutral (C++) person :)).

~~~
Twisol
As a Rustacean, I find that silly. There's a lot to love about Haskell.

I'd be interested in hearing from your Haskellers what it is about Rust that
renders Haskell obsolete. As it stands, I can only construct straw men, and
I'm not really willing to do that.

~~~
zerr
From the pure language perspective (i.e. batteries aside), what do you miss in
Rust from Haskell?

~~~
Twisol
Everyone else pretty much said it for me. To elaborate more personally: the
distilled expression of pure functions as _the_ basic entity of modular
engineering is such a huge selling point for me. Lazy evaluation is also
surprisingly valuable in this vein, because I can compose components -- pass
the output of a component to the input of another -- with the assurance that
I'll only pay for that computation if it's actually requested.

I do deeply appreciate Rust in how it supports serious functional programming
idioms without requiring a GC. The value of immutable-by-default and single-
ownership semantics have been infectious far beyond my direct use of Rust. But
those very same features of Rust also make the pure function just a _little_
more clunky in that environment.

Oh, and being literally _unable_ to perform I/O (or any other computational
effect) outside of the right context is such a clear win for me. Very few
languages, even in the functional world, have such a strict separation. The
architectural _and mental_ benefits are outstanding.

Some concepts take on a surprisingly simple existence in Haskell. I recently
discovered the Yoneda and codensity transformations, as so frequently
discussed in Haskell... in the context of a Visitor pattern on a tree
structure in Java. Visitors are literally Yonada-ified sum types, and I could
only make that connection (and understand the ramifications and benefits)
after seeing how it naturally arises in both languages.

~~~
logicchains
>Very few languages, even in the functional world, have such a strict
separation.

It's catching on. Nim has the noSideEffect pragma (enabled by default if a
function is defined with "func" rather than "proc"), and D has a "pure"
annotation. Both are compiler-checked.

