Bret Victor's Inventing on Priniciple

Bret Victor's talk has been making a huge splash on the net and we might as well talk about it here. The first part of the talk basically describes a lot of live programming ideas, some of which we have explored before but have never demoed quite as well as he has. Note that his demo is completely on cherry picked scenarios, there isn't a general system behind his work. Here are the interesting parts I'm recalling from memory:

  • The first part simply discusses live editing of a discrete program that creates a static image, which simply means you re-execute the program after each edit and observe its new output in real time. Easy enough to do in any language, as long as the program is small enough to execute quickly, edits effects on execution will appear seamless.
  • The second part deals with a stateful game, where he demonstrates time travel and projection to explore how changes in the code effect the result. Much more interesting, though I think for the demo he is just recording the input streaming and replaying the game (which is just one scene) with the recorded input each time time travel occurs backward (wit projection you just fiddle screen clearing).
  • Observing the effects of programming a quicksort function in real time by specifying sample input. Very similar to Flogo II's live text concept, but loop variable values are encoded as nice tables.
  • Finally, Bret does a custom animation through macro recording and by going back in time and recording other movements. The composite of all the recordings that occur in overlapping time segments then becomes the final animation.

why first-class functions

I am thinking about a design for a new programming language, and I can't decide whether to include first-class functions.

I understand (I think) how they work and when they might be used, but I can't think of any programming problem where the solution requires them. Can anyone give such an example?

Thanks, Mark.

why inheritence in OOP?

I thinking about the design of the object model of a new programming language, and am leaning away from the idea of inheritance.

As far as my understanding goes, inheritance serves the following purposes:

* re-use of code in the child class by inheriting functionality from parent classes

* helping/enabling polymorphism by creating classes that have similar enough capabilities to make them "compatible" to a greater of lesser extent.

Have I missed anything or got aything wrong? Does anyone know of any language type models that do not use inheritance? Does anyone have a view of the pros & cons of such a model?

I've looked at what has been in Go, and my initial impression is that I like it.

Thanks, Mark.

Massive Numbers of Actors vs. Massive Numbers of Objects vs. ????

I'm trying to get a handle on core technology for an application that's going to involve massive numbers of entities - where the entities want to have characteristics that draw from both the object and actor models.

Think of something like massive numbers of stored email messages, where each message is addressable, can respond to events, and in some cases can initiate events - for example, on receiving an email message, a reader can fill in a form, and have that update every copy of the message spread across dozens (or hundreds, or thousands) of mailboxes/folders distributed across the Internet. Or where an email message, stored in some folder, can wake up and send a reminder.

One sort of wants to blend characteristics of:
- messages (small, static, easy to store huge numbers, easy to move around)
- objects (data and methods bound together, inheritance, ...)
- actors (massive concurrency, active)

The topic has come up before, in discussions of active objects, reactive objects, concurrent objects, etc. - I'm wondering what the current state of the art and practice look like.

I'm thinking that Erlang might be nice operating environment for such a beast, but wonder at what point one hits limits in the numbers of actors floating around. I'm also wondering what other environments might blend these characteristics.