At least one of the links for a paper links to a GoogleTM search for it.

I think the design issues for APIs, DSLs and languages are very similar.

For adoption, the learning curve is very important, and the beginning of this curve is sensible defaults (like Python and Rails), so you can make the common tasks happen fast, while having the power to also do the complex low-level fine-tuning that is less common (and not the first thing you do). There's a learning curve (per user), but also a building curve (per project).

However, common is an attribute of usage, and not intrinsic to the API. You need a lot of users before you know what is common. And, over time, as the world changes, the common tasks change (eg. there are many different internet protocols, but http turned out to be most common).

BTW: just noticed HN automatically adds a [scribd] link for a pdf. Convenience and cross-promotion in one. :-) (edit added pdf warning)

That is good to hear. It seems that quality (perfection?) is secondary to actually building stuff, making mistakes, improving it, learning. As said in your essay, determination is more important than intelligence. Though "an incurable tendency to build stuff" sounds less depressing.

I think the layout similarity was an issue; but it seems to me that they just have demonstrated a barrier to entry (a non-product one).

For a product company, 37Signals does a lot of blogging, conferences, a book and so on. I think the guys are good at this, and they really enjoy it. It makes me think that, in a way, 37SIgnals is really an educational/PR company, that happens to make money from their software. If you want something like what they make, you'll need to pay someone to host it - why not them, since they are nice guys?

Another Java-style construct: Clojure has a do form, which enables you to consecutively execute the following expressions in the list.

It seems to me a way to sneak statements into the language. Or does lisp have something like that as well?

I believe that common lisp's prog1 and progn both do this.

It's pretty realist, it even has a doseq especially for side-effects iterations. It's not that it forces you to be FP (it can't, you can always run java methods), it's that it makes the advantages obvious and lets you decide.

It is my first contact with FP, but what I find incredibly cool is the way the data structures are transparently persistent. If it's true this is a rarity in functional languages, I can't imagine using another one.

I'm curious, what do you mean by "transparently persistent"? Do you mean that you can serialize anything (and so persist it as a file or what have you)?

Uh.. I know it's been 10 days :p

Let's say you have a map, and you change a value in it. Being a functional programming language, and the map being an immutable structure, you end up with two maps: the old and the new. Now, the cool part is every data-structure in clojure is designed _not_ to do this by copying the whole thing. You'll have two maps who share everything except the changed value. Same with collections, sets, trees etc. The work under the hood must be impressive...

Another nice thing (for me at least, coming from imperative programming) is there is a better difference between a variable and a value. A variable is a placeholder, and a value is ... well, a value. In clojure you treat them separately. A better explanation: http://clojure.org/state

Persistent in this case means that if FOO has value '((2 3) 4) and someone does (CONS 1 FOO) => '(1 (2 3) 4); the value of FOO does not change, but the new list shares its structure.

If you do a cons cell diagram for this it will make perfect sense.

I believe 'do' is found in the majority of Lisp dialects.

Yes, but it looks like Clojure's do is not the same thing. Lisp's do is for iteration, while Clojure's do seems to be the same as progn in Lisp.

Ah, my mistake.

I came across this http://en.wikibooks.org/wiki/Clojure_Programming/Tutorials_a... which seems to confirm progn ~ do

I'm just surprised that (it seems) you can do statement-based code in lisp. I thought it all had to be expressions. This feels like cheating. BTW: I can see that progn/do syntactically produce expressions, but the value of all but the last one are thrown away - similar to python in that respect. This seems against the spirit of expressions.

"I thought it all had to be expressions."

This is a common misconception. You are thinking of pure functional programming, not Lisp. Certainly a lot of Lisp programmers, myself included, prefer functional programming. Scheme, especially, leans toward functional programming. Haskell, not Lisp, is rightly known for embracing functional to the exclusion of all other paradigms.

What really stands out about Lisp is support for ALL paradigms, even those that haven't yet been invented. Lisp is an extensible language, that can be changed to fit your needs. Features that would require language extensions in other programming languages can be implemented as ordinary libraries in Lisp. Lisp was the language that allowed experimentation with new paradigms like functional programming, object-oriented programming, and logic programming long before more specialized languages (Haskell, Smalltalk, Prolog) were created to provide specific support for these paradigms.

I agree except that Clojure is specifically intended to be used functional, and not as OO. Clojure is not pure FP as it does allow state changes (in a controlled way), but that's an acknowledgement that state changes are useful and purity can be, I'll say, difficult. The way Java's OO embraces state changes is not the same principle, and makes things more difficult. OO style is possible in Clojure, but that's not what the language is meant for.

This is not cheating. Nothing surprising here.

Of course you can do statement-based code, like in any language that supports I/O(Haskell included).

That's a hard fact and it isn't what functional programming is about.

I've calculated this too (the same round numbers too: 10%, 10 years).

He doesn't mention that you might learn something from each attempt (if you stay in the same industry).

I think your success is (virtually) inevitable - unless there's something that you must learn that you won't learn.

> probably the best large organization for a real , cs focused, software engineer

Makes sense, it's the only multi-billion dollar business based on an algorithm.

Patent-based businesses seem to encourage fundamental technical research. Consider: Bell Labs (Alexander Graham Bell's telegraphy patent); PARC (Xerography patent); IBM research (many patents).

I've used vi for 20 years now (gosh), and it's only in the last few weeks that I've actually started using it properly. One example is that I wanted to save in fewer keystrokes; like ZZ, but without quitting. I came up with this for my .vimrc:

  :map ZA <Esc>:w<CR>

I find the vim help very intimidating (with every possible feature and then some), but it turns out to be really simple to create your own commands. I also made ctrl-N go to the next file (ctrl-P for the previous file), because I do that a lot.

I just created a poll with karma of 196

I created one with a karma of 150, so it has got to be way lower than 200.