Re: Please suggest use-cases for introspective code generation

On Sep 9, 6:58 am, Sohail Somani <soh...@taggedtype.net> wrote:


But only as long as it is clear to everyone that it is, in fact, a new
language. Perhaps you remember in 2006 that Microsoft tried extremely
hard to get the world to believe that C++/CLI was just C++ with a bit
of sugar. They even sponsored an article called "Pure C++" by Stan
Lippman:

http://msdn.microsoft.com/en-us/magazine/cc163852.aspx

....deliberately calling it "Pure C++", perhaps through power of
suggestive psychology, to counteract any suspicion in the readers
minds' that gross, non-standard, deviations away from C++ were being
made.

The problem is not with new languages. They are created all the time.
The problem is taking your entire stock of aluminum, and infusing it
with reinforced carbon, because you learned through experiment that
reinforced carbon is *really really* awesome.

We, as engineers, deliberately choose the tools we employ to construct
systems. There are always trade-offs when choosing one over the
other. A feature of a tool or primitive will be beneficial in one
context, and detrimental in another.

For example, instead of throwing an exception for irrecoverable error,
some "languages" will put up a message box to the user. This gentle
message box uis wonderful, and the users of those languages love it.
Is that something that should be done in C++?

Programming languages are not pots of soup. It is not a good idea to
take as many "beneficial" features of tools and primitives at same
level of abstraction and throw them all together. To do so in any
language, not just C++, would ruin its spirit, if such a spirit
exist.

Take Scheme for example. It is a nice, soft, language. You can write
code and let it execute, and when it crashes, the softness is like a
marshmallow falling on a pillow, with no exceptions. But as we all
know from C++, exceptions are good. So we should add exceptions to
Scheme?

Scheme is also a favorite in computer science research, number theory
included. But Scheme is slow. Maybe we should add the _asm statement
from C++ to Scheme. After all, it would not change the language. It's
just a new keyword that would not interfere with existing Scheme
code. Would that be good? Imagine expecting every Scheme-conformant
interpreter to suppport _asm.

But why stop there. C++ is not the only good language. BASIC has some
nice features too. So does Pascal. So does Forth. FORTRAN,
COBOL....How about adding code where super-documentation can be
generated directly from the code, not like Doxygen, but something that
could go straight to 4-colour printer?

What we _could_ do is go to each programming language, look at each
feature of it, and ask whether C++ contains something similar. If not,
then we could add it to C++. Would that be prudent, even if it is
feasible?

Right now, fortunately, C++ is good at a few things. If we "mash" in
features from other languages, we might violate the spirit of it make
it good at nothing.


Just make sure it is called something else, not C++.


I had never heard of it until yesterday.

Note that I have no problem with something like OpenC++. I think there
_should_ be a place others can go to experiment with a new language,
that, from a distance, looks vaguely like C++, but really is not.

That way, if it turns out that such gross changes to the language
does, indeed, erode its integrity, no harm is done.

Those that have changed it will have what they want, and those that
have stayed with C++ will have what they want, and if it is true that
the existence of the new "++C++" is inconsequential to "C++", as the
proponents of change seem to imply, then there will be no reason for
objection to this equal-but-not-equal approach.

-Le Chaud Lapin-

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]