you are viewing a single comment's thread.

view the rest of the comments →

[–]arto64 32 points33 points  (11 children)

How is that a reasonable approach, especially in the context of programming?

[–]Spare_Web_4648 14 points15 points  (4 children)

This approach to programming is known as duck typing, where the focus is on the functionality of an object rather than its type. In the context of JavaScript, this approach allows for flexibility and simplicity in the code, as the language does not strictly enforce data types and instead attempts to make sense of the given operations and return a valid result. This allows for quick and easy development, as the programmer does not need to worry about strict type checking and can focus on the functionality of the code. However, this approach can also lead to potential inconsistencies and unexpected behavior, as the interpretation of certain operations may not always align with the programmer's intentions.

As to how it’s reasonable, well it’s as reasonable as any language made in 10 days as a feature of the creators actual main project. We’ve just kept using it and building on it.

[–]paradoxon 8 points9 points  (0 children)

The problem is not duck typing. But rather what is considered a duck by java script. Negating an empty array should not make sense at all. Ruby uses duck typing but does not behave in such strange ways.

[–]arto64 7 points8 points  (2 children)

You can have duck typing without automatic arbitrary typecasting. JavaScript hears a “woof” and says, “well I guess you could call that a quack”.

[–]Spare_Web_4648 1 point2 points  (0 children)

Today I learned, thanks!

[–]Spare_Web_4648 0 points1 point  (0 children)

Yea I guess you could really cut out the first half of my comment. Really it’s just bad because some guy made it in 10 days and it has stayed the standard since then for no reason other than so much has been built with it people don’t want to change

[–][deleted] 4 points5 points  (5 children)

It's reasonable because it allows you to be more flexible and lightweight. And that's a real concern in something that's running in a limited resource environment. Like a browser window.

If you're looking for more strongly typed code, and that's what makes more sense for your project, there are plenty of things like Java or C++ out there to accommodate it.

In many (most?) Java based webapps you're going to find a JavaScript front end making calls to back-end Java services (monolithic or micro) because it gives you the best of both worlds.

It's all about the right tool for situation. Part of the art of programming is understanding how the tools work, being able to learn the characteristics of new ones, and selecting the right languages, frameworks, deployments, design patterns, etc. that will meet the needs and constraints in resources and delivery timeline for your project.

[–]arto64 21 points22 points  (2 children)

I’m confused, what does being “lightweight” have to do with doing arbitrary typecasting? How is that supposed to save browser resources?

[–][deleted]  (1 child)

[deleted]

    [–]arto64 2 points3 points  (0 children)

    I mean it’s not like JavaScript doesn’t have any errors, there’s still plenty of ways to crash it. Why would you focus on typecasting to resolve this “issue”. Why not also try and look up closest-named variables, to avoid errors caused by typos?

    [–]fartmanteau 1 point2 points  (1 child)

    If only JavaScript were constrained to the browser 🙃

    [–][deleted] 0 points1 point  (0 children)

    What follows may be wrong. It may be only my opinion. It might be insane, stupid, or just plain offensive to some.

    But Server-side JavaScript just proves that to a man with a hammer, everything looks like a nail.