6 ms·

The point here is not that metaprogramming is universally bad, it's that it should be used as a last resort ... and you should feel bad you could just refactor

The point here is not that metaprogramming is universally bad, it's that it should be used as a last resort ... and you should feel bad you could just refactor your code using static idioms you or someone else will kill some runtime optimizations of the JIT. syntax matters way less than people tend to think ... astonishment [sic] cute syntax Many intelligent, design-savvy people would strongly disagree with you. Besides the obvious gains in the ability to create DSLs, there is a power and fluidity in metaprogramming that is not possible any other way. Speed (as, say, provided by runtime optimizations from a JIT compiler) is not always critical. If it was, one probably should be using a language other than Ruby or Javascript; they're meant to be flexible, powerful languages, and their emphasis is not on pure speed. Syntax is not "cute." Humans are going to read and use this code, and the more it reads like English, the more likely it is to be understood.

adamnemecek 13y ago
You seem to be suggesting that DSLs are universally accepted as a pinnacle of good design.
- mindcrime 13y ago
  Indeed. I, for one, think that over-proliferation of DSL's can be a Bad Thing. To use one example from my own experience: I spend a lot of time coding in a Groovy / Grails environment. Now, I like Grails and Groovy, but Grails introduces it's own weird DSLs for things like: configuring Spring Beans configuring Log4J defining URL mappings configuring Hibernate mappings & queries etc. Now some of those are cool, but at least some of them replace other techniques that I already know, and find much more readable and understandable. Configuring Log4J, for example. I'd much rather simply jam a log4j.xml in there and forget about the Grails DSL. The thing is, none of these DSL's is, in and of itself, necessarily bad in any way... but there's a bit of "cognitive overload" in having to deal with 3 or 4 or 5 new DSLs, on top of the base Groovy stuff. The flip side is, these DSLs mean that your configuration is done mostly in .groovy files and you can use normal groovy syntax for looping and accessing variables, etc. So it's easier to code up more dynamic configurations than if you were using XML files or .ini files. Anyway, the point of this rant is not to say "DSLs are bad" but just to lend weight to the suggestion that they aren't universally Good either.
  - andrewflnr 13y ago
    Not knowing anything about Grails, does the Log4j DSL not do the equivalent of generating the XML config, and if not, would you have preferred a system where you could choose to write your own config or let the DSL do it for you?
peterhunt 13y ago
Unsure why you [sic]'d astonishment; I was referring to https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen..., a well-accepted principle of UX which certainly applies to the UX of languages and APIs. I am unsure what you mean by the "obvious gains" you get from DSLs. I see many DSLs as a code smell -- that the runtime environment is almost expressive enough to express the syntax construct the DSL creator wants, but not quite. The implementation of DSLs tends to judiciously use closures, operator overloading, dynamic getters and proxies such that it's non-obvious what's going on under the hood. Sometimes that trade-off is worth it. Usually it isn't, in my experience. I believe (I could be wrong) that DSLs were coined around 2004. I don't think that is a long enough history for us to even think about simply accepting that they are a good idea in and of themselves -- garbage collection was invented in 1959 and is still being debated! I see the speed argument all over the internet being presented as a binary argument: either you care about speed or you don't. That's simply false -- I care about order of magnitudes for speed. I personally don't care if I can encode h264 faster in JS than I can another way, but I do care that my event handlers execute within 16ms so I don't drop frames in the browser. Some syntax is certainly cute. Additionally, making syntax readable like English should be a non-goal IMO; for many people, Lisp is far more readable than SQL, which is much closer to English.
- sharkbrainguy 13y ago
  2004 seems really late for the inception (or possibly formalisation) of Domain Specific Language, I assume that you're talking specifically about embedded (also called internal) DSLs, otherwise SQL at least is from 1986. As an earlier example of an Embedded DSL, the book PAIP[1] included prolog embedded in common lisp in 1992. It could be argued that the loop macro in Common Lisp is a DSL for describing iteration. If not loop, then certainly regular expressions are a common EDSL for describing a regular language, and performing operations with those languages against strings? I found this snippet from Computers in Crisis [2] which seems to describe domain-specific languages in familiar terms from 1975 Most domain-specific programming languages can be categorized in one of two ways; either as a "sugared" general ... of programming, in fact the style of problem solving, embedded in and supported by that language remains unchanged. [1] http://www.norvig.com/paip/README.html http://www.norvig.com/paip/README.html [2] http://books.google.co.nz/books?id=QndQAAAAMAAJ&q=%22Embedded+Domain+Specific+Language%22&dq=%22Embedded+Domain+Specific+Language%22&hl=en&sa=X&ei=fq3gUfOmG8e_kQX59YG4AQ&ved=0CDkQ6AEwAg http://books.google.co.nz/books?id=QndQAAAAMAAJ&q=%22Embedde...

adamnemecek 13y ago

You seem to be suggesting that DSLs are universally accepted as a pinnacle of good design.

mindcrime 13y ago
Indeed. I, for one, think that over-proliferation of DSL's can be a Bad Thing. To use one example from my own experience: I spend a lot of time coding in a Groovy / Grails environment. Now, I like Grails and Groovy, but Grails introduces it's own weird DSLs for things like: configuring Spring Beans configuring Log4J defining URL mappings configuring Hibernate mappings & queries etc. Now some of those are cool, but at least some of them replace other techniques that I already know, and find much more readable and understandable. Configuring Log4J, for example. I'd much rather simply jam a log4j.xml in there and forget about the Grails DSL. The thing is, none of these DSL's is, in and of itself, necessarily bad in any way... but there's a bit of "cognitive overload" in having to deal with 3 or 4 or 5 new DSLs, on top of the base Groovy stuff. The flip side is, these DSLs mean that your configuration is done mostly in .groovy files and you can use normal groovy syntax for looping and accessing variables, etc. So it's easier to code up more dynamic configurations than if you were using XML files or .ini files. Anyway, the point of this rant is not to say "DSLs are bad" but just to lend weight to the suggestion that they aren't universally Good either.
- andrewflnr 13y ago
  Not knowing anything about Grails, does the Log4j DSL not do the equivalent of generating the XML config, and if not, would you have preferred a system where you could choose to write your own config or let the DSL do it for you?

peterhunt 13y ago

Unsure why you [sic]'d astonishment; I was referring to https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen..., a well-accepted principle of UX which certainly applies to the UX of languages and APIs. I am unsure what you mean by the "obvious gains" you get from DSLs. I see many DSLs as a code smell -- that the runtime environment is almost expressive enough to express the syntax construct the DSL creator wants, but not quite. The implementation of DSLs tends to judiciously use closures, operator overloading, dynamic getters and proxies such that it's non-obvious what's going on under the hood. Sometimes that trade-off is worth it. Usually it isn't, in my experience. I believe (I could be wrong) that DSLs were coined around 2004. I don't think that is a long enough history for us to even think about simply accepting that they are a good idea in and of themselves -- garbage collection was invented in 1959 and is still being debated! I see the speed argument all over the internet being presented as a binary argument: either you care about speed or you don't. That's simply false -- I care about order of magnitudes for speed. I personally don't care if I can encode h264 faster in JS than I can another way, but I do care that my event handlers execute within 16ms so I don't drop frames in the browser. Some syntax is certainly cute. Additionally, making syntax readable like English should be a non-goal IMO; for many people, Lisp is far more readable than SQL, which is much closer to English.

sharkbrainguy 13y ago
2004 seems really late for the inception (or possibly formalisation) of Domain Specific Language, I assume that you're talking specifically about embedded (also called internal) DSLs, otherwise SQL at least is from 1986. As an earlier example of an Embedded DSL, the book PAIP[1] included prolog embedded in common lisp in 1992. It could be argued that the loop macro in Common Lisp is a DSL for describing iteration. If not loop, then certainly regular expressions are a common EDSL for describing a regular language, and performing operations with those languages against strings? I found this snippet from Computers in Crisis [2] which seems to describe domain-specific languages in familiar terms from 1975 Most domain-specific programming languages can be categorized in one of two ways; either as a "sugared" general ... of programming, in fact the style of problem solving, embedded in and supported by that language remains unchanged. [1] http://www.norvig.com/paip/README.html http://www.norvig.com/paip/README.html [2] http://books.google.co.nz/books?id=QndQAAAAMAAJ&q=%22Embedded+Domain+Specific+Language%22&dq=%22Embedded+Domain+Specific+Language%22&hl=en&sa=X&ei=fq3gUfOmG8e_kQX59YG4AQ&ved=0CDkQ6AEwAg http://books.google.co.nz/books?id=QndQAAAAMAAJ&q=%22Embedde...