JaroslavTulach at 12:33, 7 May 2019 - 2019-05-07 12:33:40

←Older revision Revision as of 12:33, 7 May 2019
Line 5: Line 5:
As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.'' This comment brings us to the title of this post. Things looking similar at first sight may not be same underneath. At the end of 2005, most of the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 ideas were ready]. They just waited for someone to put them into a book. When I finally began to write [[TheAPIBook]], I was searching proper allegory to introduce the reader to the special context of API design. I knew the ''diamonds'' methaphor, but I could not use it, as I believe it is missing something important!
As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.'' This comment brings us to the title of this post. Things looking similar at first sight may not be same underneath. At the end of 2005, most of the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 ideas were ready]. They just waited for someone to put them into a book. When I finally began to write [[TheAPIBook]], I was searching proper allegory to introduce the reader to the special context of API design. I knew the ''diamonds'' methaphor, but I could not use it, as I believe it is missing something important!
-
There is a significant difference between diamonds and stars. While diamonds are said to be forever, nobody considers stars eternal. As such the allegories are not the same. They are in fact quite different. If you get through the [[TheAPIBook|Practical API Design]] book to [[Evolving_the_API_Universe|chapter 15]] and [[End_Of_Life_Procedures|chapter 19]], you'll find out that if you have good support from runtime container, properly versioned APIs and you know how to allow co-existence of multiple versions of similar APIs, you can make your old APIs disappear, yet keep backward compatibility. Of course, this is not a common operation, just like stars do not burn out everyday. However, if you really need to, you can send your API (aka your star) towards a black hole and make it disappear there. Moreover, you can do it in a completely ''user driven'' way, where the speed of dying is driven by number of remaining users of the old API, e.g. observers of your star. This is all possible and the [[NetBeans]] project done that few times.
+
{{:Black hole}}
-
 
+
In short, although APIs look eternal, they are not ''forever'', they are more like stars.
In short, although APIs look eternal, they are not ''forever'', they are more like stars.

JaroslavTulach at 18:53, 17 February 2010 - 2010-02-17 18:53:23

←Older revision Revision as of 18:53, 17 February 2010
Line 1: Line 1:
-
 
+
{{:Parallel Inventions}}
-
{{:Parallel Invetions}}
+
I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that Josh Bloch had spent some time thinking about API design too. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?
I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that Josh Bloch had spent some time thinking about API design too. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?

JaroslavTulach at 18:52, 17 February 2010 - 2010-02-17 18:52:09

←Older revision Revision as of 18:52, 17 February 2010
Line 1: Line 1:
-
Is it uncommon that the same invention is discovered multiple times? Multiple times by different people? At the same time? It is indeed surprising to see something like that, however if you look back at the history of science, it is not that [[Blogs:JaroslavTulach:Theory:DiamondsVsStars|uncommon]]. I know that [[wikipedia::Lightning_rod|lightning rod]] has been independently invented by at least two people in the middle of 18th century. What was so special then that allowed such independent break-through?
 
-
For a centuries great mathematicians were troubled by [[wikipedia::Euclid|Euclid]]'s [[wikipedia::Parallel_postulate|fifth postulate]]. It felt somewhat unnatural compared to the first four, the general expectation was that it is not necessary and it can be derived from the four others. Many tried, yet nobody succeeded. However, at the begging of 19th century things changed. Independently [[wikipedia::János_Bolyai|János Bolyai]], [[wikipedia::Nikolai_Ivanovich_Lobachevsky|Nikolaj Lobačevsky]] and maybe also [[wikipedia::Carl_Friedrich_Gauss|Gauss]] discovered that [[wikipedia::Parallel_postulate|fifth postulate]] is independent on the others. As such we can have geometries accepting and denying it and yet they'll make sense. Why at that time? Why three people at once?
+
{{:Parallel Invetions}}
-
 
+
-
There are many more cases that exhibit such coincidence. I do not think anyone has reasonable explanation for that, my personal feeling is that each era has something in the air that turns people's attention towards similar problems and tunes their mind to frequencies helping discover similar solutions.
+
I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that Josh Bloch had spent some time thinking about API design too. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?
I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that Josh Bloch had spent some time thinking about API design too. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?

JaroslavTulach at 03:38, 26 September 2008 - 2008-09-26 03:38:19

←Older revision Revision as of 03:38, 26 September 2008
Line 9: Line 9:
As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.'' This comment brings us to the title of this post. Things looking similar at first sight may not be same underneath. At the end of 2005, most of the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 ideas were ready]. They just waited for someone to put them into a book. When I finally began to write [[TheAPIBook]], I was searching proper allegory to introduce the reader to the special context of API design. I knew the ''diamonds'' methaphor, but I could not use it, as I believe it is missing something important!
As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.'' This comment brings us to the title of this post. Things looking similar at first sight may not be same underneath. At the end of 2005, most of the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 ideas were ready]. They just waited for someone to put them into a book. When I finally began to write [[TheAPIBook]], I was searching proper allegory to introduce the reader to the special context of API design. I knew the ''diamonds'' methaphor, but I could not use it, as I believe it is missing something important!
-
There is a significant difference between diamonds and stars. While diamonds are said to be forever, nobody considers stars eternal. As such the allegories are not the same. They are in fact quite different. If you get through the [[TheAPIBook|Practical API Design]] book to [[Evolving_the_API_Universe|chapter 15]] and [[End_Of_Life_Procedures|chapter 19]], you find out that if you have good support from runtime container, properly versioned APIs and you know how to allow co-existence of multiple versions of similar APIs, you can make your old APIs disappear, yet keep backward compatibility. Of course, this is not a common operation, just like stars do not burn out everyday. However, if you really need to, you can send your API (aka your star) towards a black hole and make it disappear there. Moreover, you can do it in a completely ''user driven'' way, where the speed of dying is driven by number of remaining users of the old API, e.g. observers of your star. This is all possible and the [[NetBeans]] project done that few times.
+
There is a significant difference between diamonds and stars. While diamonds are said to be forever, nobody considers stars eternal. As such the allegories are not the same. They are in fact quite different. If you get through the [[TheAPIBook|Practical API Design]] book to [[Evolving_the_API_Universe|chapter 15]] and [[End_Of_Life_Procedures|chapter 19]], you'll find out that if you have good support from runtime container, properly versioned APIs and you know how to allow co-existence of multiple versions of similar APIs, you can make your old APIs disappear, yet keep backward compatibility. Of course, this is not a common operation, just like stars do not burn out everyday. However, if you really need to, you can send your API (aka your star) towards a black hole and make it disappear there. Moreover, you can do it in a completely ''user driven'' way, where the speed of dying is driven by number of remaining users of the old API, e.g. observers of your star. This is all possible and the [[NetBeans]] project done that few times.
In short, although APIs look eternal, they are not ''forever'', they are more like stars.
In short, although APIs look eternal, they are not ''forever'', they are more like stars.

JaroslavTulach at 03:36, 26 September 2008 - 2008-09-26 03:36:57

←Older revision Revision as of 03:36, 26 September 2008
Line 5: Line 5:
There are many more cases that exhibit such coincidence. I do not think anyone has reasonable explanation for that, my personal feeling is that each era has something in the air that turns people's attention towards similar problems and tunes their mind to frequencies helping discover similar solutions.
There are many more cases that exhibit such coincidence. I do not think anyone has reasonable explanation for that, my personal feeling is that each era has something in the air that turns people's attention towards similar problems and tunes their mind to frequencies helping discover similar solutions.
-
I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that Josh Bloch had also spent some time thinking API design. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?
+
I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that Josh Bloch had spent some time thinking about API design too. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?
As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.'' This comment brings us to the title of this post. Things looking similar at first sight may not be same underneath. At the end of 2005, most of the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 ideas were ready]. They just waited for someone to put them into a book. When I finally began to write [[TheAPIBook]], I was searching proper allegory to introduce the reader to the special context of API design. I knew the ''diamonds'' methaphor, but I could not use it, as I believe it is missing something important!
As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.'' This comment brings us to the title of this post. Things looking similar at first sight may not be same underneath. At the end of 2005, most of the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 ideas were ready]. They just waited for someone to put them into a book. When I finally began to write [[TheAPIBook]], I was searching proper allegory to introduce the reader to the special context of API design. I knew the ''diamonds'' methaphor, but I could not use it, as I believe it is missing something important!

JaroslavTulach at 03:36, 26 September 2008 - 2008-09-26 03:36:28

←Older revision Revision as of 03:36, 26 September 2008
Line 5: Line 5:
There are many more cases that exhibit such coincidence. I do not think anyone has reasonable explanation for that, my personal feeling is that each era has something in the air that turns people's attention towards similar problems and tunes their mind to frequencies helping discover similar solutions.
There are many more cases that exhibit such coincidence. I do not think anyone has reasonable explanation for that, my personal feeling is that each era has something in the air that turns people's attention towards similar problems and tunes their mind to frequencies helping discover similar solutions.
-
I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that the Josh Bloch also spend some time thinking API design. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?
+
I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that Josh Bloch had also spent some time thinking API design. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?
As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.'' This comment brings us to the title of this post. Things looking similar at first sight may not be same underneath. At the end of 2005, most of the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 ideas were ready]. They just waited for someone to put them into a book. When I finally began to write [[TheAPIBook]], I was searching proper allegory to introduce the reader to the special context of API design. I knew the ''diamonds'' methaphor, but I could not use it, as I believe it is missing something important!
As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.'' This comment brings us to the title of this post. Things looking similar at first sight may not be same underneath. At the end of 2005, most of the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 ideas were ready]. They just waited for someone to put them into a book. When I finally began to write [[TheAPIBook]], I was searching proper allegory to introduce the reader to the special context of API design. I knew the ''diamonds'' methaphor, but I could not use it, as I believe it is missing something important!

213.220.235.180 at 03:32, 26 September 2008 - 2008-09-26 03:32:36

←Older revision Revision as of 03:32, 26 September 2008
Line 1: Line 1:
-
Is it uncommon that the same invention is discovered multiple times? Multiple times by different people? At the same time? It is indeed surprising to see something like that, however if you look back at the history of science, it is not that uncommon. I know that [[wikipedia::Lightning_rod|lightning rod]] has been independently invented by at least two people in the middle of 18th century. What was so special then that allowed such independent break-through?
+
Is it uncommon that the same invention is discovered multiple times? Multiple times by different people? At the same time? It is indeed surprising to see something like that, however if you look back at the history of science, it is not that [[Blogs:JaroslavTulach:Theory:DiamondsVsStars|uncommon]]. I know that [[wikipedia::Lightning_rod|lightning rod]] has been independently invented by at least two people in the middle of 18th century. What was so special then that allowed such independent break-through?
For a centuries great mathematicians were troubled by [[wikipedia::Euclid|Euclid]]'s [[wikipedia::Parallel_postulate|fifth postulate]]. It felt somewhat unnatural compared to the first four, the general expectation was that it is not necessary and it can be derived from the four others. Many tried, yet nobody succeeded. However, at the begging of 19th century things changed. Independently [[wikipedia::János_Bolyai|János Bolyai]], [[wikipedia::Nikolai_Ivanovich_Lobachevsky|Nikolaj Lobačevsky]] and maybe also [[wikipedia::Carl_Friedrich_Gauss|Gauss]] discovered that [[wikipedia::Parallel_postulate|fifth postulate]] is independent on the others. As such we can have geometries accepting and denying it and yet they'll make sense. Why at that time? Why three people at once?
For a centuries great mathematicians were troubled by [[wikipedia::Euclid|Euclid]]'s [[wikipedia::Parallel_postulate|fifth postulate]]. It felt somewhat unnatural compared to the first four, the general expectation was that it is not necessary and it can be derived from the four others. Many tried, yet nobody succeeded. However, at the begging of 19th century things changed. Independently [[wikipedia::János_Bolyai|János Bolyai]], [[wikipedia::Nikolai_Ivanovich_Lobachevsky|Nikolaj Lobačevsky]] and maybe also [[wikipedia::Carl_Friedrich_Gauss|Gauss]] discovered that [[wikipedia::Parallel_postulate|fifth postulate]] is independent on the others. As such we can have geometries accepting and denying it and yet they'll make sense. Why at that time? Why three people at once?

JaroslavTulach at 21:17, 25 September 2008 - 2008-09-25 21:17:33

←Older revision Revision as of 21:17, 25 September 2008
Line 7: Line 7:
I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that the Josh Bloch also spend some time thinking API design. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?
I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that the Josh Bloch also spend some time thinking API design. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?
-
As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.'' This comment brings us to the title of this post. Things looking similar at first sight may not be same underneath. At the end of 2005, most of the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 ideas were already] cooked and ready. There just waited for someone to put them into a book. When I finally began to write [[TheAPIBook]], I was searching proper allegory to introduce the reader to the special context of API design. I knew the ''diamonds'' methaphor, but I could not use it, as I believe it is missing something important!
+
As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.'' This comment brings us to the title of this post. Things looking similar at first sight may not be same underneath. At the end of 2005, most of the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 ideas were ready]. They just waited for someone to put them into a book. When I finally began to write [[TheAPIBook]], I was searching proper allegory to introduce the reader to the special context of API design. I knew the ''diamonds'' methaphor, but I could not use it, as I believe it is missing something important!
There is a significant difference between diamonds and stars. While diamonds are said to be forever, nobody considers stars eternal. As such the allegories are not the same. They are in fact quite different. If you get through the [[TheAPIBook|Practical API Design]] book to [[Evolving_the_API_Universe|chapter 15]] and [[End_Of_Life_Procedures|chapter 19]], you find out that if you have good support from runtime container, properly versioned APIs and you know how to allow co-existence of multiple versions of similar APIs, you can make your old APIs disappear, yet keep backward compatibility. Of course, this is not a common operation, just like stars do not burn out everyday. However, if you really need to, you can send your API (aka your star) towards a black hole and make it disappear there. Moreover, you can do it in a completely ''user driven'' way, where the speed of dying is driven by number of remaining users of the old API, e.g. observers of your star. This is all possible and the [[NetBeans]] project done that few times.
There is a significant difference between diamonds and stars. While diamonds are said to be forever, nobody considers stars eternal. As such the allegories are not the same. They are in fact quite different. If you get through the [[TheAPIBook|Practical API Design]] book to [[Evolving_the_API_Universe|chapter 15]] and [[End_Of_Life_Procedures|chapter 19]], you find out that if you have good support from runtime container, properly versioned APIs and you know how to allow co-existence of multiple versions of similar APIs, you can make your old APIs disappear, yet keep backward compatibility. Of course, this is not a common operation, just like stars do not burn out everyday. However, if you really need to, you can send your API (aka your star) towards a black hole and make it disappear there. Moreover, you can do it in a completely ''user driven'' way, where the speed of dying is driven by number of remaining users of the old API, e.g. observers of your star. This is all possible and the [[NetBeans]] project done that few times.

JaroslavTulach at 21:04, 25 September 2008 - 2008-09-25 21:04:25

←Older revision Revision as of 21:04, 25 September 2008
Line 1: Line 1:
Is it uncommon that the same invention is discovered multiple times? Multiple times by different people? At the same time? It is indeed surprising to see something like that, however if you look back at the history of science, it is not that uncommon. I know that [[wikipedia::Lightning_rod|lightning rod]] has been independently invented by at least two people in the middle of 18th century. What was so special then that allowed such independent break-through?
Is it uncommon that the same invention is discovered multiple times? Multiple times by different people? At the same time? It is indeed surprising to see something like that, however if you look back at the history of science, it is not that uncommon. I know that [[wikipedia::Lightning_rod|lightning rod]] has been independently invented by at least two people in the middle of 18th century. What was so special then that allowed such independent break-through?
-
For a centuries great mathematicians were troubled by [[wikipedia::Euclid|Euclid]]'s [[wikipedia::Parallel_postulate|fifth postulate]]. It felt somewhat unnatural compared to the first four, the general expectation was that it is not necessary and it can be derived from the four others. Many tried, yet nobody succeeded. However, at the begging of 19th century things changed. Independently [[wikipedia::János_Bolyai]], [[wikipedia::Nikolai_Ivanovich_Lobachevsky]] and maybe also [[wikipedia::Carl_Friedrich_Gauss]] discovered that [[wikipedia::Parallel_postulate|fifth postulate]] is independent on the others. As such we can have geometries accepting and denying it and yet they'll make sense. Why at that time? Why three people at once?
+
For a centuries great mathematicians were troubled by [[wikipedia::Euclid|Euclid]]'s [[wikipedia::Parallel_postulate|fifth postulate]]. It felt somewhat unnatural compared to the first four, the general expectation was that it is not necessary and it can be derived from the four others. Many tried, yet nobody succeeded. However, at the begging of 19th century things changed. Independently [[wikipedia::János_Bolyai|János Bolyai]], [[wikipedia::Nikolai_Ivanovich_Lobachevsky|Nikolaj Lobačevsky]] and maybe also [[wikipedia::Carl_Friedrich_Gauss|Gauss]] discovered that [[wikipedia::Parallel_postulate|fifth postulate]] is independent on the others. As such we can have geometries accepting and denying it and yet they'll make sense. Why at that time? Why three people at once?
-
There are many more cases that exhibit such coincidence. I do not think anyone has reasonable explanation for that, my personal feeling is that each era has something in the air that turns people's attention towards similar problems and tunes their mind to discover similar solutions.
+
There are many more cases that exhibit such coincidence. I do not think anyone has reasonable explanation for that, my personal feeling is that each era has something in the air that turns people's attention towards similar problems and tunes their mind to frequencies helping discover similar solutions.
I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that the Josh Bloch also spend some time thinking API design. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?
I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that the Josh Bloch also spend some time thinking API design. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?
-
As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.''.
+
As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.'' This comment brings us to the title of this post. Things looking similar at first sight may not be same underneath. At the end of 2005, most of the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 ideas were already] cooked and ready. There just waited for someone to put them into a book. When I finally began to write [[TheAPIBook]], I was searching proper allegory to introduce the reader to the special context of API design. I knew the ''diamonds'' methaphor, but I could not use it, as I believe it is missing something important!
 +
 
 +
There is a significant difference between diamonds and stars. While diamonds are said to be forever, nobody considers stars eternal. As such the allegories are not the same. They are in fact quite different. If you get through the [[TheAPIBook|Practical API Design]] book to [[Evolving_the_API_Universe|chapter 15]] and [[End_Of_Life_Procedures|chapter 19]], you find out that if you have good support from runtime container, properly versioned APIs and you know how to allow co-existence of multiple versions of similar APIs, you can make your old APIs disappear, yet keep backward compatibility. Of course, this is not a common operation, just like stars do not burn out everyday. However, if you really need to, you can send your API (aka your star) towards a black hole and make it disappear there. Moreover, you can do it in a completely ''user driven'' way, where the speed of dying is driven by number of remaining users of the old API, e.g. observers of your star. This is all possible and the [[NetBeans]] project done that few times.
 +
 
 +
 
 +
In short, although APIs look eternal, they are not ''forever'', they are more like stars.

JaroslavTulach: New page: Is it uncommon that the same invention is discovered multiple times? Multiple times by different people? At the same time? It is indeed surprising to see something like that, however if yo... - 2008-09-25 20:37:02

New page: Is it uncommon that the same invention is discovered multiple times? Multiple times by different people? At the same time? It is indeed surprising to see something like that, however if yo...

New page

Is it uncommon that the same invention is discovered multiple times? Multiple times by different people? At the same time? It is indeed surprising to see something like that, however if you look back at the history of science, it is not that uncommon. I know that [[wikipedia::Lightning_rod|lightning rod]] has been independently invented by at least two people in the middle of 18th century. What was so special then that allowed such independent break-through?

For a centuries great mathematicians were troubled by [[wikipedia::Euclid|Euclid]]'s [[wikipedia::Parallel_postulate|fifth postulate]]. It felt somewhat unnatural compared to the first four, the general expectation was that it is not necessary and it can be derived from the four others. Many tried, yet nobody succeeded. However, at the begging of 19th century things changed. Independently [[wikipedia::János_Bolyai]], [[wikipedia::Nikolai_Ivanovich_Lobachevsky]] and maybe also [[wikipedia::Carl_Friedrich_Gauss]] discovered that [[wikipedia::Parallel_postulate|fifth postulate]] is independent on the others. As such we can have geometries accepting and denying it and yet they'll make sense. Why at that time? Why three people at once?

There are many more cases that exhibit such coincidence. I do not think anyone has reasonable explanation for that, my personal feeling is that each era has something in the air that turns people's attention towards similar problems and tunes their mind to discover similar solutions.

I've been thinking about the laws of proper API design since 2001 and for a long time I believed that I am the only one who cares about such topic. I was pleasantly surprised during the Java One 2005 fully crowded [http://treefs.netbeans.org/files/documents/39/676/apidesign.sxi BOF]. However I still believed [[NetBeans]] is the only organization that does some research in this area. You can imagine how much I was surprised when I found out, at the [http://www.artima.com/weblogs/viewpost.jsp?thread=142428 end of 2005], that the Josh Bloch also spend some time thinking API design. And that was not enough, my surprise even grew, when I found out that 80% of his observation in his [http://lcsd05.cs.tamu.edu/slides/keynote.pdf presentation] are similar to mine. There must have been something in the air, mustn't it?

As one comment stated: ''These things are a lot in Jaroslav Tulach's new book. Only real difference is that 'diamonds' above are 'stars' there.''.