home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / misc / 3645 < prev    next >
Encoding:
Internet Message Format  |  1992-11-14  |  5.7 KB

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