Java and Perl (was Re: [plug] Time & Task Management Tool)

[John Summerfield]

> John Summerfield wrote:
> > 
> > Java is on more platforms. While I can get perl for OS/2 and winders for
> > example, they don't ship with perl. However, java's in every more-or-less
> > current browser.
> 
> That's part of the problem I see. Java is in most browsers, sure, but a
> Perl server-side application doesn't require something like Java
> server-side. As such, you can write an application that is server-side,
> which will work on even MORE browsers, even down to text-based Lynx,
> which can't even do images let alone Java (due to its text-based
> nature).

Lynx aside, what browsers are actually in use that lack Java support? If 
you can name any (I can), does the user have a choice (in the case I'm 
thinking of, the user does).

> 
> > Java runs on the client machine: data needn't be formatted with all that
> > html, and web pages using java can result in reduced bandwidth.
> 
> HTML is just a way of formatting the data; the data itself is rarely
> HTML-enriched. And I'm sure you have to do a different data call or
> options to get Bold text over normal text. ^_^

You'd be surprised at the html overhead. I regularly get some web pages 
that reduce 90% by removing html and redundant (constant) text.

> 
> > Java runs on the client machine. It can do preliminary data validation
> > (Did you REALLY work 25 hours last Sunday?) before sending it off to the
> > host.
> 
> *nod* I think client processing is handy; I just don't like requiring
> such support. I'm a semi-big advocate of backwards compatability with
> the lowest denominator. Catering to the Feature-impaired doesn't mean
> you can't have enhanced features for those that DO support it.

Comes the day, though, when one must step forward. Do you cater for lynx's 
lack of tables, or do you recommend users use netscape, IE, webexplorer, 
hotjava etc instead?


> 
> > Java can produce applications (not just applets) with a MUCH nicer user
> > interface than perl can.
> 
> But with more work involved.
> 
> > Java is MUCH better at drawing charts than perl is.
> 
> Hmmm. Not necessarily. Perl can talk to a myriad of graphics libraries
> for image generation. A few common ones that spring to mind are the Gif
> lib (GD?), the ImageMagick libs, and Gimp (yes, a Perl CGI with the
> graphics power of Gimp is truly scary!! ^_^)

THen it's not perl any more: it's perl and an army. Java has it built in, 
perl doesn't.

> 
> As I see it for Java:
> 
> Advantages:
>   - Complete customisability of interface
>   - Client-side processing & checking means faster feedback to the user
>   - Cross-platform compatability
> 
> Disadvantages:
>   - Steep learning curve

Easier than perl. I speak as one who's learned both in the past 12-19 
months.

>   - Many hoops to jump through to do things
>   - Pesky "downloading Java applet" time (for proper applications)

If the design's good, that us usually balanced by reductions elsewhere.

Remember too, dynamic content doesn't cache. Java applets are not dynamic 
content and do cache.

>   - Requirement for Java; and it's NOT the same per platform, not just
> for stability. A recent example was the StarWars Asciimation; looked
> fine under Windows Netscape, but Linux Netscape had the output squashed
> and upset the "frames".
> 
> And for Perl:
> 
> Advantages:
>   - Easy to pick up language

I found it harder than java.

>   - Great module expandability and availability - simple to write
> complex apps based on existing modules

java's at least as expandable. Availability's not perfect yet, but it's 
coming.

>   - Easy interface to C libraries available (eg; Do databases (Oracle,
> MySQL, etc ...), do graphics (via GD/PerlMagick/Gimp libs), etc ...)

java comes with DBMS access. It comes with graphics. It comes with sound 
too for that matter.

>   - NO client-dependency means one machine needs Perl (the server)
>   - Allows greater server control through expanding Apache server
> functionality (eg; customisable SSI's, logging methods, authentication,
> etc ...)

The server normally serves the applets so I don't see this.
> 
> Disadvantages:
>   - Server-side means any app update involves client-server
> communication (tho can be reduced using minimal JavaScript)

javascript is somewhat insecure from what I've read.
> 
> 
> Hmmm. I think that about covers it!! ^_^
> Note: This is my view, and my opinion. I use Perl a LOT, and my Java
> development experience is minimal. I would be greatly interested to see
> what other people think, esp if there's someone who has used both Perl
> and Java a lot for large applications (as in not just small cgi's).

I've not used either a lot, but I've used both reasonably often.

Picture this, and I'm making an example relevant to the original topic:
An organisation has project management software that's interfaced to the 
Internet. Let's say it produces all sorts of graphic reports: gant and 
pert come to mind, but it's years since I looked at this stuff.

If these charts are produced on the server, it has to send thumping great 
images to the client. Otoh, if the server just sends an applet (only 
needed if the latest version's not cached) it only needs to send a few 
data points, and the applet does the presentation on the client machine.

If the client machine's operated by a manager, he can maybe fiddle around 
with a few what-ifs: different staff assignments etc, and having made a 
decision, transmit the results.

Consider a share trader: calls the broker on the web, wants to draw a few 
charts to plot the next trade. Same thing: applets on the client machine 
can get the data points for the stock(s) of interest: about 12k ascii for 
a year's data for one stock and draw any number of charts on the computer, 
Or, the user can die waiting for the images to be downloaded, and go 
through the same wait next day because the images are dynamic: if not 
dynamic, then they change daily anyway.


Another advantage of doing the presentation on the target machine: it can 
find the screen resolution and adjust the presentation accordingly.


-- 
Cheers
John Summerfield
http://os2.ami.com.au/os2/ for OS/2 support.
Configuration, networking, combined IBM ftpsites index.