19 Mar, 2013, salindor wrote in the 21st comment:
Votes: 0
However I would like to offer a counter argument to this (mostly for discussion sale)

Are you telling me you have never been burned by a library you thought was great then had to spend hrs ripping it out to replace it with something better? I mean true it hasn't happened often but I have had it happen a couple times. By creating a layer between you and the library you are in effect creating an insulating layer to protect yourself from library changes. For a hobby project the number of devs is likely small and you can make this isolation is structured according to the way you think reducing the number of bugs you might code or if your understanding is wrong you have a singular place to fix the problem.
19 Mar, 2013, Runter wrote in the 22nd comment:
Votes: 0
salindor said:
However I would like to offer a counter argument to this (mostly for discussion sale)

Are you telling me you have never been burned by a library you thought was great then had to spend hrs ripping it out to replace it with something better? I mean true it hasn't happened often but I have had it happen a couple times. By creating a layer between you and the library you are in effect creating an insulating layer to protect yourself from library changes. For a hobby project the number of devs is likely small and you can make this isolation is structured according to the way you think reducing the number of bugs you might code or if your understanding is wrong you have a singular place to fix the problem.


It does happen. I use many libraries on almost every project I take on at work. The well developed ones that have become so ubiquitous I generally have no problems with. The number of libraries I use on any given project can be in the 50-100 range. A lot of the libraries depend on other libraries. Just using Rails as a webserver nets you 20 or so. Modern development uses a lot of libraries. It you're working with something like ruby it's all automated with manifests. The installation process makes the libraries like standard tools.

That being said, I have also met libraries that don't quite meet the needs. For example, I recently used a charting library for visualization. It was difficult to make it pixel perfect for what the designer gave us, and we had a fussy client. Ultimately, though, it was never an option to write the visualization code from scratch. I find in those cases you may need to be willing to give a little flexibility to the requirements yourself. Ultimately that's what the client did when faced with the option of paying for longer development costs.
19 Mar, 2013, Rarva.Riendf wrote in the 23rd comment:
Votes: 0
There are also the license problems from time to time. Though most saner libraries will use something else than GPL anyway.
19 Mar, 2013, Nathan wrote in the 24th comment:
Votes: 0
Chris Bailey said:
I only write things from scratch because I'm ignorant and completely incapable of understanding code written by others.


Tell me about it… I thought I'd look through the CircleMUD code once upon a time. I'll submit that it *might* be good coding in C and that I know very little about C (I know a little bit more about C++), but it's still pretty crazy. Files of constants, collections of functions and all kinds of other craziness. I think Classes/Objects are good, maybe better, at least for some things; like figuring out how stuff works together. When done well, variables and functions are neatly encapsulated within the parts of the program they belong to and manipulate. C/C++ at least has the opportunity to throw that kind of organization to the wind.

I've been writing a mud server (it might be more truthful to strike out the dungeon part for the moment) from scratch largely by myself. In large part it was because I wanted practice coding among other things and it also had occurred to me one day that these games (logic, etc excepted) are largely a data storage and retrieval system.

In retrospect, you could build likely one with just a well constructed relational database and some code to create logic and define when and what to retrieve/display.

Operating systems are so large and difficult to write that it seems safer to leave that domain alone, period, beyond maybe a very simplistic one to get a sense for it. And that's assuming you understand even the hardware level of stuff and some basic coding at a low level.



On the libraries topic:
There are some "libraries" that are implementing it yourself would be easier and less of a nuisance. Others are so complicated that you can barely understand what they do and how they do it much less integrate it into your code.
19 Mar, 2013, Tyche wrote in the 25th comment:
Votes: 0
plamzi said:
Of course, we're all free to go about our hobby in any way we damn' please.

+100
20 Mar, 2013, salindor wrote in the 26th comment:
Votes: 0
Runter said:
It does happen. I use many libraries on almost every project I take on at work. The well developed ones that have become so ubiquitous I generally have no problems with. The number of libraries I use on any given project can be in the 50-100 range. A lot of the libraries depend on other libraries. Just using Rails as a webserver nets you 20 or so. Modern development uses a lot of libraries. It you're working with something like ruby it's all automated with manifests. The installation process makes the libraries like standard tools.

While not what I was originally thinking when I posted my scenario, it definitely got me thinking about my reuse on my mud and my various projects at work and so I will go with what you wrote instead of my original counter-argument. I can honestly say that most my projects my direct dependencies can be counted on a single hand only having worked on one project that had enough dependencies to require use of a library management system (we were using maven). If I had to point to my greatest weakness, it would be code reuse. My natural inclination is code everything–I realize from a professional point of view that isn't the best, but since I am one of the faster programmers around my company the incentive to fix this is muted. Especially since the environment discourages re-use. I would rather not get into the excuse here, but lately because of the rules imposed on my code it makes it really hard to reuse libraries (for example no news, mallocs, deletes, or frees past initialization). This means in order to reuse a library I have to scrub that library to make sure it also follows this rule. If the time it takes me to scrub a library is greater than the time it takes to write the same functionality from 'scratch' then its not worth my time to reuse the library.

So I decided I write out the questions I ask myself when I go to re-use a library (and post them as criticism can be good for the soul)
- What is the license of the library. I actually spend the time to read every license to every software product/library I use. I can't claim to understand it; nor am I going to claim my eyes don't glaze over after about the third word. But I pretty much won't even look at any code licensed under the GPL as I don't want to be tempted. If the library fits my needs perfectly I can accept the LGPL but only if it doesn't make use of templates (which if it does then its the same as the GPL– nice little gotcha)
- Does the library do what I need it to do, or am I going to have to spend a lot of work making it work?
- How does the example code look. When I look at the example code, does it intuitively make sense to me?
- How difficult is it for me to duplicate the functionality of the library?
- Are there any certs posted against the library? Can they be mitigated? How much work will it take to mitigate the risk vs the functionality provided?
- How are the reviews of the library? Are there any? Are there any known issues?
- What is the value of just writing one myself?

Even when I decided to write my own webserver, I actually spent a month (it was off and on, I mean this is a side project after all it probably would have been a couple days if this was work instead) working through these questions. In the end I decided the value of rewriting it was worth the time. I almost used ruby but when I looked at integrating it with c++ I decided against it (especially with the warnings against using c++ threads with ruby).

There are other libraries that I have incorporated. For example openssl. If I was going to seek a job with the NSA or CIA or any other three letter acronym agency then rewriting it might have value (I do have the knowledge as my masters was in multi-party cryptography) but I am not and I only need the library for one connection at the beginning to log the player in. So the cost of rewriting it (especially given its license) was far too high compared to the given payoff. So I chose to link the library (and buy a book to figure out how to use the stupid thing because its documentation and example code is abysmal :p )
20 Mar, 2013, Vigud wrote in the 27th comment:
Votes: 0
I've always wanted to write a mud from scratch, because all mud code-bases I know are limited by short-sighted design decisions or restrictive license or something else or any combination of those… I have a desire to make a new mud server and make it properly from the ground up, simply because I'm not satisfied with what is currently available to me. At some point, I even started looking for a game system I could implement and would be allowed to implement, so that I could concentrate on implementation work only. Sadly, I didn't manage to go past that step.
21 Mar, 2013, salindor wrote in the 28th comment:
Votes: 0
If you are going to write something from scratch.

The first thing you need to decide is what is its value? How much time is a rewrite worth. Is it measured in days, weeks, months (I doubt years, but lets even say years.

Next you need to estimate how long it will take. This is a tricky science especially for a hobbiest. My tact is to break everything down into subtasks and those again until you have tasks you can estimate. If it is something you have no clue on, create a small prototype just so you can get a feel for how long it would take. Once everything is broken down into estimatable subtasks, simply add them up and multiply by 4 (if you finish early great, but finishing late is rough on the moral)

Now compare the two numbers. If your estimated finish time is greater than the worth then you need to adjust something by either removing features or deciding if the project is worth more than your original desire. If you simply can't bring the worth above the estimate, abandon the project as you will never finish.

On the other hand if your estimate is less than the worth, structure the subtasks you split your project up into a plan and execute.
21 Mar, 2013, Telgar wrote in the 29th comment:
Votes: 0
Runter said:
I'll boil my answer down to something small. It's the culture of C. C has long had a culture of people just starting from scratch, and a real aversion to using libraries and code already developed in your project. It comes from an era where people were constantly fearful of malicious code and without any real way to find out if a library is legit or not. Especially predating widespread distribution on the internet of code. Most mudders have picked up the same culture from working with codebases that never use libraries and basically have solved the problems themselves. It's my position that writing stuff from scratch can be fun, and it can be educational, but you don't have to spend all your time reinventing wheels to gain knowledge, or to have fun. You can actually do those things while contributing to existing projects, and develop products that other people will use. You'll find that's pretty fun and educational too.


This is at least one of the reasons I am working from near scratch; the Circle / Diku codebase I was working with was not trustworthy, I found everything from memory leaks to threads with outrageous (non-existant) thread safety, buffer overflows, null pointer and stale pointer crashes within the first 30 minutes of running it. Rather than switch to a modern C codebase like TBAmud, I am running away from the C arena entirely and switching to Javascript.

I actually have found a few really cool and useful Javascript libraries for my project that saved a lot of manual labor like implementing sprintf or pretty printing Javascript and JSON, which isn't a whole lot of fun. About the only thing that makes sense to do in C is link in the zlib library for MCCP support.

It's a large and challenging project, of which I am maybe 30% done, but the design goal warranted the effort.
21 Mar, 2013, Davenge wrote in the 30th comment:
Votes: 0
Chris Bailey said:
I only write things from scratch because I'm ignorant and completely incapable of understanding code written by others.


If this was facebook, I'd like this.
21 Mar, 2013, Nathan wrote in the 31st comment:
Votes: 0
Vigud said:
I've always wanted to write a mud from scratch, because all mud code-bases I know are limited by short-sighted design decisions or restrictive license or something else or any combination of those… I have a desire to make a new mud server and make it properly from the ground up, simply because I'm not satisfied with what is currently available to me. At some point, I even started looking for a game system I could implement and would be allowed to implement, so that I could concentrate on implementation work only. Sadly, I didn't manage to go past that step.


Not to burst your bubble, but people (as in humans) are extremely prone to short-sighted design decisions. It's not as though we can predict all possible future uses of code/software. What's not a restrictive license? After all GPL isn't very restrictive at all, it's just that it's particular restrictions are problematic sometimes and some people don't want to deal with them.

If you have a desire, proceed by all means. Don't suffer under the delusion that yours will be the best ever. What in particular aren't you satisified with? If you can't put a finger on it, go back to the drawing board. After all, there have to be hundreds of existing mud codebases out there.

d20 is probably pretty clean cut for a game system (OGL?), although I really doubt that the restriction on use of spell names (as Product Identity) would hold up uniformly in court (come on people, "cure light wounds" isn't all that inventive or new or anything, just because you can combine some common words doesn't mean you own it).

I went past the speculation phase, but my code is very incomplete (lack of a working combat system for one) and is hampered by MU*-esque influences in some places. For instance, I like the 'where' command, but the more I think about it the less sense it makes in a real MUD context.

Telgar said:
Runter said:
I'll boil my answer down to something small. It's the culture of C. C has long had a culture of people just starting from scratch, and a real aversion to using libraries and code already developed in your project. It comes from an era where people were constantly fearful of malicious code and without any real way to find out if a library is legit or not. Especially predating widespread distribution on the internet of code. Most mudders have picked up the same culture from working with codebases that never use libraries and basically have solved the problems themselves. It's my position that writing stuff from scratch can be fun, and it can be educational, but you don't have to spend all your time reinventing wheels to gain knowledge, or to have fun. You can actually do those things while contributing to existing projects, and develop products that other people will use. You'll find that's pretty fun and educational too.


This is at least one of the reasons I am working from near scratch; the Circle / Diku codebase I was working with was not trustworthy, I found everything from memory leaks to threads with outrageous (non-existant) thread safety, buffer overflows, null pointer and stale pointer crashes within the first 30 minutes of running it. Rather than switch to a modern C codebase like TBAmud, I am running away from the C arena entirely and switching to Javascript.

I actually have found a few really cool and useful Javascript libraries for my project that saved a lot of manual labor like implementing sprintf or pretty printing Javascript and JSON, which isn't a whole lot of fun. About the only thing that makes sense to do in C is link in the zlib library for MCCP support.

It's a large and challenging project, of which I am maybe 30% done, but the design goal warranted the effort.


Why run away from C? I would think that C++/Java would be far better than javascript anyday at least for some tasks. Besides, javascript is interpreteed, isn't it? That means you need a javascript engine plus your code.
21 Mar, 2013, roguewombat wrote in the 32nd comment:
Votes: 0
Davenge said:
Chris Bailey said:
I only write things from scratch because I'm ignorant and completely incapable of understanding code written by others.


If this was facebook, I'd like this.


Every now and then I reach for those little green up / down arrows on the right of a post thinking to upvote it… Ahh, sweet disappointment.
21 Mar, 2013, Rarva.Riendf wrote in the 33rd comment:
Votes: 0
>This is at least one of the reasons I am working from near scratch; the Circle / Diku codebase I was working with was not trustworthy, I found everything from memory leaks to threads with outrageous (non-existant) thread safety, buffer overflows, null pointer and stale pointer crashes within the first 30 minutes of running it. Rather than switch to a modern C codebase like TBAmud, I am running away from the C arena entirely and switching to Javascript.

Were there not recent trustworthy mud codebase not written in C ?
21 Mar, 2013, Telgar wrote in the 34th comment:
Votes: 0
Rarva.Riendf said:
>This is at least one of the reasons I am working from near scratch; the Circle / Diku codebase I was working with was not trustworthy, I found everything from memory leaks to threads with outrageous (non-existant) thread safety, buffer overflows, null pointer and stale pointer crashes within the first 30 minutes of running it. Rather than switch to a modern C codebase like TBAmud, I am running away from the C arena entirely and switching to Javascript.

Were there not recent trustworthy mud codebase not written in C ?


If you know of one with a Diku style feel written in Javascript, I'd love to here about it. I'm not aware of any.
21 Mar, 2013, Telgar wrote in the 35th comment:
Votes: 0
Nathan said:
Why run away from C? I would think that C++/Java would be far better than javascript anyday at least for some tasks. Besides, javascript is interpreteed, isn't it? That means you need a javascript engine plus your code.


Modern Javascript JIT compilers produce similar performance to Java, and I find it faster to develop in Javascript. Performance is not the goal here, flexibility and rapid prototyping is. Things like mob-progs and special procs are easier to integrate, as there is no need for a separate interpreter or to compile them in, they can be written in Javascript and interpreted at runtime and distributed along with zone files instead of hacking the server code.
21 Mar, 2013, plamzi wrote in the 36th comment:
Votes: 0
Telgar said:
Rarva.Riendf said:
>This is at least one of the reasons I am working from near scratch; the Circle / Diku codebase I was working with was not trustworthy, I found everything from memory leaks to threads with outrageous (non-existant) thread safety, buffer overflows, null pointer and stale pointer crashes within the first 30 minutes of running it. Rather than switch to a modern C codebase like TBAmud, I am running away from the C arena entirely and switching to Javascript.

Were there not recent trustworthy mud codebase not written in C ?


If you know of one with a Diku style feel written in Javascript, I'd love to here about it. I'm not aware of any.


I've seen two codebases written in JS, and they both use the callback model. That's probably a good thing, but it takes care to erase any Diku feel (and also means you have to be pretty comfortable with the language to start modifying).

One of the codebase projects was extremely rudimentary, and looked like someone had a passion that burnt itself out in two weeks. The other one, four weeks…

Also, don't think that writing in JS makes you impervious to memory-related bugs. It's true that memory management is a lot easier, but if you don't have a full understanding, you can still get into trouble with a server that is supposed to run for days on end.

There's a lot of hatin' over Diku, but there's a reason why what those guys did many years ago is still the de facto standard. It was far from perfect, but it was a full-fledged, open-source effort that was the result of solid teamwork. And it lives on in tbaMUD, which I have found to be very stable and competently written, though I do not use it myself.

In my book, the only reason to write my own MUD codebase would be to escape the dreaded Diku license.

On the topic, I'd like to revisit Runter's comments:

Runter said:
… It comes from an era where people were constantly fearful of malicious code and without any real way to find out if a library is legit or not. Especially predating widespread distribution on the internet of code. Most mudders have picked up the same culture from working with codebases that never use libraries and basically have solved the problems themselves…


We are now in a position to leverage all kinds of frameworks, libraries, and server apps that we know are trustworthy, well-documented and are not going away tomorrow. Some of them, like SQL / LAMP, are virtually ubiquitous. Some of them, like the iOS and Android SDK's, provide access to a huge market and guarantee exposure. And yet, it seems like many devs in this community are stuck in a previous era. So now I'm left to lament not only the lack of teamwork, but also the lack of (what I see as) common sense in how to frame one's project.
21 Mar, 2013, quixadhal wrote in the 37th comment:
Votes: 0
I love how you guys consistently ignore LpMUD's, as if they never existed. :)
22 Mar, 2013, salindor wrote in the 38th comment:
Votes: 0
plamzi said:
In my book, the only reason to write my own MUD codebase would be to escape the dreaded Diku license.


Actually, even then it may not be necessary. You could take an rpg engine and adopt it to be a mud. Though I don't have any good suggestions onto this one, I only just started looking into it.
22 Mar, 2013, Runter wrote in the 39th comment:
Votes: 0
Nathan said:
Why run away from C? I would think that C++/Java would be far better than javascript anyday at least for some tasks. Besides, javascript is interpreteed, isn't it? That means you need a javascript engine plus your code.


You don't need a javascript engine plus your code. There's plenty of them already developed for you. That's like saying if you use ruby then you need a ruby engine plus your code. If you want to use C do you have to be responsible for developing your C compiler? If I were making a mud in javascript I would use node.js and never think twice about the javascript engine. It uses googles V8 engine and it's one of the finest implementations of any interpreted language.

What tasks you do think C++/Java is better than javascript for? I can count them on a few fingers and none of them are mud related. They're equals on some things, but realistically the reason you'd use C++ or Java is if you need more performance, break out of the javascript sandbox, or writing driver code. These things aren't even remotely needed for mud dev.
22 Mar, 2013, quixadhal wrote in the 40th comment:
Votes: 0
There's also a very good, practical reason for "running away from C", when developing a MUD.

MUD's are text games. A good 95% of their code involves manipulating text. Why, in God's name, would you *CHOOSE* to use a language which lacks a native string type?
20.0/83