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

[Trevor Phillips]

John Summerfield wrote:
> 
> If you need to run Java applets, you have choices available to you. One is
> hotjava. Tru it needs a bit of computer power, but I have seen it in use
> at ECU.

I've never managed to get HotJava to run for longer than 10 minutes
without it crashing.

> However, don't write Java off as a useless toy: it's far better at what it
> does that PostgresSQL is at what IT does.

I don't write Java off, and I like the concept. I just don't think it's
there yet as an All-Platform application solution.

> > I think that version has tables support.
> 
> It's still not very good.

But it is still useable! With Java it's all or nothing, with most HTML,
if the browser doesn't support it, you still get the content.

> > Oh? Why? I should use Windows98, JUST so I can access my bank details??
> > Heck, it's easier to revert to the primitive phone banking!
> 
> There are java-capable browsers for OS/2, MACOS, most if not all versions
> of Unix, 32-bit Windows.  Who's left out?

As I said, the Java Applet that is required for my Internet Banking is
only supported by Windows9x/NT!! As in it doesn't work at all under my
Linux setup! So in that case, I *do* need to reboot into Winblows just
so I can do my banking.

> Both have their place. Perl's user interface sucks. Java's specifically
> NOT aimed at OS-dependent stuff. I think Java's networking's better: I
> have just started using Net:FTP. My ftp timed out and I've not got the
> foggiest idea of what to do about it whereas Java would throw some kind of
> exception and I would find that easy to fix.

Perl's User Interface? It's versatile is what it is. In its simplest
form, it's stdout, same as most UNIX text-based apps. Even that allows
you to use HTML as the interface. With the addition of libraries, Perl's
interface can be almost anything (eg; Gtk/Gimp).

> Assuming you configure your web server to use mod_perl for Perl use and/or
> jserv, I expect performance would be comparable for similar application
> designs. jserv uses its own port for communicating with user applications:
> this may lead to some advantages for Java.

Own port? Sounds a lot like FastCGI to me. ^_^

> > No, I'm arguing for backwards compatability. The design of a page (or
> > app) such that it will work on ANY browser, old or new, and can use new
> > features but doesn't RELY on them.
> 
> That rules out Javascript, Java, tables...

No, it doesn't! As I said, you CAN use JS/tables/frames/etc with older
Browsers, be it by auto-detecting browser capabilities and offering a
different cut-down version, or by just using them in such a way that the
lack of them doesn't impede application usage too much.

With Java it's all or nothing.

> > Also, total, 66% of people use the Java applet. That means there are 9%
> > who DO use the High Bandwidth, but don't have Java-capable browsers.
> 
> No no no. Doesn't mean that at all. The fact they don't use a Java-capable
> browser does not mean they don't have one. On OS/2 I prefer to use
> WebExplorer which does not understand Java or Javascript. I use it because
> it's fast. However, I do have Netscape and it understands both Java and
> Javascript.

But it is unrealistic to require the general public to install and use a
Java-capable browser, just so they can access your application. True, in
a LAN/Corporate environment you can require it, altho even then you'll
most likely find complaints from people about being forced into one app
or another.

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