New Hecl Release

After four or so months, it’s time for another Hecl “checkpoint”. Those who are seriously interested really ought to be getting Hecl from subversion, however, it’s a good idea to tie up the loose ends every now and then, and put something that’s easy to fetch for the casual user.

https://sourceforge.net/project/showfiles.php?group_id=122383

This release contains a number of interesting things:

  • Alpha support for Java integration. For example:

      java java.lang.System sys
      set ms [sys currentTimeMillis]
    
  • Alpha support for Google Android. This utilizes the Java integration system above heavily. What sets it apart from just writing code in Java is that on top of the building blocks, I’ve started to write little bits of Hecl code to make common things very straightforward, layering on top of the Java API.

  • Numerous fixes in the code, documentation, and build system.

No next big language?

Ola Bini, one of the JRuby hackers, and a very bright guy, posits that there “won’t be a next big language”:

http://ola-bini.blogspot.com/2008/01/language-explorations.html

There might be some that are more popular than others, but the way development will happen will be much more divided into using different languages in the same project, where the different languages are suited for different things. This is the whole Polyglot idea.

I’m dubious, and wonder what he would consider to be the underlying sociological and economic factors driving this change. Programming languages are, in the end, about people in all their weirdness, so to understand where languages are going to go, you have to consider those human factors, as I’ve attempted to do here.

One trend that points to a slow proliferation of languages is of course the lock-in cited in my article. Today’s big languages (Java, and on the web, PHP) won’t just go away from one day to the next, just as C, Cobol and Fortran have not disappeared with the advent of Java. That process will continue, making it likely that new languages will carve out new territory for themselves rather than exclusively cannibalizing existing installations from older languages. This naturally leads (slowly) to more languages, even if the next generation has a Next Big Language.

And why shouldn’t there be one? Ola talks about a situation where various languages run and interact on top of a runtime (JVM). Isn’t that similar to what we’ve had with C, though? Perl, Tcl, Python, etc… all run on top of C. Sure, the JVM is a step up from that in some ways, most notably GC, being a bit more consistently cross-platform, and having a wider array of libraries, but in the end, it still comes down to the network effects of being able to read and write a common language, whatever it runs on. Obviously, the network externalities of programming languages are not so strong that they hit a tipping point after which one language crushes all the others, but they are strong enough to consolidate leadership in one or a few languages. Programmatically, Jython, JRuby, (and Hecl?:-) may even find it easier to interact on the same platform, but the humans writing the code will still push for consistency and the minimum set of common tools in order to aid the sharing and review of code.

Another way to look at it might be from an organizational point of view. Today’s biggest fish in the pond, Google, only allows four languages for their production systems. What would a “no big language future” organization look like? I can’t believe they’d welcome a big hodge podge of things.

In conclusion, as computers are ever more widely used, it’s certain that more languages will be utilized. However, it’s also likely that from time to time a few languages, with one in the lead, will emerge as the leaders.

Tcl and Tk 8.5 out

Actually, they were out a few weeks ago, but I’ve been on vacation at the in-laws’ near Monselice, Italy. The release announcement is here:

http://www.tcl.tk/software/tcltk/8.5.tml

It’s worth writing about, because it’s been a long time in the making, and contains a number of improvements. Particularly noteworthy in my opinion are ‘real’ hash tables (dicts), an even better sandbox model (Tcl and Java have the best sandboxes that I know of), and a theme engine for Tk that, in the right hands, significantly improves how it looks.

In the fickle world of language fads, Tcl doesn’t get the respect that it should these days. Like anything, it has problems, but what doesn’t, when examined up close? It’s ironic that for years it has gotten things right like Unicode support, and OS-level threading, that are currently being worked on in Ruby.

Hecl obviously owes a great deal to Tcl, but since it’s a new language (more or less necessitated by cell phone limitations), we’re free to take a stab at improving things that Tcl doesn’t get right.

In any case, Tcl is worth a look if you want to play with something that’s fundamentally different from a lot of popular languages, and the core team has put a lot of work into the latest release, so give it a whirl (perhaps using tkcon instead of the readline-less tclsh executable) with an open mind, and see if you don’t learn something new.

Android Task List / Selector

Credit for finding out how to do this goes to dims, who has been doing lots of cool Android hacking lately:

http://davanum.wordpress.com/2007/12/18/android-task-manager-primitive-prototype/

If you’re interested in Android and what it can do, you should be following his online journal!

As a way to keep pushing and testing Hecl, I decided to see if I could copy what he’d done in Hecl. It has indeed produced a few improvements to the Java code. That done, making it work was short and sweet:

set layoutparams [linearlayoutparams -new {FILL_PARENT WRAP_CONTENT}
set layout [linearlayout -new $context]
$layout setorientation VERTICAL

# Create ourselves some commands to access Android internals.
java android.app.ActivityManagerNative activitymanagernative
java android.app.IActivityManager iactivitymanager
java {android.app.IActivityManager$TaskInfo} taskinfo
java android.content.ComponentName componentname

java java.util.List javalist
set am [activitymanagernative getdefault]
set tasks [$am gettasks 10 0 [null]]
set len [$tasks size]
set tasklist [list]
for {set i 0} {< $i $len} {incr $i} {
    set baseactivity [[$tasks get $i] -field baseactivity]
    lappend $tasklist "Task: [$baseactivity getpackagename]"
}

$layout addview [textview -new $context -layoutparams $layoutparams 
         -text "Currently running tasks"]

set lview [basiclist $context $tasklist -layoutparams $layoutparams]
$layout addview $lview
$lview requestfocus

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

heclcmd setcontentview $layout

proc SelectTask {parent view position id} {
    [activitymanagernative getdefault] movetasktofront $position
}

It could have been squeezed further by avoiding some of the temporary variables, and perhaps also by implementing a mapping between java.util.List and Hecl lists.

I think one of the next things I want to do is work on some infrastructure so that people will be able to actually work on scripts on their phone. That’s sort of a departure from the past (most phone keyboards would be sheer torture for inputting long scripts), but it’s a cool demo in any case.

Announcing Hecl Android Alpha and Hecl Android Developer Challenge Entry

Alpha Android Hecl

I’m a little bit nervous about the idea, but I decided that I might as well release early, because for the foreseeable future, there’s always going to be “one more feature” I could add.

So, without further ado, I’m going to announce that I have a version of Hecl running on Android that has a access to a number of Android wigets. It is available here:

http://www.hecl.org/Hecl.apk

Hecl Android Demo

However: this is an alpha release, for those interested in hacking on it. If you are bothered by broken code, don’t like to report bugs, don’t want to think about how to improve it, complain loudly about missing features, then this code is not for you yet. Soon, I hope, it will be stable and useful for many more people, but for the moment, a lot of things are up in the air:

  • Hecl’s java reflection interaction code, which lets us interact with Android’s API without writing wrappers for all of it, is very new. It was written specifically to facilitate the Android port. So it might change. For hackers, the opportunity is to be able to take part in shaping it.

  • More work needs to go into the threading model. Wolfgang Kechel built a nice system of timers and events into Hecl, but work will be needed to make those play nicely with Android.

  • More API coverage is needed. We have a number of the basic widgets, but more are needed.

  • Storage is still something being worked on. I want to have a Hecl script Provider so that other applications can access Hecl scripts, as well as Hecl commands to access the various types of permanent storage that Android makes available.

  • Phone features – we want to have callbacks and commands to deal with phone features like sms, phone calls, the camera, and so on.

  • Needless to say, none of what currently exists is documented besides some comments in the code!

Of course… Hecl itself is a pretty cool language, I like to think, and the fact that it’s interpreted means that you don’t have to recompile anything, you just

  1. Edit your script.
  2. Replace the script in the zip file: zip -r bin/Hecl.apk res/raw/script.hcl
  3. Load it up on the emulator: /opt/android_sdk_linux_m3-rc37a/tools/adb install bin/Hecl.apk

You can do other cool things too, like downloading bits of code over http and running them.

Hecl @ Android Developer Challenge

I hope that people interested in hacking on Hecl will do so because it’s fun and interesting. Being an early adopter means you have a lot of influence in shaping the future of this programming language, and the API’s to interact with Android (or Java ME if that’s your thing).

However, seeing as how Google has put together this contest:

http://code.google.com/android/adc.html

I have decided to submit the Android port of Hecl, and split the prize money, should we win any, with those who have contributed to Hecl. That includes any and all contributions to Hecl, whether or not it’s directly related to Android or not. So, with documentation, Java code, Hecl code, tests, and even improvements to the web page as valid things, there’s room for everyone to get involved. Of course, in order not to paint myself into a corner, I reserve the right to make final decisions about percentages, but it should be roughly equivalent to lines of code added, deleted or modified (yes, deleted counts too – if you make the project that much slimmer without sacrificing functionality, that’s wonderful!).

Also more than welcome are people who want to submit their own projects to the developer challenge based on Android. We make no claim to your winnings, and we’ll be happy to give you a hand.

Interested?

Join the Hecl mailing list, that’s where all our discussions take place:

http://sourceforge.net/mailarchive/forum.php?forum_name=hecl-devel

Hope to see you there!

Free Software Beer Network

I’ve actually had this idea floating around in my head for a while. Recently, I mentioned it on a Debian list, where it was well received. Since I don’t think I’ll be able to implement it any time soon, let me just throw it out there:

One of the cool things about belonging to a group like Debian or the Apache Software Foundation, or other similar groups is that there are people all over the world that are often willing to meet if you’re in their area.

Wouldn’t it be cool to have a centralized resource where you could post something like “hey, I’m going to be in Paris/Perth/Padova/Philadelphia/Porto Alegre/Pretoria, anyone want to get together for a beer or whatever people drink there?”.

You’d have to balance it some – make it too generic and it loses some of the appeal – part of the appeal about meeting someone from a group you belong to is that you instantly have something to talk about. Extend that too far and it would just be like meeting random people on Facebook.

I don’t have the time or inclination to pursue the creation of such a site, but it would be quite simple, I believe.

And of course, if anyone is headed to Innsbruck, I’m always happy to go out for a beer!

Programming languages are not like hand tools

I have seen the “right tool for the job” comment one too many times, and felt like writing something about it.

Real tools are pretty simple, really. Things like saws and hammers have been around for thousands of years, and don’t require a great deal of thinking to understand. Some people are masters with hand tools and create wonderful works of art with them, but the tools themselves are not complex.

My programming language, Hecl, is a pretty simple one in a lot of ways (it has to be, to fit on cell phones), and at last count, the core has 7670 lines in a rough count that includes comments. That entails quite a few “moving parts” compared to even something like an electric drill. Programming languages are complex. Certainly to create, but even to use well; to understand the nooks and crannies and ramifications of the language’s design is not something that is accomplished in a few days for most people.

Your average programmer really doesn’t know all that many languages, and even those who know many probably don’t use most of them on a day to day basis. I like learning new languages, yet still wouldn’t relish the idea of going through the mental task-switch required to move between too many in one day.

What this means, is that when there is a job to be done, most programmers will reach for what they already know, rather than the best possible system, and that makes sense. If you know Python, why not write web software in Python, if you get asked to create something for the web? Or if you know Tcl because you create gui’s with Tk, you’re still likely to pick it when you need to create a little server. There are reasons why something like Erlang might make for a better server platform than Tcl, but is it that much better to justify dropping everything, learning a new language, committing to a new set of infrastructure requirements, and adding another thing to ask of people joining your organization? Most likely, it is not, unless the server you’re writing is for a telephony switch that has to be on all the time, in which case, yes, maybe you do need Erlang. If, as is often the case, it wasn’t something that had to be the best in the world, all that extra time to learn a new language would have been mostly “wasted” (ignoring, of course, the fact that for individuals, learning new things is almost always good, but that’s not what we’re talking about). Even the smart folks who hack away in languages like Haskell are fond of using what it has to offer, rather than jumping ship to something else at the first hint of the “something else” being better at their language of choice for a given task.

So both Tcl and Erlang were up to the task of creating a little server. You could have used Ruby or Python as well. Java might prove a bit more verbose, but it’s certainly up to the task. Any number of languages would be, of course. So it’s not like there is a “right tool” and a “wrong tool”.

Maybe a better analogy is languages are like toolboxes, or even whole workshops, full of tools. Most of them have most of the common tools like hammers and saws, some sort of web libraries or the means to create tcp/ip servers. Where they differ is in things like the amount of tools available, the specialized tools that you get for free, the craftsmanship and ease of use of the tools in the hands of both experts and beginners… or in some cases (lisp, say), some fancy tools and supplies that make it possible to build yourself some new tools if you need to (that only you know how to use, but that’s another topic). Some sets of tools really aren’t very good for some jobs – you don’t want to build blazing fast 3-d shooter games in PHP, just as you wouldn’t want to use a regular set of screwdrivers on a delicate watch. However, even though you’d want to use a toolset that also has some specialized tools for working on the watch, you’d rather own a toolbox that came with the watch tools as well as the regular Phillips screwdrivers, because those are pretty handy around the house, and it wouldn’t do to have only the watch tools for fixing common household items.

The point being, languages are big investments, so those that do more, even if they’re not the absolute greatest or first choice for a given task, are generally going to be more useful to more people, especially those just starting out who want a “safe” choice, a language they know will let them do a variety of things, rather than only one or two things (pound nails, say) really well.

Charlie Munger’s criticism of economics

I found this transcript of a speech by Charlie Munger thanks to Greg Mankiw’s blog:

Academic Economics: Strengths and Faults After Considering Interdisciplinary Needs (pdf)

Despite the very dry sounding title, it’s an astute criticism of economics that I greatly enjoyed. My own interest in economics stems from attempting to understand how things like open source software and programming languages fit into the world at large, and what forces govern their rise and fall. Economics is generally a pretty good way of thinking about problems like that – one of the best there is. But it’s certainly a system that is far from perfect, and Munger points out some of its defects in an effective way, without going overboard and trashing the whole discipline, as some do. His words give voice to somewhat vague doubts in my own mind, and back them up with the experience and successful career of Mr. Munger. Like all good criticism, it’s also constructive and suggests improvements rather than simply tearing down.

I don’t agree with his complaints about free trade and China, but they’re not completely without foundation, and that’s probably a discussion best left to someone else’s online journal. Suffice it to say that I think he’s performing a bit of slight of hand by turning hypothetical numbers where everyone is objectively better off into a relative ranking, where there can only be one “winner”.

Overall, though, it’s a good read, especially if you have read a few things about the subject of economics.

Android Bug: Radio Groups/Buttons

This was informally confirmed by someone at Google:

Given this layout code:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
  android:orientation="vertical"
  android:layout_width="fill_parent"
  android:layout_height="fill_parent"
  id="@+id/ll">
</LinearLayout>

And this Java code:

public void onCreate(Bundle icicle)
{
    super.onCreate(icicle);
    setContentView(R.layout.main);

    LinearLayout ll = (LinearLayout)findViewById(R.id.ll);

    RadioGroup rg = new RadioGroup(this);
    rg.setLayoutParams(new LinearLayout.LayoutParams(
            LinearLayout.LayoutParams.WRAP_CONTENT,
            LinearLayout.LayoutParams.WRAP_CONTENT));

    ll.addView(rg);

    RadioGroup.LayoutParams rlp = new RadioGroup.LayoutParams(
        RadioGroup.LayoutParams.WRAP_CONTENT,
        RadioGroup.LayoutParams.WRAP_CONTENT);

    RadioButton foo = new RadioButton(this);
    foo.setText("foo");
    foo.setLayoutParams(rlp);
    rg.addView(foo);

    RadioButton bar = new RadioButton(this);
    bar.setText("bar");
    bar.setLayoutParams(rlp);
    rg.addView(bar);

    RadioButton baz = new RadioButton(this);
    baz.setText("baz");
    baz.setLayoutParams(rlp);
    rg.addView(baz);
}

The resulting radio buttons fail to be mutually exclusive. This is a bit frustrating, as Hecl doesn’t utilize the XML layout system. Or rather, you can use that if you want, or you can create everything in Hecl.

All radiobuttons selected

The individual at Google says the problem will be fixed in a future SDK release, so hopefully things will work in the near future. I also hope it’s open sourced soonish, so that problems like this can be fixed without requiring the intervention of “the hand of Google”. Of course, in this market, there’s also the issue of things being shipped on hardware, where open source or not doesn’t matter much if the bug is out there, because you simply can’t fix it on millions of devices. Hopefully the product that ships will be very solid.