I can't remember if I've talked about this already. If so, sorry.
In AtariBASIC, and probably other 8-bit BASICs, if the program encountered a fatal error (yes, there are fatal errors in BASIC, don't be daft), the program would stop, but it wouldn't abort. The code could be modified (by re-entering the code with the line number before it, thereby replacing the existing line) and then the program told to 'CONT'. And it would continue where it stopped. While it's stopped, you can do the usual REPL (read eval parse, whatever) stuff and print out variables and otherwise inspect or alter program state. And you can hit the 'BREAK' key, something like Control-C, at any time to interrupt it. This is a fantastic way to learn and experiment with algorithms, as well as to debug algorithmic code.
AtariBASIC was my first. 6502 assembly my next. Then LPC. LPC was the interpreted C language used by LPMud (Multi User Dungeon). A whole bunch of players would be running around, killing things, healing up, selling loot, trading stuff, stalking each other, etc, etc, while at the same time, other players who happened to be wizards were developing the game from the inside. They could call methods on objects to query or alter their state, and edit the code of the game. Quite often people would be standing around in a wizard's workroom gabbing while one or more were editing code, saving it, reloading the corresponding object, testing it, editing some more, etc. Editing in ed/ex (text mode, what came before vi) while people are gabbing, with code and prose mixed, was a challenge.
Both of these things are missing from Perl development.
I did a bunch of work on a zombie game (slowass.net is not stable despite my efforts and so the additional efforts there are sapping my strength). I can't just work a project through. I have to keep making it harder and harder for myself until I finally can't manage. I seem to be doing that with slowass.net. But I also did it with my zombie game, which I haven't touched in months, probably half of a year. I'm trying to bring the better parts of these elements to it.
I guess from the onset of the minizombies, I wanted to be able to teach people Perl like how I was taught LPC -- interactively, live, inside of a game. People looking at my code as I save it, talking to me, and having the code, upon command, reloaded into a live game for players to experience immediately. Code should be a social thing. It should also be an entertainment thing -- the wizards provide entertainment through their creations. It should foster creativity. People should be able to learn by example, modifying each other's code in simple ways at first. Programmers should take a 1st person role in an object universe, themselves represented by an object, their player body, with methods and mutators and accessors. They should be able to call methods in themselves and their friends (and enemies).
As for tech, there's a JavaScript implemented of vi stolen off the 'net, a file browser, and a button to reload code from disc. There's an eval box for immediately, directly manipulating the universe through method calls or reporting on its state. The whole universe gets serialized with Storable and written out to disc and reloaded upon server start. And of course, there's chat built in. It's Web based -- did I mention? No, I forgot that part. That'll never be as quick as a straight telnet connection, but oh well. As for stopping, atlering, and restarting code, I have Code::Splice and there's Cont. Gluing those two together should prove interesting...
-scott
Playing music by live editing of a Perl program's own source.
Re:Smalltalk's debugger
slanning on 2008-01-23T15:28:19
Or like Croquet?
