Re: Ada - State of the art tools... lacking

Re: Ada - State of the art tools... lacking

[Robert Dewar]

SteveD says

<<Neither system makes it through a build on the first attempt.  Both
ObjectAda and GNAT complain about errors in individual source files.  In
both systems I compile the files with errors individually and then rebuild
and then they suceed.
>>

If both GNAT and ObjectAda agree that something peculiar is going on with
some of your files, it is most likely pilot error on your part, or a
misunderstanding of some crucial Ada 95 issue (e.g. disappearence of
optional packages). You might want to give some details here!

Re: Ada - State of the art tools... lacking

[Jon S Anthony]

"Jon Jensen" <jon.jensen@hci.utah.edu> writes:

> 
> Did you look at using Delphi?  Were there specific reasons you didn't use
> it?  It seems like from you message it would have been a much better fit
> than Object Ada.

How can you tell?  Suppose portability is an issue.  Once it is in
Ada95, it will run basically anywhere (quite possibly with little or
no change).  OTOH, if NT is all they will ever want, maybe you're
right.

-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Ada - State of the art tools... lacking

[Robert Dewar]

Jon said

<<Did you look at using Delphi?  Were there specific reasons you didn't use
it?  It seems like from you message it would have been a much better fit
than Object Ada.
>>

Perhaps he preferred to use a standardized language, or perhaps he simply
preferred Ada over Pascal, especially over a vendor specific non-standard
extension to Pascal :-)

Re: Ada - State of the art tools... lacking

[Steved]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.882990051@merv>...
> Jon said
> 
> <<Did you look at using Delphi?  Were there specific reasons you didn't
use
> it?  It seems like from you message it would have been a much better fit
> than Object Ada.
> >>
> 
> Perhaps he preferred to use a standardized language, or perhaps he simply
> preferred Ada over Pascal, especially over a vendor specific non-standard
> extension to Pascal :-)
> 
> 
Exactly.  Going with a single vendor solution can cause severe long term
problems that don't arise with a standard language that is supported by
multiple vendors (yes optimistic).  If we wrote our code for Delphi, there
is no reason to think that Borland won't make major changes to the language
next year that breaks our system.  If something happens with ObjectAda we
can move our source code to GNAT.  If something happens with GNAT we can
move our source code to DDC-I (when they finish their NT Ada 95 product). 
If something happens to DDC-I we can move to Green Hills... and so on.

Oh, and I think the development tools will mellow with age, but right now
I'm just frustrated.

SteveD

Re: Ada - State of the art tools... lacking

[Paul Whittington]

> ... Exactly.  Going with a single vendor solution can cause severe long term
> problems that don't arise with a standard language that is supported by
> multiple vendors (yes optimistic).

Trust me, experience has shown that unless you vigilantly make sure that
yoursource code compiles and executes properly on all potential
compilers/platforms you'll not realize this dream.  It turns out that although
Ada is by far the best language for developing large and complex systems for
multiple platforms do so is FAR FROM AUTOMATIC.  Things to watch out for are
compiler/platform specific pragmas, representation clauses (legal boundries and

element sizes), and various and sundry semantic interpretation differences.


> If we wrote our code for Delphi, there
> is no reason to think that Borland won't make major changes to the language
> next year that breaks our system.

Oh I think there is!  How about 600,000 or more loyal users that depend on this

kind ofthing not happening, and the $24,000,000.00 ($39.99*600,000) in revenue
that this represents to Borland.  I've used TurboPASCAL since 1.0 and Borland
has NEVER done anything even close to what your talking about here.  They would

have to be completely stupid to even consider it!  I think that Delphi is hands

down the best way to develop Windows software, period.  The only thing that
would make it better is if it used Ada instead of ObjectPascal.

What we've done is built our systems using a Model-View-Controller type of
architecture that allows us to implement our long-term, potentially platform
mobile, code in Ada, and use Delphi to get access to easy-to-use user interface

components or very platform specific stuff.  By doing so we can both get a
state-of-the-art product out the door fast, and make a reasonably intelligent
investment in code for the future.

>  If something happens with ObjectAda we
> can move our source code to GNAT.  If something happens with GNAT we can
> move our source code to DDC-I (when they finish their NT Ada 95 product).
> If something happens to DDC-I we can move to Green Hills... and so on.
>
> Oh, and I think the development tools will mellow with age, but right now
> I'm just frustrated.
>
> SteveD

--
Paul Whittington
Whittington Engineering
260 South Woodruff Avenue
Suite 201
Idaho Falls, ID 83401
paul@srv.net

Re: Ada - State of the art tools... lacking

[Michael F Brenner]

   > ... although Ada is by far the best language for developing large 
   > and complex systems for multiple platforms do so is FAR FROM 
   > AUTOMATIC.  Things to watch out for are compiler/platform 
   > specific pragmas, representation clauses (legal boundries and
   > element sizes), and various and sundry semantic interpretation 
   > differences.

If anyone is making a list of things to watch out for, the following
have bitten me this year: 

(1) differences in system.storage_size,

(2) differences in ordinary operating system functions such as
    renaming files, getting directory lists, getting the current
    tick of the clock, accessing virtual versus absolute memory,
    how to set the environmental variables, how to spawn an
    Ada program as a separate operating system process, etc.

(3) differences in the way you address different disk drives and
    specifically the lack of ability to use URLs to address 
    different disk drives the way IE and Netscape and Mosaic do,

(4) differences in the way you access the exact unparsed command line
    from which the user invoked yourself,

(5) differences in the way you convert a machine address into
    an integer type,
   
(6) differences in the way interrupts are handled: how to enable or
    disable interrupts, how to read or set interrupt vectors,  
    how to go into supervisor (root, protected, etc.) mode,
    how to do a callback, how to put a wrapper around a function
    that will be called by an interrupt handler, how to chain
    interrupts, how to attach an Ada interrupt handler to an
    interrupt number, how to restore the previous interrupt 
    handler, how to tickle a port,

(7) differences in the way you extract bytes from integers, 
    for example, if you wish to get the third byte (the 
    byte next to the high-order byte) of a four-byte integer,

(8) differences in the way assertions are implemented as a 
    procedure or an optional pragma,

(9) differences in whether code is generated for unchecked
    conversion in each given case (i.e. when code is generated
    the procedure has to be rewritten a different way to 
    avoid making the extra copy of large data structures),

(10) whether things exist like long_float,

(11) gross differences in the way stream_io works on various 
    current implementations of gnat with regard to whether 
    extra carriage returns or line feeds are generated, 
    how to determine end of a binary file, how to connect
    to pipelines in DOS and Unix, and how to use the built-in
    random access in stream_io to actually do random access
    on your piped input file.

(12) whether one can link a package or a procedure in a package
     as the main program versus just being able to link a
     library level procedure as a main program,

(13) availability of the annexes.

Mike Brenner mikeb@mitre.org 

Re: Ada - State of the art tools... lacking

[Jean-Pierre Rosen]

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


Paul Whittington a �crit dans le message <34A74195.46994669@srv.net>...
>> If we wrote our code for Delphi, there
>> is no reason to think that Borland won't make major changes to the
language
>> next year that breaks our system.
>
>[...]
>  I've used TurboPASCAL since 1.0 and Borland
>has NEVER done anything even close to what your talking about here.
Seems you forgot the move from version 3 to version 4.
I still have an old version 3 on my computer because of an old application
that I never took the time to convert (would have involved a major
rewriting).

Re: Ada - State of the art tools... lacking

[Paul Whittington]

Ok I give :)  You're exactly correct!  One big change in, what is it, 15
years; not bad.
Some of the changes from Ada 83 to Ada 95 also broke programs, and that's one
big change in 12 or so years.  About the same record.

My point is that Borland is not likely to change ObjectPascal in any
significant way
very ofter.

TTFN Paul


Jean-Pierre Rosen wrote:

> Paul Whittington a �crit dans le message <34A74195.46994669@srv.net>...
> >> If we wrote our code for Delphi, there
> >> is no reason to think that Borland won't make major changes to the
> language
> >> next year that breaks our system.
> >
> >[...]
> >  I've used TurboPASCAL since 1.0 and Borland
> >has NEVER done anything even close to what your talking about here.
> Seems you forgot the move from version 3 to version 4.
> I still have an old version 3 on my computer because of an old application
> that I never took the time to convert (would have involved a major
> rewriting).



--
Paul Whittington
Whittington Engineering
260 South Woodruff Avenue
Suite 201
Idaho Falls, ID 83401
paul@srv.net