Where's the "IronPerl" Project? 390
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?"
Re:No one made it cause no one cares (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.
Re:No one made it cause no one cares (Score:3, 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.
Perl in decline, at least here (Score:5, 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.
Re:Python is available (Score:1, Insightful)
It turns out that code written is Perl is actually unmaintainable garbage. Sure, it works. But it really is a write-only language. 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.
Now a Perl lover will jump in and say that you can write Perl so that it's maintainable, and you can write Python or Ruby so that it's unreadable. It's true, but both are hard to do. Businesses are looking to idiot-proof as much as possible, since most of their developers are probably idiots. Hence the love for VB and Java. I can't imagine anyone commissioning a software project to seriously consider Perl, especially on windows.
Re:Perl in decline, at least here (Score:5, 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.
Demographics (Score:5, 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.
Windows Administration language (Score:5, Insightful)
Re:Perl in decline, at least here (Score:5, 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.
Don't fight it - Perl is here to stay! (Score:4, Insightful)
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
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}!
Re:Demographics (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.
So don't change. (Score:5, 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.
Re:Don't fight it - Perl is here to stay! (Score:4, 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.
apparently (Score:4, 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.
Re:Don't fight it - Perl is here to stay! (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.
perl missed several boats, sadly (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.
Re:Python is available (Score:5, Insightful)
The hell they do.
Re:No one made it cause no one cares (Score:5, Insightful)
and then join them all together ... using perl.
That's simply not possible as is. (Score:5, Insightful)
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.
Re:Perl in decline, at least here (Score:3, 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.
Re:Perl in decline, at least here (Score:3, Insightful)
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 hardly perfect. Either works just fine. I'm confident Ruby / JRuby does, too, it just arrived a little late to our party. :-)
Re:Demographics (Score:3, Insightful)
Re:Don't fight it - Perl is here to stay! (Score:3, Insightful)
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.
Re:No one made it cause no one cares (Score:3, Insightful)
The full quote being:
"Jack of all trades, master of none, though ofttimes better than master of one." ref [wiktionary.org]
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
Re:Perl in decline, at least here (Score:3, 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.
Re:Python is available (Score:3, Insightful)
You've never had a development schedule written by a business person, have you?
Re:Don't fight it - Perl is here to stay! (Score:3, 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.
Re:Don't fight it - Perl is here to stay! (Score:3, 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
Re:Masochism is rife within IT (Score:3, Insightful)
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.
Re:perl missed several boats, sadly (Score:2, Insightful)
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.