Forgot your password?
typodupeerror
Perl Windows

Where's the "IronPerl" Project? 390

Posted by kdawson
from the more-than-one-way dept.
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?"
This discussion has been archived. No new comments can be posted.

Where's the "IronPerl" Project?

Comments Filter:
  • What? (Score:5, Funny)

    by martinw89 (1229324) on Wednesday October 08, 2008 @03:10AM (#25296643)

    Perl/Windows shops? WTF?

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

  • by Big Nothing (229456) <big.nothing@bigger.com> on Wednesday October 08, 2008 @03:11AM (#25296649)

    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.

  • by prayag (1252246) <prayag...narula@@@gmail...com> on Wednesday October 08, 2008 @03:16AM (#25296681)
    here goes nothing Programming Perl in Dot Net [amazon.com]
  • by Asmodai (13932) on Wednesday October 08, 2008 @03:38AM (#25296781) Homepage

    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.

    • by pthisis (27352) on Wednesday October 08, 2008 @03:51AM (#25296835) Homepage Journal

      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.

      • by ozphx (1061292) on Wednesday October 08, 2008 @04:27AM (#25296987) Homepage

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

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

        In some cases JRuby is faster than the standard Ruby implementation. You also get access to all the services, tools, and existing libs of the JVM. It may al

      • Re: (Score:3, Informative)

        by LarsWestergren (9033)

        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/ [sauria.com]

      • Re: (Score:3, Insightful)

        by jhol13 (1087781)

        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.

    • by Ed Avis (5917) <ed@membled.com> on Wednesday October 08, 2008 @04:17AM (#25296947) Homepage

      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.

      • by wisty (1335733) on Wednesday October 08, 2008 @08:47AM (#25298229)

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

    • by init100 (915886)

      This does confirm, at least for me, why IronPython and IronRuby happened, but why IronPerl is nowhere in sight.

      What is it with the Iron prefix and .NET-connected language implementations?

    • Re: (Score:3, Funny)

      by johannesg (664142)

      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 [wikipedia.org] 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...

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

      It's not just Microsoft's Iron* stuff. Did you notice that there's also Jython and JRuby - the latter being a Sun project, not sure about the former - but no "JPerl"?

      • Re: (Score:3, Insightful)

        by ricegf (1059658)

        Sun supports Jython as well [slashdot.org].

        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 hard

    • Re: (Score:3, Insightful)

      by Coryoth (254751)

      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 Javasc

    • by hey! (33014)

      Perl was not conceived as a systems programming language. It was conceived as a language in which a number of very common problems were very convenient to solve. As such, it probably overshot its natural niche, but that's a good thing within limits, because problems are often NOT neatly contained in some kind of application niche.

      For example there are a number of nice GIS libraries in Perl. You wouldn't write a full fledged GIS application in Perl, but say you have a simple but successful web site, th

    • Re: (Score:3, Interesting)

      by jonadab (583620)
      > 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 .N
  • by Chrisq (894406)

    Where's the "IronPerl" Project?

    I don't know, but have you tried asking Captain Jack Sparrow?

  • Perl6 (Score:4, Informative)

    by Anonymous Coward on Wednesday October 08, 2008 @03:54AM (#25296845)

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

  • Demographics (Score:5, Insightful)

    by sydneyfong (410107) on Wednesday October 08, 2008 @03:59AM (#25296863) Homepage Journal

    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.

    • Re:Demographics (Score:5, Insightful)

      by Anonymous Coward on Wednesday October 08, 2008 @04:53AM (#25297093)

      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.

      • Re: (Score:3, 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.
  • by bob8766 (1075053) on Wednesday October 08, 2008 @04:04AM (#25296877)
    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.
  • Search harder (Score:5, Informative)

    by aauu (46157) on Wednesday October 08, 2008 @04:15AM (#25296933) Homepage
    http://www.activestate.com/Products/perl_dev_kit/feature_list.mhtml [activestate.com] 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.

  • by ggvaidya (747058) on Wednesday October 08, 2008 @04:16AM (#25296937) Homepage Journal

    PerlMonks [perlmonks.org] 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.

  • When .NET 1.0 was released, ActiveState released Visual Perl [activestate.com], the product is dead since 2005, so probably nobody wanted it.

  • by cynicsreport (1125235) on Wednesday October 08, 2008 @04:43AM (#25297039) Homepage
    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 [strawberryperl.com] (or go all-out with cygwin [cygwin.com]).
    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}!
    • by neuromanc3r (1119631) on Wednesday October 08, 2008 @05:17AM (#25297193)

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

      • by MostAwesomeDude (980382) on Wednesday October 08, 2008 @05:29AM (#25297253) Homepage

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

        • Re: (Score:3, Interesting)

          by marcosdumay (620877)

          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.

    • by Catharsis (246331) on Wednesday October 08, 2008 @05:59AM (#25297383) Homepage

      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.

    • by Zadaz (950521)

      Fine.

      So how does this little rant answer the question?

    • by renoX (11677)

      >And, there are some great reasons to use it:
      >1. I already know it. I learned it before Ruby was "cool".

      I know Perl also, and for me that's a reason *not to* use Perl.
      The more I used Perl, the more convinced I was that this is a poor language because
      a) beginners create unmaintainable code, but that's not the big issue here as it's the same in any language.
      b) experienced programmers create unmaintainable code(!) as the TMTOWTDI philosophy of Perl is directly opposed to maintainability..

      I haven't had th

    • Re: (Score:3, Funny)

      by Lumpy (12016)

      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

      • Re: (Score:3, Informative)

        by adamkennedy (121032)

        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.

    • Cobol is here to stay too. Look at all the vast piles of code written for the medical & insurance companies.

      Therefore your next project should be written in Cobol. Because it isn't going anywhere. . .
    • Re: (Score:3, Insightful)

      by MoxFulder (159829)

      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

  • So don't change. (Score:5, Insightful)

    by gbjbaanb (229885) on Wednesday October 08, 2008 @05:07AM (#25297137)

    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.

  • apparently (Score:4, Insightful)

    by speedtux (1307149) on Wednesday October 08, 2008 @05:48AM (#25297337)

    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.

  • by ThePhilips (752041) on Wednesday October 08, 2008 @06:02AM (#25297391) Homepage Journal

    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.

  • by orabidoo (9806) on Wednesday October 08, 2008 @06:11AM (#25297425) Homepage

    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.

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

    • Re: (Score:3, Informative)

      by bcrowell (177657)

      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 so

      • Re: (Score:3, Informative)

        by orabidoo (9806)

        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 p

  • COM deprecated ?? (Score:3, Interesting)

    by savuporo (658486) on Wednesday October 08, 2008 @07:03AM (#25297649)
    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 ?
  • by wazoox (1129681) on Wednesday October 08, 2008 @07:23AM (#25297753) Homepage
    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.
  • I believe the short answer is: ASP/ASP.NET. Perl was **the** language to use for CGI. Perl is powerful and flexible but getting stuff to work right can be a pain, especially on Win32 systems. My first Perl interrupter on Windows was a CLI interface that my server had to make shell calls to. Since NT changed to 2000 and started shipping with IIS most developer have just switched to ASP or PHP.

    For a while some languages like Cold Fusion, Miva (formally HTMLScript) and JSP were very popular on Windows. Bu

  • Not surprising (Score:3, Interesting)

    by jlarocco (851450) on Wednesday October 08, 2008 @09:33AM (#25298653) Homepage

    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.

  • IronPerl. (Score:3, Interesting)

    by miguel (7116) on Wednesday October 08, 2008 @10:38AM (#25299557) Homepage

    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.

Passwords are implemented as a result of insecurity.

Working...