Bush is a Word Weasel

Bush says Kerry does not support the troops and "There is nothing complicated about supporting our troops". But does he walk the talk?

In spite of this simplistic sound bite, Bush has actually cut support for the troops in terms of pay, veterans' benefits, and, oh, yeah: even meals available to active troops in Iraq.

And what's that issue about lack of sufficient armor?

The word weasel also weasel'd out of serving appropriately during the Vietnam war. What did Kerry do? Oh, yeah, earn several earn several purple hearts and a silver star.

I would not hold avoiding service against anyone because, based on my beliefs, I would have to be a conscientous objector and serve in a non-combat role. But Bush did not take this approach... he weaseled.

Bush is a lying weasel that clear thinking Republicans should not tolerate. Kerry and Edwards (again despite the rhetoric) have very moderate voting records in the Senate. They are in actuality much closer to a moderate Republican's beliefs than is Bush.

The lying-dangerous-to-the-world-and-our-troops-weasel Bush.

Software that Lasts

Dan Bricklin's essay on software that lasts 200 years reminds me of s similar idea from Ward Cunningham on software lifecycles...

First, the notion of a program life cycle admits failure from the start. If we are to have a life cycle, let us make it long. One hundred years cannot be beyond reason. Second, analysis as an activity to be conducted independent of implementation [see correspondence] again presumes implementation artifacts to be short lived and of little value. These ideas have become self-fulfilling prophesies. Although they apply in the current circumstance, they have become barriers to change from that circumstance. They impede progress in object-oriented programming.

The cause of flexibility will not be served by merely discrediting life cycle or independent analysis. To make progress we must examine the system of practices that have lead to these principles, discard those practices justified only by habit, construct new practice where human nature alone is insufficient, and then describe the whole with metaphor that implies useful longevity for the programs we make.

Of course we want and embrace change if for no other reason than that change is inevitable. So a great component of a realistic response to these challenges will be addressing what it may mean for software to both *last* and *change* at simultaneously.

What OOPSLA Has Become

Twenty years ago, the monthly Communications of the ACM was something to look forward to. Fifteen years ago, I guess, it had morphed into something not much better than Dr. Dobbs.

Fifteen years ago, OOPSLA was something to look forward to. Recently it has morphed into something not much better than SD West.

My first clue was the last time OOPSLA was in Vancouver. The first night's social activity was to have some celebrity OOPSLAer's name taped to your back and you had to go around asking questions to guess the name. A small group of us immediately hit the bars and had a blast. Don't know how the game turned out.

More recent evidence.

Boo hoo

I guess it's pile-on time from the dynamic language zealots, including me!, around Boo, a language that may have some promise. This post does not pile on Boo, rather, on its critic at http://www.panopticoncentral.net

I will add that one major problem with our compilers today is that entirely too much information is locked up in them. We've started exposing compilation information through mechanisms such as the Visual Studio code model, but we need to go a lot further to enable more advanced and extensible tools. It's certainly possible to expose a lot more information about what exists in the code that's being compiled without having to make that information modifiable outside of the compiler, and I think that's something that's unquestionably worth pursuing in the long run.

Complexity begets complexity. Rigid languages are the foundation of a "langauge priesthood" just as humongous mainframes were the foundation of a "computing priesthood" before the personal computer.

The author is apparently against "extensible languages". Arguing against "extensible languages" while promoting C# is an oxymoron. It's just that C# has crippled the extension mechanism and will be reinstating them over time in slightly incompatible syntaxes.

Understanding Continuations

Ian Bicking has an operational, concrete description of how continuations work.

Here's another way of explaining that sometimes works...

• Imagine running some code in a (good, hypothetical) debugger.
• Step through the code at the finest level of detail.
• The "step" command is what the code will "do next, atomically, then stop".
• The "continue" command (continue without stopping again) is what the code will "do next and thereafter".
• The "continue" command is the debugger's way to access a continuation.
• The Scheme function call-with-current-continuation is like the "continue" command of this hypothetical debugger.
• The difference is rather than having the debugger get access to the continuation, your code itself gets access to the continuation, "disguised" as a procedure rather than as a debugger command.
• Like any Scheme procedure, this "continuation procedure" can be called over and over again.
• Like any impure language, though, Scheme side effects like assignment and I/O are not purely functional and so subsequent invocations of the "continuation procedure" take place in the state of the system resulting from earlier side effects.

What's a Data Warehouse for?

Peter Nolan, esteemed DW'ist, writes in the venerable dwlist mail list (subscribe, archive) what he thinks a data warehouse is for...

Instead of making the right data readily available to the people who really need it with tools they can really use to do what could make a really big difference to the business we gave everyone a pretty dumb browser interface and we gave lots of people access to data that they have barely any earthly use for other than to fill up their 8 hour working day fiddling around with it. Oh, but these dumb web interfaces have nice pretty charts and buttons and things and that makes all the difference.....hhhmmmmm.

...in any organisation, there is only a very limited set of decisions to be made which drives only a very small number of 'questions' compared to the set of 'all questions that could be asked'. If a DW project concentrates on 'the set if possible questions that will make a major difference to the organisation' and collects the data for that rather than 'any possible question' and collects the data for that, the project is far more likely to be successful.

More of his thoughts along these lines are in an Intelligent Enterprise article from 2001.

Reason #42

"Scientists horrified by Bush's Bad Science"

What started as a group of 62 scientists fighting what they saw as Bad Science being practiced by the Bush administration has now bloated to a body with more than 4,000 whitecoats calling for change.

Jesus' General on Suspending Elections

The General speaks...

I understand that you have a tough sell. I'm sure there are many who have pointed out that elections have never been suspended before, not even during the Civil War when our very existence as a nation was in danger. These people fail to understand the nature of the threat today.

Bottom feeding with style?

James Robertson and Michael Lucas-Smith will be presenting in Canberra.

Why is this a particularly interesting combination for a presentation? Robertson's BottomFeeder is a fairly popular aggregator written in Smalltalk. Lucas-Smith's WithStyle is a new, interesting web-oriented, yet "rich" user interface technology also written in Smalltalk.

What could come of applying the WithStyle user interface approach to the BottomFeeder aggregation engine? That's one reason why.

Testimony

From KBM's weblog...

Kent Beck... said... 'I program at a third of my Smalltalk speed in Java.'

Bran Selic (RealTime UML guru, built the tool that is now the RT part of Rational Rose) said... 'Smalltalk was the only language in which I noticed a real difference in my productivity'

Interesting VMs happen elsewhere

Ted Leung points out the interesting feature and proven results of the Squeak Smalltalk VM that are apparently not apparent in the state-of-the-industry JVM or CLR.

I learned a few things about Squeak. The Squeak VM runs on about 30 platforms and runs the same (bit for bit) image on all of them. Apparently the VM is auto-generated in some fashion. Given the effort required to port the Java VM to a different platform (I did some of the work to get Java running on the Newton at Apple), this is pretty impressive.

Here's a description of how the Squeak VM is "auto-generated"...

The key to both practical performance and portability is to translate the Smalltalk description of the virtual machine into C. To be able to do this translation without having to emulate all of Smalltalk in the C runtime system, the virtual machine was written in a subset of Smalltalk that maps directly onto C constructs. This subset excludes blocks (except to describe a few control structures), message sending, and even objects! Methods of the interpreter classes are mapped to C functions and instance variables are mapped to global variables. For byte code and primitive dispatches, the special message dispatchOn:in: is mapped to a C switch statement. (When running in Smalltalk, this construct works by perform:-ing the message selector at the specified index in a case array; since a method invocation is much less efficient than a branch operation, this dispatch is one of the main reasons that the interpreter runs so much faster when translated to C).

The translator first translates Smalltalk into parse trees, then uses a simple table-lookup scheme to generate C code from these parse trees. There are only 42 transformation rules, as shown in Table 3. Four of these are for integer operations that more closely match those of the underlying hardware, such as unsigned shifts, and the last three are macros for operations so heavily used that they should always be inlined. All translated code accesses memory through six C macros that read and write individual bytes, 4-byte words, and 8-byte floats. In the early stages of development, every such reference was checked against the bounds of object memory.

Our first translator yielded a two orders of magnitude speedup relative to the Smalltalk simulation, producing a system that was immediately usable. However, one further refinement to the translator yielded a significant additional speedup: inlining. Inlining allows the source code of the virtual machine to be factored into many small, precisely defined methods, thus increasing code-sharing and simplifying debugging, without paying the penalty in extra procedure calls. Inlining is also used to move the byte code service routines into the interpreter byte code dispatch loop, which both reduces byte code dispatch overhead and allows the most critical VM state to be kept in fast, register-based local variables. All told, inlining increases VM performance by a factor of 3.4 while increasing the overall code size of the virtual machine by only 13%.

What's really interesting about this is the ability for anyone to extend Squeak using the same technique. Do you want to try making a stretch of your Smalltalk go faster? Write it using the subset language and generate the C, essentially extending the "VM" in an application-specific way.

Lisp Lives Some More!

Back in May, Lispmeister posted on a Lisp Lives! article at SD DevTalk.

The article is now in the July Software Development magazine. Lisp lives!