I hate to repeat a comment of mine, but for the sake of emphasizing just how different Perl 6 is, here's a version of Fibonacci in Perl 6:
subset NonNegativeInt of Int where * >= 0;
proto fib (|) is cached returns NonNegativeInt {*}
multi fib (0) { 0 }
multi fib (1) { 1 }
multi fib (NonNegativeInt $n) { fib($n - 1) + fib($n - 2) }
say fib(100)
I expect most would either use plain 'ol imperative code if that's what they're used to (from Perl 5), or do it with the sequence construction operator (triple dot):
my @fib := 0, 1, *+* ... *;
From what I've seen so far, Perl 6 code is still similar to Perl code. Presentation snippets tend to focus on specific new features and should not be taken as representative samples of real-life code.
My intention wasn't to make people say "wow, I know Perl 5 but now I'll never figure out Perl 6," but rather to illustrate some new features in the context of a familiar example. :) In fact, the above-mentioned presentation introduces P6 features by gradually expanding upon P5 code, showing that you can gradually grow into the language.
Another one of Johnathon's excellent presentations goes into depth about the kinds of optimizations being made in MoarVM: http://jnthn.net/papers/2014-yapceu-performance.pdf
If you're familiar with another OO dynamic language like Perl 5, Python, or Ruby, you can probably get up to speed more quickly in P6 than Haskell, and you can gradually introduce more advanced P6 ideas as your ability grows.
But yeah, I'd still recommend you learn Haskell... and Erlang, and Lisp... and...
You wouldn't.
That is to say: You might learn Haskell if you want do write 100% functional code, and Perl 6 if you want to write imperative/procedural/OO code with functional idioms mixed in here and there (in places where that facilitates a more elegant approach).
I.e. the two languages are not really competing in the same category.
Even though Perl 6 has first-class code objects, closure semantics, basic pattern-matching, lazy lists, immutable data types, and so on, a lot of the syntax and default behaviors are geared towards stateful programming styles, which - combined with the lack of static typing - means that strictly sticking to functional programming in Perl 6 will be awkward and you'd be better off using a dedicated functional language if that's what you want.
If you think that you need a revolution to get to a desirable state, Haskell is for you. If you prefer not to have to re-wire your brain, give Perl 6 a shot.
Or, of course, do both :-)
http://use.perl.org/use.perl.org/articled5d3.html?sid=00/07/...
Just for reference my company's software is all built with Perl 5 and runs great. Most of the execution time is within the database calls so there is no impact from using Perl over a marginally faster runtime like Python or Java.
I think there's a good chance that Perl6 will not only become 'relevant in the large', once again, but also, once again, be a driving force in the overall improvement of our industry.
It never made any sense to me that some people would rather see Perl stagnate and die and complain from the peanut gallery than they would help it move forward.
That's not entirely fair. Some of us doubters spent a lot of time, energy, and resources trying to help it move forward before deciding it wasn't worth it.
The problem I described is when people actually prefer to kill a project through stagnation than to help it move forward - often by active resistance to any real change. Living projects periodically change. Even goals like improving speed often require redesigns and replacements of old components. When the process of change and renewal is shut down or nobody contributes to it, everyone starts wandering off and the project dies.
I'm not a developer of Perl. I'm sure all your input was appreciated by someone. It's a personal decision whether you want to keep putting in that effort, or switch to other tools. I just don't see any sense in attacking Perl 6 any more.
Meanwhile, Perl 5 will have its 22.0 release this May.
We are upvoting non-news? It'll be a great announcement if they ship it, but it's just hype now. Also, consider all they are announcing is a version for developers.
"Larry has announced that the Perl 6 Developers will attempt to make a development release of Version 1.0 of Perl 6.0 in time for his 61st Birthday this year and a Version 1.0 release by Christmas 2015."
Do people no longer write code? Because if they do, some of them might might choose to use Perl 6 for that, and that's all the success a programming language can hope for.
I see no reason why Perl 6 can't find its niche among people who prefer the Perlish over the Pythonic way to approach problems, but want a modern, consistent, cruft-free language (which Perl 5 is not).
I'm not against Perl or its evolution, but I don't see the point to learn this today when you have so many better scripting language alternatives with established community and rich libraries available.
I've been a professional Perl developer for a long time, and I've followed Perl 6 since the first announcements. There is some impressive and really interesting work going on there, but from my perspective it seems to be a new language rather than a new version of Perl. I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl.
It seems like the usage of the name "Perl" has actually done a fair amount of damage to the Perl 5 language, and the Perl community. Non-Perl programmers don't understand what is happening. To them, Perl 6 is just the next version of Perl, and the long wait for Perl 6 is a sign of problems within the Perl community. To many of them when Perl 6 comes out it will be the obvious choice to use for new projects, since the name implies it is the new version, even though the reality is that Perl 5 will likely be the correct choice for a large number of new projects for many years to come.
Perl has become a punching bag by the uninformed who speak about it as a dying, irrelevant, read-only language. Perl 6 carrying the Perl name has helped reinforce those views, allowing them to incorrectly speak of the lack of new versions, the future versions breaking backwards compatibility, and many of the changes being a strong admission that something was very wrong with Perl 5. When Perl 6 is released there will be a lot of confusion and the common belief will become that Perl 5 is even more irrelevant.
So, why not stop using the name "Perl" and call it something different? Wouldn't it be better for everyone if Perl 6 was regarded as a new and separate language?
It's both, really. If you use it (and after a while of getting used it), it just feels like perl.
> I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl.
Well, in retrospect, it might have been a good idea to name it something else entirely. But that's too late now, and nobody has been able to come up with a good new name anyway. And the "Perl" brand is still very strong, so we are loath to give it up.
Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades. Once Perl 6 has become as fast and mature as Perl 5 is now, we want to provide the future that's closed to Perl 5.
The weakness of Parrot VM was it's ambition - to be an efficient VM for all dynamic languages. This may have seemed possible in the past but recent work (i.e. v8, luajit2, etc) has invalidated that; it's much better (and much easier) to build a VM for a specific target than for all possible targets, as there are simply fewer points where you need abstraction. (For instance, NaN is false in javascript boolean context, but not in Perl6). More importantly, MoarVM has been designed and developed by a small set of developers applying all the lessons learned from parrot, while parrot was in many ways an experiment by committee.
Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. That means cleaner design, less memory footprint, faster execution.
> and why were we stuck at Parrot for so long before giving it up?
Rakudo works on Parrot. Why drop support for it?
Once you frame the question that way, the answer becomes obvious: because there hasn't been big changes to the code generation yet that would make continued parrot support painful. Once we reach that point, the situation will be reconsidered.
Getting the right trade-offs there was no easy task.
Another challenge was how to make the type system and built-in types so that stuff works intuitively for a Perl programmer, and still has sane rules in the type system.
Finally a thing that's surprisingly tricky is precompilation. You need to serialize types and objects, and then another compilation unit comes, and needs to modify something, so it claims ownership over a piece of serialized data or code. There are way too many nasty corner cases in that area.
Or in other words what is still left to do that is not just routine work, but actually might not be possible (or not possible in the timeframe)?
Or in even more informal language, what's the holdup? :)
In general, I think there's huge latent demand for a relatively fast, "next-gen" scripting language, as even Python is showing its age in terms of the programming styles it doesn't support, and has no plans to.
Will it really be released by the end of this year? Obviously the history of this project induces a healthy bit of skepticism. My two cents would be that the dev team should just release it next week and fix the inevitable warts gradually.
On a related note, should I, as someone who does not know Perl, bother learning Perl 6 yet? Or is it likely to change a lot before release?
Barring that, there are three major technical things we want to tackle before the release: native, shaped arrays (compact storage of arrays/matrices of machine-sized types), the Great List Refactoring (GLR; mostly about speeding up list iteration and making things more consistent), and some Unicode-related tasks.
Any of those might prove more difficult than expected. I personally see the biggest risk in the list refactoring, because lists are rather central to the language as a whole.
I think that the initial port of Rakudo to JVM was done by jnthn single-handedly. I don't know how PyPy compares with JVM though.
At any rate I think that an implementation of 6model (the basis for Perl6 objects) on PyPy would likely be too slow to really make it worth the effort. ( If you really want to try I'm sure there are People who would help you )
There are currently 3 backends for the Rakudo implementation of Perl6: Parrot, JVM, and Moar.
The fastest one currently is the one designed to meet the needs of Rakudo: MoarVM. (in many benchmarks) It of course makes sense that a VM designed for Perl6 would work better for Perl6.
Some of things it does:
* type specialization. It looks at repeated executions of a piece of code, and if the type of a variable or parameter is stable, it assumes it'll be always that way, and specializes the code for that (for example, always picks a method from the same class). And of course it inserts a guard clause to ensure that if the type should change, it takes the slow (but correct) path
* inlining
* container removal. In Perl 6, things generally become mutable by being inside a container (think pointer), and if the specializer finds cases where that's not needed, it generates better code for them
* reachability analysis and elimination of allocations are being worked on, iirc.
http://design.perl6.org/S12.html#Multiple_constraints
It concludes with:
> As a first approximation for 6.0.0, subsets of enums are static, and other subsets are dynamic. We may refine this in subsequent versions of Perl.
I'm not trying to be argumentative, but the last realistic comparisons I did had Perl running quite a bit faster. For example comparing ack to grin, which are very similar projects in Perl and Python respectively...at the time, admittedly several years ago, ack was an order of magnitude faster than grin. I also wrote a few log parsers in both Perl and Python (at a time when I was working in a Python shop, so they preferred everything be done in Python). The Perl parsers were much faster than the Python variant, for exactly the same work (again, an order of magnitude difference). Perhaps this is just an example of Perl's domain of expertise...processing text is a big part of its origin story, and has always been a big part of what people use it for. Or, perhaps Python has made remarkable performance improvements in those intervening years. I haven't worked with Python in that time, so haven't followed development. Perl 5 has gotten faster in that time, too, though, so I'd be surprised if Python is dramatically faster for the same real world tasks.
What is fast is string handling and log mangling. Perl was created for that; everything else is bolted on.
perl6 has much more features than perl5, it's a completely different world. I wouldn't call that bloat.
No. I have my doubts about yet another announcement and nothing I've seen since I stopped contributing suggests that the project will provide anything I need that I can't get better elsewhere.
And, you speak of numerics, which is a good example of Python's wheel house. When I worked in Python it was at Enthought (the company run by the folks who created Numeric, SciPy, and who sponsors a lot of scientific computing Python projects). Perl definitely doesn't have the numbers performance of a hybrid Python+Fortran or Python+C++ system, like you can build with Python, Numeric, SciPy, etc.
So, even back then, Python was (probably) faster than Perl in that category (Perl has science and bioinformatics libraries, which may have been comparable back then, but certainly aren't now), and I guess it's unfair to compare Perl's strength to Python's weakness, and vice versa.
Nonetheless, I suspect Perl is not slower than Python in the general case. One would probably have to talk about specific tasks and implementations to figure it out.
I don't think so. Everything I've read in recent years has indicated that the grammar is stable, which implies that the operators and planned feature set are also stable.
If you want to melt your brain, you can take a look at STD.pm6, the official grammar for Perl 6, which is also written in Perl 6:
https://github.com/perl6/std/blob/master/STD.pm6
Recent changes seem to be very minor.
[edit] - there is also some progress in speeding up list operations, because as it turns out making all lists lazy is not a really good way to do fast list computations. This is known as the 'Great List Refactor' (GLR) in perl6 circles, and spoken of with awe :-)
Here is the current feature test statuses of the Perl 6 compilers/runtimes: http://perl6.org/compilers/features
Note that the Rakudo-MoarVM runtime is the closest to feature complete, with Rakudo-JVM close behind.
In short, you can expect you'll get whichever runtime you install, and if that runtime is ready for production you can expect that Perl 6 will work on that runtime. MoarVM will likely be the first to be ready for production.
You may have other reasons for choosing a runtime; if you have a Java/Clojure/Scala shop and wanted a powerful scripting language to integrate into your systems, the JVM runtime might be just the thing. If you wanted the fastest Perl 6 for standalone Perl 6 applications, MoarVM will likely be it (I think, I haven't looked at benchmarks, just guessing). The FFI may be easier to work with in MoarVM, if you need C or other compiled external libraries...but maybe not. I'm not at all familiar with how that works in JVM runtimes, but it seems like it would be more convoluted.
0: MSI installers for MoarVM and Parrot, I assume JVM bytecode it includes is in there as it stated it ships with "experimental JVM support."
1: http://rakudo.org/downloads/star/
A key feature of Perl 6 is optional static nominal typing:
my Int $age = 40;
$age = "old";
Do you have any tips for me on how to make it clearer on the page I linked that this is compile-time checking? Or, more simply, did you just not believe the "compile-time" comment on the page I linked or did you just miss it, perhaps because it's "commented out"? Would it make sense for me to incorporate some of what I write below?
----
Perl 6 supports more than just static nominal typing. You can add arbitrary constraints:
my Int $school-age where 5..18 = 40;
Most folk will just like the convenience of this construct and won't care whether it results in a check at compile-time or run-time.
But some will care.
So, while nominal typing is a compile-time checking affair, what about these arbitrary constraints? Do these result in checks at compile-time or run-time? Well, it depends.
Key quotes from the relevant language design doc[1] are:
> A where clause is considered static if it can be applied to the types to the left of it at compile time to produce a known finite set of values.
The line of code we're looking at:
my Int $school-age where 5..18 = 40;
However, for 6.0.0 (by which I mean the suite of 35K+ tests that are supposedly going to reach beta status by September and the Rakudo compiler that is supposedly going to reach gold status by the end of the year) there's this:
> for 6.0.0 any structure type information inferable from the where clause will be ignored
In other words, the line we've been looking at with the `where` clause will result in a run-time check for 6.0.0.
----
1: http://niner.name/talks/Leapfrogging%20the%20bootstrap/Leapf...
You say "It's better to build a specialized VM", I say "Emscripten, Clojure, Niecza, Truffle, and Jakudo."
And as a counter-example, luajit2 was built by one man (mostly) over the course of a few years, and runs very efficiently indeed, in no small part due to the lua-specific choices that have been made.
So what I'm trying to say is that there is a second tradeoff, somewhere between programmer efficiency, runtime efficiency, and running time, and that MoarVM is making a better tradeoff for perl6 than parrot is.
I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago, but wanted to couch their "Let's burn it all down and start over" in much more careful terms which allowed them to take advantage of Parrot's stability when marketing P6 to the outside world while using Parrot's concomitant lack of development to prove that they'd made the right choice.
I think you are being uncharitable. It's clear now as it has always been to me that the Rakudo developers wanted a working, fast VM that provides the needed features. Since Parrot couldn't deliver this, it was just naturally to look for alternatives.
Also, it makes me sad that you argue a lot about Rakudo's and Parrot's past, but seem to neglect their current state or the future. Could it be that you care more about how Parrot will be remembered, then about how it does today?
I'm really not sure what you're trying to say here. How is a later project being able to look at what came before and try to determine what decisions were good and bad of the prior project and trying to avoid them being uncharitable, and what does that have to do with whether some people wanted something different long ago?
I've documented this at length elsewhere.
Those specific features we were told explicitly not to work on were on the top of the list of "Reasons Rakudo Must Abandon Parrot". I find that disingenuous, as if Parrot had been set up for failure.
Perhaps I should apply Hanlon's Razor here, but that feels even less charitable.
I have strong opinions that people in situations similar to mine had no intent of contributing to "stagnation" or "death". Quite the opposite.
When the process of change and renewal is shut down or nobody contributes to it, everyone starts wandering off and the project dies.
Certainly. I also think that a project which actively chases away contributors ought to account for that eventually.
Chromatic may disagree more or less on some points above, but as someone who followed along from the outside, reading blog posts and IRC chats of both parties over years, that's how I interpreted it.
After almost 15 years in development, surely that lack should indicate something.
If it didn't it would probably be like all these other new languages which only attempt to improve upon the art of programming in one or two aspects.
Another good thing about it taking so long is that it took a few tries before anyone figured out a decent way to implement Perl6. If everybody had just settled for the first halfway decent implementation, we would have been bridled with a language that was half as good as it could be. And the worst thing about that is that there would be people relying on the features the way they were implemented then, making it far harder to break backwards compatibility and get here in as little time as it has so far taken. ( There is still at least one big breakage that will come before Perl6 is officially released )
That's ignoring a few stumbling blocks like illness and some mismatch between the goals of Parrot and Rakudo. Without which it could have been done possibly 5 years sooner.
Ha! My experience with Rakudo was "you go to the developer resources you have, tell them not to change anything, then tell them you're going to throw away their work in favor of something you haven't written yet" and then complain when they leave.
Yes, it will be very important to build up a Perl 6 community and an ecosystem of libraries. That being said, if you want to talk about modern scripting languages, Perl 6 seems like a good choice. Ok, to be fair to functional programmers a lot of these things are old features. But for the mainstream scripting languages, these are really new and powerful tools -- tools worth learning.
Not everyone thinks that ticking off a list of feature checkboxes satisfies the most important adoption criteria.
At least here on HN, rising languages such as Go, Scala, Elixir, and Clojure offer many of these features to help address developers' pain points. The authors of Go have themselves expressed surprise that their real audience ended up being disaffected Python programmers.
If we want to talk about modern languages we have to of course talk about their features. There's more to a language than features, but there was once a time when none of the above languages had much of an ecosystem or community. Rather, they all offer something compelling, such as type safety in Scala, concurrency in Elixir, etc. I just wanted to touch upon how Perl 6 offers many of these things.
Sure, but in the world where I write software, my teams need code with a working ecosystem of documentation, tooling, libraries, trained or trainable developers, deployment and monitoring, and stability. I can get that from Go, Scala, and Clojure (haven't looked at Elixir).
Looking at P6's laundry list of features may be interesting from a language geek perspective, but it doesn't help me solve real problems for the foreseeable future, and there are plenty of interesting languages further ahead in the queue of things to learn.
Having a regexp library is hardly "modeling a language on Perl".
"Most" of exactly WHICH languages are you claiming were modeled on Perl?
>Perl is a language that is still ahead of its time.
Perl's time was 15 years ago.
>"Also, Perl's library system, CPAN, is far more comprehensive than many languages."
A library and a language are apples and oranges. Python's library ecosystem is more comprehensive than Perl's language. Because most any language minus all of its libraries is less "comprehensive" than another language's libraries, simply because most mature library ecosystems are much more massive than the language itself.
Even if you compare apples and apples then oranges with oranges, Perl is a terrible language compared to most other languages, and most of CPAN is terrible outdated crap compared to other language's libraries. Python, Ruby, Java and JavaScript all have much richer and more up-to-date library ecosystems than CPAN.
>"By the way, Python is a great language, except for all the tabbing nonsense."
Is the worst thing you can say about Python that it forces you to indent your code? Then I'd hate to see the haphazardly indented code you write in Perl. Good programmers don't find that to be a problem, because they indent their code properly anyway, and Python simply lets you do that without inserting a lot of punctuation. But inserting lots of punctuation is what it's all about with Perl, isn't it?
That's an unduly simplistic argument. "Indentation that looks clean" and "Indentation that fulfils Python's specific needs" are not the same: one is a superset of the other. This means that enforcing the latter is in fact an extra burden and a loss flexibility. Whether the burden is less than having to write braces all the time comes down to personal taste, but to pretend that it does not exist is dishonest.
In any case I could get used to the significant indentation. What actually repels me the most from Python is the lack of non-broken lexical scoping, which - together with the "only one expression per lambda" limitation - makes closure based programming solutions awkward and hard to get right in Python. Which is unfortunate because I personally really like those kinds of solutions...
The ironic thing is, that this situation leads many Python programmers to believe that closures are inherently complicated/difficult/bug-prone, and sneer at languages which promote them heavily as "not newbie friendly".
To get back on the thread's topic, Perl 6 is one of those languages where function and variable handling is built on proper lexical scoping, and closures are everywhere. Even regexes are closures, in the sense that they are treated as first-class code objects (that just happen to be written in a different syntax), and if a regex uses variables from other Perl 6 scopes it closes over them.
Maybe I'm the only one who feels that way, but that kind of thing excites me in a way that Python never could.
But to each their own!
>Having a regexp library is hardly "modeling a language on Perl".
I don't know about most, but both PHP and Ruby were heavily influenced by Perl. If you've used both, this should be apparent, if not, you can easily find references on record to the effect. The original statement may have been a bit hyperbolic, but in context and with constraints something similar isn't unwarranted. E.g. "Perl was very influential to many of the most popular scripting languages today."
That doesn't even make sense.
I still don't see what place it has in this thread. It's irrelevant to the fact that a project could learn from all of it's predecessor's successes and mistakes, while not carrying any of the historical baggage. You have a point you want to make, I get that, but if you feel to need to inject it into something at best tangentially related, at least lay the foundation so it makes sense when people read it.
That is great for you as a Perl 6 developer that gets extra attention for the new language by leveraging the Perl brand, but it is absolutely awful for people in the Perl 5 community. Perl 6 gets free press, but Perl 5 gets mocked and public opinion turns even further against it.
> Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades. Once Perl 6 has become as fast and mature as Perl 5 is now, we want to provide the future that's closed to Perl 5.
I know Perl 5 isn't perfect, but no languages are. You refer to "unsolved problems" and while I'm sure there are from your perspective, from mine as someone who writes large Perl 5 applications, there are no great issues. I can do everything I need to already, and I can do it really well. I don't need Perl 6, and I won't even consider it until it has a proven track record.
For most people to make the switch, Perl 6 won't need to prove itself as being just better than Perl 5, but it will need to prove itself as the right choice in the full market of languages out there. For at least a few years, and likely many more, Perl 5 will still be the right choice for a lot of work, and Perl 6 will do nothing but confuse people and cause public opinion about Perl and with it Perl 5's market share to sink even further.
First of all, the press for Perl 6 isn't free at all. We get press because we do cool stuff with programming languages. So do the Rust and Nim communities, for example. Please don't downplay our effort. And the comments are full of prejudice against Perl 6 that is rooted in its Perl 5 legacy; so it's not "free" in a second dimension.
Second, in my experience, Perl 6 is only a small part of the ridicule. Mostly it's about Perl being aweful to read (for which Perl 6 bears no blame at all), lousy code quality, unfamiliar looks through sigils, and so on.
> You refer to "unsolved problems" and while I'm sure there are from your perspective, from mine as someone who writes large Perl 5 applications, there are no great issues
Have you ever asked yourself if this is actually true? Would your work be much easier if you had sane threading in some scenarios? Subroutine and method signatures? never had to deal with the bloat that comes from different libraries using different object systems?
I also happen to work on big Perl 5 code bases for money, and with the knowledge of what's possible in a perlish language, I regularly identify pain points that in the end are rooted in missing or deficient language features.
I am looking forward to the future of Perl 6. I really do like some of the things I've seen going on there, and it is fairly likely that in the future I will be happily writing Perl 6 code on some projects. With that said, I am very concerned about how Perl 6 carrying the Perl name will impact Perl 5, but that is separate from my excitement that a new more modern language will be carrying forward some of the Perl styles.
In short, I do appreciate Perl 6 and I don't mean to downplay anything going on there, but my concern is about what it all means for Perl 5.
Come now; that was the excuse given five and ten years ago.
the "Perl" brand is still very strong
Some would argue (including the post to which you're replying) that the brand is much less so, thanks to the very line of thinking you're defending.
Perl 6 did not "kill" the Perl brand, the state of Perl circa-2000 "killed" the Perl brand. All the issues @perlgeek just noted, those "killed" the Perl brand. The fact that Python was simply a better option for 99% of the projects that were started around that time (even if half or more went with PHP instead) "killed" the Perl brand.
If Perl 5 as a programming language is so susceptible to "oh but this new version makes it seem that there are deficiencies in the current version", could it be because there are deficiencies in Perl 5? If hiding that fact from others is so important to the "brand of Perl", what does that actually imply?
Please stop pretending that starting a project to build a better Perl somehow killed the camel. It's obvious that this is not true even from a Perl 5 usage standpoint, but it's even more absurd from the standpoint of next year, or the year after...
It's easy to look at the rate of change and the timeline of releases of Perl after 2000. It's easy for me to argue that the announcement of P6 (and the promise that 6.0 would be a successor to 5.10 or 5.12) took a lot of momentum from working on Perl.
I suspect, but can't prove without a time machine and a multiverse, that if the "they're sister languages" line of thinking had been in place from the start, Perl could have avoided its lost decade (5.6.0 to 5.10.1).
I'm wondering which unsolved problems you're referring to in particular. (Surely Perl 5 is not the only language which might happen on problems in upcoming decades, and just as surely Perl 6 isn't immune to them.)
* way too many globals in the language, making any sane threading support very hard
* OO (or lack thereof) in core. Yes, there are nice OO modules out there (Moose/Moo), but it's easy to land in a situation where you have several OO modules in the same project. Also, many built-ins still only deal in strings (example: error messages), not objects.
* lack of proper subroutine signatures. The ones in 5.20 are a step in the right direction, but still far away from anything that the competing languages offer
* high exposure of internals to the XS (C) API make it nearly impossible to do substantial rewrites of the internals
* The regex syntax has been extended way beyond its limits of sane extensibility. Yes, Perl 5 now has named captures, re-usable(ish) subrules and all that neat stuff, but the syntax is so arcane that I have to look it up every single time I use it.
* Poor type system. Perl 5's types (scalar, list, hash, code, type glob) simply aren't enough in world where you have to distinguish binary data and Unicode strings, for example. Or subroutines and methods.
... then don't write it in a language with negligible documentation, negligible tooling, barely-there library support, nearly zero users, and a roadmap based on the promise that, after almost fifteen years of working on the "It'll be ready when it's ready!" principle, sufficient volunteer mindset will change to "Let's ship a production-ready release to meet a hard deadline!"
What I object to are the terms "most" and "modeled on", each of which are hyperbolic, but taken together are "hyperbolic squared" (to stretch the mathematical metaphor).
And Perl 6 hasn't had much influence at all, since nobody's been able to use it for anything practical in the last 15 years.
At best, Perl 6 has influenced people to learn other languages than Perl, which is a good thing, I suppose.
Sorry, but your retcon fails. Even Scala admits it has Perl influences -- http://perl8.org.
I can agree that it had an influence, but I'm sick of the Perl 5 perspectives that a) the language is flawless and only an idiot would choose something else, b) Perl 6 pointed to flaws which don't exist because hand-waving, Rule A, etc.
Perl 5 has fundamental problems. At first Perl 6 was an attempt to solve those problems without a complete compatability break. That proved impossible, so the scope expanded to be a new Perl.
"But it's painting a bad picture of Perl 5!"
Perl 5 painted it's own picture, I'm sorry to say. The toxicity of p5p, the constant "this language is fine why are you making a new one", the over-confidence that Perl 5 is a pinnacle of how you can design a Perl language... these are Perl 5 things, and they belong to Perl 5. Yet I rarely see Perl 5 programmers owning to these facts.
It's just tired. You yourself did a great job in breathing new life into Perl 5, as part of the Modern Perl movement, which takes as its starting point that Perl 5 allows some seriously flawed programming. Techniques and ideas borrowing from Perl 6 are used to make life easier in Perl 5, developed during the "lost decade".
So, I'm sticking to my position that this whole line of thinking is just tired. For outsiders, Perl 5 was a non-starter because of all the flaws with the language, not because another version was in the pipeline that promised to fix those flaws.
FWIW, I program in Perl 5 every day, and I really enjoy the language.
http://www.modernperlbooks.com/mt/2013/02/goodnight-parrot.h...
I did not write but agree with this view of the Parrot Foundation:
http://whiteknight.github.io/2015/01/14/parrotfoundation.htm...
Similarly, this retrospective from another ex-Parrot developer has similar feelings about the P6 language:
http://whiteknight.github.io/2015/01/14/parrotfoundation.htm...
I personally wrote several parts of "Theme, Pragmatics, and Purpose in Programming Language Implementation":
http://outspeaking.com/words-of-technology/theme-pragmatics-...
... and I had several discussions which led to the writing of "Why Perl Didn't Win" and did some minor editing to it recently:
http://outspeaking.com/words-of-technology/why-perl-didnt-wi...
The P6 folks were developing their own bindings which used the (much nicer) 6model and the (much nicer) P6 native bindings instead. After a while I had to ask myself why I was fighting in the weeds so much, when the P6 people were rising above the problems of Parrot and doing things better? If my writing these things wasn’t helping anybody, why bother with it?
Notice that the P6 folks were having their biggest successes when they bypassed Parrot, which isn’t exactly a roadmap for synergy and mutual success.
He goes on to say he doesn't really like Perl 6, and doesn't believe in it's direction or that it can achieve it's goals. That's fine. Nobody has to like everything.
I have to say I agree with his assessment that Parrot's goals have largely been met by multiple other projects at this point. This post has convinced me even more that not relying on Parrot was the right choice, which is sad because I was a big fan for many years. Parrot was a train wreck. Some people think Perl 6 was or still is a train wreck. But that wreck has been making progress, and may actually arrive at the station. Can the same be said of Parrot? Can you really lay all that blame, or even a majority of it on Perl 6? If people wanted to work on Parrot, they would.
1: http://whiteknight.github.io/2015/01/15/parrottheend.html
What whiteknight didn't say was he'd spent over a year volunteering to port 6model to Parrot and had been repeatedly rebuffed. (He's a much nicer person than I am.) You can find that in the weekly parrotsketch logs too.
Look at the Ohloh logs of contributor activity. You can see them drop right after Rakudo said they were going to abandon the NQP Parrot was using. That's what finally drove people away.
Any post-hoc justification you hear about Rakudo dropping support for Parrot because almost everyone left is silliness. Why work on something when you've been all but told is going to be unused, no matter what you do? Especially when you've been told not to fix the things you wanted to fix.
Looking back on it, it seems obvious they were both doomed, as long as they were locked in that spiral of needing the other to advance to be able to move forward, and not being able to really drive the other project themselves. Think the only way out was to either come together again, not in tighter integration, but as a single project, or to split apart and fulfill their own needs. I think joining was actually the riskier option, there were many people in Parrot with no interest in Perl 6 beyond it's ability to drive Parrot. whitenight is frank and unapologetic in this, as he well should be.
So what if Perl 6 people stalled on giving the okay for Parrot to migrate some implementation details to Parrot? They were both immature projects, feeling their way through how to proceed. There are countless possible reasons for that, but a big one might be that they were unsure of the continued viability of that implementation, and didn't want to waste weeks of some Parrot dev's time to turn around a week after they finished and say "sorry 'bout that, but 6model really isn't going to work and we're going to scrap it for something else."
Then Perl 6 decides to hedge it's bets on Parrot. Sooner than later, because it was always the idea Perl 6 would run on multiple back-ends. Parrot as it existed could have survived that, if it hadn't already been floundering for a long time. They had recently decided to refocus on Perl 6, after realizing that the whole "VM for everything dynamic" thing wasn't really working, at least not as a main dev goal, and they were desperate for a fix. So what would that have done? Make a situation whose viability could best be described as "ridiculously horrible" all better? The best that could be hoped for there was "still pretty fucking bad."
Whiteknight lays out a pretty compelling case that Parrot was slowly imploding for a very long time. I trust his assessment, as he's one of the few people I recall landing major branches in Parrot, and fairly consistently. I understand that you put a lot of time into Parrot, and also Perl 6. Years. But that doesn't change the fact that many of Parrot's devs decided it wasn't worth continuing. Again, I think whiteknight gives a good explanation; the goals of the project had be mainly met already by outside sources.
Was the situation bad? Undoubtedly, or we wouldn't be having this exchange, but I like to think if you asked people involved from both sides candidly whether or not they thought some blame lied with themselves, they would own up to that.
> Any post-hoc justification you hear about Rakudo dropping support for Parrot because almost everyone left is silliness.
Rakudo hasn't dropped support for Parrot. Nobody has said that it will. Parrot isn't deal
> Why work on something when you've been all but told is going to be unused, no matter what you do? Especially when you've been told not to fix the things you wanted to fix.
Because, as should be obvious to anyone following along, Parrot usually did what it wanted anyway, as evidenced by the planned major shift towards treating Perl 6 as a first class citizen again. You can't shift back to Perl 6 without having shifted away. The stories don't line up. You can't be a controlling prima donna and be sidelined, because being sidelined means a lack of control.
You want to know what this looked like from the outside? Parrot was going downhill for a long time, and when they tried to re-hitch their horse the Perl 6, it was too little too late.
You can reply if you like, and I'll be happy to discuss this with you more here, in this thread, but I think I'm done engaging you on this issue here in the future or elsewhere for the foreseeable future (I imagine you're fine with that). I've spent a lot of time over the years here on this issue with you because you've garnered quite a bit of respect from me due to your prior works, but the way in which you see the people involved in this situation and how you assess their motivations is fundamentally foreign to me. I'm not sure anything I've ever said has actually ever made you think about a single point the issue in a different way than you had before, and if I'm not even having that effect, then I'm not really doing anything worthwhile in these conversations.
My problem is that this gets argued both ways. This thread is far too nested anyhow, but here's my complaint.
Yes, Parrot and Rakudo drifted apart. There were poor decisions all around. Patrick and Allison and I in particular talked extensively about how to improve things.
We decided this: I personally volunteered to fix any bug, patch any memory leak, add any feature that Rakudo wanted. I spent a lot of time doing that. Several other people also volunteered to add any feature Rakudo wanted.
Time and time again, we went to the Rakudo developers with proposals and they said "No" or "Not yet". Thus my work was mostly fixing bugs and making minor performance improvements. (The major improvements were in that list. So were major revisions of most parts of Parrot to make it smaller, simpler, and faster.)
Then the NQP rewrite came. Parrot faced using a deprecated NQP for its compiler tools, adopting a deprecated NQP so it would keep working, or rewriting all of its compiler tools.
At that point, I decided that there was no point in working on Parrot and left.
I'll take responsibility for everything I did wrong (or for not doing things I should have done). I don't accept the current party line from Rakudo, however. To wit, "Parrot of course had to be abandoned, because it wasn't meeting Rakudo's needs."
Parrot may or may never have succeeded. Rakudo may or may not have succeeded on Parrot. We'll never know. Yet the claim that Parrot developers weren't interested in making it work with Rakudo is nonsense. In my experience, it was the other way around.