Re: Do we need "Mission-Critical" software? Was: What to Do?

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

Cesar Scarpini Rabak wrote:
> "Warren W. Gay VE3WWG" wrote:
> > Cesar Scarpini Rabak wrote:
> > > "Warren W. Gay VE3WWG" wrote:
> > > [snipped]
> > > > First of all, I like the idea of the book. It should be written.
> > >
> > > A book! Let's start with an article and have it published in Dr. Dobbs's
> > > Mag first!
> > >
> > > just my .019...
> >
> > Articles are also fine ;-)
> 
> Great, lets see if we get enough material to pump a good one!
> Incidentally, Dr. Dobbs _did_ publish an article about GNAT some time
> ago (my personal library is all packed from a recent office moving and
> could not pinpoint in their site).

I missed that one (over a year ago?) I did see an article in the Linux
Journal, which was nice to see.

 > I'm not suggesting that the Ada95 language and/or compiler will solve all
> > security problems, or even reliability ones. But it does allow your CPU
> > to point out a lot of very common problems that lead to unreliable and/or
> > insecure programs. If you focus on all other aspects of security, as people
> > do when the write in C/C++/Java for example, then you leave unecessary
> > risks within the system. In a nutshell, Ada95 greatly improves the chances
> > of a program being correct, and less likely to be exploitable.
> 
> Agreed. But, again we're lost in the "mainstream" school of thought.
> Java advocates convinced the masses that the "only" dangerous feature of
> a nice language (C++) was pointers so they made an elegant one (only OO)
> w/o pointers... and rest is history. (Anedoctically  it can be added
> that in the infant days of Java a lot of people used to say that JAVA
> stand for "Just Another Version of Ada"!)

Besides doing our best to contribute in Ada code, I think the next best
thing is perhaps the "educational aspect", which I think you're hinting
at.

Anyway, I think some carefully constructed articles for various magazines
may help increase some interest. I think that one approach might be to
assume C++ knowledge, and show how things are done in Ada in comparison
fashion. While doing so, the article should quietly show why Ada95 does 
it better, of course.

I also think you need to do some comparisons of real-life programming in the
two languages. For example, show examples with records (possibly tagged)
with discrimants affecting the contained array bounds. This is one of the
ugliest problems in C/C++. Anyway, you can probably think of many more 
(I am just thinking out loud).

Other articles could take the "Why Ada?" approach. Perhaps sprinkled
with information about where Ada was, is today, and is likely to be in
the future. It seems that a lot of people have a number of pre-conceived
misconceptions about the language, and its design. I'm not sure that
surveys and studies are what readers want however (links to them would
be good for the curious of course).

A decade ago, compiler size was important on a 386. Disk space was low,
and PC CPUs were not fast. Apparently Linus Torvalds dropped the idea of 
using C++ for Linux, after a while. This was because gcc was too slow 
on the 386 at the time. Now, things are considerably different. Perhaps
this was a little short-sighted on his part.

I think that a few basic Ada "marketing" messages need to go out: 

  (1) the compiler size for Ada is no longer a problem. 
  (2) the compiler (GNAT) is available, and free.
  (3) Ada (95) is not obsolete, and supports OOP

Perhaps (2) will be an easier sell, once it is rolled in with gcc. Having
it already installed with new distributions will help it's cause greatly,
IMHO.

> > > I counter case, usually used by Ada disgusters is the famous ESA Arianne
> > > rocket, although programmed in Ada it made a very expensive piece of
> > > hardware burn (literally!) due an error in design, notwitstanding the
> > > supposed high quality language (and btw process) to build the softaware.
> >
> > You can never eliminate human error or stupidity completely. I am sure many
> > here on this news group could site "stupid Ada tricks" that are not the
> > fault of the language or its tools, but of those USING the "tool". Kinda
> > like the apprentice mechanic that uses a caliper as a C-clamp.
> >
> > Your example is more the design/human-error type, which again, is not
> > completely avoidable. At least you can say that Ada did exactly as it
> > was told to do, when it burned it's hardware!  What more can you ask
> > of a computer?
> 
> Again we are stuck with the "mental image". Ada "did not avoid" and it
> is harder to learn, etc. (I'm not advocating this, please!). OTOH, Meyer
> started to canvass the community about a new programming paradigm
> ("programming by contract") and it brand new language that supports this
> (Eiffel), which again takes the focus out of Ada.

I will agree that stepping into Ada, is not trivial (the basics are simple,
but there is a lot of familiarization required for the various Ada 
packages etc.)  There needs to be a new class of Ada95 books that take
the reader BEYOND the language and look at Ada95, using UNIX, and step
the reader through such issues as using Streams and other Ada specific
solutions.

I found the language easy enough to pick up. What wasn't found in existing
literature was the answers to such questions as:

   How do I read in structures from a file?
   How do I structure my project? My Makefile?
   How do I use shared libraries with GNAT?
   How should a main program be formed?
   How should I process command line arguments?
   How should I interface with various UNIX facilities? errno? signals?
   String handling (this is never adequately covered)

These are just a few. When the beginner goes to write a new Ada95
app, he knows how to do the basic language things. However, the
environment is very foreign to a UNIX/C type, and this is where all
of the literature I have seen, is found wanting.

> In a nutshell, I partially agree that to regain momentum (out of some
> academic circles and specific niche markets). We need to get some
> projects public interest and get them a feel of the advantages of "our"
> programming environment.
> 
> The idea of games seems interesting, an OS seems to me too far fetching
> (let alone FSF struggling to finish their GNU OS, a small community of
> Ada programmers would be faster?).

An OS, with its problems with getting driver support etc. is very ambitious.
For me, AdaOS is a wish list item, but I agree, that seeing it
completed doesn't seem likely, unless Ada participants should
suddenly rise.

> Other things we could try is to go
> the FSF "todo/wishlist" and look for some production software FSF needs,
> some of them although not as exciting as games or rocket control, are
> still software engineering respectable projects, and if they catch the
> user audience they rather be stable/robust. Two which I recall were
> office related includind a general ledger program. I wonder if a Free
> version of an ERP package wouldn't be more worth investing than a
> competing OS.
> Cesar (PY2CSH)

Because of concern about Internet security, I'd like to replace 
servers with ones written in Ada95, if time ever permits. Some 
immediate examples come to mind:

  - A better Linux DHCP client program (the C version I have installed
    is very problematic, and probably exploitable).
  - A replacement for DNS (Bind) in Ada95, possibly including
  - optional DHCP server (with dynamic DNS update)

OTOH, there are so many more interesting things to do... sigh.. like
applications that allow your host to do useful work for you. ;-)

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg