|
| Authored by: Anonymous on Wednesday, April 25 2012 @ 04:43 PM EDT |
I saw this in the last thread, and liked it there too.
This might be troubling though, as if we go down this path, then there's a
danger that every piece of software with an interface and without a main
starting method (ie. a library) becomes an API implementation, and then its
specification becomes a language.
Actually maybe that isn't troubling, but the implications perhaps need
thought.
Perhaps this has crossover with the ideas of domain specific languages.
Perhaps APIs are them.[ Reply to This | Parent | # ]
|
|
|
| Authored by: Anonymous on Wednesday, April 25 2012 @ 05:11 PM EDT |
That's a very good analogy. I'm surprised nobody thought of it before. It's
much closer to the "reality" of APIs than most of the other analogies
we've come up with (involving cars or airplanes or textbooks).[ Reply to This | Parent | # ]
|
|
|
| Authored by: Anonymous on Wednesday, April 25 2012 @ 05:27 PM EDT |
Indeed, APIs do extend the language. I still worry about keeping the
idea/expression dichotomy clear, in that an API and a program that implements an
API are distinct because you can describe an API before you actually implement
it. So you could propose an API and even design programs that would work with
that API, but then fail to implement it (say, if you ran out of money), leaving
those programs useless until someone came along to implement the API.
But yes, computer languages enable us to communicate with our computers, just as
APIs allow different programs to communicate by defining precise rules for how
the communication will work. So you're right about all that.[ Reply to This | Parent | # ]
|
|
|
| Authored by: hardmath on Wednesday, April 25 2012 @ 05:39 PM EDT |
It's not so much an analogy as it's by design. The Guy Steele 1998 lecture
Growing a
Language (mentioned
here by mjscud and several days later by me) was referenced in at least two
of Google' briefs ( here and recently here).
OOP languages have syntactic mechanisms to introduce new
terminology (classes and methods). Their implementation can be "internal"
(coded in the same language) or "external (implemented in a "foreign"
language).
For the Core Java APIs there's a lot of the latter, implementing
the "extra" classes and methods using C code. As we move down (out?) the API
hierarchy, there are more opportunities to implement methods in Java code,
relying on previous extensions. A topical example is java.util.TimSort.java
which can be viewed with annotation here from the OpenJDK 7.
The "copied" private method rangeCheck( ) code was also written in Java so that
it could throw (Java) exceptions, something alien to the C programming
language.
At any rate, you are onto a key theme in Google's
defense.
---
"Prolog is an efficient programming language because it
is a very stupid theorem prover." -- Richard O'Keefe [ Reply to This | Parent | # ]
|
|
|
| Authored by: Anonymous on Wednesday, April 25 2012 @ 07:27 PM EDT |
The problem with this analogy is that it targets a small issue (APIs vs.
language) and, as such, it confuses the forest with the trees. The argument is
that Google 'stole' Java by reimplementing it in Android. Very sneaky move.
AFIK it is not clear whether a computer language can be copyrighted. Why not?
The notion that a language itself can by copyrighted is reasonable, especially
Java which was a creative novelty when it first appeared (it was definitely a
creative "expression" by Sun).
The issue is that Sun execs were confused between the lure of open source and
the need for revenues and did not seem to have defended their property as
copyrighted -- something Sun Shareholders were angry and vocal about/see the
comments from investors on the bottom of the famous (retracted) Jonathan Schwarz
blog. Certainly this is one reason Sun went nearly bankrupt and had to be
acquired. But one cannot argue that Google did not know what they were doing...
their previous attempts to use Sun alumnis (Tim Lindholm et al) to feel out
Sun's position in the area make this clear.[ Reply to This | Parent | # ]
|
|
|
| Authored by: Anonymous on Wednesday, April 25 2012 @ 07:50 PM EDT |
* API = named idea.
* API name and syntax = the interface between humans and computers. The name
and syntax are functional and fixed because computers are absolutely literal.
* API Specification = a precise description of the named idea in human
language.
* API Implementation = code to tell a computer how to do perform the
activity described by the named idea.
[ Reply to This | Parent | # ]
|
|
|
| Authored by: Anonymous on Wednesday, April 25 2012 @ 08:22 PM EDT |
Yes, I believe you have it right. Unfortunately at least one whole generation
of programmers have been raised to belive that "API" is something
special that was invented in the 80s by Microsoft. It is not, of course, but
buzzwords and labels are more important to most people than reality. And for
lawyers, judges, and executives, buzzwords and labels are all they know.[ Reply to This | Parent | # ]
|
|
|
| Authored by: Crocodile_Dundee on Thursday, April 26 2012 @ 12:33 AM EDT |
Executive Summary: I think it's more like a Chinese-English dictionary because
it is simply a correlated list of ideas expressed in two languages. Depending
on which language you most understand, one or the other list is the description
of the other.
I've been thinking about this analogy. I think it may work, but different
people will see different things in it.
For example. A dictionary consists of a list of words (which anyone is free to
use) and associated definitions that I should reference if I use. In other
words, I can use the words any way I like, but the definitions are another
matter. (Can I copy the words and definitions from a published dictionary as my
own?)
I see it as more akin to a Chinese-English dictionary, which lists Chinese words
and phrases along with their English equivalents. It essentially tells you what
words signify the same idea in two different languages (note that it doesn't
define that idea, merely the words used to signify it)
A Chinese speaker sees the Chinese words as the description of these unusual
English words and phrases. An English speaker sees exactly the reverse.
So if the English speaker has two different Chinese-English dictionaries, and is
looking for the meaning of the Chinese word "Ma Ximum" and finds two
different meanings, he might wonder if these dictionaries deal with different
dialects. For example one might say "Largest in magnitude", and the
other one might say "Not the least of two". If the English speaker is
a mathematician, he may perceive a significant difference. At the very least he
perceives a difference in meaning.
And similarly for the Java vs. English speaker. Someone who speaks only Java
and not English (a compiler) only understands the Java descriptions and has
someone prepare this document to allow English speakers to talk to it.
A naive English speaker looks at the list of English list and finds the
associated Java expression.
A more multi-lingual person may look at the Java expressions and confirm the
English descriptions are what they expect. And here, if they differ, they might
suspect that the meaning of the Java language has changed.
So the exact wording of "descriptions" within the API may also be
important for compatibility, even though they are totally ignored by the
Java-speaking compiler.
You might be tempted to call it a Roseta Stone, however that was something which
expressed the same ideas in three languages. It was essentially a fragment of
implementation code in C++, Fortran and COBOL.
---
---
That's not a law suit. *THIS* is a law suit![ Reply to This | Parent | # ]
|
|
|
| Authored by: Anonymous on Thursday, April 26 2012 @ 12:52 AM EDT |
My analogy for an interface has always been the restaurant analogy. Imagine
ordering food in a restaurant You don't know anything about the cooks recipes or
methods of cooking. You only know the names of the foods and the menu
description of what you should get back. The interface is the waiter,
mispronounce the names of what you are ordering or forget a detail (for example
"hold the onions") and you don't get back what you expect. The waiter
doesn't cook the food, may not know how the food is cooked and only delivers
your order to the cooks in a particular format and delivers the foods as the
cooks make them. The waiter and his order form is the interface. How you order
from him is the interface description. How he passes the order to the kitchen
can be thought of as a method under the Interface. (Think about some of the
common diner slang for translating menu items.)
Nothing particularly creative or copyrightable in the interface if looked at
like that.
Order a cheeseburger in two different restaurants and you might get two very
different cheeseburgers back but the interface is always the same "I'd like
to order a cheeseburger please.""What do you want on it""I'd
like ...."
written as an API it would probably be
java.util.food.cheeseburger([Condiments]); returns cheeseburger; or some such.
(need to grab out my Java books for actual syntax description) You get the
idea.
Since everyone has gone to a restaurant almost anyone should be able to
understand that the creative part is whats done in the kitchen and cooking part,
not the bored expression on the waiters face.
[ Reply to This | Parent | # ]
|
|
|
| Authored by: Anonymous on Thursday, April 26 2012 @ 05:25 AM EDT |
In the bathroom there is a sink. On the sink are two taps. One tap is labeled
"hot", the other is labeled "cold".
This is an API: You expect bathroom.sink.tap.hot() to return hot water. You
expect bathroom.sink.tap.cold() to return cold water.
You don't need documentation to know how to use the sink.
The plumbing behind the taps can be implemented differently.
Anyone using a Sun/Oracle Java bathroom suite automatically knows how to use the
Google Android bathroom suite because the API is the same.[ Reply to This | Parent | # ]
|
|
|
| Authored by: Ian Al on Thursday, April 26 2012 @ 07:59 AM EDT |
If the procedural rules were written in Java, it would look like this.
Stunning!
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid![ Reply to This | Parent | # ]
|
|
