[off-topic] Sony releases PS Vita SDK

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Apr 20 13:56:57 PDT 2012


On Fri, Apr 20, 2012 at 02:45:51PM +0200, SomeDude wrote:
[...]
> Oh yeah, I've seen that story too in a couple of other places. C++
> seems to make exceptionnally easy for "mad coders" to screw up a
> whole system with overengineered pieces of crap. One of my
> colleagues spent more than a year rewriting a system that turned
> into a black box that nobody could maintain.
> 
> My opinion is, when a team works in this language, code reviews
> should be an obligation, else there is always a guy like that, who
> has his genius idea that nobody else understands and puts his crap
> all over the place. Basically, the only piece of C++ software I've
> seen that never became a huge piece of steaming crap was a system
> that was systematically code reviewed by the main software architect
> and a couple of highly skilled engineers.

The problem is, code review is a full-time job if it is to be done
properly. Often it just deteriorates into a side-job: senior coder A
reviews junior coder B's code, but coder A has a pending deadline that
week and has lots of complex code issues to tackle, so there's no time
to read through everything that coder B wrote. So just glance over it
briefly, if there are no blatant problems, approve it.

It gets worse if senior coder A himself doesn't have a good grasp of
good coding practices, but got to where he is because he's just very
good at last-minute patchwork hacks that makes everything "work".
Seniority gives him code review rights, but he's really not qualified
for the job.


> I suspect D is not much better on this topic, it's possible to write
> extremely complex code with it too. Actually, it's possible to write
> complex and unmaintaineble stuff in any language (even in Python),
> but I believe the more complex the language, the easier it is to
> screw things up and the more important code reviews are.

Problem is, good coders are hard to come by. It's even harder to
distinguish between coders who succeed because they practise sound
coding principles, and coders who "succeed" because they're good at
hacking things at the last minute to make them work.

>From a business perspective, the latter are actually (implicitly)
preferred, because what project manager wants coders who are hesitant
and cautious about making changes when there's an impending deadline of
doom imposed by irate customers who want the product shipped by last
week? No, they want coders who can make it work, right now, no matter
what the means. Who cares about the consequences, what's important is
Big Customer A's trivial bug must be fixed This Very Minute before we
lose the multi-million dollar contract to a competitor. Use the ugliest,
dirtiest, cruelest hacks if you must, the ends justify the means. Is it
any wonder that so many large commercial software projects are crap?

But anyway, I'm veering off-topic.

The point is that C++ has too many features that are unsafe by default,
or require the programmer to manually do too many things before it works
correctly. Like that dreaded ctor, copy ctor, and assignment operator
trio. For the most trivial of classes you need to (at least) provide
boilerplate versions of all three, all correctly implemented. Forget
some minor detail? No problem, the class will still "mostly" work. Any
effects are hard to notice. Until somebody tries to do something that
you didn't anticipate, and suddenly there are breakages everywhere.

This is one of the many areas where D shines: the default behaviour is
safe and generally correct, and you add more code if you want to fine
tune stuff. Not like C++ where failing to add certain pieces of
boilerplate code results in broken-by-default behaviour.


T

-- 
Latin's a dead language, as dead as can be; it killed off all the
Romans, and now it's killing me! -- Schoolboy


More information about the Digitalmars-d mailing list