In Academia.
Academics have a habbit of, whenever you tell them an idea, they tell you 'oh, have you read X by so and so? it's similar' First, this is often discouraging, because you think 'oh, so and so is already doing this? hm.. maybe I should work on something else', because academia values 'novelty'. There are these related work sections which essentially say 'all of these people are doing similar things, but my thing is different for this reason' and it's better if you say "this work builds on this other work, but improves it in this way" because academics like this idea that knowledge is build "on the shoulders of giants", in a very systematic fashion, where each bit of truth fits into a giant puzzle.
But that's not evolution.
It's important to note that even if you can't articulate why an idea is different than another person's idea, it may still be different (the real fitness function for an idea or a truth is whether it "survives and reproduces" -- the criterion of survival by a related work section is arbitrary. That is, people chose to kill off a mutation of a idea because it did not tell the reader exactly how it differed from related idea, which seems silly).
In Software.
Dependencies in software can be bad (it's a tradeoff).
Pros of dependencies : fixing bugs (fixing the bugs everywhere), of course, not all 'bug fixes' are really fixes, since they might have been relied on by the software (possibly because they saw the bug, didn't want to mess with your sourcecode, and so worked around the bug on their end), also, some software changes fix 'usability' bugs, like renaming a method, which will cause errors.
But, fixing usability errors is good, so the fear of having them cause errors is bad. In fact, to create a traditional sort of library, you need to come up with a 'perfect' API right from the beginning.
Another pro of dependencies is that it can use less harddrive space, but this is kindof a silly pro nowdays when harddrive space is relatively cheap (especially for sourcecode, which is typically small, compared to a video).
Cons. Makes evolution slow. I have this utility library for JavaScript called myutil.js. I've tried having a single myutil.js (after I had a nice set of methods), which I kept in github, and would point everything else at. But, I found myself reluctant to add methods to it, since they would affect everything (and might break things). Also, I felt like I couldn't fix usability errors in methods, to make things simpler.
I've also tried copying it around everywhere. Sometimes I would want a method, but I would have started from the wrong myutil.js that didn't have that method (wrong set of evolutionary parents), and so I would need to hunt around for it, or rewrite it. Also, I'm sure it makes loading my webpages slower.
But, I feel like the myutil.js has become better, since I clone the 'fittest' version of it when I start a new project, and only methods that really are generally useful make their way into the newer generations.
Also, it just feels nice when all the dependencies for a project are right there in the directory of the project. I just feel like I could come back to it 6 months later, and still run it, whereas if there were external dependencies, those dependencies might have been modified or removed 6 months from now.
No comments:
Post a Comment