Kate: so many people would rather write, say, their own new aligner that has no dependencies. People seem to think that they trust their own code most? Kate says that she tends to look for review articles, but often they're older, and it's not clear if the most-used package is cited because it's the easiest to understand.
Review articles are a pretty blunt instrument: only one person's opinion, not updated.
Too hard to read/understand someone else's code.
Maybe should email other developers? But sometimes they don't respond.
Maybe should be able to hire someone to modularize the code for extensibility.
We need to figure out how to plan for the amount of person-hours that it takes to do a large analysis or other major extension of the project.
Some kinds of software are more modularizable than others.
Interoperable files: if software can ingest/egest same file formats, that is a form of modularization.
A library might be hard to create because it's hard to chunk out different parts of the functionality.
Would Slim/Nemo/Simbit ever have the time/will to organize and unify their packages?
maybe hackathons?
Another obstacle is that fundamentally, people have different goals. Worried that people might not be okay with others rewriting their entire code base.
It'd be nice if more packages had nice APIs that would wrap any sort of code and then could be made available in other environments like R.
Maybe that's the next thing we need in an intermediate carpentry: modularization.
One of the enemies of modularization is optimization. Can't always play nice and wait for other code.
But maybe should look for optimizations in other areas instead of breaking modularity?
Why not?
Ben: it's hard to merge 3 versions of code that already exist. Hard to invest time/effort in merging without obvious benefit. Code review would be great, but who has the time?
Why do people write new software?
Kate: so many people would rather write, say, their own new aligner that has no dependencies. People seem to think that they trust their own code most? Kate says that she tends to look for review articles, but often they're older, and it's not clear if the most-used package is cited because it's the easiest to understand.
Review articles are a pretty blunt instrument: only one person's opinion, not updated.
Too hard to read/understand someone else's code.
Maybe should email other developers? But sometimes they don't respond.
Maybe should be able to hire someone to modularize the code for extensibility.
We need to figure out how to plan for the amount of person-hours that it takes to do a large analysis or other major extension of the project.
Some kinds of software are more modularizable than others.
Interoperable files: if software can ingest/egest same file formats, that is a form of modularization.
A library might be hard to create because it's hard to chunk out different parts of the functionality.
Would Slim/Nemo/Simbit ever have the time/will to organize and unify their packages?
maybe hackathons?
Another obstacle is that fundamentally, people have different goals. Worried that people might not be okay with others rewriting their entire code base.
It'd be nice if more packages had nice APIs that would wrap any sort of code and then could be made available in other environments like R.
Maybe that's the next thing we need in an intermediate carpentry: modularization.
One of the enemies of modularization is optimization. Can't always play nice and wait for other code. But maybe should look for optimizations in other areas instead of breaking modularity?
Why not? Ben: it's hard to merge 3 versions of code that already exist. Hard to invest time/effort in merging without obvious benefit. Code review would be great, but who has the time?