🚀 go-pugleaf

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