David's Computer Stuff Journal

Long day, lots of broken stuff. Rant time:

• Ubuntu's Intrepid Ibex has way too many regressions. I've mentioned this before talking about wireless, but also on the sidelines are bluetooth and my laptop's multimedia keys. Other things are probably slipping my mind, but that's what's bugging me today. I've use Linux for a while, and am used to not always having everything working just right, but "it's never worked" is less annoying than "it used to work but this release broke it". Also, I bought this computer from Dell because it shipped with Ubuntu. I would have expected the Ubuntu guys to have a few around themselves to test on prior to release.

• J2ME marketing: http://blogs.sun.com/hinkmond/entry/getjar_3rd_annual_mobile_awards GetJar is a nice service, and I put my own ShopList app there, but you can't seriously compare it to the Apple or Android stores without insulting my intelligence. What percentage of people with J2ME capable phones actually use GetJar? Is it on their phone when they turn it on? Can developers actually sell stuff there?

• Google has started dumping lots of my mail in the spam folder since I switched the domain over to a new server. I can't believe they're dumping so much non spam mail, and yet can't figure out that I have never, not once, received an email written in Chinese characters that I actually wanted to read.

Add in some bugs and broken stuff of my own, and it's made for a frustrating day.

Since I recently added sensor callback support to Android Hecl, I thought I'd write about the process of doing so. It's really pretty easy.

Ideally, it would not be necessary to write and compile any Java code to create callbacks in Hecl - you could do it all inline. However, I don't think this is possible at the current time with Android's bytecode engine, although I could be mistaken. It would be necessary to generate a class, or hang some new methods on an existing class. So, for the time being, we do it the old fashioned way whenever anyone wants a new callback to utilize:

The heart of the matter is this class:

public class HeclCallback implements
          android.app.DatePickerDialog.OnDateSetListener,
          android.app.TimePickerDialog.OnTimeSetListener,
          android.hardware.SensorListener,
          android.widget.AdapterView.OnItemClickListener,
          android.widget.AdapterView.OnItemSelectedListener,
          android.widget.CompoundButton.OnCheckedChangeListener,
          android.widget.DatePicker.OnDateChangedListener,
          android.widget.TimePicker.OnTimeChangedListener,
          android.view.View.OnClickListener {

Which as you can see, implements the various Java listener classes. Each of these requires one or more methods to be implemented in order to receive the actual callbacks. Generally, they are done like so:

public void onItemSelected(AdapterView parent, View v, int position, long id) {
try {
    Vector vec = ListThing.get(script.deepcopy());
    vec.add(ObjectThing.create(parent));
    vec.add(ObjectThing.create(v));
    vec.add(IntThing.create(position));
    vec.add(LongThing.create(id));
    interp.eval(ListThing.create(vec));
} catch (HeclException he) {
    Hecl.logStacktrace(he);
    Log.v("hecl onitemselected callback", he.toString());
}
}

Which is pretty simple as well: the objects that are passed in are wrapped up as Hecl Things, and then the command is run.

The command to use is set from Hecl like so, when we create a new instance of the HeclCallback class:

set callback [callback -new [list [list SelectDemo]]]
$lview setonitemclicklistener $callback

So, the steps are:

1. Add an "implements" to HeclCallback.
2. Define the methods that need defining, copying one of the existing methods.
3. Recompile
4. Use the 'callback' command to instantiate a new HeclCallback class with the command of your choice as the handler for callbacks.

I shouldn't have been working on Sunday, but taking care of the flu that I managed to catch from my daughter, but instead I was finishing up my move from Slicehost to Linode, so it's no surprise that I made a mistake and didn't get postfix configured quite right, and so I lost a few days of email to @dedasys.com. Argh! Hopefully nothing too important.

Thanks to Neal McBurnett, Hecl for Android finally got to run wild and free on a real phone. There were some glitches, but by and large, things seem to work, which is always exciting, and something of a relief. Neil says it runs fairly quickly, and looks good. Once again, a big thanks to Neil, and now on to fixing the bugs!

Android itself continues to evolve:

http://fredstechblog.blogspot.com/2008/12/big-updates-ahead-for-android.html

Now, if only I could get ahold of one of those dev phones! Although, truth be told, I think the "G2" or whatever it is, will probably be a significant improvement in terms of fixing up some of what needs improvement over the first generation, so I'll probably wait until sometime next year and get one of those.

It's not really "news" that Dr. John Ousterhout is no longer the Tcl leader, that happened years ago, but it's finally been formalized:

http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/99e2693293b3c945/f4932ae01d74f8e1#f4932ae01d74f8e1

And people at large have taken notice, something that doesn't happen with Tcl very often.

What I think is actually interesting about it is to consider the governance models for various programming languages. It seems that Tcl is something of an exception to the "benevolent dictator" model prevalent in the world of scripting languages. Python still uses this, with Guido van Rossum being the "BDFL", or Benevolent Dictator For Life). Perl used to, with Larry Wall, although I'm not up to date on what they do now. Ruby has Yukihiro "Matz" Matsumoto.

The really big, established, popular languages like C, C++ and Java have committees that run them, although even there, the original development was often by small teams or individuals.

What about other languages, like Lua, Erlang, Scala, Clojure, Haskell, OCaml, and so on and so forth? Which governance model is in use? How does it help or hinder the language's growth and adoption?

One of the things I have noticed running http://www.langpop.com is that, pulling data from different sources, the odds are surprisingly hight that at any given point in time, one of the sources will be out of wack, often in a subtle way that's hard to see in the results. For instance, in the December 2nd run, the Amazon results were a bit wonky, and Delicious has been gradually falling out of the Yahoo search results (weird, that). I decided to go with screen scraping for Delicious, even though, frustratingly, Delicious can't tell the difference between C, C++ and C#, so while we wait and hope that that gets fixed, those languages are all going to show nearly identical results. I have updated the site.

Michael Arrington of Techcrunch comments on the US vs Europe in terms of startups:

Joie De Vivre: The Europeans Are Out To Lunch

It's a pretty rough and coarse-grained view of things, but there's a grain of truth there.

I've written about this a little bit before. It's something that I feel qualified to talk about, having lived and worked in both the US and Europe (Italy and Austria to be precise), and in that time, generally gravitated towards startups.

Here's my quick take on a list of what's good and bad about each. Please note that these are of course not true for everyone, that things are changing, but are still things I think are generally true, even when I could think of several counterexamples for some of them myself. Also, it's very important to keep in mind how diverse "Europe" is, so most of what I write is really about Italy, and to a much smaller degree, Austria. I'd be very curious to hear your own experiences in the comments.

Europe

Bad

• Less of a startup culture and mentality. It's more typical to get a "job for life" and hang on to it for all you're worth. Many Italians are tremendously creative, industrious, inventive people, but are going to find it more difficult to express that in some form of business.

• The side effects of this mean that there are fewer people to talk with, and network with, fewer potential employees willing to risk a startup, and so on. For instance, people are at times more suspicious of a new company - both clients and suppliers.

• As I mentioned in my other article, it takes a lot more money to get started in many European countries - something like 10,000 Euro in Italy. Other places like the UK are cheaper, and apparently Germany is introducing some legislation to ease the burden on new companies. I really hope this changes in Europe because it's such an easy change to make: don't extract money from companies until they're making it.

• More bureaucracy. I think that higher taxes, once you are profitable, might be worth paying for the social system you get in Europe, but the cost of sorting out paperwork falls inordinately on smaller, newer companies. Big, established firms can hire people to deal with all the rules and regulations, and probably have contacts in the government that can help them out in some cases. Smaller firms are the ones whose time is really going to be wasted running around to different offices trying to figure out what they have to do.

• Smaller, fragmented markets. Localization is not a lot of fun in some ways, and trying to translate everything into all the languages of the European Union is a huge undertaking. In the US, you get a huge market with just English and the US Dollar. Even beyond language issues, the culture changes less in the US from place to place, meaning that you have a more homogeneous target.

• Lack of acceptance of failure, both culturally and institutionally. If you go bankrupt in Italy, it's a very serious problem. Apparently (although this is second hand, I'm not 100% sure of it - maybe someone can confirm whether it's actually true?), you can even lose the right to vote. Plenty of people in the US try several times before they get it right.

Good

• Even if your undertaking fails, you still have health care. Likewise, there are other bits and pieces of social support (that change from country to country) that mean you're probably not going to land quite so hard on your rear if things go wrong.

• Lots of smart, educated people. I never lacked for plenty of smart people to talk shop with in Padova, and didn't miss the California bay area at all from that point of view. Open source is really big in Europe - perhaps, in part, because for many people it's a better avenue for their talents than creating a business, when doing so is difficult and less common.

• Work/life balance. Sorry Mike, but the amount of people who are truly going to strike it rich is pretty small. If they want to work hard, great, but it's nice to have some other options, in terms of good, lasting friendships (rather than everything revolving around work), knowing plenty of people from outside your field, people living in and belonging to a community (how many people spend their whole lives in the bay area?). When I moved from San Francisco to Padova in 2000, I went from a world gone mad with money and the dot com craze to one where there were rich and poor, families, young people, old people, and many people who were not working for some dot com. That's not to say that people don't work quite hard in Italy - two hour lunches are a thing of the past for most anyone I know.

• Smaller fragmented markets can be an advantage, too. By the time some valley-based startup finally gets around to noticing that languages other than English exist, it's possible to capture a smaller market. Ok, so you won't be the next Google that way, but there's good money to be had in doing so.

• In some ways, the staid, established, don't rock the boat way of doing things in some industries may present big opportunities for outsiders to come in and pull the carpet out from under everyone. This is especially true of internet/web companies that can get started quickly and cheaply.

US

Bad

• If you're not careful, you can get completely sucked in to work - your life revolves around it, your friends are mostly work friends, and if something happens to your job, a lot of that goes poof. This is especially true in places like the bay area, where so many people are 'transients' - just there for a few years, without any real roots in the area. This is ok if you'll potentially make a big pile of money, but long term it's unhealthy.

• Less of a sense of building for the long term. Personally, I don't want a "job for life", but I think there is some value in loyalty (the genuine sort, not the sort created by legally not being able to lose a job) between employer and employee that has been lost in the US. Being able to count on someone growing with your company, and as an employee, knowing that your company will do what it can to help you out even in tough times are things that capture some value. The US seems to be heading towards a "Coasian" world where everyone is a freelancer, and while that efficiency is hard to deny, I wonder what is lost in the process.

• The competition is tough. Sure, it is in Europe too, but in Europe everyone may compete quite hard during the year, but still all take that one month vacation (although that is becoming a bit less common, especially amongst people my age), whereas in the US almost no one gets that kind of benefit - even if you wanted to take unpaid time off, people would look askance at that kind of behavior. That said, if you need to stay open in, say, August, in Italy, to compete, you are in big trouble, because for many businesses it's simply impossible because it's a chain reaction: all your suppliers and clients shut down, so you really have no choice.

Good

• There are certainly bureaucratic obstacles in the US, but are much more maneageable, and don't hit smaller/newer companies quite so badly.

• It's cheap to get started. As per my other article, the actual state filing fee in Oregon for an LLC is $55, and that's all you really need.

• The culture is definitely there, especially in the right places like the Bay Area, but even in plenty of others.

• You aren't bound to employees for life, and it's easy to find freelancers. I know I'm contradicting myself, but I think it's actually a complex issue, and there are definite advantages to not having people who expect or at least want to find that job for life.

• A large target market. Go online in one state, and you can, for the most part, deal with customers all over the US, in one language.

• Things turn around faster. I have more of a sense that when there are problems, they get fixed. Companies (the debacle of the automakers notwithstanding) are more often allowed to fail, or at least put in Chapter 11. Sometimes this means that when things are bad, they get really bad, but also turn around and get better sooner.

Conclusions

An interesting example of all this from my own experience was Linuxcare. The company was, culturally, a Bay Area startup, with the headquarters in San Francisco, founded by very startup oriented guys (one of whom, Dave Sifry, went on to do technorati, and is currently working on yet another venture). However, most of the actual open source talent was in our satellite offices, in Australia, Italy and Canada, places where, perhaps, people were not so distracted by the prospect of "make money fast!!! hurry!!!" that they had time to work, learn, and create some really great open source code.

To be honest, I find myself torn. Business-wise, I prefer the US. However, outside of that, there's a lot to be said for Europe. I also think that some of what's good about business in the US is coming to Europe, albeit slowly in some cases, in Europe. People my age here can see what's going on elsewhere, and try and copy what they like. A lot of what's good about Europe, though, might be more difficult to import into the US, especially the livability of the cities.

In any case, I can conclude that it's a complex, difficult topic best discussed over a glass of wine.

Antonio Cangiano has an interesting set of Ruby benchmarks here:

http://antoniocangiano.com/2008/12/09/the-great-ruby-shootout-december-2008/

The two results that were interesting to me were that JRuby does so well, and that REE ("Ruby Enterprise Edition") was a significant improvement over "plain old Ruby" too. I knew that the JRuby guys have done a lot of work, and done a nice job with their implementation, but didn't realize just how good it was. REE is a clever idea, but not that much code, and aimed at memory usage, not CPU, so it's interesting to see how much faster it ends up according to these tests.

A few things that would be interesting to see:

• Raw startup time. Yeah, that probably penalizes JRuby, but it is still a scripting language, and using it like one isn't possible if it takes forever to start up. How much slower is it?

• A more detailed look at REE's times. How is it that it's that much faster because of some memory tweaks?

In any case, it's a nice bit of work by Antonio - grazie!

Update - old, slow davidw missed the fact that there was a startup time benchmark included. Oops.

I got this error in one of my Rails apps that I migrated to 2.2. It occurs when you try and send mail with ActionMailer, which makes it especially annoying because the exception notifications I normally receive when there is a problem weren't being sent!

I wasn't able to track down the root cause of the problem - apparently something about an SSL certificate not being there or not being right, but here's the change that causes ActionMailer to fool around with SSL mail:

http://github.com/rails/rails/commit/732c724df61bc8b780dc42817625b25a321908e4

I was able to "correct" the problem (or at least get things working again) by commenting out this line of code:

smtp.enable_starttls_auto if smtp.respond_to?(:enable_starttls_auto)

Perhaps it should be a configuration option, or there should be better error detection with regards to the certificate. If anyone comes up with a nicer answer, leave a comment, but in the meantime, I thought I'd post my quick and dirty fix.

Update

I fixed the problem by running this as root:

make-ssl-cert generate-default-snakeoil --force-overwrite

Which regenerates the SSL certificates.

There has been some buzz going around about Python "surpassing" Perl in terms of "popularity":

http://mail.python.org/pipermail/python-list/2008-November/517191.html

However, they're basing their results on the TIOBE survey, which is, in my opinion, even dodgier than my own, at http://www.langpop.com . It's really difficult to pin this sort of thing down, but I think that by utilizing more data sources, my own numbers bear some relationship to what my "ear to the ground" tells me about what's going on, and certainly more than TIOBE's, which place D, Logo and Lua above things like Tcl/Tk. I know Tcl is not the hottest thing out there these days, but...Logo? D is gaining in popularity, but how many companies are hiring D programmers, how much code is out there written in D? I'm not saying that D is "bad" or "not worthy" because of that - quite the contrary, I think it's on its way up, but there are a lot of things you have to look at in order to take a stab at creating some meaningful numbers, and even then it's important to remember that popularity isn't everything! In any case, picking a precise moment in time when one language "passes" another is also a bit more theater than science, in my opinion.

Getting back to Perl and Python, I thought I'd look at some numbers of my own. Unfortunately they only go back a year, but they already give us an idea of what's going on. In order to concentrate on something fairly concrete, let's look at Freshmeat projects:

Perl is still clearly more widely used. However, I think there's an important distinction to be made in terms of popularity. Since many systems that function ok stay around for years, there's a big difference between what's being used for new systems, and what's out there already. Perl has a lot of code out there already, but how fast is it growing in comparison to Python?

Python's definitely got the edge - it's growing, whereas Perl was very nearly static. To me that does indicate that Python has got momentum right now, where Perl is sort of coasting.