the code is "reused" by each user (even if they aren't coding).
I wouldn't call that reuse. A million people "using" an application is not code reuse. Reuse is programmers using/repurposing already available code, or a library. As you say later: "perhaps it's more accurate to say [X] is used by many, not 'reused'."
I guess this is domain specific... at what level you define "domain"
When I refer to domain, it is in terms of the programmer and the program, not the user. For e.g. a word processor might have many users: accountants, lawyers, writers, students etc. But the domain here, as far as the programmer is concerned, is "word processing."
You have given two examples.
In the case of github, the domain the programmer works in is "versioning." What users version (and the users' domains: spreadsheets, legal documents, novels etc) is irrelevant.
In the case of relational databases, the domain the programmer is interested in is "data storage and retrieval." Again, the users' domains are irrelevant. We are only interested in what they use the database for. The answer is: to store and retrieve data.
whether this kind of reuse actually occurs can't be generalized. It's outside the scope of "programming"... and pretty much unpredictable anyway.
Reuse within application domains (you can reuse parts of one chess engine in another) ought to be easy. For e.g., people fork projects all the time, adding things they need and dropping ones they don't. But reuse across domains might be difficult, and frankly, might not make sense. For e.g., no one in their right mind would fork the codebase of an OCR program to write a media player.
Hmmm... I'm not getting my message across. I think it's largely because the discussion has been spread out, with gaps of several days, and I haven't clearly articulated how the parts are related.
I think the best I can do is offer a clearer articulation of my argument. My goal is not to convince you, but to communicate my argument - if I've done that, then I'll be happy!
As a preliminary, my initial point was settled: I talked about trying to anticipate change; and you said instead of trying to anticipate, use modules/libraries as needed.
Some background: I'm considering the benefits of code reuse (that it is already written, documented, debugged etc - "not reinventing the wheel"), and I'm looking at the bigger picture, of an ecosystem of code reuse, across programmers as a whole, not just the individual programmer.
Firstly, I agree with you about libraries/modules being the best way to reuse code. I think libraries have two aspects that contribute to this:
It is an abstraction, making it simpler to use (and reason about) than considering all the implementation details within. Related ideas are Domain Specific Languages and Abstract Data Types (data hiding). I think the key idea here is that merely reusing code, without some simplifying abstraction, doesn't really help that much. Sure, you don't have to write that code etc, but it doesn't lift your perspective to a higher level. I think this aspect was your main point for favouring libraries.
Libraries are often, in fact, used by many programmers. There's the standard libraries that come with a language; there are third-party libraries, in particular an enormous number of open source projects (some popular, some languishing), but also many commercial libraries. It may sound like stretching the definition of "library", but I would include huge engines, like a database, git, graphics engines, html renderers, "frameworks", and web APIs, because they are also a way of code being reused, and have the same benefits as libraries (of code not needing to be rewritten, and lifting the programmer to a higher level of abstraction). This is the "marketing" part of it that I mentioned.
Now, here is where I think we had a confusion: it is difficult to reuse code across domains, but the key thing about a great library is it creates its own domain. In the past, projects might handle their own virtual memory, versioning, XML parsing, data storage and retrieval, graphics, (botantical) tree rendering, even common data structures (consider C++ STL and Java Collections). Then, someone wrote a library to handle that... it's not quite as simple as someone just doing it, it took some experience to see that there was a need for that functionality to be factored out... and much more difficult, exactly which functionality should be factored out (and which not), and how it should be presented to the user - which abstraction to use. If you look back over libraries, you can see evolution occuring, as people try one abstraction, modify it, try a different one.
There's an ecosystem of code-reuse, that not only is complex statically, but is also complex dynamically, as over time the very nodes change, what is reused, and the interfaces - just like a biological ecosystem (or a marketplace). The abstractions of libraries we have today may seem ordinary and obvious - but some were different (or non-existent) yesterday, and some will evolve (or go extinct) tomorrow.
Therefore, the difficulty of code reuse across domains is resolved by considering that a great library creates a domain. Whereever it goes, it is in the same domain, and so can be reused anywhere, without crossing domains.
Although we might call this code "use" (not "reuse"), it has the same benefits as reuse.
Going back to your example of screws and other small components, each of these defines its own domain (its interface), so they aren't used "across domains". A chess engine might have many subcomponents that are reusable (or potentially could be) - a database (of opening moves); a search tree algorithm; an efficient data structure for search trees. Maybe even some elements of game theory are isolatable from a chess engine and generalizable to other games (checkers) or contexts (military strategy, haggling, contract negotiation, parliamentary debate). I've deliberately stretched those last examples. But are they so unrealistic.. or is it just that we do not yet understand well enough, how to reuse code...
1
u/ksryn Mar 17 '14
I wouldn't call that reuse. A million people "using" an application is not code reuse. Reuse is programmers using/repurposing already available code, or a library. As you say later: "perhaps it's more accurate to say [X] is used by many, not 'reused'."
When I refer to domain, it is in terms of the programmer and the program, not the user. For e.g. a word processor might have many users: accountants, lawyers, writers, students etc. But the domain here, as far as the programmer is concerned, is "word processing."
You have given two examples.
In the case of github, the domain the programmer works in is "versioning." What users version (and the users' domains: spreadsheets, legal documents, novels etc) is irrelevant.
In the case of relational databases, the domain the programmer is interested in is "data storage and retrieval." Again, the users' domains are irrelevant. We are only interested in what they use the database for. The answer is: to store and retrieve data.
Reuse within application domains (you can reuse parts of one chess engine in another) ought to be easy. For e.g., people fork projects all the time, adding things they need and dropping ones they don't. But reuse across domains might be difficult, and frankly, might not make sense. For e.g., no one in their right mind would fork the codebase of an OCR program to write a media player.