Perl 6 is fun
blog.urth.org
blog.urth.org
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?
The regex system is also part of grammars, which did not exist natively in Perl 5.
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.
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.
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...
The main "problem" of the Python transition is the fact that Python 2.7 is so good.
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.
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.
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.
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.
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.
Arch linux already has.
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.
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 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 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.
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.
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.
It will be possible to import most Perl 5 modules with the 'use v5;' feature.
use Inline::Perl5;
use Foo:from<Perl5>;
I don't think it's implemented yet, and I doubt it will be for Xmas. But it will eventually.
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.
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
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.
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.
> 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.
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.
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.
I have no plans to look at Perl 6.
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.
He's also pretty good at telling jokes, which explains a lot of things about 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.
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.
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.
[0] at https://docs.python.org
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.
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. ;-)
Indeed and an excellent summary it is. How do you feel about the beginnings of this? https://en.wikibooks.org/wiki/Perl_6_Programming
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.
that said, I don't think it's failing by this metric.
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?
Are you talking about something like this:
$hash_of_hash = {
hash1 => {key1 => 'value1'},
hash2 => {key1 => 'value1'}
};
say $hash_of_hash->{hash1}{key1};
I think reference syntax in Perl6 is gone. Which personally I don't like.
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.
%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}
or
$($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.
%hash = (hello => 'there');
%hash = ('hello', 'there');
print Hello => ' ' => there => "\n";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! my %hash = (
# your key/values
);
my %hash = {
# your key/values
};
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
)],
},
};
print $hashref->{another_hashref}->{key_name}->[2]; #an
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" }⏏;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.
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.
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.
Well, there is Inline::Python...
This was not its reputation BITD.
I personally avoid it like a disease... Python + Ruby + JS are wayyy more used and future proof
I think a lot of sysadmins have made their living by writing perl for the majority of their career.
Certainly there are more people writing perl today than lisp, golang, rust, or haskell.
The question to me is, is there a reason to go back to perl? I don't know the answer.
There you go. Now you do have an annoyance with Python.
But I know you're just being flippant. ;)
Basically, fun was had, but fun was not what anyone needed.
Anyway, that is my little digression.
I don't see unikernels or docker or whatever sufficiently advanced software you're referring to replacing that.
This is probably the most arrogant statement I've heard on Hacker News as somebody who has worn both the software engineer and sysadmin hat.
"Obstructionism" is what engineers, decoupled as they are from the realities of the hardware by their VMs and containers call "due diligence". As a sysadmin, I need to be assured and ensure what you want from the software ecosystem around the ball of lint you pushed onto me will not affect other line of business applications that make the company money. That is what I am hired to do, along with fixing the whole mess when it breaks. So a little due diligence and research is necessary to make sure that everything still runs.
The reason that many of the Perl scripts a sysadmin writes show "complete lack of discipline" is also a testament to the "ooh, shiny!" mentality of many engineers. We already have a database system for reporting, so why are you scribbling out report files? We have an automated system for dealing with system restarts and service restarts, so why are you doing it in the non-standard way? Remember, by the time I see your code it's too late - it's already written and has been approved by management, and rewriting it or changing it is too expensive at this point so I have to work around your complete lack of regard for the standards that keep things running.
Just something to keep in mind next time you complain about "obstruction" and "inconsistency". I only put into place what you make, so perhaps you should spend some time looking in the mirror.
Your comment is akin to saying "now that we have biologist/geneticist/etc, we no longer need doctors". Admins/Systems engineers are closer to a "true" engineer, than a developer. Developers are closer to a researcher/scientist in some respect.
Most developers ( specially app developers ), have a VERY limited scope/domain of skillsets. Your average web front end developer is great at taking business requirements and making that into a web app, but has usually zero clue of anything beyond that.
"admins" or systems engineers, should be ( and I'd admit, in many places they aren't), just like Systems engineers in any other engineering field. People who hold interdisciplinary skills ( networking and systems knowledge, specific systems knowledge, programming skills, etc ), and are able to manage complex system through their life cycle. They deal with requirements, logistics, coordination, etc, as it applies to the engineering system.
This need will always be there. If anything, more complex software gets rid of the need for different level of app developers. As frameworks become "cookie cutter", business requirements to application may be able to be fully automated. And developers may, in a not so distant future, just be responsible for building such frameworks.
Put it this way, "admins" were thought of by Charles Babbage. There will always be need for them.
note: some companies have just delegated admin and system engineering duties to app developers. That's just an HR system, not a cure as you make it.
Developers were a nadaid for the period where insufficiently advanced software existed. The generally obstructionist principles of the profession combined with the complete lack of discipline in constructing those aforementioned sites and programs spells doom that we (as an industry) are busily automating out of existence.
Whatever your arguments are against that reasoning, it would be interesting to see if they also applied to system administrators.
Not true at all. Thanks to perl I have been working high paying jobs from home since I was 19.
And I always get banks or other big companies contacting me because they need a UNIX/Perl programmer or a sysadmin
Edit:
What I really mean by "can it be used in production" is really: is anyone using it in production and what is their experience with it and their recommendations?
For now, it's fun to see what the future will bring. I'm excited.
I'm curious, what exactly are you talking about?
Here's how it was described in 2010:
Rakudo Star is aimed at “early adopters” of Perl 6. We know that it still has some bugs, it is far slower than it ought to be, and there are some advanced pieces of the Perl 6 language specification that aren’t implemented yet. But Rakudo Perl 6 in its current form is also proving to be viable (and fun) for developing applications and exploring a great new language. These “Star” releases are intended to make Perl 6 more widely available to programmers, grow the Perl 6 codebase, and gain additional end-user feedback about the Perl 6 language and Rakudo’s implementation of it. http://rakudo.org/2010/10/28/rakudo-star-2010-10-released/
In 2015, it's described as being in, "beta". http://rakudo.org/2015/11/28/announce-rakudo-star-release-20...
Although the gp doesn't post much, they are obviously a busy, respected, and influential member of the Perl community. I'm confused why they are so doom and gloom over this amazing new language (Perl 6) that is nearly a stable release.
Cf various rants by chromatic, eg http://www.modernperlbooks.com/mt/2013/02/goodnight-parrot.h...
That said, his recent comments on HN regarding this issue seem to only half the time making a cogent argument, and the other half the time being pithy snipes, and at this point I'm not sure he's not working with vastly outdated information.
https://news.ycombinator.com/item?id=8982742
(I find particular amusement in rereading Moritz's post in that thread.)
I would doubt anyone who claimed to be unbiased with his history
It's certainly possible that a mysterious GitHub error revoked my commit access late one night, but the timing seems suspicious. I'll own up to my mistakes, but the rewriting of history seems unfair.
With regard to you admitting bias? I don't recall specifically, we discussed it in depth a few times, so it could very well have been a feeling I left with and not a specific statement (and I'll fully admit I might have been projecting).
> I would doubt anyone who claimed to be unbiased with his history
What I meant was that was that anyone who has a complicated past where they feel misrepresented and that they were treated unfairly is bound to be biased in some way, and to claim otherwise would show a lack of introspection. It wasn't meant to be insulting, or something I thought you should feel the need to defend, it's more a general worldview of mine. Bias is hard to overcome and harder to eliminate. There's plenty of things I would like to think I'm unbiased about, but in reality I'm probably not.
I'm getting a strong feeling of Deja Vu. I think we may have had this discussion or one like it previously.
> This isn't the first time Perl6 has been 'production ready'
> No jobs
> no deep libraries
> no SDK support
> If we'd put 1/10 the time into minor improvements to
> perl5 over the past 15 years
'use v6;' is not mandatory either, but it allows your program to display an helpful error message if you try to run it with the perl 5 interpreter. Try "perl -e 'use v6;'", you should get:
Perl v6.0.0 required--this is only v5.20.2, stopped at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
Check your Rakudo's tools folder.
However, it's just a convention. You can have any extension you like (at least on *nix).
And to answer your question, no "use v6" is not mandatory. It's there so if you run your script with a perl (and not perl6) interpreter, you won't get confusing errors.
I've been following the journey for, more or less, the past 10 years. I hope that whoever spent those 15 years on developing Perl 6, will reap the rewards.
https://github.com/search?utf8=%E2%9C%93&q=%22use+v6%3B%22&t...
Some Fortran people do it.
Some text editors also will change to a Perl 6 highlighter if this pragma is present.
Given that Rakudo VM is JVM based, I expected that there's some interoperability layer for the host JVM, but could not find anything.
Does someone know whether this is possible?
The JVM is just one of the backends, but it's fallen a bit by the wayside during the current effort to get 6.0 out on MoarVM.
I expected that there's some interoperability layer for the host JVM
There is, but I'm unaware of proper documentation. For now, you might want to take a look at https://github.com/rakudo/rakudo/blob/nom/t/03-jvm/01-intero...
1: https://perl6advent.wordpress.com/2013/12/03/day-03-rakudo-p...
Insofar as there is a "Rakudo VM", its MoarVM, which is not JVM-based; Rakudo also compiles for the JVM, and there's some documentation on interop floating around, but most of it seems to be both old and indicating that the JVM interop was in flux at the time.
PERL is a shuffling of REPL
http://perldoc.perl.org/perlfaq1.html#What%27s-the-differenc...
Welcome to the Perl subculture!
>Welcome to the Perl subculture! I was at the time also in the Slackware subculture, Church of the subgenious. It got very foobar.
Tried learning Perl since highschool, it was too much of a mindF* for me to get going with. chomp? regex! Phew.
Maybe with Perl6, it's time.
>fun
Pick one and choose wisely.