On 18/03/14 18:03, Martin Thompson wrote:
Our use of language in the technology industry could, for sure, be
better. Take simple examples like RAM where random should be
"arbitrary", or don't get me started on people who misuse the term
"agnostic" ;-)
I would even say our use of abstractions in the tech industry could be
better, most notably because of the law of leaky abstractions
<http://en.wikipedia.org/wiki/Leaky_abstraction>: how abstractions such
as RAM, GC, persistent data structure, etc. always have a limit at which
the things they're supposed to abstract come back right in your face and
you end up needing to be aware of the abstracted things. I think
mechanical sympathy is all about dealing with leaky abstractions. The
art of knowing and playing with the limits of our abstractions is what
Rich Hickey would call knowing the trade-offs.
I don't think the law of leaky abstraction has any formal underpinning,
but using the concept of trade-off it's about what we gain from using an
abstraction, which we often know very well because that's the whole
point of using it, and what we loose, which is often the forgotten and
darker side. In those terms an abstraction without leakiness is one that
does not loose anything, whether in terms of information or capability.
Know of any? Isn't the whole point of an abstraction to be hiding
certain underlying aspects, therefore loosing seems to be part of the
deal, meaning abstractions are leaky by nature? I think they are, but
don't ask me for a proof.
The thing is that our industry is based on layers upon layers of
abstractions, whether at the physical level (integrated circuits,
interfaces, etc.) or at the software level: binary (1GL) abstracted into
assembly (2GL), then C language (3GL), etc. Virtual machines is now
another level of abstraction which is probably here to stay, at least in
terms of flexibility offered. So perhaps a key question is how many
levels of abstraction can we afford before the whole thing becomes too
difficult to manage. If think we even have situations where leakiness at
one level makes another level even more leaky, at which point one needs
to reconsider the whole stack of abstractions, perhaps from hardware up
to programming language and runtime, and check for the soundness of the
trade-offs made at each level, and then provide more than one choice.
So in the end it's all about knowing the trade-off we make at each level
of the stack we use. I don't think many of us do, this is becoming more
and more obvious as the stack becomes higher and higher. We don't have
to be a mechanic to drive a car. But it helps to know what we can expect
from it, so we can better choose other modes of transportation when for
example we need to travel 1000 km or miles in 4 hours, or travel with
10+ people, or travel where there's no road. End-users of computer
programs don't have to know the mechanics. But programmers do if they
want to excel at their trade. I don't think we can avoid this: space and
time are inescapable dimensions of our material reality and there will
always be trade-offs around them.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
