Faster processors allow for more reasonable application architectures.
Object oriented programming, which is a GOOD THING to programmers, because
it's easier to deal with and to users, because it makes programmers more
productive, could never been pervasive on, say, VAX 780 or equivalent
architectures, because they were just too slow. O-O by its nature requires
more resources somewhere, be it compiling, runtime, or usually a
combination of both. Java, in its current state, requires significantly
more of both.
>>Java is new, java programmers are new, new concepts, Im sure when C was
>>new, C programs had lots more bugs than Cobol programs.
>
>I'm not the one who stated Java was less buggy, Lucent did. Now let them
>explain it is less buggy than C and that is why they are shifting to it.
I said, and I quote:
"Java programs are much more reliable than C or C++ programs. This is
because there is no programmer initiated memory allocation, and there are
no programmer accessible pointers."
I never said that the program itself won't have bugs, just that it's less
likely because two of the major causes for bugs, invalid pointers and
memory leaks, have been removed beyond the programmer's control.
>Not to mention, they never asked US what type administrative apps we
>wanted.
Bullshit. I've been asking users what they want for management for the 4
years I've been with LuceLiving Technoprises. One of the most significant
(in quantity) requests I've seen is "can you port to ..." or "why don't you
support ...". There are few, if any, (other than SunOS, which Sun appears
to be using Java to try to kill) platforms that don't provide sufficient
Java support to run Amber. I've gotten a stack of "thank you for
supporting FreeBSD, SCO, OS/2, ... " as a result of the Java port, so I
don't think we're completely wrong.
>>> dealing with pointers from user code, although I've seen tons of pointer
>>> errors from poorly written interpreters themselves). Amber is nice, but
>>> if it is one thing, that one thing is SLOOOWWW.
>>
>>What machine are you running Amber on?
>
>Alpha PC164 - 500 MHz, 256 MB RAM running Linux. Nothing else running...
>
>Also tried on Windows NT Workstation Pentium 233 MMX with 64 MB RAM.
>Nothing else running...
>
>I guess I need MORE horsepower than that?
>
>I do agree however that speed is subjective, when comparing a C program
>to Java, it is slower -> REALLY! Even Sun admits that, then tries to
>pooh-pooh it by saying new JIT techology "may" make the Java app faster.
IMHO, Sun is approaching Micro$oft as a marketing crap generator. I went
to JavaOne conference last year when they tried to convince people that
JITs would make Java apps *faster* than native code!! I think the guy
actually believed it, too.
We acknowledge, as I have done since the beginning, that Java apps,
including Amber, will be slower than native code. If I went to the ER, and
they told me that the heart monitor was written in Java, I'd be outta there
in a *hurry*. The advantage you get is the end result of us being able to
spend more time thinking about and solving the real problem at hand, rather
than spending 90% of our time worrying about the cross-platform issues
porting from one "unix-is-unix" system to another.
andy
++++
NOC Advocate andy@livingston.com
Lucent Technologies, Remote Access Business Unit (510)737-2151
4464 Willow Road http://www.livingston.com
Pleasanton, CA 94588 http://www.lucent.com
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>