On 2009-11-20, at 13:18, Rami Ojares / AMG Oy wrote:

> Thanks for the links!
> I promise to read them (but that does not mean I am going to understand them).
> 
> > the collective (40+ year) experience in the O-O community is that
> > whenever you think you need to say super.super, or directly call an
> > inherited method in a superclass, you will end up regretting it if you > 
> > do, inevitably at a later time or in some descendant class when the
> > little "work around" will have been long forgotten.
> 
> Well...I think there is even larger consensus in the community about the 
> dangers of loosely typed languages (like laszlo).
> 
> All the odd and implicit rules of type casting keep me on my toes all the 
> time. Not to speak of all the odd behaviours echoed in the remotest parts of 
> my code because some variable had an unexpected type causing all sorts of 
> secret black magic :-)

The implicit casts of Javascript keep everyone on their toes.  So does the idea 
of having two different "null" values.  Brendan will be the first to admit many 
decisions that were made in expedience that he wishes he could take back.

I don't want to start a flame war by arguing static vs. dynamic typing.  
Personally, I think there are good arguments for both.  As I have said before, 
I like dynamic typing for prototyping and (what I call) "evolutionary" 
programming (when you are quickly turning around prototypes on user feedback).  
I like static typing for eliminating the possibility of runtime errors in a 
deployed product.

If you want to add to your reading stack, here are two really interesting books:

"The Design and Evolution of C++", Stroustrup
"Advanced C++ Programming Styles and Idioms", Coplien

The first provides some really interesting insights as to why C++ (and its 
descendants, like Java) are the way they are.  Stroustrup is very balanced in 
describing decisions that were made for truth and beauty, vs. those that were 
made for expediency.

The second is, as I see it, the story of a developer who wishes he could be 
developing in Lisp and the agony he was put through trying to emulate the more 
powerful features in C++ because his management was sure C++ was the right tool 
for the project.





Reply via email to