Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Why exactly is C supposed to be better than Perl for large systems (ignore speed of execution, assume that both can in principle satisfy your requirements)? What large-scale development advantages does it, as a language, have? What if you had raised an incredulous eyebrow and asked this gentleman, "you write large systems in *C*???" What would his response have been?

    It's kind of the thing I (try to) have in mind when I hear the word "enterprise". When a system gets big enough and lasts long enough, the

    • C is better for generating Heisenbugs. Which fact alone makes me strongly dislike it for large projects.

      Heisnbugs are trivial bugs that show up in one part of your code, will move around as you recompile for different platforms, change unrelated code, etc, will often disappear for an extended time, and then will pop up when you least expect it.

      The most common cause is a bad pointer, causing a fairly random point in memory to get overwritten. If that point has nothing particularly important, then everything seems to work. The code that is dangling the data seems to work as well. But if the point in memory is actually used for something important, then something else breaks. No, nothing that will help you track down the dangling pointer, just..something. And since trivial code changes (or compiling against different libraries, or on a different OS, or with different optimization conditions...) causes memory layout to change, the bug will apparently appear and disappear based on changes that have nothing to do with the real bug.

      Yes, any decent programmer can avoid these in a small program. But the average in commercial software is one bug per thousand lines. If your project has over 100,000 lines, you really want your bugs to be localizable if you're going to track them down. But at least one common error in C is not localizable.

      (Yes, I know about tools like Purify and so on. They are bandaids. Useful bandaids. Essential bandaids. But automated reasoning about code is still not as good as making the problems impossible at the outset.)