Slashdot Mirror
Perl 6 Gets Beta Compiler, Modules and an Advent Calendar (thenewstack.io)
An anonymous reader writes: A "useful and usable distribution of Perl 6" was released Saturday, a new beta version of the Rakudo compiler to support the coming production release this Christmas. And there's already 467 Perl 6 modules on the new archive at proto.perl6.org (though Perl 6 will also be able to load modules written in other languages). "Perl has a huge community of avid users that continues to thrive in spite of detractors," says one developer, pointing to new applications for big data, in a new article reporting that over one million people have downloaded ActivePerl's own Perl distribution just in 2015. And this week also saw the release of two new "Advent Calendars" of programming tips, one for Perl 5 and one for Perl 6.
That's always a sign of a healthy and thriving development language.
I've used Perl since the first release, gotten pretty good at it 5-6 times over the years, and loved it for it's capabilities. But I've also become disgusted with the whole idea of There's More Than One Way to Do It. What TMTOWTDI means in the real world is that, if you have to maintain someone else's perl script, you're in for a world of hurt unless you're a guru at it.
I don't want to bash perl, it was a great solution back in the day. But nowadays I tend to solve perl problems in either Python or Java (don't get me started on Java, please...). They may be a bit more inconvenient and awkward for some tasks, but when push comes to shove and I have to modify a script I've never seen before I don't have to pull 3 books off the shelf and thumb through them wondering "WTF?"
As somebody who has used Perl since Perl 3, I've been following the Perl 6 disaster on and off since its very beginning around 15 years ago.
As somebody who also relished the fantastic Perl and CPAN communities of the 1990s, I'm sad to say that I've generally been quite ashamed of the Perl 6 community.
First and foremost is their inability to get anything done. Seriously! They've fucked around with so many incomplete implementations now that I've lost track. Rakudo is just the latest failure in a long string of Perl 6 failures.
Second is the way they've handled criticism of Perl 6. I see people on Reddit and HN make good points about how awfully Perl 6 has been handled, and these people are savagely downvoted by the Perl 6 community.
Third is the way they claim that Python 3 was a disaster, when the opposite is clearly true. Python 3 improved Python 2 in important ways, it's well supported by libraries, it sees frequent updates and improvements, and most importantly they've been able to deliver stable production-usable releases for years! Python 3 has been a resounding success in a fraction of the time it has taken Perl 6 to go absolutely nowhere.
Fourth is the way that Perl 6 isn't actually that much of an improvement over Perl 5, assuming that it actually is an improvement at all. This is difficult to evaluate because of the lack of reliable, complete implementations.
Fifth is the way that they've tarnished the reputation of Perl as a whole. Now when people hear the name "Perl" they think of Perl 6 and its 15 years of screwing up. They no longer thing of the scripting language that, while maybe not the prettiest, was damn expressive and very effective to use. "Perl", which once evoked a sense of pride in many people now evokes a sense of disappointment and shame.
Even if the language does turn out to be better than Perl 5, I don't think I'll even bother using it. I just don't want to have to deal with the people who make up its community!
Perhaps it was momentary insanity, but I expected the syntax of Perl 6 to be more readable and less obstuse. Looking through the Perl 6 advent calendar, I noticed that, somehow, the people working on Perl 6 seem to have made it even worse.
Perl will always be the ugliest language in the world.
Love sees no species.
The Perl 6 logo is unbelievably childish. Even if Perl 6 were actually usable, I couldn't suggest it to my boss or colleagues. They'd take one look at the Perl 6 home page, see the immature logo, burst out laughing, and think I was joshing them, even if I was completely serious! I thought the decade of failure was bad enough, but seeing that logo makes things even worse!
Let me guess: you didn't like Clippy either.
perl who?
Sorry perl, your day, which you never deserved to begin with, is OVER.
LOL@vword: agreed
Perhaps it was momentary insanity, but I expected the syntax of Perl 6 to be more readable and less obstuse. Looking through the Perl 6 advent calendar, I noticed that, somehow, the people working on Perl 6 seem to have made it even worse.
Perl will always be the ugliest language in the world.
Perl isn't meant to be simple, it's meant to be expressive.
A simple language is wordy, requires a lot of typing and keywording to express a thought. Cobol has things like "move a to b", which is simple and readable, but requires a lot of typing. Basic has things like "for index = 1 to 10 step 2" which is very readable, but requires you to type out "step" and "to".
Perl is meant to be terse and expressive, which in practice means that things you typically want to do in programming can be called out in short sequences. Larry took a look at all the things that programmers want to do and encapsulated them in the syntax as a sort of short hand notation. Sort of like how emacs macros do complex things tersely, which could also be done with a bunch of keystrokes.
Perl is also a non Von Neumann language, meaning that it does not reflect the underlying Von Neumann architecture. It focuses on functionality instead of the machine, and as a result things like file operations are part of the syntax and not a library call.
For example, variables do not represent memory areas like they do in C. This allows Perl to do things like automatic allocation and garbage collection, and be unicode compliant. (Characters are not specifically 8-bit entities in Perl.)
This means that a lot of what you do in Perl is completely portable across architectures. File I/O and filename searching are part of the language, and thus not architecture specific.
Sometimes these are important. Being able to run on multiple architectures, or getting a prototype up and running quickly, or not having to debug allocation errors makes the act of programming more efficient.
...but at the cost of requiring the programmer to know a more complex syntax.
After observing above that Perl and Python have converse philosophies on the point of "There's more than one way to do it," I realized that a Zen of Perl could be formulated by creating the Zen of Python's evil twin:
Ugly is better than beautiful.
Implicit is better than explicit.
Complex is better than simple.
Complicated is better than complex.
Nested is better than flat.
Dense is better than sparse.
Obscurity counts.
Special cases aren't ordinary enough to follow the rules.
Although obtuseness beats clarity.
Errors should sometimes pass silently.
Unless you tell them to die.
In the face of ambiguity, refuse the temptation to delineate.
There's more than one way to do it.
Although those ways may not be obvious at first unless you've consulted the manual.
Fifteen years is better than three.
Although never is often better than *fifteen* years.
If the implementation is hard to explain, it's a good idea.
If the implementation is easy to explain, it may be a bad idea.
Namespaces are one honking good idea -- let's use as many as possible!
Presumably, this applies to Perl 6 as much - if not more - than to Perl 5. Otherwise, exactly what sort of "improvement" is Perl 6?
(with apologies to Tim Peters for applying a little Artistic License to his fine work.)
I look forward to the day that Slashdot is rewritten in Perl 6. Heck, maybe it can even be used to breathe life back into the late great Beta.
Aha! A Python-eer in Perl-monger clothing!!
O vile Apostate! May your Python 3 and all of its descendents forever live in the shadow of Python 2!
Since the Apostate hath claimed to have been a devotee of Perl, let us, the faithful Perl-Mongers, treat him as the apostate he is and casteth his anonymous screed into the depths of -2 anonymity.
May all the faithful cast aspersions and down-votes upon the vile post of the parent!
Cool nostalgia trip, but fuck that shit.
If you were to learn a new scripting language today, would you start with Perl or Python?
But.. but... what about the separation of Church and Perl?
I'd start with Javascript. It's not just for making annoying websites anymore. In the last five years it has gone though some amazing advances, culminating in ECMA6 this year.
Can we please add suicide as a third option?
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
I'm actually faced with this dilemma now, and I'm strongly considering Perl 6. I have to do a considerable amount of work with configuration files and text parsing as part of my job, and I'm willing to bet Perl can still do that better than anything else if I can achieve enough mastery in it, since that's basically what it's designed for. And Perl 6 is supposed to finally be adding objects, which was one of my big turn offs for Perl 5, so I'm hoping it will be a good fit for me. Also, I'm often under the gun when I'm doing this work, so something terse and expressive seems best.
Note - I tried filling this role with Powershell over the last few years, but it's a huge pain in the butt. It's hard to debug, and while I love the fact that it uses objects everywhere, it's not so great when I want to use "select-string" to grep some text and Powershell returns some crazy "match-info" object with all kinds of other nested objects I can't hardly begin to decipher (and this happens a lot... you want a command to return something simple and it returns some crazy complicated object). And creating a new object or class of your own on the fly in Powershell? Royal pain in the butt... better create the class in C# and import it. It just got to the point where I felt like it would be easier to write most of my stuff in C# to start with than use Powershell, unless it was just to run a series of Windows commands for which Powershell cmdlets had already been written.
I guess if Perl is too hard to learn though, I'll join the revolution and try Python. But I don't think I'm going to start there.
Beware of bugs in the above code; I have only proved it correct, not tried it.
If you were to learn a new scripting language today, would you start with Perl or Python?
no, i wouldn't start either. instead i would start with learning POSIX shell scripting because it will run on anything remotely POSIX-y.
Anons need not reply. Questions end with a question mark.
It's funny how everyone here says "No one is going to try that". Actually, Perl 6, if it releases by Christmas, will probably be the hottest language around in the next year or two. And I'm not necessarily saying that because of it's merits (which I have not definitively assessed one way or the other). I'm saying that because developers are pretty much all about "Hey new shiny thing over here!".
It seems like pretty much every time a new language drops there's a stampede to it by developers just because its new. Hey, Ruby on Rails! Hey, there's C# over there! Hey, F#! Hey, Erlang! Hey, Javascript framework of January! Hey, Javascript framework of February! Hey, Javascript Framework of the second half of February! Whoa look, it's Coffeescript! ......... Hey, it's Perl 6!
Some of these of course are decent languages and frameworks and have staying power... others, perhaps not as much. We'll know after five years or so where Perl 6 is going to end up. But don't underestimate the ability of developers to stampede at something for no other reason than that it is new. I expect considerable chatter at some point just because it's the new kid on the block.
Beware of bugs in the above code; I have only proved it correct, not tried it.
Agreed.
When you have to do flips to find ount something like
if ($foo ne "Email") fails when you read a line in because while it is Email only without the quotes, there' s something wrong.
And in strawberry, why can't you use say ? say is supposed to let you print without having to do \n.
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
| A simple language is wordy, requires a lot of typing and keywording to express a thought. Cobol has things like "move a to b", which is simple and readable, but requires a lot of typing. Basic has things like "for index = 1 to 10 step 2" which is very readable, but requires you to type out "step" and "to".
I have learned how to type and I can type "step" and "to" rather quickly now, and certainly remember what they mean, a whole bunch faster than remembering what ^%::() means, right now in this file in this programming language given that I have to sort of remember 5-7 of them for my job.
I'm just an ordinary human with an ordinary human neocortex. Us in the hoi polloi have evolved brain circuits for natural language which have been trained to recognize sequences of letters known as words, and we've learned what they mean somewhat automatically since we were about 4 years old.
Note that when we have to explain "for index = 1 to 10 step 2" we don't say,. 'well of course it really means j/x&&*10(2)", but instead we use the communication protocol which has words in it. A cortex is not lex and yacc.
No. Perl is not new no matter how much they tard [sic] it up. It's a great language for scripts and text manipulation that a bunch of hack sysadmin types started writing inappropriately large apps in.
Perl is the pinnacle of what a perl based language can be and nobody halfway smart will lock themselves into perl again.
If you're doing text manipulation, Perl's probably the way to go. The base language is set up well for it, and CPAN is full of text manipulation libraries.
I'd never suggest Perl as a first language, but it sounds like you've got other languages under your belt already.
I'd hate to use it outside of UNIX, though. Perl's very UNIXy. But I came to it as a sysadmin, not as a programmer, and I use it as a glue language more than anything else, so maybe that's just me.
Perl 5 has objects, BTW. The syntax is just weird for them. It's no worse (and probably better) than Javascript's funny OO system.
Those who can't do, teach. Those who can't teach either, do tech support.
She's dead, man. Let her go.
The Fall Of Perl, The Web's Most Promising Language http://www.fastcompany.com/302...
5 Programming Languages Marked for Death http://insights.dice.com/2014/...
Perl is Dead. Long live Perl. http://archive.oreilly.com/pub...
Meta-troll: Mod me a troll. Do it! Do it! Waste your shiny mod point to make my dream come true.
This allows Perl to do things like automatic allocation and garbage collection, and be unicode compliant.
Exactly! That's exactly why slashdot was written in Perl!
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
I have no doubt people will try it. I just don't think anyone of consequence will stick with it.
All those other things you mentioned have one thing in common - they're still used by people to get work done, and even used in new projects in some cases. Perl on the other hand has been steadily phased out over the last 10 years.
ES6 is moving JS closer to looking like Java. ES7, due out next year, does so even more. With Babel & Webpack, you can use ES6 today.
... nobody cares.
If you are tweaking config files, use Ansible.
Sure, I've written config management systems at many different jobs, but ansible does this much better and in an easy-to-manage way. Cross-platform for certain values of "platform".
I develop and maintain a product with a medium-sized code base in Perl 5. We have pretty thorough style and coding guidelines and the Perl is quite readable and maintainable. One of the nicest things about Perl that hardly anyone mentions is POD --- the abiility to put documentation right in the .pm files. This makes it much easier to keep the docs and the code in sync.
But yeah, Perl 6 is a disaster and some of its ideas have started to infect Perl 5 modules with ridiculously baroque and over-engineered code (I'm talking about you, Moose.)
Anyway, even the Perl 6 people admit that Perl 6 is not an upgrade to Perl 5, but a different language. So I'll ignore it and continue reasonably happily on Perl 5.
POSIX shell scripting is all fine and dandy until you deal with filenames with spaces in them, at which point it's nothing but tears. Shell script variable substitution is a real pain to get working in all situations.
Yeah, I saw that. It's definitely a step in the right direction.
Javascript is schizophrenic to the extreme. It's always struck me as a poorly implemented LISP that was pounded into something that looked like C. It's not so horrible once you get to know it, but learning it was a major pain in the ass.
My university is considering making it the first language they teach. I suggested to the instructor that it was probably not a good idea.
Those who can't do, teach. Those who can't teach either, do tech support.
Can anyone find the earliest Slashdot post about the coming of Perl 6? Could of sworn it was close to 20 years ago...
I used to do a lot of glue code with Perl. Its regular expressions, various perl modules, many documented solutions made it very handy indeed for tasks like stopping webservers, rolling log files with time-date stamps, archiving old log files, restarting the webserver, etc. It was also good for parsing large data sets that come as flat text files and putting them into MySQL or what have you with good error checking.
A fairly common task would be to take a variable with a value that has a Quote in it: name=O'Neil and escape it or something to insert into MySQL. Perl handled that well.
I switched to Ruby for these tasks for the following reasons:
A. More active development and a more active development community.
B. Better MySQL and PostrgreSQL driver support.
C. Better example documentation and online examples for things like inserting values into a MySQL database.
D. Object Oriented from the start -- once you start doing object oriented programming even fairly simple "glue code" tasks that are utility based become far easier.
Perl really shined as a way to quickly get things done. Now I use Ruby. Examples would be calling rsync in Linux and robocopy in Windows to backup or restore various data files from or to USB.
Yeah, I could use Python for that. I don't like the space stuff for syntax, Ruby is quite good enough for glue code, heck I've even written some Monte Carlo simulations which took me less time than constructing an Excel spreadsheet and was easily imported into R for analysis and graphing.
I think Ruby not Python is the main successor to Perl as a utility coding language. I've never coded in Rails, have no interest in that. But I do code fairly often to automate repetitive tasks or do Monte Carlo sims or stick stuff in databases and for that Ruby works ...
Elegantly. It does indeed put a smile on my face when I use it.
What happened to the parrot?
From one old guy to another, I'm glad we can both have some fun with it. :-)
From one old guy to another, I'm glad we can both have some fun with it. :-)
Us oldsters have all the fun, because we've tried everything and we can remember what was good versus what caused a sucking chest wound.
Just cruising through this digital world at 33 1/3 rpm...
As someone who has recently been tasked with using Javascript for scripting (rather than web pages), this is my immediate evaluation which, if I know Slashdot, you guys will set me straight on if I'm incorrect :-)
The base language itseld seems to have far less library meat than other languages (secure FTP was the one I needed most recently). And, if you decide to use Node.js to get such stuff, it appears to enforce on you the async nature of web pages which doesn't make sense for sequential scripts.
Now granted, I'm just a beginner at this particular aspect, but it seems very difficult compared to, say, Python which I'm way more familar with.
Nobody liked Clippy. You don't win that one, Nostradamus.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});