Religion is basically an argument over who has the best imaginary friend. Languages though are just tools, and luckily there will always be people who break the limits, lest we end up in Dark Ages.

E.g. Scheme, a dialect of Lisp, can be compiled to straight C with the Chicken interpreter; ejabberd is written in Erlang and outplayed jabberd, which is written in C, in terms of reliability.

Assembly? No, not very easy to use…
Lisp? A bit too abstract…
Ruby? That’s the slow one, right?

What’s just a tiny bit more usable than the assembly language, but with enough abstraction and still with a lot of power?

Oh, wait.

Because there aren’t that many smart programmers, probably, in relation to the rest. An island in the Carribean might be the best place in the world to live - just because it isn’t highly populated or doesn’t export much compared to bigger countries doesn’t disprove that.

Ok, eat your own dog food and have a look at http://shootout.alioth.debian.org/debian/benchmark.php?test=sumcol&lang=all

Surprised, aren’t you? Haskell uses some very clever optimizations there. Sure, the same thing could be achieved in C, but you are left on your own and have to implement it by yourself. You can write some kind of library, incorporating clever ideas and optimizations, but that’s about all you can do in C. What you can’t (easily) do is to pass information how to generate these optimizations automatically for user supplied code in the library.

I’m not trying to imply that these microbenchmarks are of any real value, though.

For the Lisp part, I’ll give you an example of my personal macro usage:

I encounter lots of html parsing in my work. At the beginning, I didn’t have much experience of how to do it properly (heck, I didn’t even know regular expressions :)). Somehow I felt, that regexps might be helpful here. So I downloaded a library for lisp and gave it a try. Well, it worked. But I wasn’t very happy with it, because through extensive regexp usage my otherwise nicely structured programs started to look like a line noise. And I hate that, because readability and maintainability stand very high in my code production. I changed my view of the problem, because approaching it with regexps was unnecessarily low-level. To say it simply, I was ignoring one major feature of html code - its structure - and reimplementing ad hoc hacks for it time and time again, scattered all over my sources. That’s not nice, as I also love a tight locality of code. Nobody loves repair-here-break-in-another-file kind of problems, it just takes too much time and effort to track all these dependencies. It also frightens you to experiment with your code, which is being in bad health and fragile. But how am I supposed to program (= continual code evolution), when it is plagued like this? That’s what I thought, being tired of endless structure handling hacks. I made an obvious step and downloaded a library, which parses html from strings into a tree representation, to be able to do matching on that. What a relief! No more bothering with nasty regexp. Still, I had to reinvent a wheel once again. I had to roll my own tree matching routines. It was fun, but I got tired of it soon. My code started to look cloberred once again, as I was adding more and more specific routines. And none of them were easily reusable. Geez, having to think about such a straightforward thing as structural pattern matching? Maybe a few times OK, but hundreds of times? Hell, I have better things to do with my time. What kind of tool is good at this task? Prolog! Oh, yes, but how can it help you, when you have chosen to suffer in Lisp, you might ask. Actually, believe it or not, there are quite a few prologs out there, implemented as a bunch of lisp macros. I used one with a lispy syntax, so I wouldn’t be left out in the cold, should the need of macros producing prolog code arise. And it sure did arise soon! While being very nice and almost ideal for my usage pattern, there still was some boilerplate code present. Mainly some initialization and directing the style of matching (all vs. first match only, etc.). After writing it time and time again I gained an intimate knowledge of these inner workings, deep enough to write a program, that generates them for me according to a given matching pattern and a few switches. This kind of program is called a lisp macro. What it does is to take a lisp code as input and compute a transformed code as output (and beware, all of this is done on abstract syntactic tree representation of source, not strings). I won’t go in further details about it, just say, that I am *very* happy to have a handy macro like this around. I admit it does not solve every one of problems, but corner cases can usually be solved with nested matching and a little bit of lisp programming (as I have a great control over the matching while it is running). I have even incorporated regexp matching, but this time only where it is needed - matching of useful string data, not html tags. Now I can really concentrate on what’s really relevant for me to program and let the machine do the tedious work (a few simple lines of input are expanded into not so few lines of prolog, that are later transformed into impenetrable lisp code implementing all those prolog backtracking and unification stuff).

I could continue more and more, but I hope, you have an idea now. Ultimate power of Lisp for me lies in the ability to create whatever domain specific language would-be-nice-to-have *now*, I don’t have to wait for a compiler creator to incorporate some nifty feature (and I have no illusions they would implement my personal wishes).

I tried to be as personal as possible, because I make no assumptions of what is good for you. I don’t know. But what I know for sure is, that Lisp was (and still is) a great mind bending trip for me. Just my $0.02

(incf lisp-preaching-counter)

OpenOffice in Ruby certainly would not be too fast ;)

DHH is talking about writing web applications, which are an exception from what I’ve written about ie. nobody uses C to write them and you can use any language you want - if it looks good in the browser, no one will care about the internals.

To clarify - it’s not that I like C very much or consider it “a better language” (whatever it means) than XYZ, I’ve just made a simple observation that almost all useful stuff is still written in the same good old thing, not in any of the new hot languages.

C and C++ aren’t languages in which you can easily “build and deploy” applications. Compared to Python/Ruby/Perl number of hacks programmers have to do in order to make an application portable is really astonishing. System libraries differ and C programmers have to reinvent the wheel every time to do simple things like sockets or graphics. They end up with another layer of complexity, which have a high probability of having bugs and being actually slower than cleaner and portable solutions in more powerful languages.

I’m using Firefox, OpenOffice, Gimp, Inkscape and others as you do and I must admit they eat quite a bit of my system memory. They’re also not particularly fast. In fact I think they will benefit by being rewritten in language like Python or Ruby. Codebase will be smaller, bug will be easier to find, and benchmarks could be done more effectively, thus producing faster systems. The biggest problem in optimization is not how to optimize it, but when and what. Writing programs “for speed” in C is just stupid, bottlenecks are often not even in your application, but in a database or network connection. You’re seeing the problem but fail to understand the cause. I know you use Rails extensively, so listen to what David says about optimization: http://www.loudthinking.com/arc/000596.html . Watch Dave Thomas talking about it as well: http://video.google.com/videoplay?docid=-7327520943909344563 .

EOT from my side, don’t have much time for Language Wars nowadays. ;-)

Riiight. Do you understand just how much of emacs is implemented in elisp? That’s like not counting the C parts of linux because it’s “really” implemented in assembly (asm shim needed to boot kernel, C shim needed to boot the Emacs elisp VM).