|
Re^3: A wholly inadequate reply to an Anonymous Monk
by chromatic (Archbishop) on Apr 23, 2010 at 07:27 UTC
|
In short, Perl 6 might have been basically a re-iteration of Perl 5 in the same way that Perl 5 was for Perl 4. Only this time we could break backwards compatibility to fix some of the hairier bits.
The problem is that--with that process--it still takes eight years to build Python 3, and then you don't get an object system like Moose, you probably don't get pervasive laziness, you don't get pervasive closures, you might get hypotheticals, you don't get grammars, you might get continuations, you probably don't get custom operators, you might get multi dispatch, and you probably don't get a rethinking of context and the type system.
You might get multiple implementations cooperating around a canonical specification. You almost definitely don't get a self-hosted grammar as part of that specification.
You don't get roles.
You get Perl 5 with some of the worst bits of Perl 1 - 4 removed. Yippee.
Also you're very, very wrong about the JVM. Invokedynamic is only the start, unless you want to throw away partial binding, multiple dispatch, continuations, coroutines, lightweight concurrency... or spend the rest of your life writing trampolines.
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
We have an object system like Moose on Perl 5 now with Roles and all; So I don't see why we couldn't have one on a cleaned up Perl 5 (the hypothetical Perl 6). Same goes for grammars, they're halfway there in Perl 5.10. Custom operators are there in 5.12 with ugly parser hooks, etc.
We've had 10 years of very productive Perl 5 development. It would have been very interesting to see what those 10 years would have been like had some of the uglier parts of the core been deprecated in favor of some of the features in Perl 6.
As for the JVM I don't think I'm that wrong. I'll give you continuations and coroutines but lightweight concurrency? Have you looked at Clojure? Its hello world demo is a ~100 thread application and it's been known to run up to a thousand threads or so pushing a few gigabytes of data per second around on a few hundred cores. It also does multimethods (Lisp-style). And in any case the JVM seems to be able to emulate these things just fine even if you don't use its native calling conventions.
Anyway discussing VMs for some of the more fancy Perl 6 features is getting a bit sidetracked (although I'd still be interested in why some of the Lisp VMs weren't adapted).
I just wanted to reply to the OP (without any hostilities) who was curious as to what the "hysteria" might be about. My posting sought to aggregate some of the most common concerns that I've heard. That's all.
For a lot of people (including me) Perl 5 is what pays the bills. There isn't a single company (correct me if I'm wrong) that's doing Perl 6 development (despite claims that "you can use it today!").
I think it's understandable given all that that 10 years later we only have a pre-alpha implementation and little uptake, and bad some bad PR for Perl externally.
| [reply] |
|
|
Marketing
Q: How can you market Perl 6?
A: You cannot. It's not ready for the market. I'd argue it's
not
pre-alpha. You can run it and write useful things with it
today. But it's not stable enough or close enough to feature complete
to be something that any sane tech managers would be bundling up as
the engine for a vendible product.
The question this leads to is "What will happen if you try to
market
Perl 6 now, aka, too early?" The same thing that would have happened
to Apple if they'd tried to market the iPod early. Ridicule,
skepticism at best. Loss of attention. High resistance to adoption on
launch.
PR
Q: How can you do public relations for Perl 6?
A: Like Perl 5 has begun to do. Iron Man Perl, EPO, Summer
of Code,
etc. Should you? No, not yet! The only thing it can serve to do is
fuel skepticism and ridicule again. How many years did it take for
Perl to get out from under the "it's too slow" meme? Ten? It only
finally has because Java was, and Ruby is, slower still so most of the
rats finally shut up about it. Imagine another ten years of that shite
because the world at large experiences early, unoptimized Perl 6 which
makes Ruby look like Erlang.
External PR for Perl 6 cannot help anyone. It just serves to cause
sideshows like the last couple threads and reinforce the idea that
there is confusion simply because there are some who are confused. I'm
not a Perl 6 dev or even a user, I've written fewer than 10 toy
scripts in it so far, but I knew the answers to most of the concerns
because I pay attention to the community.
Perl 6 smells wonderful to me but it is half-baked. Only a
desperate, addled chef rings the dinner bell now.
Now, this–
We've had 10 years of very productive Perl 5
development. It would have been very interesting to see what those 10
years would have been like had some of the uglier parts of the core
been deprecated in favor of some of the features in Perl 6.
–has been refuted in this thread already as both impossible
and actively detrimental to the goal it sets out. If you haven't
worked on the implementation of those parts of the core, this feels
mildly insulting and just disconnected from reality. It's the "Why
can't I have a pony?" again. Because ponies are really actually not as
easy as they look to a little kid.
If you're not going to get personally involved in developing and
writing code for Perl 6, just pretend it doesn't exist or frankly it
seems to me you're actively hurting its progress. These
discussions—which are outside of the regular lists, meetings,
and decision making process—don't clarify or improve the
prognosis and they are, obviously from the OP, actively
irritating and potentially detrimental to the only persons trying to
deliver the thing. I've nearly quit projects before from getting
critiques, even ones I may have deserved, which were delivered out of
turn or without etiquette. I can't imagine what it would be like to deal with it on a continuous basis. I wouldn't blame anyone who wouldn't put up with it.
Q: Do you want Perl 6?
A: Backseat driving can only serve to slow the trip down and
make the drivers start to hate their task. No one does, or can be
expected to do, a good job when it stops being fun. Help keep it
fun. If you're still impatient, go evangelize for Perl 5; it's better
all the time and its critics are easier to counter.
(update: speling.)
| [reply] |
|
|
|
|
|
|
|
Eight years for Python 3 is a selective example. Much of that time was spent dragging their feet because they were in no hurry.
A much better example is PHP 4 to PHP 5. Now, we can all agree that PHP is a pile of dung but PHP 5 is much *much* better than version 5. And it took just 4 years (first 4 release: 2000, first 5 release: 2004).
The Perl core was already good in 2000. I'd like to have seen what a similar effort without the constrains of backwards compatibility would have been like *without going too wild*.
| [reply] |
|
|
Well, there is (was) Topaz and then there's Kurila (or maybe a better link to it?).
Perl 5 has one aborted attempt to further it, one terribly out of the mainstream fork, and then there's all the progress that has been made between official Perl 5.6.0 and the recently released 5.12.0 as well. Then there's all the platform work that has come into play, with ActiveState Perl and Vanilla/Strawberry, gtk, Qt, and wx.
What are some changes to Perl 5 in the last decade? The threading model is different, signals have been cleaned up, the regex engine has been largely converted from recursive to iterative code, and lexical pragmas that were once compilation switches have improved things immensely. There are also new language features and new core modules. The quality of major CPAN modules has gone way up, too. That's just a start.
You can talk about similar effort and selective examples, but PHP is a selective example, too. Besides, it's easier to improve something when there's that much room for improvement. How much has C improved in the meantime? How about Ada, Pascal, or Smalltalk? Sure, arc and NewLisp are out. How much have individual other implementations of any language advanced? It seems a new dialect is how many make major changes in a short time. Otherwise, your implementation can be too much of a moving target. JavaScript, Lua, and C++ come to mind as improving drastically over the last ten years. Yes, I said C++; at least the drafts for the new standard appear much better than C++ 98. I admit I've never done much with Lua or C++.
Then, besides Perl5, there's also Perl6. It hasn't held Perl5 as we've known it back at all. Larry was ready to break backwards compatibility. Be careful what you ask for. Breaking compatibility with deprecated parts of Perl5 is already being done by Perl5, and Kurila breaks even more. If you really want a nice language with all the perks of Perl that's more advanced than Perl5, Perl6 will provide that if you're willing to wait.
If you want a stopgap, try Kurila or try actually using Perl5 with Moose and the other widely considered best-of-breed modules to program in what proponents call Enlightened Perl. If you really think it's like programming in 5.004_05 or even 5.6.0 (the major version that came out in 2000) and the CPAN modules that existed in 2000, then you're seeing a similarity most don't.
| [reply] |
|
|
You get Perl 5 with some of the worst bits of Perl 1 - 4 removed. Yippee.
At least we would have got that. That is still better than getting nothing at all.
| [reply] |
|
|
Maybe I really am less than competent, but as I see it, the Perl 5 core really had stagnated, development-wise, until it started borrowing features from Perl 6 -- features which wouldn't have existed if Perl 6 had pulled a Python 3000 and tried to make a few cosmetic changes and burn off a few warts here and there. (Proposing a patch to remove the Perl 1 style do subname notation starts vehement arguments on p5p, even though you can remove three percent of the entire Perl 5 parser by getting rid of a feature made obsolete at least sixteen years ago.)
Consider, as one example, the Perl testing revolution. Remember Test::Simple? Ever use Test::More? Like what Test::Builder has done for the Perl core, and CPAN, and CPANTS, and the quality of billions of lines of code written in the past eight years? Thank Perl 6 for that, because the Perl 6 QA working group decided that improving the test coverage and test tools and testing culture of Perl 5 was vital to the interest of making sure that Perl 5 and Perl 6 could interoperate.
Sure, you could claim that someone else would eventually have done something else, and that in that imaginary world things would be better, or more the sameish, or somewhat different, or everyone would wear a jaunty hat now, but facts are facts and history is history and anyone who was there will tell you that this is how it happened.
(Disclaimer: I know Moose has a lot of influences besides Perl 6, but so does the Perl 6 object system.)
(Second disclaimer: Perl 5 has grown immensely healthier in the past eight months, thanks in part to adopting yet another feature that Perl 6 and Parrot have demonstrated as useful -- the monthly release cycle. This is neither accident nor coincidence.)
| [reply]
[d/l] |
|
|
|
|
PerlMonks keeps hanging forever when I try to submit a reply, but here it is: http://pastebin.com/MchyhtVg
| [reply] |
|
|
For a lot of people (including me) Perl 5 is what pays the bills. There isn't a single company (correct me if I'm wrong) that's doing Perl 6 development (despite claims that "you can use it today!").
I think it's understandable given all that that 10 years later we only have a pre-alpha implementation and little uptake, and bad some bad PR for Perl externally.
I agree.
People laugh at me at an interview when I tell them I know Perl. They tell me So I heard Perl is very good at code obfuscation and it wins every OBFU contest, that's the kind of response I get in an interview. This is not a joke, this really happened.
| [reply] |
|
|
Re^3: A wholly inadequate reply to an Anonymous Monk
by pmichaud (Scribe) on Apr 23, 2010 at 16:54 UTC
|
Here we go again, a post that is almost entirely filled with
speculation divorced from reality...
(see how many "might haves" and "maybes" there are in the post).
If you read some of [Perl 6 RFCs] you'll see that
people mostly didn't want to turn Perl 6 into the total rewrite
it has become. Most of the suggestions were along the lines of
fixing the return value of chomp, giving us a better object
system, or fixing path handling.
First, I claim that "giving us a better object system" (i.e.,
Moose) would not have happened without having first having
had the opportunity to see what would be done by a total
rewrite. (In particular: multimethod dispatch, function
signatures, strong typing, invariant sigils on variables,
and twigils.)
Second, I think that what Larry and the cabal eventually
discovered (I wasn't there at the time) was that you couldn't incorporate
most of the new suggestions into Perl without first going through
a total rewrite. Yes, some of the ideas from Perl 6 are
now making it into Perl 5, but I claim that this is possible
only because the ideas were discoverable as part of the
exercise of creating a total rewrite. Even if you claim
the new concepts would've been achieved via a simple
re-iteration, I'll still contend that the evidence shows
that the timeframe wouldn't have been significantly shorter
than what we have now (see below).
In short, Perl 6 might have been basically a
re-iteration of Perl 5 in the same way that Perl 5 was for Perl 4.
Only this time we could break backwards compatibility to fix
some of the hairier bits.
I wasn't involved at the time of the RFCs, but my understanding
is that the issues involved in bringing these new features to Perl
were (and still are) far greater than simply dealing with
backward compatibility. A number of Perl 5 experts have told me
that the other reason for "total rewrite" with Perl 5 is that
fixing Perl 5's core codebase would also take a huge amount of
work and have uncertain chances of success. And guess what,
those experts were correct -- it took 7.5 years to
get from Perl 5.6 to Perl 5.10. Thanks to the heroic efforts of a number of pumpkings and core hackers, the Perl 5 codebase of today is orders of magnitude improved over what existed in 2000. But I also believe (from what others have told me) that many of the fundamental problems are also still present.
(Anticipating those who will say "Perl 5.10 would've arrived
much quicker if we hadn't gotten distracted by Perl 6", please
(1) cite your evidence for such a claim, and (2) note that many
well-known Perl 5 experts and insiders, including pumpkings,
strongly disagree with the notion that work on Perl 6 has
impeded Perl 5 development in any significant way.)
Had this been done we might have gotten something in 2-4 years that was production ready (ran all of CPAN) and cleaned up the worst warts. Had we cleaned up the worst parser edge cases you might be running jPerl on your JVM now instead of jRuby.
I think this is even more speculation contradicted by
available evidence. I don't know of any Perl 5 core hacker
who seriously contemplates making significant changes to
the Perl 5 parser, or that such changes could reasonably happen in just a
few years. And I certainly have plenty of evidence available
to indicate that even minor changes to the Perl 5 parser have taken years for evaluation, testing, and being incorporated into an actual release.
Several Perl 5 experts (again, including former and current pumpkings)
have told me that Rakudo and Perl 6 remain Perl's best
(and some say only) chance for Perl (both 5 and 6)
ever making it to the JVM or .Net virtual machines.
And anyone who wants to port Perl 5 to other virtual machines
would certainly want a better parsing engine than what is
currently available, which brings us back to needing a new
grammar engine, which brings us back to needing Perl 6.
It was claimed that there was no existing VM that could run a lot of dynamic languages, now it turns out that the JVM/.Net can do that just fine...
Okay, you're essentially accusing the Perl leaders of 2000
of having imperfect foresight. And you're omitting the fact
that JVM and .Net weren't at all "open platforms" then (and
in many ways they still aren't), so if "the new Perl" needed
something not available through those VMs at the time, there
was little chance of having that something added in a timely
manner.
Regardless, the debate about whether Perl should have pursued
a new VM is ultimately a red herring in my book. My other points
still stand-- even using Perl 5 as the underlying VM
it has taken Larry a couple of years to write up a parser for
our new language. And from an early date that parser has required
Perl 5.10 and Moose, neither of which were available in any sort
of usable form until 2007 at the earliest.
(I grant that it's entirely plausible that Larry could've
created his standard grammar implementation using 5.8 and
without Moose. But my speculation is that Larry would've
instead taken the time to design something like Moose and
the additional features he would need in 5.8 to support
the grammar. Which, if you think about it, is in fact
exactly what has happened. :-)
10 years later we still don't have our apple pie.
Answer 1: I have an apple pie, and a
new and better tasting apple pie shows up at my doorstep
each month.
Perhaps the apple pies I'm receiving aren't sufficiently
cooked to your culinary standards (yet), or aren't the
type of pie you're looking for, but it's wrong to claim
there aren't any apple pies being produced.
Answer 2: Maybe you don't have your apple pie yet,
but I guarantee that your Perl 5 pie is now much tastier
and better for you because of the work that has gone
into making the Perl 6 apple pie.
But it's interesting to speculate on what could
have happened differently. Maybe we'd have a Perl 6 for 6 years
already by now...
No, you'd likely have a Perl 5.10 that would be called "Perl 6".
And you would have only had it for two years (Perl 5.10.0 was
released in December 2007). It would probably be seen as
having the same level of "incremental improvements" over
Perl 5.6 that Python 3 does over Python 2, and with a similar
(slow) adoption rate.
It probably wouldn't have had the ~~ smart match operator, cited as
"the
most exciting change" in Perl 5.10 over Perl 5.8.
It would still be considered ugly (many people find Perl 6 much
less ugly by comparison). And Ruby and Python would still be
where they are today.
If the speculations being offered were being used to improve
on what is happening today, then I might agree that it's
"interesting to speculate". But much of what I see is
speculation used to justify FUD like "10 years later we
still don't have our apple pie" and "We'd have Perl running on the JVM by now", i.e., statements that I find to be totally unsupported or contradicted by the available evidence.
Pm
| [reply] |
|
|
Second, I think that what Larry and the cabal eventually discovered (I wasn't there at the time) was that you couldn't incorporate most of the new suggestions into Perl without first going through a total rewrite.
This was exactly the conclusion of the RFC process. Larry et al decided that there were enough contradictory proposals to patch problems on the surface that any real redesign of the language required deeper thinking to achieve cohesive consistency.
Any alternative history which glosses over the Perl 6 RFC period (or, as is the case in this thread, ignores it outright) has divorced itself from reality and entered instead the weird realm of Perl 6 Fanfic. I half expect to see a hard requirement for a race of militant space pandas enslave Europe in some of these alternate proposed project plans.
| [reply] |
|
|
I half expect to see a hard requirement for a race of militant space pandas enslave Europe in some of these alternate proposed project plans.
That's not sufficiently farfetched. Could I instead interest you in a volcanic eruption that causes a bunch of displaced, disaffected European hackers to descend upon PerlMonks like a plague of locusts? :-)
| [reply] |
|
|
Re^3: A wholly inadequate reply to an Anonymous Monk (Perl++)
by LanX (Saint) on Apr 23, 2010 at 09:42 UTC
|
Thank you this was the best anonymous post in a while expressing much of my thoughts much better than I could.
I wholeheartedly support the "Rakudo/Parrot/Pugs/Ponie/whatever..." team but IMHO most of the problems and tensions are the result of a communication tragedy.
Honestly, Perl6 should be renamed into something like Perl++.
It's much more than the next evolutionary step of Perl5, it's incorporating revolutionary concepts which can't be achieved in normal release steps..
But at the same time we are living in a marketing world, where the crowd measures the quality of a product at the release numbers.
Releasing a Perl5 compatible successor, maybe just bundling Moose for OOP and Coro for multithreading and maybe some syntax cosmetics and restriction³ to contradict the "write only language" complaint would easily cannibalize the Ruby spectra like they are actually cannibalizing the Python spectra.¹
But sadly such a successor can't be named Perl6, because this name slot is already taken.
And at the same time the "Perl++ team" has to cope with the burden and pressure of the whole community impatiently waiting for a answer to the contemporary needs.
They are constantly forced to justify why they are making gold, where the market just needs iron to be turned into steel. ²
Thats a marketing desaster!
Perl5 is somehow in the situation of Neanderthals who are told by the gods that further evolution is useless because Sapiens Sapiens will arrive in Europe and wipe them out.
Actually it took thousands of years to replace them ...
UPDATE: added links and to title and improved language
Footnotes:
¹) It's so paradox to see how a beautified syntax on Perl semantics plus Smalltalk object model named Ruby easily takes steadily growing market shares ....
²) and let me be clear Perl++ IS gold, but meanwhile our customers live in the stone age and are going to other jewelers to buy gems made of iron...
³) perl critic but anal! | [reply] |
|
|
The only restriction that could stop any language from being considered write only, is the restriction of the people that use it. With enough idiots, you get enough horrible code. And the number of hoops they have to jump through to shoot themselves into their feet doesn't matter.
Besides quite a few people would consider anything that contains regular expressions write-only. And I ain't gonna loose regexps due to some clueless script kiddies.
Jenda
Enoch was right!
Enjoy the last years of Rome.
| [reply] |
|
|
In general it's surely right that no restriction can avoid people writing horrible code...
But I was talking about marketing!
With a pragma called "superstrict" ( or "anal"¹ or "antigolf" ) which combines the better parts of perl critic one could enforce a coding style which looks orderly and nice at first glance!
(E.g requiring (more or less) one statement per line or avoiding the usual context traps with reasonable defaults)
And thats how many representatives judge languages, at one glance!
I mean bosses, school teachers or ignorant beginners.
Just the illusion that a good coding style can be enforced is enough to improve the sells!
"Oh you mean python looks less messy? So why don't you simply try "use anal" if you need punishment?" =)
¹) NSFW?
| [reply] |
|
|
|
|
It's so paradox to see how a beautified syntax on Perl semantics plus Smalltalk object model named Ruby easily takes steadily growing market shares ....
That wouldn't have been the case if a better alternative was available.
| [reply] |
Re^3: A wholly inadequate reply to an Anonymous Monk
by moritz (Cardinal) on Apr 23, 2010 at 08:49 UTC
|
Only this time we could break backwards compatibility to fix some of the hairier bits.
(...)
Had this been done we might have gotten something in 2-4 years that was production ready (ran all of CPAN)
Who else spots the logic error in here?
Perl 6 - links to (nearly) everything that is Perl 6.
| [reply] |
|
|
Who else spots the logic error in here?
With an approach like use 5.10.0; and use feature, there's no logic error. You can both have Perl 5 compatibility and cleaner behaviour for new scripts.
| [reply]
[d/l]
[select] |
|
|
Yes, and you don't break backwards compatiblity. Which is what AnonMonk was talking about.
If you use a menchanism like use $version or use feature there's no need to call it a major new version of perl. We already have these incremental language modifications in perl 5, which AnonMonk wished that Perl 6 would bring them.
That said, perl 5.10 still breaks backwards compatibility in several ways (introducing new operators, changed scoping of regex modifiers), even though it was "only" a bump in the minor version number. Even if it were possible in theory to avoid that, it would be a huge maintenance burden to ship two regex engines with different scoping rules, which are then swapped depending on the presence of a pragma.
| [reply]
[d/l]
[select] |
|
|
Will Perl 6 be compatible with existing CPAN modules, I mean CPAN modules for Perl 5?
| [reply] |
|
|
I think Worthington++ started some strangely named project this autumn to link Perl 5 into Parrot, as an "equal" language. So evals and function/method calls should be doable, then. (Failed to google it right now.)
Edit: Thx, Audrey++
| [reply] |
|
|
|
|
| [reply] |
|
|
|
|
|
|