6 ms·

Part of the reason it comes up frequently is that a large number of educated, experienced programmers have decided that a toolbox without OOP is a better toolbo

Part of the reason it comes up frequently is that a large number of educated, experienced programmers have decided that a toolbox without OOP is a better toolbox, than a toolbox with OOP. But, it is difficult to throw out a bad tool when there appears to be no alternative that delivers its benefits. When that happens, when a tool is devised that delivers what OOP delivers without the problems -- such as the diamond problem, or the problem of having to decide "where" to put functions, or the problem of generic functions of more than one argument -- then at that time those very problems will become much easier for everyone to acknowledge. The same thing will happen to classes and synchronous message passing, that happened to inheritance. In that case it took a while but an alternative came in the form of interface subtyping or predicate based subtyping, and then it was easy to see that inheritance was more trouble than it was worth.

robomartin 14y ago
My approach is a bit different probably because I've done a lot of work across a range of disciplines while using different tools. I have yet to run into a problem that was unsolvable due to the tools or language selection made. I don't think the tools or languages have ever caused undue delays, bugs or unreliability in any projects I've had part on. From robotics and low-level real-time embedded to image processing, DBMS and even hardware development (Verilog, VHDL). Not once have the tools and languages been brought up as an issue. In my experience most problems come from bad design, bad programmers, terrible data representation, incomplete specs, bad management and a myriad of other issues. Don't get me wrong, I am first in line for a good-solid discussion on how to properly split a bit in two. However, when it comes to the business of making money by creating products that involve some kind of software, well, pick a tool based on experience and focus on delivering a solid product. No excuses.

robomartin 14y ago

My approach is a bit different probably because I've done a lot of work across a range of disciplines while using different tools. I have yet to run into a problem that was unsolvable due to the tools or language selection made. I don't think the tools or languages have ever caused undue delays, bugs or unreliability in any projects I've had part on. From robotics and low-level real-time embedded to image processing, DBMS and even hardware development (Verilog, VHDL). Not once have the tools and languages been brought up as an issue. In my experience most problems come from bad design, bad programmers, terrible data representation, incomplete specs, bad management and a myriad of other issues. Don't get me wrong, I am first in line for a good-solid discussion on how to properly split a bit in two. However, when it comes to the business of making money by creating products that involve some kind of software, well, pick a tool based on experience and focus on delivering a solid product. No excuses.