3 ms·
LPMUD taught more people how to code and more effectively than basically any online educational environment I can think of, and it did it without people even re
by Blackthorn 2y ago
LPMUD taught more people how to code and more effectively than basically any online educational environment I can think of, and it did it without people even realizing that's what they were learning.
- em-bee 2y agoi also learned LPC in an LPmud. unlike other MUDs it had a built-in ftp server, and ed. i learned concepts like trampolines and blueprints, which i later learned were closures and classes. and i learned about inheritance and objects. conveniently, objects in an LPmud are real tangible objects like a dragon or a sword. remember those dumb sounding introductions to OO programming, like class dog, inherits animal? in LPmuds you really have examples like that: class dwarf, inherits NPC, or class sword, inherits weapon. one of the features that LPmuds needed was the ability to update objects from changed classes/blueprints at runtime without restarting the server so that the wizards could work on the game while others were playing it. it was coding in production, but usually the areas in development were closed of to regular players. but you can imagine how robust LPmuds and LPC had to be to enable that. then the web came up and i was looking for a better webserver than the ones from NCSA and cern. i discovered spinner. and to my surprise i found that it was written in uLPC, a rewrite of LPC. spinner was renamed to roxen, and uLPC was renamed to pike. spinner/roxen had modules that were easy to write: class mymod, inherit SomeModuleType, do stuff. roxen modules were objects that got instantiated each time a http request was made. the http request object would call them in some order and let them do their thing and add data to the response object. i wrote many such modules to customize the behavior of my websites. one morning i woke up and realized what OO programming really meant because i understood how the different objects interacted with each other and encapsulated things. until then i had only been going through the motions because that's how i learned to do things, but i didn't know why. roxen also was able to reload modules from changed code at runtime. (remember the LPmud ability to reload objects? it's the same feature. in roxen it was a bit weaker because it only applied to new instances, but that was intentional, because unlike LPmuds, in roxen objects were short lived anyways) fast forward almost a decade and i discover open-sTeam, an object storage server written in pike, using MUD concepts internally. it had rooms and doors/gates to connect them. users logging in had an inventory and could pick up and drop documents like objects in a MUD. it also had object level access control. the developers said they chose pike because it was the only language that allowed them to implement this kind of access control. and here too, like an LPmud open-sTeam has the ability to reload objects with new class code. and unlike roxen it does so for existing objects too. i am still using open-sTeam to build my websites today, after modernizing it by adding a REST API combined with a modern frontend framework. and i can do live coding while the server is running. for my own websites i do that in production. for client websites i keep a separate dev server. although, since the server is so rich in features i rarely have to do any custom backend coding. most of the work in in the frontends now.