> > I've read this now - a really interesting paper with many lucid
>> points. It sees live programming languages as separate from dynamic
>> programming languages. In these terms something like PD is live, and
>> something like Lisp or Smalltalk (and their descendants) are not.
>
> Yeah, too bad he got that wrong, at least as far as Smalltalk is
>concerned. Typically, the entire environment, including the code
>editors, are implemented in Smalltalk; the system is reflective at every
>stage of development. Changing the behavior of the system by changing
>the implementation of a method is something that happens routinely
>(independently of when that method is run). Whether the development
>style is "declarative" or "imperative" is orthogonal.
>
> He also seems to be under the impression that dynamic systems can't
>do type inferencing without manual annotation. This is weird; the whole
>point of type inferencing is avoiding such labor. Dynamic systems are
>perfectly capable of providing useful "semantic feedback". It makes me
>wonder how much attention he actually paid to the Self material he mentions.
>
>> "Hot swapping in a dynamic language replaces code so that
>> its re-execution occurs according to the new version of the
>> code as opposed to the old version. ... By being based on a simple
>> data-žow model, live programming in SuperGlue goes much more farther
>> than this: code edits immediately change the program's data-žow graph
>> and the observable execution state of the program."
>
> That just sounds like hot air to me. You can "change the program's
>data-flow graph and the observable execution state" with mere code
>replacement.
>
> The system he presents is interesting, but I think he has failed to
>understand what came before. And his system looks suspiciously like
>something of the long-swaths-of-source-code-in-static-files variety,
>which isn't encouraging to me as a performer.
I agree entirely. While as far as I know, that
"For example, editing the imperative Smalltalk
statement "w fill:red" to "w fill: blue" will not
immediately re-color blue all widgets that have
been bound to w." is presented as a prototypical
example for the need of re-evaluation is
misleading - but even more, it is based on an
overly simplistic notion of presence. There are
also some overly simplified ideas about what
"immediate change". The interesting thing about
interactive programming is the temporal
multiplicity it causes.
taken with a GOS, it is an interesting article.
--
.
Received on Sat Mar 24 2007 - 21:18:26 GMT