When I was tasked by AT&T & Knight-Ridder to architect their nationwide rollout of a mass market information utility starting with electronic newspapers, it was before TCP/IP had been carved in stone so I went to David P. Reed (Mr UDP) and talked with him about his PhD thesis regarding a distributed programming synchronization paradigm that, coincidentally (or perhaps not so), was isomorphic to the dataflow architecture by the guys the next floor or two down at the MIT LCS (Arvind and Gostellow's U-Interpreter). A version finally ended up being implemented as TeaTime under the now-defunct Croquet system. I had some additional semantics sufficing to deal with the memoization (cache) maintenance problem elegantly that didn't get incorporated into TeaTime. The main limitation as I saw it was the focus on functional (N:1) programming as opposed to relational (N:M) programming since one can get functional programming as a degenerate case of relational. The XSB Prolog guys finally got something done with incremental tabling that handled part of the memoization (cache) maintenance problem, but the parallelization and distributed atomic action problems remain. My focus on relational semantics was reinforced by my interactions with Backus regarding his seminal Turing Lecture about FFP when he admitted that would be an afterthought.
While it is true that we live in a world where there is an apparent unitary state transition going on, hence N:1 is a kind of underlying assumption, this is only true in the case of an atomic action "commit". Up until that point in time, the atomic action can be undone in a quasi-reversible programming sense. So, despite getting to know not only Backus, but also Curry and Church toward their end of their lives, I saw relations as the cornerstone of any programming paradigm for which I would be responsible since I could have affected the lives of billions by failing to so-discipline my architecture. This obviously leads directly into quantum information systems, which Federico Faggin attempted to explore with my colleagues at Boundary Institute -- refugees from Paul Allen's Interval Research -- by resurrecting Russell's Relation Arithmetic as the proper formal language of the quantum core. But here's the thing that everyone seems to miss about quantum information systems: If we accept that they are at the basis of the empirical world (as Russell said of Relation Arithmetic) then physical dimensions should naturally fall out of the structure. By "physical dimensions" I mean stuff of the physical world that any programming language dealing with artificial intelligence must necessarily deal with in order to be considered MODELs of reality. Other than Relation Arithmetic (as revived at Boundary), I've seen absolutely NOTHING in the SIGPLAN-proximate world that remotely accomplishes this except as a bricolage kludge. This is quite frustrating and, to be quite honest, I don't think ANY new programming language deserves to exist that doesn't perform this feat as an inevitability of its structure. This isn't just an autistic demand for a pet project. It gets to the foundation of the way computers model reality. On Sun, Mar 5, 2023 at 12:06 AM Ben Goertzel <bengoert...@gmail.com> wrote: > On Sat, Mar 4, 2023 at 6:06 AM stefan.reich.maker.of.eye via AGI > <agi@agi.topicbox.com> wrote: > > > > I'd be very curious to hear what you see as the role of Rust in AGI if > you'd be willing to expand on it a little bit. (Trade secret?! :) > > > > Stefan > > It's not very secret, see e.g. > > https://github.com/trueagi-io/hyperon-experimental > > We have created our own AGI language (MeTTa) to play a key role in our > new OpenCog Hyperon system, > > https://wiki.opencog.org/w/Hyperon > > but the interpreter for core MeTTa has to be written in something else > and that is Rust (which we chose over C++ or Haskell for this purpose > for fairly familiar reasons...) > > ben ------------------------------------------ Artificial General Intelligence List: AGI Permalink: https://agi.topicbox.com/groups/agi/Ta26ae6adc3928674-Mf2b83f83e75bc21ed0a9e360 Delivery options: https://agi.topicbox.com/groups/agi/subscription
