One could quantify this with Category Theory. In order to map from one domain to another reversibly, the target domain must have at least as many elements as the source domain, if not more. An abstraction which simplifies by reducing the number of elements in play is guaranteed to be "leaky".
Of course there could be abstractions that work not by reducing elements but organizing them so they map more efficiently to human thinking. Information theory also has tools that help us quantify when some relation or structure is lost in a translation from a domain to its abstraction. On Tuesday, March 18, 2014 2:23:46 PM UTC-7, François Rey wrote: > > 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.
