26 ms·

State of the Haskell Ecosystem – February 2016

118 points by stefans 11y ago

dexwiz 11y ago
Can someone explain to me why Haskell will ever be viable as a fullstack language? I have done a few toy projects in Haskell, and it has taught me some great functional programming concepts that I now apply to other languages. But, purely functional programming seems to work 90% the time, but the other 10% is so negative it invalidates the rest. Edit for clarification: Full Stack would be app server up. So runs a server (some sort of process/thread/worker management), server scripting is in the same language (can auth, process requests, interact with a DB, etc), and build the view (simple JSON/blob response, build html, etc). I exclude client side form this, since most of the X for client-side projects end up transpiling into JS.
- jkxyz 11y ago
  Care to elaborate on what the 10% covers? I can see a few places where pure functional programming might not be as clear as imperative code, but I don't think that it invalidates the possibility of using it for large projects.
- rifung 11y ago
  I think most people would argue that it's useful when you want your code to be very maintainable or stable. I think right now the lack of educational materials and overall difficulty of learning it make it impractical for industry use unless you plan on only having a very small team. I don't know what 10% you are referring to but I personally find performance analysis to be a huge issue due to the laziness. I suspect this is largely due to the lack of educational materials which is why I'm a little skeptical that the release of one book will suddenly make it all okay as the article seems to suggest. Still, I find the language itself a complete joy to use and use it almost wherever I can.
- mbrock 11y ago
  What does full stack language mean in this context?
- akurilin 11y ago
  Would be interesting to know what you found to be the very negative 10%, maybe we can help.
- kyllo 11y ago
  Can someone explain to me why Haskell will ever be viable as a fullstack language? It already is. If you are talking about a full stack web application, there are several fully featured production quality frameworks, Yesod being the most popular. What are the negatives to you? Long compile times? Monadic IO? Memory leaks from lazy eval?
  - lvh 11y ago
    I'm guessing the poster included being able to do front-end work in Haskell. elm and purescript might be plausible front-end languages, but ghcjs isn't really there yet.
    - kyllo 11y ago
      Picking any compile-to-JS language (not counting ES6/7) is a risky proposition though. There are a lot of people regretting their five year-old "legacy" coffeescript applications today. GHCJS is improving at an astonishing rate, but at this point I still wouldn't use any compile-to-JS language for a serious production application. There's too high of a risk of building something that becomes unreasonably expensive to maintain in a few years.
      - chadaustin 11y ago
        While I use ghcjs for one of my projects, have been a big user of Emscripten in the past, and recently switched from a CoffeeScript project to a TypeScript project at work, I understand what you're saying, but I think it's an overstatement. Compiling to JavaScript is totally okay if the new language 1) adds something meaningful (like a type system [TypeScript, js_of_ocaml] or the ability to conveniently deal with unboxed data [LLJS, Emscripten]) and 2) does not have a significant runtime overhead. GHCJS, in particular, adds a _huge_ amount of runtime overhead, largely because JavaScript doesn't (yet) support tail calls so the CPS transform must be trampolined. In addition, laziness doesn't make a lot of sense for frontend code, which generally should be as tight as possible. Also, look at the code produced by ScalaJS sometime and weep. :D js_of_ocaml, on the other hand, produces extremely tight code, and is very suitable for building web frontends. Of course, OCaml probably has a similar learning curve as Haskell. I can't imagine people would get excited about the syntax. TypeScript is a sweet spot: it's got some value over straight up ES6, but it's easy to integrate and has a very short learning curve.
- sseveran 11y ago
  I use it as a fullstack language at work. I bumped into the 10% when I was a beginner, but no more.
- tathougies 11y ago
  I use Haskell exclusively on my SaaS app (http://sostenoto.com http://sostenoto.com). The backend not only provides a simple REST API, but it also provides WebRTC signaling and a real-time graphical communications and presence protocol. Haskell makes it so easy to write correct concurrent code it's not even funny. GHC's magnificent IO manager means I can handle 1000s of connections on one amazon instance. Can't understand why you wouldn't be using Haskell for server-side web development. No other popular server-side language supports concurrency (see STM, MVar's, and Chans), transparent futures/promises for I/O (the entire IO monad in GHC is non-blocking), support for multiple processors (Just add +RTS -N<n> to make your program scale to n processors), and a blazing fast HTTP server (warp).
  - andruby 11y ago
    Elixir is getting increasingly popular as a server-side language with Phoenix. It has great concurrency, futures (Tasks [0]), smp and a fast http server (cowboy [1]). [0] http://elixir-lang.org/docs/v1.1/elixir/Task.html http://elixir-lang.org/docs/v1.1/elixir/Task.html [1] https://github.com/ninenines/cowboy https://github.com/ninenines/cowboy
    - zeckalpha 11y ago
      But limited static analysis.
      - cubahacker 11y ago
        why should I want to have static analysis?
  - johan_larson 11y ago
    > Can't understand why you wouldn't be using Haskell for server-side web development. I can't tell whether that's just a rhetorical flourish, so I'll answer straight. To begin with, there are a couple of concerns that might kill an attempt to use Haskell. 1. I might not be able to get management approval. Haskell is an obscure language with a reputation for difficulty. The bosses might well say no. 2. I might need to work with an existing codebase in something like Java or Python. Not possible from Haskell. If those don't kill the project, there's the cost-benefit tradeoff. On the benefits side: 1. Haskell code is very concise. (definitely) And greater concision means faster development. (possibly) 2. Haskell code is less likely to contain errors, because of very strict typing. (probably) 3. Haskell coders are disproportionately capable, because the language is obscure and difficult. (probably) On the costs side: 1. I have much more experience in other languages. It would take at least a year, maybe two before I'd be up to pro standards in Haskell. 2. The community of Haskell programmers is small. It might be difficult to hire anyone if the project grew; I might be faced with training someone from scratch, not just in a new language, but in a new programming paradigm. So, this isn't anything like a slam dunk. Quite the opposite, actually. There are a couple of issues that might nix the project right up front, and then a daunting cost-benefit calculation.
- dudul 11y ago
  What is the 10% that is no negative? I've been using FP for 6 years now (not in Haskell though) and never looked back.
- emergentcypher 11y ago
  Really? What is this 10%? We're using Haskell for server-side programming at my work and it's been fantastic. Functional programming is so well suited for stateless web services.
- nickpsecurity 11y ago
  "Full stack would be..." For us older engineers, full-stack was hardware up to OS up to apps. Quite a few projects did that. Haskell is more full stack via that definition given it can build hardware (Bluespec), OS's (House), system code (Ivory), and web apps. Worst case, use it as a DSL to output the language of your choosing like 4GL's used to.
- bootload 11y ago
  "Can someone explain to me why Haskell will ever be viable as a fullstack language?" Aside from the solid compiler ghc and many libraries, the ability to write less, more reliable software. That's the objective isn't it? Another reason is the increasing number of usable languages written in Haskell. Using say Purescript, elm or other front-end languages, it may be as important as knowing Haskell as know C is for Python, for example.
melling 11y ago
It sounds like tooling has improved but it's still the biggest hurdle for beginners: "Improving IDE support is the single easiest way to lower the entry barrier to newcomers."
- etcinit 11y ago
  I think stack has helped in that area. As a beginner, I found stack's ability to create a new project from a template very useful when getting started with projects. The plugins for vim and Atom do a really good job for auto-completion and showing linter/compiler warnings, but they are a bit hard to setup initially.
  - bloaf 11y ago
    And they graduate from "a bit hard" to "downright painful" if you want to do it in windows. The consequences of doing it wrong can be severe[1]. [1] https://github.com/atom-haskell/ide-haskell/issues/83 https://github.com/atom-haskell/ide-haskell/issues/83
  - mark_l_watson 11y ago
    +1 yes! The stack new project templates have saved me a lot of time. Stack, I'm general, is a great improvement in my device work flow.
rifung 11y ago
> The rating of the "Educational" section still remains "Immature" until this book is out of Early Access and finally released, but once the book is out I will finally mark Haskell as having "Mature" educational resources. I haven't read the book myself, but is the book really so good that we can go from "Immature" to "Mature" with the release of just one book? I find that to be a bit strange considering Haskell is a very complicated language; I have a hard time believing a single book (that is beginner friendly no less) could really explain everything there is to know about Haskell.
- phamilton 11y ago
  Learn You a Haskell for Great Good has been an excellent resource for the intermediate programmer. Much of the intermediate to advanced space is already quite mature. The beginner space was the big gap.
  - rjayatilleka 11y ago
    Did you switch that up? Learn You a Haskell is excellent for beginners. The intermediate space is the gap.
    - phamilton 11y ago
      Beginner Haskeller, intermediate programmer is what I meant. Great for learning a new language, not great for learning a first language.
  - coolsunglasses 11y ago
    Hi, I'm a coauthor of the book mentioned in the State of the Union post. The beginner parts were _a_ gap, but they weren't the only gap. In fact, none of the existing books really went very far beyond Monad, with only RWH covering monad transformers. So, part of the appeal of the book isn't just that we cover beginner topics better, we cover _everything_ from beginner to intermediate/advanced that you're likely to apply in order to, say, make a web application. And in fact, we use a micro web framework in Haskell to demonstrate stuff in the later chapters. It may not seem like it, because chapters like "data structures" actually cover - profiling time, profiling memory, containers, benchmarking, constant applicative forms, avoiding memory leaks, etc. We'll be updating the site to explain what each chapter covers in more detail soon. I've spent a couple years teaching Haskell and haven't found LYAH to set anyone up for success in Haskell. They usually hit a brick wall because they don't have either the foundation or intermediate idioms to really get anywhere. So there's usually a 45-days-in-the-desert period after LYAH where they have to muck through tens or hundreds of blog posts to plug all the gaps. I talk about this here: http://bitemyapp.com/posts/2014-12-31-functional-education.html http://bitemyapp.com/posts/2014-12-31-functional-education.h... Suffice to say, I would've happily written a much smaller, shorter book - but this was needed.
steveklabnik 11y ago
I really, really enjoy these posts. Figuring out what an ecosystem even has and it's quality can be daunting for those considering a language, and gives experienced community members and idea of what to improve.
deleted 11y ago
[deleted]
mark_l_watson 11y ago
I think that I own 7 Haskell books, and there are good parts in all of them. A few of them are great. Why all the love and strong recommendation for a new unpublished book? I use Emacs, IntelliJ, and TextMate for Haskell. I love all three. I thought the best part of this article was the coverage of libraries because I find myself to be uncertain of selecting the most appropriate ones. I use a small subset of Haskell but that works for me.
- coolsunglasses 11y ago
  Hi, I'm a co-author of the book mentioned. Unpublished might be a bit uncharitable, the current version of the book is 26 chapters and over one thousand pages. As for why? We make certain you actually learn everything you need to know and we _aggressively_ test and review the material with actual learners. My co-author Julie's first programming language is Haskell, which she has learned from me and while writing the book. Here's a screenshot from our Zendesk for processing reader feedback and reviews: http://imgur.com/EdpL4ql http://imgur.com/EdpL4ql We are writing the book because I've been helping people in IRC (#haskell-beginners mostly which floats around 300 users), on Twitter, etc. I saw too many people burn out and give up with the existing resources (free & paid), despite maintaining a guide for learning Haskell with free resources: https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell It's just harder than it needs to be, so we're fixing that. Even the better existing books/resources don't cover nearly enough for somebody to move on to, say, writing a web application. I wrote about the pedagogical issues with some of the existing resources here: http://bitemyapp.com/posts/2014-12-31-functional-education.html http://bitemyapp.com/posts/2014-12-31-functional-education.h... If you didn't find it difficult to learn Haskell, that's great! But most people find it intensely difficult and I think that's completely unnecessary. I've given a talk on this titled, "Learn Haskell in less than five years" located here: https://www.youtube.com/watch?v=Bg9ccYzMbxc https://www.youtube.com/watch?v=Bg9ccYzMbxc
  - mark_l_watson 11y ago
    OK, I read "early access" and thought "unpublished". I stand by my minor complaint that the article was deep in praise for your book and I thought minimized the impact of the many fine existing books on Haskell. Good luck with your book. I like your enthusiasm.
fiatjaf 11y ago
I've tried many times to learn Haskell. The problem is always with setting up a compiler, getting packages, setting environment, not getting a ton of gigabytes of duplicated packages, getting useful vim support etc.
- tome 11y ago
  Have you tried stack? It was released about six months ago and has revolutionised Haskell's offering in this area.
  - Volt 11y ago
    >not getting a ton of gigabytes of duplicated packages How does stack help here?
    - tel 11y ago
      You build against a fixed set of packages defined by "Stackage" so that you only need to build them all once. While this set evolves over time, if many (or all?) of your projects target the same Stackage LTS then you won't need to rebuild dependencies.
    - tobik 11y ago
      Dependencies are downloaded and compiled once for all your projects using the same Stackage release and are shared between projects. In the end you still might have duplicated dependencies if you use different stackage.org releases but it's a much better situation than using Cabal sandboxes where every project has its own copy of dependencies.
noobermin 11y ago
This might be a good place to ask this: if one decides to go deep into Haskell, is it a good gamble? What does the job market look like for Haskell developers?
- coolsunglasses 11y ago
  Speaking as the co-author of the Haskell book mentioned in the post and somebody that has used Haskell 9-5 for a couple years - you'll have more luck getting permission to trial Haskell internally than you will competing with other Haskellers for the jobs that are out there. I recommend getting comfortable with the sorts of libraries you'd use at work before trialing to avoid what fizbin mentioned elsewhere in the thread. tl;dr create, don't take, a Haskell job
bootload 11y ago
A great comparison to the above article is this post by Stephen Diehl, "Reflecting on Haskell in 2015". [0] A great read and an interesting pointer on the state of Haskell / Javascript (Elm, Purescript). Also, work your way through "Write you a Haskell", [1] well worth the effort. Going through the post, this looks like a comprehensive book. Read the rationale behind, 'how to learn Haskell' from author. [2] [0] "Reflecting on Haskell in 2015" http://www.stephendiehl.com/posts/haskell_2016.html http://www.stephendiehl.com/posts/haskell_2016.html [1] "Building a modern functional compiler from first principles." http://dev.stephendiehl.com/fun/index.html http://dev.stephendiehl.com/fun/index.html [2] "Why we don't chuck our readers into web apps" http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-readers-into-web-apps.html http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-read...
p4wnc6 11y ago
I am a beginner Haskeller maybe just crossing the border into "intermediate." What has been most frustrating for me is not really the quality or availability of books or learning materials. Instead, it has been hard to deal with the variability in the opinions of veteran Haskellers as to what it even means to be a beginner. For example, in one job interview I had, the people interviewing me (several of whom had used Haskell for 10+ years) were very impressed by simple things -- using ADTs to model a take-home programming problem; knowing about tail-call elimination and how it impacts folds and when to write something with a helper function; basics of type classes; and fluency with Monads perhaps just slightly beyond what is discussed in LYAH. In another interview, someone right off the bat asked me to explain Arrows in great detail. I admitted I didn't know anything about Arrows except that they were in some sense a generalization of the "context" view of Monads. Another interviewer once asked me frightening questions about Template Haskell and using it for SQL queries (e.g. HASQL). Yet another asked me "design" questions about multi-parameter type classes and multi-parameter ADTs. I could point out examples of the latter, like Either, and I could name-drop the idea of Phantom Types because I heard it once in a Haskell lecture, but I tried to communicate to them that I didn't have any real command over these things in a real-life situation. It's frustrating on one hand because it makes it seem like there is no path, of any kind, from beginner to intermediate. It's like a Heaviside functions or something. You are just a beginner until one day you're suddenly not. It's kind of like playing Marco Polo in a swimming pool too. One person's yelling from that corner about Arrows. Someone else is yelling about multi-parameter type class design patterns. Someone else thinks you should know Template Haskell. There's seriously no way to prioritize studying those things. If you want to go an learn Arrows, especially if you're in a geographically isolated area like I am (hence no ability to attend meetups) and you don't already have a job providing the crucible of real work to drive learning, then you'll just flounder for weeks or months with Wikibooks entries on Arrows, etc. Then somebody stops you and says you're not good enough because you don't know multi-parameter type class patterns and so now you stop and pivot to that. Maybe whack-a-mole is a better analogy than Marco Polo. Of course there will always be some corners of an ecosystem that are obscure. But the problem with Haskell is that it seems like everything is obscure and everything pulls you in an entirely different direction, and you don't understand how they are related until long after you've mastered them at an intermediate proficiency. What I'd really like to see is more of a community consensus about what it means to be "beginner" or "intermediate" or "advanced". Maybe then people who are putting up job ads for relatively junior positions or positions where they pay clearly means it's junior will at least have some community guidance for the sort of out-of-the-box recitational knowledge to expect?
hyperpape 11y ago
The author of the book mentioned has a post called: "Why we don't chuck readers into web apps"[0] that is...not encouraging. "....Understanding algebraic datatypes requires understanding products and sums. Understanding products and sums requires understanding addition, multiplication, types, cardinality, type constructors, and data constructors...." By the time I reach cardinality I wonder if maybe the author is more interested in making things sound intimidating than helping? Or will readers be quizzed on the Continuum hypothesis? "Why can’t I learn Haskell the way I learned $BOZOLANG?" ...I hope the book itself won't take this tone. The community doesn't need it. [0] http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-readers-into-web-apps.html http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-read...
- coolsunglasses 11y ago
  >By the time I reach cardinality I wonder if maybe the author is more interested in making things sound intimidating than helping? I'm overstating my case in that post, but underestimating how hard this currently is doesn't change that there are things you'd want to understand before diving into a Haskell web application. Part of this is on the framework designers, it's mostly/only Scotty that has made any attempt not to incorporate concepts that would be difficult for beginners and it's more "hiding" than "not using". You don't need 100% grokhood all along the way, but the current status quo is that people frequently flounder and burn out because the resources they _did_ use didn't explain things usefully or cover enough. This is not conjecture, this from a _lot_ of time spent working with people hands on via IRC and Skype and curating a popular guide: https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell >"Why can’t I learn Haskell the way I learned $BOZOLANG?" >...I hope the book itself won't encourage the stereotypes about Haskell the way this post does. The stereotype that I grew up reading c2 wiki and hacker lore? I've spent most of my career so far writing C#, VB.NET, and Python. I don't even really mind a bit of Python here and there, but I don't have much cause to resort to it any more except for Ansible. As it stands, our readers have been taking breaks from the book to successfully work on side projects starting at about chapter 9 through chapter 26. Different people find there are different spots in the book where they can step away and get things done. The point is that the rest of it is always there if they need it. Education-by-blog-diaspora has not been terribly successful for many Haskell beginners up to this point. Partly because there aren't enough people for there to be enough angles on something that beginners can reliably find something that "clicks" for them. Another problem is that you want exercises to thoroughly understand a different way of thinking about and putting together programs. In the end, it feels little different in my head than when I'm writing in something imperative, but the experience is more difficult than it needed to be for beginners for a long time. The book is me "scaling up" my ability to help people. Like it or don't, whatever, but please don't try to make a blog post I wrote into something it isn't so you can try to take me down ad hominem. >...I hope the book itself won't take this tone. The community doesn't need it. You can find out what the tone of the book is by checking out the sample provided on the book's website. No need to speculate. As it is, the tone is light but to the point. Readers have enjoyed the dry humor which is not at all like how I write on my blog. Which people have liked too. You should spend less time on HN commenting on things you don't like. I have writing to do. Goodnight.
misja111 11y ago
I like this sentence: > For a long time vim and emacs were the Haskell editors of choice. Now more traditional IDEs like Atom and IntelliJ are starting to get Haskell support
- white-flame 11y ago
  While vim and emacs are certainly more "traditional", they're not IDEs, and hence not "traditional IDEs". As a Lisper, I'm still stuck with emacs as the best-supported tool, and that's kind of a sorry state of things.
deleted 11y ago
[deleted]

118 points by stefans 11y ago

Can someone explain to me why Haskell will ever be viable as a fullstack language? I have done a few toy projects in Haskell, and it has taught me some great functional programming concepts that I now apply to other languages. But, purely functional programming seems to work 90% the time, but the other 10% is so negative it invalidates the rest. Edit for clarification: Full Stack would be app server up. So runs a server (some sort of process/thread/worker management), server scripting is in the same language (can auth, process requests, interact with a DB, etc), and build the view (simple JSON/blob response, build html, etc). I exclude client side form this, since most of the X for client-side projects end up transpiling into JS.

jkxyz 11y ago
Care to elaborate on what the 10% covers? I can see a few places where pure functional programming might not be as clear as imperative code, but I don't think that it invalidates the possibility of using it for large projects.
rifung 11y ago
I think most people would argue that it's useful when you want your code to be very maintainable or stable. I think right now the lack of educational materials and overall difficulty of learning it make it impractical for industry use unless you plan on only having a very small team. I don't know what 10% you are referring to but I personally find performance analysis to be a huge issue due to the laziness. I suspect this is largely due to the lack of educational materials which is why I'm a little skeptical that the release of one book will suddenly make it all okay as the article seems to suggest. Still, I find the language itself a complete joy to use and use it almost wherever I can.
mbrock 11y ago
What does full stack language mean in this context?
akurilin 11y ago
Would be interesting to know what you found to be the very negative 10%, maybe we can help.
kyllo 11y ago
Can someone explain to me why Haskell will ever be viable as a fullstack language? It already is. If you are talking about a full stack web application, there are several fully featured production quality frameworks, Yesod being the most popular. What are the negatives to you? Long compile times? Monadic IO? Memory leaks from lazy eval?
- lvh 11y ago
  I'm guessing the poster included being able to do front-end work in Haskell. elm and purescript might be plausible front-end languages, but ghcjs isn't really there yet.
  - kyllo 11y ago
    Picking any compile-to-JS language (not counting ES6/7) is a risky proposition though. There are a lot of people regretting their five year-old "legacy" coffeescript applications today. GHCJS is improving at an astonishing rate, but at this point I still wouldn't use any compile-to-JS language for a serious production application. There's too high of a risk of building something that becomes unreasonably expensive to maintain in a few years.
    - chadaustin 11y ago
      While I use ghcjs for one of my projects, have been a big user of Emscripten in the past, and recently switched from a CoffeeScript project to a TypeScript project at work, I understand what you're saying, but I think it's an overstatement. Compiling to JavaScript is totally okay if the new language 1) adds something meaningful (like a type system [TypeScript, js_of_ocaml] or the ability to conveniently deal with unboxed data [LLJS, Emscripten]) and 2) does not have a significant runtime overhead. GHCJS, in particular, adds a _huge_ amount of runtime overhead, largely because JavaScript doesn't (yet) support tail calls so the CPS transform must be trampolined. In addition, laziness doesn't make a lot of sense for frontend code, which generally should be as tight as possible. Also, look at the code produced by ScalaJS sometime and weep. :D js_of_ocaml, on the other hand, produces extremely tight code, and is very suitable for building web frontends. Of course, OCaml probably has a similar learning curve as Haskell. I can't imagine people would get excited about the syntax. TypeScript is a sweet spot: it's got some value over straight up ES6, but it's easy to integrate and has a very short learning curve.
sseveran 11y ago
I use it as a fullstack language at work. I bumped into the 10% when I was a beginner, but no more.
tathougies 11y ago
I use Haskell exclusively on my SaaS app (http://sostenoto.com http://sostenoto.com). The backend not only provides a simple REST API, but it also provides WebRTC signaling and a real-time graphical communications and presence protocol. Haskell makes it so easy to write correct concurrent code it's not even funny. GHC's magnificent IO manager means I can handle 1000s of connections on one amazon instance. Can't understand why you wouldn't be using Haskell for server-side web development. No other popular server-side language supports concurrency (see STM, MVar's, and Chans), transparent futures/promises for I/O (the entire IO monad in GHC is non-blocking), support for multiple processors (Just add +RTS -N<n> to make your program scale to n processors), and a blazing fast HTTP server (warp).
- andruby 11y ago
  Elixir is getting increasingly popular as a server-side language with Phoenix. It has great concurrency, futures (Tasks [0]), smp and a fast http server (cowboy [1]). [0] http://elixir-lang.org/docs/v1.1/elixir/Task.html http://elixir-lang.org/docs/v1.1/elixir/Task.html [1] https://github.com/ninenines/cowboy https://github.com/ninenines/cowboy
  - zeckalpha 11y ago
    But limited static analysis.
    - cubahacker 11y ago
      why should I want to have static analysis?
- johan_larson 11y ago
  > Can't understand why you wouldn't be using Haskell for server-side web development. I can't tell whether that's just a rhetorical flourish, so I'll answer straight. To begin with, there are a couple of concerns that might kill an attempt to use Haskell. 1. I might not be able to get management approval. Haskell is an obscure language with a reputation for difficulty. The bosses might well say no. 2. I might need to work with an existing codebase in something like Java or Python. Not possible from Haskell. If those don't kill the project, there's the cost-benefit tradeoff. On the benefits side: 1. Haskell code is very concise. (definitely) And greater concision means faster development. (possibly) 2. Haskell code is less likely to contain errors, because of very strict typing. (probably) 3. Haskell coders are disproportionately capable, because the language is obscure and difficult. (probably) On the costs side: 1. I have much more experience in other languages. It would take at least a year, maybe two before I'd be up to pro standards in Haskell. 2. The community of Haskell programmers is small. It might be difficult to hire anyone if the project grew; I might be faced with training someone from scratch, not just in a new language, but in a new programming paradigm. So, this isn't anything like a slam dunk. Quite the opposite, actually. There are a couple of issues that might nix the project right up front, and then a daunting cost-benefit calculation.
dudul 11y ago
What is the 10% that is no negative? I've been using FP for 6 years now (not in Haskell though) and never looked back.
emergentcypher 11y ago
Really? What is this 10%? We're using Haskell for server-side programming at my work and it's been fantastic. Functional programming is so well suited for stateless web services.
nickpsecurity 11y ago
"Full stack would be..." For us older engineers, full-stack was hardware up to OS up to apps. Quite a few projects did that. Haskell is more full stack via that definition given it can build hardware (Bluespec), OS's (House), system code (Ivory), and web apps. Worst case, use it as a DSL to output the language of your choosing like 4GL's used to.
bootload 11y ago
"Can someone explain to me why Haskell will ever be viable as a fullstack language?" Aside from the solid compiler ghc and many libraries, the ability to write less, more reliable software. That's the objective isn't it? Another reason is the increasing number of usable languages written in Haskell. Using say Purescript, elm or other front-end languages, it may be as important as knowing Haskell as know C is for Python, for example.

melling 11y ago

It sounds like tooling has improved but it's still the biggest hurdle for beginners: "Improving IDE support is the single easiest way to lower the entry barrier to newcomers."

etcinit 11y ago
I think stack has helped in that area. As a beginner, I found stack's ability to create a new project from a template very useful when getting started with projects. The plugins for vim and Atom do a really good job for auto-completion and showing linter/compiler warnings, but they are a bit hard to setup initially.
- bloaf 11y ago
  And they graduate from "a bit hard" to "downright painful" if you want to do it in windows. The consequences of doing it wrong can be severe[1]. [1] https://github.com/atom-haskell/ide-haskell/issues/83 https://github.com/atom-haskell/ide-haskell/issues/83
- mark_l_watson 11y ago
  +1 yes! The stack new project templates have saved me a lot of time. Stack, I'm general, is a great improvement in my device work flow.

rifung 11y ago

> The rating of the "Educational" section still remains "Immature" until this book is out of Early Access and finally released, but once the book is out I will finally mark Haskell as having "Mature" educational resources. I haven't read the book myself, but is the book really so good that we can go from "Immature" to "Mature" with the release of just one book? I find that to be a bit strange considering Haskell is a very complicated language; I have a hard time believing a single book (that is beginner friendly no less) could really explain everything there is to know about Haskell.

phamilton 11y ago
Learn You a Haskell for Great Good has been an excellent resource for the intermediate programmer. Much of the intermediate to advanced space is already quite mature. The beginner space was the big gap.
- rjayatilleka 11y ago
  Did you switch that up? Learn You a Haskell is excellent for beginners. The intermediate space is the gap.
  - phamilton 11y ago
    Beginner Haskeller, intermediate programmer is what I meant. Great for learning a new language, not great for learning a first language.
- coolsunglasses 11y ago
  Hi, I'm a coauthor of the book mentioned in the State of the Union post. The beginner parts were _a_ gap, but they weren't the only gap. In fact, none of the existing books really went very far beyond Monad, with only RWH covering monad transformers. So, part of the appeal of the book isn't just that we cover beginner topics better, we cover _everything_ from beginner to intermediate/advanced that you're likely to apply in order to, say, make a web application. And in fact, we use a micro web framework in Haskell to demonstrate stuff in the later chapters. It may not seem like it, because chapters like "data structures" actually cover - profiling time, profiling memory, containers, benchmarking, constant applicative forms, avoiding memory leaks, etc. We'll be updating the site to explain what each chapter covers in more detail soon. I've spent a couple years teaching Haskell and haven't found LYAH to set anyone up for success in Haskell. They usually hit a brick wall because they don't have either the foundation or intermediate idioms to really get anywhere. So there's usually a 45-days-in-the-desert period after LYAH where they have to muck through tens or hundreds of blog posts to plug all the gaps. I talk about this here: http://bitemyapp.com/posts/2014-12-31-functional-education.html http://bitemyapp.com/posts/2014-12-31-functional-education.h... Suffice to say, I would've happily written a much smaller, shorter book - but this was needed.

steveklabnik 11y ago

I really, really enjoy these posts. Figuring out what an ecosystem even has and it's quality can be daunting for those considering a language, and gives experienced community members and idea of what to improve.

deleted 11y ago

[deleted]

mark_l_watson 11y ago

I think that I own 7 Haskell books, and there are good parts in all of them. A few of them are great. Why all the love and strong recommendation for a new unpublished book? I use Emacs, IntelliJ, and TextMate for Haskell. I love all three. I thought the best part of this article was the coverage of libraries because I find myself to be uncertain of selecting the most appropriate ones. I use a small subset of Haskell but that works for me.

coolsunglasses 11y ago
Hi, I'm a co-author of the book mentioned. Unpublished might be a bit uncharitable, the current version of the book is 26 chapters and over one thousand pages. As for why? We make certain you actually learn everything you need to know and we _aggressively_ test and review the material with actual learners. My co-author Julie's first programming language is Haskell, which she has learned from me and while writing the book. Here's a screenshot from our Zendesk for processing reader feedback and reviews: http://imgur.com/EdpL4ql http://imgur.com/EdpL4ql We are writing the book because I've been helping people in IRC (#haskell-beginners mostly which floats around 300 users), on Twitter, etc. I saw too many people burn out and give up with the existing resources (free & paid), despite maintaining a guide for learning Haskell with free resources: https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell It's just harder than it needs to be, so we're fixing that. Even the better existing books/resources don't cover nearly enough for somebody to move on to, say, writing a web application. I wrote about the pedagogical issues with some of the existing resources here: http://bitemyapp.com/posts/2014-12-31-functional-education.html http://bitemyapp.com/posts/2014-12-31-functional-education.h... If you didn't find it difficult to learn Haskell, that's great! But most people find it intensely difficult and I think that's completely unnecessary. I've given a talk on this titled, "Learn Haskell in less than five years" located here: https://www.youtube.com/watch?v=Bg9ccYzMbxc https://www.youtube.com/watch?v=Bg9ccYzMbxc
- mark_l_watson 11y ago
  OK, I read "early access" and thought "unpublished". I stand by my minor complaint that the article was deep in praise for your book and I thought minimized the impact of the many fine existing books on Haskell. Good luck with your book. I like your enthusiasm.

fiatjaf 11y ago

I've tried many times to learn Haskell. The problem is always with setting up a compiler, getting packages, setting environment, not getting a ton of gigabytes of duplicated packages, getting useful vim support etc.

tome 11y ago
Have you tried stack? It was released about six months ago and has revolutionised Haskell's offering in this area.
- Volt 11y ago
  >not getting a ton of gigabytes of duplicated packages How does stack help here?
  - tel 11y ago
    You build against a fixed set of packages defined by "Stackage" so that you only need to build them all once. While this set evolves over time, if many (or all?) of your projects target the same Stackage LTS then you won't need to rebuild dependencies.
  - tobik 11y ago
    Dependencies are downloaded and compiled once for all your projects using the same Stackage release and are shared between projects. In the end you still might have duplicated dependencies if you use different stackage.org releases but it's a much better situation than using Cabal sandboxes where every project has its own copy of dependencies.

noobermin 11y ago

This might be a good place to ask this: if one decides to go deep into Haskell, is it a good gamble? What does the job market look like for Haskell developers?

coolsunglasses 11y ago
Speaking as the co-author of the Haskell book mentioned in the post and somebody that has used Haskell 9-5 for a couple years - you'll have more luck getting permission to trial Haskell internally than you will competing with other Haskellers for the jobs that are out there. I recommend getting comfortable with the sorts of libraries you'd use at work before trialing to avoid what fizbin mentioned elsewhere in the thread. tl;dr create, don't take, a Haskell job

bootload 11y ago

A great comparison to the above article is this post by Stephen Diehl, "Reflecting on Haskell in 2015". [0] A great read and an interesting pointer on the state of Haskell / Javascript (Elm, Purescript). Also, work your way through "Write you a Haskell", [1] well worth the effort. Going through the post, this looks like a comprehensive book. Read the rationale behind, 'how to learn Haskell' from author. [2] [0] "Reflecting on Haskell in 2015" http://www.stephendiehl.com/posts/haskell_2016.html http://www.stephendiehl.com/posts/haskell_2016.html [1] "Building a modern functional compiler from first principles." http://dev.stephendiehl.com/fun/index.html http://dev.stephendiehl.com/fun/index.html [2] "Why we don't chuck our readers into web apps" http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-readers-into-web-apps.html http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-read...

p4wnc6 11y ago

I am a beginner Haskeller maybe just crossing the border into "intermediate." What has been most frustrating for me is not really the quality or availability of books or learning materials. Instead, it has been hard to deal with the variability in the opinions of veteran Haskellers as to what it even means to be a beginner. For example, in one job interview I had, the people interviewing me (several of whom had used Haskell for 10+ years) were very impressed by simple things -- using ADTs to model a take-home programming problem; knowing about tail-call elimination and how it impacts folds and when to write something with a helper function; basics of type classes; and fluency with Monads perhaps just slightly beyond what is discussed in LYAH. In another interview, someone right off the bat asked me to explain Arrows in great detail. I admitted I didn't know anything about Arrows except that they were in some sense a generalization of the "context" view of Monads. Another interviewer once asked me frightening questions about Template Haskell and using it for SQL queries (e.g. HASQL). Yet another asked me "design" questions about multi-parameter type classes and multi-parameter ADTs. I could point out examples of the latter, like Either, and I could name-drop the idea of Phantom Types because I heard it once in a Haskell lecture, but I tried to communicate to them that I didn't have any real command over these things in a real-life situation. It's frustrating on one hand because it makes it seem like there is no path, of any kind, from beginner to intermediate. It's like a Heaviside functions or something. You are just a beginner until one day you're suddenly not. It's kind of like playing Marco Polo in a swimming pool too. One person's yelling from that corner about Arrows. Someone else is yelling about multi-parameter type class design patterns. Someone else thinks you should know Template Haskell. There's seriously no way to prioritize studying those things. If you want to go an learn Arrows, especially if you're in a geographically isolated area like I am (hence no ability to attend meetups) and you don't already have a job providing the crucible of real work to drive learning, then you'll just flounder for weeks or months with Wikibooks entries on Arrows, etc. Then somebody stops you and says you're not good enough because you don't know multi-parameter type class patterns and so now you stop and pivot to that. Maybe whack-a-mole is a better analogy than Marco Polo. Of course there will always be some corners of an ecosystem that are obscure. But the problem with Haskell is that it seems like everything is obscure and everything pulls you in an entirely different direction, and you don't understand how they are related until long after you've mastered them at an intermediate proficiency. What I'd really like to see is more of a community consensus about what it means to be "beginner" or "intermediate" or "advanced". Maybe then people who are putting up job ads for relatively junior positions or positions where they pay clearly means it's junior will at least have some community guidance for the sort of out-of-the-box recitational knowledge to expect?

hyperpape 11y ago

The author of the book mentioned has a post called: "Why we don't chuck readers into web apps"[0] that is...not encouraging. "....Understanding algebraic datatypes requires understanding products and sums. Understanding products and sums requires understanding addition, multiplication, types, cardinality, type constructors, and data constructors...." By the time I reach cardinality I wonder if maybe the author is more interested in making things sound intimidating than helping? Or will readers be quizzed on the Continuum hypothesis? "Why can’t I learn Haskell the way I learned $BOZOLANG?" ...I hope the book itself won't take this tone. The community doesn't need it. [0] http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-readers-into-web-apps.html http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-read...

coolsunglasses 11y ago
>By the time I reach cardinality I wonder if maybe the author is more interested in making things sound intimidating than helping? I'm overstating my case in that post, but underestimating how hard this currently is doesn't change that there are things you'd want to understand before diving into a Haskell web application. Part of this is on the framework designers, it's mostly/only Scotty that has made any attempt not to incorporate concepts that would be difficult for beginners and it's more "hiding" than "not using". You don't need 100% grokhood all along the way, but the current status quo is that people frequently flounder and burn out because the resources they _did_ use didn't explain things usefully or cover enough. This is not conjecture, this from a _lot_ of time spent working with people hands on via IRC and Skype and curating a popular guide: https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell >"Why can’t I learn Haskell the way I learned $BOZOLANG?" >...I hope the book itself won't encourage the stereotypes about Haskell the way this post does. The stereotype that I grew up reading c2 wiki and hacker lore? I've spent most of my career so far writing C#, VB.NET, and Python. I don't even really mind a bit of Python here and there, but I don't have much cause to resort to it any more except for Ansible. As it stands, our readers have been taking breaks from the book to successfully work on side projects starting at about chapter 9 through chapter 26. Different people find there are different spots in the book where they can step away and get things done. The point is that the rest of it is always there if they need it. Education-by-blog-diaspora has not been terribly successful for many Haskell beginners up to this point. Partly because there aren't enough people for there to be enough angles on something that beginners can reliably find something that "clicks" for them. Another problem is that you want exercises to thoroughly understand a different way of thinking about and putting together programs. In the end, it feels little different in my head than when I'm writing in something imperative, but the experience is more difficult than it needed to be for beginners for a long time. The book is me "scaling up" my ability to help people. Like it or don't, whatever, but please don't try to make a blog post I wrote into something it isn't so you can try to take me down ad hominem. >...I hope the book itself won't take this tone. The community doesn't need it. You can find out what the tone of the book is by checking out the sample provided on the book's website. No need to speculate. As it is, the tone is light but to the point. Readers have enjoyed the dry humor which is not at all like how I write on my blog. Which people have liked too. You should spend less time on HN commenting on things you don't like. I have writing to do. Goodnight.

misja111 11y ago

I like this sentence: > For a long time vim and emacs were the Haskell editors of choice. Now more traditional IDEs like Atom and IntelliJ are starting to get Haskell support

white-flame 11y ago
While vim and emacs are certainly more "traditional", they're not IDEs, and hence not "traditional IDEs". As a Lisper, I'm still stuck with emacs as the best-supported tool, and that's kind of a sorry state of things.

deleted 11y ago

[deleted]