3 ms·

Putting observability first

42 points by lelf 12y ago

mosesschwartz 12y ago
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 http://en.wikipedia.org/wiki/Observability
nateabele 12y ago
"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
jpt4 12y ago
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-against-languages 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)."
- jpt4 12y ago
  Edit: *an generic -> a generic

42 points by lelf 12y ago

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 http://en.wikipedia.org/wiki/Observability

nateabele 12y ago

"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

jpt4 12y ago

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-against-languages 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)."

jpt4 12y ago
Edit: *an generic -> a generic