15 ms·

Being "difficult to understand" is a perspective of an individual observer, not some fundamental property of the thing itself. Japanese is "difficult to underst

Being "difficult to understand" is a perspective of an individual observer, not some fundamental property of the thing itself. Japanese is "difficult to understand" if you only know English, but not if you grew up speaking Japanese. The various conventions around "accepted" programming paradigms like OO, inheritance, scoping, etc are natural if you use them every day for years, but if you're more interested in optimizing some finances or solving a physics problem, something "primitive" or "messy" like a spreadsheet formula or fortran might actually be more understandable.

xeromal 5y ago
Love this point
taoffhand 5y ago
I couldn't agree with more OP. I got my graduate degree in Statistics and, after working for several years in such a role, made a similar vow to Never Again™ touch R (or SAS). This effectively forced a career change. (I'm now "officially" a software developer and couldn't be happier.) My distaste for Statistics stems directly from the commonly used tools. I appreciate your point. In most contexts, such as your comparison between Japanese and English, I agree with it. However, paradigms like OO, inheritance, scoping, etc. are hard-won, intellectual accomplishments; they're not arbitrary. They're purposefully designed to solve specific problems. My experience with R showed it to be rife with problems that have been avoidable for decades. AFAICT, it boils down to the tragic view of "I'm a (statistician|engineer|mathematician) not a coder so I don't need to care". The unfortunate truth is that despite such a view, doing analysis with R makes the analyst a programmer by definition. And so the language, ecosystem, and, consequently, users suffer from half-baked, poorly designed workarounds to problems which have long been solved (and abundantly documented in the software literature). To reduce it to a matter of perspective feels to me like a tautology: it's easy once you get it. Clearly, I'm triggered by this. I hope I've expressed myself respectfully. My point is, I don't feel it's arbitrary. The design and complexity of R has real consequences in terms of cost and reproducibility.
- azalemeth 5y ago
  I use R regularly. I love it. Doing the maths is very easy and general. The programming makes me think differently. I like how it's high level, reasonably fast, rarely involves loops or inline functions directly, and, above all, is the Swiss army chainsaw of statistical analysis. The fact that the journal of statistical software exists is a good thing!
- edumucelli 5y ago
  Inheritance was invented for performance reasons [1]. It was not conceived for pure code organization, so in way it is arbitrary as any other solution that could have brought performance gains for the original garbage collector. Inheritance is an "intellectual accomplishment" as other accomplishments, that will incur into issues if applied blindly, so not having it is not an issue per se. On the contrary, today's widely accepted view of inheritance is to rather use composition instead of it [2]. R does have inheritance by the way, not as you will see frequently on "general purpose" programming languages, thing R is not. [1] http://catern.com/inheritance.html http://catern.com/inheritance.html [2] https://books.google.pt/books?id=ka2VUBqHiWkC&pg=PA81&lpg=PA81&dq=joshua+bloch+composition+over+inheritance&source=bl&ots=yYKfLmr_OY&sig=aUkDzKKDGl30ApOMRVO1dq6pPpU&hl=en&sa=X&ei=eP1GUqjnMaXKyQGk2oC4CA&redir_esc=y#v=onepage&q=joshua%20bloch%20composition%20over%20inheritance&f=false https://books.google.pt/books?id=ka2VUBqHiWkC&pg=PA81&lpg=PA...
  - galaxyLogic 5y ago
    I would say that "inheritance" was much developed in Smalltalk, and there it was not really a tool for improving performance. Rather it is a conceptual tool. "Inheritance" is really the expression of Abstraction in code. Superclass is more general, and thus the abstraction of its subclasses. Although Smalltalk did not have a specific keyword for "Abstract Class" it used the convention of calling "subclassResponsibility" on methods defined in abstract subperclasses which had to be implemented in subclasses. Abstraction, generalization, these are conceptual tools. I'm not sure how "composition" models abstraction if at all. Only OOP does. And one could think that abstraction is a tool valued by scientists. No?
  - spfzero 5y ago
lwhi 5y ago
> Being "difficult to understand" is a perspective of an individual observer, not some fundamental property of the thing itself. I disagree. There are inherent qualities associated with systems that happen to be easier to understand. If you or I were designing such a system, and wanted to ensure this system imbued similar qualities — I believe it would be possible to do so. > Japanese is "difficult to understand" if you only know English, but not if you grew up speaking Japanese. Needing a priori knowledge to be able to understand something, is different.
- Karrot_Kream 5y ago
  > I disagree. There are inherent qualities associated with systems that happen to be easier to understand. If you or I were designing such a system, and wanted to ensure this system imbued similar qualities — I believe it would be possible to do so. Can you formalize these inherent qualities? Until you can, it's hard to prove that a quality is or is not essential.
  - TeMPOraL 5y ago
    > Can you formalize these inherent qualities? Until you can, it's hard to prove that a quality is or is not essential. There is an obvious one, though it's tricky to fully formalize and quantify: locality (also known as "coupling"). You ask yourself a question, "if I were to make a small change to a single piece of this program, how much of the program would I have to change/retest/keep in mind?". If the answer is, "typically, just the area around the change", it's a high locality (loosely coupled) program, a good design. If the answer is, "usually, most/all of it", then it's low locality (tight coupling), a bad design. The reason is, of course, that human mental capacity is limited and in general, number of interactions grows superlinearly with the amount of interacting components. So this here is an objective measure of "easy/hard to understand": the more code you have to keep track of when investigating a random piece of the program, the more mental effort you have to exert - the more difficult to understand it is.
zaphirplane 5y ago
Of course difficult and easy exist. It’s hard to run a marathon it’s easy to eat popcorn. It’s hard to learn Japanese it’s easy to watch tv
gravypod 5y ago
I'm wondering what your opinion is of this talk: https://www.youtube.com/watch?v=7jiPeIFXb6U https://www.youtube.com/watch?v=7jiPeIFXb6U It has some comments about why good software engineering leads to good software, how good software engineering is hard right now because there's a lot of bad examples which cause people to make more bad code, and some suggestions on how things could be done.

xeromal 5y ago

Love this point

taoffhand 5y ago

I couldn't agree with more OP. I got my graduate degree in Statistics and, after working for several years in such a role, made a similar vow to Never Again™ touch R (or SAS). This effectively forced a career change. (I'm now "officially" a software developer and couldn't be happier.) My distaste for Statistics stems directly from the commonly used tools. I appreciate your point. In most contexts, such as your comparison between Japanese and English, I agree with it. However, paradigms like OO, inheritance, scoping, etc. are hard-won, intellectual accomplishments; they're not arbitrary. They're purposefully designed to solve specific problems. My experience with R showed it to be rife with problems that have been avoidable for decades. AFAICT, it boils down to the tragic view of "I'm a (statistician|engineer|mathematician) not a coder so I don't need to care". The unfortunate truth is that despite such a view, doing analysis with R makes the analyst a programmer by definition. And so the language, ecosystem, and, consequently, users suffer from half-baked, poorly designed workarounds to problems which have long been solved (and abundantly documented in the software literature). To reduce it to a matter of perspective feels to me like a tautology: it's easy once you get it. Clearly, I'm triggered by this. I hope I've expressed myself respectfully. My point is, I don't feel it's arbitrary. The design and complexity of R has real consequences in terms of cost and reproducibility.

azalemeth 5y ago
I use R regularly. I love it. Doing the maths is very easy and general. The programming makes me think differently. I like how it's high level, reasonably fast, rarely involves loops or inline functions directly, and, above all, is the Swiss army chainsaw of statistical analysis. The fact that the journal of statistical software exists is a good thing!
edumucelli 5y ago
Inheritance was invented for performance reasons [1]. It was not conceived for pure code organization, so in way it is arbitrary as any other solution that could have brought performance gains for the original garbage collector. Inheritance is an "intellectual accomplishment" as other accomplishments, that will incur into issues if applied blindly, so not having it is not an issue per se. On the contrary, today's widely accepted view of inheritance is to rather use composition instead of it [2]. R does have inheritance by the way, not as you will see frequently on "general purpose" programming languages, thing R is not. [1] http://catern.com/inheritance.html http://catern.com/inheritance.html [2] https://books.google.pt/books?id=ka2VUBqHiWkC&pg=PA81&lpg=PA81&dq=joshua+bloch+composition+over+inheritance&source=bl&ots=yYKfLmr_OY&sig=aUkDzKKDGl30ApOMRVO1dq6pPpU&hl=en&sa=X&ei=eP1GUqjnMaXKyQGk2oC4CA&redir_esc=y#v=onepage&q=joshua%20bloch%20composition%20over%20inheritance&f=false https://books.google.pt/books?id=ka2VUBqHiWkC&pg=PA81&lpg=PA...
- galaxyLogic 5y ago
  I would say that "inheritance" was much developed in Smalltalk, and there it was not really a tool for improving performance. Rather it is a conceptual tool. "Inheritance" is really the expression of Abstraction in code. Superclass is more general, and thus the abstraction of its subclasses. Although Smalltalk did not have a specific keyword for "Abstract Class" it used the convention of calling "subclassResponsibility" on methods defined in abstract subperclasses which had to be implemented in subclasses. Abstraction, generalization, these are conceptual tools. I'm not sure how "composition" models abstraction if at all. Only OOP does. And one could think that abstraction is a tool valued by scientists. No?
- spfzero 5y ago

lwhi 5y ago

> Being "difficult to understand" is a perspective of an individual observer, not some fundamental property of the thing itself. I disagree. There are inherent qualities associated with systems that happen to be easier to understand. If you or I were designing such a system, and wanted to ensure this system imbued similar qualities — I believe it would be possible to do so. > Japanese is "difficult to understand" if you only know English, but not if you grew up speaking Japanese. Needing a priori knowledge to be able to understand something, is different.

Karrot_Kream 5y ago
> I disagree. There are inherent qualities associated with systems that happen to be easier to understand. If you or I were designing such a system, and wanted to ensure this system imbued similar qualities — I believe it would be possible to do so. Can you formalize these inherent qualities? Until you can, it's hard to prove that a quality is or is not essential.
- TeMPOraL 5y ago
  > Can you formalize these inherent qualities? Until you can, it's hard to prove that a quality is or is not essential. There is an obvious one, though it's tricky to fully formalize and quantify: locality (also known as "coupling"). You ask yourself a question, "if I were to make a small change to a single piece of this program, how much of the program would I have to change/retest/keep in mind?". If the answer is, "typically, just the area around the change", it's a high locality (loosely coupled) program, a good design. If the answer is, "usually, most/all of it", then it's low locality (tight coupling), a bad design. The reason is, of course, that human mental capacity is limited and in general, number of interactions grows superlinearly with the amount of interacting components. So this here is an objective measure of "easy/hard to understand": the more code you have to keep track of when investigating a random piece of the program, the more mental effort you have to exert - the more difficult to understand it is.

zaphirplane 5y ago

Of course difficult and easy exist. It’s hard to run a marathon it’s easy to eat popcorn. It’s hard to learn Japanese it’s easy to watch tv

gravypod 5y ago

I'm wondering what your opinion is of this talk: https://www.youtube.com/watch?v=7jiPeIFXb6U https://www.youtube.com/watch?v=7jiPeIFXb6U It has some comments about why good software engineering leads to good software, how good software engineering is hard right now because there's a lot of bad examples which cause people to make more bad code, and some suggestions on how things could be done.