From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f891f,9d58048b8113c00f X-Google-Attributes: gidf891f,public X-Google-Thread: 10261c,2e71cf22768a124d X-Google-Attributes: gid10261c,public X-Google-Thread: 1014db,9d58048b8113c00f X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,2e71cf22768a124d X-Google-Attributes: gid103376,public From: The Amorphous Mass Subject: Re: next "big" language?? (disagree) Date: 1996/06/04 Message-ID: X-Deja-AN: 158531049 distribution: world references: <4p0fdd$4ml@news.atlantic.net> <4p1l65$35qi@info4.rus.uni-stuttgart.de> <4p23oe$3f1e@info4.rus.uni-stuttgart.de> x-sender: robinson@black.weeg.uiowa.edu content-type: TEXT/PLAIN; charset=US-ASCII organization: University of Iowa, Iowa City, IA, USA mime-version: 1.0 newsgroups: comp.lang.pascal.misc,comp.lang.c,comp.lang.misc,comp.lang.ada Date: 1996-06-04T00:00:00+00:00 List-Id: 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**/