4 ms·

That seems like a huge disadvantage to me. The bottle neck in any software project (> 1 person) is usually the time it takes to read and understand source code.

by Permit 12y ago

That seems like a huge disadvantage to me. The bottle neck in any software project (> 1 person) is usually the time it takes to read and understand source code. Some estimates[1] claim that up to 78% of development time is spent just reading code. With that in mind, I would not want to learn a new language for every project I was a part of. I'd even go so far as to say: The majority of programmers cannot design a good language, and if Lisp gives them the opportunity to try then that's a BadThing™. [1]http://blogs.msdn.com/b/peterhal/archive/2006/01/04/509302.aspx http://blogs.msdn.com/b/peterhal/archive/2006/01/04/509302.a...

Flow 12y ago
A big problem is people being too smart for their own good. But that happens in all languages.
tunesmith 12y ago
It depends on the complexity of the new language, doesn't it? If these new languages are highly domain-specific DSL's for complex domains, then the entire software package might be more understandable overall.
julienchastang 12y ago
The thing is when you know lisp (or scheme) you understand programming languages much more fundamentally than you would otherwise and so jumping from one programming language to another becomes much easier. (BTW, I hated Scheme in school, but I have since seen the light thanks to SICP.) Overall, I agree with the theme of this sub-thread that non-idiomatic code in any language is a real pain in the ass. I see this everyday when I look at code written by scientists who are smart, driven, motivated people and therein lies the problem.
sedachv 12y ago
What's wrong with DSLs? They make it easier to read and understand code.
wwweston 12y ago
> That seems like a huge disadvantage to me. The bottle neck in any software project (> 1 person) Even single-author projects have the person who wrote the code months ago and the person reading it today. :) > is usually the time it takes to read and understand source code. Some estimates[1] claim that up to 78% of development time is spent just reading code. Sure. This is a big deal. I'm not sure the software-conservative approach of locking down the syntax and flexibility of expression is deeply helpful, though. My experience is that comprehending syntax (while it can be a barrier) isn't the biggest portion of that 78% you're talking about -- maybe 15%. Wrapping your head around the semantics of what a piece of code does is a much bigger portion. The semantics of what the software does are the true language of the program you're writing, so in a sense the choice isn't whether or not you're going to have a DSL or not, it's just how concisely the syntax of the language will support the expression of it. And I've found that the less flexibility you have in syntax, the more likely it is over time that you'll have to type/read over larger amounts of code in order to capture the expression of a given semantic goal.
sjolsen 12y ago
>With that in mind, I would not want to learn a new language for every project I was a part of Well, you have to. Every new project comes with its own vocabulary and semantics. You have to learn those whether they're expressed in terms of data/function abstractions or syntactic abstractions. Sometimes—perhaps less often than many Lisp programmers appreciate, but sometimes nonetheless—those new concepts are simply easier to understand when expressed syntactically. >The majority of programmers cannot design a good language, and if Lisp gives them the opportunity to try then that's a BadThing™ There are many programmers (I say "many" because I haven't actually met most programmers, but "most" might be true, too) who cannot design good data abstractions. Would you consider that [your favorite "OO" language here] allows one to form data abstractions to be a "bad thing?"
brudgers 12y ago
It's not so much a huge disadvantage as a huge trade-off. The risk is that Lisp is used to create a lousy language ill-suited for the task at hand. The benefits come when it is used to capture the ubiquitous language of a domain and used at the appropriate level of abstraction. If it makes the code harder to reason about, then it's not the right level of abstraction. But poor code can be written in any language.

by Permit 12y ago

Flow 12y ago

A big problem is people being too smart for their own good. But that happens in all languages.

tunesmith 12y ago

It depends on the complexity of the new language, doesn't it? If these new languages are highly domain-specific DSL's for complex domains, then the entire software package might be more understandable overall.

julienchastang 12y ago

The thing is when you know lisp (or scheme) you understand programming languages much more fundamentally than you would otherwise and so jumping from one programming language to another becomes much easier. (BTW, I hated Scheme in school, but I have since seen the light thanks to SICP.) Overall, I agree with the theme of this sub-thread that non-idiomatic code in any language is a real pain in the ass. I see this everyday when I look at code written by scientists who are smart, driven, motivated people and therein lies the problem.

sedachv 12y ago

What's wrong with DSLs? They make it easier to read and understand code.

wwweston 12y ago

> That seems like a huge disadvantage to me. The bottle neck in any software project (> 1 person) Even single-author projects have the person who wrote the code months ago and the person reading it today. :) > is usually the time it takes to read and understand source code. Some estimates[1] claim that up to 78% of development time is spent just reading code. Sure. This is a big deal. I'm not sure the software-conservative approach of locking down the syntax and flexibility of expression is deeply helpful, though. My experience is that comprehending syntax (while it can be a barrier) isn't the biggest portion of that 78% you're talking about -- maybe 15%. Wrapping your head around the semantics of what a piece of code does is a much bigger portion. The semantics of what the software does are the true language of the program you're writing, so in a sense the choice isn't whether or not you're going to have a DSL or not, it's just how concisely the syntax of the language will support the expression of it. And I've found that the less flexibility you have in syntax, the more likely it is over time that you'll have to type/read over larger amounts of code in order to capture the expression of a given semantic goal.

sjolsen 12y ago

>With that in mind, I would not want to learn a new language for every project I was a part of Well, you have to. Every new project comes with its own vocabulary and semantics. You have to learn those whether they're expressed in terms of data/function abstractions or syntactic abstractions. Sometimes—perhaps less often than many Lisp programmers appreciate, but sometimes nonetheless—those new concepts are simply easier to understand when expressed syntactically. >The majority of programmers cannot design a good language, and if Lisp gives them the opportunity to try then that's a BadThing™ There are many programmers (I say "many" because I haven't actually met most programmers, but "most" might be true, too) who cannot design good data abstractions. Would you consider that [your favorite "OO" language here] allows one to form data abstractions to be a "bad thing?"

brudgers 12y ago

It's not so much a huge disadvantage as a huge trade-off. The risk is that Lisp is used to create a lousy language ill-suited for the task at hand. The benefits come when it is used to capture the ubiquitous language of a domain and used at the appropriate level of abstraction. If it makes the code harder to reason about, then it's not the right level of abstraction. But poor code can be written in any language.