Ah, my bad for being too brief.
I meant to point out that that EDSL use case is where Haskell excel, and you just demonstrated it. And since the thread has lots of talk about main stream use cases, and I just wanted to point out we should also focus on successful cases when cleared being demonstrated here.
I see I starred this, but have no recollection of it. I love the goals! How is it proposing to help get there ?
Monad tutorial fallacy fallacy?
Like Iāve said before, itās time to drop the taboo, just please no burritos (specious analogies), unless they contain live kittens (are impurepics memes).
Iād like to share my own experience too. I think Haskell can benefit from a wider selection of targets and better cross-compilation experience.
Iām building a wrapper for a Rust UI library, and one particalur issue Iāve encountered is the build for Windows. As far as I understand, you canāt currently link with Rust neither statically nor dynamically on Windows. And Iāve heard you canāt link with C/C++ either, but not sure about that one.
I see Haskell as the perfect language for building UI apps. If the build for WIndows is fixed, it would be possible to compete with Electron and similar cross-platform solutions.
And if thereās a way to cross-compile and link with foreign libraries for Android, itāll be possible to compete with Flutter/React Native and others. Iāve heard that cross-compilation for Android somehow works, but failed to find any instructions how to do so.
The iOS target should just work on arm macs, at least from what Iāve read.
Iām already writing examples of building UI apps with Haskell. But itāll be even more impressive if Windows and Android are supported.
Our HTML and UI EDSLs are just that good, huh? Or maybe itās the ML syntax and builder-type monads.
Yes, the ML syntax is that great. Take a look:
The examples I ported from Rust to Haskell are roughly two times shorter.
Also, sorry for the ping, I didnāt mean to reply to your message. I wanted to reply to the thread, but pressed the wrong āReplyā.
monomer was incredible for me as well when I discovered it (but it takes hacking to run on Windows; itās held in place by GHC not handling Stack Protector properly on Windows).
The Rust examples show easily what goes wrong with FP in Algol-syntax languages, you get pyramid of doom really quickly.
Dunno, it might be worth looking around for people knowledgeable on the subject, and find some way of cajoling them into helping them on this subject. I absolutely agree with you that GUI on Elm model (until we find something better) in Haskell is incredible.
Thanks! Itās proposing to get there through incremental improvement by noting the sharpest edges and smoothing them off.
As someone who just spent a couple of weeks of spare time learning Haskell, there is a LOT of room to do this. I canāt think of any language that is as under marketed - Iād even say that Haskell is anti-marketed. Iāve never enjoyed a language moreā¦ Or been more puzzled about the way it is sold.
The huge win that needs communicating is that Haskell will let you code imperatively when there is no other way of doing a job, but it uses robust type checking to separate imperative and functional code, so the later canāt call the former and undermine its functional robustness and predictability. āImperative shell, functional coreā is big trend and Haskell is the perfect tool for it. Yes, there are a lot of other positives - but this one is easily understood and its one that people are currently interested in.
Something like Golang By Example would really help. Not a Haskell translation - I think there is one - but an equivalent for Haskell. A code oriented tutorial with minimal text that starts with simple functions, demonstrates lists and tuples, shows how to do IO and use record syntax. The sort of programmers the community should be aiming at most of all are too busy to read LYAH and donāt need that much handholding. Otoh, most of them arenāt used to coding in terms of recursion and tactics for doing so need discussing - mutually recursive functions, using an accumulator, etc. (Thatās about the limit of what I know - all stuff I learned from Paul Grahamās lisp book years ago.) Haskell the language isnāt really that hard: switching from loops to recursion is the gom jabbar of Haskell.
As for the anti-marketingā¦ One of the best things the Haskell community could do would be to remove at least 90% of its attempts to explain monads from the Internet. And to tell people that you donāt need to understand the monad laws to use Haskell any more than you have to understand number theory to perform addition. Just show people how to use Maybe and do basic IO and let them code for a while. The big message about monads should be that you can ignore them and write perfectly decent code - worry about them later when you want to get fancy.
Finally, re-brand. At the moment Haskellās brand is that its a language for mathematicians and that no one, no one at all, uses it in the real world. A friend of mine was shocked when he heard that there are production Haskell code bases of over a million LOC like Standardās. The image Haskell should have is that of the language for smart people doing innovative thingsā¦ With maybe a dash of glamorous moral ambiguity, because that always attracts attention. And given Standardās enormous fines for naughtiness, and the presence of Anduril and Blackrock funded startups, it would be easily done. āHaskell: The Official Language Of Evilā is a lot more likely to get people to google for a tutorial than āThe Language Of Math Nerdsā or āThe Language No One Uses.ā
PS I bet someone in the UK or EU could a grant to create Haskell resources - normally signatures from people with imposing academic titles go a long way in securing grant money, and getting those should be easy. Not huge money, but 20-50K.
They donāt use Haskell, but Mu. Which is a strict ādialectā, but with compatible syntax - how much and with which extensions I donāt know. So they actually removed the feature for Haskellās existence (thatās like Rust without the borrow checker).
Mu has a strict runtime, which makes program performance easier to analyse and predict ā but prevents us from just copy-pasting some Haskell libraries that rely crucially on lazy evaluation.
Iāve found this interview about Mu:
IMHO using them as an example for Haskell usage is a bit disingenuous.
I also find that funny:
We also have recursion disabled by default (simply because, unlike GHC, we have not optimised the compilation of recursive functions to avoid stack exhaustion) ā but we actually donāt need it all too often, and we have all the usual recursive combinators (properly optimised) anyway.
So, loops or gotos 
But really, they didnāt succeed to do tail call optimisation?!
From the point of view of selling people on Haskell, I wouldnāt make that distinction. Just say āA Haskell dialect.ā
Also, I think you mean that they removed lazy evaluation - and although it may be important to you, it doesnāt score highly in my reasons to be interested in Haskell, and I suspect most non Haskell programmers will feel the same way. The ability to use type checking to keep the functional core clean - thatās exciting. Ease of refactoring, expressiveness, yes.
Laziness: I donāt care at all. It might be important, I might love it later - but it wasnāt and isnāt a motivating factor for me to learn Haskell - even though I know what it is, which puts me ahead of a lot of programmers. Communicating with other people is about understanding what is important to them, not to you. People do things for reasons that make sense to them, not to you.
ā¦Which was a great Tom Baker Dr Who episode, to be fair.
This is a great post (though I donāt think I can fully agree with the part about embracing evilā¦).
One of the best things the Haskell community could do would be to remove at least 90% of its attempts to explain monads from the Internet. And to tell people that you donāt need to understand the monad laws to use Haskell any more than you have to understand number theory to perform addition.
Weāre trying! Weāve known about the āmonad tutorial fallacyā for over 16 years, and the only good monad tutorial predates that. Itās just a constant battle against the semi-informed comments that pop up on every HackerNews thread.
The sort of programmers the community should be aiming at most of all are too busy to read LYAH and donāt need that much handholding.
Totally agree. Itād be great to have something as comprehensive as the Rust book, but even a much shorter official guide to the fundamentals could do wonders. Aim it at experienced programmers, think of it as an on-ramp to something like Production Haskell, and display it prominently on haskell.org. I imagine the Haskell Foundation would love to spearhead something like this if they had the funding. Thereās no shortage of people who could write it, but itās a lot for a volunteer.
It is not only not important to me, Iād prefer a strict Haskell.
It is the feature which sets Haskell apart from all the other pure functional languages with type classes and higher kinded types and ā¦ but also one reason why it is not used more for real, big projects. So it is actually a sign of the failure of Haskell in the industry.
Isnāt a short guide something that could be broken into sections with each written by a different contributor? Iād suggest something like (examples suggested for code after --)
Simple functions, control structures including guard and pattern matching
ā square, product, fibonacci, factorial
Tuples and lists, including pattern matching
ā vector maths
ā split string
ā simple dictionary using list of tuples
Basic IO and Maybe: IO major FUD point because of memes, so hit early. Then turn into a positive by explaining how type checker will keep imperative and functional apart
ā hangman
ā markov chain (because widely used ākataā since Practice Of Programming)
Data, pattern match on constructors
ā fraction maths
ā the usual shapes example (very impressive to ex C++ programmers..)
Tutorial on tactics for recursion - must explain WHY recursion is a good thing too! In coder, not mathematician, terms
ā list examples
ā binary trees
Modules
Higher order functions
Typeclasses
Tour of stdlib - dictionaries, arrays
Concurrency
ā Life
Cool stuff you will be to do if you go on, suggested reading
I donāt think youād need more than that to get people interested, which should be the idea. Or perhaps more accurately, to debunk the Haskell memes everyone has been exposed to. Get people interested, then they can buy a book.
Most of all: donāt rewrite LYAH or the Haskell wikibook. The people you need to reach are busy and are more impressed by code than text. Golang By Example was perfect.
I think the critical aims should be to debunk the usual FUD and to give people those tactics to deal with recursion. Because the first of those is why people donāt try Haskell, and Iām very sure that the second is why a lot give up.
As the topic of documentation and especially authoritative entry level guidance was mentioned, e.g. in the form of a Haskell book, i was wondering if someone could ask the authors of Haskell Programming from First Principles if they would be willing to donate the booksā content to the Haskell Foundation, or the HF could invest money and buy this book into public domain. The book seems to have good quality, is beginner-friendly and covers very important topics for real world applications such as like MTL for application context (i would be hesitant to recommend effect libraries at this moment due to low ecosystem adoption) and error handling. This would be much more effective than starting from scratch, because from experience many such initiates loose steam quickly, because it takes more time and effort than on would think.
Regarding packages, maybe we can improve the documentation together: What packages need better documentation the most?
I played around a couple of years back with making something like this: https://haskell-docs.netlify.app/ , but lost momentum eventually. In general I agree that a community-made guide, headed by the Haskell Foundation, and linked prominently to haskell.org would be really valuable in terms of encouraging new people to engage with Haskell.
The real issue here is communityās aversion to discussing and documenting laziness, so most performance complaints come from people who accidentally chain a couple dozen million thunks for the first time in their lives. Outside of those cases, which can be profiled, itās quite hard to run into performance issues on modern computers, since you can always use concurrency (one of Haskellās strongest features) and/or FFI (tolerable).
The other side effect of said aversion is that laziness in general (i.e. data type spine-laziness) means a different thing from laziness in containers (whether library forces new values to WHNF for you), means a different thing from laziness in bytestring (whether a string is a list internally).
Itās pretty easy to look at the language in hindsight and say āwell obviously writing boring old functional code and making datatypes when I need them is the optimal way of programmingā, but any newcomer has like five years of investigations to go through to get to that conclusion:
A big part of the language is devoted to type-level shenanigans, though even if you manage to make something with them itās easily going to be the worst part of the codebase no matter what you do;
Effect systems donāt bring anything unique to the table, except perhaps dynamic dispatch;
Streaming is only necessary for specific tasks and would work far better as a module in base
Ć la Data.List instead of five ginormous libraries;
Lens solve the problem of managing disgusting state blobs, with a caveat that you donāt need disgusting state blobs to run complex programs;
Generics may seem like a great way to cut corners in serialization, until it inevitably turns out thereās a hundred ways to package any particular field in a record and that that company over there decided on a special mix of five in their brazen new JSON API.
I think Simple Haskell came from a gut-level recognition that thereās an issue here, and then it promptly failed to state anything beyond āwell maybe we shouldnāt bother making new thingsā. I donāt know what the correct answer is though, since merely stating āwe should strive to make libraries as powerful and composable as possibleā immediately clashes with the boring reality that the vast majority of people are A-OK compromising on application design if itās āthe intended way to use the libraryā.
That was the Haskell wikibook (and/or wiki) wasnāt it ? There have been other less successful attempts as well. Is there nothing to salvage from those ? How could a new attempt do it better ?
PS: This got me making an inventory: https://joyful.com/Haskell+map.
https://en.wikibooks.org/wiki/Haskell seems still the closest thing we have to a canonical free community-owned book. Whatās wrong with it ? Too long ?
shorter official guide to the fundamentals
I think itās not easy to write a short Haskell book. What would you include ?
