Basically: I started with my conclusion, and then went through all the other options and rationalized them away until it seemed like my choice was based on objective reasoning.
I freely admit my personal biases and experiences eliminated a lot of potentially good options without ever giving them due consideration (e.g., Haskell, Scheme, Lua). But I really did try to give the 3 options listed in the article a fair shake at the time.
For what it's worth - I was about 50-50 on using Python till the very end ...
For a programmer without Lisp experience, that would be true. But I've written enough Lisp-based webapps that there aren't really that many 'unforseen' problems for me anymore (rule of thumb: use software by Edi Weitz - everything he writes is golden :-D)).
That being said, I still ran into trouble with Elephant, so I probably should have taken these sort of 'unknown unknowns' (which are more prevalent in unusual languages like Lisp) into consideration upfront. To not do so was certainly an oversight.
It seems like a somewhat precarious decision to let you use Lisp for this project. There's nothing supremely special about the problem you are attacking that warrants Lisp (outside of your comfort level which you clarified very clearly in your post).
Perhaps I'm just old and cynical but I've been on too many projects where the first (and therefore "lead") developer chose a particular language and architecture that in the long term was not sustainable.
As a point of reference, ITA Software has no trouble hiring 100s of Lisp programmers.
Minor correction: I am a founder - and if I were to leave (while my co-founders continued), I'd make a point to find my replacement first.
This one is a tired argument. Any good programmer will grok Lisp (or Python, or Ruby). If your Python/Ruby programmers can't get Lisp from a couple days of training, then they are not good programmers.
And, BTW, I would risk betting they are writing FORTRAN code in Python and Ruby.
This also alludes to the popularity of do-it-yourself microframeworks. If you're planning on using a microframework anyway, I'm not sure your argument really holds up. You can pretty much use whatever not-completely-marginal language you want and be just fine.
Honestly the only valid argument that I come up with is that you can't find enough programmers that know or are excited to know that language to join your team.
Looking at it from that perspective, you are not rationalizing an irrational decision when you explain your reasoning: you are simply remembering/recreating the process that lead to the initial, perhaps even rational, decision.
On the Wikipedia page for 'Anchoring', there is an example about thinking of a number and subsequently bidding (experiment by Ariely). What happens when you tell people with a high number that they are likely to make a relatively high bid, so they should try to make a relatively low bid? Do they make 'normal' bids or extremely low bids?
This shows that saying people can't rid their decisions of that influence is an overstatement. When you are consciously aware of the heuristics and the decision is taken over a period of time, you can downplay them.
One way to explain would be to think about the number of variables we should account for in virtually any everyday decision. Finding even a fairly optimal solution would consume too many resources and evolution has taught us to deal with this using emotional shortcuts. On the evolutionary time scale, the 50 years when the question of choosing a programming language was relevant would be a tiny dot.
On the other hand, rational knowledge can by absorbed subconsciousness eventually. But when it does, we become unaware of it, by definition.