Unimpressed...

OK, I finally managed to watch the keynote. Which keynote? Surly you are joking. The 2008 WWDC Keynote, of course.

Now, it's Thursday, and the keynote was Monday. That by itself should tell you a lot. Usually, I would try to find a way to watch a S. Jobs presentation as soon as it appeared on the Apple site. This time around, I felt no great longing to see the actual presentation. I could tell already, from the news trickling through the web, that I was going to be disappointed.

Don't get me wrong. The 3G iPhone is nice. GPS is nice. Better battery power is nice. And the new price is astounding. But, I don't think I'm going to run out and buy one. I love my iPhone, and I can't wait for the 2.0 update. I'm itching to develop my own apps for this platform. I might even buy a 3G phone for my wife. But, I don't think the changes are significant enough to warrant upgrading.

Of course, I might change my mind. Maybe a series of new, cool apps will require 3G or GPS, forcing me towards an upgrade. But, right now, I can wait.

And there are things that I'm waiting for. How long until Apple releases a 32 GB iPhone, or a 64 GB? Currently, my iTunes library sits at 27 GB. I'd definitely upgrade to a phone that could store all my media.

I'm also still waiting for Flash. Apple claims the iPhone provides real access to web pages. But, I'm sorry. Without Flash, its not a real browser. There are too many things I cannot access.

And there are the other dream features. The forward-facing video camera for mobile video conferencing. The auto-rotating marshmallow skewer and bacon stretcher. I'm looking for that unexpected Apple touch that places the new iPhones even further ahead of the competition.

Finally, I mentally place 3G and Blu-Ray in the same category. They're nice technologies, but I think they may be a little too late. I suspect on-demand, HD movie downloads will kill Blu-Ray before it ever becomes truly popular. Similarly, I think something (maybe WiMax, maybe a new technology using the soon-to-be-freed analog TV bands) will soon wipe 3G away. Of course, I'm probably dreaming of things 5 years in the future--so a 3G phone may still be a safe bet, assuming you're going to upgrade it in a few years anyway.

Next comes Mobile Me. A lot of people have raved about Mobile Me, claiming that it is much, much better than .mac. Again, there's noting wrong with it. Yes, the push email/calendar/contacts is nice. But, really. It's not a feature I need.

I don't need to receive my email instantaneously. If someone needs to contact me that desperately, they should call me. After all, it is a phone. And syncing my calendar and contacts once a day is fine. The web interfaces look cool, but I usually read my personal mail on my phone anyway, or on my home computer.

Now, if they gave my iPhone "Back To My Mac" capabilities, then we'd be talking about a technology I could get behind. Even if it just let me browse my home folder and open files remotely. The iPhone can already open Word, Excel and PDF files (not to mention a variety of media files). 2.0 will add support for PowerPoint and the whole iWork suite. I'd love to be able to browse through files on my hard drive at home, and open and view them remotely. Even better, let me email them from my iPhone, or let me copy them to a public .mac/Mobile Me folder. This would let me access my home files even when I'm trapped in a PC-only environment (like work).

Finally, there was an incredibly brief mention of Snow Leopard. Now, I can't say I'm excited about Snow Leopard, since we know next to nothing about it. However, I'm going to make a bold prediction here, based on rather sketchy evidence. First, I think the name is deliberately tied to Leopard. Snow Leopard may well be a variant on Leopard, not an entirely new OS. We've also heard that it won't contain any significantly new features--which would be appropriate for a variant.

Second, the marketing speak suspiciously refers to Snow Leopard as OS X, not Mac OS X. This may or may not be significant. Apple has already moved OS X away from the desktop with the iPhone OS. This could be a step in a similar direction. Or it might just be a marketing decision.

Finally, it is apparently Intel only and fully 64 bit. Here's the question no one has asked, does that mean it won't run on 32-bit intel macs? There are a number of those floating around. My MacBook Pro is one. Will I be cut out in the cold?

Or, is Snow Leopard an OS for an entirely new type of device? Something that can leverage the touch technologies pioneered in the iPhone? I'm not saying a tablet. I've been waiting for an Apple tablet so long now, I've basically given up hope. But, what about a laptop with a touch screen. Alternatively, Apple could be planning new hardware with a significant jump in the number of cores. Snow Leopard seems to emphasize parallel computing--it might be nice to have new hardware that could really take advantage of Grand Central.

The bottom line is, I don't think Snow Leopard is an OS for the computers we have today. I'm not sure what it runs on, but I hope it will be a nice surprise.

OK, back to the Keynote. While everything that Steve presented was good and interesting, nothing made me want to rip off my shirt and dance topless in the isles (and thank goodness for that!). I think Apple's moving in the right direction, but I can't help but be a little disappointed. Where are the surprises? The rumor sites scooped almost everything. Where's the "one more thing?"

Maybe I have set my sights too high, but I can't help but feel a little let down.

-Rich-

Frustrated when people just don't get it...

Ok, I'm not one of those "Ruby (or whatever language) will kill java" people. I don't like Java. I'm a proficient Java programmer. I probably know it better than any of my preferred languages, since I've had to use it so much for work. I don't wish it would die, though I do wish I could get away from it for a while...

Still, I found myself getting a bit hot under the collar when I read 13 reasons why ruby, python and the gang will push java to die… of old age.

Just look at some of the things that spiked my blood-pressure:


Reason number 1: Syntax is very important because it builds on previous knowledge. Also similar syntax means similar concepts. Programmers have to make less effort to learn the new syntax, can reuse the old concepts and thus they can concentrate on understanding the new concepts.

Reason number 2: Too much noise is distracting. Programmers are busy and learning 10 languages to the level where they can evaluate them and make an educated decision is too much effort. The fact that most of these languages have a different syntax and introduce different (sometimes radically different) concepts doesn’t help either.

Reason number 6: There is no great incentive to switch to one of the challenger languages since gaining this skill is not likely to translate into income in the near future.


To me, this seems like arguing for ignorance. Learning languages is too hard. Learning a new syntax is too hard. Why bother.

And, perhaps it's true for a certain number of programmers. Heck, I know people at work who feel exactly this way. It may even be the majority opinion, for all I know.

But that doesn't make it a good attitude.

I prefer to follow the Pragmatic Programmer's advice. I try to learn a new language every year.

Now, I don't expect to use all these languages on real projects. I'd like to, don't get me wrong. I can often be found whining about how Project X would be so much easier if we could only use Language Y. But that's beside the point. I study programming languages, because studying a variety of programming languages makes you a better programmer, even if you never use them professionally.

Let's move away from computer languages for a second and look at natural languages. It's often said that languages affect how we think. My wife is Japanese, and I know enough Japanese to get by (though her English is much better than my Japanese will ever be). There are definitely concepts in Japanese that I just cannot express in English. We just don't have the words. Sure, I can describe the idea in a round-about way. But I cannot say it directly.

This is often frustrating. If I've been using Japanese a lot, I often find myself unable to express certain feelings accurately in English. Now, the truly odd part is, I never had a need to express those feelings until I learned Japanese. My mental model of the world simply did not include those ideas, at least, not as a crisp, well-defined concept.

The same thing happens with programming languages. Knowing how to decompose a problem for a functional language is very different than knowing how to decompose a problem for an object-oriented language. It provides an entirely different set of tools for breaking down and understanding complexity.

Also, learning a new language often forces you to examine your preconceived notions. Often you find that your preconceived notions are just wrong.

And here's the best part. Just because you cannot use the tools and techniques from one language directly in another, doesn't mean the effort was wasted. Often you can borrow a really useful gem or two. Having programmed in Lisp, I now find it much easier to program recursive traversals of complex data structures. After using Smalltalk for a while, I find I write much smaller methods in Java--which makes my Java code much easier to read and maintain.

So, yes. Learning one programming language is hard. Learning a second is somewhat easier, but it's still a chore. But, by the time you get to your fourth or fifth language, it gets a lot easier.

Finally from a section labeled "Why many of the new languages will never be popular"


Some languages have very difficult to “get” concepts. For example most of the supporters of functional languages are proud of how concise statements are in their language. This is not really useful for somebody used to think procedural or object oriented. If the only gain from binding and twisting your mind is typing a few less lines then any experience programmer will tell you that this is not the main activity. Writing the first version is just a small part of the life cycle of a project. Typing the code is even smaller compared with the design time. From the second version the game changes dramatically. Maintainability is way more important. Also very important is to be able to add features and to refactor the code. Readability is paramount from version two, and for both development and support teams.


This entirely misses the point. First, I'll repeat my argument from above. binding and twisting your mind is good because it forces you to approach problems from a new perspective. That should be justification enough. But wait, there's more!

Functional languages (or any expressive language) often allow you to model complex ideas concisely, but we're not interested in just saving keystrokes. Concise languages have less code. There is a direct correlation between the size of your codebase and the number of bugs in your program. There's also a correlation between size and maintainability.

Let's make this concrete. When I took my Natural Language Processing course, I did all the assignments in Lisp. The TA was a friend of mine, and he often commented that my code was an order of magnitude smaller than the other students. I could do more with 200 lines of Lisp than they could do with 2,000 lines of Java. That's not "just a little typing." My code had fewer bugs. It typically ran faster, and I never had memory issues that often plagued other students.

Now, maybe that's not a fair comparison. These projects fell squarely within Lisp's sweet-spot: command line tools that manipulated lists of symbols. If I was building a UI, I'd probably pick a different tool.

Now, before someone else mentions it, I admit it. Nothing I have said here contradicts 13 Reason's main argument. These languages that I love may never become popular. They may never kill off Java. But, does that really even matter? Popularity has never been a measurement of quality. Trust me. My daughter loves Hannah Montana. As far as I can tell, every tween girl in the country loves Hannah Montana. Yet, I know in my heart that it is not quality music (or quality TV for that matter).

I do hope we move from a monolithic language approach to a polyglot language approach--but Java doesn't have to die for that to happen. It just needs to learn to share.

-Rich-

Two new articles.

I just received my May issue of MacTech Magazine, and I have two articles in this issue. Part II of my RubyCocoa article and an overview of the iPhone SDK (at least, what I can talk about without violating my NDA).

Hopefully I'll be able to talk a lot more about the iPhone SDK soon. However, I can safely say, good things are coming.

-Rich-

The problem with JUnit

I'm a big unit test fan. However, I often feel that the goals of testing run counter to the goals of good Object Oriented design. At least in static languages like Java.

Object oriented design is based on the idea of encapsulating behavior. Testing is an attempt to reveal and examine behavior. You can't have both.

I often run into this problem when implementing algorithms inside an object. From an OO perspective, I often want to declare all the methods that perform the scary math as private. They should never be called from the outside. However, I really need to test them somewhere.

Problems also crop up when calling methods that change an object's state. The state is not always directly exposed, and sometimes it's nearly impossible to indirectly detect the change.

I don't feel the same tension when testing in dynamic languages like Ruby. Usually, these languages have a stronger reflexion or metaprogramming functionality. They let me safely encapsulate the things that should remain hidden, but still allow me to pry my objects open and root around in the guts.

I can write tests using reflection in Java, but the syntax is painful. I can get around that with a library of helper methods--but for some reason, reflection makes many Java developers uncomfortable, even when only used in testing. And, truth be told, it never feels as natural as the dynamic language tests.

Similarly, I can use a mixture of interfaces and mock objects (for example, using EasyMock) to let me examine the inner workings of a class. Often this simplifies writing the tests, but the results can be incredibly brittle. Building useful mock objects generally requires a detailed understanding of our classes inner workings. If I change the implementation, I will break my mock objects, and then break my tests--even if the new version is functionally identical to the old.

Of course, even the reflection-based testing is somewhat brittle. Reflection, by definition, looks at the implementation, not the interface. But, our interactions with the implementation tend to be more surgical and specific. So, while these tests are somewhat brittle, they tend to be more resilient than the mock-object versions.

I can try to get around all these problems by redesigning my objects. Move my algorithms to a utility class, where they are publicly exposed and easy to test, or add accessors to the internal state, even if the accessors should never be used for non-test code. While this works, it can lead to unnecessarily awkward designs, or exposing more of the implementation than is really necessary.

I think, ultimately, a mixed approach is best. Like many software engineering tasks, we must examine our design and decide which sections are likely to change, and which are likely to remain the same. Static sections can often be effectively tested using reflection or mock objects. Sections that are likely to change should be encapsulated and tested as separate objects.

The trick is then to successfully separate one from the other.

Interested in Nu

If you haven't already, check out Nu. A LISP variant, implemented in Objective-C with heavy Ruby sensibilities. It's like all of my favorite things, rolled into one.

Well...It would be nice if it had XCode support. And it's seems a long ways away from a 1.0 release. Still, it looks quite interesting.

-Rich-

Time Machine Update Update

Nope, my wife's computer has been refusing to do backups since shortly after the 10.5.2 update. Apparently, she got tired of seeing it complain, and just shut it off. Anyway, it's not just me.

Time Machine Update

Here are a few things I've learned about Time Machine since writing the article.

1) I had to send my MacBook in for repairs. Apple replaced the logic board. Therefor, I had a new ethernet MAC address. Therefor I could no longer access my backups. I found some hackish instructions online that helped me fix it. But, I told them that I had backups when I sent it in. If they had wiped my hard drive, I would have panicked.

2) When booting from a Leopard DVD, I did not have the option to restore from backup. The problem seems to be, I need to setup the wireless to connect to the network, and I need to log into the host machine before getting access to the backup bundle. The software on the Leopard DVD simply doesn't give me the option to do that.

In the end, I erased and reinstalled OS X on the machine. Set up a dummy account. Used that account to access the network and log into the host machine. Then I connected to the time machine backup and restored all my data.

I think there may be a better option here. I think I spotted something that suggested connecting the drive directly (even though you typically cannot connect the hard drive directly if you've been doing remote backups). I don't know. It sounds sketchy to me. But it might be worth a try the next time a machine goes down.

3) 10.5.2 seems to hate Time Machine. Since upgrading, my backup has become more and more unreliable, and has taken longer and longer. Finally, it stopped working entirely. I couldn't even mount the bundle anymore. I let Disk Warrior work on it for three days. It reported over 50,000 errors, but wasn't able to do anything useful. In the end, I had to delete the bundle and start from scratch.

Actually, it may have been the hacks I mentioned in step 1 that eventually killed it--but I don't think so. Other people seem to be having the same problem. I thought 10.5.2 was supposed to improve Time Machine stability.

4) While I cannot mount my backup sparse bundle directly on the host machine, I can mount any backup bundle from any remotely logged in machine. No password needed. That's kind of scary.

That's it. If you have any other tidbits, list them in the comments.

-Rich-