Reminder

Peter Fisk observes...

Lisp is like “executable XML”. Much more powerful and flexible than Xaml.

In the very early 1990s, Lisp was actually used to define at least one standard information exchange notation, EDIF: the Electronics Design Interchange Format.

The someone latched onto this overly complicated angle bracket element and non-bracketed attribute stuff.

Now we are getting back to sanity with JSON, in some ways even better than Lisp. It is almost as easy to parse and arguably more readable (e.g. easier to distinguish pure lists from property lists).

TestDriven.Net

(via James Robertson)

Along the lines of Martin Fowler's recent expression of concern, here's this row about MSFT vs. TestDriven.Net

I am not a big IDE proponent (other than those typically found in Smalltalk). But when I was teaching and coaching agile development mainly to developers on the MSFT platform I did have Visual Studio installed, and the best thing about it was the plugin for TestDriven.Net.

It Runs

Linux, of course. Palm Folio.

Developing in the Sunlight

Martin Fowler on a potentially huge Microsoft / Ruby / FOSS conundrum... too good top-to-bottom to figure out what to quote here.

Apollo Gears

The Apollo folks talk about how they and Google Gears are both using SQLite and how they are working toward the same APIs to help code work with either.

Cool. More openness from Adobe.

Breaking Out

ars technica relays...

future versions of Windows would have to be "fundamentally different" in order to take full advantage of future CPUs that will contain many processing cores.

The concept of an "operating system" generally will have to change, even go away. Think "system" in a way that is unconfined to a "box" somewhere.

So, yeah, Windows would have to be "fundamentally different". It's not about "cores". Any specific silicon wafer will be just a host to *some* of the processes in the system. The rest will be elsewhere. Who cares, unless your revenue stream is an "operating system"?

If you are going to fundamentally redesign your system, you'd better aim for a technology landscape that is further than five years out. Ten years out will probably be as different to five as five is to today.

Messaging Only

(via Bill de hÓra)

I agree with the observation...

Messaging APIs are dying on the vine, ws-* stuff just redefines the existing APIs with ws-* APIs and transports but does nothing to simplify the life of a programmer.

...but not the cure...

Messaging is just state, state should be managed the same way whether its state from a message or state from an inmemory database like ObjectGrid or state from a relational database... messages should not be orphans in your data model

I think there is a time and place for in-stream, "continuous query" capability, but those a few and far between. Rather a simple Javaspace-like or Erlang-like pattern matching on individual messages should be sufficient for messaging, keeping the query stuff out of the stream and in memory or disk-based database-like thingies.

The biggest problem with messaging for Java (sans Javaspaces), and most other non-Erlang languages, is that creating and using even the simplest of inter-process message queues is a relative pain in the tush. Just creating another process is painful.

JSM and locking messages matched by queries joined from other (mutable) objects? Ugh. No.

Better?

How about making it easy to create a new process and automatically giving each process its own inbox and outbox supporting simple pattern matching? Some of these inexpensive processes could be storing up data and doing all kinds of queries over that using JPA or whatever floats your boat.

In Erlang and in Gambit Scheme, every thread (in Gambit, process in Erlang) automatically has its own inbox and outbox. In Gambit those are not automatically inter-process. Unix processes are the same way, but still not as easy to do, esp. remotely, as in Erlang.

Someday we'll look back and say, "Remember when starting a process was hard, and communicating with them was harder?"

Microsoft Surface

(via Don Box)

Looks good on the surface: Microsoft Surface.

Bad pun. Interesting device with a lot of potential: I need to read more to understand how it is programmed. It looks like a machine with Windows Vista. But how well can it act like a programmable client device for other machines to interact with?

What is the cost? Their current market seems to be positioned fairly "exclusively", listing restaurants, hotels, and casinos. The future direction is positioned more mass market. A lot of fun and useful potential for all kinds of applications.

(Oh, but that Adobe Flash web site is not very Restful! Please use *real* links!)

Pot-Kettle-Black

From cnet on the need for more concurrent programming...

Intel's Borkar said that Microsoft and other large software makers have known this shift is coming and have not moved fast enough.

"They talk; they talk a lot, but they are not doing much about it," he said in an interview following his discussion. "It's a big company (Microsoft) and so there is inertia."

Intel's main problem... they should have started becoming a software company a long time ago. In some ways, they have, but just not good enough.

Look at Sun. Sure Intel in significant ways has been and will be in a better position that Sun. But in other significant ways, I have to wonder: is Sun a software company or a hardware company? What about Intel? Which is better, for the long run?

There is no clear answer to me, except that Intel would be in a far better position if they were to take on more of Sun's strengths.

Maybe I am jaded as a former software developer for Intel. But there is so much more Intel could be doing to control their own destiny.

Borkar writes...

"Software has to double the amount of parallelism that it can support every two years."

Don't fall for this. I hope this was a meaningless aside attempt to make a fluffy analogy.

There is no Moore-ish path for software. Hardware essentially took the same von Neumann design and compressed it along Moore's predicted path, including increasingly more concurrency over time. The reduction in size and increase in performance was essentially due to better technology being applied to the same design up until the internet, heat, etc. forced more significant design changes.

And even now the design changes are essentially taking the same von Neumann design and replicating it on a chip.

Software? This is a different beast that will require more radical rethinking. Taking the internet and shrinking it down to everything, more or less.

Design & Test

People like Tim Bray and Fuzzy are speaking out in favor of a Rest specification language. I've not tried it, and barely read about it, so I won't comment on it.

I will say this though... specifications are good, especially if they are simple and simple tools can support them.

I hope this specification and especially these tools don't get too elaborate though. Tools are often used to hide complexity and prevent developers from really understanding and improving their designs.

Even more, though, is this: I like examples at least as much as I like specifications. Specs make understanding complete. Examples (such as out-of-the-box executable test suites) make understanding practical.

So specify your service all you want -- but please give me a suite of tests as well.

Changes

Dan Creswell on learning from others...

Notice how the monolithic single database architecture hasn’t just confined scalability and performance but the speed with which new features could be added. As an enterprise one might certainly argue that the level of scale of amazon is irrelevant to them but the ability to add features or change? That sounds like something we should all be interested in.

This is the number one problem (and yet often the least recognized) in software organizations I am familiar with: the inability to change as desired because of unnecessary dependencies among components.

Software tends to "accrete" (in the worst way) rather than change, because we developers tend not to pay attention to the limitations we are imposing on our systems. The ability to change has to be deliberately designed-in and maintained with extreme attention.

Surprising me, Bill de hÓra apparently disagrees.

That's much too convenient. It's tedious to incessantly see developers or "IT", as groups, get the rap for shortsighted upstream decisions. Plenty of developers understand exactly the limitations they're imposing, but imposed schedule pressures dictate they have little or no choice. This notion that the "business" is the set of stakeholders that are not technical is something to be questioned. Non-technical stakeholders are often worst placed to make decisions about what software should and should not do.

If you build bad stuff it is *your* fault. Period.

I've run into too many developers who've not taken the steps they could've to maintain some ease of change. Even in the most difficult of schedule pressures, or whatever, I often find it's the lack of attention on the developers' part that could still make a significant difference.

Related to this is that developers (and especially development managers) tend to be pushovers. I believe this to be so to a large extent because they don't have a high enough regard for the principles of their craft. If you are a developer working with an overbearing "business" person, it's your responsibility to stand up for the system and make the case for the consequences of bad decisions (past and present).

I'm not saying there aren't other problems in the software business. But bad development decisions leading to exorbitant "cost of change" down the road is a huge problem from what I've seen.

Links

More questions I'll keep trying to give my take on...

Can I link from my blog to content or data within a RIA app?

Can you link from your blog to content or data within a browser app? Only if that content is being served somewhere over HTTP or some other common protocol.

Same is true with a RIA app.

Flash sites where links can go out but they can't come in?

Your choice. AJAX is the same way.

An AJAX app can run in a browser and display things that are not served by links to other clients, so can a RIA app display things that are not served by links to other clients.