Hacker News Reader

Comment by drivingmenuts | Hacker News Reader

> we need to establish a good culture that doesn't abuse macros

I'm sure everyone who has ever looked at C macros has thought the same thing. It's a great theory.

In practice, having macros will lead to someone abusing them and eventually, that abuse will be become institutionalized.

Don't say "it could never happen here" because it can and it inevitably will.

I don't have a specific problem with all of this, except I keep thinking a better solution would be to hammer browser manufacturers to keep their shit up to date or explain why they are not doing so.

View on HN

I think the Clojure community manages to do pretty well in discouraging macros except as thin sugar over functionality avaible through normal channels. It also has some very complicated macros that give it a type system and lightweight threading and channels that would have have had to be implemented by the language designers in other languages.

I'm willing to run into the occasional macro abuse to get goodies like core.async and core.typed.

> I don't have a specific problem with all of this, except I keep thinking a better solution would be to hammer browser manufacturers to keep their shit up to date or explain why they are not doing so.

That's the thing though. When a new proposal comes out, if it's released in the form of a macro it can be tested without vendor buy in. The pressure relief on vendors to keep up to date with the standard is just an unintended (maybe negative * ) side effect.

* Personally I like being able to count on "current" features and I'm not opposed to using shims to patch the environment up to a workable level.

Do you even Lisp, bro?

(Forgive the irresistible pun, but the sentiment is sincere: This feature is based on Scheme, so looking at C seems misguided.)

But alas, the browser wars are upon us once again. FF vs Chrome is approaching the silly.

On the other hand, there are merits in their differences. Chrome, although it would prefer Dart, looks upon JS as legacy that they can approach via a good VM/JIT, and a brilliant Developer Tools suite.

FF on the other hand is leading into the JS futures on two fronts: asm.js for both performance and C/C++/.. integration into the browser, and ESnext. Google is very reluctant to invest in ESnext now, just look at the compatibility charts.

This makes sweet.js strategic, it lets us at least experiment with ESnext features as far as macros can take us. I'm hoping sweet.js can also help us make use of asm.js from within the browser buy building macros for things like structs, which halve or more memory footprint of object arrays.

Lets be aware of the war, and do what we can do to resolve it.

The C preprocessor is terrible, but rampant cpp insanity is much, much less prevalent these days -- the C culture has made its peace with the technology. A similar accommodation would doubtless happen with JS macros, particularly as there's almost no chance that the implementation would be as brainless as C's.

Reply on news.ycombinator.com