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:








Thursday, April 28, 2022

Linda Meets Unix

Notes on "Linda Meets Unix",  Wm Leler, IEEE Computer, February 1990

This article is behind a paywall. I have a copy but cannot share it publicly. I'll provide some notes here and link to open access articles that fill in some of the details. I can dig in deeper if you leave a note in the comments.

Some people may know Wm from his PhD research on implementing constraints in the Bertrand programming language. (Published as "Constraint Programming Languages: Their Specification and Generation", Addison-Wesley, 1988) Wm later worked a couple miles down the street from me at Tektronix. More recently he worked on Flutter and Dart at Google. Now he's somewhere between Portland and the Puget Sound area. https://leler.com/wm/

When Wm authored this article he was at a Portland startup called Cogent Research. The product was a Transputer-based network of workstations. See more about the hardware. The article "Linda Meets Unix" describes the operating system, especially the use of "Kernel Linda" which is a pared-down implementation of Linda and tuple spaces. The aim of Kernel Linda is to be applicable to systems programming.

The article describes shared-memory multiprocessing, message-passing multiprocessing, and the Linda coordination model which is considered "generative" and can be used to approximate either shared-memory or message-passing, as well as a range of coordination patterns.

The operating system described in this article is QIX ("quicks").

To the user, QIX appears almost identical to Unix but, below the surface, it is considerably different. In terms of existing versions of Unix, QIX is most like Mach, except that Mach is based on a message-passing model, while QIX uses Kernel Linda. Like Mach, QIX has a small operating system kernel that is replicated on each processor.

Each process in QIX has a tuple space that provides the "global" environment for that process. That tuple space is the only means of communication between the process and the rest of the system. A QIX process can be lightweight with few entries in the environment tuple space. A Unix-compatible process has a more complete Unix environment in its tuple space.

All processes communicate by reading a "Services" entry from the tuple space. The value is another tuple space of all the external services available to that process. For example:

  • File: the file system
  • Pipe: Unix pipe service
  • TTY: serial ports
  • Execute: the execution service
  • Console: the system error console
  • PIX: the parallel interactive executive
  • Graphics: the graphics server
  • Window: terminal emulator windows
  • FTP: file transfer service
  • Tape: file backup
  • Null: the null device (like/dev/null)
A QIX process can communicate with services directly using Linda operations. Unix-compatible system calls are implemented using these Linda operations since those operations are the lowest-level means for a process to communicate with the rest of the system. One advantage of the indirection and generative nature of Linda is that services can be customized, replicated, and distributed without affecting the behavior of the communication.

Tuple spaces form a name-space of sorts on a per-process basis. This has some similarities with the Plan 9 OS "everything is a customizable file system" philosophy.

The following code creates a new process from a code block on disk and communicates with that process using an environment tuple space that consists of just two keys ("x" and "y"). The result of the process is brought back into the original process via a third key ("z") the tuple space. The original process waits for the result via the Linda blocking operation called "in".

// the new environment dictionary
Val new_env = createdict();

// the value of x is the integer 5
new_env.out("x", (Val) 5);

// the value of y is the integer 20
new_env.out("y", (Val) 20);

// read the executable file from disk
Val proc = createblockfromfile("foo");

// create a new process
int pid = new_env.execute(proc);

// collect results
Val result;

// read the value of z
new_env.in("z", result);
printf("z = %d", (int) result);

 The code for corresponding communication in the new process:

void main()
{
  // access my environment
  Val env = environment(); 
  Val x, y;
  // read the value of x and y
  env.rd("x", x);
  env.rd("y", y); 
  int z = (int) x + (int) y;
  // set the value of z
  env.out("z", (Val) z);
}

The article goes on to illustrate the use of Linda to implement flow control, dynamic load balancing, and server farms. One of the most interesting aspects of QIX is PIX, a parallel, interactive Postscript interpreter implementing the Sun NeWS window system

The original implementation of NeWS implements "green threads" and coordination within the Unix process applies a combination of shared memory with mutexes and message passing. PIX is a true parallel program with coordination using Linda operations. 

QIX provides a big lesson for today by illustrating how an innovative substrate can be used to provide an all new operating environment while maintaining a significant level of compatibility with the current world.

Wednesday, April 27, 2022

Eva: An Event Driven Framework For Building User Interfaces In Smalltalk

 Notes on "Eva: An Event Driven Framework For Building User Interfaces In Smalltalk", Jeff McAffer and Dave Thomas, November, 1987.

This is an interesting assessment of Smalltalk user interfaces in the mid-1980s. Beyond that assessment is the design for a new user interface framework for Smalltalk. The framework is compared to Sun's NeWS and suggests Eva is better than NeWS in some ways.

The main similarities of Eva and NeWS are:

  1. Event-based
  2. Multiple active views
  3. Lightweight processes
  4. Portable interpretive language
  5. Reactive interaction with distributed applications
The main differences attributed to Smalltalk are:
  1. Smalltalk development environment
  2. Richer class library
  3. Better runtime garbage collector
  4. Better runtime performance
The advantage of these are to support more complex application user interfaces, for example CAD applications.

A prototype of Eva was developed in their Smalltalk/v system which ran in 600k. That Smalltalk was not truly multi-processing. The ultimate target for Eva was their Actra implementation of Smalltalk with "actors" providing true multi-processing. Subsequent work on their SmallScript system implemented the Postscript imaging model.