Dear DDJ,

Murray Lesser answered my question as to the starting calendar for the Julian Day, when he says it refers to the Julian "proleptic" calendar ("Letters" DDJ, September 1995). I assume that means the use of the Julian calendar algorithm in a range of years where it was not intended. (Incidentally, "Julian Day" and "Julian Date" are not the same thing, as your banner suggested.)

Now I'd like to carry this thing one step further. I've been using the following tried-and-true Basic Gregorian algorithm (unnecessary spaces have been omitted): M=7:Y=1776:N=31:Q=SQR(M-3):FOR J=1TON:D=(Y+Y\4-Y\100+Y\400+2.6*M+1.2)MOD 7+J:LOCATE D\7+6,3*(D MOD 7)+3:?J:NEXT.

I'm not as sure about the following Julian algorithm, and invite readers to check it: M=10:Y=1492:N=31:Q=SQR(M-3):FOR J=1TO N:D=(Y+Y\4+2.6*M+6.2)MOD 7+J:LOCATE D\7+6,3*(D MOD 7)+3:?J:NEXT.

For January or February you must use M=13 or 14 along with the previous year's number with both algorithms. They won't let you use M=1 or 2.

The first algorithm is set up to generate July 1776; the second generates October 1492. Now, 4713 BC= -4712 ad because 1 BC=0 ad. Neither algorithm works with negative year numbers, but we know the Julian calendar repeats every 700 years. So 4713 BC (or -4712 ad) is the same as 188 ad. Thus we use M=13:Y=187:N=31 with the second algorithm for January 4713BC Julian proleptic. The resulting display is:

     
    1   2   3   4   5   6
 7  8   9  10  11  12  13
14 15  16  17  18  19  20
21 22  23  24  25  26  27
28 29  30  31

Murray, is this correct? If not, where did I go wrong?

Homer B. Tilton

Tucson, Arizona

Dear DDJ,

In his November 1995 "Editorial," Jonathan Erickson made several negative comments about Eolas's recent patent-license announcement relating to the implementation and use of "applets" over the World Wide Web.

Rather than representing a "blow to interactivity on the Internet," the University of California patent will be used to encourage the acceptance of a standard API for Web-based interactive applications, preventing the development of a VHS/ Beta-style "API war" between Microsoft, Netscape, Sun, and the like. We are not asking browser companies to pay royalties for developing browsers that can run applets. Rather, we are only requiring that they adhere to a standard "Web-API" that will be defined by a consortium of Eolas licensees. This will accelerate the rapid pace of interactive application development on the Web, not hinder it.

Jonathan's comments go on to imply that since I went to graduate school at the University of Illinois at Urbana-Champaign, and since Mosaic was developed there, that I must have "lucked" into some special knowledge of Web technologies through an alleged "tangential association" with NCSA. This is untrue and misleading. Although I did receive my PhD from UIUC, I had no connection with NCSA at the time. My attendance on campus was from 1984-1989, long before the NCSA folks began work on a Web browser. Furthermore, my degree was from the department of Cell and Structural Biology, for studying the effects of aging on the microvascular system of the heart.

I was deeply involved at the time in computer programming, hypermedia, and image analysis, but this was entirely self-taught and had no connection with NCSA. The only computer-science department courses I ever took included a 1977 course in assembly language on a Cyber mainframe, when I was an undergraduate student, and a 1992 course in supercomputing applications at UIC, where I was on the faculty.

After joining the faculty of the University of Illinois at Chicago in 1989, I began an informal relationship with some of the visualization people at NCSA as part of an HPCC "Grand Challenge" scientific database effort, called the "Visible Embryo Project" (http://bubba.afip.mil) that I directed from 1989 to 1993. I saw Mosaic for the first time when Larry Smarr demonstrated it at an NSF site visit in my lab at UIC in early 1993. I became immediately intrigued with the potential for Mosaic to act as the front end to the Visible Embryo Project database.

Immediately after leaving UIC to take the position of Director of the Center for Knowledge Management at University of California, San Francisco, I began work with Cheong Ang and David Martin on my staff at CKM to enhance Mosaic in various ways. We designed and implemented an API for embedded "inline" applets and demonstrated it to several groups, including many of those who were later involved in projects to add APIs and applets to Web browsers at places like NCSA, Netscape, and Sun. Due to the time delay relating to the patent application, we did not make our announcement as early as we had hoped. We originally planned to release our WebRouser by January 1, 1995. In any case, this work led to the patent that UC applied for in 1994, and was the subject of our press releases in August and September of 1995.

I realize that our first press release arrived very close to your deadline for publication, and that there was not sufficient time for you to check all of the facts related to the editorial. I appreciate the opportunity to clarify some of the history surrounding our announcement.

Michael D. Doyle

Eolas Technologies

Dear DDJ,

In reading Jonathan Erickson's "Editorial" entitled "Bellying Up to the Public Trough" (DDJ, November 1995), I was struck by the somewhat defeatist tone of his closing remark regarding the pending patent for "executable content." Patents (especially pending ones) are challengeable on several grounds, one of which is prior art. That is, the prior existence of substantively related practice or material can nullify a patent claim. The Compton's New Media claim a few years back (essentially granting Compton's a patent on hypertext) comes to mind. As I recall, that patent claim ended up being rejected due to the prior existence of HyperCard and Danny Goodman's original book on the subject.

Not having read the executable-content patent application, and not being a lawyer, I would not want to hazard an opinion on whether the executable-content claims are valid or not. However, I will point out what I believe is substantively similar prior art. If others will do the same, the pending patent may be nullified.

I presume that executable content means that one computer transfers information to another, which is then executed in that other computer, causing actions therein. So why isn't downloading a program from CompuServe executable content? It seems to me to satisfy all the constraints. But maybe not. So, what if I use a telecomm program written in Forth to download Forth code? Maybe I have to download new telecomm Forth source or "macros" for it to count. Or maybe my Forth interpreter has to interpret or compile the downloaded Forth source on the fly for it to be executable content. If so, why? This is clearly all just a range of options on a continuum of behavior. And if none of this is executable content under the patent claim, then how can HotJava be an infringement?

In the Forth world, techniques of dividing execution behavior between a host computer and connected "remote" computers go back quite a ways. Just browsing through my FORML (Forth Modification Laboratory) proceedings for 1991, 1990, and 1989, it was easy to find papers on various aspects of this technique for every year. While the descriptions are given from the point of view of the host machine, they are in every way equivalent to a Web page transferring HotJava "code" to a client machine for local execution, and even communicating back and forth between the newly executing client and the existing host. I can't imagine that the same thing described from a different point of view, the client, would be patentable.

Furthermore, I am fairly sure that these techniques go back even farther than my few FORML proceedings. As a simple example, I recall a Forth-based computer that used a single RS-232 serial line for both console and mass-storage transfers. The serial line was connected to a PC also running Forth, which sent either disk or keyboard data, and received both modified disk data and displayed data. The clever part was that this entire protocol was completely transparent to anything compiled on either computer. Nothing but the lowest-level serial-port drivers knew that there wasn't a real disk connected to the "remote." What does this have to do with executable content? Well, it shows that actions initiated by either computer are not necessarily distinguishable as actually executing on one computer or the other. And the situation may change during the course of program execution, without any change at the higher levels of the program. Which is the whole reason for having executable content in the first place.

Some other executable content areas to explore: the AT&T "Blit" terminal, which could receive and execute code sent to it from the host; smart terminals in general, some of which could receive new executable code from a host computer or could ask for new definitions for actions. And what about diskless workstations?

In short, the way to prevent this executable-content patent from being granted is clear: Challenge its claims on priorart grounds. Since lawyers will certainly be involved, I doubt this can be done inexpensively, but maybe the Electronic Frontier Foundation would be interested. As for doing the research, I'm sure that the formidable resources and denizens of the Internet itself could be put to use. It will benefit us all.

Greg Guerin

Tempe, Arizona

Dear DDJ,

I found the article, "Of Milestones and Men," by Ray Valdes (Dr. Dobb's Developer Update, October 1995) interesting, especially the part regarding evolutionary development. It reminded me of something Gerald Weinberg wrote in the December 1972 edition of Datamation and was later paraphrased by Knuth in his 1974 paper, "Structure Programming with go to Statements," as: "the former regimen of analysis/code/debugging should be replaced by analysis/code/debugging/improving."

As an aside, Knuth also anticipated object technology, specifically, object-based programming languages, over 20 years ago in this quote from the same paper:

...it turns out that a given level of abstraction often involves several related routines and data definitions; for example, when we decide to represent a table in a certain way, we simultaneously want to specify the routines for storing and fetching information from that table. The next generation of languages will probably take into account such related routines.

The four-foot-high stack of project documentation that Ray mentions brought back similar memories. I was part of a three-man team that designed an integrated development environment for a major computer manufacturer about eight years ago. We cranked out a lot of documentation. The project leader wanted anything and everything written down although we didn't have a particularly well-defined development process. The result was a one-foot-high stack of documentation--all prose, no diagrams. He proudly displayed the stacks sitting in front of each reviewer at the interdepartmental design review. I shook my head, knowing that this ostensibly impressive volume rendered the design unreviewable.

Paul Long

Dear DDJ,

In the September 1995 "Letters" section of DDJ, Dwight Keeve posed a question regarding prime numbers. The list of primes up to 100 that he refers to is 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97. The number 57, which Dwight included, is divisible by 3 and therefore cannot be prime. The correct sequence p(p(n)) is: 3, 5, 11, 17, 31, 41, 59, 67, 83,....

Daniel Pfeffer

Netanya, Israel

Dear DDJ,

I enjoyed the "Programmer's Bookshelf" entitled "Nontraditional Education Alternatives," by Jonathan Erickson (DDJ, September 1995), but my local bookstore hasn't been able to get an address or phone number for Professional Publications, the publisher of High-Technology Degree Alternatives. Can you help?

Kevin Light