Naming and Binding from the Inside and Out

Naming and Binding was an important chapter in the course notes for 6.033, Systems Engineering that was part of the core computer science curriculum at MIT in the late seventies. At this point, a foundation in computer languages and their use of names is familiar, but now in the systems context we have  more data structures, file systems and databases and the applications and other tools that are all connected together. In those days and still, the glue that connected it all was the command line, in UNIX world what we call the shell. The jobs of the shell is to start other programs and all of this takes place in the data naming space of the file system. Present a name in the right syntax, and the file system semantics turn that into a bit of content, a file. As stated, the shell doesn't do much except start other programs, and those programs each have two main data spaces, external ones as file systems, data streams from other programs, networked resources, databases or any other other system, and the internal ones, the program memory. High level languages mediate between machine locations and language objects as well as managing other object properties such as persistance and scope. The details are beyond the purpose of this text, the important structural properties are all related to how names are used in programming and the operations of the systems used to both develop and deploy the systems.

For technical and non-technical people alike, we interface with the human engineered interfaces through natural language names, but for all digital systems, the names are formalized and restricted to artificial languages with a precise formal specification. Natural languages are not formal systems in spite of what some analytic philosophers might claim. This diffence between the formal and the natural system is a deep one and at the center of the controversy between scientism [ref to G.Harmon ... Materialism must be destroyed] and a naturalism that is open to the living spirit of Gaia [ref Latour and World/Globe vs. Gaia, etc.]. With more advanced systems development techniques, machine learning at its best and more, we can blur this gap and deliver artificial (augmented, better) systems that support natural language programming and systems operations. Just like with GUI interfaces, the guts of how it operates will be formal and exact and not fuzzy at all. We want to know where the decision making agency is and we want human beings to be responsible until the artificial agents have proved loyal and reliable. Like Dr. Who's K9, loyal and resourceful to the end. Azimov's rules of robotics [ref I Robot] produce a number of morality tales, but would artificial agents actually be built that way? How can you tell Data from Lore [ref STNG]?

The use of names in digital social media need to be more like natural language, but they are coded and can bear semantic marks to aid interpretation. As we have with @ name and # topic signs in tweets as well as the link shortening that formats web links for the channel. The last case is one where the human mode is actually suppressed to fit the medium [ref McCluan media is the message]. Call your attention to what is named and what is bound and how and where this occures. File names are the province of the operating system (OS), and program object names the province of the languages and programs that code the applications. The programs must conform to the specifications of the external systems and pass data objects to the OS that name the external objects within the complex nested external domains. As applications and systems get more advances, more and more of the low level name syntax is hidden from the users. This is as it should be, this is good design that presents the users with the most natural interface for them, natural language. Needing to do smart phone sign language to access devices is likely to become a thing of the past very soon.

Every data and content platform and system will have complicated formal limitations on their interfaces, this is essential for the systems engineers and developers to do their work well and to automate more of it for reliability and to eliminate intellectual grunt work where we can. The complex problem with coordinating all the formality with flexibility and ease is the metaphoric Tower of Babel problem. The ultimate system if frustrated by the crush of too many different languages. In the world of formal languages, however, this problem should be solvable. Standards bodies and informal collaborations have converged upon some very general formal standards that can be evolved if anything was missed. The space of character standards went from the conflict of ASCII vs. EBCDIC wars. I bet there are a few EBCDIC systems, but now the standard is UUcoding that has all the characters every thought of [ref character def resource]. XML and related standards can define any markup you like and it can be formally translated into any formally defined serial data format for convenient loading into high level language objects within and between applications.

The UI/UX layers of the system can and will use a lot of design excellence to hide the distracting parts of the information structures while still making the formal abstractions tranparent in contexts where it matters. Editors may still need to see and access different affordances than the readers, but doesn't want programmer's system objects either. Triple O, object oriented ontology tells us that the object always has more that what is apparent on the surfaces.