TheDarkTrumpet.com

I’ve recently begun to dabble in Clojure, a rising project with a fair bit of drive behind it. In a lot of ways it kinda reminds me of the Rails drive, in that the project itself is changing quite rapidly and a number of new people are joining the ranks fairly quickly. First, it’s worth mentioning what Clojure is – incase you haven’t heard of this before. Clojure can be defined as a lisp-like language that sits on top of the JVM. The purpose of it is to give the power that Java has in terms of concurrency and libraries and combine it with the best features of Common Lisp, without including “ugly-aspects” of the lisp history (extremely subjective…)

Common Lisp was pretty much the first language I’ve ever used that I actually fell in love with. There are many things that Common Lisp supports; including a REPL for interactive programming, extremely flexible error handling (restart case, handler case), macros, the multi-paradigm universe, and so on. I’ve found it extremely difficult to really think in a functional way when programming in PHP, Ruby, Python, and so on. Most of my programming, therefore, was done in Common Lisp because it feels cleaner and more simple. Clojure, though, I am finding is a nice balance point that Lisp has a difficulty meeting when it comes to being applicable to the masses. It includes much of the benefits of Lisp, but gives the options to call Java code too. Clojure feels also a little more on the functional side than Common Lisp does in a lot of aspects, or at least the presentation feels to lend itself more toward the functional aspect anyways.

Clojure’s project page can be located here:
http://clojure.org/

Using Clojure is fairly simple and straightforward. There are currently 3 books (that I’ve seen) for this language that talk about syntax, setup, and so on. The one book I decided upon was Programming Clojure, from the Pragmatic Studios. The book is fairly cheap and is of decent quality. You can find a link to it here:

http://www.pragprog.com/titles/shcloj/programming-clojure

There are many editors that support Clojure development, with plugins. Each one of them have different ways of being setup. Personally I settled upon using Emacs and Slime because that’s what I use for my Common Lisp development, and not having to change development environments is really helpful for me. Emacs and Slime may be a bit of a jump for many people, so there are many options when it comes to editors out there. Netbeans with Enclojure was well recommended from my searches. Textmate also has a LISP mode (but it doesn’t have the REPL – I really recommend not using it for serious development).

Clojure is also fairly simple to setup, as long as you find a good guide for doing so. Unfortunately there are many ways to setup Clojure and at a minimum you need JDK, ant, and so on – but this may differ significantly depending on your editor of choice. Emacs with slime offers an option in Emacs 23.X, for automated installed from using ELPA. To be honest, and I really hated this option, setting up this all by ELPA was probably the most simple. Your jar files are downloaded automagically to the ~/.swank-clojure directory and things are magically setup. If you use emacs 23.X and don’t currently do common lisp development, then this will work well. If you want to build stuff manually, and aren’t using emacs then your best bet is to get maven – then build your clojure .jar files accordingly. You can find detailed directions on building it on Ubuntu here:

http://riddell.us/ClojureOnUbuntu.html

If you decide to use Emacs, this video has been helpful from my perspective:

http://www.bestinclass.dk/index.php/2009/12/clojure-101-getting-clojure-slime-installed/

For general clojure development, there are a few areas that I find extremely helpful is leiningen. Essentially what this tool does is give you a working directory that makes clojure development a bit easier. There’s little I can say that the project page doesn’t say better – so you should visit this:

http://github.com/technomancy/leiningen

One last thing I’ll add is if you do Common Lisp development as well. If you do, some time may be sunk into trying to figure out how to make that work. Following the directions in the video you’d be left with an (eval-after-load “slime) block. In there, add something like: (add-to-list ‘slime-lisp-implementations ‘(sbcl (“/usr/bin/sbcl”))), then run slime by hitting M– (hold meta hit dash), M-x and type slime. You should get a prompt that asks you what lisp, type “sbcl” then enter. The other issue I want to bring up is CVS version of swank/slime don’t work with clojure. You should get git://github.com/technomancy/slime.git instead. Note that if you use ELPA to install clojure and deps, it will already install parts of the compatible slime. Running M– M-x slime, sbcl will generate errors about not being able to find source .lisp files. You can fix this by going into the .emacs.d/elpa/slime-../ directory and copying all the .lisp contents from the slime checkout from technomancy into this directory. If you find a cleaner way of accomplishing this, without separate .emacs conf files, please add a comment.

Clojure is a bit of a handful to get started on, but if you find yourself having problems I’d check the google groups group for clojure, and #clojure on freenode IRC.

Common Lisp surprises me more and more each and every day. I never thought of using it for SQL interaction, but the adventures of CL-SQL for my linguistics class lately really opened my eyes.

CL-SQL is an ORM, like that of ActiveRecord, Django’s ORM, and so on. It leans a little more toward the SQL Alchemy side of things, though. I will likely provide a much more detailed tutorial later once I get a general understanding of this library – but for now I’ll provide a bit for links on where to find more information:

CLSQL Main Site: http://clsql.b9.com/
Script I learned a lot from: http://www.boundp.net/files/weblog.lisp
Github post of my wordnet stuff: http://gist.github.com/244360

Now for a bit of information about wordnet. I’m currently in a computational linguistics course at the university, and part of the class is to develop a project of sorts. Mine relates to the use of wordnet, which is a fairly complicated database. Basically, wordnet was developed by Princeton, that has a fairly large set of words and their definitions, synonyms, hypernyms, hyponyms, and so on. In sort, it shows a lot of ways that one word relates to another word in various ways. I found a web site that had the MSSQL files for Wordnet, which I downloaded and attached. Along with that, a number of example view code that I modified to add to a listing of views. Since I do my development, most of the time, on Linux – I decided to get ODBC setup to the MSSQL server. CL-SQL works beautifully with this setup. The gist above shows the details.

For the SQL Server database I got, you can view the information here: http://opensource.ebswift.com/WordNetSQLServer/

I will likely provide more information as I go with this, as I’m finding wordnet more and more fun to mess with.

I finished my presentation for Iowa Code Camp this morning – it went pretty well I feel, although a very little turnout. Here are my notes and other information!

Here are some download locations for my notes and my code itself:

Sides themselves:
http://static.thedarktrumpet.com/theory-iccn09.pdf

Code:
http://static.thedarktrumpet.com/code-iccn09.lisp

About a year ago, I decided to ask a number of people what I should read, and what I should do to be a better programmer. Over the next year I spent a lot of time with these same people trying to learn how to be a better programmer. This book, Coders at Work, is one of those books which turns out to be one of the most helpful programmer-guides I’ve come across.

- Structure of the book:

At the start of each “chapter” (which is really an interview), there’s a short description about who each individual is. From there the chapter continues with a basic “interview-style” format, where Peter asks a question, and the interviewee answers it. Usually there’s a followup question to clarify the previous answer – which has both the positive and negative effects to say “Person A answered this way, person B answered this way” – so in other words, at times it’s hard to say, for example, how Zanwinski’s answer differed from Peyton’s.

The first question asked is one very crucial for most people, though, which is more or less, “How did you get into this?”

- Topics Covered:

The topics covered is not specific to only coding – some of the topics include:

• How did one get into coding?
• What were some successful projects?
• What were some less-successful/failure projects and why?
• What type of education is useful (e.g. is a PhD useful?)
• What tools does one use and why?
• What does one enjoy about programming?
• How one works with others and the dynamic of that.

This book is not only about coding though! That’s an important thing to recognize about this book – it’s leaned a bit toward programmers in general, but these topics help to make a better programmer in general – not simply specific to just coding better.

Some of the topics discussed feels a little dated, with some technology that’s being discussed well before I was born, but since many of these challenges exist as timeless and I see in my everyday life, they are still valuable to hear about.

- Likes:

The main thing I enjoyed about this book was the fact that it’s extremely applicable to what I see each day. A perfect example was the very first chapter in talking with Zanwinski. In this chapter, he discusses the concept of “Worse is Better”, and how the strive for perfection caused a company to fail. This very concept rings extremely clear to me, in I’ve seen a system that was developed in the “Worse is Better” philosophy, and the development of the current system has seen times where the “Right Way” caused huge delays in the development of the system. It was a breath of fresh air to hear someone else discuss a situation that was really close to one that I’ve been, and in some ways continue to be, in. This is the main thing that I feel I enjoyed about the book itself.

Another applicable thing I read was the reasons for getting a PhD – which I’ve been contemplating for well over a year now. To hear perspectives about the reasoning to get or avoid one helps a lot in the contemplation.

Along with that, the topics were very interesting – and many of the answers were very clear and to the point. One can tell that these words were exactly the way the person said it – and not edited. This is a great feature because it feels more like a dialog than just a story-telling session.

- Dislikes:

There are a few areas of the book that I feel could have been done a bit better.

• When describing more old technology (e.g. the computer that Peyton learned on), I felt I had no clue what this device looked like or anything. A quick google can help in a lot of these situations, but there’s a certain disconnect from the book itself as one’s reading. This can happen especially for younger developers who haven’t heard of some of this technology.
• The rants on some of the languages (e.g. Perl) can be taken poorly by some. I found it kinda funny, and it’s clear that it’s the individual’s opinion, but I can see some people being annoyed by that. There’s not a lot that can be done about this besides cutting out content.
• Better identifying similar crucial questions that are asked to each individual would be helpful to hear the ideals that are different between each person. Those, with a special icon or something, would have been very helpful for comparing and contrasting differences.

- Summary:

Overall, I feel this book is quite good, a definite 4.5/5 stars. This book gives a “mentor feeling”, when I honestly don’t have a mentor at this point at my job. I found that many of the questions in this book provided insights into the difficulties I’m currently presented with, and offers suggestions on how to approach them. While this book will likely not be the totally definitive guide for all programming-related knowledge, it’s definitely something I feel fits in a niche that currently isn’t occupied by other books. I feel this will benefit all levels of programmers.

I’m sure most that are reading this already know what TDD stands for, but to those that don’t know it’s termed as:

Test Driven Development

The basic idea is somple. When you write your code, you – well, don’t – you write the test first, then write the code. There are a few reasons for this:

• Code is better guaranteed to be covered.
• You can think through your problem, as you’re writing it.

TDD works great and all, if you really know what you’re working on – what the end project is going to be, and have the general design built. Many people, including myself, want to see more immediate results rather than spending time writing tests first.

As I was writing my Common Lisp library for interfacing with git (will provide links later), I wanted to write unit tests for my code. I feel that writing the tests before the code would have not worked. There’s just little/no way for me to really know the structure given my current experience and understanding of Lisp in general. Waiting until the end of the library to write tests would also be equally stupid, because that’s a lot of time invested and likely full rewrites needed to help make code testable.

The area I’m advocating at this point is a “middle ground” to the two testing methods. I found for the Lisp library, that I could do this pretty simply by thinking of:

• What are my chunks of functionality?
• Are my functions doing one and only one thing (really well?)

For each chunk then, what I’ve been doing is the following iterative development:

• Write the code first
• Start writing tests for the fuctionality (denoted by comments if needed)
• Writing one test for each function.

What this has done for me is allowed me to think of my code in a smaller scale – each node of functionality has a testable purpose now. So my iterative development has been something like:

• Write code
• Write test for the code
• Rewrite code to be more testable (usually if a test has more than one assert in it or a totally different assert than what’s necessary)
• Write tests for the new split-out code (basically just split out what I was testing before)
• Rewrite code again to make it more testable

…etc, etc until it’s “good enough”

I found that this helps me with great code coverage without forcing me to really go full TDD – which is really hard to grasp. It may be worth trying for some others who want to improve testing but don’t feel the jump to TDD is really in their grasp.