Front page | perl.perl5.porters |
Postings from February 2007
Re: Future Perl development
From: Juerd Waalboer
February 2, 2007 17:54
Re: Future Perl development
Message ID: 20070203015404.GS25362@c4.convolution.nl
Gerard Goossen skribis 2007-02-02 23:26 (+0100):
> I want a perl which evolves, which develops new features, which ideas
> are changing, on which can be experimented, new ideas tried, and old
> ideas can be replaced by new ideas. I don't want to be hold back by
> failed experiments, I want to use the insights of previous experiment
> to develop new things. Think of different garbage collection,
> continuations, monads, experiment with Object-Orientation, concurrency.
> Think of it as a natural language.
> We can not do that without breaking the current perl.
I beg to differ :)
Perl 5 actually /has/ gained near perfect Unicode support. The unicode
support offered by Perl is far superior to that of most competing
programming languages. Granted, you obviously don't like the way it
works, but re-inventing the wheel is not the same as developing /new/
As you specifically mention features, are you familiar with the
"feature" pragma, that has been around in bleedperl for a while? Use of
this pragma introduces a number of incredibly useful new features,
inspired by Perl 6.
Perl 6, by the way, is currently still the evolving, experimental,
programming language. It is commonly acknowledged that indeed for /big/
changes, backwards compatibility is hard to maintain. In fact, we've so
far established (at least some) consensus that not even syntactic
compatibility can be maintained if Perl is to support a lot of new
techniques (and use syntax for it, rather than function calls).
Perl 6 is in the experimental stage. If you like this, join in! The
project can always use intelligent people to hack around at the
implementation. In Perl 6, ideas are changing (though you're a bit late
for the really big changes, but feel free to discuss them and convince
Larry), experimentation is happening, new ideas are tried, and old ideas
are replaced with new ones. It is not being held back by failed
experiments, and the insights of previous experiments (including almost
every programming language in existence ;)) are used to develop new
things. Think, indeed, of garbage collection, continuations, a new OO
model, and different kinds of concurrency.
As for Perl 5, I personally need it to be stable, but at the same time I
would like to use new stuff in new projects. I think the current policy
of avoiding incompatible behaviour is a really great one, even though
the programmer in me sometimes dislikes the syntactic awkwardness caused
by it. The sysadmin in me, really loves that he can just upgrade Perl,
see that bugs are fixed, and not have to consult with the programmer
(which can be himself, or can be someone else) every time he upgrades a
system to a new .x version.
The PHP policy tends to differ. While learning from past mistakes isn't
necessarily their goal, the PHP project certainly doesn't seem to mind
making incompatible changes in between releases. This results in system
administration, and a huge waste of programmer time. Writing a large PHP
application is hard, partly because the changes in between PHP versions
require ugly hacks in the code, vast (typically manual) testing, and a
brain the size of a planet, to remember all the incompatibilities, and
I would rather not have to deal with such annoyances in Perl too.
juerd waalboer: perl hacker <firstname.lastname@example.org> <http://juerd.nl/sig>
convolution: ict solutions and consultancy <email@example.com>
Ik vertrouw stemcomputers niet.