David's Computer Stuff Journal

In the TechCrunch coverage of Google IO, I was impressed by this:

Not every team has the resources Google does to build for every platform. Google is betting on browser over time for mobile devices; it will be the entry point for many applications.

But today, the only browsers capable for supporting mobile apps include iPhone and few others. So Google is developing Android, which includes world class Webkit browser.

Here at the world headquarters of DedaSys LLC (which for the time being happens to be "in front of David's computer, wherever that is"), we too have some suspicions about the browser becoming the platform of choice for mobile phones, although there is a big if:

When will the carriers make always on, cheap internet connections widespread?

Until that happens, client side apps will still probably dominate for many things. And of course for applications requiring hardware access, some kind of local program will be necessary as well for the foreseeable future. (And of course, Hecl is a good choice "for the time being", too!)

Coming back to the phrase cited above, what blows me away about it is the sheer amount of time and money that they're investing in something that "over time", they're not really betting on, in the sense that they just want browsers everywhere? Jumping into a market with a new "OS", toolkit, etc... just to spread a platform with a decent browser?

Wow. That is a company with a lot of spare change. Most people and companies in business are doing the best they can to stretch out their dollars or euros as best they can. I guess it really takes a behemoth to pour so much in the way of engineering talent and financial resources into something that's in some ways a bump in the road in terms of their long term vision. Or maybe I'm just reading too much into one phrase?

I write most of my email (in gmail) and submit most web site content in English, however, a significant portion is also done in Italian. I leave the spell checker in English, because Italian is, in general, quite easy to spell, so that even as a native speaker, a helping hand is occasionally welcome. However, it isn't as if I write Italian perfectly either, so the help there would be nice as well. I find it quite annoying to go change the language in the spell checker option each time, especially when, as an example, I'm responding to email and do 2 in English, one in Italian, another in English, and so on.

Ideally, some sort of adaptive technology would be possible, where it figures out what language I'm using, out of a preselected list, after a few words, and starts behaving accordingly.

It seems as if there is some discussion, so hopefully a solution won't be too far in the future.

I've seen a lot of people talk about simply reinstalling Ubuntu with the latest CD in order to update it to the latest version. I think that's a bad habit from other OS's. For as long as I've used Debian and its derivatives, the ability to update the system has been one of its strong points.

Here are some reasons to run the updates instead of upgrading via a fresh install:

• You don't lose your old configuration information, and by choosing to see the diff's in configuration files, you can even choose which config files to update, and how.

• No need to shut down a running system.

• By keeping an eye on obsolete packages, you really don't build up any cruft at all, so that's not a reason to do a fresh install.

• With a decent internet connection, it's probably just as fast, if not faster, when you consider it takes a bit of time to get everything installed just the way you want it.

Indeed, yesterday, I upgraded a server I run in Texas from Ubuntu's edgy eft to hardy heron, remotely, with one reboot at the end to make it pick up the new kernel, and the whole thing came off without a hitch!

This is a cool little application, and a helpful tutorial for people trying Hecl for the first time. Since I know the system so intimately, people doing these kinds of pages are always a helpful reality check, pointing out where people new to the language hit stumbling blocks, and providing a guide for people who haven't "been there and done that":

http://lauri.ojansivu.googlepages.com/heclcommandlineapp

Thanks Lauri!

A little off-topic exercise conducted in the "eye of the storm", when Ilenia and Helen were still in the hospital:

A post on Seth Robert's blog brings up the idea that many Chinese restaurants were opened as a way to go into business without competing with native male workers. The post made the rounds of several other online journals.

That was the push I needed to get up and go collect a few statistics of my own, regarding an idea I've been kicking around for a while. My theory is that the number of restaurants of a given type, divided by the number of immigrants from that country might be an interesting way of guaging the popularity of the cuisine in question.

In order to simplify things just a bit, I actually used data from Italy, for the following reasons:

• Most immigration to Italy is pretty recent, so it's not necessary to account for the length of time different immigrant groups have been present, and the effects that may have had on the diffusion of a given cuisine.

• Immigration statistics were readily available: http://demo.istat.it/str2006/index.html

• Italian the language almost completely corresponds to Italy the country (outside of a chunk of Switzerland, San Marino, and the Vatican), something that makes things that much easier.

• I speak Italian, so it was easy to find out all the information I needed

Unfortunately, finding out the number of restaurants of various types is far from an exact measurement, and since this is a quick fun project, I just went for Yahoo search (they deserve credit for keeping their search API open when Google's was closed) results on terms like "Ristorante Turco" (Turkish), "Ristorante Messicano" (Mexican), and so on. This was the most expedient means of gathering information quickly, but this approach does present a number of obvious problems, listed here in the hope that someone without diapers to change and a business to run might come up with some good answers:

• Some hits likely come from people talking about a restaurant that happens to be in a country, like "ristorante americano". "Nel tipico ristorante americano, ...." or in other words, "In a typical American restaurant", rather than an American-style restaurant in Italy, which is what we were looking for in the first place. This is probably also true of countries close to Italy, where people go on vacation and thus have occasion to write about their experiences in a "ristorante tedesco" (German), rather than going to eat in a German restaurant in Italy. Perhaps the search query could be improved in an attempt to eliminate this sort of false positive.

• Some restaurants probably are not known as, nor brand themselves with a country name, but instead utilize titles like "Middle Eastern", "Arab", "South American", "African", or others that do not correspond with any one country in particular. It would be possible to group countries together with other adjectives, and get statistics for these clusters as well.

• Measuring hits is measuring what people are talking about, rather than simply restaurants that exist, so if restaurants from a certain country are more talked about than others, that would muddy the statistics a bit. However, it seems reasonable that people would mostly talk about restaurants in proportion to their popularity, and I don't see a particular reason why there would be more talk of Vietnamese restaurants, say, than Thai restaurants, compared to the actual numbers.

That said, for a quick project, this approach seemed to work out ok, and the results appear credible. Obviously, the results also reflect people discussing certain cuisines, rather than an actual number of restaurants, but since it does reflect interest, we'll use the number in any case.

Since the number of restaurants/interest in a type of restaurant was clearly not correlated directly with the number of immigrants, other factors must come into play. For instance, "ristorante giapponese" turns up 125,000 hits, but the stats say only 6873 Japanese nationals live in Italy. As above, hits don't mean actual restaurants, but clearly Japanese cuisine is not being popularized through immigration.

Here's my guess: these statistics show, to some degree, what people in the host country actually like to eat. Food that tastes good means more restaurants. Things that aren't that popular mean few restaurants, even if there are many immigrants. To pick on one country, there are many Philippino immigrants in Italy, but very few search hits - and anecdotally, I've never seen a Philippino restaurant in Italy either, whereas even smaller towns like Padova have Chinese, Mexican (well, it's called that, even if it's a shadow of the real thing), Japanese, various Arab and middle eastern restaurants, and even a few less common things like Eritrean. And I know that many native and foreign restaurants employ Philippino cooks.

Below is the chart I whipped up showing the number of Yahoo hits per immigrant. The Italian names shouldn't be too hard to figure out. A few tricky ones: Giordano-Jordanian, Giamaicano-Jamaican, Spagnolo-Spanish. If you're interested in numbers or source code, contact me.

These few days when Ilenia and Helen are still in the hospital are the eye of the storm for me. It's quiet at home and I actually have a few free hours when I'm not allowed to be in the hospital, or when they need to get some rest.

One of the things I managed to do recently was some Javascript hacking in order to create a timeline for LangPop.com: http://www.langpop.com/timeline.html. It was fun, because most of the "heavy lifting" is done by Timeplot, and I just had to push the data into place. Of course, there isn't much interesting there because the site is relatively new, but it should be interesting to see how languages fare over time.

I did some hacking on Timeplot to make it easier to host it on my own server, and to load a bit faster by stuffing it into one big ugly blob of Javascript. When I get a bit of time, I'll make my changes public, as I think they're fairly useful for anyone who wants to fiddle around with Timeplot some, and thus host it themselves.

The other thing I did with the site was switch the X and Y axis of the charts, because that works out better in terms of screen space for the labels, with so many languages to keep track of.

I normally avoid topics of a personal nature in this journal, as it's meant for programming / business topics, however, I am extremely happy to announce the birth of our first daughter!

I did some 'playing' with Hecl the other day, to see what it might look like if implemented in a slightly different way, and I thought I'd share what I was thinking about. Keep in mind that

1. I haven't thought this through completely:-)

2. It's not something I'm going to just rush out and do in the near future. It's definitely a Hecl 2.0 sort of idea.

My notion was to make use of the ClassCommand feature to have at least simple types be hooked directly to the relevant Java types, and dealt with through methods, rather than commands. For instance:

$i + 10

instead of

+ $i 10

Where $i is, in the first case, a Java Integer, rather than a Hecl type.

What it would be doing internally is something like this:

1. $i is recognized as the object to act on.

2. It's an Integer, so the corresponding ClassCommand is looked up and executed with + and 10 as arguments.

3. The classcommand for Integer has a + method that accepts an argument, in this case, 10, which is added to the value of $i, and returned as a new Integer.

Without a "real" (where real also means bloated, memory and space hungry) parser, Hecl is never going to have a C-like syntax - you still wouldn't be able to do foo = 1 + 2 + 3 - but this just might make a significant amount of people more comfortable with Hecl, which would be a good thing. You could do something like this:

set i 1

while { $i < 1000000 } {
    set i [$i + 1]
}

instead of

set i 1

while { < $i 1000000 } {
    set i [+ $i 1]
}

I actually built a really simple HeclInteger class that implements < and + as methods to Integer ObjectThings, in order to test out this idea, and it seems to run about as fast as the regular Hecl version.

I welcome any thoughts or comments on the idea.