@Thenomain
People like you and I can do some amazingly complex things in Mushcode, but it takes a level of effort that oustrips Mushcode's standard use case.
This is a very important point. For all the "bridging power" of mushcode, how many can actually use it to the level of, you know, creating a new game from scratch? I am not familiar enough with the MUSH community to know this number, but I suspect that it's not a large number.
(Note that I'm not talking about plugging in a pre-made system here. That is obviously a great boon of the mushcode ecosystem but has less to do with its inherent "bridging power" and more to do with a backlog of decades of people using it for a very specific set of game styles. For Evennia (or Ares) to catch up with that aspect comes down to adoption and time.)
- You can't do the old trick of testing your code in development in that bizarre but delightful way Mushes allow you to localize code. If you make a change, it's to the server. (New tactic: Lock the code until it's tested.)
This is what version control is for, but no, it doesn't work in the same way as mushcode.
- You have to have server access to test code. You can't test concepts on someone else's server ("how does Penn do this, again?"), and you can't do it without your own complete server installation.
That sounds like a correct observation.
The problem with my communications here is that I'm talking in what sounds like absolutes, but is a matter of degrees. I don't have the language to explain what I'm thinking of, only examples. As you and @Griatch are taking those examples as specific issues and/or complaints, cross-purposes are being attained.
Let me give one more example.
Yes, I have to install the entirety of Python to play around with it (let's ignore online tools for a moment), but I can get into a limited development shell to, well, I could create a whole Python program in it, but it's not designed for that. It's designed to "play".
Are you here comparing "playing" in the raw Python shell to "playing" with code in Evennia? The latter you do (and people commonly do) with the @py command, which allows you to modify the running game in raw Python from in-game. But no, it's indeed not as easy as a full python input line. It's a lot more convenient to just test out Python snippets in the real python interpreter shell (in a separate window).
This is the specific part I was talking about earlier that I think needs help to make Evennia more accessible. (does not say to run vitualenv first, nor how)
Thankyou, that is good and useful feedback. The page was updated to make this clearer, check it out.
Actual Game Dev
This (to me) is a person willing/interested in creating a text-based MMO. In the hobby-world of MU* it generally also means running and maintaining said game. This is accomplished using whichever tools they choose. If they also play the game is irrelevant to the definition. If you are using the build tools (however they may look) in an official capacity to expand and improve the game, you are also a game dev.
If you are a regular player that are using the build tools to expand the game world/game experience on your own volition you are not a game dev IMO - you are then a content creator or maybe a modder. Which can be super-important and something an individual game may really want to support by adding resources to make such activities easier.
@surreality
I think -- and I could be entirely wrong -- what @Thenomain is trying to say is that once you install the MUX server, you essentially type one startup command and you have what you need to begin creating a play space on the creative front.
You have the four types of objects in place -- Player, Room, Exit, and Thing -- as well as basic communication commands.
Technically speaking, if your goal was to create a very basic, statless game, you already have more or less everything you need in place to start creating your grid/playspace by just adding and describing rooms, which is as simple as: [...]
This particular example is not making MUSH/MUX any different from any other codebase out there. Even the command examples you give work the same out of the box in Evennia. 
@WTFE
Given that the process in Evennia is, as you yourself admit,
- Come up with a crazy idea.
- Type in the code for that crazy idea in your code editor.
- Switch to game and run
@reload to watch it crash and burn.
- Repeat until this doesn't crash and burn.
Yet, I would far rather try setting up a MUSH server--despite hating the technology it's based on!--over setting up a game on Evennia. Why? Because the barrier between conceiving of something and seeing it work is far, far, far smaller.
Firing up a text editor, editing code there, then switching to your game and typing @reload isn't as onerous a task as the horrible, horrible, horrible steps I take to get my C code working on an MCU, but it's a far cry from "the point of entry is the point of output" that fosters the best exploratory work. You're still switching out of your concept space and worrying about the plumbing. When you factor into that the API I linked to earlier with its myriad of StateManagerFactoryManagerStateManager types and other crud from shitty OOP methodology you have something that divorces you so far from the actual game design that it's actually kind of comical to see.
A proper Python text editor will make all of Evennia's API directly available to as you type, with inline documentation, auto-completion and direct syntax checking and testing. It's quite clear your dislike for OOP is the main beef here. Fair enough - if you prefer Mushcode over Evennia's solution that's your call.
