My perspective as a Perl5 dev: Perl6 just doesn't interest me.
The two main reasons: (a) It's still not finished, but mostly (b) all I ever see is people in love with how clever they can be with the language.
I don't need to see hyper-clever ways of using built-in lazy memoised lists to generate a Fibonacci sequence in a dozen keystrokes. If I get tempted over to Perl6 (or any other language) it'll be be by examples of how easy it makes the boring, mundane tasks that I actually need a langauge for - things like reading from/writing to files; handling dates/times nicely; etc. etc.
What I like about Perl5 is its "Make the easy things easy and the hard things possible" mantra. The only mantra I hear from Perl6 is "Look how cleverly you can solve this contrived example". That's not something I care about in the slightest when I think about what language to write my next program in.
A) It's released with a frozen spec and a large test suite for compliance (https://github.com/perl6/roast), with a compiler available that supports a module ecosystem with over 700 modules (http://modules.perl6.org). What's a complete state in your mind? If not this.
B) All of the below is core language, not a use or import anywhere required. Error reporting is also handled for you without autodie and friends.
Reading from a file:
#Efficiently line by line for STDIN
for lines() -> $line {
$line.say;
}
#Get everything in RAM right now
my $string = "filename".IO.slurp;
#Lazy list will do IO as you request into the list
my @lines = "filename".IO.lines;
#Listing of directories if the path is a directory
my @directories = "coolstuff".IO.dir if "coolstuff".IO.d;
Playing with dates:
#Get a DateTime for right now
my $date = DateTime.now;
#Does what it says on the tin
say "Yippee" if $date.later(:5years).is-leap-year;
A) Complete is when the compiler(s) actually implement all of the spec, for starters.
B) Nice examples. Well done. But it's not about whether you can do the simple things. It's more about the impression of the community and where its interest and focus lies.
I'd rather use a language where the mundane day-to-day stuff is the most important consideration. My impression of Perl6, however unfair that may be, is that the day-to-day functionality is the boring necessary evil that must be in there somewhere, but the true focus is the amazing stuff you can do with a language that's simultaneously trying to be a better Perl, and a better Lisp, and a better Erlang, and a better Haskell.
In my mind, Perl6 is a huge lumbering beast that tries to do absolutely everything. I'm sure if I ever feel the need to write a lazy asynchronous parser script, it'll be the first language that leaps to mind. In the meantime, I don't have the time nor the interest to bother.
As a beginner who never used Perl5, I found my first bug (missing method https://rt.perl.org/Public/Bug/Display.html?id=128903) within 24 hours. It does seem like there are some relatively raw things left around.
That said, it seems like a really interesting language.
> #Does what it says on the tin
> say "Yippee" if $date.later(:5years).is-leap-year;
Is that a Georgian or Benghali or Indian or Buddist Era Thai leap year?
Actually are we talking the Georgian calendar - or the Julian, Revised Julian, Coptic, Ethiopian, Chinese, Hebrew, Islamic, Hindu, Bahai, or Solar Hejri calendar ?
I have to admit the documentation for perl6 is absolutely excellent as the very first English prose line on the very first google result answers your very reasonable first question about a date class.
"A Date is an immutable object identifying a day in the Gregorian calendar."
I like a language that's not surprising, with easy to find answers. My experience with Perl over the decades is everything about it meets expectations to a spooky extent, which is also nice. The surprise factor for Perl is very low.
It seems to define excellence in programming language documentation. Is there anything better out there?
Hedgehogs aren't nearly as common road-kill casualties as people tend to think - it's just that their prickles break down really slowly, so we see more of their remains on the road than other animals. Not because so many of them die, just because the evidence hangs around longer.
Yes, it's a good point - it just looks awful so I suppose it registers. High levels of road-kill also indicate that there is enough of a species to become road-kill on a frequent basis. The wet Spring a few years ago caused a significant decline in some bird species, Barn Owls being among them. Biologists knew this because they were finding fewer road-killed owls. So anyway, that's part of the reason I said he "underplays" the road-kill effect, rather than using it as a way to outright dismiss his arguments.
..but it's git. Github don't host your repo - they host a copy of it. You still have all your work in your local checkout. What are you concerned about?
Gettin' real tired of people parroting this. Anyone who has used Github knows there is plenty of data (issues, labels, wikis) that aren't forked when you clone a GH repo.
Not a fair comparison - the store can and will track my habits just as easily via the card I pay with. If I forsake the loyalty card, I don't get my privacy back - I just get tracked via another method unless I go out of my way to always carry enough cash to pay anonymously.
All the loyalty card does is allow them to track the occasional time I DO pay with cash, which is insignificant enough to be worth the discount. If a store made a genuine, binding offer to only track people with loyalty cards, THEN your question would be a valid comparison. At the moment, it just isn't.
"The project that I am gradually preparing for is to build the Gingery Lathe. The late Dave Gingery wrote a seven-part series of books in which he describes how to build a foundry, lathe, shaper, drill press and other metalworking tools from scrap at a tiny fraction of the cost of buying each. For me it’s not so much the cost savings (or the post-apocalypse skills!) as it is the opportunity to learn for myself how tools work at a fundamental level."
I have watched many chapters of the Gingery lathe casting series, because I have always loved process and tooling and youtube is now FULL of amazing documentary footage. I found it strangely enjoyable to watch.
Many parts of machine tools like lathes need to be as flat as possible, because if the surface of the tool is not flat then that error is transferred to the object you are tooling. To get, say, a lathe bed flat, you buy or make a reference flat surface, paint the lathe bed blue, and then rub the surfaces together. The parts where the blue rubs off are the high parts. You take a scraper -- basically a modified chisel that takes off a thin layer of metal -- and scrape down the high parts. Wipe off the paint, repeat until there are no more high spots. It is very tedious.
The two main reasons: (a) It's still not finished, but mostly (b) all I ever see is people in love with how clever they can be with the language.
I don't need to see hyper-clever ways of using built-in lazy memoised lists to generate a Fibonacci sequence in a dozen keystrokes. If I get tempted over to Perl6 (or any other language) it'll be be by examples of how easy it makes the boring, mundane tasks that I actually need a langauge for - things like reading from/writing to files; handling dates/times nicely; etc. etc.
What I like about Perl5 is its "Make the easy things easy and the hard things possible" mantra. The only mantra I hear from Perl6 is "Look how cleverly you can solve this contrived example". That's not something I care about in the slightest when I think about what language to write my next program in.