Stanford Seminar - Concatenative Programming: From Ivory to Metal

[@perplexedmoth]

As a noob venturing into concatenative programming recently, this was the best talk I've seen about the subject so far!

[@DavidGauerRatfactor]

Thank you for this dense info blast. Very helpful as a primer and starting point for diving deeper into concatenative programming!

[@benjaminscherrey1124]

Am a fan of kitten and, as an old forther, concatenative programming of course. Can't believe I just now stumbled on this talk. Probably the best summary I've ever seen with excellent background and forward looking concepts. Would love to see more!

[@256k_]

most of this went over my head, but i'm excited about exploring more deeply the wold of concatinative languages. something about it feels inherently more instinctive and analogous to nature.

[@notgate2624]

Incredible talk!

[@headshock1111]

Who else watches this like once a season

[@programming3218]

I understood near nothing of this, but it was still really good.

[@wginwien4]

I think you compare algebraic effects to monads in Haskell. But if you compare algebraic effects to monads in dependently typed languages, there is a mapping of algebraic effects to dependent monads (kind of isomorphic), I think. Some this statement may not hold for more expensive type systems. The second part of the talk is interesting.

[@TheodoreCackowski]

Is the "observation that all of the basic operators are related to something that you do in logic or proof" in one of the referenced works somewhere specifically?

[@tarpiner]

I think this is essentially the Curry-Howard isomorphism

[@burakcopur3841]

Do the connection between topology in the sense of being "point-free" ends at the name? Or maybe like topology, point-free programming can say qualitative things about programs just like topology does to spaces? Is this the case?

[@holothuroid9111]

This was explained in the talk, I think. With this model you can split your program either anywhere (as in Forth) or at least at term boundaries (Cat) and what you get is still valid programs.

[@LambdaJack]

Wikipedia page on "apply" mentions a link with "Scott topology".

[@KaranLobana]

I think this is a great idea for more mathematical and scientific applications but for most commonplace applications that are infact made for von neumann machines, the combination of paradigms that we already use are much superior to the language you propose. I would argue that context is crucial when it comes to any level of human computer interface design. Perhaps we are being restricted by architecture but I don't think we will see this anytime soon considering that Quantum computers themselves are not seen as viable for consumers today.

[@sofia.eris.bauhaus]

"commonplace applications that are infact made for von neumann machines" you mean there are many programs already written for it? how would that prove the superiority of anything? and you don't need a stack machine to write in concatenative languages, have you ever actually done that?

[@nolan412]

Continuation passing style by another name.

[@nolan412]

now I want to set RAM to all ones to get a little more juice...

[@wginwien4]

I would recommend that students watch lectures from Alan Kay instead. That was in regard that you prefer C for it's simplicity and mapping to hardware.

[@frechjo]

I love Alan Kay. Smalltalk is a great language, it's one of the simplest conceptually. And A.K. has many great insights about programming beyond it. But I don't know what granted that comparison. He said he likes that C maps to hardware in a straightforward way. (He said he dislikes C++ for it's complexity, but did he mention any conceptually simple language?). Mapping well to HW is a good property by itself. As a compiler writer (which he is), it can make your life easier. As a programmer, if you know your target architecture (he does), you can write performant code with few surprises. It's only bad in relation to the compromises you might have to make, put against other desirable properties. And it's not the only property that C has. But I don't think it maps as well to modern hardware as it used to. Caches and optimizations do give you a lot of surprises, and there's no nice way to express concurrency. In that regard alone, maybe Erlang maps better to multicore CPUs than C.

[@acex222]

C doesn't map well to modern hardware at all.

[@imzoltan]

I do embedded programming in Forth and it is quite the joy.