Between a Rock and a Hard Place

Tim Brookins writes...

In case you've been living under a rock, Longhorn is platform for the next decade...

Software developers live to ship code. So delaying the first release of MBF is painful. However, as a Software Architect, I am absolutely convinced that this was the right choice. Shipping part of MBF in Whidbey and part in Longhorn would have created a system which spans two technology eras.

Interesting. There are several potential messages in this statement but I am not sure how a customer deciphers which should be heeded.

Objects and Processes

Ian Bicking on objects and processes (when processes are done right)...

That's when I thought about Erlang. Instead of objects, Erland has processes, and you send messages between processes. It seems obvious, but when I'd looked at Erlang before the parallel hadn't occurred to me. In that light Erlang processes make much more sense to me.

Something about Erlang design... if you need state, like an "object" would, then put it in its own process. Asynchronous messages to update the state and return state information. Like many small "databases" on the order of a table or so running in their own process.

Study the Work of Others

From Harold Carr's talk at the University of Utah...

• No literature search in industry.
• No encouragement for deep knowledge (want "code monkeys")
• To climb ladder encouraged to manage or "architect" versus doing "the" work

---

• Great painters and writers don't delegate
• They continue to do the work themselves
• And they continue to study the works of others

Not long after writing this, I come across an item from James Robertson with more ever-present evidence of this sad observation.

Adventure Ahead

Robert X. Cringely writes...

Right now, there is in the U.S. venture capital community about $25 billion that remains univested from funds that will end their lifespans in the next 12-18 months. If the VCs return those funds to investors they'll also have to return $3 billion in already-spent management fees. Alternatively, they can invest the money -- even if they invest it in bad deals -- and NOT have to cough-up that $3 billion.

...so get ready for the most furious venture investing cycle in history.

Inexplicable: Truth Held Hostage

Where's the outrage over the recent 9/11 disclosure?

In April last year, President Bush said, "Had I any inkling whatsoever that the people were going to fly airplanes into buildings, we would have moved heaven and earth to save the country. ..." The 9/11 commission report apparently found that there were indeed such inklings, which should have "raised alarms about the growing terrorist threat to civil aviation throughout the 1990s and into the new century."

We're left with a pretty good inkling as to why the president moved heaven and earth to keep it quiet before the election.

And reading about Mark Dayton...

Also adding to his vulnerability, Dayton recently delivered a stinging denunciation against the confirmation of now-Secretary of State Condoleeza Rice.

I should think Rice would be the vulnerable one. Some National Security Advisor!

Speaking in Objects vs. "Code Complete"

I was listening to a presenter in a recorded session today refer to their project being "code complete". I did not expect any to refer to that term these days.

Coding never made sense to me as a milestone. I was on one of the first death march C++ projects ever, beginning in 1989. The previous couple of years were spent primarily developing in Lisp. Even with CFront, no debuggers, mangled names... or maybe especially because of these things, my preferred development style was to be unambitious about the results, and to work in small steps.

As a whole hubris had overcome the team. C++ would enable us to rule the world, the sooner the better. The intuition was to spend more time thinking and then coding. Compiling, etc. took too long, so should be avoided.

The problem is that "thinking in objects" is not nearly as productive as "speaking in objects". When you speak in objects, you have a dialog. You speak your intent into the editor and the objects you create respond right back, the sooner the better.

Today Phil Windley writes about a couple of projects still on that old beaten path. So that's three projects in one day I've come across.

I think Ward Cunningham said...

It's all talk until the tests run.

Ruby's Postulate

From a talk by Sam Ruby...

The accuracy of metadata is inversely proportional to the square of the distance between the data and the metadata.

What She Said

Kimbly...

I have more to say, about how democrats are a pathetic excuse for a progressive party.

Meanwhile, we should get on to the serious business at hand... starting with this guy...

Language Evolution

Philip Wadler's humorous take on language evolution. (pdf) Via Finding Lisp.

Not Getting It Any Way

Via Cheese Bikini, too bad Nintendo apparently doesn't get it. The DS is a nice device.

This is the sort of rich, simple innovation that I hoped would emerge with the wi-fi enabled Nintendo DS portable video game system. But Nintendo seems to have locked down DS development, limiting it to internal and professional developers. Such professionals have years of experience and training in building traditional games. This background cripples their ability to innovate, to see beyond the constraints of traditional game platforms.

Nintendo, learn from eBay and Google and Amazon: let customers and outsiders build value for you. Open your platform and let it thrive.

Software Factories

Clicking through from James Robertson's item about Smalltalk and C#(?), another item refers to Software Factories.

I will wager any system using a factory metaphor for software development will either not get off the ground or hover low to the ground for some time until they shift the metaphor to something lighter weight. Like balloons.

You're Getting It Our Way

I think Bill Venner in his item on static and dynamic is trying too hard to separate language and culture.

Python supports this multi-valued return technique better in its syntax than Java, but I realized that the availability of syntax isn't the main reason I do it in Python. The main reason is that's the way it's usually done in Python. By contrast, that's not the way it's usually done in Java. The cultures are different. The culture that guided the design of a language influences my attitudes and mindset when I use the language. The Java culture encourages me to build solid bricks...

I don't think you can untangle the culture and the language, even the syntax. Python the language was influenced by Lisp and Smalltalk. Those languages were developed by, and developed the dynamic culture that surrounds them.

Lisp was created in the late 1950s by people who needed agility more than they needed speed. (Yes, 1950s.) Smalltalk was influenced by Lisp, and Python by each in turn. They began is labs that gave us the earliest work in AI, collaboration, and usability. They were not computing pi or finding the next largest prime number.

This realization got me wondering, to what extent is this perceived increase in productivity with languages such as Python, Ruby, and Smalltalk due to the culture of those communities, and the mindset that the culture engenders in programmers, versus the actual languages themselves? What is the real source of the differences in the static versus dynamic language debate?

A community cannot sustain a specific culture unless the framework supports that culture. Programming languages are the framework that sustains the culture of the community that uses the language. They go hand in hand and nother will change that.

Today, and since the late 1980s, the programming community in general has needed agility for the most part more than we have needed speed. Our languages coming out of the "need for speed" community (C and Pascal, then C++, and now Java, C#) and the cultures that accompany them, have slowly been migrating to be more a culture of agility and less a culture of speed.

Those need for speed languages have features and those cultures have adopted practices that are more like the agile languages developed and used in the AI and collaboration labs in the 1970s. Finally we are seeing the last stages of the transition. Truly dynamic languages are gaining mindshare over the partially dynamic.

Meanwhile good implementations of dynamic languages and the advances of hardware have all but eliminated the speed side of the equation. There are fewer uses than ever for the languages coming out of the speed culture.

Update: A comment on Bill's blog...

Whenever you start to think of some Java problem as a general problem with static type checking, maybe rewrite it in Nice http://nice.sourceforge.net/

let boolean redirected, reply;
let long forumID;
let String subject, body;

(redirected, forumID, reply, subject, body) = ExamplePage.process(request, response, session);

I agree as far as that goes. The newer type systems are "dynamic" even though they represent a somewhat different development model than more traditional dynamic languages. But I don't know Nice and cannot say that it is dynamic or merely "partially dynamic", esp. if it is just a precompiler for Java. (Someone will correct me so I won't even google it.)

Being dynamic or agile is more than just having an explicit type system, or having a bad type system vs. a good one. For example, are relatively heavy mechanisms like "class loaders" needed?

Imagine That

From MSDN .Net Architecture Center...

The file has been the central container of work in software development for over thirty years. All of a project's structure and logic is ultimately reduced down to files and directories. The tools that surround software development are built around this concept, too. This article explores the concept of file structure, and contrasts it with an emerging view of Model Driven Architecture...

It seems clear that the file is a relic that has outlived its usefulness for software development...

The modern development environment has not yet fully caught up to the object-oriented shift. All of the tools still rely on a file to be the container of source code. While some contain modeling capabilities as well, the models exist as different entities than the file and its code.

Maybe some tools. Not all tools.

The article seems to conflate two issues that could benefit from being addressed independently:

• Files
• Models

By the end of the article I did not really learn anything new about the next generation of tools in Microsoft's Dynamic Systems Initiative, which seemed to be the intent.

TDD: Test-Driven Demo?

Perhaps preparation for a demo should be treated as preparing any kind of release for an Extreme Programming project...

• Prioritize the stories.
• Write the story tests.
• Break stories into tasks.
• Program test-first, writing the task tests and completing the tasks.
• Run the story tests as the tasks are completed.
• Any stories not completed by demo day will not be in the demo.
• The stories are prioritized up front but can change as marketing needs change before the demo day.

If the person doing the demo sticks to the script there should be a good chance the demo won't crash.

When to Generate

Xach Beane is dissing maps.google.com...

Google Maps is essentially a large JavaScript application. Great hackers have an almost instinctual aversion to JavaScript. Google is betting its future on something a tasteful programmer's radar rejects.

I don't think JavaScript is that bad, but I've never been accused of being a great hacker. JavaScript has a few things going for it...

• It is fairly simple and regular. Not a lot of obscure corners.
• It is ubiquitous and familiar.
• Most of the interesting uses for it in the browser can be written once or generated on the server!

Cygwin Heaven

I hadn't used Cygwin in some time. So nice. I found a tip for setting the TERM to rxvt which makes applications like emacs display well.

Gambit-C 4 beta 12 builds fine. The 'make check' test fails, maybe due to some CR-LF text/binary mode setting I need to consider. When the tests are diff'd ignoring whitespace they work fine. The tests for the C interface and dynamic loading need to be looked at. But the resulting executables seem fine so far.

Now I need to try the emacs mode for gambit.

Theory: More than the Sum of Some Parts

More evidence a theory is more than the sum of some parts.

In Need of a Theory?

The notion of establishing a "metaphor" in Extreme Programming is similar to programming as "building a theory" as proposed by Peter Naur.

Reading how "Microsoft officials have characterized SharePoint as 'the killer app for XML'", I am looking for a theory to emerge in the way that perhaps continuations are beginning to form a theory around web server programs and s-expressions form a theory around manipulating XML.

SharePoint is a larger concept than continuations or s-expressions. So I would expect a larger theory, but a theory nonetheless, to associate SharePoint and XML conceptually. I did not see one emerge in this coverage of Bill Gates' keynote at a Microsoft Office conference.

Gates told keynote attendees to expect Microsoft to more tightly integrate SharePoint with other Microsoft technologies and point products, going forward. He said to expect SharePoint and Active Server Pages (ASP) to "become closer," and SharePoint and SQL Server to become more entwined, as well.

Gates discussed Microsoft's quest for unified storage of all types of data, ranging from files to e-mail and emphasized that SQL Server would be the ultimate repository for storing this type of data.

As "SharePoint evolves up on the server and WinFS evolves down to the client," Microsoft will be able to realize its unified storage goal, Gates told attendees.

Gates is attempting to associate a number of disjoint concepts in this quote. This approach is something I would expect of a salesman, rather than a Chief Software Architect. An architect should be a "theory builder". I would have trouble buying into this stated direction without a better theory, or even any theory at all.

Of course this opinion could be dismissed as just more Microsoft bashing from the likes of me. But think about it, and tell me the theory that is holding all this together. Maybe I am just missing the point. Microsoft provides the dominant architectures in my computing world. I have a vested interest in them making my life easier, and so I have the desire to point out where I think they're missing the mark.

From this, I think they're missing a theory that could propel their success for another decade. As it is, I suspect they're cobbling pieces together and I am asked to take their Word for it that there is a "there" there where there should be a theory.

Template-Based Programming

The last C++ program I wrote was long before templates became part of the language. Ted Neward writes...

There's a tremendous amount of power in template-based languages.

I have no idea what this implies for C++. I can agree that it's true for Lisp though.

Programming macros in Lisp perhaps has at least something in common with programming templates in C++. Where you go from there is up to you. I hope never to write another line of C++ even with templates.

Defending Applications

Phil Windley also writes about defending an application from OS attacks by running on multiple operating systems. An interesting idea that could be taking one or two steps further...

• You could run the application on a small OS microkernel like Utah's Flux kernel.
• You could run the application on bare metal, i.e. an even smaller microkernel.

Better XML Scripting

Phil Windley writes...

I've written programs that use XML in Java, Perl, Python, XSLT, and now Scheme. Scheme has been the easiest. I think the reason is that with s-expressions, XML is essentially a native data type in Scheme. That's an incredibly powerful idea.

The Soul of a *New* Machine?

Ted Leung writes about a reinventing of capitalism to enhance its positive social effects.

I happen to be reading an arguably related book of essays, and poetry of all things. Poetry does not have the same cultural reception here in the US as it does in other parts of the world. This book, ("The Heart Aroused", by David Whyte, who I knew briefly 18 years ago when I lived on Whidbey Island just north of Ted's Bainbridge Island) addresses the problems of capitalism as they occur in our everyday work life.

Here is part of David Whyte's essay on Beowulf...

Business and politics profess to be hardheaded, but how many businesses, and even countries, have been ruined through decisions that were ostensibly hardheaded but which had more to do with the relutance of those in charge to face fears or vulnerabilities?

This reluctance to enter the deeper waters of the psyche is not confined to modern participants of corporate life. Fifteen hundred years ago in the Old English poem Beowulf, an anonymous bardic author confronted his listeners with a frightening image of this inner lake. His listeners were almost certainly rough warriors used to getting their hands dirty. He found them equally shy of that dark water.

Beowulf is a masculine story of descent into the waters of the unconscious, but where the restoration of a profound inner feminine power is essential to his survival. In that context it is a compelling story for both women and men working in a masculine workplace sorely in need of a commensurate balancing power. In a corporate culture still dominated by the image of the warrior archetype, Beowulf's plunge into the waters of the unconscious seems to be equally instructive for both sexes.

The early English teller of Beowulf asked his listeners to drop beneath the surface of their daily existence, where the rational mind continually prays for dry feet. Since that time the physical details of life may have changed. The elemental motifs have not.

Decentralization

John Robb writes...

My future opportunity, and yours, is being diminished by a state that doesn't value decentralized energy and prefers to spend its coin on military power.

The sad irony is these concerns and strategies were being addressed in the 1970's at least. I remember reading a pamphlet in the early 1980's called "The Indefensible Society" about this idea. As it turns out the web has an excerpt from that pamphlet.

Because moving in the direction of decentralization and the development of planetary villages is different from the direction our society has been heading during the past century or so, it is likely to be dismissed at first glance as impractical and utopian. Yet in reality it is eminently practical and well within our means as a society. And not only is it appealing and workable at a human level, it also can provide creative and effective solutions to problems that presently seem both unsolvable and out of control, such as the arms race.

Of course the original 20th century arms race is over. (On the other hand the US is spending $1 billion USD per week on Iraq.) The problem now is at least as dangerous as the arms race.