5 ms·

>> [Perl is unmaintainable] You need coding standards for all languages. Most (afaik) Perl shops use Conway's "Perl Best Practices" with some local changes. Go

>> [Perl is unmaintainable] You need coding standards for all languages. Most (afaik) Perl shops use Conway's "Perl Best Practices" with some local changes. Go read "Modern Perl" etc. Are you not aware of those developments? PBP isn't exactly new. I don't think there are references of these problems while following good practices? Considering all the trolls which show up when Perl is mentioned, I ought to have seen such a link a long time ago... But sure, we could assume without support (I don't know) that using Perl forces you to read a few more pages of coding standards. That is, as percentage of work time over a long project, not a problem. >> [Go preaching] Today, I don't see much practical difference among the usual scripting languages (they tend to port the successful stuff from each others). Also their niches are partly different compared to the niches for Go. So there is no need to preach. One big advantage with Perl is that I am not often embarrassed by fan boys and/or language war fanatics, as you find in some other environments... Edit: Readability.

reality_czech 13y ago
What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them? Why would you use a language if you don't agree that the designers did a good job? That's like going to a burger joint and ordering a salad. Only someone hell-bent on maintaining an emotional connection to a worn-out old programming language, would even consider that. I've never seen a project that could enforce its coding standards in every case. Things always slipped through. Turns out, machines are much better at enforcing arbitrary coding standards than humans. Maybe we should let the machines do the machines' job, and the humans do the humans' job. Perl has all the problems of an old language. No commonly-agreed on coding style (you'll get flamed to a crisp in some parts for even talking about Modern Perl), no single object framework (Moose, Class::Accessor, Object::Tiny, Role::Tiny, and plain old "inside out object." References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references). All the various different ways that things can fail at runtime are a huge burden, especially when you combine them with the different modes that perl itself can be run in, like "use strict" versus not. Just about the only thing Perl did right was regular expressions. That, and avoiding the version hell that Python got itself into. Perl was fun in the early 90s, but it's time to let go. Only a masochist would use it today. Only a sadist would recommend it to newcomers.
- kbenson 13y ago
  What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them? Because the real world comes with edge cases. Just because 99 times out of 100 you're better off with the agreed upon standard, doesn't mean that other way doesn't have it's distinct time and place that it can shine, and clearer, cleaner and or faster. I would much rather be constrained by convention than by capability. no single object framework No, but the reason for that's been a good one historically (experiment and see what comes out on top). That ended up being Moose and it's ilk (Moo, Mouse). I can't think of a single case I've heard about where people used something else and it wasn't driven by some external factor. References are confusing and unnecessary I've always liked references. It seems to make clear exactly what's going on. Maybe it's just me.
- __david__ 13y ago
  > References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references). Perl references combined with its nested list semantics make it extremely convenient to flatten arrays and hashes when you need to. Doing the equivalent in Python and Ruby is verbose and ugly by comparison. I know in Ruby you can get it down to one line, but it lacks the cleanliness of Perl (if you can believe that).
  - reality_czech 13y ago
    Flattening an array is trivial in Ruby: [[1, 2, 3], 4, 5].flatten() I don't see how it could possibly be made easier or more intuitive than a single function call. Ruby also makes it clear what is going on.
    - __david__ 13y ago
      That flattens everything. In Perl it's trivial to flatten just the parts you need to and leave other nestings intact.
- einhverfr 13y ago
  > What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them? Two points in this. You might not want to ban all 99 in all cases. For example, you may want to do things one way in one aspect of a project and a different way in a different aspect. This sounds dangerous (and power is dangerous), but done right it allows teams to focus on doing things right with the right interfaces between them. For example, it's one thing to contribute to Moo, Moose, and PGObject in one way, but have a different coding convention internally for the programs which use these libraries. This is where those other 99 ways really come to be powerful. > Why would you use a language if you don't agree that the designers did a good job? I like the design of Perl 5. However, it took a lot to get to the point where I saw the beauty in it, and saw how to use the power properly. In a larger project however, that's not so much of a problem. Once you get the core code started, people can grow within it. Different levels of the project may handle things differently, and that's fine. People can branch out over time. > I've never seen a project that could enforce its coding standards in every case. And sometimes the responsible decision is to let the coding standards violation occur and plan to fix it later. There are times I have done that and regretted it, only to later realize it was a net positive anyway. > Maybe we should let the machines do the machines' job, and the humans do the humans' job. Absolutely. Now to tell which is which. > Perl has all the problems of an old language. Evidently every 5 years or so we need to all jump on the bandwagon to a new language? > No commonly-agreed on coding style (you'll get flamed to a crisp in some parts for even talking about Modern Perl), no single object framework (Moose, Class::Accessor, Object::Tiny, Role::Tiny, and plain old "inside out object." There are lots of object structures but you probably shouldn't list Role::Tiny there. The basic point there is you have Moose, of which Mouse was an attempt to make it smaller for performance sensitive applications (now largely superceded by Moo). Role::Tiny is an attempt at a minimalist piece of Moose aimed at specific applications. Moo/Moose/Role::Tiny are best thought of as aspects of a single object system rather than separate ones. In fact Moo and Role::Tiny were authored by the same individual. The Perl world has largely gone to Moose and friends. Pretty much everyone that uses anything else does so for legacy reasons or external constraints IME. > References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references). And yet I have been bitten by the lack of such a distinction in Python. > All the various different ways that things can fail at runtime are a huge burden, especially when you combine them with the different modes that perl itself can be run in, like "use strict" versus not. Meh, my test cases in any language use up more code than my production code anyway. There is no substitute for clear code contracts.

reality_czech 13y ago

What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them? Why would you use a language if you don't agree that the designers did a good job? That's like going to a burger joint and ordering a salad. Only someone hell-bent on maintaining an emotional connection to a worn-out old programming language, would even consider that. I've never seen a project that could enforce its coding standards in every case. Things always slipped through. Turns out, machines are much better at enforcing arbitrary coding standards than humans. Maybe we should let the machines do the machines' job, and the humans do the humans' job. Perl has all the problems of an old language. No commonly-agreed on coding style (you'll get flamed to a crisp in some parts for even talking about Modern Perl), no single object framework (Moose, Class::Accessor, Object::Tiny, Role::Tiny, and plain old "inside out object." References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references). All the various different ways that things can fail at runtime are a huge burden, especially when you combine them with the different modes that perl itself can be run in, like "use strict" versus not. Just about the only thing Perl did right was regular expressions. That, and avoiding the version hell that Python got itself into. Perl was fun in the early 90s, but it's time to let go. Only a masochist would use it today. Only a sadist would recommend it to newcomers.

kbenson 13y ago
What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them? Because the real world comes with edge cases. Just because 99 times out of 100 you're better off with the agreed upon standard, doesn't mean that other way doesn't have it's distinct time and place that it can shine, and clearer, cleaner and or faster. I would much rather be constrained by convention than by capability. no single object framework No, but the reason for that's been a good one historically (experiment and see what comes out on top). That ended up being Moose and it's ilk (Moo, Mouse). I can't think of a single case I've heard about where people used something else and it wasn't driven by some external factor. References are confusing and unnecessary I've always liked references. It seems to make clear exactly what's going on. Maybe it's just me.
__david__ 13y ago
> References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references). Perl references combined with its nested list semantics make it extremely convenient to flatten arrays and hashes when you need to. Doing the equivalent in Python and Ruby is verbose and ugly by comparison. I know in Ruby you can get it down to one line, but it lacks the cleanliness of Perl (if you can believe that).
- reality_czech 13y ago
  Flattening an array is trivial in Ruby: [[1, 2, 3], 4, 5].flatten() I don't see how it could possibly be made easier or more intuitive than a single function call. Ruby also makes it clear what is going on.
  - __david__ 13y ago
    That flattens everything. In Perl it's trivial to flatten just the parts you need to and leave other nestings intact.
einhverfr 13y ago
> What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them? Two points in this. You might not want to ban all 99 in all cases. For example, you may want to do things one way in one aspect of a project and a different way in a different aspect. This sounds dangerous (and power is dangerous), but done right it allows teams to focus on doing things right with the right interfaces between them. For example, it's one thing to contribute to Moo, Moose, and PGObject in one way, but have a different coding convention internally for the programs which use these libraries. This is where those other 99 ways really come to be powerful. > Why would you use a language if you don't agree that the designers did a good job? I like the design of Perl 5. However, it took a lot to get to the point where I saw the beauty in it, and saw how to use the power properly. In a larger project however, that's not so much of a problem. Once you get the core code started, people can grow within it. Different levels of the project may handle things differently, and that's fine. People can branch out over time. > I've never seen a project that could enforce its coding standards in every case. And sometimes the responsible decision is to let the coding standards violation occur and plan to fix it later. There are times I have done that and regretted it, only to later realize it was a net positive anyway. > Maybe we should let the machines do the machines' job, and the humans do the humans' job. Absolutely. Now to tell which is which. > Perl has all the problems of an old language. Evidently every 5 years or so we need to all jump on the bandwagon to a new language? > No commonly-agreed on coding style (you'll get flamed to a crisp in some parts for even talking about Modern Perl), no single object framework (Moose, Class::Accessor, Object::Tiny, Role::Tiny, and plain old "inside out object." There are lots of object structures but you probably shouldn't list Role::Tiny there. The basic point there is you have Moose, of which Mouse was an attempt to make it smaller for performance sensitive applications (now largely superceded by Moo). Role::Tiny is an attempt at a minimalist piece of Moose aimed at specific applications. Moo/Moose/Role::Tiny are best thought of as aspects of a single object system rather than separate ones. In fact Moo and Role::Tiny were authored by the same individual. The Perl world has largely gone to Moose and friends. Pretty much everyone that uses anything else does so for legacy reasons or external constraints IME. > References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references). And yet I have been bitten by the lack of such a distinction in Python. > All the various different ways that things can fail at runtime are a huge burden, especially when you combine them with the different modes that perl itself can be run in, like "use strict" versus not. Meh, my test cases in any language use up more code than my production code anyway. There is no substitute for clear code contracts.