10 ms·

In university I was obsessed with Haskell and being clever and writing code that was an unholy stack of lambda functions and fancy constructs like monads and mo

• deleted 9y ago
  [deleted]
• nilkn 9y ago
  Surely there's a middle ground here. Most code written by university students in any language is problematic and not professional-quality. The specific deficiencies exhibited may vary from language to language. The extreme you illustrate here is clearly undesirable in any professional context, but that doesn't mean it reflects the code written by any professional Haskell developers out there.
  • hateduser2 9y ago
    Yea to me his comment reads as a whiplash to realizing some of the downfalls of haskell. But he seems like he takes it way too far.
    • milesvp 9y ago
      I dunno, not being able to reason about performance is a pretty big deal. I've only ever fantasized about learning haskell, but I can tell you that this quality is what makes sql (or god forbid an ORM) a pain to deal with in production. The explain plan for a given sql query can change on you for no reason other than your table has grown. You can go from using an index for speedy queries to a full table scan because your sql engine decided to no longer use any of your indexes. I don't know what the equivalent cases might be for a more general purpose language, but I strongly suspect it's a problem all declarative languages suffer from.
      • fauigerzigerk 9y ago
        >The explain plan for a given sql query can change on you for no reason other than your table has grown True, but that may well lead to more predictable performance. If you write a procedural program and then the dataset grows, your programm might slow down dramatically while the new execution plan generated by the SQL engine would adapt and keep performing well (...ideally). You could argue that a procedural programmer could anticipate the growth of the dataset and choose a suitable algorithm from the start. But if you have not one but tens of datasets and value ranges whose size relative to each other determines what the best algorithm is then manual optimization becomes very difficult indeed. A Haskell compiler doesn't use knowledge of input data to optimize the program though (at least not to the extent a database engine does). So I think a relational database engine is more useful in this regard.
      • kian 9y ago
        Haskell is not declarative, however, so the programmer actually has control over the evaluation order through ordering demands for the results of computations. It does, however, take a little longer to fully grok how lazy code evaluates compared to a simple left-to-right eager evaluation a la Scheme, so it can be a bit of a rough start (and many usually only decide to take the full time to understand laziness when they're in the middle of a critical issue due to it). However, a large domain of problems (for example, search) are more easily expressed in a compositional manner using laziness.
        • milesvp 9y ago
          Forgive my ignorance, I really only have a passing familiarity with haskell, and I did a quick search before trying to lump it in with sql as declarative, but http://www.haskell.org http://www.haskell.org states above the fold, "declarative, statically typed code". If it's not generally considered a declarative language, is there a better way to describe the language?
          • smadge 9y ago
            I think "declarative" exists on a spectrum. There's no clearly defined line between declarative and nondeclarative that I know of. For instance I would say Haskell < Prolog < SQL are on one end of the declarative spectrum, but in each case you do end up reasoning about the underlying execution model.
  • gambler 9y ago
    >Surely there's a middle ground here. LINQ. Monads that are easy to reason about without the need to speak about monads, functors and so on.
    • lmm 9y ago
      To communicate we need names for things; "thing that has a suitably associative implementation of flatMap" is an important concept, and "Monad" is the name that exists for it.
• trendia 9y ago
  This is pretty similar to what happened to me. I was implementing an algorithm that had multiple parts and the data would arrive asynchronously. The first time, I wrote the multipart algorithm using a functional style to encode each state. As the algorithm grew, it became more and more difficult to reason about and managing dependencies between the parts was harder, not easier. When this became unwieldy, I rewrote it. However, when I wrote it the second time, I wrote the algorithm in a way that made it appear imperative. Everything was linear, starting with part B, then part C, etc. A small backend managed state, but you could read through the algorithm code and it almost seemed like it would run synchronously. The second method was easier to read, debug, and modify. I will probably not go back to the functional method anytime soon.
  • simplify 9y ago
    Be weary of "programmer's rewrite bias". Anything you rewrite is likely going to be easier to read, debug, and modify since you understand the problem better the second time.
    • kqr 9y ago
      Also the first version may have had post-release bugfixes etc which are frequently omitted from the rewrite and then rediscovered later on.
• tome 9y ago
  Seems unrelated to the topic under discussion.
  • tytytytytytytyt 9y ago
    Welcome to Hacker News.
  • skywhopper 9y ago
    I'm not sure. The subtext is "monads are one of many clever ideas in Haskell that make it hard to use in practice." And thus it answers the very (very very) specific question posed by the article, just in a more general context: "Are Monads a waste of time?" "Yes, Haskell is not worth the effort."
    • gowld 9y ago
      Monads are not a clever idea that makes Haskell hard to use. Purity is a clever idea that makes Haskell hard to use, and Monads are the best solution so far.
• proc0 9y ago
  Pure FP is just using math as its primary source of programming patterns and techniques, while most other languages, like OOP, use arbitrary conventions to abstract code. Because mutation gives you tremendous flexibility, you can model many kinds of patterns, give it some analogy like inheritance in animals, and then write a language that has it out of the box. Haskell on the other is using math to construct its patterns, so while the learning curve is higher, eventually you realize this is the ultimate abstraction (category theory), and it cannot go more abstract than that. This is useful in some scenarios requiring more logical rigor, but I agree it's not always the best tool.
  • j2kun 9y ago
    > eventually you realize this is the ultimate abstraction (category theory), and it cannot go more abstract than that This is exactly the kind of false sense of intellectual superiority to avoid. Mathematicians and category theorists don't talk like this. Even the parts of Haskell that have the flavor of category theory aren't really all that much like category theory.
    • proc0 9y ago
      Maybe you can expand on that, and/or show me something more abstract than category theory. Programming = abstracting information processing. Category theory = the mathematics of abstract functions (or morphisms a.k.a. changing something)... so it makes sense that CT captures something very fundamental about computation.
      • Koshkin 9y ago
        Technically, category theory is not more abstract than the rest of (abstract) algebra.
        • proc0 9y ago
          You can derive all other math branches with CT, so yes, it is more abstract. It is "higher level" (in the same sense of programming languages) than other maths.
• eastWestMath 9y ago
  I'm sorry, but it just sounds like you're a terrible functional programmer. There are basic software engineering principles you need to use when using a functional language, just like any other programming language.
  • hateduser2 9y ago
    Think you should tone it down a little, whether or not I agree
• kornish 9y ago
  I'd encourage you to look into Kotlin. It's got the 20% of FP features that give 80% of the benefits, while still having generics and a thriving ecosystem (JVM). As someone with a similar personal trajectory, it really hits the sweet spot.
• jonnybgood 9y ago
  I’m in the same boat. I deep dived into Haskell for two years. It was fun and interesting at first but lost its appeal for some of the reasons you mention. I also enjoy using Go.
• mhh__ 9y ago
  I think Haskell is full of good ideas waiting to be reused in a successor language, with a focus on software engineering as well as just purity (Multiple senses of the term!) and rigour in abstraction. The ideas are sound - When I write pseudo"Haskell" in other languages (Especially those with enforced purity), the rewards are fairly good for relatively little extra work - but Haskell (The language) is, even putting nicely, rough around the edges.
  • bborud 9y ago
    > [...] Haskell is full of good ideas waiting to be reused in a successor language Thanks. You managed to articulate something I've been thinking for a long time. To me a good programming language has empathy. Many languages that have some clever ideas have little empathy with programmers.
    • platz 9y ago
      or you could simply use it as a 'better java', and forget all the extra bells-and-whistles.
  • FridgeSeal 9y ago
    I feel like this is a sentiment sort of echoed by it's creators: I believe they've stated that they (paraphrasing here) "don't want haskell to become successful". Not in that they don't want adoption at all, but they don't want to have to support commercial requirements around stability and whatnot that companies usually require. As such, I think a language that comes along and takes a subset of the best features and learnings from Haskell would be a really great idea. Maybe like a python but for haskell?
    • naiveai 9y ago
      I've been waiting for this for a very, very long time. I've not learned Haskell yet but generally speaking I'm very fond of FP in all languages, including Python. However, the BDFL has arbitrarily decided that Python shouldn't even have remotely easy-to-use FP semantics (even though Python being so multi-paradigm is often touted as a major advantage), so (as an example) while he gave up on trying to remove `lambda`, he didn't make it simpler and more useful, which makes it so that whenever someone runs into it as a beginner they say, "Oh, what a stupid little thing that I can replace easily, FP is stupid." [1] I've been very upset generally speaking at how much control the BDFL is taking - not necessarily directly, but indirectly through people who seem to think that Pythonic™ programming is literally God and anyone who doesn't do Pythonic is Bad. [1] https://stackoverflow.com/questions/890128/why-are-python-lambdas-useful https://stackoverflow.com/questions/890128/why-are-python-la...
• platz 9y ago
  https://patrickmn.com/software/the-haskell-pyramid/ https://patrickmn.com/software/the-haskell-pyramid/ parts of it's type system has a lot of gnarly dark corners, but the those parts aren't necessary to line-of-business kind of programming. unfortunately, those are the ones that get discussed on social media - which it sounds like you were inundated in / attracted to the core type system is pretty lean
• agentultra 9y ago
  I never went to university and don't have a PhD. I find Haskell prevents me from being too clever and keeps me honest. Monads are a part of that toolbox which prevent me from using unconstrained effects in my code.
• gcb0 9y ago
  you should try modern erlang. If you try really hard, you can get both the advanced abstract concepts plus obscure machine specific optimizations.
• PopsiclePete 9y ago
  Haskell's value was never in actual "engineering" (someone somewhere is itching to point me to no fewer than 4 Haskell projects that nobody cares about) but rather in "research". To this day, I don't understand Monads, even though somehow I used the heck out of them in my C# days, and I loved "reactive" programming which also supposedly comes from Haskell, and for that - I'm grateful. Haskell tries dozens of ideas nobody but computer language theorists care about but, once in a while, something cool drops out that is adopted and made usable for mere mortals like myself.
  • platz 9y ago
    I think you're rather putting it on a pedestal. for the truck-driving contingent of haskell programmers such as myself, i assure you i'm not interested in theory much and simply enjoy haskell as a 'better java'.
    • gowld 9y ago
      May be "better than java" in your use case, but it's not "better java", as it's nothing like Java at all.
• PricelessValue 9y ago
  So true. Haskell is great to learn about functional programming and programming language theory in general. But to get things done, it's just not as practical.
  • platz 9y ago
    it's pretty practical if you're building line-of-business apps, web servers, or other things you would use java for.
    • gowld 9y ago
      Yes, miss one character in a thing that looks like HTML but is actually a gigantic function call, get an incomprehensible failure message about how the meta-template macro expansion has an error.
      • platz 9y ago
        macros/templates are usually confined to borders, databases, routes. not the business logic. Lisps are more susceptible to that.
        • gowld 9y ago
          Not even talking about business logic, just talking about page layout. https://www.yesodweb.com https://www.yesodweb.com
          • platz 9y ago
            Yes, c# and Java do codegen for you too, in the same way. This is how templating in static languages work.
• gowld 9y ago
  Even the creators of Haskell have conceded that lazy-by-default was problematic https://www.google.com/search?q="the+next+haskell+will+be+strict" https://www.google.com/search?q="the+next+haskell+will+be+st...
  • willtim 9y ago
    I think his point was more that it is purity rather than laziness that has been the big contribution from Haskell, despite the original research goals. A good language should allow for both strictness and laziness, as Haskell already does.
• willtim 9y ago
  The attraction of Haskell is to build correct software in a mathematically principled way. With practice, it is also remarkably productive, certainly more so than Go when used as a general purpose language. Haskell is simply much more expressive and capable of abstracting over many more things (perhaps this is why you say it is hard to read). The Haskell ecosystem is also constantly evolving and solving more and more real world problems, often problems that have not been solved in other languages. Modern Haskell effectful streaming libraries actually make reasoning about stream processing much easier than in say Java, where the presence of effects (exceptions etc) destroys reasoning. > Go is now my favorite language. Is this really true? Or is it just the tool you are now most familiar with? It's certainly a much more riskier proposition to try and feed the kids writing Haskell. Quoting Rob Pike on Google's own Go programmers: "They're typically fairly young, fresh out of school, probably learned Java ... They're not capable of understanding a brilliant language ... So the language that we give them has to be easy for them to understand and easy to adopt." The Go toolset can obviously get the job done, but I don't understand why it would be anyone's favourite language, it doesn't even sound like it's Rob Pike's favourite language.
  • foldr 9y ago
    >certainly more [productive] than Go when used as a general purpose language. Come on, there isn't really any evidence that Haskell is more productive than Go. It's not as if anyone's run a controlled experiment. Anecdotally, I've written code in both languages and not found much difference in productivity. I think a lot depends on the size of the team, the size of the code base, the nature of the algorithms being implemented, and the amount of IO that's performed. Haskell's abstractions have saved me time in some cases. But then again, I've also spent unproductive hours figuring out the complex abstractions that someone else decided to use. Haskell's so-so tooling and culture of using unqualified imports compound this problem. And then there's the issue of compile times. Do monad transformers make me more productive? Do functional dependencies make me more productive? I'm not sure. In contrast, I have no doubt whatsoever that fast compile times make me more productive. Most go codebases compile in under a second, whereas GHC's compile times are absolutely abysmal. Go is a language without intellectual insecurity. It doesn't care if you think it's stupid, or if you think that go programmers are stupid. It focuses on features that are known to make everyone more productive (e.g. fast compile times) at the expense of features that make you feel smart.