> JS is the only language I know where half of it is recommended to not be used.

Jamie Zawinski (who else) about C++ in 'Coders At Work': When you’re programming C++ no one can ever agree on which ten percent of the language is safe to use.

> And how do you get the "next 3 elements after the 2nd" ?

.splice(2, 3) (am I missing something?)

> > The rest can be implemented in user-land: var md5 = require("md5") And then you get the current 3Mo pages we all hate. Are you even serious with your arguments or is it trolling ?

md5 node lib is 32kb unbundled. If you meant 3Mb pages that's ridiculous. Modular necessity at the hands of the user is good, and it's something that's been present in every project i've worked on in a less granular fashion than modern npm-driven apps can deliver.

OP was talking about trading [] for {}. You can't splice on {}.

well, objects are not iterables... ??? unless you decide you want them to be, in which case you can make them such and design them in a way that they work as such?

The least elegant way is Object.keys().map(key => etc) which is really not that hard to work with

edit: it's a phony premise to begin with actually. Iterables have order, objects have mapping. I am less experienced with other languages so I probably don't understand OP's statement clearly. I just think OP's context is lazy thought rot about what's becoming a fairly elegant language. BUT I'm a noob.

> Besides, JS is the only language I know where half of it is recommended to not be used.

That's what you get for having backward compatibility I guess. If the standards committee would break my old code I would probably quit and start a sect. I would call it "ReactReduxReduce" (RRR).

> The point is my students will forget the semicolon in some code that is not properly checked, and it will work. Most of the time. Until it doesn't.

Some people prefer writing JavaScript without semicolons. How do they not have bugs all over the place ? :P

> Some people prefer writing JavaScript without semicolons. How do they not have bugs all over the place ?

The same way that people who write with semicolons avoid lots of bugs: linters and transpilers and tests.

That said there is only one rule to remember when not writing semicolons, the easy to remember "winky frown" rule: all frowns must wink if they start a line/statement. ;( ;[ ;`

;(The last two are quite rare in my experience.)

It's not that tough of a rule to remember.

Our projects' linting rules specify no semicolons, except when necessary; this means that we will _very rarely_ write something like this when we want to iterate over a small literal array:

    ;['foo', 'bar'].forEach(function (f) {
      it(`has an ${f} field`, function () {
        expect(......)
      })
    }

That said, we tend to use that construct extremely rarely, such as in a few test cases where we are doing the same kinds of things on two groups of items that need different descriptions.

Most of my usages are Typescript type assertions:

    ;(thing as Type).methodINeed()

If it weren't for these I mostly wouldn't need semicolons at all, sometimes I refactor to:

    const thingType = thing as Type
    thingType.methodINeed()

> How do they not have bugs all over the place ? :P

Who says they don't?

They don't.

Ughhhh... what?

"C++"

C++ also gets a lot of hate for half of it being forbidden to use.

"If we threw languages because they allow for errors, we'd have no language left."

Correction: we'd have Ada, some of those "prove your program is formally correct" metalanguages, and possibly Rust. Probably some others with which I'm not familiar.

>Correction: we'd have Ada

Ada allows for errors just as well.

http://www-users.math.umn.edu/~arnold/disasters/ariane5rep.h...

It's a cargo cult/myth that was circulating from back when I was in university that Ada is some super fault tolerant language because they use it for rockets and stuff and because they designed it to be super secure.

It was indeed designed to be more secure than C and to be an official government/military use language, but no "super secure" and allows for errors just fine.

Besides, they do rockets in C just as well (with certain rules).

"Ada allows for errors just as well."

    Although the source of the Operand Error has been 
    identified, this in itself did not cause the mission to 
    fail. The specification of the exception-handling 
    mechanism also contributed to the failure. In the event 
    of any kind of exception, the system specification 
    stated that: the failure should be indicated on the 
    databus, the failure context should be stored in an 
    EEPROM memory (which was recovered and read out for 
    Ariane 501), and finally, the SRI processor should be 
    shut down.

In any case, I'd argue that converting a 64-bit float into a 16-bit integer is a much different class of problem from mixing up assignment and comparison operators. But yes, you're right, even Ada is not perfect.

"Besides, they do rockets in C just as well (with certain rules)."

Yes, they do. Those "certain rules" are codified in the MISRA C standard (or derivatives thereof, like with the JPL and JSF coding standards). Said standard is way more strict than the sort of thing normally implied by "C programming".

>In any case, I'd argue that converting a 64-bit float into a 16-bit integer is a much different class of problem from mixing up assignment and comparison operators.

Is it though? Because in the end it's the same issue of conversion between types (coercion vs casting, but still).

A linter solves 100% of the "issues" you describe related to ASI and type coercion. Every single major editor or IDE has support.

> [] + {} '[object Object]' > {} + [] 0

The first case deals with an array, an object, and a concat operator. The second case deals with an empty code block, an array, and a unary math operator. None of that has anything to do with commutative properties because neither unary operators nor string concatenation are commutative in ANY language.

> Come on, you never used Java, Perl, Ruby, Python? Any language with decent string formatting ? That doesn't need a leftpad dependancy ? That can format date without importing 34ko of moment.js ?

The standard date object sucks, but that's no huge wonder because they were required to make it behave like Java (it even has an old Java Y2K API bug where it returns only the last two year digits).

We used to have horrible proceedural, class-based math libraries. Next we moved to underscore. That was replaced with a much faster lazy libraries. The current trend is toward even faster transducer-based solutions with more functional options as well. Which would be the correct language standard?

Having been bitten by bad APIs in the past, there's been reluctance to move too quickly in adding extra APIs to the core language. I think the current solution of adding good primitives and leaving the rest to good libraries is an ideal solution (after all, JS can add things, but old mistakes are forever).

> And then you get the current 3Mo pages we all hate.

We had a multi-MB page. Tree shaking got rid of most of it. Moving the biggest libraries to shared CDN versions that lots of sites use gets rid of a lot of load time as well. Using webpack to chunk your site also reduces the payload to a manageable size.

> A mapping is not a list. It doesn't perform the same. You can't push and unshift. You can map on it without Object.stuff. Length is a costly operation. Concat without spread is a pain. And how do you get the "next 3 elements after the 2nd" ?

A sparse list uses a map (in fact, Array is defined as a special case of a standard Object -- JITs simply optimize to more efficient data structures when your data allows). Further, if you start deleting in the middle of a list, it will not be optimized past a linked-list anyway (in ANY language).

If I were needing to do a bunch of item removal, I'd use this.

    var removeNth=(x,s)=>x.splice(s,1); //a bit faster
    var removeNth=(x,s,e=s+1)=>x.splice(s,e-s); //a bit more flexible
    Array.prototype.removeNth=function(s,e=s+1){this.splice(s,e-s)} //a bad idea, but possible