There are people who don't like the idea of Alexa and those who do. For the first category, the "Don't own one" response is natural. For the second category, your response is natural.
As for me, I have a natural bias because I have a voice problem. Not a bad one, but people often have to ask me to repeat something. Alexa would be somewhere between useless and extremely aggravating for me. One of my sons and his wife and kids love Alexa, and the other son and his wife hate it, so I don't know whether my granddaughter would like it or not.
When software is tested the testing should include the ease of a full uninstall, plus some regression testing to be sure the uninstall didn't have side effects. I stopped buying Logitech products about 15 years ago when one uninstall had side effects that took me 8 hours to fix.
In 1973 or 1974 I was the systems programming manager at the National Academy of Sciences after our IBM mainframe had been upgraded to the first version of the OS supporting virtual storage. And many programs, mostly Fortran programs, were running much slower than they used to. The problem was two-dimensional arrays and how they were initialized and searched. If you're looping through the wrong subscript in a big array, you cause a page fault every time you increment it. Flash storage makes that a much smaller problem than it is with disk drives, but I'm sure most programmers today have no idea that this problem exists or how to handle it.
When I turned 16 in 1962 I spent some of the first money from my first job on a shortwave radio and discovered Radio Moscow. Most of what they broadcast was pure propaganda, but it did teach me that in some areas, other points of view were valid. The U.S. government did nothing to stop it in 1962, and now it wants to spend $160 million over two years. I could see spending money to make it harder to find ISIS sites, but Russian fake news is in a different category. Maybe it really does pose more of a danger than ISIS sites, but it's a very different kind of danger. The only thing clear is that propaganda can't be stopped. It's just a matter of degree.
The first time I re-used an API was in 1968, to implement job accounting on an IBM 360/40 running IBM DOS. Their is a huge amount of prior art to re-using an API.
To read accounting info added to Job cards, I had to intercept the job card and process it myself before then handing it off to the next step of processing.
Back in the late 1960s and early 1970s, many of IBM's mainframe APIs were public and cloned regularly. One of the first reasons was to perform Job Accounting, i.e., charge for the run of batch programs based on some combination of userid, account number, CPU time and clock time used, etc.
For instance, if a Job card was processed by an API in module jobctla.exe, we would rename that IBM module to jobctlx.exe, and write our own jobctla.exe. In our module, we would simply pass on the the API calls we didn't want to process in any way and for those we did want to process, we would do our own processing and then hand the call off to the renamed module. Rewriting APIs was an easy way to do pre-processing of commands.
Back in the early 1970s, as an IBM mainframe systems programmer, I copied APIs to add functionality. E.g., the program that read JOB cards was JOBCTLA. If I wanted to extract accounting info from the job card, I would rename the IBM module to JOBCTXA and replace the original with my own version. It would do what I wanted, and then call the IBM version.
My wife and I have been watching the "Great Courses" course on "Cosmology" all summer and think it is a wonderful overview of the subject. We've watched 26 of 36 lessons and will definitely be finishing it. We have already decided that the next course will be "Dark Matter".
FWIW, in the late 1960s and early 1970s is was common to replicate some of IBM's APIs in its DOS and OS operating systems. That was a standard for modifying system behavior. A simple example that I remember was writing renaming IBMs main job control routine JOBCTRLA to something like JOBCTLA2 and writing your own JOBCTRLA which would usually call JOBCTLA2 after it was done with its additional processing but might not. This was how job accounting was first implemented, i.e., reading additional info off job cards to determine who was to be charged for the job.
Most APIs are not unique. In most cases, the same API structure is used for many other purposes in other programs.
But back in the late 1960s there was another reason to copy APIs, and that was to replace the module using it. In a simple example, assume a program called jobctla.dll that has a single API. I might have renamed jobctla.dll, with it's single API, to jobctlax.dll, and then replaced the original with my own jobctla.dll that did something new and eventually passed the same API parameters to the old jobctlax.dll. One common example of this was in early job accounting routines, where I would parse out additional account numbers, user ids and other info in a job card before it was passed on to the original job control processor.
Around 1983, in a meeting with Dr. Ted Hoff, the architect of the first microprocessor at Intel, the 4004, he gave me a perspective on ideas that has stayed with me. He said. "Everyone has ideas. It's only the people who can make something of them that count." From 1989-1999 I ran a software company and my employees used to come to me with great ideas for what the company should do next. Most of these were software developers. I told them that I couldn't commit the resources the idea needed, but I would give them all the leeway I could to make something of the idea themselves. And they hardly ever did.
Programmers have software ideas. Non-programmers have software ideas. Some of each group will succeed in implementing them, but very few.
Acacia's patent examiner never looked at the Object View Broker technology from 1994. That in turn was based on an object-oriented semantic modeling tool called Open Books, released by Open Books, Inc, in Cambridge, MA around 1990. That was written in C and released for the OS/2 platform. It wasn't successful in the market because it came out much too early, but it was a brilliant piece of technology that most prospects didn't understand at that time.
And Open Books itself was based on the Camps Planning Architecture, a LISP-based technology developed by Mitre Corporation for NASA and DOD in the 1980s. If I remember correctly, it was the basis for some of the early space shuttle mission planning system tools because of the way it could tie together different relational databases.
Slashdot Mirror
There are people who don't like the idea of Alexa and those who do. For the first category, the "Don't own one" response is natural. For the second category, your response is natural. As for me, I have a natural bias because I have a voice problem. Not a bad one, but people often have to ask me to repeat something. Alexa would be somewhere between useless and extremely aggravating for me. One of my sons and his wife and kids love Alexa, and the other son and his wife hate it, so I don't know whether my granddaughter would like it or not.
When software is tested the testing should include the ease of a full uninstall, plus some regression testing to be sure the uninstall didn't have side effects. I stopped buying Logitech products about 15 years ago when one uninstall had side effects that took me 8 hours to fix.
But the problem most likely exists in all the newer languages, yet I have never heard of programmers being aware of it or optimizing for it.
In 1973 or 1974 I was the systems programming manager at the National Academy of Sciences after our IBM mainframe had been upgraded to the first version of the OS supporting virtual storage. And many programs, mostly Fortran programs, were running much slower than they used to. The problem was two-dimensional arrays and how they were initialized and searched. If you're looping through the wrong subscript in a big array, you cause a page fault every time you increment it. Flash storage makes that a much smaller problem than it is with disk drives, but I'm sure most programmers today have no idea that this problem exists or how to handle it.
When I turned 16 in 1962 I spent some of the first money from my first job on a shortwave radio and discovered Radio Moscow. Most of what they broadcast was pure propaganda, but it did teach me that in some areas, other points of view were valid. The U.S. government did nothing to stop it in 1962, and now it wants to spend $160 million over two years. I could see spending money to make it harder to find ISIS sites, but Russian fake news is in a different category. Maybe it really does pose more of a danger than ISIS sites, but it's a very different kind of danger. The only thing clear is that propaganda can't be stopped. It's just a matter of degree.
The first time I re-used an API was in 1968, to implement job accounting on an IBM 360/40 running IBM DOS. Their is a huge amount of prior art to re-using an API. To read accounting info added to Job cards, I had to intercept the job card and process it myself before then handing it off to the next step of processing.
Back in the late 1960s and early 1970s, many of IBM's mainframe APIs were public and cloned regularly. One of the first reasons was to perform Job Accounting, i.e., charge for the run of batch programs based on some combination of userid, account number, CPU time and clock time used, etc. For instance, if a Job card was processed by an API in module jobctla.exe, we would rename that IBM module to jobctlx.exe, and write our own jobctla.exe. In our module, we would simply pass on the the API calls we didn't want to process in any way and for those we did want to process, we would do our own processing and then hand the call off to the renamed module. Rewriting APIs was an easy way to do pre-processing of commands.
Back in the early 1970s, as an IBM mainframe systems programmer, I copied APIs to add functionality. E.g., the program that read JOB cards was JOBCTLA. If I wanted to extract accounting info from the job card, I would rename the IBM module to JOBCTXA and replace the original with my own version. It would do what I wanted, and then call the IBM version.
My wife and I have been watching the "Great Courses" course on "Cosmology" all summer and think it is a wonderful overview of the subject. We've watched 26 of 36 lessons and will definitely be finishing it. We have already decided that the next course will be "Dark Matter".
Unfortunately, it's relevant to many, many mission-critical applications that can't be converted easily to run under anything else.
FWIW, in the late 1960s and early 1970s is was common to replicate some of IBM's APIs in its DOS and OS operating systems. That was a standard for modifying system behavior. A simple example that I remember was writing renaming IBMs main job control routine JOBCTRLA to something like JOBCTLA2 and writing your own JOBCTRLA which would usually call JOBCTLA2 after it was done with its additional processing but might not. This was how job accounting was first implemented, i.e., reading additional info off job cards to determine who was to be charged for the job.
Most APIs are not unique. In most cases, the same API structure is used for many other purposes in other programs. But back in the late 1960s there was another reason to copy APIs, and that was to replace the module using it. In a simple example, assume a program called jobctla.dll that has a single API. I might have renamed jobctla.dll, with it's single API, to jobctlax.dll, and then replaced the original with my own jobctla.dll that did something new and eventually passed the same API parameters to the old jobctlax.dll. One common example of this was in early job accounting routines, where I would parse out additional account numbers, user ids and other info in a job card before it was passed on to the original job control processor.
Around 1983, in a meeting with Dr. Ted Hoff, the architect of the first microprocessor at Intel, the 4004, he gave me a perspective on ideas that has stayed with me. He said. "Everyone has ideas. It's only the people who can make something of them that count." From 1989-1999 I ran a software company and my employees used to come to me with great ideas for what the company should do next. Most of these were software developers. I told them that I couldn't commit the resources the idea needed, but I would give them all the leeway I could to make something of the idea themselves. And they hardly ever did. Programmers have software ideas. Non-programmers have software ideas. Some of each group will succeed in implementing them, but very few.
Acacia's patent examiner never looked at the Object View Broker technology from 1994. That in turn was based on an object-oriented semantic modeling tool called Open Books, released by Open Books, Inc, in Cambridge, MA around 1990. That was written in C and released for the OS/2 platform. It wasn't successful in the market because it came out much too early, but it was a brilliant piece of technology that most prospects didn't understand at that time. And Open Books itself was based on the Camps Planning Architecture, a LISP-based technology developed by Mitre Corporation for NASA and DOD in the 1980s. If I remember correctly, it was the basis for some of the early space shuttle mission planning system tools because of the way it could tie together different relational databases.