8 ms·

The problem with type coercion is when it happens without you noticing it. You cannot "avoid" it...

BinaryIdiot 10y ago
Sure but this problem is inherent to any dynamic language. I find other issues far worse than simple type coercion. What about calling a function? Most dynamic languages will let you pass in any number of parameters regardless of its definition and you may not even notice. You can avoid type coercion if you understand how the language works (aka strict equality in JavaScript) but this isn't something only in JavaScript land either.
- dozzie 10y ago
  > Most dynamic languages will let you pass in any number of parameters regardless of its definition and you may not even notice. Python will throw an error. Ruby will throw an error. Tcl will throw an error. Erlang will throw an error. I believe most of the Lisps will throw an error. What was it about "most dynamic languages"?
  - BinaryIdiot 10y ago
    > What was it about "most dynamic languages"? I should have changed my text to not say "regardless of definition" because you can do that in Python, Ruby, PHP, JavaScript, etc. Python and Ruby support it through (star)args or default parameters JavaScript supports it regardless PHP supports it regardless We can argue semantics or the fact that some of those types of errors can be caught with some subset of dynamic languages but I don't think that's useful. My only point was when comparing a dynamic language with a static language I find variable function parameters to be one of the bigger issues over type coercion. But that's just, like, my opinion.
    - deleted 10y ago
      [deleted]
    - kbp 10y ago
      Those aren't particular to dynamic languages, though. You can add C, C++, Java, and C# to your list of languages that support it. Being able to explicitly make a parameter optional, or to have a 0-or-more rest argument is different from how function application works in Javascript or Perl because you have explicitly made that part of your function's signature, and the language still checks calls against that signature.
- mazelife 10y ago
  There are two separate issues in play here. You're conflating the static/dynamic dimension of language classification with the strongly-/loosely-typed dimension of languages which is what the poster you are responding to was talking about [1]. These two dimensions are orthogonal: languages may be static, but weakly typed (like C), or dynamic but strongly typed (like Python). I'll allow that there's inevitably some degree of opinion involved here, but I tend to agree with the parent poster that implicit conversion in languages like Javascript, PHP, and Perl is just another vector for bugs, and outweighs any of the advantages you get from having your language coerce everything for you. But then again, i'm one of those people that likes my language to force me to be very explicit about what I mean, so YMMV. Regardless, the strict equality operator is not at all sufficient to avoid the dangers of JavaScript's implicit conversions. Pretty much _all_ the operators are going to coerce types for you, whether you meant for them to or not. For example, this function: function increment(i) { return i + 1; } Adds one to number right? But let’s say you’ve neglected to convert some user input in a form to a number as you should have done elsewhere in your code, and you end up calling increment("1"). This will return "11". So now you potentially have introduced a serious math error into your code you may not notice right away. Conversely, if you did this in Python, the function would have raised a TypeError immediately, because you can’t apply the arithmetic operator to two different types. You can’t just “avoid” type coercion in these loosely-typed languages by understanding the specifics of how it works, because you may not even know it’s happening until you start seeing unexpected results somewhere. [1] https://en.m.wikipedia.org/wiki/Strong_and_weak_typing https://en.m.wikipedia.org/wiki/Strong_and_weak_typing
- lispm 10y ago
  Most Lisp compilers will warn about wrong number of parameters at compile-time. Lisp typically warns at runtime, too.

Sure but this problem is inherent to any dynamic language. I find other issues far worse than simple type coercion. What about calling a function? Most dynamic languages will let you pass in any number of parameters regardless of its definition and you may not even notice. You can avoid type coercion if you understand how the language works (aka strict equality in JavaScript) but this isn't something only in JavaScript land either.

dozzie 10y ago
> Most dynamic languages will let you pass in any number of parameters regardless of its definition and you may not even notice. Python will throw an error. Ruby will throw an error. Tcl will throw an error. Erlang will throw an error. I believe most of the Lisps will throw an error. What was it about "most dynamic languages"?
- BinaryIdiot 10y ago
  > What was it about "most dynamic languages"? I should have changed my text to not say "regardless of definition" because you can do that in Python, Ruby, PHP, JavaScript, etc. Python and Ruby support it through (star)args or default parameters JavaScript supports it regardless PHP supports it regardless We can argue semantics or the fact that some of those types of errors can be caught with some subset of dynamic languages but I don't think that's useful. My only point was when comparing a dynamic language with a static language I find variable function parameters to be one of the bigger issues over type coercion. But that's just, like, my opinion.
  - deleted 10y ago
    [deleted]
  - kbp 10y ago
    Those aren't particular to dynamic languages, though. You can add C, C++, Java, and C# to your list of languages that support it. Being able to explicitly make a parameter optional, or to have a 0-or-more rest argument is different from how function application works in Javascript or Perl because you have explicitly made that part of your function's signature, and the language still checks calls against that signature.
mazelife 10y ago
There are two separate issues in play here. You're conflating the static/dynamic dimension of language classification with the strongly-/loosely-typed dimension of languages which is what the poster you are responding to was talking about [1]. These two dimensions are orthogonal: languages may be static, but weakly typed (like C), or dynamic but strongly typed (like Python). I'll allow that there's inevitably some degree of opinion involved here, but I tend to agree with the parent poster that implicit conversion in languages like Javascript, PHP, and Perl is just another vector for bugs, and outweighs any of the advantages you get from having your language coerce everything for you. But then again, i'm one of those people that likes my language to force me to be very explicit about what I mean, so YMMV. Regardless, the strict equality operator is not at all sufficient to avoid the dangers of JavaScript's implicit conversions. Pretty much _all_ the operators are going to coerce types for you, whether you meant for them to or not. For example, this function: function increment(i) { return i + 1; } Adds one to number right? But let’s say you’ve neglected to convert some user input in a form to a number as you should have done elsewhere in your code, and you end up calling increment("1"). This will return "11". So now you potentially have introduced a serious math error into your code you may not notice right away. Conversely, if you did this in Python, the function would have raised a TypeError immediately, because you can’t apply the arithmetic operator to two different types. You can’t just “avoid” type coercion in these loosely-typed languages by understanding the specifics of how it works, because you may not even know it’s happening until you start seeing unexpected results somewhere. [1] https://en.m.wikipedia.org/wiki/Strong_and_weak_typing https://en.m.wikipedia.org/wiki/Strong_and_weak_typing
lispm 10y ago
Most Lisp compilers will warn about wrong number of parameters at compile-time. Lisp typically warns at runtime, too.