Do people still use Ada -- (it was mostly used in the Defense Department)
It appears that Ada was last updated in 2005 and there's work toward an Ada 2012, so the language itself is still alive and kicking.
As far as use, Ada isn't mandated for use in the Department of Defense anymore. Most of the work that I've seen and done has been in Java, C, and C++, but there's also use of the .NET framework and I've even heard of projects running other JVM languages such as Scala, depending on how the system will be used. There's probably a lot of code out there in Ada, so I wouldn't be surprised if there's a lot of code reuse and maintenance happening. Given the nature of defense projects, it's hard to come up with specific numbers as to its use.
There is a list of Ada projects and users, but it looks like the last update was in June 2008. There might be more recent lists out there, but I couldn't quickly find any.
Are all applications written in Ada "Legacy"?
If you're asking if there is new Ada development, I wouldn't be surprised if new systems are being written from the ground up in Ada. I would suspect there would be too many, but there are probably some out there. However, I would suspect that most of the Ada work out there is maintenance or upgrades on existing systems, not new development.
Does Ada knowledge still sell
Knowledge in anything sells, if you can find someone who is looking for that skill set. Even if you aren't using Ada in development, I've found that knowing a particular language or framework has changed my opinion and how I use other languages or frameworks. I would suspect that knowing Ada would give you an insight into other methods to design and construct software in other languages as well.
The fundamental problem with "void" is that it does not mean the same thing as any other return type. "void" means "if this method returns then it returns no value at all." Not null; null is a value. It returns no value whatsoever.
This really messes up the type system. A type system is essentially a system for making logical deductions about what operations are valid on particular values; a void returning method doesn't return a value, so the question "what operations are valid on this thing?" don't make any sense at all. There's no "thing" for there to be an operation on, valid or invalid.
Moreover, this messes up the runtime something fierce. The .NET runtime is an implementation of the Virtual Execution System, which is specified as a stack machine. That is, a virtual machine where the operations are all characterized in terms of their effect on an evaluation stack. (Of course in practice the machine will be implemented on a machine with both stack and registers, but the virtual execution system assumes just a stack.) The effect of a call to a void method is fundamentally different than the effect of a call to a non-void method; a non-void method always puts something on the stack, which might need to be popped off. A void method never puts something on the stack. And therefore the compiler cannot treat void and non-void methods the same in the case where the method's returned value is ignored; if the method is void then there is no return value so there must be no pop.
For all these reasons, "void" is not a type that can be instantiated; it has no values, that's its whole point. It's not convertible to object, and a void returning method can never, ever be treated polymorphically with a non-void-returning method because doing so corrupts the stack!
Thus, void cannot be used as a type argument, which is a shame, as you note. It would be very convenient.
With the benefit of hindsight, it would have been better for all concerned if instead of nothing whatsoever, a void-returning method automatically returned "Unit", a magical singleton reference type. You would then know that every method call puts something on the stack, you would know that every method call returns something that could be assigned to a variable of object type, and of course Unit could be used as a type argument, so there would be no need to have separate Action and Func delegate types. Sadly, that's not the world we're in.
For some more thoughts in this vein see:
Best Answer
Not all Ada compilers will behave like this. You must be using a version of the GNAT GPL compiler prior to 2015, or FSF GCC prior to 5; at that point, GNAT didn’t check for integer overflow by default - you had to compile with
-gnato
.This was stated to be in the pursuit of efficiency, but many users thought that the gain in efficiency wasn’t worth the cost of explaining this behaviour to new (and, sometimes, not-so-new) users. And, of course, using compiler-provided types such as
Integer
isn’t best practice.Nowadays, your program compiles OK without
-gnato
(admittedly without warnings, even with-gnatwa
) but runs withSPARK Ada would detect this problem: