3 ms·
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™ t
by 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 agoI 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 agoInheritance 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 agoI 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 agoI don’t know why you are saying inheritance was invented for performance reasons? Is there any evidence behind that? Everything I was taught when OOP became mainstream in the late 80s, was that it was a performance trade off to afford code organization insight, while preserving encapsulation. This statement about “performance reasons” is quite baffling.