On Sat, 19 Jun 1999, Cervo wrote:
> Hehehehe funny :)
I don't see the humor. In fact, I was banking on after the JavaScript
port, we'd do it in PHP and in 6502 assembly. Frankly, I find the lack of
support for the Atari 400 a glaring omission and downright apalling.
Another language to consider would be IBM's exquisite APL. Anything you
need an extended character set or Unicode to write in is just dandy in my
sanguine tome bound in freshly-flayed COBOL programmer skins.
Also, I'm now accepting volunteers for the punch-card version of
CircleMUD. If you'll remember, I began this project 4 years ago, but it
suffered a major setback when my cat, Thrasher (no, seriously), knocked
over the box of cards before I had went through and numbered them. I
recently decided to begin the project again, and I've already went out and
bought the estimated 73 million punch-cards necessary. This time I'm
taking to heart the idealogy of always keeping a backup, so if anyone has
73 million spare punch-cards (I've already bought up the entire supply on
the west coast), please contact me.
> Now after reading this thread, it seems to me as if there is some
> confusion going on. It looks to me as if some people are confusing
> JAVA and JavaScript.
I don't think he was confusing Java and JavaScript, but some people still
don't have any clue as to what the difference is. (If you're one of those
people, the difference is: everything. They're unrelated languages that
happen to have the same word in their names.)
> Personally I've never played with JavaScript, but if making a mud is
> possible in java script it would be hilarious.
It's not feasible...well, not yet feasible. The newest standard (which,
BTW, doesn't go by the name of JavaScript) might make it possible. On the
other hand, I would rule it as unfeasible simply because no-one in their
right or wrong or twisted or blossomed-and-fried mind would *want* to do
it.
> 1. First thing is that many people don't know how to make linked
> lists/pointers---Java provides a Vector Class. (Also in C++)
However, you're just exchanging one misunderstood concept with another.
Imagine all the questions about why someone can't create an instance of a
class clearly marked "abstract", or can't derive from a class clearly
marked "final". We must accept the inevitable: no matter what language
CircleMUD is written in, there will always be people who don't understand
the concepts it employs necessarily.
> 2. Java will compile/execute anywhere.
Write once, crash everywhere. I've seen very little Java run reliably.
> 3. Sockets as well as many other things are much easier to use in
> java and require much less code
On the other hand, most people don't need to worry about it, and it's
really not that difficult to do in C, either. The primary sticking point
for me with all of my socket coding has always been properly maintaining
output buffering in an efficient manner. (And not spending 2 hours of my
time [not to mention George's] trying to figure out why telnet isn't
accepting my IAC when I'm explicitly doubling them after establishing the
person is using telnet.)
> 4. Better organization and encapsulation (Also in C++)
Or worse. It depends upon how you write your code. Some of the ugliest
piece of sh!t code I've ever seen has been C++. But, then, it's almost
always the person and not the language. (The exceptions being the ugly
template syntax and the entire Perl language.)
> 5. Tons more features than C that are portable, like sound, graphics,
> etc.
Certainly "built-in", although not every platform provides these, and
Java3D and the Java Media whassit aren't exactly functional.
> 1. No explicit way of freeing memory (BIG Disadvantage)
The mark-sweep GC is supposed to handle this. It's a no-worries approach,
which is somewhat contrary to my prefered "hands-on" approach. I tend to
dislike machines doing things for me while they prevent me from doing them
myself. GC as a catch-all safety net seems better to me that GC as the
only method to get rid of memory.
> 2. Slower than C/C++
CPU doesn't much matter in the context of text MUDs of this variety.
Certainly MUDs that employ real-time calculations of complex systems, be
they economic or physical, might beg to differ, but I work on the
presumption that those are a different animal from the vast majority of
CircleMUDs. A popular text MUD (meaning 100+ players online
simultaneously average per day) these days needs only concern itself with
having a lot of memory and a good cache.
> 4. CircleMud would probably have to be rewritten from scratch
Not necessarily a bad thing, mind you. I'm sure we could come up with a
decent list of things in CircleMUD overdue for a groundlevel redesign.
> Personally I wouldn't touch java for a mud with a 10 foot pole.
I wouldn't touch Java, yet, at all, period. Well, except when I have to
at work, but that really doesn't count.
> Also advanced stuff like trees/linked lists/graphs/hash tables can be
> used by inexperienced programmers via a class interface.
"Advanced" stuff like linked lists are already used by inexperienced
programmers in CircleMUD. Of course, this is primarily because linked
lists, despite the fact they employ pointers, aren't difficult to
understand or use. The same could be said for hash tables with collision
resolution via linked lists. Someone need not understand what a "hash
key" is, what "collision resolution" is, or what a "next pointer" is in
order to employ hash tables and linked lists.
> So discussion the future language at this point is probably futile
I wouldn't say that. Even if CircleMUD 4.0 is a ways off (and, actually,
one can never be sure with projects like this -- things change overnight),
this doesn't mean we cannot have an impact on what will constitute it.
Actually, it means quite the opposite. The closer we are to 4.0, the
better chance there is that Jeremy has already made up his mind.
> Cervo the redoC retsaM
I knew a redoc retsam, once. For those that don't know, a redoc retsam is
an individual who suffers from the desease, "specialized C dyslexic coder
syndrome," (SCDCS) which is a selective form of dyslexia that affects only
C coders and, more specifically, their code. SCDCS may have affect an
individual more broadly than just inversion of code keywords, but it is
most often seen in a very limited form. Contrary to popular belief and
the name of the syndrome, scientists have discovered that the syndrome is
not specific to ANSI C, but can even affect those on the very fringe of C
coding, such as those using 'csh'. Conservative estimates place the
number of affected coders as high as 70%, but of these, only 1% have
chronic, serious problems with SCDCS. That 1% of 70% of C coders in the
world (which is probably a very slim percentage of the total population)
are classified as "redoc retsams". (For more information, see the Redoc
the Hague Chapter of the Retsam Support Group for Sioux Indians, and
various articles by the Associated Press.)
-dak
+------------------------------------------------------------+
| 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