[jerf]

Agreeing and amplifying: I believe multi-paradigm is a useful term, but you can always find a prioritization in the paradigms. Your language is going to privilege either mutable or immutable data. It can support both, but one is going to be considered the default. Even if the language itself doesn't, the standard library and the resulting influence it has on the 3rd party libraries will result in a preference. Your language will privilege one side or the other of the expression problem. Your language will privilege statements or functions. Your language will privilege static or dynamic types. Your language will prioritize compile time things or run time things. And so on for quite a few things. Even when someone finds an interesting way to split the difference in one of those categories, that does not defy this categorization, it adds a new one, a new way of prioritizing. But that new way still won't be a completely even 50% split.

There are many multiparadigm languages. They are even the norm now. But being multiparadigm doesn't mean they all support all paradigms equally. Programming X in Y is a problem for almost all combinations of X and Y for X != Y, because the language will always have a "grain" to it. Thus, it is still meaningful to argue about which paradigm preference is suitable to which tasks.

Even two of the most similar languages there are, at least in terms of language spec, Python and Ruby, demonstrate significant differences in the orientation of the library ecosystem in some of their philosophies.

[nextos]

> There are many multiparadigm languages. They are even the norm now. But being multiparadigm doesn't mean they all support all paradigms equally.

Mozart/Oz and CTM are obligatory reading to understand the topic of supporting multiple paradigms: https://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf

Oz is among the few languages where all paradigms are equal. A great HN discussion about the above link: https://news.ycombinator.com/item?id=18381640

[mtreis86]

Mostly agree but Common Lisp goes out of its way to not prioritize paradigms.

Immutable or mutable? Depends how you write it. Lists don't mutate until you choose to.

Statements or functions? Both I guess. Loop is declarative, many things are imperative, some things are functional.

Dynamic or static typing? Depends whether you bothered to give the compiler type hints or not.

Compile time or runtime? CL is AOT by default but you can eval-when your way into running code whenever you want. Readtime too

To be honest one of the biggest problems with CL is the multiparadigmatic design - you end up with many styles of code, all of which are valid and none of which anyone can agree on.

[bradrn]

I agree with all of this. But I’ll point out that ‘the paradigms can be prioritised’ wasn’t intended to be my main point there. I wanted rather to refute the argument that Rust etc. aren’t ‘post-paradigm’ at all: on the contrary, they fit in quite well with existing paradigms.

> Even two of the most similar languages there are, at least in terms of language spec, Python and Ruby, demonstrate significant differences in the orientation of the library ecosystem in some of their philosophies.

Hmm… I feel you can get a lot more similar than that. Python and Ruby are actually rather different to my mind. Rather, you could take OCaml vs SML, or Scheme vs Racket. The differences are still there, but it’s much more subtle.