Thursday December 15, 2005 Keith Bierman's Weblog
Keith Bierman's Weblog
Thursday December 15, 2005
Language Standardization considered harmful?
Les Hatton makes a reasonable argument for it.
....This is exacerbated by the process of language standardisation. We would all agree that standardisation is an important step forward in engineering maturity, however, if the
process of standardisation ignores historical lessons, then this may well be worse than useless. Language standardisation suffers from two important drawbacks as practised today. First of all, language committees (and I’ve sat on a few in my time), have an irresistible temptation to fiddle. They will persist in adding features which seem
like a good idea at the time, without any notion as to whether they will work or not. Of course, this is normal in engineering. It is similar to the role of mutation in Darwinian evolution. What is not normal however is the second drawback. This embodies the opposing principle to control process feedback. It is called “backwards compatibility” and is often expressed in the hallowed rule that “thou shalt not break old code”. So drawback one guarantees the continual injection of features which may or may not work, (most don’t) and drawback two guarantees that you can’t take them out again. In other words it is a technique whereby learning from previous mistakes is guaranteed not to take place. In backwards compatibility, you take as a starting point all the failure modes which have occurred so far and then add new and poorly understood failure modes. We call the result a modern programming language. If other engineering disciplines pursued this doctrine, hammers for example would have micro-processor controlled ejection mechanisms to cause the head to fly off randomly every few minutes as they used to about 40 years ago when made with wooden handles. Not surprisingly, they were redesigned fairly quickly.
The longtime reader (all three of you) may recognize some resonance to my comments to Bill Moffitt in a previous entry. I think that the rule about not breaking existing code is a must; but that the consequence is that (as I described to Bill in the case of Fortran) that the model for language evolution ought to be more like Algol (begat C, begat C++ begat Java) not that the old language necessarily dies ... but that the Standards group should restrict itself to a revision or two with new substantive features and then restrict themselves to cannonization of existing practice and harmonization of feature sets (or bindings to other things, etc.). The creative energy of the language's supporters should go into the "next language" which will be free to discard the bits of the original language found to be errors in practice.process of standardisation ignores historical lessons, then this may well be worse than useless. Language standardisation suffers from two important drawbacks as practised today. First of all, language committees (and I’ve sat on a few in my time), have an irresistible temptation to fiddle. They will persist in adding features which seem
like a good idea at the time, without any notion as to whether they will work or not. Of course, this is normal in engineering. It is similar to the role of mutation in Darwinian evolution. What is not normal however is the second drawback. This embodies the opposing principle to control process feedback. It is called “backwards compatibility” and is often expressed in the hallowed rule that “thou shalt not break old code”. So drawback one guarantees the continual injection of features which may or may not work, (most don’t) and drawback two guarantees that you can’t take them out again. In other words it is a technique whereby learning from previous mistakes is guaranteed not to take place. In backwards compatibility, you take as a starting point all the failure modes which have occurred so far and then add new and poorly understood failure modes. We call the result a modern programming language. If other engineering disciplines pursued this doctrine, hammers for example would have micro-processor controlled ejection mechanisms to cause the head to fly off randomly every few minutes as they used to about 40 years ago when made with wooden handles. Not surprisingly, they were redesigned fairly quickly.
(2005-12-15 15:39:39.0) Permalink Comments [3]
Calendar
| « December 2005 » | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 10 | ||||
11 | 13 | 16 | 17 | |||
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
| Today | ||||||
RSS Feeds
All
/General
/Java
/Music
Search
Links
Navigation
Referers
Today's Page Hits: 96