5 ms·
On object "states" as recorded object history (snapshots in time?): "The just computed stable state is very useful. It will never be changed again -- so it rep
by themartorana 10y ago
On object "states" as recorded object history (snapshots in time?):
"The just computed stable state is very useful. It will never be changed again -- so it represents a "version" of the system simulation -- and it can be safely used as value sources for the functional transitions to the next stable state. It can also be used as sources for creating visualizations of the world at that instant. The history can be used for debugging, undos, roll-backs, etc.
"In this model -- again partly from McCarthy, Strachey, Simula, etc., -- "time doesn't exist between stable states": the "clock" only advances when each new state is completed. The CPU itself doesn't act as a clock as far as programs are concerned.
This gives rise to a very simple way to do deterministic relationships that has an intrinsic and clean model of time.
"For a variety of reasons -- none of them very good -- this way of being safe lost out in the 60s in favor of allowing race conditions in imperative programming and then trying to protect against them using terrible semaphores, etc which can lead to lock ups."
Oh, my kingdom for atomic, history-recording (and replayable) object states! Safety existed in this fashion in the 60s!! I didn't know this, and now I'm sad.
Race conditions continue to haunt us all to this day, especially as languages start supporting concurrency and parallelism primitively. (Not to mention that debugging race conditions is a nightmare - a nod to the Go language devs for making clear a race condition caused a crash in the stack trace.)
- pjmlp 10y agoYou will be even more sad when you start researching the history of operating systems and systems programming and discover the safety that we already had in the 60's in systems like Burroughs that was destroyed by UNIX's industry adoption.
- m_mueller 10y agoAnd MacOS and Windows and and... It's the "worse is better" approach or whatever that is called that set the 'not-quite-field' (thank you AK for this) back to where it started. To me it feels like we are in a hamster wheel of constant reinvention rather than using the software technologies of the 70ies (mainly from Xerox Parc) as a stepping stone. And whenever the methodologies break down we cry for the next framework/language/hardware platform to solve everything. I for one would love to see a refresh about what is happening to OMeta and its family of technologies developed at Viewpoint [1]. Is this still ongoing? [1] https://www.youtube.com/watch?v=BbwOPzxuJ0s https://www.youtube.com/watch?v=BbwOPzxuJ0s
- jgon 10y agoIf you're looking for a continuation of OMeta check out what Alan's previous research lab CDG (I believe it is largely being folded into HARC) is working on with ohm: https://github.com/cdglabs/ohm https://github.com/cdglabs/ohm
- m_mueller 10y agoThank you!
- blihp 10y agoHere's a presentation, while chronologically earlier, that is specifically about the Viewpoints STEPS project which includes a good segment on OMeta: https://www.youtube.com/watch?v=HAT4iewOHDs https://www.youtube.com/watch?v=HAT4iewOHDs As jgon mentioned, Alex (the author of OMeta) continues work on Ohm, his successor to OMeta. Also, various flavors of OMeta implementations live on in Smalltalk, Lisp, Javascript etc. Recently VPRI released their final annual report to the NSF publicly with indications that work is ongoing. So there are at least pockets of interest and activity.
- m_mueller 10y agoThat's actually the presentation I had in mind but I couldn't find it anymore. Searching with Alan Kay as a keyword is not a big help xD. Thank you for linking it. I'd love to play around with this stuff.
- blihp 10y agoI can probably point you in the right direction for OMeta... what's you're preferred dynamic language? The other material is a bit tougher to come by as I don't believe Viewpoints has released a code snapshot of what they've been working on to date. There are bits and pieces in terms of code drops but mainly what they've released are the NSF annual reports and various papers discussing aspects of STEPS on the VPRI web site (i.e. http://vpri.org/html/writings.php http://vpri.org/html/writings.php)
- firasd 10y agoKinda sounds like Redux.
- olalonde 10y agoAlso, the event sourcing/cqrs pattern.
- inopinatus 10y agoOr double-entry book-keeping. This is an data pattern that predates electronic computing by centuries. Any time I'm delivering a user experience that involves work-in-progress or benefits from any kind of history, I reach for event sourcing. Turns out that's a majority of business processes, at least in my customer sector. I've found it straightforward to implement and realise the benefits of ES & CQRS in isolation. Complexity arises from assumptions of RDBMS/REST semantics in underlying frameworks or connected services.
- protomyth 10y ago> Oh, my kingdom for atomic, history-recording (and replayable) object states! You might want to check out John McCarthy's Elephant and its follow-ons. http://web.archive.org/web/20130729203501id_/http://itc.conversationsnetwork.org/shows/detail3770.html http://web.archive.org/web/20130729203501id_/http://itc.conv... Its not exactly what you want, but it is down that road.
- themartorana 10y agoHey thanks, that looks like a worthy time diversion!
- jgon 10y agoAlan has done work that I believe is directly related to this idea of recorded, atomic object states at VPRI under the name "Worlds". Of course Alan may chime in and let me know that it is totally different but these following two links may prove fruitful for you: http://www.vpri.org/pdf/m2013002_experiments.pdf http://www.vpri.org/pdf/m2013002_experiments.pdf and http://www.vpri.org/pdf/tr2011001_final_worlds.pdf http://www.vpri.org/pdf/tr2011001_final_worlds.pdf Check out the rest of the experiments that VPRI been pursuing here: http://vpri.org/html/writings.php http://vpri.org/html/writings.php