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

[Trevor Phillips]

John Summerfield wrote:
> 
> 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).

Does Opera? Mosaic? KDE's explorer?
Ok, personally, I run the latest Debian (ok, it's Slink with a dash of
Potato), I try to keep my kernel up to date, and I use the latest
non-beta Netscape, 4.6.
And I turn Java off and leave it OFF by default, because I'm sick of
Java applets crashing my browser. It's only a few (about 10%), but
enough to really annoy me.

As I also mentioned, even using 4.6 on Linux, and 4.6 on Windows, I've
found applets that behave differently in both.

Hmmm, an example I wouldn't mind some feedback on is the National
Australia Bank's online banking. Anyone else use it?? It's a Java
applet, yet only supports certain platforms, and I've yet to get it
working under Linux. I asked them about Linux and UNIX in general and
their response was "We plan to do a UNIX 'version', but no timeframe as
yet".
Platform-specific Java applets??

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

That's rather subjective, and depends a LOT on the page. Most of what I
deal with, if the page is large, it's due to textual content, not
formatting. Are these pages generated by a WYSIWYG? ^_^
Pages with a 90% ratio tend to be small overall anyway. ie; the ratio is
that way because the content is little (and so most is
header/heading/division markups).

Overall, HTML pages are fairly small compared to the accompanying images
most sides seem to have nowadays...

> 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?

a) Latest lynx has Table support (enough to get minimal row divisions)
b) Strip out all table elements, and a page's content is still quite
readable, in most cases. Strip out a Java applet, and the whole thing is
gone.

I use Lynx as an extreme case, although even that is hard now with its
support for Frames, and even Image Maps now. ^_^

Thing is, you can't depend on someone having Java enabled, you can't
depend on someone having JavaScript enabled, etc ... But strip out all
HTML fields, and pages can still be readable. You're not relying on
features for content; just presentation.

> > 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.

I'm arguing Perl's extensibility as a plus. ^_^
Ok, someone brings out this ducky widget set, say, called Gtk. It's a
neato widget set! It'd be nice to use it! Hmmm, it's all in C with C
libraries. Oh well, let's write a GTK app by using the GTK Perl library,
shall we? 
IMHO this also helps, um, what's the word?? Where you keep separate
things separate?? Basically, the library handles what it is good at, and
the  Perl script organises the functionality of what the app does. 
It's similar to normal shell scripts calling UNIX commands to do
everything (as someone suggested for simple apps), but without all the
forking and non-enforced dependencies.

> > As I see it for Java:
> >
> > Disadvantages:
> >   - Steep learning curve
> 
> Easier than perl. I speak as one who's learned both in the past 12-19
> months.

Wow! You found Java easier than Perl?? I picked up basic Perl in a
couple of hours going through a tutorial. Making simple apps using
libraries like the CGI one in no time. Looked at Java for several days
and just couldn't get my brain around it.

> >   - 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.

It is, I know. But depending on the app and the situation, a small delay
each time can sometimes be preferrable... (And with (Fast)CGI, the delay
is 99% network download of the page)

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

Depends on the app. I do "dynamic" content all the time which is cached,
and I'm striving to honour the If-Modified-Since header of HTTP
requests.

> > And for Perl:
> >
> > Advantages:
> >   - Easy to pick up language
> 
> I found it harder than java.

Which I find rather boggling. ^_^
A few nights ago, I decided to write a Perl Module with some OOP in it.
You know, constructors, methods, encapsulation, etc ... A few hours
later I had my brain around Perl OOP, and had my Module up and working.

> >   - 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.

Much of what I'm doing of late is server extensions, rather than
independent applications. That is, I'm tending to write solutions more
generically, rather than application specifically.

A case in point is they wanted an A to Z url listing, with some
sub-views, and a simple search, taking the info from a data file. I
wrote a generic handler for the presentation of data records.
Example of the initial app spec:
   http://www.murdoch.edu.au/cwisindex/matoz.ndx   (and associated
sub-pages)
Other implementations since then:
   http://www.murdoch.edu.au/cwisindex/dso.ndx
   http://www.murdoch.edu.au/cwisindex/servers.ndx
   http://www.murdoch.edu.au/teach/units/units.ndx/atoz

> > 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.

I mean simple JS such as form verification, like the example of editing
25 hours in a day field. And if JS is off, the CGI itself checks the
data after submission...

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

For small tasks or large-ish projects?

> 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

"thumping great"?? Looked at the filesize of a GIF graph lately?? Let's
see, our usage graphs, the largest one is a thumping great 5k in size!
Most are around the 2k size. Even over Modem, that won't take long...

> 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.

Probably 12k for such a graph would be plenty. Unless of course you want
a Truecolour one with sexy nature-scenes textured on each surface...

Don't get me wrong, those examples as Applets DO have their advantages!
I'm just not sold on Java's advantages/disadvantages for most of the
apps I do (mainly development time, and cross-platform problems). And
true, I've yet to do an app that involved (aka needed) creation of
graphics on the fly; all my apps deal with textual data processing and
display.

Actually, I lie, I did a dynamic Page Stats script a while ago. Did
graphs of usage/access! How did it do the graphics?? Easy! Using a 1x1
black pixel, a 1x1 transparent pixel (yes, they'll be cached), and
Tables + background colours!! (Note: No, I didn't have hundreds of
<IMG>'s; I used width and height to stretch the pixels to the right
size...)
Stats were gathered from the Webserver access logs, which were logged to
a DB (not the server's default behaviour), allowing the stats to be
dynamically generated
Must finish that script some day. ^_^

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

Latest browsers can do this. ^_^

-- 
. Trevor Phillips             -           http://jurai.murdoch.edu.au/ . 
: CWIS Technical Officer         -           T.Phillips at murdoch.edu.au : 
| IT Services                       -               Murdoch University | 
 >------------------- Member of the #SAS# & #CFC# --------------------<
| On nights such as this, evil deeds are done. And good deeds, of     /
| course. But mostly evil, on the whole.                             /
 \      -- (Terry Pratchett, Wyrd Sisters)                          /