There's a bit of a buzz on the interwebs, that Microsoft's project to compete with the iPhone is having some problems.
What I find ironic is that they decided to call this project "Pink". Apple once had a project with the same name, which was to be the 'new' operating system for the Macintosh, as a replacement for System 7. Pink was to be an operating system built around an application framework which was to provide the API. This was a popular 'strategic' idea in those days, Apple, IBM and, yes even Microsoft were pursuing it.
Apple's Pink attempted to take the ideas from MacApp which had just made the transition from Object Pascal to C++, and grow them into an operating system. Larry Tesler had advocated this and John Sculley, then Apple's presidency during the "inter-regnum" period, had sunk lots of money into the project which was headquartered in the original building where the Macintosh had been developed, when it was the lair of the "Dread Pirate" Job's merry band. The project had gotten bogged down, and Sculley was on the verge of killing it, unless other 'investors' could be found. Since IBM was enamored with such things back then, a task-force was dispatched to Cupertino to look at Pink. I was tapped for the task-force because of my expertise in Object Oriented programming and visibility due to my connections with VisualAge and Smalltalk, Despite whatever technical misgivings which might have resulted, in other words they didn't listen to me, IBM bought in. The result was an alliance which formed two jointly companies which were jointly owned by IBM and Apple, Kaleida which focused on multi-media, and Taligent led by IBM Executive Joe Gugliemi, where Pink died a slow death. The longest term impact of the alliance was that it got Apple to agree to switching from the Motorola 68K family of microprocessors, which had been used in Macs until then, to the IBM PowerPC. But, since Motorola was a large IBM customer, IBM licensed the PowerPC to them, so that most Macs used IBM architected chips actually produced by Motorola until the "Dread" Pirate came back and eventually switched to using Intel chips.
Of course Microsoft's "Pink" has no relation to Apple's other than the name, but I can't help but finding this all ironic.
In my rather lengthy career, I've had the opportunity to work with some incredible people. As someone who started programming in the early 1970s, and joined IBM in 1974, I found myself in the midst of both the pioneers of the beginning of the post-war boom in computer technology, as well as up and comers of my and later generations.
While I've already blogged about a few of these people, like "Big Dave" Thomas I thought it might be interesting to start an occasional series of articles about people I've met, worked with, been influenced by, and perhaps influenced myself over the years.
One of those who influenced me in the formative years of my career was John Cocke. I can honestly say that I had absolutely no influence on him. His name may not be well known to many programmers these days, but we owe an immense debt to his intelligence and imagination.
I might have run into John for the first time in the summer of 1973 during my internship at IBM before my senior year in college. I was working in White Plains NY, for a divisional headquarters department, but part of that job involved trips up to the Thomas J. Watson Research Center in Yorktown, NY, to use the IBM 360 Model 91 which was there. This was IBM's biggest, most powerful computer at the time, and there were very few of them outside of IBM and places like NASA. It might have been somewhat later after I'd become a full-time IBMer a few miles north of Watson, up the Taconic State Parkway in Yorktown Heights at the Advanced Systems Development Division, which served as a kind of organizational bridge between Research and the Systems Development Division in Poughkeepsie where the IBM mainframes were developed and built.
T.J. Watson is an impressive piece of architecture, an arc which sweeps out what was a quarter of a circle then (it's been expanded since). The front of the three story building is all window, with a wide corridor. The offices are set inside along radial aisles.
To get a good perspective on John Cocke and his personality, you might want to have a look at this retrospective by some of his friends, made a few years before his retirement. As mentioned in the video, John would almost never be in his office, he'd wander those corridors and strike up conversations with folks. He would often be seen in his tan raincoat, probably a London Fog, with its shabby hem, always with a cigarette in his fingers. One of the reasons I say that he influenced me, was because like Alan Kay wrote about me, John Cocke was the least IBM-like IBMer who I ever saw.
So who, you might be asking, particularly if you didn't take the time to watch that video, was this John Cocke. His New York Times obituary gives some insight. He started with IBM in 1956, and worked on the IBM 7030 a.k.a. Stretch computer, which was IBM's first transistorized computer, and the world's fastest computer from it's debut in 1961 until the CDC 6600 eclipsed it in 1964.
But Mr. Cocke was not just a hardware guy, he became an expert on optimizing compilers. And that led to one of my fondest memories of him. I was in the halls of Watson one day when Cocke was holding forth, and said that he had patched the IBM FORTRAN compiler to accept a half dozen or more ways of spelling the reserved word CONTINUE, because "no program I wrote was going to tell me that I didn't know how to spell!" I can still hear him saying it in his soft southern accent, which I'd always thought was Virginian, until I just today found that he was a native of Charlotte.
He is probably best known as the father of Reduced Instruction Set Computers (or RISC architectures). His compiler work along with other IBMers like Fran Allen (who features prominently in that video, and became the first woman to gain the A.C.M Turing award a couple of years ago), and others, made him an expert on optimization and parallelization, and the realization that a machine which had simpler instructions making it easier for the compiler to produce optimized sequences, could be faster than a machine with complex instructions and addressing modes.
John Cocke died at the age 77 in 2002.
T.J. Watson was a hotbed of some of the people I want to write about in this series of articles, some of them are in that video, some aren't. I'll have to see who I get moved to write about next, and when.
My buddy Adam Williams @aiwilliams tweeted this link., which is, at it's roots, about the dangers of doing more than should be done.
Feature creep is one temptation which leads to overdoing, and thus doing the wrong thing. Another is obsessively trying to remove all defects. As they say "Perfect is the enemy of good."
Which reminds me of an old chestnut from my earler days. I've provided some footnotes for younger readers
The Perfect Program
no program's that perfect" they said with a shrug. "the client is happy-- what's one little bug?" but he was determined the others went home he dug out the flow chart (1) deserted. alone. night passed into morning the room was quite littered with core dumps (2) and punch cards (3). "i'm closer." he tittered. chain smoking, cold coffee. logic, deduction. "i've got it!" he cried. just change one instruction. then change two, then three more as year followed year. and strangers would comment "is that guy still here?" he died at the console (4) of hunger and thirst next day he was buried face down, nine edge first. (5)
Footnotes
- A flow chart was a primitive form of program representation, comprising variously shaped boxes connected by lines and indicating the control-flow of a program. This was in the days when programmers wanted to be like engineers, and we all know that engineers draw stuff on big draft boards before they build anything. This idea lives on in ideas like UML. It's still a bad idea.
- Back in the days before laptops, behavior driven design and continuous testing, programmers would submit their programs to the big computer locked up in a room and attended by priests called operators. The priests would offer the program up to the computer, and return with a reply. If something went wrong, you got back a large stack of paper which showed a picture of what was inside the computer when things went south. Back then the inside of the computer had memory comprised of little magnetic donuts called cores woven into a matrix with wires, so memory was called "core" A core dump was that picture of what was in the computer. This was as close as we had to a debugger back then.
- Punch cards were strangely shaped index cards, the shape was something like a widescreen TV compared to a normal index card, three of the corners were rounded and the upper left corner was beveled.
Each card held 80 whole twelve bit words, or the equivalent of 120 bytes. Each bit was a hole bit since it was represented by the presence or absence of a hole in a particular row or column. Each column was a word. In most cases using all of the bits on a card was rare. Usually each column encoded a character, in some archaic encoding scheme like EBCDIC.
Programs were kept as large stacks of these cards, and these stacks would be fed to the big computer through a machine called a card reader. The holes would be punched into the cards using a kind of typewriter (a primitive kind of laptop/desktop comprising a keyboard and a printer) called a keypunch, which instead of printing what you typed on paper, punched it into cards.
Usually the computer would output to a printer, but some older printers output back to cards through another machine named, strangely enough a card punch. In these cases there was a separate machine detached from the computer which could read decks of cards and print their contents to a printer.
If you were really lucky, the computer would combine the card reader and punch with one input hopper. You would put your program deck into the hopper, followed by (carefully counted) blank cards for the output. One fun experience was to put your program into the hopper when a program was running with insufficient blank cards before you, in which case the machine would happily overpunch part or all of your program with the first guy's output.
For those who fell for static typing, there were specially printed cards for different programming languages, here's a FORTRAN card there were also COBOL cards, although the computer and card readers used duck typing, they really didn't care what was printed on the card, only the holes, the whole holes and nothing but the holes.
- The console was the machine through which the priests, and sometimes programmers, directly interacted with the big computer. It was a rare privilege for a mere programmer to have access to the console, it usually happened late at night on third shift when the priests wanted to sleep. What no, terminals/workstations/laptops you say! ha!
- A reference back to punch cards. Each row of bits on the card had a number. For some good reason, the top two rows had the numbers 12 and 11 and were called zone rows. The non-zone The remaining rows were numbered 0 through 9 with 9 at the bottom. A card deck could be put into a reader, punch, or reader/punch in four orientations. The deck could be inserted face (printed) side down, or face side up, and with the 12 or the 9 edge entering the machine first, hence "face down, nine-edge first." It was important to get this right, even more so when submitting a job than burying a dead programmer.
Gawd how I miss the old days!
NOT
I just got an email this morning informing me that my e-mail entry won a contest on boingboing gadgetsto win an original copy of each of the original Xerox Parc Smalltalk-72 and Alto manuals.
I'm looking forward to adding these to my collection of tech mementos.
The winning entry pointed to two articles I'd written here about Alan Kay
- Alan on the meaning of OOP
- An article on a Business Week comic strip about Alan and the invention of the Dynabook, which triggered some memories of some other past associations
And I also threw in this scan of one of my current treasured mementos. This is an autograph page from the supplemental programming manual for Digitalk Smalltalk/V PM which was presented to me at Digitalk's developers conference. I'd been working closely with Digitalk on the release in my capacity as their liaison with IBM, and I gave a talk there.
Alan was also a speaker there. Alan had been instrumental in getting Digitalk to change the name of their product from Methods (which they'd picked to avoid issues with Xerox) to Smalltalk/V. I'm pretty sure that I'd already met Alan at one or two IBM internal OOP conferences. So Alan signed too, and I've highlighted his personalized autograph.
If you want you can click on the picture for a larger view.
A couple of weeks ago, the RailsEnvy podcast covered RiCal.
So I got the honor of joining the long list of Rubyists who have had the pronunciation of their names butchered by either Jason or Gregg. That's OK, I love both of you jokers.
On the podcast it's pronounced something like din a tal.
Yes, I've heard that one before, less commonly than dee natalie, and many other attempts.
My last name is Italian. I sometimes joke that since my father was of Italian descent, my mother is of German descent, and I speak a bit of French, I am in effect Swiss.
Now I've always pronounced my last name dee nah TAH lee, or in ipa dinɑː'tɑːli . That's the way Grandpa said it.
I understand that, by normal rules of Italian pronunciation it should be more like day-nah-tah-lee, (deɪnɑː'ɑːli ). We always figured that either Grandpa, or Great Grandpa Biaggio, who brought Grandpa to New York in 1897], when Grandpa was named Guiseppe instead of Joseph, and was 6 years old, pronounced it as if it were di Natale, since that's the more noble form of the name.
On the other hand, my second cousin, Lou Alfano (the family genealogist) has uncovered some evidence that it might have been a spelling change, perhaps the immigrations officer at Ellis Island recorded the way he heard "di Natale" as "denatale". I do remember that the crest here, which I ripped off from Lou's page, from my youth, Grandpa had a rather large plywood shield painted with that crest in his cellar.
I love my last name, and dealing with other folks trying to pronounce it has been a source of amusement.
Mispronunciations were rare when I lived in New York and Connecticut, where Italians were more common, the most frequent mispronunciation up there in my youth was de-nat-ah-lee, as in Natalie Woods. When we told someone our name, they were likely to either write it correctly, or as diNatale if they were Italian themselves.
When I moved to North Carolina, the variations grew, and so did the spellings. I don't know how many times I made a telephone reservation at a hotel or a restaurant, and upon arrival discovered that they couldn't find the reservation until they looked it up under "Tolley." They'd misheard it as "Dina Tolley." It got to where some of my friends and their kids took to jokingly calling my wife and me "Mr. and Mrs. Tolley." Heck, we did that ourselves.
Yesterday I took a few hours and attended an intro to SolidWorks at TechShop Durham. Then today Kent tweeted about how JUnit Max has been faring, and it got me thinking about the state of the business in software for programmers.
For those of you unfamiliar with SolidWorks, it's a 3-D Parametric Modeling program, one of the newer and most popular CAD programs. If you are a fan of the TV Show American Chopper it's the program which Jason Pohl uses to design the bikes. It has been gradually taking over the 3D mechanical CAD market, replacing old leaders like AutoCad and ProEngineer. My main interest is as a hobbyist. I've been very interested in industrial technology since I was a kid, and I like to build scale models. I'd love to have SolidWorks to play with on my own, but it's out of my price range.
SolidWorks is owned by a big corporation Dassault Systems, and it's sold through a network of VARs. Yesterdays session was given by a support engineer from the local VAR. I haven't seen an 'official' price for a license, I think they get negotiated by businesses, but I understand that the cost of a single SolidWorks 'seat' is $5,000 to $10,000 with a yearly maintenance fee of around $1000 which gets you yearly upgrades and other goodies. There's also an 'educational' license which is carefully controlled.
And that price seems well worth it to a lot of companies.
This reminds me of the way the software development tools business used to be. IBM and others got big bucks for development seat licenses for compilers, ides and other tools, sold by salesmen and supported by customer support engineers. One of the reasons Smalltalk had a hard time gaining a foothold was that ObjectWorks and VisualAge licenses were very expensive, even Digitalk Smalltalk which was targeted at the same market as Borland TurboPascal cost a few hundred bucks.
Imagine there was a time when folks actually PAID for compilers for PCs!
Nowadays that model is harder and harder to support. Most of the tools programmers use, at least the programmers I hang with, are open source, and freely available. Every once in a while a program like TextMate will pry €39 or so from a programmer's pocket, but most of us get by living off the fat of the open source land.
Unlike the proverbial shoe maker's children, it's not that we don't have any shoes, we've got all the free shoes we want.
JUnit Max, as I understand it, is an Eclipse plugin which acts as a Java equivalent to Ruby's autotest, except on steroids. While autotest runs the most recently failing test until it passes then runs all of the tests, JUnit Max queues up retests based on how recently they failed. Knowing Kent as I do, I'm sure that it's a great tool, very well crafted, but I'm just not into Java anymore, so I don't have direct experience.
Kent is asking a measly $2 per month for JUnit (at least while it's in its beta version), but judging from his tweet this morning, he's disappointed at the number of takers so far.
I admit it, we programmers tend to be a miserly lot, and a lot of us end up doing a lot of code for the love of it. We might ask for a small fee, or put up a "tip-jar" like the one on the RiCal github page but it doesn't often amount to much monetary reward.
Boy, I wish I could come up with the next SolidWorks!
They’ll still have the fastest Java VM for Nehalem.
The rumors about IBM acquiring Sun Microsystems have been running rampant the past several days. I remember when we used to talk about that all the time.
When I was working at OTI, I was on the edges of the relationship between IBM and Sun which had been forged over Java.
A lot of the tensions were due to different goals. In the part of IBM/OTI where I worked, there was great interest in using Java for embedded applications. The IBM J9 VM came out of OTI’s legacy in building embeddable Smalltalk VMs. J9 provided a modular implementation, so the footprint could be controlled by choosing options and selecting one of a number of different core class libraries of different sizes. This was great for the embedded developer giving lots of control, but flew in the face of Sun’s “Write once, run anywhere” Java slogan. This led to a lot of friction with Sun trying to control things via the JCP. As I understand it, IBM and Sun had negotiated a special relationship over Java which gave IBM some freedom of action outside of normal Sun terms, but IBM always played by the Sun rules as much as possible.
At times, we, as developers rather than business strategists, used to wonder why IBM didn’t just buy Sun, particularly when at it is now, their stock valuation would make it a bargan.
Maybe the time has come. Maybe not.
I just discovered that my old friend, Ward Cunningham has started putting some short interviews, and “video essays” up on YouTube
In the embedded video above, Ward relates how he came up with the metaphor of debt to explain the need for refactoring in interative development. The key insight is that you can proceed faster with an incomplete knowledge of the problem you are solving, and learn as you go. In many cases this is essential because for many problems the problem itself changes as implementation proceeds, because of effects like new feedback from users once they see the system starting to emerge. Ward compares implementation with incomplete knowledge to working with borrowed money. As the system implementation proceeds, the assumptions made on incomplete or out of date knowledge, which drove the design, or “architecture” if you prefer, of the system, start to make implementation of the more complete or evolved requirements progressively harder. In the debt metaphor, this increased cost of making progress corresponds to paying interest on the loan. Refactoring is a process of redesigning the software to reflect this new problem knowledge, without breaking it, thus “re-financing” the system.
Before I’d heard Ward express this metaphor, I’d come up with another for the same idea. One of my hobbies is metalworking. I saw an evolving system as a piece of metal which starts out as flexible and malleable. But like metal, as you start to form it by hammering, and bending, and other operations, it starts to “work-harden.” This means that the metal becomes more and more resistant to further shaping, because of local changes to it’s crystal structure. Eventually it resists all further efforts, often by failing with a stress fracture. This is why you can take a piece of, say copper, and bend it back and forth several times until it finally breaks at the bend.
In metalworking, you can use a process called annealing which returns the metal to a ductile, maleable state. Of course the analogy here is to refactoring.
I still like both metaphors, I tend to use my work hardening/annealing metaphor when talking to programmers, and Ward’s debt metaphor when talking to business people (the “gold donors.”)
Better late than never
A few weeks back Jared Richardson interviewed me about the talk I gave at the inaugural RubyRX No Fluff, Just Stuff’s first foray into a Ruby oriented conference.
Although this was supposed to be published before the conference, it’s just now made it to the DZone web site. I hope you enjoy it.
When I retired from IBM some years ago, I had a couple of pending patent applications. I always wondered if and when the
patent(s) issued, whether or not I would hear about it.
Early this week, I got notification that one of the applications had been granted last Tuesday, and I’m now recorded as the inventor of
US Patent #7,464,384 “Method for inter-object communication”
Word came not from IBM, but from an outfit which sells plaques commemorating the issuance of patents. I still haven’t heard
and don’t know if I ever will, from IBM.
The road to patent issue can be long and winding. I’ve looked at transaction history for this patent on the US Patent office’s web site
and see this history (some details omitted):
- 03-14-2002
- Application filed
- 11-02-2004
- Non-Final Rejection mailed to IBM
- 02-01-2005
- IBM response after Non-Final Action
- 06-10-2005
- A second Non-Final Rejection mailed
- 08-01-2005
- IBM responds again
- 09-28-2005
- Patent office mails a Final Rejection
- 11-16-2005
- IBM submits an Amendment after Final Rejection
- 12-09-2005
- Patent office mails an Mail Advisory Action
- 12-14-2005
- IBM files Notice of Appeal
- 02-14-2006
- Appeal Brief Filed
- 06-06-2006
- Yet another Non-Final Rejection
- 09-06-2006
- IBM files another Notice of Appeal
- 11-06-2006
- Appeal Brief Filed
- 12-06-2006
- Appeal Forwarded to Examiner
- 12-06-2006
- Appeal Brief Review Complete – a quick review!
- 02-26-2007
- Another Non-Final Rejection
- 05-24-2007
- Another response from IBM
- 08-02-2007
- A second Final Rejection
What had been going on was an argument between the Patent examiner, and the lawyer representing IBM about the claims in the patent application.
The claims are what gives a patent force. Each claim can be defended individually. Most patents contain one or more series of claims
starting with specific claims followed by more and more general claims. For example if you had invented the Car, you might first
claim a motor vehicle with four wheels, powered by an internal combustion gasoline engine. A broader claim might be the invention
described in the first claim with any kind of internal combustion engine, then with any kind of engine. Other variations might hinge
on the number of wheels, etc. The original patent application contained 30 claims, and at this point the Patent Examiner had rejected
all of them.
- 11-05-2007
- And another Notice of Appeal Filed
- 11-05-2007
- Request for Pre-Appeal Conference Filed
- 12-20-2007
- Pre-Appeals Conference Decision – Reopen Prosecution
- 12-21-2007
- Mail Appeals conf. Reopen Prosec.
IBM submitted a detailed defense of the claims in the patent.
- 12-21-2007
- Date Forwarded to Examiner
- 12-28-2007
- Mail Non-Final Rejection
- 04-04-2008
- Request for Extension of Time – Granted
- 04-04-2008
- Response after Non-Final Action
- 05-09-2008
- Date Forwarded to Examiner
- 07-15-2008
- Mail Notice of Allowance
IBM’s attorney apparently finally convinced the Patent examiner to accept the most specific claim in the patent. I assume that this is
the point at which it was determined that the patent would be issued.
So it took six years and four months to convince the Patent office of the validity of the application, and just shy of fiver more months before the patent issued.
What a trip!
And to be honest, I’m rather ambivalent on the whole issue of software patents