15 ms·

Haskell is a beautiful research language. Its usecase is to supply subjects for PhDs and MScs, which it fulfills perfectly. Also it's extremely fun to learn and

• ukj 7y ago
  >Architecture is extremely sensitive to the initial choices due to isolation of side effects. This is fundamentally why it's useless in practice. It requires you to anticipate/predict everything ahead of implementation. It requires you to be perfect at Waterfall ( https://en.wikipedia.org/wiki/Waterfall_model https://en.wikipedia.org/wiki/Waterfall_model ). Real-world problems laugh at such idealism.
  • mic47 7y ago
    >Architecture is extremely sensitive to the initial choices due to isolation of side effects. Only if you choose to isolate all side effects from each other. Actually Haskell makes refactoring really easy, so you can adapt your implemention to changing requirements easily.
    • h91wka 7y ago
      Why would I need to refactor anything in this situation in the first place?
      • mic47 7y ago
        In what situation? If you predict everything correctly, you don't have to, but I was referring that you don't have to have everything designed upfront, since refactor is much easier and safer than in other languages. I wanted to make point that that #4 is not true.
        • ukj 7y ago
          Is that 1% not true or 99% not true? Amortizing the up-front cost of design, into a continuous cost of refactoring every time the requirements change doesn’t make the original claim false. You are still paying the price of rigidity.
  • youerbt 7y ago
    > This is fundamentally why it's useless in practice. It requires you to anticipate/predict everything ahead of implementation. This is simply bs. Haskell is actually a language (that I know of) where, IMO, your initial choices matters least. And that's because it's gives you great refactoring experience.
    • ukj 7y ago
      'Great refactoring experience' relative to what? An imperative language? Yeah right! I don't have to refactor extensible code.
      • youerbt 7y ago
        To most (if not all) production ready languages out there.
        • ukj 7y ago
          Perhaps you didn't understand my point. Being 'good at refactoring' is only a desirable feature if you are spending a lot of your time refactoring code. Why are you spending so much of your time refactoring code? Because your language isn't extensible!
          • youerbt 7y ago
            Being good at refactoring is desirable, so you don't have to "anticipate/predict everything ahead of implementation". What is your "extensible code", I don't know, but it doesn't matter, because we are talking about your comment on Haskell. But maybe you are just a troll, so w/e.
            • ukj 7y ago
              Do you understand the difference between extensibility and refactoring? For the purposes of flexibility extensibility is more desirable than refactorability (to me and my problem space anyway). >because we are talking about your comment on Haskell. I am not in the habit of commenting about things in a vacuum. I am comparing Haskell to other tools in my toolbox. I am sure that in the Haskell universe (isolated from the rest of reality) Haskell is the greatest thing ever.
• vapou 7y ago
  Do you have any evidence to back this up? In my experience working in the largest Haskell team in the world, dealing with various applications and services in production: none of what you said is close to reality.
  • h91wka 7y ago
    All the evidence is out there in Hackage. I backed up my points with some argumentation at least, and you dismissed it based on personal experience that we have no way of verifying. So, not changing my mind yet.
    • striking 7y ago
      You have hardly backed anything up, I don't see any links in your original post. From my perspective, your thoughts are as anecdotal of that of the other poster.
      • h91wka 7y ago
        What links do you need? If you know anything at all about the Haskell ecosystem, you already know where to find all these papers/sites/presentations about arrows, pipes, lenses and what not.
        • striking 7y ago
          Yes, I know where to find descriptions of language features. That doesn't prove to me that they're often misused or that I might commonly have a problem with code that others have written because of it. You've recounted your experience and detailed that you have seen issues with things in Hackage, and I won't claim your experience is invalid. I just won't let you claim your experience is that much more valid than someone else's without proof.
  • nuriaion 7y ago
    At which company is the largest Haskell team in the world?
• thedataangel 7y ago
  I write Haskell commercially, and none of the problems you list are problems my team actually has in reality.
  • adambyrtek 7y ago
    Your comment would be much more interesting and constructive if you actually took the time to refute the individual points instead of just saying that it's not a problem for you.
    • thedataangel 7y ago
      Sure: 1) Should basically never happen anyway. It's a point of pride on my team that we rarely (as in, maybe once a year) have breakages in production that are actually caused by Haskell - they are almost always caused by something else. On the off chance this very unlikely scenario actually happens, I've never found a Haskell codebase I'm familiar with to be any less readable than ones in other languages. If anything, the reverse is true. The important thing is familiarity, not the language it's written in. 2) Haskell is a language in which research is done. It's also perfectly suitable for production software. The two aren't mutually exclusive. It _does_ have many ways to combine things, but in generally that's seen as a positive. Most of the ways are compatible with one another. The big exception is the distinction between monadic and non-monadic code, but libraries where that distinction matters almost always support both. 3) This is a problem with developers, not the language. If you employ idiots who want to masturbate over academic points for two days instead of doing their jobs, thats your problem. 4) Architecture is much _easier_ to change in Haskell than in other languages, because refactoring is safe and straightforward. Anyone complaining about logging and config has clearly not written enough Haskell to be aware of the common patterns for handling those smoothly. On the _very_ rare occasion that you just need to jam some print-lines somewhere deep for debugging, the Debug.Trace module lets you do that with basically no effort.
  • h91wka 7y ago
    How do you deal with #4?
• sanxiyn 7y ago
  Then Haskell failed. To quote from Haskell 2010 Language Report, the primary goal of Haskell was: "It should be suitable for teaching, research, and applications, including building large systems". Applications and building large systems are explicitly goals of Haskell. Haskell was never intended to be a research language.
  • coldtea 7y ago
    "Avoid success at all costs" is also an explicit goal of Haskell. >Haskell was never intended to be a research language. Intended and actively tried not to be are two different things...
    • sanxiyn 7y ago
      No, that is not an explicit goal of Haskell. To prove otherwise, please quote from Haskell 2010 Language Report.
      • AnimalMuppet 7y ago
        You know, it's just possible that the Haskell 2010 Language Report is not the only valid statement of the "goals of Haskell".
    • chongli 7y ago
      To clarify, it’s avoid “success at all costs.” Rather than “avoid success” at all costs. It’s a joke in the Haskell community that relates to the language’s early history and its ability to break things without much fuss. Things have settled down a lot more in the last few years, hence the shift in emphasis.
• rishav_sharan 7y ago
  Agree with #1. I think Elm is probably the best functional language in this regard. Contains all the important bits yet is small and opinionated enough to be easily readable. If only weren't web only and run as a private project. An elm like language with llvm backend would be amazing
  • platz 7y ago
    Elm is like the Go of the FP world. It really works for some people, but others find working in a kneecapped language infuriating.
    • rishav_sharan 7y ago
      IMO its the best language for absolute beginners to FP.
  • leshow 7y ago
    I think Elm gets old after a couple weeks when you realize how handicapped it is as a language. Personally, I think something like Reason/OCaml is a great place to start. Haskell is a good choice too but laziness adds an additional hurdle. The core of Haskell is actually pretty simple; it's algebraic data types, parametric polymorphism, and typeclasses. > If only weren't web only and run as a private project. Yeah, the way the project is run is troubling.
  • machiaweliczny 7y ago
    Elm is copy-paste language (too much, maybe can/will be improved)
• implicit 7y ago
  I've done commercial Haskell work and it was fantastic. Almost all of the things you mention are problems with technical leadership and not Haskell itself. These problems are all very, very easy to deal with. 1) Many of us have also seen the C++ library or application that busts out the template metaprograms at every opportunity. Haskell is the same. Use restraint when bringing in new libraries and programming techniques. (as an aside, I have yet to encounter a single problem that I thought merited the use of arrows) 2) You also see this in other languages, though to a lesser degree. The same techniques we use with other languages work just as well in Haskell: As leadership, form a strong opinion on the best way to write control flow and ensure that everything uses a consistent style. 3) Are your engineers running around implementing random research papers? This has nothing to do with Haskell. 4) In practice, this is almost never a big problem. Refactoring a pure function to an effectful function is easy and safe. In a production setting, almost all of your functions run in some monad already, so it's pretty rare to run into a situation where you suddenly need to percolate effects through many functions.
  • h91wka 7y ago
    > problems with technical leadership I've never been lucky enough to get a full-time Haskell job (nor did I try), so my experience is based on single-man development & prototyping using the existing stuff found on Hackage. I presume that it may be different for a huge organization that can afford to build the entire ecosystem from the ground up while enforcing design rules (and these rules must be created by an exceptionally brilliant architect!). But in other languages you don't have this situation. > Many of us have also seen the C++ library or application that busts out the template metaprograms at every opportunity. C++ and boost set standards a bit low, to be honest. > Are your engineers running around implementing random research papers? This has nothing to do with Haskell. Not research papers, just the usual business logic. The problem is that research papers set the code style. Also they are not "my engineers". > In practice, this is almost never a big problem. It typically is, because changing internal implementation is reflected in the interface, and for each invocation of the function change has to propagate through _the entire_ call stack to some place running in IO monad or whatever. > almost all of your functions run in some monad already You defy your own argument. If that's how you design application, what's the point of bothering with side effect isolation then?
• lallysingh 7y ago
  WTF is your oncall person doing reading code at 4am? What state of mind do you expect this person to have at that time? What are they expected to do? That's a huge red flag. As for the rest.. I don't think the language was the problem at that team.
  • magicalhippo 7y ago
    Just yesterday we got a support call at 2am which quickly escalated to one of my dev coworkers. He had to dig through code to find the problem and push a fix at 3am. The problem had to be fixed right then as further delays would cause heavy disruptions of the operation for that day, which would have been very bad for our customer. While support can deal with most issues, it's not entirely uncommon that us devs have to step up and either help fix the issue by analyzing the relevant code, or actually push a fix in the middle of the night.
  • biesnecker 7y ago
    What are they meant to do if the world starts burning at 4am? Wait until a reasonable hour? Oncall fires at 4am suck but they're part of running critical services.
    • lallysingh 7y ago
      You have a runbook. Anything not covered by the runbook escalates to someone who already understands the code.
      • LargeWu 7y ago
        Are you saying you've never written code and then later came back to it, saying "Who wrote this shit?" and did a git blame, only to find out it was you?
        • lallysingh 7y ago
          If you can't read your own code, then the language isn't your problem.
• antisemiotic 7y ago
  >Production code should be understandable by an on-call person at 4 am. I don't like the "simple language means understandable code" argument being thrown around like it was some obvious fact. I'm currently working on a project whose major component is a byzantine home-grown message passing framework written in pretty much Java-in-C++ (old school OO with liberal use of shared pointers. Not that I would call C++ in any form "simple", but I do think that C++ without template magic is simpler than Haskell with GHC magic, or, say, any Lisp with a lot of macros). Maybe it's a case of grass being greener on the other side, but I'd gladly take a monad transformer stack or a DSL written in Lisp macros over doing the same song and a dance over and over again just to implent a tiny new functionality, or trying to deduce the logic from someone else's sea of boilerplate. I mean, taking this logic to extreme, one could say that code written in assembly is easy to understand: it's adding a value to EAX now, then it jumps over there... This being said, Haskell does have something in it that encourages one to design a ballistic algebra that runs in the type system before even pointing a gun at one's foot.
  • h91wka 7y ago
    > This being said, Haskell does have something in it that encourages one to design a ballistic algebra that runs in the type system before even pointing a gun at one's foot. Haskell is not even a total language, so type system doesn't magically divert gun from your feet. You can easily prove False in Haskell (there's a Prelude function for doing this!), enough said. And if you want types keep your feet safe, it's possible of course, at a _great_ cost, and not in Haskell.
    • antisemiotic 7y ago
      I was referencing an old joke; that Haskell programmers allegedly spend so much time polishing their types that they never get around to actually write anything useful.
• 08-15 7y ago
  Cute how none of this relates to the article. Why do you have a list of straw-man bullet points to rattle off whenever someone says "Haskell"? Who hurt you?
  • duxup 7y ago
    Those don't seem like "straw-man bullet points".
    • 08-15 7y ago
      Fine, I'll bite... (1) "Haskell is unreadable because the business logic gets buried under layers of technobabble." Not observed in practice, and not a property of the language anyway. (2) List of many things that are supposedly about control flow. They aren't. Also implies that these things are incompatible with each other, which isn't true. (3) Indeed, some developers try to reproduce research papers out of curiosity some of the time. That's a good thing. (4) Mostly true, but true in any language, and not due to isolation of side effects. These are textbook examples of straw manning: representing a caricature of the other side in order to easily argue against it. (But why? Who hurt the poor guy?)
• excursionist 7y ago
  > Production code should be understandable by an on-call person at 4 am. If business logic is buried under layers of lenses, monad transformers and arrows, good luck troubleshooting it under stress. And real systems do break, no matter type safety. You can say the same thing about production Java code buried under layers of frameworks, factories, facades, proxies, aspects, annotations, etc. I don't see why readable, maintainable code can't be written as easily in Haskell as Java, C++, Python - you just have to make writing clean code a priority.
• BubRoss 7y ago
  I think this points to a difference that I don't see highlighted enough - influential doesn't mean best. If you are stuck on a plane are you going to watch citizen kane or something from the last couple of years. What about an Akira Kurosawa movie? They top film critics' lists of the 'best' movies, but really they are some of the most influential movies of all time. Lisp and Haskell aren't the 'best' languages to use the vast majority of the time, but they heavily influential and have contributed a lot to computer science.
• bpyne 7y ago
  "1) Production code should be understandable by an on-call person at 4 am. If business logic is buried under layers of lenses, monad transformers and arrows, good luck troubleshooting it under stress. And real systems do break, no matter type safety." Let's assume that your on call person is a developer. (If the person is not a developer, (s)he is not going to comprehend any language.) 1) If your application is written in Haskell, the on call developer would more than likely have been involved in the code base and reads Haskell. Your assertion about not comprehending it seems suspect. 2) You have a serious process issue if a developer is woken from a sound sleep to track down, correct, thoroughly test, and promote a fix for the bug in the middle of the night. The number of cases in which this happens should be close enough to zero to call it zero. Your comment sounds like an attempt to cast Haskell as a purely academic language because it fails a (poorly) made up real world scenario. I'm NOT a Haskell-er so I don't feel a need to defend it. I do find the reasoning behind the criticism poorly thought out.
  • oarabbus_ 7y ago
    1) do you mean to imply all languages are equally parseable? 2) You’ve never worked in a company where a bug brought down prod and an on-call has to fix it?
    • bpyne 7y ago
      1) No, that would be ridiculous. My point is that a developer working with Haskell daily to develop an application would have no problem reading it in the middle of the night. The biggest problem for a developer, who may not have written the module in question, is not understanding the requirements for the module. 2) Early on and even then rarely. After working in a hospital writing and supporting an electronic patient chart system, I found it hard pretending that anything short of life and death was serious enough to be woken over.
• pwm 7y ago
  Many others have replied to your concerns already, nevertheless allow me to add my own experience to the pile, as someone writing Haskell for food: 1) For a team of Haskell programmers reading Haskell code is just the norm. It's the same as for a team of Python programmers reading Python code. Also as a side-note: I never in my 15 years of professional life had a 4am call. Maybe I'm lucky, I don't know. In my experience automated tests, code reviews, sane deployment policies, etc... all minimise the chance of this ever happening. Haskell's powerful type system helps a lot here as it saves you from a whole array of problems upfront. I feel much more confident deploying Haskell code to production than code in any other language. 2) In commercial projects engineers tend to do things in sane and simple ways. This is not surprising really. Just cause you can does not mean you should. It's not Haskell specific but a general principle ie. KISS. 3) "Fancy research papers" at times can actually be really helpful. If you happen to have a problem that someone wrote a paper about that saves you time having to rediscover the solution. Having lots of research papers is imho a great strength of Haskell. That being said KISS from above applies here. If your problem is simple then do it simply. 4) Architecture in general is much less sensitive to change in Haskell than in other languages in my experience as the type checker guides you when you want to change your code. Refactoring in Haskell is pure joy. Re logging/configuration/etc... there are well-known patterns to deal with these as you would imagine, it's not like no one had to solve these problems in Haskell before. There are also tools (eg. Debug.Trace) in case you need some quick ad-hoc printf-style debugging. The same really as in any other language. I don't want to write about all the pros of the language, others have done so already, just wanted to add my own professional experience to the mix.
• leoh 7y ago
  >4) Architecture is extremely sensitive to the initial choices due to isolation of side effects. Because if you suddenly need to do something as simple as logging or reading a config in a place where it wasn't originally anticipated, you're in for a bumpy ride. Not a serious Haskeller at all, so not sure if this is a terrible practice, but for logging, `unsafePerformIO` could work in a pinch without changing types.