Whole Program Optimization

Since encountering the Stalin compiler for Scheme about 10-15 years ago I guess (see Flow Directed Lightweight Closure Conversion, PDF), I've been fascinated by the whole-program analysis approach. Starkiller for Python is in the same ballpark.

So this ML compiler called MLton caught my attention.

MLton is a whole-program optimizing Standard ML compiler. It generates standalone executables with excellent runtime performance, supports the full SML 97 language, and has a complete basis library. It also has a fast C FFI, source-level time and allocation profiling, and many useful libraries.

XBOX 2 as a PC

One of three versions of the XBOX 2 is rumored to be "a fully functioning PC".

Interesting, because the XBOX 2 is supposed to be powered by IBM's PowerPC CPU.

C# or Java as Target Languages

An interesting post to comp.lang.lisp on generating code for C# (or Java)...

I am continuing to evolve a system that generates business applications for .NET in C#... it is giving us about a 10-1 productivity gain...

Why do we not just use Lisp as the delivery language? It comes down to components. .NET (and Java) have huge choices of commercially available components for GUI, Infrastructure, Database, ... (not available in Lisp).

Why not deliver Lisp that *connects* to the dotnet runtime? (e.g. Python.Net does this and Cincom Smalltalk is heading in the same direction with their Fall 2004 release.)

Queueing Fits

The Amazon queue service apparently has an undesirable use of HTTP. Seems like the design is aimed at being simple on the surface but not logical down deep.

Josh Sled provides a fairly simple Python implementation that is more RESTful. The implementation as well as the client code gets more complicated if you'd like it to be reliable, but the Amazon service provides no better guarantees.

Queues are nice. Would that they provided a tuple space.

Nonstop Languages

Catching up some more on old items in the queue. The title in this Register article refers to a "forgotten language" being used in "nonstop gadgets". Maybe we should refer to Lisp and Smalltalk as "nonstop" languages.

How does it achieve this magic? OOVM's technology comes in two parts, a VM and a development environment, and it uses Smalltalk, rather than modern-day kludges such as Java, which resembles a modern object-orientated environment in the way that a pub ashtray resembles a cigar store.

He has 18 years experience developing virtual machines. Any useful bit of advice stand out, we wondered?

"You have to make them simpler," he told us.

Appropriate Benchmarks

Catching up on some items, this one came through when I was on vacation a few months ago. Jon Udell wrote...

"When you think about it," Hugunin said, "why would the CLR be worse for dynamic languages than the JVM, given that Microsoft had the second mover advantage?" And in fact, while he had to do plenty of extra work to support dynamic features that the CLR doesn't natively offer, he notes that the massive engineering resources invested in the CLR make it highly optimized along a number of axes. So, for example, the CLR's function call overhead is apparently less than the native-code CPython's function call overhead, and this is one of the reasons why IronPython benchmarks well against CPython.

I am not sure I would use CPython as the benchmark for dynamic language performance.

Candor in Software Development

I love reading stories like these from James Robertson. They teach useful lessons and remind all of us to actually share them.

Not just "patterns" are worth sharing. We've all run into our share of "anti-patterns".

Thanks for demonstrating the value of candor. They are as enjoyable as reading about the ideal aspects of Smalltalk and software development.