On Tue, Jan 19, 2010 at 12:32 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
On Tue, Jan 19, 2010 at 10:18 AM, Christian Tellefsen
> That would be an actual Lua state running inside our game.
I like this, because it blurs the old distinction between editing and
debugging. The old model is that one works on dead source, and then
runs the live program, perhaps in a debugger. (There may be a fat
build cycle in between that clears out the human short term memory
cache ;))
But dynamic languages allow much more creative work flows. One can
work with the live program, and edit modules which can be loaded into
that system.
Sounds like something that SciTE could be taught to do. (Also
something that the LuaEclipse people should think about)
An idea I want to follow this year is to collect lots of annotated
coverage information from running a Lua program. This is a good idea
anyway (and of course it's been done). The idea is then to take this
coverage information and use it to browse the source. An interesting
problem, since any given method call might go to a number of actual
functions, but there's an obvious pay-off. Then I can get over my
envy at Java developers jumping all over their projects like mountain
goats.
steve d.
