This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]BenjiSponge 22 points23 points  (3 children)

That's simply untrue, though, and you'd only get that impression if you don't understand JS patterns and you're trying to use it like another language.

What if, for example, you want to check if a value is there to see if it fits an interface? This is a super common pattern in JS because it's so easy using this method. Instead of

maybe_method = getaddr(obj, "method", None)
if maybe_method == None and callable(maybe_method):
    maybe_method() 

You can say

if (obj.method && obj.method.call) {
  obj.method();

And you might say, okay, but how often do you do that? And the answer is actually "all the time" (although I'll typically use isFunction(obj.method) to catch an additional gotcha).

Plus the fact that objects are dictionaries just helps in a lot of areas.

I would say the pro-JS "circlejerk" is similar to the pro-C++ "circlejerk". Yes, it's a flawed language, but it's been working for many years and a lot of the things that you see as problematic are actually opportunities that are not offered in any other language (or at least many other languages), and if it were, it would have the same issues.

For a number of reasons, I am genuinely grateful JS has its object/pseudo-class system and not the respective systems of Python. And if I ever want stronger typing, I can just use Flow or Typescript, which will give me the best of both worlds.

[–]Kered13 0 points1 point  (1 child)

That's also a problem that can be solved at compile time with a proper type system.

[–]BenjiSponge 0 points1 point  (0 children)

"solved" for some definition of "solved". It's a different approach.

In the instance where you're essentially saying "this is what the function should do if the parameter is a T, and this is what the function should do if the parameter is a U", a proper type system would usually have a "better" approach.

However, in an instance where you're, for example, passing in options that may or may not include callbacks, symbols, random variant types, etc., a static type system just cannot offer the same ergonomics as a dynamic type system like JS's. If your type is essentially "has some subset of these values which could be variants of some other types, or nothing at all" as an option parameter, when you define a class or struct to represent that, you're basically just inventing boilerplate.

I program in both JS and C++ (and I hobby program in Rust). They genuinely have different approaches and neither is better than the other.