Almost one year ago, I posted similar opinion on perlmonks. But now, I
realize I made a mistake most of people made, to avoid knowing, learning new
things. ;)

as a sysadmin since 2000, I definitely need to handle many small tasks also,
a script for fetching files, a script for showing figure, a script for
checking capacity...   but when these script keep piling up, you will end up
with a neat way, writing a better program or module to organize those all
stuff.  In this term, perl6's grammar, and module management would make our
job more easy to be done than perl5.

sure, sometimes, you still need to handle trivial tasks. In this area, perl6
oneliner  works as well as perl5 does.

again, in perl5, you have to often look up some speical variable in perldoc,
many werid expressions confused guys take over your job, and  maybe spend
half an hour to explain why this built-in function has an comma but the
other hasn't to newbie.

the advantage of perl5 now is cpan, but because of weak module management,
how to control various modules in script become a big problem to make
headache.

Compared to this, perl6 is more neat, consistent and reasonable.  only if
would you love to take one or two hours to read perl6 syntax and try with
rakudo, you would find it's not as complex as you imagine.

In my opinion, the problem of rakudo nowadays is bloody slow, flux grammar
and unproductive. hmm, as a sysadmin, I just hope perl6 could remain some
adminblood, like >>, > in open func etc.

I'm drooling for advent of true Xmas.

In addition,  a stripable language is a great idea, I think.  thinking of
embedding perl6 interpreter into linux kernel.....

On Tue, Feb 22, 2011 at 11:57 PM, Gabor Szabo <ga...@perl-ecosystem.org>wrote:

> hi,
>
> At FOSDEM I met Arne Wichmann who is a long time sysadmin,
> Debian developer and Perl user. We had a short chat in which
> he expressed his concerns about the complexity,
> the size (memory footprint) and speed of Perl 6,
>
> Without even taking in account the current memory requirements
> and speed of Rakudo, I guess, even after lots of improvements
> we can expect Rakudo to be significantly slower than Perl 5.10
> - at least for start-up time - and significantly more memory hungry.
> I know it will do a lot more so the comparison is not fair but that's
> not the point.
>
> ( For a better comparison that takes in account the features as well see
>
> http://www.modernperlbooks.com/mt/2010/07/an-accurate-comparison-of-perl-5-and-rakudo-star.html
> )
>
> He, as a sysadmin would like to do the small tasks in a relatively
> small language. He would like to make sure the modules/applications
> he will download and will have to support are in such a relatively small
> language.
>
> I wrote him my opinion but I think it would be important to address these
> issues. (Of course if there already is a page somewhere answer these
> concerns I'd be happy to just get a link)
>
> Here is his e-mail. (forwarded with permission).
>
> regards
>   Gabor
>
> ---------- Forwarded message ----------
> From: Arne Wichmann <a...@anhrefn.saar.de>
> Date: Mon, Feb 21, 2011 at 4:00 PM
> Subject: FOSDEM - perl 6 critic
> To: ga...@perl-ecosystem.org
>
>
> Hi...
>
> You gave me your card when we were leaving FOSDEM, it took me some time to
> write a mail...
>
> The topic was: why I am very sceptic about perl6...
>
> First, my background: I am a perl hacker since '91 (or so), but mainly I am
> a sysadmin. That means, I do not write a lot of code, but I do a lot of
> debugging of other peoples code.
>
> From that background, what I have seen in perl6 does not look like a good
> idea to me: it is too complex. When I read other peoples code I have to be
> able to understand whatever subset of the perl language they choose to use
> - which means I have to be able to grasp any concept used in the language.
> And given the number and complexity of operators in perl 6 I do not feel
> that this is really doable.
>
> My other gripe is that perl5 nowadays already is too big - it takes too
> much memory and time for small tasks. But that is only secondary.
>
> cu
>
> AW
> --
> [...] If you don't want to be restricted, don't agree to it. If you are
> coerced, comply as much as you must to protect yourself, just don't support
> it. Noone can free you but yourself. (crag, on Debian Planet)
> Arne Wichmann (a...@linux.de)
>

Reply via email to