To my mind, the blockers for Perl 6 adoption in order of importance have been:
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.
> 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.
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.
# copy stdin to stdout, except for lines starting with #
while left_angle_right_angle:
if dollar_underscore[0] =eq= "#":
continue_next;
}
print dollar_underscore;
}
Feels like the big blocker is that it seems to only be useful if you insist on a language that is Perl-like but also modern, but most Perl programmers probably moved to other languages already and don't care about whether their language is Perl-like, and the remaining ones are probably mostly maintaining Perl 5 codebases that they don't want to rewrite.
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)
The thing is, there are a LOT of new things in Perl 6. Its approach to regexes (with grammars) feels genuinely revolutionary, and it's got a lot of other neat things about it.
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 agree here. Language design needs some artistic freedom, and P6 is clearly exploring new areas in that regard.
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...
> if you insist on a language that is Perl-like but also modern
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.
"Code smell" isn't an automatic "something is definitely wrong," it's an indication that maybe something is wrong.
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.
"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
There are some words used for pejorative purposes that I think the language can do without but I think wanting to get rid of modern (and hence the concepts it embodies) seems more an indicator of something wrong than just using it.
> 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.
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.
> 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.
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.
No - I'm just saying that it objectively gained a lot of popularity because they did some things right, and then lost it again because they got some things wrong.
Of course part of that is technical, but part of 'marketing' is understanding what your users want and delivering it to them.
> I'm just saying that it objectively gained a lot of popularity because they did some things right, and then lost it again because they got some things wrong.
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.
As per usual, the GP sees the matter from a purely technical perspective, which occludes the larger business insight that the top-level comment provides.
I very specifically pointed out that some of it was based on the relationship between the projects. I wasn't defending the situation, as much as providing context of why it was done that included non-technical reasons.
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).
As parrot maintainer I could explain what caused the downfall: Stupid people.
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)
As parrot maintainer I could explain what caused the downfall: Stupid people.
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 seems like you think everyone who disagrees with you is stupid. This isn't an explanation for anything.
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.
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.
Always interesting to read the final sum-total précis of what political people accomplish when they burst into a technical china shop with good intentions and not a clue. An unbelievably slow VM is an inevitable result, no matter the field. You could be doing laboratory science when a politician explodes through the door, and a year later, somehow end up with a scripting language that runs in a VM implemented in Perl...
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.
That's interesting. I've seen you make these statements, but have never been able to confirm even though I've meant to. How many actual users do you have btw?
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.
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
Sure. I just remember a lot of (possibly a bit pie-in-the-sky) talk about how it could be a VM for Perl and Python both. That the more concrete initial plans and to some degree work was to allow good interop between major versions of Perl doesn't surprise me.
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.
> 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."
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.
Sure, but most people don't know or care. They just type "python" and Python happens. If they need to find another implementation, it's possible, but there's no question about what the default implementation is.
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.
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.
> Bad example: Java actually has many VMs available for it
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.
> 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.
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.
> And it always had a single official and complete reference implementation in the form of the Sun JVM and later the OpenJDK.
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.
> Bad example: Java actually has many VMs available for it: Oracle, OpenJDK, Zing, and IBM come to mind. 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
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.
The biggest mistake IMHO was calling the perl language spec for 6.x "Perl". Because it took so long to finish and to get a proper implementation, a lot of people thought perl as a whole was mostly dead.
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)
> 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.
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.
SBCL is not Common Lisp. ChickenScheme is not Scheme, nor is guile Scheme. GCC is not C. V8 is not JavaScript. Neither is SpiderMonkey. clang is also not C. tcc is not C. Visual C++ is not C or C++. Delphi is not Object Pascal. Pypy is not Python, nor is Jython, nor is Stackless Python, nor is IronPython. JRuby is not Ruby. yasm and fasm are not x86 assembly or x86_64 assembly or ARM assembly.
I'm seeing a pattern of things that are named tools which are not the exact name of the language they compile or run.
Here's the difference. If I said "what's an implementation of Common lisp?" You'd say SBCL. If I Said "What's an implementation of C" you'd say GCC. If I said "What's an implementation of Javascript?" You'd say V8, Spidermonkey, etc.
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.
Right now rakudo with MoarVM is for all intents and purposes the main implementation of Perl6. The rakudo frontend also works with the JVM. There's work to make it work with JavaScript as a backend. It is in a continual state of being really close to the latest spec, but right now the spec is undergoing versioned revision too.
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.
> When I ask "What's an implementation of Perl6" The answer is
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.
When a project has been going on for decades, things that have only changed in the last few years are not going to be immediately and obviously understood by people.
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.
I started my first programming job using Perl in 2003.
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.
Let me clear that up for you, if you are still in doubt.
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.
Perl 5 post 5.12 is nice but people like rurban an mlehmann claim p5p are screwing it up and breaking backwords compatibility for no good reason. These two individuals are quite knowledgeable programmers, so I'm inclined to agree with them. Both have created their own fork of Perl 5.
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.
These two individuals are quite knowledgeable programmers, so I'm inclined to agree with them.
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'd like at least rurban's fork to succeed. The other one is less ambitious and probably more pragmatic as in Perl 5.22 LTS. It's nice but also quite mundane, which is exactly what you'd want in a production environment. Cperl /perl11 OTOH is very ambitious with innovation happening. I will benchmark it against 5.30 at least for the sake of science and validating its author's claims.
This is a good list. The default user experience for Perl 6 needs to be dramatically improved.
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.
perl6 has a REPL just like python if you just type perl6. There is a package manager called zef. It has some of the best and most human-readable compiler errors I have ever seen in a compiler. It has one of the simplest FFI to C I have seen to interface with the rest of the world. If there is anything perl6 got wrong, it wasn't ergonomics.
Yes, perl6 does a lot of things right. It's a great language and ecosystem that deserves more adoption.
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.
Yup, definitely agree a rename is in order. I tell people, "You must try perl 6" and they go "Oh, I tried that long time ago in the 90s". They just don't here the "6" after the perl.
I would move 4 up to 2. Every time I read an article about how cool Perl 6, I see the clever bits of syntax and think "WTF? I might enjoy playing with that for fun, but no way in hell would I use that for work."
I think this is what I admire about Perl 6, though also it is why it wasn't released as the successor to Perl 5 10 years ago.
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".
Yes, God bless them for making old Perl thirty years ago and popularizing the hash map as a core data type, and God bless them for making new Perl and whatever it brings. But I don't actually want to use either old or new Perl. :-)
Counterpoint: this is why almost all business code lacks quality.
(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.)
3 is a common anti-pattern among software systems without clear leadership. Absent a steady, guiding hand, developers behind a component of a system are forced to set their own direction.
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.
I mentioned it in another comment, but a really obvious one is that functions in Perl don't have parameters. Every function just takes in a list, and can do whatever it wants with that list. This page gives a good overview of the situation: https://perl101.org/subroutines.html
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.)
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.
So, the first tutorial on the list that you recommend has this page for functions[0]. It's more or less the same as GP's link.
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.
It's true that they're experimental, but it's extremely unlikely they'll be removed. The only reason they weren't stable in the most recent version of perl is because of some interactions with subroutine attributes (specifically, :lvalue) which needed some tweaking. We use them everywhere at Fastmail and they're great.
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."
In my experience, I never got positional parameters to reliably work on Perl5. They were always buggy and would break with completely unrelated changes.
On Perl6 those are officially supported, so I imagine they work.
There is a certain elegance to bare lists, as any lisp programmer will probably agree with. It enables the programmer to build their own abstractions as they go.
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.
My experience is that Perl scripts other people wrote are impossible to understand. It made me never want to touch it again. I was handed several unmaintained ten year old Perl scripts to update and in every case I just rewrote it in python just because Perl gave me a migraine looking at it.
As a full time Perl developer at different times over that last 20 years (and the rest of the time a sysadmin with heavy Perl use), it's not that bad anymore. A lot of very poor quality Perl was common in the late 90's and early 2000's, but for the same reason a lot of very poor quality PHP code was around from the early 2000's to early 2010's, which is to say because a lot of novice programmers (or at least novice's to Perl) were writing it, and those novices also happened to to get a lot of code into production. In Perl's case it's because the dot com boom really elevated teh quick and dirty cgi script and Perl was the main language available for that.
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]
That's a problem with the people who wrote the script, though, not the language itself.
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 a problem with the people who wrote the script, though, not the language itself.
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.
About the ten millionth time that someone had a security breach from exposing s3 buckets aws decided to look into if maybe something in their UX was bad instead of blaming the user every time.
‘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.
90% of Perl's line noise comes from using short cute variable names and trying to cram way too much into way too compressed regexes.
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.
I use Perl in my day job and enjoy it a lot, but the biggest showstopper for me is that its greatest strength is its greatest weakness. "There's more than one way to do it", it's amazing at getting things working, it excels at writing "glue" programs to shim between bigger and slower moving parts, especially if they're throwaway hacks.
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.
Routinely I see in numerous online discussions that people refuse to even consider Perl 6 because they hate Perl. Or there are younger people who think of Perl as "their grandfather's language" (in much the same way people in my generation view COBOL).
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.
As just another Perl hacker, your "not real Perl" made me laugh. And no, let me reassure you that that snippet of line-noise is not, in fact, syntactically valid Perl after all.
...you have to transpose a couple of characters for that:
cat nocarrier.pl
!$#foo->_%[]
perl -c nocarrier.pl
nocarrier.pl syntax OK
(And yes, that genuinely does make me love Perl a tiny bit more. I guess you and I are just different that way, and that's OK.)
"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?"
Except that the vast majority of those OCRs are just a series of letters. They all parse as "a variable name, that's it", and it's not even weird for that to be a valid line.
It's the kind of joke that doesn't teach you anything, rather than the kind that does.
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.”
It's not so much a feature as how really old versions of Perl worked. Any program using strict doesn't allow it unless it's a known subroutine name, built-in or other symbol.
Except in certain cases because back-compat is complicated.
I do not enjoy Perl, but I have a positive opinion of it :) I launched my career in the late 90s as a Perl/XS/CGI (later mod_perl) developer and have many fond memories of it. I also have seen enough cases of Perl codebase deterioration to acquire significant distaste for it as far as enterprise projects are concerned. I enjoy using it for one-liners and small scripts here and there because it's VI-like in terms of being ubiquitous. I just don't programming Perl in teams larger than 1. Makes sense?
I haven't used Perl since writing CGI in the 90s, and I'm not a fan of the syntax among other things.
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.
I'm a huge regex fan too. The main thing I love about Perl that is missing from most (all?) other languages is that regex is plain old syntax, not an object/function/module.
I remember those days. As someone who instantly could explain it, I was sometimes lazy, but I just assumed that most of the people knew and were similarly lazy.
Mind you at one point I was also the #2 poster on perlmonks...
> The analogy to natural language carried further into practice than Larry Wall could have dreamed.
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?
A lot of languages — in fact, a lot of software in general — is designed to make things easy for the computer/programmer: "This is how it works and you just have to adapt, deal with it."
Larry Wall put a lot of effort into making Perl try to adapt to the way the user already thinks instead, including taking advantage of having studied linguistics to figure out how the "language" part of a computer language fits (or doesn't fit) the way our brains process languages.
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).
I think there's a greater underlying dichotomy here that's relevant to your tailor-made suit analogy: the people who love Perl tend to be the people who are building and maintaining mostly only their own tooling and (usually small) codebases, and the people who don't love Perl tend to be the ones that are responsible for maintaining large piles of other people's code.
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 was stating a syllogism there: understanding and working with different coding styles is difficult, increased difficulty adds increased expense, and Perl supports many different coding styles.
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.
Larry was trained as a missionary and educated as a linguist. He came to language development with the perspective of a linguist. This is why Perl has context and pronouns.
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.
Ok, the analogy of magic variables as pronouns actually makes them make a little more sense as a concept, even though I still don't think that the ambiguity of meaning is a useful feature in a programming language overall. In a natural language an ambiguous pronoun can be clarified by a later sentence - hell, the appropriate context could come quite a bit later on if that's the intention, and comedy certainly uses this trick sometimes. But that's not true for a programming language, where magic variables aren't ever really ambiguous, they're just context dependent. My guess is that good Perl developers learn all the rules for all the different contexts and then internalise them, forgetting the bit between where they are and when they were a beginner and were only using simple things so didn't need to know more than use $_ here, use @_ there.
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.
Writing and reading Perl was meant to feel more like producing and consuming natural language. When in comes to natural language, our ability to use it for practical purposes is a fact, and whether it can be understood rigorously or shoehorned into a logical framework is an academic question. With that in mind, Perl was designed without regard for whether the everyday user of the language could understand the logic beneath it. All that mattered was that people could learn to produce meaningful chunks of code and understand code produced by others who wished to be understood. Unlike any natural language, of course, there was a standard implementation, so there was a logic underlying it all, but being able to pull apart a piece of code and explain how the parts worked together was considered to be of secondary importance to being able to successfully produce working LOC.
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.
> or that "black big dog" is as valid as "big black dog."
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.
My contention with people hating on perl was always that they mostly hated it because it was fashionable. Yes perl uses many special characters but reading perl without knowing it is no different from trying to parse OCaml or Haskell code without knowing all the lingo.
Sadly, during my career I've actually never met a kindred perl loving soul.
Perl 6 is probably a great language, I'm not very interested in it, for the reasons someone might pick it, I'd probably pick a different language; of course not for any logical reasons, but still. Perl 5 on the other hand is still a great language for lots of reasons. I hope Perl 6 is renamed and Perl 5 will become Perl again and it will be reinvigorated and more people will consider it again. Don't get me wrong, I don't use Perl day to day because of the type of work I'm doing at $DAYJOB, but people like to dump on it for all the wrong reasons or outdated reasons, but I still believe in it, and I think a lot of people still do but there just isn't the mindshare and no matter what we think about our industry and how it works, that ultimately means new developers won't use it.
No, P6 was intended to fix as many Perl 5 problems as possible, and being eminently parseable was considered very important (and important in deciding to forsake backwards-compatibility, I believe).
In fact, a key design-goal is having the language defined by a well-formed grammar that it actually uses to parse itself — and thus that can be used by tools such as editors to parse it just as easily.
This specific problem is not a deal breaker in practice. You solve the problem by adding to the readme of the tool "If the arity of a function cannot be established, we assume no arguments and print an warning. Add {foobar} before the function to assume arguments. Sorry for inconvenience."
No language tooling is perfect. We shouldn't expect that from Perl tooling either.
I mean, it's technically parseable, since otherwise perl (the program) wouldn't be able to function. However, to parse it requires - as that article demonstrates - a preexisting knowledge of what certain words mean, and those meanings are dependent on context. That's easy for perl, since it already has to know what "whatever" means in order to compile/execute it, but is - if not impossible - than prohibitively difficult for something like a syntax highlighter or other tool meant to parse Perl without executing it per se.
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).
It's real old and out of date now, but the STD grammar of Perl 6 was written in Perl 6 ahead of time and the Pugs implementation worked against it https://github.com/perl6/std/blob/master/STD.pm6
I'm sorry but Perl 6 isnt relevant IMO. It took too long. I was a Perl developer at etoys.com in 2000 and BBC in 2001. I wrote OneMusic for Radio1 and even convinced the BBCs uptight ops team to run it with modperl so it could handle the high traffic it did. I also created the job search engine WorkZoo in modperl, one of Time Magazines top 50 sites of 2005 and Indeed's main competitor at the time.
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.
... which is the whole point of renaming it, right?
"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.
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 usually more indicative of a language that's found in existing codebases, but is no longer used to start new ones. If you join a team and someone in that team actually knows Perl, that's highly unusual these days.
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?"
I am not a developer, but a sysadmin, and I don't know much about perl since I haven't used it much in the last 15 years. But I do know that if you have to run commands for CPAN to install some packages your developer says are required, your in for a bad day.
I agree, but part of the problem is that CPAN is old, i.e. it's been around for years, so you can find very out-of-date documentation and advice on the web about how to install packages.
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.
Look into cpanm, local::lib, the Cpanfile, perlbrew, and carton. There are multiple angles of attacking this issue that are better than the old CPAN shell.
Most likely, but as a Hail Mary last-ditch effort, it seems reasonable and probably better than nothing. "Raku" sounds at least 1% more interesting for a dev to look into trying than "Perl 6".
It's not the last version.
There are two latest versions of Perl, the perl5 variant, currently at 5.30.0, and the Perl 6 variant, but they use the Microsoft convention of years in the name.
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.
Someone else suggested renaming Perl 5 to Perl 7, and that has some merits so long as it is 100% backwards compatible (no Python 3 improvements).
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!).
Perl5 has linters (Perl::Critic, Perl::Lint). And warnings to keep you from using ugly features (if you assert compatibility with the 2010 release 5.12, strict mode is automatically turned on).
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.
perl 7 would be a major bump beyond perl 6, but perl 5 has not even caught to 10% of Perl 6 yet. This a non goal for them.
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.
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.
You’re ignoring the comment two above you. The suggestion was that there are no uses for Perl 6. That implies there’s at least one language that does what it does. There is not.
If you need real rational number math and are doing a lot of text processing for example, there might not be a better alternative.
What has changed in the programming world so much that Perl 6 (or raku, or whatever it will be called) is now irrelevant? Seems to me we still have the same problems we did when Perl 6 started. In fact, one of its graces, parallelism, no GIL, is an asset now with multi-core. Reactive programming is popular now which is built into perl 6. Functional programming is now more popular which is built into perl 6. Serving web requests and parsing json is popular now and that's super easy to do with perl 6.
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...
I don't need a language with everything built in anymore.
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.
The entire point is to align the name with the reality so that people don't make the exact mistake you made here of thinking that it's a "version update" for Perl.
Okay, but is it a good, useful programming language? In some ways, the long development timeline suggests a slower, more stable way of doing language changes that appeals a lot to me.
I think so. I regularly use JS and Java in daily life and used to use a whole host other languages in the past.
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.
The type system and multiple get rid of so much “if this then do that” code.
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 );
I don't use it yet, either. Why are you trying to make it sound like a new language needs instant adoption, or it's dead for all time? It's not going to expire if it takes a few years.
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.
I might be the odd one, but every talk about perl 6 I've seen picked my interest a lot in terms of expressivity and metaprogramming done in nice ways. Its relevance might be out of sync with the trends, but I believe good ideas are forever.. and perl 6 seems to have a few. Just wait 40 years.
For what it's worth, for maybe half of my scripting purposes, Perl 6 was already performant enough back in 2010. The big things I remember it having speed issues on were things you wouldn't normally have considered Perl 5 a solution for, like using a grammar to parse a multi-megabyte CAD file or calculate a Mandelbrot set using elegant high-level code.
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.
>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.
Lizormato and some other folks have put in hundreds of performance fixes...I think these things just take time. The language might have been in development and design since the 90's, but it only just got to 1.0 or a "stable release" in 2017 I think. I'm surprised Larry Wall hasn't written a Perl6 book yet. Plenty of other authors have, but I was really looking forward to something from him or Damien Conway.
I've installed just about every release since 2017. It's a nice language but still slow and lacking library support. The best thing about it is probably the rational math.
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 did some tests for prime number crunching. For example the C-style loop statement is faster than Perl's own foreach. Perl6 was the slowest of them all while the fastest was LuaJIT. The whole code is two loops with a bunch of multiplications and additions, an array push, loading a hash and looking up values in it.
This seems like a very odd standard to use? I understand that you wanted to compare performances of different languages, that's great.
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)
and get the answer back in reasonable speed, Perl 6 is perfect.
It's just stuff that I use daily in normal code, so this benchmark pretty much serves the pupose very well: it uses mundane operations, also uses memory, one can adjust it by raising the bar 10x times, so the actual algorithm takes several orders of magnitude longer than the JIT penalty. In fact most of the interpreted languages would pretty much crunch for minutes at 10⁴, while Go, Crystal, D and Rust would take seconds or tens of seconds. Perl6 is basically stuck there forever and at the other end of the spectrum are Node and Dart. LuaJIT would run out of memory at that figure, otherwise it's among the fastest.
This seems like an ignorant mindset. Not only is P6 not a "single version update" (which shows ignorance about what the language actually is) but it has features to rival any dynamically typed language today and supersedes many of them. If you don't care to "hear these discussions about the minutia related to it", what was the point in your comment other than to say you're not personally interested in it? But it's hard to gauge if you actually are interested in it since you have "blocked it from [your] psyche" so you couldn't possibly know if it's any good.
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.
As an outsider who hasn't written perl code in more than a decade this all makes a lot of sense to me.
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.
That feels like the best way to save the brand. Cut a Perl 7 release concurrently with the Raku v1 release, and just get on a regular schedule of incrementing the version every 6 or 12 months.
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.
Yes for Perl 5->7, but it would be good to have a solid-ish feature change or addition to justify the jump and promote 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.
There is little strain on the "language leaders" (that would be barking up the wrong tree, anyway) as the features you named with one exception are already done and have been available for years.
I feel like this is what Perl11 could end up being if it actually becomes a version of Perl instead of a kind of collection of Perl5 descendants: http://perl11.org/
Just keep perl 5 running forever please. I don't want to have to re-write the perl I wrote in 2001 that is still running in production. I wish now I had never started writing stuff in Python 2.
TIOBE is not a relevant barometer, it's just the number of searches and hence a noisy metric. Look at https://www.tiobe.com/tiobe-index/. It indicates that the popularity of C and Java halved between 2016 and 2018 and then made a dramatic recovery, doubling in less than a year. It would be absurd to suggest that there was a real world change to the usage/popularity of these two languages corresponding to this.
Its usage has increased, but so has the usage of other languages. Its drop in popularity is relative to its share of all users.
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.
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.)
As an active perl5 programmer, what do you mean by (1)?
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 don’t know where you’ve been looking, but none of that is particularly interesting or new at this point.
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.
Don't get me wrong, I'm not disputing that the existing collection of modules on CPAN is languishing, but specific point is that the infrastructure behind CPAN + module distribution is unparalleled by anything I've seen elsewhere.
What's wrong with a package not being updated for 10 years?
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.
I'm not talking about the 'reached perfection' case. In ten years the language, standards and it's patterns, underlying libraries, hardware, performance, all change. There is also no value in having a working, stable implementation of say, md5 when the entire world has moved on.
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.
It is pretty unfortunate that so many people used "PostgreSQL" and "Postgres" in their module name and DBD::Pg didn't, so it gets ranked lower for those queries. But ranking is a hard problem when there is no curation. The MetaCPAN team does want to improve this if possible.
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.
I'm sorry your initial search for a term didn't immediately give you what you're looking for, but the database layer of Perl is very mature, and if you looked at the docs for DBI, you would see that it uses drivers in the DBD namespace, and if you search DBD, postgres is in the first few results, under DBD::Pg. Just like NPM, having a word in your module namespace or description is probably not always very well correlated to module quality or whether it's actually related to that term, so a bit of active research is best to determine what should be used. Then again, I'm not sure NPM is known for providing mobile namespaces that allow third party modules to interact well in a pluggable way, which is quite common on CPAN.
I would love to see a upgrade to cpan able to handle names converted to lowercase internally. To remind that you must write "use MymoDuleSQL" instead "use myModuLeSqL" can become pretty frustrating for my tired eyes.
This would be a pretty difficult change. Aside from backwards incompatibility, module names are both filesystem lookups and package stash lookups, and in most cases both of those are case sensitive, and it's entirely possible for valid programs to use two modules that only differ in case - at best I could see a warning that searches for a "did you mean?" but that sounds slow.
> CPAN was great 20 years ago, but it's a joke compared to modern dependency management systems.
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.
> 1. CPAN was great 20 years ago, but it's a joke compared to modern dependency management systems.
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.
To the second point, named parameters as implemented by Function::Parameters do provide this checking if you want it to. Named parameters was a planned feature for core signatures and hopefully it will have similar functionality.
And regarding 2): Signatures have been in core for several years now, you just need to turn it on. And for back-compat reasons it’s uncommon in CPAN distributed code.
Unfortunate realities of 1) the difficulty of working on the Perl codebase combined with its unpopularity leading to few being both qualified and motivated for such a task, 2) a lack of corporate backing or visionary design purpose driving such features in the language, thus 3) being implemented almost entirely by one individual who had a long period of demotivation and sickness.
I suggest and use the opposite rule of thumb, "always use references". It tends to simplify things. Python writes the same rule into the language itself.
> but my rule-of-thumb is that if I anticipate wanting to use references, I will go elsewhere
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.
The implementation is not the issue; it is the awkward and fussy syntax. It is not a show-stopper -- I coped with it for a while -- but there are better alternatives.
The happy-path syntax is pretty straightforward. I wonder if you're under the impression like some that you need to use the arrow syntax or prefixing dollar for every reference, and not just the first? That's not the case. e.g.
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'm happy with a single arrow that lets me know if I have a reference or not. References are important, because they denote that this data may be accessed elsewhere as well, so I'm happy to have a small reminder. Inner level references needing a bit of care if they are copied is somewhat normal though, most non-toy languages have some concept of deep or shallow copying.
Fair enough. I did go a little overboard in the name of completeness. IT just boils down to actually understanding what a reference is in Perl (which is something that needs to be done for anything non-amateur), and then realizing there's one -> or not depending on if it's a reference (and doing the wrong thing will fail, not do weird stuff).
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).
> 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.
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.
> 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.
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.
"As fast as Perl 5" means "faster than python and ruby".
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.
* 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.
I don't see any future for Perl5. Through a type of Osborne Effect - https://en.wikipedia.org/wiki/Osborne_effect - the development of Perl 6 has also killed Perl 5. Few or none will reach for Perl5 these days for new development - Python or Node.js have obliterated Perl as contender in the space it used to dominate and I don't see Perl5 ever muscling it's way back. Fairly or unfairly, Perl5 is viewed as a legacy tool these days.
Speaking as someone with an existing Perl codebase in an embedded Linux system, we were planning on replacing it with Lua anyway because that would shave a solid 20 MB off the image size with no downside.
Raku is a good name (can be abbreviated to 楽 as a bonus). Camelia is too long and is already the name of the mascot. Ofun is terrible (nothing like a product implying it's "fun" by literally including "fun" in the name).
The author (and many comments here) make good cases for renaming; but other than, "Perl 5 is dead, long live Perl 6", what case is there to be made for keeping "Perl 6"?
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).
I learned Perl4 in grad school and it was a life changing tool to automate my analysis workflow. With it I was able to script complex solutions that drove stepper drivers and CCD cameras on a microscope for data and image collection.
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.
What I got from mingling with the Perl community: The single most repeated advice (indeed Larry Wall himself has said it repeatedly), is that one should use whatever tool will allow one to carry out the task at hand and generally get things done.
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.
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.
Off the top of my head:
Concurrency and parallelism using high level and low level APIs. There is no GIL.
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
}
Four of my favorite things are the built-in MOP, the syntax for declaring values and their traits in objects, hyperoperators, and native support for user grammars rather than just regexes and parsing modules.
I don't get all this "Perl 6 is a different language" nonsense. It was created by Larry Wall and retains all the characteristics of Perl 5 whilst adding a lot of great stuff from other languages. Sadly, performance prevents it being taken seriously in production.
Perl 6 is more different from Perl 5 than Java 11 is from Java 1, or ES2019 is from OG Javascript. It is genuinely a different language, and pretending that it's the same language has been a huge problem for both of these languages to an even larger extent than this article recognizes.
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.
Your information is very much out of date. C++ makes a few important changes that make most c code incompatible. #1, implicit cast between void and non-void pointers is not allowed, so something like:
int *x = malloc(sizeof(int) * 15)
is legal c, but in c++ you would have to cast the malloc call. Also, type of character literals is int in c but char in c++. String literals are const only in c++. Functions that take no arguments must be declared as taking void (as in void func(void)) in c, but simply () in c++.
It's a different language because you can't run Perl5 programs unmodified in Perl6. The same is also true of Python2/Python3, which is why that transition has also taken so long. The difference is they managed to do it without everyone abandoning Python2 for something else.
It’s pretty easy to upgrade most code from python 2 to 3 and a lot of code just runs as is. The reason the upgrade path was so slow, imo, is that even a reasonably small amount of work is still work, and for a lot of people, the benefits didn’t justify spending any time at all rewriting software that already worked.
After the initial round of "useful PyPI packages don't support Python 3 though, I can't migrate", that "I know 3.x is different and I'll have to read up on the differences....later" was absolutely the biggest blocker for adoption imo.
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.
Apart from specific cases, which all have workarounds, you can run the same source in python 2 and 3. Many projects still do and handle the edge cases with libraries like "six". Even that transition/difference is much smaller than the perl5/6 issue.
The other difference is that they did not split into a python 2 and python 3 dev team over the period of two decades which then both decided to keep officially developing their respective languages.
> It's a different language because you can't run Perl5 programs unmodified in Perl6.
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.
> It was created by Larry Wall and retains all the characteristics of Perl 5 whilst adding a lot of great stuff
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.
> 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.
That is exactly what the main architect of the compiler has been working on for the past couple of years.
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.
Wat? Consider Perl was created in 1987 when compute resources were things like the Apple II with a Motorola 68020 at 16 MHz with 4MB of RAM. Exactly what do you imagine was the reaction back then? Something being "interpreted" (which Perl 6 is not any more than C# or Java or JavaScript) simply doesn't matter given modern computers, and things like JIT at runtime are hugely valuable even in languages like C. Some interpretation is better than upfront compilation.
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.
Too early? In 4 months it will be 4 years since Perl 6 was released and it's still 5 times slower than Ruby at simple tasks like parsing a log file with a regex.
Not entirely convinced performance stops it being taken seriously, it just prevents some use cases. Unless you've tried a really recent version of Rakudo and found it monstrously slow at something? If you have, report it!
I think this is a great idea that is two decades too late. Many people say that python killed perl, and that is true for those who disliked perl. However, I think perl 6 killed perl for those who liked it, or could have liked it if they learned it. The knowledge that there was a new version on the way that would have all power of perl, but fixed many of its problems took the wind out of perl's sail, especially once it became clear how different it was going to be. Why invest time into learning perl 5, when perl 6 was just around the corner? How do I defend my use of perl 5 in production, when its own creators have moved on? Best to just concede the battle, and regroup for the war when perl 6 is ready ... and then it never was.
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.
As a non-perl programmer, the mnemonic descriptions in the perlvar manpage crack me up. They probably are useful and make sense to perl programmers, but from the outside, they look like parody.
The whole "Perl is easy to learn because it borrows from other languages" argument is based on a very specific set of historical assumptions about which "other languages" everybody knows, and what associations they have with each punctuation character from different shells and languages and utilities and operating systems and config files circa 1987, that is just totally obsolete these days.
Bash didn't exist when Perl was invented in 1987. Bash was first released two years later in 1989. In 1987 there was the Bourne shell sh, and there was csh and derivatives like tcsh, and there was the Korn shell ksh and its derivatives, and they each had their own unique quirky menageries of subtly nuanced punctuation and syntax and variable names. And of course there was sed, and awk, and C, and even BASIC.
Most if not all of the variables in question come from the Bourne shell. It's fair to mention bash still using them today because it's supposed to be Bourne's successor.
I don't think you should place too much emphasis/concern/whatever on most of the special variables available in Perl 5. I would wager that most Perl programmers never use about 95% of them (that is, the short 2-3 character ones listed on that man page).
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.
Yet you have to know both versions of them all, and be able to recognize and understand both kinds when reading other people's code.
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.
> Yet you have to know both versions of them all, and be able to recognize and understand both kinds when reading other people's code.
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.
I hope perldoc search improved on Perl6, because it only used to match section titles, and none of the line noise vars are there.
(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.)
Memorizing everything is not required, there is reference documentation. Learning the language would familiarize you with the important syntax, as with any language, and all languages have such oddities, they just appear in different forms.
No, all languages do not have such oddities. That's a false equivalence. And it doesn't excuse Perl's bad design or justify its intellectually bankrupt TMTOWTDI philosophy.
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.
$, is the output field separator, which in short or English form is very rarely used. Generally people explicitly determine what they want on output with something like sprintf(), printf(), or join() rather than sending a list to print().
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.
In practice (from a rough survey of CPAN code and Perl code in the wild I've looked at), people rarely use the English versions, and tend to memorize the few punctuation variables that are commonly used: $_, @_, $/, $], $$, $@, $!, $? (and note that some of these are out of familiarity with other languages) and ignore the rest unless needed for a specific problem.
This is probably accurate. I personally use this subset all of the time (for reasons that will be obvious to Perl programmers): $_, @_, $@, $!, $?
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.
Perl 6 was a huge mistake; it's a different language and should have never had the same name. I support renaming it so we can all forget about it and have Perl 7 be a direct, mostly backwards compatible descendant of Perl 5 with feature enhancements. This whole Perl 6 nonsense was the reason I jumped to Python many years ago.
I think this is a good idea, but there's a decent chance that some people will mishear the change as "Perl 6 is cancelled, Perl is dead".
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.
I think it was CPAN that killed Perl, at least that was a major nail in the coffin for me. I have no idea what the CPAN of today is like, but back in the mid-late 90's it was horribly unreliable. There were dozens, if not hundreds of modules that did the same thing, and a lot of them had major bugs. But installing one was the big issue, as it would always choose the latest release of any module in the dependency chain, including the perl interpreter itself. And this was done without any hint as to whether the module actually worked with the latest versions of those modules. So, you'd end up upgrading a bunch of modules, very likely breaking things that worked. And at the end, it'd "upgrade" the perl interpreter. And by "upgrade" I mean install a new copy, replace all OS references to the new version, but not include any of those modules you just installed. So you had to re-install everything again.
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 have no idea what the CPAN of today is like, but back in the mid-late 90's it was horribly unreliable. There were dozens, if not hundreds of modules that did the same thing, and a lot of them had major bugs.
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. :-)
> But installing one was the big issue, as it would always choose the latest release of any module in the dependency chain, including the perl interpreter itself.
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, not strictly mistaken, but severely outdated. The CPAN module did try to upgrade Perl in ancient versions, and this of course was a terrible idea.
Maybe that's how it is today, but every time I installed a module in would invariably end with CPAN downloading the source of the latest build, compile it, and install it. Then I'd have to go and re-install every module under the new version.
To put some numbers in this thread, it was fixed in CPAN.pm version 1.90 in 2007, which first came with Perls 5.8.9 and 5.10.0 (but can be updated on older Perls).
Then what's the next version of Perl 6 supposed to be, Perl 8? And the next version of Perl 7 will be Perl 9... From then on their version numbers will leapfrog each other to keep Even Perl and Odd Perl in parity.
> Then what's the next version of Perl 6 supposed to be
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.
This is a great idea. If Perl 6 got a new name, some new branding, and Perl 5 added a few new features and polish, the language would suddenly awaken from its 20 year nightmare.
Absolutely. I should have added that such new features whatever they may be could be touted as the lever to move Perl 5 to Perl 7 and be done with the whole Perl 6 thing.
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.
perl5 needed a single switch to make it loosey-goosey anything goes otherwise have use strict and -w by default.
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.
I think the name Camelia or Raku is fine, no need to argue over it forever. During this renaissance period of computer languages in history, it will be nice to get this out and iterate. Given there are plethora of choices today like go, rust, Nim, elm, elixir, Scala, julia, crystal, F#, D etc. trying for developer mindshare which is a limited resource speed is of essence.
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.
Yeah that's sad Perl 6 moved to moarvm[1]. I guess necessary evil to have performance which they can't get out of parrot.
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.
Perl 6 should definitely be renamed so that Perl 5 can just be Perl.
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.)
Jeremy Howard (co-founder of Fastmail (Perl used for everything), co-founder of fast.ai, etc.) in his Lex Firdman interview this week, made some interesting comments on Perl and Larry Wall no longer taking enough interest in the language. I don't use Perl, but the comments were interesting anyway.
I rarely see Perl in the wild today. Only companies that are too big too fail and too cheap to move on still clings on to Perl, the big "index" sites of the late 90'ies that somehow haven't been completely run into the ground by silicon valley giants like monster, facebook, linkedin etc.
That announced that it could be used as a second name, but provided no further guidance, so Perl 6 is still used by many thus its problems are still just as present. This proposal would be to actually consistently use Raku as the name of the language.
Wouldn't it have made more sense to hold off on the first announcement until there was consensus on a single new name, instead of having two or three inconsistent namesoperating simultaneously for a year? Neither of which might be the final one?
A lot of things would have made more sense in hindsight, but it's not where the community was at the time, and ultimately Larry said no to a straight rename. He is taking less of a role now so it can be revisited.
I think an interesting question is, if the developers of Perl 6 knew from the beginning that they are essentially designing a new language with a new identity, would their new language be different and to what extent?
Developers now want to grab old folks by using old name and new ones by using new name. Politically they can do that because there is a Perl 5 faction existing because of the big differences between 5 and 6.
Why are Modula, Modula 2, and Modula 3 so different? Or PHP 3 and PHP 7? Or K&R C, C89, C99, and C11? Or ISO Pascal, Turbo Pascal, Object Pascal, and Delphi?
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.
I want to write some scripts that are _slightly_ too complicated for bash. Basically just implementing some simple scripts that have a couple options/args and I want to use another tool.
How good would perl 5/6 be for this?
If not perl, anything similar that's not python? I want to learn something new.
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.
“Perl 6 is a sister language, part of the Perl family, not intended as a replacement for Perl 5, but as its own thing - libraries exist to allow you to call Perl 5 code from Perl 6 programs and vice versa.”
Until Perl6 is actually released, it doesn’t really matter what they call it.
(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).
> Until Perl6 is actually released, it doesn’t really matter what they call it.
> (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.
Then it should have been called "1.0". Calling it "DEFINITELY NOT 1.0" while deciding that that is secret P6 code for "really means 1.0" is awfully bad marketing.
(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.
I've got to agree Raku is way better than Cameila.
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).
Camelia is the name of the butterfly mascot, hence the suggestion to use it as the name of the language.
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.
Oh apologies I made an assumption there I probably shouldn’t have.
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.
It was shell scripting with reasonable arithmetic and an incredibly good support for text consumption and regular expressions. Everything you'd miss on a normal shell.
But it scales only slightly better than sh into large programs.
The cool part about old 90s Perl5 was ... it was doing its own thing. The best part about everyone hating you ... gives you the freedom to do precisely that.
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.
Could it be that the Perl language (and especially Perl 5) but as a community in general, is established and mature, and very stable, that the only things that are mentioned are just not the things that newer, fast moving languages such as Rust and Go talk about? I don't think that the naming situation is trivial, I really think it has had a negative effect on both Perl 5 and Perl 6.
This is by far the most important thing they could be doing right now. It should have been done 10-15 years ago, and is arguably the dominant remaining reason for why the work done on both Perls since Perl 6 has failed to payoff the way it should have.
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.)
I've found over the past 6 years that anything nice about Perl is negated by how hard it is to think of the right way to do something from among the 30 different ways. And it makes it difficult to write maintainable code because there are no good ways to constrain the input domain of functions.
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.
While it's true in human language that idiomatic expressions are a barrier to learners, they are also a means of enhancing communication between experienced users of the language. Take Jargon for example, I've not got deep experience in functional programming, category theory, or discrete mathematics (really anything much higher than college stats), so the phrase "constrain the input domain of functions" set me scratching my head a little. I'm still not exactly sure what you meant by it.
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.
> While it's true in human language that idiomatic expressions are a barrier to learners, they are also a means of enhancing communication between experienced users of the language.
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.
I believe Perl 5's decline and Perl 6's failure to catch on is evidence of the failure of their common underlying TMTOWTDI philosophy, which encourages write-only "creative snowflake" Perl code that's an inscrutable, unreadable, unmaintainable nightmare. (The sigil-heavy line-noise syntax sure doesn't help, either.)
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."
So I basically agree with you & jschwartzi. But to expand or reinforce my original point, it is very clear there is a substantial contingent of programmers who do not. While of course in my own opinion, my own opinion is correct (duh), at a more global level, or maybe in a more academic sense, I'm open to the possibility that I'm wrong. I've already flopped on that matter once in my career and I reserve the right to be convinced by another language that I'm wrong now, too.
You don't have to be "wrong". You just have to be not exactly the same as everybody else. And of course, nobody is exactly the same as everybody else, therefore there is not possible for there to be such a thing as The One Perfect Language. The right tool for the job; but also the right tool for the workman.
The idea that there's only one way implies that code context means nothing.
For example, if you have a simple function that kicks backed cached values:
sub foo ($bar) {
if %cache{$bar}.defined {
return %cache{$bar}
}
}
Is an absolutely correct way of doing things. But it's messier then using a postfix:
sub foo ($bar) {
return %cache{$bar} if %cache{$bar}.defined
}
Or simplifying:
sub foo ($bar) {
return $_ with %cache{$bar}
}
While it's true that
sub foo ($bar) {
.return with %cache{$bar}
}
is possible, I don't tend to use it too much because the dot syntax isn't as pretty with postfixes ha. But each of these options has a place where it is the better option, but none of them is universally the one and only best option. Nested ifs with multiple statements may go better with the first one, but if several conditionals have similar elements and are simple statements it might behoove to line them up with whitespace. But the placement of return right at the outset (as opposed to nestled in an if statement) to me makes it clear the return value is a gate-keeper of sorts. Ditto for using 'die if [cond]' which much more in your face then 'if [cond] {die}'.
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)
{ %cache{$bar} }
multi sub foo ($bar) { ... }
Or taking advantage of traits:
sub foo ($bar) is cached { ... }
Almost inevitably the unreadable code is where someone is trying intentionally to be cute and write unreadable code. But that can be done in languages like C too, or with any language that allows single letter variables.
I haven't looked at Perl in years, having long ago switched to Python/SciPy, but now I see that Perl 6 doesn't have GIL, something that Python has been unable to shed. So now a language that nobody cares about anymore solves the #1 problem that I have with Python. We are truly blessed to have so many shitty implementations of dumb programming languages to choose from these days!
I am a Perl user not Raku, and Perl had almost the opposite problem where its threads are concurrent but too badly designed to be useful. But from what I have seen, Raku is second to none in this capability.
Being able to do a multi-threaded map() would be divine. In Python, you're creating/destroying a new process and using IPC to seed the state info and return the results for each element in the iterable arg. If the function in question runs quickly, it ends up being faster to do it single threaded.
I'm continually astounded that threading involves jumping through so many hoops in 2019. If you want a language that provides a REPL and easy threading, your choices are few and far between.
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.