comp.lang.ada
 help / color / mirror / Atom feed
From: jgv@swl.msd.ray.com (John Volan)
Subject: Re: SOLVED! Decoupled Mutual Recursion Challenger
Date: Tue, 25 Oct 1994 15:54:20 GMT
Date: 1994-10-25T15:54:20+00:00	[thread overview]
Message-ID: <1994Oct25.155420.27353@swlvx2.msd.ray.com> (raw)
In-Reply-To: 38hcv3$j85@baleen.cs.ucla.edu

jmartin@baleen.cs.ucla.edu (Jay Martin) writes:

>jgv@swl.msd.ray.com (John Volan) writes:

>>Don't underestimate the complexities involved here.  Your "package
>>forward" idea is essentially identical to the "package abstract"
>>concept I suggested a while back (although my proposal didn't require
>>any new Ada reserved-words :-).  When I presented the idea of "package
>>abstracts", I at least considered some of the issues they raise:

>>1. Is a package abstract an optional feature, or are you compelled to
>>   precede every package spec with a package abstract?  If optional,
>>   how do you distinguish a package spec that has a preceding abstract
>>   from one that does not?  Or are we creating a situation analogous to
>>   the Ada83 problem of an "optional body for a bodiless package spec"?

>>2. How do you distinguish a "with"-clause that only imports a package
>>   abstract from one that imports the whole package spec?

>>3. Can a package-with-abstract be generic?  If so, where does the generic
>>   clause go?  How do you instantiate such a beast?  What impact does this
>>   have on the whole generic contract scheme?

>>4. This is much too late for 9X, and has to be left for 0X, if it goes
>>   anywhere at all.  Even if all the difficulties can be ironed out, is
>>   this feature worth the added compiler complexity, when there are
>>   reusable workarounds that already effectively extend the language?

>1. Optional, No, No.
>2. No.

"NO"?  What's the point of having two outside views of a package (one
incomplete, the other fuller) if a potential client can't select how
much of a view they want?  (Do you even have a *clue* what I'm talking
about, Jay?)

>3. No.

Why not?  Why do we have to make a *special exception* in this case,
for a feature that ought to be *orthogonal* to this?  Is it just
because someone like you doesn't want to be bothered about thinking
things through?

>4. Who cares. If the standard can't be easily modified as was the
>   case for Ada83 then Ada9x is dead.  

"Easily modified"?  Do you think what the MRT has been doing these
past few years was *easy*?  Where have you *been*?  Do you have
*any* idea about what it takes to revise an *international standard*?

>  The Compiler complexity is trivial,
>  the language would be cleaner.

"Cleaner"?  With yet another language feature to complicate things?  I
don't think it would be the *language* that would be "cleaner".  The
*programs* written in that language would be (a tad) "cleaner", at the
expense of (possibly a lot) more complexity in the language.  Or
rather, a certain very particular *style* of programs would be
"cleaner", possibly at the expense of other styles of programming.

I'm not a language lawyer, and I've never written a compiler, so I
haven't presumed to make any claim as to how "trivial" this kind of
feature would be.  At most, I've tried to point out a few of the
conceptual difficulties I could see, but that's all speculation on my
part.  Maybe it *is* "trivial", and if so, I hope some experienced
language lawyers will pipe up and say so.  Even if it isn't trivial,
maybe it's worth it anyway -- and if so, I hope some language lawyers
will pipe up about that too.  But for now, I'm reserving my judgment.

Jay, are *you* a language lawyer?  Have *you* ever written an
industrial-strength compiler?  That's not a rhetorical dig.  If you've
got some real experience here, by all means say so. But somehow I
doubt it, since your organization seems to be a university computer
science department, and I suspect you are a student.

>Ada9x is too obese and is being too effected [sic] by trying to be an
>"elegant" (rigid) extension of obese Ada83.

One man's "elegant" is another man's "rigid."  Is C++ an "elegant"
extension of C, or is it "rigidly" preserving C's syntax, which many
(even in the C/C++ camp) have disavowed as obsolete and kludgy?  (For
goodness sake, even *Bjarne Stroustrup* seems to have chafed a bit
about C syntax -- but I won't presume to speak for him.)  Is C++ still
"lean and mean" today, or is the agglomeration of new features such as
templates, exceptions, first-class bool and string types, and
namespaces, (all of which were in Ada ten years ago) turning it into
an "obese" language?  Is Eiffel "elegant" because of its minimalist
design, or is it "rigid" because it offers only "One True Way" of
modularizing a program, and has to resort to auxiliary languages such
as LACE to deal with higher levels of organization?

>I really don't understand
>why can't some clown ...
                ^^^^^ 
Let's see, from now on we'll have all our programming languages
designed by Bozo and Ronald MacDonald, and maybe a few Congressmen,
too...

>... spend a few minutes ...
           ^^^^^^^^^^^^^ 
Is that how long K&R spent designing C? Might explain a lot ...  

> ... to come up with a cleaner
>smaller (more minimalist) Ada style language.  

... as long as your own "trivial" pet language construct gets into it?
Honestly, do you really think that language designs can just be
slapped together, or that you can just slap in yet another feature
without causing a ripple effect in the whole design of a language?  It
seems to me that *that* way leads to *larger*, *more complex*, *less
cohesive* languages, NOT "smaller, more minimalist" languages.

Of course, if you so vehemently believe that this *is* such a 
trivial feature to slap on top of Ada9X, then I suggest that you
get yourself a copy of GNAT, revise it to implement your new
language feature, experiment with it, and then write a learned
treatise on just how trivial and orthogonal it is (or isn't,
as you might just discover).  Put up or shut up.

>My theory of why CS is
    ^^^^^^
>not coming up with one is: (1) Most Computer Scientists are
>masturbating on useless theoretic, pseudo "huge breakthroughs" and
                         ^^^^^^^^^
>"scientific" things.  

Oh, I see.  It's okay for *you* to have your pet theories, but nobody
else's ideas are worth pursuing.  Whatever's "trivial" according to
*your* theories are nuggets of wisdom to be enshrined, but if anybody
*else* has an opposing view of what's important for software
engineering, that's "pseudoscience."

Maybe your jaundiced view about "Computer Science" has less to do with
the state of the software engineering *industry* and more to do with
the state of *academic* computer science -- or maybe it just says more
about the particular academic *institution* you're currently part of.
If the latter is the case, then I feel sorry for you, and suggest you
transfer immediately to another school.

>Language design requires them to sink into the
>abyss of unholy "social science" and the law of the lowest common
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>denominator.  
 ^^^^^^^^^^^^

I understand it all now.  Forget striving for excellence, folks! Don't
bother!  Let's just keep things at the level where any fool can slap
software together!  Sure, only a fool would buy or use such software,
but that's okay, because *everybody* would be equally foolish.  O
Brave New World ...

>(2) Even if one did, political jealousy and power games
>within the Computer Science community would not allow them to
>recognize, except [sic], support and then champion a really good and
>software engineering efficient language.

"Let him who is without sin ..."  In my experience, those who
whine most about "political jealousy" and "power games" are usually
those who *tried* to play political power games in the past and
*failed*.  

Another phenomenon I've seen is this: Somebody relatively naive about
a subject thinks that they've found some grand and glorious solution
to all problems, and presents it to the experts.  The experts might
agree about some of the good points in the neophyte's ideas, but,
being more experienced than the neophyte, they also notice some of the
flaws, and calmly point them out.  Instead of addressing the flaws and
possibly taking the idea further (and maybe *learning* something in
the process), the neophyte gets angry, starts accusing the experts of
political scheming and playing power games, and storms off in a huff.
The experts look at each other and shrug, and secretly pray that the
neophyte doesn't somehow grow up to be their manager some day...

>(Can't do anything other than rant now (got to fix bugs)) Jay.
                               ^^^^      ^^^^^^^^^^^^^^^ 
Maybe if you (and a few other people) spent less time "ranting" about
"rigid, obese" languages, and spent more time trying to "recognize,
accept, support, and then champion a really good and software
engineering efficient language", then you might now be spending less
of your time fixing bugs, and more of your time doing some real
software engineering in that language.  (Guess which language I mean?)

-- John Volan

P.S.  After an outburst like that, folks, I wouldn't blame any of you
if you stuck this whole thread in your kill file.  I'm even tempted to
do so now, and I started this thread!

--------------------------------------------------------------------------------
--  Me : Person := (Name                => "John Volan",
--                  Company             => "Raytheon Missile Systems Division",
--                  E_Mail_Address      => "jgv@swl.msd.ray.com",
--                  Affiliation         => "Enthusiastic member of Team Ada!",
--                  Humorous_Disclaimer => "These opinions are undefined " &
--                                         "by my employer and therefore " &
--                                         "any use of them would be "     &
--                                         "totally erroneous.");
--------------------------------------------------------------------------------







  parent reply	other threads:[~1994-10-25 15:54 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1994-10-12 22:49 SOLVED! Decoupled Mutual Recursion Challenger John Volan
1994-10-17 15:48 ` John Volan
1994-10-17 17:55   ` Bob Duff
1994-10-17 20:52     ` John Volan
1994-10-17 22:10       ` Bob Duff
1994-10-18 22:17         ` John Volan
1994-10-19  1:01           ` Bob Duff
1994-10-19  4:45             ` Jay Martin
1994-10-19 14:38               ` Mark A Biggar
     [not found]                 ` <38fi4r$l81@oahu.cs.ucla.edu>
1994-10-24 11:49                   ` Mutual Recursion Challenge Robert I. Eachus
1994-10-24 20:32                     ` John Volan
1994-10-26 11:42                       ` Generic association example (was Re: Mutual Recursion Challenge) Robert I. Eachus
1994-10-26 23:21                         ` John Volan
1994-10-27 10:53                           ` Robert I. Eachus
1994-10-31 17:34                             ` John Volan
1994-10-27 14:37                           ` Mark A Biggar
1994-10-24 17:42                   ` SOLVED! Decoupled Mutual Recursion Challenger John Volan
1994-10-24 22:37                     ` Jay Martin
1994-10-25  5:47                       ` Matt Kennel
1994-10-25 10:04                         ` David Emery
1994-10-25 16:43                         ` John Volan
1994-10-27  4:25                           ` Rob Heyes
1994-10-28  9:03                             ` Mutual Recursion (was Re: SOLVED! Decoupled Mutual Recursion Challenger) Robert I. Eachus
1994-10-28 15:04                             ` SOLVED! Decoupled Mutual Recursion Challenger Robb Nebbe
1994-10-25 15:54                       ` John Volan [this message]
1994-10-26  1:24                         ` Bob Duff
1994-10-28  4:28                         ` Jay Martin
1994-10-28 10:52                           ` Robert I. Eachus
1994-10-28 18:46                             ` Jay Martin
1994-11-02 14:56                               ` Robert I. Eachus
1994-10-29  0:38                           ` Bob Duff
1994-10-29  7:26                             ` Jay Martin
1994-10-29 11:59                             ` Richard Kenner
1994-10-31 13:17                               ` Robert Dewar
1994-10-31 14:13                               ` gcc distribution (was: SOLVED! Decoupled Mutual Recursion Challenger) Norman H. Cohen
1994-11-02 14:14                                 ` Richard Kenner
1994-11-04 23:56                                   ` Michael Feldman
1994-10-31 18:44                           ` SOLVED! Decoupled Mutual Recursion Challenger John Volan
1994-10-20 11:25               ` Robb Nebbe
1994-10-20 19:19                 ` John Volan
1994-10-26  0:07                 ` Mark S. Hathaway
1994-10-26 18:48                 ` gamache
1994-10-27  2:15                   ` John Volan
     [not found]           ` <CxwGJF.FwB@ois.com>
1994-10-19 16:35             ` John Volan
1994-10-17 22:54   ` Cyrille Comar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox