Re: ADA Popularity Discussion Request

Re: ADA Popularity Discussion Request

[Robert C. Leif]

         The real reason for Ada's perceived and probably real lack of
popularity is the lack of sales and marketing effort or resources.  For
instance, the Real-Time & Embedded Computing Conferences will be in many
cities including San Diego.  How many companies are selling Ada or SPARK?
Is anyone providing a seminar on Ravenscar or embedded systems in Ada?
            How many Ada companies have exhibited at these meetings this
year?
            Green Hills exhibits.  However, I have never seen them say
anything other than they have Ada.  I am usually the one who asks.  I might
add that the Ada companies still do not have compilers for Windows CE or XP
embedded.  A commercially supported complete version of A# would be perfect
for these operating systems.
            Bob Leif
            ---------------------------------------------------------------
            THE ROLE OF AN OPERATING SYSTEM AND NETWORK STACK IN DESIGNED
HIGH RELIABILITY NETWORKED DEVICES
            presented by Green Hills Software 
            
            Join us for a technical discussion on the role of an operating
system and network stack in designed high reliability networked devices.
We'll discuss networking requirements as well as implementation details to
provide performance, uptime, and response time guarantees for embedded
systems.
            ---------------------------------------------
            "The Real-Time & Embedded Computing Conferences (RTECC) are a
unique, one-day event showcasing the newest products and latest information
from industry leaders."
            http://www.rtecc.com
            Registration is now open for the following locations: 
            San Diego, CA
            August 31, 2004
            
            Long Beach, CA
            September 2, 2004
            
            Helsinki, Finland
            14 September 2004
            
            Toronto, Ontario
            September 17, 2004
            
            Ottawa, Ontario
            September 21, 2004
            
            Montreal, Quebec
            September 23, 2004
            
            Gothenburg, Sweden
            28 September 2004
            
            Oslo, Norway
            30 September 2004
            
            Reston, VA
            October 5, 2004
            
            Patuxent River, MD
            October 7, 2004
            
            Toulouse, France
            26 October 2004
            
            Bristol, United Kingdom
            28 October 2004
            
            Eindhoven, The Netherlands
            4 November 2004
            
            Vancouver, BC
            November 16, 2004
            
            Seattle, WA
            November 18, 2004
             
            

RE: ADA Popularity Discussion Request

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Ole-Hjalmar Kristensen
...
| Yes, I agree. However maybe there is less resistance to doing
| restructuring of the system when it is needed with agile methods?

I think there is less resistance:
1 - because of the continuously up to date regression test suite, changes
are less risky,
2 - and also because it's well known for the management that in agile
method, 5 to 10% of the time is dedicated to refactoring, so you don't feel
unconfortable announcing that you are back working on an existing stuff.
Restructuring is now accepted and not considered more or less like a flaw in
your previous work.

Hopefully, none of those point (complete regression testing and smart
managment) is specific to Agile method.

-- 
Lionel Draghi  

RE: ADA Popularity Discussion Request

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: kevin.cline@gmail.com [mailto:kevin.cline@gmail.com]
...
| 
| The efficacy of much pre-code activity is debatable.  Many
| organizations have had great success with more agile methods of
| minimal up-front design followed by test-driven development and
| continuous refactoring.

Test-driven development includes a part of "pre-code activities". In fact,
test-driven development is an odd name, because it's as much about design
than about test. 

As you said, even wit agile methods, there is still an up-front design to
do. 
Refactoring may let's people thinks that starting almost without design is
less risky with Agile methods, but that's plain wrong.
No one can afford periodically refactoring the whole project because of a
poor architecture.
Settling down the initial design requires experienced and smart guys,
whatever is the method.

So, I don't think there is less time on design and more time on coding in
agile methods. The time is just distributed in a different way. 

-- 
Lionel Draghi  

Re: ADA Popularity Discussion Request

[Ole-Hjalmar Kristensen]

>>>>> "LD" == Lionel DRAGHI <Lionel.DRAGHI@fr.thalesgroup.com> writes:

    LD> | -----Message d'origine-----
    LD> | De: kevin.cline@gmail.com [mailto:kevin.cline@gmail.com]
    LD> ...
    LD> | 
    LD> | The efficacy of much pre-code activity is debatable.  Many
    LD> | organizations have had great success with more agile methods of
    LD> | minimal up-front design followed by test-driven development and
    LD> | continuous refactoring.

    LD> Test-driven development includes a part of "pre-code activities". In fact,
    LD> test-driven development is an odd name, because it's as much about design
    LD> than about test. 

    LD> As you said, even wit agile methods, there is still an up-front design to
    LD> do. 
    LD> Refactoring may let's people thinks that starting almost without design is
    LD> less risky with Agile methods, but that's plain wrong.
    LD> No one can afford periodically refactoring the whole project because of a
    LD> poor architecture.
    LD> Settling down the initial design requires experienced and smart guys,
    LD> whatever is the method.

Yes, I agree. However maybe there is less resistance to doing
restructuring of the system when it is needed with agile methods? This
could be a good thing, in many large projects you tend to get stuck
with the initial design when the system evolves. Sometimes you would
be better off with a major redesign, but it is often put off.

On the other hand, I cannot really see how test-driven development and
continuous refactoring would work on a 2 million LOC soft real time
distributed RDBMS. Usually, there just isn't a substitute for good design.

    LD> So, I don't think there is less time on design and more time on coding in
    LD> agile methods. The time is just distributed in a different way. 

    LD> -- 
    LD> Lionel Draghi  

-- 
   C++: The power, elegance and simplicity of a hand grenade.

ADA Popularity Discussion Request

[Chris Humphries]

Hello,

   Would like to open up the newsgroup for discussion of why
 ADA is not as popular as (of now me learning it) to it is 
 not as popular as other languages (Perl, Java, C++, C#, C).

   I can understand why C is popular, UNIX and all the tools
 for it and most of everything that runs the internet services
 (smtp, http [apache mostly according to netcraft.com], bind).
 Perl (well I use it at work, for legacy reasons of taking over
 code) I can understand due to it just being so easy to get
 something done fast in (and I must say that the regex abilities
 are definitely something that you can get used to quickly, heh.
 CPAN is also a nice feature, tons of modules/libraries to use
 for most everything one command line away.

   Java and C++ got huge during the OOP boom of the 90's, and now
 almost every Computer Science student in college has taken at
 least one of those languages.

   Java does have some nice OO abilities and there are a ton of
 libraries for it. C++ has some OO-ish abilities, yet can be 
 compiled and also has a ton of libraries.

   Yet as I grew in my programming experience and abilities, I
 learned that most of my time was spent updating and fixing code.

   C/C++ took a lot of time to develop in, and I didn't like 
 having to worry about memory management and use my gdb-fu to
 figure out why something did not work.

   Perl is somewhat better, though it is mostly just if syntax
 doesn't match up right. If it is quick and dirty, Perl excels.
 Granted, I do have a written from bottom up programs we now use
 in the company here as a core part of daily life and it is in
 nothing by Perl.
   
   Java is kinda nice, but honestly the dependency of the VM is
 nice in concept, but a pain in real life. You need to make sure
 that your program either is portable to several versions of
 virtual machines or you have to bundle your own (for client apps).
 Java is just too slow (I can not afford the hardware or even justify
 it's use of hardware money to make it's speed comparable with other
 "free" alternatives) for cgi based applications, though the whole
 application server thing with db connection pooling is cool.

   Python is nice too, and I suppose no real reason to not use it.
 I have coded python since 1.5 and early Zope releases. I just would
 like to not code in it anymore, though reason are because I am 
 sick of it.

   So, why is ADA not as popular as the above languages to the
 world (well especially opensource developers) outside of dod and
 defense contractors and banks? It seems like an extremely powerful
 and awesome language, and it is just so easy to look at the code
 and tell what is going on and what is what. It can be OO and can
 run tasks concurrently. It's runtime and compile checking is awesome.
 GNAT is free and available to all to use.

  So what is stopping ADA from being a language everyone knows? Is
 it just viewed as old and arcane like COBOL and Fortran (no offense
 to those that know these languages better than me)? Is it just lacking
 some killer apps? Is it because most ADA is closed source, so there
 are just not libraries out there (like a SSH library)?

Thanks,
Chris

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Chris Humphries wrote:
>    Would like to open up the newsgroup for discussion of why
>  ADA is not as popular as (of now me learning it) to it is 
>  not as popular as other languages (Perl, Java, C++, C#, C).

Aagh! Run for your lives! :-)

Re: ADA Popularity Discussion Request

[sk]

 > Aagh! Run for your lives! :-)

How about we just shoot the messanger ? :-)

Re: ADA Popularity Discussion Request

[Marc A. Criley]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1092233689.719755@master.nyc.kbcfp.com...
> Chris Humphries wrote:
> >    Would like to open up the newsgroup for discussion of why
> >  ADA is not as popular as (of now me learning it) to it is
> >  not as popular as other languages (Perl, Java, C++, C#, C).
>
> Aagh! Run for your lives! :-)

Oh, what the hell...   :-)

My take on why the Ada language itself (regardless of availability of tools
and libraries and such) isn't as popular among programmers as other
languages:

Every programmer thinks they're better than average--half of them are wrong.

Most programmers think they're much better than average--most are not.

Ada's enforcement of strong typing and runtime checks points out when a
programmer has made a mistake, whether as a result of requirements, design,
or coding error. (Of course no one is suggesting that Ada would catch all
requirements or design errors--that's a ridiculous mischaracterization--but
when errant reqs or design lead to a particular implementation, internal
contradictions may result in type conflicts or constraint errors.)

Over the years I've heard much cursing from coworkers about how they can't
get their Ada program to compile, or it just keeps raising these exceptions
when they run it, and they don't have anything like that to deal with when
coding in C or C++. Here's a clue: the problem isn't with the language! Fix
your code!

So Ada has the "unfortunate" characteristic of strictly enforcing what a
programmer codes, and therefore when errors are present there's no sliding
by with out-of-range data or quiet ignoring of inconsistent interfaces or
arguments. The language hits you over the head with them, and makes you deal
with your errors right now. Which can sometimes be a humbling experience.

Marc A. Criley
McKae Technologies
"The Efficient Production of High Quality Software"

Re: ADA Popularity Discussion Request

[Larry Kilgallen]

In article <2nutq5F4sdqqU1@uni-berlin.de>, "Marc A. Criley" <mcNOSPAM@mckae.com> writes:
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1092233689.719755@master.nyc.kbcfp.com...
>> Chris Humphries wrote:
>> >    Would like to open up the newsgroup for discussion of why
>> >  ADA is not as popular as (of now me learning it) to it is
>> >  not as popular as other languages (Perl, Java, C++, C#, C).
>>
>> Aagh! Run for your lives! :-)
> 
> Oh, what the hell...   :-)
> 
> My take on why the Ada language itself (regardless of availability of tools
> and libraries and such) isn't as popular among programmers as other
> languages:
> 
> Every programmer thinks they're better than average--half of them are wrong.
> 
> Most programmers think they're much better than average--most are not.

That is a good concept.  I think a more terse presentation would be:

	Disuse of Ada is because it appeals only to humble programmers.

Re: ADA Popularity Discussion Request

[Brian May]

>>>>> "Marc" == Marc A Criley <mcNOSPAM@mckae.com> writes:

    Marc> Ada's enforcement of strong typing and runtime checks points
    Marc> out when a programmer has made a mistake, whether as a
    Marc> result of requirements, design, or coding error. (Of course
    Marc> no one is suggesting that Ada would catch all requirements
    Marc> or design errors--that's a ridiculous
    Marc> mischaracterization--but when errant reqs or design lead to
    Marc> a particular implementation, internal contradictions may
    Marc> result in type conflicts or constraint errors.)

Ada has a lot of rules which you have to comply with when
programming. I suspect some programmers find these rules obscure,
weird and limiting[1]. These people prefer the freedom in other
languages like Perl where there is infinity+1 ways of doing the same
thing.

Personally, if I make a mistake, I want to find out sooner rather then
later, and this requires good compiler time checking. Even if the
program is not a mission critical program. Ada is the language I know
with the highest level of checks at compile time.

There is the argument that languages like PHP are best for quick&dirty
prototypes.  The counter argument is that these quick&dirty prototypes
often evolve into the one complicated mess of code that everyone
relies on.

I can't understand the trend in the other direction towards languages
like PHP, if you make a typo in a function name for instance, you
won't realize until that like of code is executed, and even then you
might miss the error message (for instance if it is not on screen).

Worst case scenario I have had is if you accidently change low-usage
code (e.g. error handling) unintentionally (e.g. by typing in wrong
window), you may not realize (although a good version control system
may help, if you check every commit) until months later. You have no
need to retest this code either, it was working last time...

I have also seen cases when the programmer (myself) included have
considered the C compiler broken because it says undefined variable
when it looks identical, when in actual fact it is mistyped - the same
thing is much more confusing if you just get random results instead of
an error. Examples: "OK" instead of "Ok" and "Saved_XYZ" vs
"Save_XYZ".

Then in another extreme, while the SPIM program (MIPS emulator) is
very fussy about program code, on certain errors it won't generate any
messages, but instead ignore all code past that point. Any symbols
defined beyond that point will be flagged as undefined. Now this is
pure evil...

Ada is also seen as a procedural language as opposed to an object
orientated language. I don't know why, I believe it has all the key
features of an OO language, eg. inheritance, run-time binding to
functions, etc. Sure it doesn't have the "object->function" syntax,
but none of my notes on OO programming say this is required. As stated
elsewhere, Ada2005 will be even better.

Notes:

[1] It is interesting to note that the same arguments of "rules" vs.
"flexibility" don't only apply to programming. For instance, in
aviation, I have heard some pilots prefer flying in USA compared with
Australia because airspace rules are more flexible. At the same time,
there are air traffic controllers in USA who complain that the rules
are too flexible, and this limits safety.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada Popularity Discussion Request

[Puckdropper]

I'm a sophomore in a Computer Science degree.  When I found out last 
year that we were going to be using Ada to program, I was surprised to 
find it was still in use.  I had only read about it in some old books. 
I thought everyone used C except a select few who still hung on to BASIC 
(like me) or some other old language.

 From someone who's learning Ada, I'd like to suggest a few problems 
I've had so far in learning it:
1) Lack of good tutorial-type documentation.  (I can't find it if it 
exists.  Michael Feldman likes to do about 5 things per example in his 
books, and I don't want to do all 5, just one.  It's hard to extract the 
data from there.)
2) Poor explanations of what something does.  I'm looking for a sentence 
to a paragraph discribing what a package does, not what it includes.  An 
example of what I want is:  "AdaGraph is a package that allows for 
graphical programming and basic mouse control.  You are limited to only 
16 colors."

I suppose what would help Ada tremendously is doing something to be 
picked up by the news stations.  Unfortunately, news stations tend to 
want to warn you more than inform you.

Puckdropper
--
www.uncreativelabs.net

Old computers are getting to be a lost art. Here at Uncreative Labs, we 
still enjoy using the old computers. Sometimes we want to see how far a 
particular system can go, other times we use a stock system to remind 
ourselves of what we once had.

To email me directly, send a message to puckdropper (at) fastmail.fm

Re: ADA Popularity Discussion Request

[Wes Groleau]

Brian May wrote:
> There is the argument that languages like PHP are best for quick&dirty
> prototypes.  The counter argument is that these quick&dirty prototypes
> often evolve into the one complicated mess of code that everyone
> relies on....

... but no one understands.  :-)

> I have also seen cases when the programmer (myself) included have
> considered the C compiler broken because it says undefined variable
> when it looks identical, when in actual fact it is mistyped - the same
> thing is much more confusing if you just get random results instead of
> an error. Examples: "OK" instead of "Ok" and "Saved_XYZ" vs
> "Save_XYZ".

I just love the times where the warning (unless, as usual,
warnings are turned off) says "this is undefined, so I'll
just make it an int"


-- 
Wes Groleau

Expert, n.:
         Someone who comes from out of town and shows slides.

Re: ADA Popularity Discussion Request

[Warren W. Gay VE3WWG]

Brian May wrote:
>>>>>>"Marc" == Marc A Criley <mcNOSPAM@mckae.com> writes:
>     Marc> Ada's enforcement of strong typing and runtime checks points
>     Marc> out when a programmer has made a mistake, whether as a
>     Marc> result of requirements, design, or coding error. (Of course
>     Marc> no one is suggesting that Ada would catch all requirements
>     Marc> or design errors--that's a ridiculous
>     Marc> mischaracterization--but when errant reqs or design lead to
>     Marc> a particular implementation, internal contradictions may
>     Marc> result in type conflicts or constraint errors.)
> 
> Ada has a lot of rules which you have to comply with when
> programming. I suspect some programmers find these rules obscure,
> weird and limiting[1]. These people prefer the freedom in other
> languages like Perl where there is infinity+1 ways of doing the same
> thing.
> 
> Personally, if I make a mistake, I want to find out sooner rather then
> later, and this requires good compiler time checking. Even if the
> program is not a mission critical program. Ada is the language I know
> with the highest level of checks at compile time.

Agree completely.

> There is the argument that languages like PHP are best for quick&dirty
> prototypes.  The counter argument is that these quick&dirty prototypes
> often evolve into the one complicated mess of code that everyone
> relies on.

This reminds me of Perl. I have always maintained that Perl
has its place, but not in "production".

> I can't understand the trend in the other direction towards languages
> like PHP, if you make a typo in a function name for instance, you
> won't realize until that like of code is executed, and even then you
> might miss the error message (for instance if it is not on screen).

Postscript is very much like this (nice language for what it
does). You write out your code and you execute it. Ie. you
go from writing the code straight into debugging. There is
not even a precompile step (like BASIC). And if your testing
doesn't cover all of the cases (path coverage), then surprises
lurk for you on some future black Monday.

I have to say that for most applications, I would rather
have as much static analysis done up front as possible. This
substantially reduces the need for testing for non-mission
critical things. With dynamic languages (like Postscript for
example), you need to test everything to have any confidence
at all in the code.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:

: With dynamic languages (like Postscript for
: example), you need to test everything to have any confidence
: at all in the code.

I had thought that even with dynamic languages you can
show that a given algorithm is correct. When the language
is welldefined. Can the following Postscript program fail?

%!
newpath
10 10 moveto
100 0 rlineto
0 100 rlineto
100 neg 0 rlineto
closepath
stroke
showpage


-- Georg

Re: ADA Popularity Discussion Request

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> 
> : With dynamic languages (like Postscript for
> : example), you need to test everything to have any confidence
> : at all in the code.
> 
> I had thought that even with dynamic languages you can
> show that a given algorithm is correct. When the language
> is welldefined. Can the following Postscript program fail?
> 
> %!
> newpath
> 10 10 moveto
> 100 0 rlineto
> 0 100 rlineto
> 100 neg 0 rlineto
> closepath
> stroke
> showpage

It can, if the code executing prior to it has
redefined "neg" for example. This is all beside
the point, because anyone can produce small
examples. They don't prove anything in general.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
: It can, if the code executing prior to it has
: redefined "neg" for example. This is all beside
: the point, because anyone can produce small
: examples. They don't prove anything in general.

OK, if the meaning of predefined identifiers if changed,
there is nothing to prove. OTOH, there is nothing to be
tested in such a language, because you could as well assume
that the value of an expression is a function of time...

-- Georg

Re: ADA Popularity Discussion Request

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> : It can, if the code executing prior to it has
> : redefined "neg" for example. This is all beside
> : the point, because anyone can produce small
> : examples. They don't prove anything in general.
> 
> OK, if the meaning of predefined identifiers if changed,
> there is nothing to prove. OTOH, there is nothing to be
> tested in such a language, because you could as well assume
> that the value of an expression is a function of time...
> 
> -- Georg

Exactly - welcome to dynamic languages! ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: ADA Popularity Discussion Request

[Kevin Cline]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<5ksXc.22738$_H5.696424@news20.bellglobal.com>...
> Brian May wrote:
> >>>>>>"Marc" == Marc A Criley <mcNOSPAM@mckae.com> writes:
> >     Marc> Ada's enforcement of strong typing and runtime checks points
> >     Marc> out when a programmer has made a mistake, whether as a
> >     Marc> result of requirements, design, or coding error. (Of course
> >     Marc> no one is suggesting that Ada would catch all requirements
> >     Marc> or design errors--that's a ridiculous
> >     Marc> mischaracterization--but when errant reqs or design lead to
> >     Marc> a particular implementation, internal contradictions may
> >     Marc> result in type conflicts or constraint errors.)
> > 
> > Ada has a lot of rules which you have to comply with when
> > programming. I suspect some programmers find these rules obscure,
> > weird and limiting[1]. These people prefer the freedom in other
> > languages like Perl where there is infinity+1 ways of doing the same
> > thing.
> > 
> > Personally, if I make a mistake, I want to find out sooner rather then
> > later, and this requires good compiler time checking. Even if the
> > program is not a mission critical program. Ada is the language I know
> > with the highest level of checks at compile time.
> 
> Agree completely.
> 
> > There is the argument that languages like PHP are best for quick&dirty
> > prototypes.  The counter argument is that these quick&dirty prototypes
> > often evolve into the one complicated mess of code that everyone
> > relies on.
> 
> This reminds me of Perl. I have always maintained that Perl
> has its place, but not in "production".

But there are millions of lines of Perl serving web pages reliably
every day.
When I was at DSC we used Tcl/Tk to build production GUIs for telecom
switch control, and found it about ten times more productive than
building Motif GUIs in C++.  Customers were very happy because we
could redesign the GUI to meet their needs interactively.  No
compiling or linking -- just make the change and go.

Reducing line count by programming at a higher level is an effective
way to reduce the bug count.  It's possible to find libraries for C++
or Ada that will provide the built-in features of Perl, but relatively
few development projects bother to use them.  Instead programmers
laboriously and incorrectly hand-code things like string manipulations
that could be done correctly in Perl in a few seconds.

> > I can't understand the trend in the other direction towards languages
> > like PHP, if you make a typo in a function name for instance, you
> > won't realize until that like of code is executed, and even then you
> > might miss the error message (for instance if it is not on screen).

If your Ada code raises Constraint_Error, you won't realize that until
you execute it.  I don't see the big difference between a
Constraint_Error and a missing function error.  Since the compiler
can't catch all the errors, I still have to test.  And if I'm going to
test anyway, trivial errors like misspelled function names will be
discovered pretty quickly.

> I have to say that for most applications, I would rather
> have as much static analysis done up front as possible. This
> substantially reduces the need for testing for non-mission
> critical things.

I'm skeptical of this argument.  Are you saying that you have no
problems delivering code that has never been tested?

I have learned to write the tests first just to make sure that I know
exactly what I'm trying to do before I start doing it.  And since
every line of code is tested, static analysis doesn't add much.  If it
slows down the test execution so that I have to wait idle for more
than a few secondes, then it breaks the flow and is more of a
distraction than it's worth.

Re: ADA Popularity Discussion Request

[jayessay]

kevin.cline@gmail.com (Kevin Cline) writes:

> "Warren W. Gay VE3WWG"
> > Brian May wrote:
> > >>>>>>"Marc" == Marc A Criley <mcNOSPAM@mckae.com> writes:
>
> > > I can't understand the trend in the other direction towards languages
> > > like PHP, if you make a typo in a function name for instance, you
> > > won't realize until that like of code is executed, and even then you
> > > might miss the error message (for instance if it is not on screen).
> 
> If your Ada code raises Constraint_Error, you won't realize that until
> you execute it.  I don't see the big difference between a
> Constraint_Error and a missing function error.  Since the compiler
> can't catch all the errors, I still have to test.  And if I'm going to
> test anyway, trivial errors like misspelled function names will be
> discovered pretty quickly.

In practice, I have found Kevin's position here to be exactly right.
Typos are found immediately.  The real problem here is that static
typing (certainly as found in non formal type systems like
Ada/C++/Eiffel/etc.) solves a problem that is actually fairly trivial.
Note: The _solution_ is highly _non_ trivial.


> > I have to say that for most applications, I would rather
> > have as much static analysis done up front as possible. This
> > substantially reduces the need for testing for non-mission
> > critical things.
> 
> I'm skeptical of this argument.  Are you saying that you have no
> problems delivering code that has never been tested?

I would go beyond Kevin here and claim that the proposition (as much
static analysis up front for most applications) is exactly backward.
In nearly all applications this basically becomes a recipe for "naval
gazing".


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Jerry Petrey]

Chris Humphries wrote:

> Hello,
>
>    Would like to open up the newsgroup for discussion of why
>  ADA is not as popular as (of now me learning it) to it is
>  not as popular as other languages (Perl, Java, C++, C#, C).
>
> Thanks,
> Chris

ADA is very popular.  Almost all dentists are members of it.
Now if you're talking about Ada, the language ... that's another story.

Jerry
--
---------------------------------------------------------------------
-- Jerry Petrey   -   Senior Principal Systems Engineer
-- Navigation (GPS/INS), Guidance, & Control
-- Raytheon Missile Systems  - Member Team Ada & Team Forth
-- NOTE: please perform appendectomy on email address before replying
---------------------------------------------------------------------

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Jerry Petrey wrote:
> ADA is very popular.  Almost all dentists are members of it.
> Now if you're talking about Ada, the language ... that's another story.

Oh no! It's starting! I'm scared, mommy!

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Jerry Petrey wrote:
:> ADA is very popular.  Almost all dentists are members of it.
:> Now if you're talking about Ada, the language ... that's another story.
: 
: Oh no! It's starting! I'm scared, mommy!

How is Michael Jackson, BTW?

Re: ADA Popularity Discussion Request

[Nick Roberts]

On 11 Aug 2004 06:56:17 -0700, Chris Humphries <chris@unixfu.net> wrote:

>    Would like to open up the newsgroup for discussion of why
>  ADA is not as popular as (of now me learning it) to it is
>  not as popular as other languages (Perl, Java, C++, C#, C).

I'm pretty sure the main reasons are: that there has never been a
(really) big corporation backing Ada, in the same way that many of the
languages you mention have had; that Ada is not a language suited for
or much liked by many non-professional programmers.

Microsoft have a huge historical investment in Basic (VB), C (in which
Windows was written (it was nearly Pascal)), C++ (in which they hedged
the future of their C codebase). They have poured vast resources into
developing and marketing tools supporting these languages. The latest
big thing from Microsoft is C#, and they have promoted it relentlessly.

Sun's fortunes were founded on Unix, so they have a huge vested
interest in the C language. They have done much to promote both. Lately,
Sun have placed all their faith in Java, and they have poured vast
resources into popularising it.

Languages such as Javascript, Perl, PHP, Python, Ruby, and many others
have gained popularity with non-professional programmers, who are
several orders of magnitude greater in number than the professionals,
thus boosting the following of these languages to such large numbers as
to create their own unstoppable momentum. This is not to denegrate
non-pros, by the way; some of these languages are now used by pros, for
applications they are suited to. It's not to dengrate the languages,
either. I think Python and Ruby are both excellent designs.

>    So, why is ADA not as popular as the above languages to the
>  world (well especially opensource developers) outside of dod and
>  defense contractors and banks? It seems like an extremely powerful
>  and awesome language,

Ada isn't really an awesome or extremely powerful language. It has
many advantages over many other compiled imperative languages,
including C (and probably also C++, C#, and Java). It also has its
fair share of limitations and annoying quirks.

>  and it is just so easy to look at the code and tell what is going
>  on and what is what.

If the program is well written. C code /can/ be easy to look at etc.,
but it tends not to be in practice. Honestly, this is probably because
most C code is written by bad programmers, whereas most Ada code is
not. I have seen superb C code (often written by a non-pro, what is
more). Ada does /help/ the programmer to write good code.

>  It can be OO

Albeit a somewhat limited form of OO :-) Actually, Ada 2005 promises
to be much better in this area.

>  and can run tasks concurrently.

I think this is one of Ada's greatest strengths.

>  It's runtime and compile checking is awesome.

It's good, and certainly one of the biggest practical advantages of
the language. However, there are many other languages that have
good checking (C and C++ are notably not among them).

>  GNAT is free and available to all to use.

Yes, and GNAT is one of the language's biggest assets. It is of very
high quality, and is used in many commercial applications.

Programming languages are very much a case of horses for courses,
and there are many, many courses that Python and other languages are
far better suited to than Ada. For /some/ kinds of application
(typically embedded, systems, and safety-critical software) Ada is
one of the classiest acts in town.

I am currently considering Python or Ruby to write an XML
application, in preference to Ada, because it will probably be a lot
easier to write this kind of application in Python or Ruby, both
because of the languages themselves, and also because of the superb
utility libraries available for them.

Now, where did I put that asbestos suit?

-- 
Nick Roberts

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Nick Roberts wrote:
 > The latest big thing from Microsoft is C#,
 > and they have promoted it relentlessly.

They are also working on an implementation and
ISO standard for C++/CLI, which is an extension
of C++ to support garbage collection and the CLI
data objects with minimal intrusiveness into C++
standard-conforming code.

Re: ADA Popularity Discussion Request

[Marin David Condic]

In fairness, the DoD actually *did* throw a lot of money at Ada. IMHO, 
it just didn't get spent effectively. Not much was done to "Market" the 
language or "Prime The Pump" by getting good, inexpensive compilers out 
into the hands of lots of programmers. Gnat was a good example of how 
that can help, but it came along rather late in the day and by then, 
opinions had been formed and other things had come along that had 
captured the market better, so it wasn't as effective as it might have been.

(Imagine what the world would have been like if back in 1983, the DoD 
had funded a free compiler of descent quality that would run on a PC or 
some of the other popular hardware of the day. There wasn't anything 
quite like that back then and maybe people would have used it just 
because it was the only free compiler you could get.)

Ada still has a pretty good following, but it does need to expand on 
that base. Things like Gnat and GtkAda help provide some of the 
necessary infrastructure. An "Out Of The Box" database and a library of 
utilities that goes along with it would be good additions that would 
help provide a more complete programming kit. That, and a little 
"Newness" that could be hyped as providing something you can't get 
elsewhere and Ada might see some new growth in new arenas.

MDC


Nick Roberts wrote:
> 
> I'm pretty sure the main reasons are: that there has never been a
> (really) big corporation backing Ada, in the same way that many of the
> languages you mention have had; that Ada is not a language suited for
> or much liked by many non-professional programmers.

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: ADA Popularity Discussion Request

[Adrian Hoe]

Nick Roberts wrote:
> 
> I'm pretty sure the main reasons are: that there has never been a
> (really) big corporation backing Ada, in the same way that many of the
> languages you mention have had; that Ada is not a language suited for
> or much liked by many non-professional programmers.
> 
> Microsoft have a huge historical investment in Basic (VB), C (in which
> Windows was written (it was nearly Pascal)), C++ (in which they hedged
> the future of their C codebase). They have poured vast resources into
> developing and marketing tools supporting these languages. The latest
> big thing from Microsoft is C#, and they have promoted it relentlessly.
> 
> Sun's fortunes were founded on Unix, so they have a huge vested
> interest in the C language. They have done much to promote both. Lately,
> Sun have placed all their faith in Java, and they have poured vast
> resources into popularising it.


Yes. You are right. There has never been a corporation to sponsor Ada. 
Unlike Java and C# which have vigorous and aggressive advertisement 
sponsored by Sun and M$ respectively. They are the owner of the 
respective "products". Sun has invested millions of dollars to promote 
Java, for example, Sun set up a Java Competency Center in Malaysia. 
Millions of dollars were poured in.

People who chose a programming language based on its popularity like 
advertisement and loud noisy announcement, are those have no technical 
merit in evaluating the programming language.

Anyone care to send me an asbestos suit? :)
-- 
Adrian Hoe
m a i l b o x AT a d r i a n h o e . c o m

Re: ADA Popularity Discussion Request

[Marin David Condic]

Here's the problem: We can say "That's not fair!" or "That's not right!" 
all we want, but reality can be a real bitch sometimes. If you don't 
"market" the language in some manner, nobody knows about it or has any 
reason to believe it is superior to what they *do* know about. Shoving 
the lamp under a bushel basket doesn't do much good.

MDC

Adrian Hoe wrote:
> 
> People who chose a programming language based on its popularity like 
> advertisement and loud noisy announcement, are those have no technical 
> merit in evaluating the programming language.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Power corrupts.  Absolute power is kind of neat"
         -- John Lehman, Secretary of the Navy 1981-1987
======================================================================

Re: ADA Popularity Discussion Request

[Adrian Hoe]

Marin David Condic wrote:
> Here's the problem: We can say "That's not fair!" or "That's not right!" 
> all we want, but reality can be a real bitch sometimes. If you don't 
> "market" the language in some manner, nobody knows about it or has any 
> reason to believe it is superior to what they *do* know about. Shoving 
> the lamp under a bushel basket doesn't do much good.
> 
> MDC
> 
> Adrian Hoe wrote:
> 
>>
>> People who chose a programming language based on its popularity like 
>> advertisement and loud noisy announcement, are those have no technical 
>> merit in evaluating the programming language.
>>
> 

But, what did GNAT, Aonix, Intermetrics, Greenhill and other Ada 
compiler vendors do? They did nothing to promote Ada.
-- 
Adrian Hoe
m a i l b o x AT a d r i a n h o e . c o m

Re: ADA Popularity Discussion Request

[Ed Falis]

On Fri, 27 Aug 2004 16:10:34 +0800, Adrian Hoe <AdrianHoe@nowhere.com>  
wrote:

> But, what did GNAT, Aonix, Intermetrics, Greenhill and other Ada  
> compiler vendors do? They did nothing to promote Ada.

What a crock of horse-hockey!

And no, I'm not going to list 15 years of Ada advocacy efforts on the part  
of the vendors.

- Ed

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Ed Falis" <falis@verizon.net> wrote in message
news:opsdeaw7ox5afhvo@localhost...
> On Fri, 27 Aug 2004 16:10:34 +0800, Adrian Hoe <AdrianHoe@nowhere.com>
> wrote:
>
> > But, what did GNAT, Aonix, Intermetrics, Greenhill and other Ada
> > compiler vendors do? They did nothing to promote Ada.
>
> What a crock of horse-hockey!
>
> And no, I'm not going to list 15 years of Ada advocacy efforts on the part
> of the vendors.
>
I will say a few words about this.

Ada Core Technologies has, and continues to have, an initiative
for promoting Ada.   The very fact that GNAT is available free
is a substantial achievement.   Aonix, though more recently less
of an advocated, also has a free compiler and gave away
thousands of copies of its early Ada 95 compiler at conferences
and elsewhere.

During the early years, there was a lot of advocacy.  I recall
getting excellent support for my own advocacy efforts from
Alsys, especially when Lori Heyman was in charge of public
relations there.   Ben Brosgol traveled all over the world
presenting Ada to a wide range of audiences.

Let's not forget the efforts of Ralph Crafts.  He worked his
butt off trying to promote Ada to a larger venue.  He finally
burned out and left the Ada industry, but his work on the
behalf of Ada was second to none.

For Ada 83, we had the Meridian Ada compiler, and the
Janus Ada compiler, both of which were reasonably
priced.   Though Janus was probably a slightly better
compiler, Meridian took the trouble to provide a good
library for writing DOS programs and that made it
popular in a lot of university environments.

Then there were other organizations, composed mostly of
Ada compiler publishers.   When Ada 95 came on the scene,
a large chunk of money was set aside for publicity and
promotion.  Sadly, much of it was squandered on silly
advertisements and posters that had no chance of convincing
anyone.  Even so, the ARA did give it a try even with
very limited resources.

Promotion takes money.  In the current world of Ada, there
is not much of that available.   Some compiler publishers
are not earning much money on Ada at present.  This is
due, in large part, to the move away from Ada toward
other languages for some important military projects.  Few
compiler companies can thrive, at present, by relying
solely on its Ada products.

Ada suffered some early setbacks because of bad policy
decisions on the part of the DoD as well as the compiler
publishers.   When the DoD insisted that all software
be written in a language for which compilers did not
yet exist, it set up a plan for failure.   That policy was
followed with a waiver policy that added to the problem.
Overall, the early DoD management of its Ada initiative
was pretty bad.   The blame for this can be assigned to
a fairly high level within the DoD, indeed, within the
U.S. Government, where officials failed to understand
the value, the importance, of this initiative.

The compiler publishers, all of which were staffed by
a lot of bright, enthusiastic, and conscientious people,
made their own mistakes.   Failure to provide a full
set of facilities for the popular targeted platforms was
one (except for Meridian, cited earlier).  Failure to
coordinate with each other to develop a set of
portable libraries.   Setting prices so high, for the
really good compilers, that Non-DoD companies
could not justify the use of Ada to their own
management.   Failure to fully grasp the impact
of the microcomputer revolution and adapt their
compilers, at appropriate pricing, to meet the
demand (again Meridian and Janus were the
exceptions).    Failure to be flexible enough as
the microcomputer industry evolved through a
variety of human-machine interaction modes.
Failure to develop good file management, database
management, and other libraries that could attract
a larger following.

Ada entered the marketplace at a time of marketplace
change.   The changes were occurring so fast that
a language that could not change at the same pace,
or where tools and libraries could not keep up with
that pace, was bound to be suspect.

Finally, just as Ada reached a point where it was the
ideal solution for a larger range of environments and
applications (free compilers, better tools for windowing
environments, good editors, lots of good libraries, etc),
it had its support cut from under it by the very organization
that needed it most, the DoD.   Funding was cut, the
AdaIC was disbanded, and the developers rushed to
C++ in droves.  It was a classic case where the DoD
grabbed defeat from the jaws of victory.    Ada had
become one of the most effective development tools
available, in my view, far superior to the C++ of the
time, and the DoD management simply abandoned
it.  I continue to encounter DoD officials who seriously
believe that the DoD has now banned the use of
Ada for future software projects.   At present, I know
of no high-ranking DoD official who will rebut that
view.  At present, no one in the DoD, certainly no
one in the Pentagon, wants to have his/her name
publicly associated with Ada in any way.    They look
upon it as a failed project.   How does anyone counter
that view?  How do we revive confidence in Ada once
it has become a pariah among the very people who
will benefit from it?    Sadly, these senior officials
have washed their hands of anything to do with language
selection, and our weapon systems are going to be
awash with awful, unmaintainable software, and
probably less reliable software written in C++.   The
deleterious effects of all this C++ code will not
manifest itself for a long time, and when it does, it
will be too late.

Richard Riehle

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Richard Riehle wrote:
 > The deleterious effects of all this C++ code will not
> manifest itself for a long time, and when it does, it
> will be too late.

Now, now.

Anyway, it's all going to be written in real-time Java :-)

Re: ADA Popularity Discussion Request

[Wes Groleau]

Richard Riehle wrote:
> publicly associated with Ada in any way.    They look
> upon it as a failed project.   How does anyone counter

And they're right.  It failed to achieve the government's
standard level of mediocrity and incompetence.

:-)


-- 
Wes Groleau

There are some ideas so wrong that only a
very intelligent person could believe in them.
                         -- George Orwell

Re: ADA Popularity Discussion Request

[Adrian Hoe]

Richard Riehle wrote:
> "Ed Falis" <falis@verizon.net> wrote in message
> news:opsdeaw7ox5afhvo@localhost...
> 
>>On Fri, 27 Aug 2004 16:10:34 +0800, Adrian Hoe <AdrianHoe@nowhere.com>
>>wrote:
>>
>>
>>>But, what did GNAT, Aonix, Intermetrics, Greenhill and other Ada
>>>compiler vendors do? They did nothing to promote Ada.
>>
>>What a crock of horse-hockey!
>>
>>And no, I'm not going to list 15 years of Ada advocacy efforts on the part
>>of the vendors.
>>
> 
> I will say a few words about this.
> 
> Ada Core Technologies has, and continues to have, an initiative
> for promoting Ada.   The very fact that GNAT is available free
> is a substantial achievement.   Aonix, though more recently less
> of an advocated, also has a free compiler and gave away
> thousands of copies of its early Ada 95 compiler at conferences
> and elsewhere.
> 
> During the early years, there was a lot of advocacy.  I recall
> getting excellent support for my own advocacy efforts from
> Alsys, especially when Lori Heyman was in charge of public
> relations there.   Ben Brosgol traveled all over the world
> presenting Ada to a wide range of audiences.
> 
> Let's not forget the efforts of Ralph Crafts.  He worked his
> butt off trying to promote Ada to a larger venue.  He finally
> burned out and left the Ada industry, but his work on the
> behalf of Ada was second to none.
> 
> For Ada 83, we had the Meridian Ada compiler, and the
> Janus Ada compiler, both of which were reasonably
> priced.   Though Janus was probably a slightly better
> compiler, Meridian took the trouble to provide a good
> library for writing DOS programs and that made it
> popular in a lot of university environments.
> 
> Then there were other organizations, composed mostly of
> Ada compiler publishers.   When Ada 95 came on the scene,
> a large chunk of money was set aside for publicity and
> promotion.  Sadly, much of it was squandered on silly
> advertisements and posters that had no chance of convincing
> anyone.  Even so, the ARA did give it a try even with
> very limited resources.
> 
> Promotion takes money.  In the current world of Ada, there
> is not much of that available.   Some compiler publishers
> are not earning much money on Ada at present.  This is
> due, in large part, to the move away from Ada toward
> other languages for some important military projects.  Few
> compiler companies can thrive, at present, by relying
> solely on its Ada products.
> 
> Ada suffered some early setbacks because of bad policy
> decisions on the part of the DoD as well as the compiler
> publishers.   When the DoD insisted that all software
> be written in a language for which compilers did not
> yet exist, it set up a plan for failure.   That policy was
> followed with a waiver policy that added to the problem.
> Overall, the early DoD management of its Ada initiative
> was pretty bad.   The blame for this can be assigned to
> a fairly high level within the DoD, indeed, within the
> U.S. Government, where officials failed to understand
> the value, the importance, of this initiative.
> 
> The compiler publishers, all of which were staffed by
> a lot of bright, enthusiastic, and conscientious people,
> made their own mistakes.   Failure to provide a full
> set of facilities for the popular targeted platforms was
> one (except for Meridian, cited earlier).  Failure to
> coordinate with each other to develop a set of
> portable libraries.   Setting prices so high, for the
> really good compilers, that Non-DoD companies
> could not justify the use of Ada to their own
> management.   Failure to fully grasp the impact
> of the microcomputer revolution and adapt their
> compilers, at appropriate pricing, to meet the
> demand (again Meridian and Janus were the
> exceptions).    Failure to be flexible enough as
> the microcomputer industry evolved through a
> variety of human-machine interaction modes.
> Failure to develop good file management, database
> management, and other libraries that could attract
> a larger following.
> 
> Ada entered the marketplace at a time of marketplace
> change.   The changes were occurring so fast that
> a language that could not change at the same pace,
> or where tools and libraries could not keep up with
> that pace, was bound to be suspect.
> 
> Finally, just as Ada reached a point where it was the
> ideal solution for a larger range of environments and
> applications (free compilers, better tools for windowing
> environments, good editors, lots of good libraries, etc),
> it had its support cut from under it by the very organization
> that needed it most, the DoD.   Funding was cut, the
> AdaIC was disbanded, and the developers rushed to
> C++ in droves.  It was a classic case where the DoD
> grabbed defeat from the jaws of victory.    Ada had
> become one of the most effective development tools
> available, in my view, far superior to the C++ of the
> time, and the DoD management simply abandoned
> it.  I continue to encounter DoD officials who seriously
> believe that the DoD has now banned the use of
> Ada for future software projects.   At present, I know
> of no high-ranking DoD official who will rebut that
> view.  At present, no one in the DoD, certainly no
> one in the Pentagon, wants to have his/her name
> publicly associated with Ada in any way.    They look
> upon it as a failed project.   How does anyone counter
> that view?  How do we revive confidence in Ada once
> it has become a pariah among the very people who
> will benefit from it?    Sadly, these senior officials
> have washed their hands of anything to do with language
> selection, and our weapon systems are going to be
> awash with awful, unmaintainable software, and
> probably less reliable software written in C++.   The
> deleterious effects of all this C++ code will not
> manifest itself for a long time, and when it does, it
> will be too late.
> 
> Richard Riehle
> 
> 
> 
> 


And no, this is not a crock!

What use to have fully functional and free compiler available for 
download? For someone who has not heard of Ada and does not even know 
the existence of such programming language, how does one come to know 
there is a fully functional and free Ada compiler for download?

Turn the pages of computing magazines, advertisements and projects 
write-outs about Java, Perl, C#, .NET, Delphi, Kylix and etc. come alive 
in front of these magazines readers. Ada?

I knew about Ada when I flipped through a catalog of pirated software 
around mid 1980's. I bought it for M$5 for an Apple CP/M. I could not 
find an Ada book then. After mingling with it for sometimes, I put the 
floppy disk in a cupboard until the end of 1993. I recalled something 
called Ada and did a search on Internet and there began my Ada love affairs.

I read about one article about Alsys Ada in PC Magazine (I can't exactly 
remember the name of the magazine, I hope the name is correct) in late 
80's or early 90's. That's the only article I read about Ada since then 
(I might have missed some other Ada articles in later years).

Providing a free Ada compiler is not enough to promote Ada.
-- 
Adrian Hoe
m a i l b o x AT a d r i a n h o e . c o m

Re: ADA Popularity Discussion Request

[stephane richard]

I agree,

People need to know that Ada exists or they'll never enter any Ada related 
search words hence never get Ada related results on search engines.

Seems all people are looking for today are RAD environments, very integrated 
IDE's with of course code completion and all them time saving mechanisms as 
discussed in another thread on this board.  people that know Ada are on 
comp.lang.ada, the problem is to get people on other languages to see what 
Ada can do.  and that's what lacks the most.  If people don't search for 
specific programming languages, for example, if they search for OpenGL, 
they'll come across the AdaOpenGL project and might be curious about it 
then.  Doesn't seem to be enough to say that Ada was born as a superset of 
Pascal either.  I'm trying to see what could be added to or created to bring 
any programmer to the Ada community.

One thing I did notice is in past "popularity threads" is that Ada 
developers won't change their preferences, hence to know Ada is to love Ada 
(hey that might make a quote somewhere ;-).  But I do think it's true.  I 
think we need a different side of Ada to promote maybe, alot of websites 
I've been to emphasize how Ada is made to work with software Engineering 
methods for example, that's good to software engineers, how many C/C++ or 
Delphi programmers are software engineers?  I'm sure there are some, but 
these languages are promoted to be used for anything at all.  hence the home 
user.   Maybe we need to push more the home user, the fella that wants to 
work in his basement to create the next revolutionary software, the common 
user?  I think if we find the right approach, it can happen.  Now what would 
that approach be?   Of course, to see applications developed in Ada helps, 
but I wonder, if we had enough software developed in Ada, if would help.  A 
free compiler is a good boost, but seems to be insufficient.

So then, I'm on a quest to see what people what to know about Ada that can 
and would convince them to give it a good shot.  Sure Libraries are good, 
Bindings too, but what else?  there must be something else, if there isn't 
then maybe that's the missing link.

Stephane Richard
"Ada World" webmaster
http://www.adaworld.com


"Adrian Hoe" <AdrianHoe@nowhere.com> wrote in message 
news:413812b7_2@news.tm.net.my...
> Richard Riehle wrote:
>> "Ed Falis" <falis@verizon.net> wrote in message
>> news:opsdeaw7ox5afhvo@localhost...
>>
>>>On Fri, 27 Aug 2004 16:10:34 +0800, Adrian Hoe <AdrianHoe@nowhere.com>
>>>wrote:
>>>
>>>
>>>>But, what did GNAT, Aonix, Intermetrics, Greenhill and other Ada
>>>>compiler vendors do? They did nothing to promote Ada.
>>>
>>>What a crock of horse-hockey!
>>>
>>>And no, I'm not going to list 15 years of Ada advocacy efforts on the 
>>>part
>>>of the vendors.
>>>
>>
>> I will say a few words about this.
>>
>> Ada Core Technologies has, and continues to have, an initiative
>> for promoting Ada.   The very fact that GNAT is available free
>> is a substantial achievement.   Aonix, though more recently less
>> of an advocated, also has a free compiler and gave away
>> thousands of copies of its early Ada 95 compiler at conferences
>> and elsewhere.
>>
>> During the early years, there was a lot of advocacy.  I recall
>> getting excellent support for my own advocacy efforts from
>> Alsys, especially when Lori Heyman was in charge of public
>> relations there.   Ben Brosgol traveled all over the world
>> presenting Ada to a wide range of audiences.
>>
>> Let's not forget the efforts of Ralph Crafts.  He worked his
>> butt off trying to promote Ada to a larger venue.  He finally
>> burned out and left the Ada industry, but his work on the
>> behalf of Ada was second to none.
>>
>> For Ada 83, we had the Meridian Ada compiler, and the
>> Janus Ada compiler, both of which were reasonably
>> priced.   Though Janus was probably a slightly better
>> compiler, Meridian took the trouble to provide a good
>> library for writing DOS programs and that made it
>> popular in a lot of university environments.
>>
>> Then there were other organizations, composed mostly of
>> Ada compiler publishers.   When Ada 95 came on the scene,
>> a large chunk of money was set aside for publicity and
>> promotion.  Sadly, much of it was squandered on silly
>> advertisements and posters that had no chance of convincing
>> anyone.  Even so, the ARA did give it a try even with
>> very limited resources.
>>
>> Promotion takes money.  In the current world of Ada, there
>> is not much of that available.   Some compiler publishers
>> are not earning much money on Ada at present.  This is
>> due, in large part, to the move away from Ada toward
>> other languages for some important military projects.  Few
>> compiler companies can thrive, at present, by relying
>> solely on its Ada products.
>>
>> Ada suffered some early setbacks because of bad policy
>> decisions on the part of the DoD as well as the compiler
>> publishers.   When the DoD insisted that all software
>> be written in a language for which compilers did not
>> yet exist, it set up a plan for failure.   That policy was
>> followed with a waiver policy that added to the problem.
>> Overall, the early DoD management of its Ada initiative
>> was pretty bad.   The blame for this can be assigned to
>> a fairly high level within the DoD, indeed, within the
>> U.S. Government, where officials failed to understand
>> the value, the importance, of this initiative.
>>
>> The compiler publishers, all of which were staffed by
>> a lot of bright, enthusiastic, and conscientious people,
>> made their own mistakes.   Failure to provide a full
>> set of facilities for the popular targeted platforms was
>> one (except for Meridian, cited earlier).  Failure to
>> coordinate with each other to develop a set of
>> portable libraries.   Setting prices so high, for the
>> really good compilers, that Non-DoD companies
>> could not justify the use of Ada to their own
>> management.   Failure to fully grasp the impact
>> of the microcomputer revolution and adapt their
>> compilers, at appropriate pricing, to meet the
>> demand (again Meridian and Janus were the
>> exceptions).    Failure to be flexible enough as
>> the microcomputer industry evolved through a
>> variety of human-machine interaction modes.
>> Failure to develop good file management, database
>> management, and other libraries that could attract
>> a larger following.
>>
>> Ada entered the marketplace at a time of marketplace
>> change.   The changes were occurring so fast that
>> a language that could not change at the same pace,
>> or where tools and libraries could not keep up with
>> that pace, was bound to be suspect.
>>
>> Finally, just as Ada reached a point where it was the
>> ideal solution for a larger range of environments and
>> applications (free compilers, better tools for windowing
>> environments, good editors, lots of good libraries, etc),
>> it had its support cut from under it by the very organization
>> that needed it most, the DoD.   Funding was cut, the
>> AdaIC was disbanded, and the developers rushed to
>> C++ in droves.  It was a classic case where the DoD
>> grabbed defeat from the jaws of victory.    Ada had
>> become one of the most effective development tools
>> available, in my view, far superior to the C++ of the
>> time, and the DoD management simply abandoned
>> it.  I continue to encounter DoD officials who seriously
>> believe that the DoD has now banned the use of
>> Ada for future software projects.   At present, I know
>> of no high-ranking DoD official who will rebut that
>> view.  At present, no one in the DoD, certainly no
>> one in the Pentagon, wants to have his/her name
>> publicly associated with Ada in any way.    They look
>> upon it as a failed project.   How does anyone counter
>> that view?  How do we revive confidence in Ada once
>> it has become a pariah among the very people who
>> will benefit from it?    Sadly, these senior officials
>> have washed their hands of anything to do with language
>> selection, and our weapon systems are going to be
>> awash with awful, unmaintainable software, and
>> probably less reliable software written in C++.   The
>> deleterious effects of all this C++ code will not
>> manifest itself for a long time, and when it does, it
>> will be too late.
>>
>> Richard Riehle
>>
>>
>>
>>
>
>
> And no, this is not a crock!
>
> What use to have fully functional and free compiler available for 
> download? For someone who has not heard of Ada and does not even know the 
> existence of such programming language, how does one come to know there is 
> a fully functional and free Ada compiler for download?
>
> Turn the pages of computing magazines, advertisements and projects 
> write-outs about Java, Perl, C#, .NET, Delphi, Kylix and etc. come alive 
> in front of these magazines readers. Ada?
>
> I knew about Ada when I flipped through a catalog of pirated software 
> around mid 1980's. I bought it for M$5 for an Apple CP/M. I could not find 
> an Ada book then. After mingling with it for sometimes, I put the floppy 
> disk in a cupboard until the end of 1993. I recalled something called Ada 
> and did a search on Internet and there began my Ada love affairs.
>
> I read about one article about Alsys Ada in PC Magazine (I can't exactly 
> remember the name of the magazine, I hope the name is correct) in late 
> 80's or early 90's. That's the only article I read about Ada since then (I 
> might have missed some other Ada articles in later years).
>
> Providing a free Ada compiler is not enough to promote Ada.
> -- 
> Adrian Hoe
> m a i l b o x AT a d r i a n h o e . c o m
> 

Re: ADA Popularity Discussion Request

[Björn Persson]

stephane richard wrote:

> People need to know that Ada exists or they'll never enter any Ada related 
> search words hence never get Ada related results on search engines.

Oh I think most programmers know it exists. The problem is that they 
seem to think its name is "Oh no, not Ada!", and that's all they know 
about it.

> Maybe we need to push more the home user, the fella that wants to 
> work in his basement to create the next revolutionary software, the common 
> user?

That'd be me. Well, I don't think what I've done so far is exactly 
revolutionary, but I have dreams. :-)

I don't need to see ads for something in every magazine to get 
interested. Excessive advertising is more likely to drive me away. When 
I read about computer languages, protocols, programs or operating 
systems I often want to try them out. In most cases I never get around 
to it; there are just too many things to try. What made me actually try 
Ada was a section about exception handling in a book. I had been coding 
in Turbo Pascal and been annoyed at all the error handling I had to do 
all over the code. I instantly knew I wanted exceptions. And the code 
example in that section was in Ada. So, maybe we should sprinkle the Web 
with short examples of how to do things in Ada that other languages 
can't do?

Free software enthusiasts take pride in making more stable and secure 
software than the closed source vendors, and at least some of them are 
frustrated over the never-ceasing stream of security holes in everything 
from kernels to media players. They usually think better testing and 
more code review is the answer. I do my best to spread the idea that 
buffer overflows are caused by a bad choice of language.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: ADA Popularity Discussion Request

[fabio de francesco]

chris@unixfu.net (Chris Humphries) wrote in message news:<49dc98cf.0408110556.18ae7df@posting.google.com>...
> Hello,
> 
>    Would like to open up the newsgroup for discussion of why
>  ADA is not as popular as (of now me learning it) to it is 
>  not as popular as other languages (Perl, Java, C++, C#, C).
> 
>    I can understand why C is popular, UNIX and all the tools
>  for it and most of everything that runs the internet services
>  (smtp, http [apache mostly according to netcraft.com], bind).
>  Perl (well I use it at work, for legacy reasons of taking over
>  code) I can understand due to it just being so easy to get
>  something done fast in (and I must say that the regex abilities
>  are definitely something that you can get used to quickly, heh.
>  CPAN is also a nice feature, tons of modules/libraries to use
>  for most everything one command line away.
> 
>    Java and C++ got huge during the OOP boom of the 90's, and now
>  almost every Computer Science student in college has taken at
>  least one of those languages.
> 
>    Java does have some nice OO abilities and there are a ton of
>  libraries for it. C++ has some OO-ish abilities, yet can be 
>  compiled and also has a ton of libraries.
> 
>    Yet as I grew in my programming experience and abilities, I
>  learned that most of my time was spent updating and fixing code.
> 
>    C/C++ took a lot of time to develop in, and I didn't like 
>  having to worry about memory management and use my gdb-fu to
>  figure out why something did not work.

I also must thank Ada for not to make me spend my time playing with
the debugger.

>    Perl is somewhat better, though it is mostly just if syntax
>  doesn't match up right. If it is quick and dirty, Perl excels.
>  Granted, I do have a written from bottom up programs we now use
>  in the company here as a core part of daily life and it is in
>  nothing by Perl.

I can't imagine anything less readable than Perl. I see it like the
exact opposite of Ada for that.
    
>    Java is kinda nice, but honestly the dependency of the VM is
>  nice in concept, but a pain in real life. You need to make sure
>  that your program either is portable to several versions of
>  virtual machines or you have to bundle your own (for client apps).
>  Java is just too slow (I can not afford the hardware or even justify
>  it's use of hardware money to make it's speed comparable with other
>  "free" alternatives) for cgi based applications, though the whole
>  application server thing with db connection pooling is cool.
> 
>    Python is nice too, and I suppose no real reason to not use it.
>  I have coded python since 1.5 and early Zope releases. I just would
>  like to not code in it anymore, though reason are because I am 
>  sick of it.
> 
>    So, why is ADA not as popular as the above languages to the
>  world (well especially opensource developers) outside of dod and
>  defense contractors and banks? It seems like an extremely powerful
>  and awesome language, and it is just so easy to look at the code
>  and tell what is going on and what is what. It can be OO and can
>  run tasks concurrently. It's runtime and compile checking is awesome.
>  GNAT is free and available to all to use.

Since a couple of months I have been learning Ada95 and I like it much
more than C/C++, even if I can say I am a good programmer with the
latter ones.
I think that the lack of Ada programmers produces little amount of
code to expand and to maintain and this produces little interest in
becoming an Ada programmer. I think that the more software (
especially more open source software ) in a specific language exists
the more programmers in this language are needed.

I was leaded to learn C/C++ because I wanted to understand how my
Linux box worked, seen that from the kernel to the vast majority of
the user applications have been written with those. So I started to
hack that C/C++ code.

There is nobody I know that need Ada programs, so why matter? Just for
fun, but not for more I suppose. If Linux and the user apps had been
made with Ada I would had begun to learn this beautiful language a
long time before.

>   So what is stopping ADA from being a language everyone knows? Is
>  it just viewed as old and arcane like COBOL and Fortran (no offense
>  to those that know these languages better than me)? Is it just lacking
>  some killer apps? Is it because most ADA is closed source, so there
>  are just not libraries out there (like a SSH library)?

Yes I do think so.

> Thanks,
> Chris

Ciao,
Fabio

Re: ADA Popularity Discussion Request

[Larry Elmore]

fabio de francesco wrote:
> 
> I can't imagine anything less readable than Perl. I see it like the
> exact opposite of Ada for that.

J is definitely harder to read than Perl. It's a descendent of APL, but 
replaced the special symbols with combinations of punctuation symbols. 
Like APL, you can write some incredible one-liners, but even you won't 
be able to easily figure out what it does a week later.

http://www.jsoftware.com

--Larry

Re: ADA Popularity Discussion Request

[Adam Ruth]

In article <cvySc.290200$XM6.53864@attbi_s53>,
 Larry Elmore <ljelmore_@_comcast_._net> wrote:

> fabio de francesco wrote:
> > 
> > I can't imagine anything less readable than Perl. I see it like the
> > exact opposite of Ada for that.
> 
> J is definitely harder to read than Perl. It's a descendent of APL, but 
> replaced the special symbols with combinations of punctuation symbols. 
> Like APL, you can write some incredible one-liners, but even you won't 
> be able to easily figure out what it does a week later.
> 
> http://www.jsoftware.com
> 
> --Larry


I think that BF wins, hands down, for the hardest to read language.

WARNING:  THIS PAGE CONTAINS A NAUGHTY WORD, 
          PROCEED AT YOUR OWN RISK.

http://www.muppetlabs.com/~breadbox/bf/

-- 
Adam Ruth
adamruth at mac dot com

Re: ADA Popularity Discussion Request

[Wojtek Narczynski]

Adam Ruth <adam.ruth@mac.com> wrote in message news:<adam.ruth-5C5819.06294112082004@localhost>...
> In article <cvySc.290200$XM6.53864@attbi_s53>,
>  Larry Elmore <ljelmore_@_comcast_._net> wrote:
> 
> > fabio de francesco wrote:
> > > 
> > > I can't imagine anything less readable than Perl. I see it like the
> > > exact opposite of Ada for that.
> > 
> > J is definitely harder to read than Perl. It's a descendent of APL, but 
> > replaced the special symbols with combinations of punctuation symbols. 
> > Like APL, you can write some incredible one-liners, but even you won't 
> > be able to easily figure out what it does a week later.
> > 
> > http://www.jsoftware.com
> > 
> > --Larry
> 
> 
> I think that BF wins, hands down, for the hardest to read language.
> 
> WARNING:  THIS PAGE CONTAINS A NAUGHTY WORD, 
>           PROCEED AT YOUR OWN RISK.
> 
> http://www.muppetlabs.com/~breadbox/bf/

Or Whitespace http://compsoc.dur.ac.uk/whitespace/, but those to are
joke languages.

My anti-favourite real language is M of MUMPS.

Regards,
Wojtek

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Chris Humphries" <chris@unixfu.net> wrote in message
news:49dc98cf.0408110556.18ae7df@posting.google.com...
> Hello,
>
>    Would like to open up the newsgroup for discussion of why
>  ADA is not as popular as (of now me learning it) to it is
>  not as popular as other languages (Perl, Java, C++, C#, C).
>
There are a lot of reasons.   One of my favorites is the one
that suggests that it was killed by the compiler publishers.

In early Ada 83, this argument goes, the compiler publishers
realized that they had a captive audience in the DoD.  This
led them to charge per-programmer prices for their compilers
that were so high that the ordinary programmer could not
afford to buy a compiler.

On top of that, the larger compiler publishers, while giving
lip service to commercial utilization of the language, focused
all their sales effort on the DoD -- not even the other branches
of government -- just the DoD.

Further, machine vendors who had to bid an Ada compiler for
the DoD often had no intention of anyone ever actually using
their compiler.   Tandem, for example, had a "checkbox"
compiler, but provided no interfaces to its own operating
system, development tools, or anything else in its product
line that would make using Ada attractive.  They were not
alone in this.

There were some low-cost compilers, notably Janus and
Meridian.   While these were pretty good products, they
did not quite meet the needs of day-to-day programmers,
and most programmers of the early microcomputer era
found they could accomplish more with BASIC than they
could with the existing Ada compilers and associated
toolsets.

In general, the Ada compiler publishers never put the kind
of energy into creating an attractive environment for commercial
Ada as would have been necessary.   There were those within
those organizations who did strive for that kind of thing.  Dr.
Brosgol worked very hard to make commercial Ada a reality,
but he was pretty much (but not totally) alone much of the
time.

So, as the compiler publishers found themselves able to charge
whatever the traffic would bear, they kept their prices so high
that no commercial organization could justify Ada as a choice
of languages -- not when so many other tools were so available,
including development environments, database interfaces, VDT
development tools, etc.

This whole picture changed with the advent of GNAT, CLAW,
JEWL, and many other good compilers and tools based on the
Ada 95 standard.  But by that time, Ada had already developed
a reputation as cumbersome (not true), too big (not true), and
only used by the Department of Defense (most true).

Once a language, or any other product, has gotten a bad
reputation, it is difficult to overcome it. I know people who
will not buy a Jaguar because it is, by reputation, so hard to
maintain.   Others will not buy a Volkswagen because it is
Hitler's car (and the VW van was designed, according to
them, to help transport people to the holocaust).  One
can name countless products that, no matter how they fix
themselves, have lost their potential market because of a
bad reputation.

Are the Ada 83 compiler publishers partly to blame because
of their greed or shortsightedness?    Well, maybe not entirely,
but there are those in our community who do see it that way.

Richard Riehle

Re: ADA Popularity Discussion Request

[Ed Falis]

On Thu, 12 Aug 2004 22:41:27 GMT, Richard  Riehle <adaworks@earthlink.net>  
wrote:

> Are the Ada 83 compiler publishers partly to blame because
> of their greed or shortsightedness?    Well, maybe not entirely,
> but there are those in our community who do see it that way.
>
> Richard Riehle

After putting 16 years of my life into working for one of those Ada 83  
(and 95) compiler publishers, and constantly striving to put good value  
products on the street, making zero profit year after year, I have to say  
I resent these remarks.

There are plenty of other "members of the community" at whom fingers could  
be pointed.  But I'll refrain because it won't change a thing.

- Ed

-- 
"When I was a kid, I wanted to grow up to be a wise man. Somehow, I just  
turned out to be a wise guy".

Re: ADA Popularity Discussion Request

[Nick Roberts]

On Thu, 12 Aug 2004 23:20:35 GMT, Ed Falis <falis@verizon.net> wrote:

> On Thu, 12 Aug 2004 22:41:27 GMT, Richard  Riehle  
> <adaworks@earthlink.net> wrote:
>
>> Are the Ada 83 compiler publishers partly to blame because
>> of their greed or shortsightedness?    Well, maybe not entirely,
>> but there are those in our community who do see it that way.
>>
>> Richard Riehle
>
> After putting 16 years of my life into working for one of those
> Ada 83 (and 95) compiler publishers, and constantly striving to
> put good value products on the street, making zero profit year
> after year, I have to say I resent these remarks.

Ed, I'm pretty certain that Richie was not implicating Alsys in his
comments. Everybody knows that Alsys was one of the few companies
that struggled to bring a good Ada compiler to the masses (I was one
of those masses).

I specifically remember that any development system for the IBM PC,
at that time (mid 1980s) was inevitably compared with Borland
TurboPascal, which set the price bar for that kind of thing at an
unprecendentedly low level, whilst setting the convenience bar at
an unprecendentedly high level, and was hard for anyone to compete
with.

It is easy to forget now that few people had a personal computer
then. Nearly everyone then who would become one of the hoards of
professional progrmmers in the nineties cut their teeth on a
computer either at work or at university. Ada was not (in the
1980s) available at any workplace outside the military (and a
few aerospace and communications companies, and one French train
company), and available at very few unis.

I think Ada publishers failed to do all the things that, with the
aid of hindsight, they should have done to collectively promote
the language. But I think this was mainly because they did not
feel that it was their role to do that sort of thing, rather than
just sheer greed as such. Of course, they /should/ have realised
that it /was/ their role -- for the simple reason that nobody
else was going to do it -- but I think typical corporate
attitudes were against that kind of thing in the eighties.

> There are plenty of other "members of the community" at whom
> fingers could be pointed.  But I'll refrain because it won't
> change a thing.

Quite.

-- 
Nick Roberts

Re: ADA Popularity Discussion Request

[Ed Falis]

On Fri, 13 Aug 2004 01:37:26 +0100, Nick Roberts <nick.roberts@acm.org>  
wrote:

> Ed, I'm pretty certain that Richie was not implicating Alsys in his
> comments. Everybody knows that Alsys was one of the few companies
> that struggled to bring a good Ada compiler to the masses (I was one
> of those masses).

Richard and I know each other well, and I'm pretty sure he knows that my  
having to comment on his statement was not personal in any way.

There were those of us who thought it was our job to do some of those  
things to make the language successful.  And you're right, the corporate  
environment of the times mitigated against it.

- Ed

-- 
"When I was a kid, I wanted to grow up to be a wise man. Somehow, I just  
turned out to be a wise guy".

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Ed Falis" <falis@verizon.net> wrote in message
news:opscm64kqg5afhvo@localhost...
> On Thu, 12 Aug 2004 22:41:27 GMT, Richard  Riehle <adaworks@earthlink.net>
> wrote:
>
> > Are the Ada 83 compiler publishers partly to blame because
> > of their greed or shortsightedness?    Well, maybe not entirely,
> > but there are those in our community who do see it that way.
> >
> > Richard Riehle
>
> After putting 16 years of my life into working for one of those Ada 83
> (and 95) compiler publishers, and constantly striving to put good value
> products on the street, making zero profit year after year, I have to say
> I resent these remarks.
>
Sorry for posting such a derisive screed, Ed.

To quote Laura Huxley (I know you will understand this better than
some others who might read it), "You are not the target."   The people
at Alsys that I know were among those who fought for wider accpetance
of Ada in the commercial community.  There are others including Randy
over at RR, and some of the folks at Meridian.

> There are plenty of other "members of the community" at whom fingers could
> be pointed.  But I'll refrain because it won't change a thing.
>
I mentioned in my earlier post the "checkbox" compilers.  These were among
the worst of the Ada offerings.   In most cases, the vendor had no
expectations
that anyone would use Ada on their computer.  The compiler was created only
to satisfy the checkbox on an RFQ where it said, "Validated Ada."

As far as the DoD was concerned, Validated Ada meant that there was a
minimal
implementation of Ada for a vendors computer.   The fact that there were no
tools relating to that computer's operating system, no development
environments,
no way to access the database, and no committment to Ada within the
organization, was indication enough that the vendor was not serious about
Ada.  At least one vendor's VP confided to me around 1989 that, for them,
Ada was a "checkbox" compiler.   If you wanted to create real programs, you
needed to use one of their supported languages, one that supported their
proprietary OS.  That company no longer makes computers.  They have
been acquired.

This was not uncommon in those times.   Most of us had the experience of
being confronted with a compiler environment that satisfied the checkbox,
but did not have all the tools necessary to create programs easily for the
targeted platform.

There is a line from "Who Killed Roger Rabbit," where the cartoon character
named Jessica says, "I'm not really bad.  I'm just drawn that way."  One can
imagine Ada saying something such as, "I'm not really bad.  I've just been
implemented that way."

In the end, all of us involved in promoting Ada made our mistakes, myself
included.   In my current role, that of a professor of computer science, I
hope I am doing better.  My students seem to come away from my Ada
classes with a good feeling about it.   Still, I encounter people from the
DoD,
industry, and elsewhere who say to me, "I thought the DoD now forbids the
use of Ada."   Somehow, the correct message is still not getting out.

Richard Riehle

Re: ADA Popularity Discussion Request

[Matt Morgan]

"Richard Riehle" <adaworks@earthlink.net> wrote in message
news:rmSSc.19355$cK.6880@newsread2.news.pas.earthlink.net...

> Once a language, or any other product, has gotten a bad
> reputation, it is difficult to overcome it. I know people who
> will not buy a Jaguar because it is, by reputation, so hard to
> maintain.   Others will not buy a Volkswagen because it is
> Hitler's car (and the VW van was designed, according to
> them, to help transport people to the holocaust).

I have recently come back to the Ada95 table (both professionally and as a
hobbyist), and I happen to drive a VW... Surely that has to count for
*something*... <g>

Re: ADA Popularity Discussion Request

[j]

I know for a fact that Boeing uses Ada 83 on the F/A-22 (fighter jet of the
future).

--= It Lives!! =--

Re: ADA Popularity Discussion Request

[Nick Roberts]

On Sun, 15 Aug 2004 18:56:22 GMT, Dennis Lee Bieber  
<wlfraed@ix.netcom.com> wrote:

> On Sat, 14 Aug 2004 02:26:33 -0500, "j" <toddbiz@highstream.net>
> declaimed the following in comp.lang.ada:
>
>> I know for a fact that Boeing uses Ada 83 on the F/A-22 (fighter
>> jet of the future).
>
> 	That's interesting, as the F/A-22 is a Lockheed Martin
> development...
>
> (also interesting -- I missed the announcement of the designator
> change from fighter to fighter/attack)

The Raptor has always been officially designated F/A-22, I think. It
was always conceived in a joint interdictor and ground support role.
Nevertheless, the forms "F22", "F-22", "F 22" and so on also seem to
be commonly used (odd, really).

Boeing developed a complete prototype for the competition with
Lockheed Martin for the Raptor contract. Of course, Lockheed Martin
won, but I believe Boeing are involved in the manufacturing
programme.

 From the F/A-22 web site:

    The software that provides the avionics system's full
    functionality is composed of approximately 1.7 million lines of
    code. Ninety percent of the software is written in Ada, the
    Department of Defense's common computer language. Exceptions to
    the Ada requirement are granted only for special processing or
    maintenance requirements.

-- 
Nick Roberts

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:opscslubwup4pfvb@bram-2...
>
>  From the F/A-22 web site:
>
>     The software that provides the avionics system's full
>     functionality is composed of approximately 1.7 million lines of
>     code. Ninety percent of the software is written in Ada, the
>     Department of Defense's common computer language. Exceptions to
>     the Ada requirement are granted only for special processing or
>     maintenance requirements.
>
Too bad this kind of intelligent decision-making could not have
been applied to the Joint Strike Fighter.  Instead, some idiot
decided to do all the software for JSF in C++.

Richard Riehle

Re: ADA Popularity Discussion Request

[Keith H Duggar]

Greetings all. Thank you for opening this thread I'm very
eager to learn more about Ada.

If I may explain. I'm a proficient C++ coder and have been
using it for scientific research coding for eight years. And
I have experience with various other languages including C
and Fortran.

Recently, quite by accident, I ran into the Ada language
having (unfortunately) barely heard of it and having never
seen or been taught anything about it.

When I first saw Ada I thought wow this looks like an 
excellent language. In the very least it is a language that
I wish I had known about much earlier. For example, I wish
Georgia Tech had included Ada in a course of two as they had
included Fortran and C.

So, after researching a bit on the web I still couldn't find
and explanations for why Ada isn't that popular. I decided
to email a well known programming and compiler guru who had
once commented positively on Ada. I asked why Ada wasn't as
popular as C++ (a language which he is also a guru of). Here
was his reply:

"Ada was an experiment that failed. It was specified in such a way
that it's hard to get adequate performance. So a critical mass of
users and vendors never materialized. Now we see people devoting more
energy to making C/C++ safer for programming large systems."

Can any of you help me understand the details behind what he
stated? Was it difficult to write compilers that gave good
performance? Was the language specification too complex or
difficult to implement?

Or are there simply missing features that preclude some
efficient coding idioms (does Ada have pointers?). I'm
very ignorant when it comes to Ada so please forgive these
newbie questions.

Keith

Re: ADA Popularity Discussion Request

[Ludovic Brenta]

 (Keith H Duggar) writes:
> "Ada was an experiment that failed. It was specified in such a way
> that it's hard to get adequate performance. So a critical mass of
> users and vendors never materialized. Now we see people devoting
> more energy to making C/C++ safer for programming large systems."

I wouldn't consider whoever said that a guru.  A real guru keeps
posted about new developments.

> Can any of you help me understand the details behind what he stated?
> Was it difficult to write compilers that gave good performance? Was
> the language specification too complex or difficult to implement?

Most of this has to deal with history.

C was designed for ease of implementation; Ada was designed for
safety, predictability, portability and maintainability.  Of course,
Ada compilers are more difficult to write than C compilers.  This is a
Good Thing; it means that Ada compilers do more work for you than do C
compilers.  C++ compilers are quite hard to get right; but then again,
so are C++ programs.

In the early 1980's, the DoD mandated use of Ada for most new software
development.  Contractors used to provide expensive, proprietary, and
slow compilers just because the DoD mandated it.  In return, their
compilers were Validated, i.e. certified to conform to the Ada 83
standard.  There were a few vendors that did not actually believe in
Ada and offered only "check-box compilers" - compilers barely good
enough to check a box saying "yes, we support Ada" in a form, but
lacking any real features or tools for serious development.

But things have changed since then.  The "check-box" vendors have all
but disappeared; the remaining Ada vendors are all quite serious about
Ada and software quality.  The Ada language evolved into a powerful
object-oriented language (Ada 95) without losing any of its inherent
safety, and a new standard (Ada 2005) is in the works for even more
improvements.  There are several good, inexpensive Ada compilers to
choose from.  One such compiler is even free, both in the sense of
freedom and free beer.

> Or are there simply missing features that preclude some efficient
> coding idioms (does Ada have pointers?). I'm very ignorant when it
> comes to Ada so please forgive these newbie questions.

Yes, Ada does have pointers.  They're called "access types" in Ada.
In Ada 95, "access to subprograms" were added among other things.  The
"guru" you mentioned ought to know that.  The only feature that I
think Ada lacks is functional programming; apart from that, it has
everything C++ has, and more (don't talk to me about multiple
inheritance before you've read Tucker Taft's paper on the subject).

I think that Ada is still entrenched, and thrives in safety-critical
environments, but these environments are traditionally neither Free
Software nor commercial-off-the-shelf.  As a result, the millions of
lines of Ada programs out there that fly aircraft, run trains, or
control nuclear power stations remain largely unknown to the general
public.  I think that Ada deserves more exposure by means of more Free
Software and more COTS software.  There *are* quite a few available
free software packages out there, but not nearly as many as in other
languages.  Quality compensates for that, IMHO, but there is still the
nagging impression that Ada is being ignored by the masses.

I appreciate that you took the time to ask questions here rather than
just take some uninformed bloke's word for it.  I have found that the
people interested in Ada tend to be independent thinkers.  A scarcity
nowadays.

-- 
Ludovic Brenta.

Re: ADA Popularity Discussion Request

[Ed Falis]

On Tue, 17 Aug 2004 00:24:24 +0200, Ludovic Brenta  
<ludovic.brenta@insalien.org> wrote:

> There *are* quite a few available
> free software packages out there, but not nearly as many as in other
> languages.

And Ludovic is one of the heroes because he packages Ada development tools  
for Debian ;-)

- Ed

-- 
"When I was a kid, I wanted to grow up to be a wise man. Somehow, I just  
turned out to be a wise guy".

Re: ADA Popularity Discussion Request

[Keith H Duggar]

> I wouldn't consider whoever said that a guru.  A real guru
> keeps posted about new developments
>
> ...
>
> Yes, Ada does have pointers.  They're called "access types"
> in Ada. In Ada 95, "access to subprograms" were added among
> other things.  The "guru" you mentioned ought to know that.

Unfortunately, I think my comment was a little vague. I didn't
mean to imply he was an Ada guru. Rather a guru of C/C++ and
C/C++ compiler implementation. However, he had once commented
positively on Ada so I thought he might be able to give me
some insight on Ada from a C/C++ perspective since that was
my strongest background.

Also, I mentioned pointers not because he had mentioned them
but rather because I was trying to think of "performance"
related features.

> The Ada language evolved into a powerful
> object-oriented language (Ada 95) without losing any of its inherent
> safety, and a new standard (Ada 2005) is in the works for even more
> improvements.  There are several good, inexpensive Ada compilers to
> choose from.  One such compiler is even free, both in the sense of
> freedom and free beer.

Excellent on both accounts! I look forward to seeing what
comes out of the the new standard. And is this the GNAT
compiler you are referring to? Would that be a good choice
me to get a first taste of Ada?

> I think that Ada deserves more exposure by means of more
> Free Software and more COTS software.

I don't know enough to support that generally; but, on a
personal basis I sure wish I had been exposed to Ada more
and earlier.

> I appreciate that you took the time to ask questions here
> rather than just take some uninformed bloke's word for it.
> I have found that the people interested in Ada tend to be
> independent thinkers.

Thank you. And thank you for taking the time to respond.

> A scarcity nowadays.

You definitely won't get any argument from me there.

Re: ADA Popularity Discussion Request

[Ludovic Brenta]

 (Keith H Duggar) writes:
> Also, I mentioned pointers not because he had mentioned them but
> rather because I was trying to think of "performance" related
> features.

As Marin mentioned, performance is not a good reason to use access
types; the compiler chooses how to pass parameters (by value, by
reference, or in registers), and you can trust it to make the best
decision.  The language rules also allow you to force by-reference
parameter passing without using access types (e.g. with limited
types).

In object-oriented programming, you also do not need pointers to do
dispatching of subprograms.  Tagged types (the Ada equivalent of a C++
class) are always passed by reference, too, without any explicit
pointers.

You use access types primarily when you build dynamic data structures
like linked lists.

> Excellent on both accounts! I look forward to seeing what comes out
> of the the new standard. And is this the GNAT compiler you are
> referring to? Would that be a good choice me to get a first taste of
> Ada?

Yes, I was alluding to GNAT.  And if you'll allow me another of my
customary shameless plugs here, I'd suggest you try Debian [1] as your
development platform.  One of the problems people face when they try
Ada is that they have to hunt the Internet to find compilers,
libraries and documentation, and that they sometimes have to compile
everything by hand.  Debian solves that for you; with "apt-get" you
can install about 1 million lines of code's worth of Ada software, all
pre-compiled and configured for you.  If you use Windows, my friend
Stéphane Rivière has a similar distribution called AIDE [2,3] waiting
for you.

(end of shameless plug :) )

[1] http://www.debian.org
[2] http://eig.unige.ch/lii/Aide.htm
[3] http://stephane.rochebrune.org

Oh BTW, are you aware of the main Ada portals?  They'll get you to
a wealth of documentation, software and info.

[4] http://www.adaic.org
[5] http://www.adapower.org
[6] http://www.adaworld.com
[7] http://libre.act-europe.fr

-- 
Ludovic Brenta.

Re: ADA Popularity Discussion Request

[Ed Falis]

On 16 Aug 2004 14:09:41 -0700, Keith H Duggar <duggar@mit.edu> wrote:

Keith,

I'll take a shot at it, though understand this is just my opinion.  
(However, I've been in the compiler and real-time executive side of the  
business since 1981).

> "Ada was an experiment that failed. It was specified in such a way
> that it's hard to get adequate performance. So a critical mass of
> users and vendors never materialized. Now we see people devoting more
> energy to making C/C++ safer for programming large systems."

> Can any of you help me understand the details behind what he
> stated? Was it difficult to write compilers that gave good
> performance? Was the language specification too complex or
> difficult to implement?

The language was not specified in such a way that good performance  
couldn't be achieved.  But at the time (early 80's), it was ambitious  
enough that it went out onto the bleeding edge of implementation  
techniques.  It tried to work at a level of abstraction that was a bit  
pressing for the HW resources of the day, and tried to solve software  
development problems that other languages did not.  The compiler itself  
went way beyond the usual expectations for compilers of the time in  
detecting semantic problems in applications.

That said, you would be hard-pressed to find significant performance  
differences from C++ in areas where they overlap. (There are a number of  
language-defined capabilities in Ada that are addressed by libraries in  
C++, or which fall outside the standard of the latter - and less so,  
vice-versa).

> Or are there simply missing features that preclude some
> efficient coding idioms (does Ada have pointers?). I'm
> very ignorant when it comes to Ada so please forgive these
> newbie questions.

Ada has pointers, but the abstraction is a bit "safer" / "more restricted"  
than in C or in C++ - not too different from Java, which appears to have  
been influenced by many of the ideas in Ada.

Ada was an attempt to summarize best practice at the time it was  
designed.  It's still a beautiful language, and was much improved by its  
1995 revision.  It is also in the process of a current revision, which  
should finalize next year.

Check it out further - like many recent newcomers, you may find yourself  
becoming an aficionado.

You can see, of course, that I consider your "expert"'s opinion to be  
biased and inaccurate.

- Ed

-- 
"When I was a kid, I wanted to grow up to be a wise man. Somehow, I just  
turned out to be a wise guy".

Re: ADA Popularity Discussion Request

[Keith H Duggar]

Ed,

> That said, you would be hard-pressed to find significant
> performance differences from C++ in areas where they
> overlap.

Indeed, I was having a little trouble seeing how they could
differ greatly in speed. It seems to me that Ada and C++
share a lot of "performance" related features such as static
typing, "access" types, and generics. So it seems entirely
reasonable that they are comparable in performance.

Also, I could even believe that the more restricted "access"
types vs pointers and built-in support for concurrency rather
than library based concurrency could actually give Ada an
edge in certain areas.

> (There are a number of language-defined capabilities
> in Ada that are addressed by libraries in C++, or which fall
> outside the standard of the latter - and less so, vice-versa).

If you have the time, could you give me some examples of these?
In particular, examples of C++ capabilities that aren't built-in
to Ada would help me to get a better feel for Ada in relation to
what I already know and use (C++).

Thank you for the help,

Keith

Re: ADA Popularity Discussion Request

[Ed Falis]

On 16 Aug 2004 23:28:34 -0700, Keith H Duggar <duggar@mit.edu> wrote:

> If you have the time, could you give me some examples of these?
> In particular, examples of C++ capabilities that aren't built-in
> to Ada would help me to get a better feel for Ada in relation to
> what I already know and use (C++).

Ada:

integrated concurrency
annexes providing more specific semantics for common application domains  
(eg real-time, info systems)
more specific classes of predefined types (eg fixed, decimal)
explicit support for interfacing to other languages
separate control over visibility and inheritance (as against "classes")
safety-oriented semantics by default with syntactically well-flagged  
escapes

C++:

STL (though Ada '05 will have a standard collections suite)
Explicit syntax for multiple inheritance (Ada requires building it up at  
the application level)
relatively unrestricted semantics by default, with the ability to  
construct safe abstractions
more flexible templates

I'm sure others will join in.

-- 
"When I was a kid, I wanted to grow up to be a wise man. Somehow, I just  
turned out to be a wise guy".

Re: ADA Popularity Discussion Request

[Martin Dowie]

Ed Falis wrote:
> C++:
>
> STL (though Ada '05 will have a standard collections suite)
> Explicit syntax for multiple inheritance (Ada requires building it up
> at the application level)

Ada0Y should/will have multiple inheritance through interfaces (a la Java).

Cheers

-- Martin

Re: ADA Popularity Discussion Request

[Dale Stanbrough]

Keith H Duggar wrote:

> > (There are a number of language-defined capabilities
> > in Ada that are addressed by libraries in C++, or which fall
> > outside the standard of the latter - and less so, vice-versa).
> 
> If you have the time, could you give me some examples of these?
> In particular, examples of C++ capabilities that aren't built-in
> to Ada would help me to get a better feel for Ada in relation to
> what I already know and use (C++).
> 
> Thank you for the help,

Multiple inheritance.

Constructor/Destructors that don't require inheriting from a
fixed class.

In place constructors i.e. you don't have to have a function
that then copies the new object. I seem to remember that compilers
could remove the copy as an optimisation. Anyone care to comment?

Templates that can calculate a *lot* of stuff at compile time.
(you can multiply matrices using a = b * c; notation with no
copying).

The #include model for including files in C++ means that there
isn't a problem with recursively defined types in different files.


and Keith H Duggar also wrote:

> Excellent on both accounts! I look forward to seeing what
> comes out of the the new standard. And is this the GNAT
> compiler you are referring to? Would that be a good choice
> me to get a first taste of Ada?


Gnat is an excellent compiler and has the best error messages
I have ever seen in a compiler. I groan every time I have to
use the junk they call a Java compiler. The GNU C compiler is
not much better.

> 
> I don't know enough to support that generally; but, on a
> personal basis I sure wish I had been exposed to Ada more
> and earlier.


Have a look at my notes at...

   http://www.adaware.net.au/

for a good discussion. Let me know if you would like to see
more info in the notes.

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On 16 Aug 2004 14:09:41 -0700, Keith H Duggar wrote:

> "Ada was an experiment that failed. It was specified in such a way
> that it's hard to get adequate performance.

Theoretically Ada has better support for optimizations than C. For example,
in C you can get pointer to any object. This assumes that compiler is
restricted in how and where it allocates them. In Ada an object has to be
"aliased" to allow that. Another example is

for Index in A'Range loop
   A (I) := ... -- There is no need to check array bounds

Yet another example, in C++ any call to a virtual function is dispatching.
In Ada it is only when the object is class-wide. For an OO application the
difference in terms performance could be huge.

> Or are there simply missing features that preclude some
> efficient coding idioms (does Ada have pointers?). I'm
> very ignorant when it comes to Ada so please forgive these
> newbie questions.

Yes, Ada has pointers, and interestingly, because that wasn't design
intent, richer than C++ has.

1. Ada has specific and class-wide pointers. In C++ all pointers are
class-wide. Dereferenced class-wide pointers dispatch on member functions.
In Ada you have a choice.

2. Ada has anonymous pointers. It is difficult to find any equivalent in
C++, because it has many limitations Ada does not have. It is something
like:

class X  // This is not C++!
{
public :
   friend void Foo (int Something, virtual X * This);

3. Ada has pool-specific and general access pointers. A rough C++
equivalent would be operators new and operator delete. But Ada is more
flexible here, its "new" is attached not to the object type, but to the
pointer one. So you can have many pools of objects of same type.

4. Ada pointers are true types. In C++ pointers have structure equivalence.
The difference appears when building large libraries. Consider objects of
type X to be sorted using different ways. In Ada you can:

type X_By_Name is access X; -- Pointer to X
function "<" (Left, Right : X_By_Name) return Boolean;
   -- Dereferences and compares names

type X_By_Value is access X; -- Another pointer to X
function "<" (Left, Right : X_By_Values) return Boolean;
   -- Dereferences and compares values

Now, you can instantiate a Sort procedure once with X_By_Name and its "<"
and once with X_By_Value and its "<". The result is two different sorts
with no extra control parameters to pass and no subsequent parameter
checks.

5. Ada pointers are transparent to member extraction and array indexing.
I.e. in Ada "->" and "." are same.

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

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Tue, 17 Aug 2004 16:30:45 GMT, Dennis Lee Bieber wrote:

> On Tue, 17 Aug 2004 09:50:07 +0200, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> declaimed the following in comp.lang.ada:
> 
>> 
>> for Index in A'Range loop
>>    A (I) := ... -- There is no need to check array bounds
>>
> 	Where'd the "I" come from... I suspect you mean
> 
>   A(Index) := ...

Yes, of course

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

Re: ADA Popularity Discussion Request

[Dave Thompson]

On Tue, 17 Aug 2004 09:50:07 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

> On 16 Aug 2004 14:09:41 -0700, Keith H Duggar wrote:
> 
> > "Ada was an experiment that failed. It was specified in such a way
> > that it's hard to get adequate performance.
> 
> Theoretically Ada has better support for optimizations than C. For example,
> in C you can get pointer to any object. This assumes that compiler is
> restricted in how and where it allocates them. In Ada an object has to be

In C if you declare with storage-class 'register' its address cannot
be taken and so it cannot be aliased, since C also does not have
call-by-reference. This is not quite as easy and not as clear, but it
works. But not in C++; there 'register' exists for compatibility with
C but is overridden by prefix&.

For a local or 'static' (private to source file/module ~= package)
variable, even if not declared register, the compiler can usually
determine that its address is never taken or at least never exported.

In C99 you can declare a pointer 'restrict' meaning the compiler may
assume its target is unaliased (within scope) -- but it's your (the
programmer's) responsibility to ensure that, it doesn't check for you.

> "aliased" to allow that. Another example is
> 
> for Index in A'Range loop
>    A (I) := ... -- There is no need to check array bounds
> 
Of course in C there aren't required to be, and almost never are, any
bounds checks in the first place. Nor in C++ for builtin arrays, but
you can get them with std::vector or your own array-like classes.

> Yet another example, in C++ any call to a virtual function is dispatching.
> In Ada it is only when the object is class-wide. For an OO application the
> difference in terms performance could be huge.
> 
See below.

> > Or are there simply missing features that preclude some
> > efficient coding idioms (does Ada have pointers?). I'm
> > very ignorant when it comes to Ada so please forgive these
> > newbie questions.
> 
> Yes, Ada has pointers, and interestingly, because that wasn't design
> intent, richer than C++ has.
> 
> 1. Ada has specific and class-wide pointers. In C++ all pointers are
> class-wide. Dereferenced class-wide pointers dispatch on member functions.
> In Ada you have a choice.
> 
C++ pointers and references are polymorphic, but you can "narrow" them
for a specific call by ptr-> /* or ref . */ base:: method (args). 

> 2. Ada has anonymous pointers. It is difficult to find any equivalent in
> C++, because it has many limitations Ada does not have. It is something
> like:
> 
> class X  // This is not C++!
> {
> public :
>    friend void Foo (int Something, virtual X * This);
> 
> 3. Ada has pool-specific and general access pointers. A rough C++
> equivalent would be operators new and operator delete. But Ada is more
> flexible here, its "new" is attached not to the object type, but to the
> pointer one. So you can have many pools of objects of same type.
> 
Yep. You can write your own pool-bound pointer type (sub)classes in or
for a class in C++ if you want, and I think even a (nondefault)
operator new that selects them, something like the (optional, and
AFAIK rarely used) 'allocator's on standard library containers and
streams. You would get locality and free-all-at-once, but it is very
unlikely the compiler would figure out to make them pool-relative and
give you optimized representation or access. Except, for the very
restricted case of (sub)allocating within a array of fixed or bounded
size you could make a smart "pointer" that is really just a subscript.

> 4. Ada pointers are true types. In C++ pointers have structure equivalence.

More: all C++ constructed types (pointer, reference, array, function)
have structural equivalence except named (or uniquely typedef'ed)
classes, unions, and enums.

> The difference appears when building large libraries. Consider objects of
> type X to be sorted using different ways. In Ada you can:
> 
> type X_By_Name is access X; -- Pointer to X
> function "<" (Left, Right : X_By_Name) return Boolean;
>    -- Dereferences and compares names
> 
> type X_By_Value is access X; -- Another pointer to X
> function "<" (Left, Right : X_By_Values) return Boolean;
>    -- Dereferences and compares values
> 
> Now, you can instantiate a Sort procedure once with X_By_Name and its "<"
> and once with X_By_Value and its "<". The result is two different sorts
> with no extra control parameters to pass and no subsequent parameter
> checks.
> 
Not as conveniently, but you can write pointer classes that are
distinct types yet collapse (inline if you like) to actual pointers:

struct X { int y,z; };

class X_By_y { X* x;
public: 
  /*ctor*/X_By_y (X* xx) : x(xx) {}
  int operator< (X_By_y that) { return x->y < that.x->y; }
};

class X_By_z { X* x;
public: 
  /*ctor*/X_By_z (X* xx) : x(xx) {}
  int operator< (X_By_z that) { return x->z < that.x->z; }
};


> 5. Ada pointers are transparent to member extraction and array indexing.
> I.e. in Ada "->" and "." are same.

Again you can write a smart pointer to do this if you want, but I
consider it only a minor convenience. 


- David.Thompson1 at worldnet.att.net

Re: ADA Popularity Discussion Request

[Dale Stanbrough]

Dave Thompson <david.thompson1@worldnet.att.net> wrote:

> > 5. Ada pointers are transparent to member extraction and array indexing.
> > I.e. in Ada "->" and "." are same.
> 
> Again you can write a smart pointer to do this if you want, but I
> consider it only a minor convenience. 

I (for one!) don't like this aspect of Ada. I prefer the model 
adopted by Pascal or C where you dereference explicitly.

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: ADA Popularity Discussion Request

[Martin Krischik]

Dale Stanbrough wrote:

> Dave Thompson <david.thompson1@worldnet.att.net> wrote:
> 
>> > 5. Ada pointers are transparent to member extraction and array
>> > indexing. I.e. in Ada "->" and "." are same.
>> 
>> Again you can write a smart pointer to do this if you want, but I
>> consider it only a minor convenience.
> 
> I (for one!) don't like this aspect of Ada. I prefer the model
> adopted by Pascal or C where you dereference explicitly.

Then you should try the new GNAT on gcc 3.4.1 - there is a warning now
against implicid dereferencing

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Thu, 26 Aug 2004 05:22:17 GMT, Dave Thompson wrote:

> On Tue, 17 Aug 2004 09:50:07 +0200, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> wrote:
 
>> 1. Ada has specific and class-wide pointers. In C++ all pointers are
>> class-wide. Dereferenced class-wide pointers dispatch on member functions.
>> In Ada you have a choice.
>> 
> C++ pointers and references are polymorphic,

Except that in constructors / destructors... Hyman Rosen would disagree
with me, but I believe it was a design fault. IMO the only consistent way
is to distinguish specific and class-wide objects as Ada does.

> but you can "narrow" them
> for a specific call by ptr-> /* or ref . */ base:: method (args). 

Yes, but that is not a new pointer type. It is just way to circumvent vptr.

[ Discussion point: there should be no need to specify the parent type
anywhere, except that once in the type declaration.

Unfortunately neither Ada nor C++ fulfill that. ]

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

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Dmitry A. Kazakov wrote:
>>C++ pointers and references are polymorphic,
> 
> Except that in constructors / destructors... Hyman Rosen would disagree
> with me, but I believe it was a design fault.

Yes, we've had our discussions on that. But just to be precise,
C++ pointers and references *are* polymorphic even within [cd]tors,
but the class to which they are polymorphic is the class of the
[cd]tor which is currently active.

     extern "C" int printf(const char *, ...);
     struct A {
         virtual void f() { printf("A"); }
         void g() { f(); }
         A() { g(); }
     };
     struct B : A {
         virtual void f() { printf("B"); }
         B() { g(); }
     };
     struct C : B {
         virtual void f() { printf("C"); }
         C() { g(); }
     };
     int main() { C c; } // prints ABC

Re: ADA Popularity Discussion Request

[Marin David Condic]

Keith H Duggar wrote:

> 
> If I may explain. I'm a proficient C++ coder and have been
> using it for scientific research coding for eight years. And
> I have experience with various other languages including C
> and Fortran.

I think you will find that Ada is a really wonderful language for 
scientific programming. It has excellent support for mathematical 
programming. (Look at the attributes for floating point numbers, for 
example.) The only area I could think of it being weak in that regard is 
perhaps having a plethora of mathematical libraries already in 
existence. They do exist, but probably not in the number they do in 
Fortran and to my disappointment, there are not a large number of math 
libraries (beyond log and trig stuff) that are either part of the 
standard or so ingrained that they might as well be part of the 
standard. Still, with all the numeric types, standard attributes and 
other features, if you want mathematical precision, Ada can give it to you.


> 
> "Ada was an experiment that failed. It was specified in such a way
> that it's hard to get adequate performance. So a critical mass of
> users and vendors never materialized. Now we see people devoting more
> energy to making C/C++ safer for programming large systems."
> 
"Failed" may be a bit of a relative term. I don't think it achieved its 
stated goals, but it is still used in a variety of places for its 
inherent advantages. It is certainly not as big a language as I think it 
ought to be given its merits and the ammount of money thrown at it.

As for inherent inefficiency, this is largely a myth. Part of the 
problem was that 'Back In The Day..." Ada had a lot of new concepts that 
compiler writers didn't thoroughly understand. It also had lots of 
implied runtime checking going on that added overhead to executable 
code. The thing is that fundamentally, all of its structures *can* be 
implemented efficiently and these days, they typically are. Runtime 
checks *can* be turned off when you want efficiency and, for the small 
number of applications where it makes a difference, they typically are 
disabled.

So the efficiency thing kind of came about because of bad initial 
implementations and was fueled by people looking for excuses not to use 
the language. Now, this is not true, but its hard to overcome the bad 
reputation. If you want proof by demonstration, get the free Gnat 
compiler and do some benchmarking with it. Its also a C compiler. Write 
some example code typical of what you do and clock it. Chances are, *if* 
you learn to use the compiler effectively (setting the optimization 
switches, turning off checks, etc.) you'll find it is competitive with 
equivalent C code.



> Can any of you help me understand the details behind what he
> stated? Was it difficult to write compilers that gave good
> performance? Was the language specification too complex or
> difficult to implement?
> 

Back in 1983, Ada rather exceeded the capacity of existing computer 
hardware and strained the limits of compiler technology. Sooner or 
later, both caught up and these days, efficiency is hardly a concern.

> Or are there simply missing features that preclude some
> efficient coding idioms (does Ada have pointers?). I'm
> very ignorant when it comes to Ada so please forgive these
> newbie questions.
> 
Naturally, Ada has pointers. They are called "access types". Be aware 
that usually when a C/C++ programmer starts talking about pointers from 
an efficiency standpoint, they mean as a mechanism for passing 
parameters to subroutines. This is because C was developed at a really 
primitive level. Compilers are perfectly capable of deciding that a data 
structure is too big to pass on the stack and will generate a reference 
automagically for you. No need to fuss with dereferencing pointer 
parameters inside your subroutines, etc. Its all done behind the scenes. 
*Trust* the compiler in that regard and learn to use it effectively.

Ada programs typically use pointers a *lot* less than do C/C++ programs 
because they don't need them. However, when you want to build linked 
data structures or other things where pointers are needed, Ada has them. 
Just don't try to write C++ code in Ada syntax or you'll find it is 
really tough to do.

MDC


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: ADA Popularity Discussion Request

[Martin Dowie]

Marin David Condic wrote:
> Ada programs typically use pointers a *lot* less than do C/C++
> programs because they don't need them. However, when you want to
> build linked
> data structures or other things where pointers are needed, Ada has
> them. Just don't try to write C++ code in Ada syntax or you'll find
> it is really tough to do.

And the need for doing this deminishes further with the inclusion of
standard containers, see http://www.martin.dowie.btinternet.co.uk/ for an
Ada95 implementation of the proposed new Ada0Y container libraries - there
are (doubly linked) lists, vectors, (ordered) sets and (hashed) maps.
Indefinate versions of each are available too.

Cheers

-- Martin

Re: ADA Popularity Discussion Request

[Marin David Condic]

Looks like good work & hopefully something that will be built upon & 
extended to include new capabilities. I suspect that Ada0Y is not going 
to allow the garden variety programmer to extend packages under the 
"Ada..." tree, so it is hard to imagine "growth" without some sort of 
agreed upon support from the compiler vendors. Still, one could imagine 
work being done under a different, independent branch with the 
possibility that in "Ada1Z" a given branch might be drawn into the 
standard if it proves to be something generally useful, standardizable 
and portable to a variety of implementations.

I still think there is good reason to have some kind of "supplimental 
standard" library that exists as a reference implementation that is 
allowed to grow & change at a faster rate than updates to the Ada 
standard allow - but its looking like there is at least a good start in 
that general direction...

BTW: I like the fact that there is an HTML "user's manual" written up 
for it. Hopefully, there might evolve from that some sort of "Ada 
Library Usage For Smart People (because the "dummies" are using C)" 
book. Its wonderful to have a user's manual that lays out what each 
operation does, but an example guide with practical applications can be 
a real plus for actually getting people to use it.

MDC


Martin Dowie wrote:
> 
> And the need for doing this deminishes further with the inclusion of
> standard containers, see http://www.martin.dowie.btinternet.co.uk/ for an
> Ada95 implementation of the proposed new Ada0Y container libraries - there
> are (doubly linked) lists, vectors, (ordered) sets and (hashed) maps.
> Indefinate versions of each are available too.
> 
> Cheers
> 
> -- Martin
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: ADA Popularity Discussion Request

[Martin Dowie]

Marin David Condic wrote:
> Looks like good work & hopefully something that will be built upon &
> extended to include new capabilities. I suspect that Ada0Y is not
> going to allow the garden variety programmer to extend packages under
> the "Ada..." tree, so it is hard to imagine "growth" without some
> sort of agreed upon support from the compiler vendors. Still, one
> could imagine work being done under a different, independent branch
> with the possibility that in "Ada1Z" a given branch might be drawn
> into the standard if it proves to be something generally useful,
> standardizable and portable to a variety of implementations.

I've already approached Jim Moore of "WG9" about setting up a "IWA" that
might be used to expand on what is proposed for Ada0Y, e.g. Algorithms for
the containers (these were part of the original 'Charles' library) or new
containers (Fibonacci Heaps anyone?).

Note, there is currently nothing to stop you adding whatever you like as a
/grandchild/ of Ada - you just can't add a child to package "Ada" in 'normal
mode'.


> I still think there is good reason to have some kind of "supplimental
> standard" library that exists as a reference implementation that is
> allowed to grow & change at a faster rate than updates to the Ada
> standard allow - but its looking like there is at least a good start
> in that general direction...

That is a possibility with the "IWA". It does /*NOT*/ make it part of the
standard but it could be used as a basis for inclusion.


> BTW: I like the fact that there is an HTML "user's manual" written up
> for it. Hopefully, there might evolve from that some sort of "Ada
> Library Usage For Smart People (because the "dummies" are using C)"
> book. Its wonderful to have a user's manual that lays out what each
> operation does, but an example guide with practical applications can
> be a real plus for actually getting people to use it.

Thanks, I did that myself - that's not part of the 'normal' AI process :-)
It's actually the text of the AI copied into the source code (by hand!) and
into "AdaBrowse" format (big "hello" to Thomas Wolf!).

If I get time I'll embed more examples from the AI or from elsewhere.

Cheers

-- Martin

Re: ADA Popularity Discussion Request

[Marin David Condic]

Martin Dowie wrote:
 >
 >
 > That is a possibility with the "IWA". It does /*NOT*/ make it part of
 > the standard but it could be used as a basis for inclusion.
 >

That's good news. I think the key here is that Ada needs to be able to
add new functionality at a faster rate than every ten years. Any scheme
that helps do that would be a good thing so long as the vendors go along
with it.


 >
 > Thanks, I did that myself - that's not part of the 'normal' AI
 > process :-) It's actually the text of the AI copied into the source
 > code (by hand!) and into "AdaBrowse" format (big "hello" to Thomas
 > Wolf!).
 >
 > If I get time I'll embed more examples from the AI or from elsewhere.
 >
 >
Give some thought to some kind of "textbook" format. User's guides are
nice if you already know basically how to use the library and just want
to look up the specifics of what a call to some subroutine does. But 
something that addresses "What the heck to I *do* with this package???" 
might help people get started with it. You know: "Suppose you want to 
maintain a mailing list of people and search it based on last name..." 
Explaining how to do that with a container library and pointing at code 
or code snippets can be invaluable to a new user.

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: ADA Popularity Discussion Request

[Martin Dowie]

Marin David Condic wrote:
> Give some thought to some kind of "textbook" format. User's guides are
> nice if you already know basically how to use the library and just
> want to look up the specifics of what a call to some subroutine does.
> But something that addresses "What the heck to I *do* with this
> package???" might help people get started with it. You know: "Suppose
> you want to maintain a mailing list of people and search it based on
> last name..." Explaining how to do that with a container library and
> pointing at code or code snippets can be invaluable to a new user.

Part of the problem with writing examples is that the _best_ way to
use the library will come with the new access level rules wrt access
to subprograms. Just now we have the 'cludgy' Ada95 ways, e.g.

procedure Process (C : Cursor) is
begin
   ...
end Process;

procedure Do_Something (V : Vector) is
begin
   Iterate (V, Process'Access);
end Do_Something;

Can become

procedure Do_Something (V : Vector) is
   procedure Process (C : Cursor) is
   begin
      ...
   end Process;
begin
   Iterate (V, Process'Access);
end Do_Something;

Which is a bit nicer...

However, since the versions I'm providing are Ada95, I guess I
could try and write up something in that style but with a very large
health warning! :-)

Cheers

-- Martin

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:

: The only area I could think of it being weak in that regard is 
: perhaps having a plethora of mathematical libraries already in 
: existence.

The next standard may provide some more:
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00296.TXT?rev=1.17


-- Georg

Re: ADA Popularity Discussion Request

[Marin David Condic]

Again, more good news. Vector and matrix math included as a standard 
annex of some form would add functionality & help encourage people to 
make use of Ada. Personally, I think there is enough grist for the mill 
in the area of mathematics that there could be a lot more than just 
vector and matrix functionality added. As the item you cite observes, 
the packages can be implemented in "pure" Ada and hence should pose no 
problems to adoption.

I'd disagree where it says: "Providing secondary standards has not 
proved satisfactory because they are not sufficiently visible to the 
user community as a whole." Maybe historically, and to a point. The 
question is "Would people use a secondary standard if it was blessed by 
Ada and included with most/all compilers?"

Perhaps people have avoided "secondary standards" because they aren not 
viewed as "sufficiently standard"? They ask "Can I count on this to be 
portable to some other implementation?" If it comes with most/all 
implementations, then the answer is "Yes". If its just someone's blob of 
code out there somewhere with no "official" standing and it is their 
problem to insure it works on their platform/compiler then they may 
avoid it out of fear that it will cost too much or take too long to deal 
with it themselves & opt for their own implementation because they at 
least understand and control it.

One might also ask if the "secondary standards" are "good" standards? 
I've seen lots of standards that were so overly complex that people have 
difficulty understanding how they work and what to do with them. It is 
critical that they be sufficiently clear, easy to use and well 
documented or the burden of trying to utilize them is less than that 
needed to roll your own.

MDC


Georg Bauhaus wrote:
> 
> The next standard may provide some more:
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00296.TXT?rev=1.17
> 
> 
> -- Georg


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: ADA Popularity Discussion Request

[Randy Brukardt]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:4121FFF1.80404@noplace.com...
> Again, more good news. Vector and matrix math included as a standard
> annex of some form would add functionality & help encourage people to
> make use of Ada. Personally, I think there is enough grist for the mill
> in the area of mathematics that there could be a lot more than just
> vector and matrix functionality added. As the item you cite observes,
> the packages can be implemented in "pure" Ada and hence should pose no
> problems to adoption.
>
> I'd disagree where it says: "Providing secondary standards has not
> proved satisfactory because they are not sufficiently visible to the
> user community as a whole." Maybe historically, and to a point. The
> question is "Would people use a secondary standard if it was blessed by
> Ada and included with most/all compilers?"

It says that because of history. AI-296 is a slightly modified copy of a
standard that has existed for roughly 10 years. When it came up for its 5
year review, many of the people in the WG9 meeting (myself included) had
never ever heard of it. There are no known implementations. It's clear that
historically at least, secondary standards like this might as well not
exist.

I think that the implementation rate will go from roughly 0% of all vendors
to near 100% of all vendors simply by including it in the primary standard.

There have been exceptions to the rule that secondary standards are widely
ignored (the original GEF and POSIX 5.a come to mind, but neither of those
were ever supported by anywhere near 100% of the compilers), but for the
most part, they just don't exist. That goes for users as well - after all,
if users demanded support for the standard matrix library, vendors would
have given it to them. But users are no more likely to look for and/or know
about secondary standards than vendors are.

One hopes that an IWA on extending the containers libraries would be more
like POSIX than the matrix stuff (and we intend that there is a set of
agreed upon extensions for this containers), but there can be no guarantee
of that.

                               Randy.

Re: ADA Popularity Discussion Request

[Marin David Condic]

I would agree, but add this: It is not sufficient to simply create a 
secondary standard in a vacuum. This is why many independently developed 
libraries have failed to gain traction. If the vendors of Ada and the 
standard-makers of Ada and some large users of Ada were to get together 
and discuss "The Future Strategy For Ada" and agree on a direction & 
some basic content goals, perhaps something can be made to happen.

I can write a standard an put it on the Internet and say "Would some 
vendor please make this..." but what good does that do? I could write a 
library (I happen to have some of it in my back pocket) and put it on 
the internet and say "Would someone please incorporate this as part of 
Ada and circulate it with all compilers..." but people have done this 
already with only modest success. (Charles seems to be making its way 
into the standard, but my complaint is that it a) doesn't go far enough 
and b) won't get expanded/updated except on a ten year cycle.) Writing a 
standard for a library is probably not as practical as providing a 
reference implementation anyway. The "Standard" part should come from 
Ada's portability and everyone distributing the same thing rather than 
through a written document.

Expanding the possible future for Ada is best done with some major 
subset of the interested parties working *together* to an agreed-upon 
course of action. Independent efforts - while noble - are not as likely 
to get results.

MDC

Randy Brukardt wrote:
> 
> 
> It says that because of history. AI-296 is a slightly modified copy of a
> standard that has existed for roughly 10 years. When it came up for its 5
> year review, many of the people in the WG9 meeting (myself included) had
> never ever heard of it. There are no known implementations. It's clear that
> historically at least, secondary standards like this might as well not
> exist.
> 
> I think that the implementation rate will go from roughly 0% of all vendors
> to near 100% of all vendors simply by including it in the primary standard.
> 
> There have been exceptions to the rule that secondary standards are widely
> ignored (the original GEF and POSIX 5.a come to mind, but neither of those
> were ever supported by anywhere near 100% of the compilers), but for the
> most part, they just don't exist. That goes for users as well - after all,
> if users demanded support for the standard matrix library, vendors would
> have given it to them. But users are no more likely to look for and/or know
> about secondary standards than vendors are.
> 
> One hopes that an IWA on extending the containers libraries would be more
> like POSIX than the matrix stuff (and we intend that there is a set of
> agreed upon extensions for this containers), but there can be no guarantee
> of that.
> 
>                                Randy.
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Power corrupts.  Absolute power is kind of neat"
         -- John Lehman, Secretary of the Navy 1981-1987
======================================================================

Re: ADA Popularity Discussion Request

[Martin Dowie]

Georg Bauhaus wrote:
>> The only area I could think of it being weak in that regard is
>> perhaps having a plethora of mathematical libraries already in
>> existence.
>
> The next standard may provide some more:
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00296.TXT?rev=1.17

And you can get most of it now @ http://www.martin.dowie.btinternet.co.uk/

Not complete but it does cover all the 'everyday' stuff like
multiplication/addition. 29 out of 31 subprograms for Real numbers and 71
out of 75 subprogram for Complex numbers.

I haven't had much chance to test these but I'm more than happy to hear
about any bugs - preferably with a solution attached! ;-).

Cheers

-- Martin

Re: ADA Popularity Discussion Request

[Martin Dowie]

Martin Dowie wrote:
> And you can get most of it now @
> http://www.martin.dowie.btinternet.co.uk/
>
> Not complete but it does cover all the 'everyday' stuff like
> multiplication/addition. 29 out of 31 subprograms for Real numbers
> and 71 out of 75 subprogram for Complex numbers.
>
> I haven't had much chance to test these but I'm more than happy to
> hear about any bugs - preferably with a solution attached! ;-).

You should note that for /really/ good performance from this library in
Ada0Y, I think we need to hope that AI-318 also makes it.

Cheers

-- Martin

Re: ADA Popularity Discussion Request

[Kevin Cline]

duggar@mit.edu (Keith H Duggar) wrote in message news:<b47de02.0408161309.151f6a53@posting.google.com>...
> Greetings all. Thank you for opening this thread I'm very
> eager to learn more about Ada.
> 
> If I may explain. I'm a proficient C++ coder and have been
> using it for scientific research coding for eight years. And
> I have experience with various other languages including C
> and Fortran.
> 
> Recently, quite by accident, I ran into the Ada language
> having (unfortunately) barely heard of it and having never
> seen or been taught anything about it.
> 
> When I first saw Ada I thought wow this looks like an 
> excellent language. In the very least it is a language that
> I wish I had known about much earlier. For example, I wish
> Georgia Tech had included Ada in a course of two as they had
> included Fortran and C.
> 
> So, after researching a bit on the web I still couldn't find
> and explanations for why Ada isn't that popular. I decided
> to email a well known programming and compiler guru who had
> once commented positively on Ada. I asked why Ada wasn't as
> popular as C++ (a language which he is also a guru of). Here
> was his reply:
> 
> "Ada was an experiment that failed. It was specified in such a way
> that it's hard to get adequate performance. So a critical mass of
> users and vendors never materialized. Now we see people devoting more
> energy to making C/C++ safer for programming large systems."
> 
> Can any of you help me understand the details behind what he
> stated? Was it difficult to write compilers that gave good
> performance? Was the language specification too complex or
> difficult to implement?

I don't your guru got it quite right.  Ada failed because most
programmers who tried it found Ada programming to be relative less
productive than programming in other available languages.  Ada never
attracted a large enough base of motivated users to develop the
libraries and IDEs that would make it easy to use.  Even with
available public domain compilers, almost no one is choosing to
program in Ada.

Since Ada was introduced, other new languages like C++ and Perl and
Java and C# and Python and Ruby have been relatively successful. 
While those languages are far from perfect, programmers have learned
to work with or around those imperfections, and have found enough
other benefits to learn them and use them.

In a nutshell, Ada is not popular because most people who have tried
it didn't like it.

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0408171554.2f9c48b4@posting.google.com...
>
> I don't your guru got it quite right.  Ada failed because most
> programmers who tried it found Ada programming to be relative less
> productive than programming in other available languages.  Ada never
> attracted a large enough base of motivated users to develop the
> libraries and IDEs that would make it easy to use.
>
I wonder why you think Ada is less productive than other
available languages.   Is it the static typing?  Is the ability
to define one's own types?   Is it the syntax?  Is it the way
the ALRM is written?

Over the years, I have come to the conclusion that a key
problem with Ada, in those early days, was that few of
those involved in teaching it really understood it well
enough to make it clear to those who needed to use it.

There are a few simple underlying ideas in the language. One
of them is type safety, and that has never been beyond the
comprehension of any programmer.   The idea that seems to
have been difficult to grasp, even by many who consider themselves
sophisticated software developers, is the separation of scope
and visibility.   Chapter Eight of the ALRM is rarely read by
anyone, it seems.

I recall being at a conference some years ago where someone
was giving a tutorial involving Ada.  At one point I suggested
changing a part of the design to a limited private type.  The
response, from a member of the technical staff of a well-known
compiler publisher, "Oh.  We don't design with limited because
you can't do anything with a limited type."

During nearly twenty years with Ada, I find that more programmers
have more trouble with the visibility rules than any other single
aspect of the language.   Sometimes, I as see a person struggling
to overcome those rules, I am reminded of the time during high
school when I took a part-time janitorial job and had to learn
to use a floor buffer.

Anyone who has ever had the experience of a circular floor
buffer will know what I am describing.   As soon as you take
hold of the handle, the buffer goes where it chooses, and no
amount of human muscle will overpower it.   In fact, the more
one tries to control it with brute force, the more it drags you
around the room.

Eventually, after nearly wrecking the furniture, I discovered that
I could take control of the buffer by lightly adjusting its position
relative to the floor.   In time, I learned to show off by moving
the buffer wherever I wanted, using one finger.   Instead of
fighting the design of the buffer, I learned to accomodate
myself to it.

Those who had the most difficulty with Ada, and those who
continue to have difficulty with it, are often trying to force
the language to do things the old way.   They are unable to
learn how a light touch, using the features of the language,
will make one more productive, not less productive.

I currently teach Ada in an academic environment.   My students
are in graduate school and very bright.   Many of them have
written programs in other languages.   When they first encounter
Ada, they too want to approach it the way they did other
languages.   After a short time, they learn the simple ideas behind
the design of the language and they learn to like it (most of them).
In fact, many like it far better than C++, Java, or many of the
other options they have been taught.

The benefits of the visibility rules needs to be given emphasis.  Those
rules are among the most powerful benefits of Ada, even though
some programmers continue to see them as a nuisance.

Richard Riehle

Re: ADA Popularity Discussion Request

[Björn Persson]

Richard Riehle wrote:

> "Kevin Cline" <kevin.cline@gmail.com> wrote in message
> news:e749549b.0408171554.2f9c48b4@posting.google.com...
> 
>>I don't your guru got it quite right.  Ada failed because most
>>programmers who tried it found Ada programming to be relative less
>>productive than programming in other available languages.  Ada never
>>attracted a large enough base of motivated users to develop the
>>libraries and IDEs that would make it easy to use.
> 
> I wonder why you think Ada is less productive than other
> available languages.   Is it the static typing?  Is the ability
> to define one's own types?   Is it the syntax?  Is it the way
> the ALRM is written?

The way I read the part of Kevin's post that you quoted, he said it's 
because of lack of libraries and IDEs.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: ADA Popularity Discussion Request

[Kevin Cline]

"Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<TqxUc.26181$9Y6.25639@newsread1.news.pas.earthlink.net>...
> "Kevin Cline" <kevin.cline@gmail.com> wrote in message
> news:e749549b.0408171554.2f9c48b4@posting.google.com...
> >
> > I don't your guru got it quite right.  Ada failed because most
> > programmers who tried it found Ada programming to be relative less
> > productive than programming in other available languages.  Ada never
> > attracted a large enough base of motivated users to develop the
> > libraries and IDEs that would make it easy to use.
> >
> I wonder why you think Ada is less productive than other
> available languages.   Is it the static typing?  

No, I'm very comfortable with static typing in C++.

> Is the ability to define one's own types?   

That is a problem.  User defined types are less compatable with
built-in types than they are in C++.  This makes generic programming
more difficult.  I find it more difficult to factor out duplication in
Ada than I do in C++.

> Is it the syntax?  

Yes.  The syntax, and particularly the need for explicit generic
instantiation, makes Ada programs much longer than equivalent C++
programs.  Longer programs take longer to write and longer to read.

The Ada type model, with special cases for types that overload
assignment or require a destructor, seems much more complex than the
C++ type model.

> Is it the way the ALRM is written?

The ALRM is ok, but I feel the type system is fatally flawed.

> Over the years, I have come to the conclusion that a key
> problem with Ada, in those early days, was that few of
> those involved in teaching it really understood it well
> enough to make it clear to those who needed to use it.

The early Ada compilers were horribly expensive, and horribly buggy. 
This turned a lot of programmers away from Ada, and the battle for
mindshare was quickly lost.  The battle for mindshare was lost early
when Ada failed to gain any popularity among the DARPA research
triangle of MIT, CMU, and Stanford.

> There are a few simple underlying ideas in the language. One
> of them is type safety, and that has never been beyond the
> comprehension of any programmer.   The idea that seems to
> have been difficult to grasp, even by many who consider themselves
> sophisticated software developers, is the separation of scope
> and visibility.   Chapter Eight of the ALRM is rarely read by
> anyone, it seems.
> 
> I recall being at a conference some years ago where someone
> was giving a tutorial involving Ada.  At one point I suggested
> changing a part of the design to a limited private type.  

I think the very existence of limited types is a fundamental flaw in
Ada.

> Those who had the most difficulty with Ada, and those who
> continue to have difficulty with it, are often trying to force
> the language to do things the old way.   They are unable to
> learn how a light touch, using the features of the language,
> will make one more productive, not less productive.

The difficulty of learning Ada is a flaw in the language.  

> 
> I currently teach Ada in an academic environment.   My students
> are in graduate school and very bright.  

I am too, but even among very bright people few become facile
programmers.

> 
>  Many of them have written programs in other languages.   
> When they first encounter
> Ada, they too want to approach it the way they did other
> languages.   After a short time, they learn the simple ideas behind
> the design of the language and they learn to like it (most of them).
> In fact, many like it far better than C++, Java, or many of the
> other options they have been taught.
> 
> The benefits of the visibility rules needs to be given emphasis.  Those
> rules are among the most powerful benefits of Ada, even though
> some programmers continue to see them as a nuisance.

For most applications, the benefits of the available infrastructure,
e.g. the STL and Boost for C++, the CPAN for Perl, the Java libraries,
completely dominates any possible benefit from the additional safety
afforded by Ada.  I have learned to write safe C++ code with little
effort, and have learned to use C++ templates to build extremely
powerful domain-specific libraries.

It doesn't matter to me that weak programmers can theoretically make a
mess in C++.  What matters is the amount of effort required for a good
programmer to produce sound code, and Ada is simply not competitive
for most applications.

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0408200838.43e841d@posting.google.com...

Kevin,

I have read your reasons for preferring C++ over Ada,
and appreciate that you have looked at this matter
with diligence and an honest sense of inquiry.   Because
of my confidence in the intelligent approach you took
to reach your conclusions, I will not presume to persuade
you to depart from your position.   I will say that, the
more I compare C++ and Ada (and I do have to use
C++ in some of my own work), the more I prefer
Ada.   Reasonable people can disagree on this kind
of thing.  None of these programming languages
represent revealed truth.   All have flaws.  We often
must decide which flaws we can best tolerate, rather
than which good features can be of greatest benefit.

It is a bit like voting in a major election.

Richard Riehle

Re: ADA Popularity Discussion Request

[fabio de francesco]

"Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<tJqVc.7839$3O3.4242@newsread2.news.pas.earthlink.net>...
> "Kevin Cline" <kevin.cline@gmail.com> wrote in message
> news:e749549b.0408200838.43e841d@posting.google.com...
> 
> Kevin,
> 
> I have read your reasons for preferring C++ over Ada,
> and appreciate that you have looked at this matter
> with diligence and an honest sense of inquiry.   Because
> of my confidence in the intelligent approach you took
> to reach your conclusions, I will not presume to persuade
> you to depart from your position.

What intelligent approach? He (Kevin) was able(?) to demonstrate that
some of the most interesting and powerful features of Ada represent
its major faults. I think He simply doesn't understand how to use
those features for achieving the better results and for the clever
maintaining of programs.

>   I will say that, the
> more I compare C++ and Ada (and I do have to use
> C++ in some of my own work), the more I prefer
> Ada.   Reasonable people can disagree on this kind
> of thing.  None of these programming languages
> represent revealed truth.   All have flaws.  We often
> must decide which flaws we can best tolerate, rather
> than which good features can be of greatest benefit.

I have been writing Ada code since only a couple of months and the
more I learn Ada the more I prefer this one to C++ and to all the
other programming languages I know, with the only exception of
Assembly.

> It is a bit like voting in a major election.
> 
> Richard Riehle

I don't think so. It shouldn't be just a matter of personal preference
or a matter of taste. I have begun to think that in order to really
understand, appreciate and use Ada, someone is to have some more
experience, open mind and a more vast computer science background than
that we commonly find in the average programmer. In some way, the
refuse of Ada recalls to me the same ridiculus position took by some C
programmer towards C++.

Ciao,
Fabio De Francesco

Re: ADA Popularity Discussion Request

[fabio de francesco]

fmdf@tiscali.it (fabio de francesco) wrote in message news:<ba2f9c57.0408211523.389cf201@posting.google.com>...
> In some way, the
> refuse of Ada recalls to me the same ridiculus position took by some C
> programmer towards C++.
Sorry for my poor English, please read:
In some way, the refusal of Ada recalls me the same ridiculous
position taken up by some C programmer against the adoption of C++.
Regards,
Fabio De Francesco

Re: ADA Popularity Discussion Request

[Richard Riehle]

"fabio de francesco" <fmdf@tiscali.it> wrote in message
news:ba2f9c57.0408211523.389cf201@posting.google.com...
> "Richard  Riehle" <adaworks@earthlink.net> wrote in message
news:<tJqVc.7839$3O3.4242@newsread2.news.pas.earthlink.net>...
> > "Kevin Cline" <kevin.cline@gmail.com> wrote in message
> > news:e749549b.0408200838.43e841d@posting.google.com...
> >
> > Kevin,
> >
> > I have read your reasons for preferring C++ over Ada,
> > and appreciate that you have looked at this matter
> > with diligence and an honest sense of inquiry.   Because
> > of my confidence in the intelligent approach you took
> > to reach your conclusions, I will not presume to persuade
> > you to depart from your position.
>
> What intelligent approach? He (Kevin) was able(?) to demonstrate that
> some of the most interesting and powerful features of Ada represent
> its major faults. I think He simply doesn't understand how to use
> those features for achieving the better results and for the clever
> maintaining of programs.
>
It seems that, even when I am trying to be generous toward someone
with a different point-of-view, a few on my side of the argument
can still be offended by that very generosity.

I am satisfied that Kevin has applied his own criteria with intelligence
and and sincerity to reaching his conclusions.   I don't share his
conclusions, and given the same information, have come to a
different viewpoint.   My concession is not an admission of defeat
in the argument. It is a recognition that intelligent people can reach
different conclusions even after examining the same information. I
am sorry you find fault with that.

Richard Riehle

Re: ADA Popularity Discussion Request

[fabio de francesco]

"Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<GVZVc.9513$3O3.1068@newsread2.news.pas.earthlink.net>...

> It seems that, even when I am trying to be generous toward someone
> with a different point-of-view, a few on my side of the argument
> can still be offended by that very generosity.

I don't think that "offended" is the right verb, it seems excessive to
me.

> I am satisfied that Kevin has applied his own criteria with intelligence
> and and sincerity to reaching his conclusions.   I don't share his
> conclusions, and given the same information, have come to a
> different viewpoint.   My concession is not an admission of defeat
> in the argument. 

I also don't want to make any assumptions on the cleverness of people.
I just say that whenever you discuss matters of taste people can have
different points of view, but in the case of a scientific problem with
given informations people should come to the same conclusions. The
only exceptions are either you have wrong given data or you take the
wrong explanation path.
He only lists wrong and 'unproven assumptions' and he also gets
'unrelated consequencies'.
 
At
http://groups.google.com/groups?q=g:thl4042257105d&dq=&hl=en&lr=&ie=UTF-8&selm=e749549b.0408200838.43e841d%40posting.google.com&rnum=53
Kevin says:

1) "Yes.  The syntax, and particularly the need for explicit generic
instantiation, makes Ada programs much longer than equivalent C++
programs.  Longer programs take longer to write and longer to read."
Where is the evidence that an Ada program is longer than a C++ one? (
Unproven Assumption ).
What does demonstrate that the time it takes to read and understand
lines of code are related to the lenght of the code itself? (
Unrelated Consequences ).

2) (Question: Is the ability to define one's own types?)
 "That is a problem." ( Unproven Assumption. He wants to demonstrate
that a capability doesn't add anything to the power of a language,
instead he says that the feature steals something to Ada )
 "User defined types are less compatable with built-in types than they
are in C++." ( This means nothing to me )
 "This makes generic programming more difficult." ( Whom for?
Unrelated Consequence )
 "I find it more difficult to factor out duplication in Ada than I do
in C++." ( This is only his problem and it doesn't prove anything )

3) "I think the very existence of limited types" (Ok, Proven
Assumption)
 "is a fundamental flaw in Ada".(Unrelated Consequences).
How can it be proved? Please will someone ( may be Kevin itself ) show
me the rationale of this reasoning?

4) " The difficulty of learning Ada" ( Unproven Assumption. How can he
state that learning Ada is more difficult than learning C++? How is it
proved? This shows only his difficult to learn Ada )
 "is a flaw in the language." ( Unrelated Consequences )

I don't want to go on, I'm tired.

> It is a recognition that intelligent people can reach
> different conclusions even after examining the same information. I
> am sorry you find fault with that.
> 
> Richard Riehle

It seems to me that he has examined informations from different
sources than the ones you have, if you are the author of "Ada
Distilled".

Anyway do you think that two doctors that look at the same
informations and come up with different diagnoses are both them right?
With science it's never a matter of points of view.

Ciao,
Fabio De Francesco

Re: ADA Popularity Discussion Request

[Wes Groleau]

fabio de francesco wrote:

> What does demonstrate that the time it takes to read and understand
> lines of code are related to the lenght of the code itself? (

Simple disproof would be to compare a typical APL program
with an Ada program that does the same thing.

> With science it's never a matter of points of view.

OK, you are definitely exaggerating on that one.


-- 
Wes Groleau
-----------
Daily Hoax: http://www.snopes2.com/cgi-bin/random/random.asp

Re: ADA Popularity Discussion Request

[Kevin Cline]

Wes Groleau <groleau+news@freeshell.org> wrote in message news:<ptmdnX73DcCT9bTcRVn-tQ@gbronline.com>...
> fabio de francesco wrote:
> 
> > What does demonstrate that the time it takes to read and understand
> > lines of code are related to the lenght of the code itself? (
> 
> Simple disproof would be to compare a typical APL program
> with an Ada program that does the same thing.

But an experienced APL programmer would undoubtedly find the shorter
APL program easier to read.

You can not judge the readability of a program by testing whether a
naive programmer can understand the program line by line.  Would you
consider a book on multivariate calculus to be poorly written because
it was not immediately understandable by the average high-school
graduate?  Concise mathematical notation makes it possible to reason
about mathematical objects at a high level.
So, instead of "limit(e->0) [f(x + e) - f(e)] / e", we write "f'(x)"

Similarly, writing applications concisely at a high level of
abstraction makes it easier for programmers experienced in the domain
to modify the application to meet new requirements.  The Boost::spirit
parser library for C++ is an excellent example of the power of C++
templates that is unmatched by Ada generics.

Relatively few programmers would be capable of writing the SPIRIT
parser library, but when that's what you need, Ada just won't get you
there.

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:

: But an experienced APL programmer would undoubtedly find the shorter
: APL program easier to read.

Though not all of them would agree that J programs are as easy
to read. Conversly, if you know J's operators and functions by
heart, and you read one of the 2-letter sequences in ML or Eiffel
or Ada, overload resolution has to happen in you "reading apparatus".
Why not try to avoid this when it makes sense to do so?

 
:  Concise mathematical notation makes it possible to reason
: about mathematical objects at a high level.
: So, instead of "limit(e->0) [f(x + e) - f(e)] / e", we write "f'(x)"

Uhm, the left formula is, in a sense, the body of the spec
on the right; they are *both* in concise mathematical notation.
To me, the second is as much an abbreviation as "non-inlined
subprogram calls".

How many items of concise notation should there be per page,
in a program of some size, given a set of programmers with
different areas and depths of knowledge? At least there should
be a "modularisation of notations". How can you achieve that
when the language, not the modules, defineds or invites conciseness?
 
: Relatively few programmers would be capable of writing the SPIRIT
: parser library, but when that's what you need, Ada just won't get you
: there.

It does get me there, unless you are referring to writing an exact
copy the SPIRIT parser based on Ada templates.
But there is no need.
If you need an EBNF like executable notation in Ada, SPITBOL patterns
are at your service; they are readily available for Ada. It is not
exactly the same thing as template computing, but it should turn
out to be equally powerful. This is working code, the rules are copied
from the example in the SPIRIT introduction:

begin
   integer    := span("0123456789");

   group      := '(' & (+expression) & ')';   -- "+" defers
   factor     := integer or group;
   term       := factor & arbno(('*' & factor) or ('/' & factor));
   expression := term & arbno(('+' & term) or ('-' & term));


  -- `input_text` is an Unbounded_String as per the above grammar.
  --  (which omits white space patterns.)

   match(input_text, group ** output, result);
   --   in addition to matching, displays, on `output`, what has been
   --  matched

end expr;


Ada will get me there, if along a slightly different path. :-)

-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

kevin.cline@gmail.com (Kevin Cline) writes:

> You can not judge the readability of a program by testing whether a
> naive programmer can understand the program line by line.  Would you
> consider a book on multivariate calculus to be poorly written because
> it was not immediately understandable by the average high-school
> graduate?  Concise mathematical notation makes it possible to reason
> about mathematical objects at a high level.
> So, instead of "limit(e->0) [f(x + e) - f(e)] / e", we write "f'(x)"

I tend to agree with you here.  Paul Graham has some interesting
things to say about this stuff:

http://www.paulgraham.com/power.html

[Actually, he has insightful things to say about a lot of stuff...]

With Common Lisp you could (actually this has been done...) define
some macros creating a small domain specific language for
differentiation and integration.  Then you could do things like:

(d/d? (3*x + (cos x)/x) x)

==> #<Function (:ANONYMOUS-LAMBDA 1971) @ #x774811ba>
    (((cos x) - (x * (- (sin x)))) / (x ^ 2)) + 3

where the function returned is the compiled (yes, to machine code)
form of the derivative.[1]

So, you could then write something like this:

(defun apply-derivative (fn &key (of 'x) to)
  (funcall (d/d? fn of) to))

(apply-derivative ((x ^ 2) + 2) :to 3)

==> 6

For functions the system doesn't know how to differentiate (or more
likely integrate), you could punt off to a typical iterative
approximater.


> Similarly, writing applications concisely at a high level of
> abstraction makes it easier for programmers experienced in the domain
> to modify the application to meet new requirements.

This is definitely true.  This is why domain specific languages are so
potent, but unless you are using something like Common Lisp they tend
not to be built because the effort is much too high to make them cost
effective [2].


>  The Boost::spirit parser library for C++ is an excellent example of
> the power of C++ templates...

But this is what I don't understand.  Why would anyone with this point
of view hamstring themselves by using something so inexpressive as
C++???


/Jon



1. The actual input form resulting in the compiled function here would
   be 

(lambda (x)
  (+ 3 (/ (- (cos x) (* x (- (sin x))))
          (expt x 2))))


2. See: Greenspun's tenth law


-- 
'jay' - a n t h o n y at romeo/november/charley com

Re: ADA Popularity Discussion Request

[Kevin Cline]

jayessay <nospam@foo.com> wrote in message news:<m3sma6f0d9.fsf@rigel.goldenthreadtech.com>...
> kevin.cline@gmail.com (Kevin Cline) writes:
> 
> > You can not judge the readability of a program by testing whether a
> > naive programmer can understand the program line by line.  Would you
> > consider a book on multivariate calculus to be poorly written because
> > it was not immediately understandable by the average high-school
> > graduate?  Concise mathematical notation makes it possible to reason
> > about mathematical objects at a high level.
> > So, instead of "limit(e->0) [f(x + e) - f(e)] / e", we write "f'(x)"
> 
> I tend to agree with you here.  Paul Graham has some interesting
> things to say about this stuff:
> 
> http://www.paulgraham.com/power.html
> 
> [Actually, he has insightful things to say about a lot of stuff...]
> 
> With Common Lisp you could (actually this has been done...) define
> some macros creating a small domain specific language for
> differentiation and integration.  Then you could do things like:
> 
> (d/d? (3*x + (cos x)/x) x)
> 
> ==> #<Function (:ANONYMOUS-LAMBDA 1971) @ #x774811ba>
>     (((cos x) - (x * (- (sin x)))) / (x ^ 2)) + 3
> 
> where the function returned is the compiled (yes, to machine code)
> form of the derivative.[1]
> 
> So, you could then write something like this:
> 
> (defun apply-derivative (fn &key (of 'x) to)
>   (funcall (d/d? fn of) to))
> 
> (apply-derivative ((x ^ 2) + 2) :to 3)
> 
> ==> 6
> 
> For functions the system doesn't know how to differentiate (or more
> likely integrate), you could punt off to a typical iterative
> approximater.
> 
> 
> > Similarly, writing applications concisely at a high level of
> > abstraction makes it easier for programmers experienced in the domain
> > to modify the application to meet new requirements.
> 
> This is definitely true.  This is why domain specific languages are so
> potent, but unless you are using something like Common Lisp they tend
> not to be built because the effort is much too high to make them cost
> effective [2].

As awkward as they are, you can get pretty far with C++ templates.

> 
> 
> >  The Boost::spirit parser library for C++ is an excellent example of
> > the power of C++ templates...
> 
> But this is what I don't understand.  Why would anyone with this point
> of view hamstring themselves by using something so inexpressive as
> C++???

That is a good question.  At home my projects are small, and I don't
use C++ unless they are compute-bound.  At work really expressive
languages aren't an option, since no one else here knows any of them.

Re: ADA Popularity Discussion Request

[jayessay]

kevin.cline@gmail.com (Kevin Cline) writes:

> jayessay <nospam@foo.com> wrote in message news
> > kevin.cline@gmail.com (Kevin Cline) writes:
> > 
> > 
> > With Common Lisp you could (actually this has been done...) define
> > some macros creating a small domain specific language for
> > differentiation and integration.  Then you could do things like:
> > 
> > (d/d? (3*x + (cos x)/x) x)
> > 
> > ==> #<Function (:ANONYMOUS-LAMBDA 1971) @ #x774811ba>
> >     (((cos x) - (x * (- (sin x)))) / (x ^ 2)) + 3
> > 
> > where the function returned is the compiled (yes, to machine code)
> > form of the derivative.[1]
> > 
> > So, you could then write something like this:
> > 
> > (defun apply-derivative (fn &key (of 'x) to)
> >   (funcall (d/d? fn of) to))
> > 
> > (apply-derivative ((x ^ 2) + 2) :to 3)
> > 
> > ==> 6
> > 
> > For functions the system doesn't know how to differentiate (or more
> > likely integrate), you could punt off to a typical iterative
> > approximater.
> > 
> > 
> > > Similarly, writing applications concisely at a high level of
> > > abstraction makes it easier for programmers experienced in the domain
> > > to modify the application to meet new requirements.
> > 
> > This is definitely true.  This is why domain specific languages are so
> > potent, but unless you are using something like Common Lisp they tend
> > not to be built because the effort is much too high to make them cost
> > effective [2].
> 
> As awkward as they are, you can get pretty far with C++ templates.

You can get even further with a good macro assember. C++ templates are
a good example of what is fundamentally wrong with C++: The entire
_programming_ system (core language, stl, runtime, adhoc add on libs
like boost, etc) is becoming an example of Greenspun's tenth.  This is
much worse than other such examples which are at least limited to one
off applications.


> > >  The Boost::spirit parser library for C++ is an excellent example of
> > > the power of C++ templates...
> > 
> > But this is what I don't understand.  Why would anyone with this point
> > of view hamstring themselves by using something so inexpressive as
> > C++???
> 
> That is a good question.  At home my projects are small, and I don't
> use C++ unless they are compute-bound.

Even then it is extremely unlikely that C++ would buy you anything
over Common Lisp (which has been shown on numerous occasions to beat
C++ code in performance).  OTOH, if you're using Python or Perl or
somesuch, C++ will typically blow them away on this count.


> At work really expressive languages aren't an option, since no one
> else here knows any of them.

You have my condolences.  Your situation is not exactly atypical, it's
just sad.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Kevin Cline]

jayessay <nospam@foo.com> wrote in message news:<m3sma6f0d9.fsf@rigel.goldenthreadtech.com>...
> kevin.cline@gmail.com (Kevin Cline) writes:
> 
> > You can not judge the readability of a program by testing whether a
> > naive programmer can understand the program line by line.  Would you
> > consider a book on multivariate calculus to be poorly written because
> > it was not immediately understandable by the average high-school
> > graduate?  Concise mathematical notation makes it possible to reason
> > about mathematical objects at a high level.
> > So, instead of "limit(e->0) [f(x + e) - f(e)] / e", we write "f'(x)"
> 
> I tend to agree with you here.  Paul Graham has some interesting
> things to say about this stuff:
> 
> http://www.paulgraham.com/power.html
> 
> [Actually, he has insightful things to say about a lot of stuff...]
> 
> With Common Lisp you could (actually this has been done...) define
> some macros creating a small domain specific language for
> differentiation and integration.  Then you could do things like:
> 
> (d/d? (3*x + (cos x)/x) x)
> 
> ==> #<Function (:ANONYMOUS-LAMBDA 1971) @ #x774811ba>
>     (((cos x) - (x * (- (sin x)))) / (x ^ 2)) + 3
> 
> where the function returned is the compiled (yes, to machine code)
> form of the derivative.[1]
> 
> So, you could then write something like this:
> 
> (defun apply-derivative (fn &key (of 'x) to)
>   (funcall (d/d? fn of) to))
> 
> (apply-derivative ((x ^ 2) + 2) :to 3)
> 
> ==> 6
> 
> For functions the system doesn't know how to differentiate (or more
> likely integrate), you could punt off to a typical iterative
> approximater.
> 
> 
> > Similarly, writing applications concisely at a high level of
> > abstraction makes it easier for programmers experienced in the domain
> > to modify the application to meet new requirements.
> 
> This is definitely true.  This is why domain specific languages are so
> potent, but unless you are using something like Common Lisp they tend
> not to be built because the effort is much too high to make them cost
> effective [2].

As awkward as they are, you can get pretty far with C++ templates.

> 
> 
> >  The Boost::spirit parser library for C++ is an excellent example of
> > the power of C++ templates...
> 
> But this is what I don't understand.  Why would anyone with this point
> of view hamstring themselves by using something so inexpressive as
> C++???

That is a good question.  At home my projects are small, and I don't
use C++ unless they are compute-bound.  At work really expressive
languages aren't an option, since no one else here knows any of them.

Re: ADA Popularity Discussion Request

[Richard Riehle]

Fabio,

First, yes, I am the author of Ada Distilled.   Thank you
for the acknowledgement.   I am working on a updated
version, but I am being delayed in its release by the press
of other concerns.  Perhaps I should not spend as much
time engaged in dialogue of this sort on comp.lang.ada. :-)

Second.  People do look at issues in programming languages
differently, given the same information.  While I don't agree
with their conclusions, I appreciate that they will apply
different criteria to their evaluation than I would.

For example, when Kevin states that limited types are a
flaw in the language, I choose to accept that he is correct,
only because I realize that some people find this to be a
difficult concept.  I do disagree with Kevin on this, and many
other points since limited is a powerful and effective feature
when used by a designer who understands it.

Syntax, in programming languages, seems to be a personal
thing.  I know people who dislike the syntax of the C family
of languages as well as the Pascal family.   Some of these
people are attracted to Lisp, Haskell, or Ruby, or even Smalltalk
or Eiffel.  I once sat in on a meeting where, after the presentation
by a prominent speaker,  the room erupted in a spirited argument
about the virtue of := versus = for assignment.   Sometimes I
have seen people get so upset about the placement of the type
identifier in relationship to the variable/object that I half expect
to seem white foam drooling from the corners of their mouths.

As to learning Ada being difficult.  My own experience is quite
different, and I have taught Ada to a lot of people during the
last eighteen years.   A present, I teach a class that is populated
by students who have previously learned Java, some of whom
also know some C++.   My class is a multi-language class in
which students are learning Ada, C++, Lisp, and a little bit
about Eiffel, COBOL, Fortran, Smaltalk, and other languages.
Their reaction to Ada is that it is no more difficult to learn than
Java, and certainly easier to learn to do well than C++.   Of course,
there are C++ die-hards, and I don't attempt to discourage them
since most of the other professors are also C++ enthusiasts.
As they take classes from those other professors, they
must be prepared to do exercises in the language preferred
by those professors.

Finally, Kevin makes his case from his own viewpoint, using
his own criteria.  Oddly enough, the issues he raises are not
those that represent weaknesses vis a vis Ada.   If he had
examined both languages more carefully he would have found
some really good points that show some advantages of C++
over Ada.   However, that kind of analysis would also have
shown some excellent advantages of Ada over C++.

At this stage of programming language development, there
is no perfect language, certainly no perfect language for
every set of circumstances.  I ama personally comfortable
with, and often prefer, Ada for most of my own programming.
However, I also like Smalltalk and functional languages for
certain kinds of problem solving.   I am not a fan of Java
or C++ but I do like much of what Eiffel has to offer.

Most important, I continue to look for improvements in language
design, hoping that some reasonable approach will manifest itself
during my remaining work life.  At present, the current design of
Ada is one of the best languages for general purpose programming,
but someone will someday improve upon it, and later someone
will improve upon that improvement.   By then, I will no longer
have a pulse, global warming will have become more important
than any other issue confronting human civilization, and my
great grandchildren will look at Ada Distilled and wonder what
I could have possibly been thinking when I wrote it.

Richard Riehle

Re: ADA Popularity Discussion Request

[Kevin Cline]

"Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<oZnWc.31328$9Y6.14222@newsread1.news.pas.earthlink.net>...
> Fabio,
> 
> First, yes, I am the author of Ada Distilled.   Thank you
> for the acknowledgement.   I am working on a updated
> version, but I am being delayed in its release by the press
> of other concerns.  Perhaps I should not spend as much
> time engaged in dialogue of this sort on comp.lang.ada. :-)
> 
> Second.  People do look at issues in programming languages
> differently, given the same information.  While I don't agree
> with their conclusions, I appreciate that they will apply
> different criteria to their evaluation than I would.
> 
> For example, when Kevin states that limited types are a
> flaw in the language, I choose to accept that he is correct,
> only because I realize that some people find this to be a
> difficult concept.  I do disagree with Kevin on this, and many
> other points since limited is a powerful and effective feature
> when used by a designer who understands it.

Somehow I've never understood the point of making limited types a
special case.  Why not consider assignment as just another operation a
type can support, or not, just like addition or ordered comparison?  I
think this is one of the fundamental errors in the Ada design --
certain operations are somehow "more equal" than others, and
redefining them requires special syntax.

> Syntax, in programming languages, seems to be a personal
> thing.  I know people who dislike the syntax of the C family
> of languages as well as the Pascal family.   Some of these
> people are attracted to Lisp, Haskell, or Ruby, or even Smalltalk
> or Eiffel.  I once sat in on a meeting where, after the presentation
> by a prominent speaker,  the room erupted in a spirited argument
> about the virtue of := versus = for assignment.   Sometimes I
> have seen people get so upset about the placement of the type
> identifier in relationship to the variable/object that I half expect
> to seem white foam drooling from the corners of their mouths.

That kind of syntax I don't much care about.  I care about whether I
have to write 500 lines of code or 1500.  As a general rule, 500 lines
is better.

> As to learning Ada being difficult.  My own experience is quite
> different, and I have taught Ada to a lot of people during the
> last eighteen years.   

But how much of the language have your students really learned?  To
most programmers, all languages are essentially just FORTRAN.  They
store all their data in arrays and write loop upon loop ad nauseum. 
For such programmers, Ada is undoubtedly better than C or C++, because
it has extensive facilities to support static array-based programming.

However, defining or using more complex and dynamic data structures in
Ada is  a chore.  Dynamic structures requires use of unchecked
allocation and deallocation, leaving one exposed to the same sort of
heap corruption errors that plagued naive C and C++ programmers. 
However, with the introduction of the C++ standard library,
programming in C++ with advanced data structures is simple and fast,
and it's easy to avoid memory leaks, null dereferences, and heap
corruption.

> Finally, Kevin makes his case from his own viewpoint, using
> his own criteria.  Oddly enough, the issues he raises are not
> those that represent weaknesses vis a vis Ada.   If he had
> examined both languages more carefully he would have found
> some really good points that show some advantages of C++
> over Ada.   

I wrote an Ada-83 specification parser in Ada using AYACC.  That
required a rather thorough examination of the language.

> Most important, I continue to look for improvements in language
> design, 

And this is what we should all do.  Assuming that differing opinions
have no value will not lead to progress.

Re: ADA Popularity Discussion Request

[Wes Groleau]

Kevin Cline wrote:
> Somehow I've never understood the point of making limited types a
> special case.  Why not consider assignment as just another operation a
> type can support, or not, just like addition or ordered comparison?  I
> think this is one of the fundamental errors in the Ada design --
> certain operations are somehow "more equal" than others, and
> redefining them requires special syntax.

I don't think it's an _error_.  What other language at
that time could redefine an assignment operator?

Now, Ada does allow redefining assignment--for certain types.

-- 
Wes Groleau
   "Ideas are more powerful than guns,
    We would not let our enemies have guns;
    why should we let them have ideas?"
                                -- Jozef Stalin

Re: ADA Popularity Discussion Request

[Kevin Cline]

Wes Groleau <groleau+news@freeshell.org> wrote in message news:<dZqdnehSibTGWLPcRVn-uw@gbronline.com>...
> Kevin Cline wrote:
> > Somehow I've never understood the point of making limited types a
> > special case.  Why not consider assignment as just another operation a
> > type can support, or not, just like addition or ordered comparison?  I
> > think this is one of the fundamental errors in the Ada design --
> > certain operations are somehow "more equal" than others, and
> > redefining them requires special syntax.
> 
> I don't think it's an _error_.  What other language at
> that time could redefine an assignment operator?

Which time are we talking about, 1983 or 1995?

Re: ADA Popularity Discussion Request

[Wes Groleau]

Kevin Cline wrote:
>>I don't think it's an _error_.  What other language at
>>that time could redefine an assignment operator?
> 
> Which time are we talking about, 1983 or 1995?

1983 - when Ada was not able to redefine assignment
and therefore allowed limited types where predefined
assignment was unavailable, forcing the use of subprograms
as a workaround.

IOW, there are situations where straight copy
is bad.  Limited types prevented it.

Ada 95 does have a way to redefine assignment,
but still has limited types for compatibility
and for cases where predefined assignment would
be bad but no redefined is needed.

-- 
Wes Groleau
Heroes, Heritage, and History
http://freepages.genealogy.rootsweb.com/~wgroleau/

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
: However, with the introduction of the C++ standard library,
: programming in C++ with advanced data structures is simple and fast,
: and it's easy to avoid memory leaks, null dereferences, and heap
: corruption.

Though given the Charles library I doubt that C++ vs Ada is a major
issue here.


-- Georg

Re: ADA Popularity Discussion Request

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cgn6sd$snk$2@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> : However, with the introduction of the C++ standard library,
> : programming in C++ with advanced data structures is simple and fast,
> : and it's easy to avoid memory leaks, null dereferences, and heap
> : corruption.
> 
> Though given the Charles library I doubt that C++ vs Ada is a major
> issue here.

Charles is a pale imitation of the C++ STL.  It defines containers,
but provides no generic algorithms.  My Ada is now a bit rusty, but it
also appears that Charles containers can not be used with limited
types.

The author of the C++ STL started working in Ada but abandoned it
because explicit instantiation was just too unwieldy.  A single C++
template function call like this one:
    merge(c1.begin(), c1.end(), c2.begin(), c2.end(),
c3.back_inserter())

would require half a dozen lines of Ada just for the function
instantiation.

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Kevin Cline wrote:
 > A single C++ template function call like this one:
>     merge(c1.begin(), c1.end(), c2.begin(), c2.end(), c3.back_inserter());
> would require half a dozen lines of Ada just for the function instantiation.

No fair picking an easy one. Suppose you have a vector of complex numbers and
want to set the real part of each to zero. That's far from a one liner in C++
even though it's conceptually trivial.

Re: ADA Popularity Discussion Request

[Kevin Cline]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1093634083.931713@master.nyc.kbcfp.com>...
> Kevin Cline wrote:
>  > A single C++ template function call like this one:
> >     merge(c1.begin(), c1.end(), c2.begin(), c2.end(), c3.back_inserter());
> > would require half a dozen lines of Ada just for the function instantiation.
> 
> No fair picking an easy one. Suppose you have a vector of complex numbers and
> want to set the real part of each to zero. That's far from a one liner in C++
> even though it's conceptually trivial.

With boost::lambda, it would be a one liner:
    for_each(v.begin(), v.end(), _1.r = 0);

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
: Hyman Rosen <hyrosen@mail.com> wrote in message news:<1093634083.931713@master.nyc.kbcfp.com>...
:> 
:> No fair picking an easy one. Suppose you have a vector of complex numbers and
:> want to set the real part of each to zero. That's far from a one liner in C++
:> even though it's conceptually trivial.
 
: With boost::lambda, it would be a one liner:
:    for_each(v.begin(), v.end(), _1.r = 0);

With Ada 200Y there is
"procedure Set_Re (X  : in out Complex_Vector; Re : in Real_Vector);
procedure Set_Im (X  : in out Complex_Vector; Im : in Real_Vector);

Each procedure replaces the specified (cartesian) component of each of
the components of X by the value of the matching component of Re or Im;
the other (cartesian) component of each of the components is unchanged.
Constraint_Error is raised if X'Length is not equal to
Re'Length or Im'Length."

I think no one will deny that there is power in C++ template
computing, and in CLOS makros etc. (Hey, lambda is cool!)
How many specials like _1, embedded languages, and coding conventions
are desirable?
When does code suffer from abbreviation?
What about compiler error messages involving deeply nested template
instantiations?

When people complain about explicit instantiations, for example about
the necessity to express their choices of characteristics of a Booch
Collection using three explicit instantiations, what is the complaint
about?
I think that once you have understood the model, and have learned
to appreciate the why and how, it is no longer an issue.
So the complaint might be about
- the need to understand the model.
- the need to be explicit.
- the need to choose rather than relying on an implicit default.
- the need to type rather than having a number of thoughts be
  condensed in very few characters.
- ...

Hm. Why do they still write "for_each(v.begin(), v.end," so 
frequently? :-)

-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

Kevin Cline <kevin.cline@gmail.com> wrote:
>  Hyman Rosen <hyrosen@mail.com> wrote in message
>  news:<1093634083.931713@master.nyc.kbcfp.com>...
>> 
>> No fair picking an easy one. Suppose you have a vector of complex
>> numbers and want to set the real part of each to zero. That's far
>> from a one liner in C++ even though it's conceptually trivial.
>  
> With boost::lambda, it would be a one liner:
>    for_each(v.begin(), v.end(), _1.r = 0);


Why not just use the real thing (instead of a pale emasculated hack)

(map 'vec (lambda (c) (complex 0 (imagpart c))) v)

Actually it's simple to be more flexible:

(defun zero-realpart (vec &optional (type (type-of vec)))
  (map type (lambda (c) (complex 0 (imagpart c))) vec))


(let ((vc1 (vector #c(1 2) #c(2 3) #c(1/3 4.5))))
  (zero-realpart vc1))

==> #(#c(0 2) #c(0 3) #c(0.0 4.5))

(let ((vc1 (list #c(1 2) #c(2 3) #c(1/3 4.5))))
  (zero-realpart vc1))

==> (#c(0 2) #c(0 3) #c(0.0 4.5))

(let ((vc1 (list #c(1 2) #c(2 3) #c(1/3 4.5))))
  (zero-realpart vc1 'vector))

==> #(#c(0 2) #c(0 3) #c(0.0 4.5))


It wouldn't take much to generalize this to be much more flexible and
generic while still generating optimal code.


/Jon


-- 
'jay' - a n t h o n y at romeo/november/charley com

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Kevin Cline wrote:
> With boost::lambda, it would be a one liner:
>     for_each(v.begin(), v.end(), _1.r = 0);

No, it wouldn't. There is no way to delay the evaluation of the
expression '_1.r', and the _1 placeholdr has no such member, so
this would result in a compilation error.

Re: ADA Popularity Discussion Request

[Kevin Cline]

kevin.cline@gmail.com (Kevin Cline) wrote in message news:<e749549b.0408271022.47abd0e2@posting.google.com>...
> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cgn6sd$snk$2@a1-hrz.uni-duisburg.de>...
> > Kevin Cline <kevin.cline@gmail.com> wrote:
> > : However, with the introduction of the C++ standard library,
> > : programming in C++ with advanced data structures is simple and fast,
> > : and it's easy to avoid memory leaks, null dereferences, and heap
> > : corruption.
> > 
> > Though given the Charles library I doubt that C++ vs Ada is a major
> > issue here.
> 
> Charles is a pale imitation of the C++ STL.  It defines containers,
> but provides no generic algorithms.  My Ada is now a bit rusty, but it
> also appears that Charles containers can not be used with limited
> types.

I hate to follow up my own post, but after further research I found
that Charles does indeed provide some generic algorithms.  It also
provides a number of example applications.  It will be interesting to
pick a couple and perform a side-by-side comparison of corresponding
Ada and C++ code.

Re: ADA Popularity Discussion Request

[Martin Krischik]

Kevin Cline wrote:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
> news:<cgn6sd$snk$2@a1-hrz.uni-duisburg.de>...

> Charles is a pale imitation of the C++ STL.  It defines containers,
> but provides no generic algorithms.  My Ada is now a bit rusty, but it
> also appears that Charles containers can not be used with limited
> types.

But C++ containers don't support limited types as well. If you define:

class T 
   {
    private:

      operator = (T const& value);
   }

then you can't have:

vector <T>;

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Kevin Cline]

Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1198227.gWQ0keDDOY@linux1.krischik.com>...
> Kevin Cline wrote:
> 
> > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
> > news:<cgn6sd$snk$2@a1-hrz.uni-duisburg.de>...
>  
> > Charles is a pale imitation of the C++ STL.  It defines containers,
> > but provides no generic algorithms.  My Ada is now a bit rusty, but it
> > also appears that Charles containers can not be used with limited
> > types.
> 
> But C++ containers don't support limited types as well. If you define:
> 
> class T 
>    {
>     private:
> 
>       operator = (T const& value);
>    }
> 
> then you can't have:
> 
> vector <T>;

This is true.  Classes stored in STL containers need not be
default-constructible, but they must be assignable and copyable.

I seem to have confused limited types and controlled types, probably
because I stopped programming in Ada before there were controlled
types.  Still, using controlled types also seems to be problematical. 
For example, I found this at http://www.gidenstam.org/Ada/:

"In Ada controlled types, i.e. types with user defined initialize and
finalize operations, must be declared at the library level - either as
direct descendents of Ada.Finalization./Limited_/Controlled or via a
mixin component that inherits from
Ada.Finalization./Limited_/Controlled. This makes it a bit of a hassel
to use controlled types, and in particular it makes it quite limiting
to use controlled types in generic packages that one otherwise would
have liked to instansiate at other levels than the library level.

This library, the Add Finalization Anywhere Library, provides a
nice(?) way to add finalization to any (limited) tagged type at any
level. The structure of the library is inspired by Christoph Karl
Walter Grein's library for adding finalization to library level tagged
types and my library is designed to integrate well with his.

However, since declaring controlled types elsewhere than at the
library level isn't supported by Ada there is a lot of hackish things
going on inside the library. Currently, I don't know whether the these
things work on any other compiler than GNAT 3.13p and whether they are
at all sane."

I don't know about you, but that mades my head hurt.  In C++ there are
some things that make my head hurt too, but they mostly are there to
determine the meaning of code that I would naver write in the first
place.

Re: ADA Popularity Discussion Request

[Jean-Pierre Rosen]

Kevin Cline a écrit :

> I seem to have confused limited types and controlled types, probably
> because I stopped programming in Ada before there were controlled
> types.  Still, using controlled types also seems to be problematical. 
> For example, I found this at http://www.gidenstam.org/Ada/:
> 
> "In Ada controlled types, i.e. types with user defined initialize and
> finalize operations, must be declared at the library level - either as
> direct descendents of Ada.Finalization./Limited_/Controlled or via a
> mixin component that inherits from
> Ada.Finalization./Limited_/Controlled. This makes it a bit of a hassel
> to use controlled types, and in particular it makes it quite limiting
> to use controlled types in generic packages that one otherwise would
> have liked to instansiate at other levels than the library level.
> [...] 
> I don't know about you, but that mades my head hurt.  In C++ there are
> some things that make my head hurt too, but they mostly are there to
> determine the meaning of code that I would naver write in the first
> place.
It is true that controlled *types* (not objects) need to be declared at 
library level. However, all other OO languages (that I know of) require 
*all* classes to be declared at library level.
So, there is no reason to have your head hurt. It's just one of the few 
cases where Ada makes even with other programming languages, not better.
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: ADA Popularity Discussion Request

[Martin Dowie]

Jean-Pierre Rosen wrote:
> It is true that controlled *types* (not objects) need to be declared
> at library level. However, all other OO languages (that I know of)
> require *all* classes to be declared at library level.
> So, there is no reason to have your head hurt. It's just one of the
> few cases where Ada makes even with other programming languages, not
> better.

And if AI-344 gets the nod for Ada0Y then it will be ahead of the game!

It's current status is "Amendment 200Y" :-)

-- Martin

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Jean-Pierre Rosen wrote:
 > However, all other OO languages (that I know of) require
> *all* classes to be declared at library level.

Certainly neither C++ nor Java require this. I will occasionally
write the following C++ code, when I'm too lazy to do the right
thing and make a more widely reusable class.

     void some_func()
     {
         extern int some_global_a, some_global_b;
         struct restorer {
             int &sg, oldval;
             restorer(int &var, int newval) : sg(var), oldval(var) { }
             ~restorer() { sg = oldval; }
         };
         restorer rsga(some_global_a, 53);
         restorer rsgb(some_global_b, -1);
         // ...
     }

Java allows you to write "inner classes", even anonymous ones, at
pretty much any point in your code. They are often used to create
tiny class objects which implement an interface, as callbacks for
example. Something like this
     button.setClickCB(new INotify { void notify() { /* stuff */ } });

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Hyman Rosen wrote:
>             restorer(int &var, int newval) : sg(var), oldval(var) { }

Oops. That should be { var = newval; } of course.

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Hyman Rosen wrote:
:>             restorer(int &var, int newval) : sg(var), oldval(var) { }
: 
: Oops. That should be { var = newval; } of course.

I think there is still an interesting difference. If, for the sake
of an example, I write

     void some_func(int some_para)
     {
         extern int some_global_a, some_global_b;
         struct restorer {
             int &sg, oldval, def;
             restorer(int &var, int newval) : sg(var), oldval(var) {
	       var = newval;
	       def = some_para;  // <--
	     }
             ~restorer() { sg = oldval; }
     };

the compiler tells me I can't do this, because I am using a parameter
from the containing function. In Ada, this works:


procedure nc is

   type Int_Ref is access all Integer;

   some_global_a, some_global_b: aliased Integer;
   --   global to `some_func` anyway


   procedure some_func(some_para: Integer) is

      type Restorer is record  -- "new Controlled with" for the real thing ...
         sg: Int_Ref;
         oldval: Integer;
         def: Integer;   --  only for this example
      end record;
      function make_restorer(var: Int_Ref; newval: Integer) return restorer is
         result: constant restorer :=
           (sg => var, oldval => var.all, def => some_para);
      begin
         var.all := newval;
         return result;
      end make_restorer;

   begin
      declare
         rsga: restorer := make_restorer(some_global_a'access, 53);
         rsgb: restorer := make_restorer(some_global_b'access, -1);
      begin
         null; -- ...
      end;
   end some_func;

begin -- nc
   some_func(5);
end nc;

Re: ADA Popularity Discussion Request

[Jean-Pierre Rosen]

Hyman Rosen a écrit :

> Jean-Pierre Rosen wrote:
>  > However, all other OO languages (that I know of) require
> 
>> *all* classes to be declared at library level.
> 
> 
> Certainly neither C++ nor Java require this. I will occasionally
> write the following C++ code, when I'm too lazy to do the right
> thing and make a more widely reusable class.
> 
>     void some_func()
>     {
>         extern int some_global_a, some_global_b;
>         struct restorer {
>             int &sg, oldval;
>             restorer(int &var, int newval) : sg(var), oldval(var) { }
>             ~restorer() { sg = oldval; }
>         };
>         restorer rsga(some_global_a, 53);
>         restorer rsgb(some_global_b, -1);
>         // ...
>     }
> 
If I'm not mistaken, last time I looked at C++ such inner types had 
local visibility, but still global scope. Not the same thing as truly 
"local" classes. Correct me if I'm wrong.

> Java allows you to write "inner classes", even anonymous ones, at
> pretty much any point in your code. They are often used to create
> tiny class objects which implement an interface, as callbacks for
> example. Something like this
>     button.setClickCB(new INotify { void notify() { /* stuff */ } });
Inner classes are classes within classes (same as package inside 
package, which Ada of course allows), not classes inside functions.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Jean-Pierre Rosen wrote:
> If I'm not mistaken, last time I looked at C++ such inner types had 
> local visibility, but still global scope. Not the same thing as truly 
> "local" classes. Correct me if I'm wrong.

It's not a terribly meaningful distinction for C++.
In C++ types do not have any runtime dependencies
the way they can in Ada, and therefore they also do
not any notion of lifetime or extent. So in that
sense, all types are global. But they are local in
the sense that you can declare them where you need
them, like my example.

> Inner classes are classes within classes (same as package inside 
> package, which Ada of course allows), not classes inside functions.

Anonymous classes are a type of inner class, and they most certainly
can be declared/created within functions. Please see this reference:
<http://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html>.

Re: ADA Popularity Discussion Request

[Jean-Pierre Rosen]

Hyman Rosen a écrit :

> Anonymous classes are a type of inner class, and they most certainly
> can be declared/created within functions. Please see this reference:
> <http://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html>.
Anyway, all objects are global in Java, so you cannot compare with Ada.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Jean-Pierre Rosen <rosen@adalog.fr> wrote:
: Hyman Rosen a ?crit :
: 
:> Anonymous classes are a type of inner class, and they most certainly
:> can be declared/created within functions. Please see this reference:
:> <http://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html>.
: Anyway, all objects are global in Java, so you cannot compare with Ada.

Uhm, in the following program, how is the object created by
"self.new Frob()" global?

class I {

    private class Frob {
	boolean foo() { return true; }
    }

    boolean q(Frob f) {	return f.foo(); }

    public static void main(String[] args) {
	I self = new I();

	if (self.q(self.new Frob())) {  // global?
	    return;
	}
    }
}

-- Georg

Re: ADA Popularity Discussion Request

[Jean-Pierre Rosen]

Georg Bauhaus a écrit :

> Jean-Pierre Rosen <rosen@adalog.fr> wrote:
> : Anyway, all objects are global in Java, so you cannot compare with Ada.
> 
> Uhm, in the following program, how is the object created by
> "self.new Frob()" global?
> 
> class I {
> 
>     private class Frob {
> 	boolean foo() { return true; }
>     }
> 
>     boolean q(Frob f) {	return f.foo(); }
> 
>     public static void main(String[] args) {
> 	I self = new I();
> 
> 	if (self.q(self.new Frob())) {  // global?
> 	    return;
> 	}
>     }
> }
> 
It is on the heap, and can reference only other objects on the heap.
There is therefore no issue of accessing non-existent variables.

In Ada, you can declare an access type local to a subprogram. Objects 
created by allocators for this access type will similarly be accessible 
only from within the subprogram. They are still global.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Jean-Pierre Rosen <rosen@adalog.fr> wrote:

: In Ada, you can declare an access type local to a subprogram. Objects 
: created by allocators for this access type will similarly be accessible 
: only from within the subprogram. They are still global.

Is this an Ada definition of "global" (as in RM 8.1 (15), I guess)?
That is, are the objects created by the allocators in the nested block
below global entities?


procedure I is
   type T is range 1 .. 42;
begin

   declare
      type Local is access T;
      x: Local;
      y: Local := new T;
   begin
      x := new T;
   end;

end I;


-- Georg

Re: ADA Popularity Discussion Request

[Martin Krischik]

Hyman Rosen wrote:

> Jean-Pierre Rosen wrote:
>> If I'm not mistaken, last time I looked at C++ such inner types had
>> local visibility, but still global scope. Not the same thing as truly
>> "local" classes. Correct me if I'm wrong.
> 
> It's not a terribly meaningful distinction for C++.
> In C++ types do not have any runtime dependencies
> the way they can in Ada, and therefore they also do
> not any notion of lifetime or extent. So in that
> sense, all types are global. But they are local in
> the sense that you can declare them where you need
> them, like my example.
> 
>> Inner classes are classes within classes (same as package inside
>> package, which Ada of course allows), not classes inside functions.
> 
> Anonymous classes are a type of inner class, and they most certainly
> can be declared/created within functions. Please see this reference:
> <http://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html>.

But that is only a syntax -hack for lazy typers. The so called "local"
classes are actualy global classes with special naming convention - usualy
invoving a "$" in the middle of the name.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Martin Krischik wrote:
> But that is only a syntax -hack for lazy typers. The so called "local"
> classes are actualy global classes with special naming convention - usualy
> invoving a "$" in the middle of the name.

This discussion started when JPR said
     However, all other OO languages (that I know of) require
     *all* classes to be declared at library level.

This is demonstrably untrue (unless JPR knows of neither C++ nor Java);
Java and C++ do allow classes to be declared other than at library level,
including inside functions. Neither C++ nor Java has Pascal-like block
structure, so these local classes interact more weakly with their
declaration environment than would be the case otherwise, but they are
nevertheless locally declared. Because of this weaker interaction, types
in C++ and Java do not have or need a lifetime, so they are global in
that sense, but not in a name lookup sense.

In C++, I can do
     void f() { static int x; struct c { int f() { return x; } }; }

Re: ADA Popularity Discussion Request

[Jean-Pierre Rosen]

Hyman Rosen a écrit :

> This discussion started when JPR said
>     However, all other OO languages (that I know of) require
>     *all* classes to be declared at library level.
> 
> This is demonstrably untrue (unless JPR knows of neither C++ nor Java);
> Java and C++ do allow classes to be declared other than at library level,
> including inside functions. Neither C++ nor Java has Pascal-like block
> structure, so these local classes interact more weakly with their
> declaration environment than would be the case otherwise, but they are
> nevertheless locally declared. Because of this weaker interaction, types
> in C++ and Java do not have or need a lifetime, so they are global in
> that sense, but not in a name lookup sense.
> 
> In C++, I can do
>     void f() { static int x; struct c { int f() { return x; } }; }

They can be *declared* in functions, but they behave as globals. For 
examples, I think (correct me if I'm wrong) that they cannot refer to 
local parameters of the functions. They are global classes, whose 
visibility is restricted to a function.
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Jean-Pierre Rosen wrote:
> They can be *declared* in functions

Yes. You said they couldn't be!

> but they behave as globals. For examples, they cannot refer to local parameters
 > of the functions.

Correct for C++. Java local classes may refer to constant local parameters
and variables of the defining scope, but Java does this by cheating; the
local class gets copies of these when it is created.

> They are global classes, whose visibility is restricted to a  function.

Yes (for a suitable definition of global). This does not make the
ability to declare them locally any less useful.

Re: ADA Popularity Discussion Request

[Martin Krischik]

Hyman Rosen wrote:

> Martin Krischik wrote:
>> But that is only a syntax -hack for lazy typers. The so called "local"
>> classes are actualy global classes with special naming convention -
>> usualy invoving a "$" in the middle of the name.
> 
> This discussion started when JPR said
>      However, all other OO languages (that I know of) require
>      *all* classes to be declared at library level.
> 
> This is demonstrably untrue (unless JPR knows of neither C++ nor Java);
> Java and C++ do allow classes to be declared other than at library level,
> including inside functions. Neither C++ nor Java has Pascal-like block
> structure, so these local classes interact more weakly with their
> declaration environment than would be the case otherwise, but they are
> nevertheless locally declared. Because of this weaker interaction, types
> in C++ and Java do not have or need a lifetime, so they are global in
> that sense, but not in a name lookup sense.

But my argument is: "Java cheats". You declare at local level, but you get
library level. Have a look at the following list:

-rw-rw----+   1 2,7K 2004-09-01 13:42 Empfangen.class
-rw-rw----+   1 1,1K 2004-09-01 13:42 Empfangen$My_Authenticator.class
-rw-rw----+   1 991 2004-09-01 13:42 Empfangen$Nachricht.class
-rw-rw----+   1 1,2K 2004-09-01 12:46 Messages.class
-rw-rw----+   1 132 2004-09-01 13:28 messages.properties
-rw-rw----+   1 2,2K 2004-09-01 13:45 Senden.class

The so called "local" classes even get there own files.

With Regards

Maritn

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Martin Krischik wrote:
> But my argument is: "Java cheats". You declare at local level, but you get
> library level. The so called "local" classes even get there own files.

That's not cheating, that's compiling.

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On 31 Aug 2004 00:25:27 -0700, Kevin Cline wrote:

> This is true.  Classes stored in STL containers need not be
> default-constructible, but they must be assignable and copyable.

Consider this:

procedure Foo (Object : Thing'Class) is
   Copy : Thing'Class := Object; -- Assignment "dispatches" in Ada!
begin
   ...

I should admit that I do not know how to do it in C++. Probably it is
fundamentally impossible.

[ Background: once I designed a kind of rendezvous for C++. I was stunned
by the problem of exception handling. One catches an exception in one
thread and then re-raises it in another. Well, all exceptions have to be
derived from the same base. But you cannot copy a class-wide object in C++!
(throw is like return) ]

> I seem to have confused limited types and controlled types, probably
> because I stopped programming in Ada before there were controlled
> types.  Still, using controlled types also seems to be problematical.

Much as classes in C++, controlled types in Ada are a hack designed to not
disturb the rest language. It quickly achieves its goal, to make OO
programming possible, but in a long term perspective a more consequent
solution is needed. IMO the program for Ada 2010 should be:

1. all specific types have T'Class-classes
2. all types have constructors/destructors
3. all attributes are primitive operations
4. all built-in operations are primitive
5. all predefined classes (array, record, access etc) are T'Class-classes
6. multiple inheritance
7. multiple dispatch

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ADA Popularity Discussion Request

[Martin Krischik]

Kevin Cline wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote in message
> news:<1198227.gWQ0keDDOY@linux1.krischik.com>...

> I don't know about you, but that mades my head hurt.  In C++ there are
> some things that make my head hurt too, but they mostly are there to
> determine the meaning of code that I would naver write in the first
> place.

Well there where looking for problems where there arn't any. Or how often us
use the following C++ Feature:

void Function ()
   {
   class Nested
     {     
      ...
     }
   return;
   }

Because that is what the problem described was about. There is a reason why
Ada can't do it. And the reason was that Ada can actualy have the
equivalent of vector<T> - and that is far more helpfull then non library
level classes.

There was discussion about that before - please no repeat.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Simon Wright]

kevin.cline@gmail.com (Kevin Cline) writes:

> For example, I found this at http://www.gidenstam.org/Ada/:

> This library, the Add Finalization Anywhere Library, provides a
> nice(?) way to add finalization to any (limited) tagged type at any
> level. The structure of the library is inspired by Christoph Karl
> Walter Grein's library for adding finalization to library level
> tagged types and my library is designed to integrate well with his.
> 
> However, since declaring controlled types elsewhere than at the
> library level isn't supported by Ada there is a lot of hackish
> things going on inside the library. Currently, I don't know whether
> the these things work on any other compiler than GNAT 3.13p and
> whether they are at all sane."

I'm pretty sure that Christophe's library only worked because of bugs
in GNAT 3.13p.

The reference (after a _very_ strange compilation problem) loops with
3.16a1; with 5.02a1 it does something which looks not unreasonable...

-- 
Simon Wright                               100% Ada, no bugs.

Re: ADA Popularity Discussion Request

[Anders Gidenstam]

In article <x7vllfsa3mc.fsf@smaug.pushface.org>,
	Simon Wright <simon@pushface.org> writes:
> kevin.cline@gmail.com (Kevin Cline) writes:
> 
>> For example, I found this at http://www.gidenstam.org/Ada/:
> 
>> This library, the Add Finalization Anywhere Library, provides a
>> nice(?) way to add finalization to any (limited) tagged type at any
>> level. The structure of the library is inspired by Christoph Karl
>> Walter Grein's library for adding finalization to library level
>> tagged types and my library is designed to integrate well with his.
>> 
>> However, since declaring controlled types elsewhere than at the
>> library level isn't supported by Ada there is a lot of hackish
>> things going on inside the library. Currently, I don't know whether
>> the these things work on any other compiler than GNAT 3.13p and
>> whether they are at all sane."
> 
> I'm pretty sure that Christophe's library only worked because of bugs
> in GNAT 3.13p.
> 
> The reference (after a _very_ strange compilation problem) loops with
> 3.16a1; with 5.02a1 it does something which looks not unreasonable...

Hi!

Yes, my experiment (Add Finalization Anywhere, http://www.gidenstam.org/Ada/)
is very much a hack and it does not work on GNAT 3.15p either.
Do not use it for anything that needs to work!
Btw, I suppose you meant "does something which looks unreasonable"
above, right? :)
(Or does it work with 5.02a?! That would be a suprise..) 

Best Regards,

Anders Gidenstam
-- 
"Luck is my middle name," said Rincewind, indistinctly. "Mind you,
 my first name is Bad." 
   -- (Terry Pratchett, Interesting Times) 

Re: ADA Popularity Discussion Request

[Simon Wright]

anders@legolas.gidenstam.se (Anders Gidenstam) writes:

> In article <x7vllfsa3mc.fsf@smaug.pushface.org>,
> 	Simon Wright <simon@pushface.org> writes:
> > The reference (after a _very_ strange compilation problem) loops with
> > 3.16a1; with 5.02a1 it does something which looks not unreasonable...
[...]
> Btw, I suppose you meant "does something which looks unreasonable"
> above, right? :)
> (Or does it work with 5.02a?! That would be a suprise..) 

Since I don't know what it is supposed to do I can't tell whether what
it seems to do is right. The program terminates without an exception
after printing out progress messages .. that's all I meant.

-- 
Simon Wright                               100% Ada, no bugs.

Re: ADA Popularity Discussion Request

[Anders Gidenstam]

In article <x7vllffzjj5.fsf@smaug.pushface.org>,
	Simon Wright <simon@pushface.org> writes:
> anders@legolas.gidenstam.se (Anders Gidenstam) writes:
> 
>> In article <x7vllfsa3mc.fsf@smaug.pushface.org>,
>> 	Simon Wright <simon@pushface.org> writes:
>> > The reference (after a _very_ strange compilation problem) loops with
>> > 3.16a1; with 5.02a1 it does something which looks not unreasonable...
> [...]
>> Btw, I suppose you meant "does something which looks unreasonable"
>> above, right? :)
>> (Or does it work with 5.02a?! That would be a suprise..) 
> 
> Since I don't know what it is supposed to do I can't tell whether what
> it seems to do is right. The program terminates without an exception
> after printing out progress messages .. that's all I meant.

Well, the small test program should output something like this when
it works:
# ./test_finalization_anywhere
Tjo!
Controlled_Local: Finalized  3221223464. (Dummy =>  1, Bepa =>  12)
#
 
On GNAT 3.15p it gets stuck in a loop and keeps calling Finalize.

The cause seems to be that the part of the Limited_Controlled_Component
belonging to Ada.Finalization.Controlled does not get initialized when
the Limited_Controlled_Component, which is derived from it, is.

The relevant part of the code in the package
Add_Finalization.Anywhere.To_Limited_Uncontrolled:

   type Limited_Controlled is abstract new Uncontrolled with
      record
         Controller : Limited_Controlled_Component :=
           Limited_Controlled_Component'
            (Ada.Finalization.Controlled with
             Object     => To_Raw (Limited_Controlled'Unchecked_Access),
             Initialize => To_Operation (Raw_Initialize'Access),
             Finalize   => To_Operation (Raw_Finalize'Access));

	  ...
      end record;

What I try to do is to connect the real controlled type to the non-library
level type, but with 3.15p the Ada.Finalization.Controlled part does
not get initialized properly (it did with GNAT 3.11p).

Does anyone know if it is possible to successfully initialize the
Limited_Controlled_Component with the values above while at the same time
ensuring that the Ada.Finalization.Controlled part is also initialized?

(The full code is available here:
http://www.gidenstam.org/Ada/add_finalization_anywhere20031106.tar.gz )

Best Regards,

Anders Gidenstam
-- 
"Luck is my middle name," said Rincewind, indistinctly. "Mind you,
 my first name is Bad." 
   -- (Terry Pratchett, Interesting Times) 

Re: ADA Popularity Discussion Request

[Simon Wright]

anders@legolas.gidenstam.se (Anders Gidenstam) writes:

> Well, the small test program should output something like this when
> it works:
> # ./test_finalization_anywhere
> Tjo!
> Controlled_Local: Finalized  3221223464. (Dummy =>  1, Bepa =>  12)
> #

I certainly wouldn't run it as root!

Here, I get

smaug.pushface.org[17]$ ./test_finalization_anywhere 
Tjo!
Controlled_Local2: Finalized  3221222688. ( 0,  12,  74)
Controlled_Local: Finalized  3221222752. ( 2,  12)
Controlled_Local: Finalized  3221222816. ( 0,  12)
smaug.pushface.org[18]$ 

-- 
Simon Wright                               100% Ada, no bugs.

Re: ADA Popularity Discussion Request

[Anders Gidenstam]

In article <x7vhdq3zboc.fsf@smaug.pushface.org>,
	Simon Wright <simon@pushface.org> writes:
> I certainly wouldn't run it as root!

No, I certainly wouldn't do that either, but since '>' is the quotation
mark I had to be creative.. :)
 
> Here, I get
> 
> smaug.pushface.org[17]$ ./test_finalization_anywhere 
> Tjo!
> Controlled_Local2: Finalized  3221222688. ( 0,  12,  74)
> Controlled_Local: Finalized  3221222752. ( 2,  12)
> Controlled_Local: Finalized  3221222816. ( 0,  12)
> smaug.pushface.org[18]$ 

Thanks!

Interesting, then it actually seems to work in that case, as the
three test objects (LC, LC2 and LC3) seems to be finalized properly.

The next step would be to write some more extensive tests but I don't
know if it is worth the effort considering the shakiness of the
whole approach.

/Anders
-- 
"Luck is my middle name," said Rincewind, indistinctly. "Mind you,
 my first name is Bad." 
   -- (Terry Pratchett, Interesting Times) 

Re: ADA Popularity Discussion Request

[jayessay]

"Richard  Riehle" <adaworks@earthlink.net> writes:

> also know some C++.   My class is a multi-language class in
> which students are learning Ada, C++, Lisp, and a little bit

Please, please tell me you are not telling them that Lisp is a
functional language which only has recursion for looping and only has
symbols and lists for data representation.

And please say you never use examples like:

(setq foo '(a b c))


/Jon

-- 
'jay' - a n t h o n y at romeo/november/charley com

Re: ADA Popularity Discussion Request

[Richard Riehle]

"jayessay" <nospam@foo.com> wrote in message
news:m3oekuf050.fsf@rigel.goldenthreadtech.com...
> "Richard  Riehle" <adaworks@earthlink.net> writes:
>
> > also know some C++.   My class is a multi-language class in
> > which students are learning Ada, C++, Lisp, and a little bit
>
> Please, please tell me you are not telling them that Lisp is a
> functional language which only has recursion for looping and only has
> symbols and lists for data representation.
>
> And please say you never use examples like:
>
> (setq foo '(a b c))
>
Good question, Jay.  Actually, whenever possible,
for the Lisp unit in this class, I invite one of our
other professors, a Lisp advocate and Lisp expert,
to guest lecture a few sessions.   For Prolog, I do
the same.  In each case, those guest lecturers
illustrate the capabilities of those languages with
large, real-life applications they have actually
deployed.  The combination of their experience
and their enthusiasm for their preferred language
encourages students to consider such alternatives
when they need to make a choice.

One of my goals, in this course, is to broaden the
perspective of the students so they will understand
the benefits of the choices available to them when
they are confronted with real-world problems.

Richard Riehle

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On 22 Aug 2004 17:18:28 -0700, fabio de francesco wrote:

> 3) "I think the very existence of limited types" (Ok, Proven
> Assumption)
>  "is a fundamental flaw in Ada".(Unrelated Consequences).
> How can it be proved? Please will someone ( may be Kevin itself ) show
> me the rationale of this reasoning?

Whether it was a fundamental flaws is a question, but not everybody is
happy with limited types. They are a mixture of quite different concepts
which probably should be dealt separately:

1. No assignment, never
2. No predefined [in]equality
3. Cannot be initialized (who need such? Ada 2005 will probably fix that)
4. Cannot be copied (no copy constructor)
5. Passed by reference

4 => 5, but why 5 should imply 4? 2 is unrelated to anything else. 1 should
be no different from 2 or any other *operation*. 3 is nonsense.

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

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

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

: 1 ["="] should
: be no different from 2 [":="] or any other *operation*.

(just not predefined?) What should be the rule for extensions, then?


-- Georg

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Mon, 23 Aug 2004 18:59:36 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> 
>: 1 ["="] should
>: be no different from 2 [":="] or any other *operation*.
> 
> (just not predefined?) What should be the rule for extensions, then?

No different in the sense that ":=" should be treated as a primitive 
operation rather than a hard-wired something. I do not propose ":=" to have 
a result, like in C++. But clearly, it should be [multiple] dispatching.

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

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1w3sfkwcp4q0e.1u4xeln7msgi5$.dlg@40tude.net...
> Regarding limited types:

> Whether it was a fundamental flaws is a question, but not everybody is
> happy with limited types. They are a mixture of quite different concepts
> which probably should be dealt separately:
>
> 1. No assignment, never
> 2. No predefined [in]equality
> 3. Cannot be initialized (who need such? Ada 2005 will probably fix that)
> 4. Cannot be copied (no copy constructor)
> 5. Passed by reference
>
Of your criticisms, only number 3 is an occasional, but not insurmountable
nuisance.

I take 1 and 4 together.   Assignment and copy are identical in many
respects.  When I design with limited types, I nearly always include a
"copy" procedure in my design.   Someties I include a "Move."  And
sometimes I include a more specific "copy" one that tells the client
of my package specifically what to expect in calling the copy procedure.

As to point number 3.  For composite types, especially record types,
I don't want predefined equality.  This is one of the most important
ideas in limited types.  Instead, I design functions that test for equality
that do not use the "=" operator.   For example,

   function Key_is_Equal   (L, R :  limited_type) return Boolean;
   function Data_Is_Equal  (L, R :  limited_type) return Boolean;

When someone calls one of these functions, they know exactly
what they are getting.   It may not be as convenient as the "=",
but no one every complains about being surprised by the result.
> 4 => 5, but why 5 should imply 4? 2 is unrelated to anything else. 1
should
> be no different from 2 or any other *operation*. 3 is nonsense.
>
Richard Riehle

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Mon, 23 Aug 2004 22:20:59 GMT, Richard  Riehle wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1w3sfkwcp4q0e.1u4xeln7msgi5$.dlg@40tude.net...
>> Regarding limited types:
> 
>> Whether it was a fundamental flaws is a question, but not everybody is
>> happy with limited types. They are a mixture of quite different concepts
>> which probably should be dealt separately:
>>
>> 1. No assignment, never
>> 2. No predefined [in]equality
>> 3. Cannot be initialized (who need such? Ada 2005 will probably fix that)
>> 4. Cannot be copied (no copy constructor)
>> 5. Passed by reference
>>
> Of your criticisms, only number 3 is an occasional, but not insurmountable
> nuisance.
> 
> I take 1 and 4 together.   Assignment and copy are identical in many
> respects.  When I design with limited types, I nearly always include a
> "copy" procedure in my design.   Someties I include a "Move."  And
> sometimes I include a more specific "copy" one that tells the client
> of my package specifically what to expect in calling the copy procedure.

I would separate copy constructors from ":=". You may have no copy
constructor, preventing by-copy parameter passing, but still have ":=".
Similarly you can have a copy constructor and so an ability to pass
something by copy, but no ":=" (for example, to prevent random numbers or
smart pointers from copying).

Though one can generate ":=" from a copy constructor, what Ada compilers
actually do, they are unrelated. Why not to open this mechanics for
user-defined types? In my view absence of constructors is a real problem of
Ada. Should we have them (and for all types), many problems (user-defined
assignments, streaming limited tagged types, construction of limited types
on the stack, effective implementation of user-defined access types [smart
pointers], default values for standard types etc) could be solved. I agree
that it would not be easy to do.

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

Re: ADA Popularity Discussion Request

[Kevin Cline]

fmdf@tiscali.it (fabio de francesco) wrote in message news:<ba2f9c57.0408221618.475d5941@posting.google.com>...
> "Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<GVZVc.9513$3O3.1068@newsread2.news.pas.earthlink.net>...
> 
> > It seems that, even when I am trying to be generous toward someone
> > with a different point-of-view, a few on my side of the argument
> > can still be offended by that very generosity.
> 
> I don't think that "offended" is the right verb, it seems excessive to
> me.
> 
> > I am satisfied that Kevin has applied his own criteria with intelligence
> > and and sincerity to reaching his conclusions.   I don't share his
> > conclusions, and given the same information, have come to a
> > different viewpoint.   My concession is not an admission of defeat
> > in the argument. 
> 
> I also don't want to make any assumptions on the cleverness of people.
> I just say that whenever you discuss matters of taste people can have
> different points of view, but in the case of a scientific problem with
> given informations people should come to the same conclusions. The
> only exceptions are either you have wrong given data or you take the
> wrong explanation path.
> He only lists wrong and 'unproven assumptions' and he also gets
> 'unrelated consequencies'.
>  
> At
> http://groups.google.com/groups?q=g:thl4042257105d&dq=&hl=en&lr=&ie=UTF-8&selm=e749549b.0408200838.43e841d%40posting.google.com&rnum=53
> Kevin says:
> 
> 1) "Yes.  The syntax, and particularly the need for explicit generic
> instantiation, makes Ada programs much longer than equivalent C++
> programs.  Longer programs take longer to write and longer to read."
> Where is the evidence that an Ada program is longer than a C++ one? (
> Unproven Assumption ).
> What does demonstrate that the time it takes to read and understand
> lines of code are related to the lenght of the code itself? (
> Unrelated Consequences ).

From http://home.t-online.de/home/christ-usch.grein/Ada/Dimension.html
by Christopher Grein:

"There exists also the Ada Issue 324, an Ada0Y proposal by the Ada
Rapporteur Group for handling physical dimensions. Unfortunately I
could not include my view on it in the conference proceedings because
the final submission date for papers had just expired when the ARG
proposal was published. So a very short outline thereof is included
only in the PowerPoint presentation. The proposal exhibits a very
clever use of generics and generic package parameters, so it is worth
reading just for the expressive power of Ada.

However because of the tremendous number of instantiations needed, it
is yet another demonstration that Ada is not suited to doing unit
checking during compile time. It is therefor no longer pursued by the
ARG.

You can find details directly in the Ada Issues Database of the Ada
Conformity Assessment Authority.

A C++ solution, which is very similar to the Ada one presented here -
it does however not include fractional powers, can be found at
http://www.fnal.gov/docs/working-groups/fpcltf/html/SIunits-summary.html.
The big difference is that C++ templates allow type checking during
compile-time, so that no overhead neither in memory space nor in
runtime is incurred. In this respect, C++ templates are more powerful
than Ada generics. However at the time of this writing (11 February
2004), not all C++ compilers, although capable of compiling the code,
are able to actually perform this type checking (as stated in the
documentation of the method)."

The need for explicit generic instantiation is a major roadblock in
building sophisticated type systems and libraries in Ada.  I
repeatedly found that repeated code which could easily be refactored
into C++ templates could not be conveniently expressed with Ada
generics.
  
> 
> 2) (Question: Is the ability to define one's own types?)
>  "That is a problem." 
> ( Unproven Assumption. He wants to demonstrate
> that a capability doesn't add anything to the power of a language,
> instead he says that the feature steals something to Ada )
>  "User defined types are less compatable with built-in types than they
> are in C++." ( This means nothing to me )
>  "This makes generic programming more difficult." ( Whom for?
> Unrelated Consequence )
>  "I find it more difficult to factor out duplication in Ada than I do
> in C++." ( This is only his problem and it doesn't prove anything )

Perhaps these isues are outside your experience as a programmer?  How
much experience do you have writing Ada generics and C++ templates?

Re: ADA Popularity Discussion Request

[Kevin Cline]

fmdf@tiscali.it (fabio de francesco) wrote in message news:<ba2f9c57.0408211523.389cf201@posting.google.com>...
> "Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<tJqVc.7839$3O3.4242@newsread2.news.pas.earthlink.net>...
> > "Kevin Cline" <kevin.cline@gmail.com> wrote in message
> > news:e749549b.0408200838.43e841d@posting.google.com...
> > 
> > Kevin,
> > 
> > I have read your reasons for preferring C++ over Ada,
> > and appreciate that you have looked at this matter
> > with diligence and an honest sense of inquiry.   Because
> > of my confidence in the intelligent approach you took
> > to reach your conclusions, I will not presume to persuade
> > you to depart from your position.
> 
> What intelligent approach? He (Kevin) was able(?) to demonstrate that
> some of the most interesting and powerful features of Ada represent
> its major faults. I think He simply doesn't understand how to use
> those features for achieving the better results and for the clever
> maintaining of programs.

I programmed in Ada-83 for two years before starting with C++.  I knew
Ada-83 inside-out, and stressed it enough to find bugs in both the
Verdix and Telesoft compilers.  Unfortunately, most of the claimed
advantages of Ada just don't make much of an impact on the
applications I have worked on over the past 25 years.  And there are
few features of Ada that can't be duplicated by writing a C++ template
class.  OTOH, there is no way in Ada to produce the equivalent of
sophisticated C++ libraries like the Boost spirit parser.

> I don't think so. It shouldn't be just a matter of personal preference
> or a matter of taste. I have begun to think that in order to really
> understand, appreciate and use Ada, someone is to have some more
> experience, open mind and a more vast computer science background than
> that we commonly find in the average programmer. 

But Ada has been almost universally ignored by the Computer Science
research community.

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
:   OTOH, there is no way in Ada to produce the equivalent of
: sophisticated C++ libraries like the Boost spirit parser.

There might be no way to produce the exact equivalent of C++ template
computing based libraries using Ada generics.
There certainly are ways to produce sophisticated libraries in Ada.
For the spirit parser, see my other post about the SPITBOL library.

: But Ada has been almost universally ignored by the Computer Science
: research community.

Could you give some examples?


-- Georg

Re: ADA Popularity Discussion Request

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cgn7bm$snk$3@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> :   OTOH, there is no way in Ada to produce the equivalent of
> : sophisticated C++ libraries like the Boost spirit parser.
> 
> There might be no way to produce the exact equivalent of C++ template
> computing based libraries using Ada generics.
> There certainly are ways to produce sophisticated libraries in Ada.
> For the spirit parser, see my other post about the SPITBOL library.
> 
> : But Ada has been almost universally ignored by the Computer Science
> : research community.
> 
> Could you give some examples?

An example of what?  Of computer scientists who do not program in or
teach Ada?

Are there any CS programs that have chosen Ada as their core language?
 I rarely meet recent graduates with any exposure to Ada at all.  For
better or worse, (worse in my opinion), most CS departments seem to
have settled on Java.

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0408271348.74f5a957@posting.google.com...
>
> Are there any CS programs that have chosen Ada as their core language?
>  I rarely meet recent graduates with any exposure to Ada at all.  For
> better or worse, (worse in my opinion), most CS departments seem to
> have settled on Java.
>
On this point we agree.  In my programming paradigms
course (taught at the graduate school level), I have opted
to begin with functional languages instead of imperative
languages.   The students entering this course already
have at least one Quarter of Java.  In my view, they
need to understand how to write programs without
doing any assignment at all.

I follow that with C then C++ then Ada and a brief
look at Eiffel, Prolog, and a few others (sometimes
Smalltalk if there is time).

Students need to have more languages and need to
learn them from a positive viewpoint.  As much as
I dislike C++, I try to keep students interested in
it from a positive attitude.

Richard Riehle

Re: ADA Popularity Discussion Request

[Kevin Cline]

"Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<olUXc.625$8d1.548@newsread2.news.pas.earthlink.net>...
> "Kevin Cline" <kevin.cline@gmail.com> wrote in message
> news:e749549b.0408271348.74f5a957@posting.google.com...
> >
> > Are there any CS programs that have chosen Ada as their core language?
> >  I rarely meet recent graduates with any exposure to Ada at all.  For
> > better or worse, (worse in my opinion), most CS departments seem to
> > have settled on Java.
> >
> On this point we agree.  In my programming paradigms
> course (taught at the graduate school level), I have opted
> to begin with functional languages instead of imperative
> languages.   

I applaud you for this.  In my experience, programmers familiar with
functional languages learn a deeper way of thinking about code, and
tend to produce much smaller and more maintainable code than
programmers who have never been exposed to FP.

> The students entering this course already
> have at least one Quarter of Java.  In my view, they
> need to understand how to write programs without
> doing any assignment at all.

Perhaps more importantly, how to write programs without 
the array and the for-loop.

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:

: Perhaps more importantly, how to write programs without 
: the array and the for-loop.

I'd agree with you if this weren't about Ada arrays.
True, some programs with little to no support for "true"
arrays still show arrays where sets, maps, lists, etc.
should be, using that language. But then I always miss the
close connection of Ada's enumeration types and Ada's arrays,
and Ada's predefined operations of array types.

Ada enums allow me to name things known at compile time. In addition,
Ada arrays made with an Ada enum as index type can be used like
a map. Due to the index type mechanism, completeness checks
are made at compile time. For example, an array aggregate
must be completely specified. A case distinction looking at
a value of an array's index must handle each case.

Ada arrays can also be used like lists, with concatenation predefined,
and with a NIL (null range). Using any number of dimensions.

They can be used with generic array algorithms, with built
in bounds checking and loop index optimizations.
They can also be used with STL like array algorithms when
there is a simple adapter that makes them look like a
container.

Bounds can be determined and set at run time, like index
subtypes.
Arrays can be returned on the stack, allowing typical recursive
list processing subprograms. No for loops required. :-)



-- Georg

Re: ADA Popularity Discussion Request

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<ch1q7n$q56$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> 
> : Perhaps more importantly, how to write programs without 
> : the array and the for-loop.
> 
> I'd agree with you if this weren't about Ada arrays.

> True, some programs with little to no support for "true"
> arrays still show arrays where sets, maps, lists, etc.
> should be, using that language. But then I always miss the
> close connection of Ada's enumeration types and Ada's arrays,
> and Ada's predefined operations of array types.
> 
> Ada enums allow me to name things known at compile time. In addition,
> Ada arrays made with an Ada enum as index type can be used like
> a map. Due to the index type mechanism, completeness checks
> are made at compile time. For example, an array aggregate
> must be completely specified. A case distinction looking at
> a value of an array's index must handle each case.
> 
> Ada arrays can also be used like lists, with concatenation predefined,
> and with a NIL (null range). Using any number of dimensions.
> 
> They can be used with generic array algorithms, with built
> in bounds checking and loop index optimizations.
> They can also be used with STL like array algorithms when
> there is a simple adapter that makes them look like a
> container.
> 
> Bounds can be determined and set at run time, like index
> subtypes.
> Arrays can be returned on the stack, allowing typical recursive
> list processing subprograms. No for loops required. :-)

No doubt that Ada has fabulous support for integer-indexed arrays.  

Still, in my experience what is most often wanted in applications is
not an integer-indexed array, but a map or set.  In 25 years of
programming I have seen about 17,000 implementations of linear search
and 5,000 implementations of sorted insertion, almost all of which
could and should have been eliminated by using an associative
container of some sort.

I've seen large applications where over half the code was devoted to
looping through arrays in one way or another.  I've seen multiple
instances where someone had written array-based code with O(n^3)
run-time while vastly simpler map-based code would have run in O(n)
time.

By providing extensive facilities for array-based programming while
ignoring all other data structures, Ada leads most programmers to do
the wrong thing, and frustrates most of the remainder.

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
 
: No doubt that Ada has fabulous support for integer-indexed arrays.  

(and name-indexed arrays :-)

:  In 25 years of
: programming I have seen about 17,000 implementations of linear search
: and 5,000 implementations of sorted insertion, almost all of which
: could and should have been eliminated by using an associative
: container of some sort.

OK

: By providing extensive facilities for array-based programming while
: ignoring all other data structures, Ada leads most programmers to do
: the wrong thing, and frustrates most of the remainder.

Well, ignoring... the next Ada will have vectors, sets, tables, lists,
and then some, such that more (queues, ...) can be built on top of them,
by default, and standardised.
AFAIKT the specifications are influenced by experience with 
libraries in at least Ada and STL. So if programmers have been
using arrays for things that arent't arrays, there must be
a problem other than availability of data structure libraries?
A general lack of awareness of how ADTs work?
Maybe, if the situation is really that bad, the standardised components
will ameliorate Ada programming WRT proper data structures.


-- Georg

Re: ADA Popularity Discussion Request

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<chaeg8$32k$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
>  
> : No doubt that Ada has fabulous support for integer-indexed arrays.  
> 
> (and name-indexed arrays :-)
> 
> :  In 25 years of
> : programming I have seen about 17,000 implementations of linear search
> : and 5,000 implementations of sorted insertion, almost all of which
> : could and should have been eliminated by using an associative
> : container of some sort.
> 
> OK
> 
> : By providing extensive facilities for array-based programming while
> : ignoring all other data structures, Ada leads most programmers to do
> : the wrong thing, and frustrates most of the remainder.
> 
> Well, ignoring... the next Ada will have vectors, sets, tables, lists,
> and then some, such that more (queues, ...) can be built on top of them,
> by default, and standardised.
> AFAIKT the specifications are influenced by experience with 
> libraries in at least Ada and STL. So if programmers have been
> using arrays for things that arent't arrays, there must be
> a problem other than availability of data structure libraries?
> A general lack of awareness of how ADTs work?

One might expect that graduates from a four-year degree program in
computer science would at least understand the characteristics of
basic data structures, but sadly that seems not to be the case.  I've
interviewed many, and relatively few were able to even tell me the
run-time complexity of code they had just written.

Generally I've found that programmers use the features that were
covered in class or described in their chosen textbook or manual.  And
most programmers will read only one or two books on any given
language.

Textbooks and manuals rarely cover anything that is not part of the
core language.  I would expect that most C++ texts to at least
superficially describe the STL, but very few will even mention
multi-threaded programming.  I would expect Ada texts to cover
threading, but would be surprised to see anything more than a mention
of CHARLES or other data structure libraries.

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cgn7bm$snk$3@a1-hrz.uni-duisburg.de>...

:> : But Ada has been almost universally ignored by the Computer Science
:> : research community.
:> 
:> Could you give some examples?

: An example of what?  Of computer scientists who do not program in or
: teach Ada?

I had thought of Computer Science research. When it deals with
concurrent execution in language studies or in programming oriented
presentation, or the development of programming languages,
there seems to be a certain awareness of Ada, even of proteced types,
for example.



Quite a few people I've met didn't like Ada because of they have
seen it as associated with the political, military, and industrial
organisations mentioned in Richard Riehle's posting. Indeed,
if computer languages and compilers do not care about the purpose
of a program, people do. (This is a reason why I'm somewhat uncomfortable
using Ada, sometimes. The military and the weapon makers seem to
be so close... ;-) People also judge languages not only by
their technical merits or by how well you can express ideas
in code. They appear to be influenced largely by the (non-technical)
reputation of a language, by watching the peer group for acceptable
pet languages, or "in"-languages, etc.

(For example, Robert Axelrodt (The Complexity of Cooperation, 1997,
Princeton University Press)
recommends some languages to his students/readers. He compares C,
FORTRAN, (Visual) Basic, Pascal, and C++. LISP, and some math languages
are mentioned in a footnote. "LISP ... is especially
good for handling data structures and programs interchangeably".
...  "My advice is to avoid FORTRAN" ... "is an old language that
is not as convenient to use as the others." ... "If a friend or
coworker is available to answer questions about Pascal, for example,
pick Pascal. ... designed to be a first language for serious
programmers. It is easy to learn, and is structured to encourage good
programming habits. Most of simulations in this volume were programmed
in Pascal." ... C is the most common procedural language among
serious programmers." ... "C++ was chosen as the foundation for the
Java programming language" ... "If you are fairly sure that you will
be doing programming for some time and want to start with a language
that you can grow with, then C or C++ is the best choice."

It would be interesting to know how influential this book is.
But what will people who know these languages say about the
comments? In particular, the "or" in the last relative clause
is misinformation that if spread leads to a serious misconception
in my view. (If you look at the FORTRAN code,
http://pscs.physics.lsa.umich.edu/Software/ComplexCoop.html,
you get an idea of why the author, referring to FORTRAN's "age and
prior popularity" still says no to FORTRAN in 1997.)


-- Georg

Re: ADA Popularity Discussion Request

[Adrian Knoth]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:

> Quite a few people I've met didn't like Ada because of they have
> seen it as associated with the political, military, and industrial
> organisations mentioned in Richard Riehle's posting.
[..]
> The military and the weapon makers seem to be so close... ;-)

The possibility of writing software for airplanes like the YF22,
submarines or long distance missiles and thereby having the chance
to take a drink with James Bond one day was one of reasons when
I decided to choose Ada.


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Mit 16 schon 'nen Freund haben aber nicht zu Mutters 32. kommen!

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Adrian Knoth <adi@thur.de> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
: 
:> Quite a few people I've met didn't like Ada because of they have
:> seen it as associated with the political, military, and industrial
:> organisations mentioned in Richard Riehle's posting.
: [..]
:> The military and the weapon makers seem to be so close... ;-)
: 
: The possibility of writing software for airplanes like the YF22,
: submarines or long distance missiles and thereby having the chance
: to take a drink with James Bond one day was one of reasons when
: I decided to choose Ada.

See? :-)  So if this were the only factor for choosing a language,
Ada's popularity will be a function of the popularity of the military.


-- Georg

Re: ADA Popularity Discussion Request

[Ludovic Brenta]

Georg Bauhaus writes:
> Adrian Knoth wrote:
> : The possibility of writing software for airplanes like the YF22,
> : submarines or long distance missiles and thereby having the chance
> : to take a drink with James Bond one day was one of reasons when
> : I decided to choose Ada.
>
> See? :-) So if this were the only factor for choosing a language,
> Ada's popularity will be a function of the popularity of the
> military.

The military are not the only ones using Ada.  If a language is good
enough to fly airliners, run trains, or control a scanner in a
hospital, then it's good enough for me.

And let's not discount the "Wow!" factor, which is commonly associated
with safety-critical applications, military or not.

-- 
Ludovic Brenta.

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:cgppvn$t4m$1@a1-hrz.uni-duisburg.de...
>
> See? :-)  So if this were the only factor for choosing a language,
> Ada's popularity will be a function of the popularity of the military.
>
Popularity is rarely a good reason for choosing
any tool, including a programming language.  We
who are software developers must understand
how to use more than one tool (language, method,
process, etc).  Certainly some software practitioners
may restrict themselves to one toolset, but this
will have the long-term effect of also restricting
their own career progress.

We choose a tool, in any domain, according to its
being appropriate for the problem we are trying to
solve.

To draw a somewhat rough analogy, one that I have
used before in public lectures and in my publications,
when I need a torque wrench (Ada) that is the tool
I should choose.  When I can get by with an adjustable,
fits anything wrench, I might find C satisfactory for
the job.

Smalltalk is an excellent tool for object-oriented
programming, and a good choice when the
deeper concern is not software safety.   Functional
languages free the developer from concerns about
the underlying representation issues, and allow one
to work at a level of abstraction not easily available
in imperative languages.    I find it difficult to use
functional languages for multiple programmer
projects that are what we might call, large-scale.

A poet friend of mine once explained that he writes
some of his poems in more than one form before he
is satisfied with the outcome.  For example, he might
have an idea for a poem which he first writes as free
verse.   Then he might try to write the same poem as
a sonnet.  Later he might try to express the idea in
several haiku.   At some point he might toy with it as
a kind of jingle.   He plays with the language, the meter,
the structure, and the style before he decides on what
the final poem should look like.

A well-known software practitioner once explained that
he first likes to write his software in Smalltalk, then produce
the final code in Ada.  This is somewhat like an artist who
works in oil, but first sketches some ideas on the canvas
with a pencil.

Each of us works toward the completion of a software
product in a different way.   Some are more comfortable
with C++.  I'm not one of them.  Others are more comfortable
with Smalltalk, Lisp, OCAML, etc.   Over the years, I
have become more comfortable with Ada.  I find myself
able to express my ideas in the language, most of the
time.

There is no perfect programming language. Sometimes I
might want to mix Ada and some other language (e.g.,
SQL or C) to achieve a level of expressiveness not
directly available in Ada.   That does not make Ada
bad.  Rather, the ability to mix other languages into
my Ada code is one of the things I like about the language.

So, we choose a language, not because it is popular,
but because it has the expressive power for the
problem space we require.   In large-scale software,
where lots of people will be involved in the development,
and a high level of reuse is required, the structural and
semantic model of Ada seems to be better than most.
When certain features of some other language need to be
incorporated into that large-scale design, it is no sin
to admit such and take advantage of the expressive
power of both Ada and the imported language to
develop the appropriate solution.

Richard Riehle

Re: ADA Popularity Discussion Request

[jayessay]

"Richard  Riehle" <adaworks@earthlink.net> writes:


> Smalltalk is an excellent tool for object-oriented programming, and
> a good choice when the deeper concern is not software safety.

Are you trying to say that Smalltalk is somehow inherently less "safe"
than things like Ada and Eiffel?  What is "safe" here?


> Functional languages free the developer from concerns about the
> underlying representation issues, and allow one to work at a level
> of abstraction not easily available in imperative languages.

This isn't true as simply stated.  There are counterexamples (most
notably Common Lisp and to a somewhat lesser degree Scheme).  What
real functional languages buy you is the absence of side effects,
which makes proofs about them significantly simpler

/Jon



-- 
'jay' - a n t h o n y at romeo/november/charley com

Re: ADA Popularity Discussion Request

[Richard Riehle]

"jayessay" <nospam@foo.com> wrote in message
news:m3isb2ey3w.fsf@rigel.goldenthreadtech.com...
> "Richard  Riehle" <adaworks@earthlink.net> writes:
>
>
> > Smalltalk is an excellent tool for object-oriented programming, and
> > a good choice when the deeper concern is not software safety.
>
> Are you trying to say that Smalltalk is somehow inherently less "safe"
> than things like Ada and Eiffel?  What is "safe" here?
>
Ada and Eiffel are designed with more compile-time checking capabilities
than Smalltalk.  For safety-critical software, Ada is more appropriate,
in most cases than Smalltalk.   This is not meant to deprecate Smalltalk.
Rather, it is intended to recognize that there are differences in languages,
and some have benefits for certain kinds of problem space than others.
Smalltalk certainly has its benefits, but large-scale, safety-critical
software
is not one of them.
>
> > Functional languages free the developer from concerns about the
> > underlying representation issues, and allow one to work at a level
> > of abstraction not easily available in imperative languages.
>
> This isn't true as simply stated.  There are counterexamples (most
> notably Common Lisp and to a somewhat lesser degree Scheme).  What
> real functional languages buy you is the absence of side effects,
> which makes proofs about them significantly simpler
>
Ah, yes.  Those wonderful counter-examples.  You are correct about
the absence of side-effects (though one can argue counter-examples
even there, but I won't).   When I speak of "underlying representation
issues" I mean the absence of side-effects that accompany the kind
of assignment that concerns an imperative language programmer.  For
example, a Common Lisp programmer rarely agnonizes over such
silliness as constructors, copy constructors, overloading assignment
operators, friends, and all the hideous little details that characterize
so much of C++ programming.   Functional languages tend to more
focused on the problem at hand rather than the environment in which
the problem will be solved and the implications of that environment
on the outcome.

Richard Riehle

Re: ADA Popularity Discussion Request

[jayessay]

"Richard  Riehle" <adaworks@earthlink.net> writes:

> "jayessay" <nospam@foo.com> wrote in message
> news:m3isb2ey3w.fsf@rigel.goldenthreadtech.com...
> > "Richard  Riehle" <adaworks@earthlink.net> writes:
> >
...
> Ada and Eiffel are designed with more compile-time checking capabilities
> than Smalltalk.

Static typing is largely overrated - even Hindley-Milner type systems
such as in Haskell or ML (which are significantly more potent than the
type systems of Eiffel or Ada).  The whole thing sounds great in
theory and you can make some pretty plausible arguments for its
efficacy, but it just doesn't make much difference in practice.

I used to be a real advocate of this stuff and made those arguments
myself (both here and elsewhere).  It (static typing) was one of the
things I was unsure about losing when I switched to Common Lisp (aka
Lisp in this message) for all my major work 7 years ago.  So, I kept a
log of all the errors that I knew would have been caught by compile
time type checking.  I don't rigorously follow this practice anymore,
but as I recall there were only 15 or so in 50K "lines" of Lisp [1].
Furthermore, all but a couple of these were caught immediately on
first testing of function in question.  No such errors ever manefested
themselves in production code.  Yes, I know the typical rebuttal here
is "Yet!".  In theory that's true, but the evidence at this point
suggests it is extremely unlikely.  Also, logic errors (what most
people would consider significantly more negative) are far rarer.

There turn out to be various reasons for this, but two worth
mentioning are the sort of bottom up style of programming as described
by Paul Graham (a kind of agile/extreme programming) and the ability
to move Lisp to the expressive level of the application domain.

In any application/system of any significance these two go hand in
hand.  The second is achieved by crafting a constrained narrowly
focused domain specific language _within_ Lisp, which allows the
programmer to then work at the level of the domain, _both_
syntactically as well as semantically.  This is why Lisp macros
(please don't confuse with any other kind of macro you've come across
before) are such a big deal.

Now, admittedly, creating these is not something your typical code
monkey is going to grok.  This is one of the big reasons why Lisp will
never be as "popular" as something like Java.  But then your typical
code monkey isn't going to be building your core internal application
api either.  Once you've built this though, even a code monkey will be
a lot more productive and produce much more clean and robust code.


> For safety-critical software, Ada is more appropriate,
> in most cases than Smalltalk.   This is not meant to deprecate Smalltalk.
> Rather, it is intended to recognize that there are differences in languages,
> and some have benefits for certain kinds of problem space than others.
> Smalltalk certainly has its benefits, but large-scale, safety-critical
> software
> is not one of them.
> >
> > > Functional languages free the developer from concerns about the
> > > underlying representation issues, and allow one to work at a level
> > > of abstraction not easily available in imperative languages.
> >
> > This isn't true as simply stated.  There are counterexamples (most
> > notably Common Lisp and to a somewhat lesser degree Scheme).  What
> > real functional languages buy you is the absence of side effects,
> > which makes proofs about them significantly simpler
> >
> Ah, yes.  Those wonderful counter-examples.  You are correct about
> the absence of side-effects (though one can argue counter-examples
> even there, but I won't).

Counter examples are important for getting the _concepts_ correct.  If
you want to say "typically this" or "typically that", that's fine and
such points can carry important information.


> For example, a Common Lisp programmer rarely agnonizes over such
> silliness as constructors, copy constructors, overloading assignment
> operators, friends, and all the hideous little details that
> characterize so much of C++ programming.

True (actually "rarely" should be replaced with "never"), but those
horrors are orthogonal to being imperative.  Afterall, Java, lame as
it is, doesn't have this type of grime to work through.


> Functional languages tend to more focused on the problem at hand
> rather than the environment in which the problem will be solved and
> the implications of that environment on the outcome.

Partly.  But typical functional languages (haskell, ml, ...) don't
have any means for directly encompassing domain semantics into them.
For that, you need something like Lisp macros.


/Jon

----

1. Which from experience would typically be in the range of 250K-500K
lines of equivalent Ada/C++/Eiffel/etc.  An order of magnitude is not
hyperbole here even though most uninitiated developers will raise
their eyebrows or roll their eyes.  I have a few examples where _two_
orders of magnitude would not be hyperbole as you would need a fully
integrated and embedded optimizing compiler to achieve an equivalent
result.


-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Kevin Cline]

jayessay <nospam@foo.com> wrote in message news:<m3656vfgmf.fsf@rigel.goldenthreadtech.com>...
> "Richard  Riehle" <adaworks@earthlink.net> writes:
> 
> > "jayessay" <nospam@foo.com> wrote in message
> > news:m3isb2ey3w.fsf@rigel.goldenthreadtech.com...
> > > "Richard  Riehle" <adaworks@earthlink.net> writes:
> > >
>  ...
> > Ada and Eiffel are designed with more compile-time checking capabilities
> > than Smalltalk.
> 
> Static typing is largely overrated - even Hindley-Milner type systems
> such as in Haskell or ML (which are significantly more potent than the
> type systems of Eiffel or Ada).  The whole thing sounds great in
> theory and you can make some pretty plausible arguments for its
> efficacy, but it just doesn't make much difference in practice.

I've come to the same conclusion.  Once you decide to test code before
you write it, strong typing loses most of it's value.  On the other
hand, if I'm working on code without a good set of automated tests,
then strong typing is a very nice thing to have.

> Furthermore, all but a couple of these were caught immediately on
> first testing of function in question.  

> No such errors ever manefested
> themselves in production code.  Yes, I know the typical rebuttal here
> is "Yet!".  In theory that's true, but the evidence at this point
> suggests it is extremely unlikely.  

In theory and in practice, no useful programming language can
eliminate all possibility of runtime errors.  No matter what, you
still have to test the code.

> Also, logic errors (what most
> people would consider significantly more negative) are far rarer.
> 
> There turn out to be various reasons for this, but two worth
> mentioning are the sort of bottom up style of programming as described
> by Paul Graham (a kind of agile/extreme programming) and the ability
> to move Lisp to the expressive level of the application domain.
> 
> In any application/system of any significance these two go hand in
> hand.  The second is achieved by crafting a constrained narrowly
> focused domain specific language _within_ Lisp, which allows the
> programmer to then work at the level of the domain, _both_
> syntactically as well as semantically.  This is why Lisp macros
> (please don't confuse with any other kind of macro you've come across
> before) are such a big deal.
> 
> Now, admittedly, creating these is not something your typical code
> monkey is going to grok.  This is one of the big reasons why Lisp will
> never be as "popular" as something like Java.  But then your typical
> code monkey isn't going to be building your core internal application
> api either.  Once you've built this though, even a code monkey will be
> a lot more productive and produce much more clean and robust code.
> 
> > For example, a Common Lisp programmer rarely agnonizes over such
> > silliness as constructors, copy constructors, overloading assignment
> > operators, friends, and all the hideous little details that
> > characterize so much of C++ programming.

I'm skeptical.  In any language, data structures will require
initialization to reach the empty state.  You still have to write the
code, it just has a different name.  Instead of MyThing(int mobys,
...) you have (defun make-my-thing(mobys ...).  Instead of a copy
constructor, you have (defun clone-my-thing(thing) ...).  And if you
open files or lock mutexes or consume any other limited resource, you
are going to have to ensure they are released by writing the
equivalent of a destructor.

When done well, C++ programming does not get mired in hideous little
details.  But like most programming, it is rarely done well.  And the
more popular a language, the lower the performance of the average
practitioner.  Lots of people learned C++ and Java because that's what
the market demanded.  So there is lots of horrible C++ code and Java
code.  People learn LISP because they love programming.  Not all LISP
programmers are geniuses, but almost all are well above the mean.
...
> 1. Which from experience would typically be in the range of 250K-500K
> lines of equivalent Ada/C++/Eiffel/etc.  An order of magnitude is not
> hyperbole here even though most uninitiated developers will raise
> their eyebrows or roll their eyes. 

This I know to be true, although again it's not fair to compare the
C++ code from an average programmer to the LISP code from an expert. 
An expert C++ programmer can reduce the line count of typical code by
60% or more.  In either language, experts will refactor until a new
domain-specific language appears.

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0409042036.5d4822a2@posting.google.com...
> jayessay <nospam@foo.com> wrote in message
news:<m3656vfgmf.fsf@rigel.goldenthreadtech.com>...
> > "Richard  Riehle" <adaworks@earthlink.net> writes:
> >  ...
> > > Ada and Eiffel are designed with more compile-time checking
capabilities
> > > than Smalltalk.
> >
> > Static typing is largely overrated - even Hindley-Milner type systems
> > such as in Haskell or ML (which are significantly more potent than the
> > type systems of Eiffel or Ada).  The whole thing sounds great in
> > theory and you can make some pretty plausible arguments for its
> > efficacy, but it just doesn't make much difference in practice.
>
> I've come to the same conclusion.  Once you decide to test code before
> you write it, strong typing loses most of it's value.  On the other
> hand, if I'm working on code without a good set of automated tests,
> then strong typing is a very nice thing to have.
>
No one argues that testing is unimportant.   However, testing is not
sufficient in the creation of dependable large-scale software systems.

We test for the expected, and design for the unexpected.   We can test
for the errors we anticipate, but must design for those we cannot
anticipate.  This is an essential idea in creating software with Ada.

Static typing is only one aspect of design.   In Ada, types have
proven over and over their value when used in conjuction with
the other design features of the language, including such things
as the visibility rules, accessibility rules, and named association.
Ada goes well beyond compile-time type checking.  In fact, if
it were nothing more than another language based solely on
type checking, much of this criticism would be justified.  Happily,
it is a far more comprehensive software design language than
seems evident from some of the criticism, so far.

No language can protect us, at compile time, from every possible
error.   No tool can prevent us from every kind of mistake, whether
it is a software tool or hardware tool.  But some kinds of tools
can reduce the number of mistakes we make.   Does it not seem
reasonable to use those tools when they make economic sense.
The type model, the visibility rules, the named association rules,
separate compilation units, the ability to truly encapsulate the
structure of types while making them usable, the restrictions
on pointers, the compiler checked generic instantiations, and the
many other aspects of Ada that can be evaluated by the compiler
simply help to improve the life of the programmer, the designer,
and the quality of the final product.   This capability, when combined
with testing, allows us to build the kind of software our customers
should expect.

We certainly can use these features incorrectly.  However, when
used properly, Ada gives the designer a better set of options for
dependable software creation than its nearest competitors.

Richard Riehle

Re: ADA Popularity Discussion Request

[Jean-Marc Bourguet]

kevin.cline@gmail.com (Kevin Cline) writes:

> Once you decide to test code before you write it, strong
> typing loses most of it's value.

Well, I've been told that the earlier you detect an error,
the easier and the cheaper it was to fix it.  This is
corrobated by my experience.  Errors detected by strong type
checking are found earlier than those detected by testing.

More, testing can only show that something happen.  Type
checking ensure that something does not happen.  So with
testing you'll test only the cases you have though about.
Most probably the one which are corrects.

So testing will catch only parts of the error that strong
type checking will find and that at an higher price.  That
is not to say that testing should be dropped: there are
problems which are not detected by type checking, but the
earlier detection -- and more precise localisation -- of the
problems worth the cost of strong type checking.

Yours,

-- 
Jean-Marc

Re: ADA Popularity Discussion Request

[jayessay]

Jean-Marc Bourguet <jm@bourguet.org> writes:

> kevin.cline@gmail.com (Kevin Cline) writes:
> 
> > Once you decide to test code before you write it, strong
> > typing loses most of it's value.
> 
> Well, I've been told that the earlier you detect an error,
> the easier and the cheaper it was to fix it.

Absolutely.


>  Errors detected by strong type checking are found earlier than
> those detected by testing.

Not if the testing is the sort used in bottom-up dynamic incremental
development.  There you are often testing both the "type constraints"
_and_ logic at the subexpression level up through clause and finally
to function!  This is way earlier and faster than any static type
checking.  It is also more robust as it is checking a lot more over a
far greater set of code paths.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
 
: Not if the testing is the sort used in bottom-up dynamic incremental
: development.  There you are often testing both the "type constraints"
: _and_ logic at the subexpression level up through clause and finally
: to function!  This is way earlier and faster than any static type
: checking.  It is also more robust as it is checking a lot more over a
: far greater set of code paths.

It isn't surprising that testing checks more than static type checking
alone. I don't know, has anybody suggested that static type checking
is to be used alone?

When you are testing "type constraints", how is that different from
a compiler testing type constraints at compile time?

What do you mean by robust? If a translator sees a function call, where
the function has a specific formal T parameter, and the translator
can do type checking before running this piece of the program,
doesn't this remove the necessity to test a number of code paths
in the first place?
In the following sense, if I have:

  (DEFUN ANY (X) ...)  ; old LISP

versus

  function any(x: T) return N;

the first notation would leave two additional things that have
to be tested by running the piece of program:

1  can "ANY" work with some actual parameter value that happens to be
   of type S (different from T) at test time?
2  provided 1, can the value returned by "ANY" be used in expression E
   that expects a value of type N (that is, not of type (Q or S or T or ...))?


-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> jayessay <nospam@foo.com> wrote:
>  
> : Not if the testing is the sort used in bottom-up dynamic incremental
> : development.  There you are often testing both the "type constraints"
> : _and_ logic at the subexpression level up through clause and finally
> : to function!  This is way earlier and faster than any static type
> : checking.  It is also more robust as it is checking a lot more over a
> : far greater set of code paths.
> 
> It isn't surprising that testing checks more than static type checking
> alone. I don't know, has anybody suggested that static type checking
> is to be used alone?

No.  But the point is with static typing you lose this sort of dynamic
incremental development.  See my other post on this (reply to you).


> When you are testing "type constraints", how is that different from
> a compiler testing type constraints at compile time?

Because you don't need to set up an entire boiler plate to test one
thing and then go throug a compile-link-execute-edit-again cycle.
Further, you are simultaneously testing the logic.


> What do you mean by robust?

Both type checks and logic errors are checked simultaneously and at
very fine grained levels.


> If a translator sees a function call, where the function has a
> specific formal T parameter, and the translator can do type checking
> before running this piece of the program, doesn't this remove the
> necessity to test a number of code paths in the first place?

That is often insufficient because it doesn't ensure anything about
whether the _content_ of a value conforming to the type is correct for
the input of the function.


> In the following sense, if I have:
> 
>   (DEFUN ANY (X) ...)  ; old LISP
>
>   function any(x: T) return N; -- Ada

"any" seems like an odd name if you don't really want x to be
_anything_.  Anyway here's a couple of ways to achieve the same
_typing_ constraint [1]

(defun any (x)
  (assert x any-type "a value of type any-type")
  (let ((result ...))
  ...
    (assert result N "a return value of type N")
    result))

(declaim (ftype (function (a-type) N) foo))
(defun any (x) ...)


/Jon


[1] I think you are getting confused into thinking Lisp is somehow not
typed simply because it doesn't have static typing.  It is actually
very strongly typed - actually stronger than Ada as there is no
equivalent of Unchecked_Conversion.  All _values_ have a type and that
cannot be changed.

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[jayessay]

jayessay <nospam@foo.com> writes:

brain fart...


> (declaim (ftype (function (a-type) N) foo))
                                        ^^^ should be any
> (defun any (x) ...)


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
 
 
:> What do you mean by robust?
: 
: Both type checks and logic errors are checked simultaneously and at
: very fine grained levels.

And static type checking can't add, at least in many relevant
cases?

:> If a translator sees a function call, where the function has a
:> specific formal T parameter, and the translator can do type checking
:> before running this piece of the program, doesn't this remove the
:> necessity to test a number of code paths in the first place?
: 
: That is often insufficient because it doesn't ensure anything about
: whether the _content_ of a value conforming to the type is correct for
: the input of the function.

Sure it is insufficient. But it adds value by removing the need to
test what the compiler has already found out. How about typos?

Here is a fake: 

(defun next (n) (1 + n))
(defun hext (n) (1 + (mod n 16)))

; ...

(defun advance (n) (hext n))  ; a slip of the finger

(advance 3)
4

Fine.

(advance 16)
1

Oops. Types could help I'd say.

 
:> In the following sense, if I have:
:> 
:>   (DEFUN ANY (X) ...)  ; old LISP
:>
:>   function any(x: T) return N; -- Ada
: 
: "any" seems like an odd name if you don't really want x to be
: _anything_.

OK, I have chosen the name to be irrelevant, a better name would
have been SOME-FUNC.

: Anyway here's a couple of ways to achieve the same
: _typing_ constraint [1]

I know that Lisp values are of a type.  But I simply don't see how
declaring the type of a function (via arguments), say, can't be a win.
What will the ML programmers say?


:  (assert x any-type "a value of type any-type")
 
: (declaim (ftype (function (a-type) N) foo))
: (defun any (x) ...)
 
Does this hinder incremental testing?


-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> jayessay <nospam@foo.com> wrote:
> : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
>  
>  
> :> What do you mean by robust?
> : 
> : Both type checks and logic errors are checked simultaneously and at
> : very fine grained levels.
> 
> And static type checking can't add, at least in many relevant
> cases?

In some scenarios it can indeed add a certain level of confidence.  I
think most dynamic type folks (certainly most everyone over on c.l.l)
would look at it something like this: "Static typing can indeed
provide some value.  Dynamic typing provides an enormous level of
value.  If I could have static typing without it destroying the value
provided by dynamic typing, I'd take it.  But the two are
fundamentally at odds in what they _need_ in order to _provide_ what
they offer.


> :> If a translator sees a function call, where the function has a
> :> specific formal T parameter, and the translator can do type checking
> :> before running this piece of the program, doesn't this remove the
> :> necessity to test a number of code paths in the first place?
> : 
> : That is often insufficient because it doesn't ensure anything about
> : whether the _content_ of a value conforming to the type is correct for
> : the input of the function.
> 
> Sure it is insufficient. But it adds value by removing the need to
> test what the compiler has already found out. How about typos?

True.  But since this is determined anyway as part of incremental
development it doesn't actually save anything in practice.  Typos are
a good example.


> Here is a fake: 
> 
> (defun next (n) (1 + n))
> (defun hext (n) (1 + (mod n 16)))

Let's see this in practice:

(defun next (n) (1+ n))
==> next

;; let's try it

(dotimes (i 10)
  (let ((n (random 100000)))
    (format t "~%(next ~a) --> ~a" n (next n))))

==>
(next 97872) --> 97873
(next 73063) --> 73064
(next 74426) --> 74427
(next 84763) --> 84764
(next 45797) --> 45798
(next 82856) --> 82857
(next 35267) --> 35268
(next 732) --> 733
(next 90138) --> 90139
(next 73850) --> 73851


(defun hext (n) (1+ (mod n 16)))
==> hext

;; prove it:
(dotimes (n 17)
    (format t "~%(hext ~a) --> ~a" n (hext n)))

==>
(hext 0) --> 1
(hext 1) --> 2
(hext 2) --> 3
(hext 3) --> 4
(hext 4) --> 5
(hext 5) --> 6
(hext 6) --> 7
(hext 7) --> 8
(hext 8) --> 9
(hext 9) --> 10
(hext 10) --> 11
(hext 11) --> 12
(hext 12) --> 13
(hext 13) --> 14
(hext 14) --> 15
(hext 15) --> 16
(hext 16) --> 1

Hey, hext is broken

;; fix it
(defun hext (n) (mod (1+ n) 16))

==> hext

;; prove it:
(dotimes (n 17)
    (format t "~%(hext ~a) --> ~a" n (hext n)))

==>
(hext 0) --> 1
(hext 1) --> 2
(hext 2) --> 3
(hext 3) --> 4
(hext 4) --> 5
(hext 5) --> 6
(hext 6) --> 7
(hext 7) --> 8
(hext 8) --> 9
(hext 9) --> 10
(hext 10) --> 11
(hext 11) --> 12
(hext 12) --> 13
(hext 13) --> 14
(hext 14) --> 15
(hext 15) --> 0
(hext 16) --> 1

That's better.


(defun advance (n) (hext n))  ; a slip of the finger

==> advance

;; try it
(dotimes (n 17)
    (format t "~%(advance ~a) --> ~a" n (advance n)))

==>
(advance 0) --> 1
(advance 1) --> 2
(advance 2) --> 3
(advance 3) --> 4
(advance 4) --> 5
(advance 5) --> 6
(advance 6) --> 7
(advance 7) --> 8
(advance 8) --> 9
(advance 9) --> 10
(advance 10) --> 11
(advance 11) --> 12
(advance 12) --> 13
(advance 13) --> 14
(advance 14) --> 15
(advance 15) --> 0
(advance 16) --> 1

Hey, this is broken.  Looks like hext was used when I wanted next!

Or

;;; Pre condition: N a number
;;; Post condition: result = (1+ N)
;;;
(defun advance (n)
  (check-type n number "a number")
  (let ((result (hext n)))
    (assert (= result (1+ n)) nil
	    (format nil "ADVANCE: Post condition (= RESULT (1+ N)) failed; ~
                        [~A /= ~A]" result n))
    result))


> Oops. Types could help I'd say.

What you are saying is, range types (as in Ada) could have caught
this.  True, but they would not have caught it quicker (or even as
quick) as this did.  Also, they wouldn't have caught the error in hext
until you ran it anyway.


> I know that Lisp values are of a type.  But I simply don't see how
> declaring the type of a function (via arguments), say, can't be a win.
> What will the ML programmers say?

They will (more or less) agree with you.  Of course they will go
further and claim that things like Ada/Eiffel/C++/Java/etc have lame
type systems and that what you buy with a true formal type system
(like one based on say, Hindley-Milner) makes dynamic arguments less
potent/interesting/valuable/whatever.


> :  (assert x any-type "a value of type any-type")
>  
> : (declaim (ftype (function (a-type) N) foo))
> : (defun any (x) ...)
>  
> Does this hinder incremental testing?

No.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

:> Sure it is insufficient. But it adds value by removing the need to
:> test what the compiler has already found out. How about typos?
: 
: True.  But since this is determined anyway as part of incremental
: development it doesn't actually save anything in practice.  Typos are
: a good example.
: 
: 
:> Here is a fake: 
:> 
:> (defun next (n) (1 + n))
:> (defun hext (n) (1 + (mod n 16)))
: 
: Let's see this in practice:

[lengthy testing snipped]

Do you see what I mean?  ;-) ;-) ;-)  Wouldn't have happend with
proper typing and static type checks, see below.

: What you are saying is, range types (as in Ada) could have caught
: this.  True, but they would not have caught it quicker (or even as
: quick) as this did.

No, I'm saying that this error can occur in an executing piece
of program if and only if the compiler allows me to mix
operations of an integer type and operations a modular type
without notice.
  Things like this don't happen if you get the types right at
compiletime. Similarly, physical units can be checked at compile
time using C++ templates. Is there a set of Lisp macros that
guarantees unit safe computations before a program runs?

: Also, they wouldn't have caught the error in hext
: until you ran it anyway.

Not true as explained above.


-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> jayessay <nospam@foo.com> wrote:
> : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
> 
> :> Sure it is insufficient. But it adds value by removing the need to
> :> test what the compiler has already found out. How about typos?
> : 
> : True.  But since this is determined anyway as part of incremental
> : development it doesn't actually save anything in practice.  Typos are
> : a good example.
> : 
> : 
> :> Here is a fake: 
> :> 
> :> (defun next (n) (1 + n))
> :> (defun hext (n) (1 + (mod n 16)))
> : 
> : Let's see this in practice:
> 
> [lengthy testing snipped]
> 
> Do you see what I mean?  ;-) ;-) ;-)  Wouldn't have happend with
> proper typing and static type checks, see below.

I never said types here would not have caught the "advance" error.  I
simply state that the dynamic version was as efficacious at catching
that error and also caught the logic error in hext at the same time.


> : What you are saying is, range types (as in Ada) could have caught
> : this.  True, but they would not have caught it quicker (or even as
> : quick) as this did.
> 
> No, I'm saying that this error can occur in an executing piece
> of program if and only if the compiler allows me to mix
> operations of an integer type and operations a modular type
> without notice.

OK, that is a better way than simple ranges.  But it doesn't change
the point, see below.


>   Things like this don't happen if you get the types right at
> compiletime.

Yes, and they don't happen at runtime if pre and post are checked
during incremental development.  If you don't do this, then you will
likely have problems - just like if you don't get the types right in
static languages.


> Similarly, physical units can be checked at compile time using C++
> templates.  Is there a set of Lisp macros that guarantees unit safe
> computations before a program runs?

Yes this has been done.  From what I've seen it is a very nice system.
Where it can't make the determination at compile time it generates
code for the checks and conversions at runtime.


> : Also, they wouldn't have caught the error in hext
> : until you ran it anyway.
> 
> Not true as explained above.

Your explanation above does not cover the logic error.  I don't see
right off how modular types catch that.

with Text_Io; use Text_Io;

procedure Foo is

   type Hex_Num is mod 16;

   function Hext (N : Integer) return Hex_Num is
   begin
      -- == (1+ (n mod 16)), which is the logic error.
      return Hex_Num(1 + (N mod Hex_Num'Modulus));
   end Hext;

begin
   for I in 0..20 loop
      Put_Line("Answer is: " & Hex_Num'Image(Hext(i)));
   end loop;
end;

$ gnatmake hext.adb
==>
gcc -c hext.adb
hext.adb:3:11: warning: file name does not match unit name, should be "foo.adb"
gnatbind -x hext.ali
gnatlink hext.ali

[Yeah, I know the file name is bogus, but there are no errors or warnings
 about the error, not surprising since you can't know there is a bomb here
 at compile time]

$ ./hext
Answer is:  1
Answer is:  2
Answer is:  3
Answer is:  4
Answer is:  5
Answer is:  6
Answer is:  7
Answer is:  8
Answer is:  9
Answer is:  10
Answer is:  11
Answer is:  12
Answer is:  13
Answer is:  14
Answer is:  15

raised CONSTRAINT_ERROR : hext.adb:9
$ 

Same as the Lisp:

(deftype hex-num () `(mod 16))

(defun hext (n)
  (check-type n integer)
  (let ((result (1+ (mod  n 16))))
    (check-type result hex-num)
    result))
==> hext

(dotimes (n 20)
  (format t "~%(hext ~a) --> ~a" n (hext n)))

(hext 0) --> 1
(hext 1) --> 2
(hext 2) --> 3
(hext 3) --> 4
(hext 4) --> 5
(hext 5) --> 6
(hext 6) --> 7
(hext 7) --> 8
(hext 8) --> 9
(hext 9) --> 10
(hext 10) --> 11
(hext 11) --> 12
(hext 12) --> 13
(hext 13) --> 14
(hext 14) --> 15
Error: the value of RESULT is 16, which is not of type HEX-NUM.
  [condition type: TYPE-ERROR]

Restart actions (select using :continue):
 0: supply a new value for RESULT.
 1: Return to Top Level (an "abort" restart).
 2: Abort entirely from this process.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:

: Yes, and they don't happen at runtime if pre and post are checked
: during incremental development.  If you don't do this, then you will
: likely have problems - just like if you don't get the types right in
: static languages.

Is it really much more time efficient, if pre and post checking is done
by an incrementing human? If so, how much?

 
: Your explanation above does not cover the logic error.  I don't see
: right off how modular types catch that.

See below, there isn't a logic error, only a typo.

: with Text_Io; use Text_Io;
: 
: procedure Foo is
: 
:   type Hex_Num is mod 16;
: 
:   function Hext (N : Integer) return Hex_Num is
:   begin
:      -- == (1+ (n mod 16)), which is the logic error.
                                           ^^^^^^^^^^^^ not really, see below
:      return Hex_Num(1 + (N mod Hex_Num'Modulus));
:   end Hext;
: 
: begin
:   for I in 0..20 loop
:      Put_Line("Answer is: " & Hex_Num'Image(Hext(i)));
      Put_Line("Answer is: " & Integer'Image(Hext(i)));
:   end loop;
: end;

In the Lisp example there was a "typo context". "next" should have
been where "hext" was actually typed in the Lisp example.
Therefore, an integer number was actually wanted ("next"), not
a hex number ("hext").
So there must be an Integer'image reflecting the logic/expectation
("next") not a Hex_Num'image (typo "hext").
The error is caught by the compiler.

    15.       Put_Line("Answer is: " & Integer'Image(Hext(i)));
                                                     |
        >>> expected type "Standard.Integer"
        >>> found type "Hex_Num" defined at line 4



-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> jayessay <nospam@foo.com> wrote:
> 
> : Yes, and they don't happen at runtime if pre and post are checked
> : during incremental development.  If you don't do this, then you will
> : likely have problems - just like if you don't get the types right in
> : static languages.
> 
> Is it really much more time efficient, if pre and post checking is done
> by an incrementing human? If so, how much?

Generally, yes.  For two general reasons: 1. you are always sure of
the logic as well as the type consistency 2. You don't have global
"system integration" issues as each incremental step subsumes an
integration aspect.



> : Your explanation above does not cover the logic error.  I don't see
> : right off how modular types catch that.
> 
> See below, there isn't a logic error, only a typo.

No, I'm not talking about the typo in the advance function.  I'm
talking about the logic error in the Hext function itself!

> 
> : with Text_Io; use Text_Io;
> : 
> : procedure Foo is
> : 
> :   type Hex_Num is mod 16;
> : 
> :   function Hext (N : Integer) return Hex_Num is
> :   begin
> :      -- == (1+ (n mod 16)), which is the logic error.
>                                            ^^^^^^^^^^^^ not really, see below
> :      return Hex_Num(1 + (N mod Hex_Num'Modulus));
> :   end Hext;
> : 
> : begin
> :   for I in 0..20 loop
> :      Put_Line("Answer is: " & Hex_Num'Image(Hext(i)));
>       Put_Line("Answer is: " & Integer'Image(Hext(i)));
> :   end loop;
> : end;
> 
> In the Lisp example there was a "typo context". "next" should have
> been where "hext" was actually typed in the Lisp example

That's not the logic error.  The logic error is that Hext is broken
due to the incorrect expression at the line noted above.


> Therefore, an integer number was actually wanted ("next"), not
> a hex number ("hext").

> So there must be an Integer'image reflecting the logic/expectation
> ("next") not a Hex_Num'image (typo "hext").
> The error is caught by the compiler.
> 
>     15.       Put_Line("Answer is: " & Integer'Image(Hext(i)));
>                                                      |
>         >>> expected type "Standard.Integer"
>         >>> found type "Hex_Num" defined at line 4


No. This would be a different (brain fart) type of error.  The logic
error is in Hext - it does not correctly compute the residue class
defined by Hex_Num!!!  This is shown by the Ada RT raising constraint
error - even though the compiler didn't (indeed _couldn't_ complain
about the definition!!!).

/Jon


-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:> jayessay <nospam@foo.com> wrote:
:> 
:> : Yes, and they don't happen at runtime if pre and post are checked
:> : during incremental development.  If you don't do this, then you will
:> : likely have problems - just like if you don't get the types right in
:> : static languages.
:> 
:> Is it really much more time efficient, if pre and post checking is done
:> by an incrementing human? If so, how much?
: 
: Generally, yes.  For two general reasons: 1. you are always sure of
: the logic as well as the type consistency

Yes, within the limiting conditions of parameter values of a suitable
type.

: 2. You don't have global
: "system integration" issues as each incremental step subsumes an
: integration aspect.

OK. Similarly.


:> : Your explanation above does not cover the logic error.  I don't see
:> : right off how modular types catch that.
:> 
:> See below, there isn't a logic error, only a typo.
: 
: No, I'm not talking about the typo in the advance function.  I'm
: talking about the logic error in the Hext function itself!

That's your interpretation of the "hext" function as given in
the Lisp example.

:> In the Lisp example there was a "typo context". "next" should have
:> been where "hext" was actually typed in the Lisp example
: 
: That's not the logic error.  The logic error is that Hext is broken
: due to the incorrect expression at the line noted above.

It is broken WRT your interpretation of its undocumented purpose.
It is not a broken Lisp function at all and might reflect a
specification precisely.  It could as well have been

 (defun hext (n) (+ offset  (mod n 16)))

(What has made you think otherwise? :-)

or even

 ;; hext: string -> string
 (defun hext (n) (extract-h-from-oldstyle-german-th-word n))
  ;; make Thor from Tor etc.
 
With the same typo leading to the discovery of the error only
a run time or test time.
 
:> Therefore, an integer number was actually wanted ("next"), not
:> a hex number ("hext").

(In fact at the point of definition of "advance", the programmer
will likely have been aware of the "next" function, but not of
a "hext" function. The test might have revealed the existence of
the "hext" function in the first place. (I do like surprises
sometimes, as they also make you see things that you might have
missed before :-)

Now consider a situation where there are no two similarly named
functions in the environment, with similar results, both producing
values of the same Lisp number type, and both consuming arguments of
the same number types.

I think that a static type system like Ada's, if used, will
likely catch a logic error at compile time, that is when by mistake
one function is used where the other should have been used. This is because
a value of a type being in  1 .. 10  will not be compatible with a value
of another type's  1 .. 10.  The program will not have to be run to
find out, at least there is a chance for this to to be found out
prior to surprises at run time, even if not every case can be handled
by compile time type checking.


; old Rome

(defun 1-to-10 (n)         (random-even 1 10))
; ...
(defun 1-out-of-10 (n)     (test-status  parts-of-town n))

(set-on-fire (1-to-10 3))   ; should have been 1-out-of-10

-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Now consider a situation where there are no two similarly named
> functions in the environment, with similar results, both producing
> values of the same Lisp number type, and both consuming arguments of
> the same number types.
> 
> I think that a static type system like Ada's, if used, will
> likely catch a logic error at compile time, that is when by mistake
> one function is used where the other should have been used.

This is at best unlikely as has been demonstrated.  Types, type
systems, and type consistency offer little to no help with this.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:> Now consider a situation where there are no two similarly named
:> functions in the environment, with similar results, both producing
:> values of the same Lisp number type, and both consuming arguments of
:> the same number types.
:> 
:> I think that a static type system like Ada's, if used, will
:> likely catch a logic error at compile time, that is when by mistake
:> one function is used where the other should have been used.
: 
: This is at best unlikely as has been demonstrated.

Where? Our arguments have been revolving around an undocumented
function, whose purpose has _not_ been the one that has helped
you in finding a (wrong) supposed logic error. There was no
logic error. The function has had a different purpose than the
one you have attributed. This is worse, even if it seems to support
you argument.

: Types, type
: systems, and type consistency offer little to no help with this.

Once more, could you be more specific with "little to no" and perhaps
apply this to the expression (+ offset (mod n 16))?


-- Georg

Re: ADA Popularity Discussion Request

[Chad R. Meiners]

"jayessay" <nospam@foo.com> wrote in message 
news:m3acw0bl1u.fsf@rigel.goldenthreadtech.com...
> with Text_Io; use Text_Io;
>
> procedure Foo is
>
>   type Hex_Num is mod 16;
>
>   function Hext (N : Integer) return Hex_Num is
>   begin
>      -- == (1+ (n mod 16)), which is the logic error.
>      return Hex_Num(1 + (N mod Hex_Num'Modulus));
>   end Hext;

However, most Ada programmers would have written it like

procedure Foo is
    type Hex_Num is mod 16;

    function To_Hex_Num(Item : Integer) return Hex_Num is
    begin  -- This function provides the correct conversion
           -- for use by all other subroutines.
        return Hex_Num(Item mod Hex_Num'Modulus);
    end To_Hex_Num;

    function Hext (N : Integer) return Hex_Num is
    begin
        return 1 + To_Hex_Num(N);  -- Note To_Hex_Num(1+N) also works
    end Hext;

    ...

and avoided the problem altogether.

-CRM

Re: ADA Popularity Discussion Request

[jayessay]

chad.rmeiners@gmail.com (Chad R. Meiners) writes:

> "jayessay" <nospam@foo.com> wrote in message 
> news:m3acw0bl1u.fsf@rigel.goldenthreadtech.com...
> > with Text_Io; use Text_Io;
> >
> > procedure Foo is
> >
> >   type Hex_Num is mod 16;
> >
> >   function Hext (N : Integer) return Hex_Num is
> >   begin
> >      -- == (1+ (n mod 16)), which is the logic error.
> >      return Hex_Num(1 + (N mod Hex_Num'Modulus));
> >   end Hext;
> 
> However, most Ada programmers would have written it like
> 
> procedure Foo is
>     type Hex_Num is mod 16;
> 
>     function To_Hex_Num(Item : Integer) return Hex_Num is
>     begin  -- This function provides the correct conversion
>            -- for use by all other subroutines.
>         return Hex_Num(Item mod Hex_Num'Modulus);
>     end To_Hex_Num;
> 
>     function Hext (N : Integer) return Hex_Num is
>     begin
>         return 1 + To_Hex_Num(N);  -- Note To_Hex_Num(1+N) also works
>     end Hext;
> 
>     ...
> 
> and avoided the problem altogether.

All you are saying is that _the programmer_ would have caught the
logic error!  In this ridiculously simple case, sure.  The Lisp
programmer would never have brain farted like this in this simple case
either!!  The point is, the programmer in this case, Georg Bauhaus,
_did_ make the error and did not avoid the problem!


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Chad R. Meiners]

jayessay <nospam@foo.com> wrote in message news:<m3fz5r9bnv.fsf@rigel.goldenthreadtech.com>...

> 
> All you are saying is that _the programmer_ would have caught the
> logic error!  

No that wasn't what I was saying.  I was pointing out how Ada's type
system helps programmers to think in a way that avoids these type of
logic errors altogether. By taking advantage of the type system, the
programmer is less likely to write the code that you posted and more
likely to write the code that I posted in the first place.

-CRM

Re: ADA Popularity Discussion Request

[Jean-Marc Bourguet]

jayessay <nospam@foo.com> writes:

> Jean-Marc Bourguet <jm@bourguet.org> writes:
> 
> > kevin.cline@gmail.com (Kevin Cline) writes:
> > 
> > > Once you decide to test code before you write it, strong
> > > typing loses most of it's value.
> > 
> > Well, I've been told that the earlier you detect an error,
> > the easier and the cheaper it was to fix it.
> 
> Absolutely.
> 
> 
> >  Errors detected by strong type checking are found earlier than
> > those detected by testing.
> 
> Not if the testing is the sort used in bottom-up dynamic incremental
> development.

That's perhaps one difference between us: I do mainly
maintenance and development of small features in an existing
multi-million lines program whose development started more
than 15 years ago with complex interactions between the
components of the program (some inherent to the problem,
some due to lack of forsightness 10 years ago, some due to
bad practice...)

It has a lisp dialect as extension language and one of the
maintenance problem is that some part has been written in it
with "bottom-up dynamic incremental development" testing
only the cases the developper was thinking about and fail
sometimes horribly when faced to the customer interaction.

> There you are often testing both the "type constraints"
> _and_ logic at the subexpression level up through clause
> and finally to function!  This is way earlier and faster
> than any static type checking.

Not in my experience.  Our tests takes days to run.  And
when one of them find a bug that static typing would have
found, I'm not happy at all.

Because you see, some of the functions are used by other
components in way I'm sometimes surprised.  Type information
is not only used by the compiler, it is also used as
documentation by the programmer.  And it is the most usefull
kind of documentation: the one which is in sync with the
code.

> It is also more robust as it is checking a lot more over a
> far greater set of code paths.

I'm sorry, tests check *other things* than type constaints,
*not* more things.

And then anew:

Tests can only proove that something happen, never that it
doesn't.

Type checking ensure that some constraints are never
violated.  That's outside the scoop of testing.

A+

-- 
Jean-Marc

Re: ADA Popularity Discussion Request

[jayessay]

Jean-Marc Bourguet <jm@bourguet.org> writes:

> jayessay <nospam@foo.com> writes:
> 
> > Jean-Marc Bourguet <jm@bourguet.org> writes:
> > 
> > > kevin.cline@gmail.com (Kevin Cline) writes:
> > > 
> > > > Once you decide to test code before you write it, strong
> > > > typing loses most of it's value.
> > > 
> > > Well, I've been told that the earlier you detect an error,
> > > the easier and the cheaper it was to fix it.
> > 
> > Absolutely.
> > 
> > 
> > >  Errors detected by strong type checking are found earlier than
> > > those detected by testing.
> > 
> > Not if the testing is the sort used in bottom-up dynamic incremental
> > development.
> 
> That's perhaps one difference between us: I do mainly
> maintenance and development of small features in an existing
> multi-million lines program whose development started more
> than 15 years ago with complex interactions between the
> components of the program (some inherent to the problem,
> some due to lack of forsightness 10 years ago, some due to
> bad practice...)
> 
> It has a lisp dialect as extension language and one of the
> maintenance problem is that some part has been written in it
> with "bottom-up dynamic incremental development" testing
> only the cases the developper was thinking about and fail
> sometimes horribly when faced to the customer interaction.

The problem here is that this application has tried to hack up some
lame version of half of Lisp, i.e., it is an example of Greenspun's
tenth.  It has nothing to do with the issue at hand.


> I'm sorry, tests check *other things* than type constaints,
> *not* more things.

Not the sort I'm talking about using the techniques described.


> Tests can only proove that something happen, never that it doesn't.

Proving things above the fairly simple level in software falls victim
to the halting problem.  The specifications (even very good ones) are
typically not rigorous enough to _prove_ any conformance either.
There are, of course, exceptions.


I'm not tring to convince anyone to use dynamic typing and languages
here.  I'm just trying to ensure that lurkers and others here are
getting some goofy incorrect view of what they are and how they work.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Jean-Marc Bourguet]

jayessay <nospam@foo.com> writes:

> Jean-Marc Bourguet <jm@bourguet.org> writes:
[...] 
> The problem here is that this application has tried to hack up some
> lame version of half of Lisp, 

The extension language I wrote about was a scheme with some OO
extensions and then others.  Not a full CL but not something I'd call
a "lame version of half of Lisp."

[...]

> > I'm sorry, tests check *other things* than type constaints, *not*
> > more things.
> 
> Not the sort I'm talking about using the techniques described.
> 
> 
> > Tests can only proove that something happen, never that it doesn't.
> 
> Proving things above the fairly simple level in software falls victim
> to the halting problem.

Do you really mean what you wrote.  If so, I'd suggest you to look a
little more to formal proof systems.  That's not because the full
problem can not be solved that no usefull sub-problem can.

Yours,

-- 
Jean-Marc

Re: ADA Popularity Discussion Request

[jayessay]

Jean-Marc Bourguet <jm@bourguet.org> writes:

> jayessay <nospam@foo.com> writes:
> 
> > Jean-Marc Bourguet <jm@bourguet.org> writes:
> [...] 
> > The problem here is that this application has tried to hack up some
> > lame version of half of Lisp, 
> 
> The extension language I wrote about was a scheme with some OO
> extensions and then others.  Not a full CL but not something I'd call
> a "lame version of half of Lisp."

I can't determine this from the above.


> > Proving things above the fairly simple level in software falls victim
> > to the halting problem.
> 
> Do you really mean what you wrote.  If so, I'd suggest you to look a
> little more to formal proof systems.  That's not because the full
> problem can not be solved that no usefull sub-problem can.

Never said that nothing can be proved.  Nor that nothing useful can
be.  FWIW my fomal background is mathematical logic and foundations.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Jean-Marc Bourguet]

jayessay <nospam@foo.com> writes:

> Jean-Marc Bourguet <jm@bourguet.org> writes:
> 
> > jayessay <nospam@foo.com> writes:
> > 
> > > Jean-Marc Bourguet <jm@bourguet.org> writes:
> > [...] 
> > > The problem here is that this application has tried to hack up some
> > > lame version of half of Lisp, 
> > 
> > The extension language I wrote about was a scheme with
> > some OO extensions and then others.  Not a full CL but
> > not something I'd call a "lame version of half of Lisp."
> 
> I can't determine this from the above.

I know that info was not available without doing some hunt
and inference work.  But why did you assume that it was lame
and dismissed my points as not related to the issue at hand?

Do you still think my points are not related to the issue at
hand?  Why?

> > > Proving things above the fairly simple level in
> > > software falls victim to the halting problem.
> > 
> > Do you really mean what you wrote.  If so, I'd suggest
> > you to look a little more to formal proof systems.
> > That's not because the full problem can not be solved
> > that no usefull sub-problem can.
> 
> Never said that nothing can be proved.  Nor that nothing
> useful can be.

Reading the quote above, I understood that nothing not
fairly simple can be proved.  That's not my experience.
Some quite complex invariants can be proved true with static
type checking.  More complex one can be proved by more
powerfull static checker (some of which are able to do type
inference BTW).

Yours,

-- 
Jean-Marc

Re: ADA Popularity Discussion Request

[jayessay]

Jean-Marc Bourguet <jm@bourguet.org> writes:

> jayessay <nospam@foo.com> writes:
> 
> > Jean-Marc Bourguet <jm@bourguet.org> writes:
> > 
> > > jayessay <nospam@foo.com> writes:
> > > 
> > > > Jean-Marc Bourguet <jm@bourguet.org> writes:
> > > [...] 
> > > > The problem here is that this application has tried to hack up some
> > > > lame version of half of Lisp, 
> > > 
> > > The extension language I wrote about was a scheme with
> > > some OO extensions and then others.  Not a full CL but
> > > not something I'd call a "lame version of half of Lisp."
> > 
> > I can't determine this from the above.
> 
> I know that info was not available without doing some hunt
> and inference work.  But why did you assume that it was lame
> and dismissed my points as not related to the issue at hand?
> 
> Do you still think my points are not related to the issue at
> hand?  Why?

The information still suggests that this is indeed a hack on of some
subset of a Lisp into the application.  What is not clear is whether
this was hacked up by the developers of the application or whether
they found something (in the public domain or elsewhere) which was
some partial hack up which they then included.  The former is a
classic Greenspuns's tenth, the latter is a variant.


> > > > Proving things above the fairly simple level in
> > > > software falls victim to the halting problem.
> > > 
> > > Do you really mean what you wrote.  If so, I'd suggest
> > > you to look a little more to formal proof systems.
> > > That's not because the full problem can not be solved
> > > that no usefull sub-problem can.
> > 
> > Never said that nothing can be proved.  Nor that nothing
> > useful can be.
> 
> Reading the quote above, I understood that nothing not
> fairly simple can be proved.  That's not my experience.
> Some quite complex invariants can be proved true with static
> type checking.  More complex one can be proved by more
> powerfull static checker (some of which are able to do type
> inference BTW).

Yes, formal static typists (in the mold of Hindley and Milner and the
type system they independently discovered and which is basically at
the heart of any current implementation of a formal type system) can
indeed prove some useful even interesting things.  What they cannot
prove (except in "fairly simple cases") is anything like program
correctness.  This is largely due to the fact that "correctness" here
is a vague concept.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Jean-Marc Bourguet]

jayessay <nospam@foo.com> writes:

> Jean-Marc Bourguet <jm@bourguet.org> writes:
> 
> > jayessay <nospam@foo.com> writes:
> > 
> > > Jean-Marc Bourguet <jm@bourguet.org> writes:
> > > 
> > > > jayessay <nospam@foo.com> writes:
> > > > 
> > > > > Jean-Marc Bourguet <jm@bourguet.org> writes:
> > > > [...] 
> > > > > The problem here is that this application has tried to hack up some
> > > > > lame version of half of Lisp, 
> > > > 
> > > > The extension language I wrote about was a scheme with
> > > > some OO extensions and then others.  Not a full CL but
> > > > not something I'd call a "lame version of half of Lisp."
> > > 
> > > I can't determine this from the above.
> > 
> > I know that info was not available without doing some hunt
> > and inference work.  But why did you assume that it was lame
> > and dismissed my points as not related to the issue at hand?
> > 
> > Do you still think my points are not related to the issue at
> > hand?  Why?
> 
> The information still suggests that this is indeed a hack
> on of some subset of a Lisp into the application.  What is
> not clear is whether this was hacked up by the developers
> of the application or whether they found something (in the
> public domain or elsewhere) which was some partial hack up
> which they then included.  The former is a classic
> Greenspuns's tenth, the latter is a variant.

Do you think emacs is a case of case of Greenspuns's tenth?
The program I'm speaking about is very similar to emacs in
architecture.  

But the problems I was speaking about could also occur in
any program in CL of comparable size and complexity.  Modify
some middle or low level function and break one of its user
which didn't respect one of its pre-condition in a way which
was harmless with the previous implementation.  

Where is the problem?  In the new code?  It respect the
documented interface.  And testing can only show the problem
in big, slow integration tests.  In the client code?  Well
no testing could show the problem when it was written.
 
> > > > > Proving things above the fairly simple level in
> > > > > software falls victim to the halting problem.
> > > > 
> > > > Do you really mean what you wrote.  If so, I'd suggest
> > > > you to look a little more to formal proof systems.
> > > > That's not because the full problem can not be solved
> > > > that no usefull sub-problem can.
> > > 
> > > Never said that nothing can be proved.  Nor that nothing
> > > useful can be.
> > 
> > Reading the quote above, I understood that nothing not
> > fairly simple can be proved.  That's not my experience.
> > Some quite complex invariants can be proved true with static
> > type checking.  More complex one can be proved by more
> > powerfull static checker (some of which are able to do type
> > inference BTW).
> 
> Yes, formal static typists (in the mold of Hindley and
> Milner and the type system they independently discovered
> and which is basically at the heart of any current
> implementation of a formal type system) can indeed prove
> some useful even interesting things.  What they cannot
> prove (except in "fairly simple cases") is anything like
> program correctness.  This is largely due to the fact that
> "correctness" here is a vague concept.

Agreed, program correctness is too vague.  You can try to
find equivalence with a formal description, but then you
have to proove that that description is correct.  At time it
can be more conveniant but currently it looks to me like
more a niche thing.

Most of the bugs I've to track are due to breaking
invariants.  Especially thoose stated no where invariant or
with a formulation no more in sync with the code.

Those formal systems can proove invariants and using them to
do so would be usefull.  But I know of no mainstream system
with that available.

You can use type system to state and verify invariants.  And
that's something available now.  And it is usefull.

Yours,

-- 
Jean-Marc

Re: ADA Popularity Discussion Request

[jayessay]

Jean-Marc Bourguet <jm@bourguet.org> writes:

> jayessay <nospam@foo.com> writes:
> 
> > Jean-Marc Bourguet <jm@bourguet.org> writes:
> > 
> > > jayessay <nospam@foo.com> writes:
> > > 
> > > > Jean-Marc Bourguet <jm@bourguet.org> writes:
> > > > 
> > > > > jayessay <nospam@foo.com> writes:
> > > > > 
> > > > > > Jean-Marc Bourguet <jm@bourguet.org> writes:
> > > > > [...] 
> > > > > > The problem here is that this application has tried to hack up some
> > > > > > lame version of half of Lisp, 
> > > > > 
> > > > > The extension language I wrote about was a scheme with
> > > > > some OO extensions and then others.  Not a full CL but
> > > > > not something I'd call a "lame version of half of Lisp."
> > > > 
> > > > I can't determine this from the above.
> > > 
> > > I know that info was not available without doing some hunt
> > > and inference work.  But why did you assume that it was lame
> > > and dismissed my points as not related to the issue at hand?
> > > 
> > > Do you still think my points are not related to the issue at
> > > hand?  Why?
> > 
> > The information still suggests that this is indeed a hack
> > on of some subset of a Lisp into the application.  What is
> > not clear is whether this was hacked up by the developers
> > of the application or whether they found something (in the
> > public domain or elsewhere) which was some partial hack up
> > which they then included.  The former is a classic
> > Greenspuns's tenth, the latter is a variant.
> 
> Do you think emacs is a case of case of Greenspuns's tenth?
> The program I'm speaking about is very similar to emacs in
> architecture.

Presumably you mean Elisp.  No it is not, it is just a well known
_broken_ Lisp.


> But the problems I was speaking about could also occur in
> any program in CL of comparable size and complexity.  Modify
> some middle or low level function and break one of its user
> which didn't respect one of its pre-condition in a way which
> was harmless with the previous implementation.

You are making a change to the preconditions so that the new ones are
no longer a subclass of the former.  Therefore all callers will need
to be checked.  Note, the preconditions (the new or the original) may
not even be definable in terms of any type system.


> Where is the problem?  In the new code?  It respect the
> documented interface.  And testing can only show the problem
> in big, slow integration tests.  In the client code?  Well
> no testing could show the problem when it was written.

Or big extremely slow compiles which may not catch this either.  This
sort of problem is beyond language issues (see Ariane 5...)


> > Yes, formal static typists (in the mold of Hindley and
> > Milner and the type system they independently discovered
> > and which is basically at the heart of any current
> > implementation of a formal type system) can indeed prove
> > some useful even interesting things.  What they cannot
> > prove (except in "fairly simple cases") is anything like
> > program correctness.  This is largely due to the fact that
> > "correctness" here is a vague concept.
> 
> Agreed, program correctness is too vague.  You can try to
> find equivalence with a formal description, but then you
> have to proove that that description is correct.

Exactly - and off you go down the rabbit hole.

>  At time it can be more conveniant but currently it looks to me like
> more a niche thing.

I agree.


> Most of the bugs I've to track are due to breaking invariants.
> Especially thoose stated no where invariant or with a formulation no
> more in sync with the code.
> 
> Those formal systems can proove invariants and using them to do so
> would be usefull.  But I know of no mainstream system with that
> available.

I think this is largely due to the fact that these things pretty much
require 1) no side effects 2) no procedural descriptions.  The real
world (tm) OTOH, is largely made up of things that have both of
these...


> You can use type system to state and verify invariants.  And that's
> something available now.  And it is usefull.

No one said it wasn't.  I merely claim that dynamic system can do this
and more.  Obviously you don't believe me.  That's OK.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Jean-Marc Bourguet]

jayessay <nospam@foo.com> writes:

> Jean-Marc Bourguet <jm@bourguet.org> writes:
> > But the problems I was speaking about could also occur in
> > any program in CL of comparable size and complexity.  Modify
> > some middle or low level function and break one of its user
> > which didn't respect one of its pre-condition in a way which
> > was harmless with the previous implementation.
> 
> You are making a change to the preconditions so that the new ones
> are no longer a subclass of the former.  Therefore all callers will
> need to be checked.  

The pre-conditions where documented and I simply started to make use
of one of them.

That's the whole difference between coding to an interface and coding
to an implementation.  Testing doesn't help in the former case.
 
> Note, the preconditions (the new or the original) may not even be
> definable in terms of any type system.

In the case I was thinking about, they where.

[...]

> > You can use type system to state and verify invariants.  And
> > that's something available now.  And it is usefull.
> 
> No one said it wasn't.  I merely claim that dynamic system can do
> this and more.  Obviously you don't believe me.  That's OK.

Testing can show that the problem happen, it can show that the problem
doesn't happen in the tested cases, it can't show that the problem
never happen.  

Yours,

-- 
Jean-Marc

Re: ADA Popularity Discussion Request

[jayessay]

jayessay <nospam@foo.com> writes:

> I'm not tring to convince anyone to use dynamic typing and languages
> here.  I'm just trying to ensure that lurkers and others here are

NOT

> getting some goofy incorrect view of what they are and how they work.

More brain farts...

/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Björn Persson]

jayessay wrote:

> I'm not tring to convince anyone to use dynamic typing and languages
> here.  I'm just trying to ensure that lurkers and others here are not
> getting some goofy incorrect view of what they are and how they work.

Lurking in this thread I note once again that zealots occur not only in 
the Ada camp, because this Jayessay guy is obviously a Lisp zealot who's 
firmly convinced that anything that isn't Common Lisp is broken.

But I suspect that that isn't quite the view you're trying to ensure 
that I get.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: ADA Popularity Discussion Request

[jayessay]

Bj�rn Persson <spam-away@nowhere.nil> writes:

> jayessay wrote:
> 
> > I'm not tring to convince anyone to use dynamic typing and languages
> > here.  I'm just trying to ensure that lurkers and others here are not
> > getting some goofy incorrect view of what they are and how they work.
> 
> Lurking in this thread I note once again that zealots occur not only
> in the Ada camp, because this Jayessay guy is obviously a Lisp zealot
> who's firmly convinced that anything that isn't Common Lisp is broken.

No, Common Lisp is broken as well...


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Randy Brukardt]

"jayessay" <nospam@foo.com> wrote in message
news:m3brgidrzb.fsf@rigel.goldenthreadtech.com...
...
> Proving things above the fairly simple level in software falls victim
> to the halting problem.  The specifications (even very good ones) are
> typically not rigorous enough to _prove_ any conformance either.
> There are, of course, exceptions.

The SPARK people claim to have had good luck in proving Ada software doesn't
have run-time errors and meets its specifications. See www.sparkada.com.

I'd expect that writing the specifications would be interesting. But it
would at least seem a useful technique to eliminate errors in smaller
subprograms, so that testing can be focused on the whole system (where you
have a much better chance of doing it in a reproducible fashion). After all,
creating good reusable tests is expensive, no matter what they're testing
(and non-reusable tests are close to worthless).

                                       Randy.

Re: ADA Popularity Discussion Request

[Jeffrey Carter]

Kevin Cline wrote:

> I've come to the same conclusion.  Once you decide to test code before
> you write it, strong typing loses most of it's value.  On the other
> hand, if I'm working on code without a good set of automated tests,
> then strong typing is a very nice thing to have.

For software of typical complexity, testing sufficient to prove the 
absence of errors takes longer than the allowable schedule for any 
project I've ever worked on. Testing in the real world cannot be counted 
on to find all errors.

Since testing cannot be counted on to catch all errors, anything else 
that finds errors may catch errors that testing will miss. There is a 
synergy between the Ada features that find errors during compilation (of 
which strong typing is only one) and testing.

It is a documented fact that errors cost less to fix the earlier they 
are found, so errors found during compilation save money compared to 
those found during testing.

The cost of fixing an error is proportional to the time spent making the 
correction, so errors found during compilation take less time to fix 
than those found during testing. If time to market is a concern, using a 
language that finds more errors during compilation will decrease the 
time to deployment.

The facts do not support a claim that testing is as time or cost 
efficient as detecting errors during compilation.

-- 
Jeff Carter
"To Err is human, to really screw up, you need C++!"
St�phane Richard
63

Re: ADA Popularity Discussion Request

[stephane richard]

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


"Jeffrey Carter" <spam@spam.com> wrote in message 
news:u8L_c.8238$w%6.5607@newsread1.news.pas.earthlink.net...
> -- 
> Jeff Carter
> "To Err is human, to really screw up, you need C++!"
> St�phane Richard
> 63
>

I see my quote is going places ;-).

St�phane Richard
"Ada World" webmaster
http://www.adaworld.com

Re: ADA Popularity Discussion Request

[jayessay]

kevin.cline@gmail.com (Kevin Cline) writes:

> jayessay wrote
> > "Richard  Riehle" <adaworks@earthlink.net> writes:
> > 
> > Also, logic errors (what most
> > people would consider significantly more negative) are far rarer.
> > 
> > There turn out to be various reasons for this, but two worth
> > mentioning are the sort of bottom up style of programming as described
> > by Paul Graham (a kind of agile/extreme programming) and the ability
> > to move Lisp to the expressive level of the application domain.
> > 
> > In any application/system of any significance these two go hand in
> > hand.  The second is achieved by crafting a constrained narrowly
> > focused domain specific language _within_ Lisp, which allows the
> > programmer to then work at the level of the domain, _both_
> > syntactically as well as semantically.  This is why Lisp macros
> > (please don't confuse with any other kind of macro you've come across
> > before) are such a big deal.
> > 
> > Now, admittedly, creating these is not something your typical code
> > monkey is going to grok.  This is one of the big reasons why Lisp will
> > never be as "popular" as something like Java.  But then your typical
> > code monkey isn't going to be building your core internal application
> > api either.  Once you've built this though, even a code monkey will be
> > a lot more productive and produce much more clean and robust code.
> > 
> > > For example, a Common Lisp programmer rarely agnonizes over such
> > > silliness as constructors, copy constructors, overloading assignment
> > > operators, friends, and all the hideous little details that
> > > characterize so much of C++ programming.
> 
> I'm skeptical.  In any language, data structures will require
> initialization to reach the empty state.

Just to be clear, I didn't say that last bit, Richard Riehle did.  But
you've mixed it in with my comments so it is unclear of what you are
skeptical - everything quoted above or just the R.R. bit.

It's also worth noting that if you substituted "Ada" for "C++" there
would not be a substantive change to the bit.

Anyway, other than "constructors" none of the stuff in R.R.'s quote is
remotely the concern of a developer using Common Lisp.


> You still have to write the code, it just has a different name.
> Instead of MyThing(int mobys, ...) you have (defun
> make-my-thing(mobys ...).

Strictly speaking, this is usually simply not true.  The normal case
by far is one where this code is generated for you from a
specification and it is sufficient.  There are cases where this will
need to be overridden or otherwise enhanced, but those are "outlying"
cases.


>  Instead of a copy constructor, you have (defun
> clone-my-thing(thing) ...).

This sort of thing is _extremely_ rare, because you don't use or need
"copy" semantics.  You just do _not_ make copies of things unless
there is some _domain_ level reason for it.  [Aside: fyi, in such
cases where this makes sense it is _much_ more likely that you'd be
using defmethod for this sort of thing].


> And if you open files or lock mutexes or consume any other limited
> resource, you are going to have to ensure they are released by
> writing the equivalent of a destructor.

Macros eliminate this sort of "boiler plate" code.  These are nothing
at all like a destructor.  Most other uses of "destructors" typically
revolve around "memory management" which obviously is pretty
irrelevant in Common Lisp.


A typical example here would be with-open-file.  You simply do not
need to be concerned with the maintenance of the file/os resource,
etc.  It is handled for you and guranteed to be cleaned up when
leaving scope whether by normal or exceptional flow.

Same with locks:

;;; Serialize access, lock for update, guarantee unlock on exception,
;;; and unlock/commit on success
;;;
(with-protected-resource (get-database :medline-journals)
  (foo it)
  (bar it))



> When done well, C++ programming does not get mired in hideous little
> details.  But like most programming, it is rarely done well.  And the
> more popular a language, the lower the performance of the average
> practitioner.  Lots of people learned C++ and Java because that's what
> the market demanded.  So there is lots of horrible C++ code and Java
> code.

Mostly agree with this (though C++ does force you to deal with a lot
of extraneous grime).


> People learn LISP because they love programming.  Not all LISP
> programmers are geniuses, but almost all are well above the mean.

I think you are basically correct in this also.  BTW, "LISP" is
basically never used anymore except by some as a shorthand for "a
Lisp" or "Lisp like language", i.e., as a term for a certain class of
languages.


> ...
> > 1. Which from experience would typically be in the range of 250K-500K
> > lines of equivalent Ada/C++/Eiffel/etc.  An order of magnitude is not
> > hyperbole here even though most uninitiated developers will raise
> > their eyebrows or roll their eyes. 
> 
> This I know to be true, although again it's not fair to compare the
> C++ code from an average programmer to the LISP code from an expert.
> An expert C++ programmer can reduce the line count of typical code
> by 60% or more.  

I'm instantiating "LISP" here with Common Lisp.  I'm not talking about
code monkey C++/Ada/Eiffel vs Guru Lisp.  The mentioned one to two
orders of magnitude of typical gain holds for expert code vs expert
code.


> In either language, experts will refactor until a new
> domain-specific language appears.

I agree that experts will refactor no matter what.  However, there is
no way to create a domain specific _language_ _within_
C++/Ada/Eiffel/etc.

I'm talking about where the the syntax as well as the semantics is
just as transparently and cleanly integrated in the language as any
core aspect.  Where there is no bolt on interpreter needed, no hacking
away trying to kludge up something with yacc/lex types of tools.  And
where the result supports the expression of the application code
naturally and cleanly in the terms and processes of the target domain.

You just can't do this with things like C++/Ada/Eiffel/etc.  You can't
even do this with stuff like Smalltalk, Python, or even Dylan.

The key to this was succinctly captured by John Foderaro: "Lisp is a
programmable programming language".


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On 06 Sep 2004 17:12:54 -0400, jayessay wrote:

>> And if you open files or lock mutexes or consume any other limited
>> resource, you are going to have to ensure they are released by
>> writing the equivalent of a destructor.
> 
> Macros eliminate this sort of "boiler plate" code.  These are nothing
> at all like a destructor.  Most other uses of "destructors" typically
> revolve around "memory management" which obviously is pretty
> irrelevant in Common Lisp.
> 
> A typical example here would be with-open-file.  You simply do not
> need to be concerned with the maintenance of the file/os resource,
> etc.  It is handled for you and guranteed to be cleaned up when
> leaving scope whether by normal or exceptional flow.
> 
> Same with locks:
> 
> ;;; Serialize access, lock for update, guarantee unlock on exception,
> ;;; and unlock/commit on success
> ;;;
> (with-protected-resource (get-database :medline-journals)
>   (foo it)
>   (bar it))

That's because LISP is not truly dynamic. In a really dynamic language the
scopes should be regarded as superfluous as type information, they just
bind programmer's fantasy and creativity. Bad enough, the nasty compiler
might guess your intention (to lock something). What is worse is that the
code maintainer could do it too! Garbage collectors solve this. My favorite
language is MS-DOS: format C: /q solves everything.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ADA Popularity Discussion Request

[jayessay]

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

> On 06 Sep 2004 17:12:54 -0400, jayessay wrote:
> 
> >> And if you open files or lock mutexes or consume any other limited
> >> resource, you are going to have to ensure they are released by
> >> writing the equivalent of a destructor.
> > 
> > Macros eliminate this sort of "boiler plate" code.  These are nothing
> > at all like a destructor.  Most other uses of "destructors" typically
> > revolve around "memory management" which obviously is pretty
> > irrelevant in Common Lisp.
> > 
> > A typical example here would be with-open-file.  You simply do not
> > need to be concerned with the maintenance of the file/os resource,
> > etc.  It is handled for you and guranteed to be cleaned up when
> > leaving scope whether by normal or exceptional flow.
> > 
> > Same with locks:
> > 
> > ;;; Serialize access, lock for update, guarantee unlock on exception,
> > ;;; and unlock/commit on success
> > ;;;
> > (with-protected-resource (get-database :medline-journals)
> >   (foo it)
> >   (bar it))
> 
> That's because LISP is not truly dynamic. In a really dynamic language the
> scopes should be regarded as superfluous as type information, they just
> bind programmer's fantasy and creativity. Bad enough, the nasty compiler
> might guess your intention (to lock something). What is worse is that the
> code maintainer could do it too! Garbage collectors solve this. My favorite
> language is MS-DOS: format C: /q solves everything.

Whatever floats your boat, bro...


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Larry Kilgallen]

In article <iWG_c.8033$w%6.3982@newsread1.news.pas.earthlink.net>, "Richard  Riehle" <adaworks@earthlink.net> writes:

> No one argues that testing is unimportant.

> No language can protect us, at compile time, from every possible
> error.

But assuming perfect testing, finding the errors during compilation
rather than in testing saves me time, and time is money.

Re: ADA Popularity Discussion Request

[Kevin Cline]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<vpblkhspuA9F@eisner.encompasserve.org>...
> In article <iWG_c.8033$w%6.3982@newsread1.news.pas.earthlink.net>, "Richard  Riehle" <adaworks@earthlink.net> writes:
> 
> > No one argues that testing is unimportant.
>  
> > No language can protect us, at compile time, from every possible
> > error.
> 
> But assuming perfect testing, finding the errors during compilation
> rather than in testing saves me time, and time is money.

I thought so too, until I tried incremental test-first development. 
Retesting a unit after adding a few lines of code means that type
mismatches are caught immediately with or without strong typing.  But
it goes faster if you don't have to compile and link every iteration.

Re: ADA Popularity Discussion Request

[jayessay]

kevin.cline@gmail.com (Kevin Cline) writes:

> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message
> > "Richard  Riehle" <adaworks@earthlink.net> writes:
> > 
> > > No one argues that testing is unimportant.
> >  
> > > No language can protect us, at compile time, from every possible
> > > error.
> > 
> > But assuming perfect testing, finding the errors during compilation
> > rather than in testing saves me time, and time is money.
> 
> I thought so too, until I tried incremental test-first development. 
> Retesting a unit after adding a few lines of code means that type
> mismatches are caught immediately with or without strong typing.  But
> it goes faster if you don't have to compile and link every iteration.

Exactly.  Actually this sort of development will save you much more
time and money than you could ever hope for from typical static typing.

/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Lionel Draghi]

jayessay wrote:
...
> Exactly.  Actually this sort of development will save you much more
> time and money than you could ever hope for from typical static typing.

How could this be?
With powerful typing you write code.
Without, you write as much code and much more tests.

Let's compare:

A :
function Random_Index return Integer;
-- return's a value between 1 and 10

B :
type Index is range 1 .. 10;
function Random_Index return Index;

If considering code and comments, both are of the same length.
On the other hand, in the A version, I need to check the return value on 
each call.
Moreover, if the B Random_Index try to return 11, it will raise 
Constraint_Error, whatever is the test.
If the A version try to return 11 it may be in some other test where you 
din't check Ramdom_Index result, and you may not notice it.

So, not only strong typing save you time and money, but it just do a 
better job (not to mention possible compiler optimization and preventing 
the discrepancy risk between comments and code).

PS : actually the difference may be even bigger : static code analysis 
tool may prove that B is correct, in which case you don't even need to 
test it, and not beeing able to do the same with A because of the 
missing semantic.

-- 
Lionel Draghi

Re: ADA Popularity Discussion Request

[Ole-Hjalmar Kristensen]

>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:

    LD> jayessay wrote:
    LD> ...
    >> Exactly.  Actually this sort of development will save you much more
    >> time and money than you could ever hope for from typical static typing.

    LD> How could this be?
    LD> With powerful typing you write code.
    LD> Without, you write as much code and much more tests.

You are missing the point. He is not arguing against strong typing,
but against *static* typing.

<snip>

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote:
:>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:
: 
:    LD> jayessay wrote:
:    LD> ...
:    >> Exactly.  Actually this sort of development will save you much more
:    >> time and money than you could ever hope for from typical static typing.
: 
:    LD> How could this be?
:    LD> With powerful typing you write code.
:    LD> Without, you write as much code and much more tests.
: 
: You are missing the point. He is not arguing against strong typing,
: but against *static* typing.

I don't think so. For type checking to become effective with strong
but dynamic checking, the program (or expression) will have to be run.

-- Georg

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On 08 Sep 2004 10:52:05 +0200, Ole-Hjalmar Kristensen wrote:

>>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:
> 
>     LD> jayessay wrote:
>     LD> ...
>     >> Exactly.  Actually this sort of development will save you much more
>     >> time and money than you could ever hope for from typical static typing.
> 
>     LD> How could this be?
>     LD> With powerful typing you write code.
>     LD> Without, you write as much code and much more tests.
> 
> You are missing the point. He is not arguing against strong typing,
> but against *static* typing.

Apparently, but when consistently pursued that kind of argumentation
inevitable leads to arguing against any typing, especially against ADT. The
philosophy behind is that types are random artifacts of the program, rather
than the basis of software design. When the program is not thought in terms
of types, there is nothing to check, either statically or dynamically.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ADA Popularity Discussion Request

[jayessay]

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

> On 08 Sep 2004 10:52:05 +0200, Ole-Hjalmar Kristensen wrote:
> 
> >>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:
> > 
> >     LD> jayessay wrote:
> >     LD> ...
> >  >> Exactly.  Actually this sort of development will save you much more
> >  >> time and money than you could ever hope for from typical static typing.
> > 
> >     LD> How could this be?
> >     LD> With powerful typing you write code.
> >     LD> Without, you write as much code and much more tests.
> > 
> > You are missing the point. He is not arguing against strong typing,
> > but against *static* typing.

You, Ole, are on target.

Dmitry, you need some misconceptions cleared up.


> Apparently, but when consistently pursued that kind of argumentation
> inevitable leads to arguing against any typing, especially against
> ADT. 

No, it does not.  This is simply and clearly incorrect.


> The philosophy behind is that types are random artifacts of the
> program,

No, this is also incorrect.  The real difference is that with dynamic
typing _values_ have types _not_ variables.  Since _variables_ don't
even exist at runtime, your type information is largely gone at
runtime in static systems.  In dynamically typed system you can never
have something like Unchecked_Conversion, because the type information
is actually with the value at all times.  You can convert, but this
always creates a _new_ value.


> rather than the basis of software design. When the program
> is not thought in terms of types, there is nothing to check, either
> statically or dynamically.

This is wrong on two counts:

First, types are indeed part of program design in dynamic languages.
In some respects they are even more important than in static languages
as they exist at _all_ times: compile load (link) and run.  They are
_always_ checked _all_ the time.  If you want to say "Ooo!  this has a
performance hit", fine, but with current systems any such checks are
basically in the noise.  OTOH, you can annotate a dynamic program with
static type information and/or use type inference to remove this issue
from most cases.

Second, types are _not_ the only thing to check in a program.  There
are many aspects that are not and even cannot be described by types.
This should be obvious or else you would never have the need to ever
write any functions/procedures.  Checking the correctness of
algorithms is every bit as important as type consistency.  I'm pretty
sure that you (anyone) will agree with this once brought to your
attention.


I read this newsgroup mostly as a lurker these days.  I used to be a
static typist, advocated it and thought Ada was a pretty good informal
type system.

I'm not arguing that anyone here should stop using Ada (or C++ or
Haskell or whatever static language floats your boat).  I'm simply
trying to correct a lot of misinformation here about (Common) Lisp,
"extreme/agile/incremental" development, and dynamically typed
languages in general.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On 08 Sep 2004 12:26:54 -0400, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> The philosophy behind is that types are random artifacts of the
>> program,
> 
> No, this is also incorrect.  The real difference is that with dynamic
> typing _values_ have types _not_ variables.  Since _variables_ don't
> even exist at runtime, your type information is largely gone at
> runtime in static systems.

I suppose you are talking about polymorphic objects. They still have *a*
type. It is what Ada calls "class". So what is your point:

1. That statically typed languages cannot express polymorphism? This is
plainly wrong.

2. That all polymorphic values should be considered of same type ANY? This
is also wrong.

> In dynamically typed system you can never
> have something like Unchecked_Conversion, because the type information
> is actually with the value at all times.  You can convert, but this
> always creates a _new_ value.

As Unchecked_Conversion does.

And I still do not see your point. You have accepted that types exist. So
you are talking about type information, excellent. Where is then any
difference between static and dynamic typing? There is *no* one. From this
perspective, dynamically typed systems are subset of statical ones. This is
important to understand. This is also the reason why "truly dynamic" people
sooner or later start to argue against types. Because, take a static
language, derive everything from same base, and you will have the case,
where the type information would be as useless (at compile time) as in a
dynamically typed language. Static typing does not make type information
unavailable. It makes it in some cases a-priory known.

Note that to argue against type is not a crime. On the contrary, it is
interesting to speculate whether an alternative approach to our view on
software design were possible. The only problem is that modern dynamically
typed languages do not offer that alternative. They are still typed, badly
typed, if you want. (:-))

>> rather than the basis of software design. When the program
>> is not thought in terms of types, there is nothing to check, either
>> statically or dynamically.
> 
> This is wrong on two counts:
> 
> First, types are indeed part of program design in dynamic languages.
> In some respects they are even more important than in static languages
> as they exist at _all_ times: compile load (link) and run.  They are
> _always_ checked _all_ the time.  If you want to say "Ooo!  this has a
> performance hit", fine, but with current systems any such checks are
> basically in the noise.  OTOH, you can annotate a dynamic program with
> static type information and/or use type inference to remove this issue
> from most cases.

Fine, types exist. Then you also have to accept that types need to be
documented in some way. The next step is that the documentation language
should be a part of the programming language. And the final step, if that
is a part of the language, why the compiler should be prevented from
checking where it can?

Again, having accepted types you cannot argue that to check them earlier is
worse than to check them later. You can only say that static checks, when
imposed, would limit you in using this and that *concrete* programming
pattern. And anyway, there are others very useful patterns nicely working
with static checks. So what is the point?

> Second, types are _not_ the only thing to check in a program.  There
> are many aspects that are not and even cannot be described by types.
> This should be obvious or else you would never have the need to ever
> write any functions/procedures.  Checking the correctness of
> algorithms is every bit as important as type consistency.  I'm pretty
> sure that you (anyone) will agree with this once brought to your
> attention.

Yes. Under nothing to check I meant types. But you are not proposing to get
rid of them...

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ADA Popularity Discussion Request

[Björn Persson]

Dmitry A. Kazakov wrote:

> From this
> perspective, dynamically typed systems are subset of statical ones. This is
> important to understand. This is also the reason why "truly dynamic" people
> sooner or later start to argue against types. Because, take a static
> language, derive everything from same base, and you will have the case,
> where the type information would be as useless (at compile time) as in a
> dynamically typed language. Static typing does not make type information
> unavailable. It makes it in some cases a-priory known.

That's an interesting point. In Java, all classes are derived from 
Object. Yet I find type information useful in Java. But if all 
parameters of all methods were declared as Object, then it would start 
to look like a dynamically typed language.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: ADA Popularity Discussion Request

[jayessay]

Bj�rn Persson <spam-away@nowhere.nil> writes:

> Dmitry A. Kazakov wrote:
> 
> > From this
> > perspective, dynamically typed systems are subset of statical ones.

No.  You are confusing dynamically typed with _UN_typed.

> > This is
> > important to understand. This is also the reason why "truly dynamic" people
> > sooner or later start to argue against types.

None that I know.  If you look at what "truly dynamic" people are
saying over on c.l.l, c.l.python, c.l.smalltalk, etc. you would know
just how wrong you are.


> > Because, take a static
> > language, derive everything from same base, and you will have the case,
> > where the type information would be as useless (at compile time) as in a
> > dynamically typed language. Static typing does not make type information
> > unavailable. It makes it in some cases a-priory known.
> 
> That's an interesting point. In Java, all classes are derived from
> Object. Yet I find type information useful in Java. But if all
> parameters of all methods were declared as Object, then it would start
> to look like a dynamically typed language.

Egads, no!  It would begin to look _UN_typed!  Please try to get a
grip on this.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Björn Persson]

jayessay wrote:

> Björn Persson <spam-away@nowhere.nil> writes:
> 
>>Dmitry A. Kazakov wrote:
>>
>>>Because, take a static
>>>language, derive everything from same base, and you will have the case,
>>>where the type information would be as useless (at compile time) as in a
>>>dynamically typed language. Static typing does not make type information
>>>unavailable. It makes it in some cases a-priory known.
>>
>>That's an interesting point. In Java, all classes are derived from
>>Object. Yet I find type information useful in Java. But if all
>>parameters of all methods were declared as Object, then it would start
>>to look like a dynamically typed language.
> 
> Egads, no!  It would begin to look _UN_typed!  Please try to get a
> grip on this.

class Superclass {
   Object One;
}

class Subclass extends Superclass {
   Object Two;
}

class Other_Class {}

class Proof {

   void A_Method(Object Thing) {
     System.out.println("This object's type is \""
                        + Thing.getClass().getName() +"\".");
     System.out.println("Accessing \"One\".");
     ((Superclass)Thing).One = new Other_Class();
     if(Thing instanceof Subclass) {
       System.out.println("Accessing \"Two\".");
       ((Subclass)Thing).Two = new Other_Class();
     }
   }

   public static void main(String[] Param) {
     Object Super = new Superclass();
     Object Sub   = new Subclass();
     Object Other = new Other_Class();
     Object Demo  = new Proof();

     ((Proof)Demo).A_Method(Super);
     ((Proof)Demo).A_Method(Sub);
     ((Proof)Demo).A_Method(Other);
   }

}

$ javac Proof.java
$ java Proof
This object's type is "Superclass".
Accessing "One".
This object's type is "Subclass".
Accessing "One".
Accessing "Two".
This object's type is "Other_Class".
Accessing "One".
Exception in thread "main" java.lang.ClassCastException
         at Proof.A_Method(Proof.java:7)
         at Proof.main(Proof.java:22)


Note how everything is declared as Object. Note how the type of each 
object can still be determined. Note how Java refuses to turn an 
Other_Class object into a Superclass object. Do you consider this 
untyped? If so, please state exactly how you define "untyped", so we can 
start speaking the same language.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: ADA Popularity Discussion Request

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> Where is then any
> difference between static and dynamic typing? There is *no* one. From this
> perspective, dynamically typed systems are subset of statical ones.
Just as any manifold (from differential topology) - like sphere... or even
better - like Klein's bottle - is a subset (sub-manifold) of Euclidean space
of higher dimension (this isn't too obvious, but Whitney theorem stands for
this). But topologists very often are considering manifolds without immersing
them into appropriate Euclidean space - and they do that for good reasons.

Yes, you always can consider dynamically typed system as a subsystem of some
statically typed system, but the latter generally will be substantially
heavier (in terms of precise description, full understanding and resources
needed for its maintenance).





Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: ADA Popularity Discussion Request

[jayessay]

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

> On 08 Sep 2004 12:26:54 -0400, jayessay wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> > 
> >> The philosophy behind is that types are random artifacts of the
> >> program,
> > 
> > No, this is also incorrect.  The real difference is that with dynamic
> > typing _values_ have types _not_ variables.  Since _variables_ don't
> > even exist at runtime, your type information is largely gone at
> > runtime in static systems.
> 
> I suppose you are talking about polymorphic objects.

No, I'm not.  Simply put variable don't exist at runtime.  I'm talking
about every value having its type with it.


> 1. That statically typed languages cannot express polymorphism? This is
> plainly wrong.

This is irrelevant as again, the type information is basically gone.
You have certain limited RTTI abilities, but that is not the same.


> 2. That all polymorphic values should be considered of same type ANY? This
> is also wrong.

No, this is irrelevant.


> As Unchecked_Conversion does.

I guess i've forgotten this (never really used it much).  So, when
13.9(5) says an instance of this returns a value whose "representation
is the same as that of the source, how is that functionally different
from a cast?  I realize that can make a differnce at compile time, but
where's the runtime difference?  Especially as there's no type at
runtime.


> is a part of the language, why the compiler should be prevented from
> checking where it can?

It's _not_ prevented - it isn't _required_ to!


> Again, having accepted types you cannot argue that to check them earlier is
> worse than to check them later.

If you think I'm arguing that, you really haven't understood.  I'm not
saying checking them "earlier" is somehow bad, I'm saying it is
largely irrelevant in practice with dynamic typing because any type
inconsistency is caught during development anyway!


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On 08 Sep 2004 19:23:40 -0400, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 08 Sep 2004 12:26:54 -0400, jayessay wrote:
>> 
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> The philosophy behind is that types are random artifacts of the
>>>> program,
>>> 
>>> No, this is also incorrect.  The real difference is that with dynamic
>>> typing _values_ have types _not_ variables.  Since _variables_ don't
>>> even exist at runtime, your type information is largely gone at
>>> runtime in static systems.
>> 
>> I suppose you are talking about polymorphic objects.
> 
> No, I'm not.  Simply put variable don't exist at runtime.  I'm talking
> about every value having its type with it.

But that's exactly what a [dynamically] polymorphic object is. Its value (a
class-wide value in Ada terms) carries the type tag with it. The type tag
determines the specific type. Note that this specific type is not the type
of the object. T and T'Class are different types in Ada. Note also that
there is still room for static checks here. Toy'Class and Gun'Class are
statically different types. So Baby.Take (Gun) will be a compile error.

>> 1. That statically typed languages cannot express polymorphism? This is
>> plainly wrong.
> 
> This is irrelevant as again, the type information is basically gone.
> You have certain limited RTTI abilities, but that is not the same.

Should it mean that dynamic polymorphism is not powerful enough for the
tasks ...., which ones? Note that nobody says that ADT theory in its
present state is complete. So to argue against its concrete implementations
in concrete statically typed languages would be rather wasting time.
Because everybody will agree that there are [many] problems. So your
argument should go beyond that. Namely: no static analysis of types in any
its form can be fundamentally useful. Here we go again....

>> 2. That all polymorphic values should be considered of same type ANY? This
>> is also wrong.
> 
> No, this is irrelevant.

Really? But then if you have different bases like Toy and Gun, you can use
this type information to *statically* ensure that no type of guns can be
ever given to a child. 

>> As Unchecked_Conversion does.
> 
> I guess i've forgotten this (never really used it much).  So, when
> 13.9(5) says an instance of this returns a value whose "representation
> is the same as that of the source,

ARM then continues to the list of conditions to be satisfied to make the
above true.

In other cases the result might be quite different. For example when you
convert between a general access and pool specific access types. Former are
probably fat pointers, latter could be tiny integers, depending on the
compiler, of course.

> how is that functionally different from a cast?

It is a cast.

>  I realize that can make a differnce at compile time, but
> where's the runtime difference?  Especially as there's no type at
> runtime.

How so? Types do exist at run-time. Consider it as if the *unused* type
information were optimized out.

>> is a part of the language, why the compiler should be prevented from
>> checking where it can?
> 
> It's _not_ prevented - it isn't _required_ to!

That's silly. Why not to require to check what could be checked? Compare
with your beloved tests. You can test, but not required to. Any difference?
No one, except that types as a concept have reached the level of formality
where they can be integrated into the language to support static analysis.
Which only means that the tests related to types and their relationships
are performed by the compiler. Pre- and post-conditions is another example
of tests which can be partially automated. The rest, TDD etc has not
reached that level. It is no more than a mere informal advise of good
programming practice. As such it by no means can supersede static analysis.

>> Again, having accepted types you cannot argue that to check them earlier is
>> worse than to check them later.
> 
> If you think I'm arguing that, you really haven't understood.  I'm not
> saying checking them "earlier" is somehow bad, I'm saying it is
> largely irrelevant in practice with dynamic typing because any type
> inconsistency is caught during development anyway!

"Any type inconsistency caught anyway" is either too strong to be true or
else it just means that there are no interesting types to check for
consistency. The latter returns us back to the starting point. Are you
using types in your software design?

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ADA Popularity Discussion Request

[jayessay]

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

> On 08 Sep 2004 19:23:40 -0400, jayessay wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> > 
> >> On 08 Sep 2004 12:26:54 -0400, jayessay wrote:
> >> 
> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> >>> 
> >>>> The philosophy behind is that types are random artifacts of the
> >>>> program,
> >>> 
> >>> No, this is also incorrect.  The real difference is that with dynamic
> >>> typing _values_ have types _not_ variables.  Since _variables_ don't
> >>> even exist at runtime, your type information is largely gone at
> >>> runtime in static systems.
> >> 
> >> I suppose you are talking about polymorphic objects.
> > 
> > No, I'm not.  Simply put variable don't exist at runtime.  I'm talking
> > about every value having its type with it.
> 
> But that's exactly what a [dynamically] polymorphic object is.

No, this is just wrong.


> >> 2. That all polymorphic values should be considered of same type ANY? This
> >> is also wrong.
> > 
> > No, this is irrelevant.
> 
> Really?

Yes, really.

> >> As Unchecked_Conversion does.
> > 
> > I guess i've forgotten this (never really used it much).  So, when
> > 13.9(5) says an instance of this returns a value whose "representation
> > is the same as that of the source,
> 
> ARM then continues to the list of conditions to be satisfied to make the
> above true.
> 
> In other cases the result might be quite different. For example when you
> convert between a general access and pool specific access types. Former are
> probably fat pointers, latter could be tiny integers, depending on the
> compiler, of course.
> 
> > how is that functionally different from a cast?
> 
> It is a cast.

You're contradicting your own explanation.  By your own comments above
it is (at least sometimes) _not_ a cast.


> How so? Types do exist at run-time. Consider it as if the *unused* type
> information were optimized out.

No they do not.  If they did you could create them, query them, change
them, assign them to variables, etc.  Now, you and I both know you
can't do any of this with Ada types at runtime.


> > It's _not_ prevented - it isn't _required_ to!
> 
> That's silly. Why not to require to check what could be checked?

Because it breaks many things in dynamic systems, that's why.  Sorry,
but it is your comment that is "silly", not the dynamic type system.


> > If you think I'm arguing that, you really haven't understood.  I'm not
> > saying checking them "earlier" is somehow bad, I'm saying it is
> > largely irrelevant in practice with dynamic typing because any type
> > inconsistency is caught during development anyway!
> 
> "Any type inconsistency caught anyway" is either too strong to be true or
> else it just means that there are no interesting types to check for
> consistency.

You are just plain wrong, but if you have some vested interest in
believing that, fine.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On 09 Sep 2004 21:16:24 -0400, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 08 Sep 2004 19:23:40 -0400, jayessay wrote:
>> 
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> On 08 Sep 2004 12:26:54 -0400, jayessay wrote:
>>>>
>>> No, I'm not.  Simply put variable don't exist at runtime.  I'm talking
>>> about every value having its type with it.
>> 
>> But that's exactly what a [dynamically] polymorphic object is.
> 
> No, this is just wrong.

ARM 3.9(3) reads:

"An object of a tagged type has an associated (run-time) tag that
identifies the specific tagged type used to create the object originally.
The tag of an operand of a class-wide tagged type TοΏ½Class controls which
subprogram body is to be executed when a primitive subprogram of type T is
applied to the operand (see 3.9.2); using a tag to control which body to
execute is called dispatching."

>>>> As Unchecked_Conversion does.
>>> 
>>> I guess i've forgotten this (never really used it much).  So, when
>>> 13.9(5) says an instance of this returns a value whose "representation
>>> is the same as that of the source,
>> 
>> ARM then continues to the list of conditions to be satisfied to make the
>> above true.
>> 
>> In other cases the result might be quite different. For example when you
>> convert between a general access and pool specific access types. Former are
>> probably fat pointers, latter could be tiny integers, depending on the
>> compiler, of course.
>> 
>>> how is that functionally different from a cast?
>> 
>> It is a cast.
> 
> You're contradicting your own explanation.  By your own comments above
> it is (at least sometimes) _not_ a cast.

It depends on what you understand under "cast". Anyway, what should prove
[in-]existence of casts?

>> How so? Types do exist at run-time. Consider it as if the *unused* type
>> information were optimized out.
> 
> No they do not.

This is plainly wrong. Statically known information remains known at run
time. This is what the word "static" means.

> If they did you could create them, query them, change
> them, assign them to variables, etc.

This has nothing to do with the issue, but also wrong.

> Now, you and I both know you
> can't do any of this with Ada types at runtime.

Again wrong:

1. Dynamic type creation in Ada:

procedure Foo (First, Last : Integer) is
   type Dynamic_Array is array (Integer range First..Last) of Integer;
begin
   ...
end Foo;

2. Type querying in Ada:

procedure Baz (Object : X'Class) is
begin
   Put_Line ("My type is:" & External_Tag (Object'Tag));
end Baz;

3. Changing types in Ada.

Types can be dynamically constrained in Ada. AFAIK, types will be
dynamically extensible in the coming release of Ada standard.

4. Type variables. True, Ada does not have types as the first-class
objects. So you cannot put type in a variable. For this one should have
types types.

>>> It's _not_ prevented - it isn't _required_ to!
>> 
>> That's silly. Why not to require to check what could be checked?
> 
> Because it breaks many things in dynamic systems, that's why.

It breaks nothing, re-read it carefully: "to check what *could* be
checked". Nobody claims that *all* types have to be checked statically.
This would exclude dynamic polymorphism. Again, why not to check what can
be checked?

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

Re: ADA Popularity Discussion Request

[Lionel Draghi]

jayessay wrote:
...
> First, types are indeed part of program design in dynamic languages.
> In some respects they are even more important than in static languages
> as they exist at _all_ times: compile load (link) and run.  They are
> _always_ checked _all_ the time.  If you want to say "Ooo!  this has a
> performance hit", fine, but with current systems any such checks are
> basically in the noise.  OTOH, you can annotate a dynamic program with
> static type information and/or use type inference to remove this issue
> from most cases.

Jon,

I am trying my best to understand you without knowing Lisp, but I don't. 
This is the second time you explain this, but you are to abstract for me.
My point is that with static typing, most type related problems are 
caught at compil time, before any execution.
Know, you say here that it is possible to write annotation to reach the 
same confort level in Lisp.
Could you explain me how is this supposed to save time and money?

....

> I'm simply trying to correct a lot of misinformation here about
 > (Common) Lisp,
> "extreme/agile/incremental" development, and dynamically typed
> languages in general.

Correct me if I am wrong, but you stated that
"Actually this sort of development will save you much more
time and money than you could ever hope for from typical static typing."

And this is misinformation:

*OK*, Agile methods may save you money (althrough there is no silver 
bullet and some people reading this news group possibly have more 
effective development process, for exemple using formal proof and much 
less testing),

*BUT*, static typing is still unbeatable, with or without test-fist 
practice, as I illustrate in another message.

-- 
Lionel Draghi

Re: ADA Popularity Discussion Request

[jayessay]

Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:

> jayessay wrote:
> ...
> > First, types are indeed part of program design in dynamic languages.
> > In some respects they are even more important than in static languages
> > as they exist at _all_ times: compile load (link) and run.  They are
> > _always_ checked _all_ the time.  If you want to say "Ooo!  this has a
> > performance hit", fine, but with current systems any such checks are
> > basically in the noise.  OTOH, you can annotate a dynamic program with
> > static type information and/or use type inference to remove this issue
> > from most cases.
> 
> Jon,
> 
> I am trying my best to understand you without knowing Lisp, but I
> don't. This is the second time you explain this, but you are to
> abstract for me.

I'm not sure which part you are having trouble with.  Let's try this
(admittedly somewhat handwavy, but intended to help get the ideas):

To a reasonable first approximation:


What is typed?

Static:  Variables and expressions (including literals and variables)

Dynamic: Values (the things you think of as "in a variable" or as the
         result of the evaluation of an expression)


Where/when is the "type"?

Static: In the compiler's symbol table and semantic analyzer; exists
        during compilation.  Types do not exist at runtime.  To some
        extent they are still around at link time in C++ in order for
        template instantiation to work.

        Important: Types are _not_ first class objects.

Dynamic: In values; exists whenever a value exists - compiletime,
         load/link time, and runtime.

        Important: Types _are_ first class objects, i.e., there are
        _values_ which are _types_.  The types of these value types
        are meta types.  You can walk as far up the "logic ladder" as
        you want with this.

        "Ontologically" there is no difference (they have the same
        fundamental status) between these kinds of values and any
        other, e.g., integers, class instances, etc.  You can bind
        them, query them, create them, if (as in Common Lisp) you have
        a meta object protocol (MOP) you can even _change_ them and
        _alter_ the behavior of the type system.  There is a lot more
        here.


What is checked?

Static: Variables (containers) conform to expressions

Dynamic: Values conform to operations (functions operators, etc.)


When are things checked?

Static: Mostly at compile time (though there are important exceptions)

        Examples: (Ada)

        x := a; The type of variable A is checked to conform
        with the type of variable X, so that X is assured that
        whatever the _value_ in A during runtime, it should be a
        member of the type of X (conform to it).

        x := a + b; the types of A & B are used to select a set of +
        operator candidates whose result types are then checked
        against the type of X to determine the unique operation (if it
        exists) to use.

        Generally, there is a good deal of copying of values going on
        at runtime.  Variables exist only at compile time (though in
        C++ there is some level of existence through link), they are
        transformed to simply locations with enough space to hold
        values of the variables type (as determined at compile
        time)[2].


Dynamic: Mostly at runtime (though there are some useful exceptions).

         Examples: (Common Lisp)

        (let ((x a)) ...) the value _bound_ by (named by) A is _bound_
        to X, so that X is also a _name_ for it within the scope of
        the let.  Unless specifically requested, there are no type
        checks being made in these cases since there is no need for it
        - since a variable is just a binding (name) for a value it can
        be used to name any value.  No copying is ever done.  You can
        change or add a name to a value without opening a new scope by
        means of setf, e.g., (setf x a)

        (let ((x (+ a b))) ...) the standard + operation is generic
        (this is more analogous to an Ada function of a class wide
        type, than to generics).  The dispatch mechanism checks the
        types of A and B and either raises an exception if there is no
        possible match or performs the operation[2].  If the operation
        is performed, the resulting value is _bound_ to X within the
        scope of the let.

        Values are never copied.  Variables typically do not exist at
        runtime, with the important exception of dynamic variables
        (full symbols).  Variables are basically transformed into
        locations that reference values.


Is type consistency enforeced (is it type safe)?

Static: Mostly.  Casts, certain unchecked conversions, overlays can
        all subvert this.

Dynamic: Yes, values cannot be interpreted as any type other than what
         they are.




> My point is that with static typing, most type related problems are
> caught at compil time, before any execution.
> Know, you say here that it is possible to write annotation to reach
> the same confort level in Lisp.
> Could you explain me how is this supposed to save time and money?

It is the extreme flexibility and interactive nature of the
development with continual checking that is the big time saver and bug
eliminator (both type and logic).  The type annotation you can do does
not save you any development time (it actually costs time - just like
with static typing), it can save you runtime cycles by allowing the
compiler to perform more optimizations.

The really key thing here is that you develop by testing _everything_
in a very well scoped and limited unit at each incremental stage.  I
realize this is hard to get a grip on unless you've done it -
especially coming from a global static type kind of mind set.


> Correct me if I am wrong, but you stated that
> "Actually this sort of development will save you much more
> time and money than you could ever hope for from typical static typing."
> 
> And this is misinformation:

I don't think it is misinformation, but upon reading it again it could
well be inaccurate.  Misinformation is when you state a falsehood as
fact about something you know nothing about.  For example, "dynamic
typing means no typing", "dynamic typing is unsafe", "lisp is
interpreted".  The above is inaccurate in that for all I know for some
instantiation of "you", that instance will _not_ save anything using
this sort of development.  I know it has been true for me and many
others I know.


> *BUT*, static typing is still unbeatable, with or without test-fist
> practice, as I illustrate in another message.

In general I'm long past believing this.  Even the Haskellers, MLers,
etc. don't have good enough arguments or data to support the claims.
I do believe that in certain niches this can indeed be true.


/Jon

Notes

1. As noted in the preface this is only a first order approximation.
   For example, in Ada, there may well be some extra stuff (e.g., dope
   vectors) beyond simply a location for things like unconstrained
   arrays.

2. This is _not_ like a "polymorphic" dispatch, that is the domain of
   methods, and generic functions nor an overloading.  Generic
   functions are a proper superset of standard class based "object
   oriented" polymorphism.

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On 09 Sep 2004 20:47:54 -0400, jayessay wrote:

> Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:
> 
>> jayessay wrote:
>> ...
>>> First, types are indeed part of program design in dynamic languages.
>>> In some respects they are even more important than in static languages
>>> as they exist at _all_ times: compile load (link) and run.  They are
>>> _always_ checked _all_ the time.  If you want to say "Ooo!  this has a
>>> performance hit", fine, but with current systems any such checks are
>>> basically in the noise.  OTOH, you can annotate a dynamic program with
>>> static type information and/or use type inference to remove this issue
>>> from most cases.
>> 
>> Jon,
>> 
>> I am trying my best to understand you without knowing Lisp, but I
>> don't. This is the second time you explain this, but you are to
>> abstract for me.
> 
> I'm not sure which part you are having trouble with.  Let's try this
> (admittedly somewhat handwavy, but intended to help get the ideas):
> 
> To a reasonable first approximation:
> 
> What is typed?
> 
> Static:  Variables and expressions (including literals and variables)

Come on, values are untyped?

> Dynamic: Values (the things you think of as "in a variable" or as the
>          result of the evaluation of an expression)
 
> Where/when is the "type"?
> 
> Static: In the compiler's symbol table and semantic analyzer; exists
>         during compilation.  Types do not exist at runtime.  To some
>         extent they are still around at link time in C++ in order for
>         template instantiation to work.

This is wrong. Types exist at run-time and there are operations on types at
run-time. In Ada there are view conversions. It is possible to create
objects of *unknown* at compile time types. See S'Class'Input attribute for
further information.
 
>         Important: Types are _not_ first class objects.

This was a design choice of Ada. This is not a property of statically typed
languages. One can well introduce types of types and have types as their
values. Static typing only means that objects of statically known types are
checked against this constraint (contract).

> Dynamic: In values; exists whenever a value exists - compiletime,
>          load/link time, and runtime.
> 
>         Important: Types _are_ first class objects, i.e., there are
>         _values_ which are _types_.  The types of these value types
>         are meta types.

You contradict yourself. When types are first class objects then types
types should be plain types and so, also be first class objects. Whether a
feasible type system can be built if everything is a first class object is
questionable. Probably one will have problems with Russel's paradox or else
some objects will be inconstructible / have undecidable types etc.

>  You can walk as far up the "logic ladder" as
>         you want with this.

This is another [IMO better] way, where there are firewalls between values
(first class objects), types (second class objects), types types (third
class objects) etc.

Anyway both alternatives have nothing to do with static analysis. When the
contract of an object of any class is statically known, it should be
checked. The contract of a constant is to have a known value. This is why
2+2 is known to be 4 prior run-time. At least my pocket calculator tells
so. (:-))

>         "Ontologically" there is no difference (they have the same
>         fundamental status) between these kinds of values and any
>         other, e.g., integers, class instances, etc.  You can bind
>         them, query them, create them, if (as in Common Lisp) you have
>         a meta object protocol (MOP) you can even _change_ them and
>         _alter_ the behavior of the type system.  There is a lot more
>         here.

Is meta object protocol an object? What is the type of the protocol? And
finally, is meta object protocol checked? Statically?

> What is checked?
> 
> Static: Variables (containers) conform to expressions

It is the contracts that are checked. Type checks is to narrow definition
of what is checked.

> Dynamic: Values conform to operations (functions operators, etc.)

Same as above.

> When are things checked?
> 
> Static: Mostly at compile time (though there are important exceptions)
> 
>         Examples: (Ada)
> 
>         x := a; The type of variable A is checked to conform
>         with the type of variable X, so that X is assured that
>         whatever the _value_ in A during runtime, it should be a
>         member of the type of X (conform to it).

Wrong, assignement in Ada may raise Constraint_Error at run-time.

>         x := a + b; the types of A & B are used to select a set of +
>         operator candidates whose result types are then checked
>         against the type of X to determine the unique operation (if it
>         exists) to use.

It depends. With multiple dispatch it is the type of x, of a and of b to
determine the operations + and :=. Anyway, in Ada if a and b are
class-wide, dispatching to + might fail at *run* time.

>         Generally, there is a good deal of copying of values going on
>         at runtime.  Variables exist only at compile time (though in
>         C++ there is some level of existence through link), they are
>         transformed to simply locations with enough space to hold
>         values of the variables type (as determined at compile
>         time)[2].

Your theory is wrong:

declare
   X : T'Class := Read_It_From_File (Stream);
        -- The size of X is unknown till run time 

> Dynamic: Mostly at runtime (though there are some useful exceptions).
> 
>          Examples: (Common Lisp)
> 
>         (let ((x a)) ...) the value _bound_ by (named by) A is _bound_
>         to X, so that X is also a _name_ for it within the scope of
>         the let.  Unless specifically requested, there are no type
>         checks being made in these cases since there is no need for it
>         - since a variable is just a binding (name) for a value it can
>         be used to name any value.  No copying is ever done.  You can
>         change or add a name to a value without opening a new scope by
>         means of setf, e.g., (setf x a)

declare
   X : T'Class renames Get_It;
      -- No copying, no specific type known

>         (let ((x (+ a b))) ...) the standard + operation is generic
>         (this is more analogous to an Ada function of a class wide
>         type, than to generics).  The dispatch mechanism checks the
>         types of A and B and either raises an exception if there is no
>         possible match or performs the operation[2].

No different from Ada's way of dispatching on multiple parameters. BTW, it
is actually a drawback of Ada that mutiple dispatch is limited to the cases
where types have same tag.

>         If the operation
>         is performed, the resulting value is _bound_ to X within the
>         scope of the let.
>
>         Values are never copied.  Variables typically do not exist at
>         runtime, with the important exception of dynamic variables
>         (full symbols).  Variables are basically transformed into
>         locations that reference values.

This is Lisp's problem. In Ada the programmer has a choice whether the
objects should have a by-value or by-reference semantics. Clearly, if you
want to put objects in a register, you will be in trouble with Lisp... 
 
> Is type consistency enforeced (is it type safe)?
> 
> Static: Mostly.  Casts, certain unchecked conversions, overlays can
>         all subvert this.

Unchecked conversion subverts nothing. It is as legal as any other
operation. It has the parameter profile, which is *checked*. It takes a
value of a distinct type and returns the result of another distinct type.
Note, types of the parameter profile tell nothing about the operation
semantics. So unchecked conversion is as good as any other. It is not
compiler's business to check program semantics.

> Dynamic: Yes, values cannot be interpreted as any type other than what
>          they are.

It is again Lisp's problems. Unchecked conversion have their place
regardless time and place types are checked.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ADA Popularity Discussion Request

[jayessay]

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

> On 09 Sep 2004 20:47:54 -0400, jayessay wrote:
> 
> > Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:
> > 
> >> jayessay wrote:
> >> ...
> >>> First, types are indeed part of program design in dynamic languages.
> >>> In some respects they are even more important than in static languages
> >>> as they exist at _all_ times: compile load (link) and run.  They are
> >>> _always_ checked _all_ the time.  If you want to say "Ooo!  this has a
> >>> performance hit", fine, but with current systems any such checks are
> >>> basically in the noise.  OTOH, you can annotate a dynamic program with
> >>> static type information and/or use type inference to remove this issue
> >>> from most cases.
> >> 
> >> Jon,
> >> 
> >> I am trying my best to understand you without knowing Lisp, but I
> >> don't. This is the second time you explain this, but you are to
> >> abstract for me.
> > 
> > I'm not sure which part you are having trouble with.  Let's try this
> > (admittedly somewhat handwavy, but intended to help get the ideas):
> > 
> > To a reasonable first approximation:
> > 
> > What is typed?
> > 
> > Static:  Variables and expressions (including literals and variables)
> 
> Come on, values are untyped?

<and a lot more that is not worth bothering with>

You are hopeless


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> On 08 Sep 2004 10:52:05 +0200, Ole-Hjalmar Kristensen wrote:
>
> >>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:
> > 
> >     LD> jayessay wrote:
> >     LD> ...
> >     >> Exactly.  Actually this sort of development will save you much more
> >     >> time and money than you could ever hope for from typical static typing.
> > 
> >     LD> How could this be?
> >     LD> With powerful typing you write code.
> >     LD> Without, you write as much code and much more tests.
> > 
> > You are missing the point. He is not arguing against strong typing,
> > but against *static* typing.
>
> Apparently, but when consistently pursued that kind of argumentation
> inevitable leads to arguing against any typing, especially against ADT. The
> philosophy behind is that types are random artifacts of the program, rather
> than the basis of software design.
No, the philosophy behind this is that there is no need for type systems to be
always of mainframe kind - comprehensive, complex, requiring distinguished and
rare experts for their creation, future development and general maintenance;
that there can be custom type systems - with lesser scope, that is, not so
universally applicable or useful, but bringing significant advantages in some
particular domains and which really can be succesfully created and controlled
at reasonable (more common and therefore more accessible) level of expertise.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Wed,  8 Sep 2004 23:46:44 +0400 (MSD), Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> On 08 Sep 2004 10:52:05 +0200, Ole-Hjalmar Kristensen wrote:
>>
>>>>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:
>>> 
>>>     LD> jayessay wrote:
>>>     LD> ...
>>>     >> Exactly.  Actually this sort of development will save you much more
>>>     >> time and money than you could ever hope for from typical static typing.
>>> 
>>>     LD> How could this be?
>>>     LD> With powerful typing you write code.
>>>     LD> Without, you write as much code and much more tests.
>>> 
>>> You are missing the point. He is not arguing against strong typing,
>>> but against *static* typing.
>>
>> Apparently, but when consistently pursued that kind of argumentation
>> inevitable leads to arguing against any typing, especially against ADT. The
>> philosophy behind is that types are random artifacts of the program, rather
>> than the basis of software design.
>
> No, the philosophy behind this is that there is no need for type systems to be
> always of mainframe kind - comprehensive, complex, requiring distinguished and
> rare experts for their creation, future development and general maintenance;
> that there can be custom type systems - with lesser scope, that is, not so
> universally applicable or useful, but bringing significant advantages in some
> particular domains and which really can be succesfully created and controlled
> at reasonable (more common and therefore more accessible) level of expertise.

Compare it with: there is no need is universal programming languages -
comprehensive, complex etc ... write your own every time you get a new
contract. Back in 70's people probably believed in that, largely because
the languages were undeveloped.

30 years later, why a custom type system cannot be built on the top of a
universal one?

P.S. Re-read your answer, isn't it against types? Sure? (:-))

P.P.S. Comprehensive etc type system costs nothing when static. Maintenance
etc will be compier guys business! (:-))

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ADA Popularity Discussion Request

[jayessay]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:

> Dmitry A. Kazakov wrote:
> 
> > On 08 Sep 2004 10:52:05 +0200, Ole-Hjalmar Kristensen wrote:
> >
> > >>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:
> > > ...
> > >     LD> How could this be?
> > >     LD> With powerful typing you write code.
> > >     LD> Without, you write as much code and much more tests.
> > > 
> > > You are missing the point. He is not arguing against strong typing,
> > > but against *static* typing.
> >
> > Apparently, but when consistently pursued that kind of argumentation
> > inevitable leads to arguing against any typing, especially against ADT. The
> > philosophy behind is that types are random artifacts of the program, rather
> > than the basis of software design.
>
> No, the philosophy behind this is that there is no need for type
> systems to be always of mainframe kind - comprehensive, complex,
> requiring distinguished and rare experts for their creation, future
> development and general maintenance

I submit that for good or ill (I believe good) the Common Lisp type
system is an example of this sort of characterization.

http://www.lispworks.com/reference/HyperSpec/Body/04_.htm


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Alexander E. Kopilovich]

jayessay wrote:

> "Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:
>
> > Dmitry A. Kazakov wrote:
> > 
> > > On 08 Sep 2004 10:52:05 +0200, Ole-Hjalmar Kristensen wrote:
> > >
> > > >>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:
> > > > ...
> > > >     LD> How could this be?
> > > >     LD> With powerful typing you write code.
> > > >     LD> Without, you write as much code and much more tests.
> > > > 
> > > > You are missing the point. He is not arguing against strong typing,
> > > > but against *static* typing.
> > >
> > > Apparently, but when consistently pursued that kind of argumentation
> > > inevitable leads to arguing against any typing, especially against ADT. The
> > > philosophy behind is that types are random artifacts of the program, rather
> > > than the basis of software design.
> >
> > No, the philosophy behind this is that there is no need for type
> > systems to be always of mainframe kind - comprehensive, complex,
> > requiring distinguished and rare experts for their creation, future
> > development and general maintenance
>
> I submit that for good or ill (I believe good) the Common Lisp type
> system is an example of this sort of characterization.

This is certainly OK (and perhaps even necessary) for a general platform,
on which various more simple and specifically targeted languages can be built.
Development of such domain-specific languages surely require good expertise,
but not so advanced and rare as it is needed for development/maintenance of 
the platform itself.

I suppose that you meant languages of that kind in the following passage from
your previous message here in comp.lang.ada :

(Message-Id: <m3656vfgmf.fsf@rigel.goldenthreadtech.com>
 Date: 03 Sep 2004 12:43:04 -0400)

| ...  The second is achieved by crafting a constrained narrowly
| focused domain specific language _within_ Lisp, which allows the
| programmer to then work at the level of the domain, _both_
| syntactically as well as semantically.  This is why Lisp macros
| (please don't confuse with any other kind of macro you've come across
| before) are such a big deal.





Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: ADA Popularity Discussion Request

[jayessay]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:

> jayessay wrote:
> 
> > I submit that for good or ill (I believe good) the Common Lisp type
> > system is an example of this sort of characterization.
> 
> This is certainly OK (and perhaps even necessary) for a general
> platform, on which various more simple and specifically targeted
> languages can be built.  Development of such domain-specific
> languages surely require good expertise, but not so advanced and
> rare as it is needed for development/maintenance of the platform
> itself.

Yes, I agree with this analysis.


> I suppose that you meant languages of that kind in the following
> passage from your previous message here in comp.lang.ada :
> 
> (Message-Id: <m3656vfgmf.fsf@rigel.goldenthreadtech.com>
>  Date: 03 Sep 2004 12:43:04 -0400)
> 
> | ...  The second is achieved by crafting a constrained narrowly
> | focused domain specific language _within_ Lisp, which allows the
> | programmer to then work at the level of the domain, _both_
> | syntactically as well as semantically.  This is why Lisp macros
> | (please don't confuse with any other kind of macro you've come across
> | before) are such a big deal.

Generally speaking, yes.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[jayessay]

Ole-Hjalmar Kristensen  writes:

> >>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:
> 
>     LD> jayessay wrote:
>     LD> ...
>    >> Exactly.  Actually this sort of development will save you much more
>    >> time and money than you could ever hope for from typical static typing.
> 
>     LD> How could this be?
>     LD> With powerful typing you write code.
>     LD> Without, you write as much code and much more tests.
> 
> You are missing the point. He is not arguing against strong typing,
> but against *static* typing.

Yes, you are correct.  Dynamic typing is every bit (and in some ways
more) strong as static typing.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Richard Riehle]

"jayessay" <nospam@foo.com> wrote in message
news:m3n000bv64.fsf@rigel.goldenthreadtech.com...

> Yes, you are correct.  Dynamic typing is every bit (and in some ways
> more) strong as static typing.
>
There are many kinds of strength.   I am wondering whether
you are intellectually honest enough to state the weaknesses
as well as the strengths of the Lisp approach.

For example, in the world of physical engineering, we must
acknowledge that steel is endowed with greater tensile
strength than concrete, whereas concrete is characterized
by greater compression strength.   This knowledge leads
to designs that combine the corresponding strengths
of both concrete and steel in the creation of reinforced
concrete beams.

There are, admittedly, many benefits from the Lisp dynamic
typing model, under some circumstances.  There are many
disadvantages, under other circumstances, to the static
typing model of Ada, C++, and others.  Since Ada is more
type safe than those others, those disadvantages sometimes
are more pronounced.    However, there are definite benefits
to the static typing model, when it is used intelligently, and
those often outweigh the disadvantages.

Where do you see the disadvantages of the Lisp dynamic
typing approach?

Richard Riehle

Re: ADA Popularity Discussion Request

[jayessay]

"Richard  Riehle" <adaworks@earthlink.net> writes:

> "jayessay" <nospam@foo.com> wrote in message
> news:m3n000bv64.fsf@rigel.goldenthreadtech.com...
>
> > Yes, you are correct.  Dynamic typing is every bit (and in some ways
> > more) strong as static typing.
> >
> There are many kinds of strength.

The kind I believe that people intend in this context involves the
notions of "consistency" and adherence to various "constraints".


> I am wondering whether
> you are intellectually honest enough to state the weaknesses
> as well as the strengths of the Lisp approach.

              Presumably you mean ^^^^ "dynamic typing" here as that is
              the context of this subsubthread (which would include many
              others than Lisp).

The weakness in this context is obvious: if you use a _formal_ static
type system and your problem can be stated completely in it, you can
indeed _prove_ with automated methods various useful properties from
the source code.


> There are, admittedly, many benefits from the Lisp dynamic
> typing model, under some circumstances.  There are many
> disadvantages, under other circumstances, to the static
> typing model of Ada, C++, and others.  Since Ada is more
> type safe than those others, those disadvantages sometimes
> are more pronounced.    However, there are definite benefits
> to the static typing model, when it is used intelligently, and
> those often outweigh the disadvantages.

[Aside: I believe that formal type systems like those of Haskell,
OCAML, et.al. are much more potent than the informal ones of Ada, C++,
Java, etc.  Would you agree with this?  I ask because one would think
that a static typist would want to use the best version of that kind
of system available which is not what is available in
Ada/Eiffel/... so there must be some other more important reason for
using these than the typing they provide]


> Where do you see the disadvantages of the Lisp dynamic
> typing approach?

Compared to Hindley-Milner type systems (as in Haskell, etc.), using
type inference, with dynamic typing you lose the ability to prove
certain interesting invariants and other properties automatically from
the source code.

You can augment some dynamic systems with static analysis which can
get you some of this (a lot?) of this.  But, frankly, I don't know
enough about these efforts as I haven't looked at them in enough
detail.


/Jon

--
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Kevin Cline]

Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> wrote in message news:<413e2fbd$0$30586$626a14ce@news.free.fr>...
> jayessay wrote:
> ...
> > Exactly.  Actually this sort of development will save you much more
> > time and money than you could ever hope for from typical static typing.
> 
> How could this be?
> With powerful typing you write code.
> Without, you write as much code and much more tests.

I code test-first, and the amount of test code is relatively
independent of the language.

> 
> Let's compare:
> 
> A :
> function Random_Index return Integer;
> -- return's a value between 1 and 10
> 
> B :
> type Index is range 1 .. 10;
> function Random_Index return Index;
> 
> If considering code and comments, both are of the same length.

The first version leaves me wondering if the comment is correct.
The second version leaves me wondering if it sometimes throws
Constraint_Error.  There's no way to verify that A always returns a
value from 1 to 10 or to verify that B never throws Constraint_Error
without inspecting the function body.

I'm also wondering what happens when you write Random_Index +
Random_Index ?
Or Random_Index * Random_Index ?

> On the other hand, in the A version, I need to check the return value on 
> each call.

That's silly.  You have to trust functions to satisfy their
postconditions.   Even in Ada relatively few post-conditions can be
handled by type checks.  Would you check after every call to
Create_Linked_List to make sure that you got an empty list?  And then
check after every call to Insert_At_Head to make sure that the list
hadn't somehow become circular?

If you want bounded types in C++ it's easy enough to write a template
class:

template <int lower_bound, int upper_bound> class bounded
{
  private: 
    int _value;
  public:
    operator int { return _value; }
    explicit bounded(int value): _value(value)
    { if (value < lower_bound || value > upper_bound) { throw(...); } 
    operator=(int value) { *this = bounded(value); } 
  }
}

Then your function is:
  bounded<1,10> random_index() {...}

If the spirit moves you, you can even write:

  template <int lb2, int ub2>
    bounded<lower_bound+lb2, upper_bound + ub2> 
      operator+(bounded<lb2, ub2> b2)
  {
    return _value + b2.value;
  }

Now adding bounded<1,10> to bounded<0,5> gives a result of the proper
type: bounded<1,15>.

In LISP-y languages, you would just write something like:
  (defun random-index () (bound 1 10 ... )

Re: ADA Popularity Discussion Request

[Ed Falis]

I agree to a good extent with Kevin.  I tend to use test-first, assertions  
(or DbC if available) and static typing to complement each other.  And  
they do.

- Ed

Re: ADA Popularity Discussion Request

[Lionel Draghi]

Ed Falis wrote:
> I agree to a good extent with Kevin.  I tend to use test-first, 
> assertions  (or DbC if available) and static typing to complement each 
> other.  And  they do.

Is it really your opinion, Kevin?
If yes, I am pleased to see that we fully agree ;-)

And you Jon?

OK, I suppose it's because of my poor english that I thought you where 
underestimating type usefulness :-)

-- 
Lionel Draghi

Re: ADA Popularity Discussion Request

[Kevin Cline]

Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> wrote in message news:<4140b906$0$29447$636a15ce@news.free.fr>...
> Ed Falis wrote:
> > I agree to a good extent with Kevin.  I tend to use test-first, 
> > assertions  (or DbC if available) and static typing to complement each 
> > other.  And  they do.
> 
> Is it really your opinion, Kevin?

I use static typing to do as much as it can do.  I'm currently coding
in C# and am frustrated because collections are not type-safe so one
is constantly downcasting.  You have to pay for strong typing without
getting the full benefit.  In C++ I could go for months without
writing any dynamic cast.

I used to value it highly, but have recently changed my opinion and
value the ability to rapidly switch between coding and testing more
highly.

> OK, I suppose it's because of my poor english that I thought you where 
> underestimating type usefulness :-)

It's useful, but as implemented in Ada, and to almost the same extent
as implemented in C++, it's also expensive.

Re: ADA Popularity Discussion Request

[Ed Falis]

On 10 Sep 2004 17:04:39 -0700, Kevin Cline <kevin.cline@gmail.com> wrote:

> Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> wrote in message
> news:<4140b906$0$29447$636a15ce@news.free.fr>...
>> Ed Falis wrote:
>> > I agree to a good extent with Kevin.  I tend to use test-first,
>> > assertions  (or DbC if available) and static typing to complement each
>> > other.  And  they do.
>>
>> Is it really your opinion, Kevin?


Please understand that my first sentence and second were distinct.  I did  
not mean to imply that the second had anything to do with Kevin's  
preferences other than to validate the use of test-first design as part of  
my personal approach.


- Ed

Re: ADA Popularity Discussion Request

[jayessay]

Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:

> Ed Falis wrote:
> > I agree to a good extent with Kevin.  I tend to use test-first,
> > assertions  (or DbC if available) and static typing to complement
> > each other.  And  they do.
> 
> Is it really your opinion, Kevin?
> If yes, I am pleased to see that we fully agree ;-)
> 
> And you Jon?

Not exactly, because I don't use much static typing anymore.  It just
doesn't offer much because it is largely dependent on having all
requirements set in concrete (which they almost never are).

Have a look at this:

http://martinfowler.com/articles/newMethodology.html


I think you and many others in this group will get a lot of insight
from this article.  It is not a perfect description but it has some
advantages for this context:

1. It is written by someone who has been there and done that in both
   the traditional development cycle and some agile methods

2. It is written by someone for whom most people in this group
   probably have at least some respect.


Personally, I think the sort of "agile" method I've been mentioning
here is in many ways analogous to developing a theory in mathematics
than what happens in "engineering".  There is a lot of creative
"noodling" that goes into this buttressed by very high levels of
rigor, with a very bottom up approach where each definition,
proposition, lemma and theorem are incrementally determined and
tightly integrated.  There are of course many differences, but it at
least indicates the very different mind set.


> OK, I suppose it's because of my poor english that I thought you
> where underestimating type usefulness :-)

Not type usefulness, most everyone agrees types are useful, even
necessary.  It is _static_ typing that is of questionable usefulness
in any domain that doesn't have clear, well defined requirements
(which is to say the vast majority of cases).


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Lionel Draghi]

jayessay wrote:
...
>>>I agree to a good extent with Kevin.  I tend to use test-first,
>>>assertions  (or DbC if available) and static typing to complement
>>>each other.  And  they do.
>>
>>Is it really your opinion, Kevin?
...
>>And you Jon?

> Not exactly, because I don't use much static typing anymore.  It just
> doesn't offer much because it is largely dependent on having all
> requirements set in concrete (which they almost never are).

We have several thousand types comming from norm or standard that are 
perfectly stable. (I am in the communication field).

But anyway that's not important:
1 - lot's of type just come from the design, not directly from 
requirements. So YOU are in charge of defining those.

2 - not having the range or other details is not an excuse no to create 
a specific type, as I illustrated in another mail.

> Have a look at this:
> http://martinfowler.com/articles/newMethodology.html
I will.
...

> 
> Not type usefulness, most everyone agrees types are useful, even
> necessary.  It is _static_ typing that is of questionable usefulness
> in any domain that doesn't have clear, well defined requirements
> (which is to say the vast majority of cases).
Questionable, yes, always.
But we clearly won't agree on the answer, so I suppose it's time for me 
to leave this thread.

-- 
Lionel Draghi

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:

:  It is _static_ typing that is of questionable usefulness
: in any domain that doesn't have clear, well defined requirements

I wish you had stated this so very clearly much earlier. :-)

: (which is to say the vast majority of cases).

Is it the vast majority of cases involving actual money where
there are no well defined requirements?

-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> jayessay <nospam@foo.com> wrote:
> 
> :  It is _static_ typing that is of questionable usefulness
> : in any domain that doesn't have clear, well defined requirements
> 
> I wish you had stated this so very clearly much earlier. :-)

I did.  Several times.  Perhaps you missed those?


> : (which is to say the vast majority of cases).
> 
> Is it the vast majority of cases involving actual money where
> there are no well defined requirements?

Yes.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:> jayessay <nospam@foo.com> wrote:
:> 
:> :  It is _static_ typing that is of questionable usefulness
:> : in any domain that doesn't have clear, well defined requirements
:> 
:> I wish you had stated this so very clearly much earlier. :-)
: 
: I did.  Several times.  Perhaps you missed those?

I must have missed them. ... Yes, you mention specifications lacking
rigor. OK.


-- Georg

Re: ADA Popularity Discussion Request

[Alexander E. Kopilovich]

jayessay wrote:

> ... I don't use much static typing anymore.  It just
> doesn't offer much because it is largely dependent on having all
>requirements set in concrete (which they almost never are).
>
>Have a look at this:
>
>http://martinfowler.com/articles/newMethodology.html

Well, personally I have no need to look at any article for acknowledging that
in very many (probably majority of) software works the requirements are
neither comprehensive nor stable - I know that too well. But your claim - that
this is almost always so - is severe exaggeration; there are enough software
works where where all requirements are (or at least presumed to be) indeed
set in concrete. And Ada language was and is targetted primarily at the
domains where the latter is generally true.

> Personally, I think the sort of "agile" method I've been mentioning
> here is in many ways analogous to developing a theory in mathematics
> than what happens in "engineering".  There is a lot of creative
> "noodling" that goes into this buttressed by very high levels of
> rigor, with a very bottom up approach where each definition,
> proposition, lemma and theorem are incrementally determined and
> tightly integrated.  There are of course many differences, but it at
> least indicates the very different mind set.

I'm just wondering why do you think that this mind set can be successful
in long run, when it is adopted without understanding and adoption of rigid
requirements and limitations, which are associated with it in mathematics.

Apart from that rather subjective notion of mind set, please note that there
are two highly important aspects of the difference - *scheduled* reliability
and associated immediate risks.

All that widely acknowledged reliability of mathematical theories can't be
achieved quickly - it is a long way for a theorem to be accepted as proved -
that involves many checks by many persons and enough years to wait for a
possible discovery of a hidden gap in the proof. Real-world projects these
times are usually constrained by economy and competition and therefore can
neither wait so much nor allow extensive public reviews.
(Note, that besides of really firmly established theories, mathematics - and
especially applied mathematics - has also so-called "methods", which quite
often aren't reliable - sometimes they lead to a success, but in other cases
they fail - and there may be no known way to predict what will happen in a
particular case without trying the method... or going into specifics of the
case to significant depth, and then using explicit or implicit references to
previous experience. No wonder that those generally unreliable, but sometimes
effective methods often can be developed much faster that solid theories.)

Then, creative imagination do not face immediate real-word risks; therefore
one can try to rely upon too fresh proof of some theorem (or upon too bold
interpretation) and see what can be built atop of it.  If your risks are low
- just waste of some time, waste of some (not too much) money - then you may
run as a creative programmer; but if your risks are high - immediate loss of
lives, severe breach of security, strong and massive negative impact on
environment, etc. - then your must run as responsible engineer, strictly
limiting immediate impact of your creative imagination.

And as usual, there are grey zones - where either both risks and possible
gains are substantial or where taking risk in one aspect of the whole matter
may significantly decrease risk associated with other aspects. Some would
call this a gambling, others would call this a balancing.

> Not type usefulness, most everyone agrees types are useful, even
> necessary.  It is _static_ typing that is of questionable usefulness
> in any domain that doesn't have clear, well defined requirements
> (which is to say the vast majority of cases).

I think that after that rather prolonged arguing about usefulness of dynamic
vs. static typing using "field performance" kind of arguments, it is time
to try to describe the difference between them in some more general terms.

First, for static typing, let's repeat that "Ada is for problem space".
That means, that description of problem space is considered as primary
strategic goal for Ada language. Static typing is natural thing for such
a description - a typed variable is a natural instance of a coordinate in that
space. So, the discussion is actually about whether it is generally good to
strive for (precise) description of problem space.

But what is an alternative? If static typing provides us means for description
of problem state, then what does dynamic typing provide?

I guess that dynamic typing provides description of "event space", that is,
a particular stage of the whole process, on whatever level of the latter.
In this sense, with dynamic typing, the variables represent a kind of local
coordinates along the process's trajectory (at the process's current state).

It also seems to me that there must be some duality between these two kinds
of typing; perhaps the pair of universal objects from category theory -
product and coproduct (which are dual to each other) - somehow relates to
that comparison (where product stands for static typing, and coproduct stands
for dynamic typing).

Then, static typing, with its capabilities for descrpiption of whole problem
state, promotes analytical approach, while dynamic typing, with its
concentration on local events (on various levels), promotes synthetic approach.

So, if a challenge is the most significant aspect of the job then dynamic
typing may bring noticeable advantages; but from the crash investigator's
viewpoint, dynamic typing is a horrible thing, and the stricter is static
typing - the better: strict static typing will not eliminate crashes, but
it will make investigation task much easier (note, that an investigator
often must not only discover what causes the crash, but also make someone
responsible).




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
: If you want bounded types in C++ it's easy enough to write a template
: class:

True, but it is not quite the same thing, is it? You can write bounded
types in C. Yet, they don't become C language types, with ISO definded
semantics beyond what you'd expect for any user defined type.
Does the C++ standard directly address the behavior of handwritten
bounded numbers? How many lines of template code will it take
to get the effect of

  type A is array(Some_Index_Type) of Foo;?


#include <assert.h>

struct _bint {
  long v;
  int up, lo;
};
typedef struct _bint bint;  // int with bounds checking

static inline void throw_C_overflow() { assert(0); }

bint range_checked(bint val) {
  if (val.lo > val.v || val.v > val.up) throw_C_overflow();
  return val;
}

bint make_bound(int lower, int upper, int val) {
  return range_checked((bint){ .v = val, .up = upper, .lo = lower });
}
bint multiply(bint a, bint b, bint res) {
  return range_checked((bint){ .v = a.v * b.v, .lo = res.lo, .up = res.up });
}
void set(bint* old, int new) {
  (*old).v = new;
  range_checked(*old);
}

int main()
{
  bint x = make_bound(1, 10, 3);

  // set(&x, 14);   // try this to see the effect
  return multiply(x, x, x).v;
}

: In LISP-y languages, you would just write something like:
:  (defun random-index () (bound 1 10 ... )

OTOneH people complain that large C programs mimic half of Lisp.
 (C being a compiled language with little support for anything.)
OTOtherH people suggest that Ada features be implemented in Lisp.
 (Ada being just a compiled language with a few nice features.)
Adjust for C++ and other combinations.
Now what?

-- Georg

Re: ADA Popularity Discussion Request

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<choh37$8i9$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> : If you want bounded types in C++ it's easy enough to write a template
> : class:
> 
> True, but it is not quite the same thing, is it? You can write bounded
> types in C. Yet, they don't become C language types, with ISO definded
> semantics beyond what you'd expect for any user defined type.

The Ada designers evidently thought arrays were really really
important, because they provided elaborate language facilities to
support array-based programming.  The C language designers instead
created a small but useful language.  Stroustrup didn't spend much
effort on arrays, perhaps because he didn't think they were so
important.  Instead he tried to make it easy to define and use new
types as easily as one could use the fundamental types.

> Does the C++ standard directly address the behavior of handwritten
> bounded numbers? How many lines of template code will it take
> to get the effect of
> 
>   type A is array(Some_Index_Type) of Foo;?

I don't know.  It could be done in C++ if Some_Index_Type had the
right properties.  But as a practical matter, no one seems to care, at
least no one in the C++ community.  I very rarely have any need or use
for a statically sized array.  Even if I did want a static array with
non-integer indexing, unless it's really important to shave 100
nanoseconds from the lookup time, a map will do just as well, and
that's the canonical solution in both C++ and Perl.

> #include <assert.h>
> 
> struct _bint {
>   long v;
>   int up, lo;
> };

This is quite ugly, not to mention inefficient.  But I would never
advocate use of C for writing an application of any size.

Re: ADA Popularity Discussion Request

[Martin Krischik]

Kevin Cline wrote:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
> news:<choh37$8i9$1@a1-hrz.uni-duisburg.de>...
>> Kevin Cline <kevin.cline@gmail.com> wrote:
>> : If you want bounded types in C++ it's easy enough to write a template
>> : class:
>> 
>> True, but it is not quite the same thing, is it? You can write bounded
>> types in C. Yet, they don't become C language types, with ISO definded
>> semantics beyond what you'd expect for any user defined type.
> 
> The Ada designers evidently thought arrays were really really
> important, because they provided elaborate language facilities to
> support array-based programming.  The C language designers instead
> created a small but useful language.

K&C was not at all usefull. Almost imediatly "lint" appeared to save you
from all the pitfalls C hat.

Of corse C has become more usefull But as a result it is not small anymore.
The ISO/IEC 9899:1999 is just as big as the RM but mor difficult to read.
And I am not aware of any compiler which supports the standard in full.


> Stroustrup didn't spend much 
> effort on arrays, perhaps because he didn't think they were so
> important.

Since I do own the ISO/IEC 9899:1999 I have one to swallow for your
(6.7.5.2, Page 117):

extern int n;
extern int m;
void fcompat (void)
{
        int a[n][6][m];

And next page it becomes even cooler:

void fvla (int m; int C[m][m]);

void fvla (int m; int C[m][m]);
{
        typedef int VLA[m][m];
        ...
        int D[m];

It looks like the C comunity have finaly found out that K&R and Stroustrup 
have bee wrong and arrays with bounds are important after all.

> Instead he tried to make it easy to define and use new 
> types as easily as one could use the fundamental types.
> 
>> Does the C++ standard directly address the behavior of handwritten
>> bounded numbers? How many lines of template code will it take
>> to get the effect of
>> 
>>   type A is array(Some_Index_Type) of Foo;?
> 
> I don't know.

But I do:

>wc --lines AdaArray.C AdaArray.H
     95 AdaArray.C
    467 AdaArray.H
    562 insgesamt

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Benjamin Ketcham]

Martin Krischik <krischik@users.sourceforge.net> wrote:
>
>> support array-based programming.  The C language designers instead
>> created a small but useful language.
> 
> K&C was not at all usefull. Almost imediatly "lint" appeared to save you
> from all the pitfalls C hat.

K&R C can be criticized on many grounds, but "useful" is not
a valid one, IMO.  The original C was one of the most "useful"
languages we've seen.  Witness its rapid spread through
academia, and later, industry.  Despite all the pitfalls, it
was a small and efficient language, which meant easy portability
to new platforms as they arose.  Along with Unix (also full of
pitfalls of course), the language quickly became the first
choice for systems programming on almost any CPU: a position
it continues to hold today.

> Of corse C has become more usefull But as a result it is not small anymore.
> The ISO/IEC 9899:1999 is just as big as the RM but mor difficult to read.
> And I am not aware of any compiler which supports the standard in full.

The fact that C99 has not caught on would seem to indicate that
the market considers it *less* useful, not more!  The de facto
industry standard is "C90 plus the common extensions", and there it
remains.  I guess the C programmers didn't want their language to
go down the path of the "RM".  Or, they just don't see it as
necessary (niche areas like numerical computation being exceptions).

"Robust", "type-safe", etc., are not the same thing as "useful".
C has many failings, but ya gotta give it credit, it's pretty darn
useful.  "Better" languages like Ada can only dream of being
found so "useful" by a majority of the computing market.

Is there an Ada compiler for the Palm Pilot?

--Benjamin

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Benjamin Ketcham <bketcham@drizzle.com> wrote:
: 
: The fact that C99 has not caught on would seem to indicate that
: the market considers it *less* useful, not more!  The de facto
: industry standard is "C90 plus the common extensions", and there it
: remains.  I guess the C programmers didn't want their language to
: go down the path of the "RM".  Or, they just don't see it as
: necessary (niche areas like numerical computation being exceptions).

Maybe C99 is as yet unknown to many C programmers?


-- Georg

Re: ADA Popularity Discussion Request

[Benjamin Ketcham]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> Benjamin Ketcham <bketcham@drizzle.com> wrote:
> : 
> : The fact that C99 has not caught on would seem to indicate that
> : the market considers it *less* useful, not more!  The de facto
> : industry standard is "C90 plus the common extensions", and there it
> : remains.  I guess the C programmers didn't want their language to
> : go down the path of the "RM".  Or, they just don't see it as
> : necessary (niche areas like numerical computation being exceptions).
> 
> Maybe C99 is as yet unknown to many C programmers?

Well, I can't speak for the "unwashed masses" of C/C++/Win32 programmers;
I wouldn't expect my own experience to necessarily be the same.  But *I*
am certainly aware of C99; and personally, I haven't met any C programmers
who are not aware of C99.  With me, it is a conscious choice to remain
compatible with C90 wherever possible: i.e., the same considerations that
often lead me to choose C over C++ (or Ada).  If I *need* the C99 features,
then I can try to find a compiler.  But frankly, I don't need any of the
new features, most of the time, nice though some of them are (or *would
be* if anyone implemented them!).  The main C99 features that are of
general utility, such as "long long", have been available as extensions
(though not all implementations are compatible with the C99 syntax).
Same for niceties like intermixed declarations and statements, //-comments,
etc..  I personally don't need flexible arrays enough to want to break C90
portability, and while the integer types and numerics have been greatly
improved and regularized in C99, again I am already used to living without
this.  C90 is turning out to be a hard act to follow!  Just writing a
new standard, even a clearly improved standard with the seal of approval
of a respected industry organization, doesn't seem to be enough to make
people clamour to switch.

I don't think many people are using C90 merely because they haven't
heard of C99 yet.  It's the *compiler vendors* who haven't heard of it...

--Benjamin

Re: ADA Popularity Discussion Request

[Martin Krischik]

Benjamin Ketcham wrote:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
>> Benjamin Ketcham <bketcham@drizzle.com> wrote:
>> : 
>> : The fact that C99 has not caught on would seem to indicate that
>> : the market considers it *less* useful, not more!  The de facto
>> : industry standard is "C90 plus the common extensions", and there it
>> : remains.  I guess the C programmers didn't want their language to
>> : go down the path of the "RM".  Or, they just don't see it as
>> : necessary (niche areas like numerical computation being exceptions).
>> 
>> Maybe C99 is as yet unknown to many C programmers?
> 
> Well, I can't speak for the "unwashed masses" of C/C++/Win32 programmers;
> I wouldn't expect my own experience to necessarily be the same.  But *I*
> am certainly aware of C99; and personally, I haven't met any C programmers
> who are not aware of C99.

Being aware is one thing, but do they actually know what is inside?

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Martin Krischik]

Georg Bauhaus wrote:

> Benjamin Ketcham <bketcham@drizzle.com> wrote:
> : 
> : The fact that C99 has not caught on would seem to indicate that
> : the market considers it *less* useful, not more!  The de facto
> : industry standard is "C90 plus the common extensions", and there it
> : remains.  I guess the C programmers didn't want their language to
> : go down the path of the "RM".  Or, they just don't see it as
> : necessary (niche areas like numerical computation being exceptions).
> 
> Maybe C99 is as yet unknown to many C programmers?

True. I am the only person I know of who spend the $18 to actually buy the
standart (both C and C++). I also not aware of anyone who own a pirate
copy.

I know of a company who has several hundreds of programmers who owns a fully
licensed network copy of both the C and C++ standart accesable to everybody
there. I have has contracts for 8 years with that company - I know of no
one who read only one page of the any of the standarts.

The hole mentality of C/C++ programmers is just different. They spend so
much time with the a debugger they don't have time to read standards.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Martin Krischik wrote:
> The hole mentality of C/C++ programmers is just different. They spend so
> much time with the a debugger they don't have time to read standards.

It will probably not surprise you that I own the C and C++ standards,
including the 2003 revision of the latter, and refer to them constantly.

By the way, did you know that the C++ standard contains a hidden limerick?
Look at 14.7.3/7.

Re: ADA Popularity Discussion Request

[Kevin Cline]

Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1153993.mxNGp3fqa3@linux1.krischik.com>...

> The hole mentality of C/C++ programmers is just different. They spend so
> much time with the a debugger they don't have time to read standards.

I have read the C++ standard almost entirely.  But it's true,
aficionados
of niche languages are better read than the average developer. 
Average developers learn about one language in school, usually the
most popular language of the time.  Then they find a position working
in that language, and don't learn another until forced to by the
market.  Great developers know a lot of languages, and pick one
appropriate for the job.  Still, not many of them seem to be picking
Ada.

Re: ADA Popularity Discussion Request

[Larry Kilgallen]

In article <1094926196.802462@yasure>, Benjamin Ketcham <bketcham@drizzle.com> writes:

> K&R C can be criticized on many grounds, but "useful" is not
> a valid one, IMO.  The original C was one of the most "useful"
> languages we've seen.  Witness its rapid spread through
> academia,

That was because of the low cost of the Unix/C combination to academia.

> and later, industry.

That was because of the supply of academia-trained people accustomed to C.

Re: ADA Popularity Discussion Request

[Benjamin Ketcham]

Larry Kilgallen <Kilgallen@spamcop.net> wrote:
> In article <1094926196.802462@yasure>, Benjamin Ketcham <bketcham@drizzle.com> writes:
> 
>> K&R C can be criticized on many grounds, but "useful" is not
>> a valid one, IMO.  The original C was one of the most "useful"
>> languages we've seen.  Witness its rapid spread through
>> academia,
> 
> That was because of the low cost of the Unix/C combination to academia.

Yes, exactly.  Nothing makes a tool useful like *accessibility*.
Low cost plus source code equals accessible.

>> and later, industry.
> 
> That was because of the supply of academia-trained people accustomed to C.

Absolutely.  Ye olde positive feedback, aka snowball effect (as opposed
to SNOBOL).  Tools that are more useful, get used more, therefore more
people end up knowing how to use them, and of course a large user base
only makes the tool... yes, more useful.  OK, I think the horse is dead.

Re: ADA Popularity Discussion Request

[Pascal Obry]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> That was because of the low cost of the Unix/C combination to academia.

Wasn't this also because it was quite better than the assembler ? Was there
many other choices ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ADA Popularity Discussion Request

[Marius Amado Alves]

>>K&R C can be criticized on many grounds, but "useful" is not
>>a valid one, IMO.  The original C was one of the most "useful"
>>languages we've seen.  Witness its rapid spread through
>>academia,
> 
> That was because of the low cost of the Unix/C combination to academia.

FWIW, I believe the main factor of C success was (is) the simplicity of 
its semantics. It equates the machine. For this reason--and this 
alone--I find C actually very pedagogical. It's very easy to understand 
C given knowledge of the computer architecture, and vice-versa--and both 
ways at the same time. And C does not get in the way. (A hand grenade, I 
know.)

/* I remember reading K&R as a tutorial, and loving it, and finding it
superior to the few languages I had used (BASIC, Clipper...) and learnt
(COBOL) before. This was in the early 1980's. I had no idea of the
existence of Ada (or Algol, or Simula, but I knew Pascal, and Prolog) 
then. There was no Internet.  And I was not in any University (not that 
I believe this would have helped much). If had been thrown Ada in front 
of me by then I'd probably be a different person today. So I adopted C 
in the early 1980's, used it professionally, and experienced many 
problems (no surprise here now). Until I was indeed acquainted with Ada 
95 in the mid 1990's, in a postgraduation at FCTUNL. I tried it and 
experienced orders of magnitude decrease in debbugging time. And 
increase in correcteness, reliability, etc. So now I'm married to Ada, 
but C was my first love. */

Re: ADA Popularity Discussion Request

[Larry Kilgallen]

In article <u656j9b5t.fsf@obry.org>, Pascal Obry <pascal@obry.org> writes:
> 
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> 
>> That was because of the low cost of the Unix/C combination to academia.
> 
> Wasn't this also because it was quite better than the assembler ? Was there
> many other choices ?

There were _many_ other languages.  What distinguished C was economic,
drawn not out of generosity but out of US Federal restrictions on the
activities of AT&T subsidiary Bell Labs.

Re: ADA Popularity Discussion Request

[Alexander E. Kopilovich]

Larry Kilgallen wrote:

> >> That was because of the low cost of the Unix/C combination to academia.
> > 
> > Wasn't this also because it was quite better than the assembler ? Was there
> > many other choices ?
>
> There were _many_ other languages.  What distinguished C was economic,
> drawn not out of generosity but out of US Federal restrictions on the
> activities of AT&T subsidiary Bell Labs.

Well, this explains why many common hindrances weren't applied to C.
But this isn't enough for success of such a scale. Some powerful drive,
some important internal qualities are necessary for that.

And I think, that being far from a fan of C (I really never liked it,
although I was forced to use it along with C++ - in last decade perhaps more
than any other programming language), I still see those important internal
qualities of C. There are two of them:

1) fundamentally sound abstract model, around which the language is built -
finite automata;

2) very good balance between various aspects of a practical programming
language, including careful placement of the underlying abstract model
under the hood of a set of (flavors of) already familiar (to the programming
community) constructs; no one of those aspects reached perfection in C, but
that was (and is) the balance that determines success for massive and diverse
use of general-purpose programming language.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: ADA Popularity Discussion Request

[Marin David Condic]

A lesson that ought not go lost on those who wish Ada greater success. 
Even a flawed and imperfect language can have great success if the 
economics are right. There may be droves of Ada-haters or Ada-ignorers 
out there, but if Ada has overwhelming economic advantage, the 
bean-counters will "tune them up" and get them to "think right" on the 
subject. So we ought to pay a little less attention to Ada's technical 
superiority and more to making it economically superior.

MDC

Larry Kilgallen wrote:
> 
> There were _many_ other languages.  What distinguished C was economic,
> drawn not out of generosity but out of US Federal restrictions on the
> activities of AT&T subsidiary Bell Labs.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Power corrupts.  Absolute power is kind of neat"
         -- John Lehman, Secretary of the Navy 1981-1987
======================================================================

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Sun, 12 Sep 2004 21:21:16 GMT, Marin David Condic wrote:

> A lesson that ought not go lost on those who wish Ada greater success. 
> Even a flawed and imperfect language can have great success if the 
> economics are right.

But what is the goal, perfection or commercial success?
Does one exclude other?
Something should be badly wrong with our world, if so...

> There may be droves of Ada-haters or Ada-ignorers 
> out there, but if Ada has overwhelming economic advantage, the 
> bean-counters will "tune them up" and get them to "think right" on the 
> subject. So we ought to pay a little less attention to Ada's technical 
> superiority and more to making it economically superior.

Would you like such language? (:-))

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

Re: ADA Popularity Discussion Request

[Marin David Condic]

Where did I say it had to be one way or the other? Is the premise that 
only lousy products can be commercial successes? I disagree with that. 
What I suggest is that Ada enthusiasts attempt to understand the 
*economics* of programming languages and make Ada more attractive from 
an *economic* perspective.

MDC

Dmitry A. Kazakov wrote:
> On Sun, 12 Sep 2004 21:21:16 GMT, Marin David Condic wrote:
> 
> 
>>A lesson that ought not go lost on those who wish Ada greater success. 
>>Even a flawed and imperfect language can have great success if the 
>>economics are right.
> 
> 
> But what is the goal, perfection or commercial success?
> Does one exclude other?
> Something should be badly wrong with our world, if so...
> 
> 
>>There may be droves of Ada-haters or Ada-ignorers 
>>out there, but if Ada has overwhelming economic advantage, the 
>>bean-counters will "tune them up" and get them to "think right" on the 
>>subject. So we ought to pay a little less attention to Ada's technical 
>>superiority and more to making it economically superior.
> 
> 
> Would you like such language? (:-))
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Power corrupts.  Absolute power is kind of neat"
         -- John Lehman, Secretary of the Navy 1981-1987
======================================================================

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Wed, 15 Sep 2004 20:45:42 GMT, Marin David Condic wrote:

> Where did I say it had to be one way or the other?

You didn't. But I have an impression that it is the law of supply and
demand.

> Is the premise that 
> only lousy products can be commercial successes?

It seems much so. Or better to say, that quality of any kind plays very
little role.

> I disagree with that.

Yes, to keep on use Ada one should indeed disagree... (:-))

> What I suggest is that Ada enthusiasts attempt to understand the 
> *economics* of programming languages and make Ada more attractive from 
> an *economic* perspective.

You are right. The problem is that all our understanding seems to fall
under either: a) everything is perfect we just need $2**10 for an Ada
promotion campaign. b) everything is better than perfect, we just need to
rewrite STL, AWS, MS-Word in Ada.

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

Re: ADA Popularity Discussion Request

[Pascal Obry]

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

> You are right. The problem is that all our understanding seems to fall
> under either: a) everything is perfect we just need $2**10 for an Ada
> promotion campaign. b) everything is better than perfect, we just need to
> rewrite STL, AWS, MS-Word in Ada.

Rewrite AWS in Ada ??? I think you meant something else!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On 16 Sep 2004 20:45:58 +0200, Pascal Obry wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> You are right. The problem is that all our understanding seems to fall
>> under either: a) everything is perfect we just need $2**10 for an Ada
>> promotion campaign. b) everything is better than perfect, we just need to
>> rewrite STL, AWS, MS-Word in Ada.
> 
> Rewrite AWS in Ada ??? I think you meant something else!

Amazon Web Services. Should I say GPS? But never mind! (:-))

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

Re: ADA Popularity Discussion Request

[Larry Kilgallen]

In article <mailman.16.1095009448.390.comp.lang.ada@ada-france.org>, Marius Amado Alves <amado.alves@netcabo.pt> writes:
> 
>>>K&R C can be criticized on many grounds, but "useful" is not
>>>a valid one, IMO.  The original C was one of the most "useful"
>>>languages we've seen.  Witness its rapid spread through
>>>academia,
>> 
>> That was because of the low cost of the Unix/C combination to academia.
> 
> FWIW, I believe the main factor of C success was (is) the simplicity of 
> its semantics.

It is certainly no simpler than Bliss, but much more popular.

Re: ADA Popularity Discussion Request

[Marius Amado Alves]

>>FWIW, I believe the main factor of C success was (is) the simplicity of 
>>its semantics.
> 
> It is certainly no simpler than Bliss, but much more popular.

C is simpler. At least with respect to compilation. In the success of C 
vs. Bliss, price also played a role. But I suspect this was tied to the 
difficulty of making a compiler. (Bliss high, C low.) Ada also suffered 
from this. Ada 83 at least.

Re: ADA Popularity Discussion Request

[Kevin Cline]

Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1371289.WCcgO7lass@linux1.krischik.com>...
> Kevin Cline wrote:
> 
> > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
> > news:<choh37$8i9$1@a1-hrz.uni-duisburg.de>...
> >> Kevin Cline <kevin.cline@gmail.com> wrote:
> >> : If you want bounded types in C++ it's easy enough to write a template
> >> : class:
> >> 
> >> True, but it is not quite the same thing, is it? You can write bounded
> >> types in C. Yet, they don't become C language types, with ISO definded
> >> semantics beyond what you'd expect for any user defined type.
> > 
> > The Ada designers evidently thought arrays were really really
> > important, because they provided elaborate language facilities to
> > support array-based programming.  The C language designers instead
> > created a small but useful language.
> 
> K&C was not at all usefull. 

It was far from perfect, but a huge fraction of the applications in
use today were written in C.  There can be no question that C was
useful.

> Almost imediatly "lint" appeared to save you
> from all the pitfalls C hat.

So what?  That's like complaining that grep is flawed because it
doesn't paginate its output.  K&R did not set out to design the
ultimate programming language.  They designed a language that was
useful to their team.  AFAIK, C was basically designed to replace
PDP-11 assembly language.  It did that pretty well, and facilitated
the development of the first portable operating system.  Then some
other people came along and decided that they would like to program in
C too, and got the compiler from AT&T.

> 
> Of corse C has become more usefull But as a result it is not small anymore.
> The ISO/IEC 9899:1999 is just as big as the RM but mor difficult to read.
> And I am not aware of any compiler which supports the standard in full.
> 
> 
> > Stroustrup didn't spend much 
> > effort on arrays, perhaps because he didn't think they were so
> > important.
> 
> Since I do own the ISO/IEC 9899:1999 I have one to swallow for your
> (6.7.5.2, Page 117):
> 
> extern int n;
> extern int m;
> void fcompat (void)
> {
>         int a[n][6][m];
> 
> And next page it becomes even cooler:
> 
> void fvla (int m; int C[m][m]);
> 
> void fvla (int m; int C[m][m]);
> {
>         typedef int VLA[m][m];
>         ...
>         int D[m];
> 
> It looks like the C comunity have finaly found out that K&R and Stroustrup 
> have bee wrong and arrays with bounds are important after all.

I don't program in C anymore, so I haven't paid much attention to the
1999 standard.  Almost certainly K&R left out that feature because it
means that the offset to local variables in the stack frame is no
longer a compile-time constant.

> 
> > Instead he tried to make it easy to define and use new 
> > types as easily as one could use the fundamental types.
> > 
> >> Does the C++ standard directly address the behavior of handwritten
> >> bounded numbers? How many lines of template code will it take
> >> to get the effect of
> >> 
> >>   type A is array(Some_Index_Type) of Foo;?
> > 
> > I don't know.
> 
> But I do:
> 
> >wc --lines AdaArray.C AdaArray.H
>      95 AdaArray.C
>     467 AdaArray.H
>     562 insgesamt

Great.  Now, if I ever want an Ada-style array for C++, I know what to
look for.
I don't care if a feature is built into the compiler or comes from
library code.
That was a conscious decision by the C++ community -- don't put
something in the language if writing a class will do just as well.

I expect that most of Ada's features could be implemented as C++
library code.
But what do I do when I need the power of C++ templates in Ada?

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
: I expect that most of Ada's features could be implemented as C++
: library code.

Are you saying that one should compare the benefits of ISO
standardised languages and feature semantics by referring to which
features could be implemented in libraries? What if the Ada fans
start talking about what is possible with ASIS (which might render
C++ template computing a poor thing)?

: But what do I do when I need the power of C++ templates in Ada?

It seems that now that the power of C++ templates has been discovered, 
hardly anyone can live without this power. One might ask how programming
problems have been solved in C++ when there was no bag of template
tricks?
 OTOH, given the quality of error messages that compilers issue for
template code, why not employ a Lisp style processor that in addition
to delivering C++ code also displays error messages that do not need
template error message code analysis? :-)


-- Georg

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Georg Bauhaus wrote:
 > One might ask how programming problems have been solved in C++
 > when there was no bag of template tricks?

One way was the old header "generic.h" which was a poor-man's
template mechanism, using the preprocessor to interpolate type
names into code.

Re: ADA Popularity Discussion Request

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<ci41fg$2ge$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> It seems that now that the power of C++ templates has been discovered, 
> hardly anyone can live without this power. One might ask how programming
> problems have been solved in C++ when there was no bag of template
> tricks?

Templates appeared pretty early in C++, and solved a lot of problems
that used to be solved in C with preprocessor macros.  Template
specialization and template member functions came later.

>  OTOH, given the quality of error messages that compilers issue for
> template code, why not employ a Lisp style processor that in addition
> to delivering C++ code also displays error messages that do not need
> template error message code analysis? :-)

This is indeed a serious problem, and people are working on it.  I
don't think it's particular to C++ templates.  Any interesting
facility that generates code will have the same issues to some degree.

Re: ADA Popularity Discussion Request

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<ci41fg$2ge$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> : I expect that most of Ada's features could be implemented as C++
> : library code.
> 
> Are you saying that one should compare the benefits of ISO
> standardised languages and feature semantics by referring to which
> features could be implemented in libraries? What if the Ada fans
> start talking about what is possible with ASIS (which might render
> C++ template computing a poor thing)?

They should do that.  It might make Ada more popular.  I found what
appears to be the ASIS home page at http://www.
gnat.com/addons_asis.php.  It mentions using ASIS to support run-time
type reflection, but says nothing about using ASIS for generative
programming.  That seems like a stretch for ASIS, it is basically a
hookable Ada parser, but to get better support for generative
programming you'll need to extend the language somehow.

Re: ADA Popularity Discussion Request

[Larry Kilgallen]

In article <mailman.24.1095085542.390.comp.lang.ada@ada-france.org>, Marius Amado Alves <amado.alves@netcabo.pt> writes:
>>>FWIW, I believe the main factor of C success was (is) the simplicity of 
>>>its semantics.
>> 
>> It is certainly no simpler than Bliss, but much more popular.
> 
> C is simpler. At least with respect to compilation.

Presuming you mean simplicity of compiler design, that is irrelevant
to the belief statement, which was "simplicity of its semantics".

Re: ADA Popularity Discussion Request

[Marius Amado Alves]

>>>>FWIW, I believe the main factor of C success was (is) the simplicity of 
>>>>its semantics.
>>>It is certainly no simpler than Bliss, but much more popular.
>>C is simpler. At least with respect to compilation.
> Presuming you mean simplicity of compiler design, that is irrelevant
> to the belief statement, which was "simplicity of its semantics".

I meant what I said, simplicity of its semantics. Which has multiple 
effects. Cognitive, which I discussed in first place. But clearly it has 
also consequences on compiler development--and pricing. Which I 
discussed secondly, simply because it occurred to me while investigating 
whether Bliss was as simple as C, as (incorrectly) stated.

Re: ADA Popularity Discussion Request

[David Gay]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> In article <mailman.24.1095085542.390.comp.lang.ada@ada-france.org>, Marius Amado Alves <amado.alves@netcabo.pt> writes:
> >>>FWIW, I believe the main factor of C success was (is) the simplicity of 
> >>>its semantics.
> >> 
> >> It is certainly no simpler than Bliss, but much more popular.
> > 
> > C is simpler. At least with respect to compilation.
> 
> Presuming you mean simplicity of compiler design, that is irrelevant
> to the belief statement, which was "simplicity of its semantics".

I disagree completely. Without any other information, I would always assume
that a language with simpler semantics would have a simpler compiler. Hence, 
a simpler compiler is a reasonable indicator of simpler semantics. This is, 
of course, not a direct link, as some semantic concepts might be harder to
implement on actual hardware, but claiming there is no link is clearly wrong.

-- 
David Gay
dgay@acm.org

Re: ADA Popularity Discussion Request

[Pascal Obry]

kevin.cline@gmail.com (Kevin Cline) writes:

> > Does the C++ standard directly address the behavior of handwritten
> > bounded numbers? How many lines of template code will it take
> > to get the effect of
> > 
> >   type A is array(Some_Index_Type) of Foo;?
> 
> I don't know.  It could be done in C++ if Some_Index_Type had the
> right properties.  But as a practical matter, no one seems to care, at
> least no one in the C++ community.  I very rarely have any need or use
> for a statically sized array.  

That's why working with strings in C/C++ is a nightmare! strcpy/strcat,++,--
and so on... Look at some real world C/C++ code handling strings !

For memory, a string in Ada is:

   type String is array (Positive range <>) of Character;

And you can do something like:

   function Some_Value return String is
   begin
      return "...";
   end Some_Value;

   S1 : constant String := "a long string";
   S2 : constant String := "this is definitly " & S1 & Some_Value;

   S3 : constant String := S1 (S1'First + 2 .. S1'First + 5);

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Pascal Obry wrote:
> That's why working with strings in C/C++ is a nightmare! strcpy/strcat,++,--
> and so on... Look at some real world C/C++ code handling strings !
> 
> For memory, a string in Ada is:
> 
>    type String is array (Positive range <>) of Character;
> 
> And you can do something like:
> 
>    function Some_Value return String is
>    begin
>       return "...";
>    end Some_Value;
> 
>    S1 : constant String := "a long string";
>    S2 : constant String := "this is definitly " & S1 & Some_Value;
> 
>    S3 : constant String := S1 (S1'First + 2 .. S1'First + 5);

I'm puzzled. Your Ada code translates line-for-line into C++:

     #include <string>
     std::string sv() { return "..."; }
     int main()
     {
         std::string const s1("a long string");
         std::string const s2("this is definitly " + s1 + sv());
         std::string const s3(s1.begin() + 2, s1.begin() + 5 + 1);
     }

Granted that the C++ code is using the equivalent of Ada's unbounded_string,
I'd hardly call this a nightmare.

Re: ADA Popularity Discussion Request

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> > For memory, a string in Ada is:
> >    type String is array (Positive range <>) of Character;
> > And you can do something like:
> >    function Some_Value return String is
> >    begin
> >       return "...";
> >    end Some_Value;
> >    S1 : constant String := "a long string";
> >    S2 : constant String := "this is definitly " & S1 & Some_Value;
> >    S3 : constant String := S1 (S1'First + 2 .. S1'First + 5);
> 
> I'm puzzled. Your Ada code translates line-for-line into C++:

That's wrong ! You are using a class/library. We are speaking of the
language here ! I find stange that people have a lot of problem separating
both. It is true that even in assembler we can build a library to work with
string... After all everything is translated into assembler!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Pascal Obry wrote:
> That's wrong ! You are using a class/library. We are speaking of the
> language here !

std::string is part of C++. You said "working with strings in C/C++ is
a nightmare...Look at some real world C/C++ code handling strings". I
demonstrated that your standard Ada code translates directly into standard
C++ code. Now that you see this, you are trying to manipulate your original
statements so as to avoid the uncomfortable truth.

Re: ADA Popularity Discussion Request

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> you are trying to manipulate your original
> statements so as to avoid the uncomfortable truth.

Certainly not but if you feel like having the final word !

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Pascal Obry wrote:
> Certainly not but if you feel like having the final word !

Oops, you're right, I apologize. The context was about
arrays in Ada vs. C. It's still meaningful though, that
you're code did translate so directly to C++. And Ada
users always have trouble with ragged arrays of strings,
precisely because of the way arrays work in Ada.

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Hyman Rosen wrote:
> you're

Sigh. "Your", of course. I'm groggy from my root canal
pain meds.

Re: ADA Popularity Discussion Request

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> you're code did translate so directly to C++. And Ada
> users always have trouble with ragged arrays of strings,

That's right and this is I hope something that will be part of a
future standard.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ADA Popularity Discussion Request

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> Granted that the C++ code is using the equivalent of Ada's unbounded_string,

And is quite different beast than :

   type String is array (Positive range <>) of Character;

> I'd hardly call this a nightmare.

You can't have C++ strings object everyware. A lot of function are built using
char* in the spec.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ADA Popularity Discussion Request

[Brian May]

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

    Pascal> You can't have C++ strings object everyware. A lot of
    Pascal> function are built using char* in the spec.

You can always use the string::c_str() function...

Actually, I don't know what overheads, if any, that might impose.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Pascal Obry wrote:
> You can't have C++ strings object everyware. A lot of function are built using
> char* in the spec.

In which case you do your work in std::string or std::stringstream and then
obtain a char * from the object and use it.

Re: ADA Popularity Discussion Request

[Dale Stanbrough]

Hyman Rosen <hyrosen@mail.com> wrote:

> Pascal Obry wrote:
> > You can't have C++ strings object everyware. A lot of function are built 
> > using
> > char* in the spec.
> 
> In which case you do your work in std::string or std::stringstream and then
> obtain a char * from the object and use it.

Also ACT have equipped a child package of Unbounded_String to return
a pointer to the underlying string. This makes C++ and Ada look more
alike.

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Mon, 13 Sep 2004 06:19:03 GMT, Dale Stanbrough wrote:

> Hyman Rosen <hyrosen@mail.com> wrote:
> 
>> Pascal Obry wrote:
>>> You can't have C++ strings object everyware. A lot of function are built 
>>> using
>>> char* in the spec.
>> 
>> In which case you do your work in std::string or std::stringstream and then
>> obtain a char * from the object and use it.
> 
> Also ACT have equipped a child package of Unbounded_String to return
> a pointer to the underlying string. This makes C++ and Ada look more
> alike.

...in their incorrectness

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

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> ...in their incorrectness

That's a silly comment. If you must deal with interfaces
which take const char *, then using a pointer from a string
is a perfectly reasonable approach, letting you use the
string mechanisms until the last moment where you actually
invoke the interface. It may not be the ideal design that
you would choose if starting from scratch, but it is not
"incorrect".

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Mon, 13 Sep 2004 09:35:21 -0400, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> ...in their incorrectness
> 
> That's a silly comment. If you must deal with interfaces
> which take const char *, then using a pointer from a string
> is a perfectly reasonable approach, letting you use the
> string mechanisms until the last moment where you actually
> invoke the interface.

There should be no char* (pointers) at all, that's for C++. For Ada, all
string types should be related types.

> It may not be the ideal design that
> you would choose if starting from scratch, but it is not
> "incorrect".

OK, I take this word back. Read it as "utter imperfectness"! (:-))

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

Re: ADA Popularity Discussion Request

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> There should be no char* (pointers) at all, that's for C++. For Ada, all
> string types should be related types.

I assume that the pointer thing in Ada was added so that Ada code could
more easily access C/C++ interfaces which want char *. You might still
want pointers in Ada so you can do ragged string arrays, like the C
     char *x[] = { "1", "12", "123" };

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Mon, 13 Sep 2004 11:51:05 -0400, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> There should be no char* (pointers) at all, that's for C++. For Ada, all
>> string types should be related types.
> 
> I assume that the pointer thing in Ada was added so that Ada code could
> more easily access C/C++ interfaces which want char *.

Then that should be Interfaces.C.Strings.chars_ptr. I suppose that the
intention was a kind of ersatz to To_String.

> You might still
> want pointers in Ada so you can do ragged string arrays, like the C
>      char *x[] = { "1", "12", "123" };

This is why I wrote about incorrectness. IF Ada's strings were designed as
a set of related types, then "..." literals could be ones of/convertible to
Unbounded_String and so an initialized ragged array would be no problem,
instead of horrific:

type Ragged is array (Integer range <>) of Unbounded_String;
X : constant Ragged :=
    (  To_Unbounded_String ("1"),
       To_Unbounded_String ("12"),
       To_Unbounded_String ("13")
    );

Pascal's lessons still to be learned. Bounds, whatever static, bound or
dynamic should not be a part of the string type!

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

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: This is why I wrote about incorrectness. IF Ada's strings were designed as
: a set of related types, then "..." literals could be ones of/convertible to
: Unbounded_String and so an initialized ragged array would be no problem,
: instead of horrific:
: 
: type Ragged is array (Integer range <>) of Unbounded_String;
: X : constant Ragged :=
:    (  To_Unbounded_String ("1"),
:       To_Unbounded_String ("12"),
:       To_Unbounded_String ("13")
:    );

Is it really a good idea to sprinkle source code with unnamed
string values? (No matter in what language.) If all of them are
isolated in some module(s), where's the problem. Is it an
aesthetical problem to have to use Ada's verbosity with strings?


-- Georg

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Tue, 14 Sep 2004 09:07:18 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: This is why I wrote about incorrectness. IF Ada's strings were designed as
>: a set of related types, then "..." literals could be ones of/convertible to
>: Unbounded_String and so an initialized ragged array would be no problem,
>: instead of horrific:
>: 
>: type Ragged is array (Integer range <>) of Unbounded_String;
>: X : constant Ragged :=
>:    (  To_Unbounded_String ("1"),
>:       To_Unbounded_String ("12"),
>:       To_Unbounded_String ("13")
>:    );
> 
> Is it really a good idea to sprinkle source code with unnamed
> string values?

It is a bad idea (provided that these values do not represent themselves.)

There is no difference to numeric literals with that respect. Yes, magic
constants are bad, but that by no means imply that universal integer should
to be removed and for each custom integer type we should write

X : My_Int := My_Int (1);

> (No matter in what language.) If all of them are
> isolated in some module(s), where's the problem.

The problem is a geometric explosion of interfaces in cases like:

procedure Connect
(DB : in out Data_Base; Server, Name, Password : String);

Now you have 3 string parameters each of them can separately be:
String, Wide_String, Unbounded.Unbounded_String,
Wide_Unbounded.Unbounded_String.

For the user point of view, what is the difference between String and
Unbounded_String to require explicit conversions between them? Isn't it an
implementation detail?

> Is it an
> aesthetical problem to have to use Ada's verbosity with strings?

With strings it becomes compelling. The problem is fundamental, Ada's
support of interface implementation is very rudimental. You cannot define
the interface of abstract characters and then the interface of an abstract
array of abstract characters. String, Unbounded_String, Wide_String etc are
just implementations of that interface. They should be just subtypes of a
Universal_String. And what will we do when Wide_Wide_String come?

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

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
 
:> (No matter in what language.) If all of them are
:> isolated in some module(s), where's the problem.
: 
: The problem is a geometric explosion of interfaces in cases like:
: 
: procedure Connect
: (DB : in out Data_Base; Server, Name, Password : String);

This is very much a procedure doing I/O. You cannot expect this to
work at an abstract level without hiding the outside world, can
you? And on the other hand, you have to serve the outside world
what it is expecting. If you use String values for the network
database connection credentials, what will be the interpretation
of of a Character value with 'pos > 127?  UTF-8? ISO-8859-1? Are
you connecting to DB2 on a mainframe?

To what extent is switching back and forth between Standard.String
and (Un)Bounded strings a problem? Where does it happen? Locally?
At I/O boundaries? If you store strings in one internal representation
in your program how many parameter profile variants will there be?

Would you also want a polymorhpic number type with automagic
conversion?


: For the user point of view, what is the difference between String and
: Unbounded_String to require explicit conversions between them? Isn't it an
: implementation detail?

The difference is the same as the difference between an array
of fixed size and a list. I guess that humans are more accustomed
to character lists than to something_else lists. Have you recently
read any complaints about fixed size arrays of something_else in
Ada?

:> Is it an
:> aesthetical problem to have to use Ada's verbosity with strings?
: 
: With strings it becomes compelling. The problem is fundamental, Ada's
: support of interface implementation is very rudimental. You cannot define
: the interface of abstract characters and then the interface of an abstract
: array of abstract characters.

Where would these abstract interfaces be useful?
Do you want to code convenient string conversion automagic to overcome
notions of what an array of characters is, in Ada? :-)

: And what will we do when Wide_Wide_String come?

Use it. When string memory and 32 bit instructions instead of
8 bit instructions is no concern, use it everywhere. :-)


-- Georg

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Tue, 14 Sep 2004 15:57:21 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>  
>:> (No matter in what language.) If all of them are
>:> isolated in some module(s), where's the problem.
>: 
>: The problem is a geometric explosion of interfaces in cases like:
>: 
>: procedure Connect
>: (DB : in out Data_Base; Server, Name, Password : String);
> 
> This is very much a procedure doing I/O. You cannot expect this to
> work at an abstract level without hiding the outside world, can
> you? And on the other hand, you have to serve the outside world
> what it is expecting. If you use String values for the network
> database connection credentials, what will be the interpretation
> of of a Character value with 'pos > 127?  UTF-8? ISO-8859-1? Are
> you connecting to DB2 on a mainframe?

Constraint_Error, if the data base cannot UNICODE. It is no different from:

procedure Foo (X : Positive);
...
Foo (-1);

Positive is a subtype of Integer. Integer is a "subtype" of
Universal_Integer. Conversion from the base to its subtype may raise
Constraint_Error. Wide_Character and Character are related in exactly same
manner as Integer and Positive.

> To what extent is switching back and forth between Standard.String
> and (Un)Bounded strings a problem? Where does it happen? Locally?
> At I/O boundaries? If you store strings in one internal representation
> in your program how many parameter profile variants will there be?

Look at Ada.Strings it is an example of how it explodes. Now consider, that
some day Ada will have a comprehensive library for building GUIs, text
processing, interfacing data bases etc. Should this library use: String,
Unbounded_String, Wide_String ...? Should it be generic, parametrized by a
string type. Which is BTW impossible too, because even at the level of
generics the least common ancestor of all Ada string types is "type Duno is
private"; So you have to specify all methods you might need in the library
a formal parameters!

> Would you also want a polymorhpic number type with automagic
> conversion?

It *IS* polymorphic. All numeric literals are overloaded [=statically
polymorphic.] But you probably meant other thing, which I will answer.

It seems that you are mixing types and subtypes. [IMO Ada's syntax of
extensible [tagged] types is quite misleading in that respect. They are in
fact subtypes, not distinct types.]

Different predefined string types should be subtypes, not unrelated types.
It is exactly the same case as Integer, Positive and Natural. That by no
means prevents us from creating distinct string types when we need it.
Compare:

type My_Int is new Integer; -- This a new type
X : My_Int  := Positive'(1); -- This an error!
Y : Integer := Positive'(1); -- This is OK!

Strings should work in exactly same way:

type My_String is new Unbounded_String; -- This a new type
X : My_String := String'("A"); -- This is illegal
Y : Unbounded_String := String'("A"); -- This should be legal

>: For the user point of view, what is the difference between String and
>: Unbounded_String to require explicit conversions between them? Isn't it an
>: implementation detail?
> 
> The difference is the same as the difference between an array
> of fixed size and a list. I guess that humans are more accustomed
> to character lists than to something_else lists. Have you recently
> read any complaints about fixed size arrays of something_else in
> Ada?

But all that is irrelevant for a user. What is important to him is the
interface: I can get an element by index, I can get a slice, I can
concatenate etc. How the compiler/library does the trick is interesting
only out of curiosity or when the performance is a big issue. 

>:> Is it an
>:> aesthetical problem to have to use Ada's verbosity with strings?
>: 
>: With strings it becomes compelling. The problem is fundamental, Ada's
>: support of interface implementation is very rudimental. You cannot define
>: the interface of abstract characters and then the interface of an abstract
>: array of abstract characters.
> 
> Where would these abstract interfaces be useful?

For developing class-wide/generic libraries.

> Do you want to code convenient string conversion automagic to overcome
> notions of what an array of characters is, in Ada? :-)

Yes. It is a way to have it. Type conversions A->B applied automatically,
promote B as subtype of A. I do not propose to do it in that chaotic PL/1
or limited C++ way. It should be Ada's way.

>: And what will we do when Wide_Wide_String come?
> 
> Use it. When string memory and 32 bit instructions instead of
> 8 bit instructions is no concern, use it everywhere. :-)

I do not want rain forests to disappear because of a need to print a dozen
copies of ARM 2050! (:-))

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

Re: ADA Popularity Discussion Request

[Martin Dowie]

Dmitry A. Kazakov wrote:
> Positive is a subtype of Integer. Integer is a "subtype" of
> Universal_Integer. Conversion from the base to its subtype may raise
> Constraint_Error. Wide_Character and Character are related in exactly
> same manner as Integer and Positive.

Why do you say that? Positive is defined in package "Standard" as a subtype.
Wide_Character and Character are defined in package "Standard" as difference
"type"-s.

-- Martin

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Wed, 15 Sep 2004 10:30:00 +0100, Martin Dowie wrote:

> Dmitry A. Kazakov wrote:
>> Positive is a subtype of Integer. Integer is a "subtype" of
>> Universal_Integer. Conversion from the base to its subtype may raise
>> Constraint_Error. Wide_Character and Character are related in exactly
>> same manner as Integer and Positive.
> 
> Why do you say that? Positive is defined in package "Standard" as a subtype.
> Wide_Character and Character are defined in package "Standard" as difference
> "type"-s.

Yes, that is my point. It is illogical that they are declared as unrelated
types. One should be a subtype of another. Semantically there is no
difference. Clearly there is a huge technical difference, because Ada 83
requires same representations for S, T and T'Base. Once this limitation
lifted it will be possible either to extend Character enumeration to
Wide_Character, or to constrain Wide_Character to Character, keeping their
T'Size different.

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

Re: ADA Popularity Discussion Request

[Martin Krischik]

Dmitry A. Kazakov wrote:

> Should it be generic, parametrized by a
> string type. Which is BTW impossible too, because even at the level of
> generics the least common ancestor of all Ada string types is "type Duno
> is private";

I think you have not worked enough with generics.

generic

   type Character_Type is (<>);

   type String_Type is array (Positive range <>) of Character_Type;

package Some_Generic_String_Operations


But there is a problem of course: Unbounded_String is not a generic
instantiation. It really should have been:

package Unbounded_String
is new Generic_Unbounded_String (
   Character_Type => Character,
   String_Type => String);

package Wide_Unbounded_String
is new Generic_Unbounded_String (
   Character_Type => Wide_Character,
   String_Type => Wide_String);

And sadly it is to late for that.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Wed, 15 Sep 2004 12:14:31 +0200, Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>> Should it be generic, parametrized by a
>> string type. Which is BTW impossible too, because even at the level of
>> generics the least common ancestor of all Ada string types is "type Duno
>> is private";
> 
> I think you have not worked enough with generics.
> 
> generic
> 
>    type Character_Type is (<>);
> 
>    type String_Type is array (Positive range <>) of Character_Type;
> 
> package Some_Generic_String_Operations
>
> But there is a problem of course: Unbounded_String is not a generic
> instantiation. It really should have been:
> 
> package Unbounded_String
> is new Generic_Unbounded_String (
>    Character_Type => Character,
>    String_Type => String);
> 
> package Wide_Unbounded_String
> is new Generic_Unbounded_String (
>    Character_Type => Wide_Character,
>    String_Type => Wide_String);

They couldn't do it, because of ranges/slices/attributes. They are not
first class citizens, alas.

Then it could be:

generic -- This is not Ada!
   type Index_Type is (<>);
   type Index_Range_Type is range of Index_Type;
   type Element_Type is private;
   type Array_Type is
      array (Index_Type range Index_Range_Type)
         of Element_Type;
package Abstract_Array is ...

Anyway, an equivalent, but more straightforward way is just to make
Unbounded_String matching

   type String_Type is array (Positive range <>) of Character_Type;

Once, you solved the problem of wired slices and attributes, the rest will
be easy.

> And sadly it is to late for that.

Not at all. Solve the above and add supertypes. That will do the trick. You
create a common array ancestor *afterwards* and everybody is happy.

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

Re: ADA Popularity Discussion Request

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<ci6cc6$9br$2@a1-hrz.uni-duisburg.de>...
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> : This is why I wrote about incorrectness. IF Ada's strings were designed as
> : a set of related types, then "..." literals could be ones of/convertible to
> : Unbounded_String and so an initialized ragged array would be no problem,
> : instead of horrific:
> : 
> : type Ragged is array (Integer range <>) of Unbounded_String;
> : X : constant Ragged :=
> :    (  To_Unbounded_String ("1"),
> :       To_Unbounded_String ("12"),
> :       To_Unbounded_String ("13")
> :    );
> 
> Is it really a good idea to sprinkle source code with unnamed
> string values? (No matter in what language.) If all of them are
> isolated in some module(s), where's the problem. Is it an
> aesthetical problem to have to use Ada's verbosity with strings?

It is a bit of a problem.  Just like natural language composition,
there's a fine line between too brief, too verbose, and just right. 
In the table above, the interesting parts are X and "1", "12", and
"123".  The three repetitions of To_Unbounded_String take up most of
the text while saying nothing of interest, and could be left out if
Ada supported implicit conversions at all.  Perhaps Ada's prohibition
of implicit conversions was a reaction to the problems they caused in
FORTRAN and C programming.  No doubt that FORTRAN and C got implicit
conversions mostly wrong, but that doesn't mean that they are always
bad.  It's pretty obvious what it means to convert "1" to an unbounded
string.

BTW, the code above will also use memory inefficiently since there
will be two copies of each string, one constant and one unbounded.

C++ is as bad or worse if you want to initialize a
vector<std::string>, but is better if you are OK with:
    char const * const x[] = { "1", "12", "123" };

Re: ADA Popularity Discussion Request

[Martin Krischik]

Kevin Cline wrote:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
> news:<ci6cc6$9br$2@a1-hrz.uni-duisburg.de>...
>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> : This is why I wrote about incorrectness. IF Ada's strings were designed
>> : as a set of related types, then "..." literals could be ones
>> : of/convertible to Unbounded_String and so an initialized ragged array
>> : would be no problem, instead of horrific:
>> : 
>> : type Ragged is array (Integer range <>) of Unbounded_String;
>> : X : constant Ragged :=
>> :    (  To_Unbounded_String ("1"),
>> :       To_Unbounded_String ("12"),
>> :       To_Unbounded_String ("13")
>> :    );
>> 
>> Is it really a good idea to sprinkle source code with unnamed
>> string values? (No matter in what language.) If all of them are
>> isolated in some module(s), where's the problem. Is it an
>> aesthetical problem to have to use Ada's verbosity with strings?

> BTW, the code above will also use memory inefficiently since there
> will be two copies of each string, one constant and one unbounded.

Now that you say it: True. Mind you, if space is a problem, you can always
do it the C way:

String_1  : aliased String = "1";
String_12 : aliased String = "12";
String_13 : aliased String = "13";

type String_Access  is access all String;
type Ragged is array (Integer range <>) of String_Access;
X : constant Ragged :=
    (  String_1'Access,
       String_12'Access,
       String_13'Access
    );
 
Of corse, it does not win a price with being compact code - but it does work
with contrained records as well.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
 
: Now that you say it: True. Mind you, if space is a problem, you can always
: do it the C way:
: 
: String_1  : aliased String = "1";
: String_12 : aliased String = "12";
: String_13 : aliased String = "13";
: 
: type String_Access  is access all String;
: type Ragged is array (Integer range <>) of String_Access;
: X : constant Ragged :=
:    (  String_1'Access,
:       String_12'Access,
:       String_13'Access
:    );

for constants,

   X: constant Ragged := 
    ( new String'("1"),
    ...

does just as well, the allocations are performed by the compiler,
not at run time :-)



-- Georg

Re: ADA Popularity Discussion Request

[Martin Krischik]

Georg Bauhaus wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
>  
> : Now that you say it: True. Mind you, if space is a problem, you can
> : always do it the C way:
> : 
> : String_1  : aliased String = "1";
> : String_12 : aliased String = "12";
> : String_13 : aliased String = "13";
> : 
> : type String_Access  is access all String;
> : type Ragged is array (Integer range <>) of String_Access;
> : X : constant Ragged :=
> :    (  String_1'Access,
> :       String_12'Access,
> :       String_13'Access
> :    );
> 
> for constants,
> 
>    X: constant Ragged :=
>     ( new String'("1"),
>     ...
> 
> does just as well, the allocations are performed by the compiler,
> not at run time :-)

Really! I did not know that! Where does it say in the RM - or is a compiler
dependent optimisation.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
:> for constants,
:> 
:>    X: constant Ragged :=
:>     ( new String'("1"),
:>     ...
:> 
:> does just as well, the allocations are performed by the compiler,
:> not at run time :-)
: 
: Really! I did not know that! Where does it say in the RM - or is a compiler
: dependent optimisation.

I've found it to be true, and it looks like compatible with
"evaluation of an allocator" and elaboration (control, preelaborate?).
I don't know whether there is a sentence addressing this directly,
maybe the experts can tell?

Both ObjectAda and GNAT do this. I don't know whether it is at
all possible to intruct ObjectAda not to "preallocate" constant
string pointers.


-- Georg

Re: ADA Popularity Discussion Request

[Simon Wright]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
> :> for constants,
> :> 
> :>    X: constant Ragged :=
> :>     ( new String'("1"),
> :>     ...
> :> 
> :> does just as well, the allocations are performed by the compiler,
> :> not at run time :-)
> : 
> : Really! I did not know that! Where does it say in the RM - or is a compiler
> : dependent optimisation.
> 
> I've found it to be true, and it looks like compatible with
> "evaluation of an allocator" and elaboration (control, preelaborate?).
> I don't know whether there is a sentence addressing this directly,
> maybe the experts can tell?
> 
> Both ObjectAda and GNAT do this. I don't know whether it is at
> all possible to intruct ObjectAda not to "preallocate" constant
> string pointers.

This code

   package New_String is

      type String_P is access all String;
      S : constant String_P := new String'("foo!");

   end New_String;

with 5.02a1, x86 generates code including

   [...]
   new_string___elabs:
   [...]
           call	__gnat_malloc


I think you may be remembering

   package New_String is

      type String_P is access constant String;
      Foo : aliased constant String := "foo!";
      S : constant String_P := Foo'Access;

   end New_String;

which generates (in its entirety) with -O2

           .file	"new_string.ads"
   .globl new_string_E
           .data
           .type	new_string_E,@object
           .size	new_string_E,1
   new_string_E:
           .byte	0
   .globl new_string__foo
           .align 4
           .type	new_string__foo,@object
           .size	new_string__foo,12
   new_string__foo:
           .long	1
           .long	4
           .ascii	"foo!"
   .globl new_string__s
           .align 8
           .type	new_string__s,@object
           .size	new_string__s,8
   new_string__s:
           .long	new_string__foo+8
           .long	new_string__foo
           .ident	"GCC: (GNU) 3.2.3"


-- 
Simon Wright                               100% Ada, no bugs.

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Simon Wright <simon@pushface.org> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:> Both ObjectAda and GNAT do this. I don't know whether it is at
:> all possible to intruct ObjectAda not to "preallocate" constant
:> string pointers.
: 
: This code
: 
:   package New_String is
: 
:      type String_P is access all String;
:      S : constant String_P := new String'("foo!");
: 
:   end New_String;

If the pointers are to constant strings (I should have stressed
this) there is no call to __gnat_malloc. As is

      type String_P is access constant String;
      S : constant String_P := new String'("foo!");


-- Georg

Re: ADA Popularity Discussion Request

[Simon Wright]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> If the pointers are to constant strings (I should have stressed
> this) there is no call to __gnat_malloc. As is
> 
>       type String_P is access constant String;
>       S : constant String_P := new String'("foo!");

Wow! Thanks for that!

-- 
Simon Wright                               100% Ada, no bugs.

Re: ADA Popularity Discussion Request

[Martin Krischik]

Simon Wright wrote:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
> 
>> Martin Krischik <krischik@users.sourceforge.net> wrote:
>> :> for constants,
>> :> 
>> :>    X: constant Ragged :=
>> :>     ( new String'("1"),
>> :>     ...
>> :> 
>> :> does just as well, the allocations are performed by the compiler,
>> :> not at run time :-)
>> : 
>> : Really! I did not know that! Where does it say in the RM - or is a
>> : compiler dependent optimisation.
>> 
>> I've found it to be true, and it looks like compatible with
>> "evaluation of an allocator" and elaboration (control, preelaborate?).
>> I don't know whether there is a sentence addressing this directly,
>> maybe the experts can tell?
>> 
>> Both ObjectAda and GNAT do this. I don't know whether it is at
>> all possible to intruct ObjectAda not to "preallocate" constant
>> string pointers.
> 
> This code
> 
>    package New_String is
> 
>       type String_P is access all String;

Should it be not "access constant String".

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Randy Brukardt]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:2177491.OlAk1RxoCA@linux1.krischik.com...
> Georg Bauhaus wrote:
>
> > Martin Krischik <krischik@users.sourceforge.net> wrote:
> >
> > : Now that you say it: True. Mind you, if space is a problem, you can
> > : always do it the C way:
> > :
> > : String_1  : aliased String = "1";
> > : String_12 : aliased String = "12";
> > : String_13 : aliased String = "13";
> > :
> > : type String_Access  is access all String;
> > : type Ragged is array (Integer range <>) of String_Access;
> > : X : constant Ragged :=
> > :    (  String_1'Access,
> > :       String_12'Access,
> > :       String_13'Access
> > :    );
> >
> > for constants,
> >
> >    X: constant Ragged :=
> >     ( new String'("1"),
> >     ...
> >
> > does just as well, the allocations are performed by the compiler,
> > not at run time :-)
>
> Really! I did not know that! Where does it say in the RM - or is a
compiler
> dependent optimisation.

The standard really couldn't say it; we only define the semantics of the
operation, not the exact code that it uses. That said, there was an
intention by the Ada 95 design team that this be done, and I think that
there is an AARM note to that effect. So it isn't surprises that
implementers would make this optimization. (We didn't do it in Janus/Ada,
simply because it didn't seem worth the work -- we hadn't seen any real
usage of it. If customers had asked for it, we would have done it, of
course.)

                     Randy.

Re: ADA Popularity Discussion Request

[Martin Krischik]

Randy Brukardt wrote:

> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> news:2177491.OlAk1RxoCA@linux1.krischik.com...
>> Georg Bauhaus wrote:
>>
>> > Martin Krischik <krischik@users.sourceforge.net> wrote:
>> >
>> > : Now that you say it: True. Mind you, if space is a problem, you can
>> > : always do it the C way:
>> > :
>> > : String_1  : aliased String = "1";
>> > : String_12 : aliased String = "12";
>> > : String_13 : aliased String = "13";
>> > :
>> > : type String_Access  is access all String;
>> > : type Ragged is array (Integer range <>) of String_Access;
>> > : X : constant Ragged :=
>> > :    (  String_1'Access,
>> > :       String_12'Access,
>> > :       String_13'Access
>> > :    );
>> >
>> > for constants,
>> >
>> >    X: constant Ragged :=
>> >     ( new String'("1"),
>> >     ...
>> >
>> > does just as well, the allocations are performed by the compiler,
>> > not at run time :-)
>>
>> Really! I did not know that! Where does it say in the RM - or is a
> compiler
>> dependent optimisation.
> 
> The standard really couldn't say it; we only define the semantics of the
> operation, not the exact code that it uses. That said, there was an
> intention by the Ada 95 design team that this be done, 

Well it is quite hidden. I did a query at ada-comments I got the following
very short answer:

-----
See 13.11(24):

 24. A default (implementation-provided) storage pool for an
     access-to-constant type should not have overhead to support
     deallocation of individual objects.
-----

Without the query I would neither found nor understand that chapter. Only
now I see that if no deallocation is needed than allocation isn't needed
either and the "new" can be optimised away.

> and I think that
> there is an AARM note to that effect.

The AARM  is even more difficult to read.

> So it isn't surprises that 
> implementers would make this optimization. (We didn't do it in Janus/Ada,
> simply because it didn't seem worth the work -- we hadn't seen any real
> usage of it. If customers had asked for it, we would have done it, of
> course.)

It just might be that customers haven't asked for it because customers have
not understand what 13.11(24) actually means. It makes ragged arrays just
as easy as in C - if I had only known before. 

You

With Rergards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[Simon Wright]

Martin Krischik <krischik@users.sourceforge.net> writes:

> See 13.11(24):
> 
>  24. A default (implementation-provided) storage pool for an
>      access-to-constant type should not have overhead to support
>      deallocation of individual objects.

I am always moaning at requirements that specify a mechanism rather
than an intention.

I don't see why the fact that a type is access-to-constant should
eliminate the need for deallocation.

There is clearly a difference between

   P : Constant_String_Access := new String'("p");

and

   Q : constant Constant_String_Access := new String'("q");

(well, to me anyway).

The AARM says

24.a
    Ramification: Unchecked_Deallocation is not defined for such
    types. If the access-to-constant type is library-level, then no
    deallocation (other than at partition completion) will ever be
    necessary, so if the size needed by an allocator of the type is
    known at link-time, then the allocation should be performed
    statically. If, in addition, the initial value of the designated
    object is known at compile time, the object can be allocated to
    read-only memory.

so the allocation part is there if you look, and that's the major part
here.

-- 
Simon Wright                               100% Ada, no bugs.

Re: ADA Popularity Discussion Request

[Jean-Pierre Rosen]

Kevin Cline a écrit :
> It is a bit of a problem.  Just like natural language composition,
> there's a fine line between too brief, too verbose, and just right. 
> In the table above, the interesting parts are X and "1", "12", and
> "123".  The three repetitions of To_Unbounded_String take up most of
> the text while saying nothing of interest, and could be left out if
> Ada supported implicit conversions at all.  Perhaps Ada's prohibition
> of implicit conversions was a reaction to the problems they caused in
> FORTRAN and C programming.  No doubt that FORTRAN and C got implicit
> conversions mostly wrong, but that doesn't mean that they are always
> bad.  It's pretty obvious what it means to convert "1" to an unbounded
> string.
> 
True, and that's precisely why the unary "+" is defined (and 
redefinable) in the language. It provides a convenient way to make 
conversion functions that are not totally hidden, but do not take too 
much visibility in the text.

At least, that's what I remember Ichbiah used to justify "+".
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: ADA Popularity Discussion Request

[Pascal Obry]

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

> type Ragged is array (Integer range <>) of Unbounded_String;
> X : constant Ragged :=
>     (  To_Unbounded_String ("1"),
>        To_Unbounded_String ("12"),
>        To_Unbounded_String ("13")
>     );

But of course this would be :

   function "+" (Str : in String) 
     return Unbounded_String 
     renames To_Unbounded_String;

   X : constant Ragged := (+"1", +"12", +"13");

I did not say that it is perfect, but yet far better than your example :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On 14 Sep 2004 22:35:14 +0200, Pascal Obry wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> type Ragged is array (Integer range <>) of Unbounded_String;
>> X : constant Ragged :=
>>     (  To_Unbounded_String ("1"),
>>        To_Unbounded_String ("12"),
>>        To_Unbounded_String ("13")
>>     );
> 
> But of course this would be :
> 
>    function "+" (Str : in String) 
>      return Unbounded_String 
>      renames To_Unbounded_String;
> 
>    X : constant Ragged := (+"1", +"12", +"13");
> 
> I did not say that it is perfect, but yet far better than your example :)

It is disgusting! (:-)) What goal this "solution" achieves? To save
keystrokes? Is it Ada or C++? (:-))

P.S. what would be -"1"?

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

Re: ADA Popularity Discussion Request

[Pascal Obry]

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

> > But of course this would be :
> > 
> >    function "+" (Str : in String) 
> >      return Unbounded_String 
> >      renames To_Unbounded_String;
> > 
> >    X : constant Ragged := (+"1", +"12", +"13");
> > 
> > I did not say that it is perfect, but yet far better than your example :)
> 
> It is disgusting! (:-)) 

I know there is a smiley :) But nevertheless...

> What goal this "solution" achieves? To save keystrokes?

No not only. In this case it makes the code easier to read IMHO. I have (and
found this in other piece of code too) often used:

    function "+" (Str : in String) 
      return Unbounded_String 
      renames To_Unbounded_String;

    function "-" (Str : in Unbounded_String) 
      return String 
      renames To_String;

> Is it Ada or C++? (:-))

Renamings ? Ada definitly :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ADA Popularity Discussion Request

[Kevin Cline]

Pascal Obry <pascal@obry.org> wrote in message news:<uy8jhjfcq.fsf@obry.org>...
> kevin.cline@gmail.com (Kevin Cline) writes:
> 
> > > Does the C++ standard directly address the behavior of handwritten
> > > bounded numbers? How many lines of template code will it take
> > > to get the effect of
> > > 
> > >   type A is array(Some_Index_Type) of Foo;?
> > 
> > I don't know.  It could be done in C++ if Some_Index_Type had the
> > right properties.  But as a practical matter, no one seems to care, at
> > least no one in the C++ community.  I very rarely have any need or use
> > for a statically sized array.  
> 
> That's why working with strings in C/C++ is a nightmare! strcpy/strcat,++,--
> and so on... Look at some real world C/C++ code handling strings !

> 
> For memory, a string in Ada is:
> 
>    type String is array (Positive range <>) of Character;
> 
> And you can do something like:
> 
>    function Some_Value return String is
>    begin
>       return "...";
>    end Some_Value;
> 
>    S1 : constant String := "a long string";
>    S2 : constant String := "this is definitly " & S1 & Some_Value;
> 
>    S3 : constant String := S1 (S1'First + 2 .. S1'First + 5);
> 
> Pascal.

Yes, but that can get really inefficient when you need to build up a
string from multiple parts and don't know the final length.  You keep
returning intermediate strings by value and what should be O(n) code
becomes O(n^2).
I suppose one could first collect all the parts and then join them,
but that's a convoluted way to write string handling code.

C++:
  std::string some_value() 
  { 
    return "..."; 
  }
  std::string s1("a long string");
  std::string s2("this is definitely " + s1 + some_value()); 
  std::string s3(s1.substring(2, 3));

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
 
: I don't know.  It could be done in C++ if Some_Index_Type had the
: right properties.  But as a practical matter, no one seems to care, at
: least no one in the C++ community.

Could it be an effect of tradition? If C++ had not inherited C arrays,
maybe arrays (including dynamically sized) were used more frequently?
I guess vector is used for array computation, then?

:  I very rarely have any need or use
: for a statically sized array.

If you need _dynamically_ sized arrays you still can have subtypes with
bounds determined at run time. I think this can be important. (C99 now
has some of it.) Declare the subtypes locally as index types, ranges
based on runtime values. Declare dynamically or statically sized arrays
in blocks, in functions, wherever.  Create corresponding arrays on the
stack or on the heap, assign the results ...


   type Vec is array (Positive range <>) of Natural;
   --   base type of all "vectors" counting from 1

   function make(limit: Positive; init: Natural := 0) return Vec
	--   a dynamically sized `Vec`, all values set to `init`
   is
      subtype Index is Positive range Positive'first .. limit;
      subtype A is Vec(Index);
   begin
      return A'(others => init);
   end make;

   x: Vec := make(5);

   pragma assert(x'first = 1 and x'last = 5);


-- Georg

Re: ADA Popularity Discussion Request

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<chuofo$o96$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
>  
> : I don't know.  It could be done in C++ if Some_Index_Type had the
> : right properties.  But as a practical matter, no one seems to care, at
> : least no one in the C++ community.
> 
> Could it be an effect of tradition? If C++ had not inherited C arrays,
> maybe arrays (including dynamically sized) were used more frequently?
> I guess vector is used for array computation, then?

I'm not sure what you mean by "array computation".  For mathematical
vectors and matrices with dot product and matrix multiplication you
would want a template based library, and such libraries do exist.  C++
is an excellent language for writing such a library, because template
functions can instantiate new types automatically, e.g.

   template <int M, N, P> 
     matrix<M,P> operator*(const matrix<M,N>& lhs, conat matrix<N,P>&
rhs) {...}

   template <int M>
     vec<M> trace(const matrix<M,M>& m) { ... }

   template <int M,N>
    matrix<M,N> outer_product(const vec<M>& v1, const vec<N>& v2) {
... }

   Now I can write code like this:
    matrix<3,5> func(const matrix<3,5>& m1, const matrix<5,3>& m2)
    {
      return outer_product(trace(m1*m2), trace(m2*m1));
    }

You could do the same in Ada, but first you would have to explicitly
instantiate the five functions.  That gets old really fast.

This ground is covered extensively in Scientific and Engineering C++ :
An Introduction with Advanced Techniques and Examples by John J.
Barton, Lee R. Nackman.

> 
> :  I very rarely have any need or use
> : for a statically sized array.
> 
> If you need _dynamically_ sized arrays you still can have subtypes with
> bounds determined at run time. I think this can be important. (C99 now
> has some of it.) Declare the subtypes locally as index types, ranges
> based on runtime values. Declare dynamically or statically sized arrays
> in blocks, in functions, wherever.  Create corresponding arrays on the
> stack or on the heap, assign the results ...
> 
> 
>    type Vec is array (Positive range <>) of Natural;
>    --   base type of all "vectors" counting from 1
> 
>    function make(limit: Positive; init: Natural := 0) return Vec
> 	--   a dynamically sized `Vec`, all values set to `init`
>    is
>       subtype Index is Positive range Positive'first .. limit;
>       subtype A is Vec(Index);
>    begin
>       return A'(others => init);
>    end make;
> 
>    x: Vec := make(5);

But even though X has a run-time determined size, its size is now
fixed.  I can neither add or remove elements without creating an
entirely new vector.

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
:  C++
: is an excellent language for writing such a library,

No doubt.

: because template
: functions can instantiate new types automatically, e.g.

But that is not the only reason that C++ is an excellent language
for writing such a library?

:   template <int M, N, P> 
:     matrix<M,P> operator*(const matrix<M,N>& lhs, conat matrix<N,P>&
: rhs) {...}

Note that all the instantiations appear to be there in order to have
bounded arrays. I think. It might be an advantage that the ranges
are known to match; I guess this is different from what Ada's gives
you when the compiler cannot find out at compile time:
  "Note that errors such as when bounds of arrays do not match raise
   Constraint_Error by analogy with built-in array operations."
(from the AI mentioned below.)

: You could do the same in Ada, but first you would have to explicitly
: instantiate the five functions.  That gets old really fast.

I might not have to do the same thing, because Ada arrays and
matrices tend to come with their bounds determined when a matrix
object is declared and assigned. :-) The latest on Vector and Matrix ops
for Ada 200Y is available in
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00296.TXT?rev=1.17

 
: This ground is covered extensively in Scientific and Engineering C++ :
: An Introduction with Advanced Techniques and Examples by John J.
: Barton, Lee R. Nackman.

Thanks for the pointer.

:> :  I very rarely have any need or use
:> : for a statically sized array.
 
:>    x: Vec := make(5);
: 
: But even though X has a run-time determined size, its size is now
: fixed.  I can neither add or remove elements without creating an
: entirely new vector.

Sure. That's a property of the built in arrays. They are not
flex arrays. Would you want to change the size of a matrix, too?

-- Georg

Re: ADA Popularity Discussion Request

[Lionel Draghi]

Kevin Cline wrote:
...
> I code test-first, and the amount of test code is relatively
> independent of the language.
OK, because in test-first you write typical use-cases
narrowed to the tested component. Tested features are the same whatever
is the language.

...
> The first version leaves me wondering if the comment is correct.
> The second version leaves me wondering if it sometimes throws
> Constraint_Error.  There's no way to verify that A always returns a
> value from 1 to 10 or to verify that B never throws Constraint_Error
> without inspecting the function body.
I was not discussing about code correctness (althrough the typed version
correctness is easier to proof with static analisys tools).

The big difference is that the typed version will raise the default 
obvious as soon as possible, the other not. To reach the same behaviour 
without typing, you need to do more work.

> I'm also wondering what happens when you write Random_Index +
> Random_Index ?
> Or Random_Index * Random_Index ?
Yet another advantage of typing: you wonder about problems that also 
exist without typing
I was not aware of this advantage :-)

>>On the other hand, in the A version, I need to check the return value on 
>>each call.

> That's silly.
In my simple example, yes. It's much simpler to put some assertion in 
the code.
But once more, there is more code to write without typing.

 > You have to trust functions to satisfy their
> postconditions.
I trust the code generated by the compiler to check an assertion or a 
range, I trust a formal tool that certifies to me that returned value 
will always be in range, but I don't trust a comment.

> Even in Ada relatively few post-conditions can be
> handled by type checks.
But whatever is the proportion, why would you renonce to this advantage?
Typing has no cost, no drawback, only advantages. So, why should we 
discuss on what typing can't do?

Anyway, I enter in this thread because of the claim that typing has much 
less value than test-first.
I still wait for any illustration of this claim.

(and I feel that I will wait for a long time)

-- 
Lionel Draghi

Re: ADA Popularity Discussion Request

[Kevin Cline]

Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> wrote in message news:<4140b5cc$0$17701$626a14ce@news.free.fr>...
> Kevin Cline wrote:
> ...
> > I code test-first, and the amount of test code is relatively
> > independent of the language.
> OK, because in test-first you write typical use-cases
> narrowed to the tested component. Tested features are the same whatever
> is the language.
> 
> ...
> > The first version leaves me wondering if the comment is correct.
> > The second version leaves me wondering if it sometimes throws
> > Constraint_Error.  There's no way to verify that A always returns a
> > value from 1 to 10 or to verify that B never throws Constraint_Error
> > without inspecting the function body.
> I was not discussing about code correctness (althrough the typed version
> correctness is easier to proof with static analisys tools).
> 
> The big difference is that the typed version will raise the default 
> obvious as soon as possible, the other not. To reach the same behaviour 
> without typing, you need to do more work.
> 
> > I'm also wondering what happens when you write Random_Index +
> > Random_Index ?
> > Or Random_Index * Random_Index ?
> Yet another advantage of typing: you wonder about problems that also 
> exist without typing
> I was not aware of this advantage :-)
> 
> >>On the other hand, in the A version, I need to check the return value on 
> >>each call.
>  
> > That's silly.
> In my simple example, yes. It's much simpler to put some assertion in 
> the code.
> But once more, there is more code to write without typing.
> 
>  > You have to trust functions to satisfy their
> > postconditions.
> I trust the code generated by the compiler to check an assertion or a 
> range, I trust a formal tool that certifies to me that returned value 
> will always be in range, but I don't trust a comment.
> 
> > Even in Ada relatively few post-conditions can be
> > handled by type checks.
> But whatever is the proportion, why would you renonce to this advantage?
> Typing has no cost, no drawback, only advantages. So, why should we 
> discuss on what typing can't do?

Explicit static typing ala Ada and C++ definitely has a cost, because
it makes the code longer, and also makes it more brittle.  Often I
don't really care what type a variable has as long as it is the same
type as the value it takes.  But with explicit typing a simple type
change can ripple through the application forcing the change of many
other functions.  Simply changing the return type of a commonly used
function from single precision to double precision may require every
call of that function to be changed.  That takes time that could be
better spent on higher level pursuits.

Besides the additional time to write all those declarations and keep
them synchronized with the bodies and keep all the callers
synchronized, there is the time lost waiting for compilation and
linking, and worse the loss in concentration when developers go off
surfing the web waiting for the compile to finish.

> Anyway, I enter in this thread because of the claim that typing has much 
> less value than test-first.
> I still wait for any illustration of this claim.
> 
> (and I feel that I will wait for a long time)

I don't think you will wait all that long.  Test-first development is
no longer a radical idea.  Increasing numbers of serious software
development shops, like SABRE, are getting good results from
test-first development.

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:

: Explicit static typing ala Ada and C++ definitely has a cost,

Yes. (And you get something in return, too?)

: because it makes the code longer,

Sometimes I prefer a few explicit words to brevity when brevity would
hide things away.

: and also makes it more brittle.

Hm. Brittle? Your example could be a design issue. In Ada you could have
written

   generic
      type FPT is digits <>;
   function compute(x, y: FPT) return FPT;

or

   generic
      type FPT is digits <>;
   package Computations is ...

I'm confident that changing the floating point type might not have
required adjusting a lot of calls?

Related to making changes to parameter profiles,
subtype declaractions and type declarations offer at least one choice:

-  use (possibly constraining) subtypes where you expect slight changes
   to the range of values passed.  (Use T'base type parameters if a
   function needs to be more general.)

-  use types where the domain objects are different, or where things
   should be handled separately in code.


-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Kevin Cline <kevin.cline@gmail.com> wrote:
> 
> : Explicit static typing ala Ada and C++ definitely has a cost,
> 
> Yes. (And you get something in return, too?)

In most domains, the answer is "not much".  The cost is _way_ more
than the ROI.


> : because it makes the code longer,
> 
> Sometimes I prefer a few explicit words to brevity when brevity would
> hide things away.
> 
> : and also makes it more brittle.
> 
> Hm. Brittle? Your example could be a design issue. In Ada you could have
> written

Open your mind a bit more - don't concentrate on the particular
example and think about what it would mean to have the sort of
flexibility to track changing requirements (indeed to realize new
requirements) that Kevin is talking about.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:> Kevin Cline <kevin.cline@gmail.com> wrote:
:> 
:> : Explicit static typing ala Ada and C++ definitely has a cost,
:> 
:> Yes. (And you get something in return, too?)
: 
: In most domains, the answer is "not much".  The cost is _way_ more
: than the ROI.

I know I'm nagging, but still, could you be a bit more
specific about what you mean by "most domains", and
"not much"?

:> Hm. Brittle? Your example could be a design issue. In Ada you could have
:> written
: 
: Open your mind a bit more - don't concentrate on the particular
: example and think about what it would mean to have the sort of
: flexibility to track changing requirements (indeed to realize new
: requirements) that Kevin is talking about.

(Could you give a typical example of the kind of change in requirements
you have in mind?)
I did, and I agree that requirements pattern matching can
be written more quickly by writing melleable interfaces, and making
ad hoc changes at every level of a system, tested. I don't see
how adding static type checking makes a program brittle. Type
mismatches may break the compilation run, sure.  But is a program
therefore brittle?

 When in the example

  type Direction is (North, East, South, West);

the requirements change, and now we have

  type Direction is (North, East, South, West, Up, Down);

then refactoring can be guided by static type analysis
pointing out missing cases for example (in ML terms: exhaustive pattern
matching finds definitions which need to be extended to
match the new requirements, absent wildcards). 
  Now ideally there is no need to test whether all values in the type
Direction are handled in functions (etc.) with an argument of type
Direction.

-- Georg

Re: ADA Popularity Discussion Request

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<chupnc$9t1$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> 
> : Explicit static typing ala Ada and C++ definitely has a cost,
> 
> Yes. (And you get something in return, too?)
> 
> : because it makes the code longer,
> 
> Sometimes I prefer a few explicit words to brevity when brevity would
> hide things away.
> 
> : and also makes it more brittle.
> 
> Hm. Brittle? Your example could be a design issue. 

> In Ada you could have
> written
> 
>    generic
>       type FPT is digits <>;
>    function compute(x, y: FPT) return FPT;
> 
> or
> 
>    generic
>       type FPT is digits <>;
>    package Computations is ...

Yes, you could have, if you had thought of it before your team wrote
100,000 lines of code.  But we're not omniprescient.  Sometimes
requirements change, and sometimes we make mistakes.   This
flexibility also comes with a cost -- it makes the code harder to
read.  Everyone knows what digits<> means, but the first time we see
FPT we'll have to go look it up.  Should we also create a type for
discrete inventory quantity, or just use integer?  Well, it's possible
that we could need to go to 64 bits, but right now we don't have
enough memory to expand them all to 64 bits, so better create a IQTY
type.  And so it goes... soon you have dozens or hundreds of data
types, and no one knows what they all mean, and the code is obscured
by type conversions.

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:

:>    generic
:>       type FPT is digits <>;
:>    package Computations is ...
: 
: Yes, you could have, if you had thought of it before your team wrote
: 100,000 lines of code.

OK, if the code has not used proper types right from the start
and there will be no corrections, there is little you can do but write
adequate code.

: But we're not omniprescient.

Sure. This is why things can be described in fairly abstract
terms. This does *not* mean chosing a concrete type for their
representation. If I know "we will be computing with floating point
values", I won't blindly chose one concrete predefined
floating point type unless there is good reason to do so.
In particular when it costs next to nothing to provide for
possible changes in the type by making the corresponding module a
parameterized module.

:   This
: flexibility also comes with a cost -- it makes the code harder to
: read.  Everyone knows what digits<> means, but the first time we see
: FPT we'll have to go look it up.

As a Client, you won't have to use the name "FPT", see below.

:  Should we also create a type for
: discrete inventory quantity, or just use integer?  Well, it's possible
: that we could need to go to 64 bits, but right now we don't have
: enough memory to expand them all to 64 bits, so better create a IQTY
: type.  And so it goes... soon you have dozens or hundreds of data
: types, and no one knows what they all mean, and the code is obscured
: by type conversions.

So that's it :-) You want the illusion of knowing the type. :-)
And to look at the details by trial and error testing?
Given the information present in digits<>, conceptually, and leaving it at
that, of course will give you lots of opportunities for additional testing
:-) :-)

FPT is of course a name chosen for the sake of this example, not to
be used in real programs to denote a particulat floating point type.
The name does _not_ appear outside the floating point module.

In

  package ... is new  Stone_Carving_Drawings (Float_Type => ...);

it is pretty clear what Float_Type => ... stands for, isn't it?


-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

kevin.cline@gmail.com (Kevin Cline) writes:

> Explicit static typing ala Ada and C++ definitely has a cost, because
> it makes the code longer, and also makes it more brittle.

The truth of this is really really hard to over emphasize.


>  Often I don't really care what type a variable has as long as it is
> the same type as the value it takes.  But with explicit typing a
> simple type change can ripple through the application forcing the
> change of many other functions.  Simply changing the return type of
> a commonly used function from single precision to double precision
> may require every call of that function to be changed.  That takes
> time that could be better spent on higher level pursuits.

Good description of a serious problem with static typing.


> Besides the additional time to write all those declarations and keep
> them synchronized with the bodies and keep all the callers
> synchronized, there is the time lost waiting for compilation and
> linking, and worse the loss in concentration when developers go off
> surfing the web waiting for the compile to finish.

More very good points.  Productivity, as well as robustness and
_usefulness_ of the result, generally (in my experience) skyrockets
after moving to dynamic systems and agile methods.


> > Anyway, I enter in this thread because of the claim that typing has much 
> > less value than test-first.

It is _static_ typing that has much less value, not typing!


> > I still wait for any illustration of this claim.
> > 
> > (and I feel that I will wait for a long time)
> 
> I don't think you will wait all that long.  Test-first development is
> no longer a radical idea.  Increasing numbers of serious software
> development shops, like SABRE, are getting good results from
> test-first development.

Agreed.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Lionel Draghi]

...
>>>Anyway, I enter in this thread because of the claim that typing has much 
>>>less value than test-first.
> It is _static_ typing that has much less value, not typing!

>>>I still wait for any illustration of this claim.
>>>(and I feel that I will wait for a long time)
>>
>>I don't think you will wait all that long.  Test-first development is
>>no longer a radical idea.  Increasing numbers of serious software
>>development shops, like SABRE, are getting good results from
>>test-first development.
>
> Agreed.

With what? This is not at all related to my point.
I am not waiting for whatever about XP development, not even success 
stories, because we already have this at work.
I am waiting for any point explaining how Agile methods raise static 
typing more or less obsolete.
There is no relation between those: you could have raise all your points 
before XP creation, all this thread is just a (usual) discussion about 
typing.

-- 
Lionel Draghi

Re: ADA Popularity Discussion Request

[Lionel Draghi]

jayessay wrote:
...

>> Often I don't really care what type a variable has as long as it is
>>the same type as the value it takes.  But with explicit typing a
>>simple type change can ripple through the application forcing the
>>change of many other functions.  Simply changing the return type of
>>a commonly used function from single precision to double precision
>>may require every call of that function to be changed.  That takes
>>time that could be better spent on higher level pursuits.

> Good description of a serious problem with static typing.

Serious problem?
1 - if your float is a custom type, the type and related operators are 
typically declared in the same package : changing it is trivial.
2 - if you are using predifined type: too bad, but you can't comply 
about strong typing if you are not using it the right way.

Your serious problem seems really anecdotal to me.

-- 
Lionel Draghi

Re: ADA Popularity Discussion Request

[John B. Matthews]

In article <4144d6da$0$17714$626a14ce@news.free.fr>,
 Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> wrote:

> jayessay wrote:
> ...
> >> Often I don't really care what type a variable has as long as it is
> >>the same type as the value it takes.  But with explicit typing a
> >>simple type change can ripple through the application forcing the
> >>change of many other functions.  Simply changing the return type of
> >>a commonly used function from single precision to double precision
> >>may require every call of that function to be changed.  That takes
> >>time that could be better spent on higher level pursuits.
> 
> > Good description of a serious problem with static typing.
> 
> Serious problem?
> 1 - if your float is a custom type, the type and related operators are 
> typically declared in the same package : changing it is trivial.
> 2 - if you are using predifined type: too bad, but you can't comply 
> about strong typing if you are not using it the right way.
> 
> Your serious problem seems really anecdotal to me.

Indeed, if such a change is required, the compiler will reliably 
lead me to every affected part of the code--and no other. I 
consider this an advantage.

John
----
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/

Re: ADA Popularity Discussion Request

[jayessay]

Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:



> Your serious problem seems really anecdotal to me.

Frankly, wrt software development, that is really all you ever have.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
: 
:>  Often I don't really care what type a variable has as long as it is
:> the same type as the value it takes.  But with explicit typing a
:> simple type change can ripple through the application forcing the
:> change of many other functions.  Simply changing the return type of
:> a commonly used function from single precision to double precision
:> may require every call of that function to be changed.  That takes
:> time that could be better spent on higher level pursuits.
: 
: Good description of a serious problem with static typing.
Good description of a serious problem with inflexible static typing.

-- Georg

Re: ADA Popularity Discussion Request

[Randy Brukardt]

"jayessay" <nospam@foo.com> wrote in message
news:m3wtz7e4hd.fsf@rigel.goldenthreadtech.com...
> kevin.cline@gmail.com (Kevin Cline) writes:
...
> > I thought so too, until I tried incremental test-first development.
> > Retesting a unit after adding a few lines of code means that type
> > mismatches are caught immediately with or without strong typing.  But
> > it goes faster if you don't have to compile and link every iteration.
>
> Exactly.  Actually this sort of development will save you much more
> time and money than you could ever hope for from typical static typing.

This seems like complete nonsense to me. (I'll admit that I've read other
people making similar claims). The reason is that writing a good subprogram
test takes on average 10 times as much code as is in the subprogram itself.
That's because of the need to set up the needed global state for the
preconditions, and the need to test all of the possible permutations of
input. Making the test reusable and automatible adds even more effort.

The best way to save time and money is to avoid the need to do that testing
in the first place. We do that with Ada's strong compile-time and run-time
checking, combined with occassional invariant assertions. And then we do
extensive, repeatable system-level testing to find any logic errors. Our
experience is that true logic errors (those that doesn't show up as
compile-time or run-time checks) are very rare, probably less than 1% of all
errors. (I'm omitting interfacing errors from this summary, because there
you lose all benefits of Ada or for that matter any type system, even one as
weak as C's. No language is going to help you there, but the real world is
always going to insist on it...)

If I had a stronger need for correctness, I'd move to something like SPARK,
and do *all* of the checking at compile-time; I certainly wouldn't write
more tests.

                                  Randy.

Re: ADA Popularity Discussion Request

[Kevin Cline]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<2L-dnRmP6qOePaLcRVn-ug@megapath.net>...
> "jayessay" <nospam@foo.com> wrote in message
> news:m3wtz7e4hd.fsf@rigel.goldenthreadtech.com...
> > kevin.cline@gmail.com (Kevin Cline) writes:
>  ...
> > > I thought so too, until I tried incremental test-first development.
> > > Retesting a unit after adding a few lines of code means that type
> > > mismatches are caught immediately with or without strong typing.  But
> > > it goes faster if you don't have to compile and link every iteration.
> >
> > Exactly.  Actually this sort of development will save you much more
> > time and money than you could ever hope for from typical static typing.
> 
> This seems like complete nonsense to me. (I'll admit that I've read other
> people making similar claims). The reason is that writing a good subprogram
> test takes on average 10 times as much code as is in the subprogram itself.

> That's because of the need to set up the needed global state for the
> preconditions, and the need to test all of the possible permutations of
> input. Making the test reusable and automatible adds even more effort.

A 10:1 ratio of test code to production code seems extremely high. 
Keeping subprograms small will reduce the number of permutations of
input that must be tested.  It's much easier to test five ten-line
subprograms taking one input each than to test one fifty-line
subprogram taking five inputs.

It's also much easier to maintain the five ten-line subprograms, and
easier to demonstrate code correctness.

Another benefit of unit-level testing is that in the absence of any
other documentation, the tests at least demonstrate correct use of the
unit.

> The best way to save time and money is to avoid the need to do that testing
> in the first place. We do that with Ada's strong compile-time and run-time
> checking, combined with occassional invariant assertions. And then we do
> extensive, repeatable system-level testing to find any logic errors. 

I do not like having only system-level testing because it makes
changes either risky or expensive, and inhibits refactoring.  It
drives developers to stick with the first code that passes tests, and
inhibits extraction of duplicated code because of the cost of
retesting.

Re: ADA Popularity Discussion Request

[Randy Brukardt]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0409101623.73cdaf9b@posting.google.com...
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:<2L-dnRmP6qOePaLcRVn-ug@megapath.net>...
...
> > This seems like complete nonsense to me. (I'll admit that I've read
other
> > people making similar claims). The reason is that writing a good
subprogram
> > test takes on average 10 times as much code as is in the subprogram
itself.
>
> > That's because of the need to set up the needed global state for the
> > preconditions, and the need to test all of the possible permutations of
> > input. Making the test reusable and automatible adds even more effort.
>
> A 10:1 ratio of test code to production code seems extremely high.
> Keeping subprograms small will reduce the number of permutations of
> input that must be tested.  It's much easier to test five ten-line
> subprograms taking one input each than to test one fifty-line
> subprogram taking five inputs.

The size of the subprogram is irrelevant. In real systems, there is a lot of
state associated with any particular operation. You have to set up all of
that state in order to have a useful, repeatable test. For instance, in the
Janus/Ada compiler, we have lots of short query functions. But you have to
have a complete symboltable in order to use them - otherwise their
preconditions would be violated and the test results would tell you nothing.

> It's also much easier to maintain the five ten-line subprograms, and
> easier to demonstrate code correctness.

While I don't doubt that, it's rare that you can write anything useful in 10
lines of readable code. (Sure, you can cram lots of code into that space,
especially in languages like Lisp or Perl; but is there any chance to fix it
when a problem is discovered in a few months? Not if the code isn't
readable.)

> Another benefit of unit-level testing is that in the absence of any
> other documentation, the tests at least demonstrate correct use of the
unit.

Yes, that's the main reason that we even bothered with many of the tests we
wrote for Claw. (They also served to verify that the Microsoft documentation
was accurate, a real dicey proposition in 1997.)

> > The best way to save time and money is to avoid the need to do that
testing
> > in the first place. We do that with Ada's strong compile-time and
run-time
> > checking, combined with occassional invariant assertions. And then we do
> > extensive, repeatable system-level testing to find any logic errors.
>
> I do not like having only system-level testing because it makes
> changes either risky or expensive, and inhibits refactoring.  It
> drives developers to stick with the first code that passes tests, and
> inhibits extraction of duplicated code because of the cost of
> retesting.

Changes certainly aren't risky in Ada, and a majority aren't expensive,
either. Refactoring (indeed, any sort of restructuring) is a complete waste
of effort unless it is tied to a clear end-user benefit. We used to do lots
of that, but it mainly made us (the programmers) feel good, and it did
nothing to make the product better in many of the cases. Your last sentence
seems to go against agile - test-driven - methods -- once the tests pass,
you're done! There's no reason to mess with the code further. Moreover,
there is little cost to retesting, because the tests are all automated and
run pretty much after every change. Testing is not very worthwhile in my
view if you can't rerun it frequently to verify that nothing has changed.

                         Randy.

Re: ADA Popularity Discussion Request

[jayessay]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "jayessay" <nospam@foo.com> wrote in message
> news:m3wtz7e4hd.fsf@rigel.goldenthreadtech.com...
> > kevin.cline@gmail.com (Kevin Cline) writes:
> ...
> > > I thought so too, until I tried incremental test-first development.
> > > Retesting a unit after adding a few lines of code means that type
> > > mismatches are caught immediately with or without strong typing.  But
> > > it goes faster if you don't have to compile and link every iteration.
> >
> > Exactly.  Actually this sort of development will save you much more
> > time and money than you could ever hope for from typical static typing.
> 
> This seems like complete nonsense to me. (I'll admit that I've read other
> people making similar claims).

Have a look at this:

http://martinfowler.com/articles/newMethodology.html

and I think you will have a somewhat better idea of what this is
about.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Randy Brukardt]

"jayessay" <nospam@foo.com> wrote in message
news:m3sm9n8nk2.fsf@rigel.goldenthreadtech.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
> > "jayessay" <nospam@foo.com> wrote in message
> > news:m3wtz7e4hd.fsf@rigel.goldenthreadtech.com...
> > > kevin.cline@gmail.com (Kevin Cline) writes:
> > ...
> > > > I thought so too, until I tried incremental test-first development.
> > > > Retesting a unit after adding a few lines of code means that type
> > > > mismatches are caught immediately with or without strong typing.
But
> > > > it goes faster if you don't have to compile and link every
iteration.
> > >
> > > Exactly.  Actually this sort of development will save you much more
> > > time and money than you could ever hope for from typical static
typing.
> >
> > This seems like complete nonsense to me. (I'll admit that I've read
other
> > people making similar claims).
>
> Have a look at this:
>
> http://martinfowler.com/articles/newMethodology.html
>
> and I think you will have a somewhat better idea of what this is
> about.

"Access to this site timed-out". Doesn't bode well for the quality of the
software... :-)

Seriously, I'm always very skeptical of "methodologies", because they
primarily seem geared toward selling books and consulting to clueless
management types. There's usually a few obvious truths sprinkled around to
make them more palatable.

For a test-first scheme to have any hope of success, you have to have
programmers that are very disciplined, that actually take the time to test
every path of every subprogram. I doubt that there are many such people - I
*know* I am not such a person. (The reason that I've always used Ada
exclusively is that the Ada compiler catches the vast majority of my
mistakes; without Ada, I simply could not work in this field, because the
computers would not survive many long debugging sessions.)

                                         Randy.

Re: ADA Popularity Discussion Request

[jayessay]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "jayessay" <nospam@foo.com> wrote in message
> news:m3sm9n8nk2.fsf@rigel.goldenthreadtech.com...
> > "Randy Brukardt" <randy@rrsoftware.com> writes:
> >
> > > "jayessay" <nospam@foo.com> wrote in message
> > > news:m3wtz7e4hd.fsf@rigel.goldenthreadtech.com...
> > > > kevin.cline@gmail.com (Kevin Cline) writes:
> > > ...
> > > > > I thought so too, until I tried incremental test-first development.
> > > > > Retesting a unit after adding a few lines of code means that type
> > > > > mismatches are caught immediately with or without strong typing.
> But
> > > > > it goes faster if you don't have to compile and link every
> iteration.
> > > >
> > > > Exactly.  Actually this sort of development will save you much more
> > > > time and money than you could ever hope for from typical static
> typing.
> > >
> > > This seems like complete nonsense to me. (I'll admit that I've read
> other
> > > people making similar claims).
> >
> > Have a look at this:
> >
> > http://martinfowler.com/articles/newMethodology.html
> >
> > and I think you will have a somewhat better idea of what this is
> > about.
> 
> "Access to this site timed-out".

Comes up instantly for me, from different machines on different nets.


> Doesn't bode well for the quality of the software... :-)

Looks like simple html to me, ("hand written"), and using Apache.
Maybe the broken stuff is on your side.


> Seriously, I'm always very skeptical of "methodologies", because
> they primarily seem geared toward selling books and consulting to
> clueless management types. There's usually a few obvious truths
> sprinkled around to make them more palatable.

Agreed, absolutely.  The nice thing about the above is that it is not
much about any "methodology", but merely an overview of why something
like "agile" techniques are (re)gaining interest.

> For a test-first scheme to have any hope of success, you have to have

As I pointed out elsewhere, I think a much better way of thinking
about the kind of incremental development I was discussing is that of
developing a theory in mathematics.  I typically spend 0 time in
debugging sessions.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Stephen Leake]

kevin.cline@gmail.com (Kevin Cline) writes:

> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<vpblkhspuA9F@eisner.encompasserve.org>...
> > In article <iWG_c.8033$w%6.3982@newsread1.news.pas.earthlink.net>, "Richard  Riehle" <adaworks@earthlink.net> writes:
> > 
> > > No one argues that testing is unimportant.
> >  
> > > No language can protect us, at compile time, from every possible
> > > error.
> > 
> > But assuming perfect testing, finding the errors during compilation
> > rather than in testing saves me time, and time is money.
> 
> I thought so too, until I tried incremental test-first development. 
> Retesting a unit after adding a few lines of code means that type
> mismatches are caught immediately with or without strong typing.  But
> it goes faster if you don't have to compile and link every iteration.

Hmm. I practice "test first" and incremental code/test. But I don't
write tests that duplicate what the compiler is already testing; that
would certainly be a waste of my time!

It takes me much longer to write and test code in C than in Ada. I
suppose Haskell or something might be even better, but I'm waiting for
an ISO standard language that I can buy support for.

-- 
-- Stephe

Re: ADA Popularity Discussion Request

[Kevin Cline]

Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.50.1094504533.31213.comp.lang.ada@ada-france.org>...
> kevin.cline@gmail.com (Kevin Cline) writes:
> 
> > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<vpblkhspuA9F@eisner.encompasserve.org>...
> > > In article <iWG_c.8033$w%6.3982@newsread1.news.pas.earthlink.net>, "Richard  Riehle" <adaworks@earthlink.net> writes:
> > > 
> > > > No one argues that testing is unimportant.
>  
> > > > No language can protect us, at compile time, from every possible
> > > > error.
> > > 
> > > But assuming perfect testing, finding the errors during compilation
> > > rather than in testing saves me time, and time is money.
> > 
> > I thought so too, until I tried incremental test-first development. 
> > Retesting a unit after adding a few lines of code means that type
> > mismatches are caught immediately with or without strong typing.  But
> > it goes faster if you don't have to compile and link every iteration.
> 
> Hmm. I practice "test first" and incremental code/test. But I don't
> write tests that duplicate what the compiler is already testing; that
> would certainly be a waste of my time!
> 
> It takes me much longer to write and test code in C than in Ada. 

No surprise.  C is a much lower-level language than Ada.  Have you
ever tried C++?

> I
> suppose Haskell or something might be even better, but I'm waiting for
> an ISO standard language that I can buy support for.

I don't think there's as much value in ISO standards as there once
was.  When there were two dozen CPU families in use, and compiler
writing was an arcane and expensive art, ISO standards helped keep
developers and users from getting locked in to one particular hardware
vendor.  Today, with open-source compilers and languages, de facto
standard languages like Perl are just as good.

If you want control, then I would think you would be better off with
an open-source language and compiler, like C++/gcc or Ada/gnat or
Perl.  I would rather have something I can fix myself or hire someone
to fix than be at the mercy of a monopoly supplier.

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0409051449.574ec9ce@posting.google.com...
> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message
news:<vpblkhspuA9F@eisner.encompasserve.org>...

> > But assuming perfect testing, finding the errors during compilation
> > rather than in testing saves me time, and time is money.
>
> I thought so too, until I tried incremental test-first development.
> Retesting a unit after adding a few lines of code means that type
> mismatches are caught immediately with or without strong typing.  But
> it goes faster if you don't have to compile and link every iteration.
>
This assumes that we are concerned only with type mismatches.   In
Ada, we expect the compiler to provide a great deal more than that.

For small software systems, frequent testing can often be sufficient. As
the size of the software increases, and complexity of that software grows,
we must engage all the tools available and use them appropriately to
ensure the correctness of our design.   Also, in large software systems,
it is not possible to test every path, every possible value of a variable,
and every potential timing problem.

How does one test for a race condition?   Does that test guarantee
no race condition can occur?    This is not a type checking issue, but
it is a design issue where the type model can be one of many factors
in reasoning about the stability of the design.

How does one test for a runaway pointer or dangling reference?  Again,
this is not strictly a type issue, except that Ada's overall set of rules,
including the type rules, provide some tools for reasoning about this
intelligently.

Finally, testing can only test for what we know needs to be tested.   We
must design for the unexpected, even as we test for the expected.  It is
impossible to test for the unexpected.   The Ada type model includes
both the compile-time checking and the run-time checking.   The rest
of Ada provides a wide range of compile-time checks.

Those who fail to understand this should stay away from building software
that requires a high degree of dependability.

Richard Riehle

Re: ADA Popularity Discussion Request

[Benjamin Ketcham]

Richard  Riehle <adaworks@earthlink.net> wrote:
> 
> Finally, testing can only test for what we know needs to be tested.   We
> must design for the unexpected, even as we test for the expected.  It is
> impossible to test for the unexpected.

While I agree with the overall point here, I keep seeing this
assertion, here made with especially great conviction: "it is
impossible to test for the unexpected".  As with many absolute
statements, it is not technically correct, although it expresses
a valid general truth.  Consider the method of kernel testing
where system calls are invoked with random arguments; this kind
of test often turns up "unexpected" problems.  I recall that
early in the days of Windows NT, this kind of approach uncovered
bugs that led to complete system hangs (I'd hope they have fixed
such things by now, and that MS themselves make sure they are the
first to find such things by trying such tests in-house before
releasing new kernels; thankfully I don't have to use NT or whatever
it's called now, so I don't know).

Same goes for UIs; some kinds of testing involve sending random
UI events at a program until it crashes or does something incorrect.

Sure, it's generally not possible to test *every* possible state
of large software, but this doesn't mean that testing *many* states,
particularly states that might not be "expected", by feeding it
random data, is not a valid, important, and sometimes fruitful approach.

--Benjamin

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Benjamin Ketcham" <bketcham@drizzle.com> wrote in message
news:1094529422.982635@yasure...
> Richard  Riehle <adaworks@earthlink.net> wrote:
> >
> > Finally, testing can only test for what we know needs to be tested.   We
> > must design for the unexpected, even as we test for the expected.  It is
> > impossible to test for the unexpected.
>
> While I agree with the overall point here, I keep seeing this
> assertion, here made with especially great conviction: "it is
> impossible to test for the unexpected".  As with many absolute
> statements, it is not technically correct, although it expresses
> a valid general truth.  Consider the method of kernel testing
> where system calls are invoked with random arguments; this kind
> of test often turns up "unexpected" problems.

Yes, Benjamin, I may have been a little too over the top in
my use of the word, "impossible."   I too have seen test plans
and test scripts that randomly traverse that entire universe of
possibilities to make sure that none of the unwanted combinations
of keyboard entries (or other data sources) are allowed to pass
at run-time.

One of the benefits of assertions (DbC) is that one can simply
declare a range of unacceptable conditions as part of the design
and be assured that those conditions will not be permitted to
occur.

Even so, whether programming with assertions, or using a test-driven
approach, one needs to be a little careful about depending too much
on the tests or the assertions.   Moreover, a well-designed program
must be about more than simple correctness, even as hard as that
is.

Much has been said, in this forum, about the wonders of test-driven
design in dynamically-typed languages as a benefit to on-going change
in a program.   In other forums that deal with this topic, advocates of
TDD include refactoring as one of the mechanisms of choice.   No
reasonable person will deny that, under some circumstances and for
some kinds of software, these are acceptable models of development.
We are always compelled to ask about the limits of any tool, method,
or style.  To answer, "There are no limits," is to consign oneself in the
league of the naive.

Static typing, design by contract, and other static methods are certainly
limited in what they can accomplish.   So too, we must recognize the
limits of the dynamic approach.   As we examine those limits, for
both approaches, we are required to also examine the trade-offs and
risks associated with them.   Is one approach more dependable for
a given domain than the other approach?  Is one more economical than
the other for the context in which it will be used?

This kind of inquiry is not unlike any other engineering exercise.  We
are in pursuit of a predictable outcome, an outcome that satisfies a
defined set of requirements.  Whether those requirements are specified
as the tests themselves (as in TDD), or embedded within the assertions
(as in DbC),  in the type definitions and associated methods, or some
combination, the goal is the same.

Engineering is concerned with design.   Engineeering prefers, as much as
possible, settled knowledge rather than a continual test-debug model.
We try to get the design as close to correct early, even testing parts of
it along the way as we build it.   However, testing every aspect of the
design is not always possible.   In particular, as the deployed design
is required to deal with the real world, it must be able to adapt itself
to the unexpected.

Let me give you an example.   In am system I know something about,
one with a large number of components,  a programmer included a
routine that had a built-in constraint (not a type constraint), in the
form of an if ... end if statement.    The constraint was cleverly
written and the language in use was not strongly typed, so the
programmer could use long (as in long integer) as a reasonable
data type for his algorithmic mischief.    I say mischief because
that was what it was, a small time-bomb intended to crash the
program long after he resigned and went on to another job.

No amount of testing would have caught this. He was clever
enough to see to that.   The design was not type safe, so the
result from his routine could be easily passed to some other
routine as a parameter.   You many argue to the contrary,
but the test scripts (well-designed) did not catch the error.
When it occurred, the system failed, and no one knew why
until a considerable amount of analysis was performed.

Experienced software designers could easily relate many more
such stories.   Engineering history is full of them.  Knowing that,
in the world of physical engineering, where we are constrained
by physics and can measure everything down to very fine
tolerances, and still make disastrous mistakes, how do we justify
any approach to software engineering that limits us to a single
approach to creating dependable software?     This question
is especially important with the increased use of software in
safety-critical systems.

Finally, I truly hope that no Lisp programmer, Smalltalk
enthusiast, or their ilk will persuade the designers of
flight avionics to begin using those languages.   It is bad
enough that some of them have chosen to use C and
C++.   We need to, as always, select the right tool for
the job at hand.

Richard Riehle

Re: ADA Popularity Discussion Request

[jayessay]

"Richard  Riehle" <adaworks@earthlink.net> writes:

> One of the benefits of assertions (DbC) is that one can simply
> declare a range of unacceptable conditions as part of the design
> and be assured that those conditions will not be permitted to
> occur.

There is nothing about this that is incompatible with dynamic typing.
If you wanted you could implement the whole Eiffel Dbc thing (and then
some) as a set of macros using CLOS within Common Lisp.  As I recall
now, someone actually did this (I will try to find it).


>    Moreover, a well-designed program must be about more than simple
> correctness, even as hard as that is.

Agreed (if for no other reason than what "correctness" means is
typically vague - even in very well designed and specified systems.)


> In particular, as the deployed design is required to deal with the
> real world, it must be able to adapt itself to the unexpected.

This is a particularly apropos aspect of systems built with dynamic
systems.  Evolvable and adaptable are key descriptors.


> Let me give you an example.  In am system I know something about,
> one with a large number of components, a programmer included a
> routine that had a built-in constraint (not a type constraint), in
> the form of an if ... end if statement.  The constraint was cleverly
> written and the language in use was not strongly typed, so the

Just to be clear "not strongly typed" and "not type safe" have nothing
to do with dynamically typed.


> but the test scripts (well-designed) did not catch the error.  When
> it occurred, the system failed, and no one knew why until a
> considerable amount of analysis was performed.

Also, just for clarity, are you saying you believe static typing would
have made a difference here?  You can dream up plausible scenarios
where it might have but equally plausible scenarios it wouldn't have.
I actually think dynamic typing would be significantly more
efficacious here (if not any more than static typing in prevention,
then certainly in immediately pinpointing the problem).


> Finally, I truly hope that no Lisp programmer, Smalltalk enthusiast,
> or their ilk will persuade the designers of flight avionics to begin
> using those languages.

I'm not advocating this - mostly because I don't think this domain
needs the kind of flexibility and expressiveness that comes from Lisp.
This stuff belongs to a very well bounded and concretely defined
domain.


> It is bad enough that some of them have chosen to use C and C++.  We
> need to, as always, select the right tool for the job at hand.

This, OTOH is just implicitly cast FUD, presumably intended to imply
that something like Common Lisp would not "work well" here.  I will
absolutely make the claim that such an offering would be every bit as
robust and "correct" as anything fielded.  It is likely it would also
be rather more maintainable.

Maybe you are simply saying that the resources available here are
still just too small to make this a viable option.  I'm sure there are
still a lot of things out there with just a few kilobytes available.
Then again, Garmine has some pretty impressive boxes and last I looked
Avidyne was still using WindozeNT/2000(!!!) as its base.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Mark Lorenzen]

jayessay <nospam@foo.com> writes:

> "Richard  Riehle" <adaworks@earthlink.net> writes:
> 
> > One of the benefits of assertions (DbC) is that one can simply
> > declare a range of unacceptable conditions as part of the design
> > and be assured that those conditions will not be permitted to
> > occur.
> 
> There is nothing about this that is incompatible with dynamic typing.
> If you wanted you could implement the whole Eiffel Dbc thing (and then
> some) as a set of macros using CLOS within Common Lisp.  As I recall
> now, someone actually did this (I will try to find it).
> 
> 
> >    Moreover, a well-designed program must be about more than simple
> > correctness, even as hard as that is.
> 
> Agreed (if for no other reason than what "correctness" means is
> typically vague - even in very well designed and specified systems.)
> 
> 
> > In particular, as the deployed design is required to deal with the
> > real world, it must be able to adapt itself to the unexpected.
> 
> This is a particularly apropos aspect of systems built with dynamic
> systems.  Evolvable and adaptable are key descriptors.
> 
> 
> > Let me give you an example.  In am system I know something about,
> > one with a large number of components, a programmer included a
> > routine that had a built-in constraint (not a type constraint), in
> > the form of an if ... end if statement.  The constraint was cleverly
> > written and the language in use was not strongly typed, so the
> 
> Just to be clear "not strongly typed" and "not type safe" have nothing
> to do with dynamically typed.
> 
> 
> > but the test scripts (well-designed) did not catch the error.  When
> > it occurred, the system failed, and no one knew why until a
> > considerable amount of analysis was performed.
> 
> Also, just for clarity, are you saying you believe static typing would
> have made a difference here?  You can dream up plausible scenarios
> where it might have but equally plausible scenarios it wouldn't have.
> I actually think dynamic typing would be significantly more
> efficacious here (if not any more than static typing in prevention,
> then certainly in immediately pinpointing the problem).
> 
> 
> > Finally, I truly hope that no Lisp programmer, Smalltalk enthusiast,
> > or their ilk will persuade the designers of flight avionics to begin
> > using those languages.
> 
> I'm not advocating this - mostly because I don't think this domain
> needs the kind of flexibility and expressiveness that comes from Lisp.
> This stuff belongs to a very well bounded and concretely defined
> domain.
> 
> 
> > It is bad enough that some of them have chosen to use C and C++.  We
> > need to, as always, select the right tool for the job at hand.
> 
> This, OTOH is just implicitly cast FUD, presumably intended to imply
> that something like Common Lisp would not "work well" here.  I will
> absolutely make the claim that such an offering would be every bit as
> robust and "correct" as anything fielded.  It is likely it would also
> be rather more maintainable.

More maintainable? The pieces of LISP code you have shown so far are
even less readable than French. It does not communicate any
information about the problem domain to the reader, it is just a
clever hack used to save some keystrokes.

Why oh why do they continue to teach LISP in the US? They should teach
ML instead.

> 
> Maybe you are simply saying that the resources available here are
> still just too small to make this a viable option.  I'm sure there are
> still a lot of things out there with just a few kilobytes available.
> Then again, Garmine has some pretty impressive boxes and last I looked
> Avidyne was still using WindozeNT/2000(!!!) as its base.
> 
> 
> /Jon
> 
> -- 
> 'j' - a n t h o n y at romeo/charley/november com

Regards,
- Mark Lorenzen

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Mark Lorenzen" <mark.lorenzen@ofir.dk> wrote in message
news:m3vfep90v7.fsf@0x5358ceb2.boanxx18.adsl-dhcp.tele.dk...
>
> Why oh why do they continue to teach LISP in the US? They should teach
> ML instead.
>
Lisp continues to be a useful tool for many kinds of applications.
It is, however, important that we understand the limits of each
our tools.  We must recognize that Lisp has its virtues, but also
know when to choose a toolset more appropriate for the problem
at hand.   Ada developers, those with a lot of experience in
developing software, understand that they must sometimes
combine code from some other language model in their
programs.  Fortunately, one of the significant virtues of
Ada is its friendliness to other languages -- something we
cannot acknowledge about many other popular languages.

Also, I would be more inclined to choose CAML or
OCAML than ML at this time in the development of the ML
family.  Do you have a reason for eschewing  OCAML in
favor of ML?

Richard Riehle

Re: ADA Popularity Discussion Request

[Mark Lorenzen]

"Richard  Riehle" <adaworks@earthlink.net> writes:

> "Mark Lorenzen" <mark.lorenzen@ofir.dk> wrote in message
> news:m3vfep90v7.fsf@0x5358ceb2.boanxx18.adsl-dhcp.tele.dk...
> >
> > Why oh why do they continue to teach LISP in the US? They should teach
> > ML instead.
> >
> Lisp continues to be a useful tool for many kinds of applications.
> It is, however, important that we understand the limits of each
> our tools.  We must recognize that Lisp has its virtues, but also
> know when to choose a toolset more appropriate for the problem
> at hand.   Ada developers, those with a lot of experience in
> developing software, understand that they must sometimes
> combine code from some other language model in their
> programs.  Fortunately, one of the significant virtues of
> Ada is its friendliness to other languages -- something we
> cannot acknowledge about many other popular languages.

I agree, it is just that I think Lisp is a "strange" language to use
in a programming class.

> 
> Also, I would be more inclined to choose CAML or
> OCAML than ML at this time in the development of the ML
> family.  Do you have a reason for eschewing  OCAML in
> favor of ML?

I do not have a special reason. We used ML in my first programming
class back at university, and I still think that it is one of the most
elegant programming languages I have ever encountered. I used it for
nearly all my projects including my thesis. It is an excellent tool
for learning programming and especially if data types are emphasized
from day 1 on, which they should, in order to give the students a
feeling of the difference between math and CS.

One of my colleagues calls my a type-Fascist. I take it as a
compliment.

I do not know enough about OCAML, but maybe it would be a good tool to
learn both applicative, imperative and object oriented programming
using the same language.

> 
> Richard Riehle

- Mark Lorenzen

Re: ADA Popularity Discussion Request

[jayessay]

Mark Lorenzen <mark.lorenzen@ofir.dk> writes:

> "Richard  Riehle" <adaworks@earthlink.net> writes:
> 
> > "Mark Lorenzen" <mark.lorenzen@ofir.dk> wrote in message
> > news:m3vfep90v7.fsf@0x5358ceb2.boanxx18.adsl-dhcp.tele.dk...
> > >
> > > Why oh why do they continue to teach LISP in the US? They should teach
> > > ML instead.
> > >
> > Lisp continues to be a useful tool for many kinds of applications.
> > It is, however, important that we understand the limits of each
> > our tools.  We must recognize that Lisp has its virtues, but also
> > know when to choose a toolset more appropriate for the problem
> > at hand.   Ada developers, those with a lot of experience in
> > developing software, understand that they must sometimes
> > combine code from some other language model in their
> > programs.  Fortunately, one of the significant virtues of
> > Ada is its friendliness to other languages -- something we
> > cannot acknowledge about many other popular languages.
> 
> I agree, it is just that I think Lisp is a "strange" language to use
> in a programming class.

Now there is an insightful remark...

/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[jayessay]

Mark Lorenzen <mark.lorenzen@ofir.dk> writes:

> jayessay <nospam@foo.com> writes:
> > This, OTOH is just implicitly cast FUD, presumably intended to imply
> > that something like Common Lisp would not "work well" here.  I will
> > absolutely make the claim that such an offering would be every bit as
> > robust and "correct" as anything fielded.  It is likely it would also
> > be rather more maintainable.
> 
> More maintainable?

Yes, but I don't expect you to realize this as you clearly haven't
used the concepts behind it.


> The pieces of LISP code you have shown so far are even less readable
> than French.

Wow.  I wonder what French speakers would say.


> It does not communicate any information about the problem domain to
> the reader, it is just a clever hack used to save some keystrokes.

Snippets _have_ no domain except the vague one of "example for
discussion".  Sheesh!  Give a snippet out of context in _any_ thing and
it won't communicate anything about any "domain".


> Why oh why do they continue to teach LISP in the US? They should
> teach ML instead.

In general, neither is taught.  As for ML, why choose that??  Haskell
would be a better choice if you are a formal static type fanatic.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Jean-Marc Bourguet]

jayessay <nospam@foo.com> writes:

> > The pieces of LISP code you have shown so far are even less readable
> > than French.
> 
> Wow.  I wonder what French speakers would say.

We (those who can read at least) obviously agree.

Yours,

-- 
Jean-Marc

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
 
: If you wanted you could implement the whole Eiffel Dbc thing (and then
: some) as a set of macros using CLOS within Common Lisp.  As I recall
: now, someone actually did this (I will try to find it).

Whether you can implement static DbC in CLOS is the more intereisting
question. Compare to SPARK.


-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> jayessay <nospam@foo.com> wrote:
>  
> : If you wanted you could implement the whole Eiffel Dbc thing (and then
> : some) as a set of macros using CLOS within Common Lisp.  As I recall
> : now, someone actually did this (I will try to find it).
> 
> Whether you can implement static DbC in CLOS is the more intereisting
> question. Compare to SPARK.

Yes, that is exactly the idea.  You would create a set of macros to
allow a natural expression for this.  Macros do all their work at
compile time.  Macros are "just" functions which are code transformers
- you have the entire power of Lisp available and can write complete
compilers (lex -> syntax -> ast -> semantic analysis -> optimization
-> code generation) and have the result integrated transparently with
the rest of the language.

ACL2 is another example of this sort thing.  It is an applicative
system with type inference and theorem proving used by Motorola, AMD,
Rockwell Collins, et.al. for modeling and proving properties of
commercial microprocessors.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Kevin Cline]

"Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<_xl%c.431$xA1.301@newsread3.news.pas.earthlink.net>...

> Much has been said, in this forum, about the wonders of test-driven
> design in dynamically-typed languages as a benefit to on-going change
> in a program.  

The original question was "Why isn't Ada more popular?"  For general
non-safety critical applications, there is now some question whether
the benefits of static typing outweigh the cost.  For the class of
applications you are interested in, I would want to use a language
that allowed me to most easily prove program correctness.  But a
relatively small number of programmers write those applications.

> Engineering is concerned with design.   Engineeering prefers, as much as
> possible, settled knowledge rather than a continual test-debug model.
> We try to get the design as close to correct early, even testing parts of
> it along the way as we build it.   However, testing every aspect of the
> design is not always possible.   In particular, as the deployed design
> is required to deal with the real world, it must be able to adapt itself
> to the unexpected.
> 
> Let me give you an example.   In am system I know something about,
> one with a large number of components,  a programmer included a
> routine that had a built-in constraint (not a type constraint), in the
> form of an if ... end if statement.    The constraint was cleverly
> written and the language in use was not strongly typed, so the
> programmer could use long (as in long integer) as a reasonable
> data type for his algorithmic mischief.    I say mischief because
> that was what it was, a small time-bomb intended to crash the
> program long after he resigned and went on to another job.

It might be possible to build a system to fail-safe in one component
or another,  but there is no software defense against buggy code,
whether introduced deliberately or inadvertently.  Even if the
function returned a value in range it could have been written to
return an incorrect value for certain inputs.  For a great many
applications, crashing is preferable to incorrect output.

> No amount of testing would have caught this. 

No, but an inspection could have and should have.  

> Experienced software designers could easily relate many more
> such stories.  

I don't have much experience with sabotaging programmers, but have a
lot of experience with code that is just wrong.  Some of it was Ada
code.  I found out that it is extremely difficult to write code and
then test it, although coverage analysis helps.  I've found that
writing tests and then coding to meet them works better.  At least you
are forced to think very clearly about exactly what it is you are
trying to do before you start doing it, and you have a clear
indication of when you are done.

Re: ADA Popularity Discussion Request

[Jean-Pierre Rosen]

Richard Riehle a écrit :


> Finally, testing can only test for what we know needs to be tested.   We
> must design for the unexpected, even as we test for the expected.  
As the saying goes:
"Once you've taken care of the unexpected, consider the unexpected 
unexpected"

Exceptions forever!

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: ADA Popularity Discussion Request

[Kevin Cline]

"Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<vS8%c.69$xA1.4@newsread3.news.pas.earthlink.net>...
> "Kevin Cline" <kevin.cline@gmail.com> wrote in message
> news:e749549b.0409051449.574ec9ce@posting.google.com...
> > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message
> news:<vpblkhspuA9F@eisner.encompasserve.org>...
> 
> > > But assuming perfect testing, finding the errors during compilation
> > > rather than in testing saves me time, and time is money.
> >
> > I thought so too, until I tried incremental test-first development.
> > Retesting a unit after adding a few lines of code means that type
> > mismatches are caught immediately with or without strong typing.  But
> > it goes faster if you don't have to compile and link every iteration.
> >
> This assumes that we are concerned only with type mismatches.   In
> Ada, we expect the compiler to provide a great deal more than that.
> 
> For small software systems, frequent testing can often be sufficient. As
> the size of the software increases, and complexity of that software grows,
> we must engage all the tools available and use them appropriately to
> ensure the correctness of our design.   Also, in large software systems,
> it is not possible to test every path, every possible value of a variable,
> and every potential timing problem.
> 
> How does one test for a race condition?   

I don't test for race conditions.  I try to isolate code potentially
subject to race conditions or deadlocks to a small program unit, and
then, if necessary, prove it correct.

> Does that test guarantee
> no race condition can occur?  

> This is not a type checking issue, but
> it is a design issue where the type model can be one of many factors
> in reasoning about the stability of the design.
> 
> How does one test for a runaway pointer or dangling reference?  

I don't test for these.  As a general rule, I don't write code that
would make them possible.  When I do have to write unsafe code, then I
encapsulate it tightly so that the code is either obviously correct or
can be verified correct in short order.

> Again,
> this is not strictly a type issue, except that Ada's overall set of rules,
> including the type rules, provide some tools for reasoning about this
> intelligently.

Working safely with dynamically allocated objects in Ada-83 means
using unhecked_allocation and deallocation, which reqired almost as
much diligence
as using malloc/free in C.  Then C++ appeared with constructors and
destructors and auto_ptr, and memory management got a lot easier. 
Then Ada-95 added controlled types, but by then C++ had huge
mindshare.

> Finally, testing can only test for what we know needs to be tested.   We
> must design for the unexpected, even as we test for the expected.  It is
> impossible to test for the unexpected.   The Ada type model includes
> both the compile-time checking and the run-time checking.   The rest
> of Ada provides a wide range of compile-time checks.
> 
> Those who fail to understand this should stay away from building software
> that requires a high degree of dependability.

What do you mean by the unexpected?  It seems that everything that
could happen to software can be anticipated, except for total failure
of the underlying execution engine.  Or do you mean unexpected
exceptions or incorrect values returned by unexpected software errors?

Re: ADA Popularity Discussion Request

[Lurker]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0409141214.215492cf@posting.google.com...
> "Richard  Riehle" <adaworks@earthlink.net> wrote in message
news:<vS8%c.69$xA1.4@newsread3.news.pas.earthlink.net>...

> > How does one test for a race condition?
>
> I don't test for race conditions.

> > How does one test for a runaway pointer or dangling reference?
>
> I don't test for these.

So you don't test for two major sources of errors?

>  As a general rule, I don't write code that
> would make them possible.

Good. But since you don't use testing
to achieve that you must be using something
else, right?

Re: ADA Popularity Discussion Request

[Lionel Draghi]

Kevin Cline wrote:
...

> Retesting a unit after adding a few lines of code means that type
> mismatches are caught immediately with or without strong typing.
With strong typing, you will catch it at code compilation.
Without, you will maybe catch it at test execution.
The former seems much more "immediate" than the later to me.

> But it goes faster if you don't have to compile and link every iteration.
So, use strong typing. Not only will save a lot of useless tests 
compilation, but also test writing.

-- 
Lionel Draghi

Re: ADA Popularity Discussion Request

[Ole-Hjalmar Kristensen]

>>>>> "j" == jayessay  <nospam@foo.com> writes:

    j> "Richard  Riehle" <adaworks@earthlink.net> writes:
    >> "jayessay" <nospam@foo.com> wrote in message
    >> news:m3isb2ey3w.fsf@rigel.goldenthreadtech.com...
    >> > "Richard  Riehle" <adaworks@earthlink.net> writes:
    >> >
    j> ...
    >> Ada and Eiffel are designed with more compile-time checking capabilities
    >> than Smalltalk.

    j> Static typing is largely overrated - even Hindley-Milner type systems
    j> such as in Haskell or ML (which are significantly more potent than the
    j> type systems of Eiffel or Ada).  The whole thing sounds great in
    j> theory and you can make some pretty plausible arguments for its
    j> efficacy, but it just doesn't make much difference in practice.

    j> I used to be a real advocate of this stuff and made those arguments
    j> myself (both here and elsewhere).  It (static typing) was one of the
    j> things I was unsure about losing when I switched to Common Lisp (aka
    j> Lisp in this message) for all my major work 7 years ago.  So, I kept a
    j> log of all the errors that I knew would have been caught by compile
    j> time type checking.  I don't rigorously follow this practice anymore,
    j> but as I recall there were only 15 or so in 50K "lines" of Lisp [1].
    j> Furthermore, all but a couple of these were caught immediately on
    j> first testing of function in question.  No such errors ever manefested
    j> themselves in production code.  Yes, I know the typical rebuttal here
    j> is "Yet!".  In theory that's true, but the evidence at this point
    j> suggests it is extremely unlikely.  Also, logic errors (what most
    j> people would consider significantly more negative) are far rarer.

    j> There turn out to be various reasons for this, but two worth
    j> mentioning are the sort of bottom up style of programming as described
    j> by Paul Graham (a kind of agile/extreme programming) and the ability
    j> to move Lisp to the expressive level of the application domain.

    j> In any application/system of any significance these two go hand in
    j> hand.  The second is achieved by crafting a constrained narrowly
    j> focused domain specific language _within_ Lisp, which allows the
    j> programmer to then work at the level of the domain, _both_
    j> syntactically as well as semantically.  This is why Lisp macros
    j> (please don't confuse with any other kind of macro you've come across
    j> before) are such a big deal.

    j> Now, admittedly, creating these is not something your typical code
    j> monkey is going to grok.  This is one of the big reasons why Lisp will
    j> never be as "popular" as something like Java.  But then your typical
    j> code monkey isn't going to be building your core internal application
    j> api either.  Once you've built this though, even a code monkey will be
    j> a lot more productive and produce much more clean and robust code.

I do not consider myself a Lisp programmer, but I have programmed
enough Lisp to conclude that you probably are correct that the ability
to create a constrained narrowly focused domain specific language
within Lisp could very well outweigh the advantages of static typing.
But for the last years I have been mainly working with soft real time,
multi-threaded systems. I am aware of the existence of real-time
garbage collectors, but what about multi-threading? Common Lisp used
to be pretty weak in this respect, has this changed?

<snip>

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: ADA Popularity Discussion Request

[jayessay]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com>
writes:

> >>>>> "j" == jayessay  <nospam@foo.com> writes:
> 
>     j> In any application/system of any significance these two go hand in
>     j> hand.  The second is achieved by crafting a constrained narrowly
>     j> focused domain specific language _within_ Lisp, which allows the
>     j> programmer to then work at the level of the domain, _both_
>     j> syntactically as well as semantically.  This is why Lisp macros
>     j> (please don't confuse with any other kind of macro you've come across
>     j> before) are such a big deal.
> 
>     j> Now, admittedly, creating these is not something your typical code
>     j> monkey is going to grok.  This is one of the big reasons why Lisp will
>     j> never be as "popular" as something like Java.  But then your typical
>     j> code monkey isn't going to be building your core internal application
>     j> api either.  Once you've built this though, even a code monkey will be
>     j> a lot more productive and produce much more clean and robust code.
> 
> I do not consider myself a Lisp programmer, but I have programmed
> enough Lisp to conclude that you probably are correct that the ability
> to create a constrained narrowly focused domain specific language
> within Lisp could very well outweigh the advantages of static typing.

If you've been there, you know this.  Actually, the incremental bottom
up development with _continual_ testing of almost every code snippet
is a significant advance above static typing.  In this sort of
development you are typically _extensively testing even partial
expressions or single clauses_ (well below the level of a function)
and at each increment of accretion testing that until you have a
function at which point it is tested.  The upshot is you have a
stunning level of code path coverage - not just for type checks, but
logic checks as well.

Since you are not saddled with the typical
write-try-to-compile-rewrite-compile-try-to-link-rewrite-... finally
try to test something cycle this can be done _extremely_ efficiently
and timely.  You will catch errors _much faster_ than compile time
checking - you are checking the correctness of code paths through most
every singl path possible.  You don't wait to build tests at the
higher levels with input cases which you "hope/believe" will exercise
"most" of these paths.  This is also why _logic_ errors are also far
rarer.


> But for the last years I have been mainly working with soft real time,
> multi-threaded systems. I am aware of the existence of real-time
> garbage collectors, but what about multi-threading? Common Lisp used
> to be pretty weak in this respect, has this changed?

Multi-threading has actually always been available.  All the
implementations provide an MP facility modeled on the Lisp Machine's -
they are not 100% the same as this is a "industry standard" and not
yet in the ANSI standard, but they are very very close.  So moving
code from one to another is actually very easy.

I have used multi-threading in basically all my work for years now and
don't even think much of it anymore.  In many ways, multi-threading is
far simpler and more robust in Common Lisp than most anything else for
a variety of reasons.  Two big ones: 1) you can build your own tasking
model and _embed it within the language_ for the type of tasking you
will be using.  So your code will be succinct, clean and _natural_.
2) Dynamic variables are simply amazing for reducing the much of the
programming complexity of multi-threaded applications to nearly that
of single-threaded.

As for real-time GC, it depends on what you mean by "soft real time".
If this really just means something like "it should run fast" or "I
can't have any pauses" or some such, then any good modern generational
GC will be more than sufficient.  I've only had to tune the GC in a
couple of really _huge_ application cases.  Generally, such modern GCs
will never use up more than a fraction of a _one_ percent of the
runtime and will typically out perform manual heap management by quite
a bit.

If you really mean guaranteed response and runtimes, you may well need
to roll your own, use a form of manual management, or maybe this case
just isn't a good fit for Common Lisp.  There are some bare metal
Schemes out there that might work.


/Jon


-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
: Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com>
: writes:
: 
:> >>>>> "j" == jayessay  <nospam@foo.com> writes:
:> 
:>     j> In any application/system of any significance these two go hand in
:>     j> hand.  The second is achieved by crafting a constrained narrowly
:>     j> focused domain specific language _within_ Lisp, which allows the
:>     j> programmer to then work at the level of the domain, _both_
:>     j> syntactically as well as semantically.  This is why Lisp macros
:>     j> (please don't confuse with any other kind of macro you've come across
:>     j> before) are such a big deal.
:> 
:>     j> Now, admittedly, creating these is not something your typical code
:>     j> monkey is going to grok.  This is one of the big reasons why Lisp will
:>     j> never be as "popular" as something like Java.  But then your typical
:>     j> code monkey isn't going to be building your core internal application
:>     j> api either.  Once you've built this though, even a code monkey will be
:>     j> a lot more productive and produce much more clean and robust code.
:> 
:> I do not consider myself a Lisp programmer, but I have programmed
:> enough Lisp to conclude that you probably are correct that the ability
:> to create a constrained narrowly focused domain specific language
:> within Lisp could very well outweigh the advantages of static typing.
: 
: If you've been there, you know this.  Actually, the incremental bottom
: up development with _continual_ testing of almost every code snippet
: is a significant advance above static typing.

I do these little steps all the time, _with_ static type checks,
documenting my expectations in lots of small test-programs.
But why do you assume that static typing replaces the need to test
every corner of the software?

: In this sort of
: development you are typically _extensively testing even partial
: expressions or single clauses_ (well below the level of a function)
: and at each increment of accretion testing that until you have a
: function at which point it is tested.

Yes, tested...

: The upshot is you have a
: stunning level of code path coverage - not just for type checks, but
: logic checks as well.

But the "incremental testing fans" do not assume that testing many
cases will give them type coverage?

Likewise, I guess they know that the set of paths tested and the set
of paths taken at runtime may have little overlap in unwelcome cases
(given some types are large)?


-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> jayessay <nospam@foo.com> wrote:
> : Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@.com>
...
> :> 
> :> I do not consider myself a Lisp programmer, but I have programmed
> :> enough Lisp to conclude that you probably are correct that the ability
> :> to create a constrained narrowly focused domain specific language
> :> within Lisp could very well outweigh the advantages of static typing.
> : 
> : If you've been there, you know this.  Actually, the incremental bottom
> : up development with _continual_ testing of almost every code snippet
> : is a significant advance above static typing.
> 
> I do these little steps all the time, _with_ static type checks,
> documenting my expectations in lots of small test-programs.

You can't.  Because the sort of snippets I'm discussing are not even
legal programs in things like C++/Ada/Eiffel/etc.

How do you do stuff like this:

;; Does the log reader return the correct forms for a log file
(alice:read-unanswered-log "../alice-unanswered.log")

You can simply ask Lisp to try this and see the results

;; Is the format properly formed for output to a client bin widget
(with-open-bin (:bin-id 1440691622 :session-number 12)
  (put-bin (alice:read-unanswered-log "./alice-unanswered.log")))

Same here - but this will also go over to a connected client and you
can see if all that protocol is correctly working.

(set-of-names (the-objects-in-bin 1440691622))

Just get a pretty printed output of the internal structure of the
client widget content.

Doing this in Ada/C++/Eiffel would require setting up a fairly big
procedure/function with all sorts of withs or imports and
instantiations, etc just to get to the one line out of hundred or so
that you want to test.  The whole idea is a complete non starter.

Or how about:

(with-protected-resource *main-database*
  (let ((broken-bits (ensure-consistent-state it)))
    (when broken-bits
      (pprint-db-items broken-bits))))


Here, you'd need to set up a couple of tasks and probably a protected
object plus more boiler plate.

You simply cannot do this sort of thing in stactic languages.  You
shouldn't be bothered by this because you are claiming static type
checks are worth the price of losing this sort of thing.


> But why do you assume that static typing replaces the need to test
> every corner of the software?

I don't.  Obviously it doesn't.  No one believes that it does.  You
are hacking at a strawman.


> But the "incremental testing fans" do not assume that testing many
> cases will give them type coverage?

There is no assumption.  First dynamic typing is as strong (robust) as
static typing.  Second, testing many cases is irrelevant.  Testing
_outside_ the expected envelope is key.  Once you have accounted for
this you are set to go.  As you evolve the functionality input
producing erroneous results (type or logic) is caught futher and
further up the chain.  At each point you account for this and
continue.


> Likewise, I guess they know that the set of paths tested and the set
> of paths taken at runtime may have little overlap in unwelcome cases
> (given some types are large)?

See above.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:> jayessay <nospam@foo.com> wrote:
:> : Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@.com>
: ...
:> :> 
:> :> I do not consider myself a Lisp programmer, but I have programmed
:> :> enough Lisp to conclude that you probably are correct that the ability
:> :> to create a constrained narrowly focused domain specific language
:> :> within Lisp could very well outweigh the advantages of static typing.
:> : 
:> : If you've been there, you know this.  Actually, the incremental bottom
:> : up development with _continual_ testing of almost every code snippet
:> : is a significant advance above static typing.
:> 
:> I do these little steps all the time, _with_ static type checks,
:> documenting my expectations in lots of small test-programs.
: 
: You can't.  Because the sort of snippets I'm discussing are not even
: legal programs in things like C++/Ada/Eiffel/etc.
: 
: How do you do stuff like this:
: 
: ;; Does the log reader return the correct forms for a log file
: (alice:read-unanswered-log "../alice-unanswered.log")

with Alice;
procedure test is
begin
   Alice.read_unanswered_log("../alice-unanswered.log");
end test;

 
: Doing this in Ada/C++/Eiffel would require setting up a fairly big
: procedure/function with all sorts of withs or imports and
: instantiations, etc just to get to the one line out of hundred or so
: that you want to test.

Huh?  The fact that you have a big, hopefully tested and checked
library/system full of convenient things in CL may be a plus if you
can use it. If I have a big Ada library, I expect to use it as an
Ada library. Ada is explicit and verbose. You get something in return.


: The whole idea is a complete non starter.

Not for me. A can live with some typing on the keyboard.
If I want to do incremental try-out programming, I know where to get it.
(Lisps, Smalltalk,  ...)


: Or how about:
: 
: (with-protected-resource *main-database*
:  (let ((broken-bits (ensure-consistent-state it)))
:    (when broken-bits
:      (pprint-db-items broken-bits))))
: 
: 
: Here, you'd need to set up a couple of tasks and probably a protected
: object plus more boiler plate.

Here, someone has provided a set of identifiers implicitly setting
up a couple of task and some such I guess. How much time has it
taken to define all this using testing and run-time type checking,
when you compare to the time needed to do the "same" thing with
static type checks on? Seems a more interesting question. The 
possibility to do amazing things in Lisp is beside the point I
think.

: You simply cannot do this sort of thing in stactic languages.  You
: shouldn't be bothered by this because you are claiming static type
: checks are worth the price of losing this sort of thing.

Why should static type checking be in the way of every dynamic
thing? True, sometimes being explicit about everything using types
can be combersome plus Lisp has EVAL and macros, adding power...


:> But why do you assume that static typing replaces the need to test
:> every corner of the software?
: 
: I don't.  Obviously it doesn't.  No one believes that it does.  You
: are hacking at a strawman.

From what you were saying (sounding like static type checks are
a waste of time) I thought it wasn't obvious.


:> But the "incremental testing fans" do not assume that testing many
:> cases will give them type coverage?
: 
: There is no assumption.  First dynamic typing is as strong (robust) as
: static typing.

At run-time only ... Or at try-out time, maybe?

: Second, testing many cases is irrelevant.  Testing
: _outside_ the expected envelope is key.

A type defines an envelope, known to both the compiler at 
compile time and the program at run time, or test time.
So you have at least told your readers where outside is.

Testing inside is important as well, because unless proven
you don't know for sure which values are inside and outside, resp..
As someone said somewhere else in this thread, test the
unexpected unexpected :-)

: Once you have accounted for
: this you are set to go.  As you evolve the functionality input
: producing erroneous results (type or logic) is caught futher and
: further up the chain.  At each point you account for this and
: continue.
 
And the use of types removes some of the need to test
a function with arguments that cannot be passed to the function
because the compiler has checked.



-- Georg

Re: ADA Popularity Discussion Request

[jayessay]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> jayessay <nospam@foo.com> wrote:
> : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
> : 
> :> jayessay <nospam@foo.com> wrote:
> :> : Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@.com>
> : ...
> :> :> 
> :> :> I do not consider myself a Lisp programmer, but I have programmed
> :> :> enough Lisp to conclude that you probably are correct that the ability
> :> :> to create a constrained narrowly focused domain specific language
> :> :> within Lisp could very well outweigh the advantages of static typing.
> :> : 
> :> : If you've been there, you know this.  Actually, the incremental bottom
> :> : up development with _continual_ testing of almost every code snippet
> :> : is a significant advance above static typing.
> :> 
> :> I do these little steps all the time, _with_ static type checks,
> :> documenting my expectations in lots of small test-programs.
> : 
> : You can't.  Because the sort of snippets I'm discussing are not even
> : legal programs in things like C++/Ada/Eiffel/etc.
> : 
> : How do you do stuff like this:
> : 
> : ;; Does the log reader return the correct forms for a log file
> : (alice:read-unanswered-log "../alice-unanswered.log")
> 
> with Alice;
> procedure test is
> begin
>    Alice.read_unanswered_log("../alice-unanswered.log");
> end test;

This doesn't do you any good because the procedure does not return a
value much less print it out in a form showing the internal structure
of the result.  Plus you still need to compile, link, and then execute
(though emacs will help you a lot with that).


> : Doing this in Ada/C++/Eiffel would require setting up a fairly big
> : procedure/function with all sorts of withs or imports and
> : instantiations, etc just to get to the one line out of hundred or so
> : that you want to test.
> 
> Huh?  The fact that you have a big, hopefully tested and checked
> library/system full of convenient things in CL may be a plus if you
> can use it.

Not just that - you create a sandbox where all this stuff is available
for use and testing as you are developing.  In particular this is all
done incrementally.

> If I have a big Ada library, I expect to use it as an Ada
> library.

Sure, but you don't get this sort of extremely interactive incremental
development with the integrated results always available.


> : The whole idea is a complete non starter.
> 
> Not for me. A can live with some typing on the keyboard.  If I want
> to do incremental try-out programming, I know where to get it.
> (Lisps, Smalltalk, ...)

That's the point - you can't get this with static languages, so the
idea is indeed a non starter there.


> : Or how about:
> : 
> : (with-protected-resource *main-database*
> :  (let ((broken-bits (ensure-consistent-state it)))
> :    (when broken-bits
> :      (pprint-db-items broken-bits))))
> : 
> : 
> : Here, you'd need to set up a couple of tasks and probably a protected
> : object plus more boiler plate.
> 
> Here, someone has provided a set of identifiers implicitly setting
> up a couple of task and some such I guess.

No that is what the with-protected-resource is providing along with
the incremental results that you have been accumulating in your
sandbox.


> How much time has it taken to define all this using testing and
> run-time type checking, when you compare to the time needed to do
> the "same" thing with static type checks on?  Seems a more
> interesting question.

The point is there is no time needed to set this up for this test as
it is already there in your sandbox as the previous bit to which you
are incrementally adding.  So, basically the correct answer here is 0
time.


> : You simply cannot do this sort of thing in stactic languages.  You
> : shouldn't be bothered by this because you are claiming static type
> : checks are worth the price of losing this sort of thing.
> 
> Why should static type checking be in the way of every dynamic
> thing?

It just is - what difference does the "why" part make?


> :> But why do you assume that static typing replaces the need to test
> :> every corner of the software?
> : 
> : I don't.  Obviously it doesn't.  No one believes that it does.  You
> : are hacking at a strawman.
> 
> From what you were saying (sounding like static type checks are
> a waste of time) I thought it wasn't obvious.

If what you have available is static type checking then clearly it
isn't a waste of time.  You basically have the thing backwards: If you
have a dynamic language with "extreme programming" abilities then you
don't miss static typing as what it covers is a _subset_ of what you
get.


> :> But the "incremental testing fans" do not assume that testing many
> :> cases will give them type coverage?
> : 
> : There is no assumption.  First dynamic typing is as strong (robust) as
> : static typing.
> 
> At run-time only ... Or at try-out time, maybe?

If I take "try-out time" to mean development time, the answer is both.


> : Second, testing many cases is irrelevant.  Testing
> : _outside_ the expected envelope is key.
> 
> A type defines an envelope, known to both the compiler at 
> compile time and the program at run time, or test time.

The "both" here is typically not true in static languages.  The reason
should be clear: a type in static typing applies to _variables_ (it is
supposed to define/constrain the kind of value a variable (including
parameters and results) can "hold".  Variables don't actually exist at
runtime.  So, no the program typically has no information about types
at runtime in a static language.  This is what so called RTTI is
intended for in the very limited scope it provides.

In a dynamic language, _values_ have types, variables are just binding
locations, i.e., names which can be used to identify a potential
value.  Hence, full type information is available whenever there are
values - either compile, load, or runtime.


> : Once you have accounted for
> : this you are set to go.  As you evolve the functionality input
> : producing erroneous results (type or logic) is caught futher and
> : further up the chain.  At each point you account for this and
> : continue.
>  
> And the use of types removes some of the need to test a function
> with arguments that cannot be passed to the function because the
> compiler has checked.

I agree that is the "theory", but in practice with a dynamic system
and interactive incremental development it doesn't actually matter as
the types are checked anyway at the time you are checking logic.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:> : How do you do stuff like this:
:> : 
:> : ;; Does the log reader return the correct forms for a log file
:> : (alice:read-unanswered-log "../alice-unanswered.log")
:> 
:> with Alice;
:> procedure test is
:> begin
:>    Alice.read_unanswered_log("../alice-unanswered.log");
:> end test;
: 
: This doesn't do you any good because the procedure does not return a
: value much less print it out in a form showing the internal structure
: of the result.  Plus you still need to compile, link, and then execute
: (though emacs will help you a lot with that).

Ah, wait, I was just showing what I would do in Ada provided I had your
alice:-stuff. As someone has already been mention in another posting,
how am I supposed to know that alice:read-unanswered-log is
a function that returns a value different from the empty list?
It could return a truth value as the comment above it reads as a question,
"Does ...". 
How do you know that read_unanswered_log in my package Alice doesn't
print out a dump? All this is beside the point as it talks about
libraries.


:> If I have a big Ada library, I expect to use it as an Ada
:> library.
: 
: Sure, but you don't get this sort of extremely interactive incremental
: development with the integrated results always available.

What's the measure for "extremely interactive"? 
Sure, writing tests is more work than typing testing expressions
into a REPL. Hopefully the testing exppressions are saved and
documented as regression test?
I'd be courious about a comparison using empirical data for a
program of at least a year of programming done by three or more
persons and a few years of operation.

:> If I want
:> to do incremental try-out programming, I know where to get it.
:> (Lisps, Smalltalk, ...)
: 
: That's the point - you can't get this with static languages, so the
: idea is indeed a non starter there.

I can get something sufficiently similar for the purpose of writing
a number of programs. And I know that in many cases the compiler
has saved me time and reduced anger, and has been helpful in finding
errors.


 
:> Here, someone has provided a set of identifiers implicitly setting
:> up a couple of task and some such I guess.
: 
: No that is what the with-protected-resource is providing along with
: the incremental results that you have been accumulating in your
: sandbox.

Right, incrementing takes time and testing, doesn't it?
 
 
: The point is there is no time needed to set this up for this test as
: it is already there in your sandbox as the previous bit to which you
: are incrementally adding.

There is no sandbox without someone having developed the things
needed to build sandboxes. This takes time /= 0.

:> Why should static type checking be in the way of every dynamic
:> thing?
: 
: It just is - what difference does the "why" part make?
 
"It just is" is not a convincing answer. As a SNOBOL4 fan, I know that
typed values and the ability to look at everything and to have the
compiler at hand in a running program can work miracles, also
miracles of program complexity a.k.a. cleverness.
But saying that static type checks are in the way of every dynamic
thing sounds like denying any kind of dynamics in a language like Ada
(in a Humpty Dumpty style?).  You cannot change executable pieces at
runtime in a typical Ada implementation AFAIK. But with O-O classes
of types operations are chosen at runtime. Is this not dynamic?

 
:> : Second, testing many cases is irrelevant.  Testing
:> : _outside_ the expected envelope is key.
:> 
:> A type defines an envelope, known to both the compiler at 
:> compile time and the program at run time, or test time.
: 
: The "both" here is typically not true in static languages.

Forgive me to think in terms of Ada. All Ada types do carry some type
information, even if limited. Not the same type information that you get
in CL, of course. But, with types and with variables
- you get bounds,
- you get ranges,
- You can ask whether a value belongs to the set of values that
  a type has declared.
- you can ask whether some type parameter is a definite type or not.
- ...

I agree this is not the same as type-of(value). But IIUC you are
typically asked, in Ada, to provide functionality for a set of differently
typed values not by type inspection and conditionals, but by using
interfaces and being explicit about what you do at the outer level.
It is still possible though, in particular with O-O types, to look
at what subtype we have and base decisions on the result deeply
inside some conditional.


:> And the use of types removes some of the need to test a function
:> with arguments that cannot be passed to the function because the
:> compiler has checked.
: 
: I agree that is the "theory", but in practice with a dynamic system
: and interactive incremental development it doesn't actually matter as
: the types are checked anyway at the time you are checking logic.

When I have a

   type Direction is (North, East, South, West);

and then a COND somewhere,

   case d is
      when North => bow;
      when South => spread_arms;
      when East => awake;
      when West => relax;
   end case;

There is no need, in theory and  practice, to test case coverage,
because it is guaranteed by the language rules that the compiler obeys.
Likewise, I cannot just add cases for Up and Down somewhere.

What would I have to do to have the compiler tell me in CL?

If this isn't possible, is there a way to predict the number of test
expressions together with the average time each takes to find missing
cases in all affected parts of the program?

If it is possible, don't you think that it saves lots of time
during code checking and in code restructuring as well?

When I have

   type Foo is array (Direction) of Color;

and then I create a value

   (North => Black, South => Yellow, East => Orange, West => Grey)

I know this value will have been completely initialised with
component values that are allowed for types Foo, Direction, and Color.
Again less testing.

If Direction is to be changed to include Up and Down as values,
both the case distinction and the tuple won't be valid any longer and
the compiler will let me know, as it checkes Foo-dependent
things in the transitive closure of all units depending on
the unit where Foo is defined.

I find this rather practical, for example because it can
guide the "refactoring" process without a need to run the tests
mentioned above.
 The mechanism isn't fool proof, for example when `others`
is used, but it saves time because a computer program (the compiler)
points to code that will or might have to be changed when Foo
changes.
 I think you will recognise this in ML pattern matching, too.


-- Georg

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
: Forgive me to think in terms of Ada. All Ada types do carry some type
                                               ^^^^^
Er, that shouldn't have been "types" of course.


-- Georg

Re: ADA Popularity Discussion Request

[Randy Brukardt]

"jayessay" <nospam@foo.com> wrote in message
news:m3k6v6dwbn.fsf@rigel.goldenthreadtech.com...
...
> You can't.  Because the sort of snippets I'm discussing are not even
> legal programs in things like C++/Ada/Eiffel/etc.
>
> How do you do stuff like this:
>
> ;; Does the log reader return the correct forms for a log file
> (alice:read-unanswered-log "../alice-unanswered.log")
>
> You can simply ask Lisp to try this and see the results
>
> ;; Is the format properly formed for output to a client bin widget
> (with-open-bin (:bin-id 1440691622 :session-number 12)
>   (put-bin (alice:read-unanswered-log "./alice-unanswered.log")))
>
> Same here - but this will also go over to a connected client and you
> can see if all that protocol is correctly working.

Cute, but close to useless in my view. A test that doesn't have the results
included in it (and preferably is automated to return Pass/Fail), or that
isn't saved for future use, is just wasted effort. When the function in
question is updated a year from now, you'll either have to recreate the
entire set of tests, or simply forget the testing -- and either way you'll
end up wasting a lot of time.

Moreover, this sort of stuff is fine for simple functions, but it doesn't
scale to subsystems, where there are many paths and options to test. And it
is at the subsystem level where virtually all logic errors occur - it's hard
to make a mistake in a three line function!

>> But why do you assume that static typing replaces the need to test
>> every corner of the software?

> I don't.  Obviously it doesn't.  No one believes that it does.  You
> are hacking at a strawman.

OK, let *me* hack at the strawman. The goal of programming languages ought
to be to eliminate the need for testing. This is not a goal that is likely
to be achievable, but the closer that we can come, the better.

On low-criticality systems like the Trash Finder spam filter, I don't even
bother to test updates anymore. I simply load it onto the mail server and
check the logs occassionally for problems. I can do this because I have
confidence in the design of the program that it will log any faults and save
the offending message for testing any fix needed.

I consider testing a last resort to use when you can't find any better way
to insure the correctness of your software. Of course, in practice, you do
have to use that last resort for time to time.

                             Randy.

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On Wed, 8 Sep 2004 20:02:36 -0500, Randy Brukardt wrote:

> OK, let *me* hack at the strawman. The goal of programming languages ought
> to be to eliminate the need for testing. This is not a goal that is likely
> to be achievable, but the closer that we can come, the better.

Hear here!

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ADA Popularity Discussion Request

[Lionel Draghi]

jayessay wrote:
...

> Actually, the incremental bottom
> up development with _continual_ testing of almost every code snippet
> is a significant advance above static typing.

> In this sort of
> development you are typically _extensively testing even partial
> expressions or single clauses_ (well below the level of a function)
> and at each increment of accretion testing that until you have a
> function at which point it is tested.  
In this sort of development, you typically *don't* do any extensive 
testing. You more often just test typical use-cases.
Doing extensive testing will certainly not be done with an informal method.

For extensive testing, you need some coverage tools, and this is 
obviously not specific to Agile methods.

If you really want to increase your productivity, just try to avoid 
testing by using formal proof or static analysis tools.
And once more here, strong typing will be your best friend.

-- 
Lionel Draghi

Re: ADA Popularity Discussion Request

[User Name]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> (For example, Robert Axelrodt (The Complexity of Cooperation, 1997,
> Princeton University Press)
... quotes ...

> But what will people who know these languages say about the
> comments?

That Robert Axelrodt is clearly an incompetent in this area and should
not be taken seriously by anyone with even the slightest clue.

It's telling that he uses "FORTRAN" and "LISP", neither of which is
correct. Lisp hasn't been LISP for over 20 years.  Also, in this sort
of context simply using "Lisp" is bogus, as there is no language named
Lisp.  Actually, that's probably been true for over 20 years as well.
And, ANSI standard Common Lisp, the primary Lisp language currently in
use, is every bit an industrial strength general purpose programming
language as the typically cited, yet far more pedestrian, C++, Java,
etc.

> "If a friend or coworker is available to answer questions about
> Pascal, for example, pick Pascal..."

This is so absolutely ridiculous as to evoke embarassment for the
author.

> "C++ was chosen as the foundation for the Java programming language"

This is just nonsense and simply false.


> "If you are fairly sure that you will be doing programming for some
> time and want to start with a language that you can grow with, then
> C or C++ is the best choice."

Complete garbage.  It may not even be the best advice at this point if
you substitute "can make money with" for "can grow with".


> http://pscs.physics.lsa.umich.edu/Software/ComplexCoop.html,

Anyone who uses Pascal for GA is a complete idiot.


/Jon


-- 
'jay' - a n t h o n y at romeo/november/charley com

Re: ADA Popularity Discussion Request

[Alexander E. Kopilovich]

Georg Bauhaus wrote:

> Quite a few people I've met didn't like Ada because of they have
> seen it as associated with the political, military, and industrial
> organisations mentioned in Richard Riehle's posting. Indeed,
> if computer languages and compilers do not care about the purpose
> of a program, people do. (This is a reason why I'm somewhat uncomfortable
> using Ada, sometimes. The military and the weapon makers seem to
> be so close... ;-)

As far as I know, many programmers (and even many software engineers) do not
care much abour military use of their software, but they do care much about
the psychological issues, which immediately surround their everyday's work.
And this is exactly the reputation of the military and the weapon makers
regarding those matters, which tells to many programmers that they better
should not come too near to those areas.

These people generally aren't pacifists at all, but they guess that it will
be hard and unpleasant for them to maintain compatibility with military
procedural logic and military customer's habits - and they do not feel
necessary to put themselves into that environment in peace time.





Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: ADA Popularity Discussion Request

[Jano]

Kevin Cline wrote:

> Are there any CS programs that have chosen Ada as their core language?

Yes, at least in Spain.

>  I rarely meet recent graduates with any exposure to Ada at all.  For
> better or worse, (worse in my opinion), most CS departments seem to
> have settled on Java.

Re: ADA Popularity Discussion Request

[Jeffrey Carter]

Kevin Cline wrote:

> I think the very existence of limited types is a fundamental flaw in
> Ada.

The ability to create types for which there are no operations except 
those defined by the developer is essential for creating useful 
abstractions. Since the creation of useful abstractions is the hallmark 
of software engineering, it is not surprising that Ada is the language 
of choice for the 2% of developers who are software engineers, and 
disliked by the 98% who are coders and should not be allowed to design 
software of any importance.

> It doesn't matter to me that weak programmers can theoretically make a
> mess in C++.  What matters is the amount of effort required for a good
> programmer to produce sound code, and Ada is simply not competitive
> for most applications.

It is the ease with which even very good developers make messes in C++ 
that has led to the decline in its popularity, and many are looking at 
Java, C#, and Ada for a better alternative.

-- 
Jeff Carter
"Ditto, you provincial putz?"
Blazing Saddles
86

Re: ADA Popularity Discussion Request

[Kevin Cline]

Jeffrey Carter <spam@spam.com> wrote in message news:<4CsVc.28876$9Y6.4063@newsread1.news.pas.earthlink.net>...
> Kevin Cline wrote:
> 
> > I think the very existence of limited types is a fundamental flaw in
> > Ada.
> 
> The ability to create types for which there are no operations except 
> those defined by the developer is essential for creating useful 
> abstractions. Since the creation of useful abstractions is the hallmark 
> of software engineering, it is not surprising that Ada is the language 
> of choice for the 2% of developers who are software engineers, and 
> disliked by the 98% who are coders and should not be allowed to design 
> software of any importance.

It's unfortunate to see this circular ad-hominem argument is repeated
over and over again in this newsgroup.  "I am a good programmer.  I
like Ada.  Therefore all good programmers should like Ada. 
Programmers who don't like Ada must be poor programmers."  And even
the first assertion is doubtful.

No progress can come from this argument.  Better to notice that a lot
of very good programmers have rejected Ada, and figure out why.

Re: ADA Popularity Discussion Request

[Jeffrey Carter]

Kevin Cline wrote:

> It's unfortunate to see this circular ad-hominem argument is repeated
> over and over again in this newsgroup.  "I am a good programmer.  I
> like Ada.  Therefore all good programmers should like Ada. 
> Programmers who don't like Ada must be poor programmers."  And even
> the first assertion is doubtful.
> 
> No progress can come from this argument.  Better to notice that a lot
> of very good programmers have rejected Ada, and figure out why.

No progress can come when a statement of facts (2% of developers are 
software engineers) is treated as an attack. (There are plenty of "good 
programmers" who are not software engineers.) If someone sees himself in 
the facts and doesn't like what he sees, that does not qualify as an attack.

It has been known for at least 3 decades that a very small proportion of 
developers are orders of magnitude more effective than the rest. The 
common characteristics of these effective developers include avoiding 
unnecessary complexity, creating usable abstractions, and putting much 
more effort into pre-code activites.

In my 29 years of professional software-development experience, I have 
found that only about 2% of developers fall into this category. I have 
also found that about 2% of developers like Ada and dislike the C family 
of languages, and the other 98% have the opposite opinion. That there is 
significant overlap between software engineers and those who like Ada is 
not surprising.

I call the 2% of effective software developers software engineers, and 
the other 98%, coders. What we have in software development is a failure 
to distinguish between these 2 groups. Allowing coders to design 
software and make language choices is the same as allowing construction 
workers to design bridges and decide what construction materials to use. 
We would not be surprised to have bridges that failed as often as 
software does.

-- 
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81

Re: ADA Popularity Discussion Request

[Kevin Cline]

Jeffrey Carter <spam@spam.com> wrote in message news:<M1wXc.14455$3O3.2233@newsread2.news.pas.earthlink.net>...
> Kevin Cline wrote:
> 
> > It's unfortunate to see this circular ad-hominem argument is repeated
> > over and over again in this newsgroup.  "I am a good programmer.  I
> > like Ada.  Therefore all good programmers should like Ada. 
> > Programmers who don't like Ada must be poor programmers."  And even
> > the first assertion is doubtful.
> > 
> > No progress can come from this argument.  Better to notice that a lot
> > of very good programmers have rejected Ada, and figure out why.
> 
> No progress can come when a statement of facts (2% of developers are 
> software engineers) is treated as an attack. (There are plenty of "good 
> programmers" who are not software engineers.) If someone sees himself in 
> the facts and doesn't like what he sees, that does not qualify as an attack.
> 
> It has been known for at least 3 decades that a very small proportion of 
> developers are orders of magnitude more effective than the rest. The 
> common characteristics of these effective developers include avoiding 
> unnecessary complexity, creating usable abstractions, and putting much 
> more effort into pre-code activites.

The efficacy of much pre-code activity is debatable.  Many
organizations have had great success with more agile methods of
minimal up-front design followed by test-driven development and
continuous refactoring.

Re: ADA Popularity Discussion Request

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
 
: The efficacy of much pre-code activity is debatable.  Many
: organizations have had great success with more agile methods of
: minimal up-front design followed by test-driven development and
: continuous refactoring.

Yes and even some tricks can be helpful to get something going.
But how can "refactoring" be done well without quite some thinking
and planning, that is without something that happens before coding?
Isn't "refactoring" sometimes a redesign of the modular structure of
some software? I wouldn't call this activity "coding".


-- Georg

Re: ADA Popularity Discussion Request

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cgnnc9$au4$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
>  
> : The efficacy of much pre-code activity is debatable.  Many
> : organizations have had great success with more agile methods of
> : minimal up-front design followed by test-driven development and
> : continuous refactoring.
> 
> Yes and even some tricks can be helpful to get something going.
> But how can "refactoring" be done well without quite some thinking
> and planning, that is without something that happens before coding?
> Isn't "refactoring" sometimes a redesign of the modular structure of
> some software? I wouldn't call this activity "coding".

Most refactoring is local -- observing common code in two methods and
collecting it into a new method.  But sometimes, indeed, one sees that
larger structural improvements would be beneficial.  Following agile
methods, you never undertake a gross rewrite of working software. 
Instead you
make incremental changes to the code, testing after each change, until
the desired new structure is achieved.  It takes a bit of practice to
learn how to get large changes done incrementally, but it can be done.
 So you design a little, code a little, and test a little until it's
done.  Rarely is there "quite some thinking and planning".  I find
that designing for a long time without coding, or coding for a long
time without testing is like trying to driver a car while only looking
at the road once every fifteen seconds.  You tend to spend a lot of
time getting back on the road.

Re: ADA Popularity Discussion Request

[Jeffrey Carter]

Kevin Cline wrote:

> The efficacy of much pre-code activity is debatable.  Many
> organizations have had great success with more agile methods of
> minimal up-front design followed by test-driven development and
> continuous refactoring.

The success of agile methods is debatable. Much of agile methods is 
simply a rehash of the rapid prototyping spiral methods of the 1970s 
intended to elicit requirements, and those are excellent methods when 
requirements are unclear. The main difference between those methods and 
agile methods is that the latter eliminates the final iteration of the 
spiral methods, in which the now well defined requirements are used to 
create a design, which is then implementated, possibly reusing some of 
the code from the prototypes.

Whether this is a success depends upon the definition of success. If 
success is measured in cost to initial deployment, or when you can 
charge your customers more to fix errors, it probably is a success. When 
success is based on the reliability and correctness of the software, or 
the total lifecycle cost of the software, the success of agile methods 
is unproven.

-- 
Jeff Carter
"Have you gone berserk? Can't you see that that man is a ni?"
Blazing Saddles
38

Re: ADA Popularity Discussion Request

[Kevin Cline]

Jeffrey Carter <spam@spam.com> wrote in message news:<aMKXc.203$8d1.94@newsread2.news.pas.earthlink.net>...
> Kevin Cline wrote:
> 
> > The efficacy of much pre-code activity is debatable.  Many
> > organizations have had great success with more agile methods of
> > minimal up-front design followed by test-driven development and
> > continuous refactoring.
> 
> The success of agile methods is debatable. Much of agile methods is 
> simply a rehash of the rapid prototyping spiral methods of the 1970s 
> intended to elicit requirements, and those are excellent methods when 
> requirements are unclear. The main difference between those methods and 
> agile methods is that the latter eliminates the final iteration of the 
> spiral methods, in which the now well defined requirements are used to 
> create a design, which is then implementated, possibly reusing some of 
> the code from the prototypes.

I think the main ideas of agile development are test-driven
development,
and continuous refactoring of code.  Neither was a key practice in
1970s style rapid prototyping methods.

Re: ADA Popularity Discussion Request

[Kevin Cline]

Jeffrey Carter <spam@spam.com> wrote in message news:<4CsVc.28876$9Y6.4063@newsread1.news.pas.earthlink.net>...
> Kevin Cline wrote:
> 
> > I think the very existence of limited types is a fundamental flaw in
> > Ada.
> 
> The ability to create types for which there are no operations except 
> those defined by the developer is essential for creating useful 
> abstractions. Since the creation of useful abstractions is the hallmark 
> of software engineering, it is not surprising that Ada is the language 
> of choice for the 2% of developers who are software engineers, and 
> disliked by the 98% who are coders and should not be allowed to design 
> software of any importance.
> 
> > It doesn't matter to me that weak programmers can theoretically make a
> > mess in C++.  What matters is the amount of effort required for a good
> > programmer to produce sound code, and Ada is simply not competitive
> > for most applications.
> 
> It is the ease with which even very good developers make messes in C++ 
> that has led to the decline in its popularity, and many are looking at 
> Java, C#, and Ada for a better alternative.

I suppose we have different definitions of "very good".  I see the
same developers who made messes in C++ making messes in C# and Java. 
The only difference in C# and Java is that the mess is not so obvious.

Re: ADA Popularity Discussion Request

[Alexander E. Kopilovich]

Richard Riehle wrote:

> There are a few simple underlying ideas in the language. One
> of them is type safety, and that has never been beyond the
> comprehension of any programmer.   The idea that seems to
> have been difficult to grasp, even by many who consider themselves
> sophisticated software developers, is the separation of scope
> and visibility.   Chapter Eight of the ALRM is rarely read by
> anyone, it seems.
Certainly so. It was said many times (here in c.l.a. and elsewhere) by the
most authoritative Ada experts that ALRM is NOT intended for use by regular
software developer but it is for Ada experts (mostly by Ada compiler writers).
And in many places it is indeed difficult to read - because information is not
strictly localised - you can never be sure that there is no important bit of
related information somewhere, in some distant place of the ALRM.

Actually, a reader of ALRM can't be sure of any broad statement if s/he did
not study the ALRM comprehensively - and naturally, almost no one except
professional Ada experts can afford that.

The idea of type safety is easy because it is an abstract idea, Ada did not
invent (or even modify) but just employs it. In other words, this idea is
easy for a programmer because it comes not from ALRM, and actually not from
Ada -;) .

But the separation of visibility and scope, which you mentioned, never was
formulated as a clear abstract idea, it is closely associated with Ada - and
therefore there is no affordable way to understand it properly as a separate
idea.

> The benefits of the visibility rules needs to be given emphasis.  Those
> rules are among the most powerful benefits of Ada, even though
> some programmers continue to see them as a nuisance.
Then what prevents you (or someone else) from explaining this idea - first
in some abstract form and then showing how this abstract idea is employed in
Ada language?




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: ADA Popularity Discussion Request

[Richard Riehle]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu> wrote in message
news:mailman.7.1093024431.28011.comp.lang.ada@ada-france.org...
> Richard Riehle wrote:
>
> > The benefits of the visibility rules needs to be given emphasis.  Those
> > rules are among the most powerful benefits of Ada, even though
> > some programmers continue to see them as a nuisance.
> Then what prevents you (or someone else) from explaining this idea - first
> in some abstract form and then showing how this abstract idea is employed
in
> Ada language?
>
Nothing prevents us from explaining this idea except
the fact that it is so unique, so language specific.  When
I am in the classroom setting, I do place a lot of emphasis
on this aspect of the language.   I focus on its benefits
rather than what some see as its liabilities.

I frequently used to myself annoyed with the property of
physics we call gravity.  Each time I try to defy it, I
am sorely disappointed.   After a few years of living
under its restrictions, I began to discover its virtues.

In the case of separation of scope and visibility, I have
come to appreciate the virtues of that feature.  I have
learned to use it to good advantage.   In many cases,
those who have learned Ada under my tutelage have
learned the same appreciation, and some have even
become excellent software designers because of, not
in spite of this language capability.

Richard Riehle

Re: ADA Popularity Discussion Request

[Jeffrey Carter]

Kevin Cline wrote:
> 
> I don't your guru got it quite right.  Ada failed because most
> programmers who tried it found Ada programming to be relative less
> productive than programming in other available languages.  Ada never
> attracted a large enough base of motivated users to develop the
> libraries and IDEs that would make it easy to use.  Even with
> available public domain compilers, almost no one is choosing to
> program in Ada.

Where there is hard data available, rather than biased opinion such as 
this, they consistently show that Ada projects reach delivery with half 
the cost of similar projects in "popular" languages such as C. I doubt 
if most people agree that more productive means more expensive.

-- 
Jeff Carter
"C's solution to this [variable-sized arrays] has real problems,
and people who are complaining about safety definitely have a point."
Dennis Ritchie
25

Re: ADA Popularity Discussion Request

[Steve]

The demise of Ada has been greatly exaggerated.

As I see it, with the increasing concern regarding software security and
reliability Ada is just about to come of age...

Steve
(The Duck)

Re: ADA Popularity Discussion Request

[Dmitry A. Kazakov]

On 17 Aug 2004 16:54:18 -0700, Kevin Cline wrote:

> I don't your guru got it quite right.  Ada failed because most
> programmers who tried it found Ada programming to be relative less
> productive than programming in other available languages.

I do not think so. When I started to work with Ada I found it more
productive than FORTRAN, PL/1 or C (the most popular languages that time,
around me. Well there were also unpopular Algol 60, awful COBOL, dreadful
Forth, half-baked Pascal and nice, but unavailable Modula)

I believe that Ada 83 came too early and looked too far ahead, so it failed
to solve many of the problems it tried to. These problems (with ADT,
concurrency, checkability) are not solved in either language until now.

> Ada never
> attracted a large enough base of motivated users to develop the
> libraries and IDEs that would make it easy to use.

That time there were no user movements we observe now. That Borland chose
Pascal and not Ada was rather a coincident (probably they wanted not to be
bound by any standard, making a product for what was seen as a "play
station".) I also suspect that GNU people chose C just because they didn't
trust in their ability to create a quality compiler in an observable period
of time and get it working on small machines.

> In a nutshell, Ada is not popular because most people who have tried
> it didn't like it.

I think that they rather didn't try it at all. I believe you overestimate
people's desire to try languages. My guess is that 50% of people just stay
with the first language they finished the first real project. 40% remain by
the second language. The criteria of selecting first two languages are not
in Ada's favor:

1. What I was taught
2. What is used around me
3. Current hype

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

Re: ADA Popularity Discussion Request

[Jean-Pierre Rosen]

 > That time there were no user movements we observe now. That Borland
 > chose
 > Pascal and not Ada was rather a coincident (probably they wanted not
 > to be
 > bound by any standard, making a product for what was seen as a "play
 > station".)
Historical note:
Borland did consider making an Ada compiler at some point, but gave up 
when they discovered they couldn't make a Borland Ada "better" than 
regular Ada.

The team they hired at that time tried to continue the project by 
themselves (they asked me to participate), but it never came out.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: ADA Popularity Discussion Request

[Ludovic Brenta]

Jean-Pierre Rosen writes:
> Historical note:
> Borland did consider making an Ada compiler at some point, but gave up
> when they discovered they couldn't make a Borland Ada "better" than
> regular Ada.
>
> The team they hired at that time tried to continue the project by
> themselves (they asked me to participate), but it never came out.

That's interesting.  Even back then before "standard" was a buzzword,
they understood that standards are meant to benefit the users by
making vendors interchangeable.  They did not want to be
interchangeable; they wanted their customers to be captive.  This is
the same line of thought that brought proprietary software about a few
years earlier.

Back in 1989, I used to respect Borland for the quality of their
compilers.  But now, in hindsight, what you said changed my
perspective.

-- 
Ludovic Brenta.

Re: ADA Popularity Discussion Request

[Ed Falis]

On Wed, 18 Aug 2004 19:55:04 +0200, Ludovic Brenta  
<ludovic.brenta@insalien.org> wrote:

> Back in 1989, I used to respect Borland for the quality of their
> compilers.  But now, in hindsight, what you said changed my
> perspective.

But that was the flavor of the times. And one's stance on intellectual  
property is distinct from the quality of one's products.  So, your respect  
for their technical achievements was not wasted.

- Ed

-- 
"When I was a kid, I wanted to grow up to be a wise man. Somehow, I just  
turned out to be a wise guy".

Re: ADA Popularity Discussion Request

[Jean-Pierre Rosen]

Ludovic Brenta a écrit :

> Back in 1989, I used to respect Borland for the quality of their
> compilers.  But now, in hindsight, what you said changed my
> perspective.
> 
Nothing new here. Borland never obeyed by the standards. Turbo Pascal 
always had "extensions". And I remember playing with Turbo Prolog that 
was conformant to no other Prolog of the time.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: ADA Popularity Discussion Request

[Larry Kilgallen]

In article <ril1gc.5g7.ln@skymaster>, Jean-Pierre Rosen <rosen@adalog.fr> writes:
> Ludovic Brenta a =E9crit :
> 
>> Back in 1989, I used to respect Borland for the quality of their
>> compilers.  But now, in hindsight, what you said changed my
>> perspective.
>>=20
> Nothing new here. Borland never obeyed by the standards. Turbo Pascal=20
> always had "extensions". And I remember playing with Turbo Prolog that=20
> was conformant to no other Prolog of the time.

For the Pascal case, _every_ Pascal seemed to have extensions,
since real world applications have greater needs than the
original teaching mission of Pascal.

Re: ADA Popularity Discussion Request

[Jacob Sparre Andersen]

Larry Kilgallen wrote:

> For the Pascal case, _every_ Pascal seemed to have extensions, since
> real world applications have greater needs than the original
> teaching mission of Pascal.

Yes.

But I was quite disappointed when I noticed that Borland didn't even
implement all of Pascal in their "Pascal" compiler.  The one thing I
still can remember was missing is returning record types from
functions.

Jacob
-- 
�I like it when the support group complains that they have
 insufficient data on mean time to repair bugs in Ada
 software.�                              -- Robert I. Eachus

Re: ADA Popularity Discussion Request

[Martin Krischik]

Jacob Sparre Andersen wrote:

> Larry Kilgallen wrote:
> 
>> For the Pascal case, _every_ Pascal seemed to have extensions, since
>> real world applications have greater needs than the original
>> teaching mission of Pascal.
> 
> Yes.
> 
> But I was quite disappointed when I noticed that Borland didn't even
> implement all of Pascal in their "Pascal" compiler.  The one thing I
> still can remember was missing is returning record types from
> functions.

The full ISO standart also has indefinate arrays with some kind of 'first
and 'last mechanism. Isn't there in TurboPascal either.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: ADA Popularity Discussion Request

[John Kern]

Jean-Pierre Rosen <rosen@adalog.fr> wrote in message 
> Historical note:
> Borland did consider making an Ada compiler at some point, but gave up 
> when they discovered they couldn't make a Borland Ada "better" than 
> regular Ada.
> 
The way I remember it, Borland wanted wanted to do a Turbo Ada, but
were prevented from using the copywrighted(?) name Ada unless the
product passed the validation suites, and they were not prepared to
implement full tasking capabilities in a $99 compiler.

Re: ADA Popularity Discussion Request

[Björn Persson]

Dmitry A. Kazakov wrote:

> That Borland chose
> Pascal and not Ada was rather a coincident (probably they wanted not to be
> bound by any standard, making a product for what was seen as a "play
> station".)

You're saying they seriously considered writing "Turbo Ada" instead of 
Turbo Pascal? That's interesting. Do you have any sources?

> I also suspect that GNU people chose C just because they didn't
> trust in their ability to create a quality compiler in an observable period
> of time and get it working on small machines.

I've always thought they didn't really choose a language; they wanted to 
clone Unix, and Unix was associated with C. But what do I know?

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu