BA Chap. 14 - Rereading the Classics

One of the reasons I decided to pursue my career into Software Engineering is that developing software gives one the opportunity to create something of practical use in a relatively short time, even if it's programming something as simple as a time clock. But I admit that I've fallen in the trap of spending too much time trying to make UML diagrams as beautiful as possible, and resulted in delivering incomplete code. This article is sort of a wake up call to those who are more concern about decorations and ornaments as opposed to features that are more pragmatic.

Having said that, I found the article's comparison of languages such as Smalltalk, C++, Java, & Python to be very informative because it gives a better explanation of the advantages & disadvantages of each of these languages from an object-oriented perspective. For example, every newly defined class in Smalltalk is inherited from another class, which is in clear violation of the "Favor Composition Over Inheritance" principle. Interfaces in C++ is limited to defining abstract classes whereas in Java, one can explicitly define interfaces. Despite Smalltalk's limitations, though, having a purely object-oriented language "allows us to limit the number of syntactic constructs in the language". Lisp is another example of a purely object-oriented language where program and data are "lists".

I do remember half-a-decade ago that I was annoyed by the fact that Java did not support templates. Then they came out with Generics in SE 5.0 but this didn't calm my frustration because I still had to define a type through an interface as the article pointed out. Because of this, one could argue that Java is slightly limited in its support for polymorphism.

The biggest take away was that the argument of "statically typed languages being more protective of coding errors" is weak because the most difficult errors are actually run-time bugs. Syntax errors are straight-forward to figure out, especially with the use of IDEs such as Eclipse and Visual Studio. Appropriate run-time error messages for syntax errors and a call-stack should be sufficient for most debugging purposes.