17 ms·

Haskell is a Bad Programming Language (2020)

• smlckz 6y ago
  Maybe Haskell is bad from practical perspective, but not from theoritical. So it has a strong appeal towards academics and purists.
  • smcl 6y ago
    Yeah this article was bizarre for me to read. My understanding is that Haskell doesn't aim to be big and popular (as Rust and Go have as a nice counterexample) its intended use is in academia by CS researchers, and its users seem to be quite satisfied with it. The fact that it gets any sort of traction at all outside this suggests that it's actually exceeded expectations of its success. > It is as if Haskell doesn’t want “normal” people to understand it Well, yeah kind of. I don't think it's as hostile as that though, the language isn't actively against "normal" people (I guess, that means your common or garden OOP programmer) it just doesn't actively court them. The comments about how the community treat newcomers are quite interesting though and if they are true then that's pretty shitty behaviour. It's one thing if the language isn't aimed at a given demographic of programmers, but it's another thing for people to use it as an excuse to beat down and berate others.
    • Typhon 6y ago
      The one valid definition of success for a programming language is that it looks pretty and thus the most successful programming language is Piet ( http://www.dangermouse.net/esoteric/piet.html http://www.dangermouse.net/esoteric/piet.html ) I mean, joking aside, it's always fascinating when people can't wrap their minds around the idea that their criteria for success or quality or goodness are subjective and not universal.
      • smcl 6y ago
        Piet is lovely and a really creative idea :-) But yeah you are absolutely right.
    • Blikkentrekker 6y ago
      I know many academics that exclusively use Haskell or even Idris and Agda which are even more obscure but more correct. Agda is so “correct” that the language is total and not Turing complete with the exception of a “partiality monad” that allows for partial and Turing complete computations — similarly to how Haskell isolates effects on the world from the main language and encapsulates them into a special type, Agda isolates partial computations. And this language is very much used within specific academic fields.
      • smcl 6y ago
        Wow ok Agda sounds ... challenging :-)
• madog 6y ago
  I definitely agree with the documentation side of things, particularly lack of concrete examples. I found that overall however, learning Haskell made me a better programmer, even if it's more useful as more of an academic than practical language. Dealing with pure functions, no access to loops so recursion is paramount and it is rather beautiful and useful some of the tail recursion and pattern matching stuff. The Haskell quicksort is the classic example of this: quicksort [] = [] quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) where lesser = filter (< p) xs greater = filter (>= p) xs
  • deleted 6y ago
    [deleted]
  • leereeves 6y ago
    That is quite elegant for that variant, which is a great fit for Haskell's features. How easy is it to write a different variant, like using a different pivot, or sorting in place?
  • seppel 6y ago
    > The Haskell quicksort is the classic example of this: The Haskell quicksort is also classic example of something that is small, beautiful and still misses the point. Yes, it contains the core idea of quicksort (partion the list and divide and conquer) but it completely fails on the quick part, because the Haskell lists are are leaky abstraction of real computer memory. A real quicksort in Haskell is much more convoluted.
    • hashingroll 6y ago
      What's a real quicksort anyway? You could argue that a reasonably fast implementation of quicksort is much more convoluted, which it most certainly is, but that doesn't make this implementation any less real.
      • seppel 6y ago
        > What's a real quicksort anyway? A key aspect of quicksort is that it sorts the list in-place. If you dont sort in-place, you dont have quicksort and if you dont need in-place sort, then quicksort is the wrong choice anyway. Of course, canonical Haskell does not have a concept of in-place, which makes showing quicksort in Haskell also a questionable idea. > You could argue that a reasonably fast implementation of quicksort is much more convoluted, which it most certainly is, but that doesn't make this implementation any less real. A reasonably fast implementation of quicksort is straight-forward in any language that has arrays/vectors with destructive updates. This implementation will have issues with pathological cases, but that's a problem of the quicksort algorithm, not of the implementation (whereas the Haskell one shown above has problems in the implementation).
• malthejorgensen 6y ago
  Given the opinion expressed in this blog post I wonder how the author intends to process data that they don’t know the type of :P Yes, Haskell is born out of academia. That’s where its strengths come from but also its weaknesses. Many new languages and language features are directly inspired by Haskell’s strong typing and type safety and the world of programming languages is better for it. I do question whether Haskell will ever be ready for mainstream - probably not. But hopefully some other more practical ML derivative will gain enough momentum to truly become mainstream. Arguably Scala is that language, but Scala feels the C++ of ML-derivatives - the language is too big and the syntax irks me.
• prohobo 6y ago
  One heuristic for the quality of a language is to literally ask "what is it good for?" Just off the top of my head (I'm skipping a lot of categories and languages): C/C++/Rust are great for systems programming, games, and performance critical applications. Go/JS/Python are great for creating web servers, data processing (Python mostly), and small apps/scripts. Haskell? I have no idea.
  • als0 6y ago
    Haskell: 5 line quicksort and parsers/compilers. I do like the language, though.
    • sn41 6y ago
      Actually: in-place quicksort in Haskell is as verbose as in other languages. The 5 line quicksort uses linear order additional space.
      • Blikkentrekker 6y ago
        The matter with Haskell is that one often doesn't use in-place updates and that the language is designed such that this can be more efficient than in many other languages though Ocaml probably does this better with it's incremental garbage compilation strategy.
    • AzzieElbab 6y ago
      Well, that 5 line quicksort is fake. Haskell is good for writing other languages like Elm for example
    • usrnm 6y ago
      You can write quicksort in C++ in about the same number of lines using std::partition from the standard library.
  • tlarkworthy 6y ago
    Compilers and logic programming
• deleted 6y ago
  [deleted]
• deleted 6y ago
  [deleted]
• alexmingoia 6y ago
  I program in Haskell and quite enjoy it.
  • mac01021 6y ago
    Do you use many 3rd party libraries? How do you learn to use them? The one thing stopping me from using Haskell for real work is that nothing in the library ecosystem seems to have a users manual.
    • seanparsons 6y ago
      What? I've worked in a whole bunch of languages and I tend to find that Haskell is the easiest on this front. Hackage has all the definitions for packages cross linking to each other.
    • kreetx 6y ago
      In what area would you like to program in? At least on the types-are-documentation front, I find that really helpful - just see what you have, what you want, and then find a way from one to the other. In JavaScript on the other hand it's hard to tell what the structure of some object needs to be.
    • alexmingoia 6y ago
      Many libraries lack tutorials because the type definitions are self explanatory. For example, I’ve been doing a lot of web stuff lately and here’s a package I used for working with URIs: https://hackage.haskell.org/package/modern-uri-0.3.3.0/docs/Text-URI.html https://hackage.haskell.org/package/modern-uri-0.3.3.0/docs/... Everything I need to work with is there in the type definitions.
      • cute_boi 6y ago
        exactly this is the beauty of types. Types can serve as documentation. This is also one reason why I love rust docs.
• jchw 6y ago
  I don't have the experience or knowledge necessary to judge this post, but I’m glad it exists and got posted to Hacker News because I believe the discussion will end up being insightful. I am not generally a functional programming person. I grew up on C and C++ and went on to learn Python, JS, etc. Eventually I finally wrote actual code in Scala and thought it was fine. Didn’t love the syntax, not great at “thinking” functionally, but loved sum types and pattern matching. I feel like Rust is the perfect mix for me because it gives me the aspects I like about functional programming languages (sum types, pattern matching, strong type inference) combined with composition based polymorphism and an almost C++ like attitude towards meta programming (though obviously with a clean slate.) I do think that learning to “think functionally” better would be good; maybe I should listen to the 4chan meme and read SICP after all. :)
  • roflc0ptic 6y ago
    I’ll be interested to see if this generates thoughtful discussion. It feels like a flame-y, ignorant piece of writing and my gut response is to say flame-y, marginally less ignorant things in response. Which I won’t, because that would be unhelpful and make everyone’s life who read it slightly less pleasant for no reason.
  • Ericson2314 6y ago
    I kinda want every would-be Haskeller to just go use Rust for a few years. That gives us Haskellers more time to pursue "success at minimal costs".
  • smichel17 6y ago
    In my experience so far, SML hit a really sweet spot between ease of learning and features. I never had a "what would I use this for?" moment. Kotlin comes close, but is less elegant and especially lacks full pattern matching. Unfortunately, sml is used approximately nowhere. Not sure why, but I also haven't used ocaml yet. Maybe one day. My hosting provider (hcoop.net)'s domtool is written in SML, and I hope to hack on it at some point.
    • vnorilo 6y ago
• bor0 6y ago
  The whole article builds on the premise that the main point of every programming language is adoption and growth, while for Haskell we have > avoid success at all costs According to that statement, to me it seems that the current "success" (however one defines it) of Haskell is just a side-effect. Yes, it is used in industry, but I believe the bigger impact here is how other languages "steal" features from it.
  • Blikkentrekker 6y ago
    Rust would certainly not have existed in it's current form without Haskell. There are many such “progenitor languages” that focus primarily on theoretical elegance such as Smalltalk, Scheme, and Haskell that might not see huge adoption but do inspire a rather lasting influence on many languages that grew far larger than they.
• vnorilo 6y ago
  Too bad the tone is so vitriolic, because there is an argument hidden in there somewhere. Type systems allow us to add theorems to our programs about how they operate and have the compiler check their consistency. We fight with bugs: programs behaving unlike we planned and specified. We encode plans and specifications as types, and now have formal proof that a certain class of bugs is eliminated. Excited, we want to use this strategy to eliminate more bugs. A larger part of the programming task is moved over to this higher order type layer. As it becomes less trivial, bugs and antipatterns start to manifest. We do not have any answers about the objectively best division of labor between static and dynamic aspects. This is a research project that's bigger than any single person, community or language, and I'd argue we need more of Haskell, Rust, Idris and their ilk rather than less. To merely argue that they did not result in a dramatically better OS or a word processor is beside the point.
  • asplake 6y ago
    I for one upvoted not because I agreed with the article but for what I hope is a constructive discussion. Personally, and without wishing to sound entitled, I would love for it to be a lot easier to dip one’s toe in the water. A great start would be a web dev tutorial that starts from scratch with a sane Prelude that hides away anything I don’t need to know now (or perhaps ever). With of course a database, json, and html. Coming from Flask where I was well served in that regard (no pun intended). Aside: Thought ocaml might get there first but I’m not seeing that either
  • dgb23 6y ago
    I agree, the benefit of this, is that it creates a frontier where math can be applied more rigorously to programs. There is a related xkcd comic about this. We’re in a “not there yet” kind of situation. The author likely comes from a very mainstream product centric domain, as most do. In this context one has to agree with the criticism and maybe also admit that this is not what the language is for?
    • feanaro 6y ago
      This is a good point. But I also want to add that as a freelance developer, I've done quite a number of medium sized projects for business use cases in Haskell singlehandedly. Empirically, the results were very low in bugs and remain at use at the companies in question without requiring much maintenance. So this kind of thing is something that is well served by Haskell, in my opinion. I wouldn't seriously recommend someone else that the best path to doing this kind of work is to go and learn Haskell but I also feel this is something I wouldn't have been able to do as well using many other more popular languages.
• jonny383 6y ago
  Haskell is honestly like a cult. Not so great, but once people are hooked, try convincing them otherwise.
  • valenterry 6y ago
    That's not about Haskell but about the paradigms though. So rather, pure functional programming is hooking people. I understand why: once it feels natural, it is very painful to go back.
• Santosh83 6y ago
  There are languages more suited to program in, and there are languages more suited to move the field of programming itself forward. I guess Haskell belongs to the latter category and when people try to ram it into the former set, they get frustrated.
• _query 6y ago
  > programming languages are meant to ease the task of creating computer programs as opposed to writing assembly by hand This! The haskell ecosystem is missing a certain kind of pragmatism. There's a lot of beautiful type abstractions, talking about monads, etc., but not enough builders doing actual application development. In my opinion it's not the language that is bad, but the ecosystem. Missing documentation, missing tooling and infrastructure, no focus on actually building applications. We're trying to fix that with IHP, a new haskell framework with a focus on actual building applications. Imagine the productiveness of rails combined with the typesafety of haskell. 6 months after it's release it's already the second biggest haskell framework, and we just had a new record of weekly active users last week. To me this shows that by fixing the ecosystem haskell can reach a lot more than it's currently doing. Check it out: https://ihp.digitallyinduced.com/ https://ihp.digitallyinduced.com/ GitHub: https://github.com/digitallyinduced/ihp https://github.com/digitallyinduced/ihp
  • shipp02 6y ago
    Thank you will check out. I was going to work on a web app in Haskell and am scouting libraries.
  • kdkeyser 6y ago
    This indeed seems to be the main/only point of criticism in this post that is valid: however, it is not that Haskell has no "pragmatic" libraries to get stuff done (e.g. WAI/Warp, Yesod, Servant, ... are top notch, practical libraries if you are writing network/HTTP services). They do seem to drown in the sea of libraries/blog posts that are focused on the academic/abstract stuff. The end result does not feel consistent, and reminds me of the horrors we had with the early C++ metaprogramming efforts: it looks cool, but you end up fighting the language and produce unreadable code. For Haskell to become a successful "industrial" language, I think most of the dependent-typing stuff should probably go (to Idris/Agda etc.), so that a clear and consistent Haskell subset can be defined. The other arguments in the article are just weak. The rant about data not having a type, is missing the point. Sure, often you receive data that you need to inspect to know what it is. You can easily do this in Haskell (just label it with the UnknownData type), and have a function that inspects it and returns, depending on the contents, the right type). The big advantage is that you don't have to keep on doing this same check. Types being the cause of difficulty in refactoring when business requirements change, is the opposite of my experience. In large dynamically typed codebases, being sure that a large refactor caught everything, is very hard / costly in test coverage. I have seen this go wrong many times. Having the compiler point out what you have missed, based on the types, is very helpful. While I think the arguments are a bit weak, I do agree that it is at least unclear if Haskell is a sound choice as a production language at this time. Fighting against an ecosystem is not something you want to be doing while building your product. But in contrast to the author, I do think this is fixable, and see steps happening in the right direction (e.g. with IHP, but also with the efforts around the Haskell Foundation and the Haskell Language Server)
• sn41 6y ago
  I finally understood what monads and monad transformers are about. And there comes arrows and linear types. Ouch, my head hurts.
• WJW 6y ago
  The line which sprung out most to me was the one claiming that "Clojure took the world by storm". This is simply not the case. JavaScript has taken the world by storm, as has Python. Ruby, PHP and others have taken the world by storm before and are slowly fading. Clojure has never taken the world by storm and (IMO) never will. Neither will Haskell btw. To me, Clojure is very much on the same level as Haskell: an extremely niche programming language with a small (sub-1% in TIOBE) but dedicated following that is unlikely to grow much beyond what it already is. Rest of the article: meh. It presupposes a lot of what it thinks Haskell should aspire to without investigating whether those things are actually what it is aspiring to be.
  • ImprobableTruth 6y ago
    The entire article just reads like a badly regurgitated Hickey talk.
  • thom 6y ago
    Yeah, I think Clojure people have a lot of insecurity around Haskell and it’s rarely a good look. Clojure is a language of sensible compromises without any real philosophical slam dunks, which doesn’t seem to satiate engineers’ natural desire to win internet points.
    • iLemming 6y ago
      > Clojure people have a lot of insecurity around Haskell I beg to differ. I think it's the other way around. I rarely see Clojure folk bashing on Haskell - they usually admit Haskell's strong points or any other language. They very often borrow ideas from other languages, libraries, and tools. I've heard they are figuring out interop with Python and R. They've built Clojure-like Lisp dialects that work on Golang, Erlang, compile to Lua, etc. Haskellites, however, get sad and defensive anytime someone mentions that it's not so widely used in the real world.
      • travv0 6y ago
        That’s a nice thought, but I haven’t seen examples of that myself. And your claim of real-world use seems to be the opposite of what I found with a quick Google search: https://redmonk.com/sogrady/2020/02/28/language-rankings-1-20/ https://redmonk.com/sogrady/2020/02/28/language-rankings-1-2... https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ https://insights.stackoverflow.com/survey/2020 https://insights.stackoverflow.com/survey/2020 Obviously this is far from scientific, but Clojure being a new, hyped language, it wouldn’t surprise me if that skewed people’s perception of how much it was used in production code.
• jpcooper 6y ago
  I have been giving Python a go for writing a programme which concurrently scrapes and collates data from multiple sources. I chose to figure out how to do this in Python instead of my usual Haskell because I wanted to see how productive I would be compared to how I did similar things in Haskell. I wanted to get away from what I call type-wankery, which the author seems to be complaining about as well. I’ve been using the Python asyncio library and have been thinking that Python could certainly do with monads in this context. Then I remembered what a ball-ache stacking monads is. In any case, I can’t help seeing programmes in an algebraic context after using Haskell. The author, and many people who complain about types, seem to forget that types and interfaces exist whether or not they are explicitly defined. Is the problem with such an attractive type system that they lead to people defining interfaces before they are fully explored? In that case, maybe it could be argued that a less attractive type system would keep people away from so much type-wankery. It’s hard to know where the best balance is. I am considering F# now. It also seems to have working IDEs, which is nice.
• smlckz 6y ago
  Here is a very good argument on why types are needed, by Bartosz Milewski: https://bartoszmilewski.com/2014/11/24/types-and-functions/ https://bartoszmilewski.com/2014/11/24/types-and-functions/
• deleted 6y ago
  [deleted]
• jokethrowaway 6y ago
  Haskell is a language for experimenting, success is not their goal and it would remove resources to actual research. They had promises and async/await in 1995. They're trailblazers that other languages can follow (like rust did). I would add that, after stack, tooling is not a problem anymore. It's not as good and polished as rust's cargo but it's ahead several other languages. Still, as a language, Haskell is not ideal for teaching and productivity. There too many different ways of doing things (eg. strings, records); compiler errors need improvement, prelude has too many exceptions-throwing functions (eg. head); exceptions handling is not something I want in a pure language; ghc extensions change the language so much that using some extensions almost feel like having to learn another language. On documentation, I can't say I feel the need for it, but I understand some developers may be used to program against documentation and feel lost without it. I think that Haskell is a great language to prototype pure business logic because of the type system and focus on purity, but it has several warts, because haskellers focus more on language research than DX. The reason I stopped using Haskell is because I was bit by exception handling (which is a feature shared by many other languages, incidentally!) and by GC spikes. I still like Haskell, it's closest to my "ideal" language than any other, but for production Rust is more useable (albeit being a bit uglier)
  • dom96 6y ago
    > They had promises and async/await in 1995. Really? Do you have a source on this? I was under the impression that C# was the pioneer here.
    • jcelerier 6y ago
      promises, futures, etc... are much older - it takes 15 years for stuff pioneered in research to make it into general purpose langs :p - https://d1wqtxts1xzle7.cloudfront.net/50657913/p260-liskov.pdf?1480599977=&response-content-disposition=inline%3B+filename%3DPromises_linguistic_support_for_efficien.pdf&Expires=1610200011&Signature=BEYyYwFDSL5eQAXnTHmvqVZh0MndxFKi0qmtUzmm1M41Zzk2uPeHTAwo9mMd74sTsn8Ap1W3yG15qYYOrUusIEWQ-ShmdVwWnm3x-bdQL4qrpS8Nq7M~mTM~pqSHquaG-~DqO7-dSvvFCsMqO3dJTg9rRxbkLnQSZdJoAOrJ~qSPm917gVCYLkqXSw-xTEP~oERVPe8i5DymDRssnIrCdl2BtgzY9ZiJP4rNdjHTYTby80hc-UHkNfUJ1RSQ6lXsuCDzZuBscwS1lZIN2452m1NUC6wCEv0vAw65Dix-mQt1ClZDpAtvpQfpBmbGEWUxtNLUdnt85slAlJoay6i1vg__&Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA https://d1wqtxts1xzle7.cloudfront.net/50657913/p260-liskov.p... - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.1841&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97....
• foolmeonce 6y ago
  I think an aspect of many paradigms and then the multiparadigm languages is that people don't see the original two camps of CS pioneers. Haskell is from math, brevity, correctness. Perl is a linguist's take on applied math. I would prefer to write a proof in haskell and a manifesto that expresses what I think, however irrational, in perl. ("If I had more time I would have written a shorter letter." and general sentiment towards first language vs math education imply that perl will be the easier and more comfortable language for most if that is really the primary goal. But the slight irrational thinking as we add more layers means eventual collapse.)
• cannabis_sam 6y ago
  When people talk about the beauty of Haskell due to it’s definition they are making a qualitative claim. When people say Haskell sucks because of low adoption rate they are making a quantitative claim. As a research language there is real value in Haskell not getting broad adoption, since that would increase the demands for maintaining backwards compatibility. As an industry language that philosophy is a huge detriment because it introduces risk and extra costs in keeping up with an ever changing language. These things are not a one dimensional structure, otherwise Java and C are pure perfection due to adoption and Rust and Haskell should be forcefully shutdown or whatever.
• harry8 6y ago
  You either think the astronomical number of bugs in delivered software is a problem or you don't (and good luck with that). The use of Haskell is a huge win on this metric and demonstrably so. You don't have bugs in any of the Haskell programmed OSes you actually use, nor your editor written in Haskell, your Haskell mp3 player nor your Haskell time machine and Haskell en-truthenator. Pandoc is good. Some like xmonad window manager, git-annexe has some fans. There's probably 4 or 5 more too! Mostly centred around parsing. And for all that you absolutely should learn Haskell. You'll enjoy it and it will enable you to think about programming in New and powerful ways. Just don't fall so deep you expect to actually ship anything you write.
  • thom 6y ago
    The only Haskell software I regularly interact with is Hasura, and it has plenty of bugs (even ones around nulls and other things Haskell is supposed to magic away).
  • jbjbjbjb 6y ago
    I wish functional advocates would stop saying this, it just isn’t true. There any many types of bugs and Haskell may help prevent some of those.
  • tchaffee 6y ago
    > You either think the astronomical number of bugs in delivered software is a problem or you don't (and good luck with that). We don't need luck. Competition has already given us the answer that most bugs are ok. The vast majority of the software that creates literally trillions of dollars of economic activity, and pays most of our bills, is not mission critical. Software fails all the time with the only significant consequence being a developer has to spend some time fixing it. Sure sometimes money is lost. So is money lost when factory equipment needs repair. Some software does deserve to be bug free when it might put lives at risk, like flight software or medical software. Perhaps even operating systems. But the vast majority of the software I use on a day to day basis does not fit that category. What significant harm does a bug in VS Code or Slack or even my OS cause me? None. If bug free software gave a significant economic competitive advantage, smart folks would start writing it and win big in the marketplace. Considering this has had decades to happen, and has not, it's very unlikely that bug free is the winning competitive advantage when it comes to software. I'd guess the winning advantage is that the software is useful. Much like a car with many small problems is still useful. The truth is that much of the software that exists today simply would not be worth building bug free and would never be profitable. You can extend this outside of software development to see that it's true in a more general sense. Most of the manufactured products we buy are not perfect and do not last forever. Some even have flaws from the day you buy them, but flaws that can be worked around. Once on vacation I bought screwdriver at a dollar store. Poorly manufactured and it does have "bugs" compared to something I would have paid 10x the price for. But years later I still have it and it's good enough for some jobs. You could potentially build a car that doesn't fail for any reason for a few hundred years. Only Bezos and friends could afford it. With that said, I'd like to see the negative externalities of pollution and waste included in the true cost of things we buy, so that we don't produce so many disposable things that society pays for in the long run. But that's a different discussion. Please don't take this to mean that I don't take great pride in writing quality software that is as bug free as possible. I do. I also take great pride in meeting budget goals and deadlines. All successful businesses understand that competing goals must be balanced against each other.
• isubasinghe 6y ago
  I really like Haskell, I do enjoy Rust as well. I really am not a fan of OOP languages, largely because the data flow can be anything you want it to be. When the data flow is linear I find code far more easier to understand. One thing I dont like about Haskell: GHC doesn't seem to be aware of some of its escape hatches (allowing for imperative code) and performs incorrect optimizations. I had some trouble working with IORef recently and had to write some hacky code to get it to work properly.
• agumonkey 6y ago
  > Look at Clojure. Weird parentheses, and yet it took the world by storm Am I on another planet ? I'd rate clojure slightly above haskell in terms of market share. Is my radar broken ?
  • waffle_ss 6y ago
    That raised my eyebrow as well. Semi-recently I was interested in learning Datalog so I wanted to kick the tires on Datomic (written in Clojure). I ended up getting stuck on some things; posted questions to StackOverflow and didn't get a response. I then realized the Clojure tag is very low volume + engagement. Then someone on Twitter told me that I'd be better off asking questions in the Clojurians Slack channel. So I go to sign up and... the signup link is broken. Had to flag down someone on Twitter or IRC to fix it. As an outsider I felt a whiff of decay from the Clojure community (no offense)
    • agumonkey 6y ago
      The whole article felt it's coming from a traditional / industrial OO (everybody happy about UML usually doesn't see the world as I do). broken slack links or not, the community is not as large as the author seems to convey.
      • mxz3000 6y ago
        Do people actually use UML in industry? I've never actually seen it used (or mentioned for that matter) in the few years I've been a software engineer...
        • agumonkey 6y ago
          ffff .. fff most probably yeah, at least there are some informal uses whenever you make some diagram docs .. you'll end up aligning with uml 'vocab'. I helped a european project on a uml graph versioning between various industrial uml applications, but I'd consider these niche. IBM was heavy on UML since they bought Rational suite.. but I know IBM didn't use Rational for themselves (at least my department).. but surely Rational users did. I think heavily regulated sectors are the most prevalent users of UML.. they like having a standard, having a lot of documentation etc.
• greatgirl 6y ago
  I find the circle jerk around programming languages to be kind of tired. I realise this is a deeply ironic statement. But, personally, once i realised the vast amount of the rest of the world that is out there and can be explored, intellectually and physically, going back to arguing about programming languages made me feel a bit sick. I think this can't be applied to other niche interests. There's something uniquely tireless, insignificant, and wanky about programming language discourse that makes it especially sickening to me.
• malf 6y ago
  > Functors are basically an Object with a internal state changing method in typical OOP terms. This lets me safely ignore the rest of the article.
  • newswasboring 6y ago
    Care to say why? Or just going to hit and run?
    • davorak 6y ago
      I will take a stab at it. > Functors are basically an Object with a internal state changing method in typical OOP terms. If I was writing a functional language, in an oop language, I could implement functors at least partially with an Object with an internal state changing method. I could not model/implement an Object with an internal state changing method in a fp language via a functor. The main issue with the author's statement is that it makes a claim of approximate equivalence and does not back it up with additional evidence or examples.
      • newswasboring 6y ago
        > I could not model/implement an Object with an internal state changing method in a fp language via a functor. I don't think anyone claimed that. > I could implement functors at least partially with an Object with an internal state changing method. Now we are getting somewhere. You said partially, what features are being left out?
        • davorak 6y ago
          >> I could not model/implement an Object with an internal state changing method in a fp language via a functor. > I don't think anyone claimed that. I was not trying to refute the opposite claim. I was giving info on the differences of functors and the referenced oop feature. My points run somewhat counter to the authors claim "Functors are basically an Object with a internal state changing method in typical OOP terms." or at least what I think some reads walk away with. Hard to say what is in the author's head with the provided text. > Now we are getting somewhere. You said partially, what features are being left out? I did not mean to imply features would be left out but rather I would use more than the one oop feature, "an Object with an internal state changing method", to implement functors.
• dnlkrgr 6y ago
  It's always amusing to read critiques on Haskell written by people that don't know Haskell. This entire post is borderline trolling and it's sad so many people are falling for it.
• danidiaz 6y ago
  I disagree with this: > One, types are a concretion. If you’re looking for higher level of abstractions to get flexible behaviour, you’re ultimately going to have a world of pain I don't see why types should be in the way of flexible behaviour. Frameworks like Spring in Java use types to direct dependency injection and it works well. Also this: > Types wrap data and treat it like a black box whereas schema describes the shape and content of data. Types can be made abstract and blackboxy, and sometimes that's what you want. But doesn't a record type give info about its fields? Doesn't a sum type give info about possible alternatives in the values? > As such haskell ultimately suffers a lot when they have to interact with the real world. Suddenly they are left reeling as they find out that the real world is, in fact, dynamic. The trick is to know what we are really modelling. If we are deserializing domain objects from JSON, it makes sense to have types for the domain objects. If we are writing a tool like, say, jq, perhaps we should merely have a datatype for the JSON tree itself: http://hackage.haskell.org/package/aeson-1.5.5.1/docs/Data-Aeson.html#t:Value http://hackage.haskell.org/package/aeson-1.5.5.1/docs/Data-A... > Bottom up design is something we’ve learnt collectively as a good way to be much more flexible in responding to change. Even if you want to design bottom-up, the moment you want to add anything to your program, you need a little top-down thinking, if only at the micro-level. You want to create something new that isn't there, and then think how to accomplish that with the tools you have.
• johtela 6y ago
  You can agree or disagree about the design decisions made by people contributing to Haskell language, but you have to admit that it's a pretty clever bunch of people. Haskell has contributed more to PL research in past few decades than any other language. That alone makes it a language every programmer should learn. Not because they should use it daily, but to learn what functional programming is in its purest form.
• ilikebits 6y ago
  Haskell has a lot of problems, but this article is not good, and does not describe them well. It reads like it was written by someone who has tried Haskell, and has sort of written some code in it, but has mostly been put off by bad and confusing tutorials, and has never really grokked the language. Indeed, look at the author's GitHub - of their 50 projects, only 1 is Haskell, and that is a handful of commits before giving up. My main complaint with Haskell is that it's actually a great language, wrapped up in (1) hilariously beginner-unfriendly syntax and tooling, and (2) a library ecosystem that does not quite understand the value of friendly documentation (although this is actually improving a lot). There are also some weird warts around the language itself, but those are mostly tolerable and not so much worse than the weird warts in all other languages. My specific complaints about beginner-unfriendliness in syntax and tooling: - The compiler will infer the types of names as generally as possible, and will run this inference both forwards ("this variable was assigned a string, so must be a string later") and backwards ("this variable is used as a string, and therefore must have been a string earlier") depending on what information is available for inference. This means that type errors are hit-or-miss; about 60% of the time, the type error will point you to your actual mistake, and the rest of the time it will point you to where the type inference algorithm got stuck in unification (this may not be the location you made your actual mistake, because the algorithm will try its best to infer concrete types working under the assumption that you didn't make a mistake, so it sometimes gets stuck trying to unify types at an earlier/later point than your actual mistake). - The syntax is VERY minimal, and prefers minimalism over readability. In particular, Haskell has no explicit parentheses for function calls, and has implicit currying! This means that it is very easy to accidentally get the arity wrong in a function call (for example, `foo (bar baz) quux` and `foo bar baz quux` mean very different things!), and create an extraordinarily confusing type error (in the best case, an error about applying things to the wrong number of arguments; in the worst case, errors about constructing infinite types). - This minimal syntax also means that you can sometimes type something that is _almost_ correct, but is actually valid syntax that means something totally different! Fortunately, your almost-correct expression will not type-check (so you won't ever mean something else without getting an error), but it's still a head-scratcher in the beginning to figure out exactly what the compiler is taking your code to mean. In some of these cases, you may even type something that is not syntactically valid vanilla Haskell, but _is_ valid Haskell-with-some-extension, and the compiler will unhelpfully suggest that you turn the extension on even though it may not be what you want (and also provides no explanation of the extension). - The compiler tells you what expression has a type error, but never actually tells you the exact term that has a type error. You have to sort of guess at this by understanding the rough high-level of how the type inference works. It's something you have to really pick up, and is hilariously unfriendly compared to e.g. `rustc --explain`. - Print-debugging works differently than what you'd expect. Nobody ever teaches you that `trace` is a thing (seriously, this should be thing #2 that is taught), and nobody ever teaches you "you're getting trace messages in a different order than you expect because Haskell is evaluating expressions with graph reduction, not in the order of the lines of code you wrote"). Really this boils down to: even though Haskell will do a very good job at preventing you from holding it wrong, you really do have to have a decent grasp on what you're doing to write a program. As a complete beginner, you can't just put something you think will mostly work and then rely on simple compiler errors to tell you where to spot fix (unlike e.g. Go, Java, etc.). Fortunately, this gets much better over time - you learn how to interpret compiler errors better as you get a grasp on the language, and you learn tricks for building incrementally correct programs up using `undefined` and friends. My specific complaints about documentation: - Contrary to this article, types actually ARE decent documentation in Haskell. The constraints you can do with types in a pure language are much, much stronger than in other languages you've used before. Trust me - this is a Blub paradox thing. It's just a qualitatively different kind of type safety. - Unfortunately, although types do a great job at preventing me from plugging the pipes together wrong, they still don't tell me anything about the _semantics_ of a function. Lots of older libraries do a very bad job at documenting semantics, but this is getting a lot better. - Arguments in Haskell functions are not named (or at least, their names are not exposed in documentation). This makes for some confusion sometimes - what am I supposed to pass as arguments to this `foo :: String -> String -> String` function? - Lastly, a lot of libraries document very academically. Here's an example: https://hackage.haskell.org/package/logict-0.7.0.3/docs/Control-Monad-Logic.html https://hackage.haskell.org/package/logict-0.7.0.3/docs/Cont.... The documentation here is written assuming you understand how Logic computation works, provides no examples, and you're supposed to read the module documentation and actually go and _read the paper_ (in fairness, it's pretty short) that they've linked. This is a far cry from the NPM world (which, for all its faults, has really embraced accessibility in documentation), where everybody has a quick start. Overall though, it's a really good language. Once you get monads (and a HUGE part of this is not the idea of monads, but the really unfriendly syntax and error messages of Haskell; IMO the _real_ lightbulb moment is grokking the difference between data, types, data constructors, type constructors, and typeclasses), a lot of things make a lot more sense. The testing story is amazing, the refactoring experience is amazing, the incremental development and REPL stories are great, and there are some truly astounding abstractions you can use that are just impossible to express in other languages. It's my regular side project driver, and my team maintains a Haskell codebase in production. Lastly, a word of advice to anyone looking to actually make a good-faith evaluation of Haskell: try it, make something substantive with it, and stick with it until you actually grok it. Ask for help from the FP Slack! Seriously, don't just pick it up, get stumped by error messages, and give up. The tooling is very beginner-unfriendly, but fortunately the humans over at the Functional Programming Slack (https://fpchat-invite.herokuapp.com/ https://fpchat-invite.herokuapp.com/) are VERY friendly. As a first project, I'd recommend doing the Advent of Code, or building a small web application (IMO with Scotty, which feels like Express, rather than Yesod, which feels like Rails. Yesod is almost certainly better in production, but has a different and IMO less instructive learning curve). If anyone needs help, follow along with my AoC 2020 (https://github.com/liftM/advent2020 https://github.com/liftM/advent2020), although be aware that some things I do there are a bit fancier than necessary. I find that articles like this that complain about things like type abstractness or the mathy concept names really are not representative of the actual pain points with Haskell, and are FUD more than useful. Yes, the tooling is beginner-unfriendly. Yes, you will probably need to ask some questions on the FP Slack on your path to learning, things that a friendlier language would have documented. But this mystical aura of "ooh, there are types and they are very abstract!" is not reflective of reality, is not a criticism grounded in the reality of writing Haskell, and IMO is misleading for people genuinely trying to assess the language.
• ColinWright 6y ago
  I have coded in Haskell, although only to get a sense of it, and quite a long time ago. I'm not going to pontificate about it here, but I would love to be able to filter these comments based on the length and depth of experience of the commenter, both in Haskell and other language of choice. There's a lot being said here that's true, and a lot that's personal opinion. I'd love to know the personal experiences that drive those opinions. Alas, I suspect we will get the opinions, but no way to assess how accurate they might be.
• dathinab 6y ago
  In my opinion the problem with Haskell is that terminology from computer language research (e.g. type theory) bleed into language which combined with sometimes appearing "elitarism" makes it just not very appealing for anyone not being deep into the relevant parts of computer since research. I mean I don't need to know how engineers speak about the internals of my car to drive it (but it can be helpful), but Haskell kinda expects that. Also it's not uncommon in Haskel to see functionality named not after what it does but after the theoretical computer since properties it has. Which might describe how you can combine it on a type system level but isn't that useful for easily writing programs and makes any "types as documentation" much worse.
  • FridgeSeal 6y ago
    I suspect this is because Haskell is proudly a "research"/bleeding-edge language. It's distinctly _not_ a Java or a .Net and that's ok, as it's not trying to fulfill the same role. Things in Haskell have names from theoretical computer science, because people are using it to express and experiment with those ideas - they don't need or want to spend undue time describing a monad or a functor for the 15-millionth time, they want to use them in some new cutting-edge way. I once saw (on this website) Haskell described as "the primordial soup of programming language features". Wild and weird ideas get tried-out in Haskell, and then 5-10 years later someone takes the lessons learned from the evolution of some feature in Haskell and brings it to mainstream programming in some elegant, distilled form. And I think that's super cool.
  • sfvisser 6y ago
    Haskell has many problems, but this really isn’t one of them.
  • sordina 6y ago
    Please keep in mind, when Haskell introduced some of these features they decided to take existing terminology from theory rather than make something up. The big benefit from this is that people already with the theoretical terminology have an intuition to start from, plus, users of the language also build some intuition for the theory. Win win. Given that they often broke ground on the features and couldn't borrow from other languages can you say this was a bad decision?
• colonwqbang 6y ago
  > Abstractions with types is a bad type of abstraction because it ignores the basic fact that programs deal with data, and data has no types. Or in the conventional Haskell notation: data HasNoTypes = BasicFact Yet, everyone is busy adding typing to their favourite dynamic languages. Even languages like Javascript which whose designs show open contempt for the idea of type safety, are now getting support for static typing (typescript/flow).
• dotdi 6y ago
  > A very clear indication of this is how Haskell treats programming terms. Instead of explaining Monads like all other design patterns out there, they insist on using some obscure definition from category theory to explain it. The author is bashing people for explaining a concept from Category Theory with... dum dum dum... Category Theory?! Just because OP was looking for articles explaining monads as design patterns doesn't mean there aren't other people who, God forbid, are looking for theoretical articles about CT/Monads explained with Haskell. Yes, there is value in pragmatism. Rant posts, on the other hand, have little value IMHO. Haskell has shortcomings like any other programming language. That absolutely does not make it a bad programming language.
  • dathinab 6y ago
    > Rant posts, on the other hand, have little value IMHO. Sure ;=) But Haskell's explanations of Monads is in my experience really no adequate. Category Theory is the underlying since theory, but do you need to know about mechanics and gears to drive a car? There are explanations of Monads which are much much easier to understand for most people (people not having much to do with Category Theory). E.g. by now the concept of map, flat_map is fairly wide spread in most programming languages and you can teach about Monads in terms of that fairly easy. And then add the additional abstraction layer used in context of Monads like abstracting over the "external world state" (IO) and "combining computation descriptions".
    • dotdi 6y ago
      > but do you need to know about mechanics and gears to drive a car? Depends on what you are trying to do. You don't need that knowledge in order to drive a car, but there are drivers that absolutely should know about mechanics and gears.
    • davorak 6y ago
      > But Haskell's explanations of Monads is in my experience really no adequate. Category Theory is the underlying since theory, but do you need to know about mechanics and gears to drive a car? Monads are part of the underlying category theory. So asking for a full explanation of Monads you are asking to explain part of the "mechanics and gears" in your car analogy. > E.g. by now the concept of map, flat_map is fairly wide spread in most programming languages and you can teach about Monads in terms of that fairly easy. And then add the additional abstraction layer used in context of Monads like abstracting over the "external world state" (IO) and "combining computation descriptions". I think I agree with your main point here that teaching the internal details first is often not the optimal method. You do not need to know how Monads work to use them to great effect in Haskell and other languages.
• cuddlecake 6y ago
  I feel like being Anti-Haskell is becoming a ridiculous meme. The author makes a lot of statements, but no arguments, no proofs, and no explanations. Also, the post is riddled with "The Community does X" memes, such as: > Funnily enough everyone in the Haskell community blamed everyone else instead of [...] > [Senior Developers tell you to just] write types and interfaces for the types and fill in the blanks > Look, even most haskellers would agree that purescript is a better choice compared to GHCJS > [Haskellers are] using some obscure definition from category theory to explain [Monads] > Haskell proponents try to claim that type signatures are somehow documentation > Every few months some newbie comes along to the Haskell reddit and asks why is Haskell documentation so confusing, and the post get destroyed by people telling them to get good or just pointing at academic papers. Really? > suddenly their precious castle [of type declarations] is reduced to dust and the author does not give a single link or concrete example, not a single proof or evidence of this actually being the case. In the author's defense, I would also think that the Haskell Community behaves exactly like that, if I had taken every comment on HN about Haskell as being correct and truthful. One very absurd claim by the author that I'd like to point out is: > programs deal with data, and data has no types All data has a type (structure, schema, intent), otherwise it wouldn't be data. Instead, it would be electrical noise. > Types wrap data and treat it like a black box whereas schema describes the shape and content of data. I don't understand why the author makes a distinction between "types" and "schema". I get the feeling that the author makes the distinction only to bash on Haskell because Haskellers will talk of "data types" and not of "data schemas". > Suddenly they are left reeling as they find out that the real world is, in fact, dynamic. That's why Haskell has `Maybe`, duh. I don't buy into the statement that the "real world is dynamic". It's just as slogan-y as "The Real World is Object-Oriented", because it seems to be trivially observed, BUT, programming is not the Real World. One programmer has a data type that he/she sends over the wire. It would be weird if another program didn't anticipate the data but could still handle it correctly without expecting the data to have a certain type. Programming is not dynamic, programming is guessing "what the fuck did the other programmer try to send me" and defining a type for that. This is done either implictly by just accessing the fields or explicitly by defining the type and parsing the data. --- All in all, I feel like this post adds nothing in value, and I am very annoyed that it has been ranked #1 on HN, but this stays consistent with how I personally perceive the broader HN Community. Sidenote: I am not a Haskell Developer.
• dathinab 6y ago
  I'm not sure why the article hates on types that much I mean: - schemas are types - types do not require encapsulation ("even" in java "plain old data" type which do not give any encapsulation are a thing) - many popular languages without static type ascription have by now added optional type ascription or there exists a derivative which do so which are recommended for larger projects (e.g. TypeScript and python3 type hints) - I can understand why people might not like nominal type systems, or to many explicit type ascription. - In my experience when maintaining & changing software having a proper type system is making the task easier and faster (if the type system is not abused, idk how common type system abuse is in Haskell). And in my experience non nominal type system as seen in TypeScript are already helpful making changes easier then in JavaScript. But it's still harder to change (larger projects) in TypeScript then e.g. in Rust (assuming the type system was not abused!!). - To be fair abusing type systems is in my experience often worse then not having a nice type system.
  • cannabis_sam 6y ago
    I used to hate on types, largely because I had mostly learned to program in Java, where you hade to write the name of the type twice just to initialize an object, and just the general tendency in Java to rely on explicitly specified types everywhere. I felt that the value gained from all this extra work was minimal, so when I got into Python it felt like being unshackled from utterly pointless chains. After around 10 years of developing in Java and Python/php, I learned Haskell, and realized that types are only shackles in languages that refuse to utilize them in an efficient and useful manner (i.e. type inference instead of endless type specification or type casting at every point of mutation. And don’t even get me started on the destructive horrors of automatic/implicit type coercion..) In Haskell, types feel like the nubs on jigsaw puzzle pieces, guiding you to what (potentially) fits together, which drastically reduces the amount of programming details you need to keep in your head, so you can focus on the actual, fuzzy, real-life semantics of the system your developing.
• dgellow 6y ago
  One niche I'm curious about is the use of Haskell for blockchains and smart contracts. Cardano is one of such project: https://docs.cardano.org https://docs.cardano.org. It's still very experimental and won't have smart contracts before March/April of this year (likely to be later). The blockchain and their smart contract DSLs are implemented in Haskell, that will be interesting to see how that compare to what Ethereum is doing with Solidity.
• kodefant 6y ago
  About Haskell missing pragmatism, ever tried IHP? I don't think the development environment sucks, but you are free to disagree. In my opinion, the developer experience is ultraslick, it's easy for beginners to get started with and there is very little type theory to getting started. Yes, Haskell has been bad at teaching to beginners, by forcing people to learn theory before build something, but it has been really catching on for the better recently. I think a "bad" and "good" programming language can be subjective, but I have never tried more enjoyable languages than Elm and Haskell. I feel confident using these languages because of the static types. Some will probably say that the usefulness of types is an illusion and I can live with that, but I don't think it is.
• js8 6y ago
  IMHO, Haskell is a bridge between practical programming and mathematics. That's why they use "monad" instead of "flatMappable", for example. It is connecting two different languages that cover the same concepts. Regarding types, there is a talk from Gilad Bracha titled "Types are antimodular", and it makes a similar argument as the article.
• nvarsj 6y ago
  Haskell has plenty of legitimate criticisms for use as a production language. However this article isn't it. Please don't read this and repeat the opinions posted here. A lot of what the author says is just plain wrong and shows a misunderstanding of basic functional idioms. For example: "Functors are basically an Object with a internal state changing method in typical OOP terms." Uh, no. Functors are stateless, with a well defined semantic. This is nothing like an object with internal mutable state, with instance methods that mutate it in god-knows-what-way. There are a lot of mischaracterizations like this in the article.
  • nix23 6y ago
    >>Haskell is not too hard to learn. Obviously he did no even that then.
• IshKebab 6y ago
  Hard to disagree with the premise, but the rambling that follows doesn't exactly argue the case very well.
• fbn79 6y ago
  I think we can find many analogies between the history of "Haskell/FP vs Mainstream Languages/OOP" with that of "RISC vs x86/MIPS". The article says Haskell is hard to learn/use and not appetible for business. A similar article could be written about RISC architecture in 2007 when x86 ruled. Then Steve Jobs built the iPhone and with it an empire based on RISC architecture. And now Apple Silicon it's threatening desktop and servers, last standing of X86.
• cute_boi 6y ago
  > "When you’re reading this article, or talking to someone, do you claim that you’re saying a string, a number, a Text, or something else. No! Data is simply data, and data is inherently dynamic" I think I disagree with this one. Yes data are inherently dynamic but every data usually have types associated with it. For me type is like rule. Eg u8 is a 8 bit unsigned int which is 0-255 is just a rule. In English we have grammar which is rule or another type so to speak. a-zA-z etc doesn't make meaning on its own but a combination of rules make it meaningful and beautiful. Thank You.
  • madsbuch 6y ago
    The article is generally imprecise, and I completely agree with you. Stating that `... data is inherently dynamic` in this context is plain and deductively wrong. If we can not add type to data, we can't even interpret it as a bit-string because, hey, it's a type! (the type of a string of 1's and 0's) Types are mostly used to reason about a program internally. But sometimes we need to consider the real world. When doing do we need to interpret data. In the Haskell-sense this means assigning types to it. A language like Elm has exemplified how the internal / external data barrier can be implemented for strictly typed languages. Haskell just considers everything a string and lets it be up to the developer to parse it.
• 414owen 6y ago
  I'm very sorry OP didn't stay the course, and opted to write an angry post instead. > Every few months some newbie comes along to the Haskell reddit and asks why is Haskell documentation so confusing, and the post get destroyed by people telling them to get good or just pointing at academic papers. The Haskell subreddit has a monthly 'Hask Anything', and is generally a friendly forum. I searched: https://www.reddit.com/r/haskell/search/?q=documentation%20&restrict_sr=1 https://www.reddit.com/r/haskell/search/?q=documentation%20&... and was unable to find any such behavior. In fact, people asking for documentation were generally helped: https://www.reddit.com/r/haskell/comments/eo7orr/where_to_find_documentation/ https://www.reddit.com/r/haskell/comments/eo7orr/where_to_fi... > “Haskell doesn’t suck, the development environment does” There are certainly people who would agree with this, however our language server is pretty complete nowadays, we have amazing static analysis tools, a variety of formatters, I can't think of any tooling I desperately miss. Then again, I'm an editor person, not an IDE person... > Write types and interfaces for the types and fill in the blanks. Sounds familiar? Because that’s we’ve been doing with Java and the like using UML Ouch. It's very rare to hear anyone complain about having a type system with strong guarantees. UML... Well I guess I'm not a fan of specifying your design outside of your source code... > Professional developers find themselves describing the system in such concrete ways using types that when the requirements change suddenly their precious castle is reduced to dust Hmm, so generally the better at Haskell you are, the more you express constraints in terms of Haskell constraints, rather than concrete types. It's a style called `Tagless Final`. I recommend taking a look. It gives you strong guarantees, without breaking any castles. > Somehow Haskellers think that they are more productive with Haskell when the reality in the real world is that only a few languages can proudly make that claim, such as Python and Lisp. These are languages battle tested in actual software products As other people have pointed out, there are companies that use all three of these. I think it's safe to assume OP didn't measure the productivity of any developers before writing this. > Abstractions with types is a bad type of abstraction because it ignores the basic fact that programs deal with data, and data has no types Have you heard of datatypes? > In most cases people are looking for schemas, not types Schemas describe the structure of data. Types describe the structure of data. > Types wrap data and treat it like a black box whereas schema describes the shape and content of data The former here is actually more of a slight on encapsulation, which is something you can do in Haskell, but is probably more a goto recommendation of OOP languages. It can be pretty useful to only expose the inferfaces you want, and hide the implementation. > most haskellers would agree that purescript is a better choice compared to GHCJS. No man is an island, and yet Haskellers generally convinced themselves that other languages need to learn from Haskell Are you saying Purescript didn't learn from Haskell? Have you seen PureScript? > Instead of explaining Monads like all other design patterns out there, they insist on using some obscure definition from category theory to explain it Pick a monad explanation that suits you. There are plenty of posts / tutorials online. Some people like burritos, some people like mathematics. I recommend looking at the type of (>>=), as in the end, that's the only operation a Monad adds (above Applicative)... > Look, when monads are used without the infix notation, the result is horrendous and it looks like yet another callback chain I think you mean when they're used without `do notation`. This point seems moot, seeing as we have do notation. Explicit binds can be readable, if you're going pointfree. > I tried it myself. Of course, there are very smart people who do understand Monads, but most people would just tell you to “get an intuition for it”, which to be honest is total BS You'll get there, I recommend leaving the do-notation behind, and writing some functions over Maybe, [], and Writer. Don't give up on the learning process, there's still time to write a `How I learned Haskell` blog post, or maybe you can write the umpteenth Monad tutorial :)
• pi-victor 6y ago
  i would say, that because it is a hard language to learn, it holds itself back. otherwise it would thrive, people would be interested in it, libraries would flourish. I feel Rust is somehow in the place as well, it has a rather steep learning curve and there are not enough mature libraries out there because of this.
• mark_l_watson 6y ago
  I have been playing around with Haskell for many years, and wrote a short Haskell book. That said, I still consider myself a newbie at the language and have only used it for customer work one time. Many years ago, I set aside learning Scala for a while, dug into Haskell (again), and for reasons that I don’t even understand myself, I then had an easier time using Scala. Same comment for Clojure (not my favorite language by far, but I have used it often professionally). One thing resonated in the article “Very senior Haskellers calls for “type oriented programming” which goes like this: Write types and interfaces for the types and fill in the blanks.” I prefer just using simple types, and one thing I like about Clojure is just using the built in simple data structures. In any case, I think it is very worthwhile using a wide variety of languages but I understand it when other people prefer to not spend the resources experimenting.
• zacwood 6y ago
  I discovered Haskell in a comparative programming languages course I took at university last semester, and it completely changed how I think about programming. I can't speak for an industrial use case, but for a hobbyist writing open source software and personal projects, programming in Haskell has been an absolute joy and has reinvigorated my love for programming. Tools like IHP (https://ihp.digitallyinduced.com/ https://ihp.digitallyinduced.com/) are a great example of not only the beauty of the language, but when combined with Nix and the IHP IDE, a better development experience than I ever had with Rails or any other language. If you are pragmatically minded, you can get stuff done in Haskell. In my experience there's a lack of online resources for this kind of work in Haskell, but that's what I and others especially in the IHP world are working on. If you just want to experiment, Haskell is great for that too.
• voidhorse 6y ago
  Haskell has it’s fair share of problems, the major one being pointed out in this article, that in spite of all of SPJ’s noble efforts it’s still primarily stuck in the “ivory tower”, bogged down by tons of libs and docs that are full of academic or theoretical jargon, and unfortunately plagued in some sub communities, by people that have intellectual superiority complexes, which makes it alienating to a large number of potential users and leads to bitter posts like this. But in terms of the language itself, I really don’t see the issues raised here and the author of the article comes off as having not understood the language very well. Libraries like Euterpea show that the language is insanely expressive and that they’ve, IMO, created a language that is very solid from a language design perspective. Sure there are wrinkles like records, but otherwise it’s generally pretty great from an expressive power standpoint. Communication only works when people are speaking the same language. Of course you are going to struggle when that language is different than what you are used to (lazy, functional, pure) but if you spend time in language classes and eventually learn it, you’ll find that you can probably communicate your ideas just as well in this language too. If you decide you don’t like the sound of the language then don’t communicate in it, but that’s your choice, it’s not a knock on the language itself. This article feels like it was written by someone that struggled to learn Haskell and gave up and ranted about it rather than persevering or simply deciding it wasn’t for them and moving on. If you are comparing functors to objects in OOP I don’t think you actually groked it.
• jtdev 6y ago
  Functional zealotry seems to be at the core of most problems with Haskell. It’s unfortunate that these concepts keep being shoehorned into numerous other languages.
• Ericson2314 6y ago
  > abstractions ultimately leak This is where they really loose me. No, they don't. Only bad abstractions leak. How did real limitations with statistics ("all models are wrong, some are useful") mutate into pessimism about designed, not discovered, systems? When did we all become such mindless empiricists?
• nix23 6y ago
  >Spoiler alert. It did not. Really? https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry
• carapace 6y ago
  In re: Haskell's goodness or badness, compare and contrast with, say, PHP (crap language with wild success.) Or Prolog (a stately Elven language with deep but obscure success.) Haskell is what it is. In re: types and data, FP is good for that. See e.g. "Domain Modeling Made Functional" by Scott Wlaschin ( https://www.youtube.com/watch?v=Up7LcbGZFuo https://www.youtube.com/watch?v=Up7LcbGZFuo ) it's about F# but the concepts apply cross-language. In re: FP PLs "done right" I submit Elm lang. I've been using Elm recently and it gets the job done. It's weird though: on the one hand, as a experienced professional it feels like a toy. The error messages feel almost insulting, like I'm being patronized. On the other hand, once I got over that (silly) reaction, they're awesome. Changing code is a breeze, because Elm leverages the crap out of the type system, and the structure of the code and runtime prevent whole vast categories of errors. Combine that with the sort of Domain-Driven development that Wlaschin is talking about and "baby, you got a stew going!"
  • KurtMueller 6y ago
    I was introduced to OCaml through Elm - a deeply-opinionated language with strict guard rails. In Elm, there is either a happy path or there is no path. As a newcomer, you're not overwhelmed or paralyzed with a plethora of choices on how to get things done simply because Elm limits your choices. Each tool in your toolbox is documented with simple examples how to use that tool. After finally jumping the fence and exploring/devving with other OCaml languages (specifically F#), I still come back to Elm to see how it and the community does things: namely their best practices and explanation of fp concepts.
• butterisgood 6y ago
  I can't believe how much I like this font choice on that blog post!
• ur-whale 6y ago
  Haskell : because there must be a place where ivory tower mentality folks can convene in peace.
• butterisgood 6y ago
  I find the "I'm more productive with Python" claim in the post to be specious. Maybe I've been abused (and abusive) by bad programming practices with python in the past, but it seems you really need to lint and exercise python code to have any kind of confidence that something you think is correct won't blow up at runtime. False confidence that something is "ready to go", is the worst, and it can cost a lot of money, and sometimes human life. Erlang has this problem too. It's so late binding you can make spelling mistakes and it won't be caught until runtime. It's actually the basis of some very powerful features, but you really have to know that coding in Erlang is not like coding in Rust, Haskell, or something else strongly typed. So while I think the author has a point that concretions can get you into an inflexible, hard to refactor mess over time, I think sometimes those concretions don't have to be as bad as they seem. Consider Go. Interfaces are a form of concretion too, but the advice is to keep them small. An interface of exactly one function can be a beautiful thing. I think it's better to have a type implement many interfaces than to have a type implement one huge interface.
  • adsharma 6y ago
    python3 has type checkers. I like pyright. You can use protocols which are similar to Go interfaces. The benefit of go is really in performance and packaging.
• psychometry 6y ago
  I've gotta say...the font (Magnetic Pro) used on this site might be one of the worst-designed typefaces I've ever seen. It honestly looks like a random mixture of two bad typefaces.
• daxfohl 6y ago
  So if we were to create something new and Haskell like (pure, closer to Haskell than OCaml or Rust), then what should be different?
• bluepoint 6y ago
  Does it explain why I got truly fascinated by Haskell and at the same time I did not feel like writing any useful program in it? (not that I ever write useful programs, just saying).
• adsharma 6y ago
  Counter point: This has nothing to do with the programming language in question. The anti-abstraction, everything must be concrete argument leads to madness. You can do type oriented design with python3 or typescript. Since writing this, I've discovered other systems with the same general philosophy: * Avro IDL * Fuschia/Zircon and the associated IDL (FIDL) https://adsharma.github.io/flattools-programs/ https://adsharma.github.io/flattools-programs/
• whateveracct 6y ago
  I know Go. I know Rust. I know Haskell. Any project I have built with Haskell, I could have with any other language. Maybe even faster (for some definitions of fast) But not with as little personal labor. I've found that no matter the scale, Haskell allows me to solve it without effort. Because I'm not jerry-rigging commands to do what I want. I just eventually Solve the problem. I say this as a computer engineer, so "how the computer works" is my training. But god it's nice to build things without the inherent manual labor of imperative programming.