Any Scott Wlaschin's speech is a quality mark. Thanks!

I've been programming like this for a few years now and it has been a game changer. Being able to reason about pure logic and complicated runtime state changes separately just scales so much better, is easier to debug, maintain, understand, etc.
This is btw. implemented in frameworks such as Redux, ELM (view-update-model), FRP and similar. I would argue that even React works like that: you have pure, declarative components, event handlers and state management. While they can be kind of put together they are conceptually separated.
The idea is always the same: you have a functional/pure part separated from the IO part. They all only disagree on, or have a different vision of, how to do this exactly.

Actually, this pattern is very widespread when I think about it - seems the entire industry silently embraced it without many people even noticing. My theory is anyway that sooner or later FP will dominate development. There is hardly any mainstream toolkit, language or framework that doesn't include at least a few FP-concepts - and it's getting more.

I've been using this pattern for some years. Data train goes from station from station, no side effects. Just accumulating operations as data (makes testing very easy is well). On some stations, some choo-choo is performed (fire the side-effects) and then the train continues its journey...

A presentation by Scott Wlaschin - instant click!

To me, in the narrow realm of software engineering, systems and software design are the two of the most sexiest areas ever. The best part is it will never get old or out of fashion.

"Pipeline-oriented programming" is more properly termed "concatenative programming".  There is an entire family of languages devoted to it, namely Forth, Joy, Factor, and Listack.  There is even a concatenative hack of Clojure called Gershwin.  Manfred von Thun did a lot of the theoretical work on this programming style 20 years ago.  It's really the ultimate extension of function composition.  The basic principle is simple - you send data through functions in the order in which they act upon the data.  (As opposed to the usual inside-out or backwards function call style.)

This is wonderful!! What a great talk!! Thanks Scott!

Amazing presentation.

Per usual, thanks Scott.

No one's talking about the fact that other the course of the talk he managed to sing the lyrics to "Never gonna give you up" by Rock Astley?

We got Rick-rolled in an NDC talk :D

Choice / Choose - the input can only be one of the possible options. We compose all options and a single choice is made  - Sum types / Sealed classes

Seq / Ordered conditions - we compose an ordered set of options and process input in order and choose one that matches - Routing

And All - we break down complex conditions into set of simple ones. The input has to satisfy all of them

Sequential transformations- we process the input via a series of transformations. Each one can be conditional and successive ones can do retransformation.

Parallel transformations- do the transformations in parallel. Might require a combine or reduce operation at the end

A nice approach to software development and coding 👨‍💻😎, but I find it somewhat similar to the middleware and loop pipe approach that was introduced in .NET Core 3.2, and also bears resemblance to the Aspect-Oriented Programming approach that focuses on the business management layer, so I see it as taking an advantage from AOP. And an advantage of middleware, and the result was this beautiful approach. I do not deny that it contains its own features, but the basic things that represent the essence of this approach are what I mentioned previously. Thank you, teacher, for this nice lecture.

Hmm. This is what I've been doing for years, but I've been calling it OOP. I probably started building like this around the time I discovered TDD or Clean. What a great talk.

actually functional programming

This is actually quite a common architecture when building compilers.

can we overload operator | in C#

PowerShell!

I'm a fan of fluent interfaces as well as functional programming styles, but when it comes to pipelining, I'd love to see an example of connecting functions with more complex signatures.

that can get tricky..

This is just layered architecture, which can be done with OOP or bricks, or even stones.
If one tends to spaghettify their objects, they'll definitely do the same for functions.

OOP is so weird: Why would you imprison your functions in 'objects' (which are just weird self-referential mutable records)?