4 ms·

Not a comment on the specific repo in question, but I just want to note that I have seen utter monstrosities of academic code written in Python, MATLAB, and R -

Not a comment on the specific repo in question, but I just want to note that I have seen utter monstrosities of academic code written in Python, MATLAB, and R - languages that are ostensibly "easier" than C++. I so not think that poor code quality is due to the many footguns C++ admittedly gives you. I am sure that the main research is not in the implemented code. But with unclear code, it is exceedingly hard to know that there are no mistakes: that the researched models have been properly encoded. That, I believe, is what software engineers are afraid of.

zozbot234 6y ago
I'm not sure I would describe R as "easier" than C++ tbh.
- disgruntledphd2 6y ago
  It's much more accessible, as you need to know less to use it. Consider - using Eigen in a C++ project, or calling install.packages("eigen") in R.
  - veddox 6y ago
    It's easier to dip your toes into, but it is a terrible language to learn software development with. It's such a hodge-podge of ill-thought-out and ill-fitting components with random names and no overall sense of structure that you're never going to learn core CS concepts from it, let alone good programming practice.
    - disgruntledphd2 6y ago
      That's not really its purpose though, right? R is "an environment for statistical computing and graphics". Note that it doesn't talk about software engineering at all. I agree with you that R has lots of rough edges, but please remember that it's a 90's era clone of a 70's era language (S) and a lot of those rough edges and corners are legacies from that time. I completely agree that the naming conventions (i.e. the absence of same) are super annoying, but again it's a tradeoff for the decades of statistical computing knowledge embedded in the system of R. I find your disdain for R a little annoying, and while I'm probably not a computer scientist, it was my first language and I learned about closures, higher order functions, OOP, testing and interacting with API's from it, and it definitely gave me insight into how computers worked. I'm sorry that you have to deal with horrible legacy R code, but that's no reason to throw the baby out with the bathwater.
      - claytonjy 6y ago
        I really appreciate this sentiment as a data person who learned R first, now works in python, and helps non-engineer scientists write R programs for research. I've had great luck teaching scientists to think in a function-driven way, where functions are pure-as-possible and inputs are never mutated (which doesn't need to be discussed as R makes the opposite quite unnatural). I can't imagine teaching these same folks about python, custom classes, and why you need pd.DataFrame.copy() all over the place.
        SJetKaran 6y ago
        ` and why you need pd.DataFrame.copy() all over the place.` Thanks for saying this! Also, in the past decade, the R data analysis/munging ecosystem has matured far more than the equivalent in Python. These days, writing (tabular) data transformation code in R is often far cleaner, clearer and less error prone than any other platform imo.
      - veddox 6y ago
        > I learned about closures, higher order functions, OOP, testing and interacting with API's from it, and it definitely gave me insight into how computers worked. Well done, I'm honestly impressed :D > remember that it's a 90's era clone of a 70's era language That's not an excuse. Lisp is two decades older. > I find your disdain for R a little annoying ... I'm sorry that you have to deal with horrible legacy R code This has nothing to do with legacy code - I rarely have to touch that. (Scientific code is rarely reused...). R does offer a lot of great features, I'll grant you that. It has a huge library with great functions for doing statistical analysis and really neat graphics - exactly what it was designed for. As a biologist, I cannot imagine not using it. But, and this is a big but, as a programming language it is absolutely horrible. I've worked with half a dozen languages, and none of them are anywhere near as big a pain in the backside as R. Most of that has to do with the terrible incongruity of a plethora of mutually-incompatible data types. You know, you have one function that will only work on a data frame, but somehow your data ended up as a list; or you want strings or numbers but have factors; that kind of thing. In no other language do I have to do as much googling while coding, because even basic operations are so willy-nilly idiosyncratic in their details that I keep forgetting how to do them properly. The "tidyverse" and related packages do a lot to make the experience less painful, but pure R remains a linguistic nightmare.
w0utert 6y ago
Exactly. The C++ code in the GitHub repo is absolutely frightening, but I'm 100% sure if would be pretty much the same in e.g. Python, probaly even worse. From my own experience code quality is inversely related to barrier of entry, which means I see a lot more terrible MATLAB and Python code than terrible C++ code. The only conclusion you can draw from a repo like this, is the conclusion I've drawn countless times when the next piece of modeling code developed by some math or physics expert lands on my desk: these kinds of things can not be developed by domain experts alone, you always need to include skilled software engineers to translate the prototypes they develop (preferably in something like MATLAB) into production code.
- tensor 6y ago
  How do you propose identifying these "skilled software engineers"? University doesn't teach "professional software engineering" so all these hotshots coming out of school into industry can't be what you're looking for. There is no standards body defining the skills one needs to be considered professional. There is no responsibility on practitioners unlike other engineering professions. If a mechanical engineer screws up and causes death, it's going to be bad for them. Software routinely screws up with no consequence. Hell, take two "software engineers" from FAANG and give them a piece of code and they won't agree on whether it's good or bad. None of this is to excuse poorly written scientific code, but if "professional software engineers" want to throw rocks, maybe they should fix their own glass house first.
- zanew101 6y ago
  I work in an research setting with access to lots of skilled software engineers and I've come to a very similar conclusion. The problem I often see is that there is very little incentive for the researcher to bring a software engineer onto their project unless it is absolutely necessary. It is just now becoming commonplace to release code when you publish and plenty of researchers still don't. If you think no one is going to see your code then it makes it much harder to care about its quality. One way we've been fighting this internally is by trying to get researchers less silo'd and more open to code reviews. Once a code review is part of the process then bringing on an "expert coder" to address some of the issues that come up in the reviews has more tangible results! We've seen some success in improving our code quality with this strategy.
commandlinefan 6y ago
> it is exceedingly hard to know that there are no mistakes But that's true of all software, no matter how well engineered. Usually when we discuss issues of code quality, we're looking at long-term maintainability and overall efficiency - that is, targets that are achievable. I'd love to see some effort toward quality metrics around provability of correctness, but I'm not even sure that's possible.
- Nursie 6y ago
  Without formal provability, yes, it's impossible to know there are no mistakes. Even then as most formal methods appear to operate on rules and requirements rather than on the actual code, it's still not possible. However - with well formatted code that's had a review process of some sort, it's going to be easier to cut down on the glaring errors even if there are less obvious problems lurking.

zozbot234 6y ago

I'm not sure I would describe R as "easier" than C++ tbh.

disgruntledphd2 6y ago
It's much more accessible, as you need to know less to use it. Consider - using Eigen in a C++ project, or calling install.packages("eigen") in R.
- veddox 6y ago
  It's easier to dip your toes into, but it is a terrible language to learn software development with. It's such a hodge-podge of ill-thought-out and ill-fitting components with random names and no overall sense of structure that you're never going to learn core CS concepts from it, let alone good programming practice.
  - disgruntledphd2 6y ago
    That's not really its purpose though, right? R is "an environment for statistical computing and graphics". Note that it doesn't talk about software engineering at all. I agree with you that R has lots of rough edges, but please remember that it's a 90's era clone of a 70's era language (S) and a lot of those rough edges and corners are legacies from that time. I completely agree that the naming conventions (i.e. the absence of same) are super annoying, but again it's a tradeoff for the decades of statistical computing knowledge embedded in the system of R. I find your disdain for R a little annoying, and while I'm probably not a computer scientist, it was my first language and I learned about closures, higher order functions, OOP, testing and interacting with API's from it, and it definitely gave me insight into how computers worked. I'm sorry that you have to deal with horrible legacy R code, but that's no reason to throw the baby out with the bathwater.
    - claytonjy 6y ago
      I really appreciate this sentiment as a data person who learned R first, now works in python, and helps non-engineer scientists write R programs for research. I've had great luck teaching scientists to think in a function-driven way, where functions are pure-as-possible and inputs are never mutated (which doesn't need to be discussed as R makes the opposite quite unnatural). I can't imagine teaching these same folks about python, custom classes, and why you need pd.DataFrame.copy() all over the place.
      - SJetKaran 6y ago
        ` and why you need pd.DataFrame.copy() all over the place.` Thanks for saying this! Also, in the past decade, the R data analysis/munging ecosystem has matured far more than the equivalent in Python. These days, writing (tabular) data transformation code in R is often far cleaner, clearer and less error prone than any other platform imo.
    - veddox 6y ago
      > I learned about closures, higher order functions, OOP, testing and interacting with API's from it, and it definitely gave me insight into how computers worked. Well done, I'm honestly impressed :D > remember that it's a 90's era clone of a 70's era language That's not an excuse. Lisp is two decades older. > I find your disdain for R a little annoying ... I'm sorry that you have to deal with horrible legacy R code This has nothing to do with legacy code - I rarely have to touch that. (Scientific code is rarely reused...). R does offer a lot of great features, I'll grant you that. It has a huge library with great functions for doing statistical analysis and really neat graphics - exactly what it was designed for. As a biologist, I cannot imagine not using it. But, and this is a big but, as a programming language it is absolutely horrible. I've worked with half a dozen languages, and none of them are anywhere near as big a pain in the backside as R. Most of that has to do with the terrible incongruity of a plethora of mutually-incompatible data types. You know, you have one function that will only work on a data frame, but somehow your data ended up as a list; or you want strings or numbers but have factors; that kind of thing. In no other language do I have to do as much googling while coding, because even basic operations are so willy-nilly idiosyncratic in their details that I keep forgetting how to do them properly. The "tidyverse" and related packages do a lot to make the experience less painful, but pure R remains a linguistic nightmare.

w0utert 6y ago

Exactly. The C++ code in the GitHub repo is absolutely frightening, but I'm 100% sure if would be pretty much the same in e.g. Python, probaly even worse. From my own experience code quality is inversely related to barrier of entry, which means I see a lot more terrible MATLAB and Python code than terrible C++ code. The only conclusion you can draw from a repo like this, is the conclusion I've drawn countless times when the next piece of modeling code developed by some math or physics expert lands on my desk: these kinds of things can not be developed by domain experts alone, you always need to include skilled software engineers to translate the prototypes they develop (preferably in something like MATLAB) into production code.

tensor 6y ago
How do you propose identifying these "skilled software engineers"? University doesn't teach "professional software engineering" so all these hotshots coming out of school into industry can't be what you're looking for. There is no standards body defining the skills one needs to be considered professional. There is no responsibility on practitioners unlike other engineering professions. If a mechanical engineer screws up and causes death, it's going to be bad for them. Software routinely screws up with no consequence. Hell, take two "software engineers" from FAANG and give them a piece of code and they won't agree on whether it's good or bad. None of this is to excuse poorly written scientific code, but if "professional software engineers" want to throw rocks, maybe they should fix their own glass house first.
zanew101 6y ago
I work in an research setting with access to lots of skilled software engineers and I've come to a very similar conclusion. The problem I often see is that there is very little incentive for the researcher to bring a software engineer onto their project unless it is absolutely necessary. It is just now becoming commonplace to release code when you publish and plenty of researchers still don't. If you think no one is going to see your code then it makes it much harder to care about its quality. One way we've been fighting this internally is by trying to get researchers less silo'd and more open to code reviews. Once a code review is part of the process then bringing on an "expert coder" to address some of the issues that come up in the reviews has more tangible results! We've seen some success in improving our code quality with this strategy.

commandlinefan 6y ago

> it is exceedingly hard to know that there are no mistakes But that's true of all software, no matter how well engineered. Usually when we discuss issues of code quality, we're looking at long-term maintainability and overall efficiency - that is, targets that are achievable. I'd love to see some effort toward quality metrics around provability of correctness, but I'm not even sure that's possible.

Nursie 6y ago
Without formal provability, yes, it's impossible to know there are no mistakes. Even then as most formal methods appear to operate on rules and requirements rather than on the actual code, it's still not possible. However - with well formatted code that's had a review process of some sort, it's going to be easier to cut down on the glaring errors even if there are less obvious problems lurking.