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.
•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. | [reply] [Watch: Dir/Any] |
Re: "Native Perlish"
by jdporter (Chancellor) on Mar 26, 2003 at 12:39 UTC
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
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$/}
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: "Native Perlish"
by Abigail-II (Bishop) on Mar 26, 2003 at 15:12 UTC
|
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 | [reply] [Watch: Dir/Any] [d/l] [select] |
|
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
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
|
|
|
|
| [reply] [Watch: Dir/Any] |
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. | [reply] [Watch: Dir/Any] |
|
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$/}
| [reply] [Watch: Dir/Any] [d/l] |
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
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
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 */
| [reply] [Watch: Dir/Any] |
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. :-) | [reply] [Watch: Dir/Any] [d/l] [select] |
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
| [reply] [Watch: Dir/Any] [d/l] |
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.
| [reply] [Watch: Dir/Any] |
|
|