It’s funny to praise language niceties and speak against macros in the same post. Macros are just the easiest way to add new language features to your code.
My fav example is automatic sql table and column typo checking. The macro introspects the db and you get syntax errors if the table/column isn’t found. Same idea can also be used for csv and json. Or api spec file on different server-the compiler can make http requests to show you syntax errors
My fav example is automatic sql table and column typo checking. The macro introspects the db and you get syntax errors if the table/column isn’t found. Same idea can also be used for csv and json. Or api spec file on different server-the compiler can make http requests to show you syntax errors
But the problem in all these cases isn't "I want syntax errors if this table/column doesn't exist or my http request doesn't fit spec", it's "I want to make sure my table/column exists and my http requests are in spec". Unit tests can do that. What unit tests can't do is go into the code under test and modify it so that it breaks in production. The macros you're describing can do that.
The macros you're describing are cool, but they don't do anything that can't be done with unit tests, and they're not without risks. You're essentially running test code in production.
Again the same point applies. Either you become fan of low level languages with little-no time saving features, or you are willing to use helpful high level language features (or add your own).
You can use unit tests as replacement for type checking system, for example. Test code in prod and all that.
I’ve also built macros which snapshot check output of functions for tests. So the test just calls a bunch of functions, and it saves sexps in a test dir with the expressions commented. Difficult to do that in Go or Java. Would you just use ruby/python? or some bespoke non macro code gen system?
Unit tests can also verify macros work.
It seems your point is something closer to how macros are too hard for people to maintain. That’d be more interesting of a point to make (and details for you to provide if you have any.)
Again the same point applies. Either you become fan of low level languages with little-no time saving features, or you are willing to use helpful high level language features (or add your own).
Again, the same point applies. In my experience, macros aren't a time-saving feature in the long run, as compared to alternatives.
Macros are a big time-saver up-front. Obviously. But they make code harder to understand, and in the long run, understanding code is the most important thing in most codebases.
There are exceptions, but those exceptions tend to be the ones already implemented by you Lisp interpreter. Yes, I understand that many Lisp structures are macros rather than core language features.
And I think that if you actually look at the implementation of those macros in production-quality Lisp interpreters, you'll discover that some of them are significantly more complicated than you thought they were, because they're handling edge cases you didn't think of. The benefit of having macros battle-tested by thousands of users in disparate use-cases is that it susses out all those edge cases. You and I aren't going to have thousands of people writing code against our macros in most cases: it's just us and our teammates using the macros, and as a result, we get to find those edge cases ourselves, i.e. we have bugs.
It seems your point is something closer to how macros are too hard for people to maintain.
Yes.
That’d be more interesting of a point to make (and details for you to provide if you have any.)
I'm not sure what details I could provide which I haven't already provided.
Comments
It’s funny to praise language niceties and speak against macros in the same post. Macros are just the easiest way to add new language features to your code.
My fav example is automatic sql table and column typo checking. The macro introspects the db and you get syntax errors if the table/column isn’t found. Same idea can also be used for csv and json. Or api spec file on different server-the compiler can make http requests to show you syntax errors
But the problem in all these cases isn't "I want syntax errors if this table/column doesn't exist or my http request doesn't fit spec", it's "I want to make sure my table/column exists and my http requests are in spec". Unit tests can do that. What unit tests can't do is go into the code under test and modify it so that it breaks in production. The macros you're describing can do that.
The macros you're describing are cool, but they don't do anything that can't be done with unit tests, and they're not without risks. You're essentially running test code in production.
Again the same point applies. Either you become fan of low level languages with little-no time saving features, or you are willing to use helpful high level language features (or add your own).
You can use unit tests as replacement for type checking system, for example. Test code in prod and all that.
I’ve also built macros which snapshot check output of functions for tests. So the test just calls a bunch of functions, and it saves sexps in a test dir with the expressions commented. Difficult to do that in Go or Java. Would you just use ruby/python? or some bespoke non macro code gen system?
Unit tests can also verify macros work.
It seems your point is something closer to how macros are too hard for people to maintain. That’d be more interesting of a point to make (and details for you to provide if you have any.)
Again, the same point applies. In my experience, macros aren't a time-saving feature in the long run, as compared to alternatives.
Macros are a big time-saver up-front. Obviously. But they make code harder to understand, and in the long run, understanding code is the most important thing in most codebases.
There are exceptions, but those exceptions tend to be the ones already implemented by you Lisp interpreter. Yes, I understand that many Lisp structures are macros rather than core language features.
And I think that if you actually look at the implementation of those macros in production-quality Lisp interpreters, you'll discover that some of them are significantly more complicated than you thought they were, because they're handling edge cases you didn't think of. The benefit of having macros battle-tested by thousands of users in disparate use-cases is that it susses out all those edge cases. You and I aren't going to have thousands of people writing code against our macros in most cases: it's just us and our teammates using the macros, and as a result, we get to find those edge cases ourselves, i.e. we have bugs.
Yes.
I'm not sure what details I could provide which I haven't already provided.