home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!portal!lll-winken!fnnews.fnal.gov!mp.cs.niu.edu!linac!uchinews!alex!dave
- From: dave@alex.uchicago.edu (Dave Griffith)
- Newsgroups: comp.lang.misc
- Subject: An open letter to Bob Silverman
- Message-ID: <1992Nov13.220728.25240@midway.uchicago.edu>
- Date: 13 Nov 92 22:07:28 GMT
- Sender: news@uchinews.uchicago.edu (News System)
- Organization: University of Chicago
- Lines: 90
-
-
- As an attempt to head off the incipient Curricula-Vitae-size wars,
- I will attempt to give Mr. Silverman a brief overview of comp.lang.misc.
- At it's best, comp.lang.misc provides a good place for informed discussion
- of language design issues. Several designers and informed programmers post
- fairly regularly here, and after the newbies wash out, a given discussion
- can have a very high S/N ratio indeed. We also field the occasional questions
- about availability of languages that have no group. They're quick, and
- there are enough people in this group who know wierd languages that someone
- always knows. Meatier than comp.object, more practical than comp.theory,
- far less ideology than comp.lang.*. All in all, my favorite place on the
- net.
-
- And then Herman Rubin starts posting.
-
- Now, this current rehashing of the _twenty_year_old_ structural programming
- debate may very well be new to you. I assure you that it is not new to
- Herman Rubin. For deep psychological reasons known only to himself, hrubin
- restarts this old war approximately every four months. Now, presumably he
- knows what's going to happen, its been happening for years. First, he will
- post a fairly inflammatory remark about "structured language bigots". Now
- this is Usenet, and we've got a fair number of undergrads here, some flush
- with their first exposure to programming. These undergrads quickly step in
- and give their best recitations of the virtues of structured programming.
- Herman then flames away at their lack of real world understanding, and the
- occasional user who needs to squeeze every cycle out of the computer. They
- repeat all of the old dogma about reusability, clarity, modularity and all of
- the other "ities". Herman fires back with one of his patented complaints:
-
- 1)I need a language with which I can access the hardware directly, or at
- least I would need to access the hardware directly if it offered the
- instructions I need, which it doesn't, because no language ever
- provides it. (This one always merits crossposting to comp.arch,
- if the discussion wasn't crossposted there already.)
-
- 2)I feel my code is most readable if the variable names are one letter
- long, and the code is not cluttered up by comments. (He did at one
- point allow that if more than 26 identifiers were needed, one letter
- names in different fonts might be necessary)
-
- 3)This (insert HLL feature) might be okay if the compiler could
- implement it efficiently, but as is I must be able to do it by
- hand, using low level features.( Almost invariably, the feature
- has capable of efficient compilation for at least a decade.)
-
- 4)This (insert HLL feature) would be useful, but it isn't available.
- (Almost invariably, the feature has been available in half a dozen
- languages for over a decade. Posts to this effect are dealt with
- by picking a minor syntactic nit, or by saying "I'll have to look at
- that language".)
-
- 5)I need a language which has completely fluid syntax. It should be
- absolutely trivial, for instance, to mingle C and Fortran code line
- by line. (No need to ridicule this, it's self-ridiculing.)
-
- ...and others which can be supplied by those with better memories than I.
-
- Now none of this is meant belittle Herman's actual computer problems.
- Current languages, particularly the most commonly available languages, are
- often poorly suited for his problem domain. The reason for this is pretty
- simple. Herman Rubin and people like him form a very small market. Herman
- Rubin is not a programmer, he is a mathematician who programs. His programs
- are small enough to be written and understood by one person, usually in one
- day. His programs take vast computational resources, and must be very fast
- indeed. His programs are rarely read by anyone but himself. Portabilty
- is simply not an issue. Individual bits need to be accessed. Now reading over
- this list, it should be clear to all involved that structured programming is
- not the way to go for hrubin. It fixes problems that he doesn't have, and
- imposes slight costs that he can't afford to pay. No responsible programmer
- would suggest that he restrict himself to a methodology if it's costs to him
- exceeds his benefits. He is correct in saying that current languages and
- methodologies don't fit his needs.
-
- However, he is also deluding himself if he feels that there are enough people
- out there like him that it makes sense for language designers to give a damn.
- How many people actually program in the Herman Rubin style? A few thousand?
- Certainly no where near the critical mass necessary for a language to take off.
- Without more users, good compilers would never be built, and even bad compilers
- would be extremely expensive, preventing even the few thousand who would
- benefit from the language from using it.
-
- From the sounds of your postings, Mr. Silverman is also in this camp. He has
- said _nothing_ as of yet that Mr. Rubin hasn't said a dozen times before. I
- sympathize with both of your problems. But if you want a language that solves
- all your problems, you're gonna have to write it yourself or pay someone else
- to do it. The rest of us have good market reasons for simply not caring.
-
- --
- Dave Griffith, Information Resources, University of Chicago,
- Department of Surgery dave@alex.bsd.uchicago.edu
-