3 ms·
Most enterprise software nowadays is broken up in services or micro-services anyways, and monoliths spanning more than 6 to 15 developers are becoming a lot mor
by didibus 5y ago
Most enterprise software nowadays is broken up in services or micro-services anyways, and monoliths spanning more than 6 to 15 developers are becoming a lot more rare. If you've got a monolith with 500 developers touching the code base you're in trouble even if you used Haskell.
Otherwise, macros are actually not super hard to figure out, Lisp macros are easy to write and that means also easy to read and understand, and you've got an interactive development environment so you can quickly explore and try things out to learn how a macro behaves.
Like you said, Clojure also doesn't have reader macros, so the syntax is standard across the board, so macro usage is limited in scope to particular call sites.
Finally, it's not like you're going to have a myriad of custom macros, and generally when you have them they make things simpler and easier, not harder. So you quickly can ramp up on the common macros of a code base and become familiar with them and start to benefit from their usage as well. They'll also likely have a doc string that documents them, so it's not like you have nothing to go with to understand what they do.
- chii 5y ago> Lisp macros are easy to write and that means also easy to read and understand just because something is easy to write doesnt mean it's easy to read and understand - case in point : look at perl.
- didibus 5y agoFair, in this case my feelings are they are also easy to read and understand, compared to alternatives. Similar behavior implemented with text parsing, or annotation, or pre-processor, or inside the compiler, the code to implement them is a lot less tractable. Once you know how to write macros, it becomes fairly easy to also look at the implementation of a macro and figure out what it does. Macros tend to be very self-contained and often relatively short in implementation.