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 and a system that uses intern. 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 it was interned in- just interactively type that-package::that-interned-symbol-name, and also the interned symbols can be usefully split further into interned symbols in a package which have been exported from that package. This gives a view of the complex, non-orthogonal symbol/intern/package/export 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 - packages. 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, and Barlow’s included uiop:define-package.

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 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 as always).

Underlying this is what my friend mdhughes 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, we heard a bit of the history of Kent’s work at Harlequin Inc rendering html to postscript (i.e. a print-ready format), and his subsequent plugging of the html rendering system into CLIM 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 helper and Eduardo’s eev mode 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.

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)))

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 *)

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

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

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

«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. What do you think about drawing graphs like this?

Sorry about the “fallow week” everyone.