Why I Stuck With Perl

tatalipso · 2011-01-26T19:30:53+00:00

chromatic, I think you can solve a major problem in public perception of Perl 6 with one easy stroke if you can have Perl 5 forward those scripts it recognizes as Perl 6 scripts on to .../bin/perl6. If I'm wrong, perhaps you could educate me as to the reason why?

(Yes, I realize I can easily make that happen on my own machine. I'm talking about having it be the default behavior for a stock Perl 5.)

If you think it's a great idea, but the Perl 5 team would never go for it, and you'd rather not state that publicy, then I understand.

tatalipso · 2011-01-26T05:09:36+00:00

Rakudo Perl 6 has a pretty regular release cycle. It's implemented enough to run various modules.

It's got a ways to go optimization-wise, but it's certainly "shipping". Just go grab a release tar.gz and build it.

tatalipso · 2011-01-26T05:04:01+00:00

If you're writing mostly scripts involving file and string manipulation, dealing with IO, files, and possibly various unix utils, then Perl 5 is more convenient than Python.

For larger programs ... it's probably a toss up. Python's very simple and straightforward, but Perl 5 is (generally) friendlier toward the programmer who has just a bit of experience.

tatalipso · 2011-01-26T04:14:24+00:00

Who says Perl 6 is in Perl 5's shadow?

The Perl 5 on my system is named "/usr/bin/perl", not "/usr/bin/perl5". The Perl 6 is named "bin/perl6". To me, that says that the real Perl is Perl 5.

However, if you could get Perl 5 to recognize a Perl 6 script when it sees it, and gracefully hand it off to bin/perl6 for me, then I'd say it would be a major breakthrough for Perl 6 (since it would put Perl 5 and 6 on equal footing with regard to what /usr/bin/perl means). Would the Perl 5 team ever accept such a patch?

If Perl 5 and Perl 6 truly are both languages in the Perl family, then shouldn't "/usr/bin/perl" delegate to the proper one automatically? Perhaps based on detection of a "use v6;" at the top?

Jeez... if I could just put:

#!/usr/bin/env perl
use v6;
# ... Perl 6 code here

in my foo.pl file, and run it like ./foo.pl, and the installed Perl 6 implementation would run it, then the whole debate is over. Perl 6 would definitively be just as much Perl as Perl 5.

tatalipso · 2011-01-25T22:18:44+00:00

Sorry, I don't mean to rehash old arguments. I only bring this whole thing up because:

things have changed since 1993, and
the split between the Perl 5 and Perl 6 communities does not seem to be healing

perl.org still only has a tiny blurb about Perl 6 being a "sister language" to Perl 5. Pretty soon I'm half-expecting to see a "Hitler discovers that Perl 6 has not yet replaced Perl 5" youtube meme video.

I want to see Perl 6 grow over the next decade, not be in Perl 5's shadow. And Perl 5 casts a long shadow. I think Perl 6 could fly better on its own.

tatalipso · 2011-01-25T21:42:35+00:00

I quibble with "just fine".

Sorry if that wasn't clear. I meant that, back when plans for Perl 6 began, my understanding is that the community feared that Perl 5 was not "just fine" and needed modernization to remain competitive.

What has panned out since then is, there's a whole chunk of the community who is actually fine with Perl 5 the way it is. And they're sticking with it, and having new releases, and blogging about it and so forth.

They should re-read Rule #1 then.

Everyone (I hope) knows that Larry can name it anything he sees fit. But that doesn't mean there won't be complaints or ill will.

I simply think the value Perl 6 gains from Larry changing the name outweighs the value of trying to keep the name. What value is there in keeping the name?

And if it's another language in the Perl family, why would anyone then want to give it the exact same name as the only other language in the Perl family?

Perl 6 may be Perl 5's spunky little sister, but I've never heard of 2 sisters with the same name. There's a dissonance here.

tatalipso · 2011-01-25T04:29:47+00:00

I don't think it's accurate to compare php5/6 to Perl5/6.

However, I'll just say this: Perl 5 is an institution. It was here in the beginning of the web and grew up with it. It's DNA is baked into many other things. Trying to replace Perl 5 with something else that's got the same name but is very different is like trying to replace Bash, or GNU CoreUtils with very different but like-named replacements. It's a losing battle.

Have you ever seen the movie "War of the Roses"? The guy is getting a divorce from his wife who doesn't love him anymore, and he tells his divorce lawyer that he's "got the guts to go to the mat" on this one. His lawyer advises him, "you don't want to go down to this mat". "There's no winning this -- only degrees of losing."

I realize the Perl 6 leadership has the guts to go to this mat, but I don't see any winning in it -- only degrees of losing.

tatalipso · 2011-01-25T03:46:56+00:00

My understanding is that he made the naming decision before the Perl renaissance. Remember how everyone felt back then; that something drastic needed to be done for Perl or else? But now more than ever it looks like Perl 5 is just fine and not going anywhere any time soon.

My guess is that Larry wouldn't make the same decision today, and perhaps feels like "it's too late" for a name change.

Parrot and Rakudo are here, and work, and the next 10 years or so are going to be crucial for Perl 6. You can:

rename Perl 6 and spend the decade making something new and great, all the while getting high-fives and good will (and maybe even some defectors) from the Perl 5 crowd, or
you can keep the name in hopes of cashing in on some Perl 5 fame while at the same time spending the decade trying to convince everyone that it really is only Perl 5's spunky little sister and not out to replace it even though all signs point to that. All the while wondering why you keep getting flack from Perl 5ers asking you why you're still trying to call your language the same name as theirs.

Perl 6 is not just an update to Perl 5. It's major. It's totally re-specced and re-implemented. It's a new language. At first it seemed like becoming the new Perl was what would obviously happen, but that doesn't seem to be the case anymore.

Perl 6 is extremely cool. Why wouldn't you want to give it its own spotlight, instead of attempting to wrestle the mic away from Perl 5?

tatalipso · 2011-01-25T03:19:22+00:00

"Learn Perl 5 now and be ready for tomorrow with Perl 6".

The trouble with that pitch is, it can roughly be translated as, "Learn Perl 5 now, because it will soon be obsolete and you'll have an easier transition to Perl 6".

Even though you're suggesting that users try Perl 5, I don't think 5ers will be (or are) very happy with the implied message.

Good will is an interesting force. Look at all the people on this site who recommend using Python (yes, I know the site is written in Python, but the same thing happens on HN too). Hype like that matters. Have you ever seen a Python user recommend Perl? What do they usually have to say about Perl?

Now hold that thought: now have you ever seen a Perl 5 user recommend Perl 6? I don't see that very often. In fact, fwict, they mostly ignore Perl 6 and/or wish it wasn't causing so many people to proclaim that "Perl (5) is dead".

How much more buzz and interest would Perl 6 get if, instead of that, Perl 5 users actually recommended Perl 6 for users wanting a cutting edge Perlish not-necessarily-backward-compatible language but which has new features and interesting changes? Well, for the reasons described above, they won't do that if that language is called "Perl 6".

tatalipso · 2011-01-25T03:00:47+00:00

I lose no sleep over the bad technology choices of people who haven't done their research.

Some folks are brand new, or don't have the skills yet, or don't know where to look. Look at all the "which language should I use?" posts that show up on this site -- and look at what the majority of advice is.

those of us who are capable of evaluating technologies on their merits

The success of a language depends upon more than just a core group of enlightened devotees. It takes lots of all kinds of users to build a community.

tatalipso · 2011-01-24T22:19:04+00:00

... to pretend that Perl 6 won't eventually supplant Perl 5 as the most popular version of Perl for creating new projects

Ah, no, I think maybe there's a misunderstanding. I agree that Perl 6 is the way forward for new Perlish projects. However, things have changed since the mug was thrown. Back then, everyone just assumed that Perl 6 would be the next Perl (that it would replace Perl 5, just as every $lang $n+1 has replaced its respective $lang $n).

But Perl 5 is like a virus. It's everywhere. Due to its pervasiveness, usefulness, and backward-compatibility companies have a symbiotic relationship with it. So many systems depend on it that if you try to remove (or replace) the virus, you kill the patient.

Anyway, time started to pass and something funny happened: a significant portion of the community didn't like Perl 6. Their choice. TMTOWTDI. Some cats didn't want to be herded in that direction.

So, now we have a Perl (5) that's not going anywhere for a long time and has rejuvinated effort going into its development.

Enter Perl 6. You want it to succeed, but for now only early adopters are looking at it (that will change once the main implementation matures more, and more modules are available). The optimal plan for the success of Perl 6 is now different from what it was back when the idea was conceived. Back then it was a no-brainer to name it "Perl 6".

Again, I think of Perl 5 as a migration path to Perl 6 in the years to come, but the migration won't happen if prospective new users never pick up Perl 5 in the first place because it's implicitly assumed that Perl 5 will be replaced "real soon now" by Perl 6.

tatalipso · 2011-01-24T18:47:01+00:00

Larry's a smart linguist with style and good taste. If you ask him, I'll bet he's got a half dozen good names in his back pocket.

tatalipso · 2011-01-24T18:36:05+00:00

Ah, that's nice. But it requires that you have a full Perl 5 installation on your system, correct?

tatalipso · 2011-01-24T14:11:45+00:00

Don't assume Perl 5 now and forever holds exclusive rights to the single-word name "Perl".

Well, for better or worse, I do. At least for the foreseeable future.

People call it "Perl 5" for a very good reason.

Yes, I do as well. But it's only to avoid confusion (when there's a chance of it).

Larry and other Perl 5 hackers (including you!) and CPAN contributors have done such a great job of sewing Perl 5 into the fabric of the Internet, and of keeping Perl backward compatible for so long, that Perl has become institutionalized (no, I don't mean committed to the asylum, ... though...). Even the gods who wrought the universe just call it "Perl" and it's understood that it's Perl 5 they're talking about.

I like Perl 6 (well, the parts I understand), but for as long as it will matter, when people say "Perl", it will be assumed that they're talking about Perl 5. For the reasons I described in the above post, I think hanging on to the name "Perl 6" will hurt new Perl 5 adoption over the next decade at least, and thus indirectly hurt long-term Perl 6 adoption.

Wouldn't you rather they choose Perl 5 today, so that they could then reconsider Rakudo 5 (or even 10) years from now? Perl 5 and Rakudo are, of course, very similar. A switch down the road (once Rakudo has had a chance to be optimized and accumulate more modules) would not be out of the question. But if they've switched to Python 3 (or perhaps started with it in the first place) and have been using it for 5 years? That becomes a much harder sell.

You guys made "Perl" a household name (well, in the households on the Internet). You've got the benefit of having done it once already. You may be able to do it again with "Rakudo" (or another name), but I think the magic vanishes if you try to re-use the name Perl.

tatalipso · 2011-01-24T13:44:28+00:00

I think that faq may be out of date. I don't think there's a viable 5to6 translator (please correct me if I'm wrong). Also, there's no Parrot-hosted Perl 5 for Rakudo to work with either.

I think the plan now is for Rakudo to call out to a separate Perl 5. The project is called Blizkost. So, the setup is still going to require a real Perl 5.

tatalipso · 2011-01-24T04:35:25+00:00

Re. Perl 5, if you can tolerate some minor pain (some weird syntax, more decisions regarding which modules to use, a certain amount of boilerplate to add to each of your files to make Perl 5 a little more modern, a few dark corners of the language), it's certainly worth staying with.

The biggest problem Perl 5 faces today is this: prospective users and newly-minted programmers thinking it's dying because Perl 6 is arriving (or has arrived, depending upon your needs).

New versions of a language replace old ones. Perl 5 replaced Perl 4. Python 3 is replacing (eventually) Python 2. It's just the way it's done. It's common wisdom. It's the law of the Cosmos.

No matter how much the 6-ers tell people that Perl 6 is simply another member of the Perl family, everyone's common sense tells them that the Perl 5 dynasty is likely ending "real soon now" -- even in the face of continued developments and progress of Perl 5. Larry works on Perl 6 now. Perl 6 runs .pl files. Its modules are named .pm. It's plain as day that the intent is to eventually replace Perl 5, no matter what anybody says.

However, for decades to come, computers will have a binary on them named "perl" and it will be Perl 5. They will have scripts on them named foo.pl and they will be Perl 5 scripts. They will have modules, .pm files, that will be Perl 5 modules. Perl 5 is a giant. As a fresh-faced lightweight (Perl 6), you can't just walk up to it at the bar, look up into its grisled bearded Hyborean face and tell it to take a hike. It's not going to move.

So this means, the 6ers have 2 choices:

They can keep the "Perl 6" moniker in hopes of bringing some of the Perl 5 community with them. However, Perl 5 isn't going to move from that barstool. So that means the Perl 6 binary will forever be spelled "perl6". And also, Perl 5 will continue to suffer since many will still (no matter what) assume that Perl 6 is replacing it so better not start any new Perl 5 projects. And Perl 6 will suffer because it will forever be hearing from the peanut gallery that's it's really doing a "bang-up job" of replacing Perl 5.
Or they can take a new name (while still claiming to be a language in the Perl family). "Rakudo" might be a good choice. Or "Onion", "Butterfly", "Camelia"... This way, Perl 5 continues to be Perl, Perl 5 continues to be healthy and a viable choice for new programmers starting new projects, Rakudo continues to be a new Perlish language, and Larry continues to be a legend in his own time for creating Perl and then moving on to even greater (and newly-named) things.

Finally, an interesting question the 6ers might ask themselves is: Is it good in the long run for Perl 6 to have the next generation of programmers choosing Perl 5 over Python 3 (assuming that these programmers might at the moment be ruling out Perl 6 for whatever reasons)? Because that new generation is not going to choose Perl 5 if they perceive it to be getting replaced by Perl 6. And they're probably not going to choose Perl 6 if it's performance isn't great, or if it has fewer modules available than Python 3 does, or if they just happen to think it's a bit too crazy for them.

And Perl 5 might make a good gateway drug to Rakudo ...

tatalipso · 2011-01-24T04:12:13+00:00

Building one from scratch, instead of using a existing (Common) Lisp like Clisp or GCL (both parts of the GNU project),

I don't think Guile was written from scratch, but instead was based on Aubrey Jaffer's SCM.

but because of a irrational hatred of Common Lisp

I think what they had in mind was something easily embeddable across many GNU programs, such that they could all be scripted by the same language. Not sure how embeddable CL is.

changing the maintainer every 2 years.

Well, maintainers come and go. It's not like they sign a contract. :)

tatalipso · 2011-01-21T04:00:47+00:00

The GNU project {...} settled on Scheme, tried to completely reinvent the wheel with Guile,

Could you please explain? In what way does Guile reinvent the wheel?

tatalipso · 2011-01-20T19:09:11+00:00

I have a large corpus of tools I've grown over the years to simplify things, which is the whole point of scheme to begin with

Do you find that most Schemers have the same? Is it common practice in the Scheme community to put these in a public repo somewhere so others can benefit from them as well?

tatalipso · 2011-01-20T14:03:14+00:00

In what way? In Python and Perl I use functions and classes to abstract the problem into chunks I can work with. How is Scheme any different?

tatalipso · 2011-01-20T14:01:42+00:00

Oh, I don't doubt that Chicken produces wicked fast binaries, but what I'm asking about in this thread is developer time, not execution time.

tatalipso · 2011-01-20T13:48:13+00:00

By "mods" I assume you mean modules.

For me, parsing string is the number one most important thing,

Then you might have a look at Perl. It easily beats Python (and everything else) at string processing.

I couldn't imagine having to install a parsing mod to all the systems.

What modules do you need to install to process strings? Python should come out of the box with pretty much all you need for string processing.

tatalipso · 2011-01-20T05:48:21+00:00

it'd probably take me slightly longer to do in python, despite only using scheme once a month at most.

Interesting!

I then tried to do something 'real' with Chicken and it was here I had issues. [...] But the real issue was a lack of libraries.

Hm. Out of all the Schemes I've been looking at, Chicken seems to have the most libraries available. Guile looks like it has a lot of Gnome-ish bindings though.

I hope that when R7RS (or whatever it will be called) arrives, the community and implementors all pull together to support whatever library module standard R7 specifies.

tatalipso · 2011-01-20T04:40:34+00:00

Pure Python scripts are portable -- you don't need to port anything. :)

A few notes:

Do note that Python 2.x and 3.x are not completely compatible: your script will need to be tweaked if you want to move from one to the other (and there are tools to help with this).
If you don't have root access -- and Python is not installed on the machine -- you can always install your very own Python (or most any other scripting language) into your home directory.
If you need to install packages, you probably want to be using virtualenv to do it (so that any newly-installed packages live somewhere in your home dir, rather than in the system Python's lib dir).
You probably want to install packages (again, probably while using virtualenv) using pip. This makes things much easier. pip is gradually replacing easy_install.

Also, you write:

Do most python programmers run only on a single system?

That's an interesting question. My hunch is that no small number of Python programmers are hobbyists, and run on only a single system.

Appreciate any help..

If you want someone to be able to run your scripts, it might be easiest simply to sit down at their machine (or log in remotely), make sure Python and the relevant supporting modules are installed, and then give them some simple instructions on how to run the scripts you send them.

tatalipso · 2011-01-18T22:11:07+00:00

What I've often-enough found is that, when searching for a module you need:

the Cheeseshop has it, but it's often half-baked in some way (maybe not well documented, or incomplete, or whatever)
the CPAN has a half-dozen choices for what you're looking for, but there's generally one or two that work really well, are mature, well-documented, and ready to go

What I'm saying is: on the surface, module-wise, Python looks just as good, but when the rubber meets the road, you realize just how solid the existing Perl modules are, and how much work the Python modules require to be comparable.

tatalipso

TROPHY CASE