> ...too often act like ivory towers...
I 100% agree with this. The Haskell community as a whole and various tutorials etc., aren't optimised for a new comer.
For instance, you don't see a "stand up a web app in Haskell in 10 minutes" tutorials. Historically it may have worked in Haskell's favour to slowly induct learners, but in this age where languages are fighting for mind space I don't agree that's a good approach anymore.
Simon Peyton Jones (SPJ), an earliest and a famous champion of Haskell coined the phrase "avoid success at all cost" in a certain context which may have had some role in making Haskell seem Ivory Towerish.
A language, like any living being, needs to adopt to survive and thrive. It's unfortunate to see Haskell remain a niche language even after close to 3 decades.
> and that simply is not how my brain is wired.
This, however, I disagree with. I mean in a general sense, not specific to how your brain is wired. It all depends on the first couple of language that one learns and how they are learnt and taught. 10-15 years ago people would find it hard to grok Python's functional concepts. But as it began to be taught as the first language in universities and those graduates join the working population you see how it's super natural for them to grok Python.
That must be the reason why Edsger W Dijksta once stated [0]:
> "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
... and ...
> "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."
... and ..
> "APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums."
I must be one of those mentally mutilated programmers with no hope of regeneration :)
---
[0]: https://www.cs.scranton.edu/~mccloske/dijkstra_quotes.html
I include myself. It has been a definite struggle to onboard functional concepts and solve problems in a functional style. Just doesn’t come naturally.
Why do you feel the need to denigrate people who are experienced in imperative and/or object-oriented paradigms?
If there is any paradigm that holds its own value, why not praise the value it adds instead of resorting to nothing but ad hominems?
I mean, if something was so unequivocally better then wouldn't this perhaps resulted in a massive adoption rate, and name-calling wouldn't pop up so frequently? But no, the popular thing to do is to just denigrate those who haven't jumped into that particular bandwagon.
That's not what we see happen in life. Just look at how dearly we hold on to coal plants. My country's energy is 90+% coal-based and there is an insurmountable opposition to atom, and great suspicion against solar (government recently started financially deterring against mounting solar panels).
What a non-sequitur. Adopting a programming paradigm in the code that we write on a daily basis has rigorously zero to do with the infrastructure cost of switching energy sources.
This non sequitur about coal plants is even more absurd and ridiculous once we factor out the fact that the world is already moving away from coal to renewable energy sources, which is quite costly and resistant to change and subjected to an awful lot of special interest groups, and yet during that timeframe people still chose not to bother with functional programming fundamentalisms.
If an idea is good then it holds its own against alternatives. Even in their pet projects people tend to not even bother with pure FP frameworks. While hundreds of millions of euros are being spent on wind farms, people like you and me don't even bother spending a few minutes to get a hello world going with Haskell, even though it's effortless and trivial. Why'd you think that's happenin?
Yeah, over a long time it will certainly happen that a good idea will manifest itself. But that process can take a long time, centuries even.
Let's not forget that there are commercial interests for keeping certain languages down and pushing languages up. There are huge companies like Google, Facebook, ... pushing for languages (and frameworks).
It's often easier to stick to something existing because change requires effort. And I think that's why coal was mentioned - it's easier to stick to it than to switch to something else, so it will take time but eventually it will happen.
He really isn't, and the blatant attempt to poison the well is a clear indicator of the lacking arguments.
I repeat: people don't even bother spending a few minutes trying to get a pure FP hello world going. Zero barriers to entry, zero challenge, zero resistance.
But in spite of the lack of any obstacle or challenge, pure FP fails to present a value proposition that justifies even a five minute effort from pretty much anyone.
> Yeah, over a long time it will certainly happen that a good idea will manifest itself. But that process can take a long time, centuries even.
This baseless assertion holds no water in software development. It does not take a multi-generation epifany to convince someone to use pure FP. All it takes is a single person willing to invest it's time.
But still, those who do invest their time with ivory tower tests don't see value that justifies pursuing any effort, and thus don't bother pushing it anywhere beyond a cursory test.
Why is that?
> It's often easier to stick to something existing because change requires effort.
This assertion holds no water at all, as pure FP frameworks exist for decades and still people do not bother with them. Why is that? And how can you hold such a cognitive dissonance of claiming something is so great and yet it does not exist in practice because no one ever bothered to take advantage of such greatness?
Also, are we supposed to pretend that even Microsoft offers pure FP languages that integrate with their .NET stack and still no one bothers with it at all, even when they can even contam it's use to very small and self contained modules?
The truth of the matter is that pure FP fails to gather at attention beyond navel-gazing ivory tower types because it quite blatantly fails to present a value proposition. That's the core of the issue. I mean, languages like Rust are increasing popularity like wildfire in spite of it's radically different and restrictive take on resource management because it presents a clear and inequivocal value proposition. But pure FP frameworks, in spite of having a head start of decades and a foothold on dark corners of academia, fails to convince the public that it's in their best interests to even peek in that general direction. Why is that? Do we really need to resort to absurd conspiracy theories to get an answer to that question?
First, FP required/requires more resources on average. With time progressing and better hardware coming, this point becomes less important.
The strengths of FP, such as easier concurrency, are becoming more relevant as well.
However, even universities take time to "catch" up. And developers often stick to the style they first learned (or a similar style at least). In addition, they already created and invested into an ecosystem.
But look at all the new programing languages that are getting created. They include more and more FP features, starting with the more easy ones that have a direct impact on productivity (such as lambdas) but it's getting more and more. Even languages such has Java start to slowly move into this direction.
Or do you want to deny that?
Also, I have no idea what you mean by "FP frameworks".
there is no govt forcing/de-incentivising functional programming afaik...
Carpenters don't learn "hammer-oriented" building, or "saw-oriented", "screwdriver-oriented", "chisel-oriented", or "glue-oriented". They learn to use hammers, saws, screwdrivers, chisels, and glue, and use them all at different times, sometimes one more than others. Machinists don't learn "lathe-oriented", "drill-oriented", "mold-oriented", or "welding-oriented" fabrication. They do all or any of them strictly according to what they are making, and what they are making it out of.
"This-" and "that-oriented" is a entirely a sales method used to package up coursework and seminars. It is as utterly stupid to design a whole language around one of them as it would be for a carpenter to try to run a screwdrivering business. A language is useful exactly to the degree that it enables building whatever you might be called upon to build.
That is not to say any generally useful language is equally good for any purpose. Wood is better for some products, metal for others. A metal violin would be weird, a wooden gun action would be stupid. But violins often have metal bits and guns often have wood stocks.
Elitism and gatekeeping do precisely nothing to help people solve problems with code.
They are indeed, aren't they?
I mean, they straight up sound like bullying those who happen to not think alike or share the same opinion.
Those who are in the right are able to form rational arguments, raise concerns about specific problems, and offer solutions. But no, not in this case. The only reason for anyone to not be a diehard supporters of the author's point of view is that they have mutilated minds and are coding bums.
Don't we take things a bit too serious these days? I've started programming with BASIC and I find the quotes kinda funny - I don't take it too serious and I am not sure if Dijkstra was being dead serious here either. For example: would anyone really think Dijkstra was in favour of locking COBOL teachers behind bars?
I agree that this self righteous fake outrage targeted at those who point out bullying and abuse gets a bit too tiring, and adds nothing to the discussion.
This is a very good example. Calling out the lack of rational arguments or any reasoning regarding a technical subject, and resorting to abuse to fill the void with ad hominem and bullying, is expected to be addressed with explanations on the technical merits of the original proposals.
But no, here we are wasting time with chatter that boils down to "why aren't you ok with being subjected to abuse? Don't we need to roll over and shut up when someone throws ad hominems?"
I guess we don't? But it seems that some people whine when they can't take what they are dishing out.
I agree 99% here. The 1% is where you want to shock someone to break through. Not sure if that was Dijkstra's intention, but I assume it was. He was a teacher as well, writing books, giving lectures. I think he was genuinely concerned.
Unfortunately, elitism and gatekeeping "solve problems with code" indirectly, by keeping inadequate people away from developer roles where they would make problems worse with negative-value contributions. Software mistakes are common and expensive: there are very strong incentives to predict and prevent them by following processes and by putting someone competent in charge.
It is of course possible for elitism and gatekeeping to select the wrong sort of people (for example, not recognizing terrible people outside a manager's area of expertise), but even intolerable toxic attitudes (e.g. hiring graduates from certain universities) can effectively keep away dangerous people.
If there are people who are inadequate at writing code and architecting software, then they should:
- not manage to pass their university classes and not get a degree or a programming qualification
- not manage to pass their internship by generating some value and proving that they're capable of learning and self-improvement
- not manage to get the necessary certificates for a particular technology, as a vague proof of basic competency
- not manage to solve the take home tasks that they're given by a company that's about to hire them or pass technical interviews
- not manage to pass onboarding for some months and therefore should be fired
- not manage to deal with their duties as a developer and therefore should be fired
Furthermore, the difference is in attitude - if a person doesn't pass one of the above, they can probably just upskill themselves and spend more time refining their craft, reading books, working on projects etc., whereas dismissing them entirely is likely to demotivate them and so they'll never achieve anything. It might also be selecting for the wrong types of people - those who simply brush off criticism like that and don't care, as opposed to those who are more sensitive, something that should hardly matter in regards to developing code.
There has to be a better and more constructive way of criticizing people and even dismissing them: for example, saying "Hey, your programming knowledge seems okay, but you should work on your system design skills. Try applying for a job in a year again," vs simply ghosting them.
> Software mistakes are common and expensive: there are very strong incentives to predict and prevent them by following processes and by putting someone competent in charge.
Lastly, this feels like the job of:
- the compiler, for errors and warnings
- the IDE and language server, for general suggestions
- the linter, for code style rules
- static analysis tools like SonarQube, for additional code checks
- testing frameworks (including code coverage gates), for unit, integration and end-to-end tests
- manual code reviewers, after everything above has been resolved by the code author
- QA specialists, after all of the previous checks have been successfully passed
"Evaluate the expression on the right of the = sign and make this the value of the variable on the left."
I'd like to argue on how reasonably simple is simple enough. If I need a carpenter to build a stairs I'm my house, I would expect a good carpenter to know and use all the tools appropriate, no matter how complex. Of course, most things are doable with just a hatchet just fine, but I d expect a professional to choose a hatchet because it's better, not because they never bothered to learn proper tools.
So whenever a language puts "easy to learn" as their main feature, I see it as a guide "how to build stairs with just a hatchet".
There's now the IHP framework that allows you to build haskell web apps in like 10 minutes. If you're curious, check it out: https://www.youtube.com/watch?v=UbDtS_mUMpI It's been called "Haskell on Rails", and for good reason.
"avoid success at all costs" is usually meant to be parsed as "avoid [success at all costs]" i.e. don't compromise the language just to make it more popular.
This phrase is often misunderstood, it's "avoid, success at all costs", not "avoid success, at all costs". In other words, don't optimise for mass market adoption at the expense of everything else. Languages that have arguably done so, have ended up as extremely complex and ridden with corner cases.
It's easy to follow a rule too far and end up way overcorrecting the original problem. What I like is that both meanings balance each other :)
Some popular mass-market friendly deliverables don't cost very much at all, avoid them and you're definitely avoiding success at all costs, but with both meanings at once this time.
As I understand it, the core Haskell folks don't especially care about Haskell's (admittedly limited) real-world usage. Or, if you prefer: real-world usage is a side-effect, not a value.
Yes, there is a lot of research being done on Haskell, but a lot of the research is centered on areas that more or less directly contribute to typical real-world usage. Consider the recent introduction of linear types for example: They're both exciting from a type theoretic perspective, but could also improve some real-world scenarios (even though at this point linear types are still quite new, so there's not a lot of examples out there).
> This, however, I disagree with.
I think it might well be correct, actually. I think that it might be the difference between abstract and concrete thinkers on that standard personality test. Abstract thinkers will find that Haskell makes more sense; concrete thinkers will find that C makes more sense.
First of all, I completely understand where you're coming from.
But the fact that Haskell embraces computer science, unlike most other programming language communities, is what attracts me to it the most. I can geek out about the mathematics that leads to simpler, safer software with like-minded people. I am always learning from Haskellers more than from any other programmers.
But it does take a lot of learning and unlearning to become a fluent functional programmer. This isn't because functional programming is more complicated than other paradigms (au contraire), it's because schools and universities have been mostly teaching OOP for the past 2-3 decades—unfortunately. As a result, most programmers have such a big gap in their knowledge that it can feel too daunting to dive in.
We could definitely do a better job teaching the theory and explaining how it's useful. That would be better for everyone: better for curious minds who want to expand their programming skills, and better for me because I'd have more company to discuss it with.
In particular, most algorithms research and papers are expressed in imperative pseudo-code, as that is, in fact, much easier for humans to intuitively reason about than complex category theoretical concepts.
We're not talking about any complex category theoretical concepts here. Functors, for example, are one of the first ideas one would learn in a category theory course. Likely even in the first lecture.
Even the most advanced functional programs use only the most basic categorical constructs.
And when you say "imperative pseudo-code", you've already conjured an implicit monad involving state, I/O, etc. Functional programming just teaches us that it's not the only one—and there are simpler ones that may be more appropriate for the given situation.
No, I have not. The fact that you can recreate state and I/O using monads does not mean that anyone using state is implictitly using a monad - monads have very specific properties that imperative code often doesn't have.
It's only Haskell's laziness that makes it require monads for i/o, by the way. Other pure functional languages don't use them. For example, in Idris, IO and state are not monads, they are effects - tracked at the type system level, but without all of the commodity of monads. For example, you can have a single do-block in Idris that does IO and state operations without needing any monad transformers or lifting.
I still think they don't often come up in algorithms research, though.
Why are you so fixated on algorithms research in your attempts to dismiss the usefulness of functors and monads?
Basically, I am only trying to dismiss the idea that Haskell is somehow closer to CS or more scientifically correct than other programming languages; instead, it is as related to CS as other languages are, just choosing to focus on a different area than many others.
I also want to dismiss the idea that CS == FP, that imperative style reasoning is just some second-tier style not used in rigorous circles - much of the forefront of CS is indeed using imperative style constructs more than FP ones.
You don't know what you're talking about. In the context of programming language theory, monads were first used by Eugenio Moggi precisely for the purpose of specifying the semantics of imperative programming languages. Only later did Wadler realize that they could be useful as user-defined constructs within a programming language.
The "very specific properties" are actually just the identity and associativity laws of a certain monoid. These are trivially satisfied by imperative-style code including the "algorithms research and papers are expressed in imperative pseudo-code" you mentioned: you can write an imperative program that does nothing when sequenced with other programs (identity), and A; B; C does not require explicit grouping (associativity).
> It's only Haskell's laziness that makes it require monads for i/o, by the way. Other pure functional languages don't use them. For example, in Idris, IO and state are not monads, they are effects - tracked at the type system level, but without all of the commodity of monads. For example, you can have a single do-block in Idris that does IO and state operations without needing any monad transformers or lifting.
This is an incoherent train of thought. Haskell's laziness does not require the explicit use of monads, nor are monads only useful in the context of laziness. Haskell could have used Idris's IO system instead—algebraic effects work just fine in lazy languages. But also it is not true that Idris programs do not use monads just because you don't see the word "monad" in Idris programs. Effects give rise to a monad, mathematically; namely, the free monad for the algebraic theory. Read the seminal work by Plotkin and Pretnar, for example.
Just no.
The reason Haskell is so complicated to become fluent in has nothing to do with the inherent complexity of functional programming. The Haskell community is just in love with complexe abstraction for the sake of abstraction, extremely terse and hard to understand syntax (see for example the obsession with introducing convoluted operators) and generally favour hard to understand style like point free where pipes are a lot easier to follow. The Haskell community is full of people who are here to geek out rather than produce software. Haskell is what happen when you let one upmanship leads your language design.
Meanwhile, you can learn SML, F# and Ocaml in a couple days, gradually enjoy the functionality they have to offer and benefit for a nice community. I really don't understand why anyone would choose Haskell.
I can't count the number of times I have read, here on HN, that people only choose imperative programming or OOP because they're ignorant or stupid. Because if they actually understood FP then of course they would choose it, so the only reason they don't is because they haven't learned or can't learn.
No they don't. Every Haskeller I know (myself included) acknowledges that sometimes point free style is better, and sometimes it isn't. None of them would unilaterally declare it better, and most generally avoid it except in very simple situations.
> The Haskell community is full of people who are here to geek out rather than produce software.
The Haskell community is full of people who are here to geek out about the best ways to produce software. This means they embrace tools like mathematics, and are generally extra thoughtful about structuring programs in principled ways. It's a wonderful community of people who care about the details of their craft and treat it like a skill to be honed over time. I have a lot of respect for that.
If I could rant for a moment: I'm really sick of spending many years of my life investing in myself and my ability to produce software with the best tools humanity has to offer, only to have these people in Hacker News tell me I'm just doing mental masturbation when it seems like they don't even understand what they're criticizing.
\x -> h $ g $ f x
At a certain point you realise that in many cases seeing the `x` is not just useless but needless visual noise. The following is identical and more readable once you've internalised composition:
h . g . f
And this extends to a cute trick in which, if you need to explicitly provide that data to begin with, you can do this:
h . g . f $ x
I'm now working with Haskell having previously come from PHP and JS/TS. Composition is more readable, it's just harder to get started with because it's different to what you're used to.
As for the "geek out" comment, of course, I enjoy programming for the intellectual sake of it. I'm not product-driven. Don't make the mistake of thinking everyone's the same as you, nor that of thinking there aren't benefits to being so intellectually-motivated. I don't know if it's intentional but your comment comes across as rather self-righteous.
I’ve used functors and monads to solve tons of issues and have literally no clue about the theory behind them.
You need to give the reader some real world example. A concept dangles in brain without connects to other things won't live too long. You brain is likely to `optimize it out` because it is unused.
That's completely fine. Haskell is not a single community. There are two big camps that often interact with each other, the academic and the industrial. Keep in mind the origin of Haskell is academic and it's original purpose is to test and implement ideas from Programming Language Theory. That is still there and will continue. GHC optimizes for letting people experiment with language extensions. Industrial interest didn't start to grow until somewhere around 2008-2012. It is a small community and will likely remain so.
I am a big Haskell user myself. There are many theoretical things I don't understand or need to touch, but I appreciate their contributions to the language and the community. I do agree that Haskell has lots of room to improve on tutorials for non-academics. Maybe I will get inspired to write somethings.
It's completely fine if you don't want to use it. However, you may find Haskell users' enthusiasm for the language insufferable, hehe. I do hope anyone who chooses to interact with the Haskell community finds us welcoming.
For balance, here's another common opinion about tutorials: http://dev.stephendiehl.com/hask/#eightfold-path-to-monad-sa...
> [...]
> Read the monad definitions.
> Use monads in real code.
> Don’t write monad-analogy tutorials.
In the end, the two opinions about learning monads coexist, and people have done fine following either way.
With a ‘theoretical’ description, like a BNF grammar or a Unix man page listing every possible option the program accepts, this is immediately obvious. Haskell’s focus on ‘theory’ follows the same philosophy.
In any case, all knowledge needs to be elevated to some level of theory because a correct theory guarantees the repetition of correct application.