Perl6 "style-guide"
Fagyal Csongor
I was wondering if there is (or there should be) a documentation on how
to elegantly write Perl6 code.
I am afraid that when I will be starting to write Perl6 code, it will be
too much Perl5-ish, and I will end up rewriting my code in every 3
months because I hate when my code is not elegant (at least to my own
standards).
I was wondering that some - maybe @Larry - already have (mosf ot) Perl6
in their heads, so they could create such a document/recommendation
before Perl6 gets used widely, and the coding style gets "distorted".
Or shall we just leave this to the community? Maybe this documentation
shouldn't/can't be written yet? Shall we let Perl6-style grow from usage
in 1-2 years, and create a guide like this then, when things mature?
- Fagzal
Jerry Gay
> I was wondering if there is (or there should be) a documentation on how
> to elegantly write Perl6 code.
>
> I am afraid that when I will be starting to write Perl6 code, it will be
> too much Perl5-ish, and I will end up rewriting my code in every 3
> months because I hate when my code is not elegant (at least to my own
> standards).
>
i think that's a problem you'll share with many other folks, as *very
few* have written anything of substance in perl 6 so far... and the
design is still changing.
> I was wondering that some - maybe @Larry - already have (mosf ot) Perl6
> in their heads, so they could create such a document/recommendation
> before Perl6 gets used widely, and the coding style gets "distorted".
>
i think larry's pretty busy doing what he should be doing at this
point... designing.
> Or shall we just leave this to the community? Maybe this documentation
> shouldn't/can't be written yet? Shall we let Perl6-style grow from usage
> in 1-2 years, and create a guide like this then, when things mature?
>
don't "just leave this to the community." take part! take advantage of
the perl 6 wiki (http://rakudo.org/perl6/index.cgi) and create a page
describing the task. write some code yourself. ask folks to
contribute, and fix the existing code or add their own. create an
outline of what you'd like to see there... and have fun!
be the community.
~jerry
Michael Snoyman
>
> don't "just leave this to the community." take part! take advantage of
> the perl 6 wiki (http://rakudo.org/perl6/index.cgi) and create a page
> describing the task. write some code yourself. ask folks to
> contribute, and fix the existing code or add their own. create an
> outline of what you'd like to see there... and have fun!
>
> be the community.
> ~jerry
>
Would a plausible idea be to have a section on the wiki devoted to "free
coding?" All developers, including those brand new to Perl 6, could start
writing random test code, which the more experienced in the Perl 6 world
could then tweak so that eventually, we should have a very broad sample of
code that the community has decided looks right.
Michael
A. Pagaltzis
> I am afraid that when I will be starting to write Perl6 code,
> it will be too much Perl5-ish,
Even with a style guide, your Perl 6 code will still be
Perl-5-ish. And even once it’s not anymore, six months later you
will discover that it’s not really Perl-6-ish either. Until you
become fluent in the language, your code is going to be less
elegant than it could be. A style guide can give you a bag of
broad hints for the most obvious things, but fluency is something
that comes from practice, and that inevitably takes time.
> and I will end up rewriting my code in every 3 months because I
> hate when my code is not elegant (at least to my own
> standards).
That’s an urge that bedevils many a programmer (myself included).
Learn to curb it. (I am trying to; I have already gotten much
better about it.) “Improving” old code that works and isn’t being
developed, purely for the sake of aesthetics, is a waste of time.
If you ever need to touch old code again for a particular reason,
then you have justification for cleaning it up. But code comes
and goes; if you focus on writing your new code better, your body
of code will automatically improve over time.
Also, don’t sweat the small stuff. When you write a grocery list,
you don’t expend a lot of thought on making it worthy of
Shakespear either.
----
All this is not to say there shouldn’t be a style guide for Perl
6 or that it wouldn’t help you. There absolutely should be and it
certainly would. But don’t be fooled about how much so.
Entirely aside from all these points, I think it is a bit early
to be writing a Perl 6 style guide. There are a number of
features in the language that have never been tried in the wild
in this combination, and I expect it will take a year or two at
least until the first proper best practices start to crystalise
in the community. Any guide written now would be obsolete very
soon.
That said, a cheatsheet with broad tips for arrivals from Perl 5
could already be written and will age well.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
cma...@gmail.com
> That said, a cheatsheet with broad tips for arrivals from Perl 5
> could already be written and will age well.
Oh, have a look at docs/other/porting_howto in the pugs svn tree. If
nothing else, it's a good starting point.
<http://svn.openfoundry.org/pugs/docs/other/porting_howto>
--
masak
Juerd
> * Fagyal Csongor <con...@conceptonline.hu> [2006-09-20 17:00]:
> > I am afraid that when I will be starting to write Perl6 code,
> > it will be too much Perl5-ish,
> Even with a style guide, your Perl 6 code will still be
> will discover that it???s not really Perl-6-ish either. Until you
> become fluent in the language, your code is going to be less
> elegant than it could be. A style guide can give you a bag of
> broad hints for the most obvious things, but fluency is something
> that comes from practice, and that inevitably takes time.
I've been thinking in Perl 6 terms for quite a while now, and while Pugs
hasn't implemented enough to bring life to all my ideas, I do notice
that there is a sharp distinction between "Perl 5"-ishness and "Perl
6"-ishness. A good example is the way you thought about param's dual
function in terms of arity/context, while my first thought nowadays is
to use a type that simply implements two kinds of access. With all due
respect, I already consider the former old fashioned :)
A style guide is very hard to write. It indeed boils down to fluency.
--
korajn salutojn,
juerd waalboer: perl hacker <ju...@juerd.nl> <http://juerd.nl/sig>
convolution: ict solutions and consultancy <sa...@convolution.nl>
Darren Duncan
>I was wondering if there is (or there should be) a documentation on
>how to elegantly write Perl6 code.
I have found that Damian's "Perl Best Practices" still works very
well for Perl 6 code, so I still apply that where reasonably possible.
And in fact, I expect that PBP was written to be forward compatible
to Perl 6, as it could describe styles that should be natural in Perl
6, even if less so in Perl 5.
-- Darren Duncan
Larry Wall
: And in fact, I expect that PBP was written to be forward compatible
: 6, even if less so in Perl 5.
Indeed, I know for a fact that it was. (Though the treatment of /m
ends up making ^ and $ mean the wrong thing from a P6 point of view.)
Larry
A. Pagaltzis
> I've been thinking in Perl 6 terms for quite a while now,
I won’t dismiss this claim, but the `@ISA = qw( Exporter );`
example I mentioned in the other mail cautions me from believing
that anyone is particularly fluent with Perl 6 quite yet.
Learning to use the new stuff is not the problem; learning how
not to overuse will be. Good design is about restraint.
There’s a bit of a road ahead.
Chris Dolan
Does anyone want to start a port of Perl::Critic to Perl6? :-)
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf