🚀 go-pugleaf

In <50077804@wbmt41.wbmt.tudelft.nl>, "Marcel Offermans" <marcel@wbmt41.wbmt.tudelft.nl> wrote:
> I agree with you. On the other hand, I would very much like to see an Amiga
> version of Java. I know there's a port underway, but I don't know how far
> it is. I see Java as more than just a language that can be used to make
> HTML pages more interactive. It can be a general purpose language, with the
> great advantage that it is platform independent.

If all you want is a platform independent programming language - well,
we've had a number of those around for a while. Off the top of my
head, there's Perl, T, Scheme->C and Python. Scheme-C even lets you
produce executables without having to have some kind of interpreter to
read them, and Python has a (python-)applet enabled browser available.
There are probably others I've missed.

The problems are that Perl is 5 years out of date (unless the Perl 5
port I've heard mutters about has been released) and missing critical
pieces of functionality from then, the person who ported T said he
wasn't going to provide any further support, and Scheme->C never made
it to the R3RS compatable version or to generating code SAS/C 6.0.

Which leaves Python. There's a port of the most recent version
available, and it seems pretty solid and well-behaved. However, for
many of the things you want to do there are parts missing that
interfere with it being used portably. For example, the CGI module
uses the URL module to get the URL string escape facility, and the URL
module uses the socket module which doesn't exist on the Amiga (for
this case that's OK; the CGI module doesn't use any of the URL module
that needs the socket module, so providing a dummy socket module works
fine).

Now, look at the problem with getting the applet-enabled browser to
work. It uses the TKinter module, which is an interface to TCL/TK.
There was a TCL port (yet another portable language for you), though I
don't know if it included TK functionality. Since TK is an X interface
toolkit, doing that interface is going to be interesting. Probably no
more painfull and resource-consuming than something like MUI, or
ClassAct if you strip out all the user configuration options that X
comes with.

Given that, you can write applets. To get the browser working, you
need a socket interface for the stack you're using.

In summary, computing environments have changed radically in the past
five years. Typically, languages give you a portable module for cpu
utilization and disk or TTY I/O. The current computing environment
includes network connections and windowing systems. A port of a
language by itself isn't sufficient to write modern applications - you
need an interface to the parts of the computing environment that
aren't tied to the language. Once you've got that you don't have the
ability to write portable programs - you need the interface to the
things outside the language to be the same on all the platforms.

JAVA offers some hope of this, as it dynamically loads modules that
provide classes for those APIs, meaning that JAVA programs are
portable to all platforms that have JAVA and a module for that API.
Python has the same kind of functionality on some platforms, but not
all of them.

	<mike