Is Perl 6 Being Renamed?
blogs.perl.org
blogs.perl.org
1. The name, saddling it with the legacy of Perl. (I say this as someone who really liked working with Perl back in the waning years of the old millennium, and believes that Perl was visionary in pointing the way to the state of modern programming... but also that it had some limitations that have only become more glaring over the years.)
2. The coyness around whether it's "done" or not. Right now today, as someone who has paid attention to Perl 6 and even written some toy code with it, I do not understand its release status at all. That's absurd.
3. The insistence on branding sub-components of it and exposing that branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." This wifty "no, Perl 6 is the standard, the software you're running is Rakudo and Parrot" distinction is totally irrelevant to anyone actually wanting to write code, and weirdly confusing.
4. In a distant, distant last place: any actual functional stuff about the language.
I don't have any real experience with Perl, so could you maybe expand a little? I'm curious about what you think the limitations are.
There's a kind of elegant flexibility to that, but it also makes it really hard to program reliably in the large, to build useful tooling, or even to glance at a function and know what you should pass it.
Beyond that, classic Perl was full of things that make it quick to write small programs (as CGI scripts were at the time) without a lot of boilerplate, but which don't scale up.
(Perl 6 is very different, and has an almost comically flexible/powerful function signature system (https://docs.perl6.org/type/Signature). Whether or not you like Perl 6's stuff, it's nothing at all like Perl 5's.)
Sorry, you are misinformed. That hasn't been true for a long time, see http://p3rl.org/Kavorka::Manual::Signatures
Other languages would kill for this kind of beyond-complete maximum overkill feature set.
> This page gives a good overview of the situation: https://perl101.org/subroutines.html
No, it doesn't. That page is not wrong, but incomplete and teaches the wrong stuff, wouldn't recommend. Instead see http://perl-tutorial.org/ for recommended tutorials.
> WARNING: Subroutine signatures are experimental. The feature may be modified or removed in future versions of Perl.
Which is to say: a lot of the reason they're still experimental is because Perl's commitment to backward compatibility. Other languages might have said "oh well," but Perl 5 said "oh, an unintended consequence that might break real uses in the wild; we should wait another year."
YOU are the one misinforming, it would seem. Granted, I don't work with perl (5, never tried 6) for about 15 years, but most criticism of it seems to align with my experiences back then.
[0] http://mvp.kablamo.org/basics/functions/
Edit: The second [1] also recomends the @_ method, and the third [2] the shift method. Did you even read your own links?
[1] https://perlmaven.com/subroutines-and-functions-in-perl [2] https://learnxinyminutes.com/docs/perl/ (search for subroutines)
On Perl6 those are officially supported, so I imagine they work.
That is also true for the overly simple object model of Perl 5, it is more like an OOP construction kit, which enables things like Moose which has for almost 15 years provided Perl 5 with a very flexible object model.
It would be very interesting to know if anybody knows of similar systems for other languages?
Large OO codebases can be downright nasty to navigate and while I have never had the opportunity to use something like Moose for large scale projects I imagine that's where it would shine.
Consider the difference between a minified JS script or one produced with emscripten and the code pre-minification. One is unintelligible guaranteed, the other … maybe haha.
Unfortunately, what tended to happen is people would write one liners, and slowly expand the one liners into more complex one liners, and then integrate them into larger scripts without refactoring. Regex can triple that problem (thankfully Perl 6 allows you to write some of the most intelligible — seriously! — regex out there).
That's like the folks who say "the problem with C (buffer overflow, UB, etc.) isn't C, it's the people who write C". Which leads to at some point contemplative folks deciding either "this is happening so often, maybe it is the language" or "the majority of people writing this language are incompetent". While I've heard plenty of people in the C community espouse the latter view, having written C since K&R days, I think most people acknowledge it's a problematic language. But I don't have empirical evidence of a ratio.
I wrote a ton of Perl <=5 back in the day. I'm pretty sure I know why I thought it was a good idea at the time. I know where I fall on the above. I know why I, and virtually everyone I know professionally, don't solve problems in Perl any more. But hey...maybe I'm just incompetent.
‘User error’ is rarely a sufficient explanation for why something negative happens, particular when those users are professionals using a professional product. At some point one needs look at whether there is something in the product that causes those errors to happen or that doesn’t do enough to prevent them.
There's nothing inherent about Perl that causes people to use $z instead of $somethingDescriptive. And regexes have for quite some time allowed for insignificant whitespace to comment things in detail.
If you comment your regexes and use decent variable names, you solve 98% of the readability problems of Perl, and both of those could be enforced with a linter. But as I said, a lot of the problems come from one liners being slowly expanded. Using single letter var names for anything is fine in a one liner, but not good for long term program legibility or maintance in any language.
These days, people that aren't novices tend program much more clearly in my experience, and there's style guidelines and code linters to take up the slack. It's not like other languages never have to deal with people writing odd or unintelligible code either, there's a reason why style standards are a big thing in many places. Here's an example of a module I use that I just looked up. It's fairly terse in parts (but it's a module, so I hold it to a different standard than my own code), but I would expect anyone familiar with perl would have zero trouble determining what's going on in here, and a lot of code bases will be a little more verbose or use more white space to error on the side of caution and help people process what they are seeing easier.[1]
1: https://metacpan.org/release/Path-Tiny/source/lib/Path/Tiny....
However all that flexibility means that it's not possible to run static analysis with full confidence. Yes, tools exist - but it's been proven impossible for them to catch all cases, and this uncertainty carries real risks for critical business processes.
When you have a code base encompassing a set of core modules, with hundreds of auxiliary programs using them across the business, then any attempt to update perl or its modules grinds to a halt. It's impossible to even enumerate which programs will be impacted by the change with confidence, let alone the effects of such a change.
For details see "Perl Cannot Be Parsed: A Formal Proof" (https://www.perlmonks.org/?node_id=663393). You can mitigate the impact with coding style guides and code reviews but once the damage is done it's very difficult to untangle an existing code base that loads modules at run-time and makes full use of Perl's flexible nature in other ways.
Bad example: Java actually has many VMs available for it: Oracle, OpenJDK, Zing, and IBM come to mind. (EDIT: And "Dalvik", for all the Android fans). I'm unsure if Java has multiple compilers, but its quite possible.
Python has CPython 2.0, CPython 3.0, and Jython at least. Probably a few others.
When Perl 5 was huge, there were multiple VMs and interpreters: IronPerl comes to mind as a Windows implementation back in the day that had different quirks than the canonical Perl interpreter.
It does have multiple compilers for java, at least javac and ecj (eclipse compiler for java) http://blog.deepakazad.com/2010/05/ecj-eclipse-java-compiler...
And if you consider groovy and scala and kotlin it has many more compilers.
JustInTime, HotSpot, Swing, Beans, etc.
...and IronPython, Cython, PyPy, PythonNet, MicroPython, probably plenty more I'm forgetting.
Python 2.x language has several implementations CPython (the reference implementation), Pypy, Jython, IronPython.
Python 3.x language also has several implementations CPython, Pypy
Cython understands Python but it is not Python (I don't know whether it is a strict superset).
MicroPython implements some subset of Python 3.4 (mostly)
A lot of people care. It costs $3500 per server to run Zing Java. Every user of Zing cares enough to pay $3500. Everyone who has written an Android app cares about the distinction too. Dalvik has different quirks than regular Java. (EDIT: Oh boy, that shows how out of date I am. Apparently Android is now using Android Runtime instead of Dalvik....)
> If they need to find another implementation, it's possible, but there's no question about what the default implementation is.
The implementation can, and does, change without the language changing. That's the unfortunate truth about real world deployments. As such, you need a unique name for the interpreter.
> A lot of people care.
Both of these claims are true, but yours is missing the point.
You grow a userbase by appealing to people who don't use or understand your product. People who are already invested to the point of spending $3500 for a custom VM aren't the ones you're trying to clarify things for by using consistent branding.
That's the problem.
That's not really a great comparison. There is one single organization that both defines what python is and implements a compiler/interpreter for it, and that is all you would ever need to know to use it. No ambiguity.
And it always had a single official and complete reference implementation in the form of the Sun JVM and later the OpenJDK. kbensons description makes it look as if Perl 6 had/has neither.
> And "Dalvik", for all the Android fans
Dalvik was intentionally incompatible in many ways and wont run a spec conform jar no matter how hard you try. Might as well call CPython a Perl implementation.
> Python has CPython 2.0, CPython 3.0
With CPython X being the official reference implementation for the corresponding language version and all other implementations being incompatible to varying degrees.
True though even in the mid to late 90s there were other JVMs available from companies such as Microsoft and IBM. In fact for a period, Sun’s JVM was one of the worst implementations despite being the reference implementation.
It had and has a spec. It's been evolving over time though. It was ambitious enough that no one implementation ever fully implemented it until recently, if ever (I stopped following the project actively a few years back. I'm not sure if any current implementation is fully compliant). That's not a surprise, it's an amazingly complex set of features that are describes, and there's many specs that are never fully implemented, and it's not uncommon to have an aggressive specification run up against reality when people try to implement it. For example, I've heard that the IMAP spec has never been fully implemented, or at least the later ones versions of it.
So, they have a spec, and have had one for a very long time. They have implementations that do the vast majority of the stuff you'll want from that spec, and they've been in that state for a few years.
For the most part, language specs are either bundled fairly tightly with a reference implementation, or have a completely different name. (e.g. ECMAscript, SQL)
It has some genuinely ambitious features, some things that (as someone who barely dabbles in new languages) that I haven't seen before, or combinations I hadn't seen.
Something novel instead of the umpteenth iteration of "x with a better type system" or "x without that pesky type system".
(To be clear: not because people aren't writing Perl, but because we tend to reflexively reject any technology that people are passionate about because "risk". But the risk of writing trash code that nobody ever could be passionate about is less visible. Also: I'm not saying there's an easy solution to this problem.)
The reason the implementation is named (Rakudo), is because there's a spec, and originally there were a few people making implementations. There was good effort from individuals on C and C# versions that were more monolithic, and Rakudo was where most the community work went since it was designed in a way to be more cross platform (it's mostly implemented in the minimal NQP languages, which is "not-quite perl". It's a much easier thing to port to a VM, and then you get like 90% of the language features already designed and working).
The reason the VM is noted is because it changed a couple of times. Bringing the VM name into it lets people know that if it's different, maybe it will have fixed their main performance complaints. To my knowledge, they haven't used parrot in a decade or so, and there's actually some bad blood between the VM and Perl 6/Rakudo (which had different teams, another reason to brand with both.
So, Perl 6 is the standard. There have been multiple implementations to varying degrees of completeness, including but not limited to Rakudo, Pugs, and Niecza. Those implementations have generally targeted one or more VM targets, including Parrot, MoarVM, Java, .Net and custom VMs.
It may or may not have hurt adoption seeing this terminology, but it was there for a reason, because it denoted very large important aspects of what was going on behind the scenes, and in some cases doing otherwise could have worked against some relationships that were going on between projects.
To spell it out, Parrot the project started around the same time as Perl 6 the project. Initially, a lot of Parrot's purpose in reality was to be a VM for Perl 6, but Parrot also had a goal of being a good general VM for dynamic languages. From that perspective, I think they were often mentioned together because neither wanted to be overshadowed by the other to the point of obscurity, and they wanted to draw on the general audience each might bring (and there were quite a few people doing stuff in Parrot with nothing to do with Perl 6 eventually).
Did it cause problems? Probably, even if you ignore the eventual blowout they had. That doesn't mean it was it was entirely a stupid technical reason by technical people ignoring marketing concerns, as part of the reason I think it was done was purely for marketing. Initially, it might have even helped (a VM for dynamic languages was a big idea back then, I know I saw a lot of people excited about it).
It was a CPS compiler, but after they drove the first creators away, a bunch of people who had no idea about compilers nor CPS started destroying it. First the destroyed the jit. The technical justification was bullshit. Then they destroyed the run loops, and finally the CPS (2007 YAPC workshop). This caused every function call to allocate 2 objects, continuation contexts were not reused anymore, but created on the fly for every call. After this desaster they gave up (their new idea was to create a 2nd LLVM, called something with m), and I came back to cleanup the mess. I readded the compiler optimizations, added proper lock-less threading (their current VM is lockful) and started fixing the CPS, the run loops, the GC and the Jit. But before that they decided to kill it off, and rewrote everything by themselves. But not as committee anymore and without the previous leadership, which was a very good decision. It's still a very naive architecture still, that's why it's even slower than python, the slowest scripting language on earth.
Realizing that this is futile, I started improving perl5 towards perl6 instead. Just without breaking backcompat. perl11 (5+6)
Reini, it seems like you think everyone who disagrees with you is stupid. This isn't an explanation for anything.
We were boxed in for two really good not-primarily-technical reasons:
* we had users we didn't want to abandon or cause churn * we had architectural decisions we had to improve
Now I know I'm not as smart or as experienced or as knowledgeable as you are, but that doesn't mean I'm a drooling buffoon, and it certainly doesn't mean I don't have good reasons. Sometimes it means I make mistakes. Sometimes they're not even mistakes; sometimes they're just differences of opinion.
It is the simpliest explanation. In fact it was stupid and arrogant leadership mostly.
There was no disagreement, as we didn't say a beep then. They made those stupid decisions all by themselves, and didn't listen to any advice. The better people just silently left, shaking their heads.
It's the laziest explanation.
Did you ever ask yourself why, for example, all of the calling convention code paths were consolidated into a single code path? It wasn't to make a single, inefficient code path as you claim.
It was to provide a gradual transition for clients to a better designed calling convention system which could then be optimized for actual client uses.
The goal was never to create the fastest possible VM at every single point in time. That's where I think you never understood the goal of the project, and that's where I think you've never understood the goal of p5p.
The goal was to make something that works, continues to work, and can be improved while continuing to work. That's why you're no longer welcome in p5p -- because your goals and your actions are incompatible with that.
I wish you understood this. You're very smart and very talented and you have a lot to offer, if you can get out of your own way and accept that people who don't share your exact goals in the exact same way aren't irredeemably stupid.
How odd then that ~90% of the discussions about ditching Parrot were primarily complaining about the deprecation policy and first-class Rakudo support, not speed.
I suppose you would know better though, being objectively smarter than everyone else who ever made a decision about the project. How unfortunate that we can't take your word for it; we can only read all of the public discussion about it.
This was, initially, for two reasons:
* allow Perl 5 code to run in process with Perl 6 code (without linking in libperl) * provide a unified VM on which Perl 5.12 could become Perl 6
I'll defer to your memories if they contradict that though, I know you were involved to varying degrees for the first decade or so, and all I did was lurk.
That sounds like a really solid foundation to build a business on...
I think if people are willing to look with an unbiased eye, there are a lot of software marketing lessons to be learned from the rise and fall of Perl. It got a bunch of stuff right back in the day.
Of course part of that is technical, but part of 'marketing' is understanding what your users want and delivering it to them.
This article I wrote about Tcl a while back is what I'm talking about: https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...
Yeah, but you keep pointing to things that are exactly like many successful projects as wrong, like having a different name for the language vs. an implementation vs. backends used by the implementation.
I will suggest that the two things they actuallt got wrong were:
(1) Calling it “perl”, and
(2) Taking forever.
And, really, those two in combination: even being as distinct as it is, had it stabilized in a reasonable period of time, and had once it stabilized a reasonable transition path been provided, it might have been another Python 2 to Python 3 problem, but not a complete disaster. Conversely, ha for been a new experimental language and not “Perl 6”, taking forever to stabilize would have been more tolerable.
Perl 6.c, Perl 6.d -> SQL-2011, SQL-2016
Rakudo Star -> MySQL
Rakudo compiler backends (for MoarVM, JVM, JS) -> MySQL storage engines (InnoDB, MyISAM, ...)
Having different names for languages, language spec versions, language implementations, and backends doesn't seem unknown in successful projects.
Other than the problem of “Perl” in the name, all of this is fairly boringly normal.
Well, more accurately, it's the language name (like SQL).
Standards include Perl 6.c, and Perl 6.d (Like SQL-2011 and SQL-2016)
Unfortunately, that direction stems from their motivation which is easily tainted by group ego. Maybe the developers feel like they're not getting the attention they deserve, maybe they have a big idea they want to solve and their tool is tangentially related. Or maybe they know exactly what to do, and the "other" people in the system do not.
Whatever the rationalization is, it's enough to transmute their original purpose into a larger mission that everyone in their little silo agrees with, and that gradually diverges them from the rest of the system.
"We're necessary and therefore we're important... more important than the system we were built for!"
Eventually, a new name springs forth to signal their existence or even assert their dominance over the system to which they belong.
The kind of thinking that plagued ParrotVM:
I'm surprised by this comment because this is how pretty much every language works. C++ has specs and different compilers with different names and has done for decades. As does C, Python, Perl 5, Javascript, PHP, Lua, LISP, LOGO, BASIC, Pascal, SQL and your own example of Java has different compilers/interpreters/VMs.
Often even in languages where the "spec" is defined by a reference implementation, you still find people building their own compilers or VMs for different platforms or use cases.
It's really quite common to separate the language name (and specification version) from the compiler and runtime branding. In fact that used to be the norm back when target platforms differed wildly.
There's no coyness; the language spec and implementations are both actively developed, and it's a spec-first design, so Rakudo is sometimes incomplete with regard to the most-recent spec, but Rakudo is and for some time been a “production-ready, stable” implementation of Perl 6.
The language has been consistently described as stable since the “Christmas” release, Perl 6.c, on 25 December 2015, though it took a bit longer before Rakudo had a production-ready 6.c implementation; the current (and currently supported in Rakudo) spec is 6.d, released last year.
> Yes, it has a VM.
Several, in fact. (More if you count defunct historical ones like Parrot.)
> But why do people talk about ParrotVM and Rakudo as if they're different things?
Because they are: ParrotVM is a (AFAIK) essentially dead multilanguage VM that Rakudo used to support; Rakudo currently has a MoarVM backend, and a JVM backend, and IIRC there is a non-production-ready JS backend that is available separately.
Developer ergonomics matter! Yes, when you run 'python' you get cpython, and Java is probably hotspot vm or openjdk or something (but Java is not a good example of developer ergonomics).
Rust is one of the best examples here -- adoption is being driven by the ease-of-use of the entire toolchain, including the package manager and things as small as human readable compiler errors.
But all the things the parent comment listed, particularly branding, are in my mind part of developer ergonomics. And there is room for improvement. They wouldn't be talking about renaming the language if this wasn't the case.
Ignoring the Perl angle, it's a language with a small ecosystem that doesn't seem to provide any groundbreaking advantage compared to existing languages, so no reason to adopt it.
In general, to become popular a new language needs to provide one of those:
1. A new groundbreaking and useful paradigm that cannot be added to existing popular language ecosystems without a total compatibility break (e.g. Rust)
2. Compatibility with an existing ecosystem and significant improvements (e.g. Kotlin)
3. Being the best among languages required by a platform or program (e.g. Swift, also JavaScript when introduced)
4. Have one of the best ecosystems for a specific niche (e.g. Ruby when Rails got popular)
I don't think it'd be instantly super-popular if it were a standalone, non-Perl-affiliated language, but I think it'd at least be talked about like Elixir or F# or Elm.
I always felt Perl <6 was the papa of Ruby: optimizing for (a) programmer's happiness. Perl showed the way in so many ways, combined with the object model of SmallTalk we got Ruby.
Maybe P6 also has a some new ideas in that find their use in future languages. But we will only know after P6 gets used and loved and exposed to real world scenarios, what those "most valuable/copyable innovations" are...
Is that really a thing that couldn’t just be added to PCRE and be available in any language with bindings?
F# has the advantage of easy interoperability with the vast .NET ecosystem.
Here's your perennial reminder that the word "modern" is a thought smell.
> it's a language with a small ecosystem that doesn't seem to provide any groundbreaking advantage compared to existing languages
I'd almost prefer this conception went uncorrected, because Perl6 is not just Ruby or Python in different clothes, and it's not just Perl5 with nicer aesthetics, and I don't mind enjoying niches or competitive advantages.
Sometimes it's a thought smell, but sometimes it's shorthand for "has learned the lessons of recent history", which is indeed valuable.
By analogy, "modern" might indeed sometimes mean "has learned the lessons of recent history."
One can even sometimes test this by asking people what they mean by "modern."
My experience is that they usually don't know, or have a conception uncomfortably close to "it was released more recently" or "it's more like what everybody does right now," which are both certainly worth observing... but stopping there is where the thinking becomes distinctly less so.
Not familiar with the term and can't find it elsewhere.
"this smells off" -> nonspecific indication that something might be wrong "code smell" -> nonspecific indication that something might be wrong with software code "thought smell" -> nonspecific indication that something might be wrong with a way of thinking
I'm seeing a pattern of things that are named tools which are not the exact name of the language they compile or run.
When I ask "What's an implementation of Perl6" The answer is "Nothing implements perl 6, isn't that wonderful!" It used to take forever diving around to find something that could run some subset of perl 6, usually with the disclaimer of "This isn't really perl 6, but rather a language that seems like perl 6" And you'd get the same thing from the mailing lists/etc.
Rakudo (compiler) and Rakudo Star (full distribution). Both of which have been production-ready since shortly after the Perl 6.c spec release in December 2015.
Your rant would be understandable back before there was a stable spec, especially long before when the in-process language description and the various implementations were sometimes far apart. But it's been years since it had even a remote resemblance to reality.
The legacy of confusion and weirdness around the Perl 6 project is a legit problem, even/especially if it's no longer true and now Perl 6 is like a normal language.
Niecza is an implementation of Perl6 which targets the CLR. Last I checked it lagged rakudo a bit but was still being updated and maintained.
There are other, independent implementations of Perl6. There's STD.pm which implements Perl6 in Perl6 and uses viv to transliterate portions of itself into Perl5.
Pugs is last I checked dormant, but it was an independent implementation of Perl6 in Haskell.
So if someone asks for an implementation of Perl6, they probably want rakudo. Just like if someone asks about an implentation of Ruby they probably want CRuby / MRI unless they for some reason don't. Ruby, however, doesn't really have a language spec so other Ruby implementations like JRuby chase MRI compatibility. This was a problem with Perl5 which was defined by its primary implementation. Python has the Python Language Reference for alternate implementations like IronPython and Pypy to develop against, much like the R5RS and R6RS Scheme documents. This is why Perl6 the language is defined by the spec - so multiple implementations can compatibly exist.
Pedantically, and this also helps serve your point, Parrot isn't used by any modern Perl 6 implementation, it's effectively dead (if not totally). MoarVM is the less ambitious (not trying to support every dynamic language like Parrot was) and more mature VM that is in use now.
And the requisite, ParrotVM is just pining for the fjords joke goes here. It has ceased to be, gone to meet it's maker, it is an Ex-Parrot.
EDIT: For reference, Parrot VM really was named because of that sketch. It started as an April Fools joke and kinda stuck. https://web.archive.org/web/20100718195724/http://www.perl.c...
# copy stdin to stdout, except for lines starting with #
while left_angle_right_angle:
if dollar_underscore[0] =eq= "#":
continue_next;
}
print dollar_underscore;
}
Did We Change the Definition of 'Literally'?
Literally every modern dictionary includes this definition
https://www.merriam-webster.com/words-at-play/misuse-of-lite...
OTOH, "Perl" has existed forever... it would be kind of a shame to lose the name.
There was talk about Perl 6 being ready soon. It sounded really cool like many people I was quite excited about it.
Sadly the screwing around and refusing to give a real release date really messed things up ("It will be ready by Christmas, we just aren't saying which year"). I moved on to Python - which has been a good move career wise, but its a shame as I enjoyed using Perl and Perl 6 does have a lot of interesting ideas.
Like you say, I have no idea about the release status either.
Perl5 had a period of slow releases in the 2000s, this changed in 2010 with the release of version 5.12. Since then, Perl 5 has been on a yearly release cycle. The current release is version 5.30.0. When it became clear Perl6 wasn't coming any time soon, some people left Perl. Others knuckled down and wrote some great code that made Perl5 into a much better language. With many core feature additions and deprecations, new CPAN modules, and tooling to support consistent work by teams, the Perl5 language is more expressive and better than ever.
Perl6 took forever, had major internal conflicts, but managed to survive and ship a specification in December 2015, version 6.c (6.a was an alpha version, and 6.b a beta). The Rakudo Perl6 compiler gets monthly releases, but most people install the Rakudo Star distribution, which bundles some extra modules and just makes life a bit easier. Rakudo Star began shipping "A usable Perl 6 compiler" in 2010. Regular releases tracked changes in the compiler.
The Perl6.c spec was announced in December 2015, and the first Rakudo to implement it was released at the same time. Rakudo Star, lagged a bit and released in January 2016.
Here's the Perl6 release announcement: https://perl6advent.wordpress.com/2015/12/25/christmas-is-he...
The Perl 6.d spec was released in November 2018, and the Rakudo 2018.11 version defaults to supporting it.
Here's a link the Perl6 FAQ with more info on the Perl6 versioning and releases. https://docs.perl6.org/language/faq
If you liked Perl5 then, come back and give modern perl5 a try.
Perl6 is an amazingly expressive and fun language to write with.
Perl 6 is quite nice as a language but the implementation is slow and it has too litlle lib support. Also not great for scripting because of the VM penalty.
They're both extremely knowledgeable, but neither of them can work with other people, so their forks seem motivated by the desire to do what they want without question, rather than any purely technical concerns.
I am not a fan of Perl, but this feels tragic to me. Perl was so radically different. I remember being on Perlmonks way back in the day, and someone would post a question about why their code didn't work, and there would be dozens of people who could instantly, intuitively post a corrected version of the code, but then the poster would say "oh, shit, what was my code doing? and why does the correct code do something different?" and you'd be lucky if there was a single person (cough chromatic) who could explain it. And none of the Perl fans cared, because Perl made them extremely powerful and productive, and they could (almost always) confidently produce a line of Perl code that did what they wanted. The analogy to natural language carried further into practice than Larry Wall could have dreamed. Nobody worries that the difficulty of resolving linguistic conundrums impairs their ability to have a conversation, and the Perl ninjas in my company enjoyed a very close and chatty relationship with the systems they worked on.
I'm the opposite kind of person, who got sick to his stomach looking at a line of code like !#$foo->%_[] (note: not real Perl) not knowing why it worked, even if I wrote it and knew that it would work. Even now, I have a nagging fear that if I executed "!#$foo->%_[] (note: not real Perl)" it would print "Yes it is! Ha ha. Love, Larry" to the console. I can't stand that, so Perl was never for me, but I still hope that against all odds this long, drawn-out apparent deathbed scene turns out to be the middle of a successful convalescence.
But I'm great with regular expressions. It seems like everyone around me swears regexes are an impossible black magic, and so they think that I'm some epic level wizard. And I have Perl to thank for that.
"In this paper, we aim to answer a long-standing open problem in the programming languages community: is it possible to smear paint on the wall without creating valid Perl?"
It's the kind of joke that doesn't teach you anything, rather than the kind that does.
lerzfijglpFiji-j
-*?
also, the writing is quite entertaining.
Except in certain cases because back-compat is complicated.
the Perl program “ Illegal division by zero at/tmp/quine.pl line 1. ”, when saved in theappropriate location, outputs “ Illegaldivision by zero at /tmp/quine.plline 1.”Mind you at one point I was also the #2 poster on perlmonks...
...you have to transpose a couple of characters for that:
cat nocarrier.pl
!$#foo->_%[]
perl -c nocarrier.pl
nocarrier.pl syntax OK
===SORRY!=== Error while compiling -e
Unsupported use of $#foo variable; in Perl 6 please use @foo.end
at -e:1
------> !$#foo⏏->_%[]
Over the years I've seen this mantra repeated a million times but I've yet to have anyone actually explain what it means beyond a piece of marketing fluff. What actually is this analogy in concrete terms?
The result was a language that has a lot of power and flexibility. People who like Perl tend to love it, because it fits like a tailor-made suit instead of all those off-the-rack languages. People who dislike Perl tend to hate it, because all that power and flexibility can be easily abused (even when you're trying not to — there's a reason so many people buy off the rack instead of making DIY suits).
•https://bigthink.com/videos/why-perl-is-like-a-human-languag...
A language that's "tailor-made" for the individual is fantastic when you only have to deal with your own code. You get to write stuff that makes sense to you. It doesn't matter if it's unconventional or doesn't make sense to anyone else -- it fits the way that your brain works.
But when cooperating on larger projects with lots of other people involved, this backfires remarkably. You now need to understand the way that half a dozen or more other brains work.
As software development has gradually shifted away from the published efforts of lone hackers and towards the collaborative efforts of teams of specialized people, Perl's "TMTOWTDI" approach has made it a far more expensive language to develop software in than all of the alternatives.
I feel like most scripting languages are pretty similar in terms of productivity based on my own experiences anyway...
As far as I know, nobody's done a comprehensive cost analysis of similar software built using different languages, methodologies, or architectures. Certainly nothing recent. I've harped on this before quite loudly and I think it's one of the reasons our industry can't be called "engineering".
People's individual experiences just don't make for good enough data because there are too many confounding variables.
I think this is spot on.
There's a scalar vs. list context when calling a subroutine. Some Perl builtins return different things in the different contexts. Your subroutines can as well, for example by using wantarray() in your code. For example, in list context returning an array or assigning an array to something copies the array. In scalar context an array's value is its number of elements. The readline operator <$filehandle> reads a line from the file with file $filehandle in either context. However, in scalar context it reads the "next line" (depending on line ending settings and seeks and such). In list context it reads and returns the list of lines in the file. This has the great benefit that a while loop with <> reads one line at a time into memory and sets a variable (either one you specify or by default $_) to the line just read. A foreach loop with <> reads all the lines into memory then operates on them, which is sometimes preferable.
There are operators for numbers and for strings and a single scalar variable can be accessed in either context. This allows for easy coercion from the string "42" to the numeric value 42 or back. It's possible with some trickery to set these two values independently, but don't do that.
There are the pronouns $_ and _ which recall the most recent subject in some situations. There's a magic array @_ which is the list of arguments passed to a subroutine or method. There are match variables for regular expressions, which refer back to the matches. There are the variables $a and $b which are reserved "magic" variables used to support user-defined comparator blocks for the built-in sort(). There are variables for which line of an input file you just read.
People looking at it for the first time often look at the variables available, the built-in functions and procedures available, the fact that regularish expressions have their own mini language that nests naked inside the main syntax and a few oddities like sigils and sometimes determine there's a huge breadth-first search to learn all of this. People almost immediately go to, "even if I don't need to use all of this, I need to understand all of it to maintain other people's code". If you follow a really unprincipled developer who's showing off, that may be the case.
I've been programming in Perl5 for some part of my job duties since 1998. In high school before that, I was studying two foreign human languages and was taught the basics of four or five programming languages. At university I started a third foreign language and another programming language. All this time I was also learning a bit of programming language here and there on hobby projects. I've learned several more programming languages since, some of which I use alongside Perl pretty much daily.
From my experience the core language of Perl5 contains a subset of the language which could be thought of as its virtual core language. Much of what's built in is used more like specialty modules that are only used when necessary. I think this has a lot to do with Perl up through the Perl 4 days not having great module support. There are other huge languages in the wild. Ada, PL/I, and any shell on a system with a big bin or sbin directory come to mind. It really is, in my experience, a depth-first language with lots of side paths to explore one at a time. I don't have hard data on people learning the language, but I've met many people who share this sort of thoughts about it.
One solid example of a core feature that's really complete but rarely used is formats. You can have output sent through these sieves that are a template language built into core Perl5. They are really handy if you're using Perl to match a format in RPG or COBOL or if you're just generating the sort of reports you might generate from those. You don't ever need to worry about them if you're not working on code that does that. I've written Perl formats two or three times and had to deal with them in maintenance maybe half a dozen times including the ones I wrote. There's a separate manual document on them. They are not part of the core in Perl6/Raku but someone's older program would break if they were taken out of Perl5. https://perldoc.perl.org/perlform.html
There's a separate document for pack() and unpack() which are very handy if you're hand-translating character sets or working with a binary protocol or something. Otherwise you'll not use those, but they are in that huge core language.
The data structures and references in Perl5 look different than in many other languages. There are docs on syntax, and others on referces, and then another specifically on data structures. Perl6 uses similar dot notation to other languages, which is one of the syntactical incompatibilities with Perl5.
One place where the "all those choices" is a real drawback is the number of ways to make and use objects in Perl5. The initial way Larry gave us is workable and performant but a bit ugly and utilitarian. Many CPAN modules brought their own module systems. Then, after the Perl6 team figured out what they wanted to do for objects, Perl5 got a backport called Moose. Moose is nice to use but is a behemoth and uses memory like one. Someone came along and gave us a lighter version named Moo, and then someone gave us Mouse and another group gave us Mo. In the industry and community, Moo is considered the best practice now. It even upgrades just specific objects to full Moose objects if the lightweight version won't do for some reason. So if you can write and maintain Moo code and the original Perl5 blessed data structure objects you're good for most object-oriented Perl code, but far from all. There's also Object::InsideOut, Class::Accessor, and I forget how many others.
One place where Perl6/Raku/Camelia really fixes things is having a really nice default object system. Another place it fixes things is there's really no need to graft another object system on in place of it, because it include a full and fully accessible MOP.
You even saw "folk theories" about how the language worked, which were valid and useful to the extent that they helped people produce and understand a certain subset of valid Perl. These folk theories would trip up people like me who expected them to be mathematical truths that could be combined with each other in novel ways, while more Perl-attuned people knew that this kind of analysis was as hazardous as assuming that fingers fing, or that "black big dog" is as valid as "big black dog." There are always new rules to learn and more precise versions of rules you thought you already knew, and ideally you would end up following the rules without knowing them [1]. Ideally, the better you got at reading and writing Perl, the less you thought about those things, just like we study rules of grammar as children while we're learning to stop writing incomprehensible crap like "dog run big I saw," and the better we get at writing the more we realize that the "rules" of grammar are mostly wrong and beside the point anyway. You didn't expect the sysadmin producing reams of working Perl in the next cube to be able to explain what a reference was just like you didn't expect a master advertising copy writer to be able to diagram a sentence for you.
In my attempt to learn Perl the way you would learn math, or the way you would learn a traditional programming language that was designed to be used by logically combining completely understood parts, I discovered that there were some people who understood Perl and could confidently recombine pieces into new idioms and know what they would do without trying them, but in the Perl community it was considered okay that these extraordinary people were a small minority, just like we don't worry that there isn't a professor of linguistics standing by when you order a meal in a restaurant.
Personally, I found it to be a fascinating abomination. An abomination because it flies in the face of how I think good reliable software should be written, and fascinating because it seemed to work surprisingly well.
[1] https://twitter.com/MattAndersonNYT/status/77200275722200268...
Tangentially: it is, though; the two phrases are both valid, but have different meaning. “big dog” is an idiomatic phrase that, when used as such, functions as a single noun, which can be modified by “black” as a preceding adjective (if “black” is in the usual place between “big” and “dog”, the words have their individual meaning not that of the idiomatic phrase.)
Not a super common one though, and even if you were using the idiom you wouldn't write "black big dog" because it still sounds incorrect and makes it less clear you're using the idiom.
Sadly, during my career I've actually never met a kindred perl loving soul.
Does it also have the unparseability problem[0] of Perl 5? That's a deal breaker for a lot of tooling.
No language tooling is perfect. We shouldn't expect that from Perl tooling either.
Java and C# tools are pretty close. But yeah, it's generally hard for dynamic languages.
Perl is, in this regard, very similar to natural language, which should be entirely unsurprising given that Larry Wall comes from a linguistics background and explicitly designed Perl to borrow various characteristics from natural languages.
From what I understand, though, Perl6's grammar has significantly fewer of these sorts of parsing complexities ("fixing" them was one of the design goals, IIRC).
Rakudo (the current major Perl 6 compiler) also uses grammars to actually parse Perl 6 programs, but from the bootstrap language NQP https://github.com/rakudo/rakudo/blob/master/src/Perl6/Gramm...
Perl6 was promised. Then it never happened. It's now an almost quarter century later. The world has moved on. Taking that long for a single version update in a language is not reasonable. I loved Perl. I still love Perl5. But I've moved on and have 100% blocked Perl6 from my psyche and list of expectations. No one I know uses it. I am not excited by it. I dont need it. And I don't care to hear these discussions about minutia related to it. It's a debacle and a case study in the failure of what was a beautifully ugly practical performant language.
"Oh, it took too long to update Perl and now Perl is dead" is true.
"Raku is an interesting new language with some neat features, and excels at this particular type of problem" can also be true. But nobody can hear this message while they keep thinking about Perl.
"Raku is an interesting new language with some neat features..." will be met with "Oh, you mean Perl 6? lol."
If Perl is dead, renaming the last version isn't going to change anything.
Perl6, on the other hand, is effectively another language altogether, and I hope they rename it completely to stop the confusion.
For example, if you find a page suggesting you run 'perl -MCPAN -e shell', and you try using that, you'll probably have a very bad time. Watch out for it trying to upgrade perl itself! There are newer, saner and nicer ways to access CPAN and install packages.
There's also possible conflicts between CPAN and your distribution's own packaged perl modules, but that's a common problem with any software you install yourself rather than through the distro's packaging scheme.
It doesn't mean "no developers or support" because that's at least as true of newly invented languages that HN loves to get excited about. CPAN is a thing and has been for decades.
It doesn't mean "doesn't work, not delivered yet" because there it is.
It doesn't mean "no exciting features" because that's not true either.
It seems to be more of a condemnation than a description. I suspect it's really just a synonym for "passé, uncool, brings back memories of the 1990s I was trying to forget".
It's the same kind of "dead" as Latin: lots of folks actively use it, but meeting someone that does is pretty dang unusual unless you work for the Catholic church, in which case "everyone still uses it, what's dead about it?"
Both have huge problems, perl5 being effectively dead and the most hated language amongst devs. (I'm still trying to save it via cperl though).
And Perl 6 interesting (I was the parrot backend maintainer, until they ditched it), but with no significant future.
Maybe add a few default warnings for using "ugly" features - maybe just in a linter - perhaps not affecting the runtime at all?
One of TypeScript's strengths is that it is JavaScript, but you can configure tslint to help detect certain "bad" JavaScript. Or you can switch on stricter checks (and TypeScript could be just a name for a default list of strict error checks, depending on how you use it!).
For me it's the top goal, but I'm still only at 20%.
Calling this perl7 would have been a huge joke. Renaming the thing also doesn't help with the personnel who is doing the desastrous decisions they did in the last decade. Management need to change, not the name.
JavaScript actually copied its `‘use strict’` syntax from Perl's `use strict;` which in Perl is using a pragma, not a magical string literal that reconfigures the compiler.
You want types? Several systems exist, but the leading implementation is Type::Tiny.
A big part of Perl culture in the late 2000s and early 2010s was focused around rooting out horrible old practices and tutorials, defining good practices, and getting tooling to help. Perl Best Practices came out of in 2005. Some effort to describe these tools and techniques as “modern Perl” followed—check out the inaugural entry of the Modern Perl Books blog from 2009. http://www.modernperlbooks.com/mt/2009/01/
Since Perl5 did what you’re asking for, maybe you should check it out and see what Perl 5 looks like in 2019.
There are two programming languages that I learned in their first 5 years. They both ended up being languages I dislike. A language that takes time to mature and isn't the pop language of the week sounds terrific to me.
Good languages stay in use for decades. If I miss the first 5-10 years of a new programming language, either I'll skip its turbulent youth and still be around for most of its life, or it'll turn out to have been a flash-in-the-pan language and I'll have missed nothing.
If you want to be fancy you can run the JS implementation of the Rakudo compiler in browser targeting JS https://perl6.github.io/6pad/#b66f6f0eb46f296b8a285c45a152f1...
Perl 6 is actually a joy to code in, as weird as that sounds. It's fairly straightforward to begin using, but the deeper I go the more I see the huge benefit to its long development which was mainly in spec-writing. The two killer features (for my work, at least) have been the grammars (a sort of regex on steroids that is actually readable) and the multiparadigm approach. I mean you can do functional coding with Javascript sort of, but you end up with a lot of extra line noise compared to P6 where it was contempalted from the beginning (and multisubs clear things up even more). All the typical paradigms are integrated fairly seamlessly to let you choose the best tool for the job for whatever block of coding you're working on.
multi sub eat-pie( Pie slice where *.is-custard ) { ... }
multi sub eat-pie( Pie slice where *.is-fruit ) { ... }
multi sub eat-pie( Pie slice ) { ... }
eat-pie( a-slice-of-pie );
Perl6 is a big language, but has a lot of power and beauty.
Yea... libraries are always good (especially for math and analysis), but I find that powerful languages need far fewer libraries to get things done. APL can do something with a few characters that might commonly be implemented as a lengthy function or library in some languages.
Windows Powershell can surprisingly do a lot of what Perl 6 can do and people mostly understand the limitations. You can automate processes, build your own DSL, have full OO support, full .NET interop, concurrency, you can pipe data around kind of like with FP...etc. It doesn't have some of the more perlish features though.
I wonder if the JIT will interfere with scripts where startup time is not acceptable?
But if you actually wanted to get the job done idiomatically, the code is one short, simple line of Perl 6. The performance, while admittedly slower, is within the same order of magnitude as your Perl 5 version.
To me, this is the magic of Perl 6. Sure, if you want to use 16 lines of loopy integer-crunching code to calculate the first N primes and you care about speed, Perl 6 should not be your choice. On the other hand, if you'd prefer to say
(1..$N).grep(*.is-prime)
>Perl 6 performance has now gotten to the point where it's often comparable to Perl 5 or surpasses it. It still needs some work in this area, but the work is clear, the goals are straightforward, and Perl 6 is going to easily oustrip Perl 5 in terms of performance.
I hope it's true. Perl was a great language that was ahead of it's time. Eg, most complaints about Perl boil down to needing an equivalent of PEP8 and a linter.
Today, while those two things are still slow enough in Perl 6 I wouldn't make Perl 6 my primary language for doing them, I can't even remember the last time I wrote a script in Perl 6 and it was too slow to be usable.
Mind, I think Perl 5 is still faster on things Perl 5 was super-optimized for -- regex processing, for instance. But on a normal week, I throw together a couple of quick Perl 6 scripts to get stuff done. It's usually a joy to program in and execution speed just hasn't been a problem for me.
It is probably more reasonable to block a comment which appears to have nothing of value (except in proclaiming its own ignorance) from our collective psyches.
and yet, here you are :D
Possibly the latest thing that perl 6 does not do (and most languages don't do) is heterogenous computing (GPU/CPU, etc). But perl 6 strength is that it can drop into a new language DSL inline without issue so if any language will just freely mix GPGPU and normal CPU compute in a nice way it could be perl 6. Wonder if anyone in the community is working on that...
The "one tool to do all of the sysadmin's hacks" isn't much of a thing. Instead of the monolithic system and all of its services, we're moving to smaller and smaller systems in smaller and smaller containers.
As I've gotten older, the cost of going back and trying to read the old code has gotten more and more mentally expensive. Code that doesn't provide a reasonable way (as in "way that can be reasoned about") to be read gets slowly replaced by that which I can get back into the mindset of when I wrote it quicker.
Perl 6 with its myriad of operators is unreasonable. What does ⊖ or ∅ mean? Or −= (note the unicode U+2212 minus sign vs the traditional minus sign - are they different? edit: ok, I can't even add the unicode 'atom' symbol here) or »=«? How do you even type those?
I enjoyed perl 5. I'll still code in it for a quick script... but I'm finding myself leaning more and more to groovy for the scripts in part because I've been writing Java for the two decades rather than perl.
I don't need the abilities that perl 6 provides and I wouldn't want my coworkers developing a DSL.
Perl 6 brings a lot of interesting ideas to the table... but I don't want them in my code base.
Except that it hasn't. What other language does everything P6 does? (Or even tries, let alone does it as well or better.) What language does "most" or "a lot" of it? To be honest, I would have expected that after a couple of decades, there would be other languages that stole a lot of P6's thunder, but if there is anything remotely comparable, I haven't heard of it.
P6 is an surprisingly ambitious project. (I think even surprisingly so to its creators.) Apparently it just takes this long to do something that big and powerful.
Why would any language do what Perl 6 does? Languages do what they need and typically do at least some things Perl 6 doesn't do and at least some things do better than Perl 6 does them. Sometimes such things are much more important to people than everything Perl 6 does.
If you need real rational number math and are doing a lot of text processing for example, there might not be a better alternative.
I think of Perl 5 as something "outdated" because I know that there is a language called Perl 6. When I think of Perl 6 I am not particularly interested in it because I assume it's more or less the same as the "old" Perl, which I don't use and didn't really like back in the day.
Renaming Perl 6 to something else would help with both of these problems.
That said, I wonder how much damage has already been done at this point and whether renaming it now will still be very useful. There are a lot of references to Perl 6 out there already, so convincing people that Perl 5 is the latest version of Perl again will be tough.
Renaming Raku/Camelia could help that language quit being saddled with the perception that it's also legacy in the same way, though.
Why? References are not scary and they work just like in any other language -- they are simply a memory address that points to another value stored somewhere else.
my @a = (
{ first=>1, second=>"b", another_ref=>["y"] },
{ first=>1, second=>"b", another_ref=>["z"] },
);
say $a[0]{first}; # Outputs 1
say $a[1]{another_ref}[0]; # Outputs z
my $a2 = \@a; # top level is a reference too now
say $a2->[1]{another_ref}[0]; # Outputs 1, arrow only needed at top level
# The following are alternate syntax that I find unnecessary and better left alone (and most do)
say $a2->[1]->{another_ref}->[0]; # Outputs 1, explicit, entirely unneeded because it's unambiguous without extra arrows
say $$a2[1]{another_ref}[0]; # Outputs 1, extra prefixing $ dereferences first level ref
Personally, I like that it forces you to be aware that this data structure is likely in use somewhere else as well, and your changes may not be local (which is true of deeper levels regardless).
1. CPAN was great 20 years ago, but it's a joke compared to modern dependency management systems.
2. Functions don't have explicit parameters, and still shift off of @_. (This can be kind of a catch-all for all the "things that are useful for scripts, but suck for programming in the large" design decisions in Perl 5, because I honestly don't remember all of them at this point.)
To this day, I've seen package management systems for many languages, and none I've seen has been as good as CPAN in terms of
(1) Consistent place for distribution + documentation (cpan.org/metacpan.org)
(2) Automated testing on a wide variety of platform and configuration (cpantesters.org)
(3) CPAN has as standard for declaring dependencies in packages, but a newer "cpanfile" may be more akin go "modern" dependency management. Perl has also had a way of 'use Package $version' right in the source code for ages.
(4) the command "cpanm Package::Name" (or even the older "cpan Package::Name") almost always results in figuring out whatever distribution needs to be installed, even if the distribution is named differently from the package name.
I worked with Perl daily and find CPAN even more of a wasteland than NPM. The average package there hasn’t been updated in a decade and has ancient dependencies to match; takes months / years for clients to be written for new tech.
Languages like perl--like common lisp, and c--are Stable. They change, some, but you can count on old code working. If a 10-year-old package Works, what reason is there to update it? I wrote a c library which has seen no updates in about 2 years--because it doesn't need them. It already does everything I need it to do.
Often I'll just not find the library I want since nobody using that tech is actually writing Perl. For example, complete lack of a working GraphQL package until late 2017.
CPAN search in particular is unbelievably bad. The first result for 'Postgres' is a package last updated in 1998 (not joking), try to find a usable driver here: https://metacpan.org/search?q=postgres. Even the widely used DBI package has last seen an update almost a year ago.
As for DBI, it's definitely in the "stable" category and isn't trying to keep up with anything; the DBD::Pg driver though was last updated this month.
Isn't Perl 6 already backwards incompatible?
> module names are both filesystem lookups and package stash lookups
>> names converted to lowercase internally
Converting names to lowercase internally fixes this.
> it's entirely possible for valid programs to use two modules that only differ in case
Many people (myself included) would see this as a mis-feature not worth saving.
Modern dependency management systems (at least for language-specific packages) still don't hold a candle to CPAN, IMO. The namespace structure alone is something that's sorely lacking in pretty much every other language-specific package system. I'm glad Perl6 is (finally) gravitating back in that direction (though the prior system of "let's just pull from a bunch of GitHub repos" was still better than 91% of other languages' dependency/package/library/module/plugin/etc. installation approaches, or at least so I felt, having used a lot of such languages).
> Functions don't have explicit parameters, and still shift off of @_
I don't see anything fundamentally wrong with this. It's different from other languages, but not necessarily bad (again: IMO). It makes it easier to reason about things like varargs without needing special syntax for it.
The class system is similarly deconstructed (i.e. you explicitly "bless" arbitrary data structures instead of relying on the language to automagically do something behind the scenes), and I appreciate that explicitness.
---
Like, I find it kinda interesting that the two things you cited as "bad" are also two things I very strongly like about Perl. Different strokes for different folks, I guess.
How so? I use npm/yarn daily and think they are mostly giant insecure playgrounds for teenagers with too much time on their hands. Browsing through node_modules on a large project is enough to make you give up software development and take up heavy drinking. Half the code I see in node_modules wouldn't pass a PR review at my own company. Yet we still depend on it daily.
> 2. Functions don't have explicit parameters, and still shift off of @_.
Never been a problem in my experience. The expected arguments are generally at the top of the sub. You must really not like functional programming then, with heavy use of curried functions and whatnot.
The bigger problem is with passing around an %options hash, and this is true of JavaScript as well, is that the keys can be easily mistyped leading to bugs. Not even TypeScript fixes this (because developers are generally horrible about defining types, which have to be defined perfectly).
2. Whether you go positional or use an options hash, you still need to carefully unpack your args at the top of the subroutine. And do it consistently. There are a ton of libraries to help with this, too.
The most important thing is to pick a house style and do it everywhere that doesn't need to be different.
----
Perl 5: I'm not dead!
TIOBE: 'Ere! 'E says 'e's not dead!
Internet: Yes he is.
Perl 5: I'm not!
TIOBE: 'E isn't?
Internet: Well... he will be soon-- he's very ill...
Perl 5: I'm getting better!
Internet: No you're not, you'll be stone dead in a moment.
TIOBE: I can't take 'im off like that! It's against regulations!
Perl 5: I don't want to go off the chart....
Internet: Oh, don't be such a baby.
TIOBE: I can't take 'im off....
Perl 5: I feel fine!
Internet: Well, do us a favor...
TIOBE: I can't!
Internet: Can you hang around a couple of minutes? He won't be long...
TIOBE: No, gotta get to Reddit, they lost nine today.
Internet: Well, when's your next round?
TIOBE: Next year.
Perl 5: I think I'll go for a walk....
Internet: You're not fooling anyone, you know-- (to TIOBE) Look, isn't there something you can do...?
Perl 5: I feel happy! I feel happy!
----
But seriously, Perl 5.30 just came out in May. It's not dead yet.
A better metric is the activity on stackoverflow and github, which is what RedMonk use. That's much more stable. Java and C have both been #2 and #9 since 2015. https://redmonk.com/rstephens/files/2019/03/toptwenty-2019-0...
Given how much lua is used as an embedded language in Games, Databases, Servers, etc. I feel I've only seen it's usage increase.
Go I can see as "appearing more popular then it is due to HN" but even then I feel like clis/networking tools have been using Go more and more.
If Alice has two apples and Bob has three apples, Bob has 60% of the apples. But if Alice gets four more apples and Bob only gets one, Bob has only 40% of the apples, despite having more than he did before.
It's the same with TIOBE's popularity index.
Edit: Okay, starting from the minor version instead of 7 sounds like an even better approach.
Not exactly the same situation, but this reminds me of Angular. Angular 2 was a marketing debacle; the official stance of "Angular != AngularJS" is stubborn and nonsensical — any idiot can see that they're confusingly similar, and if they're supposed to be different then why is the first Angular release version 2.0.0 instead of 1.0.0? (I personally think they should've called it Circular.)
In any case, I think the way they moved forward (with "Angular 2" no longer being a thing, except in reference to that specific release) was ultimately the best way to salvage the situation; given its recovery and growth since then I'd say Perl could take some lessons from it.
When I see that we still don't have a simple "is item 'in' set" operator, 12 (?) years after the introduction of smartmatch and 5 or 6 years after its half-retraction...
(Well, we still have no sets either :-), let's talk about lists/arrays...)
When I see we still don't have a clean function parameters declaration system (better than the mess with prototypes and signatures)...
When I see that constants, enums, simple structured data (C-like-ish structs) still have to be simulated with functions and/or objects and the weight which comes together...
...On one hand, it gives a set of features that could be used to justify a jump. On the other hand, if these basic features has never been deemed useful by the language leaders until now (that is, during a couple of decades), I have little hope they will change their minds.
• "is item 'in' set" operator: https://metacpan.org/pod/Syntax::Feature::In
• sets: https://metacpan.org/pod/Set::Object
• clean function parameters declaration system: https://metacpan.org/pod/Kavorka::Manual::Signatures
• constants that are not functions/objects: https://metacpan.org/pod/Const::Fast
• enums that are not functions/objects: ?
• structs that are not functions/objects: pack/unpack, for explanation see https://metacpan.org/pod/Convert::Binary::C
Perl6 has been under development for over a decade at this point, and this equivocating statement is the best that can be said about performance? If the "work is clear, the goals are straightforward" and Perl 6 should easily outstrip Perl 5 on performance, then by gosh they should demonstrate that. Plenty of comments are mentioning slow performance. Not having used Perl 6 myself, I can't comment on it, but the fact that this seems to crop up a lot is really worrying. I've heard varying things - regex/grammar are slower than Perl5, startup time is really slow, etc.
And yes - I realize that technically the most popular compiler/VM combination Rakudo+MoarVM hasn't had that full decade of development, and that the spec is "in theory" performant. None of that matters to developers who just want to use the language...
If performance is a major blocker to adoption and it's as straightforward to fix as suggested - it should get done. Otherwise, the empty promises will continue to hurt adoption.
Every time someone complains about python performance they are usually told that it doesn't matter. If performance was really that important, people that wanted dynamic languages would all be using luajit, SBCL, chez scheme (or any of the other 10 schemes that run laps around python/ruby) and lately also JavaScript.
Part of the reason the language looks scary from a distance is it's $sigils, which speed up the interpreter.
As the other of the post in question, I refer you to this presentation: https://www.youtube.com/watch?v=QNeu0wK92NE
It's fairly decent, but there's still a huge amount of backstory left out of it. In short: in many areas Perl 6 is pretty close to on par with most dynamic languages today. In other areas, performance is still an issue.
> If performance is a major blocker to adoption and it's as straightforward to fix as suggested - it should get done.
(Disclaimer: I'm not the one doing the work mentioned below)
It's being done, but there's a lot of work. There's compile-time analysis with constant folding, eliminating unnecessary scopes, inlining native ops, code rewriting to faster equivalents, etc. But that can only take you so far.
The run time optimizer is hard work, but that's where the good stuff is at. There's a very lightweight optimizer that builds a statistical model of the program and that's very helpful. For example, we can tell if a codepath is hot or not and that model than lets us do all sorts interesting stuff, such as realizing that a hot method is always getting called with an int, so we can skip multi-dispatch lookups, assume an int, and just have a fast guard in place.
We can inline code where appropriate. We can do more escape analysis. We can reoptimize code that's inlined at runtime. We can see an int->int and realize that we might not need to box and unbox those as objects. See also: https://jnthn.net/papers/2019-gpw-ea.pdf
In short, there's a ton of stuff to do and it's being done.
God, what a horrible typo :)
* Perl 5 can continue being "perl" and have a future. People with existing perl codebases won't think they're going to need to upgrade.
* Camilia/Raku/etc can be considered on its own merits.
The C/C++ analogy is a good one: when things are different enough you stop expecting everyone to "upgrade" and instead are making a different language.
Having written some terrible scripts in perl 20 years ago (and still occasionally using it as an awk++), I am interested somewhat to learn what Perl 6 is like. But honestly, Rust and Swift are both ahead of Perl 6 in the "interesting new languages to learn when I have some free time" queue (having picked up Go over the last few years).
(edit: spelling)
I stayed through the Perl5 change over and thought it was good. Then I tried OO programming. And cried. And read that Perl 6 would make it better. But I needed something now, on a windows box, and free. That was 2003.
I tried Python and loved it.
Higher Order Perl made me appreciate what Perl could do, but the state of Perl 6 and lack of progress kept me away, as the features I most wanted were always fixes coming real soon now.
I STILL program python. Perl had me and lost me. Perl might not be dead, but it is dead to me.
In that sense, Perl never had you because Perl probably isn't interested in "having" anyone. Maybe helping out people carry out their work, but not having them. It is about getting things done, without trying to be the next big thing in CS. At least that's what I'd like to believe.
If Python helps you carry out your work better, you should most assuredly and definitely use Python. Ditto with PHP, Go, and all the rest. And Perl.
Can fall to mention that this sounds extremely sexy...
If you want regular Perl5 for Windows, Strawberry Perl is quite nice. http://strawberryperl.com/
Perl6, OTOH, has powerful OOP features like traits all built on a powerful, standard meta object protocol. Its functional programming features have evolved beyond Perl5's excellent support.
Come back and try these things out.
I could google this (which I will), but give me the HN summary. What do you think is a good reason to use Perl 6?
Grammars which are like regular expressions on steroids for parsing. ( admittedly still not optimized for speed)
Gradual typing, you can go from no types at all for short one liners, to using built in types, to defining your own complex types for big programs.
subset Positive of Int where { $^number > 0; } #create a new type called Positive
multi factorial(1) { 1 } #multi subroutines that dispatch on type
multi factorial(Positive \n) { n * factorial(n-1) }
#say factorial(0); #Error type mismatch
#say factorial(5.5); #Error type mismatch
say factorial(5); #120
hyper for (1 .. 1000) -> $n { #use hyper indicate for loop can be run in parallel on all available CPUs
say "Factorial of $n is { factorial($n) }"; #Gives correct results by automatically upgrading to big int when needed
}There's also a nice interface for writing command line utilities that takes advantage of the above.
See my Christmas themed 2018 Perl6 Advent Calendar article on the topic: https://perl6advent.wordpress.com/2018/12/16/day-17-checking...
It's been 20 years so my information could be very much out of date, but at that time anyway I would not have said this statement was true. C++ then was a superset of C, and any C++ compiler was capable of compiling ANSI C.
int new;
int *x = malloc(sizeof(int) * 15)
Performance is a big one. Not focusing on performance is like a strategic mistake for a programming language these days.
Performance has been enhanced by a few factors since it was released in 2015.
For a lots of things the next stable release (as soon as the latest round of optimization have been merged) will be on par with perl5 / ruby / python ...
The main slow thing remaining is Grammars which if I understand correctly are not available in those other languages to compare speed, but that is next on the road map for optimization.
Here is a recent talk about the state of perl6 performance: https://www.youtube.com/watch?v=QNeu0wK92NE
I've been writing perl for twenty years, and while I love its practical expressiveness (higher than any other language currently in use, as an objective measure), I've frequently wished it had better performance and lower memory footprint.
The go-to solution for that has been to profile one's code and rewrite the critical path in C, with which perl interfaces readily. It's the same story with python -- very expressive, but slow and fat (slower and more memory-hungry than perl, even), with easy C integration as the common solution. C integration works, though it's less than ideal.
On the other hand, you're being a bit uncharitable by assuming the MoarVM developers aren't focusing on performance.
They prioritized getting it working -first-, but have since paid more attention to improving its run-time performance. Their efforts have already made considerable impact, with more on its way.
I've benchmarked its performance a couple of times, and it's still too slow to interest me, but will keep an eye on it. At some point there may be an inflection point which makes it a compelling alternative to other languages.
Though perl is still my bread-and-butter, and I've written python for a living and liked it, I've become quite infatuated with D of late. It's essentially C with some straightforward extensions and improvements, which gives it roughly 3x to 4x as much practical expressive power than C (but only about 1/3 the expressiveness of perl), and excellent support for casual parallelism, while matching C for run-time performance and small memory footprint.
Before I wrote perl for a living, I wrote C for several years, and D has "clicked" with me in a way that other languages have not. Learning python and Go was rough, but I muscled my way through them. Learning D hasn't been like that. It's actually pleasant to learn, and I find myself thinking about it when I really should be focusing on other things.
One thing D doesn't have is a lot of jobs. Maybe it will someday, but I expect to write perl6 for a living before writing D for a living (and expect to be writing perl and python for a living for a while before that).
Anyway, my point is that the MoarVM developers are actively working to give perl6 better run-time performance, and it is way too early to discount perl6 on account of its current performance.
> Perl 6 performance has now gotten to the point where it's often comparable to Perl 5 or surpasses it. It still needs some work in this area, but the work is clear, the goals are straightforward, and Perl 6 is going to easily oustrip Perl 5 in terms of performance. If the Perl 6 community wants to rename, it's perhaps the perfect time to do so. It doesn't look like a bad choice if performance is a primary concern.
Shrug.
I know proficient Python programmers who were starting projects from scratch in 2017 and didn't want to use Python 3.x because they were in a hurry, worried that they didn't know how to write Python 3.x in a timely manner because they hadn't invested the time to learn it. Lots and lots of people just knew it was a known unknown for them, had no idea of the magnitude of the effort required to switch (tiny for new projects! tiiiny) and just put "look into this" somewhere deep on their backlog.
I vaguely remember that, when Perl 6 was first announced, the idea was that it would be able to run unmodified Perl 5 programs (and not only that, but it would also be able to mix Perl 5 and Perl 6 modules in the same program).
Note that you can mix the languages in the same program, but it's no different than the capability of such modules as Inline::C and Inline::Python in Perl, and doesn't actually involve natively implementing a Perl interpreter.
Except, you know, rampant incompatible syntax. Being invented by the same person and having an overlap of desirable features doesn't make it the same language, in the same way that C# is not Delphi.
I really think that both languages would be stronger today if Larry Wall et. al. had "marketed" perl 6 as a research sandbox for new ideas for language design, and then depending on where those ideas led them, pronounced it as either a successor to perl, or a new language when it was closer to ready.
Plus, you can always "use English;" if you want less cryptic names.
At the very least, I would guess, most Perl programmers almost never use 95% of them -- and many would choose (as the perlvar man page says) to 'use English;' -- and thus use the readable version. An example would be using $LIST_SEPARATOR instead of $" (which is what I would do).
I write Perl 5 code frequently, and that man page is chock full of short variable names I never use.
I have occasion to use $$, but not too often. I tend not to use much else, and like others have said in this thread, I just look up things that I need when I need them. If it is not obvious what something does (especially if it is one of these special variables), I will add a comment to explain (as I would in any programming language I use).
I understand why people don't like this particular characteristic of Perl, and it is a legitimate thing to have differing tastes. But I don't personally find it to be anywhere near as "end of the world" awful as many people who can't stand Perl make it out to be.
How does it improve the language to be so top-heavy and chock-full of obscure unreadable arbitrary syntax, 95% of which nobody every uses, but that everyone still needs to memorize and understand in order to read?
That's exactly why Perl's philosophy of TMTOWTDI is intellectually bankrupt, and encourages write-only "creative snowflake" Perl code that's an inscrutable, unreadable, unmaintainable nightmare.
The language isn't any better for having $" as a shortcut for $LIST_SEPARATOR (or $LIST_SEPARATOR as a mnemonic for $", depending on how you look at it), because now you have to learn twice as many things, and all that duplicated effort and mental stress and syntactic surface area doesn't make it any more powerful or easy to use, has absolutely no tangible benefits, only pointless costs, and makes it twice as hard to learn and read and maintain Perl code.
Python's philosophy of "There should be one — and preferably only one — obvious way to do it" is diametrically opposed to TMTOWTDI, and Python's vastly more successful than Perl because it's much easier to learn, read, use and maintain. Can you name any schools teaching Perl as a first programming language, like so many teach Python?
Forcing you to look punctuation up in the reference documentation is even worse than having to memorize it. Pausing from reading code to look up punctuation in the manual slows you down by orders of magnitude, and knocks you out of the flow. Random punctuation is not easily memorizable or mnemonic or searchable or indexable.
You also have to have memorized the ASCII order of punctuation to index through the manual, which is different than how punctuation is arranged on the keyboard! Is a comma or underscore less than or greater than a double quote or back quote, and why should I care?
How exactly do double quotes imply "LIST_SEPARATOR"? Shouldn't it be $, because comma is the standard list separator, instead of $" which looks like it could be "STRING_DELIMITER", or does $, mean something completely different? And how am I supposed to remember all that? It's totally arbitrary, annoying, and off-putting.
Now tell me how Perl is any more powerful by having twice the number of ways necessary to express the every concept?
Perl pointlessly has twice as many inane pieces of syntax to memorize or look up, to do the same number of things. There is no upside to that, only cost. And that's one reason Perl is dead.
Just like a natural language, there's a tiny pidgin subset you can learn and use to great effect. You then learn obscure vocabulary on the rare occasion you come across it.
If you have had to maintain code by people who intentionally obfuscate it, you should be at least as angry with those people as with the designers of their tools.
You have to be able to understand that if it's a two character variable of all punctuation you may need to look it up to figure out what it is. Typing `!perldoc $"` into duck duck go sent me to https://perldoc.pl/variables/$%22 ... which is roughly equivalent to `!g [docker error]` which I already do all day long.
$ perldoc '$'
No documentation found for "$"
(Yes, after a while one should learn yo search for the section that explains all the vars, at least if he's coding Perl all day. But it's a ton of useless trivia to keep in mind anyway.)
A glance at "man perldoc" (or "perldoc perldoc") will tell you of the very useful other switches, such as -f and -q.
They make sense to shell users coming to Perl. No more or less.
To be honest, I'm not sure anything can change the decline of Perl. There will continue to be Perl projects and Perl shops for a long time, just as there are COBOL projects, and COBOL shops. There will even be some new projects. But many projects will die, some companies will go out of business or migrate, and the ecosystem will continue to ossify.
"Raku" sounds nicer for me.
Perl's main use at the time was developing CGI scripts. It had big disadvantages over things like PHP and Netscape Commerce at the time, but people still seemed to like Perl. As complex web side code grew more complex, requiring a lot of 3rd party components to get Perl to do anything, people seemed to abandoned it pretty quickly.
I still use Perl today, version 5. Mostly just to process text files, but I still don't use any 3rd party libs.
I suggest looking into local::lib and then either a combination of cpanm and a Cpanfile or using perlbrew.
You are mistaken. No cpan client is capable of upgrading perl itself. If a cpan module declares a dependency on a perl version later than what you are currently running, the installation simply fails (as what would happen if there is a dependency declaration on a module that is shipped with core and is not upgradable separately, e.g. 'strict' or 'POSIX').
Well, the main change is that between then and now, other languages have setup modules depositories / package managers which are even more of a mess, so in comparison CPAN doesn't look bad any more. :-)
raku 2? Perl 5 gets the Perl name back and gets a version number leap to show it's not dead yet and raku is off doing its own thing with its own version numbers, probably hitting 1.0 barely before GNU Hurd.
PINP: PINP Is Not Perl
New features have been coming out with yearly releases since 2010's release of version 5.12.
But by 2010, many people already thought Perl5 was dead because Perl6 still hadn't shipped.
The really interesting stuff is actually happening on CPAN, with great extensions like:
* Type::Tiny https://metacpan.org/pod/Type::Tiny
* Kavorka https://metacpan.org/pod/Kavorka
* Moo https://metacpan.org/pod/Moo
* the Test2 suite of unit testing tools https://metacpan.org/pod/Test2::Suite
(edited for clarity, hn formatting is a pain)
And whatever name is given to Perl 6, great. Let it find its way in the world as it should. It's got a lot to offer.
That one decision cost the language so very much. I miss Perl. Python is what was pushed on me by employers and it's fine, it's perfectly acceptable. As is ruby and many others but I just miss Perl.
I hope the Perl6/Raku folks get things happening in their tech and perception of it the way they might like. I think they deserve a break.
Indeed with parrot VM besides perl 6 developers can be truly polyglot with same toolchain. So move forward, it's still a great addition. I feel parrot is truly open source, better than Graal no Oracle involvement.
Hopefully someone pick up Moar with Rakudo and make it multi-lingual. Given Oracle involvement in GraalVM, it will always be a risk for open source development.
An easy way to see this is to simply look at the mascot for each language.
Perl_5 => Humphrey the Camel (See https://www.perl.org/) (I am not sure if the camel actually has a name, so Humphrey seems like a good name for a camel mascot.)
Perl_6 => Camelia the Butterfly (See https://perl6.org/)
They are very different and the languages are too, so why should the languages both be called "Perl X" ?
There are many, many languages that have been closely related but with wildly different names. There have also been plenty of languages which shared mostly the same name but are very different. It might be easy to see a mistake here in hindsight, but when the project first started that was much less clear.
How good would perl 5/6 be for this?
If not perl, anything similar that's not python? I want to learn something new.
It even has built-in multi-dispatch command-line arg-processing: https://docs.perl6.org/language/create-cli
#!/bin/bash
echo hello
#!/usr/bin/env perl6
shell "echo hello"
#!/usr/bin/env perl6
unit sub MAIN($name,:$times,:$language);
say $name, $time, $language
./foo.p6 --helphttps://perl6advent.wordpress.com/2018/12/16/day-17-checking...
I walk through the development of a utility for auditing Santa's Naughty and Nice lists. Along the way, I introduce literate programming, multiple dispatch, types, type subsets, links to documentation, perl6 collections, and File IO. And, I've been told I managed to do all this without making the reader they've been dragged over rough ground behind a certain festive sleigh.
The key thing to remember when you start learning a Larry Wall Language is that you only need to worry about the parts you need to worry about. It's more like learning a natural language than a programming language. Learn how to say the things that are important to you, and it will serve you well even if you speak with an accent.
Umm.
https://metacpan.org/pod/distribution/Inline-Python/Python.p...
I’m somehow not sure Perl6 has anything to do with that.
> because they're tired of waiting for Perl 6
But…for what exactly? It’s already stable enough for use.
Ref: https://www.youtube.com/watch?v=S5iVBlk7pdg&t=279m33s “Perl 6 Performance Update”
(yes, I know they have functional snapshot builds, but as long as there’s not a final "6.0" (or "1.0") release, expect most devs to steer clear of it. Few people (masochists, mostly) want to use an ‘experimental’ programming language for important work).
> (yes, I know they have functional snapshot builds, but as long as there’s not a final "6.0" (or "1.0") release, expect most devs to steer clear of it. Few people (masochists, mostly) want to use an ‘experimental’ programming language for important work).
The “1.0” for the Perl 6 spec (6.c, because reasons) was released in 2015; the stable implementation in Rakudo was a little later but years ago. Current Rakudo has a stable, production-ready implementation of last year's 6.d version of the language spec. So we’re well past the threshold you suggest.
(More seriously, slow performance, missing features, bugs, etc. were part of the reason for not calling it "1.0", but I would agree that to be really successful, the language needs a release that is called 1.0 and acts like it.)
6.c was described, both before and after its release, as being the “1.0” release of the Perl 6 language.
> More seriously, slow performance, missing features, bugs, etc. were part of the reason for not calling it "1.0"
No, they weren't.
The first “production-ready” release of Rakudo Star release was shortly after the 6.c spec release, in version 2016.01 (Rakudo Star uses date-based versions numbers.) If they were using semver-ish numbering for Star releases rather than dates, this would have been the 1.0 implementation (as opposed to spec) release.
Although I understand why the female developer couple would want a female name. It just doesn't sound like a programming language and shorter the better (nothing beats Ruby).
rakudo, the language tool, basically translates as "way of the camel" playing on the use of the camel as Perl's O'Reilly book mascot. "Raku" or "raku", would basically be calling the language "camel" and the tool "way of the camel" which has a certain appeal as well. However, the camel has never been really directly associated specifically with the new language except in the names rakudo and raku.
So as I see it, there are good arguments for either side of this. Knowing Liz and Wendy I doubt their suggestion has much more to do with being girly than my feelings on the matter. I think it has more to do with making the clean break really, really clean.
Unfortunately all this furor within the community and even from without has nearly convinced both ladies to leave the community they've been pillars of for two and a half decades. They've suffered personal attacks over this and their participation in anything Perl related is likely to be curtailed if not ended. It's a sad, sad day because Wendy's one of my favorite people at the conferences.
To me naming is was mostly how it rolls off the tounge so I’m not a fan of multi syllable words that aren’t super common.
I’m also not a fan of ‘clever’ words that have dual meaning, like tattoos it should mostly be an aesthetic thing.
But I’m not surprised when I hear communities responding to change poorly. Any large community has this problem and it’s best to ignore the rancour. Not everyone should have an opinion and there’s nothing that attracts more than a name. So it will come down to personal taste.
I’d 100% defer to the primary devs on this one.
But it scales only slightly better than sh into large programs.
Would you consider Bash on-par with Perl?
But I wouldn't choose either for a moderately large script.
But back in the days? Bash seems to be released a year or so after Perl.
If it was not for Python and Ruby, Perl would still be the language to go for scripts. But I don't think anybody ever used it interactively.
Perl++ is a good name. C and C++ are different enough and live alongside each other.
I don't like the proposed names because they seem to imply a new language. You need Perl in the goddamn name.
I honestly think the biggest mistake that Perl5 made was going the OOP garbage way, which complicated the language as it was implemented as a hack. And everyone just said ... look Perl, ha ha ... can't do OOP!
OOP in all its forms is a mistake. Small talk OOP, CLOS, Java OOP .... sheesh it's just a hash with sub refs. C gives you function pointers and structs. OOP should have been limited to just fucking that.
Encapsulation is a mistake. Inheritance is a mistake. Polymorphism is useless in a dynamic language.
Perl++
amirite?
joking
No, it's also declining. If not for anything else, because most younger devs won't touch it (either 5 or 6).
There is a certain contingent of developers who should have been all over Perl 6 and very excited about it. We should have been seeing the stream of "$COMMON_LIBRARY but in Perl 6!" postings on HN for a couple of years, along with the blog posts of "look how crap this is to write in $OTHER_LANGUAGE but with this bit here and there look at how slick the Perl 6 solution is!" every couple of weeks. We should be seeing blog posts about the joys of working in a language with built-in grammar support replacing the old ad-hoc regex support, and how well it integrates with the rest of the features. We should have even eventually seen the contrarian backlash posts about how much of a mess you can make if you overload all your operators and grammar constructs and use all the features at once in an ill-advised manner, followed by comment thread semi-flamewars about whether bad code is the fault of the programmer or the language.
But we didn't.
Bias disclosure: I actually have no interest in Perl 6, so this isn't advocacy. Anything I've ever seen that Perl 6 looks interesting to me (emphasis) for, I'd rather just use Haskell, which I've already learned and actually does quite a lot of what Perl 6 does. But Perl 6 does it without being a immutable functional programming language, making this all a lot more accessible to a lot of programmers. I'm not saying I'm interested in Perl 6; I'm saying, there is definitely a chunk of programmers who should have been interested in it who are not.
And from what I can see, this naming confusion is one of the major reasons.
(One other one I would point to is the Perl 6 community's multi-year "joke" that Perl 6 would be released "next Christmas", which nobody outside of the Perl 6 community found even slightly funny, instead creating a reputation for the community that overpromises and underdelivers; that a few people would swoop in to those conversations to actually mock people who weren't insiders enough to know it was a joke and not a real promise, which is to say, 99.9999999% of humanity (that is not random nines; that is all but ~700 people; take one off if you like), really didn't help. I put "remaining reason" in my first paragraph because this has been resolved for many years now. But I can tell you that this significantly diminished my own personal interest, and I'm sure I'm not alone.
Finally, I'd point to it just never being done, but, arguably, that alone couldn't have killed it. There's plenty of languages that grow quite substantially over time; the Python of when Python first really got popular and the Python of today are very different, for instance. Had more people been interested and pushing for something usable $TODAY, with more work being done later, this probably wouldn't have been as big a deal.)
https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...
http://wiki.c2.com/?ThereIsMoreThanOneWayToDoIt
While I believe Python's continuing success is evidence supporting the truth of its Zen of Python philosophy: "There should be one — and preferably only one — obvious way to do it."
For example, if you have a simple function that kicks backed cached values:
sub foo ($bar) {
if %cache{$bar}.defined {
return %cache{$bar}
}
}
sub foo ($bar) {
return %cache{$bar} if %cache{$bar}.defined
}
sub foo ($bar) {
return $_ with %cache{$bar}
}
sub foo ($bar) {
.return with %cache{$bar}
}
All of the above code is readable though. Of course, a functional approach could be just as valid and readable, and clear:
multi sub foo ($bar where %cache{$bar}.defined) Or taking advantage of traits:
sub foo ($bar) is cached { ... }
Which Python manages to break all the time. How many ways are there to format a string again?
I also don't think it's a good thing that the language has idioms. In a human language idiomatic expressions are a barrier to learners, and it's the same with Perl. The context-sensitivity of expressions is also a huge barrier to maintainability because it's impossible to know from looking at the code what the acceptable contexts are for a variable. You basically have to keep track of the state of a variable separately if you want to avoid usage errors.
Finally, the fact that Perl users consider the arcane-ness of Perl to be a good thing is the last nail in the coffin for me.
However, it's one of those phrases that I'm sure is immediately clear to your intended audience. One who has experience and understands that monads are simply endofuctors that map between two category spaces (I think I got that right, and if I didn't the main point was illustrated anyway). As a person gains experience their language usage become much more intentional and expressive. Idiomatic language is really only this expression of experience and an effort to communicate the full context and nuance as succinctly as possible.
The best Perl developers I know understand this and what you see as praise for arcane-ness is usually in my opinion just embracing the idea that jargon and idiomatic language is inescapable, and should be just another tool in the toolbox for expressive writing.
Also Perl does some weird shit, and sometimes you gotta hack around that.
Except that this is a computer language. Computer languages don't have nearly the same range as a human language, and there are very specific formal rules to be followed. If I want to I can speak English without any idioms. Another difference between computer language and human language is that there is a huge amount of duplicated information in a human language, whereas a computer language like Perl is designed to be as terse as possible. So if I want to know what an idiom means in English, I can A) ask the speaker what they meant by it, B) infer what it means based on the context in which it was spoken which includes the time and place and the situation, or C) look it up on the internet.
In a computer language, A requires either direct access to the language designer, code comments, or dialogue with the user of the idiom. B requires context information, which is simply not present. There is no situational analogue to the scene and people involved in an English conversation. You're conversing with a compiler. C is made difficult by the terseness of the syntax. So really having idioms in a computer language doesn't work at all without having someone to decode those idioms for you. And in the end if we all have to decode idioms then we should just make the meaning explicit in the code. If you have too many idioms then your code becomes unreadable without some kind of codex.
> The best Perl developers I know understand this and what you see as praise for arcane-ness is usually in my opinion just embracing the idea that jargon and idiomatic language is inescapable, and should be just another tool in the toolbox for expressive writing.
While I think we can agree that Thomas Pynchon is a highly expressive writer, I also think we can agree that he is very obtuse at times. It's fun if you get it, but it's infuriating if you don't. There's a difference between being expressive and having so many facilities that casual users of the language can't remember how to do simple things because there's just so much syntax to learn and so few mnemonics with which to do so.
EDIT: no, I'm serious and that's a cool (enough) and available name with the right amount of historical correlation
EDIT 2: plus it already has an emoji icon on most platforms: https://emojipedia.org/fish-cake-with-swirl-design/