Perl was the language that I used many years ago but I moved on. Perl 6 was announced in 2000 and took over 10 years to see a release and by then most developers moved on like I did. When a language takes that long between releases there's clearly a lack of enthusiasm and support for the language. And touting market share? That is a pointless argument. You should be working with multiple languages and move past these silly blog posts.
Perl 6 was supposed to be an upgrade but it kept changing. I lost interest and know I will never use it. And if it is a totally different language why is it called Perl?
The same guy (Larry Wall) who originally wrote Perl 1 to 5.6 is the one who is writing the spec (though not the implementations) for Perl 6. People let him do it out of respect, even though it's disastrous for Perl 5.
I've seen quite a few people describe Python 3 as a new language relative to Python 2. Having used both now, I don't agree at all, but I have no experience whatsoever with Perl so I'm not in the same position to compare the different versions of it.
Are there really more differences than things they share in common, to the extent that "new language" is an accurate description?
I think it is correct to view them as related, but definitely not the same language.
A short example from the recent Perl6 calendar[1]:
Perl5:
package Timer;
use Time::HiRes qw(gettimeofday tv_interval);
use Mojo::Base -base;
use experimental 'signatures', 'postderef';
has _event_log => sub { [] };
has _start_time => sub { [ gettimeofday ] };
sub record ($self, $event_description) {
# record the event and timestamp
my $event = {
timestamp => sprintf('%.3f', tv_interval($self->_start_time)),
description => $event_description,
};
push($self->_event_log->@*, $event);
}
sub report ($self) {
# render a full report
my $report = '';
foreach my $event ($self->_event_log->@*) {
$report .= sprintf "[%s] %s\n", $event->{timestamp}, $event->{description};
}
return $report;
}
1;
Perl6:
class Timer {
has $!start-time;
has @!event-log;
method record ($event_description) {
# initialise the start-time if this is the first time through
$!start-time //= now;
@!event-log.push({
timestamp => now - $!start-time,
description => $event_description
});
}
method report {
my @report_lines;
for @!event-log -> %event {
@report_lines.push("[%event<timestamp>.fmt("%.3f")] %event<description>");
}
return @report_lines.join("\n");
}
}
Frankly, I'm of the opinion that it's a good thing Perl6 hasn't come out yet. 10 years ago, I would have welcomed it. Now though, it's 2015. We have a plethora of very nice languages. Many of them are statically typed but still fairly expressive. In general, dynamic languages are still more expressive, but the gap is much narrower. It becomes a question of if the size of that gap is wide enough to justify using Perl, Python, Ruby, or etc over something safer. Personally, I'm feeling "no".
@Animats, this is very true. Many only want to use languages which are considered easy. Ruby and Swift are examples of the easier languages which allow developers to avoid issues like memory allocation bugs. I do find that the side effect of using simple languages, relying heavily on frameworks and easy to use dependencies leads to complex applications which the developer does not really understand. The extreme example is a WordPress site which is slow or buggy and the "developer" who put it together does not know why much less appreciate what is going on in the MySQL database. I wonder how many developers are even capable of doing this low level work in relation to the total number of people who call themselves developers.
There was some discussion of joining forces in the early days of LLVM (ca. 2005 I believe), but for various reasons that did not go forward. Licensing is indeed a big issue: GCC has had the explicit goal of making proprietary plugins technically infeasible, which leads to avoidance of some modularization/decoupling opportunities.
They already do- for a long time before Clang was ready for prime time, the default compiler on OS X was GCC with an LLVM back end. I'm not sure if any of this ever got merged into mainline GCC (the work was done on a pre-GPLv3 fork of GCC), but the code is widely available per the terms of the GPL.
The problem with click-bait is that it's so omnipresent with websites like BuzzFeed that if a journalist uses a non-factual title for an opinion piece, people say it's click bait. IMHO it's really fine in that case.
This. It does not deliver on the promise in the headline, and the headline exists only to make you simultaneously infuriated, confused or curious. If someone posted a comment with those properties they would be banned from HN.
Nope. The arguments in this piece are way off base. This is also now a very old argument which has been rehashed too many times. Modern wisdom shows us that native mobile apps have their place and Apple, Google, Mozilla and others are rapidly advancing web technologies. They are hardly holding back in order to force developers to build native apps. Once SVG, Canvas and other powerful HTML5 features become more common along with a more powerful runtime for the web, we will see the situation change. For now, I am happy building and using native mobile apps. I also build responsive web pages and plan on continuing doing so. They can coexist and they should.
I hear you. You're saying that the two things can exist symbiotically and I can't disagree. I think it makes sense given what's happened until today, but I think the open source way is far more sustainable and will yield far better results. We need developers to start thinking about what implications are carried with their decisions. I disagree that my arguments are "off base" or have been rehashed too many times, but I invite you to elaborate on that further.
My issue with how things work currently is that logging into a native mobile app is not nearly as easy as logging into a website. That process has to improve. That why I like logging in with Facebook, Twitter or GitHub.
Still what I would prefer is a single trustworthy service which does not compromise my privacy for the purpose of advertising. I could use that service to log into any service which would integrate with this single service to get a one-time password to the user on the computer or mobile device they are using.
As the user I would be able to use an mobile app and browser plugins to get the one-time password to conveniently log in with as few steps as possible.
The problem clearly lies with mobile platforms that lack any option of extendability. This is by design, and as usual, at the expense of your privacy and security.
