This is an interesting discussion, but unfortunately the term observability is overloaded. It is used in control theory as "a measure for how well internal states of a system can be inferred by knowledge of its external outputs" [1].

For several years I've been using the term "inspectability" to refer to the kind of observation of code execution to which the author refers. Inspectability is an important concept, especially for computer security, and is not often discussed.

It's interesting to note that malware written in a language like OCaml would often be harder to reverse engineer than malware written in C, precisely because of the points the author makes.

http://en.wikipedia.org/wiki/Observability

Part of the vaunt of Genera and other high level language hardware/software systems is the degree to which the runtime is inspectable; language-as-system design, however, tends to be explicitly monoglottal. Given that the author's research focus appears to be language agnostic systems programming tools (optimizing linkers, language independent interoperability, see [0]), I am curious as to how he might (assuming the final paragraph [1] entails his intention) solve the transparency problem at the scale of the meta-runtime environment, without the multiplication of C vs. gdb level effort for each language supported. The naive approaches of either 1) a powerful host runtime, to which other languages are ported or 2) an generic representation of runtimes more amenable to inspection seem both similar in spirit and akin to the language-as-system approach.

[0] http://www.cl.cam.ac.uk/~srk31/blog/2014/12/16/#for-and-agai...

[1] "This co-evolution is interesting too. The mechanisms for achieving observability in C code lie outside the language. Coredumps and symbol tables are system mechanisms, not language mechanisms. Observability in Unix has been part of the design, down in the fabric of the system; it is not an afterthought. An opinionated system designer (okay, I'll step forward) might claim that observability is too important to leave to language designers. There are, however, some gaps to plug and some mindsets to bridge in order to apply Unix-style debugging infrastructure to ML-like languages. In another post in the near future, I'll dig a bit deeper into OCaml, by considering polymorphism (and why it's not quite the problem it seems to be)."

Edit: *an generic -> a generic

"It's fair to say that the OCaml runtime has not been designed with observability particularly high on the wishlist."

s/the OCaml runtime/computing/ <-- the root of the problem