From: BrianG on
Nasser M. Abbasi wrote:
> On 6/20/2010 5:29 PM, Ludovic Brenta wrote:
>
>> Show them that no, C is not "good enough".
>>
>
> This is what I said earlier. show them, but with small clear code
> examples, side-by-side, Ada vs. C, show why in each example, Ada is
> better.
>
As others have said, larger examples are better for showing the
advantages of Ada. However, this may make for a less practical
demonstration. In this case, another way is to use examples from your
(the OP's) actual code. Show areas that have been the source of
problems, and how Ada could avoid those problems.

More generally, I would (in an ideal world) look at the problems that
occur in the entire development process and what changes would avoid them.

> Making lectures to C programmer about how much better Ada is in the
> abstract, will not work, it will sound like a politician making a
> typical speech about how good a job they will do if elected.
>
> btw, if someone is really good in C, and very careful, and stick to the
> standard, they can produce solid code.
>
> Many large applications are written in C all the time, the problem I
> think, is that it takes more skill and effort to produce as reliable
> code in C as with Ada, but it can be done, given more effort, skill,
> time and money, and lots of coffee.
>
Coffee? Coffee? I thought "real coders" always relied on Mt.Dew, or
Jolt. Or today maybe Red Bull, etc. :-)

The other problem is that the time is usually spent at the tail end of
development (testing) rather than at the front end.

> --Nasser
>
>
--Bg
From: Maciej Sobczak on
On 23 Cze, 21:57, "Peter C. Chapin" <pcc482...(a)gmail.com> wrote:

> My understanding is that Ada is primarily a "systems" programming language. It
> supports embedded programming, real time programming, and other "low level"
> applications. People writing such programs are not particularly concerned
> about GUI packages. Well... I can't speak for everyone, but I'm using Ada in
> an embedded application and I'm certainly not worried about the lack of GUI
> support.

The reason for why GUI is not (and will not be) in the Ada standard
library is the same as in C++ - there are too many ways to do it and
the cost of prototyping is too high to attract attention of
individuals who are usually *volunteers* in standardization efforts.
Especially when the already acceptable solution is to live with
existing third-party library or libraries.

> I wasn't involved in the discussion that lead to the decision to include
> conditional expressions in Ada

Again similarity to C++ - conditional expressions are *essential* for
initializing constants. Without them programmers are forced to either
use modifiable variables where constants would be more natural (this
is unsafe) or to write local or helper functions, which destroys the
locality of reference for code entities (this is less readable ->
unsafe).

I'm glad that Ada is going to adopt them.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4
From: anon on
In <9b5af9c0-43a3-4a9d-9a03-5b6c794f611e(a)e5g2000yqn.googlegroups.com>, Maciej Sobczak <see.my.homepage(a)gmail.com> writes:
>On 23 Cze, 21:57, "Peter C. Chapin" <pcc482...(a)gmail.com> wrote:
>
>> My understanding is that Ada is primarily a "systems" programming language. It
>> supports embedded programming, real time programming, and other "low level"
>> applications. People writing such programs are not particularly concerned
>> about GUI packages. Well... I can't speak for everyone, but I'm using Ada in
>> an embedded application and I'm certainly not worried about the lack of GUI
>> support.
>
>The reason for why GUI is not (and will not be) in the Ada standard
>library is the same as in C++ - there are too many ways to do it and
>the cost of prototyping is too high to attract attention of
>individuals who are usually *volunteers* in standardization efforts.
>Especially when the already acceptable solution is to live with
>existing third-party library or libraries.
>
>> I wasn't involved in the discussion that lead to the decision to include
>> conditional expressions in Ada
>
>Again similarity to C++ - conditional expressions are *essential* for
>initializing constants. Without them programmers are forced to either
>use modifiable variables where constants would be more natural (this
>is unsafe) or to write local or helper functions, which destroys the
>locality of reference for code entities (this is less readable ->
>unsafe).
>
>I'm glad that Ada is going to adopt them.
>
>--
>Maciej Sobczak * http://www.inspirel.com
>
>YAMI4 - Messaging Solution for Distributed Systems
>http://www.inspirel.com/yami4

Now, except for "GNAT.Sockets.*" and the outdate "pragma No_Rum_Time"
GNAT has side-step the following design concept.

"The language must also be "complete" in the sense of the user being
able to write all usual programs without having to resort to assembly
language or local extensions. It had to have real-time capability and
it had to be set up to produce programs for the bare machine in a
missile, without support of an operating system. It also was required
to support large Command and Control systems, so it had to have a
file input/output system, however messy that might be."


This paragraph suggest that they should be packages under Ada.* or
System.* that would control the hardware such as the Serial (both UART
and USB), parallel ports. And all connection types (bus, serial, usb,
and parallel, etc) for the keyboard and mouse devices. Plus, it should
have routine to control network cards and other standard I/O, such as
direct video control and disk while bypassing the OS. But no Ada 83
system every used the RM defined Low_Level_IO package. And in Ada 95
and Ada 2005 there is no packages that are defined in the RM that
control any group of hardware directly, bare machine or not. The Ada
package mostly just linked to a precompiled library (aka local
extensions) that connected to the OS. So, where are these packages?


Note: Allowing Ada to be written without using "Local Extension" can
mean that Ada needs a "Universal Windows/Graphics" package
groups that in one version links to the OS, as well as
having another directly control the graphics of a group of
common GPU cards. Where is the package or packages, without
the programmer using assembly language or the Machine_Code
package?


Plus, the file system in some case needs to be self-contained without
the OS. So where are the System.File_System.* packages like fat, ext2,
ext3, etc. ? Or may be a generic package for creating file systems.

From: anon on
In <wcc63198mdn.fsf(a)shell01.TheWorld.com>, Robert A Duff <bobduff(a)shell01.TheWorld.com> writes:
>"Peter C. Chapin" <pcc482719(a)gmail.com> writes:
>
>> I wasn't involved in the discussion that lead to the decision to include
>> conditional expressions in Ada, but my impression is that they were
>> introduced in large measure to make the new pre- and post-conditions more
>> expressive.
>
>Yes, that's a big part of the reason. One use for them is to express
>logical implication. ARG considered, and rejected, the idea of
>adding an "implies" operator. Instead, you can say something like:
>
> procedure P (...) with
> Pre => (if X > 10 then Y > 10);
>
>The "else True" is implied here. So it means the same
>as what "X > 10 implies Y > 10" would mean if "implies"
>were in the language.
>
>This is not (yet) Ada! It is proposed for Ada 2012.
>
>> In any case conditional expressions are entirely normal in functional
>> languages and widely implemented by such languages. They are not some sort of
>> C quirk as you seem to suggest. I'm not suggesting that Ada should become a
>> functional language (lambdas, anyone?) but to a person fluent with functional
>> programming such expressions are very natural.
>
>Lambdas should indeed be added to Ada, IMHO, and they have been
>discussed by ARG. I forget the status, but I don't think they'll
>make it in. We had a lot of trouble coming up with a readable
>syntax, for one thing. (And nobody proposed any syntax involving
>a "lambda" keyword.)
>
>But to be a true functional language Ada would need more than that.
>Full closures, for example. And those pretty much require
>garbage collection.
>
>- Bob
From a Read Only web site:

"Ada - The Project The DoD High Order Language Working Group"
William A. Whitaker, Colonel USAF, Retired
PO Box 3036, McLean VA 22103

Typo in the quoted work come from the document.


"Without exception, the following languages were found by the
evaluators to be inappropriate to serve as base languages for a
development of the common language: FORTRAN, COBOL, TACPOL, CMS-2,
JOVIAL J-73, JOVIAL J-3B, SIMULA 67, ALGOL 60, and CORAL 66."


That statement alone shows that Algol had no influence on the design
of common language (later named Ada).

Later in the paper it states a reason for Algol's dismissal:

"There were other common language meta-requirements. For example,
the language must be an applications user language. This went
against certain academic concepts of a mathematically minimalistic
formulation, like ALGOL 68."

Since, the designers were against mathematically minimalistic formulation,
this suggest that "Lambda" might need to be classified as forbidden
fruit as well. Sorry, Robert Duff. But then again "Lambda" might be
able to find itself as a separate set of math packages. Especially,
if you created the blueprint for Adacore's GNAT. Because it seams like
anything that GNAT adds to its design is adopted by the language.


Later the "Base" language of the Ada came from the four languages. But
since the DoD had a long-term commitment for Fortran and Cobol, the set
became:

"FORTRAN was significant because that was the successful language -
we are still apologizing for FORTRAN features not in Ada
(intrinsic math functions (e.g., SQRT, SIN, etc.),
interpretive I/O (i.e., with dynamic formatting)), no
matter how proper the exclusion;

COBOL pioneered validation - made sure we did not allow the
subsets that in 1976 made COBOL systems difficult to
validate and compare (may be right for COBOL but not
for the purposes of Ada) - data handling, and readability;

JOVIAL and
CORAL were languages of major military users whose
experiences made considerable contribution to the
requirements;

Pascal contributed mostly its syntactic form."


Algol did not make the cut!


Now, except for "GNAT.Sockets.*" and the outdate "pragma No_Rum_Time"
GNAT has side-step the following design concept.

"The language must also be "complete" in the sense of the user being
able to write all usual programs without having to resort to assembly
language or local extensions. It had to have real-time capability and
it had to be set up to produce programs for the bare machine in a
missile, without support of an operating system. It also was required
to support large Command and Control systems, so it had to have a
file input/output system, however messy that might be."


This paragraph suggest that they should be packages under Ada.* or
System.* that would control the hardware such as the Serial (both UART
and USB), parallel ports. And all connection types (bus, serial, usb,
and parallel, etc) for the keyboard and mouse devices. Plus, it should
have routine to control network cards and other standard I/O, such as
direct video control and disk while bypassing the OS. But no Ada 83
system every used the RM defined Low_Level_IO package. And in Ada 95
and Ada 2005 there is no packages that are defined in the RM that
control any group of hardware directly, bare machine or not. The Ada
package mostly just linked to a precompiled library (aka local
extensions) that connected to the OS. So, where are these packages?


Note: Allowing Ada to be written without using "Local Extension" can
mean that Ada needs a "Universal Windows/Graphics" package
groups that in one version links to the OS, as well as
having another directly control the graphics of a group of
common GPU cards. Where is the package or packages, without
the programmer using assembly language or the Machine_Code
package.


Plus, the file system in some case needs to be self-contained without
the OS. So where are the System.File_System.* packages like fat, ext2,
ext3, etc. ? Or may be a generic package for creating file systems.

We needs there package before adding any type of C-Like conditional
operators.


Now what did the DoD and the Ada creating teams think of C.

"Since the developed systems were to be long-lived, maintenance
and modification of the software would cost several times as
much as initial development. Readability was much more important
than writability, a requirement contrary to those advocating the
"economy of expression" that leads to incomprehensible C and APL
code. Maintainability also argued for rigid interfaces and
powerful compiler checking."

Being that the team thought C leads to incomprehensible coding. This
also include the C-like "Conditional operators"! Like :

C:
Variable := <logical expression> ? <true value> : <false value>

Ada:
Variable := <logical expression> then <true value> else <false value>


As for "powerful compiler checking", GNAT sometimes overdoes the checking
even when the programmer turns off all checking. That is, just try to
use the statement like "Z := X / 0;" the GNAT compiler will never allow
that statement, even if one disable all checking, exceptions and
exceptions handlers, the compiler will still block this statement by
inserting exception coding at that point. A friend spent a month last
year talking to Adacore on this one.

As for "rigid interfaces" GNAT could use a few adjustments, like making
sure an item can not be altered if the address to that item is passed as
an "in" only parameter. like access referenced variables. Example:

type String_Record;
type String_Access is access all String_Record;
type String_Pointer is access all String;

type String_Record id record
Index : Natural; -- 0 = empty string
Value : String_Pointer;
end record ;

A : Character ;
Buffer : String_Access ;

function Get ( B : in String_Access ) returns Character ;

-- The compiler should make sure that this function
-- does not directly alter the "Index" or "Value" in
-- the record "String_Record" referenced by Buffer,
-- if this routine is written in Ada.
...
A := Get ( Buffer ) ;

From: Maciej Sobczak on
On 24 Cze, 19:24, a...(a)att.net wrote:

>     "The language must also be "complete" in the sense of the user being
>     able to write all usual programs without having to resort to assembly
>     language or local extensions.

You are confusing "local extensions" with "third party libraries".

Local extensions are things like 'Img.
Third party libraries are things like QtAda (or YAMI4, for that
matter).

That is, there is no reason to expect standard authors to define
packages for all possible language uses or all possible ways for
creating external program interfaces. For example, I don't think that
standard Ada.iPad package would make sense at all.

> Note:  Allowing Ada to be written without using "Local Extension" can
>        mean that Ada needs a "Universal Windows/Graphics" package
>        groups

Well, no. Your conclusions are completely wrong.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4