Perl, best practices, and language design

Last night, I said this:

Writing Perl after months of coding in Python is really frustrating.less than a minute ago via webBenjamin Trott
btrott

And I thought I'd expand on it, as a couple of people had questions and/or interpreted it in different ways. There were roughly 3 interpretations: 1. moving from Python to Perl is frustrating; 2. moving from X to Perl is frustrating; and 3. moving from X to Y is frustrating. And that's sort of the order of the feelings that inspired that tweet; it was first and foremost about moving specifically from Python to Perl.

Here's the thing: I love Perl. It's still the most natural (coding) language for me to think in, and when I'm prototying, I usually use Perl (even if I'm going to rewrite the final version in another language). It's the most natural way for me to think through how an application/tool/library should work, design the interfaces, and so on.

Perl is my native language, in many ways.

But. What's most frustrating to me about returning to Perl, after months of coding in Python, is the lack of standardization in the core language for things like exception-handling, logging, proper objects, &c, that are well-defined and consistently-used in Python. Contrast that with Perl, where, just for the object model alone, you've got libraries that use Moose, others that use Class::Accessor, others that use Moo or Mouse, others than use Object::Tiny, and so on. And so if I'm writing a new project--of moderate complexity--that'd end up on CPAN eventually, the lack of a core standard around (say) objects/classes or exception handling is frustrating.

And this is where the "more than one to do it" philosophy hits its natural limit, for me. As chromatic said recently, "Sometimes you have to provide one good way to do most things without excluding the possibility of doing other things." At its worst, having more than one way to do everything leads to fragmentation and a lack of best practices.

Language design involves curation; having more than one way to do it might give you a collection of options to choose from, but at some point, you've got to choose.

Comments

[Rainboxx]

Ben, I totally agree. It's both a blessing and a curse.

[garu]

http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html

[perigrin]

This is actually one of the reasons behind the creation and promotion of Task::Kensho ( http://search.cpan.org/dist/Task-Kensho ). The end goal was to build a kitchen-sink included Perl, but that has been delayed.

The idea is to create an opinionated Perl distribution based on perceived best-of-breed distributions. Things like Moose, Catalyst, DBIx::Class, etc are included.

[TimToady]

Indeed, this is one of the primary differences between Perl 5 and Perl 6. Perl 6 still has a great deal of flexibility underneath, but we've gone out of our way to make sure you aren't required to know about it; instead, we've chosen sane defaults for most of the areas where Perl 5 forces the user to make a conscious choice.
If you love Perl because it matches the way you think, and if that's because it's also the way I think, then I think you'll love Perl 6 even more, once we get a few more of the kinks worked out, and distribute the future a bit more evenly.

[hanekomu]

What if the standard is not good enough? Then people would want to improve on it but might be held back because they don't want to break a standard.

So a lack of standards, for such things at least, might be good for innovation.

[btrott]

@hanekomu: Yeah, but--my gut is that if a language accumulated enough junky standards in the core, then it just wouldn't be popular, and no one would care about using it, let alone innovating on it.

Whereas the tl;dr version of my post above is basically: 1. there's a ton of stuff I love in Perl; 2. I wish there were more of what I love about Perl in the core (i.e., that more of the philosophy & language design that's gone into Perl, so far, would be extended to the other areas that I miss when moving from Python to Perl).

[btrott]

@TimToady: Thanks for the note, Larry--I'm looking forward to trying out (and loving) Perl 6! If it can take what I love about Perl, and bake additional sane decisions re: language design into the core, then I'm really optimistic.

[Kevin G.]

I was walking down the street today and this post came to mind and I realized I was burningly curious about one thing: when you opened a file and started typing Perl code for the first time in months, was there anything in particular that made you say "Ahhhh, I'm back in the land of _____"?

[btrott]

Hey Kevin! You know what it was, specifically? It was that I wanted to raise an exception (an actual named exception) without having to introduce some new dependency on this module I was writing, many of which dependencies would also end up pulling in all of Moose, which I wasn't particularly crazy about, and which dependency would almost certainly be different than what someone else (some application that might use my module) was using for raising exceptions. (There were other things, too, like pulling in Object::Tiny just to get simple objects with accessors, but iirc, it was the exception case that made me throw up my hands.)

[Boros1124]

I easily learned the Perl programming language. The book has been umpteen only.
www.konyv-konyvek.hu/book_images/08a/212501708a.jpg

[Kevin G.]

Ah, of course, and well put. But I was actually curious about, and my fault for not properly enunciating that the "Ahhh" was actually meant to be an "Ahhh" of satisfaction, relief and happiness rather than an "Aarrrgh". Was there any nice thing that immediately jumped out at you from being back in Perl-land? Some nice Perlishness that you missed in Python? I was just curious, and we should be fair, you know.

[btrott]

Yeah, that's an interesting question... it's hard for me to pinpoint something specific, because it's more just a general feeling of comfort that I get when I write Perl: because it's so native, and it's kinda the default for how I think when I'm coding, I find that I don't ever have to think about syntax--I can think entirely at a different level re: how the code should work and fit together. I like being at that point with a language, and it's why Perl's still the language I choose most frequently for prototyping.