http://qs321.pair.com?node_id=345589

The article Popular Perl Complaints and Myths on the mod_perl site says, "Perl can't create advanced client side applications." and "Unlike Perl, with Java you can create advanced client side applications." It briefly mentions PerlScript before focusing on the "problem" of not having Perl installed, but doesn't mention needing a VM to run Java as a problem. I found this troubling since my experience creating simple client-side apps suggests that advanced client-side applications with Perl is definitely possible. Why does this myth about Perl persist?

--
perl -MO=Deparse -e"u j t S n a t o e h r , e p l r a h k c r e"

  • Comment on Creating Advanced Client-Side Applications With Perl

Replies are listed 'Best First'.
Re: Creating Advanced Client-Side Applications With Perl
by dragonchild (Archbishop) on Apr 16, 2004 at 02:02 UTC
    This myth persists because of the following:
    1. The Java VM comes installed on most Windows systems.
    2. Java has a unified method of creating GUIs, while Perl doesn't.
    3. Java has a better set of documentation.

    That last complaint is a really really big one for me. For the past week, I've been researching using PerlScript to create client-side apps using IE without a webserver. Let me tell you - there is almost zero documentation for this.

    • 99.999% of all Googled hits have to do with PerlScript and ASP, including matts's pages
    • Almost all my examples were culled from newsgroup postings from 1997.
    • The online Perl in a Nutshell examples have syntax errors. ($window->frames[3] doesn't compile!)
    • ActiveState's example pages are blank.
    • The documentation that comes with ActivePerl stops at "Hello, World".
    • Documentation on ActiveX is cryptic to an OpenSource developer (like all of Microsoft's docs)

    In other words, someone might be able to, if they were willing to bust their ass trying to reverse-engineer it. But, why do that when you can just install Apache?

    ------
    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      Thank you for the info, dragonchild. I've been doing a fair amount of client-side scripting with JScript (Micro$oft's javascript) lately, and have been wondering why I couldn't do it in Perl. I know about PerlScript, but I can't use it here because it isn't installed. I didn't realize there were these other barriers to entry as well. :-(

      Btw -- I think it's clear from the context that "advanced client-side applications" means programming to a plug-in, not to the browser itself. Therefore the comparison between Java and PerlScript is apples and oranges. PerlScript is an alternative to Javascript/JScript/VBScript (etc.). An alternative to Java (on the client) would be something embedded, like Flash, and whatever Tk or Wx thingies people might have come up with.

      jdporter
      The 6th Rule of Perl Club is -- There is no Rule #6.

      1. One of the reasons why you do not find anything about PerlScript used in the browser is ... that people do not do that often enough. You simply can't do this in any other case than if all your users are running Windows and have Perl installed. Maybe some intranets are elligible, I don't really know. I might do something like this soonish in a HTA, but for web client-side stuff JavaScript has to be good enough.
      2. The second reason is IMHO that there is not much to document. Perl is Perl and browser object model is browser object model. Sure Netscape and MS has all their docs in J(ava)Script, but converting that to Perl syntax is not that a big deal. If you want to control a program using OLE/COM you usualy need to convert the description and examples from VB and thats a bigger difference.

      Jenda
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
         -- Rick Osborne

      Edit by castaway: Closed small tag in signature

        I want to create single-user applications to be run on a single PC that you download. The installer would include ActivePerl, should it be necessary. I can't use JavaScript because I want to use DBD::SQLite, plus I don't want to learn a whole new language.

        Put it this way - the simple utility apps I want to create and distribute would take between 2-4 days each ... assuming I can use Perl for DBD::SQLite and HTML::Template. The engines for these utilities are very small and easy ... Heck, I've already written most of the engines for two of the utilities in the general course of my work. I don't want to reimplement them, if at all possible, or spend a month learning Tk. But, I don't want to require using a webserver, even one as small as webmin.

        As for not needing much to document ... Converting from JScript to PScript is almost impossible for non-trivial cases. Take the following rather simplistic example in JavaScript:

        Here's the direct translation (as I understand it) to PerlScript.

        The JavaScript version works as expected, but the PerlScript one doesn't even run the onLoad handler. What's the difference? What am I missing?

        I'm on WinXP Pro, IE 6.0.2x, the latest build of ActivePerl (downloaded within the past week).

        Update: Changed to match Erto's statement. It still doesn't work.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Re: Creating Advanced Client-Side Applications With Perl
by Jouke (Curate) on Apr 16, 2004 at 07:41 UTC
    The statement may be true for Client-side applications that are supposed to run inside a webbrowser. Hasn't anyone heard that Perl has Tk, wxPerl, Win32::GUI or Gtk?

    Is it badly documented? I think not. Tk is very well documented, there are even O'Reilly books about it. wxPerl has a very extensive documentation set, which is basically the wxWidgets documentation with wxPerl sidenotes.

    If you can create advanced server-side applications with Perl, you can create advanced client-side applications too, just by adding a GUI to it, just like Java does

    And if the problem is the Perl installation that 'needs' to be on the client's machine...just use PAR


    Jouke Visser
    Speaking at the 2004 O'Reilly Open Source Convention about pVoice
      Among all the thoughtful replies two seem to most directly refute the object of my meditation. Hopefully the mod_perl folks will reconsider their mythos in light of this discussion.

      mod_perl docs: "Unlike Perl, with Java you can create advanced client side applications." "There are some client side Perl solutions like PerlScript in MSIE 5.0, but"

      jdporter: "Java and PerlScript is apples and oranges. PerlScript is an alternative to Javascript/JScript/VBScript (etc.). An alternative to Java (on the client) would be something embedded, like Flash, and whatever Tk or Wx thingies people might have come up with."

      Jouke: "If you can create advanced server-side applications with Perl, you can create advanced client-side applications too, just by adding a GUI to it, just like Java does." "Hasn't anyone heard that Perl has Tk, wxPerl, Win32::GUI or Gtk?" "And if the problem is the Perl installation that 'needs' to be on the client's machine...just use PAR"

      Thanks++

      --
      perl -MO=Deparse -e"u j t S n a t o e h r , e p l r a h k c r e"

Re: Creating Advanced Client-Side Applications With Perl
by zentara (Archbishop) on Apr 16, 2004 at 13:59 UTC
    <quote> focusing on the "problem" of not having Perl installed, but doesn't mention needing a VM to run Java as a problem. </endquote>

    I think Java gets cut alot of slack because there is a big "influential" company behind it. It's amazing how advertising money affects the "judgement" of various magazines, writers, and university curriculums.

    Perl installs so easily. I've gotten used to a "flawlwss install with Perl", and it would definitely surprise me if errors occured during install.

    Not true with Java. I think Java sucks, but I'm definitely biased. :-)

    When it gets down to reality, the average person likes to stick to one lanquage, to avoid confusion. Perl satisfies this need. You can do simple little scripts or complex GUI's with it.

    I have yet to see a "java 1-liner" to do something useful.


    I'm not really a human, but I play one on earth. flash japh

      I do not think that Java sucks. It is just another tool, among many (including Perl). I would agree that since Java does have marketing behind it, it has greater pull on magazines and college campuses but the programmers that you want are usually the ones who looked beyond the curriculums to realize that it is the method of development rather than the language that is important. Well, that is just my two cents. Have a nice day!