Re: Running a preprocessor from GPS?

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

"EGarrulo" <egarrulo@gmail.com> wrote in message 
news:2df4698f-4c8e-457c-822d-209cb2f8ab5e@googlegroups.com...
>On Monday, July 27, 2015 at 10:26:39 PM UTC+2, Randy Brukardt wrote:
>> Besides, if you're going to be writing Ada, you're going to be writing 
>> code
>> that's more verbose (in many ways) than C-family languages. It might take
>> some getting used to, but there is no time better than the present to
>> getting used to that.
>
>I don't mind verbosity when it serves a purpose, but I have little 
>tolerance for
>boilerplate code, and this is one such case.  Let's add the lack of a 
>facility like "printf",

Not strongly typed.

>along with a generic type system that can't perform basic type inference,

Would have to weaken the type system.

> and I am beginning to understand why engineers opposed the adoption of Ada
> by the US Department of Defense.

Ada is not for people that want to write quick sloppy code (and then debug 
it for months). Besides, the C++ generics that you are implicitly referring 
to didn't exist until long after Ada was designed. And they do things which 
would destroy the Ada contract model of generics (in C++, generics are 
glorified macros).

>  Requiring programmers to state their intentions explicitly is beneficial, 
> but
> requiring programmers to "spoon-feed" the compiler and/or write bloated 
> code is not.

"Real Ada Programmers" don't even use the shortcuts built-into Ada:
    (1) Real Ada Programmers don't use "use clauses" - objects are named by 
their expanded names;
    (2) Real Ada Programmers don't use anonymous access types or anonymous 
array types;
    (3) Real Ada Programmers don't use positional calls;
    (4) Real Ada Programmers don't use Ada 2012 conditional expressions 
(unless they need the expression to be static).
And so on.

[I'm being a bit tongue-in-cheek here. I don't quite qualify as a "Real Ada 
Programmer" under this definition, as I'll use targeted "use type" clauses 
for operators, and "use clauses" for some language-defined packages (like 
Text_IO), and for a project-specific core type package (there are several of 
these in Janus/Ada). And I definitely use positional calls 'cause I'm too 
lazy to find and write out the parameter names. But I'm surely pretty close 
to the spirit here.]

Most Ada programmers quickly find the value of the verbosity, because it 
means that the compiler can catch a lot of errors before anyone has to spend 
time debugging. But I can see that it is a hard sell, because as with many 
of the real advantages of Ada, it's not really apparent until you've used 
the language a while and realized that it detected things that you normally 
would have had to find some other way (typically, hours in a hot debugger or 
lengthy trace log).

My recommendation (as always) is to do things "the Ada way" and you'll find 
that it starts to make sense after a while. It's especially true about 
worrying about perceived "verbosity" or micro-performance (the cost of 
evaluating unused trace messages). Those things are really premature 
optimization -- a trap that we all fall into from time-to-time, but a trap 
nevertheless. They end up having no impact on the quality of the resulting 
application, and take up valuable time that could have been better used 
doing something that does impact the quality of the application.

                                      Randy.