Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • But they will be based on WxWindows, and will most likely include things like a POD Viewer, a GUI CPAN Client, and potentially an editor such as Kephra, as well as other tools as needed or available.

    Um...why ? or rather, why not the GUI toolkit that is/has supplanted all others, namely, the web browser ? Its 2008. As of about mid-2006, its become increasingly clear that, "if it doesn't run in a browser, it don't mean sh*t."

    At the risk of sounding like a buzzword bingo caller, it would be a shame to

    • The big win for browsers has always been automated deployment.

      If you want to run everything locally, there's still advantages to doing things in a GUI. Introducing a client server model and the overheads of doing things in Javascript for a process that is inherently local has it's own downsides.

      That said, it may well be that some of the client side apps ARE done in HTML/Javascript.

      The POD viewer is one example of an application that would be ideal to do browser-based. It's document focus aligns well with th
      • I don't understand implementing a "programmer's editor". There are plenty of IDEs for Perl [perl.org] already, aren't there?

        It's a good idea to make things work better on Windows, though. Languages like Python or Ruby seem to have already dealt with this better than Perl has.

        But what kind of motivation would a Windows programmer have to use Chocolate Perl instead of, say, Visual Studio [microsoft.com]?