Richard Feldman — The Next Paradigm Shift in Programming

Originally, GOTO statements were widespread. Then structured and procedural programming appeared, and now that's the normal way of doing conditionals, and the previously widespread GOTO statements are widely considered an antipattern. When garbage collection first appeared, it was largely ignored outside academia. Then hardware got faster, and since the 1990s garbage collection has become the norm in industry.

When functional programming first appeared, it was largely ignored outside academia. In the last decade it has started getting more popular. What will be the next paradigm shift in programming...and has it already begun?

[qmster]

Instead of the Wikipedia for Distributed System, you could have referenced Actor Systems.
This is where message passing happens between encapsulated entities within one program, and is often used as a *solution* to the complexities of true distributed systems. See Actix, bastion, Akka, and of course Erlang/Elixir. Pony language, too.

[chaouanabil]

I still see Alan kay perspective for OO design is exactly about what the Actors model offers: a set of distributed (physical location is transparent) objects that maintain and encapsulate their internal state and communicate by passing messages (ideally in a non-blocking way).

[OwenBickford]

Excellent talk and historical perspective. Richard is very skilled at presenting a lot of information in a short amount of time without being overly dense. I have one small nitpick, though.
50:34 You _might_ want to discuss Erlang in the next iteration of this talk. It was developed during this time as a functional programming language and *deployed* into production Ericsson phone switches. The derivative language Elixir has spawned more interest in the underlying Erlang during this FP wave we’re riding. If you enjoy piping data through functions in Elm, you’ll love designing systems in Elixir and Erlang.

[Tupster]

He said C *declarator* syntax was a failure and indeed a lot of languages, like Java and C++, which directly borrowed from C/C++ abandoned it.

[dorusie]

Interesting that the guy said that they wrote the whole program, and then rewrote it in OOP. One of the biggest problems with OOP is that you have to go full philosophical on what constitutes and separates objects. When you get it wrong you'll have to shift in place during development and then you get very esoteric object(handlers). If you already have the entire layout of the program, these are way easier to identify.

[mohamedaymanerrahmouni]

I'm a novice in computer science, I think I just got a free lesson about programming paradigms, Thanks a lot for the lecture/presentation!

[VladyVeselinov]

Watch out y'all, paradigms are like tools, different tools work well for different jobs. Don't fall into the trap of trying to solve all types of problems with one paradigm. There are always trade-offs. The modularity and easy refactoring you gain with functions you pay with cascading abstractions, every function that takes another function as a dependency makes your program harder to read and you have to be very careful about your abstractions.

[bradmccoy]

Fantastic!
I want more. I want the experience of a developer from each language summarized into videos. What works and what doesn't work. When does something work and when does it fail. What caused a rewrite. When was performance lost. I couldn't leave the room without pausing the video because I didn't want to miss anything. And because of this video I have been pushed passed a stuck point and I now have a few ideas that I will be working on for the months ahead.
Thank You!

[IliaFrenkel]

Very well crafted presentation. Thank you!

[heater]

Bjarne did not say that C syntax was an experiment that failed, curly braces, parenthesis, semicolons etc.

What he said was that the "C declarative syntax" was an experiment that failed.

A view I can sympathize with.
Much of the rest of C surface syntax for conditionals, loops, functions, etc, lives on in C++, Java, Javascript, the new kid on the block Rust, and many others. Where it works very well.
Far from a failed experiment.

[ClearerThanMud]

To the interesting list @33:08 I would add two things:

1. Polymorphism. But it turns out that both static and dynamic polymorphism are possible in non-OOP languages. Rust offers static polymorphism through generics and dynamic polymorphism through trait objects. And Rust's non-OOP polymorphism is arguably better in that you can safely make somebody else's type implement YOUR interface.

2. object.method() syntax, which improves IDE completion and allows for more consistent naming. But it turns out that you can have that in a non-OOP language, too. Rust has it, for example.

[EdwardGrigoryan]

You have no idea how confusing OOP was for me even in high school. Teachers and YouTube videos where presenting OOP as a solution to every problem. OOP has created more frustration than solutions.
I am glad I am not alone that have noticed the importance of modularity over encapsulation.

[AnthonyDunk]

Interesting talk. I agree that functional programming may be the way of the future, but the power of familiarity should not be underestimated. I've tried to transition from Java to Kotlin (which supports FP), but when push comes to shove and I'm in a hurry to produce some working code, I still find it much more productive to use Java. I think familiarity explains the meteoric rise of C++ in the 90's too (C++ is C with stuff added, and still compatible with C). As someone who earns a living from software development, its not always about what is the best language from a technical stand point, but is usually about what you can be the most productive in.

[grkuntzmd]

Outstanding talk! I've been a software developer since the mid-1970 (high-school) and knew a lot of what you talked about, but not all.

[Aki-to]

Such a great lecture. Thank you so much.

[patrickmichl]

Very engaging presentation - I'm looking forward to a sequel. From my personal observations It looks like we are currently experiencing a pradigm shift towards functional reactive programming (FRP): Whats missing in functional programming is the ability to efficiently organize (and dynamically reorganize) asynchronous processing structures. In FRP this issue has been addressed by dynamically binding functionals and observables to directed acyclic graphs, which eventually allows meta-programming in terms of dynamic graph optimization.

[mhmdkzr]

I think it's important to separate code structure from runtime structure.
Organizing code like a distributed system makes it unnecessary complex, but it is actually very beneficial to design the "runtime" with isolated processes that only communicate via message passing.
This is essentially how erlang/elixir achieve the level of fault tolerance and concurrency that they're famous for.

[ericpmoss]

I hate the purity tests. Use a multi-paradigm language (e.g. Common Lisp) and avoid tortured problem reformulations. Things fall apart when programmers have to be in service of a paradigm rather than a problem.

[SimGunther]

"Next paradigm shift" (functional programming) starts at 41:51

[youkenez]

Saying "function style is to avoid mutation and side effects" is like saying flying is to avoid touching the ground while moving. It's technically true but doesn't really help with the understanding. What could help is that you need to decompose the task into functions that (1) experience the outer world only through their input parameters (2) influence the outer world only through their output values. It's good because, when writing that function you always now where to start (input) and where you need to get to (output). Otherwise this is a very valuable video emphasising many important thoughts that are not mentioned in other FP-advocate talks, thanks for creating and sharing!