To me, gradual language design doesn’t really work. Because once you create bad rules, you can’t change them in later time without breaking things. C++’s great success was that it was a gentle transition from C. But it paid it with poor design decisions which were harder to fix later on. Make it too radical, and people would hate it. That’s probably one of the reasons Eiffel failed to gain traction. This isn’t an attack on Stourstoup. There was a discussion a while back that the concept of the C drive in Windows (the two floppies are A and B) created a stupid legacy that would be hard to break.
Guess the audience is full of Java devs… They're already using (old) C++ they just call it the JVM. Sure lambdas are "new" to C++, thing is any of the programing languages cited didn't have to be backwards compatible with C (some of them came before C). Java doesn't have to compile or run fast (or if it does it's failing at least at the former. And in most cases, without careful precautions, at the latter. )
This talk is full of jokes, and "C++ doesn't leak" is the best one. As if smart pointers don't cause reference cycles, which are nothing but memory, and occasionally resource, leaks.
Let me contemplate the meaning of that as I sit down on my Chair object of a Chair class derived from an abstract base class called 'Furniture' that has virtual function named action() that I override with my sitting instructions and which is ultimately managed by a ChairHandler Class. Hmm... I wonder how OOP wrecked the programming industry.
Chair is a Furniture to furniture store as well as is a Table(1). To a woodcutter sitting down for lunch a Chair is a Stump or a conveniently shaped Rock(2). However; when you have a tree trunk or steps in front of a museum, you should think of Benches(3). Just as in natural languages, everything is context dependent. That is why namespaces and modules are great for separation of concepts. (1), (2) and (3) all are objects that *could* have method sit() but sitting (1) is out of scope when you need to describe a store. (2) and (3) both are for sitting, but Bench should have sit(position) and maybe lie().
"Object-oriented programming" is one of the most poorly defined things in IT. There is absolutely no consensus. There are many different interpretations of this concept. There are broadly two general schools of OOP. One is from Alan Kay and the other is from Bjarne Stroustrup/Kristen Nygaard. Until we can nail down the definition, these kinds of debates, including the one in this video, are like arguing about how many angels can dance on the head of a pin. It's rather a waste of time.
@@ChrisAthanas It's an open secret. Everyone knows it but few speak out. That includes the kool-aid drinkers, which is why they get so upset when you pull back the curtain. They can stay happily deluded as long as everyone around them pretends to believe in the lie.
I don't get this obsession with "modeling the real world". Programming problems , mmost of the times,, doeflect the real world at all... It's a fools errand, it creates a new problem besides the one we actually need to solve
I think: modern programming is not programming, it's spanking fucking code. Don't get me wrong, abstraction is good evolution like from assembler to c++ and more but it was natural. Today is overhead and something there is going wrong way. Next time we will be discuss how to write sites in c++
@@egorsozonov7425 yes it seems the microservice is closer to what Alan kay was referring to, but not using the c-like languages for the implementation. I'm sure he was thinking of a language more like HyperTalk with low-level extensions written in C-like languages. We need a better abstraction than these low level languages, they are just too detailed for most use cases and prone to errors and slow to implement
@@ChrisAthanas Nah, Stroustroup just realized that you cannot solve all the problems using a hammer. C++ doesn't offer the best hammer, but it is a more complete toolbox. So if you want to build a house, you better don't limit yourself to just the hammer.
