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

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

Thread Previous | Thread Next
From:
Jonathan Rockway
Date:
December 15, 2008 22:00
Subject:
Re: [PATCH] Class as a Feature (take four)
Message ID:
87prjs8xt0.fsf@bar.jrock.us
* On Mon, Dec 15 2008, chromatic wrote:
> On Monday 15 December 2008 20:37:47 Jonathan Rockway wrote:
>
>> It would be silly to implement this stuff in core when
>> it is already working great outside of core.
>
> That theory didn't work out very well for Tcl or Lisp.

I am not sure what you mean here.  I like programmable programming
languages -- I trust myself to know what features I want, rather than
trusting the language designer to pick for me. (This is why I use Lisp
and Perl and not Python or Smalltalk.)  In my ideal language, I can
compose features together, and then pretend like *that* is the core
language.  Much easier than writing my own language.

Perl sort of allows this already, but the concept of a "system" is one
of my favorite Lisp features.  In Perl, I have to say "use strict; use
warnings; use Foo; use Bar;" in every one of my modules, if I want to
use Foo, Bar, and strict + warnings.  (It is even worse if I want to use
the "say" keyword.)  In Lisp, I just say "(define-package #:foo :use
#:common-lisp #:foo #:bar)" and then every file in my project has the
features of common lisp, foo, and bar.  This means that I don't have to
worry about what features CL actually has -- I get to decide for myself,
without "deciding for myself" in every single file.

(An example -- I use ITERATE instead of LOOP in my Lisp projects.  The
syntax is better than what they came up with in the late 80s for loops.
Rather than being stuck with the poor decisions of the language
designers, I can just drop in my own stuff and not think about it ever
again.  Anywhere I could type (loop ...) I can type (iter ...), just
like it's a built-in feature.  And, it's being continuously developed,
so bad decisions don't bother every user every day for the rest of their
lives.  If I don't want a new feature a new version introduces, I can
just not update that part.  No deprecation cycle, no "legacy", no
hassle.)

Anyway, if Lisp is a failure for this reason, I like failure a lot.  We
should all strive to fail more.

Perl is about modules.  That is the only reason why I use it.  I
disagree with a large number of the core language decisions, but it
doesn't matter at all if I can just replace or ignore the stuff I don't
like.  Mostly, I can do this right now, so that's why I use Perl for
almost everything.

Making it even easier to replace things and add new modular features
will make Perl more attractive to people like me.  Adding more features
to the core helps in the short term (they make for great blog posts),
but ends up as bloat in the long term.  Remember pseudohashes?  Is a
10-year deprecation cycle really better than just not using a module?

> I thought the purpose of allowing language evolution outside of the core was
> to test features for syntax, usability, and feasability, and then possibly
> consider subsuming the proven-good ideas (such as "We're pretty sure the
> right keyword to declare a class is "class").  Or shall the answer always
> be "Pity about the core language, but if you're fortunate enough to have a
> working development environment, access to the CPAN, and the wherewithal to
> compile XS modules, you can fix things we all agree are suboptimal"?

Yes, and yes.  Some things probably have to be core, like a JIT
compiler.  Some thing probably don't have to be core, like the sugar
layer over the object system.

If you are concerned about compiling XS modules, just use Strawberry
Perl, or Debian, or ... and let the packaging experts handle that for
you.

I don't think adding a half-assed version of Moose to the core would
help anyone.  It would be a waste of time for the people writing it, and
a waste of time for the people using it.  (This is more in response to
rgs' comment, rather than yours.  Moose is the right way to get
attributes and "final" classes in Perl 5.)

> It's unfortunately clear we can't add new syntax to Perl 5 by default.  Are
> you really suggesting we shouldn't add new features to Perl 5 at all?

Please read the sentence right after the one you quoted :)

Anyway, if you really want to add more features to Perl 5, please add
two-stage programming, like MetaLua or Template Haskell.  That would be
much nicer than a "class" keyword. :)

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

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