Add "Why Haskell?" section (alternative)

[hasufell]

An alternative to #338

The idea is for this to be developer centric. We want to attract foremost developers, not managers. And we want to give a glimpse "behind the scenes", connecting the dots between development experience and language features. It's ok if there are words the reader doesn't understand... that's what should make them curious!

Parts of the text are based on the PR by @malteneuss ...other parts were written from scratch.

---

[Kleidukos]

I'm greatly in favour of this (or even improving upon this). The sentence are in the active voice, they involve the reader much more, instead of passively describing things.

[reubenharry]

Both grammatically and stylistically, I think "Concepts that will blow your mind" could be improved. Maybe something like: "learn a new way of thinking about programming: functional concepts like referential transparency, immutability and lazy evaluation are a joy to learn, and will expand your horizons and abilities"

[hasufell]

What's grammatically wrong with it?

[reubenharry]

"Concepts that will blow your mind" isn't a sentence, it's a phrase, so it sounds weird here (to me, but mileage may vary) as opposed to e.g. "These are concepts that will blow your mind".

[hasufell]

We can use a semicolon instead?

[reubenharry]

It still sounds weird to me, because either side of a semicolon should be a sentence. I'd say a comma would work: "...and lazy evaluation, concepts that will..."

[TikhonJelvis]

this is a classic place to use an em-dash :)

although they've been getting a bit of a bad reputation thanks to ChatGPT and friends overusing them

Express your ideas clearly and learn a new way of thinking about programming. Based on lambda calculus, Haskell is a purely functional programming language that features referential transparency, immutability and lazy evaluation—concepts that will blow your mind.

[reubenharry]

How about: "Haskell is pure and lazy, has immutable data structures, and lazy evaluation: these concepts will expand your programming horizons.

[reubenharry]

Maybe: "Don't worry about evaluation order or execution details when it's not relevant to your goals - just write a program by describing its logic".

btw, I worry that the word "logic" will cue people to think of "logic programming".

[Bodigrim]

I like it. Vibing and inspiring.

[ninioArtillero]

Consensus was not reached in #338, but IMO this proposal bears the fruits of its discussion. I think it's an exciting and well backed pitch for Haskell!

[tomjaguarpaw]

Personally I significantly prefer #338, but I like @malteneuss's suggestion of acting on the basis of Safe Enough to Try, so since #338 is closed I approve of this change.

---

Here are the elements I take issue with. Nonetheless, I think it's worth giving it a go.

lambda calculus ... purely functional programming language that features referential transparency, immutability and lazy evaluation

There are probably more than one hundred times as many people to whom "lambda calculus", "purely functional", "immutability", "referential transparency" and "lazy evaluation" and scary and off-putting than to whom they are attractive. To be clear, I think those properties are what gives Haskell the emergent behaviour of being an excellent language, but they are not themselves the excellence. I would prefer to talk directly about reliability, dependability, comprehensibility, refactorability etc.

There is no global state or mutable variables obscuring the meaning of your program.

Haskell does have global state (for example uniqSource) mutable variables (many different flavours in fact!). Still, I understand this claim is true in spirit.

The strong type system makes sure there are no surprises — never again will you have to guess what your program does at execution time

This sounds like a very strong claim. I've certainly come across Haskell programs where I had to guess what my program would do at execution time!

tooling story that's truly amazing: spawn your toolchain with GHCup, build your project with cabal, get editor integration with haskell-language-server

I've certainly heard cabal and HLS derided as providing a very poor tooling experience, both inside and outside the community. (I've never heard any complaints about GHCup from anyone.) I don't think we can make a claim like this on our front page without becoming a laughing stock.

---

Still: I think it's safe enough to try.

[hasufell]

There are probably more than one hundred times as many people to whom "lambda calculus", "purely functional", "immutability", "referential transparency" and "lazy evaluation" and scary and off-putting than to whom they are attractive. To be clear, I think those properties are what gives Haskell the emergent behaviour of being an excellent language, but they are not themselves the excellence. I would prefer to talk directly about reliability, dependability, comprehensibility, refactorability etc.

I thought it's not bad to introduce some of the terminology. Ideally, I wanted to include links that give an introduction to each of these concepts (if we had a Haskell book...).

If you're not keen to learn new concepts, Haskell won't be for you. Learning something new isn't just a necessity, it's also one of the appeals and we have to make it sound cool and exciting.

So the motivation for this section was:

• describe Haskell honestly with few words (lazy and purely functional are a must, imo)
• make it sound cool to learn a new paradigm/new concepts

Haskell does have global state (for example uniqSource) mutable variables (many different flavours in fact!). Still, I understand this claim is true in spirit.

Yes, it's a white lie. But I think not much worse than claiming that Haskell scales easily.

This sounds like a very strong claim. I've certainly come across Haskell programs where I had to guess what my program would do at execution time!

I guess that's true.

My motivation for this section was to describe what is probably so natural for us Haskellers and we basically forget that we have: a different way of both reading and reasoning about programs. Coming from languages like C and bash this was truly mind blowing. And I feel we need a way to express that.

I've certainly heard cabal and HLS derided as providing a very poor tooling experience, both inside and outside the community. (I've never heard any complaints about GHCup from anyone.) I don't think we can make a claim like this on our front page without becoming a laughing stock.

Clearly, I'm biased here, since I've spent so much time on tooling and will continue to do so. HLS has seen immense improvements, both in terms of features and performance/memory residency (thanks to MPJ, Zubin, fendor, etc. etc.). Cabal is finally actively being worked on. I think we can do what sales people do here: lie a bit and then figure out how to deliver it anyway ;)

[reubenharry]

I left some more comments, ofc feel free to ignore - just my thoughts on wording.

To me, Abstraction and Excellent tooling feel like the least compelling sections - in fact I wonder whether 4 sections instead of 6 would be good, vis a vis "less is more".

I also do agree with your philosophy of targeting developers. Some features that I think are really easy for someone to be excited by (without already knowing Haskell) are: immutability, type inference (write code and the language can "always" work out the types!), and purity. Features that I think people won't be able to understand the benefit of at first glance, but might be intrigued by are laziness, declarative style and being functional.

[reubenharry]

Why are "express your ideas clearly" and "learn a new way of thinking about programming" in the same sentence? They seem like different (though connected) ideas. Seems better to me to focus on the latter here, and save the former for a different section.

"Based on lambda calculus": should have a comma after this, but also I'd advocate for dropping it. I think there's a careful balance between new terminology and ideas being intriguing and being off-putting. Having just a few seems best, like "pure", "statically typed", "lazy", "immutable" and "functional". Referential transparency and lambda calculus feel like too much, at least for me.

[hasufell]

How about: "Haskell is pure and lazy, has immutable data structures, and lazy evaluation: these concepts will expand your programming horizons.

I find this less compelling.

I want to start every section with an "action" that involves the reader. The proposed wording feels a bit more dry to me.

[hasufell]

Why are "express your ideas clearly" and "learn a new way of thinking about programming" in the same sentence? They seem like different (though connected) ideas. Seems better to me to focus on the latter here, and save the former for a different section.

Yes, I think we could move "express your ideas clearly" somewhere else. But where?

"Based on lambda calculus": should have a comma after this, but also I'd advocate for dropping it. I think there's a careful balance between new terminology and ideas being intriguing and being off-putting. Having just a few seems best, like "pure", "statically typed", "lazy", "immutable" and "functional". Referential transparency and lambda calculus feel like too much, at least for me.

Can you suggest an actual wording? I'm a bit at loss how to put all this together.

[reubenharry]

How about: "Haskell is pure and lazy, has immutable data structures, and lazy evaluation: these concepts will expand your programming horizons.

I find this less compelling.

I want to start every section with an "action" that involves the reader. The proposed wording feels a bit more dry to me.

I meant that you start with "Learn a new way of programming", then my sentence.

[reubenharry]

I'd maybe put "express your ideas clearly" in the declarative section.

[reubenharry]

Can you suggest an actual wording? I'm a bit at loss how to put all this together.

See below

[reubenharry]

How about: "Haskell is pure and lazy, has immutable data structures, and lazy evaluation: these concepts will expand your programming horizons.

[reubenharry]

the "... made possible via" feels grammatically weird. Just "parallel programming...This is made possible by" would be better, I feel

[hasufell]

Starting another sentence breaks the flow. We could replace "via" with "by" though. Not sure that makes much of a difference.

[reubenharry]

Then I'd just avoid the "..." and use a comma.

[reubenharry]

"Only your imagination is the limit" feels a little vague. Why not just "Build powerful abstractions that are not possible in other languages, thanks to polymorphism...".

Rather than "has its roots in programming language research", why not: "has a design deeply rooted in programming language theory".

[hasufell]

I've been thinking to ditch this part and replace it with:

Stability meets Evolution

Build powerful abstractions via latest functional programming principles. While Haskell’s core is rock stable, the language is constantly evolving, but does so through rigorous processes. Learn new tricks and features as you go, while relying on a solid foundation.

Which will then more nicely correlate with an alternative headline described here: https://discourse.haskell.org/t/emphasize-why-haskell-on-haskell-org-landing-page/12036/47

[reubenharry]

Sounds good. Minor note: "via the latest functional programming principles". "rock solid" not "rock stable". I'd personally avoid "tricks" and replace it with "concepts".

[reubenharry]

Feels a little hyperbolic. How about a more understated: "Simple, effective and modern tooling: spwan ..."

[hasufell]

"Simple" is a rather controversial property when it comes to tooling and it's unclear to me what "effective" would mean.

I think having an amazing tooling story is our goal. Yes, we're overstating a bit.

Again: the hyped up language is on purpose. Your proposed wording makes it a bit more dry, in my opinion. Those are different styles.

[reubenharry]

That's fair. But while I think Haskell's tooling is very good (especially compared to 10 years ago when I started using Haskell), is it really a core feature that should be used as an argument for adoption? It seems to me that the obvious way for the tooling to shine is that it's now easy for people to spend 10 minutes trying out Haskell, and have an straightforward time getting set up.

I'm not opposed to less dry language, stylistically speaking, but this seems like an odd target for hyperbole. Should tooling even aim to be amazing (rather than just so straightforward that you never have to think about it)? The things I'd want to be overstated about are how Haskell is pure, makes refactoring complex code easy, etc.

[reubenharry]

Re. the previous version (#338 ), your points about the audience are well-taken, but I thought there was some text that was quite good. In particular @malteneuss 's Delightful and Maintain with confidence were very nice, and not at odds with addressing developers.

[angerman]

I have some reservations around tooling, specifically the claim that it supports all my favorite platforms, where I know for a fact that it doesn't. But in line with the hyped up language, I'm ok with this.

[aviaviavi]

This is definitely an improvement over no "Why Haskell section at all, so I think it should be merged in the absence of #338 which is now closed, but I do also prefer that PR. I'd be happy to re-submit #338 myself after we merge this.

My primary high level feedback on this approach is something I said in a comment on the original PR discussion, but was intended to reference this one: #338 (comment)

"Why" a language should be used is about the value it provides to the developer, not merely a list of its unique characteristics. Features are not value propositions, they do not entice readers on their own. "Abstraction", for instance, is not a value proposition. Why should I care about abstraction? What benefits do I gain from being able to have more powerful abstractions?

Value propositions are what we want to lead with in a "Why Haskell" section. Listing features first and then trying to explain why those features matter means people have to read a lot more to be enticed and get the point. We want them to be interested from a very quick skim of the page.

Listing features rather than value propositions is a common and extensively documented tech marketing mistake. A relevant quote:

“The value proposition has to switch from ‘look at all the great things that can happen’ to ‘look at all the tough problems you can solve if you’re willing to step up to the new technology.’
— Geoffrey A. Moore, Crossing the Chasm

[hasufell]

@aviaviavi thanks for your reply

Value propositions are what we want to lead with in a "Why Haskell" section. Listing features first and then trying to explain why those features matter means people have to read a lot more to be enticed and get the point. We want them to be interested from a very quick skim of the page.

The text I proposed does not merely list features, but explains emergent properties and development experience by starting each sentence with an action. It then connects that emergent property with specifics of the language (e.g. features, properties, specific tools) in order to raise curiosity.

As I already explained in my analysis, we are NOT targeting programming newbies here and we are NOT targeting CEOs, so some of the jargon and terminology may already be vaguely familiar to some of the readers.

The point of this PR is to attract programmers from other languages.

Listing features rather than value propositions is a common and extensively documented tech marketing mistake.

This is not what this PR does.

• "A new paradigm": a paradigm isn't a feature per se. We're not selling referential transparency here, we're selling the fact that Haskell will change the way you think about programming.
• "Declarative": this is not a feature, but an emergent property and expresses how "high-level" Haskell is.
• "Abstraction": this is about expressivity, which is not a feature, but an emergent property of features as a whole. We're selling that fact that we can build things in Haskell that you literally can't build with other languages.
• "Composition and predictability": this is obviously not a language feature either. We're selling the "ease of reasoning" in Haskell here, both in term of writing and reading programs.
• "Performance": not a feature, but a clear high-level value proposition.
• "Excellent tooling": this isn't even about the language, but about the development experience and is a very clear value proposition

As such, I feel it's somewhat of a mischaracterization that the proposed text focuses on "language features".

I'd be happy to re-submit #338 myself after we merge this.

This is exactly what I want to avoid.

I'm sorry, but the process regarding this topic has been rather chaotic. I understand that we are all volunteers, but I'm just expressing my contribution experience here too.

My hope was that the haskell.org committee would resolve the following questions (or something along those lines):

• what is the primary target audience (e.g. developers vs entrepreneurs etc.)?
• what are the main points we want to make when marketing Haskell (e.g. how much of Haskell do we want to describe vs making general statements about emergent high-level properties)?
• what type of language do we want to apply (e.g. there are very different styles... squishy, hyped-up, dry, etc.)? Because whatever it is it should be consistent.

If the original motivation of a PR gets completely lost in a follow-up PR, then what's the point?

"It's a bit better than status quo" is not very reassuring and in that case I'd rather not have it merged. Because it sounds like we don't really have a clear vision/understanding of how to market Haskell and just go with whatever is currently proposed. And it will likely end up in a mosaic patchwork piece of a front page if we don't have basic principles on whose basis we want to evolve the text.

[aviaviavi]

Speaking for the committee: We have enough consensus to move forward at this point -- I've merged this, and would welcome everyone to continue iterating!

Lots of good points made about the cohesiveness in guiding principles from Haskell.org committee, HF on marketing the language. It is being discussed as I write this, more updates on that to follow.