The trouble with awesome
Perl 6 is awesome.
Its design is based on the combined experience of many clever people.
It addresses a whole range of contemporary computing problems, in fields
as diverse as text processing and compiler development. It's being
developed by, and for, some of the smartest people I want to risk
approaching.
In short, Perl 6 is awesome: "Extremely impressive or daunting, inspiring awe".
http://oxforddictionaries.com/definition/awesome?view=uk
That is a problem, if we want to get it adopted widely and quickly.
I've spent quite a lot of time teaching Perl 5 to a variety of normal
commercial programmers. An early part of the course was the arithmetic
operators, (+,-,*,/,%). A good many of the classes started to look
nervous and uncomfortable around the time I introduced the modulus operator,
because it was approaching the boundaries of their experience. (I don't
think it was just my deficiencies as an instructor that led them to feel
uneasy.)
One of the difficulties of teaching a complex subject to any but the
most motivated of students is overcoming their fear of that complexity,
the feeling that "this is just too hard". There's also the practical
consideration that a "solution" more complicated than the problem it
addresses doesn't really deserve to be called a solution.
Trying to teach adults something they don't need to know is like trying
to teach a pig to sing. You will only succeed in annoying the pig. If all
you need to do is total some lists of numbers, the ability to construct
compilers is not a powerful attraction; it may in fact be a distraction.
It's not even a matter of the learner not being terribly bright. It's
sobering to visit the "Software Carpentry" site, software-carpentry.org
and remember that it is aimed at graduate science students.
We all share common limitations to learning, e.g. "the magic number 7,
plus or minus 2" http://cogprints.org/730/ Introducing too much at once
is counter-productive; it leads to confusion, not knowledge. For a concept
to stick around long enough to become an unconscious competence, it has to
be reinforced by practice. To encourage practice, it has to be rewarding,
i.e. reasonably easy to get right, and do something useful, quickly.
The problem we have is to provide a path for learning 6, that presents a
comprehensible but useful subset of the language to the average user
as soon as possible, while leading the programmer with more complex needs,
(and greater abilities), to the features they need or will appreciate.
The Synopses are comprehensive. They define the language in great depth,
feature by feature, (some features bordering on the pathological, "do not
try this at home"). Since they specify what the language is to become, not
what is implemented at present, they can be frustrating to follow. Maybe
it's just an effect of advancing age, but it's easy to forget the contents
of a previous synopsis by the time one has read the next. The Perl 6
Tablets have a similar organisation, and hence the same problem.
I haven't recently revisited the book in Rakudo*, but it struck me, last
time I looked, as a powerful deterrent to learning the language. It starts
with the tricky stuff. There's a paradox inherent in computer documentation;
people who thoroughly understand software are probably the wrong people to
try to explain it, because they know too much. (That's also true of the
current state of the error messages; they assume the reader understands
the issues as well as the author. It's forgivable at the present stage of
development, but still frustrating.)
Larry's metaphor of the Onion seems to be appropriate here. Present a core
set of features to make a useful language, ("Perl 6 baby talk") and make a
series of increasingly sophisticated and esoteric aspects available as the
student becomes adept with the basics. For example, when discussing quoting,
single and double quotes are quite enough to start with. All the Q forms
can wait. Even then, they may be introduced in stages. Of course, when doing
this, the problem is not to make statements that will have to be
contradicted later.
This concept might even help define when a 6.0.0 is "done" enough to launch.
It's going to take a while for the more esoteric features of the language
to get used. If they aren't in the first version, it may not cause much
inconvenience as long as they are implemented Real Soon. If it does, the
inconvenienced might be motivated to help.
Re: The trouble with awesome
Hallo Parrot, we are well aware that the documentation for Perl 6 is quite lacking. Any contributions in that area are greatly appreciated. Am 23.05.2012 01:35, schrieb Parrot Raiser: The problem we have is to provide a path for learning 6, that presents a comprehensible but useful subset of the language to the average user as soon as possible, while leading the programmer with more complex needs, (and greater abilities), to the features they need or will appreciate. The Synopses are comprehensive. They define the language in great depth, feature by feature, (some features bordering on the pathological, "do not try this at home"). Since they specify what the language is to become, not what is implemented at present, they can be frustrating to follow. Maybe it's just an effect of advancing age, but it's easy to forget the contents of a previous synopsis by the time one has read the next. The Perl 6 Tablets have a similar organisation, and hence the same problem. The synospis were not originally meant as learning material, and they still are not. It's easy to forget, because they are the most comprehensive documents out there. But you don't learn Java by reading the specification either. I haven't recently revisited the book in Rakudo*, but it struck me, last time I looked, as a powerful deterrent to learning the language. It starts with the tricky stuff. It's by design that it starts with tricky stuff, because it's not directed at somebody who is new to programming. There are a lot of programmers who know several programming languages already, and who don't want to read a whole page on how to print 'Hello World', 5 pages on if-statements and while-loops and another 10 pages explaining lists and iteration. At this point, Rakudo mostly appeals to language enthusiasts and early adopters, so that's quite a good fit. In the long run, we need a book for beginners too. An attempt to write materials for beginners is at. https://github.com/perlpilot/perl6-docs/ But much more is needed. Please help us with it. Cheers, Moritz
Re: The trouble with awesome
First, yes, Perl 6 is awesome. Everything that's come out as a result
of this effort is awesome. The rest is inline below.
On Fri, May 25, 2012 at 10:32:35AM +0200, Moritz Lenz wrote:
> Hallo Parrot,
>
> we are well aware that the documentation for Perl 6 is quite lacking.
> Any contributions in that area are greatly appreciated.
>
> Am 23.05.2012 01:35, schrieb Parrot Raiser:
>
> >The problem we have is to provide a path for learning 6, that presents a
> >comprehensible but useful subset of the language to the average user
> >as soon as possible, while leading the programmer with more complex needs,
> >(and greater abilities), to the features they need or will appreciate.
> >
> >The Synopses are comprehensive. They define the language in great depth,
> >feature by feature, (some features bordering on the pathological, "do not
> >try this at home"). Since they specify what the language is to become, not
> >what is implemented at present, they can be frustrating to follow. Maybe
> >it's just an effect of advancing age, but it's easy to forget the contents
> >of a previous synopsis by the time one has read the next. The Perl 6
> >Tablets have a similar organisation, and hence the same problem.
>
> The synospis were not originally meant as learning material, and they
> still are not. It's easy to forget, because they are the most
> comprehensive documents out there. But you don't learn Java by reading
> the specification either.
Some people do - the kind of folks interested in standards and the
like; just sayin' :)
>
> >I haven't recently revisited the book in Rakudo*, but it struck me, last
> >time I looked, as a powerful deterrent to learning the language. It starts
> >with the tricky stuff.
>
> It's by design that it starts with tricky stuff, because it's not
> directed at somebody who is new to programming. There are a lot of
> programmers who know several programming languages already, and who
> don't want to read a whole page on how to print 'Hello World', 5 pages
> on if-statements and while-loops and another 10 pages explaining lists
> and iteration.
>
> At this point, Rakudo mostly appeals to language enthusiasts and early
> adopters, so that's quite a good fit.
I have been following Parrot and Perl 6 from the start and in the shadows.
As an extreme Perl 5 enthusiast and general language geek, I can say
that for me (and I might be the only one), from the start calling it
"Perl 6" has caused a stumbling block for me. I know, it's
a bikeshed - but a name speaks volumes to me. For one, you have to
automatically explain to someone familiar with Perl 5 (your most
obvious target user base) how it is different. What I suggest below is
superficial, but I believe semantically significant the the branding
of what the project is attempting to accomplish. If anything, my
suggestions below would make it easier for me (as a beginner to Perl
6, but not to Perl 5 or a host of other interesting languages) to join
in the fun.
A lot of cool new languages have surged in popularity since Perl 6 was
started (e.g., Go, Chapel, D, Qore, etc), and so has one particular
old one - Perl 5 (for a lot of good reasons, including the benefits
trickling down from Perl 6).
As an outside observer and long time fan, Perl 6 for me is more of a
formalization of the Perl language as it evolved (greatly influenced
by non-languages, such as Unix itself and natural language goals).
But, the truth is that it's not Perl 5 and it's not meant to replace
it (right?). It's an evolutionary step as the language itself moves
towards a more formalized specification. My point is that while it
started out as a way to improve/formalize Perl 5, it's developed
sufficiently to the point where it is its own language and not the
"next" version of 'perl'.
>
> In the long run, we need a book for beginners too.
>
> An attempt to write materials for beginners is at.
> https://github.com/perlpilot/perl6-docs/
>
> But much more is needed. Please help us with it.
>
Rebranding this as a new language is one step in the right direction.
Having the language called the same thing as whatever the defacto
reference implementation is would be a nice way to go. But it's more
than just a name to me, it's a signal saying that it's okay to stop
thinking of Perl 6 in terms of Perl 5 - and therefore it won't be
necessary to unlearn what I already know and love; rather, it'll allow
me to tap into the part of my brain that is willing and ready to learn
new languages.
Perhaps simply renaming the specification (OpenPerl?) and allowing the
reference implementation (Rakudo) to take center stage.
The Rakudo site has yet another caveat to the "Perl 6 is not Perl 5"
baggage:
"In the Perl 6 world, we make a distinction between the language
('Perl 6') and specific implementations of the language such as
'Rakudo Perl'."
Seriously, this is a ridiculous and unnecessary qualification (IMO).
The most it should say is something like, "Rakudo is the reference
Re: The trouble with awesome
Hello Estarde,
(since I'm the 'new' guy in the community, I think only I have the energy
to explain it to you :-)
Well, try to think of Perl 6 as a human. Of course you can change a
person's name, but who will go to the trouble of it all? eh? After all, we
all know how some Mr. XYZ father likes to name his son as XYZ, Jr. And we
accept the trifle confusions it creates.
It has been now almost 12 years since Perl6's conception, renaming it will
be like renaming a person. A whole lot of confusion...
Your problem is, the second you see '6', you instantly think of it as
'5+1'. Had Larry Wall named it 'Perl 666' you would never have stumbled on
the name :p
I suggest you just accept it.
That said, please don't let a name come between you and a wonderful
programming language. After all, Wordsworth has said, "What's in a name?"
>"In the Perl 6 world, we make a distinction between the language
> ('Perl 6') and specific implementations of the language such as
> 'Rakudo Perl'.
> Seriously, this is a ridiculous and unnecessary qualification (IMO).
> The most it should say is something like, "Rakudo is the reference
> implementation of the OpenPerl (formerly known as Perl 6).
Rakud is not _the_ reference implementation of Perl 6. Actually, there is
no reference implementation for Perl 6. There never will be. Whoever wants
to make a perl6 implementation is free to do so. Just follow the spec and
you get to label your compiler as a Perl6 implementation. yay !
>For that matter, I also shouldn't have to be hit with the fact that
>it's built on Parrot. We don't have to get reminded that Java is based
>on a JVM each time it's mentioned. Let's let that fade to the
>background, too. (Yes it's cool, but language enthusiasts will soon
>discover this on their own).
That's just our hubris leaking through. "We made a VM just for Perl 6!".
Which by the way, can now actually run several other languages.
> Sorry if all of this has been bandied about before, but if you're
Yes, it has been. But we don't mind.
If you have further questions, please feel free to ask more here or on the
perl6-users mailing list or the #perl6 IRC Channel on freenode.net. #perl6
is a great place to hangout and learn. I go by the name of 'sisar' there.
Cheers,
Siddhant
Re: The trouble with awesome
> My point is that while it > started out as a way to improve/formalize Perl 5, it's developed > sufficiently to the point where it is its own language and not the > "next" version of 'perl'. But it is still a version of Perl. It might not be the "next" version of Perl, but it certainly the sixth version of Perl. If you think that the difference between Perl 5 and Perl 6 is too big to still call Perl 6 "Perl", then compare some early FORTRAN code to idiomatic Fortran 2008 code. On 05/25/2012 03:44 PM, B. Estrade wrote: > Rebranding this as a new language is one step in the right direction. > Having the language called the same thing as whatever the defacto > reference implementation is would be a nice way to go. But it's more > than just a name to me, it's a signal saying that it's okay to stop > thinking of Perl 6 in terms of Perl 5 - and therefore it won't be > necessary to unlearn what I already know and love; rather, it'll allow > me to tap into the part of my brain that is willing and ready to learn > new languages. > > Perhaps simply renaming the specification (OpenPerl?) and allowing the > reference implementation (Rakudo) to take center stage. All those people who propose a rebranding assume that a good name will just be found with a bit of thought. So far I haven't heard a single good one. (OpenPerl? I don't think Perl 6 is more open than Perl 5 on any measurable level; and if it is, it's not the main difference) And no, Rakudo is not "the" and not even "a" reference implementation. It is an implementation, period. There's nothing that makes it more "official" or "reference" than Niecza, for example. Just like GCC is not more "official" or "reference" to C than is Clang, ICC, TCC or whatever.
