
On Marketing Haskell - azhenley
https://www.stephendiehl.com/posts/marketing.html
======
wirrbel
I am the person that would be the one most likely to adopt haskell in the
company I work in. Now, I don't and I won't even though I used it for several
pet projects and I would say have learned a lot of haskell and associated
patterns.

It's not that haskell doesn't have merits. However I feel like they are
oversold. While you can build programs that lack certain error classes, they
are not bug free and at the same time debugging often was a lot harder than in
other languages. The laziness is especially problematic in that regard.

Another problem is cultural. Haskell and Scala community have been the most
hostile communities I have experienced. And the friendliness of communities is
a sure predictor for growth.

Another important problem is the docs. For some reasons they hardly contain
examples. You don't get adoption that way. Even if the maintainers feel that
the type signatures are documentation enough.

And as a last remark, the combinatoric complexity of compiler flags is a
problem and needs to be fixed. But the ecosystem is in a deadlock there that
no compromise could be found on what should be in the language and what
shouldn't be. And it kind of indicates a deeper problem in the haskell design
process.

~~~
jbreckmckye
I was a Haskell developer in my last gig. I entered that job determined to
make a success of it, because I was excited about the language and felt I
wanted to "prove" that it had value in a "boring" domain like financial
services. But I was stymied at every opportunity by Haskell itself.

My biggest complaints are 1) the lack of good libraries, and 2) the apalling
state of documentation for the few that exist. Too many Haskell projects read
like "I figured out this neat family of types for thinking about X - at last
URL parsing is provably safe - now you figure out the rest".

Let's take a practical example: HTTP requests. If I'm a budding JavaScript
developer, or Kotlin developer, or Python developer, I can read through
copious search results and tutorials on Axios / OkHttp / Requests / delete as
appropriate. These tutorials not only walk me through the common use cases but
also show me their APIs in the context of the new and alien syntax of the
language I'm grappling with. They give me enough template code that I can use
an incomplete understanding of whatever language it is I'm learning to figure
out the rest without recourse to a textbook.

What does Haskell have? It has Req (and a bunch of other also rans), and the
docs for Req are atrocious, spanning a staggering 1 (one) example and then a
meandering essay on the deficiency of other Haskell HTTP clients. It's not
good enough.

And that's my assessment of Haskell as a whole - not the language
individually, which is expressive and powerful and inspired - but the whole
ecosystem around Haskell that feels like a set of beta projects and hobby
repositories generally developed by interested individuals rather than
commercial endeavours.

Or look at the paltry state of IDE support. It's 2020 and the best option we
have is VSCode with HIE, which rapidly spirals out of control allocating
memory, randomly crashes and on Windows just refuses to even start half the
time. Without this tooling a lot of the theoretical benefit of the type system
is being lost. This is low hanging fruit but there's been no incentive to pick
it.

And so I've made the difficult decision to leave Haskell behind. If you need
typed functional programming, your options are OCaml, Scala, F# or even
subsets of Rust and TypeScript. Haskell is a great learning experience but
totally unproductive right now.

~~~
_bxg1
I think one of the most underrated aspects of Rust is its stellar
documentation, tooling, community, high-level libraries and general
accessibility. The language itself isn't easy per se, but 100% of the
difficulty is intrinsic; none of it is incidental. In many ways it's "the
practical Haskell", _even though_ it's technically lower-level.

~~~
dragonsh
This is the most under appreciated feature of Python and Ruby. They got it
right and other languages are still trying to catch up. Rust offers nothing
better except memory safety at the expense of ease of use and with steep
learning curve. Indeed same can be achieved by C, if one replace the
complicated syntax and steep learning curve with better testing to check for
memory safety. Zig language shows that it is possible to provide a simple way
to write both memory safe or unsafe code.

Well begin is half done, and Python and Ruby made it so easy to program that
without reading multiple of books and spending a year or two, programmers can
write decent code. This is the reason why Go and Swift the other two system
programming language is far ahead of Rust despite being GC language. Indeed
even the latest OS Fuschia is written in C++ (zircon kernel), with Rust SDK to
write high level programs same as the one written with Dart and flutter.

~~~
ghostwriter
> Zig language shows that it is possible to provide a simple way to write both
> memory safe or unsafe code.

Zig is a kind of language that wouldn't have been written if its author
discovered ATS[1] at a right time.

[1]: [http://www.ats-lang.org](http://www.ats-lang.org)

~~~
AndyKelley
i was aware of ats before creating zig

------
kace91
Although I think the post is very clear describing the reasons why Haskell
isn't attractive in business, this part rubbed me the wrong way:

> Thus, instead of our discourse being about semantics, engineering quality,
> and implementation, we instead discuss our tools in terms of social factors
> and emotions (i.e. it “feels readable”, “feels usable”, “feels fast”).

Thinking about readability or usability as emotions and social factors, rather
than as first level concerns, is a non starter to me, and I find it extremely
off putting that the author seems to pile up those qualities in the marketing
"group", as if they were not real properties of a language.

You can design a drill in a way that makes it the most scientifically correct
at using the power it's supplied efficiently, but if the design hurts the
users hands and requires months of training to operate, any worker will throw
it in the trash, because they can drill things just fine with a regular tool.

(I'm not necessarily saying that Haskell is that drill, just saying that
usability should never be treated with condescension when you're designing
tools).

~~~
rfergie
I took his point to be that things like "feels readable" and "feels fast" and
to do with _feelings_ rather than actual quantifiable things that could
reasonably be compared between languages.

So it isn't that those things aren't important; just that they are subjective

~~~
kace91
I'd argue that ease of use and readability are perfectly quantifiable - there
are thousands of people whose job is precisely optimising usability for many
products. Sure, dealing with people is harder and less clear cut than
measuring cycles in a processor - there's a lot of variability, context based
on previous experience, etc. But that's no reason to ignore the human factor
of programming and gather some metrics/statistics, then seeing where you can
improve.

What those features are, rather than subjective, it's contextual, and I feel
that behind the author's phrase might lie the usual complain by functional
programmers that non-functional languages just feel foreign because people are
usually taught other styles during their learning process.

As an explanation, that might be partly true, but it being true doesn't really
save you from the fact that if you want people to use your tool, you have to
make it easily usable, and usable for real world people rather than for
spherical cows.

~~~
clarry
> I'd argue that ease of use and readability are perfectly quantifiable

Do we have any objective metrics? The only thing I can think of is all the
(inconclusive) studies about error density. Unfortunately error density is a
very far cry from measuring the overall quality of a software product, or the
mental effort that was required to produce it, or the mental effort required
to maintain it.

> there are thousands of people whose job is precisely optimising usability
> for many products

Yeah but programming languages are more abstract; they're tools of thought
(just like mathematical objects), and optimizing their use is nothing like
observing a user press the buttons on a machine to get themselves a cup of
coffee.

Controlled studies are very difficult to run, for obvious reasons. (Unlike for
the coffee machine)

------
spekcular
We dance around this issue in the comments to every Haskell story, but the
reason Haskell is hard to market is that it's bad. It's a research language
being shoehorned into production by a few people who really love it. Some
details of this have been given in this thread; let me suggest the following
threads for more:

1)
[https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocam...](https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocamlers_critiques_of_haskell/cugohyn/)
2)
[https://www.reddit.com/r/ocaml/comments/e7g4nb/haskell_vs_oc...](https://www.reddit.com/r/ocaml/comments/e7g4nb/haskell_vs_ocaml/fa4bnsw/)

Yes, the Haskell community hates that guy and considers him a troll. But he
does functional programming professionally as part of a private consultancy
and wrote a book on OCaml. If anyone's equipped to understand what's wrong
with Haskell, it's him.

Haskell has had 30 years to get its act together. Any benefits it has are
drowned out by a sea of buggy tooling and accidental complexity (monads,
etc.).

Ask yourself this: if there are literally billions of dollars in industry
riding on writing efficient and correct software, and Haskell is such an
obvious productivity win, why does it have a market share that rounds to zero?

Time to move on.

~~~
somewhereoutth
Following links in your 1), I liked
[https://www.cs.hmc.edu/~oneill/papers/Sieve-
JFP.pdf](https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf) 'The Genuine
Sieve of Eratosthenes' by Melissa E. O’Neill. Somewhat damning and to your
point.

Are there any theoretical barriers to writing algorithms in a pure and lazy
language with the same space/time complexity as a side-effectful and strict
language? I suppose quicksort (also mentioned) is an obvious candidate for
study in this regard.

~~~
spekcular
There's also hash tables. IIRC, Haskell didn't have a good hash table
implementation until relatively recently because people religiously avoided
mutable data structures. (And the implementation I'm thinking of is _not_
purely functional.)

~~~
centimeter
Haskell has had good HAMTs for quite some time. There isn’t really any benefit
to using a mutable hash table over that. In fact, it would probably be slower
given the way copying GC works with mutable values.

~~~
spekcular
Yes, there is a benefit: correctly implemented hash tables are faster.
Haskell's GC may prevent a good implementation, but that's a problem with
Haskell, not with hash tables.

~~~
yakshaving_jgt
Writing the fastest possible implementation of something is rarely a valid
business goal.

The ideal is the midpoint on a Venn diagram of 1) fast enough for our
purposes, 2) logically robust, 3) cheap to implement.

Besides, if something absolutely _must_ be the fastest implementation possible
and this can’t be done in Haskell, then there’s no reason why one couldn’t
drop to the FFI at that point. You could even use template Haskell and write
inline-C. It works.

------
centimeter
With respect to availability of talent pool: my alma mater used to teach
Haskell as the introductory programming language, and from what I’ve heard
from people who were around then it was great for faculty and students.
However, a very large corporate donor pressured the university to switch to
Java in the early 2000s, because that’s what they used internally and they
wanted a large local supply of pre-trained fungible labor. Now only a small
fraction of the top students who study advanced topics in PL or compilers or
what-have-you will come out of the university knowing how to use Haskell. I
think this is deeply unfortunate - if society could quantum tunnel through to
the point where Haskell was the safe, readily hireable corporate choice, the
state of software (especially corporate software) would be a lot better off.

~~~
gowld
I don’t get it. What does removing Haskell from the into course have to do
with the use of Haskell in the PL or compilers class?

~~~
mumblemumble
If it's anything like what happened at my alma mater, they may well have
switched to Java for _everything_.

It's really a disservice to students. Developing competence in a variety of
programming paradigms is a career-expanding experience. It makes picking up a
new language - and, by extension, a new technology stack - a quick and easy
thing to do, because there will be very few ways of doing things that you
haven't seen before. Which, in turn, makes it a lot more feasible to pivot
your career or act quickly when an opportunity arrives.

A bunch of students who know only Java, on the other hand, is exactly what big
corporate employers want. For employers, it maximizes the interchangeability
of employees. For employees, it minimizes the interchangeability of employers.

~~~
zabzonk
> at my alma mater

Where would that be? Why is everyone here avoiding being specific? If you are
not specific, why should we believe in what you say?

~~~
a1369209993
Probably for the same reason their username is "mumblemumble" rather than "Ted
Anderson from New York". This isn't Facebook; don't ask people to dox
themselves.

If you want people to name and shame, ask for a list of offending
institutions, not individual examples. (Also, fact-check that list, rather
than blindly accepting accusations made by internet randoms, but that should
go without saying.)

~~~
zabzonk
I didn't ask about their real name, I asked about the college they were
talking about, which hardly exposes them to doxing.

~~~
pgcj_poster
The more information attached to your account, the closer it gets to revealing
your true identity.

------
dmix
One of the best ways to get adoption is to have people take initial risks and
build real world serious product with a serious team/company backing behind
it.

Erlang got a big boost when it came out WhatsApp scaled it up with a billion
users, with tiny team and only a few servers.

React/React Native got boosted by Instagram adopting it to build their
production mobile app.

Rails had 37signals/Basecamp and Github/Shopify/early Twitter/etc.

Haskell needs some more famous commercial "killer-app" examples for real
businesses and real teams. And yes I'm very familiar with the current
selection of popular Haskell examples.

Currently I only ever hear Haskell (and Ocaml for that matter) being used by
engineers for backend engineery things (parsing programming languages,
fighting spam, tooling) mostly for OSS tools.

On a positive note, PureScript is trying to position itself as a practical
Haskell and making a bit of success. One helpful reason is they have a nice
app/company leading the way as a production app with Lumi [1], with their
founder playing a key role on the language/ecosystem dev side as well:
[https://www.lumi.dev/blog/purescript-and-haskell-at-
lumi](https://www.lumi.dev/blog/purescript-and-haskell-at-lumi)

This is what Haskell needs more of - and critical a company promoting/blogging
about their progress using Haskell as well as contributing back into the
community.

Another big one is simply a sort of 'starter kit' which guides you with best
practices on how to architect a serious Haskell app (ie, using STM, free,
etc). React has plenty of starter kits. For Rust CLI apps there is a great
starter kit
[https://github.com/iqlusioninc/abscissa](https://github.com/iqlusioninc/abscissa)

I'd love to see a similar starting point micro-framework for starting a new
Haskell app that makes a bunch of importation decisions for you and guides the
structure of the project.

~~~
narrationbox
There is Hasura, they are probably the most famous commercial Haskell app
right now (in terms of brand recognition).

[https://hasura.io](https://hasura.io)

~~~
dmix
That fits into the tooling category but it is a serious company.

I found one blog post mentioning Haskell but without much technical details:

[https://hasura.io/blog/from-zero-to-hipster-haskell-in-
produ...](https://hasura.io/blog/from-zero-to-hipster-haskell-in-
production-97ea99d90c3b/)

I hope they write more..

------
moreaccountspls
Anyone using Haskell to drive their business is making a huge mistake in my
experience. Haskell2010 is a fine language. Unfortunately, the ecosystem has
centered around whatever the latest version of GHC is, with its millions of
language extensions and breaking the world with changes like
[https://gitlab.haskell.org/ghc/ghc/issues/10365](https://gitlab.haskell.org/ghc/ghc/issues/10365)
and [https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-
of...](https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of-no-
return). Which is fine if you're doing research or building tools for fun! But
it makes an absolutely awful industrial experience when you want to ship
features and not get stuck on a bit rotted version of GHC.

edit: It's unfortunate that people are downvoting me for offering my
experience, especially on a post that wants to make Haskell more attractive to
being used in the industry.

~~~
platz
these issues probably did not cause a lot of problems for production software

~~~
moreaccountspls
Huh? My whole comment is about the fact that they DID cause a lot of problems
for production software. The company wrote their flagship product in Haskell,
and there is a pretty large chance that that decision will doom them because
of the choice to use Haskell. It's unfortunate because the product has a great
market fit. If they had choose pretty much any other tech stack, they would be
killing it.

~~~
codygman
I recall refractors from those proposal being very mechanical and easy to
automate.

Maybe my memory is fuzzy... But if not can you give an example where that
wasn't the case?

~~~
moreaccountspls
Yes. An example was moving to the version of GHC where the semigroup change
happened. The codebase was using this library:
[https://github.com/brendanhay/gogol](https://github.com/brendanhay/gogol).
The library dropped support for one version of Google's API for another
version. Fair enough, except the old version would no longer work because of
the semigroup change. So I ended up having to waste a ton of time completely
changing on how we were using a library to satisfy the semigroup change.

Again, this is the problem. The ecosystem tends to only aim at GHC latest
because of the attitude that "its mechanical to change!". Yeah, for the code
you write maybe, but if the dependencies have that attitude, all of sudden
upgrades can be a huge effort.

~~~
dllthomas
That seems like a problem with gogol dropping support for relevant features,
rather than with the semigroup change in particular. If you didn't want to
keep up to date with the library more generally, the semigroup change in
isolation could have been dealt with by forking the library in question.

Which isn't to say this isn't still indicative of friction in the Haskell
ecosystem when it comes to building a large system for production.

------
cs702
The idea of "marketing Haskell" to me is akin to marketing math and
mathematical notation. Yes, Haskell is elegant. Yes, it is powerful. Yes, it
is succinct. Yes, the benefits of its algebraic type system are many and very
real -- if your code compiles, it is correct in many important ways. No one
can argue with any of that.

But... most people who look into Haskell lose steam as soon as they realize
they actually must _understand_ and _be able to reason about_ functors,
applicative functors, monoids, monads, and (god forbid) lens-things like
prisms, traversals, isos, etc. to do anything useful. It's a shame.

~~~
6gvONxR4sf7o
The sad thing is nobody ever makes that complaint when talking about
everything you'd need to know to build a bridge, or to place an IV, or even to
build a table. There's a huge part of the software community that's self
taught, but also a gigantic part with degrees in computer science. If there
was enough value in these ideas _and_ critical mass of wide adoption, we could
just add it to the curriculum, and it'd just be yet another of those things
you need to learn to get into the software industry.

~~~
moreaccountspls
>The sad thing is nobody ever makes that complaint when talking about
everything you'd need to know to build a bridge

If we're talking about the software engineering equivalent of bridges, I think
it would be much more valuable add TLA+ or similar to the curriculum.

~~~
pwm
Why not both? They are not mutually exclusive and they both would advance the
status quo.

~~~
moreaccountspls
If there was unlimited time, sure.

~~~
pwm
OP was complaining about having to understand Functors, Monoids, etc... like
they are nuisances in the way of writing real code. In response 6gvONxR4sf7o
and I were saying that programmers really ought to be taught these incredibly
useful abstractions. After more than a decade of coding professionally in
popular languages and then 4 years of writing Haskell I cannot begin to tell
you how amazing it is that we have these abstractions to rely on. There are
virtually endless data types out there and instead of having to study each and
every one of them I can just look at whether something is a Monoid and
immediately know that I can append them and there is a unit. I can look at
whether something is a Functor and immediately know that I can map any
function over it. I only need to know a few of these generic patterns and
"magically" I can write functions that operate on any of the countless data
structures out there. This is true code reuse. Not teaching these to future
programmers, not exploiting the timeless, powerful knowledge behind these is
in my opinion a disservice to them.

~~~
moreaccountspls
I've been writing Haskell for 12 years so I'm aware of the abstractions it
offers. At the end of the day though, either we're building a bridge or we're
not.

If we're building a bridge (i.e. a distributed database, a real time system,
fly by wire system, etc.) Haskell is useless if for no other reason than how
it does memory allocation.

Dependent types are also a dead end for building bridges in my opinion.
Proving any non trivial invariants is basically impossible in the real world
([http://web.archive.org/web/20200113205635/http://blog.parall...](http://web.archive.org/web/20200113205635/http://blog.paralleluniverse.co/2016/07/23/correctness-
and-complexity/)).

And even if it wasn't, dependent types are for a program. But our "bridges"
aren't programs, they're systems! If there's one thing that the Haskell
community don't understand, it's that. The scary issues that crop up in large
scale distributed systems aren't from the nodes, they're from the edges. So
any system of correctness that is focused on the nodes [i.e. type systems] is
avoiding the real issue.

That's the power of TLA+ by the way. By modeling the system, you have a
specification that gives you some confidence what you're building is correct
before beginning to implement your bridge.

And if we're not building a bridge? The business doesn't really care about
correctness, they care about shipping features. Rollbacks are an acceptable
cost. Our job is to sit down and bang out a solution to the problem at hand,
not build the perfect abstraction to the problem. When we use languages like
Haskell, we take that power out of product's hands.

~~~
pwm
At work we're building a novel DSL and its ecosystem for a specific industry.
Not sure if you consider that a bridge or not, the naive part of me likes to
think it's akin to one but maybe i'm deluding myself. Of course we could use
any language under the sun but imho Haskell is a really great fit for this
project. It also helped hiring some truly great talent (I'm the hiring manager
for this team so I know first hand). I don't have much experience with TLA+.
From the little I know and learnt about it over the years I think it's
brilliant which is why i agreed it should be taught and used more. For the
record I've also been involved in multiple large-scale micro-service-obsessed
projects in the past, none of them used Haskell or TLA+ and they all were a
terrible mess of hidden entangled complexity. Not sure if there's any takeaway
just an anecdote.

------
solatic
> The bottom line is that rather than using more correct tools and engineering
> practices, it is simply far easier and more economical to hedge software
> risk with non-technical approaches. Moreover, if you throw enough bodies
> writing Java at a project for a long-enough period of time, it will produce
> a result or fail with a fairly predictable set of cashflows, which is itself
> a low quantifiable risk that’s very easy for a business to plan for.

This is a very MBA-like lens through which to examine software development.
It's not wrong, but it's also a recipe for mediocrity, which is a great way to
damage your culture and sit around wondering why you can never get ahead of
your competition.

The deeper question is why is software quality only loosely correlated, if at
all, with business outcomes?

The pessimists will point to Equifax et. al. and tell you that the market
simply doesn't care, that businesses can go through downtime after leak after
catastrophic failure and their stock will never take a hit. And there's some
truth to that. The end consumer actually doesn't really care about the bad
news. There's not much that any company in the business can do about that.

But the optimist understands that great engineering will _leapfrog_
competitors and leave them in the dust. The value of correctness isn't in the
two months after you begin, it's in the two months after your latest release
five years from now. It requires vision, patience, already-available human
capital, and leadership to realize the benefits.

> If the talent pool is illiquid or geographically locked, that’s a non-
> starter. If there isn’t a large corporate vendor to go to to sign up for a
> support contract, then that’s a non-starter. If there isn’t a party to sue
> as an insurance policy against failure, then that’s a non-starter.

If you give your talent the opportunity to work on a Haskell project and
they're walking out the door when it's difficult to find Haskell work to begin
with, then you, the manager, failed in deciding which talent to hire. If
you're looking for a support contract to hedge against the loss of in-house
talent, then you've already failed. If you think that legal solutions will
protect you against market failure, then you've already failed. Haskell isn't
trying to market to these people in the first place, why should it start?

~~~
WJW
> but it's also a recipe for mediocrity

This is framed as a downside, but to be mediocre it can't be so bad it doesn't
work at all. Most software that is great from a technical standpoint is made
by a relatively small team, which translates into a relatively large risk for
the business since it compresses all the volatility into retaining that team
or not. With average tenure in tech around two years, you can see how that is
not an attractive proposition for most companies. If all the competition is
also (at best) mediocre, you can simply try to compete on other (nontechnical)
fields like marketing or customer support.

There is a secondary level of incentives that is present in most larger
companies: delivering a fantastic product will make the owners rich and the
people involved will maybe get a raise. Delivering a spectacularly failed
project ends your chances of career advancement. This really diminishes the
appetite for taking technical risk amongst decision makers. Mediocre is often
good enough.

~~~
marcosdumay
> delivering a fantastic product will make the owners rich and the people
> involved will maybe get a raise. Delivering a spectacularly failed project
> ends your chances of career advancement.

Aren't ~90% of the software projects failures?

Mediocre software is failure. There is no upside to avoiding all risks.

~~~
WJW
Of course there is upside in avoiding all risks, as long as you are happy with
the status quo. I understand if you personally are not happy with it, but we
just have to look around to see conservative people everywhere.

------
awinter-py
tagged in on a client project written in haskell

codebase organization was nonintuitive and I blame type-level programming

compilation was so slow and bad that other programs on my laptop started to
die

the feature I was adding was something that would be library-provided in a
normal web language

none of the operators have names and are very hard to google; I had to search
for things like 'haskell tilde asterisk arrow'. Impossible to know what's from
libs vs core language. Lots of explanatory docs online were like 'oh we don't
pronounce this one'.

Core abstractions have no definition ('to explain that I would have to explain
monads but you won't understand monads so GFY'). Monads are just sub rosa
dependency injection .

lang doesn't protect you from runtime crashes but _does_ apparently protect
you from knowing where the program crashed

~~~
fphilipe
Haven’t written any serious Haskell, but doesn’t Hoogle work for searching
infix operators?

One thing I really like about Haskell is Hoogle. The ability to search by
function signature is great. I often wish I could do that in other languages.

~~~
awinter-py
searched `->` got

(->-) :: Bind m => (a -> m b) -> (b -> m c) -> a -> m c

semigroupoids Data.Functor.Bind

~~~
mrkeen
Fair enough. `->` is core syntax, not a library function. It means `->` if
you're a Java guy or `=>` if you're a Scala guy.

Just search for it the same as you'd search for it in Java or Scala.

~~~
awinter-py
I'm open to the argument that my imperative / scripting background in some way
primes me to learn rails but makes it hard for me to navigate a haskell
codebase, and that this is human difference rather than one language being
inherently more navigable than the other

------
rockmeamedee
This is a very lucid piece on PL adoption in general. When I think about
programming languages, I do think rather emotionally (which is fine, emotions
are early warning systems).

I liked the linked author's points about the pre-requisites for marketing a
solution:

    
    
        It is memorable
        It includes a key benefit
        It differentiates
        It imparts positivity
    

When I think about the most popular languages, they do have all of these:
Rust:

Memorable: very. It's basically everywhere you look Has a key benefit: going
C++ fast without the C++ footguns, memory-safe, WASM integration
Differentiates: Using Rust is definitely choosing a particular set of
technical tradeoffs Imparts positivity: the community is known to be
welcoming, feels cool, cute crab. People re-write existing software in Rust
just because it feels good!

Yet Haskell has almost none of these:

Memorable: I mean, yeah, but it's not being shown to people, and I can't point
to a bunch of software. Tools I know of include PostgREST, Hasura, Nix,
hledger, which is better than nothing. Key benefit: Hand waving about "being
more correct", unlike Rust which has reams of "Microsoft claims 60% of its
bugs are memory-errors" articles, and in any case TFA's point is that this
needs to be a different message because correctness isn't gonna sell it.
Differentiates: This is definitely true, almost too much Imparts positivity:
Not really feeling this one with Haskell. People feel good when they figure
out a monad is a container & a lens is a path through a data structure, but
attempts to explain to others these things feel condescending. Does Haskell
even have an animal mascot? (serious question.) Also "stumps" a lot of people
and people feel bad about it. There's no "import antigravity" equivalent
feeling with Haskell.

This sounds pretty sombre for Haskell, though it's been an academic language a
long time, and could probably stay alive that way.

One positioning possibility is maybe with the Frontend dev world becoming more
and more functional and pure-oriented, positioning itself like reasonML, as a
way to write and reason about declarative pure UIs. But I don't think the
existing Haskell community cares too much about that world.

Idk, I'm going to just keep writing Rust and JS, the already most loved and
popular languages.

------
6gvONxR4sf7o
I love haskell. What I love about it is the type system and pureness. In
python, I loathe refactoring because of how fragile it often is. I hate
finding out that I misunderstood what to even pass a function. I want the what
haskell brings to those issues. I hate how hard haskell is to debug and how
incredibly hard performance is to reason about. I want what python (or another
imperative language) brings to those issues. I wonder if haskell had been
strict by default rather than lazy by default, if its adoption would be
different today.

There are certainly pieces of haskell that would make all our lives easier,
and I can't wait for them to make their way into mainstream industry work one
way or another.

~~~
crazypython
-XStrict?

~~~
6gvONxR4sf7o
It's easy to write strict code in haskell, but the default behavior affects
community norms, and what's considered standard and idiomatic. That's where I
think the evolution could have been different.

~~~
massysett
Haskell would never have been strict by default, because the entire point of
Haskell was to be a common basis for research into non-strict languages. Non-
strictness is simply the core of what Haskell is.

------
weinzierl
The author of the article has an interesting contact page:

 _" To contact me via email run one of the following scripts to generate my
contact information. I find this is an effective filter against the deluge of
emails from recruiters."_

The "scripts" are offered in Haskell, x86-64 Assembly and Python. Solution is
pretty obvious though, no need to run them actually.

~~~
Tade0
_Recruiters who do contact me will be named and shamed publicly._

I would applaud any recruiter who went through all that trouble just to
contact a person, regardless of my interest in their offer.

------
jeffdavis
"The hard economic truth for engineers is that technical excellence is
overwhelmingly irrelevant"

No. Technical excellence matters a lot when used appropriately, but competing
with javascript and python is not where haskell is going to win.

There IS a language with HUGE success that is: declarative, strongly typed
with type inference, lazy, and no side effects. It's called SQL[1].

That's where Haskell could shine -- compared with SQL. Imagine Maybe rather
than NULLs, a sane language, multiple returns, a much better type system, etc.
Python and Java can't touch SQL, but haskell could.

[1] [http://thoughts.davisjeff.com/2011/09/25/sql-the-
successful-...](http://thoughts.davisjeff.com/2011/09/25/sql-the-successful-
cousin-of-haskell/)

~~~
dllthomas
SQL does not have type inference. It's dynamically typed, and will break at
runtime if you feed the wrong type into something. It probably _is_ strongly
typed, depending where you draw that line.

It also sometimes has side effects, although that's more dialect specific than
present in the standard I think (when it comes to DML).

~~~
jeffdavis
I'm sure there are some counterexamples, but for the most part most SQL
implementations will fail to compile a query if you try to add a string to an
integer or take the average of a date column. So I'm not quite sure what you
mean.

And type inference also plays a role with CASE statements, UNION, etc. Again
may depend on SQL implementation.

~~~
dllthomas
Hmm, I'm not sure of the details, but I very much remember encountering type
errors based on what data path was taken. Playing around now I think the
typical case is more as you described. I might revisit when I'm better rested.

------
sjakobi
Discussion on r/haskell:
[https://www.reddit.com/r/haskell/comments/gtm3w0/on_marketin...](https://www.reddit.com/r/haskell/comments/gtm3w0/on_marketing_haskell/)

------
pron
Ask any marketer — it's (almost) _never_ the marketing. Or, rather, it's never
the marketing of the "hype and subterfuge" kind. No product dominates the
market for decades due to hype and subterfuge, let alone hype and subterfuge
deployed decades earlier. It's always the product. It's just that what matters
about the product to most people is often not what matters to some minority
that insists that “technical excellence” is defined by their own preferences.
In the famous VHS vs. Betamax war, the technically superior product won, it’s
just that it was superior in matters that appealed to many and inferior in
matters that appealed to few. The few famous cases where it _was_ the
marketing (diamond rings, maybe?) stick in our mind because they're the
exception, not the rule. Blaming marketing problems is often an excuse to
overlook product problems.

Second, the problem with the message of "code written in Haskell is more
correct than code written in other [more popular] languages," isn't that the
industry doesn't care about correctness. Correctness translates to cost (to a
degree), and the ability to write software as correct as it needs to be more
cheaply is actually quite compelling. Rather, the problem with it is that it's
simply not true (or, rather, hasn't been shown to be true), certainly not to
any degree big enough to matter. That, in and of itself, does not make it a
_terrible_ message; after all it's just harmless hype, right? What makes it a
terrible message is that it is _very clearly_ not (shown to be) true and yet
some Haskellers seem to actually believe it, drunk on their own kool-aid,
which makes you think of them as out of touch with reality. At best, it's an
emotion (it "feels" more correct), which you've mocked, rather than any sort
of "critical thinking," that you present as the desirable standard.

Third, the mistake in the perception of the economics of software is not the
importance of correctness — that can have an easily measurable impact. It's in
the importance of code. Programmers in general, but Haskellers in particular,
are obsessed with code. As a result, they grossly overestimate its importance
to software. Ask yourself how long it takes you to produce, say, 1000 lines of
code of sufficient quality, and then look at a software produced at your
company and divide the size of the codebase by the number you came up with.
You'll find that the true cost is several times that. The "pure" cost of
producing code is not where most of the cost of developing software is. Maybe
it's in what you mockingly call "emotions", but it certainly isn't in
programming-language semantics. Also, before presenting managers' priorities,
it's better to actually speak to actual managers; they just might have some
useful insight here, plus, it's what a culture of technical excellence
demands, no?

All of that means that unless your language has some clear and direct effect
on the bottom line — which, these days, usually means it has good performance
and/or observability, a good ecosystem, or a monopoly of sorts on some
distribution platform -- there is no "message" that can make it popular, other
than "it's easy and it's fun." While perhaps not a sufficient requirement for
success, this can create a supply of qualified developers that at least won't
put your language at a _disadvantage_.

And here's another tip: if your retrospective introspection isn't painful,
doesn't discuss _any_ serious and conspicuous flaws with the product, and
still paints you as being somehow right after all and everyone else as being
somehow wrong — it's probably not true. Worse, it _seems_ untrue. And not
calling your own practice one of "engineering excellence" and others' as
"throwing enough bodies" can't hurt, either. In other words, I don't know what
a good marketing message for Haskell would be, but this post is a good example
of a bad one.

~~~
CyberDildonics
> All of that means that unless your language has some clear and direct effect
> on the bottom line — which, these days, usually means it has good
> performance and/or observability, a good ecosystem, or a monopoly of sorts
> on some distribution platform -- there is no "message" that can make it
> popular, other than "it's easy and it's fun." While perhaps not a sufficient
> requirement for success, this can create a supply of qualified developers
> that at least won't put your language at a disadvantage.

I think this approaches the heart of the problem. Whatever the advantages of
haskell may be, the disadvantages run extremely deep. Haskell is notoriously
difficult to debug and optimize (both memory and cpu usage). It is interesting
and influential, but trying to abstract away the order of operations as a core
of the language just didn't pan out. All of that is before issues of IDEs,
libraries, compilation times etc. It has been around for 30 years, at some
point it needs to be called a worthwhile experiment so people can move on from
clenching their fists that no one else is as clever as they are.

The more I think about it, my ideal language would be the exact opposite.
Something extremely clear and straight forward with minimal complexity and
maximum infrastructure.

~~~
pron
> The more I think about it, my ideal language would be the exact opposite.
> Something extremely clear and straight forward with minimal complexity and
> maximum infrastructure.

I completely agree. That's why I like Java for high-level (but large-scale)
programming, and interested in Zig for low-level.

------
mhh__
This is a slightly loaded question, but is a Haskell codebase harder to work
on than one in a reasonable non-functional language?

Maybe it's because the bugs are generally less common and easier to fix, but
when I look at Haskell codebases it seems like it's quite difficult to achieve
the same level of "separation" one would in (say) Java - i.e. an average
Haskell file seems to purely consist of many loose free functions (often with
very short names!).

I might be missing the point but the aforementioned always pushed me away from
Haskell - great language, but seems to have legibility as an afterthought (as
opposed to python, which is an awful language, does manage to enforce some
sort of legible coding style)

~~~
chrischen
I’d suspect the difficulty comes from the paradigm shift.

I’ve personally switch code to functional style and it has simplified and
reduced code for me. Granted if you don’t know how monads work it could be
very confusing.

~~~
mhh__
I'm a bit rusty but I do understand the type and category theory behind
Haskell. I don't find it confusing, just sort of suboptimal a la C++ template
syntax

~~~
mrkeen
How could it be tweaked to make it better?

~~~
mhh__
What D does. Angle brackets make instantiations harder to parse. Also the
template keyword is pointless

------
phreack
What about tooling? Haskell being such a powerful language would take off a
lot more if there was a very hand-holding, Jetbrains-like IDE that gave you
everything you needed and pointed out the problems in your code in real time.
Or at least that's what I think, having never worked with haskell in a
professional capacity. What are some day to day devtool stacks like in real
companies?

~~~
ghostwriter
[http://rikvdkleij.github.io/intellij-
haskell/](http://rikvdkleij.github.io/intellij-haskell/) it's been around for
a while already

------
tinco
I made the decision to stop using Haskell for things I consider "professional"
use a couple years ago. No matter how much I love the idea of the language,
there's a couple superficial things it gets wrong and one fundamental thing,
or at least I believe it's fundamental, perhaps some academics have proof one
way or the other.

The superficial things are things that are not really part of the language,
but more of its standard library, part of the 'prelude', or things the
community has agreed upon:

    
    
      - the I/O monad (and others) can throw errors
      - prelude is full of bad practice like use of strings and linked lists
      - there's something wrong with how function names can't be namespaced
    

There's more than this, and they're not just things I came up with, they've
been fought over in the community at length. Other preludes exist, I/O
libraries that don't throw errors, even whole different systems for doing I/O
exist. It's not that solutions are hard or impossible, they're there, it's
just that the way the language is managed it's not likely that they'd ever be
applied in a way the entire community, and especially those drawn to it by any
marketing would experience them.

Maybe I'm making a fool of myself and things changed in the past couple of
years, things were really developing at a rapid pace when I left, but it
seemed all the improvements happened around haskell, not to the language
itself. When Stack and LTS-Haskell emerged it was the most amazing thing that
I saw happening to Haskell in like 10 years, but given the lackluster response
Snoyman received from the core team it seemed like they didn't even realize it
even though the entire community had like an upheaval.

In my opinion, Haskell's marketing is fine. It's being marketed to every
college student anywhere that goes to a good enough university that it teaches
functional programming. In addition to that there's raving fans (myself
included) that extoll its virtues to anyone who would hear. What it needs is a
better retention rate. It needs that people who learn it, immediately realise
it's fit for production use, that it's not just a fun experiment and a
educative way of looking at things. For that we need something like a Haskell
2.0, designed by the community to incorporate everything we learned about
Haskell's flaws and make it an absolute powerhouse of productivity. Maybe
Haskell should be split into two flavors, one the teaching language with the
linked lists, strings and funny pattern matching, and one that's got a prelude
that will set you up with the perfect base to build the next compiler,
database, service or web application.

If all those smart people who learn Haskell and tinker with for a bit,
actually stayed around and used it to build awesome stuff, Haskell would truly
have an enormous foot print on the world.

(not really relevant but the fundamental thing is that Haskell's performance
is really hard to predict, this is true for many garbage collected languages,
but for Haskell it seems to be extra bad because of the way its paradigm just
doesn't map 1:1 to how computers are built)

~~~
edjrage
> we need something like a Haskell 2.0, designed by the community to
> incorporate everything we learned about Haskell's flaws and make it an
> absolute powerhouse of productivity

How about PureScript?

------
ashtonkem
Marketing Haskell as an industry language is starting to feel a bit like a
forlorn hope. After 30 years of getting passed by a variety of new languages
that are supposedly inferior, hoping that Haskell will make industrial in-
roads seems a bit silly to me.

I mean, try if you want to. It's no skin off my back. But it doesn't seem like
it'll work.

------
xixixao
Javascript is not popular because it has Java in the name name...

~~~
AnimalMuppet
But it was a big initial boost for it. "ECMAScript" didn't have the same
marketability, and Java was being publicized and becoming popular, so they
renamed it to JavaScript.

~~~
skybrian
That's wrong on the history. Netscape called the language "LiveScript" before
changing it to "JavaScript". Then Microsoft called it "JScript." Then the
"ECMAScript" name was chosen as a compromise.

Using different names for the same language didn't change anything
fundamental. It was built into the browser, so if you wanted to write code in
the browser you didn't have a choice.

