------------------------------------------------------------- WHY for Interlude trying to answer all of those annoying questions that usually start with "why the hell did you..." -------------------------------------------------------------- Q: "Why write another server at all?" in my opinion, none of the existing servers provide a general enough interface with a dynamic, easy-to-use language without becoming performance nightmares. i found myself with the opportunity to host a MU* on a machine here, but after trying everything out there, i was terribly disappointed with many of the design choices of existing platforms. if i had been more sane, i would have just waited for Greg Hudson's ColdMUD, which should be comparable if not better, but i'm not real good at waiting for others. Q: "Why did you use a Scheme-like language?" Scheme was designed from the bottom up to be easy for new people to use ... concepts like storage, type, and execution are all presented in a novel way that's easy to grow into for someone who hasn't been exposed to other programming languages. some of us old C hackers think it's a little strange, and might have to take a day or two to push through the learning curve, but after seeing the stifling, turgid crap that comes out of C-derived servers, i've come to the realization that the absolute number one priority should be to make it as simple as possible for people to do powerful things. Q: "But won't an interpreted language be slower than a compiled one?" #1) i have yet to see a server that isn't interpreted on some level ... if you can show me one that produces actual machine code, i'll gnaw off my left arm. #2) you don't use speed as an across-the-board excuse to produce unusable crap. the question isn't "how fast is it?" ... the question is "is it fast enough for what i'm doing?" we sat down and figured out what's taking the time of existing networked language servers ... then optomized that as much as possible. if that's not fast enough, i'll bang on things until it _is_ fast enough for what you're doing. #3) graphical interfaces take more CPU cycles than raw text. yet people insist that they actually _save_ time. funny. Q: "Why did you use gnu C++ and FLEX?" partly, because i wanted more experience in the language, but mostly because i hope this will provide re-usability for others and a steady upgrade path. (the standard OO claims) in addition, it seemed really silly to have OO servers written in non-OO languages. the gnu code was chosen in hopes that it would be relatively machine-independent since anyone can compile gcc on their machines these days. i had to use gnu's lexer (flex) instead of normal lex since lex produces old-style C that i really couldn't deal with. i did parsing manually (through a hand-designed LL(1) parse algorithm) rather than using YACC/BISON because i knew this would be faster since Coda is syntactically simple and unambiguous, plus this gave me greater control over the memory usage, which i needed due to the way i'm handling garbage collection. Q: "Why do you allow 'tostr' to work on user defined data types?" to keep with a true OO model for this type of data, i shouldn't have allowed people to dump the contents to string to see what's inside ... but this presented a rather large number of problems: coding with these goes from easy to exremely difficult, since ; (class #1 5) would have to return an error instead of giving an answer. similarly on down the line, there was no elegant way of doing it and still keep things non-confusing for newbies. the other reason: there had to be some sort of text format for a user defined value, since text versions of the database must be able to have these values associated with variables. if the value can't be represented uniformly, this becomes a major headache. similarly, anyone could make a program or list unreadable by just inserting a user defined value into it, since attempts to read it would yield an error. etc... therefore, i decided to settle for 'read-only' OO for this type of data