Tuesday, August 9, 2022

On Go's Interfaces and Generics

Go Interfaces: Calling Site Polymorphism

The signatures remain constant, the bodies of methods vary.
  1. A Go interface defines a set of method signatures
  2. Any type that defines that full complement of methods is said to implement that interface.
  3. Variables of that interface type provides a level of indirection to values of types that implement that interface.
  4. Callers use these variables for dispatching an interface method to the corresponding method of underlying value.
The benefit of a Go interface is calling site polymorphism. The same call site can invoke the methods of any type implementing the interface. The benefits allow the calling site to use less code and require less maintenance over time.

Go Generics: Called Site Polymorphism

The signatures vary, the bodies of functions remain constant.
  1. A Go function body may be parameterized by one or more type parameters ("generics").
  2. A generic function may be instantiated with corresponding types that satisfy the constraints of the type parameters.
  3. The result is a non-generic function for the specific types using the body of the generic function.
  4. Multiple instantiations with differing sets of types result in multiple non-generic functions with the same body.
The benefit of Go generics is called site polymorphism. The same called site (function definition) can be instantiated by any types satisfying the type constraints. The benefits allow the called site to use less code and require less maintenance over time.

Conclusion

Calling site polymorphism and called site polymorphism serve distinct purposes. One does not replace the other in whole or in part.

Thursday, June 9, 2022

GNU Mes - Maxwell's Equations of Software, cf. Alan Kay

Just found out about this GNU Mes (stands for Maxwell's Equations of Software, cf. Alan Kay)

https://nlnet.nl/project/GNUMes/

Mes is a small Scheme interpreter with a small C compiler written in Scheme. It's used to bootstrap GUIX from a very small binary.

https://www.gnu.org/software/mes/

Reminder to myself to focus on people doing the interesting work in the nooks and crannies of the industry. 

Diligence is difficult...

To be honest, the elegance displayed above that we achieved at the very start of the Mes project is currently hard to find.

Friday, May 13, 2022

Open Implementation and Flexibility in CSCW Toolkits: Well Beyond Local-First

"Open Implementation and Flexibility in CSCW Toolkits", Paul Dourish, PhD thesis, University College London, 1996. (pdf) Beyond CSCW this thesis is interesting generally for contributions to distributed systems and to open implementation software architectures.

The term Computer Supported Cooperative Work (CSCW) was coined in the early 1980s. "The use of computer-based tools to enhance and facilitate the performance of collaborative work, potentially distributed in space or time"

The ACM conferences continue to this day. CSCW is interdisciplinary and has branched out to sub-disciplines such as workflow and business process automation.

Anthropologists and sociologists observe that collaborative work...

...is improvised moment-to-moment, according to the particulars of the situation. The sequential structure of behavior is locally organized, and is situated in the context of particular settings and times.

They note...

...the distinctions between the formal processes and procedures which are often encoded in CSCW systems and the informal, flexible and opportunistic practices by which work and interaction actually take place. The flexibility required of systems to support the development of these working practices is, then, a key feature of their design.

Dourish highlights the interdependence between top-down sociological flexibility and bottom-up technical systems flexibility.

In general, the detail of collaborative activity, as explored by the ethnomethodological perspective, is rooted in the detail of the technology available, whether that technology is comprised of everyday physical artifacts or computational ones.

...far from being completely independent concerns, the issues of infrastructure flexibility and usage flexibility are closely related. 

 This thesis provides "a cross-cutting view of flexibility":

  1. The evidence of empirical and naturalistic studies of cooperative work demonstrates that usage issues and system issues are fundamentally linked. 
  2. The re-evaluation of abstraction in software engineering, set out by research in Open Implementation, applies to these issues as encountered in CSCW. 
  3. OI/reflective principles can be used to design a novel CSCW toolkit. 
  4. A toolkit built along these lines yields significant improvements in design (and hence, usage) flexibility.

 "Collaboration transparency", e.g. allowing single-user applications to be shared, is distinguished from "collaboration awareness", possibly via multiple modes of operation in the same application. Dourish expands on the need for both but his primary concern is collaboration awareness.

The second chapter of the thesis provides a useful overview of a handful of CSCW applications of the 1980s and early 1990s, including how each provides flexibility. The chapter explores in-depth genericity, extensibility, revision, and flexibility in structure and semantics.

The majority of the thesis explores open implementation, computational reflection, and meta-object protocols in support of synchrony and divergence flexibility in the Prospero toolkit for Computer Supported Cooperative Work. Studying this thesis is worthwhile for people interested in open implementation architectures generally and CSCW in particular.


 

Friday, May 6, 2022

Pat Benatar and Harry Chapin's "Shooting Star"

This is from a 1987 concert tribute to Harry Chapin. Harry Chapin was a master story teller in song. Pat Benatar knows how to deliver a great song, especially Chapin's "Shooting Star".

Wednesday, May 4, 2022

Feed Reader or Read Feeder

 What are your favorite feed reader features from today, yesteryear, or the future?

Sunday, May 1, 2022

SAIL and MAINSAIL - the Stanford Artificial Intelligence Language

Bob Sproull may be most widely known as one of the authors of Newman and Sproull's "Principles of Interactive Computer Graphics". Sproull was also one of the designers of the Alto personal computer, the first laser printer, and one of the first page description languages.

Another of Sproull's designs (1970, with Dan Swinehart and subsequently others) is the programming language SAIL, the Stanford Artificial Intelligence Language. SAIL is based on Algol-60 along with features supporting symbolic AI programming:

  • Records (named product types, i.e. "structs")
  • Garbage collection
  • Associative memory of triples
  • Backtracking (search)
  • Processes and coroutines
An associative memory of triples is essentially a "knowledge graph" of logical relationships similar to RDF's triples. SAIL's combination of associative memory, records, and backtracking could be found in Lisp systems of the day as well as Prolog which was emerging at that time. These evolved into various knowledge representation systems which had their heyday in the 1980s and the "semantic web".

Knuth wrote an early implementation of TeX using SAIL. Larry Tesler wrote PUB, a scriptable markup language using SAIL.

SAIL was machine-dependent and not portable. MAINSAIL (Machine Independent Stanford AI Language) descended from SAIL. MAINSAIL dropped the associative memory and backtracking but retained records, garbage collection, and coroutines. MAINSAIL was commercialized in 1980 and made a pretty good mark in the Computer Aided Design industry.

Garbage collected languages were still rare across all industries until Java came along 15 years later. Associative memory made a valiant comeback with JavaSpaces but Sun's myopic battle with Microsoft focused on J2EE and missed the jewel they had in JavaSpaces. Knowledge graphs are becoming much more commonplace and are beginning to be seen as valuable again at the personal and team level.

More about SAIL: