Anyone out there using Ada ?

If you don't get much back on this group the comp.lang.ada people should be happy to give you their experiences. I'd like the chance to use Ada in an embedded project - the tasking is really appealing, among other attractions. Maybe someday when C and associated languages are finally outlawed by enlightened societies as the hazards to life and limb that they are... :)

In message , John McCabe writes

It's a trap... when you identify yourselves they are going to come around and forcibly convert you to the One True Language of FORTH!!! :-)))))

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

The use of C on safety related projects is increasing whist the use of Ada is decreasing.

However, it is the process that is more important than the language.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

I know, and IMO that's a sign that the inmates are running the asylum. Or, to quote one author

1999b.pdf)

"The 1980s will probably be remembered as the decade in which programmers took a gigantic step backwards by switching from secure Pascal-like languages to insecure C-like languages. I have no rational explanation for this trend."

As for process vs. language, it's not an either-or situation. Use the right process AND the right language.

Mike

My impression it that that the number of projects with an interest in safety and/or security is increasing. Both Ada and C are used, and there seems to be recently increasing interest in Ada, reversing the trend of the last decade. The thing the holds Ada back in the low-end microcontroller space (e.g. PIC, AVR, MIPS, etc) is the lack of readily available cross-compilers for these targets. This is absolutely not due to any technical aspects of the language but just reflects the market factors of the last several years.

Ada can be (and is) used without a "runtime", or with a minimal runtime, depending on what the application requires.

Process is more important than language, but choosing a better language makes it much easier to implement and adhere to a safety/ security focused process.

- Britt

Thanks for that, but I keep an eye on that group anyway.

LOL!!

I'm using C++ at the moment - it's not that I don't like it or anything like that, but I'm sure the system I'm working on would be much better in terms of reliability and maintainability if it was in Ada!

Rubbish - the one true language was occam-2!!

In message , John McCabe writes

Only if you are running it on Transputers.

BTW the new thing is multi core and parallisum..... Maybe Occam's time has come?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

And?

No I'm not going to do that, despite having several clients who ship safety critical apps written in Forth, and despite having tools to generate FDA (the US Food and Drug Administration) quality documentation directly from Forth source code, and ...

As people have said elsewhere, the process really matters more than the programming language.

Actually, I believe that the single thing that will improve code most is to teach people *how* to debug. The process is just formal scientific method. The second most inportant change is to fix bugs before you do anything else. The third is probably to use something like literate programming as part of writing the code - it has greatly improved our code quality, and almost always reveals bugs when we add it to incoming third-party code.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

Have you seen any hardware device drivers in Pascal, before or after

1980?

Yes. Using Ada and yes using MIPS.

No - Ada handles that very nicely indeed. Better than any other major language, in fact, and MUCH better than occam could possibly do.

--
Bill Findlay
 chez blueyonder.co.uk

How many programmers need to write device drivers?

But, as it happens, yes, I have. In fact, I wrote some (around 1974).

BTW, the quote says "Pascal-like", which includes Ada (now Ada 2005), in which writing close-to-hardware code is a snap.

--
Bill Findlay
 chez blueyonder.co.uk

There is a port of GNAT to the AVR platform, but it's a community driven, instead of ACT driven, port.

Note that when I last looked at it, I came to the conclusion that I wasn't yet quite comfortable using it on a project that I was working on, as I wanted to see it have a bit more of a development history before using it on this particular project.

I don't have any information on what functionality it has these days.

See here for the port:

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world

I have built GNAT to compile for MIPS also, but no runtime - this was for base hardware access on SGI machines. Did you port the runtime?

Thanks, Luke.

Are you just pointing out that C is the language of choice for device drivers? I won't argue with you about that. But if you're suggesting other languages aren't suitable, or couldn't be made suitable, that isn't true at all. C hit a sweet spot, no question about that. But it's not irreplaceable.

Ada's and SPARK's support for the overall process is exactly why Sutton and Middleton recommend these languages in their book "Lean Software Development". They don't consider the languages' technical merits, though substantial, as important as their contributions at the very different level of process support.

Technically, anytime we write code for a micro and don't include some type of supporting OS, we HAVE to write "device drivers" for all the hardware we use. Like UARTs, I2C, SPI, and so on. Many of us have built up a library of standard routines that we use on particular processors, but we had to write the original code, none the less.

Jim

Teaching people to avoid writing buggy code in the first place is more important. But hell, that contention goes back to Fred Brooks in the

60's. Too much time is spent in the debugger, and too much emphasis is put on it. Thinking is the best way to travel.