[Ovid]

This has been a huge deal for the Perl community.

First, it was thought that Perl 6 would be the replacement for Perl 5.

But it was long ago recognized that there was no clear upgrade path from Perl 5 to Perl 6, so it was agreed that Perl 6 was a "sister" language to Perl 5 rather than the successor.

Except that many people expected that Perl 6 would be the replacement, so that stalled many projects. So an "alias" for Perl 6 was created, but that didn't seem to help.

Larry has now agreed with the change and Perl 6 will be renamed to "raku" and Perl 5, which has regular, major releases every year, will now be able to simply be "Perl" and be free to continue on its own way.

If I had my choice, I'd program in raku because it's a lovely language addressing many pain points (including being one of the few dynamic languages with a working concurrency model). But it's not adopted widely enough yet for that to happen. Time will tell ...

[msla]

And this might save Raku.

Lisp has a social problem: It's been called Lisp too long. People look at some simplified LISP 1.5-esque thing in a programming languages textbook and see a "pure" language (which isn't so pure compared to Haskell, but the creep of what "functional programming" means is its own post) which is completely useless. They don't see modern Common Lisp with its package management facility and its packages which you can manage which provide actual functionality and its FFI bindings to external libraries and the fact it compiles to optimized machine code... no, they only see some parentheses thing which is interpreted-and-therefore-slow (you know... like Javascript on V8... ) and is too elegantly pure to be bound to the outside world. Meanwhile, all the Foogols get new names every couple decades (PL/I to Ada to C to C++ to Java to C#... ) so everyone knows they're completely up to date.

My point is, Perl is a tainted name, because everyone knows Perl is dead and Perl 6 is the Duke Nukem Forever of programming languages. Calling it Raku is a chance to get what the Perl 6 team actually did out into the world without the stench of death following it.

[ddaa10]

> Foogols get new names every couple decades (PL/I to Ada to C to C++ to Java to C#... )

+1 for Foogol. Reference to commercially obscure language but annoyingly influencial Algol?

[msla]

> +1 for Foogol. Reference to commercially obscure language but annoyingly influencial Algol?

Yes, even though I don't dislike Algol and the Algol syntax style, necessarily, I just wish they'd imported more Lisp influence sooner.

[cgh]

> Calling it Raku is a chance to get what the Perl 6 team actually did out into the world without the stench of death following it.

"Raku" = "cancer" in Polish. Not a lot of Polish enthusiasm forthcoming, I'd imagine.

[techcode]

I'd imagine that chances are high that whatever name you pick for something in one language - there would be another language in this world in which same or similar word means bad/offensive thing.

[janeroe]

And not just Polish, most (if not all) Slavic languages. What a perfect name indeed.

[Merg]

No it is not. "Rak" is both cancer and crayfish in Polish.

[Jach]

The social problem of the name is less similar to Lisp than I think you're making it, but I do agree it is probably not a terrible thing in the end and could be considered good. I don't think it's going to be impactful enough to "save" or not save the language (as someone mentioned elsewhere, if you called Betamax by a different name, it's unlikely the ultimate outcome would have changed).

The reason I think it's not related to the Lisp issue is because the relation of Perl 5 and Perl 6 was like an unofficial successor with a compatibility mode, like C and C++, whereas the relations between Lisps that create the social problem you highlight of people not knowing about "Real Lisp" are the relations of very incompatible forks with varied functionality running around calling themselves "Lisps" or "members of the Lisp family" and people confusing that with "Lisp". (There were some "Perl 5/6, C/C++" types of relations in the path to Common Lisp like Flavors/CLOS but no one remembers or cares about those outside of Lisp users...) Another reason is the timing, why the name change now, years later -- it turns out Perl (5) is less dead or possessing a stench of death as you put it than people might want, it's still vigorous in its own rights, and so really it makes most sense to just call the new thing by a new name and not destroy both. (Larry's wineskin comment is nice.) The Python 2/3 situation is a closer analog if we counterfactually imagine Python 3000 came out with the current 3.7 feature set, syntax updates, and backwards incompatibility. Python 2 users (me among them) would still have dragged their feet, since Python 2 would still have been useful, still had its own vigor, the same as presently, but it might have resulted in renaming some later version of Python 3 instead of the current situation of renaming the continuation of Python 2 (Tauthon).

Going back to the lisp issue to further elaborate why I think it's not very related to this one, the languages that called themselves Lisp (not a Lisp, but Lisp or Some Lisp) shared a heritage going back to the original McCarthy Lisp. The merely "a lisp" languages used that for marketing, but were actually called something different (Clojure, Scheme, even Racket which has to further distinguish itself from Scheme). You see the heritage in the actual Lisp 1.5 manual, where one of the earliest examples should quickly dispel any illusions today about "Lisp's" supposed purity when they show the function 'length implemented with a program block and goto. By only modifying the top-level function define format and substituting ADD1 with 1+, the program works to this day in Common Lisp. For members of the lisp family that don't call themselves lisp, you're not going to be able to make such a trivial transformation, because there's no shared code heritage, just a vaguely shared s-exp-ness to the syntax. And right after that the manual describes the "pseudo-function" 'trace, which to this day is lacking in supposedly modern languages or requires a bunch of IDE ceremony to set up. It's present in CL and behaves the same, though. Continuing to call CL as simply Lisp seems pretty well-deserved.

The Lisp social problem then is that people run into members of the vaguely defined lisp family like Scheme (especially with SICP formerly being a common gateway for freshmen or HS students) or Clojure and confuse "a lisp" with "Lisp". They can spread their confusion further by releasing a project/blog like "let's write a lisp interpreter!" that can be understood correctly as "let's make a program that interprets code for a lisp¹" but tends to be misunderstood (sometimes even by the author) as "let's make a program that interprets code for Lisp".

Of course I also think this "social problem" is way overstated, especially these days when it's so trivial to dispel the old myths and when the gateways via Clojure or Racket are actually good in their own right and so don't leave the same impressions of "Lisp's a neat toy" that only seeing SICP Scheme could. But if people keep talking about the problem as if it is big, perhaps it will become self-fulfilling, hence my long comment in disagreement. ;)

¹ aka a member of the lisp family based on my vague membership criteria that probably don't even pass Steele's 3-part acceptance test in https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf that requires as its final step (atanh -2) to return a complex number. (Bonus if the correct complex number.)

[lliamander]

>including being one of the few dynamic languages with a working concurrency model...

Elixir is worth a look. It's a pretty productive little language with a great concurrency model.

[7thaccount]

When someone says they want to work in Perl6/Raku, they likely have vastly different problems than someone using Erlang/Elixer. There is overlap of course (both general purpose), but I can't imagine using Erlang for scripting, while Raku is first class here.

[lliamander]

I can't imagine scripting in Erlang. Or rather, I've seen it done and it wouldn't be my first choice.

Elixir, on the other hand, has many nice features for scripting, such as better string handling, process pipe-lining, and an excellent set of first-class generic data structures (beyond just map and list). It also happens to have Erlang's fantastic concurrency model.

[dnautics]

As a testament to this statement I wrote a Google maps API scraper to get a list of driving distances from a pair of csv tables - shortname + address and shortnames to and from, in about 1 hour, and the whole thing clocked in at 90 lines of code including about 40 lines of comments.

[7thaccount]

That seems about right for a competent Python coder. It or Powershell or Linux command line tools would have very little code and be very easy to whip something up. Perl would be great here as well or honestly any dynamic language with great library support.

[cutler]

Elixir still has to borrow arrays from Erlang and it's a pretty ugly implementation at that so no - I would not agree that Elixir has an excellent set of first-class generic data structures.

[bitwalker]

Neither Elixir or Erlang have real arrays, unless you want to count tuples. That said, I don’t see how that correlates to scripting, the data structures that are first class in Elixir are very ergonomic and certainly flexible enough to tackle pretty much any task you’d use a scripting language for.

[minton]

I guess it depends on what you're comfortable in? I myself have tons of Elixir scripts that I use to automate much of my life. It's replaced ruby as my go-to for one-off scripts.

[xyproto]

I didn't know that Elixir had such a low-threshold for one-off programs.

Have you tried Crystal? Both are on my list of programming languages to look into next, together with Elm, Reason and Zig.

[jtms]

Oh man I just love and adore Crystal. I am a long time rubyist and I have to say they just nailed it with Crystal. I just wish I had more opportunity to use it professionally!

[core-questions]

It must be time to take my Ruby skills and go and learn this. Is it really as easy as it sounds like it should be for a lazy, dynamic-typing sort of Ruby dev to pick up?

[Willamin]

Crystal is wonderful for one-off programs in my experience.

Elixir had a long startup time for one-off scripts in my experience, but Elixir’s syntax is still one of my favorites for scripting.

[dnautics]

Is a 100ms startup time really a big deal for something that is either going to be manually triggered or cronjobbed and expected to take on the order of minutes?

[emmelaich]

Crystal's startup time is not great though. 700ms vs 100ms for ruby.

Compared with

   time crystal eval <<<"puts 1"
   time ruby <<<"puts 1"

[cutler]

Elixir/Erlang isn't a general purpose language. You pointed-out one reason why - scripting. Computation is another area where the language is deficient. I'd go so far as to say Elixir's failure to challenge mainstream languages for mindshare is down to to it occupying a niche - lightweight concurrency and distributed systems.

[sanderjd]

Their point was that elixir is a good language for scripting. I'm not sure if this is true but I don't see any reason it couldn't be. I don't think "distributed systems" are niche... I think every web application I've worked on fits that description, which is basically my whole career at all different kinds of companies.

[weff_]

I'm trying to understand, what kind of scripting requires first-class concurrency that isn't fulfilled by say Python?

[dragonwriter]

For concurrency I think Raku has slightly more developed async support than Python, but the bigger advantage, I think, is in parallelism where, aside from the CPython GIL limiting practical parallelism in the main implementation (which is a big deal), Python as a language lacks the parallel iterables produced by the hyper (parallel but constrained to return in order) and race (parallel and not constrained in order) methods on the Iterable role in Raku, or anything like Raku’s hyperoperators that are semantically concurrent and parallelizable at the discretion of the optimizer. (Come to think of it, while also parallel, all those are also high-level concurrency constructs that Python lacks equivalents to.)

Python as a language can support parallelism via threads, and CPython as an implementation can via multiprocessing, but those are both very low level abstractions; Raku has higher level abstractions which allow much more succinct expression of parallel operations.

[Too]

Sounds like multiprocessing.Pool.imap and imap_unordered? When dealing with io you also have async/await equivalent iterators like asyncio.as_completed().

[b2gills]

Raku has `await` but it doesn't need `async`.

    sub foo ( Int \n where 1..100 ) {
      #  ___ start is a prefix operator that creates a Promise
      # V
      start { sleep n.rand; (1..n).pick }
    }

    my $result = foo(10);

    say $result.status; # Planned

    say await $result; # 6 (after a delay)



    # this is nearly identical to foo above
    sub bar ( Int \n where 1..100 ) {
      Promise.in( n.rand ).then({ (1..n).pick })
    }

(Note that `start` does not need a block unless you are grouping more than one statement as I have above.)

There are combinators like `Promise.allof` and `Promise.anyof`.

You usually don't need to use `Promise.allof`, because you can use `await` on a list.

    my @promises = Promise.in(1.rand) xx 10;

    my @results = await @promises;

(Note that the left side of `xx` is _thunky_ so there are ten different Promises with ten different random wait times.)

---

You should see the `react`/`supply` and `whenever` feature.

[Grinnz]

I am not that familiar with Python, but the GIL has long prevented any real in-process concurrency. Perl has concurrency but it's complex, heavy, and poorly supported. Raku's approach to this is built to avoid all these problems (like Elixir).

[weff_]

I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?

[nuclear_eclipse]

If it's entirely CPU bound, you can use multiprocessing to negate most of the GIL issues, and transparently send inputs/outputs between the parent and child processes. If it's I/O bound, then AsyncIO is a great way to express asynchronous workflows. If it's a combination of both I/O and CPU bound workloads, there are ways to mix multiprocessing and AsyncIO to better saturate your cores without losing the simplicity or readability of Python: https://github.com/jreese/aiomultiprocess

[Grinnz]

Indeed and as a Perl developer I make use of XS/external libraries, cooperative multitasking (event loops/promises), and forking to cover these use cases. It doesn't preclude wanting the additional option to take advantage of threads in a useful way, since they do exist.

[karmakaze]

It's not just CPU bound problems, handling multiple overlapping i/o operations is more trouble than it ought to be.

[vaer-k]

Why should first-class concurrency needs be required to script in Elixir? This question seems to imply that Python is somehow a default language and special requirements must be needed to justify writing in something else. Elixir is general-use and pleasant to write scripts in so seems reasonable to me for someone to do so if that's their thing.

[weff_]

Ovid2 said Perl6 has a good concurrency model

lliamander replied that Elixir does too and it's worth a look

To that, 7thaccount replied that Perl6 and Elixir fill different niches.

So far, it seems Perl6 fills a niche that requires scripting and first-class concurrency. My question then is: what is this niche that requires very solid concurrency but also scripting. In other words, what does Perl6 have in terms of concurrency that Python does not (given they are both scripting languages)?

[lliamander]

A fair question.

I don't know of many instances where scripting and concurrency would be needed in the same application. But if you wanted to use single language both for scripting tasks and applications that require concurrency, then Raku or Elixir would work.

One instance I can actually think of, that would be specific to Erlang/Elixir, is if you have a long running service that you sometimes run batch jobs against (like importing data from a CSV). An Elixir script can hook directly into an Elixir/Erlang service and interact with it using message passing. It's a heck of a lot simpler than RMI, and avoids the need to expose new HTTP endpoints specifically for such tasks.

[Ultimatt]

Jonathan Worthington (Rakudo Compiler Architect). Keynote: Perl 6 Concurrency

https://www.youtube.com/watch?v=hGyzsviI48M

[labster]

Does Python 3 have any operators that transform ordinary method calls into concurrent method calls? Perl 6/Raku does.

[Grinnz]

Which is a similar response to the comments asking "why Perl over Python?" I ask, why not (both)?

[b2gills]

Especially since you can use the Inline::Python module.

[greggman2]

I'm embarrased to say I write scripts in node :P I used to write scripts in python but I've been writing so much JS that it's just easier for me in node. Plus, node defaults to locally installed deps so I don't have to deal with virutal environments.

[tekknik]

Why do you think this is embarrassing? Javascript is great for small scripts. Largr codebases then sure

[dnautics]

Well just from experience untangling async calls in python is a nightmare and sometimes hard to reason about. The red/blue function problem is real. Meanwhile dispatching concurrent long-running scripting tasks is basically trivial in elixir (Enum.map over Task.async, then Enum.map over Task.await)

[ajoseps]

I'm guessing because Python's concurrency relies on the Global Interpreter Lock. Although I think concurrent.futures might address that. Haven't worked with python concurrency libraries in a bit.

[weff_]

as I posted above:

I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?

[zaphirplane]

There is machine learning, which usually calls into numpy or other c extensions With a lot of the data preparation done in python

[rubyn00bie]

tldr; Using a scripting language that allows for native threads or has a strong concurrency model builtin to the core would be beneficial for any CPU bound scripting task...

-----

Python's concurrency model is good for waiting on network or disk I/O because of its GIL (Global Interpreter Lock): https://realpython.com/python-gil/#the-impact-on-multi-threa...

If your program is CPU bound the GIL will slow you down. I'm sure since the python ecosystem is quite vast there are ways around the GIL... but then you have to worry about every library you use not supporting "real" multi-threading, or (b)locking for no reason and shitting all over your efforts.

[weff_]

As I've posted above, I'm a bit confused by CPU-bound work being processed in a scripting language. If you're planning on doing intense CPU-bound work, maybe use a lower-level language? I'm not saying abandon Python: you can extend Python with C or just use IPC to transfer data between a Python front-end and a computation back-end.

[b2gills]

I have a different perspective.

When I have a bit of Raku code that is too slow I complain (send a bug report) and then someone else figures out why the JIT isn't doing a better job and fixes it.

Then bingo-bango it ends up even faster than using NativeCall to call into the C code.

Of course there may be a delay before someone gets around to figuring it out; so in the meantime, NativeCall is actually very easy to use.

---

I would like to note that someone wrote Perl6/Raku code and the equivalent C/C++ code. They reported that the Perl6/Raku code was faster. (It was before Raku was brought up as an alias/name.)

I'm fairly sure that the reason the C/C++ code was slower is that it copied strings around rather than using pointers and indexes into other strings like MoarVM does.

[zmmmmm]

At one time it was an obvious dichotomy that you would not use a scripting language for CPU bound work, but these days it is a much more blurry line. Partly because modern efficient languages are becoming ergonomic enough to work well as scripting languages while still giving you very good performance.

I actually love doing CPU bound work in Groovy which is usually described as a scripting language. But it gets converted straight to java byte code which is JIT'd and ends up as machine code. It only takes a few static typed hints here and there and it runs in the same league as C++ implementations. And it gets Java's excellent concurrency support for free.

[rubyn00bie]

I totally you feel you, I guess I thought your question was substantially more surface level than it was. My apologies.

I'm personally with you. I also don't tend to think object boxing is really the performance bottleneck for most applications, and if/when it is, likely the other requirements should've already ruled out using one (a scripting language).

It's like writing Nifs for Elixir, yeah sure you _can_, they have their purpose, but you could also just write another application to do that one thing and like you said, use IPC.

So in summary, we agree with each other, here's to:

the right tool for the job!

[tombert]

For that matter, Erlang has been around for like almost 30 years and has had multicore support since 2007, and has always been dynamic.

[davidw]

Erlang is great, and I miss working with it, but I'd never want to write much in the way of 'quick scripts' with it. Something like Ruby feels much more productive for that.

[tombert]

Heh, escript isn't so bad once you get used to it.

Clojure would be a great language for small-ish scripts if it weren't the dog-slow startup times, and has excellent concurrency support.

I hear that GraalVM might fix that but I sadly haven't had a chance to play with that yet.

[cutler]

Even if GraalVM fixes startup times aren't JVM languages just too long-winded for scripting? Perl, Python and Ruby dominate the scripting world for a reason - standard libraries for file, dir and pathname manipulation written in a concise language. Scripting is a style of coding, not just a means to an end. It is here that dynamic languages excel. Clojure is the leanest of the JVMs but doesn't it still rely on Java for file, dir and pathname manipulation?

[dragonwriter]

> Even if GraalVM fixes startup times aren't JVM languages just too long-winded for scripting? Perl, Python and Ruby dominate the scripting world for a reason

Ruby is a JVM language, in that JRuby is a very complete competitive, current, and widely-used-in-production Ruby implementation.

[zmmmmm]

You should definitely educate yourself about Groovy. It's my favorite scripting language, particularly because it enables a true scripting style, but actually works well as a full application development language too (though I would always want a backbone of static typed code).

[slifin]

It relies on the implementation of its runtime, JVM, .net, JavaScript, BeamVM etc but uses it's own language for those operations, slurp/barf etc

So as a developer it's all the same until you start leveraging the features of your particular runtime but this does make code sharing viable

[davidw]

There are JVM versions of Python, Ruby and Tcl, so it's not really about the VM itself.

[didibus]

Ya, GraalVM fixes it. But it requires a compile step, so it's not as nice for scripts.

My favourite for scripting right now is Joker: https://github.com/candid82/joker

Joker is a Clojure dialect which is interpreted, thus it starts super fast (but runs slower, but fast enough for scripts). Its design is to be batteries included for all things scripting. So it's just a self contained executable with everything you need for scripting. It's implemented in Go.

I use it wherever I would have used bash or powershell prior.

There is also Babashka: https://github.com/borkdude/babashka which is a similar idea, it's an interpreted dialect of Clojure with fast start times designed for scripting. The difference with Joker is that it is newer and more experimental, and it is implemented in JVM Clojure, compiled with GraalVM and has no Windows support for now.

Anyways, I really recommend the use of Joker. Its awesome for scripting. I just put its binary in all my bin folders and script with it. It's great.

[jdminhbg]

GraalVM does in fact fix that. There's a (new-ish) project called babashka that lets you do some basic scripting for example: https://github.com/borkdude/babashka

[lliamander]

Oh certainly. I've done production work with Erlang, and it's great for building systems. I also love the Prolog syntax (I've also since done some side projects in Prolog for great fun).

Why I suggested Elixir is because it has all the strengths of Erlang but is also a better scripting language, and would compete better with Raku on a more equal footing in that respect.

[zzzcpan]

In fact Elixir and Erlang are the only reasonably known dynamic languages that differentiate on concurrency. The rest either do higher order event loop concurrency, which is ok, but not a differentiator, or do worse, shared memory multithreading (threads, coroutines with synchronous channels, mutexes, etc.)

[tombert]

I don't really know what "differentiate" means, but Clojure has support for CSP-channel style with core.async, shared-memory with transactions using atoms/refs, and actor-ish style with the agents.

[cstrahan]

> I don't really know what "differentiate" means [...]

Probably “set themselves apart from others”.

[jolmg]

> Larry has now agreed with the change and Perl 6 will be renamed to "raku" and Perl 5, which has regular, major releases every year, will now be able to simply be "Perl" and be free to continue on its own way.

I hope that doesn't mean that when Perl needs a major number version change again, they'll chose 6. It would be pretty confusing to have 2 Perl 6.

[StevePerkins]

Perl 5 was released in 1994. At this point, the "5" isn't really a version number anymore. It's just part of the name.

If you did a "major version bump" from here, you'd probably have to bring the "5" along for the ride. Like Java version 2, where you had J2EE version <X> for years.

In reality, there probably never will be another major version bump of Perl 5, in the marketing sense. The minor version number is really the major version number now.

[WorldMaker]

Which in turn suggests the Java (and others') solution of dropping the 5 and making the minor version the new major version. Look out for Perl 31.0 soon.

[spider-mario]

Java even got rid of two numbers:

J2EE 1.4 -> Java EE 5

Both “2” and “1.”.

[dottrap]

And as another example, Mac OS X (10), which debuted in 2000, has had every subsequent version continued to be named 10.X. Just this week, macOS 10.15 Catalina was released.

Funny that the name Mac OS X went to OS X and then (back) to macOS, but the 10.X name persists.

[erikpukinskis]

In communist Russia, minor version always have breaking change

[Grinnz]

I can say that at least currently, there is no appetite for Perl attempting to "reclaim" the Perl 6 version in the foreseeable future. It would be a disaster in both community relations and marketing. It will either be Perl 7 or Perl 34+.

[irrational]

Perl 2019

[lilSebastian]

This one goes to 11

http://perl11.org/

[rurban]

And we'll keep that name and idea. 5 + 6 = 11, as it should have been

[b2gills]

This has the benefit of showing that Perl gets a new version released every year.

I have previously stated that I would like it to be an alias of sorts.

    use v5.30;

    use v2019;

Basically have both of those lines do the same thing.

---

Perhaps even something like:

    use Perl v2019;

(I actually considered posting a module that would make that work.)

[wvenable]

A similar sort of situation happened with PHP which is why there is no PHP 6 -- it jumped straight from PHP 5 to 7.

[RussianCow]

And same with ECMAScript 3 to 5.

[WorldMaker]

There was an ECMAScript 4, it just wasn't adopted by browsers. (It was semi-adopted for ActionScript 3.)

[girvo]

I thought the relationship went the other way, that AS 3 was going to be standardised as ECMAScript 4? Not that it matters, I’m likely remembering incorrectly!

[WorldMaker]

Standards are a two-way street, and we're probably both right from different points of view. (Especially, because AS 2 also had a number of the features proposed for ES 4, so even if AS 3 was "solely" inspired to be an implementation of the ES 4 standard, ES 4 itself took inspiration from AS 2.)

[joshlemer]

It's not uncommon to leap frog versions in such cases. PHP went from 5 to 7, for instance.

[diag]

But that's because PHP6 was dumped after being in development for a while.

[SwellJoe]

This is not entirely unlike that. Somewhere along the way, everybody realized Perl 6 was not the path forward from Perl 5, and so Perl 6 never really took the place of Perl 5, just like PHP6 never took the place of PHP 5. It looks like a pretty similar scenario, if you squint, I think.

It makes little difference for Perl that this experiment in a next generation version of the language is still alive and going its own way. The result is the same...people kept moving forward with version 5, and if it needs a new version, it can't use version 6 because 6 was already used for that other experiment (that failed to take the place of Perl 5).

[deaddodo]

They didn't "skip" php6.

The primary goal of PHP6 was to implement full unicode support and drop mbstring. However, that took much longer than expected and multiple major features ended up getting backported to 5.3, 5.4 and 5.6; to the point that PHP 7 became the new feature version while PHP6 was worked on. They eventually gave up and PHP7 was released with unicode support built fairly deep, but basic string types and the like still being byte arrays.

PHP7 was PHP6, without the native and full unicode coverage requirement.

[Dylan16807]

"giving up" sounds like "skipping" to me.

[chubot]

Yeah there was also no ecmascript 4, it went from es3 to 5 because 4 was abandoned as too complex.

[cpeterso]

And Microsoft skipped DirectX 4.0:

"after DirectX 3 was released, Microsoft began developing versions 4 and 5 at the same time. Version 4 was to be a shorter-term release with small features, whereas version 5 would be a more substantial release. The lack of interest from game developers in the features stated for DirectX 4 resulted in it being shelved, and the corpus of documents that already distinguished the two new versions resulted in Microsoft choosing to not re-use version 4 to describe features intended for version 5."

https://en.wikipedia.org/wiki/DirectX#Version_history

[ether_at_cpan]

For those that can remember back that far, MacOS also jumped from 5 to 7. (7 was the first version that supported running multiple applications at once.. not counting the MultiFinder hack that came before it by a few years.)

[blahedo]

It certainly did not. System 6 (including MultiFinder if you had enough RAM to support it ;) was active for several years in the early 90s before System 7 came out. The label "MacOS", meanwhile, didn't show up until a few years after that.

[ether_at_cpan]

Doh, yes, system 6 was current for quite a while. I wonder what other thing from that era I confused it with. I swear something around that time skipped a 6.

[ken]

Solaris skipped from 2.6 to 7. UnixWare also jumped from 2.x to 7. HP/UX skippped from 3.x to 6.x. In perhaps the strangest version jump of all time, Darwin jumped from 1.4.1 to 5.1, as part of Mac OS X 10.1.1.

It seems Unix vendors really don't like low version numbers. Of course, Windows famously jumped from 3.x to 95, so it's not like they're any better.

[duskwuff]

System 7 skipped from 7.1 straight to 7.5. (And the pattern was repeated with 8.1 and 8.5.)

[yjftsjthsd-h]

What? https://en.wikipedia.org/wiki/System_6

[jandrese]

That would be an issue, but I don't think there is an appetite for a new major version of Perl at this point.

To avoid confusion they would probably break the version convention entirely and name it with the year instead. So instead of Perl6 it would be Perl'19.

[yesbabyyes]

I think it's likely they will skip the 5, and continue with version 32, or whatever minor they're up to now.

[mhd]

Ditch the major version. As the current one is 5.30, the next one will be Perl 31, the next stable is Perl 32.

[sdenton4]

There's even a good mathematical justification for going from 5->32; just say that previously the versioning was in log_2 scale...

[cjohansson]

Maybe it’s better to find a new name for the next Perl 5 language version. It would simplify internet searches. It should be clearly distinct from Raku though.. Angular is in a similar mess to Perl, very hard to find decent information on web crawlers

[FillardMillmore]

Well, PHP jumped from 5 to 7 (without there truly ever being a 6) so I think Perl could do the same with no major downside.

[sigzero]

They'll probably skip to 7.

[dwaltrip]

That is probably the best solution, but at the same time it is such a hilarious thing.

[b2gills]

I think it would be a better idea to make the minor number be the major number. So skip to 32.

[KSS42]

Why not Perl 10 or Perl X?

[rurban]

no, it's called cperl now. perl5 didn't see not much improvements for the last 20 years, the development happens only in cperl, which is the perl5 successor.

[ether_at_cpan]

bwahahahahaha

[ttkciar]

Since the language-previously-known-as-Perl6 will be known as Raku, there shouldn't be any conflict with Perl v6

[TheCoreh]

Even if file names/packages don't clash, there's still a conflict when it comes to documentation, articles, blog posts, books, stack overflow questions and other documents that might or might not be updated.

[lilSebastian]

That would only further confusion

[7thaccount]

Hey Ovid. I'm curious...if P6 had been performant and production worthy enough for your tau-station game, how much easier would the project be than with P5 + Moose? Just curious...I remember you saying years ago that you would've used it if you could've at the time.

[Ovid]

The https://taustation.space/ game runs great on Perl 5, but yes, with a robust Perl 6, many things would have been easier to implement. But by "robust" I don't mean just the language—I also mean the ecosystem.

There is no DBIx::Class (or related schema loader) for Perl 6. I don't know how mature the web frameworks are. Or even basic stuff like Excel reader/writers (we use lots of Excel for backend data analysis).

On the other hand, most of the async stuff we currently use can be thrown out. With raku's gradual typing, our in-house type libraries can be tossed out. Our local modules for making it easier to write clean procedural and OO code could be thrown out.

And the raku code would be far more concise and easy to read. Here's a simple Point object in Moose:

    package Point {
        use Moose;
        use overload '""' => \&Str, fallback => 1;
        use Moose::Util::TypeConstraints;
        subtype "PointLimit" => as 'Num'
            => where   { $_ >= -10 && $_ <= 10 }
            => message { "$_ must be a Num between -10 and 10, inclusive" };

        has [qw/x y/] => (
            is       => 'rw',
            isa      => 'PointLimit',
            required => 1,
        );

        sub Str {
            my $self = shift;
            return sprintf "[%f,%f]" => $self->x, $self->y;
        }
    }

raku:

    class Point {
        subset PointLimit of Rat where -10.0 .. 10.0;
        has PointLimit $.x is rw is required;
        has PointLimit $.y is rw is required;
    }

And for those who don't "grok" the above, here it is in Python 3, just so you can see how clean raku's OO syntax is:

    class PointLimit:
        def __init__(self, name):
            self.name =  name
        def __get__(self, point, owner):
            return point.__dict__.get(self.name)
        def __set__(self, point, value):
            if not -10 < value < 10:
                raise ValueError('Value %d is out of range' % value)
            point.__dict__[self.name] = value

    class Point:
        x = PointLimit('x');
        y = PointLimit('y');

        def __init__(self, x, y):
            self.x = x
            self.y = y

        def __str__(self):
            return "[%f,%f]" % (self.x, self.y)

[snapdangle]

It's worth checking out the Red ORM, great progress is being made and it feels very Perl 6 native in terms of its semantics.

[Ovid]

Red looks interesting. Though I don't like the mapping of tables to "model". In general, I find that a model should be a consumer of an ORM, not the ORM itself. Otherwise, you expose to much to the business layer and it's harder to refactor.

For example, if you have a column on table A and you later need to move that to table B, a clean model can encapsulate that change. Hard to do when the ORM is being treated directly as the model.

[hirihoto]

Try Xoos. Red also uses a meta model syntax for extra ugliness.

[7thaccount]

Thanks for the detailed reply Ovid!

I'm only a novice in Perl5 land (Python is usually my go-to along with Linux CLI tools and Powershell on Windows, or honestly a lot of SQL these days but sometimes I reach for Perl5 when it has something I need) but I always keep an eye out for different and interesting technologies and Perl6 is definitely on my radar to check in on every now and then. As you've pointed out, it seems to have a lot of power that could reduce a lot of the one-off scripts I write. I do a lot of basic text file manipulation and any feature that can save me time is valuable even if there is more stuff to learn. To me, Perl6 appears to allow for writing beautifully succinct and readable OO, Imperative, or FP like code. However, if I just need to wrangle some data (throwaway code) it looks like it can be for text what APL is for arrays (a powerful Swiss army knife).

On another note, while I have you here, do you ever plan on putting out another Perl book, but one on Perl 6 (I know there are several already published).

[dimitar]

Clojure has a focus on concurrency, is functional and it embraces JS and Java, the dominant platforms.

[bborud]

> This has been a huge deal for the Perl community.

I wasn't aware that there was one beyond the poor sods charged with maintaining my youthful sins.

[Ovid]

I get hired all the time to fix legacy systems in Perl or to build new systems in Perl.

We're still out there, but it's not "cool" to talk about.

[bborud]

I hope you are not working on my old sins. But if you are, can I watch? :-)

[sjn]

I'm pretty sure Ovid's hair would turn grey if he did! ;-)

[Causality1]

Rather reminds me of what happened with Palm OS 5 and Palm OS 6. Both ended up adopting separate names but because OS 6 wasn't backwards compatible the sheer weight of legacy software kept it from ever catching on.

[rolltiide]

If only the Python community could learn something here