437 karma · joined July 3, 2011
1. First, if you buy and read the book, your writing will definitely improve. You will write better than you ever have. I am confident you will. Those tiny grammar books on amazon.com wouldn't help much because many don't cover the crucial topics for writing well. I read nearly all of them.
2. Language is instinctual, so arguing about grammatical rules is pointless. Take this passage from my book: "I agree with Steven Pinker, as he describes in his book "The Language Instinct," that humans have an instinct to learn and use language, and some nonstandard grammars and dialects perceived to be unsophisticated and ungrammatical (Appalachian English Vernacular and Black English Vernacular, for example) do, in fact, follow sophisticated grammatical rules.
I will not hurl even a pebble of criticism to anyone who uses English grammar to his or her own inclination. Instead, this book helps people who want to improve their Standard American English and Standard British English grammar. By “standard,” I mean the form used in academia, mainstream businesses and books, and formal and informal writing aimed at the general public or educated readers.
3. For the first bullet, I combined two similar bullets into one, hence the possible oddity. I constructed it for brevity, not for eloquence. No need to niggle over a bullet; it's a peccadillo. Incidentally, I wrote an entire chapter on how to write eloquent prose.
4. Ztratar, I presume you would agree that books are not useless. While anyone can probably learn anything online, books are still usually more organized and better researched than disparate articles and blog posts spread across hundreds of websites. In fact, to my knowledge, about half of the content in my book cannot be found online. I have devised some new grammatical constructions and techniques for writing skillfully.
5. Icambron, you should definitely read my book. You will learn a lot. For example, you will learn that all those things you pointed out are actually grammar myths (aka superstitions). I have an entire section on myths that many people believe are legitimate rules of grammar. Many such myths abound even in schools, including college. You should read the following article, a section from my book; you may find some of the cool sentence constructions quite different from the prosaic and formulaic constructions taught in schools: https://grammarandwritingforcreators.com/Creative_Powerful_W...
5. Seanmcdirmid, I wrote an entire section on the rhythm and euphony of sentences, another topic rarely found in grammar books. You can read this new figure of speech that I have devised (unrelated to rhythm, but all the examples employ rhythm): https://grammarandwritingforcreators.com/Conceal_Reveal_Arti...
To clarify, it is Chrome's decision to garbage collect the str variable in that context that resulted in str being garbage collected. It is not a result of a JavaScript bug.
Moreover, different browsers have different implementations for how they garbage collect variables in closures' scope chain. Heck, browsers do their own thing when it comes to many aspects of JavaScript.
On second thought (from our previous back and forth), you are correct that I did not explicitly discuss this specific issue in my earlier post. So you win :) and I have up-voted your two comments accordingly.
Here is the code I think you are referring to: var run = function () { var str = new Array(1000000).join('*'); var logIt = function () { console.log('interval'); }; setInterval(logIt, 100); }; setInterval(run, 1000);
I don't see why you don't understand why I am saying. My first post explains in detail how closures work and why the issue is not a JS bug, though it is indeed a memory leak. All I can say is that I have explained the overall inner workings of closures in JS, and my explanation covers all the scenarios outlined in the blog post.
This is the crux of the matter of the entire blog post:
"...str is only referenced in the main body of run, and in doSomethingWithStr. doSomethingWithStr itself gets cleaned up once run ends… the only thing from run that escapes is the second closure, logIt. And logIt doesn’t refer to str at all! So even though there’s no way for any code to ever refer to str again, it never gets garbage collected!"
And I explained why that problem is observed and why closures work the way they do.
PS. I will humbly agree to disagree: I think that I have explained all the scenarios outlined in the blog post and you disagree with me. This is not a problem; there is nothing wrong with disagreeing.
First, you are correct that I specifically mentioned the logIf function when I discuss the specific example.But that does not take away from my thorough explanation of the main reason for the problem. In fact, everything I said about the logIt function applies to the doSomethingWithStr function, since they are both closures, so my explanation stands as is.
If you read my explanation again, you will see that I clearly explained that closures still have access to the outer function's scope, so both the logIt and the doSomethingWithStr functions have access to the outer function's scope chain even after the outer function or any of the other closures returns.
It is not until both all closures are destroyed or returns that the outer function's scope activation object is destroyed.
This is not devastating, it is how closures and scope chain work in JavaScript. See my detailed explanation below. The crux of the matter is that the closure still references the outer function's scope chain, even after the outer function has returned. And the outer functions's scope chain is referenced by the closure until the closure is destroyed or returns.
Here is a technical explanation of why there is a memory leak and how to fix the problem.
The scope chain of Closures (in JavaScript) contains the outer function(s) activation object. The activation object of a function contains all the variables that the function has access to, and it is part of a function’s scope chain.
This means the inner function (the closure) has access (a reference) to the outer function’s scope chain, including the global object. And even after the outer function has returned, the closure still has access to the outer function’s variables.
Therefore, the activation object of the outer function cannot be destroyed (for garbage collection) after it has returned, because the closure still references its variables.
When the outer function returns, its own scope chain for execution (its execution object) is destroyed, but its activation object is still referenced by the closure, so its variables will not be destroyed until the closure is destroyed.
The execution context of a function is associated with the functions’ activation object, but while the execution object is used for its own execution and is destroyed when it returns, its activation object is referenced by closures—its inner functions.
Now, as to the specific example in question: The reason the str variable is never destroyed is because it is referenced buy the logIt function because the logIt function's execution object references the entire scope chain of the run function, and the logIt function is never destroyed, so the str variable remains in memory.
As the original author (OP) suggested, be sure to dereference any local variable in the outer function that the closure is using, once the closure is done with it or once the outer function is done with it.
Also, simply setting the logIt function to null (when it completes execution—returns) will allow the str variable and the entire scope of chain of both the logIt and the containing run function to be destroyed and ready for garbage collection.
For a detailed explanation of closures in JavaScript, see "Understand JavaScript Closures With Ease": http://javascriptissexy.com/understand-javascript-closures-w...
Thanks for the wonderful compliment and encouragement, laughfactory. I am very happy that my blog is making a difference. Good luck with your learning.
It appears that you have the passion and determination to follow through with learning JS and then Meteor. You can skip Node.js/Express.js/Backbone.js and go straight to Meteor, if your goal is to develop modern web applications with JS soon (without the lengthy time needed to learn all the libraries and frameworks needed to put a full Node.js app together).
There will be Meteor hysteria for sure, but I don't know if it will happen so soon, although this book will help quite a bit.
The Crux of the Matter:
Coming from Node.js/Backbone.js/Express.js, I was pleasantly shocked and surprisingly inspired by how pleasurable and productive it is to develop with Meteor. I am not sure I feel this way about any other web-dev technology besides jQuery. Meteor is so awesome that it makes the book easy to get through and fun to learn from (the book is a web app, a book, and a tutorial in one; it is more than just a book, hence my use of the word “use” instead of “read”).
The book covers most of the big Meteor concepts with example code and it guides you along as you build the Microscope web app—a "real world" application you can deploy and actually use. You will learn so much and get through the book so quickly that you will want to develop your own web app with Meteor in an instant. Be warned: You will be giddy with excitement at how easy it is to get stuff done with Meteor. Using Meteor is analogous to using an iPhone for the first time after using one of those "smartphones" [1] that were available prior to the launch of the iPhone.
The alternative to using this book is to learn Meteor by painstakingly browsing and reading the thorough (but not necessarily logically organized for structured learning) Meteor docs. Forget finding a proper "Getting Started with Meteor" tutorial; they are outdated and lack depth. The book summarizes some of the important Meteor concepts in a logical, succinct, and exemplary manner, with hands-on implementation.
There are some specific Meteor core concepts that the book either doesn't cover or only discusses briefly, like eJSON, Deps, Custom Reactivity, and cursor.observe (similar to Backbone's model.on events). But fortunately, Chris Maher does an excellent job covering these topics in depth on EventedMind.com [2]. Therefore, I highly recommend the book along with frequent visits to EventedMind.com to get a thorough understanding of Meteor.js, so you can confidently start building Meteor apps straightaway.
It is worth noting that the book's format (a web app with comments, videos, frequent updates, and the main Microscope tutorial, in addition to PDF and eBook copies of the book) is groundbreaking and must be celebrated. Every book on any web development topic should be published in this manner. Authors take note.
Background: I am the dude blogging at http://javascriptissexy.com/ and I am a Frontend Developer (JavaScript Guru). Incidentally, I will likely write a detailed blog post about Meteor ("How to Learn Meteor Properly," perhaps) in a few weeks, after I develop my first Meteor app.
[1] http://reviews.cnet.com/cell-phones/sanyo-katana-6600-black/...
Sasha, could you elaborate on the quote above a bit more so that we can better understand which use cases are not ideal for Meteor right now? Thanks.
I really want this to work out, because my application needs this kind of technology to be reliable and accurate. I just processed the article at the link below, and the word "Tesla" was not captured as one of the topics. http://www.teslamotors.com/blog/most-peculiar-test-drive-fol...
In most cases, however, the eBooks (Kindle) are cheaper on Amazon, but I am willing to pay a few dollars more to get the eBooks in all 3 formats (.pdf. .epub, and .pdf). I personally prefer to use iBooks (.epub works fine), when I am on my iPad, and the .pdf—when I am on my laptop.
Here is the 45% off discount code: IUGD45 (45%)
I would advise that you make the digital copy of the book available as soon as possible—I am an interested buyer as well.
During the entire interview, I imagine PG and his partners were likely analyzing and processing your idea, your capacity to execute your idea, and your potential to succeed compared with the potential for other top-tiered candidates to succeed. Also, they were likely looking for signs, any sign (based on prior failures), that were predictor of failure.
In my opinion, you were likely turned down because either they weren't convinced that you (along with your idea) have the potential to succeed more than the candidates they were considering, or your case showed signs of potential failure. Note that the signs of potential failure is not necessarily reflective of you or your idea, it is simply based on actual factors that Y Combinators have seen in startups that had eventually failed. I have read about this from PG himself right here on HN.
If Y Combinator turned down a potentially primed-to-succeed applicant because the applicant did not convincingly answer one question (while being very convincing on all the other questions), then I am definitely mistaken about all I have read about PG and Y Combinator. These chaps are well-reasoned and thoroughly experienced investors, I don't think they will turn down a potential DropBox for missing one question—well, I hope not.