7 ms·
I (naturally) think that the article's summarily dismissing Haskell is unfortunate. It's probably just the result of poor PR on Haskell's part. Haskell is not
by tikhonj 12y ago
I (naturally) think that the article's summarily dismissing Haskell is unfortunate. It's probably just the result of poor PR on Haskell's part.
Haskell is not only for surpassingly intelligent people, or even optimized for them. If anything, it's the opposite: one of its core tenants is that we're not smart enough to reason about our programs in most languages. Much of the design work focuses on unloading complexity into the language, tools and abstractions.
Haskell goes out of its way to prevent common errors and help you design your program. In a very real sense, it trims the "search space" of possible programs, helping you zero in on a reasonable solution. To an extent, I use Haskell because I'm not smart enough to use C.
Haskell is unfamiliar. And people mistake that for some sort of innate difficulty. But the two are not the same.
I would argue that overcoming unfamiliarity is one of the most important ways to grow as both a programmer and, more generally, a person. That's why I think the article focuses too much on choosing a language that's familiar, codifying it as "just about all the good advice". This mindset is far, far too exaggerated in most programmers, and its what really slows down progress, especially for popular programming languages.
The blub paradox is also a bit misrepresented. Being a "blub" programmer is not a matter of being more or less intelligent—it's a matter of not knowing what you're missing. "Beating the Averages" is not "we used Lisp because we were smarter than you"; it's more like "we used Lisp because it offers some incredibly powerful tools that non-Lisp programmers have never used and so do not really appreciate". It's a matter of habits and experience, not intelligence.
My advice? Do try something unfamiliar. Especially if it seems to be higher in the great partial order of programming language power :).
- cageface 12y agoMany of the brightest programmers I've ever met have struggled to get their heads around Haskell. Enough of them that I don't think it's really a PR issue or a lack of good introductory materials. I'm wiling to take the claims on faith that Haskell's design eliminates a lot of common programming errors but I've been listening to predictions of Haskell's emergence into the mainstream for almost 15 years now and, from where I sit, I have to say it's never going to happen. I used to be a bench chemist in a pharmaceutical company and the tools we used to develop new drug candidates and the tools we used to put them into mass production were radically different. I don't see why software should be any different. Let Haskell be the proving ground for new ideas and we can cherry pick the best ones for simpler languages later.
- vishnugupta 12y ago> I used to be a bench chemist in a pharmaceutical company and the tools we used to develop new drug candidates and the tools we used to put them into mass production were radically different. I don't see why software should be any different. Let Haskell be the proving ground for new ideas and we can cherry pick the best ones for simpler languages later. This is a very interesting observation. I would hazard a guess that Phil Wadler developed (or at least significantly contributed to proving type-theoretic soundness of) Java Generics and Collections after they sort of proved their worth in Haskell world. Same with Lambda which made its way to Java 8. STM is perhaps next.
- jacquesm 12y agoI don't think the credit for the java implementation of 'Lambda' should go to Haskell pioneering it and proving it useful. First class functions were present in lots of other languages, most notably the lisp family long before.
- seanmcdirmid 12y agoGenerics also were not a new idea back then...and let's not forget Gilad and Martin, whose backgrounds weren't haskell.
- campezzi 12y agoDo you recommend any framework for Haskell web development? I really liked toying around with the language, but I hit a brick wall when trying to build something "real" with it - it's hard to find decent guides that made the jump between the basics of writing functions, using recursion, etc and using the language on a full-on application. Given I have been working with web development in Ruby and PHP for years, I would love to find a nice "getting started" guide for a good/well established Haskell framework.
- psibi 12y agoI have been using Yesod in my day job with great success. It also comes along with a free online book: http://www.yesodweb.com/book http://www.yesodweb.com/book Other popular alternative is Snap framework.
- platz 12y agoHappstack and Scotty are probably a little simpler for getting started imho
- pron 12y agoI think Haskell underestimates people's intelligence when it comes to things like mind-simulating state change in simple subroutines, and overestimates it when it comes to understanding lazy evaluation and monads. Humans had built useful structures long before they've been capable of rigorous abstract thought. How? By trial and error. Most people find it easier to learn how to catch a ball by practicing rather than by calculating its trajectory. I'm not saying that is always the right approach, but it does come more naturally to the human brain. Haskell discounts the very useful choice of reasoning about your code after it runs, favoring, instead, all-upfront reasoning, often at the expense of facilitating the former. There are some domains where figuring everything up front is very important. Others, where trial and error is far more productive. Trying unfamiliar things is very good advice, but not for an important project you want done relatively quickly, and which you'd have to maintain for years to come.
- knappador 12y agoPass in requests. Get responses back. Same input, same output, except for potentially dirtied DB hits. This is somewhat of a good fit for a functional language program that just handles request after request. For API's Haskell might be a great fit. For server-side rendering of fat web clients, I don't see any way around node.js and my resentment of javascript without doing some impressive design of the client to be able to reinitialize itself from a JSON that pops out of the client state in the host language. It's possible, but I'm too busy with Kivy to mess with web development atm.
- knappador 12y agoWhoops. MySQL. Nevermind. Everything is happy, everyone. I'll be going on my way now. Nice chat.
- jcromartie 12y ago> Haskell discounts the very useful choice of reasoning about your code after it runs Huh, I have never thought about it like that. Thanks.
- lmm 12y agoI have little to add, but I'd make a similar case for Scala. If you're tied to the JVM or existing code, or don't want to make the leap to laziness/purity/immutability for everything from day 1, Scala can be a smoother way to learn these new concepts (which will ultimately make you more productive whichever language you use). (And if you're going to use Play, Scala is very much the best way to do so)
- arethuza 12y agoOut of interest, what would you say are the kinds of bugs that using something like Haskell helps you avoid? I've had a look at Haskell before and while all the individual parts looked reasonable I struggled to understand both what an application would look like at a high level and what the inherent advantages are (not saying there aren't any - just that they didn't jump out to me). In most languages I have learned I've generally reached a point fairly quickly (without hours) where I've thought "wow - this is cool!" and this is generally because of enabling me to do something more easily than in other languages - I've never got to that point with Haskell. Note - this is just my own observation, not a criticism of Haskell or any of the resources I have used to try and learn it!
- zimpenfish 12y agoFrom my experience, using Haskell avoids all bugs because you'll never get anything deployed to production what with it being intractable murk.
- rfergie 12y agohttp://programmers.stackexchange.com/questions/215482/what-are-the-safety-benefits-of-a-type-system/215483#215483 http://programmers.stackexchange.com/questions/215482/what-a... has a good list of the type (no pun intended) of error that type systems can prevent
- tormeh 12y agoThe problem with Haskell is its syntax. Too many arbitrary and traditionless things to memorize. It's curious that the Haskell developers try to one-up the rest of the language space in nearly every other space, but choose such a weird and unhelpful syntax. Look at Python: The only reason people started to use it is because of the syntax. Now it's slowly eating Matlab and R in science - two specialized languages beaten in their own domain by a general purpose one because the general purpose one has nicer syntax. How great wouldn't it have been to have a Haskell-like language with a Python-like syntax? But no, Haskell needs a "first-class syntax", as if keystrokes are the limiting factor in development.
- mercurial 12y ago> The problem with Haskell is its syntax. Too many arbitrary and traditionless things to memorize. It's curious that the Haskell developers try to one-up the rest of the language space in nearly every other space, but choose such a weird and unhelpful syntax. I've seen this criticism before, and I don't understand it. The syntax of Haskell is not that big. There are some things a bit funky about it, especially the indent rules, but I don't see what there is to be mystified about. On the other hand, it does introduce a lot of mind-bending concepts if your background includes imperative programming and no category theory, and that's typically what people find hard to grok. You don't find a pile of "Haskell syntax cheatsheets", you find a bunch of monad tutorials instead.
- tormeh 12y agoYeah, but if the monads were the only problem it would be ok (for me at least). But I'm asked to learn monads while also learning this weird syntax. I'm asked to learn something I don't understand in a syntax I don't understand. It's a bit too much. Like a math lecture in which, aside from the new concepts, the lecturer has decided to replace the traditional symbols (+,-, etc) with his new and equally arbitrary ones (¤, @). Except, of course, that Haskell's syntax is often more arbitrary than its competitors.
- mercurial 12y ago
- zerr 12y agoAfter fairly long time playing with Haskell, I find it quite beautiful and pleasure to use, but only for theory/book-ish use cases. As for real world usage - it is quite ugly and cumbersome, e.g. when you need some error handling and multiple monads using (with transformers), etc... Another quick way to measure this - compare that beautiful pseudo quick sort to real quick sort (e.g. using Array.ST)...
- mercurial 12y agoI have to say that I agree with you. In principle, I find the notion of an effect system extremely powerful, both for safety and optimization, but Haskell's way of intermingling effects using monadic towers is terribly awkward and cumbersome, not to mention that it comes with a mental cost.
- mtrimpe 12y agoI'm all for trying something unfamiliar, and I could even argue for Haskell that way, but from a different angle. I would say that adopting a language for the next 10 years that doesn't have purely functional data structures at its core is a fool's errand. Persistent data structures, i.e. efficiently storing every version of your data structure, is the natural reflection of the new reality in computing where: * storage is cheap * random reads are cheap * random writes are expensive * serial writes are cheap Whether you adopt this through Haskell, Clojure, scala or even Bloom e.a. is fairly inconsequential. What will matter is that persistent data structures will inevitable become commonplace over the next decade and that techniques for leveraging it (such as functional reactive programming) will be adopted in one form or another. @jacquesm: I live in Amsterdam so I can try to explain it to you in person once; virtually everyone still underestimates the impact this will have and (or perhaps because) it's very difficult to get that across in writing.
- jacquesm 12y agoLiving in Romania right now, but I'll ping you when I'm back in NL (I go there at least once every few weeks), Clojure seems to be the most approachable from the languages you list. Besides your listed reasons mutable state is becoming a bigger and bigger bottle neck as the number of cores goes up and that's why functional programming is becoming more and more important. It also makes programs much harder to write in a bug-free manner and it makes testing much more difficult (if not impossible). It's one of the core reasons why I felt so bad about dropping Erlang from the list because I feel that it gives me that plus a battle tested environment to work with. Still tempted to put it back in. Your reasons add weight to an already very difficult decision, whether or not to pursue this opportunity as a way to get more into functional programming or to stay in my 'comfort zone'. I've been toying around with FP on and off for the last couple of years and it is one of the most important revivals the computing world has seen to date (imo of course).
- lmm 12y agoThis may be my biases speaking but I'd say Scala is a more approachable option than Clojure (and more popular, and has a first-class web framework in Play). It keeps more of the traditional OO style and syntax - you can use scalaz and write scala that looks like Haskell, but you can also write code that corresponds line-by-line to java, whereas with Clojure you're forced to make a more immediate leap to the lisp-style syntax, immediately stop using inheritance, and so on.
- ahuth 12y agoI disagree. Haskell is unfamiliar, AND it's difficult. They're separate. In any case, I'm definitely not smart enough to use it. The issue isn't functional programming, though, which is why Elixir looks very interesting.
- dllthomas 12y agoI also think "it shines in finance" is a little weird. It's used in finance because it's an industry with a premium on correctness and a sympathy for math, but I don't think it's generally better suited to solving those problems than to solving other problems. If I had to point to one area that Haskell is clearly better at than "mainstream" languages it would probably be tree manipulation - and as a consequence compilers - due to structural pattern matching (for small stuff) and evaluation strategies (for larger and more abstract stuff).
- cgag 12y agoI love Haskell because I don't have to depend on my working memory. It's so nice to have the compiler tell me everywhere some type I've changed is used, or places I've forgotten to consider possible values.