4 ms·

In Javascript (which is also dynamically typed) I've had a few times where adding 1 and 0, say, yielded "10" because either the 1 or the 0 originally came from

In Javascript (which is also dynamically typed) I've had a few times where adding 1 and 0, say, yielded "10" because either the 1 or the 0 originally came from a string. OK, I can live with that, but I find the fact that you can use that string in numeric comparisons potentially confusing. The general argument is that if you write enough unit tests, you can guarantee that your code doesn't make those kinds of mistakes. The statically-typed response is "why should you have to write unit tests when the compiler can make that guarantee for you?"

ajanuary 12y ago
Adding strings to integers is usually referred to as weak typing, which is a seperate and orthogonal concept to dynamic typing. The runtime of a dynamic language could look at the two types of the values, decide they're different and throw a type error. Similarly, a static type checker could look at the types of the values and decide it knows how to do an implicit cast from one to the other.
- maxlybbert 12y ago
  That's a valid point. But, being dynamically typed, you don't find out about the type error until runtime. It's possible, although unlikely, that a Python web application can run for months before hitting a particular code branch where a string and an int are added together, and an exception is thrown. (In Python, it's also possible to get syntax errors long after you start your program). It's possible that the compiler would have had enough information to determine this, if the compiler were to check types. Again, the proposed solution is to simply write enough tests to exercise all code paths. For what it's worth, I enjoy working in Perl. But I realize when I do that some things are deferred until runtime. I also enjoy working in C and C++, partly because I can push some things to compile time (type checks, sure, but also arithmetic ( http://en.cppreference.com/w/cpp/numeric/ratio/ratio http://en.cppreference.com/w/cpp/numeric/ratio/ratio ), unit checking ( http://www.boost.org/doc/libs/1_55_0/doc/html/boost_units.html http://www.boost.org/doc/libs/1_55_0/doc/html/boost_units.ht... ), a decent amount of reflection ( http://en.cppreference.com/w/cpp/header/type_traits http://en.cppreference.com/w/cpp/header/type_traits ), some assertions (static_assert), etc.). I don't necessarily push it all to compile time, but C++ allows me to.
rectangletangle 12y ago
Python is a strong dynamically typed language. Unlike JavaScript, which is a weak dynamically typed language. In Python `'1' + 0` throws a `TypeError`. While JavaScript attempts to figure out what you meant.
- Chattered 12y ago
  Which would be fine if I only ever used "+" with literals. But normally, I write things like x + y where x and y are values I got from who knows where. Javascript shouldn't pretend to figure out what I mean by this, because in many cases, I'm talking gibberish, and all I have is a bug. I'd rather not talk about this stuff in terms of "types." It's about assertions, and Python makes them early and throws the exceptions early. It's a defensive practice that you can emulate in any language, and your assertions can be much richer than anything that is typically thought of as a type.
  - rectangletangle 12y ago
    I'm definitely a fan of Python's strategy. It's much better at detecting bugs early and often. That, and there's a distinction in Python between identity and equality, with the `is` and `==` operators respectively.
    - thaumasiotes 12y ago
      Frankly, I think Perl has the best approach to this specific problem. We all want to do some string concatenation. We all want to render some non-string values as strings sometimes. So: 1 + 0 = 1 1 . 0 = 10 Just stop using + to concatenate strings.
redler 12y ago
> In Javascript (which is also dynamically typed) I've had a few times where adding 1 and 0, say, yielded "10" because either the 1 or the 0 originally came from a string. OK, I can live with that, but I find the fact that you can use that string in numeric comparisons potentially confusing. There are two problems demonstrated by your example; the other is the overloading of the + operator as a design decision in JavaScript. Easier, but worse.
collyw 12y ago
That's a JS probelem. The majority of dynamic languages would handle this "properly".

ajanuary 12y ago

Adding strings to integers is usually referred to as weak typing, which is a seperate and orthogonal concept to dynamic typing. The runtime of a dynamic language could look at the two types of the values, decide they're different and throw a type error. Similarly, a static type checker could look at the types of the values and decide it knows how to do an implicit cast from one to the other.

maxlybbert 12y ago
That's a valid point. But, being dynamically typed, you don't find out about the type error until runtime. It's possible, although unlikely, that a Python web application can run for months before hitting a particular code branch where a string and an int are added together, and an exception is thrown. (In Python, it's also possible to get syntax errors long after you start your program). It's possible that the compiler would have had enough information to determine this, if the compiler were to check types. Again, the proposed solution is to simply write enough tests to exercise all code paths. For what it's worth, I enjoy working in Perl. But I realize when I do that some things are deferred until runtime. I also enjoy working in C and C++, partly because I can push some things to compile time (type checks, sure, but also arithmetic ( http://en.cppreference.com/w/cpp/numeric/ratio/ratio http://en.cppreference.com/w/cpp/numeric/ratio/ratio ), unit checking ( http://www.boost.org/doc/libs/1_55_0/doc/html/boost_units.html http://www.boost.org/doc/libs/1_55_0/doc/html/boost_units.ht... ), a decent amount of reflection ( http://en.cppreference.com/w/cpp/header/type_traits http://en.cppreference.com/w/cpp/header/type_traits ), some assertions (static_assert), etc.). I don't necessarily push it all to compile time, but C++ allows me to.

rectangletangle 12y ago

Python is a strong dynamically typed language. Unlike JavaScript, which is a weak dynamically typed language. In Python `'1' + 0` throws a `TypeError`. While JavaScript attempts to figure out what you meant.

Chattered 12y ago
Which would be fine if I only ever used "+" with literals. But normally, I write things like x + y where x and y are values I got from who knows where. Javascript shouldn't pretend to figure out what I mean by this, because in many cases, I'm talking gibberish, and all I have is a bug. I'd rather not talk about this stuff in terms of "types." It's about assertions, and Python makes them early and throws the exceptions early. It's a defensive practice that you can emulate in any language, and your assertions can be much richer than anything that is typically thought of as a type.
- rectangletangle 12y ago
  I'm definitely a fan of Python's strategy. It's much better at detecting bugs early and often. That, and there's a distinction in Python between identity and equality, with the `is` and `==` operators respectively.
  - thaumasiotes 12y ago
    Frankly, I think Perl has the best approach to this specific problem. We all want to do some string concatenation. We all want to render some non-string values as strings sometimes. So: 1 + 0 = 1 1 . 0 = 10 Just stop using + to concatenate strings.

redler 12y ago

> In Javascript (which is also dynamically typed) I've had a few times where adding 1 and 0, say, yielded "10" because either the 1 or the 0 originally came from a string. OK, I can live with that, but I find the fact that you can use that string in numeric comparisons potentially confusing. There are two problems demonstrated by your example; the other is the overloading of the + operator as a design decision in JavaScript. Easier, but worse.

collyw 12y ago

That's a JS probelem. The majority of dynamic languages would handle this "properly".