RE: an interested business-oriented programmer

RE: an interested business-oriented programmer

[Beard, Frank]

-----Original Message-----
From: Gary Scott [mailto:Gary.L.Scott@lmtas.lmco.com]

> Hi,
> So why doesn't someone put together a "Visual Ada" product integrated
> with Visual Studio and mass market it?  They did it for Fortran...

That's what Aonix ObjectAda is, but I think for the past year or more
the marketing has become somewhat deficient.

There was a product called VisualAda, that pretty much went away,
but again I have forgotten who is maintaining the product.

>> Marin David Condic wrote:
> 
> 
> MSVC++ provides for all intents and
> purposes, its own version of C++. Using the whole of it, you won't build
> portable code - especially as you use the MFC. No portability, but boy can
> you get at all the nooks & crannies of Windows all from a nicely
integrated
> development environment.

Well, unfortunately, there is a company that advertises they've
ported the MFC to Unix.  I can't remember the name at the
moment, since I gave the flyer to a C++ co-worker who left about
six or eight months ago.  And since I wasn't interested, I don't
know how much of the MFC they ported.  I don't know if it would 
include any of the GUI support.

I've seen similar Ada products.  You build your GUI on Unix, then
re-compile and link with libraries on your Windows environment to
have the equivalent Windows GUI.

Frank

Re: an interested business-oriented programmer

[James Rogers]

"Beard, Frank" wrote:
> 
> -----Original Message-----
> From: Gary Scott [mailto:Gary.L.Scott@lmtas.lmco.com]
> 
> > Hi,
> > So why doesn't someone put together a "Visual Ada" product integrated
> > with Visual Studio and mass market it?  They did it for Fortran...
> 
> That's what Aonix ObjectAda is, but I think for the past year or more
> the marketing has become somewhat deficient.

About two years ago I was helping an experienced Visual C++
developer use the Aonix ObjectAda tools. He recognized the Aonix
interface as being a rather old version of Visual Studio. He really
liked using Visual Studio. His answer was to make a few 
customizations of the Visual Studio configuration files, allowing
the current version to fully support development using ObjectAda.

To his amazement, the standard Visual Studio debugger worked better
on ObjectAda than it did on Visual C++. He saw more detailed 
information about arrays, collections (records in Ada, classes in C++),
and better dereferencing of Ada access types than C++ pointers and
references.

He immediately appreciated Ada. He also liked the matrix manipulation
packages he found and downloaded to help him produce Kalman filters.

Jim Rogers
Colorado Springs, Colorado USA

Re: an interested business-oriented programmer

[Ed Falis]

James Rogers wrote:

> "Beard, Frank" wrote:
> >
> > -----Original Message-----
> > From: Gary Scott [mailto:Gary.L.Scott@lmtas.lmco.com]
> >
> > > Hi,
> > > So why doesn't someone put together a "Visual Ada" product integrated
> > > with Visual Studio and mass market it?  They did it for Fortran...
> >
> > That's what Aonix ObjectAda is, but I think for the past year or more
> > the marketing has become somewhat deficient.
>
> About two years ago I was helping an experienced Visual C++
> developer use the Aonix ObjectAda tools. He recognized the Aonix
> interface as being a rather old version of Visual Studio. He really
> liked using Visual Studio. His answer was to make a few
> customizations of the Visual Studio configuration files, allowing
> the current version to fully support development using ObjectAda.
>
> To his amazement, the standard Visual Studio debugger worked better
> on ObjectAda than it did on Visual C++. He saw more detailed
> information about arrays, collections (records in Ada, classes in C++),
> and better dereferencing of Ada access types than C++ pointers and
> references.
>
> He immediately appreciated Ada. He also liked the matrix manipulation
> packages he found and downloaded to help him produce Kalman filters.
>
> Jim Rogers
> Colorado Springs, Colorado USA

Yep, and it was even better with Phar Lap's plugin for ETS - registers,
I/O space, interrupt controller and thread state.  Oh my.  When Dave Wood
was driving the product management for ObjectAda for windows, he really was
reaching for a Visual Ada.  MS wasn't all that interested in an Ada plugin,
which was one of the approaches considered.   So, Dave's team (myself
included) did a major overhaul for OA 7.2.  The result wasn't too bad,
though I always found the GUI builder a bit weak and annoying.  David
Botton's GNATCOM stuff is a lot stronger in many ways.  But what can I say -
I work for ACT now ;-)

- Ed

Re: an interested business-oriented programmer

[Al Christians]

But, if we are talking about business-oriented programming, 
does Aonix implement interfaces.COBOL and Annex F ("information
systems", which includes decimal data)?

The competition is COBOL and/or either Java or C++ with a decimal
numbers class library.

Al

James Rogers wrote:
> 
> "Beard, Frank" wrote:
> >
> > -----Original Message-----
> > From: Gary Scott [mailto:Gary.L.Scott@lmtas.lmco.com]
> >
> > > Hi,
> > > So why doesn't someone put together a "Visual Ada" product integrated
> > > with Visual Studio and mass market it?  They did it for Fortran...
> >
> > That's what Aonix ObjectAda is, but I think for the past year or more
> > the marketing has become somewhat deficient.
> 
> About two years ago I was helping an experienced Visual C++
> developer use the Aonix ObjectAda tools. He recognized the Aonix
> interface as being a rather old version of Visual Studio. He really
> liked using Visual Studio. His answer was to make a few
> customizations of the Visual Studio configuration files, allowing
> the current version to fully support development using ObjectAda.
> 
> To his amazement, the standard Visual Studio debugger worked better
> on ObjectAda than it did on Visual C++. He saw more detailed
> information about arrays, collections (records in Ada, classes in C++),
> and better dereferencing of Ada access types than C++ pointers and
> references.
> 
> He immediately appreciated Ada. He also liked the matrix manipulation
> packages he found and downloaded to help him produce Kalman filters.
> 
> Jim Rogers
> Colorado Springs, Colorado USA

Re: an interested business-oriented programmer

[James Rogers]

Al Christians wrote:
> 
> But, if we are talking about business-oriented programming,
> does Aonix implement interfaces.COBOL and Annex F ("information
> systems", which includes decimal data)?
> 
> The competition is COBOL and/or either Java or C++ with a decimal
> numbers class library.
> 

I do not have the answer to that. I was using ObjectAda on the
PharLap ETS operating system for robotic controls. 

How much of an interface to COBOL will you get with Java or
C++? The only language interface defined for either of those
languages is C. Even without some Annex F, Ada supports business
applications better than C++ or Java. What kind of fixed point
numbers are defined as part of either language? (Does the answer
"none" come to mind?)

Let's talk a little about execution efficiency too. C++ and Ada
implementations exhibit similar execution efficienies, but both
still dramatically beat Java. I know a lot of effort has been
spent to improve the efficiency of Java Virtual Machines.
Improvements have been made. Parity has not been achieved. Even
more important is the fact that most common Java programming
idioms are terribly inefficient. For instance, editing each character
in a 1024 character Java string will require 2 Megabytes of
memory, and involve the creation and garbage collection of 1024
strings. The way around this is to convert the Java String object
to a Java StringBuffer object, perform all the edits, then convert
the StringBuffer object to another String object, requiring only
about 6 Kilobytes of memory and the creation ( and garbage
collection ) of three objects. This is clearly faster than the
use of only Java Strings, but also slower than editing an Ada 
string.

I do not see how C++ and Java can be considered close to Ada's
capabilities in the Business arena. C++ lacks Ada's numeric types
as well as any ability to interface with COBOL. Java mirrors
C++'s deficiencies topped off with a nasty dose of inefficiency.

COBOL is still a highly respectable language for business systems.
COBOL is optimized for large scale transaction processing
applications. The biggest problem facing COBOL is its aging
workforce. Few people are learning COBOL. Some companies are feeling
forced to develop solutions in other languages just so that they
can easily hire developers and maintainers for their code. With
that attitude, those employers are often going to choose the current
fad language rather than make a strict technical decision.

Another sad fact is that most employers looking to replace
COBOL have never heard of Ada. 

Jim Rogers
Colorado Springs, Colorado USA

Re: an interested business-oriented programmer

[Marin David Condic]

Annex F is "normative" which, if I understand correctly, means its basically
a requirement for validation. (I'll probably get hit over the head for
that!) I'd suspect that all conforming implementations would have it if they
are targeted to a general-purpose computer. You wouldn't much need it if you
were running on an embedded machine - unless maybe it was a
bank-teller-machine?

As for interfacing to Cobol - I doubt that would be a major concern for
someone who is looking to develop new systems for workstation/PC level
products. There isn't exactly tons of need to interface to Cobol code in
such an environment. If you were using Ada on a mainframe (is there an Ada
implementation for a mainframe that is still in use?) with all sorts of
legacy Cobol code, you might want that - but I don't see thousands of posts
here asking those kinds of questions, so I suspect most vendors wouldn't
support it. I wouldn't consider that a drawback for most business software
development.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <alc@PublicPropertySoftware.com> wrote in message
news:3B1F09F8.A6521EEF@PublicPropertySoftware.com...
> But, if we are talking about business-oriented programming,
> does Aonix implement interfaces.COBOL and Annex F ("information
> systems", which includes decimal data)?
>
> The competition is COBOL and/or either Java or C++ with a decimal
> numbers class library.
>
> Al
>
> James Rogers wrote:
> >
> > "Beard, Frank" wrote:
> > >
> > > -----Original Message-----
> > > From: Gary Scott [mailto:Gary.L.Scott@lmtas.lmco.com]
> > >
> > > > Hi,
> > > > So why doesn't someone put together a "Visual Ada" product
integrated
> > > > with Visual Studio and mass market it?  They did it for Fortran...
> > >
> > > That's what Aonix ObjectAda is, but I think for the past year or more
> > > the marketing has become somewhat deficient.
> >
> > About two years ago I was helping an experienced Visual C++
> > developer use the Aonix ObjectAda tools. He recognized the Aonix
> > interface as being a rather old version of Visual Studio. He really
> > liked using Visual Studio. His answer was to make a few
> > customizations of the Visual Studio configuration files, allowing
> > the current version to fully support development using ObjectAda.
> >
> > To his amazement, the standard Visual Studio debugger worked better
> > on ObjectAda than it did on Visual C++. He saw more detailed
> > information about arrays, collections (records in Ada, classes in C++),
> > and better dereferencing of Ada access types than C++ pointers and
> > references.
> >
> > He immediately appreciated Ada. He also liked the matrix manipulation
> > packages he found and downloaded to help him produce Kalman filters.
> >
> > Jim Rogers
> > Colorado Springs, Colorado USA

Re: an interested business-oriented programmer

[Stanley R. Allen]

Marin David Condic wrote:
> 
> Annex F is "normative" which, if I understand correctly, means its basically
> a requirement for validation. (I'll probably get hit over the head for
> that!) I'd suspect that all conforming implementations would have it if they
> are targeted to a general-purpose computer. You wouldn't much need it if you
> were running on an embedded machine - unless maybe it was a
> bank-teller-machine?
> 

"Normative" in this context means that it provides a norm
(standard) -- it does not mean that the validation of a
compiler is dependent on implementing the annex.  It means
that if a compiler creator DOES provide Annex F, that the
validation of that annex must meet the standard's definition
in order for Annex F to be so noted in the validation.

Other annexes (K, L, & M for example) are "informative" --
they don't provide extra 'normative' requirements beyond what
was given elsewhere in the standard.

Q.V. RM95 1.1.2
(http://www.ada-auth.org/~acats/arm-html/RM-1-1-2.html)

-- 
Stanley Allen
mailto:Stanley_R_Allen-NR@raytheon.com

Re: an interested business-oriented programmer

[Marin David Condic]

Thanks for the clarification. If I understand correctly, you are saying the
normative annexes have to pass validation *if* an implementation claims to
support them.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Stanley R. Allen" <u384k@gsde.hou.us.ray.com> wrote in message
news:3B1F9173.C7D51A74@gsde.hou.us.ray.com...
> "Normative" in this context means that it provides a norm
> (standard) -- it does not mean that the validation of a
> compiler is dependent on implementing the annex.  It means
> that if a compiler creator DOES provide Annex F, that the
> validation of that annex must meet the standard's definition
> in order for Annex F to be so noted in the validation.
>
> Other annexes (K, L, & M for example) are "informative" --
> they don't provide extra 'normative' requirements beyond what
> was given elsewhere in the standard.
>

Ada on mainframes (Was: an interested business-oriented programmer)

[Jacob Sparre Andersen]

Marin:

> (is there an Ada implementation for a mainframe that is still in use?)

I haven't managed to get GNAT to work on an IBM S/390, but it should be
possible. GCC already works with the C front end[1].

Jacob

1) There is a catch - it is on Linux/390, not on OS/390.
-- 
"simply because no one had discovered a cure for the universe as a
 whole - or rather the only one that did exist had been abolished"

Re: Ada on mainframes (Was: an interested business-oriented programmer)

[Gary Scott]

Hi, I think that SAS? still provides an Ada compiler for VM.

Jacob Sparre Andersen wrote:
> 
> Marin:
> 
> > (is there an Ada implementation for a mainframe that is still in use?)
> 
> I haven't managed to get GNAT to work on an IBM S/390, but it should be
> possible. GCC already works with the C front end[1].
> 
> Jacob
> 
> 1) There is a catch - it is on Linux/390, not on OS/390.
> --
> "simply because no one had discovered a cure for the universe as a
>  whole - or rather the only one that did exist had been abolished"

Re: Ada on mainframes (Was: an interested business-oriented programmer)

[Larry Kilgallen]

In article <3B20A1C4.C1B19E1E@nbi.dk>, Jacob Sparre Andersen <sparre@nbi.dk> writes:
> Marin:
> 
>> (is there an Ada implementation for a mainframe that is still in use?)
> 
> I haven't managed to get GNAT to work on an IBM S/390, but it should be
> possible. GCC already works with the C front end[1].

OC Systems sells LegacyAda (83) for MVS.

Re: an interested business-oriented programmer

[Robert A Duff]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> Annex F is "normative" which, if I understand correctly, means its basically
> a requirement for validation. (I'll probably get hit over the head for
> that!)

Or at least politely corrected.  ;-)

Annex F is one of the "optional" annexes.  An implementation can conform
to the Ada standard, and in addition, it can conform to one or more of
the optional annexes.  The optional annexes are listed in the
Introduction:

   51  The Specialized Needs Annexes have been added to provide specific
       support for certain application areas:

          52  Annex C, ``Systems Programming''

          53  Annex D, ``Real-Time Systems''

          54  Annex E, ``Distributed Systems''

          55  Annex F, ``Information Systems''

          56  Annex G, ``Numerics''

          57  Annex H, ``Safety and Security''

>... I'd suspect that all conforming implementations would have it if they
> are targeted to a general-purpose computer. You wouldn't much need it if you
> were running on an embedded machine - unless maybe it was a
> bank-teller-machine?

That's why it's optional.  Real-time systems often don't need Annex F.
Business software often doesn't need real-time stuff.

> As for interfacing to Cobol - I doubt that would be a major concern for
> someone who is looking to develop new systems for workstation/PC level
> products. There isn't exactly tons of need to interface to Cobol code in
> such an environment.

I'm not sure that's true.  Also, there is a need to interface to COBOL
*data*, in addition to programs.

- Bob

Re: an interested business-oriented programmer

[Marin David Condic]

Well, this is one of those quantitative judgements on which reasonable men
can differ. How "big" is the need to interface to Cobol from Ada? What
constitutes "big"? If one considers all code written in all languages, for
all platforms, every day, the amount that has to interface to Cobol is
probably percentage-wise pretty small. If you're the guy who has to write an
Ada program to utilize some legacy Cobol code and get it done yesterday, the
need for interfacing to Cobol is probably only slightly less important than
the need for Oxygen to exist on the planet. Need and importance can be
relative to the observer.

I understand the need to interface to Cobol data as it may exist in numerous
historic and/or active databases. However, that could probably be done
without resorting to Ada's Cobol interface. Typically you'd have some sort
of record description that you could (worst case) read/write as raw bytes
and provide a translation to/from an internal Ada format. In many cases, it
could probably be handled by a rep clause. Perhaps the special needs annex
offers some help that makes life easier, but an Ada vendor would want to
weigh the number of customers that would find this a requirement vs the cost
of implementation. If they don't see much demand for it, (or even potential
demand) they might choose to opt-out in order to concentrate on more
pressing concerns.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wcchexpiosj.fsf@world.std.com...
> "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> > As for interfacing to Cobol - I doubt that would be a major concern for
> > someone who is looking to develop new systems for workstation/PC level
> > products. There isn't exactly tons of need to interface to Cobol code in
> > such an environment.
>
> I'm not sure that's true.  Also, there is a need to interface to COBOL
> *data*, in addition to programs.
>
> - Bob