"Evaluate the expression on the right of the = sign and make this the value of the variable on the left."

Elitism and gatekeeping do precisely nothing to help people solve problems with code.

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.

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.

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

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.

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".