
Abstraction, Or, the Gift of Our Weak Brains - Huggernaut
http://engineering.pivotal.io/post/abstraction-or-the-gift-of-our-weak-brains/
======
agentultra
I've been a Hal Abelson and Sussman devotee for many years but I've been on
the fence about the whole, "executed incidentally by computers," idea this
year after Mike Acton's talk and digging into the data-oriented design
philosophy.

As a long-time Lisp user it's quite comfortable to think of the world in
abstractions and having a programmable programming language allows me to bring
the domain to my code in a way that no other language can.

However one always hits the non-theoretical limits of the target platform. At
that point it becomes a challenge to remove all of the abstractions to gain
performance back or find difficult bugs in generated code.

It always comes back to data.

The challenge for engineers trying to decipher the intent behind code is that
the intent went undocumented. It's too challenging and costly to encode those
things in the source of a program. For a system like Voyager one must make
conscious concessions about the data and use every trick they have to perform
the transformations they need with the chips they have on that device. I don't
think a sufficiently high-level language is going to help much -- even one
that can synthesize a program capable of running on Voyager's hardware.

It is crucial, I think, to be able to describe and document your data. You can
re-create the program from the data.

Synthesis might be one avenue if machine learning is capable of producing
models that can generate their own ideas and theorems. Until then the problem
space is still too large, I think, to move it out of NP. Maybe if we get the
graph isomorphism into P.

But if we get that far I don't think we'll need programmers anymore.

------
sbov
I feel like their original quote doesn't support the rest of the article:

> it’s time to turn back to old documents to figure out the logic behind some
> of the engineering decisions. Dodd says it’s easy to find the engineering
> decisions, but harder to find the reasoning.

It's not that they don't understand what the code is doing. It's that they
don't understand _why_ the code is doing what it's doing. Abstractions do not
help with _why_. Documentation does. This is why I try to include as much of
the why in the form of comments and long commit messages. Including
alternatives considered and why I chose not to use them.

------
aclissold
Abstraction and conceptualization are at the core of what makes us human. Some
people think technology is cold and hard and inanimate, but when I look at it
I see the exact opposite.

A great way to be motivated to write abstract code is to first understand how
cool it is!

------
mpweiher
Yes! I often find that I am much worse at holding tons of information in my
brain than my peers. I seem to be better at finding abstractions, and I think
that's in large part due to necessity imposed by that comparative limitation.

------
wellpast
The phenomenon described here is spot on but the OP is being generous when
suggesting that it is merely a "noblesse oblige" for the "smart" developer to
write clearer code. In my experience these developers very quickly lose
creative control of their own spaghetti -- primarily because of the
combinatorial complexity that always stacks up when one doesn't value
simplicity.

Its as Rich Hickey pointed out in his now-famous Simple Made Easy talk, "A
juggler can juggle 3 balls. A really good juggler can juggle 9. No juggler can
juggle 90 or 900." I know the "smart" developers the OP describes very well
and they aren't just doing a disservice to his fellow programmer but to their
own creative possibilities with their code.

------
saneshark
I like the thesis about abstraction, but the example of the Voyager code base
is a little bit contrived.

1) technological limitations, namely in processing and memory probably play a
large role in some of the decisions made.

2) software engineering best practices such as DRY, KISS as they relate to
abstraction have evolved considerably in the 30+ years (perhaps to some extent
because the limitations of observation 1 have been lifted).

Obviously the Voyager code base still has the same technological constraints
today since hardware can't be updated on a probe currently traveling on the
fringes of our galaxy.

It would have been nice to have a more modern example to elucidate the point
regarding empathy for peers.

In fact, the same could apply to the thought process in creating a new
programming language. Take for example PHP, it was originally intended as a
"Personal Home Page," taking PERL and CGI as its model. Method signatures are
inconsistent, and not a lot of thought was made early on to certain points
that might have been made, had the creator of this language not intended it
for his own personal use. In my own experience, PHP offers less empathy for
peers because many of the decisions made are from a single-minded use-case.
Contrast that with other higher level programming languages where the
introduction or removal of new operators is a subject that is heavily
deliberated upon from the perspective of or empathy for peers.

~~~
saneshark
That being said, I think it has as much to do (perhaps more) with laziness and
hubris as it does empathy for peers.

citation: [http://threevirtues.com/](http://threevirtues.com/)

------
silasdavis
I don't think Von Neumann failed to make an abstraction, I think using the
time to impact is about exploiting the structure or symmetry of the problem,
and does not provide a good example of an abstraction being made.

------
talles
Abstraction not only has a play on science but also on the social part of our
lives.

Take money for instance. When you see a great amount of cash you're
immediately amazed, or when you see someone purposely burning money you get
confused.

In physical reality it's all just paper. You see such paper as value (and not
as _valuable_ ) without even thinking about it (we don't "process" the
abstraction).

------
kordless
> Imagine an alien race with the cognitive faculties to reason about
> individual electron trajectories. Would those aliens fall back to the same
> abstraction?

How am I to answer that if the assumption there are individual electrons is
wrong?

~~~
eli_gottlieb
Additionally, how are we to answer that if the assumption that aliens _could_
or _should_ possess such faculties is wrong? There is no finite amount of
processing power that makes individual electron trajectories feasible or
rational to reason about in the general-case.

------
mkobit
I don't have any comments about the content, but I really liked that there was
a TL;DR at the top of the article to set the stage regarding what I was about
to read. I wish more articles would do that!

~~~
seanmcdirmid
Which is called an abstract. An abstract on an article about abstraction.
Reminds me of a paper I read once:

[http://www.ppig.org/papers/20th-
blackwell.pdf](http://www.ppig.org/papers/20th-blackwell.pdf)

~~~
Benvie
"Null" is such a great name for a cat.

~~~
isolate
It's short for Devnull.

