C++ Scandal?!

[loufoque]

Ted wrote :

I'm just
wondering about the general direction of the language if there is such a thing.

This should show you a bit the direction the language is taking :
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1969.html

 

[Phlip]

Is the complexity of C++ by design?

Yes. C++ was invented to follow these requirements:

A. be popular and useful by many
B. shred; compete with assembler
C. be useful on very large projects

To hit Requirement A, C++ had to upgrade C, so that C's humongous library of
existing code could compile, with minor tweaks and cleanups, as C++ code.
That permits C++ to inherit C's huge mind-share, as programmers upgrade
their projects to take advantage of C++ features.

Irritatingly, C is a very old system _also_ invented to hit those same
Requirements. So every hack and degeneracy in C that addressed that list,
C++ extended and augmented.

To hit B, both C and C++ obey the principle "you don't pay for what you
don't use". Consider the lowly pointer p. If you dereference it with *p,
both C and C++ will generate machine opcodes that hit that memory location.
The language doesn't add any safety checks that p contains a valid address
of the correct type. If you won't use them (because you write clean code
where p always points correctly), then you don't pay for them.

That freedom adds incredible complexity. C++ has a new system, references,
to do essentially the same logical thing but in a different physical way. So
C++ has two systems, not one, to put a "handle" on an object and pass the
handle around.

To support Requirement C, both C and C++ can compile and link incrementally.
Because the original C link program was poorly written and hard to manage, C
did not have modules like Ruby or Java. It had #include files, to simulate
importing a module. But programmers must write the import directly into .h
files, manually, instead of simply writing procedures and letting the linker
figure out what bits get linked.

On top of this, C and C++ both have many extra systems (bald pointers, class
declarations, typename, file-scope static) to allow programmers to _reduce_
the number of #include files that each source file must reference. All those
systems force a programmer to maintain and balance the dependencies among .h
files, manually, all for the slim benefit of letting a broken linker rapidly
link all the object files that didn't change.

Oh, and C and C++ force you to manage memory manually, without garbage
collection. Requirement B. Don't get clcm started on that one!!!

 

[Roland Pibinger]

And for what reason do you think?

Probably the desire to create an all-embracing, general-purpose,
multi-paradigm language.

So which simpler solution will win over C++?

'Lightweight' scripting languages like Python, Ruby, PHP, ... will
probably continue to grow. Within C++ the 'generic programming'
paradigm will be replaced by user-friendly idioms and styles.

Is clc++m the "keep the
complexity alive as long as possible" group?

The clc++m posters do not represent the average C++ programmer. clc++m
has been dedicated to very special, 'bleading edge' questions. In that
sense it will 'keep the complexity alive'.

I think so too. So you think C++ is doomed then?

IMO, C++ usage will decrease but C++ will retain certain niches. But
this is a complex question. There are many aspects outside the
language that influence language decisions (eg. Microsoft has replaced
C++ with C# as platform language). I also expect the renaissance of
'KISS' within C++.

Best wishes,
Roland Pibinger

 

[Phlip]

Probably the desire to create an all-embracing, general-purpose,
multi-paradigm language.

That's what the brochure says.

If that had indeed been the goal, Bjarne Stroustrup would have started from
scratch, and would have created a new language that cleanly balanced as many
"paradigms" as were known in the late 1980s.

Instead, he also set the goal of creating a fast and popular language. So he
started with C, and added as many paradigms as could fit.

Granted, we now have a powerful language. But we only get the full power at
the cost of amazing complexity. To support "generics", Bjarne replaced
macros with templates, which are really just type-safe macros. They are
defined to expand text, which is then compiled.

This lead to incredible problems with the language specification, because a
template expanding an indentifier has to guess if it's meant as an object or
a type.

An "all-embracing" language would have simply made classes themselves
objects, so you can pass handles to classes into function. Languages that
use this simple technique don't need templates. However, they do need very
advanced compilers, and a bit more execution time. So BS didn't use this
technique.

'Lightweight' scripting languages like Python, Ruby, PHP, ... will
probably continue to grow. Within C++ the 'generic programming'
paradigm will be replaced by user-friendly idioms and styles.

Use them in preference to C++ as often as possible.

IMO, C++ usage will decrease but C++ will retain certain niches. But
this is a complex question. There are many aspects outside the
language that influence language decisions (eg. Microsoft has replaced
C++ with C# as platform language). I also expect the renaissance of
'KISS' within C++.

Use C++ for system-level things (compilers, GUI engines, databases) that
must be portable and fast. Such things themselves tend to have multi-decadal
life spans.

 

[Ted]

Ted wrote :


This should show you a bit the direction the language is taking :
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1969.html

Well I was kinda asking rhetorically, as I don't expect "the vacuum hoses to be removed".
That's a good link though. The question becomes how long are people (me) will be willing
to use a bulldozer to rake the front lawn. I don't see traditional engineering concerns given
much though in the C++ evolution (read things outside of the technology box).

Ted

 

[Phlip]

Well I was kinda asking rhetorically, as I don't expect "the vacuum hoses
to be removed".
That's a good link though. The question becomes how long are people (me)
will be willing
to use a bulldozer to rake the front lawn. I don't see traditional
engineering concerns given
much though in the C++ evolution (read things outside of the technology
box).

That is a wild, and empty, generalization. Please don't think you are the
first person to get sold C++, to discover it sucks, and then encounter
defensiveness here. You will do better to become proficient with all the
tools in your toolbox.

What experience do you have with a non-C++ language? Please don't say Java
or C#; they take much away from C++ while adding nothing, causing their own
kinds of complexities.

 

[Ted]

Probably the desire to create an all-embracing, general-purpose,
multi-paradigm language.

I'm sceptical that it ends there.

'Lightweight' scripting languages like Python, Ruby, PHP, ... will
probably continue to grow.

Oh, that's apples/oranges though. Those are different, higher level tools.
There use may bring their own complexity by more technology dependency
and more cross-technology integration complexity.

Within C++ the 'generic programming'
paradigm will be replaced by user-friendly idioms and styles.

Such as? (preprocessor-based templates? ).

The clc++m posters do not represent the average C++ programmer.

I would agree with that. The group has the "language lawyer" types and
compiler vendor types I think.

clc++m
has been dedicated to very special, 'bleading edge' questions. In that
sense it will 'keep the complexity alive'.

Chicken and egg scenario?

IMO, C++ usage will decrease but C++ will retain certain niches. But
this is a complex question.

I think it may go that way to. I don't think it has to though.

There are many aspects outside the
language that influence language decisions (eg. Microsoft has replaced
C++ with C# as platform language).

Well MS has it's own agendas so that rejection probably doesn't count for
much (I personally reject MS technologies regularly).

I also expect the renaissance of
'KISS' within C++.

Well I would certainly hope for that (it of course is why I embarked on creating
my preprocessor-based template system, amongst other things) but I certainly
won't hold my breath until that time!

Ted

 

[Ted]

That is a wild, and empty, generalization.

Well to anyone who has done any significant engineering, seen products
go through their lifetimes using different technologies, etc., it isn't.

Please don't think you are the first person to get sold C++, to discover it sucks,

That's all you hear because that's where you are at I assume. I really don't
want to discuss petty issues with the uninformed, so I'm not going to keep
responding to your empty posts.

and then encounter defensiveness here. You will do better to become proficient with all the tools in your toolbox.
What experience do you have with a non-C++ language? Please don't say Java or C#; they take much away from C++ while adding
nothing, causing their own kinds of complexities.

I don't partake in pissing contests. (There's more to software engineering than
just knowing a programming language/languages. Much more.)

Ted

 

[Ian Collins]

Well I was kinda asking rhetorically, as I don't expect "the vacuum hoses to be removed".
That's a good link though. The question becomes how long are people (me) will be willing
to use a bulldozer to rake the front lawn. I don't see traditional engineering concerns given
much though in the C++ evolution (read things outside of the technology box).

The bulldozer comes as a kit of parts. You can select the rake if all
you have to do is rake the front lawn, or the complete package if you
wish to remove that annoying hill that's obscuring your view.

On the contrary, not paying for what you don't use is an excellent
engineering principal. Ever examine a modern auto starter motor? It's
engineered to do on job well, with no extras. C++ gives you the same
ability with your code.

 

[Ted]

The bulldozer comes as a kit of parts. You can select the rake if all
you have to do is rake the front lawn, or the complete package if you
wish to remove that annoying hill that's obscuring your view.

On the contrary, not paying for what you don't use is an excellent
engineering principal. Ever examine a modern auto starter motor? It's
engineered to do on job well, with no extras. C++ gives you the same
ability with your code.

That is cliche by now. Everyone and their mother knows that concept behind C++.
It's not the issue being discussed.

Ted

 

[Mirek Fidler]

Granted, we now have a powerful language. But we only get the full power at

the cost of amazing complexity. To support "generics", Bjarne replaced
macros with templates, which are really just type-safe macros. They are
defined to expand text, which is then compiled.

No that is not how templates work. At least, this is as correct as
saying that "compiler expands C statements into assembler which is then
assembled".

An "all-embracing" language would have simply made classes themselves
objects, so you can pass handles to classes into function. Languages that
use this simple technique don't need templates. However, they do need very
advanced compilers, and a bit more execution time. So BS didn't use this
technique.

Referring to dynamic typing here?

BUT... "execution time" is just one side of problem with dynamic typing.
What proponents of "dynamic" languages usually fail to grasp is idea of
type safety.

In practice: When I change some important interface in my code, I simply
run compiler to tell me all the places I have to fix. With dynamic
typing, compiler would issue no errors at all...

Use them in preference to C++ as often as possible.

IME, C++ can beat "lightweight" languages with ease in terms of
productivity... when used properly. The C++ advantage there is strong
type system and endless flexibility.

Mirek

 

[Mirek Fidler]

I also expect the renaissance of

'KISS' within C++.

Trying to do my best Looks like some people start to understand:

http://www.arilect.com/upp/forum/index.php?t=msg&th=460&start=0&S=8b84a158103a73da8e4db65a0b4ef758

http://digg.com/programming/Really_clever_C_GUI_toolkit_and_DE

Mirek

 

[Phlip]

No that is not how templates work. At least, this is as correct as saying
that "compiler expands C statements into assembler which is then
assembled".

The metaphor "templates expand to text which is then compiled" might be
hallowed in the Standard verbiage, or might not. It is a good way to explain
the various typesafe issues with template instantiation, and why 'typename'
is needed. There is a phase of compilation where the compiler has merged the
source of the template with the appearance of the names of its parameters.
Text. Then the compiler looks-up the identifiers, as it would fresh text.

I only use the statement to illustrate the contrast with languages that
treat classes as first class objects. This gives us the choice:

foo<SimCity>(42); or foo(SimCity, 42);

The second case is much simpler and less redundant. At the cost of declaring
a powerful class Class thing to behave like a class name.

Referring to dynamic typing here?

I don't see why classes as objects would conflict with static typing. The
technique is indeed used most frequently with dynamic typing.

BUT... "execution time" is just one side of problem with dynamic typing.

Do not get a Smalltalk VM maintainer arguing about that topic.

What proponents of "dynamic" languages usually fail to grasp is idea of
type safety.

Typesafety should be optional. I should be allowed to declare what
interfaces take only certain types, and which ones take Object as the
generic type.

In practice: When I change some important interface in my code, I simply
run compiler to tell me all the places I have to fix. With dynamic typing,
compiler would issue no errors at all...

And with unit tests, a "mistake" in types might accidentally "work",
accidentally ship, and accidentally get you paid.

The ability to change anything in a program, and then run a batch of tests
that check behavior - not just type - is priceless. And there are those who
are learning that the arbitrary and paranoid type checking that some
languages impose interferes with unit tests.

IME, C++ can beat "lightweight" languages with ease in terms of
productivity... when used properly. The C++ advantage there is strong type
system and endless flexibility.

Try implementing the Prototype Pattern in Ruby. You just pass the name of a
class and call 'new'. No futzing with marginally typesafe 'clone()' methods.

Oh, and don't get me started about Block Closures.

 

[Mirek Fidler]

IME, C++ can beat "lightweight" languages with ease in terms of

Try implementing the Prototype Pattern in Ruby. You just pass the name of a
class and call 'new'. No futzing with marginally typesafe 'clone()' methods.

Actually, this the problem. I do not need to implement "Prototype
pattern". I need to develop apps

Mirek

 

[Ian Collins]

Typesafety should be optional. I should be allowed to declare what
interfaces take only certain types, and which ones take Object as the
generic type.




And with unit tests, a "mistake" in types might accidentally "work",
accidentally ship, and accidentally get you paid.

The ability to change anything in a program, and then run a batch of tests
that check behavior - not just type - is priceless. And there are those who
are learning that the arbitrary and paranoid type checking that some
languages impose interferes with unit tests.

I'd like to second that sentiment, having been working with PHP for a
while, I find the dynamic typing liberating.

Comprehensive units tests go a long way to replacing strong typing.

 

[Ted]

Trying to do my best Looks like some people start to understand:

http://www.arilect.com/upp/forum/index.php?t=msg&th=460&start=0&S=8b84a158103a73da8e4db65a0b4ef758

http://digg.com/programming/Really_clever_C_GUI_toolkit_and_DE

A heavily templatized UI library? Yuck. Doesn't sound less complex
to me.

Ted

 

[Phlip]

I'd like to second that sentiment, having been working with PHP for a
while, I find the dynamic typing liberating.

That's a significant testament if you can even see the effect through the
fog of Perl, PHP, or Python! ;-)

 

[Noah Roberts]

Referring to dynamic typing here?

BUT... "execution time" is just one side of problem with dynamic typing.
What proponents of "dynamic" languages usually fail to grasp is idea of
type safety.

In practice: When I change some important interface in my code, I simply
run compiler to tell me all the places I have to fix. With dynamic
typing, compiler would issue no errors at all...

Bad example because this is bad practice and doesn't always work. The
compiler is a tool for compilation, not a find and replace tool. You
should be looking for places where the old signature was used and
change them for the new one. Don't use the compiler to find such
things. Use the compiler when you are done and think you have found
everything.

You can also quite easily have the compiler issue diagnostics like this
in a dynamic language. For instance the GNU compiler will generate a
warning when a method signature is called but not in the advertized
interface of a class in objective-c. It will of course continue to
compile as this is ok according to the language but the warning is
issued and if it was not expected could be fixed.

There are also several things that can easily be done in a dynamic
language that are more difficult in a static language like C++, and
visa-versa, but everything is possible in both; it is just a matter of
what tool you will be using. People that make claims that you can't do
X or Y in either, as your claim does, probably have little experience
with one or both types of languages.

 

[Mirek Fidler]

In practice: When I change some important interface in my code, I simply

Bad example because this is bad practice and doesn't always work. The
compiler is a tool for compilation, not a find and replace tool. You
should be looking for places where the old signature was used and
change them for the new one. Don't use the compiler to find such
things. Use the compiler when you are done and think you have found
everything.

Ahh, of course things are never that easy. Sure you have to know what
you are doing. However, the fact that compiler is able to check more helps.

You can also quite easily have the compiler issue diagnostics like this
in a dynamic language. For instance the GNU compiler will generate a
warning when a method signature is called but not in the advertized
interface of a class in objective-c. It will of course continue to
compile as this is ok according to the language but the warning is
issued and if it was not expected could be fixed.

Yes, but my believe is that "typeless" entitities are much more common
in Objective-C. If I remember well, Obj-C collections store "Objects",
so once something gets into the collection, type information is lost...

Mirek

 

[Phlip]

That technique is documented somewhere, possibly under "Lean on the
Compiler". You only make such a change as you know will cleanly break, then
compile and run. When an error reports, your editor can instantly navigate
to it. This is often faster than browsing code.

Ahh, of course things are never that easy. Sure you have to know what
you are doing. However, the fact that compiler is able to check more
helps.

The technique works for both static type checking and unit test errors. Such
errors should use the same editor navigation system. With current
technology you will navigate to the failing test. Soon you will also be
able to navigate to the tested code.

The ability to change something and predict the results (syntax error, test
fault, or passing tests) is very important because it represents how well
you understand your code.