Splitting into two parts due to limitations on per comment length.
Part 1.
a. C++ Never set out to be a full blown purist OO language. It was intended to be exactly as its name suggests an increment of C with OO features. You are rating it using criteria that its original author is unlikely to have shared. b. C++ struct + vtable offering allowed a migration path for at least a hundred thousand developers coming from the C world and the author did not ever claim to be a purist about OO to the best of my knowledge, the the struct with a vtable structure made sense in the days of 120Mhz CPUs. We can live happily today in the multicore multi gigahertz environments of today but back then smalltalk couldn't even get its shorts on while the C++ programs would've completed the race. The dynamic message-passing/actor model of OOP you refer to couldn't compete in those days (it can compete today). c. Sure you could use C and do the name mangling yourself as you suggested, but manual name mangling on a million lines of code borders on a degree of masochism I wouldn't be keen to adopt. Back when a majority of the development community was even struggling to understand OO, C++ lent a helping hand which could help people cross the river, and impure OO that it was people did reach the other side in most cases, the dynamic message passing paradigms got stuck in the vortices of the rivers until it finally took the helping hand of intel's speed blasters to slowly drag them out. d. Java's memory utilisation is way too high. But thats just one of the many factors about evaluating Java. But thats a characteristic which may make it difficult for use in some situations (some embedded scenarios ?). You can still run exceptionally high thruput processing in 4GB RAM using 50+ threads, and thats not a difficult proposition for most servers. e. The speed difference in java you refer to has nothing to do with the security model to the best of my understanding. It has to do with late binding. Sure one could explore things like polymorphic inline caching. But at I wouldn't ever step as far as to say this speed differential is contributing even in the slightest way to OO being a failure. Java actually runs v. v. fast. f. In the OOPSLA debate, they are languages for creating bricks, but bricks do not a city make. Yet you cannot build a city without bricks. So these languages do not satisfy your expectation of prefab units, but the component architectures which were supposed to have delivered them have succeeded far lesser than these languages. In the meanwhile Python and Ruby do allow you to work on slightly broader constructs than bricks alone. g. I did not see anything wrong in your example of
[Error: Irreparable invalid markup ('<x,y>') in entry. Owner must fix manually. Raw contents below.]
Splitting into two parts due to limitations on per comment length.
Part 1.
a. C++ Never set out to be a full blown purist OO language. It was intended to be exactly as its name suggests an increment of C with OO features. You are rating it using criteria that its original author is unlikely to have shared. b. C++ struct + vtable offering allowed a migration path for at least a hundred thousand developers coming from the C world and the author did not ever claim to be a purist about OO to the best of my knowledge, the the struct with a vtable structure made sense in the days of 120Mhz CPUs. We can live happily today in the multicore multi gigahertz environments of today but back then smalltalk couldn't even get its shorts on while the C++ programs would've completed the race. The dynamic message-passing/actor model of OOP you refer to couldn't compete in those days (it can compete today). c. Sure you could use C and do the name mangling yourself as you suggested, but manual name mangling on a million lines of code borders on a degree of masochism I wouldn't be keen to adopt. Back when a majority of the development community was even struggling to understand OO, C++ lent a helping hand which could help people cross the river, and impure OO that it was people did reach the other side in most cases, the dynamic message passing paradigms got stuck in the vortices of the rivers until it finally took the helping hand of intel's speed blasters to slowly drag them out. d. Java's memory utilisation is way too high. But thats just one of the many factors about evaluating Java. But thats a characteristic which may make it difficult for use in some situations (some embedded scenarios ?). You can still run exceptionally high thruput processing in 4GB RAM using 50+ threads, and thats not a difficult proposition for most servers. e. The speed difference in java you refer to has nothing to do with the security model to the best of my understanding. It has to do with late binding. Sure one could explore things like polymorphic inline caching. But at I wouldn't ever step as far as to say this speed differential is contributing even in the slightest way to OO being a failure. Java actually runs v. v. fast. f. In the OOPSLA debate, they are languages for creating bricks, but bricks do not a city make. Yet you cannot build a city without bricks. So these languages do not satisfy your expectation of prefab units, but the component architectures which were supposed to have delivered them have succeeded far lesser than these languages. In the meanwhile Python and Ruby do allow you to work on slightly broader constructs than bricks alone. g. I did not see anything wrong in your example of <x,y> and <42,y>. The languages meet their contracts adequately, and if they do happen to consume more memory in the process, big deal .. its going to be a speck. If it is not going to be a speck, what prevents you from coming up with a supertype (interface in java terms, abstract classes in C++) which just has abstract getX, getY and not X and Y .. you got your memory optimisation too. The inheriting struct model constraing is only in your mind and not a constraint imposed by the languages. h. The fragile base class problem is not a necessary result of every OO design. In fact if you do understand and apply the wide body of knowledge already available especially the Open Closed Principle, Liskov's substitution Principle and Dependency Inversion Principle, you will NOT run into a fragile base class problem. Why blame the languages when some enthusiastic proponents used them to bind themselves into a corner .. but that was then (a decade ago), we have sufficient knowledge to not get into that problem today and be able to use inheritance quite successfully and powerfully. i. I agree functional (actually more appropriately some of the newer dynamic) languages have features which can help implement design patterns in a easier fashion. But thats just one of the multiple trade off points. For your small and orthogonal features do not forget to check out Python and Ruby. And last I checked they were still OO.
Re: This is what I learnt from this post
Part 1.
a. C++ Never set out to be a full blown purist OO language. It was intended to be exactly as its name suggests an increment of C with OO features. You are rating it using criteria that its original author is unlikely to have shared.
b. C++ struct + vtable offering allowed a migration path for at least a hundred thousand developers coming from the C world and the author did not ever claim to be a purist about OO to the best of my knowledge, the the struct with a vtable structure made sense in the days of 120Mhz CPUs. We can live happily today in the multicore multi gigahertz environments of today but back then smalltalk couldn't even get its shorts on while the C++ programs would've completed the race. The dynamic message-passing/actor model of OOP you refer to couldn't compete in those days (it can compete today).
c. Sure you could use C and do the name mangling yourself as you suggested, but manual name mangling on a million lines of code borders on a degree of masochism I wouldn't be keen to adopt. Back when a majority of the development community was even struggling to understand OO, C++ lent a helping hand which could help people cross the river, and impure OO that it was people did reach the other side in most cases, the dynamic message passing paradigms got stuck in the vortices of the rivers until it finally took the helping hand of intel's speed blasters to slowly drag them out.
d. Java's memory utilisation is way too high. But thats just one of the many factors about evaluating Java. But thats a characteristic which may make it difficult for use in some situations (some embedded scenarios ?). You can still run exceptionally high thruput processing in 4GB RAM using 50+ threads, and thats not a difficult proposition for most servers.
e. The speed difference in java you refer to has nothing to do with the security model to the best of my understanding. It has to do with late binding. Sure one could explore things like polymorphic inline caching. But at I wouldn't ever step as far as to say this speed differential is contributing even in the slightest way to OO being a failure. Java actually runs v. v. fast.
f. In the OOPSLA debate, they are languages for creating bricks, but bricks do not a city make. Yet you cannot build a city without bricks. So these languages do not satisfy your expectation of prefab units, but the component architectures which were supposed to have delivered them have succeeded far lesser than these languages. In the meanwhile Python and Ruby do allow you to work on slightly broader constructs than bricks alone.
g. I did not see anything wrong in your example of
Part 1.
a. C++ Never set out to be a full blown purist OO language. It was intended to be exactly as its name suggests an increment of C with OO features. You are rating it using criteria that its original author is unlikely to have shared.
b. C++ struct + vtable offering allowed a migration path for at least a hundred thousand developers coming from the C world and the author did not ever claim to be a purist about OO to the best of my knowledge, the the struct with a vtable structure made sense in the days of 120Mhz CPUs. We can live happily today in the multicore multi gigahertz environments of today but back then smalltalk couldn't even get its shorts on while the C++ programs would've completed the race. The dynamic message-passing/actor model of OOP you refer to couldn't compete in those days (it can compete today).
c. Sure you could use C and do the name mangling yourself as you suggested, but manual name mangling on a million lines of code borders on a degree of masochism I wouldn't be keen to adopt. Back when a majority of the development community was even struggling to understand OO, C++ lent a helping hand which could help people cross the river, and impure OO that it was people did reach the other side in most cases, the dynamic message passing paradigms got stuck in the vortices of the rivers until it finally took the helping hand of intel's speed blasters to slowly drag them out.
d. Java's memory utilisation is way too high. But thats just one of the many factors about evaluating Java. But thats a characteristic which may make it difficult for use in some situations (some embedded scenarios ?). You can still run exceptionally high thruput processing in 4GB RAM using 50+ threads, and thats not a difficult proposition for most servers.
e. The speed difference in java you refer to has nothing to do with the security model to the best of my understanding. It has to do with late binding. Sure one could explore things like polymorphic inline caching. But at I wouldn't ever step as far as to say this speed differential is contributing even in the slightest way to OO being a failure. Java actually runs v. v. fast.
f. In the OOPSLA debate, they are languages for creating bricks, but bricks do not a city make. Yet you cannot build a city without bricks. So these languages do not satisfy your expectation of prefab units, but the component architectures which were supposed to have delivered them have succeeded far lesser than these languages. In the meanwhile Python and Ruby do allow you to work on slightly broader constructs than bricks alone.
g. I did not see anything wrong in your example of <x,y> and <42,y>. The languages meet their contracts adequately, and if they do happen to consume more memory in the process, big deal .. its going to be a speck. If it is not going to be a speck, what prevents you from coming up with a supertype (interface in java terms, abstract classes in C++) which just has abstract getX, getY and not X and Y .. you got your memory optimisation too. The inheriting struct model constraing is only in your mind and not a constraint imposed by the languages.
h. The fragile base class problem is not a necessary result of every OO design. In fact if you do understand and apply the wide body of knowledge already available especially the Open Closed Principle, Liskov's substitution Principle and Dependency Inversion Principle, you will NOT run into a fragile base class problem. Why blame the languages when some enthusiastic proponents used them to bind themselves into a corner .. but that was then (a decade ago), we have sufficient knowledge to not get into that problem today and be able to use inheritance quite successfully and powerfully.
i. I agree functional (actually more appropriately some of the newer dynamic) languages have features which can help implement design patterns in a easier fashion. But thats just one of the multiple trade off points. For your small and orthogonal features do not forget to check out Python and Ruby. And last I checked they were still OO.