|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: ISO and the Standards Golden Hammer (was Re:[xml-d ev] You
Rick Marshall wrote: > it [COBOL] also helped create the myth (and to some > extent reflected the optimism of the time) that > anyone could be a programmer (and by implication > a good programmer) with a language that allowed > them to express their instructions more naturally. > with hindsight we know that's not true. just like > not everyone, with best will in the world, can > become a "brain surgeon". Sure, not everyone can be a "brain surgeon" but just about anyone can learn to use a pin or tweezers to pull a splinter out of your toe (minor surgery)... Similarly, just about anyone with an above-room-temperature IQ can learn to become a "programmer." The question isn't one of kind, it is one of quality. Different languages serve different purposes and different audiences. One of the wonderful hopes for COBOL was that it would be language that non-programmers could *read* -- not necessarily *write*. The idea was that managers would be able to review the code to ensure that algorithms were correct. And, one of the features that was intended to encourage this was the fact that COBOL supported really long variable names (at the time, that was unusual). I remember listening to Grace Hopper complain -- at Digital, where she ended her career -- about the way people were creating variable names. She said that you were supposed to have readable variable names like "last-years-net-revenue" so that managers could review the code, however, lazy programmers were using variable names like "LYNR" to save on typing. Worse, the "data dictionary" fad was heavily in force in those days and even the vaguely meaningful "LYNR" was being replaced by indecipherable crud like "A0942B"... I also can't help being reminded of the debates we had in the Visual Basic team at Microsoft about some of the essential elements of VB's design... There were many things that you couldn't do with the original Visual Basic but that wasn't seen as a problem since the language was targeted at "Solution Builders" not "Component Builders." We explicitly decided, for instance, to support only aggregation, not inheritance, in order to keep the complexity level low enough to empower people who combined together components written by Component Builders (using C++, etc). If we had supported inheritance, pointers, etc. in Visual Basic, it would have been "just another language" and would never had had the success it has had. VB was built for folk who knew more about the applications they wanted to use and were closer to the business problem than the component builders who were closer to the machine and understood more about computers than business processes. Of course, this distinction has been lost today. The Visual Basic of today is little more than "yet-another-syntax" for doing .NET stuff. We have lost something important and useful by making it harder for the non-CS geeks to build applications. Just about everyone can be a "programmer" and just about everyone has a chance to be "excellent" at what they do as long as they are careful not to go beyond their limits. It is no "myth" that everyone can be a "good programmer." The myth is that "programming" is a single, undifferentiated set of skills. It is not. There are many kinds of programming and I've never met anyone who was "good" at all of them. bob wyman
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








