31–40 of 68 posts
As the big name languages become a never-ending accretion of multi-paradigm features, then it just feels like a sort of Grey Goo landscape. There's a charm in things remaining true to themselves, even at the cost of maximum utility.
Imperative programming lets you think about a series of steps. Structured programming lets you split and name series of steps into known procedures and structures. Object oriented programming (and object relational mapping) was wildly successful because a lot of enterprise programming is about interactions between durable real world entities. Functional programming remains somewhat niche because modelling in terms of pipelines of pure functions is hard to map to real world problems without great discipline.
None of these is right or wrong, nor is any subset or combination. But they’re not just regrettable constraints, they’re valuable ways of thinking. Any language seeking to grow beyond one or more paradigms still needs to offer a clear and consistent way for programmers to reason about the world.
Common Lisp is a modern programming language, apparently. Who knew. Greenspun’s Tenth Rule always irritated me more than it amused me but here we are.
A lisp that didn’t spam parentheses would probably be more palatable.
Javascript: f(g(x)) Lisp: (f (g x))
Same amount of parens.
The closest thing I've seen to truly multi-paradigm was a programming language now lost to time called Metamine, which I kept a clone of[1]. Here's some previous discussion[2] In Metamine a := b is a normal assignment c = d+1 means that c will ALWAYS be equal to d+1 z = 10-time results in a countdown timer, z That magical equals is declarative programming... something that I've only seen mixed with imperative functio…
A better example is the Oz programming language and the Mozart programming system ( https://en.wikipedia.org/wiki/Oz_(programming_language) ) explained in the book Concepts, Techniques, and Models of Computer Programing by Peter Van Roy and Seif Haridi .
Since Oz's Wikipedia page was linked, Wikipedia apparently has a page (https://en.wikipedia.org/wiki/Comparison_of_multi-paradigm_p...) comparing multi-paradigm languages (though can be argued all languages nowadays are multi-paradigm). A summary table for some of those (partial support isn't considered):
| Paradigms supported |
Language Native Libs Others Total
Wolfram 14 0 1 15
Oz 11 0 0 11
Raku 10 1 3 14
Racket 10 0 1 11
Julia 9 5 3 17
Scala 9 0 0 9
Haskell 8 5 2 15
Perl 8 1 0 9
CLisp 7 8 2 17
C++ 7 7 1 15
Python 6 4 0 10
Java 6 2 0 8
Rust 6 0 1 7
JS 4 3 2 8
Fortran 4 1 0 5
OCaml 4 0 0 0
Go 4 0 0 0
Lua 3 0 0 0
> The unifying aspect of new languages such as Rust, Nim, and Gleam is that they were designed from the beginning to be beyond paradigms. I really don’t think this is correct at all. Rather, Rust/Nim/Gleam are first and foremost imperative languages. They may have some functional and Lispy features thrown in, but that doesn’t change the fact that programs in those languages involve writing statements to be executed o…
I disagree. In Rust, traits are used all over for dynamic dispatch, the defining feature of object-oriented programming. Moreover, all three languages support structural pattern matching (borrowed from functional programming) as a core control-structure. Certainly all three languages can be used in a simple, imperative style. But that's not the only paradigm that can be used unlike in C or early versions of Python. M…
Common Lisp is a modern programming language, apparently. Who knew. Greenspun’s Tenth Rule always irritated me more than it amused me but here we are.
A lisp that didn’t spam parentheses would probably be more palatable.
As other commenters are saying, in 2024 we can combine paradigms more than before the 2000s but paradigms continue to exist. It is very different to use think in functional terms than in imperative ones or even in purely logic terms as in Z3. There are combinations that are pretty natural (e.g. LINQ in .NET) while others go beyond specific languages: just interfacing components written under different paradigms.
My two cents is that programming languages will always favor a paradigm over others because many paradigms are strongly connected to the compiler or interpreter and offer syntax sugar to give the developer different strategies. The multiparadigm approach would much alike the lines of Microsoft .NET (F#, C#) where specific programming languages can use a unified framework.
In futuristic terms I think the whole programming field will majorly lend more toward reuse and developing based on specs than what we are doing now: reinventing the wheel across different organizations. For example, front-end development should be more visual and parametric than the code it requires to write.
A better example is the Oz programming language and the Mozart programming system ( https://en.wikipedia.org/wiki/Oz_(programming_language) ) explained in the book Concepts, Techniques, and Models of Computer Programing by Peter Van Roy and Seif Haridi .
Not necessarily. Oz was created as poster child to multi-paradigm language design. The book shows this. Each paradigm gets its own chapter and Oz examples to program in each are shown. This is similar to the cirricula structure author mentions. In contrast the article makes a case for programming without paradigm distinction and mixing elements across styles. Since Oz's Wikipedia page was linked, Wikipedia apparently…
OTOH Java has a defined language standard (independent of implementations), which describes classes/fields/methods/dynamic dispatch/inheritance/hiding/constructors, ... ( https://docs.oracle.com/javase/specs/jls/se22/html/jls-8.htm... ).
I fail to find a similar language definition of OOP for Wolfram. That could be me.
Earlier quoted context omitted.
I disagree. In Rust, traits are used all over for dynamic dispatch, the defining feature of object-oriented programming. Moreover, all three languages support structural pattern matching (borrowed from functional programming) as a core control-structure. Certainly all three languages can be used in a simple, imperative style. But that's not the only paradigm that can be used unlike in C or early versions of Python. M…
> Many programs in these languages look significantly different than just statements and procedures. Like I said, they’ve certainly adopted features from other paradigms… but the basic, underlying structure of programs in these languages is still statements, sequenced one after another. It’s not like Haskell or Scheme where nearly every operation is ultimately done through function calls. And it’s certainly not ‘post…