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

21–30 of 68 posts

Re: Programming Beyond Paradigms

#21

Post by roenxi »

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 suspect it is possible to make the same argument for the contrary position. Once we're talking about "some functional and Lispy features thrown in"; we must start to question what a paradigm is.

If I write a program, fundamentally I have a blob in my head that I'm reifying into formal logic. It doesn't make sense to talk about the blob as having a paradigm; but I'm not sure that it is useful to talk about the reification as having a "paradigm" either. The appropriate techniques to be used are on a functional-imperative spectrum based on how stateful the problem is.

This whole idea of programming paradigms I think is a mis-take of a more fundamental question of how to classify programming problems - we're looking at the shadow in Plato's cave and getting nonsense because we expect the problem to to take on aspects of the programming language. Which is not a strategy for achieving success. We should be classifying problems based on state, not programming languages based on paradigms.

Most of the experts have figured that out, they pick their programming language based on the problem space they want to deal in. But the paradigm paradigm doesn't help in making those decisions, so it's utility is low.

Re: Programming Beyond Paradigms

#23

Post by fmbb »

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

Re: Programming Beyond Paradigms

#25

Post by valenterry »

fmbb wrote: post #23
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 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.

Re: Programming Beyond Paradigms

#26

Post by bashauma »

I more or less agree with the author that "programming paradigms are becoming practically the same as programming styles", but even so, some languages have core features that cannot be replicated by mainstream "multi-paradigm" languages, and then that I can call them as the Next Paradigm.

An example is dependent types. This is impossible in all the languages the author mentions in the article (yes, well, GHC Haskell comes close), but there is at least one "21st century general-purpose language" that uses it, called Idris.

Re: Programming Beyond Paradigms

#27

Post by benrutter »

I think a lot if the paradigm frame comes from programming being still relatively new (although that's becoming a less and less viable meme). We're still very "one true way" in how we talk about software design.

Personally, I'd love to see us talking more in terms of problems/solutions.

To give an example. State leads to complexity and bugs, and it can be minimized by preferring pure functions where possible. That's a good principle that can be learnt from without embracing everything functional and rejecting everything that involves objects.

Re: Programming Beyond Paradigms

#28

Post by lispm »

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 think Prolog is a single paradigm language. It just has one dominant paradigm: Logic Programming. But in actual Prolog systems you'll find procedural programming, constraint programming, object-oriented programming, meta programming (programming on the language level).

Re: Programming Beyond Paradigms

#29

Post by frou_dh »

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.

Re: Programming Beyond Paradigms

#30

Post by lispm »

bradrn wrote: post #7
hydroxideOH- wrote: post #6

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…

I would think pattern matching as coming from string processing (https://en.wikipedia.org/wiki/COMIT , SNOBOL, ...) and pattern-directed programming coming from rule-based & logic programming (PLANNER, Prolog, ...).
Post reply on HN