4 ms·

> ... but for typed languages I think it becomes far more difficult both to implement and understand. I don't think that types are the issue but rather that su

> ... but for typed languages I think it becomes far more difficult both to implement and understand. I don't think that types are the issue but rather that such languages were not designed with macro systems in mind from the very beginning. Some added complexity is unavoidable, of course. > A lot of people don't realize that Java offers a macro/preprocess like system (APT) and it is even sort of hygienic (an example project is Google's Auto [1]). I didn't. Will look it up. > 2001 called and wants it example back I had to use that abomination as far as 2005. I understand that's a dated example, but it is the best example of that slippery slope taken to its extremes that I could think of. It is also a good example in the sense that it used XML instead of expressing itself in the original language. As such, it is also a nice illustration of Greenspun's Tenth Rule.

ruste 10y ago
I was also completely unaware that Java had a macro system. I'll have to check that out.
- agentgt 10y ago
  Calling it a macro system is probably a stretch of the word :) but if you check out APT you should also check out the far sexier Java Agents [1] which is code that changes other code during runtime (ie alters structure and provides meta programming). [1]: https://docs.oracle.com/javase/7/docs/api/java/lang/instrument/package-summary.html https://docs.oracle.com/javase/7/docs/api/java/lang/instrume...
agentgt 10y ago
> I don't think that types are the issue but rather that such languages were not designed with macro systems in mind from the very beginning. Some added complexity is unavoidable, of course. I thought I had a reference somewhere to back that up but can't find it. However I do massively agree having had better planning early in the language could have prevented some serious headaches (its one of the reason I have concerns about Go). That being said there are some that think macros are inherently code smell particularly if your language has lazy evaluation. e.g. Haskell programmers can go quite far with out having macros. That is controlling evaluation may free the need of a majority of macros (ignoring the verbosity saving aspects).

ruste 10y ago

I was also completely unaware that Java had a macro system. I'll have to check that out.

agentgt 10y ago
Calling it a macro system is probably a stretch of the word :) but if you check out APT you should also check out the far sexier Java Agents [1] which is code that changes other code during runtime (ie alters structure and provides meta programming). [1]: https://docs.oracle.com/javase/7/docs/api/java/lang/instrument/package-summary.html https://docs.oracle.com/javase/7/docs/api/java/lang/instrume...

agentgt 10y ago

> I don't think that types are the issue but rather that such languages were not designed with macro systems in mind from the very beginning. Some added complexity is unavoidable, of course. I thought I had a reference somewhere to back that up but can't find it. However I do massively agree having had better planning early in the language could have prevented some serious headaches (its one of the reason I have concerns about Go). That being said there are some that think macros are inherently code smell particularly if your language has lazy evaluation. e.g. Haskell programmers can go quite far with out having macros. That is controlling evaluation may free the need of a majority of macros (ignoring the verbosity saving aspects).