Lambda the Ultimate

why? i think i'm a pretty good java programmer, but i haven't a clue about this - i always assumed they'd have designed it so that it works well with the language. do i have to program java in a certain way to compensate for the bytecode?

what about asts? should we all learn the intermediate representation in the compilers we use so that we can finely tune our code so that that representation is efficient?

(so i can see why someone using the prolog compiler just mentioned would need to learn about java bytecodes)

As one quip says, Lisp programmers know the value of everything, but the cost of nothing. Ok, so this is an unfair characterization of Lisp, but I would note that the Lisp community spends an inordinate amount of effort to educate it's users on how the Lisp machine works. The question is why? Why is it important to understand the Lisp engine, given that it's a purely symbolic architecture?

Efficiency: For much the same reason that one should understand x86 assembly for compilers that target that platform, it's important to know how high level constructs will work their way down into actual executable instructions of the target machine. If one is working with Java, the target machine is not ASM, but rather the intermediate byte-code language. I think the same arguments that Hyde gives for learning ASM are applicable to learning the language of target virtual machines.

Debugging: Sooner or later, I'm always faced with a problem of either (a) not understanding how a higher level construct actually translates; or (b) a problem in the compiler/interpreter that I am using. As one who dislikes having blind spots, or relying solely on trial and error to prove something, I like to have something a bit more concrete than guessing. It's not so important that I meticulously understand how each and every high level instruction translates down to the machine. But there are times when it becomes important to be able to trace the process from top to bottom. Black boxes work fine in terms of allowing us to think in higher and higher levels of abstraction. But sometimes there are problems inside the blackboxes that we have to address.

*ahem*

Corrupted bug report received in error:
could not resolve address. This traces back
unendingly, is lost at last amid
a blitz of registers - beyond my skill


if not all skill. Go high-level to bare metal
in winding descent; resist light, heat and shards;
get zapped in nether regions. Every black
box has another black box inside it somewhere.


The shortest path is a relaxed approach
to the infinite: so route around bad sectors,
solicit patches, number each release
in cautious increments. Surely that kingdom


looms aloft where art is catalogued,
all things considered harmless. There the blinding
magi parley, indolent in their wreaths:
their elan earthed, exposed as commonplace.

The same reason people seem to learn all kinds of things about how lazy certain Haskell constructs really are. I've seen (newbie) programmers who have too little knowledge about what is really happening "down below" having a very hard time to even start guessing where to begin optimizing, or looking for optimization oportunities, or the relative costs of iterating over a hundred elements in a collection and hitting the internet. I tend to think assembler (and hardware) experience makes one a better programmer, and not just in the optimization sense, but very much in the abstraction sense as well, as it gives you an idea of what your language is an abstraction of, and a basis from which you can at least start to comprehend O-notation and other things which matter.

I guess O-notation is at the crux of it - in TAOCP, you're never far away from an analysis of the time complexity of an algorithm, based on a step-by-step implementation in which every step is exactly costed. The point is to teach the discipline of thinking that way, rather than drumming the details of a specific architecture into the reader's head.

Please do not propagate this nonsense.

Not only is this not a law, but only an informal conjecture, it is also an incorrect conjecture which perpetuates fuzzy thinking and discounting of responsibility.

In that article, Spolsky gives some examples of abstractions which he claims `leak' (whatever that means).

He says that TCP claims to guarantee that every message will arrive, but that in fact 1) it won't arrive if your computer gives out, or 2) it will arrive, but very slowly. Well, 1) obviously the proposition that the receiver of a message is available is a precondition of the abstraction and 2) arriving slowly does not contradict the claim, which only says that it will arrive. Now, I don't know if TCP actually respects that guarantee, but I do know that those two counterexamples are not counterexamples at all.

His examples about 2D arrays and page faults, and SQL performance follows the pattern of 2): he pretends that performance guarantees are part of the specification. His remaining examples, about NFS and C++ strings and cars follow the pattern of 1): he pretends that the specification doesn't mention some precondition/assumption.

These are all straw man arguments which stem from Spolsky's desire to oversimplify; when the world doesn't match his expectations, rather than blame his own model of the world, he blames the notion of model (abstraction) itself. `Every abstraction is leaky' means`no model is sound.' Well, while it is undoubtedly true that no model is going to account for all phenomena of interest, one can say, with absolute certainty, of some models that they are sound, provided one is clear on exactly what the model is trying to account for.

Of course, Spolsky is used to working in languages which don't possess any kind of formal semantics, and consequently it's impossible to reason about programs, modules, procedures, classes, etc. without, at the very least, a finite degree of uncertainty. In languages like Scheme or SML, which do possess a semantics, one can formalize a specification, stating precisely what it assumes and guarantees, and then say of a module, for example, that it either implements that specification or not. There is no in-between, or leakiness, or wish-washiness of any sort.

I really find this sort of thing extremely irritating, because it's so circular and such a self-fulfilling prophecy. Why are abstractions leaky? Well, because people design them to leak. Why? It's not only that crystallizing a specification takes more work. It's also thatthey would rather keep their goals as fuzzy as they can get away with, because that way if an implementation is wrong or unsatisfactory, one can shift the blame.

Don't tell me it's not true; I used this tactic all the time when I was a teenager and wanted to get out of something. `You want me to clean my room? Sure.' An hour later. `Oh, under the bed too? And the closet? My desk? You didn't say that!'

In languages like Scheme or SML, which do possess a semantics

If one really wants to be difficult to deal with, one (the same one) can say: "It isn't Scheme all the way down, you give the semantics using some formalism, which itself needs grounding", and then bring up the problem of bootstrapping, and Goedel, and dragons.

But I am not that one :-) I tend to agree, except that probably Spolsky in fact suggested just an observation that people tend to create incomplete (if not unsound) abstractions?

The trouble with specifications is that they can't be formal all the way up (even if they can be formal all the way down, from specification language to "higher-level" language to machine language). Given informal requirements, a formal specification will always be a translation; and some part of what the requirer means (or thinks they mean) will inevitably be lost in the process.

Abstractions "leak" at this juncture, which is the point at which two quite distinct language games with quite distinct rules are brought together. Unless we can all learn to "require" only what we can specify exhaustively and unambiguously, this will continue to be the case.

As far as responsibility goes, there exists a strain of ethical opinion which holds that it is formalism that discounts responsibility by making it unnecessary: no-one need answer personally for the correctness of what can be formally proven. The situation that calls for responsibility is the situation in which I have to make a choice and do not possess any infallible means of determining what is the correct choice. But maybe we'd better not get into meta-ethics right now...

In the first case I want to hear about his assembly language skills. In the second I want hear him mention functional programming.

Being a good software engineer is all about economics. If you don't know assembly, you don't know when it would be a good time to use that knowledge.

Even if that is inevitable (and, though I think it can happen, I don't think it's inevitable), the person who does the specifying (`requirer'), and any reasonable person who uses the specification, can certainly distinguish between `X does Y' and, say, `X does Y using time O(n)'. This is a pretty clear distinction, and it's disingenuous of Spolsky to try to impute performance guarantees into the abstractions he names.

Even if you say that in every specification designed for software there is an implicit performance requirement (which I think is true), it's disingenuous not to make that explicit when you criticize abstractions in general. As in, `OK, I know that nothing in the SQL spec says that this query will be fast, but...'

Similarly, it's staggeringly obvious that windshield wipers, headlights and a car roof are not going to prevent hydroplaning, or make it seem as if it isn't raining. You don't need a formal spec of windshield wipers to see that.

In fact, I don't think Spolsky gives a single example where one could argue, in an intellectually honest way, that the gap between informality and formality is responsible for the `leakiness'.

You don't need a formal spec of windshield wipers to see that.

A spec as a statement of how it should behave or of how it's implemented? If later, then I think in light of chaos, eh, theory, it is not possible to prove even given a formal spec that in all cases, under all circumstances wipers will not influence hydroplaning. But as James mentioned already, SE is about economy, so for all practical purposes it's good enough to run QA and see that in most (realistic) cases the statement is valid.

Probably it is not inevitable to prevent information loss in the process of requirement gathering, but it could be economically inefficient to try achieving that.

I don't even suggest another sidepath - where is the boundary of responsibility between customer and provider? Is it the athmosphere bearing sound waves, is it paper of the contract, or does it depend on legislation? And morality? This leads nowhere, or rather, it can be lead to any question of philosophy.

- How people asking about why his Haskell code leaks memory, and the answer seems to be to learn the details of how the Haskell evaluation strategy works. This is ofcourse a part of the abstraction, but it's a murky and uncomfortable part. Maybe that's the crux.

- How Python string building is simple as that, but when things perform dog slow you need to learn about how the interpreter does string concatenation, and the fact that strings are immutable and all kinds of things the abstraction does not immediatly reveal.

And other things I can't think of quickly. These things are obviously parts of the total abstraction, which in this sense doesn't leak. But that is in a formal sense, in an informal sense (this is where we shouldn't go, informal?) these things are leaks in a higher-level abstraction. Is there a pattern to this kind of phenomena? If it's there, is it in any way a useful pattern to notice or should we just ignore it? Is it in any way related to the abstraction boundary 'leakage' mentioned above? Is this just a case of 'this abstraction is harder to use than it looks, youll just have to learn', as I suspect you're saying?

This is certainly an important part of the problem, since we can obviously design abstractions that don't leak. But can we do it all the time? Can we do it productively while building real life applications? This is less clear, and naturally depends on murky subjects like SE and methodology.

Which is why I formulated a different approach. I am not talking about abstractions leaking, but rather about programmers actively breaking abstractions boundaries. Why do they do it? In a nutshell: sometimes it is easier in the short term, to break an abstraction rather than create a more powerful (and usually more abstact) component.

The problem is that some language provide better (i.e., safer) constructs when it comes to abstraction breaking than others (e.g., inheritance vs. reflection vs. class loaders).

A more detailed discussion of this issue can be found in my paper Component Libraries and Language Features, Ada-Europe'2001, LNCS 2043.