What is wrong with Ada? - Programming Languages

Pascal Obry writes:[color=blue]
> Thanks for your answers. But I was more thinking about being two people
> on a project not necessary two behind the screen at the same time. Code
> review can be done at any time with the right setup (sending mails for
> each check-in for example) it is possible to make code review as
> something "normal". Many developers seems to not like somebody looking
> at their code, if every piece of code is sent to a dev mailing-list it
> changes things, making code more visible by default.
>
> I do think that a single developer on a project is bad for the overall
> quality... I'm just looking for so data to backup this idea
>
> Well this has nothing to do with Ada, so I'm completely off topic, fell
> free to ignore [/color]

I agree wholeheartedly. A few years ago, I would start each day
reviewing my teammates' commits in the version control system, and I
also encouraged them to do likewise. We caught many latent or actual
bugs even before testing that way. Furthermore, it allowed us to know
the entire source base intimately, even on those parts we weren't
directly involved in.

Now I work in avionics and we have formal code reviews instead. They
tend to take place after everything is written, and I miss the
closed-loop feedback I had with daily reviews.

--
Ludovic Brenta.

Pascal Obry wrote:[color=blue]
>
> Many developers seems to not like somebody looking
> at their code[/color]

That's called investing one's ego in one's code. It's a bad sign. People
who feel strongly that others should not look at their code should not
be working on your projects.

--
Jeff Carter
"Sir Lancelot saves Sir Gallahad from almost certain temptation."
Monty Python & the Holy Grail
69

"Jeffrey R. Carter" <jrcarter@acm.org> writes:
[color=blue]
> Pascal Obry wrote:[color=green]
>>
>> Many developers seems to not like somebody looking
>> at their code[/color]
>
> That's called investing one's ego in one's code. It's a bad
> sign. People who feel strongly that others should not look at their
> code should not be working on your projects.[/color]

Strange; I invest a lot of ego in my code, and I insist that others
read it

--
Ludovic Brenta.

"Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>
wrote in message news:awirc4gv13.fsf@hod.lan.m-e-leypold.de...[color=blue]
>
> I think I already answered that. Still, on c.l.a, the myth persists
> that "developers like unsafe languages". In actual reality it's the
> other way round:
>[/color]
Unsafe languages like developers?[color=blue]
>
> For one reason or other -- as I explained often
> enough, not related to technical merits of the languages in question
> -- people like other languages, they just happen to be "unsafe".
>[/color]
Sort of the way most people are addicted to junk food and would
rather eat something full of fat and sugar than eat their broccoli.

For example, C++ is like the peanut brittle of programming languages.
It might taste sweet, at first. But then it gets stuck in your teeth. Finally,
it begins to rot your code unless you brush away the residue.
[color=blue]
> (And even that might be questioned, since the big contenders at large
> are (probably in that order) Excel, Php, Perl, Python and not only C
> ... -- Excel and the 3 Ps are not unsafe in the same sense as C/C++
> are).
>[/color]
I happen to like Python and I'm using more often now than Ada, for
non-critical code. It is quick and easy. However, I would never think
of using it for safety-critical software. C is an important tool for some
kinds of problems, but it, along with its deformed cousin, is like a box
of "strike anywhere" matches, and needs to be used with great care.

Even Ada needs to be used with care. Even SPARK needs to be used
with care. There is no perfect programming language, at present. While
Ada is better than most, when safety is a consideration, it too has its
weaknesses. We should be striving for a language design that includes
the best of Ada's design, while avoiding the worst of C++, and moving
along toward the next generation of programming languages. These
languages, by-the-way, are not Ruby and the like. They might be
closer to Eiffel, but with a better compilation structure.[color=blue]
>[/color]
In any case, we should not be surprised when we use tools (languages)
that are inherently error-prone and get results that are error-dense. When
someone remarks that the debugger is not necessary in Ada, they are
acknowledging that, well-designed Ada code will not have as many of
the idiotic kinds of errors one finds in C++ code. However, none of us
is such a good programmer that we don't find it occasionally useful to
have a debugger to help locate the errors that result from our own stupidity.

Richard Riehle

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message
news:82dgve.spf.ln@hunter.axlog.fr...[color=blue][color=green]
>>[/color]
> Sorry, but I beg to disagree here. Conceptual bugs are found by reasonning on
> the source, not with a debugger. Every now and then you may need to check the
> value of a variable at some point in execution to validate or invalidate an
> hypothesis, but even there, I find a proper trace message much faster and more
> precise than using a debugger.
> --[/color]
I almost always agree with Jean-Pierre. However, I do recall a project
in Ada written for a MIL-STD 1750A where the debugger was an
integral part of the verification (inspection) process. Some may recall
the HP 65000 tool that was so useful in tracing, step by step, the execution
of a program while simultaneously presenting a human-readable version
of the underlying executable code.

This is an extreme example, and the criticality of the application was such
that this level of inspection was required for inspection. It was certainly
tedious, would be unnecessary in most applications, but was probably
the correct decision in this situation. And, "No" I would not recommend
this approach to anyone for most software systems -- unless they are looking
for a guaranteed cure for insomnia.

Richard Riehle

<adaworks@sbcglobal.net> writes:
[color=blue]
> "Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>
> wrote in message news:awirc4gv13.fsf@hod.lan.m-e-leypold.de...[color=green]
>>
>> I think I already answered that. Still, on c.l.a, the myth persists
>> that "developers like unsafe languages". In actual reality it's the
>> other way round:
>>[/color]
> Unsafe languages like developers?[color=green]
>>
>> For one reason or other -- as I explained often
>> enough, not related to technical merits of the languages in question
>> -- people like other languages, they just happen to be "unsafe".
>>[/color]
> Sort of the way most people are addicted to junk food and would
> rather eat something full of fat and sugar than eat their broccoli.[/color]

<...>
[color=blue]
> I happen to like Python and I'm using more often now than Ada, for
> non-critical code. It is quick and easy. However, I would never think[/color]

So perhaps most of the people don't write safety-critical software?
And there is, consider, more than one kind of safety ...

Regards -- Markus

"Pascal Obry" <pascal@obry.net> wrote in message
news:461E6DD9.6010600@obry.net...[color=blue]
>
> "The only way" for interpreted languages, for compiled languages (as
> said in my previous message) the compiler will detect lot of mistakes.
> So it is not the only way in this case. I'm wondering if you are not
> moving to the troll side!
>[/color]
Every program needs to be evaluated in more than one way. Those
who advocate test-only are off the mark. Those who depend on a
properly compiled program are way off the mark. Those who rely
on inspection alone, are certainly missing something.

Ideally, we design the software with the most appropriate methods and
tools to avoid defects. For most circumstances, but not all, Ada is a
better tool to accomplish this than most other languages. We can
certainly get better results in this regard from Ada than from an intepreted
language, but that is the old "mixing apples and oranges" issue. When
comparing Ada, we must compare it to languages that are also compiled.
C++, a language inherently error-prone, is not usually as good as Ada
(with a few very rare exceptions), so we don't expect to be able to
depend on the compiler for as much help as we get from Ada. This is
also true, to some extent, for Java.

Even so, with all the help we get from the compiler in a well-designed Ada
program, we must also apply some testing regimen and are well-advised to
add an inspection process. However, it is well-known that neither testing
nor inspection are sufficient for evaluating the correctness of a program. This
is why compiler errors are still important. Once again, Ada excels in this
regard for most kinds of design problems.

Some of the examples given, so far, such as the double underbar indicate
a lack of understanding of just what a harsh mistress really is. The
fundamental
design goal of Ada is for a language where the maximum number of errors
can be detected by the compiler as early in the development process as
possible. For the most part, in most circumstances, this actually happens.

Full-path, and total testing are simply out of the question for large software
systems. Therefore, we need to find ways to priortize the testing process
so we focus on those errors with the greatest probability of occurrence as
well as those with the greatest serverity, should they occur. A testing
strategy needs to be coupled with a risk management policy. Risk
management, to be truly effective, needs to be based on recorded experience
of the kinds of defects typical of a domain, an organization, etc. With some
knowledge of the frequency distribution of errors, we can then develop a
sensible testing strategy. For example, if we know that a certain programmer
always makes mistakes of a certain kind, we can focus more testing on his
programs. If we know that a certain category of mistakes occurs at a
given stage of projects of the kind we are developing, we can create a
strategy for evaluating software at that stage.

Strategies for testing are important since there is no way to test all the paths
of any program. Design strategies that take advantage of the error reporting
from a compiler are important so we will not have to test those errors that
are reported. Inspection strategies are essential for identifying the kind of
errors that are most easily spotted by a well-trained human. All of these
are important, even when using Ada.

Richard Riehle

"Ed Falis" <falis@verizon.net> wrote in message
news:PM00042E503F06FEA3@tilopa.unknown.dom...[color=blue]
>
> I don't know about studies, but the XP people have plenty of anecdotal
> evidence about the effectiveness of "pair programming" as a lightweight
> form of code review.
>[/color]
I recall a real-time, non-stop, program that sometimes needed to be
fixed at odd hours of the night. The rule was that no patch was allowed
to be entered into the program unless there were at least two programmers
working on it at the same time and both agreeing that it was OK.

Two, of course, is not a really good number. We can learn some lessons
from the Byzantine General's Problem, I suppose.

Richard Riehle

"Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>
wrote in message[color=blue]
>
> So perhaps most of the people don't write safety-critical software?
> And there is, consider, more than one kind of safety ...
>[/color]
Granted. I am not a one-language person. It is always a matter
of choosing the right tool for the right job.

I was once asked by a three-star general whether he should be
converting all his Fortran code to Ada, as many on his staff wanted
to do. I gave him my opinion as, "No." Old code that has worked
a long time is almost always better than new code that has not yet
proven itself in the field, regardless of what language is used.

In his environment, there were a lot of programs that needed to be
written other than translating the Fortran. It seemed to me that those
who wanted to translate Fortran were simply avoiding the new problems
that were waiting to be solved, and that could best be solved in Ada.

A large bank was persuaded to do a bunch of projects in Java. It was
a stupid decision, and that soon became apparent. All the other code
in the bank was in COBOL. My advice. Instead of using Java or
C++, or even Ada, train the programmers to use Object-oriented
COBOL. Java is a terrible choice for business data processing where
there is a lot of accounting activity. C++ is probably worse. Ada
could work because of the built-in accounting-oriented data types,
but that would also a wrong choice for this environment.

We live in a multi-language world. Perhaps it would be better if we
didn't. However, there does not exist, at present, any single language
that is superior for every kind of programming problem in every context.
One thing I like about Ada that is not as well-formed in other languages
is the Annex C, Interfacing to Other Languages facility. Ada is more
hospitable to other programming languages than most of the alternatives.

Richard Riehle