12 Jan, 2009, Lobotomy wrote in the 1st comment:
Votes: 0
I'm still looking for what programming language I'd like to learn next (mostly just to continue my hobbyist mud development desires), and while browsing about through this wikipedia page the Eiffel language caught my eye. So, naturally, I have to wonder: What about Eiffel? Does/has anyone here program(med) with that language before? Have any Muds been written using it? Should any Muds be written using it? This example on its wikipedia page makes mention of sockets, so I'd imagine that it is wholly possible to use the language to do so.

I'm little more than just curious about it right now, mind you, but any particular information or insights on the topic would be interesting to discuss, I think. :thinking:
12 Jan, 2009, David Haley wrote in the 2nd comment:
Votes: 0
It's likely that I can't tell you much more than you already know. I know of Eiffel, have messed around with it very briefly in class, but know of basically nothing written in it (for whatever that's worth). What was it that caught your eye?

Should MUDs be written in it? Well, that question is an extremely open-ended question. Should a MUD be written in any given language? You cite an example that makes use of sockets, but I'm not sure what your intention was in citing that example. Yes, I suppose that any language that supports some kind of socket makes it "possible" to write any kind of networked application in that language, but I wouldn't consider that to be anything more than a very basic precondition.

I think that to some extent, the most important thing to think about is what kind of general features you need, and then poke around in a few languages, seeing which you like generally speaking and which you don't, and then take the plunge and go with one. A lot of people get bogged down in endless questions about which language is "best" and in the end of the day don't write any code for years, having experimented with tens of languages during that time.

There are several important things to consider when choosing a language:

- abstraction: does the language provide the appropriate level of abstraction for your application? If you're writing a low-level application, does it let you get close enough to the hardware? If writing a high-level application, can you avoid worrying about the hardware? Can you do both at the same time?

- abstraction (bis), or encapsulation: does the language provide mechanisms to encapsulate, modularize, and create your own abstractions? This is important for any well-designed application.

- various features: if garbage collection is important to you, does the language have it? Can it handle unreachable but cyclical structures? Is it reasonably efficient? etc.

- library support: how many libraries exist for the language? Or, put another way, to what extent will you have to reinvent the wheel? If you find yourself having to rewrite too much code that should be in a standard library, perhaps you shouldn't be using this language.

- efficiency: even in a high-level language, efficiency matters to some extent. How fast does code in the language run? Most importantly, does it run quickly enough to let you do whatever it is you're doing?

I think that library support is a very important thing to think about, actually. There are many languages that are incredibly nifty languages, because they support very nice programming techniques, but have almost no library support and therefore force you to rewrite a considerable amount of relatively basic code yourself. For example, having to write your own container classes is kind of annoying.

One thing I have found in my experience is that I tend to prefer statically-typed languages when writing large systems. There comes a point where you can no longer keep your whole program in your head, and getting help from the compiler in the form of type checking is invaluable. I heard from somebody that they would like static typing across module boundaries and dynamic typing inside a given module; I think this would be getting the best of both worlds. Anyhow, the point is that I would discourage the use of a dynamically typed language for implementing a large system. A MUD is just big enough to qualify as a large system, I think.

I'm not sure if you'll think this constitutes an answer to the question, but IMHO the question is vague to begin with and might not even have an answer suitable for everybody. If you know Eiffel very well, it might be quite appropriate. If you don't, maybe it wouldn't be worth learning it.

To be honest, I think that making a language choice like this is really only appropriate after having worked in many languages to begin with, and after having a relatively deep understanding of the concepts and paradigms involved. There is a lot of value in staying close to things you already know. For instance, if somebody knows C very well and is looking to expand horizons, I would probably recommend Java or C++ more highly than something like Ruby or Python, given the relative closeness of the languages: this would help flatten the learning curve. Of course, if they were doing something that really isn't appropriate for C++ or Java, the answer might change… the answer "it depends" is probably starting to emerge as a general trend here. :smile: