MUDS have some really unique and interesting programming concepts which you won't find anywhere else. This is particularly true about MOOs and somewhat true about LPs, not so much when Diku derivatives are concerned.
To give just one example, MOO lets you create and reprogram objects while the game is running. Instead of your normal code-compile-run cycle, you're constantly in game, modifying things one method at a time. As you fix bugs and add features, you can experiment with your shiny new object, or even give it out to friends to play around with.
There's no need to recompile, rebuild, restart, get back into the screen where the bug you're currently fixing was, you just make a change to a verb, try performing it and see if the effects make sense. You can literally go from a bug report to globally fixing your issue in seconds.
In MOO, The distinction between code, which programmers modify and occasionally deploy, and data, which users can modify at runtime, is much more blurry. Everything is an object, including entities like players and rooms, and code is stored in the same database as object instance data. Things are persistent by default, if you edit a method at runtime, that edit is persisted across restarts, just as a simple attribute change would be.
All of this comes with a pretty sophisticated security model, which lets you decide who can see and modify your code and attributes, or even who can call it, and under what permissions. There's also a quota system, with limits on both execution time as well as the number of objects owned. This makes it safe to give out programming rights to untrusted users.
On (some) MOOs, all players have the freedom to make their own rooms and their own objects. You want a clock that chimes every hour? A game of monopoly in your virtual living room? Maybe you want to turn your virtual house into a Harry-Potter-themed world, magical duels and all? You're only limited by your imagination and your coding skills. With modern cores, which give you access to JSON serialization, HTTP requests and other such niceties, you could even build a virtual house where the light switches control real smart lightbulps in your real bedroom.
This way of coding certainly comes with some drawbacks, there's no version control, and usually no testing before you introduce your changes to everybody else. Moving changes between different servers is somewhat difficult, as core game objects reference players and the things they own and quite a bit of code is written and owned by the players themselves, making little sense when other things that those players might have in their inventory don't exist. I also imagine it would be difficult to incorporate modern notions of horizontal scalability, considering that any command you execute can theoretically modify any object anywhere in the world or send text to any other player, and you have no idea what it's actually going to do before you execute the code.
I don't think this paradigm would work well in the modern, corporate and commerce-driven world, but it lets us imagine how programming could have looked like in an alternative world that diverged from ours somewhere in the 80s; it's more like old Smalltalk than like our modern languages.
To give just one example, MOO lets you create and reprogram objects while the game is running. Instead of your normal code-compile-run cycle, you're constantly in game, modifying things one method at a time. As you fix bugs and add features, you can experiment with your shiny new object, or even give it out to friends to play around with.
There's no need to recompile, rebuild, restart, get back into the screen where the bug you're currently fixing was, you just make a change to a verb, try performing it and see if the effects make sense. You can literally go from a bug report to globally fixing your issue in seconds.
In MOO, The distinction between code, which programmers modify and occasionally deploy, and data, which users can modify at runtime, is much more blurry. Everything is an object, including entities like players and rooms, and code is stored in the same database as object instance data. Things are persistent by default, if you edit a method at runtime, that edit is persisted across restarts, just as a simple attribute change would be.
All of this comes with a pretty sophisticated security model, which lets you decide who can see and modify your code and attributes, or even who can call it, and under what permissions. There's also a quota system, with limits on both execution time as well as the number of objects owned. This makes it safe to give out programming rights to untrusted users.
On (some) MOOs, all players have the freedom to make their own rooms and their own objects. You want a clock that chimes every hour? A game of monopoly in your virtual living room? Maybe you want to turn your virtual house into a Harry-Potter-themed world, magical duels and all? You're only limited by your imagination and your coding skills. With modern cores, which give you access to JSON serialization, HTTP requests and other such niceties, you could even build a virtual house where the light switches control real smart lightbulps in your real bedroom.
This way of coding certainly comes with some drawbacks, there's no version control, and usually no testing before you introduce your changes to everybody else. Moving changes between different servers is somewhat difficult, as core game objects reference players and the things they own and quite a bit of code is written and owned by the players themselves, making little sense when other things that those players might have in their inventory don't exist. I also imagine it would be difficult to incorporate modern notions of horizontal scalability, considering that any command you execute can theoretically modify any object anywhere in the world or send text to any other player, and you have no idea what it's actually going to do before you execute the code.
I don't think this paradigm would work well in the modern, corporate and commerce-driven world, but it lets us imagine how programming could have looked like in an alternative world that diverged from ours somewhere in the 80s; it's more like old Smalltalk than like our modern languages.