The future of Ada is at risk

The future of Ada is at risk

[Rico Secada]

I have been doing a lot of research about the usage of Ada, both in
industry and in the Open Source community. I am possible writing a paper
on the issue and needs some constructive criticism. 

I have reached the following conclusions:

1. Many companies are moving away from Ada towards C/C++. Many has
already moved during the past 10 years.

2. Very few projects exists on Sourceforge and Freshmeat compared to
other languages like C++, Java, Python and others.

Only 92 projects on Sourceforge.net and 57 on Freshmeat.net.

3. This is the biggest problem: Ada lacks free support on all
platforms. The GNU GNAT Compiler is the only Open Source compiler, and
it lacks proper support and implementation on a variety of platforms.

The different GNU/Linux implementations of GNAT and the different BSD
implementations seems to miss different aspects making it impossible to
port larger projects without having to buy a proprietary compiler.

My study shows, from searching around different mailing list archives
on GNU/Linux and BSD, that people are very attracted towards Ada, but
because of a poor implementation on different platforms when compared
to C and C++ people stay away and focus on those languages instead.

Problems with GNU GNAT and platform independence seems to be the one
major reason why Ada isn't a moving target.

I would like your comments on this please!

Best regards.

Rico Secada.

Re: The future of Ada is at risk

[Pascal Obry]

Rico,

> I have reached the following conclusions:
> 
> 1. Many companies are moving away from Ada towards C/C++. Many has
> already moved during the past 10 years.

And are having lot of problems with bugs and dead-line. At least this is
my own experience on some large simulation projects. Nobody seems to
master enough C++ to be able to build some sensible piece of code. A
disaster!

> 2. Very few projects exists on Sourceforge and Freshmeat compared to
> other languages like C++, Java, Python and others.

Have you looked at Savannah, repo.or.cz...

And please this does not mean anything. Ada is more oriented toward the
industry for high reliable softwares. You won't reach those project on
any Open Source plateforms. You won't even have hint about those
projects in many case as Ada is seen as a competitive tool.

> Only 92 projects on Sourceforge.net and 57 on Freshmeat.net.

And what!

> 3. This is the biggest problem: Ada lacks free support on all
> platforms. The GNU GNAT Compiler is the only Open Source compiler, and
> it lacks proper support and implementation on a variety of platforms.

Which platforms ? Windows and GNU/Linux are probably more than 90% of
the plateforms used for Open Source projects. So what is missing ?

For the industry it is out of question of using a compiler found on the
Internet. It requires a commercial compiler or support.

> The different GNU/Linux implementations of GNAT and the different BSD
> implementations seems to miss different aspects making it impossible to
> port larger projects without having to buy a proprietary compiler.

Yes, and that's the recipe for success. Having a good support is
invaluable for large projects.

> My study shows, from searching around different mailing list archives
> on GNU/Linux and BSD, that people are very attracted towards Ada, but
> because of a poor implementation on different platforms when compared
> to C and C++ people stay away and focus on those languages instead.

Do you really think that C++ is better implemented on Windows and
GNU/Linux... and portable ???

> Problems with GNU GNAT and platform independence seems to be the one
> major reason why Ada isn't a moving target.
> 
> I would like your comments on this please!

In general I have some problems with your conclusions. For me it makes
no sense mixing Open Source projects and commercial ones.

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

Re: The future of Ada is at risk

[Dmitry A. Kazakov]

On Sat, 29 Dec 2007 04:06:39 +0100, Rico Secada wrote:

> I have been doing a lot of research about the usage of Ada, both in
> industry and in the Open Source community. I am possible writing a paper
> on the issue and needs some constructive criticism. 
> 
> I have reached the following conclusions:
> 
> 1. Many companies are moving away from Ada towards C/C++. Many has
> already moved during the past 10 years.

I think that the wave already passed. Everybody who didn't want Ada has get
rid of it long ago. Ada has nothing to loose here.

> 2. Very few projects exists on Sourceforge and Freshmeat compared to
> other languages like C++, Java, Python and others.

True. There is little interest in Ada among the open source movement. I
think there are reasons for that. Much depends on how a programming
language recruits followers and how people come into open source. But this
might be more an issue of the open source model than of the language.

> 3. This is the biggest problem: Ada lacks free support on all
> platforms.

Hmm, Ada definitely lacks support on the platforms where it were obviously
superior to any other languages (massively parallel, embedded, real-time,
gaming, distributed computing). But that is not *all*, though maybe they
will become "key" platforms in some near future.

> Problems with GNU GNAT and platform independence seems to be the one
> major reason why Ada isn't a moving target.

It is just unfair to address this to AdaCore. There are of course numerous
problems with AdaCore's policy, but the fact is, - we have an open source
industrial-strength Ada compiler thank to AdaCore efforts. Ada community is
to weak to maintain an Ada compiler. Otherwise, that would have happened
long time ago.

Happy New Year!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The future of Ada is at risk

[Georg Bauhaus]

On Sat, 2007-12-29 at 04:06 +0100, Rico Secada wrote:

> Problems with GNU GNAT and platform independence seems to be the one
> major reason why Ada isn't a moving target.
> 
> I would like your comments on this please!

What variety of unnamed platforms do you mean?
The future of Ada on OpenBSD, FreeBSD, and NetBSD seems at risk.
(It is not at risc on Mac OS X BSD.)
Seriously, by the count of installations, isn't the future of
*BSD at risk. Sadly, this might be one of the reasons why no
one bothers to write a full GNAT runtime for BSD anymore.

What do you mean by variety of platforms? GNAT is running and supported
on every mainstream OS, including Windows NT (with or without .NET),
Mac OS X, Solaris, and GNU/Linux. The number of PC OS users with
a full GNAT option should thus be very close to 100%.

GNAT has been ported to several major non-PC operating systems,
such as VMS, VxWorks, and a few well known workstation Unices.

If a goal is to port major applications to one of the other unnamed
platforms, it might be best to ask those who provide Ada compilers
for that platform.

I'm not sure that inspecting mailing lists etc. for statistics
offers either validity or reliability of data. Depending on who
is to read you paper, they might find it suspicious that you
pool BSD and Linux lists, and then draw conclusions that cannot
be true for both platforms; GNAT (and other compilers) is a fully
supported Ada compiler on GNU/Linux. The data might be good enough
for goal directed marketing statistics, though.

Is your paper aimed at readers in the profession?
(That is, where money is involved?)

Re: The future of Ada is at risk

[I. Levashew]

Rico Secada wrote:

> My study shows, from searching around different mailing list archives
> on GNU/Linux and BSD, that people are very attracted towards Ada, but
> because of a poor implementation on different platforms when compared
> to C and C++ people stay away and focus on those languages instead.
Consider tolerance of C++ programmers to their compiler and Ada 
programmers to their one. Maybe implementations are just on the same 
level :)

> Problems with GNU GNAT and platform independence seems to be the one
> major reason why Ada isn't a moving target.
Confirmed. Personally, I don't care. Even if the OS I use is unsupported.
Currently I'm happy with Debian4/VMWare (native X11).

> I would like your comments on this please!
There is one promising project, Open LINA. My hopes are tied with it.

Re: The future of Ada is at risk

[anon]

In <20071229040639.f753f982.coolzone@it.dk>, Rico Secada <coolzone@it.dk> writes:
>I have been doing a lot of research about the usage of Ada, both in
>industry and in the Open Source community. I am possible writing a paper
>on the issue and needs some constructive criticism. 
>
>I have reached the following conclusions:
>
>1. Many companies are moving away from Ada towards C/C++. Many has
>already moved during the past 10 years.


1. Most companies left in 1998 when the DOD killed the "Ada Law".



>2. Very few projects exists on Sourceforge and Freshmeat compared to
>other languages like C++, Java, Python and others.
>
>Only 92 projects on Sourceforge.net and 57 on Freshmeat.net.


2. Most Ada projects are not for open source community and will 
never be archive at any open source archiving site, such 
as sourceforge, etc.


>3. This is the biggest problem: Ada lacks free support on all
>platforms. The GNU GNAT Compiler is the only Open Source compiler, and
>it lacks proper support and implementation on a variety of platforms.





3. In this answer you need to spend more time doing research.
Free support is always limited! And Adacore's GNAT is only Ada 
that is implementation on most platforms and the number is 
growing every day. Not sure what you mean by proper support but 
if your talking about vendor (Adacore) support. You can pay for 
it just like other languages. You may hate the price but it 
does exist. 



>The different GNU/Linux implementations of GNAT and the different BSD
>implementations seems to miss different aspects making it impossible to
>port larger projects without having to buy a proprietary compiler.
>
>My study shows, from searching around different mailing list archives
>on GNU/Linux and BSD, that people are very attracted towards Ada, but
>because of a poor implementation on different platforms when compared
>to C and C++ people stay away and focus on those languages instead.
>
>Problems with GNU GNAT and platform independence seems to be the one
>major reason why Ada isn't a moving target.
>
>I would like your comments on this please!
>
>Best regards.
>
>Rico Secada.


        First you need to learn about why Ada was created. Ada was 
created for "High Integrity" and "True Portability" type of 
applications. Most programmers believe at the movement that most 
projects do not need that level of integrity. Now this is a 
falsehood, but until most programmer realize this Ada will not move 
in it current level of usage. And when using the standard Ada 
libraries (Ada) the program is 100% portable without modification.


        The problem with OpenBSD is that it is designed for 
security. Which means that there are fewer application that can be 
ported with full functionality. Even though OpenBSD was initially 
based FreeBSD it has become quite distinct. So, in porting an 
application from FreeBSD or other BSD's to OpenBSD it can be a pain 
because of its use of security and distinctive design.

        Plus, open source programming developers do not need or want 
high security developmental system limiting them from creating 
programs and projects just because it might violate the security on 
the programmer's workstation. They need a more relax security 
workstation and then add the level of security as needed for the 
project.

        That means that OpenBSD is limited in its scope of 
application and to be use of a platform for programming 
development.


        Now for Ada. Most programmer use a Desktop that they like 
to write the code and perform primary debugging. Such as FreeBSD, 
Linux, Vista and others Desktop. Then they move the code to the 
core platform and complete the debugging and optimization phase. 
This save time and money. Plus, sometime a programmer may not have 
access to the core platform until the end of the development cycle.


        Free Support! That's a Myth! Especially in Open Source!
Normally free support is limited to a few weeks to a few months 
(90 days in some cases). As for Adacore, you can get a yearly 
support but you pay a high price for it and you may not need it.

        But for normal support. You need to study the life cycle of 
a program and compiler. You will find out that the vendors of the 
language compiler have limited free support and have little to no 
support for a project. And they only port their compilers to a 
limited number of hardware platforms. Such as IBM which only 
supports hardware and platform it has developed. It is up to the 
project developers and programmers to provide the true support. 
In an examples of a traffic light system, Adacore or any or Ada 
vendor is not responsible for support.  The support is provide by 
two main sources: first the manufacturer of the traffic light 
controller and second the software team that wrote the 
controller's software.


Looks to me that you need to do a lot more research before wrtting 
your paper.

Re: The future of Ada is at risk

[Rico Secada]

On Sat, 29 Dec 2007 16:24:54 GMT
anon@anon.org (anon) wrote:

> 
> In <20071229040639.f753f982.coolzone@it.dk>, Rico Secada
> <coolzone@it.dk> writes:
> >I have been doing a lot of research about the usage of Ada, both in
> >industry and in the Open Source community. I am possible writing a
> >paper on the issue and needs some constructive criticism. 
> >
> >I have reached the following conclusions:
> >
> >1. Many companies are moving away from Ada towards C/C++. Many has
> >already moved during the past 10 years.
> 
> 
> 1. Most companies left in 1998 when the DOD killed the "Ada Law".
> 
> 
> 
> >2. Very few projects exists on Sourceforge and Freshmeat compared to
> >other languages like C++, Java, Python and others.
> >
> >Only 92 projects on Sourceforge.net and 57 on Freshmeat.net.
> 
> 
> 2. Most Ada projects are not for open source community and will 
> never be archive at any open source archiving site, such 
> as sourceforge, etc.
> 
> 
> >3. This is the biggest problem: Ada lacks free support on all
> >platforms. The GNU GNAT Compiler is the only Open Source compiler,
> >and it lacks proper support and implementation on a variety of
> >platforms.
> 
> 
> 
> 
> 
> 3. In this answer you need to spend more time doing research.
> Free support is always limited! And Adacore's GNAT is only Ada 
> that is implementation on most platforms and the number is 
> growing every day. Not sure what you mean by proper support but 
> if your talking about vendor (Adacore) support. You can pay for 
> it just like other languages. You may hate the price but it 
> does exist. 
> 
> 
> 
> >The different GNU/Linux implementations of GNAT and the different BSD
> >implementations seems to miss different aspects making it impossible
> >to port larger projects without having to buy a proprietary compiler.
> >
> >My study shows, from searching around different mailing list archives
> >on GNU/Linux and BSD, that people are very attracted towards Ada, but
> >because of a poor implementation on different platforms when compared
> >to C and C++ people stay away and focus on those languages instead.
> >
> >Problems with GNU GNAT and platform independence seems to be the one
> >major reason why Ada isn't a moving target.
> >
> >I would like your comments on this please!
> >
> >Best regards.
> >
> >Rico Secada.
> 
> 
>         First you need to learn about why Ada was created. Ada was 
> created for "High Integrity" and "True Portability" type of 
> applications. Most programmers believe at the movement that most 
> projects do not need that level of integrity. Now this is a 
> falsehood, but until most programmer realize this Ada will not move 
> in it current level of usage. And when using the standard Ada 
> libraries (Ada) the program is 100% portable without modification.
> 
> 
>         The problem with OpenBSD is that it is designed for 
> security. Which means that there are fewer application that can be 
> ported with full functionality. Even though OpenBSD was initially 
> based FreeBSD it has become quite distinct. So, in porting an 
> application from FreeBSD or other BSD's to OpenBSD it can be a pain 
> because of its use of security and distinctive design.

It was based upon NetBSD.

>         Plus, open source programming developers do not need or want 
> high security developmental system limiting them from creating 
> programs and projects just because it might violate the security on 
> the programmer's workstation. They need a more relax security 
> workstation and then add the level of security as needed for the 
> project.
> 
>         That means that OpenBSD is limited in its scope of 
> application and to be use of a platform for programming 
> development.
> 
> 
>         Now for Ada. Most programmer use a Desktop that they like 
> to write the code and perform primary debugging. Such as FreeBSD, 
> Linux, Vista and others Desktop. Then they move the code to the 
> core platform and complete the debugging and optimization phase. 
> This save time and money. Plus, sometime a programmer may not have 
> access to the core platform until the end of the development cycle.
> 
> 
>         Free Support! That's a Myth! Especially in Open Source!
> Normally free support is limited to a few weeks to a few months 
> (90 days in some cases). As for Adacore, you can get a yearly 
> support but you pay a high price for it and you may not need it.
> 
>         But for normal support. You need to study the life cycle of 
> a program and compiler. You will find out that the vendors of the 
> language compiler have limited free support and have little to no 
> support for a project. And they only port their compilers to a 
> limited number of hardware platforms. Such as IBM which only 
> supports hardware and platform it has developed. It is up to the 
> project developers and programmers to provide the true support. 
> In an examples of a traffic light system, Adacore or any or Ada 
> vendor is not responsible for support.  The support is provide by 
> two main sources: first the manufacturer of the traffic light 
> controller and second the software team that wrote the 
> controller's software.
> 
> 
> Looks to me that you need to do a lot more research before wrtting 
> your paper.
> 

Actually, it looks to me like you have just proven my point.

> 

Re: The future of Ada is at risk

[Jerry van Dijk]

>> 1. Many companies are moving away from Ada towards C/C++. Many has
>> already moved during the past 10 years.

Personally, I always suspected that these were the superior programmers. Me,
I am always making mistakes, I can use all the help I can get :-)

Doing a project in a c++ class language is like wearing shoes that are a size
too small. You may walk as fast as anybody else, but it sure hurts a lot and 
in the long run will cause all kinds of costly to correct errors.

-- 
--  Jerry van Dijk
--  Leiden, Holland
--
--  The early bird may get the worm, but the second mouse gets the cheese!!

Re: The future of C# is at risk

[Georg Bauhaus]

Rico Secada wrote:
> On Sat, 29 Dec 2007 16:24:54 GMT
> anon@anon.org (anon) wrote:

>>> 2. Very few projects exists on Sourceforge and Freshmeat compared to
>>> other languages like C++, Java, Python and others.
>>>
>>> Only 92 projects on Sourceforge.net and 57 on Freshmeat.net.
>>
>> 2. Most Ada projects are not for open source community and will 
>> never be archive at any open source archiving site, such 
>> as sourceforge, etc.
>>
>>
>> Looks to me that you need to do a lot more research before wrtting 
>> your paper.
>>
> 
> Actually, it looks to me like you have just proven my point.
> 

The biggest problem is that C# lacks free support on all platforms.
There is only really one Open Source compiler and runtime
infrastructure with thriving support. It also lacks several
important features on a variety of platforms.
Mono has essentially two^H^H^Hone sponsors^H. Implementations
are revolving around VMs ported to Novell's SuSE Linux.
Major database systems have been announced to be gradually replaced
by VistaDB. You cannot hope to be porting high security
applications to a variety of platforms without buying
a proprietary C# compiler.
Conslusion: Therefore, the future of C# is at risk!

I know this comment isn't obviously construtive.

Re: The future of Ada is at risk

[Phaedrus]

Take a look at this:
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

The game development guys realize the need for a new language.  Doesn't the 
language he describes sound a little familiar?  Lots of Ada-esque stuff 
there.  Sure, there's a lot of work to be done before Ada is really 
practical for game development, but it's certainly do-able.  Remember, the 
game market is a lot bigger than the old military market ever was.

Just a few things will have to change before it's worth-while.  You're 
right, only one real compiler exists and it's horribly expensive for 
commercial work. (Isn't it interesting that they claim to only charge for 
"support", but then force anyone who uses the free compiler to release their 
developed software for free?  *sigh*)  Along that line, a lot of current Ada 
packages have been infected with the dreaded GPL-itis. That make them 
unusable for commercial stuff, too.  But mostly I think that it's the nature 
of the mindset behind a lot of packages that would need to change.  Getting 
those 50 - 60Hz updates isn't easy!

Just my $.02 worth.
Brian

"Rico Secada" <coolzone@it.dk> wrote in message 
news:20071229040639.f753f982.coolzone@it.dk...
>I have been doing a lot of research about the usage of Ada, both in
> industry and in the Open Source community. I am possible writing a paper
> on the issue and needs some constructive criticism.
>
> I have reached the following conclusions:
>
> 1. Many companies are moving away from Ada towards C/C++. Many has
> already moved during the past 10 years.
>
> 2. Very few projects exists on Sourceforge and Freshmeat compared to
> other languages like C++, Java, Python and others.
>
> Only 92 projects on Sourceforge.net and 57 on Freshmeat.net.
>
> 3. This is the biggest problem: Ada lacks free support on all
> platforms. The GNU GNAT Compiler is the only Open Source compiler, and
> it lacks proper support and implementation on a variety of platforms.
>
> The different GNU/Linux implementations of GNAT and the different BSD
> implementations seems to miss different aspects making it impossible to
> port larger projects without having to buy a proprietary compiler.
>
> My study shows, from searching around different mailing list archives
> on GNU/Linux and BSD, that people are very attracted towards Ada, but
> because of a poor implementation on different platforms when compared
> to C and C++ people stay away and focus on those languages instead.
>
> Problems with GNU GNAT and platform independence seems to be the one
> major reason why Ada isn't a moving target.
>
> I would like your comments on this please!
>
> Best regards.
>
> Rico Secada. 

Re: The future of Ada is at risk

[Pascal Obry]

Phaedrus a �crit :
> Just a few things will have to change before it's worth-while.  You're 
> right, only one real compiler exists and it's horribly expensive for 
> commercial work. (Isn't it interesting that they claim to only charge for 
> "support", but then force anyone who uses the free compiler to release their 
> developed software for free?  *sigh*)  Along that line, a lot of current Ada 
> packages have been infected with the dreaded GPL-itis. That make them 
> unusable for commercial stuff, too.  But mostly I think that it's the nature 
> of the mindset behind a lot of packages that would need to change.  Getting 
> those 50 - 60Hz updates isn't easy!

Sorry but this is full non-sense. You oppose GPL and commercial but it
is just ok to have a commercial GPL software.

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

Re: The future of Ada is at risk

[Georg Bauhaus]

Phaedrus wrote:

> Remember, the 
> game market is a lot bigger than the old military market ever was.
> 
> Just a few things will have to change before it's worth-while.

Which ones?

>  You're 
> right, only one real compiler exists and it's horribly expensive for 
> commercial work.

I'm working with another compiler and tools, but indeed,
software has something unreal.

Not sure how those other Ada businesses are providing
their unreal tools.

> (Isn't it interesting that they claim to only charge for 
> "support", but then force anyone who uses the free compiler to release their 
> developed software for free?  *sigh*)  Along that line, a lot of current Ada 
> packages have been infected with the dreaded GPL-itis. That make them 
> unusable for commercial stuff, too.

Yeah, these days there is little you get for nothing.

Re: The future of Ada is at risk

[Florian Weimer]

* Georg Bauhaus:

> The future of Ada on OpenBSD, FreeBSD, and NetBSD seems at risk.

Last year, I tried to port one of my Ada implementations to FreeBSD (I
think it was version 6) on the amd64 architecture.  Maybe I misread the
ports collection, but there didn't seem to be a port.  There seemed to
be some performance issue with the system malloc which causes very slow
compilation on FreeBSD 6 on i386, too.

To sum it up, the platform appeared to be rather untested.  On the other
hand, there was little porting involved as far the actual application
was concerned.  But the application was small (just 30 kSLOC), and used
very few interfaces specific to operation systems (mainly the modern,
IPv6-capable sockets API, for which two variants exist, and I had only
programmed to the Linux variant before).

What's worse, the application test suite shows that tasking is broken on
SMP machines on current GNU/Linux (both i386 and amd64, IIRC), not just
on FreeeBSD. 8-(

> Seriously, by the count of installations, isn't the future of
> *BSD at risk.

Unfortunately, one of our partner organizations is rather BSD-centric.

> Sadly, this might be one of the reasons why no one bothers to write a
> full GNAT runtime for BSD anymore.

The run-time library exists, it just needs to be maintained (same for
GNU/Linux, actually).  My impression that most commercial GNAT users do
not use tasking, or use it on freestanding implementations (that is, not
GNU/Linux).  Similar to no one using Ada.Strings.Unbounded (this has
changed recently, apparently), or finalization in performance-sensitive
code.

Re: The future of Ada is at risk

[okellogg]

On Dec 30, 1:30 pm, Florian Weimer <f...@deneb.enyo.de> wrote:
>    [...] My impression that most commercial GNAT users do
> not use tasking, or use it on freestanding implementations (that is, not
> GNU/Linux).

I've been porting a large application (several 100000 executable LOC)
to  to GNU/Linux
with FSF gcc-4.2.1. The program had over 300 tasks, all statically
allocated. Basically the
entire program was running during elaboration. The problems with
elaboration order and
task stacks all went away "magically" after changing the tasks to task
types/access-to-task
objects and explicit Init procedures for allocating the task objects
from the main program.

Just my EUR 0.02

Oliver

Re: The future of Ada is at risk

[Florian Weimer]

>>    [...] My impression that most commercial GNAT users do
>> not use tasking, or use it on freestanding implementations (that is, not
>> GNU/Linux).
>
> I've been porting a large application (several 100000 executable LOC)
> to to GNU/Linux with FSF gcc-4.2.1.

FSF GCC is not commercially relevant. 8-) Its users' demands have little
influence on GNAT development, as far as I can tell.

> The program had over 300 tasks, all statically allocated.

Does the program use protected objects and conditional entry calls?

Re: The future of Ada is at risk

[adaworks]

"Phaedrus" <phaedrusalt@hotmail.com> wrote in message 
news:13nek962cd55t08@corp.supernews.com...
> Take a look at this:
> http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
>
> The game development guys realize the need for a new language.  Doesn't the 
> language he describes sound a little familiar?  Lots of Ada-esque stuff there. 
> Sure, there's a lot of work to be done before Ada is really practical for game 
> development, but it's certainly do-able.
I think it is not "before Ada is really practical," but before the Ada 
compilers,
libraries, and toolsets are ready.  As a language design, Ada is certainly 
ready.
The availability of additional libraries and tools has delayed its acceptance in
the larger community.  This is a kind of "chicken and egg" thing.

As for the lemmings rushing over the cliff carrying C++ banners, their cause
is now under assault with the advent of Java, C#, and Ruby.  The number of
professional programmers who believe C++ is the answer is dwindling, and
new options such as "D" are appearing.   We are back to the pre-Ada period
of a "Tower of Babel" and that is not good news for the profession.  The DoD,
unable to manage a single-language policy is now mired in a multiple-language
policy which will eventually become a huge problem for the weapon systems
community -- but a huge opportunity for the contractors who will get billions
of dollars for fixing the software they are currently trying to build.

As long as software engineering language choice is driven by the latest fad, we 
can
expect the problem to get worse.  The people at the contractor organizations 
such
as LM who chose C++ over Ada have made a monumental error and that error
will pesist for a very long time.   Some other contractors who made the same 
dumb
decision are now hoping Java will save them.  It won't.   As long as software 
development
is relegated to a programming process instead of an engineering process, those 
contractors
will continue to make bad choices -- and the quality of the products will be 
just good
enough to require more DoD money for follow-on projects for the software 
equivalent
of baling-wire type fixes.

I am now persuaded that the abrogation of the Ada mandate in 1998 was a very bad
step. It was the equivalent of grabbing defeat from the jaws of victory.   Just 
at the time
when Ada had advanced beyond the original conservative model to incorporate a 
more
robust language design, the DoD, reacting to pressure from contractor 
executives, and
using a fallacious economic rationale, abandoned their best language hope for 
the
preservation of a software engineering development tool.

I was told recently, by someone in the Ada tool industry, that there are very 
few new Ada
projects being started.   Economic survival requires that compiler publishers 
expand their
own software product line -- or plunge into extinction.    I know there are some 
new projects,
but some of the most important DoD projects are eschewing Ada.   This is, in 
part, because
the DoD toothless officials responsible for software contracting have abdictated 
their own
responsibility for langauge choice and left the decision to the contractor.   In 
the world of
accounting, there is a principle of "separation of controls."   This principle 
says that the
person handling the money should not also be doing the record-keeping, and 
control
for it.  Under the current model, the DoD contractors are making all the 
decisions, and there
is a chance that those decisions are made in the best interest of their own 
corporate future
-- and economic self-interest.   This is not to suggest they are dishonest. 
They are, from
my experience, honorable and dedicated patriots who have the best interest of 
the DoD
and U.S. society at heart.   However, even the noblest among us is capable of 
rationalization.

On the bright side, I am happy to note that there are a lot of people in the DoD 
who are
concerned about this kind of thing.   The awareness of a need for better 
engineering with
regard to software is growing due to the presence of some very bright and 
well-informed
personnel in the DoD.   The hope for the future can be that these excellent 
civil servants
will be able to enforce some software engineering discipline on those 
contractors (not all
of whom) are programming-centric rather than software engineering-centric.  This 
could
result in better choices of languages, and Ada would certainly be a better 
choice for many
of the current projects than some of those being chosen by the contractors.  On 
bright
light has been the contribution of SPARK to the increased use of Ada.

As for "free software." That ought not be the issue for safety-critical software 
systems.  The
folks at Green Hills, Aonix, DDC-I, and Rational understand this, and they take 
a lot of
pride in the quality of their Ada products.  We can be thankful that, after the 
fall-out from
the abrogation of the DoD mandate, we are blessed with a group of companies who 
do
take their responsibilities for developing excellent software.  I apologize if I 
omitted any
of the other commecial Ada compiler publishers.  We already know about AdaCore, 
but
these other, less well-known, participants deserved acknowledgement from time to 
time.

Re: The future of Ada is at risk

[Phaedrus]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3520 bytes --]

Perhaps this isn't the right place to have this discussion, but since you 
mentioned it...

GPL software is just fine for two different groups, hobbyists and certain 
large corporations.  Hobbyists love it 'cause they don't have to worry about 
making a profit, and they love having leverage from ever-larger toolsets. 
(I'm in full agreement with them, btw.)

Certain large corporations love GPL software when it helps them to do 
internal-only development, and when they do development for the government. 
Either way, it's a net gain for them, it lowers costs AND they don't have to 
worry about other people taking over their market niche.

Now, consider a small to middle sized company.  The business model is either 
B2B with just a few customers, or B2C with (hopefully!) hundreds or even 
thousands of customers.  Two things allow these businesses to maintain their 
market position, the customer base (which can change overnight!) and the 
technical base.  If someone got a copy of their source code, then the 
company could be out of business overnight.

True, it's possible to sell GPL software, but then it's not really the 
software that you're selling.  It's other associated expertise.  But just 
imagine what would happen to Microsoft's Word profits if the source code 
suddenly made it's way into the public domain.  With that kind of software 
associated expertise isn't really a sellable item, and so profits from Word 
would evaporate.  I'm sure Microsoft would survive, but a little company 
wouldn't. And imagine trying to sell associated expertise for a game!  A new 
game company might be in a bad position with the current Ada situation, 
having to choose to make their game GPL (no profits) or choose to use a 
price-inflated compiler (up front costs).  But, once past that hurdle, Ada 
would be very suitable...  If only AdaCore would re-think that darn license 
or charge a reasonable amount, I'm convinced that the demand for Ada people 
would skyrocket!

In summary, by releasing software as GPL instead of just releasing it as 
free, all you've managed to do is make things nicer for hobbyists and the 
big guys.  Are you sure that is what you intended?

Brian

"Pascal Obry" <pascal@obry.net> wrote in message 
news:47775D59.3070002@obry.net...
> Phaedrus a �crit :
>> Just a few things will have to change before it's worth-while.  You're
>> right, only one real compiler exists and it's horribly expensive for
>> commercial work. (Isn't it interesting that they claim to only charge for
>> "support", but then force anyone who uses the free compiler to release 
>> their
>> developed software for free?  *sigh*)  Along that line, a lot of current 
>> Ada
>> packages have been infected with the dreaded GPL-itis. That make them
>> unusable for commercial stuff, too.  But mostly I think that it's the 
>> nature
>> of the mindset behind a lot of packages that would need to change. 
>> Getting
>> those 50 - 60Hz updates isn't easy!
>
> Sorry but this is full non-sense. You oppose GPL and commercial but it
> is just ok to have a commercial GPL software.
>
> 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 

Re: The future of Ada is at risk

[Phaedrus]

>> Just a few things will have to change before it's worth-while.
>
> Which ones?
1. Cheaper development environment for non-GPL work.  If it's more expensive 
than Visual C++, then guess which one the pointy-haired managers and bean 
counters are gonna pick?

2. Packages that are suitable for non-academic work.  (I just know I'll 
catch a flame or two for this one.)  Many packages are released which will 
work just fine in a non-realtime environment, but are a little too "safe" to 
use in a commercial environment.  (Joke: What do you call an 
information-hiding hammer?  A pillow.)  For instance, once upon a time I was 
looking for a good bitmap package for Ada.  One I looked at had a very nice 
set of operations, with Get_Bitmap, Save_Bitmap operations.  However, I 
needed access to the data, and the ONLY access to the data that was provided 
was ONE PIXEL AT A TIME.  Sure, I could have re-written it, but then I 
started wondering, why would someone want to load and save bitmaps without 
accessing the data?  It didn't even give access to the address of the first 
pixel!

Okay, enough rant on that.

3. More libraries such as Gwindows.  I really can't say enough good things 
about it, it's useful, well written and really free!  David Botton and 
others have done an incredible job with this library, and it can even be 
used for commercial work.

> Yeah, these days there is little you get for nothing.
I disagree, see item 3.  There are many other examples too, just check out 
Pascal's site, and some of the other Ada sites.  These things are like 
finding gold on your doorstep!

Cheers!
Brian
"Georg Bauhaus" <rm.tsoh+bauhaus@maps.futureapps.de> wrote in message 
news:47777c46$0$16665$9b4e6d93@newsspool3.arcor-online.net...
> Phaedrus wrote:
>
>> Remember, the game market is a lot bigger than the old military market 
>> ever was.
>>
>> Just a few things will have to change before it's worth-while.
>
> Which ones?
>
>>  You're right, only one real compiler exists and it's horribly expensive 
>> for commercial work.
>
> I'm working with another compiler and tools, but indeed,
> software has something unreal.
>
> Not sure how those other Ada businesses are providing
> their unreal tools.
>
>> (Isn't it interesting that they claim to only charge for "support", but 
>> then force anyone who uses the free compiler to release their developed 
>> software for free?  *sigh*)  Along that line, a lot of current Ada 
>> packages have been infected with the dreaded GPL-itis. That make them 
>> unusable for commercial stuff, too.
>
> Yeah, these days there is little you get for nothing. 

Re: The future of Ada is at risk

[Brian May]

>>>>> "Phaedrus" == Phaedrus  <phaedrusalt@hotmail.com> writes:

    Phaedrus> [...] But just imagine what would happen to Microsoft's
    Phaedrus> Word profits if the source code suddenly made it's way
    Phaedrus> into the public domain.  [...]

Need to watch your language here. "public domain" means all rights
have been given away, and GPL code does not give away all rights.

Also, it is not entirely obvious that profits would go down if the
source code was available. Microsoft would not longer need to pay
lawyer's fees or advertising campaigns against "software pirates".
Programmers outside Microsoft would be able to solve bugs which
Microsoft aren't interested in solving (sometimes this involves
security issues). People would still pay Microsoft for support.

Having said that, it would require a major culture shift, and I don't
see this happening any time soon.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: The future of Ada is at risk

[Simon Wright]

okellogg <okellogg@freenet.de> writes:

> On Dec 30, 1:30 pm, Florian Weimer <f...@deneb.enyo.de> wrote:
>>    [...] My impression that most commercial GNAT users do not use
>> tasking, or use it on freestanding implementations (that is, not
>> GNU/Linux).
>
> I've been porting a large application (several 100000 executable
> LOC) to to GNU/Linux with FSF gcc-4.2.1. The program had over 300
> tasks, all statically allocated. Basically the entire program was
> running during elaboration. The problems with elaboration order and
> task stacks all went away "magically" after changing the tasks to
> task types/access-to-task objects and explicit Init procedures for
> allocating the task objects from the main program.

Statically allocated library level tasks are the canonical way of
getting elaboration order problems with GNAT! I wouldn't have thought
task stack overruns would be affected,though ...

Re: The future of Ada is at risk

[Phaedrus]

No need to watch my language there.  As far as the individual user is 
concerned, GPL and "public domain" mean the same thing, Microsoft won't 
receive a dime for it's use.

Interesting.  Would you, personally, pay Microsoft for support?  Would you 
pay for the product if it were available for free?  True, they wouldn't have 
to pay to protect a product that had already been given away, but that kind 
of savings rings a little hollow when you don't have the profits to offset.

When true market niches exist a new predator usually evolves to take 
advantage of them.  The lack of unicorn-eaters is a good indicator of a lack 
of unicorns.  More to the point, I won't be taking my company into game 
development until the niche is profitable, and that will mean non-GPL.

But feel free to go unicorn-hunting if it makes you happy.

Brian

"Brian May" <bam@snoopy.apana.org.au> wrote in message 
news:sa4fxxjg4qy.fsf@snoopy.microcomaustralia.com.au...
>>>>>> "Phaedrus" == Phaedrus  <phaedrusalt@hotmail.com> writes:
>
>    Phaedrus> [...] But just imagine what would happen to Microsoft's
>    Phaedrus> Word profits if the source code suddenly made it's way
>    Phaedrus> into the public domain.  [...]
>
> Need to watch your language here. "public domain" means all rights
> have been given away, and GPL code does not give away all rights.
>
> Also, it is not entirely obvious that profits would go down if the
> source code was available. Microsoft would not longer need to pay
> lawyer's fees or advertising campaigns against "software pirates".
> Programmers outside Microsoft would be able to solve bugs which
> Microsoft aren't interested in solving (sometimes this involves
> security issues). People would still pay Microsoft for support.
>
> Having said that, it would require a major culture shift, and I don't
> see this happening any time soon.
> -- 
> Brian May <bam@snoopy.apana.org.au> 

Re: The future of Ada is at risk

[Phaedrus]

> I think it is not "before Ada is really practical," but before the Ada 
> compilers,
> libraries, and toolsets are ready.  As a language design, Ada is certainly 
> ready.
> The availability of additional libraries and tools has delayed its 
> acceptance in
> the larger community.  This is a kind of "chicken and egg" thing.

It's kind of hard to market a game done in a "language design".  Ada isn't 
practical for this marketplace (the game market) until a coherent whole is 
available, and at the right price-point.  No chickens or eggs needed, but 
certain libraries/packages are a necessity.

> for it.  Under the current model, the DoD contractors are making all the 
> decisions, and there
> is a chance that those decisions are made in the best interest of their 
> own corporate future
> -- and economic self-interest.   This is not to suggest they are 
> dishonest.

I would suggest that putting self-interest ahead of customer's best 
interests IS dishonest.  Choosing the wrong toolset for the job because it 
will produce higher profits (via longer hours, more time spent coding, more 
time spent debugging, etc) is at best a little naughty, and certainly 
shouldn't be described as honest.

Brian

Re: The future of Ada is at risk

[Samuel Tardieu]

>>>>> "Florian" == Florian Weimer <fw@deneb.enyo.de> writes:

Florian> FSF GCC is not commercially relevant. 8-) Its users' demands
Florian> have little influence on GNAT development, as far as I can
Florian> tell.

During the last two months, I took on my free time to fix some bugs in
FSF GNAT. AdaCore was very reactive in assisting me, reviewing the
proposed fixes, testing them using their own regression test suite and
modifying them when needed.

As a company, AdaCore will not fix bugs reported by non-customers
before doing what they have to do for their customers. But they do
invest resources in helping people *fix* bugs in the public version.

The way to influence FSF GNAT development is to *do* it :)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: The future of Ada is at risk

[Samuel Tardieu]

>>>>> "Phaedrus" == Phaedrus  <phaedrusalt@hotmail.com> writes:

Phaedrus> Isn't it interesting that they claim to only charge for
Phaedrus> "support", but then force anyone who uses the free compiler
Phaedrus> to release their developed software for free?  *sigh*

You're confusing GNAT with AdaCore here. And AdaCore doesn't own GNAT.

GNAT is part of GCC and available from the Free Software
Foundation. With it, you can develop proprietary programs if you wish
to do so as its runtime uses the "GMGPL" (GNAT modified GPL)
license. The copyright holder of GNAT is the FSF.

AdaCore takes the FSF version of GNAT, enhances it and:

 1- releases a GMGPL version to its customers;
 2- releases a GPL-only public version;
 3- contributes back the changes to the FSF under the original license.

Any company or individual could do the same thing. Or do only 1 and
make no public version. Or do only 1 and 2, preventing the changes
from being integrated in the FSF GMGPL version. Only users choosing to
use the AdaCore GPL-only public version of GNAT are affected by the
runtime license and have to develop free software only.

Note that GNAT as found in GNU/Linux distribution such as Debian
usually comes from the FSF and are perfectly usable to develop
proprietary software.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: The future of Ada is at risk

[I. Levashew]

Florian Weimer wrote:
>> Seriously, by the count of installations, isn't the future of
>> *BSD at risk.
> 
> Unfortunately, one of our partner organizations is rather BSD-centric.
Well, at least FreeBSD (in contrast to Mac OS X) has Linux Binary 
Compatibility.

Re: The future of Ada is at risk

[Florian Weimer]

* I. Levashew:

> Florian Weimer wrote:
>>> Seriously, by the count of installations, isn't the future of
>>> *BSD at risk.
>>
>> Unfortunately, one of our partner organizations is rather BSD-centric.

> Well, at least FreeBSD (in contrast to Mac OS X) has Linux Binary
> Compatibility.

It doesn't support many modern syscalls (including the new threading
APIs), though.

Re: The future of Ada is at risk

[Rico Secada]

On Mon, 31 Dec 2007 14:12:02 +0600
"I. Levashew" <octagram@bluebottle.com> wrote:

> Florian Weimer wrote:
> >> Seriously, by the count of installations, isn't the future of
> >> *BSD at risk.

You have to be extremely ignorant to state something like that. 

What counts are you talking about?  

I have yet to see a major communications company who doesn't use BSD on
their servers.

> > Unfortunately, one of our partner organizations is rather
> > BSD-centric.
> Well, at least FreeBSD (in contrast to Mac OS X) has Linux Binary 
> Compatibility.

So does the other BSD's.

Re: The future of Ada is at risk

[Florian Weimer]

* Rico Secada:

>> Florian Weimer wrote:
>> >> Seriously, by the count of installations, isn't the future of
>> >> *BSD at risk.
>
> You have to be extremely ignorant to state something like that. 

For the record, I didn't say that.  (Yes, I know, it's possible to infer
that by counting ">" signs. *sigh*)

Re: The future of Ada is at risk

[I. Levashew]

Phaedrus wrote:
> And imagine trying to sell associated expertise for a game!  A new 
> game company might be in a bad position with the current Ada situation, 
> having to choose to make their game GPL (no profits)

There's no any big problem here. Games like Duke Nukem, Quake have their 
source available. It's already happened. But arts, sounds and levelsets 
by no any mean must be free for use and distribution. It is the most 
hard work in game creation. So the vendor still has the control.

I even think GPL game is benefittable. Game players tend to modify their 
game. I saw script compiler for GTA and many mods maid with it. I myself 
slightly tweaked Duke Nukem 3D's .con scripts. Just for fun. Releasing 
game as GPL will allow even more tricks than ever.

Releasing a game as GPL also means that somebody can make another 
levelsets and graphics and sell them instead of yours. Or not to sell. 
There are both free and not so free Total Conversions. OpenQuartz for 
Quake, FreeDoom for Doom are examples of creating free content. Why not? 
  It's not easy to replace everything. It anyway popularizes the 
original game.

 From another point of view one could make GPL game code better. Port it 
to another platform, enable anaglyph, make rendering work on a cluster, etc.

Personally I would like vendors to release GPL games even without 
AdaCore's restrictions.

The hardest part is proprietary physical engines which could not be 
released under GPL. As soon as game does not include such engines 
there's nothing to worry about.

Re: The future of Ada is at risk

[Georg Bauhaus]

On Mon, 2007-12-31 at 11:16 +0100, Rico Secada wrote:
> On Mon, 31 Dec 2007 14:12:02 +0600
> "I. Levashew" <octagram@bluebottle.com> wrote:
> 
> > Florian Weimer wrote:
> > >> Seriously, by the count of installations, isn't the future of
> > >> *BSD at risk.
> 
> You have to be extremely ignorant to state something like that. 
> 
> What counts are you talking about?  

PC OS share, number of *BSD workstations in tech companies, etc..

I don't doubt that (even outside Yahoo!) there are still some
machines that run FreeBSD and relatives for good reasons.
Could you point to up-to-date resources on BSD usage? Like,
"We, a major non-Yahoo! company, will extend our use of *BSD
driven computers because we think so-and-so"?

(The FreeBSD advocacy pages refer you to an installation
statistics site. By this, and by other equally vague sources
of information, Solaris, Linux, and Windows 2003, and lesser
known non-PC solutions seem to be the more frequent choices
of major sites connected to the net.
Obviously, this just shows what is reachable from outside,
but still...)

I notice that there are some single board computers for
use with firewall software, based on FreeBSD, good.
FreeBSD people seem to have taken pride in quality control.
So we could hope to have non-PC, non-mainframe, small computers
that would be a good match for what Ada is about.
OTOH, I see many hints to either proprietary OSs,
or Linux, for example in DSL boxes or mobile computers (phones,
navigation). Or Microsoft efforts to reduce Cost of Market
Entrance for mobile computing companies, and their generous
offerings for universities--having obvious consequences.

This is why I think that the future of *BSD is more "at risk"
than that of Ada. And for good or bad, that of GNAT on BSD.
Write a killer app and things will change.

Re: The future of Ada is at risk

[Paul]

Georg Bauhaus wrote:
> This is why I think that the future of *BSD is more "at risk"
> than that of Ada. And for good or bad, that of GNAT on BSD.

So you think BSD is dying,

And maybe Ada is not too far behind.

But if a step on a plane that is not
programmed in Ada, I wonder if I might
be dying.


Happy New Year Georg, and everyone else on this list.

Re: The future of Ada is at risk

[Florian Weimer]

* Georg Bauhaus:

> I don't doubt that (even outside Yahoo!) there are still some
> machines that run FreeBSD and relatives for good reasons.
> Could you point to up-to-date resources on BSD usage? Like,
> "We, a major non-Yahoo! company, will extend our use of *BSD
> driven computers because we think so-and-so"?

I guess for most shops, OS choice depends on available talent (unless
you're stuck with one of the obvious dead ends).

I think the main question regarding BSD's future is if it's inherently
necessary to keep up with the competitors' rate of change (a rate that
isn't necessarily a good thing in itself).  It could be that some real
kernel/low-level innovation is on the horizon affecting legacy systems,
but I doubt it; I don't buy into that multi-core mantra.  Beyond that,
you only need a rather smallish pool of developers who write drivers for
new hardware, or maintain existing to deal with new quirks.

Re: The future of Ada is at risk

[Gautier]

Rico Secada wrote on 29-Dec-2007:

> 2. Very few projects exists on Sourceforge and Freshmeat compared to
> other languages like C++, Java, Python and others.
> 
> Only 92 projects on Sourceforge.net and 57 on Freshmeat.net.

http://sourceforge.net/softwaremap/trove_list.php?form_cat=163

And 136 today...
This seems to make 44 new Ada projects in 3 days. That's not bad ;-)
Happy new year!
______________________________________________________________
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!

Re: The future of Ada is at risk

[Dmitry A. Kazakov]

On Tue, 01 Jan 2008 15:14:01 +0100, Gautier wrote:

> Rico Secada wrote on 29-Dec-2007:
> 
>> 2. Very few projects exists on Sourceforge and Freshmeat compared to
>> other languages like C++, Java, Python and others.
>> 
>> Only 92 projects on Sourceforge.net and 57 on Freshmeat.net.
> 
> http://sourceforge.net/softwaremap/trove_list.php?form_cat=163
> 
> And 136 today...
> This seems to make 44 new Ada projects in 3 days. That's not bad ;-)

and 64 (+7) Ada related projects on Freshmeat.net:

http://freshmeat.net/browse/163/

> Happy new year!

Same to all!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The future of Ada is at risk

[Colin Paul Gloster]

On Mon, 31 Dec 2007, I. Levashew wrote:

|--------------------------------------------------------------------------------|
|"Phaedrus wrote:                                                                |
|> And imagine trying to sell associated expertise for a game!  A new game       |
|> company might be in a bad position with the current Ada situation, having to  |
|> choose to make their game GPL (no profits)                                    |
|                                                                                |
|There's no any big problem here. Games like Duke Nukem, Quake have their source |
|available. It's already happened. But arts, sounds and levelsets by no any mean |
|must be free for use and distribution. It is the most hard work in game         |
|creation. So the vendor still has the control.                                  |
|                                                                                |
|[..]"                                                                           |
|--------------------------------------------------------------------------------|

The source code for Quake has been released long after Quake had been
originally available for sale. Perhaps this was also the case for Duke
Nukem or Duke Nukem 3D.

Re: The future of Ada is at risk

[Agyaras]

> The GNU GNAT Compiler is the only Open Source compiler, and
> it lacks proper support and implementation on a variety of platforms.
I can confirm this. E.g. it is a major headache to get the GNAT compiler 
working under Mac OS X. AdaCore stopped distributing GNAT/GPS (GPL) for 
the Mac. There has never been a GNAT/GPS package for Solaris AFAIK. 
etc.etc.

Ada and the Open Source community:- there are several problems.

1) Perception. Ada is still perceived as "the Pentagon language", and is 
associated in many people's minds with "evil". This perception is very 
difficult to change.
2) Complexity. Ada has been designed for large, complex, reliable 
software systems. Most open source projects are smaller and it is not 
worth the effort to use Ada: or would you use a tractor in your garden 
behind your house?
3) The quick-and-dirty mentality. This is very widespread in the current 
IT world. Deadline pressure leads to q&d coding, hence the popularity of 
dynamic script languages that promise rapid results. Goes completely 
against the Ada philosophy.
4) Ada limitations. Certain aspects of Ada are painfully clumsy. The 
three string libs, unnecessary multitude of I/O libs, primitive 
exception handling, constructors are not part of the language, 
finalization is an afterthought,....
5) Lack of libraries and frameworks. This is due to the unpopularity of 
the language. Ada needs at least a relational DB binding *that works* 
with the current open-source RDBMS-es (as opposed to Gnade), she needs a 
good scientific library, she needs simple but powerful string handling, 
just to name a few. The catch-22 is that nobody will develop these until 
there's strong demand for Ada-based s/w, and there won't be strong 
demand until the libs are available.

cheers,A

-- 
"Non est volentis, neque currentis, sed miserentis Dei"

Re: The future of Ada is at risk

[Pascal Obry]

Agyaras a �crit :
> Ada and the Open Source community:- there are several problems.

I'm really depressed by the comp.lang.ada messages those days!

> 1) Perception. Ada is still perceived as "the Pentagon language", and is 
> associated in many people's minds with "evil". This perception is very 
> difficult to change.

Ok.

> 2) Complexity. Ada has been designed for large, complex, reliable 
> software systems. Most open source projects are smaller and it is not 
> worth the effort to use Ada: or would you use a tractor in your garden 
> behind your house?

Plain wrong. I've done plenty of Open Source dev with Ada. Ada complex?
Well, this is the language used in many first year university! It is a
large language but you don't need the tasking in all projects and
certainly not all the annexes. C++ is probably lot more complex to get
right and there is far more C++ Open Source projects.

> 3) The quick-and-dirty mentality. This is very widespread in the current 
> IT world. Deadline pressure leads to q&d coding, hence the popularity of 
> dynamic script languages that promise rapid results. Goes completely 
> against the Ada philosophy.

Ok.

> 4) Ada limitations. Certain aspects of Ada are painfully clumsy. The 
> three string libs, unnecessary multitude of I/O libs, primitive 
> exception handling, constructors are not part of the language, 
> finalization is an afterthought,....

Don't see this as THE problem for Ada acceptance.

> 5) Lack of libraries and frameworks. This is due to the unpopularity of 
> the language. Ada needs at least a relational DB binding *that works* 
> with the current open-source RDBMS-es (as opposed to Gnade), she needs a 
> good scientific library, she needs simple but powerful string handling, 
> just to name a few. The catch-22 is that nobody will develop these until 
> there's strong demand for Ada-based s/w, and there won't be strong 
> demand until the libs are available.

What's wrong with GNADE? I've used it in many projects, no problem.

If hard to configure for you, look for gnadelite here:
http://repo.or.cz/ or contribute some useful piece of code to the GNADE
project.

You missed the most important point to me:

6) Lot of people are complaining about missing port and libraries but
very few step forward to do something useful for the community.

There are plenty of projects around to support Ada, like the FSF, the
Ada for Linux group. Why not jump into the wagon and try to get a decent
Mac OS-X port? I mean, there is work to be done and this work need some
task force somehow, it won't happen magically.

Sorry nothing personal, but we get so many messages listing the Ada
"problems" and so little active contribution!

Ada will be what we all do with it!

Best wishes for 2008.

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

Re: The future of Ada is at risk

[Georg Bauhaus]

On Fri, 2008-01-04 at 09:45 +0100, Agyaras wrote:
> > The GNU GNAT Compiler is the only Open Source compiler, and
> > it lacks proper support and implementation on a variety of platforms.
> I can confirm this. E.g. it is a major headache to get the GNAT compiler 
> working under Mac OS X.

What do you think of http://www.macada.org/ ?

What caused the headache?

>  AdaCore stopped distributing GNAT/GPS (GPL) for 
> the Mac.

Huh? It is still there (the 2006 edition), and support for the
later Intel based Macs is officially announced on the AdaCore
supported platforms page.


>  There has never been a GNAT/GPS package for Solaris AFAIK. 
> etc.etc.

Huh? Please, have a look. It is still there.

And what exactly is the "etc.etc." to imply?


> Ada and the Open Source community:- there are several problems.
> 
> 1) Perception.
Yes. 

> 2) Complexity.
Yes, but I doubt that the standard mode of OSS projects'
language choice is ever based on language complexity. The prove
should be obvious. C is chosen, and is probably a little
less comples than C++, chosen for OSS work, too. C has very
complex issues; some of them are buried in required compiler
documentation and machine idiosyncrasies. So what?

I'd rather say that more permissive lax languages
are preferred in non-.NET work, because they seem to
support the perception that you can get by even in the
long run. The translators will not remind you of typing
errors, dubious constructs, etc. (Witness perlcritic.)


> 3) The quick-and-dirty mentality.

This with 1), Perception. Indeed, Ada on Rails (as opposed
to GNAT on Rails) is not ready, although there are ingredients
(in particular for GNAT on Rails).

> 4) Ada limitations. Certain aspects of Ada are painfully clumsy.
Yes. The Ada 9X notes explain some of the dilemma.

> 5) Lack of libraries and frameworks. 

>  she needs simple but powerful string handling, 

I don't see how simple but powerful string handling
is missing with GNAT's SPITBOL support. You'd be forced to use
UTF-8 String, yes, but consider what the scripting languages
have to offer when it comes to UTF-8.

Even the String packages are full of useful algorithms and
data structures, even though there is no general character
type in Ada. (Will the engineers ever get this right?)
Cobol picture support adds to this.

I've looked at the latest "most powerful regex engine" added
to Ruby 1.9. And they want to tell the world that scripting
languages are easy? I don't see how there is any more power
in them than in SPITBOL patterns, and those are a lot easier
to read. (The SNOBOL4/SPITBOL motto, "Don't use pattern matching"
applies to scripting language embedded RE languages, and with
more emphasis, IMHO.)


> just to name a few. The catch-22 is that nobody will develop these until 
> there's strong demand for Ada-based s/w, and there won't be strong 
> demand until the libs are available.

OK, but who created the demand for Ruby libraries so that
there would be those who started it?

Re: The future of Ada is at risk

[Brian May]

>>>>> "Agyaras" == Agyaras  <agyaras@kerekerdoe.hu> writes:

    Agyaras> 1) Perception. Ada is still perceived as "the Pentagon language", and is 
    Agyaras> associated in many people's minds with "evil". This perception is very 
    Agyaras> difficult to change.

I don't see this myself (with perhaps one person who liked to attack
Ada for the sack of attacking Ada without understanding it); people I
talk to consider Ada obsolete, not evil.

    Agyaras> 4) Ada limitations. Certain aspects of Ada are painfully clumsy. The 
    Agyaras> three string libs, unnecessary multitude of I/O libs, primitive 
    Agyaras> exception handling, constructors are not part of the language, 
    Agyaras> finalization is an afterthought,....

A bigger issue (and a strength as well as a weakness) is that you have
to write code to Ada's strict standards. Programmers feel that this is
tedious, and that they loose "control". They just want to do "X"
without having Ada's rules get in the way.

Also, Ada is a compiled language. Many people feel this is a major
limitation these days, and argue that the ability to make fast changes
is absolutely vital to their project.

Not that I agree with these points of views, but they you can't just
discount them as stupid or ignorant either. People do consider them as
big issues.

    Agyaras> 5) Lack of libraries and frameworks. This is due to the unpopularity of 
    Agyaras> the language. Ada needs at least a relational DB binding *that works* 
    Agyaras> with the current open-source RDBMS-es (as opposed to Gnade), she needs a 
    Agyaras> good scientific library, she needs simple but powerful string handling, 
    Agyaras> just to name a few. The catch-22 is that nobody will develop these until 
    Agyaras> there's strong demand for Ada-based s/w, and there won't be strong 
    Agyaras> demand until the libs are available.

I take it that gnade has problems??

An issue here is that we don't really want 500 different competing DB
bindings. Ideally we want one DB binding that is considered the
standard set for Ada. It is easy to write a DB binding to make an
individual happy, but to write one that makes the majority of the Ada
community happy - that might be harder. Thick or thin? GPL or BSD?
Database independent layer? etc

Another issue, in order to attract people from other languages, we
really need their input in creating these standards. Otherwise they
will complain that our libraries are still insufficient in ways we
never considered and continue with what they are use to.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: The future of Ada is at risk

[Michael Bode]

Rico Secada <coolzone@it.dk> writes:


[...]

4. As long as you have to choose either program GPL code or pay like
you're Boeing there are quite a few developers for which Ada is no
option at all. They will buy Visual Studio or Delphi for at most a few
hundred $/ￜ or download j2sdk or Python for nothing and start coding.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: The future of Ada is at risk

[Ludovic Brenta]

Agyaras writes:
>> The GNU GNAT Compiler is the only Open Source compiler, and
>> it lacks proper support and implementation on a variety of platforms.
> I can confirm this. E.g. it is a major headache to get the GNAT compiler 
> working under Mac OS X. AdaCore stopped distributing GNAT/GPS (GPL) for 
> the Mac. There has never been a GNAT/GPS package for Solaris AFAIK. 
> etc.etc.
>
> Ada and the Open Source community:- there are several problems.
>
> 1) Perception. Ada is still perceived as "the Pentagon language",
> and is associated in many people's minds with "evil". This
> perception is very difficult to change.

Funny that TCP/IP was invented at DARPA where the D stands for
Defence.  Is TCP/IP widely considered evil?

> 2) Complexity. Ada has been designed for large, complex, reliable
> software systems. Most open source projects are smaller and it is
> not worth the effort to use Ada: or would you use a tractor in your
> garden behind your house?
> 3) The quick-and-dirty mentality. This is very widespread in the
> current IT world. Deadline pressure leads to q&d coding, hence the
> popularity of dynamic script languages that promise rapid
> results. Goes completely against the Ada philosophy.

I agree.  I think 2 and 3 are really one and the same.

> 4) Ada limitations. Certain aspects of Ada are painfully clumsy. The
> three string libs, unnecessary multitude of I/O libs, primitive
> exception handling, constructors are not part of the language,
> finalization is an afterthought,....

These can be explained with a simple philosophy: if you don't need
some feature, then Ada does not force you to pay the price for it.
That's why unbounded strings are not the same as simple or bounded
strings; that's why finalization is optional.

> 5) Lack of libraries and frameworks. This is due to the unpopularity
> of the language.  Ada needs at least a relational DB binding *that
> works* with the current open-source RDBMS-es (as opposed to Gnade),
> she needs a good scientific library, she needs simple but powerful
> string handling, just to name a few. The catch-22 is that nobody
> will develop these until there's strong demand for Ada-based s/w,
> and there won't be strong demand until the libs are available.

Luckily Ada also has a committed following that publishes open source
libraries from time to time.  I wish some of these libraries were
integrated into future revisions of the standard.  For example, I wish
the algorithms from Charles were part of the language.

-- 
Ludovic Brenta.

Re: The future of Ada is at risk

[Ludovic Brenta]

Michael Bode <m.g.bode@web.de> writes:
> Rico Secada <coolzone@it.dk> writes:
>
>
> [...]
>
> 4. As long as you have to choose either program GPL code or pay like
> you're Boeing there are quite a few developers for which Ada is no
> option at all. They will buy Visual Studio or Delphi for at most a few
> hundred $/€ or download j2sdk or Python for nothing and start coding.

That's not true.  You've been on this forum for quite some time now
and I am very surprised you still seem ignorant of Janus/Ada (295 USD
for Windows, with Claw); see
http://www.rrsoftware.com/html/companyinf/prices.htm).

-- 
Ludovic Brenta.

Re: The future of Ada is at risk

[Michael Bode]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> That's not true.  You've been on this forum for quite some time now
> and I am very surprised you still seem ignorant of Janus/Ada (295 USD
> for Windows, with Claw); see
  ^^^^^^^^^^^

This is not the only OS on the planet. Not even the only desktop
OS. I'm not aware of any development package that let's you develop
portable GUI apps for Windows, Linux and maybe OS X exept Gnat.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: The future of Ada is at risk

[Georg Bauhaus]

On Sat, 2008-01-05 at 11:30 +0100, Ludovic Brenta wrote:
> Michael Bode <m.g.bode@web.de> writes:
> > Rico Secada <coolzone@it.dk> writes:
> >
> >
> > [...]
> >
> > 4. As long as you have to choose either program GPL code or pay like
> > you're Boeing there are quite a few developers for which Ada is no
> > option at all. They will buy Visual Studio or Delphi for at most a few
> > hundred $/€ or download j2sdk or Python for nothing and start coding.
> 
> That's not true.  You've been on this forum for quite some time now
> and I am very surprised you still seem ignorant of Janus/Ada (295 USD
> for Windows, with Claw); see
> http://www.rrsoftware.com/html/companyinf/prices.htm).
> 

For those who have to write portable DB software,
and who for some reason must not disclose their software,
GNADE is not really an option because it is effectively written
in what might be called the GNAT language. It also uses 64bit
types. Therefore, GNADE cannot be used without changes with
other Ada compilers.
In this scenario, the GMGPL turns into the GPL.
No offence intended, I'm glad there is something up to date
for database programming, and there is no problem when 
source delivery is an option.

Re: The future of Ada is at risk

[Dmitry A. Kazakov]

On Sat, 05 Jan 2008 12:11:46 +0100, Georg Bauhaus wrote:

> For those who have to write portable DB software,
> and who for some reason must not disclose their software,
> GNADE is not really an option because it is effectively written
> in what might be called the GNAT language.

I think that can be fixed.

> It also uses 64bit types.

Hmm, how would you deal with SQLBIGINT otherwise?

> Therefore, GNADE cannot be used without changes with
> other Ada compilers.

The actual problem is that GNADE binary releases were not updated since
years. The working version is available only in CVS sources, which is a
non-starter for most users.

My problem with available Ada DB-bindings is that they pursue a philosophy
alien to Ada. Rather than to describe a DB in a higher-level way
independently on the target DB, they try to stay as DB-close as possible.
It is not Ada way, and it is simple impossible to do considering the number
of different DB engines available on the market. I do understand that DB
users are usually vendor-locked and want to extract every ms of performance
from poorly functioning engines, but again it is not in Ada philosophy.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The future of Ada is at risk

[Ludovic Brenta]

Michael Bode writes:
> Ludovic Brenta writes:
>
>> That's not true.  You've been on this forum for quite some time now
>> and I am very surprised you still seem ignorant of Janus/Ada (295 USD
>> for Windows, with Claw); see
>   ^^^^^^^^^^^
>
> This is not the only OS on the planet. Not even the only desktop
> OS. I'm not aware of any development package that let's you develop
> portable GUI apps for Windows, Linux and maybe OS X exept Gnat.

Then maybe you can go out and fill that niche.  Take GCC from the FSF
and write a good portable GUI library.  License it under whatever
terms you like, and make money.  Your complaining will not improve the
situation you complain about; your actions might.

-- 
Ludovic Brenta.

Re: The future of Ada is at risk

[Georg Bauhaus]

On Sat, 2008-01-05 at 12:40 +0100, Dmitry A. Kazakov wrote:
> On Sat, 05 Jan 2008 12:11:46 +0100, Georg Bauhaus wrote:
> 
> > For those who have to write portable DB software,
> > and who for some reason must not disclose their software,
> > GNADE is not really an option because it is effectively written
> > in what might be called the GNAT language.
> 
> I think that can be fixed.

Yes. I'm not that sure this is what is wanted...

> > It also uses 64bit types.
> 
> Hmm, how would you deal with SQLBIGINT otherwise?

Using a Big_Integer type corresponding to the DB's big integers
and make SQLBIGINT correspond to this type.
Not straight forward, not nice, not easy, but not impossible.
The GMP library might be of use in several ways.

Currently we have

 type SQLBIGINT    is range -(2 ** 63) .. +(2 ** 63) - 1;
 for SQLBIGINT'Size use 64;

We'd need an alternative user defined type that provides the
integer operations and that can be input from and output to the
DB in the same way.


>  that they pursue a philosophy
> alien to Ada. Rather than to describe a DB in a higher-level way
> independently on the target DB, they try to stay as DB-close as possible.

What would be the higher level? GNADE includes embedded SQL.
While that's not DBI or LINQ, it still offers a nice integration
and is pretty standard.

OTOH, I trust that DBI or JDBC might win a popularity contest.
Or something like SOCI ;-)

Even more higher level bindings hiding the SQL nature
of DB do what they promise. Not what I want because while they offer
high level abstractions, the high level abstractions
should be be problem domain abstractions, not database
abstractions. 

Hypothesis: The more magic is put in the layer above the high
level language SQL, the more difficult it is to actually use
that language, hiding all advantages of SQL[*].

[*] Actually, if you use one of the CRUD frameworks and you
want the effect of an "advanced" SQL command (JOIN, sub-SELECT,
etc.), chances you'll find yourself writing high level SQL
at the low level of the framework...

Re: The future of Ada is at risk

[Michael Bode]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Then maybe you can go out and fill that niche.  Take GCC from the FSF
> and write a good portable GUI library.  License it under whatever
> terms you like, and make money.  Your complaining will not improve the
> situation you complain about; your actions might.

I'm not complaining. I'm just giving my view on the topic. And thank
you, I'm making money in my day job. And in this job (which has
nothing to do with defense or aerospace) it's more economical to write
future apps in Java than to roll my own GUI library. This might be
another anecdotical example on the topic.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: The future of Ada is at risk

[Dmitry A. Kazakov]

On Sat, 05 Jan 2008 14:29:11 +0100, Georg Bauhaus wrote:

> On Sat, 2008-01-05 at 12:40 +0100, Dmitry A. Kazakov wrote:

>>  that they pursue a philosophy
>> alien to Ada. Rather than to describe a DB in a higher-level way
>> independently on the target DB, they try to stay as DB-close as possible.
> 
> What would be the higher level? GNADE includes embedded SQL.

Higher than ODBC and properly done. There must be no traces of SQL, pure
relational algebra specified in Ada types, plus connection and transaction
support. I would also like to have non-relational DB support.

> Even more higher level bindings hiding the SQL nature
> of DB do what they promise. Not what I want because while they offer
> high level abstractions, the high level abstractions
> should be be problem domain abstractions, not database
> abstractions. 

Sorry, I never could understand this argument. DB has no merits of its own.
It is a tool.

Hitting nails forget about whatever abstraction the hammer has. Otherwise,
you might hit your finger...

> Hypothesis: The more magic is put in the layer above the high
> level language SQL, the more difficult it is to actually use
> that language, hiding all advantages of SQL[*].

Advantages of SQL? Over what? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The future of Ada is at risk

[Robert A Duff]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Agyaras writes:
>> 4) Ada limitations. Certain aspects of Ada are painfully clumsy. The
>> three string libs, unnecessary multitude of I/O libs, primitive
>> exception handling, constructors are not part of the language,
>> finalization is an afterthought,....
>
> These can be explained with a simple philosophy: if you don't need
> some feature, then Ada does not force you to pay the price for it.
> That's why unbounded strings are not the same as simple or bounded
> strings; that's why finalization is optional.

Well, it explains why unbounded strings are different from fixed-length
strings.  It does not explain why unbounded strings use such painful
syntax.

The complaint about exceptions is valid.

I don't understand the complaint about constructors -- Ada 2005 is
pretty good in this area (better than C++, IMHO).

I'm not sure I understand the finalization issue.  Yes, of course it's
optional, as you explained.  But Agyaras complains that it's an
"afterthought".  Is the problem that Finalize doesn't automatically
invoke the parent's Finalize?  Or something else?

- Bob

Re: The future of Ada is at risk

[Dmitry A. Kazakov]

On Sat, 05 Jan 2008 10:16:00 -0500, Robert A Duff wrote:

> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
> 
>> Agyaras writes:
>>> 4) Ada limitations. Certain aspects of Ada are painfully clumsy. The
>>> three string libs, unnecessary multitude of I/O libs, primitive
>>> exception handling, constructors are not part of the language,
>>> finalization is an afterthought,....
>>
>> These can be explained with a simple philosophy: if you don't need
>> some feature, then Ada does not force you to pay the price for it.
>> That's why unbounded strings are not the same as simple or bounded
>> strings; that's why finalization is optional.
> 
> Well, it explains why unbounded strings are different from fixed-length
> strings.  It does not explain why unbounded strings use such painful
> syntax.

Right.

> The complaint about exceptions is valid.

Yes, it could be better. Though I don't think that exceptions should of any
type as they are in C++. I would prefer a private type with ordered values
and some mechanism for additional parameters passing, maybe
rendezvous-like.

> I don't understand the complaint about constructors -- Ada 2005 is
> pretty good in this area (better than C++, IMHO).

People complain that there is no user-defined initialization, safe, and for
all types. (Ada.Finalization hack does not count.)

> I'm not sure I understand the finalization issue.

Same as initialization.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The future of Ada is at risk

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 05 Jan 2008 10:16:00 -0500, Robert A Duff wrote:
>> The complaint about exceptions is valid.
>
> Yes, it could be better. Though I don't think that exceptions should of any
> type as they are in C++.

Yes, I agree.

>> I don't understand the complaint about constructors -- Ada 2005 is
>> pretty good in this area (better than C++, IMHO).
>
> People complain that there is no user-defined initialization, safe, and for
> all types. (Ada.Finalization hack does not count.)

What's wrong with initializing objects with function calls?
It has advantages over the C++ way, and I don't see the
disadvantage(s).

>> I'm not sure I understand the finalization issue.
>
> Same as initialization.

I don't get it.

- Bob

Re: The future of Ada is at risk

[Georg Bauhaus]

On Sat, 2008-01-05 at 10:46 -0500, Robert A Duff wrote:

> What's wrong with initializing objects with function calls?
> It has advantages over the C++ way, and I don't see the
> disadvantage(s).
> 
> >> I'm not sure I understand the finalization issue.
> >
> > Same as initialization.
> 
> I don't get it.

A brief characterization of buyers over here explained
it to me:

  "The Germans will more likely buy a certain phone
(TV set, OO programming set) if it has at least the
multitude of technical features as the one X has bought.
X is a relevant Other to whose gadget Ego's gadget will
be compared."

Ada advocates might have something up their sleeves, though:
simplicity through construction being built in,
smooth integration, no need because everything is
already there.  This is why the "Object Orientation" section
in the WiKi book tries to emphasize that in a sense there is
nothing special about OO object creation.

Re: The future of Ada is at risk

[Dmitry A. Kazakov]

On Sat, 05 Jan 2008 10:46:23 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>> I don't understand the complaint about constructors -- Ada 2005 is
>>> pretty good in this area (better than C++, IMHO).
>>
>> People complain that there is no user-defined initialization, safe, and for
>> all types. (Ada.Finalization hack does not count.)
> 
> What's wrong with initializing objects with function calls?

Ada lacks extensible functions. The predefined constructing function are
anonymous. They cannot be made abstract, private or hidden by other means.
So overriding/overloading of constructing functions is unsafe, it leaks.

> It has advantages over the C++ way, and I don't see the
> disadvantage(s).

I think that C++ model is more in Ada spirit, because it does not assume
more than absolutely necessary about constructed objects. With functions
you have to be able to return the object, which should be constructed
before ... its construction and returned before it exists, being neither
allocated, nor copied. It is a misuse of otherwise clean concept of a
function with a return parameter. Say I want to construct a task, why
should I invent "aggregates of tasks" in order to be able to "return" one
from a "constructing function"? Functions compose in absolutely different
manner than initializers do. So you need brackets like aggregates and weird
scoped return statements to put around in order to glue them. It is just
counterintuitive.

>>> I'm not sure I understand the finalization issue.
>>
>> Same as initialization.
> 
> I don't get it.

How to enforce execution of my code on say an access type, when the pointer
object gets destroyed?

(What is an inverse for function? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The future of Ada is at risk

[Georg Bauhaus]

On Sat, 2008-01-05 at 15:35 +0100, Dmitry A. Kazakov wrote:

> > Even more higher level bindings hiding the SQL nature
> > of DB do what they promise. Not what I want because while they offer
> > high level abstractions, the high level abstractions
> > should be be problem domain abstractions, not database
> > abstractions. 
> 
> Sorry, I never could understand this argument. DB has no merits of its own.
> It is a tool.

To me, a DB management system is an essential part of the operating
system. Just like a file system, only an RDBMS has more to offer.


> > Hypothesis: The more magic is put in the layer above the high
> > level language SQL, the more difficult it is to actually use
> > that language, hiding all advantages of SQL[*].
> 
> Advantages of SQL? Over what? (:-))

Advantages of SQL over fiddling with semi-successful reinventions
of somehow relational not-really-algebras in programming languages
that academic theses tend to produce. (Yes, OK, at least there is
something for the respective pet language.)

When I use SQL it is when the programs perform one of the most important
things that computers are doing: input and output. I/O and associated
calculations must be efficient, due to timing constraints. When tables
have between 200 and 65_000_000 rows then doing the most natural join
over three tables is just not meeting the specifications of both the
machine and the time on the wall clock.

A relational approach lives in its super-size infinitesimal response
time world. I don't and the servers don't either. Therefore, I need
access to the  RDMS in a transparent way, without having to go through
a chain of implications that a non-SQL better-than-SQL Ada type set
offers behind the scene. I need to work behind the scene.

In case you find a way to represent a better relational algebra
in Ada types, I'll be happy to join your newly founded DB company
operating the coffee machines or whatever is needed. ;-)

Re: The future of Ada is at risk

[Dmitry A. Kazakov]

On Sat, 05 Jan 2008 18:42:24 +0100, Georg Bauhaus wrote:

> On Sat, 2008-01-05 at 15:35 +0100, Dmitry A. Kazakov wrote:
> 
> To me, a DB management system is an essential part of the operating
> system. Just like a file system, only an RDBMS has more to offer.

The word is "persistence." Yes it is a function of OS to provide a scope
for applications, and a scope for the former scope which is traditionally
called file system. All that an application may want is to reach that
scope.

>>> Hypothesis: The more magic is put in the layer above the high
>>> level language SQL, the more difficult it is to actually use
>>> that language, hiding all advantages of SQL[*].
>> 
>> Advantages of SQL? Over what? (:-))
> 
> Advantages of SQL over fiddling with semi-successful reinventions
> of somehow relational not-really-algebras in programming languages
> that academic theses tend to produce. (Yes, OK, at least there is
> something for the respective pet language.)

Huh, SQL is neither quite relational, nor properly typed, nor portable, nor
standardized (as we, Ada people used to understand it). And, actually, SQL
is a language, so if you are looking for its advantages ... then they must
be over Ada! (:-))

If rather bindings are in question, then it is Interfaces.DB.Relational vs.
Interfaces.DB.SQL. I vote for the former.

> Therefore, I need
> access to the  RDMS in a transparent way, without having to go through
> a chain of implications that a non-SQL better-than-SQL Ada type set
> offers behind the scene. I need to work behind the scene.

How SQL should help you here? Note that people want DBMS-specific bindings
exactly because SQL and relational algebra fail to deliver needed
performance and scalability. What happens if you need the id of an inserted
row? What has row id to do with RA at all?

> In case you find a way to represent a better relational algebra
> in Ada types, I'll be happy to join your newly founded DB company
> operating the coffee machines or whatever is needed. ;-)

(:-))

First we need bindings to the existing mess...

Second, the typical scenario of DBMS choice is as follows. Before the
project start, the customer decides to use Oracle (that is not discussed).
Within next two weeks he switches to MS SQL server. And finally, the
project is delivered under MS-Access... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The future of Ada is at risk

[Jeffrey R. Carter]

Michael Bode wrote:
> 
> 4. As long as you have to choose either program GPL code or pay like
> you're Boeing there are quite a few developers for which Ada is no
> option at all. They will buy Visual Studio or Delphi for at most a few
> hundred $/ￜ or download j2sdk or Python for nothing and start coding.

Ludovic Brenta replied:

> That's not true.  You've been on this forum for quite some time now
> and I am very surprised you still seem ignorant of Janus/Ada (295 USD
> for Windows, with Claw); see
> http://www.rrsoftware.com/html/companyinf/prices.htm).

and Michael Bode re-replied:

> This is not the only OS on the planet. Not even the only desktop
> OS. I'm not aware of any development package that let's you develop
> portable GUI apps for Windows, Linux and maybe OS X exept Gnat.

Let's see: Visual Studio or Delphi, which are Windows only, are acceptable, but 
Janus Ada is not because it's Windows only.

There's also Object Ada, which like Janus Ada competes with Visual Studio and 
Delphi in the Windows area, and the FSF version of GNAT, which is available for 
a number of platforms.

-- 
Jeff Carter
"If a sperm is wasted, God gets quite irate."
Monty Python's the Meaning of Life
56

Re: The future of Ada is at risk

[Jeffrey R. Carter]

Michael Bode wrote:
> 
> I'm not complaining. I'm just giving my view on the topic. And thank
> you, I'm making money in my day job. And in this job (which has
> nothing to do with defense or aerospace) it's more economical to write
> future apps in Java than to roll my own GUI library. This might be
> another anecdotical example on the topic.

I suspect your total life-cycle costs are greater using Java than using Ada, 
even with your own GUI library.

-- 
Jeff Carter
"If a sperm is wasted, God gets quite irate."
Monty Python's the Meaning of Life
56

Re: The future of Ada is at risk

[Michael Bode]

"Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> writes:

> Let's see: Visual Studio or Delphi, which are Windows only, are
> acceptable, but Janus Ada is not because it's Windows only.

They are not acceptable if I want to develope portable apps. I gave
other examples that are. Except maybe that you can develope Mono apps
that can be compiled with VS .NET on Windows. Not that I would like to
rely on Mono when Microsoft plays their patent cards.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: The future of Ada is at risk

[Georg Bauhaus]

On Sat, 2008-01-05 at 21:52 +0100, Michael Bode wrote:
>  Except maybe that you can develope Mono apps
> that can be compiled with VS .NET on Windows. Not that I would like to
> rely on Mono when Microsoft plays their patent cards.

This nicely states that developing Mono apps is
a one way option. Yes, anything else would surprise me.

Re: The future of Ada is at risk

[Michael Bode]

"Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> writes:

> I suspect your total life-cycle costs are greater using Java than
> using Ada, even with your own GUI library.

I doubt that. And the short term cost is sure lower. And I know what my
boss will tell me.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: The future of Ada is at risk

[Jeffrey R. Carter]

Michael Bode wrote:
> 
> I doubt that. And the short term cost is sure lower. And I know what my
> boss will tell me.

Where we have hard data, they show that both the short- and long-term costs of 
Ada are less than the same project undertaken in another language, so it's up to 
you to prove otherwise.

-- 
Jeff Carter
"If a sperm is wasted, God gets quite irate."
Monty Python's the Meaning of Life
56

Re: The future of Ada is at risk

[Jeffrey R. Carter]

Michael Bode wrote:
> 
> They are not acceptable if I want to develope portable apps. I gave
> other examples that are. Except maybe that you can develope Mono apps
> that can be compiled with VS .NET on Windows. Not that I would like to
> rely on Mono when Microsoft plays their patent cards.

Changing the topic when your point is refuted is not going to convince anyone 
worth convincing.

-- 
Jeff Carter
"If a sperm is wasted, God gets quite irate."
Monty Python's the Meaning of Life
56

Re: The future of Ada is at risk

[Brian May]

>>>>> "Dmitry" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:

    Dmitry> Higher than ODBC and properly done. There must be no traces of SQL, pure
    Dmitry> relational algebra specified in Ada types, plus connection and transaction
    Dmitry> support. I would also like to have non-relational DB support.

I don't know if this would work in a compiled language like Ada, but I
really like the ideas used in Django (Python):

http://www.djangoproject.com/documentation/model-api/

You create a Python class, using specialised types for fields, and
they get mapped to database tables and columns. No need to use SQL,
although you can if you really have to for some reason. As such, it
really is database independent.

The biggest issue I see with it is they don't yet have any
infrastructure to handle schema updates automatically in a database
independent manner. I have seen rumours they are looking into solving
this though.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: The future of Ada is at risk

[Vadim Godunko]

On Jan 6, 2:47 am, Brian May <b...@snoopy.apana.org.au> wrote:
> >>>>> "Dmitry" == Dmitry A Kazakov <mail...@dmitry-kazakov.de> writes:
>
>     Dmitry> Higher than ODBC and properly done. There must be no traces of SQL, pure
>     Dmitry> relational algebra specified in Ada types, plus connection and transaction
>     Dmitry> support. I would also like to have non-relational DB support.
>
> I don't know if this would work in a compiled language like Ada, but I
> really like the ideas used in Django (Python):
>
> http://www.djangoproject.com/documentation/model-api/
>
> You create a Python class, using specialised types for fields, and
> they get mapped to database tables and columns. No need to use SQL,
> although you can if you really have to for some reason. As such, it
> really is database independent.
>
I like ideas of Hibernate:

http://www.hibernate.org/

Unfortunately without garbage collector this is very hard to implement
and use :-(

Re: The future of Ada is at risk

[Dmitry A. Kazakov]

On Sun, 06 Jan 2008 10:47:09 +1100, Brian May wrote:

>>>>>> "Dmitry" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>     Dmitry> Higher than ODBC and properly done. There must be no traces of SQL, pure
>     Dmitry> relational algebra specified in Ada types, plus connection and transaction
>     Dmitry> support. I would also like to have non-relational DB support.
> 
> I don't know if this would work in a compiled language like Ada, but I
> really like the ideas used in Django (Python):
> 
> http://www.djangoproject.com/documentation/model-api/
> 
> You create a Python class, using specialised types for fields, and
> they get mapped to database tables and columns. No need to use SQL,
> although you can if you really have to for some reason. As such, it
> really is database independent.

Yes, that looks pretty much like it should be, IMO.

[ I think that the issue with static typing can be resolved. Of course the
best way would be a support for anonymous record types (tuples). But there
exist also possibilities to use generics or else to have abstract base
tagged types for cells.]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The future of Ada is at risk

[Pascal Obry]

Brian May a �crit :
> I don't know if this would work in a compiled language like Ada, but I
> really like the ideas used in Django (Python):

I did lot of SQL programing in Ada. I would be surprised that such 
framework is versatile enough to give good performances on large SQL 
join requests! Of course I'll be glad to be proved wrong!

Mapping SQL and forms automatically works fine for simple tasks (like 
building a blog) but passed that I have yet to see something that works 
fine. Again I'll be glad to be proved wrong!

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

Re: The future of Ada is at risk

[Agyaras]

In article <1199452391.7932.27.camel@K72>,
 Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de> wrote:

> > I can confirm this. E.g. it is a major headache to get the GNAT compiler 
> > working under Mac OS X.
> 
> What do you think of http://www.macada.org/ ?

Yes, I know the site, and have downloaded the FSF gcc4.3 version from 
there ( both PPC and Intel). The problem is that this gcc sometimes 
cannot compile packages the "official" Apple gcc can. So one has to 
switch back and forth, using gcc4.3 for Ada work and the Apple gcc for 
other work (e.g. C++). This is probably Apple's fault though.

> >  AdaCore stopped distributing GNAT/GPS (GPL) for 
> > the Mac.
> 
> Huh? It is still there (the 2006 edition)
That is PowerPC only, based on gcc 3.4, with incomplete Ada2005 support. 
It would be nice to have GPS for Intel Macs, gcc4.2 at least, with 
complete Ada2005 support. I tried to compile GPS from the Linux sources 
(2007 edition) on the Mac and it turned to be very time-consuming, 
because GPS needs lots of libraries that in turn needed more 
libraries... finally I gave up, after I asked on this newsgroup and 
people told me that it was really difficult to do... but maybe the good 
folks at AdaCore have the proper setup and the know-how to do it.

> , and support for the
> later Intel based Macs is officially announced on the AdaCore
> supported platforms page.
I was perhaps not clear on this: I am missing the **GPL** editions of 
GNAT **and** the GPS IDE for a number of platforms. In 2007 the GPL-ed 
GNAT+GPS packages are available for Windows and 32-bit/64-bit Linux 
only. I cannot afford the license costs.

> >  There has never been a GNAT/GPS package for Solaris AFAIK. 
> > etc.etc.
> 
> Huh? Please, have a look. It is still there.
Sorry, I meant the **GPL** editions (see above).

IMHO it is absolutely necessary to provide freely available compilers 
and IDEs for as many platforms as possible to make a language popular. 
People should have the opportunity to "give Ada a spin" free of charge, 
even if they live outside the Intel X86/Windows/Linux galaxy.

GPS is great for learning Ada because you can "look" into the sources of 
the spec files of the standard library. It helped me a lot when I was 
learning the containers: John Barnes' otherwise excellent Ada2005 book 
is sometimes a bit tight-lipped on how these work.

> >  she needs simple but powerful string handling, 
> 
> I don't see how simple but powerful string handling
> is missing with GNAT's SPITBOL support. [...]
> Even the String packages are full of useful algorithms and
> data structures, even though there is no general character
> type in Ada.

The problem for many people starts earlier. Consider these two programs:-

-- Ada (221 chars)
with Ada.Strings.Unbounded, Ada.Text_IO.Unbounded_IO;
use Ada.Strings.Unbounded, Ada.Text_IO.Unbounded_IO;

procedure str is
   Strg: Unbounded_String := To_Unbounded_String("ergonomy");
begin
   Put_Line(Strg);
end str;

// C++ (148 chars)
#include <string>
#include <iostream>
using namespace std;

int main(int argc, char *argv[])
{
    string Strg("ergonomy");
    cout<<Strg<<endl;
}

The fact that the type of the string constant "ergonomy" is String 
requires the (semantically unnecessary) conversion To_Unbounded_String() 
in the Ada version. This is what I meant by clumsiness, not even 
mentioning the separate I/O library necessary to print this string 
afterwards. You don't really want to go through all these hoops just to 
print a string...

I think that the default string type should be the unbounded string, 
just like in C++, for ergonomic reasons. (Fixed strings may be needed in 
special cases. But the bounded string type family, where you have to 
convert from a 70-char string type to a 71-char string type, is an 
abomination and should be forgotten quickly.) And there should be only 
one I/O library, not dozens, otherwise programming ergonomics suffers, 
and that frightens people away. We should keep in mind that CPU time is 
cheaper than "brain time", so let the computer suffer a bit more 
instead. :-)

Talking about safety and ergonomics: how do you tell which Ada 
subprograms raise which exceptions? Well, you cannot. The Java designers 
got this absolutely right: the method signatures can contain a throws() 
clause. Either you catch an exception or let it propagate and the 
compiler complains if you omit the throws() in the latter case. It would 
be nice if the Ada2005 standard could be amended with a similar 
mechanism. If it can be done in Java, then it certainly could be done in 
Ada! :-)

"Make computers work so that humans won't have to"

A

-- 
"Non est volentis, neque currentis, sed miserentis Dei"

Re: The future of Ada is at risk

[Dmitry A. Kazakov]

On Sun, 06 Jan 2008 10:34:25 +0100, Agyaras wrote:

> I think that the default string type should be the unbounded string,

No, all string types should simply be subtypes of each other. In that case
you will need no conversions at all and no specialized library versions for
all geometrically exploding combinations of string types. The compiler
would convert representations where appropriate.

Same with Character vs. Wide_Character vs. Wide_Wide_Character.

BTW, if you look at use statistics of String vs. Unbounded_String you will
wonder how minor is use of Unbounded_String in Ada programs. Ada 83 string
design was extremely successful. You just do not need Unbounded_String in
most cases. The cases where Unbounded_String appears are rare and usually
at the language weakness points. For example, when you need to return two
strings out of one function. Another example is when you want to put string
into a record.

> Talking about safety and ergonomics: how do you tell which Ada 
> subprograms raise which exceptions?

True, exceptions should be contracted.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The future of Ada is at risk

[Michael Bode]

"Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> writes:

> Changing the topic when your point is refuted is not going to convince
> anyone worth convincing.

What is your problem? You can write programs in C# that run under Mono
or DotGNU in Linux and under .NET in Windows. If you want to write them on a
Windows machine you use VS and if you want to write on a Linux box you
use vi or whatever. So there is nothing refuted about VS. Delphi was a
bad example so discard that and take e.g. C++/Qt as another commercial
cross platform offering.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: The future of Ada is at risk

[Georg Bauhaus]

On Sun, 2008-01-06 at 10:34 +0100, Agyaras wrote:
> In article <1199452391.7932.27.camel@K72>,
>  Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de> wrote:

> > Huh? It is still there (the 2006 edition)
> That is PowerPC only, based on gcc 3.4, with incomplete Ada2005 support. 

OK, I understand that right after the publication
of the Amendment, a fully supporting Free Software
compiler is eagerly awaited for all computing hardware.

> It would be nice to have GPS for Intel Macs,

OK, GPS is not trivial. OTOH, I understand there is some
Xcode integration; Eclipse support is starting, too. Isn't this
more than can be had for a number of very popular languages?

> In 2007 the GPL-ed 
> GNAT+GPS packages are available for Windows and 32-bit/64-bit Linux 
> only. I cannot afford the license costs.

As always with Free Software, and with anything in general,
if there is not enough demand, developing Free Software
will not be based on demand. So if development happens, it must
be based on something else, like enthusiasm or someone
discovering a market niche, or someone perceives future ROI ...


> IMHO it is absolutely necessary to provide freely available compilers 
> and IDEs for as many platforms as possible to make a language popular.

Popular amongst who else? Windows, GNU/Linux, and Mac OS X together
do cover almost all personal computing needs. Another question
is whether a popularity attractor (famous person with fans) uses
something else and gains a following.


> GPS is great for learning Ada because you can "look" into the sources of 
> the spec files of the standard library. It helped me a lot when I was 
> learning the containers: John Barnes' otherwise excellent Ada2005 book 
> is sometimes a bit tight-lipped on how these work.

So we should probably add a note to the WiKi book explaining
just how you can "look" into the sources of files of the
standard library using any one of the freely available IDEs.
This is pretty much standard; it would be interesting to learn
how you could think otherwise.

> The problem for many people starts earlier. Consider these two programs:-
> 
> -- Ada (221 chars)

>    Strg: Unbounded_String := To_Unbounded_String("ergonomy");

> // C++ (148 chars)

>     string Strg("ergonomy");

(I notice that dynamic_cast<Foo>(expr) and static_cast<Bar>(expr)
are a lot better than the parenthetical type casts of the C tradition;
from a characters count point of view, Foo(expr) and Bar'(expr) are
shorter, though. ...)

The literals fallacy. Putting aside the missing true Character type
abstraction that creates the clumsiness of default Ada string literals.
I think that Ada is among the few languages that can make you see
how people mix up shortness and brevity. In general,

* shortness is very attractive to programmers.
* Brevity is an art that few have mastered.
* Shortness will drive programmers crazy when they have to understand
   a pre-deadline piece of code that is written short on words.
* Shortness is a tool in the hands of the cynical programmer.

Shortness takes revenge. The "Just Get Going" effect makes you
run; however, the important thing in the long run is whether or
not you will stumble. Shortness is "ergonomy" at the wrong task.
It flatters the lazy programmer, it helps in creating illusions.
It doesn't help with programming.

Brevity, on the other hand, is not as easy to measure.
Counting source code characters is not enough.
Take your average scripting language program written in an
"ergonomic" style. 

An example of popular ease. It might seem construed, but I have
seen this very frequently. Frighteningly often.

   variable->method(arg1, arg2->{_key_})
       if frobnicate->foobar(another[3]);

This is the increasingly popular conditional placed _after_
the thing which depends on the conditional.
The popularity seems to stem from the fact that, in natural
language, people sometimes put the conditional clause of a
sentence second.
 However, programming is not prose.

  if (frobnicate->foobar(another[3]))
  {
     variable->method(arg1, arg2->{_key_});
  }

Boah. This is too boring. I need to type more than is absolutely
necessary. Not ergonomic. It is not cool. Go away with you linear
reading rule that is built into that Ada language.

Similarly, Ada _is_ more verbose than C, also than C++ to some
extent. The language rules are stubborn here and there. (E.g.,
instantiation is always explicit; C++ lets you choose whether
or not you want to say which instance you want. I understand that
most C++ programmers prefer the omission.) Using a computer
is very helpful with producing the verbosity at little typing cost.
Type 'i' 'f' ' ' and your full conditional framework is there.
Saves keystrokes ergonomically.

> Talking about safety and ergonomics: how do you tell which Ada 
> subprograms raise which exceptions? Well, you cannot. The Java designers 
> got this absolutely right:

First, what is an exception? Does it raise an issue
with a program that cannot perform its job due to a bug,
or is an exception a signal that is another means of
control flow? I can't speak of absolute truths without
knowing answers to question like these.

Second, by throws clauses alone you won't find the spot where
the exception is actually thrown. And which. Only the stack trace
can tell, the throws clauses just make you follow possible
call chains. There are loads of them.

> "Make computers work so that humans won't have to"

This is not true for programmers. Though, learning how
to use a input devices can make them work less. 
Very humiliating because typewriting is not the great
work of a programmer. Isn't this telling?

Re: The future of Ada is at risk

[Georg Bauhaus]

On Sun, 2008-01-06 at 09:42 +0100, Dmitry A. Kazakov wrote:

> > http://www.djangoproject.com/documentation/model-api/
> > 

> Yes, that looks pretty much like it should be, IMO.

Did you notice that they provide anyone with direct access
to SQL in order to do non-trivial relational things? 

Re: The future of Ada is at risk

[Dmitry A. Kazakov]

On Sun, 06 Jan 2008 13:05:28 +0100, Georg Bauhaus wrote:

> On Sun, 2008-01-06 at 09:42 +0100, Dmitry A. Kazakov wrote:
> 
>>> http://www.djangoproject.com/documentation/model-api/
> 
>> Yes, that looks pretty much like it should be, IMO.
> 
> Did you notice that they provide anyone with direct access
> to SQL in order to do non-trivial relational things?

You can do assembler insertions in Ada. The relation must be same.

Ada design never considered premature, close-to-hardware optimization as a
priority. I don't see why in case of DB, it should be any otherwise.
Further I doubt very much that performance problems could be imposed by
bindings. Usually such problems have algorithmic nature. I don't see how
reasonably designed DB bindings would force you to choose a wrong
algorithm...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The future of Ada is at risk

[Frank J. Lhota]

Agyaras wrote:
> ...
> 
> Talking about safety and ergonomics: how do you tell which Ada 
> subprograms raise which exceptions? Well, you cannot. The Java designers 
> got this absolutely right: the method signatures can contain a throws() 
> clause. Either you catch an exception or let it propagate and the 
> compiler complains if you omit the throws() in the latter case. It would 
> be nice if the Ada2005 standard could be amended with a similar 
> mechanism. If it can be done in Java, then it certainly could be done in 
> Ada! :-)

Java-style statically enforced exception contracts does have some 
drawbacks, however. See

	ttp://groups.google.com/group/comp.lang.ada/msg/7dfb6f87f47d8db8

> "Make computers work so that humans won't have to"
> 
> A
> 


-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for this one to come home!"
- Mr. Wizard from "Tooter Turtle"

Re: The future of Ada is at risk

[Jeffrey R. Carter]

Michael Bode wrote:
> 
> What is your problem? You can write programs in C# that run under Mono
> or DotGNU in Linux and under .NET in Windows. If you want to write them on a
> Windows machine you use VS and if you want to write on a Linux box you
> use vi or whatever. So there is nothing refuted about VS. Delphi was a
> bad example so discard that and take e.g. C++/Qt as another commercial
> cross platform offering.

There you go, trying to change the topic again.

-- 
Jeff Carter
"We burst our pimples at you."
Monty Python & the Holy Grail
16

Re: The future of Ada is at risk

[Georg Bauhaus]

On Sun, 2008-01-06 at 13:23 +0100, Dmitry A. Kazakov wrote:
> On Sun, 06 Jan 2008 13:05:28 +0100, Georg Bauhaus wrote:
> 
> > On Sun, 2008-01-06 at 09:42 +0100, Dmitry A. Kazakov wrote:
> > 
> >>> http://www.djangoproject.com/documentation/model-api/
> > 
> >> Yes, that looks pretty much like it should be, IMO.
> > 
> > Did you notice that they provide anyone with direct access
> > to SQL in order to do non-trivial relational things?
> 
> You can do assembler insertions in Ada. The relation must be same.

Quite to the contrary, SQL is a very high level language.
OO classes are closer to attribute sets than they are to
relational expressions---unless they try to implement a
better SQL. Go ahead! ;-) A relational expression has yet to
find its way into pure Ada. If you have something ... ;-)


> Ada design never considered premature, close-to-hardware optimization as a
> priority.

However, the Ada design explicitly considers close-to-hardware
programming a priority because of resource consumption and
timing. A similar situation exists with real-world SQL programming:
when a result set must be established within soft real-time
constraints and within a given amount of available memory.
Updates must not take longer than a given duration.
Working within these constraints is not in any way premature
optimization IMHO, but rather a way to achieve the minimal goals.
What will be *mature* optimization if fulfilling the requirements
using high level, non-trivial SQL is premature optimization?


> Further I doubt very much that performance problems could be imposed by
> bindings.

In bindings such as the one you have seen, joins, key relations etc.
are built in the scripting language. The reason given is because MySQL
ISAM tables support very few features of basic SQL. "So we do
it ourselves...", i.e., try to reinvent the wheel, with moderate
success. The Ruby on Rails community quite honestly advises
against deviation from the Rails ways (... :). This means, if
a database module requires slightly more relational power than
standard framework objects have, you should "revert" to SQL (to
the higher conceptual level that is).

This is why every now and then someone suggests ActiveRelation
instead of ActiveRecord. So far, there are no results AFAICT.

>  Usually such problems have algorithmic nature.

Database performance problems are just like functional
language performance problems: The simple and elegant
expressions tend to be too resource consuming and must be
rewritten until they become efficient.
How would a purely relational type system remove this issue?

>  I don't see how
> reasonably designed DB bindings would force you to choose a wrong
> algorithm...

Something in this sentence is begging the question... ;-)

Re: The future of Ada is at risk

[Michael Bode]

"Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> writes:

> There you go, trying to change the topic again.

If you say so.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: The future of Ada is at risk

[Dmitry A. Kazakov]

On Sun, 06 Jan 2008 21:13:07 +0100, Georg Bauhaus wrote:

> On Sun, 2008-01-06 at 13:23 +0100, Dmitry A. Kazakov wrote:
>> On Sun, 06 Jan 2008 13:05:28 +0100, Georg Bauhaus wrote:
>> 
>>> On Sun, 2008-01-06 at 09:42 +0100, Dmitry A. Kazakov wrote:
>>> 
>>>>> http://www.djangoproject.com/documentation/model-api/
>>> 
>>>> Yes, that looks pretty much like it should be, IMO.
>>> 
>>> Did you notice that they provide anyone with direct access
>>> to SQL in order to do non-trivial relational things?
>> 
>> You can do assembler insertions in Ada. The relation must be same.
> 
> Quite to the contrary, SQL is a very high level language.

I don't care. The only question is how frequently one would need an
insertion of raw SQL.

>> Ada design never considered premature, close-to-hardware optimization as a
>> priority.
> 
> However, the Ada design explicitly considers close-to-hardware
> programming a priority because of resource consumption and
> timing. A similar situation exists with real-world SQL programming:
> when a result set must be established within soft real-time
> constraints and within a given amount of available memory.
> Updates must not take longer than a given duration.
> Working within these constraints is not in any way premature
> optimization IMHO, but rather a way to achieve the minimal goals.
> What will be *mature* optimization if fulfilling the requirements
> using high level, non-trivial SQL is premature optimization?

Is it about algorithms or about vendor-X specific non-standard SQL stuff?
Either is a good reason why there should be no SQL-bindings.

>> Further I doubt very much that performance problems could be imposed by
>> bindings.
> 
> In bindings such as the one you have seen, joins, key relations etc.
> are built in the scripting language. The reason given is because MySQL
> ISAM tables support very few features of basic SQL. "So we do
> it ourselves...", i.e., try to reinvent the wheel, with moderate
> success. The Ruby on Rails community quite honestly advises
> against deviation from the Rails ways (... :). This means, if
> a database module requires slightly more relational power than
> standard framework objects have, you should "revert" to SQL (to
> the higher conceptual level that is).

I don't see the point, sorry.

>>  Usually such problems have algorithmic nature.
> 
> Database performance problems are just like functional
> language performance problems: The simple and elegant
> expressions tend to be too resource consuming and must be
> rewritten until they become efficient.
> How would a purely relational type system remove this issue?

What has it to do with bindings? If you think that my goal is to search for
the Holly Grail of RA, then you get me wrong. I don't care about relational
purity.

>> I don't see how
>> reasonably designed DB bindings would force you to choose a wrong
>> algorithm...
> 
> Something in this sentence is begging the question... ;-)

Why? You told me how high level SQL is. I am impressed and presume that all
work will be done outside the bindings. So whatever performance problems
you will get, that will not because of bindings, they are all yours.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The future of Ada is at risk

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> (What is an inverse for function? (:-))

Malfunction.  ;-)

- Bob

Re: The future of Ada is at risk

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

>>>  Usually such problems have algorithmic nature.
>> Database performance problems are just like functional
>> language performance problems: The simple and elegant
>> expressions tend to be too resource consuming and must be
>> rewritten until they become efficient.
>> How would a purely relational type system remove this issue?
> 
> What has it to do with bindings? If you think that my goal is to search for
> the Holly Grail of RA, then you get me wrong. I don't care about relational
> purity.

OK, I see. Then SQL should be fine.
For me, a good compromise is this: problem domain abstractions
in Ada and then the most direct link between my Ada types and
the linguistic mechanism controlling the RDB: plain old SQL.
My programs are then written in two languages, and the connection
between the two source parts is easy, regular, and manageable.

Every ambitious binding I have seen so far isn't near the ease of a
working solution: basically, write SQL.  The most powerful thing I have
seen is CLSQL. Since Lisp tends to be most useful as a metaprogramming
language, you can do all kinds of complex magic in very clever
convolutions. Besides that, if you think of your RA type system,
will it look like SQL using Ada?

Re: The future of Ada is at risk

[Brian May]

>>>>> "Pascal" == Pascal Obry <pascal@obry.net> writes:

    Pascal> I did lot of SQL programing in Ada. I would be surprised that such
    Pascal> framework is versatile enough to give good performances on large SQL
    Pascal> join requests! Of course I'll be glad to be proved wrong!

    Pascal> Mapping SQL and forms automatically works fine for simple tasks (like
    Pascal> building a blog) but passed that I have yet to see something that
    Pascal> works fine. Again I'll be glad to be proved wrong!

You will never get a framework that is as versatile as SQL. SQL is
very flexible. Having said that, Drupal framework appears to be the
best I have seen so far.

However, it allows access to raw SQL. So If you do find something you
can't do efficiently as you require, you still do it.

As a side note, use of a good framework also avoids the
"programmer-forgot-to-SQL-quote-the-untrusted-user-input" security
errors that seem to be so common these days.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: The future of Ada is at risk

[Brian May]

>>>>> "Dmitry" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:

    Dmitry> [ I think that the issue with static typing can be resolved. Of course the
    Dmitry> best way would be a support for anonymous record types (tuples). But there
    Dmitry> exist also possibilities to use generics or else to have abstract base
    Dmitry> tagged types for cells.]

My preference for implementing such a system would be to have a
pre-compiler that compiles the basic table definitions into Ada code
that can be compiled with the rest of the application (e.g. like IDL
compilers).

That way you get static type checking, minimal run-time overhead, etc.

However, I suspect that I just turned off a lot of people who don't
like pre-compilers.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: The future of Ada is at risk

[Brian May]

>>>>> "Agyaras" == Agyaras  <agyaras@kerekerdoe.hu> writes:

    Agyaras> The problem for many people starts earlier. Consider these two programs:-

    Agyaras> -- Ada (221 chars)
    Agyaras> with Ada.Strings.Unbounded, Ada.Text_IO.Unbounded_IO;
    Agyaras> use Ada.Strings.Unbounded, Ada.Text_IO.Unbounded_IO;

    Agyaras> procedure str is
    Agyaras> Strg: Unbounded_String := To_Unbounded_String("ergonomy");
    Agyaras> begin
    Agyaras> Put_Line(Strg);
    Agyaras> end str;

    Agyaras> // C++ (148 chars)
    Agyaras> #include <string>
    Agyaras> #include <iostream>
    Agyaras> using namespace std;

    Agyaras> int main(int argc, char *argv[])
    Agyaras> {
    Agyaras> string Strg("ergonomy");
    Agyaras> cout<<Strg<<endl;
    Agyaras> }

I find the Ada version easier to understand.

Also it is interesting to note that:

Put_Line(Strg);

Is shorter and easier to understand then:

cout<<Strg<<endl;

Where Ada misses out most, is the top two lines. Maybe it could have a
clause that does both "with"+"use" at the same time.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: The future of Ada is at risk

[Per Sandberg]

Short notice
Isn't that what MDA (http://en.wikipedia.org/wiki/Model-driven_architecture)
  is all about ??

/Per

Brian May wrote:
>>>>>> "Dmitry" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>     Dmitry> [ I think that the issue with static typing can be resolved. Of course the
>     Dmitry> best way would be a support for anonymous record types (tuples). But there
>     Dmitry> exist also possibilities to use generics or else to have abstract base
>     Dmitry> tagged types for cells.]
> 
> My preference for implementing such a system would be to have a
> pre-compiler that compiles the basic table definitions into Ada code
> that can be compiled with the rest of the application (e.g. like IDL
> compilers).
> 
> That way you get static type checking, minimal run-time overhead, etc.
> 
> However, I suspect that I just turned off a lot of people who don't
> like pre-compilers.

Re: The future of Ada is at risk

[Nasser Abbasi]

"anon" <anon@anon.org> wrote in message 
news:qxudj.88867$MJ6.7813@bgtnsc05-news.ops.worldnet.att.net...


>  And when using the standard Ada
> libraries (Ada) the program is 100% portable without modification.
>

I think one of the problems is that Ada standard libraries are too limited 
in scope for applications, at least for applications outside the scope where 
Ada is generally used.

I'd love to use Ada for Scientific and numerical applications, but is has 
limited standard libraries for this.

The only way to make Ada popular, is for it to have a very large library, 
may be as large as Java's.

my 2 cents on the subject

Nasser

Re: The future of Ada is at risk

[Stephen Leake]

Michael Bode <m.g.bode@web.de> writes:

> Rico Secada <coolzone@it.dk> writes:
>
>
> [...]
>
> 4. As long as you have to choose either program GPL code or pay like
> you're Boeing 

This is just FUD.

The nicely packaged releases from AdaCore are GPL.

The nicely packaged releases from FSF are GMGPL.

What is the problem?

-- 
-- Stephe

Re: The future of Ada is at risk

[Robert A Duff]

"Nasser Abbasi" <nma@12000.org> writes:

> I'd love to use Ada for Scientific and numerical applications, but is has 
> limited standard libraries for this.

What do you think of the Ada 2005 additions in the numerics
area?

- Bob

Re: The future of Ada is at risk

[Nasser Abbasi]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccodbxnb8b.fsf@shell01.TheWorld.com...
> "Nasser Abbasi" <nma@12000.org> writes:
>
>> I'd love to use Ada for Scientific and numerical applications, but is has
>> limited standard libraries for this.
>
> What do you think of the Ada 2005 additions in the numerics
> area?
>
> - Bob

There was a talk here about Ada 2005 and numeric 5 months ago. Here was my 
little comment on it in this thread:

http://groups.google.com/group/comp.lang.ada/browse_thread/thread/c3d0e99376a4f379/86d9c043bd88a9d1?hl=en&lnk=st&q=Interested+about+number+crunching+in+Ada#86d9c043bd88a9d1

I think Ada is great for numerical work, as a language. The problem is that 
the function set and libraries for this sort of work are too small for Ada. 
Compare for example work being done using Python for scientific computing

http://www.scipy.org/

Now many people, it seems, are starting to use python for numerical work (I 
don't, I use Mathematica, Maple and Matlab mostly). But there is even an 
open source computer algebra system (sage) which uses python.  (Is python, 
at the language level, better designed than Ada for this sort of work? I do 
not think so, but it has much more libraries and packages than Ada does).

I do not think it is enough to have good language. What is more needed are 
more libraries and packages that come with it.  I think Ada 2005 does good 
job in improving this situation, but it is still too limited, when compared 
to what one can do with other systems.

It is also possible that dynamic and interpretive languages/environments is 
what becoming popular, due to the flexibility they offer the user: issue a 
command, and see the result right away, plot a function and see the result 
right there, and the old edit/compile/link/run type languages are becoming 
less popular.

Nasser

Re: The future of Ada is at risk

[Michael Bode]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> The nicely packaged releases from FSF are GMGPL.
>
> What is the problem?

Since Windows 3.0 PC programs tend to have a GUI. Since the Macintosh
programs for Apple computers have a GUI. And Linux distributions have
X11 since the early 90s. So I'd really like use this modern feature in
2008. And if I look at my PC, I'm not the only one.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: The future of Ada is at risk

[Brian May]

>>>>> "Per" == Per Sandberg <per.sandberg@bredband.net> writes:

    Per> Short notice
    Per> Isn't that what MDA (http://en.wikipedia.org/wiki/Model-driven_architecture)
    Per> is all about ??

Don't know. As far as I can tell, the above seems to be more about
models for communications (Corba, .NET, etc), where what I was talking
about is for databases. I might be mistaken though.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: The future of Ada is at risk

[Randy Brukardt]

"Agyaras" <agyaras@kerekerdoe.hu> wrote in message
news:agyaras-50CE35.10341806012008@news.inode.at...
> In article <1199452391.7932.27.camel@K72>,
...
> The problem for many people starts earlier. Consider these two programs:-
>
> -- Ada (221 chars)
> with Ada.Strings.Unbounded, Ada.Text_IO.Unbounded_IO;
> use Ada.Strings.Unbounded, Ada.Text_IO.Unbounded_IO;
>
> procedure str is
>    Strg: Unbounded_String := To_Unbounded_String("ergonomy");
> begin
>    Put_Line(Strg);
> end str;

Boy, that's sure a long-winded way to write this. I'd write something like
this:

with Ada.Text_IO;
procedure Str is
    Strg : String := "ergonomy";
begin
    Ada.Text_IO.Put_Line (Strg);
end Str;

I didn't count the characters, but it's surely a lot shorter than the
original version.

Moral: Don't even think about using Unbounded_String unless you have to; the
native strings of Ada are quite powerful. I've found that Unbounded_String
is more work than it is worth about 80% of the time. Ada is surely wordy
when that 20% comes up (especially for those of use who rarely use use
clauses), but that is about the least important attribute of a programming
language.

Moral2: Writing C++ code in Ada is rather likely to make lousy Ada code (I'm
sure the reverse is true, too.)

                     Randy.

Re: The future of Ada is at risk

[Simon Wright]

Brian May <bam@snoopy.apana.org.au> writes:

>>>>>> "Per" == Per Sandberg <per.sandberg@bredband.net> writes:
>
>     Per> Short notice
>     Per> Isn't that what MDA (http://en.wikipedia.org/wiki/Model-driven_architecture)
>     Per> is all about ??
>
> Don't know. As far as I can tell, the above seems to be more about
> models for communications (Corba, .NET, etc), where what I was talking
> about is for databases. I might be mistaken though.

All sorts of possibilities, in fact. It would be reasonably possible
to generate both a (probably unoptimised) database schema and
corresponding Ada interface code from a UML model (the model has to be
appropriate of course -- high-level aka vague models won't cut it).

http://www.kc.com/xuml.php
http://www.mentor.com/products/sm/uml_suite/index.cfm

Re: The future of Ada is at risk

[Vadim Godunko]

On Jan 8, 9:53 am, Simon Wright <simon.j.wri...@mac.com> wrote:
> Brian May <b...@snoopy.apana.org.au> writes:
>
> > Don't know. As far as I can tell, the above seems to be more about
> > models for communications (Corba, .NET, etc), where what I was talking
> > about is for databases. I might be mistaken though.
>
> All sorts of possibilities, in fact. It would be reasonably possible
> to generate both a (probably unoptimised) database schema and
> corresponding Ada interface code from a UML model (the model has to be
> appropriate of course -- high-level aka vague models won't cut it).
>
We have used MDA and developed our own generator, which generate near
to all components of the our subsystem from UML: CORBA IDL
specifications, SQL DDL (including constraints and triggers), Ada
implementation code, massive testsiute (it cover about 80% of all
code). Subsystem operate with bitemporal data and some kind of
revision control over the processed data. The only distributed
transactional service, security service, fault tolerance service and
computable object's attributes are handwriten.

Just one mouse click for generate and week for compiling and automated
testing! :-)

Re: The future of Ada is at risk

[Graham]

On Jan 7, 12:11 am, Brian May <b...@snoopy.apana.org.au> wrote:
> >>>>> "Dmitry" == Dmitry A Kazakov <mail...@dmitry-kazakov.de> writes:
>
>     Dmitry> [ I think that the issue with static typing can be resolved. Of course the
>     Dmitry> best way would be a support for anonymous record types (tuples). But there
>     Dmitry> exist also possibilities to use generics or else to have abstract base
>     Dmitry> tagged types for cells.]
>
> My preference for implementing such a system would be to have a
> pre-compiler that compiles the basic table definitions into Ada code
> that can be compiled with the rest of the application (e.g. like IDL
> compilers).
>
> That way you get static type checking, minimal run-time overhead, etc.
>
> However, I suspect that I just turned off a lot of people who don't
> like pre-compilers.
> --
> Brian May <b...@snoopy.apana.org.au>

I wrote a little system like this and posted it to the Gnade list the
other day.

http://www.virtual-worlds.org.uk/downloads/mill.tgz

It's fairly preliminary, but works for me.

Graham

Re: The future of Ada is at risk

[Pascal Obry]

Brian May a �crit :
> My preference for implementing such a system would be to have a
> pre-compiler that compiles the basic table definitions into Ada code
> that can be compiled with the rest of the application (e.g. like IDL
> compilers).
> 
> That way you get static type checking, minimal run-time overhead, etc.

Yes. That is what I generally do when I need to use a DB on an Ada 
project. The first time I did that was in 1995, nothing new :)

Note that AWS also comes with a pre-compiler for template files to 
interface to the Ajax and HTML-forms. This also adds some checking 
without run-time overhead.

Doing this ensures that when you modify the database or the templates 
the code won't compiler anymore.

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

Re: The future of Ada is at risk

[ahab]

On Jan 4, 2:45 am, Agyaras <agya...@kerekerdoe.hu> wrote:
> ...
> 5) Lack of libraries and frameworks. This is due to the unpopularity of
> the language ...

I wonder if something like a summer of code for Ada would be
appropriate. Haskell did something similar. http://hackage.haskell.org/trac/summer-of-code/wiki

There are plenty of Ada organizations out there that could possibly
sponsor something like that. (I've always been meaning to finish
fixing the file IO for XML/Ada too...)

Re: The future of Ada is at risk

[Phaedrus]

Okay, I guess we all agree, Ada is a heck of a language and we all love it. 
(Or else why would we be here?)  But the implied question that started this 
thread was, well, what's WRONG with the ol' gal?  Instead of making this an 
Ada-love-fest, how about doing some honest soul-searching about what's 
missing, wrong, or just too hard for the programming world in general?   The 
current lack of a DOD mandate isn't the reason for Ada's diminishing market 
share, the market share is the result of a real or imagined problem with the 
language, environment or something else.  So I'd like to propose that we put 
all of your Mensa-caliber gray matter to work and determine what's wrong or 
lacking.



Not to go all Econ-101 on ya'all, but the market is seldom actually wrong 
for long, and it seems to be making a statement about Ada.  The market-share 
is falling, and we need to take action!  So here's my take on some things 
that could be improved, and some questions that should be raised.



1.  It's relatively intimidating to learn.

   Not that it needs to be, but between a needlessly complicated LRM and 
academia-bound (-and-hopefully-gagged) textbooks, a neophyte shouldn't dive 
in without a full scuba set.  It gets deep, fast.  And if you didn't get on 
the Ada-train in the mid 80's, then the learning curve is STEEP.  Nice folks 
like Dean Gonzales did their best to create annotated LRM's in the 80's, 
should that effort get going again?



What else can we do to make it more attractive to the neophytes?  If an 
Ada-based turtle graphics package is all that needed to attract the newbies, 
then let's get started!



2.  More emphasis on cleverness than usefulness on rugged, reusable code.

   Have you noticed how many folks would rather use a bunch of tasks, or do 
umpteen levels of inheritance, when something simple would work just fine? 
These ivory-tower things are real nice, but isn't it more important that it 
be able to be reused in LESS time than it took to write the darn thing?  Has 
the KISS rule been forgotten?  Honest, it's okay that package Hammer isn't 
completely safe for objects of type Toe, if you document it.  And don't even 
get me started on people who make their own types (AKA "Bobs_Integer") when 
the predefined type would work just fine.



Anecdote:  In the early 90's a major submarine contract was torpedoed by 
it's own software when a mid-level Ada coder decided to make a "minor" 
architecture decision which used nested variant records for system messages 
that were then handled by nested generics.  Even if this kludge could 
compile, how would you debug it?  The lead for this section of code couldn't 
be convinced that this was a bad idea, and as a result that subcontract was 
a technical, legal and financial fiasco.



3.  Perception/PR

Let's face it; the lady has a bad reputation.  It's not from growing up 
around military guys, it's from being associated with the DOD.  It's not 
fair, it's not accurate, but it's there.  And let's not forget the Ariane 5 
problem (http://en.wikipedia.org/wiki/Ariane_5), not Ada's fault but still 
not helping the situation.  Ada is a natural for simulation, for financial 
apps, for embedded work, for robotics, for industrial work, and games, but 
only if we can change some attitudes about it.  But how?



4. Ease of deployment

It really is quicker and easier to create small C apps for Windows (The 
prevalent environment) than Ada.  Why?  What's are your favorite gripes? 
What could be made easier?  Since a lot of large projects start life as 
little projects and little demos,  if we make it easier to make little 
projects then maybe the big projects will come our way.





Anyway, any ideas???  Please skip the "rah rah Ada" comments, the "those 
mean old managers won't let us use Ada" comments, and let's pitch in and 
figure out what's wrong.  Really, the future of Ada is at risk.  And worse 
yet, we might all have to go work in Java! *gag*



Cheers!

Brian

Re: The future of Ada is at risk

[Maciej Sobczak]

On 11 Sty, 08:21, "Phaedrus" <phaedrus...@hotmail.com> wrote:

> Instead of making this an
> Ada-love-fest, how about doing some honest soul-searching about what's
> missing, wrong, or just too hard for the programming world in general?

My 0.05 Euro:

Ada lacks libraries. The standard library is close to disaster and too
many times when I was asking for something here I heard "do it
yourself". Sure I can do everything myself and - being a geek - even
find it funny, but that does not translate to successful projects,
especially commercial ones, where deadlines matter more than fun.
In particular, frequent statements about Ada guaranteeing short
development are negated by the bare fact that I have to reinvent too
many wheels to get something of reasonable functional complexity.
There are some extension libraries (GNAT), but even those seem to be
half-baked. This does matter in general-purpose programming.
If you compare it to C++ you might be tempted to claim that both
languages are equal in this aspect, because the standard library in C+
+ is also not very impressive. The difference, however, is that C++
binds *directly* to whatever system API is available on a given
platform. That changes a lot.
I don't think that this problem can be easily solved. Comprehensive
libraries cannot be written a single person and for obvious reasons
there will never be a huge community of enthusiasts willing to spend
their time building something new.

{That said, I have to admit that I find AWS just awesome.}

Ada is not likely to recruit newcomers, because it lacks an easy to
read tutorial. No, I don't find the existing on-line material to be
compelling - either too dense, or too slow, or badly formatted.
For an example of *good* tutorial (I'm not talking about the language
which is described, but about the form) see:
http://java.sun.com/docs/books/tutorial/

> 3.  Perception/PR
>
> Let's face it; the lady has a bad reputation.

I wouldn't say so, at least not in the communities I know. Ada has an
excellent reputation. I think that outside of US nobody really cares
about DoD and what matters more is the immediate mental association
with real-time, control systems, and such. The problem is that with
this positive reputation comes some kind of prejudice that "it is so
professional that I will never be able to learn it". On the other
hand, nobody fears PHP: "every kid on the block knows it, so I can
learn it too".
Bad news: you cannot do anything about it.

> 4. Ease of deployment

I think it is related to the issue of libraries.

> And worse
> yet, we might all have to go work in Java! *gag*

Identify what Java does right (consolidated libraries and good quality
tutorials) and do it as well.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: The future of Ada is at risk

[framefritti]

Phaedrus wrote:

>
> 1.  It's relatively intimidating to learn.
>
>(snip)
>
> 3.  Perception/PR
>
>

Some impressions that I got speaking with people in my environment:
when I say that I felt
(professionally, of course) in love with Ada, most of the times I get
remarks such "Does it still exist?",
"It is too huge!", "Why not an object-oriented language?", "The world
advances and you go back..."
(the last one is the litteral translation of what a coworker of mine
said).  Summarizing, my impression
is that most of non-Ada people think that Ada is too old or too
complex for general use.

About the difficulty of learning Ada: I admit it is not BASIC, but my
experience (with students carrying
out their final project) is that the average student requires few
weeks to learn enough Ada to start
working.  I believe that "intimidating" is the right word, since maybe
most people _believe_ that
learning Ada is too difficult a task.

I think I am going to put my 0.05 Euro in the Ada PR department by
talking about Ada at the next
local Linux Group meeting.

>
> 4. Ease of deployment
>
> It really is quicker and easier to create small C apps for Windows (The
                                                          ^^^^^

I believe that "small" is the key-word here. Although I am an Ada-guy,
Ada is not the only
programming language that I use: I use matlab (for numerical
experiment),
Ruby (for fast-and-dirty and/or medium-small applications) and PHP
(when I have to :-).

My impression is that the "strict" nature of Ada gets in the way when
you try do develop small
applications.  Sure, strictness is what makes your program safer and I
believe that it is
really important with large pieces of software, but when you want to
write a medium-small application
(say, a "keyring" for passwords with some GUI),  the duck-typing of
Ruby (or whatever language
you like...) is more flexible and easier to use.

Can/should we make Ada easier to use for small applications?   I do
not know... my impression
is that if you want something which is really safe you pay it with a
loss of flexibility
(like a stability/maneuverability tradeoff in planes)

Actually, I agree that a big step in ease of deployment would be the
availability of a
large number of good libraries (which, incidentally, is a big
advantage of languages like Perl,
Ruby, Python...).

Maybe if Ada was more used in the open source community.... (another
reason for  introducing Ada at the next meeting)

Re: The future of Ada is at risk

[Peter C. Chapin]

Maciej Sobczak wrote:

> Ada is not likely to recruit newcomers, because it lacks an easy to
> read tutorial. No, I don't find the existing on-line material to be
> compelling - either too dense, or too slow, or badly formatted.

FWIW I'm slowly working on an Ada tutorial that targets the particular 
students I have. It is incomplete but it is intended to be short so a 
certain amount of incompleteness is to be expected. I'm not saying it's 
great but it is at least another tutorial in the mix.

The URL is

	http://vortex.ecet.vtc.edu/pcc/AdaCrash.pdf

If anyone notices any errors or has any suggestions for the document, 
let me know!

Peter

Re: The future of Ada is at risk

[Peter C. Chapin]

framefritti@gmail.com wrote:

> Some impressions that I got speaking with people in my environment:
> when I say that I felt (professionally, of course) in love with Ada,
 > most of the times I get remarks such "Does it still exist?",

I'll second this. Some of the people I've talked with about Ada think 
the language is obsolete.

> "It is too huge!"

Which is funny when you consider that this objection sometimes comes 
from people who are using C++.

Peter

Re: The future of Ada is at risk

[Hyman Rosen]

On Jan 11, 3:49 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> Ada lacks libraries. The standard library is close to disaster and too
> many times when I was asking for something here I heard "do it
> yourself".

Just as an example, take a look at <http://www.microsoft.com/express/
samples/>,
for what Microsoft makes available for free to C# and C++ developers.
Included
is a full 2D and 3D game engine, for example.

Re: The future of Ada is at risk

[Gary Scott]

Peter C. Chapin wrote:
> framefritti@gmail.com wrote:
> 
>> Some impressions that I got speaking with people in my environment:
>> when I say that I felt (professionally, of course) in love with Ada,
> 
>  > most of the times I get remarks such "Does it still exist?",
> 
> I'll second this. Some of the people I've talked with about Ada think 
> the language is obsolete.
> 
>> "It is too huge!"
> 
> 
> Which is funny when you consider that this objection sometimes comes 
> from people who are using C++.

They say the same thing about Fortran 2k3.

> 
> Peter


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Re: The future of Ada is at risk

[Jeffrey R. Carter]

Phaedrus wrote:
> Okay, I guess we all agree, Ada is a heck of a language and we all love it. 
> (Or else why would we be here?)  But the implied question that started this 
> thread was, well, what's WRONG with the ol' gal?  Instead of making this an 
> Ada-love-fest, how about doing some honest soul-searching about what's 
> missing, wrong, or just too hard for the programming world in general?   The 
> current lack of a DOD mandate isn't the reason for Ada's diminishing market 
> share, the market share is the result of a real or imagined problem with the 
> language, environment or something else.  So I'd like to propose that we put 
> all of your Mensa-caliber gray matter to work and determine what's wrong or 
> lacking.

Ada is a SW-engineering language. It enforces SW-engineering principles. 98% of 
developers are coders, not SW engineers. It should not be a surprise that they 
don't choose a SW-engineering language.

We don't let construction workers design bridges or choose the materials for 
them, but we regularly let the construction workers design and choose the 
materials for significant SW projects. This is probably because there is 
significant liability for incompetent civil engineers, and none for incompetent 
SW engineers.

> 1.  It's relatively intimidating to learn.
> 
>    Not that it needs to be, but between a needlessly complicated LRM and 
> academia-bound (-and-hopefully-gagged) textbooks, a neophyte shouldn't dive 
> in without a full scuba set.  It gets deep, fast.  And if you didn't get on 
> the Ada-train in the mid 80's, then the learning curve is STEEP.  Nice folks 
> like Dean Gonzales did their best to create annotated LRM's in the 80's, 
> should that effort get going again?

A controlled study by the US Military Academy found Ada to be a better 1st 
language than Pascal, which was designed as a teaching language.

> 2.  More emphasis on cleverness than usefulness on rugged, reusable code.
> 
>    Have you noticed how many folks would rather use a bunch of tasks, or do 
> umpteen levels of inheritance, when something simple would work just fine? 
> These ivory-tower things are real nice, but isn't it more important that it 
> be able to be reused in LESS time than it took to write the darn thing?  Has 
> the KISS rule been forgotten?  Honest, it's okay that package Hammer isn't 
> completely safe for objects of type Toe, if you document it.  And don't even 
> get me started on people who make their own types (AKA "Bobs_Integer") when 
> the predefined type would work just fine.

SW engineers can create useful abstractions, making things simpler. Coders 
can't, and tend to create designs that make things more complex than they need 
to be.

And don't get me started on people who use Integer when an application-specific 
type would be a much better choice.

> It really is quicker and easier to create small C apps for Windows (The 
> prevalent environment) than Ada.  Why?  What's are your favorite gripes? 
> What could be made easier?  Since a lot of large projects start life as 
> little projects and little demos,  if we make it easier to make little 
> projects then maybe the big projects will come our way.

My experience is that it's easier to get something running in C than in Ada. 
Getting something that seems to be correct tends to take longer in C than in 
Ada, and getting something where I'm confident that it's correct takes even longer.

Ada sometimes seems to avoid taking advantage of its opportunities. Ada 95, with 
tasking improvements, came out just before Windows 95, the 1st widely used OS 
with multitasking support. I suggested that we promote Ada 95 as the language of 
choice for Windows 95, but that didn't happen. Now multiprocessors are becoming 
common, and a language with good, high-level support for parallelism should be 
the language of choice for such systems. Maybe we can take advantage of this 
opportunity.

A standard, portable, Ada-oriented, easy to use for most basic tasks, non-GPL 
GUI library would go a long way to making Ada more attractive. One of Java's big 
attractions was its portable GUI library. It wasn't perfect, but that wasn't a 
concern for most users.

-- 
Jeff Carter
"Propose to an Englishman any principle, or any instrument, however
admirable, and you will observe that the whole effort of the English
mind is directed to find a difficulty, a defect, or an impossibility
in it. If you speak to him of a machine for peeling a potato, he will
pronounce it impossible: if you peel a potato with it before his eyes,
he will declare it useless, because it will not slice a pineapple."
Charles Babbage
92

Re: The future of Ada is at risk

[Gary Scott]

Jeffrey R. Carter wrote:

> Phaedrus wrote:
> 
>> Okay, I guess we all agree, Ada is a heck of a language and we all 
>> love it. (Or else why would we be here?)  But the implied question 
>> that started this thread was, well, what's WRONG with the ol' gal?  
>> Instead of making this an Ada-love-fest, how about doing some honest 
>> soul-searching about what's missing, wrong, or just too hard for the 
>> programming world in general?   The current lack of a DOD mandate 
>> isn't the reason for Ada's diminishing market share, the market share 
>> is the result of a real or imagined problem with the language, 
>> environment or something else.  So I'd like to propose that we put all 
>> of your Mensa-caliber gray matter to work and determine what's wrong 
>> or lacking.
> 
> 
> Ada is a SW-engineering language. It enforces SW-engineering principles. 
> 98% of developers are coders, not SW engineers. It should not be a 
> surprise that they don't choose a SW-engineering language.
> 
> We don't let construction workers design bridges or choose the materials 
> for them, but we regularly let the construction workers design and 
> choose the materials for significant SW projects. This is probably 
> because there is significant liability for incompetent civil engineers, 
> and none for incompetent SW engineers.
> 
>> 1.  It's relatively intimidating to learn.
>>
>>    Not that it needs to be, but between a needlessly complicated LRM 
>> and academia-bound (-and-hopefully-gagged) textbooks, a neophyte 
>> shouldn't dive in without a full scuba set.  It gets deep, fast.  And 
>> if you didn't get on the Ada-train in the mid 80's, then the learning 
>> curve is STEEP.  Nice folks like Dean Gonzales did their best to 
>> create annotated LRM's in the 80's, should that effort get going again?
> 
> 
> A controlled study by the US Military Academy found Ada to be a better 
> 1st language than Pascal, which was designed as a teaching language.
> 
>> 2.  More emphasis on cleverness than usefulness on rugged, reusable code.
>>
>>    Have you noticed how many folks would rather use a bunch of tasks, 
>> or do umpteen levels of inheritance, when something simple would work 
>> just fine? These ivory-tower things are real nice, but isn't it more 
>> important that it be able to be reused in LESS time than it took to 
>> write the darn thing?  Has the KISS rule been forgotten?  Honest, it's 
>> okay that package Hammer isn't completely safe for objects of type 
>> Toe, if you document it.  And don't even get me started on people who 
>> make their own types (AKA "Bobs_Integer") when the predefined type 
>> would work just fine.
> 
> 
> SW engineers can create useful abstractions, making things simpler. 
> Coders can't, and tend to create designs that make things more complex 
> than they need to be.
> 
> And don't get me started on people who use Integer when an 
> application-specific type would be a much better choice.

On the contrary, this more often than not obfuscates, particularly for 
future maintainance purposes.

> 
>> It really is quicker and easier to create small C apps for Windows 
>> (The prevalent environment) than Ada.  Why?  What's are your favorite 
>> gripes? What could be made easier?  Since a lot of large projects 
>> start life as little projects and little demos,  if we make it easier 
>> to make little projects then maybe the big projects will come our way.
> 
> 
> My experience is that it's easier to get something running in C than in 
> Ada. Getting something that seems to be correct tends to take longer in 
> C than in Ada, and getting something where I'm confident that it's 
> correct takes even longer.
> 
> Ada sometimes seems to avoid taking advantage of its opportunities. Ada 
> 95, with tasking improvements, came out just before Windows 95, the 1st 
> widely used OS with multitasking support. I suggested that we promote 
> Ada 95 as the language of choice for Windows 95, but that didn't happen. 
> Now multiprocessors are becoming common, and a language with good, 
> high-level support for parallelism should be the language of choice for 
> such systems. Maybe we can take advantage of this opportunity.
> 
> A standard, portable, Ada-oriented, easy to use for most basic tasks, 
> non-GPL GUI library would go a long way to making Ada more attractive. 
> One of Java's big attractions was its portable GUI library. It wasn't 
> perfect, but that wasn't a concern for most users.
> 


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Re: The future of Ada is at risk

[Tero Koskinen]

On Fri, 11 Jan 2008 00:49:11 -0800 (PST) Maciej Sobczak wrote:
> Ada lacks libraries.
[snip]
> I don't think that this problem can be easily solved. Comprehensive
> libraries cannot be written a single person and for obvious reasons
> there will never be a huge community of enthusiasts willing to spend
> their time building something new.

How about submitting project ideas to software engineering project
courses running at various universities? A team of university students
many times accepts your project if the proposal is somewhat sane
and they get a relatively easy way to complete their course.
(Little bonus for a well done project might help also.)

A suitable project could be for example "Thick Ada 95 binding for
MySQL database client library. Basic Ada, C, and database skills
required."

Search for "software engineering project course" reveals courses like
http://www.cs.utah.edu/classes/cs4500/
http://www.ee.oulu.fi/research/tklab/courses/521479S/
http://www.une.edu.au/courses/2008/units/COMP395
etc.

Pick one near you and contact the lecturer.

-- 
Tero Koskinen - http://iki.fi/tero.koskinen/

Re: The future of Ada is at risk

[Georg Bauhaus]

Tero Koskinen wrote:

> A suitable project could be for example "Thick Ada 95 binding for
> MySQL database client library. Basic Ada, C, and database skills
> required."

It will be an invitation to cheat, though :-)
Thick binding to MySQL and PostgreSQL
http://home.cogeco.ca/~ve3wwg/software.html

Re: The future of Ada is at risk

[Robert A Duff]

"Phaedrus" <phaedrusalt@hotmail.com> writes:

>...the reason for Ada's diminishing market 
> share, ...

Is Ada's market share really diminishing?  It's never been huge,
compared to (say) C, but my impression is that it's slowly
increasing.  AdaCore is doing well, for example.

I don't know how to reliably measure it, though.
Do you have any concrete evidence?

I don't have any hard evidence one way or the other.

- Bob

Re: The future of Ada is at risk

[Jeffrey R. Carter]

Gary Scott wrote:
> 
> On the contrary, this [user-defined numeric types] more often than not obfuscates, particularly for 
> future maintainance purposes.

On the contrary, properly used they catch numerous development errors at 
compilation (that with the "everything's Integer" approach become run-time 
errors, often remaining in the delivered system), reducing the need for future 
maintenance. That's the point of using a strongly typed language over something 
like C.

-- 
Jeff Carter
"Propose to an Englishman any principle, or any instrument, however
admirable, and you will observe that the whole effort of the English
mind is directed to find a difficulty, a defect, or an impossibility
in it. If you speak to him of a machine for peeling a potato, he will
pronounce it impossible: if you peel a potato with it before his eyes,
he will declare it useless, because it will not slice a pineapple."
Charles Babbage
92

Re: The future of Ada is at risk

[Phaedrus]

By way of hard data, how about the Tiobe index 
(http://www.tiobe.com/tpci.htm)?  When we compare the 2008 results against 
the copy of the Tiobe index from 2004 
(http://www.developer.com/java/other/article.php/3448451), you can see that 
Ada has gone from number #19 then to #23 now.   But that just illustrates 
the current flat-lining condition.

The other data I can find is indirect, as in the computer language book sale 
graph 
(http://radar.oreilly.com/archives/2006/08/programming_language_trends_1.html), 
or the stats on open source projects 
(http://www.cs.berkeley.edu/~flab/languages.html).  Either way, Ada doesn't 
make the graph.

Compare this with the heyday of Ada, back in the late 80's to early '90's. 
I don't have any real data, but I'd guess that it's fair to say it was in 
the top half-dozen languages.

Brian

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcczlvct2mp.fsf@shell01.TheWorld.com...
> "Phaedrus" <phaedrusalt@hotmail.com> writes:
>
>>...the reason for Ada's diminishing market
>> share, ...
>
> Is Ada's market share really diminishing?  It's never been huge,
> compared to (say) C, but my impression is that it's slowly
> increasing.  AdaCore is doing well, for example.
>
> I don't know how to reliably measure it, though.
> Do you have any concrete evidence?
>
> I don't have any hard evidence one way or the other.
>
> - Bob 

Re: The future of Ada is at risk

[Pascal Obry]

Jeffrey R. Carter a �crit :
> Gary Scott wrote:
>>
>> On the contrary, this [user-defined numeric types] more often than not 
>> obfuscates, particularly for future maintainance purposes.
> 
> On the contrary, properly used they catch numerous development errors at 
> compilation (that with the "everything's Integer" approach become 
> run-time errors, often remaining in the delivered system), reducing the 
> need for future maintenance. That's the point of using a strongly typed 
> language over something like C.

Agreed 100%, I don't even see a single argument to state the opposite.

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

Re: The future of Ada is at risk

[Brian May]

>>>>> "Pascal" == Pascal Obry <pascal@obry.net> writes:

    >>> On the contrary, this [user-defined numeric types] more often than
    >>> not obfuscates, particularly for future maintainance purposes.
    >> 
    >> On the contrary, properly used they catch numerous development
    >> errors at compilation (that with the "everything's Integer" approach
    >> become run-time errors, often remaining in the delivered system),
    >> reducing the need for future maintenance. That's the point of using
    >> a strongly typed language over something like C.

    Pascal> Agreed 100%, I don't even see a single argument to state the opposite.

They require careful design. If abused, e.g. if you use two many
types, you end up constantly casting from one type to another, and you
miss the benefits.

This comes back to the discussion of programmers vs software
engineers.

Unfortunately, the attitude I have seen too often is "how do I make
this work right now?" as opposed to "how do I incorporate this change
properly into the design?" because it is perceived that the former is
faster and more likely to win clients/users. Once the clients/users
are committed to the software, then you can try to fix the bugs the
clients/users find. By then it is too late to worry about getting the
design or language right though. You are too busy adding the next
major feature.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: The future of Ada is at risk

[Pascal Obry]

Brian May a �crit :
> They require careful design. If abused, e.g. if you use two many
> types, you end up constantly casting from one type to another, and you
> miss the benefits.

Ok, but this is true for software design in general. Over-abusing 
anything is never a good idea. That does not even apply to software only 
:) But a good design using types and subtypes or derived types (no 
casting required) avoid many mistakes!

All integers seems easy, feel easy but it betray you as soon as possible!

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

Re: The future of Ada is at risk

[Dmitry A. Kazakov]

On Sat, 12 Jan 2008 21:11:30 +1100, Brian May wrote:

>>>>>> "Pascal" == Pascal Obry <pascal@obry.net> writes:
> 
>     >>> On the contrary, this [user-defined numeric types] more often than
>     >>> not obfuscates, particularly for future maintainance purposes.
>     >> 
>     >> On the contrary, properly used they catch numerous development
>     >> errors at compilation (that with the "everything's Integer" approach
>     >> become run-time errors, often remaining in the delivered system),
>     >> reducing the need for future maintenance. That's the point of using
>     >> a strongly typed language over something like C.
> 
>     Pascal> Agreed 100%, I don't even see a single argument to state the opposite.
> 
> They require careful design. If abused, e.g. if you use two many
> types, you end up constantly casting from one type to another, and you
> miss the benefits.

This is an issue where the language should have some mercy.

Let the programmer have started with two different types, and I think there
is a consensus in c.l.a that this must be the starting point. Then he
notices that sometimes he needs them transparently converted. At this point
instead of redesigning the rest, which is by the way stable and, more
importantly, is type-safe, he should be allowed to add an ad-hoc supertype
in order to allow conversions only in the contexts where he surely needs
them.

Instead of that Ada will force him either to redesign or to do explicit
conversions with an additional problem of distributed overhead of handling
possible conversion errors.

Even with well-thought and carefully designed types, it is quite common
that borders between types are half transparent and that this transparency
depends on the current view / context. Then all reasons of
coders-vs-engineers come into play forcing "coders" to write C programs in
Ada or to choose a more lax language.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The future of Ada is at risk

[Surfer]

On Fri, 11 Jan 2008 07:41:08 -0800 (PST), Hyman Rosen
<hyman.rosen@gmail.com> wrote:

>On Jan 11, 3:49 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>> Ada lacks libraries. The standard library is close to disaster and too
>> many times when I was asking for something here I heard "do it
>> yourself".
>
>Just as an example, take a look at <http://www.microsoft.com/express/
>samples/>,
>for what Microsoft makes available for free to C# and C++ developers.
>Included
>is a full 2D and 3D game engine, for example.

Globe_3D is a real-time 3D engine, in Ada, based on OpenGL
http://homepage.sunrise.ch/mysunrise/gdm/g3d.htm

Includes:

    * Real-time 3D engine (pure software rendering) and game environment, from A to Z in Ada
    * Full Ada sources including 3D models
    * Drivers for 3D rendering, controls, timers, sound, ...
    * Runs on PCs with DOS or DOS Virtual Machines - e.g. of Windows, Linux

Re: The future of Ada is at risk

[Georg Bauhaus]

Phaedrus wrote:
> By way of hard data, how about the Tiobe index 
> (http://www.tiobe.com/tpci.htm)? 

I doubt that business-oriented decision making will
find the Tiobe Index an asset. Here is its self-assessment:

"The index can be used to check whether your programming skills are
  still up to date or to make a strategic decision about what programming
  language should be adopted when starting to build a new software
  system."

At least where employers are not trying to find q&d
day-laborers for q&d web shop money making, say.

E.g., APL and OCaml are used by companies to write
programs where really large amounts of money are at stake.
Tiobe-Popularity of a language is probably not the best
commercially viable ranking in these cases.

I guess that where Ada is considered it is not considered
because it could win a fashion show---even though fashion
always affects ranking (a whole information industry being
ample prove).

Re: The future of Ada is at risk

[Gary Scott]

Pascal Obry wrote:
> Brian May a �crit :
> 
>> They require careful design. If abused, e.g. if you use two many
>> types, you end up constantly casting from one type to another, and you
>> miss the benefits.
> 
> 
> Ok, but this is true for software design in general. Over-abusing 
> anything is never a good idea. That does not even apply to software only 
> :) But a good design using types and subtypes or derived types (no 
> casting required) avoid many mistakes!
> 
> All integers seems easy, feel easy but it betray you as soon as possible!

Using a properly structured naming convention is superior to defining a 
new datatype that is internally identical with dozens of other types but 
with a different name.  It is especially disastrous in mixed language 
programming to use too many non-unique data types.  The research 
necessary to discover the interface is enormous.

> 
> Pascal.
> 


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Re: The future of Ada is at risk

[Pascal Obry]

Gary Scott a �crit :
> Using a properly structured naming convention is superior to defining a 
> new datatype that is internally identical with dozens of other types but 
> with a different name.

Are you kidding? And who is responsible to check that the convention is 
properly respected by all developers!

> It is especially disastrous in mixed language 
> programming to use too many non-unique data types.  The research 
> necessary to discover the interface is enormous.

The interface of what? Integers? When I see:

    type Whatever is new Integer;

I myself have no problem finding the interface... But if you have please 
explain!

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

Re: The future of Ada is at risk

[Gautier]

Surfer:

> Globe_3D is a real-time 3D engine, in Ada, based on OpenGL
> http://homepage.sunrise.ch/mysunrise/gdm/g3d.htm
> 
> Includes:
> 
>     * Real-time 3D engine (pure software rendering) and game environment, from A to Z in Ada
>     * Full Ada sources including 3D models
>     * Drivers for 3D rendering, controls, timers, sound, ...
>     * Runs on PCs with DOS or DOS Virtual Machines - e.g. of Windows, Linux

Thank you for the advertisement! Still, you are mixing two distinct projects:

* GLOBE_3D, which runs natively, through a GL binding, on all platforms 
providing GL or OpenGL.

* Engine_3D, an older project now fossilized, which runs on DOS, without 
binding, and ignoring 3D hardware acceleration. The interest of that one is to 
show a game machine that is mostly in Ada, including parts of the operating 
system (e.g. keyboard, sound drivers).

Cheers
Gautier

Re: The future of Ada is at risk

[jtg]

Robert A Duff pisze:
> "Phaedrus" <phaedrusalt@hotmail.com> writes:
> 
>> ...the reason for Ada's diminishing market 
>> share, ...
> 
> Is Ada's market share really diminishing?  It's never been huge,
> compared to (say) C, but my impression is that it's slowly
> increasing.  AdaCore is doing well, for example.
> 
> I don't know how to reliably measure it, though.
> Do you have any concrete evidence?
> 
My favourite - statistics compiled from job ads:
   http://www.itjobswatch.co.uk/jobs/uk/ada.do
   http://www.itjobswatch.co.uk/contracts/uk/ada.do
Unfortunately, only UK is covered.

Re: The future of Ada is at risk

[Georg Bauhaus]

On Sat, 2008-01-12 at 19:14 +0100, Pascal Obry wrote:
> Gary Scott a écrit :
> > Using a properly structured naming convention is superior to defining a 
> > new datatype that is internally identical with dozens of other types but 
> > with a different name.
> 
> Are you kidding? And who is responsible to check that the convention is 
> properly respected by all developers!
> 
> > It is especially disastrous in mixed language 
> > programming to use too many non-unique data types.  The research 
> > necessary to discover the interface is enormous.
> 
> The interface of what? Integers? When I see:
> 
>     type Whatever is new Integer;
> 
> I myself have no problem finding the interface... But if you have please 
> explain!

I suppose that
- if your head is very much capable of spinning around
  "algorithmically determined integer ranges" while
- your are writing numeric libraries
- to be supplied to the "C binding facility" of other
  languages,
you wouldn't easily see the necessities and possibilities 
of programmer defined base types?

Re: The future of Ada is at risk

[Ray Blaak]

Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de> writes:
> - if your head is very much capable of spinning around
>   "algorithmically determined integer ranges"

I would say that it is not the integer ranges as such that are important. It
is the fact the different integer types are forced to be distinct.

In fact, since I have left the Ada camp, I have never felt the need to have a
constrained integer type (well, beyond Positive or Natural). I have however,
felt the need to have the compiler prevent accidental mixups between a "count
of widgets" and a "count of wingbats".

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: The future of Ada is at risk

[(see below)]

On 13/1/08 03:54, in article ulk6uxtw7.fsf@STRIPCAPStelus.net, "Ray Blaak"
<rAYblaaK@STRIPCAPStelus.net> wrote:
> In fact, since I have left the Ada camp, I have never felt the need to have a
> constrained integer type (well, beyond Positive or Natural). I have however,
> felt the need to have the compiler prevent accidental mixups between a "count
> of widgets" and a "count of wingbats".

Selecting just the integer ranges from some of my code,
and ignoring the float, character, and enumeration ranges,
I find the following:

   subtype a_logger_list_size is Natural range 0..max_logger_list_size;
   subtype a_positive_unsigned is an_unsigned range 1 .. an_unsigned'Last;
   type a_lock_set_index is new Natural range 0..lock_set_size-1;
   subtype nat_integral is integral range 0 .. integral'Last;
   subtype pos_integral is integral range 1 .. integral'Last;
   subtype moebius_integral is integral range -1 .. +1;
   type long_integer is range -2**31 .. + 2**31 - 1;
   subtype generic_nat is generic_int range 0..generic_int'Last;
   subtype generic_pos is generic_int range 1..generic_int'Last;
   subtype rat_nat is rat_int range   0 .. rat_int'Last;
   subtype rat_pos is rat_int range  +1 .. rat_int'Last;
   subtype int_nat is int_int range   0 .. int_int'Last;
   subtype int_pos is int_int range  +1 .. int_int'Last;
   type    an_internal_integer  is range -2**63 .. +2**63-1;
   subtype line_size is Natural range 0..line_size_maximum;
   subtype creat_mode  is i64 range 0 .. 8#777#;
   subtype open_mode   is i64 range 0 .. 1;
   subtype seek_whence is i64 range 0 .. 2;
   subtype an_alignment_mask is a_virtual_address range 0..7;
   buffer_count : Natural range 0 .. retro_buffer_size := 0;
   type a_signed_long is range -2**63 .. +2**63 - 1;
   type a_signed_word is range -2**31..+2**31 - 1;
   type a_signed_half is range -2**15..+2**15 - 1;
   type a_signed_byte is range  -2**7..+2**7 - 1;
   subtype a_word_number is a_virtual_address range 0 .. RAM_size/4 - 1;
   subtype i02 is i04 range 0..3;
   subtype a_size_code is i04 range B_mode..L_mode;

Many of these are what might be called bounded Natural
or bounded Positive; several are dependent on a generic type
or in parameter, although none are dynamic in another way.

I assert that, in context, these are the natural and
necessary ways to achieve my software engineering objectives.
You'll have to trust me on that. 8-)

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: The future of Ada is at risk

[Ray Blaak]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:
> On 13/1/08 03:54, in article ulk6uxtw7.fsf@STRIPCAPStelus.net, "Ray Blaak"
> <rAYblaaK@STRIPCAPStelus.net> wrote:
> > In fact, since I have left the Ada camp, I have never felt the need to
> > have a constrained integer type (well, beyond Positive or Natural). I have
> > however, felt the need to have the compiler prevent accidental mixups
> > between a "count of widgets" and a "count of wingbats".
> 
> Selecting just the integer ranges from some of my code,
> and ignoring the float, character, and enumeration ranges,
> I find the following:
> 
>    subtype a_logger_list_size is Natural range 0..max_logger_list_size;
>    subtype a_positive_unsigned is an_unsigned range 1 .. an_unsigned'Last;
[...]
> I assert that, in context, these are the natural and
> necessary ways to achieve my software engineering objectives.
> You'll have to trust me on that. 8-)

In Ada, sure. I did this instinctively myself. My feeling now is that these
upper bounds are artificial and self imposed. What does it mean to have a
maximum amount of log messages, for example? Design your software so that it
doesn't care. Finite but unbounded is usually a better maximum.

Lower bounds probably matter more.

Perhaps in very controlled or embedded situations where resources are tight,
constrained ranges make sense. And when such ranges are very small (which
tends to mean each integer value has a distinct meaning_ probably using an
enumeration as an index is better (I do miss that, actually).

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: The future of Ada is at risk

[Ray Blaak]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>    subtype an_alignment_mask is a_virtual_address range 0..7;
>    type a_signed_long is range -2**63 .. +2**63 - 1;
>    type a_signed_word is range -2**31..+2**31 - 1;
>    type a_signed_half is range -2**15..+2**15 - 1;
>    type a_signed_byte is range  -2**7..+2**7 - 1;

I buy the bit twiddling ones, actually.

>    subtype open_mode   is i64 range 0 .. 1;
>    subtype seek_whence is i64 range 0 .. 2;

I wonder if these are better as enumerations.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: The future of Ada is at risk

[adaworks]

"Gary Scott" <garylscott@sbcglobal.net> wrote in message 
news:R%6ij.13868$6%.6087@nlpi061.nbdc.sbc.com...
>
> Using a properly structured naming convention is superior to defining a new 
> datatype that is internally identical with dozens of other types but with a 
> different name.  It is especially disastrous in mixed language programming to 
> use too many non-unique data types.  The research necessary to discover the 
> interface is enormous.
>
This depends on the design of the system and where one defines those
types.  When one declares a lot of new types in a global package
specification, your assertion is often true.   However, most experienced
Ada designers do not create global type packages.

Sometimes, it is useful to design a numeric type where there is no visibility
to the structure.   For example, I like to use opaque types in some designs.

Other times, with Ada, we can design a numeric type where the operators
are unique for that type.  For example,

    package Own_Number is
           type Number is private;
           function "+" (L, R : Number) return Number;
           -- functions for all other operators
           Number_Error : exception;
    private
          type Number_Type;
          type Number is access Number_Type;
    end Own_Number;

Now we can constrain the Number_Type within the package body and design
the operators in any way we wish.    While this is extreme, it is sometimes a
useful approach to solving some problems.    I find Ada more amenable to this
kind of design than most languages.

Richard Riehle