3 ms·
Saw a talk with Douglas Crockford[0] years ago. He said something like: Before JS classes got introduced he asked why they didn't just implement macros for the
by dgb23 4y ago
Saw a talk with Douglas Crockford[0] years ago. He said something like: Before JS classes got introduced he asked why they didn't just implement macros for the language. Classes are in fact just syntactic sugar. Just like async/await, and now this proposal.
In hindsight he was right. JS would be better off if it did have macros. Much of the whole babel/webpack/react/ts stuff would be just a bunch of macros instead of idiosyncratic build tools and so on. And we would have had much less compatibility churn.
In fact this proposal here, is trivial to implement with macros. Clojure has the same thing (threading operator) and it's just a macro.
[0] https://en.wikipedia.org/wiki/Douglas_Crockford https://en.wikipedia.org/wiki/Douglas_Crockford
- gorjusborg 4y agoFirst, syntactic macros are great, and I've often wished for them to exist in javascript (and other languages). Second, I only trust macros to people who are disciplined to use them wisely. Third, I've met only a handful of developers I would consider disciplined in this way.
- dgb23 4y agoPeople who write widely used macros are typically of that last category.
- gorjusborg 4y agoI've been thinking about your response since you left it. I think that what you said is true in an ideal world. Sadly, there are many developers who want to believe they are the disciplined ones, when in fact they are the trouble makers trying to inflate their ego at their team's/company's expense. Along with discipline, there must be humility. Good luck finding that combination reliably.
- hajile 4y agoMozilla created SweetJS over a decade ago[0]. It added hygenic macros to JS and I'm sure everyone on the TC39 committee is familiar with it. There's a lot to like about it, but macros in such a complicated language as JS are hard to get right. They'd also potentially lead to huge fracturing in the JS ecosystem with different factions writing their own, incompatible macro-based languages. Look at JSX for an example. It's actually a subset of a real standard (E4X -- actually implemented in Firefox for a long time), but just one relatively small syntax addition has added complexity elsewhere. For example, `const foo = <T>(x:T) => x` is valid Typescript for a generic arrow function, but is an error if your file is using JSX. I like the idea of macros, but I suspect they made the right call here. [0] https://www.sweetjs.org/ https://www.sweetjs.org/
- dgb23 4y agoThe issues you describe have emerged regardless of macros. Just with more expensive tooling.
- madeofpalk 4y agoWhat would macros for JavaScript look like? Would you ship them to the client for browsers to execute?
- dgb23 4y agoYes, JS is a dynamic language, so I would expect you ship them as-is.
- mattgreenrocks 4y agoIt's pretty sad that you have to advocate for macros on a site called Hacker News nowadays. They aren't even terribly different from frameworks (which everyone loves): incorrect usage generates a stack trace you need to decipher.
- ketzu 4y ago> Much of the whole babel/webpack/react/ts stuff would be just a bunch of macros instead of idiosyncratic build tools and so on. And we would have had much less compatibility churn. Wouldn't that just trade compatibility churn against running the transpilers on client side in javascript, making it even slower to execute? Moving this part of the execution on the developer side seems like a good choice to me.
- dgb23 4y agoIt’s not as clear how macros affect performance. You can write macros that are very declarative but generate very hairy code that you wouldn’t necessarily write by hand. The result might be much more machine optimized. Sure, you pay some upfront cost for expansion, but generally speaking macros don’t hinder you to write fast code, they just give you more options and trade offs.