Is C/C++ the future?

Is C/C++ the future?

[Gregory Aharonian]

   The October 1994 issue of UPSIDE (a yuppy kind of entrepreneurial magazine
popular in Silicon Valley) has an article on one of the roundtable discussions
of industry leaders, in this case predicting what technology will be like in
the year 2000.

   On the panel were Gordon Bell (father of the VAX), Robert Lucky (VP of
applied research at Bellcore), Nathan Myhrvold (VP of advanced technology at
Microsoft), Jef Raskin (one father of the Macintosh GUI), and John Warnock
(CEO of Adobe).

   One of the questions was: "What will be the dominant programming language?"
with the following responses:

BELL:  Visual Basic, Mosaic markup language, C++, Cobol, Fortran, Telescript
LUCKY: C++. There will be too much investment in code to change this.
MYHRVOLD: C and C++
RASKIN: BASIC
WARNOCK: C

   Admittedly a very small sample, tho from representatives of companies with
a much bigger influence in determining the future of programming than anyone
in the Ada Mandated world, especially in light of industry trends.

  As an example of what Lucky is referring to, Taligent (an IBM/Apple/HP joint
effort) is releasing this summer a developer release of the TAE (Taligent
Application Environment) - a collection of 100 frameworks, comprising over
2000 C++ classes and over 30,000 member functions, and who knows how many
million lines of C++ code.  This dwarfs anything in the non-Mandated part of
the Ada world.  Along with Taligent, Microsoft and Sun (whose OpenStep has
already been shipped to 100,000 users - larger than the installed Ada base)
are also coming out similarly large and complex C++ systems that will be 
adopted by large sectors of the corporate software world. Who will want to
adopt other languages once companies start investing in these systems?  Why
switch away from these industry standards?  Just to get a compiler that stops
when it encounters an error?

(And guess who funded tons of the academic R&D that is being used on these
large C++ environments.  ARPA, and it still is so funding, apparently in
cahoots with the Air Force [KBSA] and the SEI. So much for military loyalty.
The Ada9X academic campaign is a complete waste of time and money because
ARPA already has cornered DoD influence of the academic world and ARPA has no
intention of allowing any other branch of the DoD to seriously encroach on 
their turf with Ada).

   Convert? Certainly not any customer of TeamAda member IBM.  IBM's future 
OO plans will be based on its' VisualAge and VisualGen.  To supplement these
tools, IBM intends to get back into the compiler business in a big way with
C++, object oriented Cobol and perhaps even object oriented PL/1.  Also
coming are Smalltalk, object oriented REXX, Visual RPG and Microsoft's Visual
Basic.  IBM intends to deliver fully compatible versions of most compilers
across all its strategic systems, which now includes OS/2, AIX, OS/400 and
MVS.   BUT NOT ADA!!!!!!!  Imagine IBM prefering an object oriented REXX over
Ada.   Having milked all of the Ada pork it can out of the DoD, why should IBM
invest in a dead-end language?  Why should anyone, if as the DualUse plan
shows, even the DoD is unwilling to invest in commercializing Ada?

   Don't believe me?  Well, someone is giving a very rational lecture at the
upcoming weeklong C++ WORLD conference (Austin, TX, 11/14-11/18) on rules of
thumb for managing industrial-strength object-oriented C++ projects.  It
will probably be full of rational tips for using some company's products
as a rationale for using C++ on these large OO projects that are dominating
industry.  Obviously this rational lecture reflects a rational trend by
rational corporate software developers, many of whom will be using either
Taligent's, Microsoft's, or Sun's environments and need strong C++ tools,
rationally.

   Nothing DISA and the ASA is doing with its DualUse plans will have any
effect (assuming they care to measure) whatsoever on industry use of Ada.
All their plans will do is to further entrench Ada as a niche language for
those very large, critical systems that are too rare to be a basis for a
thriving industry.  Other than for that need, both outside and INSIDE the
DoD, Ada won't be used, no matter how many meaningless and conflicting
mandates the DoD issues (like Mosemann's AI memo that strategically ommitted
mentioning Ada, probably the inspiration for the Defense Science Board not
to cover Ada in its study).


Greg Aharonian

Re: Is C/C++ the future?

[David Weller]

In article <CwLAx0.GxJ@world.std.com>,
Gregory Aharonian <srctran@world.std.com> wrote:

Don't panic folks, I have no intention on commenting on Greg's
tirades, I simply want to make one small correction:

>   Convert? Certainly not any customer of TeamAda member IBM.  IBM's future 
					   ^^^^^^^^^^^^^^^^^^
I have no idea what this is in reference to -- there is no such thing
as a "corporate" Team Ada member.  Doesn't even make sense.


-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
             Ada 9X -- It doesn't suck                       ||  father's Ada
For all sorts of interesting Ada 9X tidbits, run the command:||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) 

Re: Is C/C++ the future?

[Bernie Thompson]

In <CwLAx0.GxJ@world.std.com>, srctran@world.std.com (Gregory Aharonian) writes:
>  As an example of what Lucky is referring to, Taligent (an IBM/Apple/HP joint
>effort) is releasing this summer a developer release of the TAE (Taligent
>Application Environment) - a collection of 100 frameworks, comprising over
>2000 C++ classes and over 30,000 member functions, and who knows how many
>million lines of C++ code. 
>   Convert? Certainly not any customer of TeamAda member IBM.  IBM's future 
>OO plans will be based on its' VisualAge and VisualGen. 
>Greg Aharonian

VisualAge uses SOM as its underlying object binding method.
Taligent will provide SOM wrappers for its C++ classes.

SOM is language-neutral.  Although ADA bindings havn't yet been
produced (to my knowledge), there is nothing to prevent it.
And that would mean Ada code could call/subclass/etc all of that
C++ code.

The judgements here are that use of anything other than C++ would be
rejected by the marketplace.

Bernie

Re: Is C/C++ the future?

[David Weller]

In article <CwLqrD.KDo@bocanews.bocaraton.ibm.com>,
Bernie Thompson <bernie_thompson@bocaraton.ibm.com> wrote:
>
>VisualAge uses SOM as its underlying object binding method.
>Taligent will provide SOM wrappers for its C++ classes.
>
>SOM is language-neutral.  Although ADA bindings havn't yet been
>produced (to my knowledge), there is nothing to prevent it.
>And that would mean Ada code could call/subclass/etc all of that
>C++ code.
>
>The judgements here are that use of anything other than C++ would be
>rejected by the marketplace.
>
Unless you're using Ada :-)  

This goes back to my discussion about following the market vs.
creating the market.

I'm in the "If you build it, they will come" category :-)


-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
   	      Ada -- Very Cool.  Doesn't Suck.               ||  father's Ada 
For all sorts of interesting Ada tidbits, run the command:   ||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) 

Re: Is C/C++ the future?

[Joseph Skinner]

In article <CwLAx0.GxJ@world.std.com> srctran@world.std.com (Gregory Aharonian) writes:
>   The October 1994 issue of UPSIDE (a yuppy kind of entrepreneurial magazine
>popular in Silicon Valley) has an article on one of the roundtable discussions
>of industry leaders, in this case predicting what technology will be like in
>the year 2000.
>
>   On the panel were Gordon Bell (father of the VAX), Robert Lucky (VP of
>applied research at Bellcore), Nathan Myhrvold (VP of advanced technology at
>Microsoft), Jef Raskin (one father of the Macintosh GUI), and John Warnock
>(CEO of Adobe).
>
>   One of the questions was: "What will be the dominant programming language?"
>with the following responses:
>
>BELL:  Visual Basic, Mosaic markup language, C++, Cobol, Fortran, Telescript
>LUCKY: C++. There will be too much investment in code to change this.
>MYHRVOLD: C and C++
>RASKIN: BASIC
>WARNOCK: C
>
>   Admittedly a very small sample, tho from representatives of companies with
>a much bigger influence in determining the future of programming than anyone
>in the Ada Mandated world, especially in light of industry trends.
>
>  As an example of what Lucky is referring to, Taligent (an IBM/Apple/HP joint
>effort) is releasing this summer a developer release of the TAE (Taligent
>Application Environment) - a collection of 100 frameworks, comprising over
>2000 C++ classes and over 30,000 member functions, and who knows how many
>million lines of C++ code.  This dwarfs anything in the non-Mandated part of

From what I've heard the TAE comprises only about 3/4 M lines of code
largely due to heavy code reuse. This makes it smaller than C projects
such as NT at ~4 M.

>the Ada world.  Along with Taligent, Microsoft and Sun (whose OpenStep has
>already been shipped to 100,000 users - larger than the installed Ada base)
>are also coming out similarly large and complex C++ systems that will be
>adopted by large sectors of the corporate software world. Who will want to
>adopt other languages once companies start investing in these systems?  Why
>switch away from these industry standards?  Just to get a compiler that stops
>when it encounters an error?
>
>(And guess who funded tons of the academic R&D that is being used on these
>large C++ environments.  ARPA, and it still is so funding, apparently in
>cahoots with the Air Force [KBSA] and the SEI. So much for military loyalty.
>The Ada9X academic campaign is a complete waste of time and money because
>ARPA already has cornered DoD influence of the academic world and ARPA has no
>intention of allowing any other branch of the DoD to seriously encroach on
>their turf with Ada).
>
>   Convert? Certainly not any customer of TeamAda member IBM.  IBM's future
>OO plans will be based on its' VisualAge and VisualGen.  To supplement these
>tools, IBM intends to get back into the compiler business in a big way with
>C++, object oriented Cobol and perhaps even object oriented PL/1.  Also
>coming are Smalltalk, object oriented REXX, Visual RPG and Microsoft's Visual
>Basic.  IBM intends to deliver fully compatible versions of most compilers
>across all its strategic systems, which now includes OS/2, AIX, OS/400 and
>MVS.   BUT NOT ADA!!!!!!!  Imagine IBM prefering an object oriented REXX over
>Ada.   Having milked all of the Ada pork it can out of the DoD, why should IBM
>invest in a dead-end language?  Why should anyone, if as the DualUse plan
>shows, even the DoD is unwilling to invest in commercializing Ada?

OO Rexx is something which is a natural extension to the Rexx language
but has very little to do with Ada as the 2 langauages are really not
likely to be used for the same things. Consider that Rexx was designed
as a replacement for JCL.

Also since IBMs direction with OOP seems to be strongly influenced by
CORBA IDL as seen in SOM there is really no reason for not using Ada 9x.

>
>   Don't believe me?  Well, someone is giving a very rational lecture at the
>upcoming weeklong C++ WORLD conference (Austin, TX, 11/14-11/18) on rules of
>thumb for managing industrial-strength object-oriented C++ projects.  It
>will probably be full of rational tips for using some company's products
>as a rationale for using C++ on these large OO projects that are dominating
>industry.  Obviously this rational lecture reflects a rational trend by
>rational corporate software developers, many of whom will be using either
>Taligent's, Microsoft's, or Sun's environments and need strong C++ tools,
>rationally.
>
>   Nothing DISA and the ASA is doing with its DualUse plans will have any
>effect (assuming they care to measure) whatsoever on industry use of Ada.
>All their plans will do is to further entrench Ada as a niche language for
>those very large, critical systems that are too rare to be a basis for a
>thriving industry.  Other than for that need, both outside and INSIDE the
>DoD, Ada won't be used, no matter how many meaningless and conflicting
>mandates the DoD issues (like Mosemann's AI memo that strategically ommitted
>mentioning Ada, probably the inspiration for the Defense Science Board not
>to cover Ada in its study).

Joe.

--
===============================================================================
Joseph Skinner                      | Invercargill
usenet: joe@jsnode.equinox.gen.nz   | New Zealand

There is no such thing as a wizard who minds his own business
                          - Berengis the Black
                            Court Mage to the Earl Caeline

Re: Is C/C++ the future?

[Michael M. Bishop]

In article <CwLAx0.GxJ@world.std.com>,
Gregory Aharonian <srctran@world.std.com> wrote:
[snip]
>   One of the questions was: "What will be the dominant programming language?"
>with the following responses:
>
>BELL:  Visual Basic, Mosaic markup language, C++, Cobol, Fortran, Telescript
>LUCKY: C++. There will be too much investment in code to change this.
>MYHRVOLD: C and C++
>RASKIN: BASIC
>WARNOCK: C
[snip]

If you had asked this question twenty years ago, how many "experts"
would have predicted that C or C++ would be a dominant language? I know
C++ didn't exist then, but C did. I doubt that anyone back then would
have expected it to be a dominant language. Therefore, from the above,
no one can conclude that Ada will not be a dominant language. As for
comments on the above, although Cobol and Fortran are dominant languages
now and will be in the near future, their influence will decline. As
more and more companies realize that there are big bucks in
reengineering, applications in those languages will be reengineered
using modern languages. And I have to wonder about that Raskin guy (unless
he means Visual Basic :-).
-- 
| Mike Bishop              | The opinions expressed here reflect    |
| bishopm@source.asset.com | those of this station, its management, |
| Member: Team Ada         | and the entire world.                  |

Re: Is C/C++ the future?

[Carlos Perez]

In article <36cvaj$7l4@source.asset.com>,
 on 28 Sep 1994 19:47:31 -0400,
 Michael M. Bishop <bishopm@source.asset.com> writes:
>In article <CwLAx0.GxJ@world.std.com>,
>Gregory Aharonian <srctran@world.std.com> wrote:
>[snip]
>>   One of the questions was: "What will be the dominant programming language?"
>>with the following responses:
>>
>>BELL:  Visual Basic, Mosaic markup language, C++, Cobol, Fortran, Telescript
>>LUCKY: C++. There will be too much investment in code to change this.
>>MYHRVOLD: C and C++
>>RASKIN: BASIC
>>WARNOCK: C
>[snip]
>
>If you had asked this question twenty years ago, how many "experts"
>would have predicted that C or C++ would be a dominant language? I know
>C++ didn't exist then, but C did. I doubt that anyone back then would
>have expected it to be a dominant language. Therefore, from the above,
>no one can conclude that Ada will not be a dominant language. As for
>comments on the above, although Cobol and Fortran are dominant languages
>now and will be in the near future, their influence will decline. As
>more and more companies realize that there are big bucks in
>reengineering, applications in those languages will be reengineered
>using modern languages. And I have to wonder about that Raskin guy (unless
>he means Visual Basic :-).
>--
>| Mike Bishop              | The opinions expressed here reflect    |
>| bishopm@source.asset.com | those of this station, its management, |
>| Member: Team Ada         | and the entire world.                  |

In the future, we will all be programming in Visual Assembler, using
a methodology called OOH (object-oriented hacking).  Ada will
be dead, so will be OS/2.  Instead, we will be using Windows MNT
(much newer technology).  Even the airplanes we fly will use
Windows/C++++ kernels for flight control, as well as TVs, VCRs,
bathrooms... (UAEs and GPFs will still happen occassionally, but no-one
will care because everyone is happy in the Post-Mandate world!).

O.K., just kidding, but its fun to speculate!

+--------------------------------------------------+
|   Carlos Perez           Loral Federal Systems   |
|   perez@lfs.loral.com    Colorado Springs, CO    |
+--------------------------------------------------+

Re: Is C/C++ the future?

[Bob Wells #402]

David Weller <dweller@STARBASE.NEOSOFT.COM> writes

> In article <CwLqrD.KDo@bocanews.bocaraton.ibm.com>,
> Bernie Thompson <bernie_thompson@bocaraton.ibm.com> wrote:
> >
> >VisualAge uses SOM as its underlying object binding method.
> >Taligent will provide SOM wrappers for its C++ classes.
> >
> >SOM is language-neutral.  Although ADA bindings havn't yet been
> >produced (to my knowledge), there is nothing to prevent it.
> >And that would mean Ada code could call/subclass/etc all of that
> >C++ code.
> >
> >The judgements here are that use of anything other than C++ would be
> >rejected by the marketplace.
> >
> Unless you're using Ada :-)
>
> This goes back to my discussion about following the market vs.
> creating the market.
>
> I'm in the "If you build it, they will come" category :-)

OK Dave, so how do we "ease his pain" and "go the distance?"

Bob W. (-:

Re: Is C/C++ the future?

[R. William Beckwith]

Bernie Thompson (bernie_thompson@bocaraton.ibm.com) wrote:
: In <CwLAx0.GxJ@world.std.com>, srctran@world.std.com (Gregory Aharonian) writes:
: >  As an example of what Lucky is referring to, Taligent (an IBM/Apple/HP joint
: >effort) is releasing this summer a developer release of the TAE (Taligent
: >Application Environment) - a collection of 100 frameworks, comprising over
: >2000 C++ classes and over 30,000 member functions, and who knows how many
: >million lines of C++ code. 
: >   Convert? Certainly not any customer of TeamAda member IBM.  IBM's future 
: >OO plans will be based on its' VisualAge and VisualGen. 
: >Greg Aharonian

: VisualAge uses SOM as its underlying object binding method.
: Taligent will provide SOM wrappers for its C++ classes.

: SOM is language-neutral.  Although ADA bindings havn't yet been
: produced (to my knowledge), there is nothing to prevent it.
: And that would mean Ada code could call/subclass/etc all of that
: C++ code.

OIS and MITRE have written an IDL to Ada 95 mapping document.  Someone
_is_ working on a SOM/Ada 95 product.  Talk to oec@ocsystems.com.

: The judgements here are that use of anything other than C++ would be
: rejected by the marketplace.

You guys are going to miss the boat with this kind of thinking.
Watch out.  Your competition thinks Ada is a crucial technology
and market.  You've been warned.

: Bernie

... Bill

-- 
e-mail: Bill.Beckwith@ois.com       |    Team Ada
Objective Interface Systems, Inc.   | dist, full O-O
1895 Preston White Drive, Suite 250 | multithreading
Reston, VA  22091-5448  U.S.A.      |    built in

Re: Is C/C++ the future?

[jjb]

In article <Cxo19s.5MJ@ois.com>, beckwb@ois.com (R. William Beckwith) writes:
|> Bernie Thompson (bernie_thompson@bocaraton.ibm.com) wrote:
|> : In <CwLAx0.GxJ@world.std.com>, srctran@world.std.com (Gregory Aharonian) writes:
|> : >  As an example of what Lucky is referring to, Taligent (an IBM/Apple/HP joint
|> : >effort) is releasing this summer a developer release of the TAE (Taligent
|> : >Application Environment) - a collection of 100 frameworks, comprising over
|> : >2000 C++ classes and over 30,000 member functions, and who knows how many
|> : >million lines of C++ code. 
|> : >   Convert? Certainly not any customer of TeamAda member IBM.  IBM's future 
|> : >OO plans will be based on its' VisualAge and VisualGen. 
|> : >Greg Aharonian
|> 
|> : VisualAge uses SOM as its underlying object binding method.
|> : Taligent will provide SOM wrappers for its C++ classes.
|> 
|> : SOM is language-neutral.  Although ADA bindings havn't yet been
|> : produced (to my knowledge), there is nothing to prevent it.
|> : And that would mean Ada code could call/subclass/etc all of that
|> : C++ code.
|> 
|> OIS and MITRE have written an IDL to Ada 95 mapping document.  Someone
|> _is_ working on a SOM/Ada 95 product.  Talk to oec@ocsystems.com.
|> 
|> : The judgements here are that use of anything other than C++ would be
|> : rejected by the marketplace.
|> 
|> You guys are going to miss the boat with this kind of thinking.
|> Watch out.  Your competition thinks Ada is a crucial technology
|> and market.  You've been warned.

  Hmm...I thought CORBA IDL was going to make all OO languages
work together.  Then the new OO world would be divided into Microsoft
OLE and CORBA, not into SmallTalk, C++ and Ada, etc.  By the way,
how's the Ada/OLE binding coming along?

|> 
|> : Bernie
|> 
|> ... Bill
|> 
|> -- 
|> e-mail: Bill.Beckwith@ois.com       |    Team Ada
|> Objective Interface Systems, Inc.   | dist, full O-O
|> 1895 Preston White Drive, Suite 250 | multithreading
|> Reston, VA  22091-5448  U.S.A.      |    built in

-- 
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

Re: Is C/C++ the future?

[John Barton]

In article <Cxo19s.5MJ@ois.com>, beckwb@ois.com (R. William Beckwith) writes:
|> Bernie Thompson (bernie_thompson@bocaraton.ibm.com) wrote:
|> : In <CwLAx0.GxJ@world.std.com>, srctran@world.std.com (Gregory Aharonian) writes:
|> : >  As an example of what Lucky is referring to, Taligent (an IBM/Apple/HP joint
|> : >effort) is releasing this summer a developer release of the TAE (Taligent
|> : >Application Environment) - a collection of 100 frameworks, comprising over
|> : >2000 C++ classes and over 30,000 member functions, and who knows how many
|> : >million lines of C++ code. 
|> : >   Convert? Certainly not any customer of TeamAda member IBM.  IBM's future 
|> : >OO plans will be based on its' VisualAge and VisualGen. 
|> : >Greg Aharonian
|> 
|> : VisualAge uses SOM as its underlying object binding method.
|> : Taligent will provide SOM wrappers for its C++ classes.
|> 
|> : SOM is language-neutral.  Although ADA bindings havn't yet been
|> : produced (to my knowledge), there is nothing to prevent it.
|> : And that would mean Ada code could call/subclass/etc all of that
|> : C++ code.
|> 
|> OIS and MITRE have written an IDL to Ada 95 mapping document.  Someone
|> _is_ working on a SOM/Ada 95 product.  Talk to oec@ocsystems.com.
|> 
|> : The judgements here are that use of anything other than C++ would be
|> : rejected by the marketplace.
|> 
|> You guys are going to miss the boat with this kind of thinking.
|> Watch out.  Your competition thinks Ada is a crucial technology
|> and market.  You've been warned.

  Hmm...I thought CORBA IDL was going to make all OO languages
work together.  Then the new OO world would be divided into Microsoft
OLE and CORBA, not into SmallTalk, C++ and Ada, etc.  By the way,
how's the Ada/OLE binding coming along?

|> 
|> : Bernie
|> 
|> ... Bill
|> 
|> -- 
|> e-mail: Bill.Beckwith@ois.com       |    Team Ada
|> Objective Interface Systems, Inc.   | dist, full O-O
|> 1895 Preston White Drive, Suite 250 | multithreading
|> Reston, VA  22091-5448  U.S.A.      |    built in

-- 
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

Re: Is C/C++ the future?

[R. William Beckwith]

John Barton (jjb@watson.ibm.com) wrote:
: In article <Cxo19s.5MJ@ois.com>, beckwb@ois.com (R. William Beckwith) writes:
: |> Bernie Thompson (bernie_thompson@bocaraton.ibm.com) wrote:
: |> : The judgements here are that use of anything other than C++ would be
: |> : rejected by the marketplace.
: |> 
: |> You guys are going to miss the boat with this kind of thinking.
: |> Watch out.  Your competition thinks Ada is a crucial technology
: |> and market.  You've been warned.

:   Hmm...I thought CORBA IDL was going to make all OO languages
: work together.  Then the new OO world would be divided into Microsoft
: OLE and CORBA, not into SmallTalk, C++ and Ada, etc.  By the way,
: how's the Ada/OLE binding coming along?

Yes.  CORBA IDL holds the goal of transparent interoperability between
languages.  However, there is not yet interoperability between all ORB
products.  Thus, each ORB vendor must support your language of choice.
I was speaking in the context of IBM as an ORB vendor.

I think a lot more people will use Ada now that they _can_.  As the
O/S's and products of the future define their interfaces in IDL,
the benefits of Ada's natural strengths are combined with a clean,
natural interface to GUI's, DBMS's, O/S's, etc.

Regarding Microsoft, actually OLE does not compete with CORBA, COM does.
An OLE interface could be defined with IDL.  A IDL to Ada mapping
committee member mentioned to me that DEC and IONA had such products.

Thus, the Ada/OLE binding is not necessary.  Any ORB vendors Ada/IDL
product would translate the OLE IDL into a usable Ada interface.

Microsoft made a presentation at the Dublin OMG meeting regarding the
interfacing of COM and CORBA.  While they seemed to irritate a few folks
with their approach, I think most were pleased to see Microsoft actively
participate.

... Bill

-- 
e-mail: Bill.Beckwith@ois.com       |    Team Ada
Objective Interface Systems, Inc.   | dist, full O-O
1895 Preston White Drive, Suite 250 | multithreading
Reston, VA  22091-5448  U.S.A.      |    built in

Re: Is C/C++ the future?

[Brad Brahms]

In article <Cxq4Lq.86B@ois.com>, R. William Beckwith <beckwb@ois.com> wrote:
>John Barton (jjb@watson.ibm.com) wrote:
>: In article <Cxo19s.5MJ@ois.com>, beckwb@ois.com (R. William Beckwith) writes:
>: |> Bernie Thompson (bernie_thompson@bocaraton.ibm.com) wrote:
>: |> : The judgements here are that use of anything other than C++ would be
>: |> : rejected by the marketplace.
>: |> 
>: |> You guys are going to miss the boat with this kind of thinking.
>: |> Watch out.  Your competition thinks Ada is a crucial technology
>: |> and market.  You've been warned.
>
[SNIP]
>
>I think a lot more people will use Ada now that they _can_.  As the
>O/S's and products of the future define their interfaces in IDL,
>the benefits of Ada's natural strengths are combined with a clean,
>natural interface to GUI's, DBMS's, O/S's, etc.
>
Lets, see, yes, the DoD still requires Ada.  However, many programs within
the DoD, including new ones, end up having waivers to use other languages,
most notably C or C++.  In the US, most non-DoD work utilizes C, C++,
COBOL or FORTRAN (depending on legacy).  I do not believe there is a lot
of comerical Ada work going on in the US.  When I say this, I mean for actually
producing end products for the comercial market place.  Europe, however,
I believe has taken and use Ada quite a bit in the comerical market place.
Yes, there are exceptions to all of these.  However, these are the trends
that I have noticed going on.

While I'm not an Ada enthusiast, our company is one of the biggest developers
of Ada software.  I have yet to see any large Ada project finish without
some other language, usually in the form of C-bindings, to help!  That is
not to say there arn't any, but just a view of what I have seen.

>Thus, the Ada/OLE binding is not necessary.  Any ORB vendors Ada/IDL
>product would translate the OLE IDL into a usable Ada interface.

Ada/IDL?  Isn't that an oxymoron?  Don't know of ANYONE who has one or
will have Ada/IDL for some time, not to mention Ada to any ORB connectivity.

-- 
--
"Life is like a box of chocolates..."	-- Bradley Brahms
					   TRW
					   brad@truffula.fp.trw.com

Re: Is C/C++ the future?

[James Hopper]

In article <383q62$k0v@truffula.fp.trw.com> Brad Brahms,
brad@truffula.fp.trw.com writes:
>While I'm not an Ada enthusiast, our company is one of the biggest
developers
>of Ada software.  I have yet to see any large Ada project finish without
>some other language, usually in the form of C-bindings, to help!  That is
>not to say there arn't any, but just a view of what I have seen.

This is an unfair and distorted characterization of Ada as being
incomplete
because it requires in many cases support for other languages.  While i to
usually have at least some links to C bindings, its kind of hard not to
when using a Unix based system as the operating system and all the access
libraries for it are written in C!  No one no matter how much they like
Ada
is going to rewrite fully debugged and tested libraries just to have a
100%
Ada solution.  But in my experience its fairly uncommon except when
working
with legacy software to have to write part of the sytem in C because you
cant do it in Ada.  There is a big difference in the two cases, and to
lump them togeather as you have provides a very bad example! How many 
Large C systems get by without writing at least some assembly??


Jim Hopper
SAIC

Re: Is C/C++ the future?

[R. William Beckwith]

Brad Brahms (brad@truffula.fp.trw.com) wrote:
: In article <Cxq4Lq.86B@ois.com>, R. William Beckwith <beckwb@ois.com> wrote:
: >
: >I think a lot more people will use Ada now that they _can_.  As the
: >O/S's and products of the future define their interfaces in IDL,
: >the benefits of Ada's natural strengths are combined with a clean,
: >natural interface to GUI's, DBMS's, O/S's, etc.
: >
: Lets, see, yes, the DoD still requires Ada.  However, many programs within
: the DoD, including new ones, end up having waivers to use other languages,
: most notably C or C++.  In the US, most non-DoD work utilizes C, C++,
: COBOL or FORTRAN (depending on legacy).  I do not believe there is a lot
: of comerical Ada work going on in the US.

The is a bit, but Ada usage is not openly discussed by those that are using
Ada.  The three biggest commerical users I know of do not like the
architecutre of their internal systems discussed for competive reasons.

: When I say this, I mean for actually producing end products for the
: commercial market place.  Europe, however, I believe has taken and
: use Ada quite a bit in the comerical market place.

My experiences lead me to similiar conclusions.

: Yes, there are exceptions to all of these.  However, these are the trends
: that I have noticed going on.

We're hoping to affect these trends.

: While I'm not an Ada enthusiast, our company is one of the biggest developers
: of Ada software.  I have yet to see any large Ada project finish without
: some other language, usually in the form of C-bindings, to help!  That is
: not to say there arn't any, but just a view of what I have seen.

Yes, even our `pure Ada' products have a little C in them to smooth the
interfacing to C libraries.  This is precisely where CORBA helps by
providing interfaces that are not defined in C, but in IDL.

: >Thus, the Ada/OLE binding is not necessary.  Any ORB vendors Ada/IDL
: >product would translate the OLE IDL into a usable Ada interface.

: Ada/IDL?  Isn't that an oxymoron?

Not at all!

: Don't know of ANYONE who has one or will have Ada/IDL for some time,
: not to mention Ada to any ORB connectivity.

We will have it soon.  We know of two other companies working on Ada/IDL
products.  Lots of people want it.

IMHAARO, Ada/IDL will be more fun and easier to use than C++/IDL.

_And_ Ada/IDL will transparently interoperate with C++/IDL.

... Bill

-- 
e-mail: Bill.Beckwith@ois.com       |    Team Ada
Objective Interface Systems, Inc.   | dist, full O-O
1895 Preston White Drive, Suite 250 | multithreading
Reston, VA  22091-5448  U.S.A.      |    built in

Re: Is C/C++ the future?

[Robert Monical]

How about all those unemployed Ada programmers
who used to work DoD related? Will they start
moving the commercial world to Ada?

-- rob:  i e-mail, therefore i am
-- monical@walnut.csp.mmc.com
-- v: 719-528-3777 f: 719-528-3848

Re: Is C/C++ the future?

[Michael Feldman]

In article <1994Oct25.004017.20053@den.mmc.com>,
Robert Monical <monical@walnut.csp.mmc.com> wrote:
>
>How about all those unemployed Ada programmers
>who used to work DoD related? Will they start
>moving the commercial world to Ada?
>
Gosh, I hope so! :-)

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
         Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------

Re: Is C/C++ the future?

[Brad Brahms]

In article <388a97$en1@dayuc.dayton.saic.com>,
James Hopper  <hopperj@dayton.saic.com> wrote:
>In article <383q62$k0v@truffula.fp.trw.com> Brad Brahms,
>brad@truffula.fp.trw.com writes:
>>While I'm not an Ada enthusiast, our company is one of the biggest
>developers
>>of Ada software.  I have yet to see any large Ada project finish without
>>some other language, usually in the form of C-bindings, to help!  That is
>>not to say there arn't any, but just a view of what I have seen.
>
>This is an unfair and distorted characterization of Ada as being
>incomplete

I never intendend to make Ada seem incomplete.  Only its creators can
say that.  That is clearly not the case.  However, my observation
still stands.  For whatever reasons, many large, but not all Ada projects
require atleast some external code to be written in order to get it to
work.  That also includes non legacy code!

>because it requires in many cases support for other languages.  While i to
>usually have at least some links to C bindings, its kind of hard not to
>when using a Unix based system as the operating system and all the access
>libraries for it are written in C!  No one no matter how much they like
>Ada
>is going to rewrite fully debugged and tested libraries just to have a
>100%
>Ada solution.  But in my experience its fairly uncommon except when
>working
>with legacy software to have to write part of the sytem in C because you
>cant do it in Ada.  There is a big difference in the two cases, and to
>lump them togeather as you have provides a very bad example! How many 
>Large C systems get by without writing at least some assembly??

Oh, and yes, I have worked on large systems based on C.  And no, I
don't recall one line of assembler we had to produce.  Maybe that is
the point.  Ada is it own environment.  Unless you write something in
Ada, you are almost always forced to use some type of binding in
another language to get to it.  Yet, I can write C, FORTRAN, C++,
assembler and have them all link together.

Now, to get away from the which language is better flame war that I
have no interest in getting into, the fact remains, market forces
drive what will survive.  While Sony Beta was technically better than
VHS, VHS won out. While Ada is a powerful language, it use in the US
is still mostly in DoD.  Commercially in the US, C & C++ are used.  I
believe it is this market penetration and force that will end up
dictating the language(s) that survive.  An example of how limited the
government can influance a choice is the lack of a metric system in
the US.  That plan was for us was to all be using metric as of several
years ago.  The market force, in this case people, resisted and it died.

My mom told me never to play with fire. :-)
-- 
--
"Life is like a box of chocolates..."	-- Bradley Brahms
					   TRW
					   brad@truffula.fp.trw.com

Re: Is C/C++ the future?

[Michael M. Bishop]

In article <38jmof$111@truffula.fp.trw.com>,
Brad Brahms <brad@truffula.fp.trw.com> wrote:
>In article <388a97$en1@dayuc.dayton.saic.com>,
>James Hopper  <hopperj@dayton.saic.com> wrote:
[snip]
>I never intendend to make Ada seem incomplete.  Only its creators can
>say that.  That is clearly not the case.  However, my observation
>still stands.  For whatever reasons, many large, but not all Ada projects
>require atleast some external code to be written in order to get it to
>work.  That also includes non legacy code!

It may certainly be true that most Ada projects (certainly large ones)
require interfaces to external code written in other languages. You're
also correct in saying that this condition does not make Ada an
incomplete language. In fact, I believe that the ability to easily 
integrate code written in other languages with Ada code is one of the
big strengths of Ada. It's vitally important to me because I'm
developing a Motif application in Ada.
-- 
| Mike Bishop              | The opinions expressed here reflect    |
| bishopm@source.asset.com | those of this station, its management, |
| Member: Team Ada         | and the entire world.                  |

Re: Is C/C++ the future?

[Michael Feldman]

In article <38k5dg$kko@source.asset.com>,
Michael M. Bishop <bishopm@source.asset.com> wrote:

>It may certainly be true that most Ada projects (certainly large ones)
>require interfaces to external code written in other languages. You're
>also correct in saying that this condition does not make Ada an
>incomplete language. In fact, I believe that the ability to easily 
>integrate code written in other languages with Ada code is one of the
>big strengths of Ada. It's vitally important to me because I'm
>developing a Motif application in Ada.

That you are interfacing to Motif code written in C is not due to Ada's
being an incomplete _language_, only due to the fact that not every
library in the world has been (re-)written in Ada.

Indeed, it would be quite foolish to rewrite every bit of existing
library code in Ada - why re-invent the wheel? I'm at a loss to 
understand why anyone would trash Ada because the Motif people
chose to write their stuff in C? Ada 83 compilers provide pretty good,
pretty standard, interfaces to other languages, and Ada 9X is improving
that substantially.

Take a look at the niceties in Interfaces.C, Interfaces.Cobol, and
Interfaces.Fortran. 

It has always baffled me why anyone would consider the desire (or
need) to link to existing libraries, whatever their language of origin,
as a _disadvantage_ of Ada. Bizarre.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
         Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------

Re: Is C/C++ the future?

[Richard Riehle]

In article <38jhj0$ec4@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>In article <1994Oct25.004017.20053@den.mmc.com>,
>Robert Monical <monical@walnut.csp.mmc.com> wrote:
>>
RM>>How about all those unemployed Ada programmers
RM>>who used to work DoD related? Will they start
RM>>moving the commercial world to Ada?

MF>Gosh, I hope so! :-)

    Actually, some are moving to projects elsewhere in other U.S. government
    agencies.  For example, Department of Energy is now using Ada for some
    projects.  A few other agencies are also evaluating it.

    I have been encountering more former DoD programmers who are using Ada
    to build commercial software products.  At least one of them, I see,
    is an occasional contributor to this forum.

    And when the C++ programmers begin to discover Ada 9X, there ought to
    be a massive migration to Ada.  The more I look at Ada 9X, the more
    I realize just how excellent it is.  

    
    Ada is not the language of the future, but it is a language of the future.

    C++ is not the language of the future, but it is also a language of 
       the future.

    There is no single language of the future, probably not even Eiffel, as
    good as that language may be.


    Richard Riehle
    AdaWorks Software Engineering
    Suite 27
    2555 Park Boulevard
    Palo Alto, CA  94306
    (415) 328-1815   FAX  328-1112
    email:  adaworks@netcom.com


     

Re: Is C/C++ the future?

[Richard Riehle]

>>In article <383q62$k0v@truffula.fp.trw.com> Brad Brahms,
>>brad@truffula.fp.trw.com writes:
BB>>>While I'm not an Ada enthusiast, our company is one of the biggest
BB>>developers
BB>>>of Ada software.  I have yet to see any large Ada project finish without
BB>>>some other language, usually in the form of C-bindings, to help!  That is
BB>>>not to say there arn't any, but just a view of what I have seen.

This is probably a fair characterization of many early Ada projects.  One of
early complaints was that Ada compiler vendors would provide a validated
compiler with no platform-specific support packages.  It became the chore of
the compiler user to build such packages, often necessitating the use of
pragma interface to C or assembler.  Sometimes we even had to use the
machine code package, if the compiler vendor were generous enough to include
it.  

This is not a language problem.  It is an incomplete compiler problem.  If
a C compiler or an Eiffel compiler or a FORTRAN compiler were correspondingly
incomplete, there would be a howl of protest throughout the industry.  Only
Ada compiler vendors could get away with this because they ostensibly met
the requriement for validation.         

Sometime in the past two to five years, the better compiler vendors have begun
to recognize that applications are not developed as theoretical exercises, and
platform-specific environments have begun to appear. With this development,
more Ada software can be built without resorting to the use of non-Ada code.

The purchasers of compilers need to become more sophisticated and insist that
a compiler targeted to a particular computer environment should include 
packages that support the unique features of that environment. They need to
understand that a validation certificate is not enough.  For example, IBM's
mainframe Ada compiler never included support for CICS or VSAM, an absolute
requirement for effective programming OS/MVS.  Of course, Intermetrics did
provide that capability for its mainframe compiler, so it was a good choice
for Ada projects.  

Richard Riehle

Re: Is C/C++ the future?

[David Emery]

Ada83 has been criticized for being "AdaCentric".  But in my
experience Ada83 is much easier/more flexible in its ability to call
other languages than any other language I've worked with.  In
particular, representation specifications make it possible to define
an Ada type that matches the (often bizarre) data representations in
other languages.  

"AdaCentrism" is a problem with respect to elaboration, but we're
collectively working on this issue.  

If you think Ada83 is bad, try to figure out how to integrate C++
with anything besides C!

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Is C/C++ the future?

[R. William Beckwith]

David Emery (emery@goldfinger.mitre.org) wrote:

: If you think Ada83 is bad, try to figure out how to integrate C++
: with anything besides C!

Integrating C++ with C isn't always easy either.

... Bill

-- 
e-mail: Bill.Beckwith@ois.com       |    Team Ada
Objective Interface Systems, Inc.   | dist, full O-O
1895 Preston White Drive, Suite 250 | multithreading
Reston, VA  22091-5448  U.S.A.      |    built in

Re: Is C/C++ the future?

[Michael Feldman]

In article <CyB6K5.Huq@ois.com>, R. William Beckwith <beckwb@ois.com> wrote:
>David Emery (emery@goldfinger.mitre.org) wrote:
>
>: If you think Ada83 is bad, try to figure out how to integrate C++
>: with anything besides C!
>
>Integrating C++ with C isn't always easy either.
>
True, but one can do it quite easily by simply avoiding the ++ part.:-)

You'd be surprised how far you can get by writing C, compiling it
with a C++ compiler, and then claiming to all who will listen that
you've written in C++. :-) :-)

(Undoubtedly there will be an Ada version of this phenomenon at some
point in the near future. :-))

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
         Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------

Re: Is C/C++ the future?

[R. William Beckwith]

Michael Feldman (mfeldman@seas.gwu.edu) wrote:

: You'd be surprised how far you can get by writing C, compiling it
: with a C++ compiler, and then claiming to all who will listen that
: you've written in C++. :-) :-)

There's still the problem of trying to use the C code that didn't
get compiled with your C++ compiler.

: (Undoubtedly there will be an Ada version of this phenomenon at some
: point in the near future. :-))

Fortunately the jump from Ada 83 to Ada 9X is much smaller than the
leap from C to C++.

-- 
e-mail: Bill.Beckwith@ois.com       |    Team Ada
Objective Interface Systems, Inc.   | dist, full O-O
1895 Preston White Drive, Suite 250 | multithreading
Reston, VA  22091-5448  U.S.A.      |    built in

Re: Is C/C++ the future?

[Robb Nebbe]

In article <38p3uk$ouv@felix.seas.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
|> In article <CyB6K5.Huq@ois.com>, R. William Beckwith <beckwb@ois.com> wrote:
|> >David Emery (emery@goldfinger.mitre.org) wrote:
|> >
|> >: If you think Ada83 is bad, try to figure out how to integrate C++
|> >: with anything besides C!
|> >
|> >Integrating C++ with C isn't always easy either.
|> >
|> True, but one can do it quite easily by simply avoiding the ++ part.:-)
|> 
|> You'd be surprised how far you can get by writing C, compiling it
|> with a C++ compiler, and then claiming to all who will listen that
|> you've written in C++. :-) :-)
|> 
|> (Undoubtedly there will be an Ada version of this phenomenon at some
|> point in the near future. :-))
|> 

There already is. I've seen a lot of code that looks like Pascal with
a few cosmetic changes that is passed off as Ada.

- Robb Nebbe

Re: Is C/C++ the future?

[Michael Feldman]

In article <CyCuBC.JnF@ois.com>, R. William Beckwith <beckwb@ois.com> wrote:
>Michael Feldman (mfeldman@seas.gwu.edu) wrote:
>
>: You'd be surprised how far you can get by writing C, compiling it
>: with a C++ compiler, and then claiming to all who will listen that
>: you've written in C++. :-) :-)
>
>There's still the problem of trying to use the C code that didn't
>get compiled with your C++ compiler.

Sure. I was just being smart-ass, pointing at the fact that there seems
to be a fair amount of C masquerading as C++, so that folks can please 
their managers or customers. This is anecdotal; I don't have proof.
I hope nobody took me seriously - there were _two_ smileys up there.
>
>: (Undoubtedly there will be an Ada version of this phenomenon at some
>: point in the near future. :-))
>
>Fortunately the jump from Ada 83 to Ada 9X is much smaller than the
>leap from C to C++.

Yes. Indeed, I wish we would all agree to make _less_ of a big deal
about Ada 9X. There are enough _Ada 83_ success stories out there
to tell us, and the rest of the world, that Ada 83 has NOTHING to be
embarrassed about. 

If you have not read all the success stories (I posted a few new ones
here last week) grab 'em from the AJPO machine or the Web server. You'll
be pleasantly surprised.

Not all applications need inheritance (indeed, NONE of the successful 
projects have used inheritance because they are all Ada 83); not all 
applications need the improved tasking and protected types.

The niceties in Ada 9X are an _improvement_ on something that is starting
out as a damn nice invention to begin with. In the heat of discussion
of Ada 9X details, let's try not to forget that. And tell your friends.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
         Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------

Re: Is C/C++ the future?

[Marc Wachowitz]

Mark S. Hathaway (hathawa2@muvms6.wvnet.edu) wrote:
[...]
> What if a new language was specifically designed to allow for the use of
> libraries written in COBOL, Fortran, Pascal, Modula-2, Ada, C, Smalltalk,
> Lisp (or whatever widely-used languages could be included)?

Isn't that the case with Ada9x, at least for some of the languages you're
mentioning? (The problem with the very high level languages, as Smalltalk
or Lisp, is that they may be too different from the others you mention to
make a powerful and portable interface between those languages in various
implementations possible - just look how different their foreign function
interfaces are, if they have one at all.)

------------------------------------------------------------------------------
   *   wonder everyday   *   nothing in particular   *   all is special   *
                Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>

Re: Is C/C++ the future?

[Fred McCall]

In <1994Oct25.234705.26530@sei.cmu.edu> riehler@ajpo.sei.cmu.edu Richard Riehle writes:

>This is not a language problem.  It is an incomplete compiler problem.  If
>a C compiler or an Eiffel compiler or a FORTRAN compiler were correspondingly
>incomplete, there would be a howl of protest throughout the industry.  Only
>Ada compiler vendors could get away with this because they ostensibly met
>the requriement for validation.         

Doesn't this problem (not being able to write 'real' programs, according
to the respondent, without requiring all that machine-specific support)
pretty much shoot the much-vaunted 'portability' of Ada code in the
foot?  It seems to me that this leaves Ada with the same problem that so
many Ada advocates want to 'bash' C/C++ for -- non-portable code is
non-portable (somewhat solipsist, but that seems to be the complaint).

Should the language include platform independent ways of doing most of
those 'platform-specific' things?  It would seem to follow the Ada
philosophy of maximal safety; after all, if pieces of configuration
control are required to be part of the linker, why not define an 'Ada
windows' interface (for example) and then require compilers for
platforms with window support to map their functionality onto the
interface? 



--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
---------------------------------------------------------------------------
merlin@annwfn.com -- I don't speak for others and they don't speak for me.

Re: Is C/C++ the future?

[Richard Riehle]

In article <1994Oct30.210203.1863@muvms6> hathawa2@muvms6.wvnet.edu (Mark S. Hathaway) writes:

>If you don't think Ada is complete, but Fortran is then I'm confused.

  Ada is just as complete as FORTRAN.  The issue is platform targeting.
  

>Isn't the problem of libraries one of major importance these days?  Every
>language has it's own libraries and they're not compatible and some are
>so closely attached to an operating system that they're not very portable
>and...<argh>

  I would agree that the issue of incompatibility has been a serious 
  problem with Ada 83/87.  Each compiler vendor took a different approach,
  if any, to defining libraries for targeted platforms.  Often, early Ada
  compilers lacked any useful libraries.  This improved in the late eighties
  and early ninties.  

  Ada 9X defines uniform package specifications as a remedy to this problem.


>Once you've got a good procedural language like Pascal, Modula-2, Ada, C,
>etc. there should be an extension of that utility by having better
>reusability across languages.

 None of the languages you name have fully compatibile libraries.  C, as a
 universal assembler, includes good support for hadware level programming,
 as one would expect of any other assembler.  The other languages are 
 high-order languages that require system-level libraries.  These are not
 defined as part of the language design.  
 
>What if a new language was specifically designed to allow for the use of
>libraries written in COBOL, Fortran, Pascal, Modula-2, Ada, C, Smalltalk,
>Lisp (or whatever widely-used languages could be included)?

 Interesting notion. Have you been peeking at the Ada 9X reference manual?

>Then, what set of functions/procedures/classes/etc. would constitute
>completeness?

 Each hardware and operating system environment is unique.  To get the best
 performance from such environments will always require libraries that take
 advantage of the best of the unique features.  Sometimes, the absence of
 such libraries will require interfacing with other langauges, machine code
 insertions, or whatever ...  

 This is not sinful and evil. It is not even situational ethics.  Rather,
 it is a reality of using high-order languages where appropriate, and 
 low-level langauges such as C and assembler when appropriate. 
>
>BOO,

  HAPpy Halloween to you, too.  :-)


   Richard Riehle

 

Re: Is C/C++ the future?

[Michael Feldman]

In article <1994Oct28.101326@di.epfl.ch>,
Robb Nebbe <Robb.Nebbe@di.epfl.ch> wrote:

>There already is. I've seen a lot of code that looks like Pascal with
>a few cosmetic changes that is passed off as Ada.

Hmmm. You are right - I've seen this too. Not so much of it recently, 
though. I can always tell the students who learned Pascal before Ada -
their subprograms are nested in Main, and deeply within other subprograms.

And those who learned BASIC first, write procedures without parameters
and left-adjust every statement.

This is fun to laugh at, but this is, in my experience, part of the
learning process and the students' code shows their "accent"
from the "mother tongue".  ('Course this is why I think students'
"mother tongue" should be Ada, to the extent that we can make that
happen...)

I wasn't really thinking of cases like this,
rather of situations where programmers in industry _know_ they
are writing plain C and passing it off as C++.


Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
         Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------

Re: Is C/C++ the future?

[Robb Nebbe]

In article <85DF1879046@annwfn.com>, merlin@annwfn.com (Fred McCall) writes:
|> 
|> Doesn't this problem (not being able to write 'real' programs, according
|> to the respondent, without requiring all that machine-specific support)
|> pretty much shoot the much-vaunted 'portability' of Ada code in the
|> foot?  It seems to me that this leaves Ada with the same problem that so
|> many Ada advocates want to 'bash' C/C++ for -- non-portable code is
|> non-portable (somewhat solipsist, but that seems to be the complaint).
|> 

Obviously things that are outside the langauge are not portable.
Hopefully things that are defined in the language are defined 
with enough precision that they are portable or at least the
limits of their portability are well defined. Futhermore, one
would hope that what is portable is sufficiently complete and
that compilers are available on a sufficient number of different
platforms.

Some languages are more portable than others for a variety of
reasons; many of these reasons are directly related to the
language but some go beyond the language. If anyone was naive
enough to pretend that Ada is more portable than C/C++ then
you must either infer what kind of portability they are talking
about or dismiss it as a blanket statement that language
enthousiast are prone to make.

If you doubt that the definition of Ada is more precise and
the limits to portability better defined as well as better
verified than C/C++ (which is a bit unfair since C++ isn't as
close to standardization as the new revision of Ada) then
you should make your case since this is usually what people
mean when they talk about portability as it relates to a
langauge. 

If you want to talk about other kinds of portability then
that would be fine also since they are certainly pertinent.

- Robb Nebbe

Re: Is C/C++ the future?

[David M. Tannen]

Just to through something else into the mix.  I just got a copy of this
months *Advanced Systems* magazine - a Sun mouthpiece magazine.  They
have an article in it called C++: The Cobol of the 90's.  They are
pretty serious in this article.  It seems to be based on some book that
was recently published.

My personal favorite thing was:  What does C and C++ represent?  Grades
for a language.


{Just thought I would throw some gas on this thread 8-).}



-- 
David Tannen (tannend@source.asset.com)                 TeamAda Member
Christian Acronyms: B.I.B.L.E.=Basic Instructions Before Leaving Earth
                    G.R.A.C.E.=God's Redemption At Christ's Expense
                    F.A.I.T.H.=Forsaking all, I trust Him

Re: Is C/C++ the future?

[Richard Riehle]

In article <85DF1879046@annwfn.com> merlin@annwfn.com (Fred McCall) writes:

>Doesn't this problem (not being able to write 'real' programs, according
>to the respondent, without requiring all that machine-specific support)
>pretty much shoot the much-vaunted 'portability' of Ada code in the
>foot?  It seems to me that this leaves Ada with the same problem that so
>many Ada advocates want to 'bash' C/C++ for -- non-portable code is
>non-portable (somewhat solipsist, but that seems to be the complaint).

  This is a problem one would expect from high-level languages that try
  to be portable.  COBOL, an early attempt at portable HOL was never
  portable because each compiler vendor realized the need to include,
  embedded in the targeted-edition of the compiler, a set of platform-
  specific options.  

  An intelligent designer of an Ada application can create platform-independent  wrappers (as packages) to effect the design of fully portalbe designs. But
  implementations will frequently be non-portable because of the variations
  in operating environments.  An Ada designer has good tools available to
  push platform dependencies to the lowest possible level of abstraction,
  thereby enhancing the portability of the product.  

  Even though Ada 9X provides some relief in this area, the continued progress
  in new hardware designs will necessitate retaining the capability for 
  interfacing high-level code  to low-level code in some applications.   

>
>Should the language include platform independent ways of doing most of
>those 'platform-specific' things?  It would seem to follow the Ada
>philosophy of maximal safety; after all, if pieces of configuration
>control are required to be part of the linker, why not define an 'Ada
>windows' interface (for example) and then require compilers for
>platforms with window support to map their functionality onto the
>interface? 

   In principle, I agree. Much of this lies at the feet of the compiler 
   vendors, who have chosen not to go beyond simple validation with some
   of their products.  And validation requires nothing more than the bare
   essentials of the language.  I provides no guarantee that the compiler
   will be useful for real work.  

   All in all, a language such as Ada is the lesser of two evils when
   compared against assemblers (native or C).  We can, at least, improve
   portablility, even if we do have to resort to some non-portable code
   from time to time.   

   Richard Riehle




   

Re: Is C/C++ the future?

[AdaWorks]

In article <395kgi$aun@source.asset.com> tannend@source.asset.com (David M. Tannen) writes:
>Just to through something else into the mix.  I just got a copy of this
>months *Advanced Systems* magazine - a Sun mouthpiece magazine.  They
>have an article in it called C++: The Cobol of the 90's.  They are
>pretty serious in this article.  It seems to be based on some book that
>was recently published.
>
   The article is excerpted from the "Unix Hater's Handbook," published
   at MIT.  It is exceptionally uncomplimentary of C++.  In fact, the
   tone is reminiscent of that found in some early anti-Ada tracts. 

   The message seems to be, "If you love clarity, you'll hate C++."

   Advanced Systems can be reached at (415) 243-4188, if you have a
   compelling need to satisfy your longing for techno-diatribe.

   Richard Riehle

-- 
                                             adaworks@netcom.com

Re: Is C/C++ the future?

[Michael Feldman]

In article <1994Nov1.131914.14904@sei.cmu.edu>,
Richard Riehle <riehler@ajpo.sei.cmu.edu> wrote:

[snip]

>  Even though Ada 9X provides some relief in this area, the continued progress
>  in new hardware designs will necessitate retaining the capability for 
>  interfacing high-level code  to low-level code in some applications.   

Part of the "relief" provided in Ada 9X is the annexes, which can be
thought of as optional, extendible, parts of the standard. The annexes
do not introduce syntax, only packages, types, pragmas, etc. See below.

>>Should the language include platform independent ways of doing most of
>>those 'platform-specific' things?  It would seem to follow the Ada
>>philosophy of maximal safety; after all, if pieces of configuration
>>control are required to be part of the linker, why not define an 'Ada
>>windows' interface (for example) and then require compilers for
>>platforms with window support to map their functionality onto the
>>interface? 

This is a nice idea, and is certainly a reasonable sort of thing to put 
in a future annex. However, your example turns out to be a rather
difficult case, because "windows" is an area with much diversity,
and reaching consensus on a common interface that would nicely map
to (say) Mac, Windows, OS/2 PM, and X, without resulting in a
too-low common denominator, would be very hard. If you think it
would be feasible, how 'bout if you take a crack at specifying it.

>   In principle, I agree. Much of this lies at the feet of the compiler 
>   vendors, who have chosen not to go beyond simple validation with some
>   of their products.  And validation requires nothing more than the bare
>   essentials of the language.  I provides no guarantee that the compiler
>   will be useful for real work.  

Well, in this case we can lay at the vendors' feet that they never
got together on a quasi-standard X binding. There are, unfortunately,
_several_ X bindings, mostly vendor-specific.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
         Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------

Re: Is C/C++ the future? (LONG LONG POST)

[Greg Harvey]

Hi all!  Thought I'd drop by with thoughts for the day.


riehler@ajpo.sei.cmu.edu (Richard Riehle) writes:


>>>In article <383q62$k0v@truffula.fp.trw.com> Brad Brahms,
>>>brad@truffula.fp.trw.com writes:
>BB>>>...  I have yet to see any large Ada project finish without
>BB>>>some other language, usually in the form of C-bindings, to help! ...

>This is probably a fair characterization of many early Ada projects.  One of
>early complaints was that Ada compiler vendors would provide a validated
>compiler with no platform-specific support packages.  It became the chore of
>the compiler user to build such packages, often necessitating the use of
>pragma interface to C or assembler.  Sometimes we even had to use the
>machine code package, if the compiler vendor were generous enough to include
>it.  

>This is not a language problem.  It is an incomplete compiler problem...

Well...not precisely.  Let's get specific (other posters have already, so I'm
going to summarize).  To build a successful executable you need the following:

1.  A language specification

2.  A compiler that matches and implements that specification (exactly, if
possible.  ;)

3.  A set of tools that combines the compiler output into a machine-specific
executable (for discussion purposes we'll call this 'linking' though it
must be smarter and more extensive than the thing called LINK.EXE that 
MicroSloth gives away for free.)

4.  An additional set of tools that help you manage the job in general.
Cross reference, CASE, version and configuration control all fall in this
category.

5.  A development platform, preferably with either intepretation or compilation
and execution of your target source code.  The ability to execute code on
your development platform is nice but not essential.  Note that compiling for
the development platform may require a SEPARATE compiler and linker from
that required for the target.

6.  Development libraries which contain all the previously developed code
which you wish to reuse in any way shape or form.  These libraries tend to
include (for Ada at least) both Unix/MS-DOS-style object libraries as well as
the hunkier and better developed Ada library concept.  The more of these
libraries that are written in Ada and include the original Ada source code,
the better.  The higher level the routines you call or the more architecture
dependent they are, the less likely they will be implemented/emulated/work on
a development platform that is distinct from your target.  (Rational taught
Space Station this the hard way.)  Note that BOTH development and target-
executable versions of libraries are necessary if their architecture differs.

7.  A delivery mechanism to install completed executables on the target.

8.  Some amount of debugging support that is used to initiate execution and
provide dynamic and static pathological examination. 

9.  Some mechanism for productizing and loading the completed product onto
the final hardware device.


Wshew...sorry about that, but it is important to put it all down in one
place.  Most people forget some or all of these details.  Now, how does
Ada rate?

1.  Language--Top notch.  Both 83 and 9x have lots of winning features.
Neither is object-oriented in the sense that Smalltalk is object-oriented (or
Simula, for that matter).  9X is object-oriented in the sense that C++ is
(and then some).  9X isn't really Ada++ either.  The reinventors acted more
through sensible evolution than through destruction and redefinition.  The
language is the first to move some concepts such as tasking into the compiler,
so some implementations on general purpose operating systems lose.

2.  Compilers--Mixed bag.  None are wholeheartedly terrific because Ada was
one of the first languages to require quantum leaps (sorry...I promised myself
I wouldn't do that) in compiler technology.  Others have been more like black
holes of compiler technology.  Most compiler problems are not related to the
ability to implement the language.  Most are NOT due to language incompleteness
(which has a lot to do with the linear algebraic concept of spanning the
problem space.)  Most compiler problems trace to difficulty in implementing
advanced computing concepts on relatively unadvanced hardware/os.  Many
compiler problems have stemmed from trying to do the cheap job rather than
the right job.  Many other problems have stemmed from incompatible and non-
portable interpretations of language features that all 'pass' ACVC.  The
ACVC has proven itself a filter of limited, but necessary, capability
vis a vis testing Ada implementations.   If anyone would like to hear about
my experience putting together a Postscript 'ACVC' and what it did and didn't
do for us, please feel free to drop me a line.

3.  Binding/linking tools--Another mixed bag.  For some implementations vendors
rely on commonly available tools such as 'ld' in Unixen.  For others, the
top of the line link technology for the target environment was made available.
(Well, I've always had a great deal of respect for tools like Plink-86
anyway...others have bemoaned being forced to use them.)  For most platforms,
linking technology ain't what it could be, but it ain't the Ada vendors fault.
(Or is it...after all, Ada really does require quantum leaps in compiler
technology, and this IS a related issue.) 

4.  General support tools--compared to each other, not bad.  Compared to the
ever exploding C/C++ development environment...Pfffffttttt.  Now, lest some
say:  "Well, but Ada doesn't have the market penetration of C/C++."  I
point you to ParcPlace VisualWorks 2.0.  'Nuff said and OUCH!

5.  Development platforms--Ok except for one thing:  although this isn't
strictly speaking JUST an Ada vendor issue, we gotta deal with it
fair-handedly:  Ada vendors seem to go out of their way to provide runtimes
with differing features.  This is likely to get worse with 9X annexability.
Heaven help you if you want your Alsys Apollo-Domain runtime to do what your
Vax-to-386sx runtime does.  What...you'd even like to be able to install,
activate, and deactivate extensions to the runtime?  FORSOOTH!

6.  Development libraries and target support of development libraries--
this area is poor, still, but not all the blame belongs to the vendors.
Today, too many call specifications are written in C.  This is bad for
three reasons:  C is a poor call specification language because it assumes
the interaction between the callee (a program, presumably written in C) and
the caller.  It is also a poor call specification language because its
syntax leads to very low levels of call abstraction.  Finally, it is a
very poor call specification language because both the reader and the
implementor tend to ignore semantic and state issues across the interface
since C is strictly functional.  The best example of this is the creation of
the FILE* holder for Unix I/O calls.  File holds all the state and must be
handed to each call and then kept sacrosanct by the user between calls
(more pfffffttttt.)  Besides it being simply a poor call specification
language, it is very difficult to translate the very low level C concepts
into higher level languages without providing a very poor call abstraction
(in addition to the very poor one you get because you specified in C in the
first place.)

Folks, this is going to take some aggressive behavior.  In short, join those
standards committees and vote NO to C-based call specifications.  Then
join both the committees that do the C reference spec and the committees
that do the Ada reference spec.  Try to get them to do BOTH specs in the
same book.  Teach all those C-knowledgeable standards committee members
that thinking in C breaks everyone else (including their C++ compatriots.)

7.  Delivery mechanism to target--Not bad in most cases.  Usually the goal
is an operating system-specific executable.  In the cases of embedded
processors the goal is a loader/load image or an absolute image.  Usually
the link vendors rescue the compiler vendors.  Not always. :)

8.  Debugging--As before...most Ada vendors look pretty good until you
compare them with the C/C++ market, particulary on the DOS/Windows side.

9.  Productizing approaches--Usually stops at step 7 above.  There is usually
miniscule support for versioning, installation, or any of a host of other
installation issues.  Luckily, itz usually no worse than what the operating
system provides standard.

Sorry about the long post.

Greg Harvey (harvey@blkbox.com)

Re: Is C/C++ the future?

[Carlos Perez]

AdaWorks (adaworks@netcom.com) wrote:
:    The article is excerpted from the "Unix Hater's Handbook," published
:    at MIT.  It is exceptionally uncomplimentary of C++.  In fact, the
:    tone is reminiscent of that found in some early anti-Ada tracts. 

I read the article and I agree somewhat.  I have heard lots of whining about
Ada generics (substitute C++ templates today).  But I have never heard
of Ada being called "object oriented assembly language".  Nor has Ada
lacked a formal grammar (is it really true that C++ lacks a formal 
grammar?).  Strong typing-- yup, I have heard lots of complaining here.
Most programmers who hate strong typing don't really understand how to
use types in the first place and struggle with it as much as dentist's
drill -- its a great tool for the experienced but seems to create a
bloody mess in the wrong hands.

Anyways, the article is a hoot and worth the comic relief. 

-- Carlos Perez (pardon me, but your memory is leaking ;-)

Re: Is C/C++ the future?

[Dag Bruck]

>>>>> "MF" == Michael Feldman <mfeldman@seas.gwu.edu> writes:

MF> I wasn't really thinking of cases like this, rather of situations
MF> where programmers in industry _know_ they are writing plain C and
MF> passing it off as C++.

Maybe this characterization isn't entirely fair.

When converting an organization from C to C++, the conservative
approach is to gradually introduce C++ features, starting by just
updating the C code so it compiles with a C++ compiler.  When that is
done, classes, overloading, inheritance, etc. is introduced.

The point is that during this transition phase they will not use the
full power of C++, and that is probably wise.

You could also argue that an application that doesn't use tasking is
not _really_ written in Ada :-).

					-- Dag Bruck

Re: Is C/C++ the future?

[Michael Feldman]

In article <DAG.94Nov2083525@bellman.control.lth.se>,
Dag Bruck <dag@control.lth.se> wrote:
>>>>>> "MF" == Michael Feldman <mfeldman@seas.gwu.edu> writes:
>
>MF> I wasn't really thinking of cases like this, rather of situations
>MF> where programmers in industry _know_ they are writing plain C and
>MF> passing it off as C++.
>
>Maybe this characterization isn't entirely fair.

Of course it's not. It was meant mostly as an ironic joke.

>When converting an organization from C to C++, the conservative
>approach is to gradually introduce C++ features, starting by just
>updating the C code so it compiles with a C++ compiler.  When that is
>done, classes, overloading, inheritance, etc. is introduced.
>
>The point is that during this transition phase they will not use the
>full power of C++, and that is probably wise.

If, in fact, everyone is being that honest with one another, sure.
I have seen cases, though, where it was all too easy to con a manager
that C++ was being used, when in fact _none_ of the power of C++
was being used, only a C++ compiler.

'Course that manager also thought the language was called C+. (no :-))

Mike Feldman

Re: Is C/C++ the future?

[Bill Janssen]

In article <1994Oct30.210203.1863@muvms6> hathawa2@muvms6.wvnet.edu (Mark S. Hathaway) writes:

   Isn't the problem of libraries one of major importance these days?  Every
   language has it's own libraries and they're not compatible and some are
   so closely attached to an operating system that they're not very portable
   and...<argh>

   Once you've got a good procedural language like Pascal, Modula-2, Ada, C,
   etc. there should be an extension of that utility by having better
   reusability across languages.

Libraries, IMHO, should be written and documented as ILU "true"
modules.  ILU provides an interface specification technology
specifically designed to eliminate the differences between API's (in
terms of data normalization, resource management strategies, error
handling policy, etc.) exported by different languages (or even
different designers of class libraries in a single language).

   Then, what set of functions/procedures/classes/etc. would constitute
   completeness?

See the ILU spec,
ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/manual-html/manual_1.html.

For sources and usage information, see
ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html.

Bill
--
 Bill Janssen  <janssen@parc.xerox.com> (415) 812-4763  FAX: (415) 812-4777
 Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA  94304
 URL:  ftp://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html

Re: Is C/C++ the future?

[David Emery]

The concept of a 'single interface to all window systems' is
appealing.  There are several commercial products that do this for C,
and at least one, XVT, is considering an Ada binding.  (XVT covers
MS-Windows, MOTIF, vanilla X Windows, Character terminals, MacOS and
some others that I forget right now. POC at XVT is Sue Smith, 303
545-3108).

The IEEE chartered a group (IEEE P1201.1) to do this, but the group
was unable to come to consensus.

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Is C/C++ the future? (LONG LONG POST)

[David Emery]

>In short, join those standards committees and vote NO to C-based call
>specifications.  Then join both the committees that do the C reference
>spec and the committees that do the Ada reference spec.  Try to get
>them to do BOTH specs in the same book.  Teach all those
>C-knowledgeable standards committee members that thinking in C breaks
>everyone else (including their C++ compatriots.)

It's not productive to vote NO for C bindings.  After all, C
programmers have to make a living, too.  NO votes should be based on
technical considerations, not language biases.  We don't like it when
people do it to Ada bindings, so we shouldn't do this for other
languages.  

But I completely agree with the rest of this.  There are plenty of
opportunities for developing standard Ada bindings.  The POSIX/Ada
group, IEEE P1003.5, needs people interested in working on the
following list of potential projects:
	MOTIF (IEEE 1295) and Ada
	Ada Real-Time (IEEE 1003.4a/1003.4b)
	Ada development interface (IEEE 1003.2 for Ada)
	Additions to the System Call Interface (IEEE 1003.1b)
	Protocol Independent Networking (IEEE 1003.8)
	Other networking (e.g. Sockets) (IEEE 1003.12)
	  and many more

For more information, contact Jim Longers, IEEE PASC Chair,
lonjers@planet8.sp.paramax.com, or myself.

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Is C/C++ the future? (LONG LONG POST)

[Nathan Hand]

I thought Paradox was the future?

After all, it does have objects. <snigger>

Re: Is C/C++ the future? (LONG LONG POST)

[Vince Risi]

In article <39mq1q$92o@manuel.anu.edu.au>,
Nathan Hand <h9304891@student.anu.edu.au> wrote:
> I thought Paradox was the future?
>
> After all, it does have objects. <snigger>

Don't snigger, the way things are going it looks like Visual Basic is
the future.

Vince
=====

Re: Is C/C++ the future?

[(No Name)]

Vince Risi posted:
Nathan Hand <h9304891@student.anu.edu.au> wrote:
> I thought Paradox was the future?
>
> After all, it does have objects. <snigger>

Don't snigger, the way things are going it looks like Visual Basic is
the future.

Vince
=====

I don't know about the future BUT Lotus Notes is _NOW_!

Programmers are being flown across the country to perform
their tasks.  They are charging $1000/day.  A certified
Notes developer organization is said to have said
"Your company must pay $5000.00 as step 1, then you will
become a registered company and then we will begin
analysis".

Notes user level certification can occur after a
two week school.

Reminds me of Ada in the mid 80's.

sam harbaugh HARBAUGH@ROO.FIT.EDU