to code or not to code?

[Kevin Buettner]

On Jul 24,  2:54pm, Jonathan Furrer wrote:

> Hmmmm, thats a documentation thing. If you don't document C++ for example
> you can find yourself in just as much hurt and pain. I spent an entire
> nite waisted on going back through some code a group mate wrote and trying
> to figure out what the hell he was doing. I also commented his code for
> him afterward, and he seems to get the point now. But the truth here is
> that regarding any language, OOP, Procedural, etc. If you fail to comment,
> and follow style rules, you have a mess to understand the next day.

Since we're telling stories...

At a company that I used to work at (which shall remain nameless), I
rewrote a 1000+ line C++ program that was killing performance in about
20 lines of Perl.  The Perl code was easier to understand and was several
orders of magnitude faster than the original C++ program.

It was unfortunate that my employer was unwilling to deploy a Perl
based solution at the time.  (Once I'd written a few more scripts,
they changed their mind.)  I ended up rewriting my Perl script in about
200 lines of C.  (And gained another order of magnitude in performance.)

Lessons learned:

 - Perl is not necessarily slower than C/C++.

 - A language (like Perl) with great expressive power will usually result
   in more compact, more easily understood code.

 - It is easy to write terrible C++ code.