Re: The trouble with awesome
On Mon, Jun 4, 2012 at 12:01 AM, Peter Scott pe...@psdt.com wrote: We need multiple paths. The term beginner creates problems I meant beginner with respect to Perl 6, but I think that Peter basically paraphrased my arguments about the problem. Although programming experience is an important variable, after one's third (or so) language, especially among related languages like the C family, there are few surprises, just choices. How much complexity the learner wishes to absorb depends on the level of their problem. There is no point in offering solutions more complicated than the original issue, especially to someone who would really rather not be solving them in the first place. (You might be surprised at the number of people who will assert that I'm not really a programmer, in a tone that suggests it's a social status only slightly above paedophile.) They program because their real job requires it.
Re: The trouble with awesome
On Tue, 22 May 2012 19:35:34 -0400, Parrot Raiser wrote: 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. We need multiple paths. The term beginner creates problems just by using it because there are several incompatible types of beginner, and the complexity of Perl 6 exacerbates this multiplicity. I see at least these entry points: - Never coded anything in any kind of language before - Experienced in Perl 4 (many Perl 5 programs are really just Perl 4) - Experienced in Perl 5 - Experienced in other dynamic languages (PHP/Python/Ruby/JavaScript) - Experienced in other nondynamic languages Another dimension is the learning style of any of the above. Virtually everyone reading this belongs to a small proportion of the programming population: early adopters. Most of you would learn Perl 6 even if the only documentation was written in Klingon and secreted in the small intestines of a rabid vole. Increasingly larger proportions of the population require greater levels of assistance; the next group is satisfied with a relatively complete reference document, then we have people who need tutorials, people who need live instructors and/or examples, other media like video, feedback from mentors, and so on. There's nothing new in this breakdown, but why I see it as being important to consider when constructing Perl 6 educational materials is the sheer depth of the language. This is the most incredible language ever created. If it weren't, it wouldn't have taken this long to build. It's beyond the ability of most programmers to encompass the whole language within their brains. Attempting to feed them the entire thing would be like pushing them into the Total Perspective Vortex. I suggest we think in terms of useful subsets of the language that can be assimilated by mortals, documenting the more esoteric parts behind For When You Are Ready banners. I have found that learning is mostly driven by thinking about what you leave out (or leave until later). Otherwise you could just throw the Camel at people and be done. That works only on a very few. Those subsets might be broken down by the categories I list above, or by application domain, or educational background (CS major/ other), or something else. When Perl 4 came out, you could count on most of the people learning it to have a CS background (and the rest were sysadmins). Now the landscape looks very different. -- Peter Scott
Re: The trouble with awesome
On Wed, May 30, 2012 at 6:00 AM, Moritz Lenz mor...@faui2k3.org wrote: I'd still start with simple script files, because that's what most programmers are most familiar with. I'd do them in Huffman order; the interpreter involves the least typing to start, and it's useful for demonstrating concepts. Usually, an abstract principle needs some specific examples to clarify it. Where would you put nested data structures and custom classes? Assuming you're talking about things like arrays of arrays, I'd put them between structured and unstructured data. A simple table of results by month can get into that sort of structure. Custom classes are definitely around the higher order.
Re: The trouble with awesome
On Mon, May 28, 2012 at 01:54:53PM -0500, B. Estrade wrote: On Mon, May 28, 2012 at 03:38:48PM +0800, Xiao Yafeng wrote: On Sat, May 26, 2012 at 6:34 PM, Nicholas Clark n...@ccl4.org wrote: On Fri, May 25, 2012 at 08:44:30AM -0500, B. Estrade wrote: Realistically, that's not going to happen. The internals of the Perl 5 interpreter are not flexible enough to implement a lot of the features that Perl 6 has that Perl 5 does not. Nicholas Clark * Or Python 2 to Python 3, as far as I can tell as an outsider. why can't we write a brand new perl5 interpreter or a better one based on parrot VM if perl6's strength more than perl5 is just internals of the interpreter? For some value of we? Are you volunteering - I expect not. I'm not either. In that a) it's a resourcing problem. It's probably going to take more than one person more than one year, full time. Or, therefore, a lot more than one year as a spare time project. The great thing about Parrot and subsequently the various projects that have worked to implement Perl 6 is that they've not stolen existing Perl 5 contributors. They seem to have grown the available pool of people. It's not clear whether starting now on an official rewrite would be able to do this, or whether it would reduce the (already low) number of people working on the existing Perl 5 codebase b) Personally, I'm not sure if it's worth it. What does it gain? You still have all the warts of the Perl 5 language. It's a 16 to 22 year old basic design, with at least a decade of improvements wedged in the holes in the original syntax. The stuff that Perl 6 (the language) is working to solve. Such as typeglobs (and their implications), barewords no concept of types (other than scalar/list and not-a-reference/reference-to-FOO), and that anything can turn out to be tied. (Which kills your ability to JIT compile it) It's also not clear how much of the language is actually exposing the warts of the existing C implementation. Such as the operators that behave differently on strings or numbers (++ and the bitwise operators) (this behaviour change being despite the lack of real types. ie, a hack) Then there is the choice of which language to implement in. The great strength of Perl 5 is all the code on CPAN. A lot of the code on CPAN depends on other code on CPAN, and high up many of the dependency trees are XS modules. XS relies on talking C to the internals. And, often, that the internals behave the current way. So if one has a C-re-write, where is the trade off between supporting existing XS code (and keeping the current internal uglies), and being clean but incompatible? And if one elects to target a different VM, such as Java or .NET i) how much of CPAN is no longer available due to XS? ii) how much code simply can't cope with DESTROY not happening at the right time due the VM's garbage collector? And at the end of all this, it won't completely replace the use of the existing Perl 5 implementation, so that still needs to be maintained. However, that's my personal view. I'm not stopping anyone else trying (and I'm interested to see how it pans out). I'm only aware of one project trying it, Perlito, which is working to compile Perl 5 to JavaScript: http://perlito.org/ and https://github.com/fglock/Perlito That's what Ponie is/was, right? Not quite. Ponie was an attempt to refactor the existing Perl 5 interpreter codebase and graft it onto Parrot. I think there is a major disconnect with providing a standard interpreter versus providing implementations of language versions. It's less about making /usr/bin/perl (Perl 5) work on Parrot and more about providing a /usr/bin/perl6 on every machine and a chicken in every pot. In otherwords, people are more tied to the actual binary program called 'perl' than anything else. It's not about Perl 5 vs Perl 6, it's about either getting 'perl' as Perl 6ish as possible or introducing a new utility in /usr/bin (hence my earlier suggestion of a name change or reference imlementation/one_true_implementation^tm). How man awks or greps come on a standard system these days? More than one. I would not be against seeing various perls - eperl, zperl, 6perl, qperl, rperl, c++perl, jerl, etc. I'd have no problem with this, but don't underestimate how much work it is to implement any of them. The way out is to quantify how well /usr/bin/perl implements the Perl 6 formalization - the level to which this is true would define how far Perl 5 is from being Perl 6 compliant. Of course, this would As Perl 6 compliant is (I think) defined by does it run the Perl 6 spectests, you're welcome to try doing this. I suspect that it will pass approximately zero, due to several significant basic syntax changes between Perl 5 and Perl 6, which Perl 5 isn't ever going to be able to
Re: The trouble with awesome
Am 26.05.2012 21:12, schrieb Parrot Raiser: 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. However experienced a programmer may be, there are certain minimum levels of knowledge one needs to get into a new language. What class of language is it? Machine code, assembler, compiler, interpreter, executed from source, like Java? (Obviously, we know that, but for the few sentences it takes to explain it, it might as well be stated anyway for newcomers.) A couple of paragraphs can explain where it might be expected to run, and what's required to start using it. Indeed, rereading the preface, it seems we don't mention what kind of language it is. I'll try to fix that later. That's the purpose of Hello, world programs; not to babble inane greetings, but to show simply to run something in the language. Even there, Perl 6 is unusually rich in options; interactive mode, command line, argument, and stand-alone executable. Each step requires slightly more input, so that's the order I would introduce them. I'd still start with simple script files, because that's what most programmers are most familiar with. When introducing a programming language, as opposed to teaching programming from scratch, it should not be necessary to explain what a variable is, or why decision statements are required. The reader's questions are more in the nature of what's a valid variable name or how are blocks bounded? Without the basics of of statement syntax, variable name rules, block structure, how decisions are delimited, and how to iterate, how does one interpret more complex concepts? Certainly, they can be explained by reference to some previous standard; The rules for are exactly the same as in Perl 5, except when . These rules are .. That allows the Perl maven to skip forward enlightened, and the beginner to keep learning. Learning's a process of building on previous foundations, and so is programming. Somebody creating simple tabulations may never need the techniques of the compiler writer, but the compiler creator had to learn the rules for variable names. Agreed. We need to get better on this front. Maybe insert a small cheat cheat before the 'Basics' chapter. But much more is needed. Please help us with it. Specifying the problem was meant to be the first step. I wanted to get the discussion going, (but not the bikeshedding about the language name). For the author of Perl 6 documentation, the problem is knowing the language well enough to see the logical stages to extend basic concepts and introduce new ones. Where are the rings of the onion? For example, double and single ' quotes are pretty much essential from the start; when do the alternative forms begin to be necessary? I see at least 3 levels of complexity, demanding increasing levels of sophistication; basic computation on streams of structured I/O, manipulation of unstructured data, like text, and higher order work, like program-creating programs, compilers,c. Does this seem like a reasonable taxonomy, or are other groupings a better fit? Where would you put nested data structures and custom classes? At the beginning of the higher order work? Apart from that, it sounds quite well. Cheers, Moritz
Re: The trouble with awesome
On Sat, May 26, 2012 at 05:34:18AM +0530, Siddhant Saraf wrote: Rakud[o] 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 ! Just a very minor technical nit (to help preserve clarity): Perl 6 is anything that passes the test suite, which is not necessarily the same as the specification. See Synopsis 1. (Yes, this means the synopses can also contain bugs, and we can and do file bug reports on the synopses themselves.) Pm
Re: The trouble with awesome
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. However experienced a programmer may be, there are certain minimum levels of knowledge one needs to get into a new language. What class of language is it? Machine code, assembler, compiler, interpreter, executed from source, like Java? (Obviously, we know that, but for the few sentences it takes to explain it, it might as well be stated anyway for newcomers.) A couple of paragraphs can explain where it might be expected to run, and what's required to start using it. That's the purpose of Hello, world programs; not to babble inane greetings, but to show simply to run something in the language. Even there, Perl 6 is unusually rich in options; interactive mode, command line, argument, and stand-alone executable. Each step requires slightly more input, so that's the order I would introduce them. When introducing a programming language, as opposed to teaching programming from scratch, it should not be necessary to explain what a variable is, or why decision statements are required. The reader's questions are more in the nature of what's a valid variable name or how are blocks bounded? Without the basics of of statement syntax, variable name rules, block structure, how decisions are delimited, and how to iterate, how does one interpret more complex concepts? Certainly, they can be explained by reference to some previous standard; The rules for are exactly the same as in Perl 5, except when . These rules are .. That allows the Perl maven to skip forward enlightened, and the beginner to keep learning. Learning's a process of building on previous foundations, and so is programming. Somebody creating simple tabulations may never need the techniques of the compiler writer, but the compiler creator had to learn the rules for variable names. But much more is needed. Please help us with it. Specifying the problem was meant to be the first step. I wanted to get the discussion going, (but not the bikeshedding about the language name). For the author of Perl 6 documentation, the problem is knowing the language well enough to see the logical stages to extend basic concepts and introduce new ones. Where are the rings of the onion? For example, double and single ' quotes are pretty much essential from the start; when do the alternative forms begin to be necessary? I see at least 3 levels of complexity, demanding increasing levels of sophistication; basic computation on streams of structured I/O, manipulation of unstructured data, like text, and higher order work, like program-creating programs, compilers, c. Does this seem like a reasonable taxonomy, or are other groupings a better fit?
Re: The trouble with awesome
On Mon, May 28, 2012 at 03:38:48PM +0800, Xiao Yafeng wrote: On Sat, May 26, 2012 at 6:34 PM, Nicholas Clark n...@ccl4.org wrote: On Fri, May 25, 2012 at 08:44:30AM -0500, B. Estrade wrote: Realistically, that's not going to happen. The internals of the Perl 5 interpreter are not flexible enough to implement a lot of the features that Perl 6 has that Perl 5 does not. Nicholas Clark * Or Python 2 to Python 3, as far as I can tell as an outsider. why can't we write a brand new perl5 interpreter or a better one based on parrot VM if perl6's strength more than perl5 is just internals of the interpreter? That's what Ponie is/was, right? I think there is a major disconnect with providing a standard interpreter versus providing implementations of language versions. It's less about making /usr/bin/perl (Perl 5) work on Parrot and more about providing a /usr/bin/perl6 on every machine and a chicken in every pot. In otherwords, people are more tied to the actual binary program called 'perl' than anything else. It's not about Perl 5 vs Perl 6, it's about either getting 'perl' as Perl 6ish as possible or introducing a new utility in /usr/bin (hence my earlier suggestion of a name change or reference imlementation/one_true_implementation^tm). How man awks or greps come on a standard system these days? More than one. I would not be against seeing various perls - eperl, zperl, 6perl, qperl, rperl, c++perl, jerl, etc. The way out is to quantify how well /usr/bin/perl implements the Perl 6 formalization - the level to which this is true would define how far Perl 5 is from being Perl 6 compliant. Of course, this would be a non-Parrot implementation. There is nothing saying Perl 6 compliant interpreters have to be written in Parrot; Parrot just provides an abstraction layer that allows there to be a cleaner separation between the compiler/interpreter and some of the complex things that need to be done to enable the features of Perl 6. Just throwing more out there as an outsider, but someone who really wants very badly to have a reason and simple way to start using it for stuff. cheers, Brett it seems Gcc community had a similar discussion about mess of internal. http://gcc.gnu.org/ml/gcc/2012-03/msg00263.html
Re: The trouble with awesome
On Sat, May 26, 2012 at 6:34 PM, Nicholas Clark n...@ccl4.org wrote: On Fri, May 25, 2012 at 08:44:30AM -0500, B. Estrade wrote: Realistically, that's not going to happen. The internals of the Perl 5 interpreter are not flexible enough to implement a lot of the features that Perl 6 has that Perl 5 does not. Nicholas Clark * Or Python 2 to Python 3, as far as I can tell as an outsider. why can't we write a brand new perl5 interpreter or a better one based on parrot VM if perl6's strength more than perl5 is just internals of the interpreter? it seems Gcc community had a similar discussion about mess of internal. http://gcc.gnu.org/ml/gcc/2012-03/msg00263.html
On fashion, in Re: The trouble with awesome
On 05/23/2012 03:35 AM, Parrot Raiser wrote: Perl 6 is awesome. agreed snip 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. Not convinced 'getting it adopted' should be a goal in itself. A major goal is to ensure perl6 implementations can be utilized in every relevant environment. We have unix and windows, but I'm not sure we have android or iOS. And other important environments include browsers (scripts embedded in html). The popularity of a language amongst programmers seems to be a function of fashion and ease of doing something that is fashionable. So perl became THE language for the internet at one time because it linked in so easily to the scripting url syntax. php became popular due to the ease of mixing html code with scripting language, and so on. Personally, I would like to be able to write perl6 scripts (even if only a subset of perl6 was available) that can be embedded in html files. Since perl6 is just so much more elegant than javascript, it would attract a lot of programmers. Fashion is not everything of course. perl was well designed, so even though the internet fashion for perl declined, to be replaced by other languages, programmers continue to use it for other reasons. For the same reason, once perl6 infects the programmer population, it will be used more widely because it is well designed. At some point, I think, there will be a fashionable problem area which will be most easily solved using perl6 - eg., the grammar aspect is just so different from anything else I have seen that I am sure it will find a use. In short, the gap between the status of perl6 as an interesting phenomenon for computer language scientists and the status of perl6 as a widespread standard for programming will be bridged - I suggest - by the appearance of a killer problem domain, a type of problem that is faced by many programmers and which is more easily handled in perl6 than in any other language. It would also help for perl6 activists to demonstrate just how well perl6 works in that domain, and that will require tutorials, articles, etc. So educational texts are important, but secondary to the problem domain. snip 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. Crucial to this post is the set of assumptions around 'average user', assumptions that appear to me to be US-centric. The population of programmers resident outside the USA will soon exceed (if it has not already exceeded) the number within the USA. perl6 has been designed to be agnostic to human readable languages and scripts, and that might have an effect too if it is easier in perl6 to deal with non-English texts.
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.
Re: The trouble with awesome
On Fri, May 25, 2012 at 08:44:30AM -0500, B. Estrade wrote: 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'. If Perl 6 is successful, long term it will replace Perl 5, in the same way that Perl 5 replaced Perl 4. Increasingly, new projects will be written in Perl 6, and eventually all the old projects using Perl 5 will retire. But this will take a long time - much longer than the transition from Perl 4. With Perl 4 to Perl 5, it was the same people releasing Perl 5 as had worked on Perl 4, so all development stopped on Perl 4 when Perl 5 came out. Not just new features, but bug fixing and maintenance releases.* There is much less overlap between the people working on the Perl 6 and Perl 5, so Perl 5 isn't suddenly going to stop when a production ready post early adopter Perl 6 implementation ships. But once Perl 6 starts to close the gap on the areas where Perl 5 currently leads, then the for more and more people the advantages of choosing Perl 6 over Perl 5 will start to outweigh the disadvantages. And finally, if the formalization becomes known as OpenPerl or something as standards sounding, then the 'perl' interpreter (aka Perl 5), can clearly state as a goal something like, progress towards the OpenPerl standard while maintaining strict backward compatibility with insert qualification. All of a sudden you have a Perl family Realistically, that's not going to happen. The internals of the Perl 5 interpreter are not flexible enough to implement a lot of the features that Perl 6 has that Perl 5 does not. Nicholas Clark * Or Python 2 to Python 3, as far as I can tell as an outsider.
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
implementation of the OpenPerl (formerly known as Perl 6).
For that
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
