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

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/
Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Thursday January 17, 2008
09:40 PM

Client Side *What* Now?

[ #35416 ]

Whenever I use a non-Java language, I always have this nagging feeling in the back of my head that something is going to hold this piece of code from ever becoming mainstream or used by a lot of people. It can be because the language is slow, or that it needs an interpreter. Or that it will be hard to deploy my program on a user's machine.

Cedric Beust, I'm not tired of Java yet

I won't argue that Perl apps (Perl 5 apps) are easy to deploy, but Java? Really?


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Client Side *What* Now? 18 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I think maybe the Sun marketing chip in your head is loose, don't you remember, Java is "Write Once, Run Everywhere". I mean it's not like it requires a virtual machine (*cough* JVM version incompatabilities *cough*), or that virtual machine is so notoriously slow that is would require lots of investment into some kind of JIT compiler or something.

    Next thing you know you will be complaining that Ruby is not an ideal language for writing DSLs in. *sigh*

    - Stevan

    • My problem is that I remember trying to run Java applications on multiple platforms for which there was no (or in some cases, no recent) JVM. These were not exotic platforms, either. Perhaps you've heard of GNU/Linux?

      • Clearly you are some type of subversive {commun,terror}ist and should be banned from writing software no matter what language. Don't you know that nothing in life is free!?!?!

      • Reminds me of a complaint a colleague has. He recently bought some hardware that lets you do all sorts of fancy reconfigurations. Unfortunately, you can only do this with Windows, not Linux. Apparently a developer at the company told him "we only support mainstream operating systems."

        • It's true that Linux isn't a mainstream OS. Go into Staples [wikipedia.org] and look for Linux -- I found only Windows and a little MacOSX. Go into Waldenbooks [wikipedia.org] (or whatever crappy bookstore there is in your local mall) and try to find a Linux-related magazine (after filtering out magazines without boobs, plants, balls, or guns on the cover). Can you find something in Walmart [wikipedia.org]? I'm wanting to install Ubuntu on my mom's computer while I'm at home, and I forgot to bring a CD with me and she's on dialup, so I've been looking ar
  • That's funny. Whenever I see an application is written in Java, my first thought is that it will be a hassle to install and slow to run. Then I generally move on and keep looking for something else. My bias may be totally wrong but there it is.
  • BTW, I usually think the same thing about Perl GUI apps but I just tried out Kephra on Windows. It was one-click easy to run and seems pretty fast.

    http://kephra.sourceforge.net/ [sourceforge.net]

  • "Perl programmers know how to efficiently deploy Perl apps, but not Java apps, while Java programmers know how to efficiently deploy Java apps, but not Perl apps. Film at 11."

    When I think about it, deploying's a nightmare in every single language I know. Perl? It's not everywhere. It'll run everywhere, but if I want to write something for my Dad to use, getting Perl to him is not going to be easy. Java? Same story, only I've got less experience and less ideas how to go about it. What's left? C/C++

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • If you're gonna put stuff on your dad's desktop, PAR/PerlApp + InnoSetup makes things just as easy to install as any other Windows program.

      It's not a problem. Really.
  • Really. And whilst the Java deployment story isn't great, I do prefer the bundling of Jars to installing CPAN modules. It's much more manageable.

    • The CLASSPATH environment variable. The horror.

      • Compared to installing XS modules on Windows? I know which I'd rather have to do.

        BTW, this is no affront to the fantastic nature of CPAN. Just my ability to deploy it simply.

        • I had forgotten that particular hate. Good point. At least I can get away from that by not using Windows though.

        • I have VC++ 6.0. No problemo. :)
        • Have you tried Strawberry Perl?

          I've been pleasantly surprised again and again installing stuff on Windows with cpan recently, to the point where I have almost started expecting things to just work.

          And it does.

          I attribute this mostly to the tremendous work of a) Adam Kennedy and b) the Catalyst team which really started taking ease-of-installation seriously a while back. And it paid off.

          Actually, if you still have problems installing things on production boxes, you can get things working in your dev environm

          • Strawberry Perl is great – I used it to ensure I could get XML::Genx [cpan.org] to compile under windows.

            But when it comes to application deployment, I still think Perl is a pain compared to Java. Part of that pain is XS modules.

            • You can't bundle them with your project – they need to be compiled on the target environment (or a near facsimile).
            • There's no mechanism for specifying any 3rd party libraries that they depend upon. At least with jar files, you can just include the dependencies directly
  • Where the quoted text said 'non-Java language', that should obviously have been 'Java-type language'.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.