Language matters

My non-programmer friends and relatives sometimes ask me:
Why are there are so many different computer languages?

My co-workers sometimes ask me:
Why are there so many reference books for obscure languages on your bookshelf?

The answer in both cases turns out to be the same: Language matters. The language you use affects how you think about a problem. Psychologists and Linguists (and Politicians and Salesmen) have known about this for years as it applies to human languages, and it turns out to be true for computer languages as well, of course.

I was reminded of this fact just today, as I was explaning some concepts in Object Oriented Programming to a co-worker who's just coming up to speed on C#, after using mostly C and Perl for several years.

My own first exposure to Object Oriented Programming was back in the (very) early 90's, with Borland and Microsoft's C++ compilers. I'm not sure I ever really "got" OOP in C++, and neither did most (all?) of the people I worked with. We mostly just used C++ as a better version of C.

Fortunately for me, I managed to snag a copy of Digitalk's Smalltalk for Windows not long after that. And suddenly, it all made sense!. Because the Object-Oriented nature of Smalltalk is so "in your face", you can't help but start thinking about things in a new way. The version I got came with pretty decent tutorial info as well, which was also a big help.

I never actually produced any large-scale software in Smalltalk (it was impractical for work projects in terms of performance), but the new way of looking at things stuck with me as I continued to write low-level bit-banging code in C. When I came out to California and worked for NeXT, my Smalltalk experience translated, more or less directly, to Objective-C.

Anyway, back to the discussion with my co-worker. There are a couple of different ways of thinking about "using objects" that I'm familiar with, and I tend to think of them as "The C++ way" and "The Smalltalk way". In some sense, this isn't entirely a fair characterization, but in my experience, the two views are more-or-less endemic in their respective programmer communities, so that's how I think of them.

The C++ view:
An object is a combination of some data, and functions that operate on that data. To perform some action, you call a member function of the object instance that has the data you need to work on.

The Smalltalk view:
An object is a model of some part of your problem domain, and each object has its own set of responsibilities and capabilities. To cause something to happen in your program, you send a message to an object, which may in turn send messages to other objects.

Now, it turns out that these two definitions are actually equivalent, or at least compatible, despite the fact that the C++ definition is entirely focused on the implementation detail, and the Smalltalk definition is entirely focused on the semantics.

When you get right down to the low-level implementation details, "sending a messsage" and "calling a member function" are really the same thing. A couple of CPU registers get loaded with a couple of addresses, and then you jump to a subroutine. Yes, I know it's more complicated than that in the real world, where you've got vTables, and dynamically-compiled methods, etc, etc. Work with me here...

The C++ programmers that I've met usually come to C++ from a background writing software in C. Because C is such a very low-level language, it encourages (or maybe I should say requires) that you understand the low-level details of how stuff works under the hood - memory management, how structures are laid out in memory, that sort of thing. When these folks start using C++, they apply the same low-level filter to things, and they see a class as just a data structure with some functions attached to it. This is in fact technically true, but kind of misses the point.

As I was trying to explain to my co-worker what I didn't like about some code of his that I was reviewing, I ran into a bit of a wall. I knew that something wasn't quite right, but I wasn't able to articulate the problems well enough. I think I finally figured out that it was at least partly a result of the difference in perspective due to our different backgrounds. Once I figured that out, I was able to take the discussion out of the tactical questions like "should I use a Regular Expression here?", and into the more theoretical territory of "is this an appropriate way to model the problem you're trying to solve?", and I think we made better progress after that.

It'll be interesting to see whether my co-worker has the same kind of epiphany that I did, or if he'll pick stuff up more gradually. Given that we're mostly using C# and C++ at ZING, I suspect it'll be the latter. You can write code in C# that looks just like C, with the minimal amount of "classiness" wrapped around it to compile. I suspect it would be easier for most folks to learn a new concept in a language where their old habits are obviously not going to do the trick.

Which reminds me of something else I wanted to write...

So, how was CES, anyway?

For those who don't recognize the name, "CES" is the Consumer Electronics Show, a yearly trade show for the Consumer Electronics industry.

ZING did really well at CES this year. In addition to the usual behind the scenes deal-making and partner development, we had a couple of high-profile announcements, and one of the products we're helping to bring to market won an award!

SanDisk's Sansa Connect got a "best of show" award from CNET.

What does that have to do with ZING, you ask? We designed the hardware, software, and service infrastructure that makes the Sansa Connect work.

ZING also announced a deal with FON that will allow ZING-enabled players to connect to the FON network. This is great because FON is the fastest-growing WiFi hotspot network out there. They've got an interesting business model, too - share your WiFi bandwidth at home, and get free access to WiFi when you're not at home. Check them out at http://www.fon.com.

For a while there, an at-CES interview with our CEO Tim Bucher was linked from the front page of CBS.com. It's a little harder to find today, but here's a link.

So that's what it feels like...

It was an interesting experience watching a MacWorld keynote address with a feeling of dread, rather than one of anticipation. Fortunately, Apple didn't announce anything that makes the product I'm currently working on irrelevant, but it was interesting feeling that cold prickle of fear.

The iPhone is very expensive by my standards, but that's always true for Apple hardware. When I worked there, I never really felt like I belonged, in some sense. I never would have bought an iPod when they came out, but the market certainly ate them up. I'll most likely take a pass on the iPhone as well, not least because it's not a clamshell phone. I'm not really a fan of phones that are designed such that I can't sit down with them in my pocket.

The more surprising thing (and frankly worrying, as a competitor) is Jobs' claim that the iPhone is running Mac OS X. Now, we all know that that's not *quite* true - presumably it's been stripped down a bit for the environment. But the key thing is that it's actually got a rational software architecture. One of the things that was a constant drain on the iPod team when I was there was that there wasn't any OS as such on the iPods, and they weren't really built on any kind of common platform.

This made adding new features to the product line, or even fixing minor bugs, a major hassle - between making the changes in 3 or 4 gradually diverging code bases, and retesting absolutely everything anytime we changed anything (no memory protection or preemptive multitasking on those old iPods), we had a hell of a time just getting anything done.

When Apple needs to add a new feature to the iPhone, they'll just have any one of Apple's developers crank out a widget in DashCode, and they can then just make it available for download. If you're any kind of Consumer Electronics company, you really ought to see this as a shot across the bow. Maybe you're not in the mobile phone business, and you don't see how a $500 cell phone is relevant to you.

First, don't expect that the price is going to stay that high for long. Second, think about what's the actual difference between an iPhone and a new wide-screen iPod, or an Apple portable game machine, or whatever? That's right - a couple of minor board changes, and some new application software, and it's whatever Apple wants it to be. They've got an actual PLATFORM for high-end (currently) Consumer Electronics, and the game as we've known it is changing.