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.
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.)