C++ fluency

[osgUser]

Hi for all

This is my post here. I believe this is the right place to post my
question.
I'm searching in the internet for the real meaning of C++ fluency. In
my search I found almost nothing or vague answers. I'm programming C++
about 3 years and I can't say if I am( or any person that have the
same experience ) is fluent.
So for you, experienced programmers and engineers, what you consider "C
++ fluency"?

Thanks for the replies

 

[Phlip]

So for you, experienced programmers and engineers, what you consider "C
++ fluency"?

Answer questions on without getting your
answers questioned.

 

[Victor Bazarov]

Hi [..]
I'm searching in the internet for the real meaning of C++ fluency. In
my search I found almost nothing or vague answers. I'm programming C++
about 3 years and I can't say if I am( or any person that have the
same experience ) is fluent.
So for you, experienced programmers and engineers, what you consider "C
++ fluency"?

Just like with any other language, it is not enough to be able to write
(express your thoughts/concepts) in the language to claim fluency. One
has to be able to *read* the same language as "spoken" by others.
That's often more difficult (I can attest to that AFA English is
concerned, which is not my native tongue, but in which I now consider
myself fluent).

Also, familiarity (and that's not "I've read about them" kind) with
*all* elements of the language (and its Standard library) to the point
where you feel comfortable using those, and don't have to dig deep into
the documentation to at least understand the *intent* behind the code
you read, is IMO necessary to claim fluency. If you are "fluent" in
basic "better C" subset of C++, but, say, have really hard time getting
templates, then you're not fluent.

Fluency allows one to skip the "thinking" ("figuring out") phase when
reading code. The *meaning* of the code (purposely obfuscated code does
not count) should just "appear" in your mind when you're reading
somebody else's code, in which case you can call yourself "fluent".

Just my $0.04

V

 

[osgUser]

Hi [..]
I'm searching in the internet for the real meaning of C++ fluency. In
my search I found almost nothing or vague answers. I'm programming C++
about 3 years and I can't say if I am( or any person that have the
same experience ) is fluent.
So for you, experienced programmers and engineers, what you consider "C
++ fluency"?

Just like with any other language, it is not enough to be able to write
(express your thoughts/concepts) in the language to claim fluency.  One
has to be able to *read* the same language as "spoken" by others.
That's often more difficult (I can attest to that AFA English is
concerned, which is not my native tongue, but in which I now consider
myself fluent).

Also, familiarity (and that's not "I've read about them" kind) with
*all* elements of the language (and its Standard library) to the point
where you feel comfortable using those, and don't have to dig deep into
the documentation to at least understand the *intent* behind the code
you read, is IMO necessary to claim fluency.  If you are "fluent" in
basic "better C" subset of C++, but, say, have really hard time getting
templates, then you're not fluent.

Fluency allows one to skip the "thinking" ("figuring out") phase when
reading code.  The *meaning* of the code (purposely obfuscated code does
not count) should just "appear" in your mind when you're reading
somebody else's code, in which case you can call yourself "fluent".

Just my $0.04

V

Viktor, thanks for your reply. I got some good answer now.

 

[Alf P. Steinbach]

* osgUser:

This is my post here. I believe this is the right place to post my
question.
I'm searching in the internet for the real meaning of C++ fluency. In
my search I found almost nothing or vague answers. I'm programming C++
about 3 years and I can't say if I am( or any person that have the
same experience ) is fluent.
So for you, experienced programmers and engineers, what you consider "C
++ fluency"?

Being fluent in a language has to do with being able to express yourself easily
(synthesis) and in a way so that others do not react to the awkwardness of your
utterings, and it has to do with understanding other fluent speakers easily when
they're saying something meaningful (analysis).

It doesn't mean that you have memorized an extreme vocabulary and set of idioms,
and it doesn't necessarily mean that you know all the rules of the language.

For programming fluency additionally has to do with understanding programming in
general. With natural language a fluent speaker (e.g. a native speaker) might
say very silly things and still be regarded as fluent, because the relationship
between the language and things to express is just a simple one of memorization:
is this word or idiom appropriate for this concept *by convention*? With a
programming language you're always expressing new things, things never before
expressed, things where there can be no existing memorizable convention, so that
that mapping of language to things expressed is not one that can be simply
memorized but needs understanding & thinking & a sense of aesthetics: even if
you have memorized all the rules of C++ and the entire C++ standard library, if
you choose a wholly inappropriate algorithm or data structure then you'll not be
regarded as fluent no matter how technically correct C++ your solution is, while
on the other hand, if your solutions are good but perhaps do not utilize some
standard library feature that could have simplified the code a little for those
familiar with that feature, then you'll still be regarded as fluent.

And this difference is more important than one may think.

For at least my own ability to understand other's code is based very strongly on
understanding what constitutes good or at least, not unnatural ways to use the
language to express various classes of problems. And so when a novice asks here
about something, and presents code that does something in a very inappropriate
way, then I sometimes completely misunderstand what the code *actually* does
because in the haste of replying I incorrectly see an attempt to write something
more appropriate. Not comparing myself or others of the regulars here to chess
masters, but you see something of the same with chess masters: a chess master
can memorize a meaningful board position at a glance, but give him or her a
random board position, something not meaningful, an arrangement that doesn't
stem from an actual or possible game, then he or her fails to memorize the board
position, the actual positions of the pieces, even after lengthy inspection.


Cheers & hth.,

- Alf

 

[James Kanze]

Hi [..]
I'm searching in the internet for the real meaning of C++ fluency. In
my search I found almost nothing or vague answers. I'm programming C++
about 3 years and I can't say if I am( or any person that have the
same experience ) is fluent.
So for you, experienced programmers and engineers, what you consider "C
++ fluency"?

Just like with any other language, it is not enough to be able to write
(express your thoughts/concepts) in the language to claim fluency. One
has to be able to *read* the same language as "spoken" by others.
That's often more difficult (I can attest to that AFA English is
concerned, which is not my native tongue, but in which I now consider
myself fluent).

That's a tricky requirement. Spoken by which others? If you
don't understand Cockney (I don't), you're not fluent in
English? If you don't understand all of the code at the IOCCC
site, you're not fluent in C?

C++ offers some very nice possibilities for obfuscation, if
that's your thing. And far too many programmers use them
unintentionally; there's a lot of C++ out there that I don't
understand, and I'd consider myself moderately fluent in C++.

[...]

Fluency allows one to skip the "thinking" ("figuring out")
phase when reading code. The *meaning* of the code (purposely
obfuscated code does not count) should just "appear" in your
mind when you're reading somebody else's code, in which case
you can call yourself "fluent".

What do you mean by "the meaning of the code"? Most of the
time, the real question when reading code isn't what the
programmer is doing, but why. If you see something like:

std::string::const_iterator pivot
= std::find( s.rbegin(), s.rend(), '.').base() ;

, it's rather obvious (if you're fluent in C++) that the code is
looking for the last '.' in the string "source". But to
understand the code, you really want to know why (and you might
conclude that if s is "a.b/c", the code doesn't do what it
should).

Understanding code (in any language) typically takes more than
just fluency in the language. (Note that this is true of
natural language as well. If I hear two surgeons discussing
some details of an operation, I probably won't really understand
it. Even if they're talking a language I'm fluent in.)

 

[James Kanze]

Being able to step through and debug code that uses STL heavily.

One could argue that if you need the debugger to understand the
code, you aren't fluent. (I would argue that if the code is well
written, and you're fluent in the language, you have no need of
the debugger.)

And of course, C++ is more than just the STL.

 

[Noah Roberts]

Hi for all

This is my post here. I believe this is the right place to post my
question.
I'm searching in the internet for the real meaning of C++ fluency. In
my search I found almost nothing or vague answers. I'm programming C++
about 3 years and I can't say if I am( or any person that have the
same experience ) is fluent.
So for you, experienced programmers and engineers, what you consider "C
++ fluency"?

Thanks for the replies

You're fluent in C++ when you're meditating on some other subject, such
as philosophy, and realize you're caught in a while (1) loop and have
been thinking in C++ all this time.

hehehe C++ makes a great language for telling a computer how to perform
tasks. It's not so great as a symbolic language for reasoning.

 

[Pascal J. Bourguignon]

Nor for a compiler, as Tom DeMarco once suggested. If you submit code
that doesn't compile, that's a defect that goes through the tracking
system like any other problem.

Or, less drastically, use batch systems, like in the olden days. If
you can only compile once a day you'll be much more careful about what
you write.

Well, sometimes I use batch(1), but my jobs come completed as fast as
I queue them. Perhaps multicores broke batch?

 

[Ian Collins]

Answer questions on without getting your
answers questioned.

Or even here!

Maybe that should be "answer questions here without being corrected by
James"!

 

[Victor Bazarov]

Or even here!

Maybe that should be "answer questions here without being corrected by
James"!

That's a tall order, I tell you.

V

 

[Phlip]

When I submitted through batch systems I used to spend hours and hours
hand-checking the code before for typos before it went in. And I'd spend
hours and hours writing extremely detailed tests of each and every
function, and making sure I'd hit all the paths.

These days, I get it about right, feed it to the compiler (which will pick
up some of my silly errors), then step through it making sure it does all
it should do with a much more basic test harness. Perhaps I'll realise
that some part isn't tested, and add some more tests; perhaps I'll even
throw some away. Now that a meg of RAM and a gigacycle of CPU cost so
little I can ignore them, why not make use of them?

I TDD, and run the tests after every couple of edits. Much less thinking is
involved, and that's a Good Thing.

And I spend just a little effort to type-safely _defeat_ C++ typechecking.
Sometimes it feels like typechecking is negative reinforcement - denying
what your code should not do - whereas TDD is positive reinforcement -
rewarding your code for doing the right thing...

Test software: Tests to check for problems you've already fixed.

Including the problem of the non-existence of each line of code...

 

[James Kanze]

Writing the tests before compiling (or even writing) the code
has become in fashion again, at least in certain circles. Nice
to know that what I was doing 30 years ago is the latest
technology today.

The issue is actually complex. When interactive terminals, with
screens, started becoming standard equipment, we went through a
phase in which the programmer just sat down in front of the
screen, banged out his code without any thought, and then edited
it until it compiled, and called that a development process.
And a lot of "tools" have been developed to support
this---IDE's, for example. Clearly, this doesn't work either.

I TDD, and run the tests after every couple of edits. Much
less thinking is involved, and that's a Good Thing.

Less thinking is a good thing? I'm not sure I agree.

And of course, tests may prove that code doesn't work, but they
can't prove that it does work. There are just too many aspects
which can't be reasonably tested. Not to mention that you
still have the problem of determining whether the tests are
right, and complete.

And I spend just a little effort to type-safely _defeat_ C++
typechecking. Sometimes it feels like typechecking is
negative reinforcement - denying what your code should not do
- whereas TDD is positive reinforcement - rewarding your code
for doing the right thing...

It's a point of view. Having code compile without errors first
try is a very satisfying positive reinforcement for me. As is
having code which works correctly on first link is as well. The
way I've usually seen TDD used is to not write any code except
in reaction to a failing test---and a failing test is a negative
input.

Including the problem of the non-existence of each line of
code...

You don't need a test to know that something that isn't there
won't work.

In general, there are many different levels of tests. In the
well run places I've worked (far from all of them), any errors
found in integration or acceptance tests resulted in an analysis
of the process---they should never occur. On the other hand,
you couldn't check code in that didn't pass the unit tests,
which basically left it entirely up to the developer how he
organized his own work (writing the code and the tests, etc.): I
generally expected my unit tests to run first time (and don't
use a debugger), but others preferred a more interactive
procedure, debugging errors found in the unit tests. On the
whole, however, those who used such techniques tended to take
more time to produce poorer code.

 

[Ian Collins]

Writing the tests before compiling (or even writing) the code
has become in fashion again, at least in certain circles. Nice
to know that what I was doing 30 years ago is the latest
technology today.

The issue is actually complex. When interactive terminals, with
screens, started becoming standard equipment, we went through a
phase in which the programmer just sat down in front of the
screen, banged out his code without any thought, and then edited
it until it compiled, and called that a development process.
And a lot of "tools" have been developed to support
this---IDE's, for example. Clearly, this doesn't work either.



Less thinking is a good thing? I'm not sure I agree.

The saved thinking is in the debugging. If you've only changed a few
lines since the tests passed, you know what's broken them. So you can
either fix, or undo and start again. If the pain of undoing is too
great, you changed too much between test runs.

And of course, tests may prove that code doesn't work, but they
can't prove that it does work. There are just too many aspects
which can't be reasonably tested. Not to mention that you
still have the problem of determining whether the tests are
right, and complete.

The tests prove what the tests test. TDD tests aren't code validation
tests, they are part of the design process.

In general, there are many different levels of tests. In the
well run places I've worked (far from all of them), any errors
found in integration or acceptance tests resulted in an analysis
of the process---they should never occur. On the other hand,
you couldn't check code in that didn't pass the unit tests,
which basically left it entirely up to the developer how he
organized his own work (writing the code and the tests, etc.): I
generally expected my unit tests to run first time (and don't
use a debugger), but others preferred a more interactive
procedure, debugging errors found in the unit tests. On the
whole, however, those who used such techniques tended to take
more time to produce poorer code.

If you use TDD, the tests always fail first time. You add the code to
make them pass.

 

[Phlip]

That's a good way to waste a lot of time, for very little gain. Those
tests don't tell you anything useful.

I'm convinced. I will never write a unit test again. Thanks for the advice!

 

[Phlip]

James Kanze wrote:

If you use TDD, the tests always fail first time. You add the code to
make them pass.

Ian, the rebuttals can be much more simple. For example, consider, "I generally
expected my unit tests to run first time (and don't use a debugger), but others
preferred a more interactive procedure, debugging errors found in the unit tests."

First, put aside the arrant smugness; "I don't use a debugger, but some folks
lean on it". Then notice the actual problem is "fallacy of excluded middle".

How about "I write a test and correctly predict (Without Using a Debugger)
exactly how it will fail. Then I write code to pass the test (WUD), and
correctly predict that it will pass. In the rare event either prediction is
wrong (WUD), I have the options to alter the test (WUD), revert the code change
(WUD), or revert everything (WUD)."

Or is this the wrong kind of WUD, and it should somehow be harder??

 

[Phlip]

TDD tests aren't unit tests.

That's _my_ line!!

 

[Jerry Coffin]

[ ... ]

If you use TDD, the tests always fail first time. You add the code to
make them pass.

This makes me curious. Why would you bother running the tests if you
_know_ they're going to fail? I've always written the tests first, but
then written at least some minimal bit of code that should pass at least
some part of the tests before attempting to run the tests. What's the
point of running the test when you're sure there's no possibility of
even coming close to passing it at all?

 

[Phlip]

This makes me curious. Why would you bother running the tests if you
_know_ they're going to fail?

To make sure they fail exactly the way they predicted. If you cannot predict
correctly, then your mental model of the code's situation is not complete
enough. And that is a very good reason to slow down and not make the change!

(And I am _really_ surprised these old-news threads are still going. They
are like "uses and abuses of Design Patterns" or "how to throw exceptions".
The 1990s lives on, huh?)

I've always written the tests first, but
then written at least some minimal bit of code that should pass at least
some part of the tests before attempting to run the tests. What's the
point of running the test when you're sure there's no possibility of
even coming close to passing it at all?

If you go in extremely tiny steps - one line of test, one line of code - you
are much more stable, and your tests penetrate much deeper into the logic.

I suspect TDD was invented by people doing what you are doing, but using the
Smalltalk code browser. They discovered that run the tests more often, over
smaller changes, got easier. Then they experienced a phenomenon I have since
named "the head eats the tail". They couldn't tell the difference between
writing the next test or the last code, and they were in fact writing new
tests and then passing them with new code. The Smalltalk code browser
apparently makes the One Test Button technique very easy...

 

[Phlip]

The theory is that you write tons of little tests, and you can tell
roughly how close to "done" you are by seeing how many of them pass yet.

What theory is that? Nobody advises leaving a lot of failing tests laying
around...

What you're doing is test-first development (and IMHO is a strong sign of
a great developer), not test-driven development (a misguided methodology
that has sold a lot of books).

Argumentum ad crumenum strikes again!