4 ms·

Not having to deal with copious amounts of accidental complexity needlessly introduced by the language? Just look at the example on the o'reilly page for the Pe

by sreque 16y ago

Not having to deal with copious amounts of accidental complexity needlessly introduced by the language? Just look at the example on the o'reilly page for the Perl Best Practices book which is linked to by this article. In Perl, there's more than one way of creating file handles, and one of them is the older and less effective way. What a useless fact I have to memorize! Perl was actually the first dynamic language I learned, and when I looked online to see how to open a file, I found the old way first. Later on, I was like, "Hey! How do I pass this $@($*& thing to a function!?" So I looked online and found several competing ways to do it. I first learned of the OO way of doing it, but that required rewriting a lot of code. Then I discovered the syntax required to assign your file to a normal variable, which required me only to add sigils to my code! Unfortunately, I never got so far in my newbiedom as to learn the syntax for passing typeglobs around. This page describes the madness so wonderfully as a "perl recipe": http://docstore.mik.ua/orelly/perl/cookbook/ch07_17.htm http://docstore.mik.ua/orelly/perl/cookbook/ch07_17.htm. Yum! And, of course, Steve Yegge describes what I'm saying much better at http://sites.google.com/site/steveyegge2/ancient-languages-perl http://sites.google.com/site/steveyegge2/ancient-languages-p...: "There are no rules, no heuristics, no patterns. It's pure memorization. Commit the Perl Periodic Table of the Operators to memory, and you're officially 1/1000th of the way down the road to Perl Zombiedom. "

chromatic 16y ago
I don't know what to tell you other than if you deliberately write clunky code, you'll have trouble understanding and maintaining it. Passing typeglobs around isn't modern Perl; it hasn't been necessary for over a decade (to be specific, it hasn't been necessary since 22 March 2000). ... and I know Steve and I like Steve, but I wouldn't take medical advice from him either for much the same reason.
- sreque 16y ago
  Steve may not be a medical doctor, but he is a programming language expert, so I really don't get your ad hominem refutation of what he said about Perl. Perhaps you can comment on what he actually said, not who he is? Also, I think you missed the entire point of my post, including the example. I'm also not sure of how else to word it to help you get it. My point was that Perl requires you to deal with a host of issues that have nothing to do with solving your actual computing problem. One simple example of these many thousand idiosyncracies, which the article itself indirectly brings up, is Perl file handles. Even if you know the "modern" way of using them, you still had to go through the learning process to differentiate between the old and new styles, and you still have to commit a bunch of useless facts to memory. Worse, you may still encounter and have to deal with the old way in the wild! I love the description of the perl5i CPAN module at http://search.cpan.org/~mschwern/perl5i-v2.2.2/lib/perl5i.pm http://search.cpan.org/~mschwern/perl5i-v2.2.2/lib/perl5i.pm: "perl5i - Fix as much of Perl 5 as possible in one pragma" Why not use a language that lets you get stuff done faster, instead of a language that's been feature-patched to death to fix the terrible design flaws it began with?
  - chromatic 16y ago
    Perhaps you can comment on what he actually said, not who he is? Certainly: that particular comment is irrelevant nonsense. There should also be a CPAN module called Python. Fix as much of perl 5 as possible in one new language! I expect better discussion from Hacker News.
    - sreque 16y ago
      You're right about the Python comment, and I edited it out. However, I would also say that you've provided no discussion of value in your comments. I at least back up my statements with correct supporting arguments, even if I sometimes use overly strong language in making them.
      - chromatic 16y ago
        My point is simple: the past ten years of Perl development have changed the language and its ecosystem dramatically. You can still write Perl as you did in 2000 or 1994 or 1987, but the Perl community tends to use terms like "Modern Perl" and "Enlightened Perl" and "Perl Renaissance" to distinguish between code we know to be buggy and clunky and difficult to maintain and the code we write now that we know so much better. If you want to compare Python to Perl, compare Python 1.x to the ancient Perl that always comes up in these comparisons. (You may or may not deduct points from Python for breaking backward compatibility in the past near-decade.)
        deleted 16y ago
        [deleted]
        sreque 16y ago
        Then we don't have anything to argue about. I agree that modern Perl is a lot better than older perl, and that modules that fix perl, like perl5i, Coro, and Moose, enable you to write decent code using the language. I never tried to say otherwise. My point was, why bother, when you can use a language that doesn't need to be fixed in the first place? Life is so much simpler without all the extra accidental complexity.
- deleted 16y ago
  [deleted]
mkelly 16y ago
(This probably both offends both Perl people and C++ people. Here goes.) I think writing clean, readable, modern Perl is like writing clean, readable, modern C++: it's _all_ about what language features you avoid using. Writing good code is totally possible in both languages, and people have done it successfully. It's unfortunate that both languages are filled with features better left unused, but they're both very useful tools. Perhaps Perl has a little more competition in its area of focus than C++ does. Many would argue that we should be using neither Perl nor C++, but I haven't seen any serious contenders to replace either. (For the record, I use both Perl and C++, but only infrequently.)

by sreque 16y ago

chromatic 16y ago

I don't know what to tell you other than if you deliberately write clunky code, you'll have trouble understanding and maintaining it. Passing typeglobs around isn't modern Perl; it hasn't been necessary for over a decade (to be specific, it hasn't been necessary since 22 March 2000). ... and I know Steve and I like Steve, but I wouldn't take medical advice from him either for much the same reason.

sreque 16y ago
Steve may not be a medical doctor, but he is a programming language expert, so I really don't get your ad hominem refutation of what he said about Perl. Perhaps you can comment on what he actually said, not who he is? Also, I think you missed the entire point of my post, including the example. I'm also not sure of how else to word it to help you get it. My point was that Perl requires you to deal with a host of issues that have nothing to do with solving your actual computing problem. One simple example of these many thousand idiosyncracies, which the article itself indirectly brings up, is Perl file handles. Even if you know the "modern" way of using them, you still had to go through the learning process to differentiate between the old and new styles, and you still have to commit a bunch of useless facts to memory. Worse, you may still encounter and have to deal with the old way in the wild! I love the description of the perl5i CPAN module at http://search.cpan.org/~mschwern/perl5i-v2.2.2/lib/perl5i.pm http://search.cpan.org/~mschwern/perl5i-v2.2.2/lib/perl5i.pm: "perl5i - Fix as much of Perl 5 as possible in one pragma" Why not use a language that lets you get stuff done faster, instead of a language that's been feature-patched to death to fix the terrible design flaws it began with?
- chromatic 16y ago
  Perhaps you can comment on what he actually said, not who he is? Certainly: that particular comment is irrelevant nonsense. There should also be a CPAN module called Python. Fix as much of perl 5 as possible in one new language! I expect better discussion from Hacker News.
  - sreque 16y ago
    You're right about the Python comment, and I edited it out. However, I would also say that you've provided no discussion of value in your comments. I at least back up my statements with correct supporting arguments, even if I sometimes use overly strong language in making them.
    - chromatic 16y ago
      My point is simple: the past ten years of Perl development have changed the language and its ecosystem dramatically. You can still write Perl as you did in 2000 or 1994 or 1987, but the Perl community tends to use terms like "Modern Perl" and "Enlightened Perl" and "Perl Renaissance" to distinguish between code we know to be buggy and clunky and difficult to maintain and the code we write now that we know so much better. If you want to compare Python to Perl, compare Python 1.x to the ancient Perl that always comes up in these comparisons. (You may or may not deduct points from Python for breaking backward compatibility in the past near-decade.)
      - deleted 16y ago
        [deleted]
      - sreque 16y ago
        Then we don't have anything to argue about. I agree that modern Perl is a lot better than older perl, and that modules that fix perl, like perl5i, Coro, and Moose, enable you to write decent code using the language. I never tried to say otherwise. My point was, why bother, when you can use a language that doesn't need to be fixed in the first place? Life is so much simpler without all the extra accidental complexity.
deleted 16y ago
[deleted]

mkelly 16y ago

(This probably both offends both Perl people and C++ people. Here goes.) I think writing clean, readable, modern Perl is like writing clean, readable, modern C++: it's _all_ about what language features you avoid using. Writing good code is totally possible in both languages, and people have done it successfully. It's unfortunate that both languages are filled with features better left unused, but they're both very useful tools. Perhaps Perl has a little more competition in its area of focus than C++ does. Many would argue that we should be using neither Perl nor C++, but I haven't seen any serious contenders to replace either. (For the record, I use both Perl and C++, but only infrequently.)