James Kanze said:
Not so much that, as "as productive as you would be in something
like C". You certainly won't be writing idiomatic C++ after
just a week, even with a lot of experience in other languages.
The fact that your C++ isn't idiomatic, however, and doesn't use
many features of the language, doesn't mean that it is not
maintainable
Of course it is not necessary. Just as there are winners on lottery too, you
can't rule out beforehand that buying a ticket is a poor investment...
---there's an old saw that "real programmers can
write Fortran in any language", but the reverse is true as well:
My RL experience is pretty sour, with long-time C users coming to C++. For
junoirs I'm the fan of tech that teaches C++ without C -- and on the average
level C exposition hurts more than helps.
For too many problems the C++ way differs drastically from the C way. And
in a properly shaped application the injected C-stlye code will introduce
problems.
a good programmer will write clean code in any language,
including a very reduced subset of C++.
Yes. Eventually. Not in 1 week. Just like with spoken language -- if
pressed one can learn basic interactive communication fast (where he can
manage everyday use cases). But if you have sophisticated thoughts and want
to express them precisely, that is far away. If ever happens. I'm using
English for what, 20 years? Read a ton of books, no problem, but still
struggle with stating what I want.
Certainly "productive" is not the same as "perfect" just to map back to the
original thread.
Of course, this "productive" doesn't necessarily mean that you
will be productive in every environment.
We didn;t yet see the answer to how "prodictive" is being measured. So
possibly speaking about different completely different things.
Peopleware and similar books write about the effect of adding manpower to a
late project -- that makes it even later. Getting productive in a new
project takes a plenty of time by itself. A realistic HR view is that the
*properly* selected new guy will gain 0-saldo in like half a year. Or one
year.
At my last workplace I had knowledge and experience that exceeded the sum of
all the other members put together. With weighted measure probably several
times. Yet I'm quite sure my net productivity was in the negatives for ~ 2
months.
So I keep my sceptical view on productivity when someone doesn't even know
the language -- and that is not a tuned one like python.
OTOH, for the same effect the effort of learning the language itself --
along with the other things in NOT necessarily a drain on the productivity,
if we measure it on the whole project, or picking a long time period.
Like Joel suggests in his HR articles, to go for bright people who can and
want to learn, instead of presence of stock knowledge of something.
So to sum it up, I do not doubt that someone just starting C++ can be net
productive in a project (having a proper environment), my problem is with
the statement that it happens early on, especially in a 1-week timeframe.
That doesn't have just the raw time to read the 6-7 essential books let
alone understand, distill and internalize.
If you've not see
exceptions before, I don't think you'd be writing exception safe
code after just one week.
My experience (and reading about others') suggest that changing methods is
damn hard. Even in case the "new way" has proven itself.
There was a good article somewhere describing from life, that someone showed
new approach to development, it was done by people, who appeared to love
them, and enjoy the well-visible benefits. Then later some more stressful
period came, and started to revert to the old way. Despite both knowing and
feeling that it is not good and not beneficial.
C++, being multi-paradigm allows one to continue use his paradigm. It all
looks good too, until the target project uses the same paradigm, or one
compatible. But that is just luck or accident. Especially if the
paradigm is "the C way" -- that differs massively from what is healthy using
the C++ toolbox.
And in no way would one be able to
successfully use other important new features.
Exceptions are a good example to what I said earlier -- one sits down and
can add compiling lines of C-style code ad nauseam, not ever realizing that
it is all broken for the case exceptions thrown from downstairs. And that
code will be either eventually rewritten by others or sit there like a time
bomb. If those costs are honestly calculated in the productivity what
figures we get?
