Abstract Thoughts about F# Abstractions

My recent work on Professional F# 2.0 has left me thinking a lot about the nature of abstractions.

In computation, different types of abstraction are trade-offs between clarity and freedom in different areas.   As you move away from the machine architecture, you lose the freedom to push bits around in whichever way you might want.  In the case of garbage collection, this means you might not be able to hand optimize your memory usage.  For managed code, this might mean you can no longer hand optimize your code to a CPU-instruction level.  With even a small degree of abstraction, your choices are cut down to only a small subset of what was previously possible.

In exchange for this loss, you get to think about problems in a constrained way.  This means you can make more valid assumptions about what is going on.  You can express ideas cleanly, without additionally expressing the machine’s management of the resources involved in those ideas.  You can manage less and express more.

The benefit of these constraints goes beyond just what you personally have to worry about while programming.  Some types of abstraction, such as function signature standardization or managed assemblies, enable post-compilation binary compatibility.  Other types of abstraction, such as immutability, allow the compiler to do high level optimizations beyond what was previously possible.

So, while you might be able to do everything with the JMP instruction that you can with C#’s foreach, it takes much more effort to express the same idea with JMP, and a lot more can go wrong.  Similarly, while you may be able to express all of the ideas in C# that you can in F#, it takes much more effort to express those same ideas in C#, and a lot more can go wrong.

And who knows… In the future, we F# users might even get some sweet optimizations out of the deal.

Enjoy this post? Continue the conversation with me on twitter.

Tags: ,

4 comments

  1. Abstractions also permit use to do comparisons (or mapping) between the (conceptual) domains – the ‘isomorphic structure principle’.

  2. Brandon Payton

    When you wrote about the gain of getting to think about problems in a constrained way, my gut reaction was disagreement. Because the hardware is a constraint, I viewed moving beyond hardware as a step toward freer problem solving, less constrained, corrupted, and subconsciously shaped by the realities of computer hardware.

    But it turns out that nothing is truly unconstrained. Positive choices have negative consequences… If we move “here”, then we’re not “there”. Our choices ultimately create a context in which we operate. So, the freedom we do have is to choose our own constraints and frame the problem in the way we would like to naturally think about it. Alternately, we can frame our thinking according to others’ abstractions. Hopefully, we’re doing both.

    • Richard Minerich

      Well, in this case I mean the freedom to decide what our processor spends its time doing. I can see how my wording might make it seem otherwise as “freedom in different areas” is rather nondescript.

      I agree with you that simplicity is another type of freedom, in many cases more valuable. However, when my boss says, “How do we make this faster?”, the freedom of simplicity goes out the window :).

      Looking back, I might not have been clear enough in this post. I wanted to show how F# may seem more abstract as it puts constraints on your code beyond even C#. But I also wanted to show that, counterintuitively, this could be beneficial for optimization. Perhaps I muddled this with too many other ideas.

      Thanks for the criticism.

  3. [...] Richard Minerich’s Abstract Thoughts about F# Abstractions [...]

Leave a comment