On Mon, 26 Jan 2004, Crossfire wrote:
> > Compared to Perl, Java is an insecure platform that does *not* reach its goal
> > of write once run anywhere. Perl can do this admirably. And securely.
>
> *cackle*
>
> You think Perl is a Java competitor?
>
> I haven't laughed quite so hard in a while.
Competitor? Maybe in the eyes of the programmer. I never implied
they are competing in the marketplace.
> Why is this an issue?
As I stated: one of the mos popular O-O patterns is using the constructor
to allocate resources and the destructor to return resources. That can be
done in any O-O language I can think of, except Java.
> This is one of the reason swhy Java doesn't have explicit deconstructors.
> Its to prevent you from doing something stupid with object referneces.
Java does have destructors. The programmer can create them and have them called
automatically when the object is GC'd.
There is a really simple fix for this problem:
Java *should* be calling the object's destructor when the object goes out
of scope. Then who cares when its memory is GC'd? The return of the objects
(now uninitialised) memory to the free pool can be done later:
sub foo()
{
my Thing abc = new Thing;
:
: do stuff
:
/* at this point, abc's destructor is called, abc will be GC'd later */
}
This change to Java would be backwards compatible with all existing Java
implementations
and JVM's (since it currently undefined as to exactly what point in program flow
the destructor is called, except that it is always called *after* the object goes
out of scope). And it would so simple to implement: probably one assembler instruction
to call the destructor at (here is the important point) the object goes out of scope.
> Perl's system is Ref Counting, which may work most of the time, but allows you
> to leak memory if you create reference rings and lose the entry reference to
> that ring. That's not exactly ideal either.
It is quite fine. I have worked on large ecommerce systems built from the ground
up in Perl. And yes, we inadvertantly had two (count 'em: two) cases of circular
references. We wrote a tool to find memory leaks, discovered the circs and broke them.
A very small price to pay for a far more powerful language. So, I've made Ref Counting
work *all the time*.
Have you actually ever tried to do sophisticated array / list / assoc.array / string
processing in Java? I think not. e.g. we found that what we could do in a couple lines
of perl takes literally 50-100 lines in Java. A couple lines of code is far far easier
to debug and peer review than hundred :) Have you tried to perform biometric data
processing (gene analysis) and that kind of thing in Java? O'Reilly has published
a book on how and why Perl is great at doing so. Perl is a very elegant language.
Perl6 even more so: it will support all the best O-O and functional stuff I've been
waiting for (drool). And I'll rapidly be deploying it in the workplace once it is
stable.
Java is a commodity programming language, less powerful than C++ and suited for basic
business programming, and nothing much more exciting than that. I do computing because
it is interesting, ever changing and rewarding. I have met others who do it as a rather
boring 9-5 job ... and they never seem to question the language, platform, IDE or OS on
which they work ... they just get the job done. And they are rather bemused that people
like myself even question things like that. Fine for them. They can have Java.
I'll dip into the more challenging and interesting aspects of the new languages.
I suppose if I was speaking purely theoretically, mentally wanking without any
experience,
you could punch holes in my arguments. As I have used Perl for over five years in the
enterprise, and helped my clients earn huge revenues on perl-based Linux systems,
any arguments you have promoting Java over Perl are spurious to me. It'll be a cold
day in hell before this propeller-head touches Java ever again. And I'm feel fortunate
I'm able to make the choice. :)
Back to the original thread: no, it is not more secure to allow code to run on the
client
side. The server will always be more secure from the persepctive of the web browser.
And I would include Java, Perl, VB, any language in that statement. It is folly and
naive
to contemplate that one "could write secure code that behaves and obeys all the rules
on the client side", because that is not the issue here. There are malicious users on
the 'Net who create malware traps all the time. If a security hole were discovered in
some client-side language like Java, why wouldn't such users deploy cracks for the
client
exploiting such a hole? Security has little to do with good behaviour and everything
to do with ironclad prevention. Anything less and you are misleading yourself,
your users, your clients.
cheers
rickw
---------------------------------------------
Rick Welykochy || Praxis Services Pty Limited
NAFTA might be friendly to investment but it was not all that
friendly to democracy.
-- Bill Moyers
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
