comp.lang.ada
 help / color / mirror / Atom feed
* Limitations of Ada
@ 1996-07-19  0:00 The Quelisher
  1996-07-20  0:00 ` Michael Feldman
                   ` (3 more replies)
  0 siblings, 4 replies; 31+ messages in thread
From: The Quelisher @ 1996-07-19  0:00 UTC (permalink / raw)



With all this discussion about programming different things ins Ada, I 
got to thinking......Just what are the limitations of the language? I 
mean, is it versitile enough to program a Windows program then turn right 
back around and make a kernel?

Just letting curiosity get the better of me...
-- 
#-----------------------------------------------------------------#
| _                                                   __    __    |
| \\                                                  \ \  / /    |
|  \\        GO                                     __ \ \/ / __  |
|   \\   TALLAHASSEE          * 1971 Karmann Ghia * \ \ \  / / /  |
|    \\  TIGERSHARKS!               * Coupe *        \ \/  \/ /   |
|     \\____                                          \  /\  /    |
|      \_XXX)                                          \/  \/     |
|                                                                 |
|       Live Long and Quelish!....................Kendal          |
#-----------------------------------------------------------------#




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-19  0:00 Limitations of Ada The Quelisher
@ 1996-07-20  0:00 ` Michael Feldman
  1996-07-21  0:00 ` Nasser Abbasi
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 31+ messages in thread
From: Michael Feldman @ 1996-07-20  0:00 UTC (permalink / raw)



In article <31EF79A3.812@freenet.scri.fsu.edu>,
The Quelisher  <kendal@freenet.scri.fsu.edu> wrote:
>With all this discussion about programming different things ins Ada, I 
>got to thinking......Just what are the limitations of the language? I 
>mean, is it versitile enough to program a Windows program then turn right 
>back around and make a kernel?

Yes. It's as versatile as any other language; it is general-purpose.
I often wonder why anyone would think otherwise?

>Just letting curiosity get the better of me...

Why not satisfy that curiosity by giving it a try?

Mike Feldman




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-19  0:00 Limitations of Ada The Quelisher
  1996-07-20  0:00 ` Michael Feldman
@ 1996-07-21  0:00 ` Nasser Abbasi
  1996-07-23  0:00   ` Bob Munck
  1996-07-22  0:00 ` Klaus Wyss
  1996-07-30  0:00 ` Theodore E. Dennison
  3 siblings, 1 reply; 31+ messages in thread
From: Nasser Abbasi @ 1996-07-21  0:00 UTC (permalink / raw)




   >From: The Quelisher <kendal@freenet.scri.fsu.edu>

   >With all this discussion about programming different things ins Ada, I 
   >got to thinking......Just what are the limitations of the language? I 
   >mean, is it versitile enough to program a Windows program then turn right 
   >back around and make a kernel?

   >Just letting curiosity get the better of me...



Ada has no known limitations.

bye,
Nasser
-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application 
for Nucleic acid and protein sequence search and analysis. 
Perkin Elmer - Applied BioSystem division. email:  nasser@apldbio.com   
MSEE(control), MSCS, MSCE, FM (Fide Chess Master).







^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-19  0:00 Limitations of Ada The Quelisher
  1996-07-20  0:00 ` Michael Feldman
  1996-07-21  0:00 ` Nasser Abbasi
@ 1996-07-22  0:00 ` Klaus Wyss
  1996-07-23  0:00   ` Robert Dewar
  1996-07-30  0:00 ` Theodore E. Dennison
  3 siblings, 1 reply; 31+ messages in thread
From: Klaus Wyss @ 1996-07-22  0:00 UTC (permalink / raw)



The Quelisher wrote:
> 
> With all this discussion about programming different things ins Ada, I
> got to thinking......Just what are the limitations of the language? I
> mean, is it versitile enough to program a Windows program then turn right
> back around and make a kernel?
> 
> Just letting curiosity get the better of me...
> --

There are no limitations, as long as you stay in the in the nice clean
ADA world.
If you go to the real dirty computer world, with all the C libraries
(Windows,X11,DCE, DB access .... ) you get a lot of limitations.
For example if your ADA is not based on pthreads you run into problems
with DCE. 

Klaus Wyss
UBS Switzerland




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-22  0:00 ` Klaus Wyss
@ 1996-07-23  0:00   ` Robert Dewar
  1996-07-24  0:00     ` David Emery
  0 siblings, 1 reply; 31+ messages in thread
From: Robert Dewar @ 1996-07-23  0:00 UTC (permalink / raw)



Klaus says

"There are no limitations, as long as you stay in the in the nice clean
ADA world.
If you go to the real dirty computer world, with all the C libraries
(Windows,X11,DCE, DB access .... ) you get a lot of limitations.
For example if your ADA is not based on pthreads you run into problems
with DCE."


Well of course if you are going to interface to the outside world, you
must make sure that your Ada compiler has the appropriate capabilities.
For example, if you want to interface to C, make sure that the systems
programming annex is supported.

Similarly, it is quite true that if you want to interface to an outside
threads package, then this has implications on the runtime. The statement
above is not quite correct, since DCE uses DCE threads, which are not
compatible with Pthreads (I assume Pthreads means Posix threads), since
they are based on Draft 4, rather than the final version (which was 
draft 10). However, the differences are small.

GNAT uses the DCE threads interface on a number of different machines, and
even on a machine where it uses pthreads (e.g. SGI Irix), it would be
quite easy to build a version based on DCE threads is this were a
requirement.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-21  0:00 ` Nasser Abbasi
@ 1996-07-23  0:00   ` Bob Munck
  1996-07-24  0:00     ` David Kristola
                       ` (2 more replies)
  0 siblings, 3 replies; 31+ messages in thread
From: Bob Munck @ 1996-07-23  0:00 UTC (permalink / raw)



>From: The Quelisher <kendal@freenet.scri.fsu.edu>
>With all this discussion about programming different things ins Ada, I
>got to thinking......Just what are the limitations of the language? 
> 

Ada is unable to exceed the speed of light.




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-23  0:00   ` Bob Munck
@ 1996-07-24  0:00     ` David Kristola
  1996-07-24  0:00       ` Ron Thompson
  1996-07-25  0:00     ` Limitations of Ada Keith Thompson
  1996-07-29  0:00     ` David Weller
  2 siblings, 1 reply; 31+ messages in thread
From: David Kristola @ 1996-07-24  0:00 UTC (permalink / raw)



In article 6EBF@acm.org, Bob Munck <munck@acm.org> () writes:
>>From: The Quelisher <kendal@freenet.scri.fsu.edu>
>>With all this discussion about programming different things ins Ada, I
>>got to thinking......Just what are the limitations of the language? 
>> 
>
>Ada is unable to exceed the speed of light.

I have been unable to write Ada code that reads a user's mind.

david kristola
Work: davidk@os1.ese.lmsc.lockheed.com
Play: DJKristola@aol.com

My suggestion for Lockheed Martin's next slogan:
"Lockheed Martin, we make things that go BOOM!"





^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-24  0:00     ` David Kristola
@ 1996-07-24  0:00       ` Ron Thompson
  1996-07-26  0:00         ` Ken Garlington
  0 siblings, 1 reply; 31+ messages in thread
From: Ron Thompson @ 1996-07-24  0:00 UTC (permalink / raw)



davidk@OS2.ifs (David Kristola) wrote:

>
>My suggestion for Lockheed Martin's next slogan:
>"Lockheed Martin, we make things that go BOOM!"
>

Yeah, I snipped all the other about C/C++/Ada, Ada
limitations, Java vs Freeze_Dried, etc. The suggestion
above is what is REALLY important in any discussion
of real time embedded old crap that MOST of us have to
support. At least around here anyway.

That, David, is an excellent suggestion. There was a list
floating around a couple of months ago that outlined some
really good ones for the slogan du jour. Try to get yours
on it! A good laugh here that was. LM probably laughed too.

rct
The opinions above are mine and mine alone.






^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-23  0:00   ` Robert Dewar
@ 1996-07-24  0:00     ` David Emery
  0 siblings, 0 replies; 31+ messages in thread
From: David Emery @ 1996-07-24  0:00 UTC (permalink / raw)



...
>, since
> [DCE threads] are based on Draft 4, rather than the final version (which was 
> draft 10). However, the differences are small.
> 

Not THAT small, particularly for an Ada RTS!

            dave




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-23  0:00   ` Bob Munck
  1996-07-24  0:00     ` David Kristola
@ 1996-07-25  0:00     ` Keith Thompson
  1996-07-29  0:00     ` David Weller
  2 siblings, 0 replies; 31+ messages in thread
From: Keith Thompson @ 1996-07-25  0:00 UTC (permalink / raw)



In <31F54DE2.6EBF@acm.org> Bob Munck <munck@acm.org> writes:
> >From: The Quelisher <kendal@freenet.scri.fsu.edu>
> >With all this discussion about programming different things ins Ada, I
> >got to thinking......Just what are the limitations of the language? 
> > 
> 
> Ada is unable to exceed the speed of light.

Why must people continue to spread the myth that Ada is inherently slower
than C?

8-)}

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
"As the most participatory form of mass speech yet developed, the Internet
deserves the highest protection from government intrusion." -- ACLU v. Reno




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-24  0:00       ` Ron Thompson
@ 1996-07-26  0:00         ` Ken Garlington
  1996-07-29  0:00           ` Byron B. Kauffman
  0 siblings, 1 reply; 31+ messages in thread
From: Ken Garlington @ 1996-07-26  0:00 UTC (permalink / raw)



Ron Thompson wrote:
> 
> davidk@OS2.ifs (David Kristola) wrote:
> 
> >My suggestion for Lockheed Martin's next slogan:
> >"Lockheed Martin, we make things that go BOOM!"
> 
> That, David, is an excellent suggestion.

Of course, for us LM types that build flight control systems,
we might prefer:

"Lockheed Martin, we make things that make _other_ things go BOOM!"

since, when _our_ systems go BOOM, this is considered a Bad Thing :)

-- 
LMTAS - "Our Brand Means Quality"




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-23  0:00   ` Bob Munck
  1996-07-24  0:00     ` David Kristola
  1996-07-25  0:00     ` Limitations of Ada Keith Thompson
@ 1996-07-29  0:00     ` David Weller
  2 siblings, 0 replies; 31+ messages in thread
From: David Weller @ 1996-07-29  0:00 UTC (permalink / raw)



In article <31F54DE2.6EBF@acm.org>, Bob Munck  <munck@acm.org> wrote:
>Ada is unable to exceed the speed of light.

Rumor has it that IBM is working on a practical solution to this by
redefining 'c' :-)  (A dual pun if there ever was :-)
-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-26  0:00         ` Ken Garlington
@ 1996-07-29  0:00           ` Byron B. Kauffman
  1996-07-30  0:00             ` Things that go BOOM (was Re: Limitations of Ada) David Kristola
  0 siblings, 1 reply; 31+ messages in thread
From: Byron B. Kauffman @ 1996-07-29  0:00 UTC (permalink / raw)



Ken Garlington wrote:
> 
> Ron Thompson wrote:
> >
> > davidk@OS2.ifs (David Kristola) wrote:
> >
> > >My suggestion for Lockheed Martin's next slogan:
> > >"Lockheed Martin, we make things that go BOOM!"
> >
> > That, David, is an excellent suggestion.
> 
> Of course, for us LM types that build flight control systems,
> we might prefer:
> 
> "Lockheed Martin, we make things that make _other_ things go BOOM!"
> 
> since, when _our_ systems go BOOM, this is considered a Bad Thing :)
> 
> --
> LMTAS - "Our Brand Means Quality"


Hey, whattaya expect from an ex A-12 avionics guy?

Byron Kauffman
LMTAS - "We Do Falcons Right"




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
@ 1996-07-29  0:00 Marin David Condic, 407.796.8997, M/S 731-93
  1996-07-30  0:00 ` Kazimir Majorinc
  0 siblings, 1 reply; 31+ messages in thread
From: Marin David Condic, 407.796.8997, M/S 731-93 @ 1996-07-29  0:00 UTC (permalink / raw)



David Weller <dweller@DFW.NET> writes:
>In article <31F54DE2.6EBF@acm.org>, Bob Munck  <munck@acm.org> wrote:
>>Ada is unable to exceed the speed of light.
>
>Rumor has it that IBM is working on a practical solution to this by
>redefining 'c' :-)  (A dual pun if there ever was :-)
>
    But have you heard of IBMs new ultra-super-computer? It's supposed
    to be so fast that it will execute an infinite loop in three
    minutes.

    186,000 mi/sec. It's not just a good idea... It's the law!

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Government is not reason. It is not eloquence. It is a force.
    Like fire, a dangerous servant and a fearful master."

        --  George Washington
===============================================================================




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-19  0:00 Limitations of Ada The Quelisher
                   ` (2 preceding siblings ...)
  1996-07-22  0:00 ` Klaus Wyss
@ 1996-07-30  0:00 ` Theodore E. Dennison
  3 siblings, 0 replies; 31+ messages in thread
From: Theodore E. Dennison @ 1996-07-30  0:00 UTC (permalink / raw)



The Quelisher wrote:
> 
> With all this discussion about programming different things ins Ada, I
> got to thinking......Just what are the limitations of the language? I
> mean, is it versitile enough to program a Windows program then turn right
> back around and make a kernel?

My understanding is that BLISS is required to code a VMS device driver. 
That's the only "Can't" that I ever came across.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Things that go BOOM (was Re: Limitations of Ada)
  1996-07-29  0:00           ` Byron B. Kauffman
@ 1996-07-30  0:00             ` David Kristola
  1996-07-31  0:00               ` Theodore E. Dennison
  0 siblings, 1 reply; 31+ messages in thread
From: David Kristola @ 1996-07-30  0:00 UTC (permalink / raw)



Just to set the record straight, i am currently working on a missile program
(hopefully, it will go BOOM when and where it is supposed to).

Ken Garlington wrote:
> Of course, for us LM types that build flight control systems,
> we might prefer:
> 
> "Lockheed Martin, we make things that make _other_ things go BOOM!"

That too.

> Byron Kauffman
> LMTAS - "We Do Falcons Right"

An F-16 can make a nice sonic BOOM.

david kristola
Work: davidk@os1.ese.lmsc.lockheed.com
Play: DJKristola@aol.com

My *revised* suggestion for Lockheed Martin's next slogan:
"Lockheed Martin, we make things that go BOOM!, whoosh, ping, wherrrr, pop, shhhh,
hummm (not necessarily the same thing, or at the same time)."





^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-30  0:00 ` Kazimir Majorinc
  1996-07-30  0:00   ` Brian Rogoff
@ 1996-07-30  0:00   ` Robert Dewar
  1996-07-31  0:00   ` Robert A Duff
                     ` (4 subsequent siblings)
  6 siblings, 0 replies; 31+ messages in thread
From: Robert Dewar @ 1996-07-30  0:00 UTC (permalink / raw)



Kazimir commented on alledged limitations of Ada

1) Not 100 % OO, see Smalltalk

    Shrug, this is more of a religeous comment than a technical one!

2) Without distributed objects, see Modula-3

    This is wrong, read annex E

3) Lack of MACROS, see C++

    This is an intentional part of the design, see Steelman

4) Small number of operators to overload, see  C++

    Incomprehensible, all operators and subprograms are overloadable in Ada

5) Lack of multiple inheritance, see C++

    Not necessarily a lack at all, see Tucker Taft's paper

6) Big language, see BASIC

    More of a comment, than a limitation. After all you could equally say
    that it is a limitation of BASIC that it is a small language.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-30  0:00 ` Kazimir Majorinc
@ 1996-07-30  0:00   ` Brian Rogoff
  1996-07-30  0:00   ` Robert Dewar
                     ` (5 subsequent siblings)
  6 siblings, 0 replies; 31+ messages in thread
From: Brian Rogoff @ 1996-07-30  0:00 UTC (permalink / raw)



kmajor@jagor.srce.hr (Kazimir Majorinc) writes:

   Hello everybody!

Hi!

   This are limitations of Ada:

   1) Not 100 % OO, see Smalltalk

Not a limitation. Ada allows you to write code at a lower level than 
Smalltalk. I see this as a feature, Ada 95 is a multiparadigm language.

   2) Without distributed objects, see Modula-3

A distributed object system could be written in Ada. See also the Distributed 
Systems Annex of Ada 95.

   3) Lack of MACROS, see C++

I'm sympathetic, since I know real (Lisp, not C++) macros are powerful, but 
I found reading Common Lisp macro code pretty painful. Maybe the pain subsides 
after a lot of reading, but I understand the argument in favor of readability 
here. Besides, you can always write a macro language for Ada if you really 
want. There is just no "standard" one.

   4) Small number of operators to overload, see  C++

Agreed. But where do you stop? Do you allow user defined operators? I suppose 
I would like to be able to create user defined arrays that behaved just like 
built-ins.

   5) Lack of multiple inheritance, see C++

Show me a problem which requires MI and can't be solved fairly easily in 
Ada 95. There are quite a few online papers describing what you can do.

   6) Big language, see BASIC

Is that a limitation?

-- Brian





^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-29  0:00 Marin David Condic, 407.796.8997, M/S 731-93
@ 1996-07-30  0:00 ` Kazimir Majorinc
  1996-07-30  0:00   ` Brian Rogoff
                     ` (6 more replies)
  0 siblings, 7 replies; 31+ messages in thread
From: Kazimir Majorinc @ 1996-07-30  0:00 UTC (permalink / raw)



Hello everybody!

This are limitations of Ada:

1) Not 100 % OO, see Smalltalk
2) Without distributed objects, see Modula-3
3) Lack of MACROS, see C++
4) Small number of operators to overload, see  C++
5) Lack of multiple inheritance, see C++
6) Big language, see BASIC

But, I love her more than C++ although I did wrote only 'hello world'
in Ada. 

________________________________________________
Author:         Kazimir Majorinc, 
Education:      dipl. ing. mathematics           
Address:        Vinagorska 7,                       
                10 000 Zagreb,                      
                Croatia.                           
Work:           prof. math. & comp.sci.              
                XIII. Gimnazija, Zagreb, Croatia
E-mail address: Kazimir.Majorinc@public.srce.hr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
One who know the secret of the seventh stair





^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Things that go BOOM (was Re: Limitations of Ada)
  1996-07-30  0:00             ` Things that go BOOM (was Re: Limitations of Ada) David Kristola
@ 1996-07-31  0:00               ` Theodore E. Dennison
  1996-08-12  0:00                 ` Ken Garlington
  0 siblings, 1 reply; 31+ messages in thread
From: Theodore E. Dennison @ 1996-07-31  0:00 UTC (permalink / raw)



David Kristola wrote:
> 
> Just to set the record straight, i am currently working on a missile program
> (hopefully, it will go BOOM when and where it is supposed to).
> 
> Ken Garlington wrote:
> > Of course, for us LM types that build flight control systems,
> > we might prefer:
> >
> > "Lockheed Martin, we make things that make _other_ things go BOOM!"
> 
> That too.
> 
> > Byron Kauffman
> > LMTAS - "We Do Falcons Right"
> 
> An F-16 can make a nice sonic BOOM.
> 
> david kristola
> Work: davidk@os1.ese.lmsc.lockheed.com
> Play: DJKristola@aol.com
> 
> My *revised* suggestion for Lockheed Martin's next slogan:
> "Lockheed Martin, we make things that go BOOM!, whoosh, ping, wherrrr, pop, shhhh,
> hummm (not necessarily the same thing, or at the same time)."

Well, our engine control/sensor monitoring/actuator controlling software should
neither go BOOM, nor make anything else go BOOM (unless you count the combustion
chamber inside the engine).

Additionally, the folks across the aisle from me in simulations just make things
LOOK like they went BOOM.

..here to help.
-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-30  0:00 ` Kazimir Majorinc
                     ` (3 preceding siblings ...)
  1996-07-31  0:00   ` Fraser Wilson
@ 1996-07-31  0:00   ` Brian Rogoff
  1996-08-01  0:00   ` Spasmo
  1996-08-01  0:00   ` Bob Kitzberger
  6 siblings, 0 replies; 31+ messages in thread
From: Brian Rogoff @ 1996-07-31  0:00 UTC (permalink / raw)



dewar@cs.nyu.edu (Robert Dewar) writes:
   Kazimir commented on alledged limitations of Ada

   4) Small number of operators to overload, see  C++

       Incomprehensible, all operators and subprograms are overloadable in Ada

I expect that what Kazimir meant was something like 

   4) Small number of binary infix (and unary prefix ) operators whose 
      meanings can be assigned by the user.

Overloading is an orthogonal issue; note that Eiffel 3 allows one to define 
brand new infix operators, but does not have overloading. 

This is a legitimate complaint. I have wanted additional operators for image 
processing operations. However, it is not really a "limitation", just a 
tiny syntactic inconvenience. I assume the same reasoning that led to the 
ban on macros (readability and potential for abuse) led to this decision.

-- Brian




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-30  0:00 ` Kazimir Majorinc
                     ` (2 preceding siblings ...)
  1996-07-31  0:00   ` Robert A Duff
@ 1996-07-31  0:00   ` Fraser Wilson
  1996-07-31  0:00   ` Brian Rogoff
                     ` (2 subsequent siblings)
  6 siblings, 0 replies; 31+ messages in thread
From: Fraser Wilson @ 1996-07-31  0:00 UTC (permalink / raw)



kmajor@jagor.srce.hr (Kazimir Majorinc) writes:

>This are limitations of Ada:

As Douglas Adams would say, this is obviously some new use of the
word "limitation" that I haven't been previously aware of. :-)

>1) Not 100 % OO, see Smalltalk

That's good, because OO isn't appropriate for everything.

>2) Without distributed objects, see Modula-3

Depending on your definition of distributed objects, Annexe E is
probably what you're looking for.

>3) Lack of MACROS, see C++

Lack of macros is known as a Good Thing.

>4) Small number of operators to overload, see  C++

Also known as a Good Thing.

>5) Lack of multiple inheritance, see C++

Does this mean that multiple inheritance in C++ is the One True Way?
There's different ways of doing MI, and it's not clear which flavour
is best.  Under such conditions, it seems that leaving it out of the
standard was a good decision.

>6) Big language, see BASIC

So is C++.  In fact, the C++ standard is bigger than the Ada standard.
However, Ada is very good at letting you take only the bits you need.

>But, I love her more than C++ although I did wrote only 'hello world'
>in Ada. 

It's a good start.  And she is fabulous :-)

Fraser.
--
    ____ Fraser Wilson          | email: fraser@cs.mu.oz.au     __o
    \  / The more I learn of    | voice: +61 3 9287 9193      _-\<,_
     \/  C++, the more I like   | fax:   +61 3 9348 1184     (_)/ (_)
           --- Ada 95 ---       | www:   http://www.cs.mu.oz.au/~fraser/




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-30  0:00 ` Kazimir Majorinc
  1996-07-30  0:00   ` Brian Rogoff
  1996-07-30  0:00   ` Robert Dewar
@ 1996-07-31  0:00   ` Robert A Duff
  1996-07-31  0:00   ` Fraser Wilson
                     ` (3 subsequent siblings)
  6 siblings, 0 replies; 31+ messages in thread
From: Robert A Duff @ 1996-07-31  0:00 UTC (permalink / raw)



In article <4tlpfa$cr9@bagan.srce.hr>,
Kazimir Majorinc <kmajor@jagor.srce.hr> wrote:
>This are limitations of Ada:
>...
>2) Without distributed objects, see Modula-3

Ada has this.  See E.4.2.

- Bob




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-30  0:00 ` Kazimir Majorinc
                     ` (5 preceding siblings ...)
  1996-08-01  0:00   ` Spasmo
@ 1996-08-01  0:00   ` Bob Kitzberger
  1996-08-02  0:00     ` Jack W Scheible
  6 siblings, 1 reply; 31+ messages in thread
From: Bob Kitzberger @ 1996-08-01  0:00 UTC (permalink / raw)



Kazimir Majorinc (kmajor@jagor.srce.hr) wrote:

: This are limitations of Ada:
: 3) Lack of MACROS, see C++

That's a feature.



--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-07-30  0:00 ` Kazimir Majorinc
                     ` (4 preceding siblings ...)
  1996-07-31  0:00   ` Brian Rogoff
@ 1996-08-01  0:00   ` Spasmo
  1996-08-08  0:00     ` mpost
  1996-08-01  0:00   ` Bob Kitzberger
  6 siblings, 1 reply; 31+ messages in thread
From: Spasmo @ 1996-08-01  0:00 UTC (permalink / raw)



Kazimir Majorinc (kmajor@jagor.srce.hr) wrote:
: Hello everybody!

: This are limitations of Ada:

: 1) Not 100 % OO, see Smalltalk

Why is this a limitation?  Not being 100% OO is not a limitation,
it's a design decision.  You can use OO in Ada or you can choose
not to, this to me is a superior choice to being forced to use
OO in a 100% OO language like Smalltalk.


: 2) Without distributed objects, see Modula-3

Not quite sure what you mean by this.  


: 3) Lack of MACROS, see C++

That's an advantage.  If you notice in C++ one of the first
things they tell you when you get to inlining functions is
"Now you don't have to use macros!".  Since macros are
textual substitution you can really mess things up in a
big way.  Arguments to function like macros aren't evaluated
which can lead to innaccurate results (this is a famous
problem of macros, therefore the ugly notation where
everything is fully parenthesized in an attempt to
combat this deficency), and since macros are just
pure textual substitution you can do some very strange
things with them that can send readability out the
window.  You can assemble functions to be called that
won't be seen until preprocessing time, you can have
really wacked out notation, etc...  C can keep its
macros, I couldn't care less about them.  I've
done fine without them in other languages and I
have no doubt I will continue to do well without
them in the future.


: 4) Small number of operators to overload, see  C++

This is a two pronged situation.  On the one hand you've
got a ton of C++ operators which are really useful for
saving typing and obfusicating code (something C and C++
are famous for), but in all reality they don't do anything
new.  ie: ++, --, +=, etc... are just shorthand and
can be accomplished by the standard operators +, and -.
I was about to get on a tangent about C++ and how the
way it treats operators plays havoc with generic functions
(requiring ugly hacks and kludges) but I won't :)


: 5) Lack of multiple inheritance, see C++

There are those who would say this is an advantage.  Even in C++
folks recommend that if you use multiple inheritance, you do so
very sparingly and if I'm not mistaken there was serious consideration
as to whether or not include this "feature" since many say it does
more harm than good.  


: 6) Big language, see BASIC

Even if it is, so what?  As long as a language is easy to use, 
powerful, and helps me produce better programs, I couldn't
care less about the size.


: But, I love her more than C++ although I did wrote only 'hello world'
: in Ada. 

I've done more, and while I'm still an Ada newbie, I can say that
this is one sweet language.  The more I look at Ada, the more I
look down on C and C++.



: ________________________________________________
: Author:         Kazimir Majorinc, 
: Education:      dipl. ing. mathematics           
: Address:        Vinagorska 7,                       
:                 10 000 Zagreb,                      
:                 Croatia.                           
: Work:           prof. math. & comp.sci.              
:                 XIII. Gimnazija, Zagreb, Croatia
: E-mail address: Kazimir.Majorinc@public.srce.hr
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: One who know the secret of the seventh stair


--
Spasmo
"Everyone has secrets, but sometimes you get caught,
 So if it's just between us, my silence can be bought"
	"Blackmail" by Sloppy Seconds





^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-08-02  0:00     ` Jack W Scheible
@ 1996-08-02  0:00       ` Robert Dewar
  1996-08-03  0:00       ` Keith Thompson
  1 sibling, 0 replies; 31+ messages in thread
From: Robert Dewar @ 1996-08-02  0:00 UTC (permalink / raw)



Jack said

"There is no reason at all that the C pre-processor cannot be
run on Ada source before sending it to the compiler.  Therefore,
one _can_ use macros, but it is neither standard nor advisable -
macros can be a source of very hard-to-find bugs."

Actually there is one reason: attributes will cause troubles, since they
don't look like valid C tokens.

But largely this is true, and in any case, other macro processors can be
used.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-08-01  0:00   ` Bob Kitzberger
@ 1996-08-02  0:00     ` Jack W Scheible
  1996-08-02  0:00       ` Robert Dewar
  1996-08-03  0:00       ` Keith Thompson
  0 siblings, 2 replies; 31+ messages in thread
From: Jack W Scheible @ 1996-08-02  0:00 UTC (permalink / raw)



In article <4tr86p$fvd@rational.rational.com> rlk@rational.com (Bob Kitzberger) writes:
>Kazimir Majorinc (kmajor@jagor.srce.hr) wrote:
>
>: This are limitations of Ada:
>: 3) Lack of MACROS, see C++
>
>That's a feature.
>
There is no reason at all that the C pre-processor cannot be
run on Ada source before sending it to the compiler.  Therefore,
one _can_ use macros, but it is neither standard nor advisable - 
macros can be a source of very hard-to-find bugs.

-jack




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-08-02  0:00     ` Jack W Scheible
  1996-08-02  0:00       ` Robert Dewar
@ 1996-08-03  0:00       ` Keith Thompson
  1996-08-05  0:00         ` Jack W Scheible
  1 sibling, 1 reply; 31+ messages in thread
From: Keith Thompson @ 1996-08-03  0:00 UTC (permalink / raw)



In <4tsvs7$ctk@portal.gmu.edu> jscheibl@mason2.gmu.edu (Jack W Scheible) writes:
> There is no reason at all that the C pre-processor cannot be
> run on Ada source before sending it to the compiler.  Therefore,
> one _can_ use macros, but it is neither standard nor advisable - 
> macros can be a source of very hard-to-find bugs.

Actually, there is a reason.  The C preprocessor chokes on some Ada
constructs.  The ISO C standard requires the input to the preprocessing
phase to be a valid token stream.  I don't remember the exact details,
but one consequence is that an apostrophe that's not part of a character
literal (e.g., in an Ada attribute) is illegal.

Here's an example:

package Foo is
#ifdef FIRST
   X : Integer := Integer'First;
#else
   X : Integer := Integer'Last;
#endif
end Foo;

The "cc -E" command under Solaris complains:

"foo.ads", line 5: invalid input token: 'Last;

Of course, there's nothing in the ISO C standard that requires the
preprocessor to exist as a separate program, or "cc -E" to behave in any
particular fashion.  Similarly, there's nothing preventing someone from
implementing a C-like preprocessor with fewer restrictions.  However,
using the C preprocessor on Ada code is likely to cause problems, as
the example above shows.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
"As the most participatory form of mass speech yet developed, the Internet
deserves the highest protection from government intrusion." -- ACLU v. Reno




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-08-03  0:00       ` Keith Thompson
@ 1996-08-05  0:00         ` Jack W Scheible
  0 siblings, 0 replies; 31+ messages in thread
From: Jack W Scheible @ 1996-08-05  0:00 UTC (permalink / raw)



In article <DvJyKB.9DC@thomsoft.com> kst@thomsoft.com (Keith Thompson) writes:
>In <4tsvs7$ctk@portal.gmu.edu> jscheibl@mason2.gmu.edu (Jack W Scheible) writes:
>> There is no reason at all that the C pre-processor cannot be
>> run on Ada source before sending it to the compiler.  Therefore,
>> one _can_ use macros, but it is neither standard nor advisable - 
>> macros can be a source of very hard-to-find bugs.
>
>Actually, there is a reason.  The C preprocessor chokes on some Ada
>constructs.  The ISO C standard requires the input to the preprocessing
>phase to be a valid token stream.  I don't remember the exact details,
>but one consequence is that an apostrophe that's not part of a character
>literal (e.g., in an Ada attribute) is illegal.
>
>Here's an example:
>
>package Foo is
>#ifdef FIRST
>   X : Integer := Integer'First;
>#else
>   X : Integer := Integer'Last;
>#endif
>end Foo;
>
>The "cc -E" command under Solaris complains:
>
>"foo.ads", line 5: invalid input token: 'Last;
>

The above code works just fine with the command "cpp -P" under Solaris.
It is _still_ a bad idea.

-jack




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Limitations of Ada
  1996-08-01  0:00   ` Spasmo
@ 1996-08-08  0:00     ` mpost
  0 siblings, 0 replies; 31+ messages in thread
From: mpost @ 1996-08-08  0:00 UTC (permalink / raw)



Spasmo (cosc19z5@Bayou.UH.EDU) wrote:
: Kazimir Majorinc (kmajor@jagor.srce.hr) wrote:
: : 5) Lack of multiple inheritance, see C++
: 
: There are those who would say this is an advantage.  Even in C++
: folks recommend that if you use multiple inheritance, you do so
: very sparingly and if I'm not mistaken there was serious consideration
: as to whether or not include this "feature" since many say it does
: more harm than good.  

Just a side note, I've been watching this thread as an interested student 
of computer science who knows C++ but currently has an internship with a 
DoD contractor doing Ada coding.  As far as MI goes, you're invited to 
check out a paper I wrote for my OOP class which discusses MI.  I found 
it to be an interesting topics and I welcome comments both on the subject 
and the paper.  The paper can be found on my homepage at 
http://w3.gwis.com/~mpost.

Mike




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Things that go BOOM (was Re: Limitations of Ada)
  1996-07-31  0:00               ` Theodore E. Dennison
@ 1996-08-12  0:00                 ` Ken Garlington
  0 siblings, 0 replies; 31+ messages in thread
From: Ken Garlington @ 1996-08-12  0:00 UTC (permalink / raw)



Theodore E. Dennison wrote:
> 
> Well, our engine control/sensor monitoring/actuator controlling software should
> neither go BOOM, nor make anything else go BOOM (unless you count the combustion
> chamber inside the engine).

Unless of course, your software is used in a weapon system that makes other things
go BOOM (like my software)!

> ..here to help.





^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~1996-08-12  0:00 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-07-19  0:00 Limitations of Ada The Quelisher
1996-07-20  0:00 ` Michael Feldman
1996-07-21  0:00 ` Nasser Abbasi
1996-07-23  0:00   ` Bob Munck
1996-07-24  0:00     ` David Kristola
1996-07-24  0:00       ` Ron Thompson
1996-07-26  0:00         ` Ken Garlington
1996-07-29  0:00           ` Byron B. Kauffman
1996-07-30  0:00             ` Things that go BOOM (was Re: Limitations of Ada) David Kristola
1996-07-31  0:00               ` Theodore E. Dennison
1996-08-12  0:00                 ` Ken Garlington
1996-07-25  0:00     ` Limitations of Ada Keith Thompson
1996-07-29  0:00     ` David Weller
1996-07-22  0:00 ` Klaus Wyss
1996-07-23  0:00   ` Robert Dewar
1996-07-24  0:00     ` David Emery
1996-07-30  0:00 ` Theodore E. Dennison
  -- strict thread matches above, loose matches on Subject: below --
1996-07-29  0:00 Marin David Condic, 407.796.8997, M/S 731-93
1996-07-30  0:00 ` Kazimir Majorinc
1996-07-30  0:00   ` Brian Rogoff
1996-07-30  0:00   ` Robert Dewar
1996-07-31  0:00   ` Robert A Duff
1996-07-31  0:00   ` Fraser Wilson
1996-07-31  0:00   ` Brian Rogoff
1996-08-01  0:00   ` Spasmo
1996-08-08  0:00     ` mpost
1996-08-01  0:00   ` Bob Kitzberger
1996-08-02  0:00     ` Jack W Scheible
1996-08-02  0:00       ` Robert Dewar
1996-08-03  0:00       ` Keith Thompson
1996-08-05  0:00         ` Jack W Scheible

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox