[Israel.pm] Perl 6 Critique

Scott Weisman sweisman at pobox.com
Wed Feb 18 15:52:03 PST 2004

> It's true, windows 98 sucks. Deeply. The only sollution for making it
> better is rewriting it in Finnish (he he). But there's one "killer
> application" that keeps me on it - it's called QText 8, and it's
> definitely the best Hebrew word processor on the face of this Earth
> despite getting old and lacking in features.

Does WINE support Hebrew Windows? Perhaps you could chuck that last vestige of
cruft? I myself admit to having a Win 98 partition on my primary computer (a
Thinkpad x20 -- highly reccomended). However, I *never* use it. Well, I use it
for BIOS updates, but that's *it*!

I've read about Perl 6, as I mentioned in my response. I look forward to those
new features. But Perl 5 is itself not standing still. I've use several
modules that stopped working when I started using 5.8. Obviously, Perl 5
changes slowly, but it does change, and old cruft is slowly being chucked.
However, yes, there are numerous problems that will *never* be fixed. The
extremely baroque, even confusing, syntax is a big one. The difficulty of
embedding Perl or extending it using XS, compared to other languages, is
another. The adoption of weird idioms to get around limitations. I'm with you

While I don't expect a rigorous development schedule, I still think Perl 6 is
*years* away, at best, and could change radically before final release. How
many apocalypses does Larry have to go? The last one was about 9 months ago,

Because it is so radically different (while still having the "essence" of
Perl) Perl 6 is just as likely to crash and burn, leaving Ponie (which is far
more likely to be released in a timely manner) to pick up the pieces and
evolve a little more slowly towards what Larry envisioned for Perl 6. In that
time, some CPAN modules would be abandoned (something that already happens as
deprecated features are dropped and modules aren't updated), a standard
library of sorts would probably evolve (which some people are already working
on - look at DateTime and Email as two efforts to fix the mess of date and
email modules respectively).

In fact, many developers and software shops are just as likely to consider
Perl 6 a whole new language. If they do, they might then evaluate Perl 6 that
way and give equal consideration to other languages as well. They might be
just as likely to migrate to Python or Ruby, in that case! Did you consider
that possibility?

> Also consider that some of these modules are Avoda Ba'einaim, e.g. when
> you 'use constant' it's the same as creating a 'constant subroutine' as
> the docs call it. A simple 'use base' will get quite a lot of code
> executed (try `perldoc -m base`). Away with that mess I say! Let me have
> it built in!

Agreed. I also have many particular complaints. I would be happy to learn Perl
6 as soon as it is available. And would be happy to slowly migrate my code to
it when it is ready for production use. But I can't sit around daydreaming
until then, thinking of all the cool new things Perl 6 can do, when it's not
here, probably won't be here for a while, and there's even a few cool new
things being added to Perl now.

> 1. Although perl 5 has a lot going for it, and a lot of users who will
> find it quite hard to move, this should not be a deterrant from starting
> a (possibly slow) move in the right direction.

There is NO move right now since there is no Perl 6 at all, even a buggy
implementation, to use.

> 2. Rewrites are good. They just take a lot of energy.

Not always. I'm very familiar with Fred Brooks axiom, "plan to throw the first
version away, you will anyway." But the Ponie strategy (which is also a
rewrite of sorts) might be better.

> 3. Abandonware will happen. We can afford it.

Too simplistic to apply to this case. Apache 1.3 was not abandoned after 2.0
came out, and won't be for a *long* time, even after mod_perl 2.0 is finally
released. A new Linux 2.0.x kernel was just released (!).


More information about the Perl mailing list