That book is of an era and hasn't been particularly relevant in quite awhile. The rise of classes as prototype sugar made a lot of the navel-gazing of object creation mostly moot. The rise of rigorous linting took care of the rest.
I would rather work in a language/style that draws its inspiration from Scheme than Simula 67.
Then you should push for WebAssembly improvements so you can use whatever language you want. As long as JavaScript is a de facto requirement for web development it needs to be as approachable as possible to a wide developer audience, and that means looking more like Java than Lisp.
Or we could've considered it an opportunity to move people away from classical inheritance and towards something that's conceptually much simpler? (which both prototypal inheritance and functional programming are)
JS is and always was prototype based. The class keyword is as far as I know just syntax sugar that creates a prototype chain and a new-able function that assigns the prototype to self.
Classes are fine! Inheritance isn't. You can mostly avoid using it, though.
JS lacks homoiconicity and thus can't have a lot of nice things a Lisp dialect would, notably macros.
With what we've got, I have more hope on JS eventually migrating towards a (more) statically typed language with ML influence; typescript sort of leans towards it, slowly.
You're right about Lisp features, but CLJS macros are kind of bad at the moment. I have a fairly simple macro that works just fine in Clojure but does not compile in ClojureScript and I can't figure out why. It's probably a side-effect of how macros are handled in CLJS (they're part of a different compilation stage and must be written in CLJ or CLJC, hence :require-macros instead of just :require).
If you're looking for an ML, check out ReasonML. It's really quite good, its output is quite good (and hotfix friendly), and its type system is far better than TypeScript's will ever be. Mostly because TS wants to stay close to JS. Too close, in my opinion.
You can consider it a bad thing, but 1) it's a really thin layer on top of prototypical inheritance, 2) it makes JavaScript more accessible to people who are used to conventional styles of language, and 3) it won, indisputably.
ClojureScript didn't win, and never had a chance to win, because it's written for the small minority of Clojure people. It wasn't written for the overwhelming majority of developers. TypeScript was. So sorry that the existence of those day-to-day programmers puts a crimp in your utopia, but, enh. Personally, I'm glad we have tools to make it easier to write libraries to help that majority be more productive and to make their code safer and more correct!
It really is a shame because ClojureScript is an absolute joy to work with. TypeScript and Javascript feel so incredibly tedious to write after using CLJS for a few months.
I would really love to move into PureScript as well, but I haven't quite wrapped my arms around Haskell as a whole, yet. So maybe I should tip my toes back into Elm for a bit.
> This specification, the 10th edition, introduces a few new built-in functions: flat and flatMap on Array.prototype for flattening arrays, Object.fromEntries for directly turning the return value of Object.entries into a new Object, and trimStart and trimEnd on String.prototype as better-named alternatives to the widely implemented but non-standard String.prototype.trimLeft and trimRight built-ins. In addition, this specification includes a few minor updates to syntax and semantics. Updated syntax includes optional catch binding parameters and allowing U+2028 (LINE SEPARATOR) and U+2029 (PARAGRAPH SEPARATOR) in string literals to align with JSON. Other updates include requiring that Array.prototype.sort be a stable sort, requiring that JSON.stringify return well-formed UTF-8 regardless of input, and clarifying Function.prototype.toString by requiring that it either return the corresponding original source text or a standard placeholder.
Optional chaining is moving through committee along with the "nullish coalescing operator" represented as `??`, which works like `||` except only falls through with `null` and `undefined`.
This is a very minor frustration, and I'm screaming into the abyss, but when searching for JavaScript topics, blogposts from LogRocket pretty often come up top of the search rankings, above more authoritative sources. Often under slightly misleading titles (such as this one) that seem chosen to capitalise on common search terms, or else the articles are packed with keywords. Sometimes mildly useful but mostly they're shallow and not particularly contentful, and LogRocket seem to absolutely churn them out. Seems to have gone down slightly since moving from Medium to Hosted WP, but not much. Nothing doing, it's just SEO and getting the name "LogRocket" in front of more eyeballs, but just...urrgh
51 comments
[ 3.6 ms ] story [ 123 ms ] thread[1] https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfo...
TypeScript helped a lot, too.
I would rather work in a language/style that draws its inspiration from Scheme than Simula 67.
Too bad more places are picking up TypeScript rather than ClosureScript.
Then you should push for WebAssembly improvements so you can use whatever language you want. As long as JavaScript is a de facto requirement for web development it needs to be as approachable as possible to a wide developer audience, and that means looking more like Java than Lisp.
No.
(No (No (No (No (No)))))
JS lacks homoiconicity and thus can't have a lot of nice things a Lisp dialect would, notably macros.
With what we've got, I have more hope on JS eventually migrating towards a (more) statically typed language with ML influence; typescript sort of leans towards it, slowly.
If you're looking for an ML, check out ReasonML. It's really quite good, its output is quite good (and hotfix friendly), and its type system is far better than TypeScript's will ever be. Mostly because TS wants to stay close to JS. Too close, in my opinion.
ClojureScript didn't win, and never had a chance to win, because it's written for the small minority of Clojure people. It wasn't written for the overwhelming majority of developers. TypeScript was. So sorry that the existence of those day-to-day programmers puts a crimp in your utopia, but, enh. Personally, I'm glad we have tools to make it easier to write libraries to help that majority be more productive and to make their code safer and more correct!
I would really love to move into PureScript as well, but I haven't quite wrapped my arms around Haskell as a whole, yet. So maybe I should tip my toes back into Elm for a bit.
I mean, I don't like using it in Java either, but it isn't really optional there...
If you want to know what's new in ES2019, look no further than the [Introduction](https://www.ecma-international.org/ecma-262/10.0/index.html#...) section in the spec.
> This specification, the 10th edition, introduces a few new built-in functions: flat and flatMap on Array.prototype for flattening arrays, Object.fromEntries for directly turning the return value of Object.entries into a new Object, and trimStart and trimEnd on String.prototype as better-named alternatives to the widely implemented but non-standard String.prototype.trimLeft and trimRight built-ins. In addition, this specification includes a few minor updates to syntax and semantics. Updated syntax includes optional catch binding parameters and allowing U+2028 (LINE SEPARATOR) and U+2029 (PARAGRAPH SEPARATOR) in string literals to align with JSON. Other updates include requiring that Array.prototype.sort be a stable sort, requiring that JSON.stringify return well-formed UTF-8 regardless of input, and clarifying Function.prototype.toString by requiring that it either return the corresponding original source text or a standard placeholder.
[1] https://www.ecma-international.org/ecma-262/10.0/index.html
As a current elixir dev, VERY excited about the pipe operator.
Pipeline operator has lots of quirks and syntax bikeshedding. I don’t think it may land.
Especially when you can make your own pipe(x,y,z) function quite easily. Just a guess though.
"The trimStart() method removes whitespace from the beginning of a string. trimLeft() is an alias of this method."
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I suspect that trimLeft was misnamed, since its "left" didn't take into account RTL - it just meant start of string.
One thing I miss from Objective-C that I wish JS would add is the `?:` operator – basically a shortened version of the ternary operator.
?? Short circuits on nullish. Only null and undefined.
This is already there: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
x || y
For example in PHP, it works exactly like you describe.
You can write x ?? y
Which is x !== null and x != undefined ? x : y
To get the first user from a server response would be significantly longer if you wrote three nested ternary operators.
TL;DR - most of what is added in 2019 I can already do with Ramda.js, and it works in IE11, as well.
Pity about the Ruby / Groovy style dot-condition-chaining NOT being in the 2019 features, though.
no thanks, I don't think it's an interesting feature, there are alternatives (chaining, promises, ..) to avoid the cost of this new syntax
Other proposals I'm more excited about:
- https://github.com/tc39/proposal-iterator-helpers
- https://github.com/tc39/proposal-slice-notation/ (and https://github.com/tc39/proposal-slice-notation/pull/32)