On Thu, Jan 17, 2013 at 2:13 PM, Ross Bencina <rossb-lists_at_audiomulch.com>wrote:
>
> I mostly follow your reasoning, but can you clarify what your criteria for
> "better" are here please David? Do you have a set of requirements for Live
> Programming that you're operating with?
Live programming only has a few requirements. I would characterize live
programming in terms of low-latency response to edits in program code
without stopping the program, and a certain degree of continuity - i.e.
that we don't lose important decisions, aren't forced to replay.
But there are also a lot of desiderata - things we *want* to hold true of a
live environment, a programming environment, or a live programming
environment. I've mentioned a few such desideratum in this thread already -
e.g. rich abstraction, and history-independent reasoning. There are many
more: modularity, extensibility, composability, continuity, stability,
consistency, concurrency, atomicity, efficiency, other -ilities. And then
there are features such as being robust to incomplete specification (i.e.
filling gaps in code with 'good defaults'), or inline presentation of state
(same canvas as the source code), or effective support for replay, or
effective integration with heterogeneous systems (instruments, sensors,
etc.).
By 'better' I refer to ability to address many such desiderata
simultaneously without significant losses elsewhere. (Language design is
not a zero-sum game. Modulo the effort to search for better designs, and
teach them, tradeoffs are not essential.)
> > This implicit local state can cause similar
> > difficulties as mutable variables, perhaps is even worse because it's
> > hidden from the programmer during edits.
>
> I'm not sure that I understand why you say it's hidden. When I work in C++
> with the Visual Studio debugger I have full access to all program state
> including process counters, queued messages etc etc. Effectively the whole
> running program is a database that can be queried. And there's
> edit-and-continue.
>
Granted, if you crack open the abstractions, you can find the hidden state.
But when you depend on breaking open abstractions (or editing specific
instances of them) to support live programming, it becomes difficult to
achieve a lot of nice -ilities and other features. Any programming language
deficiency can be resolved by discipline and foresight. Relying on
discipline or foresight is a sign of deficiency. I can only imagine it
takes a lot of discipline and foresight to use Visual C++ as an effective
live programming environment.
Regards,
Dave
Received on Fri Jan 18 2013 - 00:37:08 GMT