Re: How do I write directly to a memory address?

["Randy Brukardt" <randy@rrsoftware.com>]

"Hyman Rosen" <hyrosen@mail.com> wrote in message 
news:4d6e53c1$0$21954$882e7ee2@usenet-news.net...
> On 3/1/2011 7:41 PM, Randy Brukardt wrote:
>> If "the environment" had a strongly typed Ada interface,
> > then the error could not occur there.
>
> Isn't it the case that Ada proponents argue that Ada is a good
> (and possibly the best) programming language in general, and not
> just when interfacing to a strongly typed Ada interface?

I think most Ada proponents are *only* thinking about strongly-typed 
interfaces when they are thinking about Ada as a great programming language. 
Ada can do little to help when using a weakly-typed interface, nor can any 
other programming language.

You might remember when I referred to "98% of code being garbage, including 
most Ada code" (for which you called me a "crank"). One of the things I was 
thinking of is weakly-typed interfaces without little runtime checking as 
well. Those are garbage in any programming language, including Ada. (Note 
again that just because they are garbage doesn't mean that you can't use 
them - it's not that unusual to take an empty bottle or can or junk mail out 
of the trash and use it for something.)

> I sense an attitude of "If it's good, thank Ada. If it's bad, it's the
> fault of something else."

No, it's the fault of the interface, not necessarily the items on either 
side. There might very well being nothing wrong with the "something else", 
either. The problem (in implementation terms) is that there is no 
consistency check across an interface.

Specifically, when you use "pragma Import" in Ada code, you are telling the 
Ada compiler what the other side expects for parameter types, number of 
parameters, and the like. There can be no check that these declarations are 
correct, in Ada or in the other language. (At least not unless you are the 
compiler vendor for both languages, a highly unlikely situation for most of 
us.) The effect is that any error in these specifications causes random 
behavior that is often very difficult to trace to the actual mistake.

Probably 75% of the effort debugging Claw was tracking down these sorts of 
problems (along with related compiler bugs).

OTOH, if both subsystems were written in Ada (or in C++ for that matter), 
the compiler could enforce consistency between the calls and declarations, 
and the majority of those errors would be detected before they caused any 
problems at all.

That's why I have always believed that to truly get the benefits of Ada, you 
really have to write the vast majority of the system in Ada. If someone is 
trying to integrate major subsystems built in a variety of different 
languages, they greatly increase the chances for errors *at the interfaces* 
and reduce the value of Ada (and the other languages as well). Indeed, even 
though it is bad for business, I try to discourage people from just writing 
a small part of a system in Ada, as I believe that the hassles of doing so 
will most probably outweight the gains. (Plenty of others disagree with me 
on that.)

This was one of the major reasons that we built Claw to allow creation of 
Windows GUI programs all in Ada (and as much as possible in an Ada 
paradyme). Having to go outside of Ada for major parts of an application 
greatly reduces the benefits of Ada. Ideally, you would write everything in 
one language (hopefully Ada), but that isn't always possible (you might be 
forced to use SQL, or some GUI for which there is no Ada equivalent, etc.).

Note that this isn't just an Ada-specific phenomona. It applies equally well 
to C++ and Java and pretty much any other programming language out there. 
Maybe even more so, since Ada at least tries to make a facility for using 
other languages available within the language (most other languages require 
vendor-specific features to do that).

Anyway, most of the point here is that the *need* to interface immediately 
reduces the value of a strongly typed language like Ada. (And it also 
reduces the value of program analysis tools and pretty much anything else 
that can be done before the execution of the program - which is the only 
point where bugs can be automatically detected rather than having to be 
ferreted out by testing/debugging.)

                                  Randy.