I was trying to implement a simple binary search using a purely functional approach, and after much hacking, googling and wikibooking, came up with this in Clojure.

Came across an excellent series of blog posts by Lou Franco, where he uses the SICP videos as input to learn more about Clojure. His explanation of HashMap implementations in Clojure, using multimethods, as well as pointers on parallelizing functional programs are very well written. I'm currently on his day 10 post.

This post contains a list of changes between Clojure 1.1.0 and 1.2.0 that would affect you if you're reading Stuart Halloway's "Programming Clojure".

It looks like you'd have to replace,

with

since the str-utils module got renamed to string, and the re-split function to split.

I was trying to figure out how to AOT compile a Clojure program, in order to really see some fast execution times. The simplest way to describe AOT compilation would be how its done in Java,

The invocation of the Java compiler (javac) is the pre-compilation of the source file, which is then loaded by the JVM in the next step. In the case of Clojure, when a program is run using,

The code is first compiled, and then executed - resulting in large amounts of time for the output to be displayed even for simple programs.

The AOT compile process turned out to be trickier to set up than I expected, so I thought I'd put it out there for all those who get stuck after reading the original documentation at http://clojure.org/compilation.

Firstly, the directory structure for my experiment looks like this,

Directory structure

I created dir1, and its subdirectories as below. The code is in clojure/examples/ and the classes/ directory is the default compile.path - something that the documentation neglected to mention. Without this path, compilation WILL fail.

The .clojure file

This file is used with my clj script, that can be obtained from here.
It contains a list of directories that are to be specified to the Clojure compiler at compile time. The file looks like,

hello.clj

This code of course is the default from the Clojure website, as a test.

The next step is to invoke the Clojure REPL using the clj script, from the dir1 directory.

Type in the following to compile the program in the clojure.examples namespace,

Success! And the resulting output of the classes directory is,

And lastly, to run this program as any other Java program, you can use,

Also, I highly recommend Stuart Holloway's book "Programming Clojure". Its turning out to be an excellent read.

Just came across an excellent blog post by Max Ventilla, the co-founder of Aardvark (a company that Google bought a few weeks ago). His description of how Aardvark was the 6th idea that he and his co-founders tried is pretty uplifting to anyone even remotely interested in entrepreneurship.

What I found interesting was that they would build a prototype and launch it to potential users, and see what the uptake was. If it didn't work, they'd brainstorm some more and launch a new idea to see that worked. It definitely lends credence to the entire build, launch and iterate idea that most people proselytize about, but may not necessarily follow.

Some of these ideas are probably obvious to anyone who's ever brainstormed about web services - I think the main problem with most people out there is that they get stuck on the execution, trying to make things perfect for launch - which negatively impacts the use and adoption of their product.

Another lesson to take home is to have the ability to take an idea from concept to execution REALLY quickly - which means having an established base of people, code, platforms and frameworks ready to start deploying an idea on. If you were to start from scratch each time, I'm not sure if you're going to go too far!

Twang,
For posterity's sake, here's a list of the early ideas we rejected before committing to Aardvark:

Rekkit - A service to collect your ratings from across the web and give better recommendations to you. The system would also provide APIs to 3rd party websites so they could have richer profile data and better algorithms to do collaborative filtering.

Ninjapa - A way that you could open accounts in various applications through a single website and manage your data across multiple sites. You could also benefit from a single sign-on across the web and streamlined account creation, management, and cancellation.

The Webb - A central phone number that you could call and talk to a person who could do anything for you that you could do on the web. Your account information could be accessed centrally and sequences of simple web tasks could be done easily without the use of a computer.

Web Macros - A way to record sequences of steps on websites so that you could repeat common actions, even across sites, and share "recipes" for how you accomplished certain tasks on the web.

Internet Button Company - A way to package steps taken on a website and smart form-fill functionality. From a button, a user could accomplish tasks, even across multiple sites, quickly without having to leave the site or application where the button was embedded. People could encode buttons and share buttons a la social bookmarking.

Each of these ideas turned out to be interesting but not compelling. My cofounders and I would conceive of an idea, build it in very early prototype form, and get it in the hands of users. People might express enthusiasm for one idea or another but they wouldn't actually use the product that, in admittedly raw form, offered the particular value proposition. In contrast, Aardvark (a chat buddy that could accept questions and have them answered by people in your network in real-time), got pretty immediate uptake.

As an aside, most of these ideas resemble products that venture funded startups have since brought to market. Even as I see much more impressive implementations of what we prototyped, I'm skeptical of their mass appeal.