Live data from Hacker News

Reflecting on Haskell in 2015

stephendiehl.com

11–20 of 106 posts

Re: Reflecting on Haskell in 2015

#11
post #5
post #2

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.

> 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…

Dijkstra wrote an amusing little note about why it's a good idea to teach Haskell in CS 101. http://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budg...

Re: Reflecting on Haskell in 2015

#12
post #2

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.

Haskell is already gaining widespread adoption in a variety of fields that require the levels of correctness it provides (hint: compilers, DSLs to correctly specify and process complicated contracts worth millions) or where haskell-style code more directly maps onto low level machine concepts (hint: not x86).

Haskell will probably not take over the world of web programming. It currently is gaining widespread adoption in a variety of interesting places, however.

Re: Reflecting on Haskell in 2015

#13
post #2

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.

I don't think laziness is as much of an issue as the GC. You can't write a Haskell library and the link it into arbitrary programs safely.

If you want to write a new libssl or libjpeg, you need to use c, c++, or rust (or a few others, of course).

Re: Reflecting on Haskell in 2015

#14
post #2

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.

Talking about security:

https://code.facebook.com/posts/745068642270222/fighting-spa...

Re: Reflecting on Haskell in 2015

#15
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.

Re: Reflecting on Haskell in 2015

#16
post #5

Earlier quoted context omitted.

> 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…

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.

Since 2007, the intro curriculum uses Python, not Scheme.

Re: Reflecting on Haskell in 2015

#17
post #15

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…

[deleted]

Re: Reflecting on Haskell in 2015

#18
post #17
post #15

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…

[deleted]

Yikes, anyone coming from a non-FP background to Elm is very much going to learn new ways of programming.

Elm is quite different than most front-end UI and I think your last sentence does it a great disservice.

Re: Reflecting on Haskell in 2015

#19
post #15

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…

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.

Re: Reflecting on Haskell in 2015

#20
post #19
post #15

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…

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.

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.

Post reply on HN