
C++ in Coders at Work - edw519
http://gigamonkeys.com/blog/2009/10/16/coders-c++.html
======
Oxryly
Part of how C++ is successful is that it retains C compatibility, and C
accurately models how the computer _actually_ works (at least computers of the
70s and 80s, which is all we know how to program well). Lovely languages like
lisp, python, haskell may be nicer to work with, but they do not model the
underlying machine properly, and for so many problem domains that is just not
acceptable. It's not just a performance question.

And then C++ implements several programming paradigms (object oriented,
generic, etc) without compromising that machine model.

Plus Bjarne was truly correct when he said: "there are languages people
complain about, and there are languages nobody uses."

~~~
loup-vaillant
I totally agree. C++ main strength lies in its "portable assembler" nature.
However, C++ also is [quite a behemoth][1], while Lisp, Python and Haskell
aren't so.

[1]: <http://yosefk.com/c++fqa/>

The answer then is obvious : we should change the hardware, so it is not C/C++
optimized, but Lisp/Python/Haskell optimized. Then, these languages are easier
_and_ more practical.

~~~
russell
In general, hardware optimized for high-level languages have been a failure,
usually the extra baggage for handling things as machine-level interpreter
slow things down nearly as much as a software interpreter. Nothing has been a
real commercial success and it isnt for want of trying. Off the top of my head
I can think of the Burroughs B5500 which had hardware support for typed data,
the Lisp Machine, and the Intel 432. Sun had a Java machine specification, but
I dont think anyone ever bit.

~~~
LogicHoleFlaw
IBM has plug-in hardware JVMs for its mainframe big iron. They are ungodly
expensive.

~~~
jacquesm
I can't find anything about that, it's quite interesting do you have a link ?

edit: found it:

<http://news.zdnet.com/2100-9584_22-135319.html>

------
timr
This is a disappointingly flamey article: roughly 90% of the comments are from
people who got a bad impression of C++ during the pre-standardization days
(which were admittedly horrible, but long since past). Most of the rest are
from people who just skipped straight to Java, or who are so young that they
never had to learn C++ at all.

The comments that really drop my jaw are the people who seem to hold up Java
as a "better" C++. Java is okay, but from its sketchy real-world performance,
to its crappy generic programming support and poor ability to enforce such
type-safety basics as const-correctness, I've never been impressed. Take the
time to learn C++ for what it is, instead of "C with objects" and you'll find
that it's far more elegant than the backlash would suggest.

I think that what most people really hate about C++ stems from the widespread
use of legacy compilers that incorrectly implement the spec, or implement
older versions of the spec. This problem exists for every programming language
in the universe ( _e.g._ Ruby 1.8.6 vs. Ruby 1.8.7 vs. Ruby 1.9), but since
C++ is widely implemented by _multiple vendors_ , the problem appears worse.
If Python or Java were implemented by Microsoft and GNU and four other smaller
companies, you'd see the same horrible compatibility problems with those
languages, too.

~~~
jobu
The one point that I see throughout the article is that every programming shop
uses it's own subset of C++. Based on coding conventions, library usage, and
business domain I have seen how the C++ code used in different companies can
look like a different programming language altogether.

My professional experience outside C++ is limited, but I had always assumed
this was the same for other languages as well. Is C++ really that much of a
different animal from other languages?

~~~
nradov
In my experience with Java, the core language is small enough that every
company pretty much uses the whole thing. Almost everyone has finally upgraded
to using at least the Java 5.0 syntax by now. Occasionally you'll run across
silly rules that prohibit things like the ternary operator or multiple
returns, but those are minor differences.

The big differences come into play with frameworks. Depending on whether
you're using Struts/JSF/Hibernate/Spring/etc your code may look completely
different.

~~~
tjr
_Occasionally you'll run across silly rules that prohibit things like the
ternary operator or multiple returns_

In avionics software, the ternary operator and multiple returns are often
avoided to help ensure better code coverage during verification.

~~~
nradov
I don't think anyone is writing avionics software in Java? The automated code
coverage tools I have seen handle those cases just fine.

------
rams
"Yet C++ is also frequently reviled both by those who never use and by those
who use it all the time."

I was once listening to RMS speak at a conference. One guy got up and said
that this was one of the n great talks he had been to.He mentioned that
Stroustrup as another speaker who had impressed him upon which RMS said "You
need to get your head checked".

Sometimes a great hacker community can help overcome the shortcomings of a
language. Trevor Blackwell makes that point here:
<http://www.tlb.org/faq.html>.

"Besides their intrinsic characteristics, languages define commmunities of
programmers. You want to choose one that lets you communicate with good
programmers, because you'll learn from them. They tend to prefer powerful
languages like Python, Lisp, and C++. So for example, although Visual Basic is
actually a powerful and complete language, few good programmers use it. C++,
on the other hand, is a rather poorly designed language, but for historical
reasons a lot of smart people use it so at least you'll be in good company."

------
jacquesm
> Stroustrup campaigned for years and years and years, way beyond any sort of
> technical contributions he made to the language, to get it adopted and used.
> And he sort of ran all the standards committees with a whip and a chair.

> And he said “no” to no one.

And that is the core of the problem.

~~~
dkarl
_And he said “no” to no one._

I don't really see this. Most of C++'s complexity emerges naturally from three
things:

1\. Lack of GC.

2\. Direct support for user-defined types on the stack.

3\. The desire to implement every feature as efficiently as the corresponding
C idiom.

There actually aren't very many controversial features in C++: multiple
inheritance, operator overloading, templates, and exception handling are the
ones that come to mind. With the exception of multiple inheritance, none of
these is particularly heinous. Implementing them under the three restrictions
above is where things get complicated.

~~~
jacquesm
Operator overloading all by itself is a source of plenty of headaches, in
combination with multiple inheritance you can spend a good bit of time trying
to find out what something _should_ do before you can begin to figure out what
it _actually_ does.

In most languages my preferred view in the debugger is the source code of the
language, in C++ I almost always just looked at the assembly. It seemed the
more 'clear' language :)

Lack of GC never bothered me much by the way, that's no different in C, and
that's where I really learned how to code, so keeping an eye on memory leaks
and the opposite, double frees is somehow a built-in feature (of the
programmer, not the language).

~~~
dkarl
Is operator overloading in C++ really more complex than it should be, or did
you just pay the inevitable price for dabbling in the black art of multiple
inheritance? Anytime you say "in combination with multiple inheritance" you
can't expect to get much sympathy ;-)

C++ is definitely a language where you can get screwed by "clever" programmers
who would rather be reading TC++PL than actually coding, but it's not so bad
if the people you work with exercise good judgment. I've never had to deal
with multiple inheritance in real production code, for instance.

~~~
jacquesm
There was a time when I made most of my income debugging other peoples
programs, call it 'troubleshooter' or something like that.

It gives you an excellent overview of the various ways in which things can go
wrong, and C++ figured quite prominently in the 'gotcha' department.

C has it's share of issues, double frees, failure to initialize (but most
compilers catch that one nowadays), and stale pointers. With a good discipline
you can work around those.

C++ can obscure the bugs in such a way that it takes you a long long time
before you can 'nail' them. The biggest problem I have with the language is
that the code tends to obscure what is going on at the machine level.

I guess that's a 'feature' too, but I prefer to have a more direct
correspondence between program code and what goes on below the surface. That's
a problem with OO in general by the way, and I think that this is part of what
makes software so terribly inefficient these days.

Gigabytes of ram are barely enough to accomodate a single user os, it's really
pretty weird.

~~~
jimbokun
"The biggest problem I have with the language is that the code tends to
obscure what is going on at the machine level."

Which totally defeats the purpose of being backward compatible with C.

~~~
jacquesm
I think that basing it off C was a quick way to get widespread acceptance
though. It succeeded in that respect.

~~~
Periodic
Yep. If you had a C program you were automatically already using C++. You
could just suddenly start to use the extra features where you wanted them. For
that it was great.

If it had been D instead, an actual new version of C designed to incorporate
new features, instead of C++, additional features on top of C, it probably
would be less reviled but there would have been a lot more resistance to
adoption.

------
psranga
There are parts of all languages that I find confusing, but I'm a little
puzzled by the general criticism of C++ (e.g., the __getitem__ feature of
Python seems to be similar in spirit to operator overloading. Do people
criticize Python too?).

IMHO, C++ is an amazing extension to C which managed to increase productivity
for those tasks for which C would have been the right choice (modulo non-
standard compilers).

If I were writing a performance-critical system-level program today, using C++
would be no brainer. You can fake a lot of what C++ offers with macros and
function pointers in C, but lose type-safety and/or performance. I am very
thankful to all the people who have brought C++ to the state it is in today.

------
alrex021
Its really fascinating to me. We had Lisp and then the road for many lead to
C/C++, Java, and related and then we needed a way to express data in more
human-readable form so some genius came up with XML. XML was to cumbersome
(close tags, how attributes are expressed, etc.) and then JSON came into the
picture. So all that to just come back to where we were in the first place.

Now I clearly understand what some of the veterans in "Coders at Work" really
meant by "Very little progress, if any, has been made in the Programming
space".

~~~
haberman
JSON is not a programming language.

~~~
alrex021
You are absolutely right. My point exactly.

Now you need "two hammers" to get a single job done. Your current programming
language of choice and a data expression language.

For example: In C, C++, Java, or related, you "first" have to build you
structure to represent a Person with first_name and last_name and then you
have to write it to JSON:

Java:

    
    
      class Person { String firstName; String lastName; }
    

JSON with JavaScript evaluation:

    
    
      var names = [{"firstName": "John", "lastName": "Smith"}, {"firstName": "Bob", "lastName": "Jones"}]
    
      eval("(" + names + ")");
    

Lisp handles both naturally. You don't need intermediary human-readable data
expression language. It comes natural to the language itself.

Lisp ver:

    
    
      (defvar names '((:firstName "John" :lastName "Smith") (:firstName "Bob" :lastName "Jones")))
    
      (eval names)

~~~
haberman
> or example: In C, C++, Java, or related, you "first" have to build you
> structure to represent a Person with first_name and last_name

Not if you're using Protocol Buffers, which is essentially a version of JSON
that has "batteries included."

> Lisp ver:

Lisp is not the only programming language around. How am I going to consume
that data from another language? Embed an entire Lisp interpreter?

------
sshumaker
C++ is pretty awful to develop in, especially compared to many other
languages. Some of these issues have to do with poorly designed features in
the core language (templates), static variable instantiation, no good way for
declaring complex data structures in the language (a'la JSON), multiple
inheritance, etc.

But this isn't just a problem with the core language itself, but with the
compilation model and linkage model - and the compilers and linkers. You need
include guards on the top of your header files to make sure the code doesn't
get re-included. You have to aggressively forward declare to work around
declaration dependencies. And you have to trim the files that you include to
keep compile times under control, because here's the fun thing about C++: For
every .cpp file in your project, you will end up reading in and parsing the
same damn header files again and again. In a large project, that might mean
recompiling the same header files 1000s of times. Precompiled headers aren't a
good solution, either - because when you have to touch the header, you pay a
huge cost in recompiling the PCH.

In every other language I've used, I haven't had to worry about carefully
restructuring code (sometimes at a cost in performance) to reduce compile
times - because the core include and dependency mechanism sucks so badly.

Finally, C++ as a language is very poorly extensible. By this, I mean in
compared to languages like LISP (with macros), or Ruby / Scala, which both
make writing DSLs very easy. This is especially unfortunate, given that is so
heavily used in a lot of very specific domains. And don't get me started on
templates - I couldn't dream up a more backwards and awkward way of doing
generics if I tried.

------
prakash
I noticed this as well when I read the book:
[http://www.cloudknow.com/2009/08/review-coders-at-work-by-
pe...](http://www.cloudknow.com/2009/08/review-coders-at-work-by-peter-
seibel/)

------
sb
I think it's a very good article detailing the various flaws of C++; I
particularly have problems with the complexity of the languages making it very
difficult for compiler writers to generate usable error messages (not only
true for gcc as mentioned in the article, but Microsofts C++ compiler
generates many unusable error messages, too! [At least it did in 2004, never
touched it again...])

------
danbmil99
the point about everyone making their own sub-language is exactly right. In
fact, I've heard programmers say that's exactly what they love about it.

Problem is, every shop is inventing their own subculture. When programmers who
haven't worked together look at each other's C++, they're basically learning a
new language.

I do think this has changed a bit in the last few years. The whole 'design
pattern' meme exists primarily to create nexuses of style that programmers can
gravitate to. It just seems like such a slow way home, especially in
comparison to a language like Python, which goes out of its way to restrict
the number of ways you can skin the cat.

Has any serious programmer ever looked at a Python file and said "wtf?" for
more than a minute or two? And, has any experienced programmer _not_ had the
experience of looking at a new batch of C++ (say at a new job) and thought to
him/herself, jeez, this is going to be a lot of work just to understand the
basics of what they're doing?

------
tptacek
I'm liking these Seibel digest posts more than I'm liking the actual book,
which, even in the Norvig chapter, drags a bit.

I think the book might have worked better if it was organized topically,
instead of by person.

------
Jeema
Of course it's going to be more convoluted then newer languages like Java:
Java doesn't have to maintain backwards compatibility with a 35+ year old
programming language. That's just stating the obvious.

Yet for some reason people still use it. The question is 'why'. For many cases
(not all though), I think the reason is largely just institutional inertia -
you stick with the devil you know rather than the devil you don't know.

------
cturner
Have there been experiments with creating a pre-compiler that checked that you
were using a subset of C++? What downsides would this have (other than longer
compile time)?

~~~
jacquesm
But which subset ?

When I program in C++ (and sometimes you have to) there are features that I'll
avoid like the plague, once bitten, twice shy.

In fact, my subset of C++ was usually try to stay as close as you can to C and
use C++ when you have to. That seemed to be a pretty safe route.

Most of my C++ stuff was using Borland C++ Builder or Microsoft visual C++,
I'm happy to say I no longer have to support software for the windows
platform, so no more C++ for me.

~~~
coliveira
I try to stay as close to C as possible. But C++ has many temptations. If you
start using boost, for example, you will be in no time using features of C++
that are not even in the standard yet :-))

------
messel
It's the only language I really feel comfortable programming in, and
everything else seems 1) slow or 2) alien in comparison.

I'm digging scala's design, but have yet to really compare it for number
crunching, and big library building.

By the way, the article didn't really dig into any specifics besides saying
there was feature bloat in C++. Which languages don't have feature bloat? How
much use can I get out of them?

------
c00p3r
How could people complain on c++ when so many daily useful tools were written
in it? Even their beloved JVM is a mere C++ program. Consider very successful
and really cross-platform Webkit, V8, Mozilla's Geeko and so on. And there are
thousands successful proprietary projects like Informix and even this popular
MySQL.

If Google, Mozilla and many others can productively use C++ why other people
can't? They even published guidelines how to use stable and portable subsets
of language.

------
known
Isn't C++ Compiler written in C?

------
nearestneighbor
C++ sucks, why do all those idiots at Google use it? /sarcasm

------
aboodman
Argh. Not a very useful article. Start with an observation: "Everyone hates
C++, and yet it is really widely used. That's odd." Next, 10 paragraphs of
people hating on C++. End with: actually wait, no ending.

~~~
jacquesm
Well, the 'everyone' he is talking about are some of the most respected people
in the computer world, that should count for something.

Also, they make fairly specific criticisms, and they have a track record of
being right about such things.

Java seems to be the C++ replacement of the future, with C# pulling the other
way.

~~~
dtf
_Well, the 'everyone' he is talking about are some of the most respected
people in the computer world, that should count for something._

And while they're busy bitching and hating and pontificating, humble unknowns
are getting things done and making the world a better place. C++ is to systems
programming what PHP is to web programming: the loyal packhorse that the
A-list wouldn't be seen dead on.

~~~
jacquesm
That is very true.

PHP, Python and perl are rarely seen at corporations that existed before the
web came around. Their whole IT department is set up around a different kind
of environment.

I think this is in part why the web is so disruptive, because it enables all
these upstarts using very light and nimble stuff to challenge the big and
established companies directly.

You can pretty much tell what is enterprise stuff and what is 'quick & dirty
but does the job' by comparing hourly rates for programmers.

It also has everything to do with the length of time before someone can be
productive in a new environment. If that length of time is very short then
there is not a very high barrier, which tends to create a lot of 'wannabe'
programmers in that language.

By raising the bar you only end up with people that are willing to invest a
large amount of time in a platform, that tends to favour people that get paid
for their work, which in turn is found mostly in enterprise locations.

~~~
jrockway
_PHP, Python and perl are rarely seen at corporations that existed before the
web came around. Their whole IT department is set up around a different kind
of environment._

Not sure if this is true in general. I work at a bank. We use a lot of Perl.
Banks existed long before "the web", and our Perl stuff is not a web
application either. All the internal web apps are Java.

It is kind of weird, actually -- Java for stuff like the HR apps, and Perl for
the stuff that makes us money. (If it were my decision, I would use Perl for
the web apps and Haskell for the algorithmic stuff... but it's not.)

~~~
jacquesm
> We use a lot of Perl.

That's interesting! That's the last thing I would expect from a bank actually,
wonder how common that is.

But then again, is there even an 'enterprise scripting language' ?

> All the internal web apps are Java.

That's what I would expect. Sun really did some good marketing in that sphere.

~~~
coliveira
The area of a bank that generate money employs the smartest people, usually
coming from academia. So, it doesn't surprise me.

~~~
jacquesm
Good point.

Yours and gcheong's comment just above makes me wonder if someone missed the
boat in getting an enterprise level scripting language out the door. It looks
like there never was a 'natural' successor to stuff like JCL.

~~~
coliveira
Sun and MS are trying to bring scripting languages to their managed
environments. .NET already supports Python reasonably well (I was surprised to
see that SharpDevelop <http://www.icsharpcode.net/OpenSource/SD/> can easily
convert most of my C++ into Python).

