Jeremey's Weblog

Programmers and Philosophies

Dear programmers of the world: take your pet "philosophies" and shove them where the sun don't shine. You're building an app that you want to SELL and your "philosophy" prevents you from implementing a major feature that many users want? You can rot.

You want a philosophy? How about this: build great apps that people actually want to us and that solve real problems for people.

For instance, Twitter clients. I love Twitter. I hate Twitter client developers (except TweetDeck). Why? Because they don't bloody listen to users. TweetDeck has how many users? Despite the mega-suck AIR UI? Why? Because it solves a major problem (grouping Twitter users), and solves it well. Is it perfect? No. Is is 100,000 times better than every other Twitter client because it makes a decent attempt? Yes.

Would I buy TweetDeck? I might. Would I buy a fantastic Cocoa app that had a similar implementation of groups along with a nice UI, low memory footprint, etc.? Absolutely. I would pay $40 for a high-quality Cocoa Twitter client. Is there one? Nope. Not even one.

Tweetie looks fantastic, but it is DOA without groups. I love everything else about it, and it pains me to shut it off and start TweetDeck, but that's what I gotta do, because a beautiful interface to an un-grouped Twitter feed is like the most perfect baseball bat ever made when I need to chop down a tree. Sorry, it doesn't work. It's dead.

If you want to implement what people need and then make it perfect by beating Twitter into implementing groups and transition from your local implementation to an API-based implementation, fine. Just do it. What a waste of an opportunity.

Technorati Tags:
twitter, tweetie, programming, philosophy

On Languages

I've arrived at some rough analogies for programming languages.

C is like driving a Formula One race car. Most people just shouldn't. But if you're really good, you can meld man and machine in ways that just can't be done any other way, and you can build a truly fast, lean, and powerful system. But all kinds of things can go wrong, and usually badly.

C++ is like driving a Formula One race car towing an elephant. You have all of the risks of C with a whole bunch of weight making all the advantages of C moot. There are exceptions, but very few and far between.

Java is like dispensing with the car altogether and just driving the elephant. It's big, slow, and has a mind of its own.

Python and Ruby are different... they don't fit the car analogy so well, but instead fit into art forms. They just work differently. So I see Python as more like a musical composition. It has structure, and some rules, but at the same time has a free-flowing creativity and can have real elegance.

Ruby is more like painting, very pure, each stroke combining with all the others to create a whole much greater than its parts, but lacking the rules and structure that Python has. Ruby lends itself to incredibly elegant solutions. Unfortunately it doesn't have the system or networking robustness of Python, so sometimes it's as practical as a career in painting (but other times, as in the case of Rails, it's just about as perfect as any language is likely to get).

Apologies if I stepped on your pet language. I've just been doing this a long time (almost 20 years) and have developed distinct opinions and impressions. I don't want to argue about it.

Technorati Tags:
languages, programming, ruby, python

Oven Cleaning Advice

Don't self-clean your oven the same day you plan to have people over.