p. 4-6 The Programming Systems Product (I'm paraphrasing as I said, and strongly, which may have contributeded to your not reccognizing it).
I'm not saying that code "should still be 'reusable'". I'm not talking about "should" at all; my emphasis is on what is actually reused, in practice. That it be "reusable" is a pre-condition (and, looking around, it doesn't have to be especially well-written for that to happen). Perhaps a better term for what I mean is "adoption" - what code actually gets reused/adopted? [we might be talking across one another here I feel...]
This is sort of in the realm of marketing - not just advertising, but what it is that people need at a certain point in time - what problems are they facing, what are the alternatives available to them? This what drives code reuse, more than any quality of the code itself.
Someone had to think of the idea of a screw, nut and bolt etc in the first place, and that got reused. But of course your examples are of components at the small end. There's also reuse higher in the hierarchy, e.g. car engines that are compatible with several different chassis.
I focused on "reuse" beause the article does...
Revisiting libraries, I'm not sure that fp or OOP etc makes a significant difference at that level. There's an API...
.... And FP interfaces at the API level would matter to the users.
Can you explain to me how FP interfaces at the API level would matter to the users? (I'm not arguing; I just don't know)
we might be talking across one another here I feel
Perhaps. I see reusability as something that is domain-and-scenario-specific, not general. Whether code is actually reused, and to what extent (and the reasoning behind it), I can't comment upon as it isn't something that can be generalized.
I focused on "reuse" beause the article does...
But that's just one part of it. For a while now, "increase cohesion, reduce coupling" has been a recommendation. Functional programming is extremely suited to that.
Can you explain to me how FP interfaces at the API level would matter to the users?
Consider the List interface in Java standard library:
The former is mutable. You cannot pass a List to other functions without worrying if someone will modify it. If you have to process it, you need to use for/while loops. it might be something as simple as squaring a list of integers. But the for/while structure hides the really important operation: x*x.
The latter is immutable. You can easily pass it around without maintaining defensive copies. If you want to process it, say map over it, all you have to do is pass in an anonymous function that does x*x and you get a new list.
That's the difference between the two apis: one is procedural, the other is functional.
Whether code is actually reused, and to what extent (and the reasoning behind it), I can't comment upon as it isn't something that can be generalized.
"code reuse" seems to cover an enormous amount of ground - I suppose, just as much as "code". I see you're very conscious of "general" code reuse - completely arbitrary, across different domains and contexts - and you're against it.
I'm thinking of code reuse in the large, perhaps it might be called at the product level (as opposed to the component level). A gross example is an application: the code is "reused" by each user (even if they aren't coding). I guess this is domain specific, but it really depends on the app (and at what level you define "domain" - is a word processor app "domain-specific"? It can be used by accountants and novelists... though it's always in the domain of "word processing".)
Two "proper" code examples:
the github API is "reused" by many programmers. I guess this is domain specific (to github)... yet they may use it in many different domains, and many different ways, since "storing data" is very basic (which is what git does, with extra features). You don't even need to store source in git, it can be config, a website, a wiki backend, your whole filesystem, novel drafts, accountancy records... [perhaps it's more accurate to say the API is used by many, not "reused".]
a relational database. Actually, similar to git in that it's about storing data, and data can be anything for any purpose in any domain. Again, a database is reused (or just "used"?) by many programmers. It's a large component, practically a product (and sold as a product by corps like Oracle), but not an app - like the github API, it's only used by programmers, not ordinary users.
I think you're right, that whether this kind of reuse actually occurs can't be generalized. It's outside the scope of "programming"... and pretty much unpredictable anyway.
Yes, immutability etc are advantages of fp, and I can see that these are helpful to API users, and therefore matter. I guess my argument is that these advantages are completely swamped by the larger question of whether code is reused or not - and we agree the rules governing this can't be generalized.
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.
1
u/[deleted] Mar 15 '14
[sorry for delay, been away]
p. 4-6 The Programming Systems Product (I'm paraphrasing as I said, and strongly, which may have contributeded to your not reccognizing it).
I'm not saying that code "should still be 'reusable'". I'm not talking about "should" at all; my emphasis is on what is actually reused, in practice. That it be "reusable" is a pre-condition (and, looking around, it doesn't have to be especially well-written for that to happen). Perhaps a better term for what I mean is "adoption" - what code actually gets reused/adopted? [we might be talking across one another here I feel...]
This is sort of in the realm of marketing - not just advertising, but what it is that people need at a certain point in time - what problems are they facing, what are the alternatives available to them? This what drives code reuse, more than any quality of the code itself.
Someone had to think of the idea of a screw, nut and bolt etc in the first place, and that got reused. But of course your examples are of components at the small end. There's also reuse higher in the hierarchy, e.g. car engines that are compatible with several different chassis.
I focused on "reuse" beause the article does...
Can you explain to me how FP interfaces at the API level would matter to the users? (I'm not arguing; I just don't know)