Slashdot Mirror


Where's the "IronPerl" Project?

pondlife writes "A friend asked me today about using some Microsoft server components from Perl. Over the years he's built up a large collection of Perl/COM code using Win32::OLE and he had planned on doing the same thing here. The big problem is that as with many current MS APIs, they're available for .NET only because COM is effectively deprecated at this point. I did some Googling, expecting to find quickly the Perl equivalent of IronPython or IronRuby. But to my surprise I found almost nothing. ActiveState has PerlNET, but there's almost no information about it, and the mailing list 'activity' suggests it's dead or dying anyway. So, what are Perl/Windows shops doing now that more and more Microsoft components are .NET? Are people moving to other languages for Windows administration? Are they writing wrappers using COM interop? Or have I completely missed something out there that solves this problem?"

80 of 390 comments (clear)

  1. What? by martinw89 · · Score: 5, Funny

    Perl/Windows shops? WTF?

    That's like buying an extremely overpowered, difficult to setup and impossible to maintain turbo for your Yugo.

    1. Re:What? by Anonymous Coward · · Score: 5, Informative

      Microsoft was shipping Perl interpreters for Windows at least as far back as the Windows NT 4 Resource Kits (like 1998?). There is a long history of Perl on Windows.

    2. Re:What? by stas2k · · Score: 3, Interesting

      Actually, I remember reading somewhere that Microsoft uses build system written in Perl to compile Windows. Ironic, isn't it?

    3. Re:What? by noidentity · · Score: 5, Funny
      Can't believe nobody's said it yet:

      Don't cast perl(s) before swine(dows).

  2. A bit O/T, but by Big+Nothing · · Score: 5, Funny

    I _love_ perl. It's so simple, anyone can use it. In fact, the other day I found my 1½ yYO in front of the computer, and she had written a fully working email reader in perl. Truely amazing.

    --
    SIG: TAKE OFF EVERY 'CAPTAIN'!!
    1. Re:A bit O/T, but by Anonymous Coward · · Score: 5, Funny

      Unfortunately, this being Perl, she had been trying to write a word processor :)

    2. Re:A bit O/T, but by PrinceOfStorms · · Score: 5, Funny

      Not to be competitive or anything, but the email reader my cat wrote in perl this morning included a Bayesian spam filter. Did your child think of including that, huh?

    3. Re:A bit O/T, but by Big+Nothing · · Score: 3, Funny

      To be honest, no. Seriously, though, she's not that smart - I think she was actually trying to write a FPS game.

      --
      SIG: TAKE OFF EVERY 'CAPTAIN'!!
    4. Re:A bit O/T, but by syousef · · Score: 2, Funny

      I _love_ perl. It's so simple, anyone can use it. In fact, the other day I found my 1½ yYO in front of the computer, and she had written a fully working email reader in perl. Truely amazing.

      Smalltalk would have been much more suited to the job.

      --
      These posts express my own personal views, not those of my employer
    5. Re:A bit O/T, but by daeley · · Score: 5, Funny

      I'm pretty sure that qualifies as an UUOC.

      http://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat

      --
      I watched C-beams glitter in the dark near the Tannhauser gate.
    6. Re:A bit O/T, but by ijakings · · Score: 5, Funny

      I wish she'd writtedn DNF, at least wed be out of a long wait.

    7. Re:A bit O/T, but by sqldr · · Score: 2, Funny

      My dad taught me brainfuck :(

      --
      I wrote my first program at the age of six, and I still can't work out how this website works.
    8. Re:A bit O/T, but by jrockway · · Score: 2, Funny

      Perl is the Perfect Emacs Rewriting Language, after all.

      --
      My other car is first.
  3. Don't if this would help but.... by prayag · · Score: 5, Informative

    here goes nothing Programming Perl in Dot Net

    1. Re:Don't if this would help but.... by dvh.tosomja · · Score: 5, Funny

      oh god, At first I read the "Programming Perl in Dot Net" as "Programing in Perl is Not Death"

  4. As the NRA says.... by Anonymous Coward · · Score: 5, Funny

    From my cold, dead hands!

  5. Re:No one made it cause no one cares by Anonymous Coward · · Score: 3, Insightful

    No... people are just moving away from Windows for ANY administration, or anything of real value.

    The figures on this simply don't support that claim. Your anecdotal evidence of two places you worked it meaningless.

    If anything I'd say this is because many people consider Perl's time to have passed and no longer see a reason to use it in any significant project. Perl is a typical example of a jack of all trades, master of none. These days with so many well-designed languages to choose from it's a great deal easier and more productive to learn several languages that each do one paradigm well and use them as applicable instead of trying to get by using just Perl.

  6. Masochism is rife within IT by Colin+Smith · · Score: 5, Funny

    Some people aren't happy until they have the worst of all worlds.

    "Because I can".

     

    --
    Deleted
    1. Re:Masochism is rife within IT by jgrahn · · Score: 2, Insightful

      Some people aren't happy until they have the worst of all worlds.

      Oh, do all the usual Slashdot Perl-bashing moves if you want ... Perl is a big chunk of Unix sanity which you can bring with you to Windows, and use for Unix-y tasks. Same reasons as for installing Cygwin. I often use perl as a normal command-line tool, when grep and awk aren't good enough.

      But I admit that a Perl/Windows shop sounds odd.

  7. Re:No one made it cause no one cares by martinw89 · · Score: 2, Insightful

    I wouldn't say everyone is moving away from Windows, my last job was very Microsoft centered. Windows workstations everywhere, Exchange server, IIS servers, Microsoft SQL, Active Directory, all that bullshit.

    But, I do think anyone using Windows is very unlikely to use Perl; they just seem diametrically opposed. One being used for Unix administration since large systems were in their infancy, and the other one being a the-suits-picked-it decision. At least in my (very biased) opinion.

  8. Perl in decline, at least here by Asmodai · · Score: 4, Insightful

    Based on what I gather in my country the use of Perl is actually in decline, while Python's is growing. Then there's Ruby that's also popular (not sure if it proves to be stable as Python's growth though).

    This does confirm, at least for me, why IronPython and IronRuby happened, but why IronPerl is nowhere in sight. Of course, YMMV in your country, but I think it is a global trend to be honest.

    --
    Jeroen Ruigrok/Asmodai
    1. Re:Perl in decline, at least here by pthisis · · Score: 4, Insightful

      I think it's more that IronPython is basically a vanity/research project, akin to JPython/Jython a few years ago; very few people use it in practice, since the standard Python interpreter runs just fine on Windows and lets you avoid significant compatibility problems (and use all the packages that the rest of the Python world uses, seamlessly).

      These "other language on my interpreter" projects _seem_ really cool, but in practice it's usually simpler and faster (both development and performance wise) to use the languages in their own interpreters and use some IPC/RPC/web services/etc to communicate with .NET (or Java, or whatever) rather than trying to shoehorn your language onto the CLI or JVM.

      --
      rage, rage against the dying of the light
    2. Re:Perl in decline, at least here by Ed+Avis · · Score: 4, Insightful

      The biggest reason is that Python is a fairly small language with a well-defined spec. It already had at least two independent implementations (in C and Java) and between them they had ironed out areas of ambiguity in the language. If you write a Python program you are programming for the defined language and usually not for the quirks of any one implementation.

      Perl 5, on the other hand, is very much defined by its single implementation, full of odd quirks and things that don't really make any sense but have to be kept for compatibility. To implement a fully compatible Perl 5 you would essentially need to reproduce the guts of the existing perl source code, which is why nobody has really bothered.

      --
      -- Ed Avis ed@membled.com
    3. Re:Perl in decline, at least here by ozphx · · Score: 3, Informative

      Yeah Python developers tend to like Boo, which is very Python-inspired.

      The CIL part of the CLI is stack-based, and is more of a "theoretically generic" intermediary language, and works for almost any purpose.

      The CTS (Common Type System) does have some limits (no multiple inheritance except multiple interface inheritance). Your language implementation only has to play nice with the CTS if you want it to interoperate with other languages on the CLI. (Normally you can write an app in a whole bunch of languages and the metadata is exposed to the others - so you might choose to use C# for your core services, C++/CLI for interop work, and something like Python/Boo for your business layer).

      I think the Eiffel implementation ditches the CTS, or extends it. That has its ups and downsides (mainly down imo).

      --
      3laws: No freebies, no backsies, GTFO.
    4. Re:Perl in decline, at least here by johannesg · · Score: 2, Funny

      Based on what I gather in my country the use of Perl is actually in decline, while Python's is growing.

      It should be noted here that Asmodai is in fact a demon, and therefore lives in hell. So keep that in mind before you adjust your strategies based on what languages he is using...

    5. Re:Perl in decline, at least here by RDW · · Score: 2, Funny

      I think they're just being Ironic.

    6. Re:Perl in decline, at least here by LarsWestergren · · Score: 2, Informative

      Oh, and I forgot:

      I think it's more that IronPython is basically a vanity/research project, akin to JPython/Jython a few years ago

      Jython has had a resurgence last year. Sun even hired Ted Leung towork on it full time.
      http://www.sauria.com/blog/2008/03/03/the-sun-is-going-to-shine-on-python/

      --

      Being bitter is drinking poison and hoping someone else will die

    7. Re:Perl in decline, at least here by Coryoth · · Score: 2, Insightful

      Based on what I gather in my country the use of Perl is actually in decline, while Python's is growing. Then there's Ruby that's also popular (not sure if it proves to be stable as Python's growth though).

      Perl has the potential to end up being the next COBOL -- a language with vast amounts of hard to understand code, and few people that can make any sense of it. I think fewer and fewer newcomers are bothering to learn perl. It used to be the case that perl was the do all language: from web scripting, to data processing, to UNIX glue and general purpose scripting. Many different scripting languages have encroached on those different niches now, from PHP at the web end, through Ruby and Python, and even Javascript. Perl is no longer the obvious first port of call. Worse, Perl 6, the behemoth on the perpetual horizon, is threatening to change almost everything but never actually arriving. None of that is to say that perl is bad a choice, just that it is no longer the obvious first choice for beginners to scripting to learn. If the trend continues that's going to leave an awful lot of perl code out there to be maintained, and a limited supply of older geeks who are still fluent enough in perl to do it.

    8. Re:Perl in decline, at least here by ricegf · · Score: 2, Insightful

      Sun supports Jython as well.

      We've embedded Jython into a couple of Java apps to provide end-user scripting capabilities with very good success. End users have been very clever in automating their own work, and even the tool development teams have adopted it for quickly writing report front ends and such.

      We've distributed and evangelized both native Perl and Python. Perl tends to be used when manipulating text files, while Python is most popular when controlling processes, though the correlation is hardly perfect. Either works just fine. I'm confident Ruby / JRuby does, too, it just arrived a little late to our party. :-)

    9. Re:Perl in decline, at least here by wisty · · Score: 3, Informative

      *sigh*, Python is a lot of things, but it is NOT well defined. Maybe Python is OK compared to the other open source source scripting languages like Perl and Ruby. C is a well defined language (except for the bits that are explicitly left undefined), Pascal is really well defined, and Lua is pretty damn good.

      I expect that Perl is left out because a lot of its strengths are in Unix scripting, database libraries, bioinformatics applications and other goodies, which rely on C code and a Unix platform. Ruby Gems and *cough* easy_install just aren't the treasure troves of CPAN, and CPAN can't be easily ported to .net.

    10. Re:Perl in decline, at least here by jhol13 · · Score: 2, Insightful

      Python interpreter runs just fine on Windows

      I've yet to see non-trivial Python program which works in WIndows. Offhand I remember Meld (uses gtk -> won't start) and Mercurial (DNS lookup does not work -> must use IP addresses).

      So the question is: is my very limited sample representative of Python-in-windows or not.

      I'd rather use Groovy, although it does have some problems (isn't stable as has too many incompatibilities with previous revision). Java is unbeatable portability-wise.

    11. Re:Perl in decline, at least here by dedazo · · Score: 2, Informative

      You're right, there's no formal Python specification. However, CPython is for all practical purposes the spec, with a separate stable and successful implementation (Jython).

      Perl on the other hand, has no spec other than Perl5, and no separate independent implementation.

      And quite frankly, saying that Perl5 is the spec is a little bit like saying that the blueprints for that building over there are available only as crayon scribblings scattered in random walls of odd-numbered floors.

      On the other hand, and I say this as a Python proponent, nothing comes close to CPAN. And let's not forget that Perl5 (on *nix at least) is about as stable and proven as you can get with software nowadays.

      --
      Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
    12. Re:Perl in decline, at least here by jonadab · · Score: 3, Interesting

      > Based on what I gather in my country the use of Perl is actually in decline

      Perhaps. But Perl is so widely used, it could decline steadily for forty years and still be more important than C#.

      I think a larger factor is that Perl is not usually given to a strong emphasis on presentation, brand names, buzzwords, and such. Perl is a very *practical* language, grounded in the idea of getting things done, and getting them done quickly, conveniently, and efficiently.

      Some languages would want to run in the .NET environment for ideological reasons ("managed code" blah blah blah) or in order to attract programmers and/or managers who have bought into the whole .NET thing, but for Perl the only real reason to run perl in the .NET environment, as opposed to the normal way of doing things, would be if it provided some concrete practical advantages; I'm not aware of any. I'm not saying .NET wouldn't provide an advantage for *some* languages. C/C++, for instance, were in dire need of some of the things that .NET can provide, not least higher-level variable types that automatically take care of things like reallocating more space when needed. But for Perl, as far as I'm aware, the .NET environment is a solution in search of a problem.

      Also, just because there's no "IronPerl Project" running around enthusiastically talking about the importance of running Perl in a .NET environment doesn't mean there aren't modules on the CPAN for interfacing with .NET code. Perl is, after all, a major glue language, so it's accustomed to interfacing with code that runs in different environments. There are probably at least three different approaches to it, with different strengths and weaknesses for different situation. I don't happen to know what they are, because I've never had any reason to work with .NET, but I if I wanted to know, I sure wouldn't ask on slashdot and sift through thousands of irrelevant posts in hopes of finding the answer. I'd go straight to a (gasp) Perl forum (e.g., Perlmonks) or a Perl mailing list, someplace with an SNR above 1.

      --
      Cut that out, or I will ship you to Norilsk in a box.
  9. Perl6 by Anonymous Coward · · Score: 4, Informative

    A main reason is that Perl 6, which has been in development for nearly as long as .NET, was supposed to be a VM itself. In effect, it was a competitor to .NET.

    Way back when IronPython and IronRuby were starting, Perl 6 looked like it was Nearly Here, so no one thought porting Perl 5 to run on .NET was worth it. Since Perl 6 still hasn't materialized, guess it was a bad choice...

  10. Demographics by sydneyfong · · Score: 4, Insightful

    I guess it's because most of the perl guys were Unix guys?

    At any rate perl doesn't really fit into the .NET "OOP" paradigm. It has objects, but with such flexibility that every time I wanted to create an object in perl I have to look up the bless() function. Most people use it to write small, fast scripts (Activeperl on Windows takes care of that) and there aren't many medium to large scale projects (which .NET arguably does well) that use perl.

    --
    Don't quote me on this.
    1. Re:Demographics by Anonymous Coward · · Score: 5, Insightful

      Why does everyone keep repeating this? Just because you don't do it doesn't mean nobody does. There are tons of large projects in perl. You're using one right now.

    2. Re:Demographics by EraserMouseMan · · Score: 2, Insightful

      Large user base does not equate to a large project. We all love Slashdot, but Slashdot doesn't qualify as a large mission critical system.

  11. Windows Administration language by bob8766 · · Score: 5, Insightful

    I suspect people are moving to Powershell, since it's a good shell scripting language, and it's easy to load .NET assemblies among other things. I was able to learn enough powershell to do some rather useful things in a few days, and that's without having a strong shell scripting background.

  12. Search harder by aauu · · Score: 4, Informative
    http://www.activestate.com/Products/perl_dev_kit/feature_list.mhtml is the Perl Dev Kit. This will do what you want with .net. Not free, but if you want truly free, then contribute your own module.

    Perl is an antique language. You should look at a modern scripting language. Powershell is much more powerful as it pipes .net objects instead of text.

    --
    When I was young, I had to rub sticks together to compute.
  13. Try asking "PerlMonks" by ggvaidya · · Score: 4, Informative

    PerlMonks is the right place to ask this question, IMO. You'll be posing the question to a lot of very experienced Perl users who might have similar experiences to yours, or good advice on what to do next. The PM community is friendly and very helpful as well.

  14. Don't fight it - Perl is here to stay! by cynicsreport · · Score: 4, Insightful

    I know... Python and Ruby and Java are the hot languages, and you think Perl is going the way of COBOL. Well f*ck it - I like perl. And, there are some great reasons to use it:
    1. I already know it. I learned it before Ruby was "cool".
    2. It's already installed on every Linux and BSD machine. Yes, that means I can run my script on your brand new Ubuntu desktop, or your 1998 BSD server. And it'll work.
    3. Great Regex support (am not saying your language de-jour doesn't, just that perl does)
    4. CPAN is one of the most extensive software libraries known to mankind.
    5. It really doesn't matter if you use it or not - perl is here for the long haul. Too many linux utilities depend on it. My linux box doesn't have ruby or python installed, and I haven't had any problems. Try deleting perl from yours!

    So, if you are like me, you already know Perl. Maybe you don't use windows at home, but you have to use it at work. I suggest you download Strawberry Perl (or go all-out with cygwin).
    Unfortunately, there does not seem to be great support for perl with .NET. So, I guess we have to stick with the Win32 CPAN modules you already know about.
    But maybe, just maybe, someone will come along one day... and viola! Perl.NET!

    Until that day comes, I will continue to use perl anyway, and all of you Haters out there can go $@_{s/;//g}!

    --
    - Demosthenes
    cynicsreport.com
    1. Re:Don't fight it - Perl is here to stay! by neuromanc3r · · Score: 5, Interesting

      My linux box doesn't have ruby or python installed, and I haven't had any problems. Try deleting perl from yours!

      What distribution are you running? Every distribution I've used had Python installed by default for years (and would break terribly if you tried to remove it).

    2. Re:Don't fight it - Perl is here to stay! by MostAwesomeDude · · Score: 3, Insightful

      Unfortunately, bare-bones Debian lacks Python, although hopefully recent popularity-contest results will make it more likely to be part of a default install.

      --
      ~ C.
    3. Re:Don't fight it - Perl is here to stay! by Catharsis · · Score: 5, Insightful

      So your arguments for why Perl is great to use are:

      1) I know it.
      2) I have it.
      3) (irrelevant)
      4) YAY CPAN
      5) Not a reason to use it?

      So, uh, yeah, CPAN is awesome, but "I know it and it's installed." aren't really strong advocacy arguments.

      No offense, but this isn't exactly Insightful, particularly given that (aside from good old CPAN) there's really nothing in there that isn't true for Python on almost all systems people will encounter these days.

      --

      "The wise man proportions his belief to the evidence." -- David Hume

    4. Re:Don't fight it - Perl is here to stay! by RegularFry · · Score: 4, Interesting

      Oh and lets not forget how "cool" it'd be if the runtime of every pet scripting language was embedded directly in common web browsers. Yes Cletus, that sure would be 'great'!

      My word. You've just described Silverlight.

      --
      Reality is the ultimate Rorschach.
    5. Re:Don't fight it - Perl is here to stay! by Lumpy · · Score: 2, Funny

      Yes and no. the biggest problem with perl is that many large apps require 90,000 obscure modules to be installed. Perl should have a automatic CPAN downloader that allows you to run your app and it goes and graps all those obscure modules and installs them instead of forcing me to sit there for 20 minutes typing....

      perl -mCPAN -e

      i foobar
      i buttmunch
      i nosescraper

      DAMMIT

      i noseScraper ...

      This could easily be done, as well as the dev's of the app could write a nice installer that does that as well. but it's a big put-off. I used to cringe when installing a webapp on redhat systems that the module was not available in the redhat repositories, install from Cpan a module and find it updates a redhat perl module that breaks something else....

      --
      Do not look at laser with remaining good eye.
    6. Re:Don't fight it - Perl is here to stay! by adamkennedy · · Score: 2, Informative

      So what you do is write yourself a Makefile.PL that lists all the dependencies, just like those fancy CPAN modules.

      Then you run this...

      > cpan .

      And the CPAN client will just treat your applications dependencies like a CPAN distribution and run off and install all the dependencies for it in one go.

    7. Re:Don't fight it - Perl is here to stay! by sqldr · · Score: 2, Insightful

      If it was worth writing a new build tool, it was worth writing it in C

      Why would you write something which is basically a glorified file processor in C? C wouldn't exactly be my first choice for something which spends most of its time pattern matching and goal-hunting, and it's hardly 'make' using up the cpu during a massive build. That would be ld thrashing the disks.

      Make has pretty ugly syntax, and if your editor isn't set up right, you'd better watch out for those trailing tabs/spaces. I stopped writing makefiles by hand a long time ago. So what next? autoconf? Any language which uses 'dnl' as a comment specifier then tries to auto-generate 5000 line long shell scripts is something I tend to run screaming from

      I tend to use scons and qmake these days, because both have really easy and versatile syntax, which means I get to spend more time coding and less time trying to figure out how to get the thing to build. I played with cmake for a while as well. It depends on the project I'm working on, but either way I don't spend my life trying to use the same hammer to crack every nut.

      --
      I wrote my first program at the age of six, and I still can't work out how this website works.
    8. Re:Don't fight it - Perl is here to stay! by marcosdumay · · Score: 2, Interesting

      As far as I know, popularity-contest doesn't say what goes on bare-bones, you'd need an essential piece of software that depends on Python for including it there. Popularity-contest says what goes on each CD, and I think Python is already at the first one.

      Also, really, why do you want to include Python at bare-bones? If you like cluter, use the Desktop install.

    9. Re:Don't fight it - Perl is here to stay! by Abcd1234 · · Score: 2, Insightful

      Well, until I see proof otherwise, I see no reason why the percentage of crapware on CPAN is any different than the percentage of crapware on PyPi. And heck, even if 50% of CPAN was crapware and the entirety of PyPi was pure gold, CPAN would *still* win out in terms of number of quality packages available.

      All that said, you are right, much of it comes down to, is what I need there? Problem is, that answer depends based on the problem domain. And I'm willing to bet that, based purely on the sheer number of packages available in CPAN, it's more likely to cover obscure topics, in addition to the more popular subjects that both CPAN and PyPi are likely to cover adequately.

    10. Re:Don't fight it - Perl is here to stay! by skeeto · · Score: 2, Interesting

      As a Debian user who always starts from the bare bones install and apt-gets my way to ideal, I agree with you that the base install shouldn't include Python. The base install is an example of something we want to be tight and small.

      However, not everything worth writing should be written in C.

      In general, writing C is expensive, compared to interpreted languages. More bugs need to be ironed out. There are portability issues, so moving to each new architecture or platform takes more and more effort. The program is longer and more complicated. And, worst of all, you are repeating a lot of work other people have already done. In the end, your C program is going to be tighter and faster than the interpreted one, but at what cost? And what have you gained? The user will not be able to notice the difference between 10ms and 100ms run times. Most desktop software spends almost all of its time waiting on I/O (this includes user input), and there is pretty much nothing that can be done (software-wise) to make I/O faster. Meatspace is too slow.

      The interpreted version is usually fast enough and it's easier to write and maintain. To use your example, writing a build system in C is premature optimization, and the general rule for that is Don't Do It. Programs have bottlenecks, which cannot be found until you are done. If you really need speed, use a good profiler to find those bottlenecks and make them faster, which, in the case of interpreted languages, you then write those small parts in C using whatever C interface is provided.

      To quote Paul Graham,

      Everyone knows it's a mistake to write your whole program by hand in machine language. What's less often understood is that there is a more general principle here: that if you have a choice of several languages, it is, all other things being equal, a mistake to program in anything but the most powerful one.

      Write in C and assembly when you really need the raw power, such as when you are writing some kind of data compressor or high-precision scientific simulation. For everything else, use a more powerful, higher level language -- especially when doing lots of text processing. You will be done faster and with fewer bugs and security holes.

      The reason we have so many interpreters is because no one can agree on which language is the most powerful.

    11. Re:Don't fight it - Perl is here to stay! by MoxFulder · · Score: 2, Insightful

      1. I already know it. I learned it before Ruby was "cool".

      The biggest problem with this argument is... Python is incredibly easy for a Perl programmer to learn. I mean, ridiculously so. All the reasonable Perlisms (hashes, lists, foreach, etc.) translate directly, and all the unreasonable ones (*cough* objects *cough*) are just simpler in Python.

      I decided to learn Python one day and had basically rewritten (and improved) all of my lab automation scripts in it about 10-20 hours of work later.

      2. It's already installed on every Linux and BSD machine. Yes, that means I can run my script on your brand new Ubuntu desktop, or your 1998 BSD server. And it'll work.

      Erm... Python has been installed on every Linux/BSD box I've seen in the last 5 years, because a lot of system utilities depend on it. Perl has changed a lot since 1998 too... I wouldn't count on a lot of today's scripts working with Perl 5.1.

      3. Great Regex support (am not saying your language de-jour doesn't, just that perl does)

      Indeed. When you need regexes, Perl's are undoubtedly the best. Which is why Python copies Perl's regex syntax exactly... including all the new-fangled ?: ?! ?^ stuff. Just learn the Python functions to invoke regexes, and you're done.

      4. CPAN is one of the most extensive software libraries known to mankind.

      Unfortunately, it's also wildly varying in quality, and there are sometimes 5-10 different modules that sorta-kinda do the same thing and none of them gets everything right. And they might be coded in such different styles as to be nearly impossible to combine.

      ... all of you Haters out there can go $@_{s/;//g}!

      See, the fact that that might be a valid Perl program is part of why I prefer Python :-P

  15. Re:Perl6 is the problem by Anonymous Coward · · Score: 5, Interesting

    Unfortunately, (as perl fan), Perl6 is the problem. All the bright young things went into the death march that is Perl6 and CPAN stopped getting useful additions. Two burnout cycles later, we still don't have Perl6. Or modern, complete XML/Xpath support. Or a DBI::CSV which can do joins. Or any other number of actually useful code bits.

    I'm now tossing up whether to learn Ruby or Python.

  16. What color are the power LEDs on those servers? by Anonymous Coward · · Score: 5, Funny

    and before you start ranting about windows is a poor web platform http://uptime.netcraft.com/up/today/top.avg.html.

    Your theory appears to be that Windows is a good web platform, because on netcraft, 2 out of the top 50 sites by uptime are running Windows. Wouldn't the goodness of a web platform depend on a whole bunch of things, only one of which would be uptime? And uptime would be less important than things like availability and ease of installing software. And most importantly, whether the machine has a blue or green LED for the power light. Obviously machines with blue power LEDs suck, but machines with green LEDs rock! And Windows web servers always have blue LEDs for power lights! Windows sucks and always will. They don't even know how to write drivers for green LEDs.

  17. So don't change. by gbjbaanb · · Score: 4, Insightful

    Why would you want to rewrite to use .NET, I mean c'mon Perl programmers are known for their objectivity and pragmatism. Rewrite in .NET before you *have* to, forget it!

    There's 2 things to consider before you go changing your code:

    1. COM may be 'oh, that old thing we no longer talk about' to Microsoft, but it isn't going away anytime soon, no matter what their marketing department tells you. There's a fair bit of code written that uses it.

    2. One of those codebases that is heavily reliant on COM (and Win32) is this .NET thing, a lot of the class library is a wrapper around the old libraries. So even if you did rewrite your code, all you'd be doing is calling your old libraries through a intermediate layer!

    Sure MS doesn't want to do IronPerl, I think that's because python and Ruby are 'cool' languages, and MS is trying to be like someone's Dad, 'getting hip with the kids'. I doubt it'll ever create an IronPerl simply because there's no mileage in it for them to entice the Perl developers over to Windows unlike the Python and Ruby folks that they're scared of losing to other platforms.

  18. apparently by speedtux · · Score: 3, Insightful

    Well, apparently, nobody in the Perl community cared enough about it to create it. Do you care enough to start such a project.

    I suspect most people probably thought it was easier to switch to a different language that did support the environment they needed. I know I did.

  19. Re:No one made it cause no one cares by LodCrappo · · Score: 5, Informative

    The figures on this simply don't support that claim. Your anecdotal evidence of two places you worked it meaningless.

    If anything I'd say this is because many people consider Perl's time to have passed and no longer see a reason to use it in any significant project.

    Funny.. I'd like to see the figures behind your claims that "many people consider Perl's time to have passed".

    A quote from CIO.com story entitled "PHP, JavaScript, Ruby, Perl, Python, and Tcl Today: The State of the Scripting Universe" (8/29/08)

    "Of all the scripting languages, Perl offers the biggest installed base of applications, of code, of integrated systems, of skilled programmers. It has the lowest defect rate of any open-source software product. It is ported to essentially every hardware architecture and operating systems, from embedded control systems to mainframes. It is optimized for speed, for memory footprint, for programmer productivity. It has readily-accessible libraries for all types of programming tasks: Web application development, systems and network integration and management, end-user application development, middleware programming, REST and service-oriented architecture programming. Perl is ideal for the organization that takes charge of its own IT future."

    Other interesting stats and info throughout the story..

    full article

    --
    -Lod
  20. Been in similar shoes by ThePhilips · · Score: 4, Interesting

    I have been in similar shoes some time ago.

    I wouldn't elaborate on the all boring details, but just shortly summarize my experience.

    If you can Perl, then you better off porting your stuff to Linux. Perl on Windows sounds cool and ActiveState does excellent job. But Perl would always remain underdog, restrained by the fact that its foreign platform - platform where VB rules.

    I know I sound impractical, but after two years trying to make some stuff fly reliably on Windows with CygWin and ActiveState, I simply given up. I given up on Windows mostly because I found that all stuff I need, on Linux is very similar and (most importantly) there are no all those stupid CygWin and OLE/ActiveX annoyances and periodic breakages. For my application, near doubled performances was only an extra bonus.

    If you plan to remain on Windows, you have to accept and start doing it in VB or C# or whatever is language du jour in Redmond.

    If you depend on Perl, then thinking in direction of *nix platform is sound choice. (Or even some VMware or VBox setup with Linux guest.)

    P.S. My work was related to processing of .xls files with huge amount of statistical data and making some charts for them. On Linux that was solved beautifully with (1) telling people to export info as CSV (extra bonus: smaller files) and (2) gnuplot output charts to PDF. Frankly, in the end it worked magnitudes better than the setup with ActiveState Perl/Excel/WinWord/etc on Windows.

    --
    All hope abandon ye who enter here.
    1. Re:Been in similar shoes by adamkennedy · · Score: 4, Informative

      You probably should have had a look at Strawberry Perl.

      Most of the Perl technocrati abandoned ActivePerl for it over the last year, because all the CPAN modules Just Work.

      (Full Disclosure: I made Strawberry) :)

    2. Re:Been in similar shoes by ThePhilips · · Score: 2, Interesting

      Thanks for the info!

      A 100% Open Source CPAN-capable Perl for all your Windows® computers that works exactly the same as Perl everywhere else.

      Does that mean it also has fork()?

      But honestly, to me properly functioning select() (with both pipes and sockets) is already more than enough.
      Though admittedly I do not have plans to go back to Windows.

      --
      All hope abandon ye who enter here.
  21. perl missed several boats, sadly by orabidoo · · Score: 5, Insightful

    Opinionated post follows, feel free to ignore or disagree....

    Perl is the original language that taught a whole generation of programmers that you don't have to write 1000s of lines to do a simple thing. I love its expressiveness, its design philosophy (There's More Than One Way To Do It) and its linguistic roots. Despite being known for write-only shit, actually writing clean, maintainable code in perl is a pure pleasure. It just gives you the extra bit of latitude in your coding, that what you write can express not just what you want done, but a little extra bit of how you think of it... by using "unless" instead of "if" at times, putting the conditionals after the statement at others, you can actually make the code read like the main points are main points, adn the accessory checks are accessory. I love that flexibility.

    For years, perl was the secret productivity tool of many. What others would spend weeks writing in C++ or java whatever, a perl coder would prototype in a day or two, and often the result was good enough to be declared final. And with the amazing collaboration experiment called CPAN, there was a good chance you would find a module to do the heavly lifting for you, and the two days could be shortened to a couple hours.

    Sadly, the perl development community missed not one, but two boats.

    First, it missed the second wave of web programming. Perl was virtually synonymous with CGI programming, but then the web world moved on to embedding code inside the HTML, which is a rather crappy combination but is easy to start with. So the perl guys produce mod_perl and about a thousand templating kits, which all together made mod_perl a powerful, scalable, flexible web platform that was at the same time confusing, hard to learn, and unfriendly towards shared hosts. And then PHP came to fulfil that need, with their bastardized watered down clone of the language, and basically stole the show.

    Second, the perl community in all their wisdom, back in 2000, decided that the whole language needed to be redesigned from scratch, and built on a new generic virtual machine for dynamic languages, which would run not only perl6 but also python, tcl, logo, and who knows what else. They embarked on a prolonged process of design by committee, which 8 years later has just managed to produce a variety of incomplete specifications, and two incomplete prototypes of the language interpreter, with no completion date nor any backwards compatibility to be seen. In the meantime, the whole .NET framework has been created and gone through several iterations, Ruby has risen from obscurity to fame, etc. For all we know, perl6 may still one day reach completion, and be a useful language. The design specs are way cool, and the people implementing it sound like they are having fun.

    So what happens with perl and .NET? Well, not much. Apparently ActiveState have at some point developped a bridge of some kind, but I can't find it in CPAN. There's Inline::Java, but no Inline::CSharp. Maybe no-one cares enough. It's true that the target demographics for perl and .NET are quite separate, but that should not be a reason for the language that pioneered interfacing with everything on earth.

    1. Re:perl missed several boats, sadly by chromatic · · Score: 2, Insightful

      I hope you meant "functional" meaning "it works" rather than that it exemplifies functional programming ideas, because it doesn't do anything close to the latter.

      Why not? It has lambdas, dynamic scoping, lexical scoping, and closures. It lacks homoiconicity, but so do OCaml and ML and Haskell. It doesn't forbid mutable global state, but neither does CL, and a lot of people believe that CL supports functional programming fairly well.

    2. Re:perl missed several boats, sadly by bcrowell · · Score: 2, Informative

      Perl was virtually synonymous with CGI programming, but then the web world moved on to embedding code inside the HTML

      There have always been some things that you needed to do on the server side (e.g., validate the user's password), and some that were better done on the client side (e.g., warn the user *before* he hits the submit button that his social security number only has 8 digits). That hasn't changed. The only thing that's changed is that more people are doing ajax. An ajax app still needs to have some things happen on the server side, and perl is still a perfectly reasonable language for that.

      but then the web world moved on to embedding code inside the HTML, which is a rather crappy combination but is easy to start with.

      It doesn't need to be crappy. JavaScript is a very nice programming language, with good support for functional programming, and a lean, simple way of supporting OOP. You also don't need to embed your javascript directly in the HTML. I don't have any experience with php, but anyway I don't see what any of this has to do with perl, which is the language you'd be using on the server, not the client.

      So the perl guys produce mod_perl and about a thousand templating kits,

      Mod_perl is totally irrelevant here; either use it (if you need the performance boost) or don't (if you don't). As far as templating kits, if you don't like that kind of thing, don't use it. Generating HTML with perl code isn't exactly rocket science. The horrible mess with frameworks is more of an issue with ajax, which is rocket science to get working well, across browsers.

      which 8 years later has just managed to produce a variety of incomplete specifications, and two incomplete prototypes of the language interpreter, with no completion date

      So what? Why should it bother me as a perl coder if perl 6 is a long time coming? Perl 5 is a great language.

      nor any backwards compatibility

      Here you're just misinformed. Perl 6 has always been planned to be 100% backward-compatible with perl 5. I don't know if the current non-release implementations have perl 5 compatibility yet, but they will by the time they're ready for release.

      If perl is losing any mindshare (and is it? -- I haven't seen any data to demonstrate that), I don't think any of your reasons hold water. What might be more of an issue is that we've been going through a fad for OOP, but Perl 5's support for OOP is ugly.

    3. Re:perl missed several boats, sadly by orabidoo · · Score: 2, Informative

      yep, you have several good points there.

      maybe I wasn't sufficiently clear, but what I meant by "embedding the code in the html" was not a reference to Javascript, but to PHP and ASP type of programming.

      my point is that PHP could only have happened through a major blunder of the perl community, since it is basically a bland clone of perl. I don't see the languages themselves being different enough to make a difference, so I tend to think that the main reason why PHP took off is that it has a dead easy programming model ("change your files extension to .php and embed your <?php php code ?> in there"), and is friendly towards shared hosts, by basically resetting the interpreter between requests and having "safe_mode". The point is that all these things are possible to do with perl, but no-one at the time bothered to produce a package that did them and was simple to install, or if anyone did, they didn't make enough noise. So php came and filled the gap for the wider world, while the perl people smugly replied "we can do that too, and about 10,000 other things".

      so yep, I know you can use mod_perl for the performance, and templating kits if you like them, and that CGI is still available. I regularly use all of these :)

      besides, as a perl programmer, it bothers me if the perl community shoots itself in the foot, because I enjoy perl programming for the web, and that market looks to me like it's dwindling.

  22. Re:Python is available by Hognoxious · · Score: 4, Insightful

    Most businesses (which is what MS is catering to) care about structured code that can be maintained, not just stuff you banged out to get the job done.

    The hell they do.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  23. Re:No one made it cause no one cares by Hognoxious · · Score: 4, Insightful

    These days with so many well-designed languages to choose from it's a great deal easier and more productive to learn several languages that each do one paradigm well

    and then join them all together ... using perl.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  24. COM deprecated ?? by savuporo · · Score: 2, Interesting

    Dude, in which world is COM deprecated ? Effectively most of Windows system programming ( plug-ins, filters, extensions yada yada, especially the parts that concern shell, explorer or IE extensions ) are all exposed through COM intefacts still. In some cases we still have simple C interfaces like for device drivers, and a lot of security or crypto related stuff. So WDYM deprecated ?

    --
    http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
  25. That's simply not possible as is. by wazoox · · Score: 5, Insightful

    Actually the problem is that "only Perl (the executable) can parse Perl (the language)". There isn't any formal description of the current language implementation, that effectively renders near to impossible to parse and execute Perl code outside of the perl binary; some edge cases of the syntax particularly are only determined at runtime (instead of compile time).
    Perl 6 is among other things an answer to this limitation, because it's thoroughly spec'd in the "synopses", and is actually currently implemented in two different ways (Parrot VM written in C, and Pugs written in Haskell). So it's perfectly possible to make IronPerl6, but no IronPerl.

    1. Re:That's simply not possible as is. by wazoox · · Score: 2, Interesting

      Perl gives you more than enough rope to hang yourself, that's why you can often see appaling perl code. But the power of perl may also be a boon ; "use strict; use warnings;" , Perl::Tidy, Devel::Refactor, can help you tremendously to refactor bad code.

  26. Re:No one made it cause no one cares by ggvaidya · · Score: 5, Informative

    To be fair, that quote is by Richard Dice, the president of the Perl Foundation, so he might be a little biased. :-)

    On the other hand, Perl still gets many more job postings on dice.com than any other interpreted language, including PHP: http://www.presicient.com/langjobs.html

  27. Re:No one made it cause no one cares by Lumpy · · Score: 3, Funny

    And the best part....

    Almost all MCSE holders are afraid of it so they cant hire low wage cert's to maintain and change it.

    I love perl in the windows world it allows us with skills to have yet another noose around the neck of management.

    VB.NET was our first noose for management. I was so glad when Microsoft made VB hard. Almost all the part time VB programmers in the office instantly were ineffective as they could not wrap their heads around OO programming.

    Problem is, there are still millions of VB6 applications in use today in corporations all over america... and one day micrsoft will do something to break every one of them.

    That makes me smile.

    --
    Do not look at laser with remaining good eye.
  28. Re:Perl6 is the problem by ricegf · · Score: 4, Interesting

    As a former heavy user of Perl (and now a light user), let me encourage you that you're unlikely to go wrong either way. Both are popular, well-supported dynamic languages with bright futures.

    Python is less Perlish than Ruby in syntax, but in the end I found that rather charming and made it my "new" dynamic language. I have no regrets.

    Besides, if I want to shred and rebuild a text file in 40 characters of line noise (please understand that I mean that fondly - I like Perl's conciseness), then I've still got Perl 5. Python does many other things well, so I consider them both useful tools to know.

    So quit tossing up (ahem), pick one, and get on with it! :-)

  29. Re:No one made it cause no one cares by pdbaby · · Score: 2, Insightful

    Perl is a typical example of a jack of all trades, master of none

    The full quote being:

    "Jack of all trades, master of none, though ofttimes better than master of one." ref

    Although I get what you mean. The trouble is that the thing I love about Perl - its expressiveness - is also its biggest weakness. In the hands of an inexperienced programmer Perl can be a nightmare. But in the hands of a master, a Perl solution to a problem can be brief and beautiful

    --
    Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
  30. The Perl investment by Dystopian+Rebel · · Score: 2, Interesting

    I'm still using most of the Perl applications -- on *three different OSs* -- that I wrote before .NET existed, and I expect I'll be using them (on at least three different OSs) long after .NET has been replaced by Monoposoft's next attempt at World Domination[TM].

    --
    Rich And Stupid is not so bad as Working For Rich And Stupid.
  31. Not surprising by jlarocco · · Score: 2, Interesting

    First, as other people have mentioned, Perl use is declining. I love Perl, but it's just not as popular as it used to be.

    Second, Perl has always been more popular on, and worked better with, UNIX. That's even more true now that fewer people are using it. Ask 100 Perl developers whether they prefer UNIX or Windows, and 99 of them will say UNIX. So it's not too surprising there's no Windows only rewrite of it.

    As for Perl/Windows shops, do they even exist? Seems to me that if there were enough pressure to heavily use Perl, there'd be enough pressure to use something other than Windows.

  32. join them all together ... using perl by NotQuiteReal · · Score: 4, Funny

    ...and in the darkness bind them

    There, I fixed that for you.

    --
    This issue is a bit more complicated than you think.
  33. Re:Python is available by mr_mischief · · Score: 2, Insightful

    You've never had a development schedule written by a business person, have you?

  34. IronPerl. by miguel · · Score: 2, Interesting

    The Iron* family of languages are re-implementations from scratch of a language to run on top of .NET. This approach requires a large time investment to get it working as reimplementing a language and then tuning it to run fast is not a weekend hack.

    There is another option, to build bridges from a language to .NET. This is possible because .NET can be used as a library, Perl can host .NET and then create objects and send messages to objects living in the .NET world.

    For a language in continuous evolution like Perl, following the Iron* route is more difficult, and the second approach might be better.

    I believe there used to be a set of .NET bindings for Perl.

  35. Re:Python is available by shaka999 · · Score: 3, Informative

    No, a Perl lover will jump in and say Perl is FAST to write. Its so easy to do so many things. I'm not talking large systems here, I'm talking things you need to do day to day.

    I've yet to find another language where I can process a text file 100 different ways with just a few lines. I really don't give a damn if anyone else can read or maintain my short scripts. There for me.

    --
    One should not theorize before one has data. -Sherlock Holmes-
  36. Re:Python is available by synthespian · · Score: 2, Interesting

    Just please don't make the argument Python is inherently more readable.

    It's not

    http://algebraicthunk.net/~dburrows/blog/entry/attachments/debsudoku.py

    http://www.blott-online.com/sudoku/sudoku-solver

    --
    Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts