Live data from Hacker News

The Perl 6 project 10 years old today

use.perl.org

51–59 of 59 posts

Re: The Perl 6 project 10 years old today

#51

Earlier quoted context omitted.

> I can apply what I've learned using a "language" unprecedented in flexibility and capability. This right here is what I've always hated about the perl community. It's so rare to find a perl user who can mention the language without spouting these kind of exaggerations and untruths. Of course you could always prove me wrong by demonstrated how perl is "flexible" and "capable" in a manner that is unprecedented [1]. […

Do you know of another language community with a library or extension system which rivals the CPAN, for one example? How about the existence of PCRE for another? Along those lines, have you seen Perl 6 grammars?

The post I responded to said "language" so your comment about CPAN doesn't apply.

On the second part, I did misread the OP as meaning he would return to perl 5 (probably a false mental cache hit, since this is usually the context of such comments). Perl 6 does indeed have a few interesting bits.

Re: The Perl 6 project 10 years old today

#52
post #44
post #22

Earlier quoted context omitted.

> Python has engineers and Ruby rockstars This meaningless statement really bugs me. People who write Python and Ruby aren't rockstar engineers. They're just programmers/developers/[whatever you like to call them]. People who speak English are simply English speakers. Nothing more can, nor should, be inferred from that fact.

No, choosing a (Turing-complete) language is really choosing a community, of people who work on the same things you do in a similar way. Community implies shared values. Python's belief in there being only one correct way to do it, for example, is anathema to Ruby and Perl types. Ruby people like being called "rock stars" or "ninjas" (or it wouldn't be widespread in their community, job ads, blogs, etc etc). Just lik…

We absolutely do not all like being called rockstars or ninjas. I do agree that the communities are different but the differences are usually not that important when comparing languages that are very similar, such as Python and Ruby.

Re: The Perl 6 project 10 years old today

#53
post #52
post #44

Earlier quoted context omitted.

No, choosing a (Turing-complete) language is really choosing a community, of people who work on the same things you do in a similar way. Community implies shared values. Python's belief in there being only one correct way to do it, for example, is anathema to Ruby and Perl types. Ruby people like being called "rock stars" or "ninjas" (or it wouldn't be widespread in their community, job ads, blogs, etc etc). Just lik…

We absolutely do not all like being called rockstars or ninjas. I do agree that the communities are different but the differences are usually not that important when comparing languages that are very similar, such as Python and Ruby.

Which is why I said "Turing-complete".

Python and Ruby communities are radically different. Ruby people tend to be in their 20s and primarily employed to do Ruby, mainly for websites. Python people tend to be older and write Python as a part of their main job, they are not employed as programmers (and as such language choice is not mandated).

Re: The Perl 6 project 10 years old today

#54

Earlier quoted context omitted.

Do you know of another language community with a library or extension system which rivals the CPAN, for one example? How about the existence of PCRE for another? Along those lines, have you seen Perl 6 grammars?

The post I responded to said "language" so your comment about CPAN doesn't apply. On the second part, I did misread the OP as meaning he would return to perl 5 (probably a false mental cache hit, since this is usually the context of such comments). Perl 6 does indeed have a few interesting bits.

The post I responded to said "language" so your comment about CPAN doesn't apply.

Somehow Perl 5 made CPAN possible (and by deliberate language design), so that guy in a kilt seems truly a Scotsman to me.

Re: The Perl 6 project 10 years old today

#55

Earlier quoted context omitted.

My point stands, though: the intent of Perl 6 was never to create a language or runtime or compiler which would gradually succumb to a Perl 7 which would gradually succumb to a Perl 8 and so on. Since the RFC process the intent of Perl 6 has to been to create a Perl which solves the limitations and flaws of Perl 5 and can thrive for the next twenty or more years. The intent was to completely set aside iterative devel…

The intent was to completely set aside iterative development... Goodness, no--quite the opposite. The intent was and still is to allow iterative development and in-place upgrades, rather than requiring repeated flag-day breaks of backwards compatibility (the "it's obviously time to increment the major version number").

And that requires implementing every feature addition at once?

Re: The Perl 6 project 10 years old today

#56

Earlier quoted context omitted.

The intent was to completely set aside iterative development... Goodness, no--quite the opposite. The intent was and still is to allow iterative development and in-place upgrades, rather than requiring repeated flag-day breaks of backwards compatibility (the "it's obviously time to increment the major version number").

And that requires implementing every feature addition at once?

If so, I guess we're not going to get Perl 6 after all. After all, all the existing implementations have adopted strategies of getting some features working then getting more. It certainly looked to be working pretty well. I mean, in the last month, I've used grammars, feeds, hyper-ops, lazy lists, and many of the other cool features Rakudo has already implemented. I mean, feeds seriously got added last night. Any project still adding wonderful features like feeds after 30 public releases can't have much hope, if developing Perl 6 requires implementing every feature addition at once.

And the other implementations have it even worse... How am I going to tell sorear that, despite probably averaging over a dozen commits to Niecza[0] each day since the beginning of the month, and the incredible progress he's been making with it, he's doomed because he isn't trying to implementing everything all at one?

Joking aside, no one's trying to implement every feature of Perl 6 at once. The developers of the various Perl 6 implementations are trying to implement feature after feature. Sure, some of them are so productive that the Perl 6 implementation on which their brains run must have implemented auto-threading, but even they aren't trying to implement everything before they make a release. Rakudo's 31st compiler release is this Thursday; and Rakudo [1] is coming out the 29th. Pugs[2] has had quite a few releases. Pawel Murias just released Mildew[3] and STD.pm[4] on CPAN.

Rakudo , for example, isn't going to have all of Perl 6 implemented; but it has quite a bit, and that quite a bit includes some great things, some of which no one else is even trying to do.

[0] http://github.com/sorear/niecza/commits/master [1] http://rakudo.org/node/73 [2] http://hackage.haskell.org/package/Pugs [3] http://search.cpan.org/~pmurias/Mildew-0.03/ [4] http://search.cpan.org/~pmurias/STD-0.02/

Re: The Perl 6 project 10 years old today

#57

Earlier quoted context omitted.

The intent was to completely set aside iterative development... Goodness, no--quite the opposite. The intent was and still is to allow iterative development and in-place upgrades, rather than requiring repeated flag-day breaks of backwards compatibility (the "it's obviously time to increment the major version number").

And that requires implementing every feature addition at once?

Of course not. What gives you the impression that this is the case? There will be a Perl 6.1 with features not present in Perl 6.0 in the same way that Perl 5.12 has features not present in Perl 5.10.

If you meant to ask "Why not release a cut-down version of Perl 6.0 several years ago and iterate on that so you could be up to Perl 6.5 or something by now?" the answer is more complex. First, the most necessary feature of Perl 6 to allow for in place upgrades without falling into the morass of backwards compatibility that slows down the development of Perl 5 was not yet ready. That's a difficult problem and one you don't get many chances to do over.

Second, none of the implementations were mature enough to recommend for general purpose use. (That's as much due to internal strife in Parrot as anything else.)

Re: The Perl 6 project 10 years old today

#58

Earlier quoted context omitted.

The post I responded to said "language" so your comment about CPAN doesn't apply. On the second part, I did misread the OP as meaning he would return to perl 5 (probably a false mental cache hit, since this is usually the context of such comments). Perl 6 does indeed have a few interesting bits.

The post I responded to said "language" so your comment about CPAN doesn't apply. Somehow Perl 5 made CPAN possible (and by deliberate language design), so that guy in a kilt seems truly a Scotsman to me.

Confusing response. If you want to get down to it, CPAN doesn't really provide much more functionality than what you can get in most other languages and provides less than what Java has. CPAN has a tremendous amount of duplication, has a fair amount of toy code, etc., etc.

Re: The Perl 6 project 10 years old today

#59
post #53
post #52

Earlier quoted context omitted.

We absolutely do not all like being called rockstars or ninjas. I do agree that the communities are different but the differences are usually not that important when comparing languages that are very similar, such as Python and Ruby.

Which is why I said "Turing-complete". Python and Ruby communities are radically different. Ruby people tend to be in their 20s and primarily employed to do Ruby , mainly for websites. Python people tend to be older and write Python as a part of their main job, they are not employed as programmers (and as such language choice is not mandated).

More generalizations. sigh
Post reply on HN