If you want to have an idea of what makes Perl 6 compelling, check these slides that were submitted a few days ago, "Perl 6 for Mere Mortals" (which is also another talk at FOSDEM): https://news.ycombinator.com/item?id=8953368
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)
The author of that snippet was probably just trying to demonstrate multi-method dispatch using a familiar example; I don't think that's how people would actually calculate Fibonacci numbers in Perl 6.
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, *+* ... *;
...which looks funky on first sight, but is really just another operator.
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.
I wrote the above snippet, but it was basically just one step beyond what Curtis Ovid Poe shows in his "Perl 6 For Mere Mortals" presentation.
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.
I'm not sure about any current Perl6 vs other language benchmarks; older benchmarks aren't terribly useful because within the past year MoarVM both became the dominant P6 VM and also received substantial performance optimizations. My understanding is that this is one of the big goals of this year.
We try to :-). Specifically, there are designs underway to implement e.g. hyper operators - those things that apply an operator to an array of values, irrespective of order - by SIMD instructions on the hardware level. If you're interested you're very welcome to come and check it out.
[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 :-)
In his talk, Larry specifically said something like "Please understand that we may or may not be comparable to Perl5 in some benchmarks, and that speed is something we're working on. We'll get there, and it's good enough already for many tasks."
Oh, I'm a big fan of Haskell! It's definitely a language worth learning. However, if you want a pretty nice but still "dynamic feeling" (as opposed to Java-ish) object system, Perl 6 has you covered there. I'd look at P6 as similar to Scala in that it mixes both OO and FP ideas, but with P6 leaning more towards the OO side than the FP side, with not as much type safety as Haskell/Scala/OCaml but with more type safety than, say, Clojure.
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...
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.
That will generate a compile-time error. (Because the "old" bit is a string literal which is interpreted in this case as being of nominal type Str which isn't compatible with the nominal type Int).
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;
The code that comes after the 'where' (the '5..18' bit) can be arbitrary code. It is tested against any value that would be assigned to the $school-age variable.
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;
can clearly be reduced to the set of integers from 5 to 18. And the compiler code to successfully make that analysis is fairly straight-forward, so it could fairly easily be implemented in Rakudo today.
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.
Coming from other dynamic and mostly OO/imperative languages, Perl 6 is evolution, and Haskell is revolution.
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.
Forgive me for this, but why is it still called Perl 6?
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?
> 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.
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.
> And the "Perl" brand is still very strong, so we are loath to give it up.
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.
> 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.
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.
Sorry if anything has come off as being too argumentative. I just feel like you are downplaying the large impact that Perl 6 has had on Perl 5 and the public perception of Perl, and the impact that will come when a 1.0 version is officially released. With the new release coming up this may be the last opportunity to avoid the future damage, and that is what my question revolves around. As for everything else, we are really on the same side and I agree with you on the notable points, so I will leave out further discussion.
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.
Yeah, something like Perl++, Perl 10/Perl X, or something that indicted the scope of the difference in the rewrite would have been nice, though I think it's too late at this point. Ten years ago it would have helped, now 'Perl 6' has been floating around for fifteen years.
I've been in and around Perl for a long time, and this line of argument feels very tired to me.
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...
Please stop pretending that starting a project to build a better Perl somehow killed the camel.
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).
> Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades.
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.
IIRC the new VM (MoarVM) is around for quite a short time and it replaced Parrot in a dramatically short time. What are the advantages of MoarVM over Parrot and why were we stuck at Parrot for so long before giving it up?
I'm the developer of the MoarVM JIT (but not the developer of the MoarVM bytecode specialisation framework, which is typically seen as part of the JIT).
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.
Well, that's a good point, really. The JVM and the CLR do run many (dynamic) languages quite efficiently. On the other hand, that is in no small part due to the man-centuries spent trying to optimise both the JVM JIT and the language-to-JVM compiler.
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.
Thanks, I think this basic "you go to code with the developer resources you have, not the developer resources you might want or wish to have at a later time" is desperately under-appreciated in software architecture
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.
Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage.
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're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago
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?
That's... an odd way to start a response in which you are very obviously being uncharitable yourself in assessing the motivations and actions of real people. What's more, you are doing it as a non sequitur.
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?
After the first Rakudo Star release, I personally volunteered to spend my Parrot time fixing bugs which affected Rakudo, improving the performance of Rakudo, and adding features for Rakudo, in that order. I offered several suggestions (including native registers, better profiling, object system improvements) and was repeatedly told not to work on them. I will say this, though: there was no friction to working on the profiling system (though it went unused). This happened to other people as well.
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.
Looking at the release as a whole, I'd be fascinated to hear what features have taken the most time and effort? What turned out to be much harder than expected?
One big challenge is the sweet spot between flexibility and optimizability. Perl 6 is designed for extensibility, and yet we know at compile time where a given subroutine will dispatch to.
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.
I'm also interested in an answer to this question. Perl 6, as a feature set, looks awesome and I'd really consider replacing my use of Python with it, espcially because of the gradual typing and fast startup time (assuming Perl 6 follows Perl 5 in this regard; my initial experiments haven't been encouraging though).
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?
> 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?
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:
Just to clarify, as you responded "I don't think so" to two questions, the language is not going to change too significantly prior to release, so yes you should bother learning Perl 6. No one I've met who has actually bother to use the language has had anything but excitement about it.
As always in open source projects, there's the risk that a major contributor might drop out.
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.
Something I've wondered for a while: why was the decision made to write yet another dynamic language VM+JIT (MoarVM) instead of taking advantage of all the work the PyPy folks have done and using PyPy for Perl 6? Was PyPy even evaluated as a possible target?
Why would we want to write Python code to get a new Perl6 backend which doesn't have quite the same object system that Perl6 needs?
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 the presentations I've seen make it look like MoarVM does some kind of AST specialisation before it gets to the JIT. Is there any documentation of how that works?
* 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.
Do you know who it might be best to talk to about the AST/bytecode specialisation? I work on a compiler with AST specialisations and I'm interested in their approach.
Perl 6 is a spec, and different implementations are possible and encouraged. Rakudo is an implementation, and targets a few different VMs, including Parrot, MoarVM and the JVM. A lot of effort is being put into making MoarVM a good VM for the intermediate language that Rakudo uses to implement Perl 6, but AFAIK the JVM is kept up to date as well, and Parrot is also where time and expertise exist.
Thanks, my intention in asking the question was to see if there is any willingness to speak about what will ship. I don't need a pedantic explanation of the runtimes, I want to know if a decision has been made to get behind one of them. I've been waiting 15 years to hear some actual details about what I can expect when I install this thing.
MoarVM is the closest to "ready", and seems to be what most of the developers actually using Perl 6 today are using. But, as the prior post mentioned, Rakudo-JVM and Rakuda-Parrot are also getting closer to ready. All of them will likely "ship", as long as the developers keep working on them, and Perl 6 code will likely run correctly on any of them.
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.
Why wait? I assume it will be similar to Rakudo Star, which packages[0] Perl 6 for regular consumption on a semi-monthly (quarterly now?) basis, which you can download windows installers for here[1]. If you aren't on windows, compile, it's not that hard, directions are included in the github repo for Rakudo[2] under INSTALL.txt. You can see more info on that at the Rakudo website[3].
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."
Most everybody on the #perl6 IRC channel, the central part of the Perl 6 community, is preferring the MoarVM backend. It's only a matter of time and policy until it becomes more "official" in one way or another than the other backends.
It allows arbitrary code to define the subset. So it's very flexible, but it also means that compiler usually can't be clever about subsets. We can't solve the Halting problem for you.
The first line of code I ever wrote was in Basic. It was copying something in a book. Then I wrote routines on a Ti calculator for school. Then I found Perl. I felt all grown up! Maybe, just maybe I could be a "real" programmer. Thank you Perl.
I can't find it right now, but I like how this harks back to the original announcement that Perl 6 would be ready in time for Christmas—just with no commitment to which Christmas.
And at that point they found out that Perl 6 will be a complete rewrite and not just a cleaned up Perl 5. I also guess that the Second System feeling already arrived in some minds, the problem IMO is more that the 'by Christmas' joke has been kept alive for so many years, without specifying a year.
I hope Perl 6 has better runtime speed and memory efficiency because those are the only downsides of Perl 5. However I seriously doubt that will be the case. Perl 6 will most likely be more bloated and slow, but I very much hope that I'm wrong.
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'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.
Perl5 has a lot of historical baggage that makes certain things difficult to do efficiently. For example, how objects work. There is an insane amount of indirection involved for a simple method call, and this indirection can't generally be removed if we want Perl5 to stay highly backwards-compatible. Numerics aren't particularly efficient either. Perl5's opcodes are very high-level. That makes each individual opcode pretty fast, but makes it difficult to inline stuff. Variables can have “magic” attached that can change their semantics substantially. While this is very flexible and allows to do some amazing things, this also requires this magic to be checked on each access. So Perl5 has a lot of features that rank high on “clever”, but low on “can be optimized”. Perl5 never got JIT support, and only has a couple of very experimental Perl-to-C transpilers.
What is fast is string handling and log mangling. Perl was created for that; everything else is bolted on.
I understand all that (though it's useful to cover it for folks who might not know). But, is Python faster? It carries some baggage of its own. I guess PyPy may be able to make some sorts of problems faster, and it was still nascent at the tail end of when I was using Python; I think it existed, but was nothing more than a proof of concept. Even now, I think it's a pretty limited subset of Python deployments that use PyPy.
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.
With perl5 + Moose, perl6 beats perl5. In startup time and run time.
With simple small scripts the small startup footprint of perl5 still elevates it over perl6.
perl6 has much more features than perl5, it's a completely different world. I wouldn't call that bloat.
As I said over on perl.org:
From the bottom of my heart, thank you. I have been keenly looking forward to this for a long, long time.
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.
I agree: Perl could lead the industry by example to slow down and take 15 years to ship everything. Then everybody wouldn't have to work overtime so hard and so often, toil late into the night burning the midnight oil, and ignore their families, pets and social life.
Wow, pre-congratulations! Let's hope this inspires some renewal in the Perl community.
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.
some people would rather ... 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.
Have you been checking it out at all again, or are you considering it? It's been my secret hope for a long time that you would get involved again, if not at the compiler level then at the community and ecosystem level. Your blog[1] was always insightful and a good read, and I think the community is worse without it being active. I'm talking about Perl 6 here, but I could say the same for Perl 5 and it would be at least as true.
Have you been checking it out at all again, or are you considering it?
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.
I'm interested in why you removed "stagnate and die" from that quote.
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.
Chromatic was very big with both Perl 6 and Parrot development a long time ago. My understanding of it, having followed both projects for close to a decade, is that it came down to what was the "right" choice for one project was not the "right" choice for the other, and the schism this caused as it happened a few times left some people soured. I think both sides had cause for their actions and have cause for their feelings, but I don't really think either party did anything wrong. Such is life, shit happens, it's not fair.
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.
People can say that as much as they like, calling the thing that comes after Perl 5 "Perl 6" certainly SOUNDS like a version number, and the reason it sounds like it's supposed to be a new version of Perl is because once upon a time it was going to be.
Maybe at the point of the 1.0 release, a naming change could take place. I think any time before then would be a mistake though, as it would maximize the baggage and minimize the usefulness of the new name. I'm torn on whether a new name, if it happened, would be better off explicitly referencing Perl (e.g. NG Perl), or leave it out entirely for something new.
Well, with Inline::Perl5 and "use p5", that may not be entirely unfeasible. You can read more about Inline::Perl5 here[1], but the TL;DR is that it uses a Perl 5 interpreter along with Perl 6 to pass code back and forth, allowing pure perl modules and modules that interface with libraries to run fairly smoothly in Perl 6. There's also an Inline::Python that works the same way...
Why is this insulting to you? Things happen at their natural pace :-). I got my first job knowing a bit of PHP. It's still not a pretty language, but I don't find that insulting.
"Perl 6 Developers will attempt to make a development release of Version 1.0"
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."
I have a fondness for Perl 5, as it was the first general-use programming language in which I became proficient. But let's not kid ourselves: Perl 6 is the Half Life 3 of programming languages.
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).
If they wanted a modern, consistent and cruft-free language then those people most likely already moved to something better.
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.
Modern scripting languages with... parametric polymorphism, built-in parallelism/concurrency, grammars, constraint-based multiple dispatch, etc.?
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.
True, but at the same time If I'm writing a code base that will likely have a >5 year life. I'd rather write it in a feature rich backwards compatible language. Else you are left with a Python 3 like scenario where you will have to undergo a decade plus migration path just to get a few improvements over a for loop and a print statement.
I can't seem to reply to chromatic, but my point here was to address one of the parent post's specific criticisms, that of being "modern".
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.
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.
Better in this case is purely a value judgement... The Perl language is very elegant and powerful, that's why most of the other languages were modeled on it. Perl is a language that is still ahead of its time. Also, Perl's library system, CPAN, is far more comprehensive than many languages. By the way, Python is a great language, except for all the tabbing nonsense.
>"most of the other languages were modeled on it."
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?
> Is the worst thing you can say about Python that it forces you to indent your code?
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.
>>"most of the other languages were modeled on it."
>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."
There could be a misunderstanding. The editor indents the code and keeps it indented properly whatever it happens, not the programmer. I don't have to worry about which indentation level is the right one for the code I'm writing and the bugs I'll create if I get it wrong. I press tab and emacs places it where it must go, if it's not already there, which is the case unless I'm doing copy and paste. At least this is my experience with languages that have block delimiters.
> 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.
Late to having a large, committed community and momentum. 15 years ago, Perl was Real Big (although I think even then PHP was starting to eat its lunch). If you launched Perl 6 then, you had a lot of active Perl projects you could talk into switching. Now, Perl 6 is Just Another Language, and it faces most of the struggles any new language/runtime would face, plus the added burden of carrying everyone's preconceptions about what Perl is along with it.
This is not Perl 5. They are not the same language. Any whatever language you currently favor is Just Another Language that will be (or has been) displaced by [Current Fad Language]. Perl 6 hasn't even had its "Show HN: flappy bird/blog platform/etc" flavor-of-the-month phase yet, and you still claim its too late for the language? You come off as someone who does not want to expand their developer tools, because there is no reason to make the vague "claims" you have.
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.
After 15 years you're like sed || awk.
Something you know is there, and you can use.
Not something to start a new project with.
PS. 15 year ago a Pentium 3(750Mhz) was a top class CPU
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:
Edit: Another good recent talk is "Adventures in Perl 6 Asynchrony," which shows off promise combinators, channels, and supplies: http://jnthn.net/papers/2014-yapceu-async.pdf