he specifically asked what features Perl5 has that Perl6 doesn't yet.
he didn't ask for the cause it doesn't have them. many contributors with small time-slices are probably not going to make a lot of progress IMHO
Re^3: The current state of Perl6
Replies are listed 'Best First'.
Questions about the current percentage of spec coverage can be answered only by the developers who are working on it. Or probably testers.
But why was the pugs project abandoned? Why did Rakudo developers start from the scratch when something like pugs was already available to build upon?
Because it wasn't working out as a project: it wasn't maintainable and it went unmaintained. Other projects were easier/simpler/faster/more rewarding to work on.
Why did Rakudo developers start from the scratch when something like pugs was already available to build upon?
Pugs wasn't the first Perl 6 implementation by any stretch of the imagination either. There had already been two implementations on Parrot at that point. Ultimately they proved to take the wrong approach as well.
The tricky thing about implementing Perl 6 that no one predicted (and I suspect that no one could have predicted) in advance is that you have to get the grammar engine correct to have any hope of implementing it well. How you do that is an interesting question. The Rakudo approach is to write just enough of a self-hosting grammar engine to bootstrap everything else. To make that work, you need enough underneath the bootstrapping level to provide sufficient bootstrapping power. Another approach is to build a simple, self-hosting metaobject system (like Cola or Squeak) and describe the grammar engine in terms of itself from there.
Parrot's biggest failing in its first five years was that it provided almost no facility to get a bare-bones Perl 6 running. Pugs succeeded in that Audrey et al built enough of a Perl 6 implementation that people could run specification tests. If that had been possible with Parrot in 2002 or 2003, things would have turned out differently.
Pugs failed as a project on its own because it required heroics from Audrey to evolve and change. If it had been more approachable, or (towards the end of its useful life) faster, or more maintainable, or (as has been the big catalyst in Rakudo in the past several months) mostly bootstrappable in Perl 6 itself, things would have turned out differently.
No one has ever written a compiler for Perl 6 before, and if you look at the specification changes especially over the past two years, you'll see that most of the changes reflect questions and requests from implementors about the specification. Look at how long it's taken projects like IronPython and IronRuby and JRuby to implement languages already implemented elsewhere (and with actual funding and full-time developers). Implementing a language is not an easy or a fast process. Python 3000 took eight and a half years from conception to its 3.0 release, and its changes were relatively minor. (Microsoft still hasn't implemented C99 in Visual Studio, though I suspect that's not a question of resources at this point.)
Sometimes it takes a few false starts to find the right design. Certainly Parrot has iterated through a few designs on the way to find better and better approaches. Some of the ideas I had several years ago turned out to be big mistakes. Some of the ideas I had several years ago worked pretty well, but then we all learned something that countered our basic assumptions. If we had known then what we know now... well, you don't often get the luxury of being able to be right about everything or even most things up front.
Fortunately, we do have the ability to make changes. It's software, after all. It's malleable. It's flexible. You can let your users use last month's release for a month or two until you make some big changes to the internals and get next month's release to the point where it does what they need it to do and you can improve it further. You work in that cycle, where you don't have to make dramatic progress every day. Sometimes you do get a thousand tests passing or you fix a very satisfying bug or you delete a hundred lines of code that's suddenly unnecessary or you find a quick fix and get a 5% performance improvement. Usually you don't have those dramatic experiences, but as long as you make progress month after month toward a very real, very achievable goal, you're doing okay.
Meanwhile, along the way, some people get sick. Some people lose their jobs. Some people have families. Some people lose families. Volunteers do what volunteers do, and the best you can do is help them be most effective when they're available and try to keep the work fun or rewarding or at least manageable. Some of them want to work on Pugs. Some don't. Some of them want to work on Rakudo. Some don't. Some of them report a bug and that's all you ever hear from them and that's fine too, because sometimes you find someone brilliant with some spare time who can take on a larger task and it's very, very satisfying to help someone else realize that you don't have to be a genius or a famous programmer or tall or handsome or male or female to contribute to a project bigger than you could do by yourself. You just need to be a little bit patient, a little bit stubborn, a lot interested, and humble enough to be willing to learn and to experiment.
If the price for all of this is that a couple of million people think you're incompetent or diabolical or arrogant or foolish for working so hard on a project that's taken so long, well, I suppose you focus on the other six and a half billion people in the world that won't care that the project took longer than you ever thought if it makes their lives a little bit easier somehow. That, and you realize that a significant portion of the handful of people who think you're the worst person in the world still benefit from things you helped invent and achieve in Perl 5.
In addition to the language changes, a better theoretical
understanding of GADTs (which was deep black magic when Pugs.hs 6.2.x
first used them), of OO+Functional type inference (Martin Odersky et
al), of sound STM semantics and gradual typing (Jeremy Siek et al), was
also essential in coding the type system of Perl 6 as originally
Also notable was basic groundworks for 6.28.x such as Parsec
Transformers, Dynamic-linkable binaries and Data Parallelism (to name a
few) has gradually materialized as of early 2010, so folks who'd like to
tackle type systems now have a significantly easier
compilation-environment support than even a year before.
However, speaking for myself, though Haskell became sufficiently
attractive to implement compile-time type analysis for Perl 6, the
success of Moose and Pluggable Keywords in Perl 5.12.0 has convinced me
that we can also fruitfully implement such analysis directly in Perl 6,
or in Perl6-flavoured CPAN modules, which is a much more straightforward
way to amass a developer ecosystem than coding it in Haskell.
As lambdamoose demonstrated, real programmers can write Perl 6 and/or
Haskell in any language, particularly if that language is as
polymorphically existentially recursive as Perl 5. :-)
Nice summary. I'm constantly amazed at how much is routinely accomplished in the Parrot and Perl 6 world by a handful of volunteers. I think many of the folks who dismiss Perl 6 don't realize how many moving parts are involved: Parrot, NQP, Rakudo, and so on. Each of those is a significant project on its own, and each has made amazing progress during its lifetime. Perl 6 is more alive than they realize.
You just wrote your heart out!!! And it was convincing enough for us to know that some false starts took this project the way its going. As it turns out after years of learning I hope you are now going the right way today. And lets hope some years from now(1 or 2) we all will all live to see the day when Perl 6 crosses the finishing mark.
Python 3000 took eight and a half years from conception to its 3.0 release, and its changes were relatively minor
In a google tech talk, Guido specifically mentions that he doesn't want Python 3000 to go the Perl 6 way and the Perl 5 people just don't give a damn about it anymore!! Well thats the reputation Perl 6 has in the Open source community, It has just become an example of what not to do!!
you have to get the grammar engine correct to have any hope of implementing it well. How you do that is an interesting question
Oh I'll tell you how you do that. It's very simple. You get people skilled for this exact task ! Those skills are acquired in universities(preferably good ones) where professors teach courses like "Formal Languages and Automata" or "Compiler theory". If you have a bunch of people who are open-source contributors but don't have the knowledge or haven't studied the right things, they cannot contribute properly or can do so, but inefficiently because they don't know what they're supposed to know in theory and they're already trying to put it in practice. Let's go over this again, They don't know it in theory and they're trying to put it in practice!
How does that sound to you ?
Most likely the people Perl6 needs as contributors are already hired on paid jobs by companies which develop compilers and related software.
If Perl6 attracts web developers instead of compiler people how is the compiler going to evolve ? It's probably going to evolve into a hack because most web developers out there don't even have a formal education much less knowledge about the courses mentioned.
If you can't get real compiler people to use Perl6 and help with it, the average open-source rookie won't be able to deal with this. He needs to know what he's doing. But instead you have a big dream(that Perl6 is) and people that are not necessarily skilled to make that dream reality.