Gábor's blog

Today i have found an article about Arc on programming.reddit.com. While reading the article, i remembered the thing that i do not like about Arc. People often talk about problems like fragmenting the lisp-users even more, or about using lisp1 or lisp2, or hygienic macros etc. My issue is different:

Arc does not behave like an open-source project

that’s it. for example:

• what (open-source or free-software) license does the code use?
• where is the version-controlled repository for the project?
• where is the bug-tracker?

The answer to all this is probably that the project is too young, and all this is still in flux, and it will be clarified when the language becomes more ‘final’. I think it should be the opposite way. Paul Graham should have specified the license from the start. They should also open up the version-control-system they use to develop Arc, and if they don’t use one, they should.

If i got something wrong, please tell me. I’d love to be corrected on these.

p.s: if you’d like to try out a lisp that’s usable currently, there are a lot of them. here are some to start with: mzScheme from the scheme family and SBCL from the common-lisp family. Or, if you would prefer to try out something different, something new, try Clojure. It runs on the JVM, so you also have access to all java libraries.

As many other people, i also got my google app account (even crateated a stupid test application. it’s fun to try out such a radically different hosting-environment.

but there is an issue with it seems many do not realize:

the “database” backend of google-app-engine (i will call it BigTable in the following text) is not a relational (read “SQL”) store, and it will never be. for example, it does not support SQL JOINs. but it’s worse than that. because of it’s architecture, JOINS will never be fast there. BigTable is essentially a collection of spreadsheet-tables, where you can do some basic searches, that’s all. oh, and transactions.

for this reason, there probably never will be a BigTable django-ORM wrapper. of course technically it’s possible to implement in python all the missing features, but it’s performance characteristics will not be the same as of a relational-database.

Probably many of you have heard already about Seaside. It’s a smalltalk web framework, where you can write a web-app in a linear style:

let’s say you want to create a web-app which:

• shows a form to the user, where he can enter a number and submit it
• then you show him a second form, where the user can enter a second number and submit it
• then you show the user a page which displays the sum of those 2 submitted numbers

i did a quick check about what source-code-management systems are used by the programming languages that i find important/interesting, and here is what i found:

[EDIT (2008/06/23): (based on the first commenter’s message, it seems the issue i complained about here has been addressed in Git)

i am very interested in distributed version control systems, so i follow the mailing lists of several of them (bzr, git, hg)…

currently my favourite is mercurial btw…

but this post is not about why i chose mercurial.

also not about why distributed version controls are much better than centralised ones (svn, cvs, etc.) (probably will write about this a post at a later point, but not now)

this is about why git is not suitable for me.

intro:

in short, git was created when the kernel developers needed a version control system after the BitKeeper problems, so Linus wrote Git.

it’s a very powerful, and extremely fast version control system. i think, if i would have to decide purely on the features, probably Git would be the winner.

the problem:

but the problem with git is the ..hmmm.. mentality?

it was written (primarily) for the kernel developers originally, and somehow what’s user-friendly for them is not always user-friendly for me.

let’s take a recent example, which i think nicely characterizes the issue:

( the discussion on the git mailing-list )

when you use git, anytime you can do “git diff” which shows you what changed since the last commit, and “git stat” which shows you which files changed since the last commit (this is not an exact definition, but it’s more&less like that).

someone found out, that if he just re-saves a file in the repository without changing it (or in unix-speak: “touch myfile”), then:

1. “git diff” will mention the file, but show an empty diff
2. “git status” will not list the given file
3. if he does “git diff” again (after the “git status”), then it will not even mention the file

so in short, “git diff” behaves differently before “git status” and after “git status”.

when he asked on the mailing list, he was informed that this is not a bug, because for performance reasons “git status” does some things to the repository, which cause that the touched-file does not show up at the second “git diff”.

when he argued that “git status” should be a read-only operation (so that doing it should not affect the behavior of the other commands), he was told that “git status” is not a read-only operation, because in reality it does some internal things in the repository, and also that if this would be read-only, then some things might become slower, etc.

then he argued that while it can be true, that “git status” is not read-only from the implementation point of view, it still should be read-only from the user’s point of view

(for example imagine a simple form of caching of anything.. when you first request some data, they are retrieved, cached and given to you, but when you request it next time, they arrive from the cache. so from the implementation point of view, the retrieval-operation is not read-only, because it writes to the cache, but from the user’s point of view it’s a read-only operation (because to the world outside of the implementation, it behaves as read-only))

but somehow his argument did not get through…

so currently i am not sure if the problem is that:

• the git-developers are not able to understand this distinction between being read-only from the implementation point of view and being read-only from the user’s point of view

or

• the git-developers think that this property of “git status” is not important enough to maybe sacrifice a little performance for it

but whichever is the reason, it just proves for me that git is suitable not for me.

I’ve read today this blog entry about java/c++ performance .

i agree with most of his arguments, but the generics one…