Re: Why do so many companies use Apex?

["Phaedrus" <phaedrusalt@hotmail.com>]

Of course, I'm not gonna give them equal time without posting my response to
their response...
In the process I shortened it quite a bit, so the text has been modified.

--Phaedrus

>>1. It's SLOW...
I'm not surprised that it is fast in your (idealized) environment.  But,
try to run it across the network, using less than ideal Sun workstations.
That's what it's like out here in the real world.  In a lot of places it's
actually run ON THE SERVER, and the display data is shipped back to the
developer's machine.  And do you know why it's run on the server?  Because
it's too bloody big to run on the developer's machine!

>>2. Care and feeding...
When I talk about "Rational Toolsmiths", I'm not talking about people who
create the custom tools necessary to support the customer's process.  I'm
talking about what should be the trivial task of setting up views!  It's
THAT complicated!  Surely you can see that a good old "a.mklib" is easier?
And, have you tried to have a C++ program call Ada stuff, lately?  The docs
say you can do it...  Tried to call C++ stuff from an Ada program?  Again,
the docs say you can do it.  They lie.  When we called support, they just
said "Oops, that doesn't work in that version.  Wanna buy the new version?"

>>3. It's EXPENSIVE...
>  Again, just comparing prices to a straight compiler is inappropriate.
True.  But that's what the developers WANT.  We want to buy an ice cream
cone, and you want to sell the ice cream store.

>In all honesty, trying to educate customers about all of the capabilities
>in Apex is a monumental task.
Because it's too complicated!  You've tried to wear too many hats, and all
you've proven is that you can look pretty darn silly with a lot of hats on.

>If you mean that you exit Apex and a license isn't freed up, then that's
>an issue that we need to made aware of, but it may depend upon a number
>of variables to do with installation, networks etc.
Repeated calls to the Apex folks resulted in us being told, "That's the
way it is.  Wanna buy more licenses?" (Can you tell that I've had a
less than satisfactory experience with your support group?)  By the way,
it's even worse about releasing target licenses.


>>4. This thing has a terrible learning curve...
>There is only one Apex class from Rational, the standard item refered to above.
>Of course there are other classes for the layered products like ClearCase,
TestMate
>and SoDA.
Oh, silly me.  Just because they all run from under the HUGE Apex umbrella,
and you never see them anywhere else but under Apex, and you see all the
endless pull-down menus from them under Apex even when you don't need or
want them, I tend to treat them as part of Apex.

>Apex makes no pretense to being just a compiler, it isn't.
True.  Ever try to carve with a Swiss Army knife?  They are wonderful tools,
in theory, but they make terrible knives.  Being too complicated, awkward
to use, and forcing the user to spend a significant period of learning time
just to find the knife blade is a serious disadvantage.  And, once you
find it the first time, you still have to go searching for it every time
after that, 'cause there's just too many tools.

>>5. Ever try to use it to debug on the target?
>... an ethernet link (which makes debugging on the target almost
>as fast as debugging on the host)...
My particular target was a PowerPC, and debugging was performed via the
ethernet.  Two out of three times the target would timeout before the
tool had formed the connection.  Folks, that's slow.  (For comparison,
the Green Hills compiler had a much better debugger, and it connected to
the target nearly every time.)

>Indeed, consensus here is that you may have a configuration problem that
>could be usefully investigated.  Which customer do you work for?
Thankfully, I left that environment last year.  I left in disgust after
spending three years fighting the Apex tool set.  In fact, if it weren't
for ObjectAda, GNAT, the odd Verdix project, and even some Vax Ada projects,
I might be tempted to quit doing Ada altogether.  Apex is a mighty big
occurance of pissing in the well, and I'm tired of dealing with it.

>>6. It's a pig.  Every third keypress seems to generate another swarm of
>>windows...
>Apex on UNIX does use a number of windows.
To put it mildly.

>Apex taking a while to load indicates it is being run from a remote
>disk. <snip>  For me it rarely takes more than 10 - 15 seconds to
>start up.
You really should get out into the real world once in a while.  I've
seen startup times as long as four or five minutes, but it usually was
at least two minutes.  More than enough time to go for coffee.  Oh, and
that's assuming that you are able to get a license.  For some reason, the
compiler license is tied to Apex, and it'll keep the license even though
the user isn't actually compiling.

>>Granted, with Rational buying out most of the other Ada compiler
>>companies (Can anybody say "antitrust"?
>Hang on a minute.  Rational has made *one* acquisition in this space,and that
was our purchase of Verdix some 6 years ago.
By the way, why DID ya'all buy Verdix?  I don't think it was for fun.
Eliminating
the competition?  But mea culpa.  The "antitrust" comment was out of line.  I
tend
to get Rational and Microsoft confused, but not without good reason.

>The market isn't there to support more.  No one would be happier than Rational
>were the situation something other than it is.
Of course, the market might be better if people enjoyed using Ada more... And
if the environment was friendlier it might make a difference.  Taken a look
at Visual Basic's user base, lately?  Adding a steep learning curve to the
environment on top of Ada's learning curve is a great way to drive people
away.

>> but even old Vax Ada kicks it's butt for development.
>And I think you have somewhat rose-coloured glasses.  VAX Ada had it's own
>set of challenges!  I remember customers who had multi-day recompile and
>relink times resulting from a single-line change in their source closure.
And I remember, just recently, seeing development stop across the whole
project because of problems with Apex.  And this happened more than once!
Vax Ada was fairly simple to learn, and it was rugged!  Sure, I remember
the slow-as-molasses compile times, and I remember having to use CMS to
check-in/out files... And I remember the strange ways that LSE worked,
with it.  But, compile, link, and debug all happened in ONE window, and
it was simple and easy to use.  Would I want to be using LSE and Vax Ada
again?  Heck no!  But if I could have an environment that worked as well
as the Vax environment, and if I could have a compiler as fast as the
Verdix compiler, would I touch Apex with a stick?  Nope.