Edward J Glamkowski [eglamkowski@angelfire.com] wrote:
> 1.Byte-code: Java's byte code specification is
> rediculous. What should have been built was a sort of
> "universal assembley" that could, if needed, be
> assembled.
> Instead we have a byte-code that is guaranteed to
> be slow and difficult to port, because of purported
> "security" issues (which only arise on MS-Windows
> machines).
The security issues that have arised so far are due to browsers, not
Java itself. "Universal assembly" is a joke, when you consider
endian-ness, CISC/RISC, etc. Byte-code -can- be compiled into machine
code.
> 2.Built-in: Java's built-in functions are obtuse and
> random. No attempt was made to make modern visual
> programming easy or even "probable".
Try Java beans and reflection. Standard C++ has neither concept. And
this isn't relevant to designing a mud.
> Just dragging
> an image requires you to implement a double-buffer
> class (or worse, find one).
+>3. The 90's: [and pong]
Java2D fixes most of this. And who cares? Write your own lib, or buy
one, just like you'd do in C++. We're writing a mud, anyway.
>4.Libraries
There's no 3D modeling library distributed with C++ either.
> Thread management requires
> you to manage time-slices yourself.
This is the only valid point I've seen here. I don't think it's really
an issue except in realtime environments. Someone want to point out
something I'm missing? Name an environment where you =don't= have to
manage your timeslices yourself, one way or another?
> No
> multiprocessing is even implied.
Could you please try to explain this statement?
> Event handling
> consists of a bizarre series of derived classes which
> export interfaces that are called by a main module
> which performs a message handling loop. And that's the
> easy part.
Event handling is quite complicated internally in the JVM, to the user
(read: developer) it's elegant and easy. Just for grins, give us a
description of event or error handling within C or C++.
> 5.Cross Platform:
I've found platforms to be pretty consistent given the same JDK/JRE.
I'd love to hear some well reasoned arguments against writing a mud in
Java, but I don't think these qualify.
-smw
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST