James said:
Pavel said:
Bo Persson wrote:
[...]
int i = 0;
f(i);
myprint(i);
If it is written in Java (or C, for that matter), I can
tell with some certainty that myprint() receives 0 as an
argument. But to tell something about it in C++ I have to
know whether f() takes a reference or a value
Using a better name than f() would help a lot!
You are trying to avoid the point really hard -- I am clapping my hands!
No he's not. He's addressing the real problem directly.
Imagine you changed f() to doSomething() where Something
really speaks for itself. In C, you can just leave it at that,
in C++ you have to say:
doSomethingAndNeverChangeTheArgument(i) or
doSomethingAndMaybeChangeTheArgument(i)
If you have to say that, then doSomething didn't speak for
itself. I've never used anything like
"AndMaybeChangeTheArgument" in the name of a function, and I've
never found readers of my code had any problem knowing which
functions modified their arguments, and which didn't. Even in
the standard library (which doesn't particularly shine by its
naming conventions), it seems rather obvious that v.insert()
will change the vector, and that v.size() won't. I don't need
to look and verify that size() is a const function, and insert()
isn't.
Standard Library is a very bad example because it does have consistent
conventions and it is Standard, that is, a C++ programmer is expected to
know these conventions.
Any proprietary program of a considerable size is full of its own
conventions, most of the time they are little less consistent than in
the Standard (both because they have to cover bigger code base and their
authors did not have luxury of decades to polish these conventions).
Now can you please fix the code instead of only criticizing it? Bo gave
a good example:
int i = 0;
int j = increment(i);
cout << i << endl;
Please could you apply your vast experience of working in well-run
programming teams at which you hinted previously, and replace the
ill-selected names in this code to make it obvious for a reviewer what
line #3 is supposed to output without their having to resort to the
information outside of this original source code?
Oh, and yes -- what name choice would convince the reviewer that the
(renamed, of course) increment() function actually behaves with regard
to its argument exactly as its new perfect name unambiguously implies it
is supposed to behave?
-Pavel
[...]
I am not saying there is no good C++ programmers (and, by now,
you should have an idea what I mean by "good" -- it includes
"not extra expressive") -- but my mileage says there are more
Python, C and Java good programmers than C++.
That's certainly not the case of Python (the total number of
Python programmers is probably less than the number of good C++
programmers), and almost certainly not for C. But it is, in
many ways, irrelevant. Supposing you meant the percentage of
good programmers, rather than the absolute number:
Yes, that is what I meant.
I mostly agree with all that follows, but you introduced a lot of new
concepts, so I have some questions (see below):
1. In my experience, there is a large group of bad programmers
who sell their wares by bluff. Because they're more
concerned with "marketing" than any technical issues, they
"practice" the most "in" language. I suspect that today,
they're mostly in C#; I've experienced them in Java and C++,
however, in the past.
C++ was very in at the beginning of the 1990's, and so
everyone and his bother was adding it to their CV. For
Java, the period was the end of the 1990's, but it may still
continue today---Java still enjoys great visibility. An
interesting effect is that when Java appeared, and became
the in language, the average skill of C++ programmers shot
up considerably.
But C++ is still fairly much in view, and there are still a
number of programmers claiming C++ skills who have
absolutely no competence in programming, in general, much
less in C++.
2. The percentage of good programmers will almost always be
greater in smaller languages, since the only people who are
using them are those who do so intentionally, and who know
enough to evaluate the various technical considerations.
I'm sure that the average level of programmers in Modula-3
is considerably higher than it is in C++, for example; all
five of them are really competent people.
How do you define small vs big languages? From the above, it seems it is
by the number of practitioners; then, I would say, C++ is now fairly
small as comparing to Java; then, following your logic, reviewing Java
code must be, on average, more time-consuming and disappointing activity
than that of C++ code (per LOC or whatever other metrics) -- but my
experience tells different. But let me know if I guessed wrongly.
3. While people at the end points (extremely skilled, or
incompetent) are exceptions, the apparent skill level of
most programmers depends on how well the software process is
run. I've worked in places with a well run process, and
I've seen very average programmers produce excellent code.
I've also works in poorly run shops, where even above
average programmers produced shit.
Same experience -- but with some replaced epithets. No, I do not blame
you for s-word, I am just not sure we are thinking of the same issue. To
clarify, please could you classify the code like my snippet above
according to your standards you applied in the preceding paragraph --
whether it is, say, bad code in your opinion, and if it is, how would
you fix it.
(To be on record, here is my answer to this question: it is just the
code the like of which C++ (and C or Java) practitioners are likely to
meet in any development organization, no matter how run, that supports
large enough amounts of code. But their difficulties with this code will
differ depending on whether it is C++ or C or Java).
The language itself plays a role, but much less than you'd
imagine. Generally, it's been my experience that the success or
failure of a project never depends on the language; the cost of
making it a success can, to a certain degree, and C++ could
certainly be better. But in the well organized shops I've seen,
which have actually measured the difference, C++ turns out to be
less expensive than C (significantly) or Java (somewhat) in
terms of total programmer time needed. (This may depend
partially on the application domain. The place in question made
very, very large scale network management systems. I suspect
that the infrastructure available -- direct support in the
server, etc. -- might make Java cheaper for small, interactive
web sites. And infrastructure really should have been a fourth
point above---regardlesss of the intrinsic qualities of
Modula-3, for example, the lack of tools and support from other
products makes it a non-runner in most cases.)
Yes, of course, we are are talking about the languages that could be
used. Basically, C++ was unique in that it was the only [wide-spread]
language "with OOP" that could provide winning efficiency. I believe OOP
is useful for big project, BTW -- it takes some work to imitate them in
C although it is possible and was done successfully in those "poorly
run" development organizations I worked for. It required some
discipline, but probably less than C++ requires so those organizations
were not good enough for C++ (can't help it, sorry)
Java was very slow with exposing system level functionality and did not
perform too well for long time, so C++ was practically the only language
of choice for such apps. BUT -- this is changing very rapidly. (Just an
example, recently, I was able to write kind of a ps command in C# that I
could compile and run in both .Net and mono -- same code for both
Windows and Unix for ps! Anybody who ever tried to write ps-like utility
or API would really appreciate. It did not show much on UNIX (Mono API
is still not good enough), but my point is that the above advantage of
C++ is vanishing really fast. Java will have to take off their white
gloves to compete and will introduce more system-level abstractions
(they already started doing it, e.g. their Preferences API provides a
fair access to Windows registry -- it would be unthinkable "Java no-no"
in the 90s).
But my point is not about technical aspects of C++ -- it is quite
competitive in those, but about its communication aspects (I would use
the word "expressiveness" but it was already overused on this thread, I
think).
Basically, my concern is: will C++ keep enough practitioners to make it
safe for organizations to approve C++ for new programs (I am talking
about PMO programs, not computer programs here)? At some critical level,
they will just say: "Yes, you guys may be smarter than others, but we
cannot find as many smarties as we need and we learned hard way we can
only use the best for C++ specifically and it is too expensive to really
train them inside (as opposed for, say, Java or Python or C#) and you
are so expensive to both hire and fire (C++ legacy is a bigger liability
FORTRAN or C, from my experience) -- we are going to start this
application in Java (or even C) to reduce our risks of not finishing it
or not being able to fix or maintain it in the future". In fact, I have
been seeing it happening during the last 3-5 years (I have also ween
exceptions where organizations returned to C++ from Java but these were
just that -- rare exceptions, and these are now struggling with their
C++ projects).
Not knowing what you've been doing, who knows. Your experience
doesn't seem to correspond to mine (over 30 years), nor to
actual measurements made in the places I've worked.
Overall, my feeling is that nobody really likes C++, and that it
really isn't a very good language. But all of the others seem
to have even more problems, at least in general. (In specific
contexts, of course, the conclusion may vary.)
Hmm. I cannot recall another language where same piece of code can mean
so many different things depending on the non-local [from the reader's
perspective] context. My original example was the simplest one I could
come up with -- I don't even want to start on operator overloading etc.
I mean, it may not be the most popular feature these days, but this does
not help much while reviewing the others' code: who knows what the other
guy was thinking when he wrote this or that piece.
And the beauty of a preprocessor is a completely different song (C
shares the feature, but not Java or C#). I am all for pre-processors,
but the way it is done in C and C++ really hurts: you cannot tell a
difference between a macro and another object unless you rely on some
naming convention (and there are tons of evil articles around teaching
people how to make macros look and behave "just like functions" etc.).
One of IBM's PL/1 compilers had a much more powerful preprocessor, with
loops etc. but at least it was reasonable: all macro names started with
'%' so anybody could tell a macro from a non-macro without looking up
the definition..
-Pavel
