| |||||||||||||
Multiple implementations a good thingMultiple implementations a good thingPosted Dec 31, 2007 18:08 UTC (Mon) by proski (subscriber, #104)In reply to: Multiple implementations a good thing by epa Parent article: A Perl 6 status update 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 :)
(Log in to post comments)
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.
|
|||||||||||||