Perl far from dead, more popular than you think (Royal Pingdom) [LWN.net]

A Modest List of Newer Sites Running Perl

Posted Nov 6, 2009 19:32 UTC (Fri) by chromatic (guest, #26207) [Link]

What do you mean by "new" or "important"? Does the BBC iPlayer qualify?

Sites Running Catalyst is several months out of date, but it lists several other sites not on the article's list.

A Modest List of Newer Sites Running Perl

Posted Nov 6, 2009 19:53 UTC (Fri) by MisterIO (guest, #36192) [Link]

New = let's say, in the last year
Important = "big hitter"

A Modest List of Newer Sites Running Perl

Posted Nov 7, 2009 23:09 UTC (Sat) by Cato (subscriber, #7643) [Link]

BBC iPlayer is a huge site in the UK, as it lets people catch up on TV programmes from the BBC, and there are many people outside the UK who would like to use it.

A Modest List of Newer Sites Running Perl

Posted Nov 12, 2009 12:36 UTC (Thu) by dskoll (subscriber, #1630) [Link]

We wrote a REST-based API for our product using Catalyst. It was, alas, a huge mistake, and we are rewriting it in (ugh) PHP.

Catalyst is really, really cool, but like many things in the Perl world, its problem is that it strives to be really, really cool. It's under-documented, over-engineered, and keeps evolving so you can't count on a stable API. It has an insane number of dependencies (by moving away from Catalyst, we can reduce the number of CPAN modules we have to ship by about 30!) and is big and bloated. Catalyst is also TIMTOWTDI gone nuts, so when I started using it, I was never sure what the "best" way to do something was, and wasted endless hours doing things one way only to find that the idiomatic way to do them was completely different.

As I wrote in another post, I really like Perl, but the direction it's heading in is very worrying.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 20:10 UTC (Fri) by stijn (subscriber, #570) [Link]

Perl is very big in bioinformatics, which is not a recent thing however. I am probably stuck in my
ways, but to me it is additionally hard to beat in terms of succinctness (for small applications and
data processing) and features. Its regular expressions, multidimensional data structures, and map +
grep + sort make it very effective.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 21:30 UTC (Fri) by rfunk (subscriber, #4054) [Link]

Of course, Ruby has all those just as succinctly in a much more modern
language. Not that I expect the bioinformatics people to convert their mass
of code anytime soon. :-)

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 21:47 UTC (Fri) by stijn (subscriber, #570) [Link]

I seem to remember, when looking at Ruby, that creating hashes of arrays of hashes et cetera was
definitely not as succinct as in Perl, far from it. I will gladly be proven wrong, with the caveat that
succinctness and not modernity or what-have-you is what the statement is about.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 22:12 UTC (Fri) by rfunk (subscriber, #4054) [Link]

Creating the data structures you're talking about is nearly identical in Perl and Ruby. (I intentionally left out PHP, since it's much more painful there; I don't remember Python enough to say.)

# Perl
$lwn_ref = {
 users => [
  { id => 570, username => 'stijn' },
  { id => 4054, username => 'rfunk' },
 ],
 articles => [
  { id => 360847,
    title =>
     "Perl far from dead, more popular than you think (Royal Pingdom)" },
  { id => 360803,
    title => "Security advisories for Friday" },
 ],
};
$my_userid = $lwn_ref->{users}[1]{id};

# Ruby
lwn = {
 :users => [
  { :id => 570, :username => 'stijn' },
  { :id => 4054, :username => 'rfunk' },
 ],
 :articles => [
  { :id => 360847, :title => "Perl far from dead, more popular than you 
think (Royal Pingdom)" },
  { :id => 360803, :title => "Security advisories for Friday" },
 ],
}
my_userid = lwn[:users][1][:id]

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 22:28 UTC (Fri) by foom (subscriber, #14868) [Link]

The equivalent data in Python. Same thing, pretty much...

lwn = {
 'users': [
  { 'id': 570, 'username': 'stijn' },
  { 'id': 4054, 'username': 'rfunk' },
 ],
 'articles': [
  { 'id': 360847,
    'title': 
      "Perl far from dead, more popular than you think (Royal Pingdom)" },
  { 'id': 360803,
    'title': "Security advisories for Friday" },
 ],
}

my_userid = lwn['users'][1]['id']

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 3:20 UTC (Sat) by yarikoptic (subscriber, #36795) [Link]

just a matter of taste, but if someone dislikes abuse of quotes, here is equivalent:

lwn = dict(
 users = [
  dict( id=570,  username='stijn' ),
  dict( id=4054, username='rfunk' ),
 ],
 articles = [
  dict( id=360847,
        title=
        "Perl far from dead, more popular than you think (Royal Pingdom)" ),
  dict( id=360803,
        title="Security advisories for Friday" ),
 ],
)

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 4:09 UTC (Sat) by jordanb (guest, #45668) [Link]

You guys win the prize for the most tedious language comparison in LWN history.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 5:12 UTC (Sat) by mikov (subscriber, #33179) [Link]

And here is the same thing in ANSI C!

#include <stdio.h>

...
Ah, just kidding :-)

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 22:12 UTC (Sat) by wingo (subscriber, #26929) [Link]

Hahaha, thank you :) That was a nice chuckle :)

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 22:31 UTC (Fri) by stijn (subscriber, #570) [Link]

Let's try a different and for me more realistic scenario.

Perl:

my %dataframe = ();

while (<>) {
   my @F = split;
   push @{$dataframe{$F[0]}{$F[1]}}, { foo => $F[2], bar => $F[3] };
}

Ruby: ?

This uses Perl's autovivification features. They are not always suitable but a great feature nonetheless. If Ruby has something as succinct I will definitely start using it. I am not arguing that this particular feature places Perl above another language. But it's a feature I find very useful. That aside, Perl is a tool, and not a bad tool at all. I am a bit wary of perl6 though. Perhaps the offfshoots will be worthwhile (Parrot) but the language itself seems just to have too much syntax.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 23:08 UTC (Fri) by foom (subscriber, #14868) [Link]

Python (assuming I've read the perl correctly: I don't know perl all that well):

import sys
dataframe = {}

for line in sys.stdin:
   F = line.split()
   dataframe.setdefault((F[0], F[1]), []).append({ 'foo': F[2], 'bar': F[3] })

or, you can also say the following, which might be closer to perl's "autovivification" (?):

import sys, collections
dataframe = collections.defaultdict(list)

for line in sys.stdin:
   F = line.split()
   dataframe[F[0], F[1]].append({ 'foo': F[2], 'bar': F[3] })

The disadvantage of python is that you don't get to use fun words like "autovivification".

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 22:01 UTC (Sat) by njs (guest, #40338) [Link]

IIRC, the Python equivalent to Perl's <> is actually 'import fileinput; for line in fileinput.input(): ...'

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 9, 2009 7:28 UTC (Mon) by jamesh (guest, #1159) [Link]

Really? I've never bothered using the fileinput module in my programs. What features of Perl's <> operator do you miss out on by using Python's standard file objects?

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 9, 2009 8:18 UTC (Mon) by njs (guest, #40338) [Link]

Just some of the standard perl magic -- '<>' doesn't give you lines from stdin, it gives you "if there are any arguments to the script, treat them as pathnames, open them one at a time, and if along the way you bump into a file named '-' then read stdin at that point, or if there aren't any arguments just read stdin". Which is a common convention for unix command line tools (see cat, tr, etc.).

I've never used fileinput either -- but people who are used to using <> to express all that magic might be annoyed at being told that sys.stdin was equivalent.

(Oh, and it also has features to emulate perl's '-i' switch and maybe some other bells and whistles, see the docs.)

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 10, 2009 15:36 UTC (Tue) by jamesh (guest, #1159) [Link]

Fair enough. I guess it'd depend on whether the original Perl program was intended to make use of all those features, or was just using it as a shorthand for <STDIN> (I think that's correct. It's been a long time since I've programmed in the language).

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 23:30 UTC (Fri) by rfunk (subscriber, #4054) [Link]

Ah, you want autobugification! :-) In my experience, autovivification causes as many problems as it solves. It's true that Ruby's autovivification abilities don't quite match Perl's. On the other hand, they're more powerful in some ways.

dataframe = Hash.new { |h,k| h[k] = {} } # 2-level hash autovivification

ARGF.read.each do |line|
  f = line.split
  d = dataframe[f[0]][f[1]] ||= []
  d.push({ :foo => f[2], :bar => f[3] })
end

Oh yeah, I hate Perl's "my" too. Automatic local scope is a good thing, and I find it much more useful to use the sigils for scoping than for typing.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 23:48 UTC (Fri) by rfunk (subscriber, #4054) [Link]

Come to think of it, its closer to the Perl (and just better) to change the
"ARGF.read.each" to "ARGF.each_line". The .read.each version reads the whole
file at once, then loops over the result, while the .each_line version reads
one line at a time.

BTW, Perl was part of the initial inspiration for Ruby, so there are lots of
Perl-like features (and some Perl-lookalike features) in Ruby.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 23:53 UTC (Fri) by stijn (subscriber, #570) [Link]

I seem to recall mentioning that 'autovivification' is not always suitable. The code is interesting -
I advise a more detached approach towards tools though.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 9, 2009 1:18 UTC (Mon) by jmm82 (guest, #59425) [Link]

succinct = "Unmaintainable by anybody except the author"

I love writing throw-away perl scripts, but dread maintaining someone else's succinctness. I know everyone argues you can write maintainable perl code, but it leaves far too much room for someone to obfuscate the code into trash.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 9, 2009 8:16 UTC (Mon) by niner (subscriber, #26151) [Link]

> I know everyone argues you can write maintainable perl code, but it leaves far too
much room for someone to obfuscate the code into trash.

But that's not different from any other language (that I know). I still have to maintain PHP
and Python code I inherited and no, none of these is any more maintainable than the
Perl code. And really, not even the Python stuff. Just pick completely non-descriptive
variable names and completely screw up your code structure and someone will feel real
pain.

Nowadays we create only Perl code. And part of the reason is, that we have a very fine
testing framework, Test::Pod::Coverage to test for documentation coverage,
Test::Perl::Critic to automatically uncover coding style errors which could lead to
unmaintainable code and Devel::Cover to test the test suite's coverage of the code. With
those tools and some architectural review before coders start programming, it's very hard
to write something unmaintainable.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 9, 2009 16:44 UTC (Mon) by jmm82 (guest, #59425) [Link]

Every language has there "nooks and crannies", but perl goes out of its way to create as many "nooks and crannies" as possible and then has contests to promote their use. I am sure that there is some very robust perl code written within a constrained environment where maintainability is enforced.

I respect perl for its innovations in the field of scripting and regular expressions, but if I was starting a project from scratch, I would choose Python or PHP over perl. Perl is by no means close to dead, but neither is COBOL.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 0:13 UTC (Sat) by Thue (subscriber, #14277) [Link]

PHP is a little more painful, but not that bad. This example would be longer but more readable and maintainable if one used PHP objects instead

# PHP
$lwn_ref = Array(
 "users" => Array(
   Array("id" => 570, "username" => 'stijn'),
   Array("id" => 4054, "username" => 'rfunk'),
 ),
 "articles" => Array(
    Array("id" => 360847,
          "title" => "Perl far from dead, more popular than you think (Royal Pingdom)"),
    Array("id" => 360803,
          "title" => "Security advisories for Friday"),
 )
);
$my_userid = $lwn_ref["users"][1]["id"];

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 21:52 UTC (Fri) by jhoger (guest, #33302) [Link]

Personally, I find Perl to be a modern, expressive language that I know well with a very wide base of third party components.

Please elaborate as to what the "modern language" Ruby has that Perl does not. Let's say, Perl 5.10 to keep things fair.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 22:02 UTC (Fri) by cyperpunks (subscriber, #39406) [Link]

> Please elaborate as to what the "modern language" Ruby has that Perl does not.

A sane object model.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 22:23 UTC (Fri) by nix (subscriber, #2304) [Link]

This is what the Moose package is for. It's a bloody amazing object
system, to be honest, knocking the socks off everything else I've ever
heard of bar CLOS.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 8, 2009 8:54 UTC (Sun) by epa (subscriber, #39769) [Link]

I imagine what the OP wants is a sane object model by default, used consistently by the standard library, third-party libraries, tutorials and so on.

Moose is great, but for a fair comparison, Perl+Moose would need to be treated as a separate language, whose installed base and available libraries are much smaller than Perl. And even Perl+Moose would not use a sane object model for most of its builtins and standard library, which have a variety of peculiar interfaces.

Language arguments in general can get bogged down like this: language X does not have feature Y! Yes it does, just install optional package P!

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 8, 2009 12:14 UTC (Sun) by nix (subscriber, #2304) [Link]

Perl+Moose shouldn't be considered a separate language because it *is*
interoperable with Perl (except if you want to inherit from some non-Moose
using module's classes, I suppose. Moose probably has a way to do that too
that I haven't discovered). You lose no compatibility, the interpreter is
the same, it all lives in the same address space, it's one CPAN install
away to convert Perl to 'Perl+Moose', it's the same language in every way
other than some new syntax. The only environment in which you might care
is some pointlessly fascist one in which installation of new packages,
even in your own PERL5LIB directory, is forbidden --- and how can you run
any new code in such an environment anyway? (Such environments do exist,
and asking that question is a good way to reduce their administrators to
spluttering incoherence.)

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 8, 2009 21:07 UTC (Sun) by epa (subscriber, #39769) [Link]

I care because even if I install Moose on my perl5 installation, it doesn't magically cause the 'sane object model' to apply to the standard library or to most existing third-party code. The new object model is just something I can use for new code, which still has to be mixed with old-style perl5 OO, failed past attempts at a standard OO model (Class::Std etc etc), and most of all, all kinds of weird and wonderful interfaces which aren't OO at all (regexps) or exist in a peculiar halfway land where they behave somewhat like objects some of the time (filehandles, stat() tests).

There are good historical reasons for all of this and it doesn't stop me using perl as my main language. But it's hardly a fair comparison with Ruby, say, where a good object system is not only available as an extra, but consistently *used*.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 22:32 UTC (Fri) by jhoger (guest, #33302) [Link]

Please... what's "insane" about Perl's default object model? I find that it lets me do the level of object oriented programming when I want, the way I want. I think bless() is one of the most clever, simple, minimalist inventions of all time.

One of the great things about Perl is that everything is laid bare... you can scale your problem from a simple function, up to an ADT with a package, or further to an object depending on need. You aren't forced to pick a particular level.

For those that like a heavy feature-filled object system there's Moose.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 22:48 UTC (Fri) by rfunk (subscriber, #4054) [Link]

bless() is a clever hack to tack OO onto a language that wasn't designed
for it. The fact that every "sub new{}" requires a bless() is a bug, not a
feature.

Not to mention the way you have to pull the instance off the top of the
parameter list as the first thing you do in every method. (A bug that Larry
took from Python but now regrets, though the Perl version is worse because
of Perl's already-broken parameter-pulling.)

"Everything is laid bare" is another way of saying it's a low-level
language. After all, if you really want everything laid bare why not
program in assembly or C? I've seen OO done in C, after all. :-)

And I mentioned above that Moose is an improvement on functionality but too
ugly and unwieldy.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 11:13 UTC (Sat) by niner (subscriber, #26151) [Link]

If you don't want to unpack $self and the rest of the parameters, just use
MooseX::Method::Signatures:

package Foo;

use Moose;
use MooseX::Method::Signatures;

method morning (Str $name) {
$self->say("Good morning ${name}!");
}

And "ugly" is just a matter of taste.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 22:41 UTC (Fri) by rfunk (subscriber, #4054) [Link]

A sane object model with sane syntax, without an ungodly amount of
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

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 23:12 UTC (Fri) by chromatic (guest, #26207) [Link]

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

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

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 6, 2009 23:39 UTC (Fri) by rfunk (subscriber, #4054) [Link]

I want a rich standard library with great power by default. I want user
contributions to be more interesting than adding things that most modern
language platforms have by default.

When I write in Perl, I need to install a pile of CPAN modules before I can
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.

I just don't see what's so hard to understand about "rich standard library
beats poor standard library".

As for Steve's rant.. first, I didn't claim it was conclusive or complete,
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)

Posted Nov 7, 2009 0:12 UTC (Sat) by chromatic (guest, #26207) [Link]

> I've read enough of Steve's writing to know that he understands lists, arrays, and context just fine....

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.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 8, 2009 8:59 UTC (Sun) by epa (subscriber, #39769) [Link]

I think the distinction between lists and arrays, which experts understand but everyone else is unaware of, is one of the flaws in Perl 5.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 8, 2009 12:15 UTC (Sun) by nix (subscriber, #2304) [Link]

Seconded. The concept of 'contexts' is unloved by pretty much everyone
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)

Posted Nov 8, 2009 21:44 UTC (Sun) by chromatic (guest, #26207) [Link]

The concept of 'contexts' is unloved by pretty much everyone these days, even Larry Wall.

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.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 8, 2009 23:35 UTC (Sun) by nix (subscriber, #2304) [Link]

The reference is fading memory and some comments from Simon Cozens, I'm
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)

Posted Nov 8, 2009 21:48 UTC (Sun) by chromatic (guest, #26207) [Link]

If it's a flaw (and I don't see it as a flaw), it's a flaw that Perl borrowed parentheses as grouping symbols while other languages borrowed parentheses as grouping symbols as well as list creation symbols. Whose fault is a false cognate?

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.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 9, 2009 11:25 UTC (Mon) by epa (subscriber, #39769) [Link]

The trouble is that parentheses also *look like* list creation symbols in Perl. For example,
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)

Posted Nov 9, 2009 21:16 UTC (Mon) by chromatic (guest, #26207) [Link]

The trouble is that parentheses also *look like* list creation symbols in Perl.

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.

Once you get used to Perl's peculiarities this starts to make sense....

Again, this is not a matter of Perl's peculiarities. I believe the Perl approach makes more sense; different punctuation characters do different things.

... you can't pretend it is straightforward for the beginner.

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.

... nested data structures ... in Python or Ruby are so obvious they need no explanation.

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

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 10, 2009 0:30 UTC (Tue) by alankila (subscriber, #47141) [Link]

I just think it's plainly unfortunate that @ and % still exist, given that all that you could have got with them is now doable with references and the corresponding constructors of those structures. So imagine that newbie documentation only said:

@foo = (1,2,3); # depreciated
$foo = [1,2,3]; # endorsed.

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

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 10, 2009 2:16 UTC (Tue) by chromatic (guest, #26207) [Link]

PHP tried single-sigil variables; it works about as well there as does making all arrays associative (not indexed). The semantics are messy when you do anything non-trivial and you actually *lose* type information when reading code.

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.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 10, 2009 6:34 UTC (Tue) by alankila (subscriber, #47141) [Link]

Well, Perl references go $foo->[] and $foo->{} for the two kinds we have in mind here. They are clearly distinct and no information is lost by not having @ and % visible in this expression.

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()'
123
234

For some reason this never bites anyone, allegedly.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 11:19 UTC (Sat) by niner (subscriber, #26151) [Link]

"The fact that it is possible now using references (and square brackets)"

"now" is 15 years in this case! Do you honestly want to complain about things that were
bad in a time before the competition was even visible??

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 14:34 UTC (Sat) by sf_alpha (guest, #40328) [Link]

Agree. Those guys comparing 15 years old language with something new. Perl
is still a tool where many coders still use it, may not for web applications but
simple script.

When Python/Ruby not even born, Perl was used as high level scripting
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.

People writing new code may not choose Perl, but Perl is not dying because it
still there in almost any Linux/Unix systems.

One thing you cannot deny about Perl : Powerful Perl Style Regular Expression
used in many modern language now.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 15:15 UTC (Sat) by nix (subscriber, #2304) [Link]

Well, yeah, but other languages use perl *style* regexes. They generally
use PCRE (a reimplementation of the Perl regex engine without many of the
warts and more obscure features), or reimplement it themselves.

I dare you to find another language that implements (?{...}) or, hell,
anything at all listed below it in the perlre manpage (independent
subexpressions and the like).

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 21:25 UTC (Sat) by quotemstr (subscriber, #45331) [Link]

Boost's regular expression library implements independent subexpressions (or at least they're documented. I haven't tried to actually use them.)

15 years ago

Posted Nov 10, 2009 11:51 UTC (Tue) by rfunk (subscriber, #4054) [Link]

Obviously you didn't even bother reading the rest of that sentence.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 7:37 UTC (Sat) by Cato (subscriber, #7643) [Link]

You mentioned

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)

Posted Nov 8, 2009 21:41 UTC (Sun) by drag (subscriber, #31333) [Link]

Perl helped kill the 'one tool for one thing' mantra.

Pipes and shell scripting was a nice advance, but what people really are
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.

The language 'for the people' to carry out common programming tasks. Easy to
use and yet still rewards high levels of expertise.

Perl, Python, shell, PHP, etc all fill those nitches in slightly different
ways.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 10, 2009 1:29 UTC (Tue) by rfunk (subscriber, #4054) [Link]

I was quite deliberate about what I said there.

The Unix culture of the mid-90s was much different from the Unix culture of
1969. As well as different from the Unix cultures of the mid-70s, the mid-
80s, and today.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 9:51 UTC (Sat) by marduk (subscriber, #3831) [Link]

> Perl is very big in bioinformatics,

So is MUMPS, another dead programming language.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 20:21 UTC (Sat) by Wol (guest, #4433) [Link]

MUMPS dead? I hadn't heard ...

Actually, in its current incarnation of Cache, I gather it's growing quite fast. It's similar to (but not a member of) the MultiValue/PostRelational databases which are also growing quite fast ...

Last I heard the IBM MV databases (U2 - but they've just sold them) were growing market share at over 10% per year.

Cheers,
Wol

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 7, 2009 23:04 UTC (Sat) by Cato (subscriber, #7643) [Link]

Perl is big in bioinformatics, meaning the application of information technology to molecular biological research. http://en.wikipedia.org/wiki/Bioinformatics

MUMPS is big in medical information systems, as used in hospitals and clinics, which is an entirely different area. http://en.wikipedia.org/wiki/Health_informatics

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 8, 2009 4:29 UTC (Sun) by roskegg (subscriber, #105) [Link]

Newlisp takes all those advantages, and adds some syntactic sugar that makes it almost as compact, but much much more readable. http://newlisp.org/

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 8, 2009 12:12 UTC (Sun) by nix (subscriber, #2304) [Link]

Some parts of newlisp look really nice, but... no closures, but some new
construct instead, requiring slightly different syntax than function
declarations? All function arguments optional? Pointing up the lack of
compilation like it's an advantage? ('fully dynamic', er, you can be fully
dynamic *and* compiled at the same time and lots of Lisps do it,
SBCL/CMUCL for starters)

The macro tweaks are mostly nice but the 'differences from other lisps'
document had entirely too many 'oh god WTF what were they on' moments for
me to be quite comfortable with it. Some rationales might be nice. (e.g.
what is the possible advantage of making all function arguments optional?
I can see none unless you like cluttering up your code with lots of
runtime argument checking or coping with baroque bugs because of a
one-word typo.)

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 8, 2009 21:46 UTC (Sun) by roskegg (subscriber, #105) [Link]

The best argument for newLISP is its results; it is almost as compact as Perl, as fast as Perl, and has a very small binary footprint, plus it has a lot of qualities perl doesn't have, such as a very easy method of shipping as a binary application and saving current state of the application for later resumption of computation. Plus it has lots of nifty stuff perl doesn't.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 8, 2009 23:36 UTC (Sun) by nix (subscriber, #2304) [Link]

Oh, it's surely a lot nicer than Perl (if you ignore CPAN, which you
really can't if evaluating this sort of thing: it's CPAN that drives me to
use Perl even though I really dislike it as a language). But some of its
differences from normal Lisps seem strange.

Fun with Perl, 2009: ikiwiki

Posted Nov 6, 2009 22:53 UTC (Fri) by dmarti (subscriber, #11625) [Link]

I used to think I only had to pay attention to Perl to tweak around with Spamassassin any more. Then Joey Hess wrote ikiwiki.

"Ikiwiki is a wiki compiler. It converts wiki pages into HTML pages suitable for publishing on a website. Ikiwiki stores pages and history in a revision control system such as Subversion or Git. There are many other features, including support for blogging, as well as a large array of plugins."

Best. Wiki. Ever. Now a wiki that I can't "git clone" and "git push" to is like a pizza that I have to eat with a knife and fork. I keep waiting for someone to do an ikiwiki-like tool in another language, and until that happens I'll keep up with Perl.

Fun with Perl, 2009: ikiwiki

Posted Nov 7, 2009 4:23 UTC (Sat) by joey (subscriber, #328) [Link]

Thanks Don.

The funny part of that story to me is that shortly after I started ikiwiki,
I got several negative comments from people about having chosen perl. These
petered out after a week or two, and I don't hear that at all anymore. I do
hear occasionally of people who had to learn or refresh their perl-fu in
order to write a plugin (although ikiwiki also lets you do that in eg,
python).

And the development community around it is not huge, but big enough to be
healthy. (More than 30 contributors, more than 100 plugins; more incoming
code than I often have time to review on my own.)

I guess I probably turned off a few potential contributors / users right at
the beginning by using perl, but once it got up to the plausible promise
stage, people seemed to be more interested in what it could do, and how,
than implementation details.

If you are looking for something like this not in perl, you could try GitIt (http://gitit.johnmacfarlane.net/) which has at least a few of the
same ideas as ikiwiki (use of git, markdown) but is notably not a static
site compiler. It seems to have a smaller development community (6
committers, 9 plugins), though I hesitate to say that's because it's
written in a less popular (but currently possibly more trendy language) --
haskell, or maybe because it's younger.

I've written enough perl not to be a fan of it for anything large, and this
is likely my last big perl project. I would personally now prefer ikiwiki
were written in haskell, but only if people were still able to contribute
to it. I doubt that writing it in ruby or python would have increased the
contributor pool greatly, and I see no other advantages to using those
languages.

(Well, except for their lack of a few horrid perl warts such as `func($_)
foreach @list` being able to mutate the contents of the list if the
function modifies its input value.)

BTW, did you know that someone is writing an apt-get clone in perl?

Fun with Perl, 2009: ikiwiki

Posted Nov 7, 2009 5:43 UTC (Sat) by MisterIO (guest, #36192) [Link]

> BTW, did you know that someone is writing an apt-get clone in perl?
Ugh, why?!

Fun with Perl, 2009: ikiwiki

Posted Nov 12, 2009 20:13 UTC (Thu) by Velmont (guest, #46433) [Link]

Have been looking much at ikiwiki. But my perl angst has kept me from trying it. Also looked at Gitit (haskell), but am now waiting for/will help with uWiki (lua) when it gets usable enough.

I find it amusing that all of the Git-backed wikis use strange languages.

Fun with Perl, 2009: ikiwiki

Posted Nov 12, 2009 22:53 UTC (Thu) by nix (subscriber, #2304) [Link]

I'm not sure Perl counts as 'strange' for this sort of thing. It's pretty
much the common case...

Fun with Perl, 2009: ikiwiki

Posted Nov 15, 2009 1:24 UTC (Sun) by Per_Bothner (subscriber, #7375) [Link]

I don't know or care for Perl. but I like and use IkiWiki for my blog. I was able to figure it out for a moderate amount of customization. It's nice to be able to read and edit blog/wiki pages off-line, and then upload static pages to a web server, without being dependent on the software offered by the hosting provider. (I don't make use of the commenting, wiki/editing, or version control features, since it just for my personal blog.)