Seth: How about this (it was the first thing that came to mind) - ‘Create a desktop operating system that allows a single support operator to maintain 10,000 user wokstations.’ There are certainly huge implications for ease of administration and scalability there, but probably even more so for ease of use. Hell, it’s probably not even a realistic target, what with human nature and all.

I used to read Tom Coates’ weblog regularly, and came back to it after a break today. This post pretty much sums up my thoughts about David Blaine, and is very funny at the same time. My favourite quote?

…you too could make it if you just ate less mexican food and got your teeth fixed.

I’ve been thinking a bit about autoboxing, a new feature slated for Java 1.5) which is due out at the end of the year. This is basically an automatic conversion between primitive types (int, double, &c.) and their object wrappers (Integer, Double, &c.). As far as I can see, this is just a bad idea, and the only reason it’s being considered is because C# has it. Sure, Java makes you jump though hoops when you’re using the object wrappers and there’s definitely an argument for changing something about how this all works, but autoboxing is just the wrong solution in every way. It hides what the language is doing for you in a misleading way.

Just one point: look at the overheads in Java involving object creation, better than they used to be for sure, but do we really want to add more? Surely a far better solution would be to change the language and remove the primitive types altogether? Than it would also make more sense to allow the standard arithmentic operators to work with BigDecimal and BigInteger (maybe even adding a Complex class) as well.

Remember, this is just the written expression of a program, a sufficiently smart compiler should be able to optimize this away based on context, this was supposed to be one of the main advantages of JIT compilation. In theory, there should be no overhead to using the object wrappers in running code, after the first JIT run this hypothetical code:

1
2

for (Integer i = new Integer(0); i < 10; ++)
    // Do something here...

Should be no less efficient than:

1
2

for (int i = 0; i < 10; ++i)
    // Do something here...

Note that we could allow the standard operators to work on these ‘blessed’ classes, much the same way as the addition operator works for string concatenation today.

Again. Something I said that I’d never do again. Again… although at the moment I’ve not really got too much to do other than be here. Probably spend the rest of the evening coding on my current personal project, Message Explorer.

Update: A bunch of the code that I started writing for Message Explorer has been incorporated into RvSnoop.

Miguel de Icaza writes about binary encoding for XML (Omri’s page was unavailable, so I can’t comment on that). This is already in widespread usage, a la WBXML. It’s a pretty successful standard, given that it targets low bandwidth mobile phones they’ve obviously encoded for size, a fact made easier that it also targets a specific schema. I.e. it’s not a generic XML encoding.

Omri’s thesis is that there are multiple things that you might want to optimize for: size, parsing speed and overhead for generating the data and that it is not possible to define a file format that satisfies all of those different needs.

Well, I thought we had already done this with XML. The fact is, you can already use your own favourite encoding. If I want to make it easy to parse then I can use UTF32, if I want to be ‘more standard’ I can use UTF8. I’m not sure about this (I need to check the spec) but in theory you should be able to use any encoding that you want to, as long as all parties agree on it.