Thursday, June 7, 2007

Firefox 3 URL "Feature"

On the programing subreddit I got to this link, which describes some new features proposed for Firefox 3.

The one feature that received my attention (in a bad way), is the highlighting of the domain of the current site. For example (taken from here), the URL bar would look like this:

I do not like this. The first problem is that the shade of gray is not readable. The next wrong thing, which is not that obvious, but more problematic, is that this could actually help phishers. I can only image an innocent looking Firefox user: "But the site was really Bank Example. I'm sure. The browser even highlighted for me (where one of the letters is not what it seems)".

Please, please, drop this "feature". There is no use case for it. (Ok. there is a small use case, where if the address is long, with may sub-domains, you don't immediately see the top-level domain...)

Thursday, May 31, 2007

Google Gears

Just today I've seen this link on reddit. and I'm very excited about this. Remember an earlier post about off-line web applications Well, they're closer than ever. Google released Gears, which is a Firefox/IE extension that provides an API for off-line web applications.

On the developer page, google posted 4 demos showing off their API.
  • the first one shows how an offline database can be used to keep track of stuff on the client side, without it going away the second time you visit that webpage
  • the second demo shows how google gears can remember an webpage and display it even when you are offline and the cache is emptied
  • I didn't understand the usefulness of the third demo, but I'm sure there are scenarios which use it
  • the last demo is about asynchronous methods, but I'm not sure this belongs in gears.
I am very excited about Gears, as it seems to work for both Microsoft Internet Explorer and Mozilla Firefox. Google says Safari support is work in progress.

For the moment, I'm quite busy with my thesis, but I'm dying to get my code snippet web application to use Gears.

Also, I can't wait to see a geared up version of Blogger and Gmail. Imagine preparing your posts without the need to access the internet and saving them to the local database. Next time you go online, Blogger will upload whatever you've been working on. Sounds cool, right?

I like Gears because the API seems simple enough and is super useful. However, in the long term, Gears (or whatever other framework for off-line web apps will prevail) will make web applications even more difficult to create. Also, I suppose a whole new range of security issues will be uncovered by this new type of applications.

Wednesday, May 9, 2007

To the Java refactoring maniacs

Every once in a while I have a virtual fight with some Java programmer over refactoring tools. They are not available for C++, Python, whatever. How can you even use an IDE without refactoring tools? Do you know how much productivity you gain? The Java language is the best language in the world; it was designed to be "refactorable". Bullshit!

Let's see. Java is known to be a poor language from expressiveness' point of view. Tools save it somehow, and whenever I try to tell someone there are better languages out there, IDEs are thrown into my face and the refactoring tools they provide are the ultimate arguments for Java.

So I set out to prove that the most simple refactoring tool one can think of is not totally automatable, even in a language as simple as Java. Let's wait no more. I clicked Eclipse in my Applications/Programming menu, went and grabbed a cup of tea while it was loading, came back just to see it's asking about the workspace (first time use), grabbed another cup of tea while waiting, and set out to test my theory.

I entered this code:

import java.lang.Class;
import java.lang.reflect.InvocationTargetException;

public class MainClass {
public static void poorName() {
System.out.println("This is a stupid method.");

public static void main(String[] argv) {
try {
MainClass.class.getMethod("poorName", new Class [] {}).invoke(null, new Object[]{});
catch (NoSuchMethodException e1) {
System.out.println("there is no method with name poorName.");
catch (IllegalAccessException e2) {
System.out.println("there is an illegal access.");
catch (InvocationTargetException e3) {
System.out.println("invocation target exception.");

I was initially aiming at fewer lines of code, but then I decided to handle all the exceptions. Simply put, this program looks for a method called poorName in MainClass, using introspection. It then tries to call that method. If the method is not found or whatever, an error message is printed.

As I run this program, I get the nice message:

This is a stupid method.

Then, because I don't like the name of the method, I set out to rename it. Of course, what better way of renaming a method than right-clicking on it's name, and selecting "Rename" from the "Refactor" menu?

Tadam, no error message, method was renamed. Resulting code?

import java.lang.Class;
import java.lang.reflect.InvocationTargetException;

public class MainClass {
public static void goodName() {
System.out.println("This is a stupid method.");

public static void main(String[] argv) {
try {
MainClass.class.getMethod("poorName", new Class [] {}).invoke(null, new Object[]{});
catch (NoSuchMethodException e1) {
System.out.println("there is no method with name poorName.");
catch (IllegalAccessException e2) {
System.out.println("there is an illegal access.");
catch (InvocationTargetException e3) {
System.out.println("invocation target exception.");

When I run this code, guess what? It changed behavior. It now prints:

there is no method with name poorName.

which is true, but sad. There you go: method rename is not computable (anyone care for the mathematical proof?), even in a language as simple as Java (well, the language is not as simple as it used to be, but still).

To all Java refactoring maniacs out there: the next time you want to tell me you're not looking at another language because it doesn't provide automated refactoring tools, please think hard about why that happens in the first place.

Friday, March 2, 2007

Language feature request: define by renaming

A few weeks back, I was looking at Prism. Prism is a probabilistic model checker. This means it can answer interesting questions about your model. For example, when designing a protocol, you can ask it: what is the probability that a message is lost? Or, when building a model of a soft realtime system, you can ask it: what is the probability that an operation will take longer than 100ms. etc.

Anyway, that's besides the point. What I want to talk about today is a feature that I've seen in Prism's model description language (which looks a lot like Promela). Here is the second part of the Prism tutorial. It introduces a language feature that I loved instantly. It is called module renaming and it rocks.

Module renaming basically works in the following way: take this function, which does this. Then create another function, which is exactly the same, but replace this symbol by another.

I can imagine how this can work for a general-purpose programming language. Define a function which sums two numbers:

pseudocode: sum x y = x + y

Then define the product to be like the sum, except replace + by *.

pseudocode: product = sum where + = *

That's nice. So I thought I'd try and see if I can implement this using lisp macros. I don't have much experience with lisp, but here's how I sort-of did it:

First thing's first. Create a function that takes a list and replaces every "source" with "target".

(defun rename-symbol (list source target)
(if (eq list nil)
(if (listp (first list))
(rename-symbol (first list) source target)
(if (eq (first list) source)
(first list))))
(rename-symbol (rest list) source target))))

Here's how it works:

CL-USER> (rename-symbol `(+ 1 2) '+ '*)
(* 1 2)

Well, I actually want to perform multiple renamings, so I replaced source and target with an association list (sort of like a hash table):

(defun association (item alist)
(rest (assoc item alist)))

(defun rename-symbols (list alist)
(if (eq list nil)
(if (listp (first list))
(rename-symbols (first list) alist)
(if (not (eq (association (first list) alist) nil))
(association (first list) alist)
(first list)))
(rename-symbols (rest list) alist))))

Which does the same thing, except it takes an association list and can replace multiple symbols. Here's how it works:

CL-USER> (rename-symbols `(defun sum (a b) (+ a b)) '((+ . *) (sum . product)))

See where we're going? Now let's write a simple macro:

(defun rename (list alist)
(eval (rename-symbols list alist)))

And here's how Lisp's syntax can be extended to allow renaming:

(setq my-function `(defun sum (a b) (+ a b)))

(rename my-function nil)
(rename my-function '((+ . *) (sum . product)))

When evaluating the above, you'll end up with two functions, sum and product, which do what you expect.

Disclaimer: I am a Lisp beginner and I've probably made some mistakes.

I welcome any and all corrections/improvements/suggestions. I would be especially interested in creating a rename macro that works as follows:

(defun sum (a b) (+ a b))
(rename sum product '((+ . *)))

If there is any Lisp guru reading this, please let me know ;-)

Also, I am curios about how this could be implemented in languages such as Ocaml or Haskell. Some of the readers will be quick to point out that this feature is not really required, because you can get the same benefit by creating a function which is more generic that product and sum, which would look like this in Haskell:

combine op x y = op x y
sum = combine (+)
product = combine (*)

But I find the rename feature extremely geeky and cool. So let me have it :D.

Thursday, March 1, 2007

I need a GUI for my application. What library should I chose?

Hi there. I recently had an idea about a nice desktop application that I would like to write. I know a handful of programming languages, but none is very good for what I want. Let me tell you what it is about and please disagree with me.

The application I want. I'm taking a course on Embedded Systems this semester. I'm a CS student, so I don't know much (read: know next to nothing) about hardware design. But I learned about logical gates, and latches, and stuff like that, and I have a pretty good idea about how one would go about building a small processor.

I would like to be able to play with these small hardware components, and I intend to write a small simulator for myself. The basic nonfunctional requirements of the simulator are the following:

  • graphical user interface. Although I understand the superiority of a text oriented hardware description language + parser, I feel that a GUI would allow me to get a better feeling for hardware
  • cross platform

Of course, I have a good idea about how one would go in writing such a program. Except that I can't decide on a programming language/platform for the project because of the lack of good GUIs. Here are my current thoughts on this matter:

  • Java. As far as I'm concerned, even though I hate Java-the-language very much, this is my best choice so far. Java has a decent cross-platform GUI, is reasonably efficient, and I can get around the language for some of the more advanced things I want. However, thinking about the huge amount of code it would take to do even the most basic processing makes me take a step back.
  • C#. I find C# to be better language than Java, but it has a huge problem: it's not cross platform (yes, I do know about Mono).
  • C++. Ah. This is the language that I am most experienced with. Even though it doesn't do garbage collection and doesn't manage the code for me, C++ is somewhat better than Java from a language semantics point of view. However, it lacks a standard GUI. Let's look at the GUI libraries you can find:
    • QT. No thanks. I don't like metacompilers. Compiling C++ code is already very slow; I don't want the metacompiler to take another age. I don't like proprietary. I don't like the license. The GUI code, however, is quite clean and workable with.
    • MFC. NOT. The code is messy, proprietary and not cross-platform.
    • GTK+. The syntax is somewhat better and wxWidgets, but it's still messy. Also, it's not really C++. I don't like reading GTK code. I do like the box feature though. Documentation is not as good as it should be.
    • GTKMM. Better than GTK+ because it's more C++. However, the syntax is still not as good as it should be and it's not as flexible as wxWidgets. The documentation needs more work. If I would chose C++ for this project, GTKMM would probably be my GUI library.
    • wxWidgets. Well, this one is, imho, the best GUI for C++ ever. However, it's just as messy as MFC, and I don't like the code at all. Quite good documentation.
You see, C++ libraries are huge mess. It's very difficult to chose one, and, once you do, you're pretty much stuck with it. Are you sure? [Y,n]
  • Python is one of my favorite languages. It is very easy to write good Python code and you can find a library with good docs for just about anything. However, Python is lacking at the speed chapter. You see, Python can be up to 50 times slower than C++. That can be the difference between waiting one second for a simulation to finish, and waiting 1 minute. Python comes with standard Tk bindings, but I would probably chose it's wxWidgets bindings for extra power.
  • Haskell. Haskell is another favorite of mine when it comes to coding algorithms. Haskell comes lazily evaluated by default, but I'm not very concerned about it's speed limitations. What I am concerned about is that there is no standard GUI library and there are no good bindings to other libraries -- all of them wrap code around the IO monad, making it bad on your eyes.
  • Ocaml is Haskell's older cousin. Ocaml doesn't come lazily evaluated and is dead fast. It is very expressive when it comes to coding algorithms, but the GUI bindings are really bad from an aesthetic point of view.
  • Lisp/Scheme. Which one? I'm sure they are fast enough for what I need, and I'm sure that the code will end up to be very elegant, but I don't have any experience with GUIs for either of the two. Can anyone share some insight into this?

Although I would like to have all the source code in just one language, I'll probably end up choosing one language for the GUI and another for the backend. Currently I'm thinking about choosing Java or Python for the GUI and C++ or Haskell for the backend. Of course, interop will be very fun and I'll probably end up duplicating code between the two languages.

Have fun and may you never need to think about this kind of shit.

Sunday, February 18, 2007

Microsoft blew it with IE

Recently, the Mozilla Foundation announced offline application support for Firefox 3. You see, this is the holy grail of the web. Once you have support for running offline applications in the browser, the browser becomes the framework/platform of choice for any king of application.
You see, until just recently, Microsoft Windows was the platform of choice for most desktop applications. This was due to the largest install base and because Microsoft has done just about anything to make sure that programmers find it easy to target their platform (think MSDN).
A platform is very different from your average library. A platform limits the ways in which you can write code. For example, in Windows, you create so-called applications. You know, you write a window procedure and Windows takes care of calling code for you. Before you know it, you're stuck. Fortunately, all the platforms that you can possibly care about are pretty similar, so if you want to port the code, it's not the end of the world. But it's still difficult. Plus Microsoft gets to dictate the changes.
Platforms are a lot like frameworks. You must write your code to fit the platform/framework. Until recently, Windows was, of course, the platform of choice for general purpose applications (think office applications, etc). Microsoft did its best to keep you locked into their platform.
Then the web happened. Microsoft got really lucky and somehowmanaged to obtain some 90% of browser market. But then, then it screwed up really badly. Firefox started happening. A couple of years of no updates to Internet Explorer later, Firefox is the browser of choice for hackers. Now that everyone who matters runs Firefox, Mozilla (or maybe Google, because they hire the programmers behind Firefox) can go ahead and add their own features of choice. Offline application support is one killer feature.
At the present moment, the only problem that keeps people from totally throwing away their desktop apps and switching to web-based ones is that Internet connectivity is not available everywhere every time. Now that offline application support is being added to Firefox, the browser can become the platform of choice for traditional "desktop" apps. I predict that other issues, such as raw speed, will become less and less important (JavaScript will do).
I also predict that once Firefox gets a big enough market share (say 30-40%), its adoption rate will increase exponentially and we'll see 80% in a very short time. Microsoft looses.

Friday, January 19, 2007

Off to a bad start: XML sucks

I've been meaning to start a blog for a long time now. It's only now that I have the time to do it. Lots of things are getting in the way. One is school. Another is laziness. The other is that software sucks. Anyway, I've made it. Welcome to my blog.

Topic de jour: XML. XML sucks. Why is that? Isn't XML the next-generation all-purpose future-proof data storage/exchange format? Well, no.
  • XML is verbose: you know what? I'm not even going to complain about it anymore; this is a moderate failure that could eventually be fixed without much fuss (e.g. switch to lisp syntax)
  • XML is too complex: entities, namespaces, DOM, SAX, XSLT, XMLReader, XPath, XQuery, XUpdate, XPointer, DTD, XSchema, RELAX NG and these are just off the top of my mind.
  • XML is unfinished: Every one of the above technologies is not finished. You know DOM? Level 1, 2, soon to be 3. The specs are huge; no human should be tortured by having to read them.
  • XML will never be finished: Each and every one of the X* specs will die in a couple of years after it hits gold, being replaced with a newer, possibly incompatible, version. This will go on until the industry will have decided that you know, XML is just so unfashionable, they must move on to the next big thing.
So just why is the state-of-the-art data-storage/exchange format so lame? Well, because the industry is going after a chimera. The idea sounds very nice on paper: an universal interchange format, that is human readable and extensible.

Human readable? No way. If you still think XML was made for humans to read and only incidentally for machines to process, go read some XML to yourself (for the best effect, try a SOAP message, generated by your favorite framework).

Extensible? Yes. You can add new tags. Hmm. But, you know what? After you add that new tag, is your software going to work without modifications? In some cases, yes. Cases you had anticipated. In most cases, of course not; at least not like expected. Also, please remember to redo the DTD/XSchema/RelaxNG or whatever new validation technology will be invented.

So is XML any good? Well, sort of. The best thing about it is settings the record straight on encoding. Another nice thing is the tree structure for holding data. The rest is mostly crap.

Remember extensibility? XML solved a very very small problem about it: the syntax. You still have to determine the semantics of the change. You still have to recode your application to some extent. You still need to worry about incompatibilities between server and client. XML is not the silver bullet. It just solves an accident in the history of computing. It has no essence whatsoever.

Now XML is way over-hyped and will never be finished. Good. What are you supposed to use then? Well, it really doesn't matter all that much. If you need to design a new DSL, you can use XML. But more importantly, make sure you don't create essential complexity. Make sure you put in a version number somewhere. Better yet, chose a well documented text format. Also see the Art of Unix Programming.