| |||||||||||||
A Perl 6 status updateA Perl 6 status updatePosted Dec 31, 2007 0:08 UTC (Mon) by dskoll (subscriber, #1630)In reply to: A Perl 6 status update by chromatic Parent article: A Perl 6 status update
Maybe ballet would be more useful. The various perl 6 projects (pugs, parrot, etc.) seem like a meandering Larry Wall joke. Perl 6 scares me. We have a large investment in Perl 5 code, and I don't see any compelling reason to move away from Perl 5. The antics of perl6 development (I heard Larry Wall talking about the exciting Perl 6 future 7 years ago) fail to inspire confidence. Oh, and I agree with another poster: Tcl/Tk 8.5 are great! :-) Too bad there's no Tcl equivalent of CPAN. IMO, CPAN is the killer feature of Perl and the only real reason to use it.
(Log in to post comments)
A Perl 6 status update Posted Dec 31, 2007 9:26 UTC (Mon) by macc (subscriber, #510) [Link] With tcl/tk 8.5 / 8.4.14++ comes the new Teapot (Tcl Extension Archive) that supports retrieving extensions as part of the programm. see http://wiki.tcl.tk/7579 The "single file" build and distribution helpers like tclkit, starkit and relatives have become popular too. They leverage the tcl VFS capabilities. the linux tclfuse package can even make the internal VFS visible to the underlying OS. Anyway, You may find the Tclers Wiki http://wiki.tcl.tk very helpfull. Be it Info on packages small snippets of code or involved discussion on programming philosophy. G! MACC
CPAN, Tcl/Tk Posted Dec 31, 2007 16:04 UTC (Mon) by dskoll (subscriber, #1630) [Link] Yes, I know all about Tcl/Tk's extensions. The problem is that the sheer wealth of resources on CPAN makes Perl very attractive. There are far more CPAN modules than Tcl/Tk extensions. Granted, you have to pick and choose carefully because CPAN's quality is uneven, but you can usually find a module (or three or more...) that does what you need.
A Perl 6 status update Posted Dec 31, 2007 11:01 UTC (Mon) by yuri (guest, #49755) [Link] Nobody's forcing you to use Perl 6 if you don't like it. For that matter, Perl 6 and Perl 5 are separate languages, anyway, and Perl 5 will continue to be improved as well; if you don't even know that, you probably shouldn't talk about either Perl 5 or Perl 6 at all, since the only thing you're accomplishing is making yourself look like a fool. Stupid troll.
A Perl 6 status update Posted Dec 31, 2007 16:07 UTC (Mon) by dskoll (subscriber, #1630) [Link] Nobody's forcing you to use Perl 6 if you don't like it. I agree. The problem is that Perl 6 takes developer brainpower away from Perl 5. Splitting up the development effort like that is not a good idea. If Perl 6 is so completely different from Perl 5, then it should be called something else so end-users and developers are clearly aware that it's a totally separate project. I'm not even going to bother to respond to the rest of your childish post.
A Perl 6 status update Posted Dec 31, 2007 20:22 UTC (Mon) by chromatic (guest, #26207) [Link] The problem is that Perl 6 takes developer brainpower away from Perl 5. Is that a feeling or a fact? If you're going to present it as a fact, I'd like to see some evidence for that, perhaps backed up by statistics and interviews with a wide range of Perl 5 and Perl 6 developers. We can start with the fact that both Larry and I have hacked on both Perl 5 and Perl 6 in the past couple of years, often simultaneously. It's also a fact that Perl 5 has had several new developers offer patches in the past few years, and so have Perl 6 and Perl 6-related projects. Would we have devoted the same amount of energy to either project if the other did not exist? Unprovable. Another good fact is that several features of Perl 6 have made their way into Perl 5, mostly not written by Perl 6 developers. I don't know what this proves either, but I'm not sure it supports your factpinion. If Perl 6 is so completely different from Perl 5, then it should be called something else so end-users and developers are clearly aware that it's a totally separate project. The creator of the project gets to name it, and he's happy with the difference being the version number.
A Perl 6 status update Posted Dec 31, 2007 21:55 UTC (Mon) by dskoll (subscriber, #1630) [Link] The creator of the project gets to name it, and he's happy with the difference being the version number. Well, good for the creator, but bad for the rest of us. Having to completely-different languages given the same name is going to cause harm. For example: We ship a large commercial project written mostly in Perl 5. When (if?) Perl 6 is ever released, we have two unpalatable choices:
If Perl 6 were called something else (I dunno, maybe Parrotugs or something) there'd be no problem. Our software requires Perl. If you also want to use Parrotugs for something else, great! I'm also the maintainer of a couple of CPAN modules (MIME::Tools being the most prominent) and if Perl 6 were called something else, I wouldn't have to port MIME::Tools (which is after all a Perl module.) As it is now, if I want to maintain the module, I'm going to owe it to the audience to port it to Perl 6. This is work I don't really need, thanks! All in all, Perl 6 really looks to me like a failed IT project. Lots of vapour, people running in lots of different directions, and very little actual working code. It frankly scares me.
A Perl 6 status update Posted Jan 1, 2008 0:24 UTC (Tue) by chromatic (guest, #26207) [Link] I'm having trouble figuring out how you've never ever had dependency "trouble" with any other dependency. If you really need to control the entire stack your customers use, have you considered shipping the entire stack yourself? (That presumes that Perl 5 code won't run on Parrot in process with Perl 6 code, and the plan is to make that possible. That's why we're writing Parrot.) Are you going to remove
A Perl 6 status update Posted Jan 1, 2008 11:29 UTC (Tue) by dskoll (subscriber, #1630) [Link] I'm having trouble figuring out how you've never ever had dependency "trouble" with any other dependency. We depend only on core Perl modules. We ship a sizeable number of CPAN modules to make sure our dependencies are met, but it's by no means the entire Perl environment. Are you going to remove Well, since I'm not sure what you mean by renaming MIME::Parser.
A Perl 6 status update Posted Jan 1, 2008 10:51 UTC (Tue) by epa (subscriber, #39769) [Link] The same argument applies for the transition from Perl 4 to Perl 5. Most intelligent people understand the idea of version numbers.
A Perl 6 status update Posted Jan 1, 2008 16:01 UTC (Tue) by dskoll (subscriber, #1630) [Link] The same argument applies for the transition from Perl 4 to Perl 5. Well, there are a few differences:
A Perl 6 status update Posted Jan 2, 2008 2:52 UTC (Wed) by rloomans (guest, #759) [Link] Having to completely-different languages given the same name is going to cause harm.I doubt it. If you read: http://dev.perl.org/perl6/doc/design/syn/S01.html You will see that not only is backward compatibility very important, interoperability between Perl 5 and 6 code - even in the same file - is very high on the list. I'm also the maintainer of a couple of CPAN modules (MIME::Tools being the most prominent) and if Perl 6 were called something else, I wouldn't have to port MIME::Tools (which is after all a Perl module.) As I understand it, Perl 5 modules will be perfectly usable from Perl 6 code. The only incentive for using Perl 6 syntax will be if you need it's features. If you don't, don't re-write. Simple. As it is now, if I want to maintain the module, I'm going to owe it to the audience to port it to Perl 6. This is work I don't really need, thanks! I think that you are exaggerating.... Once Perl 6 is deployed you may have reason to complain if there are compatibility issues. As I understand it, your concerns are ones that are very high on the list of the Perl developers' priorites. Please damp the flames a bit.
A Perl 6 status update Posted Dec 31, 2007 11:15 UTC (Mon) by epa (subscriber, #39769) [Link] You could equally well talk about 'the antics of perl5 development', given that there were no major releases for five years before 5.10 came out this month.
A Perl 6 status update Posted Dec 31, 2007 15:13 UTC (Mon) by mattmelton (subscriber, #34842) [Link] I've been installing new releases quite often. I'm perl5 has become quite xml-ized over the past 5 years, which has repeatedly required me to upgrade (more so out of simplicity and sometimes when the cpan shell or depends break) I'm beginning to get this. Perl5 is a language that will continue to subsist long after Perl6 comes along. Perl6 is a new language. It is not perl5, or a replacement for perl5. Again, so Perl 6 is a new language. I'm having a hard time detaching myself from wanting a perl5 successor. I guess the regex changes are part way to pushing me over the wall. But then, the changes outlined in Perl6::Perl5::Differences bring me back to my much loved Perl-reality. Perl6 isn't that much different. The language changes (the things we truely care about as developers) are subtle, and imo, desirable. We want Perl6 to be Perl5's successor. But it's not. It could be. But it's not. It looks like it should. But it's not. We'll see whether the wait was worth it if other languages utilise Parrot successfully. I liked the original idea behind Parrot - a unified JIT system (? forgive me - i see Parrot as the java-for-all VM well all wanted) - but unfortunately we have fragmentation with Pugs (implemented in Haskell... serious WTF territory there) miniperl etc... With perl.tar.gz, ActiveState Perl and now Strawberry Perl, we've always been assured we'd get Larry's Perl. The same Perl code... the same tree. Now it's all a little confusing. Multiple implementations of the same language passing the a shared test suite isnt what I expected its hard enough coding for one; just look at the C# compiler bugs and runtime cockups! Is Perl6 in-your-face-anti-Java? The many implementation language with cant-run-here quirks Gosling has tried so hard to avoid!? The Perl identity crisis continues....
A Perl 6 status update Posted Dec 31, 2007 16:05 UTC (Mon) by rsidd (subscriber, #2582) [Link] Pugs (implemented in Haskell... serious WTF territory there) Pugs revitalised Perl6 almost overnight; without it there would likely be nothing. And arguably Haskell was a big part of that success. Multiple implementations of the same language passing the a shared test suite isnt what I expected its hard enough coding for one; just look at the C# compiler bugs and runtime cockups! Precisely why one needs multiple implementations.
A Perl 6 status update Posted Dec 31, 2007 16:09 UTC (Mon) by dskoll (subscriber, #1630) [Link] Pugs revitalised Perl6 almost overnight; without it there would likely be nothing. If that doesn't scare people off, I don't know what would.
A Perl 6 status update Posted Jan 1, 2008 13:41 UTC (Tue) by smitty_one_each (subscriber, #28989) [Link] Scare? A talented individual scratching a creative itch is hardly cause to be scared. Unless you're a PHB, and terrified about bouts of creativity you can't reproduce at the wave of a wand. Celebrate the creativity, and ponder how to make it infectious, yet manageable.
A Perl 6 status update Posted Jan 1, 2008 15:51 UTC (Tue) by dskoll (subscriber, #1630) [Link] Scare? A talented individual scratching a creative itch is hardly cause to be scared. No, the scary part was without it there would likely be nothing.
A Perl 6 status update Posted Jan 2, 2008 0:42 UTC (Wed) by smitty_one_each (subscriber, #28989) [Link] History doesn't support experiments. You can't go back in time and erase someone and verify your assertion. What happened happened. Accept.
Multiple implementations a good thing Posted Dec 31, 2007 16:55 UTC (Mon) by epa (subscriber, #39769) [Link] Multiple implementations has helped Python; nobody considers it a problem to have both CPython and Jython (and others). It helps iron out fuzzy areas in the language spec. Perl particularly needs this...
Multiple implementations a good thing Posted Dec 31, 2007 18:08 UTC (Mon) by proski (subscriber, #104) [Link] However, Python delivers its C implementation on a regular basis, giving non-Python developers (i.e those who develop in Python, rather than those who develop Python) a solid foundation for their programs and allowing them to supply feedback based on their real worlds needs. On the other hand, the existing Perl 6 code is mostly the test suite written by the developers of Perl 6.In the latest trailer, Perl 6 has been seen sitting next to barbells and smoking something. That inspires great confidence that it will be released really soon now :)
Multiple implementations a good thing Posted Dec 31, 2007 20:27 UTC (Mon) by chromatic (guest, #26207) [Link] In the latest trailer... All of our source code has been publicly available for years. Ditto our design documents. Ditto the minutes of our design meetings (at least for the past couple of years; they weren't always but they are now). The monthly Parrot releases always contain a newer version of Perl 6 on Parrot. As I implied in the previous paragraph, you can always check out the most current version there or just browse it through anything that speaks HTTP. We don't pop up every couple of years with a silly demo that you can't peek inside. We're not hiding anything. If you wanted to, you could track our progress to the second. I don't understand the comparison to a piece of proprietary software you can't look inside even after its release.
Multiple implementations a good thing Posted Jan 1, 2008 0:56 UTC (Tue) by sbergman27 (guest, #10767) [Link] """ All of our source code has been publicly available for years. Ditto our design documents. Ditto the minutes of our design meetings (at least for the past couple of years; they weren't always but they are now). --- I don't understand the comparison to a piece of proprietary software you can't look inside even after its release. """ I think that the point is that the sound of an OSS project spinning its wheels is remarkably similar to the sound of a closed source project spinning its wheels. But with the OSS project, you get the play by play, day by day, year after year, making it all the more excruciating to those who still care, for whatever reason. Perl6 has all the markings of a project that has become too unwieldly to effectively manage. A better comparison than Duke Nukem Forever might be Microsoft's Longhorn. And they did eventually get something out the door.
Multiple implementations a good thing Posted Jan 1, 2008 11:40 UTC (Tue) by tuna (guest, #44480) [Link] "But with the OSS project, you get the play by play, day by day, year after year, making it all the more excruciating to those who still care, for whatever reason." What is the problem with this. You have the same opportunity as anyone else to contribute to the project. If you want a better (for you) Perl 6 release, you should contribute something. Otherwise it will probably not happen.
Multiple implementations a good thing Posted Jan 1, 2008 12:31 UTC (Tue) by k8to (subscriber, #15413) [Link] Sometimes pointing out the emperor's nakedness is a worthwhile contribution. Of course, sometimes it's not.
Multiple implementations a good thing Posted Jan 1, 2008 21:20 UTC (Tue) by tuna (guest, #44480) [Link] This is something allegoric that goes compleately over my head. Could you please explain it to me? I assume you are reffering this fable: http://en.wikipedia.org/wiki/The_Emperor%27s_New_Clothes
Allegory Posted Jan 3, 2008 1:37 UTC (Thu) by AnswerGuy (guest, #1256) [Link] Tuna, You are correct, he was undoubtedly making such a reference. Typically the moral of that story is that sometimes, even though it may seem foolish, perhaps even dangerous or suicidal, to point out that something is wrong, it's nonetheless the right thing to do. Unfortunately we see this far too often in business, and particularly in IT --- charlatans come in and tell us they have magic cloth from which they have woven fine raiments in which we can dress up our organization and prance about before our adoring users and customers. Far too often our own management won't listen to the "children" among us (those who are near the bottom of the org. charts). Consequently we see horrible boondoggles perpetrated upon our employers. (I'd give a particular example of my own devising -- but I don't feel like getting sued by some megacorp that's commonly known by a pair of initials). JimD
Multiple implementations a good thing Posted Jan 1, 2008 13:23 UTC (Tue) by tialaramex (subscriber, #21167) [Link] Suppose, hypothetically, that there's a very important piece of work that you know needs to be done on a project. It needs buttons. But, the project's leaders and main contributors are sure their new plan makes that work unnecessary. They have a six month plan to build a framework for general fastening, including a heuristic zip-and-velcro system that should render buttons obsolete. So they tell you not to even bother writing a patch, because hey in six months they'll just have to rip it out again. Several years later the six month plan has been "delayed" because it turns out that solving the general problem of fastening isn't as trivial as it seemed when they were drunk at a conference. But there's now a timeline, a schedule, two new source code repositories and a paid bounty system. But there still aren't any buttons, and buttons were all the users actually asked for in the first place. Now, what exactly do you win by standing up and saying "I told you so" when that's already what everyone except a few deluded developers is thinking? Do you fork, causing a year long flamewar in which many people will decide that it's better to abandon the entire project than to put up with so much childish spite ? Sometimes projects, whether Free Software projects, or just the project of redecorating the bathroom, get mired down somehow and should rightly be abandoned. You can always move home instead.
Multiple implementations a good thing Posted Jan 1, 2008 21:10 UTC (Tue) by tuna (guest, #44480) [Link] So write the patch and have the main authors yank it out later. Or write a "libbutton" for whatever you need. Your argument would be much better if you could point to a real example where this has happened. And as always, you can ask other people to do stuff as much as you want, but if no one wants to actually do the work, the stuff won't get done.
Here's your example Posted Jan 2, 2008 17:43 UTC (Wed) by tialaramex (subscriber, #21167) [Link] Not that I'm bitter or anything, but take a look at how the GIMP is still waiting, years later in 2008, for "GEGL integration" that's supposed to finally deliver the features slated for GIMP 2.0 all those years ago. What the users wanted, more than anything*, was high dynamic range. It wouldn't have been trivial to do it, maybe several of the old hands would have to spend a few weeks hacking on dirty low-level code in the GIMP core, in addition to all the work from lesser mortals like myself - but it was definitely possible, and it could have been delivered in GIMP 2.0 if the will had existed. But not only did the will not exist, there was a specific argument that this work was not merely unnecessary but actively counter-productive. All that effort was supposed instead to be directed to GEGL. Which rotted slowly in a corner for years because no-one really had the combination of time and enthusiasm to work on something so completely abstract and unconnected with reality. * OK, the thing users actually wanted more than anything was a tool that drew straight lines, but that's because users don't read, don't want to read, and particularly don't want to read manuals. Once they'd read the manual or been told politely what it says about drawing a straight line they generally settled on wanting high dynamic range.
Multiple implementations a good thing Posted Jan 1, 2008 14:16 UTC (Tue) by sbergman27 (guest, #10767) [Link] """ If you want a better (for you) Perl 6 release, you should contribute something. Otherwise it will probably not happen. """ I was speaking as a third party observer. I eschewed Perl for the beauty, readability, maintainability, and predictability of... the language which I prefer.
|
|||||||||||||