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

51–60 of 68 posts

Re: Programming Beyond Paradigms

#51

Post by bmitc »

valenterry wrote: post #46
ogogmad wrote: post #42

Earlier quoted context omitted.

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

It isn't clear what you're discussing. You mentioned that functional programming has lost its meaning and then went on to describe things as if your defintion would exclude some of the most shining examples of functional programming.

Functional does not mean just pure functional. And a purely pure functional language would literally be worthless as it wouldn't be able to do anything useful.

Re: Programming Beyond Paradigms

#52

Post by mtreis86 »

jerf wrote: post #8
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…

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…

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.

Re: Programming Beyond Paradigms

#54

Post by klabb3 »

bradrn wrote: post #49
klabb3 wrote: post #16

Earlier quoted context omitted.

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

Fair enough! I agree with that and looks like I missed your main point.

It’s a bit naive and generally ahistorical to think we’ve “transcended paradigms”, whether within tech or outside. It’s similar to the bias of thinking that current year/western/majority perspectives are “enlightened” and free of bias. Usually just means we’re unable to see the bigger picture.

Re: Programming Beyond Paradigms

#55

Post by klabb3 »

lispm wrote: post #28
klabb3 wrote: post #16

Earlier quoted context omitted.

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

TIL. Would it be better to say that Prolog is a general purpose PL, albeit more archaic than what we typically think of?

Re: Programming Beyond Paradigms

#56

Post by valenterry »

bmitc wrote: post #51
valenterry wrote: post #46

Earlier quoted context omitted.

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

It isn't clear what you're discussing. You mentioned that functional programming has lost its meaning and then went on to describe things as if your defintion would exclude some of the most shining examples of functional programming. Functional does not mean just pure functional. And a purely pure functional language would literally be worthless as it wouldn't be able to do anything useful.

> then went on to describe things as if your defintion would exclude some of the most shining examples of functional programming

Maybe those examples are "most shining" from your perspective or definition but not mine. Mind to mention the specific languages?

That being said, to be precise, functional programming is a technique or style, it's not a property of a language anyhow. However, some languages make it very hard or even impossible to apply the style, either fully or partially. So practically speaking, that is how I classify a language as more or less functional.

> Functional does not mean just pure functional.

Yes, that's exactly what I said in my first sentence no?

Originally "functional programming" had the meaning of what we nowadays often call "pure functional programming" though. Language and definitions change over time. I was ranting a bit that the term "functional" is nowadays so unclear that there is little benefit in knowing that a language is "functional".

> And a purely pure functional language would literally be worthless as it wouldn't be able to do anything useful.

This is wrong. You haven't understand what functional programming is. In a nutshell it means that you are not directly executing effects, but rather that you build up a datastructure that describes the effect-execution. You then pass around an modify that datastructure to the point where you return it as the last thing that your does in the main-method (or whatever your language/runtime calls that). From that point on, this datastructure is being processed and the effects (like writing to a file, showing something on the screen) are (most likely) executed by the runtime.

In other words, there is no restrictions on what you can do with a pure functional language. You can try it out with Idris, which is a 100% pure functional language without any escape hatches. And still you can make it do all kinds of effectful things like processing files, sending emails, ...

Re: Programming Beyond Paradigms

#57

Post by lispm »

klabb3 wrote: post #55
lispm wrote: post #28

Earlier quoted context omitted.

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

TIL. Would it be better to say that Prolog is a general purpose PL, albeit more archaic than what we typically think of?

I don't know what you mean by "archaic".

But here are a few pointers:

Visual Prolog, https://www.visual-prolog.com

Once it was Borland's Turbo Prolog. Quote: "It combines the best features of logical, functional, and object-oriented programming paradigms, offering a powerful, type-safe, high-level language. Visual Prolog is well-suited for developing applications for Microsoft Windows 32/64 platforms and supports advanced client-server and three-tier solutions."

There is a comparison of Prolog implementations on Wikipedia:

https://en.wikipedia.org/wiki/Comparison_of_Prolog_implement...

This explains the OOP extensions of SICStus Prolog.

https://sicstus.sics.se/sicstus/docs/3.7.1/html/sicstus_35.h...

I haven't researched this, but there should be zillions of language extensions like this to Prolog. It is one of the symbolic AI languages, as such it has a long history of extensions.

Re: Programming Beyond Paradigms

#58

Post by mtVessel »

wslh wrote: post #48
mtVessel wrote: post #41

Earlier quoted context omitted.

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

LINQ is an interesting example because it exists in two forms, query syntax and method syntax. You might consider these "mini-paradigms". Most users know one or the other. I've rarely met people who are equally proficient at both. But almost anything you can accomplish in query form can also be done in method form, and the industry has settled on method syntax as the standard.

Why do you think that is? I think it's because method syntax fits more neatly into the larger C# paradigm of imperative code. Using both requires the developer to pivot to a different mental model (declarative coding), so we try to standardize on the one that fits best in the bigger picture. This is what I mean by cognitive load. Most devs can surely handle both, but why make them do extra mental work when that effort is better spent on the problem domain.

Re: Programming Beyond Paradigms

#59

Post by mpweiher »

mikewarot wrote: post #13

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…

IIRC, this was called "permanent assignment" in CPL, a name I very much like.

It's also pretty much the same as a dataflow constraint (see: Amulet, Garnet, Spreadsheets, ...)

In Objective-S, I use the syntax |= for the unidirectional variant of a dataflow constraint, =|= for bidirectional (ObjS uses := or ← for assignment, = for equality). So the above would be:

    a := b.
    a ← b.
    c |= d+1.
    z |= 10-time.  (if 'time' were the current time in ObjS)
https://objective.st

Re: Programming Beyond Paradigms

#60

Post by wslh »

mtVessel wrote: post #58
wslh wrote: post #48

Earlier quoted context omitted.

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

LINQ is an interesting example because it exists in two forms, query syntax and method syntax. You might consider these "mini-paradigms". Most users know one or the other. I've rarely met people who are equally proficient at both. But almost anything you can accomplish in query form can also be done in method form, and the industry has settled on method syntax as the standard. Why do you think that is? I think it's b…

I think it is more about education, the way "we" study/teach programming than an intrinsecally problem about paradigms. I personally find the query syntax better and I am not working as a developer "anymore". I would say that is a matter of taste and education. Related [1]. Personally, I look for simple and clear syntaxes and don't have a problem switching from one programming language to another while the focus in the solution is clear.

[1] https://www.reddit.com/r/csharp/comments/w7n11s/why_does_the...

Post reply on HN