5 ms·

I had the exact same experience coding Perl in my last company. I found myself, just like Steve Yegge says in his ancient languages blog post, having to memoriz

by sreque 15y ago

I had the exact same experience coding Perl in my last company. I found myself, just like Steve Yegge says in his ancient languages blog post, having to memorize all the special edge case rules and idioms of the language just to get anything done. Whenever I got to choose Python, Ruby, or C for a task I felt like I was breathing fresh air again after being stuck in a musty room for a while. I remember being offered to choose any toolset I wanted for a particular project and finding out that Perl was the only scripting language that had the bindings to the C libraries I needed to use. Naturally, I decided to to do the whole project in straight C instead. :) The funny thing is, whenever I would code in Perl for a while, I would actually grow acclimated to it. I would start to think to myself, "Hey! I'm finally getting things done. I CAN be productive in this language!" It was only after switching away to another language again that I would re-recognize just how painful Perl really is. This experience actually repeated itself multiple times for me as I moved on and off Perl projects and it helped me learn to sympathize more with others who are perfectly content to code in Perl for a living. At one point, I had enough and began recording all the weird Perlisms that were wasting my time as I encountered them. My goal was to compile a "95 theses against Perl" document and post it on my manager's door as a joke. Fortunately, I only got into the 40s before my manager offered to let me move to another team where I never had to write a line of Perl again in that job! It's possible to write good Perl just like it's possible to write good COBOL, and better tutorials would definitely help newcomers to the language do just that. I would rather spend my time writing good code in other languages, however.

kristaps 15y ago
Do you still have that list? I think it could be very useful to someone who has to dive into a legacy Perl codebase.
- sreque 15y ago
  I wish I had kept it, but I can't seem to find it in the set of files I kept from that job. It would have been fun to make a blog post out of it.
- hercynium 15y ago
  Two excellent books I can recommend for someone working with legacy Perl: Perl Medic (Peter J. Scott) - http://amzn.com/0201795264 http://amzn.com/0201795264 Effective Perl Programming (Joseph N. Hall, Joshua A. McAdams, brian d foy) - http://amzn.com/0321496949 http://amzn.com/0321496949 Besides those, having a good reference to the language is also essential. For example, I keep Perl In a Nutshell close by, even though I almost always just search http://perldoc.perl.org/ http://perldoc.perl.org/ when I need that info.
- flounder 15y ago
  Googling for "things I hate about Perl" turns up a number of articles -- often written by folks who like Perl 5 but who also are happy to admit to its issues.
mikecaron 15y ago
So here's the thing, Larry Wall is not only a programmer, he is a linguist. That's reflected in the myriad of ways that one can write something in Perl, reflected in the common refrain at YAPCs the world over, "TMTOWTDI" (There's More Than One Way To Do It). But because of the flexibility Larry designed into the language, there's also "more than one way to do it" ...wrong (ok, not "wrong", but so complicated and whacky that Joe programmer 10 years from now wouldn't have a clue about). But this very flexibility gives Perl a unique beauty. I don't think it's the language's fault that poor code exists to teach people the way to Perl zen. It's more that scripting languages themselves lend to one-offs and poor code writing, especially in the days of early Perl, when people were giddy to get their hands on something that wasn't as ugly as "sh". We need better programmers who are not "too busy to write good code" as well as better material.
- danssig 15y ago
  This line of reasoning is old and tired. Natural language is a bad enough way to communicate with people, it's a ridiculous way to communicate with machines which take everything literally and treat everything implied to mean "crash in amusing and unforeseeable ways". One of perl's big "natural language" claims is that things mean something different in different context. I think there are several movies based on what can happen when two people have a conversation but have a context mismatch.
  - mikecaron 15y ago
    I'm not saying it's good or bad, all I'm saying is that it was Larry's choice when developing the language. Here's a great example of C++ meaning different things in different contexts. How about this: int *& p; *&p;
    - danssig 15y ago
      One is a declaration, one is an expression. And, believe me, I taught C++ for a while and this already causes a lot of confusion.

by sreque 15y ago

kristaps 15y ago

Do you still have that list? I think it could be very useful to someone who has to dive into a legacy Perl codebase.

sreque 15y ago
I wish I had kept it, but I can't seem to find it in the set of files I kept from that job. It would have been fun to make a blog post out of it.
hercynium 15y ago
Two excellent books I can recommend for someone working with legacy Perl: Perl Medic (Peter J. Scott) - http://amzn.com/0201795264 http://amzn.com/0201795264 Effective Perl Programming (Joseph N. Hall, Joshua A. McAdams, brian d foy) - http://amzn.com/0321496949 http://amzn.com/0321496949 Besides those, having a good reference to the language is also essential. For example, I keep Perl In a Nutshell close by, even though I almost always just search http://perldoc.perl.org/ http://perldoc.perl.org/ when I need that info.
flounder 15y ago
Googling for "things I hate about Perl" turns up a number of articles -- often written by folks who like Perl 5 but who also are happy to admit to its issues.

mikecaron 15y ago

So here's the thing, Larry Wall is not only a programmer, he is a linguist. That's reflected in the myriad of ways that one can write something in Perl, reflected in the common refrain at YAPCs the world over, "TMTOWTDI" (There's More Than One Way To Do It). But because of the flexibility Larry designed into the language, there's also "more than one way to do it" ...wrong (ok, not "wrong", but so complicated and whacky that Joe programmer 10 years from now wouldn't have a clue about). But this very flexibility gives Perl a unique beauty. I don't think it's the language's fault that poor code exists to teach people the way to Perl zen. It's more that scripting languages themselves lend to one-offs and poor code writing, especially in the days of early Perl, when people were giddy to get their hands on something that wasn't as ugly as "sh". We need better programmers who are not "too busy to write good code" as well as better material.

danssig 15y ago
This line of reasoning is old and tired. Natural language is a bad enough way to communicate with people, it's a ridiculous way to communicate with machines which take everything literally and treat everything implied to mean "crash in amusing and unforeseeable ways". One of perl's big "natural language" claims is that things mean something different in different context. I think there are several movies based on what can happen when two people have a conversation but have a context mismatch.
- mikecaron 15y ago
  I'm not saying it's good or bad, all I'm saying is that it was Larry's choice when developing the language. Here's a great example of C++ meaning different things in different contexts. How about this: int *& p; *&p;
  - danssig 15y ago
    One is a declaration, one is an expression. And, believe me, I taught C++ for a while and this already causes a lot of confusion.