Re: next "big" language?? (disagree)

[The Amorphous Mass <robinson@blue.weeg.uiowa.edu>]

On 4 Jun 1996, Peter Hermann wrote:

> The Amorphous Mass (robinson@blue.weeg.uiowa.edu) wrote:
> [snip]
> :   I think you're assuming that everyone is deveoping a huge, complex 
> : project with 100 teams of 100 programmers each working on mainframes with 
> : 350MHz Alphas and 256MB of RAM (OK, I'm exaggerating a little :-).  Those 
> 
> not at all.
> My home PC is a 486 which I recently upgraded from 8 to 24MB RAM.
> The reason was an application which steadily grew complex.
> (btw, a simple DOS application, but very useful ;-) ).
> The 8MB were fine for GNAT (the GNU Ada95 translator) as long as 
> I did not use excessive generic abstraction. However, with the 
> need of dynamically requested space during compilation of
> a demanding logical architecture, the 8MB did not satisfy
> the compilation process. The size is NOT in terms of lines of code.
> A few keystrokes for a coding-abstraction generates temp space
> for the compilation process.
> The result is an executable of a few KILObytes,
> where the compiler has done all optimization before.  ;-)

  Right.  And my concern is not final executable size, because I'm sure 
Ada is just as subject to optimization as many other languages 
(especially if it has some way to guarantee against aliasing).  It's 
development bloat.  On of the reasons I refuse to give up my "obsolete" 
machine is that I see the new ones are much less stable (this box only 
crashes if I run Microsoft Word for too long, but that's Microsoft...) 
and the compilers are bloated, slow and bug-ridden.

> Ada is not big, safe, feature-laden, but industrial-strength and
> shaped with that minimum of features to compete as a general purpose
> object-oriented language (with concurrency and real-time capability).

  Really?  Then where did I hear the complaint about every Ada programmer 
using a different language?  I will admit that as I have not been exposed 
to the language in depth, my statements are less accusations and more 
questions.  I'm quite happy to be corrected.  FWIW I'm very taken by 
Miranda, although I do wish they'd port it to something besides Unix.

> : language out there.  So obviously there are people who would agree 
> : wholeheartedly with your argument, but who would then disagree that Ada 
> : would be the best language to use for "professional" programming.  The 
> : nature of that disagreement is, of course, subjective.
> 
> James, you will certainly agree that a state-of-the-art PC
> sold today will have a minimum of 16MB/800MB/80MHz, don't you?

  State of the art is 24MB/2GB/166MHz for PCs, with slightly lower numbers 
for Macs.  Alphas are up to 350MHz(!).  Of greater concern is what a run of 
the mill PC/Mac/whatever is equipped with.  8MB RAM is not uncommon, 
although 16MB is becoming more prevalent.  Of course, OSes and 
applications which hog all that space are also becoming more prevalent...

> One of the great potentials of the future are reusable software elements.

  They're also one of the great dangers of the future.  I keep a fairly 
substantial library of useful little functions that I've written over the 
3 or so years I've been programming in C, and their reusability is greatly 
enhanced by the fact that I can tweak the code a little for particular 
applications.  By contrast, at work we're trying to get this souped-up OO 
development platform to talk to an edits package written in C (the 
development platform is written in C++) and we keep getting errors 
concerning classes that we didn't know existed, whose purpose is completely 
unknown to us and undocumented, apropos problems that no amount of 
debugging has revealed sofar, because the code and the interface is at 
such a high level that the programmer only has the most notional control 
over what's actually happening.  The classes will doubtless get used 
over and over again, but too much of our development time consists of 
waiting for support to call back.
  I'm thus wary of the idea of "code reuse." Not dismissive, just wary.

/**James Robinson***********************            
  "If a fatal error occurs, the program should not be allowed to continue."
 -- Oracle Pro*C User's Guide         *************james-robinson@uiowa.edu**/