4 ms·

I remain unconvinced. Should the amount of effort that it costs to update the interpreter really be the main consideration?

by ma2rten 14y ago

chromatic 14y ago
As I wrote, it's one of the reasons I use Perl.
jbert 14y ago
> I remain unconvinced. Should the amount of effort that it costs to update the interpreter really be the main consideration? No, it shouldnt. But it's a proxy measure for the engineering and productisation effort which goes in. It's relatively easy to get features in quickly with breakage. It's easy to have stability with no change. It's relatively hard to continuously improve with good reliability and back-compat. Perl was a major leader for automated testing since before TDD was a buzzword. Modern perl is a cool language with a great OO model and a shitty threading system (seriously, use multiproc if you want concurrency or just go async with one of the eventing systems). It has some serious warts (no implicit deref of references, the scalar/list context is arguably more trouble that it's worth) and suffers from an image problem. But it's a bulletproof, fast, widely deployed, portable, actively improving scripting language which doesn't have a lot of the warts of it's competitors (broken lexical scoping, problematic object model, poor performance etc). Oh "and CPAN" (ObMention)
- jleader 14y ago
  I thought implicit deref of references was coming in 5.16 or 5.18, at least in cases where it was unambiguous?
  - chromatic 14y ago
    It's present in 5.14, though the use of hash operators on array references with automatic dereferencing has some weird potential corner cases.
  - jbert 14y ago
    I saw something for 5.16 and'push', but I've not been keeping up with the featureset since 5.10 properly. That's good to know, thanks.
adrianhoward 14y ago
I'm not chromatic - but I don't think that's the point he's trying to make. It's not that the the ability to upgrade the interpreter, and several hundred dependencies, and have several tens of thousands of lines of production work easily is good (although it would be tough to argue that it's bad :-) It's what being able to do that successfully says about the reliability of the perl ecosystem as a whole. The investment the perl community has made over the last ten years in building the best testing infrastructure of any language (seriously - it's damn excellent), and fostering a community that's values stuff working has paid off in spades. My experiences match chromatic's in that it just fracking works.
peterwwillis 14y ago
Not at all. You shouldn't be updating the interpreter unless you have to, and then it should be done through your distro's package management and standard upstream path. The OP seems to think it's a good idea to upgrade his production code to the newest stable interpreter just because it was released. This is a recipe for disaster. Sometimes there are just hidden bugs you don't see until a weird use case blows up your code, and thorough stress testing should be performed after the unit testing to ensure no major surprises after upgrade. The best rule for keeping your software stable is: don't change anything.
- jleader 14y ago
  Your rule ("don't change anything") is also an argument for never adding features! There's a tradeoff here that you're glossing over. Given that each newer version is presumably some amount better than the previous one, eventually the benefits of upgrading will outweigh the costs, at least if you're going to continue making changes to your software. I don't think chromatic was saying "everyone should immediately upgrade to the latest version of Perl". I think he was saying "upgrading to the latest version of Perl isn't as scary/costly as some people think; I did it, and here's my experience." Also, keep in mind that sometimes there are hidden bugs in the old version, too. My employer just ran into a problem with the de-allocation of deeply nested structures being implemented inefficiently in Perl 5.8 (which has been in production for close to a decade); the bug was fixed in 5.14.
- chromatic 14y ago
  The OP seems to think it's a good idea to upgrade his production code to the newest stable interpreter just because it was released. You're putting words in my mouth and knocking down the resulting strawman. I upgraded for Unicode and performance improvements.

I remain unconvinced. Should the amount of effort that it costs to update the interpreter really be the main consideration?

by ma2rten 14y ago

I remain unconvinced. Should the amount of effort that it costs to update the interpreter really be the main consideration?

chromatic 14y ago

As I wrote, it's one of the reasons I use Perl.

jbert 14y ago

> I remain unconvinced. Should the amount of effort that it costs to update the interpreter really be the main consideration? No, it shouldnt. But it's a proxy measure for the engineering and productisation effort which goes in. It's relatively easy to get features in quickly with breakage. It's easy to have stability with no change. It's relatively hard to continuously improve with good reliability and back-compat. Perl was a major leader for automated testing since before TDD was a buzzword. Modern perl is a cool language with a great OO model and a shitty threading system (seriously, use multiproc if you want concurrency or just go async with one of the eventing systems). It has some serious warts (no implicit deref of references, the scalar/list context is arguably more trouble that it's worth) and suffers from an image problem. But it's a bulletproof, fast, widely deployed, portable, actively improving scripting language which doesn't have a lot of the warts of it's competitors (broken lexical scoping, problematic object model, poor performance etc). Oh "and CPAN" (ObMention)

jleader 14y ago
I thought implicit deref of references was coming in 5.16 or 5.18, at least in cases where it was unambiguous?
- chromatic 14y ago
  It's present in 5.14, though the use of hash operators on array references with automatic dereferencing has some weird potential corner cases.
- jbert 14y ago
  I saw something for 5.16 and'push', but I've not been keeping up with the featureset since 5.10 properly. That's good to know, thanks.

adrianhoward 14y ago

I'm not chromatic - but I don't think that's the point he's trying to make. It's not that the the ability to upgrade the interpreter, and several hundred dependencies, and have several tens of thousands of lines of production work easily is good (although it would be tough to argue that it's bad :-) It's what being able to do that successfully says about the reliability of the perl ecosystem as a whole. The investment the perl community has made over the last ten years in building the best testing infrastructure of any language (seriously - it's damn excellent), and fostering a community that's values stuff working has paid off in spades. My experiences match chromatic's in that it just fracking works.

peterwwillis 14y ago

Not at all. You shouldn't be updating the interpreter unless you have to, and then it should be done through your distro's package management and standard upstream path. The OP seems to think it's a good idea to upgrade his production code to the newest stable interpreter just because it was released. This is a recipe for disaster. Sometimes there are just hidden bugs you don't see until a weird use case blows up your code, and thorough stress testing should be performed after the unit testing to ensure no major surprises after upgrade. The best rule for keeping your software stable is: don't change anything.

jleader 14y ago
Your rule ("don't change anything") is also an argument for never adding features! There's a tradeoff here that you're glossing over. Given that each newer version is presumably some amount better than the previous one, eventually the benefits of upgrading will outweigh the costs, at least if you're going to continue making changes to your software. I don't think chromatic was saying "everyone should immediately upgrade to the latest version of Perl". I think he was saying "upgrading to the latest version of Perl isn't as scary/costly as some people think; I did it, and here's my experience." Also, keep in mind that sometimes there are hidden bugs in the old version, too. My employer just ran into a problem with the de-allocation of deeply nested structures being implemented inefficiently in Perl 5.8 (which has been in production for close to a decade); the bug was fixed in 5.14.
chromatic 14y ago
The OP seems to think it's a good idea to upgrade his production code to the newest stable interpreter just because it was released. You're putting words in my mouth and knocking down the resulting strawman. I upgraded for Unicode and performance improvements.