Ada

Ada

[Brijesh]

I am fairly new to Ada programming and have a rather trivial question I
was hoping the group could help answer.

I understand Ada is a very powerful language but is not used much
outside the defence industry, I was woderign if this is a correct
assumption and if so why is this the case - and if not where else is it
used.

Thanks,

Brij

Re: Ada

[Greg Martin]

On Thu, 23 Dec 1999 11:11:12 +0000, Brijesh <brijesh.malkan@gecm.com>
wrote:

>I am fairly new to Ada programming and have a rather trivial question I
>was hoping the group could help answer.
>
>I understand Ada is a very powerful language but is not used much
>outside the defence industry, I was woderign if this is a correct
>assumption and if so why is this the case - and if not where else is it
>used.
>
Hi Brij.
I'm new to Ada as well but I can tell you it is used in other areas
where software might be considered mission critical. I'm Canadian and
know it to be used for air traffic control here (and elsewhere I
suspect) and software our space agency uses. In general it's used for
on board aircraft applications. It seems to be a small part of the
market but it's definately there. You might try searching on Ada jobs
or something similiar.
Regards,
Greg Martin.

Re: Ada

[Jon Jensen]

As someone who started doing Ada programming in 1987 I think the answer to
your question is simple:

The PC and Windows

In the 80's when Ada was first introduced, it was overshadowed by the
introduction of the PC and the drastic change the PC brought into industry.
This was compounded by the lack of inexpensive, high quality Ada compilers,
debuggers and tools on the PC.  As developers migrated from mainframe and
minicomputer development to PC development they didn't see Ada as a viable
alternative to the Pascal and C compilers that were available.

A similar change happened in the early 90's when developers migrated from
MS-DOS programming to Windows programming on the PC.  Again Ada was late to
the game in coming up with competitive compilers for Windows.  Again Ada was
ignored by most Windows developers.

Could it have been different?  I don't think so.  Any time any language is
mandated by law as opposed to being adopted as a defacto industry standard,
it is going to have an uphill struggle.

There seems to be a perception in this news group and in the Ada industry
that programming in Ada somehow makes your programs error proof.  Ada
certainly has features that make it less likely to program certain kind of
errors but you can certainly write bad code in Ada just as in any other
language.  Java purists would say that because Ada (and other languages)
allow pointers, programs developed with those languages are error prone.

There are still a lot of opportunities for Ada development out there.  I am
sure there is a lot of embedded systems work that is being done with it and
some commercial applications.  In these narrow areas you can certainly make
a living programming in Ada.  Ada development (done right) can also teach
you some wonderful things about resuability and modularity.  It isn't a
silver bullet.


Brijesh <brijesh.malkan@gecm.com> wrote in message
news:38620350.48F8FC08@gecm.com...
> I am fairly new to Ada programming and have a rather trivial question I
> was hoping the group could help answer.
>
> I understand Ada is a very powerful language but is not used much
> outside the defence industry, I was woderign if this is a correct
> assumption and if so why is this the case - and if not where else is it
> used.
>
> Thanks,
>
> Brij
>

Re: Ada

[Roger Racine]

On Thu, 23 Dec 1999 11:11:12 +0000, Brijesh <brijesh.malkan@gecm.com>
wrote:

>I am fairly new to Ada programming and have a rather trivial question I
>was hoping the group could help answer.
>
>I understand Ada is a very powerful language but is not used much
>outside the defence industry, I was woderign if this is a correct
>assumption and if so why is this the case - and if not where else is it
>used.
>
>Thanks,
>
>Brij
>

You actually have 2 questions, only 1 of which is trivial:

1) Is Ada used much outside the defence industry?

2) If not, why not; if so where?

1) Ada is not used "much" anywhere, inside or outside the military, if
you compare it with C.  It is, however, being used by "many"
organizations both within and outside the military.  This should be a
trivial question since the number is some finite countable positive
integer.  Unfortunately, I do not think anyone knows the exact number.

2) Ada is being used in communication systems (TopLayer is one
example), airplanes (Boeing), space systems (NASA), teaching,
compilers (ACT), etc.  The list is not small unless it is compared
with the equivalent list of C projects.

The hard part of your second question is "why not?"  There are so many
reasons, none of which are very "good" (which is why those of us who
still advocate its use are still doing so).  At the risk of getting
into another language war, here goes:

1) Control theory.  C is in a positive control loop; Ada is in a
negative loop.  C is popular.  Therefore people want C on their
resumes.  Therefore people want to do projects in C.  Therefore
companies provide tools for C development.  Therefore libraries for C
are written.  Ada is not popular.  Therefore people do not want Ada on
their resumes.  I know of people who have threatened to quit if they
were forced to use Ada, since they thought they were becoming
unwanted. 

2) Time to Market.  Ada is a readable language.  C is a writeable
language.  People think they are more productive using C because they
get to integration faster, and they might get a software system to
market sooner than with Ada.  Ada will allow people to find certain
errors more easily, but this is not perceived to be a significant
enough improvement, and for most commercial software, getting all the
bugs out is not necessary to getting a product out.

3) Philosophy.  I am treading on thin ice here, but there is possibly
an innate human trait to need recognition.  With C, you need gurus who
are great at finding the subtle problems.  These people are less
important in Ada projects, and therefore are less happy.  I will admit
that one of my current projects is being done in C, and we had a code
peer review the other day.  I found some very significant defects,
that probably would not have been found until very late in the
testing.  Everyone praised me for finding these defects, and I felt
very good.  The defects could not have existed in Ada.  Special
recognition in Ada projects has to come in other ways, and will
generally come to a different group of people, and possibly fewer.

4) First impressions last a long time.  The first impression many
people had with Ada was that the language had shortcomings for
real-time systems.  In fact, the Ada conferences and publications had
many articles on what was wrong with the language.  The compiler
vendors tried to provide ways to get around the problems, but then
code was not portable.  This left a very bad feeling in people who
used Ada 83.  They are not interested in even looking at Ada 95.

5) Tools.  Books, compilers, development environments, are all more
available and cheaper for C than for Ada.  I can go into a local
computer store and find Visual C++ for some small amount of money (I
have seen it, but have not bought it, so I do not remember the exact
amount).  To get an equivalent Ada development environment
(supported), I have to go to a vendor, and the cost will probably be
at least an order of magnitude more.  This brings one into economics.
If Visual C++ costs the same to produce as some Ada compiler, but 100
times more copies of Visual C++ are sold, what is the difference in
profit for Microsoft if they sell theirs for 1/10 the price?  It is
not trivial to answer this (since it depends on the cost of initial
development, the value of stock options, the cost of distribution, the
cost of lawyers, etc.), but it can be more profitable.

Does this help explain the current situation?  This is probably way
too simplistic.  I forgot to even mention the DoD mandate.

Roger Racine

Re: Ada

[Marin D. Condic]

Roger Racine wrote:
> 2) Time to Market.  Ada is a readable language.  C is a writeable
> language.  People think they are more productive using C because they
> get to integration faster, and they might get a software system to
> market sooner than with Ada.  Ada will allow people to find certain
> errors more easily, but this is not perceived to be a significant
> enough improvement, and for most commercial software, getting all the
> bugs out is not necessary to getting a product out.
> 
I beg to differ - sort of. In many systems Ada gets you to market sooner
with fewer problems. Assuming skilled programmers in each case. Where
C/C++ has an edge is in areas where you get tons of reusable libraries
with it, such as in Visual C++. But this is just one type of system
development. I've been playing with the CLAW GUI builder demo and found
that it will build Ada GUI programs quite easily, so it isn't as if Ada
*can't* do it - just that it isn't as easily marketed. If you got CLAW,
a compiler, a bunch of utilities (Similar to MFC? Where is the ACLWG
these days anyway?) manuals, tutorials, a book, a configuration
management system, etc. all in one package it might compete well in the
"Time To Market" field. All these things exist, but not as a single, one
stop shopping, package. (Maybe a teaming effort is needed?)


> 5) Tools.  Books, compilers, development environments, are all more
> available and cheaper for C than for Ada.  I can go into a local

Definitely. I was recently at a big electronics store in San Jose and
looked through their stacks of books relating to programming &
languages. Hundreds of books available on C, C++, Perl, Cobol, etc. Not
a single text on Ada, even though many good ones exist. It is sort of a
deadlock situation - The store doesn't want to stock something for which
there won't be a reasonable level of sales. The potential vendors don't
want to subsidize it because revenues are too thin to do so. The
potential users have little interest because it isn't just sitting right
there waiting for them to pick it up. The deadlock continues.

Now potentially, it would be possible for some of the vendors to get
together to produce an integrated package with each supplying some part
of the end product. A joint venture would spread the risk and might
bring sufficient resources to bear to actually put up a shrink-wrapped
package on a display rack on the floor of a few computer stores. Done
right with a sufficiently narrow focus, it could succeed and make
everyone a few bucks while making Ada a bit more prevalent. I'd
certainly be interested in discussing it... ;-)

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Richard D Riehle]

In article <38690E47.7DBDC2D1@quadruscorp.com>,
	"Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:

>> 5) Tools.  Books, compilers, development environments, are all more
>> available and cheaper for C than for Ada.  I can go into a local
>
>Definitely. I was recently at a big electronics store in San Jose and
>looked through their stacks of books relating to programming &
>languages. Hundreds of books available on C, C++, Perl, Cobol, etc. Not
>a single text on Ada, even though many good ones exist. It is sort of a
>deadlock situation - The store doesn't want to stock something for which
>there won't be a reasonable level of sales. The potential vendors don't
>want to subsidize it because revenues are too thin to do so. The
>potential users have little interest because it isn't just sitting right
>there waiting for them to pick it up. The deadlock continues.

Marin,

Sounds as if you were visiting Fry's Electronics, our local Silicon
Valley Computer Circus.  For serious literature on anything related
to computers, Fry's is not a good choice.  Instead, we have a local
bookstore, Computer Literacy Bookshops  (www.fatbran.com), which has
a representative selection of Ada books.  Next time you are looking
for computer books in Silicon Valley, don't go to Fry's.  Go to 
Computer Literacy Bookshops.  

BTW, many of us who buy computers and computer gear stay away from
Fry's.  I have had such bad experiences with their service that I will
not buy anything from them unless there is no choice.  There
are lots of good alternatives here is SV.  Next time you are in 
SV, give me a call and I will direct you to some better options. 

Richard Riehle

Re: Ada

[Marin D. Condic]

Richard D Riehle wrote:
> Marin,
> 
> Sounds as if you were visiting Fry's Electronics, our local Silicon
> Valley Computer Circus.  For serious literature on anything related
> to computers, Fry's is not a good choice.  Instead, we have a local
> bookstore, Computer Literacy Bookshops  (www.fatbran.com), which has
> a representative selection of Ada books.  Next time you are looking
> for computer books in Silicon Valley, don't go to Fry's.  Go to
> Computer Literacy Bookshops.
> 
Yes, that's where I was looking. They gave off the impression of being
sort of the "Home Depot" of electronics stores. Maybe their selection is
not the best, but they seemed to be sort of "Computer Stuff For The
Masses". The books may not have beem the "serious" computer literature
you have in mind, but they did have lots of shelves of stuff aimed at
helping folks at a variety of levels to learn different languages/tools.

My only point was that for Ada to improve its market position, it needs
to be presented to "The Masses" in a way that makes it easy to adopt and
use. That's why I think a whole shrink-wrapped kit for the PC/Windows
environment would be a good idea.

MDC

-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Robert Dewar]

In article <386F7856.26134B3E@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> My only point was that for Ada to improve its market position,
> it needs to be presented to "The Masses" in a way that makes
> it easy to adopt and use. That's why I think a whole
> shrink-wrapped kit for the PC/Windows
> environment would be a good idea.

So .. don't stop at making the suggestion that "someone" (*)
do this, instead take the initiative to do it yourself. All
the ingrediants are there. You can certainly build what you
want from the public version of GNAT. Of course getting shelf
space at Fry's is a totally different kettle of fish :-)

(*) someone -- that elusive person to whom many tasks are
assigned, but who seldom follows through, and in fact is
rather hard to track down :-) :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Marin D. Condic]

Robert Dewar wrote:
> So .. don't stop at making the suggestion that "someone" (*)
> do this, instead take the initiative to do it yourself. All
> the ingrediants are there. You can certainly build what you
> want from the public version of GNAT. Of course getting shelf
> space at Fry's is a totally different kettle of fish :-)

Yup. Shelf space at Fry's (or COMPUSA, etc.) might be an issue - but it
might be resolvable fairly easily with a few phone calls if the "right"
product is available, or at least planned. The notion I had in mind
would involve more than a version of GNAT - there would need to be a
bunch of other things in the kit, some of which might not be so readily
available. Thats why I think it would take a coordinated effort of a few
vendors to put together a comprehensive package and a marketing
strategy. What I might be able to bring to the table at this juncture is
TBD.

> 
> (*) someone -- that elusive person to whom many tasks are
> assigned, but who seldom follows through, and in fact is
> rather hard to track down :-) :-)

I'm very familiar with "someone" and frequently get frustrated with his
inability to keep to my schedule. ;-) Perhaps if I were to get him that
very expensive and rare device known as A Round Tuit he might be able to
make faster progress :-)

MDC
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Ted Dennison]

"Marin D. Condic" wrote:

> Yup. Shelf space at Fry's (or COMPUSA, etc.) might be an issue - but it
> might be resolvable fairly easily with a few phone calls if the "right"

My understanding was that stores like that tend to have sort of a
supermarket-style approach to shelf space. That means you aren't going to
get them to give you shelf space for free.

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: Ada

[Robert Dewar]

In article <386F9D7E.B6DD06B9@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:

> Thats why I think it would take a coordinated effort of a few
> vendors to put together a comprehensive package and a
> marketing strategy.

This won't happen if you wait for vendors to do it, because they
won't be convinced it makes any marketing sense (I am certainly
dubious).

But on the other hand, all the tools and components you need
are out there in open source form, so you or someone else can
certainly put everything together without needing to wait for
the vendors to move.

Part of the reason I think this makes less sense than you
think is that these days students and other likely consumers
of such a package expect to pay $0 for it, and are not about
to go and plunk down a credit card at Fry's or anywhere else
to buy a package of this kind!

Note also that there are some attempts to do something like
what you suggest, for example, the University of Brighton
CD ROM.

But if you do want to create something, I think the delivery
HAS to be free and electronic. I don't think you will get
anywhere
with a shrink wrapped box at Fry's.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Marin D. Condic]

Robert Dewar wrote:
> Part of the reason I think this makes less sense than you
> think is that these days students and other likely consumers
> of such a package expect to pay $0 for it, and are not about
> to go and plunk down a credit card at Fry's or anywhere else
> to buy a package of this kind!
> 
You may be right. The only way to really settle the question is to
attempt to do it and see if it sells. That can be pretty expensive. But
do keep in mind that Micro$oft is out there selling shrink-wrapped
versions of Visual C++, etc. and people *do* plunk down credit cards to
buy that.

One can debate how profitable this might be - MS may be subsidizing
their development environment in order to keep development for Windows
going on. Its hard to say without a look at the books and I wouldn't
trust rumors or corporate statements on the subject. But certainly
people do buy VC++ so why might they not buy a *better* environment that
was wrapped around an Ada compiler?


> But if you do want to create something, I think the delivery
> HAS to be free and electronic. I don't think you will get
> anywhere
> with a shrink wrapped box at Fry's.
> 
I wouldn't write off electronic delivery - e-commerce is certainly
booming in growth right now. Fry's may have to go that route themselves
just to stay in business. But remember that when you go into Fry's you
will see development kits for other languages there on the shelves.
Somebody must be making a buck doing that - is there a reason that Ada
can't be one of those players? And a big advantage to being on a shelf
in a computer store is that people who may never have had any knowlege
or interest in Ada might happen to see it and be intrigued enough to try
it out.

My desire is to see that Ada experiences growth in its application for
commercial efforts. I think that is a goal most of us in this newsgroup
would agree on. I think that a weakness Ada has when compared to some
other languages is that there isn't a one-stop source where you can pick
up everything you need for serious development. There are lots of things
you can gather from all over the net and possibly cobble together a
development environment with everything you need. If your garden variety
developer were able to get the whole ball of wax in one location with
everything glued together in a consistent manner, it might encourage
more use.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Roger Racine]

On Mon, 03 Jan 2000 09:39:57 -0800, "Marin D. Condic"
<mcondic-nospam@quadruscorp.com> wrote:

>Robert Dewar wrote:
>> Part of the reason I think this makes less sense than you
>> think is that these days students and other likely consumers
>> of such a package expect to pay $0 for it, and are not about
>> to go and plunk down a credit card at Fry's or anywhere else
>> to buy a package of this kind!
>> 
>You may be right. The only way to really settle the question is to
>attempt to do it and see if it sells. That can be pretty expensive. But
>do keep in mind that Micro$oft is out there selling shrink-wrapped
>versions of Visual C++, etc. and people *do* plunk down credit cards to
>buy that.
>
>
>My desire is to see that Ada experiences growth in its application for
>commercial efforts. I think that is a goal most of us in this newsgroup
>would agree on. I think that a weakness Ada has when compared to some
>other languages is that there isn't a one-stop source where you can pick
>up everything you need for serious development. There are lots of things
>you can gather from all over the net and possibly cobble together a
>development environment with everything you need. If your garden variety
>developer were able to get the whole ball of wax in one location with
>everything glued together in a consistent manner, it might encourage
>more use.
>

I went to the local CompUSA store over the weekend and noticed that
Corel is now selling WordPerfect in a box that includes Linux.
Perhaps an Ada development environment combined with the operating
system might be popular enough to create a profit?

Maybe a cross-development system for the Palm Pilot included?

Roger Racine

Re: Ada

[Larry Kilgallen]

In article <3870DEED.4744AE18@quadruscorp.com>, "Marin D. Condic" <mcondic-nospam@quadruscorp.com> writes:
> Robert Dewar wrote:
>> Part of the reason I think this makes less sense than you
>> think is that these days students and other likely consumers
>> of such a package expect to pay $0 for it, and are not about
>> to go and plunk down a credit card at Fry's or anywhere else
>> to buy a package of this kind!
>> 
> You may be right. The only way to really settle the question is to
> attempt to do it and see if it sells. That can be pretty expensive. But
> do keep in mind that Micro$oft is out there selling shrink-wrapped
> versions of Visual C++, etc. and people *do* plunk down credit cards to
> buy that.

For a point of reference, the per-copy cost of commercial CD
pressing is about $1 from a big vendor to a small customer.
That is after a setup charge of about $500.

> Somebody must be making a buck doing that - is there a reason that Ada
> can't be one of those players? And a big advantage to being on a shelf
> in a computer store is that people who may never have had any knowlege
> or interest in Ada might happen to see it and be intrigued enough to try
> it out.

Do not underestimate the value of attractive packaging at generating
sales. Lots of trash gets sold in various fields through the use of
attractive packaging -- there is no reason to skimp just because the
contents happen to be worthwhile.

If it is a boxed product, be sure to include a printed manual.
When I examine sealed boxes wondering about documentation, I
often judge by weight :-)

This does seem to be the sort of opportunity open-source software
was designed for -- the add-on value provided by promoting retail
sales is just way outside the sphere of developing software in the
first place.  If the retail package should become so overpriced as
to be offensive, competitors will enter the market.

Larry Kilgallen

Re: Ada

[Charles Hixson]

OTOH, on-line distributors, such as, e.g., Cheap-Bytes , PC-Connection, or EggHead sell items that don't
require the same concerns as the open store front.  Perhaps the packaging should be designed to look good from
a face-forward perspective, and to sell via on-line distribution, but with the ability to take advantage of
any store-front access that becomes available (without drastically raising the cost of distribution!)

Larry Kilgallen wrote:

> In article <3870DEED.4744AE18@quadruscorp.com>, "Marin D. Condic" <mcondic-nospam@quadruscorp.com> writes:
> > Robert Dewar wrote:
> ......

> > or interest in Ada might happen to see it and be intrigued enough to try
> > it out.
>
> Do not underestimate the value of attractive packaging at generating
> sales. Lots of trash gets sold in various fields through the use of
> attractive packaging -- there is no reason to skimp just because the
> contents happen to be worthwhile.
>
> If it is a boxed product, be sure to include a printed manual.
> When I examine sealed boxes wondering about documentation, I
> often judge by weight :-)
>
> This does seem to be the sort of opportunity open-source software
> was designed for -- the add-on value provided by promoting retail
> sales is just way outside the sphere of developing software in the
> first place.  If the retail package should become so overpriced as
> to be offensive, competitors will enter the market.
>
> Larry Kilgallen

Re: Ada

[Magnus Alexandersson]

"Marin D. Condic" wrote:
 
> Definitely. I was recently at a big electronics store in San Jose and
> looked through their stacks of books relating to programming &
> languages. Hundreds of books available on C, C++, Perl, Cobol, etc. Not
> a single text on Ada, even though many good ones exist. 

My school is dropping Ada for Java since the Ada books are hiedously
expensive here in Sweden and Javabooks come by the tenfold...

Reality bites, huh?

- 
///Magnus

http://www.mdtsud.chalmers.se/~md8maal

Re: Ada

[Tarjei T. Jensen]

Magnus Alexandersson wrote:
>My school is dropping Ada for Java since the Ada books are hiedously
>expensive here in Sweden and Javabooks come by the tenfold...


Are the students time worthless? 


Greetings,

Re: Ada

[Larry Kilgallen]

In article <85mpvr$mm42@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:
> 
> Magnus Alexandersson wrote:
>>My school is dropping Ada for Java since the Ada books are hiedously
>>expensive here in Sweden and Javabooks come by the tenfold...
> 
> 
> Are the students time worthless? 

Perhaps even more money could be saved by changing the course to teach
them how to program Excel spreadsheets.

Larry Kilgallen

Re: Ada

[Marin D. Condic]

Larry Kilgallen wrote:
> 
> In article <85mpvr$mm42@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:
> >
> > Magnus Alexandersson wrote:
> >>My school is dropping Ada for Java since the Ada books are hiedously
> >>expensive here in Sweden and Javabooks come by the tenfold...
> >
> >
> > Are the students time worthless?
> 
> Perhaps even more money could be saved by changing the course to teach
> them how to program Excel spreadsheets.
> 
Or let's just teach them how to use Notepad because it comes free with
Windows, has on-line documentation and is so simple that the students
wouldn't need to waste time even reading it. (Tongue firmly planted in
cheek)

Seriously: From what I've seen of Ada books, they aren't hugely out of
line with respect to price from books on other computer topics. College
level texts I've seen in the last couple of years on other topics have
been even more spendy than any of the Ada books I've purchased. The
largest cost of college is tuition. Why structure college courses around
the cost of books? (Maybe they could hire less expensive instructors?)

If I were Dean of the Computer Science department, I'd be more
interested in building a curriculum that presented important concepts in
the subject rather than picking topics because of current industry fads
or the cost of texts. But that's just me.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Magnus Alexandersson]

"Marin D. Condic" wrote:

> Seriously: From what I've seen of Ada books, they aren't hugely out of
> line with respect to price from books on other computer topics. College
> level texts I've seen in the last couple of years on other topics have
> been even more spendy than any of the Ada books I've purchased. The
> largest cost of college is tuition. Why structure college courses around
> the cost of books? (Maybe they could hire less expensive instructors?)

Our dean says that there aren't many books out there that meets the
desired content of the
courses... Well, I believe that it's programming as a general thing to
study, not the language. On the other hand, since I learnt Ada, I've now
noticed how easy (;p) C became.
 
> If I were Dean of the Computer Science department, I'd be more
> interested in building a curriculum that presented important concepts in
> the subject rather than picking topics because of current industry fads
> or the cost of texts. But that's just me.

We are doing that now, learning the way of programming... Not just the
languagepart, se above.

-- 
///Magnus

http://www.mdtsud.chalmers.se/~md8maal

Re: Ada

[Marin D. Condic]

Magnus Alexandersson wrote:
> 
> Our dean says that there aren't many books out there that meets the
> desired content of the
> courses... Well, I believe that it's programming as a general thing to
> study, not the language. On the other hand, since I learnt Ada, I've now
> noticed how easy (;p) C became.
> 
I'm presuming that language may be an issue in the texts selected, so
that may be a limiting factor. There are a number of books available in
English at least which will address Ada itself as well as Ada in
specific application domains. You might look at the "books" section of
http://www.AdaPower.com/ for a few references.

If you've learned how to program better C code from having studied Ada,
then you have definitely learned something valuable. One reason for
studying languages like Ada is to understand concepts which may be
possible in other languages, but are not as directly supported.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Magnus Alexandersson]

"Marin D. Condic" wrote:
 
> Definitely. I was recently at a big electronics store in San Jose and
> looked through their stacks of books relating to programming &
> languages. Hundreds of books available on C, C++, Perl, Cobol, etc. Not
> a single text on Ada, even though many good ones exist. 

My school is dropping Ada for Java since the Ada books are hiedously
expensive here in Sweden and Javabooks come by the tenfold...

Reality bites, huh?"Marin D. Condic" wrote:
> 
> Roger Racine wrote:
> > 2) Time to Market.  Ada is a readable language.  C is a writeable
> > language.  People think they are more productive using C because they
> > get to integration faster, and they might get a software system to
> > market sooner than with Ada.  Ada will allow people to find certain
> > errors more easily, but this is not perceived to be a significant
> > enough improvement, and for most commercial software, getting all the
> > bugs out is not necessary to getting a product out.
> >
> I beg to differ - sort of. In many systems Ada gets you to market sooner
> with fewer problems. Assuming skilled programmers in each case. Where
> C/C++ has an edge is in areas where you get tons of reusable libraries
> with it, such as in Visual C++. But this is just one type of system
> development. I've been playing with the CLAW GUI builder demo and found
> that it will build Ada GUI programs quite easily, so it isn't as if Ada
> *can't* do it - just that it isn't as easily marketed. If you got CLAW,
> a compiler, a bunch of utilities (Similar to MFC? Where is the ACLWG
> these days anyway?) manuals, tutorials, a book, a configuration
> management system, etc. all in one package it might compete well in the
> "Time To Market" field. All these things exist, but not as a single, one
> stop shopping, package. (Maybe a teaming effort is needed?)
> 
> > 5) Tools.  Books, compilers, development environments, are all more
> > available and cheaper for C than for Ada.  I can go into a local
> 
> Definitely. I was recently at a big electronics store in San Jose and
> looked through their stacks of books relating to programming &
> languages. Hundreds of books available on C, C++, Perl, Cobol, etc. Not
> a single text on Ada, even though many good ones exist. It is sort of a
> deadlock situation - The store doesn't want to stock something for which
> there won't be a reasonable level of sales. The potential vendors don't
> want to subsidize it because revenues are too thin to do so. The
> potential users have little interest because it isn't just sitting right
> there waiting for them to pick it up. The deadlock continues.
> 
> Now potentially, it would be possible for some of the vendors to get
> together to produce an integrated package with each supplying some part
> of the end product. A joint venture would spread the risk and might
> bring sufficient resources to bear to actually put up a shrink-wrapped
> package on a display rack on the floor of a few computer stores. Done
> right with a sufficiently narrow focus, it could succeed and make
> everyone a few bucks while making Ada a bit more prevalent. I'd
> certainly be interested in discussing it... ;-)
> 
> MDC
> --
> =============================================================
> Marin David Condic   - Quadrus Corporation -   1.800.555.3393
> 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
> http://www.quadruscorp.com/
> m c o n d i c @ q u a d r u s c o r p . c o m
> 
> Visit my web site at:  http://www.mcondic.com/
> 
> "Capitalism without failure is like religion without sin."
>         --  Allan Meltzer, Economist
> =============================================================


-- 
///Magnus

http://www.mdtsud.chalmers.se/~md8maal

Re: Ada

[Robert Dewar]

In article <38620350.48F8FC08@gecm.com>,
  Brijesh <brijesh.malkan@gecm.com> wrote:
> I understand Ada is a very powerful language but is not used
much
> outside the defence industry, I was woderign if this is a
correct
> assumption and if so why is this the case - and if not where
else is it
> used.
>
> Thanks,


Never believe such rumours, they are almost always wrong. It
is interesting that there is a whole series of technologies that
has important current applications, but which conventional
wisdom pronounces dead (examples, APL, OS/2, Pascal, PL/1, and
yes, Ada :-)

Ada has many non-DoD applications, go to www.adapower.com to
follow up on more information, but here are some examples:

Train switching systems (soon to be adopted by the NY subway)
Internet switches
Medical equipment
Commercial airplaces (ever flown on a 777 - it's an all Ada
plane)
Cable TV (Canal Plus in Europe)
Air Traffic Control Systems
Eurospace
Banking applications
etc.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[tmoran]

>Ada has many non-DoD applications, go to www.adapower.com to
>follow up on more information, but here are some examples:
>...
>etc.
  One etc I know about is stocks and commodities databases for
speculators, er, investors.  All databases, and the daily data,
have errors, which show up as oddballs on graphs, or, worse,
screw up technical analysis algorithms.  A system I worked on
used Ada to help cleaning and merging data.  It was useful as a
good language to help avoid introducing new errors, the
run-time error checking helped catch unexpected errors, and
tasking let it easily display questionable data to a human
asynchronously with scanning the data.  This was about 5 years
ago, at the beginning of the present on-line trading craze.

Re: Ada

[reason67]

In article <38620350.48F8FC08@gecm.com>,
  Brijesh <brijesh.malkan@gecm.com> wrote:
> I am fairly new to Ada programming and have a rather trivial question
I
> was hoping the group could help answer.
>
> I understand Ada is a very powerful language but is not used much
> outside the defence industry, I was woderign if this is a correct
> assumption and if so why is this the case - and if not where else is
it
> used.

In the USA around 1% of comercial software was written in Ada. So, your
assumption is correct.

I don't think anyone knows the reasons for sure. My personal speculation
is economic. Until fairly recently Ada compilers were very expensive
compared to C. When you buya Unix platform you got C for free with it.
(This is also why FORTRAN was so popular as it was free on old IBM
Mainfraims).

I do not have a crystal ball, but Ada could pick up. From the recent
expansion of Parallel Virtual Machine architectures, I think parallel
computing is going to be really big in a few years. The Ada runtime
could be modified to support PVM or other methods, so you could easily
port code from a 1000 machine cluster to a 5 machine cluster.

I do not know if anyone is working on this currently. After the
Holidays, I planned on looking at writing a binding to PVM for gnat 3.12
on Linux. If successful I wanted to look into using PVM as the tasking
model (instead of pthreads), but I have done almost no research at this
time.

IF Ada can be successfully merged with this new clusters, then Ada has a
real shot at being much bigger in the USA. Esp. if people
start writing parallel virtual machine libraries in Ada as
well.

Unfortunately, if I was just starting out, I would not look into Ada for
a long term career in the USA. I think I would look much more heavily
into C++.
---
Jeffrey Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Robert Dewar]

In article <83tohh$q2s$1@nnrp1.deja.com>,
  reason67@my-deja.com wrote:
> In article <38620350.48F8FC08@gecm.com>,
>   Brijesh <brijesh.malkan@gecm.com> wrote:
> > I am fairly new to Ada programming and have a rather trivial
question
> I
> > was hoping the group could help answer.
> >
> > I understand Ada is a very powerful language but is not used
much
> > outside the defence industry, I was woderign if this is a
correct
> > assumption and if so why is this the case - and if not where
else is
> it
> > used.
>
> In the USA around 1% of comercial software was written in Ada.
So, your
> assumption is correct.


I wonder where that figure of 1% comes from. If true, it means
that Ada is widely used, since this is 1% of an absolutely HUGE
market (1% is much higher than you think, once you have
subtracted out the really popular languages like COBOL and
Visual Basic, the latter accounting for the lion's share of
all software development).

In fact I suspect the figure is below 1%, but again, we are
talking percentages of a huge market, so even a sliver of this
can be highly significant. After all what percentage of the
over all automobile market does Ferrari have or Rolls Royce,
yet we still consider these technologies significant :-)

Certainly we all know lots of examples of successful commercial
use of Ada.

There seems to be a general tendency to write off technologies
that do not dominate the market. I can't tell you how many
people I meet who think OS/2 is dead, when in fact it is being
very successful in many contexts (and has exceeded sales
expectations every quarter for the last 5 or 6 quarters). Sure
it does not have the market share of Windows, but this again is
a huge market, and OS/2 has a significant share.

A similar situation exists with Ada. Of course it is not
numerically as successful as C++ for example, but that really
does not mean much. If you need the most reliable and best
technology around, you do not take a poll to see what is the
most commonly used technology!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Terry Sikes]

In article <83u8l0$5i5$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
>In article <83tohh$q2s$1@nnrp1.deja.com>,
>  reason67@my-deja.com wrote:
>> In article <38620350.48F8FC08@gecm.com>,
>>   Brijesh <brijesh.malkan@gecm.com> wrote:
>>> I am fairly new to Ada programming and have a rather trivial
>>> question I was hoping the group could help answer.
>>>
>>> I understand Ada is a very powerful language but is not
>>> used much outside the defence industry, I was woderign if
>>> this is a correct assumption and if so why is this the
>>> case - and if not where else is it used.
>>
>> In the USA around 1% of comercial software was written in Ada.
>> So, your assumption is correct.
>
>I wonder where that figure of 1% comes from. If true, it means
>that Ada is widely used, since this is 1% of an absolutely HUGE
>market (1% is much higher than you think, once you have
>subtracted out the really popular languages like COBOL and
>Visual Basic, the latter accounting for the lion's share of
>all software development).

I'm curious as to the source of your assertion regarding Visual Basic.
For one look at "per language" programmer demand, see
www.lmarkets.com, which seems to show both C++ and Java considerably
ahead of VB (of course this is programmer demand, not programmer body
count).  Perhaps someone should lobby the site maintainer to include
Ada on the chart, even if it is a low scorer today - perhaps a
positive trend will start at some point.

>In fact I suspect the figure is below 1%, but again, we are
>talking percentages of a huge market, so even a sliver of this
>can be highly significant. After all what percentage of the
>over all automobile market does Ferrari have or Rolls Royce,
>yet we still consider these technologies significant :-)
>
>Certainly we all know lots of examples of successful commercial
>use of Ada.

True.

>There seems to be a general tendency to write off technologies
>that do not dominate the market. I can't tell you how many
>people I meet who think OS/2 is dead, when in fact it is being
>very successful in many contexts (and has exceeded sales
>expectations every quarter for the last 5 or 6 quarters). Sure
>it does not have the market share of Windows, but this again is
>a huge market, and OS/2 has a significant share.

Yes, I think this is a quite unfortunate effect of the amount of
information the average programmer intellect can absorb over time.
Personally, I decided to pursue other languages years ago when Ada
compilers were all really expensive, and its use appeared to be
declining even in the DoD.  Now, with free compilers available, an OO
programming model available (Ada95), and an upcoming RT control
application in my future, Ada is looking very interesting all of a
sudden.  ;-)

>A similar situation exists with Ada. Of course it is not
>numerically as successful as C++ for example, but that really
>does not mean much. If you need the most reliable and best
>technology around, you do not take a poll to see what is the
>most commonly used technology!

Again true, but I can't help but think that wider adoption would be a
very good thing for the language.  Many projects may have gone with
other technologies simply based on the available Ada talent pool.

I've been involved with Java for a while, and it appears to me that
with suitable library support Ada could be a great alternative for (at
least) server side programming.  (IIRC there is an Ada=>JVM solution,
but I don't know much about it.)

There's a lot of discussion on the Java advocacy newsgroup about the
desirability (or lack thereof;) of generics, operator overloading and
so on.  From what I can tell, Ada provides good implementations of
these things as opposed to C++.  Also, the scientific community has
shown significant interest in a modified Java for numerical
programming (www.javagrande.org), that also seems potentially a
fertile ground for Ada advocacy.  Heck, Ada is even an ISO standard...
;-)

Looking at Ada95, it seems to me to be close to a "sweet spot" in
terms of features, efficiency, language safety, and
performance...perhaps its time for an Ada renaissance!

Terry
--
tsikes@netcom.com

Re: Ada

[Hyman Rosen]

tsikes@netcom.com (Terry Sikes) writes:
> There's a lot of discussion on the Java advocacy newsgroup about the
> desirability (or lack thereof;) of generics, operator overloading and
> so on.  From what I can tell, Ada provides good implementations of
> these things as opposed to C++.

C++ provides excellent implementation of generics,
and good implementation of overloading, except that
one cannot overload on return type as in Ada.

Is there something specific you believe you can not
do in C++ with regard to these abilities?

Re: Ada

[Florian Weimer]

Hyman Rosen <hymie@prolifics.com> writes:

[Ada generics vs. C++ templates]

> Is there something specific you believe you can not
> do in C++ with regard to these abilities?

I can't imagine anything which can't be done with C++ templates which
you can do using Ada generics.  (The opposite case is different, though,
because of Ada's strong typing.)  However, there are some shortcomings
of C++ templates (at least that's my impression):

You won't get reasonable error messages.  For example, try instantiating
a STL container with a reference type; most compilers will give you
several kilobytes of error messages.  The situation gets worse if you
nest templates more deeply.

Writing reusable templates in C++ is hard, because you have to be very
careful not to use operations on the parametric types which aren't
available in general.  These restrictions are not enforced by the
compiler unless you provide suitable instantiations.

Re: Ada

[Brian Rogoff]

On 4 Jan 2000, Florian Weimer wrote:
> Hyman Rosen <hymie@prolifics.com> writes:
> 
> [Ada generics vs. C++ templates]
> 
> > Is there something specific you believe you can not
> > do in C++ with regard to these abilities?
> 
> I can't imagine anything which can't be done with C++ templates which
> you can do using Ada generics. 

In some theoretical sense, yes, since you can express computations with 
C++ templates they can do just about anything. C++ type checking is also 
undecidable thanks to this. 

In the world of the practical programmer, Ada allows subprograms as
generic parameters and since Ada has nesting you can use them to 
clumsily simulate many uses of downward closures. C++ forces you to use 
classes and overload "()", and that is IMO *way* more clumsy than the 
Ada workaround. 

Others have discussed strong typing and separate compilation, so I'll
leave those points alone. What I like most about Ada is the confidence 
I have that a small compiled program is close to correct in my experience.

I like some aspects of the C++ template systems ability to automatically 
instantiate, and would love to see an Ada-like language with this ability. 
I suspect that this might also not have a decidable type system. 

-- Brian

Re: Ada

[Hyman Rosen]

Florian Weimer <usenet@deneb.cygnus.argh.org> writes:
> You won't get reasonable error messages.  For example, try instantiating
> a STL container with a reference type; most compilers will give you
> several kilobytes of error messages.  The situation gets worse if you
> nest templates more deeply.

This is a quality-of-implementation issue. I think vendors are
concentrating first on compiling correct code. One hopes that
in the future, error messages will get better.

> Writing reusable templates in C++ is hard, because you have to be very
> careful not to use operations on the parametric types which aren't
> available in general.  These restrictions are not enforced by the
> compiler unless you provide suitable instantiations.

"If the type will fit, you must acquit" :-) The C++ template model
allows legal instantiations to compile, without specifying
restrictions on the types in advance, only through the operations
performed on the objects of the type. This requires attention in
writing the template if you want to minimize the number of things
required of the type, but that's fine.

Re: Ada

[Robert Dewar]

In article <t7aemmtz3b.fsf@calumny.jyacc.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:

> C++ provides excellent implementation of generics,

The trouble with templates is that there is no equivalent of
the generic contract model, and also it is very difficult to
implement generic sharing of code. These are both issues
which the Ada model regards as essential, so certainly
by Ada standards, the above statement is controversial.


> and good implementation of overloading

OUCH! The rules for overloading in C++ are fiersomely complex,
far more so than in Ada, due to the interaction with implicit
conversions (something that Ada avoids), and the consequent
need for complex preference rules. In my experience, almost
no C++ programmers can tell you what the rules are, and many
people run into trouble with these rules.

> except that
> one cannot overload on return type as in Ada.

A pretty big gap! It means for example that if you have
multiple implementations of sets, that you cannot have
a parameterless function Empty that returns the (appropriate)
empty set.

> Is there something specific you believe you can not
> do in C++ with regard to these abilities?

Yes, see the above, in particular, to summarize:

1. Share generic code at the object level
2. Be sure your template is correct *before* you use it
3. Understand the overloading rules
4. Overload on return type


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Hyman Rosen]

Robert Dewar <robert_dewar@my-deja.com> writes:
> A pretty big gap! It means for example that if you have
> multiple implementations of sets, that you cannot have
> a parameterless function Empty that returns the (appropriate)
> empty set.

Incorrect as far as equivalent behavior is concerned,
as the following program demonstrates.

enum SetType { A, B, C };
template <SetType T> struct Set
{
	static Set Empty() { return Set(); }
};
struct EmptySet
{
	template <SetType T> operator Set<T>() { return Set<T>::Empty(); }
};
void f(Set<A>) { }
void g(Set<B>) { }
int main()
{
	f(EmptySet());
	g(EmptySet());
}

Re: Ada

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> A pretty big gap! 

Yes.

>...It means for example that if you have
> multiple implementations of sets, that you cannot have
> a parameterless function Empty that returns the (appropriate)
> empty set.

Even worse, it means that literals can't be overloaded.  Of course, C++
doesn't even *have* enumeration literals of different enumeration types,
anyway.  And for numeric literals, the C++ rule requires that each
literal be marked with a character that indicates its type, which is a
kludge (and certainly wouldn't work in Ada with tits capability of
having many numeric types).

- Bob

Re: Ada

[Hyman Rosen]

Robert A Duff <bobduff@world.std.com> writes:
> Even worse, it means that literals can't be overloaded.  Of course, C++
> doesn't even *have* enumeration literals of different enumeration types,
> anyway.

It certainly does. The problematic part is that enumeration literals
are entered into the scope in which the enumeration type is declared,
because of backward compatibility with C. As a result, one normally
declares enumerated types inside a class or namespace, so that literals
won't conflict.

If you really need enumerator literal overloading, you can play the
same game as for empty sets, on a case-by-case basis:

struct Direction { enum E { Left, Right, Up, Down }; };
struct Politics  { enum E { Left, Center, Right }; };

static struct
{
	operator Direction::E() { return Direction::Left; }
	operator Politics ::E() { return Politics ::Left; }
} Left;

static struct
{
	operator Direction::E() { return Direction::Right; }
	operator Politics ::E() { return Politics ::Right; }
} Right;

void f(Direction::E) { }
void g(Politics ::E) { }

int main()
{
	f(Left);
	f(Right);
	g(Left);
	g(Right);
}

Re: Ada

[Terry Sikes]

In article <t7aemmtz3b.fsf@calumny.jyacc.com>,
Hyman Rosen  <hymie@prolifics.com> wrote:
>tsikes@netcom.com (Terry Sikes) writes:

>> There's a lot of discussion on the Java advocacy newsgroup about the
>> desirability (or lack thereof;) of generics, operator overloading and
>> so on.  From what I can tell, Ada provides good implementations of
>> these things as opposed to C++.
>
>C++ provides excellent implementation of generics,
>and good implementation of overloading, except that
>one cannot overload on return type as in Ada.

I've perused the other responses to this so I won't touch on some
points raised by others.  In working fairly extensively with C++
generics (mainly STL, VC 6.0) I've come to the conclusion that at this
time they are still totally pushing the envelope for the compiler
writers.  In my current project, for instance, fairly simple things
like map<int, string> generate identifiers in excess of 255
characters, which the compiler warns about truncating.  There is a
pragma to disable this warning for the current file, but often this
warning occurs in system headers, which I'm reluctant to modify.  ;-)
I also find it troublesome that such simple cases introduce possible
software defects, which I'm being warned about, with no way of fixing
the problem other than abandoning generics.

Further the error messages generated for template errors are quite
bad.  In one case I tested an iterator using "<" rather than "!=" and
was greeted with a cascade of seemingly unrelated messages.  Careful
code inspection was the only way to find the problem.

Finally, I find the syntax of C++ templates rather illegible, but
perhaps that's just me.

>Is there something specific you believe you can not
>do in C++ with regard to these abilities?

Its not so much a matter of "can not do" as "can not do quickly", "can
not identify the error" and/or "can not read later".  ;-)

On the latter point, between operator overloading and templates, it is
quite easy to (unintentionally) generate very obtuse C++.

One thing I'd like to see in both languages is the ability to use a
set of non-reserved Unicode symbols for operator overloading, to
disambiguate with the normal operator symbols.

Terry
--
tsikes@netcom.com

Operators -> unit analysis

[Charles Hixson]

Terry Sikes wrote:

> ...
> One thing I'd like to see in both languages is the ability to use a
> set of non-reserved Unicode symbols for operator overloading, to
> disambiguate with the normal operator symbols.
>
> Terry
> --
> tsikes@netcom.com

I don't insist on unicode, but I would also like more operators that could
be overloaded.  How about swiping a leaf from Fortran60 (.le., .eq., ...)
and allowing symbols beginning with a (e.g.) period, then a string of chars
between succ (" ") and char (126) and then another period, with white space
separations  required on each side, to be an overloadable operator?

And some good way to handle units.  So that we could safely say things like:

     speed := 37.miles / 1.5.hours;
I'm not too pleased with the syntax, but the idea is there.  Computer
languages should make unit analysis easy!  This is one of the "promises" of
abstract data types, but I don't feel that it's been truly fulfilled,
largely because it's too difficult to use.  Syntax is part of the problem,
and standard libraries are another part (or perhaps that one's been solved,
and I just don't know).  But standard types should be defined for all the
standard metric units, and most of the more common English units, with
conversion functions between them.  I guess that the standard example
package, Rational, is a good example of how it could be done, but there is
lots of detail work, and it needs to be standardized.

If there is a work group on this, I would like to know about it.  The recent
Mars probe again brought this to my attention.  They may not have been using
Ada (I didn't bother to check), but avoiding this kind of problem is
something that Ada should be for.

I dislike the syntax:
    speed := (37 * mile) / (1.5 * hour);
though I prefer it to:
    speed := miles (37) / hours (1.5);
but that's the best that I know how to do it in Ada.  Is there a better
choice?  (I.e. one that would look more like what a math student would write
in a word problem?)

Of course one could say:
    dist    :    constant Miles    :=    37;
    time   :    constant Hours    :=   1.5;
    speed :  MpH;
    speed    :=    dist / time;

but that seems quite unnecessarily verbose!

Re: Operators -> unit analysis

[Matthew Heaney]

In article <387383D0.4EA02E95@earthlink.net> , Charles Hixson 
<charleshixsn@earthlink.net>  wrote:

> And some good way to handle units.  So that we could safely say things like:
>
>      speed := 37.miles / 1.5.hours;
> I'm not too pleased with the syntax, but the idea is there.

You can already do this:

  Speed := Miles'(37.0) / Hours'(1.5);

I always recommend type qualification for literals when units are an
issue.

> I dislike the syntax:
>     speed := (37 * mile) / (1.5 * hour);
> though I prefer it to:
>     speed := miles (37) / hours (1.5);
> but that's the best that I know how to do it in Ada.  Is there a better
> choice?  (I.e. one that would look more like what a math student would write
> in a word problem?)

See above.


> Of course one could say:
>     dist    :    constant Miles    :=    37;
>     time   :    constant Hours    :=   1.5;
>     speed :  MpH;
>     speed    :=    dist / time;
>
> but that seems quite unnecessarily verbose!

Agreed.

Re: Operators -> unit analysis

[Charles Hixson]

Matthew Heaney wrote:

> ...

> You can already do this:
>
>   Speed := Miles'(37.0) / Hours'(1.5);
>
> I always recommend type qualification for literals when units are an
> issue.
>

That handles the units problem, but the syntax is still backwards for how it needs
to be read.  I suppose there's no way out. (And I'm being picky).  But:
  Speed := Miles'(37.0) / Hours'(1.5);
is read as:
  Speed := (37.0)'Miles / (1.5)'Hours;
And even there, for a simple statement like this I would prefer:
  Speed := 37.0'Miles / 1.5'Hours;
Actually, this would probably be as near to optimal as is realizable.
But defining each unit separately has problems.  I like the general approach used
by Pat Rogers:

> I have a facility somewhat like that on the "free code page" at my web
> site:
>
> http://www.classwide.com/products/freecode.htm
>
> Look for the "dimensioned units" section (at the bottom).
>
> --
> Pat Rogers                            Training and Consulting in:
> http://www.classwide.com      Deadline Schedulability Analysis
> progers@classwide.com        Software Fault Tolerance
> (281)648-3165                       Real-Time/OO Languages
>
as it feels more "generalizeable".

Re: Operators -> unit analysis

[Pat Rogers]

Charles Hixson <charleshixsn@earthlink.net> wrote in message
news:387383D0.4EA02E95@earthlink.net...

<snip>

> And some good way to handle units.  So that we could safely say things
like:
>
>      speed := 37.miles / 1.5.hours;
> I'm not too pleased with the syntax, but the idea is there.  Computer
> languages should make unit analysis easy!  This is one of the
"promises" of
> abstract data types, but I don't feel that it's been truly fulfilled,
> largely because it's too difficult to use.  Syntax is part of the
problem,
> and standard libraries are another part (or perhaps that one's been
solved,
> and I just don't know).  But standard types should be defined for all
the
> standard metric units, and most of the more common English units, with
> conversion functions between them.  I guess that the standard example
> package, Rational, is a good example of how it could be done, but
there is
> lots of detail work, and it needs to be standardized.

I have a facility somewhat like that on the "free code page" at my web
site:

http://www.classwide.com/products/freecode.htm

Look for the "dimensioned units" section (at the bottom).

--
Pat Rogers                            Training and Consulting in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Re: Operators -> unit analysis

[Charles Hixson]

Pat Rogers wrote:

> Charles Hixson <charleshixsn@earthlink.net> wrote in message
> news:387383D0.4EA02E95@earthlink.net...
>
> ...
> I have a facility somewhat like that on the "free code page" at my web
> site:
>
> http://www.classwide.com/products/freecode.htm
>
> Look for the "dimensioned units" section (at the bottom).
>
> --
> Pat Rogers                            Training and Consulting in:
> http://www.classwide.com      Deadline Schedulability Analysis
> progers@classwide.com        Software Fault Tolerance
> (281)648-3165                       Real-Time/OO Languages

NICE!!
I'm going to have to study that a bit.   I may add coulombs, or some such,
just to make sure I understand what it going on, but it looks pretty
straightforward.  Much more so than I expected, actually.  I still would
prefer a nicer syntax, but that's not enough to worry much about.
(I'll certainly add pounds, feet, and dollars [that last may strain the
system :-) ] )

Re: Operators -> unit analysis

[Ted Dennison]

In article <387383D0.4EA02E95@earthlink.net>,
  Charles Hixson <charleshixsn@earthlink.net> wrote:
> Terry Sikes wrote:
>
> > ...
> > One thing I'd like to see in both languages is the ability to use a
> > set of non-reserved Unicode symbols for operator overloading, to
> > disambiguate with the normal operator symbols.

> I don't insist on unicode, but I would also like more operators that
> could be overloaded.

How would you decide where to place them in the precidence hierarchy?
Having recently built a couple of packages around overloaded operators,
I found that getting the correct precidence for the various new
operators I defined is at least as important as the appropriateness of
the chosen operator symbol to the task. You don't want to end up in a
situation where you have to use parenthesis in counter-intuitive places
to work around the precidence rules.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Samuel T. Harris]

Ted Dennison wrote:
> 
> In article <387383D0.4EA02E95@earthlink.net>,
>   Charles Hixson <charleshixsn@earthlink.net> wrote:
> > Terry Sikes wrote:
> >
> > > ...
> > > One thing I'd like to see in both languages is the ability to use a
> > > set of non-reserved Unicode symbols for operator overloading, to
> > > disambiguate with the normal operator symbols.
> 
> > I don't insist on unicode, but I would also like more operators that
> > could be overloaded.
> 
> How would you decide where to place them in the precidence hierarchy?
> Having recently built a couple of packages around overloaded operators,
> I found that getting the correct precidence for the various new
> operators I defined is at least as important as the appropriateness of
> the chosen operator symbol to the task. You don't want to end up in a
> situation where you have to use parenthesis in counter-intuitive places
> to work around the precidence rules.
> 

How about a representation clause which defines the precedence
of a custom operator to that of another. Something like ...

for "union"'precedence use "+";
for "intersection"'precedence use "*";

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: Operators -> unit analysis

[Robert Dewar]

In article <3874D0BE.82F04763@Raytheon.com>,
  "Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote:
> How about a representation clause which defines the precedence
> of a custom operator to that of another. Something like ...
>
> for "union"'precedence use "+";
> for "intersection"'precedence use "*";
>
> --
> Samuel T. Harris, Principal Engineer
> Raytheon, Aerospace Engineering Services
> "If you can make it, We can fake it!"


This is of course the Algol-68 approach, and I think even the
Algol-68 designers regard it as a horrible mistake. One should
only rely on precedence of operators where the precedence rules
are clear and obvious. This cannot be the case by definition
for user defined precedences.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> This is of course the Algol-68 approach, and I think even the
> Algol-68 designers regard it as a horrible mistake. One should
> only rely on precedence of operators where the precedence rules
> are clear and obvious. This cannot be the case by definition
> for user defined precedences.

I would say: If it's not a precedence rule I learned in grade school,
then it shouldn't be in a programming language (whether it was put there
by the language designer or by some "clever" programmer).

- Bob

Re: Operators -> unit analysis

[Matthew Heaney]

In article <wccln626ily.fsf@world.std.com> , Robert A Duff 
<bobduff@world.std.com>  wrote:

> I would say: If it's not a precedence rule I learned in grade school,
> then it shouldn't be in a programming language (whether it was put there
> by the language designer or by some "clever" programmer).

Oh dear, I'll probably get horribly flamed for saying so, but I disagree
with the Ada(83) decision to require that "and" and "or" operators
appearing within the same statement also require parenthesis.

I think that, as in C, "and" should be given a higher precedence than
"or", analogous to how "*" is given a higher precedence than "+".

--
Evolution is as well documented as any phenomenon in science, as
strongly as the earth's revolution around the sun rather than vice
versa.

Stephen Jay Gould, Time, 23 Aug 1999

Re: Operators -> unit analysis

[Robert Dewar]

In article <38764aac_2@news1.prserv.net>,
  "Matthew Heaney" <mheaney@banet.net> wrote:
> In article <wccln626ily.fsf@world.std.com> , Robert A Duff
> <bobduff@world.std.com>  wrote:
>
> Oh dear, I'll probably get horribly flamed for saying so, but
I disagree
> with the Ada(83) decision to require that "and" and "or"
operators
> appearing within the same statement also require parenthesis.


Can you really argue that depending on this makes things easier
to read, I don't think so! And it is quite error prone. It is
all too easy to write

  if asdfasdf > oiuyoiuyoiuy or asdfadsfadsf < oiuoiuyoiuyoiuy
    and not junk

and be confused by the indentation. To me this was one of the
sound decisions in Ada. The cost to the writer, extra parens.
The benefit to the writer, avoiding bugs like the above. The
benefit to the reader is clear.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Robert A Duff]

Robert, please be careful with your quotes.  I didn't say the "Oh
dear..." -- Matt did.

- Bob

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article <38764aac_2@news1.prserv.net>,
>   "Matthew Heaney" <mheaney@banet.net> wrote:
> > In article <wccln626ily.fsf@world.std.com> , Robert A Duff
> > <bobduff@world.std.com>  wrote:
> >
> > Oh dear, I'll probably get horribly flamed for saying so, but
> I disagree
> > with the Ada(83) decision to require that "and" and "or"
> operators
> > appearing within the same statement also require parenthesis.
> 
> 
> Can you really argue that depending on this makes things easier
> to read, I don't think so! And it is quite error prone. It is
> all too easy to write
> 
>   if asdfasdf > oiuyoiuyoiuy or asdfadsfadsf < oiuoiuyoiuyoiuy
>     and not junk
> 
> and be confused by the indentation. To me this was one of the
> sound decisions in Ada. The cost to the writer, extra parens.
> The benefit to the writer, avoiding bugs like the above. The
> benefit to the reader is clear.

- Bob

Operator precedence--was Re: Operators -> unit analysis

[Howard W. LUDWIG]

Matthew Heaney wrote:
> 
> In article <wccln626ily.fsf@world.std.com> , Robert A Duff
> <bobduff@world.std.com>  wrote:
> 
> > I would say: If it's not a precedence rule I learned in grade school,
> > then it shouldn't be in a programming language (whether it was put there
> > by the language designer or by some "clever" programmer).
> 
> Oh dear, I'll probably get horribly flamed for saying so, but I disagree
> with the Ada(83) decision to require that "and" and "or" operators
> appearing within the same statement also require parenthesis.

This statement shows a fundamental, yet very common, misunderstanding of 
Boolean algebra, exemplifying the value of Robert Duff's idea.  If one uses 
0 for false and 1 for true, the operation table for "and" and "or" matches 
that of "*" and "+" in 7 out of 8 slots, which digital engineers seem to 
regard as a passing grade so they can feel justified with treating "and" 
just like "*" and "or" just like "+", including implied operations and 
operator precedence without parentheses.  However, that one mismatch has 
profound impact, causing Boolean algebras to have some very different 
properties (along with some similar ones) than fields.  With any of the 
fields of rational, real, or complex numbers using standard addition and 
multiplication, one of the operations (multiplication) is distributive 
across the other (addition), but not vice versa--this is the basis for the 
justification of assigning precedence to multiplication over addition.  In 
Boolean algebras, on the other hand, each binary operation is distributive 
across the other; this, combined with other defining properties, leads to 
the vital concept of duality, which says that swapping "and"s and "or"s 
and swapping 1s and 0s has no impact on the truth (or lack thereof) of 
a statement.  Some interesting consequences result:  (1) if the statement 
"AND has precedence over OR" has any validity, then so does its dual "OR 
has precedence over AND."--a contradiction.  (2) The association of "and" 
with "*", "or" with "+", "1" with TRUE, and "0" with FALSE is a _totally 
arbitrary_ convention; duality indicates that everything would work just 
fine if the opposite would be chosen as convention.

I have yet to see a logician write an expression with both "and" and "or" 
using infix notation without writing parentheses to indicate explicitly 
which is to be done first.  (And "and" and "or" are defined as logical 
operators in Ada, not as digital electronics operators, so I would expect 
logicians to have some say about precedence, especially since they are 
very careful to be rigorous and consistent, unlike many digital folks I 
know who would rather slop something together conveniently and quickly 
without worrying about rigor and consistency--reminds me of the hacking 
mentality we commonly associate with the C world, especially the idea 
of striving to save two characters of typing.)  Also, I have yet to 
see a set theorist write an expression with both intersection and union 
operations without using parentheses to indicate explicitly which is 
to be done first.
 
> I think that, as in C, "and" should be given a higher precedence than
> "or", analogous to how "*" is given a higher precedence than "+".

I repeat my comment about C hackers saving typing two characters regardless 
of impact on readability and maintenance.  I would think very carefully 
before using C as a example for how Ada should be (although the newly 
released ISO standard has some major improvements over the 1990 version).
 
> --
> Evolution is as well documented as any phenomenon in science, as
> strongly as the earth's revolution around the sun rather than vice
> versa.
> 
> Stephen Jay Gould, Time, 23 Aug 1999

Another thing about which to dream on.

Howard W. LUDWIG

Re: Operator precedence--was Re: Operators -> unit analysis

[Mark A Biggar]

"Howard W. LUDWIG" wrote:
> 
> I have yet to see a logician write an expression with both "and" and "or"
> using infix notation without writing parentheses to indicate explicitly
> which is to be done first. 

Then your blind.  I's say that at least a plurality of logical formula seen
in published papers are in disjunctive normal form which assumes that "and"
(expressed as concatination) takes precedence over "or" (expressed as either
"v" or "+"

--
Mark Biggar
mark.a.biggar@lmco.com

Re: Operators -> unit analysis

[Ted Dennison]

In article <853lkg$tgj$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <3874D0BE.82F04763@Raytheon.com>,

> Algol-68 designers regard it as a horrible mistake. One should
> only rely on precedence of operators where the precedence rules
> are clear and obvious. This cannot be the case by definition
> for user defined precedences.

I think you are saying that in practice it gets to be a mess. I do
appreciate that. But the above statement would only be true if they are
truly user-defined. If the operators and precedences are in fact created
by the user to match existing precedences for established mathematical
notations, then I think it *would* be clear and obvious to any user. For
instance, if I make a notation including operators to mimic BNF
productions (which I am doing, btw), any reasonable user would expect to
*not* have to put parenthesis around a production's right side just to
keep the BNF "::=" operator from being evaluated prematurely.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Brian Rogoff]

On Fri, 7 Jan 2000, Ted Dennison wrote:
> In article <853lkg$tgj$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> > In article <3874D0BE.82F04763@Raytheon.com>,
> 
> > Algol-68 designers regard it as a horrible mistake. One should
> > only rely on precedence of operators where the precedence rules
> > are clear and obvious. This cannot be the case by definition
> > for user defined precedences.
> 
> I think you are saying that in practice it gets to be a mess. I do
> appreciate that. But the above statement would only be true if they are
> truly user-defined. If the operators and precedences are in fact created
> by the user to match existing precedences for established mathematical
> notations, then I think it *would* be clear and obvious to any user. For
> instance, if I make a notation including operators to mimic BNF
> productions (which I am doing, btw), any reasonable user would expect to
> *not* have to put parenthesis around a production's right side just to
> keep the BNF "::=" operator from being evaluated prematurely.

Ted, if this is what you are trying to do, you should take a look at a 
"functional" programming language, like ML or Haskell. These languages 
allow user defined infix operators, and the example you describe is 
well studied in that community. 

-- Brian

Re: Operators -> unit analysis

[Charles Hixson]

> How would you decide where to place them in the precidence hierarchy?
>
> (see bottom)
>
Choices:
1)  Put them at the bottom of the precedence hierarchy, with equal
precedence.  Use parenthesis to do groupings.
2) (too complex) Allow a more verbose declaration form that specifies the
binding level. (Arrange all standard operators in ranked order, and allow
the newly declared operator to be inserted into the list.)
3) (Complex, but NICE)  Arrange for two kinds of operator declaration.  One
that is at the bottom of the hierarchy (as 1).  The other is near the top
(don't break apart parenthesized groups!) but left-binding and taking only
one parameter.  Call this one Unit or some such.  This would be for
declaring things like grams, dynes, years, etc.  So we could have:

UnitFunction grams (scalar : <<Numeric>>) returns Gram is

Custom operators in complex statements are problematic anyway, but I would
like to distinguish between dot product and cross product (and analogous
cases), which are conventionally treated as operators rather than as
functions.  I have never gotten used to the notation that goes:
    z    =    x.dot (y);
even though it *IS* semantically equivalent to, e.g.:
    z := x .*. y
(It would be even nicer if the large centered dot was a legitimate
character [which brings us back to the unicode request earlier in the
thread {it seems to have rolled off my newsServer, so I can't say who made
the request}], but it *is* a bit hard to type).

I frequently find that "common usage" improved the understand ability of
code.  The problem is that it is hard to support in a compiler (or requires
complex implementations).  To take an example from a different thread:
    speed = x miles / y hours;
now if there were "a units operator" (i.e., high priority, left binding,
takes one operator) one could define miles as an operator that multiplied a
scalar by 1 mile and returned a value of type Miles.  But units would need
to aggregate, so that we could specify area, volume, G, etc. So the exact
implementation would need to be carefully thought out.  The customary
syntax, however, has been with us since grade school, and changing it
immediately makes things less intelligible.  We have years of experience
that tell us that units are high priority, left binding, and take one
operator.  Except for traditional exceptions like currency which are high
priority, right binding, and take one operator (although when spoken the
currency units are left binding, just like a normal unit).  Thus $5 is 5
dollars, $5.25 is 5 and 1/4 dollars (or 5 dollars and 25 cents).

A problem is that the names of units occupy the same space as normal
variable names, but conceptually they are a different *kind* of thing.
Thus 5 grams IS 5 * (1 gram) IS Gram'(5), but the versions are each more
difficult to read than the one prior to it.  5'grams, OTOH, is transparent.

Unfortunately, it appears to me that making either: 5 grams or: 5'grams
legal would require changes in the specification of any language that I
know (except for Smalltalk and Forth, which have other problems).

Ted Dennison wrote:

> In article <387383D0.4EA02E95@earthlink.net>,
>   Charles Hixson <charleshixsn@earthlink.net> wrote:
> > Terry Sikes wrote:
> >
> > > ...
> > > One thing I'd like to see in both languages is the ability to use a
> > > set of non-reserved Unicode symbols for operator overloading, to
> > > disambiguate with the normal operator symbols.
>
> > I don't insist on unicode, but I would also like more operators that
> > could be overloaded.
>
> How would you decide where to place them in the precidence hierarchy?
> Having recently built a couple of packages around overloaded operators,
> I found that getting the correct precidence for the various new
> operators I defined is at least as important as the appropriateness of
> the chosen operator symbol to the task. You don't want to end up in a
> situation where you have to use parenthesis in counter-intuitive places
> to work around the precidence rules.
>
> --
> T.E.D.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: Operators -> unit analysis

[Hyman Rosen]

Charles Hixson <charleshixsn@earthlink.net> writes:
> And some good way to handle units.  So that we could safely say things like:
>      speed := 37.miles / 1.5.hours;

There is already a very good way to handle units, without any runtime
overhead if you don't need to determine units dynamically.

See Barton & Nackman, _Scientific and Engineering C++_.

Re: Operators -> unit analysis

[Matthew Heaney]

In article <t77lhos81h.fsf@calumny.jyacc.com> , Hyman Rosen 
<hymie@prolifics.com>  wrote:

> Charles Hixson <charleshixsn@earthlink.net> writes:
>> And some good way to handle units.  So that we could safely say things like:
>>      speed := 37.miles / 1.5.hours;
>
> There is already a very good way to handle units, without any runtime
> overhead if you don't need to determine units dynamically.

Yes, there is, by using type qualification:

  Speed := Miles'(37.0) / Hours'(1.5);

Re: Operators -> unit analysis

[Robert Dewar]

In article <387383D0.4EA02E95@earthlink.net>,
  Charles Hixson <charleshixsn@earthlink.net> wrote:
> Terry Sikes wrote:
>
> > ...
> > One thing I'd like to see in both languages is the ability
to use a
> > set of non-reserved Unicode symbols for operator
overloading, to
> > disambiguate with the normal operator symbols.
> >
> > Terry
> > --
> > tsikes@netcom.com
>
> I don't insist on unicode, but I would also like more
operators that could
> be overloaded.


This was an issue discussed at length during the design, and
the great majority felt it was an unnecessary complexification
to add such operators. Even a limited proposal to add a single
operator to be used for "almost implicit" conversions failed.
I don't see what has changed to make it worth rearguing the
point.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Terry Sikes]

In article <850tl9$thu$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
>In article <387383D0.4EA02E95@earthlink.net>,
>  Charles Hixson <charleshixsn@earthlink.net> wrote:
>> Terry Sikes wrote:
>>
>> > ...
>> > One thing I'd like to see in both languages is the ability
>to use a
>> > set of non-reserved Unicode symbols for operator
>overloading, to
>> > disambiguate with the normal operator symbols.
>> >
>> > Terry
>> > --
>> > tsikes@netcom.com
>>
>> I don't insist on unicode, but I would also like more
>operators that could
>> be overloaded.
>
>This was an issue discussed at length during the design, and
>the great majority felt it was an unnecessary complexification
>to add such operators. Even a limited proposal to add a single
>operator to be used for "almost implicit" conversions failed.
>I don't see what has changed to make it worth rearguing the
>point.

Was this point argued at length after the decision was made to add the
various annexes?  I'd think that this would be better received if it
was tied to the Numerics annex, since certainly this would be the
major area of use.

Lack of a large number of overloadable operator symbols seems like a
major lack in an otherwise numerics-friendly language.

Unicode support may be a bit over the top ;) but there are alternative
syntax possibilities like:

   --  Cross product
   Mat3 := Mat1 (x) Mat2;

(This approach is borrowed from the jpp Java preprocessor).

Ah well, perhaps it will make it in Ada 200x.  :-)

Terry
--
tsikes@netcom.com

Re: Operators -> unit analysis

[Robert A Duff]

tsikes@netcom.com (Terry Sikes) writes:

> Was this point argued at length after the decision was made to add the
> various annexes?

Yes.

>...I'd think that this would be better received if it
> was tied to the Numerics annex, since certainly this would be the
> major area of use.

Perhaps, but most numerics code is done in Fortran, and it doesn't
bother with all this fancy stuff either.

- Bob

Re: Operators -> unit analysis

[Terry Sikes]

In article <wcc9022izjp.fsf@world.std.com>,
Robert A Duff  <bobduff@world.std.com> wrote:

>>...I'd think that this would be better received if it
>> was tied to the Numerics annex, since certainly this would be the
>> major area of use.
>
>Perhaps, but most numerics code is done in Fortran, and it doesn't
>bother with all this fancy stuff either.

Which is why so many people are searching for something better, and
why so much numerical code is being translated into C++ (despite its
obvious deficiencies).

By coincidence, I received the following from the advanced-java list
today, I'll include it so you can ask yourself "Why not Ada Grande?".
(BTW, while operator overloading is not part of Java today, it will be
in the future according to Gosling.)

It seems to me that Ada is better suited to this problem space than
Java since it has a) _optional_ GC and b) static data structures.

Perhaps what Ada needs most is a Java-like syntax front-end.  ;-)

Terry

--begin quoted message--
To: advanced-java@xcf.berkeley.edu
Subject: ACM 2000 Java Grande Conference (10 days, 2 weekends left)
Date: Fri, 7 Jan 2000 07:55:29 +0100

Dear Colleague,

Please find attached the Call for Papers for the ACM 2000 Java Grande
Conference.  I would appreciate it if you would help ensure the wide
publicity of this event by forwarding the call to colleagues who you
think might be interested in submitting a paper.

Please note: Due to NSF ITR proposal deadline the due dates for JG2000
have been changed.  See below.

We look forward to your submission.

Thanks, 

	   Michael Philippsen.

---------------------------------------------------------------------------

                    CALL FOR PAPERS

           ACM 2000  Java Grande Conference

(NOTICE:  Due to NSF ITR proposal deadline the due dates for JG2000
 have been changed.  See below.)
                                                       
               Sponsored by ACM SIGPLAN 

       San Francisco, California, June 3-4, 2000 

             http://www.extreme.indiana.edu/java00


The Java Grande Conference focuses on the use of Java in the broad area of 
high-performance computing; including engineering and scientific
applications, simulations, data-intensive applications, and other 
emerging application areas that exploit parallel and distributed computing or
combine communication and computing. A day of tutorials will be held on the 
day following the conference. The conference precedes the JavaOne
2000 conference, which would enable the Java Grande attendees to expose 
themselves to the latest in basic Java Technology. 

Authors are invited to submit manuscripts that demonstrate timely results, 
technologies, or experiences that are most likely to have impact on the
use of Java in high performance computing systems. 

Topics of interest include but are not restricted to: 

     Java use for scientific and engineering applications 
     Java frameworks and libraries for high-performance computing 
     Implementation techniques for Java on high-performance systems 
     Java numerics and Java extensions for high-performance computing 
     Java compilation and optimization for high-performance computing 
     Java development tools and environments for high-performance computing 
     Java performance and benchmarking 

SUBMISSION

Papers should report new research and should not exceed 5000 words 
(approximately 10 pages typeset on 16 point spacing, or 15 typewritten
double-spaced pages). The program committee will review each submission 
and select papers based on originality, timeliness, relevance, and
clarity. All accepted papers will be presented at the conference, and 
published in the conference proceedings. 

Electronic submission is strongly encouraged. Please e-mail a Postscript 
or PDF copy of your submission to java00@icase.edu or send  15 hard copies 
to the program chair. Submissions must be received by January 17, 2000. 
Authors will be notified by Feb 25, 2000. 

Authors of accepted papers will be expected to sign a copyright release form. 
Proceedings will be distributed at the conference and will
subsequently be available from ACM. Papers published in proceedings are 
eligible for subsequent publication in refereed ACM journals at the
discretion of the editor of the particular journal. Papers describing 
essentially the same work must not have been published elsewhere or be
simultaneously under consideration for publication elsewhere. 

People interested in contributing a tutorial (.5 or 1 day) should contact 
the program chair by Jan 31, 2000.  The tutorials will be held on June 5,
2000. 
  

IMPORTANT DATES

Papers due:  Jan 17, 2000. 
Tutorial Proposals due:  Jan 31, 2000. 
Acceptance notice:  Feb. 25, 2000 
Final Papers due: March 24, 2000 


CONFERENCE CHAIR

Dennis Gannon 
Department of Computer Science 
Indiana University 
Bloomington, IN 47401 
and 
NAS Division 
NASA Ames Research Center 
MS 258-5 
Moffet Field, CA 94035 
Phone: (650) 604 1934 
gannon@cs.indiana.edu 


PROGRAM CHAIR

Piyush Mehrotra 
ICASE 
MS 132C 
3 West Reid Street - Building 1152 
NASA Langley Research Center 
Hampton, VA 23681 
Phone: (757)-864-2188 
Fax: (757)-864-6134 
pm@icase.edu 
  

PROGRAM COMMITTEE

     Henri Bal, Vrije University 
     Sandra Baylor, IBM 
     Aart Bik, Intel Corporation 
     Siddartha Chatterjee, University of North Carolina 
     Ken Kennedy, Rice University 
     Scott Kohn, Lawrence Livermore National Laboratory 
     Arvind Krishnamurthy, Yale University 
     Timothy Lindohm, Sun Microsystems 
     Satoshi Matsuoka, Tokyo Institute of Technology 
     Roldan Pozo, NIST 
     Vivek Sarkar, IBM 
     Suresh Srinivas, SGI 
     Vaidy Sunderam, Emory University 
     Gregor von Laszewzki, Argonne National Laboratory 
     Martin Westhead, EPCC 
     Kathy Yelick, University of California at Berkeley 


PUBLICITY CHAIR

Michael Philippsen 
Computer Science Department 
University of Karlsruhe 
Am Fasanengarten 5 
76128 Karlsruhe Germany 
Phone: 49-721-608-4067 
Fax: 49-721-608-7343 
phlipp@ira.uka.de 

Re: Operators -> unit analysis

[Brian Rogoff]

On 7 Jan 2000, Terry Sikes wrote:
> In article <wcc9022izjp.fsf@world.std.com>,
> Robert A Duff  <bobduff@world.std.com> wrote:
> 
> >>...I'd think that this would be better received if it
> >> was tied to the Numerics annex, since certainly this would be the
> >> major area of use.
> >
> >Perhaps, but most numerics code is done in Fortran, and it doesn't
> >bother with all this fancy stuff either.
> 
> Which is why so many people are searching for something better, and
> why so much numerical code is being translated into C++ (despite its
> obvious deficiencies).

Yes indeed, I thought that the "well Fortran doesn't do it" excuse sounded 
quite weak. If you strive to be just as good as Fortran then there is no 
reason to switch!

Tucker Taft's explanation that he feels additional operators compromise 
readability is the expected Ada response, but I disagree. Certainly 
overuse of infixes is bad, but I think Ada (or a future Ada-like
language) could use either a few more reusable infixes or a more general 
scheme. Honestly though, while I'm firmly in the "gimme more infixes" camp, 
I think this  is a fairly minor issue. 

I've also noticed that lots of new numerics (and I include DSP and image 
processing here) code is written in C or C++. If you really want to see
some interesting bleeding edge stuff, check out www.fftw.org, the
"Fastest Fourier Transform in the West", which won the Third Wilkinson
Prize for Numerical Software. While the web page describes it as a C
library for computing the DFT, the interesting part is actually  the
codelet generator which outputs the C, and that is written in OCaml, my 
other favorite language.

-- Brian

Re: Operators -> unit analysis

[Ted Dennison]

In article <8531v6$6qk$1@nntp3.atl.mindspring.net>,
  tsikes@netcom.com (Terry Sikes) wrote:
> In article <850tl9$thu$1@nnrp1.deja.com>,
> Was this point argued at length after the decision was made to add the
> various annexes?  I'd think that this would be better received if it
> was tied to the Numerics annex, since certainly this would be the
> major area of use.

Not by far. There are many applications in many realms of study that
have traditionally been described by some kind of mathematical notation.
The Gnat Snobol packages are a very good example for pattern matching.
Possible other applications off the top of my head are: strings, lists,
sets, database queries, BNF, Music.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Tucker Taft]

Ted Dennison wrote:
> 
> In article <8531v6$6qk$1@nntp3.atl.mindspring.net>,
>   tsikes@netcom.com (Terry Sikes) wrote:
> > In article <850tl9$thu$1@nnrp1.deja.com>,
> > Was this point argued at length after the decision was made to add the
> > various annexes?  I'd think that this would be better received if it
> > was tied to the Numerics annex, since certainly this would be the
> > major area of use.
> 
> Not by far. There are many applications in many realms of study that
> have traditionally been described by some kind of mathematical notation.
> The Gnat Snobol packages are a very good example for pattern matching.
> Possible other applications off the top of my head are: strings, lists,
> sets, database queries, BNF, Music.

For what it is worth, in my view adding lots of operators
is not doing the user any big favor.  Good old function-call syntax,
using named parameters when appropriate, is the clearest for most things.  

The advantage of operators is when a single statement involves many 
operations, and the use of infix operators makes it much easier to "grok"
what is going on.  That advantage disappears quickly if you end
up with unfamiliar operators interspersed within the complex
expression.  Even "familiar" operators are bad news if used
in unfamiliar ways. 

Furthermore, in many of the cases you mention above, you 
don't really want the operators *executed*
at run-time.  Instead, you want to create some kind of tree
representation, and then interpret it in some special way.
Building these trees at run-time seems like an inefficient way
to do things, which means the contexts where they will be useful
is even more limited.

In my view, operators are great for complex number packages, 
and other numeric-like things (matrices, vectors, bignums, etc.),
but as soon as the meanings of the operators becomes even slightly
obscure or non-standard, the value to the reader drops precipitously.
 
> --
> T.E.D.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Operators -> unit analysis

[Robert Dewar]

In article <38762D53.A9B2CC15@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> but as soon as the meanings of the operators becomes even
> slightly obscure or non-standard, the value to the reader
> drops precipitously.


An idea that Jean Ichbian and I pushed, but did not manage
to get sufficient support for, was to have one user defined
user operator, using the pillow symbol (also called the
currency conversion operator), to be used to represent un-noisy
"almost implicit" conversion operations (the kind of thing we
use unary plus for now).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Operators -> unit analysis

[Tucker Taft]

Robert Dewar wrote:
> 
> In article <38762D53.A9B2CC15@averstar.com>,
>   Tucker Taft <stt@averstar.com> wrote:
> 
> > but as soon as the meanings of the operators becomes even
> > slightly obscure or non-standard, the value to the reader
> > drops precipitously.
> 
> An idea that Jean Ichbiah and I pushed, but did not manage
> to get sufficient support for, was to have one user defined
> user operator, using the pillow symbol (also called the
> currency conversion operator), to be used to represent un-noisy
> "almost implicit" conversion operations (the kind of thing we
> use unary plus for now).

For what it's worth, I believe that is the Latin-1 symbol that got morphed
into the Euro currency symbol recently, so we were lucky to avoid
using it.  And we would still have to have decided on the precedence,
even though it was proposed only as a unary operator.  Would it have 
precedence like "+" or like "abs"?  Well of course, anything named 
"pillow" would be like ...

-Tuck
-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Operators -> unit analysis

[Florian Weimer]

Tucker Taft <stt@averstar.com> writes:

> For what it's worth, I believe that is the Latin-1 symbol that got morphed
> into the Euro currency symbol recently, so we were lucky to avoid
> using it. 

IIRC Latin-1 wasn't touched at all (at least the mapping to Unicode
wasn't changed), but Latin-15 was added.  I very much doubt that this
standard will be widely adopted because the modifications compared to
Latin-1 (Euro, addition of some French characters) are incompatible
with the most widespread Latin-1 flavor.

BTW: Do you know any use of the internation currency sign (except the
end-of-file marker in Microsoft Write)?

Re: Ada

[Richard D Riehle]

In article <t7aemmtz3b.fsf@calumny.jyacc.com>,
	Hyman Rosen <hymie@prolifics.com> wrote:

>C++ provides excellent implementation of generics,
>and good implementation of overloading, except that
>one cannot overload on return type as in Ada.
>
>Is there something specific you believe you can not
>do in C++ with regard to these abilities?

There are some differences in Ada and C++. The issue is not
"can not do" but rather how it is done and whether the Ada
way is any improvement.   Also, it is never a matter of
whether something can or cannot be done in a particular 
language.  Rather, the issue is whether a given language
is more expressive of a desired capability.  In many ways,
Ada is more expressive.  In other ways, C++ is more expressive.

Ada generics (templates)are always compiled before they are 
"included" by the client.  This is a function of the Ada library
model.  The instantiation is permitted only after the successful
compilation of the generic unit.  This puts type checking a little
closer to the origination of the generic.  

If I read the C++ literature correctly, C++ templates are expected
to be "full expansion" units.  Ada permits a template to be instantiated
in other forms to conserve memory. Some compilers support this.

Ada has more formats for generic formal parameters.  This has its
advantages and may sometimes have disadvantages.  The designer needs
to learn more idioms of the language.  Once having learned those idioms,
more options for template design are available.

Ada permits but does not require as much overloading of operators
as one needs in a C++.  This is useful when one is creating templates
for simple scalar and numeric types.  It does simplify the templates
for those types.  Actually, in this case, the Ada model is somewhat
an improvement over C++.  Of course, a C++ advocate may answer that
the word "class" may be used for a built-in type, but this still falls
short of the Ada model for range constraints and other rules of
scalar types.

Ada is more complicated when creating templates in which an entire
package is a generic formal parameter.  C++ is very straightfoward
in this regard.  The consequence is that this powerful feature of
Ada is often ignored by component designers.  In time, as Ada 
practitioners become more comfortable with its capabilities, we should
see more use of it.  Meanwhile, C++ seems much easier when one needs
one of more classes as generic formal parameters.

On the other hand, a generic formal package parameter provides the
equivalent of a namespace parameter, something I suspect cannot be
expressed easily in C++.  It also enables one to design reusable 
signatures for simplifying the parameter lists of application frameworks
components. Moreover, these signatures are subjected to all the 
checks of the compiler before they may ever be used.

Implementation of Ada generics can take advantage of child
library units, including private child library units to create,
as private child package specifications, a whole subsystem of reusable
package bodies.  This is not widely used, in practice, but has 
substantial power once it is understood by Ada component designers.

There are lots of other issues where Ada is more expressive of 
the component design problem.  I am sure others who frequent this
forum will note some of the more obvious ones I have overlooked.

Richard Riehle

Re: Ada

[Hyman Rosen]

Richard D Riehle <laoXhai@ix.netcom.com> writes:
> Ada generics (templates)are always compiled before they are 
> "included" by the client.  This is a function of the Ada library
> model.  The instantiation is permitted only after the successful
> compilation of the generic unit.  This puts type checking a little
> closer to the origination of the generic.  
> 
> If I read the C++ literature correctly, C++ templates are expected
> to be "full expansion" units.  Ada permits a template to be instantiated
> in other forms to conserve memory. Some compilers support this.

You have not read the literature correctly, or you have not read the
correct literature :-) C++ templates can be (according to the standard,
but not yet in reality) separately compiled, and many errors within the
template can be caught before instantiation. You are correct in that it
is unlikely that a C++ will offer anything but the full-expansion style
of template instantiation.

> Ada has more formats for generic formal parameters.  This has its
> advantages and may sometimes have disadvantages.  The designer needs
> to learn more idioms of the language.  Once having learned those idioms,
> more options for template design are available.

C++ has essentially *no* format for its generic formals, which are
types, templates, or constants. I think that allows C++ to achieve
the same things with its templates that Ada can.

> Ada permits but does not require as much overloading of operators
> as one needs in a C++.  This is useful when one is creating templates
> for simple scalar and numeric types.  It does simplify the templates
> for those types.  Actually, in this case, the Ada model is somewhat
> an improvement over C++.  Of course, a C++ advocate may answer that
> the word "class" may be used for a built-in type, but this still falls
> short of the Ada model for range constraints and other rules of
> scalar types.

Well, C++ doesn't have range constraints and subtypes (which is
too bad), so it can hardly overload on them. But it does have
enumerations, and those are fully overloadable. But C++ doesn't
have attributes, so one can't write a generic wrap-around successor
function, for example, so there, I've found an example for you :-)

> Ada is more complicated when creating templates in which an entire
> package is a generic formal parameter.  C++ is very straightfoward
> in this regard.  The consequence is that this powerful feature of
> Ada is often ignored by component designers.  In time, as Ada 
> practitioners become more comfortable with its capabilities, we should
> see more use of it.  Meanwhile, C++ seems much easier when one needs
> one of more classes as generic formal parameters.

I hold that a C++ class is more-or-less equivalent to an Ada package,
so a generic formal package in Ada would simply correspond to a generic
formal class in C++.

Re: Ada

[Robert A Duff]

Hyman Rosen <hymie@prolifics.com> writes:

> You have not read the literature correctly, or you have not read the
> correct literature :-) C++ templates can be (according to the standard,
> but not yet in reality) separately compiled, and many errors within the
> template can be caught before instantiation. You are correct in that it
> is unlikely that a C++ will offer anything but the full-expansion style
> of template instantiation.

The C++ standard allows templates to be separately compiled.
And the Ada standard allows garbage collection.
And the C standard allows array-bounds checking.
;-)

- Bob

Re: Ada

[Richard D Riehle]

In article <t77lhpuc8o.fsf@calumny.jyacc.com>,
	Hyman Rosen <hymie@prolifics.com> wrote:

>Richard D Riehle <laoXhai@ix.netcom.com> writes:
>
>You have not read the literature correctly, or you have not read the
>correct literature :-) C++ templates can be (according to the standard,
>but not yet in reality) separately compiled, 

I guess it is not just my reading of the compiler publishers manuals
that prevent me from doing the same thing I can do in Ada.  Also, I
am not sure that, once this is implemented in C++, it will correspond
to the same level of error checking possible in Ada generics.  One
of the essential points in Ada is that error checking is not just a
function of type-safety.   Often overlooked is the extensive set of
rules on Scope and Visibility in Chapted 8 of the ALRM.  C++ does not
seem to be quite as comprehensive on this point.

Meanwhile, my C++ programs must correspond to what the compiler 
publishers allow rather than the theoretical permissions of the
standard.  

>> Ada has more formats for generic formal parameters.  This has its
>> advantages and may sometimes have disadvantages.  The designer needs
>> to learn more idioms of the language.  Once having learned those idioms,
>> more options for template design are available.
>
>C++ has essentially *no* format for its generic formals, which are
>types, templates, or constants. I think that allows C++ to achieve
>the same things with its templates that Ada can.

As mentioned in my earlier post, I agree that when using the word "can"
nearly every language _can_ accomplish whatever any other language _can_.
The issue, when comparing languages, should never be whether something
_can_ be expressed in this or that language.  Rather, the issue is how
easily that something can be expressed.  It is the difference between
expressibility (can express) and expressiveness (designed to express).  

A caution is in order.  An earlier critique of Ada in this forum 
suggested that Ada is not as _intuitive_ as C++.  The author of that
criticism confused the notion of _intuitive_ with the notion of
_superficial_.  Expressive does not necessarily mean _intuitive_. 
Also, I do not mean to imply that you, Hyman, are superficial.  It
is clear that you think carefully and deeply about these issues.
There are many programming constructs for which COBOL is more
expressive, others for which Smalltalk is more expressive, and some
for which Ada is not as expressive as C++ or Eiffel.  We simply have
not yet achieved perfection in the design of programming languages.
However, as you noted in you post, Ada does have some advantages of
expressiveness, as does C++.  I continue to prefer the Ada approach,
even though I am currently spending more time coding C++ than I would
want. 

>I hold that a C++ class is more-or-less equivalent to an Ada package,
>so a generic formal package in Ada would simply correspond to a generic
>formal class in C++.

I will agree with this.  I suspect that, if templates had been designed
into C++ from the beginning, they might be a little better than they
are.  I find the Ada generic slightly more expressive, for my taste,
than the C++ template.  Fortunately, not all of us on this planet are
identical so there is room for more than one viewpoint on this subject.

Richard Riehle
 

Re: Ada

[Robert Dewar]

In article <84rd2f$snm$1@nntp3.atl.mindspring.net>,
  tsikes@netcom.com (Terry Sikes) wrote:
> For one look at "per language" programmer demand, see
> www.lmarkets.com, which seems to show both C++ and Java
considerably
> ahead of VB (of course this is programmer demand, not
programmer body
> count).


Nope, this is does not reflect programmer demand. It simply
reflects the number of jobs that are being offered in this
particular forum. Even if it did reflect programmer demand,
that would say nothing about the supply (ads tend to reflect
the surplus of demand over supply, which has nothing to do
with total market).

There are many sources for this information. One for example,
was a keynote address from Bill Gates at a big conference
(perhaps Comdex?) last year. There he also stated that Delphi
was at 5%, and Java at 9% (he said he did not really believe
the Java figure, that it probably reflected a lot of
experimentation, and given the failure of Java to get a
real foothold in client side programming that sounds right
to me. This same talk put Visual basic at about 50% of
PC development, and that also sounds about right to me,
with C/C++ being about 15%.

Ada did not get mentioned, but even if it was at what
(for me) would seem a very high level of 1% of all PC
development, it would have been under Bill's radar screen :-)

To get a feel for the Visual Basic market, have a look at the
catalogs of Active-X (now COM) components. Yes, these components
can be used in Visual C++ (and for that matter in Ada programs
written with GNAT :-) but the primary use of these components
is in the visual basic world.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Terry Sikes]

In article <84sudm$33s$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
>In article <84rd2f$snm$1@nntp3.atl.mindspring.net>,
>  tsikes@netcom.com (Terry Sikes) wrote:
>> For one look at "per language" programmer demand, see
>> www.lmarkets.com, which seems to show both C++ and Java
>considerably
>> ahead of VB (of course this is programmer demand, not
>programmer body
>> count).
>
>Nope, this is does not reflect programmer demand. It simply
>reflects the number of jobs that are being offered in this
>particular forum. Even if it did reflect programmer demand,
>that would say nothing about the supply (ads tend to reflect
>the surplus of demand over supply, which has nothing to do
>with total market).

You're right about the site reflecting surplus of demand over supply.
However, I find it hard to understand how the demand for VB
programmers is being filled, given that VB programming isn't in the
curriculum of most universities (also I know a couple of VB
consultants who're making good money, which doesn't indicate excessive
supply).

I'm going to contact Ted Shieh for more details about his methodology,
I thought there was more on the site, but couldn't find it.

>There are many sources for this information. One for example,
>was a keynote address from Bill Gates at a big conference
>(perhaps Comdex?) last year. There he also stated that Delphi
>was at 5%, and Java at 9% (he said he did not really believe
>the Java figure, that it probably reflected a lot of
>experimentation, and given the failure of Java to get a
>real foothold in client side programming that sounds right
>to me. This same talk put Visual basic at about 50% of
>PC development, and that also sounds about right to me,
>with C/C++ being about 15%.

50% of Windows (not PC) development, even if true, ignores major
market segments:

o  embedded systems
o  Unix/mainframe server-side  (this has picked up recently;)
o  Mac
o  Linux

I think you're underestimating the amount of C/C++ even on the Windows
side, also.  Bill has some level of vested interest in promoting VB,
after all.

>Ada did not get mentioned, but even if it was at what
>(for me) would seem a very high level of 1% of all PC
>development, it would have been under Bill's radar screen :-)

Probably.

>To get a feel for the Visual Basic market, have a look at the
>catalogs of Active-X (now COM) components. Yes, these components
>can be used in Visual C++ (and for that matter in Ada programs
>written with GNAT :-) but the primary use of these components
>is in the visual basic world.

As you say, they are compiler-neutral.  I think that the Windows
component marketplace has been VBs biggest success...  :-)   Linux
would benefit from a similar feature - or if Java ever gets efficient
enough, Java Beans are an alternative.

Terry
--
tsikes@netcom.com

Re: Ada

[Robert Dewar]

In article <84tj1p$r2g$1@nntp3.atl.mindspring.net>,
  tsikes@netcom.com (Terry Sikes) wrote:

> o  embedded systems

This is a very small sliver of the total development market

> o  Unix/mainframe server-side  (this has picked up recently;)

Still a small player development wise compared to PC's

> o  Mac

This is a VERY small fraction of the total PC development
effort.

> o  Linux

Getting larger, but still dwarfed by PC's

> I think you're underestimating the amount of C/C++ even on the
> Windows side, also.

Most university trained people *over* estimate the amount of
C and C++, precisely because they don't know the widely
used languages (COBOL and Visual Basic).


> Bill has some level of vested interest in promoting VB,
> after all.

Well I don't think he cares too much if people use VB or
visual C++. What is interesting about his figures is the
Delphi and Java figures, which he *does* care about :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Terry Sikes]

In article <84uk54$6jl$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
>In article <84tj1p$r2g$1@nntp3.atl.mindspring.net>,
>  tsikes@netcom.com (Terry Sikes) wrote:
>
>> o  embedded systems
>
>This is a very small sliver of the total development market

I'd be interested in knowing how "small" - there are a ton of
products with embedded microprocessors.

>> o  Unix/mainframe server-side  (this has picked up recently;)
>
>Still a small player development wise compared to PC's

Really?  You think the total number of development dollars spent on
server-side software is "small" compared to client side?  Even with
the Internet taking off?

>> o  Mac
>
>This is a VERY small fraction of the total PC development
>effort.

Macs are sitting at around 5% market share right now, and I'd guess
more development is done on them, percentage-wise, than is done on
Windows.

>> o  Linux
>
>Getting larger, but still dwarfed by PC's

Well, Linux installs are hard to measure, but I'd heard a figure of
10,000,000+ over a year ago.  The thing is though, that a very high
percentage of Linux boxes are development boxes.

>> I think you're underestimating the amount of C/C++ even on the
>> Windows side, also.
>
>Most university trained people *over* estimate the amount of
>C and C++, precisely because they don't know the widely
>used languages (COBOL and Visual Basic).

Although there are some, I think you'll find the numbers of PC COBOL
programmers to be quite small...  ;-)

As to VB, I agree its widely used...but I still think that C/C++
account for more than 15% of Windows development dollars.

>> Bill has some level of vested interest in promoting VB,
>> after all.
>
>Well I don't think he cares too much if people use VB or
>visual C++. What is interesting about his figures is the
>Delphi and Java figures, which he *does* care about :-)

C'mon, Bill has a soft spot for BASIC.  ;-)

Delphi has its good points, but just think if it had been implemented
in Ada95 instead of Object Pascal...

At any rate, its fairly pointless to discuss language marketshare
without better figures - anyone have any?

Terry
--
tsikes@netcom.com

Re: Ada

[Al Christians]

Terry Sikes wrote:
> 
> >This same talk put Visual basic at about 50% of
> >PC development, and that also sounds about right to me,
> >with C/C++ being about 15%.
> 
> 50% of Windows (not PC) development, even if true, ignores major
> market segments:
> 

In one of Capers Jones's books, he mentions many millions of workers
whose job description is not 'software developer' who spend some part 
of their work week developing software anyway.  VB might have a very 
large market share among that group of informal developers.    

Should the developers of Ada language products address the needs of 
that group?


Al

Re: Ada

[Terry Sikes]

In article <3874CB8B.2613A67F@easystreet.com>,
Al Christians  <achrist@easystreet.com> wrote:
>Terry Sikes wrote:

>> 50% of Windows (not PC) development, even if true, ignores major
>> market segments:
>
>In one of Capers Jones's books, he mentions many millions of workers
>whose job description is not 'software developer' who spend some part 
>of their work week developing software anyway.  VB might have a very 
>large market share among that group of informal developers.    
>
>Should the developers of Ada language products address the needs of 
>that group?

Right, I personally wouldn't count someone who writes some Excel
(VBScript) macros for an accounting spreadsheet as a "software
developer".  I think VBScript isn't too bad for that level of
development, and that something (even 1/2;) as complex as Ada would
drive those users away.

At any rate, its pretty academic since probably 90%+ of those folk are
using MS Office, and its unlikely the scripting language there will
change anytime soon...  (I wonder what the equivalent is for Star
Office...?)

I'd guess there's a large group of self-taught web developers as well,
that might be a more fertile ground for Unix/Linux based tools.

Terry
--
tsikes@netcom.com

Re: Ada

[Robert Dewar]

In article <3874CB8B.2613A67F@easystreet.com>,
  Al Christians <achrist@easystreet.com> wrote:
> Should the developers of Ada language products address the
> needs of that group?

One way to do this is to make sure that Ada is a first class
citizen when it comes to the COM interface, so it can play in
the same playground as VB. We have worked hard in the case of
GNAT to make GNAT fully compatible with COM/DCOM, and you can
do some VERY neat things with GNAT in this arena. I am sure
David Botton will be happy to elaborate :-)

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.