Microsoft!

This could turn out to be the best thing to happen to Google in five years.

Yeah, but otherwise the browser is a great platform for applications...

(via James Robertson, who could tell you about Seaside)

News from the Blackberry

From Joe Wilcox at Microsoft Watch...

"Forrester expects at least half of the 42 percent of enterprises that
say Web 2.0 is not on their priority list to add it by year's end."

Oh, and Ray Ozzie will be speaking in March.

2008.

Testing Trumps Design

Reaching back a year or so ago to a point Ralph Johnson made about practicing test-driven development. The big lesson: every little bit helps. You don't have to be perfect by any stretch, just stretch yourself more than where you are currently, and then a bit more...

For some years, I've taught a software engineering course that used both XP and RUP. Students had group projects, and half were XP and half were RUP. The projects are not run in as controlled a fashion as those in the paper, so perhaps I am missing something. However, in general I have not seen a big difference in results between the two. The main indicator of success is previous experience. Groups that have a couple of experienced people do better than those without.

However, one group of people consistently did better with XP than with RUP. This is a group with little programming experience. RUP did not work for them because they had nobody who could act like an architect. They would produce UML diagrams, but they were always wrong, so it was a waste of time. However, when they followed XP, they produced (usually poor) working code that had regression tests. Eventually they started to refactor it. Because they always kept their tests working, they always made progress, even if it was slow. XP worked much better for these groups than it did for average groups.

I'd take a reasonable, automated test suite over a great design any day. The one can lead to the other more easily. I'm not sure I'd recognize a "perfect" test suite if it hit me in the face, but a team that tries to improve it's testing has the best chance of success.

Javascript and Smalltalk

Joe Gregorio writes...

Alan Kay had a vision for the web... Ten years later we have the Lively Kernel...

JavaScript, it's the new Smalltalk.

I can go along with the Javascript part. There are aspects of Javascript I like more than Smalltalk, and the other parts are not so bad either. Javascript does have some cruft that makes it more complicated than Smalltalk, oh well.

I can go along with the HTML and SVG parts too. But the Lively Kernel part has a way to go. Too bad it's built on the browser, which is a much worse medium than the Smalltalk image. Hopefully that will improve, but browser progress as an application development medium is depressing.

The web makes a helluva "image file". Morphic is a great UI approach, but the browser is not ready to fully realize it.

The current browser is not even up to the level of Smalltalk-72 running on a DG Nova, pushing that analogy a little over the top. It's kind of sad to see Dan Ingalls mucking around with LivelyKernel when he could be working on such a better medium. It's kind of like when Ward Cunningham was at Microsoft and they just couldn't figure out what a creative mind they had available to tap.

Wiimote and Your Computer

(Via James Robertson) Cool, cheap touch controls on your computer using a wiimote. Good YouTube videos of what's possible now for the "maker" types, and should be fairly cheap out of the box for everyone else in the near future.

And now for something...

Steve Dekorte on another of my favorite subjects...

If you're looking languages or concurrency tools that will scale to the high core count desktop machines of the near future, I wouldn't put stock in MISD oriented solutions such as transactional memory or fancy functional programming compiler techniques. Shared memory systems simply won't survive the exponential rise in core counts.

Deeper Dynamics

Oh dear. This can't go on for long. I've been in the middle of these muddles before. Say something like, "Dynamic languages have great tools and can be used to build large, long-lived systems." And you will find yourself on the receiving end of questions like the following which someone just sent me.

I can indulge these for a minute or two. The problem is they are rarely asked by open-minded people. Usually they come from the statically convinced, who just need to find a way to catch you, to allow themselves the comfort that their static languages and their tools could be the only possible methods for large systems. They need to assure themselves of being on the righteous path, and you, poor fellow, are one step away drowning in Styx.

Before I proceed let me state: I know large systems can be built statically. I've done it in more than one language. I've also done it dynamically in more than one dynamic language. Have you? Have you been part of failures in each? Yes, I have. They almost never have anything to do with the languages and the tools themselves.

That said, I prefer dynamic languages because they ease the pain when used well. On the other hand nothing eases the pain of bad projects.

"What happens in Smalltalk projects where you grow larger? Where you want to divide a system up into components, and some of those components don't exist yet?"

Well, what happens in other projects? You have a need; you have an idea to meet the need; you try it; you grow it. I guess I don't understand the question.

"How are interfaces between library and user code specified?"

Interface notations have been attempted for various dynamic languages, including Smalltalk and Lisp. There is a reason they've not really caught on, yet large systems are still developed in these languages.

Semi-formal notations, tests and other examples, documentation, good tools -- these all contribute to success. But if you are looking for some kind of a "static declaration" as they saving mechanism for large systems -- it may work for you, but I doubt you can prove they are necessary and sufficient. I have counter-examples.

"Can such interfaces be browsed in the same way if the code can't be called?"

Your question betrays your bias. "There must be some such mechanism as the one I am used to," he thinks.

Most large systems developed with dynamic languages have not used the kind of mechanism you seek. Look elsewhere.

Can we go back to arguing over WSDL vs. REST now? Face it. The history of programming is one of gradual adoption of dynamic mechanisms.