Re: Teaching C/C++ from Ada perspective?

[Maciej Sobczak <see.my.homepage@gmail.com>]

> I don't see how it could be accomplished in any reasonable way with 
> header files and preprocessor.

Nobody sees how it could be accomplished in the Ada compiler, either. :-)

Maybe the whole idea is not very reasonable in the first place? I mean - maybe this is over-engineering that nobody actually asked for, which explains why we don't have it?

Todays' IDEs can figure out and track individual declarations and use that information for editing aids like code navigation or automated refactoring. The tech is there (also for C++), but apparently there is no motivation to use it at the build stage. R1000 might have been an interesting experiment for exploring the idea, but the fact that no compiler vendor does it today can indicate that it is not what people consider a problem worth solving.

You might argue that it is not possible to do for C++ and I will disagree. You can point to the small size of AdaCore as a reason for why this is not done in GNAT, but this argument also loses its strenght if you think about Goliaths like Apple, Microsoft or Oracle, which also develop compilers. Do they do this kind of stuff, having essentially unlimited resources? If not, then why do you think that AdaCore would do that for Ada, even if they had the money to spend?

My guess is that nobody actually needs it.

> You describe exactly the scenario how not to do a tool chain.

I disagree. I want dumb text files.

> Yes. But the correct sentence is: this mess is economically viable 
> because of other mess. Tools feed on design errors, it is an illness.

In the ideal (?) world where you have only one company producing all the tools, perhaps the idea of "library" would be viable. But I want open interfaces and a dumb text file happens to be a pretty good one.
Notice that even in the Ada world the ASIS, which might be a good foundation for semantic-oriented tools, seems to be falling out of fashion. This shows that such constructs cannot be treated as a basis for very long-term projects and large-scale systems are usually long-term as well. That's why I prefer dumb text files as a stable format that can outlive not only fashions, but also vendors themselves. Today, R1000 is a history, but dumb text files are still kicking. This is the kind of format stability that we need in large-scale, long-term projects.

> Sure, there is no alternative history. But the argument is good enough 
> to counter equally fallacious - why GNAT does not do this or that.

But it is still only hypothetical. Whereas the problems that *both* C++ and Ada share in the space of physical code management with actual compilers that are available on the market, are real.

-- 
Maciej Sobczak * http://www.inspirel.com