Stanford Seminar - Concatenative Programming: From Ivory to Metal

EE380: Computer Systems Colloquium Seminar
Concatenative Programming: From Ivory to Metal
Speaker: Jon Purdy, Microsoft
Concatenative programming is a relatively new programming paradigm built on a simple yet powerful tool: function composition. In this talk I will give an overview of concatenative languages from high-level theory down to low-level implementation. I will discuss some historical background, give an overview of the existing concatenative programming literature, then dive into examples of the exciting advantages that these languages may have to offer in terms of program correctness, safety, usability, and performance on the hardware of today and tomorrow.
About the Speaker:
Jon Purdy is a software engineer who has worked extensively on programming language technology such as compilers, virtual machines, and garbage collectors, both in industry and as a hobbyist. He has worked on the Mono runtime at Xamarin and Microsoft, developed high-performance site integrity infrastructure in Haskell at Facebook, and co-developed an ActionScript compiler for an implementation of Flash. In his spare time he works on Kitten, a statically typed concatenative programming language.
For more information about this seminar and its speaker, you can visit ee380.stanford.edu/Abstracts/1...
Support for the Stanford Colloquium on Computer Systems Seminar Series provided by the Stanford Computer Forum.
Colloquium on Computer Systems Seminar Series (EE380) presents the current research in design, implementation, analysis, and use of computer systems. Topics range from integrated circuits to operating systems and programming languages. It is free and open to the public, with new lectures each week.
Learn more: bit.ly/WinYX5

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

[@headshock1111]

Who else watches this like once a season

[@notgate2624]

Incredible talk!

[@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".

[@nolan412]

Continuation passing style by another name.

[@nolan412]

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

[@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?

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