Matte Matters: I couldn't have said it better.

A recent MacWorld editorial by Rob Griffiths on Apple's glassy displays captures my feelings on this giant step backwards in display technology:

Matte Matters

Just look around you when you're at your office, favorite coffee shop, in an airplane seat, a classroom, or even a library. There are almost always glaring light sources above and behind you. What were Apple's designers thinking? Don't they use their own products?

Final article in series finally published

I forgot to mention that the final article in the 4-part series written by Randy Kahle and me was published a few weeks ago on TheServerSide.com:

A RESTful Core for Web-like Application Flexibility - Part 4

The final article contains links back to the previous articles in the series. Just scroll down the the References section at the very bottom of the article.

Abbreviations and Code Readability

James Leigh, in a recent blog post, makes a couple of good comments on the importance of code readability and the presence of redundancy.

The accompanying poll question, however, (which asks if easily readable code is important) begs the deeper question...of course easily readable code is extremely important but the real question is how to achieve it.

For example, using abbreviations in identifier names is a poor way to make the names shorter and more concise.

Abbreviated names suffer several problems including:

1) ambiguity: is 'getReq' short for getRequest, getRequirement, or getRequisition?

2) cognitive burden: abbreviations requires much more mental effort to remember which fragment of a word is being employed. This "ideolexical" design makes the API seem much more complex and daunting than it should.

As an example, is the abbreviation for 'declareDescription' going to be:

declareDescript,
declareDescrip,
declareDescr,
declareDesc,
declDescrip,
declDescr,
OR
declDesc?

3) lack of consistency: even with only one programmer creating the abbreviated identifier names, it seems highly probably that inconsistencies will creep into the naming scheme, making it harder to use.

4) loss of readability and documentation: longer names are often clearer and document the code better than abbreviations (or shorter names).

In these days of IDEs there is little reason not to use longer, clearer, self-documenting names: it is trivial to start a name and then hit the appropriate completion key. Even if you program in a non-IDE (as I do....I use Emacs a lot of the time) the importance of good names as documentation cannot be over-emphasized and is well worth a tiny bit of extra typing.

Lisp turns 50 this month

"In October 1958, John McCarthy published one in a series of reports about his then ongoing effort for designing a new programming language that would be especially suited for achieving artificial intelligence. That report was the first one to use the name LISP for this new programming language. 50 years later, Lisp is still in use. This year we are celebrating Lisp's 50th birthday."
-from the Lisp50@OOPSLA web page

How the Terrorists Won on 9/11 and Since Then

On this 7th anniversary of 9/11 it is time to finally admit
what most Americans already know in their hearts: that the
terrorists fully achieved their objectives, even beyond
their own wildest dreams. And, since then, unscrupulous men,
corporations, and our own government have helped the
terrorists to continue their success.

Seven years after 9/11, our country has turned against its
own ideals and principles in the name of security, while
ironically justifying its actions as preserving "freedom".

Seven years after 9/11, We are saddled with a costly and
pointless war against a country which had nothing to do with
the attacks. We have a massive new homeland security
bureaucracy which is hard at work trying to impose a
mandatory national ID system. The privacy of millions of
American phone conversations and emails have been secretly
and illegally violated by the government and submissive
corporations. Citizens of other countries have been
arbitrarily labeled as terrorists and jailed for years
without formal charges or a trial. Freedom of travel has
been restricted by secret and erroneous government "watch
lists", to which there is no judicial appeal. And through it
all, government agencies, such as the INS and DHS, have
simply declared themselves to have sweeping new powers.

Joseph Stalin is reputed to have said "When we hang the
capitalists they will sell us the rope" but the terrorists
of 9/11 have turned us against ourselves in a much more
insidious manner; they played upon our fear of death. And
the possibility of death by terrorism is being exaggerated
by those within our country who seek to maintain or expand
their power. The truth is that you are thousands of times
more likely to be killed by a traffic accident than by a
swarthy foreigner with a bomb. Over a quarter of a million
people have died in traffic accidents in the U.S. since 9/11
and yet there is no massive new Department of Automotive
Security.

The terrorists of 9/11 won by instilling fear in the
populace, causing us to give up some of our fundamental
freedoms and rights. It is time to awake from our long
national nightmare and to put our fears into perspective.
It is time to stop being overly afraid and to reject the
erosion of our hard-won liberties. It is time to stop
letting the terrorists win.

Data Duck Typing

Some friends of mine at 1060 Research recently sent me a new version of some software they are working on. After reading one of the XML configuration files, I asked if they had an XML Schema for it (which would define the grammar for legal configurations). The answer was that they did not, as they were moving away from formal grammars and more towards a rule-based approach like Schematron: which uses a set of pattern assertions (rules) for XML validation.

When I thought about this approach, I realized that it is duck typing for data. In object-oriented programming, the use of duck typing means that an object's behavior, rather than its class or inheritance structure, determines its interpretation and usage. The application of rule-based systems to categorize a data file or message is a data-oriented form of duck typing. Using "data duck typing", data is categorized (in this case validated) by having the right elements in the right locations.

Data duck typing means that a data file does not have to fully conform to a specific, rigid grammar as long as some of its parts meet the requirements of the particular rule set used for categorization. Thus, data messages for an application can come in all shapes and sizes as long as they contain the essential required elements with the right structural relationships. Applications which use this approach embody the design principle which says "be lenient in the messages that you accept" and will be much more flexible than applications based on rigid adherence to formal grammars.

crosslink: 5 reasons you don’t really want a jack-of-all-trades developer

Rebecca Murphey has posted an excellent blog entry in which she looks critically at the current employer trend of "asking for the moon":

"5 reasons you don’t really want a jack-of-all-trades developer".

First article in a series posted at TheServerSide.com

Randy Kahle and I are writing a series of articles on Resource Oriented Computing (ROC), which you can think of as REST principles applied to application software development. The first article of the series posted a couple of days ago on TheServerSide.com under the title

"A RESTful Core for Web-like Application Flexibility - Part 1"

Perhaps this title was somehow misleading since the article immediately engendered a passionate (and not always civil nor complementary) debate on various aspects of REST. Most of these were off-topic from the article. As a long time reader of TSS, I expected that something like this could happen. My attitude toward this is to encourage rational discussion, clarify misunderstood points, and ignore misbehavior. This is, BTW, an approach used successfully to deal with patients at mental hospitals.

Google's Protocol Buffers announcement

Nick L., at Google, recently sent the Tucson JUG a link to a blog posting about Google's newly open-sourced Protocol Buffers:

http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html

"Interesting", I thought, "but why didn't you guys just use CORBA and get it over with?"

A snippet in the blog post seems to have anticipated that question:

"OK, I know what you're thinking: "Yet another IDL?" Yes, you could call it that. But, IDLs in general have earned a reputation for being hopelessly complicated."

Complexity sounds like a strawman here.....the major problem with IDLs is that they are built upon a shared definition, which requires all parties to update and recompile when the definition changes. And once you recompile, you've lost the ability of the system to handle the old message format (so versioning is a serious problem unless you plan for it from the beginning).

Of course, these problems are ameliorated when:
1) the IDL is for internal use only and,
2) you control both ends of the conversation,
as Google does...er...did up until now.

I also wonder why Google didn't just use an existing protocol like Hessian:

http://caucho.com/products/hessian.xtp

Perhaps a case of NIH syndrome? (http://en.wikipedia.org/wiki/NIH_syndrome)

Update - 7/20/2008:

Nick responded with these comments:

Google does tend to favor technology we invent ourselves ...[snip]... OTOH, some of the systems we've built ourselves have been blockbuster hits that enable much of what you know as "Google" today.

In response to your comment about backward compatibility, Protocol Buffers are actually explicitly designed so that you can add fields and whatnot and still be able to read in records stored in the old format.

I have to admit, the "WOW" factor on some of Google's software has inspired competition and innovation. So, the next time I'm looking for a binary wire protocol, I'll take a harder look at Protocol Buffers.