The problem is trying to decide which of these mutable resources are likely to be accessed in a concurrent fashion, provide locks to enforce mutual exclusivity; ensuring no other processes is working from an intermediate, invalid state; and all without becoming deadlocked. Traditional debugging and even test—driven approaches aren’t much help, because the errors are dependent on the order in which the processes are scheduled to be executed; not very repeatable, and certainly not controllable.

So the course left me itching to have a go, but aware that concurrent object oriented development needs to be done in the right language, oh, and very carefully. A little reading around the topic lead me to the idea of immutable state development.

Now in OOP terms an immutable state is not very helpful, nothing much ever happens. We rely on the software state being stored in the attributes of all those objects, and actions being driven by the exchange of messages between them. But in the functional programming paradigm an immutable state is implicit, since the state is stored in the way functions execute each other, and themselves, no data is actually stored in variables. This means that processes can be executed in any order without any danger of seeing an invalid state: no need for any locking and a much simpler programming job!

I’ve only just started investigating these ideas, but with the thrust of computing performance in the direction of multiple processors, either on a single machine or via the ‘cloud’, it seems that concurrent, parallel programming may be very important in the future. A couple of languages I want to check out are Erlang and Clojure. Finally, I found the Ruby on Rails Podcast interview with Jim Weirich an interesting perspective on the programming.

Here’s the near future dream; they can get a lot wilder.

I’m working on my latest project on the train, in a tunnel, whilst I travel to a meeting with a client. I reach a critical part where I need to see the big picture, so I find transfer the output to an LCD display in a coffee bar at the station.

It’s not going smoothly, and I decide I could use some help, so I call a few colleagues and arrange a conference in 15 minutes time. Once we’re all virtually present, it’s early remember, I’d show them the problem by sharing my display output via the network. Each using our own devices we work together, version controlled and still conferencing, until we crack the problem.

I thank everyone and leave for the Client’s office. Once there I transfer the presentation of the key project details to a large TV in the conference room and send a hardcopy to the printer in the office.

Oh… and all seamlessly without wires. Of course, this is a picture of the utopia of perfect interoperability and security, but what are the chances?

Interoperability.

The device layer interface is a key feature, with transparent support a wide selection of drivers and protocols, I don’t want to have to get involved. As many devices aren’t wireless enabled at the moment, have poor device driver support, or use proprietary communication protocols, this is a real challenge.

Getting input.

Input is probably still the good old keyboard and pointing device, of which there are several approaches for those who don’t mind carrying extra kit.

• Fabric keyboards that can be folded away, like the Just Mobile RoKy².
• Projected light keyboards like the I-Tech Virtual Laser Keyboard are compact and lightweight.
• The pointing is easier, a wide range of Bluetooth mice and other devices already exist.

And for those that do?

• Traditional mobile phone keyboard. I hate this, I’m too old to be any good and have an aversion to developing arthritis in my thumbs.
• Touch screen keyboards, the Apple iPhone is the best implementation I’ve come across.
• Stylus on touch screen for handwriting recognition as used by Palm.
• Or just being able to use any input device I find lying around, wireless of course.

There are other options like voice recognition, cameras, and detecting eye movements which could find wider use in the future. I’d like a direct mental link, so I can just think what I want to do, but I’d probably end up with a nasty brain wiping piece of malware!

Displaying output.

Displaying output raises important issues surrounding the usability of the actual user interface, after all, I’m proposing to go from working on a typical PDA size display to a 40 inch TV! I want to make the best use of the visible area on any given device, whilst avoiding 4 inch high characters.

The experience of designing for different web browsers, screen resolutions, and colour maps could be leveraged for this new platform. CSS can be targeted at different media types and such an approach could be adopted throughout the new system.

Staying mobile.

Power management is vital for extended mobile operation and I’d like to be able to work normally for several days at least.

This may be achieved by longer battery life or a totally different energy storage or generation technology. Fuel cells, solar panels or even nuclear power could be used; though even I’d be a bit concerned about carrying around a nuclear reactor. What if the fuel cell ran on a range of organic feed stocks, just like I do? I could recharge my computer at the same time as myself in any restaurant.

Wireless recharging could be an option, maybe inductive charging such as WildCharge pad. I’d prefer my device to selectively recharge at any opportunity, and from any source, so that I don’t have to be in any particular place or make any conscious decision. The device could decide to top-up from a nearby power cable, the sun as I walk around, or even using the heat of a warm day. Again, I don’t want to know it’s happening or how.

How long?

Much of the software architecture and implementation technologies already exist to make my dream device a reality, the real work is in perfecting the hardware at a cost that makes loss or damage acceptable; it’s portable remember. At the current rate of development I suspect I won’t have to wait too long for the device itself. But the legacy issues for hardware interoperability?

Ultimately it’s my guess that computing and the Internet will become indivisible; not sticking my neck out too much since for many of us it already is. If some of the wilder concepts of ubiquitous computing come to pass I won’t need a single device anyway, I’ll just pick up computing resources whenever I need them from the environment surrounding me.