Code Monkeyism

It’s hardly Paul’s fault that his software got rewritten and then obsoleted. By that point he wasn’t involved, as far as I know.

He chose a language, wrote some software, it worked well, it got bought, it got rewritten in someone else’s choice of language. I can’t imagine how that is a failure on his part.

That’s faulty logic. If I write a program in Java, and sell it to a company who use .NET, and they then rewrite it, it wasn’t a mistake of mine to write it in Java.

Lisp was actually his advantage (or so he asserts) at the time - in times before Python, Ruby, etc. It’s not a mistake to play to your advantages. As you say, it may have been a mistake to buy it instead of just being one of Paul’s customers.

I agree with Stephan, Paul Graham is making some serious sampling errors.

But I’m not sure that it was a mistake to write Viaweb in Lisp. In the parallel universe where he chose a good production language, he might not have been able to leverage his skills (and Morris’s), and therefore may have lost the race. It’s worse-is-better, in the twisted sense where Lisp is “worse”!

If Paul Graham simply said, “Using Lisp by a few Lisp hackers is the best way to get a website to the point where you can edge out your competition and sell out to a big company” I think he’d be right. But as you say, that’s not his conclusion.

Stephan, aren’t you making the same mistake you’re accusing Paul Graham of making? Do you think Paul’s evaluation of Lisp is based solely on the fact that he made a lot of money selling a product that was written in Lisp? The fact that he made a ton of money in that venture may certainly depend on many factors outside of his control, but if you’ve read much of his writings about Lisp, I think you’d find much evidence for Lisp being a good choice for many situations besides a one-time business deal that went exceptionally well.

Regarding your statement about “good code usually depends on the production environment and the skills of the developer”, Paul made a very relevant comment about the latter which you may find interesting. It’s at the bottom of my blog post below:

http://lojic.com/blog/2008/01/17/2008-programming-language-plan/

Also, do you have evidence that Yahoo found the code unmaintainable? Surely you realize there are many possible reasons why a corporation would do what they did, and only some of them are technical.

Stephan, if you can’t see any evidence that “Lisp may be a good programming language for many situations”, then, in my opinion, it’s either because you’re not looking, or don’t want to see. The fact that you may not like it personally is irrelevant to the question of its effectiveness.

Regarding the writings of Paul about Lisp I was referring to that show evidence of the merits of Lisp, I’d check out:

“ANSI Common Lisp” and “On Lisp”

I believe the latter is out of print, but you can find online versions. I personally also like his Lisp related essays, but you may find them too fairy taleish :)

You can at least thank Paul for some blog traffic, eh ;)

I just read the hacknot link you provided. What a load of BS!

Are you interested in determining what tools would increase the productivity of a random population of individuals, or yourself? If you give credence to that article, then I can understand your views a little better.

“When a researcher allows their own biases to color their interpretation of experimental results.” Stephan, don’t let your personal bias color your interpretation - much better to let someone else run an objective experiment and tell you which tools are best for you ;)

Stephan, I think we’re probably both interested in increasing our effectiveness as programmers, and I agree that good programmers with inferior tools will probably outperform bad programmers with superior tools, but I think I feel the importance of programming language choice is more important than you do. I guess we can agree to disagree on that point.

BTW - when I said, “Stephan, don’t let your personal bias color your interpretation - much better to let someone else run an objective experiment and tell you which tools are best for you ;)”, I had a winking smiley to indicate sarcasm. My point was not that PG was objective, but that the article seemed to be saying, in effect, ignore your personal observations and run objective, scientific experiments, but what may work well for a random population of programmers may not be the best for you, or your team, or me in my opinion.

Also, I feel you changed the meaning of my statement quite a bit when you changed “random population of individuals” to “… individuals”, and then referred to your team members as the individuals. I’m not implying you should ignore the team, but that the personal observations/experiences of you and/or the team are particularly relevant - more so than an objective experiment with a “random population of individuals”.

In particular, I think the determination of the “best programming language” depends quite a bit on the capabilities of the programmers (and problems to be solved, etc.) i.e. the be best language for a large group of inexperienced programmers, is probably not the same as what would be best for a smaller team of very experienced programmers - that’s part of the difficulty with obtaining objective, relevant results from an experiment.

On the other hand, I’d like to keep an open mind, so if you are aware of objective experiments regarding programming language effectiveness, I’d be sincerely interested in hearing about them. I haven’t found many that I can put confidence in, but that’s not to say they don’t exist.

>> “I’ve seen good code in Basic, Ruby, Lisp, Machine Code, Java, C and a dozen other languages. And I’ve seen bad code in Basic, Ruby, Lisp, Machine Code, Java C and a dozen other languages. And I’ve seen good and bad developers writing code in Basic, Ruby, Lisp, Machine Code, Java, C and a dozen other languages.”

really? wow! you are so ….
I challenge you to show at least 1 example of good and bad code in each of ‘dozen’ languages.