2022-07-29

* John Bywater:

The term ‘pattern language’ was coined by Christopher Alexander. Alexander’s book *The Timeless Way of Building* presents pattern language as a scheme for describing events [→Event (Ereignis)]. Each pattern language is concerned with a particular domain. For example, *A Pattern Language for Towns and Buildings* is concerned with the built environment. > As we shall see, the timeless way is found by describing and becoming familiar with the recurring events that give living character to a world. A pattern language can help us to develop our feelings for its domain of concern, so that we may become receptive to what is real in that domain, and so that any designs we may introduce positively contribute to sustaining those events.

* Olaf Brugman:

A pattern language is a method of describing good design practices or patterns of useful organization within a field of expertise. The term was coined by architect Christopher Alexander and popularized by his 1977 book A Pattern Language - wikipedia

* Kavita Tanna:

The deep shared logic points to unrealized potential, with expanded capability...

~

strict digraph {rankdir=LR node [style=filled fillcolor=lightyellow penwidth=3 color=black fontname="Helvetica"] "2022-07-29" node [style=filled fillcolor=lightblue] node [style=filled fillcolor=white penwidth=3 color=black] "2022-07-29" -> "Pattern Language" "2022-07-29" -> "John Bywater" "2022-07-29" -> "Events" "2022-07-29" -> "Event (Ereignis)" "2022-07-29" -> "Kavita Tanna" "2022-07-29" -> "System Change" "2022-07-29" -> "Reflectable Capabilities" "2022-07-29" -> "Reflection" node [style=filled fillcolor=white penwidth=1 color=black] "Pattern Language" node [style=filled fillcolor=white penwidth=1 color=black] "John Bywater" "John Bywater" -> "Events in Software" "John Bywater" -> "Running a Progam" "John Bywater" -> "What Is an Object?" "John Bywater" -> "Event Sourcing" node [style=filled fillcolor=white penwidth=1 color=black] "Events" "Events" -> "Event (Ereignis)" node [style=filled fillcolor=white penwidth=1 color=black] "Event (Ereignis)" "Event (Ereignis)" -> "autopoiesis" "Event (Ereignis)" -> "structures" "Event (Ereignis)" -> "expectations" "Event (Ereignis)" -> "complexity" "Event (Ereignis)" -> "Interpenetration and Structural Coupling" "Event (Ereignis)" -> "System Change" "Event (Ereignis)" -> "self-reference" "Event (Ereignis)" -> "Time" "Event (Ereignis)" -> "Unlocking Luhmann" node [style=filled fillcolor=white penwidth=1 color=black] "Kavita Tanna" node [style=filled fillcolor=white penwidth=1 color=black] "System Change" "System Change" -> "Event (Ereignis)" "System Change" -> "self-reference" "System Change" -> "structures" "System Change" -> "expectations" "System Change" -> "Expectations (Erwartungen)" "System Change" -> "Time" "System Change" -> "Time" "System Change" -> "Unlocking Luhmann" "System Change" -> "Re-Entry" "System Change" -> "Asymmetrization (Asymmetrisierung)" node [style=filled fillcolor=white penwidth=1 color=black] "Reflectable Capabilities" "Reflectable Capabilities" -> "Erik Ernst" "Reflectable Capabilities" -> "Reflection" node [style=filled fillcolor=white penwidth=1 color=black] "Reflection" node [style="filled,rounded,dotted" fillcolor=white] edge [style=dotted] "2022-07-29" "Ralf Barkow" -> "2022-07-29"}

* Christopher Alexander's Pursuit of Living Structure in Cities. post (29 March, 2022)

~

> The last decade has shown that object-oriented technology alone is not enough to cope with the rapidly changing requirements of present-day applications. Typically, objectoriented methods do not lead to designs that make a clear separation between computational and compositional aspects. Component-based systems, on the other hand, achieve flexibility by clearly separating the stable parts of systems (i.e. the components) from the specification of their composition. Components are black-box entities that encapsulate services behind well-defined interfaces. The essential point is that components are not used in isolation, but according to a software architecture which determines the interfaces that components may have and the rules governing their composition. A component, therefore, cannot be separated from a component framework. Naturally, it is not enough to have components and frameworks, but one needs a way to plug components together. However, one of the main problems with existing languages and systems is that there is no generally accepted definition of how components can be composed. In this thesis, we argue that the flexibility and adaptability needed for component-based applications to cope with changing requirements can be substantially enhanced if we do not only think in terms of components, but also in terms of architectures, scripts, and glue. Therefore, we present a conceptual framework for componentbased software development incorporating the notions of components and frameworks, software architectures, glue, as well as scripting and coordination, which allows for an algebraic view of software composition.

~

> In simple terms, there is a fundamental conflict between inheritance and subtyping of object types […]

~

YOUTUBE vhTZYrWe4Xo The Design of Computation — William Bricken

> 0:31 we're trying to get a computer to understand Spencer Brown

The presentation can be downloaded at iconicmath.com , pdf > Software designers and programmers specialize in construction from nothing. My contribution to the conference describes the work that Dick Shoup, Jeffrey James and I did over fifteen years between 1981 and 2006 to implement the algebra of Laws of Form, both in software and in hardware. * Re: trade secrecy, cf. Dan Levine (2010) *Paul Allen's firm sues Silicon Valley giants*. post * James Algebra * Containment * The Principle of Void-Equivalence

~