@Derp
I hear you on the softcode's abilities. The boring answer is "Yes, you can totally implement softcode in Evennia without modifying Evennia itself. And no, it's not there out of the box". Bear with me though, I'll try to further explain this stance from the Evennia perspective.
Firstly, let's separate between developers and players. Whereas this distinction is fuzzier in MUSH softcode than in other game styles, I'm willing to bet there are still people who are actually trusted to modify the core of the game experience for everyone and others that are not. For this analogy let those be the developers and the players respectively. In both cases I think we can assume that developers are the ones expected to learn the tools the best, are accountable for keeping coding standards and generally maintaining the game's best practices. Only developers can make "cheating" stuff that affects others than themselves (so if you are offering totally free online coding like lambdaMoo this analogy fails).
Let's start with the multidescer since it's a concise example. From the perspective of the player, you have described this as a command that you use to add one or more descriptions, also with the possibility to swap one's active desc later. The player also expects to be able to modify the call signature of this function and even how its arguments are input.
Now, in Evennia, the functionality of the multidescer is the work of the developer. Coding it in Python is simple: without going into the technical lingo, it's a matter for the developer to just add multiple description storage slots on the character - these are automatically persistent and can be searched, organized and modified very efficiently. The default @desc command would maybe be expanded to look something like this: @desc/store name_of_description = description. It may even accept an optional list of inputs if you wanted that. Internally, this would just be added to the storage and could easily be retrieved later by whatever syntax you want in order to actually update the desc property on the Character.
So how about the players' ability to modify their experience of this functionality? Evennia has a "nickname" system (controlled in-game by @nick by default). This replaces the input dynamically. So you could this way change the @desc to be called as +desc or +d or whatever you prefer. This is out of the box. Changing the argument list is more complex; for this the developer need to supply something like an @aliascommand command, something that maps the players's input to the real command:
@aliascommand "@desc #1 = #2" = "@desc #1 & #2"
This (rather trivial example) would henceforth allow the player to use +desc name & description to call @desc. There is no @aliascommand in Evennia out of the box, but it would be a simple enough thing to add for the developer deciding their players expected such customization.
Now, this is not softcode. It does not offer the same flexibility as softcode. But it does offer the player the ability to change how they call their commands, changing their experience of the core functionality as defined by @desc. Could the player, say, add an echo to the room every time they update their desc? No, not without the underlying Python implementation changing. Could the developer (knowing their audience) predict this need and offer any number of callback slots for people to change and customize? Certainly - they could even parent all (player-access) commands in their game to such configuration functionality if so desired.
Now for the tarot deck. What the developer would make available here would not be a Tarot deck. It would instead be a generic "card deck" object that players could spawn and customize into a "Tarot deck" on their own: the general functionality and properties of a card deck is after all straight forward and generic. Could the developer add slots for different echoes happening when drawing specific cards? Certainly. Could the player make the drawing of a card cause in-game effects beyond an echo, like putting the room on fire or cursing someone? No, and most likely making an object with a real game-effect like that would be susceptible to cheating; it is probably not be something a player should have the right to create - it would still need a developer's (or at least staff's) input/approval on , also in a MUSH.
As you know, contrary to MUSH, Evennia requires this game effect to be done externally, in Python. Here Evennia says: Let the player, if they want to contribute, temporarily be their own developer. Using any external code tools they want they can make their modified tarot deck and offer it up to the developer using proper code sharing tools (no server access required, heck they could just post the source code directly if they didn't want to use version control). The developer can then review this, including giving online feedback etc and accept the modified tarot deck into the code base where it can now be used.
I would argue (and this is of course where opinions differ) that for the average player to extend a tarot deck beyond the customization that a developer can think of to offer, they will need to learn some more intricate programming regardless of whether it's softcode or Python.
In general I don't think a MUSH developer has any real practical reasons to dislike using external code tools, version control and code sharing resources. For them, using Evennia would mainly be a matter of learning a different workflow - a chore for sure, but one that may be considered worthwhile for Python alone (so far I've not seen any arguments in this thread that softcode as a language is a superior one).
The easy code-contribution of those more advanced players (the ones who want to make world-affecting tarot decs) is a separate, but most real concern. While Python is very easy to learn, it's a fair point that old-time players of a MUSH are more likely to know softcode than the average populace. Needing external tools (and Python which is not seen in-game) for contributing is undoubtedly a higher hurdle for them. How common those more advanced players actually are in your particular game is really what should influence the weight of this argument: As evident from the comments of various MUSHers in this thread, the assigned importance of input from this type of player varies quite a bit. But to repeat - it's a real concern that may indeed make Evennia's paradigm unsuitable for you out of the box.
To sum up (tl;dr?): Will there be things that a player can think of to do in softcode that they can't do out-of-the-box in Evennia? Yes, most certainly, at least not without implementing a softcode-equivalent running on top of Python. How important this difference is depends on the forethought of developers and just how much softcode freedom your game's average player actually uses in practice.
... Conversely, will there be things a developer can do in softcode that they can't do with Python? No. My impression is that most things are instead a lot easier, which is one of the main drives for MU*ers trying out Evennia in the first place.
.
Griatch
