6 ms·

You could be right. But I think there are good reasons to believe that there is more to it than that. I have a strong suspicion that people smart enough to do

You could be right. But I think there are good reasons to believe that there is more to it than that. I have a strong suspicion that people smart enough to do advanced meta programming on their own are not smart enough to collaborate with equally skilled coworkers on code that uses all those abstractions to the max. Even collaborating with your own former self is more difficult that writing new code. So I think _some_ dumbing down is inevitable. The question is how that can be enforced. Choosing a dumber language to bludgeon everyone into submission is the nuclear option so to speak. I often think of this Dijkstra quote about abstraction: "The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise". But I think there's something missing in this thought. Abstraction, especially when its precise, is also a form of compression. To understand what a particular abstract expression means in a concrete case requires decompression, which may require a lot of mental effort. These are admittedly extremely half-baked thoughts...

pron 7y ago
Because no large effect of programming language choice has been observed, and because no theory explains why there would even be one[1], speculating on the causes of a non-existent phenomenon is not very helpful. [1]: Once a certain point has been reached; theory does predict diminishing returns.
- lixtra 7y ago
  > Because no large effect of programming language choice has been observed Do you mind sharing a source for this? It seems trivial to generate a programming language (Brainf*ck) that performs very poorly. A more likely statement: all commonly used languages are more or less on par.
  - pron 7y ago
    I meant the latter. I just can't repeat all caveats every time I bring this subject up :) https://news.ycombinator.com/item?id=20074684 https://news.ycombinator.com/item?id=20074684
- fauigerzigerk 7y ago
  It's near impossible to objectively measure anything when it comes to programming as projects are neither repeatable nor comparable and test subjects are never blank slates. I have read quite a few studies, and I always come away thinking that the methods used are inadequate to support any conclusions at all. But does that mean there is no causal effect of programming language choice? I don't know and I'm not making any claims either way. I was talking about abstraction in one person's mind vs abstraction shared between a group a people. And what I said could actually be the reason why the choice of programming language has little effect (if that is the case)
  - pron 7y ago
    > But does that mean there is no causal effect of programming language choice? I don't know and I'm not making any claims either way. I'm also not making definitive claims, but we can't ignore observations, either. While small effects can appear or disappear depending on methodology, big effects are easy to find and hard to hide, especially in an environment with strong selection pressures. Therefore, the most likely explanation to why no big effect has been detected -- either in studies or in industry -- is that there isn't one, and that should at least be enough to make it the working hypothesis. So before explaining effects that have yet to be detected we should establish that they exist at all, something we have so far failed to do. There may well be a small effect, and there could still be a large effect, although the chance of that is small unless we have a really good explanation to why we haven't found it.
    - fauigerzigerk 7y ago
      Here are some reasons to doubt this working hypothesis: 1) It is inconsistent with the personal experience of most developers. Few would claim that C is just as productive and safe as some garbage collected language (provided that both are suitable for the task at hand), or that a SQL group by statement is not more productive to write than the equivalent procedural code. 2) The methods used to study the subject are completely unfit for purpose. 3) It is inconsistent with the few results that seem at least somewhat well supported because they are simple enough to measure, such as the constant bug count per line of code.
vbezhenar 7y ago
Java is abstraction over JVM which is abstraction over machine code. But I don't need to know anything about JVM bytecode or machine code to write typical Java code. Good abstraction does not require decompression. You're not going down to assembly to understand some Java code. You think on Java code level. That is good abstraction. If you need to decompress what you're reading, then it's a leaky abstraction. It's okay to use leaky abstractions to reduce repetitions, for example. But ideally your abstractions should not require one to learn its implementations in typical cases. For example if your function name is good enough, reader could trust you to do the proper thing and not read its implementation.
- abc_lisper 7y ago
  You just explained cornerstone of good design
- TeMPOraL 7y ago
  Abstractions are a spectrum. There's always a degree of benefit to be had from peeking under the hood. I'd argue that it's rare that you find an abstraction that can be used well without having to understand, or "decompress", some of it. Consider JVM and Java: that you can write Java seemingly without any knowledge about JVM is an illusion - you already learned a lot about how things like JVM work under the hood when first learning programming[0]. Learning more about JVM itself lets you write more efficient code and debug better. Consider functions: it's near-impossible to contain all the information necessary to use a non-trivial function in its header[1]. That's why good code contains comments and other forms of documentation describing the abstraction in more details. Even then, it's not always enough - sometimes it's really much easier to understand what you need by reading the source[2]. Consider any appliance - be it a car, or a radio, or a dishwasher. You can use it to it interface, to some extent at least. But knowing what's going on under the literal hood really does help with use, and especially helps when something goes wrong. If you don't know what's hidden under the abstraction layer, any failure will likely be incomprehensible to you and leave you helpless. -- [0] - In theory, it might be possible to learn some programming without learning anything about hardware or hardware-emulating abstractions. In reality, I've never seen it or heard of it, and I suspect that the simplest mental model of code execution is isomorphic to somewhat simplified computer or virtual machine. [1] - Function name + name of its arguments + types of its arguments and return value, if available. [2] - Then again, implementation code may not capture the entire abstraction either. That's why good code often features comments inside the implementation, explaining the rationale behind some of the less obvious code parts.
invalidOrTaken 7y ago
>I have a strong suspicion that people smart enough to do advanced meta programming on their own are not smart enough to collaborate with equally skilled coworkers on code that uses all those abstractions to the max. Even collaborating with your own former self is more difficult that writing new code. I'm an unabashed Clojure fanboy and will talk the language up to anyone who will listen, but one thing that I've been thinking about lately is that good judgment on abstraction use is necessary for using such powerful tools. I don't think the place to tackle it is by being "smart enough to understand," but rather by being "disciplined enough to not abstract sometimes." The exciting thing is that discipline doesn't require you to be super smart, just to think it's worth caring about. Also half-baked, but I think it's something.
maehwasu 7y ago
The easy solution to this is to create a culture of using powerful tools, but requiring REALLY good reasons to go far to their edges in terms of metaprogramming. It's not that much harder to enforce than it is to enforce conventions in less powerful languages, and the convenience of working in a well-designed language is so nice.

pron 7y ago

Because no large effect of programming language choice has been observed, and because no theory explains why there would even be one[1], speculating on the causes of a non-existent phenomenon is not very helpful. [1]: Once a certain point has been reached; theory does predict diminishing returns.

lixtra 7y ago
> Because no large effect of programming language choice has been observed Do you mind sharing a source for this? It seems trivial to generate a programming language (Brainf*ck) that performs very poorly. A more likely statement: all commonly used languages are more or less on par.
- pron 7y ago
  I meant the latter. I just can't repeat all caveats every time I bring this subject up :) https://news.ycombinator.com/item?id=20074684 https://news.ycombinator.com/item?id=20074684
fauigerzigerk 7y ago
It's near impossible to objectively measure anything when it comes to programming as projects are neither repeatable nor comparable and test subjects are never blank slates. I have read quite a few studies, and I always come away thinking that the methods used are inadequate to support any conclusions at all. But does that mean there is no causal effect of programming language choice? I don't know and I'm not making any claims either way. I was talking about abstraction in one person's mind vs abstraction shared between a group a people. And what I said could actually be the reason why the choice of programming language has little effect (if that is the case)
- pron 7y ago
  > But does that mean there is no causal effect of programming language choice? I don't know and I'm not making any claims either way. I'm also not making definitive claims, but we can't ignore observations, either. While small effects can appear or disappear depending on methodology, big effects are easy to find and hard to hide, especially in an environment with strong selection pressures. Therefore, the most likely explanation to why no big effect has been detected -- either in studies or in industry -- is that there isn't one, and that should at least be enough to make it the working hypothesis. So before explaining effects that have yet to be detected we should establish that they exist at all, something we have so far failed to do. There may well be a small effect, and there could still be a large effect, although the chance of that is small unless we have a really good explanation to why we haven't found it.
  - fauigerzigerk 7y ago
    Here are some reasons to doubt this working hypothesis: 1) It is inconsistent with the personal experience of most developers. Few would claim that C is just as productive and safe as some garbage collected language (provided that both are suitable for the task at hand), or that a SQL group by statement is not more productive to write than the equivalent procedural code. 2) The methods used to study the subject are completely unfit for purpose. 3) It is inconsistent with the few results that seem at least somewhat well supported because they are simple enough to measure, such as the constant bug count per line of code.

vbezhenar 7y ago

Java is abstraction over JVM which is abstraction over machine code. But I don't need to know anything about JVM bytecode or machine code to write typical Java code. Good abstraction does not require decompression. You're not going down to assembly to understand some Java code. You think on Java code level. That is good abstraction. If you need to decompress what you're reading, then it's a leaky abstraction. It's okay to use leaky abstractions to reduce repetitions, for example. But ideally your abstractions should not require one to learn its implementations in typical cases. For example if your function name is good enough, reader could trust you to do the proper thing and not read its implementation.

abc_lisper 7y ago
You just explained cornerstone of good design
TeMPOraL 7y ago
Abstractions are a spectrum. There's always a degree of benefit to be had from peeking under the hood. I'd argue that it's rare that you find an abstraction that can be used well without having to understand, or "decompress", some of it. Consider JVM and Java: that you can write Java seemingly without any knowledge about JVM is an illusion - you already learned a lot about how things like JVM work under the hood when first learning programming[0]. Learning more about JVM itself lets you write more efficient code and debug better. Consider functions: it's near-impossible to contain all the information necessary to use a non-trivial function in its header[1]. That's why good code contains comments and other forms of documentation describing the abstraction in more details. Even then, it's not always enough - sometimes it's really much easier to understand what you need by reading the source[2]. Consider any appliance - be it a car, or a radio, or a dishwasher. You can use it to it interface, to some extent at least. But knowing what's going on under the literal hood really does help with use, and especially helps when something goes wrong. If you don't know what's hidden under the abstraction layer, any failure will likely be incomprehensible to you and leave you helpless. -- [0] - In theory, it might be possible to learn some programming without learning anything about hardware or hardware-emulating abstractions. In reality, I've never seen it or heard of it, and I suspect that the simplest mental model of code execution is isomorphic to somewhat simplified computer or virtual machine. [1] - Function name + name of its arguments + types of its arguments and return value, if available. [2] - Then again, implementation code may not capture the entire abstraction either. That's why good code often features comments inside the implementation, explaining the rationale behind some of the less obvious code parts.

invalidOrTaken 7y ago

>I have a strong suspicion that people smart enough to do advanced meta programming on their own are not smart enough to collaborate with equally skilled coworkers on code that uses all those abstractions to the max. Even collaborating with your own former self is more difficult that writing new code. I'm an unabashed Clojure fanboy and will talk the language up to anyone who will listen, but one thing that I've been thinking about lately is that good judgment on abstraction use is necessary for using such powerful tools. I don't think the place to tackle it is by being "smart enough to understand," but rather by being "disciplined enough to not abstract sometimes." The exciting thing is that discipline doesn't require you to be super smart, just to think it's worth caring about. Also half-baked, but I think it's something.

maehwasu 7y ago

The easy solution to this is to create a culture of using powerful tools, but requiring REALLY good reasons to go far to their edges in terms of metaprogramming. It's not that much harder to enforce than it is to enforce conventions in less powerful languages, and the convenience of working in a well-designed language is so nice.