Leiningen on Windows/Cygwin

I've started to experiment with Noir which is a web framework for Clojure that seems really cool. In doing so I also made my first close encounter with Leiningen which seems really convenient.
Since I'm using Windows (strange huh?) I decide to run Leiningen through Cygwin (you also have the option of running a batch file but I haven't tried that yet). In doing so I found small problem with running Leiningen plugins.

Downloading and installing the plugin seemed to work as planned:

$ lein plugin install lein-noir 1.2.1
[INFO] Unable to find resource 'lein-noir:lein-noir:jar:1.2.1' in repository central (http://repo1.maven.org/maven2)
Copying 1 file to C:\cygwin\tmp\lein-db2bc8b7-7c28-4c97-a2f1-71caaa04d00c\lib
Including lein-noir-1.2.1.jar
Including clojure-1.2.1.jar
Created lein-noir-1.2.1.jar


When trying to run the plugin it doesn't seem to be installed however:

$ lein noir new first-site
That's not a task. Use "lein help" to list all tasks.

Seems like the plugin isn't installed after all... It turns out that Leiningen, Cygwin and Windows do not seem have the same idea of where your home directory is located. All plugins should be installed under $HOME/.lein/plugins/.


What you need to do is locate where Leiningen stored your new plugin. For example by doing:
$ find . -name 'lein-noir-1.2.1.jar'

Once you know where it is you simply have to copy it to $HOME/.lein/plugins/:

$ cp <Location from previous step>/lein-noir-1.2.1.jar $HOME/.lein/plugins/



That's it! You should now be able to use you're newly acquired plugin.

$ lein noir new first-site
Creating noir project:  first-site
Creating new dirs at:  D:\Development\noir\first-site
Adding files...
Project created!

Project Euler

So, how are things going with my Clojure? Pretty good I think.

I've started out writing solutions to some of the problems (about 10 so far) presented Project Euler (the site is currently down, that's how I got the time to log a post here. :-)). I've also done a Kata or two that I've previously done in other languages. There's also a new project taking shape in my head that I've started writing some code for but I'll write more about that some other time.

I think that there are a number of aspects on learning a new language through Project Euler (PE) that may be of interest.

Project Euler is not designed to teach you programming

As stated at the start page at project Euler:

Project Euler exists to encourage, challenge, and develop the skills and enjoyment of anyone with an interest in the fascinating world of mathematics.

The primary objective is hence (from my interpretation) to dig into the world of mathematics rather than into the world of programming. You simply happen to do some programming along the way to solve the problems presented to you. This is usually done with small snippets of code that (so far) haven't exceeded ten lines.

Since the form of the problem is always the same (create a function which calculates a number which is the answer to a question) and the domain is always mathematics (in particular discrete mathematics so far) there are many aspects of real world programming that are left out. Examples of such include I/O-handling, user interaction, database access and all other stuff that's not hardcore algorithm development. In my experience this caters for at least 90% of all programming time in my professional Telecom/ERPish life.

Furthermore no other feedback is given to you regarding other quality aspects of your solution apart from the correctness of the particular case that it is designed to solve. Unless you really focus on finding weak spots and smells in the code that you're producing your not likely to find them since the solutions are usually not complicated, or large enough, to make that smell stink.

The size of the solutions is also another problem if you were to use PE as your only source for programming experience. As I mentioned earlier I haven't yet seen solutions in any languages stretching more than 20 lines of code. This means that you never get close to features of object oriented languages (and Clojure) such as polymorphism which should be considered an essential feature. You usually get away with one or two loop constructs, knowing a list type and a bit of array juggling and are never really pushed to move beyond those features. One sign of this are the many (often short and elegant) solutions to the problems presented in x86 assembler by people. It shouldn't be possible to write a short and elegant solution to a programming problem using assembler if it's to push your limits as a high level programmer! ;-)

I think that the sizing problem is a bigger issue for someone trying to learn many aspects of a mainstream OO language such as Java rather than for someone trying to learn a functional language such as Lisp/Clojure. My impression is that design in the small (sub-function level) and design in the large (class and package composition) has more in common in functional languages than it does in the mainstream OO languages.

How you still can learn a lot of programming from Project Euler
Given my above findings you might think that I think PE sucks if you want to learn programming. On the contrary! I think it's great! You just have to take some things into consideration when using it as a tool for learning programming. These are a few things that have worked out really well for me so far.

Allow yourself to rush to the solution

I usually feel a bit stressed to find the solution to a problem once I've read and understood it. As soon as I've opened a new problem I&nbsp;immediately want to start throwing code at it to find the solution and get that big green check that you get when entering the correct solution.

The way I'm trying to cope with this is to force myself to take at least one or two minutes to contemplate on the mathematics behind the problem. After that i allow myself to start hacking away until I reach green knowing that I made it (with respect to the only criteria measured at PE).

But then stop, reflect and redo

Once I have a confirmed solution to a problem i force myself to go back and look it over to see if I can find a better (cleaner, faster, more idiomatic) or different (using a different technique) solution to the problem.

Once I've done that I usually hit the PE forum for the problem at hand to see what other persons have come up with (in other languages than Clojure). That's usually a good source of inspiration for another one or two solutions to the problem.

When that's is done I usually hit Clojure-Euler to browse other solutions to the problem that are written in Clojure. That's a great way to pick up some really nice idiomatic Clojure and learn a couple of new functions or macros that you're likely not to have heard of before.

Do more programming than PE

Do not use PE as your only source for exercises when learning a new language. Start a toy project that complements the things that you learn from PE.
An ideal such projects would not require a lot of algorithmic though, that you will get from PE for sure. Instead try to focus on other areas (I/O handling, user interaction, some multi-threading, etc.). A chat client/server is one example of a program that would fulfill a number of the above criterias.

Stop when you feel like

There will probably come a time when you discover that you learn more mathematics from the problems than programming. Then you should stop and consider if continued work on PE is really the best way forward.

Closing Notes

All in all doing PE problems have been a great experience so far. Every new problem is like opening a small present. I know that I still have a lot more to do (about 360 I think :-)) and that some of the points I'm trying to make above may be proven wrong once I move up the ladder. I'll write a new post when I reach 100 solved problems (if I ever)! :-)