From: Dale Johnstone (DaleJohnstone@email.com)
Date: Sun Apr 15 2001 - 09:42:33 MDT
Patrick McCuller wrote:
> OK, stop the Java bashing. I've programmed in more languages than you've
>likely heard of, and Java is my favorite for many, many technical reasons.
The biggest mistake in this post was to start by making it personal. I will ignore that (honestly). Suggestion: if you're trying to argue a point with someone, making it a personal issue is just about the worst way of going about it. Tempers are lost and things quickly deteriorate into a mud slinging match. There's no need - I'm fully able to concede a point if you have a rational argument. Becoming emotional about programming languages is not useful either, I've seen more than my share of that thank you. For what it's worth, I happen to like Java, so please refrain from pigeon-holing me. This is the SL4 list, not some warring OS newsgroup.
>Memory consumption is NOT a big issue for Java.
I have to disagree. I don't know what blend of Java you're using but I had to abandon it for an image processing app I was writing. It was fine until I started dealing with large images - Java's garbage collector struggled to provide the contiguous memory blocks I needed, the whole thing ground to a halt, and I don't just mean very slow - it stopped functioning*. Most of the code I ported from C, so I'd seen it running beforehand and had an idea what to expect. If you haven't experienced these problems then perhaps the VM you've been using is superior to the one I was using (Symantec), or perhaps your Java apps haven't had the same memory requirements.
*Just as you can take optimizing to an unnecessary extreme, so too can you take ignorance of memory consumption. Both will bite you on the bum and you'll get nowhere. I repeat - you have to use the right tools for the right job. Java was not the right tool for the job here.
> Speed is NOT a big issue for
>Java. But this is irrelevant.
Now you're putting words into my mouth. I don't have a problem with Java's speed. It compares well to C++ providing the datasets are not large.
> You could write an AI in B for all I care - interpretation speed and memory
>usage will have ZERO impace on an AI that DOESN'T WORK. Just make it work, and
>you'll do fine.
Are you sure you read my post? I wrote (to Eli): "I would suggest you concentrate effort on the development issues (like flexibility) rather than speed issues."
You seem to have interpreted that as if I'd said exactly the reverse. Strange. On the other hand, it's a common occurrence on mailing lists for people to spot something they don't like (e.g. Java remarks) and focus on it completely, ignoring everything else that was said. You're immediately vilified and nothing you say from that point on makes the slightest bit of difference. There's no need for the aggressive tone, I'm not your enemy.
> Two scenarios.
>
> Scenario A. You have a really fast, really slick program that has few
>hardware requirements. Unfortunately, this program is not a functioning AI -
>it can't reprogram itself. You've got two, three years of more slick
>programming to do before it's got a chance to do that on its own.
>
> Scenario B. You have a slow, clunky assembly of programs that suck processor
>time and gobble up memory in ways that make particle collision analysis
>systems look tame. Just to run it you've got to spend crazy cash leasing
>supercomputers. But, IT WORKS. The damn thing improves itself without much, if
>any, help.
>
> Which situation would you rather be in?
Who are you arguing with? And why do you insist on this simplified black & white picture? <sigh> Why do people always argue as if the world is either camp A or camp B? Let's leave that to the politicians please.
Patrick, I think we probably agree on most issues here (with the possible exception of Java's memory management) so for the sake of list quality I suggest we drop the subject. You are welcome to email me privately if you want to continue, although I have to say I'm not terribly interested. :-p
Regards,
Dale Johnstone.
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT