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?
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.
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.
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.
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.
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.
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.
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.
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?
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:
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:
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" }⏏;
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.
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.
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):
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 ;)
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.
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.)
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.
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".
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.
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.
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. ;-)
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.
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.
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].
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 always felt that programming in perl was fun. Fun don't pay the bills though so over time I programmed less in perl. I suspect that with the perl 6 release a lot of people are starting to go back to it and having fun with it again. And like the author mentions, they improved on a lot of things with perl 6.
Every single annoyance you can find with Python seems thoroughly addressed. Try it and see. Let someone know if there's still major pain points and the #perl6 community would love to hear it.
I wouldn't consider that a good thing. No language is perfect, so if you have no annoyances with a language, you either don't know the language well enough, aren't doing anything interesting enough to run into the annoyances, or lack enough experience in other languages to know what could be better.
Admins were a bandaid 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 Perl scripts spells doom that we (as an industry) are busily automating out of existence.
Basically, fun was had, but fun was not what anyone needed.
>The generally obstructionist principles of the profession combined with the complete lack of discipline in constructing those aforementioned Perl scripts spells doom that we (as an industry) are busily automating out of existence.
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.
I assume the parent is flame-bait... but figured I'd bite.
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.
Note that the same argument could be applied to developers. We can rewrite your statement as:
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.
I don't think so. Companies don't employ sysadmins because they need them to do anything particularly novel that the software engineers couldn't do themselves, they hire them for the liability they provide, and the capability to poke into the running system and figure out what's going on.
I don't see unikernels or docker or whatever sufficiently advanced software you're referring to replacing that.
One question I haven't seen asked in this particular thread is, can it be used in production? What type of ecosystem is available (something like CPAN) for Perl 6 and how reliable is it? Two questions I suppose, but I guess the first one is more important.
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?
I know someone who is a Software Reliability Engineer at Google (sysadmin on steroids is my interpretation of the position) that's written a few back-end tools in it, and I think those were likely shared with his department. So there's that.
I'm totally not waiting. This isn't the first time Perl6 has been 'production ready' It wasn't all those years ago, and won't be in Jan 2016 either. No jobs, no deep libraries, no SDK support... The list is unending. If we'd put 1/10 the time into minor improvements to perl5 over the past 15 years we'd have most of what people seem to like about Perl6 in a language you can actually get a job. Instead we have two languages with no future instead of one...
Likely 'Rakudo Star', which was advertized as a a useful, usable, "early adopter" distribution of Perl 6 back in 2010 (and has had regular releases ever since[1]).
Yeah, that was my thinking, too - but no one was under the impression that Rakudo Star was anything but a sneak preview of Perl 6 - something to fiddle around with, and go, "oh hey, neat!", and not to launch a business on. It answered the question, "just what exactly are you up to?"
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/
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.
chromatic is hardly unbiased in that respect. He has some good points, he's an insightful person and a good communicator, but IIRC he's admitted that he might be at least somewhat biased in his opinions to me here on HN in the past due to his history with Parrot and the past Perl 6/Parrot issues (which is to be expected. I would doubt anyone who claimed to be unbiased with his history).
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.
(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.
Somewhat the same problem with Python as well. I really would like to see Perl 6 become a standard, I guess craigslist uses Perl 6 if anything now that I think about it.
I loved Perl 5. Now when Perl 6 is out, I'm a bit confused about versioning. As far as I understand, perl 6 files are of .pl6 extension. Why would that be different from regular .pl, giving that it's just a new version of a language? I mean, I have never seen things like .js5, .php6, etc. Next, is `use v6;` mandatory? Quite confusing. Am I allowed to do `use v2;`?
Your confusion lies in thinking, as you've said, "just a new version of a language." It's actually been a long, 15-year journey that resulted in a completely brand new language. The name is still 'Perl 6' for historical reasons, but it may as well be called 'Rakudo'; something people've not heard of yet. The Perl 5 language is still being developed and improved, with a major release every year. Hence, the filename distinction.
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.
Of course one can have any extension. Not that it's a bad thing to use .p6. I was just trying to make it clear for myself to understand how beneficial the new extension is. Part of that lies in "marketing" the language. Old school engineers may still want to use .pl, whereas newbies will follow the documentation and have their files prefixed with .p6. My worry is that such behavior may lead to a confusion in Open Source world and push away newcomers from using the language.
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.
The extension is not mandatory. Usually people use .p6, but you can also use .pl . Notice that I've never seen .pl6.
'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.
'use v2;' will not run with the Perl 6 interpreter, but 'use v5;' will work, as the Perl 6 interpreter is specced to be able to run Perl 5, albeit with certain limitations (no XS, for instance).
`use v6;` actually means "use the latest version of Perl 6". I believe you can even do `use v6.b` and other versions to target specific releases of Perl 6, though I'm not sure if that's implemented yet.
Some text editors also will change to a Perl 6 highlighter if this pragma is present.
Rakudo isn't JVM "based", but the JVM is one VM that it targets (also MoarVM, and Parrot. I imagine at some point the .Net CLR will be added). That said, take a look at this[1].
Fair enough. I struggled with how to denote my uncertainty with Parrot's status without implying it was deprecated if it wasn't, so I settled with just including it without any qualifiers.
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.
The situation is really quite different. Perl 6 is a sister language, Perl 5 is still quite actively being developed, and the wait has certainly made many hesitant to begin upgrading. One thing to keep in mind is that Python 2 is just now finally starting to wane, so I am guessing that if Perl 5 does end up going the way of Python 2, it won't be for quite some time.
Not pedantic enough. You didn't comment on Perl being a backronym for REPL! I can't find anything out there about this either. It must therefore only be me :).
>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.
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?