The most recent FoC Virtual Meetup was fantastic. Three great presentations covering a pretty wide range of the FoC spectrum. The recording is live . Thanks again to our presenters, and I'm looking forward to seeing everyone next month.

Tom Larkworthy nonchalantly drops one "insane" idea after the other.

Very good presentations indeed! It makes me regret even more that I missed it. On the other hand, @Ivan Reese asked exactly the questions to @Tom Larkworthy that I would have asked as well, so I didn't really miss any opportunity!

Heh, it seems that my experience is exactly the opposite 😅 When I run projects they typically leave the platform configuration to the user. For example: "this library requires packages , Y and optionally Z, please use your OS's package manager or provide the paths through environment variables". Maybe it's a fault of the C/C++ ecosystem. I've never seen CMake download and configure Windows SDK or VS Developer Tools. In terms of cross-platformness it's rather limited. I only make sure it works of github's images for Windows, Ubuntu, on my Gentoo machine, and for anybody who reports a problem.

Looks like you have tech-savy users! Which makes a big difference of course. I hope that CMake will never download anything. But it can figure out which compiler options are required for which C/C++ compiler.

Yeah, still figuring out the UX. I also find it annoying. In the next iteration I will make it a tiny toggle for edit mode, so it's noticeable but unlikely to block the view until you need it.

@Marek Rogalski - is there a separate URL for your build stuff? Or, is one expected to pry it out of the Automat repo? I totally agree that build-ing needs to be heavily revamped. Our current build processes are rife with out-dated biases from the 1960s. @Tom Larkworthy - You use the words "microkernel" and "reactive". I'm trying to figure out whether there is a direct connection between Lopecode and PBP(0D). I am hampered by a general ignorance of Observable. Comments (from anyone) might help me come down the learning curve. And, comments / questions / brainstorming (from anyone) about interrelationships (or non-interrelationships) between these ideas would be welcome. @Achille Lacoin - PLs and OSs are dead to me. It's not 1960 anymore and we need fresh ways to look at program development workflows. This looks quite interesting and fires various of my neurons regarding steal-able ideas.

@Tom Larkworthy One more question that remains after going through the tour: what's the relation, if any, between cells and modules? Cells seem to be the same as in Observable notebooks. But the latter don't have modules, which in Lopecode are quite central.

the runtime has modules and modules have reactive variables. thats the low level programming model and the core runtime state of the mu-kernel. Cells are an artificial construct of the higher level language of Observable JS. This is what you see a notebook comprised of. Certain special cells actually map to more than one variables. A "viewof X" is two reactive variables, one holding a DOM node (the control plane, the UI, called "viewof X") and an inner one, the data plane (the "X") which is the data channel. A cell that imports looks like "import {a,b,c} from "z"", which is 1 cell, but it creates a dynamic import + a variable for each alias in the import (a,b,c), so is actually 4 reactive variables in total for that example. So the concept of cells is the front end language and not a runtime concept directly. We don't need to really stick to that, I currently do for simplicity but Observable's new canvas product, for instance, is still sharing the same runtime but has done away with the notebook and cell concept entirely. So a notebook is a module (literally an ES module). The module is composed of variables in the runtime. Those variables are grouped in cells. So transitively, cells also belong to a module, but I think it would be more accurate to say cells belong to a notebook which is implemented as a module. There is a function called cellMap which will scan a module and figure out the variable groupings in the decompiler. I have more notes here which I am slowly filling out with finer details, although its not very proof read and super well structurally thought out, its more for me to remember some of the stranger things I discover while stepping through the code.

@guitarvydas no, it's a rather bespoke build script. I use it in a couple projects but copy it over and change a little each time.

direct connection between Lopecode and PBP(0D) -- @guitarvydas

based on my reading of this. Yes! Its a very similar programming model! In Observable each named cell has 1 output and n inputs which are late bound together to form a dataflow DAG. You can update the code for any cell and only the downstream cells are reevaluated. I see PBP allows multiple outputs per part, and technically the Observable runtime could also do this but currently the front end language Observable Javascript does not manifest that semantic, its only one output per cell. Roughly speaking a Part is a Cell. Also Observable Runtime / Lopecode its all clientside javascript so the environment is very different, but there are is a lot of conceptual overlap.

@Tom Larkworthy

... I see PBP allows multiple outputs per part ...

brainstorming: From playing with electronics, I call multiple inputs "fan-in" and multiple outputs "fan-out". Fan-out seems to be eschewed by FP. Multiple inputs and multiple outputs in FP is an illusion created by the power of destructuring (one blob of data, containing many non-homogenous datums). Fan-out, IMO, means data coming at different times (like requests to servers and daemons). Function-based thinking rules this kind of thing out. For example, Morrison's FBP does not allow fan-out, mostly (I think) on the basis that it is mathematically difficult to express in typeset text (

/bin/*sh

took a stab at this using clumsy textual syntax like

|2

and program-lets like

tee

, but that clumsiness just makes the goodness go away)

I think the clearest use case for fan-out is a switch (where the dataflow goes to 1-of-n mutually exclusive ways), which is missing from Observable, in electronics this is a tristate bus where a component decides which of n components its currently connected to (its dataflow is turned off to all but one). You can't build that kind of logic with one output value. However, if you consider a reactive variable to be the wiring of the ports in the PBD diagram, and not the parts themselves, then you can make parts out of "collections of ports". So in that sense, you don't need multiple returns values, you need to be able to construct higher order components out of these lower level reactive wires. I guess important to understanding PBP is what are the semantics of notification. Probably there are massive differences in the approach on that detail. In observable the variable is a scheduled function, but that function can also be a generator, which means that when recomputed, the variable can emit a stream of values onto the dataflow graph, and thus trigger its dependants to recompute many times. I don't expect many reactive systems to have that fanout-over-time semantics. Its useful to have a gameloop defined like this, where the one gameloop is triggering dataflow ticks every animation frame autonomously.

Thanks @Tom Larkworthy, that was very helpful. I hadn't realized that Lopecode modules were ES modules. That's one concept less to keep in mind! 😆

This is actually a question, but, I don't know how to form it as a question. A scheduled function is just a tiny "process". A scheduled function can trigger other scheduled functions. A scheduled function "call" is a non-blocking "call" to some other tiny process. Can a scheduled function trigger itself? A non-scheduled function can call itself - that's called "recursion". But, it's not "recursion" when a scheduled function triggers itself. I call that "feedback". Are scheduled functions required to return a result to their "callers" (triggerers)? AFAICT in FP, this routing policy is enforced and has resulted in clumsiness like ".then". OTOH if a scheduled function is not required to return a result to its triggerer, then it's not a "function" it's a "procedure" with side-effects. (IMO, that's a good thing).

A scheduled function can trigger other scheduled functions

Only indirectly though (in runtime), due to late binding. So a schedule function publishes a value to a named location. There might not be a consumer of that value at the time of publishing. Later on you might later add the code to consume it, so the delivery to the next schedule function might occur much later. A synchronised function calling itself is recursion. A scheduled function could refer to its previous value, which is more like a fold over time. This is actually possible in observable by using the keyword "this", which refers to the prior value of the variable (docs).

When the definition is invoked, the value of this is the variable's previous value, or undefined if this is the first time the variable is being computed under its current definition. Thus, the previous value is preserved only when input values change; it is not preserved if the variable is explicitly redefined.

Some of your words imply scheduled functions are triggering other functions directly. This is not how it works in Observable runtime. The dataflow scheduler is like a trampoline that is managing invoking functions, and it manages gathering the data to populate the input args. The functions themselves jsut declare what inputs they want (what outputs of other functions they depend on). If those inputs do not exist, the function is not scheduled. If any of those inputs change, the function is called, and it emits a value, which is then used to chain onto other functions if the runtime deems necessary. The scheduled functions do not trigger each other! The runtime triggers them, and makes decisions about whether more functions need to be triggered or not based on the dependancy graph.

Wondering: would the Linda execution model be appropriate here? You get fan-out and parallel evaluation. But it's not lazy.

Oh great reference! It does seem related in that the scheduling and data passing is decoupled from function execution itself. I need to understand how they differ more.

I see the main difference in eager vs. lazy. In Linda, a computation is run as soon as (1) its inputs are available and (2) a processor is available. But I'd expect that this is a very reasonable model for interactive data flow computations, as long as computations run in the background and don't block the user interface.

To me

fan-out

means that each downstream node gets an exact copy of a message. UNIX doesn't do this - once an output is taken, no one else gets a copy (unless it was piped through

tee

first). Morrison mentions Linda when talking about FBP. I haven't studied Linda but I don't quite (yet?) see how copying fan-out would work in Linda. Fan-out is common in electronics design (electronics takes little nibbles of the message instead of doing full-blown copying ... the calculation of impedances is used to figure how much nibbling can be done before the circuit is adversely affected). AFAICT, the scheduler needs to know how many copies to make before deleting the original message.

@guitarvydas In Linda, a process can deposit any number of data items in the shared tuple space. That includes multiple copies of identical data, or copies tagged with different labels to make sure that different downstream processes pick it up.

Thanks! I wonder if that puts a new spin on what I think that PBP(0D) is about? Linda provides "assembler" operations for connecting units together (using tuples). Likewise, Python (et al, JS, Rust, ...) provide different kinds of "assembler" operations for connecting software units together (using queues and closures). I don't believe that thinking about connecting software units together at such a low level is good enough. I believe that we need to separate out the task of "making connections" into it's own paradigm (or HLL or whatever). Separating this aspect out of our code simplifies our task(s) by reducing the degrees of design freedom (simplicity is "the lack of nuance"). I think that "connection of software units" is an interesting paradigm, in its own right, in today's programming, i.e. internet, robotics, blockchain, NPCs, etc. In the 1960s, the giants took what they had - bags of transistors and vacuum tubes - and created new conceptual paradigms with them. IMO, just about all of today's programming languages are the same (synchronous, sequential). Can we combine them to derive new conceptual paradigms?

@guitarvydas I agree with that vision. We are focusing too much on low-level technology, and believe it would/should scale to larger complexity. It doesn't. What I like about Linda, beyond its immediate affordances, is its rather abstract design that allows many options for implementing the individual computational processes. It doesn't have to be all in one language, nor all in a shared memory space. These are good characteristics for component interfacing infrastructure.

@Konrad Hinsen I agree with your agreement. Ten Cent CPUs

The only chance I see for developing radically different compute technology is a completely new application domain, one which can't profitably reuse the existing tech stacks. Machine learning was close, but since it was still technically possible to run it on top of the Old World stack, that's what happened.

I would like to poke at this idea some more. I'd be interested in thoughts on what happened in the early days of reprogrammable electronic computers. FORTRAN was invented on a vacuum tube machine. Lisp was invented on a transistor machine. Both were invented before machines began using ICs. Both were invented something like 20+ years before the IBM PC was released. I doubt that Backus nor McCarthy had any idea that PCs were reasonably attainable and profitable.

The move from tubes to transistors to ICs was just a reduction in size and energy consumption, and an increase in speed. The programming model never changed. For short-term benefit it is always interesting to change as few aspects as possible when improving some technology. Put differently, re-use as much as you can. That's how we got stuck with early choices. And later ones, often bad. I remember a discussion, long ago on Twitter, about the long-term fate of programming languages. The one hypotheses that withstood many attempts at refuting it states that once a language has a critical size of user base, it will stay around forever. Where "forever" of course means no more than a few decades for such a young technology. Everything that once was popular is still supported by someone. COBOL? Compilers are still available. My proposal for a counterexample was PL/1, but someone tracked down a supported compiler for it.

more poking, a question disguised as a statement https://programmingsimplicity.substack.com/p/the-opcodes-of-tomorrow?r=1egdky