Posted by David N. Welton
Tue, 29 Jan 2008 19:41:00 GMT
I'm a bit tired after driving up to Munich for the Android developer meeting, hosted by Google, and being "on" all day, but it was worth it. I was a bit apprehensive that it might be too 'introductory' in the sense of the Google guys telling you in person things that you could have easily looked up on the web, without spending a bunch of time driving around Austria and Bavaria. Fortunately, that wasn't the case. There was some of that, but also plenty of unstructured time to chat with Dan Morrill and Jason Chen, the two Google "Developer Advocates", who are both very friendly, informative and informed, approachable and put a lot of energy into what they do, despite being a bit tired from flying over from the US. It was nice to get a chance to talk with them, and considering that the platform is still changing, useful as well, because they were definitely listening to what people had to say to them. My thanks to them for a job well done.
Here are some "impressions" I took away - note that they're not what anyone said, just ideas I got about what they said:
Source code is being released when handsets ship because they want to work very closely with the hardware partners to make sure the phone experience is good (they said this). They want to "set the bar high", and they probably run the risk of someone snatching the code and slapping together a phone if they let out the source code to early. (They definitely didn't say this, it's just me connecting the dots).
Despite interest for 'other languages', it really looks like they want everything to go through Dalvik in some way or another. Clearly, at some point in the future, there will be specs for writing Dalvik byte code.
They won't talk about the upgrade strategy, something I asked about. I want to know that as a developer, I won't be stuck with N combinations of things that I have to support over the years. I want to know how they'll minimize that pain, but they're not currently able to discuss it.
Talking with other people attending, there seemed to be some doubts about security and permissions for user data, since Android is moving away from the j2me "everything is private" model, to a model where data can be shared between apps, which opens up lots of good things, but also some potentially bad ones as well.
There's still really a sense of Android continuing to evolve, in a true spirit of openness. I liked that, as it means there is space for people to tell Google what they want, rather than simply being given a finished product and told that that's that... but then again, I would, being the open source guy that I am.
I didn't get to show off Hecl quite as much as I would have liked to, but I did get to mention it a few times, so I guess I did ok.
Tags android | no comments | no trackbacks
Posted by David N. Welton
Mon, 28 Jan 2008 15:25:00 GMT
Tomorrow (January 28th), I'll be in Munich for this:
http://www.mobile-monday.de/web/guest/android
Unfortunately, the event filled up super fast and I barely managed to squeeze in, so there are probably no spaces left. Still, if anyone would like to meet up afterwards, send me an email soonish. If you managed to get in, and would like to see a demo of Hecl, let me know, because I'd like to have the chance to show that off some too!
Hopefully it will be a valuable experience. Android is a pretty convincing system in many ways, but of course has yet to fully come into contact with reality, so I'm curious to meet some of the people involved and hear about it from them. I really hope it doesn't end up being a rehash of information that's available on the web, as it's a two hour drive from Innsbruck.
Tags android, hecl | no comments | no trackbacks
Posted by David N. Welton
Thu, 24 Jan 2008 20:58:00 GMT
This was a pleasant surprise:
I haven't had a chance to actually buy a copy and see if they did a good job with the article, but it was pretty cool to see that it made the cover!
Link: http://webonline.gruppoinfomedia.it/dac/index.php?form_rivista=login&form_rivistanum=65
Tags hecl | 1 comment | no trackbacks
Posted by David N. Welton
Sun, 13 Jan 2008 22:58:00 GMT
I'll be in Zurich doing some consulting work this coming week. If things go well I ought to be able to do drinks and/or dinner on Wednesday. Drop me an email if you'd like to join us!
Tags fsbnet | 1 comment | no trackbacks
Posted by David N. Welton
Sat, 12 Jan 2008 12:22:00 GMT
If you follow online discussions of programming languages, you'll occasionally see articles about language X "dying". It is, however, a bad metaphor, because the "life cycle" of a programming language is different from single biological units, of which you can definitely say at some point "He's not pining ... this is an ex-parrot!".
Once a programming language is widely deployed, it simply won't up and disappear from one day to the next. Too many people and companies depend on it, and replacing it is difficult enough, that the "switching costs" will keep it in place for many years. The obvious example is Cobol. This effect works in favor of languages that are not "the new thing", and means they will probably not truly cease to be used for many, many years.
On the other hand, it's also pretty easy to tell which way the wind is blowing and get an idea of what's hot and what's not. Java got hyped a lot in the past, now it's Ruby. Scala is beginning to get hyped some, so is Erlang. Careful observers can spot the rise of languages as they hit the early stages of the technology adoption lifecycle.
By paying attention to what's going on in the wider world, it's also possible to see when languages are used less and less for new projects, and solely kept on for the legacy systems. I think this is what most people mean by "dying", but of course it creates confusion, because it's clear that the language is still utilized. In some cases, I think it may be possible that a language continues to be more widely adopted, yet still seems to lag behind, simply because other languages are being adopted at a significantly higher rate.
So what it's really about is two factors: how widely deployed is the language in any given moment, and, perhaps more importantly, the rate of adoption - is it accelerating or slowing down? Are more people jumping on the bandwagon, or is the language being used less by innovators, early adopters, and new projects?
You need both those coordinates to understand where a language is at - it may be huge but declining, small but on its way up, or a niche language that never achieved widespread usage that isn't catching on any more. The last one is the one you'd probably want to be wary of. The first two will probably be ok as long as you understand what you're getting, and the type of user or organization you are matches where the language is at in its lifecycle.
I think that perhaps those interested in discussing these things seriously ought to find some good terms to use. "Forth's rate of adoption is declining" doesn't sound as exciting as "Java is dying!" though. "Fortran's diffusion is decelerating" doesn't have much of a ring to it.
Any other ideas?
Tags languages, programming | 2 comments | no trackbacks
Posted by David N. Welton
Sat, 12 Jan 2008 11:49:00 GMT
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.
Tags android, hecl | no comments | no trackbacks
Posted by David N. Welton
Wed, 09 Jan 2008 10:08:00 GMT
Go to http://www.networksolutions.com/
Type in a silly domain name (not something you actually care about!).
In a few minutes, they will have registered that domain themselves, locking you into buying it from them if you actually want it.
They're overpriced anyway, but that's really sleazy.
10 comments | no trackbacks
Posted by David N. Welton
Thu, 03 Jan 2008 09:37:00 GMT
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.
Tags economics, languages, programming | 2 comments | no trackbacks
Posted by David N. Welton
Wed, 02 Jan 2008 20:57:00 GMT
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.
Tags hecl, tcl | no comments | no trackbacks
