
Reflecting on Haskell in 2015 - lelf
http://www.stephendiehl.com/posts/haskell_2016.html
======
dcre
I really enjoyed this. Just wanted to comment on the author's brief comments
on Elm.

> As of yet, there is no rich polymorphism or higher-kinded types. As such a
> whole family of the usual functional constructions (monoids, functors,
> applicatives, monads) are inexpressible.

I completely understand that this make Elm quite limited compared to Haskell
as the author uses it, but these limitations are precisely what makes Elm
accessible to newcomers. I think it's a great way to get people into Haskell
syntax like partial application and into the functional way of thinking in
general.

I have learned Haskell very gradually over the past 6 years, and I still find
advanced Haskell with all the language extensions very daunting to get into.

~~~
baldfat
For learning functional programming I find Racket to be the best for teaching
functional programming. I think I took 4 tries at teaching myself Haskell and
then learning Racket really helped me to get over the learning curve of
Haskell though i still consider myself a beginner.

~~~
PopsiclePete
I've tried Haskell 4 times. No joke. I have no problem with currying, higher-
order functions, foldl, etc., but Monads. Get. Me. Every. Time.

My brain just refuses to fully "grok" them. I still don't see why they're so
awesome. I know I use them day-to-day - LINQ, the "List" abstraction
(supposedly also a monad??) but I just don't see why it's important to
understand them on this whole new fundamentally different level.

It's like - loops. I use loops every day. But if someone were to say - "Hey,
did you know that loops are just the Andifuncsplursx abstraction applied on
Crazofors?? This is why Crazofors in Haskell are so awesome" I still wouldn't
"get" Crazofors or why I should care enough to attempt to "get" them.

I've just given up at this point.

~~~
vans
Like Erik Meijer said in his course : there is nothing special or magic about
monads. They don't deserve all the fuzz arround them. If you don't get why
monads are so awesome, maybe that's a proof that you understood them. Because
there is nothing special !!

A monad is just a type with 2 functions defined. Like an interface with two
methods in OO langages. The 2 functions have to respect some laws but you can
imagine whatever implementation for the 2 functions as long as the laws are
observed (et type signature of course).

You could invent a total different implementation for the list monad, for the
maybe monad, etc (if you respect the laws). There is no hidden ultra powerfull
meaning which implies only one implementation.

The best paper on monads i ever read is an ascii art one, by Graham Hutton :
[http://www.cs.nott.ac.uk/~pszgmh/monads](http://www.cs.nott.ac.uk/~pszgmh/monads)

~~~
kqr
> You could invent a total different implementation for the list monad, for
> the maybe monad, etc (if you respect the laws).

Could you show such a different implementation for either list or maybe?

~~~
jjaredsimpson

        newtype HeadList a = HeadList { getHeadList :: [a] }
    
        instance Monad HeadList where 
             return a = HeadList [a]
             m >>= f = HeadList $ fmap (head . getHeadList . f) (getHeadList m) 
    

This is a list instance that only keeps the head of function result, so it's
basically just a map.

But you could imagine putting any function that returns one result. min max
avg normalize, etc

~~~
ky3

        -- const [] for a HeadList
        quux :: a -> HeadList a
        quux = HeadList . (const [])
    
        *Main> HeadList "hello... no wait" >>= quux
        HeadList {getHeadList = "*** Exception: Prelude.head: empty list
    

Such breakage is verboten. This monad instance does not fly.

------
jasperry
I consider myself a functional programmer, and I also have an interest in
logic and type theory, and have learned enough Haskell to write some student-
level projects in it.

But when I try to dip my toe back into the Haskell community, a wave of
despair washes over me. There's just too much. Haskell is changing too fast.
There are too many language extensions, and more and more conceptually
sophisticated features keep getting added to it. Every project uses a
different set of GHC extensions.

I feel that without more standardization or stability, Haskell can never be
more than a playground for PL researchers who can afford to spend all their
time learning and implementing advanced language features.

~~~
chrisseaton
For me all the extensions and abstractions induce a kind of choice paralysis,
and fear that my program isn't abstracted far enough. I don't feel that when
working in C, Java or Ruby.

~~~
jasperry
That captures my feelings really well. And then I think that if I'm going to
stick to the "meat and potatoes" of functional programming, I might as well
just use a language in the ML family.

~~~
kqr
Except controlled side effects are a godsend, even for meat and potatoes.

~~~
vu3rdd
Yes, indeed. Even with the 101 level haskell I write, it feels so right. I
exactly know where the side effects are and the semantics of the program is so
clear.

------
spooningtamarin
Stack is absolutely wonderful. stack setup command works wonders, building is
effortless, moving to new library versions is as easy as ever and ever since
I've started using it I've been writing more and more code in Haskell.

Tooling is absolutely great, Atom plugins are very fine, really, it's very
enjoyable and it all happened in a single year.

------
armitron
I like Haskell but I see no future in terms of widespread adoption for it.
It's simply too alien for your typical CS grad and for some projects one would
like to use it for (let's say security critical), laziness (and non-
predictable behavior in terms of memory use and performance) is a big problem.

We do however see some of its features being slowly introduced to other
languages which is nice, I guess.

~~~
thetmkay
> It's simply too alien for your typical CS grad

In my university, Programming 101 (mandatory) was (and is) Haskell. For
context, there is typically a mix of experience among the class - some will
have programmed seriously before, but others will have only studied math.

I had already studied Java, but I found Haskell a delightful re-introduction
(it was my first exposure to functional programming) and I see its value as an
educational tool.

~~~
flying_kangaroo
From what I've heard, MIT does the same thing with CS101, except in Scheme.
Starting the curriculum that way seems like a good idea (in the long run,
since internships and whatnot all want Java or C++/C#), between leveling the
playing field and providing a foundation on a lot of the "math" that CS is
based on.

~~~
jandrese
I had a course in College that was taught in Scheme. It wasn't the "intro to
computer science" class, but it was mandatory and at the Sophomore level.

That said, scheme never managed to feel like anything other than a toy
language to me, and that we were being fed problems that happened to map
neatly into the structure of the language. Write a RPN calculator! Write a
Tree Parser! Stuff that really isn't that much harder (but admittedly more
verbose) in imperative languages.

I couldn't help but to think "Sure, these problems are easy enough, but how
would I blit pixels with this language? How would I process TCP/IP packets?
What would a database interface look like? How am I supposed to do error
handling?"

In the end I had no desire to integrate Scheme into my day to day programming.

------
soperj
I've learned haskell at the university level, and really enjoyed it(and found
it very easy to pick up), but find it puzzling where I should use it. It's
very easy to say this problem requires a scripting language, and this problem
is better suited for an object oriented language, but I don't quite understand
what problems would be easier with a functional language. At least in terms of
problems that I want solved.

~~~
kqr
> ...this problem requires a scripting language...

Cool, we have that in Haskell these days![1] Except, of course, it has all the
good high-level stuff of Haskell, which reduces boilerplate and increases
correctness.

[1]:
[https://hackage.haskell.org/package/turtle-1.2.3/docs/Turtle...](https://hackage.haskell.org/package/turtle-1.2.3/docs/Turtle-
Tutorial.html)

~~~
soperj
Nice to know. Maybe using it more often would lead to thinking about things
functionally and finding problems that are better solved functionally.

------
galfarragem
Speaking as somebody that dabbled around with a lot of programming languages,
I believe that haskell is kind of an endpoint. Doesn't get better than this.
Going back (to other languages) is harder than going further (improving on
haskell).

But pure haskell might be too much for a begginer. For me, as an hobbyist, it
was. Then I discovered a real world haskell, Elm that (for now) is 'married'
to JS. Later, if I feel the need, I can always 'upgrade'. IMHO elm is for
haskell, what meteor is for javascript. Even without support from purists,
they conquered their market share. This irritated a lot of people.

------
rdc12
"Call-By-Push-Value

On the topic of evaluation methods there is interesting research opportunity
into exploring an alternative evaluation methods for the lambda calculus under
the so-called “Call-By-Push-Value” method. Surprisingly this technique has
been around for 11 years but lacks an equivalent of SPJ’s seminal “stock
hardware implementation” paper describing an end to end translation from CBPV
to x86. This would be an interesting student project."

Any idea which SPJ paper he is referencing?

~~~
throwaway000002
He's probably referring to SPJ's work on the spineless tagless G-machine [1].

In truth, though, I think trying to incorporate Call-By-Push-Value into
Haskell would radically change the language unless there's some research in
type theory that allows for the implicit Call-By- _Need_ nature of Haskell to
be extended into a form that can accommodate CBPV, which itself explicates a
kind duality between Call-By-Name and Call-By-Value.

If advancements have been made here, I'd love to hear about it.

[1]
[http://research.microsoft.com/apps/pubs/default.aspx?id=6708...](http://research.microsoft.com/apps/pubs/default.aspx?id=67083)

------
cageface
I've been intrigued and frustrated by Haskell on and off for years now. But I
think the open sourcing of Swift has, at least for now, iced my interest in
Haskell. Certainly they are not directly interchangeable, but I think Swift
brings a lot of the benefits of an FP language like Haskell or OCaml but is
eminently more practical and applicable. Or at least it will be as the OS
community behind it gains speed.

So Haskell is still on my radar but, for now, off my list of things I intend
to learn.

------
mikemcgowan
distance :: { x :: Number, y :: Number } -> Number

distance point = sqrt(point.x^2 + point.y^2)

The function application of sqrt shouldn't have parens.

And the type of distance should be

distance :: forall r. { x :: Number, y :: Number | r} -> Number

Otherwise, it's not row-polymorphic and you wouldn't be able to apply distance
to a record of type Point3D.

------
jrochkind1
> Avoiding success at all costs takes time...

Uh?

~~~
jberryman
"Avoid success at all costs" is haskell's unofficial motto (coined by SPJ), so
this is a little joke.

