[MUD-Dev] New to MUD Dev, need friendly advice!

shren shren at io.com
Wed May 14 16:21:37 CEST 2003


On Wed, 7 May 2003, Eric Merritt wrote:
> [shren <shren at io.com>]
 
>> Mutexes and the like are not simple tools to use.  I have my
>> first multithreaded code that I ever wrote.  I wrote it merely by
>> looking up what the functions did - I hadn't yet had any class or
>> formal training with multiprocessing.  The code is, by and large,
>> horrible.  It took a design class and a bunch of code writing to
>> finally start doing threads and processes right.
  
> I would say that the difficulty in using multiple processes is in
> the language not in the use of multiple processes it self. Take a
> look at Erlang, this is a language in which you can literally have
> a 100,000+ processes running at the same time. Granted, they are
> vm processes and not kernel processes, but in this instance you
> are using them to structure your program not for any speed benefit
> so that doesn't matter. Even in Oz (which uses a different
> threading mechanism then Erlang) its pretty simple to use
> processes freely.

Do these languages see much use in the hobby-programmer community?

>> If someone just wants to write a mud for the fun of writing a
>> mud, then there's no reason to use threads when you can do
>> without, especially if you don't already know the ends and outs
>> of multiprocessing.

> Better yet use the right tool for the job. If you want to use
> multiple processes use a concurrent language, if you want blazing
> speed use a fast language, if you want passible functions,
> continuations, etc use a functional language.

I've always held to the axiom that the right tool is the tool that
you know how to use and can do the job.  That might just be me.
Still, this is all a little off topic - no real need to bring the
language crusade into a conversation over if simple muds need
threads.


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list