Why Python is Slow: Looking Under the Hood

Re:Why Python is Slow: Looking Under the Hood by ajanuary on Friday May 09, 2014 @02:38PM (#7722561)

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.

[ Parent | on HN ]

Re:Why Python is Slow: Looking Under the Hood by maxlybbert on Friday May 09, 2014 @07:12PM (#7723770)

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 ), unit checking ( 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 ), some assertions (static_assert), etc.). I don't necessarily push it all to compile time, but C++ allows me to.

[ Parent | on HN ]