![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Geek thoughts
Jun. 14th, 2004 03:25 pmA comment in another thread regarding the lack of true class-methods in Java (and the inevitable "C# is bettah!" content-free rejoinder) got me thinking on something I read earlier on the bus, regarding Java Generics, and how they're a small step above macros in their type safety. (Hint: it's called 'type erasing', if that gives you an idea on which direction it goes...)
Why is that some languages seem like such a mish-mash of warring styles (C++, I'm looking at you...) and others seem so simple it's a wonder anything is ever accomplished with them (Objective-C anyone?), yet they can do just about everything that one can think of?
Object model. A clean object model, with introspection, reflection, genericity, dynamic binding, and late binding will let you do basically anything allowed by the theoretical foundations of object-oriented languages. (Abadi and Cardelli's _A Theory of Objects_ is a good start for this.)
Languages that lack some features of this model try and glue them on ad hoc via 'new features'. Templates come to mind. No one who has ever used Smalltalk or Obj-C to any measure can figure out what the big deal is about templates... they just aren't needed in the dynamic languages. Ditto for things like C#'s 'delegate' keyword. Or C++ RTTI. Etc.
OTOH, having clean and clear code is a big win. (Wait, did I just compare C++'s templates to clean and clear code? Shoot me.) Actually, that exemplifies my point beautifully. *CLEAN* code is good. *KITCHEN SINK* code to get around holes in the basic model of a language is not.
And in that respect, C#'s delegate is kinda nifty - it provides a single point of reference to say "Aha! So they're using a delegate object, and here it is..." No idioms to have to search for this particular implementation of, etc. It's obvious. And it's even useful. My only concern with it is, and perhaps someone can answer this for me, is it *necessary*? Is C#'s object model such that one could not do this otherwise, and do it easily?
All too often I see keywords, as tacked on 'features', being used to shore up fundamental holes in a basic language theory. The language designers biffed it up front, so they have to keep adding new thingamabobs to satisfy critics... and all those thingamabobs inevitably lead to a kitchen sink approach that pleases no one trying to get real work done... too many poorly interacting or downright conflicting language 'features' need to be used, worked around, cussed at, and eventually abandoned. But man, it sure looks good on a bulleted list.
Sounds like Word, now that I think of it - just keep tacking on 'features' that get around problems in the basic underlying design, and hope people swallow that it's 'innovation'. Uh, no.
Which leads me to today's Church of Geek Homily: "The cleanliness of a language's object model is inversely proportional to the size of its keyword list (including operators)."
Anytime you look at a language, and see a nifty new keyword or construct that looks to provide a wealth of usability, stop, and think to yourself "What hole in the object model was this designed to cover up?" If you can't find one, chances are that the designers may have stumbled onto something of worth, and one to consider as adopting as canon for language design. But I'm willing to bet that 99% of the time, you'll find that hole.
Why is that some languages seem like such a mish-mash of warring styles (C++, I'm looking at you...) and others seem so simple it's a wonder anything is ever accomplished with them (Objective-C anyone?), yet they can do just about everything that one can think of?
Object model. A clean object model, with introspection, reflection, genericity, dynamic binding, and late binding will let you do basically anything allowed by the theoretical foundations of object-oriented languages. (Abadi and Cardelli's _A Theory of Objects_ is a good start for this.)
Languages that lack some features of this model try and glue them on ad hoc via 'new features'. Templates come to mind. No one who has ever used Smalltalk or Obj-C to any measure can figure out what the big deal is about templates... they just aren't needed in the dynamic languages. Ditto for things like C#'s 'delegate' keyword. Or C++ RTTI. Etc.
OTOH, having clean and clear code is a big win. (Wait, did I just compare C++'s templates to clean and clear code? Shoot me.) Actually, that exemplifies my point beautifully. *CLEAN* code is good. *KITCHEN SINK* code to get around holes in the basic model of a language is not.
And in that respect, C#'s delegate is kinda nifty - it provides a single point of reference to say "Aha! So they're using a delegate object, and here it is..." No idioms to have to search for this particular implementation of, etc. It's obvious. And it's even useful. My only concern with it is, and perhaps someone can answer this for me, is it *necessary*? Is C#'s object model such that one could not do this otherwise, and do it easily?
All too often I see keywords, as tacked on 'features', being used to shore up fundamental holes in a basic language theory. The language designers biffed it up front, so they have to keep adding new thingamabobs to satisfy critics... and all those thingamabobs inevitably lead to a kitchen sink approach that pleases no one trying to get real work done... too many poorly interacting or downright conflicting language 'features' need to be used, worked around, cussed at, and eventually abandoned. But man, it sure looks good on a bulleted list.
Sounds like Word, now that I think of it - just keep tacking on 'features' that get around problems in the basic underlying design, and hope people swallow that it's 'innovation'. Uh, no.
Which leads me to today's Church of Geek Homily: "The cleanliness of a language's object model is inversely proportional to the size of its keyword list (including operators)."
Anytime you look at a language, and see a nifty new keyword or construct that looks to provide a wealth of usability, stop, and think to yourself "What hole in the object model was this designed to cover up?" If you can't find one, chances are that the designers may have stumbled onto something of worth, and one to consider as adopting as canon for language design. But I'm willing to bet that 99% of the time, you'll find that hole.