Bring out your dead. BONG. Perl 6: I'm not dead! BDFL: BONK.
November 2, 2019 2:13 PM Subscribe
The programming language named 'Perl 6' is dead. Long live 'Raku'.
After almost 20 years of development Larry Wall (Perl's Benevolent Dictator For Life) has pulled a 'Rule 2' on changing the name of 'Perl 6'.
At a relatively recent conference, Larry phoned in a message, Larry Wall greeting PerlCon attendees in Riga 2019 that implied that he's now OK with changing the name.
The rules for BDFL:
Well, evidently there was a bunch of back and forth, but it was going to happen: Larry Wall has approved renaming Perl 6 to Raku | Hacker News. There's some decent stuff in there about what 'Raku' means in other languages.
And a GitHub issue was put up and now it's done: Path to raku by lizmat · Pull Request #89 · perl6/problem-solving · GitHub.
Larry (aka TimToady) chimed in with the BONK:
Now there are freshly minted 'Raku' sites to behold:
Homepage: Raku Programming Language.
Reddit: Raku.
Weekly Blog: Blog Feed – Weekly Rakudo News. (The last Perl 6 Weekly Blog: 2019.41 New Wineskins | Weekly changes in and around Perl 6.)
And a couple bonus videos (just mentally replace 'Perl 6' with 'Raku'):
Jonathan Worthington. Keynote: Perl 6 Concurrency.
Jonathan Worthington. Perl 6 performance update.
The rules for BDFL:
- Rule 1: Larry is always right.
- Rule 2: Even when he changes his mind. (see: Rule 1)
Well, evidently there was a bunch of back and forth, but it was going to happen: Larry Wall has approved renaming Perl 6 to Raku | Hacker News. There's some decent stuff in there about what 'Raku' means in other languages.
And a GitHub issue was put up and now it's done: Path to raku by lizmat · Pull Request #89 · perl6/problem-solving · GitHub.
Larry (aka TimToady) chimed in with the BONK:
I am in favor of this change, because it reflects an ancient wisdom:Let the healing begin. While /r/perl was all "yay, now go away", The Perl Foundation was a bit more generous: TPF response to Raku rename
“No one sews a patch of unshrunk cloth on an old garment, for the patch will pull away from the garment, making the tear worse. Neither do people pour new wine into old wineskins. If they do, the skins will burst; the wine will run out and the wineskins will be ruined. No, they pour new wine into new wineskins, and both are preserved.”
Now there are freshly minted 'Raku' sites to behold:
Homepage: Raku Programming Language.
Reddit: Raku.
Weekly Blog: Blog Feed – Weekly Rakudo News. (The last Perl 6 Weekly Blog: 2019.41 New Wineskins | Weekly changes in and around Perl 6.)
And a couple bonus videos (just mentally replace 'Perl 6' with 'Raku'):
Jonathan Worthington. Keynote: Perl 6 Concurrency.
Jonathan Worthington. Perl 6 performance update.
Raku /Perl 6 is an unbelievably powerful language, for reasons not the least of which is that it has a built-on LALR parser. Compare: 6900 lines of C code, 90 lines of Raku/Perl6.
It’s too bad that coders will never notice or care.
posted by 1970s Antihero at 2:55 PM on November 2, 2019 [9 favorites]
It’s too bad that coders will never notice or care.
posted by 1970s Antihero at 2:55 PM on November 2, 2019 [9 favorites]
Fool! Nothing of this world can harm me. For I am rAku, the Shogun of Sorrow, the Deliverer of Darkness, your new master. And you will bow to me!
posted by aramaic at 2:59 PM on November 2, 2019 [6 favorites]
posted by aramaic at 2:59 PM on November 2, 2019 [6 favorites]
This post omits a bit of context that had me scratching my head until I found it: Perl 6 is a distinct language from Perl 5, and when people refer to "Perl" they often mean Perl 5. The name change serves to distinguish the similar but distinct languages, and it's got nothing to do with e.g. distancing the language from a problematic owner (which is sadly what I assume when something like this is on MeFi)
posted by LSK at 3:11 PM on November 2, 2019 [17 favorites]
posted by LSK at 3:11 PM on November 2, 2019 [17 favorites]
Yeah, LSK... I feared I'd get into a wall-o-text of editorial stuff if I went to deeply into the explanations. Maybe later. I'm still sorta waiting for the name change stuff to filter down and the new order to get a foothold. Then I'll have to go back and check and edit my handful of now-Raku modules and at least do a s///g and probably rename some files to new extensions just to be all proper like.
posted by zengargoyle at 3:26 PM on November 2, 2019
posted by zengargoyle at 3:26 PM on November 2, 2019
I'd like to point out that the blockquote above is basically repeating the words of Jesus, which makes all this a bit strange to me. Specifically the verses Luke 5:36-39.
posted by hippybear at 3:27 PM on November 2, 2019
posted by hippybear at 3:27 PM on November 2, 2019
Larry was a missionary for a while at least, it's why he got into languages. It's no surprise.
posted by zengargoyle at 3:30 PM on November 2, 2019 [6 favorites]
posted by zengargoyle at 3:30 PM on November 2, 2019 [6 favorites]
Larry (aka TimToady)
If you're pondering why Wall is
I'd like to point out that the blockquote above is basically repeating the words of Jesus, which makes all this a bit strange to me. Specifically the verses Luke 5:36-39.
Meet Larry Wall.
If you're pondering why Wall is
TimToady, see TIMTOWTDI.
I'd like to point out that the blockquote above is basically repeating the words of Jesus, which makes all this a bit strange to me. Specifically the verses Luke 5:36-39.
Meet Larry Wall.
Wall's Christian faith has influenced some of the terminology of Perl, such as the name itself, a biblical reference to the "pearl of great price" (Matthew 13:46).[10] Similar references are the function name bless, and the organization of Raku (previously known as Perl 6) design documents with categories such as apocalypse and exegesis. Wall has also alluded to his faith when he has spoken at conferences, including a rather straightforward statement of his beliefs at the August 1997 Perl Conference and a discussion of Pilgrim's Progress at the YAPC (Yet Another Perl Conference) in June 2000.posted by zamboni at 3:31 PM on November 2, 2019 [4 favorites]
My immediate associations with Perl (I'm a web dev who started in 2001) is Unmaintainable Mess With No IDE.
So println debugging, more-than-one-way-to-do-it meaning learning a new subset of the language every time I read a new-to-me author's scripts, and regexes (which are painful enough to parse mentally at the best of times) used when simpler pattern matching would work just fine.
Is Raku different from that?
posted by Fraxas at 3:33 PM on November 2, 2019 [5 favorites]
So println debugging, more-than-one-way-to-do-it meaning learning a new subset of the language every time I read a new-to-me author's scripts, and regexes (which are painful enough to parse mentally at the best of times) used when simpler pattern matching would work just fine.
Is Raku different from that?
posted by Fraxas at 3:33 PM on November 2, 2019 [5 favorites]
meaning learning a new subset of the language every time I read a new-to-me author's scripts
A programmer friend of mine once said he could read some perl he wrote 3 weeks ago and wonder what drunken monkey had ever chosen that approach, but he could read some python he'd never seen before and think "oh, yeah, I remember writing that!"
posted by hippybear at 3:38 PM on November 2, 2019 [20 favorites]
A programmer friend of mine once said he could read some perl he wrote 3 weeks ago and wonder what drunken monkey had ever chosen that approach, but he could read some python he'd never seen before and think "oh, yeah, I remember writing that!"
posted by hippybear at 3:38 PM on November 2, 2019 [20 favorites]
It seems to me that whatever language is used in place of Perl these days — Python, I suppose; or perhaps Node.js —is used because it has the library support that Perl had in the Before-time, the Long-Long-Ago. As much as Perl is still beloved to me, if I were looking to bang out a script to do some little task to fill in the cracks between one system and another, I would use whatever language has the libraries that makes the job easy. Changing the name isn't going to change that.
posted by ob1quixote at 3:41 PM on November 2, 2019 [11 favorites]
posted by ob1quixote at 3:41 PM on November 2, 2019 [11 favorites]
Raku doubles down on all of that.
It theoretically makes regexes easier to write and understand, but in my experience, people’s ability to grok regular expressions is hit-or-miss in the first place.
posted by 1970s Antihero at 3:41 PM on November 2, 2019 [6 favorites]
It theoretically makes regexes easier to write and understand, but in my experience, people’s ability to grok regular expressions is hit-or-miss in the first place.
posted by 1970s Antihero at 3:41 PM on November 2, 2019 [6 favorites]
> A programmer friend of mine once said he could read some perl he wrote 3 weeks ago and wonder what drunken monkey had ever chosen that approach, but he could read some python he'd never seen before and think "oh, yeah, I remember writing that!"
Which, for me, results in "document your fucking code, because next time you look at it, you're going to want the clues"...
posted by mikelieman at 3:43 PM on November 2, 2019 [4 favorites]
Which, for me, results in "document your fucking code, because next time you look at it, you're going to want the clues"...
posted by mikelieman at 3:43 PM on November 2, 2019 [4 favorites]
(it's a joke)
posted by hippybear at 3:45 PM on November 2, 2019 [3 favorites]
posted by hippybear at 3:45 PM on November 2, 2019 [3 favorites]
The Three Virtues of a GREAT Programmer.
posted by zengargoyle at 3:46 PM on November 2, 2019 [5 favorites]
posted by zengargoyle at 3:46 PM on November 2, 2019 [5 favorites]
(I mean my programmer friend actually did say that, but it was a moment of humor not descriptive of his life in general.)
posted by hippybear at 3:46 PM on November 2, 2019 [1 favorite]
posted by hippybear at 3:46 PM on November 2, 2019 [1 favorite]
PHP is a minor evil perpetrated and created by incompetent amateurs, whereas Perl Raku is a great and insidious evil, perpetrated by skilled but perverted professionals.
posted by BigCalm at 4:06 PM on November 2, 2019 [13 favorites]
posted by BigCalm at 4:06 PM on November 2, 2019 [13 favorites]
I feel like it needs to be said that for all of the warts, modern programming languages owe a debt to Perl. If I’m not mistaken it was the first real open source programming language, it was the first to introduce the concept of a repository of modules. If I’m not mistaken Ruby drew a lot from Perl, and the python community learned a lot from Perl as well. People like to poke fun at it, but perl did a lot for the early web, and I hope that Larry and company are remembered fondly for all of that instead of the warts.
posted by jzb at 4:12 PM on November 2, 2019 [21 favorites]
posted by jzb at 4:12 PM on November 2, 2019 [21 favorites]
Will renaming it Raku make it run faster? Because it's by far the slowest of the scripting languages, sometimes by an order of magnitude. You would have thought that 20 years of dicking around with it would have made it useful. As is, it's an immensely pleased-with-itself curio, of no practical use to anyone.
I'm kind of glad of the rename, 'cos Raku/Perl 6 never felt like Perl to me. I made my living with Perl from 97-2004. It was light, it was fast; you had the freedom to do beautiful things in horrible ways. It continued to grow, gaining perhaps the best "do what I mean" Unicode handling of any scripting language. But it stayed much the same at heart. Raku was always this weird thing that did things almost - but not quite - exactly unlike Perl.
At least the rename will avoid the Python 2 / Python 3 nonsense.
posted by scruss at 4:20 PM on November 2, 2019 [4 favorites]
I'm kind of glad of the rename, 'cos Raku/Perl 6 never felt like Perl to me. I made my living with Perl from 97-2004. It was light, it was fast; you had the freedom to do beautiful things in horrible ways. It continued to grow, gaining perhaps the best "do what I mean" Unicode handling of any scripting language. But it stayed much the same at heart. Raku was always this weird thing that did things almost - but not quite - exactly unlike Perl.
At least the rename will avoid the Python 2 / Python 3 nonsense.
posted by scruss at 4:20 PM on November 2, 2019 [4 favorites]
MetaFilter: You would have thought that 20 years of dicking around with it would have made it useful.
posted by hippybear at 4:22 PM on November 2, 2019 [21 favorites]
posted by hippybear at 4:22 PM on November 2, 2019 [21 favorites]
→ Comma - The Raku IDE.
200 MB download, though. That's one big-ass editor.
(as an elderly Perl programmer, I do reserve the right to use late-90's postfix ass notation)
posted by scruss at 4:26 PM on November 2, 2019 [1 favorite]
200 MB download, though. That's one big-ass editor.
(as an elderly Perl programmer, I do reserve the right to use late-90's postfix ass notation)
posted by scruss at 4:26 PM on November 2, 2019 [1 favorite]
> 200 MB download, though. That's one big-ass editor
I'm terrified to tell you the size of my VC Code + extensions install.
posted by protocoach at 4:30 PM on November 2, 2019 [10 favorites]
I'm terrified to tell you the size of my VC Code + extensions install.
posted by protocoach at 4:30 PM on November 2, 2019 [10 favorites]
In other words, Perl still exists for the same reason COBOL still exists.
As someone who used to do a lot of Perl and has now moved on to Python (for money) and Ruby (for fun), I've given this a lot of thought and there are still a few places where Perl is the right choice:
1. "perl [-np] -e " makes a better sed or awk and is an excellent replacement for those commands on the command line or in scripts.
2. There's a point between shell scripts and Python where Perl is the better tool. It's closer to the Unix environment than Python and so just kind of fits better. If you're trying to (e.g.) download, configure and compile software packages from source on a variety of platforms that don't consistently have compatible shells, Perl is the best tool
3. When you've done 1 or 2 as a one-off that has evolved into an important part of your business processes, it is relatively easy to refactor those into maintainable programs.
4. Stock perl installations--even very old versions--are incredibly powerful and ubiquitous. If you need something that runs everywhere (e.g. cross platform config scripts), a Perl script that's been tested against a ten year old Perl release will be fine.
posted by suetanvil at 4:42 PM on November 2, 2019 [14 favorites]
As someone who used to do a lot of Perl and has now moved on to Python (for money) and Ruby (for fun), I've given this a lot of thought and there are still a few places where Perl is the right choice:
1. "perl [-np] -e " makes a better sed or awk and is an excellent replacement for those commands on the command line or in scripts.
2. There's a point between shell scripts and Python where Perl is the better tool. It's closer to the Unix environment than Python and so just kind of fits better. If you're trying to (e.g.) download, configure and compile software packages from source on a variety of platforms that don't consistently have compatible shells, Perl is the best tool
3. When you've done 1 or 2 as a one-off that has evolved into an important part of your business processes, it is relatively easy to refactor those into maintainable programs.
4. Stock perl installations--even very old versions--are incredibly powerful and ubiquitous. If you need something that runs everywhere (e.g. cross platform config scripts), a Perl script that's been tested against a ten year old Perl release will be fine.
posted by suetanvil at 4:42 PM on November 2, 2019 [14 favorites]
Except most of the perk implementations I run into are more like 20 years old.... something like 5.8.mumble. Which is a heck of a language, but...
posted by wotsac at 4:59 PM on November 2, 2019
posted by wotsac at 4:59 PM on November 2, 2019
Some years ago I was working in a shop with lots of Perl, including one of the Perl 6 fanatics who was developing core code, and I was enthusiastic and kept trying to do something in Perl 6, either professionally or for personal projects. I kept running into either "that doesn't work yet", or "that works differently this week". Meanwhile, the Perl 5 folk kept improving an environment that worked.
And as I saw Perl 6 evolve, it seemed like people were excited about the sorts of language features that lead to the sorts of unmaintainable side-effect ridden systems that can make Perl 5 and C++ projects complete nightmares to work on.
I'm writing this at a Python conference. I'm reminded that when I first wanted to learn Python I made myself not write quick one-offs in Perl, and it was super hard because it was so easy to
I love Perl. I've often said that I don't care about the alleged readability issues because it's so fast to just rewrite stuff. But the culture that was driving Perl has sent it down paths that eventually put form over function when trying to build larger systems that weren't just decoupled shell scripts, and I suspect this name change is too late to save it.
posted by straw at 5:15 PM on November 2, 2019 [4 favorites]
And as I saw Perl 6 evolve, it seemed like people were excited about the sorts of language features that lead to the sorts of unmaintainable side-effect ridden systems that can make Perl 5 and C++ projects complete nightmares to work on.
I'm writing this at a Python conference. I'm reminded that when I first wanted to learn Python I made myself not write quick one-offs in Perl, and it was super hard because it was so easy to
perl -le '...'. But it's clear that the evolutionary path that Perl 6 (and Moose and all sorts of other syntactic "helpers" that led to atrocious side-effects) were leading the language down destroyed the brand.I love Perl. I've often said that I don't care about the alleged readability issues because it's so fast to just rewrite stuff. But the culture that was driving Perl has sent it down paths that eventually put form over function when trying to build larger systems that weren't just decoupled shell scripts, and I suspect this name change is too late to save it.
posted by straw at 5:15 PM on November 2, 2019 [4 favorites]
It’s too bad that coders will never notice or care.
I noticed, but I don't care. The sacrifice of legibility for conciseness bugs the shit out of me. Like every not-pos ide does autocomplete, and every modern compiler does it's job. Source-code length is a pretty weak metric for language 'goodness'.
posted by j_curiouser at 5:28 PM on November 2, 2019 [3 favorites]
I noticed, but I don't care. The sacrifice of legibility for conciseness bugs the shit out of me. Like every not-pos ide does autocomplete, and every modern compiler does it's job. Source-code length is a pretty weak metric for language 'goodness'.
posted by j_curiouser at 5:28 PM on November 2, 2019 [3 favorites]
You know, there were a few rough years there in the Python 2 to 3 transition. It damn near killed the language. But we finally got there once someone figured out a sane set of tools for transitioning code and now it's mostly dead.
Perl did not survive Perl 6. It never well. Maybe this new thing called Raku will find a niche but I'm not betting on it.
(My blog still runs on a Perl 5 script. It still works OK, although I was vexed when a breaking change in Perl 5.26 finally worked its way in and broke it. Easy enough to fix at least.)
posted by Nelson at 5:35 PM on November 2, 2019 [4 favorites]
Perl did not survive Perl 6. It never well. Maybe this new thing called Raku will find a niche but I'm not betting on it.
(My blog still runs on a Perl 5 script. It still works OK, although I was vexed when a breaking change in Perl 5.26 finally worked its way in and broke it. Easy enough to fix at least.)
posted by Nelson at 5:35 PM on November 2, 2019 [4 favorites]
and now it's mostly dead.
mostly done. Argh.
posted by Nelson at 5:54 PM on November 2, 2019 [3 favorites]
mostly done. Argh.
posted by Nelson at 5:54 PM on November 2, 2019 [3 favorites]
As a programmer who works mostly in Ruby but has done some stuff in Python and liked it very much, I'm not sure I find Perl that compelling. I'm not sure I find a renamed Perl that compelling either.
posted by Merus at 5:57 PM on November 2, 2019 [2 favorites]
posted by Merus at 5:57 PM on November 2, 2019 [2 favorites]
It's not perfect, but Raku has a really good 'parsed by itself' sort of implementation that leads to having what they call 'braids' which eases into 'slang' (sub languages) which combined with a good FFI interface (NativeCall) leads to a conclusion.... You can run Python code/modules and Perl code/modules directly from Raku. Most Raku folk now are sorta not spending time on say outputting graphics because they can just use matplotlib. You create a Raku matplotlib object (Python) and treat it as any other object and do your stuff in Raku and use that object to do the fancy graphics. You can use Perl modules if there's one that does what you need. (this is all libFOO.so type imbedding of the interpreter and IPC and translation brewhaha, but...).
Itch.scratch() | Damian Conway [blogs.perl.org] is a bit of "you can totally do that if you want".
On the Unicode side of things, Raku is even better than Perl. It even supports graphemes where you're random 'Zalgo' will be 5 characters (Raku creates virtual codepoints for combining characters and can go back and forth at will).
Speed-wise, it's getting better... It's a bit of development strategy. Raku (unlike Perl) is defined by a specification of tests. Pass the tests, and presto you're a cromulent Raku implementation. But they started with the syntax and grammar and tests and did the easiest, cleanest thing that would work. Like using CS101 algorithms. One thing I've noticed over the years is that eventually someone goes back and replaces bits of code (Raku is written in Raku (mostly)) with CS403 algorithms. The virtual machine is heading along JVM lines where it was dog-slow but now, not so much, and keeps getting better. Pass the tests first, make it faster second. Almost every week, somebody makes some bit in the Raku part faster. And the MoarVM backend keeps getting things like speculative optimization and replacing hot paths with x_86 machine code. It used to be dog-slow, now not so much (and faster than Python/Perl/Ruby in some cases, slower in others. There's also a JVM backend, and I believe a Javascript backend that tend to be a couple of months behind mainline development.
I can see the MoarVM backend getting fast enough. And the way modules and code are handled are ripe for being able to ship a single binary (ala Go). It's just that there are not enough TUITs to happen as fast as I would like.
posted by zengargoyle at 6:15 PM on November 2, 2019 [10 favorites]
Itch.scratch() | Damian Conway [blogs.perl.org] is a bit of "you can totally do that if you want".
On the Unicode side of things, Raku is even better than Perl. It even supports graphemes where you're random 'Zalgo' will be 5 characters (Raku creates virtual codepoints for combining characters and can go back and forth at will).
Speed-wise, it's getting better... It's a bit of development strategy. Raku (unlike Perl) is defined by a specification of tests. Pass the tests, and presto you're a cromulent Raku implementation. But they started with the syntax and grammar and tests and did the easiest, cleanest thing that would work. Like using CS101 algorithms. One thing I've noticed over the years is that eventually someone goes back and replaces bits of code (Raku is written in Raku (mostly)) with CS403 algorithms. The virtual machine is heading along JVM lines where it was dog-slow but now, not so much, and keeps getting better. Pass the tests first, make it faster second. Almost every week, somebody makes some bit in the Raku part faster. And the MoarVM backend keeps getting things like speculative optimization and replacing hot paths with x_86 machine code. It used to be dog-slow, now not so much (and faster than Python/Perl/Ruby in some cases, slower in others. There's also a JVM backend, and I believe a Javascript backend that tend to be a couple of months behind mainline development.
I can see the MoarVM backend getting fast enough. And the way modules and code are handled are ripe for being able to ship a single binary (ala Go). It's just that there are not enough TUITs to happen as fast as I would like.
posted by zengargoyle at 6:15 PM on November 2, 2019 [10 favorites]
1. "perl [-np] -e " makes a better sed or awk and is an excellent replacement for those commands on the command line or in scripts.
At my current job I have a policy of using those Perl incantations as necessary, and documenting what I did for the benefit of anyone who might need the same thing, but never, ever using a Perl one liner in a script that's to be run non-interactively.
If your processes need to run perl [-np], then they need refactoring.
(In my lazy, hubris filled opinion of course.
posted by ocschwar at 6:36 PM on November 2, 2019 [1 favorite]
At my current job I have a policy of using those Perl incantations as necessary, and documenting what I did for the benefit of anyone who might need the same thing, but never, ever using a Perl one liner in a script that's to be run non-interactively.
If your processes need to run perl [-np], then they need refactoring.
(In my lazy, hubris filled opinion of course.
posted by ocschwar at 6:36 PM on November 2, 2019 [1 favorite]
Wha?
$ zcat /usr/share/i18n/charmaps/UTF-8.gz | perl -ne '$x=$_ if rand()<(1/$.);END{print$x}' # pick a random line of UTF-8 info via Resevoir Sampling.
Sorry, I recently found out that while that is a way of picking a random line from a stream or file without knowing the length or reading it twice to find out happens to be a degenerate case of Reservoir sampling. I'm not going to refactor it. :P
posted by zengargoyle at 7:22 PM on November 2, 2019 [2 favorites]
$ zcat /usr/share/i18n/charmaps/UTF-8.gz | perl -ne '$x=$_ if rand()<(1/$.);END{print$x}' # pick a random line of UTF-8 info via Resevoir Sampling.
Sorry, I recently found out that while that is a way of picking a random line from a stream or file without knowing the length or reading it twice to find out happens to be a degenerate case of Reservoir sampling. I'm not going to refactor it. :P
posted by zengargoyle at 7:22 PM on November 2, 2019 [2 favorites]
Some years ago I was working in a shop with lots of Perl, including one of the Perl 6 fanatics who was developing core code, and I was enthusiastic and kept trying to do something in Perl 6, either professionally or for personal projects. I kept running into either "that doesn't work yet", or "that works differently this week". Meanwhile, the Perl 5 folk kept improving an environment that worked.
And as I saw Perl 6 evolve, it seemed like people were excited about the sorts of language features that lead to the sorts of unmaintainable side-effect ridden systems that can make Perl 5 and C++ projects complete nightmares to work on.
The thing here is that in the end, Raku is defined by the test suite. I had the same issues once where things broke and I was irate and the answer was along the lines of "that wasn't in the test suite". It was a convenience, but not set in stone yet. It hadn't been decided just how to handle that thing yet.
Unlike Perl which is defined by what the 'perl' (hunk of C code can parse and run) Perl interpreter can do, Raku is in the end defined by what is in the specification tests. If you wish to write another implementation that can pass the specification tests...you are BDFL granted the right to call yourself an implementation of Raku. TDD gone mad maybe. The goal here is to as much as humanly possible to have a Raku v6.c always work, and a Raku v6.d and v6.e and it's all lexically scoped and will always be "passes that version of the specification".
It's an ideal that is aimed for. Much like the "you can probably still run Perl 5.8 code on Perl 5.30". Every reasonable effort is made to make that backwards and forwards compatibility a reality. don't do things not in the spec tests or the documentation even if they do work now. Even Perl had this moment with Hash Key Randomization where the docs said "don't rely on this" but people did anyways and got pissed when it changed.
Just like Perl, Raku also has started to settle down into predictable advancement with backwards compatibility. If you're holding on to 5 years ago thinking, It's time to take a another look. Both are putting out new releases on a regular-ish schedule, and both are just getting faster, and dare I say... both are getting down to targeting WebASM (or at least javascript).
Hauke Dämpfling. WebPerl — Run Perl in the Browser! with bonus... Lightning Talk (probably more interesting).
Keep an open mind. They're not dead, take another look. I don't want to go on the cart.
posted by zengargoyle at 10:03 PM on November 2, 2019 [3 favorites]
And as I saw Perl 6 evolve, it seemed like people were excited about the sorts of language features that lead to the sorts of unmaintainable side-effect ridden systems that can make Perl 5 and C++ projects complete nightmares to work on.
The thing here is that in the end, Raku is defined by the test suite. I had the same issues once where things broke and I was irate and the answer was along the lines of "that wasn't in the test suite". It was a convenience, but not set in stone yet. It hadn't been decided just how to handle that thing yet.
Unlike Perl which is defined by what the 'perl' (hunk of C code can parse and run) Perl interpreter can do, Raku is in the end defined by what is in the specification tests. If you wish to write another implementation that can pass the specification tests...you are BDFL granted the right to call yourself an implementation of Raku. TDD gone mad maybe. The goal here is to as much as humanly possible to have a Raku v6.c always work, and a Raku v6.d and v6.e and it's all lexically scoped and will always be "passes that version of the specification".
It's an ideal that is aimed for. Much like the "you can probably still run Perl 5.8 code on Perl 5.30". Every reasonable effort is made to make that backwards and forwards compatibility a reality. don't do things not in the spec tests or the documentation even if they do work now. Even Perl had this moment with Hash Key Randomization where the docs said "don't rely on this" but people did anyways and got pissed when it changed.
Just like Perl, Raku also has started to settle down into predictable advancement with backwards compatibility. If you're holding on to 5 years ago thinking, It's time to take a another look. Both are putting out new releases on a regular-ish schedule, and both are just getting faster, and dare I say... both are getting down to targeting WebASM (or at least javascript).
Hauke Dämpfling. WebPerl — Run Perl in the Browser! with bonus... Lightning Talk (probably more interesting).
Keep an open mind. They're not dead, take another look. I don't want to go on the cart.
posted by zengargoyle at 10:03 PM on November 2, 2019 [3 favorites]
My first reaction is to think that this is a mistake. Everyone knows what Perl is. (And how to say it - are the vowels in "Raku" short, or long? Where is it stressed? ) But no one has ever heard of your new name, and this means that you are starting over in terms of people's perception of your credentials as a serious platform.
But, avoiding the Python 2/3 kind of situation seems like a powerful consideration. Also, if the language os so distinct from Perl 5, it's probably more honest to change the name.
I don't really have a dog in this fight, I might add.
posted by thelonius at 6:27 AM on November 3, 2019 [1 favorite]
But, avoiding the Python 2/3 kind of situation seems like a powerful consideration. Also, if the language os so distinct from Perl 5, it's probably more honest to change the name.
I don't really have a dog in this fight, I might add.
posted by thelonius at 6:27 AM on November 3, 2019 [1 favorite]
Should've gone with Javaraku
posted by sammyo at 7:26 AM on November 3, 2019 [5 favorites]
posted by sammyo at 7:26 AM on November 3, 2019 [5 favorites]
I've been slinging some form of code for between one and two decades and I always assumed "Perl 6" was just the newest version of that write-only language I messed around with in my early days, like "Java 8". That is, a revision with some added syntactic sugar (but isn't Perl almost entirely syntactic sugar?), but still fundamentally the same thing.
It wasn't until I learned of the rename that I discovered no, this is actually an entirely new and unique language. I wouldn't have considered learning Perl 6 any more than I would have considered learning Fortran or PowerBuilder. (Okay, I did learn PowerBuilder at one point, but it's a long story.)
So from my limited perspective: Why the heck was it even called Perl 6 in the first place? Were they trying to recreate the Python 2/3 debacle?
posted by The Lurkers Support Me in Email at 8:13 AM on November 3, 2019 [2 favorites]
It wasn't until I learned of the rename that I discovered no, this is actually an entirely new and unique language. I wouldn't have considered learning Perl 6 any more than I would have considered learning Fortran or PowerBuilder. (Okay, I did learn PowerBuilder at one point, but it's a long story.)
So from my limited perspective: Why the heck was it even called Perl 6 in the first place? Were they trying to recreate the Python 2/3 debacle?
posted by The Lurkers Support Me in Email at 8:13 AM on November 3, 2019 [2 favorites]
I've never written Perl (or Raku), but I sent this FPP to my Perl-programming friend and they said they enjoyed the comments here, so thanks! :)
posted by daisyk at 8:15 AM on November 3, 2019
posted by daisyk at 8:15 AM on November 3, 2019
The Lurkers: Perl 5 came out in 1994, IIRC. Then Perl 5.001 added OOP capabilities (via references) and a whole shitload of development exploded into the libraries, via CPAN (the Combined Perl Archive Network). Developing libraries with well-designed test harnesses occupied the dev community for about 5 years. Finally, Perl 6 started around 1998-1999 as "Larry is discontented with Perl 5.x, wants to add new features which may subtly break things" (a la Python 2/3). But then feature creep set in, and a couple of years later we had a language driven by specification rather than implementation and he was looking to build a language with a full-blown parser-generator so you could use it for spinning up simple domain-specific sublanguages ... then shit got even more complicated, Perl 6 turned into a moving target, and instead of it hitting release level by 2000-2002 it was still ticking along in development and the actual users wanted something stable and usable now. The language had de facto forked already but Larry didn't want to rename "Perl 6", so the public perception was that Perl had hit version 5 and stagnated.
Remember that the Python 2/3 debacle happened in 2008. So the Perl 5/6 debacle predated it. In fact, it's possible Guido was able to body-swerve the worst effects on the Python community by looking at Perl's long nightmare.
Caveat: I quit doing this stuff for a living around 2002.
posted by cstross at 8:40 AM on November 3, 2019 [10 favorites]
Remember that the Python 2/3 debacle happened in 2008. So the Perl 5/6 debacle predated it. In fact, it's possible Guido was able to body-swerve the worst effects on the Python community by looking at Perl's long nightmare.
Caveat: I quit doing this stuff for a living around 2002.
posted by cstross at 8:40 AM on November 3, 2019 [10 favorites]
PS: I've met Larry. He's a lovely guy, but he has absolutely not one single marketing bone in his body. Just sayin'.
posted by cstross at 8:42 AM on November 3, 2019 [7 favorites]
posted by cstross at 8:42 AM on November 3, 2019 [7 favorites]
I attended the O'Reilly Open Source Convention (OSCON) in 2006. It was the first "real" development-oriented conference I ever attended, and I was excited to see both Larry Wall and Guido van Rossum on the schedule. At that time, I was just finding my way as a Python developer after years of professional experience doing mostly C and Java with a fair amount of Perl on the side. My notes from the sessions captured my feeling that Larry and the rest of the Perl stewards were asking quite a lot of prospective developers:
(Still never really found a reason to get into Ruby, though.)
posted by tonycpsu at 9:58 AM on November 3, 2019 [2 favorites]
11:35am - 12:20pmAs I became more proficient in Python, Perl seemed superfluous and arcane when it was once indispensible. It still took a very long time for me to switch to writing things in Python 3 first -- just within the last couple of years, actually -- but at least there was a migration path for most of the common changes. Perl 6 just seemed to always be a playground for new cool language things first and an attempt to modernize Perl second.
Python 30001:45pm - 2:30pm
- An informative, concise, and enjoyable presentation on what's on the Python roadmap in the next 1-2 years.
- I like the balance that's being struck between cleaning out the closet and maintaining compatibility. While some changes will have to be made to older Python code, it appears they're keeping most of the language intact.
Perl 6 Update
- It appears that the Perl 6 gurus are at least aware of Perl 5's many shortcomings, and are taking steps to address them.
- My only question is whether these improvements will come soon enough to prevent Perl from being made irrelevant by Python and Ruby.
- Most of the proposed changes make a lot of sense, but the syntax is getting even uglier.
(Still never really found a reason to get into Ruby, though.)
posted by tonycpsu at 9:58 AM on November 3, 2019 [2 favorites]
Ha, it figures that I had the chronology of the Python 2/3 thing mixed up. I had no idea the origins of Raku stretched so far back. Thanks for the background!
posted by The Lurkers Support Me in Email at 10:30 AM on November 3, 2019
posted by The Lurkers Support Me in Email at 10:30 AM on November 3, 2019
Perl 5/6 was a debacle. Python 2/3 was a minor speed bump. I say this as someone who loved Perl 5 back in the day.
Still got Go and F# on my next languages list, I don't think Raku will be supplanting them anytime soon.
I maintain that R is the new Perl, spawning mountains of unmaintainable code and requiring layered onion packages to smooth out the core language's deficiencies (e.g. tidyverse is the new Moose).
posted by benzenedream at 11:01 AM on November 3, 2019 [1 favorite]
Still got Go and F# on my next languages list, I don't think Raku will be supplanting them anytime soon.
I maintain that R is the new Perl, spawning mountains of unmaintainable code and requiring layered onion packages to smooth out the core language's deficiencies (e.g. tidyverse is the new Moose).
posted by benzenedream at 11:01 AM on November 3, 2019 [1 favorite]
Raku is pretty much Japanese in pronounciation and meaning. And is full of some word play as one would expect. The current main implementation is named 'rakudo' which is a shortened combination of rakuda 駱駝 and dō 道. rakuda is a camel, and dō is 'the way of'. So it's "the way of the camel" but shortened. The shortening makes it raku do. which is 'paradise' 楽土 and raku in this case is comfort/ease (and also a style of pottery). So I can see how/why they decided to just call the language Raku. I'm only slightly miffed at the name change, mostly from just siding with Larry for so long about keeping Perl 6, but once he did change his mind... I guess I have to be OK with it. I just think it's going to make things complicated for a long while with all of the old Perl 6 books and web pages and videos and all that history.
The big bump that sucked a bunch of time out of development back in the day wasn't Raku itself... It was the original idea for the VM that was going to run the codes. It was called Parrot and they intended for it to be a VM that would be suitable for *all* sorts of dynamic languages. Run Python, TCL, Ruby, Javascript, etc. Unlike say the JavaVM Parrot was going to be designed with dynamic languages in mind. Parrot was a horrorshow.
This changed a good while back when someone (Jonathan I believe) started a skunk-works project to write a VM that was just going to support what Raku would need and nothing else. Parrot is no more, long live Moar (VM). That's when things really started to take off. It wasn't painfully slow to build or run. It didn't have to be overly generic. Anyways, IMHO the biggest delay in Raku seeing the light of day was that damn Parrot.
posted by zengargoyle at 12:45 PM on November 3, 2019 [5 favorites]
The big bump that sucked a bunch of time out of development back in the day wasn't Raku itself... It was the original idea for the VM that was going to run the codes. It was called Parrot and they intended for it to be a VM that would be suitable for *all* sorts of dynamic languages. Run Python, TCL, Ruby, Javascript, etc. Unlike say the JavaVM Parrot was going to be designed with dynamic languages in mind. Parrot was a horrorshow.
This changed a good while back when someone (Jonathan I believe) started a skunk-works project to write a VM that was just going to support what Raku would need and nothing else. Parrot is no more, long live Moar (VM). That's when things really started to take off. It wasn't painfully slow to build or run. It didn't have to be overly generic. Anyways, IMHO the biggest delay in Raku seeing the light of day was that damn Parrot.
posted by zengargoyle at 12:45 PM on November 3, 2019 [5 favorites]
I feel like someone needs to speak up in defense of Perl 5. The language itself isn't bad at all. There are several others that are much worse in many ways, yet remain popular today. The problem is how it is used, not how it is designed. The "design" (quotes used to express uncertainty about the level of intention involved) does allow for inscrutable code and it also allows for easily maintainable code.
See, Perl is really two languages in one. The first is more akin to a beefed up shell script language, written mainly for the ability to quickly automate repetitive one off tasks with a minimum of keystrokes. The other is an actual programming language suitable for developing system utilities and user-facing software.
Both work well in their respective domains. The problem comes in when the quick and dirty one off ends up being made permanent, requiring ongoing maintenance or when familiarity results in the use of the inscrutable side effect laden bits where they aren't appropriate.
posted by wierdo at 5:17 PM on November 3, 2019 [2 favorites]
See, Perl is really two languages in one. The first is more akin to a beefed up shell script language, written mainly for the ability to quickly automate repetitive one off tasks with a minimum of keystrokes. The other is an actual programming language suitable for developing system utilities and user-facing software.
Both work well in their respective domains. The problem comes in when the quick and dirty one off ends up being made permanent, requiring ongoing maintenance or when familiarity results in the use of the inscrutable side effect laden bits where they aren't appropriate.
posted by wierdo at 5:17 PM on November 3, 2019 [2 favorites]
I wrote some Perl scripts in the early 2000s that are still used. The language choice was reasonable then, but today I really wish they were in Python. I may rewrite them one day. Trying to read and modify old Perl code is a nightmare, and I was only ever doing really simple text processing stuff. I can't imagine what it's like to read and modify "advanced" Perl.
posted by nnethercote at 7:02 PM on November 3, 2019
posted by nnethercote at 7:02 PM on November 3, 2019
Again, it depends on what you mean by "advanced." If that means "90 character long regex with lookbacks, lookaheads, and positional variables wrapped in a function to hide the hairy bits," then yeah, it sucks to maintain. If by "advanced" you mean the OOish parts, modularization, and that sort of stuff, I can't really agree.
The advantages Python has in readability come from throwing away half of what Perl 5 was used for and forcing the use of reasonably sane formatting choices. Those attributes encourage, but do not require, the sort of forethought that results in code being maintainable.
That said, my opinion is largely shaped by the experience of studying their respective, somewhat canonical, O'Reilly tomes very early on in my use of each. Someone whose foundational experience with them was mostly shaped by learning from random found examples, documentation, and trial and error would naturally have a very different way of seeing things, especially if they also had to clean up other people's messes, which is something I don't do much of at all.
posted by wierdo at 8:51 PM on November 3, 2019
The advantages Python has in readability come from throwing away half of what Perl 5 was used for and forcing the use of reasonably sane formatting choices. Those attributes encourage, but do not require, the sort of forethought that results in code being maintainable.
That said, my opinion is largely shaped by the experience of studying their respective, somewhat canonical, O'Reilly tomes very early on in my use of each. Someone whose foundational experience with them was mostly shaped by learning from random found examples, documentation, and trial and error would naturally have a very different way of seeing things, especially if they also had to clean up other people's messes, which is something I don't do much of at all.
posted by wierdo at 8:51 PM on November 3, 2019
I think the problem, ultimately, is that quick-and-dirty one offs that work have an alarming habit of becoming permanent, so a language where you can bang something together and it'll work but you need to do it completely differently to be maintainable is a language with a design flaw. PHP had the opposite problem - it was easy to get something simple actually working, but extending it proved much more difficult than it needed to be because of design flaws you didn't notice at first.
posted by Merus at 10:17 PM on November 3, 2019
posted by Merus at 10:17 PM on November 3, 2019
See, Perl is really two languages in one. The first is more akin to a beefed up shell script language, written mainly for the ability to quickly automate repetitive one off tasks with a minimum of keystrokes. The other is an actual programming language suitable for developing system utilities and user-facing software.
I worked for a company that had ... well I don't know how it compares to all other codebases, but certainly the largest I'd ever heard of. Millions of lines of perl code, developed over about a 20 year period starting ~1998. They had perl gurus like you couldn't imagine -- people who knew deep internals, added all sorts of custom modules, tried to make sense of Perl's OO capabilities, etc. Ungodly man-hours were put into internal Perl knowledge and tooling.
The codebase was of course a total nightmare, and the company is presently hoping to replatform as much as possible because it's dragging them into the abyss like an anchor.
The idea of Perl being used for anything larger than a one-off script gives me hives.
posted by tocts at 5:42 AM on November 4, 2019 [5 favorites]
I worked for a company that had ... well I don't know how it compares to all other codebases, but certainly the largest I'd ever heard of. Millions of lines of perl code, developed over about a 20 year period starting ~1998. They had perl gurus like you couldn't imagine -- people who knew deep internals, added all sorts of custom modules, tried to make sense of Perl's OO capabilities, etc. Ungodly man-hours were put into internal Perl knowledge and tooling.
The codebase was of course a total nightmare, and the company is presently hoping to replatform as much as possible because it's dragging them into the abyss like an anchor.
The idea of Perl being used for anything larger than a one-off script gives me hives.
posted by tocts at 5:42 AM on November 4, 2019 [5 favorites]
FWIW, I once worked on what I call (completely objectively and accurately) the World's Worst Perl Program. This was a quarter million lines of code, much of which created by copying an existing module subtree and changing a few lines of code.
The thing is, if you went through class by class, module by module, function by function and translated it to Python, it would have been just as bad. All of the problems were not syntax abuse; they were the usual terrible things bad programmers do in any language. The horrible, horrible Python programs I worked on later in my career were less bad only because they were shorter.
Perl's syntax is easier to abuse but all that means is you can detect bad Perl code earlier. It's easy to avoid the worst parts of it: just buy Damien Conway's Perl Best Practices and follow it religiously, minus the parts that are wrong.
posted by suetanvil at 9:04 AM on November 4, 2019 [1 favorite]
The thing is, if you went through class by class, module by module, function by function and translated it to Python, it would have been just as bad. All of the problems were not syntax abuse; they were the usual terrible things bad programmers do in any language. The horrible, horrible Python programs I worked on later in my career were less bad only because they were shorter.
Perl's syntax is easier to abuse but all that means is you can detect bad Perl code earlier. It's easy to avoid the worst parts of it: just buy Damien Conway's Perl Best Practices and follow it religiously, minus the parts that are wrong.
posted by suetanvil at 9:04 AM on November 4, 2019 [1 favorite]
I mean ... maybe?
I would totally agree with the statement: "you can write maintainable or unmaintainable code in any language"
I would strenuously disagree with the statement: "it's equally as easy to write maintainable or unmaintainable code in every language"
How easy it is to write maintainable code and how easy it is to accidentally write unmaintainable code are both, in my experience, spectrums. And for me, Perl falls on the bad end of both of those spectrums -- it takes a lot of effort to write maintainable code, and it's really easy to create an unmaintainable mess.
I first learned Perl from the camel book in ... '97? '98? I still use it on occasion. If I'm dealing with an issue that could probably be solved by fancy applications across sed + awk + xargs + a bunch of other tools to do some one-time thing, I can probably do it faster in Perl.
I still don't want to maintain anything of size in it, though.
posted by tocts at 9:11 AM on November 4, 2019 [1 favorite]
I would totally agree with the statement: "you can write maintainable or unmaintainable code in any language"
I would strenuously disagree with the statement: "it's equally as easy to write maintainable or unmaintainable code in every language"
How easy it is to write maintainable code and how easy it is to accidentally write unmaintainable code are both, in my experience, spectrums. And for me, Perl falls on the bad end of both of those spectrums -- it takes a lot of effort to write maintainable code, and it's really easy to create an unmaintainable mess.
I first learned Perl from the camel book in ... '97? '98? I still use it on occasion. If I'm dealing with an issue that could probably be solved by fancy applications across sed + awk + xargs + a bunch of other tools to do some one-time thing, I can probably do it faster in Perl.
I still don't want to maintain anything of size in it, though.
posted by tocts at 9:11 AM on November 4, 2019 [1 favorite]
It usually seems to me that most people who hate Perl are those who stopped in the early aughts and switched to Python or Ruby. There was a big stall there between Perl 5.8 and then finally a 5.10, the .12, .14 where they got back on yearly releases and are now at 5.30. A lot of those changes were wart-removal-syntax. The thing is that a lot of Perl is system sort of code using system perl and system modules and you can't touch those, and you have to do least common denominator and use only the ancient perl of RHEL 6 and Solaris 10 or something like that. Common Perl programmers often *have* to keep using a bit of ugly just because they can't go and make sure 5.28 is available on every system just so they can do things wart-free. The same thing happens in CPAN where developers try to support the oldest perl they can get away with. Only a few can use you're shiny module if it requires a perl that's only 4 years old...
On the other hand, when you can do that like you're building an app to deploy to AWS or Heroku or Docker and you can use a recent enough perl (maybe a year behind just to avoid the new). Well, then you can avoid some warts and you can do the same thing Python and Ruby and Java applications tend to do where they package up the whole kit-and-kaboodle into one directory and have it checked by travis and have their own perl, their own install of CPAN modules that they use, their own modules, their own tests, their own perltidy rules, their own perlcritic rules, etc.
Sure, there's old stuff that everybody remembers from way back when... and one of Perl's strengths is that it probably still works. Might throw some warnings, or some thing may have finally been deprecated after more than a decade, but in general... still works.
I'm not sure if other languages do this, but Perl core devs and such have smoketesters where they build/test a large chunk of the most used and referenced modules on CPAN with every dev build and before release. One of the benefits of putting your module on CPAN is that's you'll probably get an email if your tests will fail with the new release of perl.
On the whole, I've found the readability and obviousness of Perl code to be proportional to the freedom of the developers to not be stuck having to use an ancient version for whatever reason.
posted by zengargoyle at 1:51 PM on November 4, 2019 [1 favorite]
On the other hand, when you can do that like you're building an app to deploy to AWS or Heroku or Docker and you can use a recent enough perl (maybe a year behind just to avoid the new). Well, then you can avoid some warts and you can do the same thing Python and Ruby and Java applications tend to do where they package up the whole kit-and-kaboodle into one directory and have it checked by travis and have their own perl, their own install of CPAN modules that they use, their own modules, their own tests, their own perltidy rules, their own perlcritic rules, etc.
Sure, there's old stuff that everybody remembers from way back when... and one of Perl's strengths is that it probably still works. Might throw some warnings, or some thing may have finally been deprecated after more than a decade, but in general... still works.
I'm not sure if other languages do this, but Perl core devs and such have smoketesters where they build/test a large chunk of the most used and referenced modules on CPAN with every dev build and before release. One of the benefits of putting your module on CPAN is that's you'll probably get an email if your tests will fail with the new release of perl.
On the whole, I've found the readability and obviousness of Perl code to be proportional to the freedom of the developers to not be stuck having to use an ancient version for whatever reason.
posted by zengargoyle at 1:51 PM on November 4, 2019 [1 favorite]
No other language community has anything at all like CPAN Testers. That — and most of the other services that are built on top of the CPAN infrastructure, are what I miss the most about Perl (to the point where I've been pitching conference talks to other language communities about things they should be stealing from CPAN...)
posted by genehack at 3:35 PM on November 5, 2019
posted by genehack at 3:35 PM on November 5, 2019
« Older "a fragile being that finds great strength within... | Why can't they see they're just like me Newer »
This thread has been archived and is closed to new comments
Where I work old-timers like me use Perl because that was what existed when we needed a flexible scripting language. None of the new young engineers here use it--they all use Python. But Perl still exists here because of people like me and some of our scripts are not just one-offs and are used by others so these scripts survive and are maintained.
In other words, Perl still exists for the same reason COBOL still exists.
posted by eye of newt at 2:26 PM on November 2, 2019 [25 favorites]