3 ms·

I think many will agree that the import statement example is fairly weak. If you are writing import statements by hand you should just seriously consider the be

by agentgt 10y ago

I think many will agree that the import statement example is fairly weak. If you are writing import statements by hand you should just seriously consider the benefits of using an IDE. That being said I use code generation instead of the IDE all the time but for harder things like generating fluent builders , copying objects, generating visitor pattern for pattern matching etc. What I do is write Groovy scripts and will either use Groovy GString templates or Squares Poet to generate code. What I do though instead of making some sort of DSL is use a subset of the language itself to help the code generator. For example copying a list of private fields I can quickly turn into either an immutable object with builder or an interface or just a plain object copy etc etc. I put my Groovy scripts in my ~/bin and then just keep my terminal running. I then copy from Eclipse/Intellij some code and then run: pbpaste | SomeGroovyTransformScript.groovy | pbcopy Then paste back the code into the IDE. Ideally I would use APT libraries (and in same cases I have converted Groovy code into APT libraries) but some times I just want something lightweight.

outworlder 10y ago
> I think many will agree that the import statement example is fairly weak. If you are writing import statements by hand you should just seriously consider the benefits of using an IDE. Agreed that the example is weak. I do agree that, for import statements, having and IDE fill those in for you is fair game. It can figure out what you are trying to use and offer to import those, that's fine. The problem here is the slippery slope. You get an IDE writing import statements. Than it will write getters and setters for you – which is already an aberration that prevents language evolution. For instance, C# has a syntax for default getters and setters (and for properties, in general). Then you get IDE plugins for writing boilerplate (for, say, JEE). Then you end up with a XML preprocessing pass that writes Java code (XDoclet). It's amazing the amount of machinery that gets created when people do not have access to a useful macro system.
- ruste 10y ago
  I probably should have presented more than one example in my post. A lot of people are focusing on the example I presented and not the general utility. Live and learn I guess. :/
  - agentgt 10y ago
    I like the effort and general idea/content but for me almost any sort of plain text code generation is just not that impressive. It would have been interesting if you had for example generated byte code or enhanced some existing code (Java classes) but I realize that was is probably out of scope for the article. For example it would be funny/interesting if you had Guile VM generating JVM byte code in realtime and some how the Guile VM could figure out some sort of optimizations based on macros to generate better bytecode.
- agentgt 10y ago
  Yes but there is also abuse and or complexity that doesn't make it easy. One of the classic examples for me at least is OCaml's Camlp. For Lisp like languages it is easier to have a macro language but for typed languages I think it becomes far more difficult both to implement and understand. 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]). APT is not that powerful but it gets you quite far and going back to OCaml the new ppx language extension is actually fairly similar (ie annotation processing instead of a complete macro/preprocessing language). .NET has something analogous but even more powerful (IIRC as well as the whole access to the AST aka LINQ style). > Then you get IDE plugins for writing boilerplate (for, say, JEE). Then you end up with a XML preprocessing pass that writes Java code (XDoclet). 2001 called and wants it example back :) . Yes APT didn't exist for a while. Tangental but XDoclet sort of reminds me of Go's very weak annotation system. And again It takes time to get a macro/preprocessing engine right particularly for typed languages. e.g. Rust has had some fair challenges getting this right and even their macro system is not completely hygenic IIRC. [1]: https://github.com/google/auto https://github.com/google/auto
  - outworlder 10y ago
    > ... 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.

by agentgt 10y ago

outworlder 10y ago

> I think many will agree that the import statement example is fairly weak. If you are writing import statements by hand you should just seriously consider the benefits of using an IDE. Agreed that the example is weak. I do agree that, for import statements, having and IDE fill those in for you is fair game. It can figure out what you are trying to use and offer to import those, that's fine. The problem here is the slippery slope. You get an IDE writing import statements. Than it will write getters and setters for you – which is already an aberration that prevents language evolution. For instance, C# has a syntax for default getters and setters (and for properties, in general). Then you get IDE plugins for writing boilerplate (for, say, JEE). Then you end up with a XML preprocessing pass that writes Java code (XDoclet). It's amazing the amount of machinery that gets created when people do not have access to a useful macro system.

ruste 10y ago
I probably should have presented more than one example in my post. A lot of people are focusing on the example I presented and not the general utility. Live and learn I guess. :/
- agentgt 10y ago
  I like the effort and general idea/content but for me almost any sort of plain text code generation is just not that impressive. It would have been interesting if you had for example generated byte code or enhanced some existing code (Java classes) but I realize that was is probably out of scope for the article. For example it would be funny/interesting if you had Guile VM generating JVM byte code in realtime and some how the Guile VM could figure out some sort of optimizations based on macros to generate better bytecode.
agentgt 10y ago
Yes but there is also abuse and or complexity that doesn't make it easy. One of the classic examples for me at least is OCaml's Camlp. For Lisp like languages it is easier to have a macro language but for typed languages I think it becomes far more difficult both to implement and understand. 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]). APT is not that powerful but it gets you quite far and going back to OCaml the new ppx language extension is actually fairly similar (ie annotation processing instead of a complete macro/preprocessing language). .NET has something analogous but even more powerful (IIRC as well as the whole access to the AST aka LINQ style). > Then you get IDE plugins for writing boilerplate (for, say, JEE). Then you end up with a XML preprocessing pass that writes Java code (XDoclet). 2001 called and wants it example back :) . Yes APT didn't exist for a while. Tangental but XDoclet sort of reminds me of Go's very weak annotation system. And again It takes time to get a macro/preprocessing engine right particularly for typed languages. e.g. Rust has had some fair challenges getting this right and even their macro system is not completely hygenic IIRC. [1]: https://github.com/google/auto https://github.com/google/auto
- outworlder 10y ago
  > ... 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.