Home | About AutomatingInvention.com | About Robert Plotkin | The Genie in the Machine | Contact | Disclosures

February 26, 2008

Upcoming talk on automating invention at the MIT Technology and Culture Forum

I will be giving a talk on computer-automated inventing and its philosophical and ethical implications at MIT on Thursday, March 6 from 4:30pm-6pm in Room E51-315 (campus map). In the talk I will give a preview of some of the examples of computer-automated inventing that I will describe in more detail in my upcoming book, and explain how the inventive processes behind them are already raising new questions about what it means to be an inventor and the ethical responsibilities of inventors.

The talk is sponsored by the MIT Technology and Culture Forum.

Posted by Robert at 8:00 AM | Comments (0)
category: Ethics | Philosophy of Computing

October 31, 2005

Defining "software"

I often find people defining computer hardware as the "physical" part of a computer and software as either the "intangible" part of the computer or as "instructions" stored in the hardware. Although there's nothing wrong with these definitions per se, they leave out something important and might actually impede our ability to understand the importance of computer programs in the future.

I think it is worthwhile to think of hardware as the fixed part of a computer and software as the variable part. I like to use the following analogy: hardware is to software as a drill is to a drill bit. A drill is a drill; it doesn't change. To make the drill perform different functions, you attach different bits to it. The drill is fixed and the bits are variable, just like hardware and software, respectively. When you buy a computer, you buy the fixed hardware, which you can make perform different functions by attaching (installing) different software to it.

What I find useful about this analogy is that it makes clear that we are not talking here about the physical form taken by the drill and its bits -- both are quite physical. And the same is true in the case of hardware and software -- both are physical if what we are talking about are components of a physical computer. The web browser that you are using to read this blog is physical; it consists of electrical signals in your computer. Even if you take issue with the physicality of electrical signals, tomorrow's molecular computers will convince you that software is a physical thing.

Therefore, if the law is to treat software differently than hardware or anything else, the difference must stem from something other than the fact that software is not "physical." I've tried elsewhere in this blog to explore what else makes software different, and the implications of those differences for the law.

Posted by Robert at 4:24 PM | Comments (1)
category: Philosophy of Computing

July 19, 2005

Is it harder to think in the abstract than in specifics?

Glenn Reynolds (a.k.a. "Instapundit") criticizes Daniel Pink's A Whole New Mind for encouraging people, perhaps indirectly, to seek out "holistic" and "right-brain" approaches to problems that will be appealing because they seem "easier than those tiresome traditional linear approaches with all their steps, increments, and well, work." Reynolds cautions that:

[G]enius . . . has more to do with perspiration than inspiration. And while our workplaces may be too unfriendly to right brain thinking, they're a lot friendlier than they used to be. . . . In fact, it's arguable that most business management could benefit from a more traditional approach to balance sheets and bottom lines: More thinking inside the Income Statement, and less effort to think "outside the box."

I think part of Reynolds' criticism stems from a problem with Pink's distinction between "logical" and "holistic" modes of thought. I've said before that I think Pink's analysis is insightful and well worth reading, but this distinction has limitations.

Consider instead a different distinction, that between thinking at different levels of abstraction (see previous posting). Imagine an engineer faced with the problem of designing an electronic calculator. She might start with low-level electronic components, such as resistors and capacitors, and attempt to combine them together into a calculator. This would require a detailed understanding of circuit design at a low level of abstraction (i.e., a high level of specificity).

If, however, the engineer had available existing components for adding, multiplying, and performing other arithmetic functions, she could design a calculator by combining those existing components together. She might not need to know anything about the internal guts (e.g., resistors and capacitors) of the components she used. This would require an understanding of circuit design at a higher level of abstraction.

Finally, if the engineer had access to an existing electronic calculator, she would not need to know anything about circuit design. But imagine that she programs the calculator to not only perform arithmetic, but also to solve equations. This would require a yet more abstract understanding of mathematics and programming.

Is it any "harder" or "easier" to solve problems at any one of these levels of abstraction than at the other? Yes, but only in the sense that it is easier to make an existing calculator add 2+2 than it is to design from scratch a calculator for adding 2+2.

But that is comparing apples and oranges. Once the calculator exists, it poses problems at a higher level of abstraction that are just as complex in their own right as the problems that existed at the lower level of abstraction before the calculator was built. Science and engineering are fractal in this way; there is no loss in resolution as you move among layers of abstraction.

Let me take a stab at using this analysis to harmonize Pink's original argument and Reynolds' criticism of it. We need to use both "logical" ("left-brain") thinking and "holistic" ("right-brain") thinking at every layer of abstraction. As Pink's Abundance, Asia, and Automation make it impossible for people in the U.S. to compete at their current level of abstraction using logical thinking alone, they will either need to use holistic thinking at that level of abstraction, or move up a level, where it will be possible for them to succeed using only logical thinking until the same forces kick in at that level at some point in the future. Then the whole game starts over again, and Pink will be able to write about the Neo-Conceptual Age and its progeny, ad infinitum.

Posted by Robert at 10:22 AM | Comments (0)
category: Human Creativity | Philosophy of Computing

June 28, 2005

Patent Law and Layers of Abstraction

In his talk yesterday (see my previous posting), Drew Endy talked about how some of his work is shifing towards designing biological systems at higher layers of abstraction. The idea of "layers" (or "levels") of abstraction is deeply engrained in the way engineers, and computer scientists in particular, think about systems. I've argued elsewhere that some of the problems with software patents could be fixed if patent law recognized the distinction between different layers of abstraction and focused its attention on the layer(s) where innovation is actually occurring in a particular field.

If you're not familiar with the concept of "layers of abstraction," imagine that you're designing a toaster. You might design the toaster as follows:

1. Start with the very high-level (i.e., very abstract) goal of designing a machine to toast bread.
2. Then you might identify the functions that the toaster needs to be able to perform, such as holding bread, heating bread, detecting when the bread has been toasted to the desired darkness, and ejecting the bread. Identifying these functions is called "functional design."
3. Then you might design the physical components for performing the functions described above, such as heating elements for heating the bread and springs for ejecting the bread. Designing these components is called "physical design" and is often what we think of as "inventing."

Once you've designed and built your toaster, there is of course only a single physical toaster. But you can still think about and describe the toaster in terms of its "physical layer" (its physical components) and its "functional layer" (the functions it performs). Machines and other systems are often designed and described in terms of many such layers in addition to the physical and functional.

It is possible to innovate in any of these layers. Mechanical engineers traditionally have innovated in the physical layer by designing new physical components or new combinations of existing physical components. Computer programmers traditionally have innovated in the functional layer by writing programs consisting of new functions or new combinations of existing functions.

But physical innovation holds a special place in patent law, as the result of assumptions that are no longer valid. One example of patent law's attachment to the physical layer is section 112, paragraph 6 of the U.S. patent statute, which says that patent claims written using functional language are to be limited in scope to the specific physical structure of the invention as described elsewhere in the patent. This section hard-wires the physical layer as the upper limit on the layer of abstraction at which an invention may be claimed.

This legal distinction between the physical and functional layers made sense when the focus of most innovation was the physical layer, and when there were no computers or other means available to automatically produce physical implementations of innovations described at higher levels of abstraction. But these assumptions are no longer valid, and patent law needs to become more flexible in response by focusing protection on the layer(s) of abstraction at which innovation is actually occurring in the real world. In future postings on this site I will explore ways in which patent law could be reformed to achieve this goal. I will also consider potential problems with such reforms.

Posted by Robert at 9:31 AM | Comments (0)
category: Philosophy of Computing | Software Patents