There’s nothing particularly methodical about what the author is doing here. Entire languages are dismissed on subjective criteria. If you have the same prejudices and predilections, you’ll find this useful. If you don’t, you won’t.
This sort of handwavey stuff belongs on HN, not here.
How would you go about it without being hand wavy? The author doesn’t have hands on experience with probably 95% of the frameworks he started with so he relied on subjective instead of objective methods.
Your second sentence is exactly my point. Collecting references to other people’s detailed experiences of various frameworks would be more useful.
Was thinking the same thing. Linux and MySQL are non-negotiable? Really?
Linux: probably yes. But MySQL … there is not single reason to not use PostgreSQL instead.
It is interesting to follow the reasoning of the author, but in my opinion he puts too much emphasis on the importance of choosing a framework. First, in some languages like Go, most people don’t use a “framework”. They just use some libraries. Second, one must decide about its architecture before choosing a framework. One major decision is to build a single page application or not. Some server-side frameworks are well adapted to SPA, some aren’t.
Haskell is pretty easy to learn. I’ve gotten about 25-30 people started, many of whom don’t have CS degrees or any degree at all. I think it was unfairly dismissed here.
I learned Haskell and I have no uni education.
My guide for learning Haskell is here: https://github.com/bitemyapp/learnhaskell
Haskell is pretty easy to learn.
I thought it was of reasonable difficulty to learn, but I suspect it’s because I had already been introduced to functional languages like Scheme and Standard ML. But that’s for me. I don’t know how anyone could say this about the rest of the world. Have you been on the Internet lately? Droves of people have said, “I tried learning Haskell but gave up. Three times.” And of the people who have learned Haskell, I frequently hear, “It took me several tries before Haskell started to stick.”
There is no other mainstream language that even comes close to being that difficult to learn.
And don’t get me started on monads. The amount of tutorials out there is evidence enough that people really struggle with them. I know I did. I think SPJ was on to something when he said we should have called them Warm Fuzzy Things, but I don’t see how that can account for all of it.
Now, there may be good reasons for this. Maybe it’s because most learn programming by gratuitously manipulating state, and so switching to a completely different paradigm is really hard. Maybe Haskell would be easier if it was the first thing people learned. But that’s just not reality.
For example, I’ve TA'ed my department’s Programming Languages course a couple times now, and we have to spend at least a couple weeks on writing simple recursive functions because our students haven’t had any experience with functional languages before that point. (And yes, that’s changing! But it takes time.)
Functional programming is hard for people to learn once they’re used to programming with state. I think this is a clear fact supported by the number of people who have tried and failed to use a language like Haskell productively. To pretend otherwise is to discount their experience. And that only compounds the difficulty beginners will have.
Haskell could be easy in some alternate universe where nobody knows how to program but everyone knows how to write a proof in discrete math.
That’s possibly a good universe to live in. Haskell is really simple from a lot of perspectives. It’s the case that the complexity layers nicely and ultimately it all fits together in a nice way. That’s a different kind of purity, purity of concept, that’s often been lauded in OO languages from Smalltalk to Ruby, though I don’t think it ever reaped the rewards it was expected to there.
But in a universe where most people learning Haskell already think in for loops and expect to get things done “in IO” without having to fight anyone, Haskell is tremendously difficult to learn. It undoes everything you take for granted and rebuilds your intuition from scratch. Post Haskell every other language looks ridiculous because of how many unexpected and complex liberties they take to build to their ultimate form.
The other place where I hear learning described that way is Boot Camp in the military. I don’t think anyone ever describes Boot Camp as easy. Valuable and transformative, absolutely, but the furthest thing, actually, from “easy”.
Well… Yeah. I admitted as such. But I think it is just reasonable speculation.
Haskell is really simple from a lot of perspectives.
Well, sure. But bitemyapp clearly disagrees.
Post Haskell every other language looks ridiculous because of how many unexpected and complex liberties they take to build to their ultimate form.
I will never understand this attitude. Haskell is not the One True Language. I certainly don’t think this way. There are plenty of non-functional simple languages that I love to work with.
You are not the first Haskell programmer that I’ve heard say this. But I suppose, it goes both ways. I hear plenty of people denigrating functional programming as something just for academics. They declare victory with OOP.
First, to be clear, I’m not disagreeing with you.
To clarify why I think that about Haskell is that I think constructing effect bases atop a pure foundation is such a powerful tool for understanding the semantics of other languages that it transforms the way you envision semantics at large. This is the promise of monads, at least how Moggi envisioned it I think, and I think they accomplish it wonderfully.
As a minor side-note, I don’t think there’s really a division between FP and OO. I think FP embeds most of OO easily and in a very conceptually pure fashion: existentials and modules and ambient state are wonderful. It’s also really, really great, for instance, to learn the lens library and then read Meijer’s “The essence of data access in cω: The power is in the dot”. It makes it really clear where Meijer has taken conceptual shortcuts for accelerating common use cases at the expense of simplicity.
So when you learn Haskell you become exposed to a massive, conceptually clear semantics sandbox. It’s a little bit like how Lisp programmers become exposed to a massive, conceptually clear syntactic sandbox. It’s not true that living in a sandbox is necessarily the best way to get your work done, but it will make you painfully aware of the tradeoffs made in other languages' syntax/semantics. You’ll want to feel that they were poor choices because in your sandbox all of the choices are so much more obvious (and this is true).
That’s when the most fun begins. Determining when some of those choices are actually expert opinions made under the weight of a different value judgement and then beginning to understand the art in that is a big step forward. I see that with Comega, for instance. I still think it’s a horribly kludgy language compared to Haskell (or F#) but I understand why those kludges were selected.
As a final note, I think that this point of view becomes depressing because a lot of languages were simply not designed with much intentionality. When you examine those design choices you tend to see them as complete losses instead of careful decisions between two well-researched options. That POV can be infectious.
I think that’s a perfectly reasonable stance to take.
The problem is with your language. Allow me to quote it again:
You leave no room for reasonable people to disagree. What am I to think? I love writing Haskell and I’ve produced usable open source software with it. But I still very much enjoy using other non-functional languages—languages that I believe are well designed and simple. So now where do I stand? Either I haven’t reached your plateau of enlightenment or my perception of other “less enlightened” languages (like, Go, for example) is just flat out wrong. If isn’t clear, I reject both of these conclusions.
Given the absolute ruthlessness with which others here have expressed similar thoughts (FP is the One True Paradigm and everyone who doesn’t think so is either a blubbering idiot or just hasn’t been enlightened yet), the language employed here definitely touches a nerve.
I think that this point of view becomes depressing
Why do we have to be all melancholy whenever someone tries to do something different than the One Way We Think Is Correct? I completely reject this notion that there is one good way to solve problems. Not everyone wants an extremely strong, expressive and safe type system all the time. Maybe you don’t work that way, but rejecting the experience of others makes it difficult to have constructive discussion.
I apologize if I’ve read too deeply into what you said, but if you read my conversations with bitemyapp, I hope you’ll forgive me.
Yeah, it’s alright. I’m being gestural instead of fair and accurate, so the response is warranted if not exactly in line with what I’m trying to say. (I wrote a similar, more accurate and fair response at length a while back: https://lobste.rs/s/h9vu5h/what_to_know_before_debating_type_systems/comments/oinwwc)
I don’t think those feelings are ultimately correct, but I do think they genuinely exist. I also think there are many definitions of simplicity. I tried to emphasize that conceptual clarity is at a max for Haskell and that this provides certain kinds of affordances.
I personally would like to see all languages have semantics derived from type theory as I think it’s a much more firm place to stand than the operational stories you usually learn. I think the operational stories are still great, though, and operational simplicity is another kind of value with its own kinds of affordances. I don’t think it’s impossible to have both conceptual clarity and operational simplicity, though it requires the kinds of tradeoffs that are very difficult to make. I really admire the C# team for trying to do that.
I think the depression I aimed at is much more around something like PHP. I think it’d be hard to argue that the tradeoffs made with PHP were done with a great deal of foresight or thought. The value PHP expresses to me has always been speed, and as that value fades what’s left is “depressing”.
To take a counter-example, Lua is a language with a similar semantics as PHP but with much, much greater design. Its operational model is crystal clear and clean.
I’d love to see an experiment like Hack performed atop Lua as well. I think that “hybrid” typing information could illuminate a lot about the semantics of both languages. I would believe that the information found about Lua would be more compelling at the end of the day.
I personally would like to see all languages have semantics derived from type theory as I think it’s a much more firm place to stand than the operational stories you usually learn. I think the operational stories are still great, though, and operational simplicity is another kind of value with its own kinds of affordances. I don’t think it’s impossible to have both conceptual clarity and operational simplicity, though it requires the kinds of tradeoffs that are very difficult to make.
Yes! Now we’re getting somewhere. I like this divide.
I would absolutely agree with your assessment about PHP and Lua. I love Lua! The language itself is extremely small and orthogonal. It’s exceptionally well designed. (Bonus: I got to share an afternoon with Roberto Ierusalimschy last year where we talked about his wickedly clever implementation of closures. As someone who writes a lot of Python, I am envious of Lua’s closures. None of this nonlocal cruft. :-))
Yeah, I’m not actually a language zealot that much. I just play one in conversation from time to time. That closures paper is on my reading list now, btw.
A real question I’d like to ask—and I think is being asked directly elsewhere—is whether or not learning a pure language gives you important tools to be more sensitive to tradeoffs in language. I’m certainly more prepared today to go and read a paper describing the denotational or operational semantics of the languages and comparing them thanks to exposure to Haskell/ML/Agda, but that’s not immediately an improvement of understanding. I also find that I tend to use a big monad stack as my mental model for really diving in on how other languages behave.
As a follow up question, I think it’d be interesting to see how learning something like type theory improves someone’s ability to learn languages. I know that my intro to programming class had more to do with teaching people how memory worked or what pixels were and thus totally failed to give someone the tools to tackle formal languages well.
Great insights. I had a really great PL professor who really tried to impress upon us the importance of operational semantics and how it can be used as a tool to understand the real details of how languages work. (We even got to write meta theoretic proofs to prove properties about languages for homework.)
It has definitely helped me learn languages quickly. It provides a conceptual framework with which to understand features under a different name. Old wine in new bottles, so to speak.
It’s pretty easy to write a bad Haskell tutorial, but that doesn’t mean Haskell is intrinsically difficult.
I’ve personally witnessed how, as I’ve improved the lesson plan and process over time, it gets vastly easier and faster for people. This has come from rapidly iterating the lesson plan and developing coherent and thorough understandings (as a teacher) of the material being taught.
It’s very difficult to do a good job of teaching something you don’t totally understand yourself. Just look at math education in the US.
It’ll never be trivial, if only due to unfamiliarity of things like recursion (as you mention). Doesn’t have to be something 90%++ of the population could be taught though.
People used to think universal literacy and arithmetic was impossible. It wasn’t, but we had to work on how we teach other people and take the subject matter seriously.
And don’t get me started on monads.
20 shitty explanations of monads by people who didn’t understand them doesn’t mean monads are hard to understand or explain. I’ve had very little trouble explaining monads once I’d gotten some experience on how to properly teach them. The monad tutorial meme is a running joke in the Haskell community. Nobody believes they’re hard to learn, just unfamiliar and obscured by very poor tutorials. People with a 10% complete understandings (of anything) are too eager to write blog posts. I have been guilty of this too.
I think this is a clear fact supported by the number of people who have tried and failed to use a language like Haskell productively.
Er, not quite. If I throw a copy of Ulysses at a toddler and they don’t learn how to read and write just from that, it doesn’t mean learning to read and write is impossibly, intrinsically difficult. It means the pedagogy needs vastly improved.
Functional programming is hard for people to learn once they’re used to programming with state.
I don’t think anything is ever going to change the fact that step-by-step imperative instructions is going to come naturally to a lot of people, especially those without a mathematical background. That doesn’t mean we should use imperative languages. Designing for triviality and the bare-bones beginner is folly.
Similarly, we drive cars not by walking on simulated sidewalk but with steering wheels, pedals, and shifter sticks. I’ve had people tell me they could “never” learn to drive stick, which is clearly bollocks given the many countries where it’s majority stick-shift. If you were 16 and learning to drive stick was between you and being able to drive, you’d learn it.
I’ll be expanding my Haskell teaching from the ~30'ish people I’ve gotten started over the last 6 months to in-person classes soon. I’ll let you (and everybody else on lobsters) know how it goes.
People used to think universal literacy and arithmetic was impossible. It wasn’t, but we had to work on how we teach other people.
You claimed learning Haskell was easy. I pointed out that the sum total of evidence clearly suggests otherwise. My evidence is the pile of tutorials and the droves of people stating how they’ve tried over and over to learn Haskell, but have failed to be productive with the language. This is a ubiquitous sentiment from programmers I know and respect.
I did not say learning Haskell was impossible. I did not say it could not be taught. I did not say that one bad tutorial means things are hard. In fact, I did not even claim that any tutorials were bad. I merely pointed at the sheer number of monad tutorials as a clear suggestion of the fact that people have a lot of difficulty learning them. (Many people write about things they don’t understand precisely to get an understanding. When one teaches, two learn. So the number of tutorials could be a reflection of people clamoring for more, and/or it could be a reflection of people not quite understanding them, and so they seek to try and explain it to others.)
If you absolutely insist that learning Haskell is easy, then I must insist that learning any other mainstream language is downright simple. Child’s play, even. I’m fine if you want to move the goalposts, but let’s call a spade a spade.
Nobody believes they’re hard to learn
Maybe that’s the problem, then. Dismissing this by saying they are “just” unfamiliar is missing the point. If something being unfamiliar makes it hard to learn, then guess what, it’s still hard to learn!
You are straw manning my rebuttal. You said learning Haskell was easy. I contested that using evidence that clearly suggests that people have a much harder time with Haskell than with any other language.
Maybe a reason for that is bad pedagogy. That’s certainly possible. But that doesn’t change the simple fact people have a ton of difficulty learning Haskell.
You’ll note that I’ve made exactly zero claims about things in Haskell that make it hard to learn. Instead, I’ve cited my own observations of people that struggle with it. (I did mention monads, but only in the context that there are so many tutorials written about them, which suggests a lot of people still aren’t understanding them easily.)
I’ve suggested that perhaps Haskell is difficult to learn because people are used to programming by manipulating state. I said this to explicitly acknowledge the fact that it may not be Haskell’s fault that it’s hard to learn. Nevertheless, it’s hard to learn.
That doesn’t mean we should use imperative languages.
Your writing style is insufferable. I never said we should. (I have no strong opinion on the matter. I see neither paradigm as intrinsically better. I know you do. But good god man, can we not go down that path again? We got nowhere fast and it’s utterly irrelevant to my point here.)
Yes, please do. I suspect we will all benefit from it.
I contested that using evidence that clearly suggests that people have a much harder time with Haskell than with any other language.
Haskell won’t let you run wild quite as easily (still can happen) without knowing what’s what. You think it’s “easier” to teach Java, it is not.
I can trivially demonstrate that almost anyone that thinks they know “Java” doesn’t. I can further demonstrate that it’s easier to write code in Haskell that makes sense.
For a preview of what I’m talking about, compare the Haskell Report with the JLS
Yes, lets talk about what’s simpler and easier to understand.
Most imperative language avoid the problem of learning by letting people lie to themselves and to each other about what their programs are doing and produce things that limp along on half-understandings.
Because learning new things or knowing what you’re doing is orthogonal to propagating this product (Go, Java, MongoDB, etc) you need to market so you can capture hearts and minds for your technological empire.
Anyway, updates to come on what teaching Haskell in person is like.
I find it incredibly difficult to have a constructive discussion with you. The language you use is borderline inflammatory and overtly condescending.
What I can observe is other peoples' reported experience. In Haskell’s case, a significant number of people have great difficulty employing the language productively. For all practical purposes, this makes Haskell difficult to learn. End of story. It’s that simple.
It is with great comfort that I note that those advancing the state of the art don’t share your attitude.
Originally written by bitemyapp:
It is with great comfort that I note that those advancing the state of
the art don’t share your attitude.
It’s an observation. Not an “attitude.”
It grows ever clearer that you have no desire to rid your writing of its condescension.
(I guess publishing research software built with Haskell, including an Experience Report in ICFP 2012, doesn’t count as advancing the “state of the art.”)
@burntsushi, I searched for your experience report, found it and read it!  It’s a really interesting piece. It gives a good overview of the strengths and weaknesses of a pure lazy functional programming language like Haskell in the context of your project.