Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

"Native Perlish"

by spurperl (Priest)
on Mar 26, 2003 at 11:47 UTC ( #245902=perlmeditation: print w/ replies, xml ) Need Help??

Friend Monks,

I hope this topic wasn't beaten in the past too much, but I just got thinking (meditating) about something interesting.

Those of you who dealt with foreign language speakers for some (depends on what is a foreign language for you, of course... for me English is) time surely know what it is like to hear a person talking correctly, but not the "native way". Eg, using phrases, that, while syntactically (sp ?) and semantically correct, don't "sound right". It gets you to think that the person studied the language well, but hadn't really spoken it to native speakers much.

The same, IMHO, applies to programming languages. Languages have a "way" - a style & techniques that "seem right" to gurus. For instance, Lisp has a very specific "way". You can, and many definitely do, write C-ish code in Lisp. Sure, just bang variables all around, setf them, use do and loop instead of map and recursion, pay no attention to closures and macros, etc.
C itself also has "a way", and many others do - notably the old and established languages, and not some new trend M$ invents every second friday.

Well, Perl, the language for which we've all gathered here seems like a mix of everything. It has the imperative stuff from C and family, the functional stuff from Lisp and friends. But is there a "Perlish way" ? Could we look at code of some good programmer (not talking about newbies here) and say - "Yump, he knows the trade, but he definitely came from a different background and just recently learned Perl from a book".

Thus, I ponder... Hope to hear (or see, literally) some examples or thoughts from you.

Comment on "Native Perlish"
Re: "Native Perlish"
by jdporter (Canon) on Mar 26, 2003 at 12:39 UTC
    The concept you have independently rediscovered here has a name: Idiom.

    ++spurperl

    jdporter
    The 6th Rule of Perl Club is -- There is no Rule #6.

      According to the Webster's 1913 accessible frim KDE thanks to kdict, one of the meanings for idiom is the syntactical or structural form peculiar to any language.

      I think that syntactical/structural forms are the way of capturing in syntax recurrent programmatic patterns so they stand out. So a language that captures patterns syntactically absent from other languages is certainly idiomatic. Perl is very aggressive in capturing patterns with its syntax so it is certainly idiomatic. A language can also be very idiomatic by its very repetitive syntax like Lisp and its "clipped nails". I would use the expression syntactically idiotic here to qualify Lisp.

      -- stefp

        idiom goes beyond syntactical or structural form. Here are two definitions from the OED (the second and third major ones; using the 1971 compact edition):

        • the specific character, property, or genius of any language; the manner of expression which is natural or peculiar to it.
        • a form of expression, grammatical construction, phrase, etc., peculiar to a language; a peculiarity of phraseology approved by the usage of a language, and often having a significance other than its grammatical or logical one

        The first definition there, applied to Perl, might be things like using $_ and @_ to write concisely (Effective Perl Programming item 7). The second definition would mean things like while (<FH>) { do_stuff } (although technically that is approved by the design, rather than the usage, of the language) or perhaps things like naming conventions. A non-Perl example would be Hungarian Notation in C++. The Perl community has things like that too.

        Stuff like the Schwartzian Transform could be considered idiomatic also, or the practice of returning undef for false (which, incidentally, will change in Perl6).


        for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc' .'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$ p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}
Re: "Native Perlish"
by hding (Chaplain) on Mar 26, 2003 at 12:53 UTC
    FWIW, it's not at all uncommon nor considered "un-Lispish" by the Lisp community (at least the Common Lisp community; I don't presume to speak for the Schemers) to do things like use variables, setf them, use loop, etc. (In fact, that's why those sorts of things are in the language.) Spend some time reading code that some very good Lisp programmers post to comp.lang.lisp and this will be clear. :-)
Re: "Native Perlish"
by dragonchild (Archbishop) on Mar 26, 2003 at 14:54 UTC
    Given the syntactic richness that Perl offers, it's actually quite easy to tell what language a person was most comfortable with when learning Perl. Where I currently work, I can see C-Perl, C++-Perl, and Java-Perl, all in the same codebase (along with some Crud-Perl).

    (They then complain about my Perl-Perl ... I mean, map and grep aren't "undocumented features", are they? Parentheses are required in C, but quite obfuscating in Perl ... right?)

    ------
    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.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      I like the parens, actually. But then, I came to Perl from Emacs lisp...

      I really can't stand Perl that's been written by an extreme died-in-the-wool C programmer. It's one thing to slip in an occasional semicolon-laden for loop (though I'm not fond of too many of them), but when every hash is pretending to be a struct and every array is traversed using an index and every simple pattern match is done with a loop and substr and every interpolation is done with sprintf, I want to scream. Don't get me wrong, I like sprintf, when I need leading zeros or something... I'm only talking about the people who use it when simple interpolation would do fine. People who write Perl like that should be punished by forcing them to read a thousand lines of code that does absolutely everything with closures.


      for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc' .'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$ p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}
•Re: "Native Perlish"
by merlyn (Sage) on Mar 26, 2003 at 14:59 UTC
    I might be so bold as to suggest that a model for "native Perl" would be the code written by those of us that have spoken Perl the most frequently and the longest (and more importantly, have written it enough different ways that we've had time to compare which ones really suck on a reading three months later).

    However, one should also consider that part of the coolness of Perl is having so many ways to do things. Certainly, using a for loop instead of a foreach loop to process every element of an array is "less Perlish", but would something like the Schwartzian Transform, which is basically a Lisp-technique adapted to Perl, be "native Perl"? It's hard to tell.

    If you can say in three nice simple lines what someone else said in six, I'd say the three lines are probably more Perlish. But when you start trading three lines for three lines, I'm not sure there's a gain. But it's not all about lines of code... that's just my first rule of thumb.

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

Re: "Native Perlish"
by Abigail-II (Bishop) on Mar 26, 2003 at 15:12 UTC
    OTOH, there's a lot of "overcompensating" going on in Perl code, especially in forums like this in comp.lang.perl.misc. What I mean is things like using complicated code to avoid a warning, where it would have been easier to turn of warnings (or strict). Or to use several lines of Perl code (or an entire module) to avoid having to use system or backticks.

    You might want to say that someone using

    system cp => $from, $to and die "Eeps";
    comes from a shell background and has just learned Perl from a (bad) book. But it might also be someone with 20 years of Unix experience, and 8 years of Perl experience who's just using the toolkit concept and can't be bothered with using a module. (Wait, that sounds like me).

    I do use system more than I really, really have to, I've never used File::Find (or is it Find::File), prefering to read from a find pipe instead, I do use for (my $i = 0; $i < @arr; $i ++) even if I could use for my $i (0 .. $#arr) instead, and more "tell tale" signs of coming from a different background.

    I think that Perl more than most other languages allow a programmer to keep using his/her unique, or carried over, style. That is, IMO, one of the good things of Perl.

    To quote Geoff Gerrietts, in comp.lang.perl.misc article of 26 July 1996: Perl lays down like a wanton woman and lets me have my way with her.

    Abigail

      I'm sure anyone who'd have to port your code to Windows (or VMS or Mac-pre-OSX or ...) would love you for this.

      Jenda
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
         -- Rick Osborne

      Edit by castaway: Closed small tag in signature

        I've never worked in a place were there was the smallest chance one of my Perl programs needed to be ported to Windows or any other non-Unix platform.

        However, I've written large shell scripts on Solaris that needed to be ported to both Windows NT and to HP-UX. The port to Windows was *trivial*. One directory needed to be renamed, and we installed a Unix tools package on Windows (I think it was MKS). Porting to HP-UX was actually more work.

        Generally, I don't give a rats ass whether my programs can be easily ported to Windows or not. If you want to cripple yourself running on that platform, be my guest. Don't expect any pity or help from me.

        I'm a toolsmith. I write tools, usually highly specialized tools. Needing to do one particular job, on a particular platform. Portability to non-Unix platforms usually is a non-issue. Besides, there are Unix toolkits for non-Unix systems available. Install them, and your platform will become better.

        Abigail

      To quote Geoff Gerrietts, in comp.lang.perl.misc article of 26 July 1996: Perl lays down like a wanton woman and lets me have my way with her.

      Some quotes you just can't get rid of.

Re: "Native Perlish"
by hardburn (Abbot) on Mar 26, 2003 at 15:21 UTC

    When learning a human language, people are encouraged to try to "think" in that language, instead of thinking in their native tounge and translating. Now, when it comes to human languages, I'm an utter failure at learning ones outside my native tounge (probably because I'm too lazy to really study another one). Even so, I recognize the principal of thinking in a different language.

    I've noticed a similar trend in programming languages. I orginally learned BASIC on an Apple //c. Around 1995, I started learning a little about Perl. I didn't get very far with Perl back then, and I soon went onto C. I did fairly well in C and later learned Java. However, at first, I programmed Java as if it were C--i.e., no real use of OO. And if you're not using OO, why are you bothering with Java?

    I later figured out how to use Java's OO effectivly, but then bought the Camel and really started learning Perl. However, I was still "thinking" in C, and my code looked like it. For instance, I was always using the three-element form of for, I use parans and return even when its not necessary (still do, but less so than I used to). I got mad that you couldn't say if($condition) print "true"; but instead had to do print "true" if($condition);.

    I think PerlMonks (plus a job where I've been writing Perl almost every day for the past year) is what really got me to "think" in Perl. Whenever I try a new language, I come up with a Perl solution in my head and try to translate. This doesn't work so well for Perl as it did for C. C is fairly bare-bones, and its idioms can often be translated directly into a new language. Perl has some very special ways of doing things.

    Looking at other people's Perl code, I can usually spot what language their thinking in. It seems that most Perl programmers come from a C background. This script (external link) looks like it was written by someone thinking in VB (notice the long series of if statements when they could have used elsif or (beter yet) a hash). People who are really thinking in Perl will often use a clever bit of map or grep and a clear grasp of regexen (using /x for anything too complex, hopefully).

    So yes, there is very much a "Perlish" way.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated

      I completely agree with your point, though you probably stated it much more concisely than I would have.

      I am a relative programming "babe in the woods". I've been at this for about 3 1/2 years or so, and have noticed the following trend in myself and others either learning to program or adding a new language to their belt.

      1) Learning the syntax
      2) Learning the functions available (builtin and libs)
      3) Learning to think in the language
      4) Accepting the limitations of the language

      When you can think in the language I think you have really started to grok it. You can address your problem from the way the language will be able to deal with it best. Depending on the available capabilities of the language, this could mean you have mastered it (i.e BASIC) or are well on your way to getting into deeper solutions (C, C++, Perl). When you get to the point where you can honestly review a problem and determine that the language probably isnt the right solution, you have become what I would consider a "native".

      At that point you are able to cleary define the problem, how to address it in the language, and whether or not that is valid in the given situation.



      /* And the Creator, against his better judgement, wrote man.c */
Re: "Native Perlish"
by Zaxo (Archbishop) on Mar 27, 2003 at 06:17 UTC

    One feature that I consider to be distinctively perlish is the use of the pronouns $_ for it and @_ for them, eg. /foo/ and print for @bar;

    After Compline,
    Zaxo

Re: "Native Perlish"
by spurperl (Priest) on Mar 27, 2003 at 08:44 UTC
    Below is an excerpt from the book "Effective Perl Programming" by Joseph N. Hall and our friend merlyn. It is taken from the first paragraph of chapter 3:

    Perl is a language designed by a linguist, and as much as any human lan-guage,
    Perl is a language of idioms.
    What I call idiomatic Perl is the mixture of elegance and custom that
    comes naturally to Perl programmers, or, at least hopefully, to the majority
    of them, after experience and experimentation. Exactly what is idiomatic
    and what is purely a matter of style or opinion is debatable. There are
    many different ways to express both simple and complex algorithms in
    Perl. Some ways, however, are clearly more “right” than others.
    

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://245902]
Approved by valdez
Front-paged by Enlil
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (8)
As of 2014-08-21 05:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (127 votes), past polls