15 ms·

Reflecting on Haskell in 2015

191 points by lelf 11y ago

armitron 11y ago
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.
- LukeHoersten 11y ago
  Haskell's learning curve is certainly steeper than other popular general programming languages. But my view on that is best explained with an analogy: calculus is certainly harder to learn than arithmetic approximations but once learned, the complexity of calculus is factored out of all the problems suited for solving with it. Haskell is excellently suited for solving extremely complex problems and why it's so desirable for concurrency and parallelism tasks. On your second point, while it seems nice to have Haskell features slowly percolate into other languages, I urge caution in thinking that's a panacea for not learning more complex languages. Haskell is greater than the sum of all it's features. It's power comes from the combination of everything working together in a very well thought-out way. So I don't necessarily disagree with your tone, just some additional commentary from someone who knows C++, Python, Java, and Haskell equally well (and perhaps equally bad ;) ).
  - imh 11y ago
    Maybe the difference is that we all learned calculus in classes from experts, while the only way for most people to learn haskell is to pick it up themselves.
  - imakesnowflakes 11y ago
    > Haskell is excellently suited for solving extremely complex problems and why it's so desirable for concurrency and parallelism tasks. What is an example of an extremely complex problem that you have solved that would be vastly more harder to implement in another language. The most powerful thing that I have noticed is the type system. When you have a complex problem, you end up breaking it up by writing a lot of functions. In case of a language with a less powerful type system, it is hard for you to string them all together to build the complete program. But with Haskell, if you have cared to actually annotate the types, this becomes a really trivial task. It also detects flaws in your reasoning (because the result of the previous step is incompatible with the input of the current step). So, doing this would be vastly more difficult in a language like Python or even a language with less powerful type system like C.
  - incepted 11y ago
    > Haskell is excellently suited for solving extremely complex problems and why it's so desirable for concurrency and parallelism tasks. As is the JVM (and most languages running on it). Not only that, but the JVM has actually a proven track record of being good and performant at it. And you can solve these problems with pretty much the language of your choice. What makes you think Haskell is well suited for it? Immutability? This is available in a lot of languages (and for languages where it's not enforced, simple programmer discipline and code reviews address it).
  - progman 11y ago
    > Haskell is excellently suited for solving extremely complex problems I doubt that seriously. Could you write a complete Mars landing project in Haskell for instance? That would impress me. That's the area where Ada excels, or (less impressive) C and FramaC. But Haskell? No way. AFAIK there is not one serious large project written in Haskell There is not even one sophisticated Haskell IDE for daily use written in Haskell (excuse me Leksah). Tell me if I am wrong, and if there actually are really big Haskell projects. Please don't listen compilers, they are not really complex. The only advantage which Haskell actually has in comparison to other modern languages is its greatest disadvantage. The overall rock solid type safety of the whole application makes it very difficult to add additional unpredicted functionality which requires a significant change in many modules (where on the other hand the type system helps a lot). I am very impressed by the efforts and the implementations of Haskell but the simple fact that the Cabal hell -- for the simple job of a basic package manager -- lasted for years reveals that Haskell is not that practical after all. I invested a lot of time to learn Haskell to use it seriously but after I switched to Nim (nim-lang.org) I realized how easy I can get real productivity.
    - dllthomas 11y ago
      "Could you write a complete Mars landing project in Haskell for instance? That would impress me. That's the area where Ada excels, or (less impressive) C and FramaC. But Haskell? No way." Depending on what you mean by "in Haskell", probably. You can write hard-realtime software in an embedded DSL in Haskell that gives you explicit control over timings, scheduling, etc, while still giving you Haskell's higher order features for composing your programs. https://hackage.haskell.org/package/atom https://hackage.haskell.org/package/atom As I understand, the company that wrote it uses it in production in automotive systems.
- onesixtythree 11y ago
  I like Haskell but I see no future in terms of widespread adoption for it. The aim isn't necessarily widespread adoption, so much as the ability for people who know it to use professionally. It's way past merely "production ready", but reputation is a lagging indicator and so most programmers are stuck doing Java... Since the goal is to avoid {success at all costs}, getting 25% market share is probably not possible. 1 percent would be a start. The problem, economically speaking, is that Haskell and Clojure engineers are massively underpaid, when you consider that an average Haskeller would be Principal+ at any Java shop. That's because the Java and C++ people can create bidding wars every year and spike their salaries, whereas using a better but more niche language makes that career strategy untenable. Haskell's laziness isn't as much of an issue as people make it out to be. You can have strictness any time you need it, so it's more akin to an opt-out model than laziness being forced upon the programmer. It is correct to observe that high-performance applications frequently have a lot of strictness annotations, and the argument can be made that high-performance Haskell (while it can be close to C in performance) isn't "idiomatic"... although that claim is true of all high-level languages (even Java). High-performance Clojure ends up being full of '^' characters for type annotations, and high-performance Haskell ends up being full of '!' characters for strictness.
  - LukeHoersten 11y ago
    Great points. I can attest to the fact that low-latency Java code looks nothing like idiomatic Java. Ironically, the techniques for writing low latency Java are the same in Haskell (avoiding object creation, boxing, garbage collection, etc). High performance C and C++ are a league of their own with direct control over memory layout and alignment etc. Haskell has some amazing work on that front as well though: http://www.doc.ic.ac.uk/~dorchard/publ/icfp-2013-simd-vectorisation.pdf http://www.doc.ic.ac.uk/~dorchard/publ/icfp-2013-simd-vector...
  - mmarx 11y ago
    > high-performance Haskell ends up being full of '!' characters for strictness. The upcoming GHC 8 provides the Strict extensions which makes everything strict by default on a per-module level. That should greatly reduce the number of »!« characters.
- thetmkay 11y ago
  > 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 11y ago
    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.
    - gugagore 11y ago
      Since 2007, the intro curriculum uses Python, not Scheme.
    - jandrese 11y ago
      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.
  - chrisseaton 11y ago
    > In my university, Programming 101 (mandatory) was (and is) Haskell I think this is true at a lot of universities. I would have thought if you get a random CS grad they're much more likely to have Haskell experience than Go, Ruby, Clojure, etc.
- dragonwriter 11y ago
  > It's simply too alien for your typical CS grad I think its more too alien for your typical mid- to late-career developer that hasn't seen a CS classroom for a decade or more, or your typical successful non-CS-degree-holding autodidact developer that's done well with a narrow range of industrially-popular languages, than it is too alien for your typical CS grad.
- yummyfajitas 11y ago
  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.
- jeffdavis 11y ago
  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).
- xixixao 11y ago
  Talking about security: https://code.facebook.com/posts/745068642270222/fighting-spam-with-haskell/ https://code.facebook.com/posts/745068642270222/fighting-spa...
  - AnimalMuppet 11y ago
    I don't think "fighting spam" is really what the GP was talking about. A common "best practice" with cryptographic material is to hold it as short a time as possible (um, but garbage collection makes that hard), and zero it before releasing it (but immutability gets in the way). That means that, in a language like Haskell, you're going to leak crypto material into the free memory pool unless you break the language paradigm to prevent it. Worse, you have to remember to break the language paradigm everywhere you need to. In C++, you'd just wipe it with zeroes in the destructor, and use RAII to make sure it's freed when you don't need it any more. In Java, you have to explicitly overwrite it on your way out of the block (maybe with a "finally" clause). But in Haskell, you can't overwrite it (yeah, you actually can, but still...)
    - jerven 11y ago
      In non RT java this is nearly impossible. The best way is to use a specific allocated off memory byte buffer and zero it once done. But GC/deallocation and JIT compilation will fight your zeroing attempts, and it can easily break existing code :(
    - startling 11y ago
      This is just wrong. You can totally use managed mutable buffers that you overwrite once you're done. It's probably easier than in Java.
- jberryman 11y ago
  When you say "security critical" are you thinking specifically of stuff like crypto timing attacks? I think aside from those sorts of concerns haskell is an excellent choice for security-critical code.
- thinkpad20 11y ago
  "It's simply too alien for your typical CS grad" That's just a question of teaching it to more CS students then. I don't think it's outside of the reach of the average programmer. And yes you probably wouldn't use it to build real-time applications. But you probably wouldn't use Python to write an operating system. No language fits all use-cases.
dcre 11y ago
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.
- deleted 11y ago
  [deleted]
  - vvanders 11y ago
    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.
- baldfat 11y ago
  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 11y ago
    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.
soperj 11y ago
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 11y ago
  > ...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-Tutorial.html https://hackage.haskell.org/package/turtle-1.2.3/docs/Turtle...
  - soperj 11y ago
    Nice to know. Maybe using it more often would lead to thinking about things functionally and finding problems that are better solved functionally.
  - omaranto 11y ago
    When comparing with scripting languages, I think it's fair to talk about how Haskell increases correctness, but I don't think you'll convince people coming from those languages it reduces a lot of boilerplate. (On the other hand, you can definitely sell Haskell as a boilerplate reducer to people coming from languages like Java, say.)
- bpicolo 11y ago
  Traditionally speaking, one of the bigger arguments for functional languages is "embarrassingly high parallelism" because they tend to simplify many issues that writing imperative languages concurrently can bring about
- implicit 11y ago
  My experience is that typed functional programming is excellent for any application that can afford to run a garbage collector and needs to to be able to change continuously forever.
spooningtamarin 11y ago
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.
jasperry 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      Except controlled side effects are a godsend, even for meat and potatoes.
      - vu3rdd 11y ago
        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.
  - throwaway6969 11y ago
    That's why Go succeeds too.
cageface 11y ago
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.
jrochkind1 11y ago
> Avoiding success at all costs takes time... Uh?
- jberryman 11y ago
  "Avoid success at all costs" is haskell's unofficial motto (coined by SPJ), so this is a little joke.
- kqr 11y ago
  Originally spoken as "Avoid (success at all costs)", i.e. don't sacrifice your principles just to get your 15 seconds on the stage. Now sometimes used as a joke in the alternate meaning.
rdc12 11y ago
"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 11y ago
  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=67083 http://research.microsoft.com/apps/pubs/default.aspx?id=6708...
galfarragem 11y ago
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.
mikemcgowan 11y ago
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.

191 points by lelf 11y ago

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.

LukeHoersten 11y ago
Haskell's learning curve is certainly steeper than other popular general programming languages. But my view on that is best explained with an analogy: calculus is certainly harder to learn than arithmetic approximations but once learned, the complexity of calculus is factored out of all the problems suited for solving with it. Haskell is excellently suited for solving extremely complex problems and why it's so desirable for concurrency and parallelism tasks. On your second point, while it seems nice to have Haskell features slowly percolate into other languages, I urge caution in thinking that's a panacea for not learning more complex languages. Haskell is greater than the sum of all it's features. It's power comes from the combination of everything working together in a very well thought-out way. So I don't necessarily disagree with your tone, just some additional commentary from someone who knows C++, Python, Java, and Haskell equally well (and perhaps equally bad ;) ).
- imh 11y ago
  Maybe the difference is that we all learned calculus in classes from experts, while the only way for most people to learn haskell is to pick it up themselves.
- imakesnowflakes 11y ago
  > Haskell is excellently suited for solving extremely complex problems and why it's so desirable for concurrency and parallelism tasks. What is an example of an extremely complex problem that you have solved that would be vastly more harder to implement in another language. The most powerful thing that I have noticed is the type system. When you have a complex problem, you end up breaking it up by writing a lot of functions. In case of a language with a less powerful type system, it is hard for you to string them all together to build the complete program. But with Haskell, if you have cared to actually annotate the types, this becomes a really trivial task. It also detects flaws in your reasoning (because the result of the previous step is incompatible with the input of the current step). So, doing this would be vastly more difficult in a language like Python or even a language with less powerful type system like C.
- incepted 11y ago
  > Haskell is excellently suited for solving extremely complex problems and why it's so desirable for concurrency and parallelism tasks. As is the JVM (and most languages running on it). Not only that, but the JVM has actually a proven track record of being good and performant at it. And you can solve these problems with pretty much the language of your choice. What makes you think Haskell is well suited for it? Immutability? This is available in a lot of languages (and for languages where it's not enforced, simple programmer discipline and code reviews address it).
- progman 11y ago
  > Haskell is excellently suited for solving extremely complex problems I doubt that seriously. Could you write a complete Mars landing project in Haskell for instance? That would impress me. That's the area where Ada excels, or (less impressive) C and FramaC. But Haskell? No way. AFAIK there is not one serious large project written in Haskell There is not even one sophisticated Haskell IDE for daily use written in Haskell (excuse me Leksah). Tell me if I am wrong, and if there actually are really big Haskell projects. Please don't listen compilers, they are not really complex. The only advantage which Haskell actually has in comparison to other modern languages is its greatest disadvantage. The overall rock solid type safety of the whole application makes it very difficult to add additional unpredicted functionality which requires a significant change in many modules (where on the other hand the type system helps a lot). I am very impressed by the efforts and the implementations of Haskell but the simple fact that the Cabal hell -- for the simple job of a basic package manager -- lasted for years reveals that Haskell is not that practical after all. I invested a lot of time to learn Haskell to use it seriously but after I switched to Nim (nim-lang.org) I realized how easy I can get real productivity.
  - dllthomas 11y ago
    "Could you write a complete Mars landing project in Haskell for instance? That would impress me. That's the area where Ada excels, or (less impressive) C and FramaC. But Haskell? No way." Depending on what you mean by "in Haskell", probably. You can write hard-realtime software in an embedded DSL in Haskell that gives you explicit control over timings, scheduling, etc, while still giving you Haskell's higher order features for composing your programs. https://hackage.haskell.org/package/atom https://hackage.haskell.org/package/atom As I understand, the company that wrote it uses it in production in automotive systems.
onesixtythree 11y ago
I like Haskell but I see no future in terms of widespread adoption for it. The aim isn't necessarily widespread adoption, so much as the ability for people who know it to use professionally. It's way past merely "production ready", but reputation is a lagging indicator and so most programmers are stuck doing Java... Since the goal is to avoid {success at all costs}, getting 25% market share is probably not possible. 1 percent would be a start. The problem, economically speaking, is that Haskell and Clojure engineers are massively underpaid, when you consider that an average Haskeller would be Principal+ at any Java shop. That's because the Java and C++ people can create bidding wars every year and spike their salaries, whereas using a better but more niche language makes that career strategy untenable. Haskell's laziness isn't as much of an issue as people make it out to be. You can have strictness any time you need it, so it's more akin to an opt-out model than laziness being forced upon the programmer. It is correct to observe that high-performance applications frequently have a lot of strictness annotations, and the argument can be made that high-performance Haskell (while it can be close to C in performance) isn't "idiomatic"... although that claim is true of all high-level languages (even Java). High-performance Clojure ends up being full of '^' characters for type annotations, and high-performance Haskell ends up being full of '!' characters for strictness.
- LukeHoersten 11y ago
  Great points. I can attest to the fact that low-latency Java code looks nothing like idiomatic Java. Ironically, the techniques for writing low latency Java are the same in Haskell (avoiding object creation, boxing, garbage collection, etc). High performance C and C++ are a league of their own with direct control over memory layout and alignment etc. Haskell has some amazing work on that front as well though: http://www.doc.ic.ac.uk/~dorchard/publ/icfp-2013-simd-vectorisation.pdf http://www.doc.ic.ac.uk/~dorchard/publ/icfp-2013-simd-vector...
- mmarx 11y ago
  > high-performance Haskell ends up being full of '!' characters for strictness. The upcoming GHC 8 provides the Strict extensions which makes everything strict by default on a per-module level. That should greatly reduce the number of »!« characters.
thetmkay 11y ago
> 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 11y ago
  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.
  - gugagore 11y ago
    Since 2007, the intro curriculum uses Python, not Scheme.
  - jandrese 11y ago
    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.
- chrisseaton 11y ago
  > In my university, Programming 101 (mandatory) was (and is) Haskell I think this is true at a lot of universities. I would have thought if you get a random CS grad they're much more likely to have Haskell experience than Go, Ruby, Clojure, etc.
dragonwriter 11y ago
> It's simply too alien for your typical CS grad I think its more too alien for your typical mid- to late-career developer that hasn't seen a CS classroom for a decade or more, or your typical successful non-CS-degree-holding autodidact developer that's done well with a narrow range of industrially-popular languages, than it is too alien for your typical CS grad.
yummyfajitas 11y ago
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.
jeffdavis 11y ago
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).
xixixao 11y ago
Talking about security: https://code.facebook.com/posts/745068642270222/fighting-spam-with-haskell/ https://code.facebook.com/posts/745068642270222/fighting-spa...
- AnimalMuppet 11y ago
  I don't think "fighting spam" is really what the GP was talking about. A common "best practice" with cryptographic material is to hold it as short a time as possible (um, but garbage collection makes that hard), and zero it before releasing it (but immutability gets in the way). That means that, in a language like Haskell, you're going to leak crypto material into the free memory pool unless you break the language paradigm to prevent it. Worse, you have to remember to break the language paradigm everywhere you need to. In C++, you'd just wipe it with zeroes in the destructor, and use RAII to make sure it's freed when you don't need it any more. In Java, you have to explicitly overwrite it on your way out of the block (maybe with a "finally" clause). But in Haskell, you can't overwrite it (yeah, you actually can, but still...)
  - jerven 11y ago
    In non RT java this is nearly impossible. The best way is to use a specific allocated off memory byte buffer and zero it once done. But GC/deallocation and JIT compilation will fight your zeroing attempts, and it can easily break existing code :(
  - startling 11y ago
    This is just wrong. You can totally use managed mutable buffers that you overwrite once you're done. It's probably easier than in Java.
jberryman 11y ago
When you say "security critical" are you thinking specifically of stuff like crypto timing attacks? I think aside from those sorts of concerns haskell is an excellent choice for security-critical code.
thinkpad20 11y ago
"It's simply too alien for your typical CS grad" That's just a question of teaching it to more CS students then. I don't think it's outside of the reach of the average programmer. And yes you probably wouldn't use it to build real-time applications. But you probably wouldn't use Python to write an operating system. No language fits all use-cases.

dcre 11y ago

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.

deleted 11y ago
[deleted]
- vvanders 11y ago
  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.
baldfat 11y ago
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 11y ago
  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.

soperj 11y ago

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 11y ago
> ...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-Tutorial.html https://hackage.haskell.org/package/turtle-1.2.3/docs/Turtle...
- soperj 11y ago
  Nice to know. Maybe using it more often would lead to thinking about things functionally and finding problems that are better solved functionally.
- omaranto 11y ago
  When comparing with scripting languages, I think it's fair to talk about how Haskell increases correctness, but I don't think you'll convince people coming from those languages it reduces a lot of boilerplate. (On the other hand, you can definitely sell Haskell as a boilerplate reducer to people coming from languages like Java, say.)
bpicolo 11y ago
Traditionally speaking, one of the bigger arguments for functional languages is "embarrassingly high parallelism" because they tend to simplify many issues that writing imperative languages concurrently can bring about
implicit 11y ago
My experience is that typed functional programming is excellent for any application that can afford to run a garbage collector and needs to to be able to change continuously forever.

spooningtamarin 11y ago

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.

jasperry 11y ago

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 11y ago
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 11y ago
  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 11y ago
    Except controlled side effects are a godsend, even for meat and potatoes.
    - vu3rdd 11y ago
      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.
- throwaway6969 11y ago
  That's why Go succeeds too.

cageface 11y ago

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.

jrochkind1 11y ago

> Avoiding success at all costs takes time... Uh?

jberryman 11y ago
"Avoid success at all costs" is haskell's unofficial motto (coined by SPJ), so this is a little joke.
kqr 11y ago
Originally spoken as "Avoid (success at all costs)", i.e. don't sacrifice your principles just to get your 15 seconds on the stage. Now sometimes used as a joke in the alternate meaning.

rdc12 11y ago

"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 11y ago
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=67083 http://research.microsoft.com/apps/pubs/default.aspx?id=6708...

galfarragem 11y ago

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.

mikemcgowan 11y ago

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.