Hacker News Reader

Comment by pault | Hacker News Reader

I respectfully disagree. Simple and elegant code is extremely difficult to write, and the ability to do so is mostly orthogonal to intelligence. However, below a certain threshold of skill and capacity for reasoning about spatial complexity, the developer is much more likely to write confusing, tangled, unnecessary, and verbose code. Reading through a codebase with tons of copy pasted code requires far more effort than a codebase with well designed abstractions. The key phrase there is well designed. What you are describing is someone who know which abstractions to use when and where, and that is a skill that requires lots of experience and technical maturity.

View on HN

I respectfully disagree with your disagreement.

Experience and technical maturity do not equate with intelligence.

Abstractions serve one purpose and one purpose only: to reduce cognitive work load. Any abstraction above a primitive implementation only can offer added inefficiencies . Ex: SQL is less efficient than C++ which is less efficient than assembly. A zero abstraction code base is the usually the most efficient implementation and it will be written in assembly.

So from a technical standpoint, we use abstractions only to reduce cognitive workload because other than that abstractions can only offer inn-efficiencies.

Intelligent people do not put in the effort to learn about or implement proper abstractions because they usually deem it unnecessary to abstract what they perceive to be trivial cognitive workloads..

I respectfully disagree with your disagreement of that disagreement.

Abstractions have far more roles than reducing cognitive load. You're completely overlooking platform realities, code reuse, usability and other benefits of reduced/managed complexity.

From a technical standpoint efficiency of the code is irrelevant if it's bug-ridden due to it's complexity. Code is for humans, not the other way around. We chisel away at lower-level languages if efficiency is required (Ex. C bindings in Python).

If you want to utilize your intelligence to the fullest you abstract away most of the trivial stuff to the point where it pays. You can still go down and inspect or override the abstraction if it's needed. Experience in this case is knowing what to abstract in what manner so it will work for you. Intelligence is the act of keeping everything in a sane state without over-focusing on unimportant stuff.

What I think you're critiquing is the act of adding abstractions when there's no need for one at a given time, just to make something simpler in name of simplicity overlooking it's usability. This can be attributed to the lack of experience.

KISS is a suggestion, not a rule. It also applies to abstractions, so in one could argue that doing everything in assembly is actually the "simplest" way of programming, like a rough sketch of a scene is simpler than a full-blown oil painting.

As an aside the whole notion of "intelligence" is a bit twisted with experience IMO. The "classical" IQ applies mostly to dumb pattern matching - a skill one can perfect. EQ can be trained by getting out and deliberately practicing human interactions.

I respectfully disagree with your disagreement of that disagreement of that disagreement.

>Abstractions have far more roles than reducing cognitive load. You're completely overlooking platform realities, code reuse, usability and other benefits of reduced/managed complexity.

I am not overlooking anything. The traits you bring up in this statement do offer any performance improvements to the system. Therefore the only other possible benefits that these traits offer is that they reduce cognitive overhead.

>From a technical standpoint efficiency of the code is irrelevant if it's bug-ridden due to it's complexity. Code is for humans, not the other way around. We chisel away at lower-level languages if efficiency is required (Ex. C bindings in Python).

Yes. And intelligent people can write more complex code with less abstractions and have less bugs... We agree.

>What I think you're critiquing is the act of adding abstractions when there's no need for one at a given time, just to make something simpler in name of simplicity overlooking it's usability. This can be attributed to the lack of experience.

I am not critiquing anything. I have not said anything about my opinion on where or when to add abstractions. I have only commented on how a very intelligent person would do it. I never said I was intelligent... All I said was more intelligent people tend to write less readable code and this can be attributed to the fact that they have less need for abstractions. So no I am not critiquing about when or where to write abstractions.

>The "classical" IQ applies mostly to dumb pattern matching

IQ tests present questions with patterns that the test taker usually has not seen before. A test taker cannot "dumb pattern match" a pattern he has not seen. Therefore the IQ test cannot be testing for "dumb pattern matching." If the IQ test measures IQ and the IQ test is not measuring for "dumb pattern matching" then by concrete logic IQ must not apply to "dumb pattern matching." QED

IQ must apply to something more. A general intelligence.

If you're working with what you perceive to be "trivial cognitive workloads" I think that is more a sign that you aren't quite working at the level you're capable of, than a sign that you're a really intelligent person.

The thing is that all humans have a limited working memory (which generally correlates with 'intelligence'). Whether you can juggle 3 objects in your working memory or 30 doesn't matter; eventually you will get to a problem that you can't hold within your working memory. At that point you will need to start using abstractions for both object-structure and functional characteristics. The limit of what you can do with abstraction is way higher than that of your working memory or intelligence.

As a rule it's always better to properly abstract and structure your code, to keep it as simple and well-formed as possible, and to let your tooling deal with any higher-order actions.

As a bonus this allows other people to have an easy time understanding your code, especially when those 'other people' are your future selves.

>If you're working with what you perceive to be "trivial cognitive workloads" I think that is more a sign that you aren't quite working at the level you're capable of, than a sign that you're a really intelligent person.

Logically it can be a sign of either. If the cognitive workloads are on average hard for normal people and you perceive it to be trivial than you are likely intelligent. If the workload is considered to be trivial by most people and you see it as hard than you are likely not intelligent.

>The thing is that all humans have a limited working memory (which generally correlates with 'intelligence'). Whether you can juggle 3 objects in your working memory or 30 doesn't matter; eventually you will get to a problem that you can't hold within your working memory. At that point you will need to start using abstractions for both object-structure and functional characteristics. The limit of what you can do with abstraction is way higher than that of your working memory or intelligence.

I get where you're coming from. Think of it this way. If we organize the complexity of programs into layers such that each layer functions as an abstraction to reduce cognitive overhead, then we can use the number of layers as a quantitative measure of how much abstractions were used on a program.

A very intelligent person would use 3 layers while a less intelligent person would organize the program into 10 layers. There see how it works? Yes complexity is potentially unlimited but the more intelligent person still ends up relying on abstractions less than the unintelligent one.

One thing that does equate with intelligence is capability for metacognition.

Less intelligent are also those less capable of realising that they’re overburdening their cognitive capacities with their convoluted code.

More intelligent people are likelier to notice that they’re making things harder for themselves (even if it is within the realm of tolerability) and look for alternative strategies.

I actually agree with this. I've seen it happen but not in the way you expect.

I've seen less intelligent people write unnecessary design patterns and abstractions and end up making things harder for themselves. In essence, the heavy reliance the less intelligent programmer has on writing hyper readable and abstract code ends up damaging the app overall.

> Ex: SQL is less efficient than C++ which is less efficient than assembly. A zero abstraction code base is the usually the most efficient implementation and it will be written in assembly.

I don't think we can compare SQL and C++ like that. Not at all.

SQL implementations are most likely written in C or some systems level language. It is a language built on top of another language. A higher level language built on a lower level one. It is therefore by definition a higher abstraction and thus since the nature of the comparison is based off abstractions the comparison is apt since it fits the definition of the word. What you think is different then facts defined by words, and therefore your thinking: that you can't compare C++ to SQL falls in the face of facts.

Perhaps for a very narrow definition of efficiency. Writing in assembly what could be written in SQL is definitely less efficient from a productivity point of view. Even for your definition of efficiency that may not be true.

>Writing in assembly what could be written in SQL is definitely less efficient from a productivity point of view.

You mean productivity as in cognitive workloads can be so high in assembly that it's not efficient? I choose to use a narrow definition of assembly because my argument is that the productivity gains given to an intelligent person by abstractions above assembly language are inconsequential. It wouldn't make sense to use a broader definition. You use the word Productivity but we're really talking about the same thing or in other words "the loss of productivity due to cognitive workloads." Thus your argument is circular to mine and therefore ineffective.

My definition of efficiency is true. SQL eventually executes assembly commands thus it is a higher level of abstraction than assembly and thus it can only be equally or less efficient in terms of space and time complexity. Realistically, the assembly code actually executed is most likely not the most efficient way to execute the code.

Reply on news.ycombinator.com