To:
[email protected]
Subject: language comparisons your java white paper
Reply-to:
[email protected]
Date: Mon, 21 Aug 95 10:05:27 MDT
Message-ID: <11832.809021127@mox>
From: Tom Christiansen <tchrist@mox>
I've read your white paper (book?) on java written by James Gosling and
Henry McGilton, and I was very impressed by its thoroughness and
professionalism. I thought therefore you might be interested in having a
couple of areas of potential improvement pointed out.
* More full-program examples would be nice.
* Why do you assert that removing functions and forcing
an o-o class paradigm is simplifying things for programmers?
Why is supplying both so complicating? Aren't you forcing
things into an o-o paradigm that shouldn't be there?
Aren't you just going to be using static class methods a lot
for those operations that don't merit a real object?
* The comparison chart on page 49 has numerous significant
mistakes in the Perl column, as well as several oversights.
I'll try to explain them at length:
1. OBJECT-ORIENTED
You say perl isn't object-oriented. Are you using the 1990 release
or perl or the 1994 release? The 1990 release was not O-O, but the
1994 is. See for example
http://www.metronet.com/1h/perlinfo/perl5/manual/perlobj.html
2. ROBUSTNESS
The robustness column is very odd. You give perl a 50%, and
yet grant tcl and the shells 100%, and C and C++ 0%. what
do you mean by robustness? You talk about compile time checking.
You are perhaps unaware of perl's ability to require declarations
at compile time. See
http://www.metronet.com/1h/perlinfo/perl5/manual/modpods/strict.html
for details.
Also, references are not castable in perl. Attempts to use
a reference as something it isn't raises a run-time exception.
For example:
$ref = \@ARGV;
print &$ref(3);
you take a reference to the program's argument list, but then use
that reference to call a function. That's a bad pointer usage,
and will trap this way:
Not a subroutine reference at - line 2.
To learn more about references, you might examine:
http://www.metronet.com/1h/perlinfo/perl5/manual/perlref.html
3. SECURITY
You equate perl's and shell's security level. I suspect you aren't
aware of perl's security features: it was designed with security
in mind. If you haven't read about it, a brief overview is
available in
http://www.metronet.com/1h/perlinfo/perl5/manual/perlsec.html
then you should. Another fascinating notion is in
ftp:://ftp.ox.ac.uk/pub/perl/README.Safe
ftp:://ftp.ox.ac.uk/pub/perl/Safe-a2.tar.gz
which Malcolm Beattie is doing even more interesting work with
operator masks. This is to support passing code fragments around
to untrusted programs, which I believe is what you're trying
to do with Java.
4. DYNAMIC
Under dynamic, you give perl 0%, even though you have given shells
50%. I don't know what you mean by dynamic. Certainly the
fragile superclass problem doesn't not occur due to perl's nature
of being a byte-code interpreter.
Its method calls are certainly dynamic -- you can even redefine your class
inheritance hierarchy on the fly, add new methods during your execution,
etc. The autoloading mechanism is quite flexible, and anonymous functions
with full lexical closure is powerful, allowing interesting dynamic
operations:
sub mkcounter {
my $start = shift;
return sub { ++$start };
}
$func1 = mkcounter(10);
$func2 = mkcounter(20);
print &$func1(), &$func2(), &$func1();
11 21 12
On the other hand, if you just mean dynamic scoping,
Perl provides both lexical and dynamic scoping of variables.
5. NEUTRAL
You assert that if one merely supplied the java run-time system,
applications written in it will run without porting. Discounting
the issue of pathnames oddnesses (filename notation is inconsistent
across different operating systems), I will grant you this as true.
However, given that, how do you give java 100%, C and C++ 0%, and
the rest 50%? I don't see how java is different from perl in this
regard. Once the main code is there, most programs will run, at least
those not requiring unique ioctl()s to get a PC hardware, etc.
6. PORTABLE
Again, you give Java and TCL 100% on portable and everything else 50%.
You explain that Java's data types are defined without respect to
architecture, and that this helps in this regard. And yet perl's data
types (and the others save C and C++) are also that way. In fact, for
doing bit access, perl defines a distinct bitlayout, so your application
doesn't need to know how your hardware works. Many operations are
emulated where the O/S or C lib doesn't support them directly, thus
increasing portability. Perl ports are available not merely for virtually
any Unix-like system, but also for MS-DOS, Mac, Windows-NT, VMS, Amiga,
OS/2, Atari, LynxOS, MVS, MPE, Xenix, and Netware, just to name a few.
Applications that aren't system-specific will run automatically.
7. THREADS
I guess you don't think running multiple tcl interpreters counts.
Malcolm Beattie <
[email protected]> has been working on threads (and
safe proxy objects and other neat stuff) for perl, but it's not in the
bundled release yet. I believe pre-releases of his work are available.
8. EXCEPTIONS
You give perl a 0%. Apparently you were unaware of its exception
mechanism. It uses a catch/throw paradigm, although there is no
resume from exception. See
http://www.metronet.com/1h/perlinfo/perl5/manual/perlfunc.html#perlfunc_eval_1
for some explanation of the low-level exception interface.
9. PERFORMANCE
You characterize the shells, tcl, and perl as all being low in
performance. Perl is a byte interpreter like Java, and thus enjoys a
ten-to-one speedup against simplistic interpreters like tcl. I would
certainly call perl's performance medium.
===============
I hope some of this will be of use to you.
--tom
