If they spent two seconds researching Modern Perl and Enlightened Perl they would say WOW look where Perl has come!!!

What would I like to see?

• Easier interop with other high-level languages like Matlab and R. All of them have C interfaces, but going through C requires writing two bindings. I've usually found it easier to just have perl read and print the other language's data format (this is what many of the CPAN modules do, too), but that's not necessarily all that efficient.
• Easier C binding. Inline::C is pretty good, but requires a compiler and doesn't feel quite "done." Maybe C::DynaLib would do the trick.
• Simpler PDL. PDL is very powerful, but it's not conceptually simple, and it uses terminology unfamiliar to anyone coming from another mathematical language. Also, it can be tricky to install, requiring both C and FORTRAN compilers, as well as some weird external libraries, to get the most from it.
• A better Bioperl. IMHO Bioperl is an over-engineered disaster (or at least it was 4-5 years ago when I last looked at it). Someone who started over from scratch, developing efficient representations for sequences and graphs, then building data input/output routines for various tools' formats, would be doing the world a great service.

They're slick marketing around some slick code that some people find useful.

As with the other commenters on this thread I think you are totally off on this one. The Perl Foundation, Modern Perl, Enlightened Perl, and the rest of the Perl community actually do very little "slick marketing" of the great things they are producing that help us Perl programmers get our jobs done efficiently and elegantly. For better or for worse other languages have done more "slick marketing" and gained popularity solely because of that. Most humans unfortunately seems to be attracted only to pretty shiny things e.g. look at Apple they have mastered this art.

Particularly with newcomers and beginners to a language in order to attract them Perl should market a little more, they are the the lifeblood of a language that keeps the community thriving.

Easier interop with other high-level languages like Matlab and R. All of them have C interfaces, but going through C requires writing two bindings.

I agree I've mentioned RPy2 as an example to Adam Kennedy who maintains Statistics::R as a future roadmap, Perl binding directly to R's libraries.

Easier C binding. Inline::C is pretty good, but requires a compiler and doesn't feel quite "done." Maybe C::DynaLib would do the trick.

Have you looked at SWIG or XS? I agree for C++ Perl binding (where you can use SWIG or XS++) I wish there were more experts and examples out there to help beginners but with C binding you have tons of stuff to help you so many libraries on CPAN have C binding via XS and therefore you have tons of examples to get you going.

A better Bioperl. IMHO Bioperl is an over-engineered disaster (or at least it was 4-5 years ago when I last looked at it). Someone who started over from scratch, developing efficient representations for sequences and graphs, then building data input/output routines for various tools' formats, would be doing the world a great service.

BioPerl is a project that started over a decade ago (read here http://www.bioperl.org/wiki/History_of_BioPerl) and has grown organically along with the new era of biology that was born at the same time. When developers do things using their free time for free it can be difficult to refactor and improve a huge library as time goes along. Also the BioPerl developers have had to maintain stability, backwards compatibility, and support for older versions of Perl which prevented them from refactoring the entire codebase to a more elegant solution. This would have happened in any language.

Have you looked at SWIG or XS?

I use SWIG regularly, and believe it's the best option currently available for C/C++ bindings. It's also nice that you get Python, Ruby, Java, etc. bindings along with the Perl ones. I have written XS for a couple of projects, but prefer SWIG or Inline::C.

BioPerl is a project that started over a decade ago

Age and organic growth have nothing to do with its problems, except to the extent that Java's popularity when BioPerl started led its original developers to overengineer the heck out of it. Like I said above, IMHO the best "refactoring" would be to start over.

I agree I've mentioned RPy2 as an example to Adam Kennedy who maintains Statistics::R as a future roadmap, Perl binding directly to R's libraries.

Sorry made a mistake here, getting names from different mailing lists mixed up! :) I meant Brian Cassidy not Adam Kennedy, sorry Brian

They're slick marketing around some slick code that some people find useful.

Shh, don't tell anyone that I've made millions of dollars encouraging people to use three-argument open, lexical filehandles, App::cpanminus, autodie, and testing. You'll ruin it for everyone.

Where did I say you made any money? You've made a name (or at least pseudonym) for yourself, so maybe you could make money on speaking and books -- I don't know, and I don't really care. Anyone loud and persistent enough can do that. But what kind of name have you made?

As a fellow bioinformatician and programmer, I have to say that I could not possibly care less about these things. They're slick marketing around some slick code that some people find useful. A sizable number of modules on CPAN (though a small fraction of the total) are just as useful, but not as aggressively marketed.

I am not sure what the problem is with "slick marketing around... slick code," if any. I, for one, welcome it. Is this purported slickness harming perl? It seems that the last sentence in the quote above implies perhaps that the sizable number of modules on CPAN that are just as useful should indeed be aggressively, and hopefully, slickly, marketed, non?


when small people start casting long shadows, it is time to go to bed

Well, then feast your eyes on pdl.perl.org

Looks like someone with a better eye for design recently got a hold of the website, which a lot of projects would benefit from. These efforts are crucial to get people excited about using Perl. If we don't, the language risks stagnation and people will move on - something Jon Orwant pointed out 10 years ago

As a community, I'd suggest that people aim to be ready to shout their efforts with loads of slick marketing for the launch of Perl 6 and ride the wave of shininess. Jokes aside, The Year of Perl 6 should really be a whole year full of Perl.

perl -e 'print qq(Just another Perl Hacker\n)' # where's the irony switch?

I'd like to throw a question back at you.

There is a long mile between knowing what ought to happen and making it actually happen. Key elements of marketing are knowing your target audience and understanding how best to get their attention. If you were to plan out a public relations campaign for the scientific/financial community, how would you go about it?

• What messages or stories would get attention and interest? Journal articles? Case studies? Here's "how I made it work" essays?
• Is bling or coolness needed? Fancy graphics and jingles? Ipod touch/ipad apps?
• Where would they have to be placed? blogs? newsgroups? portals? word of mouth?
• Who would have to deliver the message? Are there big names people trust? Who are they? How would you get them to want to talk about how great Perl is?

If you were to plan out a public relations campaign for the scientific/financial community, how would you go about it?

Hi there, not sure if this reply was to ask post author. What I asked myself a while ago was "how did Python and the NumPy/SciPy/matplotlib stack become popular in these communities?"

The first thing that's vital is to have great tools and libraries available that cover most if not all needs and are easy to install and easy to integrate together. For example some people have said that PDL's integrated plotting libraries PGPLOT and PLplot are not as good as the competitors. This can be fairly easily improved and we've talked about it on the PDL mailing list. Perl R integration using Statistics::R is not nearly as complete an interface as say RPy2 and I've mentioned that to the maintainer. People on PDL also have been discussing making a full-fledged wxPerl PDL IDE with embedded plotting which would be a awesome for PDL and the knowledge to do most of it is already there from the Padre community.

With the tools and libraries there and easy to install and use then it's about communicating to the scientific and financial communities that you have a stack that is as good if not better than the competitors and what advantages your stack has. This can happen organically without need for direct communication if you have great tools, a la "if you build it they will come", people start using it and telling others, etc.

Make people's jobs easier. Remember how Perl became popular? Sysadmins wanted to write scripts, and Perl was better than SH. Then people wanted to make web pages, and Perl plus CGI made that much easier.

Write packages that make people's lives much easier, then publish them. For example, do some research good enough to get into a top journal, use Perl to do it, and release your code. No, that's not easy, but true, lasting success never has been.

Closely tied to the article I posted yesterday Polly wants some Numerical Computation. Must be the phase of the moon.

Write a book teaching numerical calculation using PDL & Statistics::R, and O'Reilly will publish it. You might even get $5/hr for the work you put into it.

Get the feel right, and it might get used as a textbook, so some people actually read it.

Write a book teaching numerical calculation using PDL & Statistics::R...

I'll publish it.

---

Improve your skills with Modern Perl: the free book.

The discussions from the OP and all the responders intrigue me and I enjoy the diverse perspecives on the issue. Thanks to all for their rich ideas, thoughts, and perspectives.

In my work place we have had a real world example of this very discussion. Our language of choice for testing and command and control of many of our space missions has been Perl. It has been a wonderful and trustworthy workhorse and we rarely use or need the various CPAN modules and capabilities of additions like PDL or MOOSE or the like. Not that they aren't useful or great; we just don't need them or use them...and on our command and control systems we're generally not allowed to import externally generated code except as comes in the core of Perl. We have a few internally developed and maintained libraries that we have used for almost 15 years and, while they've grown and morphed over the years, they get our job done.

We recently, however, decided to do a complete re-look, from the ground up, at our whole system and to "bring it into the 21st century" as our senior leadership likes to say.

We are looking at a whole nest of more "modern" approaches to capabilities to try to harness everything from "data mining" to "adaptive, emergent behaviors". I'm not saying that we *need* such capabilities per se; but rather that we're trying to consider in various niches how we could be much more effective, efficient, and capable.

I and my collegues have for about a year now been casting our nets wide throughout the community looking at where the state-of-the-art is today and we are considering how (or even if) we could benefit.

One outcome that crept in somewhat unexpectedly is that we have found several promising techniques (especially in terms of Service Oriented Architectures (SOA), data mining, etc.) that we are migrating towards. So we have all been absorbing, at high rate, every book and article that we can get our hands on to try to figure out how best to embrace these promising technologies.

The surprise is that almost *all* of these various currently popular techniques are richly described and even have lots of learning examples and algorithms readily available...in Python!

So over the last 2-3 months a movement has gone afoot to discard our Perl backbone and replace it with Python.

The only real impediment is that we would truly have to "start from scratch"...all the way from retraining our programmers to the learning curve of beginning to reprogram in another language to having to redevelop and test and verify all of our decade-long work in libraries that are still (and look to be into the future) our bread-n-butter. All because folks are starting to say, "Python *must* be the way to go since all of these 'modern' topics use it...none of them use Perl as their backbone or examples!"

I have a beginner's knowledge of Python and find it interesting but have yet to find anything that makes it any *better* than Perl. It is more compact in some ways; more troublesome and clunky in others. But in no instance that I've found so far is it *better*...just different. I can certainly see that it is fine language and can do the job, too. But I'm having a hard time getting that point across to those who keep pointing out that "it (Python) *must* be better because that's what all the gurus of these neat new gadgets use!"

So, to me, the problem with Perl is that noone is using it in a very visible, documenting-state-of-the-art new ideas using it. It is *not* sufficient, in my view, to just do great research and new technology developments in Perl and to publish the results such that Perl's contribution is better highlighted; it has to be used in popular, easily accessed examples for newly emerging techniques such as SOA, data mining, etc...especially in course text-book and popular introductions to those new techniques and technologies.

That's just my view; obviously it's just one more perspective.

Might I suggest the best of both worlds given your situation. Use the Python as "pseudocode" to write the algorithms in Perl. You keep your expertise in the language domain while benefiting from the work in another (and benefiting the Perl community in general with the new tools).

Perl really can make this kind of thing easy and having sample code before to redraft/translate can sometimes even lead to better code as you won't be boxed in or painted into a corner the way so many code bases end up, you'll just be guided.

Compare your project to the Perl effort to port Python's WSGI. And don't stop there! There is more to be learned from others. Why not mix in Ruby's Rack? We arrive at Plack. And it was a pretty short trip.

Caveat: if your team was reticent to hit up the CPAN for help in the past, trying to keep this kind of thing together on your own might not be a good match for your culture. "Modern" has more to do with approach than the language and if you're rooted in old-school Perl it might be harder to change that than to change languages.

And how do you plan to convince people to repeatedly rewrite a piece of code that works fine in Python to Perl?

Unless a Person is Perl fan, the moment he sees Python looking for cleaner and getting the job done. He will switch to Python.

A few points from my end.

1. Its not sufficient just to do good, we must look and speak about that good. I seriously think Python has some genuine advantage over Perl. It has good defaults and currently the best web frameworks in its class. People are building cool stuff in it and demonstrating it to the world. When something gets that sort of attention and real world business benefits are shown, its bound to get famous and adopted widely. We need a major revamp in our attitude towards a lot of things. Chromatic has done a lot of good job, and he deserves a lot appreciation for what he has achieved with Modern Perl.

2. Building something cool and showing it to the world is important. Every other day I see post on HN or reddit where there is some discussion on how some problem or a start up was done with Python. We need more of those. Blogs showing real life uses of Perl and their comparison over other languages. Once people are shown how many good things can be done with Perl, a lot of people will join the party.

3. New shiny stuff is important. Standards are important, People are a little afraid to try out Syntax plugins in production because 'not in core' basically means not standard(You may call that thing wrong, but it unfortunately works that way). Nobody wants to maintain a third party bolt on for as basic things like class and method syntax. Besides the boiler plate scares away a lot of people. All that needs to change. People need to be shown that all the Moose and Syntax plugin magic can be made to work from a out of the box installation, without module installation, configuration and worrying about plugin dependency and maintenance here. I am speaking about old school lessons of usability here. Syntax plugins and magic modules just need to felt like being used as a part of Perl, rather being perceived syntax modules.

3. Perl 6 needs to show up or remain silent. We can go on harping about various definitions of 'release ready' software. But for 99% of the world a 'release ready' software means a feature complete, stable and release with a good ecosystem of tools and libraries. Atleast if not frameworks and all the make up stuff. Basic things need to be ready. Writing blog posts and then the discussion descending to questions on Perl 6's readiness, followed by elaborate discussion on X number releases of incomplete buggy software being termed as release ready is embarrassing to say at the least.

4. Some make up and dressing up is needed for sites like Perlmonks and CPAN. For heavens sake we live in an era where people buy iPhones only for the gloss factor. Dumb web pages are good for gray beard system administrators but not for most part of the world. The way things are presented matters a lot.

I think this is due to pure luck
Objectively, python is no better: programming python is like using "no strict" everywhere, it has inconvenient syntax for regex, and many more.

but the true is - python is indeed popularized better...

How about the middle ground?

Perhaps there is room in this world for More Than One Language, and perhaps the only important thing is that “the job gets done.”   Python is also a very clever language, and in some ways it is extremely Lisp-like.   On my computer I can type the perl command to get to one, and the python command to get to the other.   Why does Perl (or Python) need an advocate or a defender?   I am not in these areas of computing, but I nevertheless like both languages, know both, and in various situations choose one vs. the other.   “Tools for the job,” you know, and tool boxes are pretty big.   Always room for one more . . .

There is definitely room for multiple languages and indeed there are, all of us agree with that. I think the discussion is not about whether the world needs multiple programming languages it's about how some are negatively and falsely painted.

I make a serious point of spending lots of time to correct any falsehoods I find made about Perl typically by Python or Ruby programmers who don't know squat and haven't kept up with Perl in 5 years. As I've written before these false statements are never retracted even though they are proven to be false and they hang out on the web, get indexed, and people see them and start to believe them when they see all this crap. It's analogous to Fox Noise on TV, don't bother to retract any lies and then the lies become true.

• Avoid the overcomplexity of projects by emphasizing the flexibility and simplicity of the [ language/module/feature/etc. For me, I would emphasize these in the reverse order. That is, key in on simplicity first and flexibility second. My take on a lot of programmers nowadays is that they want to be spoon fed the right way to do things. They will take a simple example over a lengthy discussion of multiple ways to accomplish something. ]
• Write better documentation. [ You are not going to win without this, which is one of the reasons for my reposting these bullet points. Making good documentation is a collaborative effort. You will have to either guide module authors to write more clearly or rewrite the documetation for clarity/brevity yourself.]
• When the best way to do something changes, deprecate old documentation and point to the new approach. [ I covered this in the last bullet point, but I think the key is to take up the pen and combat outdated/inaccurate information whenever possible. For example, there is this guy who created a website to catch U.S. military veteran imposters. I saw a television news story where even some branches of the military were using the site to weed out phonies. You never know what one person can do to change the world. ]
• Emphasize simplicity. Make the default a good way to do most things. Provide comprehensive tutorials which explain the entire system using that effective default. [ Frankly, I don't know what this means but it sounds good. ]
• Provide smaller upgrade paths and avoid big-bang incompatible releases which fork documentation and knowledge. [ In other words, think Agile. ]
• Unify where possible. [ In order to do this you need to create synergies between people who are working on different, but complimentary modules/documentation/projects/etc. Work on your people skills for this because you will need them. Don't forget that you will attract more bees with honey than vinegar. ]

No but seriously, nice comment and summary :)

That is, key in on simplicity first and flexibility second. My take on a lot of programmers nowadays is that they want to be spoon fed the right way to do things. They will take a simple example over a lengthy discussion of multiple ways to accomplish something.

I totally agree, particularly novice-to-intermediate programmers learning Perl. If they get in any way frustrated and there is an easier language to learn that does the same things they will of course take, as you said, the path of least resistance. One of the reasons in my community for moving to Python was exactly what you stated, Perl from their perspective didn't spoon feed them the best or most recommended way to solve whatever problem they were working on and people just want to get their jobs done without any additional hassle, again very much like what you have said. Python for all of its problems has spoon fed for better or for worse and that attracts programmers who are frustrated and just want to solve their problem.

Now this shift started occurring a few years ago when Perl as a community was more or less at a lower point, but since then as we all know there has been a incredible new energy, so many amazing distros on CPAN, and so much has changed in the language that most of those people in my community who changed wouldn't even recognize the Perl of today. From my perspective there has been big shift since a couple years in the community's attitude towards the comments you have stated and many major things within Perl have and are being done this way.

With Perl and CPAN so many of us love that it's so powerful and flexible there isn't any programming problem that cannot be solved with it, but I am glad that leaders in the community are seeing that humans don't like too much choice, that to keep new programmers we have to make the learning curve as easy as we can (yes more spoon feeding). There has been a lot of research done showing too much choice is confusing and frustrating and with programming humans are no different, as one example have a look at the book Paradox of Choice: Why More Is Less.

Perl has a new Many-core Engine (MCE) to help maximize on all available cores. There's an entire folder dedicated to matrix multiplication using plain perl as well as with PDL. The read me contains benchmark results for parallelizing matrix multiplication across many cores.

... and making sure we don't get bought by Oracle :)

I think you didn't quite understand the issue, we are not discussing what Perl is. But what Perl will be given the news hype(Even if false) that other scripting languages are getting.

Most of the worlds developers use something just because a lot of people are using it. That's how Java and Python are winning. Hype and News attracts people because they are often interconnected with things like Jobs and number of projects.

Therefore its important to make noise regarding what you have doing. Even ten line Python scripts get posted on reddit and HN. And in the Perl world CPAN grows by tens of modules everyday and we don't even make a noise. Lets start posting links to two to three modules on these modules every day and you will suddenly see due to all that noise there will be rise in Perl adoption in those communities.

PDL is pretty slow, also, compared to other available software for doing what it doesn't provide the speed, ease of use of other pieces of software.

I've been a PDL developer for a few years now and am the current release manager. This is the first time I've heard any reports that "PDL is pretty slow". I would appreciate references and benchmarks for this.

Also, a weird thing is that PDL depends on OpenGL, so on a machine without X you can't actually do anything with PDL (or you can but it takes you some additional $amount_of_time). That is not normal since machines that only crunch numbers needn't have X on them.

OpenGL is not X and X is not OpenGL. We're moving the baseline graphics capability to one based on OpenGL because it is the best common denominator for 2D and 3D display across all the major perl platforms.

Also, how portable is PDL actually? Haven't tried it on windows.

See the CPAN Testers matrix for the PDL-2.4.7 stable release at http://matrix.cpantesters.org/?dist=PDL+2.4.7. For current and accurate information on PDL, I refer you to our web site at http://pdl.perl.org

Also, the book Modern Perl, if everybody agrees

Muhahahaha. *Everyone agrees*? This is the Perl community. Even the relative small number of people on p5p (the people that usually do the actual work on the documentation) cannot agree on anything.

Perl is something that was an improvisation and it's starting to get more organized.

Perl organized?

But nobody knows that it's organized because they don't have the time to read all the blogs in the Perl "ecosystem" and go on IRC and ask a ton of questions on various channels.

Ah, it's organized because it has too many blogs and channels for a sane person to follow!

I would say that Perl isn't organized. Larry Wall != p5p != TPF != YEF != OSCON != ... "Modern Perl" is just someones view of how one can program. A view that has some followers. A view that also many people disagree with.

Perl is all about "there's more than one way of doing it". And that's not limited to having more than one way of programming a basic thing. It extends to the entire "cloud" around it.

So if they include the "Modern Perl" modules and docs in the documentation that comes with every Perl distro then maybe the situation will change.

Unlikely. If only that most people don't even read the documentation.

<quote>Unlikely. If only that most people don't even read the documentation. </quote>

that's because the documentation is bulky sometimes and for a beginner it's hard to quickly find what they're looking for, IOW the documentation is a reference.

I would say, put that famous book in the docs and see what happens. I would expect a positive outcome. Am I right chromatic ?