Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Putting Perl Back on Top in the Fields of Scientific and Financial Computing

by hermida (Scribe)
on Mar 05, 2011 at 15:55 UTC ( #891575=perlmeditation: print w/ replies, xml ) Need Help??

Hi everyone,

As a bioinformatician and software developer of many years and avid Perl programmer and supporter, one thing I've noticed over the past few years is that Perl has been needlessly losing ground to Python in the major areas of scientific and financial computing, areas where it used to be *the* high-level interpreted language of choice. I am constantly having to correct people on blogs and forums that state incorrect Perl shortcomings when compared to Python or they were shortcomings from many years ago which don't exist anymore in the current language and ecosystem. If they spent two seconds researching Modern Perl and Enlightened Perl they would say WOW look where Perl has come!!!

All of us know there is no absolutely no technical reason for this, Python as a language is not "better" than Perl for any reason, choosing one over the other is simply a matter of personal preference to the style of the language. I program in Python as well and I definitely think that Perl has far more to offer in terms of CPAN and its community.

To illustrate what I've been seeing let's look at the following. In scientific and financial computing, Python has a great set of libraries and toolkits that users commonly use together in their research and work:

  • NumPy - N-dimensional array object container for SciPy and tools to integrate C/C++ code
  • SciPy - scientific computing libraries for science, mathematics, engineering
  • Rpy2 - tightly integrated low-level interface between Python and R for statistical computing
  • Matplotlib - 2D plotting library
  • IPython - Enhanced interactive Python shell
  • Boost.Python - Seamless interoperability between C++ and Python

In Perl we have these same capabilities and tools if not more:

  • PDL - The Perl Data Language, which has:
    • N-dimensional array objects
    • integrated scientific computing libraries for science, mathematics engineering
    • integrated 2D plotting libraries via PGPLOT and PLplot
    • integrated 3D graphics libraries via OpenGL and TriD
    • and much more...
  • Statistics::R, Statistics::useR - basic integration between Perl and R for statistical computing
  • ExtUtils::XSpp and SWIG - interoperability between C++ and Perl
  • Countless other libraries on CPAN for math, science, engineering (just look at Math::*, Statistics::* namespaces for example)

The problem seems to me that simply no one knows about these tools and/or for the average scientist or quant installing/using/integrating them is more difficult than their equivalents in Python. For example, PDL is only well known in the astrophysics community when it is perfectly suited and written for any science, math, engineering work! Compared to Python we don't make it easy enough for newcomers to get going and these are the people that need this help the most. This shouldn't be happening and is bad for the community because the overall goal to keep a language thriving, growing, and dynamic is to get new programmers into that language. When they come to those times in their working life or in school when they have to make a decision as to what they are going to choose that they see Perl has an equal if not better platform to offer them!

I think we really need to:

  1. Communicate to the public in a clear, exciting, and attractive manner what we have to offer (why are there very few if not zero Perl books in the pipeline? Look at Python they have tons... why?)
  2. Make our tools and libraries much easier to install and integrate

The Python community seems to package their tools together, make them easier to install and use, and communicate that they exist to the public better which is a shame because again I believe Perl has so much more to offer than Python in terms of CPAN and its community.

I would really appreciate any input, feedback, criticism anyone has... I really care about Perl and want the public to see all it has to offer!

Comment on Putting Perl Back on Top in the Fields of Scientific and Financial Computing
Re: Putting Perl Back on Top in the Fields of Scientific and Financial Computing
by educated_foo (Vicar) on Mar 05, 2011 at 16:55 UTC
    If they spent two seconds researching Modern Perl and Enlightened Perl they would say WOW look where Perl has come!!!
    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.

    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.
    Even without these things, I use Perl as the glue for much of my work, and find it works just fine.
      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?
      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

      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?
Re: Putting Perl Back on Top in the Fields of Scientific and Financial Computing
by ELISHEVA (Prior) on Mar 05, 2011 at 19:55 UTC

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

      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.

Re: Putting Perl Back on Top in the Fields of Scientific and Financial Computing
by TomDLux (Vicar) on Mar 06, 2011 at 02:38 UTC

    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.

    As Occam said: Entia non sunt multiplicanda praeter necessitatem.

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

      I'll publish it.


      Improve your skills with Modern Perl: the free book.

Re: Putting Perl Back on Top in the Fields of Scientific and Financial Computing
by spx2 (Chaplain) on Mar 07, 2011 at 16:35 UTC
    Also knowing Perl well requires more time than knowing Python well.
    You need time to study Perl's quircks and variables, to give only a few examples:

    - perlvar
    - perlop

    Also, the book Modern Perl, if everybody agrees that it's such a nice book and all, should be integrated in perldoc or in Perl's official documentation, because only in this way people can have easy access to it (It should be distributed with the perldoc package in Ubuntu for example).
    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.
    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.
    Also, how portable is PDL actually ? Haven't tried it on windows.
    So Python is used for financial and scientific computing because its syntax is easier to learn.
    Perl is something that was an improvisation and it's starting to get more 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. 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.

    But in bioinformatics I think Perl is used a lot, I see recurring questions from students in bioinformatics here on perlmonks and some books are out on that and the BioPerl package is pretty vast, lots of people worked on it and I'm pretty sure it's development was well-funded by some big companies in the domain.
      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

        well, I would benchmark it against LAPACK, but I don't have the time, but if you want, you can do the benchmark and show me that I'm wrong :)

        As a matter of fact, I would like to see some benchmarks myself, who knows, maybe I'm completely wrong(I saw most of the PDL code is C code and the Perl is just calling that).

        the main problem is if people would use Perl+PDL for scientific/financial computing, but if they decide they won't use it, it doesn't matter if it's fast or slow. I think it is slower than LAPACK which doesn't necessarily make it very slow, just slower than LAPACK ..
      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 ?

Re: Putting Perl Back on Top in the Fields of Scientific and Financial Computing
by vkon (Deacon) on Mar 08, 2011 at 19:14 UTC
    I also noticed this a tendency
    What could I say?
    at some time, Python had better luck - it noticed and popularized better, and it became popularized a POV that python is more modern compared to perl.

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

Re: Putting Perl Back on Top in the Fields of Scientific and Financial Computing
by sundialsvc4 (Monsignor) on Mar 09, 2011 at 14:56 UTC

    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.

Re: Putting Perl Back on Top in the Fields of Scientific and Financial Computing
by Anonymous Monk on Mar 22, 2011 at 05:08 UTC

    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.

Re: Putting Perl Back on Top in the Fields of Scientific and Financial Computing
by ack (Deacon) on Mar 24, 2011 at 17:14 UTC

    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.

    ack Albuquerque, NM

      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.

Re: Putting Perl Back on Top in the Fields of Scientific and Financial Computing
by petdance (Parson) on Mar 24, 2011 at 21:29 UTC
    Perl is still huge in finance here in the Chicago area.

    xoxo,
    Andy

      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.

Re: Putting Perl Back on Top in the Fields of Scientific and Financial Computing
by InfiniteSilence (Curate) on Apr 09, 2011 at 02:45 UTC
    I found a nice article online titled How Perl can Avoid Java's Worst Web Messes that, although does not discuss the subject of this post directly, contains a section that I think pretty much sums up how to solve the supposed weakening of Perl in favor of Python's offerings dilemma. I'll copy the bulleted list here and make a few edits:
    • 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. ]
    In all, if you apply these principles collaboratively with others who think/feel/act similarly you can turn around virtually anything including some perceived trend toward a weakened position. I think what people want to see most of all is activity that produces results that will benefit them in their work and/or lives. When that activity is clear and the benefits are easy to grasp people will naturally gravitate toward it. When it is not the attention quickly moves to the path of least resistance, which normally means a competitor.

    Celebrate Intellectual Diversity

      ... and making sure we don't get bought by Oracle :)
      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. Check out the MCE 1.403 release. 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.

        https://metacpan.org/source/MARIOROY/MCE-1.404/examples/matmult/README

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://891575]
Approved by Old_Gray_Bear
Front-paged by luis.roca
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2014-09-15 02:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (145 votes), past polls