🚀 go-pugleaf

In article <70903@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>In article <1991Feb21.185106.20605@gpu.utcs.utoronto.ca> craig@gpu.utcs.utoronto.ca (Craig Hubley) writes:
>
>|Not equivalent, just consistent where other languages with longer 
>|experience have proven the way to go.  
>
>If old languages *had* proven the right way to go, people wouldn't still
>be deriving new languages today.  

I disagree.  No one language had all the answers, nor is it possible for
one language to make the "right" engineering tradeoffs for all people and
all applications.  We went through this in the 60s with PL/1, and in the
70s with Ada...

We gotta learn from our mistakes, too... and I don't believe that type
tags were originally in any of those other languages, they were added as
it was realized there were situations that required them.

People will be deriving new languages so long as there are new needs and
new technologies to meet them.  C++ is a response to a need for an efficient
data abstraction language.  Making it a good reusable code language ought
to fit somewhere between "efficiency" and "data abstraction" on the priority
scale.

>C++ already is saddled with restrictions
>imposed by attempting to be compatible with one old language. 
>
>Let's not add more!

If you mean "don't mimic the functionality of other languages", I agree,
there are enough problems supporting C already.  However, if a mechanism
from Smalltalk or whatever seems to work and solve a problem in C++, why
not mimic it ?  The alternative is to invent it over and over in practice,
training everyone how to do it, or worse, to invent it in a standards 
committee...

-- 
  Craig Hubley   "...get rid of a man as soon as he thinks himself an expert."
  Craig Hubley & Associates------------------------------------Henry Ford Sr.
  craig@gpu.utcs.Utoronto.CA   UUNET!utai!utgpu!craig   craig@utorgpu.BITNET
  craig@gpu.utcs.toronto.EDU   {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig