Anybody in US using ADA ?
Mr Bill
Thanks,
Bill
John R. Strohm
You might try looking at their web sight (http://www.lmco.com) and seeing
what they are looking to hire. (Most of their effort appears to be trawling
for resumes for Joint Strike Fighter, which is in C++.
"Mr Bill" <nos...@nospam.com> wrote in message
news:VtlQ9.42144$%3.107...@twister.neo.rr.com...
Britt Snodgrass
>
> Thanks,
> Bill
Rockwell Collins still uses Ada 83 or Ada 95 in many new avionics
products. Many products use a mixture of Ada and C.
Marin David Condic
some of them. As one who is working on the engines for the JSF, I can tell
you that those controls are still in Ada - for the time being. (Don't know
what will happen when they go into full scale development.)
Its a shame to see that many in the DoD arena are abandoning Ada because
"Everybody else is using C++". In this area, Ada does not tend to suffer so
much from lack of large libraries or other development enhancers since
hardware is often custom built and/or software development is not the long
pole in the tent. Here Ada's faster development time and reduced defect
characteristics can truly stand out. I'm afraid I don't know how to overcome
the "follow the crowd" mentality here. Ada has the technical edge and so
long as compilers/tools are available for the target (at a reasonable cost)
there isn't a whole lot of business/financial edge to something else (in
many cases at least). None of that tends to persuade the programmers or
their managers that they shouldn't try to be like everyone else. The only
real hope is for Ada to find its way into a significant commercial niche so
that there is a large body of "everyone else" out there to be followed.
Its hard to blame the programmers or the managers. Programmers want to have
skills that can get them a job somewhere else if Congress pulls the plug on
what they're doing - or simply want to use what they are familiar with
already. Managers don't want to be perceived as taking unnecessary risks
and - as the saying used to be - "Nobody ever got fired for picking IBM".
Similarly, management won't be fired for using tools that are "industry
standard". Nobody is going to change that position unless Ada is adopted for
some reasonably wide sector of the software market.
MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/
Send Replies To: m c o n d i c @ a c m . o r g
"I'd trade it all for just a little more"
-- Charles Montgomery Burns, [4F10]
======================================================================
John R. Strohm <str...@airmail.net> wrote in message
news:C900921B7A3FDDD4.5FD752FF...@lp.airnews.net...
tmo...@acm.org
> Congress pulls the plug on what they're doing
sets? "Young doctors don't want to learn surgery in case advanced drugs
make it unnecessary." "Lawyers don't want to learn criminal law in case
everybody becomes saintly." "Civil engineers want to learn only about
high speed rail, not roads, fearing no more roads will be built in future."
Even actors worrying about type casting usually try to diversify, rather
than getting lots and lots of practice in crowd scenes. :(
Q 2: What will all those C++ and Java programmers do when they discover
you don't innovate by getting a job that let's you use last year's
innovations, and they have no competitive advantage over Indians or
Russians at learning last year's innovations.
faust
>> Programmers want to have skills that can get them a job somewhere else if
>> Congress pulls the plug on what they're doing
> Are there other industries or professions with as narrow apparent skill
>sets? "Young doctors don't want to learn surgery in case advanced drugs
>make it unnecessary."
Well, very few doctors want to specialise in a niche like neonatal
neurology or pediatric cardiac surgery.
--------------------------------------------------------
Come see,
real flowers
of this pain-filled world.
(from Basho)
faust
>What will all those C++ and Java programmers do when they discover
>you don't innovate by getting a job that let's you use last year's
>innovations, and they have no competitive advantage over Indians or
>Russians at learning last year's innovations.
Those smart Indians are now inventing next year's innovations.
There are a fair number of South East Asian names in the programming
languages research and the functional programming worlds.
Marin David Condic
important is not the language or toolsets you use, but your abilities as an
engineer. But there is the other side of the coin. All professions
specialize to some extent and just as a doctor who specialized in gynocology
might have a hard time switching to proctology and beginning to work in an
entirely new field, so is it true that a programmer who has specialized in
Ada and some Ada toolset might have a bit of work making the transition to
some other language/toolset/problem domain. And even if one dismisses this
as not that big a deal, there's still this nasty problem called "Reality".
Job postings try to look for very specific skills and hiring managers
generally don't want to consider someone unless they match their job
description very closely. The fact that you can adapt and don't think that
this is a big deal doesn't matter because the people making those decisions
*do* think its a big deal. Life is often not fair, eh?
MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/
Send Replies To: m c o n d i c @ a c m . o r g
"I'd trade it all for just a little more"
-- Charles Montgomery Burns, [4F10]
======================================================================
<tmo...@acm.org> wrote in message
news:hwwQ9.518530$%m4.1...@rwcrnsc52.ops.asp.att.net...
tmo...@acm.org
frozen - "we will be using this language, that database, this kind
of UI, ...".
I read an interesting essay recently that pointed out that color TV,
UHF, and cable were all technically feasible in 1948 when TVs were in less
than 1% of American households. But we had three black and white VHF
network channels for a very long time because of industry structure&power
reasons. I suppose there were lots of job postings for B/W VHF tuner
designers, and few for people who knew UHF etc.
Marin David Condic
contemplating a new system from bottom-dead-center then one ought to
consider all of the inputs and decide what provides the best solution. But
new systems from bottom-dead-center are the exception. Almost always, you're
dealing with evolutionary growth or enhancement of some existing system or a
new project living within an existing context. Hence someone already has a
big investment in infrastructure that isn't going to get discarded just
because there exists some superior technology somewhere. (Example: A bank
needs some new accounting package that must operate on its existing
mainframe(s) & peripherials, against its existing database, maintained by
its existing staff, etc. They already have an OS, a Cobol compiler, a
database product and a heavy investment in tools, utilities, libraries, etc.
to operate here and the new system has to interact with the existing
applications. What are the odds someone is going to talk them into switching
to Ada for that new development?)
Maybe that's part of why there was/is a lot of resentment toward Ada. It
walked in the door with a mandate and everyone had big investments in other
things and the feeling was "This is going to cost me truckloads in
discarding my existing investment and for what? An uncertain 'technical
advantage'? Why are they trying to make my life harder?"
This is why Ada's best hope would be to attach itself to some new, emerging
technology where it doesn't have to displace existing technology and can
itself become the entrenched status quo. Barring that, it has to find some
groundswell of usage out in the hacker world so that there is some large
infrastructure of practical things in use that keep it afloat. (Another
version of "new technology") I don't see it doing either one unless it
offers the world some significant edge over the existing technology and
"reduced errors" isn't selling. "Time to market" probably would.
MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/
Send Replies To: m c o n d i c @ a c m . o r g
"I'd trade it all for just a little more"
-- Charles Montgomery Burns, [4F10]
======================================================================
<tmo...@acm.org> wrote in message news:VfKQ9.193788$qF3.13607@sccrnsc04...
Warren W. Gay VE3WWG
> I believe Pratt & Whitney is still using Ada for engine controls. At least
> some of them. As one who is working on the engines for the JSF, I can tell
> you that those controls are still in Ada - for the time being. (Don't know
> what will happen when they go into full scale development.)
>
> Its a shame to see that many in the DoD arena are abandoning Ada because
> "Everybody else is using C++". In this area, Ada does not tend to suffer so
> much from lack of large libraries or other development enhancers since
> hardware is often custom built and/or software development is not the long
> pole in the tent. Here Ada's faster development time and reduced defect
> characteristics can truly stand out. I'm afraid I don't know how to overcome
Maybe what needs to be done is to form a brand new committee, to design
a spashy new language that basically implements the same features, with
similar syntax (but not too obviously). Then give it a splashy new name
after a popular young female (no programmer experience required), and
call it something like "Shania". Make sure it gets included in .Net, and
have the Universities preach about it and.. world domination!
;-)
Just a thought.
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg
Warren W. Gay VE3WWG
...
> Maybe that's part of why there was/is a lot of resentment toward Ada. It
> walked in the door with a mandate and everyone had big investments in other
> things and the feeling was "This is going to cost me truckloads in
> discarding my existing investment and for what? An uncertain 'technical
> advantage'? Why are they trying to make my life harder?"
It would be interesting reading to review the "competition to
the Green language" at this point in time, to see how the
other entries stack up with what we know and accept today in
compiler languages and technologies. Are there online documents
that describe the other entries?
The Internet today would make it very easy for us to form our
own committee of "language experts" to start a language design
competition and review. Once the winner is announced, there must
be enough open sourced people spoiling for a chance to work on
a new language/compiler. Getting it accepted by industry would
be a different matter, but hey -- Linux is gaining acceptance.
Stranger things have happened.
However, when I think about it myself, I just feel that Ada95 (and
pending 200y) has gained so much useful experience, that it seems
a shame to start over (and add to the competition with Ada). I'd
rather see Ada succeed than start from near scratch again. But hey-
maybe there is a better design waiting to be sprung on the world.
Mike Silva
>
> Its a shame to see that many in the DoD arena are abandoning Ada because
> "Everybody else is using C++".
Seems like we should be seeing some results of the "DoD arena" rush to
C++ by now. As the data comes in, we should either see that indeed
C++ introduced problems and added costs that Ada would have avoided
(my expectation), or that it didn't (in which case, time to re-examine
assumptions). So, where are the C++ disaster coverups, and/or the
shining successes?
Mike
Vinzent Hoefler
> Maybe what needs to be done is to form a brand new committee, to
> design a spashy new language that basically implements the same
> features, with similar syntax (but not too obviously). Then give it a
> splashy new name after a popular young female (no programmer
> experience required), and call it something like "Shania".
new language Shania renames Ada;
But, WTF is Shania?
> Make sure
> it gets included in .Net, and have the Universities preach about it
> and.. world domination!
We already got A#. :-)
Vinzent.
Bill Findlay
VE3WWG" <ve3...@cogeco.ca> wrote:
>
> Maybe what needs to be done is to form a brand new committee, to design
> a spashy new language that basically implements the same features, with
> similar syntax (but not too obviously). Then give it a splashy new name
> after a popular young female (no programmer experience required), and
> call it something like "Shania".
In a language controversy on comp.arch a few weeks ago, some of us came to
the conclusion that a lot of the irrational antipathy to Ada was based on
unregenerate machismo. Real Programmers don't want to hear about "software
safety" (obviously a namby-pamby concern) and they certainly don't want
their code criticized by Ada (a mere slip of girl).
I suggested that we Ada proponents should talk instead about "aggressive bug
destruction" and that the 0Y committee should look at changing the name to
something that exudes testosterone. My first idea was "Rocky", but "Brutus"
attracted more support.
--
Bill-Findlay chez blue-yonder.co.uk ("-" => "")
Warren W. Gay VE3WWG
> Warren W. Gay VE3WWG wrote:
>>Maybe what needs to be done is to form a brand new committee, to
>>design a spashy new language that basically implements the same
>>features, with similar syntax (but not too obviously). Then give it a
>>splashy new name after a popular young female (no programmer
>>experience required), and call it something like "Shania".
>
> new language Shania renames Ada;
>
> But, WTF is Shania?
No real reason, other than her naval seems to
still persist in my memory cells ;-)
Warren.
Robert C. Leif
free version of GNAT to build commercial applications that put US software
manufacturers out of business.
Deming taught the Japanese manufacturers statistical quality control and the
US automotive industry has still and probably never will fully recover.
Bob Leif
Robert C. Leif
and Ada semantics. It will be both very verbose and sexy. If we model it
after SPARK, we can hype it as a new marvel of software engineering. A good
name would be XML#.
-----Original Message-----
From: comp.lang...@ada.eu.org [mailto:comp.lang...@ada.eu.org]
On Behalf Of Warren W. Gay VE3WWG
Sent: Thursday, January 02, 2003 9:57 AM
To: comp.l...@ada.eu.org
David Emery
In 1990 MITRE did an internal study based on then available data
saying that the cost to maintain Ada was -LINEAR- on SLOC, not
exponental as Barry Boehm says. If you think about this, it's a
radical conclusion. And it wasn't done by the Ada people at MITRE, but
by our cost center's statisticians and cost analysts
Back when Emmett Paige was ASD-C3I, he held a series of Ada Dual-Use
summits. At each, my position was: DoD has the data available to show
if Ada has the value we claim. Let's collect the data and let the facts
speak for themselves.
Two results from this experience:
1. DoD didn't want to gather and then hear facts
2. Language decisions are generally not made on the
basis of -any facts- but rather management perception of
"acceptability", "training costs", etc.
dave
(been there, done that, forgot my T-shirt)
Alexandre E. Kopilovitch
>In a language controversy on comp.arch a few weeks ago, some of us came to
>the conclusion that a lot of the irrational antipathy to Ada was based on
>unregenerate machismo. Real Programmers │ don't want to hear about "software
>safety" (obviously a namby-pamby concern) and they certainly don't want
>their code criticized by Ada (a mere slip of girl).
>
>I suggested that we Ada proponents should talk instead about "aggressive bug
>destruction" and that the 0Y committee should look at changing the name to
>something that exudes testosterone. My first idea was "Rocky", but "Brutus"
>attracted more support.
Well, if the gender matters here then...
THE FEMALE OF THE SPECIES
(R. Kipling, 1911)
When the Hymalayan peasant meets the he-bear in his pride,
He shouts to scare the monster, who will often turn aside.
But the she-bear thus accosted rends the peasant tooth and nail,
For the female of the species is more deadly that the male.
When Nag the basking cobra hears the careless foot of man,
He will sometimes wriggle sideways and avoid it if he can.
But his mate makes no such motion where she camps beside her trail,
For the female of the species is more deadly that the male.
When the early Jesuit fathers preached the Hurons and Choctaws,
They prayed to be delivered from the vengeance of the squaws.
'Twas the women, not the warriors, turned those stark enthusiasts pale,
For the female of the species is more deadly that the male.
Man's timid heart is bursting with the things he must not say,
For the Woman that God gave him isn't his to give away;
But the hunter meets with husband, each confirms the other's tale--
For the female of the species is more deadly that the male.
Man, a bear in most relations--worm and savage otherwise,--
Man propounds negotiations, Man accepts the compromise.
Very rarely will he squarely push his logic of a fact
To its ultimate conclusion in unmitigated act.
Fear, or foolishness, impels him, ere he lay the wicked low,
To concede some form of trial even to his fiercest foe.
Mirth obscene diverts his anger--Doubt and Pity oft perplex
Him in dealing with an issue--to the scandal of The Sex!
But the Woman that God gives him, every fibre of her frame
Proves her launched for sole issue, armed and engined for the same;
And to serve that single issue, lest the generations fail,
The female of the species must be deadlier that the male.
She who faces Death by torture for each life beneath her breast
May not deal in doubt or pity--must not swerve for fact or jest.
These be purely male diversions--not in these her honour dweils,
She the Other Law we live by, is that Law and nothing else.
She can bring no more to living than the powers that make her great
As the Mother of the Infant and the Mistress of the Mate.
And whe Babe and Man are lacking and she strides unclaimed to claim
Her right as femme (and baron), and equipment is the same.
She is wedded to convictions--in default of grosser ties;
Her contentions are her children, Heaven help him who denies!--
He will meet no snave discussion, but the instant, white-hot, wild,
Wakened female of the species warring as for spouse and child.
Unprovoked and awful charges--even so the she-bear fights,
Speech that drips, corrodes, and poisons--even so the cobra bites,
Scientific vivisection of one nerve till it is raw
And the victim writhes in anguish--like the Jesuit with the squaw!
So it comes that Man, the coward, when he gathers to confer
With his fellow-braves in council, dare not leave a place for her
Where, at war with Life and Conscience, he uplifts his erring hands
To some God of Abstract Justice--which no woman understands.
And Man knows it! Knows moreover, that the Woman that God gave him
Must command but may not govern--shall enthral but not enslave him.
And ~She~ knows, because She warns him, and Her instincts never fail
That the Female of Her Species is more deadly that the Male.
Bill Findlay
Bieber" <wlf...@ix.netcom.com> wrote:
> Well, keeping concurrent with Ada's period, we could go to last names:
> Byron (and thence to friends of the family -- Shelley).
>
I don't think poets are macho enough.
We need something really violent, like names of famous prizefighters, or
extreme weather events (Tornado? Cyclone? Hurricane?).
> Pity Frankenstein is the name of the "doctor" and not the proper name
> of the monster... Then again, being built from odd parts is more the
> domain of PL/1, is it not?
>
8-)
Marin David Condic
and for a whole bunch of reasons, it went over like a lead balloon with the
embedded developers. Partly because it initially didn't satisfy those
requirements in practice. (Eventually, it got there but not after having
created a horrible first impression and leaving a bad taste in the mouths of
too many embedded developers.)
I don't think there is anything inherently wrong with the language and there
isn't anything inherently wrong with its original requirements. However, if
I was going to write a new set of requirements for Ada (or some new
language) to meet, I'd spend some time talking to the folks who are not
using Ada now and find out what they want most in a programming language.
I'd bet (given the history of what is being bought out there) that
development leverage would tip the scales in its favor. "Hey guys! Pay that
initial investment in learning curve and infrastructure development up front
and you'll be building apps in half the time you do now and oh, P.S.,
they'll be portable across Windoze, Unix, Linux and Mac too!!!"
Reliability, performance, maintainability are all wonderful and desirable
things - but first you've got to deliver! Ada's problem is that it has a
history of promising how great its going to be one day, but doesn't
deliver - at least not on time. By this, I mean that it has promised things
like being good for embedded development and then taking years to get
efficient enough to do it and not being targeted to nearly enough embedded
platforms. People went with C because Ada just talked about how great it
would be one day. Same story now for workstation/PC development. One day, if
enough bindings and libraries are built you could develop better GUI apps
that are more reliable. But so what? C++ and/or Java are already there with
their libraries and bindings. Too bad that "One Day" Ada could do it better.
People are picking their languages and platforms today - not "One Day". If
Ada wants to win, its got to get out in front and lead the way with
more/better leverage *today* rather than "One Day".
MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/
Send Replies To: m c o n d i c @ a c m . o r g
"I'd trade it all for just a little more"
-- Charles Montgomery Burns, [4F10]
======================================================================
Warren W. Gay VE3WWG <ve3...@cogeco.ca> wrote in message
news:3E148004...@cogeco.ca...
Marin David Condic
that patterned itself on Ada - just to get away from the negative
impressions and bad press. But if all we've got is another language, it
won't do any better. It has to offer the developer something he can't get
elsewhere and it has to address a real need that's not being satisfied. I
think "Reliability" etc. are all good points, but any language or language
revision needs to consider what will help get it adopted by a larger crowd -
and "Reliability" just isn't cutting it.
MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/
Send Replies To: m c o n d i c @ a c m . o r g
"I'd trade it all for just a little more"
-- Charles Montgomery Burns, [4F10]
======================================================================
Warren W. Gay VE3WWG <ve3...@cogeco.ca> wrote in message
news:3E147D79...@cogeco.ca...
Marin David Condic
shallow, marketing for very long. Eventually, they open the box up and see
the same old Ada and word gets out. I don't think Ada is *bad* - but it sure
has a problem selling itself with "reliability", etc. That's why I've become
convinced that a new emphasis and new tools might do a better job of getting
Ada accepted. I'd be happy to be proven wrong - that all we really had to do
was change the name and use some more cosmetics - but I don't think that's
the case.
MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/
Send Replies To: m c o n d i c @ a c m . o r g
"I'd trade it all for just a little more"
-- Charles Montgomery Burns, [4F10]
======================================================================
Bill Findlay <yald...@blueyonder.co.uk> wrote in message
news:BA3A535D.177F%yald...@blueyonder.co.uk...
sk
> Machismo may be interesting, but nobody is going to be fooled by
> empty, shallow, marketing for very long. Eventually, they open the
> box up and see...
How has MS and windows survivied then ? :-)
--
--
-- Merge vertically for real address
--
------------------------------------
-- s n p @ t . o
-- k i e k c c m
------------------------------------
Bill Findlay
David Condic" <mcondic.a...@acm.org> wrote:
> Machismo may be interesting, but nobody is going to be fooled by empty,
> shallow, marketing for very long.
It was a joke, Marin.
> Eventually, they open the box up and see the same old Ada and word gets out.
"Same old Ada"? For all practical purposes Ada 95 is the same age as Java.
"Word gets out"? What word is that? Are you saying that there are serious
unacknowledged technical defects in Ada 95?
Opposition to Ada in comp.arch fell into three categories, which I parody
(grotesquely unfairly, I admit 8-) as follows:
(1) "We don't care about software quality. We make money selling ****
written in C, and that's fine with us."
(2) "We do care about software quality. We write our software in C (or
other, even less safe, languages) and ensure its quality by being faultless
programmers and superior human beings. Ada is for talentless losers."
(3) "Ada is too low-level. Our favourite language is Functional-Telepathy/1,
which generates an optimal program for you while you are still thinking
about the specification. It should be implemented real soon now."
Depressingly, type (1) critics were in a majority. When shown evidence (the
Rational data) that Ada could help them to make even more money, the
response was "I don't believe it"; taken even to the point of suggesting
that Rational had fabricated their figures. In other words: "I've no
evidence of my own, so I'll find reasons to ignore yours".
The intensity of denial was astonishing.
Type (2) and type (3) critics tended to post from academic domains (no
surprise 8-), although academia did not have a monopoly on false pride.
It's interesting that essentially no-one objected to Ada on the grounds of
technical or pragmatic issues such as are are openly discussed here.
> I don't think Ada is *bad* -
That's damming with faint praise. I think Ada 95 is very, very good indeed.
> but it sure has a problem selling itself with "reliability", etc.
> That's why I've become
> convinced that a new emphasis and new tools might do a better job of getting
> Ada accepted. I'd be happy to be proven wrong - that all we really had to do
> was change the name and use some more cosmetics - but I don't think that's
> the case.
Why do you care whether anyone adopts Ada, if "reliability, etc" is not the
primary concern? I look at this the other way round. I want the general
level of software quality to rise, and I believe that better understanding
and wider adoption of Ada would promote this objective. I'm more than happy
to make common cause with anyone, such as yourself, who has ideas about how
to make that happen. But I do not think that it is Ada that is the barrier;
and I do think that the barrier is fairly impenetrable. 8-(
Robert C. Leif
XP Professional. This file was created under Windows 98 and still opens
under 98. The customers would flock to something that worked!
In case this bug happens to anyone else, shorten the file names under an old
version of Windows. Evidently XP has a constraint that does not exist in the
older versions. Although XP has not crashed itself, many applications still
crash including Windows Explorer. Rebooting once a day is a reasonable means
of eliminating pointer garbage. Ada needs commercial products.
Bob Leif
-----Original Message-----
From: comp.lang...@ada.eu.org [mailto:comp.lang...@ada.eu.org]
On Behalf Of Bill Findlay
Sent: Thursday, January 02, 2003 8:43 PM
To: comp.l...@ada.eu.org
Subject: Re: Anybody in US using ADA ? One silly idea..
Robert C. Leif
lead the way with more/better leverage *today* rather than "One Day".
similarity with Ada than other programming languages. We need an XForms
implementation that works and can exchange data with Ada.
Bob Leif
-----Original Message-----
From: comp.lang...@ada.eu.org [mailto:comp.lang...@ada.eu.org]
On Behalf Of Marin David Condic
Sent: Thursday, January 02, 2003 6:47 PM
To: comp.l...@ada.eu.org
Mike Silva
The only reason things *may* be different this time is that the
amount, and cost of writing, software is so much greater today than
10-20 years ago that the risk of failure (or gross overrun) may be too
great to ignore or sweep under the carpet anymore, or, inverting, the
potential savings from using the right tools may be too great to
ignore....
Mike
Kevin Cline
> VE3WWG" <ve3...@cogeco.ca> wrote:
> >
> > Maybe what needs to be done is to form a brand new committee, to design
> > a spashy new language that basically implements the same features, with
> > similar syntax (but not too obviously). Then give it a splashy new name
> > after a popular young female (no programmer experience required), and
> > call it something like "Shania".
>
> In a language controversy on comp.arch a few weeks ago, some of us came to
> the conclusion that a lot of the irrational antipathy to Ada was based on
> unregenerate machismo.
Not all the antipathy to Ada is irrational. Most of it comes
from sad experience. Mine was trying to use Ada-83 to write Unix
applications with a Motif UI. Regardless of any superiority in
reliability, the scarcity of libraries and trained
programmers makes Ada too expensive for most commercial software
projects.
Kevin Cline
> Maybe that's part of why there was/is a lot of resentment toward Ada. It
> walked in the door with a mandate and everyone had big investments in other
> things and the feeling was "This is going to cost me truckloads in
> discarding my existing investment and for what? An uncertain 'technical
> advantage'? Why are they trying to make my life harder?"
It walked in the door with an overly broad mandate and almost nothing
else.
The compilers were buggy. The debuggers were a joke. Tasking was
useless
except on an Ada RTOS. Bindings to system facilities were
compiler-specific.
Without function pointers, binding to a GUI was nearly impossible.
Work that could be done in hours in C suddenly expanded to take
several days.
Most programmers with any breadth of experience quickly labelled Ada
a non-starter.
>
> This is why Ada's best hope would be to attach itself to some new, emerging
> technology where it doesn't have to displace existing technology and can
> itself become the entrenched status quo. Barring that, it has to find some
> groundswell of usage out in the hacker world so that there is some large
> infrastructure of practical things in use that keep it afloat.
LOL. Look at the languages that have been adopted by the 'hacker
world'
over the past fifteen years: C++. Tcl/Tk. Perl. Java. Python. Ruby.
PHP.
The drive is to do more and more while saying less and less. Safety
is good, but expressiveness and compatibility with existing technology
(i.e. the Web, relational databases, and GUI) are the real drivers. OO
is still going strong, but functional programming is gaining
mindshare.
Compile-link-run is on the wane.
Also, all these languages provide built-in associative containers.
Arrays are fine for small embedded systems, but not very useful
for database-driven text processing applications.
John R. Strohm
news:ba162549.03010...@posting.google.com...
In the very early 1980s, General Dynamics / Fort Worth Division started the
F-16C/D program. This was a MAJOR upgrade of the airplane, involving, among
other things, all new computers and all new software.
Ada wasn't there yet, so they chose JOVIAL J73.
At that time, there existed precisely one J73 compiler, and it didn't target
EITHER of the processors they were designing into the airplane (Zilog Z8002
and MIL-STD-1750A). They wound up having to let compiler development
contracts to two (small) companies to develop toolsets.
At that time, trained J73 programmers just plain didn't exist. GD/FW had to
train every single programmer they hired for that project.
Every time I hear someone grumbling about the scarcity of trained Ada
programmers, I think about F-16C/D and JOVIAL, and I wonder how GD/FW ever
managed to get that airplane off the ground, if training is so hard.
I'm not even going to mention HAL/S, the Space Shuttle language, which to my
(unclassified) knowledge was not used for anything else on the planet.
Where does NASA (and the SEI Level 5 contractor) get trained HAL/S
programmers?
John R. Strohm
Cost per SLOC, in constant dollars, has declined SIGNIFICANTLY over the last
20 years. This was one of the big findings in the SEI CMM stuff, that it
really is significantly cheaper to do things right the first time.
At one point, I was informally putting together a business case for Ada and
Rational R1000s at GD/FW, based on (a) Rational's productivity numbers and
"force multiplier" effects, (b) the known size of F-16C/D operational flight
software, (c) the expected size of the next airplane's software, (d) the
size of the parking lots at GD/FW (which were ALREADY overflowing).
"Mike Silva" <snarf...@yahoo.com> wrote in message
news:20619edc.03010...@posting.google.com...
Marin David Condic
sharing software without some immediate commercial purpose in mind. Ada has
its own hacker community that is putting out some software - just not enough
of them to flood the world with something like Linux. If you can't get the
commercial developers to use Ada because of their investment in existing
technology, you get the "hackers" to build technology to surpass what is
already there.
I agree that there are trends in the larger "Hacker Community" that Ada does
not fit in well with. But that doesn't mean it can't have some appeal in
some other way to some segment of the world. When you say "The drive is to
do more and more while saying less and less" I couldn't agree more nor do I
think that is a bad thing. That's simply talking about "leverage" and if Ada
concentrated on that a bit more it might start looking really attractive to
others. I don't mean shorten the syntax. I mean provide big libraries so
that a developer basically spends time patching together existing code
rather than developing it all from bottom-dead-center.
MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/
Send Replies To: m c o n d i c @ a c m . o r g
"I'd trade it all for just a little more"
-- Charles Montgomery Burns, [4F10]
======================================================================
Kevin Cline <kcli...@hotmail.com> wrote in message
news:ba162549.03010...@posting.google.com...
>
Marin David Condic
where software development was not going to be the cost or schedule driver.
How many commercial products are in that position? Your average
garage-startup company is never going to be able to let out contracts to get
a compiler retargeted and your average small business is never going to be
able to wait until the retargeted compiler is ready to use before they can
start development.
Ada shot itself in the foot early on because it was A) Too expensive, B)
Didn't work well and C) Wasn't available for the platforms people were
developing on. It pretty much cured those problems by now - but too late to
avoid all the damage and missed opportunities. Now it faces new problems and
it has to address those if it hopes to avoid the same missed opportunities.
MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/
Send Replies To: m c o n d i c @ a c m . o r g
"I'd trade it all for just a little more"
-- Charles Montgomery Burns, [4F10]
======================================================================
John R. Strohm <str...@airmail.net> wrote in message
news:80F453381B124BF8.ACEC5877...@lp.airnews.net...
Marin David Condic
>
> It was a joke, Marin.
>
> > Eventually, they open the box up and see the same old Ada and word gets
out.
>
> "Same old Ada"? For all practical purposes Ada 95 is the same age as Java.
>
By which I meant that simply changing the terminology to be more "Macho"
and/or just tinkering with the syntax a little to make it look different
isn't going to fool anyone into thinking its something "new".
> "Word gets out"? What word is that? Are you saying that there are serious
> unacknowledged technical defects in Ada 95?
>
Nope. See above.
> Opposition to Ada in comp.arch fell into three categories, which I parody
> (grotesquely unfairly, I admit 8-) as follows:
> (1) "We don't care about software quality. We make money selling ****
> written in C, and that's fine with us."
> (2) "We do care about software quality. We write our software in C (or
> other, even less safe, languages) and ensure its quality by being
faultless
> programmers and superior human beings. Ada is for talentless losers."
> (3) "Ada is too low-level. Our favourite language is
Functional-Telepathy/1,
> which generates an optimal program for you while you are still thinking
> about the specification. It should be implemented real soon now."
>
> Depressingly, type (1) critics were in a majority. When shown evidence
(the
> Rational data) that Ada could help them to make even more money, the
> response was "I don't believe it"; taken even to the point of suggesting
> that Rational had fabricated their figures. In other words: "I've no
> evidence of my own, so I'll find reasons to ignore yours".
>
> The intensity of denial was astonishing.
>
I understand and sympathize. The problem is that those are your potential
customers for Ada and if you don't find a way to persuade them with
*something* then you'd might as well just give up. I've had my own data
showing how Ada can make more money and the problem is that this sort of
data just doesn't seem to help people get interested in it. Mostly because
it is "Life Cycle" money and most business efforts are driven by "Time To
Market" money. They don't care if it costs more in the long run because if
it doesn't get there first, it won't earn anything anyway, so better to
spend more "in the long run" if whatever you do gets a product out the door
quicker.
So if we could find a way to show some segment of this market that Ada
brought them some truckload of leverage that got them to market twice as
fast, don't you think they'd perk up and be interested? I did a stint in the
Cable TV Set Top Box world and if Ada had been there with a whole package of
stuff that got the box delivered faster - and with fewer defects - it might
have been given a serious shot. (And found a nice "emerging technology" to
tie itself to.) There ought to be some segment of the developer world that
Ada can address more effectively by listening to its concerns and providing
it with leverage.
> Type (2) and type (3) critics tended to post from academic domains (no
> surprise 8-), although academia did not have a monopoly on false pride.
>
> It's interesting that essentially no-one objected to Ada on the grounds of
> technical or pragmatic issues such as are are openly discussed here.
>
So if you want to sell to them, using technical arguments of superiority or
pragmatic arguments of life cycle costs aren't going to work. (That
shouldn't be news. Ada's been making that case for 20 years now and
customers are ignoring it by the millions.) That means we ought to find out
what the customer *would* buy and find a way to get that into Ada if it
doesn't already exist.
> > I don't think Ada is *bad* -
>
> That's damming with faint praise. I think Ada 95 is very, very good
indeed.
>
Maybe. I've been an Ada advocate for a very long time, so I think I'm on
record as saying nice things about it. My intent was to indicate that I
didn't see some fundamental flaws in the language itself that were causing
it to fail to be adopted. Syntactic or semantic changes are probably not
necessary on any large scale - more an emphasis on what else Ada provides
besides its syntax & semantics.
>
> Why do you care whether anyone adopts Ada, if "reliability, etc" is not
the
> primary concern? I look at this the other way round. I want the general
> level of software quality to rise, and I believe that better understanding
> and wider adoption of Ada would promote this objective. I'm more than
happy
> to make common cause with anyone, such as yourself, who has ideas about
how
> to make that happen. But I do not think that it is Ada that is the
barrier;
> and I do think that the barrier is fairly impenetrable. 8-(
> --
O.K. I hope I can make myself crystal clear on this one: I am NOT opposed to
reliability nor do I think it is irrelevant or should be taken out of the
language or anything of that sort. What I'm saying is that Ada has been
harping on "Reliability" for TWENTY YEARS and people are staying away from
it in droves. Twenty more years of harping on reliability is not likely to
change that. Hence, let's keep reliability in our back pocket to pull out
when it makes sense to talk about it, but in the mean time, lets find
something more appealing to put in front of the potential users that they
might actually care about. Find out what some commercial developers in some
sector might want in a programming language and fill that need. When they
get reliability as a byproduct, then you can pull the "See??? I Told You
So!!!" out of your back pocket and we can all brag about that.
As someone who likes and uses Ada, I'd like to see the language grow and
prosper. I think the best way to do that is to get Ada focused on providing
something that some large segment of the developer population just can't
resist using. If we give thought to that, maybe we can come up with the
right changes and the right focus.
Mark
On Fri, 3 Jan 2003, Marin David Condic wrote:
> It depends. By "Hacker Community" I meant those who are developing and
> sharing software without some immediate commercial purpose in mind. Ada has
> its own hacker community that is putting out some software - just not enough
> of them to flood the world with something like Linux. If you can't get the
> commercial developers to use Ada because of their investment in existing
> technology, you get the "hackers" to build technology to surpass what is
> already there.
Not quite sure if anyone cares, however:
I know that a number of people are trying to write/re-write various
parts of the Linux kernel and kernel modules with Ada... I hear the
projects 'should' be out by the summer...
>
> I agree that there are trends in the larger "Hacker Community" that Ada does
> not fit in well with. But that doesn't mean it can't have some appeal in
> some other way to some segment of the world. When you say "The drive is to
> do more and more while saying less and less" I couldn't agree more nor do I
> think that is a bad thing. That's simply talking about "leverage" and if Ada
> concentrated on that a bit more it might start looking really attractive to
> others. I don't mean shorten the syntax. I mean provide big libraries so
> that a developer basically spends time patching together existing code
> rather than developing it all from bottom-dead-center.
Sounds good to me, would save muchos time and effort.
cheers folks,
Mark
Warren W. Gay VE3WWG
> Well, Ada's original requirements were targeted towards the embedded world
> and for a whole bunch of reasons, it went over like a lead balloon with the
> embedded developers. Partly because it initially didn't satisfy those
> requirements in practice. (Eventually, it got there but not after having
> created a horrible first impression and leaving a bad taste in the mouths of
> too many embedded developers.)
In its day, I could see why embedded people had concerns (Ada is still
a very large "language"). The largeness should not be a concern for
general purpose use - GNAT just flies through compiles on my 1.2Ghz
laptop. I can only image how fast it is on current technology.
The only general fault that I would state about the Ada95 _language_
apart from a few "warts", would be the complexity of some of the rules.
But then, I suppose, if you were to implement limited types (for example)
in a new language, you'd probably still have those same complex rules
under different names/circumstances. The freezing rules are a bit tricky,
and some of the visibility aspects are a bit tricky. I also think better
could be expected of "representation rules" as well.
> I don't think there is anything inherently wrong with the language and there
> isn't anything inherently wrong with its original requirements.
I would generally support this (with exceptions noted above).
> However, if
> I was going to write a new set of requirements for Ada (or some new
> language) to meet, I'd spend some time talking to the folks who are not
> using Ada now and find out what they want most in a programming language.
I think we've discussed this before-- the real reason IMHO is the lack
of "library support". It is less an issue of the language, but more
about the libraries and bindings. Being that Ada95 is different than
C/C++, bindings come into just about everything (for both Windows
and UNIX) -- speaking non-embedded world wise.
Also a lack of a "generally accepted" container library (standard or
not), is also a "fracturing component". I myself find the Booch
components extremely useful, but many I suppose do not like the
complexities of the instantiations required to use them.
Is it possible that the generics in the _language_ needs to be
researched to make container libraries more elegant? Or are the
implementations of these (Booch?) the problem? Or are we too
hard on the requirements?
> I'd bet (given the history of what is being bought out there) that
> development leverage would tip the scales in its favor. "Hey guys! Pay that
> initial investment in learning curve and infrastructure development up front
> and you'll be building apps in half the time you do now and oh, P.S.,
> they'll be portable across Windoze, Unix, Linux and Mac too!!!"
I think you could eventually sell Ada if the binding/library support
was there. If developers could find all the bindings to the O/S,
database, GUI and all that other cool Open Sourced set of libraries,
then it becomes only a matter of language choice. The reality is that
using Ada for general purpose work is still very much an uphill battle
on most of these fronts, because the developer must become expert
in writing bindings to existing libraries and often O/S facilities.
Portability might be enhanced with a _standard_ preprocessor (something
like gnatprep).
> Reliability, performance, maintainability are all wonderful and desirable
> things - but first you've got to deliver!
THat is where libraries/bindings would be a great benefit.
> Ada's problem is that it has a
> history of promising how great its going to be one day, but doesn't
> deliver - at least not on time. By this, I mean that it has promised things
> like being good for embedded development and then taking years to get
> efficient enough to do it and not being targeted to nearly enough embedded
> platforms. People went with C because Ada just talked about how great it
> would be one day.
Embedded systems have their own challenge, because they are very much
focused on efficiency with very limited resources. On the GP scene
however, I don't believe this needs to be much of a factor.
> Same story now for workstation/PC development. One day, if
> enough bindings and libraries are built you could develop better GUI apps
> that are more reliable.
Yes, that's it.
> But so what? C++ and/or Java are already there with
> their libraries and bindings.
Yep, that is the _competition_ then -- the competition is at the library
level.
> Too bad that "One Day" Ada could do it better.
> People are picking their languages and platforms today - not "One Day". If
> Ada wants to win, its got to get out in front and lead the way with
> more/better leverage *today* rather than "One Day".
> Marin David Condic
I do believe however, that language/tool choice is becoming increasingly
critical in the GP scene. Consider this:
1. Assembly language was the language of choice for operating
systems when hardware was slow, clunky in resource strapped. This
was so in order to be efficient (mostly), due to limited choice
of compiler technology and memory/CPU resources and needs.
2. People started to write O/S in higher level languages: C, Modula-2
etc. There was still a need to be "resource frugal", but the higher
level language was decidedly much more reliable, and saved time in
development and maintenance.
3. Large software systems like the X-Window software was written in
C, because it was available and efficient for the hardware of that
time. It is still in C, primarily due to its age and "legacy reasons"
4. About the same time, we have various incarnations of unreliable
Microsoft software also being written in C initially, although
increasingly in C++.
5. The Internet: with it came the problems of security and virus
and hacking threats. Users are sick of Windows unreliability.
Also a fork into the foray of java etc.
6. Users/IT is sick of securing against network hacks. Still contending
with "instability". Systems of all kinds are getting "huge" and
built with an "unstable foundation".
<Present Time: 2003>
7. Recognition that software reliability requires that the compiler
technology must be very rigid. Two alternatives:
i) Form a consortium to design a new language/tools.
ii) Recognize that Ada95/Ada200y is the best new tool for
the job.
iii)Fork off another Ada200x variant that is targeted to
general purpose work, leaving the embedded systems
roots behind. Clean up warts.
8. Build new foundations (O/S etc.) in this/these new language(s).
# 4, 5 and 6 remind me of the time when O/S were unstable because
of their assembler language roots. Now we have O/S that have
some instability due to their C roots (granted a great improvement
in some cases over the assembler counterparts). Now its time to
move past C into Ada (thinking optimistically...)
I like to think optimistically, that we are headed in the 7.ii or 7.iii
direction in the near future. We cannot keep buiding humungous
systems on unstable foundations. At some point, someone is going
to say "scrap the foundation and put something more reliable there,
so that we can get _on_ with building on top reliably". How can
you build a tower if you have to keep patching the basement?
This even applies to the embedded world still -- I
can't believe the number of software bugs I have encountered
in my Kodak digital camera.
Warren W. Gay VE3WWG
> It might not hurt to start over again with a new name and a new language
> that patterned itself on Ada - just to get away from the negative
> impressions and bad press. But if all we've got is another language, it
> won't do any better. It has to offer the developer something he can't get
> elsewhere and it has to address a real need that's not being satisfied. I
> think "Reliability" etc. are all good points, but any language or language
> revision needs to consider what will help get it adopted by a larger crowd -
> and "Reliability" just isn't cutting it.
>
> MDC
While I just finished harping on library/binding support in an earlier
post in reply to you, I just realized something reading this reply. Java
has had (at least initially) the same binding/library challenges that
Ada95 has in the current general purpose world. Yet everyone and their
grandmother has come out with bindings to databases etc. to make Java
work within an application framework with great enthusiasm.
Q. So why is the enthusiasm so different for Ada, than it is/has been
for Java?
The overwhelming difference (I think) is simply that Java is new and is
seen as (or was) "cutting edge". Ada is seen simply as "old and big".
You don't find Borland (for example) thrilled about selling support
for Ada, but they might be enthused over selling Java support.
Could there be more substance to the "new" suggestion after all?
Maybe the Ada way must distance itself from:
- the Military association
- the US assocation(?)
- the committee association
- the being "old" asociation
- the being "big and clumsy" association
and maybe it just needs to be resold as :
- the latest new computer science theory of "reliable computing"
(even though the solution was well understood in ages past ;-)
Just like in science where the theory is often not well accepted
until the author of it passes away, we may need to have Ada
reborn to have it gain acceptance. ;-)
Bill Findlay
David Condic" <mcondic.a...@acm.org> wrote:
> Bill Findlay <yald...@blueyonder.co.uk> wrote in message
> news:BA3AC562.17A7%yald...@blueyonder.co.uk...
>>
>> It was a joke, Marin.
>>
> Ahhh, but a "joke" that's been seriously suggested here before. :-)
!!!!
>> "Same old Ada"? For all practical purposes Ada 95 is the same age as Java.
> By which I meant that simply changing the terminology to be more "Macho"
> and/or just tinkering with the syntax a little to make it look different
> isn't going to fool anyone into thinking its something "new".
I agree, of course.
[...]
>> (1) "We don't care about software quality ..."
>> (2) "We do care about software quality. ... Ada is for talentless losers."
>> (3) "Ada is too low-level. ..."
>>
>> Depressingly, type (1) critics were in a majority.
[...]
>>
> I understand and sympathize. The problem is that those are your potential
> customers for Ada and if you don't find a way to persuade them with
> *something* then you'd might as well just give up. I've had my own data
> showing how Ada can make more money and the problem is that this sort of
> data just doesn't seem to help people get interested in it. Mostly because
> it is "Life Cycle" money and most business efforts are driven by "Time To
> Market" money. They don't care if it costs more in the long run because if
> it doesn't get there first, it won't earn anything anyway, so better to
> spend more "in the long run" if whatever you do gets a product out the door
> quicker.
That pretty much sums up what type (1) critics said.
Despite my making fun of them, I do think they have the makings of a point.
But donšt you think that (other things being equal - and that is what you
are emphasizing) Ada *would* get them to market sooner?
I was even more depressed that type (2) critics, who did care about quality,
had the perception that Ada was a crutch for the talentless.
This is so contrary to my own perception that I find it bewildering.
John R. Strohm
recollection is that Silicon Graphics was using Ada internally VERY early in
their life, and they were keeping this VERY quiet because it was helping
them, a lot, and they didn't really want anyone else to know.
Rational used Ada internally, and it helped them a lot. They published
their numbers, but the reaction at GD/FW was that it just wasn't possible to
get those kinds of numbers.
McDonnell-Douglas had been using assembly language on F-15. For the
IFFC/Firefly demonstration, they jumped into Ada with both feet,
enthusiastically, and reported very good numbers, for a digital flight
control application. (IFFC/Firefly was Integrated Flight and Fire Controls:
the idea was to let the firecontrol computers cue the flight control system
directly, to let the airplane help the pilot point the airplane and the
weapons at the target. The demo pilot reportedly said, very
enthusiastically, "I don't know if I fired the gun or the airplane did, but
WE GOT HIM!")
I do know that Silicon Graphics was unique among workstation manufacturers
for having a solid Ada toolset long before anyone else did.
Software development very much WAS the schedule driver on F-16C/D. First
flight was a year late because the software came in a year behind schedule.
You better believe that caused some ruffled feathers. (I was told by an
old-timer there that it had something to do with a senior manager
arbitrarily carving a year out of the development schedule estimates...)
"Marin David Condic" <mcondic.a...@acm.org> wrote in message
news:av42sd$jje$1...@slb6.atl.mindspring.net...
Kevin Cline
> news:ba162549.03010...@posting.google.com...
> > from sad experience. Mine was trying to use Ada-83 to write Unix
> > applications with a Motif UI. Regardless of any superiority in
> > reliability, the scarcity of libraries and trained
> > programmers makes Ada too expensive for most commercial software
> > projects.
>
> In the very early 1980s, General Dynamics / Fort Worth Division started the
> F-16C/D program. This was a MAJOR upgrade of the airplane, involving, among
> other things, all new computers and all new software.
>
> Ada wasn't there yet, so they chose JOVIAL J73.
>
> At that time, there existed precisely one J73 compiler, and it didn't target
> EITHER of the processors they were designing into the airplane (Zilog Z8002
> and MIL-STD-1750A). They wound up having to let compiler development
> contracts to two (small) companies to develop toolsets.
>
> At that time, trained J73 programmers just plain didn't exist. GD/FW had to
> train every single programmer they hired for that project.
>
> Every time I hear someone grumbling about the scarcity of trained Ada
> programmers, I think about F-16C/D and JOVIAL, and I wonder how GD/FW ever
> managed to get that airplane off the ground, if training is so hard.
>
> I'm not even going to mention HAL/S, the Space Shuttle language, which to my
> (unclassified) knowledge was not used for anything else on the planet.
> Where does NASA (and the SEI Level 5 contractor) get trained HAL/S
> programmers?
I said "commercial software projects" -- i.e. projects undertaken in the
hope of making a profit, that have to be compatible with a large base
of existing software and systems, and that have to be delivered within
a few months of initiation. In other words, about 99% of the software
work in the world. Ada is a poor fit for these projects, and is therefore
unpopular.
The projects you mentioned are taxpayer-supported with software budgets
in the billions and initial delivery some years after project start.
NASA spends about $500 for every line of shuttle code changed.
With that kind of budget and timeline training costs can be absorbed.
Most projects can't afford it.
Mike Silva
as well as in general in the areas where Ada would excel, is
increasing much faster than such per-sloc reductions, so that total
software budgets (and overruns) are becoming larger, and significantly
so?
Does anybody know of DoD numbers that show the total amount they
spend, directly and indirectly, on software development per year?
Mike
"John R. Strohm" <str...@airmail.net> wrote in message news:<CF4C46E154A483BD.B6BD906C...@lp.airnews.net>...
tmo...@acm.org
>resist using.
PDAs? Consumer robots (beyond the Ada-subset => C for Lego)?
Small, cheap, embedded gadgets in general? If so, are there bindings?
John R. Strohm
Software budgets in ALL arenas are increasing, not just DoD, not just
Ada-advantaged. Compare the bloat in MS-DOS to the BLOAT in Windoze XP, and
in Windoze applications.
Budget overrurns happen for two reasons: 1) the problem is harder than they
thought, 2) the budget estimators estimated too low. Usually, problem 2)
occurs because management ORDERED the estimates trimmed for political
reasons.
Ted Dennison
> Not all the antipathy to Ada is irrational. Most of it comes
> from sad experience. Mine was trying to use Ada-83 to write Unix
> applications with a Motif UI. Regardless of any superiority in
> reliability, the scarcity of libraries and trained
> programmers makes Ada too expensive for most commercial software
> projects.
Odd. That's one of the few domains where Ada (even 83) is almost
ideal. I've done just that myself, and you can actually do Motif UI's
in Ada way quicker than you can in C (counting debugging), even if you
have *no* bindings to start with. UIL can do all the GUI work, and the
Ada "glue" code only needs a few UIL, Motif, and X routines bound (3
to load and paste the UI, plus one for any widget class you interact
with, if I remember correctly). The profusion of UIL GUI builders out
there pretty handily negates Ada's usual disadvantages with library
support.
Martin Dowie
The Symbian OS can use gcc, so GNAT shouldn't be outrageously difficult to
port to that.
Robert C. Leif
work for all of the processors supported by these operating systems. Since
ECMA is a legitimate standards organization, multiple chip vendors should be
considering developing code generators specific for the ECMA intermediate
language. If they are smart, they will hardwire the ECMA intermediate
language in a manner similar to the J code processors.
Bob Leif
-----Original Message-----
From: comp.lang...@ada.eu.org [mailto:comp.lang...@ada.eu.org]
On Behalf Of tmo...@acm.org
Sent: Friday, January 03, 2003 12:08 PM
To: comp.l...@ada.eu.org
Mike Silva
another look at ways to get more bang for the software buck, including
Ada (?, for skeptics) because the cost of software is going up.
Surely this is not a controversial, or even particularly insightful,
opinion :) True, it's not only DoD, but my comment doesn't rise or
fall on that fact -- it's only that DoD was mentioned in the message I
replied to, in particular:
> Two results from this experience:
> 1. DoD didn't want to gather and then hear facts
> 2. Language decisions are generally not made on the
> basis of -any facts- but rather management perception of
> "acceptability", "training costs", etc.
Mike
"John R. Strohm" <str...@airmail.net> wrote in message news:<277C0E266C8E20F4.834E7043...@lp.airnews.net>...
Kevin Cline
> kcli...@hotmail.com (Kevin Cline) wrote in message news:<ba162549.03010...@posting.google.com>...
> > Not all the antipathy to Ada is irrational. Most of it comes
> > from sad experience. Mine was trying to use Ada-83 to write Unix
> > applications with a Motif UI. Regardless of any superiority in
> > reliability, the scarcity of libraries and trained
> > programmers makes Ada too expensive for most commercial software
> > projects.
>
>
> Odd. That's one of the few domains where Ada (even 83) is almost
> ideal.
With no access to subprogram types, attaching Ada-83 subprograms to
widget callbacks was a real puzzle for me. At the time I was doing
the
work (1988) I had two buggy compilers, Verdix for Solaris and TeleSoft
for Silicon Graphics. Both were expensive, validated, and neither was
anywhere
near the quality of the free GNU C compiler. Within a week of
starting
to program in Ada I found legal code that one or the other compiler
rejected.
With no compiler supporting both the target architectures, I was left
to
deal with different pragmas for calling C functions,
different bindings to POSIX, different bindings to X windows,
and no bindings to Xt or Motif. Neither had a useful mapping of
Ada tasks to POSIX threads, but instead simulated multitasking within
a single kernel thread. This was useless for all practical purposes.
We were fortunate enough to have the TeleSoft GUI builder, which in
an indirect way allowed us to connect Ada subprograms to widget
callbacks.
After many years of C programming, it was nice to work in a language
where I was fairly sure that any code that compiled would probably
work. But most
of the problems with C were solved by the introduction of C++.
After a while I was comfortable with Ada. But the insular
viewpoint of the original Ada community meant that Ada just
wasn't helpful for the programs I needed to write.
Today, the features that Ada provides have little value
compared with the features that C++ provides and Ada lacks:
the STL, automatic template function instantiation, smooth
integration of user-defined and primitive datatypes, and
bindings to every API in existence.
Kevin Cline
> I don't know whether I can use this as a counterexample or not. My
> recollection is that Silicon Graphics was using Ada internally VERY early in
> their life, and they were keeping this VERY quiet because it was helping
> them, a lot, and they didn't really want anyone else to know.
I'm skeptical that Ada was ever very widely used at SGI.
> Rational used Ada internally, and it helped them a lot. They published
> their numbers, but the reaction at GD/FW was that it just wasn't possible to
> get those kinds of numbers.
At the time, Rational had an Ada compiler to sell, and not much else,
so their numbers are suspect.
> McDonnell-Douglas had been using assembly language on F-15. For the
> IFFC/Firefly demonstration, they jumped into Ada with both feet,
> enthusiastically, and reported very good numbers, for a digital flight
> control application.
I would certainly expect programming in Ada to be much more productive
than programming in assembly language!
Dmitry A. Kazakov
> Today, the features that Ada provides have little value
> compared with the features that C++ provides and Ada lacks:
> the STL, automatic template function instantiation,
Generics in any form is an illness of programming languages.
> smooth integration of user-defined and primitive datatypes,
Why do you think C++ is better in that respect? C++ OO model is badly flawed
as compared with Ada's one. In any case both Ada and C++ have primitive
types separated from user-defined types by a fire wall. The difference is
that Ada's design potentially allows to mend this, while in C++ it is
beyond repair.
> and bindings to every API in existence.
That's not language fault. This can be addressed to any language except C.
Even C++ suffers from that: you might need 'extern "C" {}' to call most of
API functions. You are unable to pass a class as a parameter etc.
--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de
Marin David Condic
news:3E15CF31...@cogeco.ca...
>
> In its day, I could see why embedded people had concerns (Ada is still
> a very large "language"). The largeness should not be a concern for
> general purpose use - GNAT just flies through compiles on my 1.2Ghz
> laptop. I can only image how fast it is on current technology.
>
code and if a compiler worked at all, it almost certainly wasn't targeted to
your embedded processor. If by some miracle it was, the large overhead could
kill you. Assuming you also had the tools needed to get an executable image
into the target - which would be a rather rash assumption at the time.
Things eventually got better, but not before validating everyone's
prejudices and guaranteeing that Ada would never get considered by a large
segment of the population.
Things have gotten better today but Ada still fails in the embedded world
for a variety of reasons. Sure, you can get good quality compilers that
target some of the larger processors in use today and you might even find
enough support tools to make the job relatively easy, but there are still
lots of tiny processors out there that Ada doesn't (and arguably, can't)
target and in general, Ada is pretty much totally ignored by the embedded
world. (A few notable exceptions out there - including myself.) So if Ada's
original requirements were aimed at satisfying the needs of embedded
development, it seems to have failed in that market. Did it fail because it
failed to satisfy *real* embedded requirements or did it fail for other
reasons? (Political, social, environmental, etc?) Probably a combination of
both.
>
> I think we've discussed this before-- the real reason IMHO is the lack
> of "library support". It is less an issue of the language, but more
> about the libraries and bindings. Being that Ada95 is different than
> C/C++, bindings come into just about everything (for both Windows
> and UNIX) -- speaking non-embedded world wise.
>
> Also a lack of a "generally accepted" container library (standard or
> not), is also a "fracturing component". I myself find the Booch
> components extremely useful, but many I suppose do not like the
> complexities of the instantiations required to use them.
>
If Ada woke up tommorrow with everything in it you describe above, it would
meet the general reaction of "Gee. That's interesting. C/C++ have had this
for years and we're already heavily invested in those technologies. What
else have you got?"
The problem here is not that Ada shouldn't strive to have those things, but
rather that these are just the entry price needed to even get in the game.
Its not enough to be able to supplant someone's heavy investment in other
technology. Whatever Ada does, it needs to become *better* than other
languages out there or nobody has any reason to want to switch. It might
even be necessary to rethink all of the library & binding stuff to do
something totally *different* or Ada is just another "Me Too!!!" player that
is going to be ignored because it will *never* be as good at binding to
something as the language the thing is written in (Unix, Motif, etc.)
> Is it possible that the generics in the _language_ needs to be
> researched to make container libraries more elegant? Or are the
> implementations of these (Booch?) the problem? Or are we too
> hard on the requirements?
>
I'd say pick one and start enhancing it. We can argue all day long and into
the night about what is the best way to ultimately come up with the
"perfect" container library. Doing that will insure we never have one. Grab
something as a model, get it under a tree that can be easily expanded to
include new things for different problem domains, build a reference
implementation and share it with all the vendors. That would get something
in use and start providing leverage for the developer.
>
> I think you could eventually sell Ada if the binding/library support
> was there. If developers could find all the bindings to the O/S,
> database, GUI and all that other cool Open Sourced set of libraries,
> then it becomes only a matter of language choice. The reality is that
> using Ada for general purpose work is still very much an uphill battle
> on most of these fronts, because the developer must become expert
> in writing bindings to existing libraries and often O/S facilities.
>
Agreed. And disagreed. As noted above, you need the bindings just to be a
player, but I think you've got to offer something *more* than just that to
sway someone away from what they already use. Also, I've never liked Ada
bindings to C libraries because while it is technically possible, itr always
feels like an unnatural act and demands that the Ada developer think like a
C programmer. It would be better if Ada could go down its own path and do
something new/different that got the same net effect as bindings might
produce, but do it in a way consistent with Ada and offering a *better*
answer.
>
> Embedded systems have their own challenge, because they are very much
> focused on efficiency with very limited resources. On the GP scene
> however, I don't believe this needs to be much of a factor.
>
Really? We're here talking about how great it will be one day when Ada
provides libraries and bindings and all that. Where are they? By the time
Ada succeeds in getting some of the useful things already found in numerous
other languages, the world has passed it by once again. Something needs to
be done with Ada to institutionally/culturally get it to react faster to the
marketplace or it will always be in "catch up" mode chasing the leaders
rather than *being* the leader.
I like Ada and want to see it succeed, but efforts need to be focused on
leapfrogging the competition if this is to happen.
Marin David Condic
>
> That pretty much sums up what type (1) critics said.
> Despite my making fun of them, I do think they have the makings of a
point.
> But donšt you think that (other things being equal - and that is what you
> are emphasizing) Ada *would* get them to market sooner?
>
They may be saying something else - or you're hearing something else, if you
find disagreements here. Your problem is the "Other things being equal"
part. They never are. Contemplating a project you want to take to market,
you look at what is available to you and quite often with C or C++, you've
got an OS, GUI, Database, etc. that are all written in C and can be
interfaced/embedded/whatever rather readily as long as you use C/C++ to do
the job. Sure you'll spend twice as long debugging the unholy mess, but
you'll have something to show the customer *much* sooner than the guys who
are working in Ada and spending the first 6 months developing the bindings,
libraries, utilities, etc., they'll need to just get to where you are at
when you open up the box and install the compiler. Sure your product will be
a piece of crap - but it will be the only thing available to the customer,
so he'll buy it and use it anyway and you'll have money in your pocket and a
customer locked in to your product just about the time the Ada guys are
going "Hey, we've got the bindings and libraries and tools now. Let's get
started building the app."
I don't think most companies build crap software because they *want* to.
They do it because they're using tools/methods that result in crap, but crap
that gets there quickly. Bringing them something that let them build
solid-gold apps just as quickly might persuade them to switch.
> I was even more depressed that type (2) critics, who did care about
quality,
> had the perception that Ada was a crutch for the talentless.
> This is so contrary to my own perception that I find it bewildering.
>
I've always been disappointed by the "Any *competent* programmer..."
argument, but not at all surprised. Back in the days of Shakespear there was
the "Any *competent* carpenter can do his job with an axe and doesn't need
that crutch you call a 'saw'..." Eventually, the crutch can win out because
it is providing leverage to the developer, so I don't get discouraged. Its
just that Ada's particular 'crutch' is not being perceived as a big enough
deal to warrant switching to Ada. So maybe Ada just needs to come up with a
bigger, better crutch?
Marin David Condic
that Sun did right with Java.
They spent a truckload of money advertizing Java when it first came out so
that people had a favorable impression of it and a willingness to look at
it.
They actually made some improvements over C/C++ that eliminated some of the
worst syntactic & semantic problems.
They provided truckloads of library code that leveraged development of GUI
based applications.
They promised and mostly delivered the ability to develop on one platform
and run on many.
They made the compiler available for the cost of a download so that anybody
could play the game.
They targeted a market with a real need (Internet apps) that wasn't being
addressed well by other languages.
In other words, they made it easy and desirable for people to try Java and
they delivered real development leverage over its nearest competitor. They
found a real need out there and filled it.
Ada *could* do the same, but not by trying to play a "me too" game or by
trying to be all things to all developers. Find a market with a real need
and start giving them real advantages and I think you'd see that market
start to move to Ada.
MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/
Send Replies To: m c o n d i c @ a c m . o r g
"I'd trade it all for just a little more"
-- Charles Montgomery Burns, [4F10]
======================================================================
Warren W. Gay VE3WWG <ve3...@cogeco.ca> wrote in message
news:3E15D2E2...@cogeco.ca...
John R. Strohm
news:<694A0F8ED8C6BEE3.22D30132...@lp.airnews.net>...
> > I don't know whether I can use this as a counterexample or not. My
> > recollection is that Silicon Graphics was using Ada internally VERY
early in
> > their life, and they were keeping this VERY quiet because it was helping
> > them, a lot, and they didn't really want anyone else to know.
>
> I'm skeptical that Ada was ever very widely used at SGI.
I don't have any data one way or the other to prove it. I observe that SGI
had a complete Ada toolset for their machines long before any of the other
Unix workstation companies did.
> > Rational used Ada internally, and it helped them a lot. They published
> > their numbers, but the reaction at GD/FW was that it just wasn't
possible to
> > get those kinds of numbers.
>
> At the time, Rational had an Ada compiler to sell, and not much else,
> so their numbers are suspect.
A few reports trickled out that other people using the R1000 were getting
similar numbers.
Also, it is very easy to reality-check the Rational numbers, to a rough
order of magnitude: Take the number of SLOC in the product, which they
reported, divide by the number of years the company had been in existence,
and you get SLOC/year. From there, it is utterly trivial to divide by trial
values of SLOC/man/year to estimate the number of programmers involved, and
then compare them to the company headcount and money burn rate.
The short answer is that Rational's numbers stand up under reality checking.
> > McDonnell-Douglas had been using assembly language on F-15. For the
> > IFFC/Firefly demonstration, they jumped into Ada with both feet,
> > enthusiastically, and reported very good numbers, for a digital flight
> > control application.
>
> I would certainly expect programming in Ada to be much more productive
> than programming in assembly language!
Their numbers were good even for high-order language development.
There is this, also. At the time, the conventional wisdom was that Ada
would not EVER be suitable for "real" embedded work. Using it for digital
flight controls *and* firecontrol, and doing a successful demonstration (gun
shootdown of a QF-102 drone from a 90 degree aspect: something that is
essentially impossible for a human pilot on his own), *AND* getting good
productivity numbers to boot, was a very solid counter to that belief.
Steve
news:mailman.1041664082....@ada.eu.org...
[snip]
Is there an Ada compiler targetted to the chips used by cell phones?
PDAs? Consumer robots (beyond the Ada-subset => C for Lego)?
Small, cheap, embedded gadgets in general? If so, are there bindings?
Funny you should ask.
I just purchased a Handspring Visor Platinum (PDA) to replace my Day Timer.
While I'm not planning on writing programs, I was curious as to what's
available for development.
It turns out the Visor uses a Motorola MC68VZ328 processor, one of the
variants of the 68K. You can download a version of gcc that includes what
is needed to program the visor, but the version referenced by handsprings
site uses a version of GCC prior to 3.0 so Ada is not included in the kit.
It may very well be possible to build a new version of GCC targeting PalmOS
(m68k-palmos-gcc). I am not aware of any run-time library support, but it
looks like building GNAT to target PalmOS may not be that difficult.
Since I'm not that interested in programming PDAs I don't plan on pursuing
it, but some ambitious soul might. I would be very suprised if ACT turned
down a request from a paying customer.
Steve
(The Duck)
Ted Dennison
> With no access to subprogram types, attaching Ada-83 subprograms to
> widget callbacks was a real puzzle for me. At the time I was doing
Damn near every compiler realised that fairly early on, and provided a
(non-standard) way to do that, documented in Appendex F (if I remember
correctly). However, 1988 is before my time, so I don't know if it
counts as "fairly early on".
> near the quality of the free GNU C compiler. Within a week of
> starting
> to program in Ada I found legal code that one or the other compiler
> rejected.
That's hardly anything you wouldn't have to deal with using C though. I
believe there *was* a C standard in 88, but you wouldn't have known it
to look at the compilers available. The same goes today for C++. The
most commonly used C++ compiler today (MSVC++ 6.0) is just barely over
60% compliant, which means its barely more of a C++ compiler than not. I
can tell you from sad experience that trying anything more than the most
basic of the STL examples in Stroustrup's book will fail miserably with it.
> work. But most
> of the problems with C were solved by the introduction of C++.
Having worked with both, I'd say that is just true. However, 60% less of
C's language-induced problems is not near enough. Plus, C++ adds several
new ones of its own, and even makes some of C's existing problems far
worse. (eg: Now unexpected implicit type casts can happen with *any*
type, not just the numeric ones)
> Today, the features that Ada provides have little value
> compared with the features that C++ provides and Ada lacks:
> the STL, automatic template function instantiation, smooth
I'd agree a bit with that. However, MSVC++ 6 doesn't really have this
feature either. A large amount of the compilers that do have it, do it
differently from each other. That effectively means you can't count on
it in portable code. That's why rule #1 in the Mozilla C++ portability
guide is "Don't use C++ templates". (see
http://www.mozilla.org/hacking/portable-cpp.htmll#dont_use_templates)
> integration of user-defined and primitive datatypes, and
> bindings to every API in existence.
I don't really consider this an issue. Bindings to anything that has a C
interface are almost trivial to generate.
Robert A Duff
> Generics in any form is an illness of programming languages.
Why?
- Bob
Hillel Y. Sims
"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
news:av6hla$cggao$1...@ID-77047.news.dfncis.de...
> Kevin Cline wrote:
>
> > Today, the features that Ada provides have little value
> > compared with the features that C++ provides and Ada lacks:
> > the STL, automatic template function instantiation,
>
> Generics in any form is an illness of programming languages.
As someone who uses C++ template functionality extensively, I find that a
very odd statement and completely inconsistent with my own experience. Can
you provide some rationale?
thanks,
hys
--
(c) 2003 Hillel Y. Sims
hsims AT factset.com
Hillel Y. Sims
news:wmFR9.111225$Y86.1...@news2.central.cox.net...
>That's why rule #1 in the Mozilla C++ portability
> guide is "Don't use C++ templates". (see
> http://www.mozilla.org/hacking/portable-cpp.htmll#dont_use_templates)
>
Why should anyone care about coding guidelines from a failed project though?
:-)
Ted Dennison
> "Ted Dennison" <denn...@telepath.com> wrote in message
> news:wmFR9.111225$Y86.1...@news2.central.cox.net...
>
>>That's why rule #1 in the Mozilla C++ portability
>>guide is "Don't use C++ templates". (see
>>http://www.mozilla.org/hacking/portable-cpp.htmll#dont_use_templates)
>>
>
>
> Why should anyone care about coding guidelines from a failed project though?
> :-)
A good point, but I'm not sure how it relates to Mozilla. I've been
using it for my main browser for over a year now, and personally think
its about the best thing since sliced bread.
If you don't have the latest alpha with the baesean spam filtering, you
are really missing out too. I get about 10-20 spams a day at this
address, since I don't believe in email address munging. That's *after*
the filtering my ISP does which catches about 40 a day (I'm *not*
joking. My ISP caught 37 for January 3). But I almost never have to look
at a spam any more. I think in the last week Mozilla let about 2 slip
through, and hit one false positive.
Robert C. Leif
the ECMA intermediate language. This is how Java and before that UCSD Pascal
facilitated hosting.
Bob Leif
-----Original Message-----
From: comp.lang...@ada.eu.org [mailto:comp.lang...@ada.eu.org]
On Behalf Of Steve
Sent: Saturday, January 04, 2003 9:50 AM
To: comp.l...@ada.eu.org
Subject: Re: Anybody in US using ADA ? One silly idea..
Dmitry A. Kazakov
> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
> news:av6hla$cggao$1...@ID-77047.news.dfncis.de...
>> Kevin Cline wrote:
>>
>> > Today, the features that Ada provides have little value
>> > compared with the features that C++ provides and Ada lacks:
>> > the STL, automatic template function instantiation,
>>
>> Generics in any form is an illness of programming languages.
>
> As someone who uses C++ template functionality extensively, I find that a
> very odd statement and completely inconsistent with my own experience. Can
> you provide some rationale?
In short generics is a meta language and no more than dressed macros used to
patch the source code. More elaborated:
1. Generics are static. You cannot have an object or dynamic-link library of
generics.
1.a. This kills code reuse at run-time.
1.b. You cannot have a true polymorphism with generics. [A fake, "static"
polymorphism was invented to hide the truth.]
1.c. You have geometric code size explosion if you consequently use
generics.
2. You have no ADT with generics. All generic types are hard-wired. In C++
you have only one generic type: "class". In Ada there are few: "private",
"range <>" etc. This is Stone Age. Theoretically one could leverage
generics to full ADT, but what for? It is much better to have a better ADT
in the core language and abadon generics.
3. Generics are inconsistent with type relationships. When you instantiate
something, this something is absolutely unrelated to everything else. A
generic container instantiated with a subtype will never become a subtype
of same container instantiated with the base type.
4. Generics are inconsistent with DbC. In C++ you just instantiate and pray.
In Ada it is better, but still you have reemergence of predefined
operations and other contract violations. The reason is clear, while the
core language operates with types and their relations, generics are sort
of: let's substitute one string for another and see if the result go
through the compiler. I think it was Kernigan and Ritchie who said that
preprocessor does not know C. Substitute generics for preprocessor and
language X for C.
5. Generics are unstructured and too powerful. They are comparable with
gotos. Gotos arbitrarely change control flow. Generics arbitrarely produce
new language objects. You can have a generic type, subroutine, package,
everything. The consequences of an instantiation is almost impossible to
predict. As with gotos, you should admit, that a program with generics is
very difficult to understand and maintain. [For C++ replace difficult to
impossible, because of automated instantiation]
6. Generics completely fall out of the language, because in fact they form a
meta-langauge. A generic object does not exist for the core language. What
could be done with a generic object? The answer is: nothing. One cannot
pass a generic function as a parameter to a normal function. Even a generic
parameter cannot be generic (:-)), only instances [= objects of the core
language] are allowed. So even as a meta-language, generics represent an
inconsistent one.
------------------------
A little of bad philosophy as a conclusion. (:-)) If we consider the
evolution of programming languages, we could note maybe unconscious, but
constant and very successfull attempts to solve the problem of
parametrization in a more civilized way than just by brute force of
preprocessing = generics.
A subroutine is parametrized by the values of the arguments [FORTRAN]
A subroutine is a value which can be a parameter [?]
A type is parametrized by the values of the discriminants [Ada 83]
A type set (=class-wide type) is parametrized by a type (=type tag) [OOPL
with dispatching]
In the end of this process we will need generics as much as we need gotos
now.
James S. Rogers
Are you also against the use of abstract tagged types?
Jim Rogers
chris.danx
> A good point, but I'm not sure how it relates to Mozilla. I've been
> using it for my main browser for over a year now, and personally think
> its about the best thing since sliced bread.
Couldn't agree more. Every release just keeps getting better - type
ahead find is quite useful and just one of the many things in Mozilla -
and suprisingly faster. Initially on Windows it was quite slow without
quicklaunch but last time I downloaded a release it was a little faster.
Haven't tried 1.3a on Windows yet, how is it?
> If you don't have the latest alpha with the baesean spam filtering, you
> are really missing out too.
Your post intrigued me so I've turned it on. Even if it knocks a few of
these (mostly Korean - oh to be an NTLWorld account holder is such a
joy...) spams on the head it'd be worth it. How do you get it to send
junk to a junk mail folder? The options are there but they're greyed
out so I don't know if it'll delete them or "junk folder" them. I would
like to keep an eye on it to see what it classifies as junk, so I've
turned on the log but can't see how to control where it send junk mail to.
> I get about 10-20 spams a day at this
> address, since I don't believe in email address munging. That's *after*
> the filtering my ISP does which catches about 40 a day (I'm *not*
> joking. My ISP caught 37 for January 3).
Is that all? I get 100+ spam a day and my ISP does no filtering :( I
get around 300emails a day in total, so spam accounts for 1/3 of emails
I recieve with the rest mostly mailing lists - gcc, gtkada, lfs, etc.
That is quite a lot of spam!!! :(((((((((((
> But I almost never have to look
> at a spam any more. I think in the last week Mozilla let about 2 slip
> through, and hit one false positive.
And that's just the prototype... <crosses fingers> :)
Cheers,
Chris
--
for personal replies change spamoff to chris
Hillel Y. Sims
your original point was "Generics in any form is an illness of programming
languages", let me try to address a few of your general issues w/r/t C++
templates at least..
"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
news:av9egl$dd34q$2...@ID-77047.news.dfncis.de...
> In short generics is a meta language and no more than dressed macros used
to
> patch the source code.
They are much more than dressed macros; there is also a great deal of
semantic context which is totally unavailable with macros.
>More elaborated:
>
> 1. Generics are static. You cannot have an object or dynamic-link library
of
> generics.
I have written and maintain a number of (large) dynamic-link libraries of
instantiations of C++ templates.
>
> 1.a. This kills code reuse at run-time.
This is therefore not necessarily true, based on the above.
>
> 1.b. You cannot have a true polymorphism with generics. [A fake, "static"
> polymorphism was invented to hide the truth.]
Depends on your definition of 'polymorphism'. I have done some interesting
things with compile-time polymorphism (inheriting a class from a template
base class of the derived type). Anyhow, I see compile-time static and
run-time dynamic polymorphism as complementary techniques which can provide
a greater amount of flexibility in combination than either alone.
>
> 1.c. You have geometric code size explosion if you consequently use
> generics.
I guess this depends on the instantiation model and a lot of other
variables. It is not inherently true with C++ templates.
>
> 4. Generics are inconsistent with DbC. In C++ you just instantiate and
pray.
> In Ada it is better, but still you have reemergence of predefined
> operations and other contract violations. The reason is clear, while the
> core language operates with types and their relations, generics are sort
> of: let's substitute one string for another and see if the result go
> through the compiler. I think it was Kernigan and Ritchie who said that
> preprocessor does not know C. Substitute generics for preprocessor and
> language X for C.
Sorry, I don't really follow this point at all.
>
> 5. Generics are unstructured and too powerful. They are comparable with
> gotos. Gotos arbitrarely change control flow. Generics arbitrarely produce
> new language objects. You can have a generic type, subroutine, package,
> everything. The consequences of an instantiation is almost impossible to
> predict. As with gotos, you should admit, that a program with generics is
> very difficult to understand and maintain. [For C++ replace difficult to
> impossible, because of automated instantiation]
Again, I can't really speak of Ada generics, but I maintain several sizeable
C++ libraries which make extensive use of templates. The amount of
functionality provided is far greater with much fewer lines of code than the
equivalent non-templated version would be. This complexity issue simply does
not seem to be inherent in the manner in which you imply, at least with C++
templates.
> 6. Generics completely fall out of the language, because in fact they form
a
> meta-langauge. A generic object does not exist for the core language. What
> could be done with a generic object? The answer is: nothing. One cannot
> pass a generic function as a parameter to a normal function. Even a
generic
> parameter cannot be generic (:-)), only instances [= objects of the core
> language] are allowed. So even as a meta-language, generics represent an
> inconsistent one.
>
The biggest research/growth area in C++ these days seems to be templates and
meta-programming. It is true there are some inconsistencies in the
meta-language, but they don't prevent a lot of interesting programming from
being done. If you have never seen the Boost Meta-Programming Library
(http://www.boost.org/libs/mpl/doc/), you might want to check it out
briefly; it demonstrates that quite a great deal can be done at compile-time
with uninstantiated generic meta-objects.
Anyhow, I will acknowledge that there are issues which need to be
addressed/understood for successful use of generics/templates, and some of
your points may be more oriented toward Ada than any other language, but I
remain fully unconvinced that true generics (not glorified macros) are
inherently a bad idea in any particular programming language.
Robert C. Leif
that are also part of a private tagged record. This structure can be
extended and manipulated. For instance, when dealing with hardware, Intel
input-output registers and memory locations can be 8, 16, and 32 bits. A
generic is a simple way to model this. In fact if it were possible, I would
greatly prefer generic constructs to pointers. I must note that generics can
be instantiated at run-time and, I believe, still be located on the heap. No
need for garbage collection. Oberon.NET, which is very new, has generics.
Bob Leif
-----Original Message-----
From: comp.lang...@ada.eu.org [mailto:comp.lang...@ada.eu.org]
On Behalf Of Dmitry A. Kazakov
Sent: Sunday, January 05, 2003 6:13 AM
To: comp.l...@ada.eu.org
Subject: Re: Anybody in US using ADA ? One silly idea..
Adrian Hoe
> To some extent, you're preaching to the choir. I agree that what is
really
> important is not the language or toolsets you use, but your
abilities as an
> engineer. But there is the other side of the coin. All professions
> specialize to some extent and just as a doctor who specialized in
gynocology
> might have a hard time switching to proctology and beginning to
work in an
> entirely new field, so is it true that a programmer who has
specialized in
> Ada and some Ada toolset might have a bit of work making the
transition to
> some other language/toolset/problem domain. And even if one
dismisses this
> as not that big a deal, there's still this nasty problem called
"Reality".
> Job postings try to look for very specific skills and hiring managers
> generally don't want to consider someone unless they match their job
> description very closely. The fact that you can adapt and don't
think that
> this is a big deal doesn't matter because the people making those
decisions
> *do* think its a big deal. Life is often not fair, eh?
I find that programmers specialized in other programming
languages/toolsets have strong resistance against Ada and require more
effort to learn Ada. OTOH, programmers specialized in Ada
and Ada toolsets have the abilities making transition to some other
languages/toolsets with little effort.
Therefore, I would suggest Universities to teach Ada as the first
language. Ada can help students to understand programming languages,
--
type Dmitry is new Adrian; -- Adrian Hoe
-- http://adrianhoe.com
-- Remove *nospam* to email
Adrian Hoe
>>Job postings try to look for very specific skills
>>
> The necessary implication being that the design has already been
> frozen - "we will be using this language, that database, this kind
> of UI, ...".
> I read an interesting essay recently that pointed out that color TV,
> UHF, and cable were all technically feasible in 1948 when TVs were
in less
> than 1% of American households. But we had three black and white VHF
> network channels for a very long time because of industry
structure&power
> reasons. I suppose there were lots of job postings for B/W VHF tuner
> designers, and few for people who knew UHF etc.
>
Another identical twin - Betamax vs. VHS. Betamax (Ada) was more
expensive although it had better playback quality than VHS (C/C++)
which was cheaper. It was the price that put VHS into every living
rooms. Today, some professionals (high-end) still use Betamax.
If there were Turbo Ada in the mid/late 80's, Ada could have been a
mainstream programming language today. If there were M$ Visual Ada,
Ted Dennison
> joy...) spams on the head it'd be worth it. How do you get it to send
> junk to a junk mail folder? The options are there but they're greyed
> out so I don't know if it'll delete them or "junk folder" them. I would
> like to keep an eye on it to see what it classifies as junk, so I've
> turned on the log but can't see how to control where it send junk mail to.
Well...it is just an alpha right now. Presumably all that stuff will be
turned on by the final release of 1.3. What I do for now is make my own
"Junk" filter that moves all messages marked as junk into a junk folder.
Unfortunately, it appears to run the baesean marker *after* rules, so I
have to do an "<alt>t r" to get it to run the rules again. Clearly
that's not as nice as it will be once the ghosted options get turned on.
Still, 2 keystrokes to separate out all the chaff is way better having
to deal with each message individually.
You don't want to actually *delete* all the junk, as the filter uses
your past junk to recognise future junk.
Kevin Cline
>
> > Today, the features that Ada provides have little value
> > compared with the features that C++ provides and Ada lacks:
> > the STL, automatic template function instantiation,
>
> Generics in any form is an illness of programming languages.
>
> > smooth integration of user-defined and primitive datatypes,
>
> Why do you think C++ is better in that respect?
Because all operations applicable to C++ fundamental types can be made
to work for user-defined types. Ada's fundamental types have
attributes, but those attributes can not be provided for user-defined
types. This makes generic programming in Ada more difficult than
generic programming in C++.
> C++ OO model is badly flawed
> as compared with Ada's one. In any case both Ada and C++ have primitive
> types separated from user-defined types by a fire wall. The difference is
> that Ada's design potentially allows to mend this, while in C++ it is
> beyond repair.
You need to substantiate this claim; I have found the opposite to be
true.
>
> > and bindings to every API in existence.
>
> That's not language fault.
I didn't say that it was a language flaw. But it makes Ada more
difficult
to integrate with existing APIs.
> This can be addressed to any language except C.
> Even C++ suffers from that: you might need 'extern "C" {}' to call most of
> API functions.
Generally I don't have to supply "extern C ... " because the most
header
files handle the problem. Even if they don't, I can simply say:
extern "C" {
#include "someAPI.h"
}
rather than redeclaring every one of the functions needed.
Kevin Cline
That document is now almost five years old. Two years before that I
was working on template code that compiled on HP/UX, IBM AIX, Solaris,
and MSVC 5.0. Today most template code is portable, except for a
couple of
features not implemented by MSVC 6.0. I think that Microsoft Ada
supports an even smaller subset of the Ada language.
> > integration of user-defined and primitive datatypes, and
> > bindings to every API in existence.
>
> I don't really consider this an issue. Bindings to anything that has a C
> interface are almost trivial to generate.
Do you mean they can be generated automatically?
Ted Dennison
>That document is now almost five years old. Two years before that I
becase nothing in there has needed changing. That is *still* the policy
at Mozilla.
> and MSVC 5.0. Today most template code is portable, except for a
> couple of
> features not implemented by MSVC 6.0.
More than a couple. None of the function generators work at all (try
using a "for all" or "for each" template to insert something into or
delete something from a container based on a predicate, which is pretty
much what they were created for. It doesn't work.), and automatic
instantiation doesn't work except in trivial cases. Large portions of
boost are unusable too. Lots of the stuff that *is* usable requires you
to manually specify the template parameters (because its
auto-instantiation sucks). The only way you could possibly make any
reasonably complicated template code "portable" is with conditional
compliation, or by going out of your way to use the least-common
denominator. With 2 or 3 platforms that you know about ahead of time you
might be able to do that. Mozilla has to work with so many different
sucky C++ compilers that the least common denominator is no templates at
all.
> I think that Microsoft Ada
> supports an even smaller subset of the Ada language.
That's a very good way of describing Microsoft C++ too. :-)
>>I don't really consider this an issue. Bindings to anything that has a C
>>interface are almost trivial to generate.
>
>
> Do you mean they can be generated automatically?
Well...yes there are such generators about, but no, that's not what I
meant. I typically prefer to create my *own* bindings by hand, and have
no compunction about doing so, even when good bindings are already
available. That's what I mean by "almost trivial". Its about the same
amount of work as writing external funtion prototypes in C.
Dmitry A. Kazakov
> I disagree! A very simple construct is a generic set of types and objects
> that are also part of a private tagged record. This structure can be
> extended and manipulated.
Why to put something into anything else? Why not to have the tagged record
doing everything what you want from the start?
> For instance, when dealing with hardware, Intel
> input-output registers and memory locations can be 8, 16, and 32 bits. A
> generic is a simple way to model this.
An abstract integer type with three non-abstract descendants is even more
simple model. My point is that almost everything you do with generics could
be done with ADT.
> In fact if it were possible, I
> would greatly prefer generic constructs to pointers. I must note that
> generics can be instantiated at run-time and, I believe, still be located
> on the heap. No need for garbage collection. Oberon.NET, which is very
> new, has generics. Bob Leif
--
Dmitry A. Kazakov
> Are you also against the use of abstract tagged types?
By no means. It would mean that I am against generic programming. I am
against overusing generics in generic programming.
In my view tagged types are a real alternative to generics. We have T'Class
which denotes a set of types as "digits <>" or "private" does. But they
need a long way to evolve before they will supersede generics in things
like STL.
Dmitry A. Kazakov
> I can't really speak much for experience with generics in Ada, but since
> your original point was "Generics in any form is an illness of programming
> languages", let me try to address a few of your general issues w/r/t C++
> templates at least..
>
> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
> news:av9egl$dd34q$2...@ID-77047.news.dfncis.de...
>> In short generics is a meta language and no more than dressed macros used
> to
>> patch the source code.
>
> They are much more than dressed macros; there is also a great deal of
> semantic context which is totally unavailable with macros.
>
>>More elaborated:
>>
>> 1. Generics are static. You cannot have an object or dynamic-link library
> of
>> generics.
>
> I have written and maintain a number of (large) dynamic-link libraries of
> instantiations of C++ templates.
Note that "instantiations of" is not what follows "of". A library of
instantiations is not a library of templates.
>> 1.a. This kills code reuse at run-time.
>
> This is therefore not necessarily true, based on the above.
No, you cannot reuse code across instantiations. Each of them is a macro
expansion which has a separate body. Theoretically one could share generic
bodies [at least in Ada it is sometimes possible], but practically it is
not the case.
>> 1.b. You cannot have a true polymorphism with generics. [A fake, "static"
>> polymorphism was invented to hide the truth.]
>
> Depends on your definition of 'polymorphism'. I have done some interesting
> things with compile-time polymorphism (inheriting a class from a template
> base class of the derived type). Anyhow, I see compile-time static and
> run-time dynamic polymorphism as complementary techniques which can
> provide a greater amount of flexibility in combination than either alone.
The time of binding (dispatch in a polymorphic call) is an *implementation*
detail. If the type information is known at compile-time, then, at least in
Ada, dispatch happens at compile time.
>> 1.c. You have geometric code size explosion if you consequently use
>> generics.
>
> I guess this depends on the instantiation model and a lot of other
> variables. It is not inherently true with C++ templates.
If you bind at compile time then this is just a consequence.
>> 4. Generics are inconsistent with DbC. In C++ you just instantiate and
> pray.
>> In Ada it is better, but still you have reemergence of predefined
>> operations and other contract violations. The reason is clear, while the
>> core language operates with types and their relations, generics are sort
>> of: let's substitute one string for another and see if the result go
>> through the compiler. I think it was Kernigan and Ritchie who said that
>> preprocessor does not know C. Substitute generics for preprocessor and
>> language X for C.
>
> Sorry, I don't really follow this point at all.
template <class X> class Y
{
public :
X max (X A, X B) { if (A > B) return A; else return B; }
};
What ensures that X has ">"? There is no word about a contract, because
"class X" means anything. In FORTRAN-IV you also can pass an INTEGER*4
instead of REAL*4. I remember some people claiming that this is a very
useful feature.
>> 5. Generics are unstructured and too powerful. They are comparable with
>> gotos. Gotos arbitrarely change control flow. Generics arbitrarely
>> produce new language objects. You can have a generic type, subroutine,
>> package, everything. The consequences of an instantiation is almost
>> impossible to predict. As with gotos, you should admit, that a program
>> with generics is very difficult to understand and maintain. [For C++
>> replace difficult to impossible, because of automated instantiation]
>
> Again, I can't really speak of Ada generics, but I maintain several
> sizeable C++ libraries which make extensive use of templates. The amount
> of functionality provided is far greater with much fewer lines of code
> than the equivalent non-templated version would be. This complexity issue
> simply does not seem to be inherent in the manner in which you imply, at
> least with C++ templates.
Code density and simplicity of language constructs do not imply
maintainability. What could be simplier than "JMP $1034"?
>> 6. Generics completely fall out of the language, because in fact they
>> form
> a
>> meta-langauge. A generic object does not exist for the core language.
>> What could be done with a generic object? The answer is: nothing. One
>> cannot pass a generic function as a parameter to a normal function. Even
>> a
> generic
>> parameter cannot be generic (:-)), only instances [= objects of the core
>> language] are allowed. So even as a meta-language, generics represent an
>> inconsistent one.
>
> The biggest research/growth area in C++ these days seems to be templates
> and meta-programming. It is true there are some inconsistencies in the
> meta-language, but they don't prevent a lot of interesting programming
> from being done. If you have never seen the Boost Meta-Programming Library
> (http://www.boost.org/libs/mpl/doc/), you might want to check it out
> briefly; it demonstrates that quite a great deal can be done at
> compile-time with uninstantiated generic meta-objects.
>
> Anyhow, I will acknowledge that there are issues which need to be
> addressed/understood for successful use of generics/templates, and some of
> your points may be more oriented toward Ada than any other language, but I
> remain fully unconvinced that true generics (not glorified macros) are
> inherently a bad idea in any particular programming language.
A need in a meta language indicates that the core language is incomplete.
Then the question is only whether this incompleteness is inherent or not.
As long as the former is not proved I will claim that we do not need a meta
language.
Dmitry A. Kazakov
> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
> news:<av6hla$cggao$1...@ID-77047.news.dfncis.de>...
>> Kevin Cline wrote:
>>
>> > Today, the features that Ada provides have little value
>> > compared with the features that C++ provides and Ada lacks:
>> > the STL, automatic template function instantiation,
>>
>> Generics in any form is an illness of programming languages.
>>
>> > smooth integration of user-defined and primitive datatypes,
>>
>> Why do you think C++ is better in that respect?
>
> Because all operations applicable to C++ fundamental types can be made
> to work for user-defined types. Ada's fundamental types have
> attributes, but those attributes can not be provided for user-defined
> types.
Some of them, to be correct. There are overridable attributes. Note also
that Ada offers much more "standard" operations than C++. I agree that
every of them has to be a primitive overridable operation, but the burden
of Ada 83 is heavy. Then some of things are difficult to make. Consider
aggregates. Can C++ override them? Consider indefinite types. Does C++ have
them? Consider short circuit operations. In C++ you can override it but you
loose its property.
> This makes generic programming in Ada more difficult than
> generic programming in C++.
I disagree. Generic programming is not equal to programming with generics.
It is programming for type sets. Ada's class-wide types are much more
consistent and powerful that flawed C++ OO model.
>> C++ OO model is badly flawed
>> as compared with Ada's one. In any case both Ada and C++ have primitive
>> types separated from user-defined types by a fire wall. The difference is
>> that Ada's design potentially allows to mend this, while in C++ it is
>> beyond repair.
>
> You need to substantiate this claim; I have found the opposite to be
> true.
1. C++ does not distingush a specific type from a types set.
2. In C++ you can dispatch on exactly one parameter
3. The dispatching parameter cannot be result. So all functions are
contravariant
4. In C++ you cannot return a class-wide parameter otherwise than through a
pointer
5. Because of 1. there is no way to deal with ALL types in same way. For
instance, int is not a class and will never be one.
6. Because of 2. you cannot implement binary operations properly
>> > and bindings to every API in existence.
>>
>> That's not language fault.
>
> I didn't say that it was a language flaw. But it makes Ada more
> difficult
> to integrate with existing APIs.
>
>> This can be addressed to any language except C.
>
>> Even C++ suffers from that: you might need 'extern "C" {}' to call most
>> of API functions.
>
> Generally I don't have to supply "extern C ... " because the most
> header
> files handle the problem. Even if they don't, I can simply say:
>
> extern "C" {
> #include "someAPI.h"
> }
>
> rather than redeclaring every one of the functions needed.
Really? And what about stdcall vs. cdecl? Parameter passing conventions
could be well different from what extern "C" does.
I would agree with you, should you say: many API are written in C which
allows a smooth integration into a C program provided that the compiler and
linker are of same vendor as API, or a sort of standard was involved. Then
because MS is a monopolist and all poor programmers have to use MS VC++,
then ...
Wes Groleau
> sway someone away from what they already use. Also, I've never liked Ada
> bindings to C libraries because while it is technically possible, itr always
> feels like an unnatural act and demands that the Ada developer think like a
> C programmer. It would be better if Ada could go down its own path and do
Like we did with POSIX--declared _one_ exception, and after it's
raised you examine a global variable to find out what actually
happened.
I see your point about "leapfrogging the competition" _but_
anything new has to actually be not only new but self-contained.
If you make a new web server, it still has to interoperate with
most of the things other webservers work with, or it won't get
used. And it isn't being used, is it? Sure, by Ada fans, but
that's not the point.
How about TopGraph'X - is it a better X-server?
How many of them have been installed compared to
the number of X-servers in (the) other language(s)?
If they're better and they do interoperate,
why are they not being used? Anonymity?
Wes Groleau
>>>smooth integration of user-defined and primitive datatypes,
>>
>>Why do you think C++ is better in that respect?
>
> Because all operations applicable to C++ fundamental types can be made
> to work for user-defined types. Ada's fundamental types have
> attributes, but those attributes can not be provided for user-defined
> types. This makes generic programming in Ada more difficult than
> generic programming in C++.
I don't know C++ very well, but this complaint
about Ada is true--at least partially. I do
understand C and Java, so I'll risk interpolating
to C++ ....
Does C++ have subtypes and derived types? The lack
of such in Java is really a pain. And these DO inherit
attributes from parent types. But I wish I could
define things like 'First and 'Last when I create a
private type for which they are meaningful.
It would also be nice to be able to redefine 'Size
for an access type or record containing an access type.
But these are minor issues.
Wes Groleau
> generics.
>
> 1.a. This kills code reuse at run-time.
Weakens it, but does not "kill" it.
I can instantiate a generic at run-time.
And that generic can instantiate another
generic or give actuals to another generic.
Where is the body code for the following instantiations?
-- Admittedly, this is a pretty unlikely scenario!
procedure Demo (First : Natural) is
type Weird_Num is range First .. Last_Function (First);
type Weird_Record is
record
Field_That : .....;
Did_Not : Weird_Num;
Exist_Before : .....;
end record;
This_Is_It : Weird_Record;
package Temporary is new Wierd_Thing (Weird_Num, Weird_Record);
function Make_Weird is
new Oddball (Weird_Num, Temporary.Weird_Function);
begin
....; -- Generate the contents of This_Is_It.
Ada.Text_IO.Put_Line (Temporary.Image_Of (Make_Weird (This_Is_It));
Wes Groleau
> joking. My ISP caught 37 for January 3). But I almost never have to look
> at a spam any more. I think in the last week Mozilla let about 2 slip
> through, and hit one false positive.
Can it catch them just by headers, or does it evaluate
for spam AFTER it downloads the entire piece of crap,
complete with HTML bloat (generated by Microsoft Word
or some equally lame thing that toggles styles on and
off multiple times on every line) and all the stupid
graphic attachments?
I just route my mail through despammed.com - a free
forwarding service. I see one or two spams per month.
There are other such services. One is myrealbox.com.
Another is mailircuit.com (although I haven't seen it
in a year, and it might have become a pay service).
Can Mozilla spam-check the mail and then hand it off
to the mail-reader I prefer?
Georg Bauhaus
: Oberon.NET, which is very new, has generics.
of a different sort.
Larry Kilgallen
> How about TopGraph'X - is it a better X-server?
> How many of them have been installed compared to
> the number of X-servers in (the) other language(s)?
I thought it was a replacement for the Motif Library rather than
for the Xwindows server.
chris.danx
> Well...it is just an alpha right now. Presumably all that stuff will be
> turned on by the final release of 1.3. What I do for now is make my own
> "Junk" filter that moves all messages marked as junk into a junk folder.
> Unfortunately, it appears to run the baesean marker *after* rules, so I
> have to do an "<alt>t r" to get it to run the rules again. Clearly
> that's not as nice as it will be once the ghosted options get turned on.
> Still, 2 keystrokes to separate out all the chaff is way better having
> to deal with each message individually.
Nice tip, thanks Ted. Hey... they changed the filter dialogues. It's
much easier to select and create folders now! :)
> You don't want to actually *delete* all the junk, as the filter uses
> your past junk to recognise future junk.
I wasn't suggesting to delete them, I want it to move them just incase
there's an important false positive, but wasn't entirely sure how the
junkmail filter worked - if it deleted, flagged or moved them. After
reading up a bit, it flags them which is good! Like you say it would be
better if it applied the spam filter prior to applying rules, and this
is my only quibble with it - it's picking up junk already and being
trained on the rest!
James S. Rogers
news:YRhS9.215$Z74...@dfw-service2.ext.raytheon.com...
>
> I don't know C++ very well, but this complaint
> about Ada is true--at least partially. I do
> understand C and Java, so I'll risk interpolating
> to C++ ....
>
> Does C++ have subtypes and derived types? The lack
Not in the Ada sense.
C++, supporting OOP, does allow you to create your own classes
and inherit from those classes. It does not allow you to create your
own primitive types or derive directly from primitive types.
C++ does not support anything like
type Voltages is digits 15 range -4.0..40.;
type Strange is new Integer range -123..1024;
Nor does it support anything like
subtype Natural is Integer range 0..Integer'Last;
> of such in Java is really a pain. And these DO inherit
> attributes from parent types. But I wish I could
> define things like 'First and 'Last when I create a
> private type for which they are meaningful.
Of course, 'First and 'Last imply a range. Ranges imply
discrete values. How would you describe the range for
a type that is not discrete? This would imply the ability to
define discontinuous ranges. Although that ability seems
convenient for the programmer, I have no idea how it could
be implemented by the compiler writer in an efficient and
general manner.
> It would also be nice to be able to redefine 'Size
> for an access type or record containing an access type.
> But these are minor issues.
Defining 'Size for an access type would require a consistent
implementation of access types across all compilers. Remember
that an access type need not be implemented as a pointer.
Ada makes a strong distinction between an access type and a
value of type System.Address.
Jim Rogers
Warren W. Gay VE3WWG
> Warren W. Gay VE3WWG <ve3...@cogeco.ca> wrote in message
> news:3E15CF31...@cogeco.ca...
>
>>In its day, I could see why embedded people had concerns (Ada is still
>>a very large "language"). The largeness should not be a concern for
>>general purpose use - GNAT just flies through compiles on my 1.2Ghz
>>laptop. I can only image how fast it is on current technology.
>
> Back when Ada was first emerging, compilers were generating really crappy
> code and if a compiler worked at all, it almost certainly wasn't targeted to
> your embedded processor. If by some miracle it was, the large overhead could
> kill you. Assuming you also had the tools needed to get an executable image
> into the target - which would be a rather rash assumption at the time.
> Things eventually got better, but not before validating everyone's
> prejudices and guaranteeing that Ada would never get considered by a large
> segment of the population.
I guess this problem exists even today for certain processor models. I think
of a small single chip CPU like the Motorola MC68705 where you may only
have 2kb worth of EPROM to place your code in. Its difficult to imagine
much Ada95 code compiling into 2k, but that is not to say it couldn't be
done. Its a stretch even for assembly code, depending upon what it must
accomplish ;-) I havn't worked with the PIC chips, but there again, I
suspect that it would be a challenge.
But surely for larger processors, it is simply a matter of vendor
support (and market).
> Things have gotten better today but Ada still fails in the embedded world
> for a variety of reasons. Sure, you can get good quality compilers that
> target some of the larger processors in use today and you might even find
> enough support tools to make the job relatively easy, but there are still
> lots of tiny processors out there that Ada doesn't (and arguably, can't)
> target and in general, Ada is pretty much totally ignored by the embedded
> world. (A few notable exceptions out there - including myself.) So if Ada's
> original requirements were aimed at satisfying the needs of embedded
> development, it seems to have failed in that market. Did it fail because it
> failed to satisfy *real* embedded requirements or did it fail for other
> reasons? (Political, social, environmental, etc?) Probably a combination of
> both.
Free compilers might give it a chance... but part of the problem is that
I don't see enough Open Sourced Ada enthusiasts chomping at the bit for
a project like this ;-)
>>I think we've discussed this before-- the real reason IMHO is the lack
>>of "library support". It is less an issue of the language, but more
>>about the libraries and bindings. Being that Ada95 is different than
>>C/C++, bindings come into just about everything (for both Windows
>>and UNIX) -- speaking non-embedded world wise.
>>
>>Also a lack of a "generally accepted" container library (standard or
>>not), is also a "fracturing component". I myself find the Booch
>>components extremely useful, but many I suppose do not like the
>>complexities of the instantiations required to use them.
>
> If Ada woke up tommorrow with everything in it you describe above, it would
> meet the general reaction of "Gee. That's interesting. C/C++ have had this
> for years and we're already heavily invested in those technologies. What
> else have you got?"
The "what else have you got?" I think can be explained in the way of
the compiler and language benefits (all else being equal). Ultimately
the siren song of lower total costs and faster to market sell.
But if the Ada95 user has to start building a database binding, a GUI
binding and an O/S binding just to get started on the _application_
(that is supposed to bring the tangible real benefit), then he's
going to sigh and give up. This leads to taking a path of lower
resisitance, no matter that it may be the road to hell ;-)
> The problem here is not that Ada shouldn't strive to have those things, but
> rather that these are just the entry price needed to even get in the game.
Agreed.
> Its not enough to be able to supplant someone's heavy investment in other
> technology. Whatever Ada does, it needs to become *better* than other
> languages out there or nobody has any reason to want to switch.
If the libraries/bindings were there, then the differences _would_ be
at the superiority of the language/compiler. The problem is, that no
one cares about this issue because X or Y is not available at the
library support level. This is seen as a more fundamental requirement.
> It might
> even be necessary to rethink all of the library & binding stuff to do
> something totally *different* or Ada is just another "Me Too!!!" player that
> is going to be ignored because it will *never* be as good at binding to
> something as the language the thing is written in (Unix, Motif, etc.)
I don't see this as an issue. Java has all of these same issues, but
people look past this because it is "new" and is considered "the
thing to do(TM)".
> I'd say pick one and start enhancing it.
Well I have picked the Booch components for my work, but that hardly
does anything for the rest of the community ;-)
> We can argue all day long and into
> the night about what is the best way to ultimately come up with the
> "perfect" container library.
Agreed.
> Doing that will insure we never have one.
Yep.
> Grab
> something as a model, get it under a tree that can be easily expanded to
> include new things for different problem domains, build a reference
> implementation and share it with all the vendors. That would get something
> in use and start providing leverage for the developer.
That would be a good thing. Another workable approach is to get an
Ada package distribution going. I can't start one yet, but if I
find enough time, I may. I see this as being important. Right now
to compile any major Open Source project requires the end user to
download this, that and another package from this, that and another
web site in shopping cart fashion. THe poor user must then get them
all compiled and installed correctly. If all goes well, he might
get your project compiled and then installed correctly. I see this
as a horrible way to introduce C/C++ types to the "Ada way".
Mind you, this type of thing is done in the C/C++ world too, but
often times the Linux/*BSD distributions have already done the
bulk of the work for you. If not, then a "make install" does the
rest.
How many Linux distributions do you know that include the Booch
components or Florist installed as ready to compile against
Ada packages/libraries? We are missing the boat here.
>>I think you could eventually sell Ada if the binding/library support
>>was there. If developers could find all the bindings to the O/S,
>>database, GUI and all that other cool Open Sourced set of libraries,
>>then it becomes only a matter of language choice. The reality is that
>>using Ada for general purpose work is still very much an uphill battle
>>on most of these fronts, because the developer must become expert
>>in writing bindings to existing libraries and often O/S facilities.
>>
>
> Agreed. And disagreed. As noted above, you need the bindings just to be a
> player, but I think you've got to offer something *more*
Again, I think the "more" is the language benefits that are often
espoused here. But if the "other" is not equal or better, no one
wants to talk about the language features.
> than just that to
> sway someone away from what they already use. Also, I've never liked Ada
> bindings to C libraries because while it is technically possible, itr always
> feels like an unnatural act and demands that the Ada developer think like a
> C programmer. It would be better if Ada could go down its own path and do
> something new/different that got the same net effect as bindings might
> produce, but do it in a way consistent with Ada and offering a *better*
> answer.
I advocate thick bindings to O/S and other features (MOTIF etc.) Anything
less, is a nightmare in Ada (agreed). Certainly the thick bindings can
build on thin bindings, but only the thick bindings should be used in
application level code (IMHO). The reality at some levels however,
is that some O/S features may not map that well. But I still see thick
bindings reducing this to a minimum.
>>Embedded systems have their own challenge, because they are very much
>>focused on efficiency with very limited resources. On the GP scene
>>however, I don't believe this needs to be much of a factor.
>
> Really? We're here talking about how great it will be one day when Ada
> provides libraries and bindings and all that. Where are they?
I am not sure what you are reacting to here, but basically my statement
was meant to convey the idea that for general purpose programming, there
doesn't need to be any Ada "issues" (save for the bindings/libraries).
Compiler availability, and fast CPUs eliminate much of the "compiler
issue". I didn't state this well in the above paragraph ;-)
> By the time
> Ada succeeds in getting some of the useful things already found in numerous
> other languages, the world has passed it by once again. Something needs to
> be done with Ada to institutionally/culturally get it to react faster to the
> marketplace or it will always be in "catch up" mode chasing the leaders
> rather than *being* the leader.
>
> I like Ada and want to see it succeed, but efforts need to be focused on
> leapfrogging the competition if this is to happen.
Well, let's get a group to organize an "Ada Package Distribution". I may
be forced to do it myself, but I would rather spend my free time on
developing Open Sourced Ada applications, if possible. I have already
booked my free time for the next forseeable 6 months. I have even hatched
a name for this distribution, which I would gladly give away to
someone/group that would take on this worthy cause ;-)
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg
Randy Brukardt
>>> 1.a. This kills code reuse at run-time.
>>
>> This is therefore not necessarily true, based on the above.
>
>No, you cannot reuse code across instantiations. Each of them is a
macro
>expansion which has a separate body. Theoretically one could share
generic
>bodies [at least in Ada it is sometimes possible], but practically it
is
>not the case.
Bull.
You just need to use a different compiler. Ada /= GNAT!
Janus/Ada 95 shares all generic bodies. That's probably too aggressive,
but it's too expensive to change.
Dan Eilers will tell you that their compiler (ICC) shares generic bodies
(I believe unless pragma Inline is used on the generic).
Many Ada 83 compilers shared generic bodies, include DEC and Rational.
It's harder in Ada 95, but if there was any significant demand,
compilers would have it.
Randy Brukardt.
Pascal Obry
"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:
> An abstract integer type with three non-abstract descendants is even more
> simple model. My point is that almost everything you do with generics could
> be done with ADT.
I'm not sure what you have in mind, but ADT and generics are orthogonal
notion. In fact a lot of generic components are designed as ADT. The fact
that 'A' stand for abstract has nothing to do the "abstract" Ada keywords or
OO feature.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
Randy Brukardt
<1ciS9.217$Z74....@dfw-service2.ext.raytheon.com>...
>
>> joking. My ISP caught 37 for January 3). But I almost never have to
look
>> at a spam any more. I think in the last week Mozilla let about 2 slip
>> through, and hit one false positive.
>
>Can it catch them just by headers, or does it evaluate
>for spam AFTER it downloads the entire piece of crap,
>complete with HTML bloat (generated by Microsoft Word
>or some equally lame thing that toggles styles on and
>off multiple times on every line) and all the stupid
>graphic attachments?
Actually, most spam these days are short HTML messages with little or no
text. There isn't much load on the server from them. Simply blocking
HTML graphics gets rid of many of them. Also, a lot of spam is now
encoded in various ways so that simple text filters can't find them.
The big messages tend to be real or are viruses. (I'm seeing 3-5 viruses
a day in the various filters; most are sent to the public webmaster and
mailing list addresses we support.)
I know this well, because I wrote a spam-filtering plug-in for our
mailserver (in Ada, of course). Our mail server is receiving about 150
messages per day, of which the filter passes only about 15%. About 30%
are so frequent and obvious that I'm able to match them and autodelete
them. And many of those get caught by the (old) blacklist filtering,
which runs after my filter.
Randy Brukardt
Randy Brukardt
>If there were Turbo Ada in the mid/late 80's, Ada could have been a
>mainstream programming language today. If there were M$ Visual Ada,
Of course there *was* a Turbo-like Ada in the mid 80's. Indeed, there
were several companies vying for that market. The basic Janus/Ada system
cost $99 then; it was validated in 1987, but versions were available
before that. Indeed, we still have that compiler (Janus/Ada 83 for
MS-DOS) available for $129. Perhaps the product could have been better
or the marketing better, but certainly low-cost Ada compilers existed
from the mid 80's onwards.
Randy Brukardt.
Randy Brukardt
>If you make a new web server, it still has to interoperate with
>most of the things other webservers work with, or it won't get
>used. And it isn't being used, is it? Sure, by Ada fans, but
>that's not the point.
That's a lousy example. If you "interoperate" with those other things,
(i.e. plugins and CGIs), you're also bringing in the intractable
security problems of those other things.
That's precisely why I updated Tom Moran's web server to use for our
AdaIC backup server. It doesn't know how to execute another program (and
never will), so no one will ever be able to use it to launch Cmd.Exe, no
matter what garbage it is given. And most of the other security problems
you hear about can't happen, either. The only thing it writes is log
files, so an attacker can't use it to create files, either, no matter
what they do. About the worst that can happen is that they could use it
to cause a denial-of-service -- and given that it uses a set of Ada
tasks, even that would be fairly difficult.
Of course, it has to understand HTTP and make log files that analyzer
programs recognize, but the first is the definition of "web server" and
the latter is trivial.
But, all of that said, I think your basic point is correct.
Randy Brukardt.
Randy Brukardt
>Well, let's get a group to organize an "Ada Package Distribution". I
may
>be forced to do it myself, but I would rather spend my free time on
>developing Open Sourced Ada applications, if possible. I have already
>booked my free time for the next forseeable 6 months. I have even
hatched
>a name for this distribution, which I would gladly give away to
>someone/group that would take on this worthy cause ;-)
SigAda is supposedly working on setting up such a thing. Hopefully,
they'll succeed, because they are the right sort of organization to do
it: independent of the vendors; not a standards body (which would take
years) yet they have visibility and clout to get people to pay
attention.
Randy Brukardt
Richard Riehle
> I *THINK* that Lockheed-Martin Fort Worth is using Ada for F-22 and F-16.
> You might try looking at their web sight (http://www.lmco.com) and seeing
> what they are looking to hire. (Most of their effort appears to be trawling
> for resumes for Joint Strike Fighter, which is in C++.
This will eventually turn out to be one of the all time stupid software
engineering
decisions, one that will end up with lots of people blaming each other for a
series of cost-overruns, buggy software, and probably a lot of regrets.
However,
it is a decision that needs to be experienced so the managers can learn just how
hideous C++ is for this kind of software. One can only hope they do learn that
lesson and no one will get killed due to a software accident because of it.
Richard Riehle
Jerry van Dijk
Richard Riehle <ric...@adaworks.com> writes:
[on C++ for the JSF]
> However,
> it is a decision that needs to be experienced so the managers can learn just how
>
> hideous C++ is for this kind of software. One can only hope they do learn that
>
> lesson and no one will get killed due to a software accident because of it.
Right. And I am paying for that experience... Ugh.
(Dutch government is going to invest half a billion of our tax money in JSF
development)
--
-- Jerry van Dijk | email: jva...@attglobal.net
-- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk
Ted Dennison
>
>> joking. My ISP caught 37 for January 3). But I almost never have to
>> look at a spam any more. I think in the last week Mozilla let about 2
>> slip through, and hit one false positive.
>
>
> Can it catch them just by headers, or does it evaluate
> for spam AFTER it downloads the entire piece of crap,
> complete with HTML bloat (generated by Microsoft Word
> or some equally lame thing that toggles styles on and
> off multiple times on every line) and all the stupid
> graphic attachments?
Its the contents. Mozilla downloads your email (through pop3 or smtp or
whatever), then examines the contents. That's obviously not as ideal as
some kind of server-side filtering, but if you would have been
downloading that email anyway without it, it doesn't hurt you any either.
> I just route my mail through despammed.com - a free
> forwarding service. I see one or two spams per month.
To do that, you have to use only the despammed address. The Mozilla
software works with the same address that I've been using for 6 years
(and I don't want to change, lest some old friends loose me).
>
> There are other such services. One is myrealbox.com.
> Another is mailircuit.com (although I haven't seen it
> in a year, and it might have become a pay service).
The filtering I said my ISP does is provided by BrightMail. I don't know
how much better Despammed is than BrightMail, but I suspect they use
mostly the same methods. Typically a combination of matching against
known bad senders, looking for header munging, and checking contents
against blacklists. The first two methods are hardly exhaustive, and the
last is always one step behind the spammers.
The nice thing about the Baesean filtering method is that you train it
yourself to recognise what *you* consider to be spam. Once its got a
reasonably good sample size of your email and spam to work with, its
damn tough to fool. A spam would have to be worded quite unlike your
typical spams, and quite like normal correspondence. It'd be tough to
squeeze a sales-pitch through that.
> Can Mozilla spam-check the mail and then hand it off
> to the mail-reader I prefer?
I haven't played around with the rules enough to see if there's
something like that in there. Probably not. This is a feature that's
built into the Mozilla mail reader.
However, I do know that there are several other baesean filter projects
out there, some that work as straight filters. If your email tool of
choice can import stuff in the method one of those uses (and I suspect
at least one somewhere acts as a pop3 proxy), then you'd be in business.
I think when last I looked I found several, but none that worked on
Windows and were Free.
The nice deal about Mozilla is that its built right into the mail tool.
Jeffrey Creem
"Adrian Hoe" <mailbox@*nospam*adrianhoe.com> wrote in message
news:3e18f...@news.tm.net.my...
> Another identical twin - Betamax vs. VHS. Betamax (Ada) was more
> expensive although it had better playback quality than VHS (C/C++)
> which was cheaper. It was the price that put VHS into every living
> rooms. Today, some professionals (high-end) still use Betamax.
>
> If there were Turbo Ada in the mid/late 80's, Ada could have been a
> mainstream programming language today. If there were M$ Visual Ada,
Ok..If you are going to post the obligatory Betamax thing then I have to
post the obligatory response
that the VHS v.s. Beta battle is not exactly the case that everyone thinks
that it is :
http://groups.google.com/groups?q=beta+group:comp.lang.ada+author:dewar&hl=e
n&lr=&ie=UTF-8&selm=8sg6g2%24eur%241%40nnrp1.deja.com&rnum=3
Hyman Rosen
> Why to put something into anything else? Why not to have the tagged record
> doing everything what you want from the start?
I'm not sure what specific case we're talking about here,
but in general, one uses generics (or templates) when
complete type information is available at compile time,
and tagged types when type information is available only
at run time.
Under typical compiler implementations, very large gains in
efficiency become possible using generics, mainly because of
inlining opportunities.
You may not like this, but the Ada designers clearly saw generics
as a benefit, and the C++ metaprogramming developers have sealed
its fate - generics are here to stay, and will probably become
more enhanced.
Ted Dennison
> Actually, most spam these days are short HTML messages with little or no
> text. There isn't much load on the server from them. Simply blocking
> HTML graphics gets rid of many of them.
That's right. So are many of the newer email viruses. One nasty thing
about the HTML messages is that they often contain 1 pixel images, whose
only purpose is to serve as a trojan to get your email tool to hit their
website, so that they know they've got a good address. Another really
nice thing about the Mozilla mail tool is that it lets you disable
picture references in email, along with Java and Javascript (all of
which I've done).
If you want, you can also set the browser to not fetch pictures from
separate servers, or from your own blacklist of servers, which can get
rid of a lot of banner adds. I don't do that (my favorite websites have
to pay the bills, after all), but some folk do. The option's yours.
> Also, a lot of spam is now
> encoded in various ways so that simple text filters can't find them.
A baesean filter would almost certianly catch such things, unless its
somehow worded to look exactly like your normal correspondence (in which
case, *you'd* have trouble noticing the difference too). However,
because of the need for personal guidance, it isn't really appropriate
for server-side filtering like you were talking about (unless you have a
1 person server, or don't mind someone reading everyone else's mail).
See http://www.paulgraham.com/spam.html for details on how it works.
Hyman Rosen
> Does C++ have subtypes and derived types?
No. The only thing of this type available is
class inheritance.
> But I wish I could
> define things like 'First and 'Last when I create a
> private type for which they are meaningful.
In C++, you can set up arbitrary "attributes" of this
sort by using a technique called traits. You define a
class template, and then specialize it for your type.
Whether to have a common fallback value or not is up
to you. Eg.,
template<typename T> struct DoesIt;
struct Dog;
struct Cat;
struct AEIOU;
template<> struct DoesIt<Dog> { enum { Howl = 1, Yowl = 0, Vowel = 0 }; };
template<> struct DoesIt<Cat> { enum { Howl = 0, Yowl = 1, Vowel = 0 }; };
template<> struct DoesIt<AEIOU> { enum { Howl = 0, Yowl = 0, Vowel = 1 }; };