
Putting observability first - lelf
http://www.cl.cam.ac.uk/~srk31/blog/2015/02/20/
======
mosesschwartz
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)

------
jpt4
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...](http://www.cl.cam.ac.uk/~srk31/blog/2014/12/16/#for-and-against-
languages)

[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
Edit: *an generic -> a generic

------
nateabele
"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

