Having harshly criticized Haskell before, now I feel compelled to defend it a little.
See, every language has a feature that is terribly abused because it’s the cool, clever thing in the language: (…) monadic everything in Haskell
Every higher-order language with strict evaluation implicitly uses monadic style, including every object-oriented language. Why is monadic style particularly bad in Haskell? Monadic style does have shortcomings, chiefly among them, it doesn’t even attempt to make imperative programming more tractable. But, what it does (describe and delimit the existence of effects), it does very well.
My impression is the author said “monad” to mean “abstract nonsense” instead of “procedural program.” Though he’s right that people do write too many procedural programs in Haskell :).
If what he finds distasteful is too much abstraction, he could have said “overly abstract” or “unnecessarily abstract”.
By the way, I empathize with this feeling. Abstractions have to justify their presence on a benefit/cost basis, just like everything else. In particular, sophisticated abstractions have to justify their presence with sophisticated applications.
When I read a few Haskell books, circa 2008-2010, monads were all the rage. You had to have a Reader and a State in your program! Real World Haskell made the most sense.
I was thoroughly flummoxed by trying to write a program which makes an HTTP request and parses a JSON response. In retrospect this was not a great beginner Haskell program to write. Too much type system wrestling for me, at the time.
I still think isolating one’s state changes into specific kinds of buckets is a great idea. But, I think other languages have since packaged it more accessibly and pragmatically than Haskell does.
As my parent comment implies, I don’t like Haskell much. But, if there is one thing I wish my favorite language (Standard ML) could borrow from Haskell, it’s precisely the ability to track effects with types. What are those more practical alternatives you are thinking of?
My favorite is at the end:
The Majestic Monolith doesn’t pretend to provide a failsafe architectural road to glory. That’s a fool’s errand. Many programmers suffering under many oppressive influences will turn any architecture made with any tool into a big pile of mud.
IOW the Rails Way will get you started down the road, but eventually you’ll have to choose the right forks in the road. As is the way with any technology, no matter how much it turns its nose up at Rails :p.
So one thing that could differentiate this from a uninformed rant is a link to a well implemented REST (as they decree it) interface that I can play with that uses JSON Schema, HTTP/2, content-types to make a multiplatform, multilingual app that serves ~ 1.44 billion users monthly.
I don’t think a response of, effectively, “shut up until you have billions of users, which will authorize you to talk” is a very reasonable reply. I don’t even particularly agree with the linked criticism, but imo it’s pretty anti-intellectual to say that they can’t criticize Facebook’s architectural choices unless they first build a successful competing product.
Yeah, I almost left off the users figure when I wrote this offhand critique, since it’s immaterial to the quality of the ideas of relay, graphql, react, etc.
“I shall not today attempt further to define the qualities I understand to be embraced within a REST API; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the API involved in this blog post is not that.” - programmers
On the one hand, I kind of agree with PPK here.
On the other hand, perhaps we’re just old curmudgeons. The features we wanted are there, so it is time for these damned kids to stop changing things now.
On the other other hand, Navigation Transitions really do sound dumb, given that if you want to do that sort of thing it is pretty easy to do with HTML5 ‘single page’ apps and any number of existing JS libraries.
Part of PPK’s argument here is that browsers should cede the “low latency/high interactivity” ground currently held by native apps entirely and focus on being document viewers. Transitions are a great example: they make no sense for hyperlinked documents, and all the sense in the world for building natural interactions.
IMO this entirely misses the leverage of web browsers. To paraphrase Churchill, web browsers are the worst cross-platform application platform, except for all the others.
web browsers are the worst cross-platform application platform, except for all the others.
This presupposes that cross-platform application platforms are the solution to our problems.
There was a time when Java was in the same position, with the same rationale. After a lot of wasted effort, we seem to have moved on and multi platform java is mostly history.
I’m not just presupposing that, I think its axiomatic. Who wants to spend time porting applications and services between platforms when they could be doing anything else?
It might make the developer’s life easier, but it is pure shit for the users. In the case where the users are developers, well OK, sure. But in the general case, something that makes my life better at the expense of the people who need to use my software is 100% a non-starter.
Pure shit for users? I don’t know, seems like quite a few websites nail the whole cross-platform problem pretty handily. When’s the last time you saw someone complain that <insert website here> doesn’t work on <insert browser/os here>?
When’s the last time you saw someone complain that <insert website here> doesn’t work on <insert browser/os here>?
I make this complaint regularly, if not daily. Scroll hijacking is a common issue. Every browser supports “native” scrolling, but that’s not good enough. We need “cross platform” scrolling in JavaScript. And it’s pure shit.
Two things struck me:
Overall, a very level-headed and honest-sounding look back.