Perl far from dead, more popular than you think (Royal Pingdom)
Perl far from dead, more popular than you think (Royal Pingdom)
Posted Nov 6, 2009 22:41 UTC (Fri) by rfunk (subscriber, #4054)In reply to: Perl far from dead, more popular than you think (Royal Pingdom) by jhoger
Parent article: Perl far from dead, more popular than you think (Royal Pingdom)
boilerplate.
In all fairness, Perl does have Moose available (but not standard), which
everyone seems to love. But using it requires the most tortured syntax this
side of INTERCAL, unless you use another even more nonstandard add-on
(MooseX::Declare, I think).
I prefer getting my powerful language without a pile of "package This" and
"use That" needed at the top before it's bearable.
In addition, Perl doesn't distinguish well between scalars and references,
but does distinguish between references and the hashes or arrays they
reference; this causes loads of bugs. Ruby doesn't need references at all
because *everything is an object*. That concept is amazingly powerful.
Plus, Perl's standard library is sadly dated; too many of the really useful
library modules need to be pulled from CPAN. Ruby's standard library,
however, is quite rich. (And lots of user-contributed "gems" are also
available.)
Perl was built for a particular culture: the 90s Unix culture already
familiar with C, Bourne and C shells, awk, and sed. Anyone not from that
culture finds Perl difficult, and anyone who's moved beyond that culture in
the past decade (in hopes of working with managable code) finds it quaint
and annoying.
Here's a fun rant about some of Perl's problems:
http://steve.yegge.googlepages.com/ancient-languages-perl
Posted Nov 6, 2009 23:12 UTC (Fri)
by chromatic (guest, #26207)
[Link] (17 responses)
Which way do you want it? Either it's okay to use user-contributed libraries (CPAN, gems), or you only stick with the standard library. Why is it a slight on Perl 5 that so much evolution happens outside the core but not a slight on Ruby (especially given the proclivities for monkeypatching core classes and libraries in Ruby gems)?
> Here's a fun rant about some of Perl's problems:
I know Steve. I like Steve. Even so, it's awfully difficult to write an accurate criticism of Perl 5's actual faults without understanding lists, arrays, and context in much more detail than his essay demonstrates. In particular, the "Perl 5 flattens nested lists!" argument *always* is shorthand for "I don't understand context, parentheses, and arrays in Perl 5 because I think they should work like they do in some other language which doesn't have list context."
Posted Nov 6, 2009 23:39 UTC (Fri)
by rfunk (subscriber, #4054)
[Link] (16 responses)
When I write in Perl, I need to install a pile of CPAN modules before I can
I just don't see what's so hard to understand about "rich standard library
As for Steve's rant.. first, I didn't claim it was conclusive or complete,
Posted Nov 7, 2009 0:12 UTC (Sat)
by chromatic (guest, #26207)
[Link] (10 responses)
I disagree. Anyone who talks of lists in Perl 5 as if they were a first-class construct doesn't understand lists in Perl 5. In particular, parentheses do not create rvalue lists in Perl 5. (If you prefer an argument by analogy, compare the expressions "3 * 3", "(3) * 3", and "(3,) * 3" in Python and Ruby. Some surprise lurks there however your language handles this.)
As well, it was perfectly possible to nest arrays in Perl 4, even if the syntax was bletcherous -- far worse than reference syntax. You'll never catch me defending Perl 5 reference syntax, but there are very few options for combining list context with list flattening. I suppose parentheses *could* create rvalue lists, but that would cause a lot of other unpleasant tradeoffs in other parts of the system.
> I just don't see what's so hard to understand about "rich standard library beats poor standard library".
One of the most important (and most successful) goals of Perl 5 circa 1994 was to enable a rich ecosystem outside the Perl 5 core. I believe CPAN demonstrates that admirably. Perl 5 may not be your favorite language and that's perfectly acceptable -- it's not a language for everyone -- but I find the criticism odd that Perl 5 has succeeded in that goal, especially that Perl 5 goes out of its way to allow maintenance and development of many core modules outside of the core as well as upgrading of those core modules outside the core.
That comes at a cost, but it's a deliberate goal of development.
Posted Nov 8, 2009 8:59 UTC (Sun)
by epa (subscriber, #39769)
[Link] (9 responses)
Posted Nov 8, 2009 12:15 UTC (Sun)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Nov 8, 2009 21:44 UTC (Sun)
by chromatic (guest, #26207)
[Link] (1 responses)
Can you provide a reference for this? I checked the Perl 6 synopses prior to responding, in case Larry had changed his mind in the past 24 hours, but Perl 6 still has context.
Posted Nov 8, 2009 23:35 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Nov 8, 2009 21:48 UTC (Sun)
by chromatic (guest, #26207)
[Link] (5 responses)
If you try to program Perl 5 by pretending that everything means the same in Perl 5 as it does in other languages, you will write buggy, confusing code.
Posted Nov 9, 2009 11:25 UTC (Mon)
by epa (subscriber, #39769)
[Link] (4 responses)
Posted Nov 9, 2009 21:16 UTC (Mon)
by chromatic (guest, #26207)
[Link] (3 responses)
That's not a problem unique to Perl. I posted elsewhere in this thread some very short Ruby and Python examples which I believe violate the principle of least surprise because the meaning of parentheses switches between creating lists (or tuples or whatever you want to call them) and grouping expressions. Again, this is not a matter of Perl's peculiarities. I believe the Perl approach makes more sense; different punctuation characters do different things. Sure, but we're talking about operator precedence, grouping, and false cognates here. Show me a beginner who doesn't know anything about lists or arrays in any programming language and the first two will still be difficult concepts to understand. Perhaps that is true for experienced programmers who've used a similar language with similar semantics before. I don't believe nested data structures are obvious to programming novices in any language. (Again, I won't defend Perl 5's dereferencing syntax -- but you won't convince me that a neophyte programmer can guess that nested data structures exist with the specific Python or Ruby syntax from reason alone.)
Posted Nov 10, 2009 0:30 UTC (Tue)
by alankila (guest, #47141)
[Link] (2 responses)
@foo = (1,2,3); # depreciated
Unfortunately the syntax for references then gets a few annoying {} and -> which the @ and % versions can avoid, so stuff that should be simple looks ugly as heck.
I agree with the base criticism of the grandparent: everyone learning Perl5 will have to climb that particular roadblock of untangling the rather subtle meaning of "@a = (1,2,3)" and then the completely different "$a = [1,2,3]".
Posted Nov 10, 2009 2:16 UTC (Tue)
by chromatic (guest, #26207)
[Link] (1 responses)
I think you also break list context and complicate the optree, when you can't determine at compilation time if a list is constant or if it's merely part of an array constructor.
Posted Nov 10, 2009 6:34 UTC (Tue)
by alankila (guest, #47141)
[Link]
That being said, it's a bit frustrating if you would need some third kind of collection, there's no syntax available for that. But that's a completely different argument, and my opinion is that there's no real need to use every symbol on the keyboard, anyway: a single generic syntax seems cleaner to me than allocating every type of brace for something. Java only has fixed-size arrays available on syntactic level and no hashes at all: method calls work as the generic extension mechanism. PHP apparently decided to just implement arrays as hashes and forget about having "real", numerically indexed arrays.
As to the second point, I'm not even proposing removal of anything, I was just suggesting that the @foo and %foo style variables could/should be avoided as unnecessary in new code.
On a tangential note, here's another of these famous Perl hacks which indicates that Perl currently plays fast-and-loose about which lists are constants and which are not:
$ perl -wle 'sub bug { print map $_++, 1..3; } bug(); bug()'
For some reason this never bites anyone, allegedly.
Posted Nov 7, 2009 11:19 UTC (Sat)
by niner (subscriber, #26151)
[Link] (4 responses)
"now" is 15 years in this case! Do you honestly want to complain about things that were
Posted Nov 7, 2009 14:34 UTC (Sat)
by sf_alpha (guest, #40328)
[Link] (2 responses)
When Python/Ruby not even born, Perl was used as high level scripting
People writing new code may not choose Perl, but Perl is not dying because it
One thing you cannot deny about Perl : Powerful Perl Style Regular Expression
Posted Nov 7, 2009 15:15 UTC (Sat)
by nix (subscriber, #2304)
[Link] (1 responses)
I dare you to find another language that implements (?{...}) or, hell,
Posted Nov 7, 2009 21:25 UTC (Sat)
by quotemstr (subscriber, #45331)
[Link]
Posted Nov 10, 2009 11:51 UTC (Tue)
by rfunk (subscriber, #4054)
[Link]
Posted Nov 7, 2009 7:37 UTC (Sat)
by Cato (guest, #7643)
[Link] (2 responses)
Posted Nov 8, 2009 21:41 UTC (Sun)
by drag (guest, #31333)
[Link]
Pipes and shell scripting was a nice advance, but what people really are
The language 'for the people' to carry out common programming tasks. Easy to
Perl, Python, shell, PHP, etc all fill those nitches in slightly different
Posted Nov 10, 2009 1:29 UTC (Tue)
by rfunk (subscriber, #4054)
[Link]
The Unix culture of the mid-90s was much different from the Unix culture of
Perl far from dead, more popular than you think (Royal Pingdom)
Perl far from dead, more popular than you think (Royal Pingdom)
contributions to be more interesting than adding things that most modern
language platforms have by default.
do anything useful. When I write in Ruby, I can do a lot more useful things
with the standard library. But I'm still not limited to the standard
library.
beats poor standard library".
just that it was relevant. Second, he talks about context, and the problem
of having to memorize what happens in different contexts, and the fact that
nesting lists wasn't at all possible until references were invented. The
fact that it is possible now using references (and square brackets) makes
the whole point more of a commentary on the mindset of the language
designers rather than on the current functionality of the language. And
third, I've read enough of Steve's writing to know that he understands
lists, arrays, and context just fine, As do I.
Perl far from dead, more popular than you think (Royal Pingdom)
Perl far from dead, more popular than you think (Royal Pingdom)
Perl far from dead, more popular than you think (Royal Pingdom)
these days, even Larry Wall. It confuses everyone on first encountering
the language, keeps causing bugs as people mistake which context they're
in, and is widely regarded as a mistake.
Perl far from dead, more popular than you think (Royal Pingdom)
The concept of 'contexts' is unloved by pretty much everyone
these days, even Larry Wall.
Perl far from dead, more popular than you think (Royal Pingdom)
afraid. None public :/ I've blown half an hour googling and have come to
the conclusion that he's never said this anywhere Google can see it, so
feel free to ignore it completely.
Perl far from dead, more popular than you think (Royal Pingdom)
The trouble is that parentheses also *look like* list creation symbols in Perl. For example,Perl far from dead, more popular than you think (Royal Pingdom)
my @a = (1, 2, 3);
This is wrong:
my @a = 1, 2, 3;
So () makes a list? No, not really, since this doesn't work as you'd expect:
my @nested = ((1, 2), (3, 4));
In fact the list constructor is []. But then, this is also incorrect:
my @nested = [[1, 2], [3, 4]];
The right answer is to use a mixture of both:
my @nested = ([1, 2], [3, 4]);
Once you get used to Perl's peculiarities this starts to make sense - but you can't pretend it is straightforward for the beginner. Perl has a whole tutorial (perldsc) on how to accomplish the feat of nested data structures, which in Python or Ruby are so obvious they need no explanation.
Perl far from dead, more popular than you think (Royal Pingdom)
The trouble is that parentheses also *look like* list creation symbols in Perl.
Once you get used to Perl's peculiarities this starts to make sense....
... you can't pretend it is straightforward for the beginner.
... nested data structures ... in Python or Ruby are so obvious they need no explanation.
Perl far from dead, more popular than you think (Royal Pingdom)
$foo = [1,2,3]; # endorsed.
Perl far from dead, more popular than you think (Royal Pingdom)
Perl far from dead, more popular than you think (Royal Pingdom)
123
234
Perl far from dead, more popular than you think (Royal Pingdom)
bad in a time before the competition was even visible??
Perl far from dead, more popular than you think (Royal Pingdom)
is still a tool where many coders still use it, may not for web applications but
simple script.
language in most of UNIX systems where shell script not suitable or not
powerful enough, Perl also allow code sharing and binding by CPAN modules.
Script writing in that time still there now, And consider if your 120,502 lines
of Perl code work fine and simple, will u convert it to Python/Ruby/PHP for a
little advantages, same output and may even slower ? My answer is No.
still there in almost any Linux/Unix systems.
used in many modern language now.
Perl far from dead, more popular than you think (Royal Pingdom)
use PCRE (a reimplementation of the Perl regex engine without many of the
warts and more obscure features), or reimplement it themselves.
anything at all listed below it in the perlre manpage (independent
subexpressions and the like).
Boost's regular expression library implements independent subexpressions (or at least they're documented. I haven't tried to actually use them.)
Perl far from dead, more popular than you think (Royal Pingdom)
15 years ago
You mentioned
Perl far from dead, more popular than you think (Royal Pingdom)
the 90s Unix culture already
familiar with C, Bourne and C shells, awk, and sed
This is more of a '70s, 80s and 90s' culture, since Unix was invented in 1969 - see Wikipedia's Unix page.
Perl far from dead, more popular than you think (Royal Pingdom)
looking for is a programming languages that is 'fast enough' and is easy to
program in, easy to read other people's code, and easy to re-use the work of
others without having to put a lot of effort into understanding the work of
others.
use and yet still rewards high levels of expertise.
ways.
Perl far from dead, more popular than you think (Royal Pingdom)
1969. As well as different from the Unix cultures of the mid-70s, the mid-
80s, and today.