9 ms·

> That's why when choosing between two languages, assuming both are well suited to the job at hand, a company should always pick the one with the wider adoption

> That's why when choosing between two languages, assuming both are well suited to the job at hand, a company should always pick the one with the wider adoption unless the other is so significantly "better" to trump lesser adoption. I think it plateaus at a certain point. You don't need the largest community, you just need critical mass so you don't have to build everything yourself. In fact, at some point being the biggest ends up diluting the talent pool because of the number of people getting into it for the money, and this is becoming a much bigger problem as the traditional job economy dries up and the demand for programmers increases. As to being "significantly better", I think Haskell has that in spades. In fact the things that make Haskell better are probably difficult to appreciate by a lot of younger programmers who are using relatively new languages and frameworks like Node and Rails. When you start seeing the effects of code rot and programmer turnover on a codebase over time, the types of static checks that are a couple orders more powerful and simultaneously less verbose and restrictive than what most people think of when they hear "static language" (ie. Java), then Haskell really starts to shine. Personally I think companies that invest in Haskell are going to start seeing major dividends in terms of productivity and agility over the lifetime of the company.

meric 13y ago
I don't disagree with your major point - "companies that invest in [[functional programming languages with a strong typing system]] are going to start seeing major dividends in terms of productivity and agility over the lifetime of the company." Haskell in particular I'm not sure of - the 'code rot' could easily manifest itself in performance. Haskell's laziness makes slow code and code that use up a lot of memory hard to locate, and at times require significant refactoring, to correct, though this is offset by haskell's type system somewhat... You can see this manifesting in the project of the article's author under the "Not All Sunshine and Rainbows" section. What I'm getting at - Bad code can be written in any language. IMO what's more important with regards to the language is how easy does it make to fix it. I've only used haskell for my thesis project as well as having toyed with it in my free time now and then over the past two years, and have no commercial Haskell experience, so perhaps someone with more experience can chime in... EDIT: A Haskell project I was working on: http://stackoverflow.com/questions/21654081/how-do-i-optimise-this-haskell-limit-order-book-with-code-reports-graphs http://stackoverflow.com/questions/21654081/how-do-i-optimis...
- tel 13y ago
  So far as code leaks go I think the professional story is divided. Everyone runs into them, some people learn to fix them, those that do tend to think of them as a little annoying but not significantly more so than profiling and tuning strict code. Fortunately, outside of space leaks the Haskell runtime is actually really quite fast. At the end of the day most of your code which isn't leaky (buggy) will be really fast almost for free. But that second step can be painful right now. The tools exist to profile and debug space leaks, but they're not cohesive and require a fair amount of black knowledge. It's also fairly murky as to how to escalate: if you've identified your problem area, strictified it a bunch, and it's still broken... well what then? The answer seems to be growing that internal expertise. There are enough people out there writing enough stuff that a dedicated student of the runtime can learn all of the tricks needed to really attack failures like that—profiling, unboxing, reading core, figuring out the inliner, and a variety of style guide hints to making things all work smoothly (e.g. avoid the Writer monad).
  - meric 13y ago
    Upvoted. "The answer seems to be growing that internal expertise." Or you can go with OCaml. :)
    - mamp 13y ago
      Or F#, if you are using .net or mono. It's pretty well integrated into Visual Studio these days, and quite good in Xamarin Studio.
      - platz 13y ago
        Sadly, although the performance of mono is good enough for most things i.e. GUI, it's several factors slower in performance-critical applications. Although I'm excited about F#, the experience in Visual Studio is really great.
    - tel 13y ago
      Sure, or any strict language. There are a lot of benefits to laziness though even before you start to consider other Haskell/OCaml deltas. Laziness provides a much better platform for separation of concerns which has enabled Haskell programs to have an unheard of degree of decomposition and reuse. As always, it's a tradeoff. At this point, I don't personally feel afraid of debugging core or profiling space leaks. I don't feel like I'm much more than 50% up to date on techniques to fix them... but when they arise I have little trouble eliminating them. Lazy resource deallocation is a problem of lazy IO. The solution is to not use lazy IO and that's tremendously tenable today due to libraries like pipes and conduit.
ulisesrmzroche 13y ago
Every year I read on HN that this year is Haskell's year. What's so different about 2014? The whole 'only for REAL PROGRAMMERS ' argument still hasn't gotten any traction, my dudes, lisper's been trying it since the beginning of time. Anyone got a link to a good todo-mvc implementation or something like that?
- copergi 13y ago
  >Every year I read on HN that this year is Haskell's year Really? Every year I read on haskell a bunch of uniformed dismissal of haskell from people who seem to have a deep seated hatred of learning. How do you get "this year is haskell's year" from his comment at all? >Anyone got a link to a good todo-mvc implementation A what? MVC is an object oriented pattern, I would certainly hope nobody tried to do it in haskell.
  - ulisesrmzroche 13y ago
    Every year, on a Haskell thread, someone calls me a noob for not knowing it. Then you get like the same 3 or 4 dudes talking about how it's only a matter of time until the enterprise picks it up and all the dumb people go away. The some stuff about static analysis, and I'm like, that's it? I just want to see a working to-do list application, or anything resembling that size.
    - copergi 13y ago
      >Every year, on a Haskell thread, someone calls me a noob for not knowing it. That sounds a lot like you putting words in other people's mouths. I've never seen anything like that. >Then you get like the same 3 or 4 dudes talking about how it's only a matter of time until the enterprise picks it up and all the dumb people go away. Or that. >I just want to see a working to-do list application, or anything resembling that size before we start the name-calling. Now I am even more confused. Why do you want to call people names, who do you want to call names, and why do you want to see some random toy app first?
      - 13y ago

meric 13y ago

I don't disagree with your major point - "companies that invest in [[functional programming languages with a strong typing system]] are going to start seeing major dividends in terms of productivity and agility over the lifetime of the company." Haskell in particular I'm not sure of - the 'code rot' could easily manifest itself in performance. Haskell's laziness makes slow code and code that use up a lot of memory hard to locate, and at times require significant refactoring, to correct, though this is offset by haskell's type system somewhat... You can see this manifesting in the project of the article's author under the "Not All Sunshine and Rainbows" section. What I'm getting at - Bad code can be written in any language. IMO what's more important with regards to the language is how easy does it make to fix it. I've only used haskell for my thesis project as well as having toyed with it in my free time now and then over the past two years, and have no commercial Haskell experience, so perhaps someone with more experience can chime in... EDIT: A Haskell project I was working on: http://stackoverflow.com/questions/21654081/how-do-i-optimise-this-haskell-limit-order-book-with-code-reports-graphs http://stackoverflow.com/questions/21654081/how-do-i-optimis...

tel 13y ago
So far as code leaks go I think the professional story is divided. Everyone runs into them, some people learn to fix them, those that do tend to think of them as a little annoying but not significantly more so than profiling and tuning strict code. Fortunately, outside of space leaks the Haskell runtime is actually really quite fast. At the end of the day most of your code which isn't leaky (buggy) will be really fast almost for free. But that second step can be painful right now. The tools exist to profile and debug space leaks, but they're not cohesive and require a fair amount of black knowledge. It's also fairly murky as to how to escalate: if you've identified your problem area, strictified it a bunch, and it's still broken... well what then? The answer seems to be growing that internal expertise. There are enough people out there writing enough stuff that a dedicated student of the runtime can learn all of the tricks needed to really attack failures like that—profiling, unboxing, reading core, figuring out the inliner, and a variety of style guide hints to making things all work smoothly (e.g. avoid the Writer monad).
- meric 13y ago
  Upvoted. "The answer seems to be growing that internal expertise." Or you can go with OCaml. :)
  - mamp 13y ago
    Or F#, if you are using .net or mono. It's pretty well integrated into Visual Studio these days, and quite good in Xamarin Studio.
    - platz 13y ago
      Sadly, although the performance of mono is good enough for most things i.e. GUI, it's several factors slower in performance-critical applications. Although I'm excited about F#, the experience in Visual Studio is really great.
  - tel 13y ago
    Sure, or any strict language. There are a lot of benefits to laziness though even before you start to consider other Haskell/OCaml deltas. Laziness provides a much better platform for separation of concerns which has enabled Haskell programs to have an unheard of degree of decomposition and reuse. As always, it's a tradeoff. At this point, I don't personally feel afraid of debugging core or profiling space leaks. I don't feel like I'm much more than 50% up to date on techniques to fix them... but when they arise I have little trouble eliminating them. Lazy resource deallocation is a problem of lazy IO. The solution is to not use lazy IO and that's tremendously tenable today due to libraries like pipes and conduit.

ulisesrmzroche 13y ago

Every year I read on HN that this year is Haskell's year. What's so different about 2014? The whole 'only for REAL PROGRAMMERS ' argument still hasn't gotten any traction, my dudes, lisper's been trying it since the beginning of time. Anyone got a link to a good todo-mvc implementation or something like that?

copergi 13y ago
>Every year I read on HN that this year is Haskell's year Really? Every year I read on haskell a bunch of uniformed dismissal of haskell from people who seem to have a deep seated hatred of learning. How do you get "this year is haskell's year" from his comment at all? >Anyone got a link to a good todo-mvc implementation A what? MVC is an object oriented pattern, I would certainly hope nobody tried to do it in haskell.
- ulisesrmzroche 13y ago
  Every year, on a Haskell thread, someone calls me a noob for not knowing it. Then you get like the same 3 or 4 dudes talking about how it's only a matter of time until the enterprise picks it up and all the dumb people go away. The some stuff about static analysis, and I'm like, that's it? I just want to see a working to-do list application, or anything resembling that size.
  - copergi 13y ago
    >Every year, on a Haskell thread, someone calls me a noob for not knowing it. That sounds a lot like you putting words in other people's mouths. I've never seen anything like that. >Then you get like the same 3 or 4 dudes talking about how it's only a matter of time until the enterprise picks it up and all the dumb people go away. Or that. >I just want to see a working to-do list application, or anything resembling that size before we start the name-calling. Now I am even more confused. Why do you want to call people names, who do you want to call names, and why do you want to see some random toy app first?
    - 13y ago