You can just look up some dictionary definitions, like "not influenced by personal feelings or opinions in considering and representing facts." I've explained how that applies in this case - we can use comparative analysis to draw factual conclusions.

Focusing on the specific word "terrible" is a bit silly. Sure, it's hyperbolic, but I used it as a way to capture the idea that Javascript has many features that are comparatively worse at achieving their goals than equivalent features in many other languages. This is something that can be analyzed and measured, producing facts.

Crockford's book title is simply an example of how even a strong advocate of Javascript recognizes its weaknesses. You may not understand how it's possible for it to objectively have weaknesses, but that doesn't mean it doesn't. In this case an objectively bad feature would be one that has negative consequences for programmers, and can be replaced by a features that can achieve the same goals more effectively, without those negative consequences.

If there's anyone who'll argue in favor of such features on technical rather than historical grounds, then it would certainly undermine the objectivity claim. But the point is that there are (mis)features in Javascript which no-one defends on technical grounds. That is a reflection of underlying objective facts.

I'm also not making some sort of ad populum argument. As I pointed out, any claim of objective fact has to be made in some context that provides it with semantics. In some languages, the expression "1"+"1" is a type error, in others it produces "11". Both of those outcomes are objective facts in some context. What your objection really amounts to is saying that there's no semantic context in which my claim could be true. That's clearly not the case.

Perhaps a different example would help: people don't write programs any more by toggling binary codes into machines via switches. That's because we've come up with approaches that are objectively more effective. We can factually measure the improvements in question. The features I was referring to fall into the same category.

I'm going to repeat the closing from my last comment, because you're still doing the same thing:

You can of course quibble with such claims, based on a rigid application of a simplistic set of definitions. But you'd do better to try to understand the truth conveyed by the claims, and engage with that.

I occasionally write JavaScript since 2007, experiment a lot last 5 years, red through ES5 specification several times. I've worked as C++, PHP, Python, Ruby developer. Experimented with a few languages.

"JS" instead of "TypeScript" brings confusion. TS solves some issues and I've mentioned it, still

    typeof null
    //"object"

Template literals interpolation helps but if string (not literal string) slips by it is a mess

    1 - "2"
    //-1
    1 + "2"
    //"12"

Check out another comment [1], Object, Function, etc defined as constructor. It is not solved by "class", it is still a function with a bit of sugar:

    class Foo {}
    Foo instanceof Function
    //true

Globals with a few exceptions defined as constructors, DOM elements defined as constructors, inheritance defined as constructors

    class Bar extends Foo {}

You can internalize how it works and there are some good explanations [2] but design is error prone and terrible.

[1] https://news.ycombinator.com/item?id=24815922

[2] https://yehudakatz.com/2011/08/12/understanding-prototypes-i...

> Virtually no one writes plain JavaScript

Which is because plain Javascript is objectively terrible, as I pointed out.

I have no grudge against operator overloading when done consciously — complex numbers, matrix multiplication. I've tried to implement JavaScript arithmetic in Ruby, failed so far.

Sorry, I had to be clear, in Lua "one number type" means float, my bad. I meant Lua 5.3 integer still works like JavaScript Number. In the end we have to know about ToInteger, ToInt32, ToUint32, Number.MAX_SAFE_INTEGER [1]. It is not one number type but encoding of several number types, union.

Prior to 5.3 and in LuaJIT it has different limitations

    > print(string.format("%18.0f",9007199254740991 + 1))
      9007199254740992
    > print(string.format("%18.0f",9007199254740991 + 2))
      9007199254740992

they have extended original "one number type" without change of the interface. In any case both versions do not convert to BigNum like Ruby.

    0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
    => 115792089237316195423570985008687907853269984665640564039457584007913129639935

Ruby unified Fixnum, Integer and BigNum as Integer in 2.4. Can't see benefits of Number/BigInt against Float/Integer. I'd rather have 3.6f literal.

Yes, I know how WAT works. I meant ToPrimitive [2]

    [] * {}
    //NaN

I've disabled this code in Firefox, have not done extensive testing but looks like no one depends on it. We infer types with TypeScript and flow but VM already knows it, it can report such cases without external tools. I think of it as extension of Firefox Developer edition — lint in the browser.

Object.prototype.toString is not as useful as Ruby, Python

    class Foo {}
    `${new Foo}`
    //"[object Object]"

    class Foo end
    Foo.new
    #=> #<Foo:0x0000560b7a10df20>

    >>> class Foo:
    ...     pass
    >>> Foo()
    <__main__.Foo object at 0x7fb53aecf1f0>

And there is no separate inspect/__repr__

    Date.today
    #=> #<Date: 2020-10-20 ((2459143j,0s,0n),+0s,2299161j)>
    Date.today.to_s
    #=> "2020-10-20"

> UCS-2 actually

Oh, DOM UTF-16 string broken by UCS-2 JavaScript function. I understand it is not easy to fix, Ruby fixed in 1.9, Python in 3.0, new languages (Rust, Elixir) come with UTF-8. Microsoft Windows has code pages, UCS-2, UTF-16.

Maybe Python way? b"binary", u"utf-8" (but together, not python fiasco), ruby has "# Encoding: utf-8", transformation tools can mark "b" or "u" all unspecified strings.

> Once again though, the deep parts of both Python and Ruby classes are probably more difficult to explain.

No, every Ruby object contains variables and has a link to a class which defines instance methods, we call it singleton_class

    foo = Object.new
    foo.class == Object
    #=> true
    foo.singleton_class == Object
    #=> false

    def foo.bar
    end
    foo.singleton_class.instance_method(:bar)
    #=> #<UnboundMethod: #<Class:#<Object:0x000055cb33808e10>>#bar() (irb):7>

There is ancestors chain

    Object.ancestors
    #=> [Object, Kernel, BasicObject]

There is a bit of syntactic sugar

    Foo = Class.new

There are few revelations with main (method defined in Object)

    def baz
    end
    Object.instance_method(:baz)
    => #<UnboundMethod: Object#baz() (irb):19>

Nothing like audible "click" I had when understood that "function" is a "constructor"

    constructor Foo {}
    // you can call me as function too

that unlike any other language [[Prototype]] is hidden. I've red through ES5 to be sure there are no hidden traps left.

Every JavaScript programmer has to go through this list either beforehand or by experience. I do not want to undermine TC39 effort — arrow functions, string interpolation in template literals, strict BigInt, Object.create — these are great advancement. I don't feel same way for "class", underlying weirdness is still there.

Make [[Prototype]] visible

    Object = Object.prototype
    Function = Function.prototype

now it is easy to reason about

    typeof Object 
    //"object"

    Foo = class {}.prototype         // redefine with sweetjs macro
    Bar = class extends Foo.constructor {}.prototype

    new Foo.constructor              // redefine with sweetjs macro

    Object.constructor.create(Bar)   // redefine as Reflect.create

once redefined:

    Foo = class {}
    Bar = class extends Foo {}
    new Foo
    Reflect.create(Bar)

I've shown it in another comment [3].

Languages are weird, there are a lot of C++ developers, I've been there, no way to know all dark corners. Pythons ideology hurts. Java took EE way. C# was tied to Microsoft. C K&R is beautiful, hard to write safe, packs a lot in the code. PHP has its bag of problems. SQL is not composable, CTE helps. Go ideology. Ruby — performance. And JavaScript because browser, not bad when know and avoid skeletons in the shelf.

Lua metatables looked like a proxy/method_missing for me.

[1] https://www.ecma-international.org/ecma-262/5.1/#sec-9.5

[2] https://www.ecma-international.org/ecma-262/5.1/#sec-9.1

[3] https://news.ycombinator.com/item?id=24815922