Domain: perl.com
Stories and comments across the archive that link to perl.com.
Comments · 775
-
Re:My short experience with perl...
Oh please.
"Especially when every perl doc I see around tells me to use curved parentheses for lists, and @ prefixes for variables that refer to them..."
How hard did you look, really? If you go to Google and type in perl list of lists, the FIRST link takes you here.
And within 1/2 a page, you see this:
# assign to our array a list of list references
@LoL = (
[ "fred", "barney" ],
[ "george", "jane", "elroy" ],
[ "homer", "marge", "bart" ],
);
print $LoL[2][2];
bartDamn anti-Perl trolls
:-) -
Re:Isn't Duke Nukem Forever coded in Perl 6?
Perl 6 has got to be the vaporiest vaporware out there, almost.
Funny, I have working Perl 6 code.
The development on this thing has been going on forever.
Like the C programming language or Java or C++ or Python 3000 or Ruby or PHP or....
Six really is going to be the horse developed by committee.
What does that even mean? Is Larry a committee now? (Yes, I know about @Larry. That doesn't make a meaningless cliche mean anything.)
How much of the stuff in there was cool back in '00 really matters now?
Off the top of my head, cleaner syntax, better consistency, improved FFI, more powerful grammars, multi-methods, improved OO, a better VM, true garbage collection, better speed, currying, optional type inference, hyperoperators, junctions, improved reflection, integration of regular expressions and tree transformations, role-based typing, better distribution options, JIT, true macros, and built-in set operations matter. I probably missed a few.
-
Isn't Duke Nukem Forever coded in Perl 6?
Perl 6 has got to be the vaporiest vaporware out there, almost. The development on this thing has been going on forever. Six really is going to be the horse developed by committee. How much of the stuff in there was cool back in '00 really matters now?
-
duke nukem forever syndrome
Rewrite of Perl has been in the works longer than most would like to rememer. I find it hard to believe it will ever be adopted over perl5.
-
Re:The real 90s versus outdated 00s software
Such a fiasco never occurs in Java because the compiler catches the error no matter what
But every programmer worth his salt is starting his/her scripts with use strict.
This forces you to declare your variables. With PHP however, I admit, you're screwed. -
You want documentation, not coding standards.Don't get me wrong, coding standards help too, but by the question:
Right now I'm more concerned about trying to set up coding standards, so that any developer can jump into any part of a project and be able to figure out what's going on, without wasting a couple hours just to figure out the code
I couldn't care less if people are using tabs / 2 space indents / cuddled elses / whatever formatting crap.
Even how you name your variables vs. functions vs. methods vs. objects has very little to do with being able to jump into a project, so long as people are consistent. What's more important, is to maintain good documentation, so that someone has some clue what the relevent files are, and what the overall logic was in how the program / general modules / etc are laid out.
No one is going to be able to jump in and start modifying code on a moment's notice. On a large project, spread across multiple developers, it might take a week or more for someone to have a grasp of what needs to be done, why it's being done the way it is, and what the implications are to change things to the way that they think is better. (I consider unit tests to be a form of documentation -- given a specific input, I expect the given result)
And let's not forget the whole mythical man month -- tossing in another developer at the wrong time may screw up the existing developers if they get pestered by the newbie. That's why I try to keep documentation explaining what the purpose of the project is, known outstanding issues, how the program is laid out, all of those sorts of things that a new developer would need, should I get reassigned, fired, given extra help, or just give up and decide to quit.
A ticket tracking system, and some centralized documentation repository (might be a wiki for multi-person projects) can really help you get a handle on these sorts of things.
If you want actual programming tips ... take a look at Damian Conway's Best Practices article for perl.com (or his book) ... much of it applies to more languages than just Perl. -
perlcc
You may try perlcc
-
Yawn. Perl Catalyst had this same exampleCatalyst Web Framework on Perl.com
The best bits about catalyst are:
1. built in webserver. Apache/Apache2 is in flux at the moment, and you're caught in shifting sands of documentation, libraries and online-help. A built in webserver means you can prototype fastest.
2. Eclipse. With EPIC you can code and debug your perl in Eclipse. -
Re:refactoring dirty prototypes
Anonymous methods can also make use of the local variables and parameters in whose scope the anonymous method lies. This is a somewhat complicated, and we don't yet have a clear idea of when one should exploit it. So to illustrate it we'll borrow the example from the documentation.
That's funny. They should have read the standard Perl article on closures: http://www.perl.com/pub/a/2002/05/29/closure.html
Here's a quote from it:
Here's the canonical example of closures, that you'll find in practically every Perl book:
sub make_counter {
my $start = shift;
return sub { $start++ }
}
my $from_ten = make_counter(10);
my $from_three = make_counter(3);
print $from_ten->(); # 10
print $from_ten->(); # 11
print $from_three->(); # 3
print $from_ten->(); # 12
print $from_three->(); # 4
Related Reading
Perl in a Nutshell, 2nd Edition
Perl in a Nutshell, 2nd Edition
By Stephen Spainhour, Ellen Siever, Nate Patwardhan
We've created two "counter" subroutines, which have completely independent values. -
Am I the only one...
Am I the only one to think Pixie was kinda cute, then go back to her card and realise she's supposed to be 14? Curse you Larry Wall, curse you!
-
Re:State of the Onion
You want the exegesis and apocalypse articles for that. They're the ones that go into details about the language (apocalypse more about design and big picture stuff, exegesis more about implementation and how it actually works, IIRC). State of the Onion is more about the perl community.
Look here for the articles.
Just bear in mind that perl 6 is a lot different than perl 5 (which is what you're probably learning). The syntax is similar, but object handling will be different, some of the data types are changing (I think), and a few of the operators will change (the biggest example, "." will be replaced by "_").
Perl 5 development continues, of course, but there's not going to be any major changes to it from here on out, so you won't see many articles about the language itself anymore. Most of what you'll find is cookbook style articles and documentation. -
Perl 6 is a mistake.I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespacethank you very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. It's like Ada all over again! The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.
-
Short article by the same author
In a similar vein there was a recent article by the same author printed on perl.com:
- Ten Essential Development Practices (Perl centric)
-
Re:GUI's suck at iteration
Well, for the zip example, I bet the newer version of Winzip, with it's context menu: "Extract to ____" (where ____ is the name of the archive...or 'extract to here'), would extract the stuff and preserve structure. I do have a paid version of Winzip at work, and it is worth it, even though XP has Zip stuff built in, as it is simply more efficient.
However, needless to say, for the examples you provide, I'd certainly hit the Start menu, and choose 'rxvt,' and use Cygwin bash. :D Oh, and for the .doc example, you might want to give Win32::OLE (http://www.perl.com/pub/a/2005/04/21/win32ole.htm l) a try. I bet that could be used to script M$ Word. It'd be an evil hack to end all evil hacks, but would probably be quite cool. Needless to say, if it was on Linux, and you were using OOo, the file format would likely be manageable by sed. :D (Or LaTeX, or just about anything on *nix)
I may not like Windows a whole lot, but I do make it my business to use it as efficiently as I can. Naturally, this means that I spend a good >=3/4 of my time using FL/OSS on it. ;) I can't imagine how much time I'd waste without Perl, cygwin, vim, Firefox, PuTTY, WinSCP, & co. -
Good article
Check out this article for a good intro to Plucene, the Perl port of Lucene.
This is also a good link for all of you slashdotters who have no idea what Lucene is for and are posting rants wondering why people don't just use Google instead. -
Re:Moving from Perl (slightly OT)
Ruby on Rails if you want to switch, Catalyst if you're comfortable with perl and don't want to switch. There are excellent introductory articles on the O'Reilly web site for both of them.
-
Perl6 is closer than you think
check out "http://pugscode.org/"
for a working perl6 compiler. Yeah, it is not yet feature complete, but progress is very rapid.
Perl6 is really amazing. It removes most of the worst parts of perl5 and make things even easier on the programmer. If you do an research at all you can find that.
Some people are even starting to port important CPAN modules to perl6 and discovering how much a pleasure it is to use.
see http://www.perl.com/pub/a/2005/07/28/test_builder_ p6.html
as an example of that.
btw, check out the example code. for all of you who think perl5 looks like static on a tv screen, you will be pleasantly surprised I think.
peace -
Perl 6 macros
Perl syntax is absolutely awful, and that's the reason Perl will never have macros
According to Synopsis 6, Damian Conway and Allison Randal's summary of Perl 6's "Subroutines and Other Code Objects":Macros are routines whose calls execute as soon as they are parsed (i.e. at compile-time). Macros may return another source code string or a parse-tree.
Having once upon a time built an application based almost entirely on IBM System/360 Assembler macros, even Perl < 6 syntax is a breeze in comparison.
Despite the prevailing "wisdom" of those who have become impatient with the Perl 6 project, it is meant for the long term and I suspect its strong linguistic roots might enable us to start looking for meaning in text, and that might be a reasonable candidate as a future disruptive application technology.
Presumably that scenario would require a stronger mix of automated and by hand programming, which Perl 6's macros should facilitate. -
MVC?
I think the most promising thick-client app development model is the Model-View-Controller paradigm, as seen in such well-designed app frameworks as Cocoa for OS X, and of course Ruby on Rails, and although I see Skunkworks improving the "typical" drudgery of web-app dev, I would wonder what it provides in the way of code management when it comes time to test your controller without worrying about how the view renders it or the model stores it.
And I know this is a personal preference and all, but... Python's significant whitespace? Yuck... I hope you don't copy/paste much, you might forget a tab somewhere (not to mention, copying from webpages is an adventure in itself...) To me this is like drinking cider instead of beer. Why would anyone consider such a thing worthwhile? Just to avoid some begin/ends or curly braces?
Python does have a more complete library but I am pretty sure Ruby and friends are catching up (and of course, no real word on Parrot yet...) Ruby also just seems to do the whole object-oriented thing nicer (abbreviated getter/setters, everything is an object, no self-referential hacks or whatever...) -
What's all the hype?
Although I applaud Ruby at finally getting an MVC-based framework together, I don't see what all the hype is lately. MVC-based frameworks have been around for a long time, and MVC-based frameworks in other OSS languages have been around since RoR came to be as well.
Java has Struts and others, Perl has an excellent Framework called Catalyst based on another MVC framework by Simon Cozens called Maypole - see Jesse Sheidlower's article on O'Reilly for building an AJAX-based framework in 30-lines of code or less in Catalyst. PHP even has one that's been out for awhile called Fusebox that is based off of another for Cold Fusion. What is it that is so special about Ruby on Rails?
-
Re:Don't count the pros out. (off topic)
Hi, Lee.
Yes, that's me. Do I know you / were you a classmate of mine? The 'main Lee' I remember from those days I mainly did appmath (computational simulations) courses with. I think he went to UW for his PhD.
If you're interested in more of the 'YAPC story', I did an interview with Perl.com here: http://www.perl.com/pub/a/2005/05/12/rdice.html
Cheers,
Richard -
for the grammer nazi's
I forgot to preview.
Okay, and Perl has Catalyst coming. Now everybody's pet language has it's own rapid development platform. Can we move on now? -
What's old is new again
Ok, and perl has catalyst coming. Now everybodies pet languages have their own rapid development web platform. Can we move on now?
-
Re:Seconded!
Pugs really hasn't implemented the whole language, but it's possible to write useful, practical, usable Perl 6 programs with it. (See Porting Test::Builder to Pugs, an article I just wrote about my experience doing so.)
I think I'm pretty good at Perl 5, but Perl 6 is amazingly nicer.
-
Re:waiting for MS's perl.NET to be released!
I suppose if it were Perl 6, it would be funnier, because the parrot virtual machine is atttempting to do a few of the same things as CLR. http://www.perl.com/pub/a/2002/03/19/dotnet.html
I made this attempt at humor about Python and Perl flamewars, which started early here, because both groups tend to also be "open source" purists, and I find it funny that evil empires' borg-like platform embraces both languages. I also noticed that despite having the book, you don't claim to be using it! ;-) -
Do these people need to munge data?
I'm guessing some of the people you'll be talking to are spreadsheet junkies. Often such people have requirements that can't be met easily by a spreadsheet but would be easy to do in a script (eg: munging data from text files into CSV so they can get it into a spreadsheet).
My Sprog project is targetted at exactly that type of user, the project catch phrase is "Scripting for the GUI Guys". It's a friendly GUI environment in which a user can drag and drop reusable components to 'build' a script rather than 'write' a script.
This article gives some hint of what's possible (and has pictures too).
At this point, a GNOME desktop on Linux would be the best demo platform, but Windows support is coming.
-
Perl6 is a mistakeI've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goat.cx. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.
-
Write it yourself using Perl and IE
I've seen a lot of comments mentioning you should write a testing tool yourself. If you decide to do this, maybe this article could be useful; it talks about automating IE using Perl scripts.
-
Two good sources
Thought I'd mention two sources for this that I think are worthwhile.
The first is a great article about what the differences between mainframe programers and Unixy programmers. The second is a book designed to teach mainframers to operate in a Unix environment. The article is definitely worth a look for anyone interested in this topic. -
Semi-OT: Catalyst is the Perl equivalent
Check it out, it's based on Maypole, but now forked off and is under heavy and fast development.
There's a short introductory article on perl.com. I quote one paragraph from this article, that gives a good overview on Catalyst:
Catalyst is a new MVC framework for Perl. It is currently under rapid development, but the core API is now stable, and a growing number of projects use it. Catalyst borrows from other frameworks, such as Ruby on Rails and Apache Struts, but its main goal is to be a flexible, powerful, and fast framework for developing any type of web project in Perl. [...]
It's semi-OT cause it supports AJAX and uses Prototype as its Javascript library.
Bye egghat. -
Re:Is Mason there yet?OK, I'll bite.
Mason rocks. It's got the "scripting language in a web page thing" which can be great, especially if you modularize your code so not too much is happening inside the Mason code. On the other hand, it's quite easy to write spaghetti of code and HTML, so PHP programmers should like it too.
Mason also has good control over execution phases - you can do things "once", "first", etc. Arguments are named (not positional), can be made optional, or given defaults - and this is easier than you can imagine (if you don't know why this is a good thing, you haven't done very much programming). You can also pass a Mason "component" formatting from the "outside" and let the "inside" take care of other logic. It makes caching things (like, say, a list of articles pulled from a database) as easy as it can possibly be (even worse than not pooling DB connections is not caching results when you can). It generally pushes you in the direction of good solutions.
Check this article on Catalyst, too.
But having used PHP, JSP, Perl with other templating systems, I prefer Mason by far. Mason uses Perl - no mini-languages here - and gives you access to the huge amount of stuff on CPAN - PEAR isn't there yet and won't be soon (and Java never will be).
-
Re:I'm the pimpking for our product!
I see that the glorious art of asking the google first is nearly abandoned.
Here's the first hit: http://www.perl.com/doc/manual/html/Porting/pumpki n.html#Why_is_it_called_the_patch_pumpk. -
Re:PHP vs JSP
Back in the days, say a few years ago at least, getting JSP and Servlets up and running was a pain, even if you knew and used Java already, and had it installed. And then it was a pain configuring it all. PHP, as I remember it, has always just worked, with ease. No, I don't know how the status is today, and since I don't miss Java I don't need to know. Back then this was important though.
After all that was done, well then it was up to if you liked Java or not. And I've come to realize that Java is a language you either like or not, rarely any in-betweens. I came from Java, so in order to use PHP I'd have to learn a new language, granted it is not hard - and maybe that is the point. PHP is easier. It is not guarded by a lot of "safety syntax", but really, that usually isn't needed. Java is quite powerful, but it is also very verbose and does things the long way around, or at least it did.
I still use PHP now and then, if rarely, but right now I'm looking into Catalyst which seems really promising - it's inspired by Ruby on Rails and Maypole, among other things, but for Perl. I really wish there were some more examples and example applications to look at though, the documentation is pretty good (and there's always the source), but too see how it all should fit together, I'd like to see more from people already grokking it. I've been reading the mailing lists, this perl.com article and some other things, but that is what I am missing.
Perl has become the favourite language. It has CPAN (if Ruby had that on the same level, it'd probably be Ruby). It can do anything, and it doesn't get in your way. It also attracts lots of jokes about readability but that's just people who haven't actually made a serious try to understand. -
FYI
I happen to work with several people who were there. For a good overview of their website, see this article on how it scaled.
As for going out of business, when you have debts and no revenues to pay them, you don't get much of a choice about staying in business. The year before they died they got killed because they didn't have enough inventory. They overcompensated and overinvested in warehousing. Their next Christmas showed solid growth, but was not nearly good enough to stay afloat. Nobody was willing to inject the necessary cash. They had tons of inventory that nobody would buy for a year (if ever for fad products) whose manufacturers didn't want it back.
If the choice was theirs they would have stuck it out. At that point they had no choice. -
Re:etoys
Nope, you should read up on this article by Perrin Harkins and Bill Hilf: http://perl.com/pub/a/2001/10/17/etoys.html?page=
1
eToys was a very large Linux and Open Source environment - I use to consult for eToys - and Hilf was the man leading the engineering efforts there. -
same goes with Perl!
-
Re:Not necessarily comments...
That was MJD's POD is not Literate Programming.
-
Users like you give Apple a bad name.
A major factor in my switch to Macintosh as my primary platform was that I could run both perl and Excel on the same machine.
So you're able to install Excel, but being unable to download and install Perl drove you to the Mac? What business do you have evangelizing that platform? Choose your poison:
* Activestate Perl
* Cygwin
Two completely different ways of getting Perl on Windows.
Maybe if more geeks played with the spreadsheets we could come up with best practices to hand over to the PHBs.
This is entering the realm of a technical artist - somebody who knows something about the underlying math, but also has a good eye for presentation.
It has been over a decade since the last innovative new spreadsheet - Lotus Improv. Time for something new.
I agree that Excel is ancient, but there are still modern newcomers like Gnumeric or OpenOffice? -
Re:Whats Bricolage?
all in all, aren't there better things to be doing?
Perhaps, but I've been doing this for four years now. Read my article introducing Bricolage and comparing it to other CMS solutions to learn more about how it's different
--Theory
-
Gifts
-
Re:Ebonics?
And how about computer programming's version of ebonics, scottish and everything other dialect with a latin character set? Perl moves like a pyroclastic flow.
-
perl6 is not a mistake
Well, I can tell you have some pretty strong feelings on this subject. I'd just like to add a few comments from my perspective as another long time Perl user...
Let me start by saying that I've read all of the perl6 documents with great interest and have almost universally been pleased with the changes that are being made. In all cases, I appreciate how most of the decisions are being made and that the concepts of useability and clarity are taken as important overarching goals. As an example, if you actually read apoc 5 which you linked to as an example of "smoking crack", you'll see that one of the main goals is "better huffman coding" - ie: making frequent tasks easier to express than infrequent tasks and that another is to make regular expressions more readable and maintainable and less like line noise. These, to me, are eminantly admirable goals in a scripting language.
On OO, Note that Perl6, unlike Perl5, is being rewritten with OO at its core, not as an expansion to the previous "nasty hack".
Note also that the perl6 team shares many of your issues with perl5's OO implementation and wants perl6 to be better: Apocalypse 12.Similarly, when you complain about $,@,% and how confusing they are, you seem to be complaining about perl5isms that perl6 is dedicated to addressing...
In answer to your length of the keys array of a hash question, just use (keys %hash) in a scalar context, or (keys %hash).length. In your specific case, because the hash in inside another hash, you're looking at something like (keys $hash{"key"}).length;
... which doesn't seem particularly brain melting to me, especially compared to perl5. I also don't see this threatened horde of new datatypes you seem so angry about. I really recommend that people interested in what these differences will bring read the Exegesises, where equivalent perl5 and perl6 code is usually compared."const int $var = 27;" ? Did you mean something like "my int $var is constant = 27;"? What specifically do you mean when you say that it isn't entirely constant or entirely an integer, and why does it matter?
I completely have no understanding of why perl6 would please "the managers" or what this "one thing that makes perl5 special" is that you think is being lost. As far as I can tell, perl6 keeps everything that I thought made perl5 special and aims to clean up many of the things that make it a PITA.
"It can't do what it wants to do whilst still being based upon a nasty mess." Isn't that why perl6 is a complete rewrite? What unholy mess are you referring to? From your post, I don't believe that you're one to be swayed from your beliefs, but many of your arguments appear on the surface to be based more on emotional response than factual backing...
-
perl6 is not a mistake
Well, I can tell you have some pretty strong feelings on this subject. I'd just like to add a few comments from my perspective as another long time Perl user...
Let me start by saying that I've read all of the perl6 documents with great interest and have almost universally been pleased with the changes that are being made. In all cases, I appreciate how most of the decisions are being made and that the concepts of useability and clarity are taken as important overarching goals. As an example, if you actually read apoc 5 which you linked to as an example of "smoking crack", you'll see that one of the main goals is "better huffman coding" - ie: making frequent tasks easier to express than infrequent tasks and that another is to make regular expressions more readable and maintainable and less like line noise. These, to me, are eminantly admirable goals in a scripting language.
On OO, Note that Perl6, unlike Perl5, is being rewritten with OO at its core, not as an expansion to the previous "nasty hack".
Note also that the perl6 team shares many of your issues with perl5's OO implementation and wants perl6 to be better: Apocalypse 12.Similarly, when you complain about $,@,% and how confusing they are, you seem to be complaining about perl5isms that perl6 is dedicated to addressing...
In answer to your length of the keys array of a hash question, just use (keys %hash) in a scalar context, or (keys %hash).length. In your specific case, because the hash in inside another hash, you're looking at something like (keys $hash{"key"}).length;
... which doesn't seem particularly brain melting to me, especially compared to perl5. I also don't see this threatened horde of new datatypes you seem so angry about. I really recommend that people interested in what these differences will bring read the Exegesises, where equivalent perl5 and perl6 code is usually compared."const int $var = 27;" ? Did you mean something like "my int $var is constant = 27;"? What specifically do you mean when you say that it isn't entirely constant or entirely an integer, and why does it matter?
I completely have no understanding of why perl6 would please "the managers" or what this "one thing that makes perl5 special" is that you think is being lost. As far as I can tell, perl6 keeps everything that I thought made perl5 special and aims to clean up many of the things that make it a PITA.
"It can't do what it wants to do whilst still being based upon a nasty mess." Isn't that why perl6 is a complete rewrite? What unholy mess are you referring to? From your post, I don't believe that you're one to be swayed from your beliefs, but many of your arguments appear on the surface to be based more on emotional response than factual backing...
-
perl6 is a mistakeI've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. It's like Ada all over again! The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.
-
English module
I avoid using $_ and other magic variables because, while they are useful when writing the program, they are a kick in the head when reading the program a month or two later.
Have you tried the built-in English module? Just add this line to your script:
use English;
Then you get verbose aliases for the magic variables. So $. becomes $INPUT_LINE_NUMBER, $" becomes $LIST_SEPARATOR, etc.
A complete list of the aliases can be found here. -
What about the Artistic License?My understanding was that the Perl Artistic License was originally crafted to address the problem of businesses who were "afraid" of the GPL.
I'm not as current on licensing issues as I used to be, and perhaps this post will show that (too much) but the artistic license seems historically important; I can't right now find the post/statement from Larry Wall that I remember reading oh, so many years ago about why he devised it. But the spirit of it -- of making
something that had originally been GPLd work for those who were wary of GPL; of dual-licensing under the AL and the GPL, of furthering the spread of Perl at a time when there wasn't nearly as much OSS code around... It seems like some similar variation should still be able to work today. (Apparently "some variations" are underway -- scroll down to "License of Perl" on this FSF page to read more). See also AL considered ambiguous
In any case, perhaps something like the AL is what those who wish to have a "commercial version of the GPL" actually mean. They should follow their own advice, and choose either Public Domain, a BSD-style license, or the Artistic License as their "commercial GPL" rather than invent yet another new one.
-
Re:mono
What are you on about?
That's not a dead Parrot! That's a kickin' chicken.
It's the (presumably innocent) misinformation that wreaks so much havoc... -
Re:Um, dude.
Here's instructions on how to draw information from del.icio.us
Here's perl
Write your own interface, bitch. -
TMTOWDI
Perl has its own rapid application development framework, Maypole. Here are some screenshots from a Perl.com article where Simon Cozens sets up an online sales catalog in 11 lines of code. (Here's a followup article, and the Maypole home page.)
These systems all demo well because the developer gets to decide what functionality to demo, and it not coincidentally happens to be the functionality the framework was designed to easily support. The real test of the system comes when you want to do something the designer did not anticipate, and you find out how flexible the system is and how sensible the designer's instincts are.
With these environments I think time will tell, with most developers watching the few willing to take the risk of investing the time needed to learn the framework and how to customize it extensively. -
But...
But we already have an extensible language.