Lisp introduced garbage collection and first class functions, and literal data types (the proverbial “list” in Lisp) fifty years ago — long before these features started showing up in mainstream languages like Java or Python. It’s the original: the real mccoy. It had it all way before anybody else did. It’s forgotten more than mainstream languages ever learned.

Unfortunately, despite being oh so excellent, poor adoption by the mainstream has negatively effected the language. Common Lisp and Scheme lack libraries compared to other languages; there is no CPAN equivalent. As a efficiency minded programmer, you’d do better assembling Lego blocks in Java than writing it all from scratch in Scheme.

But what makes Lisp the 100 year language–the undying, unkillable, everlasting language–is that whenever a new paradigm comes along, somebody writes a new lisp (or an extension of an old lisp) to absorb that new paradigm as a first class feature of the language. As an example, Common Lisp was adapted to include Object Oriented programming, with CLOS (Common Lisp Object System.) Now the latest thing is concurrency, and lisp has an answer!

Clojure is a Lisp with strong concurrency semantics. It can handle scaling an application to many cores, and it interoperates seamlessly with the gazillions of Java libraries out there. You can have Lisp, and your Lego blocks too!

1. “git init” initializes a repository in your current directory. That’s the first command you should execute when you’re putting a project into version control.
2. “git add” adds files into the repository. By default nothing in your working directory is added into your git repository unless you call “git add” on it. That way you don’t waste time versioning your .pyc files
3. “git commit” saves whatever changes you’ve made since the last commit, into your repository. It’s just like making a save point or a check point. Each commit is uniquely identified, and you can always get back to it if you fall off the rails.

The typical workflow for starting a project is:

cd project; git init; git add *; git commit -am “first commit”

At the end of which, you have a working git repository with all your files and an initial commit.

Now that’s only half of it; the local half. Now we talk about the remote portion of git: the part that deals with other people’s repositories, or repositories stored elsewhere.

1. “git clone <url>” is the first step in getting at another person’s repository, where the ‘url’ parameter is the path to that other person’s repository. A common example would be “git clone git://github.com/somedude/his-project.git”. Cloning a repo will give you a complete copy of the repo and all its history.
2. “git pull <remote> <branch>” fetches a remote repository and merges it into your local. The ‘remote’ parameter could be a url like in the clone command, or it could be a name like ‘origin’. If you’ve cloned a repo off of github, you’ll probably be pulling from ‘origin’. Parameter ‘branch’ defaults to ‘master’, which is the branch most people will be working on. As for the basic concept of a branch, that should be familiar to people with previous version control experience. Just know that git can have many branches at a time, and they’re easy to create and easy to merge back into the trunk.
3. “git push <remote> <branch>” sends the commits from your local repo to the remote.

For collaborating, a typical workflow is:

git clone <some-repo>; [[make some changes]]; git commit -am “made some changes”; git push;

If your push fails, you might do a pull, then push.

Common Issues:

1. “git checkout <commit> <file-path>” will restore a file (pointed to by ‘file-path’) from ‘commit’ into the current working directory. If you accidentally deleted a file a few commits ago, and you want to have it back, you might do “git checkout master~2 my-dir/my-file.txt” to get it back. The ‘master~2′ incantation is a special way to refer to a commit: it says go back 2 commits and get me whatever was on the master branch.
2. “git status” is one of the most useful commands (perhaps it should be at the top of this post) because it prints out the status of your working directory. Untracked files (files not yet under version control), modified files, new files and deleted files will all show up under this command. If you can’t remember what you’ve been futzing around with, type “git status” and find out real quick.
3. “git log” prints you a list of your commits, in case you can’t remember what you’ve been doing. It’s essential when you need to checkout an older commit: type ‘git log’, find the commit you’re looking for, and then copy the SHA1 identifier (big alphanumeric thing at the top.)
4. “git diff <commit> <file?>” will give you a diff of your HEAD versus ‘commit’ for either your entire working directory, or just ‘file’. Very useful if you’ve made some changes and can’t figure out what they were ;

For now that’s all I can think of. Next post I should have the screencasts and maybe some additions to this post.

I also have a GUI for viewing documentation and invoking commands.

Obviously it is half-baked. If you’ll notice, the title on the main window is “qttest.rb”, which is not final. The GUI is written with Qt, using the RubyQt4 bindings. I chose Qt because I have some experience with it; though that doesn’t stop me from getting hung up debugging segfaults. Honestly… all you have to do is pass in the wrong kind of object, or inherit from the wrong class and BAM! code explodes, interpreter crashes, program exits, done.

Despite the dangers of invoking third party C++ GUIs, Qt is the most mature cross platform GUI library outside the JVM, I’ve ever used. That doesn’t mean it is the last word, cause I haven’t tried all the GUI framworks, but there’s no doubt Qt is top tier. It even has a nice graphical editor.

The only gripe I have is that its wrappers (PyQt & RubyQt) have trouble producing idiomatic code; thus code ends up being more verbose than it should otherwise be. This problem could probably be solved with a higher level of abstraction. HotCocoa comes to mind. But it’s not that big of a gripe. All things considered, it’s awesome that there are these bindings in the first place. I should count my blessing that I’ve never had to dive in to the Ruby FFI. (or does it even have one?!)

Back to my Autoinstaller; it’s not yet ready for release to the public (in fact, it’s not entirely ready to be used pervasively in my own company) but I like the potential of the DSL for specifying packages, and (if I have the time) it’d be awesome to get it to run on OSX and Windows. Right now it is heavily dependent on the Debian package management system to install most of its dependencies — what it handles for itself are things not in a Debian repository, or source code repositories that need to be pulled directly and then built. But I could certainly substitute in macports or fink or gentoo or portage…