https://bytes.vadeai.com/how-one-clojure-function-destroyed-agent-framework-completely/

How Clojure's iteration Function Disrupts Agent Frameworks

Agent Framework Pitfalls

Traditional agent frameworks like CrewAI introduce significant complexity with configuration files, rigid agent definitions, and orchestration mechanics. They require developers to manage state, orchestrate tasks, handle errors, and manage resources, but still abstract away critical decisions, making debugging and customization difficult[1].

The Simplicity of iteration

Clojure 1.11 introduced the iteration function, which models any sequential, stateful process — including agentic workflows — far more simply than the framework approach. Its key parameters:

• step: Does the work (e.g., LLM call, tool execution)
• initk: Starting state (prompt, initial data)
• vf: Extracts the meaningful result from each step
• kf: Determines the next state for the following iteration
• somef: Decides if the workflow continues or stops

This aligns perfectly with agentic workflows: - step: agent action - initk: initial task/state - vf: extract agent output - kf: update agent context/state - somef: goal/termination checker[1]

Real World Example

A basic agent workflow with iteration in Clojure:

clojure (defn simple-agent-workflow [initial-prompt max-iterations] (let [llm-instance (create-llm-instance) step-fn (fn [{:keys [iteration prompt response]}] (when (< iteration max-iterations) (let [messages [(create-message :user prompt)] new-response (generate llm-instance messages) next-prompt (extract-next-task new-response)] {:iteration iteration :prompt prompt :response new-response :next-token {:iteration (inc iteration) :prompt next-prompt :response new-response}})))] (iteration step-fn :somef (fn [res] (some? res)) :vf identity :kf :next-token :initk {:iteration 0 :prompt initial-prompt :response {}})))

Production variants in Vade AI simply expand this pattern for live API streaming, logging, and complex branching, without introducing unnecessary abstraction or opaque state[1].

Benefits Over Frameworks

• Complete control: Every workflow step and state transition is transparent and customizable.
• Easy debugging: Print or inspect state at any moment; no special debugging tools needed.
• Flexible termination: Workflow can halt based on any custom logic, not just predefined callbacks.
• Resource efficiency: No framework overhead, predictable and low memory footprint.
• Streaming and real-time: Can process operations incrementally as LLM responses stream in, with immediate visibility for the user[1].
• Composability: Integrates natively with the rest of Clojure — no framework lock-in.

When to Use This Approach

The iteration pattern is ideal when you need:

• Custom agent behaviors
• Transparent workflows
• Performance optimization
• Complex branching or termination logic
• Deep integration with Clojure systems

Especially powerful for research and analysis, planning systems, validation pipelines, and unique business logic that standard frameworks struggle to express[1].

Key Takeaways

Frameworks often create more complexity than they solve. By embracing Clojure’s iteration, you implement agentic workflows with less code, greater clarity, and full control. This enables adaptive, resource-aware, and highly debuggable systems — proven at scale inside Vade AI[1].

Citations: [1] How One Clojure Function Destroyed Agent Framework Completely https://bytes.vadeai.com/how-one-clojure-function-destroyed-agent-framework-completely/

• Purpose of the Smalltalk project

  "The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone."

• Emphasis on enabling creativity via computing hardware and software.

• Focus of research areas

  "We have chosen to concentrate on two principle areas of research: a language of description (programming language) ... and a language of interaction (user interface)..."

• Programming language as an interface between mental models and hardware.

• User interface as a communication bridge between human and computer systems.

• Development process

  "Our work has followed a two- to four-year cycle that can be seen to parallel the scientific method."

• Iterative cycles aligned with hypothesis-experiment-validation.

• Two levels of communication

  "Explicit communication includes the information that is transmitted in a given message. Implicit communication includes the relevant assumptions common to the two beings."

• Distinction between explicit message content and shared implicit context.

• System complexity and dependencies

  "If there are N components in a system, then there are roughly N-squared potential dependencies between them."

• Larger systems exponentially increase chances for unwanted interactions.

• Design goal to minimize interdependence

  "...a computer language should be designed to minimize the possibilities of such interdependence."

• Isolation of components reduces complexity-related risks.

• Message-sending metaphor for modularity

  "The message-sending metaphor provides modularity by decoupling the intent of a message ... from the method used by the recipient to carry out the intent."

• Separates communication intent from implementation detail.

• Protection of structural information

  "All access to the internal state of an object is through this same message interface."

• Encapsulation enforced through message-based access.

• Reducing system complexity via grouping

  "The complexity of a system can often be reduced by grouping similar components."

• Logical grouping organizes structure and reduces mental overhead.

• Smalltalk’s class mechanism

  "A class describes other objects — their internal state, the message protocol they recognize, and the internal methods for responding to those messages."

• Classes define state, protocol, and behavior for their instances.

• Instances and meta-classes

  "Even classes themselves fit into this framework; they are just instances of class Class..."

• Meta-level reflection: classes are themselves objects.

• Nature of a user interface

  "A user interface is simply a language in which most of the communication is visual."

• UI framed as a predominantly visual language.

• Role of esthetics in UI

  "Because visual presentation overlaps heavily with established human culture, esthetics plays a very important role..."

• Design aesthetics influence user understanding and comfort.

• Flexibility in UI design

  "Since all capability of a computer system is ultimately delivered through the user interface, flexibility is also essential here."

• UI adaptability is critical for capability delivery.

• Object-oriented principle enabling UI flexibility

  "An enabling condition for adequate flexibility of a user interface can be stated as an object-oriented principle."

• OOP structures support adaptable interface design.

Summary of the Discussion on SwiftUI: Understanding Identity, Lifetime, and Dependencies

1. Introduction to SwiftUI and Its Declarative Nature

2. SwiftUI operates as a declarative UI framework where you describe UI states, and the framework manages their actualization. "That means that you describe what you want for your app at a high level, and SwiftUI decides exactly how to make it happen."

3. Understanding Identity in SwiftUI

4. SwiftUI views have identity to distinguish elements as the same or different across updates, critical for UI transitions and state management. "Identity is how SwiftUI recognizes elements as the same or distinct across multiple updates of your app."

5. Concept of View Identity Using Practical Examples

6. Demonstrated using the "Good Dog, Bad Dog" app example, explaining how identity influences view transitions and behavior. "That distinction actually matters a great deal because it changes how our interface transitions from one state to another."

7. Explicit vs. Structural Identity

8. Discussed two types of identity:

   • Explicit identity is assigned using identifiers like tags. "Explicit identity is powerful and flexible, but does require that someone, somewhere keeps track of all those names."
   • Structural identity is derived from the view's type and position in the hierarchy. "SwiftUI uses the structure of your view hierarchy to generate implicit identities for your views so you don't have to."

9. Role of Lifetime in SwiftUI

10. Explained how SwiftUI manages the life cycle of views and data by associating views' identity over time. "Lifetime is how SwiftUI tracks the existence of views and data over time."

11. Impact of Dependencies on UI Updates

12. Dependencies are inputs like state variables or environmental settings that trigger UI updates when they change. "Dependencies are how SwiftUI understands when your interface needs to be updated and why."

13. How SwiftUI Manages State and Identity

14. Discussed how State and StateObject help preserve state across the lifetime of views tied to their identity. "State and StateObject are the persistent storage associated with your view's identity."

15. Advanced Use of Identity with SwiftUI's ForEach

16. ForEach leverages identifiers for efficient updates and animations, showing how identity can impact performance and correctness. "Choosing a good identifier is your opportunity to control the lifetime of your views and data."

17. Best Practices for Using Identity

18. Emphasized the importance of stable and unique identifiers to improve performance and prevent state loss. "An identifier that isn't stable can result in a shorter view lifetime."

19. Troubleshooting and Optimization Techniques

    • Discussed common pitfalls with AnyView and alternatives using view builders to optimize SwiftUI’s understanding and performance. "Having too many AnyViews will often make code harder to read and understand."

Key Takeaways

• Identity, lifetime, and dependencies are core concepts that determine how SwiftUI manages and updates the UI.
• Effective management of these properties can significantly enhance the performance and predictability of SwiftUI applications.
• Developers are encouraged to use stable and unique identifiers and understand the implications of explicit and structural identities on their code.

This summary focuses on the critical aspects discussed in the tech talk, ensuring a comprehensive understanding of the primary themes and practical implications for SwiftUI developers.

• Introduction

• Eric Normand introduces himself and the purpose of the talk: "The title of this talk is building composable abstractions...to develop a process to do that and also I'd like to start a discussion about how we can do that better."

• Importance of Abstractions

• Abstractions are critical for creating complex applications from small, simple problems. "A lot of people are able to solve small problems like Fibonacci...when they finally want to create an app...they don't know how to take the tools that they've learned and turn them into software."

• Map of the Talk

• The talk covers the importance of abstractions, the process of developing them, an example, and concluding thoughts. "Here's sort of the map of the talk: why focus on abstractions, the process, an example abstraction, and concluding thoughts."

• Why Focus on Abstractions?

• Refactoring introduces the distinction between the behavior of the code and its implementation. "In the general industry we now have this idea that there's a difference between the behavior of the code and the actual implementation."

• Example of Newtonian mechanics replacing Aristotelian physics illustrates that some systems can't be refactored but need to be redesigned from scratch. "You can't refactor Aristotle into Newton."

• Objectives of the Abstraction Process

• The process should produce good, Newtonian-style abstractions, be iterative, accessible to all, and foster collaboration. "It has to consistently produce good abstractions...an iterative process...anyone can do it...fosters collaboration."

• Example of Vector Graphics System

• Normand uses a simple vector graphics system as an example to demonstrate the process of building abstractions. "This is the example we're going to develop: a vector graphics system."

• Step 1: Physical Metaphor

• Choose a metaphor to capture important information. "The idea behind this is to choose a metaphor that will capture the important information in your program."

• Shapes and construction paper is chosen as the metaphor. "Shapes and construction paper...I cut out shapes like rectangles and ellipses...and then I can move them around."

• Step 2: Meaning Construction

• Convert physical intuition into precise mathematical language, focusing on the interface. "We're going to be focusing on the interface right now...precise mathematical language."

• Definitions in Clojure for different components like color, shape, and transformations. "We're defining two types here: cutout and shape...defining a function that takes a cutout and returns a shape."

• Importance of preserving shape and color, overlay order, and rotation and translation independence. "Preservation of shape...preservation of color...overlay order...rotation and translation independence."

• Step 3: Implementation

• Implement the system based on the constructed meaning, ensuring it can be refactored to different requirements like SVG output. "Implementation...we already know what to do...refactor from quill to SVG."

• Summary of Process

• Use a physical metaphor, define the parts and their relationships in mathematical language, and refactor for implementation details. "Use a physical metaphor...define the parts and their relationships...refactor to get all the meta properties."

• Corollaries for the Process

• Know your domain, constructs, and refactoring techniques. "Know your domain...know your constructs...know your refactoring."

• Conclusion

• Encourages further learning and provides resources. "Please go to my site...download the slides...sign up for my newsletter."

• ClojureScript has excelled in standard UI patterns but now aims to harness modern browser APIs for high-performance use cases.

"The majority of Clojurescript application development and community discussions seems to be focused on improving standard UI implementation patterns and the general workflow of how we can build web applications better, easier and faster." (Medium)

• The workshop’s goal was to probe ClojureScript’s internals, identify bottlenecks, and introduce technologies like WebGL, WebRTC, WebWorkers, and Emscripten.

"So for this workshop I chose to look more below the surface of Clojurescript, analyze problem areas, examine possible optimization strategies and above all introduce people to a number of modern web technologies (WebGL, WebRTC, WebWorkers, Emscripten), techniques & tools offering possible routes to use the language in a sound and elegant way to work with these features." (Medium)

• A six-step implementation of Conway’s Game of Life, from naive to optimized, achieved a speedup from 10,840 ms to 16.5 ms per frame (\~650× faster) on a 1024×1024 grid.

"Six implementations of Conway’s Game of Life — from naive (but idiomatic & slow) to optimized Clojurescript using typed arrays and direct pixel manipulations (10,840 ms / frame vs 16.5 ms / frame = \~650× faster for a 1024×1024 grid)." (Medium)

• A compile-time macro version of get-in eliminated temporary vector allocations and reduce calls, boosting lookup speed from 205.18 ns to 43.61 ns (\~5× faster).

"Benchmarking this example with criterium under Clojure (which has somewhat different/faster protocol dispatch than in Clojurescript), the macro version results in 43.61ns vs 205.18ns for the default get-in (\~5× faster)." (Medium)

• Switching from nested vectors to a flat 1D vector enabled nth-based indexing (\~6× speed-up), before Typed Arrays and loop-based pixel updates removed millions of function calls for the full \~650× gain.

"The more obvious improvement to speed up the simulation was using a flat 1D vector to encode the grid and calculate cell indices for the 2D coordinates ... gain a \~6× speed up ... Since all our data ... are stored in typed arrays ... and altogether gained a \~650× speedup compared to the original." (Medium)

• Adopting transduce for neighbor counting proved \~15–20% slower than map & reduce, highlighting that idiomatic functions can sometimes underperform.

"One of the intermediate steps ... was using transduce instead of map & reduce to compute the number of alive neighbor cells, however this ended up actually being \~15–20% slower in this case." (Medium)

• Effective WebGL programming demands deep knowledge of geometry, linear algebra, the OpenGL state machine, GPU pipelines, and GLSL, making it daunting for newcomers.

"To anyone interested in directly utilizing the GPU in the browser, WebGL is a huge & fascinating topic, but it can also be very daunting for newcomers to graphics programming, since efficient use of it requires a multitude of prerequisite knowledge and terminology about 2D/3D geometry, linear algebra, spatial thinking in multiple spaces (coordinate systems), low-level data organization, the OpenGL state machine ... GPU processing pipelines, knowledge of the GLSL shading language, color theory etc." (Medium)

• The thi.ng/geom library employs Clojure maps for semi-declarative OpenGL/WebGL buffer and shader specifications, while preserving explicit control over the GL state machine.

"The thi.ng/geom library takes a semi-declarative approach to working with OpenGL/WebGL in that it’s extensively using Clojure maps to define various geometry and shader specifications, which are then compiled into the required data buffers & GLSL programs ... but at no point is it hiding the underlying layer, giving advanced users full control over the GL state machine." (Medium)

• Shadergraph addresses GLSL code reuse by offering transitive dependency resolution, a library of common functions, compile-time minification, and metadata extraction for tooling.

"To address this in Clojurescript from early on, we can use the thi.ng/shadergraph library, which provides us with: a transitive dependency resolution mechanism for GLSL code ... a growing library of pure, commonly used GLSL functions (lighting, color conversion, matrix math, rotations, effects etc.) ... and a basic compile-time shader minifier ... Clojure meta data extraction of the defined GLSL functions ..." (Medium)

• A hands-on WebRTC demo showed how to stream a camera feed into Shadertoy-style WebGL shaders for real-time video FX processing.

"I prepared a small example combining a WebRTC camera stream with Shadertoy-like WebGL image processing using a bunch of effect options." (Medium)

• True parallelism in the browser comes from WebWorkers—unlike core.async’s simulated concurrency—and relies on isolated modules, message passing, and transferable ArrayBuffers for efficient data sharing.

"However, the currently only way to obtain real extra compute resources of a multi-core CPU in JavaScript is to use WebWorkers ... WebWorker code needs to be loaded from a separate source file and can only communicate with the main process via message passing. By default, the data passed ... is copied, but some types (e.g. ArrayBuffers) can also be transferred ..." (Medium)

• Emscripten’s LLVM-based compiler targets asm.js (and soon WebAssembly), enabling C/C++ modules to outperform idiomatic ClojureScript for math-heavy and mutable-data tasks.

"Emscripten ... a LLVM-based transpiler for C and C++ to asm.js ... the resulting asm.js code almost always performs noticeably faster than the Clojurescript version ... With WebAssembly on the horizon, it’s maybe a good time to invest some time into some “upskilling” ..." (Medium)

• The workshop’s capstone was a C-based 3D particle system demo, using Emscripten’s JavaScript ArrayBuffer heap and typed arrays to pack 36-byte particle structs tightly and avoid copying overhead.

"For the final exercise ... we implemented a simple 3D particle system in C, compiled it with Emscripten and learned how to integrate it into a Clojurescript WebGL demo ... The Emscripten runtime emulates the C heap as a single, large JS ArrayBuffer ... Each particle only takes up 36 bytes ... all particles in this array are tightly packed ..." (Medium)

"one of the best critiques of modern AI design comes from a 1992 talk by the researcher Mark Weiser where he ranted against “copilot” as a metaphor for AI."

• Weiser’s critique of the “copilot” metaphor for AI is foundational to this argument.

"He gave this example: how should a computer help you fly a plane and avoid collisions?... The agentic option is a 'copilot' — a virtual human who you talk with to get help flying the plane. If you’re about to run into another plane it might yell at you 'collision, go right and down!'"

• The “copilot” model is described as an interactive assistant giving explicit instructions or alerts.

"design the cockpit so that the human pilot is naturally aware of their surroundings. In his words: 'You’ll no more run into another airplane than you would try to walk through a wall.'"

• Weiser advocates for UIs that naturally augment human situational awareness, eliminating the need for explicit assistant intervention.

"Weiser’s goal was an 'invisible computer'—not an assistant that grabs your attention, but a computer that fades into the background and becomes 'an extension of [your] body.'"

• The ultimate aim: seamless, ambient support that integrates with human perception.

"the Head-Up Display (HUD), which overlays flight info like the horizon and altitude on a transparent display directly in the pilot’s field of view."

• The HUD is presented as a practical realization of Weiser’s concept: information is ambiently present, not actively disruptive.

"A HUD feels completely different from a copilot! You don’t talk to it. It’s literally part invisible—you just become naturally aware of more things, as if you had magic eyes."

• HUDs differ fundamentally from copilots by passively enhancing awareness instead of communicating via dialogue.

"spellcheck isn’t designed as a 'virtual collaborator' talking to you about your spelling. It just instantly adds red squigglies when you misspell something! You now have a new sense you didn’t have before. It’s a HUD."

• Spellcheck is given as a familiar analogy for AI-as-HUD: subtle, always-on augmentation of cognition.

"use AI to build a custom debugger UI which visualizes the behavior of my program!... With the debugger, I have a HUD! I have new senses, I can see how my program runs."

• Custom visual UIs for debugging exemplify HUD-like designs in AI-driven tools, enabling deeper understanding rather than focusing on transactional automation.

"Both the spellchecker and custom debuggers show that automation / 'virtual assistant' isn’t the only possible UI. We can instead use tech to build better HUDs that enhance our human senses."

• Non-agentic, perception-extending UI paradigms are positioned as powerful, sometimes preferable alternatives to assistant-like AI.

"I don’t believe HUDs are universally better than copilots!... anyone serious about designing for AI should consider non-copilot form factors that more directly extend the human mind."

• While not dismissing assistants, the author stresses the importance of exploring HUD-like, sense-extending UI for ambitious AI design.

"routine predictable work might make sense to delegate to a virtual copilot / assistant. But when you’re shooting for extraordinary outcomes, perhaps the best bet is to equip human experts with new superpowers."

• The conclusion is a nuanced tradeoff: assistants excel in predictable routines, but empowering human expertise requires HUD-style augmentation.

• Core Concept: The paper introduces Universalis, an AI-first, program-synthesis framework and language designed to be read by human knowledge workers but generated by AI models (LLMs). > "this paper outlines the high-level design of an AI-first, program-synthesis framework built around a new programming language, Universalis, designed for knowledge workers to read, optimized for our neural computer (Automind) to execute, and ready to be analyzed and manipulated by an accompanying set of tools."

• Design Philosophy: Universalis prioritizes readability for domain experts over writability for professional developers, making code intuitive and easier for AI to generate accurately. > "Unlike traditional programming languages, which prioritize syntax and structure optimized for writing by professional developers, Universalis is designed with the philosophy that code should be read by domain experts and written by machines."

• Structure and Syntax: The language syntax is analogous to "literate Excel spreadsheet formulas," embedding logical predicates inside [...] hedges surrounded by natural language explanations. > "Think of Universalis clauses as some kind of literate Excel spreadsheet formulas such as [@D is (@S-@B)] over named tables, or relations, enclosed in hedges surrounded by natural language explanation, where cells in the table correspond to variables such as @B, @S, and @D..."

• AI Safety through Contracts: It natively embeds pre- and post-conditions (contracts) into the language, providing a formal and extensible method to ensure the logical correctness and safety of AI-generated computations. > "By embedding pre- and post-conditions directly into the language semantics, Universalis provides a pragmatic and extensible method for implementing AI safety."

• Readable Conditionals: Conditional logic is structured as simple checklists, making decision-making processes clear and intuitive for human readers while still being executable by the AI interpreter, Automind. > "By structuring conditionals as checklists and explaining each branch in natural language, Universalis ensures that the logic is clear and intuitive for the human reader, while the Universalis interpreter Automind can still recognize them as control-flow decision points..."

• Loopless Bulk Processing: The framework handles operations on data collections via implicit broadcasting, similar to NumPy or modern Excel, removing the need for explicit loops that can be a distraction for non-programmers. > "In Universalis, this is handled by implicitly broadcasting operations on single elements to collections, similar to how NumPy or Pandas operate in Python or how dynamic array formulas and spilled array behavior in Excel allow for loopless programming."

• Accessible Data Queries: It features query comprehensions that use a structured, natural-language style for complex data operations like filtering and aggregation, making them more approachable than traditional query languages like SQL. > "By focusing on a structured natural-language approach for comprehending queries, Universalis ensures that even those with minimal experience in programming can perform advanced data manipulations."

• Simplified Data Extraction: The language includes powerful pattern-matching capabilities, allowing users to easily extract specific information from complex, nested data structures like JSON without writing complicated parsing code. > "This is where Universalis excels with its pattern-matching capability. Users can simply specify the patterns they want to match within the JSON structure..."

• Intentional Representation: Rather than generating final, concrete syntax, the Automind system produces an abstract, intentional representation of the user's intent, which can then be rendered into different formats. > "Since Universalis programs are trying to capture the high-level intent of the user as well, Automind does not generate the concrete syntax seen in the examples so far but instead creates an abstract, intentional representation of the Universalis code..."

• Minimalist Language Design: The language is intentionally kept minimal, focusing on core features like sequential composition, implicit looping, and nested dataframe queries to maintain readability and compatibility with formal verification tools. > "For Universalis, we intentionally keep the language minimal, focusing on sequential composition, implicit looping by lifting singleton operations over collections, and fully nested dataframe queries."

The Utopian Vision of Smalltalk

Smalltalk as a vision, not just a language:

“Smalltalk is a vision of the world as it should be, not necessarily as it is but the way it's supposed to be.”

A future imagined where Smalltalk has won:

“As we all know, Smalltalk has won and a new age, a Utopia is upon us.”

Language and System Design Philosophy

Smalltalk wasn’t originally a full language, but a live object system:

“Small Talk was never a programming language it was a programming system… there is no way to express a class as a linguistic construct.”

Early Smalltalk used a clever hack for class definition:

“Yes a class just happens to be this object that knows how to make other objects… but it is a hack and it's important to recognize that.”

Textual syntax was later added to enable integration with tools like source control:

“We came up with an actual textual Syntax for Smalltalk… interacting with Source Control Systems became really easy.”

Resolving Dialect & Library Fragmentation

Overcoming dialect fragmentation:

“We realized all this and came together to define a Common Language.”

Library standardization was harder but necessary:

“The situation with the libraries was a bit of a mess… but we realized that the benefits of having a standard… outweighed [vendor-specific advantages].”

Reflection and Mirrors

Original reflection API mixed base and meta levels:

“These class objects… are playing two roles… that architecture was replaced with mirrors.”

Mirrors cleanly separate base-level and meta-level:

“We clearly separated the base level and the meta level… that has all kinds of advantages for deployment, distribution, security.”

Mobile and UI Integration

Early design enabled seamless remote mobile dev:

“We were already running images that could manipulate other images… fantastic development experiences almost immediately.”

Binding to native UI was essential for adoption:

“We realized early on that we should… bind to Native stuff… they run natively on all the platforms.”

Tool evolution toward navigation-based UIs:

“We wouldn’t dream of using the 40-year-old design of a browser… we evolved our tools.”

Foreign Function Interfaces and “Alien” Objects

Unified model for system integration:

“These things outside of Smalltalk… they're second class objects… but they were objects.”

Alien objects replaced clunky primitive syntax:

“We didn’t need these hacky things like the Primitive syntax… everything was an object.”

Modularity and Deployment

Object ecosystems are difficult to transfer without structure:

“Fish and objects live in an environment… if you want the fish to be transferred and survive you have to bring its friends.”

Deployment as serialized object graphs:

“We realized that an application… was also an object… we just had to serialize it.”

Avoided “extraneous concepts like packages”:

“We used the concepts of classes and objects to solve our distribution and modularity problems.”

Optional Typing and Pluggable Type Systems

Types as useful but not mandatory:

“Types can be useful at times… we certainly don’t want them telling us how to live.”

Static analyses used for optimization:

“Extra information helps… we could have multiple analyses that didn’t conflict.”

Web and Live Environments

Ahead of the curve with web-based IDEs:

“We built complete programming environments with all their features running in the browser long before anyone else.”

True liveness beyond class browsers:

“We never want to look at Dead code… environments evolved to show Exemplar values.”

Integration of ML into the environment:

“We started to incorporate [ML] in our live programming environments.”

Performance and JIT

Ahead of AOT compilation trend:

“We had systems that would… have a database of compiled methods… ready to apply them instantly on Startup.”

Addressed Apple’s no-JIT constraint early:

“We already had techniques for that… just deploy that and turn off the jit.”

Security through Object Capabilities

Reinvention of capability-based security:

“The capability you want is an object… the only damage you can do is through a message send.”

Enforced encapsulation and access control:

“We needed an access control model… public, protected, and private messages.”

Education and Longevity

Revolutionary ideas in education:

“Smalltalk had these ideals of Education from day one.”

Avoided student drop-off by staying dominant:

“We short circuited [students leaving] because of all our previous successes.”

Hypertext-based live documentation:

“We could put live widgets embedded in text long before the worldwide web.”

Satirical Punchline

Entire talk is satirical utopia:

“This is the world as it should be… imagine if the world wasn’t like the way I described it…”

Ironic jab at real-world language use:

“Think if one of the world’s largest… sites ran on PHP… we all know Facebook runs on Smalltalk.”

• Core Concept: Missionary is a Clojure library for supervised data flow programming, providing a universal language for handling asynchronous event sources in both frontend and backend applications.

  "the missionary is a closure library for supervised data flow programming so this is a common language to manipulate asynchronous event sources um that you can use from anywhere in the stack"

• Problem Addressed: The library tackles the difficulty of resource management in concurrent programming, where resources (like circuits, UI components, or threads) have a life cycle that must be explicitly managed.

  "this is in my "pinion the main reason why concurrency is hard a resource is an object with a Time dimension because it has a Time Dimension it also has a life cycle"

• Limitations of Garbage Collection: Traditional garbage collection is insufficient for this problem due to bidirectional references between producers and consumers, leaving the producer unaware if a resource is still needed.

  "garbage collection doesn't help the reason why it doesn't fa is because um the reference to the resource is B directional there is it is referenced by the consumer and it is also referenced by the producer"

• Proposed Solution: The solution is explicit structure, which enables automatic, demand-driven resource management by binding the resource's allocation lifespan to the period when its data is actually required.

  "what we want to achieve is to bind um the time span where the resource is allocated to the time span when the data produced by this resource is actually needed so it's demand WR resource maintenance"

• DAG Supervision for Shared Resources: For complex scenarios with shared resources, missionary moves from a simple tree supervision model to a Directed Acyclic Graph (DAG) supervision model, where a resource can have multiple supervisors.

  "so now the supervision uh three is not a three anymore it's a dag has a shared resource here"

• Core Supervision Policy: The policy for managing shared resources is "allocate on first use and dispose on last," elegantly summarized by the real-world analogy of "the last one turns of the lights."

  "the last one turns of the lights uh so this is a dck for the real world"

• Improving on Functional Effect Systems: Missionary was conceived to improve upon functional effect systems like Rx by properly implementing continuous time, which requires synchronicity semantics to avoid event-ordering issues.

  "the IDE was uh continuous time is a good idea...the problem is um well at this time the popular FX system in Java was RX and RX doesn't properly Implement continuous time uh so the reason why it doesn't properly Implement continuous time is because it has no synchronicity semantics"

• Glitch-Free Propagation: A key innovation is a bidirectional flow protocol and a propagation algorithm that uses a priority queue to traverse the dependency graph, ensuring atomic updates and preventing inconsistent intermediate states, known as "glitches."

  "to solve the glitch problem...the string protocol doesn't support that and so therefore the idea is can we have our and El two"

• Bidirectional Flow Protocol: The protocol allows a producer to signal that its state is invalidated before a new value is computed, enabling a two-phase process of invalidating dependent nodes and then recomputing them in the correct order.

  "bidirectional IPC is what we need to implement uh back pressure and solve the git problem that I talk just before"

• Successful Validation: The model has been battle-tested at scale through its use in Electric Clojure for serious business applications, proving its robustness and success in managing complex, dynamic, and massively concurrent UIs.

  "that's a success we've been validating that model at scale with electric closure we we've been working on that for more than two years now uh we've been using electric closure for serous business application and this algorithm just well we we experience really no problem with that"

• Core Thesis: Functional programming is an excellent fit for creating reactive or "situated programs" that must continuously interact with their environment, contrary to some earlier views.

  "we're going to use functional programming to make situated programs um i'm going to show you that rich is wrong about it functional programming is actually a very good fit for situated programs and we're going to see why."

• Functional Effect Systems: The fundamental principle is to describe computations as values rather than executing them immediately. An effect is a description of an action to be performed.

  "an effect is a description of something to be done that's the essence of functional programming instead of doing we describe."

• Core Operators: The system is built on operators like pure for turning any value into an effect and bind for composing effects sequentially.

  "pure takes an arbitrary value turns that into an effect... blind is about sequential composition so we want to do something and then do something else."

• Concurrency and Supervision Trees: Concurrent operations are managed within a process tree. This structure is critical for handling failures and managing resources. When one parallel process fails, its siblings must be canceled to prevent wasted resources.

  "what we get is not a list of process it's a tree of processes and that's that's very important... when it happens you want the error to be processed by another process and this process is the supervisor."

• Structured Concurrency: Functional programming naturally enforces a well-defined supervision hierarchy, where combinators also define the supervision strategy, preventing orphaned processes.

  "in functional programming it's impossible to do that so you get structural concurrency by default that is you are forced to build your program in such a way that the supervision trees is properly structured."

• Streams vs. Signals: The talk distinguishes between two types of long-lived effects:

• Event Streams: A discrete series of events where each event is critical and must be processed. They require backpressure to prevent data loss. > "an event stream is not defined when events don't happen it's discrete time... losing an event is really bad... to represent stream's effect the effect representation must implement by pressure."

• Signals: A continuous value representing the state of an identity (e.g., mouse position). They are always defined, only the latest value matters, and they benefit from lazy sampling. > "the signals represent the state of an identity... at any point in time you can take a snapshot... only the latest value matters... if you want to represent signals as effects you won't play something."

• Missionary Library: A Clojure library that implements these concepts, providing operators for two effect types: tasks (for single values) and flows (for multiple values).

  "this is mission array it's a closure library that works enclosure and closure script and it's a collection of purely functional operators that work on effects and there's two kinds of effects there is tasks and flows."

• Language Extensions: Missionary avoids "callback hell" through language extensions that provide a functional version of async/await, allowing for more readable, sequential-looking code that is internally transformed into callbacks.

  "the solution is to extend the language so we we extend closure with another operator that's the idea of async await but now it works in functional effects."

• Awaiting Flows: A powerful and unique feature is the ability to "await" a flow (a stream of multiple values). This reruns a computation for each new value while automatically canceling the previous computation if it's still running.

  "if we get a new value of the state and the previous value is still being computed we want to interrupt this this previous computation and start the new one you we are only interested in the latest value so we want to discard the previous computation."

• Key Differentiators: Missionary stands out due to its powerful language extensions (an expressive alternative to monads) and its first-class support for both discrete-time (streams) and continuous-time (signals) effects.

  "what makes it unique is language extensions uh it's alternative to monad it's as much as powerful but it's much more expressive... discrete versus continuous time we need both."

• Computational Challenges:

  • We lack effective computational methods: "i think we actually have the foggiest idea how to compute very well."
  • Importance of fast, efficient processes: "it took only 100 milliseconds... we don't understand how to do."

• Genomic Complexity:

  • Human genome's complexity and flexibility: "with a small change to it you make a cow instead of a person."
  • High-level language for biological processes is unknown: "what I'm interested in is the high-level language that's necessary to do things like that."

• Programming Evolution:

  • Legacy of programming assumptions based on scarcity: "all of our sort of intuitions from being programmers have come from a time of assuming a kind of scarcity."
  • Current abundance of resources shifts the focus: "memory is free, computing is free."

• Security and Correctness:

  • Traditional concerns of correctness and security are secondary: "people worry about correctness... is it the real problem? maybe... most things don't have to work."
  • Evolution and adaptability of code are crucial: "we spend all our time modifying existing code."

• Programming Constraints:

  • Early decisions in programming constrain future changes: "we make decisions early in some process that spread all over our system."
  • Need for flexibility in modifying systems: "organize systems so that the consequences of decisions we make are not expensive to change."

• Generic Operators and Extensions:

  • Dynamically extensible operations: "dynamically extend things while my program is running."
  • Symbolic algebra as an extension of arithmetic: "expand this arithmetic on functions... it's a classical thing people can do in algebra."

• Propagators and Parallelism:

  • Concept of propagators for parallel computation: "propagators are independent little stateful machines."
  • Parallelism and monotonic information merging: "we don't actually put values in these cells we put information about a value in a cell."

• Truth Maintenance Systems (TMS):

  • Maintaining and improving data consistency: "truth maintenance systems... maintain the best estimates of what's going on."
  • Dependency-directed backtracking for efficient problem-solving: "automatically find for me the consistent sub consistent sub the sub world views that are consistent."

• Historical and Educational Insights:

  • Historical evolution of computation: "when I started computing in 1961... the total amount of memory is probably about 10 kilobytes."
  • Educational gaps between theory and practical engineering: "what we taught the students wasn't at all what the students actually were expected to learn."

• Vision for the Future:

  • Future computing systems must be inherently parallel, redundant, and flexible: "future... computers are so cheap and so easy to make... they can talk to each other and do useful things."
  • Importance of evolving current computational thinking: "we have to throw away our current ways of thinking if we ever expect to solve these problems."

• Summary and Call to Action:

  • Main challenge is evolvability, not correctness: "problem facing us as computer engineers is not correctness it's evolvability."
  • Proposals include extensible operations and new architectural paradigms: "extensible generic operations... a more radical proposal is maybe there are freedoms that we can unlock by throwing away our idea of architecture."

Bet on context engineering for rapid iteration.

“Manus would bet on context engineering. This allows us to ship improvements in hours instead of weeks, and kept our product orthogonal to the underlying models: If model progress is the rising tide, we want Manus to be the boat, not the pillar stuck to the seabed.”

Design around the KV-cache to optimize latency and cost.

“If I had to choose just one metric, I'd argue that the KV-cache hit rate is the single most important metric for a production-stage AI agent.”

Mask tool availability rather than removing tools mid-iteration.

“Rather than removing tools, it masks the token logits during decoding to prevent (or enforce) the selection of certain actions based on the current context.”

Use the file system as scalable, persistent context.

“That's why we treat the file system as the ultimate context in Manus: unlimited in size, persistent by nature, and directly operable by the agent itself.”

Manipulate attention through recitation of objectives.

“By constantly rewriting the todo list, Manus is reciting its objectives into the end of the context. This pushes the global plan into the model's recent attention span, avoiding ‘lost-in-the-middle’ issues.”

Keep errors in the context to enable adaptive behavior.

“One of the most effective ways to improve agent behavior is deceptively simple: leave the wrong turns in the context. When the model sees a failed action—and the resulting observation or stack trace—it implicitly updates its internal beliefs.”

Avoid over-few-shotting by injecting controlled diversity.

“The fix is to increase diversity. Manus introduces small amounts of structured variation in actions and observations—different serialization templates, alternate phrasing, minor noise in order or formatting.”

Context engineering defines agent performance and scalability.

“Context engineering is still an emerging science—but for agent systems, it's already essential. … Engineer them well.”

• Abstractions are based on assumptions

• We assume some properties which allows us to neglect them.

• The more we assume the simpler our abstraction.
• The less we assume, the more we need to address, and the more complex our abstraction becomes.

• Summary of Tech Talk on Software Abstractions and Model Assumptions

• Overview of Book on Closure: The speaker discusses a book written to serve as a comprehensive second book on Closure, focusing on choosing the appropriate parts of the language based on different programming situations.

• "the goal of this book was to be the best second book that you could read about closure where you already know what you can do with the language but you don't know why you would use one part of the language versus another to solve a particular problem."

• Importance of Names in Programming: Emphasizes the significance of names in software, noting the lack of deep discussion in education and practice, leading to debates often decided by authority rather than merit.

• "the first chapter that I wrote was about names and for all that we pay a lot of lip service to names being one of the two hard problems in software we don't really spend a lot of time confronting them head-on."

• Challenges in Defining "Abstractions": Discusses the difficulty in defining and writing about abstractions in software, leading to extensive research without writing progress.

• "things were going well until I tried to do the same for abstractions right what makes an abstraction good what makes it bad if it's bad how do we make it better."

• Different Interpretations of "Abstraction": Highlights the two distinct concepts the term "abstraction" covers in computer science, demonstrated by church numerals and cons cells in LISP.

• "we use the word abstraction to mean two fairly distinct concepts and I think this is demonstrated by two ideas that are very much at the heart of lists which are church numerals and cons cells."

• Timelessness vs. Practicality in Abstractions: Examines how some abstractions remain relevant due to their theoretical utility, while others fall out of favor due to practical inefficiencies in changing environments.

• "the difference between these things is not what they are but how we judge them one of them is timeless right it is judged against a standard which does not change but the other one is judged against lis very rapidly changing sort of standard."

• Role of Environment in Software Abstractions: Argues that understanding the environment and its assumptions is crucial in defining and evaluating abstractions.

• "when we define an abstraction specifically a software abstraction we have to have three parts we have to have the model which is the thing that we implement we have to have the interface which is a means of interacting with that model and we need to have the environment which is everything else."

• Adaptability and Principle in Software Systems: Proposes that effective software systems combine principled and adaptable components, ensuring robustness and flexibility.

• "if we have a sort of an adaptable abstraction that contains as little principal pieces we can see that change comes from the outside and as change comes in from the outside these principled fragile pieces are protected."

• Complex Adaptive Systems and Software: Suggests modeling software systems on complex adaptive systems to manage change effectively through principled and adaptable components.

• "these sorts of systems right where you have sort of an adaptable whole and principled subcomponents exist at every level of the world this is empirically a very successful strategy."

• Conclusion and Encouragement to Engage with Concepts: Concludes by encouraging the audience to read the book and engage in discussions about the concepts, highlighting the evolving understanding of software abstractions.

• "if this was interesting to you I really encourage you to read my book I think that it's much more clearly articulated there than it has been on this stage but if you do read it right I really encourage you to talk to me about it."

• Introduction to Queues:
• "Queues really are pretty simple, right? You have a producer that enqueues messages, you have a consumer that dequeues messages."
• "Something that is maybe non-obvious is that in addition to the act of enqueuing being a side effect... we get back to just confirmation that it was added."

• "Queues are a way of dealing with actions... we of course are in the business of making computers do things."

• Core.async Channels and Queue Mechanisms:

• "A core.async channel has not one but three queues: a buffer that holds the messages, a puts queue where producers that are trying to add to a full buffer will wait, and a takes queue where consumers that are trying to take messages from an empty buffer will wait."

• "The blocking queue under the covers looks a great deal like core.async... it has a buffer that holds the messages... it’s just a place for threads to park themselves."

• Ubiquity and Importance of Understanding Queues:

• "Queues are ubiquitous; they’re everywhere and it sort of behooves us on some level to understand them."

• "The reason that queues are so ubiquitous is because they separate what we want to have happen from when it happens."

• Closed vs. Open Systems:

• "A key distinction in queuing theory is between closed and open systems."
• "A closed system is where as we produce something, we must wait for the consumer to complete it before producing something else."

• "Many of the systems that we build are open systems where there is no coordination... requests are processed as they come in, often before we’re ready."

• Simulation of Queue Behaviors:

• "Tasks are arriving according to this exponential distribution... the complexity of the tasks is not very well modeled by an exponential distribution."

• "As the system becomes unstable... it just sort of takes off like a rocket... what happens when a queue grows out of control."

• Dealing with Queue Overload:

• "Unbounded queues are fundamentally broken because it puts the correctness of your system in somebody else’s hands."

• "We cannot have our strategy for dealing with too much data be to hold onto it and hope for the best."

• Strategies for Managing Excess Data:

• "When too much data shows up, we have only three strategies: drop the data on the floor, reject the data, or pause the data."
• "Dropping the data is valid for problems where newer data makes older data obsolete."
• "Rejecting the data... is what you see when you go to an overloaded website and it returns a 503."

• "Pausing the data or exerting back pressure... is often the most neutral choice we can make."

• Benefits of Buffers and Back Pressure:

• "Buffers allow us to make sure that our throughput is more stable and going at a higher rate."

• "Back pressure enacting and retracting is not free... buffers help with the overall throughput at the expense of latency."

• Best Practices for Queue Management:

• "Always plan for too much data... using back pressure wherever possible."
• "Buffers are useful for constant throughput but should be used where absolutely necessary."

• "Avoid composing buffered queues wherever possible as each additional buffer magnifies the results of the next."

• Application Example: Durable Queue and S3 Journal:

• "I end up writing two libraries, one of which is called durable queue, a disk-backed queue, and another called S3 Journal, built on top of the durable queue."

• "The system looks like this: there are two stages, the HTTP server concerned with persisting data and another loop uploading it to S3."

• Ensuring System Stability:

• "Measure what is the health of our system... quantify how much we might have lost when a machine goes down."

• "It’s really crucial when building these systems to understand what it means to complete something."

• Monitoring and Instrumentation:

• "We have metrics now... gives us a little bit more visibility in the system."

• "Be picky about your tools... prefer something which actually tells you how fast it is."

• Final Recommendations:

• "Unbounded queues are bounded by memory or some fixed shared resource."
• "Account for what happens when your system receives too much data."
• "Use back pressure to defer the choice to someone who understands the application better."
• "Demand metrics everywhere to ensure system robustness."

This summary outlines the core arguments of the paper "Biology as Reactivity," which posits that biological systems, particularly living cells, can be understood as the ultimate reactive systems. * Core Thesis: The principles and tools used for analyzing reactive systems in computer science can be applied to biological research to create virtual experimentation environments.

"Concepts, languages, and tools for the description and analysis of reactive systems can help in the process of biological discovery, ultimately by providing biologists with virtual experimentation environments."

• The Cell as a Reactive System: A living cell is presented as a quintessential reactive system, where its behavior is a function of not just the inputs, but also their timing, order, and location.

  "A living cell, we claim, is not only reactive in nature, but is the ultimate example of a reactive system, and so are collections thereof."

• Adaptivity as a Form of Reactivity: The adaptive nature of biological systems to both internal and external stimuli is a key aspect of their reactivity.

  "Biological systems are also highly adaptive, to both internal and external changes; they use signals coming in from receptors and sensors, as well as emergent properties to fine-tune their functioning. This adaptivity is another facet of the reactivity of such systems."

• Key Concepts in Biological Reactivity: The understanding of biological systems as reactive necessitates a grasp of fundamental concepts like parallelism, interaction, and causality.

  "Hand-in-hand with the central notion of reactivity go the discrete event-based execution and simulation of dynamical systems, which requires a fundamental understanding of parallelism, interaction, and causality; the design of complex systems from building blocks, requiring means for composition and encapsulation"

• Signal Propagation and distributed control: The paper gives the example of muscle contraction to illustrate how signals are propagated in a distributed manner.

  "But notice that when a muscle contracts, the nerve reaches only some of the muscle cells, and responsibility for the remainder of the signal's effect must be taken over by other mechanisms."

• A Novel Programming Paradigm: Behavioral programming is a new way to create reactive systems by focusing on how the system should behave, which aligns with the initial requirements.

  "We describe an implementation-independent programming paradigm, behavioral programming, which allows programmers to build executable reactive systems from specifications of behavior that are aligned with the requirements."

• Modular and Flexible Development: It allows for the addition and modification of existing behaviors through software modules, which simplifies dealing with incomplete or conflicting requirements.

  "Behavioral programming simplifies the task of dealing with under-specification and conflicting requirements by enabling the addition of software modules that can not only add to but also modify existing behaviors."

• Scenario-Based Programming: Behavioral programming originated from the scenario-based language of live sequence charts (LSC), which allows for creating executable specifications of reactive systems.

  "The work on behavioral programming began with scenario-based programming, a way to create executable specifications of reactive systems, introduced through the language of live sequence charts (LSC) and its Play-Engine implementation."

• Core Programming Idioms: The paradigm uses specific idioms to express what must, may, or must not happen, similar to modal verbs in natural language.

  "Reminiscent of modal verbs in a natural language (such as shall, can or mustn't), they state not only what must be done (and how) as in standard programming, but also what may be done, and, more uniquely to behavioral programming, what is forbidden and therefore must not be done."

• Event-Driven Approach: To begin development, a common set of events relevant to the system's scenarios is determined.

  "In behavioral programming, all one has to do in order to start developing and experimenting with scenarios that will later constitute the final system, is to determine the common set of events that are relevant to these scenarios."

• Conflict Resolution and Scalability: The paradigm includes composition operators to manage and resolve conflicting behaviors, analysis tools like model checkers, and architectures for large-scale applications.

  "We deal with these issues by using composition operators that allow both adding and forbidding behaviors, analysis tools such as model checkers, and architectures for large-scale applications."

• Language Independence: The principles of behavioral programming can be implemented in various programming languages and environments.

  "Behavioral programming principles can be readily implemented as part of different languages and programming approaches, with possible variations of idioms."

To my understanding, the talk started with the following premise:

Global state is bad, DB is global state => DB is bad (use Rama instead)

I'd argue that: every observable state is global state

• Global state refers to a state that is outside of some context but still affects it.
  • Affects it means that the state is observable in some way from outside the state's context.
• If we consider that when we talk about the problems of state we effectively means observable state and the issues it causes outside its context.
• Then by acknowledging it has effects on other contexts outside its own context we acknowledging that it is a global state (because it affects some context from outside).

So after establishing every observable state should be considered global state to some extent (of some contexts). The way to solve this problem is eliminate state. Can this be done? I don't know (I don't believe it can)

But more practically: did Rama eliminated state? No, it didn't, if you append an event to an event log you have changed the state of that event log and potentially every view that was derived from that event log.

So:

global state is bad, db is global state, rama is global state => everything is bad

https://youtube.com/watch?v=TAQ7yBLRZ3U&feature=shared

Certainly! Here’s a detailed summary and key insights from the YouTube talk “Use.GPU - Declarative/Reactive 3D Graphics by Steven Wittens #LambdaConf2024” (link to video):

Overview

Steven Wittens introduces Use.GPU, a TypeScript library for driving WebGPU with a declarative and reactive programming model. The talk explores the motivation, design, and technical underpinnings of Use.GPU, emphasizing productivity, maintainability, and the bridging of web and graphics paradigms.

Key Topics Covered

1. The Problem with Traditional 3D Graphics Development

• High Complexity & Maintenance Cost: Building custom 3D graphics (e.g., configurators, data visualizations, CAD apps) is often slow, expensive, and results in code that’s hard for teams to maintain.
• Specialization Barrier: The field is so specialized that many companies avoid using advanced GPU graphics due to the expertise required.

2. The Permutation Problem

• Example: A 3D house configurator requires manually assembling assets and coding every possible combination of options, leading to exponential complexity.
• Customization Pain: Existing visualization libraries (like Deck.gl) are hard to deeply customize without forking and maintaining complex codebases.

3. The Web vs. Graphics Divide

• Graphics World: Driven by games/CAD, large teams, offline delivery, monolithic codebases, and focus on rendering performance.
• Web World: Driven by SaaS, small teams, continuous delivery, focus on compatibility, composition, and reuse.
• Different Priorities: These differences make it hard to bring GPU graphics into mainstream web development.

4. Live: A React-like Runtime

• What is Live? A React-inspired, incremental, and reactive runtime that allows for declarative UI and graphics code.
• Key Features:
• Incremental updates: Only re-executes code in response to changes.
• Implicit, one-way data flow.
• Declarative side effects: Auto-mounting and disposal.
• Enables features like undo/redo and multiplayer state management.
• Unique Twist: Live allows data to flow back from child to parent components—something not possible in React—which is crucial for certain graphics/data workflows.

5. Use.GPU: Declarative WebGPU

• Goal: Make GPU graphics as easy to use and maintain as modern web UIs.
• Approach: Use familiar JSX-like syntax and React-style components to describe 3D scenes and behaviors.
• Incremental Rendering: The system is designed as if rendering one frame, and only reruns necessary parts for interactivity/animation.
• Bridging the Gap: By combining Live’s reactive model with WebGPU, Use.GPU makes advanced graphics accessible to web developers.

6. Technical Insights

• Immediate vs. Retained Mode:
• Immediate mode (e.g., Canvas): Easy but doesn’t scale for complex interactivity.
• Retained mode (e.g., GPU): More efficient but much harder to program and maintain.
• GPU as a Pure Function Applicator: The challenge is efficiently feeding unique data to millions of parallel shader invocations, with memory bandwidth as a key constraint.
• Use.GPU’s Innovation: Abstracts away much of the boilerplate and complexity, letting developers focus on high-level structure and reactivity.

Why This Matters

• Productivity: Use.GPU aims to democratize GPU programming for web developers, reducing the need for deep graphics expertise.
• Maintainability: Declarative, reactive patterns make complex interactive graphics more maintainable and composable.
• New Possibilities: Opens the door for more sophisticated, interactive, and visually rich web applications.

Further Resources

• Use.GPU Project: GitHub link (if available, check video description) (replace with actual link if different)
• Steven Wittens’ Website: acko.net (famous for its interactive header)
• LambdaConf: LambdaConf 2025 Tickets

TL;DR

Use.GPU is a new TypeScript/WebGPU library that brings React-style declarative, reactive programming to 3D graphics in the browser. Built on the “Live” runtime, it enables maintainable, high-performance graphics apps with familiar web development patterns—potentially revolutionizing how interactive graphics are built on the web.

If you want a specific section of the talk summarized, or code examples from Use.GPU, let me know!

Citations: [1] watch?v=TAQ7yBLRZ3U https://www.youtube.com/watch?v=TAQ7yBLRZ3U

https://stopa.io/post/296

Certainly! Here’s a summary and key insights from the article "A Graph-Based Firebase" by Ivan Stopa.

Summary: "A Graph-Based Firebase"

The Problem

Modern, delightful apps like Figma, Notion, and Linear share three standout features: - Optimistic updates (instant UI feedback) - Multiplayer collaboration - Offline mode

Building these features is hard. Most frameworks and databases don’t make it easy-especially when you want all three together.

Existing Solutions & Their Limits

• Firebase: Great at optimistic updates, offline mode, and reactivity. But it falls short for complex data relations and permissions.
• Supabase & Hasura: Support relations (thanks to SQL/Postgres), but lack robust local/offline abstractions and have limited permission systems for complex apps.
• Custom Architectures: Apps like Figma/Notion/Linear end up building their own stack: normalized in-memory stores, custom permission layers, manual syncing, and more.

The Core Insight

All these apps end up re-inventing a kind of database, but one that works both locally (in the browser) and remotely (on the backend), with: - Graph/relational queries - Expressive permissions - Built-in reactivity, offline, and optimistic updates

The Proposed Solution: Instant

Ivan and his co-founder built Instant: a graph-based, Firebase-like platform with: - Triple store backend (instead of SQL), enabling flexible relations and recursive queries. - Datalog-inspired query language (instead of SQL or GraphQL), for nested, relational data. - Unified local/remote architecture: The same query/mutation language runs in the browser and on the server. - Expressive, Facebook-like permissions: Functions for allow/deny rules, not just boolean expressions or row-level policies. - Lightweight and easy to start: No heavy schemas or large client libraries.

Why Not SQL?

• SQL is heavyweight (1700+ page spec), not optimized for nested/recursive queries common in UIs.
• Frontend needs nested data, but SQL returns flat rows-requiring GROUP BY, JSON hacks, or complex post-processing.
• Implementing full SQL reactivity and sync is overkill for most app needs.

The Vision

A new abstraction-something like a graph database in the browser-could make it dramatically easier to build fast, collaborative, offline-capable apps. If the local and backend database speak the same language, you get: - Real-time sync - Optimistic updates - Offline support - Powerful, maintainable permissions - Simple, nested queries for UI

Key Takeaways

• Modern app UX is a database problem: The hardest parts of delightful apps (speed, collaboration, offline) are really about how data is managed and synchronized.
• Existing tools force trade-offs: You can have relations or offline support, but not both. You can have permissions or reactivity, but not both.
• A new kind of database abstraction is needed: One that combines the best of Firebase (local-first, reactivity) with the best of SQL/Graph (relations, permissions).
• Triple store + Datalog is promising: It enables flexible, nested queries and is easier to make reactive and local-first than SQL.

If You’re a Developer…

• If you’ve struggled to build fast, collaborative, offline-friendly apps, you’re not alone.
• Watch for tools like Instant (or similar local-first, graph-based databases).
• The future of app development may look a lot more like building with a distributed, reactive, permissioned graph database-on both client and server.

Let me know if you want a deeper technical breakdown, a comparison table, or actionable recommendations for your own projects!

Citations: [1] A Graph-Based Firebase https://stopa.io/post/296 [2] A Graph-Based Firebase https://stopa.io/post/296

• Definition and Nature of Design:

  • Design involves preparing executable plans and structuring form.

    "Prepare the plans for a work to be executed... plan the form and the structure of that thing." - Effective design separates elements to enable later composition.

    "Designing is fundamentally about taking things apart... in such a way that they can be put back together."

• Misconceptions About Design:

  • Good design isn't mere documentation generated post-implementation.

    "Can we just write our program and then generate some documentation?... No, that's not a plan." - Bad past experiences with monolithic designs don't invalidate design itself.

    "Those were plans but those are not good plans... doesn't mean planning is bad."

• Key Elements of Good Design:

  • Identify underlying problems rather than stated needs or symptoms.

    "Decompose those wants and needs into problems." - Differentiate known from unknown requirements, causes from symptoms.

    "Take apart causes and root causes from symptoms." - Address unstated, implicit requirements (e.g., maintainability, performance).

    "Unstated requirements... problems nobody wants in the future." - Separate concerns clearly: time/order, places/participants, information/mechanisms.

    "Separating apart when things happen... places and participants... information our systems manipulate."

• Iterative and Decompositional Nature of Design:

  • Design involves continuous decomposition and recomposition, supporting iterative changes.

    "Good design process is iterative... breaking things down until they're nearly atomic."

• Why Good Design Matters:

  • Design aids understanding, coordination, extension, reuse, and efficient testing.

    "Design helps you understand a system... coordinate... extension... reuse... design-driven testing." - Design leads to greater efficiency by simplifying iterative changes.

    "Easier to iterate a design than... an implementation."

• Composition and Performance Analogies (Bartók and Coltrane):

  • Composers set constraints deliberately, solving self-created problems through design.

    "First thing composers do... they create their own problems to solve." - Bartók (composer) specifies details precisely; Coltrane (performer) dynamically applies studied compositional knowledge.

    "Bartók completely specified every note... Coltrane had melody and changes... providing constraints for the performer."

• Improvisation vs. Planning in Software:

  • Improvisation isn’t random; it relies heavily on preparation and deep understanding.

    "Improvisation is not spontaneous emoting... application of knowledge and vocabulary." - Good developers, like good improvisers, combine studied preparation and dynamic execution.

    "Coltrane was working out this composition dynamically... resources behind it were things he had prepared."

• Harmony as Critical Design Skill:

  • Harmony is about congruity and simultaneous fitting together.

    "Harmonic sensibility is of critical design skill... systems that fit together." - Bartók and Coltrane exemplify mastery and innovation in harmonic principles.

    "Masters of harmony... retained focus on what fits together."

• Programming Languages as Instruments:

  • Programming languages/tools should resemble instruments: simple, focused, and designed for skilled users.

    "Languages and libraries like instruments... minimal yet sufficient." - Instruments are intentionally limited, enabling deep expertise through practice.

    "Piano can’t play in-between notes... saxophone one note at a time... instruments are minimal yet sufficient."

• Problems of Excessive Complexity and Choice:

  • Too many options or excessive configurability leads to poor design, overwhelming users.

    "Having a lot of choices... opposite of enabling us to accomplish things... constraint is a driver of creativity." - Simplicity and constraint enhance usability and creativity.

    "Every module is a good idea... adding them together you end up with something you can't play."

• Tools Should Empower Skilled Users, Not Beginners:

  • Software tools/instruments should not overly cater to beginners, sacrificing depth.

    "Instruments are made for people who can play them... beginners can't play yet." - Effort and practice are necessary for mastery; attempts to eliminate all effort weaken tool quality.

    "Effort is not a bad thing... neither learning nor teaching is effort-free."

• Design as Decision-Making:

  • Effective design clearly communicates deliberate, beneficial decisions.

    "Design is about making decisions... conveying those decisions to the next person." - Failure to decide clearly (excess configurability) is a design failure.

    "If you make everything configurable you're failing to design."

• Summary Recommendations:

  • Embrace decomposition and iterative refinement in design.
  • Develop harmonic sensibility for building coherent, maintainable systems.
  • Create simple, constrained, and purposeful software tools/instruments.
  • Prioritize deliberate decision-making to convey clarity and utility.

• Final Takeaways:

  • "Design like Bartók" by applying meticulous compositional care across scales.
  • "Code like Coltrane" by dynamically applying studied design knowledge.

  • Seek simplicity and harmony, avoiding unnecessary complexity and choice.

    "Take things apart... design like Bartók... code like Coltrane... pursue harmony."

Overview & Motivation

Repeatedly failed to write a post, realizing it should be a talk:

“It turns out that I wasn’t really writing a post; I was actually preparing a talk.”

Central Topic: React Server Components and distributed computations between two machines using React concepts.

“It’s about everyone’s favorite topic, React Server Components.”

Act 1: Recipes (Imperative) vs. Blueprints (Declarative)

Tags vs. Function Calls:

Visual and structural differences:

“< and > are hard and spiky and ( and ) are soft and round.”

Similarities:

Both reference named operations (functions or tags) and accept arguments.

Both allow nesting.

“Clearly, function calls and tags are very similar...they let us elaborate by nesting further.”

Differences:

Tags (declarative):

Often nouns; represent timeless structures (blueprints).

Convenient for deep nesting, clearly marking structure.

Time-independent, passive descriptions.

“Tags tend to be nouns rather than verbs... nouns are easier to decompose.”

Function calls (imperative):

Often verbs; represent sequential actions (recipes).

Execution order critical.

“A recipe prescribes a sequence of steps to be performed in order.”

Remote Procedure Calls (RPC) and Async/Await

Problem: Calling Functions Across Computers

RPC concept introduced: Functions across network boundaries.

async/await: Simplifies asynchronous calls but still has limitations (coupling, losing direct references).

“An async function...may pause execution...async and await propagate upwards.”

Import RPC idea: Extends importing to remote function calls while maintaining references and type-checking.

“Let’s invent a special syntax...import rpc because what we’ve described here has been known for decades as RPC.”

Potential Calls (Tags as Deferred RPCs)

"Potential function calls": Represented by tags; calls that might happen in the future.

“It’s a blueprint of a function call.”

Nested tags: Express dependencies naturally.

“Dependencies between potential calls...should be expressed by embedding these calls inside each other.”

Splitting Computation in Time and Space

Computation split in time: Returning partial functions that capture necessary data (closures).

Computation split across space (client-server): Splitting execution between two computers, handling data passing explicitly.

“It’s an interesting shape—a program returning the rest of itself...closure over the network.”

Two Types of Operations: Components vs. Primitives

Components (Capitalized): "Brains" of a program; flexible, timeless, and declarative, embedding tags without introspection.

“Components are truly timeless...they accept tags as arguments.”

Primitives (lowercase): "Muscles"; introspect arguments, execution order sensitive, imperative, execute last.

“Primitives introspect arguments...they must know all their arguments.”

Execution Phases:

1. Interpret (thinking): Processes Components freely without strict order.

2. Perform (doing): Executes Primitives strictly inside-out.

“First, you need to think...then you need to do.”

Act 2: Reflections and Dialog

Meta-dialog: Reflection on the writing process itself; writer and reader dialogue, acknowledging uncertainty and experimental nature of content.

“The Writer: I have a rough idea, but truthfully, I’m pretty much winging it.”

Core Conceptual Innovations

Tags as code/data pairs: Potential function calls represented explicitly as data (tags), allowing deferred execution across contexts.

Program as distributed computation: A single conceptual function spanning multiple runtime environments (Early and Late worlds).

Timelessness and Flexibility: Components allow arbitrary computation ordering; Primitives enforce execution order.

Key Quotes & Ideas:

Blueprints vs. Recipes:

“A blueprint describes what nouns a thing is made of...a recipe prescribes a sequence of steps to be performed.”

RPC and Potential Calls:

“A tag is like a function call but passive, inert, open to interpretation.”

Components and Primitives Separation:

“Components are the ‘brains’...Primitives are the ‘muscles’.”

Importance of Introspection vs. Embedding:

“If a function only embeds an argument without introspection, you can delay computing it.”

Conclusion (Conceptual Breakthroughs)

Distributed React Model: Redefining client-server interaction as React component structures.

Future implications: Suggests moving common primitives into lower-level implementations to optimize distributed computation.

“If many programs used the same Primitives...move their implementation to Rust or C++.”

Talk overview: Discusses integrating Resource Description Framework (RDF) with language models (LMs), aiming to leverage RDF’s logical precision and LM’s linguistic flexibility.

"We'll go over what rdf is, what language models are, and why they go well together."

Controversial statements: Presents two conflicting viewpoints:

LMs are valuable technological advances with profound philosophical implications.

"Language models are pretty neat and I like them... We never imagined we'd be able to compute over unstructured text like this."

AI/LMs have negative societal impacts, including environmental harm, disinformation, and devaluing art and labor.

"Language models suck or rather AI sucks... It's bad for the environment, art, labor... we're drowning in slop and spam."

Personal perspective and approach: Advocates mindful, responsible tech use; avoid superficial social media debates; focus on enhancing tech to achieve net positive societal impact.

"Be mindful of the impact... don't talk about this stuff on social media... how good does it have to be before it becomes net good?"

Introduction to RDF: RDF, developed post-internet by symbolic AI enthusiasts (W3C), is designed for precise, abstract knowledge representation via "triples" (subject-predicate-object).

"RDF is an attempt to tackle some of the hardest problems of knowledge representation and reasoning."

Critiques of RDF: Historically misunderstood due to complex formats (RDF XML), overly complex object-oriented libraries, and failed Semantic Web hype.

"RDF XML... was a verbose complex format... The Semantic Web was simply overhyped."

Strengths of RDF: Despite critiques, RDF remains robust and is heavily adopted in scientific, governmental, and enterprise environments for precise information modeling.

"RDF is being used productively in science, heavy industry, government."

Core components of RDF:

Resources: Unique identifiers (IRIs) representing any real or abstract entities.

"Anything that can be the subject of language can be the subject of rdf."

Triples: Fundamental units of RDF, expressing precise semantic relationships clearly.

"Subject predicate object... one of the most granular ways of representing information."

Importance of context in RDF: RDF IRIs inherently carry context, resolving linguistic ambiguity through precise identifiers.

"The goal of IRIs in RDF is that they carry their context with them."

RDF as knowledge representation: RDF is more than data storage; it’s structured for logical entailment, inference, and reasoning capabilities, akin to symbolic AI.

"RDF... is about representing knowledge... it's designed to make it possible to talk about all the things I know."

Introduction to Language Models (LMs): Originating with Transformers (Attention Is All You Need, 2017), LMs revolutionized natural language processing by capturing grammar, syntax, semantics, pragmatics, and reasoning patterns from vast datasets.

"Attention is all you need... unlocks everything language models can do today."

Defining LMs: LMs are pure mathematical functions trained on language, predicting next tokens based on vast statistical measurements (latent semantic space).

"Language model... is a pure function that predicts the next token."

Current state of LM programming: Due to the complexity and opaque outputs of LMs, effective usage relies on controlling inputs through prompt engineering, information retrieval, query generation, tool use, and agent design.

"All AI programming... is altering the inputs... Prompt engineering... Tool use... Agents."

RDF and LM integration: RDF uniquely bridges structured data (logic) with natural language, enabling precise interactions (querying, reasoning) between LMs and structured data via RDF's semantic precision and natural linguistic alignment.

"We should be putting rdf data in our prompts... RDF is really surprisingly good at going back and forth between natural language and rdf."

Advantages of combining RDF and LMs:

Simplifies querying structured data through natural language, enabling reasoning and inference beyond simple SQL queries.

"If my RDF implementation supports reasoning... all that complexity is abstracted out of the model."

Allows soft inference using LMs to approximate implicit knowledge, overcoming limitations of strictly rule-based AI systems.

"Soft inference... we now have hard inference... and soft inference... you can do reasoning you couldn’t do with either alone."

Neurosymbolic AI: Integrating RDF (symbolic reasoning) with LMs (neural networks) represents neurosymbolic AI, combining the strengths of precise logic with flexible language modeling.

"This is the central insight behind what's called neurosymbolic AI."

Practical vision and conclusion: Advocates using AI/RDF to automate tedious "data chores," proposing a constructive, pragmatic use-case-driven vision of AI tech.

"I do a lot of programming is dishes and laundry of data... trying to build it... we're going to bring back the Semantic Web with AI."

Figma's blog post, "How Figma's Multiplayer Technology Works," provides an in-depth look at the architecture and mechanisms enabling real-time collaborative editing in Figma. Below is a structured summary highlighting key concepts and direct quotes from the article:

• Client-Server Architecture: Figma employs a client-server model where web clients communicate with servers via WebSockets. Each document has a dedicated server process managing real-time collaboration.

"We use a client/server architecture where Figma clients are web pages that talk with a cluster of servers over WebSockets." citeturn0search0

• Custom Multiplayer Solution: Instead of using traditional Operational Transforms (OT), Figma developed a bespoke system tailored to design tools, prioritizing simplicity and performance.

"We decided to develop our own solution... we didn’t want to use operational transforms... As a startup we value the ability to ship features quickly, and OTs were unnecessarily complex for our problem space." citeturn0search0

• Document Structure: Each Figma document is organized as a tree, akin to the HTML DOM, with a root object encompassing pages and nested objects.

"Every Figma document is a tree of objects, similar to the HTML DOM. There is a single root object that represents the entire document." citeturn0search0

• Conflict Resolution via CRDTs: Figma's system draws inspiration from Conflict-Free Replicated Data Types (CRDTs), specifically implementing structures like grow-only sets and last-writer-wins registers to manage collaborative edits.

"Figma’s data structure isn't a single CRDT. Instead it's inspired by multiple separate CRDTs and uses them in combination to create the final data structure that represents a Figma document." citeturn0search0

• Property Synchronization: The servers track the latest values for each property on objects, ensuring that non-conflicting edits merge seamlessly, while concurrent edits on the same property resolve using a last-writer-wins approach.

"Figma’s multiplayer servers keep track of the latest value that any client has sent for a given property on a given object." citeturn0search0

• Object Creation and Deletion: Object IDs are generated to be unique across clients, facilitating offline operations. Deleted objects' data is stored in the undo buffer of the client that performed the deletion.

"This system relies on clients being able to generate new object IDs that are guaranteed to be unique." citeturn0search0

• Tree Structure Management: Parent-child relationships are maintained by storing parent links as properties on child objects. Measures are in place to prevent cycles and ensure a valid tree structure.

"The approach we settled on was to represent the parent-child relationship by storing a link to the parent as a property on the child." citeturn0search0

• Fractional Indexing for Ordering: Children's order within a parent is determined using fractional indexing, assigning positions as fractions between 0 and 1, allowing efficient reordering.

"Figma uses a technique called 'fractional indexing' to do this." citeturn0search0

This architecture ensures that Figma delivers a responsive and reliable real-time collaborative design experience.

Introduction and Motivation: Term rewriting with Meander offers an intuitive introduction aimed at everyday software engineers.

> "Meander is heavily inspired by the capabilities of term rewriting languages. But sadly, there aren't many introductions to term rewriting aimed at everyday software engineers."

Basic Concept of Term Rewriting: It transforms data by applying rules that match a left-hand-side pattern to produce a right-hand-side output.

> "The goal of Term Rewriting is to take some bit of data and rewrite it into some other bit of data. We accomplish this by writing rules that tell us for a given piece of data what we should turn it into."

Simple Rewrite Rule Example: A basic rule maps a specific input (e.g., :x) to a designated output (:y).

> "Here is the most simple rewrite rule imaginable. If we are given :x we turn it into :y."

Combining Multiple Rewrite Rules: Multiple rules can be defined to handle various inputs simultaneously.

> "Here we've extended our rewrite to have multiple rules."

Utilizing Variables in Patterns: Variables (prefixed with ?) match any value and allow that matched value to be reused in the output.

> "Here we added the variable ?x to our left-hand-side. Variables start with a ? and match any value."

Pattern Matching on Data Structures: Rules can be crafted to operate on vectors, enabling extraction of specific elements such as the first element.

> "Here we can see some really simple rules that work on vectors of various sizes. We can use this to extract the first element from each."

Rewriting Strategies for Control: Strategies allow precise control over how and when rewrite rules are applied during computation.

> "Strategies let us control how our terms are rewritten."

The Attempt Strategy: The attempt strategy tries to apply a rewrite and, if it fails, returns the original value to handle cases where no match is found.

> "We can fix that by using the attempt strategy. It will try to rewrite and if it fails, just return our value."

Iterative Application with (until =) Strategy: The (until =) strategy repeatedly applies rules until the expression stops changing.

> "What we really want to say is to continue applying our rewrite rules until nothing changes. We can do that by using the (until =) strategy."

Traversal Approaches – Bottom-Up vs. Top-Down: Different strategies, such as bottom-up and top-down, affect the order and frequency of rule application in nested expressions.

> "If we look at the top-down approach, we can see that the top-down strategy actually gets called three times... Our bottom-up strategy however is only called twice."

Tracing the Rewriting Process: The trace strategy provides visibility into each step of the rewriting process for debugging and analysis.

> "We can inspect our strategies at any point by using the trace strategy."

General Computation via Term Rewriting: Term rewriting can express any computable function, exemplified by implementing Fibonacci with Peano numbers.

> "Term Rewriting is a general programming technique. Using it we can compute absolutely anything that is computable."

Code and Execution as Data: It enables code to be treated as data, allowing for introspection of intermediate execution steps.

> "Not only can our 'code' be data more than it can in lisp, but we can actually have our execution as data."

Support for Partial Programs: The paradigm facilitates working with incomplete programs by allowing unimplemented parts to be represented without immediate failure.

> "Term Rewriting also gives us an easy basis for talking about partial programs."

A New Programming Paradigm: Term rewriting represents a uniform, pattern-based approach to programming that challenges traditional distinctions between code and data.

> "Term Rewriting represents a distinct way of programming. It offer s us a uniform way of dealing with data."

You can change permanent notes

What kinds of connections are there?

Permanent notes

bullets vs written prose?

• After annotating a mass of content around a topic (a problem to be solved?)
• I review all the notes and simply group them (using drag & drop? Or canvassing) as I go through them
• Each note goes into a group of similar notes
• These groups might just be the key takes from my research and the outline of my permanent note
• Problems to be solved could be the anchors of my structure
• At any given moment I'm thinking or consuming content in the context of some problem
• Problem could be phrased as goals, challenges or even products to be designed
  • It might be important to choose which way to phrase it or even use aliasing to find it from different state of mind

Alias for permanent notes

Who is?

• Original thinking
• Contains full context and can be understood as a stand-alone unit
• Contains references & sources

For Literature Notes

• Spontaneous thought that occur.
• Only need quick capture
• I'd also add a quick linking/tagging mechanism so it will at least be at the right area

• Bullet point summary in my own words of external content
• I need to read more on how to take notes
• Annotations seems like an effective approach

How to take smart notes

• Collecting material feels more useful than it usually is
  • When I'm collecting references around a topic of interest I feel productive: it is very systematically, efficient, easy to do, and the product is tangible.
  • However it leaves the meaningful work of actually digging into those references for later.
  • Sometimes that later usually doesn't come and if it does:
    • Digging deeply into references isn't cheap so I usually don't dig into most of that references I collected but only to a selected few.
    • This can be looked at as BFS vs DFS strategy.
    • For articles, collection means less than actually reading and writing about the article.
    • For tools, nothing beats actually using the tool.
  • Perhaps my knowledge accumulation strategy should emphasis shortest path to value.

• Comparison of web annotation systems
  • [[Memex]]
    • Desktop
      • UI looks good
      • Live annotations on the site
      • Multiple notes on page
      • AI integration
      • Annotations for videos
    • Mobile
      • Annotations through the app
        • The app seems to keep the integrity of the original content (no content loss)
      • Buggy text input widget
    • Syncing
      • Require Readwise
        • Not bi-directional!
        • Unmodifiable log-based format
  • [[Hypothesis]]
    • Desktop
    • Mobile
      • Bookmarklet is a good option to bypass the need for extension
      • Proxy is also an option
      • Annotations on the original site (no content loss)
      • No annota
    • Syncing
      • Through Readwise
        • Nice format
        • Full control over frontmatter
      • Obsidian plugin
        • No control over frontmatter
  • [[Readwise]]
    • Desktop
      • UI looks old and unmaintained
      • Live annotations on the site
      • Multiple annotation on site can only be achieved by highlights
        • Only single note per page without highlighting
    • Mobile
      • Annotations through the app
        • Some content is lost when importing to the app
      • Text-to-speech
    • Syncing
      • Through Readwise
        • Not bi-directional!
        • Cleaner format then memex

• I too think knowledge should be open for feedback
• Feedback improves quality
• This also increases exposure which creates opportunities for collaboration

• This is true for my KMS as well
• A system of naming and aliasing is very important for discoverablity
• And also prevent duplications

• I'm looking for a Taxonomy of notes and relations
• Andy's Taxonomy can provide some ideas / insight for my Taxonomy

Really?

• Purpose & Motivation

  We show that for a broad class of CRUD (Create, Read, Update, Delete) applications, this gap can be bridged.

  • This work addresses the difficulty many web authors face in creating interactive, data-driven applications due to limited programming and data-schema knowledge.

• Core Contribution

  Mavo extends the declarative syntax of HTML to describe Web applications that manage, store and transform data.

  • The system introduces a novel approach where authors define schemas implicitly by marking up HTML elements, effectively eliminating the need for complex server-side CMS solutions or JavaScript frameworks.

• Related Work Context

  These three systems introduced powerful ideas: extending HTML to mark editable data in arbitrary web pages, spreadsheet-like light computation, a hierarchical data model, and independence from back-end functionality.

  • Mavo differentiates itself from prior efforts (e.g., Dido, Quilt, Gneiss) by combining lightweight computation, purely client-side data management, and seamless integration with arbitrary HTML layouts.

• HTML-Based Declarative Syntax

  We chose to use HTML elements, attributes, and classes instead of new syntax for Mavo functionality because our target authors are already familiar with HTML syntax.

  • Mavo leverages standard HTML attributes—like property, data-multiple, and data-store—to mark elements for data binding, persistence, and editing.

• Editing & Storage

  Mavo can store data locally in the page (data-store=#elementid\), in the browser’s local storage (data-store=\local\), in an uploaded / downloaded file (data-store=\file\) or on one of the supported persistent storage services.

  • Once marked, any element or text becomes directly editable on the rendered page; changes are saved back to the chosen store, enabling WYSIWYG content management within the browser.

• Objects & Collections

  Properties that contain other properties become grouping elements (objects in programming terminology); this permits a user to define multi-level schemas.

  • By adding data-multiple, users enable collection-like behavior, allowing repeated sections or items to be dynamically added or removed.

• Lightweight Computation & Expressions

  Expressions are delimited by square brackets ([]) by default and can be placed anywhere inside the Mavo instance, including in HTML attributes.

  • This spreadsheet-like capability supports referencing other properties, performing aggregations (e.g., sum(), average(), count()), and conditional logic (iff()).

• Implementation Details

  Mavo is implemented as a JavaScript library that integrates into a web page to simulate native support for our syntax.

  • On page load, Mavo constructs an internal tree representation of the HTML and expressions, updating all references reactively whenever data changes.

• User Studies: Structured Tasks

  We found that the majority of users were easily able to mark up the editable portions of their mockups to create applications with complex hierarchical schemas.

  • Participants successfully transformed static HTML pages (for a ‘Decisions’ app and a ‘Foodie log’) into dynamic CRUD applications, achieving a 100% success rate on the basic CRUD tasks.

• Common Difficulties

  Some participants frequently copied and pasted expressions when they needed the same calculation in different places.

  • Most challenges arose around conditionals (iff()) and more advanced expressions (e.g., filtered counts), underscoring that more complex logic remains harder for novices.

• User Studies: Freestyle Tasks

  We asked them to use Mavo to make their mockup fully functional in any way they chose.

  • Users brought their own HTML for an ‘Address Book’ concept. All were able to implement multi-level data (e.g., multiple phone numbers) with minimal changes.

• Direct Manipulation Design

  Instead of crafting a data model and then deciding how to template and edit it, a Mavo author’s manipulation of the visual layout of an application automatically implies the data model.

  • This makes building and editing data-backed pages more natural for users who think first in terms of presentation.

• Intended Audience & Scalability

  Mavo is aimed at a broad population of users. There is no hard limit to what it can do, since its expressions also accept arbitrary JavaScript.

  • The system is best suited to ‘small data’ applications such as personal information management or single-author web publishing, but can also facilitate multi-user scenarios with suitable back-end access controls.

• Semantic Web Alignment

  Mavo syntax for naming elements is based on a simplified version of RDFa… as a result, at runtime any Mavo instance becomes valid RDFa that can be consumed by any program that needs it.

  • Authors who add property attributes gain structured, machine-readable data without explicitly learning RDFa or JSON.

• Planned Improvements

  A more direct way to declaratively express these operations [sorting, searching, filtering] is needed… sorting, searching and filtering were recurring themes.

  • Future work will focus on refining conditional syntax, improving data migrations when HTML structures change, and incorporating advanced multi-user access models.

• Conclusion

  We show that HTML authors can quickly learn use Mavo attributes to transform static mockups to CRUD applications, and, to a large extent, use Mavo expressions to perform dynamic calculations and data transformations.

  • The researchers envision a future where editing and storing structured data via standard HTML becomes ubiquitous, lowering barriers for both novice and skilled web authors.

• Object algebras solve the expression problem in OO languages using simple generics.

  "This paper presents a new solution to the expression problem that works in OO languages with simple generics (including Java or C#)."

• They avoid the need for advanced typing features such as F-bounded quantification, wildcards, or variance annotations.

  "Object algebras use simple, intuitive generic types that work in languages such as Java or C#. They do not need the most advanced and difficult features of generics available in those languages, e.g. F-bounded quantification, wildcards or variance annotations."

• They improve on the Visitor pattern by eliminating accept methods and preserving encapsulation.

  "Object algebras also have much in common with the traditional forms of the Visitor pattern, but without many of its drawbacks: they are extensible, remove the need for accept methods, and do not compromise encapsulation."

• They support retroactive interface implementations, allowing new operations to be added without modifying existing code.

  "By using this simple pattern we can provide retroactive implementations of interfaces to existing code."

• They enable extension in two dimensions: adding new data variants and new operations.

  "There are two ways in which we may want to extend our expressions: adding new variants; or adding new operations."

• They directly implement functional internal visitors, reflecting Church encodings.

  "Object algebras provide a direct implementation of (functional) internal visitors since constructive algebraic signatures correspond exactly to internal visitor interfaces."

• Multi-sorted object algebras support multiple, potentially mutually recursive types and operations as a family.

  "In larger programs, it is often the case that we need multiple (potentially mutually) recursive types and operations evolving as a family."

• Modular combinators, such as union and combine, allow independent extensibility and parallel execution of operations.

  "Sometimes it is useful to compose multiple operations together in such a way that they are executed in parallel to the same input."

• A real-world case study demonstrates their application in a remote batch invocation system integrating RPC, web services, and SQL translation.

  "We have used this technique in implementing a new client model for invoking remote procedure calls (RCP), web services, and database clients (SQL)."

• In conclusion, object algebras offer a lightweight, factory-oriented programming style that scales well while minimizing conceptual overhead.

  "This paper presents a new solution to the expression problem based on object algebras. This solution is interesting because it is extremely lightweight in terms of required language features; has a low conceptual overhead for programmers; and it scales well with respect to other challenges related to the expression problem."

• Denotational Model Overview:

  This paper presents a denotational model of inheritance. The model is based on an intuitive motivation of inheritance as a mechanism for deriving modified versions of recursive definitions.

• Inheritance as Differential Programming:

  Inheritance is a mechanism for differential, or incremental, programming.

• Handling Self-Reference:

  in order for a derivation to have the same conceptual effect as direct modification, self-reference in the original definition must be changed to refer to the modified definition.

• Fixed Point Semantics Foundation:

  Theorem 1 (Fixed Point) If D is a cpo and f ∈ D → D is continuous, then there is a least x ∈ D such that x = f(x).

• Modeling Inheritance via Generators:

  Inheritance is modeled as an operation on generators that yields a new generator.

• Wrapper Mechanism for Modifications:

  The modifications, however, are also defined in terms of the original methods (via super). In addition, the modifications refer to the resulting structure (via self).

• Equivalence of Semantics:

  Theorem 2 send = behave.

• Operational Method Lookup Semantics:

  When a message is sent, the methods in the receiver’s class are searched for one with a matching selector. If none is found, the methods in that class’s superclass are searched next.

• Intuitive Advantages and Broader Implications:

  The primary advantage of the denotational semantics is the intuitive explanation it provides. It suggests that inheritance may be useful for other kinds of recursive structures, like types and functions, in addition to classes.

• Application to Compiler Generation:

  Our denotational semantics of inheritance can be used as a basis for semantics-directed compiler generation for object-oriented languages, as shown by Khoo and Sundaresh (1991).

• Denotational Design as a Real Process

Denotational design is the process that has been elaborately developed by Conal Elliott.

• Core Principle of Stepping Back from Implementation

We don't want to jump in and say, ‘An image is an array of pixels.’ That’s too soon yet that’s where most of us start.

• Abstract Definition of an Image

An image is just a function from a pixel location, so an X, Y coordinate to color, where X, Y are in the real number space.

• Emphasis on Algebraic Properties and Category Theory

He uses algebraic properties and category theory. I think algebraic properties are a very good indicator that you are, ‘on to something’ in the design.

• Incremental, Iterative Refinement

You have to go back and revise and you make an attempt in a certain direction, and you learn something, and you bring that back to the beginning.

• Four Steps of the Denotational Design Process

These are the four steps that I see... This first one is to...like a Zenning out and forgetting all implementation assumptions...Then you explore...Then you align with category theory concepts...Then the final thing is actually implementing it.

• Challenges with Haskell’s Type System

Haskell has no type for real numbers. Most languages don’t...Another thing is, when you’re talking about say, the Monad laws or the Functor laws...there’s no way to do that equality comparison.

• Similar Difficulties in Clojure

I do think it's a little harder than in Haskell, but I also think that most of the design part is happening in your head.

• The Essence of Denotational Design

It’s about going back to first principles, building things up, understanding how things compose, and following a different gradient from what most people use when they design.

• Introduction to Signals & Reactivity

"Signals are value that change over time...The key to a reactive system is that it knows when you set the value; it looks for the set on the specific property, the specific function...and it reads with a function."

• The speaker emphasizes that signals conceptually hold a current value rather than providing a continuous stream of intermediate states.
• Signals update synchronously, ensuring that any consumer remains consistent with the current snapshot of data.

• Immutable vs. Mutable Structures

"We used to learn the framework and then learn the fundamentals kind of thing... in 2014, JavaScript had already taken off and I admittedly didn’t know very much."

• The conversation highlights the contrast between immutable data (where changes create new references) and mutable data (where changes happen in place).
• Immutable updates trigger re-diffing, whereas mutable updates allow granular changes at the specific location.

• Nested Signals & Efficiency

"If we just go in and change Jack’s name to Janet by just setting the name, we only need to re-run the internal effect…it’s only the nearest effect that runs."

• By nesting signals inside signals, individual property changes can avoid re-running the entire component or the entire data structure.
• This nested approach demonstrates how specific effects update only the parts that need to change, improving performance.

• Store Proxies as a “Best of Both Worlds”

"React basically tells you that this is where you end up—when you know that you can cheat it a little bit, you just get past it."

• Using proxies allows for deep mutation with minimal overhead, merging the developer simplicity of an immutable interface with the fine-grained updates of mutable change.
• The speaker points out that many frameworks lack built-in “derived mutable” structures and rely on bridging solutions such as user-space code or specialized stores.

• Map, Filter & Reduce with Signals

"We can also avoid allocations here by only storing the final results... but only if you care about final results."

• Mapping over large datasets illustrates the trade-offs between immutable approaches (always re-map) and mutable approaches (apply partial updates or diffs).
• The speaker notes that “filter” and “reduce” often involve more complete re-runs and may need specialized logic or custom diffs rather than a one-size-fits-all operator.

• Convergent Nodes & Reactive Graphs

"Because signals are a value conceptually, not a stream—...the goal of effects isn’t to serve as a log... it’s a way of doing external synchronization with the current state."

• Computed values (memos) serve as convergence points in the reactive graph. Multiple sources merge into derived data that updates automatically.
• Fine-grained systems need to track only minimal dependencies, but the conversation repeatedly underscores that different transformations (map, filter, reduce) pose unique challenges.

• Async & Suspense Insights

"Run once doesn’t work—there’s no way to avoid scheduling. We need to always throw or force undefined, so we need suspense."

• Lazy asynchronous signals can lead to “waterfalls,” where the second request only starts after the first completes.
• Suspending or temporarily showing old data can prevent blank states but risks double fetching and inconsistent chaining unless carefully guarded.

• Early Returns vs. Control Flow Components

"Early returns... push decisions upwards where further positions are pushed down, so it might not impact React, but it doesn’t lead to a way forward."

• The speaker critiques patterns that rely on returning early in components, arguing they duplicate layout logic and sometimes break optimal reactivity.
• The recommendation is to align with data flow and push condition checks closer to where data is rendered instead of scattering them at multiple return statements.

• Syntax Debates & Framework Convergence

"Syntax in JS frameworks is overrated... we’re at a point now where the looks are so superficial that you can be looking at complete opposites and it looks identical."

• Despite the prevalent notion that “ruin” syntax in various frameworks resembles React, the underlying reactivity mechanics differ significantly.
• Discussion highlights that every major framework—React, Vue, Svelte, Solid—converges on signals or reactivity, yet each approach’s details (mutable vs. immutable, compiler vs. runtime) vary widely.

• Conclusion: Future of Signals & Reactive Systems

"People are starting to wonder if we should just have one super framework now that we mostly agree... but each framework’s identity is in how it approaches these details."

• The speaker underscores ongoing exploration into data diffing, nesting, and push-pull mechanisms to improve performance while simplifying the developer experience.
• Signals and granular reactivity are core to bridging a user-friendly interface with minimal overhead, a goal each framework pursues in its own unique, evolving way.

Summary of "Wrong Way! Choosing a Direction for Datomic Ref Types" by Francis Avila

Problem Statement

• Datomic reference attributes require a direction (e.g., :vehicle/passengers vs. :passenger/vehicle).
• Key question: Which direction should be chosen for optimal performance and usability?

Why Prefer :passenger/vehicle (Lower-Cardinality Forward Direction)?

1. Keeps collections in map-projections smaller

• "Lower-cardinality attributes values are generally easier to deal with because entity-walking with d/entity or d/touch won’t occasionally give you unexpectedly large sets."
• Key Issue: High-cardinality attributes can create large collections, making entity exploration cumbersome.
• Protection Mechanism: "d/pull protects you from this because it will only pull 1000 items by default, but this is easy to forget!"

2. Keeps EAVT index smaller per entity

• "A high-cardinality relationship between two entities often implies some kind of containment relationship."
• Key Benefit: If the container entity is "rich" (i.e., has many attributes), using :passenger/vehicle keeps the EAVT index for the container smaller.
• Why it matters: Large EAVT indexes decrease index selectivity, making entity lookup less efficient.
• Caveat: This mainly affects d/entity and d/pull, not d/q or d/pull-many, which rely more on AEVT.

3. Improves EAVT history readability

• "Keeping the EAVT smaller per E also makes the history of an entity more human-legible when using d/history database reads over the EAVT index."
• Problem with :vehicle/passengers: "It will clutter the history of the container entity (the vehicle)."
• Advantage of :passenger/vehicle: Changes in passenger-vehicle relationships are recorded on the passenger’s history, not the vehicle’s.
• Takeaway: For audit logs and admin views, the passenger's history is usually more useful than the vehicle's.

4. Supports cardinality-one constraints with last-write-wins semantics

• "Very often, there is also an 'only in one container' constraint between a container and contained entity."
• Key Advantage: Using :passenger/vehicle as a cardinality-one attribute naturally enforces the rule that a passenger can only be in one vehicle at a time.
• Contrast with :vehicle/passengers: This direction cannot enforce uniqueness without additional constraints (e.g., transaction functions).
• Takeaway: If the relationship is inherently one-to-one, :passenger/vehicle provides better integrity guarantees.

Why Prefer :vehicle/passengers (High-Cardinality Forward Direction)?

1. Better schema legibility

• ":vehicle/passengers makes it clear when grouping by keyword namespace that vehicles are expected to reference many passengers."
• Issue with :passenger/vehicle: It does not make the vehicle-passenger relationship explicit.
• Challenge: No built-in way to highlight reverse ref relationships in Datomic schema.
• Possible Fixes:
  • Use entity specs with :doc metadata.
  • Create custom ref-range annotations.

2. More useful d/index-pull queries

• "d/index-pull provides extremely efficient, lazy, and offset-able pulls over the third slot in an AVET or AEVT index span."
• Problem: "d/index-pull cannot scan VAET."
• Why it matters: If you need to retrieve all passengers for a vehicle, d/index-pull won’t work efficiently for :passenger/vehicle.
• Workaround: Adding :db/index true to :passenger/vehicle, but this adds extra datoms to the index.

3. Reduces index segment churn

• "If the number of containers is significantly smaller than the number of contain-able entities, and the containment relationship churns frequently, the lower-cardinality-forward attribute is going to invalidate more segments during indexing."
• Example: If passengers frequently switch vehicles, using :passenger/vehicle means frequent updates across many EAVT and AEVT segments, causing more index fragmentation.
• Alternative: ":vehicle/passengers results in fewer index segments being invalidated."
• Takeaway: For high-churn relationships, :vehicle/passengers may be more efficient.

Summary Takeaway

• :container/contained (e.g., :vehicle/passengers) is intuitive, but :contained/container (e.g., :passenger/vehicle) is usually better due to:
  • Smaller map-projections.
  • More efficient entity walking.
  • Better historical auditing.
  • Natural enforcement of cardinality constraints.
• But :vehicle/passengers is better when:
  • Schema readability is critical.
  • d/index-pull is needed for efficient queries.
  • The relationship has frequent changes and involves many contained entities.

• Introduction to the Stream and Purpose

“I'm uh pretty excited about this one because I'm going to get to finally show off some of the stuff I've been working on for months.”

• Highlights the speaker’s enthusiasm to demonstrate months of development progress.
• Establishes that the stream will cover new reactive features and mechanisms.

• Parallel and Nested Async Fetching

“What if we want to do nested fetching where each component fetches data, but we don’t want to cause waterfalls? … We’ve basically solved waterfalls because promises do not throw out too early.”

• Emphasizes that asynchronous tasks in Solid can now run in parallel.
• Shows how nested components fetch data without blocking each other.

• createAsync as a Core Signal Primitive

“createAsync… if we look at the signature here, it expects a computation… and then returns an accessor of a number… it will just give you the resolved async value without returning undefined.”

• Introduces createAsync as an “async signal” that never yields undefined.
• Allows a direct, non-nullable way to fetch and use async data in the component.

• Local vs. Global Suspense Boundaries

“We don’t have to throw away our render tree just because we have something async… it only throws exactly where we read it, and that means everything else is fine.”

• Suspense is granular: only the part that reads an unresolved value suspends.
• Other parts of the UI remain interactive rather than unmounting the entire tree.

• Self-Healing Error Boundaries

“We basically collect the nodes that fail, and then, if they become unfailed or get disposed, the boundary can remove itself—self-heal.”

• Explains that failed async or errors get tracked locally by boundaries.
• Once the failure resolves or is disposed, the error boundary automatically resets.

• Avoiding Unpredictable Tearing

“You basically never want your async data to just flicker in or out. We can choose to throw or to keep ‘stale’ data. Suspense can opt into that.”

• Details the importance of consistent state during asynchronous updates.
• Introduces a mechanism (isStale or latest) to avoid jarring UI replacements.

• Splitting createEffect for Predictability

“If we just let you read signals in the same function where we do side effects, we get unpredictable re-runs… so we split it into two halves.”

• Shows how Solid 2.0 separates the tracking (pure) side from the side-effect (impure) side.
• Ensures that data retrieval and side-effects remain consistent, avoiding “zalgo” outcomes.

• Mutable Reactivity and Store Projections

“I realized a store approach is a general solution… the idea is you have a single source signal and can ‘project’ it out to many places… only the fields that change update.”

• Describes a new technique called “projections” to handle large data sets efficiently.
• Allows per-field reactivity, so only the row or property that changes triggers updates.

• Granular Handling of Async and Errors

“Error boundaries and suspense handle each failing effect locally. The rest of the system doesn’t even know something failed.”

• Illustrates that errors remain localized, preventing a full unmount.
• Reflects the fine-grained reactivity approach, making error handling more targeted.

• Impact on Ecosystem Comparisons

“React can’t do this because… they don’t have the semantics to pull from signals. It’s not the same model.”

• States the fundamental difference from React’s component rendering.
• Emphasizes that granular updates and specialized async signals differ sharply from React’s design.

• Future Plans: SSR, Hydration, Transitions

“We still need transitions. I haven’t implemented them yet, but they’re part of the equation. … Also looking at SSR so we can skip hydration IDs.”

• Points to upcoming work for Solid 2.0: concurrency transitions, improved server rendering, and more efficient hydration.
• Aims to unify the new runtime mechanisms with advanced features like streaming.

• Concluding Observations

“We’ve basically… proven we can handle async, error boundaries, and concurrency all purely at the reactive level. This changes everything.”

• Summarizes the significance of these new developments in Solid’s reactivity engine.
• Stresses that purely runtime-based solutions enable advanced use-cases without a compiler-centric approach.

Summary of "Genuinely Functional User Interfaces" by Antony Courtney & Conal Elliott

Abstract & Motivation

• Fruit is a GUI library for Haskell based on a formal model.
• The model defines signals (continuous time-varying values) and signal transformers (pure functions mapping signals to signals).
• GUI components are composed as signal transformers.
• The aim is to develop a denotational model for GUIs to enable reasoning about properties, abstraction levels, and new interaction paradigms.

Key Contributions

• Introduces AFRP (Arrow-based Functional Reactive Programming), an extension of FRP (Functional Reactive Programming).
• Uses signals (functions from time to values) and signal transformers (functions from signals to signals) to model GUIs.
• Defines GUI components compositionally, rather than as a hierarchy of widgets.
• Provides novel transformations, including continuous spatial scaling (zooming) and multiple views.

1. Introduction

• Previous Haskell GUI libraries (e.g., TkGofer, Fudgets, FranTk) have imperative or semi-functional designs.
• High-level programming means focusing on the conceptual model rather than implementation details.
• Fruit aims for a purely functional approach, mapping Haskell types and functions directly to their conceptual counterparts.

"What is an abstract conceptual model of a graphical user interface?"

"All previous GUI libraries for Haskell define the conceptual model of a GUI only informally, or defer to some external system (e.g., X Windows, Tk, Gtk)."

2. AFRP Programming Model

• Based on signals (time-dependent values) and signal transformers (functions on signals).

Signals

"A signal is a function from time to a value: Signal α = Time → α"

• Example: The mouse’s (x,y) position is a Signal Point.

Signal Transformers

"A signal transformer is a function from Signal to Signal: ST α β = Signal α → Signal β"

• Example: A transformer that outputs a signal of the mouse position.

Abstract Types

• Signals are conceptually continuous but implemented using discrete sampling.
• First-class signal transformers (but signals are not first-class) ensure modularity and prevent space-time leaks.

Arrows in AFRP

• Arrows (introduced by Hughes) allow composing functions structurally.
• AFRP uses arr, >>>, first, and loop operators for structuring signal transformers.

Discrete Events

• Events modeled as Maybe α signals:

"If the value at time t is Nothing, the event did not occur. If it is Just v, the event occurred with value v."

3. The Fruit GUI Model

GUI Definition

"A GUI is a signal transformer of type GUI a b = ST (GUIInput, a) (Picture, b)"

• GUIInput: Captures mouse and keyboard state.
• Picture: Defines the GUI’s visual representation.
• a → b: Represents auxiliary semantic input/output.

GUI Components

• Mouse Position Transformer haskell mouseST = arr snd >>> arr (fmap mpos) >>> stepper G.origin2
• A GUI that draws a ball following the mouse haskell ballGUI = first (mouseST >>> arr (move ballPic))
• Running a GUI haskell runGUI :: GUI a b -> IO ()

4. Composing Applications

Example: Paddleball Game

• Uses recursive signal transformers for position and velocity.
• Handles collisions with when combinator: haskell when :: ST Bool (Maybe ())
• Enables restart functionality with an event-based state machine.

Restart Button

"To restart the game, we need a button that produces an event when pressed and resets the game state."

• Uses stepAccum and switch for event handling.

Dynamically Enabling Buttons

• Uses an event-driven signal for enabling/disabling: haskell allowRestart <- stepper False -< gameDone

5. Exploring Modularity

Transforming GUIs

"A GUI's visual output is a Picture signal, which can be transformed point-wise."

• Enables zooming and spatial transformation: haskell transformGUI :: G.Transform -> GUI b c -> GUI b c

Multiple Views

"Many applications need multiple views on the same underlying dataset."

• Passive views: Observe state but don’t interact.
• Active views: Interact and sync across views.
• Implemented using focus-aware GUI multiplexing.

6. Dynamic GUIs

• Adding GUI components dynamically (e.g., labels appearing when a button is pressed).
• Uses accumST for incremental updates: haskell accumST :: (ST b c -> d -> ST b c) -> ST b c -> ST (b,Maybe d) c
• Example: Dynamically growing label list haskell countLabels = proc (inpS, es) -> do lblNumE <- countE -< es (picS,_) <- accumST addLabel (mkLabel 0) -< ((inpS,()),lblNumE)

7. Related Work

• Fudgets: Similar compositional approach but uses asynchronous stream processing.
• FranTk: Uses FRP but has an imperative widget-creation model.
• Mux (Pike, 1989): A CSP-style GUI system similar to Fruit’s multiplexing model.

8. Implementation & Future Work

• Prototype implemented using Haskell and Java2D.
• Plans to:
• Replace stream-based FRP with efficient data-driven FRP.
• Add a complete widget set.
• Support efficient dynamic collections.

Key Takeaways

1. Denotational Model
   • GUI components are pure signal transformers.
   • Enables formal reasoning and abstraction-level comparisons.
2. Modularity & Composability
   • GUIs are first-class values, supporting higher-order manipulation.
   • Transformations (e.g., zooming) are naturally expressible.
3. Functional Advantages
   • No space-time leaks (unlike earlier FRP models).
   • Multiple active views and zooming come "for free."
4. Real-world Implications
   • Can integrate modern HCI paradigms (e.g., zoomable UIs) seamlessly.
   • Has potential beyond traditional GUI frameworks.

Final Thoughts

Fruit presents a genuinely functional approach to GUIs, offering modularity, composability, and abstraction benefits over imperative toolkits. Its denotational foundation provides a rigorous semantic basis, paving the way for more principled and flexible UI development in functional programming.

Summary of the Talk: Building More Powerful User Interfaces in the Browser

Introduction & Motivation

• The speaker reflects on a year’s work in adopting modern web technologies (AMD, Backbone, HTML5, CSS3, new browser APIs) but realizes that the fundamental power given to users has not improved significantly from 15 years ago.

"I looked at what we had built at the end of the year and I said you know I think I could have built this 15 years ago when I started writing JavaScript."

• Traditional web applications function like simple forms: users provide inputs, and the application computes outputs. The speaker seeks a way to eliminate this rigid distinction and create more interactive and dynamic UI models.

"You have to decide in advance which things you think are input... and which things you think are output."

Example: Federal Budget Visualization

• A web-based visualization of the US 2013 federal budget illustrates the limitations of traditional input-output models.

"What if we could actually take this and change this and not have a distinction between input and output?"

• The speaker explores how users could interact more dynamically by locking certain variables (e.g., keeping the deficit fixed) and observing how other variables (e.g., taxes) adjust automatically.

Concept of Constraint Programming

• Constraint programming allows defining relationships between variables instead of prescribing explicit procedures for computation.

"Constraint programming is about writing our programs in terms of relations instead of procedures."

• Example: Instead of coding tax rates explicitly, define relationships between tax brackets and let the system adjust them dynamically.

"We make all of our variables both input and output."

Cassowary Solver for UI Constraints

• Cassowary (CJS), a JavaScript library, enables constraint solving for UI applications. Originally used in iOS Auto Layout.

"Cassowary is a fantastic library for doing constraint programming in JavaScript."

• It ensures relationships like total spending = defense + non-defense spending remain consistent, even when one variable is modified dynamically.

"The solver will automatically for us make sure that this relationship between the three variables always holds."

• Supports priority constraints to handle over-constrained systems (e.g., some constraints are "required," others are "nice to have").

"If you have problems that are over constrained where there's no complete solution, Cassowary will find you the best solution you can find."

Practical Implementation

• Basic interaction model:
• Mark a variable as being edited (beginEdit).
• Suggest new values (suggestValue).
• End editing (endEdit).
• Add constraints (stayConstraint) to keep certain variables fixed.

"The reason this is called Suggest and not set... is that this value might not lead to an actual solution."

• Using constraints simplifies complex relationships, such as progressive taxation and revenue calculations.

"Several very natural things fell out of writing the relationships that would have been a real pain to code by hand."

Limitations of Cassowary

• Only supports linear equations and numeric variables (e.g., it cannot handle quadratic constraints).

"C can only solve problems where the variables are numbers and it can only solve where the relationships between the numbers are linear expressions."

• Proposes improvements:
• Nonlinear constraint solvers (for geometric problems, e.g., keeping a point on a circle).
• MiniKanren & Core.logic for relational programming on non-numeric problems.

MiniKanren & Core.logic

• A relational programming model that generalizes constraints beyond numbers to trees, lists, colors, and abstract structures.

"MiniKanren provides relational programming just like we've been doing with Cassowary but over non-numerical problem domains."

• Example: Sudoku Solver in Core.logic solves the problem declaratively by defining constraints rather than writing procedural code.

"This looks like a statement of the problem of Sudoku, and yet this will run really fast and give us the answers."

• Benchmarks: A JavaScript Core.logic Sudoku solver runs 100x faster than Peter Norvig’s optimized Python version.

"This version which is not handwritten just happens to use a constraint solver works on average about a hundred times faster than Peter Norvig's Python code in JavaScript in the browser."

Future Directions: Cooperating Solvers

• Alan Kay’s Viewpoints Research Institute explores "cooperating solvers," where different constraint-solving techniques (dataflow, logical constraints) work together.

"How do they cooperate? There's some really interesting PDFs and example code showing how to do that."

• Potential applications:
• More powerful layout engines.
• Interactive problem-solving beyond algebraic constraints.

Bonus: Brett Victor’s Scrubbing Calculator

• Inspired by Brett Victor’s UI work, the speaker demonstrates an interactive "scrubbing calculator" implemented in Cassowary.

"This is an example of the kind of program that would be hard to write by hand unless you really want to write your own computer algebra system."

• Allows solving for any variable in an equation dynamically just by adjusting values interactively.

"If we had a real computer algebra system in JavaScript wouldn't that be great?"

Conclusion

• Advocates for constraint programming as a means to build more powerful, flexible UI applications.
• Suggests integrating constraint-based approaches in mainstream web development to create more intelligent, adaptive, and user-driven applications.

"If we want to build more powerful applications, we’ve got to give our users more leverage."

• Calls for open-source contributions to Cassowary and similar projects.

"C.JS is a fantastic one... let's go out and build more powerful user interfaces."

Summary of DevTools FM Podcast with Juan Capa on Membrane.io

Introduction and Background

• Juan Capa is the creator of Membrane.io, a still-in-development platform for simplifying API automation and internal tooling.

"Juan is the creator of membrane.io, a still-on-development platform for simplifying API Automation and internal tooling."_

• He has a background in game development, having spent over a decade working on console, mobile, and web games.

"I have a background in game development. I spent about 10 years a little bit more than 10 years working in game development."_

• Worked at Vercel on the CDN team after being hired through Twitter, then briefly returned to Zynga before joining Mighty under a program that allowed him to work part-time on Membrane.

"I saw a tweet by Guillermo Rauch ... He hired me to work for Vercel ... I spent two years there as the lead in the CDN team."_

"Then I guess my last last thing I did was join Mighty ... working on my startup but also working three days for them."_

• Now focusing on Membrane full-time and looking to onboard users soon.

"So yeah now I'm a member in 100 and yeah hoping that I can show to the world and onboard some users in the coming week or two."_

Membrane: Concept and Vision

• Membrane was inspired by game engines, where every entity is programmable and data is universally accessible.

"In game development, you’re dealing with this Engine with this universe, and this universe is completely programmable."_

• Aimed at simplifying API automation and small-scale applications, particularly for personal automation.

"It’s a place to write programs to build personal automation ... optimized for personal automation programs."_

• Membrane provides an abstraction over APIs, allowing users to interact with data and automate workflows through a graph-based system.

"The key to Membrane is this whole concept of a graph that is the main thing that programs use to manipulate the world."_

• Designed to be highly accessible by integrating with Visual Studio Code and leveraging JavaScript/TypeScript.

"The entire thing is built inside of Visual Studio Code ... The most used IDE is Visual Studio Code and the most used language is JavaScript."_

Durability & Orthogonal Persistence

• Membrane implements "orthogonal persistence," ensuring program state is always durable.

"I decided to start building what is sometimes called orthogonal persistence, which is this concept of a durable program."_

• Every Membrane program is an SQLite database, meaning all messages, state, and execution history are stored persistently.

"Every member program is actually just one SQLite database."_

• Programs execute with an event-sourcing model, where all inputs and outputs are first logged in SQLite before execution.

"Every message that it receives, it first goes in the database and then it's processed."_

• Uses Linux’s soft dirty pages for memory tracking, making it highly efficient in persisting only changed memory states.

"I use quickjs ... and there’s a constant in the Linux kernel called Soft Dirty Pages ... only serialize the pages that actually change."_

• Future improvements include optimizing serialization using WebAssembly’s linear memory model.

"I’m saving more data than I should, so there’s even more optimizations I can do."_

Observability & Debugging

• Membrane prioritizes perfect observability, logging every event to enable full program introspection and debugging.

"If it’s not in the logs, it didn’t happen."_

• Allows time-travel debugging, replaying past states and executions.

"You can go back to when that message was received and then run the code that was available back then."_

• Aims to support snapshot-based time travel for enhanced debugging.

"The first version I’m gonna have of that type of time travel is going to be with a snapshot that is taken every hour."_

Membrane’s Graph Model

• Membrane’s "graph" serves as a type-safe, unified interface for APIs.

"Everything is a node, which you can think of as an object or a scalar (string, number, JSON type)."_

• Drivers enable API connectivity, converting external APIs into Membrane’s schema and providing a consistent interface.

"The GitHub driver has a schema ... basically it mirrors the GitHub API as a Membrane schema."_

• Pagination is abstracted away, making API traversal seamless.

"With Membrane, you have this object that’s a one-page, and a page has a reference to the next page."_

• Users can mount different programs' graphs into their own, dynamically expanding their automation environment.

"Your graph is basically the combination of all the graphs of all your programs."_

Chrome Extension & API Interfacing

• Membrane includes a Chrome extension that recognizes API entities on webpages.

"What it does is it asks Membrane, ‘Hey, do any of the programs under Juan’s account recognize anything on this page?’"_

• Future improvements will allow automatic driver installation when encountering unrecognized APIs.

"Eventually, I can just offer you the option to install that driver with a click from the Chrome extension."_

• Currently requires users to provide their own API keys, but OAuth-based authentication is planned.

"Right now, you have to bring your own keys."_

Cron & Automation Features

• Membrane features built-in cron-like timers, which are stored in SQLite and visualized in the UI.

"The SQLite database has a table called timers, and that table holds all scheduled actions."_

• Users can visually track when timers will execute and manually trigger actions for testing.

"From Visual Studio Code, you can just hover on each timer and see how long until it fires."_

• Logs every timer execution, ensuring full transparency in automation workflows.

"If it’s not in the logs, it didn’t happen."_

Potential for Expansion & Future Vision

• Membrane’s approach is inspired by game development tooling, where objects and behaviors are always inspectable.

"In game engines, you’re dealing with objects where you can see all their properties and control them."_

• Aims to provide a seamless developer experience, where APIs become interactable entities without custom adapters.

"If you wanted to automate something with Twitter, you shouldn’t have to pre-install a driver."_

• Exploring self-hosting and open-source models to improve privacy and decentralization.

"Self-hosting membrane is going to be a thing ... I think I want to make it open-source."_

• Could enable mobile implementations, particularly for interacting with on-device automation.

"You could just access your Membrane graph from your phone."_

• Possibility of auto-generating API drivers from HAR files or OpenAPI specs.

"There are ways to generate API specs from network traffic ... from that API spec, you can generate the driver."_

Conclusion

• Membrane is a powerful tool aimed at making personal automation and API interaction seamless, leveraging game engine principles for maximum programmability.
• It provides persistent execution, deep observability, and a graph-based API abstraction layer that simplifies working with external services.
• With a focus on usability, it integrates tightly with VS Code and JavaScript while also offering innovative features like event sourcing, time travel debugging, and drag-and-drop API connections.
• The future of Membrane includes open-source possibilities, mobile integrations, and potentially eliminating the need for manually defining API adapters.
• It represents a new paradigm in developer tooling, where programs are durable, transparent, and universally programmable.

Introduction and Purpose

“I would like to tell you why fulcro is awesome and why it's much easier to learn than you might believe so we will look at what fulcro is and what it can do for you and why is it interesting...”

• Emphasizes that the talk aims to introduce Fulcro, explain its ease of learning, and highlight its benefits.

Speaker Background

“So first of all who is… I've been doing back-end development since 2006 and front-end development since 2014 on and off…”

• Establishes the speaker’s credibility with extensive development experience.

“...I built learning materials for Fulcro beginners and I pair program with and mentor my private clients on their first Fulcro project...”

• Demonstrates the speaker’s active role in teaching Fulcro to newcomers.

Motivation for Fulcro

“When I create web applications I want to be productive and I want to have fun… I don't want to have to manually track whether the data started loading or finished or failed…”

• Highlights the desire to reduce boilerplate and tedious manual tasks.

“I don't want to write tons of boilerplate and especially not to do that and again and again for every new type data in my application…”

• Stresses that Fulcro removes repetitive coding patterns, enhancing developer efficiency.

Choosing a Full-Stack Framework

“Now there are simpler Frameworks… or you can pick a full stack framework that has all the parts you need…”

• Explains how Fulcro’s integrated approach can be preferable to patching together multiple libraries.

“...malleable web framework designed for sustainable development of real world full stack web applications...”

• Defines Fulcro as a flexible system that supports complex, long-lived applications.

Key Fulcro Capabilities

“It can render data in the UI and it uses React so it's wraps React for that…”

• Confirms that Fulcro uses React under the hood for rendering.

“It can manage state… it keeps the state for you at some place… re-render the UI so it reflects that state…”

• Describes automatic state management and reactive re-rendering.

“It makes it easy to load data from the backend… you have full control...”

• Emphasizes the fine-grained control over data fetching.

“Fulcro also caches the data for you automatically and it does so in normalized form…”

• Highlights how normalized data storage simplifies updates across the UI.

“Fulcro has excellent developer experience for multiple reasons… the biggest is locality and navigability…”

• Points out how Fulcro keeps relevant code together, making it easier to navigate and maintain.

Core Principles

1. Graph API / EQL (Edn Query Language)

“...we use graph API instead of rest API which means that we have just a single endpoint and it's the front end which asks the back end for what data it wants by sending over a query…”

• Simplifies data retrieval by letting the client specify exactly what it needs.

• UI as Pure Function of State

“UI is pure function of state… components only ever get the data they need from their parent…”

• Removes side effects from the rendering flow.

• Locality

“...to understand the UI component I shouldn't be forced to jump over four different files… so in Fulcro a component doesn’t have only a body but also a configuration map…”

• Co-locates component queries, rendering, and logic in one place.

• Normalized Client-Side State

“...it stores that data normalized in a simple tabular form where entities contain other entities replaced with references…”

• Ensures any update in one place is reflected throughout the UI.

Architecture Overview

“...it's a full stack web framework so it has the front end and back end part… front end is Fulcro proper… the back end is Fulcro’s library Pathom…”

• Describes the division between the Fulcro client and the Pathom-based server.

“On the front end… we have client DB… we have a transactional subsystem… to the back end we have Pathom… as kind of adapter between the tree of data the UI wants and whatever data sources there are.”

• Clarifies how Fulcro’s client and server components communicate via EQL queries and mutations.

UI Rendering Process

“...UI is a tree of components and for each component we have a query… these queries are composed up so that the root component’s query is the query for the whole page.”

• Outlines how each component declares its data needs, culminating in a single root query.

“...Fulcro takes this query, combines it with the client DB, and forms a tree of data that matches the query shape, then hands it off to the root to render.”

• Demonstrates the round-trip from query to final rendered UI.

Component Example

“Here we can see how a Fulcro component looks in code… The most important part here is the query…”

• Provides a code snippet showing query co-location with the component.

“...the component also includes the queries of its child components so the parent can pass down just the needed data.”

• Reinforces that data flows naturally down the component tree.

Learning Fulcro

“People have this assumption or believe that Fulcro is hard to learn but it's not…”

• Dispels the notion of steep difficulty.

“There are simpler frameworks that do just one thing… but you need to handle a number of tasks and that you need to work across both front end and back end…”

• Explains why novices might find full-stack solutions initially overwhelming.

“You need to rewire your brain… if you come in expecting that things just work the way you expect you will be running into walls…”

• Advises a mindset shift for those accustomed to different paradigms.

Recommended Beginner Resources

“...the Fulcro Developer's Guide… it describes everything in great detail but it can be overwhelming…”

• Mentions the official documentation’s comprehensive nature.

“...start with the do it yourself Fulcro Workshop… play with the concepts in practice and see how they work...”

• Suggests hands-on learning as the best first step.

“...there's this minimalist Fulcro tutorial… tries to teach you the absolute minimum amount of things you need to know…”

• Recommends a focused tutorial that avoids overload.

Simplicity Through Principles

“Fulcro doesn't do any magic… its operation is straightforward and very much possible to understand…”

• Emphasizes that Fulcro’s complexity is principled, not opaque.

“...UI is pure function of data, standard input of data is the graph API, standard output of side effects is the transaction subsystem, and data is data, meaning queries and mutations are just data.”

• Summarizes how Fulcro simplifies data handling, state management, and side effects uniformly.

Demo Highlights

“So let's have a demo… a simple Fulcro application showing todo list…”

• Introduces a working demonstration of a to-do list in Fulcro.

“...every side effect goes through transaction subsystem so I should see data here and I do, I see that they are loading them…”

• Illustrates how Fulcro logs and displays all transactions for debugging.

“I can also see the response… the data mirrors the query… if I ask for something that doesn't exist I get back empty data…”

• Demonstrates the transparency of EQL-based queries and responses.

Conclusion and Key Takeaways

“Takeaways… that full stack frameworks are really useful and especially that Fulcro is really worth looking into and learning is not hard if you are a little smart about it…”

• Concludes that Fulcro offers an approachable path to building maintainable full-stack ClojureScript applications.

“Here are some awesome resources especially the Fulcro Community guide where you find the workshop and tutorial…”

• Reiterates the availability of community-driven materials to support new learners.

Summary of the Tech Talk on Software Development Leverage

Speaker's Background & Context

• The speaker has experience with nine startups, with four successes (defined as acquired or still operational).

  "I've been involved in nine startups, four successes so far, success defined as either bought by somebody else or still exists." - Core interests include minimal degradation over time, maximum architectural clarity, and minimal boilerplate.

  "I want to build systems that have a minimal amount of that maximum architecture clarity... I want a small number of Core Concepts and I also want minimal boilerplate." - Prefers Clojure and ClojureScript due to Lisp features, a REPL, macros, full-stack capabilities, and immutable data.

  "The main things are that it's a Lisp, I've got a REPL, I've got macros, I've got full stack language immutable data and literals."

Concept of Software Development Leverage

• Defines leverage in software as maximizing efficiency while minimizing incidental complexity.

  "What’s the minimal amount of code I can write to build these things?" - Software generally consists of forms and reports, and optimizing these elements reduces complexity.

  "A lot of what we write are forms or reports essentially." - Critiques past attempts at UI and form abstraction (e.g., Informix 4GL, Visual Basic, Rails, Java Enterprise) as insufficient or overly complex.

  "Every kind of library on the planet trying to do the same sort of thing." - Identifies challenges in leverage: short levers, fragile systems, opposing mindsets, and complex structures.

  "You can have too short of a lever, the object that we're trying to move could be too big for the lever, or my strength... I could have a crowd of people who are just philosophically opposed to levers."

Key Approaches to Leverage

• Minimal Incidental Complexity: Reducing unnecessary complexity that accumulates over time.

  "We love minimal incidental complexity... other communities don’t even think about that." - Functional & Immutable Data Models: Advocates for a pure functional approach to state management and UI rendering.

  "The state of the world is some immutable thing, initialized somehow, then I walk from step to step running some pure function." - Generalized Pure Functions: Aiming for functional purity while acknowledging that some dynamism is needed.

  "To me, you're starting by breaking the ideal. You're saying, 'I’m not really going to use pure functions for that.'" - Component-Based Rendering: Prefers data-driven UI, minimizing reliance on React’s event-based state management.

  "A pure function, a render of some sort of transform of the world."

Core Abstractions for Software Leverage

1. Entity-Attribute-Value (EAV) Model: A flexible, normalized data structure for representing application state.

   "The first one is just the power of entity attribute value." 2. Idents (Universal Entity Identifiers): Unique tuples ([type id]) for referencing entities.

   "The kind allows you to prevent collisions... useful semantic information." 3. Graph Queries: Uses EDN-like queries to efficiently pull and update data.

   "Attach logic to graph queries that say when you get the result of this query, here's how you normalize it." 4. Full-Stack Datified Mutations: CQRS-like abstractions over side effects and state transitions.

   "CQRS kind of idea... I’m going to make an abstract thing that says what I want to do."

Emergent Benefits of This Approach

• Normalized State Representation: Enables automatic merging of data, reducing complexity in state updates.

  "This gives me on my world, my immutable World in that diagram of kind of our idealized application." - Minimizing UI Boilerplate: Using annotated queries and data-driven components reduces manual UI code.

  "A UI location-specific way to annotate my UI... initial state is just a mirror of that." - Abstracting Side Effects: Remote calls and transactions become well-structured, reducing ad-hoc state management.

  "Transact things... processing system talks to remotes for side effects, talks to the database for local changes, and triggers renders."

State Machines for Process Control

• Advocates state machines for handling application logic, avoiding scattered imperative code.

  "Very often, process is just peppered around everywhere... having a state machine that abstracts over this is powerful." - Uses state charts (Harel state machines) for complex workflows like authentication.

  "State charts are way better when your state machine gets large."

Fulcro & RAD (Rapid Application Development)

• Fulcro: A ClojureScript-based framework built on these principles.

  "How do I simplify F? How do I get these core pieces generic enough to reuse?" - RAD: Built to automate UI and backend generation, minimizing redundant work.

  "I really wanted to minimize the boilerplate right... tired of handwriting schema." - Plugins for Databases, Forms, Reports, and APIs: Reduces custom implementation for common application patterns.

  "Datomic support gives me my network API and integration with Datomic in 1900 lines of code."

Key Takeaways

• Graph-based, normalized application state leads to better leverage and scalability.
• Functional purity where possible, and controlled side effects when necessary.
• Automatic UI and backend generation through metadata and introspection.
• Composable, small-core abstractions allow flexibility without unnecessary complexity.

"A very small number of Core Concepts... it's pluggable, you can escape from everything... it's just an annotated data model."

This approach significantly reduces the long-term maintenance cost of applications by emphasizing reusability, composition, and functional principles.

Summary of the Talk on the Future of CMS, No-Code, Low-Code, and AI-Generated Applications

Evolution of CMS and No-Code Tools

Traditional CMS:

"Back in the day it was like WordPress... the original web where we would write code and then we would just push it up to servers."

CMS emerged to allow non-developers to contribute to web content without coding.

No-Code Tools:

"No code is like your drag and drop GUI... Webflow or whatever."

Introduced drag-and-drop interfaces for broader accessibility, with pros and cons in usability.

AI in No-Code:

"Fast forward even further we've got AI coding right... now a person can just make an app."

AI models like Claude 3.5 enable app generation with minimal developer intervention.

Current No-Code/Low-Code AI Tools Landscape

Key Tools in the Market:

"Let's create the definitive list here... Cursor, Bolt, Lovable."

Cursor is for developers; Bolt and Lovable cater to non-developers with different strengths.

Strengths and Weaknesses:

"Bolt is a great boilerplate generator... Lovable is great if you want ShadCN styling."

Developers prefer Bolt for flexibility; Lovable is preferred for pre-styled design systems.

Challenges with AI-Generated Code

Integration Issues:

"It's not your existing code base... you need to use your components, design system, and backend logic."

AI-generated code often exists in isolation, making integration difficult for enterprise use.

Code Quality Concerns:

"Engineers are not going to want a pull request by a non-engineer."

Quality control and maintainability remain significant barriers.

Customization and Precision:

"Webflow is hard to use... but it gives you 100% precision control."

While AI provides convenience, fine-grained control is still preferred by professionals.

Future of AI-Driven Development

Combining AI with Structured CMS-like Workflows:

"Ideally, we have something like a headless CMS where we can make updates over API."

Future solutions should enable AI updates via APIs while maintaining design consistency.

Ideal Workflow Vision:

"In an ideal world, we can be editing with prompts and visually."

The goal is a hybrid model with AI-driven automation and manual precision controls.

AI-Based Iteration and Optimization:

"AI should listen to your customers... iterate really fast."

Faster feedback loops and continuous optimization through AI experimentation.

Technical Approaches to Solving Challenges

Meta's React Blocks:

"What React blocks let developers do is a backend dev in Python can code up a React UI."

An approach that allows dynamic UI changes without shipping new native app versions.

Mitosis Framework:

"Mitosis is a project that explores transpilation and visual manipulation."

Enables converting JSX into structured JSON for flexible rendering and AI-based updates.

Code-Driven Visual Editing:

"SwiftUI allows updating code with visual previews and vice versa."

Bidirectional code editing is a possible future solution but is still complex.

Current Limitations and Considerations

Performance and Feasibility Issues:

"When I had Google bots crawling my AI-generated site, I got a $4,000/day Anthropics bill."

Generating content in real-time is currently too expensive at scale.

Security and Compliance Risks:

"Dynamic code delivery is ripe with security challenges."

Any AI-driven solutions must consider performance, security, and governance.

Key Use Cases and Applications

Prototyping vs. Production:

"Phenomenal prototyping tools, but moving to production is challenging."

AI tools excel in concept validation but require extensive refinement for production.

Personalization Opportunities:

"The AI could automatically scale things up or down based on performance."

Future possibilities include hyper-personalized user experiences.

Conclusion and Outlook

Near-Term Expectations:

"Webflow and Framer will likely add more AI features over time."

Existing players are expected to incorporate AI capabilities gradually.

Long-Term Potential:

"AI tools will eventually iterate and personalize dynamically based on user input."

The convergence of AI, CMS, and design systems may redefine how software is built.

This summary captures the essence of the speaker's discussion, highlighting key concepts, industry trends, challenges, and possible future developments in the AI-powered CMS and no-code/low-code space.

Summary of JavaScript Frameworks - Heading into 2025 by Ryan Carniato

General Reflections on 2024

The pursuit of simplicity hasn’t simplified web development:

"The quest for simplicity hasn't resulted in making web development simpler."

Despite advancements, the overall complexity of web development persists.

Economic pressures have led to a cautious approach:

"Global economy tightening budgets and keeping solutions on the safe path."

The industry has recognized that complex problems have no silver bullet solutions.

A call for reflection and reassessment:

"It is a sobering thought but it gives me hope in 2025 that we can take some time and re-evaluate."

Returning to fundamentals has shown the need for a better balance.

The Server-First Movement

Resurgence of server-first frameworks:

"Making things 'server-first' has been the narrative over the last 5 years in the front end."

New meta-frameworks (SvelteKit, Astro, Remix, SolidStart, Qwik) and upgrades (Next, Nuxt).

Tension between SPA and MPA models:

"SPA-influenced isomorphic approaches up against MPA-influenced split-execution approaches."

New technologies such as Out-of-Order Streaming and Server Islands emerged.

Complexity in feature integration:

"When you assemble all these features, things are not so simple anymore."

It remains uncertain whether these advancements are truly solving core issues.

Return to traditional server approaches:

"Not wanting to wade through this mess, has led the conversation back to more traditional server approaches."

Server-side rendering (SSR) is being reconsidered, despite its lack of novelty.

Compilation as a Core Component

The role of compilation in modern development:

"Compilation is an ever-present aspect of JavaScript development."

It addresses shortcomings, improves performance, and introduces new capabilities.

React and Svelte’s contrasting compiler approaches:

"On one side we have the React Compiler... on the other, you have Svelte 5 Runes."

React optimizes re-renders, while Svelte adopts a fine-grained signals model.

Increased complexity due to compiler-driven optimization:

"Both choices come at the expense of increased complexity in tooling."

The trade-offs between simplicity and capability continue to evolve.

AI and Development Tools

AI's growing role in developer tooling:

"AI's impact on JavaScript frameworks themselves is still minimal."

While AI aids prototyping, it has yet to revolutionize core development.

AI-assisted performance optimization:

"MillionJS developer Aiden Bai got our attention again with React Scan."

Tools now analyze apps for re-render issues, though challenges remain.

Shift towards integrated AI support:

"Supporting tools rise up to meet that."

Projects like VoidZero suggest the future of integrated AI development workflows.

Emerging Trends for 2025

Pendulum swinging back to SPA-friendly approaches:

"We already have started seeing some of the swing back of the pendulum."

Frameworks like SvelteKit and SolidStart now offer SPA modes.

Local-first and sync engine technology gaining traction:

"How that is to manifest itself is still left to be seen."

Sync-first approaches may play a larger role in future web applications.

Slow and steady adoption of stable frameworks:

"Both Vue and Angular are frameworks I'd have my eye on this next year."

Reliable, well-supported frameworks remain attractive in uncertain times.

Challenges in adopting signals-based architectures:

"Developers are starting to understand the depths of tradeoffs present."

While signals improve performance, they come with complexity and learning curves.

Final Reflections

No major technological leaps anticipated in 2025:

"I'm not predicting some big technology leap in the next 12 months."

The focus is on refinement and thoughtful development.

Complexity remains a persistent challenge:

"We live in a world full of complexity and that doesn't appear to be changing."

Balancing complexity and usability is an ongoing struggle.

Encouragement to tackle interesting problems:

"Between you and me, this is the type of environment I thrive in."

Developers are encouraged to embrace problem-solving in a complex ecosystem.

This summary captures the key insights from the article while preserving clarity and depth, offering a comprehensive understanding of the current state and future outlook of JavaScript frameworks.

Below is a concise overview of the key concepts in the article “How Real-Time Materialized Views Work with ksqlDB, Animated.” It explains:

1. What Real-Time Materialized Views Are
2. A real-time materialized view is a continuously updated “pre-aggregated” or “read-optimized” result of incoming streaming data.

3. Instead of recalculating the entire view on demand (as in many traditional databases), stream processing incrementally updates the view with each new event (the “delta”).

4. How ksqlDB Maintains These Views

5. Continuous Queries: When you write a SQL-like query in ksqlDB (e.g., CREATE TABLE ... SELECT ... FROM readings GROUP BY ... EMIT CHANGES;), ksqlDB creates a persistent query that runs forever, reading new events from Kafka topics and updating the view.

6. Incremental Updates + Changelog: As ksqlDB updates the materialized view in its local state store (RocksDB), it also emits a new record to a changelog topic in Kafka that captures the change.

   • This changelog topic is essentially the “audit log” of every update.
   • The local RocksDB store is fast but treated as transient; changelog topics in Kafka provide durability and fault tolerance.

7. Push vs. Pull Queries

8. Pull Queries ask for the current state of the materialized view at the moment you run the query (e.g., SELECT * FROM avg_readings WHERE sensor=...;).

9. Push Queries subscribe to changes as they happen (e.g., SELECT * FROM avg_readings EMIT CHANGES;). You get a continuous stream of updates whenever a new change arrives.

10. RocksDB as the Local Store

11. Each partition of the input stream(s) to a ksqlDB query is associated with its own local RocksDB instance.
12. RocksDB stores the current state needed for aggregations, joins, etc.

13. Because data is partitioned, all rows with the same key end up on the same partition (and thus the same RocksDB instance).

14. Automatic Repartitioning

15. If your grouping key is not the same as the original Kafka key, ksqlDB must shuffle data so that rows with the same group key end up on the same partition.
16. This shuffle is automatically handled by creating a *-repartition topic.

17. If your original keys are already aligned with the grouping columns, ksqlDB skips this shuffle to save I/O.

18. Fault Tolerance via Changelogs

19. If a ksqlDB node dies, a new node can rebuild the materialized view by replaying the changelog from Kafka.
20. Changelog topics use log compaction, which removes older updates to each key, keeping only the latest.

21. This keeps replay time manageable (rather than applying every single historical update).

22. Latest-by-Offset Aggregations

23. Besides sum, min, max, or average, ksqlDB also supports “latest by offset” to store just the most recent value for each key, effectively creating a “recency cache.”
24. Example:<br /> sql CREATE TABLE latest_readings AS SELECT sensor, LATEST_BY_OFFSET(area) AS area, LATEST_BY_OFFSET(reading) AS last FROM readings GROUP BY sensor EMIT CHANGES;
    • This ensures the table always reflects the last known value for each key (based on Kafka offset).

Why This Matters

• Fast Queries: Because the materialized view is already “pre-aggregated,” queries against it are extremely fast—no need to scan or recalculate everything from scratch.
• Real-Time Updates: The view is updated continuously as new data arrives, so you always have a near-real-time representation of what is happening.
• Scalable & Fault-Tolerant: Using Kafka’s partitions and log compaction for changelogs, ksqlDB scales horizontally (across multiple nodes) and recovers state quickly when nodes fail.

Further Resources

• Try It Out
• The ksqlDB quickstart is a straightforward way to experiment locally.
• Once it’s running, you can execute the code examples in the article to see real-time materialized views in action.
• Next Steps
• Deep dive into ksqlDB’s fault tolerance and scaling model (i.e., how queries distribute across clusters).
• Explore additional stream processing patterns such as windowed aggregations for time-based summaries.
• Learn how joins work between tables and streams in ksqlDB (similar incremental update logic, but with different partitioning considerations).

In essence, real-time materialized views in ksqlDB let you maintain continually up-to-date “snapshots” of streaming data. By storing incremental results in a local state store and capturing updates in a Kafka changelog, ksqlDB can serve extremely fast queries, recover quickly from failures, and scale out for large data volumes.

Introduction and Context

• The speaker acknowledges the significance of the event, as it coincides with the 25th anniversary of Smalltalk's creation.

  "This conference on this day is pretty much in the epicenter of the 25th anniversary of Smalltalk."

• The talk is not intended to be historical but rather to provide insights into the evolution and current relevance of object-oriented programming (OOP).

  "I don't want to I'm not going to give a historical talk because I finally discharged those obligations."

Early Computing Insights

• Early programs in the 60s were mechanical and small, akin to interlocking gears, with a heavy influence from mathematics.

  "Programs were quite small and they had a lot in common with their mathematical antecedents."

• Scaling challenges are illustrated using the analogy of dog houses vs. cathedrals, where naïve scaling leads to collapse.

  "When you blow something up by a factor of 100, it gets about a factor of 100 weaker."

Object-Oriented Programming (OOP) and Abstraction

• OOP was conceived to manage growing complexity, emphasizing architecture over raw materials.

  "Part of the message of OOP was that as complexity starts becoming more important, architecture is always going to dominate material."

• The Air Force’s early approach to data abstraction in 1961 is highlighted as a precursor to OOP concepts.

  "Somebody came up with the following idea: on the third part of the record on this tape, we'll put all of the records of this particular type."

Limitations of Current Systems

• Criticism of modern systems, particularly HTML, which reintroduces archaic dependencies on browsers.

  "HTML on the internet has gone back to the Dark Ages because it presupposes that there should be a browser that should understand its formats."

• Object-oriented thinking should align more with biological models rather than mechanical systems to achieve scalability and maintainability.

  "Computers should realize their destiny by learning from biology."

Encapsulation and Polymorphism

• Encapsulation is key to building scalable systems; the internal state of an object should not affect the overall system.

  "You must must must not allow the interior of any one of these things to be a factor in the computation of the whole."

• Polymorphism enables objects to act as flexible service providers, facilitating interoperability across systems.

  "Polymorphism allows us to define classes of these services and interact in a general way."

Challenges with Modern Programming Approaches

• C++ and Java fail to capture the true essence of OOP, focusing too much on old paradigms rather than leveraging new metaphors.

  "The most pernicious thing about languages like C++ and Java is that they think they're helping by looking like the old thing."

• The lack of metaprogramming in Java is seen as a significant hindrance to its evolution and adaptability.

  "When I looked at Java I thought, my goodness, how could they possibly hope to survive without a meta system?"

Lessons from Biological Systems

• Biological systems, such as bacteria and cells, provide a model for growth and adaptability that software should aspire to replicate.

  "Cells not only scale by factors of a hundred but by factors of a trillion."

• The success of the internet is attributed to its ability to replace every component over time without needing to stop.

  "The internet has expanded by a factor of 100 million and has never had to stop."

Future of Object-Oriented Systems

• A move towards universal interoperability through unique identifiers such as URLs and IPs for every object is necessary.

  "Every object should have a URL because what the heck are they if they aren't these things?"

• Future systems should be designed with the ability to dynamically evolve without requiring downtime.

  "Growing systems without shutting them down is crucial for future success."

Critique of Programming Culture

• The programming community tends to take single perspectives too seriously, leading to dogmatism rather than evolution.

  "Taking single points of view and committing to them like religions is the biggest challenge in our field."

• Smalltalk’s success was not in its syntax but in its ability to continuously evolve and support innovation.

  "The thing I’m most proud of is that Smalltalk has been so good at getting rid of previous versions of itself."

Conclusion

• The speaker encourages a mindset of continuous improvement and pushing current systems to achieve their full potential.

  "Just play it grand, and always play your systems more grand than they seem to be right now."

Introduction and Context

• The speaker acknowledges the significance of the event, as it coincides with the 25th anniversary of Smalltalk's creation.

  "This conference on this day is pretty much in the epicenter of the 25th anniversary of Smalltalk."

• The talk is not intended to be historical but rather to provide insights into the evolution and current relevance of object-oriented programming (OOP).

  "I don't want to I'm not going to give a historical talk because I finally discharged those obligations."

Early Computing Insights

• Early programs in the 60s were mechanical and small, akin to interlocking gears, with a heavy influence from mathematics.

  "Programs were quite small and they had a lot in common with their mathematical antecedents."

• Scaling challenges are illustrated using the analogy of dog houses vs. cathedrals, where naïve scaling leads to collapse.

  "When you blow something up by a factor of 100, it gets about a factor of 100 weaker."

Object-Oriented Programming (OOP) and Abstraction

• OOP was conceived to manage growing complexity, emphasizing architecture over raw materials.

  "Part of the message of OOP was that as complexity starts becoming more important, architecture is always going to dominate material."

• The Air Force’s early approach to data abstraction in 1961 is highlighted as a precursor to OOP concepts.

  "Somebody came up with the following idea: on the third part of the record on this tape, we'll put all of the records of this particular type."

Limitations of Current Systems

• Criticism of modern systems, particularly HTML, which reintroduces archaic dependencies on browsers.

  "HTML on the internet has gone back to the Dark Ages because it presupposes that there should be a browser that should understand its formats."

• Object-oriented thinking should align more with biological models rather than mechanical systems to achieve scalability and maintainability.

  "Computers should realize their destiny by learning from biology."

Encapsulation and Polymorphism

• Encapsulation is key to building scalable systems; the internal state of an object should not affect the overall system.

  "You must must must not allow the interior of any one of these things to be a factor in the computation of the whole."

• Polymorphism enables objects to act as flexible service providers, facilitating interoperability across systems.

  "Polymorphism allows us to define classes of these services and interact in a general way."

Challenges with Modern Programming Approaches

• C++ and Java fail to capture the true essence of OOP, focusing too much on old paradigms rather than leveraging new metaphors.

  "The most pernicious thing about languages like C++ and Java is that they think they're helping by looking like the old thing."

• The lack of metaprogramming in Java is seen as a significant hindrance to its evolution and adaptability.

  "When I looked at Java I thought, my goodness, how could they possibly hope to survive without a meta system?"

Lessons from Biological Systems

• Biological systems, such as bacteria and cells, provide a model for growth and adaptability that software should aspire to replicate.

  "Cells not only scale by factors of a hundred but by factors of a trillion."

• The success of the internet is attributed to its ability to replace every component over time without needing to stop.

  "The internet has expanded by a factor of 100 million and has never had to stop."

Future of Object-Oriented Systems

• A move towards universal interoperability through unique identifiers such as URLs and IPs for every object is necessary.

  "Every object should have a URL because what the heck are they if they aren't these things?"

• Future systems should be designed with the ability to dynamically evolve without requiring downtime.

  "Growing systems without shutting them down is crucial for future success."

Critique of Programming Culture

• The programming community tends to take single perspectives too seriously, leading to dogmatism rather than evolution.

  "Taking single points of view and committing to them like religions is the biggest challenge in our field."

• Smalltalk’s success was not in its syntax but in its ability to continuously evolve and support innovation.

  "The thing I’m most proud of is that Smalltalk has been so good at getting rid of previous versions of itself."

Conclusion

• The speaker encourages a mindset of continuous improvement and pushing current systems to achieve their full potential.

  "Just play it grand, and always play your systems more grand than they seem to be right now."

Cono Elliot's work on notational design and his influential papers - Cono got his PhD at Carnegie Mellon University in the '90s under Frank Fenny working on higher order unification. - Cono has devoted his life to thinking and refining graphic computation and tools behind it, and has published influential papers on various topics related to functional programming and notational design.

Living in a forest setting with deep connection to nature. - Conor lives on 20 acres next to his family's 60 acres and has a deep emotional connection to the place because of his parents' presence. - He sees a connection between nature and technology, highlighting the non-sequential nature of computation and neurology.

We are in a pre-scientific age of thinking about computation. - Humans have created thinking organisms that think systematically, leading to computation. - We are in an awkward phase of thinking about computation in a clumsy and pre-scientific way.

Humans are driven by curiosity to understand the universe. - We have a limited ability to perceive the universe due to our evolutionary constraints. - Through the advancement of science and technology, we have developed tools like telescopes, microscopes, high-speed cameras, and time-lapse to enhance our perception.

Elegance and wonder in computer science - Elegance is the deepest value in computer science, inspiring a sense of play and wonder. - Computer science is in a deeply inelegant phase, but there is potential for Elegance and Beauty in the field.

Elegance as a guiding value in theoretical physics - Elegance guided Einstein in developing the special and general theory of relativity. - Modern civilization is built on general relativity and quantum physics; GPS system corrects for relativity.

Elegance and simplicity in formalizing concepts in computer science - Elegance and simplicity in formalizing concepts are related - People often mistake familiarity for simplicity in programming

Academia today lacks time for critical thinking - Focused on churning out papers and credentials - Issue of education accessibility affecting teaching quality

Semantics is crucial in programming - Meanings are called semantics - The relationship between a program and its meaning is important

Dana Scott answered the crucial question of the mathematical meaning of Lambda calculus in 1970. - Lambda calculus was originally intended for encoding high order logic and quantifiers, not for programming. - Peter Landon realized the potential of Lambda calculus for programming and introduced the concept of executing Lambda calculus on a machine.

Languages convey meanings, computation looks at meanings. - Languages and programming languages serve the same purpose: to convey meanings. - Computation and technological tools help us observe and understand meanings in various forms, from stars and quasars to microorganisms and atoms.

Euclid revolutionized geometry with his conceptual approach - Introduced a new way of thinking about geometry with axioms and postulates - Plato's influence on the idea of mathematical space and its relation to the physical world

Mathematics describes real truth and possibly taps into platonic truth. - Platonist perspective considers mathematics as a way to describe truth beyond us. - Success of mathematical fantasy or story inspires acting as if tapping into platonic truth.

Ancient beliefs about movement of stars and planets - Stars and planets thought to move in circular paths due to perfection/God concept - Some stars behaved differently, known as 'The Wanderers' or planets

Kepler discovered planetary laws - Planets move in an ellipse, not a circle - Kepler's explanation lacked why planets move in an ellipse

Scientific theories evolve with enhanced observations - Newton's theory successful until discrepancies discovered in the 20th century - Einstein's theory validated through observations of planet Mercury during solar eclipse

Scientific exploration is an unending journey - Science aims to understand what we don't know - In academia, the system often fails to reward wonder and not knowing

Denotational semantics helps distinguish beauty and elegance from complexity - Beauty or elegance in theory is described precisely in terms of mathematics - Fortran, led by John Backus, introduced expressions, advancing from Von Neumann style sequential programming

Functional programming emphasizes expressions over statements - Fortran blends statements and expressions but still leans towards statements - Functional programming eliminates everything except expressions

Hardware limitations led to sequential model prototyping - John Von Neumann's experiment from 1947 is still relevant in 2022 - John Backus discussed fundamental problems in computing during the war

Von Neumann bottleneck affects computer performance. - Physical bottleneck slows computers due to high heat generation. - Mental bottleneck limits brain capacity and mental efficiency.

Breaking out of the Von Neumann bottleneck - The Von Neumann style of programming forces us to think small and is fundamentally sequential and mechanistic. - The lecture emphasizes the importance of thinking in larger, powerful notions and focusing on functions rather than words.

Functions as building blocks for knowledge - Functions built from other functions allow for scalability and creation of complex systems - Importance of denotational semantics in designing new languages rather than just explaining existing ones

Backus emphasized fixing defects and learning from mistakes. - Using denotational semantics reveals detailed defects in existing languages. - Advancement in computer science involves replacing outdated concepts like go-to with structured and functional programming.

The cost of focusing on education and progress is losing the ability to make significant advances in science. - The speaker expresses disappointment with the impact of Academia on progress and science. - The speaker remains dedicated to truth and beauty, advocating for the importance of denotational semantics in making aesthetic distinctions.

Ideas are expressions of beauty or ugliness which give deep insights across fields. - Denotational semantics serves as a reliable guide to beauty and elegance in ideas. - Beauty and elegance are valuable guides for understanding the universe and computation.

Passion for mathematics and computer graphics - Attended undergrad in math at UC Santar with a small group of math students in a nurturing environment - Transitioned to grad school at Carnegie Mellon for computer science and pursued computer graphics due to love for geometry and math

Had to change plans at Carnegie Mellon - Arrived at CMU to study computer graphics, but found out the people I wanted to study with had left - Discovered a group focusing on reasoning about programs, which became the focus of my PhD work

Transition to computer graphics and involvement in group projects - Worked with notable advisors like Dana Scott, John Reynolds, and Frank - Focused on exploring the next advancements in programming interfaces and data structures at Sun Microsystems

Introduction to denotational semantics in understanding language meanings - Studied denotational semantics under Stevenh Brooks and Dana Scott in grad school, leading to a revelation on language meanings - Believes language meanings should be independent of specific machines and analyzed compositionally for better understanding

Graphics programs are sequential commands organizing video memory for visual output. - Graphics programs are different from traditional software due to their focus on organizing instructions for video memory. - Alternative design paradigms focus on conveying meanings and inventing tools to help users view desired content through a computer.

Designing a language library for geometry and colors - Creating a composable vocabulary of geometry and colors, similar to modern linguistic frameworks - Developing a rich system of types for three-dimensional geometry and adding a time component to the design

Rendering graphics offscreen to build up incrementally for a correct answer. - Rendering offscreen allows showing previous true things before replacing them incrementally. - Temporal discreetness in computer graphics breaks compositionality and introduces fundamental bugs.

Compositional models with approximations lose accuracy when composed - Compositional models incorporating approximations result in gross inaccuracies upon composition - Functional reactive programming involves composing before approximating for accurate results

Outline fonts are resolution independent - Outline fonts are continuous and do not have pixels when zoomed in - Switching from bitmap graphics to outline fonts improves efficiency and clarity

Transition from discrete to continuous programming in space and time. - Examples of continuous programming in space like fonts, 2D and 3D geometry, vector graphics. - Applying continuous programming principles to time requires a fundamental shift in implementing and describing things that vary with time within the Von Neumann model.

John Reynolds introduced the idea of using functions from the reals instead of sequences for solving time interpolation problems - This approach helped in resolving issues with interpolations and time manipulation - Continuous time modeling was found to be more effective than discrete modeling for things that vary with time

Functional programming requires a shift from loops to lazy lists - Functional programming involves describing the mathematical model behind the data manipulation - The common reasoning that input and output data should have the same nature is wrong in functional programming

Functional reactive programming is about understanding concepts in the simplest, most elegant compositional terms. - It emphasizes denotational semantics, where types have a mathematical model. - It focuses on fully explaining operations in terms of the model, independent of implementation.

Programming expresses ideas with clear understanding before implementation - Category Theory is appreciated for its precise and elegant tools in mathematics - Functional Reactive Programming lacks denotational and compositional principles, leading to fundamental misunderstandings in programming

Algebraic patterns like monoids and distributivity are powerful for organizing reasoning - There are different types of monoids like addition and multiplication each with their own properties - Multiplication distributes over addition and zero plays a special role in this interaction

Algebra and category theory provide reusability and reasoning in mathematics and programming. - Algebra allows for reasoning that is parameterized and applicable to different mathematical scenarios. - Category theory generalizes various algebraic concepts and is important for correctness in programming.

The complexity of Python programs and limited cognitive abilities can lead to a lack of understanding. - Options include quitting the profession or divorcing what you've seen from what you do. - Another option is switching to a language with simple semantics, such as purely functional or denotative languages.

Denotative programming allows for proving program correctness. - Denotative programming enables answering questions about the multiple meanings of programs. - Functional programs can have meanings within a cartesian closed category.

Tropical semi-rings relate to timing analysis of parallel computations. - Understanding operations of plus and max in relation to semi-rings. - Realization of dot products and matrix multiplication pattern in timing analysis.

Timing analysis can be described compositionally using the language of categories - I realized the parallel sequential composition is the fundamental building blocks of functions computation - The type Lambda calculus has more than one model, and the mathematical values it describes can have different interpretations

Realizing the connection between HCLL and lambda calculus led to successful compilation to hardware. - HCLL translates to a small core lambda calculus - Interpreting lambda calculus in cartesian closed categories enabled successful compilation to hardware

Exploring unconventional categories for computation - Discovering powerful ideas by compiling categories since 1980 - Seeking beauty in solutions to drive innovation and never settling for unsatisfactory answers

Geometry and the introduction to proof changed my life - The systematic way of exploring what is true and growing knowledge in geometry was a life-changing concept for me. - Discovering computers at Lawrence Hall of Science through the Star Trek Club in high school eventually led me to computation.

Introduction to programming through games on teletypes - Experiencing games and printing out results on rolls of paper as souvenirs - Discovering source code hidden in the printed paper, initiating an interest in programming

Started college with no computer science department, emphasized logic and enjoyed math contests - Computer science classes offered in math department or College of Engineering - Discovered talent and passion for math despite discouragement from elementary school teacher

The origin of computer science in universities and its impact on its development - Initial classes were labeled as Computer Science or logic, sparking a debate on department placement. - Placement in engineering rather than mathematics influenced the practical nature of computer science education.

Transition from imperative to functional programming - Discovered Haskell as a better alternative to imperative programming languages - Applied Haskell in programming for 25+ years and mentorship in hardware design for machine learning

Realizing the power of category theory in simplifying automatic differentiation - Changed vocabulary to be more symmetric with respect to composition - Describing automatic differentiation in the language of categories simplifies and generalizes it

Denotational design is key for software implementation - HLL was not effective for teaching denotational design - Inner guidance essential for understanding and using HLL effectively

Struggling with teaching denotations and homomorphisms in programming - Encountered issues with students not understanding correct implementations - Wanted compiler to indicate errors instead of personally correcting

Understanding the question is more important than answering it correctly - Operational thinking is about biases in answering problems and questions - The most important thing is to understand the question in the most beautiful way

Realization about teaching and learning process - Programmers differ in their attitude towards being told they're wrong - Importance of being open to feedback for growth in programming

Automation has benefits but limited scalability - SMT automation has advantages in problem-solving but faces scaling limitations - Despite advancements, SMT technology cannot achieve unlimited scalability

Agda is the most tasteful tool for working with dependent types. - Agda offers beauty, consistency, simplicity, and tremendous power. - Agda contributes to an incredibly beautiful story about the equivalence of computation, logic, and the foundations of mathematics.

Exploring if all of mathematics can be built on logic - David Hilbert's attempt to formalize logic in the early stages - Can natural numbers be understood via logic as a foundation?

Natural numbers are a profound and important concept - Natural numbers are a product of human construction on top of other systems - Piano numbers are a significant concept in mathematics

Constructive logic allows expression of proofs as either A or B - In constructive logic, every proof of A or B can be expressed as a proof of A or a proof of B - Brower's logic allows for this expression without the law of excluded middle, leading to simple answers for negation, implication, truth, and falsehood in terms of types.

De bruyne pioneered logic computable through computers - Exploration of dependent typing and realization of logic and types - Mechanization of information and manipulation, leading to modern programming languages

The power of math and knowledge in programming - Manipulating from the bones is a powerful and beautiful concept - Embracing sequential stateful notion of computation limits insights and learning

Written language enabled deep reflection and improvement of ideas. - Written language allowed ideas to be examined and improved over time. - Written language initiated a feedback loop for continuous enhancement of concepts.

Continuous improvement through iterative optimization - Iteratively refining program logic and expressions for efficiency and clarity. - Enhanced abstraction and reusability through denotational design and parameterization.

The debate on using formal proofs in industry - Industry perspective often argues against formal proofs due to perceived time constraints and impracticality. - Decision to use formal proofs depends on the objectives and the value placed on accuracy and thoroughness.

Achieving 100% correctness is the only way to reach 95%. - Errors compound, leading to significant deviations in calculations. - Approximations and probable correctness can lead to overall incorrectness in complex projects.

Inspired by deep conversation - The conversation has been engaging and has touched on major topics of interest. - The speaker hopes to discuss denotational design and its application in software design.

Create space for contemplation in the age of instant information - Encourage meditation and reflection on content - Announcement about a dedicated email for audience feedback and inquiries

• Definition and Promise of Reactivity

  “Reactivity is the future of JS frameworks! Reactivity allows you to write lazy variables that are efficiently cached and updated, making it easier to write clean and fast code.”

  • The article frames reactivity as a foundational approach for modern JavaScript frameworks, emphasizing its power to optimize code by caching and selectively recalculating only what changes.

• Introduction to Reactively

  “I’ve been working on a new fine grained reactivity libary called Reactively inspired by my work on the SolidJS team.”

  • Reactively is presented as a fine-grained, “tiny (<1 kb)” library that focuses on lazy variables, caching, and incremental recalculation, aiming to be “the fastest reactive library in its category.”

• Core Functionality Example

  “Here’s an example of using Reactively for a lazy variable:”

  • The provided code snippet (with reactive(10) and a deferred fetch) illustrates how Reactively defers computations and retrieves data only when needed, ensuring on-demand execution for performance benefits.

• Dependency Graph Awareness

  “Reactive libraries work by maintaining a graph of dependencies between reactive elements.”

  • By automatically detecting and organizing which reactive elements depend on which sources, libraries like Reactively minimize developer effort and maximize performance by only re-executing relevant nodes in the graph.

• Wide Use Across Frameworks

  “Reactivity libraries are at the heart of modern web component frameworks like Solid, Qwik, Vue, and Svelte.”

  • Fine-grained reactivity is not limited to standalone libraries; it also underpins the state management logic of multiple popular front-end ecosystems.

• Primary Goals of Reactive Libraries

  “The goal of a reactive library is to run reactive functions when their sources have changed.”

  • Two fundamental objectives emerge—efficiency (avoiding unnecessary computations) and glitch-free updates (ensuring all dependencies are in sync before rendering to the user).

• Lazy vs. Eager Evaluation

  “Reactive libraries can be divided into two categories: lazy and eager.”

  • Eager libraries update as soon as a source changes, while lazy libraries defer recalculation until the value is explicitly requested. Each approach has implications for performance optimizations and complexity handling.

• The Diamond Problem & Equality Check Problem

  “Evaluating D twice is inefficient and may cause a user visible glitch.”

  • Eager libraries often face the “diamond problem” (risk of double-updating downstream nodes), while lazy libraries must handle the “equality check problem” (e.g., re-checking parents unnecessarily if the value hasn’t changed).

• MobX Algorithm

  “MobX uses a two pass algorithm, with both passes proceeding from A down through its observers.”

  • MobX solves the diamond problem by a “count” mechanism across two phases, ensuring every dependent node is updated exactly once and in the correct order, also tracking whether a parent’s value has changed for equality checks.

• Preact Signals Approach

  “Preact checks whether the parents of any signal need to be updated before updating that signal. It does this by storing a version number on each node and on each edge…”

  • Preact employs version numbers and a two-phase “down” and “up” traversal. This allows quick detection of stale nodes without re-walking the entire graph when no real changes occur.

• Reactively’s Graph Coloring Mechanism

  “Instead of version numbers, Reactively uses only graph coloring.”

  • Reactively marks changed nodes as red (dirty) and their children as green (check). An “up” phase (updateIfNecessary()) recalculates only if a node or any of its ancestors is red, then cleans the graph state once values are confirmed.

• Benchmarks and Observations

  “Reactively is the fastest (who would’ve guessed 😉).”

  • Although performance differences are often negligible for typical app use, experiments show Reactively performing strongly under heavy load, with Solid excelling in wide graphs, and Preact Signals being both swift and memory-efficient.

• Memory Management & Data Structures

  “In a future blog post we'll look at the data structures and optimizations used in each framework…”

  • Beyond the core update algorithms, internal implementation details—like how each library manages and structures reactive nodes—play a crucial role in overall speed and memory usage.

• Overall Conclusion

  “Most important is that the framework not run any user code unnecessarily.”

  • Across modern fine-grained reactive libraries, the central guiding principle is to avoid superfluous work. The focus remains on providing glitch-free, lazy or eager updates while preserving efficiency and correctness.

• Motivation & Purpose of the Talk

  “This talk is called I see what you mean what a tiny language can teach us about gigantic systems… which sort of uh formed the rock on which I built all of my thesis work.”

  • Alvaro introduces a small, “tiny” language (Dedalus) that explores how to effectively build and reason about distributed systems by focusing on semantics rather than purely operational details.

• Importance of Abstraction & Its Pitfalls

  “Abstraction is a thing… arguably the the the best tool that we have in computer science… but sometimes it’s harmful.”

  • While abstraction helps manage complexity, it can also hide essential details about distributed behavior and lead to design failures (e.g., RPC “leaking” distributed complexity).

• Division Between “Infrastructure Programmers” and “Users”

  “We tend to think of abstractions as these fixed boundaries, you know these walls… we put us right we put the Geniuses the infrastructure programmers the 10x Engineers below the wall… who goes above the wall well the the despised users.”

  • Alvaro criticizes the mindset that library writers and library users are separate classes of people; instead, we all alternate between these roles.

• Spark for a Declarative Approach

  “…if you kind of squint your eyes the work that I was doing in those two modes [C code vs. SQL queries]… it wasn’t really that different.”

  • Observing that data wrangling in both imperative and declarative styles shares core similarities prompted an interest in “could you write distributed systems using a logic/query language?”

• Model-Theoretic Semantics & Queries

  “…model theoretic semantics say that no no the meaning of a program is precisely the structures that make the statements in the program true… data becomes a Common Language…”

  • A logic-based or query-based approach allows mapping “programs” to “outcomes” directly through data, making correctness and debugging potentially clearer than in purely imperative styles.

• Data Log & Concurrency

  “Data log is interesting because we see that there's this Rich intimate connection between talking about what you don't know and having to commit to particular orders to get deterministic results.”

  • Data log provides a unifying lens for data, but the addition of recursion, negation, and timing must be carefully managed to keep semantics deterministic in distributed settings.

• Introducing Dedalus (pronounced ‘Day-Duh-Luss’)

  “So the idea is we want to take that clock and rify it, make the clock a piece of every uh unit of knowledge that we have… time is just a device that was invented to keep everything from happening at once.”

  • Dedalus extends data log with explicit time and asynchronous rules so programmers can represent mutable state, concurrency, and message ordering in a precise logical framework.

• Three Rule Types in Dedalus

  “…we say you know every every record has a time stamp… deductive rules say the conclusion has the same time stamp as the premise… inductive rules say the conclusion has one Higher Tim stamp… asynchronous rules say hey look there's this infinite domain of time we randomly pick from it…”

  • Dedalus’s key contribution is capturing “now,” “next,” and “eventually” semantics, reflecting real-world distributed behaviors (e.g., immediate local inference vs. future state vs. network delays).

• State as “Induction in Time”

  “…unlike in databases which with having no time had only state in Dedalus there is no state… state is what you get when you say when you know something then you know it at the next time and by induction you keep knowing it.”

  • Dedalus reframes state changes as an inductive process on discrete time steps, allowing logic-based reasoning about mutation.

• Confluence & Determinism

  “If we take away that pesky negation… or with very carefully controlled negation… monotonic… we know that negation free or monotonic more broadly Dedalus programs are confluent… they're deterministic without coordination.”

  • By restricting programs to monotonic logic (no negative conditions or well-controlled negation), a system can behave deterministically despite asynchronous execution and failures.

• Significance for Distributed Systems

  “…there’s this Rich intimate connection between… the meaning of programs, the uniqueness of a model… and this really valuable systems property of deterministic outcomes…”

  • Dedalus reveals how purely logical constructs (stable models, minimal models) can correspond directly to reliable, deterministic distributed protocols in practice.

• Legacy & Extensions

  “…on top of Bloom we built Blazes… that allow programmers… exactly why they aren’t if they aren’t [deterministic]… lineage driven fault injection… we can prove that our programs are fault tolerant…”

  • Dedalus’s ideas led to subsequent systems like Bloom, Blazes, and lineage-driven fault injection that leverage logic-based reasoning to auto-generate or verify coordination strategies.

• Closing Thoughts & Academic Invitation

  “We don’t do a good enough job respecting our users… If any of you are interested in spending the next five or six years screwing around inventing languages Building Systems with them… I’m looking for PhD students.”

  • Alvaro emphasizes user-focused abstractions, fluid design, and invites new students to further this research in language-driven system development.

Overview of a keynote on a tiny programming language and its impact on systems. - Peter Alvaro discusses the development of the programming language Deus at UC Berkeley and its significance. - The talk includes a mix of personal insights and technical elements about language design and semantics.

The significance of abstraction in software design and its implications. - Abstraction helps in managing complexity by hiding unnecessary details and exposing only essential functionalities. - While abstraction fosters innovation, it can lead to complacency if perceived as fixed boundaries.

Speaker discusses personal journey from novice to professional coder. - Became a coder in the Bay Area around 2000, working at a company called Ask Jeeves. - Balanced roles in infrastructure coding with C and data reporting using SQL, feeling skilled in both.

Explores the use of SQL for general-purpose distributed systems. - Data wrangling in SQL provides clearer rules for data manipulation compared to traditional programming. - SQL fosters a more intuitive connection between programming logic and outcome semantics, enhancing debugging and correctness.

Understanding complexities in reliable messaging over faulty networks. - Alice and Bob's communication can face message loss and reordering, complicating reliability. - Calculating correct outcomes during message reception involves considering numerous execution scenarios.

Understanding outcomes requires examining the properties of functions f and g. - If function f is commutative, certain variables become irrelevant in calculating outcomes. - The streaming model allows queries to operate dynamically with data, contrasting with static query models.

Decisions on web server design should leverage adaptable optimization strategies. - Choosing data structures, algorithms, and caching strategies is crucial for efficient web server performance. - Most query languages, like SQL, combine basic relational operations but lack recursion and iteration, necessitating enhancements for complex queries.

Data log semantics remain intact despite looping structures. - The data log model asserts that a program's meaning is its minimal model, avoiding unsupported data. - Programs in data log function as implications, where true right-hand premises guarantee true left-hand conclusions.

Data log enables order-independent explanations and supports 'what if' scenarios in data analysis. - By capturing lineage, data log reveals why specific data is included in outputs, facilitating clear reasoning. - It allows for exploring the impact of data deletion on derived data, highlighting redundancy and support in decision-making.

Self-reference and negation complicate program semantics, leading to non-deterministic outcomes. - Programs with self-reference can yield multiple meanings based on the order of data and rule execution. - Non-deterministic behavior arises when different replicas process the same input in varying sequences.

Understanding state and non-determinism in distributed systems is critical. - Protocols like Paxos and two-phase commit face challenges due to unreliable communication and dynamic state. - Capturing mutable state and non-deterministic message handling is essential for improving the design of distributed systems.

Discussing the relationship between assignment statements and the concept of time. - Assignment statements in programming segment time into past and future, with implications for how values are understood. - The conventional and database models of time, with emphasis on their linearity and how events are recorded.

Knowledge is ephemeral and relies on context and timing. - Knowledge only holds meaning at specific moments and must be shared in real-time to be relevant. - Computation involves aligning data and events temporally to derive new knowledge.

Implementing asynchronous rules in data log languages simplifies time management. - Every record in the data log has a timestamp, allowing for deductive and inductive reasoning based on time. - The powerful constructs in Deal list enable expressing complex temporal relationships like atomicity, mutual exclusion, and sequencing.

Understanding non-determinism and time in distributed systems programming. - In distributed systems, messages from agents race to the counter, leading to uncertain outcomes about the read values. - The challenge lies in developing a model theoretic semantics for programs with non-deterministic behavior influenced by time.

Understanding program behavior and outcomes through equivalence classes. - Behavior tracking reveals that outcomes often change only by their timestamps, requiring classification. - Establishing unique models for programs can simplify distributed systems, ensuring deterministic executions.

Abstraction in programming simplifies complexity while ensuring data consistency. - Hiding various representations of state helps in maintaining clarity, allowing focus on data as the core unit of computation. - Utilizing concepts from logic programming enhances understanding and correctness of distributed systems through deterministic outcomes.

Development of programming languages and systems for fault tolerance and ease of use. - Blom language simplifies programming syntax while preserving semantics, providing insights into program determinism. - Lineage-driven fault injection enhances program reliability by proving outcomes through independent redundant proofs.

Audience applauds in appreciation of the performance. - The applause signifies the audience's approval and enjoyment of the event. - It serves as a positive reinforcement for the performers' efforts.

Summary of Tech Talk: Atomic Data and the Semantic Web

Introduction

• Speaker: Software developer and entrepreneur with experience in linked data and the semantic web.

"My name is [Hube], I'm a software developer and entrepreneur and I did a lot with linked data and the semantic web."

• Context: Focus on atomic data as an iteration on the semantic web and RDF concepts.

"Today I'm going to talk about the semantic web and atomic data which is an iteration on that."

Challenges with the Current Web and Semantic Web

• Centralization: Web has shifted from a decentralized network to a centralized model controlled by few actors.

"It has become way more centralized...and the nodes between individuals have kind of went missing over time."

• Non-interoperable APIs: Many systems are incompatible due to proprietary APIs.

"Even when developers create new types of applications, they often end up creating their totally own APIs."

• Initial Design Gaps: The web's machine readability and write capabilities were underdeveloped.

"The web is not machine-readable...The very first web browser actually had full read-write capabilities."

RDF and the Vision for a Semantic Web

• Concept: RDF uses triples (subject, predicate, object) to make data machine-readable and interoperable.

"The idea of RDF is that it really increases the quality of data on the web."

Challenges with RDF:

• Lack of native arrays or sequential data, making JSON more practical.

"RDF doesn't have any form of native arrays or sequential data."

• Subject-property uniqueness issues lead to complexity.

"A subject can have many triples with the same predicate...makes it very hard to store data in maps."

• Blank nodes and named graphs introduce high complexity.

"Blank nodes are this really complex thing...and there's also named graphs in RDF which provide just another layer of complexity."

Atomic Data: An Alternative Approach

• Vision: Combines RDF's interoperability, JSON's simplicity, and TypeScript's type safety.

"Atomic data is basically where all these three things are combined."

Key Features:

• Strict subset of RDF and JSON with tight coupling between schema and validation.

"Classes describe which properties are required and which ones are optional."

• Transactions standardize changes for versioning, history, and cryptographic verification.

"Every change is a transaction...every transaction is actually a resource."

• Fully resolvable URLs ensure semantic clarity and reusability.

"Every resource actually resolvable...you can use a local ID for resources not hosted globally."

• Extensibility for dynamic and interactive web applications (e.g., real-time collaboration, file handling).

"Static data is relatively easy but as we all know data changes over time."

Practical Implementations

• Atomic Server: Graph database in Rust for speed and robustness.

"A graph database...written in Rust and it's really fast."

Features:

• Full text search, authentication, and live synchronization.

"Embedded full text search index, queries, sorting, filtering, pagination, authorization."

• Front-end: Built with React for ease of use and collaboration.

"A graphical user interface that basically allows you to view all the data and add all data."

Community and Tools

• Libraries: JavaScript, TypeScript, and Rust libraries for integration.

"Atomic Lib Library which is a JavaScript TypeScript npm type of library."

• Open Source and Documentation: MIT-licensed projects with comprehensive guides.

"Everything shown is all MIT license...a very, very big documentation book."

• Community Engagement: Discussions on GitHub, Discord, and plans for W3C submission.

"There's a W3C community group for atomic data...most of the activity is on GitHub and Discord."

Conclusion and Vision

• Future of Atomic Data: Bridging the gaps of RDF with pragmatic, developer-friendly solutions.

"I think we should always use URLs that resolve."

• Call to Action: Developers encouraged to explore, contribute, and adopt atomic data.

"Thank you for listening, does anybody have a question?"

This summary encapsulates the core challenges and solutions proposed for evolving the web's interoperability through atomic data while highlighting the technical nuances and community-driven development efforts.

• Context and Core Problem

  “Harvard writes, you know additionally llms struggle to provide contextual relevant answer … specifically llms have difficulty combining scientific factual … with tcid … non-codified knowledge…”

  • The text emphasizes how Large Language Models (LLMs) struggle in medical contexts due to the dual challenge of incorporating both codified (structured) and non-codified (tacit) knowledge.
  • Harvard recognizes that inaccurate or incomplete retrieval poses a major risk in medical applications.

• Inadequacy of Current Medical LLM Performance

  “…if you look here at llama 3B we are here with the basic below 50% inmediate we are below 40% and the expert is below 30% … with gbt4 Turbo … about at 50% so for a medical system this is not acceptable…”

  • The text compares LLMs on basic, intermediate, and expert-level medical questions, showing subpar performance (30%-50% accuracy).
  • Such performance is “horrible” for medical standards where high precision is necessary.

• Limitation of Retrieval-Augmented Generation (RAG)

  “…Howard discovers that also those R methods can provide multisource knowledge … but they are really vulnerable to potential errors… incomplete and incorrect information … leading now here in har Medical School inaccurate retrieval…”

  • RAG systems can still fail, especially if the underlying data repositories are incomplete or if there is no robust verification mechanism after retrieving facts.

• Proposed Knowledge Graph-Based Agent

  “…they developed a new methodology … knowledge graph-based agent … designed to address the complexity of knowledge intensive medical queries…”

  • Harvard’s new solution leverages knowledge graphs (KGs) to systematically integrate multi-source, structured medical data.
  • It aims to combine LLM-generated insight with the rigor of codified knowledge in KGs.

• Four-Phase Approach

  1. Generate

     “…At first we are at a generate level … to prompt the llm to follow different procedures for generating relevant triplets…”

     • The LLM identifies key medical entities and relationships from the question (“H, R, T” format).
     • It creates structured triplets (head entity – relationship – tail entity) to capture potential facts.
       1. Review

     “…it aims to assess the correctness of the generated triplets … by grounding here the correctness of the triplets in a medical Knowledge Graph…”

     • The system validates these newly generated triplets against the KG.
     • Entities are mapped to UMLS codes to ensure standardized medical terms.
       1. Revise

     “…the llm continues to propose and refine the triplets until the triplet are now validated Again by the knowledge CFT…”

     • If the triplets are incorrect or incomplete, the LLM iteratively refines them.
     • Mismatched or missing

Speaker’s Mixed Feelings on Language Models

Key Quote: “The second controversial statement is language models suck or rather AI sucks and specifically the way our culture has been using it.”

The speaker acknowledges that while language models are groundbreaking (“language models are pretty neat”), there are serious ethical, social, and environmental concerns, which creates a personal and professional dilemma.

Motivation: Making AI Good

Key Quote: “How can we make the tech actually good if it comes with all these trade-offs...so let’s make it as good as it can possibly be but how?”

The talk’s central goal is to explore how to refine language model technology to maximize its societal benefits and minimize harms.

RDF Overview and History

Key Quote: “rdf is an attempt to tackle some of the hardest problems of knowledge representation and reasoning...from the same group of people that put together all the internet specifications the w3c.”

RDF (Resource Description Framework) emerged post-internet boom, aiming to provide a universal system for knowledge representation, rooted in symbolic AI traditions and overseen by the W3C.

Why RDF Fell Out of Favor

Key Quote: “One is rdf XML which is one of the initial formats...this is a verbose complex format it’s just honestly not great.”

Early technical choices and heavy enterprise solutions contributed to RDF’s reputation as being cumbersome and outdated, even though “under the hood” it remains robust and conceptually sound.

RDF’s Elegant Core: Resources and Triples

Key Quote: “It’s the resource description framework so let’s talk about resources first...a resource is anything in the world that you can talk about.”

RDF structures knowledge as “triples” (subject, predicate, object) linked by unique identifiers (IRIs), enabling precise, context-rich data representation.

Federation and Union of Data

Key Quote: “An rdf data set is a set in the closure sense or the mathematical sense...we can also safely union sets.”

By standardizing each piece of data (triples + IRIs), RDF allows combining multiple datasets (federation) without losing context or creating duplication conflicts.

Inference, Logic, and Schemas

Key Quote: “This is all about entailment...given a set of triples I can derive other triples from them conceptually.”

RDF includes logical rules for automatically deriving new facts (entailment) and validating data, reflecting decades of research in symbolic AI and formal logic.

Language Models: Context and Probabilistic Reasoning

Key Quote: “All a model is is a pure function that predicts the next token...with some constants in it.”

Modern language models leverage the Transformer architecture for predicting tokens and exhibit capabilities in semantics, grammar, and even “fact patterns,” though they remain probabilistic approximations.

Challenges of Using Language Models

Key Quote: “All of AI programming...is putting the right stuff into the model to try to get it to get out the stuff that you want.”

Because re-training an LLM is expensive, practitioners focus on techniques like prompt engineering, retrieval-augmented generation, query generation, and tool use to shape the model’s output.

Core Problem: Integrating Data and Language

Key Quote: “We write programs that work between them a lot...But how do I get my data to meet my language?”

The speaker emphasizes the need for a mechanism that unifies formal data representation and natural language capabilities, highlighting RDF as the bridge.

RDF as the Bridge Between LLMs and Data

Key Quote: “We should be putting rdf data in our prompts and when we are asking to get kind of more structured data out of models we should be asking for it in rdf format.”

RDF’s subject-predicate-object structure aligns naturally with the grammar captured by language models, enabling more precise input/output handling and reducing ambiguity.

RDF Queries for Tool Use

Key Quote: “If my rdf implementation supports reasoning...the language model is asking a different question who is Luke a descendant of.”

By combining RDF’s inference with LLM queries, complex or open-ended questions (“who am I?” or genealogical lookups) can be answered reliably, without forcing the language model to handle all logic internally.

Combining Symbolic and Neural Approaches

Key Quote: “Neuorsymbolic AI is...any research that is trying to combine the abstract fuzzy neural network with hard concrete logical symbols.”

RDF can serve as the symbolic layer, and the language model as the neural layer—together addressing knowledge gaps that purely logical or purely neural methods struggle with alone.

Conclusion and Practical Use Cases

Key Quote: “I think it’s a tool to actually automate a lot of the dishes and the laundry of working with data...particularly on the data side.”

The speaker envisions AI not to replace creative work or coding but to handle the “tedious chores” of data management, with RDF acting as a structured, logic-friendly foundation to harness LLMs effectively.

Speaker’s Mixed Feelings on Language Models

Key Quote: “The second controversial statement is language models suck or rather AI sucks and specifically the way our culture has been using it.”

The speaker acknowledges that while language models are groundbreaking (“language models are pretty neat”), there are serious ethical, social, and environmental concerns, which creates a personal and professional dilemma.

Motivation: Making AI Good

Key Quote: “How can we make the tech actually good if it comes with all these trade-offs...so let’s make it as good as it can possibly be but how?”

The talk’s central goal is to explore how to refine language model technology to maximize its societal benefits and minimize harms.

RDF Overview and History

Key Quote: “rdf is an attempt to tackle some of the hardest problems of knowledge representation and reasoning...from the same group of people that put together all the internet specifications the w3c.”

RDF (Resource Description Framework) emerged post-internet boom, aiming to provide a universal system for knowledge representation, rooted in symbolic AI traditions and overseen by the W3C.

Why RDF Fell Out of Favor

Key Quote: “One is rdf XML which is one of the initial formats...this is a verbose complex format it’s just honestly not great.”

Early technical choices and heavy enterprise solutions contributed to RDF’s reputation as being cumbersome and outdated, even though “under the hood” it remains robust and conceptually sound.

RDF’s Elegant Core: Resources and Triples

Key Quote: “It’s the resource description framework so let’s talk about resources first...a resource is anything in the world that you can talk about.”

RDF structures knowledge as “triples” (subject, predicate, object) linked by unique identifiers (IRIs), enabling precise, context-rich data representation.

Federation and Union of Data

Key Quote: “An rdf data set is a set in the closure sense or the mathematical sense...we can also safely union sets.”

By standardizing each piece of data (triples + IRIs), RDF allows combining multiple datasets (federation) without losing context or creating duplication conflicts.

Inference, Logic, and Schemas

Key Quote: “This is all about entailment...given a set of triples I can derive other triples from them conceptually.”

RDF includes logical rules for automatically deriving new facts (entailment) and validating data, reflecting decades of research in symbolic AI and formal logic.

Language Models: Context and Probabilistic Reasoning

Key Quote: “All a model is is a pure function that predicts the next token...with some constants in it.”

Modern language models leverage the Transformer architecture for predicting tokens and exhibit capabilities in semantics, grammar, and even “fact patterns,” though they remain probabilistic approximations.

Challenges of Using Language Models

Key Quote: “All of AI programming...is putting the right stuff into the model to try to get it to get out the stuff that you want.”

Because re-training an LLM is expensive, practitioners focus on techniques like prompt engineering, retrieval-augmented generation, query generation, and tool use to shape the model’s output.

Core Problem: Integrating Data and Language

Key Quote: “We write programs that work between them a lot...But how do I get my data to meet my language?”

The speaker emphasizes the need for a mechanism that unifies formal data representation and natural language capabilities, highlighting RDF as the bridge.

RDF as the Bridge Between LLMs and Data

Key Quote: “We should be putting rdf data in our prompts and when we are asking to get kind of more structured data out of models we should be asking for it in rdf format.”

RDF’s subject-predicate-object structure aligns naturally with the grammar captured by language models, enabling more precise input/output handling and reducing ambiguity.

RDF Queries for Tool Use

Key Quote: “If my rdf implementation supports reasoning...the language model is asking a different question who is Luke a descendant of.”

By combining RDF’s inference with LLM queries, complex or open-ended questions (“who am I?” or genealogical lookups) can be answered reliably, without forcing the language model to handle all logic internally.

Combining Symbolic and Neural Approaches

Key Quote: “Neuorsymbolic AI is...any research that is trying to combine the abstract fuzzy neural network with hard concrete logical symbols.”

RDF can serve as the symbolic layer, and the language model as the neural layer—together addressing knowledge gaps that purely logical or purely neural methods struggle with alone.

Conclusion and Practical Use Cases

Key Quote: “I think it’s a tool to actually automate a lot of the dishes and the laundry of working with data...particularly on the data side.”

The speaker envisions AI not to replace creative work or coding but to handle the “tedious chores” of data management, with RDF acting as a structured, logic-friendly foundation to harness LLMs effectively.

Introduction & Problem Statement

Quoted sentence: “The problem is that datomic users can’t reason about transactor performance and our objective today is that everyone should be able to leave being able to answer two questions: where is all the time going and what can I do about it?”

Summary: The speaker highlights a key challenge: Datomic users struggle to understand transactor performance. The goal of this presentation is to enable them to identify performance bottlenecks and find actionable solutions.

Datomic Architecture Overview

Quoted sentence: “We then have another component called the transactor and the transactor is an appliance which processes transactions safely one at a time… sometimes given enough load transactions will cue.”

Summary: Datomic consists of peer processes co-located with user applications for fast reads and a single-threaded transactor responsible for safely processing write transactions, which can become a bottleneck under heavy load.

Queuing Theory Basics

Quoted sentence: “As the utilization of any queuing system increases, the residence time trends toward infinity.”

Summary: The talk introduces queuing theory to explain how increased transaction arrival rates and high resource utilization cause wait times to grow dramatically. Key metrics—service time, utilization, throughput, and response time—are all crucial to analyzing performance.

Impact of High Utilization on Latency

Quoted sentence: “We can determine the max utilization in order to achieve a response time that we could tolerate.”

Summary: By controlling or reducing service time (S) in Datomic’s transactor, one can keep overall utilization manageable and thus keep transaction latencies within acceptable limits.

Working Set Model Explanation

Quoted sentence: “The working set model is effectively the smallest collection of information that must be present in main memory to ensure efficient execution of your program.”

Summary: The speaker references a classic 1968 MIT paper to illustrate that performance is fundamentally affected by how much necessary data (segments) are in memory. Excessive page traffic (moving segments from external storage to memory) slows down transaction processing.

Performance Benchmark: 10-Billion-Datum Database

Quoted sentence: “We’re going to…flood this system with 5,000 TPS and it’s going to be completely saturated… so this is just a way for us to ensure that we’re absolutely saturating this system.”

Summary: A large-scale test environment demonstrates how Datomic transactor performance responds under heavy load, revealing that as data size grows, the transactor becomes increasingly IO-bound.

Identifying IO Bottlenecks

Quoted sentence: “If we wanted to know what can we do about it we would look at the TX stats chart and we can see…most of the time is spent resolving transaction identities.”

Summary: Transaction resolution and de-duplication dominate overall processing time once the database is large. Reducing disk or network IO through smarter caching and smaller working sets is key to boosting throughput.

Caching Hierarchy in Datomic

Quoted sentence: “We have…a valache which is an NVMe SSD…Light Years faster than a network hop especially across availability zones.”

Summary: Datomic’s multi-tier caching structure (object cache, in-flight lookup, val cache, external storage) significantly impacts latency, showing that local NVMe-based caching outperforms remote storage solutions.

Strategies to Improve Transactor Performance

Quoted sentence: “If you wanted to improve transactor performance you could fiddle with some knobs… deploy faster Hardware… or semantic improvements in your application.”

Summary: Tuning existing settings is a short-term fix. More powerful hardware (e.g., NVMe val cache) or re-thinking application design (e.g., minimal uniqueness checks, fewer data collisions, smaller transactions) often yields far bigger gains.

Semantic Optimizations & Sequential Identifiers

Quoted sentence: “Why do sequential identifiers actually work this way? … if you’re using a squid… you only need to check against the random part of competing squid identifiers within a slide time window of one second.”

Summary: The talk stresses that using sequential or time-ordered IDs (like squids) can drastically reduce random lookups and maintain a small, hot working set in memory, leading to significant transaction throughput improvements.

Platform-Level Improvements

Quoted sentence: “An interesting consequence of this… is that as the utilization increases we end up getting more time waiting in the Q which then gives us more time to prefetch the IO which then reduces the utilization.”

Summary: Recent Datomic enhancements, such as “datomic hints” and advanced prefetching, exploit queue wait time to fetch needed segments preemptively, alleviating IO stalls in the critical apply phase and thereby driving down utilization and latency.

Datomic Hints & Segment Prefetch

Quoted sentence: “We can begin to prefetch some of the reads… purely for side effects to pre-populate the cache with the appropriate data… it can reduce the IO inside the apply thread.”

Summary: A notable new feature allows peers to send “hints” about which segments the transaction will touch, letting the transactor load them while transactions are queued. This cuts down service time dramatically.

Conclusion

Quoted sentence: “With that I think we’ve run through our agenda… so thank you.”

Summary: The talk ends by reiterating how queueing theory, the working set model, semantic changes, and new Datomic features like segment prefetch collectively empower engineers to tackle transactor bottlenecks at scale.

Introduction & Problem Statement

Quoted sentence: “The problem is that datomic users can’t reason about transactor performance and our objective today is that everyone should be able to leave being able to answer two questions: where is all the time going and what can I do about it?”

Summary: The speaker highlights a key challenge: Datomic users struggle to understand transactor performance. The goal of this presentation is to enable them to identify performance bottlenecks and find actionable solutions.

Datomic Architecture Overview

Quoted sentence: “We then have another component called the transactor and the transactor is an appliance which processes transactions safely one at a time… sometimes given enough load transactions will cue.”

Summary: Datomic consists of peer processes co-located with user applications for fast reads and a single-threaded transactor responsible for safely processing write transactions, which can become a bottleneck under heavy load.

Queuing Theory Basics

Quoted sentence: “As the utilization of any queuing system increases, the residence time trends toward infinity.”

Summary: The talk introduces queuing theory to explain how increased transaction arrival rates and high resource utilization cause wait times to grow dramatically. Key metrics—service time, utilization, throughput, and response time—are all crucial to analyzing performance.

Impact of High Utilization on Latency

Quoted sentence: “We can determine the max utilization in order to achieve a response time that we could tolerate.”

Summary: By controlling or reducing service time (S) in Datomic’s transactor, one can keep overall utilization manageable and thus keep transaction latencies within acceptable limits.

Working Set Model Explanation

Quoted sentence: “The working set model is effectively the smallest collection of information that must be present in main memory to ensure efficient execution of your program.”

Summary: The speaker references a classic 1968 MIT paper to illustrate that performance is fundamentally affected by how much necessary data (segments) are in memory. Excessive page traffic (moving segments from external storage to memory) slows down transaction processing.

Performance Benchmark: 10-Billion-Datum Database

Quoted sentence: “We’re going to…flood this system with 5,000 TPS and it’s going to be completely saturated… so this is just a way for us to ensure that we’re absolutely saturating this system.”

Summary: A large-scale test environment demonstrates how Datomic transactor performance responds under heavy load, revealing that as data size grows, the transactor becomes increasingly IO-bound.

Identifying IO Bottlenecks

Quoted sentence: “If we wanted to know what can we do about it we would look at the TX stats chart and we can see…most of the time is spent resolving transaction identities.”

Summary: Transaction resolution and de-duplication dominate overall processing time once the database is large. Reducing disk or network IO through smarter caching and smaller working sets is key to boosting throughput.

Caching Hierarchy in Datomic

Quoted sentence: “We have…a valache which is an NVMe SSD…Light Years faster than a network hop especially across availability zones.”

Summary: Datomic’s multi-tier caching structure (object cache, in-flight lookup, val cache, external storage) significantly impacts latency, showing that local NVMe-based caching outperforms remote storage solutions.

Strategies to Improve Transactor Performance

Quoted sentence: “If you wanted to improve transactor performance you could fiddle with some knobs… deploy faster Hardware… or semantic improvements in your application.”

Summary: Tuning existing settings is a short-term fix. More powerful hardware (e.g., NVMe val cache) or re-thinking application design (e.g., minimal uniqueness checks, fewer data collisions, smaller transactions) often yields far bigger gains.

Semantic Optimizations & Sequential Identifiers

Quoted sentence: “Why do sequential identifiers actually work this way? … if you’re using a squid… you only need to check against the random part of competing squid identifiers within a slide time window of one second.”

Summary: The talk stresses that using sequential or time-ordered IDs (like squids) can drastically reduce random lookups and maintain a small, hot working set in memory, leading to significant transaction throughput improvements.

Platform-Level Improvements

Quoted sentence: “An interesting consequence of this… is that as the utilization increases we end up getting more time waiting in the Q which then gives us more time to prefetch the IO which then reduces the utilization.”

Summary: Recent Datomic enhancements, such as “datomic hints” and advanced prefetching, exploit queue wait time to fetch needed segments preemptively, alleviating IO stalls in the critical apply phase and thereby driving down utilization and latency.

Datomic Hints & Segment Prefetch

Quoted sentence: “We can begin to prefetch some of the reads… purely for side effects to pre-populate the cache with the appropriate data… it can reduce the IO inside the apply thread.”

Summary: A notable new feature allows peers to send “hints” about which segments the transaction will touch, letting the transactor load them while transactions are queued. This cuts down service time dramatically.

Conclusion

Quoted sentence: “With that I think we’ve run through our agenda… so thank you.”

Summary: The talk ends by reiterating how queueing theory, the working set model, semantic changes, and new Datomic features like segment prefetch collectively empower engineers to tackle transactor bottlenecks at scale.

State management is a complex topic in Flutter with various approaches to choose from.

"State management is a complex topic."

Provider: A commonly used state management solution in Flutter.

"Provider package"

Riverpod offers compile safety and testing without depending on the Flutter SDK, similar to Provider.

"Riverpod works in a similar fashion to Provider. It offers compile safety and testing without depending on the Flutter SDK."

setState is the low-level approach for widget-specific, ephemeral state.

"The low-level approach to use for widget-specific, ephemeral state."

ValueNotifier & InheritedNotifier use Flutter's built-in tools to update state and notify the UI of changes.

"An approach using only Flutter provided tooling to update state and notify the UI of changes."

InheritedWidget & InheritedModel facilitate communication between ancestors and children in the widget tree and are the foundation for other state management solutions.

"The low-level approach used to communicate between ancestors and children in the widget tree. This is what provider and many other approaches use under the hood."

June is a lightweight and modern library focusing on a pattern similar to Flutter's built-in state management.

"A lightweight and modern state management library that focuses on providing a pattern similar to Flutter's built-in state management."

Redux is a state container approach familiar to web developers, suitable for managing application state.

"A state container approach familiar to many web developers."

Fish Redux is an assembled Flutter application framework based on Redux, suitable for medium and large applications.

"Fish Redux is an assembled flutter application framework based on Redux state management. It is suitable for building medium and large applications."

BLoC / Rx comprise a family of stream/observable-based patterns for state management.

"A family of stream/observable based patterns."

GetIt is a service locator approach that doesn't require a BuildContext for state management.

"A service locator based state management approach that doesn't need a BuildContext."

MobX is a popular library based on observables and reactions for state management.

"A popular library based on observables and reactions."

Dart Board is a modular feature management framework designed to encapsulate and isolate features in Flutter applications.

"A modular feature management framework for Flutter. Dart Board is designed to help encapsulate and isolate features, including examples/frameworks, small kernel, and many ready-to-use decoupled features such as debugging, logging, auth, redux, locator, particle system and more."

Flutter Commands uses the Command Pattern and ValueNotifiers for reactive state management.

"Reactive state management that uses the Command Pattern and is based on ValueNotifiers."

Binder is a state management package using InheritedWidget at its core, promoting separation of concerns.

"A state management package that uses InheritedWidget at its core. Inspired in part by recoil. This package promotes the separation of concerns."

GetX is a simplified and powerful reactive state management solution.

"A simplified reactive state management solution."

states_rebuilder combines state management with dependency injection and an integrated router.

"An approach that combines state management with a dependency injection solution and an integrated router."

Triple Pattern (Segmented State Pattern) uses Streams or ValueNotifier, focusing on three core values: Error, Loading, and State.

"Triple is a pattern for state management that uses Streams or ValueNotifier. This mechanism (nicknamed triple because the stream always uses three values: Error, Loading, and State), is based on the Segmented State pattern."

solidart is a simple yet powerful state management solution inspired by SolidJS.

"A simple but powerful state management solution inspired by SolidJS."

flutter_reactive_value offers a minimalistic solution, allowing newcomers to add reactivity without complexity.

"The flutter_reactive_value library might offer the least complex solution for state management in Flutter. It might help Flutter newcomers add reactivity to their UI, without the complexity of the mechanisms described before."

Elementary provides a straightforward way to build Flutter applications with MVVM, enhancing productivity and testability.

"Elementary is a simple and reliable way to build applications with MVVM in Flutter. It offers a pure Flutter experience with clear code separation by responsibilities, efficient rebuilds, easy testability, and enhancing team productivity."

Developers are encouraged to review these options to select an approach that best fits their use case.

"If you feel that some of your questions haven't been answered, or that the approach described on these pages is not viable for your use cases, you are probably right."

Summary of Ravi Chugh's Talk on "Programming with Direct Manipulation":

Motivation to make programming languages more interactive, human-friendly, and accessible:

Quote: "This talk is about research efforts to make programming languages and tools more interactive, more human friendly, and hopefully more accessible and useful to a wide variety of people."

Tension between programming and direct manipulation interfaces:

Quote: "On one hand, we want and need the full expressive power of our fancy general purpose programming languages that are equipped for abstract symbolic reasoning; at the same time, we also want and need tangible interactive user interfaces for understanding and manipulating the concrete things we are making."

Desire for systems that blend programming languages with direct manipulation UIs:

Quote: "So naturally, what we would like are systems that blend programming languages and concrete direct manipulation user interfaces, allowing us to smoothly move back and forth between these different modes as needed."

Introduction of the concept "Programming with Direct Manipulation":

Quote: "I'll refer to these goals as programming with direct manipulation—that is, in addition to unrestricted text-based editing of source code in whatever our favorite language happens to be, we would like the ability to inspect and interact with and change the output, and have the system help suggest changes to the code based on these interactions."

Historical context of interactive programming systems:

Quote: "Similar visions for interactive programming systems to augment human creativity and intelligence can be traced all the way back to the 1960s, from the constraint-oriented Sketchpad system by Ivan Sutherland to the work on graphical user interfaces and interactive computing by Doug Engelbart, Alan Kay, and many, many others."

Recent interest and efforts in the intersection of PL and HCI:

Quote: "In the past decade or so, there's been renewed interest in these challenges which lie at the intersection of PL and HCI."

Introduction of Sketch-n-Sketch prototype system:

Quote: "In my group, we've been exploring a few ideas in a prototype system called Sketch-n-Sketch—for sketching partial programs in the program synthesis sense, and sketching or drawing objects in the GUI editor sense."

Three main ideas explored in Sketch-n-Sketch:

Programming by demonstration in a pure lambda calculus:

Quote: "The first idea is to explore programming by demonstration techniques for building programs in a pure lambda calculus, rather than in a lower-level imperative language as in most PBD work."

Streamlined structure editing of abstract syntax trees in a text editor:

Quote: "The second idea is to explore how structure editing of an abstract syntax tree might be streamlined into an ordinary existing text editor, as opposed to being a completely separate editing paradigm."

Incorporating bidirectional programming techniques:

Quote: "The third idea explores how to incorporate bidirectional programming techniques so that relatively small changes to the output can be mapped back to changes in the program."

Demo Part 1: Programming by Demonstration—Every interaction is codified as a program change:

Quote: "The key takeaway from this first part of the demo is that every direct manipulation interaction in the output pane is codified as a change to the program in the left pane."

Demo Part 2: Structure Editing—Combining text and structure edits with GUI overlays:

Quote: "The key takeaway from the following demo is that, in addition to regular text edits on the concrete syntax of the program, the left pane also supports certain program transformations by hovering, selecting, and clicking on the abstract syntax tree."

Demo Part 3: Bidirectional Programming—Mapping output changes back to the program:

Quote: "In the third and final part of the demo, we'll talk about the bidirectional programming features in Sketch-n-Sketch that support such changes and compare to the previous examples where Sketch-n-Sketch was configured for SVG programming, the following example will show a program that generates a simple HTML page."

Exploration of programming by demonstration techniques in functional programming languages:

Quote: "In contrast, our goal in Sketch-n-Sketch so far has not been to build the ultimate visual graphics editor, but rather to explore whether GUI interactions can be represented as ordinary text-based programs, as a way to bridge rather than replace a full-featured programming language."

Discussion on structure editing and the use of GUI elements to manipulate ASTs:

Quote: "There are many aspects to consider, both in the user interface side as well as the semantics of the transformations."

Integration of text and visual editing in programming environments:

Quote: "All of these ideas help make progress toward the goal of integrating text and visual editing, but these user interfaces really only make edits at the leaves of the AST."

Challenges in scaling up structure editing and program transformations:

Quote: "It remains an open question how to scale up such edit languages to describe larger program transformations and refactorings in a way that preserves static and dynamic information across compiles and allows the editor to be extended with new and custom transformations."

Importance of bidirectional programming in mapping output changes to code:

Quote: "I think there's potential to develop this kind of bidirectional programming for a lot of practical settings."

Potential application domains: Data science, web development, graphics design:

Quote: "I think it's easy to imagine a workflow where programmers, designers, and end users with a variety of technical backgrounds and different permission levels can work together to suggest and commit changes in this kind of a bidirectional system."

Advances in live programming interfaces and integrating program synthesis:

Quote: "It's been great to see all these efforts to make synthesis techniques more usable, and we'll need a lot more of this work going forward."

Discussion on the role of spreadsheets as live programming interfaces:

Quote: "So although spreadsheets have always lacked many of the bread-and-butter features that we would expect in any real programming system, spreadsheets have proven extraordinarily flexible and useful, and especially with some of these recent language extensions, spreadsheets provide a lot of really compelling opportunities both for PL and user interface design."

Bridging the gap between designers and developers in collaborative projects:

Quote: "Here's one setting in which I'm personally interested in trying to bridge these gaps between the designer and developer, regardless of whether they are multiple different people or just an individual user."

Conclusion emphasizing recurring themes and future challenges:

Quote: "So that was a whirlwind tour of a bunch of ideas spanning PL and HCI that factor into this pursuit of more interactive programming systems that support direct manipulation."

Summary of recurring themes:

Quote: "One is, can we design every graphical user interface to be backed by text-based programs in a general programming language?"

Encouraging collaboration and future work in PL plus HCI:

Quote: "So if you're interested, if you're sympathetic to the cause, there are certainly missions out there for you."

Acknowledgments and appreciation:

Quote: "There are a lot of people I want to thank for encouraging me in this work."

Summary of Ravi Chugh's Talk on "Programming with Direct Manipulation":

Motivation to make programming languages more interactive, human-friendly, and accessible:

Quote: "This talk is about research efforts to make programming languages and tools more interactive, more human friendly, and hopefully more accessible and useful to a wide variety of people."

Tension between programming and direct manipulation interfaces:

Quote: "On one hand, we want and need the full expressive power of our fancy general purpose programming languages that are equipped for abstract symbolic reasoning; at the same time, we also want and need tangible interactive user interfaces for understanding and manipulating the concrete things we are making."

Desire for systems that blend programming languages with direct manipulation UIs:

Quote: "So naturally, what we would like are systems that blend programming languages and concrete direct manipulation user interfaces, allowing us to smoothly move back and forth between these different modes as needed."

Introduction of the concept "Programming with Direct Manipulation":

Quote: "I'll refer to these goals as programming with direct manipulation—that is, in addition to unrestricted text-based editing of source code in whatever our favorite language happens to be, we would like the ability to inspect and interact with and change the output, and have the system help suggest changes to the code based on these interactions."

Historical context of interactive programming systems:

Quote: "Similar visions for interactive programming systems to augment human creativity and intelligence can be traced all the way back to the 1960s, from the constraint-oriented Sketchpad system by Ivan Sutherland to the work on graphical user interfaces and interactive computing by Doug Engelbart, Alan Kay, and many, many others."

Recent interest and efforts in the intersection of PL and HCI:

Quote: "In the past decade or so, there's been renewed interest in these challenges which lie at the intersection of PL and HCI."

Introduction of Sketch-n-Sketch prototype system:

Quote: "In my group, we've been exploring a few ideas in a prototype system called Sketch-n-Sketch—for sketching partial programs in the program synthesis sense, and sketching or drawing objects in the GUI editor sense."

Three main ideas explored in Sketch-n-Sketch:

Programming by demonstration in a pure lambda calculus:

Quote: "The first idea is to explore programming by demonstration techniques for building programs in a pure lambda calculus, rather than in a lower-level imperative language as in most PBD work."

Streamlined structure editing of abstract syntax trees in a text editor:

Quote: "The second idea is to explore how structure editing of an abstract syntax tree might be streamlined into an ordinary existing text editor, as opposed to being a completely separate editing paradigm."

Incorporating bidirectional programming techniques:

Quote: "The third idea explores how to incorporate bidirectional programming techniques so that relatively small changes to the output can be mapped back to changes in the program."

Demo Part 1: Programming by Demonstration—Every interaction is codified as a program change:

Quote: "The key takeaway from this first part of the demo is that every direct manipulation interaction in the output pane is codified as a change to the program in the left pane."

Demo Part 2: Structure Editing—Combining text and structure edits with GUI overlays:

Quote: "The key takeaway from the following demo is that, in addition to regular text edits on the concrete syntax of the program, the left pane also supports certain program transformations by hovering, selecting, and clicking on the abstract syntax tree."

Demo Part 3: Bidirectional Programming—Mapping output changes back to the program:

Quote: "In the third and final part of the demo, we'll talk about the bidirectional programming features in Sketch-n-Sketch that support such changes and compare to the previous examples where Sketch-n-Sketch was configured for SVG programming, the following example will show a program that generates a simple HTML page."

Exploration of programming by demonstration techniques in functional programming languages:

Quote: "In contrast, our goal in Sketch-n-Sketch so far has not been to build the ultimate visual graphics editor, but rather to explore whether GUI interactions can be represented as ordinary text-based programs, as a way to bridge rather than replace a full-featured programming language."

Discussion on structure editing and the use of GUI elements to manipulate ASTs:

Quote: "There are many aspects to consider, both in the user interface side as well as the semantics of the transformations."

Integration of text and visual editing in programming environments:

Quote: "All of these ideas help make progress toward the goal of integrating text and visual editing, but these user interfaces really only make edits at the leaves of the AST."

Challenges in scaling up structure editing and program transformations:

Quote: "It remains an open question how to scale up such edit languages to describe larger program transformations and refactorings in a way that preserves static and dynamic information across compiles and allows the editor to be extended with new and custom transformations."

Importance of bidirectional programming in mapping output changes to code:

Quote: "I think there's potential to develop this kind of bidirectional programming for a lot of practical settings."

Potential application domains: Data science, web development, graphics design:

Quote: "I think it's easy to imagine a workflow where programmers, designers, and end users with a variety of technical backgrounds and different permission levels can work together to suggest and commit changes in this kind of a bidirectional system."

Advances in live programming interfaces and integrating program synthesis:

Quote: "It's been great to see all these efforts to make synthesis techniques more usable, and we'll need a lot more of this work going forward."

Discussion on the role of spreadsheets as live programming interfaces:

Quote: "So although spreadsheets have always lacked many of the bread-and-butter features that we would expect in any real programming system, spreadsheets have proven extraordinarily flexible and useful, and especially with some of these recent language extensions, spreadsheets provide a lot of really compelling opportunities both for PL and user interface design."

Bridging the gap between designers and developers in collaborative projects:

Quote: "Here's one setting in which I'm personally interested in trying to bridge these gaps between the designer and developer, regardless of whether they are multiple different people or just an individual user."

Conclusion emphasizing recurring themes and future challenges:

Quote: "So that was a whirlwind tour of a bunch of ideas spanning PL and HCI that factor into this pursuit of more interactive programming systems that support direct manipulation."

Summary of recurring themes:

Quote: "One is, can we design every graphical user interface to be backed by text-based programs in a general programming language?"

Encouraging collaboration and future work in PL plus HCI:

Quote: "So if you're interested, if you're sympathetic to the cause, there are certainly missions out there for you."

Acknowledgments and appreciation:

Quote: "There are a lot of people I want to thank for encouraging me in this work."

The speaker aims to distill years of thinking about Functional Reactive Programming (FRP) into a concise talk.

Quote: "So this talk is really distilling those years into like a 40-minute thing so you don't have to you don't have to go through the same thing that I did."

The main goals are to understand what FRP is, categorize different variations, and evaluate them effectively.

Quote: "Our goals for today are to understand what is FRP, how do we categorize different things that sort of fall into that umbrella, and then how do we evaluate those different things in a nice way."

First-order FRP, as implemented in Elm, involves signals connected to inputs from the world, representing values that change over time.

Quote: "The key part of a signal graph is that it has inputs from the world... it's a mouse position that's changing over time."

Signals in Elm are infinite and cannot be created or destroyed; they model continuous inputs like mouse position or keyboard presses.

Quote: "Another property is signals are infinite... there's no such thing as deleting a signal... the inputs to your program are fixed."

Signal graphs in Elm are static, meaning their structure is known at startup and does not change over time, which provides several benefits.

Quote: "Another property is signal graphs are static; there's a known structure for your application from startup all the way into the future."

Elm's FRP model is synchronous by default, ensuring events are processed in the order they occur, which is crucial for consistent user interactions.

Quote: "Finally, it's synchronous by default... when you type hello... you want those letters to show up in that order."

Transformations on signals are performed using functions like lift, allowing for pure functional manipulation of time-varying values.

Quote: "We have a function that goes from A's to B's... and we go make a signal of B."

Stateful computations are handled using foldp (fold from the past), which accumulates state over time based on incoming events.

Quote: "In Elm, this is called foldp... we give it a starting state... and a way to update that state."

Signals can be merged and combined using functions like merge and lift2, enabling complex signal graphs built from simpler components.

Quote: "Finally, we have a way to merge signals together... we can apply a function that puts them together."

The static nature of signal graphs in Elm enables efficient execution, as everything is event-driven and stateful nodes only need to look back at their previous state.

Quote: "Okay, what do we get when we make these design choices... the first one is efficiency... everything's event-driven."

Elm's architecture promotes modularity and separation of concerns, dividing programs into models, updates, and views in a pure functional style.

Quote: "So when we look at the structure of this application, it breaks up nicely into four parts... we first have a model... we have update... we have a view."

Hot swapping allows code changes to propagate in real-time without restarting the application, facilitated by the static signal graph.

Quote: "So we're able to change the behavior of the program while the program is running and sort of see those changes propagate automatically."

The time-travel debugger in Elm leverages the static nature of signal graphs to record and replay events, aiding in debugging and development.

Quote: "We can pause this program and sort of go back in time to wherever we want to go... you can start to get really cool insights about what's going on in your program at particular points in time."

Higher-order FRP introduces dynamic signal graphs that can be reconfigured at runtime, but this comes with significant trade-offs and complexities.

Quote: "What happens if signal graphs could be reconfigured? What is higher-order FRP? Surely higher is better... this is a very surprisingly hard question."

Introducing join in higher-order FRP allows for signals of signals, enabling dynamic switching between signals but leading to challenges like infinite lookback and memory growth.

Quote: "We have a signal of signals... creating a new signal may need infinite lookback... memory growth is linear with time."

To mitigate these issues, higher-order FRP requires restricting join with advanced type systems, adding complexity to the API or language.

Quote: "The solution isn't that this is a bad idea; it's that we only should switch to signals that have safe amounts of history... How do we restrict the definition of join with fancier types?"