Re: Ada to C++ translator?

["Ken Garlington" <Ken.Garlington@computer.org>]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:%Wvk6.102$aw5.380@www.newsranger.com...
: In article <cyik6.1725$DE.61421700@newssvr10-int.news.prodigy.com>, Ken
: Garlington says...
: >
: >"Ted Dennison" <dennison@telepath.com> wrote in message
: >news:Qybj6.354$a4.1745@www.newsranger.com...
: >: Heh. Not likely. Ada tasking execs generally fall into one of two
: >categories:
: >:
: >: 1) Uses the OS "threading" capabilities.
: >: In this case, it will be pretty much *exactly* the same speed in task
: >: switching as the OS. The main difference is that the Ada tasking exec
is
: >:
: >: 2) Uses its own tasking code within a single OS process/thread.
: >: This is usually significantly *faster* that OS threads, since it
generally
: >
: >This is *definitely* not true for *early* Ada compilers, compared to
: >current-generation RTOSs. (The key phrase in the original statement:
"when
: >they *originally* developed the code...)
:
: I suppose that's possible. In my experience, what I wrote has been
universally
: true. However, my experience with Ada only dates back to about 1989.

To paraphrase my response to another claim that efficient tasking has been
universally true since 1889 (e-mail me if you want the identity of "X", "Y"
and "Z").

"...the last copy of the Xcompiler for the VAX/1750 *still* had
poor tasking behavior (early '90s), as did the last Y one (still in use
today), compared to the lightweight threads available, say, in VxWorks for
the PowerPC. I'd be happy to post the Yassembly code sequences if
you're interested. You might claim that this is comparing apples (PowerPC)
with sour apples (1750A), but so what? It's only been recently (in project
lifetime scales) that modern 32-bit processors with COTS OSs and excellent
thread support has been available to us DoD contractors, so it's not
surprising that our systems reflect the limitations of the available
environment. You might also claim that these are obsolete compilers, and so
it's unfair to use them as a basis for comparison, but so what? We still use
Yon active projects because we can't afford to switch to another 1750
toolset.

"This behavior, by the way, is despite the (literally) millions of dollars
my
company invested in both companies before they went under (and still invest
in Z to maintain the remnants of the Y product). I'd be happy to
post the invoices if you're interested. You might claim that this is unfair
because we didn't making better tasking a priority, but so what? We spent
our money where we had to spend it -- to get the features that were the most
necessary. If we were able to do our job without tasking (but not without a
compiler that, for example, gave us access types now found in Ada95), then
we spent our money where our project needed it....

"How could you possibly have access to every toolset combination still
rattling around today, much less in the entire history of Ada, to run your
benchmarks? This hubris shouldn't be buried in an e-mail, it should be
publicly posted for the world to gaze at in awe! :)"

And now, of course, it is :)

As I've noted before, this sort of attitude makes it very difficult for me
to sell Ada. From the same post:

"There's plenty of blame to go around with respect to Ada...

"6. And the one that got us here: Legitimate issues with the Ada language
are
attacked with religious zeal instead of reason. Compare Ada/Eiffel
discussions with C/C++ discussions, then look at their penetration into the
software engineering community. I think you'll see a correlation....

"This has always been the case with Ada. I remember early X meetings
where we were trying to get a compiler bug fixed for a large package, and
being told that "the problem is that you're not coding it using the
preferred Ada style." I remember A-12 being attacked because we didn't use
tasking. The attackers didn't care about any silly compiler problems, etc.
They just knew we "weren't Ada enough" if we didn't use tasking. After all,
they could get tasking to work on their PC; what's the problem?....

On the projects where we used C++, I don't believe we've ever had anyone say
we weren't "C++ enough" because we constrained the use of templates. Quite
the contrary - there's an active effort to develop a standard C++ subset
(EC++) for use in certain domains, without any fear of being arrested by the
"C++ police" for subsetting the language. Why would someone want to use a
language with a built-in Inquisition?