mat@hou5d.UUCP (10/12/83)
>From a net author:
ADA is the best, safest way of expressing algorithms and data
structures that I have seen yet. It is the result of painstaking
effort by better informed language designers than almost any of the
contributors to this newsgroup (I include myself in that description).
It beats the pants off C for most work -- a shame that its concurrency
(its most talked about point) is unlikely to be up to scratch for
serious real time use. GO AWAY AND LEARN IT. Your C might even be
better afterwards.
Alright. I HAVE learned Ada (TM of DoD, as you failed to mention). I learned
it (early Stoneman) from Jerry Fischer @ NYU/Courant, and while I haven't made
large-scale use of it, I feel that I am qualified to at least TALK about some
of it.
"ADA is the best, safest way ... yet."
Well, Ada MAY have the advantage that only experienced programmers will be
able to get off the ground with it; this MIGHT prevent nincompoops from being
allowed to write critical code. I wouldn't bet on it, though.
The bigger the language, the easier it is to hide creeping quicksand in it.
What is creeping quicksand? Well, consider PL/I's system of types. If you
don't declare everything, and just right, the interplay between types is gonna
getcha. Part of the problem comes from default assignemt of types to
undeclared things. A larger part seems to come from the number of independent
attributes that a fundemental data object must have. part comes from the need
to insert magic and mysterious conversions in funny places like proceedure
calls. I won't bother the net with examples ... the problem is well known.
PL/I's quicksand is ready-made. In Ada, however, the rather large number
of degrees of freedom for numerical types makes it easy to devise quicksand
of your own.
What about overloading? Overloading is a NECESSARY part of Ada; you cannot
avoid it since all your default operators overload. If used with care,
caution, and good judgement born of experience, the rather well-controlled
overloading can help you keep your code sensible and orthogonal in data types
vs. algorithms. But without a LARGE dose of the above, code can degenerate
into a welter of irregular and incomprehensible references to God-only-knows-
which of a group of not-quite-the-functional-same subprograms.
The previous comments apply to generic packages with even more force. GPs
provide a fantastic opportunity to foul up -- probably at least on order
more in the size of the programming effort. They can also be used well.
How many ``real world'' programmers and how many ``maintanance programmers''
will have the needed programming strengths? I can only pray ... .
What about knowing when to use fully qualified names (Package.Package.Proc() )
and when to get at things with WITH clause ; USE clause ? Not too tough a
choice if you REALLY know what's going on ... hmm, maybe a tough choice indeed.
Please don't get me wrong ... Ada does a LOT of things right, especially around
enumerated types and the special uses of the "'" operator (like getting a
printable name for your enumeration objects and discriminating between
enumerated types whose objects have the same names). There are a LOT of
things that were done, in my opinion, ten years too soon. One of the strengths
of C is the fact that the language really contained nothing new. Can you say
the same for Ada? And some of the strengths could/should be taken right into
C. Today. But that doesn't mean that everything in Ada was done right.
And what about the problem with the programmer who has a harder and harder time
judging the execution costs on his machine? The ability to hide a great
deal of work or a complex data structure behind an overloaded operator is
nice, but if you are programming something that is a factor of four away
from becoming time critical, you are going to have to be concerned about
execution costs.
Ada also has a VERY large number of keywords, used in a rather irregular
way. One has to say ``let's see, is it the IN keyword or the OF keyword
that goes in this statement ...''. Experience will help here, it is true,
but the list is about 3 times bigger than it has to be and about three
times bigger than seems comfortable.
Finally, I don't share your pessimism about Ada's tasking. It looks like
a rather good way to do things IN SELF CONTAINED SYSTEMS. Within the UN*X
kernel, however, it would just get in the way. You pays yer money and yer
takes yer chers.
Ada was both designed and tested in an industrial/academic laboratory
environment. DoD should have waited until AFTER the compilers had been
validated and in use in industry for two years before calling the final
freeze on the language. The issues raised above, and many others, could have
been much better settled that way. As it stands, the tricky and subtle
issues that came up in Ironman and thereafter were settled by voting
across a large pool of academics. I don't trust decisions like that.
Mark Terribile
Duke of deNetleichter@yale-com.UUCP (Jerry Leichter) (10/12/83)
Since we seem to be descending to "proof by reference to authority" ("some
people with more experience in language design than anyone in this group
designed ADA, etc."), consider the following quote:
...ADA. This project has been initiated and sponsored by one of the
worlds most powerful organizations.... Thus it is ensured on an
influence and attention quite independent of it technical merits and
its faults and deficiencies threaten us with far greater dangers.
For none of the evidence we have so far can inspire confidence that
this language has avoided any of the problems that have afflicted
other complex language projects in the past.
...The original objectives of the language included reliability,
readability of programs, formality of language definition, and even
simplicity. Gradually these objectives have been sacrificed in favor
of power, supposedly achieved by a plethora of features and notational
conventions, many of them unnecessary and some of them, like exception
handling, even dangerous. We relive the history of the design of the
motor car. Gadgets and glitter prevail over fundamental concerns of
safety and economy.
...And so, the best of my advice to the originators and designers of
ADA has been ignored. In this last resort, I appeal to you, representa-
tives of the programming profession in the United States, and citizens
concerned with the welfare and safety of your own country and of man-
kind: Do not allow this language in its present state to be used in
applications where reliability is critical, i.e., nuclear power sta-
tions, cruise missiles, early warning systems, anti-ballistic missile
defense systems.... An unreliable programming language generating unre-
liable programs constitutes a far greater risk to our environment and
to our society than unsafe cars, toxic pesticides, or accidents at
nuclear power stations. Be vigilant to reduce that risk, not to
increase it.
>From "The Emperor's Old Clothes", C.A.R. Hoare's 1980 Turing Award Lecture
(CACM V24 #2 (Feb. 1981) page 75.
-- Jerry
decvax!yale-comix!leichter leichter@yaletim@unc.UUCP (Tim Maroney) (10/12/83)
Mike Banahan has pointed out that Ada solves many of the problems of C, and heaps derision and ridicule on those of us who continue to use the sadly outmoded language C. Spoken like a true theoretician, Mike! I agree entirely that Ada is in many ways superior to C for algorithm description and similar tasks, which you cited. However, if you are one of us poor schmoes who is trying to write programs that will actually do something and help people in a concrete fashion, there is one way that C outshines Ada completely, and that is that production-quality verified complete compilers for C exist, and C support tools have been in development for many years. On the popular operating system that is making it possible for you to read this news group, C is the friendliest language. On the other hand, I wish I weren't forced to use C in so many applications, such as yacc and lex. (Yes, I know, such programs often allow you to use fortran or ratfor instead, but that's like a choice between defenestration and castration.) Tim Maroney
guy@rlgvax.UUCP (Guy Harris) (10/12/83)
Ok, does anybody have ADA implementations for all of the following:
PDP-11
VAX-11
Intel 80[12]*8[0568]
Zilog Z8[0]+
Motorola MC680[0-9]+
National Semiconductor (16|32)0(08|16|32)
Data General Eclipse
IBM 360 and successors
etc., etc., etc., in which one can write most, if not all, algorithms in a form
which generates as efficient code as the C implementations for the above
machines? (No cheating and dragging in "ADA engines", not that the iAPX 432
is blazingly fast...) Until there are such implementations, for writing
software for all the above machines - or even just writing software for any
two of the machines above which run UNIX - ADA isn't better than C for getting
real work done.
Besides, there is much debate about whether ADA really does make it harder to
write bad programs; C.A.R. Hoare probably wouldn't like C's laxity but he
doesn't think ADA is a good idea either.
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guyscs@foxvax1.UUCP (S.C. Schwarm ) (10/14/83)
>Ok, does anybody have ADA implementations for all of the following: > >PDP-11 >VAX-11 >Intel 80[12]*8[0568] >Zilog Z8[0]+ >Motorola MC680[0-9]+ >National Semiconductor (16|32)0(08|16|32) >Data General Eclipse >IBM 360 and successors Just remember that C didn't have compilers for all of these when it was only 3 years old. Give it time. We also have to keep the goals of the languages clear. C was intended to be a replacement for assembly language and Ada* is for very long liked Real time applications. C has changed a lot and so has Ada. Both languages have their place and will continue to be use for quite a while. Steve Schwarm genrad!wjh12!foxvax1!scs *TM US DoD
mason@utcsrgv.UUCP (Dave Mason) (10/15/83)
(It was bound to happen, so I may as well add the third language.)
Concurrent Euclid has most of the advantages of ADA, but instead of
maybe having a reasonable implementation someday, there are ConEuc
compilers for: PDP-11, VAX, 68000, 16000, i432, 6809 at least. These
produce good code quite fast. It has very good concurrency (monitors).
It has been used to write a Unix look-alike called TUNIS.
On the other hand, the true C-hacker will never like it (or ADA):
because it is strongly typed, and you can't even use aliasing to make
your code unreadable, and (worse and worse) you can even write provably
correct code (it's still hard of course, but it is possible).
I know what this is going to lead to, so hold on while I dig my asbestos
suit out of the closet....OK...ready...
-- Dave Mason, U. Toronto CSRG,
{cornell,watmath,ihnp4,floyd,allegra,utzoo,uw-beaver}!utcsrgv!mason
or {decvax,linus,research}!utzoo!utcsrgv!mason (UUCP)mike@taurus.UUCP (10/16/83)
Ah, dear me. Here starteth another holy war, but I always was one to enjoy
a fight.
ADA is simply a BIG improvement on C. I've smiled a lot recently at some of
the things that have turned up in this column -- watched the debate about
parameter matching for function calls -- what sort cast should be applied
to functions returning nothing -- comparison of structures -- the ill-designed
'switch' selectors, 'break' and 'continue's -- introduction of complex numbers,
etc. etc. .
The one point that comes up time and again is that the people submitting to
the debate are arguing about problems that have already been solved. If you
want to see the way that all the stuff mentioned above can be done cleanly,
efficiently and portably, then go read the ADA Reference Manual, or at least
a primer on the language. Until you have done that, you are simply contributing
noise, not real debatable opinion.
You want my opinion? Well you get it anyway.
C is outdated. It is a poor language for quick, reliable implementation of
portable applications programs. It works well enough for small bit-twiddling
coding, but leaves too many minefields for even the experienced programmers
to walk into.
ADA is the best, safest way of expressing algorithms and data structures that
I have seen yet. It is the result of painstaking effort by better informed
language designers than almost any of the contributors to this newsgroup (I
include myself in that description).
It beats the pants off C for most work -- a shame that its concurrency
(its most talked about point) is unlikely to be up to scratch for serious
real time use. GO AWAY AND LEARN IT. Your C might even be better afterwards.
Please reply by sending personal abuse to the 'junk' newsgroup. Intelligent,
well informed argument is welcome.
--
Mike Banahan
{ENGLAND}!ukc!root44!taurus!mikecrandell@ut-sally.UUCP (Jim Crandell) (10/19/83)
> It has very good concurrency (monitors).
I can't wait to see bad concurrency.
--
Jim ({ihnp4,kpno,ut-ngp}!ut-sally!crandell or crandell@ut-sally.UUCP)andree@uokvax.UUCP (10/23/83)
#R:taurus:-8000:uokvax:3000001:000:873 uokvax!andree Oct 14 13:01:00 1983 As Mike said, it is true that ADA(tm) solves many of the problems of C. But the same thing works in reverse - ADA has problems that were solved in C (and FORTRAN, for that matter), like the nested environment/scope definition kludgery. One of the members of the ADA design team (whose name escapes me) was quoted as saying `with packages, nesting is for the birds.' I agree completely. Unfortunately, Pascal seems to have imbued the world with the idea that nesting is, and will remain, good (this could be due to new languages being based on Pascal, rather than some unnested language). Thus, modern languages (Modula *, * Euclid, Ada, etc.) tend to have nesting. The only exception I am aware of is CLU. If you haven't seen the CLU manual, you may want to take a look. They present some interesting (and effective) solutions to many standard PL design problems. <mike
andree@uokvax.UUCP (10/24/83)
#R:utcsrgv:-248800:uokvax:3000003:000:492 uokvax!andree Oct 20 18:31:00 1983 I've got copies of Holt's papers on Euclid (not here - I think it's a users manual & something similar), but not the new book (eventually...). I agree with Dave Mason - Euclid looks considerably nicer than C. The solution to the standard problems with pointers and sets are quite nice, and the features that make it possible to write provable code aren't to shabby, either. So: Can I get Tunis for my VAX? Supported? Or do I stick with running someones supported version of 4.2 bsd? <mike
andree@uokvax.UUCP (10/24/83)
#R:taurus:-8000:uokvax:3000002:000:102 uokvax!andree Oct 16 20:13:00 1983 Yes, but for TRUE portability and TRULY efficient code, you should (chollileh) write FORTAN. <mike
grunwald@uiuccsb.UUCP (11/01/83)
#R:taurus:-8000:uiuccsb:9000007:000:984 uiuccsb!grunwald Oct 30 14:57:00 1983 bjb: Most of the nice features of Ada having little to do with code generation at all -- most of them are features which allow you to obtain more information about a type than in C. Additionally, the concept of allowing you to specify a ``generic type'' is very powerful and actually allows you to save code. For instance, in Pascal, if one has two types A and B, and wants to make stacks of 100 elements each using these types, you need to write separate routines for "pushA", "pushB", etc. In Ada, it should be possible to write a compiler which does not expressly need to provide separate routines for each type. The code within a generic type may be able to be made to share routines which do not reference any specific feature of the type (e.g. size, etc). The data type definitions of Ada are, while not exactly clean, very well done and they would allow you to avoid most of the explicit kludges that one does in Pascal and most of the implicit kludges that go on in C.
emjej@uokvax.UUCP (11/09/83)
#R:taurus:-8000:uokvax:3000005:000:689 uokvax!emjej Oct 30 13:14:00 1983 Hmmm. It's not clear to me that C has any concepts at all behind it. It was quite simply a language to write Unix in other than assembler. It has designed into it the facilities to do all the "clever tricks" (something I'd like to see the phrase "sleazy programming" come into use for) one does in assembler. It has built into it things that correspond to PDP-11 addressing modes. It pushes as much as possible out of the compiler and onto the programmer (especially if one looks at early versions of the language), and rubs the programmer's nose in the machine architecture. This is C's strength (for implementers and OS hackers) and its weakness (for everyone else). James Jones