So, why isn't it the poster child of the scripting languages yet?
"Please note: This announcement is not for the Rakudo Star distribution[^2] --- it’s announcing a new release of the compiler only. For the latest Rakudo Star release, see <http://rakudo.org/downloads/star/>."
Perl 5 is much more straightforward. Their download link sends me to a page where I click my platform and then there's a link to "download latest stable version." Why can't I just download the latest stable version of perl6?
I know I can spend a couple of hours learning more about it but perl 5 more than meets my needs and I'm comfortable with it.
As an outsider, my 2c is "abandon 'perl 6', too much baggage for reuptake, and go with Rakudo, which is a more modern name". People smarter than me decided on this rakudo/perl 6 nomenclature split, but it just feels like an own-goal to me.
Languages are a specification and implementation. Perl's been implemented in Rakudo, which runs on MoarVM and the JVM. It's handy being able to run on multiple VMs so that you can take advantage of their strengths, and in particular, places that deploy the JVM for Java will be simpler to integrate with, and apparently you can do stuff across with Java libraries even, though I haven't played with that at all myself.
http://rakudo.org/how-to-get-rakudo/#Installing-Rakudo-Star-... that's how I get it. Rakudo::Star is just a bundle of Rakudo with a bunch of commonly used modules which can be handy to have already installed.
Right now you get your choice of MoarVM or JVM to use as the tie into your OS, and MoarVM gets selected by default. It's started showing up in Linux distributions now too.
But yeah, I'm still a lot more comfortable in Perl 5 too.
The popularity of Perl coincides with the golden age of personal computing (and hackers culture). PCs got powerful enough that individuals could do the same things that were only available to big corporations and sometimes universities. Perl helped to harness this power, becoming the proverbial "Internet duct tape" to connect things (in the world of UNIX with emphasis on text protocols, the most powerful language for text processing won).
When lone hackers were no longer enough to satisfy the demand, the world had moved on to create _software industry_, and Perl's advantages (all power to the individual) started to be harmful. Different individuals have different preferences, and when you have to work in the team, reconciling your differences with your colleagues creates way too much friction. To facilitate teamwork, more uniform languages were deemed necessary, where understanding other people's code became a priority. Even open source software moves faster when anybody can read and participate in your code without fighting over style. This attitude was firstly exemplified with Java; now, we have Golang, which is a king of all languages optimized for team development. To facilitate this, the expression power available for individual developers had to be cut short.
As a consultant supporting my own code, I still use Perl, and if you are working alone, it's your fine bet. But as 99.9% of people work in teams, Perl6 is not the best choice for them.
Both are just an eyesore for everybody but the person who wrote it.
Heck, even the very experienced JS/Node developer who works at my place says that they sucks in teams, and I totally agree.
PHP...well, that was designed as a hack job to get a Personal Home Page to work dynamically by a lone dev kid...
That number is far too high, given the rate at which I run into single points of failure aka individuals working alone. They might be on a product team or whatever-team but they're the only software dev on the project or only dev who understands the problem space, the one and only dev who can fix that bug.
Its not entirely wrong in that 99.9% of software experiences more than one author over its useful lifetime and idioms and peculiarities of individual developers will make transition between single maintainers more exciting.
It is instructive that in general business communication if that theory were correct then English would have long been replaced by Lojban, but there hasn't been much success. Perhaps its a non-tech startup business model to increase effectiveness of a business by conducting all internal communication and documentation in Lojban. Maybe there's some kind of tech startup business model in somehow technologically encouraging support of Lojban. It could just be wrong in most scenarios.
There are however code linters, formatters, etc. You use those you can do the same in Perl (6).
You need style guides, yes even in Python. In Python there is a bit more community wide agreement though.
And even in other languages you need style guides, but often they are already enforced or strongly encouraged by the IDE you use.
Anyway, when comparing with JavaScript the problem seems to be the same. Lone scripter code is barely readable by others, while in teams style guides are often created and enforced. The same appears to be true for Perl.
I am not using Perl (anymore), but I think the main reason for this argument being mostly used in the context is that Perl has been around for longer, which means you have more code written detached from the community. Also Perl has been used a lot more by people that refer to themselves primarily as sysadmins, rather than programmers.
When comparing programmer code with system administrators code JavaScript, Perl, Ruby and Python are all harder to read and more different from commonly agreed style.
So I agree that your argument is true for why Go or Javan are used and maybe to a small degree to Python, because that seems to be the strictest language, but if you compare it with JavaScript, I think they pretty much even out on weird things they allow and that is frequently done.
I think there are some other reasons for JavaScript being used more. It's not Async IO[1]. One of the reasons is web development. There is just many people who start out their career as what we nowadays consider frontend people and the step simply is smaller, even if they eventually become systems programmers, write drivers and OSs the introduction frequently was through browsers.
Another reason is performance. V8 and Spidermonkey are probably some of the most advanced interpreters out there when it comes to code optimization (other than what Facebook did to PHP). That's if you include the complexity of the language. Of course there are highly optimizing interpreters for languages that are simpler.
Tools, libraries, etc. While Perl 5 is really good there, Perl 6 is not quite there yet. Also there is no commercial company behind it, only a not too big (compared to Mozilla) foundation, which makes it harder to do PR and gain traction.
[1] think about it, libev, which was done done after libevent, and which for a while even was used by node.js, after they created libuv, mostly for better Windows support was done by a Perl guy and is widely used by the Perl community. Also they had callback, future, promise based systems and abstraction layers for quite a while.
So when you look at a language and ask why it isn't popular, the answer is probably not that it's bad or that it has terrible features or that it's missing things every other language has.
Instead, the relevant answer is some combination of timing, marketing and luck—and Perl 6 definitely flubbed the first two!
It's been, what, two decades since Perl 5 first came out? In that time, trends have changed, people's preferences have shifted (and ossified) and even the role of a scripting language is different. And Perl 6 is not making any of that up on marketing, niftly logo notwithstanding: the Perl brand has been pretty well tarnished over the past years which makes these the absolutely wrong coattails to try sliding in what is supposed to be a brand new language.
None of this, by the way, shows that Perl 6 is a bad language. That's a different discussion entirely—a discussion in which popularity plays a small role at best.
But it is to say that I'm not all that surprised Perl 6 hasn't gotten anywhere.
They should drop the name Perl altogether and go for Rakudo IMHO
That would be a great idea. Inside the Perl community, everybody is already invested in Perl 5, and Perl 6 is just too different. Outside the Perl community, nobody would want to be found dead with anything called Perl. If Perl 6 is sufficiently better and sufficiently different, releasing under a new name would make a lot of sense.
A cousin of that problem is it doesn't matter how many years ago "Modern Perl" was written, today MySQL still doesn't support transactions.
Not a non-sequitur, in that to this day you'll still run into people swearing mysql doesn't support transactions because last time they looked into it in '94 it WAS true, mysql didn't add transaction support until the late 90s IIRC. Likewise its a law that all Perl discussions ignore everything that's happened in Perl development in the last 20 years. If no one has written code like that since '96 it just doesn't matter to the discussion.
But more importantly, NOBODY I know and rate has come to me and told me "You know what? Perl has moved on, it's actually become a wicked language, you should give it a shot". Whereas that has happened to other languages that I had given up on (ActionScript, JS, PHP) and I had no problem going back to them.
As for MySQL, seriously? Are there people who think that in 2016? I find it hard to believe. One thing is a programming language, but for a RDBMS it's just a matter of time before all the feature developer wants get added. With MySQL it's just a matter of "so what's version is it now, have they added them yet?"
Yet, as a previous Perl 5 programmer that abandoned it when better languages got powerful enough... How can Perl ever fix it's image in my head, so I'd take a deeper look at it and evaluate this new language?
I don't know the answer here. But there are a few things I know. What normally makes me look at languages is a combination of:
- Competent people recommending it. (This one is keeping open to learning Perl, but it's still not recommended enough for me to stop and learn it.)
- Unique new features. (Stuff that are in no other language. I don't see many for Perl)
- Community and ecosystems. (Those will drag me into a language, instead of leading, but they do make me look. Again, Perl has nothing here.)
So, Perl 6 has a bit of one of those, and it may be unable to ever get anything more. If for not other reason, because of bad standing image that won't attract many competent people for recommending it. I'm not convinced it will ever get anywhere, whatever is the actual language quality.
It's also perfectly possible that it does not add much value and I shouldn't mind learning it.
And there's a lot of effort required to discover what of those is true.
I've been converting some old stuff to it to learn it, and it crazy how much more compact things can become. Working with grammars has been amazing. And I'm just now getting hit over the head with how flexible class roles with parameters can be to consolidate methods that do similar, but slightly different things.
I haven't even started into the concurrency bits yet... something about "promises" and "supplies". But I'm actually looking forward to it at this point. And that's really a surprising thing to me ;)
Anyway, my 2 cents on it at least. I'm not sure it matters if Perl is ever a poster child for anything. I think it kinda just doesn't matter.
Oh gosh that sounds scary. A lack of compactness was never Perl's problem, quite the opposite in fact.
> one should do token golf, not keystroke golf
> would be a nice cultural hack to start the Clean Golf meme
Or like type. I've been loving their type system. You can use Perl as a heavily typed and enforced language, or not at all. And it's really easy to make up your own types, which you can also easily use for handling arbitrary constraints you might need.
subset Even of Int where * mod 2 == 0;
(1..1000).map: { when .is-prime { .say }
when Even { say 'EVEN Num' }
default { say 'no'}
}
subset Even of Int where * %% 2;
subset Even of Int Where $_ %% 2;The two main reasons: (a) It's still not finished, but mostly (b) all I ever see is people in love with how clever they can be with the language.
I don't need to see hyper-clever ways of using built-in lazy memoised lists to generate a Fibonacci sequence in a dozen keystrokes. If I get tempted over to Perl6 (or any other language) it'll be be by examples of how easy it makes the boring, mundane tasks that I actually need a langauge for - things like reading from/writing to files; handling dates/times nicely; etc. etc.
What I like about Perl5 is its "Make the easy things easy and the hard things possible" mantra. The only mantra I hear from Perl6 is "Look how cleverly you can solve this contrived example". That's not something I care about in the slightest when I think about what language to write my next program in.
B) All of the below is core language, not a use or import anywhere required. Error reporting is also handled for you without autodie and friends.
Reading from a file:
#Efficiently line by line for STDIN
for lines() -> $line {
$line.say;
}
#Get everything in RAM right now
my $string = "filename".IO.slurp;
#Lazy list will do IO as you request into the list
my @lines = "filename".IO.lines;
#Listing of directories if the path is a directory
my @directories = "coolstuff".IO.dir if "coolstuff".IO.d;
Playing with dates:
#Get a DateTime for right now
my $date = DateTime.now;
#Does what it says on the tin
say "Yippee" if $date.later(:5years).is-leap-year;Is that a Georgian or Benghali or Indian or Buddist Era Thai leap year?
Actually are we talking the Georgian calendar - or the Julian, Revised Julian, Coptic, Ethiopian, Chinese, Hebrew, Islamic, Hindu, Bahai, or Solar Hejri calendar ?
https://docs.perl6.org/type/Date
"A Date is an immutable object identifying a day in the Gregorian calendar."
I like a language that's not surprising, with easy to find answers. My experience with Perl over the decades is everything about it meets expectations to a spooky extent, which is also nice. The surprise factor for Perl is very low.
It seems to define excellence in programming language documentation. Is there anything better out there?
"A Date is an immutable object identifying a day in the Gregorian calendar."
(It's proleptic.)
The days used in DateTime, which is compatible with the Date class, also identify days in the Gregorian calendar.
(DateTime adopts RFC 3339[1].)
The `is-leap-year` methods for both classes refer to the Gregorian calendar year.
For a civil calendar independent date, use the `daycount` method to return a Modified Julian Day[2].
The `Dateish` role[3] abstracts from any particular civil calendar.
I'm not aware of any routines, built in or in existing Perl 6 modules, for conversion to other calendars.
[1] https://www.ietf.org/rfc/rfc3339.txt
B) Nice examples. Well done. But it's not about whether you can do the simple things. It's more about the impression of the community and where its interest and focus lies.
I'd rather use a language where the mundane day-to-day stuff is the most important consideration. My impression of Perl6, however unfair that may be, is that the day-to-day functionality is the boring necessary evil that must be in there somewhere, but the true focus is the amazing stuff you can do with a language that's simultaneously trying to be a better Perl, and a better Lisp, and a better Erlang, and a better Haskell.
In my mind, Perl6 is a huge lumbering beast that tries to do absolutely everything. I'm sure if I ever feel the need to write a lazy asynchronous parser script, it'll be the first language that leaps to mind. In the meantime, I don't have the time nor the interest to bother.
The spec was frozen last Christmas, with a corresponding compiler release.
That said, it seems like a really interesting language.
Around 2000-2001, I worked on Perl 5 in a close-knit team at a dotcom startup. Even with daily interaction, it was really hard to keep coding standards straight and readability under control. The problem with Perl is that it tends to be a different language for every programmer. Its flexibility leads to arcane code that can only be easily understood by the person who wrote it.
Years later, in different roles, I've worked extensively with both Ruby and Python (I prefer Ruby). I will never, ever, ever go back to Perl for anything more than one line long. I still use Perl for 'perl -e' one-liners in the shell, mostly complex greps. That's it. If I write anything small enough that structure doesn't matter, I use /bin/sh. If I write something large enough that structure matters, I use Ruby.
Why? Because I like to be able to read my code.
Ruby is wonderfully expressive. It can do everything Perl can, and it does it in a much more readable, much more human way.
My rule is pretty similar now: Perl or Bash is fine for one-liners or a script which fits in an 80x25 window and doesn't use non-scalar data structures but anything longer or which has much expectation of maintenance is written in something like Python where the culture and tooling favor readability.
Larry Wall (primary author of record for both Perl 5 and Perl 6) noted in an article[1] that:
"Perl 6 is also a completely different language ... [that specifically addresses] readability"
Or, in greater depth:
"Perl 6 is also a completely different language that has been rethought and rebalanced on every level, with much stronger support for both functional and object-oriented programming as well as reactive and concurrent programming.
There is now pervasive concern for composability, evolvability, readability, and maintainability.
We try to "hang everything on the right peg" to allow proper separation of concerns.
While we still believe in providing multiple ways to accomplish something, we now try to encourage one of those ways as an appropriate starting default.
So we think the language scales both down and up to the level of talent of the programmer; the programmer can start out in "baby talk" without getting into too much trouble and then whenever he or she is ready to learn a new concept, the language is ready to support that and to make it easy to refactor the code as the programmer grows in sophistication.
For developers who are already sophisticated, they'll see that most of the problems endemic to the currently available dynamic languages are solved in Perl 6.
We understand lexical and dynamic scoping. We detect most typos at compile time. We don't have a global interpreter lock. We encourage Smalltalk-style trait composition over uncontrolled mixins, multiple inheritance, or monkey patching."
[1] http://www.infoworld.com/article/2882300/perl/perl-creator-l...
JavaScript, for all its blecherous losing horror, had a compelling use case - it ran in browsers. Later, Node became a compelling use case, for dealing with both performance issues and package management problems that plagued other systems (including Rails).
Python had multiple compelling use cases. It became very popular in math programming and teaching, for its clarity and consistency.
Perl's compelling use case was with Perl 4, as a general purpose glue scripting language in a Unix world. It solved tremendous problems. Perl 5 didn't have a compelling case, and it grossly exaggerated the already bad problems with complexity and inconsistency. Am I talking about Perl 5? Yes, because for 22 YEARS, we've been saddled with that crap. Two decades of waiting for Perl 6, for Perl to unfuck itself and become something useful for more than one person at a time. That's like, my entire career. Longer than most programmers in this industry have been in the industry. Longer than some of them have been alive. 22 years.
So why, why, why should I switch? What's the promise now? What problem am I having with Ruby that it can solve?
All good questions. My personal answers boil down to "no need" (to switch), "see the rest of this thread" (to read what promise Perl 6 might have), and perhaps https://docs.perl6.org/language/rb-nutshell (to read how someone familiar with Ruby explains how to map Ruby knowledge on to Perl 6).
So why do it? Mainly, if the framework I'm currently using can't do things I need to do, or if it's incredibly painful to use. To the extent that someone has neither of those problems, a new language is a cure worse than the disease, whatever its benefits.
Look at it this way... imagine there's a rib joint across the street. It may not have the best bbq, but it's there. Do I walk across the street for bbq, or do I drive halfway across town to get slightly better? I'll take what's there, thank you. Now, if I'm a vegan, I'll get up and go somewhere else.
Ruby's "DSL" ability is what allowed Rails, in Perl 6 everything is a DSL. Even strings are written a customizable DSL. You can turn on and off string features, and add new ones. It goes even deeper than that, you can swap the parser out with a new one mid-parse. One implementing Ruby for example. ( While it is possible to do this today, this isn't specced yet, as the exact way to do this is still in flux to get it to the same quality as the rest of the language ) So in a sense, all programming languages can be thought of as a subset of Perl 6. ( There would be little point in doing this for assembly though, as it will probably have to be emulated in most cases ) This feature is usually only used to slightly alter the existing parser currently.
That isn't even the best part, many features from other high level languages have already been brought together in Perl 6, in a way that makes them seem as if they have always belonged together.
If you asked a random sampling of people about which feature that they like in Perl 6, you will probably get a different one from each.
Exactly. Larry Wall cited an analogy somewhere: if you want to know where to put walkways on a new campus, wait until pedestrians have worn trails into the grass and pave there. Perl docs repeatedly makes jokes along the lines of, "it does what you want, unless you want consistency. Bottom line, Perl was designed without predictability and consistency in mind. This makes it blazingly fast for development by one person, but the administrative overhead between multiple programmers balloons.
Because of a natural inclination to reduce the number of characters one uses, as you get comfortable with Perl you start taking more and more shortcuts. A singular moment in my long career occurred when I opened some old Perl code after leaving the language for a time. I stared for a long moment, dumbfounded. It was as if an alien had visited my computer and overwritten my code with what Wall has affectionately described as "line noise."
Also, I was awed by the feature set in Perl 6. I don't think any language outside of Lisp, C, and Smalltalk has had such profoundly new ideas. Pronouns in Perl 5 are still unique to my knowledge after 20+ years. Wall is wildly imaginative.
Perl is what made me realize, in the mid-90's, that OO is largely just a marketing term. A sufficiently powerful language provides whatever portions of OO you need a la carte.
It'll also take a bit for people who loudly push 25-year-old languages like Python and Ruby like holy grail to... die off (no, I don't want them to convert). Perl 6 is a next generation language over them and it'll take next generation of programmers to make use of the new programming paradigms.
What you're probably asking is why hasn't Perl 6 went viral like Swift, Rust, or Go? Well, we don't have a multi-million (or -billion) company backing us, so fanboys and people who are after the latest shiny things aren't flocking to us like to manure. But look around this site: those langs get as much nonsensical comments from the Python-Ruby zealots who are too scared of new languages :)
Perl 6's first production release was less than a year ago. It's a bit unrealistic to expect it to be a "poster child" of anything so fast. If you're old enough to remember, no one gave a shit about Python until at least second version.
Don't worry about popularity. Learn many languages and use what you like using.
> It'll also take a bit for people who loudly push 25-year-old languages like Python and Ruby like holy grail to... die off (no, I don't want them to convert). Perl 6 is a next generation language over them and it'll take next generation of programmers to make use of the new programming paradigms.
... the kinds of paradigms or ng features that perl has that python doesn't?
I am talking more about programming thinking than a feature set. That there's no such thing as Unicode issues or needing to use silly "u" prefixes. That 0.1 + 0.2 == 0.3 reliably that you can write accounting software worry-free and not wonder about why it fails in so many old langs. That you can use grammars to write a mini-language for your specific problem to save yourself tons of generic programming. That you can branch off into a separate processor core with a simple `start` keyword or parallelize a method call on a list of items with just a `>>` hyper prefix or seamlessly communicate a job parallelized over 30 cores with yet another core with a simmple channelled supply without worrying about data races.
These features may be present in Python, but way of thinking isn't. A new programmer starting in Perl 6 won't think of multi-threading, Unicode, floating point math as problematic areas and grammars together with full-language maleability that lets you create problem-specific langs instead of a mountain of generic classes is undreamt of by oldschoolers like me.
It's interesting that you lead with a bunch of examples which are very old or simply wrong.
For example, in any language where you don't think about Unicode you are guaranteed to have encoding issues as soon as you have sufficiently diverse (i.e. real-world) data. If Python 2's u"" prefix offends you so – I must say, hearing a Perl programmer complain about punctuation is a somewhat novel experience – note that Python 3 was released in 2008 which changed to use Unicode by default. In every language, however, you will need to think about file encodings everywhere you read or write data until we finally hit that halcyon decade (century?) where you can assume UTF-8 with a very high level of confidence.
Similarly, Python has had decimal-accurate math since the early 2000s so the developer is free to pick whether they value absolute precision over standard IEEE floating point semantics. Perl 6 dynamically switches numeric classes so the simple syntax you show will lose precision at some point depending on the data and order of operations – that's why the documentation specifies Rat as “limited precision” and it means that anyone writing accounting (or, in many cases, scientific) software would explicitly use an arbitrary-precision data type to avoid the classic floating-point math problems:
$ perl6 --version
This is Rakudo version 2016.10 built on MoarVM version 2016.10
$ perl6
> 123456789 - 1e-5
123456788.99999
> 123456789 - 1e-6
123456788.999999
> 123456789 - 1e-7
123456789
> (123456789 - 1e-1) - 123456789
-0.0999999940395355
> my $a = Num(12356789)
12356789
> $a + FatRat(0.1) - $a
0.099999999627471
> my $a = FatRat(12356789)
12356789
> $a + FatRat(0.1) - $a
0.1
> 123456789 - 0.0000001
123456788.9999999
> (123456789 - 0.1) - 123456789
-0.1
> (1 / (10 ** 100)).WHAT
(Num)
> sin(0).WHAT
(Num)
Reference: https://docs.perl6.org/language/syntax#Number_literals https://docs.perl6.org/type/Rat
Sure, but Python 3 only took on correct handling at the whole string level. It ignored correct handling at the character and sub-string level. Something similar applies for many programming languages. I think this was Zoffix's point.[1]
> explicitly use an arbitrary-precision data type to avoid the classic floating-point math problems:
> 123456789 - 1e-5
123456788.99999
> my $a = Num(12356789)
12356789
> $a + FatRat(0.1) - $a
0.099999999627471
> my $a = 12356789
12356789
> $a + 0.1 - $a
0.1
> $a + 0.00001 - $a
0.00001
[1] Of the 150+ languages with Rosettacode solutions for returning the length of a string (at http://rosettacode.org/wiki/String_length) just 3 (Elixir, Perl 6, Swift) have a built in way to get the right result for what Unicode defines as "what a user thinks of as a character".
It very well could have been what Zoffix had in mind but do note that this goes back to the problem with the rant style of post.
As for the specific question of character handling which you raised, given the wide number of people who have made other choices on the question of whether a length function should count codepoints or graphemes that I'm reluctant to say using one versus the other is a question of “correct” or “incorrect” versus simply “different”. I suspect most programmers are rarely going to care and the ones who do are going to need to learn enough more about Unicode and i18n that this difference will not be a deciding factor for anyone.
(This is not to detract from the great history the Perl community has with taking seriously the benefits of having a rich Unicode API – I've routinely used this as an example to follow – but simply that Unicode is a deceptively simple-looking topic)
> Literals of the form `1e-5` are not arbitrary precision in Perl 6. They are floating point (called Num in Perl 6).
Yes. Again, my point wasn't that Perl 6 is bad but rather that it's lazy and ineffective advocacy to say something like “you can write accounting software worry-free” when you know full well that anyone doing that for real will still need to understand the differences and that most users will never care because they aren't writing financial software.
However, keep in mind that I was responding to a comment which simply referred to “Unicode issues or needing to use silly "u" prefixes”. This whole tangent started with a guess about what the author might have had in mind.
On this specific point, note that I wasn't saying that it wasn't good to have both but that I wouldn't call a language incorrect for working only with Unicode codepoints. That's because for most programmers this entire class of problem is someone else's problem – usually whoever wrote the text rendering engine in your browser or OS – and the people who do need to care have needed to learn most of e.g. http://unicode.org/reports/tr29/ anyway and understand which portions are relevant to whatever task and data they're working with. It's kind of cool that e.g. 'क्षि'.elems == 1, 'क्षि'.chars == 2, etc. but on the rare occasions where that would be more than trivia, I was more interested in questions like measured width in a certain font or language-specific collation or word-breaking rules.
This is all coming back to why I don't think attacking other languages is effective advocacy unless you're very knowledgeable on the details and impact for working programmers. Telling someone that a commonly used tool which works well for millions of users is incorrect is unlikely to produce the desired outcome. Showing them a cool thing which your favorite tool does better is usually going to be more effective because it gives you something concrete to talk about and it's not confrontational. Programming languages are a major commitment and very few people are going to switch because of one bullet point – that either takes market requirements (e.g. Objective C/Swift, JavaScript) or gradually building up a good reputation over time.
I didn't call Python incorrect. I'll footnote another attempt to communicate the point I was trying to make.^1
> for most programmers this entire class of problem is someone else's problem
Do you primarily mean most western devs when you say "most programmers" or are you including chinese, indian, etc.?
Do you primarily mean rendering issues when you say "this entire class of problems" or do you mean the full range of character handling issues that ordinary devs occasionally encounter such as comparing strings?
> and the people who do need to care have needed to learn most of e.g. http://unicode.org/reports/tr29/
To date, and for the near term future, sure.
But do you think it was the long term intent of Unicode that devs who merely want to grab the first three characters from a Unicode string have to first get up to speed on these incredibly complex portions of the Unicode standard if they wish to get it right?
TC made great points in his SO -- but so did the guy asking the question.
Now users have begun inserting colorized emojis and other such complexities in what might reasonably be considered contemporary run-of-the-mill text strings (eg tweets). I think this problem is going to accelerate.
Those who designed Elixir, Perl 6 and Swift have taken on Unicode, including TR29, as a core language level responsibility so that devs who merely use these programming languages don't immediately get overwhelmed when they just want to compare two strings.
> 'क्षि'.elems == 1
In Perl 6 `.elems` is always `1` for any single string of any length.
> 'क्षि'.chars == 2
By default, character boundaries are determined by the default EGC algorithm specified by Unicode. The default EGC algorithm gives the incorrect result for क्षि.
Getting the correct result (`== 1`) would require `use`ing a module that implements the appropriate tailored grapheme clustering.
> I was more interested in questions like measured width in a certain font or language-specific collation or word-breaking rules.
For now, the Perl 6 perspective on such matters is that devs should use the appropriate Perl 5 modules:
use Some::Perl5::Module:from<Perl5>;
... Perl 6 code ...
----
^1 A search for "grapheme" (the term used in the Unicode standard to denote what I mean by "atomic character" and what a user thinks of as a character) yields zero matches. Does Python doc use some other term to denote what a user thinks of as a character? Microsoft uses the term "text element". Swift and Perl 6 use the term "character". What term does Python use?
A search in the Python 3 docs for "character" yields several pages that total over 500 matches. I looked at a few. All corresponded to use of the word "character" to denote a codepoint (an accent, a colorizing instruction, a bidi directive, a base letter, etc.). None corresponded to what a user thinks of as a character. Do you think any uses of the term "character" will turn out to correspond to what a user thinks of as a character / text element / grapheme / whatever you and/or Python docs wish to call them?
Grammars are YACC on steroids. You can very simply say "this parsing state requires reading dot-separated things".
Junctions define multiple plausible states. In certain instances, they can look like a feature you know, but they're more generalized than any of those: sum types, switch statements with multiple cases, combined guards, sets…
Autothreading gives the ability to automatically parallelize certain constructs (for instance, when an expensive operation happens on a junction).
Perl6 also includes features found only in non-mainstream languages, like lazy lists, macros, and runtime addition of syntax.
And it has most modern concurrency primitives, unlike most languages which only have one: threads, locks, semaphores, promises, channels, event loops, supplies.
To be clear: Perl 6 is not without flaws (marketing and performance, for instance), but it is definitely innovative. It lets you write expressive code more succinctly than mainstream dynamic languages, in a way similar to how Python lets you write expressive code succinctly compared to C++.
I learnt ruby in early 2000', way before rails, because I was attracted to its "it's 100% OO" concept. Now, I use golang, because background jobs have progressively became a capital part of my programs, and I love how it's just about prefixing a function call with a keyword, in golang. The idea of having system programming-like perfs in web doesn't hurt either. What would you say are the groundbreaking new concepts of perl-6 ?
If you like go's conc stuff, then I'm sure you'll love Perl 6's async/conc/paralel. stuff: https://docs.perl6.org/language/concurrency#High-level_APIs
I wrote an IRC API with Perl 6 that I really love, since it makes it so easy for me to parallelize a plugin's work, while working with an async protocol, all the while connected to multiple servers, all with the same short script: http://perl6.party/post/IRC-Client-Perl-6-Multi-Server-IRC-M...
I'm going to be honest: nothing in what is described seems to me like a new idea that makes me want to try perl6. Floating point safeness is in R, dsl is in ruby, concurrence is in golang. And unicode... I'm not exactly sure what the problem is with other languages, I guess it never hit me. :)
That being said, it's cool to see all those features in the same language. I'll keep it in mind if anyone mentions all or most of those as pain points.
Examples: multi wins(Scissors $, Paper $) { +1 }; # dispatch on types
my @a = 1..5; say [+] @a; # 15
(a,b,c) Z (1,2,3) # ((a,1),(b,2),(c,3))
my $time = now; say now - $time;
class Person does Employee { }
use NativeCall; # WOW
and MORE !
So ansering: why Perl6 hasn't taken off yet ? Becouse language specification was released 11 month ago with referential implementation (just like Amaya in 1996). So give it 2 years, it will be "fully operational" ;)
I'm pretty sure you noticed this was exactly the questions my comment was addressing ;)
Needless to say the notion that python and ruby programmers are greybeards who need to "die off" to make way for the future of software development is not a rational assessment of the state of the industry.
The logo is cute, I will say.
See e.g. Inline::Perl5 and Inline::Python (don't know how mature that is).
>> For a new language to get adoption
I'm not really that knowledgeable right now, but how many weeks have Perl 6 (the language, not the libraries) had an implementation ready for production? :-)
Edit: Thanks, Ulti. Close to 50 weeks. Good work of the implementors. :-)
1) The field is pretty crowded. There's a lot of languages competing for attention. It takes time to learn. Which ones should I spend time on?
2) Momentum. Scripty siblings Python & Ruby & JS & even PHP have active communities with a lot going for them.
3) Baggage. Some of the conventional wisdom about Perl 5 is pretty iffy, but it's well established conventional wisdom, dammit! In fact, you'll almost certainly see it recapitulated in this thread. Most arguments to the contrary seem to be slow to make a real dent in what Everybody Knows™ about Perl. The fact that Perl 6 is a different language will probably be equally slow. People will repeat the comforting mantra that Ruby is the new Perl. Order will be reinforced.
4) Blub-ish paradoxes. Perl 6 is doing some weird and different stuff. Is it hyper-useful weird and different stuff? Will I know until I learn to use it?
5) Not a big win in terms of market value yet.
IF you are going to find Perl installed on some system, it's more likely to be Perl 5 than anything newer.
You are very likely to find SOME version of Python, or Python compatible thing on most Linux distributions. Anything really old you're safe targeting Python 2.6 compat, maybe 2.7 compat. Anything relatively recent you will probably find a 'decent' version of Python 3.
And this is surprising?
- Most perl developers moved on long ago. My last 3 bosses were all "perl" people who switched to Ruby as their primary language around 2010.
- No strong argument that perl 6 is "best-in-class" for any particular type of problem. This is often what brings interest in new languages (Go, Elixir, and Rust for example, all have this).
For most people the Unicode handling isn't the main problem they're solving, and most languages are more or less good enough now.
Yes, every other language has flaws on Unicode handling. But those flaws persist exactly because they are not important.
It's been I long time I don't write a "Unicode handling" application, yet the only environment where I ever got problems with it on the last decade was .Net. And it was a very small problem, worked around in less time than I've lost on this HN page.
I don't know why I should learn Perl 6 when there are so many new languages to learn. (Just keeping up with web-tech and Javascript itself takes an enormous chunk of time away)
Can a perl 6 geek give a use case of why perl 6 would be better choice than Ruby/Python/ES6/Java/Scala/C#/F#/Rust/Swift for an application in some domain ?
A comparison on where Perl 6 is superior on different parameters such as productivity, libraries, module system, documentation tools, packaging & assembly, macro and micro performance, runtime-scaling, concurrency models, hot-deployment, software-update, etc would be great.
use Package=1.2.3;
So you have some hope of using the system perl without dll hell.
You also have grammars, more readable regex language, and superb object model. On a more advanced spectrum, with grammars and slangs, you can craft your own mini-languages for a specific domain where they would fit better; there's a nice little presentation by Damian Conway where he crafts an operator for quantum mechanical math that looks and functions just like the proper mathematical symbol functions: https://www.youtube.com/watch?v=Nq2HkAYbG5o
As for the langs you mentioned: I find a lot of similarities between Rust and Perl 6, although in some areas it seems Perl 6 folks did more thinking (like the .match stuff). They are however in different domains, Rust being a systems language; but you can use Rust libraries in Perl 6 via NativeCall if you compile them for C calling convention.
Perl 6 smokes Ruby and Python with its asynch/parallel/conc. support and more advanced object model.
As far as Unicode support goes, only Swift comes close to Perl 6; try to uppercase "ß" in Ruby, for example. Even if you to claim you only write software for English-speaking customers, you still have to deal with weird customer names for example.
For parameters you mention, many people notice they have to write fewer code in Perl 6. Personally, I found when writing equivalent code as Perl 5, my Perl 6 versions were TWICE as short. And I don't mean you golf your program to anything unreadable, but rather the provided primitives are... well, modern... so I don't have to reinvent them with more basic primitives provided by older langs.
What you'll find is performance is a bit crappy right now. Perl 6's stable got released less than a year ago so there's still a ton of work left to do in bugfixing and optimizations. I think that's what a lot of folks fail to realize that Perl 6 is a brand new baby language so trying to compare its performance to Python (25 years of work) or Ruby (21 years of work) or ES6 (tons of corporate interest) is a bit unrealistic at this moment in time.
In conclusion, one can list dozens of benefits, but I think at the end of the day, it'll all come down to which language better fits your brain and if you participate in a community, which community feels more like the folks of your kind. So far, anyone who I saw try the language say they loved it. The performance can use an improvement and that's what the core devs are working on. So, I think the steam is being gathered.
I discovered that Perl 6 Supply is basically the same as Streams/Sequences which is great for handling async activities and work units.
Also discovered that perl 6 has optional typing. This is terrific since it makes for better maintenance and refactoring tools possible.
I do hope the performance improves! There are so many competitive languages for the backend today that without excellent performance, memory management and scaling characteristics, it is difficult for any new language to gain traction just on features alone.
While this perception did hurt Perl5 it seems to have also hurt itself since reading this thread and seeing the number of people saying that it is "still in progress" or "still changing". This brings me to my second point, and the one that frustrates me more.
In fact Perl6 was released as stable 1.0 on Christmas of 2015. You could be excused for not noticing it. There were a few articles in a few technical journals in the months leading up tot he release but mostly the release day went by completely unnoticed and barely remarked upon.
Perl6 is a spectacular achievement! A language designed over the course of 15 years with the extreme flexibility and malleability to last 100 years more. This could have been a news story, a big release party, lots of hype, press releases. A language in the works for 15 years, it must be great right!?
Instead, to keep with an in-joke about "released by Christmas" it was released on Christmas day by developers who had family plans to a community that was busy with their own. I doubt many people know it happened. Indeed this thread seems proof of that.
Its not everyday that a 15 year project is completed. What an opportunity for exultation, and good press, wasted.
Sorry, but that's just wishful thinking. We don't have infinite resources or infinite number of volunteers. Maybe instead of endless critique, you could offer a helping hand. You did want to at one point: https://irclog.perlgeek.de/mojo/2016-10-09#i_13366119
Perl says "there's more than one way to do it"
Python, by contrast, says "There should be one-- and preferably only one --obvious way to do it."
The practical outcome of the Perl philosophy is that Perl code can be extremely varied to get the same thing done and therefore much harder for different programmers to understand and maintain. Python programmers are more likely to quickly understand the intent of a chunk of code regardless who the author is.
Perl at its worst can also be pretty arcane and I've heard it described as "executable line noise". That doesn't make for maintainability.
> Yes, sometimes Perl looks like line noise to the uninitiated, but to the seasoned Perl programmer, it looks like checksummed line noise with a mission in life.
edit: formatting
I moved to Python for a later project (a custom CI system) and while there were people of varying skill working on it, the code looked the same because of the "only one way to do it" philosophy. Similar formatting, same idioms, readable code etc. This alone justified moving to Python for me. I could fix a problem in about a tenth of the time I needed to fix a similar bug in the perl codebase.
A huge part of this is due to the bad coding practices and relative inexperience of the programmers on the perl project. However, my feeling is that, perl is forgiving when it comes to style. It allows a skilled used to create really beautiful programs but pays the price by allowing terrible programs by bad programmers to run sufficiently well. We compared it to English. Very flexible, very forgiving when it comes to grammar and syntax if your intention is just to convey meaning.
(as far as I know, Python doesn't give you an error message when your function gets up to 66 lines, or whatever, long)
But, in my experience, because of the limitations on how flexible the language is, a 3000 line python function which is edited by multiple people is usually more readable than a 3000 line perl one.
(As an aside, you can make it more horrible because you don't even need a "run" function - just stuff it into the *.py file and it'll get executed :) )
Maybe a better question is: what makes 3000 lines single-function code so prevalent in Perl?
There's something to say about Perl 5 making function arguments difficult. But I don't think it ends there, because other languages attract the same kind of code.
YMMV, as they say.
This attitude is not very good in corporate environments where all code produced must be uniform so that new people can come and go and the software keeps churning out money.
Contrast this to Python which is a much more enterprise-y language, which is the reason for its success.
you mean, like string interpolation? :)
Ruby is probably the main reason Perl lost so much market share, since it took a lot of the underlying philosophies from Perl and turned it into a beautiful, easy-to-read language.
> turned it into a beautiful, easy-to-read language.
and got annoyed (presumably?) that Python wasn't mentioned, but you completely ignored:
> it took a lot of the underlying philosophies from Perl
Ruby is a lot closer to Perl than Python is, which is what the draw would be for people migrating away from Perl.
I kept writing quick throw away text processing scripts in Perl until a few years ago, when I started to forget how to write the basic constructs due to lack of use. I'm writing them in Ruby now but I think that Perl was better suited to the task. At least I can read the Ruby ones years later.
But am I giving a try to Perl 6? No, I don't even know how it looks like. What problem would be solving for me? Who else is using it and for what? Can I go to a customer and say let's use Perl 6 for this project, don't worry you'll find many other developers to carry on development if I won't be available anymore? Not yet.
Again, this is my own personal opinion. I know many people have made some great software based on Perl, but it's the only language I won't touch with a 10 foot pole, and I've spent a couple of years programming in PHP and a year in COBOL.
|| has a higher precedence than or in Ruby as well.
> rubocop -D foo.rb
Inspecting 1 file
C
Offenses:
foo.rb:1:3: C: Style/AndOr: Use || instead of or.
a or b
^^
1 file inspected, 1 offense detectedBut ruby was a quite a happy move for me back then in 2006, language was underperforming, features were lacking, nowhere anything like CPAN, but I could express logic much closer to how I think about problems, without additional layer of "thought translation".
I've seen some expensive boo-boos due to operator precedence mistakes (e.g. - in C)
That said, there are a lot of special variables that can be tedious to figure out (e.g. - $" vs $;), if somebody uses the less frequently used ones, rather than the long-form names.
man perlvar
I can remember $_, $? and $!, but that's about it. And I like Perl.
The rest were either just abandoned or given names such as $GROUP or $PROGRAM-NAME
$/ isn't the same as it was in Perl 5 instead it is for storing the result of successful matches. ( you can also assign to it )
$0, $1, $2 is short for $/[0], $/[1], $/[2] $<abc> is short for $/{'abc'} which can be spelled as $/<abc>
Many years ago, I had a bookmark in my C manual (Harbinson Steele) for the operator precedence page.
After a while I removed that bookmark. I decided that if I needed to look at that list, I should use parentheses. :-)
> who knows :|
> It Just Is.
> remember, perl is a memory competition
There is a LOT to remember about how Perl works.
1. PCRE copies the Perl regex syntax almost completely (except some much newer cases than \A and \Z). See e.g. http://www.rexegg.com/regex-quickstart.html for \A, \Z, \z
2. If you check http://perldoc.perl.org/perlre.html then:
\a alarm (bell)
\A Match only at beginning of string, as PCRE.
\z \Z Same as PCRE. (But \z is not in Regexps for Python/JS.)
It _is_ a memory competition though. In the various languages I've learned, Perl feels like it has the most to remember about how things work or interact (ymmv of course, I'm speaking of my experience here).
Expressive is the good side of this. But you really need to have coding standards in place.
On this subject, to upgrade to Perl 6 will be a bit scary, like driving a much faster car. :-)
6 Looks just fine as a language, but it really does feel like a completely new language which means it's less a migration and more a re-write. Which then leads to the question: if we're going to re-write, should it still be Perl?
And I'm not touching the "Perl 6" naming discussion.
There is inlining for using Perl 5 libraries in Perl 6, which smoothen the road. But it is a hard start to motivate projects in a new language, which is incrementally better. I would be happy to try.
Just because both slots are filled with the same "value" in perl, doesn't mean it's _not_ a dualvar. It's just a side-effect of the way scalars in Perl work.
It don't happen to me often, but I sprinkle "+ 0" and so on, without thinking about it.
The ASCII table used to be the alpha and the omega. :-)
That is, it was not so much of unnecessary extra detail when the char codes was inserted into Reg exps. The newfangled Regexps and grammars of Perl 6 cleaned out a lot of lint.
You could probably make an argument for starting to remove, not only add, [more] features when you declare a perl version in a script.
(And personally, I only ever used \n, \r, \t and similar. Everything else is as Cthulhu meant it to be, octal. Regular expressions' problem always was readability, I never used more features than I need and /x is my friend. That said, the "modern" Perl 5 regular expressions are like grammars, really cool.)
This one is useful. Remember that Perl was created for being a more powerful kind of shell.
Those operators have their precedence set so that you'll use || as a logical operation inside a command, and "or" for control flow between commands. The same is true for && and "and".
The python community have just about managed to achieve a backwards-incompatible change, which was fairly minor and developed in a reasonable timeframe to address certain specific issues.
The Perl community were made extravagant promises 15 years ago. People started holding their breath for 6. By now, everyone has given up and the delay has asphyxiated the community. Not to mention that the Perl niche is much more crowded and still has a working, complete Perl5 in it.
However, some things seem to be harder. For instance, it seems that I can't use the handy =~ s/.../ string replacements anymore but have to write grammar rules. Is that true?
If the old way is still possible (without Perl5 mode) then I cannot find it in Perl6's documentation.
Apart from that -- good work!
BTW: There is only one thing which I really dislike about Perl6, and that is that "nifty logo" :-) If you want to attract professional developers you should provide a professionally looking logo.
I personally like the method version: .subst() and .subst-mutate()
The "Learning Perl" book sucked hugely. CPAN is pretty cool but too many modules have poor documentation and almost no example code.
Web app frameworks got convoluted and didn't make things easier and tended to lock you into doing things their way.
Despite that, I still liked perl because it did let me do things my way. I waited and waited for Perl 6, and then quit caring.
This year I finally rewrote a perl/cgi web app in Javascript. What little server side I code I needed I used Perl 5 but there was very little.
Wow. It's always interesting to see how people can have such different takes on things. Perhaps it was the time in my programming career that I read it, but I remember being impressed with some of the programming practices it instilled. Never used Perl a whole lot, but the way Schwartz presented programming, not just Perl, I found very useful.
c.l.p.m. on the other hand, was a hatefest dominated by people who seemed to resent the peasants daring to touch "their" precious programming language.
I suppose we came in hordes and stormed their gates but all they really had to do was provide us with a space and that didn't happen.
Ironically, they did the same thing with the Raspberry Pi foundation reached out to them. No one responded.
I even went back to the "Perl Beginner's" mailing list and told them about the RPi Foundation and that Perl was being reviewed for the languages they would support with their Edu projects. No one responded.
At that point I don't think Larry Wall was involved much with Perl 5. And I know a few years before that he was frustrated with with lack of a cohesive path for Perl 6, and that not long ago he talked about how the Perl 6 Community had to reach out to educators and get involved with programs for kids.
The Python community did respond To the RPi Foundation when they reached out, and in a big way too. That's paid off big for them and the Foundation. Kids are growing up with Python now and will know it well and use it.
This evolution of languages has been interesting to observe.
Perl is the only language where devs see unreadability as a badge of coolness, indeed there was even an Obfuscated Perl Contest: https://en.wikipedia.org/wiki/Obfuscated_Perl_Contest
(There are golfing competitions in other languages, for example js1k, but the focus there is download size, the fact the code is obfuscated is a side effect rather than the point)
When I was still active on their mailing list there was a lot of excitement around Perl 6. By the time I left most others had already been long gone. They'd gotten smacked too many times.
None of that is Larry Wall's fault. He's been herding cats since he started these projects. I think Larry is great.
Perl Monks was super helpful to beginners and intermediate Perl programmers; unmatched then or now, I think; maybe the Go community is a modern parellel, as it has a very beginner-friendly culture, IME. IRC was always great (though I must concede it is somewhat cranky these day...not unhelpful, but not always as gentle about helping as it once was). I don't know which "Beginners Perl" mailing list you're referring to, but the ones I used to follow when I was learning (a couple of decades ago) were very helpful.
I'm sure there are cranky old Perlmongers in this world. And, it's been so long since I was paying close attention to beginner resources that I may have missed a shift in tone in that time. But, Perl, to me, was a great learning language.
And, I liked Learning Perl, though I think the Camel is a better book, and if you're not a true programming beginner, Programming Perl is the better book to read. Learning Perl teaches Perl and programming at the same time, and may not be the best way to learn either; though, again, I thought it was quite good, and was very empowering for me.
That's a great point. I've never thought of it like that but that is no doubt the reason why I strained with "Learning Perl".
Thanks for pointing that out!
We've taken something of a chainsaw to the 'RTFM dumbass' side of the community over the past half-decade or so - you can even discuss perl on irc.perl.org #perl these days.
That makes me want to join again!
The reason why existing Perl 5 developers don't migrate is because they don't need and/or want to. The benefit would mostly be derived from writing new code, but most Perl 5 code in the wild are legacy systems and complex admin shell scripts. Those are exactly the kind of thing that you don't want to rewrite in the latest-and-greatest; the potential to introduce subtle bugs by upgrading is more important than the benefit of being able to use new constructs in those parts that you need to improve. And the vast majority of new code is also admin shell scripts written by experienced greybeards, who really don't like their cheese moved, and so will stick to what they're used to for as long as they can.
Exactly. I continue to use Perl (5) for text munging, data cleaning, and gluing together programs written in other languages. It was designed for these tasks, I still need to do them, and nothing has come along since that is substantially better. When I need to do other things, I use other languages, and so far I haven't seen that Perl 6 has a "killer app."
Maturity: Perl 6 was released a little under a year ago. That's not long, and the leading implementation has not yet caught up with the standard (though work is ongoing). The ecosystem isn't quite there yet either.
Examples: People can be really bad at imagining value in the right things - they need to see it. There hasn't been a very compelling killer app yet.
Perception: People conflate Perl 6 with Perl 5. (Reasonably!) Most people remember TIMTOWTDI and remember that it was a bad thing, or at least that they prefer the Zen of Python. Most of all, they remember trying to read bad code. I don't think that Perl encourages bad code, but it sat in spaces that had lots of bad code already. (Lots of code made by people who are not programmers.) There are also codebases in Perl that are very well made, and easy to read. But we are better at remembering bad things.
Again, IMO, Perl 5's biggest problem was the surprising language. I could write something that was legal code, but had different semantic value than I thought, and the language was littered with cases like that. It was common to think that Perl was to complex for any one programmer to know.
Perl 6 isn't like this - the entire language is composed of simple components (at least, simple for their problem domains). It's also littered with good ideas that don't exist in other languages, like their regexen and grammar support. Everything else in the language is still top notch, like unicode handling and concurrency.
Basically, it is the things around the language, not the language itself. I think it is telling that people saying they don't want to use the language are saying "Perl sucks" rather than "I don't like feature X" or "This construct is confusing".
(I remember Eevee saying that "Perl 6 is truly the realization of Perl 5’s mission: to be startlingly consistent, and also just plain startling." I think that when people look at Perl 6, they'll be startled. But when they are no longer surprised, they'll just find powerful consistency.)
> So, why isn't it the poster child of the scripting languages yet?
Why would people move from PHP or Python back to Perl ?
i think the story it similar to Visual Basic 6 and VB .NET: the change between perl 5 and perl 6 is really big, perl 6 is a new language - not just a change of version, people who are comfortable with perl 5 have little incentive to learn it all again (or they have switched to python)
Six years ago I got into a flamewar on Hacker News about Perl 6 not being done yet and had to clarify to an angry Perl hacker that by "not being done", I meant, "as of 2010 we only have an incomplete implementation of a draft specification of the language".
More like it took 14 years for the first attempt (Parrot) to be abandoned, and about a year for the second attempt (MoarVM) to be somewhat usable, but still not really production ready.
To the OP it's quite simple - Perl 6 isn't done yet, it's still in development.
People use this as a negative all the time, or as "the reason" it hasn't picked up, but the rules of software dev are simple: ship fast, ship efficient, ship cheap -- pick two. It's FLOSS, so one choice is already made: ship cheap. Glad that Perl 6 went with efficiency over getting to market quickly.
Spend some time with the language and then go find me anything that comes close to covering the same number of programming paradigms, let alone the coverage of the standard library, then tell me that it missed its shipping target.
tl;dr -- 15 years after it started and it still manages to be more featureful than anything else out there.
But i hate Perl6. It feels like an obnoxious showoff who people prefer not to talk to.
It offers little that I crave for in Perl. And those bits I can do with Go already.
Perl6 is a distraction from what we should have had .. I'm still dreaming of the day Perl7 comes out with these features: (i) full Perl5 functionality (without having that klunky Inline::Perl5), and (ii) built-in concurrency.
Perl6 is late to the party. Sorry kid, nobody likes you and besides, it's time to go home.
Curious: can you further define 'klunky'? Thanks!
use Data::Random:from<Perl5> <:all>
In my opinion perl will slowly die because it has no social capital. A good sign of this is when you are around other programmers working on a real problem if you say "Hey let's solve this problem in perl!" it will almost always be the case that everyone can do it that way and knows exactly what perl to script (if they are of a certain age) but almost no one would even bother. Who cares about the why. It's just the fact. You get no extra points for knowing perl and for the most part if you are the guy on the team that is assigned to work on some old perl script it's probably a bad sign for you career-wise. Other languages, on the other hand, do have social capital.
Ultimately for me it's a lot like asking why everyone still uses the QWERTY keyboard when there are other keyboard layouts out there that are so much better. Perl might be better at some things, but like alternatives to the QWERTY keyboard, it's just weird to use it and the payoff isn't big enough to justify the change.
Just recently, Booking.com gave over $100k to continue work in Perl. Craigslist gave over $50k for Perl. These are huge companies doing amazingly well, all depending on Perl. And they give like this every single year. Got a few minutes, check out all the companies (including tons of startups) on BuiltInPerl.com.
Perl bad for your Career? Don't tell that to the people at BusinessInsider, who ranked it the highest paying language to learn: http://www.businessinsider.com/9-tech-skills-that-pay-over-1... And they aren't alone. A recent Gartner study says "Current and prospective Perl developers should feel confident that the language will remain a solid technology investment for the foreseeable future."
The truth is Perl is the original QWERTY keyboard. But many people left it a long time ago for some really good reasons, and Perl took too long to fix those issues. Many of the reasons people left have been fixed for years or decades now. But anybody in sales will tell you it takes a lot more effort to fix a bad relationship than it takes to keep people happy. I wish the Perl community had realized that 15 years ago. Now, Perl faces the uphill battle of getting people willing to take a second look.
Fortunately, Perl has a massive community behind it. No other language can rival what the Comprehensive Perl Archive Network (CPAN) offers right now (even the ones that tried to copy it outright). Perl has amazing conferences going on around the world with huge turnouts. Yet, it has an invalid reputation that "Perl is dying." Why? Because Perl's Achilles heel is marketing.
Perl is seriously competitive in every category. It's being used all around the world by huge companies. It has an amazing community of support built around it. Perl developers are in huge demand (check out jobs.perl.org). Want a great job after school? Learn Perl!
But you'll never hear it discussed in a board room. And if you try to bring it up in a non-perl shop, you'll probably run into somebody that thinks "You get no extra points for knowing Perl." Really, the issue that people don't understand is that there are people that write scripts in Perl, and then there are people that write CODE in Perl. Both are great, both are important, but they are both very different. Many scripters don't even know, or need to know, there's a whole other level of Perl coding available. And this all comes down to marketing. Perl has failed to market itself.
So what happens now? Companies that are more interested in picking a tool that does the best job will take a look at Perl, and many will choose it. Companies that are primarily interested in hype probably won't. The Perl community isn't going anywhere. Things will progress and then 10 years from now, there will still be people posting about how in their opinion "perl will slowly die." while the other languages of today are dead and gone.
1. At the time, there was not a great 'hello world' installation story for Rakudo Star.
2. There was not a good Perl 6 book published in the last ten years (that does not appear to have changed per a quick Google).
The most readable information I found was the Advent Calendars, but it's fragmented, poorly indexed, and doesn't form a coherent whole. At the time, there wasn't a good StackOverflow story (and the most recent question right now is from October 16, and the average is less than one question per day).
That said, Perl 6 is obviously a long term project and looks like an innovative language that could build mindshare with a bit of luck and the right resources (Ruby and Python didn't become popular overnight). All I'm saying is that it was not a good fit for me at the time.
Books also take time to write, and the people who would write such books have day jobs.
To be fair the rate of questions about Perl 5 back when Stack Overflow started was fairly low too.
That isn't even the best metric, on the site anyway. The best metrics are how many are answered, and how quickly before someone at least adds a comment.
Basically at that point there were less Perl jobs and the language had (has?) bad reputation on being too easy to write hard to maintain code that I thought the language wasn't worth the peer pressure when Python or Ruby were nice languages too with open and welcoming communities behind them.
Perl 6 seems to add to that bad reputation unfortunately, adding extra complexity.
This is just an anecdote, but reading the comments seems like other people had a similar experience.
You are right that Perl 6 is more complex, but you will never see the majority of it until you decide you want to dig deeper.
If you write equivalent idiomatic code in both versions of Perl, the Perl 6 code will likely be less complex, shorter, more declarative, and easier to read.
In the Perl6 community there is no equivalent of "The Python Tutorial" [0] or the "Python X.Y.Z documentation". From Python 1.X onwards, if you wanted to learn Python from scratch, this is where you started. Where is this in Perl6 version that assumes you start from scratch without having to learn the baggage of PerlN? [3]
[0] If I'm wrong loot at this: https://docs.python.org/3/tutorial/index.html and point me to the Perl6 equiv.
[1] https://docs.python.org/3/
[2] where N < 5.X
https://docs.perl6.org/language/rb-nutshell
An overview of the differences between Ruby and Perl6, which doesn't seem to assume Perl5 knowledge, but beyond that the docs are a bit lacking on the tutorial front. (and personally they seem a bit lacking on the polish side of things too. They seem like they could benefit from a some better organization.)
Bulgarian: http://bg.perl6intro.com
Dutch: http://nl.perl6intro.com
French: http://fr.perl6intro.com
German: http://de.perl6intro.com
Japanese: http://ja.perl6intro.com
Portuguese: http://pt.perl6intro.com
Spanish: http://es.perl6intro.com
The start page of https://docs.perl6.org/ is not referring there is a bug indeed. It will be fixed in a day or two.
Also, there aren't hat many libraries in its ecosystem yet, a thing which can be a plus for devs who want to create a name for themselves in the open source world by implementing/translating libraries with a large user base potential.
2. Perl has a bad reputation - lots of people wrote really really obtuse code in Perl and called it clever. Maintenance sometimes feels like stepping into an alt. dimension.
I have to say, it kind of makes me a bit sad, that the image of Perl is so bad while in fact it is a great language. Almost like a genious ugly-looking child in school. I wish more people would actually try it and give it a proper chance. That is also true for other languages as well, like Haskell and Prolog.
Fair enough. I've written a lot of Perl code - some I'm still proud of! :)
By 2000 or so you had Python and PHP coming on really strong. PHP owned the web and I think Python owned everything else.
I had a module that did web authentication with cookies in a number of languages (PHP, Java, Cold Fusion, Perl, Classic ASP) and out of all of them I liked the OO Perl implementation the best.
In that context, Tcl/Tk was magical... you could put together a window with a button and an event handler inside of five lines of code. (And it would look pretty good when you were done.) If you weren't hung up on drag and drop UI building, it was arguably a better way to assemble UI components than VisualBASIC. I spent a year or two doing research UI development in Tcl and loved the tool chain.
On the other hand, Tcl got swamped with a number of forces that conspired against it in the long run. In some ways, Tk was a deficit, as good as it was... I think it tended to pigeonhole the language a bit more than was fair. Also, the changes of ownership (and motivations) between Berkeley/Osterhout, Sun, and Scriptics were muddled... particularly given the rapid ascendancy of Java and JavaScript. (Both of which did a good job of supplanting Tcl in it's non-GUI roles.)
While I don't think the string-oriented nature of the language did it any favors, I also think it illustrates one of the problems with language design. The language had some great capabilities (because it was so heavily based on strings) but I don't think many people ever truly understood the significance enough for it to really become a selling point. Tcl suffered the downside of the weird syntax, but realized none of the benefits it got from having the weird syntax. (A lot like Lisp, as you say.)
It has a lot to do with human psychology. People don't like that argument, but many things happening in IT have a lot more to do with psychology, sociology and marketing rather than any technical ("factual") reasons.
The most technical reason probably is the cost to switch, but that reason doesn't explain many things and people do switch to new things all the time.
I worked at least 3 different places that had massive code bases in Perl 5, that saw no signs of changing the entire time. Furthermore, ecosystems develop around these things, e.g. people (unwisely or not) saving “data” as Perl 5 hashes. There are similar dependencies on the Python 2.x way of doing things.
Also, every project has its own long-term maintenance items to do. LONG before I consider screwing with the very syntax of my entire code base, I will be thinking about things like: avoiding deprecated APIs in other libraries, refactoring problematic designs, etc.
Also, project repositories frequently branch out and every merge is a pain point. There could be many people developing unrelated items in parallel. There is NO convenient place to merge in somebody’s completely new language syntax, just like there is no place for gratuitous reformatting of code or other high-impact, low-benefit scenarios.
And finally, even if a code base isn’t massive, developers have limited time. It is always more attractive to fix some bugs or add dozens of features. It is never attractive to do a complete rewrite of code for unproven gain and definite pain.
I do it for the same reason I learned Perl originally, because I have a mortgage/rent/expenses to pay. You have folks who walk around with LISP books under their arms and learn obscura perfecta like OCaml, but I'm a lot more simple-minded: I learn what I need to learn to get my job done and also new jobs/gigs lined up. I'm not an academic, nor an advocate.
Don't get me wrong, I enjoy reading purist debates, early adopters, experts, people with interest in dynamic language theory, duking it out. At the end of the day, though, if not a single person around me writes in Perl 6, and not a single job listing shows Perl 6, then I'm probably going to wait it out until that does start to happen. And then we'll see.
So, to answer the question by the original poster: I haven't adopted Perl6 because I'm not an early adopter. Maybe if the 24 hour day suddenly became a 28 hour one ...
That said, Perl 6 is becoming such an attractive platform for those who have bothered themselves to go and actually try it; being a Perl 5 hacker myself, I'm taking my time learning it in parallel to a few other languages, and its interesting to see how 2 decades of wandering has brought forth. I suppose that maybe Perl 6 will become like a Lisp (in such that learning provides for a deeper appreciation,) or maybe not (e.g. we actually make https://xkcd.com/224/ happen,) but at the end I know Perl 6 will be there as a tool I can reach for.
If you think about it the only one among new scripting languages that offers something over competition is Elixir, because of the actor model. And it's getting traction.
It takes years for a language to become used by a reasonably large group to make a difference. Given you come from Python you probably know that the first release happened in 1991. Do you know anyone who used that language before 2000? So Perl 6 didn't take off yet because less then a year since the initial release has happened.
With Perl 6 having a learning curve, I thought I might as well use that time to instead learn Python, a language designed with the stated principle that there should be one preferred way to do things.
Unfortunately I started learning Python just as the Python 2 vs Python 3 rift was at a peak. Sigh.
I've since switched to Go, because the way it handles static types is actually pretty awesome (for the most part … there are edge & corner cases), and I find that my software is much more reliable in Go.
For my quick-and-dirty tasks I have Lisp; for my job I have Go: does Perl 6 offer me anything I don't already have?
These days I tend to use Python for new projects, because the young coders where I work are more accustomed to that. Now, if someone where to show up fresh out of school and sure that Perl 6 was the thing, I'd be open to trying that.
(See also Phoenix and Elixir.)
https://github.com/ufobat/Bailador
https://github.com/tokuhirom/p6-Crust
https://github.com/skaji/Frinfon
https://github.com/nunorc/p6-Pekyll
https://github.com/retupmoca/P6-Web-RF
https://github.com/drforr/perl6-App-prancer
https://github.com/sergot/BreakDancer
https://github.com/supernovus/perl6-web-app-ballet
Testing https://github.com/azawawi/perl6-selenium-webdriver
Even desktop style web applications with Electron https://github.com/azawawi/perl6-electron
It's all there just no one engages with any of the development because its not trending on HN every five seconds or has the eye of the tweener set of developers who blog and vlog.
None of these seem to be anything like Rails - they look much more geared towards the Sinatra/Flask micro-framework crowd. People didn't start flocking to Ruby because of Sinatra (not that there's anything wrong with Sinatra).
Baliador is meant to be a take on Dancer from Perl 5 which is somewhere between Sinatra and Rails in complexity. In the Perl 5 world the equivalent of Rails would be Catalyst. But even that isn't really as monolithically well integrated.
The point I'm making is Rails wasn't built in a day and to date Perl 6 has had quite a few people want to kickstart a Rails initiative but they always do it with new code and new ideas cloning a previous paradigm. A better plan is to embed yourself in what's there especially the core language. With grammars you could write a complete DSL as a web framework with all of the power of Perl 6. But it would take someone knowing the core language well to make something that's slick. For behind the scenes there is little reason to reimplement HTTP parsing/serving since there are a couple of modules that are tested against every release of the Rakudo compiler already.
The part about trending every five seconds was gratuitous and overlooks the point that using something with broad community engagement has huge benefits, as people share their issues and solutions, and things get fixed and stay updated with the input of a large community, the power of which exceeds that of any one developer.
I have started doing some things in Go, but the bulk of my code is Perl 5. Having lots of code written in Perl 5 that has worked for over a decade, makes a tough case to suddenly switch to Perl 6. In some sense its like switching from Python 2 to 3. You have to get all the CPAN authors to port all of their modules that your code depends on. I think there too much risk and not enough resources on the corporate side to make the switch.
For example, if you've installed the Perl 5 DBI from CPAN then you can use that in Perl 6 code like this:
use DBI:from<Perl5>;
my $dbh = DBI.connect('dbi:Pg:database=test');
my $products = $dbh.selectall_arrayref(
'select * from products', {Slice => {}}
);
I expect usage and awareness will grow with time, as the geniuses that do the proofs of concept that get the masses' blood flowing burn out on Clojure, Rust, and Haskell and start looking for the next big thing, and write a framework that makes people's heads spin.
Maybe that genius could be you.
It appears that Perl 6 lets you be very clever and can save you some keystrokes. But I don't want to be clever, and am willing to type a few extra keystrokes if it makes things easier for me to understand the next time I look at my code.
And "tens of thousands" doesn't sound like a lot to begin with TBH...
What's your experience?
(mentioned elsewhere, but let's distill it down)
my a = fn { local $v= _[0] %~=->
for 'dict.txt'.IO.words -> $word {
say "$word probably rhymes with Perl"
if $word ~~ /[ea?|u|i] rl $/;
say "$word is a palindrome"
if $word eq $word.flip;
}If I had to guess, ‘foo.IO.words’ probably turns ‘foo’ into an IO object of some sort and then reads words. (Whether it reads the whole file into a string and splits that into words, or if it just reads the next word generator/iterator-style is not especially relevant.) An error throws an exception, like it would in Python or Ruby ‘open('dict.txt')’.
Also I kinda doubt that ‘loop over lines and split them into words’ is more readable than ‘.words’ which presumably does exactly what it says on the tin.
A word is probably defined by either \b or UAX #29. (And since IIRC one of the goals of Perl6 is good support for Unicode, \b hopefully uses the word boundary algorithm in that appendix.)
use warnings;
use autodie;
It's a bit of a trap, I agree and we should fix it. Having all exceptions listed is on the list and will add another few hundred man hours to the nearly 5000 we invested in the docs so far.
If you really want to be verbose you can always write `open('foo.txt', :r).Str.split(/\W/)`. If you learn a new language there will be buildins that are well tested and may be more efficient then your solution (it isn't right now for your example. Rakudo does it exactly your way). It can be worth your time to learn what the standard library provides you with -- in any language that is.
The lack of feedback from actual language users did slow down Perl 6 development and esp. getting all the holes in the docs plugged.
What is that? It certainly isn't Perl (5 or 6).
All it would take is buzz... and millennials. Lots of millennials.
Generally, products that are the most popular aren't always the best. Better to just accept that now, especially before you invest much time in the space :)
I think Perl 6 has not taken off because of three things:
1. Other options.
When Perl 5 really took off in the mid-late 90's, building much of the early Web as well as all sorts of business software (we used it heavily in biotech), there weren't so many other options.
For server-side things it was (or at least seemed) faster, easier, and much much newbie-friendlier to use Perl than the other "obvious" languages, C and Java.
Now there are a lot more languages to choose from, inluding ones that share Perl's original virtues of accessibility and "hackability." While some of these newer languages were gaining ground, Perl 5 was enjoying subtle improvements while seeming more and more dated.
We have large populations of potential Perl hackers who have, for good reasons, chosen to develop their expertise in other languages. They have little interest in learning the "new Perl" because they don't have deep knowledge of nor love for the "old Perl."
That at least some of the hot new languages (Go, Swift) have corporate backing with infinitely deep pockets may also be a factor.
2. Hiring death-spiral.
It's very hard to hire for Perl programming jobs these days. We older Perl hackers often move on (or up) and the young folks look around at where the excitement and the jobs are, and they see them elsewhere.
(Perhaps counterintuitively, there are also a lot of young programmers who prefer Java: maybe not much excitement there, but never any lack of employment.)
The fact that it's hard to assemble, grow or even maintain a Perl team means that it's harder to justify developing systems in Perl from a business perspective. On the one hand you have all the advantages your senior Perl hackers can list for you, and on the other hand you have the cold hard fact that the systems they build will one day be maintained by junior devs who wish they were using something else.
It should be obvious that this is self-reinforcing, and I think there are probably thousands of little Perl shops embedded in big companies where the managers have long been dreaming of a path away from Perl, while the senior Perl hackers reluctantly start to agree with them.
This ends up as Perl 6's problem, not just Perl 5's, because the same people who would usually champion the newest version of the language are busy keeping their Perl 5.x legacy systems alive with shrinking staffs and growing pressure to get off that train.
Also, it will be hard to get your management team to back a big push into Perl 6, because they will only hear "Perl" and remember how painful it was to find Perl people the last time, and the time before that.
3. Approachability.
Perl 6 is really cool and really hackalicious but also not super easy to get started with. Where even back in Perl 4 it felt like it was newbie-friendly, the only thing newbie-friendly on perl6.org is the butterfly logo, of which I am not a fan.
Something like the Go Playground[0] would be nice and might help spread the word. As would a story about what Perl 6 is better at than anything else.
As far as I can tell, cutesy "spokesbugs" aside, Perl 6 is presented as something for the Perl crowd. And as noted above, much of the Perl crowd is too busy for it.
A lot of languages get popular because they show you how easy and fun it is to do thing X in them, and you've always hated doing X in whatever other language. I'm not sure what that X would be for Perl 6, but I have a feeling it's something about the writing itself, which might be a hard sell, but I don't really see it being sold outside the Perl community.
...
Anyway, all that said I would love to see Perl 6 get some traction. I just have no idea where it's going to do that. Maybe if a super high-profile project appears that's all done in Perl 6? Maybe if a small but influential cult of AI hackers falls in love with it? Maybe if it out-Pythons Python as the default entry-level "big data" language?
Because of the reasons listed here, for this old Perl hacker "write stuff in Perl 6" is stuck at the way-way back of the backlog, and well behind at least two other "write stuff in..." stories.
On the other hand Perl 5 is faster for normal usage, and has mature library support, while perl6 has to catchup a lot. Perl 5 is only slower with their not-existing/silly object systems (Moose), there Perl 6 is much better.
Many perl5 devs just don't want to learn a new language yet.
Syntax: It explicitly deviates from perl6 and could have looked much cleaner.
Sounds like you're making shit up just to be difficult. The giant button on perl6.org says "Rakudo is a compiler for Perl 6 code", it leads you to a page of choices, among which is a link to a binaries where you choose your platform.
It's like complaining that you have to use `gcc` when learning the C Programming Language and being flabbergasted to find there are multiple versions of it.
Seriously, this isn't rocket surgery.
We detached this subthread from https://news.ycombinator.com/item?id=12888924 and marked it off-topic.
Any time people notice comments breaking HN's rules that we haven't replied to, they're welcome to email us at hn@ycombinator.com.
Edit: ok, I've now found that comment (which you're right was worse) and banned the offending account.
Then once I'd posted that, I downvoted zoffix myself for being unconstructive and went and tracked him down on IRC (we've known each other for years) and pointed out that even if you're right, accusing somebody of being intentionally obstructive is pretty much never constructive.
"This is the third post-Christmas (production) release of Rakudo Star and implements Perl v6.c. It comes with support for the MoarVM backend..."
"Deconfusion note: if you're just a regular Perl 6 user, you likely use and only ever heard of Rakudo Star, which is a distribution that includes the Rakudo Perl 6 Compiler, some modules, and the docs. This post details a release of that compiler only, which gets released more often than Rakudo Star. So please don't think there's a new release, if Star is all you use."