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.
If I'm writing a code base that will likely have a >5 year life
... 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!"
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."
It's true that most popular scripting languages today were influenced by the same scripting (and other types of) languages that Perl was influenced by. Namely shell scripting and Lisp.
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.
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.
What he said, "Also, Perl's library system, CPAN, is far more comprehensive than many languages", doesn't make sense, because he's comparing a "library" to "languages": apples and oranges.
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
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).