How Twitter is Different

Humans Leave Many Different Tracks
© Silus Grok

Now that I've been using Twitter for a few days, I thought I'd note how it's different from other forms of communication I'm used to using. Comparing to things like irc, instant messaging (im), email, mailing lists, newsgroups, etc.

One very noticeable difference is in the 140 character limit on the messages. This is due to the fact that most people (I guess) are twittering via SMS on their phones, which has a limit of 140 characters per SMS message. Actually, is that 140 characters, or bytes? What's the character encoding story? hmmmm ...

This limit if far less than most other communication messages. Which forces various forms of conservatism, like using TinyURL for any URLs you want to 'send'.

Twitter is also, generally, not directed. You are talking to your 'friends' and/or 'followers' (the distinction has not stuck with me yet). In IRC terms, you could think of this as being a separate channel that you are sending your messages out on; but it's not neccessarily two-way. You might send a message that a 'follower' sees, but if you aren't set up to see their messages, you won't see them.

Twitter is not as intrusive as im or irc. With im, I can actually see who's online, and even perhaps how long they've been online or offline. I'm not sure if it was a bug or feature, but in a version of Sametime 7.5 that I used, it would actually popup a messaging window when someone started sending you a message, but before they actually sent the first one. It was fun to freak people out, when no one knew about this, by getting a message to them first. "Hey, I have this weird feeling that you want to ask me something". :-) But the fact is, I think im in general exposes a bit too much information.

Twitter is persistant. When I send a message, it's out there for everyone to eventually see, even if they aren't online to see it. Compare to irc, where if you aren't online (and don't have easy access to irc logs), you missed out on the conversation. Mailing lists have the same poor quality; it's easy to join a mailing list, but getting access to previous conversations can be painful. Hint: use gmane.

Twitter tends to be personal. "That was a delicious ham sandwich I just had!". It's easy enough to believe that this would make some folks non-interested in the product. However, the content which people are providing today is not really a telling indicator of how this might be useful in the future. For instance, my first foray into NNTP (or it might have been NetNews then), in the mid 80's, was rec.humor. Today, NNTP is an extremely valuable communication channel for non-personal, technical information.

Twitter has an insanely easy API. I was able to whip up a little 'reader' app for it in 1.5 hours. And that involved dusting off my python skills, figuring out how to talk to Growl, and dealing with cron. Compare with any of the other channels, and, it's night and day. I've looked at XMMP a few times, and it's not insanely easy. I've also written code to deal with many of the other channels, reading and writing, including email and nntp clients and servers, etc. Twitter is just plain simple in comparison to all of them.

I think the technology here is interesting. Perhaps as it gets integrated more into the fabric of our other communication channels, and daily-use tools, we'll find that it's a useful niche for certain styles of communication. I'm bullish on it.

Perhaps we can look at expanding this out a bit more. It would be nice to be able to support > 140 characters per message. It would be nice to be able to support sending hypertext of some kind. It would be nice to be able to support sending structured data. It would be nice to have more 'endpoints' than just twitter.com. And do we need to start thinking about spam?

Of particular interest to me, is the use of automated sending of messages from other programs, like continuous builds. And then the automated reception of messages. Jazz folks, take note.

Updates:

2007/04/02: fixed a broken link to Jazz.

ActionScript Typing

Type
© Tony Unruh

In the blog post, "The Open Web and Its Adversaries", Brendan Eich writes "If I were VP of Engineering in a 10,000 person company, I would want the security blanket of the C-like syntax and a static type system for a well-known, big-bell-curve language like AS3, C#, or Java." It's interesting that he's lumping ActionScript 3 with C# and Java as 'strictly typed' languages, since ActionScript is an evolution of JavaScript, which is not strictly typed.

It's true that the documentation for ActionScript 3 uses the 'typing' notation everywhere. Here's an example from one of the Hello World samples.

	package { 
		public class Greeter { 
			public function sayHello():String  { 
				var greeting:String; 
				greeting = "Hello World!"; 
				return greeting; 
			} 
		} 
	} 

Now compare with the 'untyped' version, in which I also took the liberty in removing the completely unneccesary semicolons. One of my pet-peeves with JavaScript: You almost never need to use semicolons in JavaScript, but everyone does!

	package { 
		public class Greeter { 
			public function sayHello()  { 
				var greeting 
				greeting = "Hello World!"
				return greeting
			} 
		} 
	} 

To prevent the compiler from complaining about the missing type information, use the mxmlc option -compiler.warn-no-type-decl=false when compiling. I tried playing with some options to try to get non-typing warnings flagged as errors, instead of warnings ... and I couldn't. The compiler would complain without the option specified above, but always produced the .swf file in the end.

This example doesn't really do justice to the impacts of typing things. But I think you can imagine how much more un-scannable your code is going to be with typing information littered throughout.

What's the rationale for doing all this typing? From the "Programming ActionScript 3.0" document: "In ActionScript 3.0, type information is preserved at run time, and used for a number of purposes. Flash Player 9 performs run-time type checking, improving the system's type safety. Type information is also used to represent variables in native machine representations, improving performance and reducing memory usage."

So typing helps with two things: 'improving type safety' and 'improving performance'.

We've beaten the type safety issue into the ground over the years; I won't touch that one. But performance? This sounds like premature optimization to me. As in premature optimization is the root of all evil.

May I suggest a comprise: use typing when it provides the convenient side-effect of documentation, and use typing when you need to optimize something. In terms of the documentation-style typing, I'm thinking the typing of 'fields' in an object, and the parameters and return types of methds. In fact, if you just did that, couldn't the compiler infer, to a large extent, the types of local variables?

Brendan also seems to be implying that corporations as a whole seem to prefer to deal with strictly typed languages, compared to 'looser' typed languages. Implying that ActionScript 3, and thus Flex, and thus Apollo, are all being aimed at corporations instead of a more general audience. Assuming this, and combined with the pricing model for tools, which I've already blogged about and ... yeah, you could see this as being marketed at corporations.

I'm constantly reminded of the programming model for the Palm Pilot, since I use mine daily (but only for reading on my walks, using the fantastic iSilo). One of the reasons for the Palm's popularity was that approachable tools were made available to the general public, which allowed for a flood of software programs to be released for that platform.

If you want wild success for your programmable product, make sure your target hacking audience is as wide as you can get.