How Many Paradigms Does It Take to Screw In a Lightbulb?

I’m glad you acknowledge it as a ‘rant’. I’m a native English speaker so I reckon I understand the term, but for others, Google thinks it means ‘a loud, uncontrolled, or angry outburst, often involving lengthy complaints or exaggerated, irrational statements’. I don’t disagree.

This kind of invective is not helpful and, whether intentioned or not, ends up reflecting poorly on the community here in my opinion.

For the record, I’m invested in Elixir (literally), and have a full time team of 4 working on an Elixir product. I’ve been following Erlang and then Elixir for nearly 25 years now all up. I think, for the right problem spaces, it has clear advantages.

The issue I have is that, your ‘rant’ comes off as a purity spiral. I’ve been fortunate enough in my career to work with some genuinely great engineers, people who’ve solved hard problems and not only shipped, but shipped at scale.

From the Windows USB3 kernel stack, the DotNet Task Parallel Library or even Real Time Pose Estimation (HoloLens), these were - I observed - all problems solved by people totally immersed in only one paradigm - the most common one, imperative. They were open to ideas from maybe one other paradigm, notably functional, but would reasonably reject these ideas on solid engineering grounds e.g performance or ‘fit’.

Many extremely competent engineers never leave the ‘imperative’ paradigm in their entire career. The idea that you need to know other approaches to be classified as such is frankly bunk.

I’m not a native speaker, so what is your point (besides that if I wanted to be reflected by the community I should ditch my blog)?

Your survey of all the paradigms are very good but your assertion of “knowing at least 5 is a must” is not sufficiently substantiated. Why 5, not 3 or 6?

Also, you criticized most paradigms you cited but one is missing for the functional programming. If your position is that FP is above all others you did not make it clear.

I actually agree with most of what you said but since you asked about feedbacks so here you go.

Because 5 is favorite number (and also 5 cover all others to some extent.) To be honest, I’d say 3 is already well enough for the vast majority of cases.

you criticized most paradigms you cited

Did I? That was not intentionally. I love them all, to be honest. I wanted rather say that each paradigm is great in its own niche, while might be flagrantly failing if applied beyond it.

This is probably a nice thread to mention a couple of Pragmatic Bookshelf titles: Seven Languages in Seven Weeks and Seven More Languages in Seven Weeks. They give you a taste of multiple paradigms for those who want broader exposure.

As someone who is not well versed in the history of computer science, only only somewhat-versed in the science itself, but who is fairly interested in category theory:

Is there a difference between a “style,” an “approach” and a “paradigm”? I see the examples you cite referred to as various things but I always feel like I am missing the definition that justifies the groupings. Each language has its own set of abstractions, and along with syntax and other things certainly gives it a certain “style” but that seems pretty ad hoc so I’m not sure how useful it could be in making an argument for the use of one language, or pattern within a language, over another when given a particular problem.

I hate to refer to Wikipedia on that matter, but when there’s no one else, even dumb Tommy is a prince. Programming paradigm - Wikipedia

how useful it could be in making an argument for the use of one language, or pattern within a language, over another when given a particular problem

It makes sense to come up with a proper architecture in the first place. Long before making any arguments.

Writing WhatsApp in any OOP language would have been a nightmare because of state management. Writing GoogleDocs in any functional language would have been a nightmare because of state management. There is no typo in two sentenses above: WA is all about the states of the users, GD is all about the state of the doc. Actors vs Object.

Rails could not be possible without an all-in object-oriented approach of Ruby. The user-facing DSL is better be declarative. If side effects matter for the users of your library, avoiding reactive patters will drive them bonkers soon. Etc.

The real-life example: when I started working on my FSM library finitomata, I prototyped the conversion from a mermaid/plantuml text representation using Idris and then carefully translated the solution to Elixir. The proper solution would be to use Prolog, but I forgot about it at the moment. Anyway, my approach somehow worked, but imagine the attempt to validate the correctness of the FSM and its transitions in pure C, or even Java. You’ll get a state management, not a finite automata.

that Wikipedia article isn’t helping me with my question unfortunately, because not only is its definition supremely vague in a way that makes it indistinguishable from much more obviously ad hoc terms like “style” (“relatively high-level way to conceptualize and structure the implementation”), the examples now are ordered in a semi hierarchical way that only raises more questions. So rather than choosing between imperative and object oriented programming, the latter is just a more specific kind of the former? But then what could it possibly mean to “choose between” them?

And let’s not even discuss the fact that “vibe-coding” is apparently a peer here

One cannot implement Rails ot top of Haskell (well, it’s possible but it takes too much of a hassle.) If DHH was an expert in FP and never dealt with OOP in his life before, Rails would have been a dead-end.

I believe I already provided several clean enough examples of why it’s better to understand several paradigms, otherwise there is a risk of attempting to implement GoogleDocs clone with Actor Model, or a ChatRoom on top of Reactive Patterns.

[EDIT] Law of the instrument - Wikipedia

I fully agree that a broad knowledge is important for fundamental understanding. I don’t trust monolingual developers. I also agree that not every language is equally suitable for every task. I’m just not sure about how to use these categories when I’m thinking about my work.

In general I’m very skeptical even of the attempts to formalize the manifold differences between languages, patterns etc into allegedly clearly demarcated “types” like this that one can choose between like one chooses a utensil. In philosophy there are similarly various “schools” but this is never claimed to be some sort of guide for someone who wants to think, it’s just a post facto label which pretty much only has practical value for librarians. Kantianism is kind of like a philosophical language that is useful if you want to to achieve a particular aim, viz. determining the nature and limits of what can be thought without any reference to experience (we can set aside to what extent it succeeds in this). But “idealism,” a label which is said to apply to Kant, doesn’t really help you with anything…it’s much to vague and its meaning ultimately totally depends on the context.