| HN Mirror

> regarding Graham's essay, I don't think it's about interfaces. It's about abstractions.

Hm... I disagree. would argue that the interface determines the level of abstraction. Almost so much that they might as well be referred to as the same thing, in colloquial contexts.

According to Wikipedia [1], "abstraction" is a way of deriving concepts from tangible objects. According to Paul Graham [2], McCarthy had the insight that variables are effectively pointers. To paraphrase a Zen Koan [3], "The wise man looks at the moon, the fool looks at the finger".

What I'm hinting at is, I think of the entire English lexicon in terms of pointers. Words point to a subset of (real or imagined) particulars we encounter in our experiences. Programming is pointing to a task we want to accomplish via instructions. So when pg talks about "succinctness and abstraction", the list of pointers becomes shorter. But the things they point to remain the same. If a lisp source file and an assembly source file accomplish the same task given the same parameters, then it's the pointers which have changed, not what they point to.

The programming interface affects abstraction. Whether it's an IDE, or a notepad document -- perl or punch tape, the interface affects abstraction. Think about the interface as a medium of expression. it shapes not only the length of the code, but also how the programmer attacks the problem space. E.g. suppose you sketched the Eiffel Tower in pen on cloth, and I carved the Eiffel Tower in marble. Both our works point to the same object. They also have their unique nuances because some of the details of the real tower are lost due to the limitations of the medium. To quote pg [4], "You need that resistance [a friend to bounce ideas off of], just as a carver needs the resistance of the wood."

If abstraction (regarding programming) is about how "instructions to perform a task" are conveyed, then implementation is about technique of performing the conveyed task. Our instructions can point to a specific implementation (per low level languages). But I think we agree they're not the same thing since delegating a task is obviously distinct from specifying how to accomplish it. In my previous comments, I linked to an article which described implementation. When it mentioned "implementation", it meant it in the sense of how the CPU handles interrupts.

pg's essay talks about how fast and easy it is to write code, which is derivative of interface. But does he mention how high-level languages like lisp often execute at a snail's pace given our society's current processing power? He does in another essay, but not in the particular essay you cited. In "Succinctness is Power", pg only addresses one half of the "conservation of complexity equation". I admit it could have been helpful. But I accomplished more by citing other links. Therefore, it would have been redundant.

P.S.

Furthermore, pg is advocating for a higher level abstraction. But in my Orwell link, Orwell complains that words are often vague and overgeneralized. I.e. he's arguing for a lower level of abstraction. Therefore, citing pg would have hurt my case. It's not that I'm trying to cherry pick. I recognize that everything has a time and place, including high lvl and low lvl abstraction. But in the case of addressing the meme "all languages are powerful!", "Succinctness is Power" was definitely not the right citation for the job.

[1] http://en.wikipedia.org/wiki/Abstraction

[2] http://www.paulgraham.com/diff.html

[3] http://www.fifth-ape.com/blog/2012/3/27/the-finger-and-the-m...

[4] http://paulgraham.com/ideas.html