Re: Got a License for That?

[Maxi Rose]

Why is it that MUDs have to make money? And why is it money is the only thing that drives innovation? Is money the best thing for driving innovation? Hands down yes. But why does money have to enter into the MU* picture?

If you've ever been to Darker Realms LP or any of the other heavily-modded MUDs out there, you'll see innovation and interest coded without money as the driving force. They didn't need it, and it's greedy to need it.

The original authors of LP, Aber, and other flavours coded their servers so people could have FUN. If they wanted money to be made off of them, they would be making the money, themselves. Why spend hours and hours, years possibly, even, to make something, only so that some lazy moron can make money off of your work by adding in a personally-written "theme" and not adding any real code to speak of? Or adding 165482th guild/clan to the list of already bloated guilds/clans out there.

The problem here in this article also, lies in that the author has conflicting interests. He works for a For-Pay MUD server, and is decrying free MUD servers. Gee. I wonder why that might be?

Even if MUD servers and devteams are poor at documenting any and everything about their source, at least you don't have to pay hard earned cash for a game built around the premise of:

Bob verbs adverbly at Mary.

For the same cost to join a Skotos game, I can play Ultima Online or EverQuest and get FULLY GRAPHICAL games with constantly-changing content, better mobs, more items, more interactive commands, and NO interference from game staff, no obvious favouritism, and THEY don't censor you if you have something less-than-stellar to say about their company or their adminning practices.

I'll do our friend, here, the service he could not be bothered to do, himself, in trying to downplay the competition. Here's links to several flavours of MUD and MUSH source code webpages. I just typed in "MUD source" into Google, and here are some links I got, in the order Google gave them to me:

Desolation of the Dragon MUD - Source (http://www.dotd.com/source.html)
Overview of gnome-mud source package (http://packages.qa.debian.org/g/gnome-mud.html)
About PerlMUD 3.0 (http://www.boutell.com/perlmud/)
SourceForge.net: Project Info - Koala Mud Server (http://sourceforge.net/projects/koalamud/)

But of course, our author, here, no doubt wants to only talk about "famous" codebases. So here are links to "famous" codebases and their source. I found them, again in Google, by typing, "diku source". Here they are in the order Google gave them to me:

The Mud Slide (http://www.themudslide.com/source.html?user_id=&session=)

Wow! That webpage, found on page one of Google, has ALL the major "famous" codebases! So much for not being able to find anything about these codebases very easily.

Shall we talk about the Tiny- flavour of codebases? I can easily dig up the source pages for TinyMUSH 3.x, TinyMUX, TinyMUCK, and PennMUSH. More obscure codebases can be found as well, but I don't dabble in them so haven't looked:

TinyMUSH 3: The Home Page (http://www.godlike.com/tm3/)
MUX 2.2 Main Page (http://svdltd.com/TinyMUX/)
FuzzBall Software (http://www.belfry.com/fuzzball/)
PennMUSH Home Page (http://www.pennmush.org/)

Before anyone decides that MUD codebases are sliding into the ground or are impossible to find or ANYTHING is absolutely TRUE as written by a person with conflicting interests, do your homework. My digging took less than five minutes. It's like listening to movie critics, and how often has a movie critic been right for anything but an OBVIOUS Oscar-nomination movie that you could smell a mile away?

[Sentack]

I may be mistaken but I think actually the author was trying to make diffrent points then the ones you only picked up on. What I got from the article, and I must admit, from my own casual observation, I find to be true, Is the following. Most open source based MUD's have stoped evolveing lately. As a matter of fact, they seem to be quite stagnant universaly.

On top of that, you have lack of documentation, and in a lot of cases, I've seen that as well. Not to mention other odd little things like all but one of the built in mudlib's that come with the source to LDMUD don't actually WORK anylonger. One of them does and while it may be nice that one does, I really wish the other examples where more playable.

The thing is, and this is kind of true with a lot of OSS projects is that a lot of what your expecte to learn, is thru FAQ's, Trial and Error, and the Search Feature of every Forum and Newgroup available to the project. Rarely have I seen good honest basic docs for any of such projects that explain the basics to advance and remain up to date. It doesn't help that good docs are expensive to make and very boring. So few people really put the effort into it. And once a project gets of a specific size, things get forgotten, out of date and basicly ignored till the point that your only choices are just sludgeing it out on your own.

Combine with the fact that typicaly, most MUDS tend to thrive thru replication then inspriation you get a situation where you have a lot of projects that really look alike minus a few minor or major tweaks. But for a for pay company to really be successfull, THEY have to be inspirational to attract and keep customers. So thus, When a pricetag is involved, inspriation is what keeps you alive compared to the other guys.

It doesn't mean free muds can't be the hot beds of inspriation. It just makes it less likely once you take into consideration the greater whole.

Overall, the auther has a point, OSS muds are in a lull when it comes to code and docs. They haven't even touched recent concepts, many just still do things the same old way, many are still much more diverse and enhanced then the new MMOG's are, but that's changeing with time as the big developers are pumping in more time, effort and funds into bigger, better, more creative works.

All in all, OSS MUD's are sliping behind the curve, but do they need to stay above the curve? Maybe not. People still love em, people still play em. Angband hasn't changed much over the years. Today you hae Diablo, a bigger rendition of the game, but that doesn't mean Angband should change to match the times that drasticly. It's still just as fun now, as it is then, and it does what it does well.

Sentack

[Lee]

I think, Maxi Rose, that you are missing the relevant points of the article and inserting some of your own.

One of the main points of the article was that the technology behind free mud codebases is years behind the curve compared to todays commercial engines. And that when the occasional advancement is made it gets 'lost'. Word often never gets out about its existence. Even if the source code is published it never makes into some central distribution for that codebase. This is not in anyway saying 'all free muds suck' or anything equivalent.

Technology/architecture affects a MUD by dictating how easy or hard it is for the game desinger(s) to implement thier ideas. Obviously many free muds are fun and full of good ideas. But I bet you the coders had to work much harder to implement those ideas than they would have using a more advanced engine.

I could bitch all day about how hard it is to write a minesweeper game in C using notepad. Or I could use an IDE specifically made for writing C code to make minesweeper and have a much easier time of it. Either way I get my minesweeper game, but I would be well within my right to say how problematic it is to write C code in notepad.

Relax, take a hot bath, and read the article again with a different perspective.

[Maxi Rose]

I can see what you're saying, Sentack. It makes perfect sense. Maybe I misinterpreted what he said a little.

I still stand by my view that if you want lots of people to PAY for a MU*, you need to provide a LOT more than:

Bob verbs adverbly at Mary.

I've played Castle Marrach. It provides me less features than many, if not most FREE MU*s. As well, most free MU*s don't rely on subjective staff for character advancement. Free MUDs have mobs you can fight to gain money and XP which goes up based on how much effort you put into killing the mobs. You level up regardless of whether staff thinks you're their best friend or not.

Even most MUSHes, which have no coded mobs, allow your fellow players to rank you for quality, handing out XP points when you earn them.

Now to address the main issues I only partially touched on, or may have incorrectly noticed:

MUDs are more static these days simply because yes, when you're not being paid, it's hard to be as motivated. As well, people horde code. They code something cool, they do not share.

I code for the Pueblo MU* client, and any code I make, I offer up freely to help further the Pueblo community. Unfortunately, not everyone feels the same way. A lot of times, games want to seem "cooler" than their competition, and the one way they feel they can do that is by having cooler code, unlike anyone else's. This hording may be innovation, but it's still hording, and that leads to stagnation, despite the cool code. Look at the semi-famous MUSH variant called RhostMUSH (http://rhost.mybis.com/) .

Here's their "license agreement" of sorts, for allowing other people to use the code. See how wonderfully stifling this all is.

http://rhost.mybis.com/availability.html

Especially look at this passage:

3. We would greatly prefer that no one rape our mush for ideas in other servers. And if you do get an idea from our server, please put a credit down that you got it from us. You don't have to ask us permission for ideas, but we would appreciate it and it does show some deal of tact. Please make a generic credit to 'RhostMUSH'.

Apparently, we're not allowed to be inspired by their work unless we duly notate this in our code or credits. As well, inspiration is considered "rape". And the main coder, a guy called Ashen-Shugar, raves on and on about how great his server base is and how others either suck or are full of bugs. If his server is so great, why doesn't he share?

If Ashen-Shugar charged people for access to his games or to the code, would this cause greater innovation? Only for those people with no interest in game creation. Creators are stifled by For-Pay schemes because it prohibits them working with existing code to improve it. Instead, they have to reinvent the wheel just to be able to improve on it, and many people just don't have that kind of patience. This is why we have so few games of that sort out there that succeed, and they're mostly backed by major corporations.

Those with money, or backing to GET money, create the new, innovative games. I have great ideas, so I think, but not the coding experience in C++ to be able to implement them, or connections within EA or Sony to get someone else to make my ideas a reality. As such, my ideas don't happen in C++-based languages. I code rather well in TinyMUSH, however, and with the Pueblo client, and because both give me free access, I can make my "great" ideas a reality in those code bases. Their being free and already well-coded allows me to build upon them and make new things and new ideas. I don't have to start from scratch.

To address Lee, Castle Marrach is a "commercial engine". Please tell me how "advanced" `Bob verbs adverbly at Mary.' is. I seem to not understand the meaning of "advanced". Maybe this is some sort of Invader Zim reference?

[nigel_ht]

Why is it that MUDs have to make money? And why is it money is the only thing that drives innovation? Is money the best thing for driving innovation? Hands down yes. But why does money have to enter into the MU* picture?

Eh, I prefer a license that will allow me to recoup my recurring expenses at a minimum. That's ignoring the time required to actually code the content for a mud.

Which is the hard part IMHO. The engine is the prerequisite but the heart is the content.

You support the author's assertion that mud code bases are stagnating because they aren't cross-pollinating and the "coolest" code is being kept internal to a particular mush rather than making it back to the wider community.

As far as Skotos and cost Marrach isn't the only mud on skotos, there is The Eternal City (which sounds more like your cup of tea). Plus you get M59 and Underlight in the package along with a couple other games outside the RP arena (like turn based strat, etc).

My biggest complaint with the author is I'm waiting for some meat. So far this stuff is pretty fluffy...I want to know the pros and cons of the various code bases. Heck, a table of what language they are written in would be a good start.

I also want to know what core functionality is the difficult part in writing a mud server.

Bob verbs adverbly at Mary is only one portion of the codebase. There has to be more to it than that...but looking at the few code bases I've seen gives me a headache. Both the code and the content creation mechanisms seem to me to be arcane, or more accurately obsolete.

Heck, is there a modern mud codebase written in C++/STL (or Java) using mySql as the persistence layer?

I'm guessing that many of the coders who might have coded a new codebase are working on graphical mud codebases instead. Its a heck of a lot cooler...

Nigel

[angelbob]

A minor correction...

The problem here in this article also, lies in that the author has conflicting interests. He works for a For-Pay MUD server, and is decrying free MUD servers. Gee. I wonder why that might be?

I'm the author. I don't work for Skotos. I get paid nothing for these articles. I'm paid for programming, but that's a different company (NVidia) for unrelated work (graphics drivers).

I have a codebase I wrote, called Phantasmal. It's public domain, and I make no money off it. You can find it on SourceForge. I've written a lot of LPC documentation, which I give away free, and license as public domain.

So actually, no, I don't consider this a conflict of interests. You're welcome to differ, but asserting that I work for Skotos is simply incorrect.

[angelbob]

Why is it that MUDs have to make money? And why is it money is the only thing that drives innovation?

Time, not money, drives innovation. And money buys time.

don't have to pay hard earned cash for a game built around the premise of: 'Bob verbs adverbly at Mary'

That's like saying you should pay hard-earned money for a game like Baldur's Gate which is based around the premise of "move your mouse around a bit and hit the buttons." You're confusing the UI with the game. Unless you mean that nobody should ever pay for a social game since that's only communication with other people, and nobody should pay for that.

The phone company and your ISP would beg to differ on that point, though.

For the same cost to join a Skotos game, I can play Ultima Online or EverQuest and get FULLY GRAPHICAL games with constantly-changing content, better mobs, ...

Griefers, fewer staffers, less continuity... You're welcome to say that EverQuest works better for you, and that's fine. Saying it works better for everybody is just silly.

NO interference from game staff,

You consider this a feature? I'd call it a bug.

no obvious favouritism, and THEY don't censor you if you have something less-than-stellar to say about their company or their adminning practices.

It's possible Skotos does this, but I've never caught them at it.

[angelbob]

To address Lee, Castle Marrach is a "commercial engine". Please tell me how "advanced" `Bob verbs adverbly at Mary.' is. I seem to not understand the meaning of "advanced". Maybe this is some sort of Invader Zim reference?

Heh. By 'advanced', they're referring to several things. You're right, adverbs aren't enough to warrant that by themselves.

Castle Marrach has a software architecture that is essentially zero downtime. That's not to say the servers are perfect, but the software layer makes it possible to keep stuff persistently forever, to a level that's not possible in, say, EverQuest. If you do a web search on "DGD mud" you'll find some sites (mine, for instance) that explain this in more detail.

CM also includes the whole "prox" system, which may not be rocket science but I can't name a free MUD that has anything similar. Also, there are details -- there are a few free MUDs that allow them, such as my own, but they're not at all common.

However, most of what you're paying for in Marrach isn't any of that. It's staffer time and builder time. Since you seem to dislike what they build and resent time staffers spend on you, perhaps you shouldn't subscribe to Skotos' service. People who actively dislike customer service certainly shouldn't be forced to pay for more of it. Go somewhere that they'll ignore you :-)

[angelbob]

My biggest complaint with the author is I'm waiting for some meat. So far this stuff is pretty fluffy...I want to know the pros and cons of the various code bases. Heck, a table of what language they are written in would be a good start.

Unfortunately, a lot of the meat you want would require a lot more total writing than you're going to get in a biweekly article. What I mean is, it takes many pages to dissect this stuff, and even, say, a decent comparison of parsers between three or four MUD codebases is longer than one of these articles.

On the one hand, that means I have material for, like, forever since I can just go analyze particular features of particular codebases. On the other hand, it means you won't get a ten-page summary that tells you everything you want to know about all the codebases.

I also want to know what core functionality is the difficult part in writing a mud server.

Almost none of it. No single part is surpassingly difficult. However, there are many individual parts and they need to be coordinated with one another. The problem isn't the difficulty of the parts, it's the size of the whole.

but looking at the few code bases I've seen gives me a headache. Both the code and the content creation mechanisms seem to me to be arcane, or more accurately obsolete.

"Obsolete" implies that there's something newer and better out there. What are you thinking of?

The code is somewhat arcane, but mostly it's built by too many different people, and too few of them knew what they were doing. Codebases that were built by a smaller team tend to be better about this, but those aren't the big popular ones.

The building mechanisms are *very* arcane, and that's actually where Skotos is doing much, much better than the free MUDs. Their work, though, isn't free, so you don't see it adopted by the free MUDs. Go fig.

The problem is that building over a text/telnet interface is *hard*. It's hard to come up with a good interface, and almost all existing ones suck. However, if you don't build over a text/telnet interface then you have to build your own client and you're suddenly not platform-independent any more. Java takes you partway there. That's what Skotos uses, and what ScryMUD used for its Hegemon client. However, it's not really all there yet, which is why older Linux distribs won't play Skotos games properly (nor run Hegemon, frequently).

Heck, is there a modern mud codebase written in C++/STL (or Java) using mySql as the persistence layer?

Ah, by "obsolete" you mean "not using your favorite platform". STL and C++ aren't cure-alls. In fact, they tend to make things worse if the programmers involved aren't very skilled, and most MUD programmers aren't. I'm a fan of DGD, which replaces both C++ and mySql in your example.

But yes, there are codebases written in C++ and mySql. I have yet to see one that isn't buggy, glitchy and severely incomplete, and I have yet to see one that has been adopted for anything large by anybody but the author.

I'm guessing that many of the coders who might have coded a new codebase are working on graphical mud codebases instead. Its a heck of a lot cooler...

Yeah. Those never get anywhere either, but for slightly different reasons.

[Lee]

Originally posted by nigel_ht
Heck, is there a modern mud codebase written in C++/STL (or Java) using mySql as the persistence layer?

A codebase should judged based on the tools the programmers used to implement it. I could write an awesome codebase in C or an awful one in C++/STL (or Java) using mySql as the persistence layer.

One should decide what features makes a codebase advanced and then pick the tools that best suit the task. It's dangerous to do it the other way around. You could easily end up thinking 'inside the box'.

Personally, I value flexibility and the ability for non-programmers to create the game they want with as little programmer involvement possible. Us coders are slow :).

And now that I have a goal, I can pick the tools that work the best.

Lee

[nigel_ht]

Originally posted by angelbob
My biggest complaint with the author is I'm waiting for some meat. So far this stuff is pretty fluffy...I want to know the pros and cons of the various code bases. Heck, a table of what language they are written in would be a good start.

Unfortunately, a lot of the meat you want would require a lot more total writing than you're going to get in a biweekly article. What I mean is, it takes many pages to dissect this stuff, and even, say, a decent comparison of parsers between three or four MUD codebases is longer than one of these articles.


No, I don't expect 10 pages...at least not at once. I view these articles in terms of a complete series...though generally its because I start them a year in. :)

But you're now on page 3...I'm hoping for more geeky details in the coming pages. Three pages of motherhood is cool but IMHO soon there should be one page that is a summary of the state of muddom...at least from the 10,000 ft level rather than the 30,000 ft level.

Then detailed commentary on specific implementations and features as you mentioned.


I also want to know what core functionality is the difficult part in writing a mud server.

Almost none of it. No single part is surpassingly difficult. However, there are many individual parts and they need to be coordinated with one another. The problem isn't the difficulty of the parts, it's the size of the whole.


About what I expected.


but looking at the few code bases I've seen gives me a headache. Both the code and the content creation mechanisms seem to me to be arcane, or more accurately obsolete.

"Obsolete" implies that there's something newer and better out there. What are you thinking of?


I mean that some of the core concepts were pretty advanced...for the early 80s. Its 20 years later and I get the impression that we're still using the architechtures built back then.


The code is somewhat arcane, but mostly it's built by too many different people, and too few of them knew what they were doing. Codebases that were built by a smaller team tend to be better about this, but those aren't the big popular ones.


After a certain point software gets too creaky to be able to change (I guess kind of like people). Too much coupling between modules, too much dead code everyone is afraid to delete, etc.


However, if you don't build over a text/telnet interface then you have to build your own client and you're suddenly not platform-independent any more. Java takes you partway there. That's what Skotos uses, and what ScryMUD used for its Hegemon client. However, it's not really all there yet, which is why older Linux distribs won't play Skotos games properly (nor run Hegemon, frequently).


Java is probably not the right answer for the builder interface. I was thinking more along the lines of blog programs like movable type. While I'm not a PhP coder, I would think that this would be a way to go...assuming that the backend was something reasonably clean...like a RDBMS.

Were I a game developer for Skotos I dunno how much I care if a game like Hegemon plays poorly or even not at all for folks that are running an old JVM. The performance differences between Java 1.4 and the old 1.1.8 on the old distros far outweighs the penalty of not having my game run on someones old slackware distro on a 386 box.


Heck, is there a modern mud codebase written in C++/STL (or Java) using mySql as the persistence layer?

Ah, by "obsolete" you mean "not using your favorite platform". STL and C++ aren't cure-alls. In fact, they tend to make things worse if the programmers involved aren't very skilled, and most MUD programmers aren't. I'm a fan of DGD, which replaces both C++ and mySql in your example.


Not "my favorite platform" but languages that support modern architectures without a lot of workarounds.

Of course modern languages are not cure-alls but they do support modern development paradigms at the code level better than C does. Having done OO C, its a PITA.

And there are tons of books on Java/C++ development as well as for MySQL. How many for DGD? I dunno if its in the old Andrew Busey book...or if that thing is still even in print.

At the content creation level, it should be all transparent anyway.


But yes, there are codebases written in C++ and mySql. I have yet to see one that isn't buggy, glitchy and severely incomplete, and I have yet to see one that has been adopted for anything large by anybody but the author.


Most open source ends up this way. The huge success stories like linux, apache, etc are surrounded by a sea of opensource projects that consist of 3 guys and a page on SourceForge.

These likely have not had the chance to gain critical mass because they are written by programmers for programmers and haven't put in clean interfaces for content creation by non-programmers.

Some features, like guild support, etc will need to be done by programmers that understand code. But for the most part the heavy lifting in MUDs appear to me to be the content creators that bring a MUD to life.

Besides, the original codebases were buggy, glitchy and severely incomplete when they were first written. The counter argument is today they are bloated, outdated and hard to change.

You can't decry that these codebases are slow to change without also acknowledging that old codebases are intrinsicly hard to change if for no other reason of their age and the entropy caused by too many hacks on the original framework.


I'm guessing that many of the coders who might have coded a new codebase are working on graphical mud codebases instead. Its a heck of a lot cooler...

Yeah. Those never get anywhere either, but for slightly different reasons. [/B]

Well, I suspect that the original authors of the current codebases would likely have started one of those projects rather than joined in maintaining creaky old codebases.

And I doubt they'd not choosen the architectures you see today. Code interpreters were kinda cool/state of the art in the 80s...folks wanted to write one just to learn how. Today, I think that folks want to write something else just to learn how.

That sure isn't the case today.

Nigel

[nigel_ht]

You know what I'm looking for? I dug out my old Secrets of the MUD Wizards book by Andrew Busey and in the back is an appendix that lists the available servers circa 1995.

I'd like to see one for 2004.

Here's what it says about DGD

"Written by Felix Croes. A reimplementation from scratch of the LPMUD server. It is disk based, and thus uses less memory. Its also smaller and lacks many of the features of the other LPMUD servers, though it is capable of simulating most of those features in LPC. Many DGDs are capable of simulating a LP, but there are several MUDs that now use DGD to simulate a MOO variant. The name stands for Dworkin's Generic Driver. Stable. Has been ported to Atari ST and Commodore Amiga."

Now granted, there isn't a publisher handing you cash for such a list but hey, I'll buy you a beer. :)

Nigel

[angelbob]

Originally posted by Maxi Rose
I'll do our friend, here, the service he could not be bothered to do, himself, in trying to downplay the competition.

Actually, I didn't say no codebases could be found, I said that there were a number of major ones that couldn't. For instance, my prime example was PernMUSH, which wasn't on your list and you downplayed by default as "you don't dabble in it so you didn't try to find it."

I didn't say that, say, CircleMUD couldn't be found. In fact, I specifically mentioned that *they* even had a decent web page. Anyway, let me hit your actual links that you mentioned one by one.

Desolation of the Dragon MUD - Source (http://www.dotd.com/source.html)

This is a minor variant on SMAUG with a couple of things tacked on. SMAUG is also easy to find. So are fifty other bastardized versions of SMAUG, none of which add anything real. There are probably decent ones buried in the mess, but I couldn't tell you which.

Overview of gnome-mud source package (http://packages.qa.debian.org/g/gnome-mud.html)

Did you look at this, or just post the link? There's not really anything here, other than "maybe some day".

About PerlMUD 3.0 (http://www.boutell.com/perlmud/)

Ditto. Check the source. Nobody sane would actually run this MUD, though it does a couple of cute things as far as using Perl for features.

It is, like the above, more a fun thought exercise than, y'know, a server you'd look for specifically.

But you're right -- Google dutifully returns it.

SourceForge.net: Project Info - Koala Mud Server (http://sourceforge.net/projects/koalamud/)

Again, did you check these guys out, or just post the link? Note the entire documentation section is "under construction"? And that the whole MUD is alpha? And that they haven't updated since November 2002?

But of course, our author, here, no doubt wants to only talk about "famous" codebases. So here are links to "famous" codebases and their source. I found them, again in Google, by typing, "diku source". Here they are in the order Google gave them to me:

The Mud Slide (http://www.themudslide.com/source.html?user_id=&session=)

Wow! That webpage, found on page one of Google, has ALL the major "famous" codebases! So much for not being able to find anything about these codebases very easily.


Actually, it contains a couple of Diku and a couple of LPC. Specifically, for Diku it contains Circle, Merc and GodWars (which isn't really Diku, but anyway). It didn't contain ROM, SMAUG or any of the other common Diku variants.

For LPC, it contained an old link to MudOS, and even older link to MudOS, an even-older-yet version of LPMUD, one Lima and one Merentha. It contained nothing about CDLib, LDMUD, DGD, DiscWorld, various Nightmare-descendants...

So I'd say within just Diku- and LPC-descended MUDs, my point about there being no good single site summarizing the codebases (I think that's from a previous article) is absolutely correct, and you've just proven it.

Since that page contained no MUSHes, MUCKs, MOOs, etc, you've proven it even further in that direction. Thanks.

Shall we talk about the Tiny- flavour of codebases? I can easily dig up the source pages for TinyMUSH 3.x, TinyMUX, TinyMUCK, and PennMUSH. More obscure codebases can be found as well, but I don't dabble in them so haven't looked:

"Don't dabble in them so haven't looked." Good to know.

I don't know the MUSH codebases as well, so I won't go through a rebuttal like the one above. Perhaps you're right, and only the one specific codebase I was looking for was unavabilable and unmentioned, and unlike the entire rest of the MUD community, this part is clearly documented and easily available. I'll remember that next time I'm trying to find documentation on MUSH scripting languages.

Before anyone decides that MUD codebases are sliding into the ground or are impossible to find or ANYTHING is absolutely TRUE as written by a person with conflicting interests, do your homework.

What she said. But please, do more of it than she did.

My digging took less than five minutes.

Yes. Do more than five minutes of digging.

[angelbob]

Originally posted by nigel_ht
I mean that some of the core concepts were pretty advanced...for the early 80s. Its 20 years later and I get the impression that we're still using the architechtures built back then.

Sort of. Bear in mind that, for instance, nobody has come up with a better shortest path algorithm than Dijkstra for most cases, and that Euclid is still a standard source for Geometry. Some stuff just doesn't change much in 20 years.

You're right that few MUDs use heavily multithreaded and semaphore'd servers, but I'd argue that that's because such monstrosities are really awful to maintain. Most of the 'new' architectures I've seen put forward since, oh, maybe '85 are just not worth the effort for large-scale projects. If there's anything specific you're longing to see, somebody's probably done it in a MUD and it's probably gotten nowhere, but I'd be curious what.

Java is probably not the right answer for the builder interface. I was thinking more along the lines of blog programs like movable type. While I'm not a PhP coder, I would think that this would be a way to go...assuming that the backend was something reasonably clean...like a RDBMS.

The problem with a web interface is that you can either do it as plain HTML/Javascript, which makes for *really* ugly interfaces, or use Java, which you've just said (and I agree) isn't the answer. Server-side scripting languages like PHP have to turn into HTML (and/or Javascript and/or ActiveX and/or whatever) eventually, no matter how cool they are. They just don't make it to the end user.

Were I a game developer for Skotos I dunno how much I care if a game like Hegemon plays poorly or even not at all for folks that are running an old JVM.

I wasn't referring to the game Hegemon. There's a builder client called Hegemon for ScryMUD that automates a lot of the grunt work in the builder commands.

Not "my favorite platform" but languages that support modern architectures without a lot of workarounds.

Are you talking about exceptions here, or what? What do you mean by "modern architectures"? C++ doesn't exactly have the cleanest support for exceptions either, and some of its OO support is awful, and always has been.

And there are tons of books on Java/C++ development as well as for MySQL. How many for DGD?

Not a one that I didn't write or rewrite, so you're correct here. However, books or not, I'm still not convinced that C++ is good for a large multiperson project. Yes, your C++ code may be good, but the word "abusable" is relevant when you may have tens or hundreds of collaborators over the years (think MUD, ROM, Smaug, Diku, etc).

Most open source ends up this way. The huge success stories like linux, apache, etc are surrounded by a sea of opensource projects that consist of 3 guys and a page on SourceForge.

Sure. And you're right, that's not proof that it doesn't work. However, if you ask "why not use those", I still get to say "because there aren't yet any real success stories like that."

These likely have not had the chance to gain critical mass because they are written by programmers for programmers and haven't put in clean interfaces for content creation by non-programmers.

How is this different from MUDs in other languages and on other platforms?

You can't decry that these codebases are slow to change without also acknowledging that old codebases are intrinsicly hard to change if for no other reason of their age and the entropy caused by too many hacks on the original framework.

It's true. When we see a new codebase done from scratch that *isn't*, I'll consider changing my tune.

Well, I suspect that the original authors of the current codebases would likely have started one of those projects rather than joined in maintaining creaky old codebases.

Sadly, yes. One more reason we're not seeing more progress.

And I doubt they'd not choosen the architectures you see today. Code interpreters were kinda cool/state of the art in the 80s...folks wanted to write one just to learn how. Today, I think that folks want to write something else just to learn how.

Not sure what you mean by this.

[nigel_ht]

Originally posted by angelbob
You're right that few MUDs use heavily multithreaded and semaphore'd servers, but I'd argue that that's because such monstrosities are really awful to maintain. Most of the 'new' architectures I've seen put forward since, oh, maybe '85 are just not worth the effort for large-scale projects. If there's anything specific you're longing to see, somebody's probably done it in a MUD and it's probably gotten nowhere, but I'd be curious what.


Eh, your classic N-tier architecture as far as architecture goes. I'd guess the web based muds will follow the typical enterprise web architectures.

If the netcode isn't multi-threaded I'd be moderately surprised as that seems to be a common text book implementation though I suppose that you could just loop through your sockets.

But I include other things I kind of lump into architectures that aren't "architecture" per se but rather the framework for design. For example, its hard to implement many of the design patterns without using an OO language.

Which architectures do you feel aren't worth the effort? I would guess that most are derived from large projects in other problem domains.

I'm not certain that MUDs cross over into the "large scale projects" arena anyway.



The problem with a web interface is that you can either do it as plain HTML/Javascript, which makes for *really* ugly interfaces, or use Java, which you've just said (and I agree) isn't the answer. Server-side scripting languages like PHP have to turn into HTML (and/or Javascript and/or ActiveX and/or whatever) eventually, no matter how cool they are. They just don't make it to the end user.


I think some of the blog interfaces are reasonably well laid out and professional looking. You need to apply text descriptions to objects, set values and link objects for the most common content creation activities.

How much uglier than the text interfaces can you get? @whatsits foo=bar isn't ugly?

Heck, I've helped write web based Network Element management systems for telecom. These things describe the state of fibers pairs and matrix switches as well as setting up complex protection schemes to handle failover cases.

You can make them pretty. You also can make them moderately efficient although a scripting language is more useful for bulk setting of parameters.


I wasn't referring to the game Hegemon. There's a builder client called Hegemon for ScryMUD that automates a lot of the grunt work in the builder commands.


Either way. Telling builders to get something a little more recent isn't a huge heartache IMHO. You can run the latest distros on something as wimpy as a PII 300Mhz. Its slow but it works as long as you have the memory. That kind of rig should run you all of $50 on EBay.


Are you talking about exceptions here, or what? What do you mean by "modern architectures"? C++ doesn't exactly have the cleanest support for exceptions either, and some of its OO support is awful, and always has been.


Better OO support than C. Exceptions do suck in C++...in as much as they are slow. But with smart pointers and container classes C++ is a much more friendly coding environment than C is in terms of not shooting yourself in the foot as well as coming with some useful constructs out of the box. You also tend to get away from things like pointer arithmetic and other efficient but often buggy methods of doing things. I guess those aren't in LPC either but I dunno.

Plus C++ and Java tool support is much better than C.

It's not 1995 where memory, disk or processor power is a major issue.

Looking back on some of the concerns/requirements is humorous. "Runs best with a 1 MB ram disk! Requires 640K!"

Hokay. What do I do with the rest of my Gig of RAM?


Not a one that I didn't write or rewrite, so you're correct here. However, books or not, I'm still not convinced that C++ is good for a large multiperson project. Yes, your C++ code may be good, but the word "abusable" is relevant when you may have tens or hundreds of collaborators over the years (think MUD, ROM, Smaug, Diku, etc).


Well there are a lot of C afficionados, especially in kernel code development but I think that C++ has sufficient history that folks that are not convinced that C++ is good for "large multiperson projects" is ignoring a good decade worth of projects in the software industry as a whole and even within just open source projects...if I recall correctly Mozilla is at least partially written in C++. Parts of Apache are (tho' the core is C).


Sure. And you're right, that's not proof that it doesn't work. However, if you ask "why not use those", I still get to say "because there aren't yet any real success stories like that."


And in 1995 DGD was still considered a newcomer lacking features present in other LPC codebases. /shrug


How is this different from MUDs in other languages and on other platforms?


I dunno that it is different. Though I suppose in 1995 it would have been hard to predict which of the rewrites and new codebases would still be around in 2004.


It's true. When we see a new codebase done from scratch that *isn't*, I'll consider changing my tune.


That isn't what? Creaky with age? By definition, new codebases are just that...new. Lacking features but with a cleaner structure and easier to extend and maintain if for no other reasons than fewer hands have touched them.

Tack on 10 years and I'm sure they'll be messy too.


Sadly, yes. One more reason we're not seeing more progress.


Er, I dunno why you'd think this is a negative. Were it not for Felix Croes deciding to recode LPC from scratch you wouldn't have DGD. I dunno why...licence, code sucked, he was bored but whatever, all codebases started somewhere by someone who wasn't happy with the status quo.

I suspect that hot coders will almost always prefer to choose to build new over maintaining old. That's not to say they wont use libraries, reuse concepts or even older code but I think most prefer to control their own destiny.

Where would we be if Linus decided that FreeBSD would do what he wanted and joined some BSD team?


Not sure what you mean by this.

I mean in the late 80s and early 90s writing your own language (LPC, MUF, U, whatever they called the language in MOO) was "cool" among CS folks. Language writers were "uber" and the industry young enough that there were a plethora of new languages in development and contention.

Saying you wrote a new language from scratch was even a plus on your resume...even if folks rarely did that in the real world.

Today, I'd guess that the first thought of a hot spit coder in college wouldn't be "gee, I could write my own language and parser and that would be the core of my codebase! WOOT!".

Assuming that MUDs are even on their radar (which I think unlikely), I'd have to guess some sort of XML whoosits sitting atop Apache and Xerces or maybe Java and JAXB connecting to postgres or something.

Content builders would export their work in XML to be sucked in by the engine and stored in the DB.

Well, anyways, just my opinion. I'm certainly no expert on MUDs and I eagerly await your following articles.

And um, yeah, I think that if I had a lot of time on my hands I could write a killer new MUD codebase. :D If there is a coder out there that doesn't think that...well...

Nigel

[Maxi Rose]

Originally posted by angelbob
Actually, I didn't say no codebases could be found, I said that there were a number of major ones that couldn't. For instance, my prime example was PernMUSH, which wasn't on your list and you downplayed by default as "you don't dabble in it so you didn't try to find it."

This comment I'll deal with, later.

As well, let me concede right this moment, that I know next to nothing about hack'n'slash MUDs except from the viewpoint of a player, and having peered over the shoulder of some wizards while they were coding for Darker Realms LP MUD back when it was hosted at worf.tamu.edu.

In short, I admit to not enough knowledge about hack'n'slash to hold up a decent end to this argument about availability, quality of codebases or even of information provided, etc. My only argument I feel I can speak on is the "quality versus price" issue with regard to paying for a text-based MU* of any server codebase type.

As such, I'll snip most of the stuff I don't' feel qualified to adequately rebutt.


So I'd say within just Diku- and LPC-descended MUDs, my point about there being no good single site summarizing the codebases (I think that's from a previous article) is absolutely correct, and you've just proven it.

Since that page contained no MUSHes, MUCKs, MOOs, etc, you've proven it even further in that direction. Thanks.

That page didn't include Tiny-types of MU*s because the two codebase styles are nearly completely different. Or did you not realize that?

"Don't dabble in them so haven't looked." Good to know.

Ok. I'll admit to being snarky with my first post. Especially so I can feel justified in pointing out your snarkiness.

I don't know the MUSH codebases as well, so I won't go through a rebuttal like the one above.

This, you make painfully obvious. When I speak of lesser variants, I'm speaking of codebases that have not been considered part of the Tiny-community since mid-90's. I've been in the Tiny community since 1992, having started on FurryMUCK. This was about a month or few after its creation since the dissolution of Islandia MUCK.

Let me go ahead and correct you on something which was really a very ridiculous thing to try to hold up as a way to prove I'm ill-informed on the topic.

PernMUSH as a codebase, which you so valiantly herald, hasn't been an official codebase since the devteam who coded it originally as a single GAME changed its name to avoid copyright infringement and legal hassles from the author of the book series it was created for, Dragonriders of Pern. It's hard to find direct references to the date because this is not considered "vital information", but the changeover happened pre-1995, and likely around 1991-1993 or so. That info is gleaned from some old postings to mailing lists, again, gathered from Google.

For those lesser variants which I say I don't dabble in, I'm speaking of the zombie-freak codebase called TinyTIM, written by what many people consider to be a somewhat eccentric and rabid individual, RhostMUSH, which as mentioned is so jealously guarded by its fanatical devteam lead by the infamous Ashen-Sugar, TinyMUSE, which I've not heard any ongoing information about in over FIVE YEARS, MOO, which is still a going concern, but of a different architecture which is not one that personally interests me, and any breakoffs of older codebases which for whatever reason, people wish to keep going, such as PennMUSH, which mutated from PernMUSH to Penn, then to TinyMUX, which was later merged by BOTH devteams into TinyMUSH 3.x.

We come from two different text-based game worlds of thought. I do what are called "social" games, or "socials". You come from what I've known as "hack'n'slash" games. Neither is better than the other. Both are lots of fun and very interesting. As such, I don't think you and I can really discuss this topic fully and accurately, since we're not so versed in each others' fields. Let me just end this by adding a few things to some more of your replies.


Perhaps you're right, and only the one specific codebase I was looking for was unavabilable and unmentioned, and unlike the entire rest of the MUD community, this part is clearly documented and easily available. I'll remember that next time I'm trying to find documentation on MUSH scripting languages.

If you want to learn about Tiny- codebases, those social MU*s like TinyMUSH, TinyMUCK, etc., I'd love to talk with you about them. I don't know everything there is to know, but I know a lot, and can find resources for those things I don't know.


What she said. But please, do more of it than she did.

Yes. Do more than five minutes of digging.

CORRECTION: It's a good idea to actually know the subject you're trying to debate so you don't look like such a fool when debating it. I can still hold up my own with regard to the argument about quality versus pay, but I really didn't know enough about hack'n'slash to present this very well. My apologies. So yes, when digging for info, no matter how much time you spend, bother to actually get to know the topic at hand, at least better than I did. ;)

[angelbob]

Originally posted by nigel_ht
Eh, your classic N-tier architecture as far as architecture goes. I'd guess the web based muds will follow the typical enterprise web architectures.

Hm. The problem with putting MUDs onto an N-tier architecture is that you have to separate out the various tiers. Some MUDs use significant modularity, but that modularity tends to cut vertically more than horizontally. Have a look at Phantasmal (my own MUDlib) for an example.

If the netcode isn't multi-threaded I'd be moderately surprised as that seems to be a common text book implementation though I suppose that you could just loop through your sockets.

Generally, MUDs tend to just use select() on sockets and connections, which may or may not just loop internally.

Multithreaded is great if you're trying to do a number of similar tasks in large-scale parallel with very little interaction between them. However, that's almost never the way a MUD works since connections (players) interact constantly with each other. In that case, multithreaded requires doing a lot of synchronizing with all your resources since multiple threads can be playing with them at once. Since single-threaded is also more efficient and your timer is required to advance in lockstep anyway (usually -- otherwise one player/connection could get ahead of the others on time, and that's not good).

So multithreaded operation is generally much more effort for a MUD than it's worth.

But I include other things I kind of lump into architectures that aren't "architecture" per se but rather the framework for design. For example, its hard to implement many of the design patterns without using an OO language.

Very true. I'm surprised more MUDs aren't OO. Then again, most OO fans start on monstrosities like C++ (single-dispatch OO, and still uses pointers) or Java (single-inheritance single-dispatch with horrendous performance), which would make their lives significantly more difficult.

Which architectures do you feel aren't worth the effort? I would guess that most are derived from large projects in other problem domains.

I'm not certain that MUDs cross over into the "large scale projects" arena anyway.

For architectures I don't think are worth the effort, I'm thinking of template libraries and of heavily multithreaded architectures. If you have a look at the ACE framework, it's a fine example of the worst parts of each. I've even worked on *that* vile thing professionally.

Some MUDs definitely qualify as "large-scale projects". Once you've implemented a builder system, significant scripting architecture, a web server, a nontrivial parser and intermud chat, you're up to a pretty decent size codebase. There are 70,000+-line MUD servers available free, if memory serves, and some larger ones that are used by various proprietary folks (think Medievia, which is over 100,000 lines and has hundreds of builders and wizards working on it).

I think some of the blog interfaces are reasonably well laid out and professional looking. You need to apply text descriptions to objects, set values and link objects for the most common content creation activities.

I'd argue that most of those interfaces can't be extended to do serious building. Most of what makes them pretty (uncluttered, easy to figure out quickly, correct things emphasized) have to be sacrificed to do a decent MUD building interface.

Have you read enough of the Skotos stuff to have seen the Tree of Woe and its graphical interface? While it's certainly possible to do something cleaner than that, it illustrates some of the problems nicely. A good MUD building system will allow you to do tens or hundreds of things to each object, and it's very hard to keep that many options in a clean interface.

How much uglier than the text interfaces can you get? @whatsits foo=bar isn't ugly?

Nope, standard MUSH builder systems are ugly too. You can do better than that with a good text-based interface and you can do worse than that with a bad web-based interface.

Don't ask too loudly how much uglier you can get than a text-based interface. Somebody out there will answer you.

The thing about a text-based interface is that most of your options are invisible. Since you often have literally thousands of options, that's important. A graphical interface can do the same trick with a hierarchical menu, but that gets *really* nasty to use *really* fast.

Again, check out the Skotos stuff with the Tree of Woe. It illustrates the problem nicely.

Either way. Telling builders to get something a little more recent isn't a huge heartache IMHO.

The problem isn't affording the hardware. I'm *still* trying to get something running on my current home machine that will run Java to Skotos' satisfaction. My old RedHat 7.3 stuff is too outdated, and my current Fedora Core 1 stuff contains no useful Java plugin, and can't seem to use any of the ones I've ever downloaded. Telling your builders to get something more recent is often telling them to do the very difficult or the impossible.

I'm sure all of this would make more sense to me if I did Java stuff all the time. However, the whole point of this is to prevent people from having to learn a new programming language to use your stuff, so making them learn to use a full set of Java tools seems to eliminate any actual benefit of the system.

Better OO support than C. Exceptions do suck in C++...in as much as they are slow. But with smart pointers and container classes C++ is a much more friendly coding environment than C is in terms of not shooting yourself in the foot as well as coming with some useful constructs out of the box.

Exceptions also suck in C++ because they're buggy, unpredictable and tend to cause weird border cases where they subtly do the wrong thing. Do you want do debug somebody else's bad exception code?

C++ and accompanying things like the STL are, um, interesting. I've never seen them documented in a useful way, for instance. For an even better example, find me decent documentation on cout... I've never seen such a thing.

However, ignoring documentation and learning how to use them, they're still ugly on most platforms. For an example, try using them on, oh, Visual C++ 6 (I haven't tried the more recent ones and seen if they have the same problems). I can say roughly the same thing about templates generally -- they're ugly, they're incompatible and compiler support is, at best, iffy.

You also tend to get away from things like pointer arithmetic and other efficient but often buggy methods of doing things. I guess those aren't in LPC either but I dunno.

You're correct. LPC doesn't have pointers, just references. So it's more like Java that way (but faster).

Plus C++ and Java tool support is much better than C.

Maybe that's true on Windows, but it's certainly blatantly false on Unix. I should find the posts of the last person that tried to say this to me and link to them...

Essentially *no* C++ tools on Unix fail to support C. However, there are *many* C tools on Unix that work poorly on C++ or not at all.

And Java tool support may be better than C, but you'll have to sell me on that one, because I've never used a Java development setup that was better than chewing off a limb.

Well there are a lot of C afficionados, especially in kernel code development but I think that C++ has sufficient history that folks that are not convinced that C++ is good for "large multiperson projects" is ignoring a good decade worth of projects in the software industry as a whole and even within just open source projects...

I'm not ignoring them. Rather, I've participated in some of them. I've worked for Palm and NVidia and worked in C, and I've worked for MetaCreations and NOW Solutions and worked in C++. And I have no reservations whatsoever about saying that C is a better language than C++ for large groups working on large projects.

We began to use C++ for one module of one part of a large project at a company I worked for. It caused constant, nasty linking problems. The rest of us protested bitterly that coordinating a C++ module with the C stuff would cause problems, and the C++ guys denied it. Turns out it did. Who knew? (Well, we did).

In fact, that happened twice at companies I worked for. C++ was added, and immediately started causing ugly problems.

At Be, who I didn't work for, they used C++ for the system libraries. You know what the first immediate consequence was? There was only one C++ compiler you could use, because no two C++ compilers will compatibly link to each other.

And in 1995 DGD was still considered a newcomer lacking features present in other LPC codebases. /shrug

I assume you're talking about the book excerpt you mentioned. What he said about that (that some features aren't in the server and have to be written in LPC) is still true now. Like, it hasn't changed in any way since then, except perhaps that there are *more* features like that.

[angelbob]

That isn't what? Creaky with age?

Slow/difficult to change.

Lacking features but with a cleaner structure and easier to extend and maintain if for no other reasons than fewer hands have touched them.

Tack on 10 years and I'm sure they'll be messy too.

In theory, it should be possible to come up with a cleaner structure so that a mature (i.e. has most modern features) codebase would still be reasonable to alter. A bit of serious refactoring could probably do that for most of the existing codebases, in fact, which is roughly what Circle did for Diku.

However, I have yet to see any codebase get large without becoming a bit hard to change. Some codebases seem to have less of this problem than others, though.

Er, I dunno why you'd think this is a negative. Were it not for Felix Croes deciding to recode LPC from scratch you wouldn't have DGD. I dunno why...licence, code sucked, he was bored but whatever, all codebases started somewhere by someone who wasn't happy with the status quo.

The problem is that when good people start from scratch on new projects, old projects don't get better. That's fine if you never need a mature project for any reason. Sadly, we do.

I suspect that hot coders will almost always prefer to choose to build new over maintaining old. That's not to say they wont use libraries, reuse concepts or even older code but I think most prefer to control their own destiny.

And since so few of them ever produce anything, most of that effort goes down the crapper. DGD has had at least six or seven groups that I know of that have made a viable, reasonable start on a new MUD library and then gone away without ever releasing any code. In other words, to my certain knowledge, there would be over twice as many viable MUDlibs out there if those people had bothered to release code rather than start anew.

However, if they had instead started from more mature existing stuff, it would be even better -- we'd have about the same number of codebases, but they'd *work decently*. Imagine that for a moment.

Where would we be if Linus decided that FreeBSD would do what he wanted and joined some BSD team?

The possessors of a better flavor of BSD than currently exists?

[nigel_ht]

Originally posted by angelbob
Hm. The problem with putting MUDs onto an N-tier architecture is that you have to separate out the various tiers.


Well, the presentation layer is telnet/mud client text. Then you have business logic (combat code etc) and then a persistence layer. Like say...an RDBMS...


Very true. I'm surprised more MUDs aren't OO. Then again, most OO fans start on monstrosities like C++ (single-dispatch OO, and still uses pointers) or Java (single-inheritance single-dispatch with horrendous performance), which would make their lives significantly more difficult.


There's a nice smart pointer template in the boost library. Its being added to the library spec hopefully.

The Java 1.4 JVM was about as fast as code compiled by g++ for certain benchmarks. Granted that gnu doesn't generate the worlds fastest code its still not shabby.

Besides, what would you choose instead? Objective C? Smalltalk? Yah, those stormed the marketplace.


For architectures I don't think are worth the effort, I'm thinking of template libraries and of heavily multithreaded architectures. If you have a look at the ACE framework, it's a fine example of the worst parts of each.


I'm no fan of ACE either.


Some MUDs definitely qualify as "large-scale projects". Once you've implemented a builder system, significant scripting architecture, a web server, a nontrivial parser and intermud chat, you're up to a pretty decent size codebase. There are 70,000+-line MUD servers available free, if memory serves, and some larger ones that are used by various proprietary folks (think Medievia, which is over 100,000 lines and has hundreds of builders and wizards working on it).


That's large...but I'm guessing atypical. How big is the DGD team?


I'd argue that most of those interfaces can't be extended to do serious building. Most of what makes them pretty (uncluttered, easy to figure out quickly, correct things emphasized) have to be sacrificed to do a decent MUD building interface.

Have you read enough of the Skotos stuff to have seen the Tree of Woe and its graphical interface? While it's certainly possible to do something cleaner than that, it illustrates some of the problems nicely. A good MUD building system will allow you to do tens or hundreds of things to each object, and it's very hard to keep that many options in a clean interface.


One wonders if hundreds of actions is really required for each object but yes, having that many attributes to modify is difficult to put in a graphical interface.


The thing about a text-based interface is that most of your options are invisible. Since you often have literally thousands of options, that's important. A graphical interface can do the same trick with a hierarchical menu, but that gets *really* nasty to use *really* fast.


Again, thousands of options sounds kinda excessive to have content creators keep track of. Yes, it would get nasty in a graphical interface but I'm guessing that the most common options aren't in the "thousands" category.


Again, check out the Skotos stuff with the Tree of Woe. It illustrates the problem nicely.


Okay, I'll check that out when I get a chance.


The problem isn't affording the hardware. I'm *still* trying to get something running on my current home machine that will run Java to Skotos' satisfaction. My old RedHat 7.3 stuff is too outdated, and my current Fedora Core 1 stuff contains no useful Java plugin, and can't seem to use any of the ones I've ever downloaded. Telling your builders to get something more recent is often telling them to do the very difficult or the impossible.


Red Hat 7.3 is on the supported systems list for J2SE 1.4.2. It shouldn't be much more difficult than downloading and installing the latest JVM.


I'm sure all of this would make more sense to me if I did Java stuff all the time. However, the whole point of this is to prevent people from having to learn a new programming language to use your stuff, so making them learn to use a full set of Java tools seems to eliminate any actual benefit of the system.


Um, downloading a JVM off the sun website is hardly on par with "learning a full set of java tools". And I don't see the difference with learning LPC and learning Java.

In any case, we're talking about a graphical IDE for mud content development. Where does learning a new programming language come into this? The benefit is that you hide all that programming mumbo jumbo from folks...and that includes that @foo bar or LPC.


Exceptions also suck in C++ because they're buggy, unpredictable and tend to cause weird border cases where they subtly do the wrong thing. Do you want do debug somebody else's bad exception code?


Um...okay. I use exceptions sparingly because they are slow and I'm old fashioned. Some folks use them like they're the best thing since sliced bread. But I see it more of a style thing than exceptions are broken.

Which is what you are claiming here.


C++ and accompanying things like the STL are, um, interesting. I've never seen them documented in a useful way, for instance. For an even better example, find me decent documentation on cout... I've never seen such a thing.


STL is reasonably well documented in Josuttis book The C++ Standard Library. Meyers has a nice little Effective STL book that while not quite up to par with this [i]Effective C++[i] series isn't bad as long as you aren't expecting a tutorial.

Googling for iostream on the net results in a fairly decent writeup on the MSDN website that goes into the various ios options and how streams work. There are tons more but I honestly didn't bother looking at them.

My Lippman book has a decent intro to streams, incore formatting and such. Sufficient that you can replicate most if not all printf features...which you can still use if so inclined.


However, ignoring documentation and learning how to use them, they're still ugly on most platforms. For an example, try using them on, oh, Visual C++ 6 (I haven't tried the more recent ones and seen if they have the same problems). I can say roughly the same thing about templates generally -- they're ugly, they're incompatible and compiler support is, at best, iffy.


Um...I might have agreed...in 1991. Or 1995. But 2004 template support is usable for any compiler that fully supports the ansi standard for the language. STL has worked since VC++ 5.0 according to the old sgi stl 2.0 website (circa 1997).

Please. Its been 15 freaking years...the technology is finally mature and usable. My ancient Lippman book from 1991 talks about templates and exceptions.


You're correct. LPC doesn't have pointers, just references. So it's more like Java that way (but faster).


Maybe. Maybe not. Java is pretty fast these days. Not like say...in 1995.


Maybe that's true on Windows, but it's certainly blatantly false on Unix. I should find the posts of the last person that tried to say this to me and link to them...

Essentially *no* C++ tools on Unix fail to support C. However, there are *many* C tools on Unix that work poorly on C++ or not at all.

And Java tool support may be better than C, but you'll have to sell me on that one, because I've never used a Java development setup that was better than chewing off a limb.


I think you'll find it difficult to find a C/C++ tool that reliably maps your UML objects to their C implementation. Typically any of the OO support tools don't do well with C.

Netbeans is pretty decent for Java. C++ and Java tend to have better XML support though libxml2 from Gnome isn't bad for C. Still though, not quite the same as JAXB.


I'm not ignoring them. Rather, I've participated in some of them. I've worked for Palm and NVidia and worked in C, and I've worked for MetaCreations and NOW Solutions and worked in C++. And I have no reservations whatsoever about saying that C is a better language than C++ for large groups working on large projects.

...

In fact, that happened twice at companies I worked for. C++ was added, and immediately started causing ugly problems.


And twice is such a substantive statistical sample size. I too have ancedotal stories about project successes and failures for C, C++, Java, Pascal and FORTRAN. I also know that these technologies evolve over time and that earlier problems get resolved over the decade or so since they've been accepted for use, much less from the time they were initially developed and overhyped.


At Be, who I didn't work for, they used C++ for the system libraries. You know what the first immediate consequence was? There was only one C++ compiler you could use, because no two C++ compilers will compatibly link to each other.


Typically a name mangling issue.


What he said about that (that some features aren't in the server and have to be written in LPC) is still true now. Like, it hasn't changed in any way since then, except perhaps that there are *more* features like that.

The point is that you like DGD. Its unlikely that any of the changes the original dev team wanted to do would have been done by the LPMUD dev teams even had they joined it.

So saying that all these new codebases are of little value isn't any more substantive than saying DGD was of little value when it was first released because it didn't have the same feature set (and likely more buggy) than the LPMUD codebase.

Nigel

[angelbob]

Originally posted by nigel_ht
The Java 1.4 JVM was about as fast as code compiled by g++ for certain benchmarks. Granted that gnu doesn't generate the worlds fastest code its still not shabby.

Ah, I didn't so much mean the speed. If I wanted speed, I wouldn't use Java. I was referring to how difficult the tools were to use.

Besides, what would you choose instead? Objective C? Smalltalk? Yah, those stormed the marketplace.

For OO? Probably Dylan if I had to. Or build-it-myself in C. You're right, no good OO language ever did well in the marketplace. It's why I don't use OO for much except as a hack on top of C.

Why reject C++ when it adds OO (sorta) and is C backwards-compatible? Because it adds more problems than it solves, especially when some other idiot starts adding code to my project.


I'm no fan of ACE either.

Sure, but I've never seen a template library doing the "lots of multithreading" thing that didn't share its problems. Can you name one?


That's large...but I'm guessing atypical. How big is the DGD team?

The DGD team is just Felix. However, not all of that is in DGD for roughly the same reason that Word isn't a part of Visual C++. DGD is just a language interpreter.

The other stuff I mentioned is more properly part of Skotos, or perhaps MudOS + TMI-2. Those teams are larger, more like five to ten active members at a given time, with significantly more minor contributors.

One wonders if hundreds of actions is really required for each object but yes, having that many attributes to modify is difficult to put in a graphical interface.

Depends. Do you want short, long and detailed descriptions for every object? Do you want the ability to have an object be a weapon, edible, potable or poisonous? Do you want it to be wearable? Should it be expected to wear clothes, and it be noteworthy if it doesn't? There's many, many more little questions of that type. Like, hundreds easily. The question is which of those things your game supports. You can choose fifteen or twenty arbitrarily (as most Diku-derivative flavors do), but that's not very scalable.

Red Hat 7.3 is on the supported systems list for J2SE 1.4.2. It shouldn't be much more difficult than downloading and installing the latest JVM.

And yet that didn't allow me to run Skotos games using it. Weird, huh? Nor did either of a couple of other competing JVMs. I'll take your word for it that it's just that simple, in which case I or my computer are braindead.

It didn't work when I tried it with the previous computer, either.

Um, downloading a JVM off the sun website is hardly on par with "learning a full set of java tools". And I don't see the difference with learning LPC and learning Java.

If downloading it worked, no. It's possible that the last three Linux distribs I've used are all much worse than average. And that it's actually easy. And that it actually installed fine, and the error I get is unrelated to that (though the error comes from Java, so presumably Java is running and just doesn't work).

You're correct, though, that that's not as bad as learning the language. Only *debugging* the problems would require learning the language.

And learning LPC isn't actually necessary to use most of the Skotos stuff, oddly enough. Again, read their articles.

Um...okay. I use exceptions sparingly because they are slow and I'm old fashioned. Some folks use them like they're the best thing since sliced bread. But I see it more of a style thing than exceptions are broken.

Which is what you are claiming here.

The problem is that there are a lot of cases like constructors (does the memory get allocated? How do you recover if the fields aren't there any more?) and destructors (same questions, but with "freed" replacing "allocated") and other weird flow-of-control issues. It's hard to get those right, and harder to debug if they're wrong.

STL is reasonably well documented in Josuttis book The C++ Standard Library. Meyers has a nice little Effective STL book that while not quite up to par with this [i]Effective C++[i] series isn't bad as long as you aren't expecting a tutorial.

Googling for iostream on the net results in a fairly decent writeup on the MSDN website that goes into the various ios options and how streams work. There are tons more but I honestly didn't bother looking at them.

Nor do I. I just rant for a few minutes that it's impossible to figure out for given functionality what the friggen' operator is, then go back to printf. Printf has a perfectly good man page, which explains it concisely and in a way that's easy to locate.

Such is progress, I guess. It doesn't like documenting its code any more than its architects do.

(template stuff)Um...I might have agreed...in 1991. Or 1995. But 2004 template support is usable for any compiler that fully supports the ansi standard for the language. STL has worked since VC++ 5.0 according to the old sgi stl 2.0 website (circa 1997).

Then, speaking as somebody who has used it in VC++6.0, that website is wrong. Or, more specifically, they didn't work, they "work". So other than bad symbol name mangling (like, even the compiler, sticking with just one version, couldn't correctly reverse it and give the names in question) and several ugly mis-implementations, it mostly worked.

We dropped it pretty quickly at my workplace. 'Cause, y'know, it didn't work.

Though admittedly we were in a situation where we had limited RAM, which is the *other* good reason not to touch templates, or C++ generally. We kept C++, sadly, but one can't have everything.

Please. Its been 15 freaking years...the technology is finally mature and usable. My ancient Lippman book from 1991 talks about templates and exceptions.

When it had been ten friggen' years, g++ still didn't do template instantiation in any reasonable way and VC++ couldn't figure out the names from the linker symbols, plus your ancient Lippman book from 1991 still talked about them. What's your point? Ten years didn't make it mature and usable, and fifteen years has made it geriatric, but still not usable.


Maybe. Maybe not. Java is pretty fast these days. Not like say...in 1995.

Dunno. Maybe there are fast Java programs out there. I'm used to a Java implementation doing roughly the same things as telnet taking at least 15 Megs. That's fine if all you want is telnet, but the memory hogging continues. The speed is proportionally bad.

But perhaps you're thinking of JIT rather than JVMs. I've never seen a JVM work very well. Then again, I've never seen JIT work very well, but Java fans tell me that it does. So far, only my firsthand experience with Java has been unrelentingly awful.

I think you'll find it difficult to find a C/C++ tool that reliably maps your UML objects to their C implementation. Typically any of the OO support tools don't do well with C.

Other than UML stuff, what kind of "OO support tools" are you thinking of? I've actually only used Together as far as UML tools go. I'm told there's something worth the trouble out there, but Together definitely isn't it.

And twice is such a substantive statistical sample size.

Well, I'm giving samples. So far, your sample size this conversation is zero.

Your reasoning seems to be "well, a lot of versions have come out, and it's in really old textbooks." By that logic, PHIGS (never heard of it? You and the rest of the world, buddy) should be friggen' awsome.

It's not, but it should be.

Typically a name mangling issue.

Not entirely, but close enough. Even so, that doesn't alter the fact that it doesn't work, it just gives a lofty-sounding name for it.

It's not just a name-mangling issue because most stuff for finding functions at runtime (think vtables) are stored differently per-compiler. While ARM has recently promised it'll have a C++ ABI (Application Binary Interface) on its platform Real Soon Now, the same has been promised for those same fifteen years you think made templates work well.

The point is that you like DGD. Its unlikely that any of the changes the original dev team wanted to do would have been done by the LPMUD dev teams even had they joined it.

So saying that all these new codebases are of little value isn't any more substantive than saying DGD was of little value when it was first released because it didn't have the same feature set (and likely more buggy) than the LPMUD codebase.

I'm a little confused. If that's the point, then what is all this other stuff you've been talking about? You're correct, though, that I like DGD.

You're claiming that people will only create new features in the absence of old features. I'm a little confused by that, too. When you mention things like Java, NetBeans, C++, boost and so on, you're aware that the people who use them didn't write them again from scratch, right?

People *do* join new projects and add features. In the specific case of DGD, Felix didn't, but I assume that's so he could sell DGD commercial licenses. That wouldn't have been allowed under the LPMUD license, and I believe it's how he now makes his living.

[nigel_ht]

Originally posted by angelbob
Ah, I didn't so much mean the speed. If I wanted speed, I wouldn't use Java. I was referring to how difficult the tools were to use.


Its all what you're used to I guess. While I code just ducky in emacs (and I suppose some folks think THATs too advanced) I do like IDEs that can do code completion and other little things that IDEs do these days.

On the other hand, using a modern Java IDE like netbeans to build GUIs beats the snert out of hand coding Motif or even using older tools like UIMX.


The other stuff I mentioned is more properly part of Skotos, or perhaps MudOS + TMI-2. Those teams are larger, more like five to ten active members at a given time, with significantly more minor contributors.


That along the size I expect (5-10 folks). Its different than your other example of large teams.


And yet that didn't allow me to run Skotos games using it. Weird, huh? Nor did either of a couple of other competing JVMs. I'll take your word for it that it's just that simple, in which case I or my computer are braindead.

It didn't work when I tried it with the previous computer, either.


Not having access to the Skotos builder I have no idea what the issues are but the implication that Java is somehow impossible to deploy and use because it doesn't work in your particular environment is nonsensical.


If downloading it worked, no. It's possible that the last three Linux distribs I've used are all much worse than average. And that it's actually easy. And that it actually installed fine, and the error I get is unrelated to that (though the error comes from Java, so presumably Java is running and just doesn't work).


All I can say is that there are RH7.x machines in my office with some reasonably up to date JVMs loaded. It worked on my older SuSE distro with no undue heartache. Its not like we're jumping through hoops here to get this stuff to work.

There are plenty of reasons not to go with Java. Lets not pick silly ones like it doesn't run on RH 7.3. You don't like Java, fine. That's cool by me having been on enough projects that thought Java was the answer to everything only to end in death march mode I can understand why some folks dislike it.

But like CORBA, OO and other overhyped technologies, a decade later it does more or less do what that original 1995 vintage hype said it would do.

In 1985 there were lots of FORTRAN programmers poo pooing C as well.


And learning LPC isn't actually necessary to use most of the Skotos stuff, oddly enough. Again, read their articles.


And learning Java somehow is necessary?


The problem is that there are a lot of cases like constructors (does the memory get allocated? How do you recover if the fields aren't there any more?) and destructors (same questions, but with "freed" replacing "allocated") and other weird flow-of-control issues. It's hard to get those right, and harder to debug if they're wrong.


You typically aren't supposed to put anything in the constructors that can fail like that. Not saying I don't do that...I do all the time. But its not great practice and I do kinda know that if an exception is thrown in a constructor I did something bad.

It also depends what got thrown...I know I'm lazy and catch (...) more than I should and that hides problems but generally you don't throw in a destructor or constructor.

But anyway, having C dump core is better how?


Nor do I. I just rant for a few minutes that it's impossible to figure out for given functionality what the friggen' operator is, then go back to printf.

Such is progress, I guess. It doesn't like documenting its code any more than its architects do.


Somehow an assertion that iostream is undocumented seems extreme. And while I forget those oddball ios formatting commands too I find that either I don't need them or I just use printf.

On the other hand I wouldn't give up streams just because printf is better at formatting.


Then, speaking as somebody who has used it in VC++6.0, that website is wrong.
...
Though admittedly we were in a situation where we had limited RAM, which is the *other* good reason not to touch templates, or C++ generally. We kept C++, sadly, but one can't have everything.


Sure. Because you tried it a few years ago and it didn't work well then it'll never work well. And because its not overly well suited for some applications (like embedded work) it has no application anywhere.

I'll conceed that STL was buggy in 1997 and might only have worked in certain circumstances in VC++ 5.x. However STL worked on vxWorks using the old g++ WindRiver uses.


When it had been ten friggen' years, g++ still didn't do template instantiation in any reasonable way ... What's your point? Ten years didn't make it mature and usable, and fifteen years has made it geriatric, but still not usable.


The point is that it does work today and given 10 years both templates and exceptions have matured greatly. Its not arcane anymore. You have a reasonable expectation that on current compilers your code is portable (excluding specific system calls) across platforms and that the STL is the Standard Template Library part of the language spec.


Dunno. Maybe there are fast Java programs out there. I'm used to a Java implementation doing roughly the same things as telnet taking at least 15 Megs. That's fine if all you want is telnet, but the memory hogging continues. The speed is proportionally bad.


Yeah, if you stick with the old JVMs. While the new JVMs aren't lightning they are acceptable.


But perhaps you're thinking of JIT rather than JVMs. I've never seen a JVM work very well. Then again, I've never seen JIT work very well, but Java fans tell me that it does. So far, only my firsthand experience with Java has been unrelentingly awful.


JIT compilers has been part of Java since 1.2. Which is a bit old. At first they worked so-so but have gotten a lot better. A somewhat dated article compares the speeds here (http://www.idiom.com/~zilla/Computer/javaCbenchmark.html).


Other than UML stuff, what kind of "OO support tools" are you thinking of? I've actually only used Together as far as UML tools go. I'm told there's something worth the trouble out there, but Together definitely isn't it.


Together is slow. Folks that love it tend to be java coders as it has more Java support than C++ support. Rational Rose is a lot more C++ (and Ada) oriented.


Well, I'm giving samples. So far, your sample size this conversation is zero.


Well I COULD prattle on about the various FORTRAN/C/C++/Java projects (some successful, some not) I've worked on from telecom to space systems to web apps to defense but what real purpose would it serve?

Even with a fairly prolific career I dunno that I've been on more than a double handful major projects which makes any of my examples no more or less ancedotal than yours.

On the other hand, the industry as a whole has a lot of C++/Java activity going on. What? These people are all stupid or something?


Your reasoning seems to be "well, a lot of versions have come out, and it's in really old textbooks." By that logic, PHIGS (never heard of it? You and the rest of the world, buddy) should be friggen' awsome.


No, my reasoning is that just because a product or technology was overhyped when it started does not mean it will always suck. That you had bad experiences with them 10 years ago doesn't mean much today.


I'm a little confused. If that's the point, then what is all this other stuff you've been talking about? You're correct, though, that I like DGD.


The point is that hot coders like working with cutting edge stuff. Whatever that is today, the current codebases don't have them.

So they are more likely to roll their own codebases if they bother at all.


You're claiming that people will only create new features in the absence of old features. I'm a little confused by that, too. When you mention things like Java, NetBeans, C++, boost and so on, you're aware that the people who use them didn't write them again from scratch, right?


Sorry, but Java, Netbeans and C++ were written from scratch because the creators didn't like the status quo (well maybe not netbeans). These aren't continuations of older projects but rengineered new projects that built on some concepts from before but also moved largely in their own directions.

And I suspect that the next generation of creators will write new languages and tools because they believe that C++, Java, etc suck. And they'll be right. They do. They just suck less than most other languages and tools...at least as far as the general market has decided.


People *do* join new projects and add features. In the specific case of DGD, Felix didn't, but I assume that's so he could sell DGD commercial licenses. That wouldn't have been allowed under the LPMUD license, and I believe it's how he now makes his living.

Great. But given your other posts you have written your own codebase right? Why didn't you join the Melville team rather than build Phantasmal? Why didn't you update 2.4.5?

Whatever those reasons are, I'm sure that they are good ones (no sarcasm). Just like all those hot dog new coders out there writing their own codebases...often failing but you never know what might stick.

And no, not for a single minute do I believe that had Linus joined some BSD team that we'd see anything close to Linux or even significant improvement to the BSDs.

Nigel

[angelbob]

Originally posted by nigel_ht
But like CORBA, OO and other overhyped technologies, a decade later it does more or less do what that original 1995 vintage hype said it would do.

Heh. More or less. CORBA is still a massive pain to use, and OO still hasn't produced, say, a factor of two reduction in programming time for large projects (with the exception of some GUI stuff, which it actually does very well).

In 1985 there were lots of FORTRAN programmers poo pooing C as well.

And their matrix and large mathematical operations are still about a factor of two faster than similarly-optimized C code. So yes, they did, and some still do, and with good reason.

You typically aren't supposed to put anything in the constructors that can fail like that. Not saying I don't do that...I do all the time. But its not great practice and I do kinda know that if an exception is thrown in a constructor I did something bad.

It's difficult not to. Most people do. It's very difficult to keep people from doing it. Therefore, I refuse to use a language that makes such nasty mistakes possible.

But anyway, having C dump core is better how?

'Cause GDB debugs it correctly, recognizes all the function names and states them clearly, as opposed to C++ debuggers, which tend to give names of destructors and exception handlers obscurely, if at all. In other words, in C they're all functions, and there's the "one name per function" rule, which helps debugging immensely. Nifty, huh?

Somehow an assertion that iostream is undocumented seems extreme. And while I forget those oddball ios formatting commands too I find that either I don't need them or I just use printf.

If you have to punt and use a previous (only partially compatible) tool in stressful cases because you can't find the formatting codes, that's a sign that the documentation for those formatting codes is lacking.

Since I have to use printf() in the cases that matter, I don't bother to use the simple tool in the simple cases. Why bother to learn another one when I'll just have to dump it as soon as the going gets tough?

Sure. Because you tried it a few years ago and it didn't work well then it'll never work well. And because its not overly well suited for some applications (like embedded work) it has no application anywhere.

I'll conceed that STL was buggy in 1997 and might only have worked in certain circumstances in VC++ 5.x. However STL worked on vxWorks using the old g++ WindRiver uses.

It's possible that all this stuff is now standard and mature. They said that in 1994 (they lied). They said it in 1997 (they lied). They said it in 2000 (they lied, at least for g++ and VC++, the most common two C++ compilers). It's possible that this time it all really works. I gave up on them about four years ago, because I know that such things failed miserably in border cases (as you say, embedded stuff, including Palm, WinCE and Win95).

The point is that it does work today and given 10 years both templates and exceptions have matured greatly. Its not arcane anymore.

When I say "arcane" I'm referring to the error behavior and the syntax. Those things haven't changed. They're still painful.

Together is slow. Folks that love it tend to be java coders as it has more Java support than C++ support. Rational Rose is a lot more C++ (and Ada) oriented.

Yes, Together is slow. It also requires write access to all your code, and uses that access, so it's basically incompatible with source control systems. Plus it modifies your source files even to add random comments, and often even when you don't (not sure why, it never made sense to me).

Maybe Rational Rose fixes all those problems, too. It was too expensive for me to give it a try, especially given the utterly miserable performance of the previous UML tools we tried (this was at a small company, so a tool of dubious utility wasn't worth several thousands dollars for a practice attempt).

On the other hand, the industry as a whole has a lot of C++/Java activity going on. What? These people are all stupid or something?

Well, that was the case when they were mostly using Visual Basic.

No, my reasoning is that just because a product or technology was overhyped when it started does not mean it will always suck. That you had bad experiences with them 10 years ago doesn't mean much today.

True. I gave up after bad experiences ten, seven, five and three years ago, but it's possible that everything has come up roses since then.

I have my doubts.

Sorry, but Java, Netbeans and C++ were written from scratch because the creators didn't like the status quo (well maybe not netbeans). These aren't continuations of older projects but rengineered new projects that built on some concepts from before but also moved largely in their own directions.

Actually, C++ was written as a preprocessor on top of C at AT&T labs. It was called CFront. Java's written from scratch only to the extent that it doesn't look like C++. I haven't used Netbeans, so I'll give you the benefit of the doubt on that one.

Great. But given your other posts you have written your own codebase right? Why didn't you join the Melville team rather than build Phantasmal? Why didn't you update 2.4.5?

Because I built on top of the Kernel Library instead of those. So I didn't start from scratch. I used DGD, and also an extra layer in between. I didn't start from Melville because there was too little there, and I didn't start from 2.4.5 because the Kernel Lib gave better security.

In other words, I didn't start from those because you forgot a choice, and that's the one I started from.

And no, not for a single minute do I believe that had Linus joined some BSD team that we'd see anything close to Linux or even significant improvement to the BSDs.

So you figure that Bruce Perens joining the Apache project was basically a mistake? And that people building things like ReiserFS for Linux should be doing something wholly other?

Linus actually started on Minix, and at least his early email exchanges (have you read the Torvalds/Tanenbaum email?) made it sound a lot like he'd have started from Minix if the license were better and (consequently)the distribution easier. That's why Minix filesystems are still supported by the Linux kernel. Linux actually started as a second-boot OS on a machine that already had Minix.

[nigel_ht]

Originally posted by angelbob
CORBA is still a massive pain to use, and OO still hasn't produced, say, a factor of two reduction in programming time for large projects.


No technology cuts a factor of two off programming time by itself. Otherwise it would be the proverbial silver bullet. But if it saves you 10%...its still improvement.

Besides, as an industry we're building more complex systems in less time with more functionality and generally with smaller teams. It isn't because we're still using APL, FORTRAN, PL1, SNOBOL or ASM on IBM mainframes using Chief Programmer Teams, Structured Analysis and Structred Design and flowcharts.


And their matrix and large mathematical operations are still about a factor of two faster than similarly-optimized C code. So yes, they did, and some still do, and with good reason.


If it were still twice as fast then there would be more new FORTRAN projects. Somehow the demand for FORTRAN coders has massively decreased...so as a general purpose language FORTRAN has fallen by the wayside and those naysayers are retired, marginalized or C/C++/Java programmers.


It's difficult not to. Most people do. It's very difficult to keep people from doing it. Therefore, I refuse to use a language that makes such nasty mistakes possible.


But its okay to use a language (C) that allows you to do pointer arithmetic? Nice high horse buddy. Doesn't seem a very rational one but whatever.


'Cause GDB debugs it correctly, recognizes all the function names and states them clearly, as opposed to C++ debuggers, which tend to give names of destructors and exception handlers obscurely, if at all. In other words, in C they're all functions, and there's the "one name per function" rule, which helps debugging immensely. Nifty, huh?


Yeah, that's nifty...of course if I choose not to catch exceptions I get the same thing...if you dislike C++ because of options that can go wrong you should dislike C for the same reason. C is the picture you see in the dictionary for "programming language with lots of power with which you can shoot yourself in the foot with".


If you have to punt and use a previous (only partially compatible) tool in stressful cases because you can't find the formatting codes, that's a sign that the documentation for those formatting codes is lacking.


Or laziness. The docs are there, they can even be readily accessible in the right IDE or just a google search.


It's possible that all this stuff is now standard and mature. They said that in 1994 (they lied). They said it in 1997 (they lied). They said it in 2000 (they lied, at least for g++ and VC++, the most common two C++ compilers). It's possible that this time it all really works. I gave up on them about four years ago, because I know that such things failed miserably in border cases (as you say, embedded stuff, including Palm, WinCE and Win95).


Yeah, STL doesn't work and will never work. You just keep believing that.

There are three kinds of coders out there. One kind lives on the bleeding edge and well, does a lot of bleeding. These guys are great...because otherwise I'd be doing more of the bleeding. Better them than me. Unless of course one of these guys is the project lead. In which case it IS me doing the bleeding.

Another kind has to be dragged kicking and screaming away from safe old comfortable technology from 20 years ago. These guys are the crochety old fogeys that are pains in everyone's asses.

The rest of us understand that neither the hype of new technology or the dire predictions of doom are true and reality is somewhere in between.

We do understand that just because they aren't the silver bullets promised us or because they are buggy and a pain when young that they wont always remain so and never be useful. Typically this is about 10 years for mainstream adoption of new technologies.

Is Java or C++ the end all of languages? Heck no. So what? They are more efficient to develop in than languages we had before in many problem domains. The COMMON problem domains.

For the rest we have specialized tools and languages.


Yes, Together is slow. It also requires write access to all your code, and uses that access, so it's basically incompatible with source control systems. Plus it modifies your source files even to add random comments, and often even when you don't (not sure why, it never made sense to me).


Yeah, Together is slow. Yeah it inserts comments (all code generation tools do, Together actually less than Rose) in your source code.

Incompatible with source control systems? Only if you want it to be. Just like not being able to get Java running on Linux.


Well, that was the case when they were mostly using Visual Basic.


There's nothing wrong with VB as a GUI development language. Its not my first choice because I prefer to be cross platform but if you're strictly windows its not a horrible decision. I haven't checked out the .net version of studio but VB always seemed to have better 3rd party GUI components than VC++. Built in components for that matter.


Actually, C++ was written as a preprocessor on top of C at AT&T labs. It was called CFront. Java's written from scratch only to the extent that it doesn't look like C++. I haven't used Netbeans, so I'll give you the benefit of the doubt on that one.


Yes, early C++ "compilers" did preprocess to C code but the langauge wasn't developed because C was the end all of language development. In essense its a new codebase despite similarities and backwards compatibility with C. At least when the compilers became actual compilers.

What are you saying? There's nothing new under the sun?


Because I built on top of the Kernel Library instead of those. So I didn't start from scratch. I used DGD, and also an extra layer in between. I didn't start from Melville because there was too little there, and I didn't start from 2.4.5 because the Kernel Lib gave better security.

In other words, I didn't start from those because you forgot a choice, and that's the one I started from.


And new codebases developed from mySql, PhP, Apache and other third party products are built on top of tools too. So what?

Did you join a team as you suggest in your articles? No, you started your own. All good reasons why (which I don't think you've mentioned) but if Mellville was so primitive you could have added a great deal to it right?


So you figure that Bruce Perens joining the Apache project was basically a mistake? And that people building things like ReiserFS for Linux should be doing something wholly other?


ReiserFS is a project that was built because the devs didn't believe the older filesystems had the features to move forward with. Apache was created because NCSA development pretty much died when Rob McCool left NCSA.

Folks at Bruce's level of reputation can join major projects and expect to have some say in the direction of the project. Few others can.

So...here we are, talking about MUD codebases, which you as the expert decry as not very forward looking or inventive. But wait, you also want to stipulate that its also bad to just run off and do your own thing.

Ignoring the fact that the most common way that new (open) projects come into being is because some folks decide the old stuff sucks and roll their own.

Well tough because you can't have it both ways. Either live with chaos or stagnate. Old teams don't want to change, there's too much inertia and time invested in the status quo. There's the psychodrama and personalities in every long standing dev team.

There's usually the crochety old guy on the team that says OO sucks, Java sucks, STL sucks, C++ sucks, the web sucks, everything but the stuff he likes sucks that the rest of the team has to appease.

So the new guys with the new ideas don't have the pull to make anything happen without forking the codebase or just starting over.

This is clearly not a difficult concept and someone with your years in the industry should know this.


Linus actually started on Minix, and at least his early email exchanges (have you read the Torvalds/Tanenbaum email?) made it sound a lot like he'd have started from Minix if the license were better and (consequently)the distribution easier. That's why Minix filesystems are still supported by the Linux kernel. Linux actually started as a second-boot OS on a machine that already had Minix.

Sure. And it would have been a tragedy if he had been able to use the Minix codebase rather than start his own. IMHO the reason that Linux is successful and the free BSDs less so is Linus as a driving factor. With an existing codebase with an existing team he would not have had the influence (read as control) that he did with the Linux kernel.

This industry is all about innovation and change. Change is always messy and filled with pitfalls because that's the way humans do things...no matter what SEI tells you.

I think we'll just have to agree to disagree on this subject.

Nigel

[angelbob]

Originally posted by nigel_ht
No technology cuts a factor of two off programming time by itself.

For a lot of cases, scripting does (I'm thinking Perl here, and I'm told Python is equally useful in many cases). For matrix programming, Fortran often does. In certain cases things like garbage collection can make that difference, though I can't give you a very specific example of that.

If it were still twice as fast then there would be more new FORTRAN projects. Somehow the demand for FORTRAN coders has massively decreased...so as a general purpose language FORTRAN has fallen by the wayside and those naysayers are retired, marginalized or C/C++/Java programmers.

Actually, they're just working in the corners of the industry that still care about speed. By and large they're scientific or mathematical programmers working on Crays or clustered computers.

See if you can find some information about pointer aliasing in C some time, and what that does to the run time of things like simple array multiplication code. You can beat that by coding all your matrix routines in assembly, but I've never actually seen that done -- it's a pain, and matrix code is often quite large, and the problem is pervasive throughout it.

But its okay to use a language (C) that allows you to do pointer arithmetic? Nice high horse buddy. Doesn't seem a very rational one but whatever.

So basically, you're saying it's far more rational to go for a language with exceptions *and* pointer arithmetic than just one with pointer arithmetic? So once a language has a feature that can cause pernicious problems, you should add many more features like that? That would explain a lot about C++ if Bjarne Stroustrup feels the same way.

Yeah, that's nifty...of course if I choose not to catch exceptions I get the same thing...if you dislike C++ because of options that can go wrong you should dislike C for the same reason.

Yes and no. C++ has a lot more of them. Since many of those problems are subtle interactions of features and C has fewer abusable features, it's easier to vet C code for correctness. I've known a number of people in my time with a good solid knowledge of all C's features and how they interact, even if most programmers still don't. I never met somebody with that grasp of C++, and I've talked significantly to former members of the C++ ANSI subcommittee.

Or laziness. The docs are there, they can even be readily accessible in the right IDE or just a google search.

I've never seen an IDE make that attempt. You ever try to Google for "C++ iostream right-justified formatting"? Or "C++ format codes"? "C++ formatting codes" gives something marginally more useful if you find the student's tutorial. What *would* you call that if you wanted to Google for it? For that matter, what would you call it if you wanted to look for it in a man page? The answer, of course, is "setiosflags(ios::left)", but for those of us without your natural instinct for this, it's tough to find. Only the word "left" denotes the actual functionality there, and it turns out "left" isn't a very useful search term.

Printf would have that problem too if it didn't have a good single overview man page. I've seen overview *chapters* for iostream, and you're right: only laziness keeps me from reading an entire chapter every time I want to find a formatting code for cout. Another word for that kind of laziness, to my mind, is "efficiency" -- instead I'll use an older, better-tested tool which is reasonably documentable.

Yeah, STL doesn't work and will never work. You just keep believing that.

Speaking as an embedded programmer: thank you, I will.

Yeah, Together is slow. Yeah it inserts comments (all code generation tools do, Together actually less than Rose) in your source code.

Incompatible with source control systems? Only if you want it to be. Just like not being able to get Java running on Linux.

True. You could just check out big swaths of the codebase every time you want to comment (as we did, briefly, with Together). You know how much that makes people kick and scream when they're trying to verify there are no problems with a build, right? And when they're checking the new sync from the source-control system to make sure nobody did anything stupid and there are great big blocks of randomly-changed files for no good reason?

Incompatible with source code control systems? Well, technically no. Incompatible with responsible use of source control? Mostly.

Yes, early C++ "compilers" did preprocess to C code but the langauge wasn't developed because C was the end all of language development. (...)

What are you saying? There's nothing new under the sun?

You were saying that people shouldn't start with old projects or no 'real' innovation would get done. I argued in my article that new MUD coders should start with existing codebases because otherwise they tend to fail without ever producing something useful. You gave C++ as a counterexample -- start anew from nothing, look, here's the excellent result (ignoring its quality for a moment). I said: no, he *did* start from an existing project. C++ was a preprocessor on top of C.

And new codebases developed from mySql, PhP, Apache and other third party products are built on top of tools too. So what?

Same point as above, basically.

Did you join a team as you suggest in your articles? No, you started your own. All good reasons why (which I don't think you've mentioned) but if Mellville was so primitive you could have added a great deal to it right?

Actually, I didn't suggest joining a team. I suggested starting with somebody else's code. I *did* start with somebody else's code: I built on top of the Kernel Library. Melville was primitive, so I chose something less-primitive instead. I didn't do both because that would be redundant effort. I chose the best code for my efforts, and built on top of it.

We on the same page now?

So...here we are, talking about MUD codebases, which you as the expert decry as not very forward looking or inventive. But wait, you also want to stipulate that its also bad to just run off and do your own thing.

Yup. Almost as though it's generally an order of magnitude less effort to modify an existing codebase, even a creaky old codebase, than to rebuild the whole thing from scratch, which few people ever manage to do.

Ignoring the fact that the most common way that new (open) projects come into being is because some folks decide the old stuff sucks and roll their own.

But those projects fail utterly most of the time. People modifying an existing project still fail, but they fail completely less often. My goal isn't to see vast new innovation overnight: won't happen. My goal is to see more of those flash-in-the-pan developers actually producing something that gets passed to the next flash-in-the-pan developer. Currently the vast majority of all MUD development sinks beneath the waves and nobody else ever sees it or gets a chance to use it. You seem to feel that's a good thing.

Old teams don't want to change, there's too much inertia and time invested in the status quo. There's the psychodrama and personalities in every long standing dev team.

And yet if their code is open source, you can still grab a copy and start modifying it. Neat, no? Even if, as you say, every team that exists for long is guaranteed to suck and any project that has existed for longer than fifteen minutes is too archaic to be worth spitting on, their code may still be worth grabbing. If not, then by the time you have anything that works, you suck (for the same reasons).

There's usually the crochety old guy on the team that says OO sucks, Java sucks, STL sucks, C++ sucks, the web sucks, everything but the stuff he likes sucks that the rest of the team has to appease.

Yup. Build something better and we can stop saying that. We spend most of our time saying "show me a (Java/C++/STL/web/etc) codebase that doesn't suck and maybe I'll believe that one exists. In the mean time, we start from SMAUG. Take it like a boy scout."

So the new guys with the new ideas don't have the pull to make anything happen without forking the codebase or just starting over.

You know what happened when the Cygnus guys felt that way and GCC wouldn't play ball? EGCS happened.

This is clearly not a difficult concept and someone with your years in the industry should know this.

As is the separation between the codebase and the people who wrote it. Someone with your experience living in the material world should know this. I recommend either taking a correspondence course in Existential Philosophy, or meeting some people, debugging some codebases, and comparing and contrasting between the two experiences. :-P

(continued in a sec)

[angelbob]

Sure. And it would have been a tragedy if he had been able to use the Minix codebase rather than start his own.

What, you mean *aside* from the license issues?

IMHO the reason that Linux is successful and the free BSDs less so is Linus as a driving factor. With an existing codebase with an existing team he would not have had the influence (read as control) that he did with the Linux kernel.

You're saying that nobody will put much effort into a codebase they didn't start from scratch. Is it possible that it's just *you* who won't put much effort into a codebase you didn't start from scratch?

This industry is all about innovation and change.

And yet it's also all about pragmatism, carefully choosing tools for the job and getting results regardless of cool factor. As you say, a fun little contradiction.

I think we'll just have to agree to disagree on this subject.

Fair enough.

[Ashen-Shugar]

Originally posted by Maxi Rose
This hording may be innovation, but it's still hording, and that leads to stagnation, despite the cool code. Look at the semi-famous MUSH variant called RhostMUSH (http://rhost.mybis.com/) .

Here's their "license agreement" of sorts, for allowing other people to use the code. See how wonderfully stifling this all is.

http://rhost.mybis.com/availability.html

Especially look at this passage:



Apparently, we're not allowed to be inspired by their work unless we duly notate this in our code or credits. As well, inspiration is considered "rape". And the main coder, a guy called Ashen-Shugar, raves on and on about how great his server base is and how others either suck or are full of bugs. If his server is so great, why doesn't he share?

If Ashen-Shugar charged people for access to his games or to the code, would this cause greater innovation? Only for those people with no interest in game creation.

You know, I ran across this post, Maxi, and I just can't help but comment on it. Usually I stay quiet, but when people are so obviously flawed and arrogant in their one-sided viewpoints, I tend to just squash the FUD when it starts.

Actually, the 'liscense agreement' for RhostMUSH is just 'don't give out the code; don't let others view the code'. This is just to the hardcode. If you want to modify it, tweek it, play in it, delete it, or otherwise deficate all over it, I couldn't care less, as long as the NDA on not giving out the _original_ code is followed. You can do what you want with your modifications, including, but not limited to, not letting us see them.

Why do we even _have_ an NDA and, as you say 'stifle innovation'? I'll be happy to answer. We got tired of being anal-raped for ideas and code-theft for over a year without even a goodbye kiss and a see you later and finally closed the door on the code being public. You want to bitch about us having the code private? Turn your ire to the people who steal code and take credit for it themselves. Have you ever once thought or even asked why we do what we do, or do you just get on that high horse of yours and assume you know all the answers? In the 8