Posts made by WTFE

I am neither for nor opposed to metaplots in a game. I just avoid them if present. My reasons why:

1. Lack of opportunity. My time zone makes it very hard to sync up with me. When metaplot pieces have fallen in my lap in the past the result was disastrous because I couldn't hook up with the right people ever to move things along. I became the stumbling block that prevented the plot from moving onward (quite involuntarily, I might add!).
2. Lack of interest. Most of the metaplots I've seen make me yawn. They're either so vague as to be meaningless in terms of actual game play and/or contribution or they're so tightly on rails that I may as well be a remote keyboard for whoever is running them.
3. Avoiding the wrong crowd. I can't help but notice that all the people WORA was originally established to call out and mock tend to flock to metaplots. They're like the gathering ground of the degraded. cough Custodius! cough
4. Avoiding staff. For the longest time after being burned on Skotos I avoided any and all staff interaction like plague. Indeed even now, except on the smaller, intimate games, I still feel a little on edge when talking to a known staffer. Metaplots by their very nature involve staff and while I'm no longer as virulently anti-staff as I used to be, I still am a bit skittish.

The problem with prefix codes (or paired identical tokens) is one of scoping. I'll pull an example of this (specifically paired identical tokens) out of the realm of Unix-alike shell scripts.

The traditional way of getting the output of a command in a shell into another command is the use of the "backtick" (`). You wrap the command in backticks to get the string that the command would otherwise print to your screen. So, for example, `date -I` would put the current date in the "international" format into your command. So if I wanted to scan a file for any instances of today's date in it, I'd use a command line like this: grep -i `date -I` my_file.txt

There are several problems with this (for an example of these, check the actual text I had to type above to get it looking the way it does…), but chief among them is that you can't nest. I can't take the output of a command and put it into another command whose output I want to use. foo `bar`baz`` doesn't work, for example. This unnecessarily limits your abilities to compose higher-order constructs in your text.

The solution to this in the Unix-alike shell world was to deprecate the use of backticks and instead use the $(...) construct. Because there's a clear opening token and a clear closing token, it's easy to build nested structures. The original scanning one would now be grep -i $(date -I) my_file.txt, for example. And the one that doesn't work would become foo $(bar$(baz)). It's clearer to the eye where the replacement is going to be in the first example, and the second example is actually possible. (Incidentally, this also makes it easier to write the parser, so a developer who opposes balanced tokens is of dubious competence in my books.)

Of course this still leaves us with the problem of how to identify replacements. The MUSHcode solution is, as is typical for that family of half-baked software, utterly idiotic. Using % as the introductory token doesn't work because % is a character people use a lot. As in saying "75% off!", a problem I face after well over a decade of playing MUSHes still. (It doesn't help that various bits of softcode deal with this inconsistently so sometimes I have to use %% and sometimes I don't in an incoherent mess.) Too, using square brackets is also pretty idiotic. We may not use square brackets as often in English as we'd use, say, the percentage sign, but we still do use them.

What a good system really needs is something that's consistent and different from English.

So here's the outline of what I propose:

First, use a compound, balanced-pair approach for EVERYTHING. Period. Yes it means you type a bit more when you're accessing, say, a variable name. Suck it up. For substitution codes, open with, say "$(" and close with ")". So what in MUSH would be "%n" becomes "$(n)". (Let's not quibble over whether it should be $(...) or %{...} here. This is illustrating a concept, not detailed specifics.) For function invocation and substitution I'd suggest a different pairing be used, just to make it visually clear to the reader that different behaviour is intended. So "[random_select(this|that|the other)]" in a hypothetical MUSHing substitution could be instead "${random_select(this|that|the other)}".

Now my reasoning for these:

1. First, $( and ${ (or whatever opening tokens are chosen) are not exactly commonly used tokens in English expressions. This means you reduce ambiguity and the resulting disambiguation (like MUSHcode's irritating, and inconsistent, requirement for %% when you want to talk about sales promotions). About the only time you're going to have to escape these is if you're directly talking about the code itself.
2. To my eyes $(n) stands out a lot more from the text than %n does. It calls out that a substitution is being made and this makes it perfectly clear precisely what is being substituted and where it fits.
3. The parser is easier to write when you have a clear and consistent single character that begins a substitution.
4. It's easy to mix and match at need, as well as nesting at need. Consider a piece of code that can randomly affect the invoker or the target: ${name(${select_from([$(n), $(1)]})} is bonked on the head!
5. It is also, by virtue of being properly tokenized, parsed, and executed code instead of simple-minded string substitutions all the way down, code that's able to be formatted. In situ, not passed through external formatting/deformatting tools.

If that "Leah" is who I think it is, there's no way Thenomain drove her off. She's too self-involved for someone else's opinion to do that.

@faraday said:

@WTFE I'm not sure I see that as an "advantage". As you say, checking for the presence of something is a core part of almost any application, whether it's checking for a message or checking to make sure the user didn't forget to provide some critical piece of data. Why would you want to re-invent that concept every single time you do an app when the ubiquitous nil/null check is something everyone's already familiar with?

Because people shouldn't be familiar-to-the-point-of-contempt with a manual, rote, error-prone process.

People were once familiar with writing out the underlying machine code directly, hand-assembling from a textual description into final object code. No less a person than Von Neumann himself scoffed at the notion of an automated assembler because it was wasting valuable machine time on something a person could do. Nowadays 99.44% of programmers would have their eyes glaze over if you handed them an assembler source file because in the interim we've recognized that human beings suck at rote work.

If you have a rote pattern whose absence leads to (often undiagnosable) failure, you don't expose it and make it the norm (if you're sane). You find a way to automate it or abstract it away unless it's absolutely needed. This is true whether you're dealing with hardware abstractions (trust me: you really don't want to deal with the vagaries of all the pieces of hardware behind your code; be very happy the people who designed your OS, as bad as it may be, didn't do that to you!), memory management (even the "manual" memory management of C and C++ and their ilk is automated to the hilt; it's just not as automated as it could be), or, in this case, presence/absence checks (a.k.a. nil checks).

Now it sounds like Griatch's plugin system does it right and doesn't expose a requirement for a presence check. That's good. It would have been easier to provide that in another language, but it's decent that he's thought of that. Because I guarantee you: if you make plugin developers have to look for this kind of stuff, you'll have a fragile set of plugins that will at the very least comically fail and at the worst case may subtly corrupt your server.

If you can have a value that is "nothing" that needs to be tested for before you do things, you have a null check. It may not be a physical null pointer (although I'd bet large amounts of money that most ARE such behind the scenes), but it's effectively the same thing: a bottom test. An unnecessary complication that boils down to "get X, test if X is actually there, use X". Such a manual cycle is incredibly error-prone (and is, indeed, at the core of a lot of security breaches and other related bugs).

Languages which don't have this basically do proper abstraction behind the scenes. Prolog, for example, has no "nil" value (unless you deliberately put one in for the rare use cases in which it is necessary). Any language with proper higher-order functions (or equivalent) can also dodge the bullet in most cases. The same applies to languages like Erlang or the ML family (although sadly in the libraries people will define an equivalent instead of thinking out their abstraction; imperative thinking still infects even declarative languages a lot of the time when people get started).

As an example of how Erlang (the language, not necessarily the library) avoids the need for nil checks, the core of a proper Erlang program is a process. A process has a mailbox. A typical process waits for a message and reacts according to it. If there is no message it waits until there is one. There's no cycle of "get message; check if message exists; do something with that message" -- unless you explicitly TELL it to work that way (with timeouts, etc.). By default there's no need for nil checks.

Similarly pattern matching in the MLs, combined with the nice array of higher-order functions, eliminates the need for nil checks in the overwhelming majority of cases you'd find them in imperative code (to the point that I don't actually recall when I last did an explicit nil check in SML). Sure, under the covers, there's presence checks galore, but the end-user is shielded from them in 99.44% of the cases unless they're doing some very specific things.

As for Prolog, the most common use case for nil checks in imperative languages coincides with backtracking situations in Prolog. The runtime finds the "nil" (no solution) case for you and just goes back and tries again if there's another path.

The advantage to all this is, of course, that your code isn't littered with nil checks that fall outside of the actual problem domain you're coding to. The code reflects your problem domain more accurately and what code there is can be more easily followed without the line noise of constant access/existence/solution/whatever checks. (Unless, of course, said checks are part of the very problem domain, like say file system handling where checking if a file exists can be viewed as a nil check if you squint right.) And of course, it means there's no way to forget to do the nil check. The system's underlying mechanisms do them for you and direct as appropriate.

Ever since Tony Hoare made his "billion dollar mistake" (a mistake he made, incidentally, not because of and actual need but because it was so easy to implement in the Algol W compiler!) the software industry has internalized the nil check to the point that we can't even imagine what programming without one would look like. Like I said, it even infects otherwise declarative languages and environments in a pernicious way as people reinvent it.

You can't get away from null ... and yet entire language environments exist in which there's not a nil/null/whatever check in sight.

I have literally no opinion on Evennia beyond not really liking the name much. (Although it's light years ahead of PennMUSH, RhostMUSH, TinyMUX, etc.) I have no idea what you're doing with it or where you're going with it except from a few things I've seen here and there as you guys talked about it. What you just said sounds like you're going in the right direction, however.

See it would be "uncharitable" if any actual advances had been put into MUSH code bases in the past 20 years. Let me count the advances I've seen:

1. Some MUSH code bases have primitive RDBMS interaction capabilities now.
2. Some MUSH code bases have Unicode capabilities inserted.
3. Some MUSH code bases have the ability to sense if a kinda/sorta HTML-supporting client is attached and can kinda/sorta support it.

That's about it. Over 20 years. Now look at the huge foundational changes that have taken place in computing in that same time period. In every field (with the possible ironic exception of development tooling) there have been huge strides in making things accessible and friendly for users. In that same time period MUSHing has not taken even a baby step forward.

So if calling out this painfully slow maturing process is "uncharitable" then I guess I'm just Steve Jobs reincarnated. (The joke here, such as it is, is that Jobs is (in)famous for not contributing to charity ever.)

So it then becomes a question of how to make the game more approachable to newbies without alienating your core users.

See, it's statements like this that cause me to make cracks about ignorance of 40 years of advances. On the computer system I'm using right this very minute I have a GUI-based file manager open and a command line shell in the same directory. For a certain class of operation (selecting a set of files quickly and doing something simple to them) the GUI file manager is better. For another class of operation (selecting single files or large batches based on patterns and/or performing complicated operations on them) the command line is better. There's two views and two approaches to operations on the same thing. (And, I might add, doing things a whole lot more complicated than what a MUSH does.)

And that is one example of many just on the desktop in front of me right now.

The notion of having multiple views and interfaces on a problem domain is ancient technology. It goes back well past the first MUSH ever being written. Want to cater both to your newbs and your grognards? Just ... do it. Give the whiny grognards their idiotic (1- Lisp) language and their primitive interface. And give the newbs a modern interface that doesn't suck. Given how trivially simple the grognard interface is to implement (it's almost the embodiment of Worse Is Better after all) it shouldn't be too hard to slather a grognard interface atop a sane core that presents a sane interface to a client based on modern principles like "discoverability" and "theming" and "not sucking matter out from behind the event horizons of galactic black holes".

Ah, the eternal null check. Tony Hoare's "billion dollar mistake" made manifest.

A properly-architected system does those null checks for you behind the scenes so you don't have to do it yourself constantly with the attendant risk of failure when (not if) you forget one.

We know its culture already. Sales. At least one of its principals has come out and said that.

This whole debacle reminds me of a tea chatter place I frequent. Now I make no secret here that I'm a huge aficionado of tea. This means I tend to know my shit and, more importantly, I tend to know what it is I don't know. (I personally find the latter knowledge more important of the two.) I hang out in a forum of like-minded people: people who like teas (and tisanes) and want to learn more about them.

Into this forum comes someone who suggests we join another forum of people who've been around for longer discussing tea. Several of us eagerly go to join other tea lovers and expand our knowledge and social base.

Uh…

Problem is: in our small tea group we've got people who can meaningfully express the distinction between a <deep breath>Castleton Estates TGFOP 1st Flush Darjeeling</deep breath> and its 2nd flush kissing cousin, explaining why they prefer the "inferior" 2nd flush in most circumstances to the rarer and more expensive 1st flush. And we've got people (well, OK, me) who are currently exploring the bewilderingly huge world of pu'er tea. And we've got a guy now tackling all the weird traditional tea-like beverages like "rooibos" (still have to track down a good source for that to try it out) and making reports on progress. Other problem is: the other "longer, better-established" forum consists of people whose idea of talking about tea is "I just found this place near my home that sells TWINNINGS Earl Gray!"

That tilting the head and looking confused thing? That was my impression when one of us started asking about favourite estate-grown teas and tea-growing regions. There was absolutely zero engagement across the divide because, although we were both "interested in tea" we were interested in radically different subsets of the topic of tea. We drifted off back to our own forum where we were happy and left the others over on their forum where they were happy. We had smug thoughts about their shallow understanding of the topic they purported to love and they probably had their smug thoughts about our pretentiousness.

I'm getting this vibe from the OR crowd, only … they kept coming BACK to tell us about themselves after it was pretty clear we weren't compatible. At least they've cleaned up that part of their act. So far.

It's fun watching people "solve" problems that have been solved since the '90s.

If you want a tip on how to do hot-swapping of code, take a look at Erlang and its OTP library. You'll probably be able to kit-bash something that kinda-sorta works based on that model.

Wait? @HelloRaptor is dead!?

…

Can I have his handle?

@silentsophia said:

I dunno. There's no real fucking reason to bully someone. But I guess 'don't be an asshole' is too tough for some folks …

Well, there's also the issue that "being an asshole" varies wildly from person to person. A friend of mine that I've known for decades asked me for some recommendations on computer hardware. I know what he uses his computer for, etc. and said, "well, based on your use profile, there's no reason for you to waste money on a top-of-the-line rig that you won't even use 10% of". Another friend of his who was present thought that had me being an asshole (while the guy I said it to nodded in agreement and went on to buy a computer he used for four years before he finally outgrew it).

Some things are pretty obviously "asshole behaviour", but the dividing line between "asshole" and "not-asshole" are not as clear as some would like to pretend they are.

It takes more than a near-700GB data loss to keep me down, motherfuckers!

Edited to add:

And, point of order, that photo was taken while I was recovering data. Yeah, I'm just that hard core. By which I mean, obviously, stupid.

Well, after a ten-day hiatus because of a badly damaged hard drive and four (!) subtly-corrupted backups, I'm back online and I lost only about 2GB of data (out of 700GB). And, better, that data was lost entirely from the directory named, I kid you not, "junk".

Also, during that ten-day hiatus, that fucking neocon thug asshole Stephen Harper got his humiliating send-off from office and maybe, slowly, I can start forgiving Canadians for putting him into power in the first place.

Finally, music and tea got united in my home at last:

What the everloving f…!?

I take it back. A couple of people have paid attention to the past forty years. Just not the ones making the server engines and/or the actual games.

When watching people talk about future MU* technology it's like the last 40 years of software research and development never happened.

@Reason said:

I appreciate your interest in softcode, mind you. I think that the world would be a better place if more people took a moment to think about functional programming. W.W.H.D., that's my moto.

Pity that MUSHcode is to functional programming what SNOBOL4 is to structured programming.

WTF kind of "functional" language doesn't have functions as first-class types that are easily composed!? Oh, right. MUSHcode. The language invented by someone who took a Lisp class but didn't understand it.