2 ms·

The thing is, I've never found this to be a huge issues in lisps: partly because plenty of languages have libraries that are essentially the same sort of thing,

The thing is, I've never found this to be a huge issues in lisps: partly because plenty of languages have libraries that are essentially the same sort of thing, but less ergonomic: Spring/Hibernate in Java, Spark and the various FP stuff in Scala, Ruby on Rails, React. Any sufficiently complex library is essentially an embedded language that must be learned in addition to the base language: the cost of learning a language made out of macros isn't much different from learning a library with a large API surface area. In fact, since macros reduce the noise in the "language" a library implements, I've generally found that macro-based libraries are somewhat easier to learn than libraries in other languages.

fauigerzigerk 6y ago
Here's the dilemma as I see it: A carefully designed library that introduces a small set of coherent concepts can make good use of powerful syntactic abstractions and result in readable and succinct code. But application code that implements a large number of one-off requirements is far harder to read if you cannot rely on fixed semantics of basic syntactical elements. The usual response to that is to say that we shouldn't restrict the features available to good developers just because bad developers might abuse them. But this argument is flawed. If you read syntax that can be overloaded then you have to account for the possibility that it actually is. It's the possibility that creates the mental burden, not the fact. I think the solution is for languages to provide a basic set of syntactical elements that cannot be overloaded and are sufficient to write all code. Additionally, there should be optional syntactical elements that can be overloaded even to the point of creating DSLs. The important point is, there has to be a local cue that tells you whether or not you have to watch out for redefined semantics.

fauigerzigerk 6y ago

Here's the dilemma as I see it: A carefully designed library that introduces a small set of coherent concepts can make good use of powerful syntactic abstractions and result in readable and succinct code. But application code that implements a large number of one-off requirements is far harder to read if you cannot rely on fixed semantics of basic syntactical elements. The usual response to that is to say that we shouldn't restrict the features available to good developers just because bad developers might abuse them. But this argument is flawed. If you read syntax that can be overloaded then you have to account for the possibility that it actually is. It's the possibility that creates the mental burden, not the fact. I think the solution is for languages to provide a basic set of syntactical elements that cannot be overloaded and are sufficient to write all code. Additionally, there should be optional syntactical elements that can be overloaded even to the point of creating DSLs. The important point is, there has to be a local cue that tells you whether or not you have to watch out for redefined semantics.