On 6/11/2011 6:59 PM, Julian Leviston wrote:
On 11/06/2011, at 3:40 PM, BGB wrote:
this is also partly where dynamic script loading and eval can be nifty...
say, one is using an app, and then in the console they type in a command, say:
;load("scripts/myscript.bs");
and can quickly edit the file, hit the uparrow in the console to re-enter the
prior command, and observe the results.
Yes, but this method of programming sucks, severely. This is why I am
wholeheartedly happy that FoNC are on the case. Unfortunately I don't know of
any other group of people who have both the insight and capability to do this
research.
yes, but reloading as the app runs, is still better convenience-wise
than its main alternative:
go over to Bash or CMD;
hit up-arrow, which re-summons a command like, say, "make -f Makefile.msvc";
wait for several minutes (as the C or C++ compiler rebuilds everything,
doing a big recursive makefile walk), maybe go and use bathroom or get
coffee;
start up app, and test whatever changes were made;
edit source files some more;
repeat...
the main advantage is that, often, the in-program "load" command may
only take maybe a matter of milliseconds, or a few seconds for a large
mess of scripts, and so is a good deal faster, and doesn't require
exiting/restarting the app, but as a drawback, does not cover
statically-built parts of the app.
the analogy would be doing a page-load in FireFox, vs going and exiting
and rebuilding FireFox, to update the page...
also, one can type commands interactively into the console, but the
downside of this is that it is not nearly as effective (the console
isn't very good for entering large/complex fragments), as well as
generally anything entered into the console is forgotten when the app
exits/reloads.
"auto-reload on save" could also make sense...
for example, in my 3D engine, it is possible to dynamically alter the
map geometry as the program is being run (this is how my mapper works),
however, the "trick" is that the world representation is not itself
nearly so dynamic, and in-fact, most of the "dynamic" aspects can be
attributed to me using a very "quick and dirty" strategy to rebuilt the
BSP tree (some years back, I had observed that QuickSort could be used
as the basis of an O(n log2 n) BSP-rebuild algorithm, vs a more
traditional O(n^3) or so BSP algorithm...).
a sufficiently fast dynamic compiler could recompile and relink the code
whenever the user makes changes, and then saves them...
I actually originally intended something like this with my "dynamic C
compiler" project, but discovered that my C compiler was far too slow
and buggy with this, and often attempting something like this was more
liable to blow up in ones' face than work correctly (there are many ugly
issues with hot-patching running C code).
I later concluded that C was not really the ideal sort of language for
this sort of thing.
a partial compromise could be a "fast reload" key, where one hits a key
to cause the VM to automatically reload any loaded scripts (without
having to re-enter a console command). the downside is that one would
have to keep track of any loaded modules as to force-reload them.
hmm...
either way, it is better than a full rebuild with "make", since this
generally requires fully exiting and restarting the program as well, in
addition to any delays related to rebuilding.
Decades later and the Smalltalk and Self systems are STILL some of the easiest environments to
discover the intention of programmers, and to create new models and expressions in code. Almost
needless to say is that even though this is the case, these systems are severely lacking. Who am I
to judge, that I have produced nothing that "doesn't suck"? I'm at present simply someone
who is calling it how I see it. All development begins with the awareness of a "lack".
;-) A real need in the beholder.
image-based systems have their own sets of drawbacks though...
dynamic reload could be a "good enough" compromise IMO, if done well...
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
