It's interesting that we've known results such as these for 30(+) years, yet 99.999% of all software is still written in outright miserable languages such as Python or Javascript...
Interesting take on the paper. From my perspective I’d say that developing this wouldn’t take 8 hours in python or JavaScript, but it might just be a preference thing.
These days I’d be surprise if asking Copilot to start the product wouldn’t cut of the equivalent of 6hours of the Haskell development time.
It's not Haskell, but you can write great functional programming code with Javascript. I think it is very ergonomic for FP. Remember that Javascript is the world's most misunderstood programming language =))
As much as I appreciate the FP features of Python, I much prefer a language that enforces immutability. Constraints like that make the code easier to understand, reduces the number of possible bugs.
At this stage in my life, when I'm beginning to give up on immutability being taken seriously, I'd almost settle for proper immutable collections being provided alongside the mutable ones.
I really just want to combine Sets and Maps the way I combine numbers and strings.
I don't think you can be surprised that Python or Javascript are more popular than Haskell. Just the monad thing rules it out entirely.
I would say ML might have been a more popular language, but again it's just a bit too weird for people that aren't deeply into academics / PL research. Also the tooling is just bad, even to this day. (Tbf that is true of Python too.)
Monads aren't weird. Basically it's data structures you can map over and flatten, like a list or a maybe/result/option. Everyone who isn't extremely junior knows about them. There's some theory that ties into formal systems and blah blah blah, but you sure don't need to be janking your monoid in public to understand and use monads.
As for tooling, few people actually want immersive, robust tooling. If that was popular things like Pharo and Allegro wouldn't be niche. Most want crude text editing with pretty colours and not much more.
Says everyone after having spent months getting the hang of it and more months writing blogs about how everyone is wrong to think it’s difficult because when you think about it “ A Monad is just a Monoid in the Category of Endofunctors”
It’s incredible just how blind most programmers are to the time they spend on learning things to come to the point where they think a subject is simple and how they all assume that any junior should just listen to their magical recital of a boiled down explanation and immediately understand it at a fundamental level.
If they were called "flatmappable" (which is essentially what they are), people wouldn't complain so much about monads. But in Haskell you have to bend over backwards just to set a variable you think should be in scope, or to log something to the console, and monads are involved in achieving that kind of things.
Haskell is hard - monads in themselves not really.
Yes, if only people called it something different. Quantum mechanics similarly immediately understandable if you just call it mechanics of discrete amounts. No need to read a lot of books, do a lot of math or calculation. You now know quantum mechanics at a fundamental level because I have told you the magical recital of a boiled down version. I’ll get back to you with a link to my blog explaining why university courses on the subject should just be replace with a picture of a cat and my magical phrase which will have the same effect.
Honestly do you not even see how naive this idea is that the only thing standing between a subject that literally everyone spends a ton of time on getting good understanding of is a renaming or a catch phrase? Even people who read tons of blogs of “actually it simple just…” end up spending time getting to know it. And every one of those people writing those blogs spent a ton of time on it which is why they are writing blogs about their “eureka moment” that will forever make the subject and instantly learned matter.
There are so many things in programming that are hard to grasp at a deep level, but don't look scary to beginners (who misuse them without realizing). Monads look scary so they take all the blame. I'm not really proposing this, but I guess if monads were called something like "flatmappable", the focus would perhaps shift to the more difficult parts of Haskell: at the root, immutability and purity, and on top of that, the deluge of abstractions and ways to compose them. It wouldn't make Haskell any easier... it would just save the poor monad all the bad rap.
The weird thing is the word monad and the technical formalism. Practically speaking, I really don't see why I decent junior can't understand
x = [1, 2, 3].flatMap(el => if (el % 2 == 0) [] else [ el ]) // x = [1, 3]
vs
x = []
for (i = 1, i <= 3, i++) { if (i % 2) == 0) x.push(i) } // x = [1, 3]
or some such. There are advantages and disadvantages to either style of programming. I actually don't like pure functional or imperative style because of the respective tradeoffs each make (functional style requires either significant runtime overhead or heavyweight compiler optimizations and imperative gets messy very quickly and is typically difficult to reason about as program size expands).
The problem is, that's not "monad"; that's the implementation of the monad interface specifically on an array. That's like claiming to understand "iterators" because you understand how to write an iterator implementation on an array, but then trying to take that understanding to an iterator that yields the primes in order. If you think "iterator == presenting each element of an array in order", and nothing else, you don't actually understand iterators, because presenting each element of an array in order is an iterator, not the concept of iterators. "flatMap" is a monad, it is not the concept of monad.
I don't understand shit about the formalisms and I don't care. If you look at my posting history you'll notice that I'm a very uneducated, very crude programmer.
This kind of data structure is like the next step after learning how the scalars work.
It's a claim that monads are somehow supernatural, twists of reality, which is obviously not the case since a lot of people who have never learnt the word monad are using them daily in the form of Optional style types and lists and so on.
so many people are enchanted by quick results.. it’s the same psychology as that of enchantment by LLMs.. and they exert the same pull as tiktok reels.
you get results, who cares when they have no correctness tying them together.
Monocole-wielding elitist opinions like these scream to me very low productivity environments that would spend weeks on reinventing the wheel rather than getting to market fast.
I love and practice Haskell, but anybody thinking that technologies like these are fit for fast moving startups are absolutely delusional.
You can easily setup a monorepo and release quickly mobile/native/web/apis and whatever with excellent editor and ecosystem support in TypeScript, good luck achieving that on alternative languages.
Last but not least, 99% of people like you criticizing JavaScript have never seen what kind of great goodies there are in the ecosystem, even for writing pure functional programming that scales, e.g. with Effect-ts[1]
Okay, since you made quite a good argument, I will give you my counter.
The primary problem with JavaScript is that one, the entire ecosystem is prone to breaking. It is a very brittle system.
Next, TypeScript gives you an allure of safety, but at the edges it breaks down because underneath it, it's all just untyped JavaScript.
And the last and the most important one is because it makes it so easy to wrap functions in each other and there are no patterns at all, there is a lot of indirection in most typescript code bases.
This causes API surface area bloat which becomes hard to maintain in the long term.
And tooling doesn't completely solve for this problem either. I have seen code bases where the LSP struggles because of tons of generic types.
I think the most pragmatic alternative is Golang if you are building APIs.
And for a full stackish framework Phoenix and Elixir is a great choice.
Or you can just go all in on Rust like my companies and you get the best of everything.
The issue isn’t the quality of libraries, and as you said, there are nice ones out there. The issue is the churn and dependency management.
And as for fast moving startups, the most important factor will always be the problem (and it’s myriad sub problem) and hiring. Selecting a language is dependent on those.
No, PG advocating for Lisp because he has had a good experience with it 30 years ago is not a "good reason".
Build a tech team around lisp in your startup then task somebody with scraping a website or handling session tokens refreshing and see the results.
At some point people should ask themselves why there's so little killer software written in Lisps or pure functional languages (besides extremely rare exceptions like Emacs or Datomic) when modest and much hated languages like PHP have plenty.
> scraping a website or handling session tokens refreshing and see the results
Have done this task at work - taking a Java crawler and modifying it to be able to navigate saml-based auth.
It's the goddamn pervasive mutation that kills you everytime. The original author will make assumptions like "I can just put my cookies here, and read from them later". And it works for a while, until you add more threads, or crawl different domains, or someone attempts some thread-safety by storing cookies in shudder thread-locals.
(This was actually the project that convinced me that I'll never be able to diagnose or fix a race condition with a step-through debugger.)
I was so fed up with this task that I whipped up a Haskell version at home. I then used that as a standard to test the Java work crawler against - by comparing mitmproxy dumps. If the Java version didn't do what the Haskell version did, I hacked on it some more.
