4 ms·
there is two sides. probably, one evil thing is you have to deal with every other's abstraction and it will make you frustrated when there is a large codebase
by swuecho 11y ago
there is two sides.
probably, one evil thing is you have to deal with every other's abstraction and it will make you frustrated when there is a large codebase and a deadline.
- kazinator 11y agoLet's see, what would I rather deal with. * Another programmer's 15 function API, and a document on how to use it properly? * Or another programmer's 15 function API, along with three macros which use the API properly, and capture all the scenarios I need based on a couple of examples.
- GFK_of_xmaspast 11y agoHow's this any different than taking a big ugly api and writing three shims around it to call it in the way you want?
- kazinator 11y agoThe difference isn't whether or not code is written; the question is who/what writes it: - Does the machine write it, using a reliable syntax rule loaded into the compiler (implemented as a macro); or - Does the programmer, by hand (or with textual preprocessing, copy and paste, IDE help, ...). Macros can be as smart as you want them to be.
- swuecho 11y agogenerally, even bad api is easier to understand or debug than macro. and not all macros are well written.
- kazinator 11y agoMacros being hard to debug may be true of some macro systems that you know. Not all macros are well written is a poor argument; not all anything is well written ... so don't use anything!