If Perl 6 had been presented from the start as an experimental 'sister language' (perhaps with a different name), rather than being named as Perl 5's successor over a decade early, perhaps the perception would now be different.
People express that sentiment often, but I've never found it realistic. Many of the philosophical goals of Perl 6 are the same philosophical goals Larry had when designing Perl 5. Many of the tactical approaches are far different, but there's where my disagreement with the "It deserved the label as an experiment at the time!" idea arises. No one really knew how far redesigning Perl needed to go to achieve those philosophical goals until the RFCs and Apocalypses started pulling at loose strings in the sweater.
Isn't your term 'Modern Perl' itself a way of saying that things have changed a bit since 1993, even though we're still using 'Perl 5'?
Certainly, though it's less about using new and exciting features because they're new and exciting than it is about understanding how the language and its features, both new and old do—and, in some cases, don't—work. The biggest and most important language change has been the gradual lexicalizing of features such as filehandles, pragmas, grammar modifications, and even packages. You may have to squint to see the latter, but it's there. Perl 6 takes that principle to another level.
With better PR, Perl 5.10 could easily have been 'Perl 6'.
That would have been extremely silly.
Modern Perl 5 is a good language with great libraries, but Perl 5 still has many, many flaws that only breaking backwards compatibility in a very dramatic way could fix. You can take the Perl 5.10 approach of deprecating a few of the worst offenders and considering removing them and eventually replacing them, but that process will take decades.
Also, the Perl 5 core is very, very difficult to maintain.
I do something similar with the book Modern Perl. Electronic versions are free and freely redistributable. Download numbers are at least 10 or 20 times the number of sales of the printed version, but I've made more in royalties than I'd ever see from a so-called "traditional" publisher, as I earn at least eight times as much per copy sold than I would.
If you can find a reputable publisher who won't give you the awful 10-15% of wholesale, or if you can find a credible editor and copyeditor to look over your work, self-publishing or small-press publishing is a much, much better way to make money writing books, even if you give away electronic versions.
I find Apple's practices unethical with regard to the app store and the artificial limits they've put upon general purpose computing hardware sold directly to customers; thus it's an ethical question for me. I choose not to reward them with my money, regardless of the quality of hardware or the ease of jailbreaking.
Not everyone shares my concerns and that's fine—but to me the question "What kind of world would I like to see?" influences my purchasing decisions.
Suppose that the wholesale price of a book is 50% of the cover price. Suppose that your royalty rate is 10% of that. Suppose that you, like me, end up doing almost all of the editing and almost all of the marketing of the book. Has your publisher really earned 90% of the value of that wholesale price?
(The marketing plan for one of my books—I am not making this up—appears to be "The editor will mention it in a Tweet once every six weeks".)
I signed the contracts and blame no one else but myself for that, and I certainly begrudge the publisher nothing for taking on the risk of publishing the book and managing distribution and sales channels. That provides value.
Yet given the lack of editing, production, and marketing, the publisher has not convinced me that it deserves 90% of the revenue. It certainly didn't do 90% of the work.
I can't believe that it's a good idea to make kids learn about line numbers, with all of the associated complexity, rather than to use a simple text editor.
I've gone back and forth on that myself, but ultimately we're sticking with line numbers in the dialect we have there now for simplicity sake. You hit on this when you mention a simple text editor: either we implement that text editor to keep our zero-installation cross-browser footprint, or we allow people to use their own text editors and take the hit of setup and configuration.
Further, then we have to find another mechanism to distinguish between immediate commands and commands to store to create a program or else explain the REPL concept early. We'll also have to explain using named labels or even user-defined functions.
Remember, we're talking about teaching motivated eight year olds.
I agree that it's possible, but we decided that rather than producing a stripped-down version of Python or Scheme or Smalltalk which runs client-side in the browser and includes graphics primitives, we'd enhance a simpler language designed for teaching. Remember, we're not trying to produce professional programmers. We're trying to produce people who see computers as tools which they can use to create, not just consume.
Personally, I'd recommend Python as a starting language...
I might, if there were a simple, cross-platform, one-click-install download bundle for all of the major operating systems which included pygame and a decent IDE, and even then I'd target motivated 13 year olds as the youngest users.
If I were trying to teach motivated ten year olds in person, I might choose Python/pygame as well.
That's not our goal, though. We're trying to help motivated eight year olds discover the joy of programming as a means of using computers as creative tools, not to produce millions of practical programmers.
But theres an entire lobby of MPAA, RIAA and various book publishers who want s a piece of the cake, and if theres' only one slice available, then how can they afford to pay the author ?
In my case, I choose not to work with selfish publishers.
If I'm going to do much of the editing of the book and if I have to do most of the marketing for the book, then why would I work with a publisher who'll give me only 5% of the revenue?
I've just done this with the book Modern Perl. Rather than punishing paying customers with DRM or trying to track down and stop copyright infringement, my publisher gives away electronic versions for free and asks readers to spread them to other people, to write reviews, and to consider donating a reasonable value for the information.
So far I've earned more money more quickly than I would have with the traditional publishing model.
The implication is that, without Moose, Perl 5 is difficult, inconsistent, and tedious.
That inference may go too far. Perl 5's default OO is flexible and powerful, but it goes too far in allowing flexibility and it doesn't promote an obvious best way for most projects. As with any abstraction which offers and takes advantage of defaults, Moose reduces complexity and makes it easier to write consistent and concise code.
... the quality control for Moose?
I'm certain many CPAN contributors will welcome an automated testing system to find non-spelling documentation typos. That'll be a very nice addition to the extensive test suites for Moose and other important CPAN distributions.
Thanks for reporting the typo, though. I'm fixing it in the repository right now.
Perl6.org, and specifically Camelia, do not say "fun", or anything about sterile environments or anything about clarity.
I question this.
The argument that "No one will ever take a programming language seriously because it has a cartoon butterfly for a logo! Are you six years old?" says a lot more about the arguer than the logo or the language or the community. At least it suggests to me that I would not enjoy working with the person making that argument.
Have you considered hiring good developers and then teaching them OO Perl? If your workplace uses Moose, for example, writing good OO Perl 5 is surprisingly easy and effective.
Ruby also has a lot of the OO built in that you need Moose for in perl.
I use plenty of Moose features that Ruby doesn't have (and I find Perl's module and importing mechanism far more powerful than Ruby).
Most of the language features can fit in the average person's head at all times, allowing you to focus on writing cleaner code.
I don't believe that. Count the number of methods on core classes sometime.
Blocks make a lot of code less error prone, because a file open block will automatically cleanup and close the file when your code has finished.
Blocks are nice, but properly scoped lexical variables in Perl have this property as well. As a bonus, Perl gets lexical scoping right and readable, unlike both Python and Ruby.
Slashdot Mirror
People express that sentiment often, but I've never found it realistic. Many of the philosophical goals of Perl 6 are the same philosophical goals Larry had when designing Perl 5. Many of the tactical approaches are far different, but there's where my disagreement with the "It deserved the label as an experiment at the time!" idea arises. No one really knew how far redesigning Perl needed to go to achieve those philosophical goals until the RFCs and Apocalypses started pulling at loose strings in the sweater.
Certainly, though it's less about using new and exciting features because they're new and exciting than it is about understanding how the language and its features, both new and old do—and, in some cases, don't—work. The biggest and most important language change has been the gradual lexicalizing of features such as filehandles, pragmas, grammar modifications, and even packages. You may have to squint to see the latter, but it's there. Perl 6 takes that principle to another level.
That would have been extremely silly.
Modern Perl 5 is a good language with great libraries, but Perl 5 still has many, many flaws that only breaking backwards compatibility in a very dramatic way could fix. You can take the Perl 5.10 approach of deprecating a few of the worst offenders and considering removing them and eventually replacing them, but that process will take decades.
Also, the Perl 5 core is very, very difficult to maintain.
Strawberry Perl 5.14 may wait for 5.14.1 in a month.
The free book Modern Perl explains how to use Perl 5 in an effective and maintainable fashion.
Perl allows trailing commas at the ends of lists to make maintenance easier. I often wish for such a feature in other languages.
I do something similar with the book Modern Perl. Electronic versions are free and freely redistributable. Download numbers are at least 10 or 20 times the number of sales of the printed version, but I've made more in royalties than I'd ever see from a so-called "traditional" publisher, as I earn at least eight times as much per copy sold than I would.
If you can find a reputable publisher who won't give you the awful 10-15% of wholesale, or if you can find a credible editor and copyeditor to look over your work, self-publishing or small-press publishing is a much, much better way to make money writing books, even if you give away electronic versions.
I find Apple's practices unethical with regard to the app store and the artificial limits they've put upon general purpose computing hardware sold directly to customers; thus it's an ethical question for me. I choose not to reward them with my money, regardless of the quality of hardware or the ease of jailbreaking.
Not everyone shares my concerns and that's fine—but to me the question "What kind of world would I like to see?" influences my purchasing decisions.
Perhaps you mean "buy a used iPad". Why would I give Apple money for a product that doesn't do what I want?
Suppose that the wholesale price of a book is 50% of the cover price. Suppose that your royalty rate is 10% of that. Suppose that you, like me, end up doing almost all of the editing and almost all of the marketing of the book. Has your publisher really earned 90% of the value of that wholesale price?
(The marketing plan for one of my books—I am not making this up—appears to be "The editor will mention it in a Tweet once every six weeks".)
I signed the contracts and blame no one else but myself for that, and I certainly begrudge the publisher nothing for taking on the risk of publishing the book and managing distribution and sales channels. That provides value.
Yet given the lack of editing, production, and marketing, the publisher has not convinced me that it deserves 90% of the revenue. It certainly didn't do 90% of the work.
I've lost more money to publishers than I have to copyright infringement.
(My current publisher and I give away the electronic versions of Modern Perl: the book for free.)
Thanks, I'll take a look at the VPRI project. That's very tempting.
Try it yourself. Find a smart eight year old, then ask her to make a list of instructions for a task with obvious multi-step loops.
I've gone back and forth on that myself, but ultimately we're sticking with line numbers in the dialect we have there now for simplicity sake. You hit on this when you mention a simple text editor: either we implement that text editor to keep our zero-installation cross-browser footprint, or we allow people to use their own text editors and take the hit of setup and configuration.
Further, then we have to find another mechanism to distinguish between immediate commands and commands to store to create a program or else explain the REPL concept early. We'll also have to explain using named labels or even user-defined functions.
Remember, we're talking about teaching motivated eight year olds.
That's a lot more development work for little (or no) benefit. We don't want to bundle Python. We want to teach kids to create things with computers.
I agree that it's possible, but we decided that rather than producing a stripped-down version of Python or Scheme or Smalltalk which runs client-side in the browser and includes graphics primitives, we'd enhance a simpler language designed for teaching. Remember, we're not trying to produce professional programmers. We're trying to produce people who see computers as tools which they can use to create, not just consume.
I might, if there were a simple, cross-platform, one-click-install download bundle for all of the major operating systems which included pygame and a decent IDE, and even then I'd target motivated 13 year olds as the youngest users.
If I were trying to teach motivated ten year olds in person, I might choose Python/pygame as well.
That's not our goal, though. We're trying to help motivated eight year olds discover the joy of programming as a means of using computers as creative tools, not to produce millions of practical programmers.
If Perl 5's default OO is the wrong choice, how is Python's OO the right choice? Syntactic differences aside, they're the same system.
I'm sure some people agree with that sentiment. I don't agree that most or all people do.
In my case, I choose not to work with selfish publishers.
If I'm going to do much of the editing of the book and if I have to do most of the marketing for the book, then why would I work with a publisher who'll give me only 5% of the revenue?
I've just done this with the book Modern Perl. Rather than punishing paying customers with DRM or trying to track down and stop copyright infringement, my publisher gives away electronic versions for free and asks readers to spread them to other people, to write reviews, and to consider donating a reasonable value for the information.
So far I've earned more money more quickly than I would have with the traditional publishing model.
Perhaps to you.
Do you speak for everyone outside of what you've defined as "the Perl community"?
That inference may go too far. Perl 5's default OO is flexible and powerful, but it goes too far in allowing flexibility and it doesn't promote an obvious best way for most projects. As with any abstraction which offers and takes advantage of defaults, Moose reduces complexity and makes it easier to write consistent and concise code.
I'm certain many CPAN contributors will welcome an automated testing system to find non-spelling documentation typos. That'll be a very nice addition to the extensive test suites for Moose and other important CPAN distributions.
Thanks for reporting the typo, though. I'm fixing it in the repository right now.
I question this.
The argument that "No one will ever take a programming language seriously because it has a cartoon butterfly for a logo! Are you six years old?" says a lot more about the arguer than the logo or the language or the community. At least it suggests to me that I would not enjoy working with the person making that argument.
Have you considered hiring good developers and then teaching them OO Perl? If your workplace uses Moose, for example, writing good OO Perl 5 is surprisingly easy and effective.
So does Perl, with perlbrew.
I use plenty of Moose features that Ruby doesn't have (and I find Perl's module and importing mechanism far more powerful than Ruby).
I don't believe that. Count the number of methods on core classes sometime.
Blocks are nice, but properly scoped lexical variables in Perl have this property as well. As a bonus, Perl gets lexical scoping right and readable, unlike both Python and Ruby.