Learning Ada (newbie)

Learning Ada (newbie)

[Ayende Rahien]

1. Where can I learn Ada? Preferably a turial on the web. I'm currently
reading (http://www.adahome.com/Ammo/Cplpl2Ada.html) which presents some
very interesting concepts (the fine-grained variables, frex), but it doesn't
really teach much. I used to know Pascal (been several years since I program
in it), and I know C/C++ pretty well. So I don't really need an interduction
to programming, just to Ada itself.
2. Can you recommend a good IDE for Ada? Preferably for Windows.
3. I read in Jargon File that "hackers find Ada's exception handling &
inter-process communication particularly hilarious." among other stuff. Why
is that? What are the advantages & disadvantages of Ada compare to C or C++
and other languages?

Thanks in advance,
    Ayende Rahien

Re: Learning Ada (newbie)

[Marin David Condic]

1) Go to http://www.adapower.org/ for resources on Ada. It is much more up
to date than Adahome. Look at the "Learn Ada" page & I am sure you will find
something there that is useful. Also look at the "Books", etc. & you'll find
lots of good stuff.

2) There is AdaGIDE which used to be distributed with GNAT. (Maybe it still
is? I've not upgraded anything in quite a while.) Try:
http://www.usafa.af.mil/dfcs/bios/mcc_html/adagide.html There are also a
variety of tools that work with GNAT - some of which are available at the
FTP site for GNAT. (Look at the "Links" page at AdaPower)

3) a) People who write Hacker Jargon files are often boneheads with
prejudices they want to validate by having all their friends say "Yes!
You're Right" rather than justify their beliefs with reasoning and evidence.
b) "Hacker" IMHO is a derogatory term that refers to someone who
"organically grows" software on the fly rather than designing software using
acceptable engineering techniques. Id est, consider the source. c) Exception
handling works quite well when used as intended. d) I have no idea what they
mean by inter-process communication. That would imply communication with
other processes via something like TCP/IP which is not part of the language.
If they meant intra-process communication - id est,
tasking/rendesvous/etc. - then probably they are coming at it from their own
prejudices & preferences for something like forking & shared memory. I've
used lots of tasking & its assorted features. So have many people on this
group. We can all attest to the fact that it works quite well - you just
have to know what you're doing (as with any feature of any language.) Start
with tasking carefully by writing small experimental programs & understand
how they operate & I think you will find them powerful.

BTW: You will find lots of tutorial level programs (including stuff on
tasking) on my web page. See my trailer for the link.

Good luck!

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ayende Rahien" <Dont@spam.me> wrote in message
news:9af9ao$6ee$1@taliesin.netcom.net.uk...
> 1. Where can I learn Ada? Preferably a turial on the web. I'm currently
> reading (http://www.adahome.com/Ammo/Cplpl2Ada.html) which presents some
> very interesting concepts (the fine-grained variables, frex), but it
doesn't
> really teach much. I used to know Pascal (been several years since I
program
> in it), and I know C/C++ pretty well. So I don't really need an
interduction
> to programming, just to Ada itself.
> 2. Can you recommend a good IDE for Ada? Preferably for Windows.
> 3. I read in Jargon File that "hackers find Ada's exception handling &
> inter-process communication particularly hilarious." among other stuff.
Why
> is that? What are the advantages & disadvantages of Ada compare to C or
C++
> and other languages?
>
> Thanks in advance,
>     Ayende Rahien
>
>
>
>

Re: Learning Ada (newbie)

[chris.danx]

"Ayende Rahien" <Dont@spam.me> wrote in message
news:9af9ao$6ee$1@taliesin.netcom.net.uk...
> 1. Where can I learn Ada? Preferably a turial on the web. I'm currently
> reading (http://www.adahome.com/Ammo/Cplpl2Ada.html) which presents some
> very interesting concepts (the fine-grained variables, frex), but it
doesn't
> really teach much. I used to know Pascal (been several years since I
program
> in it), and I know C/C++ pretty well. So I don't really need an
interduction
> to programming, just to Ada itself.

You should try the lovelace tutorial, it's great.  Do you know
www.Adapower.com?  if not bookmark it, it's good for all sorts of Ada
related stuff.  There's a link to the tutorial in there.  Also try
http://www.diax.ch/users/gdm/pascada.htm by Gautier de Montmollin.  It's
good too.

I might also do an introduction to Ada for programmers soon.  The OS
developer i work with is considering a switch from C to Ada and he knows
Pascal well, so i might do it to help him out.  Maybe try
http://willow.os-4u.com in the (near?) future.  This is my new programming
site so be patient.

> 2. Can you recommend a good IDE for Ada? Preferably for Windows.

AdaGIDE is the best IMO, again you'll find links to it at AdaPower.

> 3. I read in Jargon File that "hackers find Ada's exception handling &
> inter-process communication particularly hilarious." among other stuff.
> Why is that?

Dunno, i think exception handling in Ada is simple and powerful.  None of
that
    try {}
    catch {}

nonsense.  Ada's handling is simple, effective, uniform and less verbose
than C++ and Java.

> What are the advantages & disadvantages of Ada compare to C or C++
> and other languages?

Ada is a standard and a validated compiler has undergone testing with
massive test suite.  C compilers can't even agree on the size each of the
member of integer type family.  Ada's advantages over C are numerous, too
numerous to go into.  You might be interested to know that when I came to
Ada initially (just over a year ago), I didn't hold it in such high regard.
Now I use it lots and really like it.


Hope this helps,
Chris Campbell

Re: Learning Ada (newbie)

[Ted Dennison]

In article <9af9ao$6ee$1@taliesin.netcom.net.uk>, Ayende Rahien says...
>
>1. Where can I learn Ada? Preferably a turial on the web. I'm currently
>reading (http://www.adahome.com/Ammo/Cplpl2Ada.html) which presents some
>very interesting concepts (the fine-grained variables, frex), but it doesn't
>really teach much. I used to know Pascal (been several years since I program
>in it), and I know C/C++ pretty well. So I don't really need an interduction
>to programming, just to Ada itself.

AdaHome has some good stuff, but its a cobweb. You should go to AdaPower (
http://www.adapower.com ) and look around. There's a "Learn Ada" button on the
main page that will show you all sorts of good links.

As a former Pascal user, you shouldn't have too much trouble picking up Ada.
Tasking and Generics are going to be about the only totally new concepts (and
C++ has something close to Generics).

>2. Can you recommend a good IDE for Ada? Preferably for Windows.
Gnat with Emacs is generally the favorite of serious hobbiests. Emacs isn't much
of a GUI, but is very well integrated with the compiler and its tools and more
powerful than your typical GUI. If you are used to GUI's like Visual C++ uses,
you'd probably be a bit more comfortable with ObjectAda. However, ObjectAda is
not Free Software (just as Visual C++ isn't). But you can download a (hobbled)
copy of it from the aonix website. My website (see my sig) should have links you
can follow to download Gnat and Emacs for NT. There's links for a lot of other
goodies there too.

>3. I read in Jargon File that "hackers find Ada's exception handling &
>inter-process communication particularly hilarious." among other stuff. Why
>is that? What are the advantages & disadvantages of Ada compare to C or C++
>and other languages?

The author of the Jargon file (Eric Raymond), while brilliant, has a lot of
rather odd ideas about things (programming, Free Software, politics, marriage,
guns, etc). He isn't much of a fan of C++ either. In fact, one could argue that
he doesn't like any language whose sources can't be made to look like line
noise. :-)

For this reason, I'd advocate not using the Jargon file as a first reference.
Instead, use FOLDOC, ( http://www.foldoc.org ) which has a nice GUI interface,
and is maintained in a much more democratic manner. Some entries are taken from
the Jargon file where they are appropriate. (While you are there, don't miss the
entry for Shub-Internet -
http://www.foldoc.org/foldoc/foldoc.cgi?query=shub-internet ). Their entry for
Ada is much more even-handed.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Learning Ada (newbie)

[David Starner]

On Wed, 4 Apr 2001 15:25:27 +0200, Ayende Rahien <Dont@spam.me> wrote:
>2. Can you recommend a good IDE for Ada? Preferably for Windows.

Emacs for Windows is an IDE for Ada; it's a bit generalized and
bears little resemblance to the Visual C++ IDE, but it's the tool 
of choice of quite a few programmers.

>3. I read in Jargon File that "hackers find Ada's exception handling &
>inter-process communication particularly hilarious." among other stuff. Why
>is that? 

No one's quite sure. Ada's exception handling bears close resemblance 
to the exception handling of many other languages. Ada 83 may be bigger 
than most other languages of the early 80's, but Ada 83/95 is significantly 
smaller than many languages of the 90's - especially C++.

>What are the advantages & disadvantages of Ada compare to C or C++
>and other languages?

Ada is a whole lot more anal about stuff than C or C++, tending to
move errors from run-time to compile-time. Ada often allows you to
work at a higher level than C. (For example, if you want to work
with a substring, you create one (string (1 .. 3)) and pass it
around. There's no need to go messing with string functions and
finding a static buffer or allocating memory.) Ada can be compiled
to a JVM and interoperate with Java. There's very few Ada compilers 
out there that don't implement the whole language, unlike C++.

Most of the disadvantages are not inherant in the language. Ada
doesn't have the support of C, C++ and Visual Basic. Most libraries
for those languages will work, but it will take some work finding a
recent binding or writing your own. 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Learning Ada (newbie)

[martin.m.dowie]

Well, not all "cutting edge"/linux/hacker-types go for this - www.slashdot.org
had a reasonably Ada-favourable thread a while back.

Maybe GNAT with its GNU links and Open Source background are helping
break the ice a little...

Ayende Rahien wrote:

> 3. I read in Jargon File that "hackers find Ada's exception handling &
> inter-process communication particularly hilarious." among other stuff. Why
> is that? What are the advantages & disadvantages of Ada compare to C or C++
> and other languages?

Re: Learning Ada (newbie)

[Ayende Rahien]

"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:3ACB6286.181416F@ntlworld.com...
> Well, not all "cutting edge"/linux/hacker-types go for this -
www.slashdot.org
> had a reasonably Ada-favourable thread a while back.

Do you've a URL for me?
I would like to read it.

> Maybe GNAT with its GNU links and Open Source background are helping
> break the ice a little...

I hope so, Ada looks interesting.

Re: Learning Ada (newbie)

[Ayende Rahien]

"Marin David Condic"

<Snip, a lot of good advice>
Thanks, for you and everyone else that responded, that was a lot of help.

Re: Learning Ada (newbie)

[Peter Milliken]

Have a look at http://members.nbci.com/pmilliken/ - this is a language
sensitive editting addition to Emacs. It provides full language support for
Ada83 and Ada95. I first learnt Ada in the mid-80's using just such a
package (from DEC), the templating menu system guides you through what
choices are available for language constructs (follows the EBNF for the
language) and saves a lot of typing also! :-)

Aside from my package, Emacs is well supported for programming in Ada, so
even if you prefer to type everything "by hand" you couldn't go too far
wrong with selecting Emacs as your editting environment.

Goodluck in your search,
Peter


"Ayende Rahien" <Dont@spam.me> wrote in message
news:9af9ao$6ee$1@taliesin.netcom.net.uk...
> 1. Where can I learn Ada? Preferably a turial on the web. I'm currently
> reading (http://www.adahome.com/Ammo/Cplpl2Ada.html) which presents some
> very interesting concepts (the fine-grained variables, frex), but it
doesn't
> really teach much. I used to know Pascal (been several years since I
program
> in it), and I know C/C++ pretty well. So I don't really need an
interduction
> to programming, just to Ada itself.
> 2. Can you recommend a good IDE for Ada? Preferably for Windows.
> 3. I read in Jargon File that "hackers find Ada's exception handling &
> inter-process communication particularly hilarious." among other stuff.
Why
> is that? What are the advantages & disadvantages of Ada compare to C or
C++
> and other languages?
>
> Thanks in advance,
>     Ayende Rahien
>
>
>
>

Re: Learning Ada (newbie)

[Jerry Petrey]

Ayende Rahien wrote:
> 
> 1. Where can I learn Ada? Preferably a turial on the web. I'm currently
> reading (http://www.adahome.com/Ammo/Cplpl2Ada.html) which presents some
> very interesting concepts (the fine-grained variables, frex), but it doesn't
> really teach much. I used to know Pascal (been several years since I program
> in it), and I know C/C++ pretty well. So I don't really need an interduction
> to programming, just to Ada itself.
> 2. Can you recommend a good IDE for Ada? Preferably for Windows.
> 3. I read in Jargon File that "hackers find Ada's exception handling &
> inter-process communication particularly hilarious." among other stuff. Why
> is that? What are the advantages & disadvantages of Ada compare to C or C++
> and other languages?
> 
> Thanks in advance,
>     Ayende Rahien


I would recommend you read "Ada Programming Essentials: Overview,
Examples and Glossary".
You can get it from http://www.LearnAda.com/ .
You can read my short review of it (along with some other good Ada book
reviews)
at http://www.seas.gwu.edu/~mfeldman/ada95books.html .

Jerry
-- 
-----------------------------------------------------------------------------
-- Jerry Petrey                                                
-- Senior Principal Systems Engineer - Navigation, Guidance, & Control
-- Raytheon Missile Systems          - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to
reply                  
-----------------------------------------------------------------------------

Re: Learning Ada (newbie)

[martin.m.dowie]

http://slashdot.org/askslashdot/00/05/06/1435238.shtml

That's back to May/june time last year - and there is a fair bit
of dis-information, but most of it is refuted nicely. enjoy! :-)

Ayende Rahien wrote:

> "martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
> news:3ACB6286.181416F@ntlworld.com...
> > Well, not all "cutting edge"/linux/hacker-types go for this -
> www.slashdot.org
> > had a reasonably Ada-favourable thread a while back.
>
> Do you've a URL for me?
> I would like to read it.
>
> > Maybe GNAT with its GNU links and Open Source background are helping
> > break the ice a little...
>
> I hope so, Ada looks interesting.

Re: Learning Ada (newbie)

[BSCrawford]

Jerry Petrey wrote:

>I would recommend you read "Ada Programming Essentials: Overview,
>Examples and Glossary".
>You can get it from http://www.LearnAda.com/ .

I am the author. (Thanks, Jerry :-) 

"Ada Essentials .." is available in three forms.  The HTML version 
costs $12 -- you can download the entire set of web pages into 
your computer.  It has thousands of hyperlinks, making it a good 
resource for self-directed learning -- instant clicking from key terms 
to definitions and from there to related discussions, examples, etc. 

Bard S. Crawford, 
  Author of "Ada Essentials: Overview, Examples and Glossary," 
  a compact volume available in three forms: printed book, pdf 
  file, and a collection of browser-based web pages.  See
http://www.learnada.com  
-----------------------
Stage Harbor Software
9 Patriots Drive - Lexington, MA - 02420 USA
bard@learnada.com - 781-862-3613

Re: Learning Ada (newbie)

[Mark Lundquist]

Ayende Rahien <Dont@spam.me> wrote in message
news:9af9ao$6ee$1@taliesin.netcom.net.uk...

> What are the advantages & disadvantages of Ada compare to C or C++
> and other languages?

OK!  I'd like to take a whack at that question...

"Other languages" of course is pretty broad... :-) so most of my comparisons
will be with the "C-class" languages, C/C++/Java (and there are others on
this group who know Java a lot better than I do, so they can add to what I
have to say).  Someone like Brian Rogoff  :-) can handle comparing Ada with
functional languages like OCAML.   You probably already understand the
issues involved w/ scripting languages vs. compiled languages, so I'll leave
that alone.

I'll give a summary first, then go into more detail in a bit.

The bottom line is: "Done sooner, fewer bugs, less pain".  And over the
lifecycle of a long-lived project, I think that well-written Ada code is
more maintainable than well-written code in many other languages (of course
it is possible to write crap in any language, and there isn't much point in
comparing the crap :-).  This benefit accrues primarily to two factors.

The first factor is the expressive power of Ada, which translates directly
into better understandability of code written in Ada.  I think a
programmer who really knows both Ada C++ (for instance) can communicate
"intent" better in Ada.

The second factor has to do with early detection of programming errors.  Let
me try to explain this.. :-)  When you make a programming mistake, the
result is going to fall into one of four categories:

    1) The compiler will reject your code.  Or,
    2) Your code will compile OK, but when you try to link your program you
         will get errors (undefined symbol references).  Or,
    3) Everything compiles and links OK, but when you run your program it
        blows up with an unhandled exception.  Or,
    4) No exception is raised, your program just goes beserk.  This result
        can range from subtly or occasionally incorrect behavior or results,
to fatal
        errors (e.g."segmentation fault"), to system hangs, to destructive
crashes.

Compile-time errors are generally the easiest thing to figure out.  If I
make a mistake that results in one of these errors, it could be that I just
made a simple mistake that violated one of the language definition rules.
In that case, I just figure out what rule I broke and fix the code.  Other
times, the violation of a language rule points to some underlying logic
error or design error.  Now I have to step back and do some redesign, but
then I'm glad that at least my error was one that could be caught at compile
time instead of later, because later means more head-scratching and farting
around to figure out what the problem was.

A robust, programmer-friendly language would be consciously designed to
"shift" the manifestation of errors along the scale toward the
"compile-time" category and away from "unbounded run-time" category.  This
is just what Ada is designed to do.

The designers of Ada tried to eliminate as much nonsense as possible at
compile time.  For instance, an Ada "function" is analogous to a
non-void-returning function in C (the analog of a void-returning function is
an Ada "procedure").  Now, if you write an Ada function with no "return"
statement, the compiler will reject it because this is not legal Ada.  But
in C, it's perfectly legal for a non-void-returning function not to have a
return statement.  The result of this at run-time is that the caller simply
takes as the return value whatever happens to be in the return-value
register.  Don't miss the fact that this behavior is in fact the *meaning*
of that formulation in C.  Now how likely is it that the programmer intended
this meaning?  Fat chance... How likely is it that he/she just forgot to
write the return statement, or deleted it inadvertently?  Pretty likely.
Now consider that the resulting error may not appear until well after the
product has been released to the user community.

That's just one example out of many.  Another is Ada's "case" statement,
compared to the fall-through semantics of C's "switch" statement.  And it's
well-known that  in C, a simple typo of "=" in place of "==" (or
vice-versa) can escalate right up to an unbounded run-time error.  From the
syntax level all the way up, Ada was consistently designed to catch these
kinds of errors at compile time, and it does this without imposing burdens
on the programmer.

Link-time errors are more of a pain than compile-time errors.  The compiler
has all kinds of information that the linker can't see, so a compiler is
able to give error messages with a lot more specifics about what went wrong.
All a linker can say is "I couldn't resolve symbol X", and then it's up to
me to figure out what I did wrong.  In Ada, linker errors are virtually
unknown.  The only times you ever get a linker error are due to (a) linking
against modules written in other languages; (b) linking against object
module archives (which is legitimate, but outside the scope of what is
defined by the Ada language, or (c) a bug in the Ada language
implementation (compilation system or whatever).  You never get a link error
when linking an ordinary, self-contained Ada program.

Once you get into run-time errors, it's a whole different ball game.  A lot
of times, finding the problem means debugging, which is more or less pain
depending on the nature of the program and the nature of the error.  For a
simple, small program, it's not bad.  For a large system that's heavily
state-dependent and timing-sensitive, debugging can be next to impossible,
i.e., doing it is going to require a serious investment in time and
creativity.

The "exception" error mode is preferable because (a) it gives you a good
hint of where to start when debugging or otherwise investigating the
problem, and (b) it represents a boundedness on the error behavior of the
program; that is, the error is being "caught" at some point by the program
itself rather than going on to wreak more havoc.  The program may have no
better way to deal with the exception than to terminate, but in that case
this is still better than not having raised an exception at all.  When an
error isn't caught by a run-time check, often the result is a chain-reaction
of cascading error effects in the program, and it's not uncommon to begin
investigating by debugging a second- or third-order downstream effect of the
error (for example, the error causes corrupted data which is later read and
causes the observable incorrect behavior).

Obviously, in C all run-time errors fall into the last category (unbounded
run-time error), since C doesn't have exceptions.  C++ has few run-time
checks (bad_cast, bad_typeid) that throw exceptions, so unhandled exceptions
usually originate with an explicit "throw" in the program rather than a
language-defined check.  Java defines a few more run-time checks (such as
the array vounds check), but not as many as Ada.  Ada defines a large number
of run-time checks that raise exceptions, which would otherwise result in
unbounded errors.  Better yet, Ada's language rules are constructed in such
a way that the compilers can often optimize away a suprising number of the
language-defined checks.  Java doesn't have this ability to the same extent.
(It's often asked, "Don't the run-time checks carry a lot of run-time
overhead?"  The answer is, first of all: "Not as much as you might think",
but more importantly, Ada gives you the choice.  All the run-time checks can
be suppressed, either through pragmas in the source code or compilation
options.  So you get to decide the cost-benefit tradeoff as you see fit).


Blow-by-blow, here are the technical aspects I see contributing to the
factors of "expressive power" and/or "early error detection".

1) I think one of the coolest things about Ada is its 'package' construct.
Packages represent the programming concept of a "module" and are absolutely
fundamental in Ada.  The package construct unifies, very cleanly and
elegantly, three important concepts: (1) encapsulation (which is about
privacy, i.e. hiding an abstraction's representation from its clients), (2)
separation of interface and implementation, and (3) namespace control.
Every package has a construct called a "specification" (the interface), and
most packages, depending on the contents of the specification, also require
a "body" (the implementation).  The idea of separation of interface and
implementation calls for more than just textual separation, it implies a
"contract" specified by the interface which the implementation is obligated
to fulfill.  So in Ada, if the body is incomplete or incorrect with respect
to the spec, you get an easy-to-understand compilation error when you try to
compile the body.  If you do not provide a body for a package that requires
one, then you'll get a prelinker error when you try to link the program (not
a linker error complaining that a screenful of symbols is undefined, but a
clear error message that you are "Missing body for package Foobar" or
whatever).

   Compare this with C/C++.  The interface is typically given by a ".h"
header file containing extern declarations, and the implementation is given
by a .[cC] file.  But there is no language-defined correctness/completeness
relationship between the header file and the implementation file, and the
identification of either one with a "module" is entirely notional.  If the
"implementation" doesn't match, the code is still perfectly legal and will
compile just fine.  The backstop for catching this is the linker, when it
can't resolve all the symbols.  Moreover, you can only do this if you are in
a position to link a main program, which is an annoyance when developing
libraries or developing components of large software projects.  And it's
quite easy to violate the interface/implementation contract in ways that are
not caught by the linker, so and so will cause a run-time error.  C/C++ has
three separate mechanisms to handle the three aspects of modularity: classes
for encapsulation, namespaces for namespace control, and the .h/.c
convention to simulate separation of interface and implementation; but the
three mechanisms don't fit together snugly.  Some other random notes... If
you want to inline a member function, it must go in the class declaration,
i.e. the header file (thus violating separation).  The "namespace" construct
in C++ also is inferior to the namespace control provided by Ada packages
(don't have time to go into detail on this).  In C/C++, namespace control
must largely be implemented through ad-hoc policies that must be manually
checked and enforced by a human "name czar" (see the book "Large-Scale C++
Software Design", by John S. Lakos -- it covers high-maintennance techniques
for working around this and other problems that don't exist -- at least to
nowhere the same degree -- in Ada, such as circular compile- and link-time
dependencies).  Ironically, one gripe against Ada is that it has too many
rules.  With other languages, instead of  language-definition rules that
work
with you to help you express intent, you have to submit to labor-intensive
project policies if  you want the project to succeed.

   Compare with Java and Eiffel...  In both of these languages, a class's
interface and implementation are not separated.  Java has a mechanism (the
"interface" construct) that can be used to simulate this, but that's not
really what it's meant for.  I think Eiffel also has a construct that can be
used to achieve some separation of interface and implementation. But in both
cases it would be somewhat onerous to implement a "modularized" design using
these features, and the result would be code written in an unnatural style
for those languages.

   Embracing packages is the "library unit" concept in Ada which allows for
true separate compilation of modules while maintaining semantic
relationships between them.  One result is that the reliance on makefiles
for codifying compilation dependencies is rendered obsolete; the compilation
system can do all the necessary dependency analysis on the fly.

   The bottom line is that since modularity is fundamental to programming,
it should be primitive in a programming language.

2) Ada has a powerful type system.  Some have called this "strong typing",
and strong static type checking is indeed part of it, but not all.  It's not
just that the type system is "strong", it's that it's also "rich".  One
aspect of this is the ability to create user-defined types -- not just
record types (which are like C/C++ structs and classes), but user-defined
numeric types which are distinct from each other and the predefined numeric
types, user-defined array types (most array types in Ada are named, while in
C-class languages they are all anonymous), real enumeration types that are
not aliases for integers and can be used as array index types (and that
don't collapse into ints as soon as you get in with a debugger), and more.
Another aspect of "rich" typing is the very cool concept of "type/subtype"
(no time to go into this right now, and covered in at least two other recent
threads on comp.lang.ada).

The classic example of why you need distinct types even for numbers is
something like this:

    function Area (Radius : Meters) return Square_Meters;

where the types "Meters" and "Square_Meters" both happen to have the same
representation (say, a floating-point number), but are clearly not the same
type.  If you take something of type Square_Meters and try to pass it as the
parameter to Area, you want the language to tell you at compile time.

Packages and the type system head up my short list of technical advantages.
A few others:

3) Generic units, which are similar to C++ templates except that they are
almost perfectly type-safe and compile-time checkable.  They also implement
a programming concept called "constrained genericity", which you can read
about on the Web or wherever (no time to go into it here).  For some, in
whose minds Ada went overboard in requiring explicit instantiation of
generics, Ada generics do not represent the ideal but are still preferable
to C++ templates.  When you make a coding mistake when working with Ada
generics, you get brief and informative compile-time error, where the
comparable mistake in C++ can result in a linker error message that is truly
epic in size and whose cryptic syntax renders it virtually unreadable (if
you've ever used STL, then you know what I'm talking about! :-)

4) Safe pointers.

6) A crisp model for inheritance and dynamic polymorphism that is *not*
based on the idea of a "class".  IMHO, class-oriented languages
(Simula/Smalltalk/C++/Java etc.) embody an intellectual error in their
treatment of encapsulation (privacy and primitive operations, a.k.a.
methods), by making the the "class", which is really a type definition, also
the unit of modularity.  The conflation of "module" and "type" in the notion
of "class" results in all kinds of distortions: special syntax and sematic
complexities for various types of constructors (constructors as a
language-level concept do not exist in Ada, since they are unnecessary
without classes), the need for a "singleton" idiom, and the need for
"friend" classes.

   Also, Ada's dispatching model is nice and clean.  Inheritance does not
imply dispatching, and dispatching is a property of the method invocation,
not just the method declaration.  And you can dispatch on the return type of
a function, not just parameter types.

7) Limited types.  In C++ if you want to define an abstraction that retains
complete control over its own instances, e.g. does not allow clients to copy
instances or test for equality, you have to jump through some hoops --
declaring the abstraction as a class, then declaring private
equality/inequality operators private and constructors.  In Ada, the idea of
a "limited type" is primitive, and you get it by including the single word
"limited" in the type declaration.

8) True array types, including constrained and unconstrained array types and
multidimensional arrays.  The concept of an "array" is another fundamental
programming concept, and collapsing to the pointer-based, machine-model
level
a la C/C++ doesn't do it justice.

9) Support for tasking and task communication/synchronization, at a higher
and nicer level of abstraction than the "thread" level.  The tasking model
allows all kinds of errors to be caught at compile time that are simply
impossible when coding to thread-level library routines.  The task priority
model is unified with interrupt priorities.

10) To make it an even 'Top-Ten List' :-)... The Ada Reference Manual is a
masterpiece of definition.  That's about all I can say about it!

It could go on, the list of advantages by no means ends there.  OK,
fine-grained control over the machine-level representation of data
structures... package elaboration... lexical scoping... better string
handling...

Compared to other mainstream languages, Ada holds a lot of cards in
terms of technical advantages.  Some technical disadvantages:

1) A lot of people think Ada would be better if it had more support for
something like Eiffel-style "Design By Contract" (preconditions,
postconditions, invariants).  Personally, I'm undecided, but quite
intrigued.

2) That's about all I can think of right now.  That doesn't mean there
aren't a lot of things I'd like to see improved, I just don't think the
things on my wish list rise to the level of "disadvantages", especially
compared to C/C++/Java.


> 3. I read in Jargon File that "hackers find Ada's exception handling &
> inter-process communication particularly hilarious." among other stuff.
Why
> is that?

In all honesty, nobody knows.  This is just somebody talking out of the
wrong orifice :-)  The Jargon File seems to be a pretty good source for
information about jargon, i.e. slang terms.  I doubt if it's much good for
anything else.  In addition to the "particularly hilarious" nonsense, the JF
entry perpetuates the myth that Ada was "designed by committee" (patently un
true, as a matter of public record) and refers to Ada's "elephantine bulk",
which is hardly fair... Once the C++ standard was published at long last, it
was basically just as huge, and even at that, success in C++ still depends
on a large knowledge structure that falls outside the language itself --
linker and makefile details, the standard libraries, threads libraries...
but mostly a vast body of knowledge of "pitfalls" about which whole books
have been written.  These pitfalls are all the same kinds of things that
were designed away in Ada, whose language definition is roughly the same
size.

Mark Lundquist
Rational Software

Re: Learning Ada (newbie)

[Marin David Condic]

Many Kudos. You might just want to spiff this up a little bit and submit it
somewhere as an article. I like the commentary about catching errors early.
You might want to note that catching errors early is not just a matter of
coolness or intellectual tidiness. It translates very directly into $$$$$
saved! (I'm currently doing a *lot* of C programming and getting quite
urinated-off at the lack of checking that makes me have to get code loaded
into the box, executed, exploded and debugged just to discover some kind of
parameter mismatch happened that I could have fixed at compile time & saved
myself the whole development iteration!!!) Money is a pretty strong
incentive for the commercial developer - it just isn't well known that Ada
will, in fact, save you quite a bit of it.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Mark Lundquist" <mark@rational.com> wrote in message
news:z75z6.679803$U46.21074483@news1.sttls1.wa.home.com...
>
> Ayende Rahien <Dont@spam.me> wrote in message
> news:9af9ao$6ee$1@taliesin.netcom.net.uk...
>
> > What are the advantages & disadvantages of Ada compare to C or C++
> > and other languages?
>
> OK!  I'd like to take a whack at that question...
>
> "Other languages" of course is pretty broad... :-) so most of my
comparisons
> will be with the "C-class" languages, C/C++/Java (and there are others on
> this group who know Java a lot better than I do, so they can add to what I
> have to say).  Someone like Brian Rogoff  :-) can handle comparing Ada
with
> functional languages like OCAML.   You probably already understand the
> issues involved w/ scripting languages vs. compiled languages, so I'll
leave
> that alone.
>
> I'll give a summary first, then go into more detail in a bit.
>
> The bottom line is: "Done sooner, fewer bugs, less pain".  And over the
> lifecycle of a long-lived project, I think that well-written Ada code is
> more maintainable than well-written code in many other languages (of
course
> it is possible to write crap in any language, and there isn't much point
in
> comparing the crap :-).  This benefit accrues primarily to two factors.
>
> The first factor is the expressive power of Ada, which translates directly
> into better understandability of code written in Ada.  I think a
> programmer who really knows both Ada C++ (for instance) can communicate
> "intent" better in Ada.
>
> The second factor has to do with early detection of programming errors.
Let
> me try to explain this.. :-)  When you make a programming mistake, the
> result is going to fall into one of four categories:
>
>     1) The compiler will reject your code.  Or,
>     2) Your code will compile OK, but when you try to link your program
you
>          will get errors (undefined symbol references).  Or,
>     3) Everything compiles and links OK, but when you run your program it
>         blows up with an unhandled exception.  Or,
>     4) No exception is raised, your program just goes beserk.  This result
>         can range from subtly or occasionally incorrect behavior or
results,
> to fatal
>         errors (e.g."segmentation fault"), to system hangs, to destructive
> crashes.
>
> Compile-time errors are generally the easiest thing to figure out.  If I
> make a mistake that results in one of these errors, it could be that I
just
> made a simple mistake that violated one of the language definition rules.
> In that case, I just figure out what rule I broke and fix the code.  Other
> times, the violation of a language rule points to some underlying logic
> error or design error.  Now I have to step back and do some redesign, but
> then I'm glad that at least my error was one that could be caught at
compile
> time instead of later, because later means more head-scratching and
farting
> around to figure out what the problem was.
>
> A robust, programmer-friendly language would be consciously designed to
> "shift" the manifestation of errors along the scale toward the
> "compile-time" category and away from "unbounded run-time" category.  This
> is just what Ada is designed to do.
>
> The designers of Ada tried to eliminate as much nonsense as possible at
> compile time.  For instance, an Ada "function" is analogous to a
> non-void-returning function in C (the analog of a void-returning function
is
> an Ada "procedure").  Now, if you write an Ada function with no "return"
> statement, the compiler will reject it because this is not legal Ada.  But
> in C, it's perfectly legal for a non-void-returning function not to have a
> return statement.  The result of this at run-time is that the caller
simply
> takes as the return value whatever happens to be in the return-value
> register.  Don't miss the fact that this behavior is in fact the *meaning*
> of that formulation in C.  Now how likely is it that the programmer
intended
> this meaning?  Fat chance... How likely is it that he/she just forgot to
> write the return statement, or deleted it inadvertently?  Pretty likely.
> Now consider that the resulting error may not appear until well after the
> product has been released to the user community.
>
> That's just one example out of many.  Another is Ada's "case" statement,
> compared to the fall-through semantics of C's "switch" statement.  And
it's
> well-known that  in C, a simple typo of "=" in place of "==" (or
> vice-versa) can escalate right up to an unbounded run-time error.  From
the
> syntax level all the way up, Ada was consistently designed to catch these
> kinds of errors at compile time, and it does this without imposing burdens
> on the programmer.
>
> Link-time errors are more of a pain than compile-time errors.  The
compiler
> has all kinds of information that the linker can't see, so a compiler is
> able to give error messages with a lot more specifics about what went
wrong.
> All a linker can say is "I couldn't resolve symbol X", and then it's up to
> me to figure out what I did wrong.  In Ada, linker errors are virtually
> unknown.  The only times you ever get a linker error are due to (a)
linking
> against modules written in other languages; (b) linking against object
> module archives (which is legitimate, but outside the scope of what is
> defined by the Ada language, or (c) a bug in the Ada language
> implementation (compilation system or whatever).  You never get a link
error
> when linking an ordinary, self-contained Ada program.
>
> Once you get into run-time errors, it's a whole different ball game.  A
lot
> of times, finding the problem means debugging, which is more or less pain
> depending on the nature of the program and the nature of the error.  For a
> simple, small program, it's not bad.  For a large system that's heavily
> state-dependent and timing-sensitive, debugging can be next to impossible,
> i.e., doing it is going to require a serious investment in time and
> creativity.
>
> The "exception" error mode is preferable because (a) it gives you a good
> hint of where to start when debugging or otherwise investigating the
> problem, and (b) it represents a boundedness on the error behavior of the
> program; that is, the error is being "caught" at some point by the program
> itself rather than going on to wreak more havoc.  The program may have no
> better way to deal with the exception than to terminate, but in that case
> this is still better than not having raised an exception at all.  When an
> error isn't caught by a run-time check, often the result is a
chain-reaction
> of cascading error effects in the program, and it's not uncommon to begin
> investigating by debugging a second- or third-order downstream effect of
the
> error (for example, the error causes corrupted data which is later read
and
> causes the observable incorrect behavior).
>
> Obviously, in C all run-time errors fall into the last category (unbounded
> run-time error), since C doesn't have exceptions.  C++ has few run-time
> checks (bad_cast, bad_typeid) that throw exceptions, so unhandled
exceptions
> usually originate with an explicit "throw" in the program rather than a
> language-defined check.  Java defines a few more run-time checks (such as
> the array vounds check), but not as many as Ada.  Ada defines a large
number
> of run-time checks that raise exceptions, which would otherwise result in
> unbounded errors.  Better yet, Ada's language rules are constructed in
such
> a way that the compilers can often optimize away a suprising number of the
> language-defined checks.  Java doesn't have this ability to the same
extent.
> (It's often asked, "Don't the run-time checks carry a lot of run-time
> overhead?"  The answer is, first of all: "Not as much as you might think",
> but more importantly, Ada gives you the choice.  All the run-time checks
can
> be suppressed, either through pragmas in the source code or compilation
> options.  So you get to decide the cost-benefit tradeoff as you see fit).
>
>
> Blow-by-blow, here are the technical aspects I see contributing to the
> factors of "expressive power" and/or "early error detection".
>
> 1) I think one of the coolest things about Ada is its 'package' construct.
> Packages represent the programming concept of a "module" and are
absolutely
> fundamental in Ada.  The package construct unifies, very cleanly and
> elegantly, three important concepts: (1) encapsulation (which is about
> privacy, i.e. hiding an abstraction's representation from its clients),
(2)
> separation of interface and implementation, and (3) namespace control.
> Every package has a construct called a "specification" (the interface),
and
> most packages, depending on the contents of the specification, also
require
> a "body" (the implementation).  The idea of separation of interface and
> implementation calls for more than just textual separation, it implies a
> "contract" specified by the interface which the implementation is
obligated
> to fulfill.  So in Ada, if the body is incomplete or incorrect with
respect
> to the spec, you get an easy-to-understand compilation error when you try
to
> compile the body.  If you do not provide a body for a package that
requires
> one, then you'll get a prelinker error when you try to link the program
(not
> a linker error complaining that a screenful of symbols is undefined, but a
> clear error message that you are "Missing body for package Foobar" or
> whatever).
>
>    Compare this with C/C++.  The interface is typically given by a ".h"
> header file containing extern declarations, and the implementation is
given
> by a .[cC] file.  But there is no language-defined
correctness/completeness
> relationship between the header file and the implementation file, and the
> identification of either one with a "module" is entirely notional.  If the
> "implementation" doesn't match, the code is still perfectly legal and will
> compile just fine.  The backstop for catching this is the linker, when it
> can't resolve all the symbols.  Moreover, you can only do this if you are
in
> a position to link a main program, which is an annoyance when developing
> libraries or developing components of large software projects.  And it's
> quite easy to violate the interface/implementation contract in ways that
are
> not caught by the linker, so and so will cause a run-time error.  C/C++
has
> three separate mechanisms to handle the three aspects of modularity:
classes
> for encapsulation, namespaces for namespace control, and the .h/.c
> convention to simulate separation of interface and implementation; but the
> three mechanisms don't fit together snugly.  Some other random notes... If
> you want to inline a member function, it must go in the class declaration,
> i.e. the header file (thus violating separation).  The "namespace"
construct
> in C++ also is inferior to the namespace control provided by Ada packages
> (don't have time to go into detail on this).  In C/C++, namespace control
> must largely be implemented through ad-hoc policies that must be manually
> checked and enforced by a human "name czar" (see the book "Large-Scale C++
> Software Design", by John S. Lakos -- it covers high-maintennance
techniques
> for working around this and other problems that don't exist -- at least to
> nowhere the same degree -- in Ada, such as circular compile- and link-time
> dependencies).  Ironically, one gripe against Ada is that it has too many
> rules.  With other languages, instead of  language-definition rules that
> work
> with you to help you express intent, you have to submit to labor-intensive
> project policies if  you want the project to succeed.
>
>    Compare with Java and Eiffel...  In both of these languages, a class's
> interface and implementation are not separated.  Java has a mechanism (the
> "interface" construct) that can be used to simulate this, but that's not
> really what it's meant for.  I think Eiffel also has a construct that can
be
> used to achieve some separation of interface and implementation. But in
both
> cases it would be somewhat onerous to implement a "modularized" design
using
> these features, and the result would be code written in an unnatural style
> for those languages.
>
>    Embracing packages is the "library unit" concept in Ada which allows
for
> true separate compilation of modules while maintaining semantic
> relationships between them.  One result is that the reliance on makefiles
> for codifying compilation dependencies is rendered obsolete; the
compilation
> system can do all the necessary dependency analysis on the fly.
>
>    The bottom line is that since modularity is fundamental to programming,
> it should be primitive in a programming language.
>
> 2) Ada has a powerful type system.  Some have called this "strong typing",
> and strong static type checking is indeed part of it, but not all.  It's
not
> just that the type system is "strong", it's that it's also "rich".  One
> aspect of this is the ability to create user-defined types -- not just
> record types (which are like C/C++ structs and classes), but user-defined
> numeric types which are distinct from each other and the predefined
numeric
> types, user-defined array types (most array types in Ada are named, while
in
> C-class languages they are all anonymous), real enumeration types that are
> not aliases for integers and can be used as array index types (and that
> don't collapse into ints as soon as you get in with a debugger), and more.
> Another aspect of "rich" typing is the very cool concept of "type/subtype"
> (no time to go into this right now, and covered in at least two other
recent
> threads on comp.lang.ada).
>
> The classic example of why you need distinct types even for numbers is
> something like this:
>
>     function Area (Radius : Meters) return Square_Meters;
>
> where the types "Meters" and "Square_Meters" both happen to have the same
> representation (say, a floating-point number), but are clearly not the
same
> type.  If you take something of type Square_Meters and try to pass it as
the
> parameter to Area, you want the language to tell you at compile time.
>
> Packages and the type system head up my short list of technical
advantages.
> A few others:
>
> 3) Generic units, which are similar to C++ templates except that they are
> almost perfectly type-safe and compile-time checkable.  They also
implement
> a programming concept called "constrained genericity", which you can read
> about on the Web or wherever (no time to go into it here).  For some, in
> whose minds Ada went overboard in requiring explicit instantiation of
> generics, Ada generics do not represent the ideal but are still preferable
> to C++ templates.  When you make a coding mistake when working with Ada
> generics, you get brief and informative compile-time error, where the
> comparable mistake in C++ can result in a linker error message that is
truly
> epic in size and whose cryptic syntax renders it virtually unreadable (if
> you've ever used STL, then you know what I'm talking about! :-)
>
> 4) Safe pointers.
>
> 6) A crisp model for inheritance and dynamic polymorphism that is *not*
> based on the idea of a "class".  IMHO, class-oriented languages
> (Simula/Smalltalk/C++/Java etc.) embody an intellectual error in their
> treatment of encapsulation (privacy and primitive operations, a.k.a.
> methods), by making the the "class", which is really a type definition,
also
> the unit of modularity.  The conflation of "module" and "type" in the
notion
> of "class" results in all kinds of distortions: special syntax and sematic
> complexities for various types of constructors (constructors as a
> language-level concept do not exist in Ada, since they are unnecessary
> without classes), the need for a "singleton" idiom, and the need for
> "friend" classes.
>
>    Also, Ada's dispatching model is nice and clean.  Inheritance does not
> imply dispatching, and dispatching is a property of the method invocation,
> not just the method declaration.  And you can dispatch on the return type
of
> a function, not just parameter types.
>
> 7) Limited types.  In C++ if you want to define an abstraction that
retains
> complete control over its own instances, e.g. does not allow clients to
copy
> instances or test for equality, you have to jump through some hoops --
> declaring the abstraction as a class, then declaring private
> equality/inequality operators private and constructors.  In Ada, the idea
of
> a "limited type" is primitive, and you get it by including the single word
> "limited" in the type declaration.
>
> 8) True array types, including constrained and unconstrained array types
and
> multidimensional arrays.  The concept of an "array" is another fundamental
> programming concept, and collapsing to the pointer-based, machine-model
> level
> a la C/C++ doesn't do it justice.
>
> 9) Support for tasking and task communication/synchronization, at a higher
> and nicer level of abstraction than the "thread" level.  The tasking model
> allows all kinds of errors to be caught at compile time that are simply
> impossible when coding to thread-level library routines.  The task
priority
> model is unified with interrupt priorities.
>
> 10) To make it an even 'Top-Ten List' :-)... The Ada Reference Manual is a
> masterpiece of definition.  That's about all I can say about it!
>
> It could go on, the list of advantages by no means ends there.  OK,
> fine-grained control over the machine-level representation of data
> structures... package elaboration... lexical scoping... better string
> handling...
>
> Compared to other mainstream languages, Ada holds a lot of cards in
> terms of technical advantages.  Some technical disadvantages:
>
> 1) A lot of people think Ada would be better if it had more support for
> something like Eiffel-style "Design By Contract" (preconditions,
> postconditions, invariants).  Personally, I'm undecided, but quite
> intrigued.
>
> 2) That's about all I can think of right now.  That doesn't mean there
> aren't a lot of things I'd like to see improved, I just don't think the
> things on my wish list rise to the level of "disadvantages", especially
> compared to C/C++/Java.
>
>
> > 3. I read in Jargon File that "hackers find Ada's exception handling &
> > inter-process communication particularly hilarious." among other stuff.
> Why
> > is that?
>
> In all honesty, nobody knows.  This is just somebody talking out of the
> wrong orifice :-)  The Jargon File seems to be a pretty good source for
> information about jargon, i.e. slang terms.  I doubt if it's much good for
> anything else.  In addition to the "particularly hilarious" nonsense, the
JF
> entry perpetuates the myth that Ada was "designed by committee" (patently
un
> true, as a matter of public record) and refers to Ada's "elephantine
bulk",
> which is hardly fair... Once the C++ standard was published at long last,
it
> was basically just as huge, and even at that, success in C++ still depends
> on a large knowledge structure that falls outside the language itself --
> linker and makefile details, the standard libraries, threads libraries...
> but mostly a vast body of knowledge of "pitfalls" about which whole books
> have been written.  These pitfalls are all the same kinds of things that
> were designed away in Ada, whose language definition is roughly the same
> size.
>
> Mark Lundquist
> Rational Software
>
>
>

Re: Learning Ada (newbie)

[Ayende Rahien]

"Mark Lundquist" <mark@rational.com> wrote in message
news:z75z6.679803$U46.21074483@news1.sttls1.wa.home.com...

Thanks, that was very educating, as well as intersting, two things that
don't con-exist often.

Re: Learning Ada (newbie)

[Ayende Rahien]

"Ayende Rahien" <Dont@spam.me> wrote in message
news:9aj49r$aul$1@taliesin.netcom.net.uk...
>
> "Mark Lundquist" <mark@rational.com> wrote in message
> news:z75z6.679803$U46.21074483@news1.sttls1.wa.home.com...
>
> Thanks, that was very educating, as well as intersting, two things that
> don't con-exist often.

That is co-exist, not con exist, sorry.

Re: Learning Ada (newbie)

[Mark Lundquist]

Marin David Condic <marin.condic.auntie.spam@pacemicro.com> wrote in message
news:9aiq8h$ik8$1@nh.pace.co.uk...
> Many Kudos.

thx!

> You might just want to spiff this up a little bit and submit it
> somewhere as an article.

It'd certainly need an up-spiffing, but I could go for that...

Do you (or does anyone!) have any suggestions as to publications I might
submit it to?

> I like the commentary about catching errors early.
> You might want to note that catching errors early is not just a matter of
> coolness or intellectual tidiness. It translates very directly into $$$$$
> saved!

Good point! :-)

thx again,
-- mark

Re: Learning Ada (newbie)

[Martin Dowie]

what happened to point 5) - the anonymous point! :-)

Mark Lundquist <mark@rational.com> wrote in message
news:z75z6.679803$U46.21074483@news1.sttls1.wa.home.com...
>
> Ayende Rahien <Dont@spam.me> wrote in message
> news:9af9ao$6ee$1@taliesin.netcom.net.uk...
>
>
> 4) Safe pointers.
>
> 6) A crisp model for inheritance and dynamic polymorphism that is *not*
> based on the idea of a "class".  IMHO, class-oriented languages
> (Simula/Smalltalk/C++/Java etc.) embody an intellectual error in their
> treatment of encapsulation (privacy and primitive operations, a.k.a.
> methods), by making the the "class", which is really a type definition,
also
> the unit of modularity.  The conflation of "module" and "type" in the
notion
> of "class" results in all kinds of distortions: special syntax and sematic
> complexities for various types of constructors (constructors as a
> language-level concept do not exist in Ada, since they are unnecessary
> without classes), the need for a "singleton" idiom, and the need for
> "friend" classes.
>
>    Also, Ada's dispatching model is nice and clean.  Inheritance does not
> imply dispatching, and dispatching is a property of the method invocation,
> not just the method declaration.  And you can dispatch on the return type
of
> a function, not just parameter types.
>

Re: Learning Ada (newbie)

[Mark Lundquist]

Yeah I know.. I guess it's a Tip-9 List after all :-)

Martin Dowie <martin.dowie@nospam.baesystems.com> wrote in message
news:3acd6863$1@pull.gecm.com...
> what happened to point 5) - the anonymous point! :-)

Re: Learning Ada (newbie)

[Ted Dennison]

In article <9aiq8h$ik8$1@nh.pace.co.uk>, Marin David Condic says...
>
>You might want to note that catching errors early is not just a matter of
>coolness or intellectual tidiness. It translates very directly into $$$$$
>saved! (I'm currently doing a *lot* of C programming and getting quite

That's very true, but I wouldn't even stop there. To a corporation time is
indeed money. But to you and me as developers it can be much more than that. We
have personal lives to live, and interpersonal relationships to nurture. 

Many times integration has to happen at a customer site, far from one's family.
If its a relatively quick and smooth integration, that's no big deal. It can
even bit kind of fun. But once it starts to get to be more than a couple of
weeks or so, it can start to put a big strain on people's personal
relationships. Thus pushing error-finding off into later phases of a project can
not only have monetary consequences, but social consequences as well. 

I had one very close friend whose marrige broke up as a direct result of the
exteneded separation imposed by integration of buggy C code. (One example of a
bug they found: An array out-of-bounds indexing error which would have at worst
immediately raised an exception in Ada, instead caused an odd intermittent
symptom 2 networked computers away. It took them 3 *weeks* to track it down.) I
had another close friend working on the same project with *5* young kids at
home, whose marriage very nearly broke up, again directly related to the
extended separation. Of course for you mercenary types, this also cost the
corporation even more money. For one thing, all that site time living in hotels,
etc., isn't cheap. For another, neither one of these valuable developers were
very productive at work for the next 4 months while they desperately tried to
get their personal lives back in order. But I'd argue that there were (and are)
more important issues at stake than meer money. 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Learning Ada (newbie)

[Marin David Condic]

Yes, but don't say "mere money". The *ONLY* reason I bother to show up here
every morning (work, that is) and the *ONLY* reason they bother to open up
the doors at all is because of money. If they stopped paying me, I'd be at
home, working on The Great American Operating System. (Or out at the Juno
Beach pier with a fishing stick in one hand and a cold one in in the other!
Its definitely toooooo gorgeous here today to be at work!!! :-)

If money stopped flowing in from customers, I doubt we'd be building our
products out of charity or because it makes a cool hobby. So from the
standpoint of making *business* decisions about what technology to use, Ada
makes sense (sometimes) because the early detection of bugs makes them
(sometimes substantially) less expensive to fix. (How much less depends on
how long your turnaround time is to get a new version fielded. That's why I
noted "sometimes".)

Of course, there are other economic factors to consider such as
infrastructure, knowledge base, tools, problem domain, etc. But with the
standard issue "All Other Things Being Equal" qualifier, Ada is a money
saver because of early error detection.

I agree with your point that there are more important things in life than
spending time chasing down stupid errors. Its a bad idea to sacrifice one's
marriage in order to spend hours in the lab debugging stupid C errors. Of
course, one's willingness to sign up for that on a consistent basis may be a
sign that one enjoys midnight debugging sessions (puzzle solving? sense of
self-importance?) and that's why one selects C instead of Ada. Either that,
or one has a wife from whom time away is a relief. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Ted Dennison" <dennison@telepath.com> wrote in message
news:Hakz6.3384$jz.287874@www.newsranger.com...
> In article <9aiq8h$ik8$1@nh.pace.co.uk>, Marin David Condic says...
> >
> >You might want to note that catching errors early is not just a matter of
> >coolness or intellectual tidiness. It translates very directly into $$$$$
> >saved! (I'm currently doing a *lot* of C programming and getting quite
>
> That's very true, but I wouldn't even stop there. To a corporation time is
> indeed money. But to you and me as developers it can be much more than
that. We
> have personal lives to live, and interpersonal relationships to nurture.
>
> Many times integration has to happen at a customer site, far from one's
family.
> If its a relatively quick and smooth integration, that's no big deal. It
can
> even bit kind of fun. But once it starts to get to be more than a couple
of
> weeks or so, it can start to put a big strain on people's personal
> relationships. Thus pushing error-finding off into later phases of a
project can
> not only have monetary consequences, but social consequences as well.
>
> I had one very close friend whose marrige broke up as a direct result of
the
> exteneded separation imposed by integration of buggy C code. (One example
of a
> bug they found: An array out-of-bounds indexing error which would have at
worst
> immediately raised an exception in Ada, instead caused an odd intermittent
> symptom 2 networked computers away. It took them 3 *weeks* to track it
down.) I
> had another close friend working on the same project with *5* young kids
at
> home, whose marriage very nearly broke up, again directly related to the
> extended separation. Of course for you mercenary types, this also cost the
> corporation even more money. For one thing, all that site time living in
hotels,
> etc., isn't cheap. For another, neither one of these valuable developers
were
> very productive at work for the next 4 months while they desperately tried
to
> get their personal lives back in order. But I'd argue that there were (and
are)
> more important issues at stake than meer money.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Learning Ada (newbie)

[Mark Lundquist]

Mark Lundquist <mark@rational.com> wrote in message
news:B8kz6.682507$U46.21204123@news1.sttls1.wa.home.com...
>
> Yeah I know.. I guess it's a Tip-9 List after all :-)

I mean, "a Top-9 List"... sheesh, can't even type this morning.
Must... have... more... coffee!...
:-)

Re: Learning Ada (newbie)

[Mark Lundquist]

Ted Dennison <dennison@telepath.com> wrote in message
news:Hakz6.3384$jz.287874@www.newsranger.com...
> In article <9aiq8h$ik8$1@nh.pace.co.uk>, Marin David Condic says...
> >

>
> I had one very close friend whose marrige broke up as a direct result of
the
> exteneded separation imposed by integration of buggy C code. (One example
of a
> bug they found: An array out-of-bounds indexing error which would have at
worst
> immediately raised an exception in Ada, instead caused an odd intermittent
> symptom 2 networked computers away. It took them 3 *weeks* to track it
down.) I
> had another close friend working on the same project with *5* young kids
at
> home, whose marriage very nearly broke up, again directly related to the
> extended separation.

Wow.

I think everybody recognizes that professional and personal life are
intertwined.  And I don't think anyone would deny the strong connection
between the technical world and the professional world...

But the consequence, that the technical world thereby affects the personal
life, is something that's maybe not often considered (I know I've never
really thought about it quite in those terms before...)

Maybe there's some coalition of divorce lawyers behind the C-class language
hegemony and the anti-Ada climate. :-)  Or "sucky software" in general;
maybe Ron Oliver should examine this in the next round of his inquiry...:-)

-- mark

Re: Learning Ada (newbie)

[Britt Snodgrass]

Mark Lundquist wrote:
> 
> Marin David Condic <marin.condic.auntie.spam@pacemicro.com> wrote in message
> news:9aiq8h$ik8$1@nh.pace.co.uk...
> > Many Kudos.
> 
> thx!
> 
> > You might just want to spiff this up a little bit and submit it
> > somewhere as an article.
> 
> It'd certainly need an up-spiffing, but I could go for that...
> 
> Do you (or does anyone!) have any suggestions as to publications I might
> submit it to?

Mark,

I just stumbled on the following URL where fatbrain.com is providing
various whitepapers for free.  It looks like it might be a good place to
put some pro-Ada articles:

http://fatbrain.tradespeak.com/res.asp?rfx=001&level=3&catname=Programming+Languages&catcode=0001002014

However I didn't see instructions on how to submit a whitepaper.

Britt

Re: Learning Ada (newbie)

[Georg Bauhaus]

Marin David Condic (marin.condic.auntie.spam@pacemicro.com) wrote:
: (I'm currently doing a *lot* of C programming and getting quite
: urinated-off at the lack of checking

Have you been trying LCLint? It does many many checks
beyond what gcc -pedantic will do. It's also helps a
lot in building ADTs even in C.

Georg

Re: Learning Ada (newbie)

[Marin David Condic]

AFAIK, we don't have this in-house at this time. It might be worth looking
around for a way to include this in our compilation procedures to help cut
down on the problems to some extent.

The biggest problem is that too many of the "stupid mistake" errors that
happen frequently in C are also the "clever trick" features that regularly
get used in C programming. Checking for them and trying to eliminate them
leaves you with the problem of being alerted to all sorts of "legitimate"
uses of those features. Now you've got to deal with the "I meant to do that"
problem. Does someone come by afterwards, see the warnings and waste a lot
of time trying to eliminate them only to discover that this was what was
intended?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:9ankht$oaj$1@a1-hrz.uni-duisburg.de...
> Have you been trying LCLint? It does many many checks
> beyond what gcc -pedantic will do. It's also helps a
> lot in building ADTs even in C.
>
> Georg

Re: Learning Ada (newbie)

[David Thompson]

(posted&mailed)
Mark Lundquist <mark@rational.com> wrote :
[ long and good summary from which I pick only a few nits ]
...
> The second factor has to do with early detection of programming errors.
> .... Now, if you write an Ada function with no "return"
> statement, the compiler will reject it because this is not legal Ada.  But
> in C, it's perfectly legal for a non-void-returning function not to have a
> return statement.  The result of this at run-time is that the caller simply
> takes as the return value whatever happens to be in the return-value
> register.  Don't miss the fact that this behavior is in fact the *meaning*
> of that formulation in C.  Now how likely is it that the programmer intended
> this meaning?  Fat chance...

Technically in the C standard it is Undefined Behavior (= unbounded error)
if a non-void function "falls off the end" without executing a return statement
_and_ the caller tries to use the returned value.  What you describe
(just using whatever happens to be lying about in the return register)
is a common implementation but not required.

> That's just one example out of many.  Another is Ada's "case" statement,
> compared to the fall-through semantics of C's "switch" statement.  And it's
> well-known that  in C, a simple typo of "=" in place of "==" (or
> vice-versa) can escalate right up to an unbounded run-time error.  ...

Certainly substituting = for == or vice versa is a common bug,
to the point that better compilers warn about (but can't reject)
using an assignment where a predicate is normally expected,
but rarely unbounded error; if a comparison == was legal
and the assignment = does not violate the compile-time constraint
that the left hand side must be an lvalue and apparently modifiable,
the assignment is usually well-defined though wrong.
The only case that gets by here is if the target is actually
a const object but you have "deconstified" the lvalue
used in the assignment, which is hard to do by accident.
If an assignment was legal a comparison is well-defined
unless the left hand side is an "auto" (stack) object
not initialized or previously assigned, and a good compiler
can frequently warn of this.

> Link-time errors are more of a pain than compile-time errors.  The compiler
> has all kinds of information that the linker can't see, so a compiler is
> able to give error messages with a lot more specifics about what went wrong.
> All a linker can say is "I couldn't resolve symbol X", and then it's up to
> me to figure out what I did wrong.

Especially in C++ where the (apparently) missing symbol
may be one of many overloads of a function, or implicit
template instantiations, involving implicitly promoted types.

...
> Obviously, in C all run-time errors fall into the last category (unbounded
> run-time error), since C doesn't have exceptions.  ...

In practice mostly true, although it is not actually prohibited
and _occasionally_ done for the runtime support to detect
an error and give a clean dump.

...
> 2) Ada has a powerful type system.  ....
> user-defined array types (most array types in Ada are named, while in
> C-class languages they are all anonymous), real enumeration types that are
> not aliases for integers and can be used as array index types (and that
> don't collapse into ints as soon as you get in with a debugger), and more.

C can create a name for an array type (or any other) with typedef,
though it is often confusing to do so for arrays in particular because
they are not first-class (as you note below).  Good debuggers can
handle enum names properly -- but there is no in-language facility
for doing so like 'Image.  Your other points stand.

> 3) Generic units, which are similar to C++ templates except that they are
> almost perfectly type-safe and compile-time checkable.  ...
> ... mistake in C++ can result in a linker error message that is truly
> epic in size and whose cryptic syntax renders it virtually unreadable (if
> you've ever used STL, then you know what I'm talking about! :-)
>
C++ template instantiations are fully compile-time checked
(at any rate as fully as explicitly-written code) and can be
typesafe if you write them that way, although to the extent
you use them for C-ish code they tend not to be.
Most STL mistakes tend to produce cryptic _compiler_ error
messages rather than linker ones (not much better).

...
> 8) True array types, including constrained and unconstrained array types and
> multidimensional arrays.  The concept of an "array" is another fundamental
> programming concept, and collapsing to the pointer-based, machine-model
> level
> a la C/C++ doesn't do it justice.
>
In C++ (only) you have the option of writing array-like classes
which are somewhat better, if you go to the trouble,
but the builtin C-style arrays can't be disabled.


--
- David.Thompson 1 now at worldnet.att.net