The path of a programmer is a varied and twisted one. You start out on a problem, and before you know it, you've ended up in the deepest, darkest dungeon.
I started out in the Green Fields of Python code. I should enhance this script I thought. But, it's complex and critical, so I should test this before I write more. I know it works now, but it might stop working in the future.
So, before I can test, I need to restructure to make it into more "bite sized chunks". Each chunk is easier to test. Futhermore, Python forces you to do so if you want to test. Ok, now I have to worry about module structures and where to put files. A moment of consternation, then moving on.
Now, let's test... test code is going ok. Wait, what is this 'global' keyword?
And now, a few hours later, I am finding myself annoyed that Python doesn't have lexical closures. I had the exact same problem as this person here.
I was remarking to my co-workers that as a programmer you are always chasing after that perfect language. You want the balance between clean design, all the features you want, and modernity. Roughly speaking the language choices I've pondered about are:
- Python: Very clean, modern, but missing strange features. The white-space sensitivity makes it a hard without a full editing environment - not the greatest embedded scripting language.
- Javascript: Elegant, has good features, and severe gotchas. More of a web dev language, and not as well established as a server-side programming language. Lacks advanced features (think OS-level functions).
- Ruby: Frankly I don't know enough, but I do know the lack of unicode support is a major concern - with UTF8, multi-lingual support becomes easy.
- Java/C++/C: Too static. You end up writing too much code.
- Erlang: Cool concurrency model, but the language seems to lack "programming in the large" features.
- Common-Lisp: Inspired by Paul Graham perhaps? CL is fairly old and has wonder features from the early 80s, such as mono-case symbols. Even major Lispers don't recommend using Lisp for serious stuff.
- Haskell: Very weird, and is it practical to get things done in a pure functional language?
- PHP: Too hacky at a language level, and lacks many features. Passing function names as strings? Ouch.
I've obviously left off a huge number of languages, these are the ones that are foremost in my mind. If you feel like I've done a major disservice and my life could be transformed, let me know!
Practically speaking, my life is ruled by Python and PHP right now. PHP has quirks, but it's reasonably dynamic and not too bogus. Python is one of the better languages, but things like lexical closures and the limited-lambda support really chafes me. I want uber power, and I'm not sure I'm getting it.
Monday, November 17, 2008
Wednesday, November 5, 2008
Election over, can we get back to code please?
Well the elections are over. With an epic battle for the white house, it's like a slow-moving car crash - how can you NOT look?
But it is now time to get back to the code. Time to crank out those functions, write those new classes, debug those files of twisted goto-ridden lines.
Recently at work we were having a discussion about what kinds of new systems we might need to build. Some people were advocating trying to make do with existing systems, but tweak them more. Others were arguing that this might not be enough, and we'll have to end up coding new persistent-daemons anyways, we might as well get a start now.
Both arguments are pretty convincing, the first one is summed up by "don't over-engineer, only build what you need." The best bug you can have is the one you don't write. The second argument would be "if you can easily predict what you need, get a start early so you can build experience with it." If you know you'll need a database, why not set it up early and build expertise in-house?
The first argument seems to be a perfect counterbalance to the second. More code vs less code, in this structure, the less code would seem to have to win. If you take a longer term approach, you can easily come to the conclusion that you may end up with more code in the long term - sometimes the best time to make changes is when things are flexible. Less cruft to work around later, less data to migrate. Build expertise when things are relatively low volume.
These two approaches are seemingly intractable. Stubborn developers in the #1 camp can drag out debate and ultimately "win". But there is a third way.
What if a new system wasn't 50,000 lines of Java code? What if a new persistent-server-process was 500 lines of code? What if a complicated transaction-logged persistent engine was in reality 2000 lines of code? A good developer can make radical changes to 2000 lines of code in a weekend easily.
What if you can build the new system in an afternoon? There is practically no reason not to toss out that system, after all, afternoons have been wasted on even more trivial things - OS problems, expense reports, the DMV. The sooner you can build and throw out code, the more you'll learn about the nature of your problem.
But how do you build and throw out code quickly? The ultimate limit is how fast a human being can type - say 60 words per minute. If we assume that one line of code is 4 words, then we have 15 lines per minute, or about 1000 per hour. One afternoon would be about 4000 lines. And practically speaking most programmers would be lucky to get a solid 4 hours of coding a day.
So if you can only realistically get a few thousand lines of code out of a programmer a day, you better make sure those lines really count. By increasing the level of abstraction, coders write less words yet get more done. This is a fundamental argument that is difficult to dispute - no one would argue that programmers are more productive in C vs assembly, or in Python vs C. The power generally comes from what you do not have to do as you code, vs what you do. Memory management, structure definition, fundamental libraries, loops and so on. All of these things improve the levels of abstraction, and thus improve the level of programmer productivity - you simply go farther with those 4000 lines of code.
This is a popular minority argument to make. I think one of the better ones is done by Paul Graham. Nearly every language jockey takes this position - some languages are more powerful than others, and why would you use the lessor of two powers?
But in the end, programmers are human, and humans are creatures of habit. And so we only get a new language once every 7-10 years. C in the 80s, C++ in the early 90s, Java from about 1997-2005, and now... what?
But it is now time to get back to the code. Time to crank out those functions, write those new classes, debug those files of twisted goto-ridden lines.
Recently at work we were having a discussion about what kinds of new systems we might need to build. Some people were advocating trying to make do with existing systems, but tweak them more. Others were arguing that this might not be enough, and we'll have to end up coding new persistent-daemons anyways, we might as well get a start now.
Both arguments are pretty convincing, the first one is summed up by "don't over-engineer, only build what you need." The best bug you can have is the one you don't write. The second argument would be "if you can easily predict what you need, get a start early so you can build experience with it." If you know you'll need a database, why not set it up early and build expertise in-house?
The first argument seems to be a perfect counterbalance to the second. More code vs less code, in this structure, the less code would seem to have to win. If you take a longer term approach, you can easily come to the conclusion that you may end up with more code in the long term - sometimes the best time to make changes is when things are flexible. Less cruft to work around later, less data to migrate. Build expertise when things are relatively low volume.
These two approaches are seemingly intractable. Stubborn developers in the #1 camp can drag out debate and ultimately "win". But there is a third way.
What if a new system wasn't 50,000 lines of Java code? What if a new persistent-server-process was 500 lines of code? What if a complicated transaction-logged persistent engine was in reality 2000 lines of code? A good developer can make radical changes to 2000 lines of code in a weekend easily.
What if you can build the new system in an afternoon? There is practically no reason not to toss out that system, after all, afternoons have been wasted on even more trivial things - OS problems, expense reports, the DMV. The sooner you can build and throw out code, the more you'll learn about the nature of your problem.
But how do you build and throw out code quickly? The ultimate limit is how fast a human being can type - say 60 words per minute. If we assume that one line of code is 4 words, then we have 15 lines per minute, or about 1000 per hour. One afternoon would be about 4000 lines. And practically speaking most programmers would be lucky to get a solid 4 hours of coding a day.
So if you can only realistically get a few thousand lines of code out of a programmer a day, you better make sure those lines really count. By increasing the level of abstraction, coders write less words yet get more done. This is a fundamental argument that is difficult to dispute - no one would argue that programmers are more productive in C vs assembly, or in Python vs C. The power generally comes from what you do not have to do as you code, vs what you do. Memory management, structure definition, fundamental libraries, loops and so on. All of these things improve the levels of abstraction, and thus improve the level of programmer productivity - you simply go farther with those 4000 lines of code.
This is a popular minority argument to make. I think one of the better ones is done by Paul Graham. Nearly every language jockey takes this position - some languages are more powerful than others, and why would you use the lessor of two powers?
But in the end, programmers are human, and humans are creatures of habit. And so we only get a new language once every 7-10 years. C in the 80s, C++ in the early 90s, Java from about 1997-2005, and now... what?
Election night photos
There was an epic election results party in the Castro tonight. Tempered a bit perhaps due to the Prop 8, but still, very exciting and happy. Here are some photos:
Thursday, October 30, 2008
Android OTA Upgrade
It's pretty late but I just got the notification that my G1 wanted an update. Early adopter is early adopter so I let it go.
It's a pretty slick updater, completely hand free and wireless. One nice thing about the G1 vs the iphone is the degree of independence. The iphone is essentially a teathered device. You can't get all data off without syncing with itunes. Unless you fork over for mobile me. At least gmail and gcal are free.
I really hope they maintain a good update velocity. I can think of a dozen features that I'd love to see.
It's a pretty slick updater, completely hand free and wireless. One nice thing about the G1 vs the iphone is the degree of independence. The iphone is essentially a teathered device. You can't get all data off without syncing with itunes. Unless you fork over for mobile me. At least gmail and gcal are free.
I really hope they maintain a good update velocity. I can think of a dozen features that I'd love to see.
Tuesday, October 28, 2008
Android Stuff
Well it's been a week since I started using my G1. Overall, this is a great device, and I won't be switching back to my iPhone original flavor. So here is my new list of things I really love about this device:
Now, on to photos... The G1 has a very respectable 3 megapixel camera, but it won't be causing me to leave my Canon 5D at home anytime soon. Here is a sample photo:
Nighttime photos are tricky, but no more so than under the iPhone. Bonus: it you are tricky with the physical button you can take candid shots.
- 3G speed - 800 kbps in tests. EDGE can come in at up to 200 kbps too!
- GPS - the 50' accuracy rules!
- IM - It's great to be able to instant message on the device.
- MMS - picture messages, they are just so handy when you need them.
- Push Gmail - this is just outstanding.
- Gmail interface - finally a compelling email application for a mobile device. If you are a heavy Gmail user, this is worth the price of admission.
- Auto-sync contacts and calendar. Don't worry about losing this device!
- Full text keyboard is fast and awesome.
- Scroll ball is surprisingly useful - it's great for navigating tiny links on webpages.
- Notification system and swipe-down status bar is surprisingly awesome and usable!
- Regular email app is substandard.
- Surprisingly: I miss the portrait virtual keyboard of the iPhone. Flicking open the keyboard all the time for quick SMSes isn't always handy. I'm in luck though: this feature is on the short-term Android roadmap!
- Android Market - needs more apps. Needs the incentive of pay-apps to up the overall platform quality.
- Apps in general - you need to cache more (on the SD card?) and avoid using the network.
- Battery life... This is probably the darkest note here. Battery life can be dismal. I've heard of people getting more life as the battery gets calibrated.
Now, on to photos... The G1 has a very respectable 3 megapixel camera, but it won't be causing me to leave my Canon 5D at home anytime soon. Here is a sample photo:
Nighttime photos are tricky, but no more so than under the iPhone. Bonus: it you are tricky with the physical button you can take candid shots.
Tuesday, October 21, 2008
My Android review
Well the Android arrived today. First off, I noticed that someone at Google is taking box design cues from Apple. As soon as you open it up, there is a little spot for the phone and you can yank it right out. Check it out:
This was a nice touch, and I'm glad someone was paying attention. The phone is not featured because it is taking the photo itself!
Setting up was a breeze. I moved my tmo sim from my old iPhone to the Android device, then it asked me to enter my Google address. A few minutes later and it was all done. Next step is syncing my address book entries (from the iPhone), I'll let you know how that goes.
Instead of a big blob of blog text, I'm going to list the things I really love so far about the Android:
Overall, the Android is not as shiny-slick as the iPhone, but it is slick in it's own way, and very very fast which is a huge plus. It also feels like using a portable computer again, not just a pre-defined gadget (the iPhone).
This was a nice touch, and I'm glad someone was paying attention. The phone is not featured because it is taking the photo itself!
Setting up was a breeze. I moved my tmo sim from my old iPhone to the Android device, then it asked me to enter my Google address. A few minutes later and it was all done. Next step is syncing my address book entries (from the iPhone), I'll let you know how that goes.
Instead of a big blob of blog text, I'm going to list the things I really love so far about the Android:
- Physical buttons = maximizing of screen real estate.
- Unlock screen is cool and fun.
- The GPS is really awesome and really accurate when you drive around.
- The notification system with the slide-down status bar is a fantastic UI system
- Push GMail rules
- Oh the GMail client is as great as the web client
- Instant Messaging - it's as integrated as SMS
- MMS again - that was tiresome iPhone
Overall, the Android is not as shiny-slick as the iPhone, but it is slick in it's own way, and very very fast which is a huge plus. It also feels like using a portable computer again, not just a pre-defined gadget (the iPhone).
Saturday, October 18, 2008
Android... it's alive!
Well I finally got an updated shipment status from UPS:
Looks like my previous hope/assumption that UPS had the item but wasn't scanning it just wasn't true. For some reason T-Mobile send the shipping number to UPS 3 days prior to its actual shipping.
What is really interesting is how the package went from Kentucky to California in just 5 hours. The tracking says 'Mather, CA' which Google maps puts on the junction of several forestry roads. Ok, so poorly named tracking point, since Sacramento's airport is called "Sacramento Mather Airport." Air freight from Kentucky to California. I only hope that UPS doesn't dilly dally over the package until Tuesday because that is when it is due. I've seen them do things like that before.
Looks like my previous hope/assumption that UPS had the item but wasn't scanning it just wasn't true. For some reason T-Mobile send the shipping number to UPS 3 days prior to its actual shipping.
What is really interesting is how the package went from Kentucky to California in just 5 hours. The tracking says 'Mather, CA' which Google maps puts on the junction of several forestry roads. Ok, so poorly named tracking point, since Sacramento's airport is called "Sacramento Mather Airport." Air freight from Kentucky to California. I only hope that UPS doesn't dilly dally over the package until Tuesday because that is when it is due. I've seen them do things like that before.
Subscribe to:
Posts (Atom)