Summary of Electric Closure Presentation

Overview and Purpose

• The presentation discusses the motivation, applications, and technical workings of Electric.
• Electric is designed for enterprise apps, specifically single-page applications with complex business rules and validations.
• It aims to solve issues encountered in CRUD apps by simplifying state management, network interaction, and rendering.

Application Examples

• Partner apps for internal operations, such as support apps for startups, demonstrate Electric's capabilities.
• Electric enables the creation of apps that look and function like spreadsheets, emphasizing strong user experience over styling.

Technical Approach

• Electric uses a DSL (domain-specific language) to encode operational CRUD apps.
• It allows the creation of live CRUD apps through a DSL that generates full-stack applications in real-time.
• The key innovation is the ability to compose functions directly with the DOM, simplifying the data flow and reducing the need for heavy frameworks.

Challenges and Solutions

• Traditional approaches to managing CRUD apps involve complex state and network interactions.
• Electric proposes a direct composition model, eliminating the need for frameworks like ORMs and simplifying the data flow.
• The system uses reactive programming to manage interleaved client-server data flows efficiently.

Architecture and Implementation

• Electric compiles programs into a directed acyclic graph (DAG), managing data flow between client and server.
• The DAG enables efficient rendering and state management, minimizing unnecessary computations and optimizing performance.
• Missionary, the functional effect system used by Electric, supports glitch-free rendering, cancellation, resource lifecycle management, and composability.

Practical Examples and Demos

• The chat app demo shows multiplayer capabilities by streaming state changes across clients.
• The 2D MVC demo illustrates full-stack applications created with Electric, highlighting its ability to handle real-time data entry and server-client synchronization.

Future Directions and Goals

• Electric aims to support more advanced use cases, such as offline-first applications and more complex data interactions.
• The project is committed to improving build times, optimizing network traffic, and refining the development experience.
• The team envisions Electric as a foundational technology for richer, more dynamic web applications, emphasizing strong composition and functional effects.

Key Takeaways

• Electric simplifies the development of enterprise applications by using a functional effect system to manage state and data flow.
• It provides a declarative approach to building CRUD apps, reducing accidental complexity and enhancing code readability and maintainability.
• The system's architecture ensures efficient real-time data synchronization and rendering, making it suitable for high-performance applications.

Relevant Quotes

• "We're going to talk about why we built this and what is for."
• "Electric is designed for enterprise apps, single-page applications."
• "The system uses reactive programming to manage interleaved client-server data flows efficiently."
• "Electric compiles programs into a directed acyclic graph (DAG), managing data flow between client and server."
• "Missionary, the functional effect system used by Electric, supports glitch-free rendering, cancellation, resource lifecycle management, and composability."

Summary of "Propagation Networks: A Flexible and Expressive Substrate for Computation" by Alexey Andreyevich Radul

Abstract and Introduction

• Shift in Computation Foundations: Proposes a shift from single-computer, large-memory models to networks of local, independent, stateless machines interconnected with stateful storage cells.

  • Quote: "The propagation paradigm replaces this with computing by networks of local, independent, stateless machines interconnected with stateful storage cells."

• General-Purpose Propagation System: Introduces a prototype for a general-purpose propagation system to enhance expressive power and flexibility.

  • Quote: "I present in this dissertation the design and implementation of a prototype general-purpose propagation system."

Chapter 1: Time for a Revolution

• Expression Evaluation Limitations: Traditional programming systems are limited by time constraints and the need for complete values.

  • Quote: "The successful evaluation of an individual expression, or, equivalently, the successful production of an individual value, inescapably marks a point in time."

• Propagation Paradigm: Argues for computation as a network of interconnected machines propagating information, allowing for non-linear time management.

  • Quote: "The commonality is to organize computation as a network of interconnected machines of some kind, each of which is free to run when it pleases, propagating information around the network as proves possible."

Chapter 2: Design Principles

• Propagators: Describes propagators as asynchronous, autonomous, and stateless machines communicating through cells.

  • Quote: "Let us likewise posit that our propagators are autonomous, asynchronous, and always on—always ready to perform their respective computations."

• Simulation Until Quiescence: Simulation focuses on achieving a quiescent state where no further propagation occurs without external input.

  • Quote: "The objective of our simulation of such a system is then the faithful computation of such a steady, or quiescent, state, rather than the faithful reproduction of the intermediate states that lead up to it."

• Cells Accumulate Information: Cells do not store values but accumulate information about values, enabling incremental computation and multidirectionality.

  • Quote: "I propose, in contrast, that we should think of a cell as a thing that accumulates information about a value."

Chapter 3: Core Implementation

• Basic Example - Temperature Conversion: Demonstrates a simple propagator network converting Fahrenheit to Celsius, emphasizing the structure and low-level nature of propagator networks.

  • Quote: "If we have a Fahrenheit temperature in cell f, we can put the corresponding Celsius temperature in cell c by the formula c = (f − 32) ∗ 5/9."

• Simulation Details: Details the implementation of a basic scheduler to handle the execution of propagators, ensuring they run in an arbitrary order.

  • Quote: "This dissertation, therefore, uses a relatively boring software scheduler that maintains a queue of pending propagators, picking them off one by one and running them until there are no more."

Chapter 4: Dependencies

• Dependency Tracking: Introduces dependency tracking to improve expressiveness and support for alternate worldviews, contradictions, and search optimization.
  • Quote: "Dependencies track Provenance."

Chapter 5: Expressive Power

• Applications: Discusses various applications of propagation networks, including constraint satisfaction, logic programming, and probabilistic programming.
  • Quote: "Propagation systems allow us to embed constraint satisfaction naturally."

Chapter 6: Towards a Programming Language

• Language Design: Explores potential programming languages based on propagation networks, focusing on conditionals, abstraction mechanisms, and partial information strategies.
  • Quote: "Conditionals just work."

Chapter 7: Philosophical Insights

• Broader Implications: Reflects on the philosophical implications of propagation networks on concurrency, time, space, and side effects.
  • Quote: "On Concurrency."

Appendix

• Implementation Details: Provides detailed implementation notes, code fragments, and design considerations for the prototype propagation system.

This summary encapsulates the essence and key points of Radul's dissertation, offering insights into the innovative propagation network model and its implications for the future of computation.

Summary of Gerald J. Sussman's Tech Talk on Programming

Introduction

• Event and Speaker Introduction:
  • Jointly sponsored by IEEE Computer Society chapter and Greater Boston chapter of ACM.
  • Speaker: Gerald J. Sussman, a professor of electrical engineering at MIT, co-author of the influential "Structure and Interpretation of Computer Programs" book used globally for computer science education.
• Event Context:
  • Talks usually occur monthly and are still virtual due to COVID-19.
  • Recordings available on chapter websites.

Programming History and Evolution

• Early Programming Experiences:
  • Sussman began programming in 1962.
  • Initial experiences with large, expensive computers like the IBM 70 90 system and later at MIT with PDP6.
  • Cost and capabilities of early computers highlighted (e.g., IBM 70 90 cost over $15 million with less than a megabyte of memory).

Philosophical Insights on Programming

• Nature of Programming:
  • Programming is not merely coding but a form of abstract engineering design.
  • Specifications are often unclear or evolve during the development process.
  • Analogous to creative arts like poetry, music, and architecture.
• Creative Process:
  • Importance of planning and debugging, comparing programming to the creation of artistic works and scientific theories.
  • Emphasis on programming as a process of continuous refinement and exploration.
  • Quote: "Programming is fun because it allows for creative problem-solving and exploration of new ideas."

Programming as a Learning Tool

• Education and Influence:
  • Shared experiences from his freshman year at MIT learning LISP and its transformative impact.
  • The role of programming in enhancing understanding of complex subjects like physics and mathematics.
• Historical Comparisons:
  • Comparison of programming concepts like the eval-apply interpreter to Maxwell’s equations in physics.
  • Philosophical reflections on dualities and the nature of identity in programming.

The Joy of Debugging

• Debugging as a Learning Opportunity:
  • Bugs are not failures but opportunities to learn and improve designs.
  • Debugging described as a detective adventure.
  • Quote: "Interesting bugs are a consequence of doing things right because they reveal the limitations of our initial assumptions."

Modern Programming Challenges and Fun

• Modern Tools and Systems:
  • Critique of languages like C and Python for their inconsistencies and potential to introduce errors.
  • Praise for the flexibility and expressiveness of languages like LISP and Scheme.
• Innovations in Programming:
  • Shared personal anecdote about developing automatic differentiation using dual numbers.
  • Collaboration with other researchers to extend programming capabilities in areas like classical mechanics and differential geometry.
  • Quote: "Programming languages need to be flexible enough to allow for abstract thinking and extension of primitive operations."

Conclusions

• Programming as an Intellectual Pursuit:

  • Emphasis on programming as a source of intellectual pleasure through discovery, philosophical contemplation, and creative problem-solving.
  • Encouragement to view programming as a means of achieving clarity in thought and expression.
  • Quote: "The fun in programming comes from the joy of discovery and the satisfaction of creating something that works beautifully."

• Call to Action:

  • Encouragement to share work with others and contribute to free software initiatives.
  • Quote: "Programming is most fun when you can share your work with others. Write and use free software."

Additional Resources and References

• Further Learning:
  • Mention of influential books and works by Sussman and collaborators, such as "Structure and Interpretation of Computer Programs" and "Software Design for Flexibility."
  • References to external resources like Spivak's "Calculus on Manifolds" for mathematical notation and theories.

This summary captures the main ideas and key points from Gerald J. Sussman's talk, highlighting the evolution of programming, the joy of creative problem-solving, and the importance of sharing knowledge and tools within the programming community.

• Work toward a collection of use-cases
• Always design & test against all of them

• Introduction to Presentation

  • Speaker introduces themselves as Lou or Luke and begins the presentation titled "Cell Pond: Spatial Programming Without Escape."
  • The presentation is structured into three parts: spatial programming, Cell Pond, and the concept of programming without escape.

• Part 1: Spatial Programming

  • Lou shares a personal story from 23 years ago about their interest in trains and computers, learning to code with Stagecast Creator.
  • Stagecast Creator involved drag-and-drop spatial rules, where actions were defined by before-and-after pictures, such as character movement and obstacle navigation.
  • Despite its popularity, spatial programming had limitations, especially in 3D environments, requiring many rules for simple tasks.
  • Block-based coding became the norm, leading to a decline in spatial programming's popularity.

• Spatial Programming Tools

  • Various spatial programming tools are introduced, such as Splats, Color Code, NetBoden, and Viskit, each serving different purposes like education, art, simulation, and games.
  • Lou introduces their own tool, Sand Pond, which uses before-and-after pictures to code elements like sand, water, and rock.

• Challenges of Spatial Programming

  • The main challenge is the reliance on escape hatches, where more complex tasks require traditional programming, not just spatial rules.
  • Tools like Stagecast Creator and others incorporate lines of code for advanced functions, highlighting the limitation of pure spatial programming.

• Part 2: Cell Pond

  • Lou demonstrates Cell Pond, a tool where users can paint and create rules using color channels and directional triangles to manipulate spatial elements.
  • Example: A rule turning green into pink is shown, highlighting how spatial rules work dynamically.
  • Users can create complex simulations with multiple rules, illustrating conservation of properties like color across rules.
  • A key feature is creating generalized rules that apply to multiple elements, such as sand, water, and rock.

• Concept of Conservation in Cell Pond

  • Conservation ensures that properties remain consistent when elements interact, demonstrated through color copying.
  • Complex behaviors like diffusion are shown, where rules allow elements to swap positions randomly.

• Advanced Features of Cell Pond

  • Cell Pond supports splitting and merging cells to increase or decrease resolution and store more data.
  • Example: Creating a fractal by continuously splitting cells, demonstrating Cell Pond's potential for complex simulations.

• Part 3: Programming Without Escape

  • Lou questions if it's possible to create a powerful spatial programming tool without escape hatches.
  • The breakthrough came from creating a virtual machine called Dragon, which includes instructions for memory operations, streamlining the creation of spatial rules.

• Implications and Future Directions

  • Lou reflects on how the virtual machine (VM) simplifies the process, leading to better UI development.
  • The goal is to develop higher-level spatial programming languages, exploring what a "C of spatial programming" might look like.

• Q&A Session

  • Lou discusses the iterative design process and the importance of strict goals to achieve the intended functionality of Cell Pond.
  • Comparisons to other games like "Falling Sand" and "Baba is You" are made, highlighting influences and potential future directions.
  • Lou addresses the balance between adding UI features and maintaining VM capabilities, emphasizing the VM's core role in enabling advanced functions.
  • The presentation concludes with a discussion on live programming's role in creativity and how it fosters exploration and discovery in computational creativity.

Summary of David Nolan's Talk on Predicate Dispatch and Pattern Matching in Clojure

• Introduction to Predicate Dispatch:

  • David Nolan introduces the concept of predicate dispatch and its benefits, calling it "incredible benefits of wishful thinking".
  • Nolan references an email from Rich Hickey mentioning predicate dispatch as an improvement over current multi-methods.

• Historical Context and Personal Journey:

  • Nolan recounts his journey from discovering William Byrd’s dissertation on miniKanren to implementing core.logic in Clojure.
  • He acknowledges the influence of logic programming and the flexibility of Clojure in incorporating such advanced concepts.

• Core.logic and Performance Enhancements:

  • Nolan's implementation of core.logic made it idiomatic to Clojure with significant performance enhancements.
  • He highlights features like knowledge base facilities similar to Prolog, which allow defining FAQs and running queries.

• Pattern Matching Exploration:

  • Nolan describes his deep dive into the theory of pattern matching, inspired by William Byrd's alphaKanren and Luke Maranjé's work on compiling pattern matching to decision trees.
  • Maranjé's approach uses lazy pattern matching to create shorter decision trees, enhancing efficiency.

• Predicate Dispatch in Detail:

  • Nolan discusses Craig Chambers’ paper on efficient predicate dispatch, noting its comprehensive handling of single and multiple dispatching, predicate classes, and classifiers in pattern matching.
  • He explains the challenges in implementing a flexible and efficient predicate dispatch system, mentioning the hardwired handling of numeric operations in Chambers’ system.

• Limitations of Multi-Methods in Clojure:

  • Multi-methods in Clojure are powerful but limited by the dispatch function, which can restrict future extensions.
  • Nolan emphasizes the need for a more flexible system like predicate dispatch, which allows for dynamic and open-ended dispatching.

• Core.match and Extensibility:

  • Nolan's core.match library aims to provide a pattern matching facility in Clojure with extensibility in mind.
  • Core.match uses a pattern matrix to optimize decision trees, allowing for efficient pattern matching by reordering tests based on the most constrained variables.

• Examples of Pattern Matching:

  • Nolan provides examples of matching sequences and maps, demonstrating how core.match handles different data structures efficiently by analyzing and reordering patterns.
  • The algorithm ensures minimal testing by leveraging random access in maps and optimized testing order for sequences.

• Challenges in Dynamic Predicate Dispatch:

  • Nolan addresses the complexity of making predicate dispatch dynamic and extensible, highlighting the need for namespace-local changes to avoid breaking existing code.
  • He proposes using core.logic to drive the core.match compiler, ensuring logical consistency and efficient dispatch tree generation.

• Future Directions and Open Questions:

  • Nolan suggests several strategies for maintaining performance in a dynamic system, such as lazy compilation and grouping predicate dispatch definitions.
  • He invites the community to contribute ideas and solutions to the challenges of dynamic predicate dispatch, emphasizing Clojure’s flexibility and the importance of non-overlapping clauses.

• Conclusion and Community Engagement:

  • Nolan concludes by encouraging the community to experiment and innovate with predicate dispatch and pattern matching in Clojure, aiming for next year's advancements to be a reality rather than wishful thinking.

Keynote Summary: Enhancing Programming Languages with Direct Manipulation Interfaces

Introduction

• Motivation: Enhance programming languages and tools to be more interactive, human-friendly, and accessible.
  • "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."

Current State of Programming Interfaces

• Limitations: Traditional programming interfaces are text-based and lack the interactivity of other computer applications.

  • "The actual interfaces we use to build and understand our programs essentially look like this: we have a big text box where we punch in our source code."

• Ideal Scenario: Blend the expressive power of programming languages with tangible, interactive user interfaces.

  • "We also want to need tangible interactive user interfaces for understanding and manipulating the concrete things we are making."

Programming with Direct Manipulation

• Concept: Systems that allow seamless transitions between text-based programming and direct manipulation of code and output.
  • "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

• Legacy: The vision for interactive programming has roots in the 1960s with works like Sutherland's Sketchpad and Engelbart's interactive computing.
  • "Similar visions for interactive programming systems to augment human creativity and intelligence can be traced all the way back to the 1960s."

Techniques and Trends

• Renewed Interest: Recent conferences and workshops indicate a growing interest in integrating programming languages (PL) with human-computer interaction (HCI).
  • "In the past decade or so there's been renewed interest in these challenges which lie at the intersection of PL and HCI."

Sketch and Sketch System

• Prototype: An exploration into combining direct manipulation and programming by demonstration in a lambda calculus environment.

  • "In my group we've been exploring a few ideas in a prototype system called sketch and sketch."

• Key Features:

  • Programming by Demonstration: Building programs through direct manipulation and demonstration in a pure lambda calculus.

  • "Every direct manipulation interaction in the output pane is codified as a change to the program in the left pane."

  • Structure Editing: Integrating abstract syntax tree (AST) manipulation within a text editor.

  • "The left pane also supports certain program transformations by hovering, selecting, and clicking on the abstract syntax tree."

  • Bi-directional Programming: Allowing changes to program output to propagate back to the source code.

  • "In sketch and sketch, bi-directional programming features are used to reconcile changes to output values."

Broader Research Themes

• Programming by Demonstration: Techniques for representing GUI interactions as ordinary text-based programs.

  • "Our goal in sketch and 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."

• Structure Editing: Enhancing the usability of programming environments by supporting structure-based program transformations.

  • "Structure editing of an abstract syntax tree might be streamlined into an ordinary existing text editor."

• Bi-directional Programming: Extending traditional lenses to mainstream languages and exploring backward evaluation for program expressions.

  • "Several recent proposals employ some kind of backward evaluation that allows all program expressions to be run in reverse."

Live Programming and Synthesis

• Immediate Feedback: Providing users with real-time feedback about the dynamic behavior of their programs.

  • "Live programming interfaces can be useful in educational contexts."

• Integration with Synthesis: Developing interfaces where program synthesis techniques help fill in code holes based on user interaction.

  • "There have been other promising ideas for integrating program synthesis techniques into a live programming loop."

Application Domains

• Spreadsheets: Enhancing spreadsheets with more structured data types and reactive programming features.

  • "The spreadsheet interface is now probably one of the most promising approaches to live programming in a general setting."

• Graphics Editors: Combining programming and direct manipulation in tools for data visualization and creative expression.

  • "There are a variety of different kinds of programming and GUI systems for making charts."

Future Directions

• General Framework: Developing a general framework for programming with traces and demonstration.

  • "Can we design every graphical user interface to be backed by text-based programs in a general programming language?"

• Improving Usability: Studying programmer behavior to design better hybrid text and structure interactions.

  • "If we study more about how programmers go about their work, we can design better hybrid text plus structure interactions to help."

Conclusion

• Call to Action: Encouragement for more research and collaboration to achieve the goal of more interactive and user-friendly programming systems.
  • "There are certainly missions out there for you."

This summary encapsulates the critical aspects and insights of Ravi Chugh's keynote on making programming languages more interactive and user-friendly through the integration of direct manipulation interfaces.

• Introduction to re:Invent 2021:

  • Werner Vogels, CTO of Amazon.com, celebrates the 10-year anniversary of re:Invent.
  • Emphasis on the evolution and innovation in cloud computing over the past decade.

• Historical Context and AWS Lambda:

  • Introduction of AWS Lambda as an event-driven compute service eliminating the need for servers: "introduce AWS Lambda, which is an event-driven compute service for a dynamic application, and you have to run no servers, no instances, server-free back ends."
  • Reflection on the cloud's impact on innovation and resource accessibility: "Suddenly, getting access to capacity was just a click of a button."

• Evolution of AWS Services:

  • Transition from physical to programmable resources, enhancing scalability and flexibility: "all the hardware pieces... now became virtually programmable."
  • Development of specialized EC2 instances for various needs (compute, memory, storage): "Now, you want to store the optimized ones, you want compute optimized, you want to have large memory instances where you could run your SAP online."

• Technological Innovations and Nitro Hypervisor:

  • Investment in data centers and introduction of the Nitro hypervisor for enhanced performance: "The Nitro hypervisor made it possible to introduce all these new hardware platforms for you."
  • Launch of Mac EC2 M1 instances, highlighting Apple's shift to custom silicon: "Today, I'm happy to announce that you will get your hands on the Mac EC2 M1 instances."

• Scaling and Utilization of EC2:

  • Significant increase in EC2 usage: "60 million launches of EC2 each day," doubling since 2019.
  • Importance of scaling both up and down to optimize resource use and energy consumption.

• AWS Global Footprint and Latency Reduction:

  • Expansion to 25 regions and 81 Availability Zones, with plans for more: "there are the nine more regions planned that we will bring online in the coming two years."
  • Development of Local Zones and AWS Wavelength for low-latency applications.

• Advances in Networking and AWS Cloud WAN:

  • Introduction of AWS Cloud WAN for building and managing global networks: "AWS Cloud WAN, which gives you the ability to build, manage, monitor global-private five wide area networks using AWS."
  • Shift from EC2-Classic to VPC as the default network model.

• Edge Computing and IoT:

  • FreeRTOS and AWS IoT Core for managing billions of devices: "for that, we give you FreeRTOS as a stable base as an operating system for these devices."
  • Introduction of AWS Panorama Appliance for video stream analysis in various environments.

• AWS in Space:

  • AWS Ground Station enabling space data processing and innovation: "Ground Station, data comes off to the Ground Station, you basically just went a 10-hour time to get your data of your satellites and move into AWS."
  • Case study of the Mohammed Bin Rashid Space Center using AWS for Mars exploration data.

• Development Tools and Services:

  • Launch of AWS Amplify Studio for low-code development: "AWS Amplify Studio, which is a completely visual environment to build feature rich apps in hours and weeks."
  • Introduction of new SDKs for Swift, Kotlin, and Rust, expanding developer tools.

• Customer Success and Best Practices:

  • Liberty Mutual's journey using AWS CDK for rapid, compliant development: "delivering industry leading capabilities like our unstructured data ingestion pipeline... all built using well architected CDK patterns."
  • Emphasis on reusable constructs and Well-Architected Framework to optimize development processes.

• Sustainability and Energy Efficiency:

  • AWS's commitment to reducing carbon footprints through efficient cloud solutions: "moving on premises workloads to AWS can lower your carbon footprint by 88%."
  • Introduction of the AWS Carbon Footprint Tool and new Sustainability Pillar in the Well-Architected Framework.

• Gaming and Distributed Systems:

  • Overview of New Worlds, an MMORPG game built on AWS architecture: "New Worlds is a game designed by Amazon Games... a massively online multiplayer game where players from all over the world can connect together and play together."
  • Details on the scalable, serverless architecture enabling immersive gameplay and rapid scaling: "in New Worlds, we were able to do this 30 times a second."

• Final Advice and Vision:

  • Importance of security, simplicity, and innovation in building modern applications: "protecting your customers will be forever, should be forever your number one priority."
  • Encouragement to build with AWS's broad array of services and tools, emphasizing sustainability and efficient resource use.

Here is a detailed, thorough, in-depth, and concise summary of the provided research paper, formatted as a bullet outline for easy understanding. Each bullet point includes a relevant quoted sentence for reference.

Abstract

• Influence of Tokenization: Tokenization significantly influences language models (LMs)’ performance.
• Evolution of Tokenizers: Traces the evolution from word-level to subword-level tokenizers.
• Challenges with Subword Tokenizers: Subword tokenizers face difficulties with non-Latin languages and require extensive training data.
• Principle of Least Effort: Introduces the Principle of Least Effort from cognitive science to improve tokenizers.
• Less-is-Better (LiB) Model: Proposes the LiB model, which learns an integrated vocabulary of subwords, words, and multiword expressions (MWEs).
• Evaluation of LiB Model: Comparative evaluations show that the LiB tokenizer outperforms existing word and BPE tokenizers [❞].

Introduction

• Simplification of Information: Our brains simplify vast or intricate information into smaller segments to better understand and remember it.
• Impact of Tokenizers on LMs: The choice of tokenizer crucially impacts the performance of language models.
• Tokens and Types: Investigates the roles of tokens and types in tokenizer design to optimize performance.
• Human Language Processing: Argues that tokenizers should emulate human language processing methods [❞].

From Word-level Tokenizers to Subword-level Tokenizers

• Initial Word-level Tokenizers: Word-level tokenizers initially divided text into words using spaces and punctuation.
• Limitations: Word-level tokenizers struggled with languages without clear word boundaries and flexible morphological inflections.
• Rise of Subword Tokenizers: Subword tokenizers became mainstream due to their flexibility and ability to generalize [❞].

Balancing Tokens and Types by Subwords

• Core Consideration: Balancing the number of tokens and types is crucial in transitioning from word-level to subword-level tokenizers.
• Example of BPE and WordPiece: These tokenizers handle rare vocabularies by merging frequently occurring character pairs.
• Efficiency of Subword Tokenization: Subword tokenizers reduce the number of types significantly while slightly increasing the number of tokens, enhancing model performance and adaptability [❞] [❞].

Current Marginalization of Multiword Expressions (MWEs) in Language Models

• Importance of MWEs: MWEs play a crucial role in everyday language but are often overlooked in LM development.
• Challenges: Introducing MWEs increases the number of types and complexity, leading to rare or domain-specific MWEs being underrepresented in training data.
• Potential Benefits: Direct recognition of MWEs can enhance the model’s language comprehension and accuracy [❞] [❞].

Optimizing Future Tokenizers

• Human Language Processing: Emulating human language processing methods can optimize tokenizer design.
• Principle of Least Effort (PLE): The PLE suggests that people follow paths that minimize effort, and this principle can guide the design of efficient tokenizers [❞] [❞].

Principle of Least Effort

• Human Tokenization: Humans learn and recognize cognitive units (words, subwords, MWEs) that reduce language complexity.
• Cognitive Units: These units are adaptable in size and form, reflecting how humans process language.
• Zipf’s Principle: Zipf’s Principle of Least Effort states that people strive to minimize total work in solving immediate and future problems [❞] [❞].

LiB Model: An Implementation of ‘Principle of Least Effort’

• Model Mechanism: The LiB model consists of a “Memorizer” that merges tokens into longer units and a “Forgetter” that removes less useful units, balancing the number of tokens and types.
• Flexibility and Performance: The LiB model autonomously learns a vocabulary that includes subwords, words, and MWEs, performing better than traditional tokenizers in various evaluations [❞] [❞] [❞].

This structured summary encapsulates the essence of the research paper while providing clear references to the original text for verification and further reading.

Summary of "A History of Clojure" by Rich Hickey

Key Points and Quotes:

• Introduction and Design Goals:

  • "Clojure was designed to be a general-purpose, practical functional language, suitable for use by professionals wherever its host language, e.g., Java, would be."
  • It aims to combine the features of functional programming and Lisp while running on the runtime of another language such as the JVM.

• Unique Positioning:

  • "Most of the ideas in Clojure were not novel, but their combination puts Clojure in a unique spot in language design (functional, hosted, Lisp)."
  • This combination allows Clojure to leverage existing libraries and interoperate efficiently with its host language.

• Concurrency and State Management:

  • "It complements programming with pure functions of immutable data with concurrency-safe state management constructs that support writing correct multithreaded programs without the complexity of mutex locks."
  • This feature is crucial for developing robust multithreaded applications.

• Adoption and Impact:

  • "In spite of combining two (at the time) rather unpopular ideas, functional programming and Lisp, Clojure has since seen adoption in industries as diverse as finance, climate science, retail, databases, analytics, publishing, healthcare, advertising, and genomics, and by consultancies and startups worldwide."
  • Clojure's adoption across various industries showcases its versatility and effectiveness.

• Evolution and Community:

  • "This paper recounts the motivation behind the initial development of Clojure and the rationale for various design decisions and language constructs. It then covers its evolution subsequent to release and adoption."
  • The language has evolved through community contributions and the author's vision, continuously adapting to new challenges and requirements.

• Host Language Integration:

  • "Clojure is intentionally hosted, in that it compiles to and runs on the runtime of another language, such as the JVM."
  • This intentional design choice allows Clojure to benefit from the performance and ecosystem of its host language.

Main Ideas and Takeaways:

• Practical Functional Language: Designed to be practical and usable in professional environments, leveraging the strengths of functional programming and Lisp.
• Concurrency-Safe: Emphasizes immutability and concurrency-safe constructs to facilitate the development of correct and efficient multithreaded applications.
• Wide Adoption: Despite initial skepticism, Clojure's unique approach has led to its adoption across a diverse range of industries.
• Community and Evolution: The language's evolution is driven by both community input and the original design vision, ensuring it remains relevant and robust.
• Integration with Host Languages: By compiling to and running on established runtimes like the JVM, Clojure can interoperate with existing libraries and technologies efficiently.

This summary captures the essence of the provided text while adhering to the specified guidelines.

Summary of "The Essence of Dataflow Programming"

Introduction

• Comonadic Approach to Dataflow Computation:
  • "We propose a novel, comonadic approach to dataflow (stream-based) computation."
  • The approach is based on comonads, which structure context-dependent computations.

Key Concepts and Takeaways

• Pure and Impure Computations:

  • Examples of pure and impure functions are provided to illustrate how impure computations can be handled using monads.
  • "Ever since the work by Moggi and Wadler, we know how to reduce impure computations with errors and non-determinism to purely functional computations."

• Dataflow Computation:

  • Dataflow computation involves programming with streams or signals in discrete time.
  • "The style of programming is functional, but any expression denotes a stream (a signal)."

Comonads vs. Monads in Dataflow

• Limitations of Monads:

  • Monads are not suitable for structuring dataflow computations.
  • "Could it be that monads are capable of structuring notions of dataflow computation as well? No, there are simple reasons why this must be impossible."

• Advantages of Comonads:

  • Comonads provide a better framework for dataflow computation.
  • "Comonads are even better, as there is more structure to comonads than to arrow types."

Implementation and Examples

• Comonadic Interpreter:

  • The paper develops a generic comonadic interpreter for context-dependent computation, specifically for stream-based computation.
  • "We show that general and causal stream functions... are elegantly described in terms of comonads."

• Higher-order Dataflow Languages:

  • The approach allows for higher-order dataflow language designs with minimal effort.
  • "Remarkably, we get elegant higher-order language designs with almost no effort."

Combining Effects and Context-dependence

• Distributive Laws:
  • The paper discusses the use of distributive laws to combine effectful and context-dependent computations.
  • "We show how effects and context-dependence can be combined in the presence of a distributive law of the comonad over the monad."

Conclusion

• Relevance of Comonads:
  • Comonads are presented as highly relevant for programming language semantics, particularly for context-dependent computations.
  • "While notions of dataflow computation cannot be structured with monads, they can be structured perfectly with comonads."

This summary encapsulates the critical points and concepts presented in the provided document on the comonadic approach to dataflow programming. It highlights the advantages of comonads over monads in this context, and provides an overview of the implementation and potential applications of this approach.

Summary of "A History of Clojure" by Rich Hickey

Key Points and Quotes:

• Introduction and Design Goals:

  • "Clojure was designed to be a general-purpose, practical functional language, suitable for use by professionals wherever its host language, e.g., Java, would be."
  • It aims to combine the features of functional programming and Lisp while running on the runtime of another language such as the JVM.

• Unique Positioning:

  • "Most of the ideas in Clojure were not novel, but their combination puts Clojure in a unique spot in language design (functional, hosted, Lisp)."
  • This combination allows Clojure to leverage existing libraries and interoperate efficiently with its host language.

• Concurrency and State Management:

  • "It complements programming with pure functions of immutable data with concurrency-safe state management constructs that support writing correct multithreaded programs without the complexity of mutex locks."
  • This feature is crucial for developing robust multithreaded applications.

• Adoption and Impact:

  • "In spite of combining two (at the time) rather unpopular ideas, functional programming and Lisp, Clojure has since seen adoption in industries as diverse as finance, climate science, retail, databases, analytics, publishing, healthcare, advertising, and genomics, and by consultancies and startups worldwide."
  • Clojure's adoption across various industries showcases its versatility and effectiveness.

• Evolution and Community:

  • "This paper recounts the motivation behind the initial development of Clojure and the rationale for various design decisions and language constructs. It then covers its evolution subsequent to release and adoption."
  • The language has evolved through community contributions and the author's vision, continuously adapting to new challenges and requirements.

• Host Language Integration:

  • "Clojure is intentionally hosted, in that it compiles to and runs on the runtime of another language, such as the JVM."
  • This intentional design choice allows Clojure to benefit from the performance and ecosystem of its host language.

Main Ideas and Takeaways:

• Practical Functional Language: Designed to be practical and usable in professional environments, leveraging the strengths of functional programming and Lisp.
• Concurrency-Safe: Emphasizes immutability and concurrency-safe constructs to facilitate the development of correct and efficient multithreaded applications.
• Wide Adoption: Despite initial skepticism, Clojure's unique approach has led to its adoption across a diverse range of industries.
• Community and Evolution: The language's evolution is driven by both community input and the original design vision, ensuring it remains relevant and robust.
• Integration with Host Languages: By compiling to and running on established runtimes like the JVM, Clojure can interoperate with existing libraries and technologies efficiently.

This summary captures the essence of the provided text while adhering to the specified guidelines.

• Introduction and Context:

  • The talk focuses on "rethinking identity with Clojure" by a senior software engineer at Vouch.
  • Vouch is developing a platform to address identity and trust issues among people, machines, and processes.
  • The speaker emphasizes leveraging emerging technologies for significant improvements in current best practices.
  • "At Vouch, we love Clojure and ClojureScript" for tackling ambitious problems with a small team.

• Clojure Philosophy:

  • The Clojure philosophy, which emphasizes separating concerns and simplifying complexity, guides Vouch's approach to problem-solving.
  • The speaker references Rich Hickey's talk "Simple Made Easy," which highlights the importance of decoupling elements to reduce complexity.
  • "As software developers, we often do this thing called complecting," where unrelated aspects are combined, creating complications.

• Security and User Experience:

  • A fundamental flaw in security systems is poor user experience, particularly in how users secure their accounts.
  • "If the user experience is wrong, there's nothing you can do because in any system, people are often the weakest link."
  • The speaker argues that complexity in security measures, like passwords, leads to vulnerabilities due to user error.

• Clojure's Approach to Simplifying Complexity:

  • Clojure decouples programs from state, a core principle borrowed from functional programming.
  • This separation simplifies development and reduces bugs, particularly in concurrent programming.
  • "Clojure adopted the idea from Ruby, Python, and JavaScript that the common pattern is data literals."

• Innovations in Clojure and Its Impact:

  • Rich Hickey innovated by proving that persistent data structures can perform well on modern hardware.
  • "Persistent data structures...give me these certain properties in a concurrent scenario but...in a very easy to use ergonomic way."

• Applying Clojure Principles to Identity and Security:

  • Vouch uses secure enclaves in devices like iPhones and Google's Titan M to manage cryptographic keys securely.
  • "What just happened there are no secrets. The secret isn't on our server. We don't know anything about secrets."
  • This method ensures that even if a device is lost, unauthorized access is prevented due to the secure enclave.

• Blockchain and Distributed Systems:

  • Vouch leverages blockchain (Hyperledger Fabric) to ensure tamper-evidence and secure user actions.
  • "All interactions with our system write to the blockchain...prevent tampering with the actions that users have taken."

• Developer Experience with Clojure:

  • Clojure allows Vouch's small team to be highly productive, with one language for all system parts.
  • "We actually get a feedback loop into every piece of our architecture...we have a shell into it and can interact with it using our language."
  • ClojureScript enables writing code once and deploying it across multiple platforms, saving development time.

• Practical Demonstration:

  • The speaker showcases an app that uses biometrics for logging into services, demonstrating a superior user experience compared to traditional passwords.
  • "The user experience needs to be so good that this feels better than the password approach."

• Closing Thoughts:

  • The speaker encourages finding and addressing sources of complexity to improve user and developer experience.
  • "Complexity is not just the software; it will eventually burden your users."
  • Revisiting Clojure can benefit teams building ambitious full-stack solutions with many moving parts.

• Q&A Highlights:

  • Addressing concerns about biometrics and fallback mechanisms, such as using blockchain for account recovery.
  • Clarifying the differences between Clojure spec and other type systems, emphasizing runtime-oriented specifications.
  • Discussing the soundness and limitations of using Clojure in security-focused projects.

• The speaker, an experienced software developer with expertise in C++, Java, and Clojure, introduces key concepts in Clojure programming, emphasizing the shift from Java to Clojure for enhanced code efficiency and readability.

  • "I've been doing software development since I was kid and professionally for you know 1517 something like that years now I did a little bit of C++ work and then spent a long time in Java."

• The talk focuses on the differences between values and objects, highlighting the immutability of values in Clojure and contrasting it with the mutability of objects in Java.

  • "I'm going to start by talking about values and what is the value... all of these things are immutable."

• Values in Clojure have intrinsic, semantically evident meanings, allowing for precise and undisputed representation and equality comparison.

  • "It has a precise meaning and it's semantically evident what we mean by that... all of these things are immutable."

• Composite values in Clojure allow for creating larger data structures from primitives while retaining immutability, ensuring consistent behavior and avoiding common issues with mutable objects.

  • "With a composite value, you should not have to write an equals method; it should be semantically evident whether two things are equal or not."

• Clojure collections (vectors, lists, maps, sets) are introduced as immutable composite values that offer extensive functionality and efficiency despite initial concerns about performance.

  • "Vectors are what you use constantly in Clojure... they are expandable indexed collections."

• Sequences in Clojure are immutable views into collections, providing a powerful abstraction for functional programming and enabling efficient handling of large or infinite data sets.

  • "Sequences are really immutable views into a collection... logically a list and you can get back from it the first."

• Generic data interfaces in Clojure facilitate the handling of diverse data types through consistent, reusable functions, enhancing code reusability and reducing redundancy.

  • "Closure does not do that and that is one of the things I really like about it."

• Identity and state are treated distinctly in Clojure, with immutable values representing states at particular points in time, offering a clearer and more predictable model for concurrent programming.

  • "Identity is an abstraction that represents an entity whose state changes over time, while state is the value of an identity at a point in time."

• Clojure's software transactional memory (STM) model provides robust mechanisms for managing state changes in concurrent environments, ensuring consistency and reliability.

  • "STM protects you from inconsistent views and ensures that the states you perceive are coherent and correct."

• The speaker emphasizes that transitioning to programming with immutable composite values significantly changes one's approach to software development, leading to more maintainable and less error-prone code.

  • "I say this night seriously it will change the way you think about programming to start from immutability like this you'll design and write code differently."

• Metaphor of Knowledge and Innocence in "The Time Machine"

  • "HG Wells' 'The Time Machine' describes a world populated by two races, the Eloi and the Morlocks."
  • "The Eloi live in a paradise they don't fully understand, and sometimes what they don't know comes up and bites them."

• Foundations of Software Engineering

  • "As software engineers, we build on foundations that we don't understand...we sit atop 60 years of accreted abstractions."
  • "At some point, we have to be content with what we know and build upwards."

• Hierarchical Structures in Problem Solving

  • "We're taught ways to cope with the fact that we don't understand the systems that we build in their entirety, and chief among them is the hierarchy or the tree."
  • "For some problems, this is a completely accurate representation... but the systems we build look more like this (diagram of connected components)."

• Polite Fiction and Model Limitations

  • "We spend a lot of our time pretending that these two things (simple hierarchies and complex systems) are the same... it's a necessary story because otherwise, we can't make progress."
  • "It's easy to forget that the model we have is not the world as it actually is."

• Historical Example: Scientific Forestry

  • "Scientific forestry is roughly the process of going from a natural forest to a monoculture for efficient lumber production."
  • "The bureaucrat understood that his model was not the forest as it actually was... he made the world conform to his understanding of it."

• Systems Thinking and Complexity

  • "Gerald Weinberg defines a space with two axes: complexity and randomness."
  • "Heuristic devices are lossy ways of looking at the world... effective models but not true models."

• Mid-Century Critical Theory and Heuristic Devices

  • "Deleuze and Guattari talk about the interplay between the state (hierarchical structures) and the Nomad (local understanding)."
  • "They describe 'rhizomatic' structures versus 'arborescent' or tree-like structures."

• Borges' Parable: The Map and the Territory

  • "In Borges' story 'On Exactitude in Science,' a map the size of the empire becomes useless."
  • "We use maps because they are reductive... as we become more reductive, the utility of the map falls off."

• Modern Urban Design and Control

  • "Baron Haussmann's redesign of Paris included wide roads to prevent slums from seceding."
  • "Le Corbusier's sketches for the new center of Moscow had no concern for the context."
  • "Brasilia's construction showed the failure of a completely planned city, leading to disconnected spaces and 'Brasília' syndrome."

• Pattern Language and Quality without a Name

  • "Christopher Alexander's 'A Pattern Language' and 'A Timeless Way of Building' describe a holistic quality in buildings."
  • "Alexander emphasizes that this quality is contextual and cannot be reduced."

• Software Design Patterns and Habitability

  • "The Design Patterns book tries to give universal constructs, missing the contextual nature of Alexander's ideas."
  • "Richard Gabriel's 'Patterns of Software' focuses on habitability... the degree to which you can make a codebase your own and adapt to changes."

• Timeless Knowledge versus Cunning

  • "The Greeks had two words for knowledge: 'techne' (timeless knowledge) and 'metis' (cunning)."
  • "In practice, everything depends on the domain and our experience, not on universal truths."

• Conclusion and Broader Lessons

  • "We should plan for the eventuality that our models and systems will be wrong."
  • "The goal is to inform intuition and provide a vocabulary for discussing complex systems and their trade-offs."

https://github.com/TimelyDataflow/differential-dataflow https://github.com/TimelyDataflow/timely-dataflow

https://tonsky.me/blog/the-web-after-tomorrow/

Data arrival triggers computation, ensuring systems stay in sync with real-time changes.

• Introduction and Context:

  • "Thank you for coming, this is reactive data log for data..."
  • Nicolas Gruber, a software consultant and graduate student at ETH Zurich, discusses reactive systems and introduces 3DF, a system for reactive data log evaluation.

• Definition and Importance of Reactive Systems:

  • "We want to make reactive systems that don't poll and we want those systems to get a consistent view of the world."
  • Reactive systems trigger computations based on new data arrivals instead of polling at regular intervals.
  • Examples include live-updating web applications, alerting systems, and real-time dashboards.

• Key Characteristics of Reactive Systems:

  • "All these systems share the interesting property that data coordinates code and not the other way around."
  • Data arrival triggers computation, ensuring systems stay in sync with real-time changes.

• Reactive Data Management Approach:

  • Nikita Prokopev's vision for future web applications involves handling unbounded data streams and deriving refined views for individual users.
  • "We want this derivation to stay in sync as new data arrives."

• Practical Example and Demonstration:

  • The example domain involves persons issuing loans with hierarchical bank branch structures and user permissions.
  • "For this child branch we have read permission initially and we have two initial loans..."
  • The demo illustrates how the system maintains real-time updates and permissions adjustments using data log rules.

• System Overview - 3DF:

  • 3DF performs reactive data log evaluation on a distributed data parallel stream processor.
  • "We've been developing that for the better part of this year now."

• Core Concept of Incremental Computation:

  • "We need the modified operator...that gives us the exact set of changes that are required."
  • 3DF propagates only changes to optimize performance and ensure real-time updates.

• Handling Complex Queries and Iterative Computations:

  • "We want to do something that I actually didn't know at the beginning of this year was considered almost impossible..."
  • Iterative computations and reactive iteration are managed using the differential dataflow framework developed by Frank McSherry.

• Implementation Details and Differential Dataflow:

  • "Differential dataflow manages persistent multi-sets...logical collection of edges as a sequence of additions and retractions..."
  • Utilizes multi-dimensional timestamps for consistent, efficient reactive iteration.

• User and System Interaction:

  • External services and users can send data log queries to 3DF clusters, which update computations based on new data from sources like Datomic.
  • "External users other services can first of all of course transact data to Datomic..."

• Applications and Advantages:

  • 3DF enables scalable, distributed reactive systems beyond the limits of a single database peer.
  • "It lets you scale queries beyond the limits of a single peer in the way I discussed."

• Future Work and Community Involvement:

  • Continued development focuses on scalability, performance isolation, and robust integrations.
  • "We're working on bulletproofing that and we're working in general towards a better release of that system."
  • Encourages collaboration and engagement with others facing similar challenges.

This summary encapsulates the essence of the talk, highlighting the main ideas and essential information while maintaining clarity and conciseness.

• 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."

Summary of "Revised Report on the Propagator Model" by Alexey Radul and Gerald Jay Sussman

Introduction

• Main Problem: Traditional programming models hinder extending existing programs for new situations due to rigid commitments in the code.
• Quote: "The most important problem facing a programmer is the revision of an existing program to extend it for some new situation."
• Solution: The Propagator Programming Model supports multiple viewpoints and integration of redundant solutions to aid program extensibility.
• Quote: "The Propagator Programming Model is an attempt to mitigate this problem."

Propagator Programming Model

• Core Concept: Autonomous machines (propagators) communicate via shared cells, continuously adding information based on computations.
• Quote: "The basic computational elements are autonomous machines interconnected by shared cells through which they communicate."
• Additivity: New contributions are seamlessly integrated by adding new propagators without disrupting existing computations.
• Quote: "New ways to make contributions can be added just by adding new propagators."

Propagator System

• Language Independence: The model can be implemented in any programming language as long as a communication protocol is maintained.
• Quote: "You should be able to write propagators in any language you choose."
• Cell Operations: Cells support adding content, collecting content, and registering propagators for notifications on content changes.
• Quote: "Cells must support three operations: add some content, collect the content currently accumulated, register a propagator to be notified when the accumulated content changes."

Implementing Propagator Networks

• Creating Cells and Propagators: Cells store data, while propagators compute based on cell data. Propagators are attached using d@ (diagram style) or e@ (expression style) for simpler cases.
• Quote: "The cells' job is to remember things; the propagators' job is to compute."
• Example: Adding two and three using propagators.
• Quote: "(define-cell a) (define-cell b) (add-content a 3) (add-content b 2) (define-cell answer (e:+ a b)) (run) (content answer) ==> 5"

Advanced Features

• Conditional Network Construction: Delayed construction using conditional propagators like p:when and p:if to control network growth.
• Quote: "The switch propagator does conditional propagation -- it only forwards its input to its output if its control is 'true'."
• Partial Information: Cells accumulate partial information, which can be incrementally refined.
• Quote: "Each 'memory location' of Scheme-Propagators, that is each cell, maintains not 'a value', but 'all the information it has about a value'."

Built-in Partial Information Structures

• Types: Nothing, Just a Value, Numerical Intervals, Propagator Cells, Compound Data, Closures, Truth Maintenance Systems, Contradiction.
• Quote: "The following partial information structures are provided with Scheme-Propagators: nothing, just a value, intervals, propagator cells, compound data, closures, supported values, truth maintenance systems, contradiction."

Debugging and Metadata

• Debugging: Scheme's built-in debugger aids in troubleshooting propagator networks. Metadata tracking for cells and propagators enhances debugging.
• Quote: "The underlying Scheme debugger is your friend."
• Metadata: Tracking names and connections of cells and propagators helps navigate and debug networks.
• Quote: "Inspection procedures using the metadata are provided: name, cell?, content, propagator?, propagator-inputs, propagator-outputs, neighbors, cell-non-readers, cell-connections."

Benefits of the Propagator Model

• Additivity and Redundancy: Supports incremental additions and multiple redundant computations, enhancing flexibility and resilience.
• Quote: "It is easy to add new propagators that implement additional ways to compute any part of the information about a value in a cell."
• Intrinsic Parallelism: Each component operates independently, making the model naturally parallel and race condition-resistant.
• Quote: "The paradigm of monotonically accumulating information makes [race conditions] irrelevant to the final results of a computation."
• Dependency Tracking: Facilitates easier integration and conflict resolution via premises and truth maintenance.
• Quote: "If the addition turns out to conflict with what was already there, it (or the offending old thing) can be ignored, locally and dynamically, by retracting a premise."

Conclusion

• Goal Achievement: The Propagator Model approaches goals of extensibility and additivity by allowing flexible integration and redundancy in computations.
• Quote: "Systems built on the Propagator Model of computation can approach some of these goals."

• The speaker initially describes the excitement and complexity of rendering a simple red triangle in Clojure using a Java library.

  • "I found a Java library that gave bindings I started playing around with it and after quite a bit of struggle I was able to get a red triangle to show up on the screen."

• The creation of more complex shapes like the Sierpinski pyramid, which involves recursive geometric transformations, serves as an example to explore different programming abstractions.

  • "It's actually fairly straightforward and I'll switch to two dimensions for your convenience, you start with a triangle and you shrink it down to half its size and then you copy it twice."

• The speaker introduces macros as a way to handle repetitive code by creating a reusable "Sierpinski macro" that can be nested to achieve different levels of detail.

  • "We can write ourselves a Sierpinski macro which takes a body which is really just anything and first we wrap it in a function and then we create a scoped transform which shrinks everything that we draw by half."

• Despite their usefulness, macros have limitations in terms of composition and downstream flexibility, prompting the exploration of functions as a better abstraction.

  • "Macros are not necessarily our most composable sort of abstraction and this has two issues... there is no potential for downstream composition."

• Functions, though still limited, allow for more composable and testable abstractions by introducing indirection and treating rendering operations as data.

  • "We take our draw triangle function and we call it now it's a renderer and now we have a render function which simply invokes it."

• The speaker demonstrates how higher-order functions and mapping over data can create more flexible and testable code, moving from functions to data-centric approaches.

  • "We defined three of these that will offset and scale appropriately and now we Define a Sierpinski method which takes a list of shapes and returns a list of shapes which is three times larger with all of them sort of offset and scaled appropriately."

• The comparison between data, functions, and macros emphasizes the generality and composability of data-centric approaches, albeit with the necessity of grounding them in executable code.

  • "Data doesn't do anything by itself we have to sort of eventually ground out in code that does something we have to wrap our data in functions and execute our functions somewhere within our code."

• The speaker critiques taxonomies while acknowledging their utility in providing a framework for discussion and suggesting approaches.

  • "Taxonomies are not a way to perfectly model the world... but they give us both a vocabulary to talk about it and they give us sort of a predictiveness."

• Applying these abstractions to more practical examples, like sequence transformations and transducers, illustrates the balance between abstraction and practical utility.

  • "We can use the double threaded arrow to structure it so that the flow of data is left to right rather than inside out."

• The exploration of automaton theory and finite state machines (like Automat) showcases the power of data-driven approaches in providing flexibility and compositional capabilities beyond traditional regular expressions.

  • "Automaton Theory... there's a much richer set of tools there than I'd originally realized and I tried to encompass this in a library called Automat."

• The discussion on backpressure and causality in asynchronous programming highlights the importance of managing side effects and execution order in concurrent systems.

  • "Backpressure here is this emergent property because we have this structural relationship between this it's just that one happens before the other and that one can cause the other not to happen."

• The introduction of streams and deferreds in the Manifold library exemplifies a less opinionated approach to handling eventual values and asynchronous computation, allowing for greater flexibility in execution models.

  • "A stream is lossy right you take a message it's gone a deferred represents a single unrealized value and you can sort of consume it as many times as you like."

• The concept of "let-flow" in Manifold, which optimizes concurrency by analyzing data dependencies, demonstrates advanced techniques for achieving optimal parallel execution.

  • "Let-flow will basically walk the entire let binding figure out what the data dependencies are and execute them in the correct order."

• The speaker concludes by emphasizing the importance of understanding the different forces at play in software composition and encourages ongoing discussion to improve the ecosystem.

  • "This is what causes our ecosystem to flourish or dwindle right the degree to which all the disparate pieces can work together."

• In the Q&A, the speaker briefly touches on the position of monads in the spectrum and compares Automat to other finite state machine libraries like Regal.

  • "Where do you put monads in your spectrum... somewhere between functions and data right."
  • "Automat... is meant to be sort of a combinator version of Regal effectively."

• 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."

This outline captures the essential points and arguments presented, while providing specific quotes for reference.

• Introduction

  • Jerry Sussman discusses the importance of flexible programming systems.
  • "I want to show how to the ways of making systems that have the property that you can you write this big pile of code and you know you, you get all of a sudden it's gee I have a different problem I have to solve why can't I use the same piece of code."

• Personal Background

  • Sussman's extensive experience as a programmer since the 1960s.
  • "I'm the oldest guy here probably and way back when I first started programming computers that's what they looked like."

• Goals for Robust Systems

  • Desires systems that are generalizable, evolvable, and tough.
  • "I want is robust systems that have the following property that they're generalizable in the sense that... they're evolvable in the sense that they can be adapted to new jobs without modification."

• Critique of Programming 'Religions'

  • Emphasizes the need for diverse tools and approaches in programming.
  • "We have a lot of people who have religions about how to program... Each of which is good for some particular problems but not good for a lot of problems."

• Body Plans in Engineering and Programming

  • Discusses the concept of body plans from biology and its application in engineering.
  • "Superrod radio receiver... a body plan... that separates band selectivity from inter-channel selectivity."

• Multiple Approaches in Problem Solving

  • Highlights the value of having multiple methods to solve the same problem, inspired by biology.
  • "There are two ways to make a frog... why don't we do that in programming?"

• Biological Inspiration in Programming

  • Advocates learning from nature's solutions, such as the flexible human genome.
  • "One of the things nature does is it's very expensive... generates and tests... we don't do that very much in programming because it's expensive."

• Generating and Testing in Programming

  • Discusses McCarthy's amb operator for non-deterministic search.
  • "McCarthy's amb operator... is a modeling non-deterministic autometer."

• Generic Operations and Extensibility

  • Explains the power of generic operations and their application in programming.
  • "Most people think generic operations... in fact, automatic differentiation is just a generic extension of arithmetic."

• Risks and Benefits of Generic Extensions

  • Acknowledges the dangers of generic programming while emphasizing its power.
  • "Generic arithmetic... very dangerous... the only thing that scares me in programming is floating point."

• Teaching and Practical Applications

  • Emphasizes the importance of teaching robust, flexible programming techniques.
  • "I've only given you three of them... I have hundreds of them that I just understand how to avoid programming yourself into a corner."

• Conclusion

  • Discusses his books and teaching philosophy, integrating traditional and programming languages for clarity.
  • "I've written several books about this... using programming as the way of expressing the ideas besides the traditional mathematics in addition to you make it unambiguous CL clear and therefore easy to read."

Old School

Back before there were computers there were databases and transactions. Databases were realized as accumulate-only ledgers and transactions were realized with atomically executed contracts.

Datomic’s data and transaction models are highly analogous to these real-world constructs. Datomic accumulates facts (datoms) and, like a ledger, has no addressable places nor semantics for updating thereof.

Datomic’s transactions are like contracts. A contract has a bunch of clauses that, while appearing in order, do not specify a procedure executed in that order. Instead they are a bunch of declarations (of rights, obligations etc) that will all become true together upon execution of the contract (or not at all!), typically by signing of the parties. There is no partial contract along the way - within a contract there is no notion of time or imperative execution, no partial operations on the world etc. Contract execution has no temporal extent - you sign it and it all becomes true.

A contract execution thus identifies a point in time - that point dividing the time before the execution of the contract from the time after, in which the contract (in toto) is in effect. A Datomic transaction does the same.

Obviously, not being a procedure bundling up imperative operations, there is nothing analogous to a traditional DB “stored procedure” in a contract. But Datomic doesn’t offer stored procedures. Instead it has “transaction functions” which, given the state of the db immediately preceding the transaction, calculate values for incorporation within it.

Do contracts have “transaction functions”? Of course they do! Clauses such as “the buyer shall pay the NYSE opening share price on the day of closing + 0.1%” or “the buyer will reimburse the seller for utilities paid for the month of the closing pro-rated by the number of days elapsed as of the closing”, or “the purchaser shall get the contents of the house as of the closing except for the washer/dryer” etc all use a function of the state immediately preceding the moment of execution to calculate values utilized in the contract.

Why do contracts, and Datomic transactions, have such functions? Because they allow you to define transactions that are more flexible as to when they are applied vs contracts/transactions which explicitly supply all values and thus are brittle (and much longer!) and need to be rewritten as the circumstances in which they are to execute change.

That all such clauses/transaction-functions have the immediate past as their (fixed) basis is an essential feature. Having a fixed basis means they can’t be directly composed (i.e. the output of one can’t feed the input of another). In practice that means that there will be only one such clause/function that calculates any particular value, and if it requires compound logic it will be a compound clause, or in the case of a Datomic transaction function, leverage composition in the language (Clojure/Java) in which you write it.

A lot of benefits accrue to Datomic’s “old-school” approach to transactions. I hope the above helps people better understand them.

Rich Hickey https://clojurians.slack.com/archives/C03RZMDSH/p1716049896478429?thread_ts=1716049896.478429&cid=C03RZMDSH

Here is a detailed and concise summary of the article on Clojure's agents and asynchronous actions:

• Nature of Agents in Clojure: Unlike Refs which support coordinated changes, agents in Clojure enable independent and asynchronous updates to individual storage locations. "Agents provide independent, asynchronous change of individual locations."

• Lifetime and Mutation of Agents: Agents are tied to a single mutable location for their entire lifecycle and can only mutate through specific actions. "Agents are bound to a single storage location for their lifetime, and only allow mutation of that location to occur as a result of an action."

• Action Functions: Actions on agents are asynchronous functions or multimethods, allowing polymorphism and an open set of potential actions. "Actions are functions that are asynchronously applied to an Agent’s state and whose return value becomes the Agent’s new state."

• Reactive Agents and State: Agents in Clojure are reactive; they do not operate under an autonomous imperative message loop, and their immutable state is always readily available for reading without blocking or coordination. "Clojure’s Agents are reactive, not autonomous - there is no imperative message loop and no blocking receive."

• Agent Action Dispatch Process: Dispatching an action to an agent involves applying a function and its arguments to the agent's state, with changes being validated and, if valid, updating the agent’s state. "At some point later, in another thread, the return value of fn will become the new state of the Agent."

• Error Handling: Any exceptions within agent actions prevent further nested dispatches, and errors are stored within the agent until they are cleared. "If any exceptions are thrown by an action function, no nested dispatches will occur, and the exception will be cached in the Agent itself."

• Concurrency and Execution Order: Agent actions are managed concurrently in a thread pool, ensuring no more than one action per agent is executed at any time, with actions occurring in the order they were sent. "At any point in time, at most one action for each Agent is being executed."

• Integration with STM and Thread Pool: Agents work in conjunction with Clojure's Software Transactional Memory (STM), holding actions until transactions commit, and operate on non-daemon threads that require explicit shutdown. "Agents are integrated with the STM - any dispatches made in a transaction are held until it commits."

• Practical Example: A practical implementation example demonstrated is the "send-a-message-around-a-ring" test, showing the setup and dispatch mechanism in a real scenario. "This example is an implementation of the send-a-message-around-a-ring test."

Each bullet point has extracted critical information and relevant quoted sentences from the text, providing a comprehensive yet succinct overview of the key concepts related to agents in Clojure.

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."

We want our any element of our system to be cohesive & decoupled with respect to other elements his size.

• Why we split code into files?
• Good way to restrict context?
• We can afford coupling in small contexts but as the context gets large coupling becomes expensive.
• Therefore we might optimize on context size vs coupling?
• Context needs to be defined more precisely

This explanation shows the phenomenon is natural but software design | software engineering it's not necessarily natural, when we engineer something we often bypassing natural courses by precisionly understanding and avoiding their causes.

https://hyp.is/9rUXdtxYEe655jsfCAXzWw/en.wikipedia.org/wiki/Cyclomatic_complexity

https://clojure.org/reference/transients

Distinction Between Prototypal and Classical Inheritance Models: The talk concludes with a discussion on how JavaScript’s inheritance differs from classical models like Java, focusing on how JavaScript uses a prototypal model which is more flexible.

Practical Application of Prototypes in JavaScript: The speaker emphasizes the practicality of prototypes in JavaScript, explaining how modern JavaScript incorporates prototypal inheritance through syntax like Object.create.

Delegation in Object Prototypes: When an object receives a request (message) for a property it lacks, it delegates the request to its prototype. This system allows objects to utilize properties and behaviors of their ancestors

Object Behavior and Communication: Objects in JavaScript communicate through a mechanism where messages are sent and received, with prototypes playing a key role in delegating responses when objects lack certain properties

Prototypal Chain and Differential Inheritance: The process involves creating objects based on a prototype and then customizing new objects, illustrating how inheritance chains work by describing objects in terms of their differences.

Shared Characteristics and Modifications: The speaker discusses how changes to a prototype affect all objects derived from it, using an example of adding features to a chair to demonstrate shared and differential inheritance.

Definition and Function of a Prototype: In computing, a prototype is a model used to create copies (instances) with the same properties. Prototypes in JavaScript are foundational for creating objects that can inherit properties from other objects.

Utility of Prototypal Inheritance: Prototypal inheritance allows for more flexible manipulation of object properties compared to the static nature of physical objects. The speaker uses the analogy of a chair to illustrate copying and modifying objects in computing.

• Clarification of Terminology: The speaker begins by clarifying that "prototypal inheritance" is the correct term, not "prototypical inheritance."

  • "First thing I learned is that this is not called prototypical inheritance, that's something else."

• Utility of Prototypal Inheritance: Prototypal inheritance allows for more flexible manipulation of object properties compared to the static nature of physical objects. The speaker uses the analogy of a chair to illustrate copying and modifying objects in computing.

  • "Did you realize that some things are more convenient with computers like think of the chair that you're sitting on."

• Definition and Function of a Prototype: In computing, a prototype is a model used to create copies (instances) with the same properties. Prototypes in JavaScript are foundational for creating objects that can inherit properties from other objects.

  • "A prototype is your chair, and I want to copy that."

• Shared Characteristics and Modifications: The speaker discusses how changes to a prototype affect all objects derived from it, using an example of adding features to a chair to demonstrate shared and differential inheritance.

  • "If we add a rocker to the prototype, the objects inherit the rock."

• Prototypal Chain and Differential Inheritance: The process involves creating objects based on a prototype and then customizing new objects, illustrating how inheritance chains work by describing objects in terms of their differences.

  • "This really underscores this idea of differential inheritance, my chair is like your chair except..."

• Object Behavior and Communication: Objects in JavaScript communicate through a mechanism where messages are sent and received, with prototypes playing a key role in delegating responses when objects lack certain properties.

  • "Objects aren't just about manipulating static things, objects can do things, and the way to get an object to do something is to send it a message."

• Delegation in Object Prototypes: When an object receives a request (message) for a property it lacks, it delegates the request to its prototype. This system allows objects to utilize properties and behaviors of their ancestors.

  • "If the child gets a message that doesn't know how to respond to it, it can ask its prototype and attach themselves."

• Practical Application of Prototypes in JavaScript: The speaker emphasizes the practicality of prototypes in JavaScript, explaining how modern JavaScript incorporates prototypal inheritance through syntax like Object.create.

  • "What we just saw prototypes with pointers to other objects prototypes chains message passing that sort of thing."

• Distinction Between Prototypal and Classical Inheritance Models: The talk concludes with a discussion on how JavaScript’s inheritance differs from classical models like Java, focusing on how JavaScript uses a prototypal model which is more flexible.

  • "This wasn't necessarily what was invented first in JavaScript, this is very recent actually at least the first part is."

This detailed summary provides a comprehensive overview of the key points made in the talk about prototypal inheritance, illustrating its fundamental concepts and practical implications in JavaScript programming.

Concludes with the implementation phase where the selected approach is detailed out, emphasizing the importance of revisiting and possibly revising strategic decisions based on practical considerations during implementation. "we thought we were going to do this and we didn't find a way to implement so that wasn't going to be too much work."

The use of decision matrices and structured design processes encourages reflective thinking and abstraction, leading to more innovative and effective solutions. "you're starting to do abstraction...if you do this during the day I promise you you're going to get new ideas when you hit the hammock or the bed"

Discusses how a decision matrix helps maintain a clear focus on the problem, facilitates shared understanding, and drives thoughtful examination of each potential solution. "you're going to have shared understanding...you're going to be able to say I don't think you're saying that right."

Advises against subjective judgments within the matrix, recommending the use of color coding to visually represent the evaluation of each criterion. "use colors...to show subjectivity."

Stresses the selection of relevant and salient criteria for evaluating approaches, differentiating between merely describing features and critically analyzing their implications. "you want things that are salient or relevant."

Details on how to set up a decision matrix, emphasizing the importance of clearly defining the problem in cell A1 and using the subsequent columns and rows to evaluate different approaches against defined criteria

Introduces the decision matrix as a critical tool for evaluating different approaches, using a live-editing spreadsheet format to facilitate collaborative design. "what is a decision matrix it's a spreadsheet that more than one person can see at the same time and edit at the same time."

Highlights the process of creating use cases focused solely on user intentions, leaving out the implementation details for later phases. "the best first phase for use cases is to talk about only what people intend to accomplish."

Emphasizes the need to explore different strategies (e.g., automated solutions versus tools for users) to address user objectives more effectively. "you're then going to start thinking about what are the ways that you could possibly address it."

Strategy is defined as determining the direction, focusing on user intentions and potential approaches to meet those intentions without specifying how they will be achieved initially. "strategy means to be a general or to lead and fundamentally it means about where are you going."

The speaker discusses the importance of distinguishing between strategic direction setting and tactical implementation decisions in design, particularly for larger projects

• you're going to be able to modify the top story title to try to make it about the problem
• the other thing you're going to do is you're going to now add another thing to that top story you had the title description now you're going to have that problem statement

Covers the transition from identifying and understanding design problems to formulating solutions, emphasizing the necessity of a clear, succinct problem statement in this process.

Describes the 'top story' as a pivotal part of project management in design, which synthesizes understanding and outlines the plan forward. "you need to have a ticket that says this is what the overarching plan is."

Explains the concept of reflective inquiry where questioning one's own thoughts helps advance understanding in design. "reflective inquiry... helps you think it also helps agendaize your background thinking."

Introduces the Socratic method as a tool for probing and understanding through structured inquiry, which helps uncover underlying truths about design challenges.

Discusses the strategic use of questions to clarify goals and intentions in the design process, promoting a deeper exploration of problems

Recommends creating a glossary to consistently define and use terms, enhancing understanding within teams

Advocates for precise use of language to avoid ambiguity and ensure that design intentions are clearly communicated and understood.

• Be percise about the meaning
  • Builds better understanding (of differences and similarities)
• Keeps everyone on the same page => better collaboration

Stresses the role of writing in design, not for documentation, but as a tool to visualize and refine ideas collaboratively: * Forces us to concrete thoughts * Allow us to not lose threads * Allow us to share our thoughts

Emphasizes that design is not a magical skill but involves concrete, learnable practices that enhance team-based software development.

Transformers give Clojurists some of the benefits of "Object Orientation" without many of the downsides Clojurists dislike about objects.

1. Objects couple behaviors required from multiple callers into a single class, while transformers do not change existing behaviors for existing callers by default
2. Objects push inheritance first design, whereas transformer inheritance is a function of shared structure between Clojure data structures derived from one another and design is driven by concrete implementation needs, like regular Clojure
3. Objects couple state and methods in spaghetti ways and transformers are just immutable maps. And just like how Clojure lets you stash stateful things like atoms in functions, transformers allow you to build stateful transformers, but like Clojure the default convention is to do everything immutably
4. Objects try to provide data hiding as a function of encapsulation whereas transformers are doing the opposite, exposing data otherwise hidden by a closure

There are many strategies for reusing code in the software industry. In Clojure, we use what some call a "lego" method of building small, single purpose functions that just can be used in a million different contexts, because of a tasteful use of simplicity in the right places. This works tremendously well for 95% of use cases. In certain use-cases, like for building hierarchies of functions that are highly self-similar, like with UI toolkits, transformers provide a better alternative.Transformers allow you to build a UI toolkit with 25% the code of normal function composition and 25% of the code required for evolution over time for the widgets in that hierarchy. The lego method is great for vertically composing things together, but when you want to make lateral changes for only certain callers in the tree, you have to defensively copy code between duplicative implementation trees and just call them "grandpa-function-1" and "grandpa-function-2" and then make versions 1 and 2 for all functions that wrapped the grandpa-functions afterwards. Transformers provide a solution for that situation, in the rare cases we end up in them in Clojure, without the downsides of a traditional object system.

• Concise expression of application logic
• Actually being incremental
• Tab focusing
• Simple types
• Simple control flow
• Overall system complexity

Summary of Raph Levien's Blog: "Towards principled reactive UI"

Introduction

• Diversity of Reactive UI Systems: The blog notes the diversity in reactive UI systems primarily sourced from open-source projects. Levien highlights a lack of comprehensive literature but acknowledges existing sources offer insights into better practices. His previous post aimed to organize these diverse patterns.
  • "There is an astonishing diversity of 'literature' on reactive UI systems."

Goals of the Inquiry

• Clarifying Inquiry Goals: Levien sets goals not to review but to guide inquiry into promising avenues of reactive UI in Rust, likening it to mining for rich veins of ore rather than stamp collecting.
  • "I want to do mining, not stamp collecting."

Main Principles Explored

• Observable Objects vs. Future-like Polling: Discusses the importance of how systems manage observable objects or utilize future-like polling for efficient UI updates.
• Tree Mutations: How to express mutation in the render object tree is crucial, focusing on maintaining stable node identities within the tree.
  • "Then I will go into deeper into three principles, which I feel are critically important in any reactive UI framework."

Crochet: A Research Prototype

• Introduction of Crochet: Introduces 'Crochet', a prototype exploring these principles, acknowledging its current limitations and potential for development.
  • "Finally, I will introduce Crochet, a research prototype built for the purpose of exploring these ideas."

Goals for Reactive UI

• Concise Application Logic: Emphasizes the need for concise, clear application logic that drives UI efficiently, with reactive UI allowing declarative state expressions of the view tree.
  • "The main point of a reactive UI architecture is so that the app can express its logic clearly and concisely."
• Incremental Updates: Advocates for incremental updates in UI rendering to avoid performance issues related to full re-renders, highlighting the limitations of systems like imgui and the potential of systems like Conrod, despite its shortcomings.
  • "While imgui can express UI concisely, it cheats somewhat by not being incremental."

Evaluation of Existing Systems

• Comparison with Other Systems: Mentions SwiftUI, imgui, React, and Svelte, discussing their approaches to handling reactive UI and their adaptability to Rust.
  • "SwiftUI has gained considerable attention due to its excellent ergonomics in this regard."

Technical Challenges and Proposals

• Challenges in Tree Mutation and Stable Identity: Discusses the challenges in tree mutation techniques and the importance of stable identity in UI components to preserve user interaction states.
  • "Mutation of the DOM is expressed through a well-specified and reasonably ergonomic, if inefficient, interface."

Conclusion and Future Work

• Future Directions and Experiments: Encourages experimentation with the Crochet prototype and discusses the ongoing development and research in making reactive UIs more efficient and user-friendly.
  • "I encourage people to experiment with the Crochet code."

This blog post encapsulates Levien's ongoing exploration into developing a principled approach to reactive UI in Rust, highlighting the complexity of the task and his experimental prototype, Crochet, as a step towards solving these challenges.

Summary of "Towards Principled Reactive UI" by Raph Levien (September 25, 2020)

• Introduction and Motivation:

  • Levien revisits the topic of reactive UI in Rust, building on his previous work to further explore efficient expression methods in the context of Rust's capabilities and limitations.
  • Discusses the diversity of reactive UI frameworks and the potential for adopting successful concepts from existing systems without needing to create an entirely new framework.
  • "It is not the intent of this post to provide a comprehensive review of the literature" – Indicates a focus on identifying promising techniques rather than exhaustive cataloging.

• Goals for Reactive UI Systems:

  • Emphasizes the need for concise expression of application logic, with references to various frameworks like SwiftUI and imgui that have addressed this in differing ways.
  • Highlights the necessity of incremental updates to UI elements, criticizing some approaches like imgui for not truly being incremental.
  • Discusses challenges such as implementing tab focusing and handling simple types within the UI toolkit, pointing out the difficulties faced by frameworks like Iced in these areas.

• Principles for Building Reactive UI Frameworks:

  • Identifies three critical principles for any reactive UI framework: use of observable objects, expression of mutations in the render object tree, and stable identity of nodes within that tree.
  • Questions the standard use of observable objects due to their complexity and potential inefficiency, especially in a Rust context.
  • Advocates for a system where UI logic can trigger re-computation without requiring detailed context about what changed, potentially borrowing concepts from Rust's async infrastructure.

• Introduction of Crochet Prototype:

  • Introduces Crochet, a research prototype designed to explore and implement the principles discussed.
  • Crochet aims to simplify the reactive UI model by not relying on observables and using a simpler system for tracking UI changes.
  • Discusses potential advantages of Crochet, such as better integration with Rust's async features and a simpler approach to handling UI mutations.

• Comparative Analysis with Other Frameworks:

  • Compares Crochet's approach to other frameworks like Jetpack Compose and imgui, highlighting differences in handling actions from widgets and mutations within the UI tree.
  • Describes Crochet's approach to avoiding recomposition from the root for performance efficiency and its potential impact on the development of reactive UIs in Rust.

• Closing Thoughts and Future Directions:

  • Levien encourages experimentation and feedback on the Crochet prototype to refine and validate the proposed principles.
  • Notes ongoing discussions and contributions from the community that influence the development of Druid and Crochet.

Concluding Insights:

• This blog post represents Levien's ongoing efforts to refine the theoretical foundations and practical implementations of reactive UI frameworks in Rust, highlighting new research directions and the introduction of the Crochet prototype as a platform for further exploration and development.

Summary of the Talk on the Future of Web Frameworks by Ryan Carniado

• Introduction and Background:

  • Ryan Carniado, creator of SolidJS, has extensive experience in web development spanning 25 years, having worked with various technologies including ASP.NET, Rails, and jQuery.
  • SolidJS was started in 2016 and reflects a shift towards new paradigms in web frameworks, particularly in the front-end JavaScript ecosystem.
  • Quote: "I've been doing web development now for like 25 years... it wasn't really until the 2010s that my passion reignited for front-end JavaScript."

• Core Themes and Concepts:

  • Modern front-end development heavily relies on components (e.g., class components, function components, web components) which serve as fundamental building blocks for creating modular and composable applications.
  • Components have runtime implications due to their update models and life cycles, influencing the performance and design of web applications.
  • Traditional component models use either a top-down diffing approach (like virtual DOM) or rely on compilation optimizations to enhance performance.
  • Quote: "Modern front-end development for years has been about components... however, in almost every JavaScript framework components have runtime implications."

• Reactive Programming and Fine-Grained Reactivity:

  • Ryan advocates for a shift towards reactive programming to manage state changes more efficiently. This approach is likened to how spreadsheets work, where changes in input immediately affect outputs without re-execution of all logic.
  • Fine-grained reactivity involves three primitives: signals (atomic atoms), derived state (computeds or memos), and side effects (effects). These primitives help manage state and side effects without heavy reliance on the component architecture or compilation.
  • Quote: "What if the relationship held instead? What if whenever we changed B and C, A also immediately updated? That's basically what reactive programming is."

• Practical Demonstration and Code Examples:

  • Ryan demonstrated the implementation of fine-grained reactivity using SolidJS, showing how state management and updates can be handled more efficiently compared to traditional methods that rely heavily on component re-renders and hooks.
  • The examples provided emphasized how reactive programming can simplify state management and improve performance by only updating components that need to change, reducing unnecessary re-renders.
  • Quote: "The problem is that if any state in this component changes, the whole thing reruns again... what if we didn't? What if components didn't dictate the boundary of our performance?"

• Performance Implications and Advantages:

  • The "reactive advantage" in SolidJS and similar frameworks lies in their ability to run components minimally, avoiding stale closures and excessive dependencies that can degrade performance.
  • Ryan highlighted that in reactive frameworks, component boundaries do not dictate performance; instead, performance optimization is achieved through smarter state management and reactive updates.
  • Quote: "Components run once... state is independent of components. Component boundaries are for your sake, how you want to organize your code, not for performance."

• Future Directions and Framework Evolution:

  • The talk touched on the broader impact of reactive programming and fine-grained reactivity on the evolution of web frameworks. This includes the potential integration with AI and compilers to further optimize performance and developer experience.
  • Ryan suggested that the future of web development might see more frameworks adopting similar reactive principles, possibly leading to a "reactive renaissance" in the industry.
  • Quote: "A revolution is not in the cards, maybe just a reactive Renaissance."

• Q&A and Additional Insights:

  • During the Q&A, Ryan discussed the potential application of SolidJS principles in environments like React Native and native code development, indicating the flexibility and broad applicability of reactive programming principles across different platforms and technologies.
  • Quote: "The custom renderer and stuff is not something you need a virtual DOM to... the reactive tree as it turns out is completely independent."

Summary of "Xilem: An Architecture for UI in Rust" by Raph Levien (May 7, 2022)

• Introduction and Motivation:

  • Levien introduces Xilem as a new UI architecture specifically tailored for Rust, addressing the unique challenges posed by Rust's aversion to shared mutable state.
  • The architecture aims to combine modern reactive and declarative UI paradigms in a way that is idiomatic to Rust, learning from the limitations of previous architectures like Druid and other Rust UI projects.
  • "Rust is an appealing language for building user interfaces for a variety of reasons, especially the promise of delivering both performance and safety" – Explains the motivation behind developing a Rust-specific UI framework.

• Xilem Architecture Overview:

  • Xilem leverages a view tree for declarative UI descriptions, supports incremental updates through diffing, and features an innovative event dispatch system using id paths.
  • Introduces Adapt nodes, an evolution of the lens concept from Druid, allowing for better composition by managing mutable state access between components.
  • "Like most modern UI architectures, Xilem is based on a view tree which is a simple declarative description of the UI" – Describes the core structural concept underpinning Xilem.

• Comparison with Existing Architectures:

  • Levien critiques existing architectures like immediate mode GUI, The Elm Architecture, and React adaptations in Rust, identifying their limitations in the context of Rust's programming model.
  • Highlights the challenges with integrating asynchronous operations and complex state management in existing systems.
  • "Another common architecture is immediate mode GUI, both in a relatively pure form and in a modified form" – Discusses how Xilem addresses deficiencies in these models.

• Innovative Features of Xilem:

  • Xilem's event handling distinguishes itself by not relying on shared mutable state but instead uses a path-based dispatch system to manage state mutations.
  • The architecture supports highly granular change propagation and efficient state management through features like memoization nodes and adaptive state nodes.
  • "The most innovative aspect of Xilem is event dispatching based on an id path, at each stage providing mutable access to app state" – Highlights the unique approach to event handling in Xilem.

• Challenges and Future Directions:

  • Discusses potential areas for further development, including multithreading support, fine-grained change propagation, and integration with dynamic languages through Python bindings.
  • Expresses interest in exploring other domains like text-based user interfaces (TUI) or adapting Xilem principles to web-based environments.
  • "We haven’t yet built up real UI around the new architecture" – Acknowledges that Xilem is still in the conceptual stage and requires practical validation.

Concluding Insights:

• Xilem represents Levien's ongoing efforts to refine UI architecture in Rust, addressing the specific challenges posed by Rust's language features while embracing the principles of modern UI design. This architecture aims to provide a robust foundation for building intuitive, high-performance, and safe user interfaces in Rust, encouraging feedback and experimentation to validate and expand its capabilities.

Summary of "Xilem: an architecture for UI in Rust" from raphlinus.github.io

• Motivation for Xilem: Existing UI architectures in Rust like Druid face limitations due to Rust's avoidance of shared mutable state, making them a poor fit for conventional UI systems. Xilem aims to provide an architecture better suited to Rust's paradigms, inspired by existing works and innovations specific to UI needs.

  • "However, finding a good architecture is challenging... Rust is a poor fit for UI."

• Design Goals and Influence: Xilem seeks to blend modern UI design principles such as reactive and declarative UIs with Rust's emphasis on performance and safety. It draws inspiration from SwiftUI, Flutter, and React.

  • "The goals include expression of modern reactive, declarative UI, in components which easily compose, and a high performance implementation."

• Core Components of Xilem:

  • View Tree and Widget Tree: Utilizes a declarative view tree for UI description, which is diffed against its successive versions to update a more traditional widget tree. This setup helps manage UI state and changes efficiently.
    • "Xilem is based on a view tree which is a simple declarative description of the UI."
  • Incremental Computation: At its core, Xilem incorporates an incremental computation engine that optimizes UI updates and event handling.
    • "Xilem also contains at heart an incremental computation engine with precise change propagation, specialized for UI use."
  • Event Dispatching: Introduces an innovative event dispatching mechanism using 'id paths', allowing mutable access to app state throughout the component hierarchy.
    • "The most innovative aspect of Xilem is event dispatching based on an id path."

• Comparative Analysis:

  • Druid and Immediate Mode GUI: Xilem addresses challenges like static vs dynamic widget hierarchies and complex state management seen in Druid and immediate mode GUIs.
    • "The existing Druid architecture has some nice features, but we consistently see people struggle with common themes."
  • Elm Architecture and React-like Implementations: Discusses the limitations of message dispatch in Elm and the adaptation challenges of React patterns in Rust.
    • "The Elm documentation specifically warns against components, saying, 'actively trying to make components is a recipe for disaster in Elm.'"

• Technical Implementation:

  • Example: Uses a simple counter to demonstrate the declarative construction of UI and event handling within Xilem, showing how the architecture supports mutable access to app state without the typical challenges of Rust.
    • "fn app(count: &mut u32) -> impl View<u32> { ... }"
  • Identity and Event Propagation: Explains the use of stable identities and id paths for event propagation, which is crucial for maintaining state consistency across UI updates.
    • "A specific detail when building the widget tree is assigning a stable identity to each view."

• Future Directions and Integration:

  • Async Integration: Discusses the potential integration of asynchronous operations, which are crucial for responsive UIs.
    • "Async and change propagation for UI have some common features, and the Xilem approach has parallels to Rust’s async ecosystem."
  • Environmental and Threading Considerations: Outlines plans for handling environment settings and multithreading, which could enhance performance and scalability.
    • "Another very advanced topic is the ability to exploit parallelism (multiple threads) to reduce latency of the UI."

The post concludes by acknowledging the conceptual stage of Xilem, inviting feedback, and highlighting its potential application across various UI domains.

Summary of "Towards a Unified Theory of Reactive UI" by Raph Levien (November 22, 2019)

• Overview and Motivation:

  • Levien explores various reactive UI frameworks to develop a cohesive understanding and communicate effective strategies for the Druid UI system.
  • Reactive UI allows UI construction and updates to be more intuitive and less redundant compared to traditional object-oriented approaches.
  • "My own main motivation for exploring reactive UI is primarily because the object-oriented idioms don’t translate well to Rust" – This highlights the shift towards reactive UI due to language and paradigm limitations in Rust concerning ownership and callbacks.

• Theoretical Framework and Tree Transformations:

  • Reactive UIs fundamentally involve transforming UI component trees across various stages: user data → widget tree → render object tree → draw tree.
  • Levien discusses tree representation either as a data structure or as an execution trace, both impacting how UI transformations are managed.
  • "The main theoretical construct is that reactive UI is at heart a pipeline of tree transformations." – This signifies the central role of managing UI component hierarchies through transformations.

• Diversity in Framework Implementations:

  • Despite common goals, implementation details in reactive UI frameworks vary significantly, influencing how application state is managed and updated.
  • Differences are often seen in how these frameworks handle state, incremental updates, and dependency tracking.
  • "The details of implementation still seem wildly divergent." – Points to a lack of standardization in implementing reactive principles across different systems.

• Incremental Transformations and Diffing:

  • Emphasizes the importance of incremental updates in UI frameworks to minimize the performance costs of updating UI states.
  • Discusses strategies like diffing, which involves comparing new and old UI trees to determine necessary updates.
  • "One of the fundamental goals of a UI framework is to keep the deltas flowing down the pipeline small." – Highlights the challenge of efficiently propagating changes through the UI system.

• Push vs. Pull Interfaces in UI Frameworks:

  • The distinction between push and pull interfaces in managing data flow through UI systems is crucial, with many systems using hybrid approaches.
  • "Pulling from a tree basically means calling a function to access that part of the tree." – Describes how data is retrieved or updated in UI components.

• Case Studies and Examples:

  • Provides insights into specific UI frameworks like Druid, Imgui, Flutter, Jetpack Compose, and React, each illustrating unique approaches to tree transformations and state management.
  • These examples highlight the practical applications of theoretical concepts discussed throughout the blog.

• Future Directions and Academic Gaps:

  • Levien seeks further discussion and academic input to refine these theories and potentially translate them into systematic, robust UI development practices.
  • "I’m also curious if there’s good academic literature I’m missing." – Shows an openness to expanding the theoretical underpinnings of reactive UI based on community and academic feedback.

Concluding Thoughts:

• Raph Levien’s exploration into reactive UI frameworks is a deep dive into understanding and characterizing the diverse implementation strategies that exist, aiming to refine and communicate effective methods for building reactive user interfaces, particularly in the context of systems like Druid that utilize Rust’s programming paradigm.

Here is a detailed summary of the article "Super Charging Fine-Grained Reactive Performance" by Milo:

1. Introduction to Reactivity in JavaScript

   • Definition and Importance: "Reactivity allows you to write lazy variables that are efficiently cached and updated, making it easier to write clean and fast code."
   • Introduction to Reactively: "I've been working on a new fine grained reactivity library called Reactively inspired by my work on the SolidJS team."

2. Characteristics of Fine-Grained Reactivity Libraries

   • Library Examples and Usage: "Fine-grained reactivity libraries... Examples include new libraries like Preact Signals, µsignal, and now Reactively, as well as longer-standing libraries like Solid, S.js, and CellX."
   • Functionality and Advantages: "With a library like Reactively, you can easily add lazy variables, caching, and incremental recalculation to your typescript/javascript programs."

3. Core Concepts in Reactively

   • Dependency Graphs: "Reactive libraries work by maintaining a graph of dependencies between reactive elements."
   • Implementation Example: "import { reactive } from '@reactively/core'; const nthUser = reactive(10);"

4. Goals and Features of Reactive Libraries

   • Efficiency and State Consistency: "Efficient: Never overexecute reactive elements... Glitch free: Never allow user code to see intermediate state where only some reactive elements have updated."

5. Comparison Between Lazy and Eager Evaluation

   • Evaluation Strategies: "A lazy library... will first ask B then C to update, then update D after the B and C updates have been completed."
   • Algorithm Challenges: "The first challenge is what we call the diamond problem... The second challenge is the equality check problem."

6. Algorithm Descriptions

   • MobX: "MobX uses a two pass algorithm, with both passes proceeding from A down through its observers... MobX stores a count of the number of parents that need to be updated with each reactive element."
   • Preact Signals: "Preact checks whether the parents of any signal need to be updated before updating that signal... Preact also has two phases, and the first phase 'notifies' down from A."
   • Reactively: "Reactively uses one down phase and one up phase. Instead of version numbers, Reactively uses only graph coloring."

7. Benchmarking Results

   • Performance Observations: "In early experiments with the benchmarking tool, what we've discovered so far is that Reactively is the fastest."
   • Framework Comparisons: "The Solid algorithm performs best on wider graphs... The Preact Signal implementation is fast and very memory efficient."

This summary encapsulates the key concepts, methodologies, and findings presented in the article, focusing on the innovations and performance of various fine-grained reactivity libraries, especially the newly introduced Reactively.

Is Big-Data about storage and joins? Or is it about computing efficiently over massive scales?

Are these two different features? OWL for defining rules? and SPARQL for recursive queries?

SHACL

Here's a detailed summary of Daniel Petronik's talk about Fluree, an immutable graph database with Clojure, and its significance in the context of data sharing across trust boundaries:

• Introduction of Speaker and Topic

• "my name is Daniel Petronik and I work at Fleury where we are making an immutable graph database with closure" - Introduction to the speaker and the subject of the talk.

• Historical Context of Shipping

• "stepping back into a serious problem of shipping boxes in the days of yore" - Petronik starts with a historical analogy to illustrate a complex system of logistics and shipping before modern containerization.

• "it's a very long journey and then you go across the ocean eventually you'll reach your Port of Call" - Description of the arduous process involved in shipping goods before the advent of container ships.

• Introduction of Containerization

• "shipping things isn't that expensive we have containers" - Introduction to containerization as a transformative technology that simplified and reduced the cost of shipping goods globally.

• Parallels to Data Sharing

• "shipping data across trust boundaries is expensive, risky and not worth it for many categories of applications" - Draws a parallel between the old shipping methods and the contemporary challenges in data sharing across organizational and technical boundaries.

• Detailed Problems in Data Sharing

• "every step of the way when somebody touches it you've got to pay for Freight, you've got to pay for labor" - Analogy to the logistical and bureaucratic hurdles in managing data across different systems.

• Introduction to Semantic Web and RDF

• "at the foundation of all these things that they came up with is the resource description framework rdf which is just a notation for graphs" - Introduces RDF as a foundational technology for managing data more effectively.

• Proposal for Simplifying Data Interaction

• "let's simplify the shape of the data and get rid of that application server that special snowflake" - Proposes a simplification of data handling to improve interoperability and reduce complexity.

• Role of Fluree in This Paradigm

• "Flurry right we've we've got a database" - Discusses how Fluree fits into this new paradigm by offering a graph database that incorporates these simplified, standardized approaches to data handling.

• Future Vision and Call to Action

• "this isn't going to cover every use case but just like containers didn't take over everything in order to provide value they took over enough that it made a huge difference" - Reflects on the potential impact of Fluree and similar technologies in changing how data is shared and managed.

This talk emphasizes the need for new methodologies in data management that reduce friction and lower costs, drawing an extended metaphor between the evolution of physical goods shipping and data sharing practices.

Reactivity?

Summary of "So you want to build an ECS-backed GUI framework"

• Introduction to ECS and Bevy for GUI: The authors discuss using the Entity-Component-System (ECS) framework within Rust, specifically Bevy, to build a UI framework. They highlight the unconventional nature of ECS-based GUIs but reference prior implementations like flecs and various Bevy experiments demonstrating the feasibility and potential of this approach.

• "It's a type-safe, trendy solution for state management and most importantly: it'll be blazing fast" and "existing experiments like belly, bevy_lunex, bevy_ui_dsl, cuicui_layout and kayak_ui show a ton of promise using Bevy's ECS."

• Challenges of Developing bevy_ui: The text outlines that the issues with bevy_ui stem not from its ECS or Rust foundations, but rather from the inherent complexity and labor intensity of GUI framework development, which involves numerous components and meticulous coordination.

• "most of the problems that plague bevy_ui aren't driven by the decision to use an ECS, or even to use Rust. They're the boring, tedious and frustrating ones: writing GUI frameworks is a lot of work with many moving parts."

• Authors’ Background and Disclaimer: Alice is a maintainer (not the lead) of Bevy and Rose uses Bevy professionally, indicating their deep involvement but also stressing that their opinions are personal and not official.

• "Alice is a maintainer of Bevy, but not the project lead or even a UI subject-matter-expert. Rose is an employee at the Foresight Spatial Labs."

• Vision for bevy_ui: The post aims to clarify the rationale behind using ECS for GUI, addressing common critiques and misconceptions, and outlining necessary improvements for making bevy_ui competitive and functional.

• "This post aims to record how you might make a GUI framework, why we're using an ECS at all, and what we need to fix to make bevy_ui genuinely good."

• Common Misconceptions and Arguments: The discussion addresses several typical arguments against developing a native Bevy GUI framework, like the feasibility of a single framework satisfying diverse application requirements and the tendency to prefer existing solutions to avoid 'Not Invented Here' syndrome.

• "One GUI framework to rule them all?" and "Bevy should just use an existing GUI framework."

• Technical and Social Reasons for a Bevy-Specific GUI: The authors argue for a Bevy-specific GUI to ensure consistency, ease of maintenance, integration with Bevy’s core features, and avoiding dependency risks which can complicate maintenance and updates.

• "Consistency with the rest of the engine is valuable in its own right. It makes for an easier and more consistent learning experience for new users."

• Implementation Challenges: The article details specific technical challenges involved in building bevy_ui, such as managing a UI tree structure, input collection, text rendering, and integrating with Bevy's system for rendering, state management, and data transfer.

• "Storing a tree of nodes... In bevy_ui, this is stored in the World: each node is an entity with the Node component."

• Strategic Plan for Improvement: The authors propose a mix of straightforward, controversial, and research tasks to progressively refine and enhance bevy_ui. These include enhancing documentation, adopting new layout strategies, creating a styling abstraction, and improving integration with accessibility features.

• "We can split the work to be done into three categories: straightforward, controversial and research."

• Conclusion: The text concludes with optimism about the future of bevy_ui, encouraging the Bevy community to engage in its development to realize its potential fully.

• "But critically, none of it is impossible. If we (the Bevy developer community) can come together and steadily fix these problems, one at a time, we (Alice and Rose) genuinely think bevy_ui will one day live up to the standard for quality, flexibility and ergonomics that we expect out of the rest of the engine."

Here's a detailed and comprehensive summary of the information provided about the Sciter documentation on "Flows and Flexes":

• Sciter's Layout Responsiveness Principles
• Flex Units: Defined as 0.5, 1, 2, or simply , these are used in layout properties such as width, height, margins, paddings, and border-width. "The flex unit (width:1 or just width:) can be applied to pretty much any existing CSS property."

• Flow Property: Manages the layout inside an element, similar to display:flexbox and display:grid in W3C CSS. "The flow property - declaration of layout manager used inside the element."

• Flexible Margins

• Affects horizontal positioning inside a container using left/right flex ratios. Example: "These rules will shift a child horizontally inside a container with left(0.7)/right(0.3) ratio."

• Flexible Dimensions

• Child elements can be set to fill the container's space completely using width: 1 and height: 1. "These rules will instruct a child to fill a container's free inner area in full."

• Flexible Border Spacing

• Distributes spacing evenly among children within a container. "These rules will instruct children to be spread inside a container's with equal spacing."

• Flow Configurations

• Default: Automatically discovers flow based on content.
• Horizontal: Positions children in a single row. "Children are replaced in single row."
• Horizontal-wrap: Arranges children in multiple rows. "Children are replaced in multiple rows, if they do not fit in one row."
• Vertical: Organizes children in a single column. "Children are replaced in single column."
• Vertical-wrap: Similar to horizontal-wrap but for vertical arrangements.
• Stack: Stacks children on top of each other. "Children are replaced on top of one another."
• Grid(): Places elements in a defined grid layout. "The grid flow allows to replace elements as grid cells using 'ascii template'."

• Row(): Similar to grid but organizes content by columns automatically. "The row() flow is a variant of a grid() flow and is different only by method of grid content definition."

• Specific Layout Tips

• Tips for using flex units to fill vertical space, aligning children using vertical-align and horizontal-align, and breaking rows or columns explicitly are provided to optimize layout management.

This summary condenses the critical aspects of the Sciter documentation on CSS flows and flexes, focusing on how these properties can be implemented to manage layout responsiveness effectively.

Here's a structured summary of the article "Why Not Flexbox?" discussing Subform's decision to develop its own layout engine instead of using Flexbox:

• Background on Flexbox and Subform: Initially, Subform used Flexbox post-Kickstarter launch, but user feedback revealed its complexity as a barrier for designers familiar with Photoshop or Sketch. "Flexbox was too difficult to learn."

• Complexity of Flexbox: Flexbox adds new concepts like flex, justify-content, and align-items to existing CSS ideas (margins, padding, etc.), creating a complex, often unintuitive system. "Flexbox introduces new concepts...on top of existing CSS concepts."

• Subform's Layout Engine:

• Simpler Conceptual Model: Designed to be more intuitive with fewer concepts applied more uniformly. "Compared to Flexbox, the Subform layout engine has fewer concepts, applied uniformly."

• Design Choices:

  • Uniform Usage: Utilizes the same units (pixels, percentages, stretch) uniformly across different settings. "Uniform stretch units."
  • Default Settings: Includes 'default between' settings to avoid common CSS issues like margin manipulations. "Default between."
  • Expressiveness: Facilitates more specific spacing configurations between elements. "This approach is far more expressive than Flexbox."

• Learning and Implementation: The article encourages experimentation with Subform's layout engine and provides resources for further learning. "The best way to learn the layout system is to just play around with it."

For further details and in-depth understanding, you can check out the full article here: Why Not Flexbox?

Does this mean, removing children computations from the graph every time the parent re-evaluates?

Solid's design minimizes creation overhead by using efficient data structures for managing subscriptions and avoiding unnecessary memory allocation. "Signals hold the list of subscribers so that they can notify them when they update..."

Balanced Granularity: By reducing the granularity where it pays off the most, such as by diffing a few values for attributes, Solid optimizes performance without sacrificing reactivity. "So what if we only made one for each template to handle all attributes as a mini diff..."

Balanced Granularity: By reducing the granularity where it pays off the most, such as by diffing a few values for attributes, Solid optimizes performance without sacrificing reactivity. "So what if we only made one for each template to handle all attributes as a mini diff..."

• What if we write self adjusting reactivity graph?
• Reactive graph is composed of computations that depend on each other.
• Managing those dependencies has overhead
• The more granular the graph, the more overhead
• At some point the cost at weights the value, there's an optimum to be found here.
• What if we would write this graph by hand?
  • We'll probably write less nodes
  • Things that we know doesn't change won't even be in the graph
  • Things that change frequently together might be clumped together (kinda like neurons)

IMPORTANT * It's better to clump all attributes together and diff at the leaf. * I'm not sure about the insertion

• I think that means: reactivity on orederly reduced lists is hard to granular.

• What does "reconciling lists" means in this context?

• Does the translation happens at compilation (build) time? Or at run time?
• At compilation time we are bound to the syntax (i.e if the compiler is implemented for jsx we can't use it with cljs).
• Also it can't be dynamic (kind of the point of compilation)
• If it happens at runtime, does translation more performant than decision tree?

Efficiency through Simple Algorithms: The story of udomdiff illustrates that sometimes simpler, practical approaches to algorithm design can yield high performance. The library leverages a basic Set lookup combined with common list manipulation techniques, demonstrating efficiency through simplicity. "And guess what it was smaller and about the same performance. Maybe even better."

Performance Plateaus and the DOM's Role: The author begins by discussing how despite various optimizations, web development libraries face performance limitations due to the fundamental constraints of the DOM. "The DOM. Ultimately that is our biggest limitation."

When this is properly partitioned and named it is just a set of rules and properties that compose to express complex behaviors.

Just like physics in real life.

If the systems communicate sequencially using data changes to components of entities (state) it seems like order is of concern. This sounds like manual state propagation, can automatic propagation (reactive, propagator) solve ordering and improve efficiency?

https://www.flecs.dev/flecs/index.html

Semantic type system can be extremely powerful declarative tool

Don't we also need some kind of associative store that associates entities ids to components?

How?

This approach is especially suited game engines which operate of a single attribute of all the entities (i.e the position of all entities, shadow of all entities, etc..) and not the overall attributes of a single entity.

Based on WebGL

• Data ownership:
  • Wallabag has a paid hosted service
  • But the project is open source and self-hosting should be possible

• Collection & Recollection:
  • Looks like wallabag is sensitive to URL variations like memex
    • It will double save a url with hash and without hash
    • This probably will apply to Wikipedia's mobile domain and I won't know if I already saved a page on desktop/mobile

• Annotations
  • Text & Images
• Smart Bookmarking
  • Full-text search
  • Automated Tagging

Does mymind support integrations? I would like to automatically export entries to logseq/obsidian.

Does it have to be that way? Can't we optimize production process without compromising quality?

I believe fine engineering can enhance both.

I don't see anything inherent in mass production that must contradict quality.

It might be that one of the easy ways for mass production is compromising quality, but it's like any other problem: resources (time, effort, ingredients...) and quality can always be tradedoff.

Does it have to be that way? Can't we optimize production process without compromising quality?

I believe fine engineering can enhance both.

I don't see anything inherent in mass production that must contradict quality.

It might be that one of the easy ways for mass production is compromising quality, but it's like any other problem: time and quality can always be tradedoff.

Does it have to be that way? Can't we optimize production process without compromising quality?

I believe fine engineering can enhance both.

I don't see anything inherent in mass production that must contradict quality.

It might be that one of the easy ways for mass production is compromising quality, but it's like any other problem: time and quality can always be tradedoff.

How?