The BBC, the world’s largest broadcaster, had Perl everywhere. They decided to ditch it. MongoDB claims that their clients aren’t developing any new projects in Perl, so they’re ditching Perl 5 support. Other companies are continuing this trend and this is, as potential clients have told me, because they’re tired of waiting for Perl 6. They think Perl 6 is the successor to Perl 5 and given the name, it makes perfect sense. Combine that with the negative press about Perl 5 and you get into “nobody got fired for buying IBM” territory, but
s/Perl/$other_language/g.
Tag Archives: coding practices
Computer program fixes old code faster than expert engineers
From there, the Helium system then replaces the original bit-rotted components with the re-optimized ones. The net result: Helium can improve the performance of certain Photoshop filters by 75 percent, and the performance of less optimized programs such as Microsoft Windows’ IrfanView by 400 to 500 percent.
“We’ve found that Helium can make updates in one day that would take human engineers upwards of three months,” says Amarasinghe. “A system like this can help companies make sure that the next generation of code is faster, and save them the trouble of putting 100 people on these sorts of problems.”
Source: Computer program fixes old code faster than expert engineers | MIT News
Having the ability to automatically fix bad code is like when they introduced auto focus on cameras to automatically fix bad focus or auto tunes to fix bad singing. The downside might be that development chooses to do less code reviews releasing more bad code into the wild relying on these automatic techniques to fix everything.
Here’s another article recently published by MIT News about this concept.
Remarkably, the system, dubbed CodePhage, doesn’t require access to the source code of the applications whose functionality it’s borrowing. Instead, it analyzes the applications’ execution and characterizes the types of security checks they perform. As a consequence, it can import checks from applications written in programming languages other than the one in which the program it’s repairing was written.
Source: Automatic bug repair | MIT News
Things You Should Never Do, Part I – Joel on Software
There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
It’s harder to read code than to write it.
via Things You Should Never Do, Part I – Joel on Software.
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
The Underhanded C Contest
The goal of the contest is to write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil. Every year, we will propose a challenge to coders to solve a simple data processing problem, but with covert malicious behavior. Examples include miscounting votes, shaving money from financial transactions, or leaking information to an eavesdropper. The main goal, however, is to write source code that easily passes visual inspection by other programmers.
What’s preferable: Exceptions or explicit error testing?
Just show me one learner’s book where error handling is rigorously designed from the start and consequently used through all the examples, without being left out for brevity and readability and as exercise for the reader. If this is applicable from an educational POV, that is another question, but it’s no surprise that error handling is often enough a second or third thought when it should be the very first.
via What’s preferable: Exceptions or explicit error testing? | Ars Technica.