Thanks to the Agile Ajax blog, I’ve learned about Remember The Milk. Essentially, it’s an online service for managing a to-do list. It apparently integrates with a variety of other services, including Gmail, ICQ, MSN, Skype, AIM, and more. It claims to also allow for task lists to be published and shared with others.
Most serious Java programmers have heard about Scala at this point, I would imagine. If you haven’t, here’s the description from the Scala web site: Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages. It is also fully interoperable with Java.
I was just reading an article about the future of CSS. A main focus of the article is on the extremely poor layout capabilities of CSS. One such paragraph from the article goes a long way towards showing the futility of AJAX development today: CSS is great for simple web style. CSS is awful for layout. Rich Ajax apps need layout. You spend the majority of your time trying to get CSS working correctly!
When it comes to judging programming languages, there are three main factors that we need to consider: programmer productivity, the application feature set that can be implemented, and the runtime performance of the developed applications. There are, of course, many others, including memory usage, portability, and implementation cost. However, memory is plentiful these days, most languages have cross-platform implementations, and many of these implementations are free or have a low cost. So the three factors mentioned in the title become the most important ones.
I saw an article today, written by Clinton Forbes, suggesting that it’s useless to compare compiled and interpreted programming languages. The target of his wrath is this comparison of D and Ruby, with it claimed that it is “comparing apples to oranges.”
That is clearly not the case. It is often necessary, and quite acceptable, to compare two programming languages. Both Ruby and D allow for a human to instruct a computer how to perform various tasks. Thus they are the same thing. The execution method (compilation versus interpretation) is nothing but yet another factor to be considered when performing a comparison.
Today I was reading about Buzzword, yet another Web-based word processor. There is some sort of a Buzzword preview page, but it said the browsers I tried were “unsupported.” At the very least, they could have put up some screenshots of their application on that page, so people like me can see what we’re supposedly missing out on.
We’ve all seen cars that have been “riced out“. Typically, a rather lousy car has all sorts of doodads and gizmos stuck on it. Sometimes this is done for the sake of the car’s appearance. Sometimes it’s done in a vain attempt to increase the vehicle’s performance. Regardless, what often happens is that it’s a costly hassle to modify the car, in the end the car looks awful, the performance actually decreases, and there’s been virtually nothing gained.
I’ve met a lot of end users over the years. Some I have quite disliked, most I am indifferent about, but some I will remember forever. One such user I met today at an insurance company. His job was to perform some actuarial tasks for the company. The work he does is apparently quite computationally-intensive, so he had some pretty modern, high-end Sun and IBM workstations at his disposal.
Recently I voiced my concerns about the IronMonkey effort. It aims to allow programming language implementations like IronPython and IronRuby to run on the Tamarin VM.
My main concern is with regards to the runtime performance of such a stack. In short, running a program with an interpreter that is itself running on a bytecode virtual machine embedded in a Web browser raises many warning flags. When you stack one slow technology upon another, there’s a really good chance that what you’ll end up with with be, well, slow!