.::output >> /dev/null::.

Apple's New Calling: The iPhone -- Tuesday, Jan. 09, 2007 -- Page 2 -- TIME:

"Because there's no intermediary input device like a mouse or a keyboard there's a powerful illusion that you're physically handling data with your fingers. You can pinch an image with two fingers and make it smaller."

(Via Projectionist: A tumbleblog.)

I was actually expecting some announcement about Mac OS X 10.5 Leopard during yesterday's Macworld Conference. Unfortunately, the spotlight seems to be taken by the iPhone and Apple TV. I do not see myself getting the iPhone just yet. It's too expensive, has a touch screen that is probably going to have smudges all over and, I believe, requires a service plan (most probably the higher end ones) with Cingular.

However, what is more interesting about the iPhone is the multi-touch display. Most tablet PCs out there today only support interaction via the stylus. This is good. You do not want your fingers to interfere with the process of writing. However, for some tasks, using the stylus is no better than using a mouse in the first place. For instance, for drag-and-drop, the gesture for the stylus resembles using the mouse.

With multi-touch display, however, you get more interaction. Like the TIMES article says, you should be able to "pinch" with two fingers and have the image shrink. No more having to point at the corner of the picture and drag. This opens a new world of interaction. HCI enthusiasts should begin analyzing and researching new idioms and metaphors for such interactions.

If you have seen the BumpTop videos, you will notice that it is more suited for use with a multi-touch display rather than a conventional tablet.

So, for me, the iPhone itself is not that revolutionary: integrated music player, cell-phone and smart-phone. It's the multi-touch screen that will be interesting in the long run. And it will be nice to see what else can be done with the multi-touch screen for normal computers and laptops.

RubyConf 2006 had a lot of interesting new ideas for Ruby. There is a nice summary of the main points here on the InfoQ website. One feature that actually caught my eye was how Apple was taking part in RubyOSA.

RubyConf: Mac OS X and Ruby:

"RubyAEOSA is a Ruby wrapper for Apple events, that was started in 2001, but not active since 2003. The code required is unnecesarrily verbose. Instead, you could wrap and execute with AppleScript, but it's slower and limited by knowledge of AppleScript.
RubyOSA is a new project created by Apple, intended to be a successor to RubyAEOSA, under active development and used today. It has a much more Rubyish API, generating Ruby code on the fly and sending events lazily. Apple events are completely hidden."

This is an interesting thing for me because I have always wanted to interact more with the applications on OS X but I really do not like the syntax of AppleScript nor the tools that are provided to support it.

A side effect of this is the realization that Apple and other companies such as Sun and Microsoft have actually taken a very strong interest in the Ruby community. Java 6.0 is supposed to have scripting support built-in. However, seeing how the Mac version of Java always lacks behind its other counterparts, we probably will not be using much of this yet.

All the more why I should really try to do some research in this language. Since the idea of refactoring for Ruby is partially take by the RDT team, I might consider doing something in metaprogramming refactoring. That seems like a new field and should be interesting to venture into.

While reading about Aspect-Oriented Programming on Wikipedia, I came across an interesting term toward the end of the article: weasel words. Being someone who just likes word plays such as this, I decided to visit the link.

Wikipedia:Avoid weasel words - Wikipedia, the free encyclopedia:

"Weasel words are words or phrases that seemingly support statements without attributing opinions to verifiable sources. Weasel words give the force of authority to a statement without letting the reader decide if the source of the opinion is reliable. If a statement can't stand on its own without weasel words, it lacks neutral point of view; either a source for the statement should be found, or the statement should be removed."

What is interesting is the list of examples of is that most of us actually use such innocuous phrases when we are trying to write objective and unbiased articles. I know that I have been guilty of phrases such as "clearly...", "it is believed that...", "experts say...".

However, while avoiding weasel words are important, I think that sometimes they are a good addition to an article. It is almost impossible to be unbiased when you are writing an article. Usually you write an article because you have some strong opinions on it. Thus, your opinion is going to be reflected in that article. Indeed, that is what makes some articles better to read than others. Your tone of voice and the choice of words used speaks to the reader and draws him or her into the writing.

Of course, regardless of whether we are writing for an encyclopedia or for our web blog, we should always be careful of weasel words. Using too many of them makes for unclear articles that are hard to follow. In fact, some of the weasel words listed in the article are so common that we even forget that we are using one. Even readers might easily gloss over those words as mere phrases that join sentence together (there must be a term for these kind of words but I can't seem to remember it). On the other hand, trying to stay away from them also makes for articles that are too dry and boring to read. A proper balance is hard to achieve but as long as you are trying to be unpretentious in your writing then it should work out well.

Q&A: Jobs on iPod's Cultural Impact - Newsweek Technology - MSNBC.com:

"In a word, no. I've seen the demonstrations on the Internet about how you can find another person using a Zune and give them a song they can play three times. It takes forever. By the time you've gone through all that, the girl's got up and left! You're much better off to take one of your earbuds out and put it in her ear. Then you're connected with about two feet of headphone cable."

You gotta respect Steve Jobs. With just that one sentence, he has made Zune's main marketing tactic (the ability to share songs wirelessly) sound pathetic. Now anyone who had originally planned to get a Zune will be reminded of this sentence every time they try to send a song to the girl sitting next to them.

Guest Post: DavidCo's Robert Peake on "Getting Software Done" (part 1) | 43 Folders:

"GTD in this way also provides the ultimate "safety net" for making sure stuff doesn't slip through the cracks. Sure, the act of programming in itself is highly linear: you run down the path until you have satisfied your test cases, then you move on to the next thing. However, in addition to bookmarking your progress along the path so that you can get right back to what's important after an interruption, GTD also gives you a complete, trusted inventory of all of the very next steps along all possible paths. Combined with an overall strategy (obviously), this means you can program with greater confidence and peace of mind - can run down the trail knowing it is the perfect trail for you to be running down at this moment - because you have scanned all the other options first, and know this course to be the best. Life, especially the life of a developer, is an open-ended, unknown tree. And the breadth-first approach of GTD is necessarily the most efficient option for traversing that tree."

The above is an interesting read on how GTD might be applicable to programmers. The author is a programmer with a degree in poetry so that might explain his metaphorical examples.

Be sure to check out the second part to this post that compares GTD to Extreme Programming.

defmacro - Why Exotic Languages Are Not Mainstream:

"Haskell is an excellent programming language. It has features that allow for a tremendous productivity boost. Type inference figures out and lets you examine types of every piece of code that you write so you don't have to baby sit the compiler, yet you get the benefits of static typing. Functions are first class objects so you can build abstractions without writing useless glue code. The language is elegant and has plenty of syntactic sugar that makes it a pleasure to work with. It even has libraries for things you may want to do in a real world project. So why wouldn't you want to pick Haskell for your projects?"

There are a lot of great programming languages out there. But having a great language alone will not be able to get people to program in it. There must be the tools to help you be productive in it. No matter how many lines of code savings you could potentially shave from a more expressive language, the returns are not going to be all that great if you have to invest the time to write your own libraries for common tasks. It's actually kind of like a catch-22: people cannot really start using the language unless there are good libraries for it; but libraries will not be written if they aren't enough people using it.

One of the reasons for Java's success was backing from Sun Microsystems. They had this incipient language out in 1995 when C++ was still reigning champ of programming languages. However, Java was quickly bundled with lots of libraries that worked together nicely. There was the GUI layer, the enterprise architecture, the sound, etc. At that time, none of the libraries was particularly mature yet but Java was able to entice people who were already were tired of trying to find out how to get different libraries to work together.

In the article by defmacro, he also lists another tool that is missing for esoteric languages: a good IDE. A normal text editor - as Vim and Emacs users will tell you - is sufficient for most tasks. But what happens when you need to write lots of code in different packages? Actually, Vim and Emacs are great because of the underlying unix tool support that is built-in. For instance, ctags and cscope really help make a project easier to navigate and Vim and Emacs have support for them. However, ctags and cscope do not support a lot of languages. For people who are spoilt with all the features from an IDE, using a normal text editor that just offers syntax highlighting is barely going to be fun.

It's hard to get people to abandon their mindset of what a development environment should be. Most people are already used to the idea of having a debugger, IDE, good reference and libraries at their fingertips for serious productions work. So, if esoteric languages want to really take off some of these things that people take for granted have to be offered first.

But then again, esoteric languages might not really want to take off. True, you can use Erlang and Haskell and Forth and ... in everyday situations but that might not be the original intentions of those languages. All I am saying is that certain languages were not created to be mainstream languages. They function well in their own little niche and the few people who use it are already happy with the tools that are provided.

Stevey's Blog Rants: Egomania Itself:

"How many 2-word anagrams of 'Agile Manifesto' do you think there are? Guess what? There's exactly one: Egomania Itself"

Don't get me wrong. I like Agile methods. I think they are better than the other heavy weight methods out there. But as Jeff Atwoods mentions, the real problem is not even about being agile; it's how to get people to stop using the Waterfall model. And even then, the waterfall model does work pretty well for small projects.

But as Steve Yegge has so very well pointed out, there is life outside of Agile.

ArticleS.UncleBob.PerformanceTuning:

"All this just leads back to the title. Performance tuning is perverse. What you think is going on is seldom what really is going on. Who could have guessed that limiting the outer iteration to the square root of the maximum would yeild just a 2X increase in performance? Who could have guessed that the algorithm itself was linear?!"

Optimizing is a dangerous game. It's always tempting to try to make small tricks here and there which you think are going to help your program run faster. However, unless you actually check out the speed increase, you will realize that those small tricks do not matter significantly.

I used to do little tricks such as that in C/C++ or Java as well. Maybe it's the nature of the language that allows such "optimizations". I don't do such optimizations when using Smalltalk or Ruby. At this stage, some of you might decide to jump in and say: 'cos that languages are so darn slow to begin with. Ruby might be slow (for now) but there are variants of Smalltalk that run almost on par with C.

For instance, in a function, I might think that a calling another function (say pow()) a couple of times is going to really slow. So I cache this value whenever possible by assigning it to some variable. Sure, everyone knows that calling pow() is going to slow so caching that value especially if you are going to use is going to make great difference right? Not true. Caching variables for something like this is what a compiler ought to be able to do by itself. Caching variables can be something short-termed because when you actually have to modify your code, you might forget to change all the places where you use that cached variable. Maybe you cached the value for pow(number, 3) and used it in four different places, then if you ever need to use pow(number, 2) you have to allocate a new variable and all that again. The changes that need to be made to your code to accommodate that change might not be trivial.

So unless you have a profiler at hand and real world usage data, your suspicions on what part to optimize is going to be wrong. For an algorithm that is always going to be linear, O(n) at most what you can do is speed it up by a constant amount. Unless you change the algorithm, there is no way you can suddenly get to O(lg n) performance.

Five Worlds - Joel on Software:

"Embedded Software has the unique property that it goes in a piece of hardware and in almost every case can never be updated. This is a whole different world, here. The quality requirements are much higher, because there are no second chances. You may be dealing with a processor that runs dramatically more slowly than the typical desktop processor, so you may spend a lot of time optimizing. Fast code is more important than elegant code."

But then again, such tricks are important when you do not have a great compiler. For instance, on embedded systems. It's hard for people to write great C compilers for every microchip there is out there. You can be pretty sure that the C compiler you are using for the ATMegatel chip is not going to be as good as the one you have your desktop. In such cases, little tricks on the developer's part does work. That was pretty much the reason why people wrote in assembly last time when the first C compiler came out: it just wasn't good enough yet for demanding tasks like games that push the limits of the computer.

The Emperor’s New Clothes Syndrome:

"The problem is that although we know exactly what doesn't work right and how it should be fixed, most of us will never say anything. We don't say anything because there's a very good chance the minute we do we will be marked as uncooperative, pessimistic, or simply detached from the business reality."

So the next time your team member suggests so clever little optimizing trick, please think it through before actually implementing it. Most clever little tricks that used to work great in the past might not be so necessary anymore. Things like loop unravelling should definitely be left to the compiler so that you do not generate weird amounts of code that no one else can clean up after you. Seriously, think about it. The same goes for over-engineering, I guess but that would require more articles before I can come to a valid conclusion.

I have always wondered why the fonts in Firefox/ Flock looked so bad sometimes. Why do they allow the fonts to get so small that the text becomes barely readable? Well, I found out today that there is an option to prevent that. Go to Preferences. Select the Content tab. In the Fonts & Colors section, select Advanced... And change the minimum font size. It works wonders! Now, the page does not look so bad anymore.

I think Safari by default already has the minimum font size set for it. I am amazed that Firefox/ Flock did not do the same.

Coding Horror: Separating Programming Sheep from Non-Programming Goats:

"All teachers of programming find that their results display a 'double hump'. It is as if there are two populations: those who can [program], and those who cannot [program], each with its own independent bell curve. Almost all research into programming teaching and learning have concentrated on teaching: change the language, change the application area, use an IDE and work on motivation. None of it works, and the double hump persists. We have a test which picks out the population that can program, before the course begins. We can pick apart the double hump. You probably don't believe this, but you will after you hear the talk. We don't know exactly how/why it works, but we have some good theories."

(Via reedit: joel.)

Here is a direct link to the original paper. I looked at the test script and all it tested was assignment. And they were not complex assignments that you might expect to see in a program that supports it. For instance, in Ruby, you can do this: a, b = c, d. Nope, nothing like that. Just plain simple a = b.

Some of you might be wondering why a test like that can actually measure programing aptitude. Here is my opinion on that.

• You need to understand what variables are. For instance, a and b are just names for some value. And they can be easily replaced by some other name like 'cat' and 'dog'. This indirection is even more important when it comes to pointers and other data structures.
• You need to remember state. For instance if you assign a to be equal to 10 at the beginning and change its value somewhere else, you need to remember that a can only take on the latest assignment.
• You need to understand what sequence means. Programs do not just jump around, There is a proper sequence to the execution of each line.
• You need to know when words that you do not understand will not affect the outcome much. For instance, regardless of whether you know what 'int' means, you should be able to guess that the next statement does. This is really important when you learn a new language. Good programmers are familiar enough with programming concepts that different syntax will not throw them off.
• The ability to notice that sometimes any relations between the value themselves are purely coincidental. For instance, having the first three odd numbers might throw someone else off to think that this question is different from the previous one. While it is important to notice trends in the numbers, it is also important to realize that those trends can be purely coincidental. The underlying principles of assignment do not change with different numbers.

I looked at the answer script. It does not only demand the right answer. Instead it assigns different categories for different answers. This would be the proper way to grade a test such as this. For instance, some people might prefer to do left to right assignment making the result of a = b being that b gets the value of a instead of the other way around.

I am going to read the draft of the paper later tonight. Any updates will be posted here.

Update: It seems that the survey was done only with 61 students. Hardly a conclusive figure I would say. And the paper is a bit too colloquial to merit much academic attention. Therefore, I do not believe that their postulation has been proven.

Update: Head over here for more discussion on the topic.