Absurdly defined 'inventions' threaten scripting's ease of
expression
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.
Application Development 
