Hacker News Reader

Comment by bambax | Hacker News Reader

> If one person does a job in half the time of another, maybe it can be attributed to their choice of programming languages. If one does it in 1% of the time of another, it’s probably a matter of talent.

This has been discussed many times (recently, somebody attributed a significant difference in productivity among programmers to... the ability to touch type).

Anyway, why different tools could in principle not be able to generate wildly different productivity outcomes?

"If you only have a hammer" can be reversed: if you don't have a hammer, then planting nails becomes incredibly difficult and takes a great amount of time (and ingenuity). A (not too practical-oriented) friend of mine once called me because he had spent an hour and a half trying to screw together a simple Ikea bookshelf (where the documentation said it could be done in less than 10 minutes). Turned out he was trying to screw the big bolts with pliers, and that's really hard.

View on HN

This kind of argument irks me slightly. I think it's partly the "Lisp is awesome, only a genius can really understand. btw, did you know I use lisp?" attitude, and partly because, well, for all you geniuses who are so awesome and productive, there's not a hell of a lot to show for it.

You've had fifty years, ffs, and what have you got to show for it. Some furry guy who wrote emacs 40 years ago? Why is it that the web was built with php and perl? Why my desktop apps are still mostly written in C? You've had you're arse handed to you on a platter by every language (just about) since fortran. Stop waxing lyrical about how great lisp it, and get out there and prove it, dammit.

Lisp may be a great language, but it's proponents don't seem all that great at getting stuff done

Do not undermine network effects. C/C++ have had unbeatable network effects going on for them for a very long time now. Most systems are shipped with C based drivers and apis (Opengl, posix etc). Writing code in Lisp (Or any other HLL) means that you have to first write a binding for said library which is lispy, then build a system on top of that. Also then data has to be marshalled / unmarshalled from the C data structures into your language specific data constructs - this has a penalty in terms of speed. And finally you have to wrap the unmanaged c/c++ code so that it has an idiomatic (in lisp) garbage collection and exception handling story. In short - to write systems level lisp code requires you to be a jedi in C, api design, lisp and sheer code writing (because you have to essentially recreate the convenient wrappers that intel/ nvidia etc write in C).

Put another way - in 10 years if HTTP/Javascript continue on the same path people could arguably say the same thing - "some furry guy wrote Linux in C, but what has C done for the world recently? All the cool apps being built recently are in Javascript/HTML on the frontend and Python/Ruby on the backend"

But Lisp is older than C by 15 years and still lost out?

It did not really compete that much. The target audiences and target domains are really different.

C was invented as a replacement for assembler to portably write operating systems and applications in a slightly higher-level notation.

Lisp was invented as a tool for computing with symbols (computer algebra, theorem prover, game playing, natural language processing, expert systems, knowledge representation, ...).

Then what about the Symbolics and Lisp Machine guys?

when the Lisp Machines were invented in the mid 70s (as personal workstations for research programmers mainly in AI) and commercialized in the early 80s there was nothing to compete with. When alternatives were available, there was no longer the need to have those (and they were not competitive), so they died away.

I do not want to rehash all the points covered under "Worse is better" - [A] largely because I dont think I could ever write as eloquently as Richard Gabriel. You are right C has "won" for some value of won - in the sense that most large systems currently in existence have C at their core. From another point of view lisp has "won" because at least in the circles I roll the languages used today are closer to lisp (dynamic languages with garbage collection) than they are to C. In any case neither you or me could take any credit for what our language ancestors (Kernighan, Ritchie, Steele, Pitman etc) accomplished in their day.

[A] - http://www.dreamsongs.com/WorseIsBetter.html

Lisp is not concerned by implementation details. C is somewhat concerned with implementation details.

Implementation details largely determine how fast a given program will run.

C makes it rather easy to predict how fast a piece of code will run, and what its bottlenecks will be. Lisp makes that rather hard.

Given that there are always programs that need to be as fast as possible even with hand-optimized algorithms running on top-of-the-line hardware, C will win for many applications that have even moderate performance requirements.

Also, current mainstream operating-systems favor C and C++, if only implicitly.

I don't buy the "Lisp is not concerned by implementation details" because all I see in Lisp are implementation details, namely everything is a singular linked list and you have to go somewhat out of your way to use anything else (switch from lists to actual arrays, and you have to modify your code from using CAR to AREF, for example). Don't forget the numerous equality operators either (EQ, EQL, EQUAL, etc) whose results are most definitely dependent upon the underlying implementation detail (EQ compares pointers, EQUAL compares visual representations).

For speed, I use profilers, because I'm still surprised at where the code is spending its time, even after 20 years of programming in C.

I'm beginning to think that Lisp appeals to programmers that like programing in raw Abstract Syntax Trees which is a small subset of all programmers.

Your point over everything being a singular linked list is a very good one. Even as a lisp user I wish that things were specified in terms of a sequence protocol rather than a list data structure. I believe Clojure rectifies this historical anomaly. In their defense the people creating Lisp didnt have any prior art and were making rules as they went along.

Yeah, but not to fix it for 53 years?

Mistakes in non trivial languages are not fixed, they are worked around. (cl-containers does offer a clos based sequence protocol)

"Some furry guy who wrote emacs 40 years ago? Why is it that the web was built with php and perl?"

Try using Google? CL-HTTP has been around since 1994, Symbolics came out with the second ever commercial 3d animation package a few months after Wavefront in 1983 or 1984, first HDTV-capable digital editing systems in 1989 for Japan, etc. Most of the "hot" parallel processing stuff of today (Map/Reduce, futures, actors) was done in Lisp at MIT in the early 80s.

Just because you're too lazy to find out whether something exists doesn't mean it's not there.

If you continue with this line of reasoning you'll come off sounding an awful lot like Monty Python's "What have the Romans done for us?" Skit.

>> If one does it in 1% of the time of another, it’s probably a matter of talent.

The original article seems to base this on the flawed assumption talent and choice of tools are not related.

edit: should have phrased the above as "this statement seems based". It's not the entire article.

>> The original article seems to base this on the flawed assumption talent and choice of tools are not related.

The article does say they could be related:

"Another possibility is that super-programmers are attracted to Lisp."

That would be a strong correlation. However, the article is about causality, though. If the truth is that

Programming talent -> Choose Lisp

Then it is not necessarily the case that

Choose Lisp -> Programming talent

Sorry for the poorly thought out post.

Anyway, as was pointed out elsewhere, someone can write a web CRUD in Rails in 1% of the time it would take to write it in C with Apache modules (or ISAPI DLLs). Choosing the wrong tool can have disproportionate effects.

Having a large tool set is one of the hallmarks of the great programmer.

One example off the top of my head: a friend of mine was struggling for a week to deliver a simple J2ME (it was 2002 or 2003) app using Eclipse. I directed him towards NetBeans. The product was ready that same afternoon. The IDE support in NetBeans was so complete his job was more a fill-in-the-blanks than anything else.

Oh, I see what you mean. I agree completely.

Reply on news.ycombinator.com