Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

(Started replying to Griatch, went on a tangent, it'll fit better here I think. Skip the first paragraph to go straight to LPC advocacy :D)

Last time I looked at Evennia it wasn't even in alpha, it just started out (and I was a jealous teenager that wanted to do everything himself, too). Since it was so long ago, I only remember (roughly) the basic ideas and some funny interactions on the mailing list, where the creator tried to convince some would-be contributor that no, you don't need money to start such a project... :)

I do remember LPMUD stuff way better. You're right that, at least in the beginning and on the MUD I played and later coded on, the most common way of writing code was... a clone of `ed`. Really, the line-oriented editor, the one just a step before "magnetic needle and a steady hand". You wrote the code in Notepad, then ran `ed` over telnet, pasted the code and observed it being sent, line by line. You quickly learned what \n is and why it's important thanks to that :) Sometimes you missed a semicolon, so you also naturally learned about `s` and regexes, to ease the pain a little. At some point, though, admins figured out the permissions and it became possible to upload code via FTP. Progress!

As for the architecture, the only "hard"-coded part was the "driver", which was just an interpreter/VM for LPC, plus some code to handle network and disk IO. Everything else was written in LPC. LPC was unique in a bunch of ways: it was gradually typed, it was object-oriented but didn't have classes and used prototypal (and multiple!) inheritance on top of providing #include. Imagine a cross between Ruby and JavaScript coupled with object database/object persistence built-in. Everything was an object, and the system was fully reflective - you could manipulate and change parts of the running system from within. Even the source files on disk were objects within the system - as soon as the file got created, it was already an entity you could manipulate with code (that `ed` clone was written in LPC, too).

It was incredibly powerful and fun way of coding. Version control was a problem, of course - since code was a dynamic, run-time construct, versioning just files wouldn't cut it. It's the same problem Smalltalk images suffer from. It's possible to solve, but you'd have to code the version control system into the driver, and guys capable of hacking on the driver were few and far in between. Once again, simpler triumphed - although modern Smalltalks do offer VCSes comparable in features with mainstream ones.

Much, much later I realized that what made it all possible was a version of "become" method from Smalltalk: a way to replace one object with another completely and invisibly. The lack of this primitive operation was what made all my attempts to fully recreate the environment in Python fail (along with problematic object model in Python 2.x, but that's another story). In the end, some ten years later, I learned both Smalltalk and Self, and realized I could get what I wanted by writing a rudimentary telnet server in Pharo. By then, though, MMORPGs ate most of the mindshare that kept MUDs alive, and I got distracted with other projects. I did a few prototypes while learning strange programming languages, but always stopped at ~2-3k loc and never finished any of them. I used these as tools for learning only, believing there's nobody who'd be interested in this way of playing by programming (or programming by playing.)

> I wish there was something similar today.

TL;DR: I researched ~20 programming languages and environments, and got reasonably close to the LPC experience in two of them: Io and Smalltalk. Io is not very actively maintained (last I checked), but there are mature, stable, and free Smalltalk implementations out there. An added bonus is that you get MUD client along with the environment and you don't need to build Web-based admin interface (most Smalltalks provide a GUI).

I have some code I can share if you're interested; I get the same urge to build this thing from time to time, but never really followed through with any of the attempts. Though, I suspect the story would change a little if even just one other person was interested :)



This was a great post. I never really thought that much about why I found LPC so good as a starter language, but the "become" method explains it. I found it so natural--I want this to be this, but different, and wow, there it is, cool.

Every time I started making an effort to duplicate the LPMUD experience with whatever, I ended up in some kind of inheritance hell, and this explains that as well.

You've given me quite a lot to think about, and I appreciate it.

(I remember the editing nightmare as well. I had to use computer lab computers, so I did a lot of my work with paper and pencil outside of the lab. That probably did a lot to teach me as well, but even so, the editing part was just awful. The LPMUD I was on got a better editor, something a lot closer to vi, at some point, which made things so much nicer.)


Glad to hear you liked it :) This is the post that kind of opened my eyes and let me identify the issue: https://gbracha.blogspot.com/2009/07/miracle-of-become.html

There are workarounds, of course - now that I know what I'm missing, it's perfectly possible to implement it in most anything! Though, why bother, if there are existing systems that already implement it :)

(The other important issue is providing prototypal, dynamic inheritance (like in Self, Io, JS, and ofc LPC). Finally, object persistence - that's something that I didn't consider much until now, but other threads here about MOOs also opened my eyes. Not having to worry about server restarts might be a good thing... I think with these 3 things taken care of you'll get pretty close (maybe even a bit better) to the LPMUD environment.)


i am curious to see what you did with smalltalk there.

you may also enjoy looking at pike, which evolved out of LPC, turning it into a general purpose programming language. it kept the ability to replace objects at runtime. which makes it one of my favorite programming languages, next to smalltalk. this ability to implement changes in a live running program is just magic. i find it actually disappointing how rare this feature is. it is pretty much the first thing i ask for any new programming language that someone designs.


It's slowly getting traction - Kotlin on Android has a "live update" feature (in development, only available in alpha release), for example. Multiple less mainstream languages also offer the feature. Nim got it in the last major release, for example. V has it as one of the base features. Erlang and Elixir had it since forever. Common Lisp as well. Racket and Clojure are a little more limited than CL, but also support it. Many interpreted languages offer some degree of this, either by default (JavaScript) or as a library/package (Python, Ruby).

In general, programming language features take about 20 to 30 years to go from obscure niche implementation into the mainstream. Look at lambdas - anonymous function literals - they're now everywhere, including Java and C++. Ten years ago, though, only some scripting languages had it. The feature itself is as old as the bones of the Earth (LISP, 1960, 63 years old). The same is true for many other "advanced" features. I think this is tied to generational changes - each generation of programmers has a chance to bring one or two lesser known features into mainstream, and then they're content with that. Other features have to wait for the next generation to discover them.

As for Smalltalk - I made a mistake and based the implementation on GNU Smalltalk, which is unmaintained. I should have gone with Smalltalk/X, Visual Works, or (begrudgingly) Pharo (or Cuis). I started the project as yet another attempt at making a MUD, but then changed focus to making a productive command-line-based programming env for Smalltalk. Then I changed my mind again and tried to make it into a usable shell. Here's the project: https://github.com/piotrklibert/stshell/ The screenshots focus on the REPL/shell side, but in the source you'll see things like "server", "player", and "world". There are a few locations IIRC and you can move your character between them still (plus, it's multiplayer, so another person can connect and you can talk to them!). It was an interesting project, but without a clear vision of what it should be it lost focus and I left it to rot after a while :(




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: