NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
make it look better (Score:1)
I don't understand what people keep complaining about. Perl 5 has some legacy, but it is not broken. You don't have to have a major new release of the language every year to keep it current. Perl is mature, and that's a good thing. It has all you need. It's even fun and exciting; you know it. (At the same time there is the next wave of development happening all time.)
(IMO, saying that Perl is too nice (too easy, too liberal, too flexible or what ever I keep hearing about) is just an absurd subject for criti
Re: (Score:1)
You have to have a sane deprecation policy if you want any hope of avoiding the crushing burden of legacy code. How long did it take to get rid of pseudohashes, for example?
Re: (Score:1)
You have to have a sane deprecation policy if you want any hope of avoiding the crushing burden of legacy code. How long did it take to get rid of pseudohashes, for example?
Yes, and Perl 6 will be a major milestone in the history of interpreted languages.
However, my feeling is that the Perl community is now lacking entry- and mid-level users in "new" application areas like Web development. I don't see the language details as the problem here.
People are looking for CMS:s, modern MVC frameworks, good looking friendly sites, easy to find documentation, exciting examples and a consistent presence in the web. All can be done with Perl, all has been done with Perl, but people ju
Re:make it look better (Score:1)
For the marketing problem, no. That's probably the most important problem to address.
I do strongly believe that language details (and the Perl 5 deprecation policy until now) still matter. Perl 5 has been in a situation where it can't evolve. Hopefully that will change.
Reply to This
Parent
Re: (Score:1)
I was thinking about this only a few weeks ago especially after seeing some of the excellent things coming out of Devel::Declare.
So wouldn't it be lovely to see things like autobox, Moose, MooseX::Declare, Method::Signature etc become part of standard Perl5.
Methinks we need a clear roadmap for Perl5?
Re: (Score:1)
No, I want the stuff currently in Perl core dumped. My thought is that the Pumpkings should be focusing on *Perl* not CGI.pm or Moose or other Dual Life modules.
Someone *else* should pickup the slack and work on dists with this other stuff. The Enlightned Perl organization is already working on doing this for Enterprise oriented Perl, other people to pick it up and run too.
Re: (Score:1)
Bit like Dave Thomas's suggestion of different versions of Ruby at recent RubyConf... http://use.perl.org/comments.pl?sid=41745&cid=66286 [perl.org]
So... PerlLite? Perl++? PerlPlus? Perl5000?
Re: (Score:1)
Correct link....http://rubyconf2008.confreaks.com/keynote.html
Re: (Score:1)
Exactly, I think of it like Linux Dists. There are different dists for different markets, tuners, stability hounds, FOSS nazis, Usablilty wonks ... there should be Perl dists tuned to different goals similarly.
Re: (Score:1)
use dist 'perl5++'; # switches on strict, warnings & mooseX::Declare!
#use autobox; # its there but don't need it right now
class Sum {
has 'x' => ( isa => 'Num', is => 'rw', default => 0 );
method add (Num $y) {
$self->x + $y;
}
}
my $maths= Sum->new( x => 10 );
say $maths->add( 2 );
Re: (Score:1)
Every one of those distributions is a workaround for a feature that should be in the core language but isn't. There's my evidence for the crushing weight of backwards compatibility.