Re: An Ada advocacy method

[Marin David Condic <nobody@noplace.com>]

Ed Falis wrote:
 >
 >
 > That really isn't a very good characterization of the point of MFC,
 > which is that it's an application development framework.  When I was
 > with Aonix, an MFC binding was available at extra cost.
 >
"Application development framework" "Development library" Pick your
title - it was a bunch of code I could use to get an app out the door
faster. Ada ought to have one. It shouldn't be an exact duplicate of
MFC, but that doesn't mean the MFC wasn't important in providing lots of
capabilities. Lack of some kind of big development library is a weakness.


 >
 > Don't remember the details on this in ObjectAda.  I do know that
 > "hovering" was implemented as a contextual help aid.
 >
A one sentence blurb while hovering over something is a long way away
from a really thorough collection of hyperlinked documentation. Say what
you will about Microsoft - the documentation you got from MSVC++ was
pretty thorough. It would be a useful thing to have the ARM similarly
hyperlinked and (should Ada ever get something resembling a library) it
would be a good thing to have thorough documentation about all the
available stuff in a library.


 >
 > OA did put you right where the problem was, but I don't think you
 > were in a position to edit and rebuild without exiting the debugger
 > (it was a while ago for me).  Patching was not implemented.  In GPS,
 > you are in the source, can edit and rebuild.  Given the speed of
 > rebuilding, patching is really not necessary.
 >

I won't harp on the debugger because I think it is less necessary for
Ada than with C++. (Most of what I ever needed it for was tracing
wayward pointers or bad values in some variable or other things that
were difficult or impossible to create in Ada.) However, I *liked* the
fact that it was so tightly integrated. Patching was cool. If you're
going to have a debugger, this level of integration is good to shoot for.


 > As of the last time I looked (3 years ago), the GUI builder was still
 >  somewhat separate, but better than it had been.
 >
The thing that was nice about the GUI builder in MSVC++ was the fact
that the GUI was part of the project and you got all sorts of code
generation out of it that made it easy to hook up to the app. I hated
all the cryptic comments and other trash that it stuck into things to
enable the code generation to work, but it at least got me a GUI and its
related code really fast. In Ada, it might be possible to do the code
generation better than in C++. What I liked was that they at least
picked a framework for developing an app and then started providing
tools to help the developer work within the framework to get an app out
the door. Ada could do something similar and possibly keep it moderately
platform independent.

 >
 >
 > Check out the version control in GPS.
 >
I have only taken a sideways glance at this. My understanding is that
GPS can be made to talk to CVS or other third-party products. I suppose
I've got my own ideas on this score and could imagine a nearly invisible
  sort of CM integrated in with an IDE. I won't harp on this one much
because the original point was about the capabilities of MSVC++ and what
was good about that. MSVC++ didn't do much except hook up to some other
system as well, so this isn't an issue here. But if Ada wants to win, it
needs to be *better* than what is already out there and I can imagine
all sorts of possibilities as to how CM might be one area in which to be
"better".



 > One thing to bear in mind while you "bitch, bitch bitch" is that OA
 > was an attempt to put together a Windows development environment for
 > Ada that at least approached MSVC++.  A lot of effort went into it,
 > but the bottom line was that there was insufficient volume for it to
 > succeed at a competitive price point, especially with the support
 > requirements of its native market (people used to getting support for
 > $10K+ type systems rather than the kind they got with MSVC++).  The
 > money wasn't there to move the product to the same kind of
 > capability, though we tried awfully hard.
 >
This is interesting, but not compelling. What made Aonix less successful
than desired in this area were strategic mistakes - not the notion that
Ada needs an environment that has capabilities similar to MSVC++ (and
beyond). The first mistake was trying to *duplicate* what MSVC++ did in
every way. The very best one could hope for would be to forever be
playing "catch up" and "me too!!!" with Microsoft - who has far more
resources than Aonix does and hence they could *never* win. Another
mistake was in not doing sufficient market research to determine what
the customers wanted and what they were willing to pay to get it. ACT
seems to be doing O.K. selling premium level support, so it must be
possible. (Proof by existence! :-) So I don't accept that there was
anything wrong with the notion of developing a well integrated IDE and
looking at MSVC++ (as well as other tools) to see what they did *right*
in the process of figuring out what that Ada IDE should be. Aonix had
the wrong business strategy, not the wrong technical capability nor
insufficient effort on the part of those involved.

 >
 > But from my current location, check out GPS. ;-)
 >
I have GPS downloaded and it does look pretty spiffy. Its heading in the
right direction. It needs to continue to provide more capabilities and 
(from my perspective, at least) those capabilities should be tightly 
integrated and come in a "One-Stop-Shopping" kit. (It could also stand 
to have a few bugs fixed so that one could actually select some style 
options and not have the system puke over it, but that's another story. ;-)


But some of the problems are more Ada-in-general than GPS or some other 
IDE-specific. Why couldn't there be a nice, big, library with all sorts 
of things in it that *exceed* the expectations people usually have for a 
language library? Why couldn't there be a standardized database 
interface that came with development kits (along with a database?) so 
people would come to expect this from Ada? Why couldn't there be a 
standardized GUI interface that provided some kind of portable 
connection between an app and the native GUI?

If Ada wants to attract developers, it needs to provide new and 
interesting capabilities that one doesn't find with other languages. 
There are lots of areas in which this could be done. Some of it involves 
building better IDEs. Some of it involves improving overall language 
capabilities. I know I'd have an easier time selling it to my customers 
if I could say "Look, Ada does *way more* than C++, so I'll save you 
time and money while building your project..." I have a hard time 
selling it if all I can claim is that it does "almost as much..." ;-)

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================