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.
Programming Beyond Paradigms
11–20 of 68 posts
Re: Programming Beyond Paradigms
#12> 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…
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 l…
> 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
Re: Programming Beyond Paradigms
#13The 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
Re: Programming Beyond Paradigms
#14The 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…
Easy to achieve the same in any language that supports the uniform access principle, and it does not even look magical
Re: Programming Beyond Paradigms
#15> 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…
> In Rust, traits are used all over for dynamic dispatch, the defining feature of object-oriented programming.
In my experience, Rust traits are used much more for static dispatch `fn foo(T)` than dynamic dispatch `fn foo(Box)`. This, together with its ADTs and lack of inheritance, gives it a very different feel from most "object oriented" languages.
Also, what counts as a "defining feature" depends greatly on who's defining it. Though dynamic dispatch is certainly up there on most lists.
Re: Programming Beyond Paradigms
#16> 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…
To add to my parent comment, I think there’s another point to be made here: ‘post-paradigm’ is, to some extent, a contradiction in terms. You can’t build a language without its basic structure implying some paradigm (or possibly more than one). There’s a perspective I find useful here. I tend to think of different ‘programming paradigms’ as different approaches to solving problems. In imperative languages, you solve…
Replying here to both.
I don’t disagree on any of your technical points. But I also think for practical purposes you’re missing the forest here. I agree with the sentiment of the article - I think the big trend in general purpose PLs is a blend of multiple classical paradigms. Perhaps we’re moving the goalpost and paradigms need to be rearranged - but that is intrinsically interesting - it’s literally the continents of knowledge drifting slowly into new configurations.
Single-paradigm languages like prolog, CSS or SQL keep their restrictions not because the lack of use-cases, but because the benefit of keeping the complex execution engines away from the end-user exceeds the minor wins in expressiveness.
I don’t think it’s a coincidence that the declarative languages are in this category. They are higher level, and opening up low-level customizations is really tricky: for instance, if you put imperative code inside your CSS, it needs complex “re-evaluation rules”, that results in a dilemma: either give full control to the programmer, which imposes specific execution engine designs and complex API surfaces – or re-evaluate too often, which risks killing memoization and perf (cache invalidation). It could be even worse if the code has side-effects or dep cycles.
On the contrary, imperative low level languages like Rust can easily come along and say things like: “this is not only a function, but a side-effect free function”. “This is not just a reference, but an immutable reference”. Then you can cleverly leverage those traits in your “execution engine” ie the compiler, to deliver low-level perf. There are even people who describe rust as a high-level language for these reasons, which is a bit provocative to me but in all honesty not completely outrageous.
An alternative take on the last 10-15 years:
- General purpose PLs typically have an imperative base, while integrating multiple classical paradigms:
- Only a few aspects of OOP are added to modern PLs, where inheritance has largely been superseded by simpler composition
- Features from FP have surged in popularity, being integrated and even retro-fitted into general purpose PLs, providing both perf- and DX improvements
- Structured meta-programming and/or codegen has been a strong focus for compiled languages, acknowledging that it’s preferable to limit the complexity of the core language at the expense of separate pre-compile phases
Re: Programming Beyond Paradigms
#17> The most common understanding is that a paradigm is a set of features in a programming language that determine its control flow or type system
A better viewpoint is to question what sort of problems or way to model a system, is a particular paradigm best suited to?
Re: Programming Beyond Paradigms
#18[deleted]
Re: Programming Beyond Paradigms
#19A 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.
Re: Programming Beyond Paradigms
#20[deleted]