supporting ES upgrading with a programming pattern repo?
On Nov 9, 2011, at 10:55 , Claus Reinke wrote:
Both the committee and JS coders could profit from examples.
Amen to that. JavaScript seems worse than any other language when it comes to finding correct information on the web. For example, I trust StackOverflow for many topics, but for JavaScript, it’s often shockingly wrong. Half-truths are even worse than information that is completely wrong.
However, there are so many styles in JavaScript that I don’t think there is a way of creating a corpus that everyone agrees on. The best you can do as a newbie is hitch your wagon to someone that you trust and follow his/her style. There are a few books that allow you to do that (JavaScript the good parts, Eloquent JS, etc.). I really liked “Effective Java”, a similar book would make sense for JavaScript (in many ways “the good parts” already is). Some of Brendan’s tweets, some of Allen’s or David’s posts, and Mark’s recent puzzle would all qualify as material for such a book.
Apart from that, I thought that it might make sense to found some kind of “network of trust” of people who write introductory articles. It would be a brand that tells people that the information they see is correct. For example, when I see something by, say, Addy Osmany, Angus Croll, or Nicholas Zakas I know that there usually won’t be any errors. It might make sense for someone to curate the considerable introductory material that is out there. That could be complemented by a peer review process.
Oops, I think I partially misread your email: You were talking about upcoming changes and new patterns enabled by ES.next. But some of my observations should still hold: You probably need a single person to write such material (or at least to curate it).
Begin forwarded message:
Amen to that. JavaScript seems worse than any other language when it comes to finding correct information on the web. For example, I trust StackOverflow for many topics, but for JavaScript, it’s often shockingly wrong. Half-truths are even worse than information that is completely wrong.
Join the PromoteJS revolution. promotejs.org
However, there are so many styles in JavaScript that I don’t think there is a way of creating a corpus that everyone agrees on. The best you can do as a newbie is hitch your wagon to someone that you trust and follow his/her style. There are a few books that allow you to do that (JavaScript the good parts, Eloquent JS, etc.). I really liked “Effective Java”, a similar book would make sense for JavaScript (in many ways “the good parts” already is). Some of Brendan’s tweets, some of Allen’s or David’s posts, and Mark’s recent puzzle would all qualify as material for such a book.
As an aside, this book is pretty good too: www.amazon.com/JavaScript-Patterns-Stoyan-Stefanov/dp/0596806752
Apart from that, I thought that it might make sense to found some kind of
To keep this thread from getting off-track: I am talking about patterns as a common ground between ES.next spec writers and JS.current coders. Focusing on patterns now would help to get JS coders involved in checking current proposals for consistency/edge cases, instead of leaving that burden to the spec editor alone.
Let me give an example of what I have in mind. I'll pick ES.next modules because they are complex, new, and are documented in a fairly accessible form already.
Joe Programmer has been using module loaders, following certain code patterns, such as:
-
just load a named module and use its exports, synchronously
-
just load a named module and use its exports, asynchronously
-
try loading common libs from CDN, fall back to local copies
-
conditionally load polyfills for older browsers, selectively load different code for mobile browsers
-
load asynchronous file API, loop over exports to convert from file operations from callback parameters to promises
-
re-export (parts of) existing modules as a single module (loop and filter, mix and match)
-
..
Joe Programmer likes to be ahead of the curve, so he wants to know what ES.next modules mean for his coding habits. He finds the ecmascript wiki, and the harmony namespace (isn't it time to separate harmony from ES.next, btw?), and goes looking for modules.
For most ES.next proposals, the first thing he sees is the spec-ese (Joe prefers to learn JS, translated from ES in blogs, rather than study the raw source), but he is lucky: the modules proposal actually has examples and rationales! They don't seem to address all his use cases, and he is beginning to suspect that he will either have to keep his old module loader around, or use ES.next module loaders and reified module objects, instead of the nice and simple ES.next modules.
Joe is slightly confused by all this talk about compilation and early errors: JS is a just-in-time language, so compilation happens behind the scenes, right? And how can he catch those early errors, to keep his clients from being exposed to "compilation errors"? Is there a way to depend on the latest version of a module, but fall back to a known-good version if the latest fails to compile?
Joe wonders whether he should join es-discuss, but he doesn't read or speak spec-ese and ES.next is in the process of writing out the spec. And finding answers to his specific questions in the archives, with their torrents of back-and-forth snippets and alternative design options, turns out to be difficult.
Meanwhile Steven Spec has been answering similar questions by Jim Programmer, Jack Coder, and Doris Developer, and is beginning to wonder whether there is an easier way to find old answers and communicate about the new design and its possible issues. And Ed Editor is having nightmares about missing obscure feature interactions while turning proposals into a coherent spec.
If Ed, Steven, Joe, Jim, Jack, and Doris could communicate via a repository of code patterns, they might understand each other well enough to talk to each other. Before the spec gets frozen.
And if failed design speculations get cleaned from the pattern repository, we'd end up accumulating useful patterns for the blog writers, when ES.next reaches stability and everyone has to look into upgrading.
Claus clausreinke.github.com, clausreinke.github.com/js-tools
Both the committee and JS coders could profit from examples.
The committee wants to ensure that their design decisions lead to improvements in language usage, JS coders want to know what those semi-formal proposals mean for their day-to-day use of the language. Both parties want to be sure that the new proposals do not lead to nasty surprises when put together and confronted with real-life code bases.
(as the @iter example shows, small tweaks might be needed even if no disasters loom anywhere)
Yet the committee cannot look at every JS code base out there in any detail, and JS coders are not comfortable reading the current spec, let alone a variety of subtly different proposals.
Could there be a repo of programming patterns, where
TC39 puts up new patterns they want to enable (patterns as examples or proposals in use)
TC39 puts up old patterns they want to discourage, together with replacement patterns they want to encourage (patterns as transition help, demonstrating that no expressiveness is lost)
JS coders submit patterns that they rely on, so that TC39 can decide how those patterns may be affected by ES.next
JS coders can browse the pattern repo to see what ES.next means for them, and whether their programming styles will be affected
This would not only help to communicate the ES.next design decisions and discussions (if patterns are annotated with the proposals they depend on, and proposals link to the patterns that serve as positive and negative examples).
It would also help TC39, to become aware of possible problem spots early, if we can get JS coders to get involved with such a pattern repo as a more accessible peek at the new design. Examples:
"I've been using 'with' like this - what should I do instead?"
"I have a sequence of alternative module source locations, to be tried in order until one succeeds - can I still do that with ES.next modules?"
"I rely on monkey patching and ES shims - how is that going to work with ES.next modules?"
..
It might get more eyes looking through the effects of putting current proposals into practice, instead of putting most of that responsibility on a single spec editor. That implies that the repo should be a wiki, or a github repo editable by all TC39 members (at least).
What do you think?
Claus clausreinke.github.com, clausreinke.github.com/js-tools
Both the committee and JS coders could profit from examples. The committee wants to ensure that their design decisions lead to improvements in language usage, JS coders want to know what those semi-formal proposals mean for their day-to-day use of the language. Both parties want to be sure that the new proposals do not lead to nasty surprises when put together and confronted with real-life code bases. (as the @iter example shows, small tweaks might be needed even if no disasters loom anywhere) Yet the committee cannot look at every JS code base out there in any detail, and JS coders are not comfortable reading the current spec, let alone a variety of subtly different proposals. Could there be a repo of programming patterns, where - TC39 puts up new patterns they want to enable (patterns as examples or proposals in use) - TC39 puts up old patterns they want to discourage, together with replacement patterns they want to encourage (patterns as transition help, demonstrating that no expressiveness is lost) - JS coders submit patterns that they rely on, so that TC39 can decide how those patterns may be affected by ES.next - JS coders can browse the pattern repo to see what ES.next means for them, and whether their programming styles will be affected This would not only help to communicate the ES.next design decisions and discussions (if patterns are annotated with the proposals they depend on, and proposals link to the patterns that serve as positive and negative examples). It would also help TC39, to become aware of possible problem spots early, if we can get JS coders to get involved with such a pattern repo as a more accessible peek at the new design. Examples: - "I've been using 'with' like this - what should I do instead?" - "I have a sequence of alternative module source locations, to be tried in order until one succeeds - can I still do that with ES.next modules?" - "I rely on monkey patching and ES shims - how is that going to work with ES.next modules?" - .. It might get more eyes looking through the effects of putting current proposals into practice, instead of putting most of that responsibility on a single spec editor. That implies that the repo should be a wiki, or a github repo editable by all TC39 members (at least). What do you think? Claus http://clausreinke.github.com http://clausreinke.github.com/js-tools/