On the iPad (Apple's new tablet)

Where's the pen (or stylus) to go with it ?

I mean, really, this is the one thing which for me would make it a no brainer. Multitouch is cool and all, but if we're still going to be stuck with silly keyboards that's just stupid. Why can't we just write on this thing ?

Question which comes close after: can I develop my own apps (probably) and put them on my own and friend's devices without having to pay extra (unlikely) and without going through the appStore (very unlikely) ? This is still my biggest gripe with the iPhone. You buy it but it's not really yours. If the iPad is the same it really loses out against the 13" MacBook Pro.

Very unlikely to buy this unless one of the above questions gets a positive answer.

Some notes to go with my previous rant

1. This post by Steve Yegge seems related. And it's a fun read anyway.

2. I'm wondering if it wouldn't be enough to have a code-generation framework with support for method interception, rather than a full meta-programming system. It would be simpler and, I think, easier to grasp.

Some thoughts about enterprise platforms

I spent the last three days at a training about the EJB3 standard. It was very interesting but, while it's way beyond the troublesome tech that was EJB2, I still have my reservations about it.

Here's my problem: you have a layer of entity beans, which are persistent versions of your business objects. Then you have a layer of session beans which provide services to the outside world which allow you to manipulate the entity beans according to your business processes. For that outside world the safest strategy is to treat the objects as pure data; as structs rather than objects. The overall effect is that you're really programming in a procedural way. In Java. Yeah.

Now you may point your finger in the direction of the JEE standard. But actually I put the problem with the embedding in Java (or any OO language). That's because I think that a procedural approach with a separation of data and services is a much better fit in enterprise settings. Service oriented architectures really are a smart way of setting up such environments.

So, assuming you're in agreement with me (which I won't take as a given), you might come to the following question: wouldn't it be smarter to define an enterprise platform on a language which is a better fit to the services+data architecture, rather than trying to fit it into an OO language and then having to deal with the mismatch ?

Might this be another reason why Cobol was (and still is) such a success ? That it was designed for a business environment, and actually fit very well ? I quite understand why companies might want to stay with Cobol (and I know that some still do), but Cobol no longer fits the current enterprise reality: web applications with high availability, integration with relational databases, distributed systems, clustering, load balancing, and integration in heterogeneous environments.

So let's say we wanted to start with the right language (and it's not Cobol), what would it need to be ? What should it have ? Well, here is my list:

• No objects but structs. That is, your data is just that: data. Easy mapping to and from a relational database is essential.
• A procedural language for manipulating the data. I'm wondering if we could even go with a purely functional language, which would be ideal in a distributed environment. I think this should be possible and, if so, would be preferential.
• Dispatching on argument types (multi-methods), because polymorphism is a very good idea. Let's stay away from if-elsif-elsif-elsif-etc hell. This means that our data should be typed, and that we need some sort of type system.
• A module system for grouping functionality in logical units. Not to be mixed with objects/classes! We want reuse of components and services, not just of their code.
• A meta-programming system. Because a lot of interesting and important stuff becomes much easier that way: logging, security, transactions, etc. This stuff should get generated as much as possible from meta-code.
• Lambda's, closures and higher order functions ? These are nice in event systems and for callbacks. Not sure how essential this is...
• No support for the presentation tier. Because that's where OO and other paradigms actually are a natural fit.

Given the above I'm pretty sure you could define a superior enterprise platform. So anyone know a language which fits ? Or perhaps has some observations on the wish-list ? Let me know.

Pitfalls of OO

This presentation by Tony Albrecht might be interesting to some of you. It's a nicely motivated (with real code, tests and measurements) argument about why OO sometimes isn't the best solution.

For the case being presented (scene graph trees) a functional description seems to make the most sense. A lot of data without type variation and no behavioural differences ? Yeah, not much need for OO there.

So why did I build that 3D engine in Java again ? Uhm... :-)

Burrowed

Yeah, I haven't been doing much these last few weeks. In my spare time, that is. With the holidays, the new year, and the darkness I haven't had a lot of energy to get back to programming something useful.

Things I have been doing instead:

• Playing games on my old Super Nintendo. It still works perfectly. Zelda, Super Mario All Stars, Super Mario Kart, Starwing, etc. Some of these games seem much more fulfilling than others I have been playing lately. But maybe I have been playing the wrong games.
• Watching StarCraft games. The commentaries by DiggitySC are really good. He says he's not a pro, but he's way above my level (mine being somewhere slightly above that of a paramecium). And it's entertaining.

Anyway, I hope to get back to some programming soon, but it might be a while before I post something "interesting". In the mean time you might like to try the Next Revison blog. It has lots of 3D yumminess!