Re: Emacs contributions, C and Lisp

[David Kastrup <dak@gnu.org>]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> What happened to the other one?  It is still in the source.
>
> Smart completion is all about showing the appropriate completions for
> the context where the point is. Once you know the number and type of
> arguments, if you have zero or more than one acceptable overloads, the
> code is malformed. Barred that, there is one and only one correct
> overload, which is the one the compiler will use. A correct smart code
> completion system will show precisely that overload.
>
> That's what a C++ programmer expects, and then I'm perplexed when I read
> this:
>
> [snip]
>
>>> Eli, are you a C++ programmer? Do you code in C++ on a regular basis?
>>
>> Yes!
>
> It is obvious then that we have here a complete miscomunication, so I'll
> stop the discussion here.

The miscommunication appears to be that you apparently are convinced
that coding C++ on a regular basis is impossible without using crutches.
It is my opinion that writing a code style that can neither be written
nor understood without reverting to computer help is a bad idea.

Writing a code style that can neither be written nor understood without
letting a full-blown compiler take a look at it is an even worse idea.
If you consider that a _regular_ part of your coding practices, you are
writing code that can only be maintained by throwing it away and
rewriting from scratch.  This step will become necessary in particular
whenever the C++ standards change in some manner.

That may be putting it overbluntly, but I am absolutely unsurprised that
someone coding C++ on a regular basis does _not_ find himself on the
edge of ambiguities so often that he requires constant handholding by
his tools in order to produce working code.

When one declaration changes the meaning and syntax of a program all
over one file (and yes, this sort of thing _can_ happen with C++),
getting things right might require a full-file parse.  When presented
with a preexisting C++ file, being able to get the actual meaning out by
the use of exhaustive tools is nice.  When _writing_ a C++ program, it's
preferable to stay away from those edges and thus get along with more
simplistic tools.  Or even none at all.

-- 
David Kastrup