Re: What are Perl 6's killer advantages over Perl 5?

[Fagyal Csongor]

Hi,

On Tue, Aug 11, 2015 at 07:12:00AM -0500, Tom Browder wrote:

I have seen several lists of new Perl 6 features (versus Perl 5) but they
all seem to be lists that intermix features with varying degrees of value
to "ordinary" Perl 5 users.  If one wants to sell long-time Perl 5 users
(already using the latest Perl 5, Moose, etc.) on the value of Perl 6, what
should be on the important feature list?

For me, stronger typing, named subroutine arguments, better classes and
namespaces, object methods, and eventually better concurrency and compiled
program persistence are among goodies long awaited.

Thanks.

-Tom

The reason for my request is to help with a better introduction in my
modest draft tutorial on converting Perl 5 to Perl 6 code at the Perl
Monastery.  I am comfortable with the example code I use there (which is
not currently intended to showcase new features), but I am getting several
comments on why one should even bother with Perl 6?

In talking to Perl 5 people about my Perl 5 to Perl 6 docuentation,
trying to get some feedback on it from people who aren't already doing
Perl 6, I get this question a lot. So, yes, some kind of document saying
"these are reasons Perl 6 is actually useful" would be very helpful.

Just make them look at Perl6 source code. E.g. on rosettacode. Someone 
who doesn't see how wonderful Perl6 is, is a lost soul anyway. :)


- Fagzal

Re: rakudo-current loop 2-3 orders of magnitude slower than perl 5?

[Fagyal Csongor]

Hi,

I think featurewise Rakudo is now at a point where it could already be 
use for some serious work. Surely many things are missing, but (for me) 
the two most important things - good OOP support and types - are already 
in. And the syntax is just lovely :) (I think I have a syntax-fetish... :))


However, performance is an issue. I would not mind running into bugs, 
writing some extra code to work around missing stuff, etc., but right 
now it is just hard to find any projects (for me - YMMV) where 
performance would not be a blocker. Right now the only thing I can use 
Perl6 for is to learn Perl6, and that's a problem, because when I sit in 
front of a computer, learning is the only thing I do not get paid for :)


For a long time, people I talked about Perl6 all feared that it would 
never be ready. Now concern shifted to "will it ever be fast enough?" 
And I think it's not really about Rakudo, but about Parrot. 
Unfortunately I am not a Rakudo, neither Parrot hacker, but as I 
understand, there are features in Rakudo which are implemented using 
only a few lines of code. You cannot gain 100x speed difference 
optimizing, say 7 lines, so I must assume it really is Parrot which 
needs a lot of love, and there aren't too many people who can/could hack 
on Parrot. That sometimes feels scary.


I very much agree with Patrick: an order-of-magnitude speed difference 
compared to Perl5 is kind of the point where many will just stop caring 
about performance and start using Rakudo/Perl6. Actually I expect a 
significant increase in the number of new Perl6ers at around < 100x 
slower. (That, and the 10 "most important" Perl5 CPAN modules ported to 
Perl6 :))


I think it would be nice to have some sort of a performance-tracking 
page, with just some very basic Perl5 / Perl6 code and very rough 
measurements. If noone will do that, I will :)


- Fagzal

Re: RFD: Built-in testing

[Fagyal Csongor]

Hi,

I pretty much like this idea. Very perl6ish :)

- I don't think it's important whether it is called :ok, :OK or :test or 
:wellhowdidthatworkout. I assume people who will be testing their 
modules/code/etc. will be using more advanced modules for testing 
anyway. This is for testing the implementation against the specs, and 
they *will* know how it works :)


- I don't think we should be concerned whether to implement :ok is 
difficult. Implementations in early stage are totally broken anyway :), 
they won't even *parse* the tests well - they will have have their own, 
limited tests. Later they can chose to do some magic to make :ok work... 
and finally implement it.


- I like "ok" better than "test", as the former kind of implies a 
boolean "was that true?" to me. YMMV, though.


- Fagzal

Re: Perl 6 fundraising and related topics.

[Fagyal Csongor]

[...]


I was there at the workshop too. You cannot count me in into being biased
against Perl 6. Only biased that it takes so long :-).
   



I know, and there were some others (like Herbert aka lichtkind, who writes
and maintains the German Perl 6 wiki pages) with the same opinions.

But the general atmosphere there was rather anti Perl 6, and the recent
discussions on the wsinfo mailing lists show that all too clearly.
 


It's really not a surprise. Perl5 is not "broken": IMHO many Perl5 programmers just 
wanted some "little" (erm...) things like a less hacky OO implementation, better function 
parameters and types, things like that. Perl6 promised these and much-much more, so people were 
happy. There were news, ideas, Parrot hacking, etc... and people got bored. Basically nothing 
happend for *years*. That is: many things happened, there is a nice specification now, brilliant 
features, etc., you all know - but for Average Perl Joe, there is just nothing there. Average Perl 
Joe needs this:

perl6 hello_world.pl

That's why I am rooting for rakudo: there is progress, or so I figure, and I can "ln 
-s rakudo perl6" anytime :) Once you can point people to some targzipped source or 
an RPM or something like that, and 10 minutes later they can indeed write the above line, 
they will not be anti-Perl6 anymore. (I mean if they will be anti-Perl6 after that, then 
we can just close this list and everyone can just go home.)

- Fagzal

Re: Perl 6 fundraising and related topics.

[Fagyal Csongor]

[...]


Should it really? I mean: is the time right for that now?
   



Let's ask the other way round: Is this the time for only one
implementation? And who decides that it's the one based on parrot?

What happens if parrot turns out to be a dead end? (very unlikely, but
possible).
 

Let's give some $$$ to say 3 implementations, see what they come up in a 
month. Lets mupltiply their 1/CPU-time with #of tests passed :), and the 
winner gets the rest of the money.



It's really hard to define what the community wants: noone can speak on
behalf of the whole community (and the community has many ideas about
things :)) However, and strongly IMHO, what most Perl users want is very
simple: to have a not-too-slow Perl6 implementation that runs most of
the current Perl6 specification - without too much bugs.
   



I also think that many perl people also want a good Perl 6 specification.
 


I agree.

On the other hand, I would be very happy if current implementations 
could pass 25% of the current specification.



And different implementations help to explore different part of the specs.
That also helps rakudo, if the specs are well covered by other
implementations and are therfore much stable and really implementable.
 

How about sponsoring some implementations, but give "special attention" 
to the most promising one?



If you argue that most people want an implemenation that covers large
parts of the specs, the most logical step would be to boost pugs
development. It's the most advanced implementation by far.
And I do believe that it can be sped up if you really want that.
 

I don't know Haskell and the structure of Pugs so I cannot comment on 
that - however, I have some doubts. And speed *is* important: I don't 
think we can expect people to start using Perl6 if it runs even 2x 
slower than Perl5. If Pugs was really up-to-date (I mean: feature 
complete), only slow, I would probably use it to learn Perl6, because 
Perl6 is just lovely. I would not build something on it, though.



So where's that pro parrot bias coming from?
 

IMHO people like the idea of Parrot. It just.. makes sense. It's been 
around for quite a while. There are releases every month or so. There is 
a mod_parrot. These things.



Surely it is very nice to have many implementations (we have seen how
much helpful the Pugs project was to help Perl6, for example), but could
that happen (or: be sponsored) *after* we have *one* that is fairly
complete?? After some time, one imlementations will emerge and become
*the* implementations anyway.
   



Oh will it? Just like we have one C implementation? Or one Forth
implementation? Or one Lisp implementation?
 


Can we add PHP and Perl5 to the list? ;)


What I would like to add is that IMHO this time implementators should be
sponsored. That is: those who hack and those who answer their questions
on how to hack. :)
   



Aye.
And perhaps the ones who write the specs, if they want/need it.
 


I meant that, too.


I also think that different Perl groups all around the world could be
responsive. Let's contact the gazillion perl lists and say: "...if you
like Perl, please give $10 to the \"Let's have Perl6 now!\" foundation!"
I would, and I will personally send anyone to /dev/null who would not! :)
   



I don't know if that's a good idea - sadly many of them have the
perception that Perl 6 is vapour ware.
 


I guess I have more trust in people than you do. :)

I know that the company I work for would never give a dime to any 
foundations, but I would. And I *own* that company :) That's because a 
company is always a business, but a person can be an enthusiast.


Anyway: I don't know anything about fundraising, so maybe I shouldn't 
say a thing... I just say it might worth a try. People would help to 
convince other people. Once again: I would.



My idea would be to ask big companies that use perl (for example amazon)
if they would sponsor some of the development.

Are there other organisations that routinely sponsor open source software?
 

Can't we just go to Google and say we will use Yahoo if they don't give 
us some money? :) And if they don't, we tell everyone! ;)


How about just looking at the sponsor logo-s on the webpages of 
different OS conferences? There should be plenty, and could give some 
ideas. (But there really should be something you can *show* to them. I 
mean at least *one* webpage on Perl6 which is not outdated :) ) YAPC 
organizers should have some ideas, too.


- Fagzal

Re: Perl 6 fundraising and related topics.

[Fagyal Csongor]

[...]


To that end, I'm soliciting:
(1) your suggestions for preparation,
(2) your ideas for proposals, and
(3) your reasons why the Perl 6 ecosystem (including Parrot
   and CPAN6) is one of the world's greatest and and most
   extremely leveraged causes (technically, economically,
   and socially).

I'll also put whatever fundraising-oriented material I come
up with on the Perl 6 wiki, to help and encourage others
along similar lines.
   



I'd like to raise the question what to do with the money, assuming that
you can acquire some.

I see two possible route:

1) Let The Perl Foundation decide what to do with the money
advantage: they already have a comitee (is that really an advantage? ;-)
disadvantage: they seem to think that Perl 6 on Parrot is _the_ and the
only way to go. (There's nothing wrong with rakudo and parrot, but Perl 6
is, by definition, a language. And it should have multiple
implementations)
 


Should it really? I mean: is the time right for that now?

It's really hard to define what the community wants: noone can speak on 
behalf of the whole community (and the community has many ideas about 
things :)) However, and strongly IMHO, what most Perl users want is very 
simple: to have a not-too-slow Perl6 implementation that runs most of 
the current Perl6 specification - without too much bugs. Maybe the Perl 
Foundation got some people who can decide what we need to achieve that - 
someone must make a decision where the money should go anyway.


Surely it is very nice to have many implementations (we have seen how 
much helpful the Pugs project was to help Perl6, for example), but could 
that happen (or: be sponsored) *after* we have *one* that is fairly 
complete?? After some time, one imlementations will emerge and become 
*the* implementations anyway.


What I would like to add is that IMHO this time implementators should be 
sponsored. That is: those who hack and those who answer their questions 
on how to hack. :)


I also think that different Perl groups all around the world could be 
responsive. Let's contact the gazillion perl lists and say: "...if you 
like Perl, please give $10 to the \"Let's have Perl6 now!\" foundation!" 
I would, and I will personally send anyone to /dev/null who would not! :)


- Fagzal

Re: pluralization idea that keeps bugging me

[Fagyal Csongor]

Hi,

Warnocked!

Indeed :)
I posted an idea about pluralisation could be handled in a way that 
would not be English-centric (Subject: interpolation 
contextualisation). There were no responses to the idea. Was it so 
bad? Did no one see it? Was it too un-perlish? Was the title too 
horrible?


The basic idea would be to add hooks into interpolation to allow for 
context suppliers and context sensors. The context sensors change 
words depending on data supplied through context suppliers.


Note that even in English, if you change a noun from singular to 
plural, you need to change the verb from singular form to plural form.
First of all, I think a module like this should be either perfect or not 
exist at all: you won't use it after it makes the first mistake, or when 
you cannot use it everywhere.
Now, to have a perfect module you need some pretty smart people to 
create the base lib (dealing with natural languages is not a piece of 
cake). Then you need a bunch of other people who understand what's going 
on to to create and test the different language versions. I fear that at 
the end you end up with a huge codebase, created by various people, 
parts of which get out-of-sync or become unmaintained, and which 
generally consumes a lot of memory (think about e.g. dictionaries for 
irregular words - take a look at Lingua::EN::Inflect, for example) when 
used, and also slows down execution. All this to save one 
not-very-often-used "if... else" block. If we really want to help people 
type less, why not just rename "else" to "e" ? :)


It also seems to me that I will need a module like this when my computer 
does not only *ask* where I want to go today, but also *cares*. ;)


So IMHO while it's a nice idea, it's just an overkill. (And it's 
definitely not about Perl6 as a language.)


- Fagzal

Re: pluralization idea that keeps bugging me

[Fagyal Csongor]

Amir E. Aharoni wrote:

On 26/01/2008, Larry Wall <[EMAIL PROTECTED]> wrote:
  

After a recent exchange on PerlMonks about join, I've been thinking
about the problem of pluralization in interpolated strings, where we
get things like:

say "Received $m message{ 1==$m ?? '' !! 's' }."

...

Any other cute ideas?



No matter what you do it will remain too English-centric. It might
work for Catalan, too. But it will remain totally useless for Arabic
or Chinese.

In any case, i don't understand why should this be in the core language at all.

I second that.

A few more thoughts:

1. For example in Hungarian, you don't need this at all: the noun stays 
singular after the numeral.


2. AFAIK in some languages it's not "1 ore more", but "1, 2 or more".

3. It's often not "1 or more" what you need, but "none, 1 ore more". "No 
new messages - You have 1 new message - You have 3 new messages." Or 
more likely "Now new messages. - You have 1 
new message. ..." etc.


4. I work a lot with multilingual websites. I have learned long ago that 
it's never "{{you_have}} [% messages %] {{messages}}." You have to be 
*very* lucky just to make this work in two languages. Instead, it's 
"{{number_of_new_messages}}: [% messages %]." That pretty much works 
everywhere.



So not in the core, probably. There are too many exceptions. A module 
would be cool, though :) String::Plural::English, or whatnot.




- Fagzal

Re: xx operator

[Fagyal Csongor]

A. Pagaltzis wrote:


I have the following code:

class MyStupidString {
   method repeatit(Str $string, Int $repeat) {
   say $string xx $repeat;
   my $add = $string xx $repeat;
   say $add;
   }

};

my $obj = MyStupidString.new;
$obj.repeatit("---",10);



Interestingly, it says:
> pugs test2.p6
--
--- --- --- --- --- --- --- --- --- ---


What am I misunderstanding here?
   



The `xx` operator. That's list-repeat, not string-repeat.

In Perl 5 terms, the code you wrote is:

   sub repeatit {
   my ( $string, $repeat ) = @_;
   my @res = ( $string ) x $repeat;
   print @res;
   my $add = "@res";
   print $add;
   }

which should make it obvious what is going on.
 


Thank you and Juerd.

It was indeed a misunderstanding, I though "x" changed to "xx" in Perl6 
for some reasons...



Now is the first time I write some Perl6 code that I actually run, too 
:) It is *really* enjoyable. Feels like "this is how Perl should really 
look like", and it is so DWIM I can hardly believe it. Kudos to all who 
helped to make it happen!


- Fagzal

xx operator

[Fagyal Csongor]

Hi,

I have the following code:

class MyStupidString {
   method repeatit(Str $string, Int $repeat) {
   say $string xx $repeat;
   my $add = $string xx $repeat;
   say $add;
   }

};

my $obj = MyStupidString.new;
$obj.repeatit("---",10);



Interestingly, it says:
> pugs test2.p6
--
--- --- --- --- --- --- --- --- --- ---


What am I misunderstanding here? Or is this a Pugs bug?

I am using pugs 6.2.12

- Fagzal

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[Fagyal Csongor]

Randal L. Schwartz wrote:


""A" == "A Pagaltzis" <[EMAIL PROTECTED]> writes:
   



"A> * Randal L. Schwartz  [2006-09-20 19:30]:
 


"Fagyal" == Fagyal Csongor <[EMAIL PROTECTED]> writes:
 


yet I never needed those HTML generating methods.
   


You've never made a sticky form then.
 



"A> False dilemma. You can create sticky forms conveniently without
"A> using CGI.pm’s HTML generation stuff. You can use HTML::Template,
"A> HTML::FillInFrom, HTML::Widget, CGI::FormBuilder… should I go on?

"A> C’mon merlyn, you’ve been around long enough to know about CPAN
"A> and realise that your statement is transparently fallacious.

However, HTML::FillInForm, HTML::Widget, CGI::FormBuilder were *not*
in core.  CGI.pm was.  One stop shopping.  Easy to describe to people.

We need the same thing for Perl6: "If you're going to do simple web stuff,
please use MUMBLE module".  And MUMBLE better have tight integration of param
processing and sticky form generation, as well as good header generation for
cookies and redirects.  In other words, at least two thirds of what CGI.pm
does for me now.  And MUMBLE better be included *with* Perl6.

Without that, people will *hand code* that stuff, and get it wrong, and we'll
get the reputation of Perl6 being horrible for the web.


I am in favour of different bundles. Then you can, for example
yum install perl6-base
or
yum install perl6-web
or
yum install perl6-everything

You know what I mean. The diff between perl6-base and perl6-web is a 
bunch of (CPAN6) modules.


- Fagzal

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[Fagyal Csongor]

Randal L. Schwartz wrote:


"Fagyal" == Fagyal Csongor <[EMAIL PROTECTED]> writes:
   



Fagyal> As a side note I also have to add that I really dislike the
Fagyal> "html-functions" CGI.pm currently has. Creating the representation is
Fagyal> the task of the designer, not the programmer. It's almost like "echo"
Fagyal> in PHP :))) I used CGI.pm with simple cgi scripts, with Apache::ASP,
Fagyal> mod_perl and FCGI, I used CGI::Cookie, etc. yet I never needed those
Fagyal> HTML generating methods. To me, it feels wrong that they are
Fagyal> there.

You've never made a sticky form then.


Erm... what makes you think so?

Not with CGI.pm, but I use HTML::FillInForm for the basic cases (which 
is simply a per-page config parameter in my framework, and which has the 
advantage of using simple HTML markup without any coding), and my own 
module (PET::Filter::UtilXmlMap) for more comples cases when forms are 
pre-populated from DB. E.g.:




(Note: this generates [% Util.ehtml.bodySelect('array', subst.pages, 
'name', 'page', selected, QUERY.page %] at compile time.)


I think JSP tag libraries had a too strong effect on me :)

- Fagzal

Perl6 "style-guide"

[Fagyal Csongor]

Hi,


I was wondering if there is (or there should be) a documentation on how 
to elegantly write Perl6 code.


I am afraid that when I will be starting to write Perl6 code, it will be 
too much Perl5-ish, and I will end up rewriting my code in every 3 
months because I hate when my code is not elegant (at least to my own 
standards).


I was wondering that some - maybe @Larry - already have (mosf ot) Perl6 
in their heads, so they could create such a document/recommendation 
before Perl6 gets used widely, and the coding style gets "distorted".


Or shall we just leave this to the community? Maybe this documentation 
shouldn't/can't be written yet? Shall we let Perl6-style grow from usage 
in 1-2 years, and create a guide like this then, when things mature?


- Fagzal

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[Fagyal Csongor]

Juerd wrote:

[...]


Fagyal Csongor skribis 2006-09-20 15:43 (+0200):
 


Inefficient was probably a bad choice of word.
I would rather say: I would not like to see Perl6's CGI.pm as a monster 
module, which has one part everyone uses, and one hundred other parts 
that some uses, because I feel those parts should be put into other 
modules.
   


Perl 6's Web toolkit, even with all these classes, is likely to be much
lighter than Perl 5's CGI.pm with :standard.
 


I guess that's one of the reasons we are heading from 5 to 6 :)


But note that especially if it is a well designed bundle of
classes/roles, you can pick exactly those things that you need, and
leave all others out. That's part of the reason why you should separate
things. 


And here is another reason :)

[...]


If we talk about nicely structured OO, I can see a few ways:
- CGI.pm include something like "CGI::HTML", to get rid of the HTML 
generating part, or maybe even separating CGI::HTML and CGI::Request
   



s:g/CGI/Web/, please! mod_perl has nothing to do with CGI (except
perhaps for its compatibility syntax), and neither does HTTP::Daemon. We
should write generic code, suitable for any implementation.

I'm thinking of:

   Web::Init::CGI  # Initializer for CGI requests
   Web::Init::FastCGI  # Initializer for FastCGI requests
   Web::Init::ModPerl  # Initializer for ModPerl requests
   Web::Request# Request objects
   Web::Response   # Response objects
   Web::Session# Session objects
   Web::HTML   # HTML generation
   Web::Util   # HTML-entities, URI-encoding, etc
   Web # utility module that mostly loads other modules
 


Hmmm.

A very sound idea. Reorganising the CPAN namespace :) (This 
CGI/HTTP/LWP/HTML/etc. got a bit confusing as it grew.)


I would say, maybe add "Web::Tools::*" so that others can add various 
useful (and not that useful) modules without mixing up everything.


And maybe expand Web::HTML something like:
Web::Markup::HTML
Web::Markup::XHTML
Web::Markup::WML
etc...
But that's might as well be too much.

So is Web::Init::* class supposed to be selected by Web, and 
Web::Init(::*) used by e.g. Web::Request & Web::Response, so it all 
becomes transparent?



Yes. I'm talking about a web development toolkit, that does at least
what CGI.pm did, and not about CGI as a namespace, because I think
that's an incredibly bad thing anyway.
 


I absolutely agree.

- Fagzal

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[Fagyal Csongor]

Erm...

Sorry for the bandwith usage again, but what about something like

class CGI
 is CGI::Base
 does CGI::ParamParser
 does CGI::HTML
{ ... }

?

To make CGI.pm kind of backward compatible, but separates the layers.

(Please excuse my bad syntax/semantics.)

- Fagzal

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[Fagyal Csongor]

Juerd wrote:


Fagyal Csongor skribis 2006-09-20 11:28 (+0200):
 


You rarely do real HTTP handling when you use CGI.
   


You may not, but many people do a lot of these things.
 


Actually me, too. Not with CGI.pm, though.
I tend to use CGI::Simple for form/param parsing, Template.pm for 
template processing, LWP::Simple for... well, HTTP handling (kind of...) 
and so on and so on.



And when you don't, the datastructures are currently parsed and filled
anyway, so I don't know why you say it'd be too inefficient.
 


Inefficient was probably a bad choice of word.
I would rather say: I would not like to see Perl6's CGI.pm as a monster 
module, which has one part everyone uses, and one hundred other parts 
that some uses, because I feel those parts should be put into other 
modules.
I just feel quilty when I use (Perl5's) CGI.pm for such trivial tasks as 
parameter parsing. Feels like... say, using MIME::Lite for *sending* 
mail not *constructing*.
Or maybe... you know, I have a Windows XP installed at home. The one 
thing I use it for is to run dvdsrhink :)) That's a big price for 10G of 
discspace :)


As a side note I also have to add that I really dislike the 
"html-functions" CGI.pm currently has. Creating the representation is 
the task of the designer, not the programmer. It's almost like "echo" in 
PHP :))) I used CGI.pm with simple cgi scripts, with Apache::ASP, 
mod_perl and FCGI, I used CGI::Cookie, etc. yet I never needed those 
HTML generating methods. To me, it feels wrong that they are 
there.


A general, simple CGI handling module fits into 200 lines, including 
POD. Imagine like
   


That's not "CGI handling", that's form parameter parsing. CGI, and web
programming, is much more than that.
 

That I know :) That's what I do for a living :), for almost like 10 
years now. And I started with "cgi-lib.pl" :)  ...which makes me think 
"CGI.pm" should not do much more than that old horse.



But please see below.


You don't really need more.
   


I think you mean: "I don't really need more". Many people do need a
whole lot more, and CGI.pm does do a whole lot more.


My public domain framework's dispatcher class starts something like:

use strict;
use FCGI;
use Template;
use Template::Stash;
use CGI::Simple::Cookie;
use CGI::Simple;
use Config::General;
use Data::Dumper;
use Time::HiRes;
use Digest::MD5;
use PET::GCONF;
use HTML::FillInForm;
use LWP::Simple;
use MIME::Base64 qw/encode_base64/;
use PET::Filter;
use PET::Util;
use PET::Log;
use PET::CacheControl;
use Storable;
use Carp qw/croak cluck carp/;
use UNIVERSAL;
use BSD::Itimer;
use POSIX qw/setuid setgid/;
use BSD::Resource;

And that's just the dispatcher - the framework uses every third module 
from CPAN, so to say :) So I am also between those people who need a lot 
more - yet I think CGI.pm should only do parameter parsing.


But no, that is not correct. What I really want to say is that I have no 
problem with any parts of the original CGI.pm, *except for* the HTML 
generation stuff. CGI/Lite.pm is ~1200 lines. CGI.pm is ~7500 lines. And 
what is missing? From the man page of CGI::Simple:


"
  CGI::Simple provides a relatively lightweight drop in replacement 
for CGI.pm.  It shares an identical OO
  interface to CGI.pm for parameter parsing, file upload, cookie 
handling and header generation. This mod-
  ule is entirely object oriented, however a complete functional 
interface is available by using the

  CGI::Simple::Standard module.

  Essentially everything in CGI.pm that relates to the CGI (not 
HTML) side of things is available. There
  are even a few new methods and additions to old ones! If you are 
interested in what has gone on under the

  hood see the Compatibility with CGI.pm section at the end.
"


Just not in a
nicely organized set of classes.
 


If you put it that way, I can certanly agree.


It's unfortunate that it mostly lets the user handle headers that are
communicated through ENV, precisely because that's part of the CGI spec,
and not common to other kinds of web programming, so it's specifically a
job for a module called CGI.pm
 


It might give some useful other routines (e.g.  url encoding /
decoding, various ways to mix GET+POST, set content types more easily,
etc.), but other than that, it should be very lightweight and easy to
use.
   


I agree that things should be lightweight and easy to use. But in Perl
6, that doesn't mean that you should avoid nicely structured OO.
 


If we talk about nicely structured OO, I can see a few ways:
- CGI.pm include something like "CGI::HTML", to get rid of the HTML 
generating part, or maybe even separating CGI::HTML and CGI::Request
- now that I write it down, for me it feels more natural to have 
something like "HTML::CGI" :

 # imagine something li

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[Fagyal Csongor]

Thomas Wittek wrote:

[...]


But I think that it would be a good idea to create a clean, "servlety"
foundation, upon which you still can implement a 200 lines
CGI.pm/Web.pm/foo.pm that covers the most common web-request tasks.
 


That sounds nice.

- Cs.

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[Fagyal Csongor]

Ian Langworth wrote:


It sounds like the name of HTTP is more appropriate:

  HTTP::Request
 ...uri, pathinfo, params, method, headers, etc.

  HTTP::Request::Session
 ...adds to HTTP::Request to provide session() method

  HTTP::Response
 ...response code, content, headers, etc.

  HTTP::Response::JSON
 ...extends response.write() to encode JSON

Maybe CGI.pm could adapt these to the CGI environment and ecapsulate
their functionality.

Maybe it's too servlety.


It is :)

It is probably the *proper* way, but definetely not the *efficient* way. 
You rarely do real HTTP handling when you use CGI.


A general, simple CGI handling module fits into 200 lines, including 
POD. Imagine like


sub parseQueryStupidAndWrong {
   my $self = shift;

   $ENV{'QUERY_STRING'} || return {};

   my @pairs = split(/&/, $ENV{'QUERY_STRING'});
   my %query;
   foreach my $pair (@pairs) {
   my ($key, $value) = split (/=/, $pair);
   $key =~ tr/+/ /;
   $key = whatever::url_decode($key);
   $value =~ tr/+/ /;
   $value = whatever::url_decode($value);
   if ($query{$key}) {
   $query{$key} .= ", $value";
   } else {
   $query{$key} = $value;
   }
   }
   return \%query;
}


You don't really need more. IMHO a CGI module 
parses/preprocesses/decodes/etc. all incoming parameters (POST, GET, 
COOKIES), and that's it. It might give some useful other routines (e.g. 
url encoding / decoding, various ways to mix GET+POST, set content types 
more easily, etc.), but other than that, it should be very lightweight 
and easy to use.


- Cs.

Re: the CGI.pm in Perl 6

[Fagyal Csongor]

> Randal L. Schwartz wrote:
>
>> The thing that CGI.pm does is put in one place everything you need for
>> a simple web form.  And there's an amazing number of applications for
>> this... putting a "contact us" page on an otherwise static site comes
>> to mind immediately.
>>
>> Sure, if you're building a complex shopping cart application, you're
>> gonna reach for Jifty or Catalyst, or at least roll your own with
>> Template Toolkit or Mason, and you'd be silly to use either CGI.pm's
>> parsing or HTML generation in those cases.
>
> You seem to be forgetting the case in the middle - a small dynamic site.
IMHO that is: "most sites".

>   My weapons of choice for that are CGI.pm to parse requests and
> Template Toolkit to stuff the relevant content into templates.
That's why I use CGI::Lite - no fancy HTML, only a lightweight module with
themost important features. (Gee, I am emitting WML sometimes!)

And let me add this as a side note:
http://www.w3.org/CGI/
IMHO a module should do what its name stands for.

Surely, when I do something with CGI, I also do HTML generation in 99% of
the time. But as the matter of fact, I also use DBI in 99% of the time, so
why not put DBI into CGI.pm, too? ;)

[...]

>> But don't throw out the simplicity of CGI.pm's basic task handling:
>> parsing the incoming parameters (including file upload), and
>> generating sticky forms and other common HTML elements.
>
> That's two tasks.  It should be two modules.
Absolutely.

> I suppose you could argue that generating  tags specifically and
> all their baggage like s might fall under its remit (they are,
> after all, what generates the fancy requests that are CGI's bread and
> butter), but generating  tags is most definitely not anything to do
> with CGI.
Also consider that handling the "input part" of CGI is very
straightforward. No matter what system/language you use, you basically do
the same thing (parse/access GET/POST, the ENV variables, etc.) On the
other hand, handling the output is much more dubious - besides setting the
content type on some other headers, there are dozens of ways to
handle/mangle the content you output. Perl5's CGI.pm provides a way, but
that is IMHO just a legacy API Perl6 has nothing to do with. Basically
everyone who use CGI.pm use ->param() - but only a few use ->h1(), for
example. (IMHO if something beyond CGI input handling must go into CGI.pm,
then that is cookie handling - but that's another story.)

Just my two cents.
- Fagzal

Re: Stubborn coworkers

[Fagyal Csongor]

Jeff,

Greetings all.  I've followed perl6 development since the beginning, 
and have tried to stay at least somewhat informed along the way.  I'll 
confess to being puzzled at some of the design decisions, but knowing 
my own limitations have had faith in @Larry to do the right thing.


This topic would be m,ore appropriate for perl6-advocacy, if it 
existed, but rather than pestering the language designers with it, I 
thought I'd look for the user perspective on it.


As one of the lead perl programmers here, I've been tasked with 
introducing some of the changes to people.  Something short of sending 
them off to read the Synopses.  While I can discuss features like MMD, 
strong typing, Roles and the like, you don't get too far before you 
start introducing the new operators, and the fact that we've got 
Unicode operators (yes, with ASCII equivalents, but they're terrible 
IMHO).


I have one coworker known for her stubbornness.  I've been hit with 
the following several times, and honestly don't have a good reply:


"My bigger concern with the Perl6 syntax is that they expect humans to 
write it.  This is a similar problem that Forth and Lisp had.  You see 
how widely used

those are now..."

Since I came to programming after the days of Forth and Lisp being 
prominent languages, I can't dispute nor concur with her statement.  
How would you respond?


Well.

Perl5 is hard to read, and so will Perl6 be. That (mostly) comes form 
the gazillion tons of syntax sugar we have, and from the lots of 
DWIMmery. So yes, your coworkers are partially right, at least IMHO: 
Perl6 syntax is way overloaded, and that can give you some headache. I 
do not like the unicode operators, either, for example.


However, a par excellence programmer, who actually *writes* code, might 
never experience issues like this. I mean you do not have to use what 
you do not need to use. How many here know, for example, the exact 
syntax in Perl5 regex for, say, "zero-width look behind assertion" 
without looking it up in the man pages? :) Perl5 is like three languages 
combined into one. Perl6 is like 5 languages combined.


A mathematican will love to use the sum sign 
(http://www.w3.org/TR/MathML2/glyphs/022/U02211.png) in his Perl6 
program, for example - but you don't have to. You will never even see 
it. And so on and so on. Yes, readibility might suffer, when you want to 
"decode" code someone else wrote - however, at this point one should 
consider that this overloaded syntax also mean much dense code, which 
*usually* means that the code you are looking at can fit to one screen, 
which might worth more than some more understandable code that fits 
twice as much. Just compare

my $a = $b . $c;
to
String a = (new Integer(b)).toString().concat((new 
Float(c)).toString());   /* I don't do Java, so this is probably wrong 
here :) */




Just my two cents.

- Fagzal

Re: OT: wiki engine architecture

[Fagyal Csongor]

[...]


Also, what is the best place to begin learning the Perl6 syntax? A
tutorial would be great, as a dry technical specification of the
language doesn't teach very well. 


IMHO examples teach the best. A table with "Perl5 version" versus "Perl6 
version" examples - even one-liners - would be lovely.


I don't know if this URL had already shown up in the list or not, but 
anyway, I have just come across with it:

http://cog.cognitivity.com/perl6/

There is also a PD version of the Perl5 Cookbook for Perl6 - I can't 
find the link to it :(, but IMO it is(?) included in the Pugs docs.


- Fagzal
ps: BTW, I am also in favour of MVC. :)

Re: OT: "my wiki syntax is better than yours"

[Fagyal Csongor]

Hi,

I have never understand this "my wiki syntax is better than yours" 
thing. It's like "my templateing engine is better than yours".


I feel like which should have "wiki.conf" with :

...
syntaxhandler = SuperbPerl6Wiki::Syntax::MediaKwikiMikiBiky
...

That shall please everyone. :)

- Fagzal

Re: $1,000 prize for Perl 6 Wiki written in Perl 6

[Fagyal Csongor]

Hi,


Hi Conrad,

I run the grant committee for the Perl Foundation and I sit on the steering 
committee, so I suppose I can discuss your proposal (there are some other TPF 
folk here, too, so that's why this is a public email).  Also, the following 
stuff is just off the top of my head and is in no way official.

For TPF to handle something like this, we'd have to have some agreement on what the specs are, who would judge whether or not a Wiki met the specs and what to do if there were timing concerns (if we get one Wiki before another even the the later one was sent first, who wins?)  


Oh my, this is getting complicated :)


Also, though I hate to be a spoilsport and bring this up, I'm really not sure 
what legal issues might be involved with running a contest, either.  Would that 
be considered a form of gambling and possibly be illegal?  I don't think so, 
but I'm not sure.
 


Well, it cannot be gambling. IMHO something constitutes to gambling only if:
- the outcome (who wins/loses) is mostly controlled by chance
- you have to pay in order to participate
Both should hold and none holds.

However, there might be taxing issues...


In any event, if you can come up with a solid set of contest rules, TPF can 
consider whether or not we can officially run the contest.  It sounds like a 
nice idea, I just don't know what's involved.
 



If I had some mone to spare for a contest like this, I would say: "I 
have the money so I make the rules" :) Some might not like that, but it 
makes things much less complicated. It's Conrad's money and his generous 
gesture. I would say let him decide who makes the specification and let 
him name the winner, according to the rules he comes up with. Those who 
will be unhappy with the result can always STFU, don't they? ;)



Of course if the community can make this happen is a nice and 
"controlled" way, that would be the best. I just like pragmatism :))


- Fagzal

Re: Minimum modules for Production?

[Fagyal Csongor]

Hi,


However, as has been pointed out regarding MS Word, most users only
use a very tiny subset of its functionality.  The problem is that the 
users

are using different subsets.  I've done huge amounts of HTML parsing and
can't recall having used GDBM_File.



It all comes to *different* subsets 


I think if we leave out but one module from CPAN, someone will miss it.
However, 98% of all Perl users will be happy with 2% of all (current 
Perl5) CPAN modules.



I wrote a lot of Perl for Unix, VMS and Windows system management,
text files processing and connectivity to databases (Oracle and LDAP).
I never used an HTML parser and only used LWP once.

So for me a stripped down version of Perl with reasonable I/O
capabilities (print, open, close, ) would be just enough and i can
settle for an easy-to-install connectivity bundle.

Then again, i only represent myself.



Some use Perl for biometric, some for converting SVG to PDF, some for 
creating desktop applications. But that is not typical. System 
administration and "web/net programming" covers most of the tasks most 
Perl users use Perl for. So my list would be something like:


- basic protocols, say UDP and TCP (so that you have something to build on)
- a little more higher level protocols, say HTTP / HTTPS, POP3, IMAP, 
SMTP (you want to *send mail*, don't you?)

- something LWP-like, so you can handle GET/POST and Cookies
- something CGI-like, so that you can url_encode(), 
$cgi->param("submit") and such

- Digest::* Who can live without md5_hex() ?
- Crypt::* DES, 3DES, Blowfish, SSL...
- Serialize: thaw/freeze (yep, something like Storable)
- something like Data::Dumper (to see what you are doing)
- a template handler (like TT2 - preferably TT3 or TT6 :))
- XML parsing/generation (we must be serious...)
- HTML parsing, I second that (so that you can WWW::Mechanize and 
HTML::FillInForm and so on...)

- command line argument parsing (LongOpt or whatsthename)
- DBI
- MIME (you want to send mail with attachments, too :))
- some kind of image manipulation, probably using an external library 
(to populate your TGPs :))) - ImageMagick comes to the mind


And for the sake of my open source Perl5 framework, so that I can start 
thinking about the Perl6 version :), these would make *me* happy :

- FastCGI
- Config::General
- Cache::*





- Fagzal

Re: Simple Print/Say Question

[Fagyal Csongor]

Chris,

Strange. I have just tried this using an old version (6.2.3) of Pugs:

my (@array) = 1,2,3;
print @array[0] ~ "|" ~ @array[1] ~ "|" ~ @array[2] ~ "\n";

It prints
1|2|3
on my terminal.

Gabor's join-ed version also works.

- Fagzal

> Oops.  That last . is a typo on my part.  Sorry about that!  It should
> read, which it does in my code:
>
> print @array[0] ~ "|" ~ @array[1] ~ "|" ~ @array[2] ~ "\n";
>
> However, your say join technique does not work.  I will keep on it but
> for now I am off to dinner!
>
> Thanks!,
> Chris
>
> On 5/23/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
>> On 5/23/06, Chris Yocum <[EMAIL PROTECTED]> wrote:
>> >
>> > 1|2|3
>> >
>> > I would say something like:
>> >
>> > print $array[0] . "|" . $array[1] . "|" . $array[2] . "\n";
>> >
>> > not the best way but it works.
>> >
>> > In Perl6 if say something like this:
>> >
>> > print @array[0] ~ "|" ~ @array[1] ~ "|" ~ @array[2] . "\n";
>> >
>> > I get
>> >
>> > 1 2 3 | | |
>> >
>> > My question is: why is it doing that or, more to the point, what am
>> I doing wrong?
>> >
>>
>> I am not sure, maybe the . before "\n" cause the problem but why not
>> try this one:
>>
>> my @array = (1, 2, 3);
>> say join "|", @array;
>>
>> Gabor

Re: proposal: 404 method

[Fagyal Csongor]

András,

I think you have just discovered AUTOLOAD :-)

OTOH I don't know how the AUTOLOAD mechanism will work in Perl6 compared 
to Perl5, or if it has been imlemented in Pugs (yet), but as far as I 
remember, in Apocalypse 12 somewhere it says it will work the same(?) as 
in Perl5, and what you have described works in Perl5 (if I understood 
you correctly, which might not be the case).


- Fagzal


Hi,

Is there a way, to catch, if I call a method, that doesn't exists, to 
run a default one? I'm thinking about an "error handler" method. If 
not, I would like to propose this:


class MyClass {
method example ($self: $var) {
say "HELLO";
}
method default ($self: $method_name, %parameters)
is method_not_found {
say "$method_name called";
}
}

$mc = new MyClass;
$mc.example("var")
$mc.helloworld("var", "var");

--

and it outputs:

HELLO
helloworld called

The above is maybe not the best (and not the most valid) syntax for my 
proposal, but I think you can get the idea. It would be very useful 
the hide parameters into the method name, like this:


 save_the_world();
 save_the_captain();

And the default method will match the method name with 
/^save_the_(.*)$/, and saves $1.


I hope, you will like it. As I know, it's not possible currently.

Bye,
  Andras

Re: new mailing list: perl6-general?

[Fagyal Csongor]

Hi,


Hi,

I think, that David's version is matches with my opinion. I don't 
think, that "beginners" would be a better name for it, but maybe more 
practical, as it's a more evident name.


Hmmm, I think "beginner" is a little negative. What about professional 
Perl5 programmers, who wish to learn Perl6? Wouldn't like the name :-))


How about 'perl6-usage',  'perl6-programming' or... hmmm, simply 'perl6'?

- Fagzal

Re: new mailing list: perl6-general?

[Fagyal Csongor]

Hi,

Just wanted to say the same. All my questions starting as "How to..." 
and "Is this..." are just to trivial to ask here :)


OTOH as there is no "global" Perl5 list (AFAIK, at least), these things 
should go to the "regional" mail-lists - later on. However, at this 
phase of develpment of Perl6/Pugs/Parrot/Andtherest, we would just 
overload those who are not (yet) interested in Perl6 with a continuous 
fear of getting Warnocked ;)


Andras++

- Fagzal


Hi,

I would have some general Perl6 programming questions. Where should I 
ask them? It's not about language design, not about 
compiling/compilers and even not related to the internals.


As more and more people will start hacking Perl6, I think, that it 
would be useful to having a list for this.


In this particular case, I would like to ask about creating a 
langugage construct (maybe there's a desgin pattern for it, maybe not) 
for a web templating system can be expanded by the user.


Bye,
  Andras

Re: What the heck is... wrong with Parrot development?

[Fagyal Csongor]

Larry,


On Mon, Jun 06, 2005 at 04:31:01PM +0200, anonymous coward wrote:
: It's a funny old world...
: wrote Dan Sugalski on June 04, 2005 in his Squawks of the Parrot blog.
: Go and see: .
: 
: Hence the subject.
: 
: What the heck is wrong with Parrot development?


I can't comment on aspects I am in all likelihood blind to, but I'll
be glad to point out that one of the most *irritating* problems
is people who snipe from the sidelines without having earned the
right to do so by contributing.  Dan has earned the right to carp,
and deserves our respect for refusing to vent (much) in public, but
anonymous cowards are generally just interested in making trouble
without being held accountable.  Feel free to prove otherwise.
 

With all respect, I think this is a very important thing which needs 
attention, and I hope that you will help us to clarify the situation. I 
am pretty sure Dan did not leave because he had a bad day - we know he 
is a much more serious person. I also think that the community does not 
ask you to tell us what is happening - your mind is worth more than that 
to us :-) However, it is vital to know if there were issues that should 
worry us. I hope someone will come forth and talk about these underlying 
problems most of us do not know about - and then your role, if you 
accepted it, could be to tell us if that brave person is authentic or not.


Of course it would be best if this person were Dan himself, but I (hope 
that I) understand his motives, so if he choses not to tell, let it be 
that way, he has indeed earned the right do do so. I know noone asked 
*my* opinion, and obviously I have no right to make any waves  here, but 
what I can say is if there were personal problems that led to this 
parting - I mean the "anonymous cowards" you mentioned -, while that is 
*very-very* bad and sad, it still sounds better to me than, say, knowing 
that Parrot development might fall into the hands of those who will 
scr*w it up. Apart from the tremendous amount of work and enthusiasm 
that went into creating Perl6/Pugs/Parrot, business decisions will be 
(if not are being) made on the (predicted) success of Perl6.


I have many things to worry about - it goes with working in IT. Please 
someone let me know if there is one more unpredictable thing in the 
future or not :-)


- Fagzal

Re: ./method

[Fagyal Csongor]

Abhijit Mahabal wrote:
(Note that "./" and "../" are prefix operators, and unlike ".?", ".*",
".+" and ".=", cannot be used infix. In fact, it requires that "?", "*",
"+" and "=" be thought of as meta-operators to ".", and from now on, to
"./" and "../" as well, so you get "./+method". This isn't as complex as
it looks right now.)
Your opinions please! (I ask those who already responded off-list, to
repeat their opinion here)

Since new syntax is being suggested for these things, here is my 
suggestion, very late in the discussion, but here it is anyway.

$_ is the topic; the "only" problem is that we have two topics here: 
an immediate and a "main" topic. What if a method call binds the 
invocant to *both* $_ and the "bigger topic" $__?

method foo($x){
# invocant accessible by both $__ and $_
for (1..3) {
# invocant accessible by $__ only
.bar(); # called on $_
$__.bat(); # called on the invocant
$?CLASS.bas();
}
}
I like this because things still look a little like a topic. This is 
not better than $o/$O, except that $__ looks more like $_ (but maybe 
it looks too much like $_, and that alone could invalidate this 
proposal).
Yep. I'd hate it to move the cursor every time on __ to see if it is _ 
or __. I have bad eyes and a small monitor :-)

This view won't be popular, but I'd prefer all these "built-ins" look 
like $_SOMETHING, like
$_, $_SELF, $_CLASS and so on...  even $_ to be an alias to $_TOPIC .

- Fagzal

Re: ./method

[Fagyal Csongor]

I also like this notation.
However, as a side note, let me voice the opinion that the "bad 
reputation" of Perl partially comes from the fact that it often looks 
like line noise. I think everybody know this. Now there has been a lot 
of discussion on finding different meanings for any two-character 
combinations of ^/[EMAIL PROTECTED]&~{}\ (I am sorry to say it that way). As a 
Perl programmer I like this, but I am afraid that other programmers of 
different languages ("...who will burn in Hell..." :-)), or newcommers 
to Perl6 will have trouble even to pick up the basics. But again, this 
is just a side note.

In this particular case, I like ./method because I don't like 
$?SELF.method, which looks like my terminal is in UTF-8 and there is an 
ISO-8859-2 character between $ and SELF :-))

- Cs.
A few days ago, when typing ./pugs,... You can guess the rest :)
I suggest
   ./method
to mean $?SELF.method, and
   ../method
   

 

Your opinions please! (I ask those who already responded off-list, to
repeat their opinion here)
   

Wonderful!

Re: Nested captures

[Fagyal Csongor]

Autrijus Tang wrote:
On Thu, May 12, 2005 at 12:37:06AM +0200, Fagyal Csongor wrote:
 

Damian Conway wrote:
   

  print @array[1st..($n)th];
 

Sounds cool, but what about $n = 0; ?
   

Then it would be 0..-1, an empty range.
 

Yep, but I mean in general isn't it confusing that the 0th element is 
actually the -1st (in Perl5 sense)? Does this mean that the -1st (Perl6) 
element would be the -2nd (Perl5)? Or are (-n)th elements invalid?

- Fagzal

Re: Nested captures

[Fagyal Csongor]

Damian Conway wrote:
print @array[1st..($n)th];
Sounds cool, but what about $n = 0; ?
- Fagzal

Re: Nested captures

[Fagyal Csongor]

H,
On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote:
 

On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
: But that's only the opinion of one(@Larry), not of $Larry.
Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
Our old $0 (P5's $&) could be $<> instead, short for $ or some
such.
   

Both 0-based $0 etc and $<> are now implemented in Pugs.
 

Does anybody check if he actually implements what he say? :))) It just 
doesn't seem possible... :)

Autrijus, I assume you started Pugs by creating Time::Machine first...
BTW, anybody interested in creating and FastCGI interface for Pugs?
- Fagzal

Re: Perl6 and support for Refactoring IDE's

[Fagyal Csongor]

Matisse,
Just one note before we take this off-list:
Maybe this isn't the right place to keep discussing this, so I'll take 
pointers to other places. I'm very worried about the continued 
viability of Perl for major projects and am trying connect with other 
people and see what can be done about it.
I share some of your fears, and would be very much interested in talking 
about them with you (and others). Actually I gave a small lightening 
speech on this topic at last year's Perl gathering at Budapest, which I 
will hopefully make into an article some day...

IMHO Perl needs some more marketing 
:)

- Fagzal

Re: Perl6 and support for Refactoring IDE's

[Fagyal Csongor]

Matisse,
Will Perl 6 help us have tools that are as good or better than the 
ones available for Java, C#, etc?

I've been using Perl since 1994 and for the past several years have 
used it to build a number of complex mod_perl applications. I love Perl.

The following  may be considered heresy, but I believe that these days 
the quality of the whole development environment is just as important, 
maybe *more* important than the language itself. I mean that the 
availability of *easily integrated* tools including IDE, automated 
testing tools, refactoring, deployment tools, etc. are a HUGE factor 
in determining what language gets used for a large project
Heresy or not, I think you are (mostly) right. Actually I would say your 
are right *unfortunately*.

Available tools are a huge factor, yes - not in a way as which language 
to select for a project, but which one to *deselect*. And currently Perl 
(I mean Perl5) is not doing very well compared to others.

I've become scared that if Perl is to continue to be viable for large, 
complex, multi-developer projects that the tools need to serious 
catch-up with what is available for Java, for example. Things like:

  - Refactoring Support (see http://www.refactoring.com/)
  - CVS and/or Subversion integration
  - Support for integrating regression tests and auto-building
  - Automated syntax and dependency checking
IMHO subversioning does not have too much to do with the language 
itself. Subversioning operates on files. An IDE might integrate some 
interface for this task, but that is a different question.
Syntax checking in general is very hard to do in Perl5/6 because of the 
great amount of line noise there (consider yourself in the middle of 
writing a regexp :)) The perl6 compiler must be able to do syntax 
checking, though :-), and the design of Perl6, as I understand, 
definetely gives you more possibilities compared to Perl5.

For the others, some more knowledgeable folks will probably provide some 
answers and ideas. However, I think that the language design and 
implementation does not have too much to do with IDE availability.

I've been using Eclipse, with the EPIC plugin 
(http://e-p-i-c.sourceforge.net/) and so far I like it. It uses 
Devel::Refactor to support "extract subroutine", but a lot more is 
needed to match what you can do with Java these days.

What are others' thoughts on this?
Have you considered using the "DONATE" button on 
http://e-p-i-c.sourceforge.net/ ? :)))

- Fagzal