D4mations.com

JavaScript: The Good Parts



Google Tech Talks
Web Exponents
presented by Doug Crockford
February 27, 2009

blog post: http://google-code-updates.blogspot.com/2009/03/doug-crockford-javascript-good-parts.html

JavaScript is a language with more than its share of bad parts. It went from non-existence to global adoption in an alarmingly short period of time. It never had an interval in the lab when it could be tried out and polished. JavaScript has some extraordinarily good parts. In JavaScript there is a beautiful, highly expressive language that is buried under a steaming pile of good intentions and blunders. The best nature of JavaScript was so effectively hidden that for many years the prevailing opinion of JavaScript was that it was an unsightly, incompetent abomination. This session will expose the goodness in JavaScript, an outstanding dynamic programming language. Within the language is an elegant subset that is vastly superior to the language as a whole, being more reliable, readable and maintainable.

Speaker: Douglas Crockford
Douglas Crockford is a product of our public education system. A registered voter, he owns his own car. He has developed office automation systems. He did research in games and music at Atari. He was Director of Technology at Lucasfilm. He was Director of New Media at Paramount. He was the founder and CEO of Electric Communities/Communities.com. He was founder and CTO of State Software, where he discovered JSON. He is interested in Blissymbolics, a graphical, symbolic language. He is developing a secure programming language. He is now an architect at Yahoo! and the world’s foremost living authority on JavaScript.

Original source

d4mer

, , , , , , , , , , , ,

25 responses to “JavaScript: The Good Parts”

  4. Why is "===" good and "==" bad? They do different things. You should use whichever operator does what you want it to do, not always default to one even if it doesn't accomplish what you're trying to do just because someone said the other one is evil one time.

  5. There are a number of issues I have with this talk. First of all, while JavaScript is enormously "popular," saying that it is used everywhere is rather overstating things. The fact is, JavaScript is only dominantly used in the web browser and to a lesser extent in Node. Everywhere else, JavaScript has to compete against better languages and so it doesn't get used very heavily. For example, in game development, C++ and C# are the preferred languages. While there is JavaScript-derived UnityScript, almost nobody uses it because it's such an awful language. Before you point out that browser-based games are increasingly popular, let me remind you that these are simply more web development.

    Another example. In mobile development, using JavaScript for cross-platform apps is not especially strong. Developers overwhelmingly prefer using the languages native to these platforms, i.e., Java for Android and Objective-C/Swift for iOS.

    Final example. In the Internet of Things, JavaScript is not gaining traction against C, Java, Python, even Perl! Again, developers prefer using languages that are better than JavaScript.

    So I think I've made my point. JavaScript is only good for web development and perhaps some back-end stuff, but otherwise it has no place anywhere else.

    Crockford says that JavaScript is essentially Scheme with C syntax. This is patently untrue. JavaScript is nothing like Lisp nor Scheme:

    1. JavaScript’s C-like syntax robs it of Lisp’s clean and elegant syntax. JavaScript code is always so painful to read!

    2. Lisp’s central data structure is the list. JavaScript doesn’t have a list data type. JavaScript’s central data structure is the associative array, which often masquerades as some other data type.

    3. Lisp is homoiconic, i.e., its code and its data have the same primary representation. JavaScript is not. Not even a little bit.

    4. Lisp’s homoiconicity provides for a powerful macro system. JavaScript does not have macros.

    5. Lambdas do not make JavaScript Lisp-like, any more than C++, Java, Python, Haskell, and Smalltalk are Lisp-like. Anything you can do in JavaScript as a functional language, you can do in Smalltalk!

    Lisp (or Scheme) is a purely functional language. JavaScript is primarily an imperative/procedural language with some functional capability tossed in. Here’s the elephant in the room: most JavaScript code is NOT functional, it’s procedural. So even in terms of real-world usage, JavaScript bears little resemblance to Lisp.

    I wish Douglas Crockford and his minions would stop repeating this idiotic meme. Please!

    As Crockford says, JavaScript's speed of execution in the web browser doesn't matter, but it does matter on the back end in Node. Here, JavaScript (V8) does not fare well against Go and Java. If you care about execution performance, you'll choose Go or Java over Node.

    Crockford says Java has a niche in the server space. What an idiotic thing to say! Java is one of the most versatile programming languages in the world. It's used nearly everywhere for everything, including cloud computing, robotics, Internet of Things, numerical computing, mobile, desktop, games, etc.

    Crockford says he prefers greater minimalism for JavaScript, pointing at ES3.1. I guess he now knows that ES6 is a frickin' language behemoth with over 545 pages of language spec! ES3 only had 180 pages, and ES5.1 had 245 pages. This is a very bad trend.

    Crockford says that proper concurrency needs not, and should not, be built into the language (the way it is in Go and Erlang/Elixir). I couldn't disagree more. Genuine concurrency should be designed into a language so that it fits well with all the other language features and works optimally.

    And finally, Crockford is frequently making the same mistake again and again: confusing "strong" typing with static typing. Strong typing has nothing to do with compiling. Strong typing is the opposite of "weak" typing. For example, Smalltalk is a dynamically and strongly typed language, whereas JavaScript is a dynamically and weakly typed language. Since Crockford is supposedly a programming language expert, shouldn't he know this???

  7. Crockford crows about JavaScript's lambda, hailing it as the best thing ever to make it into a programming language. But nearly all the major programming languages in use today have lambdas! Java 8. C# 3.0. Python. C++ 11. Ruby. PHP 5.3. Perl 6. Scala. Lambda does not make JavaScript stand out at all as a programming language. I'm just saying.

    Crockford says that you can program prototypal inheritance as though it was classical, but you can't do the opposite, ie, program classical as though it was prototypal. This is absolutely wrong. You can easily simulate prototypal inheritance, for example, in Smalltalk, which is the purest of class-based OOP languages. You can even do it in Java. You can also do it in C# with the DynamicObject class. There is nothing magical about object prototypes, which are basically glorified hash tables. JavaScript simply makes them slightly more convenient.

    Prototypal inheritance is so useful and so desirable that no other programming language introduced in the past 20 years have adopted it, at least, none that are noteworthy. When Microsoft created TypeScript, they eschewed prototypal in favour of classical. In ES6, ECMA caved in to pressure to add class-based OOP features. It would seem that nobody really wants prototypal inheritance.

  8. Crockford says that Scheme has "loose typing." This is incorrect. Scheme is a dynamically-typed language. It is also a strongly-typed language. JavaScript is dynamically-typed, but it's also weakly-typed. This is what I would describe as "loose typing" and this is one of the main things that cause a lot of problems with the language: https://medium.com/javascript-non-grata/javascript-is-a-dysfunctional-programming-language-a1f4866e186f.

    Dynamic typing is actually quite nice and powerful. Languages like Scheme and Smalltalk are great for this reason. But JavaScript's loose typing and freewheeling coercions introduce many semantical inconsistencies, which are the source of so many WATs and WTFs that make JavaScript the butt of many jokes.

  9. JavaScript is not misunderstood. We understand it very well: https://medium.com/javascript-non-grata/samson-and-javascript-3ff39a4f836d

    The Good Parts don't make up for how dangerous it is to use this language, esp. for software engineering at scale: https://medium.com/javascript-non-grata/javascript-s-sword-of-damocles-47256cf17b5a

    What does JavaScript "get right?" What makes it so "expressive?" Functional programming capability? This is not unique to JavaScript, and many other FP languages do it better.

    Object prototypes are the building blocks for class-based OOP. They are a low-level facility. As such, they make it much more difficult to refactor your code. For example, how can you examine the object relationships in your code, the inheritance hierarchy? You'd have to follow every line of source in every function looking for instances of object instantiation, whether done through object literals, constructors, delegation, or concatenation. This is awkward beyond imagination.

    With class-based OOP, you simply look at the class definitions, typically via a "class browser" in your IDE (eg, Visual Studio, IntelliJ, Smalltalk) which is able to easily extract the inheritance hierarchy from the code.

    This difference from classical inheritance is what makes JavaScript impossible to scale in size, making your code much harder to maintain. It makes it much harder to understand your codebase. In the end, this is what compromises your application's reliability.

  10. The beginning was great. One of the largest languages where people don't try to understand before using it. That's hilarious, and I definitely fell into that category. Great video Mr. Crockford.

  11. From my experience inheritance(prootypal inheritance) should never be used in your development cycle. When you are extending one object from another, you are making the worst form of coupling you can have. It is much better way to use composition instead IMHO.

  14. Huh? Perl5 RegEx is awesome, and I wish the JS regex syntax was even more similar to Perl's, as JS just has a stripped version of the powerful Perl syntax. JavaScript doesn't even have the x flag by default.

    Compare:
    for(@array){ s/word1/word2/g }
    vs.
    for (var i=0;i<array.length;i++) { array[i] = array[i].replace(/word1/g, "word2");

    Perl is your tool for quick text hacking on the command line.

  15. Just to ask a quick question to anyone who may know. Does the prototype chain compile the function to memory and leave it in memory until the window closes?

  17. I'll make a car with square wheels.. that will be the most misunderstood car in the world.. You just need to learn to drive it.

    Learn anything extensively, and you can work with it.. but that doesn't give you satisfaction, That's why JS community hate it.

    JavaScript is widespread is because it's packed with browser and there is no alternative, decision is more political.. JS can any be replaced easily.. just needs right amount of efforts and push by IT giants.

  19. Doesn't Google have any female developers? There isn't a single woman in the audience! I mean, yes, working in software development and computer science for more than a decade, I kind of realized that there are way more men than women in the field, but seriously … none?

  24. Any language that mandates K&R brace style for `return` is fundamentally *broken by design*.

    Programmers chose their indentation style for their readability not some dumb-ass parser written by an idiot forcing their "One True Way" upon everyone else who has zero respect for the variety of how programmers format their code.

    I've tried out all the various indent styles to see both their strengths and weaknesses.  It is far more important to be consistent then being forced to waste time being a language lawyer reading inconsistent parsing rules in "Section 7.9 Automatic Semicolon Insertion"

    * One, consistent, rule = simple.
    * Multiple, inconsistent exceptions = confusion.

    https://en.wikipedia.org/wiki/Indent_style

Leave a Reply