Weekly Edition
Return to the Development page
| |||||||||||
|
| |||||||||||
A Perl 6 status update
Remember Perl 6? Here is a status update by Patrick Michaud on the development of this new language. "Even though the new implementation is only a couple of weeks old, we already see huge gains in the quality and extensibility of the compiler, and in the ability for others to participate in its development. Because the current implementation is so new, I'm reluctant to hazard a guess as to an anticipated pace of development going forward, other than to say it should be much faster than what has been. I do tend to think that we'll be reaching the 'workable implementation' stage in a matter of weeks instead of months or years."
(Log in to post comments)
A Perl 6 status update Posted Dec 30, 2007 6:26 UTC (Sun) by dw (subscriber, #12017) [Link] For those who're sick listening to this (like me), I've scanned the article and filtered it for all the sentance fragments I've seen before. I'm left with: - January 2008, "working, perhaps primitive tarball" So basically still no deliverables. I love the quote. The most extensible code is code that doesn't exist, just like the most bug-free code. This whole thing is like waiting for awk version 2 or something. A few years ago my interest was really finally peaked in learning perl when I saw Conway's perl 6 talk. I've since learned to a sufficient level of competance: C# 1 & 2, C++, and D (hell, 2 new compilers have almost been written in the time since that talk). Forgive me if I fail to feel anything but cynicism for the Perl 6 effort.
A Perl 6 status update Posted Dec 30, 2007 6:33 UTC (Sun) by epa (subscriber, #39769) [Link] Have you tried pugs?
A Perl 6 status update Posted Jan 1, 2008 2:02 UTC (Tue) by xorbe (guest, #3165) [Link] link to pugs?
A Perl 6 status update Posted Dec 30, 2007 16:16 UTC (Sun) by macc (subscriber, #510) [Link] perl 6 is here. It is called tcl8.5 ;-)) G! MACC
A Perl 6 status update Posted Dec 30, 2007 16:45 UTC (Sun) by chromatic (subscriber, #26207) [Link] I suppose we can stop working on it then, if you're so sure that we can't deliver anything in the past month. Maybe I should go learn ballet instead.
A Perl 6 status update Posted Dec 30, 2007 17:08 UTC (Sun) by dskoll (subscriber, #1630) [Link] 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.
A Perl 6 status update Posted Dec 31, 2007 2: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 9: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 4: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 9: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 13:22 UTC (Mon) by chromatic (subscriber, #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 14: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 Dec 31, 2007 17:24 UTC (Mon) by chromatic (subscriber, #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 4: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 3: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 9: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 1, 2008 19:52 UTC (Tue) by rloomans (subscriber, #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 4: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 8: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 isn’t what I expected – it’s 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 can’t-run-here quirks Gosling has tried so hard to avoid!? The Perl identity crisis continues....
A Perl 6 status update Posted Dec 31, 2007 9: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 isn’t what I expected – it’s 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 9: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 6: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 8: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 1, 2008 17:42 UTC (Tue) 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 9: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 11: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 13:27 UTC (Mon) by chromatic (subscriber, #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 Dec 31, 2007 17:56 UTC (Mon) by sbergman27 (subscriber, #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 4: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 5: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 14: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 2, 2008 18:37 UTC (Wed) by AnswerGuy (subscriber, #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 6: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 14: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 10: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 7:16 UTC (Tue) by sbergman27 (subscriber, #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.
Self Hosting Guaranteed Long Development Posted Jan 1, 2008 6:48 UTC (Tue) by roblucid (subscriber, #48964) [Link] As soon as Perl6 was defined as an extensible langauage, that would be flexible enough to be written in itself, yet be compatible enough to run most of perl5, and have a general VM backend a long tortuous development was guaranteed. It's a very ambitious "Research" type project, no surprise that it's not rapidly produced deliverable. There's some memes going round the anti-FOSS world about lack of innovation, generally fuelled by their self-cencsorship and ignorance filters, applied to innovative FOSS examples, which have become ubiquitous eg) WWW. Should perl6 succeed even partially in it's aims, it'll be most innovative; even if other languages are slow to leverage parrot back-ends. Does the market prefer "Worse is Better" though? Perhaps shipping something less ambitious, but more immediately useful and practical matters more than ambitious innovation. In that case Larry Wall, would have had more effect by making perl6 a cleanup of perceived mistakes in perl5, with perl++ being the greenfield project.
Self Hosting Guaranteed Long Development Posted Jan 1, 2008 14:26 UTC (Tue) by chromatic (subscriber, #26207) [Link] Perl 6 is a cleanup of perceived (and keenly felt) mistakes in Perl 5 and most other mainstream programming languages. I'm not sure you understand how deeply those mistakes run. If I may channel Larry perhaps badly for a moment, consider if you had the opportunity to reshape the practical world of programming languages for at least the next 20 years. Would you limit that to minor syntax cleanups, a reorganization of the standard library, and perhaps requiring parentheses around the arguments to
Self Hosting Guaranteed Long Development Posted Jan 1, 2008 15:44 UTC (Tue) by sbergman27 (subscriber, #10767) [Link] """ Perl 6 is a cleanup of perceived (and keenly felt) mistakes in Perl 5 and most other mainstream programming languages. I'm not sure you understand how deeply those mistakes run. """ Perl 6 is a re-purposing of the language. Once upon a time, Perl was a better Unix shell script and was damned good at that. Then the WWW and CGI came along and the choice was between C, shell script, and Perl. C and shell script were simply too hideous to contemplate in that context, and so Perl won out. Based upon its popularity in cgi, people started trying to write real programs in Perl. The rest is history. There is already a Perl 6. It's called Ruby, and is a very nice language. Not my language of choice. But a very nice language, none the less.
Self Hosting Guaranteed Long Development Posted Jan 1, 2008 17:19 UTC (Tue) by jordanb (subscriber, #45668) [Link] By "reshaping the practical world of programming languages," I assume you mean taking your incredibly popular language, that had become the de-facto scripting language for Unix, and announce to everyone working on it that their code is going to be obsolete when the next version comes out, zapping all the energy out of most of the projects using your language, then taking over EIGHT YEARS to produce that next version, ensuring that all the little languages like Python and PHP that used to tremble in your shadow got all the forward momentum. I admit Wall has completely reshaped the practical world of programming languages, he's made one in which Perl isn't relevant in anymore.
Self Hosting Guaranteed Long Development Posted Jan 1, 2008 19:27 UTC (Tue) by dskoll (subscriber, #1630) [Link] If I may channel Larry perhaps badly for a moment, consider if you had the opportunity to reshape the practical world of programming languages for at least the next 20 years. I assume this is the "hubris" part of "laziness, impatience, hubris." It assumes that people will still care about Perl when (if) Perl 6 is finally released. Major earth-shattering rewrites of software are rarely successful. The only one I can think of that was was the Netscape 4 to Mozilla transition and even that was hugely painful. By the time Perl 6 is released, many Perl 5 programmers may have moved on to non-Perl. At my company, we've always found it hard to find good Perl talent, and the Perl 6 development process is not attracting more people to Perl. Once you start rethinking fundamental assumptions, you might find that the problem is a lot larger and more interesting than you initially thought. That's endemic to software engineering. Unless you say "stop" at some point, you never ship a product. And when you're positioning the new product to be the successor to a wildly popular and useful product, it's very dangerous to let your pie-in-the-sky thinking run wild.
Self Hosting Guaranteed Long Development Posted Jan 1, 2008 19:28 UTC (Tue) by roblucid (subscriber, #48964) [Link] "Perl 6 is a cleanup of perceived (and keenly felt) mistakes in Perl 5 and most other mainstream programming languages. I'm not sure you understand how deeply those mistakes run." May be not, but what was clear to me, as soon as I saw the main proposed ideas for perl6, was that it would not be done any time soon... perl was a practical pragmatic choice, it gave access to the C library which was an advantage over diddling with shell, and with perl5 a large and growing collection of CPAN modules. The language perl4/5 was not exactly small, but tended towards having everything but the kitchen sink included... TMTOWTDI became well known for a reason. Somehow seeing the responses here, leans me towards thinking, that the "rethinking fundamental assumptions" ought to be done with a tiny, research toy language, that could then be fleshed out, for production using the learned lessons. Launching perl6 tainted perl5 with FUD, about the future. This mattered as the size of perl5 script systems was an order of magnitude larger than those attempted with perl4. Depressingly, distro's seem to have moved back to shell scripting, for jobs that I *know* from experience on old hardware would run much faster and be quicker to code with the relatively self-contained perl4. Shell has re-asserted itself through ubiquity, and the limitations become accepted through familiarity. Ny comment, was not meant to be critical of the perl porters, nor Larry Wall; I intended to point out how ambitious the project was, therefore it is not suprising that progress is slow. Part of me, wanted not to rule out "hacking miracles" but my head suspected 2nd System Syndrome, OS-370 (read Brooks) style problems, and a very, very long development process.
A Perl 6 status update Posted Jan 1, 2008 21:27 UTC (Tue) by pynm0001 (guest, #18379) [Link] I've come to this thread pretty late but I find it troubling that so many people are whining about Perl6. If you don't like it because it's not like Perl5, use Perl5. If you don't like it because it's not here yet, help get it here. If you don't like it because it's not enough like a different language, use the other language! For years now Perl has attracted a lot of vitriol which I believe is unwarranted, and this story is no different. I maintain a large script in Perl which I'll even admit, if I had to start it over now I would use Ruby (but probably not Python) for. If you're going to complain at least point out something specific which the Perl porters are screwing up, and point out what you think they should do (even if it's "I don't know how to do it better, but this sucks"). In my case if Perl6 did nothing more than make using classes and objects less painful (i.e. more like Ruby or Python) and make hashes and lists less stupid (scalar references for lists in lists? :P) then it's a net bonus, whenever it arrives. Until then Ruby is perfectly fine (although it requires much more thinking to do The Right Thing than I'm used to).
A Perl 6 status update Posted Jan 2, 2008 8:53 UTC (Wed) by dskoll (subscriber, #1630) [Link] I've come to this thread pretty late but I find it troubling that so many people are whining about Perl6. I run a company that uses Perl as its primary development language. It has always been difficult to find talented Perl programmers. Perl 6 is making it *much* more difficult because the whole development process has made Perl look like a crazy experiment rather than a practical language for building software. It's easy to say "if you don't like Perl 6, use Perl 5" but you're discounting the real harm done to Perl and the Perl community by the "new-age experimental" Perl 6.
A Perl 6 status update Posted Jan 2, 2008 11:46 UTC (Wed) by rsidd (subscriber, #2582) [Link] The unfortunate thing about Perl is that it was there first and acquired a huge base. Like Cobol. Both, at least to my eyes, are write-only languages (and I don't think it depends on the programmer's style). As a previous poster said, Ruby is a good Perl6. Still, the complaints seem excessive. If Perl5 will continue to be maintained, or Perl6 can continue to load Perl5 modules, great for those who need to maintain perl code. We still have Fortran77 compilers, so I expect Perl5 will live a long time yet.
A Perl 6 status update Posted Jan 2, 2008 12:10 UTC (Wed) by pynm0001 (guest, #18379) [Link] > Both [Perl and Cobol], at least to my eyes, are write-only languages > (and I don't think it depends on the programmer's style). Well programmer's style can fix most of what's hard to read about Perl. From my experience the problems that are left are: * Regexs. But pretty much every language tries to be Perl compatible in this regard so we're stuck with it. And anything much more verbose would stink IMO (and Perl provide commented regexps as well) * Indirection syntax/sigils: I'm not opposed to sigils (as that's what allows Ruby to avoid the self.crap everywhere that Python is plagued with) but Perl makes it confusing and even worse, the lists and hashes require references in order to work recursively which is incredibly annoying when you're doing hashes of lists, etc. This is something which I hope they fix for Perl 6. * Exception handling by checking $@: die/eval/$@ is a pretty crappy means of exception handling by it's at least consistently crappy. :-/ Some other things (like the new defined-or operator //= for example) are things which I avoid using out of respect for other programmers in my project who have to maintain the script when I'm away but I'd expect people programming Perl to get acquainted with. There's lots of other things (like a good 80% of the global $ variables) that although are valid Perl should probably be shot.
A Perl 6 status update Posted Jan 3, 2008 13:36 UTC (Thu) by chromatic (subscriber, #26207) [Link] As a previous poster said, Ruby is a good Perl6. Anyone who says that in seriousness knows very little about either Ruby or Perl 6. Ruby has some nice features, but it has some serious shortcomings (as does Perl 5). Perl 6 corrects those.
A Perl 6 status update Posted Jan 5, 2008 2:18 UTC (Sat) by njs (subscriber, #40338) [Link] As phrased, you seem to be asserting that (a) Perl5 has shortcomings, (b) Ruby has shortcomings, (c) Perl6 has no shortcomings. I hope that isn't what you mean, but you see how it makes people suspicious of Perl6 when its proponents seem to be advertising it that way...
A Perl 6 status update Posted Jan 5, 2008 8:03 UTC (Sat) by hummassa (subscriber, #307) [Link] > As phrased, you seem to be asserting that (a) Perl5 has shortcomings, > (b) Ruby has shortcomings, (c) Perl6 has no shortcomings. I hope that > isn't what you mean, but you see how it makes people suspicious of > Perl6 when its proponents seem to be advertising it that way... I think what he meant was "(c) Perl6 has /other/ shortcomings, but not the same ones"
A Perl 6 status update Posted Jan 6, 2008 22:17 UTC (Sun) by chromatic (subscriber, #26207) [Link] Perl 6 may have shortcomings. We won't know what they are until people start using it as much as they use Perl 5. We hope we've designed out most of them. We've certainly tried to design away the keenest problems of Perl 5, Ruby, C++, and Java.
A Perl 6 status update Posted Jan 2, 2008 11:57 UTC (Wed) by pynm0001 (guest, #18379) [Link] All I'm saying is that much of the "damage to the community" is your standard "Me Too!-ism". It has become quite fashionable to beat up on Perl and sadly those kinds of things are self-perpetuating. It always takes awhile for people to ease up (I suspect the initial distate for Perl came because of how much nicer Python and then Ruby seemed to be and because Perl was King of the Hill). The Perl5 community is dated, there is simply no way around it. It's not something the Perl guys can fix easily (especially as long as people continue to believe Perl is strictly write-only). I guess they're attempting to fix it by Perl6 so I guess it would be better if it were out sooner rather than later but things don't always work that way. And anyways, were companies really under the impression that Perls 1-5 were *not* some kind of wacky New Age experiment? Perl's idea of OOP is blessing objects for crying out load. Typeglobs! There's modules out there to program Perl in Latin! The language has never had a spec, just the interpreter and later the test suite. So in that regard Perl6 is nothing markedly inferior.
A Perl 6 status update Posted Jan 2, 2008 16:47 UTC (Wed) by sbergman27 (subscriber, #10767) [Link] """ I suspect the initial distate for Perl came because of how much nicer Python and then Ruby seemed to be and because Perl was King of the Hill. """ For what purpose? One off scripts? 1990's cgi routines? Or real programs? For real programs, you can replace "seemed to be" with with "are". """ The Perl5 community is dated, there is simply no way around it. It's not something the Perl guys can fix easily (especially as long as people continue to believe Perl is strictly write-only). I guess they're attempting to fix it by Perl6 """ Which makes Perl 6 a new language, with a new purpose, which needs to prove itself just like any other new language on the block. The first thing it needs is a working and practical implementation. And then we can get down to concepts like usefulness and utility. Sometimes I get the impression that some people think that the names "Perl" and "Wall" should just get them in the door automatically. To me, those names symbolize quirkiness, inconsistency, unreadability, and 1997. So Perl 6 has a lot to prove to me.
A Perl 6 status update Posted Jan 2, 2008 22:39 UTC (Wed) by pynm0001 (guest, #18379) [Link] >> I suspect the initial distate for Perl came because of how much nicer >> Python and then Ruby seemed to be and because Perl was King of the >> Hill. > For what purpose? One off scripts? 1990's cgi routines? Or real > programs? For real programs, you can replace "seemed to be" with > with "are". Well IMHO real programs should be written in C++/C# (or Java if you're feeling masochistic) or Python/Ruby with enough assertions and test suites to catch the silly mistakes which a compiler would typically catch. Python and Ruby are great for very simply applications but maybe it's just me but both give me trouble hunting down the bugs. > Which makes Perl 6 a new language, with a new purpose, which needs to > prove itself just like any other new language on the block. The first > thing it needs is a working and practical implementation. It has that. It's called Pugs. (http://www.pugscode.org/) To be honest I'm not sure why they haven't released it or the Parrot backend-based Perl6 as at least a technical preview yet so people can at least play around with it. I'm also not sure as to what steps are left before Perl 6 can be released. Are they waiting for features to be implemented, is it too buggy, is Parrot not ready, etc. etc.? None of that however warrants the kind of reaction it has been getting. I don't know who's been claiming that Perl6 is the next coming of the Messiah but all I'm saying is the arguments against it are more typically FUD than anything substantive, and I haven't yet seen a response to that which shows otherwise.
A Perl 6 status update Posted Jan 2, 2008 22:56 UTC (Wed) by rsidd (subscriber, #2582) [Link] Python and Ruby are great for very simply applications but maybe it's just me but both give me trouble hunting down the bugs. Probably just you. I don't know much about Ruby, but Python, unlike C and C++, has "tracebacks" when it encounters a problem, and throws exceptions that you can catch, rather than just segfaulting on you. Plus of course you can do high-level programming that eliminates a huge category of bugs (bounds-checking, memory management, side-effects, etc). And it's easy to read, so you catch logical bugs by inspection. Programming in python takes me a tenth the time it would take in C, and it is always my choice when speed is not absolutely critical. (And when speed is important but not totally critical, I have used ocaml and am seriously looking at haskell now.)
A Perl 6 status update Posted Jan 3, 2008 0:01 UTC (Thu) by pynm0001 (guest, #18379) [Link] > I don't know much about Ruby, but Python, unlike C and C++, > has "tracebacks" when it encounters a problem, and throws exceptions > that you can catch, rather than just segfaulting on you. Ruby does. So do C/C++, although they are called "backtraces" there. I've never used nonstandard C Structured Exception Handling (or the more standard setjmp()/longjmp()) but C++ exceptions have not given me trouble. Old versions of g++ had problems throwing exceptions across .so boundaries however. > Plus of course you can do high-level programming that eliminates a huge > category of bugs (bounds-checking, memory management, side-effects, > etc). Yup. Ruby/Python add some categories of their own of course. This is probably due to my C++ background but the fact that everything is like a reference in Ruby (ie. a = b translated to Obj *a = b instead of being a copy constructor) has tripped me up to no end. Freezing Ruby objects is handy for tracking down that kind of bug however. I simply will never get used to having to use self.foo in Python however, no matter how hard I try. That alone has caused me so much grief. I will point out that you will still get resource leaks using Ruby and Python if you're not careful. They will simply not be memory leaks. This is one area where C++ shines (C# managed to steal a good chunk as well). I'm referring to the Resource Acquistion Is Initialization idiom (http://en.wikipedia.org/wiki/RAII). Even among C++ programmers it's not used often enough due to the need to define a class for more resources you use first but if you use it consistently you can practically eliminate resource leaks entirely. It's also useful with stuff like mutexes/thread-locks, etc. > And it's easy to read, so you catch logical bugs by inspection. And the C++ compiler catches them with 10-page template errors messages. ah well. :) Seriously though, this hasn't typically tripped me up, and the next revision to C++ should help with auto variables that infer their type automatically. i.e.: for(std::list<Foo>::const_iterator i = list.begin(); i != list.end(); ++i) {...} becomes foo(auto i = list.begin(); i != list.end(); ++i) { ... } i still has a static type and it's still checked, but you don't have to type it all out. > Programming in python takes me a tenth the time it would take in C, and > it is always my choice when speed is not absolutely critical. Who programs in C anymore? You'll notice I never mentioned it. People like to ding on C++ as just C with objects but that's simply not true. I especially like how Java 1.5 has finally almost caught up to the syntax mess of C++. Python is a great language though, although I only use it over Ruby when... speed is an issue but not so much to where I turn to C++. I still do one-off scripts in Perl just out of habit. But anytime I've tried to make a large program in Python I've typically been able to get the prototype working in Python first but the extra debugging time makes the coding time difference not as drastic. > (And when speed is important but not totally critical, I have used > ocaml and am seriously looking at haskell now.) I've looked at them both (and Erlang, and Common Lisp, and Scheme/guile, and etc.) but functional languages to be honest still completely kick my ass. I understand and like things like lambda functions and closures, and I think I mostly understand the concept, but it doesn't translate to a program design so I just sit there at the editor feeling dumb. :)
A Perl 6 status update Posted Jan 3, 2008 13:24 UTC (Thu) by sbergman27 (subscriber, #10767) [Link] """ None of that however warrants the kind of reaction it has been getting. I don't know who's been claiming that Perl6 is the next coming of the Messiah but all I'm saying is the arguments against it are more typically FUD than anything substantive, and I haven't yet seen a response to that which shows otherwise. """ That categorization of people's reactions as FUD is a bit unfair, and sounds awfully defensive. The "reaction" that I have seen have been mostly observations that it has been 8 years since the announcement and there are still no real deliverables. People are pointing out pugs, and I suppose that's fair. But still, it does not appear that Perl 6 is anywhere near release status. That's not FUD. It's pointing out reality. The fact that it might be construed to reflect badly upon Perl as a language does not make it FUD. If there is real and justifiable "Uncertainty" and "Doubt" regarding a project, based upon fact, making some people "Fearful" of committing their own long-term projects to it... is that really FUD? I call it good sense.
|
|||||||||||