…there was another phrase similar to it that appeared a few years ago in popular culture?
© HBO
Perhaps the writers of Veep were inspired by Rust’s "stability without stagnation”…
There already are testimonials from educational and commercial users using Haskell on www.haskell.org - have more of those and less (variations of) cliches…
Imagine a team of business marketing experts trying to design a complex software architecture, a system with impure multithreaded code, asynchronous exceptions and type-level programming. Then, for analogy, imagine a team of software developers designing a marketing and sloganing strategy. Neither team has competence in its task and neither team will succeed. You wouldn’t bet money on either.
A little bit of marketing expertise really could help and we shouldn’t hesitate to get those skills. The HF could fund this outright, or partner with a university marketing class and its students who need real-world projects for course credit and resume building. I’ve seen similar engagements with MBA students who developed a product strategy and they far outperformed the non-professional attempts from our tech-heavy team.
That’s a great idea, but even that requires some basic input from us, such as “what is our target group”, because no one can really answer the question “how do we grow the community?”. It requires us to decide:
Given that input, a marketing specialist could certainly cook something up.
- who do we want to attract?
- how do we want to present ourselves?
As a community interested in finding a balance between the needs of those educators, researchers, and practitioners that regularly use Haskell.
I did my best to go through the thread, to avoid re-iterating points that were already stated.
One of the most important points that was raised, in my opinion, is that there’s no way to focus resources on any particular area of programming. Who would make that happen? If some companies in a certain sector find Haskell a good fit for their purposes, then the foundation could pave the way for them, and remove obstacles, but that’s about it.
What the foundation could do on its own, is to lead by example. I believe that part of the success of Go is because the language, and the standard library, set a tone, so to speak. And libraries generally emulate that tone. And that makes onboarding pretty easy. Not just onboarding newcomers to the language, but also onboarding experienced developers onto new libraries.
For example, every Go package is documented on https://pkg.go.dev/. I know where to click, what to expect, and so on. The standard library sets the bar pretty high by supplying lots of examples that you can just copy paste into a playground, or into your code.
Then there’s also the code style. The idea behind abstractions like io.Reader, the absence of functional programming constructs like mapping and folding, and so on. Please note that I’m not saying that this particular style should be emulated by Haskell (obviously), but that leading by example can go a long way towards creating an ecosystem where most things are somewhat familiar and therefore easy.
I think Haskell has already improved in these areas. For example, I love the Haskell playground and use it a lot to prototype, or just check out examples. It also seems to me that more core packages come with examples. But there are also lots and lots of under documented examples and the documentation overall could be easier to navigate. I’m a huge proponent of standardized documentation (something that Javascript for example lacks) and since the foundation (I assume) kind of “owns” hackage, they’re also in a position to influence things here.
The other aspect is uniformity and familiarity. Everyone uses a different set of extensions, custom prelude, this or that library for the same purpose. I’m not sure how to best address this, but if the foundation, through the code it owns, would show average programmers like me how things should be done, that would greatly help me.
The same goes for formatting, linting, and generally tooling. If Haskell had an official formatter, it would also serve as a demonstration of how to write a CLI tool in Haskell. It could show people whether Haskell is a community that prioritizes customization, by offering lots of formatting options, or one that favors simplicity (think go fmt). Again, not saying one is better than the other.
Error messages also fall under this umbrella. Is Haskell a language/ecosystem where having understandable error messages is important? If I see obscure errors from the compiler and core libraries every day, then I’ll likely just do the same in my own code. This follows the idea of writing code that looks like the surrounding code.
Summary: I believe that the best lever the foundation has is to use the part of the ecosystem it owns to set an example for what modern Haskell should look and feel like.
I fully admit that there are plenty of languages that succeed without that. I mean look at Javascript. I’ve been writing JS on and off for over 7 years, and it seems to just get wilder and messier every year. But it still hasn’t collapsed under its own weight. Not sure what to make of that.
that is something i really want Haskell to take inspiration from. Go does a great job~!
god i am grateful Haskell differs from Go in that respect. if Haskell falls to One Way to Do It that’d be a shame. luckily that’ll never happen, at least.
for example, there will (inherently due to the nature of Haskell) never be a go fmt equivalent for Haskell. or if there is one, it’ll be so unopinionated that it will leave a lot of room for personalized formatting via whitespace. but then it wouldn’t be go fmt 
explan your reasoning, please
Go has a painfully low ceiling. You bump into it pretty much immediately if you start using it for moderately-sized projects as a sole, skilled developer.
But that’s not Go’s stated purpose. Its goal is to be a good language for scaling teams of fungible developers who you do not trust to have taste. This is not me being edgy it’s what the creators have said (in different words).
You use Go to solve big problems by hiring people and ensuring none of their agency causes problems. It’s proven to work but isn’t especially pleasant to partake in for some people.
It’s true Go has some nice things Haskell doesn’t. Maybe Haskell can get some. But it’s important to realize that a lot of the nice parts of Go are born from it aggressively eschewing the stuff that makes Haskell Haskell. There are trade-offs at play.
Let’s have a think about what we would never had had if we stuck to “one way” of doing things:
IO-wrapper effect systems like effectful/Bluefin… plus plenty of other stuff over the years. So I’m inclined to agree that we get a lot of benefit out of the Haskellish reluctance to “standardize”.
Don’t forget all the database access libraries! And parser combinators.
I get as a beginner it’s annoying to see ReadP, attoparsec, megaparsec, and more..but it’s for the best.
At the end of the day, Haskell doesn’t bend over backwards for beginners. I appreciate that it has an actual learning curve. It means it’s actually worth learning.
It does mean that there’s an opportunity and perhaps responsibility for us, as the more proficient users of the language, to provide guidance to people starting out. This can be done by writing about how we actually use things together, e.g. by highlighting libraries as “new research area”/“good choice if you’re OK with the bleeding edge”/“safe default choice”/“old, not recommended”/“abandoned, there are better alternatives”; or by writing about things that have worked well (and not so well), and how to choose pieces that fit together well (in terms of language features, library selection, or even entire stacks).
I agree. I’m aware of
+1 for the whole list, combo of all of these is what makes Haskell great, which is why it is a bit hard to explain it in only one or two sentences.
Especially ADTs: it sounds very simple, but ADTs are just such a natural way to capture the domain as I imagine it in my mind, and the ease of writing them (compared to writing a class in OO language) is what allows me to quickly prototype.
Which (exhaustiveness checking in pattern matches) are a weak point of GHC’s type-checker, for example compared to the data flow analysis of many (not all) Python type checkers (just because Python has been mentioned above). So better don’t mention that as an advantage for Haskell
Maybe I should explain what I’m talking about:
-Wincomplete-patterns does this:
let x = Just 1
case x of
Just n -> putStrLn "AAH"
-- Nothing -> putStrLn "Hmm"
main.hs:3:3: warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In a case alternative:
Patterns of type ‘Maybe Integer’ not matched: Nothing
|
3 | case x of
| ^^^^^^^^^...
I think this is correct!
One thing I would add is that the type safety that Haskell offers is also what enables rapid prototyping for me, because rapid prototyping involves a lot of small-scale, fast refactorings.
At the end, what it comes down to is that I can really rely on the compiler and let go of thinking so much myself about what can go wrong → type system / compiler is there for me, as a guard rail, to protect me from oversight and other mistakes. That allows me to move fast and focus on the problem I am solving, knowing that I am not leaving gaps behind me.
I remember somebody on reddit saying that (paraphrasing) “Haskell allows me to think less”, and I think that captures the essence in a great way. Indeed, with Haskell I can “let go” and know that compiler has my back.
Oh and of course, combo of this + GC + high level + fast + ADTs + functional paradigm is what really makes Haskell great. I think @hasufell captured it nicely in his answer.
What’s the weakness in that example ?
The erroneous warning.
Well, ideally GHC would throw a warning if the Nothing is added, because of unreachable code.
And GHC “knows” that Nothing would be unreachable, as the core doesn’t include the branch (even with -O0).
main = do
let x = Just 1
case x of
Just n -> putStrLn "Aah"
Nothing -> putStrLn "Hmmm"
main :: IO ()
[GblId]
main = putStrLn (GHC.CString.unpackCString# "Aah"#)
The original:
That’s a feature, not a bug. If the constructor is actually fixed statically, the case expression is entirely useless, so it’s safe to assume that it’s only a stand-in for a different expression that might vary at runtime.
Swallowing warnings for incomplete cases and instead throwing spurious warnings for useful cases until the constructor is replaced with something not statically known is pretty counterproductive.
Well, why does GHC (well, versions >= 8.10) report a warning now? Or what is the reasoning behind not changing the Just 1 against a different expression that might vary at runtime.
main = do
case Just 1 of
Just n -> putStrLn "Aah"
Nothing -> putStrLn "Hmmm"
<source>:4:9: warning: [GHC-53633] [-Woverlapping-patterns]
Pattern match is redundant
In a case alternative: Nothing -> ...
|
4 | Nothing -> putStrLn "Hmmm"
| ^^^^^^^^^^^^^^^^^^^^^^^^^^