
Introducing Haskell to a Company - k0t0n0
https://alasconnect.github.io/blog/posts/2018-10-02-introducing-haskell-to-a-company.html
======
timwaagh
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
> 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
> 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.

~~~
thedataangel
Haskell's type system is _worlds_ better than Java's, and it's absolutely
essential to the maintenance benefits that Haskell gives you over other
languages.

~~~
crehn
Just curious, but care to give a practical example of how it's worlds better?

~~~
thedataangel
Practically speaking, Haskell's type system gives you a lot of code for free.

Stuff like "toString", "equals" and inequalities that you'd usually implement
manually in something like Java are done for you automatically by the
compiler, with a one-line directive.

That system is extensible as well, so for example you can automatically get
Serde code for stuff like JSON, Avro, Protobuf etc with a one-liner.

On a more abstract level, there's a lot of stuff you can express in Haskell
that's difficult or impossible on a technical level in Java. For example:

\- Functions which are polymorphic in their return type, so that what they do
is determined by what type the caller wants them to return.

\- Function constraints - for example try to express "A function which takes
two polymorphic arguments, which must both be of the same type, and which must
be orderable (i.e have <, ==, >, etc defined for them), and returns the same
type" in Java. In Haskell, that's just "f :: Ord a => a -> a -> a".

\- Higher kinded types. These let you have (loosely speaking) polymorphic
containers. For example, instead of List<A> and Set<A>, in Haskell you'd have
something like Traversable t => t a, where Traversable is a particular
interface you want your "container" to implement.

~~~
davidgay
You need some better examples (your examples all appear expressible in Java):

> \- Functions which are polymorphic in their return type, so that what they
> do is determined by what type the caller wants them to return

You'll have to be more specific here - polymophism in the return type is
clearly trivial w/o specific constraints, e.g. <T> T identity(T x) { return x;
}

> \- Function constraints - for example try to express "A function which takes
> two polymorphic arguments, which must both be of the same type, and which
> must be orderable (i.e have <, ==, >, etc defined for them), and returns the
> same type" in Java. In Haskell, that's just "f :: Ord a => a -> a -> a".

<T extends Comparable<T>> T f(T a1, T a2)

> \- Higher kinded types. These let you have (loosely speaking) polymorphic
> containers. For example, instead of List<A> and Set<A>, in Haskell you'd
> have something like Traversable t => t a, where Traversable is a particular
> interface you want your "container" to implement.

Iterable<T>

If you're arguing that the Java version requires the types to declare that
they implement Iterable, Comparable, etc, I think that's more a philosophical
distinction about programmer responsibilities rather than a technical type
system difference.

Haskell does have a fancier type system than Java, so you can actually present
some interesting differences. However, my belief and observation is that for
many smart programmers, Java's type system is already "too fancy", i.e., too
hard for many people to use effectively. So I'm somewhat skeptical of the
extra value brought by Haskell's type system.

~~~
hderms
I think one distinction is that typeclasses let you add some new 'interface'
like Fooable and then implement them for standard types like String and Int as
well as allow the user of the library to implement a version as well. With
generic programming like Shapeless in Scala one could also recursively derive
a Json decoder based on having Decode defined for all the components types of
some nested arbitrary data object.

A lot of this stuff is possible in other languages for varying definitions of
'possible' which usually comes down to how much code you have to write to do
this, how flexible it is with code you haven't explicitly written (i.e.
standard prelude types or what have you) and how much the ecosystems that
exist in these languages are oriented in a manner which takes advantage of
these features.

Consider nullability in Java and how pervasive it is. Java has tons of great
software but the type system is lacking based on how many functions could
return null but don't document it, could throw an exception but don't document
it, etc... This is predominantly because actually handling nullability on the
type level, or error handling on the type level is not straightforward in
Java.

------
godid
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
My thoughts exactly. I'm curious what compelled the author to choose Haskell
over F#.

~~~
vmchale
I'm not familiar with F# but from what I understand it lacks support for
laziness, unlike GHC.

~~~
Barrin92
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
> 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.

------
incadenza
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?

~~~
thedataangel
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
yeah it sounds like it. One day I’ll actually dive in and learn that stuff.

------
sv12l
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.

~~~
kreetx
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
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
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...

~~~
aphexairlines
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.

~~~
pythonaut_16
I think this is the wrong mindset.

A better one would be: "Hire good developers. You can invest in teaching them
whatever technology your company uses and/or built."

Otherwise you end up with companies that hire good developers who don't know
the tech stack and expect them to be 110% productive in one week with no
investment from the company in training them. Then, even if the developer can
keep up with demands they end up writing sub par code due to unfamiliarity
with the tech stack.

~~~
aphexairlines
That's probably a better way to phrase it.

------
tayo42
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.

------
sdinsn
"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
Believe it or not, it wasn't that long ago that Python was that weirdo
language nobody uses.

~~~
XorNot
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
But the programming process in python feels like cheating sometimes :)

------
wink
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
I should have been more clear. People left due to their unhappiness with the
company merger, not the development team merger specifically.

------
bojo
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
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.

------
Caillebotte
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.

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

------
risto1
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

~~~
bojo
When we say "reduce programmer cognitive overload" we are usually talking
about purity.

    
    
      f :: A -> B
    

There is nothing ambiguous about this function when considering application
state and IO. You cannot call fireTheMissiles inside it, it performs no side
effects. It simply takes an A and returns a B.

The headphone rule always comes to mind when talking about this. Typically
developer productivity is killed when a developer is interrupted because they
are trying to maintain a complete picture of time and space in their head.
This problem is much less so with Haskell because you can just glance at the
inputs and outputs of the function you were working on and get back on track
immediately.

In the sense that you are implying, that the language itself is cognitively
demanding, I would argue that is only a beginner problem. Once the core
concepts are internalized it's actually very easy to use.

Where it gets hard and becomes a mental burden is when you start going off the
map and looking into some of the more advanced concepts, like type level
programming, which to date we haven't had to pay attention to or use on my
team.

~~~
risto1
If you're talking about purity then I'd agree with that, but I'm talking about
haskell as a language.

I'm definitely not a haskell beginner, and I know others who are definitely
not beginners and they feel the same way.

I'm talking about the language as a whole. With all of the extensions
available, there's plenty there for even seasoned haskellers to learn. Sure
you can get used to anything, but I've found the more advanced type features,
and higher kinded polymorphism, to make code and type errors harder to reason
about. Sometimes type inference screws up in ways that makes it hard to figure
out whats going on.

------
didip
"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.

------
alexandercrohde
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.

~~~
nilkn
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.

~~~
lmm
> 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 question is how you get to there from here.

6-8 years ago I wrote "better Java" style Scala. For the last couple of years
I've been writing Haskell-like Scala and enjoy all the cited advantages. But,
crucially, I was able to remain productive the whole time, and do all my
learning on the clock while working on real, useful projects. Nowadays I could
probably get by in Haskell (I would still choose Scala over Haskell, but
that's a separate discussion), but if I'd tried to start with it in the first
place I would never have got off the ground.

~~~
nilkn
I'm not necessarily arguing in favor of a team being spontaneously switched to
Haskell (any big move like that seems ill-advised in general), but I do find
this overall line of reasoning a little unconvincing. You're suggesting that
you'll only learn something if there's a smooth, continuous path to its
mastery from what you already know. That basically leaves you stuck in
whatever connected component of programming expertise you're already in,
incapable of making a big jump anywhere else.

~~~
lmm
> You're suggesting that you'll only learn something if there's a smooth,
> continuous path to its mastery from what you already know. That basically
> leaves you stuck in whatever connected component of programming expertise
> you're already in, incapable of making a big jump anywhere else.

Indeed it does, but I think it's the right choice. How many times can you
afford to "not be productive for months" for the sake of learning some new
paradigm that promises the world - and how many actually deliver on what their
advocates claim? There are dozens or hundreds out there, and while I now know
from experience that the advantages of Haskell-style functional programming
are real, a priori there was no way to distinguish it from all the oversold-
but-useless approaches that are out there. Indeed my experience is that
whether you can do it incrementally is actually quite a good signal for
whether there's real value in a paradigm, or it's a load of hot air.

