4 ms·

And what is wrong, exactly, with changing the language syntax? DSLs become more readable and closer to the way the problem domain experts think if they are usi

• arethuza 11y ago
  Because if there is no explanation of what the new syntax is and it's one developers take on making Lisp look a bit more pascally (which this was - it wasn't a DSL) I don't really see what it achieves other than confusion.
• TeMPOraL 11y ago
  Personally I think it's totally cool as long as you stay consistent and your language makes sense. It is written in SICP that programming is in fact building layers of abstraction, the lower one serving as a programming language for the higher one. Macros or not, everyone designs new 'programming languages', though today's term of art is "API".
• jlg23 11y ago
  There is nothing wrong if you can justify it to the next programmer who has to deal with your code. If your gain is only marginal but I have to read and understand 200 lines of code to understand your DSL, I might be mildly annoyed....
  • armitron 11y ago
    You know there is such a thing as documentation right? If you have to read and understand 200 lines of code with no documentation, take it up with the incompetent developer. This argument holds no water whatsoever. Bad programmers can cause all sorts of damage, why should everything be dialed down to their level? Clojure forces you to deal with concurrency issues in a way that might be premature optimization at best, tremendous waste of time at worst. As opposed to DSLs in CL with reader macros, I have no choice in the matter, it's all or nothing. Yet I don't see you complaining. Good DSLs (meaning they map very well to the problem domain ) are irreplaceable. They can make a problem completely disappear.
  • sklogic 11y ago
    A well-designed DSL should be self-documenting and obvious. And the right tools (like a proper IDE integration, with syntax highlighting and autocompletion) would make such a DSL much more obvious than a library of functions (which still must be thoroughly documented to be usable).
    • zzalpha 11y ago
      A well-designed DSL should be self-documenting and obvious. ROFL. You're adorable. :) You're also conveniently ignoring the maintenance required on the DSL itself. DSLs are, themselves, code, and code must be tested, updated, will likely experience regressions, etc.
      • sklogic 11y ago
        I've been building properly designed, syntactically rich DSLs for over a decade. It is much, much easier than building usable APIs. DSL compilers are the simplest and cleanest code possible. They're nothing but a chain of very trivial tree rewrites, and with a help of a proper DSL you can write and maintain them easily.
• lubonay 11y ago
  Programming languages carry with them certain conventions. Straying too much from the established code style will make your code a pain to work with. It's pretty hard to hit the right balance between adhering to the original language and matching your DSL to the problem domain. If you build a DSL that requires a day of studying code and documentation in order to make a minor change, you might be better off without it.
  • sklogic 11y ago
    > Straying too much from the established code style will make your code a pain to work with. This is a theory. Reality is a bit different. There is nothing in common between, say, JavaScript and the regular expressions DSL embedded into it, but yet they come ok together. Code style is overrated.
    • zzalpha 11y ago
      The difference is that's a standard embedded DSL (another excellent example is C#'s LINQ). Inventing your own alien syntax is a recipe for long-term code maintenance disaster. Anyone who's worked on a codebase that's lived longer than a decade has likely experienced this pain firsthand.
      • sklogic 11y ago
        Most of the code I worked with was 30-40 years old. Often full of ad hoc DSLs. Refreshing this kind of code was easier than any other kinds - rewriting the DSL itself with the modern technologies was sufficient, 90% of the remaining code base did not need much maintenance then.
• chaitanya 11y ago
  While I don't think readability is a problem if you are judicious with your use of reader macros, the real problem is that they don't play well with editing tools e.g. all those nice Emacs shortcuts like forward-sexp, backward-sexp, etc. won't work correctly with any JSON that you write in your Lisp files. Forget JSON, the problems are evident even when using something like CL-INTERPOL, which makes minimal changes to the read-table.
  • sklogic 11y ago
    Yes, of course you need your IDE to play well with the reader macros. That's why I use PEGs to construct such macros and to provide a feedback for the IDE while parsing (e.g., token locations, definitions, etc.).