Lisp as an Alternative to Java

I agree entirely. Its a balance, that's why I referenced the qoute from Norvig. Not to show that language has no importance at all but that even in this very particular case the author has a broader point of view than is represented in the article. Anyway even though I don't really miss C++ I was thinking the other day of all the code that I wrote in it when I had no choice but to use it. I got a lot of work done, and it wasn't a mess either. I would say that in my case anyway I tend to think that the language matters more than it does and this (in my case again) is a source of procrastination. So Norvig's qoute is like a kick in the backside for me (focus on what matters) and that's a good thing.

That's true, choice of language does attract certain type of developers. At one time in the past, it seemed that it was for the better goods. But lately, it isn't. Choice of language is used as a recruiting/promotion practice that may not be for the good of the business: they tend to attract people who jump between companies quickly as soon as they found another "cool" technology.

Let's be very very very honest here. Geeks like to try the latest coolest cutting edge. Don't forget to add the allure of working at the coolest hottest startup in Silicon Valley (or the "chance" to be able work, given that you mastered a specific technology) for street-cred and if they're lucky, IPO or big $$$.

How many times you see/hear/meet people switching jobs just because they don't want to be perceived as "behind the time"? (When in reality Google, Microsoft, are still moving forward with old-school technology).

Personally, I felt that there's Fire and Motion (http://www.joelonsoftware.com/articles/fog0000000339.html) going on in the so-called "hacker/startup" community.

At the end of the day, there are some developers becoming the victim of Fire and Motion being executed by a small group of alpha-nerds that write the initial code in their preferred cutting edge technology and left the company for another cutting edge green-field software development, leaving the "legacy 2 years old code-base filled with hacks" to the next group of developers that try to catch up the boat.

OK, enough ranting. Now, can we move on from the whole programming language war conversation?

He is saying that he uses Clojure for personal projects because those are the projects where he doesn't have to recruit for or justify his choice of a niche language.

I'm guessing what he means is that, because Clojure can work so well with Java, he doesn't have to find people with Clojure experience to help on a Clojure project, he can just get Java people (of which there is an abundance).

Getting customer approval is often the hardest part. Back in 2002 I started working with Python and Zope. It was easy to hire and train people in Python and Zope (you can pick up Python in an afternoon and work from there), but it was mindbogglingly hard to convince customers the data not being in a relational database was, actually, an advantage.

> Test cases were not that fashionable back in the day. Surprisingly, people still got work done.

Reinforced concrete did not exist back in the day. Surprisingly, some people still got work done.

It's tempting to be dismissive of modern development practices (TDD, for example) using the argument that a lot of great software was written before it existed. If the icons of the past could write Unix without TDD, why do we need it to build a CRUD app? This is an extremely poor argument against improving development practices.

People were getting building done before reinforced concrete, doing particle physics before synchrotrons, and designing mechanical devices before CAD. Since we have had these things, however, each of these fields has advanced significantly due to their use. It would certainly be possible to design the complex solid forms of something like an iPad without CAD, but it would be much more difficult and expensive. It's the same way with development practices. Modern development approaches, in many cases, significantly reduce the cost and risk of software development.

Lest we forget -

IEEE Standard for Software Unit Testing

Approved December 11, 1986

Actually, for a programming genius, those exact comments in the article seems lazy and ignorant.

Unfortunately the JVM is optimized for Java, rather than for computer languages in general. This is a problem because you can't just say execute function 'foo' on object bar, you have to look up the type of bar to find foo and then execute it.

Clojure gets around this by having all its functions implement a standard interface, and Java 7 has sorta seen the light (still no closures, but they can kind be emulated).

JRuby just suffers.

Well, "very close" might be an exaggeration. C# has lazy evaluation, generators, LINQ, generics, and functions as first class citizens, while Java has... none of those. Or what amounts to none of those.

Overall C# ends up being a much more expressive language. Though obviously C# and Java are closer than C# and Lisp.

The original Common Lisp was more like a community work. It led to an understanding about the language in early 1983. A book about the language was then published in 1984: CLtL1.

The work on the ANSI CL standard started then in 1986 using the ANSI standardization process. An intermediate language description (not a work of ANSI) was published as CLtL2. The ANSI CL standard then still took a few years more work to finalize and publish a standard document.

But the Lisp community does.