IBM Acquires Rational Ada

IBM Acquires Rational Ada

[Richard Riehle]

Just announced today was the 2.1 billion dollar purchase
of Rational by IBM.   One can only wonder what will happen
to the Ada compiler products.   Things will either get better
or they will get worse.   Of  course, I think Norm Cohen still
works for IBM.  Perhaps he can make a difference.

Richard Riehle

Re: IBM Acquires Rational Ada

[achrist]

Memo is here:

http://www.internalmemos.com/memos/memodetails.php?memo_id=1145

Al

Re: IBM Acquires Rational Ada

[Richard Riehle]

achrist@easystreet.com wrote:

> Memo is here:
>
> http://www.internalmemos.com/memos/memodetails.php?memo_id=1145
>

Alas, no hint of what will become of Rational Ada.   If anyone at IBM
realizes the power of the Rational Ada product, it could be great for
Ada and for IBM.   I wish I could be optimistic about this.

Richard Riehle

RE: IBM Acquires Rational Ada

[Steven Deller]

Richard,
I'd bet that when the smoke clears, Rational Ada will live on pretty
much as now.  It is possible that IBM will actually add support for it.

It can't go away -- too many large users of Rational Ada (who are also
IBM customers) will bring pressure to keep support of the product.

Granted that's a guess, but it is an "educated" guess.  If nothing else,
it should make you a bit more optimistic.

By the way -- during the transition, I'd bet there could be some
momentary ignorance that causes a termination notice, but I'd also bet
(if it occurs) that a retraction will occur within 2 days.  It all
depends on how well IBM does their due diligence.

Regards,
Steve

> Alas, no hint of what will become of Rational Ada.   If anyone at IBM
> realizes the power of the Rational Ada product, it could be great for
> Ada and for IBM.   I wish I could be optimistic about this.
> 
> Richard Riehle

Re: IBM Acquires Rational Ada

[Richard Riehle]

Steven Deller wrote:

> Richard,
> I'd bet that when the smoke clears, Rational Ada will live on pretty
> much as now.  It is possible that IBM will actually add support for it.

Thanks.  I realize you are in a better position to offer an opinion about
this because of your close association with Rational for many years.

> It can't go away -- too many large users of Rational Ada (who are also
> IBM customers) will bring pressure to keep support of the product.

Good point.   Another poster, Steve_H, suggests that GNAT is the last
word in Ada compiler technology.   Of  course that is dead wrong.  In
the case of Rational, my customers find the Rational Ada run-time to be
an important feature.  Some believe, after running their own benchmarks,
that Rational Ada is better for high-performance embedded applications.
This takes nothing away from GNAT.  Different products meet different
needs.  GNAT's contribution is enormous and necessary.

There is not only room for more than one Ada compiler product in the
marketplace, there is a need for more than one.  Each of the compiler
publishers has a unique contribution.   I often direct my clients to
explore the options from ICC, DDC-I, Aonix, and Green Hills, along
with the better known options such as Rational and GNAT.

I agree with you that IBM could benefit the visibility of Ada with its
own clients -- but only if the widespread misconceptions about the
language can be reversed.    In particular, Dr. Norm Cohen could make
a huge difference within IBM.  He is probably the most visible, and
to those of outside IBM, the most knowledgeable person with the
IBM corporate structure when it comes to Ada.

Re: IBM Acquires Rational Ada

[Wes Groleau]

> By the way -- during the transition, I'd bet there could be some
> momentary ignorance that causes a termination notice, but I'd also bet
> (if it occurs) that a retraction will occur within 2 days.  It all
> depends on how well IBM does their due diligence.

Speaking of momentary ignorance, think we'll see some
ill-conceived attempts on corporate identity?

Hmmm...

    iRational

    I B Rational

    Rational B. M.

:-)

Re: IBM Acquires Rational Ada

[achrist]

Steven Deller wrote:

> It can't go away -- too many large users of Rational Ada (who are
> also IBM customers) will bring pressure to keep support of the
> product.

The news today is that IBM is withdrawing OS2 in March 2003.  That
product was not a smashing success, but probably more users than
Rational Ada.

Al

Re: IBM Acquires Rational Ada

[Martin Dowie]

<achrist@easystreet.com> wrote in message
news:3DF78324.3D5A1DE1@easystreet.com...
> The news today is that IBM is withdrawing OS2 in March 2003.  That
> product was not a smashing success, but probably more users than
> Rational Ada.

Yes, but how many OS/2 users have 20+ year support required? From what
I can make out Boeing are about the largest users of Rational Ada and I'd
be surprised if lots of their programmes didn't require _very_ long
post-delivery
support. I'm sure (well, I'd hope!) that in winning the Ada compiler supply
contract in the first place, they'd have stipulated some sort of commitment
out of Rational.

Re: IBM Acquires Rational Ada

[faust]

 "Martin Dowie" <martin.dowie@no.spam.btopenworld.com> ,  emitted
these fragments:
 
>Yes, but how many OS/2 users have 20+ year support required? From what
>I can make out Boeing are about the largest users of Rational Ada and I'd
>be surprised if lots of their programmes didn't require _very_ long
>post-delivery

Well, you can still buy support for Jovial compilers.
However, it is still stone cold dead as a language for new
development.

--------------------------------------------------------
Come see,
real flowers
of this pain-filled world.

(from Basho)

Re: IBM Acquires Rational Ada

[faust]

 "Steven Deller" <a101.deller@smsail.com> ,  emitted these fragments:

>
>It can't go away -- too many large users of Rational Ada (who are also
>IBM customers) will bring pressure to keep support of the product.


They said the same thing about OS2

--------------------------------------------------------
Come see,
real flowers
of this pain-filled world.

(from Basho)

Re: IBM Acquires Rational Ada

[steve_H]

Richard Riehle <richard@adaworks.com> wrote in message news:<3DF2A483.EC512CDF@adaworks.com>...
 
> 
> Alas, no hint of what will become of Rational Ada.   If anyone at IBM
> realizes the power of the Rational Ada product, it could be great for
> Ada and for IBM.   I wish I could be optimistic about this.
> 
> Richard Riehle

I have not used rational Ada products. But from the point of view of making
Ada more popular with the masses, I doubt it will make any difference if
Rational Ada compiler existed or not. Why do you think rational Ada
is important for Ada?

The only hope for Ada getting more popular, is for gnat to be 
fully integrated in the gcc system. This makes Ada available 
anywhere gcc is available. This means a programmer now can write in Ada
(instead of C or C++) knowing their software can be build just as easily.

All those commerical compiler systems are dying (those for standard 
languages that gcc can now fully do, mainly  C and C++). From Sun to 
IBM to HP to Borland's. As gcc improves, commerical systems that 
costs thousands and tangled with licensing issues are being left behind.   

Those companies now need to add more value to their compilers than just
compiling the source code, and this comes in the form of better debuggers,
and such. 

If it were not for gcc, we probably would not have linux nor apache nor
99.99% of the open system products out there. If gcc could do Ada long time
ago, then may be apache would have been written in Ada instead of C? at 
least that would have been an option.

just my 2 cents ofcourse.

RE: IBM Acquires Rational Ada

[Steven Deller]

> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org 
> [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of steve_H
> Sent: Sunday, December 08, 2002 11:18 AM
> To: comp.lang.ada@ada.eu.org
> Subject: Re: IBM Acquires Rational Ada
>...
> Why do you think rational Ada is important for Ada?

Purer Ada implementation (no non-standard extensions).
Fewer bugs (more correct programs compile).
Better code generation (faster, head to head).
 
> Those companies now need to add more value to their compilers 
> than just compiling the source code, and this comes in the 
> form of better debuggers, and such. 

Integrated application *system* navigation with simple point and click.
Integrated CM builds for managing 100's of simultaneous developers.
Integrated tools such as "find all uses of X".
Integrated multi-program debugger.
Integrated with Rose (build and maintain OO in UML).

> The only hope for Ada getting more popular, is for gnat to be 
> fully integrated in the gcc system. This makes Ada available 
> anywhere gcc is available. This means a programmer now can 
> write in Ada (instead of C or C++) knowing their software can 
> be build just as easily.

I like GNAT as much as Apex (use both all the time).  But if any major
development shop is to commit to a technology they (almost always) want
the technology to have several sources.  For all sorts of good
management reasons.

For gcc, most OS vendors offer support for the compiler they provide.
It may be gcc, but I can guarantee you that they are NOT fully
equivalent.  That appears to be "multiple sources" to managers, even if
underneath they all came from similar source.

None of those vendors, at least yet, support gnat, or rather Ada under
gcc.  Getting Ada into gcc is useful, don't get me wrong, but it is NOT
going to be the saviorr of Ada.

Having multiple vendors makes managers much more likely to pick a
technology.   

Finally, if a current major Ada vendor stops supporting Ada, I can
guarantee you that your ability to sell Ada into any development
situation will get MUCH harder (sell as in "convince to use").

It is important for the Ada market that we have multiple, viable
vendors.

> just my 2 cents of course.

And my 2 cents.

Regards,
Steve

Re: IBM Acquires Rational Ada

[Wes Groleau]

>>Why do you think rational Ada is important for Ada?
> 
> Purer Ada implementation (no non-standard extensions).

Not so.  I am constantly begging people here to use
LRM-defined packages and pragmas instead of home-brewed
and vendor specific.

> Fewer bugs (more correct programs compile).

Not in my experience.

> Better code generation (faster, head to head).

Faster, _maybe_  But the GNAT library model means
that GNAT can simultaneously compile as many
units as the network/filer/CPU can handle.

> Integrated application *system* navigation with simple point and click.
> Integrated CM builds for managing 100's of simultaneous developers.
> Integrated tools such as "find all uses of X".
> Integrated multi-program debugger.
> Integrated with Rose (build and maintain OO in UML).

Indeed, Rational has some outstanding tools.
But since they don't really do Java very well,
if they should drop Ada, they basically become useless
to me.

Re: IBM Acquires Rational Ada

[John McCabe]

On Mon, 09 Dec 2002 09:24:26 -0500, Wes Groleau
<wesgroleau@despammed.com> wrote:

>> Better code generation (faster, head to head).

>Faster, _maybe_  But the GNAT library model means
>that GNAT can simultaneously compile as many
>units as the network/filer/CPU can handle.

I don't think that compilation speed was what is being referred to. I
assumed it was speed of execution.

Re: IBM Acquires Rational Ada

[Wes Groleau]

> I don't think that compilation speed was what is being referred to. I
> assumed it was speed of execution.

Ah, I can't comment on that, since I'm still trying
to get past all the pragmas and other things GNAT won't
recognize.  Some of which, by the way, are rejected by
GNAT because the RM requires them to be rejected.
Others because recognizing Apex-specific pragmas
hasn't been high on GNAT's priority list.

(to be fair, I've seen bug-diffs go the other way.)

Re: IBM Acquires Rational Ada

[Christopher Browne]

A long time ago, in a galaxy far, far away, nma124@hotmail.com (steve_H) wrote:
> If it were not for gcc, we probably would not have linux nor apache
> nor 99.99% of the open system products out there. If gcc could do
> Ada long time ago, then may be apache would have been written in Ada
> instead of C? at least that would have been an option.

That seems totally unlikely.

We might not have Linux without GCC, but we almost certainly would
have Apache, because Unix platforms virtually always come with a C
compiler.  Most of the GNU "toolchain" existed for years before Linux
came along.

And actually, while it is unlikely that "Linux" would be without GCC,
it is fairly likely that the "desire for a free Unix" would have been
satisfied as a result of some combination of the BSD codebase along
with either some port of PCC, the TENDRA C compiler suite, or perhaps
LCC.

At the time, there was zero likelihood of Ada being a plausible
alternative.  The nearest alternative might have been one of the Wirth
languages, whether Modula 2 or Modula 3 or Oberon.  But in the
community of "Unix folk" that were building things like the GNU tools
and HTTPD, the language of choice was C, and if GCC had not been
available, one of the other C compiler alternatives would surely have
been chosen.
-- 
(concatenate 'string "chris" "@cbbrowne.com")
http://cbbrowne.com/info/c.html
"I think that helps the users too much."   -- CSTACY

Re: IBM Acquires Rational Ada

[John McCabe]

On 8 Dec 2002 09:18:02 -0800, nma124@hotmail.com (steve_H) wrote:

>I have not used rational Ada products. But from the point of view of making
>Ada more popular with the masses, I doubt it will make any difference if
>Rational Ada compiler existed or not. Why do you think rational Ada
>is important for Ada?

Rational Ada is important for Ada because, if Rational didn't do an
Ada compiler, do you think they would bother with Ada support for UML?
I doubt it personally. I believe if Rational Ada is dumped, then so
will Rational Rose's Ada support. How many other UML tools can say
they have the sort of Ada support that Rose has? Rational Rose is by
far the most visible UML tool available - if there is no Ada support
in the tool, then those who can't be bothered doing their homework
(and there are a lot of them around) will see that there is no visible
UML based design tool with Ada support, so will assume that they
cannot carry out their project in Ada and use some other language
instead.

Re: IBM Acquires Rational Ada

[Georg Bauhaus]

John McCabe <johnnospam@nospamassen.nospamdemon.co.uk> wrote:
:  How many other UML tools can say
: they have the sort of Ada support that Rose has?

BTW, does anybody know how well PragSoft is doing?
(No news since Feb 2002)
-- georg

Re: IBM Acquires Rational Ada

[Pat Rogers]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:at28ae$664$3@a1-hrz.uni-duisburg.de...
> John McCabe <johnnospam@nospamassen.nospamdemon.co.uk> wrote:
> :  How many other UML tools can say
> : they have the sort of Ada support that Rose has?
>
> BTW, does anybody know how well PragSoft is doing?
> (No news since Feb 2002)

They have a new release planned for the near future.  If it has the
new capability they intend, I think we (in this group, particularly)
will be pleased.  :-)

Re: IBM Acquires Rational Ada

[Simon Wright]

johnnospam@nospamassen.nospamdemon.co.uk (John McCabe) writes:

>                                   How many other UML tools can say
> they have the sort of Ada support that Rose has?

Not a very good target to aim for, IMO.

Artisan has Ada support, and is fairly well-known to real-time
users. As far as I can tell, it's rather fixed in its views; if you
need lots more control over what gets generated, you'd probably be
better off using Aonix's ACD via Software through Pictures.

There are other routes, I just mention the more well-known ones from
slightly larger companies.

Of course, if all your boss needs is a tick in a box, Rose Ada will
suit very well.

-- 
Simon Wright                         Email: simon.j.wright@amsjv.com
AMS                                        Voice: +44(0)23 9270 1778
Integrated Systems Division                  FAX: +44(0)23 9270 1500

Re: IBM Acquires Rational Ada

[Alvery Grazebrook]

Simon Wright <simon.j.wright@amsjv.com> wrote in message news:<x7vy96zyzac.fsf@galadriel.frlngtn.gecm.com>...
> johnnospam@nospamassen.nospamdemon.co.uk (John McCabe) writes:
> 
> >                                   How many other UML tools can say
> > they have the sort of Ada support that Rose has?
> 
> Artisan has Ada support, and is fairly well-known to real-time
> users. As far as I can tell, it's rather fixed in its views; if you
> need lots more control over what gets generated, you'd probably be
> better off using Aonix's ACD via Software through Pictures.
> 
The Artisan tool, Real-time Studio has been evolving its Ada code
support. The code-generator is template based, so you can customize it
any way you like. It also includes reverse engineering and what we
call "Synchronization". This is basically a differencing engine to
compare the current state of the code with the current state of the
model, combined with a resolution capability that will re-generate or
reverse any parts that you select based on the differences.

Give it a try if you want. You can download a copy from
http://www.artisansw.com/eval/eval_download.asp

Cheers,
    Alvery

Alvery Grazebrook (Product Manager, Real-time Studio)

Re: IBM Acquires Rational Ada

[Martin Dowie]

"Alvery Grazebrook" <alveryg@artisansw.com> wrote in message
> > Artisan has Ada support, and is fairly well-known to real-time
> > users. As far as I can tell, it's rather fixed in its views; if you
> > need lots more control over what gets generated, you'd probably be
> > better off using Aonix's ACD via Software through Pictures.
> >
> The Artisan tool, Real-time Studio has been evolving its Ada code
> support. The code-generator is template based, so you can customize it
> any way you like. It also includes reverse engineering and what we
> call "Synchronization". This is basically a differencing engine to
> compare the current state of the code with the current state of the
> model, combined with a resolution capability that will re-generate or
> reverse any parts that you select based on the differences.

But is reversing and synchronisation available once you customise
the templates?

This isn't just a question for Artisan but for all UML tools.

UML to Ada Mapping

[Alvery Grazebrook]

"Martin Dowie" <martin.dowie@no.spam.btopenworld.com> wrote in message news:<atau5l$s9p$1@knossos.btinternet.com>...
> "Alvery Grazebrook" <alveryg@artisansw.com> wrote in message
> > > Artisan has Ada support, and is fairly well-known to real-time
> > > users. As far as I can tell, it's rather fixed in its views; if you
> > > need lots more control over what gets generated, you'd probably be
> > > better off using Aonix's ACD via Software through Pictures.
> > >
> > The Artisan tool, Real-time Studio has been evolving its Ada code
> > support. The code-generator is template based, so you can customize it
> > any way you like. It also includes reverse engineering and what we
> > call "Synchronization". This is basically a differencing engine to
> > compare the current state of the code with the current state of the
> > model, combined with a resolution capability that will re-generate or
> > reverse any parts that you select based on the differences.
> 
> But is reversing and synchronisation available once you customise
> the templates?
> 
> This isn't just a question for Artisan but for all UML tools.

Since you ask, there are 2 parts to the answer. 

The simple answer is that the reversing works to a defined mapping,
and the synchronizer supports a pre-defined range of possible mappings
when producing the comparison view. This means that synchronization
works cleanly for all generation templates that generate code that
conform to the semantics of the reverser's Ada -> UML mapping, and
will show differences otherwise.

The second part to the answer is that the job of a synchronizer is to
help translate UML model to Ada and back. Given that the semantics of
Ada is well defined, and the semantics of UML is reasonably well
defined, the only part of the mapping that is at issue is the way you
need to annotate the UML model to cover the features supported by Ada
that aren't supported by UML. The Ada UK community has taken up the
challenge of developing an Ada Profile (for UML) to define the UML
extensions required for the mapping.

A profile in UML is a set of extended properties that can be attached
to UML elements (e.g. operations, classes) to identify them as having
a particular significance.

For example, Ada 95 has several "structures" that can contain
variables, sub-programs etc. they are:
 Package, task type, protected type, and subprogram 
UML has only two: 
 Class, Package
Therefore the UML Class, in particular, needs extra annotation to
determine whether it should map to an Ada package, a task type or a
protected type.

Does anyone in this community have an interest in participating in the
definition of an Ada profile?

Cheers,
    Alvery
(Product Manager, Artisan software tools, wwww.artisansw.com)

Re: IBM Acquires Rational Ada

[Simon Wright]

alveryg@artisansw.com (Alvery Grazebrook) writes:

> Simon Wright <simon.j.wright@amsjv.com> wrote in message news:<x7vy96zyzac.fsf@galadriel.frlngtn.gecm.com>...

> > Artisan has Ada support, and is fairly well-known to real-time
> > users. As far as I can tell, it's rather fixed in its views; if you
> > need lots more control over what gets generated, you'd probably be
> > better off using Aonix's ACD via Software through Pictures.
> > 
> The Artisan tool, Real-time Studio has been evolving its Ada code
> support. The code-generator is template based, so you can customize
> it any way you like. It also includes reverse engineering and what
> we call "Synchronization". This is basically a differencing engine
> to compare the current state of the code with the current state of
> the model, combined with a resolution capability that will
> re-generate or reverse any parts that you select based on the
> differences.

It is very true that Artisan provides you with not just a translation
capability but also a specific Ada tailoring (set of templates) and
runtime support.

If you went the ACD route you would, I suspect, have the fun of doing
the tailoring and writing your own runtime.

I believe that many larger projects will need to write their own rules
and support eventually, but clearly it's best to get a running start.

Re: IBM Acquires Rational Ada

[Andreas Almroth]

"steve_H" <nma124@hotmail.com> wrote in message
news:8db3d6c8.0212080918.4e0a732@posting.google.com...
> Richard Riehle <richard@adaworks.com> wrote in message
news:<3DF2A483.EC512CDF@adaworks.com>...
>
> >
> > Alas, no hint of what will become of Rational Ada.   If anyone at IBM
> > realizes the power of the Rational Ada product, it could be great for
> > Ada and for IBM.   I wish I could be optimistic about this.
> >
> > Richard Riehle
>
> I have not used rational Ada products. But from the point of view of
making
> Ada more popular with the masses, I doubt it will make any difference if
> Rational Ada compiler existed or not. Why do you think rational Ada
> is important for Ada?
>

As with any compiler available it will make a difference to them who have
made a decision to rely on the compiler of choice....
Rational Ada may not prove to be very important to the "GNU" masses, but
it surely does fit in well with the rest of the Rational tool chain...

> The only hope for Ada getting more popular, is for gnat to be
> fully integrated in the gcc system. This makes Ada available
> anywhere gcc is available. This means a programmer now can write in Ada
> (instead of C or C++) knowing their software can be build just as easily.
>
> All those commerical compiler systems are dying (those for standard
> languages that gcc can now fully do, mainly  C and C++). From Sun to
> IBM to HP to Borland's. As gcc improves, commerical systems that
> costs thousands and tangled with licensing issues are being left behind.
>

As a developer it is only second most important to use a tool that can do
the same on all platforms. For any program developed today on a specific
platform it is done so because of the "pros" of doing so.
GCC is so lost when it comes to 64 bit support of SPARC processors. It is
only now with 3.x that we can see some work at all for 64 bit SPARC.
As a developer I want the compiler to help me produce effiecient programs,
especially if they are CPU bound.
GCC with Ada support is really really nice, but it is not the most
efficient,
optimised solution. GCC provides a very good standard environment for
programs coded in Ada.
For projects where we do have requirements on efficiency we do have to
choose the compiler that has the best support for that targeted platform.

And, Ada is not the mainstream compiler for general-purpose, platform
independant programs. Ada is used where there are very specific
requirements,
and therefore specific compilers are used to fulfill those requirements.
Not that Ada in any means is not promoting platform-indepentant programs,
but
it due to the specific requirements that one may choose Ada over other
languages, and a non-GCC compiler of the very same reasons...

> Those companies now need to add more value to their compilers than just
> compiling the source code, and this comes in the form of better debuggers,
> and such.
>
> If it were not for gcc, we probably would not have linux nor apache nor
> 99.99% of the open system products out there. If gcc could do Ada long
time
> ago, then may be apache would have been written in Ada instead of C? at
> least that would have been an option.
>

Seriuosly doubt that, the authors of Apache have choosen the language that
best
suited their requirements.
GNAT which is based on GCC has been around since 1995. GCC have in fact
supported Ada since then, but not in the normal distribution tree.
So that gives us seven years for Ada95 only, and I don't think Linux (91')
and
Apache would have been written in Ada just because GCC had support for it
back in 1995.
> just my 2 cents ofcourse.

Just my $0.25,
Andreas

Re: IBM Acquires Rational Ada

[Marin David Condic]

One would think that if IBM bought up Rational, they did so because they a)
thought it would be an important profit center and/or b) wanted to bring
important technology in-house where it could be better utilized and
compliment other products. If "A" is true, then the corporate guys won't
care much if the Rational division sells Ada compilers or grows tangerines -
just bring in the cash. In that case, Ada just needs to be a profitable
product or it deserves to be discontinued. If "B" is the case, then Ada as
one of Rational's products has to be some sort of "complimentary" product
that helps IBM sell its hardware. Here it is not so clear that IBM would
have a big incentive to keep it around since they are almost certainly more
interested in things like Rational Rose.

Still in all, it would make sense for IBM to sell off the compiler portion
to someone else if they weren't interested in it, so someone would likely
continue support. The point is that Ada must have some non-trivial
commercial potential in its own right or it won't really matter what IBM (or
anyone else) does with the compiler technology out there. If Rational is
keeping their product around as an "also ran" technology that has a handful
of followers that they simply want to keep happy, then IBM would be wise to
let it fade away. If Rational has found more than a handful of customers who
are actively buying the compiler, support, etc., then their Ada compiler is
a viable product that IBM would either continue to sell or at least sell off
to someone else.

I doubt this will have much of an impact on the future of Ada in the sense
that whatever happens is more a symptom of what is going on in the overall
industry, rather than a root cause. If Ada is to gain in popularity it has
to demonstrate more than just the availability of several compilers. It
needs to demonstrate measurable performance for the bottom line on corporate
balance sheets. (Lower costs, better quality, faster time to market, etc.)

Personally, I think the key is rapid development. Engineering costs usually
aren't the big drivers in most industries, but getting out the door faster
*is* a major advantage. To that end, better development kits around Ada,
bigger & better libraries and better access to underlying OS capabilities
are going to create development leverage that gets end-products out the
door. Maybe Ada is "A Better Mousetrap" but I think it has mostly gone after
the wrong mouse. Emphasis on standardization, portability and reliability
are all good things and might help push a sale over the edge, but the
industry seems to be willing to sacrifice all that in exchange for the
things that help them get to market faster.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Richard Riehle <richard@adaworks.com> wrote in message
news:3DF2A483.EC512CDF@adaworks.com...
>
> Alas, no hint of what will become of Rational Ada.   If anyone at IBM
> realizes the power of the Rational Ada product, it could be great for
> Ada and for IBM.   I wish I could be optimistic about this.
>
> Richard Riehle
>

Re: IBM Acquires Rational Ada

[steve_H]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message  

>. Engineering costs usually
> aren't the big drivers in most industries, but getting out the door faster
> *is* a major advantage. To that end, better development kits around Ada,
> bigger & better libraries and better access to underlying OS capabilities
> are going to create development leverage that gets end-products out the
> door. 

This is like the chicken and egg problem. Ada won't get popular until
more packages are available. And no packages will be written to it if it
is not popular.

The only way for Ada to become popular is for gcc to have full Ada support,
where any one can just type "gcc foo.adb" on any system where gcc is
installed, and it just works. No downloads, no nothing. ALl the libraries
and all the packages are there.

There is no other way left for Ada for it to become popular. All the
tricks and the speeches have been tried and said.

Commerical Ada compilers from closed commerical companies would make 
no difference to the popularity of a language.  (unless one can
buy it for $99.99 and have full IDE with it, etc.. Sorta like 
the TurboPascal days, which made Pascal the most popular language 
in its days).
 
It is not the few Ada programmers working inside Boeing or the defenss
department who will write those package for everyone to use, it is the 
open source programmers, the college students who want to make some 
impact, and the inspiring programmers who love to program and want
to spend the whole weekend coding for the love of it. Now those 
programmers turn to C and C++ and Java becuse it is everyone and free. Ada
full support in gcc makes Ada an option, and only then you will start to
see more Ada packages and more systems built with Ada. 

Ada has to grow from the bottom up (if it is to have a chane), from the 
masses up. Not from the officies of corporate America down to the
programmers. That is why I think rational rose Ada compiler, or any other
expensive commerical Ada compiler being there or not, will make no 
difference to the popularity of Ada. After all, we hade those for years,
and it did not make Ada any more popular.


just my 2 cents.

Re: IBM Acquires Rational Ada

[Marin David Condic]

steve_H <nma124@hotmail.com> wrote in message
news:8db3d6c8.0212091445.12594821@posting.google.com...
>
> This is like the chicken and egg problem. Ada won't get popular until
> more packages are available. And no packages will be written to it if it
> is not popular.
>
But its a chicken and egg problem that has been solved before with other
languages. Granted, it takes resources of one kind or another, but building
the infrastructure *has* been done in the past so it *could* be done in the
future.


> The only way for Ada to become popular is for gcc to have full Ada
support,
> where any one can just type "gcc foo.adb" on any system where gcc is
> installed, and it just works. No downloads, no nothing. ALl the libraries
> and all the packages are there.
>
If you can only think of one way to solve a problem, you have not thought
about it long enough. :-)

I will grant you that if Ada were completely integrated into gcc so that
when you got it, it just plain worked right out of the box, that this would
help encourage use of Ada. I've stated here in the past similar things about
development kits. Sure, there are nice tools out there for Ada, but you've
got to go out on the net and get X and Y and Z all from different sources
and cobble them together into a patchwork of development tools and then,
maybe, you've got equivalent capabilities to what people might get right out
of the box from MSVC++ or Sun-Java. But that makes it *hard* and not very
pretty. Any level of difficulty starts discouraging the average user and
pointing them down the path of least resistance.

So, yes, integrating Ada fully into gcc would help. But that's not the total
answer.


> There is no other way left for Ada for it to become popular. All the
> tricks and the speeches have been tried and said.
>
Sure there is. Like I said, lots of different factors can contribute to
making Ada more popular - gcc integration being one of them. What is wrong
with the notion of looking at the Ada standard and the direction the
language takes as a possible mechanism for improving its popularity? I don't
think that the syntax or semantics of the language itself needs much
improvement, but what it *does* need is some sort of effort to create large
libraries of utilities that provide development leverage. (Libraries as a
"Convention" rather than a "Standard".) If something similar could be done
to give Ada a GUI interface that could be the "Convention" across a number
of platforms, that would help add development leverage. Anything that gives
a developer an edge in getting out the door faster is a help.

People I know who don't have some sort of knee-jerk, anti-Ada response will
often admit that the language has many superior qualities, but that they
can't/won't use it to develop their products because other languages give
them some significan leverage they just can't get with the average Ada
compiler. It may be a tough nut to crack, but if it isn't cracked, Ada will
forever be an interesting "also ran" language.


> Commerical Ada compilers from closed commerical companies would make
> no difference to the popularity of a language.  (unless one can
> buy it for $99.99 and have full IDE with it, etc.. Sorta like
> the TurboPascal days, which made Pascal the most popular language
> in its days).
>
Yes, commercial compilers can and will make a difference. Microsoft doesn't
give away MSVC++ and they don't open source it and yet it is a very popular
development environment. Why? IMHO, its because it provides tons of leverage
for getting a GUI based app out the door on a Windows platform. Granted,
commercial products must be within the reach of "The Masses" or Ada can
never become "The Language Of The Masses". ACT charges lots of money for
Gnat to its commercial customers, but makes the unsupported, older versions
available free of charge for The Masses. There are other Ada compilers out
there that are available at reasonable cost too. The thing is that they are
all too often trailing other compilers/IDEs in terms of features and end up
in the "also ran" category rather than getting out front and leading the way
with something truly "different".


> It is not the few Ada programmers working inside Boeing or the defenss
> department who will write those package for everyone to use, it is the
> open source programmers, the college students who want to make some
> impact, and the inspiring programmers who love to program and want
> to spend the whole weekend coding for the love of it. Now those
> programmers turn to C and C++ and Java becuse it is everyone and free. Ada
> full support in gcc makes Ada an option, and only then you will start to
> see more Ada packages and more systems built with Ada.
>
Speaking as someone inside the defense industry, I'll say this. The Defense
industry may not be the driving force behind Ada or what will make it
popular - we have too many specialized needs that don't line up well with
those from the "real world" - but the Defense industry is at least keeping
Ada on life support & providing it with the time it needs to gain in
popularity within the commercial and educational sectors.

Yes, the college kids who hack things together in the free software world
are going to make a contribution to the popularity of the language. Its just
that somewhere along the line, Ada has to find a way to pay the freight. It
has to have some amount of commercial success behind it or nobody is there
to pay the bills. When a student graduates from college will he go to work
for some company developing software and do it free of charge just for the
fun of it? Well compiler vendors are companies too and they've got to pay
those graduates something, don't they? So they'd better have some market for
their wares besides college-kid-hackers or they won't have much of a
business to support further development of tools for the language.


> Ada has to grow from the bottom up (if it is to have a chane), from the
> masses up. Not from the officies of corporate America down to the
> programmers. That is why I think rational rose Ada compiler, or any other
> expensive commerical Ada compiler being there or not, will make no
> difference to the popularity of Ada. After all, we hade those for years,
> and it did not make Ada any more popular.
>
We may be in partial agreement here - possibly for different reasons. Yes,
Rational's price for an Ada compiler has never been "Rational" - at least
from where I've sat in the purchasing seat. (Corporate as well as personal).
Lots of vendors were way over the line with prices back then. This *did*
hurt Ada in the early days. I looked at vendors way back when (who shall
remain nameless) and was awestruck at the testicular fortitude it took to
price a compiler in the $100,000 neighborhood and then further tell you that
it could only be run on some specialized machine that only they made and
that the compiler would only target that machine - thus making it a) totally
useless to me and b) way too expensive in comparison to what I could get
elsewhere. (When you could buy a development computer with Unix on it and it
came with a C compiler - and you could get a cross compiler for your target
as well - for a fraction of what they were asking, it got real easy to see
why the decision got made to go with C.)

Ground-up popularity is certainly important. Kids coming out of college who
know Ada and are impressed by it and want to use it will help make it
popular. Part-time hackers putting together free software will help it too.
But don't underestimate the value of being able to go to corporate America
and tell them "I can get you to market in 50% of the time with 4x fewer
defects..." If that sale gets made, that will be what pays the bills to
enable the students and hackers to go off and have some fun.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> steve_H <nma124@hotmail.com> wrote in message
> news:8db3d6c8.0212091445.12594821@posting.google.com...
...
>>The only way for Ada to become popular is for gcc to have full Ada
>>support,
>>where any one can just type "gcc foo.adb" on any system where gcc is
>>installed, and it just works. No downloads, no nothing. ALl the libraries
>>and all the packages are there.
> 
> If you can only think of one way to solve a problem, you have not thought
> about it long enough. :-)

The other thing is that even when gcc fully includes Ada (gnat), the
packages/libraries may not necessarily be there (although there is a
greater chance of it now).

The problem is that when the user is shrink wrap
installing Linux for example, and asked whether or not it wants the
Ada packages or not, may look at the disk space requirement and say
"I don't need it". Over time, I would hope of course that people will
say instead "but I might need it to compile other Open Sourced
components". Disk space is getting cheaper, and as a result, maybe
that will even cease to be an option ;-)

> I will grant you that if Ada were completely integrated into gcc so that
> when you got it, it just plain worked right out of the box, that this would
> help encourage use of Ada. I've stated here in the past similar things about
> development kits. Sure, there are nice tools out there for Ada, but you've
> got to go out on the net and get X and Y and Z all from different sources
> and cobble them together into a patchwork of development tools and then,
> maybe, you've got equivalent capabilities to what people might get right out
> of the box from MSVC++ or Sun-Java. But that makes it *hard* and not very
> pretty. Any level of difficulty starts discouraging the average user and
> pointing them down the path of least resistance.

This is still a problem IMHO with Ada. I think the adapower site could
be better organized and more complete in this regard. But I don't like
to complain unless I can volunteer ;-)  Too much seems spread all over
the net (and I am guilty of this myself).  What adapower cannot host,
should perhaps have links to other Ada sites at least. I know that some
of this is there, but it seems rather incomplete.

> People I know who don't have some sort of knee-jerk, anti-Ada response will
> often admit that the language has many superior qualities, but that they
> can't/won't use it to develop their products because other languages give
> them some significan leverage they just can't get with the average Ada
> compiler. It may be a tough nut to crack, but if it isn't cracked, Ada will
> forever be an interesting "also ran" language.

There needs to be more "general purpose" quality bindings written. Some
of this is happening now that GNAT has been available, but like XFree86,
this effort takes time. It may be a pipe dream, but I still believe
in the possibility that we could see an Ada renaissance some day. As
pyramids of software are written, at some point, people are going to
start demanding that better quality foundations exist from which to
start building.

> Yes, the college kids who hack things together in the free software world
> are going to make a contribution to the popularity of the language. Its just
> that somewhere along the line, Ada has to find a way to pay the freight. 

It needs to exist in the workplace as an option. I can count on one
hand, then # of developers that are favourable to it in my career
circle. Young people need to start coming up from the ranks asking
to use it in projects.

> It
> has to have some amount of commercial success behind it or nobody is there
> to pay the bills. When a student graduates from college will he go to work
> for some company developing software and do it free of charge just for the
> fun of it? Well compiler vendors are companies too and they've got to pay
> those graduates something, don't they? So they'd better have some market for
> their wares besides college-kid-hackers or they won't have much of a
> business to support further development of tools for the language.

Part of the trouble is that many professors are selling "Java". In
part I can't blame them, for they need to prepare people for the
practicle realities of commercial development. OTOH, Ada is a much
better tool, assuming that the necessary library framework is there.

But IMHO, the library framework is not really there. AFAIK, even
Oracle has dropped support of the embedded Ada SQL precompiler. For
other databases, there exists no support at all for Ada. For my
own needs, I needed to write a better PostgreSQL binding (see
http://home.cogeco.ca/~ve3wwg/software.html for APQ). The problem
is that not everyone has time to write new bindings (nor can
everyone do a good job of it). We have GtkAda, but it is not a
perfect solution yet (its difficult to compile on some platforms,
and may not be fully supported from a commercial requirements
perspective). So I think a better "commercial support" set of
packages and libraries is needed for more general purpose use.
Ada's standard packages are still rather primitive for daily
use in a general purpose environment (just look at Ada.Calendar
for example -- you cannot determine the day of the week from
the API given).

> Ground-up popularity is certainly important. Kids coming out of college who
> know Ada and are impressed by it and want to use it will help make it
> popular. Part-time hackers putting together free software will help it too.
> But don't underestimate the value of being able to go to corporate America
> and tell them "I can get you to market in 50% of the time with 4x fewer
> defects..." If that sale gets made, that will be what pays the bills to
> enable the students and hackers to go off and have some fun.
> 
> MDC

One other way Ada could become more popular, is to have an O/S
based upon it (the O/S would need to become popular of course).
In this way, the Ada API would be more natural,
and C programs (for example) would have to write their own bindings
to the Ada APIs. This would tend to encourage Ada source code ;-)

However, this is not likely to happen any time soon, because too
much has been written and expected (like Xlib, XFree86 etc.) that
is now written in C.

The ironic thing is that it might happen that our kids or grandkids
may be the ones that finally recognize Ada for what it is. It is
like some scientists and their discoveries -- they are never
really appreciated in their own lifetimes.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: IBM Acquires Rational Ada

[Wes Groleau]

>> pretty. Any level of difficulty starts discouraging the average user and
>> pointing them down the path of least resistance.

That, unfortunately is a bigger key than just with libraries.

With C, you can lean on the keyboard and almost generate
something that will compile.   Many people will dump Ada
about the fifth time their program is rejected.  They'll
never get far enough to find out that it would have had
fewer errors.

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Wes Groleau wrote:
>>> pretty. Any level of difficulty starts discouraging the average user and
>>> pointing them down the path of least resistance.
> 
> That, unfortunately is a bigger key than just with libraries.
> 
> With C, you can lean on the keyboard and almost generate
> something that will compile.   Many people will dump Ada
> about the fifth time their program is rejected.  They'll
> never get far enough to find out that it would have had
> fewer errors.

It is true that learning to do things the "Ada way" will
create some frustration in beginners. However, I can say
that I am always grateful for what the compiler finds up
front.

The challenge is to educate people that fighting with
the compiler is much preferred over looking
for memory leaks and other odd corruption problems.  In other
words quality time spent with your Ada compiler is much
less than the quality time you spend with your debugger.

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

Re: IBM Acquires Rational Ada

[steve_H]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3DF6653D.3030603@cogeco.ca>...
 
> It is true that learning to do things the "Ada way" will
> create some frustration in beginners. However, I can say
> that I am always grateful for what the compiler finds up
> front.
> 

I think this is a way similar to the Latex vs Word debate. Let 
Latex be Ada here and MS Word be C.

It is much easier to write a quick something in MS Word. Just open
the document and start typing. 

It takes more time to first learn Latex, few commands to learn, and more
advanced commands, and one has to compile it and then view it. However,
if one invests the time to learn Latex, and get all the commands right, 
then their final output will be so much better than the 'quick' 
MS Word can ever generate, and it is a great investment that will 
pay multiples over a life time. And actually with time, one will find the
producing documents with Latex is faster.

But most will not spend the few short days to learn Latex initially, (will 
get either frustrated quickly, or would not even try it as it 'looks' hard) 
and will insead spend their life producing ugly documents with MS Word.





> The challenge is to educate people that fighting with
> the compiler is much preferred over looking
> for memory leaks and other odd corruption problems.  In other
> words quality time spent with your Ada compiler is much
> less than the quality time you spend with your debugger.

OT: Word processing (was: Re: IBM Acquires Rational Ada)

[Anders Wirzenius]

"steve_H" <nma124@hotmail.com> wrote in message news:8db3d6c8.0212101850.51506572@posting.google.com...
> It takes more time to first learn Latex, few commands to learn, and more
> advanced commands, and one has to compile it and then view it. However,
> if one invests the time to learn Latex, and get all the commands right,
> then their final output will be so much better than the 'quick'
> MS Word can ever generate, and it is a great investment that will
> pay multiples over a life time. And actually with time, one will find the
> producing documents with Latex is faster.
>
> But most will not spend the few short days to learn Latex initially, (will
> get either frustrated quickly, or would not even try it as it 'looks' hard)
> and will insead spend their life producing ugly documents with MS Word.
>

A side note:
I made three files, one with a MS Notepad, one with MS Word, one with MS Excel. With each program I stored only the letter 'A'.
Using the current settings that are used in my company (just ordinary "Windows settings", no special) I got the following result:

File length in bytes:
text editor: 1
MS Word: 19456
MS Excel: 13824

This means over 10k of meta and formatting data in addition to the actual data.
The Excel file contained my name three times, the Word file only two times.

Anders

Re: IBM Acquires Rational Ada

[Marin David Condic]

Interesting, but not compelling. Consider that if all I want is a quick note
to my boss, that opening up a document and starting to type is all I really
want to do. If I've got to learn all sorts of commands that ultimately
produce an illuminated manuscript, that's nice, but not what I needed.

While I'm all in favor of Ada catching errors up front and I accept that
this means programmers need a mental shift from C to avoid frustration, I
think that this "Ada Mentality" is in some way blinding the community to
what the ultimate customer wants and needs. We keep thinking "Take your time
and get it right. It'll pay in the long run". This may be true and the
customer will be glad he's got that one day, but what would be far more
compelling in making the sale is "This will get you to market faster!" If
the Ada community started focusing in on developmental leverage that got
someone to market quicker, that would be a quality they wouldn't (and
couldn't!) ignore.

If you build & market accounting software and Ada could get your new product
done a couple of months ahead of your competitor's new product, you'll jump
on it - or your competitor will. Getting a *good* accounting package out of
the deal would be a bonus, but a *good* one that hits the shelves 6 months
after the competitors package does is worthless.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

steve_H <nma124@hotmail.com> wrote in message
news:8db3d6c8.0212101850.51506572@posting.google.com...
>
> I think this is a way similar to the Latex vs Word debate. Let
> Latex be Ada here and MS Word be C.
>
> It is much easier to write a quick something in MS Word. Just open
> the document and start typing.
>
> It takes more time to first learn Latex, few commands to learn, and more
> advanced commands, and one has to compile it and then view it. However,
> if one invests the time to learn Latex, and get all the commands right,
> then their final output will be so much better than the 'quick'
> MS Word can ever generate, and it is a great investment that will
> pay multiples over a life time. And actually with time, one will find the
> producing documents with Latex is faster.
>
> But most will not spend the few short days to learn Latex initially, (will
> get either frustrated quickly, or would not even try it as it 'looks'
hard)
> and will insead spend their life producing ugly documents with MS Word.
>
>
>
>
>
> > The challenge is to educate people that fighting with
> > the compiler is much preferred over looking
> > for memory leaks and other odd corruption problems.  In other
> > words quality time spent with your Ada compiler is much
> > less than the quality time you spend with your debugger.

Re: IBM Acquires Rational Ada

[Wes Groleau]

> what the ultimate customer wants and needs. We keep thinking "Take your time
> and get it right. It'll pay in the long run". This may be true and the
> customer will be glad he's got that one day, but what would be far more
> compelling in making the sale is "This will get you to market faster!" If
> the Ada community started focusing in on developmental leverage that got
> someone to market quicker, that would be a quality they wouldn't (and
> couldn't!) ignore.

If you could _convince_ them it would get them to market faster.
My point was that they first find out that it doesn't get
something COMPILED faster, so they drop it and never find out
how long it takes to get to market.

And in the "hacker" world (in the good sense of the term),
getting something compiled is for some a good goal in itself,
because that way you get it out there faster for other people
to debug.

Hmmm.  Come to think of it, getting it out there for
the customer to debug seems to be the paradigm in
some commercial domains as well!

Re: IBM Acquires Rational Ada

[Marin David Condic]

Well, yes, of course. You still have to make your case. I've made the case
with metrics within the realm of digital electronic controls - but that's an
environment with very specialized needs. I believe the case *could* be made
in other areas, but Ada has to be bigger than just a compiler that conforms
to the ARM. If, for example, there were an environment that rivaled MSVC++
in terms of functionality and did it more reliably and with less obfuscation
and you had some data to indicate that similar apps can be built faster with
"Visual Ada" than with MSVC++, would that not start making a case for why
people should switch?

My real point is that the "Ada Mentality" has traditionally concentrated on
high reliability and lower long-term costs for long-lived systems and that
this is not necessarily what the vast bulk of developers are buying. Not
that its a bad thing to have high reliability, etc. More a matter of the
driving factors in many development efforts tend to be around "How quick can
you get me something that works out the door???" Without analyzing the
rightness/wrongness of that driver, accept fot the moment that it is a fact.
(id est, that most developments are driven by time to market.) If that's the
case and you walk in with your Ada compiler and someone else walks in with
their XYZ language that has a spiffy IDE, massive library of utilities, GUI,
etc. You tell the customer "My language will build highly reliable
long-lived software better than XYZ." and the other guy says "But with all
my tools and libraries, I'll get you a product 3 to 6 months sooner than his
will because you'll have to spend all that time duplicating the same stuff
in Ada that already comes with my kit." Who wins the sale?

So if Ada as a community or culture or whatever it is, were to shift its
emphasis and start concentrating on Time To Market, I'd bet we would come up
with some really successful stuff. If the language standardization Powers
That Be put that at the top of their list of priorities in considering
revisions, that would help. If the vendors looked to optimize, demonstrate
and sell Time To Market, that would help. If the hackers started using their
imaginations on what/how to build software faster through interesting
hacker-tools, that would help. If the academics did more studies on
productivity in software development and research into tools/techniques that
made Ada faster in this regard, that would help.

There are no guarantees here, but I think that in many cases Ada gets
dismissed because of Time To Market issues and so addressing that becomes
the cost of admission if it wants to be a player.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Wes Groleau <wesgroleau@despammed.com> wrote in message
news:WcIJ9.2225$c6.2445@bos-service2.ext.raytheon.com...
>
> If you could _convince_ them it would get them to market faster.
> My point was that they first find out that it doesn't get
> something COMPILED faster, so they drop it and never find out
> how long it takes to get to market.
>
> And in the "hacker" world (in the good sense of the term),
> getting something compiled is for some a good goal in itself,
> because that way you get it out there faster for other people
> to debug.
>
> Hmmm.  Come to think of it, getting it out there for
> the customer to debug seems to be the paradigm in
> some commercial domains as well!
>

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Well, yes, of course. You still have to make your case. I've made the case
> with metrics within the realm of digital electronic controls - but that's an
> environment with very specialized needs. I believe the case *could* be made
> in other areas, but Ada has to be bigger than just a compiler that conforms
> to the ARM. If, for example, there were an environment that rivaled MSVC++
> in terms of functionality and did it more reliably and with less obfuscation
> and you had some data to indicate that similar apps can be built faster with
> "Visual Ada" than with MSVC++, would that not start making a case for why
> people should switch?

This is the IDE and libraries case. Yes, improvements there would
create some encouragement for Ada use. I agree that this is certainly
one part of the problem.

> My real point is that the "Ada Mentality" has traditionally concentrated on
> high reliability and lower long-term costs for long-lived systems and that
> this is not necessarily what the vast bulk of developers are buying. Not
> that its a bad thing to have high reliability, etc. 

Getting back to the language (which I think was the suggested issue
earlier), was that the "Ada Mentality" requires you to structure your
programs a bit differently (hence the "frustration"). But here, I think
this is just a matter of becoming familiar with what is there (language
features, generics, standard and public packages etc.)

In response to the quick to market point,
it is still possible to "hack" Ada code to produce quick
results. The problem is only that you end up with ugly disorganized code,
with perhaps a number of Var'Address, Var'Unchecked_Access or GNAT
specific Var'Unrestricted_Access all over the place. But this is no
different than C/C++ when it is hacked together either.

So my point is really that if you want to hack, Ada does let you do
that. It is just as in any other language, you'll also pay the
price for it later ;-)

Getting back now to your point of IDEs and better general purpose
packages (libraries), I agree that there is a lot of work to be
done there still.

For example, you could get near standard conformance on text screens.
Yet, there does not exist any _standard_ curses package. There are
some public versions of bindings, but none of them are
complete or "standard". So even text based applications are
barely accomplished in a portable fashion.  In this sense IMHO,
Ada is still better suited to embedded applications, rather than
the general purpose use that other languages are used for.

But I still believe that there is hope that this may change
over time. I think that the Ada standards need to move beyond
the focus of the embedded market to the business and general
purpose use to improve its acceptability.  Give us a _PROPER_
Ada.Calendar package for a start! (can't determine the day of
the week for example)

> So if Ada as a community or culture or whatever it is, were to shift its
> emphasis and start concentrating on Time To Market, I'd bet we would come up
> with some really successful stuff.
...
> 
> MDC

And if they actually did that (shift emphasis), there would be
less that would need to craft so much from scratch (like a
standard and complete curses binding).

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

Re: IBM Acquires Rational Ada

[Wes Groleau]

> it is still possible to "hack" Ada code to produce quick
> results. The problem is only that you end up with ugly disorganized code,
> with perhaps a number of Var'Address, Var'Unchecked_Access or GNAT
> specific Var'Unrestricted_Access all over the place. But this is no
> different than C/C++ when it is hacked together either.

Actually, there is a difference:
In Ada, it stands out as ugly.
In C/C++ it looks like the rest of the code.
In Java, you can't do it (supposedly).

:-)

Re: IBM Acquires Rational Ada

[Marin David Condic]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
news:3DF8D33F.9020205@cogeco.ca...
>
> Getting back to the language (which I think was the suggested issue
> earlier), was that the "Ada Mentality" requires you to structure your
> programs a bit differently (hence the "frustration"). But here, I think
> this is just a matter of becoming familiar with what is there (language
> features, generics, standard and public packages etc.)
>
In this particular case, I was talking of the "Ada Mentality" with respect
to language design issues, rather than coding style. We've been asking the
question "How do we make the language more reliable or more safe or more
comprehensible to the maintainer?" which is fair and reasonable but not what
is of critical importance to the customer. Asking "How can we make Ada get
an app out the door quicker than its competitors?" is likely to be a more
profitable line of inquiry. The language is already safer, more reliable,
more maintainable, etc, than just about anything out there already, but that
"Better Mousetrap" is not apparently what the market has so much of an
interest in.


>
> For example, you could get near standard conformance on text screens.
> Yet, there does not exist any _standard_ curses package. There are
> some public versions of bindings, but none of them are
> complete or "standard". So even text based applications are
> barely accomplished in a portable fashion.  In this sense IMHO,
> Ada is still better suited to embedded applications, rather than
> the general purpose use that other languages are used for.
>
To start with, I don't think that trying to add some sort of support for
character cell terminals is going to impress anybody much. ("Wow! I'm
impressed! You guys put into the language something that C has had for 20+
years and got there just in time for the character cell terminal to go the
way of the punchcard. What's next? A paper tape I/O package???")

Also, if I were doing it, I wouldn't make bindings. I think that just ends u
p in the "Me Too!!!" category and makes your stuff dependent on what happens
in another language - also requiring you to haul around another compiler. If
you wanted a curses package, it would be better (and not that big a deal) to
implement it from the ground up in Ada and give it an Ada flavor while
you're at it. You could probably even dramatically improve it beyond just
cursor positioning and the like - give it more of a GUI feel (DEC had
something like this - pasteboards, windows, etc, all out of VT220's.)

That said, it probably wouldn't hurt to throw in some version of a curses
package if there was some reasonable perception out there that it would be
mildly useful. (I just wouldn't advertize it as The Major Ada Productivity
Improvement.)

Suppose we had a package called "CAL" ("Conventional Ada Library") and under
it we had, at minimum, a branch called "CAL.Containers". There's no reason
someone couldn't propose a "CAL.Curses" and if whoever the controlling body
of the library was agreed that it was at least moderately useful and not too
difficult to make work on most platforms, I don't see why it should be kept
out of the library. The notion being that this "CAL" library would be some
semi-formal (Suit&Tie - No Tux Required :-) reference implementation that
could maybe be released every 6 months or so and thus react quickly to what
the perceived needs are of the Ada community and beyond. It would be a LOT
more useful than waiting for some limited language extensions to come around
every ten to fifteen years via the ARM.

>
> And if they actually did that (shift emphasis), there would be
> less that would need to craft so much from scratch (like a
> standard and complete curses binding).
>
That is exactly my claim. If you provide a million lines of code to the
developer and he finds 100,000 lines of that is useful in getting his app
out the door, he's got a reason to go use Ada. People often use languages
they don't like because of all the leverage that goes with it. I've worked
with guys who have been programming things in C for forever and they are
fully aware of its weaknesses and wish they were using something else, but
they've got some embedded RTOS or graphics library or something else that
would be too costly to redevelop in another language, so they keep using C.
Give them an Ada substitute and maybe they can see their way to switching
languages.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
> news:3DF8D33F.9020205@cogeco.ca...
...
>>For example, you could get near standard conformance on text screens.
>>Yet, there does not exist any _standard_ curses package. There are
>>some public versions of bindings, but none of them are
>>complete or "standard". So even text based applications are
>>barely accomplished in a portable fashion.  In this sense IMHO,
>>Ada is still better suited to embedded applications, rather than
>>the general purpose use that other languages are used for.
> 
> To start with, I don't think that trying to add some sort of support for
> character cell terminals is going to impress anybody much. ("Wow! I'm
> impressed! You guys put into the language something that C has had for 20+
> years and got there just in time for the character cell terminal to go the
> way of the punchcard. What's next? A paper tape I/O package???")

I am very aware that text "fails to impress" people these days, but when
you own the company, you don't necessarily care that those under you
are stuck using cheap dumb terminals (especially if clients never get
tours for impressions). There are still a large number of warehouse
(and similar) situations, where they are quite content to use dumb
terminals. They're cheap, never need software upgrades, don't get
viruses, can't pass viruses onto the LAN etc. They also don't need
Microsoft licenses/extortion to keep them going.

Furthermore, text mode apps are very cheap and easy to maintain
compared to the GUI counter-parts.  I'll grant that good IDEs make
GUI maintenance easier. But overall, my experience is that they
take much longer to produce and cost more in time to maintain.

I still see dumb terminals in use at stores, particularly
video rental stores etc. Banks are still very text based.

So while it is not impressive technology, don't write it off.  It is
also very good console technology, when you cannot get your X server
running on Linux/*BSD/UNIX.

One last thing to consider is that data entry is far more efficient
on a properly designed text mode interface than a GUI screen. Any
time the operator has to take the hand(s) off the keyboard to work
a mouse, is an instant degradation in productivity.  I've seen
operators bang away at the keyboard on a text mode app
and never look at the screen until they reach
the point of Save/Update. You don't get that
experience with any of the GUI apps I've seen.

So yes, I see value in a "standard" or "defacto standard" text
mode interface.

> Also, if I were doing it, I wouldn't make bindings. 

That is my preference also ;-)

> I think that just ends u
> p in the "Me Too!!!" category and makes your stuff dependent on what happens
> in another language - also requiring you to haul around another compiler. If
> you wanted a curses package, it would be better (and not that big a deal) to
> implement it from the ground up in Ada and give it an Ada flavor while
> you're at it. You could probably even dramatically improve it beyond just
> cursor positioning and the like - give it more of a GUI feel (DEC had
> something like this - pasteboards, windows, etc, all out of VT220's.)

But who is going to do it? A binding is less work was my point.

I'd also love to see the entier X11/MOTIF framework rewritten in an
object oriented language (Ada naturally), but until someone takes on
this mamoth task, we'll both be sitting here wishing ;-)

> That said, it probably wouldn't hurt to throw in some version of a curses
> package if there was some reasonable perception out there that it would be
> mildly useful. (I just wouldn't advertize it as The Major Ada Productivity
> Improvement.)

No, text mode is frowned on by most people. However, if you have just
accounting, warehouse or even some scientific data to maintain, a text
mode system is probably more productive and your IT department can
respond to changes more quickly.

No, it certainly wouldn't be an "Ada selling point" -- but at least one
practical library tool.

> Suppose we had a package called "CAL" ("Conventional Ada Library") and under
> it we had, at minimum, a branch called "CAL.Containers". There's no reason
> someone couldn't propose a "CAL.Curses" and if whoever the controlling body
> of the library was agreed that it was at least moderately useful and not too
> difficult to make work on most platforms, I don't see why it should be kept
> out of the library. The notion being that this "CAL" library would be some
> semi-formal (Suit&Tie - No Tux Required :-) reference implementation that
> could maybe be released every 6 months or so and thus react quickly to what
> the perceived needs are of the Ada community and beyond. It would be a LOT
> more useful than waiting for some limited language extensions to come around
> every ten to fifteen years via the ARM.

Agreed. Standards move very slowly, and sometimes "works of art" can
become standards (much like the C++ STL did).

>>And if they actually did that (shift emphasis), there would be
>>less that would need to craft so much from scratch (like a
>>standard and complete curses binding).
> 
> That is exactly my claim. If you provide a million lines of code to the
> developer and he finds 100,000 lines of that is useful in getting his app
> out the door, he's got a reason to go use Ada. People often use languages
> they don't like because of all the leverage that goes with it. I've worked
> with guys who have been programming things in C for forever and they are
> fully aware of its weaknesses and wish they were using something else, but
> they've got some embedded RTOS or graphics library or something else that
> would be too costly to redevelop in another language, so they keep using C.
> Give them an Ada substitute and maybe they can see their way to switching
> languages.
> 
> MDC

I am not disagreeing with you here. But some were saying that many
can't get past the hassle of the "compile". To me, the "hassle" is
a well appreciated "feature" because it saves me a great deal of time,
not having to chase down what would be stupid errors.

One thing that does bug me though is this limitation that you cannot
take a procedure'Access within a generic body. This makes for extremely
clumsy work-arounds when you want to register callbacks!  But this issue
should be the subject of another thread ;-)

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

Re: IBM Acquires Rational Ada

[Wes Groleau]

> I am not disagreeing with you here. But some were saying that many
> can't get past the hassle of the "compile". To me, the "hassle" is
> a well appreciated "feature" because it saves me a great deal of time,
> not having to chase down what would be stupid errors.

I feel the same way, _but_ what I was saying is that
potential "converts" try to compile something five or six
times and then go back to C.  They never find out about
how it prevents errors down the road, because they back up
and take the other road.

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Wes Groleau wrote:
>> I am not disagreeing with you here. But some were saying that many
>> can't get past the hassle of the "compile". To me, the "hassle" is
>> a well appreciated "feature" because it saves me a great deal of time,
>> not having to chase down what would be stupid errors.
> 
> I feel the same way, _but_ what I was saying is that
> potential "converts" try to compile something five or six
> times and then go back to C.  They never find out about
> how it prevents errors down the road, because they back up
> and take the other road.

Yet, many of them forget about the same experience they had when
they were first learning C ;-)

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

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Wes Groleau wrote:
>>> I feel the same way, _but_ what I was saying is that
>>> potential "converts" try to compile something five or six
>>> times and then go back to C.  They never find out about
>>> how it prevents errors down the road, because they back up
>>> and take the other road.
>>
>> Yet, many of them forget about the same experience they had when
>> they were first learning C ;-)
> 
> They didn't have that experience when they were
> first learning C.  C doesn't complain when you
> assign a char to a bool or a bool to an int.
> Nor does C complain when you use an assignment
> for a conditional or vice versa.  Nor does a
> C compiler tell you it's illegal to use 100 for
> an index when the array ends at 10.  et cetera

Of course. That was understood. But anyone learning a new
language struggles with the compiler at first. That was
the point I was making (granted that C is much more
forgiving also).

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

Re: IBM Acquires Rational Ada

[Wes Groleau]

> Of course. That was understood. But anyone learning a new
> language struggles with the compiler at first. That was
> the point I was making (granted that C is much more
> forgiving also).

Sure, that's true.  My point was that many see
that Ada is much less frogiving and abandon it
_without_ ever arriving at the evidence that
there's a good reason for being less forgiving.

Re: IBM Acquires Rational Ada

[John R. Strohm]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:KIkL9.2260$c6.2599@bos-service2.ext.raytheon.com...
> >> I feel the same way, _but_ what I was saying is that
> >> potential "converts" try to compile something five or six
> >> times and then go back to C.  They never find out about
> >> how it prevents errors down the road, because they back up
> >> and take the other road.
> >
> > Yet, many of them forget about the same experience they had when
> > they were first learning C ;-)
>
> They didn't have that experience when they were
> first learning C.  C doesn't complain when you
> assign a char to a bool or a bool to an int.
> Nor does C complain when you use an assignment
> for a conditional or vice versa.  Nor does a
> C compiler tell you it's illegal to use 100 for
> an index when the array ends at 10.  et cetera

Actually, under certain circumstances, gcc will complain about assigning
e.g. a bool to an int.

I had to fix a few of those recently, when I installed GNU Common LISP on a
Linux box.  I suppose I should've sent FSF some bug reports against them...

Re: IBM Acquires Rational Ada

[Randy Brukardt]

Marin David Condic wrote in message ...
>Also, if I were doing it, I wouldn't make bindings. I think that just
ends u
>p in the "Me Too!!!" category and makes your stuff dependent on what
happens
>in another language - also requiring you to haul around another
compiler. If
>you wanted a curses package, it would be better (and not that big a
deal) to
>implement it from the ground up in Ada and give it an Ada flavor while
>you're at it. You could probably even dramatically improve it beyond
just
>cursor positioning and the like - give it more of a GUI feel (DEC had
>something like this - pasteboards, windows, etc, all out of VT220's.)


That's JWindows, which has been a part of Janus/Ada for MS-DOS and
Janus/Ada for Unix since the late 1980's. We originally developed it to
use for our original IDE (JAWS). It does multiple, overlapping text
windows, colors, cursor control, and drop down menus. It's implemented
by a low-level package that went direct to the hardware on MS-DOS and
used termcap (the underlying mechanism for curses) on Unix.

We redesigned it for Ada 9x during the Ada 9x project (thus, the Ada 95
version is different than the Ada 83). Indeed, it provided the starting
model for Claw.

              Randy Brukardt.

Re: IBM Acquires Rational Ada

[Marin David Condic]

Randy Brukardt <randy@rrsoftware.com> wrote in message
news:uvskpvaik0db2b@corp.supernews.com...
>
> That's JWindows, which has been a part of Janus/Ada for MS-DOS and
> Janus/Ada for Unix since the late 1980's. We originally developed it to
> use for our original IDE (JAWS). It does multiple, overlapping text
> windows, colors, cursor control, and drop down menus. It's implemented
> by a low-level package that went direct to the hardware on MS-DOS and
> used termcap (the underlying mechanism for curses) on Unix.
>
> We redesigned it for Ada 9x during the Ada 9x project (thus, the Ada 95
> version is different than the Ada 83). Indeed, it provided the starting
> model for Claw.
>

Well, now there seems to be an answer! I'd guess that something like this
would not be too hard to make reasonably portable between Windows and Unix
(thus covering the bulk of the bases). Assuming an effort got started to
make some kind of "Standard" Ada library, would you think that this might be
included?

Maybe that's a way to go - get the various vendors to look at what they
already have as possible contributions and then find a way to restructure it
under some sort of common tree. With a little bit of code modification, you
have specified a common interface that all vendors can share and immediately
support with their existing parts. "We supply A, B and C of the Common Ada
Library, but not yet D, E and F...". Depending on licensing and willingness
on the part of vendors to share, it might be a really fast way of getting
something going. The advantage to the vendors is that they are making Ada
more attractive to the customers they are *not* getting at the moment rather
than struggling to win over the pool of customers already there. Given where
Ada is today, it would seem that cooperation between the Ada vendors would
be more profitable than competition. Get that pie growing and everyone will
get get a bigger slice.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: IBM Acquires Rational Ada

[Randy Brukardt]

Marin David Condic wrote in message ...
>Randy Brukardt <randy@rrsoftware.com> wrote in message
>news:uvskpvaik0db2b@corp.supernews.com...
>>
>> That's JWindows, which has been a part of Janus/Ada for MS-DOS and
>> Janus/Ada for Unix since the late 1980's. We originally developed it
to
>> use for our original IDE (JAWS). It does multiple, overlapping text
>> windows, colors, cursor control, and drop down menus. It's
implemented
>> by a low-level package that went direct to the hardware on MS-DOS and
>> used termcap (the underlying mechanism for curses) on Unix.
>>
>> We redesigned it for Ada 9x during the Ada 9x project (thus, the Ada
95
>> version is different than the Ada 83). Indeed, it provided the
starting
>> model for Claw.
>>
>
>Well, now there seems to be an answer! I'd guess that something like
this
>would not be too hard to make reasonably portable between Windows and
Unix
>(thus covering the bulk of the bases). Assuming an effort got started
to
>make some kind of "Standard" Ada library, would you think that this
might be
>included?


Sure, we have no real interest in it anymore.

This library was 100% portable between Unix and MS-DOS, and it would be
simple to build a low-level implementation for the console in Windows.
It would be much harder to build an implementation that could map to the
Windows (or other) GUI, but it would be possible.

I even wrote a "form" package for it, so it even had primitive dialog
boxes available, along with the drop-down menus and windows. But no
graphics of any kind.

             Randy.

calenday (was Re: IBM Acquires Rational Ada

[Peter Hermann]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> But I still believe that there is hope that this may change
> over time. I think that the Ada standards need to move beyond
> the focus of the embedded market to the business and general
> purpose use to improve its acceptability.  Give us a _PROPER_
> Ada.Calendar package for a start! (can't determine the day of
> the week for example)

http://www.csv.ica.uni-stuttgart.de/homes/ph/adapilotresources/basic_tools/calenday.ads

which is ready to be built into ada.calendar of gnat for Ada2005.
Of course only after finding a common consensus about the most 
useful spec. :-)
I am ready to accept suggestions.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: calenday (was Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Peter Hermann wrote:
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> 
>>But I still believe that there is hope that this may change
>>over time. I think that the Ada standards need to move beyond
>>the focus of the embedded market to the business and general
>>purpose use to improve its acceptability.  Give us a _PROPER_
>>Ada.Calendar package for a start! (can't determine the day of
>>the week for example)
> 
> http://www.csv.ica.uni-stuttgart.de/homes/ph/adapilotresources/basic_tools/calenday.ads
> 
> which is ready to be built into ada.calendar of gnat for Ada2005.
> Of course only after finding a common consensus about the most 
> useful spec. :-)
> I am ready to accept suggestions.

I would suggest one more small point WRT to:

type day_name_type is (mon,tue,wed,thu,fri,sat,sun);

Add a representation clause to guarantee that the values
start with sun => 0, mon => 1 etc.  For some code, it is
much easier to work with the day of the week in the form
of a number.

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

Re: calenday (was Re: IBM Acquires Rational Ada

[Bill Findlay]

On 16/12/02 18:38, in article 3DFE1D97.6020109@cogeco.ca, "Warren W. Gay
VE3WWG" <ve3wwg@cogeco.ca> wrote:
> 
> I would suggest one more small point WRT to:
> 
> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> 
> Add a representation clause to guarantee that the values
> start with sun => 0, mon => 1 etc.  For some code, it is
> much easier to work with the day of the week in the form
> of a number.

I'm puzzled by this advice.

day_name_type'Pos(mon) .. day_name_type'Pos(sun)

is necessarily 0 .. 6, is it not?

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: calenday (was Re: IBM Acquires Rational Ada

[David C. Hoos]

----- Original Message ----- 
From: "Bill Findlay" <yaldnifw@blueyonder.co.uk>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Monday, December 16, 2002 1:04 PM
Subject: Re: calenday (was Re: IBM Acquires Rational Ada


> On 16/12/02 18:38, in article 3DFE1D97.6020109@cogeco.ca, "Warren W. Gay
> VE3WWG" <ve3wwg@cogeco.ca> wrote:
> > 
> > I would suggest one more small point WRT to:
> > 
> > type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> > 
> > Add a representation clause to guarantee that the values
> > start with sun => 0, mon => 1 etc.  For some code, it is
> > much easier to work with the day of the week in the form
> > of a number.
> 
> I'm puzzled by this advice.
> 
> day_name_type'Pos(mon) .. day_name_type'Pos(sun)
> 
> is necessarily 0 .. 6, is it not?
> 
Yes, the _pos_ attribute is defined by the language as you state,
but Warren is looking to have the _representation_ specified in
the package specification.  This insures that instantiations of
Ada.Unchecked_Conversion between day_name_type and
integer types produce specified results.

> -- 
> Bill-Findlay chez blue-yonder.co.uk ("-" => "")
> 
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 

Re: calenday (was Re: IBM Acquires Rational Ada

[Bill Findlay]

On 16/12/02 20:25, in article
mailman.1040070362.25927.comp.lang.ada@ada.eu.org, "David C. Hoos"
<david.c.hoos.sr@ada95.com> wrote:

> 
> ----- Original Message -----
> From: "Bill Findlay" <yaldnifw@blueyonder.co.uk>
> 
> 
>> On 16/12/02 18:38, in article 3DFE1D97.6020109@cogeco.ca, "Warren W. Gay
>> VE3WWG" <ve3wwg@cogeco.ca> wrote:
>>> 
>>> I would suggest one more small point WRT to:
>>> 
>>> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
>>> 
>>> Add a representation clause to guarantee that the values
>>> start with sun => 0, mon => 1 etc.  For some code, it is
>>> much easier to work with the day of the week in the form
>>> of a number.
>> 
>> I'm puzzled by this advice.
>> 
>> day_name_type'Pos(mon) .. day_name_type'Pos(sun)
>> 
>> is necessarily 0 .. 6, is it not?
>> 
> Yes, the _pos_ attribute is defined by the language as you state,
> but Warren is looking to have the _representation_ specified in
> the package specification.  This insures that instantiations of
> Ada.Unchecked_Conversion between day_name_type and
> integer types produce specified results.
> 

Yes, but if what you want is "to work with the day of the week in
the form of a number", why use Unchecked_Conversion when
day_name_type'Pos does what you want without further ado?

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: calenday (was Re: IBM Acquires Rational Ada

[David C. Hoos]

----- Original Message -----
From: "Bill Findlay" <yaldnifw@blueyonder.co.uk>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Monday, December 16, 2002 2:37 PM
Subject: Re: calenday (was Re: IBM Acquires Rational Ada


> On 16/12/02 20:25, in article
> mailman.1040070362.25927.comp.lang.ada@ada.eu.org, "David C. Hoos"
> <david.c.hoos.sr@ada95.com> wrote:
>
> >
> > ----- Original Message -----
> > From: "Bill Findlay" <yaldnifw@blueyonder.co.uk>
> >
> >
> >> On 16/12/02 18:38, in article 3DFE1D97.6020109@cogeco.ca, "Warren W.
Gay
> >> VE3WWG" <ve3wwg@cogeco.ca> wrote:
> >>>
> >>> I would suggest one more small point WRT to:
> >>>
> >>> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> >>>
> >>> Add a representation clause to guarantee that the values
> >>> start with sun => 0, mon => 1 etc.  For some code, it is
> >>> much easier to work with the day of the week in the form
> >>> of a number.
> >>
> >> I'm puzzled by this advice.
> >>
> >> day_name_type'Pos(mon) .. day_name_type'Pos(sun)
> >>
> >> is necessarily 0 .. 6, is it not?
> >>
> > Yes, the _pos_ attribute is defined by the language as you state,
> > but Warren is looking to have the _representation_ specified in
> > the package specification.  This insures that instantiations of
> > Ada.Unchecked_Conversion between day_name_type and
> > integer types produce specified results.
> >
>
> Yes, but if what you want is "to work with the day of the week in
> the form of a number", why use Unchecked_Conversion when
> day_name_type'Pos does what you want without further ado?
Suppose you have an array of day_name_type that you want to
convert to an array of numbers.  It's much cheaper to use
Unchecked_Conversion than it is to loop through the array and
call the 'Pos function or the 'Val function on each element of
the array.

>
> --
> Bill-Findlay chez blue-yonder.co.uk ("-" => "")
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: calenday (was Re: IBM Acquires Rational Ada

[Bill Findlay]

On 16/12/02 21:41, in article
mailman.1040074922.28258.comp.lang.ada@ada.eu.org, "David C. Hoos"
<david.c.hoos.sr@ada95.com> wrote:

[snip]
>>>> On 16/12/02 18:38, in article 3DFE1D97.6020109@cogeco.ca, "Warren W.Gay
>>>> VE3WWG" <ve3wwg@cogeco.ca> wrote:
>>>>> 
>>>>> I would suggest one more small point WRT to:
>>>>> 
>>>>> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
>>>>> 
>>>>> Add a representation clause to guarantee that the values
>>>>> start with sun => 0, mon => 1 etc.  For some code, it is
>>>>> much easier to work with the day of the week in the form
>>>>> of a number.

> Suppose you have an array of day_name_type that you want to
> convert to an array of numbers.  It's much cheaper to use
> Unchecked_Conversion than it is to loop through the array and
> call the 'Pos function or the 'Val function on each element of
> the array.
> 

Isn't mon => 0, ..., sun => 6 guaranteed to be the
encoding of this type in any case, even without a
representation clause?

Defining sun => 0, mon => 1, inconsistently with 'Pos, is going
to create a distributed inefficiency in processing this type.

Can you see this being worth the hypothetical saving in unchecked array
conversion? (We are discussing unconditional advice here.)

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: calenday (was Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Bill Findlay wrote:
> On 16/12/02 21:41, in article
> mailman.1040074922.28258.comp.lang.ada@ada.eu.org, "David C. Hoos"
> <david.c.hoos.sr@ada95.com> wrote:
> 
> [snip]
> 
>>>>>On 16/12/02 18:38, in article 3DFE1D97.6020109@cogeco.ca, "Warren W.Gay
>>>>>VE3WWG" <ve3wwg@cogeco.ca> wrote:
>>>>>
>>>>>>I would suggest one more small point WRT to:
>>>>>>
>>>>>>type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
>>>>>>
>>>>>>Add a representation clause to guarantee that the values
>>>>>>start with sun => 0, mon => 1 etc.  For some code, it is
>>>>>>much easier to work with the day of the week in the form
>>>>>>of a number.
>>>>>
> 
>>Suppose you have an array of day_name_type that you want to
>>convert to an array of numbers.  It's much cheaper to use
>>Unchecked_Conversion than it is to loop through the array and
>>call the 'Pos function or the 'Val function on each element of
>>the array.
> 
> Isn't mon => 0, ..., sun => 6 guaranteed to be the
> encoding of this type in any case, even without a
> representation clause?
> 
> Defining sun => 0, mon => 1, inconsistently with 'Pos, is going
> to create a distributed inefficiency in processing this type.
> 
> Can you see this being worth the hypothetical saving in unchecked array
> conversion? (We are discussing unconditional advice here.)

Actually, I was not thinking of Unchecked_Conversion when
I suggested the representation clause. You are right in that
the 'Pos(mon) is zero anyway (I didn't know that this was
guaranteed by the language). It is also apparently bad
practice to rely on the representation, because I get the
impression that some Ada compilers may ignore the representation
clause.

My question now is, why is Monday first?  My own personal
preference would be to have Sunday first to be consistent
with the UNIX practice in the use of localtime/gmtime and
mktime(3C) routines.

Was there a reason that Monday was chosen as the first in
this series?

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

Re: calenday (was Re: IBM Acquires Rational Ada

[Peter Hermann]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> My question now is, why is Monday first?  My own personal
> preference would be to have Sunday first to be consistent
> with the UNIX practice in the use of localtime/gmtime and
> mktime(3C) routines.

> Was there a reason that Monday was chosen as the first in
> this series?

I personally very much prefer the Monday to be first
because it is more practical, e.g. 
subtype working_day_type is day_type range mon..fri;

I only can vote for monday in a democracy ;-)
i.e.  I do not want to ignite a flame war with
people from different cultures.
We had these discussions several times and we did not
find consensus. So my hope is in favor of M=1     :-)


-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: calenday (was Re: IBM Acquires Rational Ada

[Bill Findlay]

On 17/12/02 16:26, in article atnj76$c7n$1@news.uni-stuttgart.de, "Peter
Hermann" <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote:
> 
> I personally very much prefer the Monday to be first
> because it is more practical, e.g.
> subtype working_day_type is day_type range mon..fri;
> 

Sunday-first does not prevent you declaring this subtype.
What it would do is require a range check for the working-day predicate,
instead of the single comparison with Monday-first.

> I only can vote for monday in a democracy ;-)
> i.e.  I do not want to ignite a flame war with
> people from different cultures.
> We had these discussions several times and we did not
> find consensus. So my hope is in favor of M=1     :-)
> 

Well, if M is Monday, then you actually favour M=0!

Is this issue the calendrical equivalent of big- vs little-endianism?
8-)

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: calenday (was Re: IBM Acquires Rational Ada

[tmoran]

> This insures that instantiations of
> Ada.Unchecked_Conversion between day_name_type and
> integer types produce specified results.
  An enumeration of days of the week is unlikely to be of the same 'size
as integer'size, so the result is "implementation defined".  And why
worry about that when
  My_Day : constant  array(Day_Of_Week) of Integer
    := (Sunday => 7, Monday => 0, ...
is so simple, portable, and modifiable.

Re: calenday (was Re: IBM Acquires Rational Ada

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> 
> Add a representation clause to guarantee that the values
> start with sun => 0, mon => 1 etc.

Hmmm. It shouldn't fall to the C++ programmer to point out
that 13.4/6 requires that "the associated integer codes shall
satisfy the predefined ordering relation of the type".

Re: calenday (was Re: IBM Acquires Rational Ada

[Simon Wright]

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

> I would suggest one more small point WRT to:
> 
> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);

This (and month_name_type) seems very English and abbreviated.

> Add a representation clause to guarantee that the values
> start with sun => 0, mon => 1 etc.  For some code, it is
> much easier to work with the day of the week in the form
> of a number.

I would have thought the chance of this being standardised was very
close to zero! given 'Pos.

Re: calenday (was Re: IBM Acquires Rational Ada

[Frank Piron]

Hi,

seems to me, that the "calendary" discussion is typical
for ADA95 enthusiasts.

The C - Programmer works for performance and nowaday for
nothing but performance.

The Java - Programmer works for building longer and longer
class names, hoping that someday there is at least one
java application which is platform independent.

The Visual Basic - Programmer works for ... aahhh, money ?

But the ADA community does work for eternity and the hall of
fame in computer programming.

So everything has to be thought out till the very end. But for
the price that many good ideas never come to work.

Frank Piron

Peter Hermann schrieb:
> 
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> > But I still believe that there is hope that this may change
> > over time. I think that the Ada standards need to move beyond
> > the focus of the embedded market to the business and general
> > purpose use to improve its acceptability.  Give us a _PROPER_
> > Ada.Calendar package for a start! (can't determine the day of
> > the week for example)
> 
> http://www.csv.ica.uni-stuttgart.de/homes/ph/adapilotresources/basic_tools/calenday.ads
> 
> which is ready to be built into ada.calendar of gnat for Ada2005.
> Of course only after finding a common consensus about the most
> useful spec. :-)
> I am ready to accept suggestions.
> 
> --
> --Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
> --Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
> --http://www.csv.ica.uni-stuttgart.de/homes/ph/
> --Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: calenday (was Re: IBM Acquires Rational Ada

[Karel Miklav]

I thouhgt they're simply joking :)


Frank Piron wrote:
> Hi,
> 
> seems to me, that the "calendary" discussion is typical
> for ADA95 enthusiasts.
> 
> The C - Programmer works for performance and nowaday for
> nothing but performance.
> 
> The Java - Programmer works for building longer and longer
> class names, hoping that someday there is at least one
> java application which is platform independent.
> 
> The Visual Basic - Programmer works for ... aahhh, money ?
> 
> But the ADA community does work for eternity and the hall of
> fame in computer programming.
> 
> So everything has to be thought out till the very end. But for
> the price that many good ideas never come to work.
> 
> Frank Piron
> 
> Peter Hermann schrieb:
> 
>>Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
>>
>>>But I still believe that there is hope that this may change
>>>over time. I think that the Ada standards need to move beyond
>>>the focus of the embedded market to the business and general
>>>purpose use to improve its acceptability.  Give us a _PROPER_
>>>Ada.Calendar package for a start! (can't determine the day of
>>>the week for example)
>>
>>http://www.csv.ica.uni-stuttgart.de/homes/ph/adapilotresources/basic_tools/calenday.ads
>>
>>which is ready to be built into ada.calendar of gnat for Ada2005.
>>Of course only after finding a common consensus about the most
>>useful spec. :-)
>>I am ready to accept suggestions.
>>
>>--
>>--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
>>--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
>>--http://www.csv.ica.uni-stuttgart.de/homes/ph/
>>--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Frank Piron <frank.piron@konad.de> wrote in message
news:3E01BA24.7648FEC2@konad.de...
>
> But the ADA community does work for eternity and the hall of
> fame in computer programming.
>
> So everything has to be thought out till the very end. But for
> the price that many good ideas never come to work.
>
Alas. All too true. :-(
At least it is a Noble Fault.

If the mentality were to shift *slightly* towards finding a Good Enough
answer that would satisfy 90% of the needs - and doing so in a timely
manner - we might be able to make Ada more attractive to the masses.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

Simon Wright <simon@pushface.org> writes:

> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> 
> > I would suggest one more small point WRT to:
> > 
> > type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> 
> This (and month_name_type) seems very English 

Well, "begin" and "end" are English, too.  It seems to me that if you
want to print out day names in some other language, the program could
internallly use Sunday, Monday, etc, and then do a table lookup to find
the appropriate String to print.

> and abbreviated.

...and uses non-standard case.

- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[tmoran]

> > > type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> the program could internallly use Sunday, Monday, etc, and then do a table
> lookup to find the appropriate String to print.

type Day_Name is (Monday, Tuesday ...
Short_Day_Name : constant array(Day_Name) of String(1 .. 3) := ("Mon", ...
makes it easy to print three letter abbreviations, and Day_Name'image(Day)
would print the full (English) names if you want full length names.  Going
the reverse direction, with an array of different length strings, is
rather less convenient.
  "And on the seventh day He rested" suggests Sunday should be last and
Monday first.  OTOH, both moon and sun are mere astronomical objects,
whereas Thor was a god, so clearly Thursday should be first. ;)

Re: calenday (was Re: IBM Acquires Rational Ada

[Bill Findlay]

On 17/12/02 19:08, in article 9DKL9.380955$P31.141586@rwcrnsc53,
"tmoran@acm.org" <tmoran@acm.org> wrote:

> "And on the seventh day He rested" suggests Sunday should be last and
> Monday first.  OTOH, both moon and sun are mere astronomical objects,
> whereas Thor was a god, so clearly Thursday should be first. ;)

Nope, Tuesday gets it on that basis. 8-)

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: calenday (was Re: IBM Acquires Rational Ada

[Hyman Rosen]

tmoran@acm.org wrote:
>   "And on the seventh day He rested" suggests Sunday should be last

Not for Jews. For us, the seventh day is Saturday.

Re: calenday (was Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <1040155235.443519@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> tmoran@acm.org wrote:
>>   "And on the seventh day He rested" suggests Sunday should be last
> 
> Not for Jews. For us, the seventh day is Saturday.

So the general problem is that enumerated types follow the model
of integer types rather than modular types :-)

Re: calenday (was Re: IBM Acquires Rational Ada

[David C. Hoos]

----- Original Message -----
From: <tmoran@acm.org>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Tuesday, December 17, 2002 1:08 PM
Subject: Re: calenday (was Re: IBM Acquires Rational Ada


> > > > type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> > the program could internallly use Sunday, Monday, etc, and then do a
table
> > lookup to find the appropriate String to print.
>
> type Day_Name is (Monday, Tuesday ...
> Short_Day_Name : constant array(Day_Name) of String(1 .. 3) := ("Mon", ...
> makes it easy to print three letter abbreviations, and Day_Name'image(Day)
> would print the full (English) names if you want full length names.  Going
> the reverse direction, with an array of different length strings, is
> rather less convenient.
>   "And on the seventh day He rested" suggests Sunday should be last and
> Monday first.  OTOH, both moon and sun are mere astronomical objects,
> whereas Thor was a god, so clearly Thursday should be first. ;)

The day of rest  prescribed in the Ten Commandments is the seventh day
or the sabbath, derived from the Hebrew verb shabath  ("rested"), and which
is reflected in the name of the seventh day of the week in several of the
Romance languages -- e.g., Italian "Sabato."
Moreover, the name for the first day of the week in several of the Romance
languages is derived from the Latin Domini ("Lord") -- e.g., Italian
"Domenica."
As a matter of fact the names of the days of the week in Portuguese are
Domingo, Segunda-fiera, Terca-fiera, Quarta-fiera, Quinta-fiera,
Sexta-fiera, Sabado.

So... ISO notwithstanding, it's pretty clear from historical usage that
Sunday is
the first day of the week.

http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: calenday (was Re: IBM Acquires Rational Ada

[Dennis Lee Bieber]

tmoran@acm.org fed this fish to the penguins on Tuesday 17 December 
2002 11:08 am:

> Monday first.  OTOH, both moon and sun are mere astronomical objects,
> whereas Thor was a god, so clearly Thursday should be first. ;)

        Ah, but Freya was a goddess, so by all rights Friday should be 
first... Of course, Odin (Woden) was putative chief god, and likely 
would insist that his day (Wednesday) be first.

-- 
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <

Re: calenday (was Re: IBM Acquires Rational Ada

[Steven Murdoch]

In article <9DKL9.380955$P31.141586@rwcrnsc53>,
 tmoran@acm.org writes:
>  "And on the seventh day He rested" suggests Sunday should be last and
>Monday first.  OTOH, both moon and sun are mere astronomical objects,
>whereas Thor was a god, so clearly Thursday should be first. ;)

ISO 8601 defines the first day of the week to be Monday, and this practice
is also quite widespread (it is the convention in the UK and much of Europe)

Also ISO 8601 defines Monday to be day 1 and Sunday to be day 7 so I would
suggest forcing the representation to be 1..7, if this is not what
the languge defaults to. This also makes many of the date processing
functions slightly easier to understand.

See:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html
for more information.

Steven Murdoch.

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

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

>... It is also apparently bad
> practice to rely on the representation, because I get the
> impression that some Ada compilers may ignore the representation
> clause.

Ada compilers cannot ignore rep clauses.

- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message
news:wccn0n4oazy.fsf@shell01.TheWorld.com...
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>
> >... It is also apparently bad
> > practice to rely on the representation, because I get the
> > impression that some Ada compilers may ignore the representation
> > clause.
>
> Ada compilers cannot ignore rep clauses.
>

They may not be allowed to ignore them, but they sure can refuse to obey
them. Is there a practical difference between: "I can't hear you.
LaLaLaLaLa..." and "Yeah. Right. When hell freezes over!" Either way, I
don't get what I wanted.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message
> news:wccn0n4oazy.fsf@shell01.TheWorld.com...
> > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> >
> > >... It is also apparently bad
> > > practice to rely on the representation, because I get the
> > > impression that some Ada compilers may ignore the representation
> > > clause.
> >
> > Ada compilers cannot ignore rep clauses.
> >
> 
> They may not be allowed to ignore them, but they sure can refuse to obey
> them. Is there a practical difference between: "I can't hear you.
> LaLaLaLaLa..." and "Yeah. Right. When hell freezes over!" Either way, I
> don't get what I wanted.

Yes, there is a practical difference.  In particular, it means that
Warren W. Gay's "bad practice to rely on the representation" comment
above is wrong.  You *can* rely on rep clauses, in the sense that if
your compiler doesn't complain, it must obey the rep clause.
Furthermore, there is a fairly substantial subset of rep clauses that
must be supported by all compilers.  For example, the suggestion of
rep-clausing the Day_Name_Type should be completely portable.  (But I
still think it's not a good idea.)

On the other hand, I agree with your rants about the non-portability of
rep clauses.  If I were designing a language from scratch, I would try
to nail down the rules for rep clauses so that all compilers support
exactly the same ones.  Or, at least, all compilers for the same machine
(where "same machine" can be interpreted to mean that the various values
in System, such as Storage_Unit and Word_Size are the same).  I think I
would also require fairly "complete" support, in the sense of requiring
"weird" bit fields that are extremely inefficient to access.  As you
say, it's very frustrating to use rep clauses for 90% of the cases, and
then be forced to use a completely different mechanism when you run
across "weird" hardware you need to interface to.

- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Rants? Well, perhaps I have a bad habbit of typing with a "shrill" accent.
:-)

Actually, I don't really care about portability. In my business, we'd seldom
have to port something that was this machine-dependent. I'll accept a
totally vendor/processor specific answer - as is usually a requirement when
you've got to dip into rep clauses anyway.

And I wouldn't really characterize the need as relating to "weird" hardware.
I've not usually found much problem, for example, getting a rep-clause to
work to line up with some register word or other device. Usually, its a case
of someone with a communication link packing things together as tightly as
possible or from hardware substantially different from the thing doing the
reading. You get odd-sized bit fields, things that span byte or word or
longword boundaries, unusual numeric formats (1750a 48-bit float, for
example?) and things of that nature. You try to create a record that will
deal with the data and you discover your compiler is going to whine and
snivel about being asked to span things across unusual boundaries. The
instant the possibility exists that you aren't going to be able to make one
message in your catalog work with the compiler in hand, you're likely to
head for an overall solution that *will* work in all cases - id est
twiddling the bits by hand in some manner. You don't usually want to
implement 90% of the messages as records with rep-clauses and then the
remaining 10% as a byte array & access routines. You'd end up building two
totally different infrastructures and should one of your 90% ever change and
the compiler refuse to help, you're rebuilding something dramatically.

Hence (at least part of) my angst over the rep-clause. :-)

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message
news:wcc3cov1hlu.fsf@shell01.TheWorld.com...
>
> On the other hand, I agree with your rants about the non-portability of
> rep clauses.  If I were designing a language from scratch, I would try
> to nail down the rules for rep clauses so that all compilers support
> exactly the same ones.  Or, at least, all compilers for the same machine
> (where "same machine" can be interpreted to mean that the various values
> in System, such as Storage_Unit and Word_Size are the same).  I think I
> would also require fairly "complete" support, in the sense of requiring
> "weird" bit fields that are extremely inefficient to access.  As you
> say, it's very frustrating to use rep clauses for 90% of the cases, and
> then be forced to use a completely different mechanism when you run
> across "weird" hardware you need to interface to.
>
> - Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[tmoran]

> deal with the data and you discover your compiler is going to whine and
> snivel about being asked to span things across unusual boundaries.
What's wrong with the routine to align things, followed by an
Unchecked_Conversion to something with an acceptable rep spec, approach?

   type Bit_Width_Lists is array(Integer range <>) of Positive;
   procedure Align (Source : in     Packed_Data;
                    Control: in     Bit_Width_Lists;
                    Target :    out Ada.Streams.Stream_Element_Array);
   -- Copy sequential bit strings, inserting padding as needed to ensure
   -- that each starts on an alignment boundary in Target.

Unless only a few of the resultant fields are accessed, this won't be much
slower than having the compiler do the shifting and masking, and if some
fields are accessed a lot, it will actually be faster.  This doesn't help
with endianness or foreign floating point etc, but those are semantic
level things that a rep spec can't describe anyway.

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Well, there's all kinds of ways of getting what you want. The thing is that
you have the rep clause there for this purpose, so you hate to come up with
a kludge to get around the fact that it won't.

I'll grant that most of the time, it really isn't a problem. The bulk of the
time, I don't care about representation at all. When I do care about
representation, its typically only as something is going into or coming out
of some device and once I've got it picked apart, the data can go into
un-represented things where the compiler can do what it likes. Even when
we're talking about down at the device level, it usually works because
people don't tend to do things that are all that strange. But there are
still times when getting the data packed as tight as possible - or dealing
with some legacy system - is necessary and you get into issues with the
compiler.

Tagged records probably present the worst problems if you try to throw
representation clauses on them. I've only tinkered with one compiler in this
regard, so I can't speak for all of them and I realize that there are
special problems in this respect. But if you're going to allow rep clauses
on tagged records, there ought to be some ability to actually make them
work. Two problems I had were that a) you have no mechanism to find the
position/size of the tag, so you have no mechanism to offset everything from
it and b) the compiler insisted that all extensions of the record start on a
longword boundary and there was no apparent way to tell it to start
elsewhere - even though it would have been an even byte or word boundary. It
seems to me that those are problems that *could* be addressed and maybe the
rep clause would be more useful.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

<tmoran@acm.org> wrote in message news:5JfM9.395655$P31.145145@rwcrnsc53...
> > deal with the data and you discover your compiler is going to whine and
> > snivel about being asked to span things across unusual boundaries.
> What's wrong with the routine to align things, followed by an
> Unchecked_Conversion to something with an acceptable rep spec, approach?
>
>    type Bit_Width_Lists is array(Integer range <>) of Positive;
>    procedure Align (Source : in     Packed_Data;
>                     Control: in     Bit_Width_Lists;
>                     Target :    out Ada.Streams.Stream_Element_Array);
>    -- Copy sequential bit strings, inserting padding as needed to ensure
>    -- that each starts on an alignment boundary in Target.
>
> Unless only a few of the resultant fields are accessed, this won't be much
> slower than having the compiler do the shifting and masking, and if some
> fields are accessed a lot, it will actually be faster.  This doesn't help
> with endianness or foreign floating point etc, but those are semantic
> level things that a rep spec can't describe anyway.

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

Marin David Condic wrote in message ...
>Tagged records probably present the worst problems if you try to throw
>representation clauses on them. I've only tinkered with one compiler in
this
>regard, so I can't speak for all of them and I realize that there are
>special problems in this respect. But if you're going to allow rep
clauses
>on tagged records, there ought to be some ability to actually make them
>work. Two problems I had were that a) you have no mechanism to find the
>position/size of the tag, so you have no mechanism to offset everything
from
>it and b) the compiler insisted that all extensions of the record start
on a
>longword boundary and there was no apparent way to tell it to start
>elsewhere - even though it would have been an even byte or word
boundary. It
>seems to me that those are problems that *could* be addressed and maybe
the
>rep clause would be more useful.


a) is not a problem in practice. We did this in Claw, and all compilers
put the tag at offset 0. (A few can be told to put it elsewhere, but
that wasn't generally available a few years ago when we did that.) The
size is a problem in that it is implementation-defined.
Ada.Tags.Tag'Size is the correct value, but it isn't static, so you
can't use it in representation clauses. We ended up declaring a constant
TAG_SIZE that we use in the rep. clauses (and compare to
Ada.Tags/Tag'Size as a validity check). However, it is 4 (bytes) in all
of the compilers that we tried, so it really wasn't necessary.

b) is clearly compiler specific. I'd suggest trying to convince your
compiler vendor to improve their compiler. Janus/Ada doesn't require any
alignment for the extension part. And I don't recall having problems
with this in Claw, although perhaps we were lucky.

The biggest non-portability is in the ability (or lack thereof) to put
extension components into "holes" in the parent. This is useful, but can
be really hard to implement (it causes problems with the predefined "="
operation, and I believe that there are other problems that I don't
remember at the moment).

            Randy Brukardt.

Re: calenday (was Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <v04c0ul05vht40@corp.supernews.com>, "Randy Brukardt" <randy@rrsoftware.com> writes:

> a) is not a problem in practice. We did this in Claw, and all compilers
> put the tag at offset 0. (A few can be told to put it elsewhere, but
> that wasn't generally available a few years ago when we did that.) The
> size is a problem in that it is implementation-defined.

Which compilers allowed you (at the time) to specify the tag position ?

What language construct did they use to accept that specification ?

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

Larry Kilgallen wrote in message
<7HQjlgUY7GDY@eisner.encompasserve.org>...
>In article <v04c0ul05vht40@corp.supernews.com>, "Randy Brukardt"
<randy@rrsoftware.com> writes:
>
>> a) is not a problem in practice. We did this in Claw, and all
compilers
>> put the tag at offset 0. (A few can be told to put it elsewhere, but
>> that wasn't generally available a few years ago when we did that.)
The
>> size is a problem in that it is implementation-defined.
>
>Which compilers allowed you (at the time) to specify the tag position ?
>
>What language construct did they use to accept that specification ?

Janus/Ada doesn't allow to specify the location of the tag explicitly,
but it doesn't require a particular position, either. So if you put a
component at location 0, the compiler will put the tag elsewhere (in the
first hole big enough). And if you specify the location of all other
components and the record size, it's pretty clear where the tag is. :-)

Pascal Leroy of Rational has indicated that they had at least one
customer who needed tags other than at location 0, so that their
compiler supports that as well. I don't know if they explicitly allow
specifying it, and I don't know the syntax if they do. I would presume
it is an attribute, following the standard, see 13.5.1(15).

             Randy.

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Randy Brukardt <randy@rrsoftware.com> wrote in message
news:v04c0ul05vht40@corp.supernews.com...
>
>
> a) is not a problem in practice. We did this in Claw, and all compilers
> put the tag at offset 0. (A few can be told to put it elsewhere, but
> that wasn't generally available a few years ago when we did that.) The
> size is a problem in that it is implementation-defined.
> Ada.Tags.Tag'Size is the correct value, but it isn't static, so you
> can't use it in representation clauses. We ended up declaring a constant
> TAG_SIZE that we use in the rep. clauses (and compare to
> Ada.Tags/Tag'Size as a validity check). However, it is 4 (bytes) in all
> of the compilers that we tried, so it really wasn't necessary.
>
I'd suspect that declaring in the standard that all tags shall start at
offset 0 and extend for 32 bits would not cause anyone any rework. I doubt
it would come up often that the offset needed to be anything other than
zero - I can't think of why I'd want it to or why I couldn't make things
work somehow if it were always zero. Having a predefined constant for size
and a mandated (dare I use that word?) starting point at the beginning of
the record ought to be good enough.


> b) is clearly compiler specific. I'd suggest trying to convince your
> compiler vendor to improve their compiler. Janus/Ada doesn't require any
> alignment for the extension part. And I don't recall having problems
> with this in Claw, although perhaps we were lucky.
>
Well, someone must have thought it was more important to longword-align
things than to give the programmer what he asked for. :-) The important part
is that if you're going to have a rep-clause, it needs to give the
programmer control over the representation - even if it introduces
inefficiencies.


> The biggest non-portability is in the ability (or lack thereof) to put
> extension components into "holes" in the parent. This is useful, but can
> be really hard to implement (it causes problems with the predefined "="
> operation, and I believe that there are other problems that I don't
> remember at the moment).
>
That starts sounding a bit extreme. The overwhelming bulk of the time, I'd
be trying to use rep-clauses because things are packed tightly together -
not overlapping things. Most typically for tagged records, you'd have a
class called "Message" that included message header info then followed by a
variety of message formats - very naturally expressed in OO Design. But if
you can't control representation, you can't make it work with what happens
on the wire. Short of the base class ending in the middle of a byte (never
seen that) and wanting the derived class to pick up in the middle of that
byte, I can't think of a case where I'd want derived class parts put into
holes in the base class. Maybe it happens, but I think you could probably
put on my tombstone "He never packed derived class data into holes in the
base class..." :-)

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: calenday (was Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <atv5fj$ldi$1@slb5.atl.mindspring.net>, "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> I'd suspect that declaring in the standard that all tags shall start at
> offset 0 and extend for 32 bits would not cause anyone any rework. I doubt
> it would come up often that the offset needed to be anything other than
> zero - I can't think of why I'd want it to or why I couldn't make things
> work somehow if it were always zero. Having a predefined constant for size
> and a mandated (dare I use that word?) starting point at the beginning of
> the record ought to be good enough.

It depends on whether there are external constraints on the record.
VMS kernel data structures, for instance, use the first 64 bits for
a doubly-linked list, the next 16 bits for length and the 16 bits
after that for a "type" (the closest thing to a constraint or tag).

Interoperation with other languages is crucial in this domain, unlike
all-Ada environments.

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Fine. Same deal with messages or other structures. Place them after the tag
(exactly represented) and load/store with an offset from the start of the
record. I suppose it might be a bit easier if the tag appears after
everything - but that just creates problems if you want to extend the
record. I can always do overlays or offsets or addresses or something
similar to get past the tag so long as I know exactly where it is and how
big it is.

Would you think the case you cited would be something that would need tagged
records or would it more appropriately be represented by a plain-vanilla
record? Where would you want to put the tag if not at offset 0?

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Larry Kilgallen <Kilgallen@SpamCop.net> wrote in message
news:FxwVAF3i62TM@eisner.encompasserve.org...
>
> It depends on whether there are external constraints on the record.
> VMS kernel data structures, for instance, use the first 64 bits for
> a doubly-linked list, the next 16 bits for length and the 16 bits
> after that for a "type" (the closest thing to a constraint or tag).
>
> Interoperation with other languages is crucial in this domain, unlike
> all-Ada environments.

Re: calenday (was Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <au22gl$hc5$1@slb0.atl.mindspring.net>, "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:
> Fine. Same deal with messages or other structures. Place them after the tag
> (exactly represented) and load/store with an offset from the start of the
> record. I suppose it might be a bit easier if the tag appears after
> everything - but that just creates problems if you want to extend the
> record. I can always do overlays or offsets or addresses or something
> similar to get past the tag so long as I know exactly where it is and how
> big it is.
> 
> Would you think the case you cited would be something that would need tagged
> records or would it more appropriately be represented by a plain-vanilla
> record? Where would you want to put the tag if not at offset 0?
> 
> MDC
> --
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jast.mil/
> 
> Send Replies To: m c o n d i c @ a c m . o r g
> 
>     "I'd trade it all for just a little more"
>         --  Charles Montgomery Burns, [4F10]
> ======================================================================
> 
> Larry Kilgallen <Kilgallen@SpamCop.net> wrote in message
> news:FxwVAF3i62TM@eisner.encompasserve.org...
>>
>> It depends on whether there are external constraints on the record.
>> VMS kernel data structures, for instance, use the first 64 bits for
>> a doubly-linked list, the next 16 bits for length and the 16 bits
>> after that for a "type" (the closest thing to a constraint or tag).
>>
>> Interoperation with other languages is crucial in this domain, unlike
>> all-Ada environments.

The allocation of these structures must start at the queue link
longwords, since they get allocated and deallocated by non-Ada
components.  I have dealt with this in Ada93 for ordinary variant
records, but it seems to me that tags have the same issue as
discriminants.  The start of the record is _not_ ok.

Randy's answer about leaving a hole seems the best I have read so far.

Re: calenday (was Re: IBM Acquires Rational Ada

[Hyman Rosen]

Marin David Condic wrote:
> I'd suspect that declaring in the standard that all tags shall start at
> offset 0 and extend for 32 bits would not cause anyone any rework.

Since the tag is often a pointer, forcing it to 32 bits
is highly inappropriate. Furthermore, it's possible that
teh layout for such objects is described by a platform
or compiler ABI that the Ada compiler needs to match.

The whole concept of representation specs on tagged
records seems pretty dodgy to me.

Re: calenday (was Re: IBM Acquires Rational Ada

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1040410199.497867@master.nyc.kbcfp.com...
> The whole concept of representation specs on tagged
> records seems pretty dodgy to me.

I agree. AFAIK, the only reason to use a representation clause is to make
sure that a type matches some external data layout. Tagged types, by their
very nature, do not fit into this category. This seems to be one of those
theoretical issues with no practical consequences.

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

Frank J. Lhota wrote in message ...
>"Hyman Rosen" <hyrosen@mail.com> wrote in message
>news:1040410199.497867@master.nyc.kbcfp.com...
>> The whole concept of representation specs on tagged
>> records seems pretty dodgy to me.
>
>I agree. AFAIK, the only reason to use a representation clause is to
make
>sure that a type matches some external data layout. Tagged types, by
their
>very nature, do not fit into this category. This seems to be one of
those
>theoretical issues with no practical consequences.


Not true. It's perfectly possible to use rep. clauses to insure storage
minimization better than the compiler's pragma Pack. (Usually, Pack
assumes some amount of efficiency is required.)

Also, it is perfectly possible to pass a tagged record to an external
data layout, if that layout includes a tag already (such as COM on
Microsoft machines), or if you are passing the object minus the tag to
the external system, but need type extension to define the external
format properly (that's what happened to use with bitmaps in Claw).

I agree this isn't likely to be a common use, but it has happened, and I
understand that Rational finds that they have customers which think
these capabilities are very important. It's best not to argue with
customers. :-)

              Randy.

Re: calenday (was Re: IBM Acquires Rational Ada

[AG]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:v072u4dmuc809f@corp.supernews.com...

> I agree this isn't likely to be a common use, but it has happened, and I
> understand that Rational finds that they have customers which think

Can you post a link pls? :))

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

AG wrote in message ...
>"Randy Brukardt" <randy@rrsoftware.com> wrote in message
>news:v072u4dmuc809f@corp.supernews.com...
>
>> I agree this isn't likely to be a common use, but it has happened,
and I
>> understand that Rational finds that they have customers which think
>
>Can you post a link pls? :))


It came up during an ARG meeting. I believe that the comment itself
appears in the minutes of that meeting, but I don't think that any
details were given. You'd have to ask Pascal Leroy to find out more.

                 Randy Brukardt.

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Not at all true. Many message protocols look very much like an Object
Oriented thing with a base class and many derived classes. It is extremely
natural to represent this as a tagged record. Not so much because you expect
to transmit the tag itself, but because you expect to process your messages
internally with all sorts of dispatching and inheretance and stuff like
that. It is extremely natural to do this in an OO way. What you need to do
though is to control the representation of everything that comes after the
tag. You look at your communication link and once you determine the
appropriate type of message, you're doing an overlay or unchecked conversion
or something similar to get the bytes into the tagged record and then go do
your dispatching from there.

The thing is, without the tagged record, you end up building your own
dispatching and inheritance and things like that anyway. (Big case
statements, similarly named procedures or procedures common to all message
types, etc.) You're either going to do it with a lot of bit-twiddling and
extra work or you can do it with tagged records very cleanly. If you've got
two Ada programs talking to each other and they're built by the same
compiler, representation can become a "don't care" issue - maybe. If its on
a more heterogeneous plane, you've got to be sure you control
representation. So I don't really think the issue is all that abstract or
theoretical - it does occur in the real world often enough and you'd just
like to take advantage of tagged records & representation to make it work
nicely.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Frank J. Lhota <NOSPAM.lhota.adarose@verizon.net> wrote in message
news:zuKM9.66886$4W1.13625@nwrddc02.gnilink.net...
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1040410199.497867@master.nyc.kbcfp.com...
> > The whole concept of representation specs on tagged
> > records seems pretty dodgy to me.
>
> I agree. AFAIK, the only reason to use a representation clause is to make
> sure that a type matches some external data layout. Tagged types, by their
> very nature, do not fit into this category. This seems to be one of those
> theoretical issues with no practical consequences.
>
>

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

Marin David Condic wrote in message ...
> I'd suspect that declaring in the standard that all tags shall start
at
> offset 0 and extend for 32 bits would not cause anyone any rework. I
doubt
> it would come up often that the offset needed to be anything other
than
> zero - I can't think of why I'd want it to or why I couldn't make
things
> work somehow if it were always zero. Having a predefined constant for
size
> and a mandated (dare I use that word?) starting point at the beginning
of
> the record ought to be good enough.

As noted elsewhere, Rational has at least one customer that wants to be
able to place tags, and both Janus/Ada and Rational Apex support
non-zero tag locations. Asking us to remove functionality (with the
possibility for incompatibilities) is not likely to be looked on kindly.

And, as also noted elsewhere, there are machines out there where a
pointer (and thus a tag) is not 32-bits. How would you suggest we
implement that rule on the U2200 with its 36-bit words (and pointers)??

>> The biggest non-portability is in the ability (or lack thereof) to
put
>> extension components into "holes" in the parent. This is useful, but
can
>> be really hard to implement (it causes problems with the predefined
"="
>> operation, and I believe that there are other problems that I don't
>> remember at the moment).
>>
>That starts sounding a bit extreme. The overwhelming bulk of the time,
I'd
>be trying to use rep-clauses because things are packed tightly
together -
>not overlapping things. Most typically for tagged records, you'd have a
>class called "Message" that included message header info then followed
by a
>variety of message formats - very naturally expressed in OO Design. But
if
>you can't control representation, you can't make it work with what
happens
>on the wire. Short of the base class ending in the middle of a byte
(never
>seen that) and wanting the derived class to pick up in the middle of
that
>byte, I can't think of a case where I'd want derived class parts put
into
>holes in the base class. Maybe it happens, but I think you could
probably
>put on my tombstone "He never packed derived class data into holes in
the
>base class..." :-)

Well, it comes up when you're trying to minimize storage of the types,
and the parent has unused bits. Consider:

     type Root_Type is tagged record
         Int : Some_Int_Subtype;
         Is_Valid : Boolean;
    end record;
    for Root_Type use record
        -- We assume the tag is at 0 and is 32 bits. A real rep. clause
would use a constant instead
        -- of assuming the tag size is 4 below.
        Int at 4 range 0 .. 15;
        Is_Valid at 6 range 0 .. 0;
    end record;

The bits 1 .. 7 in byte 6 are unused, as is byte 7. Now, look at the
extension:

     type Day is (Sunday, Monday, ....);

     type Day_Type is new Root_Type with record
            The_Day : Day;
     end record;
     for Day_Type use record
            -- The_Day at 6 range 1 .. 4; -- No extra space needed. But
fills a hole.
            The_Day at 7 range 0 .. 3; -- Extra byte needed.
            -- The_Day at 8 range 0 .. 3; -- Insisting on alignment
makes it worse. Probably a 4 extra
                                                             -- bytes
when allocated.
     end record;

And you waste even more space if some of the extension components need
alignment.

If there are going to be a lot of these (as there might if these are
used in compiler expression trees, for example), the wasted space can
turn into a lot of extra memory overhead (meaning longer compile times
in this example).

         Randy Brukardt.

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> Rants? Well, perhaps I have a bad habbit of typing with a "shrill" accent.
> :-)

No offense intended.  :-)

> Actually, I don't really care about portability. In my business, we'd seldom
> have to port something that was this machine-dependent. I'll accept a
> totally vendor/processor specific answer - as is usually a requirement when
> you've got to dip into rep clauses anyway.
> 
> And I wouldn't really characterize the need as relating to "weird" hardware.
> I've not usually found much problem, for example, getting a rep-clause to
> work to line up with some register word or other device. Usually, its a case
> of someone with a communication link packing things together as tightly as
> possible or from hardware substantially different from the thing doing the
> reading. You get odd-sized bit fields, things that span byte or word or
> longword boundaries, unusual numeric formats (1750a 48-bit float, for
> example?) and things of that nature. 

That's the sort of thing I meant: you're interfacing to something
(hardware or software protocols) that is "weird" from the point of view
of the computer hardware you're running on.  Sometimes the compiler
supports bit fields that are "natural" for *this* computer, but your
data is coming from a computer with a different word size, or different
natural alignments, etc.

>...You try to create a record that will
> deal with the data and you discover your compiler is going to whine and
> snivel about being asked to span things across unusual boundaries. The
> instant the possibility exists that you aren't going to be able to make one
> message in your catalog work with the compiler in hand, you're likely to
> head for an overall solution that *will* work in all cases - id est
> twiddling the bits by hand in some manner. You don't usually want to
> implement 90% of the messages as records with rep-clauses and then the
> remaining 10% as a byte array & access routines.

Yeah, that's a pain.  But so is doing all 100% the bit-twiddling way.
Sigh.

>...You'd end up building two
> totally different infrastructures and should one of your 90% ever change and
> the compiler refuse to help, you're rebuilding something dramatically.

Hahah!  So you *do* care about portability!  (To newer versions of the
same compiler, at least.)  In any case, I think the RM should tell you
which rep clauses are legal, rather than tripping over
implementation-dependent compiler error messages.  I think you agree
with that...
 
- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Robert A Duff wrote:
> "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:
...
>>And I wouldn't really characterize the need as relating to "weird" hardware.
>>I've not usually found much problem, for example, getting a rep-clause to
>>work to line up with some register word or other device. Usually, its a case
>>of someone with a communication link packing things together as tightly as
>>possible or from hardware substantially different from the thing doing the
>>reading. You get odd-sized bit fields, things that span byte or word or
>>longword boundaries, unusual numeric formats (1750a 48-bit float, for
>>example?) and things of that nature. 
> 
> That's the sort of thing I meant: you're interfacing to something
> (hardware or software protocols) that is "weird" from the point of view
> of the computer hardware you're running on.  Sometimes the compiler
> supports bit fields that are "natural" for *this* computer, but your
> data is coming from a computer with a different word size, or different
> natural alignments, etc.

Imagine trying to deal with 9-bit bytes as they had on the Honeywell
Level 66 machines (36 bit words) ;-)  No 9 bit bytes ever
made it to the Internet (due to its octet nature), but if you
had to create a hardware interface to such a beast, you may be in
a different situation ;-)

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

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

Warren W. Gay VE3WWG wrote in message <3E00C9AB.8040108@cogeco.ca>...
>Robert A Duff wrote:
>> "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:
>...
>>>And I wouldn't really characterize the need as relating to "weird"
hardware.
>>>I've not usually found much problem, for example, getting a
rep-clause to
>>>work to line up with some register word or other device. Usually, its
a case
>>>of someone with a communication link packing things together as
tightly as
>>>possible or from hardware substantially different from the thing
doing the
>>>reading. You get odd-sized bit fields, things that span byte or word
or
>>>longword boundaries, unusual numeric formats (1750a 48-bit float, for
>>>example?) and things of that nature.
>>
>> That's the sort of thing I meant: you're interfacing to something
>> (hardware or software protocols) that is "weird" from the point of
view
>> of the computer hardware you're running on.  Sometimes the compiler
>> supports bit fields that are "natural" for *this* computer, but your
>> data is coming from a computer with a different word size, or
different
>> natural alignments, etc.
>
>Imagine trying to deal with 9-bit bytes as they had on the Honeywell
>Level 66 machines (36 bit words) ;-)  No 9 bit bytes ever
>made it to the Internet (due to its octet nature), but if you
>had to create a hardware interface to such a beast, you may be in
>a different situation ;-)


We had to write a cross-compiler to such a machine (the U2200). That was
interesting. :-) (Especially handling 36-bit constants on the 32-bit
machine.) It's one reason why I am not enthusastic about trying to set
strong rules for rep. clauses -- because they vary so much on different
hardware.

         Randy Brukardt.

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

Robert A Duff wrote in message ...
>"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:
>>...You'd end up building two
>> totally different infrastructures and should one of your 90% ever
change and
>> the compiler refuse to help, you're rebuilding something
dramatically.
>
>Hahah!  So you *do* care about portability!  (To newer versions of the
>same compiler, at least.)  In any case, I think the RM should tell you
>which rep clauses are legal, rather than tripping over
>implementation-dependent compiler error messages.  I think you agree
>with that...


OK, so why did you refuse to work further on the AIs defining this. :-)
:-)

In fairness to Bob, the ARG struggled with these issues (the
"recommended level of support") for years. But a consensus on the
answers could never be reached. Part of the problem has been that new
members tend to vote against the solutions proposed. They have to be
personally talked into the solution. But that, to me, indicates the
rules are too complex -- nothing should require a personal chat with the
designers before it can be agreed to.

So while I tend to agree with Bob that the RM should tell you, I
disagree with him on WHAT it should tell you. And I suspect that that
will never change, as there are as at least as many correct answers as
there are targets and compiler implementors.

                Randy.

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> OK, so why did you refuse to work further on the AIs defining this. :-)
> :-)

;-)

> In fairness to Bob, the ARG struggled with these issues (the
> "recommended level of support") for years. But a consensus on the
> answers could never be reached.

In my earlier posting, I said that if I were designing a language from
scratch I would do all these glorious portable things.  In the context
of Ada, it is probably neither possible nor desirable, given the history
-- existing language rules, existing compiler implementations, existing
Ada code.

- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message
news:wcc4r9b40ka.fsf@shell01.TheWorld.com...
>
> Hahah!  So you *do* care about portability!  (To newer versions of the
> same compiler, at least.)  In any case, I think the RM should tell you
> which rep clauses are legal, rather than tripping over
> implementation-dependent compiler error messages.  I think you agree
> with that...
>
Nahhh. There comes a point in some really serious embedded projects where
you freeze the version of the compiler because you can't invalidate all your
verification effort by switching to a new one. Its more like the case where
some bozo at the other end of the hose says "You know that message we used
to agree was going to look like this? I've got a problem at this end which
means I've got to change it to look like that....." and now the message you
used to have coaxed the compiler into accepting needs to be redone as the
bit-twiddling variety. Better to pick an answer that is going to work 100%
of the time than get stuck with major rework later.

Now all other things being equal, I'd rather have 100% portability and 100%
guarantees about what *must* work on all compilers rather than dealing with
two compilers dancing to the beat of their own drummers. It would be nice to
have rep clauses that gave you 100% of everything you ever asked for in a
record layout. If I can't have any of the above, I'll settle for
implementation dependent behavior that gets me the layouts I want. (Like I
said, for a given project, you often know you're never going to change
compilers - and if you did, you'd have much bigger fish to fry than settling
out a few rep clauses.)

If none of that is practical, then lets go invent some new kind of data
structure similar to a record that is used strictly for pulling the bits
apart in an arbitrary byte stream.  Usually, when you're dealing with this,
you're pulling data together from a variety of places where it is used
computationally and packing it up to ship it off somewhere, so all you care
about is packing and unpacking it. Since I (with my limited intellect) can
figure out how to write a bunch of procedures and functions with hard-coded
bit/byte positions in them to pick apart what I want from a byte array, I'd
think the compiler could do the same and give me a little help getting the
job done. If that requires some special pragmas or modified data structure
with different rules, I can live with that.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: calenday (was Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <3E01BA24.7648FEC2@konad.de>, Frank Piron <frank.piron@konad.de> writes:

> The C - Programmer works for performance and nowaday for
> nothing but performance.

I believe that would be "apparent performance from the source viewpoint"
ignoring the importance of compiler optimization.

Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <atcju3$svh$1@slb5.atl.mindspring.net>, "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> Also, if I were doing it, I wouldn't make bindings. I think that just ends u
> p in the "Me Too!!!" category and makes your stuff dependent on what happens
> in another language - also requiring you to haul around another compiler. If
> you wanted a curses package, it would be better (and not that big a deal) to
> implement it from the ground up in Ada and give it an Ada flavor while
> you're at it. You could probably even dramatically improve it beyond just
> cursor positioning and the like - give it more of a GUI feel (DEC had
> something like this - pasteboards, windows, etc, all out of VT220's.)

It is called SMG, and the entrypoints and features might make a useful
design input for an Ada-style equivalent.  Calling SMG from Ada works
fine (on VMS) but it doesn't flow naturally.

Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <3DFA1BB8.1050303@cogeco.ca>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> I am very aware that text "fails to impress" people these days, but when
> you own the company, you don't necessarily care that those under you
> are stuck using cheap dumb terminals (especially if clients never get
> tours for impressions). There are still a large number of warehouse
> (and similar) situations, where they are quite content to use dumb
> terminals. They're cheap, never need software upgrades, don't get
> viruses, can't pass viruses onto the LAN etc. They also don't need
> Microsoft licenses/extortion to keep them going.

They also don't run Solitare or Mine Sweeper.

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Larry Kilgallen wrote:
> In article <3DFA1BB8.1050303@cogeco.ca>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> 
>>I am very aware that text "fails to impress" people these days, but when
>>you own the company, you don't necessarily care that those under you
>>are stuck using cheap dumb terminals (especially if clients never get
>>tours for impressions). There are still a large number of warehouse
>>(and similar) situations, where they are quite content to use dumb
>>terminals. They're cheap, never need software upgrades, don't get
>>viruses, can't pass viruses onto the LAN etc. They also don't need
>>Microsoft licenses/extortion to keep them going.
> 
> They also don't run Solitare or Mine Sweeper.

Well, Mine Sweeper is close to the reliability
experience that Windows software gives you
anyway -- so how can you tell the difference ;-)

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

Re: IBM Acquires Rational Ada

[Marin David Condic]

I have nothing against character-cell terminals & applications. I think they
have a number of advantages such as those outlined here and elsewhere. The
problem is that if one is looking to build a library of useful things for a
language to offer developers that might help generate interest in the
language, I just don't see that as a thing that should be at all at the top
of the list. The idea ought to be to look at what changes in the industry
are likely to need support 5 to 10 years from now and get out in front of
that rather than look backwards and try to support development for old
hardware. It might be useful and I wouldn't object to its existence, but I'd
think other things ought to come first.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Larry Kilgallen <Kilgallen@SpamCop.net> wrote in message
news:uaDr7xp1zlGD@eisner.encompasserve.org...
> In article <3DFA1BB8.1050303@cogeco.ca>, "Warren W. Gay VE3WWG"
<ve3wwg@cogeco.ca> writes:
>
> > I am very aware that text "fails to impress" people these days, but when
> > you own the company, you don't necessarily care that those under you
> > are stuck using cheap dumb terminals (especially if clients never get
> > tours for impressions). There are still a large number of warehouse
> > (and similar) situations, where they are quite content to use dumb
> > terminals. They're cheap, never need software upgrades, don't get
> > viruses, can't pass viruses onto the LAN etc. They also don't need
> > Microsoft licenses/extortion to keep them going.
>
> They also don't run Solitare or Mine Sweeper.

Re: IBM Acquires Rational Ada

[tmoran]

> The idea ought to be to look at what changes in the industry are likely to
> need support 5 to 10 years from now and get out in front of that rather
> than look backwards and try to support development for old
  Guessing at some likely changes, I'm adding easier high level
http and ftp, and audio and video support to Claw.  Do you happen to
know better what's coming? ;)

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> I have nothing against character-cell terminals & applications. I think they
> have a number of advantages such as those outlined here and elsewhere. The
> problem is that if one is looking to build a library of useful things for a
> language to offer developers that might help generate interest in the
> language, I just don't see that as a thing that should be at all at the top
> of the list. The idea ought to be to look at what changes in the industry
> are likely to need support 5 to 10 years from now and get out in front of
> that rather than look backwards and try to support development for old
> hardware. It might be useful and I wouldn't object to its existence, but I'd
> think other things ought to come first.
> 
> MDC

I don't entirely disagree with you here, but disagree on one point.

If you fail to support "essential" levels of library support,
then you will have some factors working against you.

For example, if you have
the greatest GUI support, but cannot satisfy the console support,
and console support is needed (at least some of the time)
then the greatness of the GUI support becomes somewhat irrelevant.

As an application developer who must at times
support curses type interfaces (like for console applications), if you
cannot provide this basic support for that environment, people
may look elsewhere for better overall support.  Even if they don't
plan to make extensive use of it.

Considering that text based support is rather basic, it
would seem a shame IMHO to omit this, only because it is not the
most common practice at the present time.

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

Re: IBM Acquires Rational Ada

[Ed Cogburn]

Warren W. Gay VE3WWG wrote:
> Marin David Condic wrote:
> 
>> I have nothing against character-cell terminals & applications. I 
>> think they
>> have a number of advantages such as those outlined here and elsewhere. 
>> The
>> problem is that if one is looking to build a library of useful things 
>> for a
>> language to offer developers that might help generate interest in the
>> language, I just don't see that as a thing that should be at all at 
>> the top
>> of the list. The idea ought to be to look at what changes in the industry
>> are likely to need support 5 to 10 years from now and get out in front of
>> that rather than look backwards and try to support development for old
>> hardware. It might be useful and I wouldn't object to its existence, 
>> but I'd
>> think other things ought to come first.
>>
>> MDC
> 
> 
> I don't entirely disagree with you here, but disagree on one point.
> 
> If you fail to support "essential" levels of library support,
> then you will have some factors working against you.
> 
> For example, if you have
> the greatest GUI support, but cannot satisfy the console support,
> and console support is needed (at least some of the time)
> then the greatness of the GUI support becomes somewhat irrelevant.
> 
> As an application developer who must at times
> support curses type interfaces (like for console applications), if you
> cannot provide this basic support for that environment, people
> may look elsewhere for better overall support.  Even if they don't
> plan to make extensive use of it.
> 
> Considering that text based support is rather basic, it
> would seem a shame IMHO to omit this, only because it is not the
> most common practice at the present time.


Agreed, and consider that many people, at least on Unix, are using X11 based 
GUIs but are still running console apps in terminal emulators like xterm. 
There are still programs that do not need graphics, just as the other person 
is arguing about text mode apps, I can make the same argument about there 
being a class of apps that need more dynamic, sophisticated support for 
console I/O but still don't need a GUI.  Plenty such programs exist and are 
being used, and more are being produced, despite the apparent "success" of the 
GUI.  Building a GUI without support for current and *future* console apps 
would be a lack of foresight.

Re: IBM Acquires Rational Ada

[Hyman Rosen]

Marin David Condic wrote:
 > I think that this "Ada Mentality" is in some way blinding

You know, no one loves C and C++ more than I do, but I
don't think I would be any slower coding in Ada than in
either of the above languages (once I got a good working
knowledge of the language, of course). I think it's a
fallacy cherished by Ada programmers that C or C++ will
just accept any garbage, and therefore code can just be
churned out in those languages.

Re: IBM Acquires Rational Ada

[Wes Groleau]

> fallacy cherished by Ada programmers that C or C++ will
> just accept any garbage, and therefore code can just be

Those of us who have programmed in both languages
know that "just accept any garbage" is an exaggeration.

But "accept a heck of a lot more garbage
than Ada will accept" is a fact.

Re: IBM Acquires Rational Ada

[steve_H]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1039618741.173427@master.nyc.kbcfp.com>...
 
> I think it's a
> fallacy cherished by Ada programmers that C or C++ will
> just accept any garbage, and therefore code can just be
> churned out in those languages.

Oh but it does accept any garbage.

Are you say that C will not accept this code

-----------------------
main(){
long j=999999999;
short i;

i=j;
}
----------------

??

Ok, lets find out:

$ cat foo.c
main(){
long j=999999999;
short i;
i=j;
}

$ gcc foo.c -o foo
$ ./foo
 
it worked!! It compiled with no erros, and ran with no errors.

I wonder how the compiler managed to stuff 999,999,999 into a short
variable? special packing algorithm must be :)

If the above is not garbage, then what do you call it? Brilliancy?

And on top of them, people will actually choose C and C++ for numerical
computation instead of Ada.

Re: IBM Acquires Rational Ada

[Hyman Rosen]

C and C++ freely interconvert the fundamental arithmetic
types. If you would like to construe that as accepting
garbage, you are free to do so. I don't find it a very
compelling argument.

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Here's another one ;-)

main(){
   short i = -32768;
   short j;

   j = -i;
}

The results are implementation specific (although
that may have changed with C99 -- I stopped
caring after I got into Ada ;-)  I have seen
j=0 in my travels, but don't count on it.

Warren.

steve_H wrote:
> Hyman Rosen <hyrosen@mail.com> wrote in message news:<1039618741.173427@master.nyc.kbcfp.com>...
>  
> 
>>I think it's a
>>fallacy cherished by Ada programmers that C or C++ will
>>just accept any garbage, and therefore code can just be
>>churned out in those languages.
> 
> 
> Oh but it does accept any garbage.
> 
> Are you say that C will not accept this code
> 
> -----------------------
> main(){
> long j=999999999;
> short i;
> 
> i=j;
> }
> ----------------
> 
> ??
> 
> Ok, lets find out:
> 
> $ cat foo.c
> main(){
> long j=999999999;
> short i;
> i=j;
> }
> 
> $ gcc foo.c -o foo
> $ ./foo
>  
> it worked!! It compiled with no erros, and ran with no errors.
> 
> I wonder how the compiler managed to stuff 999,999,999 into a short
> variable? special packing algorithm must be :)
> 
> If the above is not garbage, then what do you call it? Brilliancy?
> 
> And on top of them, people will actually choose C and C++ for numerical
> computation instead of Ada.

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

Re: IBM Acquires Rational Ada

[David Thompson]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote :
> Here's another one ;-)
>
> main(){
>    short i = -32768;
>    short j;
>
>    j = -i;
> }
>
> The results are implementation specific (although
> that may have changed with C99 -- I stopped
> caring after I got into Ada ;-)  I have seen
> j=0 in my travels, but don't count on it.
>
Well, in C99 your example as written is illegal, because
"implicit int" function return type, or variable type, is gone;
also, since you neither return'ed from main() or exit()'ed
in C89 the program exit status was undefined but in C99
it is now zero = successful as a special feature^Wkludge.
Not to mention that your entire body is all dead code
that any decent optimizer can completely eliminate.

But those are irrelevant to your point.

The minimum ranges of integer types are unchanged,
except for the addition of new long long types (signed
and unsigned) of at least 64 bits; signed short, and for
that matter int, still need not handle +/-32768, although
two's-complement implementations, the overwhelming majority,
IME always do support -32768 (but not +32768 in 16 bits).

Overflow in any signed integer computation was and is
Undefined Behavior, which means anything at all is
permitted, including but not limited to any value produced
or any signal.  And that initializer is really an expression:
-(unary negate) 32768(positive int or long literal).  Even
though it may well (and should) be evaluated at compile
time, its defined semantics are as for runtime.
But the initializer can't overflow because if 32768 is
representable in int then -32768 is also, and if not
it is evaluated as and must be representable in long.

For the initializer value either way, and the computation
of -i as signed int (due to the integer promotions) if it
does not overflow, the narrowing by assignment (or cast, or
at least scalar initialization) of signed integer types is still
implementation-defined but is now allowed to "raise ...
an I-D signal" instead of producing an I-D result (value).
I-D does mean that the implementation must *document*
what it does, FWTW.  And I've heard of no implementation
that raises a signal here; I'm not sure why the committee
added this new option.  The most recent Rationale draft
I've looked at says nothing on this point.

--
- David.Thompson 1 now at worldnet.att.net

Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <1039642856.867910@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> C and C++ freely interconvert the fundamental arithmetic
> types. If you would like to construe that as accepting
> garbage, you are free to do so. I don't find it a very
> compelling argument.

Whether one construes that as accepting garbage depends on one's
attitude toward computing, and potentially one's problem domain.

Re: IBM Acquires Rational Ada

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <1039642856.867910@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> > C and C++ freely interconvert the fundamental arithmetic
> > types. If you would like to construe that as accepting
> > garbage, you are free to do so. I don't find it a very
> > compelling argument.
> 
> Whether one construes that as accepting garbage depends on one's
> attitude toward computing, and potentially one's problem domain.

Heh?  In what problem domain is it beneficial to have *implicit* type
conversions that lose information?

- Bob

Re: IBM Acquires Rational Ada

[Hyman Rosen]

Robert A Duff wrote:
> Heh?  In what problem domain is it beneficial to have *implicit* type
> conversions that lose information?

It's not particularly beneficial, and if the language was
being designed today, those implicit conversions would most
likely not be included. But C had them, now a very long time
ago, and C++ had to follow suit because C compatibility was
an important goal.

I'm sure the original argument was for conciseness of
expression, something along these lines -

     void utoa(unsigned u, char *a)
     {
         char buf[30], *p = buf;
         do *p++ = u % 10 + '0'; while (u /= 10);
         do *a++ = *--p; while (p > buf);
         *a = 0;
     }

There are various expressions mixing integers and
characters, and assignments of integers to characters.

Re: IBM Acquires Rational Ada

[Fraser Wilson]

Hyman Rosen <hyrosen@mail.com> writes:

> I'm sure the original argument was for conciseness of
> expression, something along these lines -

[ utoa function deleted ]

Not quite as concise as Integer'Image (X)!

:)

Fraser.

Re: IBM Acquires Rational Ada

[Hyman Rosen]

Fraser Wilson wrote:
> Not quite as concise as Integer'Image (X)!

Or sprintf(buf, "%u", u), for that matter.
The code was illustrative of the kind of manipulation
that C was intended to facilitate. Not getting in the
way of the programmer was a major design goal.

Re: IBM Acquires Rational Ada

[Wes Groleau]

> that C was intended to facilitate. Not getting in the
> way of the programmer was a major design goal.

A valid goal under certain circumstances.
As long as you realize it also means not
getting between the gun and the foot.

Re: IBM Acquires Rational Ada

[Programmer Dude]

Wes Groleau wrote:

>> that C was intended to facilitate. Not getting in the
>> way of the programmer was a major design goal.
> 
> A valid goal under certain circumstances.
> As long as you realize it also means not
> getting between the gun and the foot.

More like, you need to be very careful where you point the gun.  ;-)

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|



Opinions expressed here are my own and may not represent those of my employer.

Re: IBM Acquires Rational Ada

[John R. Strohm]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1039717990.240969@master.nyc.kbcfp.com...
> Fraser Wilson wrote:
> > Not quite as concise as Integer'Image (X)!
>
> Or sprintf(buf, "%u", u), for that matter.
> The code was illustrative of the kind of manipulation
> that C was intended to facilitate. Not getting in the
> way of the programmer was a major design goal.

Sorry.  That is a popular misconception.

C was intended to be a high-level assembler for the PDP-11, that would be
easy to translate into concise machine code.  That is where the ++ and --
operators originally came from.  Specifically, Kernighan and Ritchie wanted
to be able to use the indirect predecrement and indirect postincrement
addressing modes of the PDP-11, which C expresses as *--var and *var++, so
they hardwired them into the language.

Yes, the language did have to stay out of the programmer's way, but that was
not an explicit design goal.

Experience since then has shown, conclusively, that "staying out of the way
of the programmer" is not necessarily a good idea.  C takes the philosophy
that, because 0.01% of the time the programmer is correct in wanting to do
something, the language should allow him to do it easily 100% of the time,
EVEN THOUGH IT IS A HORRIBLE MISTAKE 99.99% of the time.  Ada, on the other
hand, takes the attitude that it should be ugly as hell to do that thing, so
that 99.99% of the time the programmer won't do it, and, on that 0.01% where
he really means it, he has to work for it and everyone reading the code
three years later knows he is doing something unusual.

Unusual things, with interesting, subtle effects, should advertise
themselves to novice programmers.  It is like the notation on the old maps,
"Here Be Tygers".

Re: IBM Acquires Rational Ada

[Hyman Rosen]

John R. Strohm wrote:

> Sorry.  That is a popular misconception.
>
> C was intended to be a high-level assembler for the PDP-11, that would be
> easy to translate into concise machine code.  That is where the ++ and --
> operators originally came from.  Specifically, Kernighan and Ritchie wanted
> to be able to use the indirect predecrement and indirect postincrement
> addressing modes of the PDP-11, which C expresses as *--var and *var++, so
> they hardwired them into the language.


No. According to Ritchie, in <http://cm.bell-labs.com/cm/cs/who/dmr/chist.html>:

     Thompson went a step further by inventing the ++ and -- operators,
     which increment or decrement; their prefix or postfix position
     determines whether the alteration occurs before or after noting
     the value of the operand. They were not in the earliest versions
     of B, but appeared along the way. People often guess that they were
     created to use the auto-increment and auto-decrement address modes
     provided by the DEC PDP-11 on which C and Unix first became popular.
     This is historically impossible, since there was no PDP-11 when B
     was developed. The PDP-7, however, did have a few `auto-increment'
     memory cells, with the property that an indirect memory reference
     through them incremented the cell. This feature probably suggested
     such operators to Thompson; the generalization to make them both
     prefix and postfix was his own. Indeed, the auto-increment cells
     were not used directly in implementation of the operators, and a
     stronger motivation for the innovation was probably his observation
     that the translation of ++x was smaller than that of x=x+1.

Re: IBM Acquires Rational Ada

[John English]

Robert A Duff wrote:
> 
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> 
> > In article <1039642856.867910@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> > > C and C++ freely interconvert the fundamental arithmetic
> > > types. If you would like to construe that as accepting
> > > garbage, you are free to do so. I don't find it a very
> > > compelling argument.
> >
> > Whether one construes that as accepting garbage depends on one's
> > attitude toward computing, and potentially one's problem domain.
> 
> Heh?  In what problem domain is it beneficial to have *implicit* type
> conversions that lose information?

The domain of "keeping programmers in jobs, fixing their bugs" :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: IBM Acquires Rational Ada

[Zaphod]

Consider now the ramifications of Rational's potential acquisition by
Microsoft. Given the long-standing and rather tight relationship between
these two companies -- and the role played by Rational technology in
Microsoft's Visual * product line -- I don't believe this rumor is without
basis. The risk to Ada in the IBM acquisition scenario pales in comparison.

Who will start the bidding?

Re: IBM Acquires Rational Ada

[Marin David Condic]

The metrics I've collected in the past didn't have anything to do with how
fast someone could code-up some routine. In that respect, Ada probably
wouldn't have any advantage over C or C++ - possibly even a disadvantage.
What my metrics demonstrated was that when the whole development cycle was
complete (requirements through formal testing) using Ada meant a reduction
in man-hours spent (by about 50%) and a reduction in bugs found (by a factor
of 4). My study was not alone. There was also the famous Ada/Model-Railroad
study that demonstrated an impressive improvement in productivity and
reduction in errors in a similar environment. (realtime controls)

I wouldn't claim that you couldn't code just as fast - or even faster than I
can code, given our favorite languages. I'll even go so far as to say that
you'd be in that "Any Competent C Programmer" category who never makes
stupid mistakes in coding that cost untold hours down the line in debugging.
But given a random selection of developers with varying levels of skills and
the need to work together on a large development project, you've got a
different animal on your hands. In that situation, there is data to indicate
that when other factors are equal, (id est, nobody gets huge libraries of
utilities or other leverage) Ada is more productive and results in fewer
errors over the development cycle.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Hyman Rosen <hyrosen@mail.com> wrote in message
news:1039618741.173427@master.nyc.kbcfp.com...
> Marin David Condic wrote:
>  > I think that this "Ada Mentality" is in some way blinding
>
> You know, no one loves C and C++ more than I do, but I
> don't think I would be any slower coding in Ada than in
> either of the above languages (once I got a good working
> knowledge of the language, of course). I think it's a
> fallacy cherished by Ada programmers that C or C++ will
> just accept any garbage, and therefore code can just be
> churned out in those languages.
>

Re: IBM Acquires Rational Ada

[tmoran]

> While I'm all in favor of Ada catching errors up front and I accept that
> this means programmers need a mental shift from C to avoid frustration,
  It's the wrong view that with Ada you must fight with the compiler up
front, while while with C your fights are delayed till after compilation.
Perhaps Ada compilers should come in two parts:  a checker/analyzer, and a
code generator.  View the checker as a handy tool to get rid of the
obvious errors before you even bother compiling to code.  Is your program
as important as, say, a progress report to your boss?  Would you use a
spell checker before sending the latter?  Or is a spell checker just a
useless annoyance?

> but a *good* one that hits the shelves 6 months after the competitors
> package does is worthless.
  That's a popular myth.  Pioneers get arrows, settlers get land.  How
long did Visicalc last after Lotus came out?  I helped with the first
WYSIWYG publishing program on the PC, and it was only a very few years
before it ate the dust of much better ones.  Or consider the fate of
Apple's Newton, which preceded Palm.  Who got rich off the WIMP interface?
Not Xerox, not Apple, but Microsoft.

Re: IBM Acquires Rational Ada

[Jeffrey Carter]

Marin David Condic wrote:
> 
> While I'm all in favor of Ada catching errors up front and I accept that
> this means programmers need a mental shift from C to avoid frustration, I
> think that this "Ada Mentality" is in some way blinding the community to
> what the ultimate customer wants and needs. We keep thinking "Take your time
> and get it right. It'll pay in the long run". This may be true and the
> customer will be glad he's got that one day, but what would be far more
> compelling in making the sale is "This will get you to market faster!" If
> the Ada community started focusing in on developmental leverage that got
> someone to market quicker, that would be a quality they wouldn't (and
> couldn't!) ignore.

But where we have real data (Rational's metrics on Ada compiler 
development in C and Ada), Ada was faster to completion as well as 
having fewer errors which were easier to correct.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger

Re: IBM Acquires Rational Ada

[Marin David Condic]

I understand. I've collected similar data. I've seen other studies
indicating the same thing. But all of these studies (of necessity) have the
built-in caveat "All Other Things Being Equal". Someone who comes in the
door with a truckload of libraries and development tools and natural
bindings to the OS and other people's libraries and all that other stuff,
simply isn't playing fair. :-) They've moved their ball a hundred yards
closer to the pin while Ada has to tee off from the usual line. So what if
Ada could develop all those libraries, tools, bindings, etc. and ultimately
do a better job? The problem is they aren't there now and the project starts
today. The guy who bought the cheesy, buggy, C++ compiler that came with the
GUI wizard and magical debugger and the half-million lines of class-library
code got his project out the door 6 months ahead of you because you're still
building the interface bindings to the OS.

I'm sympathetic to the notion that Ada actually is faster for development
and I believe it because I've measured the results myself. However, there
really is no getting around that "All Other Things Being Equal" caveat and
right now the other guys are cheating while the Ada community can't even
find a way to create a standard class library without a ten year language
revision cycle. Is it any wonder that developers choose C++ or Java?

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Jeffrey Carter <jrcarter@acm.org> wrote in message
news:3DF7901C.3000006@acm.org...
>
> But where we have real data (Rational's metrics on Ada compiler
> development in C and Ada), Ada was faster to completion as well as
> having fewer errors which were easier to correct.
>

Re: IBM Acquires Rational Ada

[Hyman Rosen]

Marin David Condic wrote:
> The guy who bought the cheesy, buggy, C++ compiler that came with the
> GUI wizard and magical debugger and the half-million lines of class-library
> code got his project out the door 6 months ahead of you because you're still
> building the interface bindings to the OS.

Here's what Scott Meyers has to say in his preface to _Effective STL_:
<http://www.awprofessional.com/catalog/product.asp?product_id={AA4735AF-4407-4011-B7D3-0C924DFA675D}&selectDescTypeId={0BBA7A1C-E080-49A0-B103-E1BE9F7C7092}&st={75A0BC87-B9B4-435A-86E0-36F0AC8E0923}&session_id={4C1AEA22-4C0C-4D62-8DB2-5552A4AFA3C9}>

     Then I began to notice something that took me by surprise. Despite
     the portability problems, despite the dismal documentation, despite
     the compiler diagnostics resembling transmission line noise, many
     of my consulting clients were using the STL anyway. Furthermore,
     they weren't just playing with it, they were using it in production
     code! That was a revelation. I knew that the STL featured an elegant
     design, but any library where programmers are willing to endure
     portability headaches, poor documentation, and incomprehensible error
     messages has a lot more going for it than just good design. For an
     increasingly large number of professional programmers, I realized,
     even a bad implementation of the STL was preferable to no implementation
     at all.

Re: IBM Acquires Rational Ada

[Marin David Condic]

Exactly, 100% the point. Ada seems to be so busy coming up with a "perfect"
answer that it misses the point - even a bad answer is better than *no*
answer. If the Ada community was willing to gather under the auspices of
SIGAda or some other organ and declare that some library of containers
(existing, or to be developed) was "The Conventional Answer" and started
delivering Ada with it, then Ada would have containers by now and not be
lagging behind C++ in that respect. Regularly working on that library to
extend and enhance it would bring Ada ahead of C++ in that regard. The fact
that the best we seem to be able to do with respect to libraries is to raise
the issue as an "Ada0x" standards issue is symptomatic of why Ada has a
problem catching on with the masses. A useful, leverage building capability
is going to take *years* to get in place and even then will probably only
address some small fraction of the needs based on least-common-denominator
factors. Why can't we find a mechanism to get things like this into
"Conventional Ada" more quickly?

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Hyman Rosen <hyrosen@mail.com> wrote in message
news:1039712678.466533@master.nyc.kbcfp.com...
>
> Here's what Scott Meyers has to say in his preface to _Effective STL_:
>
<http://www.awprofessional.com/catalog/product.asp?product_id={AA4735AF-4407
-4011-B7D3-0C924DFA675D}&selectDescTypeId={0BBA7A1C-E080-49A0-B103-E1BE9F7C7
092}&st={75A0BC87-B9B4-435A-86E0-36F0AC8E0923}&session_id={4C1AEA22-4C0C-4D6
2-8DB2-5552A4AFA3C9}>
>
>      Then I began to notice something that took me by surprise. Despite
>      the portability problems, despite the dismal documentation, despite
>      the compiler diagnostics resembling transmission line noise, many
>      of my consulting clients were using the STL anyway. Furthermore,
>      they weren't just playing with it, they were using it in production
>      code! That was a revelation. I knew that the STL featured an elegant
>      design, but any library where programmers are willing to endure
>      portability headaches, poor documentation, and incomprehensible error
>      messages has a lot more going for it than just good design. For an
>      increasingly large number of professional programmers, I realized,
>      even a bad implementation of the STL was preferable to no
implementation
>      at all.
>

Re: IBM Acquires Rational Ada

[Peter Amey]

Marin David Condic wrote:
> 
> Exactly, 100% the point. Ada seems to be so busy coming up with a "perfect"
> answer that it misses the point - even a bad answer is better than *no*
> answer. 

Not if the application is life-critical (or even business critical).


[snip]

Peter

Re: IBM Acquires Rational Ada

[Marin David Condic]

Peter Amey <peter.amey@praxis-cs.co.uk> wrote in message
news:3DF9A5B3.3CC0E2A3@praxis-cs.co.uk...
>
>
> Marin David Condic wrote:
> >
> > Exactly, 100% the point. Ada seems to be so busy coming up with a
"perfect"
> > answer that it misses the point - even a bad answer is better than *no*
> > answer.
>
> Not if the application is life-critical (or even business critical).
>
>
Not necessarily true. In fact, its done all the time. People write
life-critical or business-critical or anything-else-critical applications in
weak languages with shoddy libraries all the time. It just *costs* more to
do it! I could use some crappy library of buggy containers in a life
critical app if I a) test carefully and avoid the things that kill it and/or
b) patch the library myself until it works right. Both of which probably
will take less time than building the library from bottom-dead-center.

Granted, all other things being equal, I'd rather have a good, solid,
rigorously standardized, thoroughly tested Ada library to work with. But if
I've got hardware coming in 3 months and you're perfect Ada library is going
to be delivered in 2005 with the next ARM, my choices are these: Write my
own or use some piece of crap that someone else built in C. Hardware is here
in 3 months? Damn! I think I'll go with the piece of crap in C and hope I
can patch it together well enough to do the job. Chances are, I can make
that work and it got me the leverage I needed to get my job done by the time
the hardware arrives.

So if the Ada mentality is going to remain "We won't build a library until
it can be released in the ARM and implemented on every processor ever
designed and thoroughly run through the wringer so that it is 100% provable
to be safe and reliable...." then I guess Ada can just keep on giving up
development jobs to C, C++ and Java.

Don't get me wrong. I don't advocate "Lets go build really crappy libraries
so we can be just like C/C++ with lots of core dumps because then everybody
will love us..." I'm suggesting that coming up with a library that is
maintained less formally than the Ada standard and released more frequently
than the Ada standard is likely to a) produce something that is probably not
going to be as rigorously defined and validated as the ARM would be and b)
so what? it got there and is doing the job.


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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: IBM Acquires Rational Ada

[Robert Spooner]

Marin David Condic wrote:
> So if the Ada mentality is going to remain "We won't build a library until
> it can be released in the ARM and implemented on every processor ever
> designed and thoroughly run through the wringer so that it is 100% provable
> to be safe and reliable...." then I guess Ada can just keep on giving up
> development jobs to C, C++ and Java.
> 
This is a good point.  From my vantage point, one of the big mistakes
Digital Equipment Corp. (remember them?) made with their version of UNIX 
was
that they didn't release it until if was up to (or at least close to) 
their reliability standards.  That put them in a bad competitive 
position, and we all know what happened subsequently.  I'm not saying 
the demise of DEC was solely due to that, but I think it was a 
contributing factor.

Bob
-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

Re: IBM Acquires Rational Ada

[Marin David Condic]

Part of it was that they refused for *years* to do anything about Unix and
only started heading in that direction when it appeared that they might sink
unless they did. They wanted to keep pushing VMS - which might have been a
good thing, but they also weren't willing to take the steps necessary to
make VMS "The Operating System" (such as make it executable on more than a
VAX or Alpha platform and license it easily to the rest of the world. Sort
of the Apple "I want the whole pie" strategy to achieve business demise.)

But it is a perfect example of getting to the market too late. Others had
established dominance in the Unix field and DEC was just there with too
little too late. Ada is free to make exactly the same mistake. "Gee.
Everyone is jumping on C++ and the STL and the Java class libraries and
other large libraries of stuff. Maybe we should try to get containers into
the standard five years from now....." Sounds to me like a recepie for too
little too late.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Robert Spooner <rls19@psu.edu> wrote in message
news:3DFA00D5.9010307@psu.edu...
> >
> This is a good point.  From my vantage point, one of the big mistakes
> Digital Equipment Corp. (remember them?) made with their version of UNIX
> was
> that they didn't release it until if was up to (or at least close to)
> their reliability standards.  That put them in a bad competitive
> position, and we all know what happened subsequently.  I'm not saying
> the demise of DEC was solely due to that, but I think it was a
> contributing factor.
>

Re: IBM Acquires Rational Ada

[Ingo Marks]

Marin David Condic wrote:

> Maybe we should try to get containers into the standard five years 
> from now....." Sounds to me like a recepie for too little too late.

I think you don't need to wait five years. There are some efforts on the 
way already. Look at

http://www.nongnu.org/Grace/Grace_Home.html
http://savannah.nongnu.org/projects/grace/

Regards,
Ingo

Re: IBM Acquires Rational Ada

[Marin David Condic]

If that's all I wanted, I don't even need to wait 5 minutes. There are
dozens of component libraries out there for the cost of a download. I've got
my own personal component library right here that I wrote myself. Component
libraries are not the problem. The problem is a "Standard" component library
that just plain comes with any given Ada compiler by default. The weakness
of non-standard libraries is not that they don't work well or won't get a
job done, but rather that each one is different (user's can't move from one
project to another and be sure of having the same tools) and none of them
are just there to use without any special effort. (You need to go out and
select one of your own choosing that is, by definition, not part of Ada.
"See??? Ada is not as good as C++ because C++ comes with a component library
and Ada doesn't!!!" :-)

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Ingo Marks <nospam_adv@region-nord.de> wrote in message
news:athli4$93i$06$1@news.t-online.com...
> Marin David Condic wrote:
>
> > Maybe we should try to get containers into the standard five years
> > from now....." Sounds to me like a recepie for too little too late.
>
> I think you don't need to wait five years. There are some efforts on the
> way already. Look at
>
> http://www.nongnu.org/Grace/Grace_Home.html
> http://savannah.nongnu.org/projects/grace/
>
> Regards,
> Ingo
>

Re: IBM Acquires Rational Ada

[tmoran]

> The problem is a "Standard" component library that just plain comes with
> any given Ada compiler by default.
  1) What spec should be implemented for a component.  For instance,
a high level abstraction like Claw.Sockets, or a lower level like
Gnat.Sockets?  Both?  Or are they sufficiently different they don't
compete?  The user is back where he started, trying to make a decision.
  2) A compiler vendor must consider not only what would attract new
customers (from his rivals, in a slow growing market), but what keeps
his existing customers from switching.  If his current customers are
dependent on his non-standard features/libraries, it would be costly
for them to switch, but standard items make the vendor's product more
a commodity, subject to competition from anyone with a lower price.
For the vendor that's a disincentive to standardization.  Microsoft
doesn't offer "standard" components out of good will, they offer
"lock you into Windows" components.  Perhaps if there was a monopoly
in Ada compilers, it wouldn't worry about losing customers to other Ada
vendors, but would instead worry about losing them to other languages.

Re: IBM Acquires Rational Ada

[Marin David Condic]

<tmoran@acm.org> wrote in message news:AB4L9.166662$pN3.10785@sccrnsc03...
> > The problem is a "Standard" component library that just plain comes with
> > any given Ada compiler by default.
>   1) What spec should be implemented for a component.  For instance,
> a high level abstraction like Claw.Sockets, or a lower level like
> Gnat.Sockets?  Both?  Or are they sufficiently different they don't
> compete?  The user is back where he started, trying to make a decision.

That's a decision I'm willing to defer to some committee that acts as the
owner of the library. Granted, its not a simple question. We've watched the
debate here over something as relatively simple as a linked list package -
everyone wanting something different. There will never be a perfect answer
that will satisfy all users, but that doesn't mean that we shouldn't try to
come up with something that provides more leverage to the developer.


>   2) A compiler vendor must consider not only what would attract new
> customers (from his rivals, in a slow growing market), but what keeps
> his existing customers from switching.  If his current customers are
> dependent on his non-standard features/libraries, it would be costly
> for them to switch, but standard items make the vendor's product more
> a commodity, subject to competition from anyone with a lower price.
> For the vendor that's a disincentive to standardization.  Microsoft
> doesn't offer "standard" components out of good will, they offer
> "lock you into Windows" components.  Perhaps if there was a monopoly
> in Ada compilers, it wouldn't worry about losing customers to other Ada
> vendors, but would instead worry about losing them to other languages.

I'm well aware of economics. Sure the vendors have a built-in interest in
locking customers into proprietary, non-standard answers. Sure, they have to
react to what their customers (existing and potential) seem to want and
need. But if that were the only issue, then C++ should not have the STL,
should it? Or taken a step further, there should be no adherence at all to
the ARM or even that there be a "Standard" language called Ada, would there?
Obviously, there must be other factors in the industry that cause "standard"
libraries to arise for a language because languages seem to have them.

There is something to be said for the notion that a rising tide lifts all
boats. My argument here is that Ada is at best a bit-part player in the
software development play. Changing that helps everyone with an interest in
Ada and is going to require truly innovative thinking on the part of those
who want to see the language succeed - which I assume includes the vendors.

Several years ago, Dodge took a look at the pickup truck market and in the
field of large trucks, they owned less than one percent of the US market.
They figured that the choices were to either to get out of it or do
something radical on the notion that they couldn't reall hurt anything by
trying. They conducted lots of research to find out what the potential
customer wanted then got really creative and innovative at the drafting
table. The result was that they not only dramatically increased their market
share but also pretty much forced Ford and Chevrolet to follow their design
lead with the result being that the bigger players are now chasing the
Dodge, rather than the other way around.

Sure its risky and its difficult to see what the right answer is or how to
get it done. But lets be realistic. Ada has such a small segment of the
software development market that the choices look pretty much the same to me
as they did for Dodge. Either milk the cash-cow for as long as you can while
it gradually dries up and migrate to some other business, or take some
radical action that dramatically changes what Ada means to the whole world.
If there were a *will* to do something, I'm sure a way would be found. If
the vendors had a strong desire to say "The language should go down this
path to make it more valuable..." (Be that a large library, GUI, Database,
Operating System, all of the above, or something completely different) then
some creative thought could be put into how to get there. Joint funding of
some development effort? Government research grants? Volunteer efforts?
Combinations of all three?

The alternative is to do nothing and continue to watch new development
projects go to languages like C++ and Java.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: IBM Acquires Rational Ada

[steve_H]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message  

> That's a decision I'm willing to defer to some committee that acts as the
> owner of the library.

That is the problem with Ada, it is the 'committee' thing.

committees can not write or design software. May be review or comment
on it only.  

the best libraries and software out there was written by a single, 
or two talented individuals. Only in the Ada world I keep seeing this 
committee thing pop up all the time. The more people work on software,
the worst and more delayed it gets. 

my 2 cents.

Re: IBM Acquires Rational Ada

[Marin David Condic]

I don't mean to suggest that a committee should design the library, but I
can't see how you're going to avoid a committee deciding what is going to be
considered part of Ada. If there was only a single vendor of Ada and no
users of Ada, then the vendor gets to design what goes in Ada. The instant
it becomes plural and/or has users with various interests, there's your
committee.

If I were Dictator of the Universe, the way it would happen would be to have
the vendors and the major users cough up a few intelligent individuals to
serve as the committee to decide what the design parameters are and survey
what's already out there to see if anything can be adopted or modified.
Select one person to be the designer and then review/approve his work. Give
them a deadline to come up with an initial result and give them sufficient
resources to get that done. I'd imagine something like that could get you at
least a container library in two or three months. Maybe more than that.
Establish some reasonable objectives with a broad brush and let some smart
people agree on what the details should be. (Mission Statement: "Go figure
out how to give Ada some development leverage for some significant subset of
development projects via libraries. Subjects to consider are Containers,
Math, Text Processing, OS Interfacing, Communications, GUI, {etc}. First
Deadline: A working Containers package, under a tree extensible to other
areas, within 3 months.")

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

steve_H <nma124@hotmail.com> wrote in message
news:8db3d6c8.0212170741.18770baa@posting.google.com...
>
> That is the problem with Ada, it is the 'committee' thing.
>
> committees can not write or design software. May be review or comment
> on it only.
>
> the best libraries and software out there was written by a single,
> or two talented individuals. Only in the Ada world I keep seeing this
> committee thing pop up all the time. The more people work on software,
> the worst and more delayed it gets.
>
> my 2 cents.

Re: IBM Acquires Rational Ada

[Wes Groleau]

> For the vendor that's a disincentive to standardization.  Microsoft
> doesn't offer "standard" components out of good will, they offer
> "lock you into Windows" components.  Perhaps if there was a monopoly

That's the key!  Follow Microsoft's example: write some "lock you
in" libraries and _call_ them 'standard.'

Re: IBM Acquires Rational Ada

[Marin David Condic]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
news:3DF628C4.7090607@cogeco.ca...
>
> This is still a problem IMHO with Ada. I think the adapower site could
> be better organized and more complete in this regard. But I don't like
> to complain unless I can volunteer ;-)  Too much seems spread all over
> the net (and I am guilty of this myself).  What adapower cannot host,
> should perhaps have links to other Ada sites at least. I know that some
> of this is there, but it seems rather incomplete.
>
Well, its not just that its spread out over the net. Its that it is also
bits and pieces, none of which were designed to work together or look alike
or present a consistent, integrated programming environment to the
developer. If you need the pieces to work together, you typically are going
to have to make that happen yourself - and even then, it is going to look
like some cobbled-together, ecclectic collection of stuff and its never
going to be as slick and smooth and seamless as something that was designed
from the ground up to be a well integrated IDE.


>
> There needs to be more "general purpose" quality bindings written. Some
> of this is happening now that GNAT has been available, but like XFree86,
> this effort takes time. It may be a pipe dream, but I still believe
> in the possibility that we could see an Ada renaissance some day. As
> pyramids of software are written, at some point, people are going to
> start demanding that better quality foundations exist from which to
> start building.
>
It wouldn't hurt to have an Ada OS, but that's a really big project. If
there were a way to get some funding to build one, that might get the ball
rolling. After all, that's how Gnat got its start - and Gnat did a lot to
make Ada more popular by providing an accessible compiler for the masses.

Bindings, I'm not so sure about. That can get into tricky issues. But at
least a nice, big, juicy library of some general purpose code might start
offering lots of leverage. Containers at minimum. Probably some nice math
and statistics packages. Maybe some text processing facilities (like XML?)
All that sort of thing would be relatively straightforward to build and make
portable. A reference implementation that was agreed upon by most of the
vendors would do the trick and it would create lots of leverage for the
developer.


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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
> news:3DF628C4.7090607@cogeco.ca...
...
>>There needs to be more "general purpose" quality bindings written. Some
>>of this is happening now that GNAT has been available, but like XFree86,
>>this effort takes time. It may be a pipe dream, but I still believe
>>in the possibility that we could see an Ada renaissance some day. As
>>pyramids of software are written, at some point, people are going to
>>start demanding that better quality foundations exist from which to
>>start building.
> 
> It wouldn't hurt to have an Ada OS, but that's a really big project. If
> there were a way to get some funding to build one, that might get the ball
> rolling. After all, that's how Gnat got its start - and Gnat did a lot to
> make Ada more popular by providing an accessible compiler for the masses.
> 
> Bindings, I'm not so sure about. That can get into tricky issues. But at
> least a nice, big, juicy library of some general purpose code might start
> offering lots of leverage. Containers at minimum. Probably some nice math
> and statistics packages. Maybe some text processing facilities (like XML?)
> All that sort of thing would be relatively straightforward to build and make
> portable. A reference implementation that was agreed upon by most of the
> vendors would do the trick and it would create lots of leverage for the
> developer.

But consider the challenges of a Windows programmer that wants to write his
application in Ada:

  - A user interface beyond tty (console) mode is required (text or GUI)
  - Database access is required (very few serious applications can do
    without this).
  - O/S interfaces (e.g. printing and registry)
  - Network APIs

Right away the user has a 3 or 4-way struggle, with the first being the
user interface (GtkAda, CLAW, GWindows, or a
binding to curses?) Should the app be portable to Linux? This reduces
the choices still further.

What Ada database support exists? Near none.  Do you build bindings to
to Microsoft's APIs?  Do you use other bindings like those that exist
for PostgreSQL (or like mine ;-)

What bindings are there for registry use?

Do you need COM access (GNATCOM?)

Which Ada socket binding do you use?

Should the application be written with GNAT specific features? Should
gnatprep be used as a preprocessor for portability?


Linux and FreeBSD application writers face many of these same tough
decisions. The reality at present, is that general purpose application
development is a tougher road to tread at the moment in Ada. Things are
improving with the help of volunteered software from all over, but
I think there needs to much more before the masses will swallow the
challenges that they'll face.

<flame-bait>
Most programmers are wimps!
</flame-bait>

Things need to get easier.

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

Re: IBM Acquires Rational Ada

[tmoran]

> What Ada database support exists? Near none.
  I don't understand that.  4 years ago, learning Ada, my son used a
binding from, IIRC, www.adapower.com  Has there been no progress?

>   - A user interface beyond tty (console) mode is required (text or GUI)
>   - Database access is required (very few serious applications can do
>     without this).
>   - O/S interfaces (e.g. printing and registry)
>   - Network APIs
>
> Right away the user has a 3 or 4-way struggle, with the first being the
> user interface (GtkAda, CLAW, GWindows, or a binding to curses?)
  So decide on CLAW and stop worrying yourself. <g,d&r>

> Should the app be portable to Linux? This reduces
> the choices still further.
  What would a C++ programmer do?  People sell systems to do cross-OS
programming, but what are their limitations?  Is there no decision
to be made whether the app is portable to Linux?  How many real world
apps do in fact exist on multiple platforms?

> What bindings are there for registry use?
> Which Ada socket binding do you use?
  These are no longer questions once you've decided which binding to
go with.

In <3DF8D33F.9020205@cogeco.ca> Warren W. Gay VE3WWG said:
> Give us a _PROPER_ Ada.Calendar package for a start! (can't determine
> the day of the week for example)
  Of course you can.  Claw, among others, has

Re: IBM Acquires Rational Ada

[Richard Riehle]

"Warren W. Gay VE3WWG" wrote:

> But consider the challenges of a Windows programmer that wants to write his
> application in Ada:
>
>   - A user interface beyond tty (console) mode is required (text or GUI)
>   - Database access is required (very few serious applications can do
>     without this).
>   - O/S interfaces (e.g. printing and registry)
>   - Network APIs

Some of this list is easily dealt with.   I believe a serious Windows
developer would use CLAW for the GUI.    However, the database
issue is more serious.

We once had AdaSage for good database support, but that has vanished
from the landscape.   There was a company in Santa Clara, CA that
once developed a full relational database in Ada for Ada, but that has
also vanished.   Oracle seems to have de-escalated support for Ada,
and I'm not sure of the status of other database bindings that once
existed.

So, if someone were to create a database product in Ada for Ada, would
there be a market for it?  Oh, I see.  We distribute it via the FSF under the
GPL.  Who can afford the time to do that.  Most Ada programmers I know
are working full-time jobs and don't have the luxury of creating free
software.   OK.  Will someone fund such development?   Well, there's
no one left in the Ada industry with enough money to do this kind of
thing.

Randy and Tom are struggling to keep CLAW going as a viable
commercial venture.   Compiler publishers are stuggling to keep
the cash flow flowing.   There is no one in the DoD willing to
break free money for anything related to Ada these days.

We lost the opportunity when we had it.   So much focus on embedded
systems and little on database systems.   Well, the compiler companies
had no interest in commercial sales of Ada (or the compilers would
have been priced more reasonably).  As long as the DoD was a captive
customer, there was no incentive for competitive product pricing.

ACT has done great things for democratizing Ada.  We can hope it
is not too late.  Just today, one of my international students delivered
a presentation for his final project in my software risk management
class comparing the risks of Ada to the risks of C++.   As a language,
absent all other issues, Ada still wins over C++.  When one considers
the above list given by Mr. Gay, the situation is much gloomier.

What can we do to fix this?   How can we take a superior language
technology, one for which compilers are now in the affordable
range, and make available the necessary tools, at reasonable
prices, to make it a more attractive alternative?

Richard Riehle

Re: IBM Acquires Rational Ada

[Ed Cogburn]

Richard Riehle wrote:
> "Warren W. Gay VE3WWG" wrote:
> 
> 
>>But consider the challenges of a Windows programmer that wants to write his
>>application in Ada:
>>
>>  - A user interface beyond tty (console) mode is required (text or GUI)
>>  - Database access is required (very few serious applications can do
>>    without this).
>>  - O/S interfaces (e.g. printing and registry)
>>  - Network APIs
> 
> 
> Some of this list is easily dealt with.   I believe a serious Windows
> developer would use CLAW for the GUI.    However, the database
> issue is more serious.
> 
> We once had AdaSage for good database support, but that has vanished
> from the landscape.   There was a company in Santa Clara, CA that
> once developed a full relational database in Ada for Ada, but that has
> also vanished.   Oracle seems to have de-escalated support for Ada,
> and I'm not sure of the status of other database bindings that once
> existed.
> 
> So, if someone were to create a database product in Ada for Ada, would
> there be a market for it?  Oh, I see.  We distribute it via the FSF under the
> GPL.  Who can afford the time to do that.  Most Ada programmers I know
> are working full-time jobs and don't have the luxury of creating free
> software.

[snip]

Who had the time to write all the Free software out there now?  I think 
Steve_H's point is to get an Ada compiler out there as a "standard" component 
of GCC, available on most systems (on Debian Linux the compiler, RTL, curses 
binding, socket bindings, database/mySQL bindings, and GtkAda are parts of the 
main distribution, although not installed by default, so you don't need to go 
looking elsewhere), and let this new-found accessibility and presense 
kickstart the kind of development that will lead to the tools needed to take 
Ada mainstream.  I wouldn't even be here if it weren't for GNAT becoming 
integrated into GCC 3.2, which is what led me to take a closer look.  If you 
look just at the commercial side, the situation probably is grim, I'm not 
familar with it, but SteveH's post near the beginning of this thread wasn't 
referring to the commercial market.  Perhaps Ada will have to succeed in the 
Free/Opensource software community first before it can make a comeback on the 
commercial side?  Or are you saying the commercial side is already lost for good?

Re: IBM Acquires Rational Ada

[Marin David Condic]

Well, one thing might be to not look backwards at what has been done already
and ask what direction the future holds? For example, you bring up
databases. I agree that it would be *really* slick if Ada compilers were to
come with some sort of database available. But how do we get the money to
build something like that? The government? But they don't want to fund Ada
development, do they? O.K. Don't tell them its for Ada.

Is there someone out there who has a researchy kind of thing that applies to
databases? One with a twist that isn't currently being addressed? Something
beyond "relational"? Something new and innovative that doesn't say "Me
Too!!!"?

Suppose a research proposal were to be written up to implement the XYZ
database that has the PDQ capability that is going to add some significant
benefit to the world and perhaps spin off new commercial products. Suppose
that part of the research proposal is that when the research is done, the
software will be put under the GPL and made available to the world in a way
similar to GNAT. Suppose further that the developers just so happen to
decide that Ada is the best language in which to build this database
thingie. Whoops! There's a new database that can be marketed along with your
garden variety Ada compiler! :-)

I think we need to be creative and dream up capabilities for Ada that are
*not* mere duplicates of what everyone else has. If it is too costly to do
with a handful of guys as a part-time thing, then maybe we need to get
creative about how it gets funded as well. I don't know about the rest of
the world, but I'd always be willing to sit down and talk about potential
products that might have the beneficial side-effect of improving Ada usage
and try to figure out the mechanisms by which they could be built/marketed.
I could always use a good tilt at some windmills somewhere. :-)

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Richard Riehle <richard@adaworks.com> wrote in message
news:3DF978DE.B4C2A2C1@adaworks.com...
>
> What can we do to fix this?   How can we take a superior language
> technology, one for which compilers are now in the affordable
> range, and make available the necessary tools, at reasonable
> prices, to make it a more attractive alternative?
>

Re: IBM Acquires Rational Ada

[Wes Groleau]

> databases. I agree that it would be *really* slick if Ada compilers were to
> come with some sort of database available. But how do we get the money to
> build something like that? The government? But they don't want to fund Ada
> development, do they? O.K. Don't tell them its for Ada.

They already did.  See my answer to R.R.  I forgot to mention
RTDB was Ada 83 and was written because Ingres was way too slow
for AN/BSY-2.  FIRM was its Ada 95 successor (sort of).

Note that both were developed under defense contracts,
with all the requirements, design, test, peer review,
etc. rigor which that implies.

Re: IBM Acquires Rational Ada

[Jeffrey Carter]

Wes Groleau wrote:
 > Note that both [RTDB and FIRM] were developed under defense
 > contracts, with all the requirements, design, test, peer review, etc.
 > rigor which that implies.

Many defense contracts are structured so the contractor maximizes 
profits by using hordes of unqualified coders to create barely 
acceptable software, even though using fewer software engineers would 
create much better software much sooner. This may not be good PR for 
these DBs.

-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail

Re: IBM Acquires Rational Ada

[Jeffrey Carter]

Wes Groleau wrote:
 > Note that both [RTDB and FIRM] were developed under defense
 > contracts, with all the requirements, design, test, peer review, etc.
 > rigor which that implies.

Many defense contracts are structured so the contractor maximizes 
profits by using hordes of unqualified coders to create barely 
acceptable software, even though using fewer software engineers would 
create much better software much sooner. This may not be good PR for 
these DBs.

-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail

Re: IBM Acquires Rational Ada

[Marin David Condic]

Sounds like a good start. Problem 1: Is any of that stuff available under
any kind of license that lets someone else use/develop it? Problem 2:
Assuming it were available, would any of the vendors (or their existing
customers) start clammoring to have it incorporated in their products?
Problem 3: Is it sufficiently powerful - or at least offering something
new/unique - that it could compete against other database products?

I don't want to shoot down a good idea - just trying to raise the issues
that would need to be addressed if persuing the matter further is to have
any success. Its sort of like raising the issue of the Booch Components as a
conventional part of Ada - The vendors don't seem to be itching to put them
in, their customers don't seem to be begging for it and it really isn't
somehow or other some major innovation above & beyond other component
libraries that makes it so interesting to use that everybody just gravitates
to it naturally instead of writing their own component library. Its a tough
nut to crack without having something pushed from some sufficiently powerful
body to make it stick.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Wes Groleau <wesgroleau@despammed.com> wrote in message
news:1ZlK9.2246$c6.2601@bos-service2.ext.raytheon.com...
> > databases. I agree that it would be *really* slick if Ada compilers were
to
> > come with some sort of database available. But how do we get the money
to
> > build something like that? The government? But they don't want to fund
Ada
> > development, do they? O.K. Don't tell them its for Ada.
>
> They already did.  See my answer to R.R.  I forgot to mention
> RTDB was Ada 83 and was written because Ingres was way too slow
> for AN/BSY-2.  FIRM was its Ada 95 successor (sort of).
>
> Note that both were developed under defense contracts,
> with all the requirements, design, test, peer review,
> etc. rigor which that implies.
>

Re: IBM Acquires Rational Ada

[Wes Groleau]

> Sounds like a good start. Problem 1: Is any of that stuff available under
> any kind of license that lets someone else use/develop it? Problem 2:

It is my belief that since we (the taxpayers) paid for it,
we (the taxpayers) can get the source, provided it isn't
classified--which it shouldn't be, being a general-purpose
database.

> Assuming it were available, would any of the vendors (or their existing
> customers) start clammoring to have it incorporated in their products?

Don't know.  They might if they knew about it.  But they might prefer
to get it from the developer, _with_support_

> Problem 3: Is it sufficiently powerful - or at least offering something
> new/unique - that it could compete against other database products?

Seemed like it to me.  But contact Lockheed-Martin, Boxo 4840, Syracuse, NY
for the details.  They do not seem to be agressively marketing it.
I did not work directly on RTDB and I left GE/Martin/Lockheed before
the successor, FIRM, came along.  But I liked what I read about both.
One thing I _did_ work on there was, in the opinion of several of us,
a very useful testing tool.  We tried to get the company to market it,
and we were told "We are not a tools business."

BTW, RTDB = Real-Time DataBase.  A fast _and_ deterministic
component for a hard-real-time _large_ military system.

> I don't want to shoot down a good idea - just trying to raise the issues
> that would need to be addressed if persuing the matter further is to have
> any success. Its sort of like raising the issue of the Booch Components as a
> conventional part of Ada - The vendors don't seem to be itching to put them

I understand.  But you did suggest developing a database,
and I figured mentioning the existence of a good one couldn't
hurt.

Re: IBM Acquires Rational Ada

[Marin David Condic]

Wes Groleau <wesgroleau@despammed.com> wrote in message
news:0YkL9.2262$c6.2398@bos-service2.ext.raytheon.com...
>
> Seemed like it to me.  But contact Lockheed-Martin, Boxo 4840, Syracuse,
NY
> for the details.  They do not seem to be agressively marketing it.
> I did not work directly on RTDB and I left GE/Martin/Lockheed before
> the successor, FIRM, came along.  But I liked what I read about both.
> One thing I _did_ work on there was, in the opinion of several of us,
> a very useful testing tool.  We tried to get the company to market it,
> and we were told "We are not a tools business."
>
That's a common problem with the larger contractors out there. They develop
something for internal use because they couldn't make do with what was
commercially available, but they are not in the position to market what they
have built. They'd almost be better off spinning off a software company to
which they dump the things they build for further development. Getting a
commercial base for it means they don't have to be the sole supporters of
all future development. The model still has problems - you don't get
guarantees that the development will go exactly the way you'd like and your
competitors suddenly gain access to the tools that were maybe instrumental
in helping you get the business you really wanted. But life is full of
tradeoffs.

However, that does bring up an interesting possibility in the way of finding
funding for various Ada enhancement projects. There are a number of large
institutional users of Ada who might be willing to toss some money at an
"Ada Productivity Consortium" - the goal of which would be to build Ada
related tools and libraries that would then be made generally available.
Glomming onto what might already be there and then enhancing it as a joint
effort might be a way for them to get what they want/need and have it
incorporated in with compilers & development kits. A few million bucks from
the likes of LockMart, Boeing, GE, Pratt, et alia, is a spit in the bucket
to them as long as they thought they would get something they could use out
of it. Hmmmm......

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: IBM Acquires Rational Ada

[Wes Groleau]

> have built. They'd almost be better off spinning off a software company to
> which they dump the things they build for further development. Getting a
> commercial base for it means they don't have to be the sole supporters of
> all future development. The model still has problems - you don't get
> guarantees that the development will go exactly the way you'd like and your
> competitors suddenly gain access to the tools that were maybe instrumental
> in helping you get the business you really wanted. But life is full of

Perhaps that's why they didn't let us do that, either.  :-)

Re: IBM Acquires Rational Ada

[Marin David Condic]

Wes Groleau <wesgroleau@despammed.com> wrote in message
news:rHML9.2286$c6.2634@bos-service2.ext.raytheon.com...
>
> Perhaps that's why they didn't let us do that, either.  :-)
>
Oh, I've been in on conversations where these sorts of things were
discussed. Pratt & Whitney had (still has) a toolset they were interested in
possibly farming out to a subcontractor at one or more times. The
discussions would go around and around and because of lack of consensus or
the unwillingness of anybody to put their neck on the line, inertia took
over and they never farmed out the tools. They wouldn't likely have found a
huge market, but if there were a handful of other users supporting a
development team, it would have defrayed the costs to Pratt and probably
given them more and better tools.

There was once something called the Software Productivity Consortium which
maybe once had some promise for being a mechanism by which the big companies
might have leveraged their efforts, but for reasons I didn't understand,
they refused to produce software (or even designs of software) and insisted
mostly on producing paper. Unfortunately, paper didn't really result in much
productivity imporvement. Had the companies agreed to jointly develop some
software tools instead, they might have got somewhere with it. That's why I
was thinking that some kind of "Ada Productivity Consortium" might achieve
what the SPC couldn't and help make Ada a better product for the whole world
at the same time.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: IBM Acquires Rational Ada

[faust]

 Wes Groleau <wesgroleau@despammed.com> ,  emitted these fragments:

 
>They already did.  See my answer to R.R.  I forgot to mention
>RTDB was Ada 83 and was written because Ingres was way too slow
>for AN/BSY-2.  FIRM was its Ada 95 successor (sort of).

see
http://www.lockheedmartin.com/syracuse/eaglespeed/products/rtdb/rtdb_features.html

--------------------------------------------------------
Come see,
real flowers
of this pain-filled world.

(from Basho)

Re: IBM Acquires Rational Ada

[Wes Groleau]

> So, if someone were to create a database product in Ada for Ada, would
> there be a market for it?  Oh, I see.  We distribute it via the FSF under the
> GPL.  Who can afford the time to do that.  Most Ada programmers I know

RTDB -> FIRM.  Developed under US DoD contract, therefore
source can be acquired from the DoD.  Being DoD, however,
the red tape to get it would be a pain.

For less hassle (but more money), buy them from Lockheed-Martin
with support.  At least I think you can.

Someone with initials M. C. could tell you more.  I don't know
whether he follows C.L.A., but he _is_ on the Ada for Mac OS X
mailing list.  See adapower.com to subscribe, and post something
like "Somebody here want to tell me about databases called
FIRM and RTDB?"

Re: IBM Acquires Rational Ada

[faust]

 Wes Groleau <wesgroleau@despammed.com> ,  emitted these fragments:

>For less hassle (but more money), buy them from Lockheed-Martin
>with support.  At least I think you can.

You can 
See
http://www.lockheedmartin.com/syracuse/eaglespeed/products/firm/firm.html

--------------------------------------------------------
Come see,
real flowers
of this pain-filled world.

(from Basho)

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Richard Riehle wrote:
> "Warren W. Gay VE3WWG" wrote:
> 
>>But consider the challenges of a Windows programmer that wants to write his
>>application in Ada:
>>
>>  - A user interface beyond tty (console) mode is required (text or GUI)
>>  - Database access is required (very few serious applications can do
>>    without this).
>>  - O/S interfaces (e.g. printing and registry)
>>  - Network APIs
> 
> Some of this list is easily dealt with.   I believe a serious Windows
> developer would use CLAW for the GUI.    However, the database
> issue is more serious.

Someone else mentioned CLAW as well earlier. But this doesn't help
the many *BSD/Linux/UNIX application developers.

> We once had AdaSage for good database support, but that has vanished
> from the landscape.   There was a company in Santa Clara, CA that
> once developed a full relational database in Ada for Ada, but that has
> also vanished.   Oracle seems to have de-escalated support for Ada,
> and I'm not sure of the status of other database bindings that once
> existed.

AFAIK, Oracle no longer supports the Ada embedded SQL product. If you're
lucky, it might be available still.

> We lost the opportunity when we had it.   So much focus on embedded
> systems and little on database systems.   Well, the compiler companies
> had no interest in commercial sales of Ada (or the compilers would
> have been priced more reasonably).  As long as the DoD was a captive
> customer, there was no incentive for competitive product pricing.

Perhaps I don't understand the military mindset well, but I would have
thought that the DoD would have had their own needs for databases
and a preference for Ada. Or did they not consider these to be as
mission critical?

> What can we do to fix this?   How can we take a superior language
> technology, one for which compilers are now in the affordable
> range, and make available the necessary tools, at reasonable
> prices, to make it a more attractive alternative?
> 
> Richard Riehle

I am pleased to see that GNAT is being integrated into GCC. With
time, as many hope, it will become a standard feature of Linux
distros for example. As more apps get written in Ada, more people
who compile from source will want to make sure that they have
the packages installed to compile them with.

But here's a thought:

If someone could help out the Red Hat's/SuSe's etc. to package
all of those "other" Ada packages like FLORIST, Booch Components
etc. into pre-installed Linux packages, then things might become
a bit easier for some developers at least.

For Windows, someone could provide a 2ndary install for all of
those other useful Ada packages so that after installing GNAT,
one more simple install puts all of the other libraries and
packages into place.

In other words, we need some Ada package distros to do the
same thing that Linux distros do. Make it easier to install and
maintain all of those optional Ada packages that do exist.

Any volunteers? ;-)

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

Re: IBM Acquires Rational Ada

[Dennis Lee Bieber]

Warren W. Gay VE3WWG fed this fish to the penguins on Friday 13 
December 2002 09:55 am:

> 
> Perhaps I don't understand the military mindset well, but I would have
> thought that the DoD would have had their own needs for databases
> and a preference for Ada. Or did they not consider these to be as
> mission critical?
>
        In this day and age, the directive to defense contractors leans 
towards COTS. Evaluate the existing products and buy the one that fits 
the needs before implementing a proprietary solution.
 

-- 
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <

Re: IBM Acquires Rational Ada

[Wes Groleau]

>         In this day and age, the directive to defense contractors leans 
> towards COTS. Evaluate the existing products and buy the one that fits 
> the needs before implementing a proprietary solution.

That's the theory.  The practice is select one with a GUI
that impresses the customer (who may not know much about
software engineering).  Then re-write the requirements
to fit what you've selected.

Re: IBM Acquires Rational Ada

[steve_H]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message  

> In other words, we need some Ada package distros to do the
> same thing that Linux distros do. Make it easier to install and
> maintain all of those optional Ada packages that do exist.
> 
> Any volunteers? ;-)

this is such a group: http://www.gnuada.org/alt.html I do not know
how active the group is still.

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

steve_H wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message  
> 
>>In other words, we need some Ada package distros to do the
>>same thing that Linux distros do. Make it easier to install and
>>maintain all of those optional Ada packages that do exist.
>>
>>Any volunteers? ;-)
> 
> this is such a group: http://www.gnuada.org/alt.html I do not know
> how active the group is still.

This effort is focused too much on Linux (only). Where is
the *BSD installable versions for example?

IMO what is needed is a fairly extensive _group_ of packages
rolled into one RPM (or other installable package). Even nicer,
would be a menu to allow you to exclude packages you didn't want
to install as part of this one time install/update.  The gnuada
approach is still very much a piecemeal approach.

What I am suggesting is an "Ada Distribution" where everything
is included (maybe on CD), and you pick and choose what you
want installed (including the option to install "all") at
install time.

Heck, I may do it myself someday, if I ever find the time. But
time is my enemy at the moment ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: IBM Acquires Rational Ada

[Tarjei T. Jensen]

Warren W. Gay  wrote:
> 
> AFAIK, Oracle no longer supports the Ada embedded SQL product. If you're
> lucky, it might be available still.
> 

There is still gnade which is sort of nice.

greetigns,

Re: IBM Acquires Rational Ada

[Ole-Hjalmar Kristensen]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
<snip>

> 
> I am pleased to see that GNAT is being integrated into GCC. With
> time, as many hope, it will become a standard feature of Linux
> distros for example. As more apps get written in Ada, more people
> who compile from source will want to make sure that they have
> the packages installed to compile them with.
> 

GNAT is distributed with Suse 8.1.

<snip>

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

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: IBM Acquires Rational Ada

[Tarjei T. Jensen]

"Ole-Hjalmar Kristensen wrote:
> 
> GNAT is distributed with Suse 8.1.
> 

Also with FreeBSD (you need the extra CDs).

greetings,

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Tarjei T. Jensen wrote:
> "Ole-Hjalmar Kristensen wrote:
> 
>>GNAT is distributed with Suse 8.1.
> Also with FreeBSD (you need the extra CDs).
> 
> greetings,

Yes, and I am one of FreeBSD's clients so to speak ;-)

What version of GNAT are they shipping with the newest
versions of FreeBSD these days?  I am still on
FreeBSD 4.3-Release + (GNAT 3.13p). I have compiled
GCC 3.1 with Ada support, but it has issues ;-)

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

Re: IBM Acquires Rational Ada

[Michael Bode]

Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> writes:

> GNAT is distributed with Suse 8.1.

It is part of Suse at least since 7.1. It is also in Debian 3.

-- 
Michael Bode
Rhens

Re: IBM Acquires Rational Ada

[Marin David Condic]

Fair enough and an apt description of the problem. Consider that while there
may be dozens of libraries/tools that get you at least part of the way
there, you don't really have a single, well integrated, orthogonal,
"conventional" answer. If Ada were to shoot for coming up with a means of
addressing the areas you describe (User Interface, Database, OS Interface,
Network) it would go a long way toward providing the developer with the
needed leverage. I could imagine parent packages that do the things that can
be made portable across the major systems (Windows, *nix, MacOS, etc.) with
allowable child packages that provide the features that can only be had in
some specific implementation. Build a reference implementation shared by all
the vendors and update it regularly and I think you've really got something
there.

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

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
news:3DF8D8BF.9020606@cogeco.ca...
>
> But consider the challenges of a Windows programmer that wants to write
his
> application in Ada:
>
>   - A user interface beyond tty (console) mode is required (text or GUI)
>   - Database access is required (very few serious applications can do
>     without this).
>   - O/S interfaces (e.g. printing and registry)
>   - Network APIs
>
> Right away the user has a 3 or 4-way struggle, with the first being the
> user interface (GtkAda, CLAW, GWindows, or a
> binding to curses?) Should the app be portable to Linux? This reduces
> the choices still further.
>
> What Ada database support exists? Near none.  Do you build bindings to
> to Microsoft's APIs?  Do you use other bindings like those that exist
> for PostgreSQL (or like mine ;-)
>
> What bindings are there for registry use?
>
> Do you need COM access (GNATCOM?)
>
> Which Ada socket binding do you use?
>
> Should the application be written with GNAT specific features? Should
> gnatprep be used as a preprocessor for portability?
>
>
> Linux and FreeBSD application writers face many of these same tough
> decisions. The reality at present, is that general purpose application
> development is a tougher road to tread at the moment in Ada. Things are
> improving with the help of volunteered software from all over, but
> I think there needs to much more before the masses will swallow the
> challenges that they'll face.
>
> <flame-bait>
> Most programmers are wimps!
> </flame-bait>
>
> Things need to get easier.
>
> --
> Warren W. Gay VE3WWG
> http://home.cogeco.ca/~ve3wwg
>

Re: IBM Acquires Rational Ada

[GianLuigi Piacentini]

Marin David Condic wrote:
> .... But at
> least a nice, big, juicy library of some general purpose code might start
> offering lots of leverage. Containers at minimum. Probably some nice math
> and statistics packages. Maybe some text processing facilities (like XML?)
> All that sort of thing would be relatively straightforward to build and make
> portable. ...


I agree with this.  I think that every language system should come with 
some sort of this stuff, otherwise it would be difficult to come out 
from the language specialized niche, if any.
Beside this, I'm not aware of any Ada porting to general purpose 
microprocessors, they do only C, with very few exception (not Ada).  But 
was Ada not intended for embedded systems ?  Is that difficult to port 
Ada in such environments ?

Just my .02 euro arguments ...

G.L. Piacentini

Re: IBM Acquires Rational Ada

[Dennis Lee Bieber]

GianLuigi Piacentini fed this fish to the penguins on Saturday 14 
December 2002 11:51 am:

> 
> I agree with this.  I think that every language system should come
> with some sort of this stuff, otherwise it would be difficult to come
> out from the language specialized niche, if any.
> Beside this, I'm not aware of any Ada porting to general purpose
> microprocessors, they do only C, with very few exception (not Ada). 
> But
> was Ada not intended for embedded systems ?  Is that difficult to port
> Ada in such environments ?
>
        Bottom up:

        The language itself probably ports easily -- it is the RUNTIME (since 
an embedded system doesn't have an OS per se, the runtime libraries 
have to do /everything/, including the tasking scheduler. If you have 
I/O devices, a small hard-disk or CF card, let's say, you have to 
supply a runtime that includes low-level disk I/O. Porting GNAT would 
involve: building a GCC back-end for the target machine; building a 
runtime library for the target; build your application specifying the 
target machine (this assumes true embedded system, where only the 
application will exist; if you mean to install the compiler on the 
system build GNAT/GCC specifying the target machine, and then use it 
/on/ the target to build the application).

        Would you consider the Lego Mindstorms robots to classify as an 
Embedded system? The Windows AdaGIDE system, with add-on downloads, 
supports the Mindstorms controller as a target (integer only and no 
tasking as I recall).
 


-- 
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <

Re: IBM Acquires Rational Ada

[faust]

 Richard Riehle <richard@adaworks.com> ,  emitted these fragments:

 >> http://www.internalmemos.com/memos/memodetails.php?memo_id=1145
>>
>
>Alas, no hint of what will become of Rational Ada.   If anyone at IBM
>realizes the power of the Rational Ada product, it could be great for
>Ada and for IBM.   I wish I could be optimistic about this.

Large doses of Prozac would help.

--------------------------------------------------------
Come see,
real flowers
of this pain-filled world.

(from Basho)

IBM , the kiss of death ( Re: IBM Acquires Rational Ada)

[faust]

 Richard Riehle <richard@adaworks.com> ,  emitted these fragments:

>Just announced today was the 2.1 billion dollar purchase
>of Rational by IBM.   One can only wonder what will happen
>to the Ada compiler products.   

Here is a hint.
Look at what IBM did to OS/2
Look at what IBM did to Lotus
Look at what IBM did to their own PC business.

I suppose that some of the technology may surface later in some other
product.

But you can kiss Rational goodbye.

>Things will either get better
>or they will get worse.  

Or they will stay much the same.

--------------------------------------------------------
Come see,
real flowers
of this pain-filled world.

(from Basho)

Re: IBM Acquires Rational Ada

[Don Westermeyer]

Richard Riehle <richard@adaworks.com> wrote in message news:<3DF1615C.7AAAC86E@adaworks.com>...
> Just announced today was the 2.1 billion dollar purchase
> of Rational by IBM.   One can only wonder what will happen
> to the Ada compiler products.   Things will either get better
> or they will get worse.   Of  course, I think Norm Cohen still
> works for IBM.  Perhaps he can make a difference.
> 
> Richard Riehle


Rational told us that they were moving away from Apex Ada anyway so
IMO IBM's purchase can't hurt.

I'm not too impressed with Rational Ada anyway - the editor and
debugger in particular are pretty mediocre

Re: IBM Acquires Rational Ada

[Alexandre E. Kopilovitch]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

> > In article <1039642856.867910@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> > > C and C++ freely interconvert the fundamental arithmetic
> > > types. If you would like to construe that as accepting
> > > garbage, you are free to do so. I don't find it a very
> > > compelling argument.
> > 
> > Whether one construes that as accepting garbage depends on one's
> > attitude toward computing, and potentially one's problem domain.
>
>Heh?  In what problem domain is it beneficial to have *implicit* type
>conversions that lose information?

Scripting. That is, rapidly cooking a cocktail by mixing several problem domains.

Re: IBM Acquires Rational Ada

[Grein, Christoph]

> >      void utoa(unsigned u, char *a)
> >      {
> >          char buf[30], *p = buf;
> >          do *p++ = u % 10 + '0'; while (u /= 10);
> >          do *a++ = *--p; while (p > buf);
> >          *a = 0;
> >      }
> 
> Not quite as concise as Integer'Image (X)!

Oh, thanx, Fraser, for enlightening me what all this unreadable C junk means :-)

Re: IBM Acquires Rational Ada

[Hyman Rosen]

Grein, Christoph wrote:
> Oh, thanx, Fraser, for enlightening me what all this unreadable C junk means :-)

This "unreadable C junk" runs the internet, and the newsgroup software
which is allowing you to disseminate your contempt. You should have a
little respect for your grandpappy.

Re: IBM Acquires Rational Ada

[Richard Riehle]

Hyman Rosen wrote:

> Grein, Christoph wrote:
> > Oh, thanx, Fraser, for enlightening me what all this unreadable C junk means :-)
>
> This "unreadable C junk" runs the internet, and the newsgroup software
> which is allowing you to disseminate your contempt. You should have a
> little respect for your grandpappy.

Yes, and back on the farm we kept equipment operating by clever
use of baling wire.

One of my colleagues asked me recently why I was so reluctant to
use C or C++ for my programs.   I replied that C++ was reminiscent
of the strike-anywhere matches our grandpappies named "barnburners."

Just today, I was reading a book on software architecture in which the
authors acknowledged that the vast marjority of C++ is noted for
being unmaintainable by anyone except its creator.

The fact that C and C++ is so widely used to create popular
software is no different than the fact that so many people
select MacDonald's, Burger King, or Kentucky Fried
Mynah Bird, for their sustenance under the illusion they
are actually being nourished.   The fact that something is
popular does not make it good.

I am required, during these past couple of years, to spend
more and more time with C++.  The more time I spend
with it, the more horrified I am at the thought it is being
used for our military weapon systems.

If C++ is the best we can do, this industry is in trouble
for a very long time to come.

Richard Riehle

Re: IBM Acquires Rational Ada

[Kevin Cline]

Richard Riehle <richard@adaworks.com> wrote in message news:<3DFD7E9D.69976C19@adaworks.com>...
> Hyman Rosen wrote:
> 
> > Grein, Christoph wrote:
> > > Oh, thanx, Fraser, for enlightening me what all this unreadable C junk means :-)
> >
> > This "unreadable C junk" runs the internet, and the newsgroup software
> > which is allowing you to disseminate your contempt. You should have a
> > little respect for your grandpappy.
> 
> Yes, and back on the farm we kept equipment operating by clever
> use of baling wire.
> 
> One of my colleagues asked me recently why I was so reluctant to
> use C or C++ for my programs.   I replied that C++ was reminiscent
> of the strike-anywhere matches our grandpappies named "barnburners."
> 
> Just today, I was reading a book on software architecture in which the
> authors acknowledged that the vast marjority of C++ is noted for
> being unmaintainable by anyone except its creator.

So is the vast majority of the code written in every other
popular language.  As the popularity of a language increases,
the average skill of the practitioners decreases.

Re: IBM Acquires Rational Ada

[Wes Groleau]

>>Just today, I was reading a book on software architecture in which the
>>authors acknowledged that the vast marjority of C++ is noted for
>>being unmaintainable by anyone except its creator.
> 
> So is the vast majority of the code written in every other
> popular language.  As the popularity of a language increases,
> the average skill of the practitioners decreases.

In the early 1980s, I listened to a presentation
given to a "Computer User's Group" aged teen to old.

I was appalled* when the presenter stated, "I can
never understand a program six months after I wrote it."

*Because this guy was a professor of Computer Science
at UCSD!

Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Wes Groleau wrote:
>>> Just today, I was reading a book on software architecture in which the
>>> authors acknowledged that the vast marjority of C++ is noted for
>>> being unmaintainable by anyone except its creator.
>>
>> So is the vast majority of the code written in every other
>> popular language.  As the popularity of a language increases,
>> the average skill of the practitioners decreases.
> 
> In the early 1980s, I listened to a presentation
> given to a "Computer User's Group" aged teen to old.
> 
> I was appalled* when the presenter stated, "I can
> never understand a program six months after I wrote it."
> 
> *Because this guy was a professor of Computer Science
> at UCSD!

This doesn't really surprise me. I once heard a college
prof complain about how hard it was to get C code to
compile. This had me wondering how he was doing at the
real challenge -- debugging the compiled C program that
was corrupting memory. Compiling is the easy part after
all. So when I heard this, it was easy to assess his
knowledge level of the C language ;-)

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

Re: IBM Acquires Rational Ada

[Kevin Cline]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3E00C2F7.8040800@cogeco.ca>...

> This doesn't really surprise me. I once heard a college
> prof complain about how hard it was to get C code to
> compile. This had me wondering how he was doing at the
> real challenge -- debugging the compiled C program that
> was corrupting memory. Compiling is the easy part after
> all. So when I heard this, it was easy to assess his
> knowledge level of the C language ;-)

In years of interviewing candidates for C++ programming positions,
two of the weakest claimed to have taught C++ professionally, one at
another company, and one at the undergraduate level at a U of Texas
branch.  Neither could answer simple questions about the C++ object
model, nor could they manage a solution to a straightforward
programming problem that could be handled in a dozen lines of code.

I suppose that's to be expected as long as programming pays better
than
teaching programming.

Re: IBM Acquires Rational Ada

[faust]

 kcline17@hotmail.com (Kevin Cline) ,  emitted these fragments:

>In years of interviewing candidates for C++ programming positions,
>two of the weakest claimed to have taught C++ professionally, one at
>another company, and one at the undergraduate level at a U of Texas
>branch.  Neither could answer simple questions about the C++ object
>model, nor could they manage a solution to a straightforward
>programming problem that could be handled in a dozen lines of code.


I met a TAFE ( sort of a community college or polytechnic ) teacher
who taught Pascal. 

He thought that Pascal was object oriented.

He now teaches at the University of Western Sydney !

--------------------------------------------------------
Come see,
real flowers
of this pain-filled world.

(from Basho)