-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

I feel like my Perl is finally loosening up after three years. When I first started using the language I pulled out a lot of hair trying to make it look more structured, like Java. So for a long while I would nearly always use parentheses with methods and functions even when not required, just to make them look more like I thought they ought to. (Recall that in Java Class.member refers to a variable, where Class.member() refers to a (class) method). So I wrote a lot of code like:

return(grep(defined($_), @thingies));
[download]

return grep(defined $_, @thingies);
[download]

It's also been a recent change for me to use -> for dereferencing rather than prepending an extra $. I used to have a strong aversion to $this->{foo}, preferring instead $$this{foo}, whereas now that aversion is reversed. I suspect that it was originally a consequence of my early discomfort (read: total lack of comprehension) with respect to references, and using the form with fewer characters allowed me to pretend there wasn't anything spooky going on :^)

As a general trend, I find that I'm trying less to force my Perl into accordance with a priori principles and relying more on context (hence my sig). The downside is that I'm making decisions more based upon that nearly always elusive quality called "judgment"; the upside is that I think my judgment is getting better :^)

However, I have noticed a tendency to move away from the C++/Java style many people start with and fully embrace map, grep, hashes, and the like. This, I would say, is a very different dialect than C++Perl or JavaPerl. I would say it's almost a different language, in the way that an OO purist would use C++ differently than a procedural purist. Same language, different dialect.

Good meditation! ++!

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

I use overloading and tie-ing a little, more often to add extra functionality while still looking core-ish.
Examples: exception stringification and bool overloading or using IxHash for ordering.

I've also dabbled in source filters, once to create debugging macros and I also started a Literate Pod filter.

I'm reluctant to override core functions, add to UNIVERSAL, globally change special variables, etc for fear of breaking some remote piece of code.

Some times I (mis)use core perl when I can use a certain aspect of it's behaviour even though it is outside the original intention. Eg. using @ISA, isa() and can() on hierarchies that aren't code classes. I love the fact that I can do this, that the language doesn't hide it away for my own good.

That's all I can think of at the moment.

Brad

I like to think that I speak a fairly 5.6 dialect of perl. :-) Some things that I do and dont do are

• I dont use -w, I do use warnings;
• I dont use map/grep in void context
• I often use map, less so grep
• I do use logical operators as flow control statements
• I try to use statement modifiers instead of composite statements as much as possible
• I try to write my code so it uses as few parens and brackets as possible
• I often use code templating techniques
• I ususally do OO modules
• When writing non OO modules that are more than just a subroutine library I very often write my own import to provide more intelligent interfaces. A module can be treated as a subroutine from the point of view of the interface that import provides.
• Occasionally I use named paramaters for methods/subs, but usually only for constructors.
• I never use code filters.
• When writing recursive routines I usually use a named wrapper and then an anonymous sub to do the recursion

  sub recurse_inorder {
    my $self=shift;
    my @inorder;
    my $sub;
    $sub=sub{ 
              my $node=shift;
              $sub->($node->left) if $node->left;
              push @inorder,$node->value;
              $sub->($node->right) if $node->right;
            };
    $sub->($self);    # Added due to [dragonchild]s eagle eye
    return \@inorder;
  }
  [download]

• I often use dynamic scoping
• I often use pack, as well as s///e
• If it has more than a few alternations I usually write my regexes under /x
• I use return, and last/redo/next very often to reduce nesting depth of my code.
• I often use iterative algorithms instead of recursive algorithms
• When doing recursive data structures I usually use a wrapper type istead of a "pure" OO implementation

---
demerphq

• Update:  
dragonchild noticed that I ommitted to call $sub so I added the missing line. Thanks dude.

* When writing recursive routines I usually use a named wrapper and then an anonymous sub to do the recursion

<plug>Why, what a perfect situation for Sub::Lexical</plug>

* I often use pack, as well as s///e

What situations do you find yourself using s///e? I can't say I've ever used it anything outside golf and obfu so where does it fit into your day-to-day coding?

_________
broquaint

<plug>Why, what a perfect situation for Sub::Lexical</plug>

*Blush* I have meaning to check that out for a while... Ill have looksee when i get a minute. :-)

What situations do you find yourself using s///e? I can't say I've ever used it anything outside golf and obfu so where does it fit into your day-to-day coding?

I do a lot of data transformation type tasks. So it comes in useful quite regularly. Having said that I can't remember exactly where I used it last, but I do recall that I used it fairly recently.

---
demerphq



---

• Update:  
Heres an (untested) simplified example of where s///e comes in useful

  $date=~s/^(\d+)-(\d+)-(\d+)$/sprintf('%04d/%02d/%02d',$1,$2,$3)/e
    or die "Failed to normalize date...";
[download]

sub recurse_inorder {
  my $self=shift;
  my @inorder;
  my $sub;
  $sub=sub{ 
            my $node=shift;
            $sub->($node->left) if $node->left;
            push @inorder,$node->value;
            $sub->($node->right) if $node->right;
          };
  return \@inorder;
}
[download]

Maybe I'm just dense, but when does the actual population of @inorder happen?

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Maybe I'm just dense, but when does the actual population of @inorder happen?

Presumably you are refering to the fact that originally I forgot to call $sub. Thanks for the heads up. :-)

Ive updated the node now. If this isnt what you meant /msg me and Ill update this node with an explanation....

---
demerphq

Whatever gets the job done, or will get future jobs done more quickly. Attribute::Property exists for a reason, but I normally don't use attributes much. My perl scripts are not threaded, although I like how forks gives me similar functionality with good old CoW forks. I'd use extensions like Switch if I felt any need to, but I'll probably not use it as long as series of ifs and elsifs and hashes of coderefs do what I want.

Although you're not interested in this information, I'd like to note that I'm a 4-space indenter and that I like cuddled elses. My code doesn't have much parenthesis, but it's not something I try to avoid; I'm just lazy and don't want to type much.

I'm not a strong believer in object orientation, and like that Perl lets me choose the way I code. In practice, I do use OO a lot. I like code to be clear and dislike redundancy. Because I don't want to limit myself in what I do, I always assume that whoever will maintain my stuff speaks Perl fluently. Many others avoid constructs with map, don't touch certain regex assertions, write extremely_verbose_variable_names and spell out every idiom used, just so that any moron can maintain their code. I hate when people do that: just be yourself and code the way you want to; use the features that you think are appropriate and don't be afraid of using things that newbies would avoid.

My Perl dialect? I have no idea, and don't really care. I'm happy if perl does what I want and I can still read my own code in a few months from $now.

Juerd
- http://juerd.nl/
- spamcollector_perlmonks@juerd.nl (do not use).

I'm not sure one could call it a dialect: I've found myself using List::Util more and more lately. It's a pity it wasn't in core before 5.8. Not that it does anything I couldn't do anyway; but it's convenient not to spell out its idioms constantly.

But I would rather call it more elaborate Perl, as opposed to a dialect, much the way a writer hones his ability to use his language more skillfully by expanding his vocabulary and his mastery of rhetorical devices. My about five years of Perl so far have been a constant transition towards a more and more functional programming style.

Perl has grown me out of thinking on the low, the machine dependent level, the implementation specific plane, and expanded my mind into a far more abstract approach. I have gained another, very different perspective into programming. In a paradoxical way, Perl's "dirty" approach to solving problems the practical way has made me much more of a computer scientist than I was before.

Given that spirit, I'm not sure I could treat myself to something like OO C++ or even Java with their stiff and rigid typing system anymore. It seems like a chore dictated by the close proximity of a language to the hardware and the consequent lack of metainformation about the program and its data at runtime. I've got myself several books on Java and tried to get into it so far; after all, it's a very marketable skill (even if I can end up doing more of my job in Perl, eventually *grin*), but haven't had the stamina to shovel through any of them. It's just no fun.

On the other hand, I am wildly curious about Lisp, Smalltalk and Prolog nowadays.

Err.. I think I veered off topic somewhat. Anyway. You get an idea of how I look at code nowadays. The way I write my Perl is a direct consequence.

Makeshifts last the longest.

--
$you = new YOU;
honk() if $you->love(perl)

Hmm. Most of the scripts I write are trivial in comparison to the stuff I've seen here. My most complicated script so far used a three dimensional hash (like $foo{'bar'}{'baz'}{'quack'}). My scripts have to be readable by other people, some of those people know a touch of Perl. Most don't.

The scripts I write are used almost exclusively on Windows, and in reality I don't think they're ever used on a Unix (or Mac) box. All of our development is done on Windows. So I can safely put in a system "dir"; call. And I know that's a horrible thing to do, so I avoid it. But I look at it this way: If you're writing text, do you translate it to every known language if you are sure that the text is only going to be read by people who speak one language?

As I mentioned, the scripts I write need to be readable above all else. Well, maybe not above functioning. But since I've pretty much turned into the Perl person around here I need to have scripts that look like something a C++ coder will grok without too much brain twisting. So anything that is too Perlish gets commented, or expanded to something a little less efficient.

And I almost never use modules. While I can guarantee that 99.999 percent of my scripts will be used on Windows, I can't guarantee that the modules will be available. So the worst case scenario entails me grabbing the code from a module and changing it so that it can be run from within my script. Properly citing references, of course.

And I almost never use modules. While I can guarantee that 99.999 percent of my scripts will be used on Windows, I can't guarantee that the modules will be available.

This is bad. Very very bad. I use windows 100% of the time, and ive never encountered this problem. Use ppm, use CPAN, whatever, but definately use modules. You will come to regret not doing so one day. And if anybody professional looks into your code your reputation will suffer.

---
demerphq

I write code for physics research, and since my programs often have run times of months I find myself developing an incredibly strict style.

If I know an idiom that turns a task into a oneliner, I use it; if I don't I try to find or reason one out that I can add to my "dialect" and further cut my code. The goal is brevity. I want to be able to read my code as a few lines of colloquial instructions, all of which are familiar.

I always use warnings; use strict; use diagnostics in every script. I write the script, debug it, and then write either a commented header or a POD document telling what it does and how to use it. I never actually comment my code, since it's all in my dialect.

grep, map, and such don't see the light of day that often in my code just because I have little use for them. sort occasionally comes up. My data is usually in files being operated on my FORTRAN programs, or is in piddles under PDL. I got to use sort yesterday to arrange the frequencies of emitted photons in n=3 to n=2 transitions in hydrogen with fine structure corrections yesterday, but that was more for aesthetic reasons than need. Physics seems to be order independent...