develooper Front page | perl.perl5.porters | Postings from December 2008

Re: [PATCH] Class as a Feature (take four)

Thread Previous | Thread Next
From:
chromatic
Date:
December 16, 2008 00:03
Subject:
Re: [PATCH] Class as a Feature (take four)
Message ID:
200812160003.21266.chromatic@wgz.org
On Monday 15 December 2008 23:41:59 Steffen Mueller wrote:

> chromatic wrote:

> > That theory didn't work out very well for Tcl or Lisp.  Surely the fact
> > that it's possible even fourteen years after the fact to give Perl 5 a
> > little bit nicer syntax out of the box (barring the 'use feature' fiasco)
> > has some degree of compelling to it?
>
> It does. I like it. I'm not sure I'd call 'use feature' a fiasco,
> though. There is a default feature set in effect with "use 5.X.Y" and
> I've been advocating that... no, I'm not going to say it on the list again.

It's backwards, though.

I've been a professional system administrator and a professional programmer, 
and for several years I've been a professional editor who helps people 
explain system administration and programming and such to normal people who 
don't teach themselves by reading source code, and I can build my own Linux 
system from scratch if I have to.  I don't, though.  I use Xubuntu because I 
can install it and have something useful without spending hours or days 
tweaking it to my liking.

Good defaults go a long way.

Imagine if feature.pm had existed in the days of 5.6.0, and the only way to 
get lexical filehandles was to say something like:

	use 5.006;
	use feature 'lexical_filehandles';

That's nice for all of the people who have Perl 4 programs they want to keep 
running unmodified some nine years later, but do you really want to imagine a 
world where you have to enable every nice new feature added for the 
convenience of Perl programmers explicitly?

Do you want to write or edit tutorials which say "Don't forget to add all of 
these gobbledegook incantations you don't understand right now to all of your 
programs -- don't worry about knowing what they mean, but trust us!"?

Perhaps I give away my bias here.

If that still doesn't convince you, ask yourself how many tens of thousands of 
hours of debugging time we've perpetuated on the world because 'strict' 
and 'warnings' aren't on by default.  Perl can often identify very simple and 
very common problems with programs but danged if we'll let it help people 
because that might break code written in nineteen-flippin'-ninety-one.  The 
upgrade instructions might very well say "Here's what you put in your 
PERL5OPT environment variable."

(To forestall the predictable retort: there's nothing we can do to cater to 
people who upgrade willy nilly without reading these instructions or 
performing a modicum of testing.  They're doomed anyway.  Spend your tuits 
where you can actually help people.)

Alternately, feature.pm could have been the module you load to *disable* new 
features -- you know, if you're upgrading and don't want to migrate yet.  
Somehow I think someone who's been using Perl for at least seventeen years 
will be able to figure that out before someone who's just started using it 
today figures out the cantrips to let the interpreter help him.

> Again, I agree. The largest part of the Perl user base has never
> installed a CPAN module and does not intend to. It is that same group of
> people that we are catering to with the hard and fast rule never to
> break backwards-compatibility (cf. feature). Why not cater to them with
> an improving core as well?

Precisely.

-- c

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About