Nokia 6120

I finally got around to getting myself a new mobile phone, as it looks like the Android phones may take a while to arrive here in Europe, unlocked, and my old phone was fading.

I ended up selecting a Nokia 6120 in order to get something that runs Symbian, which has a decent amount of apps above and beyond the Java ME stuff.

So far, I’m fairly happy with the phone. Here are some notes:

  • It’s small and light. Nice!

  • It runs Java ME (J2ME) applications surprisingly slowly. I’m non-plussed by this. And no, it’s not just Hecl, even ShopList, which is quite simple and small (~ 6K), takes several seconds to start up. This is not appreciably faster than on my cheap phone from several years ago.

  • My old, cruddy phone was able to recharge (slowly) via USB. This one doesn’t, as far as I can tell.

  • I bought it from, and the bozos who were the ‘real’ sellers sold me a phone intended for the polish market, meaning the dictionary languages installed are all eastern European – no Italian, which I need. Not the phone’s fault though, and I guess it’s probably possible to replace that stuff.

  • The camera has some weird issues where it leaves streaks. I realize that it’s only a phone camera, but it ought to be able to do better. Here’s an image from my recent trip to Oslo, by way of example:

Oslo Fjord

  • Creating videos wors pretty well though.

  • Playing video is just a bit jerky – it mostly keeps up, but not 100% of the time, when you lose a few frames.

  • Nokia ought to do a better job making sure that it’s integrated with Linux (Ubuntu in my case). That said, things work quite well, by and large, and I was able to get things done with relatively little fiddling.

  • The amount of progress over a few years is very impressive. This phone completely blows my old phone out of the water. Sure, it’s a bit pricier, but it’s way more capable.

All in all, I’m happy with it, but I think that my next phone will be some kind of Android-based device, as that system is way more hackable than Java ME, and the people developing it seem to ‘get it’ a bit more.

That said, I’m glad I got it – I needed something modern to play with Hecl on, and hopefully I will be able to work on using some of the fancier bits of the phone from Hecl.

Oh, and by the way, I’m always on the lookout for phones to try Hecl with – even if they’re old and worn out, the only thing that matters is that they are able to run Java ME applications. Contact me for shipping information:-)

Making Applets Suck Less

With all the effort being poured into Javascript lately, it’s pretty evident that that’s the way forward. However, there are still some neat things you can do with applets that you can’t do with Javascript. For instance, I use the microemulator applet to let people play with a simulated phone on the Hecl web site.

Unfortunately, the user experience hasn’t that good. While playing around with the code for that site, Firefox crashed a number of times, and I’ve heard other browsers have trouble as well. No fun.

So it is with some satisfaction that I found this:

It’s an updated Java plugin that seems to work much, much better than the old one. Unfortunately it doesn’t appear as if it will be in the new Ubuntu, as it was released recently, but I’m quite happy to have something a bit more stable to develop with.

You can download that version of the Java SDK or JRE here:

It’s good to see this effort, even if it may be a bit late.

Hecl Syntax: A Survey

[ Taken and modified from a post to the hecl-devel mailing list ]

I’ve been talking with a company about a consulting job regarding a programming language for mobile apps. Sounds familiar, right?

There is, however, a bit of discussion regarding the syntax – my contact at said company maintains that Hecl‘s syntax is unfamiliar to many programmers, and I think on the face of it, I’d have to agree. Of course, Hecl’s syntax is like it is because when I started the project, being very small was a necessity, and a very simple syntax facilitated that goal nicely. Additionally, the syntax allows for extreme flexibility, letting you create new control commands, and “DSL’s” (domain specific languages) easily. Also, sticking with small/simple means that the interpreter and parser can both reside on the phone, instead of doing some kind of solution where the development/host computer compiles the scripting language to byte code, and the interpreter on the phone runs the byte code. That sort of strategy has some advantages, but has disadvantages too: if you don’t have an on-board parser, you don’t get “eval”.

A quick Hecl syntax refresher:

In Hecl, everything is a command, seperated by spaces, and grouped with {}:

if { ... } { ... }

Is a command that takes two arguments. It evaluates the first one, and if it’s true, evaluates the second one. This is different from languages like C, Python or Ruby, where ‘if’ is part of the language. For those unfamiliar with languages like Lisp, where this looks strangest is probably in conditions or other expressions:

if { = $foo 10 } { puts "foo is ten" }


set foo [+ [* $bar 10] [- $beebop $doowah]]

Which is certainly a different take on things than most ‘mainstream’ languages. That radical simplification is, however, one of the ways that I used to save space in the interpreter.

Personally, I’m pretty happy with how Hecl looks, but I am sensitive to the ‘marketing’ argument: popularity helps, and this isn’t the first time I’ve heard complaints about Hecl looking “funny” to people.

What do you think?

A) “I like Hecl just the way it is and wouldn’t want to change it!”

B) “Hecl is quite useful, but I just want a mobile scripting language, the syntax doesn’t matter much.”

C) “I think the syntax is ugly, but I use it because I need an interpreter.”

Also related:

1) “I don’t care too much about code size. My current apps target N kb as an acceptable size.”

2) “Small is really important. The smaller the better.”


I) “I don’t care about eval, or being able to run human readable code on the phone.”

II) “I really like the fact that you can download or even write code directly on the phone.”

And finally:

X) “I don’t care about midp1.0”

Y) “The fact that Hecl runs on midp1.0/cldc1.0 is important to me.”

Now, I am not going to run off and change Hecl! Code that currently runs ought to continue to run, modulo some tweaks here and there, api changes, and the normal stuff. If I do something ‘new’, it would probably be a clean break (although of course code that could be reused would be), and will be in addition to Hecl, rather than instead of Hecl, because I would be working on the ‘new’ language as a day job. I do that with Hecl too, but not all the time, as I often have consulting/contracting work.

New Hecl Release

I’ve added a new Hecl release to the sourceforge site:

Although, as always, you’re probably better off checking it out of subversion. We mainly do releases in order to focus on polishing things up just a bit, and as a way to promote Hecl by creating a reasonably stable release.

Some of the things that we’ve got working pretty well for this release include:

  • Google Android support.

  • Java reflection/integration – call Java directly from Hecl.

  • And of course a lot of numerous other little tweaks and fixes that crop up over time.

An impressive amount of resources

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?

Neat Hecl app from newcomer

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”:

Thanks Lauri!

Hypothetical Hecl

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.