23 ms·

I tried Haskell for 5 years

• anorphirith 10y ago
  we should forbid click bait titles on HN, it's an insult to the audience's intelligence Clickbait title are so common we think they're normal titles.... Here's how he did it: you create a craving for an answer then you offer a solution for that craving. "here’s how it was" ==> that's the trick Also "here’s how" should never be used in a title, we all know that the title's subject IS what you're going to talk about. a pre-click bait era title would have sounded like: Learnings after using Haskell for 5 years
  • marvy 10y ago
    Do you think this title is clickbait? I just read the thing it seems like a good title.
    • dualogy 10y ago
      It's "baitish-feeling at first", just missing the tailing "and here's what happened" --- but --- at this point I think this style is just starting to become assimilated into general "unintended" blogging/writing style.. The other day, I saw some Medium post titled "Functional programming will make you happier". I was furious and about to blast some diatribe on the increasingly infantile-inanity-inflation-in-headlines but looking at the post, the author seemed genuine in taking the troubles to work out their thoughts to the reader, so I refrained.. tilting at windmills, increasingly people are simply growing up with these sorts of titles and develop a primal instinct for what gets attention and clicks --- aka, reads.
  • hyperhypersuper 10y ago
    While this title follows a particular style it actually tells you what the article will be about (5 years of Haskell). What bothers you about it?
    • ajkjk 10y ago
      It's clickbaity because you have to click to find out if their opinion is highly positive or negative. It sounds like it's going to be answered by "... terrible" or "... great!", and that it's phrased that way to make you click and find out. Granted, once you click you find out that's not why it's titled that, but you still feel baited into clicking to find out. A better title would be something like "I tried Haskell for 5 years and here's the good and the bad", or something like that.
      • leshow 10y ago
        It's hardly clickbait. Clickbait would be a purposely inflammatory or exaggerated title to get you to click the link. This is the complete opposite of that. > It's clickbaity because you have to click to find out if their opinion is highly positive or negative. I think you just stated the purpose of a title. Wiki says clickbait is: > "... relying on sensationalist headlines or eye-catching thumbnail pictures " There's nothing sensationalist about. "I tried Haskell for 5 years". It's rather banal.
  • paulddraper 10y ago
    We should, and we do. This title is on point: The author used Haskell for several years, and found there was a learning curve, some helpful libraries, some poorly documented libraries, lots of historical baggage, unclear performance consequences, and uncommon correlations (good and bad) between task and difficulty.
  • danso 10y ago
    The title is not only accurate but it is stylistically appropriate in this case as the author is making an explicit criticism of the type of post where an author tries something for a few days and blogs about it.
  • deleted 10y ago
    [deleted]
• davidrm 10y ago
  This has been the most disappointing blog post I have read in quite some time.
  • scardine 10y ago
    Do you care enough to share why is it disappointing for you?
  • vadman 10y ago
    Why? The author didn't crap nor fawn all over the language. He highlighted what he thought were important quirks of the Haskell ecosystem/community/whatever, in a measured manner, while noting that if you invest time and effort you can indeed produce relevant output. Should one dive in given those quirks? The decision is up to the reader. Curious, what did you expect/wish for? EDITED for better phrasing.
• choxi 10y ago
  If anyone's curious to try out functional programming, I would highly recommend Elm. I haven't been so excited about a language since I went from C to Ruby ten years ago, and Pragmatic Studios has a great course on it (I have no affiliation): https://pragmaticstudio.com/courses/elm https://pragmaticstudio.com/courses/elm
  • cbrewster 10y ago
    I would also give a recommendation to elm. It is like a simpler version of Haskell and its relatively easy to build something quickly(no affiliation either). I always had a hard time wrapping my head around functional programming, but elm was easy to understand and shows off the strengths of a functional approach.
  • deleted 10y ago
    [deleted]
  • nijaru 10y ago
    And Elm is implemented in Haskell ;] I've been meaning to try Elm since I've been playing around with Haskell more and more. Purescript is relatively similar but allows you to build more than frontends. It seems Elm has grown quite a lot in popularity though.
    • dmix 10y ago
      PureScript has great potential. I'm very excited for what it offers the future of Javascript and even Haskell. It's on a whole other level than Elm. The only problem from my experience trying to use it in a project is that since it's alpha software a) it's changing so fast that APIs/libraries are very unstable to the point they are almost unusable if you try to follow newish releases (this was 6-8 months ago, I hope/expect stability has improved) and b) you have to be intimately familiar with Haskell. As the OP's article describes about Haskell with PureScript the documentation situation is even worse, the documentation is 90% "hard" and 10% "soft". Which is fine if you know Haskell, or even a bit of Elm, but it's very tough coming in as a newbie of both Haskell and PS.
  • melling 10y ago
• m-j-fox 10y ago
  > very hard to understand why a function could be useful in the first place So true. https://hackage.haskell.org/package/base-4.9.1.0/docs/Control-Monad-Fix.html https://hackage.haskell.org/package/base-4.9.1.0/docs/Contro... > mfix :: (a -> m a) -> m a > The fixed point of a monadic computation. mfix f executes the action f only once, with the eventual output fed back as the input. Hence f should not be strict, for then mfix f would diverge. But why tho?
  • z1mm32m4n 10y ago
    By analogy to fix: fix f --> f (fix f) That is, to compute the fixed point of some function f, we give f access to the fixed point (i.e. fix f) in order to compute the fixed point. Consider f is strict, and that we try to run this: fix f --> f (fix f) --> f (f (fix f)) --> f (f (f (...))) Why? Because if f is strict it has to evaluate its argument before evaluating the body. On the other hand, if f is non-strict, we can evaluate its body without evaluating its argument first. mfix generalizes fix to monadic functions. When we have monadic functions, we're usually dealing with side-effectful computation, so we want to make sure that we only force the monadic action f once, so that the side effects only run once. --- Another question to ask is "what is fix even useful for"? fix is how we introduce general recursion into a language. For example, the lambda calculus has fix, except it's called the Y combinator. Compare: Y f --> f (Y f) fix f --> f (fix f) The lambda calculus is Turing complete because it has this general recursion. fix is often used in smaller toy languages to also make them Turing complete, because this form of recursion is straightforward. While Haskell has recursive function definitions, fix (and mfix more generally) are sometimes useful in their own right.
    • dllthomas 10y ago
      I think you answered the wrong "why".
  • ashark 10y ago
    Ubiquitous single-letter symbols mapping to who-knows-what possible things, pnflly abvted fncn nms, and unclear motivations for code are what I've bounced off of with Haskell every time I've tried to dig in. The community seems to have adopted all the worst parts of mathematics culture, along with whichever good parts they've brought in.
• hzhou321 10y ago
  > 1. There is a learning curve. Time and experience can cover up anything. So this does not say much about Haskell other than it is all negative without time and experience. > 2. Haskell has some very nice libraries So does NodeJS and (on an abstract level) Microsoft Word. Libraries are infrastructures and investments that (like time and experience) can cover up any shortcomings. > 3. Haskell libraries are sometimes hard to figure out That is simply negative, right? > 4. Haskell sometimes feels like C++ That is also negative, right? > 5. Performance is hard to figure out That is also negative, right? > 6. The easy is hard, the hard is easy That is a general description of specialty -- unless he means all hard are easy. > 7. Stack changed the game Another infrastructure investment. > 8. Summary: Haskell is a great programming language. ... I am a bit lost ... But if I read it as an attitude, it explains a lot about the existence of infrastructure and investment. Will overcomes anything.
  • codewithcheese 10y ago
    I feel the same way. I think the Author was trying to give an honest opinion on the pitfalls. Would have been nice to hear about the honest benefits too.
  • scardine 10y ago
    I don't think being like C++ is a negative and it is far easier to learn compared to Haskell.
  • hvs 10y ago
    Every time I've tried to dedicate time to really learning Haskell, I've come away with the feeling, "If I was a lot smarter or had a lot more time to dedicate to it, this would be a fantastic language to develop in after about 2-3 years." The way that functions can compose in the hands of a gifted developer is truly elegant. That said, I'm not sure it's a skill that translates well to the general development community (and maybe that's fine?).
    • BoiledCabbage 10y ago
      Out of curiosity, what method/resource did you use to try to learn it?
• matt_wulfeck 10y ago
  > The same is not true of Haskell. If you have never looked at Haskell code, you may have difficulty following even simple functions. Why is it that people talk about this almost as if it's done virtue of the language? As if the fact that's it's so inscrutable proves that it's valuable, different, and on a higher plane of computing.
  • gkya 10y ago
    Not that that's a virtue, but it's a proof that it's a different thing.
  • AnimalMuppet 10y ago
    I didn't read it that way at all. I read it as acknowledging the syntax as a problem in the beginning, but claiming that it became much easier to read once you really learned the language.
  • jdreaver 10y ago
    You are reading into that way too much. The author is just saying the syntax is a lot different than languages you have probably used before.
  • deleted 10y ago
    [deleted]
  • tikhonj 10y ago
    The point is that it's not inherently inscrutable—it's different. And being different is a virtue: at the very least, you'll learn something from Haskell, and it's going to let you do things other languages won't. It's not just an Algol reskin.
    • tormeh 10y ago
      If it had Algol syntax and Algol naming conventions it might actually have succeeded outside of academia. The decision not to go with an Algol-derived syntax was probably the biggest mistake ever done in Haskell's design.
• gjkood 10y ago
  Question to the Haskell experts here. Is Haskell more academic in nature or used heavily in Production environments? Is there an application sweet spot/domain (say Artificial Intelligence/Machine Learning, etc) where it shines over using other languages (I am not talking about software/language architectural issues like type systems or such)? I have no experience with Haskell but do use functional languages such as Erlang/Elixir on and off.
  • moomin 10y ago
    Application sweet spot is a funny thing, because it's mostly determined by the presence of specific libraries. What Haskell has more than anything is ridiculously general libraries. It's got perfectly good libraries for web development, Postgres access &access, but the only place I'd say it's got a real application-specific strength in libraries is parsing. Weirdly, what Haskell is good at is generality. Which is much the same as for LISP. I'd say the Haskell community remains academic/hobbyist, but that's not to say there aren't plenty of people doing Real Work in it.
    • gjkood 10y ago
      Ok, so the generality like LISP/Scheme with a few basic productions/rules and some basic operations could be used to create/represent any levels of complexity. Something like Northhead & Russell's Principia Mathematica.
      • platz 10y ago
        I think painting Haskell as a LISP but in a blank-slate world without packages is not quite accurate. There is a large library of existing packages that take you beyond the language's primitive constructions.
      • moomin 10y ago
        Yes, and that's why you're often scratching your head at the function definitions: they're extremely general solutions to general problems. This, in conjunction with the documentation issue means that often you end up getting referred to papers, which does nothing to help the "only for academics" impression.
• deleted 10y ago
  [deleted]
• jes5199 10y ago
  Haskell: where difficult problems are trivial, and where trivial problems are the subject of ongoing academic research
  • adamwk 10y ago
    The Sieve of Eratosthenes is a good example of relatively trivial in imperative code but a research paper in Haskell.
    • ahakki 10y ago
      I am pretty sure the sieve can be written like this in Haskell, which might be a bit short for a research paper: sieve :: Integral a => a -> [a] sieve l = sieve' [2..l] [] where sieve' (p:ns) ps = sieve' (filter (\x -> rem x p /= 0) ns) (p : ps) sieve' [] ps = reverse ps
      • adamwk 10y ago
        That's not the real sieve, though. It doesn't cross off pre-visited primes and is incredibly inefficient. Try finding just the 19th prime. Here is the paper on the real sieve, https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf
        • Confusion 9y ago
          And it's exactly the same thing with the classical beautiful functional example of quicksort. It's not actually quicksort and its performance is awful as a result. Haskell has trade offs.
      • hzhou321 10y ago
        Some ideas on how to make it into a research paper -- add discussion on how do you trivially manage memory (avoid unnecessary allocation and copying and reversing). The original trivia idea was simply to sieve in place. So how do we do that in Haskell (hint: invent something)?
• nabla9 10y ago
  > Performance is hard to figure out 1000x changes in performance is not a problem if: 1. Performance of one module is not overly dependent on the code that uses it. 2. Performance never degrades order of magnitude with new compilers.
• arnon 10y ago
  We have a code base of roughly 200,000 lines of Haskell code, dealing with high performance SQL query parsing, compilation and optimizations. I only remember one situation over the past 5 years that we had a performance issue with Haskell, that was solved by using the profiling capabilities of GHC. I disagree that performance is hard to figure out. It could be better, yes - but it's not that different than what you'd get with other programming languages.
  • luispedrocoelho 10y ago
    (OP here) I do say it's not that big of a deal in the end: it almost always is OK and at the end you optimize the inner loops by looking at profiles; like in any other project. But when using GHC, I have indeed sometimes ran into situations where I expect something to be fast when it is not (e.g., `ByteString.map (+ value)` is incredibly slow compared to a pseudo-C loop). I also did find a bona fides performance bug in GHC https://ghc.haskell.org/trac/ghc/ticket/11783 https://ghc.haskell.org/trac/ghc/ticket/11783
    • arnon 10y ago
      GHC isn't magical. It has bugs too. We had an issue with the Data.Text package and OverloadedStrings in 7.10.2 which caused extremely slow compilation times and filed a bug report for that, which was solved for 7.10.3.
    • codygman 9y ago
      > (e.g., `ByteString.map (+ value)` is incredibly slow compared to a pseudo-C loop). That situation sounds like you needed a ByteString Builder to get comparable performance.
      • luispedrocoelho 9y ago
        Maybe, but pseudo-C actually worked very well. I even have some "real C" in my Haskell code to handle some inner loop stuff.
  • knz42 10y ago
• fizixer 10y ago
  Wow, really good writeup. And on point regarding '5 days' vs '5 years' approach. And it really confirms my biases against the language.
• dlwdlw 10y ago
  The thing with enlightenment level ideas isn't that they aren't enlightening but that they attract hype. Individuals pretending to be enlightened if you will. A scientific mindset as well as liberalism are also ideas where new proponents often want to draw a line in the sand to stratify people into superior and inferior. The original proponents were chasing a higher level of quality for all, but the need for social stratification weaponizes and gates ideas.
  • highwind 10y ago
    I'm confused. Can you tell me how your comment relates to the article? The author of the article is sharing his experience with Haskell, explaining ups and downs. He concludes by > Haskell is a great programming language. It requires some effort at the beginning, but you get to learn a very different way of thinking about your problems. Are you interpreting the word "different" as "better"?
• throwaway110034 10y ago
  I will never, ever use Haskell in production because of its default evaluation strategy, the wrongness of which was tacitly conceded not long ago with the addition of the strictness pragma (which only works per-module) to GHC. I think it's especially telling that its community skews so heavily towards this blogger/monad tutorial writer dilettante demographic rather than the D. Richard Hipp/Walter Bright 'actually gets real work done' demographic. I know which of the two I'd rather be in. Haskellers are even worse than Lispers in this regard. For the amount of noise about Haskell, you'd expect to see high-quality operating system kernels, IDEs, or RDMBSs written in it by now. Instead its killer apps are a tiling window manager, a document converter, and a DVCS so slow and corruption-prone even they avoid it in favor of Git.
  • proaralyst 10y ago
    My impression on the consensus was that laziness was good for the tree (computation) but bad for the leaves (datatypes); hence the good practice of using strictness annotations on datatypes.
    • whateveracct 10y ago
      > hence the good practice of using strictness annotations on datatypes. It's such a good practice that there's -XStrictData (different than the pragma mentioned by GP)
  • Buttons840 10y ago
    Would you also feel that a strict-by-default language which adds support for lazyness is a tacit admission that strict-by-default is wrong?
    • throwaway110034 10y ago
      How would you feel if Common Lisps suddenly started sporting infix operator notation? Haskel's alien, counter-intuitive evaluation strategy was actually marketed (circa 2010) as a powerful performance-enhancer that facilitated optimizations that were difficult if not impossible to do in a strict language like C. Instead, it ironically tends to cause more performance problems than it solves, with hard-to-debug spaceleaks capable of taking down production systems. The entire Miranda branch of the PL tree is likely going to prove to be an evolutionary dead end, and Haskell will eventually lose out to Idris or some other strict language. And I don't think it's a coincidence that the strictness pragma (which does not even give you a strict program) was added soon after Idris and the rest started getting traction.
• dmix 10y ago
  > The easy is hard, the hard is easy Probably the best single line description of Haskell. The learning curve helps with the former (easy) part, the latter (hard) part contains some really brilliant ideas where you start to wonder why so many people still use other languages for everything, then you remember how hard the easy stuff can be...
• cowardlydragon 10y ago
  "Java is just a C++ pidgin language" Muahahaha, today on the interweb, we play: insult, or compliment?
• Maro 10y ago
  I have tried to use Haskell a number of times in the past ~5 years for small-scale projects and witnessed others try to use it, and most of these projects (actually I think all) have resulted in failure / rewrites in more simple/plain-vanilla languages like Python/Go. I keep thinking Haskell is interesting, but at some point I had to force myself to stop investing time in it because I kept concluding it's not a good investment of time for a move-fast/practical person like me. I again had to remind myself when I read this post. Some reasons I remember for the various failures, in no particular order: - steep learning curve = experienced (in other languages) programmers having a tough time not being productive for weeks/months in the new language, with no clear payoff for the kind of projects they're working on - sometimes/often side-effects/states/global vars/hackyness is what I want, because I'm experimenting with something in the code; and if I'm not sure if this code will be around in 3 months, I want to leave the mess in and not refactor it - in general, I think all-the-way pure no side effects is too much; I think J.Carmack said sth along the lines: Haskell has good ideas which should be imported into more generally useful languages like C++/etc, eg. the gamestate in an FPS game should be write-once, it makes the engine/architecture easier to understand (but in general the language should support side-effect) - I found the type system to be cumbersome: I kept not being able to model things the way I wanted to and running into annoyances; I find classes/objects/templates etc from the C++/Java/Python/whatever world to be more useful for modeling applications - when the spec of the system keeps changing (=the norm in lean/cont.delivery environments), it's cumbersome/not practical to keep updating the types and deal with the cascading effects - weird "bugs" due to how the VM evaluates the program (usually around lazyness/lists) leading to memory leaks; when I was chasing these issues I always felt like I'm wasting my time trying to convince the ghc runtime to do X, which would be trivial in an imperative language where I just write the program to do X and I'm done - cryptic ghc compile errors regarding types (granted, this is similar in C++ with templates and STL..) - if it compiles it's good => fallacy we kept running into - type system seemed not a good fit for certain common use-cases, like parsing dynamic/messy things like json Working at Facebook for the last year and seeing the PHP/Hack codebase which powers this incredibly successful product/company has further eroded my interest in Haskell: Facebook's slow transition from PHP to Hack (=win) shows that some level of strictness/typing/etc is important, but it's pointless to overdo the purity. Just pick sth which is good enough, make sure it has outstanding all-around tooling, have good code-review, and then focus on the product you're building, not the language. I'm not saying Haskell is shit, I just don't care about it anymore. I'm happy if people get good use out of it, clearly there are problem spaces that are compact, well-defined and correctness is super-important (like parsing).
• KirinDave 10y ago
  I strongly agree with most of this. I've been so pro-Purescript because I think we need a break from Haskell into something new but related. Haskell is great, but has so much baggage it's tough to enter into.
• Safety1stClyde 10y ago
  > If you read an article from 10 years ago about the best way to do something in the language, that article is probably outdated by two generations. Thank you, that is all I need to know about Haskell. I won't be learning Haskell then, in the same way that I won't have anything to do with C++. I don't have enough time to use these fashion-dominated and fad-obsessed programming languages.
  • charlieflowers 10y ago
    Holy cow! Don't ever dream about getting into node.js then!
    • Safety1stClyde 9y ago
      Anything to do with Javascript is prey to churn. Many modern web pages consist of a blank page which loads various bits of Javascript from various servers which then process other Javascript via Javascript templates into the final page. There might be a small minority of web sites which actually are updated so often that these actions are justified, but the bulk of the websites clearly are those where some Javascript-fixated person has decided that "there is no such thing as too much Javascript". Considering that the language was not very well designed in the first place, putting it on both the web browser and the server, and then insisting on regenerating what could easily have been supplied as static HTML pages by running dozens of Javascripts on both the server and the browser should be enough to convince an average observer that Javascript is being abused in this way due to nothing more than faddism.
  • evincarofautumn 9y ago
    Surely you’re joking? I think ~5 years is a totally reasonable time frame for new techniques, language features, and best practices to come about. Languages and libraries evolve in response to the needs of users and pain points with older approaches. To be honest, having been a Haskeller since ~2010 (and a C++ guy since long before that) I’m not even really sure what specifically the author is referring to there.
• nicolashahn 10y ago
  I don't think it takes 5 years to learn this stuff. Nothing stood out to me and I only used Haskell for 10 weeks for a single college course 2 years ago. It's all true though.
• devrandomguy 10y ago
  > Types / Type-driven development Rating: Best in class > Haskell definitely does not have the most advanced type system (not even close if you count research languages) but out of all languages that are actually used in production Haskell is probably at the top. What are these other research languages, that have such incredible type systems? Do they usually have implemented compilers, or would they only be described in an abstract form? Can I explore them for fun and curiosity?
  • tines 10y ago
    The fact that he mentions type driven development probably means that he has dependent typing around, probably as seen in the language Idris, whose recently published book is called the same. Idris is very much not just an abstract language.
    • devrandomguy 10y ago
      Yes, the author mentioned Idris shortly afterwards, but I get the impression that this is just the tip of an iceberg. Idris was presented as the one example that is most likely to evolve from a research-only language, to a production language.
      • dllthomas 9y ago
        There's also agda and coq, at various points on the spectrum between programming language and theorem prover.