Remembering the Future

Now this is revolutionary. Amazon is attempting to create massively scaleable grid computing for the masses.

Have I said it is cheap yet? $0.10 per hour per instance. And should load get too high you can simple startup more instances, turning computing power on and off like a tap!

From what I can see looking through the notes, EC2 images (i.e. think of this as Virtual Machine images) run the Linux 2.6 kernel.

If you are a Web 2.0 entrepreneur, Amazon is starting to look a lot like your friend.

And suddenly I'm starting to develop a much bigger interest in Mono...

Topics: web2.0 | WebService

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

Topics: Design | BestPractices

Maybe XML is the COBOL of the future. Millions of applications have been written to emit and consume XML, just like there are billions of lines of COBOL code still in production.

But if I’m right we will soon move on to a much smarter approach based on self-describing, self contained and open databases. It would share all XML’s key benefits, but it would be in a much better format for manipulation and querying, and that can only be good.

This would leave behind a wasteland of legacy XML systems that will be maintained by the equivalent of today’s COBOL programmers, the XML programmers!

Perhaps the key distinction to make is this:

Today when we query a database we get a recordset. Tomorrow when we query a database we will get another database.

Data2.0 here we come...

Topics: XML | Database | Web2.0

As a language, JavaScript is still horribly misunderstood. All real power in JavaScript comes from understanding closures, the "everything is always mutable" property, and the prototype chain. These are foreign concepts to Java developers who don't have FP or scripting backgrounds.

. . .

The JavaScript style of data hiding via closures is the flip-side of class-based OO: instead of having instantiable data structures that carry around behaviors, closures are behaviors that carry around their data with them. Thanks to the prototype chain and some magic in the "new" keyword, they can be made to look like class-based OO from a distance, but that illusion breaks down pretty quickly. Most Java programmers just assume that JavaScript is somehow "broken", when in fact it's just providing more abstract primitives for getting at the same end goals.

. . .

The upshot of closures, the primality of the function object, and the prototype chain is that it's possible to better express your intent as a programmer in less space than Java and without resorting to syntax or contored class hierarchies. The language is just more supple. It bends more easily to your will.

There was a fascinating paper by Lutz Prechelt in 2000 entitled "An emperical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl". Among a representative sample of programmers, he found that scripting languages produced better performing programs that used less resources and required roughly half as much code as their Java equivalents.

Scripters lost out big-time in I/O (expected) and C and C++ developers could turn out code that beat all, but not with as much reliability as the scripters. The scripters on the other hand beat everyone for productivity despite roughly static LOC/hour productivity between the programmer populations. Takeaway?: if you're a decent programmer but want to look freaking brilliant, use a scripting language in a Java shop.

The paper wasn't a "do the same thigns the same way" kind of benchmark, it was a sampling of how programmers think about the problems they're presented with given the facilities of the various languages. In the 50's there was this paper called "The Magical Number Seven, Plus or Minus Two" that outlined the limits on human capacity for keeping things "on the stack" when solving problems. The limits are just as real today, and the mildly functional programming style that most scripting languages expose adds new tools for managing and encapsulating complexity to the programmer's toolbox. OO clearly isn't going away, but single-paradigm languages seem to be at a statistical disadvantage. I think we're seeing a realization that 20 years into the experiment, strict OO design is not the be-all and end-all of complexity management. Functional programming probably isn't either.

The hybrids (Python, Ruby, JavaScript, etc.) seem to have real legs these days. Luckily for the Java world, Sun is finally adding good scripting interfaces to the language. They're 5 or 6 years late to the party, but it's a big improvement for the lot of Java devs none the less.

JavaScript is poised to become a productivity shot-in-the arm for Java.

Topics: Programming | Javascript

Only about 5% of these documents contain *any* triples that contribute to a definition. The rest consist of all data. We’ve determined that most of the 5% that contain definitional triples do so incorrectly and should be all data. Of the remaining ones, many are duplicates and copies. We estimate that only about 1% of Swoogle’s collection are proper ‘ontologies’ that are intended to (partially) define at least one named term.

Topics: RDF | Representation | Web2.0