Emphasize "Why Haskell?" on haskell.org landing page

1

To grow the overall Haskell user base a common suggestion was to clearly answer the question “Why should i choose Haskell (over all the other programming languages i could use)?”

See e.g. @sinicholls post @ktf post, @jazzlobster post, many thanks for your input.)

To me this looks like an important low-hanging fruit to fix on the https://haskell.org landing page.
I suggest to focus on the business/developer benefits in headlines and descriptions, and to reduce technical jargon such that decision makers and developers from other programming languages understand the points easily. Specifically,

  • change subheadline from “An advanced, purely functional programming language” to “Write next-generation reliable, maintainable and efficient software on solid foundations” or similar.

Rewrite “Features” section or add a “Benefits” sections above with:

  • “Rapid prototyping: Try out new ideas, write less code and get to market quickly. Haskell’s foundations enables one of the best code-reuse with solid libraries. Don’t like writing types? One of the best-in-class compilers like GHC will figure out most types for you. With Haskell you write less code, so less code to maintain.” (Appeal to Startups and new projects within existing companies)
  • "Scale with ease: From 1 to 100k users and more. Haskell is used by startups and large corporations, because it’s one of the best and easiest programming languages for high-performance multi-core processors with convenience and efficiency. It’s focus on purity, that no other mainstream language supports, enables one of the best-in-class async and parallel programming experiences. (Appeal to use in modern ever more powerful environments and other companies)
  • “Maintain with confidence: Add new and ever more complex features, or refactor your whole code base with minimal costs. Haskell saves money on maintenance by having one of the strongest type systems on the market to prevent mistakes before they reach production, even before writing tests. “If it compiles, it works” – a Haskell proverb.” (Appeal to long-term success, money and ever increasing software complexity)
  • “Holistic: Everything you need at your fingertips. Get all your tools quickly with GHCup or Nix. Use your favorite code editor like VSCode, start an interactive environment in the GHCi to explore libraries and ideas, and build on top of the shoulders of a large library ecosystem with the package manager Cabal.” (Introduce key names of tools)
  • “Cutting edge: Haskell is a vehicle for programming language research and innovation. Peek into the latest, upcoming language features of the market, which often enter the mainstream much later. Try out next-generation ideas like Effect Systems, Linear Types, Dependent Types (soon) etc. to make your code even more reliable if you need it and can tolerate risk, or stay with safe current best practices.”

What do you think? How would you formulate it and what else would you improve?

edit:
Please now propose concrete formulations in the PRs:

21 Likes
2

Is Nix part of the Haskell tooling that we want named? I’m not just asking as a Guix user, but it seems like a really big endeavor to field questions about. It seems like something that should be mentioned in the docs, but perhaps not so prominently as to avoid intimidating new users.

7 Likes
3

Makes sense. I updated the post

1 Like
4

Reading your other thread, it’s clear to me that the messaging should be tailored to the audience to some level.

How about incorporating a section that splits based on the type of reader? The reasons to be interested in Haskell are different for:

  • A beginner who has never programmed before;
  • An experienced programmer who has never used Haskell, but may have used something else;
  • A manager who is considering Haskell for a new project;
  • A graduate student / researcher (this is Haskell’s roots after all)
5 Likes
5

I like the idea, but I find point 2 and 3 a bit of a mouthful.

In general, it reads more like a sales pitch.

I’d probably approach it more from the angle: why is Haskell fun to write?

It’s ok to make statements of opinion, but being too grandiose carries the risk of coming across as less believable.

13 Likes
6

I tried to make it interesting for all of these audiences but with an emphasis on commercial usage. Do you have specific formulations in mind?

7

That’s exactly the point to tease people to try Haskell out.

My assumption is that fun emerges from using it and is hard to convey and convince by words, but i’m open for improvements. Do you have specific formulations in mind?

1 Like
8

Good question. I would reuse all of what you said; this is about presenting the appropriate information for the appropriate reader.
We wouldn’t want someone to read something they’re not prepared for, in which case our sales pitch would sound like this.

Without specific phrasing, I would say:

  • For beginners:
    • Haskell is general-purpose – you can build practically anything you want;
    • The emphasis on types makes it easy to write programs that work;
  • For the experienced:
    • Haskell is a gateway to a programming paradigm which you may not be familiar with, but is gaining traction in many communities;
    • Fearless concurrency;
    • Complete toolchain including multiple mature build systems and a language server for ease of development
    • Relatively large ecosystem of open-source libraries;
  • For the manager:
    • “Scale with ease: From 1 to 100k users and more”;
    • “Maintain with confidence: Add new and ever more complex features, or refactor your whole code base with minimal costs”);
    • Relatively large pool of excellent candidates available for hire
  • For the researcher:
    • As you said: “Cutting edge: Haskell is a vehicle for programming language research and innovation.", and cite some cool examples.
5 Likes
9

Can we move the suggested text to a Google Doc or something similar so we can work on it collectively by suggesting changes?

2 Likes
10

I hope this doesn’t come off as rude/demotivating, but:

I find more or less the entire text you wrote off putting. The text is full of grandiose, unsubstantiated, uninformative, and even some outright incorrect claims [1], that tend to make me immediately close a particular page and never look at it again.

[1] some examples:

  • “refactor your whole code base with minimal cost” (what does that even mean?)
  • same for “best-in-class compilers”: according to what metric?
  • “Scales with ease: …”: that is not a feature of a programming language but whatever one writes in it. You can write either an efficient or an extremely inefficient solution in any language.
  • “Dependent Types (soon)” (This doesn’t seem to be anywhere close to the truth based on what I’ve read from the roadmap that was shared here a while ago).

Generally, I don’t really understand the need to specifically attract/appeal to commercial users. I would think we are better off trying to improve haskell the language, its compiler, and its ecosystem for the users it already has. That both has an immediate benefit for everyone already using haskell, and I also think it is the best way to actually attract people: if they see/hear from someone actually using the language and shows it is effective.

3 Likes
11

This is a great idea! IMO “Why Haskell?” should be visible on the very first vertical screen and focus entirely on decision makers. (The “choose your role” could work, but decision maker should be the default.)

I would avoid generic, unverifiable statements (“get to market quicky”) and focus on what puts Haskell ahead of the competition. I would avoid “programming language research”. Haskell as a language isn’t very research-y anymore, and I would imagine that such a statement pushes decision makers away rather than draws it towards Haskell.

4 Likes
12

To me, the biggest under-emphasised win for Haskell is fearless refactoring over the long term. (It’s on your list but I’d put it even higher.)

Readers of this thread have much more experience than me, but my impression is that it’s very easy for a dynamically-typed codebase to get to the point where no one dares modify it any more. The original author has left. Two years after that it’s essentially read-only; and it’s only a matter of time before it has to be rewritten from scratch.

In Haskell, it’s possible to do truly major heart-lung-transplant refactors on a 200k-loc code base that is 30 years old. (I know, because I do that to GHC.) That is a major value proposition. Instead of having a 5-year lifetime, your investment has a mult-decade lifetime.

Now, this is somewhat true of any statically-typed language; but the more expressive the type system, the more true it becomes. Haskell is at the bleeding edge of expressiveness, which certainly has its costs, but it has its benefits too.

This is a “total lifetime cost” argument, not a programming productivity one.

I’m an academic, so my opinion on Haskell-in-the-wild is deeply suspect. I’d love to hear from others with concrete of software evolution over its life. For example, am I right to claim that many codebases become essentially un-maintainable after a few years when the original authors have left?

One other thought. You mention concurrency, but you don’t mention STM (software transactional memory). STM is an astonishingly powerful and effective concurrency abstraction. But (after a 10-yera flurrry of interest) no mainstream language has adopted it wholesale because it just doesn’t work well in languages where mutation is the way you get computation done. In contrast, it works brilliantly in Haskell; indeed the “retry” and “orElse” primitives give it qualitatively-new power that I don’t think any imperative-langauge STM implementation ever attempted.

STM has come “in the box” with GHC for around 20 yrs. For concurrent programs, it’s a really big value proposition. (See my 2007 book chapter on “Beautiful concurrency”, getting on for two decades ago.)

Same caveats as above – I’d love to hear from practitioners. Am I over-claiming?

33 Likes
13

I will say the long-term pitch is exactly how we got Haskell adopted at my company, where most software is written in Java or runs on a mainframe. And the proof is in the pudding, we refactored our own 100k LoC app (now > 200k) into an event sourced architecture while still shipping releases to production. Fixing the boat without dry docking, if you will.

I can say with the utmost confidence that this would not have been possible, or even considered, if we were not using Haskell.

17 Likes
14

Haskell’s fun as shit - give it a try! If you have to work, you might as well have a good time.

^ there’s your Why :slight_smile:

4 Likes
15

To me, Haskell is fun to write, because:

  • I can express my thought’s with ADTs precisely
  • the functional paradigm allows me to reason about different pieces of code “locally” and their composition
  • the GC makes Haskell super high level, so I don’t need to worry about operational details too much
  • I can refactor code radically with high confidence
  • I can read code with ease without guessing where certain effects occur

There are some white lies in there, but I won’t apologize for them.

14 Likes
16

White lies are key to selling tech :laughing: when things are subjective, who’s to say I’m fibbing :wink:

1 Like
17

Yes. My experience after years of PHP is that big code bases tend to become unmaintainable even independently of whether the original authors are still in the team. At some point the complexity becomes too high and modifying the oldest parts of the code becomes too risky. So you end up with strategies to isolate the “legacy” parts from the rest, a sort of “permanent rewrite”.

That being said, Haskell doesn’t save you from legacy either. But in my experience with Haskell the legacy parts tend to be outside of the code base: abandoned libraries, messy database schemas, bugs that users start relying on (xkcd: Workflow) and so on. The code itself is easy to keep clean.

3 Likes
18

One thing I value about Haskell is the clarity of well-written Haskell code. Being able to refactor code is downstream of this, I think.

I remember reading a study about how developers spend much more time reading code than writing it, and I definitely experience that. Haskell code can be very nice to read. Haskell gives us the tools to write code that is explicit without being verbose.

The expressivity of Haskell also gives you the tools to write difficult to understand code with layers and layers of abstraction, or code that is much too concise at the cost of clarity (eg, overly point-free code), but that’s also possible to do in any language.

2 Likes
19
14 Likes
20

Maintainability is a mixed sell; the business environment changes fast and managers want rapid feature adds without breaking the legacy code, which I guess is maintainability, right?

So, maybe rephrase maintainability in a way more favorable to MBAs. “Code that safely adapts as fast as you do; dynamic languages might be as fast in adapting, but Haskell lets you change safely and retain the multi-million or even billion-dollar codebase you’ve built over the years.”

“Pivot a hundred million dollar codebase to a new business case in record time, and do so safely, with Haskell.”

1 Like