Re: Rational Apex

[Gene Ouye <geneo@rational.please_no_unsolicited_mail.com>]

!!!!!!!!!!! WARNING !!!!!!!!!!!
	!!! SHAMELESS PLUG INCLUDED !!!
	!!!!!!!!!!! WARNING !!!!!!!!!!!

I agree with most of the things that Tony said below especially his
first three "suggestions/recommendations", but I do have to comment on
some of his post (I must warn you that I work for Rational and am
directly associated with the product discussed in the next few
paragraphs, so you should consider my opinions biased, even if they are
true :-)

First, I've missed most of the start of this thread, so I apologize in
advance for any duplication or wasted bandwidth...

I can understand the metaphor comparing Apex for the "everyday user"
with every day commuting in a rather large, cumbersome, vehicle, but
"circus train" wouldn't be my first choice!  ;-)  One could argue
whether that metaphor is appropriate, but I would rather discuss another
option that isn't mentioned: Apex Ada for Windows NT.

If you have a bunch of PC's sitting on your desktops, and they are
capable of running NT4.0, then you can run Apex Ada natively on the PCs
instead of using them as X-servers connected to UNIX boxes.  You can get
it without all the "cumbersome" :-( features like Configuration
Management and Change Management if you like.  Most people who use it
comment favorably on how un-"cumbersome" it really is.  There's no need
to use an X-server to UNIX, it's a Windows application, and in fact it
comes with a demo version of CLAW and the CLAW GUI builder.  If you want
to work in conjunction with existing UNIX Apex developers, you can
easily plug Apex NT into the UNIX CMVC repository.

There are some things you will not get away from.  The subsystem/view
paradigm is still there in Apex NT even if you choose not to use CMVC
(in fact, it maps nicely to DLLs).  And the whole notion of imports and
exports between Rational subsystems is an extremely powerful paradigm
for architecting an application.  Also, Apex NT (like UNIX Apex and like
GNAT) requires one compilation unit per file, and the filename is
directly related to the unit name (although not in the same way as
GNAT).  And yes, there is a straightforward way (incorporated into the
GUI) to parse the compilation units out of other source files :-)

I do a lot of simple Ada things these days (I'm in a marketing job now,
need I say more?) and I find it quite easy to do them with Apex.  Just
as Ada doesn't force you to create a new integer type for every number
in your application (you can make them all Standard.Integer if you want)
and Ada doesn't force you to put every tagged type into a different
package (you can put your entire application in one procedure if you
like), Apex doesn't force you to partition your application into lots of
subsystems and views.  I keep a "play area" subsystem with a view
containing several directories that imports all the base libraries. 
Whenever I want to throw something together quickly (like when I want to
see if someone's sample code really does produce the errors they post),
I just go there and try things out.  I find the syntactic and semantic
completion make writing the simple applications go much faster...

BTW, I haven't updated the external Rational web pages with the latest
information on Apex NT (didn't want to be pushing vaporware), so don't
go rushing over there yet for more details.  If you check it over the
next few weeks you'll see some pages specifically dedicated to Apex NT.

Gene Ouye <g.e.n.e.o.@.r.a.t.i.o.n.a.l...c.o.m>
    (make the obvious fix to send me mail)

Apex Ada NT Product Manager


Lowe Anthony A wrote:
> 
> Roy is totally right.   For the standard everyday user I equate Apex as
> driving a circus train to get to work.   There can be a ton of overhead just
> to get the first file put in and compiled.  When it comes to the build
> manager, QA, CCB members, Apex is their best friend.  It has quite a few very
> useful tools and utilities available, but if you are used to a MS interface,
> it can be quite annoying.
> 
> As for suggestions/ recommendations:
>     * Learn as much about the Apex tools and how the components function (i.e.
> subsystem versus view versus history).  If you architect correctly, it can be
> years of easy sailing.   If you just throw something together, you will spend
> more time fighting the tool than building with it.  (Another fact true of
> Ada).
> 
>     * Provide the correct training to the specific job functions.  The
> standard developer needs to have a basic understanding of how Apex does stuff,
> but does not need gory details about the underbelly of the program.   Spend
> the money however to get the development environment people up to speed on how
> to manage Apex.  This will save much time, dollars, and frustration in the
> long run.
> 
>     * The RCI capability Roy spoke of is beautiful for replacing 'obsolete'
> environments with a nice push button GUI.  We have quite extensively used a
> RCI to replace a VAX command line environment and it is immensely helpful.
> If you choose to use a GUI compiler (GNAT, ObjectAda) the utility of the RCI
> dramatically drops, since the GUI environments provided by the other compiler
> are most often easier to use than Apex.
> 
>     * Overall, like Roy said, Apex is a great tool if you need strong
> Configuration Management, Change Management, and have a very diverse or
> changing product.   I find it quite cumbersome to use as just a coding
> environment (especially if you have PC's in front of the developers and they
> have to XWindow over to a server to use it!).   If you have a simple product,
> I would think hard about a smaller product.
> 
> Good Luck!
> 
> --
> Tony Lowe                   Rockwell Collins
> 1431 Opus Place   -  Downers Grove, IL 60515
> (630)-960-8603          Fax : (630)-960-8207