Perl - the Detroit of scripting languages

https://speakerdeck.com/stevan_little/perl-the-detroit-of-scripting-languages

by petepete • 13 years ago

72 94 13 years ago

speakerdeck.com

guylhem2• 13 years ago

In perl5 :

- I can have a prototype running in a matter of minutes

- I have access to a vast library of modules doing everything I need (which helps the former)

- I write quick and efficient code

Do I really care about what other people think about the languages and tools I use? No.

However, I do care about efficiency and results

And, uh, working with a language that has been out for tens of years makes me believe my time investment is safer than with the fad-du-jour JS framework/library/whatever.

BTW, Maybe buying a home in Detroit (especially now that it's officially bankrupt and will hopefully be able to break out of the unions commitments) would be a good business move? That's a cheap place to bootstrap a business for sure.

j546• 13 years ago

I can have a prototype running in a matter of minutes

That's the case for any microframework whose language you're comfortable in.

Not really because part of having a business is staying alive :)

untothebreach2• 13 years ago

For the record, I know plenty of alive people in Detroit :)

TylerE11• 13 years ago

I challenge your efficiency claims.

The benchmarks just do not support. I mean, roughly in parity with Python and PHP, 20x slower than Clojure on average, 30x slower than Haskell, and on many tasks 100x slower than C. Over the whole bredth of the Alioth shootout programs, Perl trades places with JRuby as the slowest tested language.

guylhem2• 13 years ago

Most of what I do involves loading text files with fixed width records. A file is between 500M and 4Gb. Then I do things with these records.

So far I have not found anything faster than perl unpack (1), but I would be happy to. I plan to investigate Go soon.

Would you have another suggestion?

1 : or marginally faster, with the advantages negated by the time it takes to write the code. However, a 10x improvement would be very interesting to me.

tbrownaw2• 13 years ago

Well, what does "efficient" actually mean here? I like Perl (for medium-small programs) because it's quick to write, doesn't require lots of boilerplate like Java does, and allows a much more direct translation of my intent than shell scripts do.

nmcfarl4• 13 years ago

When I look Alioth I really don't see this, particularly the "slowest but JRuby" claim. What is your methodology?

---

Edit: What I do see is all the fastest test program for the interpreted languages, ruby, python, etc are all trading places for the slowest language - the differences seem to be completely minimal. (As there seem to be more perl test programs per benchmark the slowest of them is often near the bottom - perhaps that was your methodology.)

bcoates• 13 years ago

The Alioth benchmarks do a really bad job of capturing the reality of language-related performance issues. The choice of specified algorithm is going to dominate all other concerns in their benchmark, and that's not the sort of problem people face in the real world, perhaps out of rarefied HPC circles where benchmarks on one quad-core machine aren't relevant to anything.

Performance handling in high level languages is more about knowing where the landmines are (total heap usage in GCed languages, various troublesome malloc()s, weird caches in dynamic languages...) and trying to figure out as quickly and cheaply as possible if the program you're planning on writing is going to hit them, and how much it's going to cost to mitigate it. It's not relevant if the actual runtime overhead of the problem is 5% or 1000x, the end product is either fast enough or it isn't, and the workaround is either viable or it isn't.

Trying to protect yourself from this by picking the fastest language in a shootout isn't going to work because the perfect, gotcha-free language hasn't been invented yet. There are sound performance reasons to avoid any language, not just Perl.

VLM5• 13 years ago

"The benchmarks just do not support."

I don't make money writing benchmarks. I would challenge that given a flexible enough language, they're nearly meaningless.

Another very important point is most of my Perl is glue between enormous systems. Spending any time optimizing it would be a waste of time/money. I'm not writing real time video encoding here.

pyre3• 13 years ago

That's a cheap place to bootstrap a business for sure.

Depends on what you're willing to give up. Emergency response time can be pretty important.

untothebreach2• 13 years ago

Especially in a city that is consistently in the top-5 most violent cities in the U.S.

(disclaimer: I live in Flint, MI, another of those top-5 cities)

SeanDav• 13 years ago

In 10 years you could say exactly the same thing, except that:

- Perl 6 will STILL be in development

- You just lost 10 years of development experience and related marketability because now all those fad-du-jour systems are established industry leaders

- Nothing would have have changed back in Perl 5 land because everyone can only develop in 5.8.x or 5.10.x in case they break something.

The upside of course is that there will still be COBOL and perl programmers making a living ...

chromatic2• 13 years ago

Nothing would have have changed back in Perl 5 land because everyone can only develop in 5.8.x or 5.10.x in case they break something.

Seems doubtful to me. With yearly releases and a two year support cycle, only the enterprisey distribution nonsense is still infected with that particular brokenness.

VLM5• 13 years ago

"all those fad-du-jour systems are established industry leaders"

I'm trying to think of what the fads were in 2003. That was the tail end of extreme programming. Kernel03 or kernelcon or whatever it was called had a presentation about replacing devfs with udev since adsorbed into systemd. Simultaneously the new JACK system running on top of ALSA was going to take over sound on the desktop. In 2003 Moodle was the new leader of online course software. I would claim PHP4 was a very popular web programming language in 2003. Firefox was beginning its explosive growth. Bonjour/Rendezvous was new and making noise in networking. By far the most dominant handheld computing platform was the Palm, I still had my couple year old 3 and my wife had one of the M100 series. Dot-net and/or mono were going to take over the entire world; we're still waiting. I believe by this late the cuecat had already sunk along with most of the dotcom era stuff.

At this point I'm running out of ideas from 2003. I don't think "all" would be a good adjective. I'm having an easy time remembering fads that took off, and forgetting things that sank.

simias• 13 years ago

Dozens of slides of memes, curses and buzzwords. The state of communicating on the internet in 2013.

Can someone more patient than I am tell me if there's some actual content in there?

mahmud• 13 years ago

tl;dr:  

The talk might have been different, but there is nothing of substance in the slides.

davidw• 13 years ago

I haven't even looked at these since it doesn't interest me, but I think posting slides is kind of bizarre: if they're done properly, there shouldn't be anything much of substance in them.

petepete2• 13 years ago

There are notes as to what the actual talk covers beneath the slides; some of them are quite substantial.

Mithaldu15• 13 years ago

Did you read the notes under the slides?

jack-r-abbit3• 13 years ago

The print was very small. I can't think of a worse way to present one's thoughts.

Edit: well... I guess if I could not control the speed of the slides... that would have been worse.

williadc• 13 years ago

tl;dr - the author wants someone to re-write Perl 5 and CPAN to add some features he likes and remove some features he doesn't like.

petepete2• 13 years ago

In fairness, the author is also Stevan Little, the chap who brought us Moose and Moe

http://en.wikipedia.org/wiki/Moose_(Perl) https://github.com/MoeOrganization/moe

nmcfarl4• 13 years ago

My tl;dr - The author says people are currently writing "perls" that add features that he likes and remove features that he doesn't like - and he would like us all to consider them all the perl not just the one binary. IE the future of perl is many runtimes, that are slightly incompatible.

Mithaldu15• 13 years ago

IE the future of perl is many runtimes, that are slightly incompatible.

That is already the reality of Python and Ruby. ;)

runn1ng2• 13 years ago

I can't wait for Perl 6.

</irony>

mjolk• 13 years ago

Whose irony tag are you closing? I looked at the page source and couldn't find an opening irony tag.

runn1ng2• 13 years ago

<irony>

^^ here you go.

Mithaldu15• 13 years ago

Before you comment, please keep the following things in mind:

The talk was held by Stevan Little, the creator of Moose, the person who experimented in Moe on a modern Perl 5, and the person who is currently working on a Meta-Object-Protocol that can be put in the Perl core to make good OO available out of the box, on which Moose, Moo and friends can built. He dearly loves Perl and has done a lot for it.

This talk is not a blind troll, but a warning, an overview of his past efforts and ends on a positive note.

Please do not comment before actually reading the entire thing.

jack-r-abbit3• 13 years ago

I won't comment then because the tiny tiny print was so painfully horrible to read I only made a few slides in. He seemed to be making a point though. Just the presentation was horrible.

Mithaldu15• 13 years ago

I agree that the font could have been bigger, especially since some people have trouble with their vision. However i would also like to remind you that probably all browsers capable of displaying the slides at all, also have zoom controls available.

Lastly, i would like to thank you for refraining from commenting on the contents. That is all i ask from anyone unable to take in the content. :)

veesahni3• 13 years ago

For me, the biggest pros for Perl were it's extreme expressiveness and the power of CPAN. However, it wasn't without it's warts - odd threading, weird sub signatures, faked OO, etc .. I've spent a lot of time explaining the nuances of these warts to others, which only made me realize how serious these issues are.

I was sold on the promises of this thing they were calling Perl 6, that was supposed to break backwards compatibility and "fix all the things" in one shot. I followed it for a couple of years and then something happened...

Somebody pointed me to tryruby.org - I discovered a language that was more expressive than perl, followed similar values (i.e. There's more than one way to do it) and opened me up to a new world of meta programming. I embraced & absorbed it and today it's my weapon of choice for most of what I would have reached out to Perl for.

Mithaldu15• 13 years ago

You got two things wrong there:

weird sub signatures

No core signatures, but modules on CPAN that make signatures available.

faked OO

The OO in Perl works almost identically to the one in Python, and i assume Ruby is similar too. The difference is that OO syntax sugar is implemented in core in Python and Ruby, while in Perl it is implemented in Perl directly and available on CPAN but in core.

There's nothing fake about it.

As for your conclusion: I have the strong suspicion that the difference lies less in the language itself [1], but more in the fact that with tryruby you had a modern learning resource available that taught a good coding style; while pretty much all Perl learning written before February 2012 are mainly based on material originating in the early 90ies. [2]

[1] The main Ruby implementation doesn't even have multi-core-capable threads, but uses something that's basically a VM-level event system: http://en.wikipedia.org/wiki/Green_threads

[2] http://perl-tutorial.org/

veesahni3• 13 years ago

The difference is that OO syntax sugar is implemented in core in Python and Ruby, while in Perl it is implemented in Perl directly

I see what you mean. However, that syntax sugar is what people are used to from other OO implementations. Lacking that sugar meant that I found myself regularly explaining the workings of blessed hashes.

mst2• 13 years ago

Ruby ... fixes everything about perl5 that annoys me, except that Ruby's OO and metaprogramming is weak sauce compared to Moose (written by the presenter of these slides).

Without a proper role system, I can't replicate a lot of my designs. Without a proper meta-model, I can't write attribute traits to extend the OO system when I need to.

So any time a ruby program of mine gets large enough to need a significant number of classes, it gets ported back to perl5 first so I can do it properly.

If you want something lightweight to experiment, try looking at Moo (written by me for smaller projects) - you may find that declarative attribute definitions, method modifiers and roles become very addictive very quickly :)

dj-wonk• 13 years ago

To add two different thoughts:

* Perl is widely used and has inspired many other languages. These are not small accomplishments.

* How many major revision bumps can a language undergo before it loses its identity? How many breaking changes are allowed before it becomes something else? Perhaps the name is about something more than the language as crystallized at any one point in time? But how do you convey that to the community as the language changes?

Mithaldu15• 13 years ago

To the last point:

I'm fairly sure that the identity of a language is defined by its teaching materials.

Up until 2012 all Perl teaching materials were largely based on text written in the early 90s. And as well, any newbie program tended to look like it was almost Perl 4. This was in spite of there being a concensus and strong effort to push among the active Perl community that modern Perl was the way forward.

Then two things happened: The books Modern Perl by chromatic and Beginning Perl by Ovid were written. I used these two books to teach newbies and their code is nothing like the code of newbies of old.

If these two books reach enough penetration, they will change the identity of Perl.

VLM5• 13 years ago

"Modern Perl by chromatic"

I have a copy on my desk and this cannot be emphasized enough that one inward facing book on what boils down to style and good taste, has already had more impact on the language than the last two decades of outward facing comparisons.

Insert forest and trees analogies in that we've got way too many presentations over the decades about how one individual tree needs trimming or fertilizing or bonsai treatment as compared to how our neighbors orchard does the same, but not enough real forestry management presentations.

fusiongyro6• 13 years ago

Moe is an attempt to show a way forward, not be a way forward.

I can certainly appreciate the desire to make something fun, either for your personal edification, or to try to engage the constructive aspect of your community, I have to wonder: is there enough manpower left in the Perl community to handle all five-six of these revitalization efforts, while also continuing the march to Perl 6 and maintaining 25 years of backwards compatibility? The analogy to Detroit really couldn't be more apt.

In 1998 Perl had a substantial portion of all programmers simply because it was the best free tool for a wide range of jobs. In 2013 nearly every problem has a language more appropriate than Perl. You don't have a captive audience anymore. These days, almost every language is marginal and makes a living by cultivating a small but fanatical base. In order to play the new game, Perl has to find a new pitch, and "we finally work like real modern programming languages" is pretty weak. There are thousands of languages with real object systems, real exceptions, real functions, etc. Until Perl throws its weight behind something more interesting and substantial than "backwards compatibility with filth" and "someday, it might be nicer" it can expect the current trend of net emigration and a Detroit-like heat death to continue.

Mithaldu15• 13 years ago

In 2013 nearly every problem has a language more appropriate than Perl.

Citation needed. Seriously, please stop making such broad statements based on your feelings and opinions and instead please make an earnest effort to separate objective facts from your subjective perception.

And just to address another point: Perl has multiple real object systems that are inter-compatible (with one small exception), and are considerably more powerful than the OO of Ruby or Python. The only real complaint you can level against Perl is that they need to be installed from CPAN; which is not a very useful complaint since all the useful bits in Perl need to be installed from CPAN anyway.

fusiongyro6• 13 years ago

I'd say the onus is on Perl to be the best language for a niche, rather than on me to provide a list of niches with languages better than Perl.

Besides that, language appropriateness is necessarily subjective. I love Prolog and Haskell and use them all the time. My passion for them makes their thorns seem small and easily avoided, but the reality is that those thorns are sufficient to keep out a lot of curious people. I didn't really figure out how to write a Prolog program that handled command line arguments until a month ago. Prior to that, I would just run Prolog, consult my script and run my function. Simple enough barrier, but one that would have kept most of my friends away.

I think you took my "real X, Y, Z" list as a literal insult, which isn't what I meant. I don't know Perl. I was just referencing the presentation, not trying to sling arrows at Moose or whatever.

I do think that providing multiple options where most languages have one option built-in is unnecessary cognitive load. One doesn't "choose" an "object system" for Python--what benefit would one hope to gain? That the options are compatible is nice, but it's indisputably more work for everyone than just having one.

Having what are essentially language built-ins elsewhere available instead on CPAN is worth complaining about, because if you're going to do things differently from others, the difference should be motivated by something. That something in Perl is backwards compatibility and the desire to provide lots of options. The former is an explanation, not a rationale, and the latter implies, again, a cognitive cost. When you spend my attention and brain power, I had better get something in return. "Options" are only worth something if the alternatives are worth choosing between. In the case of OO, complete intercompatibility between them suggests the differences are minor; in that case, why have them?

antitrust• 13 years ago

A few thoughts:

Trends come and go, but it's the general purpose languages that remain.

Perl seems to fit in that space that was occupied by the various BASICs in the 1980s, meaning that it was the best glue for everyday tasks. It's quick to write, has the right tools, and plays well with system tools.

In general, in my experience, it's the quality of staff and not the tools that makes the difference. Good management, coders and business-side analysts make a much bigger difference than what language you use.

In general, in my experience, few experienced Perl programmers use vanilla Perl. Almost all of them rely heavily on libraries and write code according to their own knowledge of what's most efficient.

Be wary of the world of trends in programming. It is as fickle as trends in education, interior design or nutrition. Then again, I'm still waiting for the Pascal comeback.

ape4• 13 years ago

I like the "bikeshedding" idea.

PleaseBeSerious• 13 years ago

I switched languages 6 months ago. I now make more than I did as a Perl developer for 7+ years.

codeboost• 13 years ago

The reverse sounds nicer :

Detroit - the Perl of cities :)

jimmytucson• 13 years ago

Perl is actually far from abandoned and I would venture to guess (based on no facts and figures but my own personal experience) that there are more lines of Perl in production today than Python or Ruby combined.

But how can that be?! Building a large scale application with Perl would be like building a F111A Aardvark out of duct tape! Quite simply, because Perl is the perfect duct tape. Too many people (knowingly or not) think of Perl as a crappy version of Python when it's actually shell scripting on steroids.

You see, way up here, where projects are constantly in development, paradigms are constantly shifting, and people are building new and exciting things, Perl is an unwelcome high school acquaintance who shows up at the party and makes everybody feel awkward and bad. But way down there, where people are just trying to keep Sputnik up and running until the Soviet Union collapses, Perl is a rock star! If it's too "small" for Java but too "large" for .ksh -- guess what, use Perl.

In my opinion, if you want a scripting language with function signatures, little to no support for UNIX commands, real object orientation (Moose), yadda yadda yadda... just use Python. No one's going to blame you. Larry Wall's not gonna feel bad. You have a right to your impact gun and bolts.

Just leave my duct tape alone.

Perl - the Detroit of scripting languages

Related Stories