Okay, we all know why macros are evil and why no one likes them. What I would like to present are reasons why I think Kotlin should have them anyway. Not maybe as a tool for everyday use, but as a set of high powered tools when nothing else works. The way I would implement them is the same way it is done in Nemerle (little known fantastic language for .net), as compiler plug-ins. IDE should be able to expand every macro to see generated code. The principal reasons for macro systems are:
(1) Everyone will be doing it anyway. Java doesn’t have macro system so everyone is writing those horrible code generators. Why let people do it in ad-hoc way that IDE doesn’t support and no one else can understand when we can create cannonical code generation tool? You can say that Kotlin won’t be as bad because it has less bloat and I would be inclined to agree but nothing is bloat free and people will want to simplify repetative tasks.
(2) There are some very good use cases. Macro could log in to a relational database at compile time and check you SQL queries to see if all tables and fields really exist. Also, writing most design patterns could be automated via macros. I know IDE can automate design patterns as well but when it does so it generates code which increases LOC and boilerplate. Macros, on the other hand, generate code on compile time so it is not as visible (but you could still expand macro if you want to know what it outputs.) The cancer that is killing Java is not the lack of any specific feature but boilerplate, so I am all for radical steps to prevent boilerplate.
(3) As one wag put it, programming is all about automating repetative task. Macros are about automating writing code. Therefore programmers should support macros.