Right, I assumed the real point the quiz was making is that Python is as full of footguns as JavaScript, since I've seen this type of thing for JS a bunch of times.

Not saying I agree, but was definitely expecting that to be the main topic of discussion here...

More specific shenanigans aside, JavaScript will always be the king of unintuitive syntax. Some of these f-string tidbits are very much strange, but you'd have to be implementing something specific to encounter them. Meanwhile over in JS you're still waiting for your dependencies to install so you can compare two arrays.

That is exactly the kind of unfounded, strawman-riddled criticism I was after ;-)

What does an algorithmic task such as array comparison have to do with language syntax? The answer is nothing.

Sure, some languages might have builtins for comparing certain things, or doing intersections/differences, but those only apply to arrays of primitives, and even in those cases the utility of the builtins completely depends on the use case, and those builtins still have nothing to do with syntax.

> those only apply to arrays of primitives

I guess you've not written much python, or just not used any custom types in lists if you have.

    class Thing:
        def __init__(self, a, b):
            self.a = a; self.b = b
        def __eq__(me, them):
            return me.a == them.a and me.b == them.b
    >>>[1, 2, Thing(6, "Hi")] == [1, 2, Thing(6, "Hi")]
    True
    >>>[1, 2, Thing(6, "Hi")] == [1, 2, Thing(6, "Hello")]
    False

In this case, the builtins are syntax, namely the `==` operator. There's a uniform syntax for comparing two objects for equality.

Sure, the language has a mechanism for overriding the equality operator for classes, just like Java has .equals(), but the code is overriding the builtin algorithm. The case of comparing mixed type arrays is not a usual case and seems contrived. In JS, you could do the same by extending Array and using that, or implementing a custom .equals() for your objects. I suppose Python is a bit more functional in that respect.

On the subject of javascript template literals.

Do they really not support the equivalent to

    let template = 'hello ${name}';
    let n1 = template.format({ 'name':'joe' });
    let n2 = template.format({ 'name':'bob' });
    

I am not really a javascript programmer. but I was writing some and wanted to store a bunch of templates then fill them out dynamically and was unable to figure out how to do it with the native javascript template system. So I ended up having to write my own. As it appears to be a huge obvious hole in missing functionality, I have to ask. Am I holding it wrong?

While writing this up I was rereading the mdn page on template literals, perhaps tagged templates would do what I wanted, I don't remember why I did not use them(I think it is still not possible to store the template), but on first glance, yeah, lamentations about the unintuitive syntax and weird features.

Tagged templates probably won’t help, or will be quite messy. But you can just use a thunk with some parameter destructuring:

    const tpl = ({ name }) => 
      `hello ${name}`;
    const n1 = tpl({ name: "joe" });
    const n2 = tpl({ name: "bob" });

Or if you don’t like the duplication of property names, you could do it without destructuring:

    const tpl = (o) => 
      `hello ${o.name}`;

Look for the free online book ”You don’t know JS”, it is good reading.

I think what you want is to just make a function and pass it the values:

  const template = ({name}) => `hello ${name}`;
  const n1 = template({ name: 'joe' });

(Tagged templates won’t help here because the bit in curly braces is an expression which is evaluated to a value first; you’d need some kind of macro system to get access to the original variable name at runtime.)

But if it were Perl, they'd be celebrating.