Hacker News new | past | comments | ask | show | jobs | submit login
And suddenly, you're hip (perl.org)
182 points by Phra on Jan 9, 2011 | hide | past | web | favorite | 142 comments



Thing is, while both Ruby & Vim have been driven by what she's describing she neatly sidestepped why those movements got started in the first place. Ruby gained huge traction primarily via Rails because working on PHP is unenjoyable to many and Ruby is a really pleasant language to work with. Vim's recent resurgence can largely be traced to development of Textmate grinding to a complete halt. Textmate's rise a few years ago was due to BBEdit failing to evolve. Git beats seven shades of shit out of SVN. Erlang provides a proven answer to concurrency issues. Javascript is the only choice for the ever more important front-end side of web development. Each of these shifts of development momentum have rational, logical underpinnings.

The buzz, the screen casts and other errata are a consequence of a lot of people making the same logical, reasoned choice and talking about it in public. I cannot think of anything that's changed in Perl that'd justify any such interest. I admit that may be my ignorance. Making sexy screencasts might get a little traffic but you can't astroturf wave of developer momentum with them.


Sure, there are plenty of reasons of the whys and whens - on the other hand, we could easily ask "why didn't everyone choose Emacs when textmate's development came to a halt" or "Why didn't people choose Python as their web language of choice when they didn't like PHP" or "Why not Bazaar instead of SVN" or why Ryan Dahl chose JavaScript as a base language for Node.js and not any of Python, Ruby, Perl, Scheme, Lisp or Lua - but JavaScript - and so on. (As others already pointed out below so I'm summing this up in one sentence here..) Thankfully we have plenty of options to choose from nowadays.

And yet I'm still convinced that the choice of Git over Bazaar has something to do with the smoothness of Github and with "It's from Linus!", the choice of Ruby/RoR with the image 37signals so nicely projects, that JavaScript's recent rise and massive change in perception comes thanks to Douglas Crockford and Erlang would have probably stayed in its niche if it wasn't for CouchDB.

So I was surprised and amazed by the change in perception of Vim over the last year and therefore I blogged about it.

And yes, along your examples Perl faced a similar situation around 2000 (so thanks for the well chosen examples) and decided to do Perl 6 to re-ignite the Perl spark. (Let's set aside for a moment wether or not it worked and what happened after that and boy am I sure the second I hit the submit button people will _exactly_ totally get into this subject.. ;)

I also didn't ask wether or not one really wants the success of the masses or if it might be a good thing to stay in a well-defined niche with a community of your choice, creating your own culture - as for example shows the Linux distribution Slackware very happily year by year and to a great satisfaction of its users.

I also didn't mention how much it might have to do with the age of developers, wether some changes plainly might be a generation thing of "first generation web developers" and "second generation web developers" or how much Apple's regained success does play into all that.

But as we can see within the comments below, old Perl cliches aren't really dead and get repeated all over wether or not the subject was Perl's marketing and not Perl's qualities (or the perceived lack thereof...)

Or maybe we all get kicked our asses by Lisp next year - thanks to Peter Seibel's Practical Lisp Programming book or "Land of Lisp" and of course Paul Graham and Emacs wins all over. ;)


Predictably Irrational talks about what you are describing here. You see, despite many of these technologies having a smaller install base, what they have done is create a new anchor in technology, which allows them to monopolize the conversation. The iPhone and Rails are the most significant anchors within the past 5 years. You can't make Perl popular by acting like rock stars and making videos on youtube, you can only making Perl popular by creating a new technological anchor for others to hook themselves to.


I agree with this whole-heartedly. My sentiments exactly.


I chose emacs when Textmate stopped getting updated. The joke page registered at textmate2.com redirects to emacs, and a most of the people harassing Allan on his blog a couple years ago were saying they'd switched to emacs.

I think it might just be that emacs doesn't lend itself to screencasts or golf quite as much as vim.


I could lower the lid on my macbook so the webcam is pointing at my fingers to show the chording. Hmm, yeah, probably not so helpful.

Emacs has also had a really strong community for over 30 years (perhaps driven somewhat by the higher education roots). As such, I think it had a more firm underpinning than vim did, so more of the tutorials and such already existed.


Older documentation might actually be a disadvantage. Older tutorials often tell you out-of-date ways to do things, and do it in a not-so-hip way.


I think there still was one good point in the parent comment that you did not address. If screencast were not the reason of RoR popularity but it's consequence, then maybe we should not lose too much time on making screencasts and instead concentrate on some other things? I have to attest that screencasting does require enormous amounts of time, especially if you try to do that on Linux where the tools break every 5 minutes and you need to make manual savepoints to keep with moving ahead with your work. Even though it was also very captivating and quite entertaining.


I may be a rare case, but I honestly started using git and vim in particular long before the heaps of hype that built up around the tools, before I even started reading HN actually.

I found the tools I went with to be more intuitive and easier to learn than the others. When tools are legitimately pleasurable to use, developers talk about them, and 'hype' builds up.


The hype then attracts the next generation of users and perpetuates the trend. Most users are pulled in by the hype, rather than the rational decision making of the early adopters.


    > Vim's recent resurgence can largely be traced
    > to development of Textmate grinding to a complete
    > halt.
makes sense - but then why didn't Emacs see an equivalent resurgence (although personally I think Emacs did see a resurgence, not because of Textmate but because of Org Mode).

    > Git beats seven shades of shit out of SVN.
you could argue the same for Mercurial (or darcs, for that matter). But Git had the better initial marketing, Github, the Ruby folks used it etc.

    > I cannot think of anything that's changed in Perl
    > that'd justify any such interest.
hm, CPAN (and the arguably failed attempts to copy it by other language communities), Moose, MooseX::Declare, Devel::REPL, Dancer, Mojolicious, Task::Kensho, ...


I think emacs did see a similar resurgance, for the same reason that vim has. We just each tend to notice different resurgances depending on which editor we use...

And here's some constructive criticism for the aspiring Perl advocate: Stop talking in acronyms and obscure library names. What the hell is Moose and what real world problem does it solve significantly better than the popular alternatives?

Same for CPAN, frankly. Most people younger than me don't get it when you name-check CPAN. What does that stand for?Give me a killer app for CPAN, preferably one that people care about.

Note that the parent post speaks in use cases: Ruby is for problem X, Erlang is for problem Y, JavaScript is for problem Z. What is Perl for, and why won't Ruby work just as well?


Well....

How about Django, Evently, Moustache, CLOS, Hackage, Sinatra, Merb, OMQ as acronyms? ;) (None of it Perl..)

Anyways. CPAN _is_ the killer app. It's a HUGE, extremely easy to install module/library archive. Perl's modules aren't spread around everywhere but neatly and nicely collected there and you just do a "cpan Foobar" and get Foobar with all possible dependencies included.

Which is something what many languages (some still don't) have these days one way or another but really nothing compared to CPAN in number, service, search, testing facility and so on. You plainly _never_ have to bother searching your ass off to find some library you might need.

Moose is Perl's OO system - as with JavaScript you can do different OO styles with Perl and Moose is a framework to do a role/trait based (please see Smalltalk for details or Perl 6's spec) OO with a heavy twist on metaprogramming.

Perl is for writing things like Amazon or the IMDB and keep it running for 12 years in a row or for creating Nagios and SpamAssassin to watch over half of the Internet. Thanks to Perl, everybody can easily imagine what push, pop, shift, unshift on Arrays/Lists does and thanks to Perl everybody has very shiny Regex these days. That's why Vim has a magic/nomagic flag and what the P in PCRE stands for. The Ruby world gladly thanks Perl's DBI after which it modeled its own database interface.

That's what Perl is about. Sharing shiny features and establishing a culture of "getting things done who run really fast".


The problem with perl is that it got a bad rap and has never shaken it. The "perl is line noise that makes magic" sort of reputation. The people who love perl don't seem to be interested in moving the language forward and shedding the old ways of doing things.

Now.. CPAN.

Let me explain my latest round with fighting Perl/CPAN. I wanted a perl interactive mode. When I want to test out something in Ruby I use irb. In Python, I can type in `python` and enter interactive mode. Even PHP has a rudimentary interactive mode now.

So I try looking at `perl --help`. Nothing there. So I turn to google and find that I need a REPL whatever that is. So I try to figure out what a REPL is. Find that. Now I find that I need to run a little script to run Devel::REPL. Doesn't work. So I load up CPAN and type in `install Devel::REPL`. No less than thirty minutes later, 150 or so screens of noise, and at least 25 questions that I have to hit [enter] for I get a failed install. I have no clue what failed -- something to do with tests (the error is 4 screens back in the middle of even more text) so I try to force the install. I'm now 45 minutes into this and finally get Devel::REPL installed. I fire up re.pl and I get `SCALAR(0x100b81070) is not of type SCALAR at /opt/local/lib/perl5/site_perl/5.8.9/namespace/clean.pm line 56`. All of this for a feature that should come with a base install.

This is just one example of why I avoid perl as much as possible.


As the author of Devel::REPL, I've never seen that error or have it reported.

If you want to email me (address in profile) I'd love to figure out what went wrong so nobody else has the same problem in future.


Email sent.


For the record, upgrading Package::Stash fixed it.


Notwithstanding your apparent problems with CPAN, the traditional way to go to an interactive mode in perl is

perl -de0

which still seems to work.


> Perl is for writing things like Amazon or the IMDB and keep it running for 12 years in a row or for creating Nagios and SpamAssassin to watch over half of the Internet.

Perl was the hip thing back when those projects were being developed. If they were being made today, it's overwhelmingly likely that Perl would not be used (see Facebook).


Anyways. CPAN _is_ the killer app. It's a HUGE, extremely easy to install module/library archive. Perl's modules aren't spread around everywhere but neatly and nicely collected there and you just do a "cpan Foobar" and get Foobar with all possible dependencies included.

Sounds like Ruby's Gems: http://rubygems.org/ or even python's PyPi: http://pypi.python.org/pypi ...


CPAN is the killer app for developers because it is: - an archive of libraries for them to use - a publication mechanism - a documentation mechanism - a global distribution mechanism

And most importantly: It provides you globalized automated testing on a variety of systems of anything you upload, through CPANTesters.

Just as an example: I uploaded a module yesterday and now it has 38 tests on as many different configurations already: http://matrix.cpantesters.org/?dist=CGI-Application-Plugin-T...

So not only gives it a very useful and otherwise extremely expensive tool to you, the developer, it also shows you this information about other modules, so it lets you gauge the quality of the modules you are considering to use.

Edit: Also, as an additional goody: The testing culture of CPAN allows development of ancillary tools that analyze the current state of CPAN and highlight modules that are having issues with their tests: http://analysis.cpantesters.org/ This can help generate bug reports for developers who don't have time to figure out exactly why a test failed on an obscure combo and they provide an in for CPAN-Newbies by pointing out to them which distributions could use patches.


Err.. yeah - what do you think after whom gems etc. are modeled? :)

Haskell's system is called "hackage" for example and "R" has its "CRAN" and so on.

Though it's really no fair comparison as CPAN contains what.. 89033 modules? http://search.cpan.org/


Just because it was modelled after CPAN doesn't mean it's not better.

I'm not very familiar with PyPi since I'm not a Python programmer, but Gems pretty much work exactly like they should. Especially when you throw RVM into the mix.


Ruby gems by default don't run unit tests. If you care about reliable software, this is a bad thing compared to CPAN.


And CPAN itself was modeled after CTAN, as far as I recall...


    89033 modules
Only 21694 distributions, though. The analogue in Ruby is a gem and RubyGems already has 19502.


Ok. Shitload of lib err bricks. Great. Where are the prefab houses (frameworks) that help you get the thing done ... fast ? Perl has building blocks but lacks known products. Either finished products you just have to configure (like Drupal or Wordpress) or higher level building blocks (say Rails) that help you get where you want to get faster.

Note I didn't say there is not such product/framework, just, as the articles says, they are not promoted/known.


Mojolicious, Dancer, Catalyst (biggest and most enterprise one), CGI::Application, Jifty.

There's a whole bunch of them, with different design goals or philosophies.


I didn't there wasn't, just that the need better promotion. Call it screencast if you wish. They need Promotive Passionate Users.

[edit] I'm gonna pick a little bit on Catalyst and do a quick surface review at website level from a non-Perlist POV.

Homepage : ok, looks nice.

Documentation : uuh ! Dry redirect to CPAN. First impression before reading, it's not the doc, it's the API doc. Ah, wait a second, it _is_ the doc. Not very appealing and some things are so not obvious that it takes a note to understand it like "Note: Click on the heading in the previous line to jump to the actual chapter. Below is a "table of contents" for this chapter."

Download : Again directly to CPAN, at first sight confusingly looks like an API doc. For newcomers not versed in Perl it is not very friendly.

Community : not much to say, a good wiki with apparently interesting stuff to read. But the first thing you see is that the "Why Catalyst is an excellent web application framework?" is an empty page.

The perl community has every reason to be proud of CPAN. It's great tool but it's not the answer to everything. It's all therem but it lacks the last mile, the 20% of polish to make it a tad more friendly/attractive.

It's the whole point of the article I think. It's not to criticize Perl, just to say it needs a better marketing strategy.


>Though it's really no fair comparison as CPAN contains what.. 89033 modules?

Why do people keep trotting out this stupid pointless number. How much of that is duplication? How much of it is crap? How much of it is literally toys (e.g. ACME stuff)? In any case, Java has vastly, vastly more so any language that runs on the JVM automatically beats perl here.

99% of programmers will never notice any functionality missing in Ruby or Python that CPAN has.


Why do people keep trotting out this stupid pointless number.

Metcalfe's Law. The value of the CPAN increases dramatically with every addition, especially because of the maturity of the entire CPAN infrastructure: CPAN testers, CPANTS, annotations, reviews, dependency tracking, BackPAN tracking, gitpan, linked documentation, et cetera.


>CPAN increases dramatically with every addition

Demonstrably nonsense. Let me add a new module called ACME::DoNothing. What have I increased besides disk space and a meaningless module count?


You've tested the entire CPAN ecosystem, as well as the ability of the ecosystem to identify and remove harmful contributions, if said contribution is in fact harmful.


I'll concede that that is very good. And I'll also concede that I can't think of any other systems that do this as well as CPAN (if at all). But my point remains that for 99% of developers we want a library that provides functionality (e.g. an ORM for a common database) and in that respect CPAN will only have an advantage for very obscure requirements. And even then it still loses to Java.

The testing stuff is good and it's the direction everyone should be going but not having it obviously isn't too much of a problem because so few systems currently have it (CPAN was successful long before it had it as well).


> not having it obviously isn't too much of a problem because so few systems currently have it

You can't really draw that conclusion. Other systems do not have it because it is not an easily solved problem, not because they do not think they need it.

Also, needing and benefiting from something are two entirely different things. Yes, no language actually NEEDS this kind of thing. But a language that has it is literally self-healing, since any kind of problem, be it breakages from dependencies, cross-platform issues or core language changes are communicated very rapidly to the developers without them even needing to make an effort.


The testing stuff is good and it's the direction everyone should be going but not having it obviously isn't too much of a problem because so few systems currently have it....

The Perl 5 Porters mailing list has automated mailings which test CPAN against bleadperl to discover which, if any, commits break existing CPAN distributions. This helps p5p revert genuine mistakes and CPAN authors to patch their bugs.

I know that several minor revisions of other languages have broken several popular extension libraries.


Without a testing infrastructure, you pretty much rely on programmers having code doing what they say it does, instead of having proof it does what they say it does.

Given human penchant to slip up and not realise problems until after they are encountered, having tests makes pretty much the difference between "science" and "hypothesis"


Not entirely true. Languages with strong static type systems like Haskell and OCaml go a long way towards being provably correct without test suites. Dynamic languages like Perl however have no such guarantees.

The fact that the cross product of several generations of interpreter, several platforms, and tens of thousands of distributions is generated automatically by a handful of volunteers is a strong argument for CPAN/Perl being unique amongst the dynamic languages in it's testing and compatibility.

Additionally, people who aren't in the right circles probably never know how much grepping through CPAN happens when new features and syntax is suggested for the core Perl5 language. All done by the porters to be sure that new syntax won't break existing code without some fore-knowledge. This is on top of the automated testing.


As a seasoned Python programmer,I think PyPI doesn't even come close to CPAN.

CPAN is the only reason that I've kept my Camel book around since 2000, hoping that "someday" I'll learn Perl.


Neither one of those actually holds a candle to CPAN.


Then maybe CPAN's advantages shouldn't be explained as "gem install", err... "perl -e -MCPAN "install net::foo". Explain the _actual_ strengths of CPAN that make it a killer app.

Oh, and "It has MOAR!" isn't really a good argument. I've authored two gems, I think. Those are the only two times in two years of using Ruby that I haven't had the ability to just install the library that I needed.

(I loved Perl for years until I found Ruby, then never turned back...)


Tests. Integrated Bug Tracking. There's 2 reasons.


Sweet! Then lead with that. I'm not saying that CPAN isn't better than Rubygems somehow, but that "easy installation" isn't a selling point.


try "cpan Module::Name", which installs the requested module


Sweet. That's still on par with Rubygems, cabal, and everything else, though. That wasn't my main point.


CPAN is large and comprehensive but every time I've had to use it I've had to watch a minimum of 20 minutes of scrolling compilation, installing dependencies and running tests. Ruby and python install what I need in a few seconds so I can get back to work.

Maybe it's a question of perl putting a lot of things in CPAN versus other languages putting more in the standard library?


CPAN is large and comprehensive but every time I've had to use it I've had to watch a minimum of 20 minutes of scrolling compilation

Have a look at cpanminus (http://search.cpan.org/dist/App-cpanminus/lib/App/cpanminus....). Its a lightweight and JFDI alternative to the default CPAN client.

Maybe it's a question of perl putting a lot of things in CPAN versus other languages putting more in the standard library?

Swings and roundabouts really because there is no definitive advantage in either approach.

Advantage in CPAN approach: Its more darwinian. Your libraries are more up-to-date (stdlibs often get stale)

Advantage in stdlib approach: Less dependencies. Batteries included out of the box.

After installing Perl first thing I do is load a few important CPAN modules (like Moose, AnyEvent, Coro, Devel::Repl, DBIx::Class) and then all your big loads are pretty much done.


    > And here's some constructive criticism for the aspiring Perl advocate
point taken, thanks.

Perhaps the Perl success stories should be mentioned more often, too:

Want to launch a one-man search engine? Perl makes the easy things easy and the hard things possible: http://www.gabrielweinberg.com/blog/2009/03/duck-duck-go-arc...

Amazon.com, del.icio.us, Craigslist, the BBC? All have significant parts written in Perl: http://www.fischerlaender.net/perl/perl-used-for-web-develop...

http://perl.apache.org/outstanding/success_stories/bbc.html


For me, I use Ruby for everything I used to use Perl for, unless I can't get ruby on the system (still haven't managed a successful compile on HPUX!). The other use case is that Perl has a library Ruby does not, which still happens now and then.


emacs? Stop talking in acronyms and obscure names. Same for vim, frankly. Most people younger than me don't get it when you name-check vim. What does that stand for?

:P


The differences I see here are that

a) emacs vs. vim has been a holy war that has gone on since both were conceived and is a debate which is often older than the programmers discussing it. To be ignorant of recent language developments or internal acronyms is excusable, to be ignorant of vim/emacs is less so.

b) emacs and vim are not specific to any one language. Dropping acronyms that are non-specific to the topic (perl vs ruby, python, whatever) doesn't have some domain specific knowledge attached to it. If you're on either side of the debate, vim can be equally familiar or obscure.


Terminology has context.

Complaining about an article on perl.org not mentioning what CPAN is, is like complaining about an article on cars.com not mentioning what BMW is.


Regarding a) - that was emacs vs. vi, not vim. vim was first released in 1991.


CPAN (and the arguably failed attempts to copy it by other language communities)

I haven't used perl, but I do use ruby and I'm learning haskell. What does CPAN do that make rubygems and cabal failures? They both work really well from what I can see (especially cabal), but since I don't know perl, my POV is obviously limited. What am I missing out on?


Hackage, rubygems, PyPi - are all modeled after CPAN


Right, modeled after, but I'm wondering why they would be considered failures. Rubygems and cabal both work really well for me, and cabal is both the nicest package management system and the nicest build system I've ever used. I'd love to know why somebody would call it a failure.


You obviously have never tried to compile profiling binaries for a haskell I would not call cabal the nicest build system I had used. Cpan beats the pants off it.


with "failed attempts to copy" I meant they (Rubygems, Hackage, ...) did not succeed (yet?) to replicate the size, diversity, test coverage, community etc. of CPAN. I do agree that they are useful.

Sorry for the misunderstanding.


Yes, that's clear. But what I don't understand is why the author thinks they have failed? I only have experience with PyPi, combined with easy_install it's an incredibly easy way to install packages and their dependencies.


Failed in the sense that they've failed to recapture the glory of cpan for solving problems from the late 80s and early 90s. Personally I've been very pleased with library support in Python.

Counting a library's worth by the number of things in it is probably not a good measure of its worth. But it'll be who knows how long before pypi or gems overtake cpan in terms of sheer quantity.

A better measure of worth would be a deathmatch showdown between seasoned perl people and seasoned ruby/python/whatever developers, where each can bring the powers of his libraries to bear.

But anyone who has had much exposure to perl people will tell you: never, ever underestimate them. They'll come at you with solutions to problems out of left field that solve the problem in 34 characters of self morphing regular expressions or something while everybody else is turning in comparatively huge 8 line readable programs.


Or they come up with a 5 line solution, using a CPAN module that has had it's battery of unit tests automatically run through on 200+ different os/hardware/perl combinations, which also comes with its own little test suite and works out of the box; while everyone else runs their stuff and discovers they still need to catch a dozen weird edge cases.

Until other languages reach this kind of solidity and thoroughness in testing CPAN will stay at the top of the bunch.


It's not nice to think that marketing shapes the way we see the world - but it does.

Programmers are just likely to want to follow fashions as tweens - it's just that they're not so likely to admit it.

EDIT: (we're) not so likely to admit it.


The clarity of your writing makes this point very clear.


I used to be a huge Perl advocate; I loooved perlmonks back in the day. (Just tried to log back into it after probably over 10 years but the forgot password link doesn't work) I read the Camel book cover-to-cover and giggled at the footnotes.

While I loved the language, I can't imagine going back to it. Now perl programs look like cat typing to me. It was way too expressive. The TIMTOWDI mentality meant that I could never read code I didn't write myself, and even some that I did. It was terse and dense like poetry and hard to understand - like poetry. To really "know" the language meant knowing a huge surface area full of exceptions and special conditions.

Sure, you could limit yourself to certain best-practices and styles but it was like being handing the keys to the porsche and told to only drive 35. At every turn, the language was begging you to flex that newly acquired knowledge of special syntax. The obfuscation contests, the perl poetry, the quines… Many languages have this failing in my opinion and it certainly matters more when you're working in a large team (hence, rigid boring old Java) but Perl taught me what it was like to go too far down that path.

It is what I would call a write-only language.


You are describing a Perl mentality that really doesn't exist today and is only really touted by people that used Perl "back in the day". The community mindset has changed a lot in the last couple of years. Now, that community is trying to show that change to the world...and slowly...it is working.


>>Just tried to log back into [Perlmonks] after probably over 10 years

>>It is what I would call a write-only language.

I get a bit of vertigo, here...

You really left about a decade ago -- and don't seem to know much about what has happened since. But you have opinions?!

(If you wonder what is wrong with that quote, check the Best Practices book. [Edit: And as someone noted, chromatic's "Modern Perl" is good.] And so on.)

But the real joke here, are the upvotes. wtf?

Edit: For the third time... :-) "Write only language" is just trolling. PBP by Conway is the standard work on layout, variable naming etc etc. It is from 2005...


I left perlmonks a decade ago. I would also say I left the active community. Doesn't mean I haven't kept up with the language. Doesn't mean I haven't programmed perl in the meantime. What don't you get? You're making an attack on me about my own impression of the language because I haven't logged into a website for 10 years. Seems like if you disagreed with the substance of the post, you could have just explained it.

Also, of course I have opinions just like you. I told my story. And some people liked it and upvoted. I don't get why that deserves a "wtf" other than trying to rally people to downvote me.


>>What don't you get?

To quote myself, re "write-only language":

>>If you wonder what is wrong with that quote, check the Best Practices book.

Was that really so hard? (I might add that PBP isn't directly new... Then we have Moose, which is the best OO system among the scripting languages, etc...)

Edit: I might comment on this part, that "po" added afterwards:

>>Also, of course I have opinions just like you.

Well, I don't go and write standard troll comments from ten years ago in language discussions...


"Read the best practices book" is great for writing good code yourself, but a primary complaint of the OP is that reading others' code is pure hell. You can't guarantee that others have read it...


Well, the OP comments seems to get rewritten a bit, without adding "Edit:". :-)

Edit: If I should touch your point, too... the OP's complaints are literally about 1990s system administrators, which weren't really programmers. You'll get bad code in any language without coding standards, etc.


I have just started getting into perl and its terse procedural goodness is a breath of fresh air. Sometimes static types, classes and objects get really old.


That's why you must use Modern Perl. See guidelines in the free Modern Perl Book : http://www.modernperlbooks.com/mt/2010/11/the-book-is-out.ht...


Why? Because I don't want objects or because I should use objects?


Because sometimes objects are the right answer, and when they are the right answer, you want to be maximally equipped to use them as easy as possible.

Perl doesn't bash you over the head and make you use objects by making "int" an object, but they're there if you need them.

( And if you really need to, you can make int at least look like an object )


    where btw is A NICE HIP FEMALE PHRASE I COULD PRINT
    ON A SHIRT? 
I'm a vim ballerina!

    "we" are literally invisible to the bigger public, not
    matter how much CPAN grows and no matter how much #perl
    is the biggest IRC channel on freenode.
Secret societies are cool.


I don't see why females can't be ninjas and rockstars, or are these things just not as appealing to the "fairer sex"?


I thought this part of the essay was strange, because they sure as hell can be. Courtney Love, Brody Dalle, Joan Jett.

Not to mention: http://en.wikipedia.org/wiki/Kunoichi


I don't know, but being a "Perl rockstar" would probably evoke a more "prog rock" feel, not exactly the best target if you aim for sex appeal.

(NB: I do like both Perl and prog rock, so I personally wouldn't have problems with that.)


Here's an idea -> bring visitors to the perl.org front-page directly to #perl freenode channel, via a JS IRC client.

Let them speak directly with core users from the very start.


Nice idea, but what tends to happen is this:

    -- User1235 has joined #perl --
    user1235> PERL SUCKS 111!!!11!!1!!11!!
    -- Chanserv set mode +o mst --
    -- user1235 was kicked ( troll ) --
The people who are honestly interested tend not to need the door shown to them, and people who aren't interested can't be convinced by such tactics.


From the article:

"The iPhone isn't the highest sold smartphone"

Sure it is. At least in the U.S., Japan, New Zealand and Australia. In most other countries, Nokia is the most popular smartphone vendor, but because they offer hundreds of different models, I doubt Nokia has one specific model that sells better than the iPhone 4.

[U.S.] http://www.engadget.com/2010/11/01/canalys-iphone-becomes-mo...

[Australia] http://www.idc.com/about/viewpressrelease.jsp?containerId=pr...

[New Zealand] http://computerworld.co.nz/news.nsf/telecommunications/andro...

[Japan] http://www.businessweek.com/news/2010-04-23/apple-iphone-cap...


I learned vim over emacs because vi is installed on every linux machine I have ever touched, so when I sit down to a server and I need to edit a config file, I try vim, then I use vi, and I always find one or the other. I just opened Terminal on my Ubuntu 10.10 machine and typed "emacs" and it informed me that it wasn't installed, but was available in a slew of packages.


I never understood this rationale for learning vim. Do you really spend a lot of your development time on random Unix boxes you and all of your friends lack root access to?


These days, probably not that much, with the advent of virtualisation. But a decade ago there were a lot of shared shell servers in use with only a minimal install and a small per-user quota. So the rationale made sense...


Probably a good reason to use Perl too, finding a machine without it is hard. =)


A suggestion for a Perl screencast: using the Perl debugger. ~1.5 years ago my friend found a bug in the Perl debugger that had rendered it basically non-functional for several releases. I think it's telling that no one picked up on that for so long (i.e. no one is using the Perl debugger, probably because they don't know it exists and/or how to use it).

[ IIRC, it might be the bug under: http://perldoc.perl.org/perl5100delta.html ; search for 'PERLIO_DEBUG' ]


I guess I'll throw my hat in the ring. Perl is awesome, and since I've been using it practically my entire career and have contributed quite a substantial amount of time developing libraries for CPAN I suppose it my core-competency.

Bottom line, CPAN is awesome ... but lets not be a one trick pony. When you hear things over-and-over you should probably take notice (and maybe even onus). "Perl is not newbie friendly, past or present (modern)", "Perl community is not friendly (rtfm)", "Perl is not used for the new web", "Perl has no good IDE", etc.

I'd like to see Perl restored to its former glory because it is an incredibly versatile language. IMHO, I think Perl developers need to develop more purty public-facing tools, e.g. Websites, Web Apps, Desktop Apps, etc. .. see Lacuna Expanse for example.

CPAN Modules are not public-facing (or are to a point) and do nothing towards altering the perception of Perl.


Why Ruby? is a pretty damn good presentation. He talks about how the benefits include the culture, as well as the language.

http://ontwik.com/ruby/david-hansson-why-ruby/


I came to comment just the same. I used to work with Perl for about 4+ years, and now I'm on my way to exit a PHP work after 2 years. My next project will be in Ruby and this presentation helped me to rationalize the guts I had for Ruby (I've been playing a little bit with it).

The idea of making tools that are joyful to use to the programmers (wether it's the programming language, the editor, the SCM...) is something that appeals a lot to me, and it's something that (unfortunately) Perl lacks, basically due to it's syntax.

The community around the languages also affects, both have a great community around with hundreds of incredibly smart people with it's own quirkinesses, but the Ruby quirkinesses are more appealing to me (think DHH or _why) than Perl's (think Larry Wall or all the JAPH/golf...).


You haven't really started using Ruby till you start trying to JAPH and golf it. Fortunately, that phase will pass and you'll return to writing maintainable code =).

>> "The idea of making tools that are joyful to use to the programmers ... basically due to it's syntax."

Thats pretty much entirely "who is working in this language" based imo. As for syntax being a limitation, its interesting you complain that, because others have complained that the syntax is too dynamic, too augmentable, and too unpredictable, hence people talking stuff about it being impossible to write a parser for it =).

Granted, often when this feature is used, its often abused, and there are various 'source filters' in Acme:: you'd get shot if you tried using them in production ( Switch.pm is one such shootable offsense ... with great power comes ... extra unwanted side effects ).

But an example of a Good use of the source filter/metaprogramming nature intrinsic to Perl is MooseX::Declare ( its only part source filter, but its "Sane" because its smart enough to not cause too many unwanted side effects ) to provide alternative class declaration syntax, that some would claim, even looks readable!.

   use 5.010;
   use MooseX::Declare; 
   
 
   class Foo { 
         method hello( $what ){ 
             say "Hello $what";
         }
   }

   Foo->new()->hello("World");  # Hellow World\n


This is bascially what I was talking about.

Though the Ruby community managed somehow to drive off _why and someone like Zed Shaw if I remember correctly. If that really appeals to you...


    if I remember correctly
You don't. _why left open source for unknown reasons.


Don't really wanna go down here, but _why left after someone claimed to post his IRL name/info


That's certainly one leading theory, and probably the most likely. However, that happened earlier in the summer, a month or more before he actually shut everything down. There are other possible theories, eg, in his last tweets he lamented about feeling left behind by the progress of open source, or the theory that he planned it all along based on the Poignant Guide's ending.

No matter which of those reasons it was, it's pretty baseless to claim that he took down all of his websites, comics and open source software in a variety of languages including one he created due to some mysterious, unmentioned, irreconcilable beef the Ruby community, especially considering he was one of the most influentual people in defining that community.


'I've always wondered how those mechanism of "being THE it-language" or "the tool the cool kids use these days" or "success" in terms of "spreading everywhere" really works.'

Just having CPAN isn't enough. There need to be new and interesting projects that stand on their own and are current and relevant. I'm not saying there aren't, I just don't read about them on HN, reddit, etc. Perl was always about making things easy, and it wasn't hard to see how a perl script was better than a cgi handler in C. How is writing a DSL interpreter in Perl cool compared to, say, Ruby? How do the Perl MVC frameworks make things easier/better than rails or django?


That's totally not the point with all our languages these days - Ruby, Python, Perl - next year JavaScript will probably have a similar ecosystem of modules as we do as productive as the community writes code. Who doesn't have some amazing web framework these days?!

The differences boil down to details, architecture, stability, speed, security, documentation and the like - but seriously, do you really think some route handler in _programming language_ X or Y does make _any_ difference?

I personally didn't like the philosophy of RoR - I liked Merb better and got really put off by its community (and still am) and specifically by blog postings selling me shit as gold and all this "awesome <insert some simple basic not even well crafted solution to an every day problem here>" selling - but this is a matter of _taste_ and _personal preferences_ and don't really count as an argument.

Of course you can write a damn DSL in Perl in any way you like - otherwise a project like Moose wouldn't even be possible which wrote an entire metaobject OO system in Perl.

My point was that people usally plainly don't _know_ about those things and blindly think that PHP is the only language you can do "Web" with, Ruby the only language to write a DSL in and Python the only language well I have no idea what Python might be the only language for. ;)


Marketing re-energised the web after the period of downtime after the dot-com crash (O'Reilly and Web 2.0), I'm sure it could similarly re-energise Perl.

EDIT: If Web 2.0 wasn't a well crafted marketing campaign I don't know what is.


Now your edit is a phrase that would make a great tee shirt!


Also, Ruby is a better language than Perl. No amount of campaigning will change that.

(Before anyone follows-up with the usual "the right tool for the job", it's not the point here. There are good screwdrivers and bad screwdrivers).


in terms of stability? really?

I hear this a lot about Python. And I know a little bit about Python; I know less about ruby. But the thing of it is, from a SysAdmin perspective, Python is where Perl was in 2000. In 2000, you had differing versions of perl that were close enough to step on oneanother, but still so incompatible that you had to maintain one version of perl for your base OS tools, and usually another version of perl for every major application you used.

Perl has stabilized to the point where this is no longer a problem. I can run nearly everything on system perl without worrying about it. Python, on the other hand, I've had to wrangle with many RHEL systems that have two versions of python (one, because the RHEL base system requires a staggeringly ancient version of python, and then the other for the application the server was running.)

Python just isn't "done" in the way perl is. In five or ten years, sure. But for now, it's still a pain in the ass.

Hell, I'd bet money that at this point, perl5 has fewer memory leaks and other programming errors in the compiler than Ruby does, just because people have been pounding on it for so long.


I'm going to draw an analogy from Larry Wall's own words: Python 3 is to Python 2 what Perl 6 is to Perl 5, a different language.

Just because you had a bad experience with Python legacy code (yes, RHEL sucks), doesn't mean you get to discredit the language. What is it about the language you find unfinished? I'd be 99% certain any issue you're going to mention is actively being worked on.


That analogy is wrong. Python3 is not a different language. It is a cleanup of the Python2 language. Perl6 on the other hand is a total rewrite. The better analogy would be VB6/VB.NET and P5/P6.


My point was that even if the language is superior (maybe it is, and maybe it isn't. I'm not really qualified to debate the point) if the /platform/ is immature, that is still quite a disadvantage.

Me, I'm not complaining about the large, predictable breakage you get when changing major versions, but the breakage that you got with minor versions of perl5 10 years ago, that you get with minor versions of python 2 today.


Interesting... Are people using Python 3, now?

(Hint: I don't think the grandfather comment was about Python 3.)

And different languages doesn't say much. :-)

Perl 6, compared to e.g. Python 2/3, is a really ambitious undertaking. But OK, with the backporting going on, Perl 5 might end up being similar to Perl 6... :-)


I'm sure some are, but it's not mainstream. For example, the Django team hasn't started porting to Python 3 yet. For now, you can ignore Python 3.


It seems like formerly popular but effectively dead languages tend to be most popular with sysadmins. (It explains bash, sed, and awk, at least.) So I'm not sure that being popular with sysadmins is really what the folks who want to revive Perl are going for?


That is just a monstrously huge opinion and that is all it is.


    > Also, Ruby is a better language than Perl.
"Perl is the syntax, CPAN is the language"


What's the fastest way to learn about the benefits of SPAN/Perl?


Recently chromatic finished his book "Modern Perl":

http://www.onyxneon.com/books/modern_perl/index.html

you can download the PDF for free:

http://www.onyxneon.com/books/modern_perl/modern_perl_letter...

http://www.onyxneon.com/books/modern_perl/modern_perl_a4.pdf

this book follows and introduces modern practices/modules developed by the Perl community in recent years.


The quality of the syntax is purely a question of taste and as such isn't really debatable (de gustibus coloribusque non disputandum est), but so far it seems that Ruby still lacks in scalability and speed compared to Perl or Python.


    Ruby still lacks in scalability and speed compared to Perl
Ruby is faster than Perl, according to the language shootout:

http://shootout.alioth.debian.org/u32/which-programming-lang...

http://shootout.alioth.debian.org/u32q/which-programming-lan...


It depends which graphs you look at:

These graphs tell me

1. Perl is slightly faster. 2. Perl uses much less memory on average 3. Perl uses less code.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

However, on Ruby18 you do have a substantially bigger problem:

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

Lies, Damned lies.


> These graphs tell me

It must be the spectacles you're looking through.

These graphs tell me that

- about the same number of Perl programs are faster than the Ruby 1.9 programs by about the same amount, as there are Ruby programs faster than Perl programs

- some of the Perl programs use half the memory of the corresponding Ruby 1.9 programs

- the Perl programs and Ruby 1.9 programs use about the same amount of code.


> Ruby is faster than Perl

Only if you focus on a single number - the median - and ignore the complete overlap of the measurements shown by the boxplot and interquartile range.


As a canadian I wish manufacturers would use robertson screws rather than those damn philips screws. But alas, things are manufactured for north america as a whole and the canadian market is so small compared to the US market. Then again it could be worse, they could be using flat head screws.


As an American, I see flat head screws quite often (but also philips).


Robertson screws are not flat head screws. They are a type of screws that is particularly popular in Canada and that requires a square screwdriver. Look it up on Wikipedia... it's an interesting tale of intellectual property guarded too zealously for the inventor's own good.


There are also phillips head, straight edge and torx :)


There is also Robertson, which is superior to Philips, but lost due to poor marketing :)


What I'd heard was that the Robertson screw, though awesome, didn't take off due to exorbitant royalties, but checking, it looks like he refused to license them to let anyone else make them after getting burned, & having only one supplier worried Henry Ford too much to use them.

http://en.wikipedia.org/wiki/List_of_screw_drives#Robertson


Sounds a bit like Android vs iOS (or Windows vs. MacOS).


Each come in good and bad variety.


True - but you need to compare like-to-like to make a fair comparison.


Nice article, although I'd fear a "Project for a New Perl Century". If there were an International Criminal Court for Programmer Rights, Perl should be the first language tried for crimes against programmerdom.


Any "crimes" were the fault of the programmer and not the language. Period. End of story.


I don't get it; when the Perl folk thought they had to reach the masses, instead of making Perl 5 more accessible to newbies, instead of covering Perl events (a comment on the blog mentions some specialized hardware for doing so - lol), instead of actively pushing Perl projects, they decided to come up with Perl 6!

Yet Perl 6, except from some blog posts describing its utter dominance over Perl 5 performance, still hasn't seen the coverage/promotion it deserves (I'm assuming here, because I'm not using it).

Maybe there are some lessons to be learned here.


I don't get it

To start: there exist Perl programmers who have worked on both Perl 5 and Perl 6, specifically to make Perl 5 more accessible and to make Perl 6 more imminent. Don't assume the entire Perl community is a hivemind with a single shared purpose.


I don't; and that wasn't my point.


To whom does the pronoun "they" refer, if not "the Perl folk"?


I started replying, but I'm not going to engage in a discussion of syntax and semantics. Feel free to downvote me.


I'm just getting into Ruby and converting to vim as my primary editor, and I didn't even know that this is a "hip" thing to do. All of a sudden I feel trashy for making logical choices.

I think the author misjudged why people like me choose Ruby and vim -- choices that have nothing to do with each other, btw.

I'm a fan of terseness and readability. Ruby has a reputation for both. I've never heard the following phrases spoken: "Perl is great for writing DSL's." "Perl is very readable."

The most amazing experience has been going on GitHub on day one, reading the Rails, Haml, Sinatra, Tilt, you name it, code and being able to understand virtually any part of it. This is not only a testament to the language, but also a testament to the quality of the frameworks and the API's that are being produced with it. Show me a web framework written in Perl that I can dig into and understand with zero Perl experience.

Vim, on the other hand, is a sour-sweet topic. Here is the only reason I'm using vim: everything else sucks ___. Vim also sucks ____ because in 2011 it is still a text editor that can't copy paste using the "normal people" shortcuts. I'm looking forward to the day I finally customize vim enough to match Notepad in usability.

As much as vim usability sucks, I know that I can spend a year customizing it (and it will take a year) and be able to rely on it for the rest of my life. In contrast, there is no such incentive to invest into the monstrosities riding over the JVM (not calling names).

Also, screencasts are great because I read all day and its tiring, physically tiring. Sitting back, relaxing my eyes and being educated while I sip on a coffee and have a cookie is my idea of fun. Screencasts are free, bite sized, training. By the author's logic Khan Academy is worthless as an educational tool because most of it is written somewhere.


Regarding vim and "normal people" shortcuts, if 'source mswin.vim' doesn't work for you, here are the mappings I have in my .vimrc to give it the normal CTRL-C, CTRL-X, and CTRL-V, as well as sharing the clipboard with windows:

    " share clipboard
    set clipboard=unnamed  

    " CTRL-V is Paste in insert mode
    imap <C-V>		"+gpa   
    " CTRL-C is Copy, CTRL-X is Cut, in visual mode
    vmap <C-C>		"+y
    vmap <C-x>		"+d
    " Use CTRL-Q to do what CTRL-V used to do
    noremap <C-Q>		<C-V>


Thank you for sharing that. I've never heard of source mswin.vim. The standard copy paste shortcuts are platform agnostic at this point, hell, even my phone uses them (webOS). This is where I've found vim and emacs incredibly frustrating out of the box.


Show me a web framework written in Perl that I can dig into and understand with zero Perl experience

I think delving into any web framework with zero language experience isn't going to be easy :)

However here are two Perl web frameworks which (IMHO) are easy to follow:

* Mojolicious - https://github.com/kraih/mojo

* Tatsumaki - https://github.com/miyagawa/Tatsumaki


Try ":source mswin.vim" - I think that should give "normal" style copy/cut/paste behavior - note that "old" ctrl-v becomes ctrl-q with this change.


Communication skills correlate with social standing. News at 11.

:)


Sure, maybe the idea is obvious - I suppose the interesting question is 'how can a transformation occur?', which is something the article tries to address.


Hip or un-hip, ChargeSmart loves perl - developers looking for work at a San Francisco based funded payments start-up should email me their details, pmikal [at] ChargeSmart.com.


"... Err, yeah well of course Vim is a really nice programming editor, man - why do you think we use it?! ..."

traditionally because if you are on a machine with limited memory vi, vim is the only editor that will load and there is no way you will get me using 'ed' again ~ http://www.faqs.org/docs/artu/ch13s02.html#id2963445


Maybe you should market Perl as uncool and weird and without annoying yuppies like DHH. ;P


This article kind of made me want to get better at Vim.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: