
How to Sell Excellence - lelf
https://docs.google.com/presentation/d/1a4GvI0dbL8sfAlnTUwVxhq4_j-QiDlz02_t0XZJXnzY/preview?sle=true&slide=id.p
======
amazing_jose
I loved Haskell, seriously!

The year was 1997 and my uni professor was contributing to Hugs (do you
remember it?). But, while I was working my way through Monads and stuff other
people were running circles around me in C or C++. The basics were "simple"
(even for basic C++) and they concentrated in getting things done.

Years later I launched my first start-up idea on Common Lisp. In both
situation I learnt two hard truths:

a) libraries and support are very important

b) Architecture + basics >>>>> any particular technology

Now we are in 2015 (nearly 20 years later) and Haskell has advanced as much as
Common Lisp on regards of usefulness for the general business. People still
consider them elite (or 1337!) languages for showing off, meanwhile the rest
of the world (with its mediocre programmers and tools) are running circles
again. Programs now are distributed around dozens, hundreds or thousands of
machines. Latency, networks, deployments, services, data communication,...

In the end I selected Python as my main programming language, following
Norvig's advice that Python made for a good replacement for Lisp. I don't
regret my decision not even a bit. Python paid/pays my bills. Yet, from time
to time I read this posts and presentations and I feel a bit of envy for not
being in a position where I could say «I reject your reality and substitute my
own» and use Haskell or Common Lisp for main infrastructure to have the 1337
feeling again... like when I use obscure operative systems and end up in
fruitless battles over how they are better even taking into account the lack
of mainstream adoption (I'm staring at you Haiku-os!).

~~~
deeviant
I really could not have said it better. Programmers seem much more likely to
feel the need to prove they are smarter than their peers than the average
population and functional languages seem to be a very popular I'm-smarter-
than-you badge to bandy about.

I think the penetration of functional programming speaks for itself. If a tool
is clearly superior, you'd expect it to do great things, and to do it often. I
hear tons of excuses but not one that has made any sense.

To be clear, I'm not say functional languages are worthless, I am succinctly
saying that they are not measurably more productive than the usual suspects
and I say this after having a rather pleasant experience with erlang working
on a rather huge ejabberd plugin.

~~~
amazing_jose
Going philosophical (and I do this a lot), it's really about exploration of
the solutions space. I think the whole profession has moved a step forward and
we need metaphors, tools and architectures for systems where one computer
(regardless of the number of CPUs or architecture) is just a component in our
systems. Functional programming (not Functional design, think Map/Reduce) is a
late attempt to improve on a "semi-solved" problem: to produce high quality
systems that run inside a unique computer. Late attempts always can
contribute, but they only offer some negligible benefits that doesn't balance
properly with the added complexity (in technology or training... the famous
learning curve). These attempts will always be welcome and will improve some
layers on the systems we design, it's just that as move forward the benefits
will go into a diminished returns dynamic.

------
ryandvm
At the risk of sounding inflammatory... I would be willing to believe that
purely functional languages are the "one true way" if there were even the
slightest bit of empirical evidence to support it. But where are all the
successful large scale projects built with Haskell (or Clojure or whatever)?

The biggest FP project I was aware of was Twitter using Scala and they ended
up completely backing away from it. Yikes.

The only other popular site that springs to mind is Hacker News, and frankly,
it sucks. It's practically the Hello World of discussion forums.

The truth is, at the end of the day almost everything is being built with
Java, Python, Ruby, or JavaScript. Can you really blame the product owners for
being wary of writing their whole product in a functional language?

~~~
rdtsc
> But where are all the successful large scale projects built with Haskell (or
> Clojure or whatever)?

How about Erlang. Let's try it, just from the top of my head:

* AXD 301 Switch -- Classic. Powers and control phone switch networks of whole countries. Claims 99.9999999% reliability.

* Basho Riak -- popular NoSQL database, highly scalable nodes are peers

* RabbitMQ -- popular message queue used by enterprises

* WhatsApp -- messaging application, processes billions of messages a day. Built and maintained by only a few engineers. Sold for billions of dollars.

* Klarna -- European payment processing

* Bet365 -- Sports bets

* Stock trading -- Allegedly Goldman Sachs uses it.

* Erlyvideo.org -- Video streaming service

* eNodeB -- Ericsson cell to internet gateway. There is a 50% if you want to look at cat pictures from your smartphone and Erlang breaks, you won't see your cat pictures.

* Wings3D -- A subdivision 3D modeler. I guess you can build your 3D cat and then send it over WhatsApp via a eNodeB to your friend.

Those are just I know of. So there you go. Maybe you should learn Erlang ;-)

~~~
solomatov
> How about Erlang. Let's try it, just from the top of my head.

Erlang isn' purely functional language in the same sense as Haskell is. It's
much more mainstream compared to it.

Clojure has even less of it. It's basically LISP which is about 60 years old.

~~~
rdtsc
Well OP asked about Clojure so Erlang fits the profile.

But you make an interesting point in a way. One can ask, ok here are two non-
strictly functional languages that seem to be fairly practical. Used for large
distributed mission critical systems.

Would they be better off written in Haskell?

Would they have been written at all if creators only knew about Haskell?

How large is the relationship between fault tolerant and safe systems as a
product vs strong compiler type safety in the language it was written.

~~~
solomatov
>But you make an interesting point in a way. One can ask, ok here are two non-
strictly functional languages that seem to be fairly practical. Used for large
distributed mission critical systems.

I think there're at least these problems with Haskell:

* The language is badly designed. See the number of extensions which aren't standardized but widely used. See also obvious problems such as requirement to use renames when importing code, and problem with record names conflicts which isn't solved for years.

* The focus of the language isn't correct. Lazy evaluations creates a lot of problems both in program performance and complexity of the compiler. The most important parts are pureness and side effect control.

* The language is already obsolete. Many its constructions and related complexities are redundant if we unify type and expression level, and get as a result dependently typed system.

I hope some language in the future will implement these ideas, and we will
have a widely used pure functional dependently typed language with explicit
control of effects.

I see two candidates for such a language:

* Pure script - it's Haskell done right, compiledd to JS. Unfortunately, it doesn't support dependent types.

* Idris - it's the language which I describe, but I fear that it's impossible to create a widely used commercial language without major industry players' support.

~~~
mightybyte
> the number of extensions which aren't standardized but widely used.

Actually, I think this is something that Haskell did right. It allows
experimentation with new language ideas in a way that allows them to be tested
safely with existing codebases. Edward Kmett recently had this to say about
it:

> I appreciate Haskell's willingness to take a very very long view, and
> explore the design options, before committing to a path. In many ways, it is
> this feature of our community and our language that keeps other programming
> languages looking to us for features and designs to steal.

> The language is already obsolete.

By that argument so are C, C++, Java, etc. But it's about the existence of a
mature ecosystem, not about what is theoretically known.

> Pure script

PureScript is great, but its compile to JS basis makes it inappropriate as a
general purpose language.

> Idris

Idris looks promising, but it doesn't have a large enough ecosystem yet. I
would certainly be willing to switch from Haskell to Idris in the future, but
Haskell already is at least a little bit dependently typed [1] and as hinted
at above I wouldn't be surprised if Haskell is able to continue improving its
dependent typing capability as research advances.

[1]
[https://www.youtube.com/watch?v=OZWYohmLKuU](https://www.youtube.com/watch?v=OZWYohmLKuU)

~~~
jaggederest
> PureScript is great, but its compile to JS basis makes it inappropriate as a
> general purpose language.

Except that Javascript is rapidly making inroads on everything except systems
programming. If Java is a general purpose language (can't be used for systems
without translation due to the JVM), then so is anything-which-compiles-to-JS.

I think the really important thing is that, while I've been enthusiastic and
interested in Haskell for a long time now (~8 years?), the vast majority of
people will never understand even a comparatively simple concept like monads,
let alone anything higher level than that.

Until you can 'get work done' without the equivalent of graduate-level math
classes, there's simply no way to develop that 'mature ecosystem' that
everyone is hoping for. People have been using 'better if you understand the
complication' languages for a long time now, and there's a good reason they're
still niche, unfortunately.

Erlang _is_ a great language, but it's very definitely not of the same scale
of difficulty to understand as Haskell. You can noodle around with Erlang and
end up with something that works reasonably well - in my experience with
Haskell, if you can't mathematically formalize what you're talking about,
you're going to have a bad time, unless you _do_ go the 'embedded scheme
interpreter' route, which is a fun project, but why not just use Racket to
begin with?

~~~
mightybyte
> If Java is a general purpose language (can't be used for systems without
> translation due to the JVM), then so is anything-which-compiles-to-JS.

Fair point. I guess my thinking here is that PureScript is unlikely to replace
Haskell. It is _possible_ , but I think there are a few reasons that probably
won't happen. The first is that it's mission statement "PureScript is a small
strongly typed programming language that compiles to JavaScript" points it in
the wrong direction. Maybe Javascript is the counter to this, but that feels
like an anomaly. Second is that it is way behind Haskell in terms of
infrastructure, ecosystem, and a lot of core language/compiler features that
enable general purpose programming. Could swarms of people come in and change
this? Sure. But if they did, it seems to me that PureScript is similar enough
to Haskell that people could just switch to Haskell and avoid that work.

> Until you can 'get work done' without the equivalent of graduate-level math
> classes

This is a big misconception that is demonstrably untrue. I know many people
who have developed a solid working grasp of monads without doing graduate-
level math.

~~~
jaggederest
> Second is that it is way behind Haskell in terms of infrastructure,
> ecosystem, and a lot of core language/compiler features that enable general
> purpose programming.

No, it's way ahead because it's based on Javascript, and javascript is having
umpty-billion libraries developed for it right now. Of course that's not
actually a good thing at the moment but they'll settle down at some peoint.

> This is a big misconception that is demonstrably untrue. I know many people
> who have developed a solid working grasp of monads without doing graduate-
> level math.

Ref my reply to Mr. Church, but it's not just monads - you never stop running
into category theory if you're using Haskell, it's baked in.

If someone without any knowledge of category theory rewrote the language, that
statement might become true (though I'd be skeptical they'd get it right), but
as of right now, you _need_ to know category theory to understand the language
and it's base libraries.

I know, I've struggled with it for a long time - every time I have a problem,
I have to go back and reteach myself category theory to understand it.

~~~
sclv
> as of right now, you need to know category theory to understand the language
> and it's base libraries.

This is patently false. You need to know what a Functor and a Monad are, as
typeclasses with attendant laws.

But you don't need to know the definition of a "Category" much less any actual
CT.

There's nothing baked in. I think people just use "I need to learn CT" as an
excuse for not learning things, to be honest.

------
solomatov
I disagree with the presentation a lot.

* There's no widely used successful system written in Haskell. Yes, there's GHC, Agda, Idris and other research tools but they are marginal.

* It's untrue that mutable state is the main reason of problems with code. You can manage state in Java and C# in any other language.

* Haskell programmers are usually smarter than Java programmers, but they often don't want to work on tasks which they aren't very interested in, which are almost non existent, or have little business meaning.

* Haskell, actually has a lot of design flaws. The worst of them is the scope of record fields.

~~~
dragonwriter
> There's no widely used successful system written in Haskell. Yes, there's
> GHC, Agda, Idris and other research tools but they are marginal.

Google's Ganeti?

Microsoft's Bond?

> It's untrue that mutable state is the main reason of problems with code.

Its certainly one of the biggest, if not the single biggest (the only thing I
can think of that gets cited nearly as much is multithreading/parallelism, and
the main source of problems in that domain is _also_ managing mutable state in
that context.)

> You can manage state in Java and C# in any other language.

Sure, Turing equivalence means there is very little difference in what
languages _can_ do, just in how suitable the abstractions they present are to
enabling humans to do it _effectively_.

> Haskell programmers are usually smarter than Java programmers, but they
> often don't want to work on tasks which they aren't very interested in,
> which are almost non existent, or have little business meaning.

So, take Java programmers (particularly smart ones) and teach them Haskell.
Bang, you've got Haskell programmers without worrying about the interest
distribution among pre-existing Haskell programmers. Learning PLs, for skilled
programmers, isn't a huge deal -- the good Java programmers won't have much
problem becoming good Haskell programmers.

~~~
solomatov
>Google's Ganeti? Microsoft's Bond?

Only 2 known products for 20+ years of being widely known and available is
unimpressive.

~~~
dragonwriter
Those aren't the only two _known_ projects, those are just two examples of
open source projects that are, in addition, used in key infrastructure by the
major solutions provider that is the original source of the project, and so
widely, if indirectly, used.

More Haskell use in production:
[https://wiki.haskell.org/Haskell_in_industry](https://wiki.haskell.org/Haskell_in_industry)

~~~
solomatov
Compare this list to Java/C#/C++ used in the industry. Or even to
Scala/Clojure/Erlang used in industry. There will be several orders of
magnitude difference.

~~~
dragonwriter
And, so what? Sure, Haskell is less popular in industry many other languages.
That was true of all the currently popular industrial languages before they
became popular. But its certainly not the case that there are no succesfull
uses of Haskell in significant systems.

~~~
solomatov
>That was true of all the currently popular industrial languages before they
became popular.

The most popular language, namely C#, Java and C++ became popular quite
quickly.

>But its certainly not the case that there are no succesfull uses of Haskell
in significant systems.

I didn't say that. I am sure there are successful uses for Haskell, but
there're no killer apps for it.

~~~
codygman
> The most popular language, namely C#, Java and C++ became popular quite
> quickly.

But those languages had corporate backing. Haskell doesn't have corporate
backing, so shouldn't you compare it to languages that became popular and
didn't have corporate backing?

------
chuckcode
Personally I find selling excellence easiest without sweeping negative
generalizations like they claim in their summary slides[1]. Presentation feels
more like a blame game about how people have done things wrong in the past
than highlighting success and features of Haskell.

[1] From slide 152:

    
    
       - Old East Coast tech culture valued quality and
       correctness, weak on practicality and communication.
    
       - The new California-centric one emphasizes commercial practicality and communication 
       but doesn’t give a damn about software quality or excellence.

------
BrandonY
Reading the "How to Sell to Business" section convinced me as an engineer that
I should not focus on Haskell. If Haskell programmers are a better deal for
businesses because better programmers can be hired for less money, I should
logically choose to be a Java programmer for the same reason.

~~~
dasil003
The paradox is that if you are focused on how to make the most money to the
point that you are choosing your programming language based on estimated
market value, you are likely not the caliber of developer that the top-tier
tech companies are looking for. In other words, you can probably make $150k
under an insufferable pointy-hair at any Fortune 500 company, but you won't
get to work on cool stuff at Google or Facebook for $250k.

~~~
JamesBarney
If great engineers didn't care about money Facebook and Google wouldn't have
to pay them 250k :).

~~~
dasil003
Who said anything about not caring? It's about making technical decisions
based on money.

------
duncanawoods
That chart on slides 29-35 which claims you will be 600% more productive with
Haskell than C#/Java after 5 years...

Its just made up isn't it? This is part of the problem. If you try to convince
someone smart, experienced but skeptical by making things up, you hurt your
own case.

~~~
CamperBob2
Yeah, I like how he attacks the "false precision" of stack ranking and similar
business practices, in the midst of an entire presentation full of it.

------
cpeterso
Does the name "Brand X" on slide 29 refer to any specific language? Why add a
mysterious third line to the graph when the presentation's primary focus is
comparing the other two lines, Haskell and Java?

------
nowarninglabel
Good stuff, but doesn't Hack language also solve this need? I'd guess a more
likely route is PHP shops switching to Hack than to Haskell.

------
portlander52232
Michael, big fan of your work here. Can you talk a bit more about how to avoid
subordinating or dominating?

~~~
michaelochurch
My main point is to recognize that:

    
    
        (a) there are good business people out there,
        (b) the fact that they trust idiots on tech is our fault as much as theirs 
            (we get too arrogant or too submissive and fail to convince them),
        (c) we need to recognize that we and they have orthogonal skill sets
            and aren't *prima facie* smarter,
        (d) and this requires understanding certain cultural differences.
    

It's a long road, though. We're not a socially skilled tribe, for one.
Secondly, there _are_ a lot of terrible managers and business people in tech
(more than in other industries) due to the Damaso Effect.

~~~
solomatov
>(a) there are good business people out there

IMO, good business people are people who are doing good for their business not
using technology which their developers want them to use. They should consider
things such as: ability to find developers, availability of training and
books, availability well supported libraries, maturity of tools, code
maintainability, etc.

>(b) the fact that they trust idiots on tech is our fault as much as theirs
(we get too arrogant or too submissive and fail to convince them)

So, you are calling people who recommend to use technologies different from
Haskell idiots, right? Or at least you pointing at them in your presentation.
IMO, it's not the things which a professional should do. We have a lot of
opinions, and it should be ok to have a different opinion. We shouldn't bash
people who don't agree with us, otherwise, we will have (and I feel we already
have) haskell cult.

~~~
sheepmullet
"IMO, good business people are people who are doing good for their business
not using technology which their developers want them to use. They should
consider things such as: ability to find developers, availability of training
and books, availability well supported libraries, maturity of tools, code
maintainability, etc."

Business people should not be making tech decisions. Most good business people
don't know a damn thing about code maintainability etc and they shouldn't have
to.

------
octatoan
> KingdomLostException

Yeah.

------
pgrote
I still find it odd that Google Docs cannot handle a large number of people
looking at a file.

"Wow, this file is really popular! Some tools might be unavailable until the
crowd clears."

Even with the tools turned off there should be a way to simply view.

~~~
revelation
That's what it is saying? You can't use the tools, only view right now.

~~~
pgrote
There was no information loading at all when the link first appeared .. only
the warning.

