Nexuses Redux: Nativity

I previously wrote about nexuses. One pattern I've noticed with regard to nexuses is that different languages are “native” to different nexuses. It's thus useful to talk about languages (programming languages, scripting languages, shells) with regard to their native nexus.

For example, the native nexus of C is C APIs. The filesystem can be accessed, but necessarily via C APIs.

The native nexus of .NET is the .NET type system and ecosystem. C APIs can be accessed, but with some effort. Indeed, there are many different languages which run on .NET, all native to the same nexus.

Case Study: The Bourne Shell

The Bourne shell is native to an integration nexus, namely the UNIX filesystem. It also constitutes an effective maintenance nexus, precisely because of its nativity to such an important nexus. It is an expedient means of working with a UNIX system because of its nativity to UNIX filesystem objects, operations, state (working directory, environment variables) and executable programs.

Compare this to most programming languages, where performing filesystem operations is likely to be a lot more longwinded than in the Bourne shell.

For this reason, I conclude that choosing a language with appropriate nativity is perhaps an important factor in choosing a language to use. The sheer degree of difference this can make can perhaps best be demonstrated simply by point that when you type commands at the Bourne shell, you are writing in shell, yet are barely aware of this. It is said that the best and most influential technologies tend to become invisible, because we cease to notice them. The Bourne shell is to a degree such a case. Arguably, it, along with coreutils, defines our very relationship with the UNIX filesystem, an integration nexus and namespace.

Although I have little experience with PowerShell, I gather it is interesting because it provides native access to more of Windows' integration nexuses, its namespaces, than the conventional command line. For example, you can change “directory” into the WMI tree, or the registry! By comparison UNIX mostly solves this issue by placing everything in the virtual filesystem hierarchy. (Arguably this is a more elegant solution; there must be a lot of complexity underlying PowerShell to enable traversal of the registry in this manner, and other applications cannot easily benefit from this unification.)