3 ms·

Perl gives you plenty of rope to hang yourself with. That isn't a good thing in any language.

yellowapple 10y ago
Sure, but it ain't a "bad thing", either. It's just a thing about Perl, neither good nor bad. It's pretty easy to avoid self-asphyxiation in Perl, and that rope can be used to tie all sorts of knots other than just nooses.
- PeterisP 10y ago
  It is a bad thing, since while it usually is easy to avoid self-asphyxiation, when given enough rope to hang themselves people invariably use it. When I've had to read/bugfix/adapt Perl code, most of the time all the bad things people say about Perl were there, that's just the way how the world works, that's how people are. The same applies for other languages. Get a task for maintaining random C code, you will have to fix memory handling problems; get a task for maintaining random JavaEJB code and you will invariably see unreasonable extra layers of indirection added; get a task for maintaining random Perl code, and you will have readability problems. For maintainability, you want something that prevents people from tying all sorts of interesting knots whenever standard, idiomatic solutions can be used.
  - yellowapple 10y ago
    I'd rather have enough rope to hang myself than not enough rope to climb a mountain. "When I've had to read/bugfix/adapt Perl code, most of the time all the bad things people say about Perl were there, that's just the way how the world works, that's how people are." This might very well be confirmation bias. If code needs fixed, it's unlikely to be high quality to begin with. The similar examples for other languages demonstrate this effect. Really, all languages have their strengths and weaknesses. In Perl's case, its strengths also happen to be its weaknesses. :) "For maintainability, you want something that prevents people from tying all sorts of interesting knots whenever standard, idiomatic solutions can be used." True, but when standard, idiomatic solutions don't exist for the problem you're trying to solve, being able to tie interesting knots is a lot better than being totally out of luck. One of Perl's underlying philosophies is "Easy things should be easy; hard things should be possible". There are some things that really could and should be easier (FFI being among them: without installing third-party packages, the "recommended" way is to splay open Perl and start fiddling with its C internals, which is absolutely absurd; something like FFI::Platypus really ought to be included by default), but Perl has an "anything is possible" mentality that is invaluable for solving hard problems.

Sure, but it ain't a "bad thing", either. It's just a thing about Perl, neither good nor bad. It's pretty easy to avoid self-asphyxiation in Perl, and that rope can be used to tie all sorts of knots other than just nooses.

PeterisP 10y ago
It is a bad thing, since while it usually is easy to avoid self-asphyxiation, when given enough rope to hang themselves people invariably use it. When I've had to read/bugfix/adapt Perl code, most of the time all the bad things people say about Perl were there, that's just the way how the world works, that's how people are. The same applies for other languages. Get a task for maintaining random C code, you will have to fix memory handling problems; get a task for maintaining random JavaEJB code and you will invariably see unreasonable extra layers of indirection added; get a task for maintaining random Perl code, and you will have readability problems. For maintainability, you want something that prevents people from tying all sorts of interesting knots whenever standard, idiomatic solutions can be used.
- yellowapple 10y ago
  I'd rather have enough rope to hang myself than not enough rope to climb a mountain. "When I've had to read/bugfix/adapt Perl code, most of the time all the bad things people say about Perl were there, that's just the way how the world works, that's how people are." This might very well be confirmation bias. If code needs fixed, it's unlikely to be high quality to begin with. The similar examples for other languages demonstrate this effect. Really, all languages have their strengths and weaknesses. In Perl's case, its strengths also happen to be its weaknesses. :) "For maintainability, you want something that prevents people from tying all sorts of interesting knots whenever standard, idiomatic solutions can be used." True, but when standard, idiomatic solutions don't exist for the problem you're trying to solve, being able to tie interesting knots is a lot better than being totally out of luck. One of Perl's underlying philosophies is "Easy things should be easy; hard things should be possible". There are some things that really could and should be easier (FFI being among them: without installing third-party packages, the "recommended" way is to splay open Perl and start fiddling with its C internals, which is absolutely absurd; something like FFI::Platypus really ought to be included by default), but Perl has an "anything is possible" mentality that is invaluable for solving hard problems.