Feeling less comfortable is exactly the point :)
889 karma · joined July 8, 2009
If there had been logic, data, or some other proof besides a couple of counter examples, I may need to do more than appeal "argue from authority." They aren't, so I'm sticking with the authority.
My opinion is that if you use let, don't use var, and if you use var, don't use let. Either one on its own is fine, together they are just a mess.
If you master one of these fields, you'll be doing well. I agree on taking an intro to each of these, but only to figure out which one you want to specialize in later on and because it's nice to know something about other related fields. You won't master all of these in your career, so don't let the list intimidate you.
That doesn't mean don't testify though, what's more important to you, your career or getting the company punished for what it did?
Sounds like he programs too.
That doesn't make his 5 star review illegitimate at all. If he thought it was a 4 star book, he would give it four stars, if he thought it was a 3 star book, he wouldn't give a rating. He gave it 5 stars because he thinks it is worth 5 stars.
------------
His note in full from your link:
------------ NOTE: I am not paid by publishers to review and tout their books. And I do not guarantee to publish a review about a particular book. If I do not like a book, I will not review it here. Writing a book requires significant time, effort, and expense, and I will not trash someone else’s writing. My goal here is to provide what I hope is an honest assessment and provide useful information to readers seeking particular types of books. Sometimes I offer a few critical comments, but mostly, I try to provide useful information that can help a reader decide to purchase a book–or not.
I receive sample copies from publishers, and I am under no obligation to publish reviews of any of those books. Indeed, I review only the books that I want to review, and I try to assess how well I think the books meet the goals set forth by their writers.
Publishers may mail printed books for possible review (no promises!) to: Si Dunn, Sagecreek Productions LLC, 1101 W. 34th St., #131, Austin, TX 78705-1907. As a general rule, I do not review e-books.
If you buy a book or e-book through links published in one of my reviews, I will make a few dimes (and not much more!) through my Amazon Affiliate account. Periodically, after printed books have been on my shelves for a while, I have to make room for new ones. So I sell some of the reviewed books on the used-book market. A few get donated to libraries. And a few are passed along to friends and relatives.
Book reviewing definitely is not a way to get rich quick–nor slowly. But reviewing is something I have done, part-time, for more than 35 years, mainly because I love books and enjoy helping authors reach new readers.
This title caught my attention, so first purpose, check.
I think the book is positioned for beginner to mid-career engineers working with JavaScript that want to do a deeper dive and based on the title is presented in an irreverent and funny tone. If it is those things, it accomplishes #2.
Great title. I haven't read the book, so I don't have any opinion on it beyond that, but can we try and take things a -tad- less personally?
var foo = "abc";
function do ( foo ) { foo = "def"; console.log( foo );
let foo = "bar";
console.log( foo );
var foo = "baz";
console.log( foo );And of course var has to be around for backwards compatibility, but if the addition of let is being made to make variable declaration more intuitive or simpler then it is failing because var must be included. You cannot consider let in isolation and when considered in combination with var, it makes things more complicated.
But adding a block level variable declaration just adds to the complexity of the language and doesn't add any real additional capabilities. It adds some nice fluff around loops and asynch operations, but that is all easily done using current scoping rules once you understand closures.
var is still going to be around, but now we've added let. you might like let's scoping rules better then var's scoping rules, but now we'll have both. the interaction between the two is going to have some amazingly confusing and complex edge cases. If you think that hoisting and closures are confusing now, just wait until let is thrown into the mix as well. Even if let is simpler, var isn't going away. So we're just adding complexity to the system.
The ideas in the article are terrible. It does not look remotely interesting. I read these slides and think, this is someone that doesn't like JavaScript and is trying to make it more like languages they enjoy, like Java. Trying to eek out every performance improvement possible by removing developer friendly features is not a good idea.
"let" scoping is a terrible idea, it is not at all sane. Functional scoping is clean and simple, there is only one thing that scopes variables, functions. Thats it. Easy. Block level scoping will introduce coding nightmares trying to figure out what scope your variable is in. I can just imagine the nightmare code people are going to write interspersed with both var and let, and having to figure out how the variable was declared to know its scoping rules. GAH. Not having to tell the compiler what kind of variable you are trying to use makes coding so much simpler. Not having to cast variables manually is a godsend. And this is considered a good thing to take away?
Reading further into this presentation, it's clear that the developer wants JavaScript to be Java. any<T>...? No no no no no no no.
Keep classes away from JS, unneeded complexity. Classes are inherently complex compared to the simplicity of prototypes. Classes sound like such a good idea, until you are knee deep in the inheritance chain trying to figure out where some method or attribute is defined and/or overwritten. They are one of the biggest reasons people need to use an IDE to write code.
Just learn JavaScript, guys. It'a a really simple language, just not like the ones you learned in university.