3 ms·

Your criticism seems to apply to every DSL, which in my mind makes it too generic and therefore invalid. It also reminds me of the argument which was used to p

Your criticism seems to apply to every DSL, which in my mind makes it too generic and therefore invalid. It also reminds me of the argument which was used to push Java in the corporate world. "We need a language which protects us from the dumb programmers we hired to save money" Understanding someone elses code is always a challenge. Outlawing custom abstractions in favour of a few very shallow ones doesnt seem like a convincing thechnical argument.

snek_case 5y ago
> Your criticism seems to apply to every DSL, which in my mind makes it too generic and therefore invalid The problem is that LISP macros are extremely powerful. The DSLs you can design don't always neatly fit into a box and integrate seamlessly. They're leaky abstractions. You don't necessarily know what's a function or a macro. You don't necessarily know that a macro isn't doing lazy evaluation or redefining some operators you're familiar with. Programming languages aren't just about coding, they're also about having a shared language that other people can understand. If you introduce 500 new syntactic forms that you designed yourself into your code, and newcomers have to look them all up to really understand what's going on, that makes it much harder for new people to onboard. LISP loops minimalistic on the surface, but it's kind of a lie. In practice it's easy for it to become exactly the opposite of that.
- taeric 5y ago
  This is the popular narrative. But it is talked about more than it happens. In most lisps, few stray from the basic data structures, such that the data you can get is usable basically everywhere. Contrasted with many Java libraries, where coding a library locks you in to said library. Yes, a few have tried to keep interface compatibility with the core collections. I'd hope most do, nowadays. But that really just highlights that we are both talking of previous year's mistakes. My hypothesis is it comes from novice attitudes in building everything as a masterpiece. As the community matures, things tend to stabilize.
- mlang23 5y ago
  I believe a DSL-done-right doesnt care about the issues you mention. The important thing about DSLs is the DS, Domain-specific. The domain experts care about a nice language fitted for their specific domain. But they dont care about evaluation order, macros, lazyness, and whatnot. If the DSL fits the domain, these are non-issues.
jdmichal 5y ago
> Outlawing custom abstractions in favour of a few very shallow ones doesnt seem like a convincing thechnical argument. The entire point of the Lisp Curse is that this is a social issue! Not a technical one. And, furthermore, what is a technical issue in another language can be pushed into being a social issue in a Lisp. And social issues are a lot more difficult to solve. Compare this to something like Java + Spring Boot or Ruby on Rails or any other framework favoring configuration and convention over code. Where the explicit point is a social agreement on what a program looks like, which in turn allows everyone to hopefully focus on the actual business logic. (Also: Sibling commenter already addressed the differences in abstraction power better than I would have.)
- kazinator 5y ago
  "The Lisp Curse" article was written by a then neophyte web developer with no Lisp experience.
  - kazinator 5y ago
    He had a good idea there with the concept of a social problem in one culture being merely technical in another one which has the right technical wherewithal that is relevant to the problem. For instance, suppose that cheap and 100% effective sound-proofing were available and installed into every apartment by default (an example of (practically nonexistent) technology). Then unwanted noise from neighboring units wouldn't be a social problem.
d0mine 5y ago
Creating good languages is hard. Let's not encourage it e.g., It is good that Python enforces a few constraints on the syntax and many abstraction can be used as is between various unrelated projects.

snek_case 5y ago

> Your criticism seems to apply to every DSL, which in my mind makes it too generic and therefore invalid The problem is that LISP macros are extremely powerful. The DSLs you can design don't always neatly fit into a box and integrate seamlessly. They're leaky abstractions. You don't necessarily know what's a function or a macro. You don't necessarily know that a macro isn't doing lazy evaluation or redefining some operators you're familiar with. Programming languages aren't just about coding, they're also about having a shared language that other people can understand. If you introduce 500 new syntactic forms that you designed yourself into your code, and newcomers have to look them all up to really understand what's going on, that makes it much harder for new people to onboard. LISP loops minimalistic on the surface, but it's kind of a lie. In practice it's easy for it to become exactly the opposite of that.

taeric 5y ago
This is the popular narrative. But it is talked about more than it happens. In most lisps, few stray from the basic data structures, such that the data you can get is usable basically everywhere. Contrasted with many Java libraries, where coding a library locks you in to said library. Yes, a few have tried to keep interface compatibility with the core collections. I'd hope most do, nowadays. But that really just highlights that we are both talking of previous year's mistakes. My hypothesis is it comes from novice attitudes in building everything as a masterpiece. As the community matures, things tend to stabilize.
mlang23 5y ago
I believe a DSL-done-right doesnt care about the issues you mention. The important thing about DSLs is the DS, Domain-specific. The domain experts care about a nice language fitted for their specific domain. But they dont care about evaluation order, macros, lazyness, and whatnot. If the DSL fits the domain, these are non-issues.

jdmichal 5y ago

> Outlawing custom abstractions in favour of a few very shallow ones doesnt seem like a convincing thechnical argument. The entire point of the Lisp Curse is that this is a social issue! Not a technical one. And, furthermore, what is a technical issue in another language can be pushed into being a social issue in a Lisp. And social issues are a lot more difficult to solve. Compare this to something like Java + Spring Boot or Ruby on Rails or any other framework favoring configuration and convention over code. Where the explicit point is a social agreement on what a program looks like, which in turn allows everyone to hopefully focus on the actual business logic. (Also: Sibling commenter already addressed the differences in abstraction power better than I would have.)

kazinator 5y ago
"The Lisp Curse" article was written by a then neophyte web developer with no Lisp experience.
- kazinator 5y ago
  He had a good idea there with the concept of a social problem in one culture being merely technical in another one which has the right technical wherewithal that is relevant to the problem. For instance, suppose that cheap and 100% effective sound-proofing were available and installed into every apartment by default (an example of (practically nonexistent) technology). Then unwanted noise from neighboring units wouldn't be a social problem.

d0mine 5y ago

Creating good languages is hard. Let's not encourage it e.g., It is good that Python enforces a few constraints on the syntax and many abstraction can be used as is between various unrelated projects.