12 ms·

Introducing Haskell to a Company

130 points by k0t0n0 8y ago

thedataangel 8y ago
I've done something very similar, albeit with a more bottom-up approach. Pretty much everything he's suggesting is good advice.
godid 8y ago
If introducing a functional language was the aim (EDIT: that's my reading of the motivation here) then, given the political context described, I can't help but feel a better choice would have been F#. It ticks, or half ticks, most of the points in the "Benefits of Using Haskell" section. Whilst also coming armed with C# interop and integration with the .NET ecosystem in which they were already invested.
- iammiles 8y ago
  My thoughts exactly. I'm curious what compelled the author to choose Haskell over F#.
  - vmchale 8y ago
    I'm not familiar with F# but from what I understand it lacks support for laziness, unlike GHC.
    - akra 8y ago
      As a counter to this that may make it easier for a company to adopt and reduce the learning curve. Laziness can make it harder for some to reason about performance as an example.
      - vmchale 8y ago
        > Laziness can make it harder for some to reason about performance as an example. Lots of people are fond of pointing this out, but very few are actually able to reason about performance of lazy data structures.
    - Barrin92 8y ago
      I think this is Haskell's biggest disadvantage in industrial sized applications because it significantly complicates debugging and performance reasoning. Laziness is, in my opinion, the wrong default.
      - vmchale 8y ago
        > complicates debugging and performance reasoning Lots of people say this, very few understand what it actually means and how to do the analyses. > Laziness is, in my opinion, the wrong default. Unfortunately, GHC is still the only compiler with first-class support for laziness as well as strictness. And you need both if you want to be able to do immutable functional programming. But in the grand scheme of things it doesn't really matter if you know what you're doing when you use data structures. Some data structures are meant to be strict, others lazy. Haskell allows you to create data structures that are strict in the right places fairly cheaply.
    - nestorD 8y ago
      The language does support laziness, it is just not the deafault.
      - nybble41 8y ago
        The default is the whole point. Almost any language can support lazy evaluation, given enough boilerplate, but laziness-by-default is a major contributor toward making Haskell code more composable and reusable compared to idiomatic code in other languages. In strict-by-default languages one must decide up front whether to permit evaluation to be deferred, and there is a cost to be paid via more awkward syntax to first capture the deferred computation and then explicitly evaluate it. This also tends to add runtime overhead which a Haskell compiler would optimize out in cases strict evaluation can be inferred. As a result, libraries generally expose only strict interfaces—and while most lazy functions can easily be made strict in Haskell with judicious application of `seq`, the reverse is not so simple. Sure, sometimes excessive laziness becomes a problem. However, these cases are not that common, or particularly difficult for an moderately experienced Haskell coder to identify or work around. Enforcing strictness-by-default just because one does not foresee a need for laziness, without any evidence that laziness is negatively impacting performance, would be a form of premature optimization.
  - toastal 8y ago
    If I recall, F# doesn't require managed IO which just opens up a can of debugging worms to where you have no guarantees of where side effects and impurity are happening.
  - deleted 8y ago
    [deleted]
- village-idiot 8y ago
  Don’t forget the importance of Microsoft’s approval, that carries a lot of weight.
- jimmcslim 8y ago
  Which points do you believe that F# doesn't tick, or only half ticks?
- thedataangel 8y ago
  In my experience, languages that try to bridge OO and functional ecosystems (F#, Scala, etc) tend to suffer from a lot of split-brain / "worst of both worlds" syndrome. You miss a lot of the advantages of FP unless you go all-in on it like Haskell does.
  - vmchale 8y ago
    > You miss a lot of the advantages of FP unless you go all-in on it like Haskell does. I'm not familiar with F# but Scala at least has a far inferior compiler (compared to GHC). There are a lot of functional techniques that simply don't make sense when you don't have dedicated tooling to support them.
  - nestorD 8y ago
    My experience with F# is that functional programming is the default paradigm while object oriented is used when it is required or easier (or required by a C# library you really want). A striking difference with the little Scala I read in the wild (where object oriented was the clear default). The same goes for mutability, it is there and you should certainly use it when it makes sense but it is not the default.
    - thedataangel 8y ago
      > The same goes for mutability, it is there and you should certainly use it when it makes sense but it is not the default. This is also true for Haskell. It's not especially hard to get and use mutable variables, they're just not something that most tutorials cover.
      - nybble41 8y ago
        Haskell has confined mutation with the State and ST types, which guarantees that whatever may be going on inside, the external interface to the function is pure. My main problem with F# (and other multi-paradigm / "functional-first" languages) is that they do not provide any such guarantees; purity becomes merely a matter of convention and convenience, not something ensured by the language. This misses the entire point of functional programming, IMHO, which is referential transparency, and greatly increases the complexity since there are things that matter in F#, like evaluation order, which purity renders completely irrelevant in Haskell. (Yes, Haskell does have unsafePerformIO and the like for special cases, but the expectation is still that the external interface remains pure. If you deliberately circumvent the language's protections and fail to adhere to this rule then you get to keep both pieces when it inevitably breaks. The compiler is still going to operate under the assumptions that the result depends only on the explicit inputs and that evaluating the function has no side effects.)
- nestorD 8y ago
  And if you ever want to convince a manager that F# could make a difference in productivity/safety/... : http://fpbridge.co.uk/why-fsharp.html http://fpbridge.co.uk/why-fsharp.html
timwaagh 8y ago
I like haskell. It reads like a math proof more than a cooking recipe. very elegant. I'm a math guy and i'd love to get back to it in my free time. But i don't think i could recommend it for the enterprise. not honestly. I tried to do a professional project in Haskell once. it was a good fit, since it was about parsing and generating configuration. However I was still new to it. the bottom line: it's just not that great for newbies. since most people are going to be newbies at it, i could not recommend it at all. sometimes i think the language even goes over my head, and I'm supposed to be a pretty smart cookie. OP makes 'they are not going to be productive for months' sound like an obstacle to overcome. But if I tell management the honest story in advance and they will obviously not give me the greenlight. But i suppose it is a language that's a reasonably easy sell to management if you hype up the reliability stemming from the type system and skip over the downsides. managers dont know much about programming, but they hate incidents even more than developers. if you are honest, you have to tell them that in practise operational problems become more likely. I mean: ever tried to install ghc on a centos server behind a firewall? If i have to recommend something now it would be python. because it's easy and because i started using it for my personal stuff. i know lots of languages and that's what i end up coming back to if i need to do stuff quickly. OP doesn't even mention the real advantage to introducing Haskell. Few colleagues will end up being good at this, so if a piece of critical software is written in Haskell and you are the only one who is a great Haskell engineer, it increases your negotiating power in the company. people won't be able to get around you and it will be hard to deny a request for increased compensation.
- platz 8y ago
  > OP doesn't even mention the real advantage to introducing Haskell. Yes, he does - contrary to the non-technical political motives you outlined - he outlines the importance of a strong type system for maintenance and refactoring—A property much harder to achieve in something like python. I think your own experience of having some difficulty bringing your previous skills to bear on the language is not so uncommon—This is why mentors are so important.
  - sdinsn 8y ago
    > he outlines the importance of a strong type system for maintenance and refactoring—A property much harder to achieve in something like python. Of course a typed language is going to have a better type system than an untyped language... When you compare to a language like Java, your argument doesn't shine.
sdinsn 8y ago
"How to trick a company into adopting a language that is difficult to hire for and has a small ecosystem" If FP is the goal, then Clojure and F# would be FAR better suited.
- yen223 8y ago
  Believe it or not, it wasn't that long ago that Python was that weirdo language nobody uses.
  - XorNot 8y ago
    I mean yes but it's no longer true. It's ridiculously easy to get a job on the basis of "yeah I can do Python". My current challenge for my next job is to get an opportunity to work with Go professionally, because try as I might deploying Python reliably remains a colossal pain in the lower.
    - tudelo 8y ago
      But the programming process in python feels like cheating sometimes :)
  - sdinsn 8y ago
    And nothing is hinting that Haskell will become a mainstream language. It's an unnecessary risk for a business to take.
- xedrac 8y ago
  As much as I like Clojure (and Racket/Scheme/Lisp), it's a dynamically typed language and is a nightmare to work with on a large scale project - similar to Python. Those languages are much better suited to small projects. F# would have been a fine choice, but I think Haskell was an excellent choice despite its initial drawbacks.
sv12l 8y ago
Please don't do it, unless you know you are going to stay there (in the same project) for very long time and you know you can hire/retain and train new people in Haskell. I work for a large MNC bank and in my prev stint with a different department, for whatever reason I had to inherit a not-so-trivial Haskell code-base which gave me really hard time. Although it was in BAU mode, maintenance was difficult and hiring was even more difficult, I couldn't even get help from other guys from different projects as they are all mostly Java guys, anyway I moved and I know the new manager is trying hard to convince his boses and business for getting fund to migrate it to Java.
- zhte415 8y ago
  I might know your bank, do you run three versions of Murex at the same time? They have a pretty strong Haskell team (though somewhat small, 10s vs 1000s of Java devs), but that's what's at the core of the article. The writer seems very keen about developing and coaching a Haskell culture. So, as you say... > unless you know you are going to stay there (in the same project) for very long time and you know you can hire/retain and train new people in Haskell.
- kreetx 8y ago
  Unless there will be many capable developers who stay. If you're the single guy who has a clue then yes, don't do this if you don't have a reasonable plan for those who stay. It also sounds like maintaining a haskell code base is some rocket science. It is not. There are both extreme, but also conservative ways of doing things, and if you pick the conservative, then the people staying won't have that much trouble coping.
  - sv12l 8y ago
    Please don't get me wrong, I've been in programming for more than 13 yrs, started with C++ and moved to Java later in my career and that Haskell code is of top notch quality, it does what it was written for very well and if I remember correctly, it never caused any prod incidents, its just that the devs didn't stick around, one of them went to Uni and others to greener pastures and we found it hard to extend/enhance with new functionalities that business was asking for.
Thaxll 8y ago
Yep let's bring a language into a company where: - it's very hard to hire people - lack of libraries - lack of support / community - difficult learning curve for the language Where I work some teams are dropping Scala because hiring Scala dev is hard, so imagine Haskell...
- sitepodmatt 8y ago
  What is replacing Scala? Kotlin?
  - meh2frdf 8y ago
    In terms of people moving away from java, I would say yes. It’s a smaller leap than Scala and an easier sale to management. Quite a lot of teams that have moved to Scala have struggled, mostly around supporting the new shiny services that have been written by guys who have moved on. The TCO from my observations seems to be higher than for java. To give some context I’ve never been a fan of java.
- aphexairlines 8y ago
  Teams hiring developers versed in specific languages, libraries, databases, http servers, deployment orchestrators, etc are doing it wrong. Hire good developers. They will learn whatever technology your company uses and/or built.
  - vmchale 8y ago
    Pretty expensive, to be honest. Facebook snatches up most of the "engineers" and blockchain companies hire a lot of the academic community. That being said, if you have the money, Haskell developers will absolutely follow - and in some domains the project will actually be cheaper.
    - MrMorden 8y ago
      The executives who think good developers are "expensive" are generally happy to throw gobs of money at BPO firms to do the job half as well as in-house staff for twice as much money. Besides which, an employee with a fully-loaded cost of $200k/yr can be sent to a one-week external class for well under $15k including salary, tuition, travel, and expenses. That's far less than the cost of acquiring and onboarding that employee; and if you don't care to train your staff, they'll jump ship for an employer that doesn't suck the stars out of the sky.
incadenza 8y ago
If I'm a manager, and somebody tells me that the development team wont be productive for months, I'd likely ask for some real metric indicating that Haskell solves / eliminates classes of bugs untouched by other statically typed language. At least some figure indicating that a Haskell app is less prone to bugs, etc. Otherwise why not throw Typescript at it?
- thesz 8y ago
  The "not productive for months" is a exaggeration. Even non-trivial type-level programming can be picked up by complete novice in Haskell in less than month. I experimented with that.
- thedataangel 8y ago
  I'd probably rephrase "not" to "less". Haskell is sufficiently unlike other languages that a lot of knowledge/skills that are usually transferable between languages don't apply to it. That means you need to (re-)learn how to solve those problems in Haskell if you want to use it. The end result is _usually_ better (e.g. Lenses are in almost all cases an improvement over getters and setters; Functors, Monads and Traversable are an improvement over imperative control flow), but damn it it doesn't take a while to get your head around those concepts.
  - incadenza 8y ago
    yeah it sounds like it. One day I’ll actually dive in and learn that stuff.
didip 8y ago
"will not be productive for months" is probably going to be instant deal breaker from about 98% managers. Also, another big responsibility is teaching the rest of your coworkers. Classes, hackathons, documentations, etc.
Caillebotte 8y ago
Haskell is fantastic. In fact, it is by far my favorite language. Strict types and functional programming come together in a perfect union. Monads are very similar to JavaScript callbacks, actually. After extensive use of the language, I finally decided to give it up for 2 reasons. 1) Stack and package management. Specifically, after building many websites with Haskell's "supposedly" production ready framework, Yesod. After an upgrade, every site I made completely broke and there was almost no documentation on any version changes for this framework. Which leads me into complaint 2) Lack of good documentation. I'm not trying to take sides on the debate of self documenting code, however, when using higher level libraries, it is completely infeasible to rely on reading source code to determine what a function does. Haskell programmers believe that because of such strict typing, the code should speak for itself. Unfortunately, the real side effect of this is you end up coding trying to match up your types instead of focusing on your goal at hand.
alexandercrohde 8y ago
Absurd. The bulk of being a good-engineer is productivity, by reinventing the minimal amount possible. Highly efficient engineers are very accustomed to their tools (IDE, language, framework, database and DB drivers, webserver, deploy system, logging). Forcing a team of engineers to use a new language, IDE, framework, particularly one that has minimal backing, is something I would consider a "fireable" offense (i.e. costing the company hundreds of thousands of dollars for personal amusement). And also, if you did want to go functional, why not something used by literally any professional company? E.g. Twitter on scala.
- wink 8y ago
  Maybe I should preface that by saying I'm not a big fan of Scala... But I think Scala has the major problem that Perl has, take 5 developers and you get 6 different styles. I went from "Scala is horrible" to "oh, this actually looks nice" to "omg, what the hell" and so forth. Look at a random library as a beginner and think "is this really Scala"? And that's even ignoring the problems with sbt, binary compatibility, and so on. Yes, there were some success stories. Also some stories of replacing Java with Scala, but I've heard nearly as much "well we replaced it but we don't know if it's really better".
  - alexandercrohde 8y ago
    Seems like a very weak justification to me. I'm sure it's easier to hire an engineer who can write idiomatic scala than idiomatic haskell. But all that is aside from my main point, which was changing tools on people is almost never justified. Unless you're writing a web app in ASM, you usually should stick with your language.
- nilkn 8y ago
  I do think your analysis here is a bit shallow. - Scala is not an easy language to learn unless you just use it as a "better Java" with syntactic sugar, in which case it cannot be considered to be in the same class as Haskell. The same is true of many other languages folks are proposing, like Clojure or F#. It might be easier to bang something out with Clojure than Haskell, but I don't think it's any easier to master than Haskell. - Your estimate of the cost (hundreds of thousands of dollars) assumes there's no benefit to the switch. There may or may not be, but you didn't even account for that possibility. - Highly efficient engineers are also efficient at learning new tools, frameworks, IDEs, etc., because for many developers that's part of daily life.
tayo42 8y ago
Somewhat related. How do you introduce any language? How do you get past writing anything that isn't java,c/c++ and python without being a cowboy. In my short experience writing with any other language gets a somewhat negative response.
wink 8y ago
This was an interesting read but the "some people didn't like this and thus left" left a sour taste. I'm a big fan of team decisions for tooling and languages used and I'd personally have some problems if someone told me we'd be switching languages next month. Well, unless I already knew the language and/or tried and liked it - but that's just a random coincidence that I like using and learning a lot of languages.
- bojo 8y ago
  I should have been more clear. People left due to their unhappiness with the company merger, not the development team merger specifically.
risto1 8y ago
Benefits of using haskell - Reduce programmer cognitive overload I don't know how he could honestly say that. Haskell is much more cognitively demanding than other languages from my experience A lot of the benefits he talks about he could get from F# or Ocaml, which are much simpler to learn and use for a team That being said, I think haskell does have unique niche in industry: if the company does something very complex and cognitively demanding and requires the best and the brightest, using haskell can be a way of luring the best and brightest to work there
- ealhad 8y ago
  > Haskell is much more cognitively demanding than other languages from my experience How? I think Haskell code can be overcomplicated sometimes, but that's not mandatory.
  - AnimalMuppet 8y ago
    If you have internalized the concepts Haskell is built on (to the point that you don't have to think about them), then Haskell can be as simple as any other language, maybe even simpler. But if you have to still have to think about the underlying concepts, Haskell probably is more cognitively demanding.
    - ealhad 8y ago
      That's exactly the point, yes. People just have to properly learn the language.
      - AnimalMuppet 8y ago
        I'm not sure it's that simple. I suspect (but cannot prove) that some people are naturally procedural thinkers, and others are naturally functional thinkers. Haskell just makes sense to some people - and not to others. To say they "just have to properly learn the language"... I could say the same about you and C. Assuming I'm right, can the naturally procedural thinkers really learn to use Haskell? Probably yes, at least most of them. Will it ever be as easy to them as procedural programming? Probably not. What will that "not as easy" look like? Greater cognitive load. I am aware that all of this depends on my opening assumption being correct...
bojo 8y ago
As the OP I am happy to see this post make its way to HN. I hope the contents have helped people/teams willing to take something positive from it.
- kreetx 8y ago
  It's a wonderful write up, thank you! We should have more of these from seasoned developers. There are a lot of hard core math/type theory guys on reddit and elsewhere (who I have lots of respect for), but in an industry setting there are (1) features to deliver and (2) people to be dealt with -- outsmarting has little place with those. You have apparently succeeded in doing the jump in this setting.

130 points by k0t0n0 8y ago

I've done something very similar, albeit with a more bottom-up approach. Pretty much everything he's suggesting is good advice.

godid 8y ago

If introducing a functional language was the aim (EDIT: that's my reading of the motivation here) then, given the political context described, I can't help but feel a better choice would have been F#. It ticks, or half ticks, most of the points in the "Benefits of Using Haskell" section. Whilst also coming armed with C# interop and integration with the .NET ecosystem in which they were already invested.

iammiles 8y ago
My thoughts exactly. I'm curious what compelled the author to choose Haskell over F#.
- vmchale 8y ago
  I'm not familiar with F# but from what I understand it lacks support for laziness, unlike GHC.
  - akra 8y ago
    As a counter to this that may make it easier for a company to adopt and reduce the learning curve. Laziness can make it harder for some to reason about performance as an example.
    - vmchale 8y ago
      > Laziness can make it harder for some to reason about performance as an example. Lots of people are fond of pointing this out, but very few are actually able to reason about performance of lazy data structures.
  - Barrin92 8y ago
    I think this is Haskell's biggest disadvantage in industrial sized applications because it significantly complicates debugging and performance reasoning. Laziness is, in my opinion, the wrong default.
    - vmchale 8y ago
      > complicates debugging and performance reasoning Lots of people say this, very few understand what it actually means and how to do the analyses. > Laziness is, in my opinion, the wrong default. Unfortunately, GHC is still the only compiler with first-class support for laziness as well as strictness. And you need both if you want to be able to do immutable functional programming. But in the grand scheme of things it doesn't really matter if you know what you're doing when you use data structures. Some data structures are meant to be strict, others lazy. Haskell allows you to create data structures that are strict in the right places fairly cheaply.
  - nestorD 8y ago
    The language does support laziness, it is just not the deafault.
    - nybble41 8y ago
      The default is the whole point. Almost any language can support lazy evaluation, given enough boilerplate, but laziness-by-default is a major contributor toward making Haskell code more composable and reusable compared to idiomatic code in other languages. In strict-by-default languages one must decide up front whether to permit evaluation to be deferred, and there is a cost to be paid via more awkward syntax to first capture the deferred computation and then explicitly evaluate it. This also tends to add runtime overhead which a Haskell compiler would optimize out in cases strict evaluation can be inferred. As a result, libraries generally expose only strict interfaces—and while most lazy functions can easily be made strict in Haskell with judicious application of `seq`, the reverse is not so simple. Sure, sometimes excessive laziness becomes a problem. However, these cases are not that common, or particularly difficult for an moderately experienced Haskell coder to identify or work around. Enforcing strictness-by-default just because one does not foresee a need for laziness, without any evidence that laziness is negatively impacting performance, would be a form of premature optimization.
- toastal 8y ago
  If I recall, F# doesn't require managed IO which just opens up a can of debugging worms to where you have no guarantees of where side effects and impurity are happening.
- deleted 8y ago
  [deleted]
village-idiot 8y ago
Don’t forget the importance of Microsoft’s approval, that carries a lot of weight.
jimmcslim 8y ago
Which points do you believe that F# doesn't tick, or only half ticks?
thedataangel 8y ago
In my experience, languages that try to bridge OO and functional ecosystems (F#, Scala, etc) tend to suffer from a lot of split-brain / "worst of both worlds" syndrome. You miss a lot of the advantages of FP unless you go all-in on it like Haskell does.
- vmchale 8y ago
  > You miss a lot of the advantages of FP unless you go all-in on it like Haskell does. I'm not familiar with F# but Scala at least has a far inferior compiler (compared to GHC). There are a lot of functional techniques that simply don't make sense when you don't have dedicated tooling to support them.
- nestorD 8y ago
  My experience with F# is that functional programming is the default paradigm while object oriented is used when it is required or easier (or required by a C# library you really want). A striking difference with the little Scala I read in the wild (where object oriented was the clear default). The same goes for mutability, it is there and you should certainly use it when it makes sense but it is not the default.
  - thedataangel 8y ago
    > The same goes for mutability, it is there and you should certainly use it when it makes sense but it is not the default. This is also true for Haskell. It's not especially hard to get and use mutable variables, they're just not something that most tutorials cover.
    - nybble41 8y ago
      Haskell has confined mutation with the State and ST types, which guarantees that whatever may be going on inside, the external interface to the function is pure. My main problem with F# (and other multi-paradigm / "functional-first" languages) is that they do not provide any such guarantees; purity becomes merely a matter of convention and convenience, not something ensured by the language. This misses the entire point of functional programming, IMHO, which is referential transparency, and greatly increases the complexity since there are things that matter in F#, like evaluation order, which purity renders completely irrelevant in Haskell. (Yes, Haskell does have unsafePerformIO and the like for special cases, but the expectation is still that the external interface remains pure. If you deliberately circumvent the language's protections and fail to adhere to this rule then you get to keep both pieces when it inevitably breaks. The compiler is still going to operate under the assumptions that the result depends only on the explicit inputs and that evaluating the function has no side effects.)
nestorD 8y ago
And if you ever want to convince a manager that F# could make a difference in productivity/safety/... : http://fpbridge.co.uk/why-fsharp.html http://fpbridge.co.uk/why-fsharp.html

timwaagh 8y ago

I like haskell. It reads like a math proof more than a cooking recipe. very elegant. I'm a math guy and i'd love to get back to it in my free time. But i don't think i could recommend it for the enterprise. not honestly. I tried to do a professional project in Haskell once. it was a good fit, since it was about parsing and generating configuration. However I was still new to it. the bottom line: it's just not that great for newbies. since most people are going to be newbies at it, i could not recommend it at all. sometimes i think the language even goes over my head, and I'm supposed to be a pretty smart cookie. OP makes 'they are not going to be productive for months' sound like an obstacle to overcome. But if I tell management the honest story in advance and they will obviously not give me the greenlight. But i suppose it is a language that's a reasonably easy sell to management if you hype up the reliability stemming from the type system and skip over the downsides. managers dont know much about programming, but they hate incidents even more than developers. if you are honest, you have to tell them that in practise operational problems become more likely. I mean: ever tried to install ghc on a centos server behind a firewall? If i have to recommend something now it would be python. because it's easy and because i started using it for my personal stuff. i know lots of languages and that's what i end up coming back to if i need to do stuff quickly. OP doesn't even mention the real advantage to introducing Haskell. Few colleagues will end up being good at this, so if a piece of critical software is written in Haskell and you are the only one who is a great Haskell engineer, it increases your negotiating power in the company. people won't be able to get around you and it will be hard to deny a request for increased compensation.

platz 8y ago
> OP doesn't even mention the real advantage to introducing Haskell. Yes, he does - contrary to the non-technical political motives you outlined - he outlines the importance of a strong type system for maintenance and refactoring—A property much harder to achieve in something like python. I think your own experience of having some difficulty bringing your previous skills to bear on the language is not so uncommon—This is why mentors are so important.
- sdinsn 8y ago
  > he outlines the importance of a strong type system for maintenance and refactoring—A property much harder to achieve in something like python. Of course a typed language is going to have a better type system than an untyped language... When you compare to a language like Java, your argument doesn't shine.

sdinsn 8y ago

"How to trick a company into adopting a language that is difficult to hire for and has a small ecosystem" If FP is the goal, then Clojure and F# would be FAR better suited.

yen223 8y ago
Believe it or not, it wasn't that long ago that Python was that weirdo language nobody uses.
- XorNot 8y ago
  I mean yes but it's no longer true. It's ridiculously easy to get a job on the basis of "yeah I can do Python". My current challenge for my next job is to get an opportunity to work with Go professionally, because try as I might deploying Python reliably remains a colossal pain in the lower.
  - tudelo 8y ago
    But the programming process in python feels like cheating sometimes :)
- sdinsn 8y ago
  And nothing is hinting that Haskell will become a mainstream language. It's an unnecessary risk for a business to take.
xedrac 8y ago
As much as I like Clojure (and Racket/Scheme/Lisp), it's a dynamically typed language and is a nightmare to work with on a large scale project - similar to Python. Those languages are much better suited to small projects. F# would have been a fine choice, but I think Haskell was an excellent choice despite its initial drawbacks.

sv12l 8y ago

Please don't do it, unless you know you are going to stay there (in the same project) for very long time and you know you can hire/retain and train new people in Haskell. I work for a large MNC bank and in my prev stint with a different department, for whatever reason I had to inherit a not-so-trivial Haskell code-base which gave me really hard time. Although it was in BAU mode, maintenance was difficult and hiring was even more difficult, I couldn't even get help from other guys from different projects as they are all mostly Java guys, anyway I moved and I know the new manager is trying hard to convince his boses and business for getting fund to migrate it to Java.

zhte415 8y ago
I might know your bank, do you run three versions of Murex at the same time? They have a pretty strong Haskell team (though somewhat small, 10s vs 1000s of Java devs), but that's what's at the core of the article. The writer seems very keen about developing and coaching a Haskell culture. So, as you say... > unless you know you are going to stay there (in the same project) for very long time and you know you can hire/retain and train new people in Haskell.
kreetx 8y ago
Unless there will be many capable developers who stay. If you're the single guy who has a clue then yes, don't do this if you don't have a reasonable plan for those who stay. It also sounds like maintaining a haskell code base is some rocket science. It is not. There are both extreme, but also conservative ways of doing things, and if you pick the conservative, then the people staying won't have that much trouble coping.
- sv12l 8y ago
  Please don't get me wrong, I've been in programming for more than 13 yrs, started with C++ and moved to Java later in my career and that Haskell code is of top notch quality, it does what it was written for very well and if I remember correctly, it never caused any prod incidents, its just that the devs didn't stick around, one of them went to Uni and others to greener pastures and we found it hard to extend/enhance with new functionalities that business was asking for.

Thaxll 8y ago

Yep let's bring a language into a company where: - it's very hard to hire people - lack of libraries - lack of support / community - difficult learning curve for the language Where I work some teams are dropping Scala because hiring Scala dev is hard, so imagine Haskell...

sitepodmatt 8y ago
What is replacing Scala? Kotlin?
- meh2frdf 8y ago
  In terms of people moving away from java, I would say yes. It’s a smaller leap than Scala and an easier sale to management. Quite a lot of teams that have moved to Scala have struggled, mostly around supporting the new shiny services that have been written by guys who have moved on. The TCO from my observations seems to be higher than for java. To give some context I’ve never been a fan of java.
aphexairlines 8y ago
Teams hiring developers versed in specific languages, libraries, databases, http servers, deployment orchestrators, etc are doing it wrong. Hire good developers. They will learn whatever technology your company uses and/or built.
- vmchale 8y ago
  Pretty expensive, to be honest. Facebook snatches up most of the "engineers" and blockchain companies hire a lot of the academic community. That being said, if you have the money, Haskell developers will absolutely follow - and in some domains the project will actually be cheaper.
  - MrMorden 8y ago
    The executives who think good developers are "expensive" are generally happy to throw gobs of money at BPO firms to do the job half as well as in-house staff for twice as much money. Besides which, an employee with a fully-loaded cost of $200k/yr can be sent to a one-week external class for well under $15k including salary, tuition, travel, and expenses. That's far less than the cost of acquiring and onboarding that employee; and if you don't care to train your staff, they'll jump ship for an employer that doesn't suck the stars out of the sky.

incadenza 8y ago

If I'm a manager, and somebody tells me that the development team wont be productive for months, I'd likely ask for some real metric indicating that Haskell solves / eliminates classes of bugs untouched by other statically typed language. At least some figure indicating that a Haskell app is less prone to bugs, etc. Otherwise why not throw Typescript at it?

thesz 8y ago
The "not productive for months" is a exaggeration. Even non-trivial type-level programming can be picked up by complete novice in Haskell in less than month. I experimented with that.
thedataangel 8y ago
I'd probably rephrase "not" to "less". Haskell is sufficiently unlike other languages that a lot of knowledge/skills that are usually transferable between languages don't apply to it. That means you need to (re-)learn how to solve those problems in Haskell if you want to use it. The end result is _usually_ better (e.g. Lenses are in almost all cases an improvement over getters and setters; Functors, Monads and Traversable are an improvement over imperative control flow), but damn it it doesn't take a while to get your head around those concepts.
- incadenza 8y ago
  yeah it sounds like it. One day I’ll actually dive in and learn that stuff.

didip 8y ago

"will not be productive for months" is probably going to be instant deal breaker from about 98% managers. Also, another big responsibility is teaching the rest of your coworkers. Classes, hackathons, documentations, etc.

Caillebotte 8y ago

Haskell is fantastic. In fact, it is by far my favorite language. Strict types and functional programming come together in a perfect union. Monads are very similar to JavaScript callbacks, actually. After extensive use of the language, I finally decided to give it up for 2 reasons. 1) Stack and package management. Specifically, after building many websites with Haskell's "supposedly" production ready framework, Yesod. After an upgrade, every site I made completely broke and there was almost no documentation on any version changes for this framework. Which leads me into complaint 2) Lack of good documentation. I'm not trying to take sides on the debate of self documenting code, however, when using higher level libraries, it is completely infeasible to rely on reading source code to determine what a function does. Haskell programmers believe that because of such strict typing, the code should speak for itself. Unfortunately, the real side effect of this is you end up coding trying to match up your types instead of focusing on your goal at hand.

alexandercrohde 8y ago

Absurd. The bulk of being a good-engineer is productivity, by reinventing the minimal amount possible. Highly efficient engineers are very accustomed to their tools (IDE, language, framework, database and DB drivers, webserver, deploy system, logging). Forcing a team of engineers to use a new language, IDE, framework, particularly one that has minimal backing, is something I would consider a "fireable" offense (i.e. costing the company hundreds of thousands of dollars for personal amusement). And also, if you did want to go functional, why not something used by literally any professional company? E.g. Twitter on scala.

wink 8y ago
Maybe I should preface that by saying I'm not a big fan of Scala... But I think Scala has the major problem that Perl has, take 5 developers and you get 6 different styles. I went from "Scala is horrible" to "oh, this actually looks nice" to "omg, what the hell" and so forth. Look at a random library as a beginner and think "is this really Scala"? And that's even ignoring the problems with sbt, binary compatibility, and so on. Yes, there were some success stories. Also some stories of replacing Java with Scala, but I've heard nearly as much "well we replaced it but we don't know if it's really better".
- alexandercrohde 8y ago
  Seems like a very weak justification to me. I'm sure it's easier to hire an engineer who can write idiomatic scala than idiomatic haskell. But all that is aside from my main point, which was changing tools on people is almost never justified. Unless you're writing a web app in ASM, you usually should stick with your language.
nilkn 8y ago
I do think your analysis here is a bit shallow. - Scala is not an easy language to learn unless you just use it as a "better Java" with syntactic sugar, in which case it cannot be considered to be in the same class as Haskell. The same is true of many other languages folks are proposing, like Clojure or F#. It might be easier to bang something out with Clojure than Haskell, but I don't think it's any easier to master than Haskell. - Your estimate of the cost (hundreds of thousands of dollars) assumes there's no benefit to the switch. There may or may not be, but you didn't even account for that possibility. - Highly efficient engineers are also efficient at learning new tools, frameworks, IDEs, etc., because for many developers that's part of daily life.

tayo42 8y ago

Somewhat related. How do you introduce any language? How do you get past writing anything that isn't java,c/c++ and python without being a cowboy. In my short experience writing with any other language gets a somewhat negative response.

wink 8y ago

This was an interesting read but the "some people didn't like this and thus left" left a sour taste. I'm a big fan of team decisions for tooling and languages used and I'd personally have some problems if someone told me we'd be switching languages next month. Well, unless I already knew the language and/or tried and liked it - but that's just a random coincidence that I like using and learning a lot of languages.

bojo 8y ago
I should have been more clear. People left due to their unhappiness with the company merger, not the development team merger specifically.

risto1 8y ago

Benefits of using haskell - Reduce programmer cognitive overload I don't know how he could honestly say that. Haskell is much more cognitively demanding than other languages from my experience A lot of the benefits he talks about he could get from F# or Ocaml, which are much simpler to learn and use for a team That being said, I think haskell does have unique niche in industry: if the company does something very complex and cognitively demanding and requires the best and the brightest, using haskell can be a way of luring the best and brightest to work there

ealhad 8y ago
> Haskell is much more cognitively demanding than other languages from my experience How? I think Haskell code can be overcomplicated sometimes, but that's not mandatory.
- AnimalMuppet 8y ago
  If you have internalized the concepts Haskell is built on (to the point that you don't have to think about them), then Haskell can be as simple as any other language, maybe even simpler. But if you have to still have to think about the underlying concepts, Haskell probably is more cognitively demanding.
  - ealhad 8y ago
    That's exactly the point, yes. People just have to properly learn the language.
    - AnimalMuppet 8y ago
      I'm not sure it's that simple. I suspect (but cannot prove) that some people are naturally procedural thinkers, and others are naturally functional thinkers. Haskell just makes sense to some people - and not to others. To say they "just have to properly learn the language"... I could say the same about you and C. Assuming I'm right, can the naturally procedural thinkers really learn to use Haskell? Probably yes, at least most of them. Will it ever be as easy to them as procedural programming? Probably not. What will that "not as easy" look like? Greater cognitive load. I am aware that all of this depends on my opening assumption being correct...

bojo 8y ago

As the OP I am happy to see this post make its way to HN. I hope the contents have helped people/teams willing to take something positive from it.

kreetx 8y ago
It's a wonderful write up, thank you! We should have more of these from seasoned developers. There are a lot of hard core math/type theory guys on reddit and elsewhere (who I have lots of respect for), but in an industry setting there are (1) features to deliver and (2) people to be dealt with -- outsmarting has little place with those. You have apparently succeeded in doing the jump in this setting.