4 ms·

I've found this Jon Kalb talk immensely helpful - it's about applying best practices to OOP, and doesn't promote it or discourage it, just describes how to mini

I've found this Jon Kalb talk immensely helpful - it's about applying best practices to OOP, and doesn't promote it or discourage it, just describes how to minimize excess complexity if you're going to use it. (2020) https://youtu.be/c0lutJECNUA https://youtu.be/c0lutJECNUA He also mentions three popular alternatives: 'object-based, static polymorphism, and functional' which is an interesting breakdown. I don't quite get what the author of this 2002 piece is saying here, however: > "And as a result we find that object-oriented languages have succumbed to static thinkers who worship perfect planning over runtime adaptability, early decisions over late ones, and the wisdom of compilers over the cleverness of failure detection and repair." Static polymorphism bad? OOP should be more on the dynamic side?

wsc981 4y ago
> "And as a result we find that object-oriented languages have succumbed to static thinkers who worship perfect planning over runtime adaptability, early decisions over late ones, and the wisdom of compilers over the cleverness of failure detection and repair." The way I read this is that you first have to think out all the objects and the way they interact with each other up front, before starting the development proces. I would imagine with a procedural style this is much less of a concern. You just have data types (adding fields as needed) and implement each procedure as needed as well, one by one. There's no interaction between objects to think about, just manipulations on some data type. But I also think his perspective is not 100% correct. Alan Kay said the main idea about objects is that they send messages to each other (or something like that). Objective-C (like Smalltalk) have objects that act this way and this allows for very dynamic programming where at runtime decisions can still be made easily (e.g. exchange method implementations at runtime or re-route messages). I would imagine this is harder in many other languages that have objects, since they generally don't adopt the idea of sending messages. From Wikipedia [0]: > One notable difference [with regards to C++] is that Objective-C provides runtime support for reflective features, whereas C++ adds only a small amount of runtime support to C. In Objective-C, an object can be queried about its own properties, e.g., whether it will respond to a certain message. In C++, this is not possible without the use of external libraries. The use of reflection is part of the wider distinction between dynamic (run-time) features and static (compile-time) features of a language. Although Objective-C and C++ each employ a mix of both features, Objective-C is decidedly geared toward run-time decisions while C++ is geared toward compile-time decisions. The tension between dynamic and static programming involves many of the classic trade-offs in programming: dynamic features add flexibility, static features add speed and type checking. --- [0]: https://en.wikipedia.org/wiki/Objective-C https://en.wikipedia.org/wiki/Objective-C

wsc981 4y ago

> "And as a result we find that object-oriented languages have succumbed to static thinkers who worship perfect planning over runtime adaptability, early decisions over late ones, and the wisdom of compilers over the cleverness of failure detection and repair." The way I read this is that you first have to think out all the objects and the way they interact with each other up front, before starting the development proces. I would imagine with a procedural style this is much less of a concern. You just have data types (adding fields as needed) and implement each procedure as needed as well, one by one. There's no interaction between objects to think about, just manipulations on some data type. But I also think his perspective is not 100% correct. Alan Kay said the main idea about objects is that they send messages to each other (or something like that). Objective-C (like Smalltalk) have objects that act this way and this allows for very dynamic programming where at runtime decisions can still be made easily (e.g. exchange method implementations at runtime or re-route messages). I would imagine this is harder in many other languages that have objects, since they generally don't adopt the idea of sending messages. From Wikipedia [0]: > One notable difference [with regards to C++] is that Objective-C provides runtime support for reflective features, whereas C++ adds only a small amount of runtime support to C. In Objective-C, an object can be queried about its own properties, e.g., whether it will respond to a certain message. In C++, this is not possible without the use of external libraries. The use of reflection is part of the wider distinction between dynamic (run-time) features and static (compile-time) features of a language. Although Objective-C and C++ each employ a mix of both features, Objective-C is decidedly geared toward run-time decisions while C++ is geared toward compile-time decisions. The tension between dynamic and static programming involves many of the classic trade-offs in programming: dynamic features add flexibility, static features add speed and type checking. --- [0]: https://en.wikipedia.org/wiki/Objective-C https://en.wikipedia.org/wiki/Objective-C