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

[John Summerfield]

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

Don't know about opera, but the platforms where I know it's availal,e 
users have an alternative, and it's likely to be installed.

Mosaic I thought hat died, but ditto.

KDE? Qui sais. But ditto.

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

I've not tried 4.6, but I reverted to 4.08 on account of problems with 4.5.


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

Subjective? 90% is OBJECTIVE, or was when I was at school.

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


I don't know what generated them, but after 270+ enquiries the bulk is 
considerable.

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


Hmm I have 2.8.0. What do I need? 

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


For corporate software (and that's where we started, allowing a Uni to be 
a body corporate), one can make executive decisions about these things, 
especially for in-house software. Even in cases such as NAB one can 
reasonably say, "to use this service you must have a java-enabled browser."

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


I wouldn't: it means learning YAP/YAL.


Besides, we started discussing the merits of Java. They stand alone, but 
to illustrate them I made some comparison with Perl. For many things where 
Perl requires add-ons, java doesn't because the capability's built in. I 
can also find all manner of advantages to perl, but that's not the 
original question.

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

Nobody learns perl in a couple of hours. You might learn a little perl in 
that, but I have a book containing about 650 pp. Nobody can even READ it 
in that.


I taught a REXX course for IBM about three years ago. REXX is comparable 
to Perl in function. The "introduction" course runs three days, and if 
you're not a programmer already, don't expect to understand the material 
in that time.


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


The particular kind of dynamic content I had in mind is pages with pricing 
information: ask for a price on something different, you get the whole 
page again with maybe as little as 20 bytes different.


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

jserv integrates nicely.

> 
> 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 turn off javascript and allow java. java was designed to be secure, and 
has a better history in that respect than its competitors.

> 
> > I've not used either a lot, but I've used both reasonably often.
> 
> For small tasks or large-ish projects?
> 

Small in both cases.


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


12k may well be enough for the applet, and that gets cached.


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

To change the layout of a form?

Weren't you arguing for older browsers a while ago?

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