Add "Why Haskell?" benefits section to main page #338
Conversation
|
Update with prototyping first: |
|
Some thoughts on wording and content: In the "Scale with ease" section, the first sentence about users was a bit hard to follow. Is it clear how it relates to the rest of the paragraph? Bleeding edge section: in light of a few minor grammar and wording quibbles, I'd rewrite it as "Get a view into the latest in programming language innovation. Haskell has its roots in programming language theory, and has influenced many popular languages. New features like Generalized Algebraic Data Types (GADT), Effect Systems and Linear Types are at your fingertips, but are optional." . I'd also vote for "Cutting edge" instead of "Bleeding edge" (the latter connotes "unstable" to me). I really like the "Fun" paragraph, but maybe a synonym of fun would sound less flippant as a title? Like "Developer friendly". Maintain with confidence, suggested rewording: "Haskell has the strongest type system in any practical language: this prevents mistakes from reaching production code, and enables developers to refactor large codebases easily and safely. As the Haskell slogan goes, "if it compiles, it works"." I'd also say that links might add a lot of value, e.g. a link to the State of the Ecoystem site when mentioning Haskell's libraries, or to info about STM when mentioning Haskell's advantage in concurrent programming. |
|
I love the idea of this section. Since this is a significant change to the front page of haskell.org we'll want a majority vote from the committee on the change before we merge it. |
malteneuss
force-pushed
the
benefits_section
branch
from
5eb0efd to
a732f4e
Compare
@reubenharry Thanks for the suggestions. I've simplified and clarified some of the wording. (Please write further comments as review comments for to separate discussions for separate sections).
|
|
I've been wondering if there was a way to merge it with the "Features" section or make a hybrid of both or just leave it as is. Because the development experience kind of emerges out of those features. But I have no idea what the best structure would be. |
|
To me the current "Features" section further below is actually nice to get more technical details what Haskell has that others don't; although that section could also be improved (in another PR). |
|
This is a great PR! And I think it's awesome to highlight why haskell. I am however of the opinion that "Cutting Edge" is actually not a "why haskell", but rather "why not haskell" part. I'd even go as far as say it conflicts with the "Maintain with confidence" and "Scale with ease" parts. The Cutting Edge section even mentions Linear Types, which as far as I recall, is still highly experimental. |
|
I think the tension between language innovation and stability is actually a selling point. I'm not sure how many language communities actively pursue both goals. It is hard and we're doing it! |
@angerman I'm also open revert back to towards "Bleeding edge" (with the experimental connotation), and maybe removing GADT's from the examples. I want to emphasize that Haskell supports both like @hasufell (if you need it, but can tolerate more instability), maybe that should be clearly stated along the lines as it was before: |
site/index.html
Outdated
| <h3>Delightful</h3> | ||
| <p>Software that works, scales and is easy to maintain helps you to attract talent and keep your team motivated. | ||
| Haskell is a language that let's you express your ideas clearly and teaches you a new way of thinking about programming | ||
| — if you work on a challenging project, you might as well have a good time. |
There was a problem hiding this comment.
This sounds slightly odd to my ear both in terms of tone and content, but I don't have a great alternative suggestion.
There was a problem hiding this comment.
Indeed it's a bit bold in contrast to the rest. I'm open to change it someone has a more fitting phrasing.
site/index.html
Outdated
| <h3>Rapid prototyping</h3> | ||
| <p>Start small and explore new ideas to find your market fit. Haskell is a compact language with a large ecosystem of open-source libraries and tools | ||
| to get you started and help you growing. | ||
| The strong type system makes it easy to write programs that work, both large and small, even when you don't like writing types — the compiler will figure it out. |
There was a problem hiding this comment.
Perhaps we could also mention that you can defer type checking to run time, letting you test programs that are not completely finished yet.
There was a problem hiding this comment.
To me this seems like a lower-level details that could fit into another PR for the "Features" section further below on the site, e.g. the "Statically typed" subsection.
@malteneuss I do like this more. I don't even mind GADTs much, those are pretty stable. To expand on my rational: If you want to kill Haskell at scale, you start going overboard with advanced type features, and make your codebase churn for each GHC upgrade (or you stop upgrading, which becomes its own drawback). If you stick to simple/boring/Haskell98+eps, you get pretty performant, and unlikely to break codebase, that's easy to maintain. If you go out and use Linear Types, or some of the work towards Dependent Types, you are opening yourself up to more churn. Yes you get great features, at the expense of increased maintenance burden. At the same time maintaining Haskell code is generally pretty great, because the rigorous type system gives you fairly easy refactoring abilities. This all falls flat once you have to refactor your code every 6-12 mo because of new compiler releases, and the subsequent churn in the ecosystem. We have made progress towards reducing this with the stability guarantees, and trying to move breaking stuff into e.g. ghc-internal. We didn't get all the way to put turely experimental stuff behind feature flags. So yes, I like your rephasing that basically says that haskell tries to provide industrial use while also allowing language research. I guess I'm just opposed to conflating it, as that distinctly does not reflect what I see in using haskell. |
|
@angerman Reverted to "Bleeding Edge" and emphasized experimental connotation. |
Co-authored-by: Julian Ospald <[email protected]>
The main connotation i wanted to convey is that Haskell is not (only) for small POC projects but for real-world mission-critical services, and efficient enough to do that while better handling complexity of parallel and conurrent programming. I can move the specific features (like GC; apparently not the best related feature here) out of this section into the "Features" section in a later PR, as i originally planned.
My main connotation was to express that Haskell at least offers more advanced features for reliability (when you need it) that mainstream languages don't offer, albeit as a trade off against more instability/churn. We can improve that in a later PR |
Exactly. To make it more vivid:
|
But you are already in the Haskell community :) I understand the point of this proposal is to appeal to the kinds of people who aren't yet. |
I don't think that's the point. If I'd visit a new language community front page and read this type of sentence, I'm not sure I'd be excited to dig deeper since it sounds grandiose and not really developer oriented. Would you as a developer be interested about a language that tells you that you can easily upscale to 1 million users? Anyone who has ever worked on a project with 1 million users, regardless of language, will probably get nightmares from just thinking about it. Any decision or mistake you make has super high impact... I want to think about why haskell is fun, not how to navigate the most challenging industrial projects without going broke. That's why I think there is an obvious rift in terms of audience. |
|
I'd go so far to say that if our audience are managers and startup CEOs it's even more so inappropriate to tell white lies. What does actually matter for a business?
In light of those priorities, I think Haskell cannot be recommended without reservations. It depends: are you tech focused, do you already have access to strong talent, will your product be a long-living product, etc. etc. I think we should be cautious here as to not be perceived as misleading. If we focus on developers... and they will be disappointed after 3 weeks of experimentation... well, sorry about that. And everyone moves on. But I'd really be nervous if this text is seen as advice for startups and managers. |
|
My impression is that parts of the Haskell community subconsciously(?) don't actually want Haskell to gain widespread adoption so that they can stay special unicorns in their niche. Remaining at the status quo and preaching to the choir of FP enthusiast certainly won't help Haskell to improve adoption commercially much. You have to start somewhere to target a larger audience, and one important step is to start using language that more people understand, e.g. what Rust did when it transitioned from a developer focused https://prev.rust-lang.org website to its current form https://rust-lang.org with the explanation "As part of Rust 2018, we will completely overhaul the Rust web site, making it useful for CTOs and engineers alike." |
I think that's almost ad-hominem and I didn't spend 6 years of my free time on Haskell tooling, because I want it to remain niche. If a CTO asks me whether Haskell is a good choice for them, then my answer depends on the situation. Lots of what's written here is a pretty good pitch if it was on the website of a consulting company that can help you actually do it. Otherwise, it lacks substance. And then the only two options are a) it's seen as a bad sales pitch, because it lacks evidence or b) someone actually buys into it without understanding the consequences. |
I overgeneralized and apologize. My frustration is actually with comments like "Haskell not being for everyone is a feature, not a bug" and ambitions to keep the status quo. In this thread we just seem to have different opinions on what constitutes effective marketing, of which we both probably can agree on that Haskell needs more. |
|
+1 to more effective marketing one way or another. A few more points I'd like to make on what is effective:
Given Haskell is currently so niche especially compared to the quality of the language, we have significant evidence for the claim: the marketing pitch that's effective to you, @hasufell (and me), versus the marketing that is effective for the broader programming community at large, are quite different. We should be careful about leaning too heavily on "Well I would react like {this} to {that messaging}". We are optimizing for the reader who is unfamiliar with Haskell, not the one who was already curious enough to try Haskell with our current marketing materials. Our historic approach is empirically not as effective as it could be. Second, this is a "Why Haskell" section, and not a "Why not Haskell" section -- so giving the in depth and fully balanced view of tradeoffs and caveats to every claim we make should also not be the goal here. We could certainly add a "why not" section or similar that really digs into the tradeoffs of the language! It's not misleading to highlight the benefits and values and leave the deeper and more nuanced overview for another place. We need to be put our best foot forward here and write this section as if this is our only chance ever to convince the reader that Haskell is worth spending more time on. I still think this PR is ready to go now, but I thought the above was worth writing out to hopefully build more alignment between everyone here on the marketing strategy. This is an important and productive discussion! |
Sorry, I don't follow. What made you come to this conclusion? |
|
This conversation thread will go nowhere until we've determined with precision what is the target audience. Only then we'll be able to move forward in a productive manner. |
|
Given the Haskell Foundation's mission statement "broadening the adoption of Haskell, by supporting its ecosystem of tools, libraries, education, and research", i suggest to pick (and i picked) the broader programming community at large (including commercial users) as @aviaviavi described, and communicate not in terms of features (why should i care that Haskell is using functional programming and is advanced?) but in terms of value propositions. |
Because your developers will deal with those facts every day? |
|
Alright, I feel we're running in circles and not really getting deeper into the problem and all I get seem to be red herring arguments like "but you're already in the Haskell community, I've worked in a multitude of Haskell companies, including startups, banks, traditional small software shops and large tech companies. I've also had minor experience with non-tech entrepreneurs asking me for technological advice. So I want to draw on that experience when making my claims. How do businesses decide what language to use?This is the main question we need to answer. And we need to recognize there are different types of businesses. Non-tech startupNon-tech startups don't care about the technology, but about selling a product. They lean towards outsourcing the tech part and only keep the product and project management in-house. They care about fast results and an easy way to outsource or hire cheap developers. The non-tech savy CEO will either just go with whatever the market standard is in that industry or try to get a tech-savy founder (CTO) on board, who will then make the decision. As such, the only way I've ever seen Haskell make it into a non-tech startup is because one of the founders is a Haskell aficionado. I doubt any founder with software engineering background would be so bold to pick a language for the business they're not already proficient with. Chance of failure is already tremendous. Tech startupTech startups deeply care about technology and put that at the core of their business ideology. In my opinion, tech startups already have a deeply preconceived idea of what to use, so they won't be looking for advice or go around and do extensive research. They're all techies and are already sold on a paradigm and have years of experience. They care about language features, excellence and performance. So why would they pick Haskell? Either they're already Haskell experts or they come from an adjacent language (e.g. Scala) and want to experiment with Haskell in production and have the confidence to do so. Big corps (non-tech)I think the easiest example of this are banks. They don't care about tech, it's just a means to an end. They could as well just use excel sheets for everything if that was more efficient. They are often very hierarchical, with strict reporting and performance goals. They foremost care about commercial support, integration, reliable systems and so on. Since they have lots of resources and access to very strong talent, they don't mind developing in-house solutions or deviating from the industry standard if that gives them an edge. So why would they pick Haskell? Because it scales? Certainly not, so does Java. I think these are rarely purely higher management decisions, but developers and ex-tech managers proposing the technology, because it has a very specific advantage. These places are risk averse, so if it's just another language that scales, then they'd rather stick with Java. Big corps (tech)Big tech corps already use Haskell. They drive technology and have huge budgets to experiment. They pick Haskell, because they can, but they don't have to. They have access to global talent, can drive language ecosystems or develop their own dialects/languages on a whim. So why would they pick Haskell? I would say simply because their developers want to or it particularly fits a specific use case well. They likely have a multitude of languages in use, so Haskell has to compare well to the alternatives, especially because they have the means to develop in-depth experience and compare velocity etc. Traditional small software shopsThese places have possibly decades long software engineering experience (e.g. with older tech stacks) and are tech-savy, but conservative. They care about maintenance, stable hiring market and robustness. They may pick Haskell, because it's more modern than their previous tech stack and promises to provide a better development experience. These places care about their developers as much as they do about their products. They might be so bold to make a prototype in a new language as a proof of concept. So where do the decisions to pick Haskell come from?There are lots of nuances here, but I think on average the decision to pick Haskell comes from the "bottom" (the developers) or very tech-savy management, which will have to consider their development team anyway. There have been lots of cases where people sneaked in Haskell into their company for smaller projects. The decision to completely jump ship isn't something that happens over night and the reasons to do so will usually be deeply technical and based as much on the development flow and experience as the "healthiness" of the language/compiler/ecosystem. The business concerns are usually not the reason to pick a specific language over another... they are a reason to rule out certain languages. A business always wants a language that scales, has a large ecosystem, commercial support and easy to hire talent (I repeat: we are not at the forefront of those points). If some of those points are lacking, the language has to make up for it with other (technical) superior properties. So how should we market Haskell?We can't market Haskell as the best pick for large conservative businesses, as we simply lack the commercial support (we have what... 3 major consulting companies?). Most of its users are on the tech-savy end, because Haskell provides enough net value that those other shortcomings won't hurt them. That means the easiest way to market Haskell is to focus on developers coming from other languages and do so aggressively. Forget about Scala, Elixir and Clojure. Haskell is the real deal. They will promote Haskell in their businesses and are part of larger tech decisions in the end, collectively or as they rise in ranks. As the adoption increases through our sleeper agents, we may reach a point in the future where Haskell really shines in terms of commercial support. And maybe that will become its main value proposition at one point. But at the moment... it's the language itself, its technical properties and the super engaged community. We could also discuss: who's even visiting the Haskell front page? A CEO desperately looking for a tech solution? Probably not. They'll be over at Tiobe index where we already dropped out. Case studies of other programming language front pagesRustI was deeply disappointed by the headline. It's empty words. The "Why Rust?" section however similarly references specific language features (and tooling) just as my alternative PR does: #342 ElixirI find the headline much better: it tells me what type of paradigm I'm dealing with, but also gives room for some bragging about scalability and maintainability. The rest of the site very quickly goes into technical details (even with code examples) for every claim they make. I proposed this idea earlier, where we could merge the "features" and "why Haskell?" section. PythonThe headline is short and conveys what Python truly stands out for: "work quickly" and "integration". It's not sales speak, it's the truth and easy to back up. Above the headline are interactive code examples that (again) explain language properties, rather than vague value propositions. UnisonHeadline (or sub-line) explains the paradigm in one sentence. The value propositions are fairly technical and quite specific. GleamI can understand the paradigm from the first look at the page. Scrolling further down gives me more technical insights. So what should the front page provide
|
To be clear, this is not my argument, and I have not made any claims about what you know or don't know. My argument is that we already have in the community pretty much all of the people, you and me included amongst them, to whom our traditional marketing approaches appeal ("Haskell is pure and lazy!", "Haskell is academically rigorous!", "Haskell is theoretically advanced!"). In order to grow we need to market in a way that is not appealing to people already in the community. |
|
Thanks, did you read the rest of my analysis? 😄 I feel you're not engaging with my arguments, to be honest. |
No I didn't. I read what I interpreted to be a misunderstanding of what I was saying which seemed to warrant urgent clarification, since it is the kind of thing that could cause offence. |
|
@hasufell Thanks for doing this study of other players in the space. This is very valuable work and should have been the first thing posted – not necessarily by you. There seems to be a trend that we can safely follow with a hook first, and technical details later. |
Being able to scale is indeed not the main reason to choose Haskell, but I think the fear of Haskell failing to scale (because it is just a research language) has already caused people to avoid Haskell. Our front page should dispel such myths.
I would recommend to also look at Swift and Go, which I consider to be better role models for Haskell. And, for the record, only the Go front page lists even one feature which is just "built-in concurrency".
Those are hardly unique features, unless you consider functions, arithmetic, and records, to be selling points of a language. Instead, the code examples in the top banner are aimed at novices! |
Incidentally, my first job at a Haskell company had massive problems with scaling exactly because of memory issues ;) Was Haskell developed to scale? No it wasn't. But there are ways to scale it. It's the community and tech pioneers that enable this with resources, documentation and institutional knowledge. So maybe what I want to say here is: if you fundamentally have a problem with doing a bit of pioneering work or getting your hands dirty, then Haskell might be a questionable choice.
Oh they don't have to be. They just have to represent the language. Python isn't very unique in terms of features, but there are reasons it has taken off. |
|
I find @hasufell analysis compelling and spot on. It is a good starting point for following the discussion. How do businesses (actually) decide what language to use? I would like to hear more experience-informed answers to this question, and leverage this knowledge to find the target audience. This is needed for the "Why Haskell?" question to be answered in any meaningful sense. It is also needed for it to be effective, because if the section engages business managers who won´t care or might be disappointed the effort would be wasted or could even backfire. What if it is not that easy to scale their business? Or if their developers are not delighted to learn a new paradigm imposed on their already refined practice (I've seen some complaints before)? Or—on another angle—are not thrilled by the possibility of their developers going experimental on bleeding edge features? As the argument stands, the target audience would be the developer—rather the non-tech entrepreneur, manager or executive board—who (ultimately) is the means to promote Haskell into a business tech stack bottom-up. Developers are indeed the bulk of the broader programming community. This proposal pushes towards wider adoption and —in a sense— questions the status quo that makes Haskell a niche language. I have to say that I was all in for the original approach at the beginning, but in the light of the arguments put forward I agree that
I think this gives a fair account of this proposal's content and pitch angle. In this context I would ask, are we to supersede Haskell's actual strengths by the business value it can bring if properly used? |
|
I don't have the time nor patience to discuss this topic to death by constantly moving the target further away. I suggest to try a Safe Enough to Try attitude. Feel free to use any of the text in case someone else would like to drive this topic.
|
|
I think we should apply the same logic as #337 and merge this as-is and continue the debate if we want to improve it. If we can get another committee member to approve, I think we should re-open this and merge it, and let the discussion continue. We don't currently have a succinct set of value propositions on the website, explaining why they should care about the features Haskell offers. This is a trivial marketing blunder according to widely accepted best practices in messaging/positioning. Adding this section in its current form will very likely help, and we have tooling in place to measure its effectiveness. It's low risk to try, potentially high reward if it resonates with readers better than not having it. |
@aviaviavi it seems odd to me when there's an alternative PR that has not been discussed in detail: #342 Sure, process wise you could just chronologically vote on each PR based on time of creation, but that risks shutting down synergies and discussions surrounding the differences. The first proposer might be overturned by the second without the ability to defend their stance, etc. |
|
@aviaviavi Yeah, I'd like us to take a proper look at #342 as well, before merging one or the other. |
I'm disappointed to hear this now, when we were just one committee member approval away from merging your PR. So be it. It is deeply regrettable that contributions to the Haskell ecosystem around public facing resources like the website are extremely difficult to make, and can only be made by people with superhuman stamina. That's not good, but it is the way it currently is. I would like to improve the situation, but I'm not sure I can. I will try. One way things I envisage things improving is if people are willing to expend the required amounts of energy to go through the process to completion, build consensus, build trust, build working relationships, build shared understanding, and bit by bit build velocity and momentum. I hoped the approval of your previous PR, @malteneuss, would have helped in that regard. Maybe not. Maybe my hope is in vain. Anyway, I'm also sorry I spent a lot of time engaging in good faith with this PR, trying to help drive it forward, only to have it closed. If I had expected that to happen I wouldn't have spent my time on it at all.
I would also support that. |
I support this, but since the submitter has closed this issue it will have to be submitted by someone afresh. @malteneuss said he would be happy with that: "Feel free to use any of the text in case someone else would like to drive this topic." |
I'm not sure I agree. The proposed change is very exciting (so I'm very thankful to @malteneuss for kicking it off), but also super invasive: we're basically deciding on a marketing strategy! This requires discussion, careful thought and considering alternative ideas. I've so far found it a bit disappointing that my critique was met with dismissive comments that felt like my own contribution to the topic wasn't welcome. I think it's fair to assume that such proposals will draw in lots of attention and critique, but it's vital that we remember that we all have the same goal: improving the website. |
|
Due deliberation is very important, but I don't think it should be conducted in a way that causes contributors to give up their attempts to contribute saying "I don't have the time nor patience to discuss this topic to death by constantly moving the target further away.". Surely another contributor experience is possible that still maintains sufficiently high standards. |
Follow-up from discussions on https://discourse.haskell.org/t/emphasize-why-haskell-on-haskell-org-landing-page/12036
Motivation: Increase general Haskell adoption by focusing 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, and to nudge them to try out Haskell.
Position on landing page:
Content:
