Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming Beyond Paradigms

micahcantor.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Programming Beyond Paradigms

#41

Post by mtVessel »

wslh wrote: post #38

From the content of the article it is not clear if the author really knows about the topic of programming paradigms (as per undergraduate courses). 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 a…

"Think" being the operative word. Paradigms are mental models of computation and organization. The benefit of designing a language around a single model is ease of understanding. The downside is that this locks the developer into a single way of looking at things, which may not always be the best match for the domain. Multi-paradigm approaches (most modern langs) broaden the available options, but at the cost of greater cognitive load.

Re: Programming Beyond Paradigms

#42

Post by ogogmad »

valenterry wrote: post #25
fmbb wrote: post #23

Earlier quoted context omitted.

I think your comment may be arguing against you. Gleam is one of the really really functional languages out there. There is no mutability, there are no statements, no loops. It has let bindings, function application, and conditionals through if/case, and that’s it. It has just tricked you because it has a very nice and friendly syntax. It also has no macros so I don’t know what you mean in that last paragraph.

"Functional" has lost its meaning. Originally, functional programming was rather well-defined - now everything that has a `.map` is called functional. Gleam goes a longer way than, say, Python. But since it still has side-effects and lacks a system, it is very different from e.g. Haskell.

If Gleam is imperative by your logic, then Scheme and the whole ML family (SML, OCaml) would be imperative as well. That's a strange choice of semantics. Even Haskell has unsafePerformIO, which it might sadly need.

Re: Programming Beyond Paradigms

#43

Post by cess11 »

'Multi-paradigm' languages are quite old, like Lisp.

Got closures? Then you've got objects.

Can you write code that's executed sequentially? Then you've got imperative programming.

Can you pass a function as a parameter to another? That's pretty functional.

Having this in a language has been common for decades. But there are more paradigms, notably 'macro-oriented' programming and logic programming. Are these well supported in Rust and Nim? If not, then they aren't as "beyond paradigms" as Lisp.

There's arguably several forms of object oriented languages too, besides what might be called Java/C++/Python style there's message passing Smalltalk style and prototype style as in JavaScript and its parent. Would probably need to support these styles too, to be "beyond paradigms".

Assembler could also be considered a programming paradigm, so we'd need to support that too.

And if logic programming is a paradigm, constraint programming likely is another. Glue or shell programming yet another.

And so on and so on.

Re: Programming Beyond Paradigms

#44

Post by alilleybrinker »

I think this article is _closer_ to right than a lot of writing on programming paradigms is, but still misses a central idea.

Programming paradigms can't be defined intensionally, by listing their features, nor extensionally, by listing programming languages that fit each paradigm. Either way results in unsatisfactory definitions from which reasonable people will identify errors of excluded languages.

This is because programming paradigms aren't sets, they're cognitive categories. Programming paradigms are subjective mappings of conceptual framings of program structure onto specific languages. A language fits a paradigm if that mapping is subjectively natural.

Of course, people tend not to like subjective definitions, but this is more accurate.

Re: Programming Beyond Paradigms

#45

Post by cess11 »

LettuceSand12 wrote: post #11
ergonaught wrote: post #4

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.

It's not uncommon in the Lisp-family that you can use [] as well as () so that problem of yours is solved already.

Re: Programming Beyond Paradigms

#46

Post by valenterry »

ogogmad wrote: post #42
valenterry wrote: post #25

Earlier quoted context omitted.

"Functional" has lost its meaning. Originally, functional programming was rather well-defined - now everything that has a `.map` is called functional. Gleam goes a longer way than, say, Python. But since it still has side-effects and lacks a system, it is very different from e.g. Haskell.

If Gleam is imperative by your logic, then Scheme and the whole ML family (SML, OCaml) would be imperative as well. That's a strange choice of semantics. Even Haskell has unsafePerformIO, which it might sadly need.

Imperative and (pure) functional are not opposites! They are actually orthogonal.

The opposite of imperative is declarative, and the opposite of (pure) functional is non (pure) functional.

Schema and (to my limited knowldge) the ML family are in fact non (pure) functional. However, they share more functional-aspects with pure functional languages than most other popular languages do.

> Even Haskell has unsafePerformIO, which it might sadly need.

Sure, it's almost never a black and white thing. But I think for the sake of the argument we can call Haskell a pure functional language, even if it is indeed possible to write non pure functional code in it. There are actual pure functional languages (like Idris) but I think for practical use in the discussion it's fine to call Haskell pure functional. Scheme and ML languages are very different from Haskell though, so I think they deserve to be called differently. They are however also different from, say, C. So to improve our communication I think it is worth to not put those 3 things into 2 boxes. We need 3 boxes here.

Disclaimer: I want to emphasize that none of any of that says that a language is inherentially better or worse! This is just terminology-talk.

Re: Programming Beyond Paradigms

#47

Post by ubertaco »

bradrn wrote: post #3

> 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…

Yeah, I'm having trouble seeing how Rust/Nim/Gleam can be written in a logic programming style (like Prolog or Datalog).

At minimum, that means there are _two_ paradigms: logic programming and "beyond paradigms"....which sorta means that we're not really beyond paradigms now, are we?

I think the reality is that certain previously-niche paradigms became cool again, and folks started grabbing off some of the most-visible pieces of those paradigms (pattern-matching, ADTs, map/reduce/filter, maybe even a pipeline operator) and adapting them to other paradigms.

Re: Programming Beyond Paradigms

#48

Post by wslh »

mtVessel wrote: post #41
wslh wrote: post #38

From the content of the article it is not clear if the author really knows about the topic of programming paradigms (as per undergraduate courses). 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 a…

"Think" being the operative word. Paradigms are mental models of computation and organization. The benefit of designing a language around a single model is ease of understanding. The downside is that this locks the developer into a single way of looking at things, which may not always be the best match for the domain. Multi-paradigm approaches (most modern langs) broaden the available options, but at the cost of grea…

I don't agree about the cognitive load, people are different and the idea that there is a "single developer mind" is completely wrong. For example, YMMV, if you look at LINQ in .NET is a natural query language over different paradigms. I don't think it adds a cognitive load.

And, we should also think about the way that computer science and/or software engineering is studied. If there were a better teaching approach about multiparadigm thinking there would be less cognitive load. My argument is that when you work professionally you don't spend the same cognitive requirements that studying at university because even unconsciously you assume that you know most of the material.

What I agree is that you would not find many people who are profficient in Haskell/OCaml/Lisp at the same time of imperative languages. You can know both but it is rare to work interchangeably in both. Again, I think that part of this is how we learn computer science and that new pedagogic ways could help to be at least good in both.

My personal frustration with logic implementations like Prolog is that the promise on focusing in the "what" instead of in the "how" is not fullfiled. I think that SMT solvers like Z3 are great in this topic at the expense of narrowing the problem space.

Re: Programming Beyond Paradigms

#49

Post by bradrn »

klabb3 wrote: post #16
bradrn wrote: post #9

Earlier quoted context omitted.

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…

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

You’re not wrong. That may even be the sentiment of the article. But the article certainly doesn’t phrase it that way — it’s saying that modern programming languages are ‘beyond paradigms’. That’s clearly wrong, and that’s what I’m arguing against.

Re: Programming Beyond Paradigms

#50

Post by bmitc »

bradrn wrote: post #3

> 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 don't think I have ever seen a BEAM language described as imperative. They are worlds apart from Rust and Nim.
Post reply on HN