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.

Comments:

See John Klensin's comments (he was chair of X3J1, PL/1) at http://www.ncits.org/archive/2003/in030390/in030390.pdf. Section 8 in particular. This document is a restatement of his position; I did not continue to search for the original statement putting PL/1 into maintenance mode. dick w

Posted by Dick Weaver on December 15, 2005 at 03:00 PM PST #

Dick, as always, you've come up with a great bit of history. Of course, the PL/1 case is what probably drives folks in other communities to avoid such an outcome. PL/1 itself stopped evolving (which Les is arguing is probably good) but as best I can tell, PL/1 did not wind up begatting any replacement either. It turned out to be a cul-de-sac. No doubt there are still a number of PL/1 users; but it's quite a contrast with, say, the C->C++ transition or the following Java migration. C and C++ continue to thrive as well as having spawned successors.

Posted by Keith Bierman on December 15, 2005 at 03:57 PM PST #

If the justification of "never cause old code to fail" is economic the cost of forcing the change to a successor language, algol - C, C - C++, C++ - java has got to be much worse than converting from Fortran with statement functions, say, and Fortran with internal procedures. Evolving the same language has much to recommend it economically but Hatton has a point. If the standards bodies do not remove bad features as well as adding new and better ones we get limited improvement and unsustainable complexity.

Posted by Lawrie Schonfelder on December 15, 2005 at 11:09 PM PST #

Post a Comment:
Comments are closed for this entry.
About

khb

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today