Earlier quoted context omitted.
Breaking backwards compatibility is a more apt description of that list than major rewrite. Part of the lesson from Python 3 is that large numbers of people will only spend 3 years deciding whether a 5 year plan to make a major change to a 20 year old language succeeded or not.
Agreed. If there's one thing that Bill Gates understood better than everyone else (with the exception of maybe Intel) is that you never break backwards compatibility. You have instantly leveled the playing field for all of your competitors. Why should your users use YOUR new language if there are other languages that already exist and they are just as incompatible as your language?
Why Perl Didn't Win
181–187 of 187 posts
Re: Why Perl Didn't Win
#182Earlier quoted context omitted.
I agree and have made that point before. Java tried to be a language for "enterprise programming", which tried to keep the language so simple that having lots of people wouldn't muck up your code. IMHO, it failed epically at this, and today we would basically laugh at the idea that Java is good at that, but it was in fact a design criterion back in the day. One could make the case that it sort of succeeded at the iso…
The same arguments can be said about Perl. An expressive language is good to work in, because reading 1 line of code instead of 100 is always better for readability and also verbosity is a cause of accidental bugs - one line of code that does the same work as 100 lines is much less probable to contain accidental bugs. Plus, the closer you have code that precisely models the business logic, the more readable it is (as…
> I also programmed in Perl and after 2 years of doing it I would still have problems reading code from other people
> I've seen many superficial opinions floating on the web that a language like Scala is too complicated and then when you ask those people why, it turns out that in most cases we are talking about misconceptions and unjustified fear coming from a superficial understanding of a language
That's generally the same thing I see when talking to people about Perl. I don't know the level of knowledge you gained with Perl, so I don't know if it really applies the same, but from the outside, it does look the same.
I generally view this a a problem of language power AND complexity. Complex languages take longer to learn and be comfortable with, but if the complexity is because they provide more power, what you are really doing is front-loading work to make future work easier, which pays dividends in the end. I think this also fits your description of leverage quite well.
Re: Why Perl Didn't Win
#183Re: Why Perl Didn't Win
#184Earlier quoted context omitted.
> Not at all [can one use CPAN] You are mistaken. See my nearby comment about Inline::Perl5. > not without major contortions [can one convert]. One doesn't need to convert (due to Inline::Perl5). That said there can be valid reasons (eg having fun and learning Perl 6) to want to convert existing Perl 5 code to a Perl 6 equivalent anyway. While some partial P5-to-P6 conversion tools already exist[1] (and I'd be surpri…
Perl5.18 has some limited support for Perl6-style function signatures, but it's still considered "experimental" and requires a pragma to enable. I don't consider that to really be part of the language yet; real-world Perl5 function definitions end up looking like this, at best: sub foo { my ($foo, @bar) = @_; ... } I'm not sure if that's valid syntax in Perl6 or not, but either way it's certainly not idiomatic.
So, to recap:
> Can one even use CPAN with Perl6?
Yes.
A Perl 5 coder might write:
use Data::Dumper;
print Data::Dumper->Dump([1]);
A Perl 6 coder can now use the same Perl 5 module, eg: use Data::Dumper:from;
print Data::Dumper.Dump([1]);
The Perl 6 "adverbial phrase" `:from` at the end of the `use` statement line tells Perl 6 what module loader to use.(Another important `from` option in Perl 6 that's currently being brought up to production grade is `:from`.)
The `.` rather than a `->` in the print statement line is another giveaway that this is Perl 6 code. And the `[1]`; is that a Perl 5 or a Perl 6 array literal? It doesn't matter. This line is a taste of how slick Perl 6 interop magic is. You barely notice it, but the language is automatically marshaling data and objects back and forth between languages as necessary.
Of course, the above is a trivial example. But that's not because complex examples don't work; within a few weeks of starting Inline::Perl5 its author Stefan Seifert was demoing a Catalyst app written in Perl 6. That needed fancy stuff beyond mere passing objects back and forth; in this case Perl 6 code had to subclass a class from another language, in this case Perl 5, and have Perl 5 accept objects made with the subclass as if they were Perl 5 objects made from a Perl 5 subclass.
Inline::Perl5 hasn't yet been smoke tested with all 130,000 CPAN modules, and it will no doubt fail with a few, and a similar story applies for the even more immature support for calling Java libs, but this tech ought to be a game changer, at least within the Perl community.
> Is it even possible to convert existing Perl5 CPAN packages?
There's no need. (See previous point.)
But if you really want to, then yes it is possible, and seems to be enjoyable. Reports I've read of P5-to-P6 conversion stories tend to express satisfaction that basic syntax is generally the same, the changes that are necessary make sense, and the final code is a lot shorter, often half the length, and is very readable.
It's not all roses with Perl 6. There's plenty to bitch about. (#1 is still speed.) But use of CPAN modules, and writing Perl 6 code alongside Perl 5 code, are quickly shifting over to the strengths column for Perl 6, not the weakness one.
Re: Why Perl Didn't Win
#185Earlier quoted context omitted.
One way to look at things is that Perl 6 breaks backwards compatibility with Perl 5. Another is that Perl 6 has well designed language interop and evolution features that make it so easy to nicely use code and libs from other languages that backwards compatibility becomes irrelevant. The big problem with Perl 6 has been that the implementation has trailed the ambitions of the design. But that's changing due to pieces…
Well, not quite irrelevant. Just because language interop is easy doesn't make the fact that there doesn't exist the interop for a library you need. That said, it's also a good chance to get good sane default implementations in first. On of the problems with CPAN is finding the best of the multiple modules available that fit the need.
In the unlikely event there's a module that doesn't work, then yes, you have to learn and wield a new language that isn't backwards compatible. But it is Perlish, and it is designed to coexist beautifully with Perl 5.
Re: Why Perl Didn't Win
#186Earlier quoted context omitted.
Well, not quite irrelevant. Just because language interop is easy doesn't make the fact that there doesn't exist the interop for a library you need. That said, it's also a good chance to get good sane default implementations in first. On of the problems with CPAN is finding the best of the multiple modules available that fit the need.
As I said elsewhere in this thread, Inline::Perl5 hasn't been tested against all 130,000 modules on CPAN to my knowledge, but, based on what I know of the tech and its 100% success rate so far, I'm going to assume until I hear otherwise that it already works, or will do so this year, for the vast majority. In the unlikely event there's a module that doesn't work, then yes, you have to learn and wield a new language t…
Re: Why Perl Didn't Win
#187Earlier quoted context omitted.
Perl5.18 has some limited support for Perl6-style function signatures, but it's still considered "experimental" and requires a pragma to enable. I don't consider that to really be part of the language yet; real-world Perl5 function definitions end up looking like this, at best: sub foo { my ($foo, @bar) = @_; ... } I'm not sure if that's valid syntax in Perl6 or not, but either way it's certainly not idiomatic.
Yes, that works in Perl 6 too. So, to recap: > Can one even use CPAN with Perl6? Yes. A Perl 5 coder might write: use Data::Dumper; print Data::Dumper->Dump([1]); A Perl 6 coder can now use the same Perl 5 module, eg: use Data::Dumper:from ; print Data::Dumper.Dump([1]); The Perl 6 "adverbial phrase" `:from ` at the end of the `use` statement line tells Perl 6 what module loader to use. (Another important `from` opti…
P6's speed is still well behind Perl 5, but it's catching up very, very quickly.
And performance improvements won't stop there: https://fosdem.org/2015/schedule/event/perl6_beyond_dynamic_...