Re: Borland Ada

Re: Borland Ada

[Jean D. Ichbiah]

In article <3ianqv$ghb@Starbase.NeoSoft.COM> dweller@Starbase.NeoSoft.COM (David Weller) writes:


>>4) Does it use the OWL meta-windowing objects?

>No (thank goodness!)

I really do not understand your answer on this point (did
I miss some  smiley?).  Have you used OWL? I have. And as
most OWL users, consider this to be the minimum level required
to program Windows.

Anything below this level (that is, the 800 or so API functions) is
like programming in assembly language.  Please  do not spread 
this kind of misinformation.  It is too bad for Ada that the industry
has not developed this kind of abstraction layer allowing you to
program WIndows efficiently in Ada.  By efficiently, I mean efficiently
in terms of the time you  invest in programming (as well as efficiently
in the old-fashioned sense).

Ada has a future only if a bridge to faster development tools and
frameworks (such as OWL) can be established.  Without this kind
of bridge, Ada will not be cost-effective for developing Windows
applications.  If Ada ends up not being a cost-effective  way to 
develop, how will anyone be able to continue supporting Ada?

Object Pascal may be a lesser language than Ada, but with the Delphi 
environment, its tools, and its components, developing applications in
it will be much more cost-effective than with current Ada environment
(my past association with Alsys prevent me from commenting  on ActivAda).

It is very  important to start looking at ways to bridge Ada with Delphi.

Jean D. Ichbiah

Ada in Client/Server (was: Borland Ada)

[Howard.Gilbert]

In <ichbiah.239.2F4C00CF@jdi.tiac.net>, ichbiah@jdi.tiac.net (Jean D. Ichbiah) writes:
>
>Ada has a future only if a bridge to faster development tools and
>frameworks (such as OWL) can be established.  Without this kind
>of bridge, Ada will not be cost-effective for developing Windows
>applications.  If Ada ends up not being a cost-effective  way to 
>develop, how will anyone be able to continue supporting Ada?
>
Although many people talk about Client/Server, they usually
only consider the hardware.  IBM's SAA was the worst example,
an entire architecture based on the assumption that people would
program the same languages and interfaces on PC's and mainframes.
One of the advantages of C/S is that you can choose technologies
at each level in the hierarchy.

Ada may be a wonderful language, but it is unlikely that anyone
will invest the amount of effort needed to build the surrounding
infrastructure of development environment, GUI interface, database
interface, case tools, and all the rest.  Even with the investment,
it is simply not true that Ada will ever compete head-on with 
Visual Basic.  So maybe the Client isn't the best place to 
concentrate effort ("Programming in the Small").

On the other hand, Clients need a Server.  Server code can be
complex logic, multi-tasking, mission-critical, performance 
sensitive, and all the other stuff for which Ada was designed.
The Server doesn't generally need a GUI binding.  What it does need,
however, is access to the Interface.

Support for the DCE environment and remote procedure calls is 
probably the highest priority.  Then, in some order, one needs 
Sockets (general TCP/IP), CPIC (IBM mainframe and AS/400 
communication and transaction processing), maybe named pipes.

In the older PC operating systems, it might have been necessary to 
run everything in one module in one language.  However, with OS/2 
and WIN32 an application can be componsed of separate 
processes linked by Interprocess Communication.  Leave the front-end
to lightweight modules written using high-productivity, 
low-reliability languages.  Write the backend in languages that 
encourage reliability.

Old Ada discouraged communication between languages.  The DOD 
100%-Ada mandate seemed to justify this design, but it simply left 
the decision as "all or nothing" and that really meant 0%.  Ada 95 
is much more flexible in its approach.

I am not suggesting that Ada should never get an interface to 
building "pulldown combo boxes,"  but I would suggest that the 
effort be placed first in pipes, sockets, RPC, SOM, and CORBA.
Play to the language strengths.  In particular, the current language
of choice appears to be C, but that language was specified for the 
Unix environment and has serious shortcomings running multithreaded.
Putting C++ on top of C doesn't fix the original structural 
deficiencies.  Since Server code is almost necessarily 
multithreaded, a language orignally designed to synchronize 
concurrent access to storage by multiple tasks has a clear 
advantage.  Ada has no special advantage when deciding if the Window
title should be in Times Roman or Perpetua Bold.

 ---------------
Howard Gilbert -- Chief Mechanic at PC Lube and Tune
Technical training on PC's, networks, and communications.
Point Netscape or WebExplorer at http://pclt.cis.yale.edu/pclt/default.htm

Re: Ada in Client/Server (was: Borland Ada)

[Thomas W. Hood (703)913-4308]

Howard.Gilbert@yale.edu wrote:
<snip>
> 
> Ada may be a wonderful language, but it is unlikely that anyone
> will invest the amount of effort needed to build the surrounding
> infrastructure of development environment, GUI interface, database
> interface, case tools, and all the rest.  Even with the investment,
BZZZZT!  whether or not you _like_ the tools, they exist :
Environment : Rational has a nice one...
GUI         : Fresco beats the crap outta VisualToolbox
DB          : Oracle Pro*Ada or Informix AdaSAME will get you there
Case tools  : Cadre's Teamwork/Ada or Software Through Pictures

> it is simply not true that Ada will ever compete head-on with 
> Visual Basic.  So maybe the Client isn't the best place to 
^^^^^^^^^^^^^^^^ Ada 83 never competed with GW-BASIC either ;-)
> concentrate effort ("Programming in the Small").
<snip>
>  ---------------
> Howard Gilbert -- Chief Mechanic at PC Lube and Tune
> Technical training on PC's, networks, and communications.
> Point Netscape or WebExplorer at http://pclt.cis.yale.edu/pclt/default.htm
> 
I don't disagree that we need to concentrate on interfacing with other
languages/standards, but I _strongly_ disagree that we should nich-ify
Ada 95 by ignoring the client side of C/S architectures.

Thomas Hood
------------------------------------------------------------------------
-- hoodt%postoffice.sdf.sbis.com@inetgw.fsc.ibm.com (_really!_)
--
-- Ignorance can be cured with learning, but stupidity lasts a lifetime.
--
-- I don't speak for ATT, Loral, IBM, RSI, or anyone else.
-----------------------------------------------------------------------

Re: Ada in Client/Server (was: Borland Ada)

[David Emery]

Of course, I've been programming using client/server, ONC RPC and
cross-platform GUI binding (XVT) for several years now...

				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: Borland Ada

[Michael M. Bishop]

In article <60.18011.4393.0N1D0B41@canrem.com>,
Steve Shadoff <steve.shadoff@canrem.com> wrote:
>I was hoping that someone here cound tell me the following.
>
>1) Is there a Borland Ada compiler
>
>2) If not, will there be one soon?
>
>3) What price would it be?
>
>4) Does it use the OWL meta-windowing objects?

There is no Borland Ada compiler at this time and I'm not convinced
that such a thing will exist any time in the near future. I doubt that
Borland sees any major return on investment for an Ada compiler project
and at this point, I couldn't argue with them. If more people become
interested in Ada through initiatives such as GNAT, then it's possible
that other vendors (maybe even Borland) will get into the Ada arena. I
hope this happens because mainstream Ada compilers like IntegrAda and
ActivAda are hideously expensive for a single user who will only use it
at home.

-- 
| 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: Borland Ada

[David M. Tannen]

In article <3iibtm$hlf@source.asset.com>,
Michael M. Bishop <bishopm@source.asset.com> wrote:
>In article <60.18011.4393.0N1D0B41@canrem.com>,
>Steve Shadoff <steve.shadoff@canrem.com> wrote:
>>I was hoping that someone here cound tell me the following.
>>1) Is there a Borland Ada compiler
>>2) If not, will there be one soon?
>>3) What price would it be?
>>4) Does it use the OWL meta-windowing objects?
>There is no Borland Ada compiler at this time and I'm not convinced
>that such a thing will exist any time in the near future. I doubt that
>Borland sees any major return on investment for an Ada compiler project
>and at this point, I couldn't argue with them. 
Actually there is no reason to ever think that Borland will build an Ada
compiler.  There current "hot-ticket" is called Delphi which builds upon
their Borland Pascal v7.0 technology.  In fact if you look at the
language features they have added it is a very nice language for doing
Win3.1 etal development on.  Just don't count on portability to other
OSes or pascals.  Besides that the price is right, <$250 gets the
desktop version on CD and their component library (VCL) on source.  (For
more info see comp.lang.pascal).

Although I will use GNAT for any OS/2 development I might do in the
future, I will be using Delphi for my MS-Windows development until an
Ada vendor can match the Delphi toolset and at their price.

Hopefully the Ada/Windows vendors get the point that there are folks who
will use their tools if they priced them at a reasonable amount.  I do a
lot of short term consulting and many of my clients want portable and
maintainable solutions; but they are not willing to pay thousands of
dollars for tools (and neither am I).  One client is willing to live
within the Windows world and has a lot of BP code so Delphi fits the
bill.  But they would like to also goto  OS/2 one day, and right now the
only reasonable solution I can make is C++ (blech).

So Mr. Vendor if you have a solution for Windows and OS/2 that provides
a visual environment (see Delphi) and a database engine (see Delphi) or
a really good set of libraries for a database engine (see TurboPower's
B-Tree Filer) for ~$500 per seat send me a note.



-- 
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