---
layout: ../Site.layout.js
---
# Complex Systems and lisp - a graph starting journey
- - «.Orthogonality and complexity»	(to "Orthogonality and complexity")
- - «.The complexity crisis of initial creation»	(to "The complexity crisis of initial creation")
- - «.software example from Kent Pitman»	(to "software example from Kent Pitman")
- - «.My system complex»	(to "My system complex")
- - - «.OS → emacs → eev»	(to "OS → emacs → eev")
- - - «.eev → ecl slime → McCLIM»	(to "eev → ecl slime → McCLIM")
- - - «.eev → screwlisps-knowledge/cons-grapher»	(to "eev → screwlisps-knowledge/cons-grapher")
- «.Conclusions»	(to "Conclusions")
- «.fin»	(to "fin")


I am constantly thinking about Winograd's 1972 call for complex systems architects to follow his SHRDLU approach, in terms of that his human contribution was to create the most vast, intricate and boggling system he was just barely humanly capable of in contrast to good-business-advice cheap-shot software strategies. As you may know. I am not saying that I think SHRDLU in 1972 is the most significant language software ever written, though it bears study. It was Winograd's approach to contribute maximally-straining-his-personal-human-limits complexity capability into his program, as a particular exemplar for lisp community software architecture.

Tempermentally also, I think that I personally am not very good at picking low hanging fruit.

## «Orthogonality and complexity»  (to ".Orthogonality and complexity")

In the first place, orthogonality and complexity are opposites. What affect does this have on this other complexity? None / `O(1)`.

However this is also the basis for complex systems- orthogonality is the statement that this axis never leaks complexity into this axis. Consider a lisp system that uses [`make-symbol`](http://www.lispworks.com/reference/HyperSpec/Body/f_mk_sym.htm) and a system that uses [`intern`](https://www.lispworks.com/documentation/HyperSpec/Body/f_intern.htm). In so many words, `make-symbol` just makes a symbol, whereas intern registers the maybe-new symbol in a package. `make-symbol` is orthogonal to the package it is being used in, whereas `intern` "leaks complexity" into the package - you are potentially intern-bombing yourself (attempting to register a huge number of symbols with a package). In this sense, `make-symbol` does not require you to actively be aware of your potential for `intern`-bombing yourself. On the other hand, `intern` makes it easy to reach for a symbol by picking it out of the [`package`](https://www.lispworks.com/documentation/HyperSpec/Body/11_aa.htm) it was `intern`ed in- just interactively type `that-package::that-interned-symbol-name`, and also the `intern`ed symbols can be usefully split further into `intern`ed symbols in a package which have been `export`ed from that `package`. This gives a view of the complex, non-orthogonal [`symbol`](https://www.lispworks.com/documentation/HyperSpec/Body/t_symbol.htm)/`intern`/`package`/[`export`](https://www.lispworks.com/documentation/HyperSpec/Body/f_export.htm) system and the orthogonal `make-symbol`.

## «The complexity crisis of initial creation»  (to ".The complexity crisis of initial creation")

In the last example, it might seem that `make-symbol` is better than `intern` due to its orthogonality to - i.e. not leaking complexity into - `package`s. However, `make-symbol` is basically less useful interactively than `intern` and friends. In fact, lisp's `intern` etc over time have been the basis of Faré's ubiquitous substandard [`asdf`](https://github.com/fare/asdf/blob/master/doc/best_practices.md), and Barlow's included [`uiop:define-package`](https://asdf.common-lisp.dev/uiop.html#UIOP_002fPACKAGE).

However, one still gets the feeling that one is definitely *a user* of the ASDF system seperately to one being a lisp programmer. Furthermore, we all have the experience with non-lisp programmers - they express an interest in adding lisp to their personal repertoire - and then, they suddenly need to learn what, at least ASDF and either emacs or otherwise enough of emacs to understand lisp software reactions to emacs, and this is sufficient to chase off a reasonable cadre.

This being said, [the lisp curse](http://www.winestockwebdesign.com/Essays/Lisp_Curse.html) is infamous- relative to later languages, it has been seen that single lisp developers can and do write Winogradian bogglingly complex - *and great* - software systems that are, like Winograd's example, simply the most phenomenally complicated thing they are capable of *by themselves* and it is attested by the lisp curse, *specifically* by themselves (though something like minor martial arts traditions emerge to hand particular great arts onto a chosen apprentice in the next generation happens - consider [cl-series](https://gitlab.common-lisp.net/rtoy/cl-series/\-/wikis/Series-User's-Guide) as always).

Underlying this is what my friend [mdhughes](https://mdhughes.tech) always says -

> Other people's code is the devil

Basically that becoming a *user* is making a deal with the devil. However, we can consider the extreme success of ASDF/UIOP/cl-series subsystems above. (And emacs.).

## «software example from Kent Pitman»  (to ".software example from Kent Pitman")

In [this episode graced by Kent M. Pitman](/show/kmp-lisp-web-testing/), we heard a bit of the history of Kent's work at [Harlequin Inc](http://lispworks.com/) rendering html to postscript (i.e. a print-ready format), and his subsequent plugging of the html rendering system into [CLIM](https://www.lispworks.com/documentation/lw80/clim/clim.htm) and adding html anchors to realise a lisp web browser (new complex system) at the time.

## «My system complex»  (to ".My system complex")

I am kind of hurting for some of my softwares to finally come together. This section is a beginning of my attempt to bring most of my threads together into a fabric. I am adopting my own [trivial CLIM graph formatting](https://www.lispworks.com/documentation/lwu41/climuser/GUID_286.HTM#HEADING286-0) helper and [Eduardo's eev mode](https://anggtwu.net/#eev) as my systems for this part of this journey. I am here defining A⮕B to mean *B is directly used from A*. For *A⮕B⮕C*, C would be said *not to be directly used from A*. The graph is permitted to be complex. [Note, the meaning of the arrows changes later.]

### «OS → emacs → eev»  (to ".OS → emacs → eev")

This graph is somewhat special because it is prior to emacs being started, (and my emacs starts into eev-mode). So one might invoke `emacs` or `emacsclient -c -a ""` in their operating system's `shell`.

```
emacs
M-x eev-beginner
```
(hypothetically).

### «eev → ecl slime → McCLIM»  (to ".eev → ecl slime → McCLIM")

eev lets me alternate controlling emacs (red star lines, which are emacs lisp) and eepitching lines to programs/buffers run inside emacs. One can imagine 'doing this manually' in a shell or another editor.

```
#|
 (setq inferior-lisp-program "ecl")
 (slime)
 (setq eepitch-buffer-name "*slime-repl ECL*")
|#
'test
#|
 (find-quicklisp-links "mcclim")
|#
;; Oh that utility is really handy, Eduardo.
;; F8-ing that will help you get and load McCLIM.
;; If you need particular help el em kay on the mastodon.
(asdf:load-system :mcclim)
(in-package :clim-user)
```

I don't consider `asdf:load-system` to be 'using asdf' here per se (quicklisp neither), since these functions are just to load systems that *were* made using asdf and [quicklisp](https://quicklisp.org).

Incidentally, Eduardo is working on direct ASDF support from eev-mode as well as the above quicklisp support.

### «eev → screwlisps-knowledge/cons-grapher»  (to ".eev → screwlisps-knowledge/cons-grapher")

```
#|
 (eepitch-shell)
mkdir -p ~/gits
cd ~/gits
git clone https://codeberg.org/tfw/screwlisps-knowledge.git
mkdir -p ~/common-lisp
cd ~/common-lisp
ln -s ~/gits/screwlisps-knowledge
 (eepitch-kill)
 (setq eepitch-buffer-name "*slime-repl ECL*")
|#
'foo
(asdf:load-system :screwlisps-knowledge/cons-grapher) ; register system packages and retry?
(use-package :screwlisps-knowledge/cons-grapher)
(visualize '(a (b (c))) '(d (c)))
```

<img src="../screwlisp-visualize-test.png">

Okay it looks like we are getting into business.

```
(defvar *system-interactions* (list))
(setq *system-interactions* (list))
(push '(OS (emacs (eev))) *system-interactions*)
*system-interactions*
(apply 'visualize *)
```

<img src="../os-emacs-eev.png">

```
'(eev (slime (mcclim (clim-user))))
(push * *system-interactions*)
(apply 'visualize *)
```

<img src="../eev-slime-mcclim.png">

```
'(screwlisps-knowledge (cons-grapher (clim-user)))
(push * *system-interactions*)
*system-interactions*
(apply 'visualize *)
```

<img src="../screwlisp-cons-clim.png">

Ah, the arrows seem to best mean- A→B meaning "A is directly prior to B" rather than "B is used from A" as I had initially thought. `clim-user`'s status as the changing absorbs-user-interactions package needs a more clear statement.

# «Conclusions»  (to ".Conclusions")

In the context of reasoning and about complex systems, we started using CLIM 2 spec's graphing utility via the McCLIM implementation to sketch how systems relate directly to each other. The way it seemed to work in practice was slightly different to how I had initially imagined it would. It's nice to piece-meal construct and visually pop up windows of a graph as part of a writing session in emacs. eev in particular is an excellent way of using emacs.

Metacircularly graphing our calling of the grapher is somehow particularly satisfying.

I might change the graph's orientation to left-to-right instead of up-to-down (it's a keyword choice) to better accomodate crowds of short graphs on an up-down scrolling page.

I have quite a few thoughts about these graphs. I think orthogonality might be the same thing as having very short direct-dependency graphs, so a complex system of orthogonal components would be a crowd of short direct dependency graphs. Three more key thoughts about these graphs as such is that the graphs are close to being literal HTML trees, which is also close to literally being a [kitten](https://kitten.small-web.org) component, while also literally being a common clim spec LISP cons tree to graph. The other thing that is close to this html would be the OWL stuff that shizamura keeps promising to do a segment on on the show (while sleeping).

Another view of sketching systems is [Sacha's literal sketching of systems](https://sketches.sachachua.com/).

# «fin»  (to ".fin")

See you tomorrow for the lispy gopher climate featuring writer, gopher, onieric monk and host of the Evolution Revolution and many great (and small) works `gopher://sdf.org/1/users/gef`, exploring using emacs for their writing. We expect to have Edrx also joining us live via #Emacsconf on the liberachat IRC.

[Mastodon thread for this article](https://gamerplus.org/@screwlisp/114735785560268601). What do you think about drawing graphs like this?

Sorry about the "fallow week" everyone.