On 6/13/2011 1:33 AM, Julian Leviston wrote:
On 12/06/2011, at 1:00 PM, BGB wrote:
image-based systems have their own sets of drawbacks though...
dynamic reload could be a "good enough" compromise IMO, if done well...
I don't follow this train of thought. Everything runs in "an image". That's to say, the
source code directly relates to some piece of running code in the system at some point. Smalltalk,
Self and the like simply let you interact with the running code in the same place as the artefacts
that create the running code. It's akin to programming in a debugger that saves the contents of
memory constantly as "the source".
except, that traditional source-files have a "concrete" representation
as so many files, and, beyond these files, there is nothing really of
relevance (at least, conceptually, a person could print a program to
paper, re-type it somewhere else, and expect the result to work).
does it rebuild from source? does the rebuilt program work on the target
systems of interest? if so, then everything is good.
an image based system, OTOH, often means having to drag around the image
instead, which may include a bunch of "other stuff" beyond just the raw
text of the program, and may couple the program and the particular
development environment used to create it.
this coupling may be somewhat undesirable, and it is preferable to have
the source as files, so then one can "rebuild from source" whenever this
is needed.
also, another risk is of the development image becoming "polluted" as a
result of prior actions or code, which may risk compromising a project.
granted, the one major drawback of traditional files-based development
is its traditional dependency on the "edit/compile/run" cycle. scripting
languages can often make this cycle a little faster, but don't
necessarily eliminate it.
however, "dynamic reload" can stay with using plain text files (thus
allowing restarting clean if/when needed), and preserving familiar
aspects of "the coding process" (namely, having ones' code organized
into a tree of source files), but allows some of the merits of
live-system coding, such as the ability to quickly load their changes
back into the app, without having to exit and restart the program...
in this case, the currently running program image is partially
malleable, and so is subject to hot-patching (within sane limits), so
changes to the source can be reflected more immediately (no app restart).
however, unlike full image-based development, the app will generally
"forget" everything that was going on once it is exited and restarted.
by analogy, it is like running programs in Windows:
one can open/close/run programs, edit things, ... in Windows, and so
long as it is running, it will remember all this;
but, if/when Windows is rebooted, it will forget, and one starts again
with a "clean slate" of sorts (an empty desktop with only their icons
and start-up programs to greet them...).
but, the merit of rebooting Windows is that it keeps the system "clean",
as running Windows continuously is prone to cause it to degrade over
time, and without an occasional reboot will begin to manifest lots of
buggy behavior and eventually crash (IME, much worse in Vista and Win7
than in XP...).
As it's 2011, surely we can come to a point where we can synthesise these two
"apparently" orthogonal concerns?
I think the main issue with smalltalk-like "image" systems is that the system doesn't as easily let
you "start from blank" like text-file source-code style coding does... thats to say, yes, it's
possible to start new worlds, but it's not very easy to reference "bits" of your worlds from each
other...
yes. for many types of project though, this is a potential deal-breaker.
another part of the matter may be that of dealing with different
libraries being updated independently by different developers.
I am not certain how well either image-based development would map to
traditional team-based development practices (say, where 5 or 10 people
are assigned to work on a particular component, and 5 or 10 others
working mostly independently are assigned to an adjacent component, ...).
granted, I may be wrong here, as I haven't done a whole lot of
development with image-based systems.
and essentially, that's what text-file coding (ie editing "offline" code) does for us... because things are
in files, it's easy to "include" a file as one packaged unit, or a group of file, or a "package"...
and then that "package" can be referred to... separately, and even maintained by someone else, and it's not a
COPY of the package, it's a reference to it... you know? This is incredibly powerful.
yep.
I am generally mostly in favor of using files.
The equivalent in a smalltalk system would need to be some kind of amazing version
control system that can version worlds at certain points, and package code in a recursive
encapsulation process. Having a "global namespace" is kind of retarded...
because context is everything...
... that's to say, when and as context yields meaning (as I believe it does from my fairly deep
ponderings), no "token" that yields meaning in a given context holds its meaning when
decontextualised in the same way, therefore names (as these "tokens") are deeply
important IN CONTEXT. What kind of relevance, therefore, has a global namespace got?
well, it is a tradeoff...
global namespaces make a lot of sense for file-based development though,
as then everything can be identified as belonging in a certain place and
having a certain scope, so namespaces can serve as an organization system.
the downside though is that not always does one want all code to have
access to the same stuff.
for example, one may want to run code in a sandbox where only certain
namespaces are visible, but sadly there is no "ideal" way to do this
that I have found...
my VM does support multiple root/toplevel objects (all
packages/namespaces are relative to this root), where a given toplevel
may itself contain only a certain subset of the namespaces.
however, this is not generally used, and creates some awkward issues.
another partial compromise would be to support, essentially, symbolic
linking and "chroot" in ones' namespace system (sandboxed' code
essentially running with a "chroot" in effect, so it only sees packages
aliased into its local subset namespace).
the main alternative though would be introducing security-checking
and/or an ACL-like mechanism (scope-based ACL checks...).
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
