3 ms·
The Perl that most people write can be parsed just fine. Not true. The example he shows to not be statically parseable is: whatever / 25 ; # / ; die "thi
by andreyf 17y ago
The Perl that most people write can be parsed just fine.
Not true. The example he shows to not be statically parseable is:
whatever / 25 ; # / ; die "this dies!";
(because you need to know the value of `whatever' to parse it)
- nkurz 17y agoI'm not sure I agree with you. You do have a point though: 1) Any programmer who writes this line of code as anything other than a lesson in obfuscation should be taken out and shot. 2) Speaking as a Perl programmer who has maintained others' code, _many_ Perl programmers should be taken out and shot. How about: "Except for pathological constructs that should probably be avoided anyway, the Perl that most people write can be parsed just fine." As I see it, the Perl attitude is that these constructs should be forbidden by social contract rather than by the language itself. Sort of like the farmer who refuses to put a lock on his fuel pumps in case someone really needs to fill a tank in an emergency.
- arohner 17y ago>As I see it, the Perl attitude is that these constructs should be forbidden by social contract rather than by the language itself. In most other languages with "dangerous" constructs, having the dangerous construct usually allows power that isn't possible using only safe constructs. Is it the case that this is useful in some circumstances, or is it just poor design?
- Dove 17y agoIt is useful writing one-shot programs on the command line. Perl's idioms can allow very powerful programs to be written very quickly in very small spaces. But any code that is saved to a file and run more than once should lean a bit more toward clarity of expression. Three rules the pathological counterexample breaks: put parens around your function calls if they might otherwise be ambiguous; put =~ before a regexp if its identity might otherwise be unclear, and for heaven's sake put your line breaks in sensible places. This snippet exists to be pathological, and would quickly lose its ambiguity if written by anyone with reasonable habits of self-expression. I am glad perl allows the balance between ruthless speed for programmer-efficiency and expressive clarity for maintainer-efficiency, for sometimes I write short one-shots and sometimes I write bulletproof modules, and I write many things in between. But don't use habits suited to the former in the latter case. If you do that, perl will shoot you repeatedly until you either improve or shoot yourself. And if you survive, then you will have to deal with the folks who inherit your code.
- tedunangst 17y agoIs 'whatever / 25 ; # / ; die "this dies!";' an example of the perl most people write, or just an example of what perl detractors claim most people write?
- mbrubeck 17y agoYou mean, is real-world code likely to contain a regular expression with a # character, or a comment with a / character following code with a / character? Not all the time, but it doesn't seem terribly outlandish.
- tedunangst 17y agoI think a regex with # in it is common enough, but passed to a one-arg function? And followed on the same line by another statement? No. The example takes several things that could be individually probable and packs them into a single rather unlikely line.
- chromatic 17y agoYou don't need to know its value, only its syntactic type -- in almost all but the most pathological cases, a clever static parser can identify that.