3 ms·
It could be made to work technically, certainly. But it'd be a complete mess of a code base. Code is read much more often than written, easily understanding a
by Nitramp 13y ago
It could be made to work technically, certainly.
But it'd be a complete mess of a code base. Code is read much more often than written, easily understanding a code base is incredibly important, and really hard in larger systems.
If even your syntactical constructs behave subtly different (let alone the code you're writing!), you're setting yourself up for unpleasant surprises.
There's an excellent book on UX, "Don't make me think". The same applies to code: strive to reduce the cognitive load it takes to understand a piece of code as much as possible.
- couchand 13y agostrive to reduce the cognitive load it takes to understand a piece of code as much as possible. Agreed. And it seems macros can really help with that, by encouraging a DRY codebase.
- Nitramp 13y agoAs others have noted, macros in theory could really help with that. But with macros in practice, I wouldn't be so sure. Macros essentially add syntax to languages. Syntax to help with common tasks is nice, but if you end up with lots of ad hoc syntax for lots of very divergent, and maybe not so common tasks, you're in trouble. The problem is just the multitude of syntax constructs that typically end up way underspecified, as opposed to the much more formal and strict models of a language that went through a specification process. Imagine learning not three kinds of loops (for, while, do), but 300 subtly different ones in one code base. Ugh. On the other hand, lots of boilerplate make code unreadable just by the sheer amount of it. This is a very hard balance to strike, I'd rather err on not giving every developer on a code base the power to add new syntactical abstractions.