That sounds like an excellent way to create a maintenance and troubleshooting nightmare.
Apply discipline and discretion appropriately, as you would if you worked on a project with HTML, CSS, SQL, JavaScript, a templating system, and some other server-side language.
How many of those releases could anyone confidently use in place of Perl 5 in a production environment?
You changed your argument (from "You haven't released any software!" to "I don't think I would use the software you released!".) Even so, the amount of confidence anyone has in any particular Rakudo release depends on who that anyone is, what that anyone uses Perl 5 to accomplish, and what a production environment means to that anyone.
Clearly we are not using the same definition of a "production" release.
Clearly, but that was the point of my post. I won't use PHP or C++ in production, despite the fact that many businesses do successfully.
If you try to cram all possible meanings of all possible uses into a single word, you overload it past the point of meaning. Patrick's goal with Rakudo Star is to release something that many people will find useful and usable. Whether you want to deploy it in a production setting is entirely up to you; we refuse to make that decision for you.
Whether it's useful in production depends on who you are, what you do, and what production means to you.
If I had a couple of libraries ported from Perl 5 to Perl 6 (simplified greatly by new features of Perl 6, of course), I'd use Rakudo in the core of my business. I might do that as of the Rakudo Star release.
I'm going to release the 24th stable monthly version of Rakudo Perl 6 in a couple of weeks. How many more releases do we have to release to meet that mythical bar of "shipping"?
For an interpreted language, well, all that tokenization and such, even with JIT compilation, means at least once, your app is going to get kind of clunky.
Do you mean tokenization in the parsing process? If that overwhelms the profile of the program, either the implementation has an awful, awful parser or the program executes so quickly that it's not worth optimizing.
I'd prefer to strictly use objects to scope variables which need controlled....
That includes loop iterators (yes, I know these are rare in Ruby with pervasive blocks) and block-local variables not declared as incoming parameters. I'm curious to see idiomatic Ruby code written using only instance variables where a more straightforward approach would use lexicals. (Don't forget that if you have a method_missing on the object, you have more work to do to catch variable typos.)
I remember multiple debates over scoping changes between Ruby 1.8 and Ruby 1.9. That debate wouldn't have happened if scoping were more explicit.
Sigils are a different story. In Perl, they exist for two reasons: to provide additional namespaces to disambiguate builtin and user-defined symbols and to provide compile-time context hints. The latter doesn't apply to Ruby.
The dominant meaning of "translate" used by native English speakers generally implies some non-zero amount of veracity.
Cardinal hasn't had much activity in the last couple of months because there have been only a couple of people working on it lately, and one of them started a new job at the end of September.
Even so, it exists, it passes tests, and it can interoperate in the same Parrot process with Perl 6 and Perl 5 code. (I suspect it can work with other Parrot-hosted languages as well, but I haven't tried.)
You claimed that Ruby kept most of the syntax of Perl, but not the 'semantics' whatever that means in this context.
You gave a great example yourself:
[In Ruby,] you don't have to declare variables with a prefix....
That tiny syntactic change -- which you describe as line noise -- moves variable scoping out of the realm of heuristics you have to guess about because they depend highly on containing context. You can still make a mess of lexical scoping in Perl, but at least you have syntactic hints about what people expect to happen as well as a compiler which can tell you if you've gone wrong.
In a hundred years of Crusades, about a million people died on both sides. That's ten thousand per year. Diarrhea killed more people than that -- and it still does.
[If] Apple were to build a netbook, why would they eliminate Atom capability since that processor could serve as the basis for a ultra small, low-power mac?
I'm happy to second the praise for Lighting Source.
However, a publisher will help you with editing and marketing (although you pay dearly for both of those).
You can't overestimate the value of a good editor, though I've been dissatisfied for the cost-to-value ratio of editing and marketing on my last two books through a so-called traditional publisher. Editorial input was minimal, the production process was a mess, and I'm not sure any marketing ever happened. Believe that the publisher certainly didn't change the royalty rate to reflect how little value they added to the process, however.
With a POD publisher that does fulfillment and his standard 10% of wholesale price royalty rate, I can make more money on my own after selling 1500 copies -- and that's without selling electronic versions, where my margin is much, much better. I can break even after selling some 70 copies.
Tim's right that the costs of handling physical books yourself eats up a lot of net income, but you don't have to do that.
Slashdot Mirror
This is a minor nit in an otherwise accurate post. The Parrot Foundation governs Parrot.
Apply discipline and discretion appropriately, as you would if you worked on a project with HTML, CSS, SQL, JavaScript, a templating system, and some other server-side language.
You changed your argument (from "You haven't released any software!" to "I don't think I would use the software you released!".) Even so, the amount of confidence anyone has in any particular Rakudo release depends on who that anyone is, what that anyone uses Perl 5 to accomplish, and what a production environment means to that anyone.
Clearly, but that was the point of my post. I won't use PHP or C++ in production, despite the fact that many businesses do successfully.
If you try to cram all possible meanings of all possible uses into a single word, you overload it past the point of meaning. Patrick's goal with Rakudo Star is to release something that many people will find useful and usable. Whether you want to deploy it in a production setting is entirely up to you; we refuse to make that decision for you.
Why not?
Whether it's useful in production depends on who you are, what you do, and what production means to you.
If I had a couple of libraries ported from Perl 5 to Perl 6 (simplified greatly by new features of Perl 6, of course), I'd use Rakudo in the core of my business. I might do that as of the Rakudo Star release.
That was Guy Steele, talking about C++ programmers.
Fedora 12 includes Rakudo Perl 6.
For comparison, Fedora 13 will likely include Python 3.
We've released a new version of Rakudo Perl 6 every month since December 2007. That's 24 months in a row.
I'm going to release the 24th stable monthly version of Rakudo Perl 6 in a couple of weeks. How many more releases do we have to release to meet that mythical bar of "shipping"?
Do you mean tokenization in the parsing process? If that overwhelms the profile of the program, either the implementation has an awful, awful parser or the program executes so quickly that it's not worth optimizing.
Almost every sentence I've read which starts that way ends differently. This leads me to believe that customization is, in fact, important.
That includes loop iterators (yes, I know these are rare in Ruby with pervasive blocks) and block-local variables not declared as incoming parameters. I'm curious to see idiomatic Ruby code written using only instance variables where a more straightforward approach would use lexicals. (Don't forget that if you have a method_missing on the object, you have more work to do to catch variable typos.)
I remember multiple debates over scoping changes between Ruby 1.8 and Ruby 1.9. That debate wouldn't have happened if scoping were more explicit.
Sigils are a different story. In Perl, they exist for two reasons: to provide additional namespaces to disambiguate builtin and user-defined symbols and to provide compile-time context hints. The latter doesn't apply to Ruby.
The dominant meaning of "translate" used by native English speakers generally implies some non-zero amount of veracity.
Cardinal hasn't had much activity in the last couple of months because there have been only a couple of people working on it lately, and one of them started a new job at the end of September.
Even so, it exists, it passes tests, and it can interoperate in the same Parrot process with Perl 6 and Perl 5 code. (I suspect it can work with other Parrot-hosted languages as well, but I haven't tried.)
You gave a great example yourself:
That tiny syntactic change -- which you describe as line noise -- moves variable scoping out of the realm of heuristics you have to guess about because they depend highly on containing context. You can still make a mess of lexical scoping in Perl, but at least you have syntactic hints about what people expect to happen as well as a compiler which can tell you if you've gone wrong.
Cardinal still exists; it could use a couple of people concentrating on it.
In a hundred years of Crusades, about a million people died on both sides. That's ten thousand per year. Diarrhea killed more people than that -- and it still does.
Isn't a major contributing factor that Windows has a huge advantage in preinstallations?
ARM seems more likely, given the iPhone.
Which case is this? In which jurisdiction was this case?
When did that become a right? In one fell swoop, you render libraries, lending, and leisurely browsing in stores unethical.
Clearly; a lot of the practice of certain kinds of law is problem solving.
I'm happy to second the praise for Lighting Source.
You can't overestimate the value of a good editor, though I've been dissatisfied for the cost-to-value ratio of editing and marketing on my last two books through a so-called traditional publisher. Editorial input was minimal, the production process was a mess, and I'm not sure any marketing ever happened. Believe that the publisher certainly didn't change the royalty rate to reflect how little value they added to the process, however.
With a POD publisher that does fulfillment and his standard 10% of wholesale price royalty rate, I can make more money on my own after selling 1500 copies -- and that's without selling electronic versions, where my margin is much, much better. I can break even after selling some 70 copies.
Tim's right that the costs of handling physical books yourself eats up a lot of net income, but you don't have to do that.
Not true: Tim's numbers are wrong, especially if you use a POD supplier.
Why would you still buy Macs, if you feel that strongly about Apple?