olov

You're trying to make a complex issue simple. It's true that scenarios exist where you can use the redistribution-loophole to keep your modifications to a server side GPL program proprietary (Affero GPL was later designed to prevent that).

Meteor's client and server architecture are very tightly intertwined, and both of them are GPL (v2). Given that the GPL is (deliberately) vague in defining the technical details of copyleft, I can't see how it would be unreasonable for an attorney to take the position that the Meteor client and server parts form one program and thus when the client part is redistributed, the server part must be too.

Heck, I would be surprised if folks like the FSF didn't take that position. "The client and server sides raise different ethical issues, even if they are so closely integrated that they arguably form parts of a single program." -- Stallman himself in [The JavaScript Trap](http://www.gnu.org/philosophy/javascript-trap.html).

The major difference is that JSLint as well as "the good parts" focus on a subset that can be verified statically (before running the program) while restrict mode sanitizes operator semantics that must be verified dynamically (when running the program). I like the few changes strict mode did except for one thing that breaks compatibility in an unfortunate way (this is bound to the primitive, not the boxed number). But we should take all this much further.

More important than anything I'd like us to start talking about sane subsets of JS more, and stop limiting ourselves to what one author considers "good" because quite frankly, _that_ subsets still contains a whole lot of awful stuff.

I want to take this further still. Most JavaScript programmers already use a subset of the language and I believe that there is quite a broad union of those subsets that should resonate with the majority of us. Excluding certain parts of the language will lead to more robust code that is easier to reason about (and more fun to write), I claim. My attempt to formalize it is called "restrict mode for JavaScript" http://restrictmode.org and I laid my case here: http://blog.lassus.se/2011/03/case-for-restrict-mode.html . Would be curious to hear other thoughts about it.

Yes.

"LuaJIT 2.0 intellectual property disclosure and research opportunities" <http://article.gmane.org/gmane.comp.lang.lua.general/58908&#...; is further proof to that.

Rumor has it that Mike Pall is actually a collective pseudonym used by an army of cycle counting language expert cyborgs (from the future).

Tracing is no silver-bullet. Mike Pall is.

I found the blog comments far more interesting than the post itself.

Great article, shame it got optimized away before I had the chance to re-read it.

edit: seems Blogger turned their -O knob to eleven http://status.blogger.com/

I'd also like to see macro capabilities in JS, although as others have said it's not trivial (but certainly not impossible) to add.

For what its worth JSShaper [http://jsshaper.org] may be of interest although it doesn't provide macros per se. It's an extensible framework for JavaScript syntax tree shaping (rewriting/transforming). For a macro-like example, I described how I created an assert plugin for it here: http://blog.lassus.se/2011/03/c-style-assertions-in-javascri...

It gives you the power of macros and some, but with more power comes more complexity. Declarative style matching and rewriting remediates some of that, and it's the direction I'm taking JSShaper in.