Back to the __future_

Replies are listed 'Best First'.
Re: Back to the __future__ by moritz (Cardinal) on Aug 18, 2011 at 21:09 UTC
But deep down I expected the significant future to be Perl 6. And I still do. I might be on a lonely position here, but I do think of Perl 6 not only as a successor for Perl 5, but also as a successor for Ruby, TCL, Lisp and a number of other dynamic languages. We need to start giving Perl version numbers against CPAN modules FWIW all of my CPAN modules already declare a dependency on a minimal Perl version, by having `perl: 5.006001` in my META.yaml, and `require 5.006001;` [download] in Build.PL. So maybe you should be more specific: maybe it's time to track lower and higher version constraints, and make parts of the infrastructure() aware of it. () intentionally left vague here, because I'm not yet sure exactly which parts need to be changed. Let me tell you a short story. Nearly exactly two years ago I uploaded the first Perl 6 module to pause.cpan.org. I had carefully declared a minimal Perl version of 6.0.0. I joined #toolchain on irc.perl.org in order to talk about any problems that might occur. As one might expect, the attempt didn't work out too well. The indexer didn't know what to make of the Perl 6 Pod dialect, so no docs showed up on search.cpan.org. But still the tarball got distributed to the CPAN mirrors, and was available for download. This disheartening part was that the overwhelming majority of #toolchain wasn't interested in making anything Perl 6 related work, but demanded that I didn't break anything Perl 5 related. I didn't plan to, and as far as I can tell, I did not. All my plans (which I tried to discuss there) had carefully been designed not to break anythiing for the Perl 5 folks. All I had was one distribution on CPAN that wasn't indexed correctly, and that no perl 5 tester could run, because their perl version was too low. Still, when I rejoined #toolchain about 15 months later, a pretty vocal and influential member of infrastructure hackers remembered me as "the guy who broke CPAN" As a result, Perl 6 has started to develop it's own, albeit pretty primitive, module infrastructure in the mean time. Some people from the Perl 5 community did seem genuinely interested, and reminded me not to repeat the mistakes that were made in connection with Perl 5's packaging system, without being able to actually point to concrete mistakes. When I now read that Damian Conway (and maybe others) want Perl 6 modules on CPAN, I wonder if they believe in fairytales, or if they are connected to a different reality than I am, or if I simply met the wrong people when I started my attempt two years ago, or if something substantially has changed in the mean time. I'd very much like to see a reuse of resources when building a module distribution system for Perl 6, and I'd very much like to see that happen soon. If anybody can propose concrete steps to drive that effort, I (and many other Perl 6 hackers) am willing to do my best. I'm just weary of two things: handwaving like "we must fix CPAN", and overdesign that leads to too much effort before a simple installation of a Perl 6 module can actually happen. Perl 6 - second systems done right	[reply] [d/l] [select]
Re^2: Back to the __future__ by sundialsvc4 (Abbot) on Aug 18, 2011 at 23:20 UTC
To me, what is remarkable, important and lasting about Perl is not the language itself, but the CPAN library. Many years’ worth of rugged, battle tested software that works. That is what makes Perl different ... as I discovered first hand while briefly consulting for “A Popular Powerful Legendary Enterprise” that wanted for some reason to replace its Perl Software That Works™, with Something In Ruby. Oops! Although Ruby at first blush appeared to have an equivalent package to do many things, it often didn’t provide the functionality that was needed right-now, and furthermore the packages had a rather disagreeable number of flaws. The upshot (at the present day, of course... the Ruby teams are no slouch and I’m not suggesting any such thing) was that while the Ruby language might (?) have been Better,™ the project was not well served by the Ruby system in its present condition. Of course it could happen to anyone, anywhere, in any language system fill-in-the-blank, but ... the Perl library spoils you quick. It is of course the product of many more years of effort than is Perl Itself.	[reply]
Re^3: Back to the __future__ by sundialsvc4 (Abbot) on Aug 22, 2011 at 12:58 UTC
“The trick,” for the Perl-6 project, is how to make it a different-and-better language while also allowing it to be source-compatible in some way with its important installed-base ... namely, CPAN. There is too much in CPAN to allow all of that stuff to be “rewritten.” So, there is a formidable engineering challenge here. Existing projects such as (specifically...) Moose do show what can be accomplished, even in the context of Perl-5. So, IMHO, “Perl-6 must be more than a forward step. It must be a broader step.” If it were merely to be thought of as “a new and therefore better language,” well, we’ve had all of those things before. We’ve got them right now. Ruby. Haskell. Your Opinion May Vary.™ All of them, nevertheless, different, and all of them rebuilding from scratch a thing that Perl has spent the last X years already doing. So, the engineering problem, as it turns out, is in the existing code. The existing shared code. The easiest approach of course is to “start with none,” but that is throwing away the baby. The language isn’t the baby; it isn’t a thing that can be “improved upon” in isolation. The commercially valuable thing is CPAN, not to mention millions of vital “legacy code” installations that are literally hauling the freight and paying the bills. Hence, my observation that the approach must be a broader approach: one that encompasses what exists now, and which elaborates upon it without repudiating it. We cannot say, “that was then, this is now.” We need, “that was now, and this is also now.” A vastly more complex software-engineering problem . . .	[reply]
Re^2: Back to the __future__ by Anonymous Monk on Aug 19, 2011 at 03:17 UTC
When I now read that Damian Conway (and maybe others) want Perl 6 modules on CPAN... If you've read that, then I have been either misquoted, misattributed, or misunderstood. I want Perl 6 modules on 6PAN, or C6AN, or CPAN6, or some other suitable parallel to CPAN. At the moment, that repository seems to be named "GitHub", but I still long for a more PAUSE/CPAN-ish front end to it. I certainly don't want Perl 5 and Perl 6 on a single undifferentiated repository. Half of the Perl 6 modules I've written are direct ports of my existing Perl 5 modules, with identical names and similar APIs. There is no way they can coexist with Perl 5 modules...at least, not under CPAN's linear notion of "latest version" (which, BTW, I wholeheartedly approve of as being much more appropriate for the majority of CPAN users). Damian	[reply]
Re^3: Back to the __future__ by moritz (Cardinal) on Aug 19, 2011 at 08:33 UTC
Sorry, I didn't mean to misquote you, since I couldn't attend YAPC::EU, all my knowledge is from second hands. Yes, we need work both on the frontend and backend for a Perl 6 module solution, it will be interesting to see what we can come up with. While we are at the topic, are your Perl 6 modules available somewhere for the general public? Perl 6 - second systems done right	[reply]
Re^4: Back to the __future__ by Anonymous Monk on Aug 19, 2011 at 10:54 UTC
Re^3: Back to the __future__ by JavaFan (Canon) on Aug 21, 2011 at 13:04 UTC
I didn't know what to make of your YAPC::EU keynote. I kept wondering whether I was listening to the 2011 Damian, or a time warped Damian from 2004. I'm with Jesse when it comes to view of Perl 6. It's a nice research project. Now let's do something useful with/to Perl 5. As for the name. I actually think the name "Perl 6" hurts "Perl 5". While for the incrowd it's clear what the differences between perl6 and perl5 are; how they relate to each other; and what Larry's feelings are, the rest of the world doesn't have that knowledge. They see numbers and think Perls numbering scheme is sane, and acts like the rest of the world. And hence, they're not considering perl5 something to invest in -- they'll wait for perl6. But I also realize that any discussion here about it is fruitless. Unless you can convince Larry, it's not going to change (Rule 1). And in Asheville, he made it quite clear he hasn't changed his mind yet (Rule 2 isn't being invoked at the moment).	[reply]
Re^2: Back to the __future__ by cdarke (Prior) on Aug 19, 2011 at 10:10 UTC
I did not intend to undermine the work you and others have done on Perl 6. The fact that there is a future vision for Perl 5 should take some of the pressure off Perl 6. I expected too much from Perl 6 in an unrealistic timeframe - my fault not yours.	[reply]
Re: Back to the __future__ by sundialsvc4 (Abbot) on Aug 18, 2011 at 13:38 UTC
Effectively, it is “a new language,” and what I would suggest is: stop calling it ‘Perl (6).’ The problem with every computer language is its history. The literally millions of installed programs, web sites, and so-forth which consist of code that has been well tested and proved ... and for which, pragmatically, the most important consideration is that they continue to do so, even as bugs are fixed and as evolutionary improvements are made in the host language implementation. “Dance with the one who brung ’ya, ’cuz he’s the one driving you home.” No matter how badly you might want to “improve things,” continuity of service, and risk-management, really does trump everything. If you want to bring in “a new language,” then by all means, do so. Just say that this is what you’re doing. Don’t bring radical change into the scope of a massive, mature, multi-billion dollars’ worth, installed base. There are real technical-risk potentials there, and risk is never welcome at the dinner table. “Beware of Geeks bearing gifts.” Instead, just call it something else. Clearly-separate, albeit perhaps source-compatible or mostly-source-compatible, language systems. Distinct names. (“Lerp?” “Camel.poo?”) Everyone from the CEO to the janitor will avoid the confusion that can, once again, result in risk. Eliminate ambiguity with regard to what you are actually talking about. (Our techno-babble is already bad enough as it is.)	[reply]
Re^2: Back to the __future__ by raybies (Chaplain) on Aug 18, 2011 at 19:31 UTC
I suggest Perl 6 should be called "Perm" because the next letter after "l" is "m", and it makes a perfectly good (if a bit frizzy) word for a language. ...that and just think the followon of Perm could be sPerm.	[reply]
Re^3: Back to the __future__ by snoopy (Curate) on Aug 18, 2011 at 23:59 UTC
`$ perl -e 'my $p = qw{Perl}; print ++$p' Perm` [download]	[reply] [d/l]
Re^2: Back to the __future__ by LanX (Saint) on Aug 26, 2011 at 13:47 UTC
Actually I suggested calling it Perl++ at the YAPC::EU. Damians reaction was "well it's too late for that" and I agreed. Cheers Rolf	[reply]
Re: Back to the __future__ by ForgotPasswordAgain (Priest) on Aug 18, 2011 at 22:24 UTC
Can you link to where they've been saying that for years? I honestly had quite the opposite impression and recall it being basically heretical to suggest that Perl 6 was not Perl. I've sorta been waiting for Perl 6 to go off to wherever languages du jour like Haskell, Clojure, Scala, Erlang, etc. go. Sorry if that seems a bit hostile. Perl 6 certainly has nice ideas. I can't remember which book it was, but in one of the books by Feynman he mentioned how in high school he'd understood mathematics using methods or notation that nobody else used. The problem is it doesn't matter how well you understand something if nobody else understands you; you have to be able to communicate your ideas. On the other hand, he invented Feynman diagrams, so go figure. I'm not sure I even have a point here, but if I do it is that Perl 6 doesn't seem like Feynman diagrams.	[reply]
Re^2: Back to the __future__ by chromatic (Archbishop) on Aug 19, 2011 at 00:42 UTC
... and recall it being basically heretical to suggest that Perl 6 was not Perl. Still is. Certainly when I've contributed to Perl 5 I understand that I've contributed to Perl in the same way that when I've contributed to Perl 6 I understand that I've contributed to Perl. I will understand the mindset of someone who feels the need to tell me that by contributing to either Perl 5 or Perl 6 I haven't contributed to Perl.	[reply]
Re^2: Back to the __future__ by cdarke (Prior) on Sep 09, 2011 at 07:42 UTC
http://www.perl.org/about.html states: "Perl 6" is part of the family, but it is a separate language	[reply]
Re: Back to the __future__ by Anonymous Monk on Aug 18, 2011 at 10:58 UTC
Did Larry really meant Perl 6 to be a new language back then in 2000? I thought Perl 5 and 6 separate more and more in an evolutionary fashion?	[reply]
Re^2: Back to the __future__ by hardburn (Abbot) on Aug 18, 2011 at 19:27 UTC
He clearly meant it to not be backwards compatible. Larry did want Perl5 and 6 to live in harmony on a single runtime, but Ponie has been indefinitely put off. "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply]
Re: Back to the __future__ by Tux (Canon) on Aug 19, 2011 at 06:01 UTC
FYI that talk is now on line. Enjoy, Have FUN! H.Merijn	[reply]
Re^2: Back to the __future__ by LanX (Saint) on Aug 19, 2011 at 21:48 UTC
Does anyone know when the videos are supposed to go online? (well except the ones from the stolen camera...) Cheers Rolf	[reply]
Re: Back to the __future__ by Anonymous Monk on Aug 18, 2011 at 06:39 UTC
We need to start giving Perl version numbers against CPAN modules, and be able to search and select that way. We have an issue with that right now, but if Jesse gets his way then it will become much more important. What does that mean? Patches welcome? Extending META.yml/META.json?	[reply]
Re^2: Back to the __future__ by Corion (Patriarch) on Aug 18, 2011 at 07:06 UTC
Basically the idea is that your module states `use 5.20;` [download] And it will get (lexical) 5.20.x semantics for its code, no matter what version of Perl it runs on. At least to the best of effort that can be made. The intention is to free Perl code up from backwards compatibility issues in the sense that for example the current implementation of the smartmatch operator ~~ does not make much sense, but code that uses it now will likely expect 5.14 semantics. The one thing that Jesse has not yet declared is how to specify "I need Perl 5.xx or higher". For example, I have code that declares it wants Perl 5.06 because it wants lexical filehandles. But that same code will (likely) run on any future version of Perl as well, so I don't want to request 5.06 semantics for everything.	[reply] [d/l]
Re^3: Back to the __future__ by JavaFan (Canon) on Aug 19, 2011 at 10:53 UTC
First of all, the least version for which this will apply is 5.16. And that's assuming it can be build before that. But really, what's is the purpose of saying "I need Perl 5.xx or higher"? The entire point of this exercise is to be able to remove features without breaking. The fact that `use 5.006;` means "I want lexical filehandles" means we have to support lexical filehandles forever, in the same as it's now. Say, in 5.20 we have a really awesome feature. You get it with `use 5.20;`. But a year and a half later, it turns out the feature wasn't so awesome, or it can be made better, but only in a way to break backwards compatibility, Jesse's proposal makes it possible. `use 5.20;` and `use 5.22;` will give you the awesome feature, `use 5.24;` won't, or with a changed syntax and/or semantics. But if people can say "use 5.20 or something newer", it's not going to work. Then we're back to the same backwards compatibility issues we have right now. Note that Jesse's proposal doesn't imply that `use 5.20;` means it's going to croak on 5.22 or 5.24. Not at all. It means that 5.22 or 5.24 is going to emulate the 5.20 behaviour.	[reply] [d/l] [select]
Re^4: Back to the __future__ by Corion (Patriarch) on Aug 19, 2011 at 12:37 UTC
Re^5: Back to the __future__ by JavaFan (Canon) on Aug 21, 2011 at 12:52 UTC
Some notes below your chosen depth have not been shown here
Re^4: Back to the __future__ by cdarke (Prior) on Aug 19, 2011 at 13:07 UTC
Re^5: Back to the __future__ by JavaFan (Canon) on Aug 21, 2011 at 12:39 UTC
Re^3: Back to the __future__ by Tux (Canon) on Aug 18, 2011 at 14:50 UTC
Note that it is by far "done" (yet). There are lots of issues to be discussed before decisions are made. E.g. the above statement conflicts with the idea that `use v5.12.4;` can be used to indicate that one needs version 5.12.4 or up because a vital bug was fixed in that version and the script won't work with anything older. That concept could be solved by using something like `use ge5.12.4` (as in greater or equal to 5.12.4, which I suggested to Jesse). That however will not suffice, as you might need 5.12.4 or newer (because of the bugfix) but do not support beyond 5.16.7 (because of syntax change). How would you define ranges? `use ge5.12.4, lt5.16.8;`? How will perl "support" ranges (if at all)? Should there be more than one declaration? What if - inside a range - something changed dramatically. What should perl choose to do? Syntax vs Semantics? etc etc. Enjoy, Have FUN! H.Merijn	[reply] [d/l] [select]
Re^4: Back to the __future__ by thargas (Deacon) on Aug 19, 2011 at 11:24 UTC
Re^3: Back to the __future__ by davido (Cardinal) on Aug 18, 2011 at 07:21 UTC
Given the Perl6 interpreter has a Perl5 mode of operation, would there be Perl5 lexical semantics available to modules that can interact with Perl6 callers? Or is that 'switch' all or nothing? If the CPAN is Perl5's 'killer application', some interoperability could ease the concerns about beginning new projects in a new language. ...after Christmas comes, of course. ;) Dave	[reply]
Re^3: Back to the __future__ by cdarke (Prior) on Aug 19, 2011 at 09:12 UTC
What's wrong with: `use 5.18; no 5.22;` [download] which would mean "use any release after 5.18, but not 5.22 or higher".	[reply] [d/l]
Re^4: Back to the __future__ by Tux (Canon) on Aug 19, 2011 at 14:58 UTC

Back to the __future__

Back to the future