Patents Should Meet BASIC Tests of Reason

 
 
By Peter Coffee  |  Posted 2004-11-22
 
 
 

It sounded like the worst sort of sophomoric parody, worthy of the most rabidly anti-Microsoft blog, but it turned out to be the literal truth. A team of three inventors, two of whom are publicly identified as "members of the Visual Basic team," has applied (in a filing published late last week) for a U.S. patent on "A system for determining if two operands point to different locations in memory"—in short words, on the IsNot operator in "BASIC-derived" programming languages.

The fundamental idea, of course, is the same as that of the eq  predicate in Lisp, which determines whether two symbolic expressions evaluate to the same actual object rather than merely to objects with identical values, or the similarly semanticized == operator in Prolog. Oh, excuse me, I guess the patentable novelty is in having a single inequality operator that is the logical complement of Lisps eq or Prologs ==. Prolog, though, already had \==—and for that matter, C already had the !=  operator whose allowable operands include pairs of pointers.

This seems like an obvious setup for a dumb joke with a nursery-rhyme punch line, perhaps "Peter promptly proffered pounds of programmers prior practice," except that Im not making up this stuff.

As often is the case with legal documents, whats perhaps most interesting is not the self-evident silliness of the top-line claims, but rather the invidious implications of the footnotes. Some developers, for example, might dismiss this episode as irrelevant to their interests due to the putative focus on "BASIC-derived languages." Perhaps their threat assessment will change when they realize that Paragraph 42 of the Description section of the patent application lists Borlands Pascal-based Delphi among the so-called "BASIC-like or BASIC-derivative" languages. Excuse me?

I also invite the attention of your legal team to Paragraph 55 of the Description, reading in part: "The various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both... [W]hen the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention... [P]rograms that may utilize...the present invention...are preferably implemented in a high level procedural or object oriented programming language... However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations." Your lawyers will doubtless advise you as to whether this incredibly sweeping language places your work or your products at risk of infringement.

Oh, you dont have a legal team? Gee, thats a shame. I guess that makes life much more interesting.

Click here to read a Nov. 9 column by eWEEK Labs Director Jim Rapoza about software patents gone bad.

Im sure that many others will dissect, at length, the patentability of IsNot. Let me, then, jump ahead to the larger question of how were ever going to get a dramatic improvement in programmer productivity.

The connection is closer than it might seem. I spent two days, last week, at an IBM workshop on the subject of a Services Science—bearing the same relationship to a service-based economy that operations research, perhaps, might be said to bear to a manufacturing economy. In opening remarks on the first day, IBM Fellow Mark Dean alluded to the need for a two-order-of-magnitude improvement in services productivity over the next few years, merely to meet IBMs own needs for satisfying its clients without a huge expansion of its services staff.

Its notoriously difficult to improve the productivity of services, but one vital way to do it is by capturing expertise and automating its availability to those in need—which typically means writing software. One of the biggest boons to software productivity has been the advent of powerful scripting languages such as Python, Perl, Ruby, and many others. I agree with German developer Falk Bruegmann when he says that "we should expect to see a trend from languages that put the main emphasis on efficiency to languages which put their emphasis on productivity and scalability... I expect dynamically typed languages traditionally used for scripting to be enhanced for better scalability by better package systems, better tools or improvements in the type system... Such "enhanced" scripting languages are well-positioned to take away market share from traditional system languages." Three for three, it seems to me.

This desirable trend could be thwarted, though, if languages are prevented from evolving in the most natural possible way toward whatever people find to be productive. Elaborate workarounds, inspired by concerns about infringing on patents held by deep-pocketed competitors, pervert the aims of the Constitutional power to grant patents and copyrights in the first place. That Congressional power, as Ive noted before, is the only one that the Constitution seems to feel a need to defend with a statement of purpose: namely, "to promote the progress of science and useful arts."

Granting patents on obvious means of expressing our ideas, merely because theyve been dressed up in dubious computer-science bafflegab, IsNot (ahem) a promotion of progress.

The eWEEK Excellence Awards for 2004 are now accepting entries. The deadline for submitting entries is Jan. 31, 2005. For more information go to www.excellenceawardsonline.com.

Tell me where youre looking for programming productivity gains at peter_coffee@ziffdavis.com

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.

Rocket Fuel