API Copyright-ability... the rant continues.
So, the Google vs. Oracle appeal is getting under way. And as a result, the ire is building up inside me again, and I felt the need to revisit this.
Apparently, and I hadn't seen this before, the Judge likened API's at one point to a cataloguing system in a library. And while I can see the parallels, that is so far from the truth it barely deserves merit. The argument I felt more compelling, but also flawed was when others compared it to a Table Of Contents which is not afforded the same protection as the rest of a book might.
On the cataloguing or filing system front, for this analogy to be both true and relevant would be to imply that there is logically only a trivial number of ways that an API can be structured and its elements named (and the parameters they take along with their sequence and names).
This, right off the bat is just totally untrue. I can't tell you how many times I've been writing a piece of code and looking for a function or method in the place that I felt was logical, only go searching it out and finding it in a complete different library/namespace/etc, or perhaps, not at all. Also of note here, is that most times the exact name of the function/method and the parameters it requires are not exactly as I would expect. If this were true, I should never have to go looking for a method or class again. I should just have to think where *I* would have logically placed it and what I think it should be called, and it should just be there. Exactly as I reasoned it should. But, that doesn't happen.
I would also say that 9 times out of 10, when this happens, it suddenly makes sense to me why it might be elsewhere. It also doesn't typically invalidate my belief that what I was looking for would also be justified in being located where I originally expected to find it.
But, perhaps the more profound statement there is that something I expect to be a core part of a programming language is often not even there.
Why, if it is so categorically obvious exactly how an API should be structured, that I should run into functionality included by default in some languages and not in others? Or functions, classes and methods in different places with different names and often different parameters?
These things happen because it isn't at all like a catalogue or filing system. Classes, functionality and the likes are included or left out for a myriad of reasons. I may move very large, specialized class off into its own library to avoid forcing developers to load the entire library for a particular function that would rarely be used. I may leave out entire concepts because I don't feel that they are either necessary or compatible with what I hope a particular programming language will be used for. I may have more or less parameters for a given function depending on how easy I want the API to use, or how advanced I want to enable it to be. Or heck, something may not be in there simply because I didn't think of it. Naming conventions will vary by language, upbringing, group dynamics, personal preference or even mood.
I once named a method "GoF***Yourself" after getting frustrated with my code which I later submitted and got full marks for. YAY! I once felt a classes functionality was so self explanatory based on the class name that the sole method it contained was simply called "DoIt". These are perhaps extreme examples, but the less extreme varieties of these happen all of the time. I regularly read other peoples code and can vouch for that.
Funny thing. All of those last 2 paragraphs sound an AWFUL lot like a non-trivial, heavily creative process. Filing a book away on the hand, is not a creative process at all. A cataloguing system is a hard and fast set of rules dictating where something belongs. And having been involved in the creation of several API's, I can tell you there is very little directing these things.
But is an API like a Table of Contents (ToC)? In a way yes. Like a table of contents is to the contents of a book, an API is an abstraction derived from the content or code in this case. But, that is where the similarities end.
A ToC is merely a navigation tool. At the highest level, a ToC might include descriptions in additions to headings and then the page you can locate it on. But the purpose of a ToC is to enable the finding of content. It is a secondary, purely meta representation indicating where to physically find the content within a book. It is also non-necessary. You don't need to read a table of contents to access the content. In fact, I've successfully completed many books without ever referencing the table of contents.
By contrast, the API is how developers utilize a programming language or library. You CANNOT in any way shape or form be said to have utilized a programming language or library without accessing its API. Every method call is an API usage. Every class referenced or instantiated is an API usage. In fact, the API in many cases IS THE ONLY CONTENT a 3rd party can ever consume. The source is often hidden. Closed source software is far more heavily used than open source or anything in between.
Apparently, and I hadn't seen this before, the Judge likened API's at one point to a cataloguing system in a library. And while I can see the parallels, that is so far from the truth it barely deserves merit. The argument I felt more compelling, but also flawed was when others compared it to a Table Of Contents which is not afforded the same protection as the rest of a book might.
On the cataloguing or filing system front, for this analogy to be both true and relevant would be to imply that there is logically only a trivial number of ways that an API can be structured and its elements named (and the parameters they take along with their sequence and names).
This, right off the bat is just totally untrue. I can't tell you how many times I've been writing a piece of code and looking for a function or method in the place that I felt was logical, only go searching it out and finding it in a complete different library/namespace/etc, or perhaps, not at all. Also of note here, is that most times the exact name of the function/method and the parameters it requires are not exactly as I would expect. If this were true, I should never have to go looking for a method or class again. I should just have to think where *I* would have logically placed it and what I think it should be called, and it should just be there. Exactly as I reasoned it should. But, that doesn't happen.
I would also say that 9 times out of 10, when this happens, it suddenly makes sense to me why it might be elsewhere. It also doesn't typically invalidate my belief that what I was looking for would also be justified in being located where I originally expected to find it.
But, perhaps the more profound statement there is that something I expect to be a core part of a programming language is often not even there.
Why, if it is so categorically obvious exactly how an API should be structured, that I should run into functionality included by default in some languages and not in others? Or functions, classes and methods in different places with different names and often different parameters?
These things happen because it isn't at all like a catalogue or filing system. Classes, functionality and the likes are included or left out for a myriad of reasons. I may move very large, specialized class off into its own library to avoid forcing developers to load the entire library for a particular function that would rarely be used. I may leave out entire concepts because I don't feel that they are either necessary or compatible with what I hope a particular programming language will be used for. I may have more or less parameters for a given function depending on how easy I want the API to use, or how advanced I want to enable it to be. Or heck, something may not be in there simply because I didn't think of it. Naming conventions will vary by language, upbringing, group dynamics, personal preference or even mood.
I once named a method "GoF***Yourself" after getting frustrated with my code which I later submitted and got full marks for. YAY! I once felt a classes functionality was so self explanatory based on the class name that the sole method it contained was simply called "DoIt". These are perhaps extreme examples, but the less extreme varieties of these happen all of the time. I regularly read other peoples code and can vouch for that.
Funny thing. All of those last 2 paragraphs sound an AWFUL lot like a non-trivial, heavily creative process. Filing a book away on the hand, is not a creative process at all. A cataloguing system is a hard and fast set of rules dictating where something belongs. And having been involved in the creation of several API's, I can tell you there is very little directing these things.
But is an API like a Table of Contents (ToC)? In a way yes. Like a table of contents is to the contents of a book, an API is an abstraction derived from the content or code in this case. But, that is where the similarities end.
A ToC is merely a navigation tool. At the highest level, a ToC might include descriptions in additions to headings and then the page you can locate it on. But the purpose of a ToC is to enable the finding of content. It is a secondary, purely meta representation indicating where to physically find the content within a book. It is also non-necessary. You don't need to read a table of contents to access the content. In fact, I've successfully completed many books without ever referencing the table of contents.
By contrast, the API is how developers utilize a programming language or library. You CANNOT in any way shape or form be said to have utilized a programming language or library without accessing its API. Every method call is an API usage. Every class referenced or instantiated is an API usage. In fact, the API in many cases IS THE ONLY CONTENT a 3rd party can ever consume. The source is often hidden. Closed source software is far more heavily used than open source or anything in between.
Comments
Post a Comment