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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Any research putting c above ada? Date: 1997/05/07 Message-ID: #1/1 X-Deja-AN: 240178301 Distribution: world References: <5ih6i9$oct$1@waldorf.csc.calpoly.edu> <5ijb0o$ajc@ns1.sw-eng.falls-church.va.us> <334d3da5.14386594@aplcen.apl.jhu.edu> <2senchydgk.fsf@hpodid2.eurocontrol.fr> <5im3an$3dv@bcrkh13.bnr.ca> <33526cbf.41c6@cca.rockwell.com> <5iusvd$118e@newssvr01-int.news.prodigy.com> <33530e22.5940@worldnet.att.net> <5j18h3$1564@newssvr01-int.news.prodigy.com> <5j8ukr$lu9@nntpa.cb.lucent.com> <5jddr6$mqm@newssvr01-int.news.prodigy.com> <335d880c.324@dynamite.com.au> <5ki7ln$2ttg@newssvr01-int.news.prodigy.com> <336ea9ca.3c92@dynamite.com.au> <5kopik$1jos@newssvr01-int.news.prodigy.com> Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada Date: 1997-05-07T00:00:00+00:00 List-Id: In article <5kopik$1jos@newssvr01-int.news.prodigy.com> NKSW39B@prodigy.com (Matthew Givens) writes: > (Ada...) all, a rigid programming environment that Not particularly - certainly not really in comparison to C or C++. Definitely true in comparison to Lisp, ST, and such. > Ada also has it's weaknesses. We're using it to develop GUI based Oracle > applications on a Sun system. The compiled code for the executables is > tryuly enormous, in comparison with the executable generated for similar I have a bad feeling you are doing this using some Ada83 impl... > Anyway, size of executables is one problem (I wrote one that had an > executable size of almost 600K, and that was just a report > generator, not a GUI app). If you instantiate a lot of generics all over the place (especially if you don't organize things sensibly) and you implementation does not have generic code sharing, then sure, you can wind up with code bloat. Generally, I've found this has more to do with poor understanding of how this stuff should be used. Typical example is instantiating Integer_IO or whatever all over the place when one is just fine. > Others include indequate programming tools for the language and > tasking problems (Ada tasking won't work with the graphic front-end, > no work-around possible, they tell me). Well, X just plain has problems here (assuming you are using X). But even X works fine (as much as can be expected) with tasking built on the OS threads. For example, default GNAT on Solaris with X/Motif makes multiple user sessions trivial with tasking. I've done it. If the GUI has at least _some_ thread sense, then this will not be a problem if you have any idea of how concurrent systems work. > Not Ada per se, I understand, but the tools used with the language > are important. All sounds way out of date and irrelevant. > Another thing about Ada that I deplore is generics. A nice concept, but > when the same procedure has eight different bodies, it's a bit confusing > to debug (which body had the bug in it???). Easy. It is the name of the instantiation unit. Trivial even in GDB. Works fine. Generics are actually very important for anything even attempting to provide multiple setting abstractions. They're in C++, Eiffel, Modula-3, Clu, etc. They are really passe' in this respect: "everyone knows these things are vital in a statically typed language". > Or optional parameters. Ugh, I hate the concept. To me, no > parameter to a procedure should ever be optional. At any time. > But I guess that's just the neanerthal C programmer peeking out. Misunderstanding. There are no "optional" parameters. There can be *default* parameters, but not optional ones. I suppose you can say, "whatever", but this really is a big difference. > That's what I'm talking about. Not everyone can be equally good in > both C and Ada. Like me. I program in both, but am infinitely more > comfortable in C. The code I turn out is better, and I can do it > quicker. Forcing me to use Ada will produce results, but won't be > as productive. This argument is the only one you give that is semi-plausible. There really are good reasons why you would choose one language instead of another, and Ada is certainly and obviously not "perfect for all scenarios". But the issues you raise are really irrelevant to this question. Things like, "I need a dynamic language here [Lisp or something]", or "I need to have true vectorization of all this computation [Fortran]" are the sorts of questions that really count in this context. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com