Hacker News Reader

Comment by doktrin | Hacker News Reader

Naive question time. Is Perl 6 something that non-Perl developers should be looking into?

This may be inflammatory, but it's my earnest impression : as an outsider, I really don't like how Perl's versioning was handled (5 vs. 6). On top of being unnecessarily confusing, it also gives an impression of complete mismanagement - fair or not.

With so many languages out there to choose from, what sets Perl 6 apart from other modern languages and ecosystems?

View on HN

Although I program in Perl 5 professionally, I think that Perl 6 is something that non-Perl developers should look into. While it's true that P6 draws inspiration from a variety of languages and techniques, from Smalltalk through Reactive Extensions and more, a laundry list of features is not necessarily the best reason to adopt a language -- especially one with a small ecosystem.

Instead, I think that P6 is worth looking at because of the "feel" of the language, or perhaps another way to put it is the way that all the pieces fit together. I found it easy to do the following in Perl 6:

1. Quickly write a small proof of concept program

2. Heavily use concurrent and asynchronous code in a way that "just works"

3. Fluidly mix imperative, functional reactive, and object oriented code

4. Add types for safe refactoring / further development

Even though Perl 6 still abides by TIMTOWTDI (There Is More Than One Way To Do It) there was "something" that gave a consistency to all of the above. Or perhaps, nothing felt bolted on, which is perhaps a luxury of essentially starting from scratch. :)

Perl 6 is not only fun to write, but also easy to read (once you of course learn the syntax, which is quite different coming from not-perl). My hope is that the ease of using its OO features and type system will help avoid the "hash-of-who-knows-what" problem.

Lately the two languages I most enjoy using are Perl 6 and Go, which would appear to be almost total opposites! But they both have that "something" that just feels great to write. This is of course subjective, but I hope it's helpful somehow.

> Is Perl 6 something that non-Perl developers should be looking into?

Perl5 was feeling the weight of its humble origins as a small language for scripts, designed in the 80's. All that $@%<>$_ syntax, and bad support for keeping larger programs clean and organized.

Python's main selling point was: like Perl, but cleaner syntax and object system is in-build, not bolted on as an afterthought.

Also Ruby's selling point was: Perl, flexible for meta-language hacking like Perl, but cleaner syntax and in-build object system, also not as restrictive as Python.

Now Perl6 has everything that at a time made Python or Ruby feel more modern than Perl5, and more, even optional typing. (Well, it doesn't have Python's opinionated restrictiveness.) Of course at the moment, Perl6 doesn't have the huge selection of libraries that Python and Ruby have at the moment.

I don't know what, if anything, is a good reason for you to learn a new language. But while in the trio perl5,python,ruby perl5 was the most dated, old-feeling language, now in the trio perl6,python,ruby Perl6 is now the most modern in its design.

> Of course at the moment, Perl6 doesn't have the huge selection of libraries that Python and Ruby have at the moments.

Well, there is Inline::Python...

In my opinion, yes.

I had zero perl experience before diving into perl6. I've found it to be a great language with a fun community.

As for compelling features, there was a good discussion on this a few days ago, so I'm just going to link to that: https://news.ycombinator.com/item?id=10637789

In my mind, the great thing about Perl has always been that it's built into pretty much every UNIX-like system, so you can literally use it out of the box in either Mac OS X or any flavor of Linux. But Perl 6 isn't universal like that (yet?) so to me it just competes with Python and Ruby, both of which I already know and which get the job done just fine, and which I have installed wherever I need it.

The goal of Perl 6 is to pull together many different things. The clarity of the original Perl, the ease-of-use of Java, the community size of experimental languages like Self, the raw performance of Bash scripting, and the safety of C++. If that's a combination that appeals to you, then go for it.

> The clarity of the original Perl

This was not its reputation BITD.

SARCASM ALERT WOOP WOOP

If intellectual dishonesty appeals to you ... well, you went for it.

Listing features is a bad way to choose a language[1].

Program something in it, and if you get a good feeling, then probably a lot of other people will too, and the language will take off.

Larry Wall is a linguist, and I think that is probably what sets perl apart more than anything.

But yes, it happens to have the kitchen sink, too.

[1] Unless you have hard requirements, like control over memory or runtime environment.

> Larry Wall is a linguist, and I think that is probably what sets perl apart more than anything.

He's also pretty good at telling jokes, which explains a lot of things about Perl ;-)

I think it's less what Perl 6 has that other languages don't have (almost everything is implemented in at least one language), and more that it implements everything together in one language. The pure breadth of what is supported is somewhat staggering. I posted the other day[1] about what I thought were some interesting features, so that might be a good start for some things that might set it apart.

1: https://news.ycombinator.com/item?id=10642153

Don't know much about the rest of the language, but the Perl 6 regexes are a big improvement and I hope they take over as the conventional syntax in the world outside of Perl.

What appeals to you about the new regex system? Is it a new syntax or an expanded feature set?

It's a completely new syntax, though a few elements are identical (quantifiers for instance are similar). It tries to be more readable and intuitive.

The regex system is also part of grammars, which did not exist natively in Perl 5.

They're probably talking about the new "rules" system: https://en.wikipedia.org/wiki/Perl_6_rules

There are plenty of Perl5 users that have never liked the idea of "Perl6" and swear that they will never use it. That is just one of the reasons why Perl6 took awhile to release. It was not made by the Perl5 community, it was/is a different community although it does have some Perl5 guys strewn through it. It will be interesting to see how it turns out. I plan on picking it up soon. So yes, non-perl people should try it. Other than the name, and Larry Wall, there is not much the same between the two.

I am not following your issues with the versioning. Perl6 was supposed to be released like back in 2005 or so. In that context it made sense that the next release of Perl would be 6 and that the 5 series would just go into maintenance only mode. But that didn't really happen. Perl5 devs continued to do their own thing while a new community was built around Perl6 with different people.

> I am not following your issues with the versioning.

As I understand it, Perl 6 is essentially a complete language overhaul. However, the sequential numbering implies an iteration. To me, that's unintuitive.

At the risk of over-analogizing, it's a bit as if Scala had been released as Java (n). Totally, completely irrational? Maybe not. Confusing? Almost certainly.

Think of Perl5 and Perl6 as American English and British English. Both languages are English, but essentially they are different languages but with a similar foundation.

> Confusing? Almost certainly.

Agreed. I don't know if it would've been better for Perl6 to not have 'Perl' in its name, but it almost surely would have been better for Perl5 if Perl6 hadn't had 'Perl' in its name.

> Think of Perl5 and Perl6 as American English and British English

This is a bit pedantic, but I think a better analogy might be Dutch and German - similar roots, but where fluency in one doesn't confer fluency in the other.

Granted, I haven't touched Perl 6 so the magnitude of difference I'm estimating is based off of a very superficial impression.

Python 2 & 3 might be somewhat akin to American & British English.

> It almost surely would have been better for Perl5 if Perl6 hadn't had 'Perl' in its name

Agreed. From a distance, there's definitely the sense that Perl5 was sacrificed for the benefit of Perl6.

Actually I remember reading somewhere that when Perl 6 was just getting started, it motivated a number of Perl 5 devs to hunker down and improve Perl 5. Almost in opposition to the new somewhat-alien syntax of Perl 6.

At this point I think most programmers are at least slightly aware of the 5/6 debacle and I feel that both languages actually benefit from it! It makes people think about versioning, sisterhood, and syntax! Which are all important things for programmers to think about. But really, everyone's got an opinion on the matter and that's kind of what makes it so great.

Historically, Perl6 was supposed to be the next version of Perl (replace Perl5). There was a plan for Perl5 and Perl6 to share a new virtual machine and for there to be some sort of compatibility layer so that Perl6 could run Perl5 code. However when it started to take decades to complete Perl6, and when it started to become clear that Perl6 was so different from Perl5 that it was essentially a new language, working Perl5 developers started working on Perl5 again and porting as many Perl6 features as possible to Perl5 (although typically not as new minor versions of Perl5, but as modules on CPAN). So for example we have Moose which brings a lot of the best bits of Perl6 objects to Perl5. As a result many Perl5 programmers stopped waiting to be saved by Perl6 and just got on with it. Over time the distance between Perl5 and Perl6 communities grew, despite some efforts at unification, so that now the fact that both languages share the Perl name is a bit silly (in my opinion, but I know that's not universally shared). In fact there's been moments of hostility between the communities, over the Perl name and so forth. So sorry this is confusing to you, you are rightly confused and it saddens me that it happened. I wish that when it became clear that Perl6 was not replacing Perl5 that we'd have chosen a new name for Perl6. Unfortunately the groups running this are not democratically chosen people to represent the Perl community, just people that showed up and did work, so they often don't feel or care about the confusion. What I usually do is consider Perl5 the language and the version is 22 (the current release of Perl5), and I think of Perl6 as being alpha or beta for version zero. If you consider the number part of the language title it sorta can make some sense.

"intuitions" have nothing to do with it ... you simply aren't knowledgeable about programming languages and their history. Perl 6 looks more like Perl 5 than Perl 5 looked like Perl 4, and the same goes for the earlier versions of Perl, as well as FORTRAN, Modula, Simula, Algol, and other languages with numbers in their names. These numbers are not simply release or version numbers.

Exploiting a post with this question, as somebody who knows Perl 5, I'd like to ask people that knows Perl 6:

Will I be able to write a dictionary of dictionaries or arrays without looking at the documentation every time? Did Perl 6 syntax for references got sane?

That depends on the person. I imagine anyone who looks at the docs for a few minutes would have a pretty good idea for themselves

I really don't have any idea what you are talking about..

Are you talking about something like this:

  $hash_of_hash = {
    hash1 => {key1 => 'value1'},
    hash2 => {key1 => 'value1'}
  };
  say $hash_of_hash->{hash1}{key1};

Seems easy to me...

I think reference syntax in Perl6 is gone. Which personally I don't like.

I imagine the gripe has something to do with either hash/array sigil variance, that you assign to hashes and arrays with lists (as opposed to ref constructors as you've done), or both.

Both are cleared up by really understanding context as it applies in Perl 5, which is probably the single largest difference to other languages that is (sometimes unfortunately) easy to get along without understanding because of the DWIMiness of the language. Or references, but I tend to think most people should be able to understand them without too much trouble.

As an example, this won't run:

%hash = {key1 => 'value1'}

$hash_of_hash->{hash1} = %hash

Now, this will work (or something like it, I don't remember the syntax):

%hash = {key1 => 'value1'}

$hash_of_hash->{hash1} = \%hash

The syntax makes a lot of sense when you read the specs. It does create lots of problems when you try to create complex data structures in practice. It's also complex enough (with enough corner cases) that I can't remember it if I don't use it every week - but maybe that's just me.

By the way, I don't remember whether I must read the above structure as:

$hash_of_hash->{hash1}{key1}

$($hash_of_hash->{hash1}){key1}

I also don't remember if it is equal to the one you defined. I know it's in the documentation, and it's very clear there. It's just some corner case that I never bothered to memorize for any long time.

The quick way to remember this is that hashes naturally consume and supply lists. When a hash consumes a list, it alternates to assigning list items as keys and values. When a hash is supplied on the right hand side of an assignment, it's keys and values are supplies as a list in alternating order. Values for a hash or array must be a regular variable (scalar), or a reference to some item (such as an object, hash, array or scalar).

It also helps to know that '=>' is really just syntactic sugar for a comma that also implicitly quotes the word to its left, and not a special operator for hashes. These 2 lines are the same (in Perl 5):

    %hash = (hello => 'there');
    %hash = ('hello', 'there');

This is also perfectly valid (though non-idiomatic) Perl 5:

    print Hello => ' ' => there => "\n";

Yeah, I had quite a bit more in my reply originally, including that and code snippets with assignment back and forth between a hash and array, but decided I didn't need to turn this article into a Perl 5 tutorial ;)

I totally understand your question, as I was struggling to do this kind of things in Perl 5 some time ago. I hear that it's been made easier in Perl 5 lately, though. In any case, it's indeed much easier in Perl 6, as in Perl 6, there is no more references, or rather, everything is a reference.

so for instance a dictionary of dictionaries or arrays looks like:

    my %dict = {
       'foo' => {
                    'bar' => [ 'an', 'array' ],
                    'a deeply nested word' => "tada!"
               },
       'an empty dict' => {},
       'an empty array' => []
    };
    say %dict{'foo'}{'a deeply nested word'};  # tada!

Little syntax error: for hashes, you would say:

    my %hash = (
    # your key/values
    );

and not,

    my %hash = {
   # your key/values
    };

I think that may be one of the problems people have with Perl - the syntax gets a little whacky and it's hard, sometimes, to wrap your mind around Perl-style references.

My personal way to solve this is to almost exclusively use references in complex data structures, so:

		my $hashref = { 
		another_hashref => { 
			key_name => [qw(
				value
				is
				an 
				array_ref
			)], 
		},
	};

Is a hashref, that contains another hashref, which contains an array ref. Easy to bring up the 3rd thingy in the arrayref:

    print $hashref->{another_hashref}->{key_name}->[2]; #an

This should be somewhat palatable to do actually, if you're slinging JSON all day.

Oh I was sure the syntax was ok in both forms. I'm guessing it's a GLR revision. It's indeed better to to reserve {} for scalar containers.

Notice how in Perl 6 you get a nice error message:

    $ perl6 -e 'my %h = { foo => "bar" };'
    Potential difficulties:
        Useless use of hash composer on right side of hash assignment;
        did you mean := instead?
        at -e:1
        ------> my %h = { foo => "bar" }⏏;

That's good, because in Perl 5, it does DWIM, but that sometimes means returning undef, which - erm, thanks Perl ;)

Regarding versioning, it seems Perl did the same trick as Mac OS, minus the marketing part. From Mac OS 9 to Mac OS X, there was a total rewrite (which was originally planned for OS 8 but got delayed until NeXT saved the day). Switching from 10 to X (besides the unix/NeXT allusion) was a great way to remove focus on the major release number and shift it to the minor one.

So look at it as Perl VI, minor version 0. :)

Perl6's main strength and which makes it "fun" is that it is multi-paradigm. It supports many ways of approaching a problem, instead of forcing a particular model. So you get a toolbox instead of just a modular hammer.

I would say its sorta like what Apple did, except Perl5 is still production ready and in active development. Although Perl6 has the Perl label for historical reasons and out of respect to Larry Wall, Perl5 and Perl6 are considered distinct languages by their respective communities and each has an independent development track. Even after Perl6 considers itself version 1 complete, Perl5 will continue to be worked on, and in fact it will continue to be the only version of Perl with a full library of tools and jobs available.

So it's more like Windows {95,98,ME} and Windows {NT,2000}. Eventually both combined into a single version that could run almost all the prior software of either (XP).

Multiple dispatch in a scripting language is enough to make me take a serious look at Perl.

The versioning was weird, but it could have been worse. At least they didn't take the PHP option and leap from v5 to v7 because the number 6 was cursed.

> Naive question time. Is Perl 6 something that non-Perl developers should be looking into?

As a non-Perl dev who has been looking into Perl 6 after encountering some posts and samples, I'd say it is, though unfortunately the kind of documentation that would make the most interesting bits easily approachable is still somewhat lacking.

> unfortunately the kind of documentation that would make the most interesting bits easily approachable is still somewhat lacking.

Can you be more explicit? I'm not a Perl 6 dev but I would love to help adoption and I'm not so bad at documentation.

The best way I can be explicit about what the Perl 6 docs are missing is holding up the official Python docs for any version [0] as a standard, and saying that Perl 6 needs that; and, for onboarding, especially a Perl 6 equivalent of what Python has as its Tutorial (the Language Reference and Library Reference are also important, though the latter might need rethought more fundamentally for Perl 6, with its more-complete independent modularization as opposed to batteries-included standard library.)

[0] at https://docs.python.org

Personally I really dislike the Python documentation for an average module. Return types seem to never be specified and everything is written too much in a tutorial fashion.

However, you bring up a good point as to the Language Reference / Library Reference. I'm not sure if there's anything remotely comparable for Perl6. I'll get looking into what it would need to add it. Also fwiw Perl6's stdlib is not as bare as 5s.

What style would you want it in if not tutorial? You're in the reference to learn something (possibly again), right? That's a situation tutorial style is well suited for.

Any effective tutorial is going to gloss over some, potentially lots, of infrequently used confusing edge cases. That's great sometimes. But when I'm trying to understand the infrequent and confusing edge case, a generic tutorial is the last thing I want. Git's man pages get dumped on a lot, but they're some of the best comprehensive reference documentation I can think of off the top of my head and are definitely not in a tutorial style.

Well, when many programmers look up something in a reference, they are looking for details about the API (functions/modules/variables/etc), not necessarily a tutorial on how to use those things. Examples can be good, but usually you are not expecting a full-fledged tutorial. Reference manuals are usually full of nuts-and-bolts details. Examples I can think of are O'Reilly books that have titles that end with "Reference" verses ones that start with "Learning".

Basically, I guess, I would like something like the Camel book for Perl 6.

There was one published by O'Reilly about ten years ago, but of course back then you could not say "apt-get install perl6" or something equivalent. Also, the language definition was far from finished, back then, so that book is probably totally outdated by now.

The Perl community, as far as I can tell, has no lack of talented writers, so I am optimistic something will be written before too long.

Another reference you might want to look at is "Modern Perl" (http://modernperlbooks.com/).

And really, I would like something I can read offline, preferably as a PDF. I know we live an always-online age, but really, I want something I can read on the train where I have no Internet access, and I want to be able to search the documentation without having to send a request to a web server.

I am aware there are of http://www.perl6.org/documentation/, but the docs there seem to be ... not organized in the way my brain is used to.

Another reference that just comes to my mind is the Python documentation, which IMHO is superb. It's well organized, concise and to the point, without being spartan.

Just to be clear, I do not expect you to do all that work, but if you want starting points what I would like Perl 6 documentation to look like, now you know. ;-)

> Just to be clear, I do not expect you to do all that work, but if you want starting points what I would like Perl 6 documentation to look like, now you know. ;-)

Indeed and an excellent summary it is. How do you feel about the beginnings of this? https://en.wikibooks.org/wiki/Perl_6_Programming

It is a little spartan at the moment, and it appears to be incomplete (which should not be surprising at this point). But it seems to be well-structured.

I have never written non-trivial amounts of documentation, so I can only guess, but I have the gut-feeling that structuring documentation well is pretty hard, much like interface design (both for APIs and UIs) is (to me, at least) very hard. So having a well-structured but incomplete Wikibook as a starting point is probably a lot better than vice versa. ;-) The parts that are there are well-written.

Partly off-topic, but the Perl documentation used to be really, really good - around Perl 4.x or early 5.x or so. (Not saying it is worse now, just have't looked at it after that.) There used to be (either one or many) PDF files, that had info on pretty much any aspect of the language. The PDFs also looked very good. Excellent font. Not a typography expert, just going by the impression it made on me.

The subtype system is cool, the async too, the custom grammar also.

Given that perl 6 is compatibility breaking, we can category say that if it is not something non-Perl developers should be looking into, it has utterly failed: it means you've made a completely new language nobody should use who isn't already using it!

that said, I don't think it's failing by this metric.

I would suggest you to use Perl only if you have a dmc delorean that can jump 20-30 years back when reaching 88mph

I personally avoid it like a disease... Python + Ruby + JS are wayyy more used and future proof

What exactly don't you like about the way they did the versioning?

Do you prefer what python did? Python 2 vs. Python 3 is a complete and utter mess. Perl, which exists mostly in the same use case, shouldn't have any of those problems.

> Python 2 vs. Python 3 is a complete and utter mess.

Besides being off topic and adding no value to this thread, for those of us who made the transition to Python 3 with minimal fuss, this is just pure hyperbole. I really wish people would quit grinding their Python 2/3 axes.

Are you joking? Off topic? He made a comment about perl doing a poor version transition, and perl was largely replaced by python which also did a language transition. It makes complete sense to bring up python2 -> python3.

I also made the transition to `#!/usr/bin/env python3` fairly smoothly. That doesn't mean that the majority of the community did. Python3 came out in 2008, next week will be seven years of it being out. Yet `#!/usr/bin/env python` still defaults to python2[1]. That's not quite the expected 5 years of transition that they hoped for. At year 5 it looked like this [2].

[1]: http://legacy.python.org/dev/peps/pep-0394/

[2]: https://web.archive.org/web/20131204094939/http://python3wos...

On the short list of places where even those tired of hearing about Python migration problems have to admit the discussion is relevant, I have to imagine the Perl 5 to Perl 6 discussion qualifies.

I've no idea why you were downvoted. Python is indeed going through an almost identical transition, except that 3 does not fix as much as 6.

Python 3 fixes a few things, mostly in Unicode handling. What I've seen of Perl 6 looks like a new language.

The main "problem" of the Python transition is the fact that Python 2.7 is so good.

Perl6 is absolutely a new language. Perl 5 had so many structural problems it was deemed unlikely they'd be solved. Since then however lots of hard work has been done on every side.

The biggest problem about Python is not the superiority of 2.7, it's the hubris of the Python community to think that 2.7 is actually that great.

I would send any Python programmer on a course of writing Golang and Perl 6 and I would put money on the line they would come out a better programmer. That's what I feel happened to me to some extent.

I mean good compared to Python 3 -- for years, all I heard was "what is so much better in Python 3 that I should switch?". Comparing against other languages usually isn't all that relevant as no company is going to move over all their code. Since a year or so, everybody is moving to Python 3.

And for the last years, we've had the bliss of a stable programming language. So much in open source constantly brings out new versions that you have to keep your stuff compatible with all the time.

Your last part is spot on for me. Writing Golang indeed made me a better Python programmer.

That sounds interesting. Could you share some details? Which parts of Golang reveal so much about Python? I'm using Python and I'm thinking about getting more into some compiled languages of similar expressivity like Nim or Go.

When you have to implement things in a "large" language after writing a similar one in Go you'll find yourself coding with a very minimalistic set of objectives. It's a Go-flavored pythonism of sorts. Things like explicit error handling, concurrency, maybe even memory management, will make their way deeper into your work flow and thought processes then they did before, especially if the language you are now using doesn't emphasize them to begin with.

It's this reason why I think learning as many languages as possible is a good thing. I can't imagine what'd I'd be missing out on if I was stuck programming Java 6 for a decade.

> except that 3 does not fix as much as 6

On the logical flipside, 3 also doesn't alter nearly as much as 6. It was intended (and largely functions) as an iteration - not a backwards incompatible re-write.

It's not an irrelevant comparison, but I feel like it's an overstated one.

You're not wrong, but what I'm trying to hilight is that this transition to a compatible iteration is still ongoing nearly a decade later.

python will always point to version 2 because version 2 syntax and version 3 syntax are mutually incompatible; one is not a subset of the other. Making python suddenly point to version 3 would break a huge number of scripts already out there, including numerous setup and configure scripts.

I remember Python 1 and Python 2 having this problem, it was done before, so it's not impossible it would be done again.

Maybe. But those were the early stages of the language. Python 2 has huge amounts of industrial-scale deployment that many people would prefer not to break. There are also numerous systems in deployment that need to have 2 and 3 running simultaneously on the same machine.

> There are also numerous systems in deployment that need to have 2 and 3 running simultaneously on the same machine.

There were numerous systems that needed both 1 and 2 in the Redhat ecosystem. I agree it likely won't happen again, but mostly because the Linux distros have likely learned their lesson. It's the package managers and Linux distros with included system functionality written in some version of Python which have the ultimate say, and there are much better solutions for the problem now than when Python 2 came out. That said, it's possible some distro will make /usr/bin/python be Python 3 and /usr/bin/python2 be Python 2, if they haven't already. Weirder stuff happens all the time.

Ubuntu 16.04 plans for this: https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-...

Arch linux already has.

I imagine /usr/bin/python will be Python 3 then. The cycle continues.

I have yet to write a code where I was unable to make it work on both py2 and py3.

As a former Perl user, and a current Python user (though less lately), I very much prefer the Python transition.

I might be an exception, but I've had very few issues with the Python2 to Python3 transition. Python3 made the language more consistent, made a lot of little things simpler and easier, and added several features that makes using it generally more straightforward than Python2. It's essentially the same language, with warts removed. Library support lagged a bit, so on the odd occasion I need an old library, I just use Python2. Both versions can coexist on the same system, so it's not a big deal.

More relevant, though, Python3 was announced and then released when they said it would be. Some parts of the library community dragged their feet with support, and in a lot of cases they were replaced with even better libraries. The important thing is that the language was out and people could use it, and everybody's on the same page that Python3 is the future of Python.

The Perl transition has been a total mess in comparison. Perl6 is not just removing the warts from Perl5, it's an entirely different language. It's been "right around the corner" for almost 15 years now, and as far as I can tell, still isn't released. And good luck porting 25k CPAN modules to a completely new language.

To put it another way, in 15 years Perl6 has gone from announced to still not existing, while in 8 years Python3 was announced, released, and has had vast parts of its library ecosystem have been ported. Seems hard to believe anybody would say the Perl6 transition has gone better.

> As a former Perl user, and a current Python user (though less lately), I very much prefer the Python transition.

So should anyone, as it changes only minimal sections of the language. It may remove warts, but in my eyes it re-adds many. I never had typing issues with dictionary keys being strings vs ints in Python 2. I do however have to suffer from that in Python 3.

The fact is, Python 3 barely fixes /any/ of the fundamental problems with Python 2. After writing a little Go and coming back to Python i couldn't believe how little static checking there is, for example.

Another example for you, I have functions which take named parameters, but one of those named parameters I need to be a list.

If it's not a list, python's 'for x in y' will split the string and provide a character based loop. If it is a loop it will split based on loop elements.

This means that I have to have a bunch of isinstance checks wrapped around things and provides no safety whatsoever as I would have to exclude all types other than arrays to even begin to have any rigor.

I don't think Python 2 or 3 is a bad language, but 3 fixed only some of the most superficial issues with 2 and still the transition is ongoing after 8 years. You're glossing over how much of a mess it's been and how much it will continue to be.

I'm not glossing over anything, I was relating my experience, and I've had very few issues.

I don't even see what your complaints have to do with the Python2/3 transition. Python isn't a statically typed language, so obviously Python3 isn't going to fix badly written code with type errors.

Regardless, if Python2 to Python3 has been a mess, clearly Perl5/6 has been an even bigger mess because they haven't even managed to release the interpreter, much less start moving to it.

> I'm not glossing over anything, I was relating my experience, and I've had very few issues.

I wasn't trying to imply you're intentionally glossing over things, just that the situation isn't as simple as your post made out.

> I don't even see what your complaints have to do with the Python2/3 transition. Python isn't a statically typed language, so obviously Python3 isn't going to fix badly written code with type errors.

Perhaps I'm wrong, but these errors only seemed to occur in 3, and I've read elsewhere it introduced additional 'hidden' type constraints.

> Regardless, if Python2 to Python3 has been a mess, clearly Perl5/6 has been an even bigger mess because they haven't even managed to release the interpreter, much less start moving to it.

Perl 6 isn't really an interpreter, and the same sort of transition is very unlikely to occur. It essentially is an entirely different language that's just very perl-y.

>>clearly Perl5/6 has been an even bigger mess

The migration path from Perl 5 to 6 is like going from C to C++ or D. Basically there is no 'migration path'. C didn't go away after C++, neither did the whole rewrite C applications to C++,Perl 5 is not going to go way after Perl 6.

>> because they haven't even managed to release the interpreter, much less start moving to it.

They released a beta and production release is coming out this christmas.

Clearly you have a lot catching up to do.

> Clearly you have a lot catching up to do.

TBH, I'm not planning on catching up. I skim through the Perl6 articles that get posted here to see how things are evolving, and AFAICT Perl6 doubled down on all the Perl5 features I liked the least. More "magic"; more arcane symbols and operators; more context aware variables, syntax and semantics; etc.

> And good luck porting 25k CPAN modules to a completely new language.

It will be possible to import most Perl 5 modules with the 'use v5;' feature.

That use case is actually handled by

    use Inline::Perl5;
    use Foo:from<Perl5>;

I can imagine for Inline::Perl5 to eventually end up as a core module like NativeCall, but that's just speculation on my part.

Oh yeah, the correct syntax will indeed be 'use Foo:from<language>;', where 'language' does not have to be Perl 5 (could be C, Java, python...). I'm not sure you need the Inline::Perl5.

I don't think it's implemented yet, and I doubt it will be for Xmas. But it will eventually.

I'm not sure you need the Inline::Perl5.

You do, currently.

I don't think it's implemented yet

It is - nine's Inline::Perl5 module has been around for a year or so.

What is confusing about 5 and 6?

That it looks like a new improved version, while in reality it is basically a completely new language.

One neat thing about Perl 6 is that many Perl 5 "isms" the compiler will catch and inform you of the right Perl 6 way of doing it!

A lot of sysadmin stuff is really well supported in Perl. However, I do a lot of sysadmin work and I've never learned Perl. I use shell scripts, awk, sed, et. al, and when necessary to go beyond that I'll reach for Python (or lately, Ansible) because I find it so much more readable.

I have no plans to look at Perl 6.

Your whole post is you pointing out that you are willfully ignorant. Congratulations.

You are not answering any part of the question.

Reply on news.ycombinator.com