3 ms·

That's a problem with the people who wrote the script, though, not the language itself. Consider the difference between a minified JS script or one produced wi

That's a problem with the people who wrote the script, though, not the language itself. Consider the difference between a minified JS script or one produced with emscripten and the code pre-minification. One is unintelligible guaranteed, the other … maybe haha. Unfortunately, what tended to happen is people would write one liners, and slowly expand the one liners into more complex one liners, and then integrate them into larger scripts without refactoring. Regex can triple that problem (thankfully Perl 6 allows you to write some of the most intelligible — seriously! — regex out there).

kjs3 7y ago
That's a problem with the people who wrote the script, though, not the language itself. That's like the folks who say "the problem with C (buffer overflow, UB, etc.) isn't C, it's the people who write C". Which leads to at some point contemplative folks deciding either "this is happening so often, maybe it is the language" or "the majority of people writing this language are incompetent". While I've heard plenty of people in the C community espouse the latter view, having written C since K&R days, I think most people acknowledge it's a problematic language. But I don't have empirical evidence of a ratio. I wrote a ton of Perl <=5 back in the day. I'm pretty sure I know why I thought it was a good idea at the time. I know where I fall on the above. I know why I, and virtually everyone I know professionally, don't solve problems in Perl any more. But hey...maybe I'm just incompetent.
- empath75 7y ago
  About the ten millionth time that someone had a security breach from exposing s3 buckets aws decided to look into if maybe something in their UX was bad instead of blaming the user every time. ‘User error’ is rarely a sufficient explanation for why something negative happens, particular when those users are professionals using a professional product. At some point one needs look at whether there is something in the product that causes those errors to happen or that doesn’t do enough to prevent them.
  - Grinnz 7y ago
    Both things are true: it's probably the user's fault, and it should be made more foolproof.
- alabamenhu 7y ago
  90% of Perl's line noise comes from using short cute variable names and trying to cram way too much into way too compressed regexes. There's nothing inherent about Perl that causes people to use $z instead of $somethingDescriptive. And regexes have for quite some time allowed for insignificant whitespace to comment things in detail. If you comment your regexes and use decent variable names, you solve 98% of the readability problems of Perl, and both of those could be enforced with a linter. But as I said, a lot of the problems come from one liners being slowly expanded. Using single letter var names for anything is fine in a one liner, but not good for long term program legibility or maintance in any language.

kjs3 7y ago

That's a problem with the people who wrote the script, though, not the language itself. That's like the folks who say "the problem with C (buffer overflow, UB, etc.) isn't C, it's the people who write C". Which leads to at some point contemplative folks deciding either "this is happening so often, maybe it is the language" or "the majority of people writing this language are incompetent". While I've heard plenty of people in the C community espouse the latter view, having written C since K&R days, I think most people acknowledge it's a problematic language. But I don't have empirical evidence of a ratio. I wrote a ton of Perl <=5 back in the day. I'm pretty sure I know why I thought it was a good idea at the time. I know where I fall on the above. I know why I, and virtually everyone I know professionally, don't solve problems in Perl any more. But hey...maybe I'm just incompetent.

empath75 7y ago
About the ten millionth time that someone had a security breach from exposing s3 buckets aws decided to look into if maybe something in their UX was bad instead of blaming the user every time. ‘User error’ is rarely a sufficient explanation for why something negative happens, particular when those users are professionals using a professional product. At some point one needs look at whether there is something in the product that causes those errors to happen or that doesn’t do enough to prevent them.
- Grinnz 7y ago
  Both things are true: it's probably the user's fault, and it should be made more foolproof.
alabamenhu 7y ago
90% of Perl's line noise comes from using short cute variable names and trying to cram way too much into way too compressed regexes. There's nothing inherent about Perl that causes people to use $z instead of $somethingDescriptive. And regexes have for quite some time allowed for insignificant whitespace to comment things in detail. If you comment your regexes and use decent variable names, you solve 98% of the readability problems of Perl, and both of those could be enforced with a linter. But as I said, a lot of the problems come from one liners being slowly expanded. Using single letter var names for anything is fine in a one liner, but not good for long term program legibility or maintance in any language.