Perl: panic! or stay with Perl, and re-engineer? - No Programming language is perfect - Strongly Type Languages might NOT have less bugs
GEP Launcher is/was some old x86 program, which was in an unfortunate manner, revealed to be written in Perl.
Perl is a much maligned language, something like JavaScript, without the good parts. There is no compiler which in itself has the advantage to shorter iteration times during development, but then all checks and validations are performed only when the program is actually running. Originating in a lax kind of West Coast environment, Perl kind of "sits by the poolside" and lets you do what you want, no matter the consequences. A running joke is that almost anything can be interpreted by Perl: so, something like Regular Expressions, the code can be easy to write, but hard to read. And it's generally agreed that developers spend far more time reading than writing code.
Unfortunately for fans of particular programming languages, it is difficult to objectively measure the prevalence of bugs with a particular language. Reports abound of how buggy C++ projects tend to be, but other factors may skew the result: the huge quantity of code, the older age of C++ codebases, the poorer tools and hardware used to build such older code-bases. At least one study has been publicly criticized for failing to allow for other factors when evaluating any association between languages and bugs.
In an ideal world, selecting a newer and in theory better designed language should result in higher quality code with less bugs. However, coding is craft, and there is no substitute for good discipline and best practices such as code review, unit testing, refactoring and periodically reviewing code for architectural and quality issues. Like any product of design, there is no silver bullet for a quality product.
One such failed example to establish that more modern languages are associated with fewer bugs, was discredited at the Curry On London conference of 2019, by Jan Vitek. There is not much strong evidence that languages or stronger typing improves software quality. The
biggest differences seem to be between individual developers. A stronger factor than langauge choices, seems to be hours worked and how well the work is managed - for example, crunch time as commonly practiced in the games industry, notoriously leads to quality issues and delays. The paper in question is unfortunately widely quoted and to my knowledge has STILL not been retracted by the authors. Vitek describes many serious problems and mistakes made with the data used, including but not limited to: 'ts' files included, from before TypeScript was invented, volume of codebases not allowed for (so, older more populous languages like C++ are misrepresented as high in bugs).
So, let's have some compassion for our brothers and sisters in arms who are on the front lines, armed only with Perl. Crashes such as the above may be a case for catastrophic failure or a case for rebuild, depending on the code quality, presence of automated tests, available budget, and other factors...
It's Perl: time to panic, indeed? OR time for better software engineering practices...
Relevant reading could include Elements of Programming - “Ask a mechanical, structural, or electrical engineer how far they would get without a heavy reliance on a firm mathematical foundation, and they will tell you, ‘not far.’
Related: a recent report from VeraCode on the same old topic of languages-by-bugs, but interestingly ends with a recommendation of "nature over nurture" - so, the original choice of language for a codebase need not be a fatal error!
Related: some articles on the problems around Crunch Mode/Crunch Time - which may be more important to avoid than old languages!
http://chadfowler.com/2014/01/22/the-crunch-mode-antipattern.html
https://www.infoq.com/news/2008/01/crunch-mode/
Why Crunch Modes Doesn't Work: Six Lessons - International Game Developers Association (IGDA) https://www.igda.org/page/crunchsixlessons
Comments
Post a Comment