kuyper@wizard.net ("James Kuyper Jr.") wrote
> Pete Becker wrote:
> > There are many things that sloppy programmers can do by accident. There
> > is very little that they can do right. They might produce code that runs
> > the way they expect. There's a long distance from there to code that's
> > right.
>
> It isn't necessarily a long distance, or even any distance at all.
> Sometimes code which runs exactly the way they expect, happens purely by
> chance to also be code that's right, even though they don't know enough
> about the system to ensure that result.
>
> In the case of rand(), I'd even argue that it's pretty easy to do so.
> I've seen quite a few situations where non-default seed initialization
> was completely unimportant. Not serious scientific simulations, of
> course - but not all uses of rand() are as demanding as that. In my
> experience, most of the situations where non-default seed initialization
> is called for, are also situations that call for a more reliably useful
> randomizer than rand().
>
> > ... But how can a programmer who doesn't
> > know about srand determine that it's not needed?
>
> He doesn't; he can achieve correctness only by accident. I was rebutting
> your claim that the knowledge was necessary to achieve correctness; it
> isn't - in the absence of knowledge, an accident can achieve the same thing.

As I understand it, your conflict can be boiled down to this:

   Imagine that some program needs rand(), but should not use srand()
   for some reason -- perhaps because the results need to be
   repeatable. Bad programmers don’t even know about srand(), so of
   course they won’t use it. Is it possible for a bad programmer to
   write a good program?

You're both making an unwarranted assumption: that there are good
programmers and bad programmers, at least with respect to their
knowledge of C++. If that was true, then all you would have to do to
prevent all coding errors is hire good programmers (except that
James admits a bad programmer can write a good program "purely by
chance" although he has no way of knowing that he has done so).

I don’t suppose you believe that a “bad programmer” ever gets a
sudden flash of knowledge, turning into a “good programmer” without
any sort of transition. Perhaps you recognize that not all
programmers are at the extremes. Perhaps you imagine an entire
spectrum of programmers, like a rainbow, with expert C++ programmers
at one end, and total novices at the other, and most ordinary
programmers somewhere in between.

Fellows, it isn't a rainbow. It's more like a tapestry. One
programmer may understand the STL much better than another, while
the second understands inheritance much better than a first. Meanwhile,
both of them are better-than-average at understanding what magic goes on
in a new-expression, and both of them are rather weak with
documentation skills and at designing useful user interfaces.

C++ has the advantage of being multi-paradigm. As you know, that means
that the language is flexible enough to accommodate different coding
styles. But more than that, it also means that you can be experts on
one feature and know little or nothing about others.

The particular topic of rand / srand is fantastically easy to teach
(although greater related issues such as "how random is random" and
"why rand()%3000 tends to give skewed results" can be more complicated).
The result is, I can take a reasonably bright person who has never heard
of either function before, and make them an expert *in that topic* in a
very short time (perhaps an hour). Of course, after this hour they still
won't necessarily understand why "i = i++ + ++i;" is undefined behavior.

My point here (yes, I do have a point!) is that it's ridiculous to say
things like, "[They wrote code that] happens purely by chance to ...be
code that's right, even though they don't know enough about the system
to ensure that result." Non-trivial code never happens by accident. Given
a 1-hour lecture on the topic of rand/srand, I can produce programmers
who can indeed ensure that their code is absolutely right in that respect.

You don't need to be an expert on every C++ feature, in order to write
correct programs in the language. Indeed, Stroustrup himself advocates
using C++ as a "better C" without necessarily understanding all of the
additional benefits that C++ can provide (at least, he used to take
this position and I assume he still does).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]