13 ms·

Why hasn't Haskell taken over the world? And the curious case of Go

130 points by atombender 10y ago

evincarofautumn 10y ago
A programming language doesn’t need to “take over the world” to be successful. Nor does it even need to be “the best”, just serve a niche, as the article goes into. Haskell is the best language I’ve found for the software I write, so I use it. If other people aren’t using it, then I figure they have a good reason, or it’s their loss.
mark_l_watson 10y ago
Haskell is one of my favorite languages and just wrote a book using Haskell (you can read it free online: https://leanpub.com/haskell-cookbook https://leanpub.com/haskell-cookbook ) That said there are a lot of tasks that I use Ruby for (text wrangling), Python (machine learning), and Java (huge number of useful libraries). I use Haskell for NLP, some web apps, and coding algorithms that don't require libraries that aren't available for Haskell. If Haskell had a huge set of 3rd party libraries like Java, then I would probably use it for most of my development.
- innocentoldguy 10y ago
  Haskell Tutorial and Cookbook is one of the two books I've been using to learn Haskell (the other one being Haskell Programming, by Christopher Allen and Julie Moronuki). Thanks for the excellent book!
  - codygman 10y ago
    Those two books sound like an excellent strategy.
  - bubblesocks 10y ago
    I can vouch for Haskell Programming, but I haven't read the other book. Thanks for the recommendation.
- zigzigzag 10y ago
  I'll be interested to see if Eta takes off more than Frege. It seems like a good way to get haskell+java libraries together.
acchow 10y ago
Who says Haskell is so great? What does "better" even mean?
- allengeorge 10y ago
  From what I've inferred from the article "better" means: easier to write large-scale, composable systems that engineers can reason about easily.
  - _yosefk 10y ago
    It doesn't seem easy to reason about the performance of a program under lazy evaluation. Generally there are many aspects of a system that you may want to reason about, and making it easier to reason about one often comes at the expense of making it harder to reason about another. Pure functional code, for example, makes it easy to reason about what outputs are produced from what inputs, but that is one (important) aspect among many (and to take one thing that's really simple without purity and really tough with it - consider "pure functional data structures" vs data structures in imperative languages assuming a mutable RAM.)
    - solidsnack9000 10y ago
      Laziness is a real problem for reasoning. Reasoning about pure functional data structures in the absence of laziness isn't that difficult, any more than the many mutable data structures that have copying/rebuilding/rebalancing that takes place only sometimes. The benefit of pure functional data structures is most visible when there is some kind of sharing -- concurrency of some kind -- in which case, reasoning about side effects becomes more difficult. There are good approaches to handling in-place array update and similar operations in pure functional programming (the ST monad, for example), it's just not the default. As long as the side effect is somehow accounted for in the return value, referential transparency is maintained; we might say the return value is there to help us reason about side effects.
- ExpiredLink 10y ago
  A higher peak in the hype cycle.
innocentoldguy 10y ago
I completely agree with the heart of this article, and its reasoning for Go's popularity (e.g. familiarity for people who know languages like C and Java). It speaks to my experiences, anyway. I went down the Go path myself for a while, because it was familiar, but I found that it had many of the same issues I was trying to get away from in other languages. As the article points out, I also found Go "boring." After searching for a while, I ended up wanting to use Haskell, but it was taking me too long to become proficient with Haskell's unfamiliar syntax and functionality; which is why, the author posits, Haskell hasn't taken over the world. I ended up using Elixir instead. It offered me the functional paradigm I was looking for in Haskell, and the ease of managing large-scale applications, while also offering a familiar and easy to learn syntax. I'm still studying Haskell, and may eventually employ it professionally, but for now, Elixir is working for me just fine.
- sudshekhar 10y ago
  Are you using the above languages for your day to day job? Or are you working on your own side projects? If the later, can you give some examples of the things you're building. I've tried learning them several times, but mostly stop after finishing the basic syntax :/
  - innocentoldguy 10y ago
    Hello, sudshekhar, I am not using Haskell in my day to day job, yet, but I am using Elixir, and have been since last April. For learning Elixir, I highly recommend Dave Thomas' book Programming Elixir, The Little Elixir & OTP Book, by Benjamin Tan Wei Hao, and the website https://www.learnelixir.tv https://www.learnelixir.tv. You may want to start with the website and jump into the books afterwards. I learned with the two books, but one of my co-workers started with the website, and said he found it quite helpful. I watched the tutorial videos after the fact, and they are quite good. The website https://www.dailydrip.com https://www.dailydrip.com also has a lot of Elixir tutorials (similar to Avdi Grimm's website, Ruby Tapas), but you have to be careful because the older videos contain descriptions of features that are deprecated. I wouldn't bother with Daily Drip until you have a solid foundation in Elixir, and can pick around the deprecated bits. The later videos on Daily Drip are up-to-date though.
verletx64 10y ago
In the end, Haskell's ramp up time (to be productive) will slow it's momentum, and I feel that's with all languages with a ramp up time. Most popular languages have a pretty low ramp up time, and part of that is business concerns (getting a whole team to being productive in a language with a long ramp up time takes...well, time, and it's rarely the right option to have them make that transition), but also the personal, human side of it - we suck at being bad at things and the experience of it is hard to push through for people. Actually, jumping back into mathematics outside of work, I'm having to go through this period of uncomfortable 'badness' and resisting my urges for the greater good. It is emotionally taxing to be 'bad' at something. I think that's part of why we favour languages that allow us to be productive quickly, despite it probably paying off in the long run. I wouldn't do it with everything (you need quick wins _somewhere_) but it's a good skill to have, to be disciplined and persevere despite what your heads saying. I'm no psychologist though, so this is largely conjecture and anecdotes.
phs2501 10y ago
I kind of like Haskell, but the learning curve is brutal and the documentation is often intensely non-helpful if you don't want to learn a whole lot of mathematical terms. i.e. when browsing and trying to understand parts of the XMonad code, I came across the "Endo" type. I Hoogle'd it, and the only documentation for it is "newtype Endo a: The monoid of endomorphisms under composition." Thats.... not helpful for me.
- evincarofautumn 10y ago
  The biggest thing missing from Haskell docs is examples, I find. The mathematical language is tempting when you’re writing docs, because it’s succinct and precise, and can say a lot about how something’s implemented: -- Endo is… newtype Endo a = Endo { appEndo :: a -> a } -- ^ -- | -- …the monoid of endomorphisms… -- | -- V instance Monoid (Endo a) where mappend (Endo f) (Endo g) = Endo (f . g) -- ^ -- | -- …under composition. mempty = Endo id But not so much about how to actually use it: -- If you’ve got a list of functions… pipeline :: [Int -> Int] pipeline = [(+ 3), (* 2), abs] -- …you can compose them with the generic mconcat. run :: [a -> a] -> a -> a run = appEndo . mconcat . map Endo run pipeline (-1) == 5
  - stcredzero 10y ago
    None of that helped me understand anything.
    - catnaroek 10y ago
      “Endo” is a type constructor for functions that have the same domain and codomain, so if you have two values of type “Endo Foo”, for any type “Foo”, you know that they can be composed in either order. That composition of such functions is associative and has an identity, I hope it isn't necessary to explain.
      - 10y ago
Shank 10y ago
You could ask a similar thing to any functional language. The internet has a very wide variety of introduction points to imperative languages, and quite a bit fewer for functional languages. This means that the barrier to entry isn't just "can learn a language" but the vast majority of the time, you have to convince programmers who already know another language to adopt a new one (and in an entirely new design paradigm than they're familiar with). Functional languages have to be penetrable to newcomers and offer huge benefits to veterans to switch, or they're going to remain nearly esoteric. Is mathematically provable code nice? Sure is. Is that enough to win people over? Well, language adoption says otherwise.
- Kenji 10y ago
  It has nothing to do with newcomers or skill or any of that. Often, we need to make computers do a list of things. Conditionally, sometimes, but nevertheless, a list of things. This is human thinking. A C function is nothing other than a list of things the computer does, one by one. Functional programming essentially throws rocks into anyone's way who thinks like this (which is pretty much everyone) and makes everything unnecessarily complex. There are few areas where functional programming is great, parsing and compilers come to mind. Other than that, in my eyes, it is mostly an academic pursuit.
  - stcredzero 10y ago
    Often, we need to make computers do a list of things. How often do we need to do those things in a specific dependency order? How often do we need to simply get those things done, regardless of order?
    - douche 10y ago
      All the time? Human beings, on average, are more apt to think imperatively by default than otherwise, unless they've been explicitly trained to think otherwise.
sandhundred 10y ago
I struggle with this. After years of studying OO and design patterns in Ruby and JavaScript I was having troubling building complex asynchronous systems and stumbled into Go. I saw the value of types for managing that complexity and the runtime for supporting asynchronous primitives, but internally was very limited by the lack of generics for things like collections and higher order control flow for things like error handling. Eventually I arrived at Haskell after strongly considering Clojure, and I'm very happy about what I've learned and my new way of approaching programming complexity. Unfortunately there is nowhere else to go from here since I can't find employment as a Haskell programmer. OCaml, F#, Scala, Elixir, and Elm all feel like a step back. Now I'm a Java programmer and quite miserable. I feel hampered by the language nearly everyday in terms of how easily I can express my thoughts in code. Haskell isn't perfect but is the best fit for my mathematical mindset. I am trying to lead by example. I help host my city's Haskell meetup and contribute to a Haskell reading group. The path is lonely, my co-workers poke fun at me, and don't care to put in any effort to understand what I have to say. I love teaching and explaining things but there is zero interest because the machine keeps moving. Not many at the office even enjoy Java but are resigned to do it for our large pool of enterprise clients. All in all each work day is a void I put 8 hours into, which is fine, compared to most working conditions; it causes no suffering beyond the lacuna. I'm past the stage of trying to convince other programmers anything. I recognize many are happy with their tools. I yearn for that happiness and don't seek to spread my misery. I offer my time to those who are interested and want to learn more. Anyway, this article nails it, Haskell has advantages but they aren't enough to change things without the infrastructure the author is building. I look forward to being an early adapter of Unision and continue to remain hopeful for the future despite the long odds.
- Kenji 10y ago
  I have two questions for you: - How does Haskell fare with large projects that use APIs that are inherently stateful, like OpenGL? Don't things get messy and ugly as the pure world of Haskell is being tainted? - How do I optimise Haskell code without having studied the language for decades? I had a lecture where we were taught Haskell, so I know the language, but darn, even a simple hash map seems to be so very complex in the language. The fact that everything is a linked list (bad for caching & performance) and everything gets copied around really turns me off.
xyzzy4 10y ago
Haskell doesn't make it clear what things will process the fastest. For example in Java you can use hashmaps or arraylists depending on the situation and it is easy to optimize for run time. But I'd have no idea how to do this in Haskell.
- catnaroek 10y ago
  Efficiency is a matter of using appropriate data structures and algorithms for your problem, regardless of the programming language. Unfortunately, pervasive laziness is a serious disadvantage here. (But being functional is not.)
stonogo 10y ago
Because the entire programming model breaks down at I/O. When you have to compromise the language's _raison d'être_ to perform a basic function of the computer, the cognitive dissonance is real.
- tene 10y ago
  I don't want to be excessively dismissive, but I'm curious if you have a more-precise explanation for why you think that Haskell's programming model "breaks down" at I/O? I'd say that one of Haskell's entire purposes as a research language has been exactly about modeling, reasoning about, and representing I/O and other sorts of effectful computation in the type system. Unless I've misunderstood you or there's something more subtle you're referring to, I don't follow what you're trying to say here.
- douche 10y ago
  This is what always fucked me up with Haskell. To introduce printf debugging, you get sucked into the morass that is the IO monad, and all the clusterfucking that involves.
  - tene 10y ago
    You don't need IO at all for printf debugging. Just call trace or traceShow. https://www.stackage.org/haddock/lts-7.16/base-4.9.0.0/Debug-Trace.html https://www.stackage.org/haddock/lts-7.16/base-4.9.0.0/Debug...
    - douche 10y ago
      Apparently things have changed since 2007... Or else my Ivy league CS professors didn't know what the hell they were talking about. As I grow older and more cynical, the difference between those options continues to narrow...
      - TheCoelacanth 10y ago
        I wouldn't be surprised at all if Ivy league CS professors didn't have in depth programming knowledge. They are Computer Science professors after all, not programming professors.
hacker_9 10y ago
Main reason I don't make the jump into fully functional language, is the difficulty of refactoring. It's nice if you get the program structure right first time, but of course that doesn't happen and so the inability to easily pivot makes me stay away. saying that, I do get hit by bugs that come from state, and each time I wished I'd used the functional approach, but it's not enough of a reason to make me switch.
- nbouscal 10y ago
  That's… exactly the opposite of my experience, and that of every Haskeller I know. Refactoring is 100x easier in Haskell than any other language I've worked in.
  - izacus 10y ago
    What was the biggest and oldest codebase you worked on?
    - nbouscal 10y ago
      A few years and maybe ~50k lines of code, iirc. I've heard the exact same reports from people who work on multi-million-line Haskell codebases, though (e.g. Standard Chartered).
  - preordained 10y ago
    100 times easier than right-click refactor in a modern Java IDE? I beg to differ--if we are talking about your typical Haskell vim/text editor rig. For a language with such powerful types, it's like a gun with no bullets lacking a good IDE to take full advantage.
    - nbouscal 10y ago
      I've never used a modern Java IDE (as I've been fortunate enough to never have to program in Java), but still feel confident in the claim that refactoring Haskell is 100 times easier, yes.
stcredzero 10y ago
And so the history of programming has been a series of advancements in both removing barriers to composability, and building new programming technologies that better facilitate composition. This is like saying that the history of architecture has been a series of advancements in reducing the cost of structures. This is the fallacy of narrow focus a single sexy metric. (See below.) Stage 4: Composability is destroyed at program boundaries, therefore extend these boundaries outward, until all the computational resources of civilization are joined in a single planetary-scale computer Smalltalk tried to do this with the Image, which contained everything within it, including compiler, source control, and development environment. (Smalltalk started out as an Operating System.) However, what this actually did was to sequester the community in the boundaries of the image while the rest of the programming field was busy building varied forms of infrastructure to allow interaction. I think this hypothesis also offers an explanation for why Go is popular, even though the language is “boring” and could have been designed in the 1970s. Java won over Smalltalk because the Java community understood much better how to win mindshare. Ruby took over Smalltalk's pure object schtick because it could play nice with the rest of the programming world, and it had a killer app in Rails. Go wins because it is exceedingly well designed for convenience in a myriad of ways where other languages drop the ball. You can have very fast incremental compilation in C++, if you are careful. In Go, it just works. You can have a good deployment process with Java, if you are careful. In Go, it just works. You can have easy to use concurrency in other languages, like C#, provided you find and learn the correct libraries. In Go, it's baked into the language, and people can learn how to use it competently with about as much effort as learning how to implement FSM using switch{}, and very good documentation and tutorials are dead easy to find. A Lamborghini is way faster than a Corolla. A Ford F300 can haul many times more groceries. A Corolla doesn't have remotely near the potential for track day fun as an Ariel Atom. The above 3 qualities are sexy metrics, but in terms of overall utility and convenience for the largest number of people, for the most favorable cost/benefit, the boring old Corolla kicks butt. (That said, I'm pretty sure that someone can figure out how to disrupt programming in the way that companies like Tesla are poised to disrupt the above story. It might well be a "boring" version of functional programming that has many "just works" qualities.)
montanonic 10y ago
Honestly, I think for a lot of people who've used both Haskell and Elm, the answer is pretty clear: lots of Haskell in the wild can be very hard to read and think about, even with significant time invested in it; and when it simple to read, it's likely not using many more features than Elm is. Yet, even with a very strict subset of its features, it is a very expressive language: sum and product types are an incredibly powerful concept; I'm blown away by how much more straightforward managing state is with them. Expressive types and superb type inference generally make refactoring a breeze. There are just many huge wins overall. But you can have the bulk of these wins in a simpler language like Elm, or a language like Rust which tries to only add more type complexity in cases where it would significantly improve code in practice, rather than in theory. Haskell is necessary; it pushes the state of the art forward because of how experimental it is (compiler extensions). But it's pretty clear that the community is skewed towards research rather than industry, and culture strongly influences what a language is practically capable of. This does not at all mean that Haskell isn't fully capable of industrial applications; we have direct evidence suggesting otherwise. But with a philosophy to "avoid success at all costs", it should be fairly clear that moving out of the realm of obscurity isn't exactly a goal of the language.
- deleted 10y ago
  [deleted]
mcphage 10y ago
The gain from composition isn't that it's easier for our brains to comprehend; lots and lots of tiny pieces are often harder for our brains to understand than a much smaller number of larger pieces.
nabla9 10y ago
Haskell is pure functional language and it enforces purity. Haskell did not take over the world for the same reason as pure OO programming, pure logic programming, pure relational databases, or pure anything never took off. Programmers have impure toughs.
- insulanian 10y ago
  We have dirty thoughts... Never thought about it that way :)
alkonaut 10y ago
Ask yourself this: are/were the designers of Haskell aiming to create a popular/widespread language? No. They were not. Quite the opposite. They have succeeded well in their aim to keep it s niche language. Perhaps a more reasonable question is why F# isn't eating C#'s lunch.
tikhonj 10y ago
One critical assumption behind discussions like that is that popularity is strongly correlated to quality. But that just doesn't seem true in practice—popularity is the result of complex social dynamics and isn't strongly correlated to any intrinsic qualities of whatever becomes popular. We come up with compelling narratives about whey one thing gets popular and another doesn't after the fact, but these are just rationalizations; we can't use them to make good predictions and they do a poor job of representing the social processes involved. We can see this in a microcosm when we consider music. What makes music popular? To a large extent, it's music that's listened to by the right people at the right time—perhaps seeded intelligently with exposure and marketing. There are some minimal bars the music itself has to pass, of course: it can't be terrible and it has to be accessible, but those aren't high bars to clear. There are thousands of bands as good or better than most of the ones you hear on the radio but they don't get anywhere. You just never hear them, or they never catch on among your friends and never make inroads into your social network. (Or, more importantly, into the social networks of the labels that push music in practice.) Unless they do, in which case you have some unknown band "going viral"—virality says a lot about how something spreads and little about the thing itself. It doesn't even matter what you mean by "better": some objective notion of quality, musical sophistication, aesthetics, "catchiness", pertinent lyrics... whatever. That's not the main driver of popularity. Nautilus had a great article[1] about this a while back, based on some experiments run with music. They created several large groups of participants listening to the same set of 40 musical tracks over time. People in the control group listened to music independently; the other groups all had social feedback mechanisms within the groups. The results were all over the place: the popularity of songs was completely inconsistent across groups, and could be traced to early chance decisions that snowballed over time. The article had a great analogy about how the whole process worked: > …a single match is not the entire reason for a wildfire starting and spreading. But that’s exactly how we naturally think about social wildfires: that the match is the key. In fact, there are two requirements: a local requirement (a spark), and a global requirement (the ability of the fire to spread). And it’s the second component that is actually the bottleneck: If a forest is dangerously dry, any spark can start a fire. Sparks are easy to come by, and are not intrinsically special. The programming language in question? Its qualities? Pragmatism? Purity? Elegance? All just sparks. Which one starts the biggest fire depends far more on its context than the spark itself. [1]: http://nautil.us/issue/5/fame/homo-narrativus-and-the-trouble-with-fame http://nautil.us/issue/5/fame/homo-narrativus-and-the-troubl... (The article was written by a researcher in the field and cites a few papers on the topic, if you want to read more.)
Animats 10y ago
Go is successful because it's exactly what Google needs to write back-end code. It's (almost) memory-safe. It comes with a set of well-debugged libraries for doing most of the things you need to do on a web server. That's good enough for most web-related work. From a language theory perspective, there's a lot to criticize about Go. The "goroutine" and "channel" thing turned out to be less useful for general concurrency than expected. But it's good enough to service lots of network connections. The lack of generics means that functions like "sort" are painful. But you can still get sorting done; it's just clunky. Haskell hasn't taken over the world because it's designed by theorists for theorists. It's too clever, or, "l33t", like LISP. Also, anything interactive is dominated by I/O, while the functional model is better matched to pure computation. The IT industry today is mostly I/O dominated interactive applications. (It's not clear yet if Rust is "too clever" for widespread use. The jury is still out.)
- bsaul 10y ago
  I agree on the general point that go is simple and familiar, but it's absolutely not memory safe ( and as you said, channel is really not working as well as expected in practice, unless you start using them as actor mailboxes, which i don't think was the original point). Actually, seeing all those panic on null pointers was really my first surprise when i started coding in go ( and really first disappointment).
  - kazinator 10y ago
    Panics on null pointers don't indicate that the language isn't memory-safe. Lack of memory safety means that misuses of memory go undiagnosed, with unpredictable results. (Not to mention that they are allowed in the first place, with features like arrays that blindly allow oout of bound access.) A null pointer indicates a memory problem only if it is the field of a memory object that was wrongly overwritten with zeros, giving rise to the null value in an invalid way. If the null value was correctly assigned, then it isn't a problem in the memory safety category. If Go diagnoses all null pointers with panics, that makes it safer than C, whose implementations require on the virtual memory hardware to catch null pointers. An expression like ptr->member in C will onlyl segfault on a null ptr if the member displacement is within 4096 bytes, or whatever is the virtual memory page size. If memb is offset beyond the unmapped zero page, then some memory is silently accessed or overwritten. Not to mention that on systems without VM hardware, ptr->member just silently works when ptr is null, for any struct type. I don't program in Go, but as far as I know, panic is a kind of high level exception handling feature in Go. So it sounds like you should be able to write Go code which expects that null pointers will occur in some object field or parameters, and just use panic/recover to trap it all in one place instead. In C, you would need platform-specific coding to do anything similar, like catching a SIGSEGV in POSIX or a structured exception in Win32. Yuck!
deleted 10y ago
[deleted]
zzzcpan 10y ago
Well, every language is a product that has to compete with other languages. Nothing to do with composability or advancements in out-of-touch research areas. And these days languages compete on a lot of things, on performance, reliability, security, productivity, on syntax, on tooling, on libraries, on deployment and supporting infrastructure, on interoperability. Syntax is not even that big of a deal, it's not hard to compete on it, you can just take Go's approach or you can do it thoroughly and properly, not forgetting about newcomers, their likely previous experience and designing the whole learning experience into the language too. You can't leave it as is though or it's going to be a huge disadvantage.
elihu 10y ago
As someone who has done a lot of programming in Haskell, I'm glad to see that the limitations of composability across program boundaries is being recognized as a problem. (And it may be a problem that Haskell can't fix without some help from the operating system.) When you have to convert data to type "String" in order to send it over a pipe, and then convert it back in the receiving program, that sort of defeats the purpose of having a strong type system in the first place. Similarly, if you have a bunch of processes, each with their own IO Monad interacting with each other, it starts to have an uncomfortable resemblance to the shared mutable state that Haskell tries so hard to avoid. As for the question of why Haskell isn't more popular, there are a lot of possible reasons. GC overhead and less control over memory layout makes it less performant than C/C++ and not really suitable for real time tasks. Some algorithms are hard to express without mutation. (The ST Monad is usually appropriate for those cases, but it's kind of cumbersome to use.) Laziness makes memory and CPU utilization hard to reason about. The learning curve is very steep. There aren't many books on "advanced" Haskell programming, or writing system software in Haskell. One of the things I really like about Haskell is that you never stop learning new things, and new abstractions and libraries are being invented all the time. After 25 years or so, we're still figuring out new ways to program in Haskell. This has a couple of unfortunate side effects, though. One is that programmers can become distracted from the task at hand and direct all their effort at figuring out a better abstraction to solve their problem. A lot of great things come out of such work and sometimes it pays off it terms of productivity, but I think the common criticism that there isn't enough practical, "boring" software being written in Haskell is justified. Another problem is that it's hard for Haskell programmers to communicate with each other or understand each other's code when they haven't learned or are comfortable with exactly the same set of abstractions. I do think Haskell is on to something good. I don't expect Haskell to take over the world, but I think in a hundred years people will look back and say that ideas from Haskell were a major influence on later languages that were more popular. Learning Haskell is probably a good way to prepare for languages of the future that haven't been invented yet, in the same way that learning Smalltalk would have been a good way to prepare for the object-oriented languages that came after.
harry8 10y ago
New language to learn? Write a toy. Spend more time on that toy than it warrants, re write it and someone else find it useful or fun. These programs are almost wholly absent in Haskell. List all the programs used for something that isn't writing code that were written in haskell. Xmonad Pandoc Git-annexe maybe ... And. Please really do add to this list, its length is informative and tells us something about haskell's strength and weakness.
- codygman 10y ago
  > List all the programs used for something that isn't writing code that were written in haskell. As smugly as possible and with a huge grin: Purescript Some I can think of off the top: - PostgREST - hoodle - Microsoft Bond - git-annex - darcs
  - harry8 10y ago
    So you don't use purescript for writing code according to your definition? Ok. Anyway, that aside the haskell pushers out there really need to address why there's so very little in the way of application written in haskell. The article notes that haskell is used very successfully for compilers. The number of successes elsewhere is very, very much smaller. Why? It's important not to just yell "rah rah" but actually analyse it as a problem and maybe, just maybe, you know, solve it.
    - nbouscal 10y ago
      Haskell is used successfully in industry, e.g. at Standard Chartered where they have >1MM lines of Haskell in production. Take a look: https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry
    - shae 10y ago
      Anecdotally, I see much commercial and personal use of Haskell. Have you looked at the other comments in this thread? Alternatively, why do you think there aren't small fun toys and/or commercial usage of Haskell?
88e282102ae2e5b 10y ago
It's like I accidentally stuck my hand in a running blender and someone asks whether I'm angry because of the noise of the motor or because the buttons aren't arranged in a reasonable order. I tried learning about Haskell just so I could understand a flurry of articles I came across that were trying to explain monads. But mostly I found super abstract notation, something about bind and unit and >>=, and I came away just feeling dumb. I gave up pretty quickly, but to be fair I suppose I wasn't super motivated to work through it. Later, I learned Rust just for fun. Options? Sounds like a good way to express uncertainty about a function call. Oh, and you can compose it with other Options using this function called and_then(), and things will short-circuit if they fail. Neat! A year later I find out I had been productively using monads the whole time without even knowing it. It's so frustrating knowing how easy it could have been to learn this concept explicitly the first time around.
deleted 10y ago
[deleted]
cwmma 10y ago
This is an interesting article about Haskell because it does concede that haskell might not be the best language for everything and other languages might be useful for certain kinds of apps though not exactly, the actual claim was that haskell was not superior enough to make learning it worthwhile for crud apps. The big disconnect between fp/haskell devotees and other programmers is that everyone else doesn't consider it self evident that haskell or fp is better and the haskell and fp group does a terrible job explaining why they are better paradigms without making assumptions like 'all side effects are bad in all circumstances' or 'imperative programing is always worse way to impliment algorithms' without justifying them empirically and saying your paradim is better without justifying it empirically.
bubblesocks 10y ago
I agree with the author that Haskell's unfamiliar syntax and functional constructs are why it hasn't taken over the world. I also think that Haskell's syntax and functional constructs are precisely why it should though. I also like the fact that Haskell isn't a mega-corp-owned technology, but rather grown by intelligent engineers to do intelligent things in intelligent ways. I'm not the greatest Haskell programmer, but I love it. I recommend learning the basics of Haskell, if you haven't yet. Doing so improved my code in other languages quite a bit, so it was worth studying for that reason alone.

130 points by atombender 10y ago

A programming language doesn’t need to “take over the world” to be successful. Nor does it even need to be “the best”, just serve a niche, as the article goes into. Haskell is the best language I’ve found for the software I write, so I use it. If other people aren’t using it, then I figure they have a good reason, or it’s their loss.

mark_l_watson 10y ago

Haskell is one of my favorite languages and just wrote a book using Haskell (you can read it free online: https://leanpub.com/haskell-cookbook https://leanpub.com/haskell-cookbook ) That said there are a lot of tasks that I use Ruby for (text wrangling), Python (machine learning), and Java (huge number of useful libraries). I use Haskell for NLP, some web apps, and coding algorithms that don't require libraries that aren't available for Haskell. If Haskell had a huge set of 3rd party libraries like Java, then I would probably use it for most of my development.

innocentoldguy 10y ago
Haskell Tutorial and Cookbook is one of the two books I've been using to learn Haskell (the other one being Haskell Programming, by Christopher Allen and Julie Moronuki). Thanks for the excellent book!
- codygman 10y ago
  Those two books sound like an excellent strategy.
- bubblesocks 10y ago
  I can vouch for Haskell Programming, but I haven't read the other book. Thanks for the recommendation.
zigzigzag 10y ago
I'll be interested to see if Eta takes off more than Frege. It seems like a good way to get haskell+java libraries together.

acchow 10y ago

Who says Haskell is so great? What does "better" even mean?

allengeorge 10y ago
From what I've inferred from the article "better" means: easier to write large-scale, composable systems that engineers can reason about easily.
- _yosefk 10y ago
  It doesn't seem easy to reason about the performance of a program under lazy evaluation. Generally there are many aspects of a system that you may want to reason about, and making it easier to reason about one often comes at the expense of making it harder to reason about another. Pure functional code, for example, makes it easy to reason about what outputs are produced from what inputs, but that is one (important) aspect among many (and to take one thing that's really simple without purity and really tough with it - consider "pure functional data structures" vs data structures in imperative languages assuming a mutable RAM.)
  - solidsnack9000 10y ago
    Laziness is a real problem for reasoning. Reasoning about pure functional data structures in the absence of laziness isn't that difficult, any more than the many mutable data structures that have copying/rebuilding/rebalancing that takes place only sometimes. The benefit of pure functional data structures is most visible when there is some kind of sharing -- concurrency of some kind -- in which case, reasoning about side effects becomes more difficult. There are good approaches to handling in-place array update and similar operations in pure functional programming (the ST monad, for example), it's just not the default. As long as the side effect is somehow accounted for in the return value, referential transparency is maintained; we might say the return value is there to help us reason about side effects.
ExpiredLink 10y ago
A higher peak in the hype cycle.

innocentoldguy 10y ago

I completely agree with the heart of this article, and its reasoning for Go's popularity (e.g. familiarity for people who know languages like C and Java). It speaks to my experiences, anyway. I went down the Go path myself for a while, because it was familiar, but I found that it had many of the same issues I was trying to get away from in other languages. As the article points out, I also found Go "boring." After searching for a while, I ended up wanting to use Haskell, but it was taking me too long to become proficient with Haskell's unfamiliar syntax and functionality; which is why, the author posits, Haskell hasn't taken over the world. I ended up using Elixir instead. It offered me the functional paradigm I was looking for in Haskell, and the ease of managing large-scale applications, while also offering a familiar and easy to learn syntax. I'm still studying Haskell, and may eventually employ it professionally, but for now, Elixir is working for me just fine.

sudshekhar 10y ago
Are you using the above languages for your day to day job? Or are you working on your own side projects? If the later, can you give some examples of the things you're building. I've tried learning them several times, but mostly stop after finishing the basic syntax :/
- innocentoldguy 10y ago
  Hello, sudshekhar, I am not using Haskell in my day to day job, yet, but I am using Elixir, and have been since last April. For learning Elixir, I highly recommend Dave Thomas' book Programming Elixir, The Little Elixir & OTP Book, by Benjamin Tan Wei Hao, and the website https://www.learnelixir.tv https://www.learnelixir.tv. You may want to start with the website and jump into the books afterwards. I learned with the two books, but one of my co-workers started with the website, and said he found it quite helpful. I watched the tutorial videos after the fact, and they are quite good. The website https://www.dailydrip.com https://www.dailydrip.com also has a lot of Elixir tutorials (similar to Avdi Grimm's website, Ruby Tapas), but you have to be careful because the older videos contain descriptions of features that are deprecated. I wouldn't bother with Daily Drip until you have a solid foundation in Elixir, and can pick around the deprecated bits. The later videos on Daily Drip are up-to-date though.

verletx64 10y ago

In the end, Haskell's ramp up time (to be productive) will slow it's momentum, and I feel that's with all languages with a ramp up time. Most popular languages have a pretty low ramp up time, and part of that is business concerns (getting a whole team to being productive in a language with a long ramp up time takes...well, time, and it's rarely the right option to have them make that transition), but also the personal, human side of it - we suck at being bad at things and the experience of it is hard to push through for people. Actually, jumping back into mathematics outside of work, I'm having to go through this period of uncomfortable 'badness' and resisting my urges for the greater good. It is emotionally taxing to be 'bad' at something. I think that's part of why we favour languages that allow us to be productive quickly, despite it probably paying off in the long run. I wouldn't do it with everything (you need quick wins _somewhere_) but it's a good skill to have, to be disciplined and persevere despite what your heads saying. I'm no psychologist though, so this is largely conjecture and anecdotes.

phs2501 10y ago

I kind of like Haskell, but the learning curve is brutal and the documentation is often intensely non-helpful if you don't want to learn a whole lot of mathematical terms. i.e. when browsing and trying to understand parts of the XMonad code, I came across the "Endo" type. I Hoogle'd it, and the only documentation for it is "newtype Endo a: The monoid of endomorphisms under composition." Thats.... not helpful for me.

evincarofautumn 10y ago
The biggest thing missing from Haskell docs is examples, I find. The mathematical language is tempting when you’re writing docs, because it’s succinct and precise, and can say a lot about how something’s implemented: -- Endo is… newtype Endo a = Endo { appEndo :: a -> a } -- ^ -- | -- …the monoid of endomorphisms… -- | -- V instance Monoid (Endo a) where mappend (Endo f) (Endo g) = Endo (f . g) -- ^ -- | -- …under composition. mempty = Endo id But not so much about how to actually use it: -- If you’ve got a list of functions… pipeline :: [Int -> Int] pipeline = [(+ 3), (* 2), abs] -- …you can compose them with the generic mconcat. run :: [a -> a] -> a -> a run = appEndo . mconcat . map Endo run pipeline (-1) == 5
- stcredzero 10y ago
  None of that helped me understand anything.
  - catnaroek 10y ago
    “Endo” is a type constructor for functions that have the same domain and codomain, so if you have two values of type “Endo Foo”, for any type “Foo”, you know that they can be composed in either order. That composition of such functions is associative and has an identity, I hope it isn't necessary to explain.
    - 10y ago

Shank 10y ago

You could ask a similar thing to any functional language. The internet has a very wide variety of introduction points to imperative languages, and quite a bit fewer for functional languages. This means that the barrier to entry isn't just "can learn a language" but the vast majority of the time, you have to convince programmers who already know another language to adopt a new one (and in an entirely new design paradigm than they're familiar with). Functional languages have to be penetrable to newcomers and offer huge benefits to veterans to switch, or they're going to remain nearly esoteric. Is mathematically provable code nice? Sure is. Is that enough to win people over? Well, language adoption says otherwise.

Kenji 10y ago
It has nothing to do with newcomers or skill or any of that. Often, we need to make computers do a list of things. Conditionally, sometimes, but nevertheless, a list of things. This is human thinking. A C function is nothing other than a list of things the computer does, one by one. Functional programming essentially throws rocks into anyone's way who thinks like this (which is pretty much everyone) and makes everything unnecessarily complex. There are few areas where functional programming is great, parsing and compilers come to mind. Other than that, in my eyes, it is mostly an academic pursuit.
- stcredzero 10y ago
  Often, we need to make computers do a list of things. How often do we need to do those things in a specific dependency order? How often do we need to simply get those things done, regardless of order?
  - douche 10y ago
    All the time? Human beings, on average, are more apt to think imperatively by default than otherwise, unless they've been explicitly trained to think otherwise.

sandhundred 10y ago

I struggle with this. After years of studying OO and design patterns in Ruby and JavaScript I was having troubling building complex asynchronous systems and stumbled into Go. I saw the value of types for managing that complexity and the runtime for supporting asynchronous primitives, but internally was very limited by the lack of generics for things like collections and higher order control flow for things like error handling. Eventually I arrived at Haskell after strongly considering Clojure, and I'm very happy about what I've learned and my new way of approaching programming complexity. Unfortunately there is nowhere else to go from here since I can't find employment as a Haskell programmer. OCaml, F#, Scala, Elixir, and Elm all feel like a step back. Now I'm a Java programmer and quite miserable. I feel hampered by the language nearly everyday in terms of how easily I can express my thoughts in code. Haskell isn't perfect but is the best fit for my mathematical mindset. I am trying to lead by example. I help host my city's Haskell meetup and contribute to a Haskell reading group. The path is lonely, my co-workers poke fun at me, and don't care to put in any effort to understand what I have to say. I love teaching and explaining things but there is zero interest because the machine keeps moving. Not many at the office even enjoy Java but are resigned to do it for our large pool of enterprise clients. All in all each work day is a void I put 8 hours into, which is fine, compared to most working conditions; it causes no suffering beyond the lacuna. I'm past the stage of trying to convince other programmers anything. I recognize many are happy with their tools. I yearn for that happiness and don't seek to spread my misery. I offer my time to those who are interested and want to learn more. Anyway, this article nails it, Haskell has advantages but they aren't enough to change things without the infrastructure the author is building. I look forward to being an early adapter of Unision and continue to remain hopeful for the future despite the long odds.

Kenji 10y ago
I have two questions for you: - How does Haskell fare with large projects that use APIs that are inherently stateful, like OpenGL? Don't things get messy and ugly as the pure world of Haskell is being tainted? - How do I optimise Haskell code without having studied the language for decades? I had a lecture where we were taught Haskell, so I know the language, but darn, even a simple hash map seems to be so very complex in the language. The fact that everything is a linked list (bad for caching & performance) and everything gets copied around really turns me off.

xyzzy4 10y ago

Haskell doesn't make it clear what things will process the fastest. For example in Java you can use hashmaps or arraylists depending on the situation and it is easy to optimize for run time. But I'd have no idea how to do this in Haskell.

catnaroek 10y ago
Efficiency is a matter of using appropriate data structures and algorithms for your problem, regardless of the programming language. Unfortunately, pervasive laziness is a serious disadvantage here. (But being functional is not.)

stonogo 10y ago

Because the entire programming model breaks down at I/O. When you have to compromise the language's _raison d'être_ to perform a basic function of the computer, the cognitive dissonance is real.

tene 10y ago
I don't want to be excessively dismissive, but I'm curious if you have a more-precise explanation for why you think that Haskell's programming model "breaks down" at I/O? I'd say that one of Haskell's entire purposes as a research language has been exactly about modeling, reasoning about, and representing I/O and other sorts of effectful computation in the type system. Unless I've misunderstood you or there's something more subtle you're referring to, I don't follow what you're trying to say here.
douche 10y ago
This is what always fucked me up with Haskell. To introduce printf debugging, you get sucked into the morass that is the IO monad, and all the clusterfucking that involves.
- tene 10y ago
  You don't need IO at all for printf debugging. Just call trace or traceShow. https://www.stackage.org/haddock/lts-7.16/base-4.9.0.0/Debug-Trace.html https://www.stackage.org/haddock/lts-7.16/base-4.9.0.0/Debug...
  - douche 10y ago
    Apparently things have changed since 2007... Or else my Ivy league CS professors didn't know what the hell they were talking about. As I grow older and more cynical, the difference between those options continues to narrow...
    - TheCoelacanth 10y ago
      I wouldn't be surprised at all if Ivy league CS professors didn't have in depth programming knowledge. They are Computer Science professors after all, not programming professors.

hacker_9 10y ago

Main reason I don't make the jump into fully functional language, is the difficulty of refactoring. It's nice if you get the program structure right first time, but of course that doesn't happen and so the inability to easily pivot makes me stay away. saying that, I do get hit by bugs that come from state, and each time I wished I'd used the functional approach, but it's not enough of a reason to make me switch.

nbouscal 10y ago
That's… exactly the opposite of my experience, and that of every Haskeller I know. Refactoring is 100x easier in Haskell than any other language I've worked in.
- izacus 10y ago
  What was the biggest and oldest codebase you worked on?
  - nbouscal 10y ago
    A few years and maybe ~50k lines of code, iirc. I've heard the exact same reports from people who work on multi-million-line Haskell codebases, though (e.g. Standard Chartered).
- preordained 10y ago
  100 times easier than right-click refactor in a modern Java IDE? I beg to differ--if we are talking about your typical Haskell vim/text editor rig. For a language with such powerful types, it's like a gun with no bullets lacking a good IDE to take full advantage.
  - nbouscal 10y ago
    I've never used a modern Java IDE (as I've been fortunate enough to never have to program in Java), but still feel confident in the claim that refactoring Haskell is 100 times easier, yes.

stcredzero 10y ago

And so the history of programming has been a series of advancements in both removing barriers to composability, and building new programming technologies that better facilitate composition. This is like saying that the history of architecture has been a series of advancements in reducing the cost of structures. This is the fallacy of narrow focus a single sexy metric. (See below.) Stage 4: Composability is destroyed at program boundaries, therefore extend these boundaries outward, until all the computational resources of civilization are joined in a single planetary-scale computer Smalltalk tried to do this with the Image, which contained everything within it, including compiler, source control, and development environment. (Smalltalk started out as an Operating System.) However, what this actually did was to sequester the community in the boundaries of the image while the rest of the programming field was busy building varied forms of infrastructure to allow interaction. I think this hypothesis also offers an explanation for why Go is popular, even though the language is “boring” and could have been designed in the 1970s. Java won over Smalltalk because the Java community understood much better how to win mindshare. Ruby took over Smalltalk's pure object schtick because it could play nice with the rest of the programming world, and it had a killer app in Rails. Go wins because it is exceedingly well designed for convenience in a myriad of ways where other languages drop the ball. You can have very fast incremental compilation in C++, if you are careful. In Go, it just works. You can have a good deployment process with Java, if you are careful. In Go, it just works. You can have easy to use concurrency in other languages, like C#, provided you find and learn the correct libraries. In Go, it's baked into the language, and people can learn how to use it competently with about as much effort as learning how to implement FSM using switch{}, and very good documentation and tutorials are dead easy to find. A Lamborghini is way faster than a Corolla. A Ford F300 can haul many times more groceries. A Corolla doesn't have remotely near the potential for track day fun as an Ariel Atom. The above 3 qualities are sexy metrics, but in terms of overall utility and convenience for the largest number of people, for the most favorable cost/benefit, the boring old Corolla kicks butt. (That said, I'm pretty sure that someone can figure out how to disrupt programming in the way that companies like Tesla are poised to disrupt the above story. It might well be a "boring" version of functional programming that has many "just works" qualities.)

montanonic 10y ago

Honestly, I think for a lot of people who've used both Haskell and Elm, the answer is pretty clear: lots of Haskell in the wild can be very hard to read and think about, even with significant time invested in it; and when it simple to read, it's likely not using many more features than Elm is. Yet, even with a very strict subset of its features, it is a very expressive language: sum and product types are an incredibly powerful concept; I'm blown away by how much more straightforward managing state is with them. Expressive types and superb type inference generally make refactoring a breeze. There are just many huge wins overall. But you can have the bulk of these wins in a simpler language like Elm, or a language like Rust which tries to only add more type complexity in cases where it would significantly improve code in practice, rather than in theory. Haskell is necessary; it pushes the state of the art forward because of how experimental it is (compiler extensions). But it's pretty clear that the community is skewed towards research rather than industry, and culture strongly influences what a language is practically capable of. This does not at all mean that Haskell isn't fully capable of industrial applications; we have direct evidence suggesting otherwise. But with a philosophy to "avoid success at all costs", it should be fairly clear that moving out of the realm of obscurity isn't exactly a goal of the language.

deleted 10y ago
[deleted]

mcphage 10y ago

The gain from composition isn't that it's easier for our brains to comprehend; lots and lots of tiny pieces are often harder for our brains to understand than a much smaller number of larger pieces.

nabla9 10y ago

Haskell is pure functional language and it enforces purity. Haskell did not take over the world for the same reason as pure OO programming, pure logic programming, pure relational databases, or pure anything never took off. Programmers have impure toughs.

insulanian 10y ago
We have dirty thoughts... Never thought about it that way :)

alkonaut 10y ago

Ask yourself this: are/were the designers of Haskell aiming to create a popular/widespread language? No. They were not. Quite the opposite. They have succeeded well in their aim to keep it s niche language. Perhaps a more reasonable question is why F# isn't eating C#'s lunch.

tikhonj 10y ago

One critical assumption behind discussions like that is that popularity is strongly correlated to quality. But that just doesn't seem true in practice—popularity is the result of complex social dynamics and isn't strongly correlated to any intrinsic qualities of whatever becomes popular. We come up with compelling narratives about whey one thing gets popular and another doesn't after the fact, but these are just rationalizations; we can't use them to make good predictions and they do a poor job of representing the social processes involved. We can see this in a microcosm when we consider music. What makes music popular? To a large extent, it's music that's listened to by the right people at the right time—perhaps seeded intelligently with exposure and marketing. There are some minimal bars the music itself has to pass, of course: it can't be terrible and it has to be accessible, but those aren't high bars to clear. There are thousands of bands as good or better than most of the ones you hear on the radio but they don't get anywhere. You just never hear them, or they never catch on among your friends and never make inroads into your social network. (Or, more importantly, into the social networks of the labels that push music in practice.) Unless they do, in which case you have some unknown band "going viral"—virality says a lot about how something spreads and little about the thing itself. It doesn't even matter what you mean by "better": some objective notion of quality, musical sophistication, aesthetics, "catchiness", pertinent lyrics... whatever. That's not the main driver of popularity. Nautilus had a great article[1] about this a while back, based on some experiments run with music. They created several large groups of participants listening to the same set of 40 musical tracks over time. People in the control group listened to music independently; the other groups all had social feedback mechanisms within the groups. The results were all over the place: the popularity of songs was completely inconsistent across groups, and could be traced to early chance decisions that snowballed over time. The article had a great analogy about how the whole process worked: > …a single match is not the entire reason for a wildfire starting and spreading. But that’s exactly how we naturally think about social wildfires: that the match is the key. In fact, there are two requirements: a local requirement (a spark), and a global requirement (the ability of the fire to spread). And it’s the second component that is actually the bottleneck: If a forest is dangerously dry, any spark can start a fire. Sparks are easy to come by, and are not intrinsically special. The programming language in question? Its qualities? Pragmatism? Purity? Elegance? All just sparks. Which one starts the biggest fire depends far more on its context than the spark itself. [1]: http://nautil.us/issue/5/fame/homo-narrativus-and-the-trouble-with-fame http://nautil.us/issue/5/fame/homo-narrativus-and-the-troubl... (The article was written by a researcher in the field and cites a few papers on the topic, if you want to read more.)

Animats 10y ago

Go is successful because it's exactly what Google needs to write back-end code. It's (almost) memory-safe. It comes with a set of well-debugged libraries for doing most of the things you need to do on a web server. That's good enough for most web-related work. From a language theory perspective, there's a lot to criticize about Go. The "goroutine" and "channel" thing turned out to be less useful for general concurrency than expected. But it's good enough to service lots of network connections. The lack of generics means that functions like "sort" are painful. But you can still get sorting done; it's just clunky. Haskell hasn't taken over the world because it's designed by theorists for theorists. It's too clever, or, "l33t", like LISP. Also, anything interactive is dominated by I/O, while the functional model is better matched to pure computation. The IT industry today is mostly I/O dominated interactive applications. (It's not clear yet if Rust is "too clever" for widespread use. The jury is still out.)

bsaul 10y ago
I agree on the general point that go is simple and familiar, but it's absolutely not memory safe ( and as you said, channel is really not working as well as expected in practice, unless you start using them as actor mailboxes, which i don't think was the original point). Actually, seeing all those panic on null pointers was really my first surprise when i started coding in go ( and really first disappointment).
- kazinator 10y ago
  Panics on null pointers don't indicate that the language isn't memory-safe. Lack of memory safety means that misuses of memory go undiagnosed, with unpredictable results. (Not to mention that they are allowed in the first place, with features like arrays that blindly allow oout of bound access.) A null pointer indicates a memory problem only if it is the field of a memory object that was wrongly overwritten with zeros, giving rise to the null value in an invalid way. If the null value was correctly assigned, then it isn't a problem in the memory safety category. If Go diagnoses all null pointers with panics, that makes it safer than C, whose implementations require on the virtual memory hardware to catch null pointers. An expression like ptr->member in C will onlyl segfault on a null ptr if the member displacement is within 4096 bytes, or whatever is the virtual memory page size. If memb is offset beyond the unmapped zero page, then some memory is silently accessed or overwritten. Not to mention that on systems without VM hardware, ptr->member just silently works when ptr is null, for any struct type. I don't program in Go, but as far as I know, panic is a kind of high level exception handling feature in Go. So it sounds like you should be able to write Go code which expects that null pointers will occur in some object field or parameters, and just use panic/recover to trap it all in one place instead. In C, you would need platform-specific coding to do anything similar, like catching a SIGSEGV in POSIX or a structured exception in Win32. Yuck!

deleted 10y ago

[deleted]

zzzcpan 10y ago

Well, every language is a product that has to compete with other languages. Nothing to do with composability or advancements in out-of-touch research areas. And these days languages compete on a lot of things, on performance, reliability, security, productivity, on syntax, on tooling, on libraries, on deployment and supporting infrastructure, on interoperability. Syntax is not even that big of a deal, it's not hard to compete on it, you can just take Go's approach or you can do it thoroughly and properly, not forgetting about newcomers, their likely previous experience and designing the whole learning experience into the language too. You can't leave it as is though or it's going to be a huge disadvantage.

elihu 10y ago

As someone who has done a lot of programming in Haskell, I'm glad to see that the limitations of composability across program boundaries is being recognized as a problem. (And it may be a problem that Haskell can't fix without some help from the operating system.) When you have to convert data to type "String" in order to send it over a pipe, and then convert it back in the receiving program, that sort of defeats the purpose of having a strong type system in the first place. Similarly, if you have a bunch of processes, each with their own IO Monad interacting with each other, it starts to have an uncomfortable resemblance to the shared mutable state that Haskell tries so hard to avoid. As for the question of why Haskell isn't more popular, there are a lot of possible reasons. GC overhead and less control over memory layout makes it less performant than C/C++ and not really suitable for real time tasks. Some algorithms are hard to express without mutation. (The ST Monad is usually appropriate for those cases, but it's kind of cumbersome to use.) Laziness makes memory and CPU utilization hard to reason about. The learning curve is very steep. There aren't many books on "advanced" Haskell programming, or writing system software in Haskell. One of the things I really like about Haskell is that you never stop learning new things, and new abstractions and libraries are being invented all the time. After 25 years or so, we're still figuring out new ways to program in Haskell. This has a couple of unfortunate side effects, though. One is that programmers can become distracted from the task at hand and direct all their effort at figuring out a better abstraction to solve their problem. A lot of great things come out of such work and sometimes it pays off it terms of productivity, but I think the common criticism that there isn't enough practical, "boring" software being written in Haskell is justified. Another problem is that it's hard for Haskell programmers to communicate with each other or understand each other's code when they haven't learned or are comfortable with exactly the same set of abstractions. I do think Haskell is on to something good. I don't expect Haskell to take over the world, but I think in a hundred years people will look back and say that ideas from Haskell were a major influence on later languages that were more popular. Learning Haskell is probably a good way to prepare for languages of the future that haven't been invented yet, in the same way that learning Smalltalk would have been a good way to prepare for the object-oriented languages that came after.

harry8 10y ago

New language to learn? Write a toy. Spend more time on that toy than it warrants, re write it and someone else find it useful or fun. These programs are almost wholly absent in Haskell. List all the programs used for something that isn't writing code that were written in haskell. Xmonad Pandoc Git-annexe maybe ... And. Please really do add to this list, its length is informative and tells us something about haskell's strength and weakness.

codygman 10y ago
> List all the programs used for something that isn't writing code that were written in haskell. As smugly as possible and with a huge grin: Purescript Some I can think of off the top: - PostgREST - hoodle - Microsoft Bond - git-annex - darcs
- harry8 10y ago
  So you don't use purescript for writing code according to your definition? Ok. Anyway, that aside the haskell pushers out there really need to address why there's so very little in the way of application written in haskell. The article notes that haskell is used very successfully for compilers. The number of successes elsewhere is very, very much smaller. Why? It's important not to just yell "rah rah" but actually analyse it as a problem and maybe, just maybe, you know, solve it.
  - nbouscal 10y ago
    Haskell is used successfully in industry, e.g. at Standard Chartered where they have >1MM lines of Haskell in production. Take a look: https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry
  - shae 10y ago
    Anecdotally, I see much commercial and personal use of Haskell. Have you looked at the other comments in this thread? Alternatively, why do you think there aren't small fun toys and/or commercial usage of Haskell?

88e282102ae2e5b 10y ago

It's like I accidentally stuck my hand in a running blender and someone asks whether I'm angry because of the noise of the motor or because the buttons aren't arranged in a reasonable order. I tried learning about Haskell just so I could understand a flurry of articles I came across that were trying to explain monads. But mostly I found super abstract notation, something about bind and unit and >>=, and I came away just feeling dumb. I gave up pretty quickly, but to be fair I suppose I wasn't super motivated to work through it. Later, I learned Rust just for fun. Options? Sounds like a good way to express uncertainty about a function call. Oh, and you can compose it with other Options using this function called and_then(), and things will short-circuit if they fail. Neat! A year later I find out I had been productively using monads the whole time without even knowing it. It's so frustrating knowing how easy it could have been to learn this concept explicitly the first time around.

deleted 10y ago

[deleted]

cwmma 10y ago

This is an interesting article about Haskell because it does concede that haskell might not be the best language for everything and other languages might be useful for certain kinds of apps though not exactly, the actual claim was that haskell was not superior enough to make learning it worthwhile for crud apps. The big disconnect between fp/haskell devotees and other programmers is that everyone else doesn't consider it self evident that haskell or fp is better and the haskell and fp group does a terrible job explaining why they are better paradigms without making assumptions like 'all side effects are bad in all circumstances' or 'imperative programing is always worse way to impliment algorithms' without justifying them empirically and saying your paradim is better without justifying it empirically.

bubblesocks 10y ago

I agree with the author that Haskell's unfamiliar syntax and functional constructs are why it hasn't taken over the world. I also think that Haskell's syntax and functional constructs are precisely why it should though. I also like the fact that Haskell isn't a mega-corp-owned technology, but rather grown by intelligent engineers to do intelligent things in intelligent ways. I'm not the greatest Haskell programmer, but I love it. I recommend learning the basics of Haskell, if you haven't yet. Doing so improved my code in other languages quite a bit, so it was worth studying for that reason alone.