Comment Re:We banned Perl (Score 1) 126
I don't ascribe the bad code to the language, but to the bad developers.
Unfortunately, Perl limits even good developers.
The major problem I have with Perl is not its sometimes ugly syntax, but rather its limited mechanisms for enforcing code correctness at compile time. This means that many types of error can't be found until one runs a program. This in turn means one runs up against the classic combinatoric explosion problem associated with run time testing. Given that even the best developers have bad days, this can be a big problem.
Perl is a lot like Visual Basic, or spreadsheet languages, in this sense.
Languages such as Java, C#, C++, Ada, VHDL, SystemVerilog, and many others all provide a much stronger level of support for checking things at compile time. This can even be done to some extent in a really old language like C, with tools such as the mainstream lint tool, and the many lint extensions that are available or which can be readily written.
As a bonus, many of these mechanisms to exist to support compile time checking of code make reading other people's code easier (and with modern development tools, they also make modifying that code to help understand it easier).
With Perl, "use strict" gives you a little bit of this, but it really doesn't compare to what is possible in other languages. Even modern Perl extensions such as Moose are pretty limited in comparison to what can be done in other languages. In the final analysis making smart compilers and other tools for code checking depends on the type system the language implements, and Perl falls short.
I don't think Larry Wall understood this (if he had done his research, he would have, since Ada had been around for several years when Perl was created, and even then -- 1987 -- these issues were well understood), and I don't think most Perl programmers understand it either to this day.
Perl also has the problem that it's difficult to parse, so a coding team has to have pretty strict standards regarding language use if it's going to be developing code checking tools. Hence, the "there's more than one way to do it" concept in the design of the language actually creates a serious problem for users of the language, because it complicates the problem of parsing the language (and there's no built-in parser that can readily be customized for use in writing a code checking tool).
It would have been better to have strong type checking be the default, with a more limited syntax, then let the user relax the strictness when desired (sort of like using Java and Groovy together, getting the benefits of a scripting language when appropriate, but also getting the benefits of a well thought out language).
As a result of this issue, I prefer not to use Perl for anything more than 5-10 pages in length. In such a short program, it's not that bad to review the code, fully understand it, and test it. Within those limits, it's a useful tool.