4 ms·

Thanks for the link (it's one of PG's I hadn't read yet.) That being said, I really didn't like the part where he implied that if 1 line of Lisp can replace 20

by smeyer 12y ago

Thanks for the link (it's one of PG's I hadn't read yet.) That being said, I really didn't like the part where he implied that if 1 line of Lisp can replace 20 lines of C that it also means that a feature can be developed 20 times faster in Lisp than C. Are you a Lisp programmer? I've only used it a bit, but I didn't get the impression things would scale that way for feature development.

BugBrother 12y ago
If you check the research on the subject of development speed, it suggests a given programmer generates around a certain number of pages of code in any language he/she is proficient in. And if the programmer learns another language, they will write about the same number of pages when they get proficient. (Apply NaCl. I assume the real statement is that a given programmer generates a given amount of complexity in a work day.) [This paragraph of background was not needed, you seem aware of this point.] You can, simplified, see Lisp as the grandfathers of the scripting languages. (But with parse trees as syntax, efficient compiler decades ago and so on.) The point with the scripting languages is that development speed is so much quicker than e.g. C, for many cases. Lots of less code is needed. Personally, I went to scripting languages from C originally because of that the sheer productivity is so fun. I would have gone Lisp if there were jobs.
ColinDabritz 12y ago
Interesting point. Particularly I believe that the 'coding' part isn't the real job, I'm not just an overpaid typist. So why is concise expression good? For the record, I am NOT a day-to-day Lisp programmer, but I've played with it a little and read about it some. I think it's because its about expressing your problem clearly. It's not "20 times less lines" so much as it is "20 times clearer expression". Not that it's exactly 20x, but it seems better. When you express things more clearly, and structure your code more like your problem, and less like your programming language, you shed a lot of accidental complexity ( See Out of the Tarpit - http://shaffner.us/cs/papers/tarpit.pdf http://shaffner.us/cs/papers/tarpit.pdf ), so managing the complexity of your project is easier, which means fixing bugs and adding new features is also easier. I think this is the route being implied when they say you can develop features faster. I'm not so certain you'd see the benefit in a particular feature, but over time. Note that a lot of the modern languages are picking up many of these expressive features, closing the gap there as well, which is wonderful.

by smeyer 12y ago

BugBrother 12y ago

If you check the research on the subject of development speed, it suggests a given programmer generates around a certain number of pages of code in any language he/she is proficient in. And if the programmer learns another language, they will write about the same number of pages when they get proficient. (Apply NaCl. I assume the real statement is that a given programmer generates a given amount of complexity in a work day.) [This paragraph of background was not needed, you seem aware of this point.] You can, simplified, see Lisp as the grandfathers of the scripting languages. (But with parse trees as syntax, efficient compiler decades ago and so on.) The point with the scripting languages is that development speed is so much quicker than e.g. C, for many cases. Lots of less code is needed. Personally, I went to scripting languages from C originally because of that the sheer productivity is so fun. I would have gone Lisp if there were jobs.

ColinDabritz 12y ago

Interesting point. Particularly I believe that the 'coding' part isn't the real job, I'm not just an overpaid typist. So why is concise expression good? For the record, I am NOT a day-to-day Lisp programmer, but I've played with it a little and read about it some. I think it's because its about expressing your problem clearly. It's not "20 times less lines" so much as it is "20 times clearer expression". Not that it's exactly 20x, but it seems better. When you express things more clearly, and structure your code more like your problem, and less like your programming language, you shed a lot of accidental complexity ( See Out of the Tarpit - http://shaffner.us/cs/papers/tarpit.pdf http://shaffner.us/cs/papers/tarpit.pdf ), so managing the complexity of your project is easier, which means fixing bugs and adding new features is also easier. I think this is the route being implied when they say you can develop features faster. I'm not so certain you'd see the benefit in a particular feature, but over time. Note that a lot of the modern languages are picking up many of these expressive features, closing the gap there as well, which is wonderful.