How come Ada isn't more popular?
artifa...@googlemail.com
I am a long time C programmer (10 years plus), having a look
at Ada for the first time. From my (inadequate) testing, it seems
that performance of average Ada code is on par with average
C code, and there's a clear advantage in runtime safety. The
GNU ada compiler makes pretty sure that there are very few
platforms without easy access to Ada, so portability should be
on at least an equal footing too.
My question is: how come Ada isn't more popular?
This isn't intended to start a flame war, I'm genuinely interested.
thanks,
MC
adaw...@sbcglobal.net
<artifa...@googlemail.com> wrote in message
news:1169531612.2...@38g2000cwa.googlegroups.com...
>
> My question is: how come Ada isn't more popular?
>
things. One is that the designers of the language did not anticipate
the impact of the personal computer and the democratization of
computing. There were other factors, as well.
1) The DoD mandated Ada before there were any good compilers
or development environments in place. That began a routine
practice of rubber-stamping waivers to use other languages.
2) The compiler publishers, having a captive audience, inflated the
price of compilers and tools, making Ada unattractive for anyone
in the non-DoD world. For example, Alsys sold a compiler for
the personal computer at $4000 per copy thereby putting out
of the range of most companies and every hobbyist.
Turbo Pascal and other alternatives were already in place and
much cheaper than Ada. A few brave souls tried to compete
with products such as RR Software's Janus Ada and Meridian's
AdaVantage, but the full environment (e.g., integrated editors,
debuggers, etc.) were not in place they were for Turbo Pascal.
3) Inept DoD management of the Ada initiative. Sometimes it seemed
that the DoD was trying to make Ada a bad choice for businesses.
The public line was that they wanted commercial users, but the
practices often put barriers in the way.
4) Other languages were cheaper to acquire, cheaper to use, and had
no copyight associated with them. The copyright was eventually
removed, but late.
5) The earliest compilers were not uniformly good. I recall the mainframe
compiler from Telesoft was, when compared to other language choices,
simply terrible. It was slow, had an awkward development environment,
and did not support the central features of the mainframe very well.
Many of those early compilers were "checkbox" compilers. On the form
where one had to check-off "Validated Ada Compiler" the fact that a
validated
compiler was available was considered enough. One compiler I recall quite
vividly was for the Tandem. Although the compiler was validated, that same
compiler was not integrated into the rest of the system tools, and barely
supported by the operating system. The word in the Tandem management
was that no one was expected to take Ada seriously, but the checkbox had
to be supported. This was quite widespread in the industry.
6) Really good compilers began to appear around 1989. By then Ada's reputation
for being slow, cumbersome, and hard to use had already been firmly set.
7) Instruction in the language was bad. I recall a U.S. Navy Admiral
complaining
about how hard it was to teach anyone Ada. He described the efforts he put
in place to make this happen. I told him he had hired people to do the
teaching
who were incompetent. That was true, but they had PhD's and he thought
that
should have ensured success. The fact was that those teachers had not yet
come
to a full understanding of the Ada and their own confusion was more a source
of
obfuscation than enlightenment for the students.
8) Grabbing defeat from the jaws of victory. In the mid-90's, when Ada became
a powerful alternative to other languages, when tools were in place, the
language
modernized, and the availability of low-cost (or free) compilers could have
made
it attractive, the DoD lost its nerve and gave the impression that Ada was
no longer
part of the DoD language requirement. A lot of people misinterpreted this
and thought
the DoD had decided to abandon Ada entirely.
9) Traitors. Some people who were previously charged with promoting Ada, in
particular certain former AJPO officials, once having left government,
exploited
their former role and joined the forces against Ada. They were able to
use their
title as former ... to gain credibility and lobby against the use of Ada in
exactly
the places where it was appropriate to lobby for it.
Ada is not now, nor has it ever been, the perfect language. There is no perfect
language. However, anyone who understands Ada and has a good understanding
of the competing technologies realizes that Ada continues to be the most
appropriate
choice when the requirement is for a language that will improve the probability
of
an error-free software product at a reasonable cost. The alternatives, mostly C
and C++ are generally less dependable. In fact, I often wonder why anyone would
pick a language that is inherently error-prone (e.g., C++) and expect a result
that
is error-free.
If one does an objective comparison of Ada to its alternatives, in the design
and
constuction of dependable software, Ada will come in with high marks -- higher
than most alternatives. If one is looking for a language that is well-suited
to
supporting a long-lived software system, Ada is certainly better than most of
the alternatives.
More could be said in favor of Ada. I will leave that more to others.
Richard Riehle
artifa...@googlemail.com
a killer.
Thanks for the impromptu documentary.
MC
Grein, Christoph (Fa. ESG)
This has been asked several times, and I think you'll get many opinions.
There are historical reasons, but by now, they are no longer relevant.
In effect, there is no real reason why she isn't more popular - I
personally cannot understand this. Most of the arguments you hear
against Ada are in fact made up - people just don't want to use her,
they're happy with whatever they're using.
Mind you, I do not argue that there are strong reasons why some project
does not use Ada - we're talking popularity here.
Stephen Leake
> I am a long time C programmer (10 years plus), having a look
> at Ada for the first time. From my (inadequate) testing, it seems
> that performance of average Ada code is on par with average
> C code, and there's a clear advantage in runtime safety. The
> GNU ada compiler makes pretty sure that there are very few
> platforms without easy access to Ada, so portability should be
> on at least an equal footing too.
>
> My question is: how come Ada isn't more popular?
Because most people don't have the same attitude towards language
evaluation that you do.
Most that I've actually asked have the attitude "C was what I learned
in college, and it's good enough for me".
Or, in managers, "everyone else is using C, so it must be the best
language". When I point out that far more programs are written in
Visual Basic, or Excel, they look very puzzled :).
Welcome to enlightenment :).
--
-- Stephe
Talulah
Grein, Christoph (Fa. ESG) wrote:
> Mind you, I do not argue that there are strong reasons why some project
> does not use Ada - we're talking popularity here.
Popularity is the key thing surely - the chicken and egg. As a software
manager in a commercial business, I employ C programmers because there
are so few Ada programmers around in the UK. There are so few Ada
programmers in the UK because I employ C programmers! How do you break
that chain?
There are many examples in marketing history of inferior products
becoming the more widespread, e.g. Betamax v VHS video recorders, MSDOS
v Concurrent CPM-86. I guess this is just another one of them.
Alex R. Mosteo
> Hello.
>
> I am a long time C programmer (10 years plus), having a look
> at Ada for the first time. From my (inadequate) testing, it seems
> that performance of average Ada code is on par with average
> C code, and there's a clear advantage in runtime safety. The
> GNU ada compiler makes pretty sure that there are very few
> platforms without easy access to Ada, so portability should be
> on at least an equal footing too.
>
> My question is: how come Ada isn't more popular?
Others have given longer scoped responses, and I will concentrate on the
hobbyist POV (I have felt an Ada hobbyist for a long time now): there is a
catch-22 problem with Ada and it is the lack of libraries. This is a
relative problem, consider these points.
1) The standard library is really standard, so this is an advantage if it
does all you need. Also some features (e.g. fixed point, bound checking,
tasking!) are in the language so you don't need extra wrappers around the
basic language or OS.
2) There's no good, easy, almost automatic C binding generator, although the
language has well defined mechanisms for C interfacing. Yes, there was some
generator. No, it is not trivial at present to get it running in my
experience. There's some effort to have Ada integrated into SWIG; this is
promising and IMHO an important selling point to newcomers.
3) There are bindings for quite some important things: Gtk+, Xml parser,
Unicode, CORBA, databases...
Summarizing, the Ada programmer feels a bit pariah when he sees his fellow
C/C++/java friends trying the latest and greatest version of some library.
Either it is unavailable for Ada, or is not up to date, or has to invest
some time in creating or tweaking a binding.
This is something that, as I said, may be important or not at some point,
depending on what you need to do. Also going against the majority of
colleagues is a burden. In my lab almost all development is done in matlab,
C or C++, and these are not all CS people but from other engineering
branches too. It's a shock when you have to use other's code and start to
see random pointers in function declarations, arcane syntax for complex
datatypes (because typedef seems a forbidden word) and so on. In my case,
Ada isn't event a obscure language: it is taught in my university and has
good backing among several high-profile teachers. Even so, I feel very
alone... :)
gautier...@hotmail.com
For libraries that are no more developped, like some compression or
image formats, an alternative is to get an Ada translation and not
needing a binding anymore (a problem with a binding is that you have to
provide it and keep it up-to date for each compiler/OS/CPU
architecture, and accept that the quality of the bound library
fluctuates with the time...).
If you are lucky, there is a Pascal translation around and you can go
further with P2Ada, it is much easier than translating from C which is
very different.
It is also a good occasion to seriously debug these libraries.
______________________________________________________________
Gautier -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm
NB: For a direct answer, e-mail address on the Web site!
Anders Wirzenius
> Grein, Christoph (Fa. ESG) wrote:
>
> > Mind you, I do not argue that there are strong reasons why some project
> > does not use Ada - we're talking popularity here.
>
> Popularity is the key thing surely - the chicken and egg. As a software
> manager in a commercial business, I employ C programmers because there
> are so few Ada programmers around in the UK. There are so few Ada
> programmers in the UK because I employ C programmers! How do you break
> that chain?
Quality is not free - short term.
Quality costs are traditionally split in:
- preventive costs
- inspection costs
- error costs, which are split in:
- external error costs
- internal error costs
Investing in Ada people belongs to the preventive quality
costs which hopefully are paid back at a later stage.
So, breaking the chain is a long term process which in the very
beginning does not produce much more than costs.
But in the long term ...
>
> There are many examples in marketing history of inferior products
> becoming the more widespread, e.g. Betamax v VHS video recorders, MSDOS
> v Concurrent CPM-86. I guess this is just another one of them.
I don't know what "this" refers to. :(
--
Anders
Arthur Evans Jr
<adaw...@sbcglobal.net> wrote:
> Ada suffered, in its early days, from a convergence of several
> things.
Richard Riehle wrote eloquently on this subject. I'll add one more point.
Ada came out at a time when the government in general and the defense
Department in particular were widely perceived as evil. Since Ada was
intended to be used to write programs that would kill people, some
perceived it as inherently evil. Many folks, myself included, made the
argument that wrenches are used to build weapons; should we ban
wrenches? Those who had already made up their minds couldn't or wouldn't
hear that argument.
This argument alone wasn't a major desideratum in Ada's failure to
become more popular, but then neither was any one of Richard's
arguments. All of these arguments taken together, though, were too much
at the critical time when Ada might have succeeded as intended.
Too bad.
Art Evans
Ed Falis
> Ada suffered, in its early days, from a convergence of several
> things.
It would make a fascinating book.
adaw...@sbcglobal.net
"Stephen Leake" <stephe...@stephe-leake.org> wrote in message
news:uy7nuc...@stephe-leake.org...
>
> Or, in managers, "everyone else is using C, so it must be the best
> language". When I point out that far more programs are written in
> Visual Basic, or Excel, they look very puzzled :).
>
company that has a history of grabbing defeat from the jaws of victory.
A team of developers at Xerox decided to use Ada for the software on
a new Xerox copier. The project was a resounding success and every
team member was enthusiastic about the potential for software on other
Xerox projects. There were analyses showing how Ada was more
cost-effective than C or other alternatives. It looked as if Ada might
have found its niche in commercial software development.
Not so. In spite of all the evidence in support of Ada, some idiot
higher up in management decreed that all software must be written
in C. He had no understanding of Ada. All he knew was that it
was a DoD language and he wanted no part of it.
This story has repeated itself over and over. As noted, a lot of people
are reluctant to use a language designed for "killing and maiming." It
is silly, of course, but programming aptitude has never been a good
predictor for sensible decision-making.
There is a shortage of Ada programmers, so Lockheed-Martin made
the decision to use C++ on some of our major weapon systems. Not
a particularly wide decision. They have discovered that, for the software
to be dependable, they must cripple C++ to the point where it is being
used as a "better C" and they have lost all the alleged benefits of C++
except one: the larger population of university-trained C++ programmers.
Academia has been no better. As long as the DoD funded projects related
to Ada, professors were happy to take the money. Once the funding vanished,
those professors redirected their efforts to projects using newer whiz-bang
languages that looked good when they submitted papers for publication.
I recently had the opportunity to teach a beginning class in Java. What I
discovered is that Java is not type safe, and includes a lot more opportunities
for programming errors than Ada. It is not any better designed than Ada,
but it does have a lot of libraries. Most important, it is easier to get a
paper
published if it mentions Java than if it mentions Ada. A few years ago I was
invited to submit a paper to a conference by the conference chairperson. I
was told not to mention Ada.
For a variety of reasons, there is a lot of ignorance and bias regarding Ada and
it will not be easy to overcome. One bright spot is that SPARK has achieved
a high level of respectability and SPARK is an Ada-based environment.
Richard Riehle
Tero Koskinen
On 22 Jan 2007 21:53:32 -0800 artifa...@googlemail.com wrote:
>
> My question is: how come Ada isn't more popular?
>
I would like to throw in yet another possible reason(*) for Ada being
not popular (within the free software folks).
Currently, the only non-restricted free Ada compiler is FSF GCC/GNAT.
However, the GCC development team doesn't consider Ada to be
a release critical language, so it gets less love whenever a new GCC
is released and its quality is sometimes lower than C and C++ parts
of GCC. In addition, Ada part of GCC supports far less platforms than
C and C++ parts. (**)
So, lets imagine that you are a lead developer in an open source
project (***). One of your goals is to produce software, which will
run atleast on following systems:
* Debian GNU/Linux 3.1: i386, IA-64, ARM, PowerPC, SPARC, MIPS
* OpenSUSE 10.2: i386, x86-64
* OpenBSD 4.0: i386, AMD64, ARM, PowerPC, SPARC
* FreeBSD 6.2: i386, AMD64, Alpha
The question is: Which programming language do you choose?
Ada is ruled out, because of its limited support for non-mainstream
free operating systems.
-Tero
(*) Actually, only a guess
(**) For example, platforms like OpenBSD/{arm,sparc,ppc,amd64} are
totally unsupported.
(***) Like KDE, Subversion, GTK+, or Sendmail
Jeffrey R. Carter
Much of what others have posted is good, but I also see:
Most developers (98% in my experience) are coders. Coders like languages
like C that let them code. Then then enjoy spending more time debugging
then they did coding.
The other 2% are SW engineers. They like languages like Ada.
Obviously, C and its ilk are going to be more popular than Ada.
Jeffrey R. Carter
>>
> Ada suffered, in its early days, from a convergence of several
> things. One is that the designers of the language did not anticipate
> the impact of the personal computer and the democratization of
> computing. There were other factors, as well.
An excellent reply. Ada was also ahead of its time. Computers in 1983
really weren't up to the demands of Ada.
> Turbo Pascal and other alternatives were already in place and
> much cheaper than Ada. A few brave souls tried to compete
> with products such as RR Software's Janus Ada and Meridian's
> AdaVantage, but the full environment (e.g., integrated editors,
> debuggers, etc.) were not in place they were for Turbo Pascal.
There's always the question of why, given TP's widespread popularity, C
became more popular.
> 6) Really good compilers began to appear around 1989. By then Ada's reputation
> for being slow, cumbersome, and hard to use had already been firmly set.
Actually, the DEC Ada compiler of 1984 was pretty good.
> 8) Grabbing defeat from the jaws of victory. In the mid-90's, when Ada became
> a powerful alternative to other languages, when tools were in place, the
> language
> modernized, and the availability of low-cost (or free) compilers could have
> made
> it attractive, the DoD lost its nerve and gave the impression that Ada was
> no longer
> part of the DoD language requirement. A lot of people misinterpreted this
> and thought
> the DoD had decided to abandon Ada entirely.
Windows 95 was the 1st widely used OS with support for tasking. Ada (95)
was the only widely available language with support for tasking at the
time. We probably lost a good opportunity to gain more acceptance of Ada
by not including a standard windowing library and promoting Ada as the
best language for taking advantage of Win95's features.
Jeffrey R. Carter
>
> Or, in managers, "everyone else is using C, so it must be the best
> language". When I point out that far more programs are written in
> Visual Basic, or Excel, they look very puzzled :).
More programming is done in COBOL than any other language.
Jeffrey R. Carter
>
> Ada came out at a time when the government in general and the defense
> Department in particular were widely perceived as evil. Since Ada was
> intended to be used to write programs that would kill people, some
> perceived it as inherently evil. Many folks, myself included, made the
> argument that wrenches are used to build weapons; should we ban
> wrenches? Those who had already made up their minds couldn't or wouldn't
> hear that argument.
These people never seemed to be very concerned about the DOD's
involvement in COBOL, either.
Jeffrey R. Carter
>
> Popularity is the key thing surely - the chicken and egg. As a software
> manager in a commercial business, I employ C programmers because there
> are so few Ada programmers around in the UK. There are so few Ada
> programmers in the UK because I employ C programmers! How do you break
> that chain?
No one should be hiring X programmers. For long term employees, you
should be looking for SW engineers, whom you then train if necessary.
Identifying SW engineers isn't easy, but one clue is that SW engineers
generally like Ada once they've been exposed to it.
This approach has long term cost savings, as Ada results in SW that is
ready for deployment sooner and has far fewer post-deployment errors
than SW in C. Your SW is ready before your competitors, and is higher
quality.
Plus, your employees, liking Ada, won't be leaving to do C for your
competitors.
Pascal Obry
> No one should be hiring X programmers. For long term employees, you
> should be looking for SW engineers, whom you then train if necessary.
> Identifying SW engineers isn't easy, but one clue is that SW engineers
> generally like Ada once they've been exposed to it.
How true! But sadly far from the common practice :(
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
Ludovic Brenta
> Ada part of GCC supports far less platforms than C and C++ parts.
Actually, I don't think that that's a result of Ada not being a
release-critical language for GCC. I rather think that that's a
result of too few people contributing to the Ada part of GCC, which is
itself a result of too few people using Ada. Chicken and egg,
catch-22. But that also applies to other software; for example
OpenBSD's ports collection is much smaller than Debian's or FreeBSD's;
why is that?
As a counter-example, Aurélien Jarno single-handedly ported GNAT to
GNU/kFreeBSD, which is hardly a mainstream platform. His patches,
initially available for several versions of GNAT, are now in the
Debian packages; you can review them if you like to get a feeling of
how hard it would be to support, say, OpenBSD.
I believe that it was Samuel Tardieu who contributed the sparc-linux
port back in the 3.13p or 3.14p days, but I may be wrong on this.
> So, lets imagine that you are a lead developer in an open source
> project (***). One of your goals is to produce software, which will
> run atleast on following systems:
> * Debian GNU/Linux 3.1: i386, IA-64, ARM, PowerPC, SPARC, MIPS
> * OpenSUSE 10.2: i386, x86-64
> * OpenBSD 4.0: i386, AMD64, ARM, PowerPC, SPARC
> * FreeBSD 6.2: i386, AMD64, Alpha
>
> The question is: Which programming language do you choose?
> (***) Like KDE, Subversion, GTK+, or Sendmail
If your project consists of general-purpose libraries and you want
them available to as many developers as possible, then your best
choice is C; not only because of compiler availability because, more
importantly, because C makes it easy to call your libraries from other
languages. It is a design goal of GNOME, for example, to support many
languages for application development, and that's why the GTK+ and
GNOME libraries are implemented in C, despite the fact that they are
object-oriented and so would have benefited from an object-oriented
language.
--
Ludovic Brenta.
Björn Persson
> Because most people don't have the same attitude towards language
> evaluation that you do.
>
> Most that I've actually asked have the attitude "C was what I learned
> in college, and it's good enough for me".
Lots of people also seem to pounce on the latest hype, thinking that latest
equals greatest. (I suppose that's what makes up a hype.) Those who realize
that C has serious problems typically hope for a new language to solve
those problems. It doesn't seem to occur to them that the problems might
have already been solved in some existing language. At least that's the
impression I get.
--
Björn Persson PGP key A88682FD
omb jor ers @sv ge.
r o.b n.p son eri nu
kevin cline
artifa...@googlemail.com wrote:
> Hello.
>
> I am a long time C programmer (10 years plus), having a look
> at Ada for the first time. From my (inadequate) testing, it seems
> that performance of average Ada code is on par with average
> C code, and there's a clear advantage in runtime safety. The
> GNU ada compiler makes pretty sure that there are very few
> platforms without easy access to Ada, so portability should be
> on at least an equal footing too.
>
> My question is: how come Ada isn't more popular?
1. Ada-83 simply sucked. Expensive, inexpressive, with poor libraries
and no support for writing desktop applications. Ada-83 was designed
for embedded development, and was OK for that purpose, but it was
hopeless for writing hosted applications.
2. For the same reason that Esperanto isn't more popular. Ada was
designed by a committee to meet theroetical needs. Most popular
languages have evolved to meet practical needs. They grew from humble
beginnings to widespread acceptance. Theoretically, they may be
abominations, but they get the job done.
3. For the same reason that Limburger cheese isn't more popular. Most
programmers who have tried Ada didn't like it. What makes a programmer
like a new language? Usually, someone comes along and says something
like "Remember that program that we spent two weeks writing in C?
Here's a Perl implementation that I put together in three hours and
one-tenth the code." That's never happened with Ada.
Dr. Adrian Wrigley
> artifa...@googlemail.com wrote:
>
>> Hello.
>>
>> I am a long time C programmer (10 years plus), having a look
>> at Ada for the first time. From my (inadequate) testing, it seems
>> that performance of average Ada code is on par with average
>> C code, and there's a clear advantage in runtime safety. The
>> GNU ada compiler makes pretty sure that there are very few
>> platforms without easy access to Ada, so portability should be
>> on at least an equal footing too.
>>
>> My question is: how come Ada isn't more popular?
>
> Others have given longer scoped responses, and I will concentrate on the
> hobbyist POV (I have felt an Ada hobbyist for a long time now): there is a
> catch-22 problem with Ada and it is the lack of libraries. This is a
> relative problem, consider these points.
>
> 1) The standard library is really standard, so this is an advantage if it
> does all you need. Also some features (e.g. fixed point, bound checking,
> tasking!) are in the language so you don't need extra wrappers around the
> basic language or OS.
>
> 2) There's no good, easy, almost automatic C binding generator, although the
> language has well defined mechanisms for C interfacing. Yes, there was some
> generator. No, it is not trivial at present to get it running in my
> experience. There's some effort to have Ada integrated into SWIG; this is
> promising and IMHO an important selling point to newcomers.
I think this is critical. Why can't we just say:
with stdio;
pragma import (C, stdio, "stdio.h");
and be able to get structs, functions, constants, variables from C in
an obvious and reasonably reliable way?
Much of what is in C has direct analogs in Ada. Some of it is via
fiddly #defines, but even a useful subset of these would be e
And of course compilers should spit out header files on request
matching an ada package via the "obvious" rules, so you can
#include it from C.
--
Adrian
Martin Dowie
> 3. For the same reason that Limburger cheese isn't more popular. Most
> programmers who have tried Ada didn't like it. What makes a programmer
> like a new language? Usually, someone comes along and says something
> like "Remember that program that we spent two weeks writing in C?
> Here's a Perl implementation that I put together in three hours and
> one-tenth the code." That's never happened with Ada.
FUD!!
http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
Frank J. Lhota
news:WYtth.318145$FQ1.108931@attbi_s71...
> More programming is done in COBOL than any other language.
Several decades ago, that was definitely true, but is it /still/ true today?
If one measures things by job openings, then COBOL appears to be outpaced by
C++, Java, and C#.
JPWoo...@gmail.com
On Jan 22, 9:53 pm, artifact....@googlemail.com wrote:
>
> My question is: how come Ada isn't more popular?
>
I have another hypothesis that involves the way many programmers got
started at a young age. For some decades, classes of smart young
teenagers have had easy access to computers and amateur tools, and
have honed their skills at what most of them called "hacking". They
learned to reason in low levels of abstraction. They spent a lot of
time in thread-of-execution debugging.
I think that software engineers who started their understanding in
that paradigm are a hard sell for Ada. They do have techniques that
work and there are plentiful examples of their success, but we Ada
guys prefer something different.
There are other ways to come to the software engineering mindset. One
way is to want to write interesting essays in the form of executable
programs. Ada is one of the finest tools for this task - at least as
far as our kind of program is concerned.
I submit Richard as an example - he writes whereof he knows. A few of
the other deponents on this conversation are no slouches either.
John
Alexander E. Kopilovich
>> What makes a programmer
>> like a new language? Usually, someone comes along and says something
>> like "Remember that program that we spent two weeks writing in C?
>> Here's a Perl implementation that I put together in three hours and
>> one-tenth the code." That's never happened with Ada.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>FUD!!
>
>http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
Is FUD a reserved word in Ada?
By the way, I think that the referenced (by above URL) article does not
contradict the apparently contested (under-marked) sentence, because
circumstances are far too different in several important aspects.
adaw...@sbcglobal.net
> artifa...@googlemail.com wrote:
>
> Most developers (98% in my experience) are coders. Coders like languages like
> C that let them code. Then then enjoy spending more time debugging then they
> did coding.
>
> The other 2% are SW engineers. They like languages like Ada.
>
> Obviously, C and its ilk are going to be more popular than Ada.
>
the equivalent of a nourishing meal rather than a greasy burger. C++
is the equivalent of peanut-brittle. It tastes good at first, then it gets
stuck in your teeth, and then it causes your molars to decay.
Richard Riehle
Jeffrey R. Carter
>
> Several decades ago, that was definitely true, but is it /still/ true today?
> If one measures things by job openings, then COBOL appears to be outpaced by
> C++, Java, and C#.
The most recent survey of actual projects that I've seen (in CACM, IIRC)
still had COBOL in 1st place.
--
Jeff Carter
"Every sperm is sacred."
Monty Python's the Meaning of Life
55
Jeffrey R. Carter
>
> By the way, I think that the referenced (by above URL) article does not
> contradict the apparently contested (under-marked) sentence, because
> circumstances are far too different in several important aspects.
Could you elaborate? It seemed pretty close to a controlled experiment
to me. The students were not specially selected; the problem was the
same; only the language and amount of solution made available to the
students changed.
Jeffrey R. Carter
>
> FUD!!
The whole post is FUD. It's an obvious troll, full of outright lies, and
hardly worth the effort of a reply.
kevin cline
On Jan 23, 4:18 pm, Martin Dowie <martin.do...@btopenworld.remove.com>
wrote:
> kevin clinewrote:
Yes, I've read that article. It would really be sad if Ada were not
superior to C for a toy problem in embedded control system development,
since Ada was designed specifically for that purpose. But the point
was that expressiveness drives programmers to new languages, and Ada
isn't particularly expressive.
Ludovic Brenta
> But the point was that expressiveness drives programmers to new
> languages, and Ada isn't particularly expressive.
On the contrary, I think that Ada is the most expressive language
around. Consider:
procedure Set_Bit_In_Register (At_Address : in System.Address) is
type Register is array (1 .. 32) of Boolean;
pragma Pack (Register);
for Register'Bit_Order use System.High_Order_First;
pragma Volatile (Register);
R : Register;
for R'Address use At_Address;
begin
Register (4) := True;
end;
versus
void set_bit_in_register (volatile unsigned long * at_address)
{
*at_address |= 2 << 3;
}
The Ada version makes many more things explicit, that are assumed and
implicit in C; for example, the size of the register, the fact that
the parameter is an address and not a pointer (*), the endianness, and
which bit is being set. As 64-bit architectures become prevalent, the
hidden assumption that C's "unsigned long" is 32 bits wide is more and
more likely to be incorrect.
(*) consider that when we increment the address by one, it then
references the next byte; whereas if we increment the pointer by one,
it points to the next "unsigned long", i.e. 2, 4 or 8 bytes and not 1
byte further. C makes no distinction between addresses and pointers,
lacking expressiveness in a crucial area.
When calling the subprogram, we get:
Set_Bit_In_Register (At_Address => To_Address (16#DEADBEEF#));
versus
set_bit_in_register (0xDEADBEEF);
Again, at the call site, the Ada version gives more information to the
human programmer, i.e. is more expressive.
Expressiveness is not to be confused with conciseness.
--
Ludovic Brenta.
Dmitry A. Kazakov
> adaw...@sbcglobal.net wrote:
>
>> Turbo Pascal and other alternatives were already in place and
>> much cheaper than Ada. A few brave souls tried to compete
>> with products such as RR Software's Janus Ada and Meridian's
>> AdaVantage, but the full environment (e.g., integrated editors,
>> debuggers, etc.) were not in place they were for Turbo Pascal.
>
> There's always the question of why, given TP's widespread popularity, C
> became more popular.
Because C was sufficiently worse. At some point Visual Basic came and
superseded both... (:-))
>> 6) Really good compilers began to appear around 1989. By then Ada's reputation
>> for being slow, cumbersome, and hard to use had already been firmly set.
>
> Actually, the DEC Ada compiler of 1984 was pretty good.
Yes!
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Maciej Sobczak
> For long term employees, you
> should be looking for SW engineers, whom you then train if necessary.
Yes.
> Identifying SW engineers isn't easy
Especially when the management (the hiring guys) are not SWEs themselves.
> but one clue is that SW engineers
> generally like Ada once they've been exposed to it.
Sorry, but this is made up of very thin air.
What about SWEs that were never exposed to Ada?
What about coders that were exposed to Ada but still have no clue?
The only thing that backs up your statement is that an average Ada
programmer is probably more competent than an average C programmer, but
even though this correlation is statically true, it is not necessarily
related to the virtues of any language, but rather to the fact that it
requires more self-determination (and therefore professional discipline)
to learn Ada in the world where Ada just does not sell (see "How come
Ada isn't more popular" thread). Learning C or Java comes for free and
the rest is just statistics, not the rule. There *are* SWEs that use
other languages.
> This approach has long term cost savings, as Ada results in SW that is
> ready for deployment sooner and has far fewer post-deployment errors
> than SW in C.
As if these were the only progamming languages in the world. There are
~2500, according to some very conservative estimations, so there is no
need to keep comparing just these two. "Ada is good, because it's better
than C" - is this the only thing that Ada can offer? :-) With ~2500
languages around just being better than C does not count as any
advantage, so I don't understand why do you use this as an argument so
often.
If you want to sell Ada, compare it to Java or C++ or C#, for example.
> Your SW is ready before your competitors, and is higher
> quality.
Just to flame a bit, I can write a database client library in C++ faster
than in Ada without compromising its quality (see my recent posts
concerning how much fun I've had with [Limited_]Controlled). ;-)
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Maciej Sobczak
>> Several decades ago, that was definitely true, but is it /still/ true
>> today? If one measures things by job openings, then COBOL appears to
>> be outpaced by C++, Java, and C#.
>
> The most recent survey of actual projects that I've seen (in CACM, IIRC)
> still had COBOL in 1st place.
Did it cover open-source projects as well?
COBOL was popular at the time when development was centralized in big
companies, so it was easier to count the number of lines. Today every
kid is coding something and it's even hard to estimate how much code is
written every day that is just unnoticed. Just having Windows as a major
operating system (with milions of development shops shipping software
for it) gives a hint that COBOL might not be a winner any longer.
Maciej Sobczak
> If your project consists of general-purpose libraries and you want
> them available to as many developers as possible, then your best
> choice is C
That's a misconception as well, quite common in an open-source world.
> not only because of compiler availability because, more
> importantly, because C makes it easy to call your libraries from other
> languages.
> It is a design goal of GNOME, for example, to support many
> languages for application development, and that's why the GTK+ and
> GNOME libraries are implemented in C, despite the fact that they are
> object-oriented and so would have benefited from an object-oriented
> language.
Windows was implemented in C++, and it has C API.
Encapsulation is what separates a language choice for the interface and
implementation - well, at least to some extent and provided that both
languages are easily "bindable". You can even have C API for Ada
implementation - pragma Export is just as useful as pragma Import!.
In other words, you don't need to use C for implementation part even if
you want to have C API for reasons of useability. This is exacly what
the open-source guys don't seem to get right.
gautier...@hotmail.com
> started at a young age. For some decades, classes of smart young
> teenagers have had easy access to computers and amateur tools, and
> have honed their skills at what most of them called "hacking". They
> learned to reason in low levels of abstraction. They spent a lot of
> time in thread-of-execution debugging.
>
> I think that software engineers who started their understanding in
> that paradigm are a hard sell for Ada. They do have techniques that
> work and there are plentiful examples of their success, but we Ada
> guys prefer something different.
Probably one hurdle for Ada is that the "Ada guys", self-called "we,
the true Software Engineers" want to keep "their" language for
themselves and discourage the "young hackers" even to take a look at it
when they mature... :-)
You are missing some aspects:
- a hacking teenager (I was one) is able to evolve and see that the
some previous "hacks" stop quicker working because there too much
intrication between I/O, GUI, system, libraries, or the code was too
cryptic
- it is possible to hack in Ada; no surprise, such programs are the
only that compile and run after 10 years sleep, on a new environment;
you are happy there was no conditional compilation in the source,
whereas other hacks in another language stop a compiler at line 2 or
3...
- not having hacked in the young age does not help to program better.
If you look at the code of whatever time you see that untalented people
program exactly as poorly whatever they did in their young age. You see
these same huge chunks of copy-paste style instruction blocks in old
Fortran code or recent code of whatever language, with a mix of
interactive/non-interactive, mix of abstraction levels; these people
find that a subprogram is a kind of magic, so they prefer to activate
the copy-paste machine, which they think is safer...
If you succeeded in your effort of generation split (drawing Ada on the
"old" side, then into the coffin), yes, there would be trouble for that
language...
______________________________________________________________
Gautier -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm
NB: For a direct answer, e-mail address on the Web site!
Markus E Leypold
Different generation?
Regards -- Markus
Markus E Leypold
<adaw...@sbcglobal.net> writes:
> I recently had the opportunity to teach a beginning class in Java. What I
> discovered is that Java is not type safe, <...>
How so? I'd be really intrested to know.
Regards -- Markus
gautier...@hotmail.com
> > Turbo Pascal and other alternatives were already in place and
> > much cheaper than Ada. A few brave souls tried to compete
> > with products such as RR Software's Janus Ada and Meridian's
> > AdaVantage, but the full environment (e.g., integrated editors,
> > debuggers, etc.) were not in place they were for Turbo Pascal.
> There's always the question of why, given TP's widespread popularity, C
> became more popular.
It has to do with the deep unportability of Pascal and (consequence)
the fragmentation of Pascal into incompatible dialects. At the time you
had Amiga's, Atari's, Mac's; you had MS Windows coming to replace DOS,
so a DOS-oriented, Pascal dialect had little chance against C, except
for a short time.
TP was an extremely fast compiler producing unoptimized code (except
some trivial XOR AX,AX's), but with the CPU's frequencies quickly up
around 1990, the interest was more targeted to profit from this speed
in the compiled code and less to have a couple millions more of LoC
compiled per second.
...
> Windows 95 was the 1st widely used OS with support for tasking. Ada (95)
> was the only widely available language with support for tasking at the
> time. We probably lost a good opportunity to gain more acceptance of Ada
> by not including a standard windowing library and promoting Ada as the
> best language for taking advantage of Win95's features.
Mmmh I think it was a good idea *not* to include a standard windowing
library: then now Ada would be stuck with an outdated standard
windowing library. There was also another problem then: the lack of a
good but cheap or free compiler.
Don't be so pessimistic, Ada's quality only appear with time - and of
course with the effort of brave souls.
If you say "I'm a smart software engineer, Ada is for me and not for
you", you won't help Ada.
If you make good, visible, useful open-source software with Ada, you
will help.
Markus E Leypold
Hi Ludovic,
Ludovic Brenta <lud...@ludovic-brenta.org> writes:
> kevin cline writes:
>> But the point was that expressiveness drives programmers to new
>> languages, and Ada isn't particularly expressive.
>
> On the contrary, I think that Ada is the most expressive language
> around.
If I were in the business of language advocacy as some people in this
thread obviously are, I'd now cry: "FUD!!"
Anyway, I have to contradict. You'd have to restrict the scope
of your statement a bit (to a special application area or a specific
subset of all programming languages) for it to become true.
I stipulate that languages with a Hindley-Milner type system and/or
functional languages are, in many aspects, more expressive. Even more
so, if they have modules, functors and classes (like OCaml) does.
Or consider Haskell which is a VERY expressive language.
Of course it all depends a bit on how you define "expressiveness".
I do not want to denigrate Ada here. But I think judging the place of
Ada in the world right is more important (or useful to Ada or the
community) than claming ALL the superlatives for Ada.
> procedure Set_Bit_In_Register (At_Address : in System.Address) is
> type Register is array (1 .. 32) of Boolean;
> pragma Pack (Register);
> for Register'Bit_Order use System.High_Order_First;
> pragma Volatile (Register);
>
> R : Register;
> for R'Address use At_Address;
> begin
> Register (4) := True;
> end;
>
> versus
>
> void set_bit_in_register (volatile unsigned long * at_address)
> {
> *at_address |= 2 << 3;
> }
<cynical mode>
You're sure you're not confusing verbosity with "expressiveness"? :-)
</cynical mode>
Regards -- Markus
Ludovic Brenta
> Hi Ludovic,
>
> Ludovic Brenta <lud...@ludovic-brenta.org> writes:
>
>> kevin cline writes:
>>> But the point was that expressiveness drives programmers to new
>>> languages, and Ada isn't particularly expressive.
>>
>> On the contrary, I think that Ada is the most expressive language
>> around.
>
> If I were in the business of language advocacy as some people in this
> thread obviously are, I'd now cry: "FUD!!"
[...]
> I do not want to denigrate Ada here. But I think judging the place of
> Ada in the world right is more important (or useful to Ada or the
> community) than claming ALL the superlatives for Ada.
OK, I'll take back what I said above, and replace with "Ada is the
most expressive language I know of." I can't comment on Haskell or
OCaml because I don't know them well enough.
>> procedure Set_Bit_In_Register (At_Address : in System.Address) is
>> type Register is array (1 .. 32) of Boolean;
>> pragma Pack (Register);
>> for Register'Bit_Order use System.High_Order_First;
>> pragma Volatile (Register);
>>
>> R : Register;
>> for R'Address use At_Address;
>> begin
>> Register (4) := True;
>> end;
>>
>> versus
>>
>> void set_bit_in_register (volatile unsigned long * at_address)
>> {
>> *at_address |= 2 << 3;
>> }
>
> <cynical mode>
> You're sure you're not confusing verbosity with "expressiveness"? :-)
> </cynical mode>
No, but there is bound to be some correlation. Expressiveness is the
ability to carry a lot of information across to the human programmer
as well as to the compiler. Verbosity, or its opposite conciseness,
is the density of that information, as in "information units per line
of code" or some such ill-defined measure.
Ada is more expressive than C because it allows programmes to express
more information. In a way, it is also more concise in that Ada
compilers insert all sorts of implicit checks, and in that Ada has
built-in constructs like tasking, array slices and return of
dynamically-sized objects that require much more lines of code to
achieve in C.
But C more concise than Ada in other ways; for example "volatile
unsigned long *" does not require a separate type definition, and "{}"
takes only 11.765% of the space of "begin; null; end;"
--
Ludovic Brenta.
Peter Hermann
> <adaw...@sbcglobal.net> writes:
> > discovered is that Java is not type safe, <...>
>
> How so? I'd be really intrested to know.
Java adopted a type system (at least for its scalar types)
which was about 20 years outdated at the time of Java's creation.
There is a lack of an important layer of abstraction
resulting from a C and Assembler mindset.
--
--Peter....@ihr.uni-stuttgart.de (+49)0711-685-872-44(Fax79)
--Nobelstr.19 Raum 0.030, D-70569 Stuttgart IHR Hoechstleistungsrechnen
--http://www.ihr.uni-stuttgart.de/
Pascal Obry
> <cynical mode>
>
> You're sure you're not confusing verbosity with "expressiveness"? :-)
>
> </cynical mode>
Let's try :
pragma Remote_Call_Interface;
as an expressiveness example :)
I won't even try to give the equivalent C/C++ code!
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
Alex R. Mosteo
>> 2) There's no good, easy, almost automatic C binding generator, although
>> the language has well defined mechanisms for C interfacing. Yes, there
>> was some generator. No, it is not trivial at present to get it running in
>> my experience. There's some effort to have Ada integrated into SWIG; this
>> is promising and IMHO an important selling point to newcomers.
>
> I think this is critical. Why can't we just say:
>
> with stdio;
>
> pragma import (C, stdio, "stdio.h");
>
> and be able to get structs, functions, constants, variables from C in
> an obvious and reasonably reliable way?
Ah, that sounds even better... One can dream...
Alex R. Mosteo
> artifa...@googlemail.com wrote:
>>
>> My question is: how come Ada isn't more popular?
>
> Much of what others have posted is good, but I also see:
>
> Most developers (98% in my experience) are coders. Coders like languages
> like C that let them code. Then then enjoy spending more time debugging
> then they did coding.
>
> The other 2% are SW engineers. They like languages like Ada.
>
> Obviously, C and its ilk are going to be more popular than Ada.
Perhaps we could run an informal poll to see the background of Ada people
here.
Markus E Leypold
Peter Hermann <ica...@csv.ica.uni-stuttgart.de> writes:
> Markus E Leypold wrote:
>> <adaw...@sbcglobal.net> writes:
>> > discovered is that Java is not type safe, <...>
>>
>> How so? I'd be really intrested to know.
>
> Java adopted a type system (at least for its scalar types)
> which was about 20 years outdated at the time of Java's creation.
> There is a lack of an important layer of abstraction
> resulting from a C and Assembler mindset.
So the type system is not rich enough, at least if you come from the
Ada world with those interesting subtyping stuff.
But how is Jave not _type safe_?
I believe Luca Cardelli gave a good definition of what type safe means in his paper
http://research.microsoft.com/Users/luca/Papers/TypeSystems.pdf
But I fail to see, how "execution errors" in the sense give there can
occur in Java. Shall I elaborate?
Regards -- Markus
Markus E Leypold
Ludovic Brenta <lud...@ludovic-brenta.org> writes:
> Markus E Leypold <development-2006-8...@ANDTHATm-e-leypold.de> writes:
>
>> Hi Ludovic,
>>
>> Ludovic Brenta <lud...@ludovic-brenta.org> writes:
>>
>>> kevin cline writes:
>>>> But the point was that expressiveness drives programmers to new
>>>> languages, and Ada isn't particularly expressive.
>>>
>>> On the contrary, I think that Ada is the most expressive language
>>> around.
>>
>> If I were in the business of language advocacy as some people in this
>> thread obviously are, I'd now cry: "FUD!!"
> [...]
>> I do not want to denigrate Ada here. But I think judging the place of
>> Ada in the world right is more important (or useful to Ada or the
>> community) than claming ALL the superlatives for Ada.
>
> OK, I'll take back what I said above, and replace with "Ada is the
> most expressive language I know of." I can't comment on Haskell or
> OCaml because I don't know them well enough.
Fine. I agree it's the most expressive one of the "classic" imperative
Familie, under which I count FORTRAN, C, C++, Modula, Pascal and so on
(forgive me, there is a similarity, so I think it makes sense for a
rough classification to put all those languages into a big
super-family, as opposed to in example the more or less functional
languages from LISP to Haskell).
>>
>> <cynical mode>
>> You're sure you're not confusing verbosity with "expressiveness"? :-)
>> </cynical mode>
>
> No, but there is bound to be some correlation. Expressiveness is the
> ability to carry a lot of information across to the human programmer
> as well as to the compiler. Verbosity, or its opposite conciseness,
> is the density of that information, as in "information units per line
> of code" or some such ill-defined measure.
Difficult. With time I've learnt to like the type inference and
annotations of Ocaml + Haskell and starting to get annoyed by the
Pascal style. Here verbosity buys me hardly anything and leaves me
with the necessity to state and restate the same thing everywhere. So
no: There is a correlation between verbosity and expressiveness, but
not a very strict one.
>
> Ada is more expressive than C because it allows programmes to express
> more information. In a way, it is also more concise in that Ada
I admit it has a richer, type system which allows to express more details.
> compilers insert all sorts of implicit checks, and in that Ada has
> built-in constructs like tasking, array slices and return of
Those I wouldn't count towards expressiveness, only as more
functionality in the standard runtime.
> dynamically-sized objects that require much more lines of code to
> achieve in C.
More power.
Regards -- Markus
Markus E Leypold
Pascal Obry <pas...@obry.net> writes:
> Markus E Leypold a écrit :
>> <cynical mode>
>>
>> You're sure you're not confusing verbosity with "expressiveness"? :-)
>>
>> </cynical mode>
>
> Let's try :
>
> pragma Remote_Call_Interface;
>
> as an expressiveness example :)
>
> I won't even try to give the equivalent C/C++ code!
So what is expressiveness in your definition? :-)
Regards -- Markus
Larry Kilgallen
> Perhaps we could run an informal poll to see the background of Ada people
> here.
(in reverse order) Pascal, Bliss, various assembly languages.
adaw...@sbcglobal.net
"kevin cline" <kevin...@gmail.com> wrote in message >
> Yes, I've read that article. It would really be sad if Ada were not
> superior to C for a toy problem in embedded control system development,
> since Ada was designed specifically for that purpose. But the point
> was that expressiveness drives programmers to new languages, and Ada
> isn't particularly expressive.
>
is often "in the eye of the beholder." For many software professionals,
the absence of curly-braces makes a language less expressive. For
others, their presence is a problem. For some, brevity is a sign of
expressiveness. For others, ease of understanding on the part of a
reader is important to expressiveness.
I do know a lot of languages, including many in the C family. I have
programmed in COBOL, Fortran, PL/I, BASIC, Python, and many
others. I teach a class in comparative programming languages.
An important distinction to be made is expressibility versus expressiveness.
The fact that I can express a solution in Fortran that is better suited to being
expressed in COBOL does not mean that Fortran is expressive. When
a solution is possible, that makes it expressible. When the language is
designed to express such solutions, that makes it expressive -- for that
kind of problem.
Languages evolve to become more expressive. Fortran has evolved. COBOL
has evolved. Ada has evolved. Even Java continues to evolve. Some languages
seem not to evolve and remain stagnent. PL/I comes to mind. Some programmers
do not evolve, and they also become out-of-date.
As languages evolve some tend to get better at being more directly expressiveof
a larger range of solutions. Not all languages evolve well. In my view, C++
has not become better with its most recent "improvements."
Ada is expressive of a large number of solutions that are more difficult to
express in C or other languages. However, the base language is not as
expressive as Perl for regular expressions. That has required a separate
library unit. It is not as directly expressive of mathematical solutions as
Fortran. That too requires library units. All the fundamental constructs
are in place to create powerful library units. This capability allows the
language to be easily extended to accomodate a large number of kinds
of solutions. Expressiveness is, for some kinds of solutions, through the
creation of such libraries, not by burdening the language.
The type model of Ada does enhance expressiveness since it allows a
lot of extensions. There are certainly things I would do differently in
that type system, and future languages will come along that improve on
Ada. At present, that has not happened -- certainly not with a type
model that I like. The visibility rules of Ada allow some powerful
constructs for designing large-scale software systems. None of the
C family, including C++, is as expressive in this regard.
Expressiveness needs to be considered beyond toy programs. Real
software systems also evolve. The fact that I can program myself
into a corner with some simple code that needs to be rewritten from
scratch each time the problem changes a little, can give me the
illusion of expressiveness. Real expressiveness includes the ability to
easily adapt the software in-place to the changing realities of the
environment in which it is deployed.
With all its shortcomings, and it does have shortcomings, Ada seems to
be have the capacity for being expressive of most kinds of practical
software solutions. For many of those solutions, without supporting
libraries, it is characterized by expressibility. When one adds libraries
written in Ada, we see greater expressiveness.
Expressiveness is not always hampered by the language design but
by those who have not yet learned how to use that design as it was
intended to be used.
Richard riehle
Adam Beneschan
On Jan 24, 12:07 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> kevin cline writes:
> > But the point was that expressiveness drives programmers to new
> > languages, and Ada isn't particularly expressive.On the contrary, I think that Ada is the most expressive language
> around. Consider:
>
> procedure Set_Bit_In_Register (At_Address : in System.Address) is
> type Register is array (1 .. 32) of Boolean;
> pragma Pack (Register);
> for Register'Bit_Order use System.High_Order_First;
> pragma Volatile (Register);
>
> R : Register;
> for R'Address use At_Address;
> begin
> Register (4) := True;
> end;
>
> versus
>
> void set_bit_in_register (volatile unsigned long * at_address)
> {
> *at_address |= 2 << 3;
>
> }
I think maybe I understand how C might be considered "more expressive"
to some programmers. If you want to set the third bit of this word,
you can just type in what you want, without going through a whole lot
of rigmarole like defining types and telling the compiler what you
intend to do and what order you think the bits are in and stuff like
that. You can just say it. Of course, if there's a misunderstanding
between you and the compiler about how your data is laid out, perhaps,
then your code doesn't work and it crashes your PC and introduces a
vulnerability that some clever hacker can take advantage of to turn
your computer into a subservient automaton whose sole purpose in life
is to send millions of "performance-enhancing drug" ads to *my* e-mail
address---but hey, at least you got to express yourself. C lets you
do this without having to do as much thinking or actual work, which
mean old Ada makes you do.
Perhaps we should just concede that C is a "more expressive
language"---with about as much benefit as there is to teaching math
students to be "more expressive" as opposed to getting the right
answer.
-- Adam
Niklas Holsti
fouls in this battle...
Adam Beneschan wrote:
>
> On Jan 24, 12:07 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
>>kevin cline writes:
>>
>>>But the point was that expressiveness drives programmers to new
>>>languages, and Ada isn't particularly expressive.On the contrary, I think that Ada is the most expressive language
>>
>>around. Consider:
>>
>>procedure Set_Bit_In_Register (At_Address : in System.Address) is
>> type Register is array (1 .. 32) of Boolean;
>> pragma Pack (Register);
>> for Register'Bit_Order use System.High_Order_First;
According to RM 13.5.3, the Bit_Order attribute can be specified only
for record types, not array types like Register, so this Bit_Order
clause is nonstandard. But this is perhaps not central to the argument...
>> pragma Volatile (Register);
>>
>> R : Register;
>> for R'Address use At_Address;
>>begin
>> Register (4) := True;
>>end;
If the High_Order_First clause were allowed for type Record, this would
set the 4th highest bit, that is the bit for 2**28. If the bit indices
run the other way, this would set the 4th lowest bit, the bit for 2**8.
>>versus
>>
>>void set_bit_in_register (volatile unsigned long * at_address)
>>{
>> *at_address |= 2 << 3;
>>
>>}
That sets the bit for the 5th lowest bit, the bit for 2**16. Note that
the shifted thing is 2#10#, not 2#1#.
> I think maybe I understand how C might be considered "more expressive"
> to some programmers. If you want to set the third bit of this word,
> you can just type in what you want, without going through a whole lot
> of rigmarole like defining types and telling the compiler what you
> intend to do and what order you think the bits are in and stuff like
> that. You can just say it. Of course, if there's a misunderstanding
> between you and the compiler...
There is a misunderstanding somewhere, because the oh-so-expressive C
code is not doing the same thing as the Ada code (in either Bit_Order),
nor the same thing as you say it does.
And of course the same formula can be written in Ada with modular types,
Shift_Right, "or". More characters to type, but less line-noise style
and no need to check the well-thumbed page of my C manual that shows the
C operator precedence table. This page has had a yellow post-it tab on
it for a long time... :-)
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
Pascal Obry
> So what is expressiveness in your definition? :-)
It is so expressive that I won't be able to comment here. See Annex-E in
the Ada reference manual :)
Markus E Leypold
Pascal Obry <pas...@obry.net> writes:
> Markus E Leypold a écrit :
>
>> So what is expressiveness in your definition? :-)
>
> It is so expressive that I won't be able to comment here. See Annex-E in
> the Ada reference manual :)
No, I asked, how you define expressiveness (generally), not, what is
so expressive in this pragma. But never mind. It's not important.
Regards -- Markus
Pascal Obry
> No, I asked, how you define expressiveness (generally), not, what is
> so expressive in this pragma. But never mind. It's not important.
Sorry I did not understand that! For me, a high expressiveness in a
programming language is how easy/simple it is to declare something that
can be quite complex underneath.
Yves Bailly
> [...]
> implementation - pragma Export is just as useful as pragma Import!.
> In other words, you don't need to use C for implementation part even if
> you want to have C API for reasons of useability. This is exacly what
> the open-source guys don't seem to get right.
Please, replace that "the" by "some", or even "many" if you like ;-)
I'm an open-source guy, currently creating an Ada binding to the
C++ library Qt through a C layer... pragma Export, Import and exern "C"
everywhere :-)
Regards,
--
(o< | Yves Bailly : http://kafka-fr.net | -o)
//\ | Linux Dijon : http://www.coagul.org | //\
\_/ | | \_/`
Markus E Leypold
Maciej Sobczak <no....@no.spam.com> writes:
> both languages are easily "bindable". You can even have C API for Ada
> implementation - pragma Export is just as useful as pragma Import!.
> In other words, you don't need to use C for implementation part even
> if you want to have C API for reasons of useability. This is exacly
> what the open-source guys don't seem to get right.
So Ada = Closed Source = Good and C = Open Source = Bad or something
like this? I don't understand it.
Apart from that, me seems it would be a bit difficult to have a C API
to some Ada library, since Ada requires quite a lot of runtime support
for tasking, so certainly doesn't interact to well C-code which also
use signals, longjmp etc.
Regards -- Markus
tmo...@acm.org
>
> with stdio;
>
> pragma import (C, stdio, "stdio.h");
>
> and be able to get structs, functions, constants, variables from C in
> an obvious and reasonably reliable way?
To some extent one can do this with APIs that come with typelibs. But
having recently made an Ada binding to the Google Earth API, I observe
that the time spent finding out what the various calls *actually* do vs
what the documentation indicates they do, takes much more time than the
typing of a bunch of pragma imports etc.
tmo...@acm.org
> > was the only widely available language with support for tasking at the
> > time. We probably lost a good opportunity to gain more acceptance of Ada
> > by not including a standard windowing library and promoting Ada as the
> > best language for taking advantage of Win95's features.
>
> Mmmh I think it was a good idea *not* to include a standard windowing
> library: then now Ada would be stuck with an outdated standard
> windowing library. There was also another problem then: the lack of a
> good but cheap or free compiler.
Actually some of us did try to make a standard Windows library and
promote Ada as the best language for Windows programming (see "CLAW, a
High Level, Portable, Ada 95 Binding for Microsoft Windows" TriAda 1997).
As a matter of fact, it seems everybody who wanted access to the Windows
API designed a standard windowing library - eg GWindows et al.
Also, there was the Janus Ada compiler which was pretty cheap at
something like $100, and the early versions of the free Gnat compiler were
coming out at that time.
Markus E Leypold
Hi Pascal,
Pascal Obry <pas...@obry.net> writes:
> Markus E Leypold a écrit :
>
>> No, I asked, how you define expressiveness (generally), not, what is
>> so expressive in this pragma. But never mind. It's not important.
>
> Sorry I did not understand that! For me, a high expressiveness in a
> programming language is how easy/simple it is to declare something that
> can be quite complex underneath.
Ludovics example was quite the opposite (verbose if precise). I think,
that expressiveness can not be defined or measured very well. Perhaps
as number of programming patterns that are supported and their
flexibility. So object orientation introduces more expressiveness when
compared with procedures, Hindley-Milner type systems when compared
with languages that have no parameterized types, templates (C++) would
also introduce more expressiveness (don't flame me, we are talking
"expressiveness" now, not safety), range sub-typing Ada style is also
added expressiveness (which on the other side is absent from the
Hindley-Milner type systems ...), functions as closures and 1st class
citizens allow to abstract over iteration patterns (fold, map, etc),
so this also introduces more expressiveness. And so on.
I do not agree with your definition that just measures the ratio
between "things happening underneath" and the construct you write in
your program. If I'd agree, I also had to concede that
#include <stdio.h>
is terribly expressive, because it pulls in such a lot of
functionality with one line (actually I think Fortran programmer would
agree :-) -- since there is no preprocessor defined in Fortran (up to
77 at least), they abuse the C preprocessor to reuse data definitions
and this like).
Perhaps we should ask: Which programming patterns / paradigms does
the language support? I realize that is terribly vague.
To widen the scope of this discussion a bit: I've been using some
10-20 languages in the last 2 decades intensively and looked upon
perhaps double as many. I'm amazed about the narrowing of perspective
I perceive with a number of participants in this discussion and the
other one (where someone asked for an Ada example for his book). Ada
still has it's place in the world, I think, but it would be good to
admit that things have changed a bit during the last 25 years. There
is a lot to be learned from Ada. Exclusive focus on it and ignoring
that not every piece of software fits into the Ada niche (which I
perceive to be reliable embedded programming) won't help to promote
it. I sometimes even doubt it can be rescued in the long run.
(That isn't against you, I'm just adding this not here, because I
can't decide where else).
Regards -- Markus
Arthur Evans Jr
"kevin cline" <kevin...@gmail.com> wrote:
> Ada was
> designed by a committee to meet theroetical needs.
Not so. Before design of Ada started, about 1970, there was a lengthy
period of gathering requirements. Input was solicited from all over,
both inside DOD and out, about what should be in the language. DOD
published in 1971 a Strawman proposal of language features, followed by
a Tinman, an Ironman, and finally a Steelman. Each of these feature
requirement documents was widely reviewed by anyone who chose to submit
comments, and these comments were studied to produce the next document
in the series. Comments came from language design theorists and
practitioners, from folks who thought a big program was 5000 lines and
from those who thought big was 5,000,000 lines, and from pretty much any
one else who chose to participate. Many had extensive experience in
large scale software development.
During all of this requirements development process, compiler
implementation started. In response to an RFP four teams were chosen to
implement the language. (I think Tinman was then the latest requirement
document.) The designs were evaluated publicly and the two best were
told to go on, and later the better of the two completed implementation
of what became Ada-83. I may have mis-remembered some of the details;
it's been a long time.
Was the result perfect? Far from it, but I thought then and still think
that Ada-83 was better for large mission-critical applications than any
other language then available.
BUT: Ada was not designed by a committee, and the needs it was intended
to meet were not theoretical. They were very practical.
All of that said, much of what was fine in Ada-83 was due to Jean
Ichbiah, who led the team that did that implementation. I disagreed with
some of Jean's decisions, some times vocally, but I later came to
realize that he was usually right. Participation in the Ada design
process was one of the high points of my career.
Art Evans
Distinguished Reviewer for Ada-83 and Ada-95
artifa...@googlemail.com
<a...@linuxchip.demon.co.uk.uk.uk> wrote:
>
> Why can't we just say:
>
> with stdio;
>
> pragma import (C, stdio, "stdio.h");
>
> and be able to get structs, functions, constants, variables from C in
> an obvious and reasonably reliable way?
>
That, would be one of the most beautiful things I'd seen in computing
if it existed!
MC
Pascal Obry
> #include <stdio.h>
>
> is terribly expressive, because it pulls in such a lot of
Certainly not. It does nothing at the semantic level. But I agree that
it is not easy to have a common view about expressiveness, let's drop
this then.
Cesar Rabak
> Hi,
>
> On 22 Jan 2007 21:53:32 -0800 artifa...@googlemail.com wrote:
>> My question is: how come Ada isn't more popular?
>>
>
> not popular (within the free software folks).
As a lot of interesting and complete info already has been posted here,
my humble contribution on Tero's view:
>
> Currently, the only non-restricted free Ada compiler is FSF GCC/GNAT.
> However, the GCC development team doesn't consider Ada to be
> a release critical language, so it gets less love whenever a new GCC
> is released and its quality is sometimes lower than C and C++ parts
> of GCC. In addition, Ada part of GCC supports far less platforms than
> C and C++ parts. (**)
[snipped]
FSF actually in their site
http://www.gnu.org/prep/standards/standards.html#Design-Advice
explicitly recommends use of C language as *the* language for FSF Open
Source projects.
All other factors withstanding, they got clout in their realm.
--
Cesar Rabak
Alexander E. Kopilovich
>> By the way, I think that the referenced (by above URL) article does not
>> contradict the apparently contested (under-marked) sentence, because
>> circumstances are far too different in several important aspects.
>
>Could you elaborate? It seemed pretty close to a controlled experiment
>to me. The students were not specially selected; the problem was the
>same; only the language and amount of solution made available to the
>students changed.
The original statement (from kevin cline) was:
>>> What makes a programmer
>>> like a new language? Usually, someone comes along and says something
>>> like "Remember that program that we spent two weeks writing in C?
>>> Here's a Perl implementation that I put together in three hours and
>>> one-tenth the code." That's never happened with Ada.
The article http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
presents the case where use of Ada language in very specific circumstances
was much more effective than use of C language in the same circumstances.
Those circumstances include:
1) close support provided by teaching staff
2) full and precise spefications for the problem domain
3) stable general requirements for the task and at the same time relative
freedom regarding details, and anyway, the absence of a stream of
unexpected changes in requirements and/or scope and/or additional
requirements
Compare these circumstances with those implied in the original statement
(quoted above). The latter certainly imply absence of condition 1 (permanent
close support), and also, the freedom of choice of a programming language
(or even an opportunity of discussion about that) very rarely comes to
programmers together with conditions 2 and 3.
Jeffrey R. Carter
>
> Because C was sufficiently worse. At some point Visual Basic came and
> superseded both... (:-))
What a depressing idea ...
--
Jeff Carter
"Strange women lying in ponds distributing swords
is no basis for a system of government."
Monty Python & the Holy Grail
66
Jeffrey R. Carter
>
> Did it cover open-source projects as well?
> COBOL was popular at the time when development was centralized in big
> companies, so it was easier to count the number of lines. Today every
> kid is coding something and it's even hard to estimate how much code is
> written every day that is just unnoticed. Just having Windows as a major
> operating system (with milions of development shops shipping software
> for it) gives a hint that COBOL might not be a winner any longer.
It covered projects for which people were paid to develop SW. When you
include open-source and teenage kids creating buffer-overflow errors in
their bedrooms, you may get a different result.
Jeffrey R. Carter
>
> Sorry, but this is made up of very thin air.
> What about SWEs that were never exposed to Ada?
You're going to expose them to Ada. They will like it. You'll know
you've got a keeper.
> What about coders that were exposed to Ada but still have no clue?
They don't like Ada.
> As if these were the only progamming languages in the world. There are
> ~2500, according to some very conservative estimations, so there is no
> need to keep comparing just these two. "Ada is good, because it's better
> than C" - is this the only thing that Ada can offer? :-) With ~2500
> languages around just being better than C does not count as any
> advantage, so I don't understand why do you use this as an argument so
> often.
> If you want to sell Ada, compare it to Java or C++ or C#, for example.
The OP said he hired C programmers because he couldn't find Ada
programmers, and he couldn't Ada programmers because he hired C
programmers. So my reply is in those terms.
kevin cline
On Jan 24, 10:14 am, <adawo...@sbcglobal.net> wrote:
> "kevin cline" <kevin.cl...@gmail.com> wrote in message >
> > Yes, I've read that article. It would really be sad if Ada were not
> > superior to C for a toy problem in embedded control system development,
> > since Ada was designed specifically for that purpose. But the point
> > was that expressiveness drives programmers to new languages, and Ada
> > isn't particularly expressive.It depends on what you want to express. Expressiveness, like beauty,
Not as powerful as I would like, and definitely not as powerful as C++
templates. Christopher Grein demonstrated this conclusively in his
paper on modeling scientific units in Ada. C++ templates allow the
straightforward construction of a compile-time safe system of physical
units, allowing arbitrary computations, while Ada's explicit
instantiation model forced one to rely on run-time checking.
Alexander E. Kopilovich
> classes of smart young
>teenagers have had easy access to computers and amateur tools, and
>have honed their skills at what most of them called "hacking". They
>learned to reason in low levels of abstraction. They spent a lot of
>time in thread-of-execution debugging.
Well, thread-of-execution is an extremely powerful abstraction, which appears
both as high-level and as low-level one. And thread-of-execution debugging
richly furnishes this abstraction with emotionally colored and socially
sharable practical cases. No wonder that it attracts some fraction of smart
young teenagers.
> One way is to want to write interesting essays in the form of executable
>programs. Ada is one of the finest tools for this task - at least as
>far as our kind of program is concerned.
The problem with this way is that it is hard to find a publishable subject,
which has sufficient potential of interest for "smart young teenagers" and
at the same time clearly demonstrates the strengths of Ada language.
It is because Ada language isn't adapted well for vague outlining of
possibilities and opportunities. Its main strengths are in expression of
very real and actual things, which, if are interesting, unfortunately almost
always are parts (or contain elements of or somehow connected with)
military/commercial/trade secrets.
Gautier
>>> Windows 95 was the 1st widely used OS with support for tasking. Ada (95)
>>> was the only widely available language with support for tasking at the
>>> time. We probably lost a good opportunity to gain more acceptance of Ada
>>> by not including a standard windowing library and promoting Ada as the
>>> best language for taking advantage of Win95's features.
>> Mmmh I think it was a good idea *not* to include a standard windowing
>> library: then now Ada would be stuck with an outdated standard
>> windowing library. There was also another problem then: the lack of a
>> good but cheap or free compiler.
>
> Actually some of us did try to make a standard Windows library and
> promote Ada as the best language for Windows programming (see "CLAW, a
> High Level, Portable, Ada 95 Binding for Microsoft Windows" TriAda 1997).
> As a matter of fact, it seems everybody who wanted access to the Windows
> API designed a standard windowing library - eg GWindows et al.
The point is that neither CLAW nor GWindows were included in the Ada standard,
and it is a good thing. And promoting Ada for Windows programming in an Ada
conference is good, but that won't make that language a lot more popular: you
have to make promotion outside the insider circle...
> Also, there was the Janus Ada compiler which was pretty cheap at
> something like $100, and the early versions of the free Gnat compiler were
> coming out at that time.
I'm afraid you read a bit too quickly: I discussed about finding a (_good_)
and (cheap or free) compiler in 1995. GNAT needed a few years to become really
good, IHMO.
______________________________________________________________
Gautier -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm
NB: For a direct answer, e-mail address on the Web site!
Alexander E. Kopilovich
> the point
>was that expressiveness drives programmers to new languages, and Ada
>isn't particularly expressive.
This is substantially inaccurate statement.
Ada is very expressive language, perhaps the most expressive language overall
among programming languages for which more than one commercially supported
compiler exists.
But there is indeed big issue with expressiveness in Ada, which hampers it
popularity: that big part of Ada expressiveness, which is really outstanding,
pertains to concrete information (both for data and for program structure),
which is likely to be proprietary in too many cases and thus not sharable.
At the same time Ada has poor expressiveness for incomplete (in one sense
or another) programs and components - thus making random collective
development almost impossible.
adaw...@sbcglobal.net
But safer than C++, overall. And safer than C++ templates.
>Christopher Grein demonstrated this conclusively in his
> paper on modeling scientific units in Ada. C++ templates allow the
> straightforward construction of a compile-time safe system of physical
> units, allowing arbitrary computations, while Ada's explicit
> instantiation model forced one to rely on run-time checking.
>
I have not read Christopher Grein's paper, and from what I know
of C++ and C++ templates, I am skeptical of the notion of it being
compile-time safe under any circumstances. I suppose one could
write some very careful code to make that true, but the language
itself is not inherently safe.
I have not had the experience of having to rely on run-time checking
for templates. In fact, my own experience of generics is that they
tend to enforce a great deal of checking at compile-time. That being
said, C++ templates do allow more complex variations on genericity,
and that does not contribute to type-safe software.
The whole point of Ada is to allow the maximum amount of checking
at compile-time. In fact, the point of the language design is to maximize
the amount of checking possible over the entire system as early in the
development as possible. C++ does not support anything close to
that goal except in a few isolated places within the langauge design.
We would want to evaluate the language as a whole, not one or
two features. We can compare C++ to Visual Basic and make
Visual Basic come out ahead. We can compare Ada to COBOL
and make COBOL come out ahead. In both cases, it will depend
on our criteria and what we decide to compare.
As to power. With Ada you get more power, safely, than you do in
C++ or Java. Empowering a language, while making it less safe
is not a good thing. As for Grein's paper, which I will take the time
to read, it is my experience that one can make a case quite nicely
by stacking the evidence in a particular way. I will try to find a
copy of the paper and make my own judgement about that.
Richard Riehle
Harald Korneliussen
On 24 Jan, 19:09, Pascal Obry <pas...@obry.net> wrote:
> For me, a high expressiveness in a
> programming language is how easy/simple it is to declare something that
> can be quite complex underneath.
>
But does that really matter all that much, as long as there are good
means of abstraction? I'd say that functional languages do perhaps have
an advantage there --- from the little I've tried, it seems that they
have some genuinely different ways of gluing things together.
Combinator-based parsing libraries would be an example. Amazing stuff,
which is not feasible in Ada or C++ (you could probably torture
templates into doing it in C++, but I don't count that as feasible).
But you can't easily do low-level stuff in them, which you can in Ada,
and although the type system in Ada is less extensible, it also has
some lovely features like the Positive numeric type, which can probably
be emulated in Haskell, but usually aren't.
Harald Korneliussen
> The type model of Ada does enhance expressiveness since it allows a
> lot of extensions. There are certainly things I would do differently in
> that type system, and future languages will come along that improve on
> Ada. At present, that has not happened -- certainly not with a type
> model that I like.
Just wondering, what do you think is the problem with H-M-type systems,
like ML and Haskell use? It seems to me they are a wonderful tool for
extending the type system to check properties at compile time that
would otherwise have to be checked at run time. I recently read about
an XML combinator library for Haskell that some researcher had written
that ensured that only valid XML could be generated - and it guaranteed
this at compile time!
Maciej Sobczak
>> both languages are easily "bindable". You can even have C API for Ada
>> implementation - pragma Export is just as useful as pragma Import!.
>> In other words, you don't need to use C for implementation part even
>> if you want to have C API for reasons of useability. This is exacly
>> what the open-source guys don't seem to get right.
>
> So Ada = Closed Source = Good and C = Open Source = Bad or something
> like this? I don't understand it.
Of course not. There is a significant amount of extremely good open
source software around, and I also suppose that some crappy Ada code
exists as well (it's harder to find it, but for the sake of argument I
can write some ;-) ).
My point is that the majority of open source world seems to get stuck
with C as a main development language for reasons which I don't really
understand. I understand the use of C on the interface level (everything
can bind to C, so it's the "least common denominator" for interfacing),
but internally many projects would greatly benefit from using just about
anything else. Developers reject this idea on the grounds that C is
*the* progamming language for open source, end of story. I think that
GNU luminaries (Stallman in particular) add to this mindset by
publishing web pages promoting C as the language of choice and the crowd
follows.
> Apart from that, me seems it would be a bit difficult to have a C API
> to some Ada library, since Ada requires quite a lot of runtime support
> for tasking, so certainly doesn't interact to well C-code which also
> use signals, longjmp etc.
Your argument can be applied in the other direction as well. How about
binding Ada to C libraries that use non-Ada runtime internally? It's
enough if the C library uses POSIX threads and its interaction with
tasking in Ada is already outside of what AARM specifies.
Binding (in any direction) requires some assuptions about the two
environments. There is way to escape them.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Harald Korneliussen
On 25 Jan, 09:37, Maciej Sobczak <no.s...@no.spam.com> wrote:
> Markus E Leypold wrote:
> I think that
> GNU luminaries (Stallman in particular) add to this mindset by
> publishing web pages promoting C as the language of choice and the crowd
> follows.
I'm pretty sure Stallman has more love for Lisp and Scheme than C,
given his background. I don't think it's a coincidence that the lexer
amd parser, Bison/Flex, was something of the first they made for GNU,
and that gcc, pretty uniquely among C compilers, has support for
tail-call elimination and inner functions. Raymond is another case, and
quite explicitly anti-Ada. (I may be wrong, but it seems to me that
Larry Wall, the author of Perl, has something of a love/hate
relationship with Ada. Didn't he first publish the diff algorithm in
Ada way back when?)
Anyway, I think individuals are less important than culture. You could
read this straight out of the wikipedia page for C (until I changed it
slightly ...): "the safe, effective use of C requires more programmer
skill, experience, effort, and attention to detail than is required for
some other programming languages." So if you use C, that means you are
skilled, experienced and attentive, by some people's logic. It's a
macho thing, "If you can't handle the power, don't use it!".
Klingon programmers if there ever were any.
It's of course a symptom of lack of professionalism: construction
workers who are proud of what they do wear their helmets.
Maciej Sobczak
> I have not read Christopher Grein's paper, and from what I know
> of C++ and C++ templates, I am skeptical of the notion of it being
> compile-time safe under any circumstances.
What is there in C++ templates that makes them unsafe?
> C++ templates do allow more complex variations on genericity,
> and that does not contribute to type-safe software.
Could you elaborate on this?
Do you mean that expressiveness and flexibility go against type-safety?
Dmitry A. Kazakov
> Christopher Grein demonstrated this conclusively in his
> paper on modeling scientific units in Ada. C++ templates allow the
> straightforward construction of a compile-time safe system of physical
> units, allowing arbitrary computations, while Ada's explicit
> instantiation model forced one to rely on run-time checking.
There exist numerous application where run-time unit checking is a
requirement. For instance in automation and control, data acquisition and
distribution, HMI. Templates fail there.
BTW, I am afraid that the solution you referred to, is unable to handle 蚓,
蚌. Not much promising, I would say...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Ali Bendriss
> <artifa...@googlemail.com> wrote in message
> news:1169531612.2...@38g2000cwa.googlegroups.com...
>
> > My question is: how come Ada isn't more popular?
>
> things. One is that the designers of the language did not anticipate
> the impact of the personal computer and the democratization of
> computing. There were other factors, as well.
> [...]
Does the fact that there is no "public" operating system written in Ada is one
of this factor ?
I think about the closest link between the C language and the *nix systems.
--
Ali
Bob Spooner
"Adam Beneschan" <ad...@irvine.com> wrote in message
news:1169655934....@j27g2000cwj.googlegroups.com...
> ...
> Perhaps we should just concede that C is a "more expressive
> language"---with about as much benefit as there is to teaching math
> students to be "more expressive" as opposed to getting the right
> answer.
>
> -- Adam
>
My view of expressiveness in a computer language is that it is inversely
proportional to the distance between the problem space and the solution
space. In other words, it is a measure of how high a level of abstraction in
which you can work when you use it.
Bob
Randy Brukardt
news:45b83...@news.bluewin.ch...
...
> I'm afraid you read a bit too quickly: I discussed about finding a
(_good_)
> and (cheap or free) compiler in 1995. GNAT needed a few years to become
really
> good, IHMO.
"Good" is highly subjective, and what you think of as "good" may differ
widely from other people. I know Tom thinks Janus/Ada was pretty good, and
long before 1995...
Your opinion of good may differ, depending on what you want to do.
Randy.
Jeffrey R. Carter
>
> The original statement (from kevin cline) was:
>
>>>> What makes a programmer
>>>> like a new language? Usually, someone comes along and says something
>>>> like "Remember that program that we spent two weeks writing in C?
>>>> Here's a Perl implementation that I put together in three hours and
>>>> one-tenth the code." That's never happened with Ada.
>
> The article http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
> presents the case where use of Ada language in very specific circumstances
> was much more effective than use of C language in the same circumstances.
The circumstances differed in this respect: The C students were given
60% of the teacher's solution. Initially, the Ada students were given
10% (or maybe less).
> Those circumstances include:
>
> 1) close support provided by teaching staff
> 2) full and precise spefications for the problem domain
> 3) stable general requirements for the task and at the same time relative
> freedom regarding details, and anyway, the absence of a stream of
> unexpected changes in requirements and/or scope and/or additional
> requirements
I agree that 1. doesn't apply to the OP's statement. However, I consider
a running program to be a very precise and stable specification, so 2.
and 3. appear to apply. And it's definitely a case of "Remember that
program you couldn't get working in C in an entire semester even though
you were given 60% of the code? Here's an Ada implementation that I got
working in a semester when given 10% of the code."
--
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28
Jeffrey R. Carter
>
> The point is that neither CLAW nor GWindows were included in the Ada
> standard, and it is a good thing. And promoting Ada for Windows
> programming in an Ada conference is good, but that won't make that
> language a lot more popular: you have to make promotion outside the
> insider circle...
I think I may have been misunderstood. I wasn't talking about Ada 95
including a standard library for MS Windows; I was talking about a
portable standard windowing library. On MS Windows platforms, that
library would target MS Windows.
> I'm afraid you read a bit too quickly: I discussed about finding a
> (_good_) and (cheap or free) compiler in 1995. GNAT needed a few years
> to become really good, IHMO.
Janus Ada was, and I'm sure still is, a good compiler. I used it for
many years after winning a copy at the Tri-Ada programming contest.
Jeffrey R. Carter
>>
> Well... as I recall, it ("Green") became DOD standard 1815 in
> December of 1980. It took another few years to become an ISO standard.
1980 Dec: MIL-STD-1815, Ada 80
1983 Feb: ANSI/MIL-STD-1815A, Ada 83 (adopted as an ISO standard 1987)
1995 Jan: ISO/IEC 8652:1995, Ada 95 (Technical Corrigendum 1 adopted in
2000)
Hopefully 2007 will see Ada 0X become a standard. On the Ada-comment
mailing list there's a discussion of revising the wording for
"equivalence" for ordered containers (originally discussed on c.l.a), so
it may be a while yet.
Jeffrey R. Carter
>
> Anyway, I think individuals are less important than culture. You could
> read this straight out of the wikipedia page for C (until I changed it
> slightly ...): "the safe, effective use of C requires more programmer
> skill, experience, effort, and attention to detail than is required for
> some other programming languages." So if you use C, that means you are
> skilled, experienced and attentive, by some people's logic. It's a
> macho thing, "If you can't handle the power, don't use it!".
The only safe use of C is as a target language for code generators (such
as the SofCheck Ada -> C compiler). The continuing creation of
buffer-overflow errors in C shows that, in practice, it is impossible
for humans to create safe C.
Markus E Leypold
Pascal Obry <pas...@obry.net> writes:
> Markus E Leypold a écrit :
>
>> #include <stdio.h>
>>
>> is terribly expressive, because it pulls in such a lot of
>
> Certainly not. It does nothing at the semantic level. But I agree that
I can see your point here.
> it is not easy to have a common view about expressiveness, let's drop
> this then.
OK. :-)
Regards -- Markus
Markus E Leypold
"Jeffrey R. Carter" <jrca...@acm.org> writes:
> Maciej Sobczak wrote:
>> Did it cover open-source projects as well?
>> COBOL was popular at the time when development was centralized in
>> big companies, so it was easier to count the number of lines. Today
>> every kid is coding something and it's even hard to estimate how
>> much code is written every day that is just unnoticed. Just having
>> Windows as a major operating system (with milions of development
>> shops shipping software for it) gives a hint that COBOL might not be
>> a winner any longer.
>
> It covered projects for which people were paid to develop SW. When you
> include open-source and teenage kids creating buffer-overflow errors
> in their bedrooms, you may get a different result.
Teanage kids these days write c001 PHP web applications. Now buffer
overflows there, but any amount of security holes.
BTW, what one can learn from that, is, that it is the absence of
correct models and absence encapsulation of state and representation
that makes software bad (insecure / unsafe / whatever), not only the
buffer overflows.
Regards -- Markus
Markus E Leypold
Markus E Leypold <development-2006-8...@ANDTHATm-e-leypold.de> writes:
> "Jeffrey R. Carter" <jrca...@acm.org> writes:
>
>> Maciej Sobczak wrote:
>>> Did it cover open-source projects as well?
>>> COBOL was popular at the time when development was centralized in
>>> big companies, so it was easier to count the number of lines. Today
>>> every kid is coding something and it's even hard to estimate how
>>> much code is written every day that is just unnoticed. Just having
>>> Windows as a major operating system (with milions of development
>>> shops shipping software for it) gives a hint that COBOL might not be
>>> a winner any longer.
>>
>> It covered projects for which people were paid to develop SW. When you
>> include open-source and teenage kids creating buffer-overflow errors
>> in their bedrooms, you may get a different result.
>
> Teanage kids these days write c001 PHP web applications. Now buffer
> overflows there, but any amount of security holes.
s/Teanage/Teenage/;s/Now/No/
Sorry.
Markus E Leypold
Maciej Sobczak <no....@no.spam.com> writes:
> Markus E Leypold wrote:
>
>>> both languages are easily "bindable". You can even have C API for Ada
>>> implementation - pragma Export is just as useful as pragma Import!.
>>> In other words, you don't need to use C for implementation part even
>>> if you want to have C API for reasons of useability. This is exacly
>>> what the open-source guys don't seem to get right.
>> So Ada = Closed Source = Good and C = Open Source = Bad or something
>> like this? I don't understand it.
>
> Of course not. There is a significant amount of extremely good open
> source software around, and I also suppose that some crappy Ada code
> exists as well (it's harder to find it, but for the sake of argument I
> can write some ;-) ).
Well. I remember having read some of it. :-). The language does not
guarantee good design.
> My point is that the majority of open source world seems to get stuck
> with C as a main development language for reasons which I don't really
> understand. I understand the use of C on the interface level
I share your not-understanding. My understanding of the reason for
this situation was always that it has something todo with (a)
premature optimization and (b) the lowest common denominator: A C
library can be bound to different language APIs, but a, say Python
library cannot. I doubt a Ada library could.
Apropos Python: There are a lot of languages that are rather popular
in OSS development apart from C. KDE is bound to Qt so cannot leave
C. GNOME AFAI understand will slowly shift to Mono as application run
time and thus will have more and mor C# code (that also shows what the
OSS guys percieve as their main problem: Pointers and memory
management, both of which have not been really solved in Ada to an
extent desirable for application programming (as opposed to
embedded)).
> (everything can bind to C, so it's the "least common denominator" for
Ooops. I didn't read so far. We agree :-).
> interfacing), but internally many projects would greatly benefit from
> using just about anything else. Developers reject this idea on the
> grounds that C is *the* progamming language for open source, end of
More likely, its "the available compiler".
> story. I think that GNU luminaries (Stallman in particular) add to
> this mindset by publishing web pages promoting C as the language of
> choice and the crowd follows.
I don't think so. Nobody really has a problem to contradict RMS :-).
>> Apart from that, me seems it would be a bit difficult to have a C API
>> to some Ada library, since Ada requires quite a lot of runtime support
>> for tasking, so certainly doesn't interact to well C-code which also
>> use signals, longjmp etc.
>
> Your argument can be applied in the other direction as well. How about
> binding Ada to C libraries that use non-Ada runtime internally? It's
Yes, this is a problem. Therefore the usual approach is, to avoid this
or at least to make the runtime separable and exchangeable.
> enough if the C library uses POSIX threads and its interaction with
> tasking in Ada is already outside of what AARM specifies.
Exactly. But you can writ Code in C which just does something with
things on the stack, doesn't fiddle with threads or signals and thus
interacts minimally with the host runtime. That's the reason why C is
so popular for libraries: You can.
> Binding (in any direction) requires some assuptions about the two
> environments. There is way to escape them.
Regards -- Markus
Markus E Leypold
Gautier <gau...@fakeaddress.nil> writes:
>> Also, there was the Janus Ada compiler which was pretty cheap at
>> something like $100, and the early versions of the free Gnat compiler were
>> coming out at that time.
>
> I'm afraid you read a bit too quickly: I discussed about finding a
> (_good_) and (cheap or free) compiler in 1995. GNAT needed a few years
> to become really good, IHMO.
Given, that I recently found in 3.15p (which is not the newest one, I know):
- Really bad bugs handling Read and Write of discrimated records,
- Race conditions in the runtime system when trying to catch
interrupts,
- No way to catch the console break under windows with the interupts
mechanism (i.e. a design error in my opinion),
I wonder wether GNAT was good even in, say 2002 (or whatever was
3.15p's release date).
And all those problems are really expensive to circumvent (partly
because the runtime system insists on fiddling with the signal
handlers).
Regards -- Markus
Markus E Leypold
"Harald Korneliussen" <vinte...@gmail.com> writes:
> On 25 Jan, 09:37, Maciej Sobczak <no.s...@no.spam.com> wrote:
>> Markus E Leypold wrote:
>> I think that
>> GNU luminaries (Stallman in particular) add to this mindset by
>> publishing web pages promoting C as the language of choice and the crowd
>> follows.
It was not me, that wrote this, but Maciej. Looks a bit strange this
way to quote.
Regards -- Markus
Markus E Leypold
"Harald Korneliussen" <vinte...@gmail.com> writes:
> skill, experience, effort, and attention to detail than is required for
> some other programming languages." So if you use C, that means you are
> skilled, experienced and attentive, by some people's logic. It's a
> macho thing, "If you can't handle the power, don't use it!".
>
> Klingon programmers if there ever were any.
That, of course is a general problem in IT: Public
criticism/discussion of "popular" (read hyped) paradigms or tools is
hardly possible, because that seems to imply that the critic is just
not able to use it ("What you can't program safely in C -- I can!"). I
might go farther and note that in teams/projects criticism is often
disliked: What is called a 'can-do' attitude in cheap management
literature is considered to be important. ("According to my analysis,
we can not write this piece of software in 2 months, since ..." --
"What, are you so incompetent? Your colleague / competitor says he can
do it. So'll give it to him").
So in my opinion you only point out a sub-aspect of a quite larger
problem.
> It's of course a symptom of lack of professionalism: construction
> workers who are proud of what they do wear their helmets.
Quite right. But in computer science (esp. software engineering) the
hard data is often quite missing, so the participants in these
discussions replace it by belief. Whereas nobody expects a proud
construction worker to wear amulets and nobody seriously suggests it,
because the majority agrees that helmets protect and amulets probably
not, the situation is different for development paradigms, processes
and tools. And usually there is no hard data available. So even those
which act wrong from your point of view can continue believing that
they are doing the right thing.
There is also the aspect of marketing which tends to further distort
reality (or whatever goes for it in IT).
Regards -- Markus
Markus E Leypold
"Jeffrey R. Carter" <jrca...@acm.org> writes:
> Alexander E. Kopilovich wrote:
>> The original statement (from kevin cline) was:
>>
>>>>> What makes a programmer
>>>>> like a new language? Usually, someone comes along and says something
>>>>> like "Remember that program that we spent two weeks writing in C?
>>>>> Here's a Perl implementation that I put together in three hours and
>>>>> one-tenth the code." That's never happened with Ada.
>> The article
>> http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
>> presents the case where use of Ada language in very specific circumstances
>> was much more effective than use of C language in the same circumstances.
>
> The circumstances differed in this respect: The C students were given
> 60% of the teacher's solution. Initially, the Ada students were given
> 10% (or maybe less).
So it was not really a comparable situation. One might argue that
already given partial solutions demotivate and that they have dangers
of its own (often draw people on a wrong path of thinking). I've
actually seen people given a partial solution perfoming worse than
those who had to do without.
Mind you, I do not suggest that really is the reason for the
differences found (I haven't even read the study yet), but I see a
problem with a study where the 2 groups compared are not really
starting from the same point. The only different factor should be the
programming language, not the rest of the setup.
Regards -- Markus
Markus E Leypold
"Jeffrey R. Carter" <jrca...@acm.org> writes:
> Harald Korneliussen wrote:
>> Anyway, I think individuals are less important than culture. You
>> could
>> read this straight out of the wikipedia page for C (until I changed it
>> slightly ...): "the safe, effective use of C requires more programmer
>> skill, experience, effort, and attention to detail than is required for
>> some other programming languages." So if you use C, that means you are
>> skilled, experienced and attentive, by some people's logic. It's a
>> macho thing, "If you can't handle the power, don't use it!".
>
> The only safe use of C is as a target language for code generators
> (such as the SofCheck Ada -> C compiler). The continuing creation of
> buffer-overflow errors in C shows that, in practice, it is impossible
> for humans to create safe C.
Not to promote C, but purely from a logical perspective: The
"continuing creation of buffer-overflow errors in C" only shows that
there exist programmers/humans that don't always create safe programs
in C.
Since I assume that the same thing (unsafe programs) applies to Ada
(say with respect to unhandled exceptions (Ariane, for instance ...)
or with respect to memory leaks or priority inversions in tasking),
the only remaining line on which an argument of the usability of C
vs. that of Ada can develop is quantitatively, not qualitatively.
I'd like just to point out that the world even in this respect is
neither black and white (or at least you haven't demonstrated that
convincingly yet), but more shades of gray. I concede the gray might
be lighter in Ada sector and darker in the C sector, but I'd prefer
quantitative arguments / reasoning in this world and some effort to
estimate the difference between those shades over striking but
logically flawed reasoning. I want absolutes I'll turn to religion. :-).
Regards -- Markus
Markus E Leypold
Maciej Sobczak <no....@no.spam.com> writes:
> adaw...@sbcglobal.net wrote:
>
>> I have not read Christopher Grein's paper, and from what I know
>> of C++ and C++ templates, I am skeptical of the notion of it being
>> compile-time safe under any circumstances.
>
> What is there in C++ templates that makes them unsafe?
Yes, the "under any circumstance" makes me rather
suspicious. Overgeneralizing? There might be (indeed are) good reasons
for disliking C++ templates but that statement, I think, will not hold
under examanation as a sufficient one.
>
>> C++ templates do allow more complex variations on genericity,
>> and that does not contribute to type-safe software.
>
> Could you elaborate on this?
> Do you mean that expressiveness and flexibility go against type-safety?
'adaworks' has already suggested that Java is not type safe. I fear he
does not agree with my definition of type safe.
Regards -- Markus