I got my new T-Mobile G1 a couple weeks ago and I absolutely love it. The battery life is probably the only thing that bothers me, as it is too short, but I think this is largely because I use it constantly.
I’ve gotten a feel for the Android Market, and it seems to be lacking a few things. One decidedly annoying omission is a decent IM app. The one that comes on the metal is sub par, which is really surprising given how much polish most of the system exhibits. Nothing in the Market does much of a job of improving upon it either. Most apps are either hungry for features or have basic issues like connectivity problems.
I’m planning to either whip up a libpurple client with JNI or simply write a decent Jabber client and funnel all the legacy services through transfers. Either way, I should be able to drum up something far more compelling.
In addition, I’ve come up with an app idea all my own. I was out hiking, and thinking “wow, it’d be really neat to have trail maps on my phone.” Sadly, I seem to be the only programmer who hikes. So I brainstormed with my dad for a bit and threw together some ideas for a hiking companion I’m calling TrailMix:
- Find a trail nearby (or in a specified location).
- Rate and comment on trails you’ve been to.
- Submit your own trail maps (using the GPS to track you as you hike) and geotagged pictures, as well as your own trails. (very wiki-ish)
- Track your hikes – distances, times, etc.
I think some more ideas may crystallize soon.
Outside of the G1, I have an ambitious new project. I’d like to invent a better C++.
But let me rephrase that. C++ is one of the most disgusting programming languages ever invented. It forces developers to think in wholly ridiculous ways about problems that simply should not be overcomplicated by language barriers. It leads to idiomatic recitation rather than true understanding, and in general it’s a damnable evil wound upon the face of software engineering. What I want to do is not to take C++’s mistakes and try to correct them, but rather to go back to C, and expand it into an object-oriented language in the Simula style which is not an unspeakable evil.
I call this project K. My choice of this letter was largely arbitrary, but it is the first letter of my name. I basically just wanted to pick a letter which wasn’t already in use (D, E) or used by anoher language (F, J) and also wasn’t too heavily invested in other works (G, Q, X). I guess I forgot about KDE in this process, but that’s acceptable.
Plus, K has an interesting history as one of our twenty-six Latin letters. It has the distinguishment of being a hard C-like sound which has been used for words of royal or otherwise high status (king, knight). Get it? K is “classy C”. Har har.
Enough babbling. The basic ideas in K are thus:
- There’s nothing wrong with Simula-style languages. I don’t agree with the notion that the Smalltalk syntax is the only valid way of doing object-oriented programming. This is the view which led to Objective-C, and while I admire Obj-C as an elegant language, it’s pretty clear that if Mac OS hadn’t picked it up, it wouldn’t even exist anymore. Simula-style languages are what people are used to, and I’m not keen to throw the baby out with the bathwater.
- It’s 2009. Why are strings still second-class citizens? K does away with NUL-terminated character arrays or pointers or whatever they are this week and makes `string` a built-in complex datatype. Lists are given the same privilege, as are dicts, sets, and other ubiquitous datatypes.
- Everything is an object.
- defining class.__mul__ is less painful than class.operator*, so that’s how we roll.
- Overloading is overrated, but it should still be possible.
- Template syntax should not make the compiler blow up. K makes sure it doesn’t.
- If it’s not an atom, it should be passed by reference. Them’s the breaks. You’ll thank me later.
I may or may not give up on this idea soon. =) But TrailMix? That’s a keeper.