A question for my personal knowledge.

A question for my personal knowledge.

[Siamak Kaveh]

Hello Everybody,

Accepting that Ada is one of the best available programming languages, the
following question comes to my mind: Why BIG PLAYERS of computer industry
(IBM, HP, COMPAQ(Digital), CRAY, Microsoft, SUN...) don't develop their
native ADA compiler? (or they disconnected their development).

Do their engineers and managers understand that using ADA can improve
quality of their software?


Siamak,


Please note this question is only for my personal knowledge and I have no
intention to start any never-ending dispute. If you think your response can
start a religious war please neglect this question.

Re: A question for my personal knowledge.

[Larry Kilgallen]

In article <1VEZ2.1515$I51.88140@carnaval.risq.qc.ca>, "Siamak Kaveh" <kaveh@meca.polymtl.ca> writes:
> Hello Everybody,
> 
> Accepting that Ada is one of the best available programming languages, the
> following question comes to my mind: Why BIG PLAYERS of computer industry
> (IBM, HP, COMPAQ(Digital), CRAY, Microsoft, SUN...) don't develop their
> native ADA compiler? (or they disconnected their development).

IBM and DEC both developed their own Ada83 compilers, and both their
products are still available for the two vendor's high-end commercial
operating systems (although the IBM one now comes from OC Systems).

For Ada95 DEC decided to rely on Rational for Unix and ACT for Alpha VMS.
If those vendors build good compilers it is not clear that there is some
inherent advantage to DEC in doing their own (although I tend to favor
the DEC compiler).

> Do their engineers and managers understand that using ADA can improve
> quality of their software?

This is an entirely different question, pertaining to using Ada
rather than developing an Ada compiler.  I see no connection
between what compiler you want to use and what compiler is
most profitable to sell, particularly if your sales staff
not particularly dedicated to selling compilers.

It could even be argued that the most profitable compiler to be selling
is the one which causes the largest number of programmers to be used
on any particular programming project, because you sell more licenses.

Larry Kilgallen

Re: A question for my personal knowledge.

[Keith Thompson]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:
[...]
> IBM and DEC both developed their own Ada83 compilers, and both their
> products are still available for the two vendor's high-end commercial
> operating systems (although the IBM one now comes from OC Systems).

DEC developed its own Ada 83 compiler, but IBM's compiler was
originally developed by TeleSoft (which became part of Alsys, which
became part of Thomson Software Products, which became part of Aonix).

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
Techno-geek.  Mouse bigger than phone.  Bites heads off virtual chickens.

Re: A question for my personal knowledge.

[Charlie McCutcheon]

Compaq/DEC Ada is still available and supported!

Some operating system software (OpenVMS) within Compaq has been written in
Ada.  Our management is not dictating Ada.  They have to work within the
limits of what the programmers know, or are willing to program in...  ;-)

Charlie


Keith Thompson wrote:

> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> [...]
> > IBM and DEC both developed their own Ada83 compilers, and both their
> > products are still available for the two vendor's high-end commercial
> > operating systems (although the IBM one now comes from OC Systems).
>
> DEC developed its own Ada 83 compiler, but IBM's compiler was
> originally developed by TeleSoft (which became part of Alsys, which
> became part of Thomson Software Products, which became part of Aonix).
>
> --
> Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
> San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
> Techno-geek.  Mouse bigger than phone.  Bites heads off virtual chickens.

Re: A question for my personal knowledge.

[Werner Pachler]

Hi Charlie, sounds interesting.

Can you be a little more specifc (what software, which version,...)

Thankx,
Werner

Charlie McCutcheon <"cmccutcheon@NOSPAMbegin"@enet.dec.com> wrote in message
<7hc1g7$3p3@zk2nws.zko.dec.com>...
>Compaq/DEC Ada is still available and supported!
>
>Some operating system software (OpenVMS) within Compaq has been written in
>Ada.  Our management is not dictating Ada.  They have to work within the
>limits of what the programmers know, or are willing to program in...  ;-)
>
>Charlie
>

Re: A question for my personal knowledge.

[Charlie McCutcheon]

Parts of OpenVMS, most recent versions, I think at least 6.2 on.

Not major parts mind you.  Some sub-sections where the programmers involved
wanted to use Ada.

Charlie

Werner Pachler wrote:

> Hi Charlie, sounds interesting.
>
> Can you be a little more specifc (what software, which version,...)
>
> Thankx,
> Werner
>

Re: A question for my personal knowledge.

[bglbv]

Charlie McCutcheon <"cmccutcheon@NOSPAMbegin"@enet.dec.com> writes:

> Parts of OpenVMS, most recent versions, I think at least 6.2 on.

At that level of certainty I might as well reiterate my own vague
recollection. (Unfortunately, when I tried to track down the specifics
recently I found that DejaNews had not preserved the postings where
the most detailed and reliable information appeared, and the OpenVMS
FAQ is short on specifics.)

Anyway, my recollection is that use of Ada in VMS development started
with version 4.0 of the operating system. This would place the
beginnings of such activity in the 1983-1984 time frame, more or less
when DEC's first Ada compiler for the VAX came out. It is good
practice to test new software products by exercising them in-house,
so this makes at least some sense.

I have a hunch that the SMG$ screen management routines may have been
written in Ada, but this is just a guess on my part (I won't say how
educated).

I suppose someone with access to a VMS system could go through system
executables and shared libraries and watch for the Ada compiler's
idiosyncracies in code generation. (Things like working out the size
of everything in bits rather than bytes, for example. Certainly if I
wanted to search for GNAT-generated code on an x86 I would look for
sections with a high density of arithmetic shifts left by 5. Similar
heuristics should work with other compilers and on other platforms.)

> Not major parts mind you.  Some sub-sections where the programmers involved
> wanted to use Ada.

My understanding is that the use of Ada resulted in measurable
productivity gains. Pity I don't have the original reference anymore.

Re: A question for my personal knowledge.

[Larry Kilgallen]

In article <87k8u7if6a.fsf@bglbv.my-dejanews.com>, <bglbv@my-dejanews.com> writes:
> Charlie McCutcheon <"cmccutcheon@NOSPAMbegin"@enet.dec.com> writes:
> 
>> Parts of OpenVMS, most recent versions, I think at least 6.2 on.
> 
> At that level of certainty I might as well reiterate my own vague
> recollection. (Unfortunately, when I tried to track down the specifics
> recently I found that DejaNews had not preserved the postings where
> the most detailed and reliable information appeared, and the OpenVMS
> FAQ is short on specifics.)
> 
> Anyway, my recollection is that use of Ada in VMS development started
> with version 4.0 of the operating system.  This would place the
> beginnings of such activity in the 1983-1984 time frame, more or less
> when DEC's first Ada compiler for the VAX came out. It is good
> practice to test new software products by exercising them in-house,
> so this makes at least some sense.

I have a subscription to the VMS source listings, and Charlie is
correct, modulo some VAX-Alpha skew.  I am talking about actual
use for code that ships in the operating system product, not whatever
DEC may use internally for testing the compiler.

> I suppose someone with access to a VMS system could go through system
> executables and shared libraries and watch for the Ada compiler's
> idiosyncracies in code generation. (Things like working out the size
> of everything in bits rather than bytes, for example. Certainly if I
> wanted to search for GNAT-generated code on an x86 I would look for
> sections with a high density of arithmetic shifts left by 5. Similar
> heuristics should work with other compilers and on other platforms.)

I presume that any reasonable Ada compiler would handle that before
emitting object code, and it would never show up.

>> Not major parts mind you.  Some sub-sections where the programmers involved
>> wanted to use Ada.
> 
> My understanding is that the use of Ada resulted in measurable
> productivity gains. Pity I don't have the original reference anymore.

I doubt that DEC has done enough Ada to make such measurements.
It takes a _lot_ of code to filter out "other factors".  See
Marin David Condic's cautious optimism at his company after 10
years of comparisons.

Larry Kilgallen

Re: A question for my personal knowledge.

[bglbv]

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

kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> I have a subscription to the VMS source listings, and Charlie is
> correct, modulo some VAX-Alpha skew.  I am talking about actual
> use for code that ships in the operating system product, not whatever
> DEC may use internally for testing the compiler.

Well, source listings are of course the kind of authoritative
references I was missing. Thank you. So you are saying that there
is no trace of Ada code in VMS sources prior to release 6.2? For
completeness' sake, how far back did you look?

> > I suppose someone with access to a VMS system could go through system
> > executables and shared libraries and watch for the Ada compiler's
> > idiosyncracies in code generation. (Things like working out the size
> > of everything in bits rather than bytes, for example. Certainly if I
> > wanted to search for GNAT-generated code on an x86 I would look for
> > sections with a high density of arithmetic shifts left by 5. Similar
> > heuristics should work with other compilers and on other platforms.)
> 
> I presume that any reasonable Ada compiler would handle that before
> emitting object code, and it would never show up.

Why not? It does show up in GNAT-generated code in at least some
circumstances, and as long as the impact on performance is negligible,
who cares? It used to be possible to tell apart Fortran and Pascal
code on a VAX by noticing that Fortran used CALLG and Pascal CALLS
instructions. It would be na�ve to expect compilers for different
languages to generate totally indistinguishable object codes (as
opposed to equally efficient ones) for equivalent source programs.

> >> Not major parts mind you.  Some sub-sections where the programmers involved
> >> wanted to use Ada.
> > 
> > My understanding is that the use of Ada resulted in measurable
> > productivity gains. Pity I don't have the original reference anymore.
> 
> I doubt that DEC has done enough Ada to make such measurements.
> It takes a _lot_ of code to filter out "other factors".  See
> Marin David Condic's cautious optimism at his company after 10
> years of comparisons.

Oh, sure. As I said, I was citing from (probably not wholly accurate)
memory a source I can no longer even identify, let alone check for
trustworthiness. I don't recall that source going into any detail on
the method of measurement; the statistic may well have been meaningless.
This is at the anecdotal ("a good story doesn't need to be true")
level, no doubt about that.

Re: A question for my personal knowledge.

[Larry Kilgallen]

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

In article <871zge2h7q.fsf@bglbv.my-dejanews.com>, <bglbv@my-dejanews.com> writes:
> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> 
>> I have a subscription to the VMS source listings, and Charlie is
>> correct, modulo some VAX-Alpha skew.  I am talking about actual
>> use for code that ships in the operating system product, not whatever
>> DEC may use internally for testing the compiler.
> 
> Well, source listings are of course the kind of authoritative
> references I was missing. Thank you. So you are saying that there
> is no trace of Ada code in VMS sources prior to release 6.2? For
> completeness' sake, how far back did you look?

Well, I've been reading the listings since V1.5 (well before Ada existed)
at client sites.  Could someone have slipped in some isolated Ada I did
not find, yes, but it would be unlikely.  The major part that is in Ada
now was created from scratch for V6.2 or so, with no predecessor in any
language.

> who cares? It used to be possible to tell apart Fortran and Pascal
> code on a VAX by noticing that Fortran used CALLG and Pascal CALLS
> instructions. It would be na�ve to expect compilers for different
> languages to generate totally indistinguishable object codes (as
> opposed to equally efficient ones) for equivalent source programs.

VAX Pascal and VAX Fortran are sort of unique because they have their
own code generator.  Most VAX compilers from DEC use VCG.

Larry Kilgallen

Re: A question for my personal knowledge.

[Sam]

In article <1VEZ2.1515$I51.88140@carnaval.risq.qc.ca>, "Siamak says...
>
>Hello Everybody,
>
>Accepting that Ada is one of the best available programming languages, the
>following question comes to my mind: Why BIG PLAYERS of computer industry
>(IBM, HP, COMPAQ(Digital), CRAY, Microsoft, SUN...) don't develop their
>native ADA compiler? (or they disconnected their development).
>
>Do their engineers and managers understand that using ADA can improve
>quality of their software?
>
 
becuase everyone is busy writing Java software now. 

Sam.

Re: A question for my personal knowledge.

[Marin David Condic]

Siamak Kaveh wrote:
> Accepting that Ada is one of the best available programming languages, the
> following question comes to my mind: Why BIG PLAYERS of computer industry
> (IBM, HP, COMPAQ(Digital), CRAY, Microsoft, SUN...) don't develop their
> native ADA compiler? (or they disconnected their development).
> 
> Do their engineers and managers understand that using ADA can improve
> quality of their software?
> 
This is always a subject that is bound to start a long chain of
reactions. I'll get mine in early! :-)

I think you have to account for the fact that not all decisions are made
on the basis of purely technical criteria. In some cases there are
financial concerns. For example, an existing investment in
infrastructure and training. You can't discount the purely emotional
criteria used by the decision makers. If a lead engineer knows language
X and has little knowledge of language Y, which way is he likely to
lean? Or the fear of trying something new which might put your project
at risk. And you always have the totally irrational factors of
misinformation, rumors and hearsay which can take on qualities of "urban
legend" - largely believed, yet without any basis in fact.

As for the "Big Players" not wishing to develop their own Ada compilers,
ask why they don't want to develop their own compilers for almost any
other language at the same time. To start with, these guys are
*hardware* manufacturers and software in general is not their "core
business". They need to have *some* software developed in house, but
increasingly they want the job outsourced if it doesn't somehow create
competitive advantage for their product. It used to be that all hardware
vendors had their own proprietary operating systems. Now they mostly use
some flavor of Unix, Windows NT or maybe a handful of other things. If
they have in-house developed compilers, probably most of them have been
around for a while and given the choice the hardware vendor would prefer
that it be outsourced, except why bother once its already built?

The only exception I can think of is Java being a product of Sun. Its
easy to figure out what the plot is there. If you get lots of people
developing in Java which targets to a "virtual machine" rather than
native hardware, you have created the excuse why people need to buy
more/faster/bigger hardware, haven't you? Almost by definition, an
interpreted pseudo-machine-language is going to have to take more cpu
cycles than native machine instructions.

It's probably better for the industry if the big hardware vendors
contract out for their compiler technology because it unbundles the
interests of the compiler vendors & users from the interests of the
hardware vendors. As for using Ada (or any other language for that
matter) in their own internal development? I'd say it is their loss -
they ought to consider it but may not for reasons I stated above.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: A question for my personal knowledge.

[Paul Whittington]

When it comes to quality the question is not is it as good as it can
be, or could it be better; the question is "Is it good enough?"

Marin David Condic wrote:
> 
> Siamak Kaveh wrote:
> > Accepting that Ada is one of the best available programming languages, the
> > following question comes to my mind: Why BIG PLAYERS of computer industry
> > (IBM, HP, COMPAQ(Digital), CRAY, Microsoft, SUN...) don't develop their
> > native ADA compiler? (or they disconnected their development).
> >
> > Do their engineers and managers understand that using ADA can improve
> > quality of their software?
> >
> This is always a subject that is bound to start a long chain of
> reactions. I'll get mine in early! :-)
> 
> I think you have to account for the fact that not all decisions are made
> on the basis of purely technical criteria. In some cases there are
> financial concerns. For example, an existing investment in
> infrastructure and training. You can't discount the purely emotional
> criteria used by the decision makers. If a lead engineer knows language
> X and has little knowledge of language Y, which way is he likely to
> lean? Or the fear of trying something new which might put your project
> at risk. And you always have the totally irrational factors of
> misinformation, rumors and hearsay which can take on qualities of "urban
> legend" - largely believed, yet without any basis in fact.
> 
> As for the "Big Players" not wishing to develop their own Ada compilers,
> ask why they don't want to develop their own compilers for almost any
> other language at the same time. To start with, these guys are
> *hardware* manufacturers and software in general is not their "core
> business". They need to have *some* software developed in house, but
> increasingly they want the job outsourced if it doesn't somehow create
> competitive advantage for their product. It used to be that all hardware
> vendors had their own proprietary operating systems. Now they mostly use
> some flavor of Unix, Windows NT or maybe a handful of other things. If
> they have in-house developed compilers, probably most of them have been
> around for a while and given the choice the hardware vendor would prefer
> that it be outsourced, except why bother once its already built?
> 
> The only exception I can think of is Java being a product of Sun. Its
> easy to figure out what the plot is there. If you get lots of people
> developing in Java which targets to a "virtual machine" rather than
> native hardware, you have created the excuse why people need to buy
> more/faster/bigger hardware, haven't you? Almost by definition, an
> interpreted pseudo-machine-language is going to have to take more cpu
> cycles than native machine instructions.
> 
> It's probably better for the industry if the big hardware vendors
> contract out for their compiler technology because it unbundles the
> interests of the compiler vendors & users from the interests of the
> hardware vendors. As for using Ada (or any other language for that
> matter) in their own internal development? I'd say it is their loss -
> they ought to consider it but may not for reasons I stated above.
> 
> MDC
> --
> Marin David Condic
> Real Time & Embedded Systems, Propulsion Systems Analysis
> United Technologies, Pratt & Whitney, Large Military Engines
> M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
> ***To reply, remove "bogon" from the domain name.***
> 
> Visit my web page at: http://www.flipag.net/mcondic

-- 
Paul Whittington
GrepNet, Inc.
(208)523-7375
paul@grep.net

"Even if you're on the right track you'll get
 run over if you stand still."

Will Rogers

Re: A question for my personal knowledge.

[Marin David Condic]

Paul Whittington wrote:
> 
> When it comes to quality the question is not is it as good as it can
> be, or could it be better; the question is "Is it good enough?"
> 
Very true! I'm not sure if my previous response had a whole lot to do
with quality though. And, of course, deciding when you've reached "good
enough" can be a difficult task.

Of course (if we're going to get a language war going ;-) there are more
reasons for selecting Ada than issues of quality or reliability.
Depending on the mission, Ada has lifecycle cost advantages over some
other approaches. There are also fitness for a given purpose issues,
such as support for OOP, support for multitasking applications,
interfacing to other languages, interfacing to hardware, etc.

A lot depends on the nature of the project you have in mind.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: A question for my personal knowledge.

[Roy Grimm]

Siamak Kaveh wrote:
> 
> Hello Everybody,
> 
> Accepting that Ada is one of the best available programming languages, the
> following question comes to my mind: Why BIG PLAYERS of computer industry
> (IBM, HP, COMPAQ(Digital), CRAY, Microsoft, SUN...) don't develop their
> native ADA compiler? (or they disconnected their development).

Many of the "big players" would not necessarily agree with your
assertion that Ada is one of the best available programming languages. 
Hence, they see no need to make a compiler.

Beyond that, they have a fair amount of legacy support for the languages
they do use.  It costs money to develop a new compiler for their systems
for a language that isn't as widely used as, say, C/C++, COBOL, FORTRAN,
etc.

In addition, there is a cultural issue.  Ada was generated as a result
of the U.S. DoD mandating one language for most of their systems.  Many
people still see Ada as a "government language", regardless of the true
nature of it.  People's opinion has a lot more weight than the facts in
this case.

> Do their engineers and managers understand that using ADA can improve
> quality of their software?

First off, many people will contend your assertion that using Ada, by
itself, can improve the quality of their software.  Facts aside, many
people believe that the language choice does not matter.  Until there
are significant quantitative analyses for managers to be shown, the
discussion will continue back and forth.

Second, there are many legacy systems in this world and converting them
to a new language is prohibitively expensive.  That's why you still see
jobs for COBOL programmers.

Third, training a programming team a new language is expensive.  Not
only do you have to provide the training, you have to pay the
programmers for the "dead time".  Many companies are not willing to take
the short term expense.

Fourth, there is a Catch-22 situation.  There aren't too many Ada
programmers out there which make many managers use other languages in
order to find people to work for them.  But, the lack of projects means
there's no incentive for people to learn Ada.  This industry has a lot
more inertia than one might realize.

> Siamak,
> 
> Please note this question is only for my personal knowledge and I have no
> intention to start any never-ending dispute. If you think your response can
> start a religious war please neglect this question.

I'm not interested in holy wars.  I just call 'em like I see 'em. 
Nevertheless, I think that by merely asking the question, you will have
started a holy war in one form or another...

-- 
Windows98 (noun)- 32 bit extensions and a graphical shell for a 16 bit
patch to an 8 bit operating system originally coded for a 4 bit
microprocessor, written by a 2 bit company, that can't stand 1 bit of
competition.

Re: A question for my personal knowledge.

[Pascal Obry]

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


Roy Grimm <ragrimm@bigfoot.com> a �crit dans le message :
37372A84.641F2133@bigfoot.com...

>
> Third, training a programming team a new language is expensive.  Not
> only do you have to provide the training, you have to pay the
> programmers for the "dead time".  Many companies are not willing to take
> the short term expense.
>

It cost but I would not say that it is expensive. A computer language to
learn is
just syntax. The expensive part are the concepts like : Information hidding,
encapsulation, data abstraction, polymorphisme, inheritance, .... But all
this should be known by any good software engineer.

Now when you understand all these concepts, learning a new language is
not that expensive but it still cost a bit.

Pascal.

Re: A question for my personal knowledge.

[Roy Grimm]

Pascal Obry wrote:
> 
> Roy Grimm <ragrimm@bigfoot.com> a �crit dans le message :
> 37372A84.641F2133@bigfoot.com...
> 
> >
> > Third, training a programming team a new language is expensive.  Not
> > only do you have to provide the training, you have to pay the
> > programmers for the "dead time".  Many companies are not willing to take
> > the short term expense.
> >
> 
> It cost but I would not say that it is expensive. A computer language to
> learn is
> just syntax. The expensive part are the concepts like : Information hidding,
> encapsulation, data abstraction, polymorphisme, inheritance, .... But all
> this should be known by any good software engineer.

If they don't know those concepts, learning a new language in and of
itself certainly isn't going to help them.  They *should* know all that
as a result of the training they received before they took the job in
the first place.

> Now when you understand all these concepts, learning a new language is
> not that expensive but it still cost a bit.

When one has dozens or hundreds of
programmers/engineers/developers/whatever, the costs can add up
quickly.  Not only do you have to pay for the classes but you also have
the costs of learning the new development environment (even if your old
environment supports the new language, it has to have new ways of
handling some language features so it is never 100% identical).  Beyond
that, there's the unseen costs of the true learning curve of the
language.  Sure, you can pick up the syntax reasonably quickly but
you'll still take a few weeks or more of using that syntax to really
learn the language.  That is what's expensive.

> Pascal.

Roy

-- 
Windows98 (noun)- 32 bit extensions and a graphical shell for a 16 bit
patch to an 8 bit operating system originally coded for a 4 bit
microprocessor, written by a 2 bit company, that can't stand 1 bit of
competition.

Re: A question for my personal knowledge.

[Robert Dewar]

In article <37382B0C.A95B6745@bigfoot.com>,
  Roy Grimm <ragrimm@bigfoot.com> wrote:
> If they don't know those concepts, learning a new language in
> and of itself certainly isn't going to help them.  They
> *should* know all that as a result of the training they
> received before they took the job in the first place.

Well I won't disagree with your *should* here (indeed I think
they should have learned Ada as part of this training, since it
is a much better introduction to these critical concepts).

But you are in my experience quite wrong to think that learning
a new language does not help. On the contrary, switching to a
new language often illuminates principles that are hard to
understand in a language that does not support or is actively
hostile to these principles.

For example, Fortran programmers were quite puzzled by EWD's
letter to the ACM on gotos, but this was totally familiar to
all Algol programmers.

Once you understand the details of separation of spec and
implementation, you can indeed apply this even in languages
which are really not very hospitable to the notion, but the
experience I have seen is that typical C programmers do NOT
have a good understanding of this separation, and learning
Ada is very helpful in gaining this understanding.

Roy, what is your experience with Fortran or C programmers
switching to Ada, does it match this? (indeed, do you have
direct experience with projects making such a switch?)


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: A question for my personal knowledge.

[Roy Grimm]

Robert Dewar wrote:
>
> Well I won't disagree with your *should* here (indeed I think
> they should have learned Ada as part of this training, since it
> is a much better introduction to these critical concepts).
> 
> But you are in my experience quite wrong to think that learning
> a new language does not help. On the contrary, switching to a
> new language often illuminates principles that are hard to
> understand in a language that does not support or is actively
> hostile to these principles.

I would concede this point.  I learned much when I went from GW-BASIC to
Turbo Pascal lo those (not too) many years ago.  Of course, that was
before I took any "real programming classes".  I spent much of my time
in the "Intro to Programming" class reviewing what I had already
learned.

> For example, Fortran programmers were quite puzzled by EWD's
> letter to the ACM on gotos, but this was totally familiar to
> all Algol programmers.
> 
> Once you understand the details of separation of spec and
> implementation, you can indeed apply this even in languages
> which are really not very hospitable to the notion, but the
> experience I have seen is that typical C programmers do NOT
> have a good understanding of this separation, and learning
> Ada is very helpful in gaining this understanding.
>
> Roy, what is your experience with Fortran or C programmers
> switching to Ada, does it match this? (indeed, do you have
> direct experience with projects making such a switch?)

I've seen that some experienced programmers (at least half of them) will
not use many of the features of Ada.  In some of the Ada projects here,
I still see everything being laid out as if it was being written in C. 
I suspect that is more an effect that people just learn the Ada syntax
they need or want and ignore the rest.  They try to force the proverbial
square peg into the round hole.  Fortunately, while this attitude is not
uncommon, it is not as pervasive as one might fear.

I have seen some projects (or parts of projects) which have truly
adopted the Ada culture as well as the language.  You could almost call
the code elegant.  The specifications of the packages are really compact
and efficient with minimal use of global variables and procedures. 
Package bodies are as encapsulated as they can be.  All the relevant
local data is kept locally instead of being brought in from global
packages.  The packages have been well organized and the code is easy to
read.  It's truly a joy to work on those projects.  The new engineers on
the project (experienced programmers or college grads) tend to pick up
this attitude.  The dedicated C style programmers often times transfer
to other departments where the culture is more oriented to the C style
(or in fact a C based project...).

I think it really boils down to the attitude of the individual.  They
can either shape the language around their attitude or they can shape
their attitude around the language.  And the individual attitudes many
times draw upon the collective attitude of the team.  The attitudes of
the lead engineers and other "gurus" can have a great deal of influence
over the style of the code being written.

Roy
-- 
"I want you to do it right as fast as you can, not fast as right as you
can."  -- Arthur Collins, founder Collins Radio

Re: A question for my personal knowledge.

[Robert A Duff]

Roy Grimm <ragrimm@bigfoot.com> writes:

> I think it really boils down to the attitude of the individual.  They
> can either shape the language around their attitude or they can shape
> their attitude around the language. ...

The former isn't always a bad idea.  Eg, when programming in C, use .h
files in a very stylized way that indicates the "spec" vs
"implementation".

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: A question for my personal knowledge.

[dennison]

In article <7h9o21$9v4$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-dejanews.com> wrote:

> a new language does not help. On the contrary, switching to a
> new language often illuminates principles that are hard to
> understand in a language that does not support or is actively
> hostile to these principles.

Another good example of this is Lisp and recursion. After learning Lisp,
I was never afraid of recursion again.

--
T.E.D.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: A question for my personal knowledge.

[Mike Yoder]

In article <7h9o21$9v4$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-dejanews.com> wrote:

> ... On the contrary, switching to a
> new language often illuminates principles that are hard to
> understand in a language that does not support or is actively
> hostile to these principles.

Additionally, it (unfortunately) matters significantly which is the
*first* language learned, especially to those programmers that aren't
exposed to a great many languages.  When I taught programming using
Pascal at Boston University in the late 70's, the students who had never
programmed before found the material easy, while those who had already
learned FORTRAN or COBOL were constantly struggling.  Outside the
classroom I see a similar effect in those who learn C, C++, or BLISS
first and then write Ada code: the most noticeable symptom is an overuse
of Unchecked_Conversion (even for pointer types!).  It's uncertain that
that is the most damaging effect, but it alone is quite bad.

If I were to teach programming today, I'd choose Ada 95 as the vehicle. 
It is a serious detriment to pedagogy (and to programming!) to muddle
together the vehicle of polymorphism and the vehicle of abstraction as
C++ does.  (This impinges on the discussion in another thread, which I
will nevertheless refrain from joining.)  In case it is inobvious to
some what I'm referring to, I mean the tagged type for polymorphism and
the package for abstraction; in C++ these both become classes.

Re: A question for my personal knowledge.

[Mike]

In article <373AC668.4824FF07@decada.enet.dec.com>, Mike says...
 
>If I were to teach programming today, I'd choose Ada 95 as the vehicle. 
>It is a serious detriment to pedagogy (and to programming!) to muddle
>together the vehicle of polymorphism and the vehicle of abstraction as
>C++ does.  (This impinges on the discussion in another thread, which I
>will nevertheless refrain from joining.)  In case it is inobvious to
>some what I'm referring to, I mean the tagged type for polymorphism and
>the package for abstraction; in C++ these both become classes.

And what is wrong with that? a class serves as abstraction and polymorphism.
it is simpler really.

Ada OO mechanism is not simple and I find it confusing. a class is the
most basic concept in OO, and Ada does not have it. No wonder all heavely
used OO languages today use the class concept (C++, Java) even Simula
the original OO language used a class to represent objects with. All except
Ada does it different. 

Mike

Re: A question for my personal knowledge.

[Martin C. Carlisle]

In article <7hfctj$1kb4@drn.newsguy.com>, Mike   <Mike@newsguy.com> wrote:
>In article <373AC668.4824FF07@decada.enet.dec.com>, Mike says...
> 
>>If I were to teach programming today, I'd choose Ada 95 as the vehicle. 
>>It is a serious detriment to pedagogy (and to programming!) to muddle
>>together the vehicle of polymorphism and the vehicle of abstraction as
>
>Ada OO mechanism is not simple and I find it confusing. a class is the
>most basic concept in OO, and Ada does not have it. No wonder all heavely
>used OO languages today use the class concept (C++, Java) even Simula
>the original OO language used a class to represent objects with. All except
>Ada does it different. 

Of course Ada has a class-- it's called a tagged record.  It has attributes
and methods (which must be declared together with it).  The original poster
merely points out that you can select whether to have multiple classes
together in the same abstraction.

--Martin


-- 
Martin C. Carlisle, Asst Prof of Computer Science, US Air Force Academy
carlislem@acm.org, http://www.usafa.af.mil/dfcs/bios/carlisle.html
DISCLAIMER:  This content in no way reflects the opinions, standards or 
policy of the US Air Force Academy or the United States Government.

Re: A question for my personal knowledge.

[Dale Stanbrough]

Mike wrote:

"Ada OO mechanism is not simple"

Well _I_ find Ada's mechanism quite simple, so we'll have to put
this down to perception. 

Quite simply (from my point of view) you declare a tagged type (class),
then you declare the subprograms (methods). Class wide pointers are the
equivalent of C++'s pointers, and you dispatch through them.

What else is there to know (that is equivalent to C++*)?

Dale


(* i do find multiple inheritance trickier!)

Re: A question for my personal knowledge.

[Mike]

In article <dale-1405990852190001@r1021c-34.ppp.cs.rmit.edu.au>,
dale@cs.rmit.edu.au says...
>
>Mike wrote:
>
>"Ada OO mechanism is not simple"
>
>Well _I_ find Ada's mechanism quite simple, so we'll have to put
>this down to perception. 
>
>Quite simply (from my point of view) you declare a tagged type (class),
>then you declare the subprograms (methods). Class wide pointers are the
>equivalent of C++'s pointers, and you dispatch through them.
>
>What else is there to know (that is equivalent to C++*)?
>
 
In Ada, you still use function calls and pass tagged records as
parameters.

in real OO, you invoke methods on objects.

Also, a class is more clear representation of an object. in Ada, bolting
OO concepts into a procedural language, makes the way to do OO in Ada
not very natural at all.

The biggest mistak Ada made in 95 was not introduce the class construct
as is common in other OO languages. who care if that would have broke
Ada83 programs, you could have called it X95 for all I care, it did not
have to be called Ada.

sorry, but OO in Ada is not normal OO. I am happy that you have no problem
with it, but 99% of the rest of the world do not do OO that way Ada does it.

Mike

Re: A question for my personal knowledge.

[Brian Rogoff]

On 13 May 1999, Mike wrote:
> In article <dale-1405990852190001@r1021c-34.ppp.cs.rmit.edu.au>,
> dale@cs.rmit.edu.au says...
> >
> >Mike wrote:
> >
> >"Ada OO mechanism is not simple"
> >
> >Well _I_ find Ada's mechanism quite simple, so we'll have to put
> >this down to perception. 
> >
> >Quite simply (from my point of view) you declare a tagged type (class),
> >then you declare the subprograms (methods). Class wide pointers are the
> >equivalent of C++'s pointers, and you dispatch through them.
> >
> >What else is there to know (that is equivalent to C++*)?
> >
>  
> In Ada, you still use function calls and pass tagged records as
> parameters.
> 
> in real OO, you invoke methods on objects.

What ignorant hogwash! In CLOS, you also have function call syntax,
and in Dylan as well. "Real OO" is just using dot notation, eh?

> sorry, but OO in Ada is not normal OO. I am happy that you have no problem
> with it, but 99% of the rest of the world do not do OO that way Ada does it.

73% of all statistics are made up on the spot. 

-- Brian

Re: A question for my personal knowledge.

[David Starner]

Mike wrote:
> In Ada, you still use function calls and pass tagged records as
> parameters.
> 
> in real OO, you invoke methods on objects.

Only syntatic sugar. Pretty synatic sugar, but synatic sugar. Before I
got used to it, I was planning on writing a preprocessor to change
Object.Method(...) to Method(Object, ...). 

> Also, a class is more clear representation of an object. in Ada, bolting
> OO concepts into a procedural language, makes the way to do OO in Ada
> not very natural at all.
Actually, no. They introduced OO into Ada in an extraordinarly Ada way.
It fits very naturally into Ada; it doesn't feel bolted on. 

Anyway, why is a class a more clear representation of an object? A class
forces A.atan2(B) (for atan B/A) when there is no reason to put emphasis
on A, where atan2(A, B) would be more natural. 

> sorry, but OO in Ada is not normal OO. I am happy that you have no problem
> with it, but 99% of the rest of the world do not do OO that way Ada does it.
Who cares? Just following the rest of the world is a bad reason for
doing anything.

Re: A question for my personal knowledge.

[Georg Bauhaus]

David Starner (dstarner98@aasaa.ofe.org) wrote:
: Mike wrote:
: > In Ada, you still use function calls and pass tagged records as
: > parameters.
: > 
: > in real OO, you invoke methods on objects.

: Only syntatic sugar. Pretty synatic sugar, but synatic sugar. Before I
: got used to it, I was planning on writing a preprocessor to change
: Object.Method(...) to Method(Object, ...). 

Why fix yourselves to one particular perspective on things?
You might look at the string ``get(me, "out")'' and consider
it a sentence in Language "English" (with weird puctiation,
though).  You might say, "get" is a Verb (you are a linguist),
you might say, "get" is a method - not an HTTP method, though ;- ,
because you know that "me" is an object-like thing (you are
the programmer).  And you conclude, from the quotes around
"out", that "out" is not an out parameter, but a message:
"out"! (The meaning of quotes...) You could write, in some
other languages, me.get("out"), which I do not find easier to
comprehend *in English*. It might be easier for you to know the
type of programming thing from this syntax if you are used
to using dot .notation. and if this syntax were uniquely bound to
a syntactic/semantic meaning, yet does it matter? Not if you
are interested in the meaning of a program, rather than in its
technical structure.

In Perl - to add something new - you choose from:

  get $me "out";

or

  $me->get("out");

Same thing. Or not?
Isn't this whole discussion about an aesthetical topic, really?
And arent these matters of taste, to some extent? 

-#- Georg

Re: A question for my personal knowledge.

[Florian Weimer]

Mike  <Mike@newsguy.com> writes:

> in real OO, you invoke methods on objects.

No, you send messages to them.

(SCNR. I was offered a job as a Smalltalk coder yesterday. ;)

Re: A question for my personal knowledge.

[Steve]

In article <m3so8z4hg5.fsf@deneb.cygnus.stuttgart.netsurf.de>, Florian says...
>
>Mike  <Mike@newsguy.com> writes:
>
>> in real OO, you invoke methods on objects.
>

>No, you send messages to them.
>

Yes, that is even better. Now In Ada, how does one send a message to a 
tagged record?? 

>(SCNR. I was offered a job as a Smalltalk coder yesterday. ;)

cool. Smalltalk is a real OO language, even more than Java. But Java
is the one most used OO language these days.

Steve

Re: A question for my personal knowledge.

[Florian Weimer]

Steve  <Steve@newsguy.com> writes:

> In article <m3so8z4hg5.fsf@deneb.cygnus.stuttgart.netsurf.de>, Florian says...
> >Mike  <Mike@newsguy.com> writes:
> >
> >> in real OO, you invoke methods on objects.
> >
> 
> >No, you send messages to them.
> 
> Yes, that is even better. Now In Ada, how does one send a message to a 
> tagged record?? 

`Message(Tagged_Record_Variable);'?

I'm not sure whether Ada is a bit nearer to the message-based model
than C++ or Java because I haven't understood all the implications of
the Ada approach yet.

C++ and Java lack truely dynamic message dispatching (i.e. you can only
send a message to an object if its class (or some suitable base class)
is known at compile-time), and judging from my preliminary understanding,
Ada doesn't have this capability, either.  Of course, you can implement
dynamic dispatching in almost any (even non-OO) languages used today,
but without syntactic support of some kind, your code won't be easy to
write or read.

BTW: At bytecode level, the Java object model is very similar to that
of Smalltalk and Objective C.  Although you can access some of these
aspects via the Reflections API, this is very clumsy, completely lacking
any syntactic sugar, and certainly not intended for regular use.

> >(SCNR. I was offered a job as a Smalltalk coder yesterday. ;)
> 
> cool. Smalltalk is a real OO language, even more than Java. But Java
> is the one most used OO language these days.

Unfortunately, I couldn't accept, because I'm already under contract --
as a C++ programmer. :-/  But some day, I certainly want to do some
real work with one of these more dynamic OO languages (Smalltalk,
Objective C or even Python).  (Of course, Ada is on my list, too.
But I wonder whether I'll get there because I don't  want to become a
full-time programmer at all. ;)

Re: A question for my personal knowledge.

[Matthew Heaney]

Florian Weimer <fw@cygnus.stuttgart.netsurf.de> writes:

> > Yes, that is even better. Now In Ada, how does one send a message to a 
> > tagged record?? 
> 
> `Message(Tagged_Record_Variable);'?
>
> I'm not sure whether Ada is a bit nearer to the message-based model
> than C++ or Java because I haven't understood all the implications of
> the Ada approach yet.

One implication of the Ada approach is that binary operations are more
natural:

  Marry (John, Jane);

The operation "marriage" applies to each object equally.

> C++ and Java lack truely dynamic message dispatching (i.e. you can
> only send a message to an object if its class (or some suitable base
> class) is known at compile-time), and judging from my preliminary
> understanding, Ada doesn't have this capability, either.  Of course,
> you can implement dynamic dispatching in almost any (even non-OO)
> languages used today, but without syntactic support of some kind, your
> code won't be easy to write or read.

Your choice of nomenclature is unfortunate, because everyone else uses
the term "dynamic message dispatching" to refer to run-time binding,
which Ada95, C++, and Java _do_ have.

Re: A question for my personal knowledge.

[Dale Stanbrough]

Mike  wrote:

" In Ada, you still use function calls and pass tagged records as
  parameters.
  
  in real OO, you invoke methods on objects."



Hang on, I could write a program that does a _simple_ transformation
to change the "real OO" syntax to Ada's current syntax (or vice versa).
This must mean that "real OO" is _only_ syntax

And I thought that OO was about semantics! 

The solution to solving this argument is for you to supply a list
of features that you think "real OO" _must_ have, and for you to 
tick them off against Ada. No doubt your list will have

   "must have a particular syntax"

and you will therefore prove that Ada doesn't fit the bill.
That's fair enough, you can call anything by any name that you
choose. The question that we will all be left with is does
anyone agree with you, or does anyone care.

Dale

Re: A question for my personal knowledge.

[Matthew Heaney]

Mike  <Mike@newsguy.com> writes:

> In Ada, you still use function calls and pass tagged records as
> parameters.
> 
> in real OO, you invoke methods on objects.

You are confusing syntax and semantics.  The call

  Push (X, On => Stack);

really does "invoke a method on an object."  


> Also, a class is more clear representation of an object. in Ada, bolting
> OO concepts into a procedural language, makes the way to do OO in Ada
> not very natural at all.

Ada83 was already a class-based language.  All Ada95 was to extend the
existing facilities for class-based programming with type extension.

In Ada83, you did this:

  type T is private;


In Ada95, you do this:

  type T is tagged private;


In Ada83, you did this:

  type NT is new T;

In Ada95, you do this:

  type NT is new T with private;


What's "bolt-on" about that?  Ada95 was designed specifically to NOT add
bolt-on features, so your statement to the contrary is incorrect.

 
> The biggest mistake Ada made in 95 was not introduce the class
> construct as is common in other OO languages.  Who cares if that would
> have broken Ada83 programs, you could have called it X95 for all I
> care, it did not have to be called Ada.

But the class already existed in Ada83: it's called a "private type".

  type Stack_Type is private;

  procedure Push
    (Item : in     Item_Type;
     On   : in out Stack_Type);

  function Get_Top (Stack : Stack_Type) return Item_Type;


In Ada95, I might say:

  type Stack_Type is tagged private;

  procedure Push
    (Item : in     Item_Type;
     On   : in out Stack_Type);

  function Get_Top (Stack : Stack_Type) return Item_Type;


Not much difference, except that in Ada95 I can extend the stack type:

  type My_Special_Stack is new Stack_Type with private;



> sorry, but OO in Ada is not normal OO. I am happy that you have no problem
> with it, but 99% of the rest of the world do not do OO that way Ada does it.

You seem not to understand the difference between syntax and semantics.

Re: A question for my personal knowledge.

[Richard D Riehle]

In article <7hfctj$1kb4@drn.newsguy.com>,
	Mike  <Mike@newsguy.com> wrote:

>Ada OO mechanism is not simple and I find it confusing. a class is the
>most basic concept in OO, and Ada does not have it. No wonder all heavely
>used OO languages today use the class concept (C++, Java) even Simula
>the original OO language used a class to represent objects with. All except
>Ada does it different. 

 ... and Oberon, and Modula-3.

 I believe it was Albert Einstein who said, "Everything should be as
 simple as possible but not simpler."

 The most basic concept in OO is not that of "class."  Rather, it is
 the concept of "object."  Not all OOPL's require "class" in the same
 form.  Also, some practitioners make a distinction between type and
 class.  In one of the languages cited, C++, the model is,

                    type = class = module

 where the relationship is associative so we can also have,

                    module = class = type
                    class = type = module

 This relationship has definite advantages for some approaches to 
 software development.  Its simplicity also has its drawbacks. In
 fact, its very simplicity is seductive, especially in C++, where
 the model requires some rather bizzare code to compensate for the
 absence of other supporting constructs.  For example, a properly
 designed C++ class requires at least one constructor, a copy constructor,
 overloading of assignment, and a destructor.  And that is before one
 even gets started thinking about the problem to be solved.  As one
 explores this presumably "simple" model in depth, it becomes clear that
 it is not at all as simple as we might have thought it would be when
 looking at the general form of the class construct. 

 Ada has a model closer to,
 
                   module contains type,
                   type = root of derivation class
                   class = a derivation of types

 A superficial examination of these two forms would lead one to
 conclude that C++ is simpler.  That is a problem with superficial
 examinations.  It is also the origin of an interesting paradox
 when comparing C++ and Ada in more depth.

 The Ada model has its advantages. We also admit to it having its own 
 downside.  Some OO practitioners regard the Ada model as "counter
 intuitive."  It is only counter-intuitive if you are trying to make Ada
 look like the C++ or Eiffel model.  Otherwise, it is, in practice, easier
 to design and implement code using the Ada model than with the C++
 model.  The superficially simpler model of C++ increases the   
 implementation complexity during the source code development process.   

 The Ada model of enclosing the type as root of a derivation class in
 a package seems, at first, more complex.  This is the paradox.  Even
 though Ada seems more complex because of the separation of concerns
 between module and type, it becomes simpler in practice.  This paradox
 is not easy to see unless one has actually engaged in the development
 of software in both languages.  Sadly, too many software managers see
 only the surface issues, and are misled into believing C++ is simpler 
 because it seems to be so when looking at the basic form.  When comparing
 Ada and C++, it is appropriate to keep the quotation from Einstein
 in mind, especially when doing a cursory evaluation of the two language
 design models.

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com
 

Re: A question for my personal knowledge.

[Hyman Rosen]

Richard D Riehle <laoXhai@ix.netcom.com> writes:
>  For example, a properly designed C++ class requires at least one
>  constructor, a copy constructor, overloading of assignment, and a
>  destructor.

That is completely untrue, if you mean that the programmer must supply
those methods, since the compiler will write all of these for you if
you don't write them yourself. You only need your own if the default
ones are not suitable for your purposes. But for those cases, you would
have to do the same in Ada, I imagine.

>  A superficial examination of these two forms would lead one to
>  conclude that C++ is simpler.  That is a problem with superficial
>  examinations.  It is also the origin of an interesting paradox
>  when comparing C++ and Ada in more depth.

Why don't you show us an example of some class or object where the
Ada is simpler than the C++? Then we'll have something concrete to
look at.

Re: A question for my personal knowledge.

[Richard D Riehle]

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

>Richard D Riehle <laoXhai@ix.netcom.com> writes:
>>  For example, a properly designed C++ class requires at least one
>>  constructor, a copy constructor, overloading of assignment, and a
>>  destructor.
>
>That is completely untrue, if you mean that the programmer must supply
>those methods, since the compiler will write all of these for you if
>you don't write them yourself. You only need your own if the default
>ones are not suitable for your purposes. But for those cases, you would
>have to do the same in Ada, I imagine.

 While it is true that a C++ compiler may create _all_ of these for 
 you, it would be a rare class where there was no constructor defined
 in the public part.  I have seen C++ classes where no constructor
 was defined in which the constructor was inherited from an ancestral
 class.  Not common.  Destructors are more often defaulted to the one
 created by the compiler.  This is sometimes the source of an error
 in the design of a class.  An even more interesting source of errors
 is the failure to create a copy constructor or overload assignment. 
 You are correct that the compiler will create these for you.  The 
 question is when to create your own instead of accepting the default
 created by the compiler.  The answer to this question is often non-trivial.

 In Ada, a creation of an object is a simple declaration.  Since Ada
 allows initialization of object components, no initializor list is
 required, unless the type has a discriminant.  An Ada designer has
 some options not available to the C++ programmer when choosing which
 level of abstraction to incorporate into a design.  A prolonged 
 discussion of these is beyond the scope of a short note on this forum.
 I wonder if the closing words of your reply, "I imagine," suggest
 that further study of Ada would illuminate some of the points better
 than I could do in this brief space.  

 As to comparing the languages, such comparisons are nearly always
 fruitless.  People have their preferences.  They will find whatever
 features, syntax, and semantic horseradish that best supports their
 personal point-of-view.  This is as true of me as it no doubt is of
 you.  I use both languages, Ada and C++.  My personal preference is
 Ada.  I find it better suited to complex design of large-scale safety
 critical software.  Perhaps my preference is a function of unbridled
 bigotry.  So be it.  But I have taken the trouble to study and use
 both languages, so I think my bigotry is softened by my experience.
 Have you taken the trouble to study Ada?

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com

  
 

Re: A question for my personal knowledge.

[Hyman Rosen]

Richard D Riehle <laoXhai@ix.netcom.com> writes:
>  The question is when to create your own instead of accepting the
>  default created by the compiler.  The answer to this question is
>  often non-trivial.
...
>  In Ada, a creation of an object is a simple declaration.
...
>  I wonder if the closing words of your reply, "I imagine," suggest
>  that further study of Ada would illuminate some of the points better
>  than I could do in this brief space.  
...
>  As to comparing the languages, such comparisons are nearly always
>  fruitless.

But you started it! You said that to the uninformed, C++ looks simpler
than Ada, but that with deeper understanding, the opposite becomes
apparent. I invited you to show me some code which demonstrates this.

I don't know Ada, and I don't feel like learning it right now, but I
think I could follow an example you post. So show me an object which
requires a constructor and user-defined assignment operator in C++,
but only a simple declaration and no such operator in Ada. Or if I
misunderstood, just show me *something* where Ada's object model lets
you do away with things that C++ requires.

Re: A question for my personal knowledge.

[Richard D Riehle]

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

>Richard D Riehle <laoXhai@ix.netcom.com> writes:

>>  As to comparing the languages, such comparisons are nearly always
>>  fruitless.
>
>But you started it! You said that to the uninformed, C++ looks simpler
>than Ada, but that with deeper understanding, the opposite becomes
>apparent. I invited you to show me some code which demonstrates this.

 I apologize for having "started it."  I should know by now that 
 language comparisons are the equivalent of wading through fresh
 taffy on a warm autumn afternoon, sweet but difficult when a quick
 movement is necessary.  

 I am going to decline this invitation, but decline with a thank
 you.  The thank you is because your challenge has opened a new
 avenue of thought for me, an avenue I am going to explore by
 creating just such an example for the book I am currently writing.
 It is clear from the discussion that I might be able to make a
 contribution by creating such an example.  

 As a point of information, I will use the C++ Vector class example, 
 published in most textbooks about C++, the .  This example
 works in the comparison because it is nearly always designed with
 all four of the member functions mentioned in my earlier post.  An
 interesting feature of C++ design is the frequent use of * and & for
 variables and function return types.  In this respect, Ada is quite
 different.  That is, we do not use pointers and references in quite 
 the same way, mostly because of the increased risk of using these in
 safety-critical applications.  Yes, I know of the availability of 
 memory.h and other features to reduce the risk of raw pointers.  And
 this certainly does help C++ to be a little safer.

 I do not want to give the impression that I think C++ is evil, or even
 bad.  It is a very good language.  In my earlier post, I tried to emphasize
 that some aspects of C++ are less than wonderful and some aspects of Ada
 are less than wonderful.  My actual point was somewhat obscured by the
 way I presented it.  Someone had mentioned that the syntax of a C++ class
 was more intuitive or easier, or some such thing.  My point was that the
 simplicity seems simpler than it really is.  Class design, whether in 
 Ada, Eiffel, or C++ is not so simple.  Some kinds of designs will be 
 better in Ada.  Others might be better in C++.  It is, however, a mistake
 to think that the simplicity of the class format in C++ makes it easier
 than the class format in Ada -- or vice versa.  

>I don't know Ada, and I don't feel like learning it right now, but I
>think I could follow an example you post. So show me an object which
>requires a constructor and user-defined assignment operator in C++,
>but only a simple declaration and no such operator in Ada. Or if I
>misunderstood, just show me *something* where Ada's object model lets
>you do away with things that C++ requires.

 The textbook example of the Vector class is a good example.  Not only
 does one need to include a constructor (at least one), but also a
 copy constructor, a destructor, a friend function for the + operator,
 and a lot of other stuff one would not find in a typical Ada package
 for the Vector class.  On the other hand, I might very well want to 
 design a Vector class that had all that stuff.  I would not require
 a "friend" function because Ada's model would not require such a thing.
 If I designed the type as,

           type Vector (Size : Positive) is limited private;

 I would need a copy procedure to emulate assignment (but no separate
 copy constructor), and would probably overload the equality operator.
 I actually have a wide range of options for this design.  If I design
 it as,

          type Vector (<>) is private;

 then I will, in fact need something equivalent to a constructor such
 as a function that returns the constrained type,

          function Make (Size : Positive) return Vector;

 and will probably want to create a copy procedure for this type. Again,
 Ada practitioners will consider other design options such as use of
 a controlled type to implement an adjust procedure to prevent the 
 potential for constraint errors at assignment.  The point is, I have
 a wide range of options for designing either an elegantly simple 
 Vector or an elegantly complicated one.  

 I can also design an Ada type that resembles the C++ class, with all the
 attendant overhead.  It is more difficult, I think, to design a C++
 class that resembles an Ada type.  This will be an interesting example
 to design for my book.  It will require some thought, some compilations,
 and some testing.  I am not going publish the code here since I intend to
 use it in my book.  

 This is more than I intended to say on this subject.  I don't plan to 
 say anymore.  (Say Amen, someone).  I know this will not satisfy you.
 When you are ready to study Ada I think you will enjoy what you discover.
 Until then, enjoy the experience with C++.  I am enjoying my experience
 with it too.

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com

Re: A question for my personal knowledge.

[Marin David Condic]

Roy Grimm wrote:
> When one has dozens or hundreds of
> programmers/engineers/developers/whatever, the costs can add up
> quickly.  Not only do you have to pay for the classes but you also have
> the costs of learning the new development environment (even if your old
> environment supports the new language, it has to have new ways of
> handling some language features so it is never 100% identical).  Beyond
> that, there's the unseen costs of the true learning curve of the
> language.  Sure, you can pick up the syntax reasonably quickly but
> you'll still take a few weeks or more of using that syntax to really
> learn the language.  That is what's expensive.
> 

...And let the language wars begin!...:-)

pragma Flame (On) ;

I hear this argument all the time - "Nobody wants to switch to language
X because training/education/infrastructure/whatever is too expensive."
This ends up absurd on the face of it. Stick "Java" in where "X" appears
above. Apparently people were willing to eat the costs - large or small
or whatever they really are - in order to get the perceived benefits of
the new language. This *must* be true or we'd all still be programming
in assembler.

I think it ends up coming down to this: "I find language X interesting.
Hence, I will acquire the resources and start developing in X." versus
"I hate language Y and someone is encouraging/forcing me to adopt it.
Hence, language Y will cost too much, take too long, introduce too many
risks, make it impossible for me to get qualified staff, blah, blah,
blah." 

I hope this isn't looked at as any sort of attack. I realize lots of
people of good will and intelligence understand that there are costs
associated with switching over to a new language. I just get frustrated
with the notion that this is somehow an insurmountable barrier. It is
obviously *not* an insurmountable barrier the instant Programmer Pete or
Manager Mel decide they like a language and want to use it. It is done
*all*the*time* and apparently doesn't bankrupt a project or company or
there would *never* be any progress beyond machine code.

pragma Flame (Off) ;

Whew! Feels good to get that out of my system!

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: A question for my personal knowledge.

[Roy Grimm]

Marin David Condic wrote:
> 
> ...And let the language wars begin!...:-)

Oh dear, what have I done?!?

> pragma Flame (On) ;
> 
> I hear this argument all the time - "Nobody wants to switch to language
> X because training/education/infrastructure/whatever is too expensive."
> This ends up absurd on the face of it. Stick "Java" in where "X" appears
> above. Apparently people were willing to eat the costs - large or small
> or whatever they really are - in order to get the perceived benefits of
> the new language. This *must* be true or we'd all still be programming
> in assembler.
> 
> I think it ends up coming down to this: "I find language X interesting.
> Hence, I will acquire the resources and start developing in X." versus
> "I hate language Y and someone is encouraging/forcing me to adopt it.
> Hence, language Y will cost too much, take too long, introduce too many
> risks, make it impossible for me to get qualified staff, blah, blah,
> blah."
> 
> I hope this isn't looked at as any sort of attack. I realize lots of
> people of good will and intelligence understand that there are costs
> associated with switching over to a new language. I just get frustrated
> with the notion that this is somehow an insurmountable barrier. It is
> obviously *not* an insurmountable barrier the instant Programmer Pete or
> Manager Mel decide they like a language and want to use it. It is done
> *all*the*time* and apparently doesn't bankrupt a project or company or
> there would *never* be any progress beyond machine code.
> 
> pragma Flame (Off) ;
> 
> Whew! Feels good to get that out of my system!

All I intended to say is that there are real costs associated with
switching languages.  I never meant to imply that they were
insurmountable.  Nevertheless, some managers (what percentage, I have no
idea and will not presume to guess) use theses costs as a justification
not to switch to a different language.  That was the subject of the
original question which was, to paraphrase, "Why don't people switch to
Ada?"

Now, I will also say that there are plenty of managers out there who
will also plan for those costs (successfully or not...) and make the
change to another language for whatever reason.  Again, I have no idea
how many, so I won't guess.

I'm actually in favor of using the right language for the job.  Some
problems lend themselves to using specific languages (or classes
thereof) and it's easier in the long run to teach the project crew the
new language than to deal with using an inappropriate language.  In my
job, I do quite a bit of switching back and forth between languages and
environments depending on what project I'm working on.  In the last
three years, I've had to learn four different development environments
and three new languages (ok, so one was a dialog of a language I already
knew, but that has it's own peculiarities.)

People switch languages all the time.  Some people use the cost of doing
so as a justification not to.

> MDC
> --
> Marin David Condic
> Real Time & Embedded Systems, Propulsion Systems Analysis
> United Technologies, Pratt & Whitney, Large Military Engines
> M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
> ***To reply, remove "bogon" from the domain name.***
> 
> Visit my web page at: http://www.flipag.net/mcondic


Roy
-- 
What if Bill Gates had a nickel for every time Windows crashed... Oh,
wait.  He does!

Re: A question for my personal knowledge.

[Tucker Taft]

Roy Grimm wrote:
> ...   In the last
> three years, I've had to learn four different development environments
> and three new languages (ok, so one was a dialog of a language I already
> knew, but that has it's own peculiarities.)

I'll bet you meant "dialect" rather than "dialog," or perhaps
the whole program is written in a dialog box?  ;-).

> ...
> Roy

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

Re: A question for my personal knowledge.

[Roy Grimm]

Tucker Taft wrote:
> 
> Roy Grimm wrote:
> > ...   In the last
> > three years, I've had to learn four different development environments
> > and three new languages (ok, so one was a dialog of a language I already
> > knew, but that has it's own peculiarities.)
> 
> I'll bet you meant "dialect" rather than "dialog," or perhaps
> the whole program is written in a dialog box?  ;-).

Whoops.  You're right.  I meant dialect.  Though, I have built more
dialog boxes than I ever wanted to... :-P

Roy

Re: A question for my personal knowledge.

[Roger Racine]

>I hear this argument all the time - "Nobody wants to switch to language
>X because training/education/infrastructure/whatever is too expensive."
>This ends up absurd on the face of it. Stick "Java" in where "X" appears
>above. Apparently people were willing to eat the costs - large or small
>or whatever they really are - in order to get the perceived benefits of
>the new language. This *must* be true or we'd all still be programming
>in assembler.

>I think it ends up coming down to this: "I find language X interesting.
>Hence, I will acquire the resources and start developing in X." versus
>"I hate language Y and someone is encouraging/forcing me to adopt it.
>Hence, language Y will cost too much, take too long, introduce too many
>risks, make it impossible for me to get qualified staff, blah, blah,
>blah." 

There is also the "sqeaky wheel" issue.  There are a few very vocal opponents 
of Ada.  There are fewer (especially in percentages) vocal opponents of C, 
etc.  It is much easier for a manager to say "I do not want to lose this 
employee, so we will do it in that person's favorite language".  

We recently had a former employee come back for a job interview.  He 
specifically said that he would not come back to an Ada job.  There are many
who think it is a blot on their resume to have their current job something 
that is "not marketable", like Ada.  These are (otherwise) very intelligent 
people.

Roger Racine

Re: A question for my personal knowledge.

[Marin David Condic]

Roger Racine wrote:
> We recently had a former employee come back for a job interview.  He
> specifically said that he would not come back to an Ada job.  There are many
> who think it is a blot on their resume to have their current job something
> that is "not marketable", like Ada.  These are (otherwise) very intelligent
> people.
> 
Having been on either side of the job interview, I cannot possibly
imagine how someone looking for a hard working, intelligent, self
starting, go-getter to work on their project would view experience with
some specific computer language as a *negative*. I could imagine someone
saying "interesting, but we don't do that here", but it is difficult to
imagine someone saying "Oh, you worked with language X so it must have
dammaged your brain and made you worthless to do 'real' work!"

I spent two years working with Jovial code. (I refer to this as my
"Exile in New Jersey" :-) Jovial was not something most people are
looking for, but I don't think it was a detriment when I was out looking
for another job. Obviously, I knew how to use a number of other
languages and my real skill was in getting a job done - not being an
expert in the Language Du Jour.

BTW: I've had any number of people contact me saying "I'm currently
working in C++ (or whatever) but I'd really like to go back to
programming in Ada" and ask if I can get them a job. I'm not in a
position to be handing out jobs to everyone I get an e-mail from, but
the point is, there are plenty of programmers who are experienced with a
variety of languages who would *prefer* to be doing Ada. My advice would
be to start encouraging its use in the shop where you are at. If you
can't use it for the direct project, you can probably use it for support
tools or other sideline kinds of things where nobody much cares what you
use. It's a little like the camel getting its nose under the tent -
pretty soon there is a lot more development going on in Ada.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: A question for my personal knowledge.

[Richard D Riehle]

In article <373992FC.86F994D6@pwfl.com>,
	Marin David Condic <condicma@bogon.pwfl.com> wrote:


>... but it is difficult to
>imagine someone saying "Oh, you worked with language X so it must have
>dammaged your brain and made you worthless to do 'real' work!"

 Often attributed to Edsger Dijkstra is the quotation, "Anyone whose
 first programming language is BASIC is fundamentally brain dead."

 Of course, Dijkstra is also reported to have said, "I do not know what
 programming language will be used after the year 2000 but I do know it
 will be called Fortran."

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com 

Re: A question for my personal knowledge.

[Marin David Condic]

Richard D Riehle wrote:
>  Of course, Dijkstra is also reported to have said, "I do not know what
>  programming language will be used after the year 2000 but I do know it
>  will be called Fortran."
> 
Maybe if we had named Ada95 Fortran95 the world would be our oyster? :-)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: A question for my personal knowledge.

[bglbv]

Marin David Condic <condicma@bogon.pwfl.com> writes:

> Richard D Riehle wrote:
> >  Of course, Dijkstra is also reported to have said, "I do not know what
> >  programming language will be used after the year 2000 but I do know it
> >  will be called Fortran."

> Maybe if we had named Ada95 Fortran95 the world would be our oyster? :-)

That would have been an interesting scoop. The current Fortran is in
fact Fortran 95. (It was approved in 1995 November, so Ada 95 is a few
months older.)

Work is in progress to make Fortran 2000 suitable for serious object-oriented
programming. (How successfully? Wait and see... Some of us are already
unhappy that neither generics nor exceptions will make it into Fortran this
time around.)

Re: A question for my personal knowledge.

[William B. Clodius]

bglbv@my-dejanews.com wrote:
> <snip>
> 
> That would have been an interesting scoop. The current Fortran is in
> fact Fortran 95. (It was approved in 1995 November, so Ada 95 is a few
> months older.)
> <snip>

The draft that became Fortran 95 was submitted for public review in
November 95. It passed the nominal review process with minor comments
six months later. However, both correcting one minor comment
(translitterating the title into French did not work which led to a
change in the English title) and getting lost in the ISO beaurocracy,
put off official approval until late spring 1997, and publication until
late 1997.

> Work is in progress to make Fortran 2000 suitable for serious object-oriented
> programming. (How successfully? Wait and see... Some of us are already
> unhappy that neither generics nor exceptions will make it into Fortran this
> time around.)

A committee of eleven unpaid (except for a few vendors's
representatives) part time workers (and one unpaid part time editor that
is not a committee member) has to put their priorities somewhere. If you
want to change their priorities get involved. Another four or five
(competant) members, or ten observers, would do wonders.

The 8x committees apparently put significant time into examining
exception handling, and the Fortran 95 committees put in about two years
(late 94 through early 96) with no significant progress. While a
majority of the F95 committees wanted exception handling, they were
unable to arrive at a concensus on the details of the syntax and
semantics. In the absence of a strong defacto implementation standard,
or a leader to decide things arbitrarily, there will be no true
exception handling in Fortran. In the end they did agree on a floating
point exception model, so at least they got in the most important needs
for their user community, albeit too late for F95 itself.

In 1995/96, when most of the official planning for Fortran 2000 occurred
there was *NO* significant public demand for generics (unless you count
one person as significant.) That, of course, changed by late 1997.

As it is the current committee has trouble handling all it committed to
in early 97, e.g., C interoperability, object orientation, derived type
I/O, polishing floating point exceptions.  The work needs more people to
review it for minor problems, but in their absence that task is getting
dumped on the editor who is very competant but overwhelmed.

The primary worker on object orientation, Malcolm Cohen, is also very
competent. He wrote the first Fortran 90 compiler, apparently unaided,
in one year and understands every aspect of the language. With a little
more help he could do a great job, but the help is almost absent.

http://www.ionet.net/~jwagener/j3/

Re: A question for my personal knowledge.

[Charlie McCutcheon]

I think "interesting we don't do that here" generally translates to "we're not
interested in training you - NEXT".  If you don't have the specific language
skills they want, you're not considered for the job.  That's a negative if you
wanted the job.  So if Ada is not wanted with employers, Ada programmers worry
about being employable.

That said, I certainly think that any decent programmer can and should be able to
learn new languages...  ;-)

Charlie

Marin David Condic wrote:

> Roger Racine wrote:
> > We recently had a former employee come back for a job interview.  He
> > specifically said that he would not come back to an Ada job.  There are many
> > who think it is a blot on their resume to have their current job something
> > that is "not marketable", like Ada.  These are (otherwise) very intelligent
> > people.
> >
> Having been on either side of the job interview, I cannot possibly
> imagine how someone looking for a hard working, intelligent, self
> starting, go-getter to work on their project would view experience with
> some specific computer language as a *negative*. I could imagine someone
> saying "interesting, but we don't do that here", but it is difficult to
> imagine someone saying "Oh, you worked with language X so it must have
> dammaged your brain and made you worthless to do 'real' work!"

....

Re: A question for my personal knowledge

[Larry Kilgallen]

Someone who believes decent programmers can learn new languages
probably would not be happy with an employer who believes otherwise.

Larry Kilgallen

In article <7hp5qk$at@zk2nws.zko.dec.com>, Charlie McCutcheon <"cmccutcheon@NOSPAMbegin"@enet.dec.com> writes:
> I think "interesting we don't do that here" generally translates to "we're not
> interested in training you - NEXT".  If you don't have the specific language
> skills they want, you're not considered for the job.  That's a negative if you
> wanted the job.  So if Ada is not wanted with employers, Ada programmers worry
> about being employable.
> 
> That said, I certainly think that any decent programmer can and should be able to
> learn new languages...  ;-)
> 
> Charlie
> 
> Marin David Condic wrote:
> 
>> Roger Racine wrote:
>> > We recently had a former employee come back for a job interview.  He
>> > specifically said that he would not come back to an Ada job.  There are many
>> > who think it is a blot on their resume to have their current job something
>> > that is "not marketable", like Ada.  These are (otherwise) very intelligent
>> > people.
>> >
>> Having been on either side of the job interview, I cannot possibly
>> imagine how someone looking for a hard working, intelligent, self
>> starting, go-getter to work on their project would view experience with
>> some specific computer language as a *negative*. I could imagine someone
>> saying "interesting, but we don't do that here", but it is difficult to
>> imagine someone saying "Oh, you worked with language X so it must have
>> dammaged your brain and made you worthless to do 'real' work!"
> 
> ....
> 

Re: A question for my personal knowledge

[Chris]

In article <1999May17.145258.1@eisner>, kilgallen@eisner.decus.org says...
>
>Someone who believes decent programmers can learn new languages
>probably would not be happy with an employer who believes otherwise.
>
 
In an ideal world, yes.  In the real world, 99.999% of those hiring have
no clue, they only look for certain words on the resume. If you do not
have those words listed, you've just missed a chance to be even invited for
an interview.

Chris

Re: A question for my personal knowledge

[Marin David Condic]

Chris wrote:
> In an ideal world, yes.  In the real world, 99.999% of those hiring have
> no clue, they only look for certain words on the resume. If you do not
> have those words listed, you've just missed a chance to be even invited for
> an interview.
> 
This is very true if you are dealing with a personnel department or
possibly the sorts of organizations that hire truckloads of associates
degrees to maintain existing payroll applications. However, in my
experience, when you are talking to the person who is actually going to
have to be your boss and the job itself is sufficiently sophisticated,
the language stops being the real concern and your ability to come up
with imaginative solutions to real world problems along with your work
ethic and ability to get things done become far more important.

When I've been in the hiring side of the equation, my biggest concern is
that I have a problem that needs fixing. Project X has certain technical
challenges and a schedule to meet. Am I going to find someone who is
going to make my problems go away? Language is seldom an issue if the
individual in question seems to know anything about embedded systems.
Maybe that's because coding is only a small fraction of the overall job.

But send a request to the personnel department and all they are going to
be able to do is read is buzzwords and see who's resume has matching
buzzwords. Its not their fault - they can't know everything technical
about the people they bring in the door and all they've got to work with
is our description of what we're looking for.

You know, now that I think about it, I never once got a job where I
could point to significant work experience in the language that was
actually used. I've had five different professional jobs and a few
dramatic "job changes" internal to Pratt, and each one of them meant I
had to start using a language I knew almost nothing about. Am I the only
one with this experience?

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: A question for my personal knowledge.

[Marin David Condic]

Charlie McCutcheon wrote:
> 
> I think "interesting we don't do that here" generally translates to "we're not
> interested in training you - NEXT".  If you don't have the specific language
> skills they want, you're not considered for the job.  That's a negative if you
> wanted the job.  So if Ada is not wanted with employers, Ada programmers worry
> about being employable.
> 
I think you missed the original issue. It isn't a case of telling the
prospective employer "I know language X and have been programming in
nothing else but language X for the last 40 years and I don't know any
other languages." It was originally posited that knowing language X
would be viewed as a negative.

For example, I'm interviewing for an embedded programming position where
the languages involved are SNOBOL and Lisp. I tell the interviewer, "Why
yes, I know and have used in practical projects SNOBOL and Lisp. As a
matter of fact I was on the design team that invented both of these
languages. I've been called into court to testify as an expert witness
on the precise interpretations of both SNOBOL and Lisp. Why, I could
roughly estimate the amount of absolutely flawless lines of SNOBOL and
Lisp I've written as easily going into the billions. Oh, and I also have
used Ada in case you ever want to use that in an embedded system."

The employer turns and says "Hmmmmm... Ada, eh? I'm terribly sorry, but
we don't allow Ada speakers to work here. We feel that anyone who
bothers to learn Ada must be a member of a criminal subclass, a
dangerous Bolshevek revolutionary, a rebellious malcontent and a freak
of nature who could *never* fit into civilized society. Now I'll thank
you sir to leave before I call security!"

Somehow I can't find that scenario to be realistic. Somehow, I have some
faith in people who hire software engineers to have some knowledge of
what it is they are supervising and that they wouldn't hold knowledge of
a given language against someone, provided they were well qualified for
the task at hand. They might foolishly overlook an otherwise qualified
Software Engineer for lack of experience with their language of the day
- a dumb move, if you ask most of us - but I couldn't see people being
so stupid or bigoted that they would actually hold knowledge of a
specific language against someone.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: A question for my personal knowledge.

[Dan Nagle]

Hello,

Siamak Kaveh wrote:
> 
> Hello Everybody,
> 
> Accepting that Ada is one of the best available programming languages, the
> following question comes to my mind: Why BIG PLAYERS of computer industry
> (IBM, HP, COMPAQ(Digital), CRAY, Microsoft, SUN...) don't develop their
> native ADA compiler? 

I don't know about the rest, but the reason Cray dropped their Ada
was because there wasn't that much demand for it in the Cray market
(of course, large scale number crunching 99.99% done in Fortran).

The idea originally was that one would simulate the missile's
processor, including the program it was running, along with the
airframe stresses, CFD, etc.  The program running in the missile's
processor was, of course, written in Ada.  So your Fortran code
would call an Ada routine to ask "what are you going to do now?"
during the simulation.

I'm surprised to see Cray listed with the "Big Boys"; I don't think
Cray ever got much above $700 M - $800 M per year.  Now, they're
part of SGI.

<snip rest of post>

-- 

Cheers!
Dan Nagle		dnagle@erols.com
Purple Sage Computing Solutions, Inc.

Re: A question for my personal knowledge.

[Jean-Pierre Rosen]

Siamak Kaveh a �crit dans le message
<1VEZ2.1515$I51.88140@carnaval.risq.qc.ca>...
>Hello Everybody,
>
>Accepting that Ada is one of the best available programming
languages, the
>following question comes to my mind: Why BIG PLAYERS of computer
industry
>(IBM, HP, COMPAQ(Digital), CRAY, Microsoft, SUN...) don't develop
their
>native ADA compiler? (or they disconnected their development).
>
It is true that Ada never got much support from hardware vendors.
Remember that one of Ada's major benefits is that is allows you to
write truly portable code, so you can switch hardware more easily, and
THAT is not very appealing to hardware vendors...
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: A question for my personal knowledge.

[Robert Dewar]

In article <7h8v9n$dm4$2@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> It is true that Ada never got much support from hardware
> vendors. Remember that one of Ada's major benefits is that is
> allows you to write truly portable code, so you can switch
> hardware more easily, and THAT is not very appealing to
> hardware vendors...


There is absolutely NO evidence to support this conspiracy
theory. After all the same can be said of COBOL, it definitely
allows you to write truly portable code.

In fact Ada got a lot of support from hardware vendors. Nearly
every vendor ensured that Ada compilers were available, either
by building them or making sure someone else built them. Today
only SGI seems to have a direct primary commitment to Ada, but
I suspect that is a development that reflects two things:

1. The Ada market turned out smaller than people expected

2. Hardware manufacturers are turning in the direction of
   outsourcing things like Ada compilers anyway (this is at
   least a large part of why Digital abandoned their own Ada
   compiler, even though it made money for them).



--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---