Comments on Kickin' the Darkness: The Fundamental Theory of Ada

For the exact reasons the pi-dividers complain abo...

2008-02-07T12:40:00.000-06:00

For the exact reasons the pi-dividers complain about, the planes, in fact, do not crash.

Pi-dividers: Please do not apply for a job where my money or my life will depend on your code.

Casts, type-conversions, whatever you choose to ca...

2008-01-09T22:22:00.000-06:00

Casts, type-conversions, whatever you choose to call them. To my thinking, acting like the plane is crashing if I dare try to divide a floating-point number by an integer is inconsistent with mathematical convention. But by adopting your "better than you" tone of the rarefied software engineer versus the lowly coder, you have pretty much guaranteed that I will not bother with discussing the matter with you further. Thanks for confirming some of what I already thought about Ada programmers.

Anonymous:

A better one would be, why shoul...

2008-01-09T13:26:00.000-06:00

Anonymous:

A better one would be, why should it be so difficult to get half of pi? Or for another, why does it have to require me to overload operators and/or wrap subexpressions in multiple layers of ugly casts, to write a hash function for, say, a Bloom filter?

Ada.Numerics.Pi / 2

What's so difficult about that?

There are no casts in Ada. The fact that you're using C terminology indicates that you're probably thinking in C and trying to implement it in Ada. That path guarantees conflicts with the language. When your thinking follows the SW engineering discipline that Ada enforces, you'll find that such conflicts don't arise. That's why coders hate Ada, and SW engineers (about 2% of developers) love it.

I got my CS degree from a university where Ada is ...

2008-01-09T08:34:00.000-06:00

I got my CS degree from a university where Ada is a required language used in CS III "Data Structures." Most students absolutely hated Ada, whereas I actually thought it not too bad, though a tad verbose. I noticed the usefulness of type declarations that you explain here and still think it's a wonderful feature. But eventually I got frustrated with it, because of those type mismatches you mention. "Why can't I multiply velocity by a time interval and add it to distance? They're all just numbers!" is a very poor, straw-man example. A better one would be, why should it be so difficult to get half of pi? Or for another, why does it have to require me to overload operators and/or wrap subexpressions in multiple layers of ugly casts, to write a hash function for, say, a Bloom filter?

Ah, but you're not getting my point underly...

2007-09-04T15:08:00.000-05:00

Ah, but you're not getting my point underlying this Fundamental Theory stuff. Hopefully the
Picking the Right Tool post will help clarify where I'm coming from.

Types are just types. A strongly typed language i...

2007-09-03T23:12:00.000-05:00

Types are just types. A strongly typed language is good for many problem domains. Conversely, a weakly-typed language like Perl 5 can be very powerful. The power to morph quickly as one uses Perl to process Query Design Language files into C accessors for Oracle, as I did in 1997 for Lockheed Martin, was very powerful and prodigious. At that point in time Perl was a hot item in the software community. I loved using Perl because it was easy to learn, it was very terse, and was very powerful for text processing. Using Ada, C, or C++ for that particular job would have been painful. With Perl it was a breeze.

This gets back to my premise from earlier responses in this blog. Pick the right tool for the job. Marc has significant experience building complex ground breaking systems for the U.S. Navy and beyond. For these systems, which need to failsafe, Ada is an excellent choice.

In 2007, I think object models, name spaces, and domain-specific programming languages rule the day. Languages will continue to morph. Computer science is a very young discipline. It has only been around for roughly 60 years.

As we move toward service-oriented architectures, dynamically composed programs, and grammar-oriented architectures, much work will need to be done to realize the dream of self-configuring systems that adjust to threats and loads in real-time. Guaranteed quality of service and guaranteed service delivery are important.

I believe one of Ada 83's biggest contributions was the notion of package specifications and package bodies as a mechanism for information hiding and abstraction. Grady Booch pressed further with the notion of subsystems that were composed of Ada packages (or namespaces).

To me extensibility and the composition of reusable components is very important.

But, let's get back to what is the central issue. Pick the right tool for the job. There are many excellent languages and software development platforms.