Re: Have the Itanium critics all been proven wrong?

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Michael S a wrote on comp.lang.ada:
> "not possible to clobber arbitrary memory locations" is probably good
> enough definition of what I consider "safe" computer language.
[...]
> So let's do not call it "two languages". Let's talk about "full Ada"
> and "checked Ada" where "checked Ada" is a subset in which "it is not
> possible to clobber arbitrary memory locations". Hopefully  "checked
> Ada" is still much closer in # features to the "full Ada" than to
> SPARK.

Yes.  SPARK imposes a lot of restrictions which in turn exclude most of
the standard run-time library.

>>> Q.
>>> Do people actually use the "second" Ada language for really big
>>> and really complex application programs?
>>
>> It is certainly possible. For example, the main SPARK tools are
>> written in SPARK.
> 
> Well, so let's define "really big and really complex application
> programs" (RBaRCAP) as something that not only executes complex
> processing, but also handles multiple tightly or loosely related
> inputs for hours/days/weeks/months either as long-running service or
> as an interactive [GUI] application.
> Then compilers or lint-like tools are not RBaRCAP.

I work on such an application: 2 million lines of code, multiple
processes running 24x7 on multiple machines, mission-critical,
multiple GUIs.  This application uses almost every feature of Ada and
then some more :) (e.g. we've patched the compiler and run-time
library so that every exception dumps core for post-analysis before
being handled the normal way).  SPARK would be unsuitable for this
application but full Ada is *eminently* suitable.

Like I said we use almost every feature Ada has to offer, from high-
level tasks and protected objects to the lowest level of bit
manipulation in memory addresses (e.g. in a tree structure we align
all objects on 8 bytes; the 3 low-order bits of all addresses are
therefore zero and we use some of them to store booleans).  We also
use custom memory pools that call mprotect(2).  But these "scary" bits
are few, far between and well isolated; they must represent less than
0.5% of our code base (still, 10 kSLOC or so...).  It is important to
note that we could do without those low-level tricks; they exist only
for performance reasons or to detect and diagnose rare errors.

-- 
Ludovic Brenta.
The standard-setters boost roadmaps.