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?"
Perl/Windows shops? WTF?
That's like buying an extremely overpowered, difficult to setup and impossible to maintain turbo for your Yugo.
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'!!
here goes nothing Programming Perl in Dot Net
Complete rewrite! FTW! Get real man. Although some quick research does reveal that even though it still is somewhat of a personal taste matter, Python does seem to have certain advantages. Of course, you could always try Java...
From my cold, dead hands!
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.
Some people aren't happy until they have the worst of all worlds.
"Because I can".
Deleted
and before you start ranting about windows is a poor web platform http://uptime.netcraft.com/up/today/top.avg.html.
If you mod me down, I will become more powerful than you can imagine....
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.
But I hope, no JPerl for upcoming 0xff years ever. Otherwise I will not just "Write once and debug everywhere", but also "Write once and never look at it again".
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
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.
Epic fail there, buddy.
Where's the "IronPerl" Project?
I don't know, but have you tried asking Captain Jack Sparrow?
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...
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.
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.
So far all attempts to re-create perl 5 were unsuccessful.
Basically Perl has so many idiosyncrasies that it's impossible to rewrite it, and it has no specification. The large test suite would help, but it's still a crazy task.
Perl 6 should change that, because it's essentially a language specification (plus a test suite as well). But as you might recall, Perl 6 is not yet ready. Sorry dude. We're working on it.
But ActiveState (who make one of the Win32 perl distros) has a commercial package "Perl Dev Kit" that has .NET integration -- see their feature list. I haven't tried it out myself, so I can't comment on how well it works.
If you need to just use .NET components from Perl, you could always use the expose the .NET interfaces over COM and then use Win32::OLE to access them.
Part of the problem is that Perl is not a specified language; the specification is the Perl interpreter itself (see the "Design" section from the wikipedia entry)
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.
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.
When .NET 1.0 was released, ActiveState released Visual Perl, the product is dead since 2005, so probably nobody wanted it.
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:
.NET. So, I guess we have to stick with the Win32 CPAN modules you already know about.
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
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
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.
Comment removed based on user account deletion
look at what site is number 2. no doubt at all bsd/unix is awesome, but win 2003 is NOT a bad web platform by any means, and for many purposes it's very effective
If you mod me down, I will become more powerful than you can imagine....
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.
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.
How the hell, insightful, when citing netcraft ? :P
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
many people consider Perl's time to have passed and no longer see a reason to use it in any significant project.
Ho, lo, and behold. Many people consider that, and many don't. One can use Perl in a dozen of ways in any type of project, one just has to know it enough so as to use it where it's appropriate and not use it for everything like a madman. I've known people who'd use Perl for literally everything, well, god keep us from such people in any kind of project. But, I wouldn't say, even if Perl is so many years old, that it hasn't got it's place. It does, and I still enjoy using it for stuff from time to time.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
If someone wants IronPerl then why don't they start the project? It is just that no one has yet got around to scratching that itch.
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.
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
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.
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.
That's not even worth a Troll mod - much less a 'fixed that for you'.
Try harder next time.
The hell they do.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
and then join them all together ... using perl.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I concur. And if you really want to program powerful in Perl, you should first learn how to design program.
Perl is Lisp, but without the macro facility.
It'd be interesting to see what the distribution of web servers between Windows & the rest is when you completely take out the uptime. I'd guess Windows' share of the web server market is a lot bigger than 2/50 = 4%. Maybe the 2 windows servers listed are just administered by brilliant admins, have zero load or run on a hardware/software combo that has been untouched since Windows 2003 was actually released... Or they're just spoofing the server response, something that has been brought up before when netcraft stats where involved...
Windows 2003 probably isn't all that bad, but I still wouldn't want to have it on my server...
use the the same logic on the linux servers, there's only one listed on there.
If you mod me down, I will become more powerful than you can imagine....
Under cygwin it works afaik.
Furthermore I would strongly advise you wise up, pop in an Ubuntu CD, and ditch .NET altogether. But that's just my 2 cents.
Everything that mentions just shows that Perl was popular and still has a wide base of installs and knowledgeable users as a result. A better measure of its standing now would be to list all the big apps that have been created recently using Perl. I can think of plenty for a dozen other languages, but honest to God nothing springs to mind for Perl.
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!
You never ever mention about security in these area's.
And to me tbh its the fact we have more windows monkeys out there than real IT pro's, which is why you have these great numbers on netcraft ( and lets be fair has been an M$ biatch as of late ). How can choosing a win32 platform ( including said security issues ) for a web platform be great? let alone professional.
I am so sorry but IIS aint it.
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.
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
and studying *nix now that their 2009 budgets are gone ;)
Good people go to bed earlier.
and it's just around the corner.
Who can't help but feel the problem in situations like this isn't any one product vendor but the developer themselves?
The only possible reason I can see people squeezing themselves into such obscure situations is because they're too incompetent, too lazy or just too stuborn to bother to learn the right language for the job.
A good programmer should be able to switch between languages with very little preparation as a good programmer should understand the fundamentals of languages, of different programming paradigms and so on and so forth.
The solution to the problem is simple, stop cornering yourself with an obscure way of doing things when you can save a lot of time and effort doing things a more mainstream way with say, Python if you want to remain OSS, or a .NET language if you're happy to shell out for Visual Studio.
If you learn to accept and embrace change, you and your organisation will be far better off as a result.
And the fact that 34 of the results on that site are apache on BSD including the 1st entry and 11 are irix
so 2 vs 34 hmmm which is a better platform i dont know.
I was the hard-core perl guy for our shop, but more recently we've switched towards Windows Powershell for the tasks I was using perl for. (Mostly AD manipulation)
Using Quest software's extensions for AD, there isn't much I can't do against AD in a lot less code than I would have done in perl.
My initial looks at Powershell/Monad left me less than interested, but since spending a little time with it, I'm realizing that it's got some wicked tricks to it.
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.
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! :-)
I'm now tossing up whether to learn Ruby or Python
Spend 3 hours on the tutorials for each, then make a decision. I'm pretty sure I know which most people will prefer (certainly understand quicker), but I'm not going to start a flame war by saying which.
Either way, that's the only way to make the right decision and not regret it, or blindly dive into one without knowing about the other.
I wrote my first program at the age of six, and I still can't work out how this website works.
Will you be bottom or top?
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. But those languages were rigid and didn't always scale well. Yes, I know JSP scales better then the other two; but, I've personally had nothing but bad experiences with JSP.
So the next generation web developers were either taught on ASP or PHP. The ones that needed more power from PHP usually then went back to Perl. Otherwise they stuck with was free and easy to use.
In recent years newer and simpler languages have come out to do what Perl does on Windows. .NET has caught up to Perl in power and extensibility. PHP 6 is a step away from having the same power and code consistency. Now IronPython and IronRuby is out with great power of their own and the ability to plug directly into .NET.
So with all these new choices and lack of the much promised version 6, Perl on Windows has lost most of its shine.
You say things that offend me and I can deal with it. Can you?
Only in America...
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
FWIW I'm writing a full test suite for our hardware in perl.
kind of like e-test, but while I do timing centric and low level stuff in C, I'm writing the test scripts in perl. It's actually the right tool for the job as anyone can modify the script as needed for their boards and if you know c/c++ then there is very little you need to know additional to modify an existing perl script. We are nearly a 100% windows shop too. (there are a few people with MACs (mostly running windows) and we do test most of the major OS's on our boards at one point or another, but the bulk of the testing and software is Windows based.
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
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;"
Windows recently created a tool called PowerShell which is a rather fully-featured language which gives you basically full access to win32 and .Net APIs from a script. So while perl / python / ruby may be a more comfortable choice for many people, the use of those languages on Windows platforms is likely to always be less fully featured than the MS solution.
See http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx for more info.
I'm a mostly-Windows (some Netware and Linux, also AS/400, which does support Perl, however I stay the fuck away from that system...) admin and the only language I use is Perl. I don't know if that's normal but it was easy to learn and implement in a short period of time; I can't see using anything else for scripting now that I've learned it.
I never said anything about Linux, did I?
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.
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.
Maybe not
...and in the darkness bind them
There, I fixed that for you.
This issue is a bit more complicated than you think.
oh you're a b*st*rd.
you made me smile too and I don't even program Perl! :-)
I prefer Linux to Windows. But for many companies, the cost of installing Linux (in time, not licenses) and retraining the staff exceeds the cost of the Microsoft licenses.
Windows is a headache, but it's not enough of a headache at many places for them to migrate. I want that to change, but my personal preference and yours doesn't change the reality.
I'm now tossing up whether to learn Ruby or Python.
Meh, six of one, a half dozen of the other. You either pick a seriously half-assed Smalltalk, or whitespace significance and broken closures. In the end it's basically a wash, IMHO.
I have no opinion about the lack of of a finished and well distributed Perl6, but you are completely wrong to say that CPAN is not getting any more useful additions. Since 2000 the number of cpan modules has grown from about 5,000 to 14390 (you can see the count and other stats, such as the number of authors registered at http://cpan.org/) Also, some of the code I've seen in the past few years is among the best. For example Moose, (http://moose.perl.org/) is a full on meta object stack for Perl, and makes writing very clear OO code trivial.
To answer the general question, "Where is IronPerl", I guess I have to say that most people in the Perl community are pretty die hard Unix people so unless we are getting paid to work on Windows supporting it is an afterthought.
Also, the CPAN philosophy is to try to write stuff that runs everywhere, and an IronPerl would be something specifically for Windows, so that's not going to be popular.
I'm not sure what you mean by lack of XML/Xpath support. There's probably a 100 modules on CPAN dealing with this.
To be honest, I am not familiar with DBI::CSV, but I really don't see not being about to do joins on a text file to be a major defeat for a language. If you could give me an example of what you are trying to do I'd be happy to comment.
Peace, or Not?
You've never had a development schedule written by a business person, have you?
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.
Suits who pick the technology are usually wrong, and seldom obeyed.
Strawberry Perl and ActivePerl are both pretty nice packages. Many Win32 modules like Win32::OLE, Win32::API, and more in the Win32 and Win32API namespaces are perfectly usable.
The places most qualified to answer specific questions are probably comp.lang.perl.moderated (or maybe comp.lang.perl.misc) and Perlmonks. I don't know too much first-hand about PerlGuru, but they do have a section specific to Win32 programming with Perl and I've heard some good things.
where is "IronMyShirt"??
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
The inexperienced tend not to get any code done in other languages. So is it really a bad thing that Perl let's someone get their project done poorly instead of not at all?
Oh, and with all of Java's misdirections (or abstractions), while any one line may be readable, the program can be completely incomprehensible.
t
Have you ever seen Perl 5 source code? It's a big disorganized mess. Many years of add-ons and patches have probably made porting it from C to a VM language less than it is worth. Perl on a VM would need to be developed from scratch.
A correction is in order.
PP suggests that Perl has been used by Unix sysadmins since Unix was in its "infancy". Unix was more than 16 years old when Perl v1.0 was released. In its first 1.5 decades, Unix sysadmins used various shell scripts and awk (forever an awkward language) to work their magic.
<ramble>
I agree with PP that Perl and Windows do not get along very well together, I think because of very low level philosophical differences over who should benefit from the resources available on a client's computer. Perl's philosophy is that as far as it is concerned, any user should have full access to all system resources, and the OS has the responsibility for limiting access to whatever is appropriate for a specific user through permissions and so on. Windows' philosophy has always been that the developer should have full control over all the client systems' resources and the user should have only the access that the developer chooses to expose. It comes down to money: the Windows approach supports licensing fees for Microsoft and for third party developers. It comes at the cost of the Registry "database", but the high maintenance and repair costs of the Registry are borne by the user, not by Microsoft or the 3rd party developers, so that's never been considered an issue.
Coding perl scripts for WinNT was a big part of my career for several years. Many of these were one-shot programs to convert text output from some idjit's pet "database" into standardized data files that could be fed to properly developed and maintained spreadsheets or databases for further work. Others were scripts I did not allow anyone else to have access to, which mined a large legacy MUMPS database, anonymized, sanitized, and often summarized the data, and formated the results into .csv files for feeding to spreadsheets for various reports. This was usually because the legacy system had been designed to produce the yearly and quarterly reports that had been adequate in the slower paced world of a decade or so earlier, but we now needed monthly and weekly reports to manage personnel resources, costs, and safety concerns. I also wrote a handful of perl scripts that needed to be operated by others, but because WinNT's security features were arcane and inadequate, we couldn't safely put the Perl interpreter on any user workstations. I converted the scripts to executables with perl2exe, to better fit the Windows security model. This worked pretty well, but the need to find workarounds for some simple run-time Perl techniques that could not be precompiled into an exe was irksome.
</ramble>
No, I was very careful not to say that Perl was used since Unix's infancy. I said since large systems were in their infancy. By this, I mean since we started needing large systems for more than just the military or giant companies (like Boeing etc.)
As I recall, it was quite obvious to me around 1985 (when I first started paying attention to such things) that COBOL would be overtaken and die. Likewise, when I first started playing with Unix around that time, after years of VMS, it was completely obvious that VMS was finished.
Now, it is quite true that both of these were very popular in the job ads of the day and many people used them and advocated for them. To this day they are still used. But they are also pushing up daisies in the sense that its clear that their future will be one of decline and death.
Perl is dead, and has been for almost a decade. It may take many years for its inertia to spin down, but the die has been cast.
"Not an actor, but he plays one on TV."
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-
All the bright young things went into the death march that is Perl6 and CPAN stopped getting useful additions.
That's not true. There are still lots of people working Perl 5 and CPAN modules. Since you've last checked, we've gotten Catalyst, DBIx::Class, Moose, and tons of other useful stuff. Most of this doesn't even compare to what other languages are offering. If you use Python or Ruby, you basically get Catalyst (Merb), but you don't get DBIx::Class (AR is a painfully bad joke) or Moose.
There are also tons of other interesting projects being worked on by "bright young things".
Or modern, complete XML/Xpath support.
XML::LibXML
Or a DBI::CSV which can do joins.
There's more than one way to do it, of course, but just shove your CSV into a SQLite database (via DBD::SQLite) and enjoy having a real database instead of a text file. Of course, joins are very easy to implement yourself; I'd almost go so far as to use the word "trivial".
But anyway, if you want this, please write it an put it on the CPAN, then we can all have it. That's what's made CPAN so valuable.
My other car is first.
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
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.
Learn Ruby. As a Perl programmer I predict you'll love Ruby much more than Python. I've been converting some of my old Perl stuff to Ruby lately, and I notice a big performance jump too.
Amen to that. I jumped ship from Perl 5 to Python about 1.5 years ago, and haven't looked back.
There really isn't a lot of difference between the two languages in terms of what they can actually *DO*, it's just that Python does it more easily, more consistently, more readably, and with a broader and more coherent standard library. I'm a lot more productive in Python, and there is nothing it lacks. (Number crunching? Check! Perldl->Numpy. Date manipulation? Check!)
Let me put it this way: If Larry Wall took a time machine back to 2002, and presented Python 2.6 as the brand new Perl 6, everyone would hail it as a brilliant but not excessive redesign, and he would be richly congratulated for the (ahem) brisk development schedule.
My bicyles
More specifically that quote is from Richard Dice, president of the Perl Foundation. Can't imagine why he would speak highly of Perl. ;)
Don't know much about Ruby, but I find the whitespace significance very nice and makes reading existing python code very pleasant.
If you indent your code properly anyway it shouldn't make a difference. Actually, you wind up not having to type out parenthesis or curly braces. And who likes looking at...
}}
}
}
You whine too much.
There's more than one way to do it.
If you want to do joins on data that you have in CSV files, just insert them into an SQLite database first.
XML/XPath support: XML::XPath
If you want to code .Net, use C#. If you want to use CPAN, use Perl. The two languages are getting more similar all the time, with each release of C# getting better.
Oh, and here, or more specificly here is one metric reflecting a significant drop in popularity for Perl relative to other languages.
That isn't to say Perl is "bad" or going away any time soon. The huge installed base and extensive module repository ensures its longevity (and even as it wanes a larger job market) but as time goes on fewer new projects (both public and internal) are choosing Perl as the implementation language. It was never particularly strong as a desktop application language - Python seems the leader there - and it has long since been eclipsed by PHP as a web development language.
Perl's strongest area is in it's roots as a quick and often dirty language used by administrators. Unlike developers admins are relatively unlikely to go language shopping and most of the deficiencies of Perl are relatively unimportant for that type of work.
I resemble that comment!
Seriously, the reason why there is no "IronPerl" is that no one with the capability to do the port of Perl 5 to .NET has had the motivation to do so. As was previously commented upon, the bar to do this kind of work is, unfortunately, higher with Perl than with other languages in its class (e.g. Ruby, Python) due to the evolutionary creation & implementation of the Perl 5 language. Python has a language spec off of which implementations can be built in a clean-room fashion. Perl has a language implementation which is its own spec. This leads to significant gnarly-ness when it comes to doing subsequent implementation, be they on .NET, the JVM or on a Lisp Machine. Still, it's not impossible. If someone made a reasonable effort at it then it could happen. (And Microsoft could well pick up the tab to someone who showed sufficient talent and initiative too. The IronRuby implementation is the product of one guy who started it as a personal project. And then Microsoft noticed and hired him to keep doing what he was doing.)
Perl 6 addresses this problem in that Perl 6 is a spec. (Well, it's getting really damn close to being a completed spec.) There are no completed implementations of it but several are in the works. Pugs is a Haskell implementation effort. Rakudo is one built on the Parrot VM. There's the SMOP implementation effort too. Larry Wall is working on one that will use the Perl 5 VM to implement Perl 6. I'm sure we'll have implementation teams working on JVM and .NET implementations soon enough too.
If all you want to do is Perl 5 on Windows there are a few ports -- see ActivePerl and IndigoPerl.
Cheers,
- Richard
Why would anyone trust TIOBE's results? They don't reveal their research methods, and no one has been able to reproduce their findings. That's not good science. That's push polling without the telephone.
how to invest, a novice's guide
I think that page is more a testament to the admins of the servers and the datacenters they are in than the OS they run. It's pretty obvious from the page that there are only 7 groups of servers there.
So you nerds are getting a little pussy after all!
at OSCON this year, I seem to recall a talk on "Strawberry Perl" http://strawberryperl.com/ - apologies as I can't remember the developer's name, but basically if I recall correctly this is meant to be a quick easy way to get perl working on Windows boxes, fully CPAN compliant. I believe he was working on "Chocolate Perl" as well. Not sure if this will work with what you want but it should be a start. The problem with active perl is that it is no longer being supported.
but I find the whitespace significance very nice and makes reading existing python code very pleasant.
Until you need to move a block of code from one level of scope to the other and discover your editor can no longer help you get the indentation right because the language doesn't provide block scope delimiters. And if you do try to use the editor, it can actually introduce semantic bugs by accidentally placing lines of code at the wrong lexical level. Awesome.
Sorry, but no thanks. I have absolutely no problems formatting my code properly and don't need a language enforcing it's standards on me (in fact, any programmer that *does* need a crutch like that should be drummed out of the industry for the hack they are). Meanwhile, I regularly use my editor for automatic indentation, and any language that makes that impossible (or unnecessarily difficult) is out of the running.
It depends what their code's doing - if they're automating some admin task then sure, it's better to get some code written. But if it's for something that multiple programmers are/will be working on I'd say yes, inexperienced Perling can be a very bad thing. Also because you or I might have to maintain it :-)
That said, I learned to code in Perl and I'm sure I wrote more than my fair share of unmaintainable, unintelligible code (and, I'm sure, still do!)
You're so right, though, that incomprehensible programs are easy to write in any language.
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
They don't? The methodology isn't perfect, but we're not talking about calculating tolerances for a bridge or determining what hunk of tissue to excise during brain surgery here. In other words, a blunt metric is all we're looking for (and is certainly more reliable than a quote from an individual with a direct interest in promoting the language).
And it's not like there aren't corroborating sources like Google trends, Sourceforge statistics (a bit old but still relevent), book sales and so forth.
Perl made windows usable, by bringing a real power tool to NT. I sure it would have slowed adoption if it had not been not available since NT had such a lackluster scripting system.
putting the 'B' in LGBTQ+
Other than some poor choices for string formatting, I don't find that python example particularly hard to follow.
The perl above seems to be as streamlined as possible, nice to know it can be done.
#6495ED - cornflower blue
Apparently some mod out there doesn't understand that "Flamebait" does not, in fact, equate to "I disagree with this guy"...
"Lowest defect rate..."
Of course, there are different measurements, but:
http://scan.coverity.com/rung2.html
At the end of the day, the COM stuff isn't going anywhere. The .Net APIs provide a kind of wrapper around the system code and usually molest the unmanaged stuff with P/Invoke... they don't replace it. In fact there's some stuff the managed APIs still can't get to (mostly at the system level), and a big reason why you still see jobs posted for VB6 developers out there.
And while I haven't spent much time with IronPython and IronRuby, I'd imagine that the code you produce still must adhere to .Netisms and use .Net core objects to get things done. If there was an IronPerl, there probably wouldn't be much diff between learning how to use it and learning another lang already supported by the CIL.
Finally: perl AND COM? That's not Sparta... that is madness. :(
Agreed. I'd add that in addition, in my view Perl 6 was heading in the wrong direction.
What I wanted from Perl 6 was a cleaned-up Perl with fewer linenoisy operators, a cleaner OO programming syntax, and so on.
When I saw the Apocalypses citing code like &::('*')::($alice ~ '_misc')::Bob::doit(1,2,3) and @a =:= @b (yes, verbatim examples from Apocalypse 12), I realized that Larry Wall's idea of what makes a good programming language was fundamentally at odds with mine.
Discussing it with some unnamed senior figures in the Perl community, I was quietly informed that a lot of people were looking at Ruby. So I looked at Ruby, liked it, learned it. I've rewritten most of my Perl code as Ruby now. The result is usually about half the speed, and about 10x as readable. That, to me, is a good tradeoff.
(I wonder how many more programmers Python would get if they simply added a Ruby-like "end" keyword to end blocks with.)
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
If I wrote a sentence like:
"Of all the PC operating systems, Windows offers the biggest installed base of applications, of code, of integrated systems, of skilled programmers" (This is of course true by orders of magnitude).
I would get hundreds of replies that say in essence:
I'm smart so the system I use is much better than Windows despite its popularity. Windows is popular because users are fools and have been duped.
Perl has a language implementation which is its own spec. This leads to significant gnarly-ness when it comes to doing subsequent implementation, be they on .NET, the JVM or on a Lisp Machine.
ObCorollary: only Perl can read Perl.
This actually looks like a problem - I went looking to see if there was anything that could read Perl code and do static analysis, etc. I was interested in call-graphs and similar metrics. At first I found some rough stuff but basically the field was empty, at least as far as external tools were concerned.
Then, epiphany. I stumbled on the "only Perl can read Perl" and discovered a whole new world - the Perl compiler and the profiler hooks in Perl allow one to act on pretty much anything you could dream of.
So Perl is quite capable of instrumenting Perl code. But it is alone in that respect - at least until Perl 6.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Here are some random phrases from Gravity's Rainbow, one of the finest works of 20th Century English literature.
crimson, hot, squeak-stockinged slavegirl "gam"
a woman or an entente of nations
You can keep Der Bingle too a- And that darn "bu-bu-bu-boo"
allowing the cosmic Serpent, in the violent splendor of its scales, shining that is definitely not human, to pass
Thus, English is also unmaintainable and Pynchon is a terrible hack, at least when you take random bits and phrases out of context.
how to invest, a novice's guide
If Perl is antique, then I suppose C is absolutely ancient. Fortunately, hyperbole doesn't keep Perl, C, or even, dare I say, Cobol, from being used, today, tomorrow and well into the future.
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.
If you're spending that much time concerned with how effective your program languages are at prohibiting your programmers from producing unreadable or unmaintainable code, I'd say you should look to hire some better programmers.
In fact the way OO is implemented in perl is nice, you can do all sorts of handy things that are nearly impossible, even in other dynamic scripting languages.
As for the 'plumbing hanging out' it actually doesn't in practice 99.9% of the time. I mean materially what is the big difference between notations like:
this->{attributename}; # perl
and
this.attributename; // most anything else
And ouch, you have to call 'bless', but actually that gives you considerable flexibility since you can choose what package to bless to, and even rebless an object to a (possibly totally different) class at run time. Purists will tell you how HORRIBLE this is, but when was the last time you tried to stuff an X into a variable that was supposedly a Y? It just isn't that big of a problem, and if it IS something to worry about, you can easily add type checking to any variable via a tie.
There are a couple of minor annoyances, like the lack of implicit lexically scoped variables for parameters which might be nice to do away with, but again if you look at the syntax overall it makes little difference.
Finally if you are using a package (class) which produces blessed references (instances) as long as you use the defined API provided by the developer it should hide anything like 'is this class implemented using blessed hashes or blessed arrays'. Why would you care? How many of you have used CGI.pm for years? Does ANYONE here know off the top of their head if an instance is a hashref or not? I seriously doubt it.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
This is how I see most of my colleagues (and myself) using it. Looking at it as a custom tool(s) in their toolbox not so much as part of the public toolbox.
For the type of tasks I use it for nothing else comes close. I still use it on OpenVMS, Linux and Windows.
I wouldn't build a large system that runs on Perl, but every large system I build gets done quicker and is maintained better because of Perl.
Wrong just isn't a strong enough word for this.
There are 250 BILLION lines of running COBOL code today. In fact there is more COBOL running out there than all the other code in all other languages combined (at least counting just business applications, but even counting everything this may be true). Many of them are truly gargantuan pieces of software, dwarfing things like Linux kernel in both size and at least some measures of complexity.
COBOL is in fact not dead at all, and is a .NET supported language, even MS knows better than to shun it. There is a real need for COBOL programmers as well, and there has been for several years now a concerted effort by industry to increase the number of people trained in COBOL programming. Believe it or not COBOL supports OOP and pretty much all the other commonly seen features of other procedural languages.
Likewise Perl is FAR from dead. There are vast quantities of web application code written in Perl.
Neither may be considered by 'cool' by the self proclaimed 3L1t3 hackers of the world, but if you think businesses really care much about that, you'd be mistaken.
Not to say I think everyone should code in or would LIKE coding in either COBOL or Perl, but calling either one of them dead is just contrafactual in the extreme...
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Will people still be saying it's vapourware? :-)
Parrot is a virtual machine that pre-dates .NET and has many of the similar objectives. Probably the reason that no-ones put PPI and .NET together into something like IronPerl is that there are more interesting projects around, like JIT conversion of .NET bytecode to parrot bytecode. Then who needs Mono :-).
> A friend asked me today about using some Microsoft server components from Perl.
fuck him off, he's no friend
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
There's a difference between a fragment of an expression in English, and what's supposed to be an entire meaningful expression in Perl.
And if you think the Perl examples are unclear and ugly because of lack of context, you have ENTIRELY missed the point.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
You and I apparently have different definitions of what a large system is. In the 1970s Unix was being used on minicomputers that were running university campuses, banks, point of sale systems, and so forth. Which to my mind were large systems. They certainly required the full time attention of a sysadmin. Who had to make do without Perl until it finally came along in the late 1980s.
I think you believe they're "unclear and ugly" because you know don't know Perl 6, in the same way I have trouble understanding Stanislaw Lem's Solaris because I don't even know the Cyrillic alphabet. Your original post jumped around between "I find advanced Perl 6 constructs difficult to read despite never having programmed in the language" and "My Ruby code is more readable than my Perl 5 code", so I may have missed your point.
how to invest, a novice's guide
Also, at the age of 8 he was an active member of the Weatherman's society with Bill Ayers.
Just a small correction though, oreo is a little over 2/3 black unless it is doublestuffed.
If you're going to dismiss any criticism of Perl 6 from someone who doesn't program in it, then you've dismissed *all* criticism of Perl 6. Well done.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
You made a hasty generalization. I dismiss all "It's hard to read!" criticisms from people who don't know the language.
how to invest, a novice's guide
Python + ctypes
load the DLL yourself direct from python, get a pointer to the function and use it, from python, the same any other windows programmer.
zero reliability on frameworks and included in the main python distro for 2.5 and above.
how about this?
http://search.cpan.org/~yamato/Win32-CLR/
No I am a winner. You are the loser since you get modded down to (-1, Troll) and suffer Karma point damage. Go me!! :)
If all you want to do is Perl 5 on Windows there are a few ports -- see ActivePerl and IndigoPerl.
And, of course, the understandably famous Strawberry Perl. I currently work on Windows servers which run ActivePerl as CGI, and it all works peachy, but it's nice to know we have other options to fall back on if ActiveState lets us down.
As usual, the answer to any such question is "both". It's not at all hard, as many concepts are shared. Both have something to bring to the table as tool languages, and both have great potential on the market (the indicator, for me, is that both Sun and Microsoft have their own actively developed and pushed implementations of both of these languages).
A programmer should be able to write a Web app in an OO-language and MVC framework of his choice, write a parser in Haskell, write a distributed system in Erlang, write heavy yet fast number-crunching code in template C++, and write a script to automate some daily task in any shell language popular on his platform. Specialization is for code monkeys :)
Hmmm... but is "Lisp without the macro facility" really Lispish?
Yes, Perl shares anonymous first class functions. But so do JavaScript and an number of other languages. What everyone talks about as the defining feature of Lisp is programmatic redefinition of the program at runtime. While you can theoretically do this in Perl, it's so far from being easy that I don't think it can really be called a language feature. Add to that Perl's incredible verbosity and plurality of specific features...
I guess what I'm trying to say is, you can program Perl like it's a crippled version of Lisp, but only by ignoring a great deal of the language's basic structure.
The difference is that C, for all its antiqueness (and yes, it is quite obviously an antique language in so many ways), is still the reigning king in its niche because there were no successful contenders to supercede it. Not so for Perl.
Aah, here we go again - Perl bashers coming out of the woodwork, and the usual mantra being repeated ad nauseam : line noise, unmaintainable, doesn't scale etc etc. I have used Activestate Perl on Windoze, but my first love will always be Perl on a *nix box. I earn my living writing Perl day in and day out (yep, they actually pay me real money, and my credit is accepted all over town - go figure) and I enjoy it. I maintain my own code and code written by other Perl programmers : you take a lot more care when you know someone else may have to troubleshoot what you have written. I also like Python (actually coding as opposed to just talking about it). Beating up on the other guy's language/toolkit/methodology really hasn't gotten us anywhere : please don't judge 20 years of Perl on the 500-line nightmare your sysadmin wrote after he realised that his 3000 line Bash script was a piece of sh*t. As for Perl being an 'antique' language, I believe that there are still folk out there coding in C and that new-fangled C++ upstart, although those languages don't seem to have that aura the cool kids are looking for these days. I guess we need a video of a guy creating a Wiki with C in 20 lines of code.
I guess you missed the 9000 posts where chromactic replies to any perl6 thread with the logic that "we have monthly builds, therefore perl6 is out and you _can_ program in it."
the mind boggles.
If you're spending that much time concerned with how effective your program languages are at prohibiting your programmers from producing unreadable or unmaintainable code, I'd say you should look to hire some better programmers.
How do you expect anyone to actually do that? Have you ever tried to find really good programmers? There are a few around, but they don't exactly grow on trees. Remember: half of all developers are below the median skill level.
And why bother? Most projects don't need your rock star programmers (if you have any) to do the bulk of the work.
Furthermore, I haven't seen too many brilliant programmers complain seriously about Python (well, they do, but it's about how hasattr() swallows KeyboardInterrupt and about the str/unicode duality). It seems like one way to weed out idiot programmers is to see if their "WTFOMGwhitespace!!!" stage lasts too long, or if they still like PHP after using it for a few months.
http://outcampaign.org/
Perl is in decline because everyone thinks it is "going away" to be replaced by "perl6" which is a different and incompatible language.
It's almost like Larry, as initial creator of Perl, decided to kill the language, making 'Perl6' one big long suicide project. It's more than a bit sad.
Though last I heard Guido was trying a smaller rendition of the same by going for a new, incompatible version of Python -- but too many people are into the religion of python (vs. religion of Guido) unlike in the perl community, where Larry managed to get most of the language supporters to drink his Kool-Aid.
With Perl as it is known today having "no future" (i.e. it's future is to be replaced by a new language bearing its name), its no wonder it's momentum is going south in a big way.
It's very sad, since Perl served a purpose python never will -- short, 'one-liner' scripts that took the place of sh+sed+awk+tr (etc). A perfect replacement for the cornucopia of unpronounceable unix command line tools.
Having a "Lisp without the macro facility" is like having a Porsche 911 Turbo without the engine.
Stop Bogarting the scripts man....
I know! The epistemological/ontological gyrations required to argue that Perl 6 is vaporware make my head hurt too.
You're welcome to download any of the 20 previous monthly Parrot releases and write and run Perl 6 code with them, though we've only had a binary called perl6 for the past nine or ten.
how to invest, a novice's guide
Yeah, well, it would be a pointless debate in the sense that it is well and truly water under the bridge at this point, but there WERE choices. We could argue about the technical merits of different VMs, but there were choices in 2001. Have been for 20 years before that for that matter. Pointless to get into it at this juncture.
The proof will be in the pudding in any case. Personally I think P6 missed the window of opportunity unfortunately.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx At first I thought we finally had a real shell on windows, but we don't. Once you get used to it, it is much nicer than the cmd shell. You can access .NET/COM stuff from a powershell script.
e.g.
PS C:\Users\jake> $now = [DateTime]::Now
PS C:\Users\jake> [Console]::WriteLine($now)
10/10/2008 10:44:10 PM
PS C:\Users\jake>
Thanks for this informative comment - I haven't had the time to try Python yet, but now I won't bother.
I agree wholeheartedly - having a language FORCE you to indent/whitespace in this fashion is not only restrictive, but fucking stupid.
I'll stick with languages such as C/C++, Perl, PHP, etc, which allow you the freedom to structure your code the way you want to.
Sounds like you're using the wrong editor. If you move pieces of code around in languages other than python you should be changing the indentation too....so your editor should provide an easy way to do that.
Personally I use nedit where I can select a rectangular area and delete it to outdent. To indent I usually create a macro. space space space space back back back back down...repeat. My editor is not that feature rich and doesn't have buttons for indenting and outdnting and I do fine.
If using proper indentation is so hard for you that you won't try Python I hope I never look at your code in other languages.
Thanks for this informative comment - I haven't had the time to try C/C++ yet, but now I won't bother.
I agree wholeheartedly - having a language let you have the option to use curly braces is fucking stupid.
I'll stick with languages such as Python, which is consistent.
:-)))
Haven't done much programming, have you?
Let me guess, you're fresh out of school and you're using Python cuz it's koool, w00t, and all that juvenile shit?
You remind me of the dingdongs who sang songs of praise about Pascal in years gone by... Academic rectitude doesn't cut it in the real world. :-)))