So, after my fail getting Padre up and running on my MacBook Pro, I figured the least I could do was take a few minutes to try installing the new Almost Six package on my 64-bit Vista box.
Quickly: Install was straightforward and fast. It created a Padre folder in the Start menu. Padre started smoothly. I quickly loaded one of my Perl 6 scripts. After fiddling around a minute, I got the Perl 6 plug-in activated, and the syntax highlighting looks good. Using the Run menu constantly ran it against Perl 5.10 -- I assume that means Strawberry Perl is now installed on my machine, as I'm pretty sure my ActiveState Perl was at 5.8.x. I wasn't able to figure out how to run my script in Rakudo from Padre. But I assume that's just a matter of playing around a few more minutes to get it working.
Showing posts with label Perl 5. Show all posts
Showing posts with label Perl 5. Show all posts
Thursday, August 6, 2009
Friday, July 3, 2009
I'm Not Afraid of Change...
... but I am starting to get a bit worried about the Perl 5 maintainers.
Let me try to explain my point of view more clearly. That 11,000 lines of code of mine represent a significant technological debt for my company. I've learned a lot about Perl since I wrote the bulk of it, and Perl itself has progressed considerably in that time. It isn't well-written, or well-commented, and it certainly isn't tested, other than in the sense that its output is mostly used and seems to work fine.
Luckily, for the last decade of Perl 5 development, I have effectively had an interest-free loan on that debt, so it has only been an issue on the rare occasions I have had to update the code.
Now, as I see it, a new version of Perl can do one of three things to that debt:
1) It can add to it, or force me to pay it off all at once. People keep on blithely suggesting simply keeping old copies of Perl around to run the old software. But with 5+ different platforms to worry about and me hoping to write my new Perl code using new features, this would quickly become a significant new source of technological debt. Likewise being forced to rewrite the code without getting something useful from it.
2) It can keep the technological debt the same. This would be the case if my old code works fine with a few changes, but I cannot easily access new features without completely rewriting my code. In this case, upgrading Perl 5 would be painless, but would only make a difference in newly written code.
3) It can actually reduce the debt. This could be because the old code works with few changes and actually works better -- faster, or automatically detects real errors instead of just nagging me about clumsily written code that works. Or it could be because I can make the old code work easily without blocking my access to the bulk of the new features, and those features are actually really easy to use to make the old code better.
Unsurprisingly, I'd be unhappy if updates to Perl 5 fell into category 1, reasonably happy if they fell into category 2, and ecstatic if they fell into category 3.
What has me now worried about this process is no one seems to be claiming the changes fall into category 3. If all it takes is
Instead, people are making it sound like we can expect most future Perl 5 updates to be like taking some unpleasant but necessary medicine. I don't see how the DarkPAN can really object if it only takes one line of code or a command-line switch to make the Perl 5 of the future act just like the Perl 5 of the past. So when I see comments like "Fuck DarkPAN", I start to get worried that people are envisioning changes that are both major and not easy to ignore.
Let me try to explain my point of view more clearly. That 11,000 lines of code of mine represent a significant technological debt for my company. I've learned a lot about Perl since I wrote the bulk of it, and Perl itself has progressed considerably in that time. It isn't well-written, or well-commented, and it certainly isn't tested, other than in the sense that its output is mostly used and seems to work fine.
Luckily, for the last decade of Perl 5 development, I have effectively had an interest-free loan on that debt, so it has only been an issue on the rare occasions I have had to update the code.
Now, as I see it, a new version of Perl can do one of three things to that debt:
1) It can add to it, or force me to pay it off all at once. People keep on blithely suggesting simply keeping old copies of Perl around to run the old software. But with 5+ different platforms to worry about and me hoping to write my new Perl code using new features, this would quickly become a significant new source of technological debt. Likewise being forced to rewrite the code without getting something useful from it.
2) It can keep the technological debt the same. This would be the case if my old code works fine with a few changes, but I cannot easily access new features without completely rewriting my code. In this case, upgrading Perl 5 would be painless, but would only make a difference in newly written code.
3) It can actually reduce the debt. This could be because the old code works with few changes and actually works better -- faster, or automatically detects real errors instead of just nagging me about clumsily written code that works. Or it could be because I can make the old code work easily without blocking my access to the bulk of the new features, and those features are actually really easy to use to make the old code better.
Unsurprisingly, I'd be unhappy if updates to Perl 5 fell into category 1, reasonably happy if they fell into category 2, and ecstatic if they fell into category 3.
What has me now worried about this process is no one seems to be claiming the changes fall into category 3. If all it takes is
no strict; no warnings; and maybe a couple of minor tweaks to the code (carefully and automatically pointed out by Perl 5 itself, ideally) to make a range of cool new features available, then I'm excited by that, and I would certainly expect the vast majority of the DarkPAN would be at least okay with it.Instead, people are making it sound like we can expect most future Perl 5 updates to be like taking some unpleasant but necessary medicine. I don't see how the DarkPAN can really object if it only takes one line of code or a command-line switch to make the Perl 5 of the future act just like the Perl 5 of the past. So when I see comments like "Fuck DarkPAN", I start to get worried that people are envisioning changes that are both major and not easy to ignore.
Wednesday, July 1, 2009
Silent Majority?
NPEREZ asks, "Who are these people that have a vested interested in Perl and yet do not participate?" Well, I guess until very recently I was one of them.
The core of my professional work is a set of C++ libraries. But there are 11,000 lines of Perl 5 code split across about 30 programs which are essential components supporting those libraries. Most of it is generating things, including 95,000 lines of C++ code and hundreds of makefiles, VC++ projects, etc. The Perl 5 I use is either the vendor-supplied Perl (on my Linux boxen and my MacBook) or ActiveState on Windows; my development environment requires that most of that 11,000 lines runs on every platform I use.
In this context, Perl 5 has just plain worked for me for the last decade. With a fresh Linux install it usually takes me about five minutes to get the modules I use off of CPAN and than I'm up and running. I can't recall ever having an issue with using a different version of Perl for this; it just has always worked, quickly and easily.
Given that, why would I have "participated" in steering Perl 5? I'm a busy guy, and Perl 5 has been steered perfectly for my purposes without my contribution. It took Perl 6 to draw me into the community. Now that I'm following a number of Perl blogs (thank you Iron Man), I'm taking an interest in Perl 5 development as well, because I'm excited about the newer modules I am learning about.
So I come to this issue from both sides. On the one hand, I'm very excited about new developments in Perl (both Perl 5 and Perl 6); I'm correspondingly disappointed that 5.10 has not been widely adopted, because that slows my own use of it. (Though after seemingly good results compiling a "personal" 5.10 on one of my Linux boxen, I may try switching to this approach, leaving the vendor Perl for the system to use and upgrading the version I use personally.)
On the other hand, I'd be pretty put out if someone gratuitously broke all my scripts. (The proposed idea of making "use strict" default would do it nicely, breaking all but the most recent.) I guess if the breakage could be controlled by a command line switch it would just be a minor nuisance. Otherwise the cost would likely be somewhere between days of work and simply refusing to ever update Perl 5 again.
Having just taken my first steps into the community, I don't feel like the me of six months ago somehow deserved to be screwed over just because I wasn't really part of the community then. From my perspective, the Perl community did a fantastic job of steering the language through 5.005, 5.6, and 5.8; to the extent there has been a bit of a fumble with 5.10, it seems to be the lack of updates more than the changes to the language. I'd like to see that great work continue along similar lines.
The core of my professional work is a set of C++ libraries. But there are 11,000 lines of Perl 5 code split across about 30 programs which are essential components supporting those libraries. Most of it is generating things, including 95,000 lines of C++ code and hundreds of makefiles, VC++ projects, etc. The Perl 5 I use is either the vendor-supplied Perl (on my Linux boxen and my MacBook) or ActiveState on Windows; my development environment requires that most of that 11,000 lines runs on every platform I use.
In this context, Perl 5 has just plain worked for me for the last decade. With a fresh Linux install it usually takes me about five minutes to get the modules I use off of CPAN and than I'm up and running. I can't recall ever having an issue with using a different version of Perl for this; it just has always worked, quickly and easily.
Given that, why would I have "participated" in steering Perl 5? I'm a busy guy, and Perl 5 has been steered perfectly for my purposes without my contribution. It took Perl 6 to draw me into the community. Now that I'm following a number of Perl blogs (thank you Iron Man), I'm taking an interest in Perl 5 development as well, because I'm excited about the newer modules I am learning about.
So I come to this issue from both sides. On the one hand, I'm very excited about new developments in Perl (both Perl 5 and Perl 6); I'm correspondingly disappointed that 5.10 has not been widely adopted, because that slows my own use of it. (Though after seemingly good results compiling a "personal" 5.10 on one of my Linux boxen, I may try switching to this approach, leaving the vendor Perl for the system to use and upgrading the version I use personally.)
On the other hand, I'd be pretty put out if someone gratuitously broke all my scripts. (The proposed idea of making "use strict" default would do it nicely, breaking all but the most recent.) I guess if the breakage could be controlled by a command line switch it would just be a minor nuisance. Otherwise the cost would likely be somewhere between days of work and simply refusing to ever update Perl 5 again.
Having just taken my first steps into the community, I don't feel like the me of six months ago somehow deserved to be screwed over just because I wasn't really part of the community then. From my perspective, the Perl community did a fantastic job of steering the language through 5.005, 5.6, and 5.8; to the extent there has been a bit of a fumble with 5.10, it seems to be the lack of updates more than the changes to the language. I'd like to see that great work continue along similar lines.
Saturday, June 20, 2009
Adventures in IRC
Yesterday I spent time in #perl6 for the first time. Basically, I tried updating to Rakudo's Pittsburgh release and it failed for me. So I poked my head into #perl6 to see what to do about it. I gave it "last.of.the.careless.men" as my ID, and it thoughtfully translated it to "last" for me, so I suppose I'll probably try "SF" next time.
Anyway, no solution for the bug, so moritz walked me through the process of submitting a Perl 6 bug report. That done, I hung around on the channel all day, just to see what it was like. (Crazy to see Larry Wall checking a bunch of stuff into the repository while I was watching.)
After dinner, someone came around asking for help with a simple Perl 5 regex. No one else seemed to be using the channel for anything, so I went ahead and helped him there. And naturally, in the process, help me with a regex turned into help me with two regexes and then the entire program to use them. In the process of trying to help him quickly, I dug up and posted my old script for running substitutions on a bunch of files.
About thirty minutes later I started regretting having done that. That code is simple, but pretty awful for how simple it is. It's not properly error checked, I obviously didn't
Anyway, I've decided as penance for posting bad code to the net and Perl 5 on the Perl 6 channel at that, I'm going to clean it up in Perl 5 and then take a stab at translating it to Perl 6 this weekend. (The latter will probably be easier if I can get Perl 6 working again!) It should be a pleasant distraction from the ugly C++ API overhaul I need to do for work.
Anyway, no solution for the bug, so moritz walked me through the process of submitting a Perl 6 bug report. That done, I hung around on the channel all day, just to see what it was like. (Crazy to see Larry Wall checking a bunch of stuff into the repository while I was watching.)
After dinner, someone came around asking for help with a simple Perl 5 regex. No one else seemed to be using the channel for anything, so I went ahead and helped him there. And naturally, in the process, help me with a regex turned into help me with two regexes and then the entire program to use them. In the process of trying to help him quickly, I dug up and posted my old script for running substitutions on a bunch of files.
About thirty minutes later I started regretting having done that. That code is simple, but pretty awful for how simple it is. It's not properly error checked, I obviously didn't
use strict, and it is Windows-specific as written. (BTW, if the code at the above link looks okay, that means I've updated it already. You should check out the earlier revisions for the full badness.)Anyway, I've decided as penance for posting bad code to the net and Perl 5 on the Perl 6 channel at that, I'm going to clean it up in Perl 5 and then take a stab at translating it to Perl 6 this weekend. (The latter will probably be easier if I can get Perl 6 working again!) It should be a pleasant distraction from the ugly C++ API overhaul I need to do for work.
Subscribe to:
Comments (Atom)
