Slashdot Mirror
Perl 6 In Time For Next Christmas?
An anonymous reader writes Larry Wall has reportedly announced at Fosdem that "Perl 6 Developers will attempt to make a development release of Version 1.0 of Perl 6.0 in time for his 61st Birthday this year and a Version 1.0 release by Christmas 2015." From the article: "There is going to be the inevitable discussions, comments and probably some mileage from detractors to come. However ever were it so, for us in the Perl Community these are quite exciting times. We have two strong languages and a strong community, I think there is a lot that binds us together so here's looking forward to Christmas."
...Says No
How's Python 3 adoption coming along? (and they worked so hard to make it forwards and backwards compatible if you remember to put parentheses around your print arguments!)
If I have been able to see further than others, it is because I bought a pair of binoculars.
Perl's strength is that it's expressive. It's not a language which is easy to learn or which generates heavily optimized code.
In the demo phase, you're not really worried about performance. The goal is to have something showing as quickly as possible, and not worry too much about how fast it runs, or how much memory it takes. Overspec your demo system for the time being (ie - make it really fast and install lots of memory), and once you have a reasonable interface go back and recode it in a simpler language which can be more easily optimized.
Languages which are simple to learn (c++, for example) are generally not very expressive. You end up spending tons of time debugging issues of memory allocation, library interface details, and datatype conversion.
Expressive languages are harder to learn, but any individual line in the expressive language does a lot more. Since you are writing fewer lines, and since the fewer lines do more, you end up making programs more easily and in less time.
Yes, the programs will execute a little slower, but as mentioned, this is not important in the demo stage. Your productivity will be much higher. And there are lots of places where performance simply doesn't matter. Scripts usually fall into this category.
Perl was designed by a linguist, not an engineer. As such, it's harder to learn (it's got tons more keywords and context), but once you get the hang of it coding is much more efficient. The following single line:
@Lines = sort { $a->{Name} cmp $b->{Name} } @Lines;
unfolds into several lines of C++, plus a subroutine definition with datatype definitions. The following line:
@Files = <c:/Windows/*.exe>;
can be implemented using one of over a dozen possible library calls in C++, but is builtin in perl. You don't have to look up the library call interface specific to your system.
And note that writing unreadable/unmaintainable code is an aspect of the *coder*, not the language. If you disregard perl because "other people use it to write poorly" you are probably one of those people, in which case you should avoid coding altogether.
I thought it was done over a decade ago but was so different due to strange stuff like 100 different identifiers that no one used it?
http://saveie6.com/
EOM
If the universe is someone's simulation -- does that mean the stars are just stuck pixels?
Version 1.0 of Perl 6.0? Why not just "Version 6.0 of Perl"?
Perl 6 is the developers equivalent of Duke Nukem Forever. I'll believe it when I see it.
You're right. Next Christmas is optimistic.
From a decade ago until now, the Perl devs have spent those ten years improving upon what you either misunderstood or are exaggerating for comedic effect.
Java was rushed out quickly, and early versions of Java made that obvious. Perl6 is the opposite - they've taken all the time needed to perfectly implement their vision, to make it exactly what it's supposed to be. Not everything is nail, so a hammer isn't the right tool for every job, but Perl6 is a mighty fine hammer. If you have a task well suited to what Perl6 is made for, it's a fine tool for the job.
That's a fair point.
Thanks for the info - I'll go brush up on C++ again.
They've been working at Perl 6 for - what? Ten years now? In that time one can develop an OS from scratch. What's Perl going to do? Give you minty fresh breath all day long and unlimited sex with multiple, highly-desirable partners of your choice?
It's farking 6.0. That *is* the farking version. What is the "6.0" thing if 1.0 is the version?
no new Perl.
God, what a nightmare is to try to actually understand existing code from a different coder.
Before you blame me for being my fault, trolling, etc... How come I don't have any problem with any other language?
How come everybody sane I know avoids it as well?
I look forward to seeing what Perl 6 brings. However, I can't imagine it makes any improvements on the core reason I use Perl5. Perl puts no restrictions on how I program and I am able to get something running by myself faster than any other language.
I am an adult and when I am programming for my own enjoyment I don't want to be told how I have to program. I definitely don't want to have to worry about squeezing my design into some Object Oriented bullshit. I want to tabulate my code the way I feel best. If I want to enjoy some dynamic variable scoping so be it. Mix up some functional with some procedural go for it. Create some cryptic one liner that I won't understand later, live and learn.
Bonus points for still serving its original purpose stellarly. Give me some text and I will mold it to how I want. This is what a majority of commercial software does anyways.
I take it you're not a Python user in any form. If you were, you wouldn't have asked such a dumb question.
Python 3's adoption is going very well, in fact.
It didn't negatively affect any existing Python 2 users at all. None were forced to upgrade against their will. Python 2 has seen continued maintenance to support these users.
At the same time, Python 3 has been rapidly maturing. Libraries have been adopting it a good pace, and the implementation has stabilized very nicely. It's trivial to support both versions of the language, and there are even tools to automatically convert Python 2 code to Python 3 code with excellent results.
Users have started to use Python 3 more and more for its better Unicode support, among other advantages. If they're porting a Python 2 code base, they aren't forced into unreasonable deadlines. They were able to migrate at a pace that suited them, thanks to Python 2 being maintained.
As more and more users adopt Python 3, Python 2 will slowly fade out of existence over time. That's the ideal scenario; nobody suffered any negative consequences, and the entire community is now better positioned to move into the future.
If you consider Python 3 to be a "disaster", then I don't even know what the Perl 6 debacle would be considered. It must be a combined tragedy, catastrophe, cataclysm, fiasco, wreck, and calamity, at the very least.
We've been able to use Python 3 to build massive production software systems for years now. We can barely run a "Hello, world!" Perl 6 script at this point with Rakudo Star, which is like the third or fourth failed attempt at a Perl 6 implementation.
Perl6 began July 19, 2000, announced by Larry Wall in his State of the Onion address.
Yes, it will indeed include the feature you requested, via this new operator, which looks much like Perl's other operators: :O ==8
There's actually a lot of truth in that joke. It's been fifteen years not because nothing was being done, but because a lot was done, and done very thoughtfully, after thorough analysis. The goal was not to get it to market quickly (ala Java) or to solve a pressing business need right now (Google's assorted languages and tools). The goal was to do it RIGHT, really right. Based on the Perl idea of right, of course. Perl6 is like Pavarotti - neither everyone's favorite nor appropriate for all occasions, but damn good at what it does.
I hear they changed the name.
Some drink at the fountain of knowledge. Others just gargle.
What exactly is it that you're trying to say here?
Python 3's adoption is going very well, in fact.
It didn't negatively affect any existing Python 2 users at all. None were forced to upgrade against their will. Python 2 has seen continued maintenance to support these users.
At the same time, Python 3 has been rapidly maturing. Libraries have been adopting it a good pace, and the implementation has stabilized very nicely. It's trivial to support both versions of the language, and there are even tools to automatically convert Python 2 code to Python 3 code with excellent results.
Users have started to use Python 3 more and more for its better Unicode support, among other advantages. If they're porting a Python 2 code base, they aren't forced into unreasonable deadlines. They were able to migrate at a pace that suited them, thanks to Python 2 being maintained.
As more and more users adopt Python 3, Python 2 will slowly fade out of existence over time. That's the ideal scenario; nobody suffered any negative consequences, and the entire community is now better positioned to move into the future.
If you consider Python 3 to be a "disaster", then I don't even know what the Perl 6 debacle would be considered. It must be a combined tragedy, catastrophe, cataclysm, fiasco, wreck, and calamity, at the very least.
We've been able to use Python 3 to build massive production software systems for years now. We can barely run a "Hello, world!" Perl 6 script at this point with Rakudo Star, which is like the third or fourth failed attempt at a Perl 6 implementation.
Makes no difference to anybody. Who cares?
Perl is a write-only language? There's more than 1 way to do it? But who wants to look through and understand all the interactions of all the ways?
>. Unless Larry took features away
The first thing decided about Perl6 was that some things would go away, meaning you wouldn't have automatic full backward compatibility. Certain constructs that result in a dense line of punctuation marks were an early example.
To be clear, you can now do those things in a more clear, consistent, general and intuitive way - the power wasn't removed, rather special cases and sparse syntax were replaced with concepts that are more generally applicable, using a more clear syntax.
Since graduating college in 1999, I've been a Perl fan. Yes, it's an awkward language, but one of Perl's mantras is "there is more than one way to do it'. One of Perl's greatest strength is that is doesn't tell programmers how to program. It allows creative programming, which for people like me (admittedly I'm not a great programmer), is a great thing.
Perl is to the Linux and UNIX server admins the duct tape that makes creative systems creative. Beautiful language I hope never really ever goes away.
Python has become the prom queen, but Perl is that slightly chubby girl with the wry smile that is always reliable and willing to go to the dance with you.
God bless,
Perl Man
No, Larry and co. screwed around for 15 years, trying to throw in everything and the kitchen sink, and made a badly designed hodge-podge of a mulligan stew. And Perl 6 still isn't done. The world has moved on, only legacy code in Perl 5. Perl 6 is doomed if it even comes out, nothing of note will be done with it.
I was actually not aware that Perl 6 was still, actually, being developed as "someone may use this for real".
I, unlike many people, like perl. Please don't get me wrong - I'm not trying to flame here. I personally love perl (5), and I'd say it's the language I'm most comfortable/familiar with. It's what I've used for years when I've needed to write something.
But I fully realize that perl is not preferred by many, if not most, these days. It has been replaced in preference by python for many (most?) sysadmins and devops. Legacy mission critical perl code (second to, perhaps, old PHP) is, in my experience, the most reviled thing out there - not because the language is bad, but because so many truly horrible developers (think: those who work on Enterprise Java now for a living) wrote it - and bad perl is worse than pretty much anything and everything else due to how 'creative' it let people be. Most developers really shouldn't try to be creative; it ends badly for everyone but the developer (should he want a perpetual job maintaining the code).
Perl just isn't used all that much anymore, and you tend to get yelled at for trying to do so. I personally think this is sad: what other scripting language will work (often without having to install much, if anything, to get it working) on everything from Windows, to Linux, to FreeBSD, to AIX, and god knows what else, completely seamlessly (assuming it was only written in perl and did not system() stuff all over the place). BASH and even simple SH scripts will not do this.
Perl was written and adopted in the era when CGI was still common, if not still relatively young - almost 20 years ago. In the interim, other languages have come on (ruby, python) which are more pragmatic if you're dealing with common developers with common tasks, and it's use (as well as the many, many modules available for use have gone out of repair. What's more, perl 6 largely fragmented interest in further maintenance/development of perl.
I'm really not sure what perl 6 has to offer over perl 5, or other languages - it does appear to be quite the paradigm change, from what I recall reading a couple years ago... I wish it well but doubt it'll see much adoption.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
FYI it can target most any virtual machine. Parrot is just one. The JVM is another. For example, Rakudo Perl is a Perl 6 implementation which targets JVM, MoarVM, JavaScript and Parrot.
With all the work that has been poured into MoarVM, MoarVM Perl 6 is now painfully slow.
This is a tremendous improvement. The best they'd ever managed with Parrot was "abysmally slow." Before that, perl 6 implementations ranged from "diabolically slow" to "the madness-inducing manifestation of the visage of Gn'oguracha, Elder Slug-God of Unspeed."
A typical statement from a recent presentation: "2013.08 was about 3,600x slower than Perl 5. 2014.08 is 34x slower. Better. But still sucks."
If they keep pouring in the effort, eventually they may reach parity with Perl 5, which was simply very slow. It is unlikely they will ever approach the performance of modern javascript engines, which are just plain slow.
I see you chose the nick "robycodez" to declare your allegiance to Ruby. As you mature in your profession, if you choose to mature, you may find that information systems isn't high school football, and that what works best is to use the right tool for the job. The "fan" thing wears thin as the guy or gal in the office next to you produces validated, documented, elegant, efficient, maintainable, correct systems in half the time it takes with whatever language or vendor you've sworn allegiance to. You may find that he uses Perl for one thing, C for another, Python a week later, and the Python calls a .Net assembly, with translation between them done by declarative xslt. Right tool for the job, he may say, use the right tool for each job.
Interesting comment. Let's take that 1 step further. If you can't easily read programs written by students, doesn't that mean the teaching has been extremely inadequate?
who is waiting for this with bated breath? i think the wait is over, we've moved on from needing anything from perl6.
Legalize the constitution. Think for yourself question authority.
We must have really been naughty.
With all the delays I hope the first and not the second.
Whatever happens: congratulations and thanks to a team who have done so much over the years!
but Perl is that slightly chubby girl with the wry smile that is always reliable and willing to go to the dance with you.
Perl still runs fast.
And, before running, detects typing mistakes in variables when you "use strict;" (which, of course, your editor automatically inserts). Python has this little problem that such mistypings are still a run-time error. When the code that uses them executes. Oh the horror.
I'm spoiled. The Linux Conference Australia people get their videos of all 100+ talks out within days. I've not see the link to the video of Larry's talk. Anyone know where it is?
The likes of Python, Ruby and Node.js have eaten much of Perl's lunch and what they haven't eaten is already served by Perl 5. Unless migration is relatively simple (unlike some previous Perl upgrades), I could well see the world choosing to stay with 5.
No, not shooting the messenger. I understood from what you said that you were not the teacher.
(I notice that, when someone in the U.S. says something unusual, people in the U.S. often feel that the intent may be to attack them.
I suggest you visit Brazil. People are much happier there than in the United States. There are many shortcomings in the Brazilian culture. However, Brazilians are likely to consider that what someone says is just that person expressing himself or herself, and not an attack.)
"... there is some pretty bad code out there in a wide range of languages for whatever reason."
To me, that is a HUGE issue.
There don't seem to be any well-written books about C++ or HTML, for example. My wife and I spent several hours a few months ago reviewing 18 books about HTML. All were terribly written.
Generally, books about C++ don't educate readers about which constructs are appropriate. So, programmers try everything as a way of educating themselves.
So what? Doesn't change my point - perl 6 is still MIA and DOA. Just like the bird in the Monty Python skit.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Personally I think they jumped the shark at Perl 5. My favorite Perl by far was Perl 3 -- when it was a better awk+sed. Now every language seems to want to follow the C++ trend of moving away from it's original strengths ---- and glomming on some really bad object-oriented model on itself during the late 1990's ---- and glomming on some really bad almost-but-not-quite-functional programming features during the 2010's. Seems the programming world would be a better place if the tools focused on their strengts, and didn't all try to be some "oooh, I'm object oriented too", "oooh, I'm functional too" game.
Perl is Finish, Python is Esperanto
Your analogy is especially apt because just as Python isn't perfect, neither is Esperanto.
Given the state of python, ruby, Haskel, etc... It's not hard to imagine that Perl programmers are satisfied with what that had in Perl 5 and patiently waiting to see if Perl 6 is worth the upgrade.
The nice thing about perl culture, though, is you don't have to deal with quite so many people who think esr knows what he's talking about.
'Twas the night before Christmas
When all through the house
Not a creature was stirring
Not even a mouse.
The stockings were hung
From the chimney with care
In hope that St. Nicholas
Soon would be there.
And Ma in her nightgown
And me in my cap
Had just settled down
For a long winter’s nap
When across on my laptop
There arose such a clatter
That I got out of bed
To see what was the matter
Everywhere curly braces
Did litter the halls
And I knew this disaster
Was from one Larry Wall.
I felt woe in my heart
For the many poor coders
Who would follow this prophet
And down many sodas.
Their programs pre-doomed
To illegible hell
'Til the day they heard clearly
Their career path death knell
I did try to warn them
On Twitter and Slashdot
But on they coded like lemmings
Who'd smoked too much hash-pot
But before I despaired, I remembered one fact
Perl 6 had been threatened 'ere machines like the fax!
So I went back to bed full of Christmas Good Cheer
Knowing that Perl 6 would never appear.
Thanks for the recommendation. Is there a particular Scott Meyers C++ book that covers general C++ techniques that you would recommend?
An Amazon search shows other books besides those written by Scott Meyers. So does Google. Also, there is no good way to understand what is the focus of each book, other than reading the very general title and the reviews.
I will start with Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14. Wow, 27 reviews, and all 5 stars.