J-expressions make Javascript the acceptable Lisp

The consistent implementation of key enumeration order of objects in Javascript engines allows us to write specifications of composeable computations using generic JSON-serializable notation that we can call “J-expressions”.

{opname: main_parameter,
keyword1: value1,
keyword2: value2,
...}

J-expressions, in combination with functions that implement what the operation named opname is supposed to do, are then a systematic way to approach DSL construction within Javascript. The notation is as expressive as s-expressions.

>>24
Classes were unnecessary, but I can understand why they added them. The language has gotten criticized for decades for not making OOP easy enough for retards. The masses want classes. The one place where do is calling a superclass method: now you can write super.whatever() rather than pig disgusting SuperClassConstructor.prototype.whatever().

IMO they've already gone too far. Readability is starting to suffer. Some jackass posted a thread on Reddit showing a bunch of truly perverted uses of destructuring applied to objects, which now I'll have to read and understand when they appear in other people's code.

Generators, function*, and yield had some uses, but added a bunch of complexity to the language, and were limited and shitty and didn't really fix the async problem, so now they're adding more complexity (async/await) to deal with that.

Not only must the programmer evaluate whether each of these features is worth using but (this being JS) you need to consider what environments they'll actually work in, and until every feature is universally supported, rely on fifty zillion polyfill plugins for a code generation framework that complicates your build process.

Meanwhile, no old features can ever be removed because ancient web pages would be broken.

It's a fuckin mess and if the committee isn't careful they'll have another C++ on their hands.