Hacker News Reader

I can think of three ways of thinking about the term "strongly typed" once you realize it doesn't mean "statically typed".

1) It's meaningless--it's almost impossible to produce a real ranking of languages on the strength of their types.

2) These dynamic languages are all unityped because they're not statically typed. The fact that runtime tags won't allow certain operations to succeed has nothing to do with types.

3) Strongly typed is a rough and ready way of saying you don't do many implicit conversions.

I sympathize with (1). (2) is accurate, but really a terminological point. There's clearly a phenomenon to talk about, even if "typed" is the wrong word. I also sympathize with (3).

Python does far fewer implicit conversions than PHP, JavaScript or Perl. It even doesn't do at least one that Java does. So people often say Python is strongly, but dynamically typed. It's a real aspect of the language that you can view as a plus or minus.

  >>> 1 + "0"
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unsupported operand type(s) for +: 'int' and 'str'

This is what strong typing refers to.

It's not so clearcut. If this is evidence Python is strongly typed, would the following be evidence to the contrary?

  In [1]: 1 + 2.5
  Out[1]: 3.5

  In [2]: "foo" * 3
  Out[2]: 'foofoofoo'

  In [3]: [1, 2] * 3
  Out[3]: [1, 2, 1, 2, 1, 2]

It's not contrary, it's just convenience. One of the weaknesses in Python (if you can call it that) is that everything is an "object." The classes implementing string, list, and integer simply have methods that respond to those operators and rhs types.

  In [1]: "foo" + 3
  ---------------------------------------------------------------------------
  TypeError                                 Traceback (most recent call last)
  <ipython-input-1-21582e79f06e> in <module>()
  ----> 1 "foo" + 3

  TypeError: cannot concatenate 'str' and 'int' objects

That's because the "special" method "__add__" implemented by the string class will raise TypeError if it gets any object that isn't an instance of a subclass of string.

In a way it is kind of funny to call it, "strongly typed," but it does work. Maybe it should be called, "instancely-typed."

Okay, with this definition of 'strongly typed', can anyone come up with an example language that _isn't_ strongly typed?

It seems to make 'strongly typed' pretty meaningless, and this definition is probably _not_ what anyone who says they want a "strongly typed" langauge is using, so it hardly counters them to say that python is "strongly typed" under another definition, it's just confusing them with semantics.

(Of course, the people who say they want 'strongly typed' may have no idea what they're actually talking about, but wouldn't it be better to educate them then to take advantage of their ignorance to push your pro-python agenda?)

C is not strongly typed.

In general, when someone is talking about strong typing, they are talking about silent failure for unintuitive or ambiguous constructs. For example, if the expression

    x = '1' + 1

results in an error, you are probably using a strongly-typed language. In C, this is equivalent to

    x = 32;

In javascript you get

    x = '11'

In PHP you get

    x = 2

These are examples of weak typing.

Strong, as opposed to weak, implying that there is type-constraint checking; it's just done at run-time in Python.

You could also describe Python's type system to be dynamic in that instances of the type meta-class define the constraints and objects (instances of a class) can have constraints added and removed at run-time. Python is still fairly strong in this regard in that the built-in classes are immutable (ie: it is a TypeError to assign a bound method to an attribute on a built-in class such as str).

I suggest "instancely-typed" because categories, unions, and type theory. I'm only coming to grips with that in that OCaml's type solver can be both awesome, annoying, and cryptic. And at the end of the day I'm still not sure what it's buying me other than proving exhaustive pattern matches in certain conditions, fast pattern dispatching, and requiring specialized operators (+, -, , / for ints... +.,-.,.,/. for floats... etc). I'm sure the enlightenment will come when it stops becoming such a PITA to write a basic program.

Sometimes not having to satisfy the constraints up-front makes exploratory programming (where the constraints are not specified and known up front) easier. Python is going the annotation route in newer versions of the language which is rather useful so that tools could be written to verify consistency up-front (or at least provide hints).

Javascript comes to mind, since it only functionally has I think 5 types (string, number, boolean, array, object - and the line between array and object is blurry) and no user-added ones. There are no built-in type semantics whatsoever other than what properties are present on an object at the time of its use. Functions of different arities aren't even type-differentiable (although arity is available as a reflectable value).

I don't know. Runtime type checking is necessary because the language doesn't have constructs which allow dispatching based on type.

Otherwise, you'd run into Python's strong type system when doing an incompatible operation.

This is a great example, which is why I think "strong vs. weak" typing is properly thought of as a scale rather than a classification. Which is used properly in the blog post, merely comparing some instances of implicit conversion in JVM that make less sense by default (all of your examples can be argued to be deliberately useful, as opposed to Javascript WAT-style statements).

I agree with your second point. Python doesn't pretend to be strongly-typed, but it does use its, uh, 'loose' typing to great advantage.

I particularly like Python's arbitrary-precision integers, where ints are implicitly converted to longs, allowing you to have the performance of ints without the problem of integer overflows.

You say "python doesn't pretend to be strongly-typed", yet the OP is claiming it _is_ strongly typed.

I think the reality is "strongly typed" doesn't really mean much.

I love Python for things like this. 'foo' * 3 is so intuitive. Seriously, to hell with Java's StringWriters and StringBuffers and StringBufferInputStream throws IOException.

No. That would be evidence of polymorphism. Those objects have explicit ways of handling those operations based on the types or interface of the object left/right of the operand.

The interpreter/type system is doing nothing implicitly behind the scenes to coerce the objects.

No. Why would it?

As most OO languages, Python has function overloading based on the type of the parameters. The fact that those operators do different things when operating on different types is evidence that Python has strict types, not loose.

Not overloading in the sense of Java and what not.

There is no dynamic dispatch based on types in the interpreter, you have to manually do it in the body of the method, of which you have one.

Which makes it ambiguous:

    Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34) 
    [GCC 4.2.1 (Apple Inc. build 5664)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 1/2.3
    0.4347826086956522
    >>> 1 / 2.3
    fish: Job 2, 'python' terminated by signal SIGSEGV (Address boundary error)

(I didn't expect that last part.)

There's something weird going on with your system. There is absolutely no way under normal circumstances that you'd get a segmentation fault dividing 1 by 2.3.

    Python 2.7.5 (default, Nov  3 2014, 14:26:24) 
    [GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 1/2.3
    0.4347826086956522
    >>> 1 / 2.3
    0.4347826086956522

Identical output under Python 3.3.2

> There's something weird going on with your system.

Yep -- it seems like a readline problem. As you can tell, I don't use this machine for Python.

Indeed, it is strongly typed but not statically typed. The only thing is, almost every language is strongly typed now, the only counterexample I know is C (and derivatives). Not that there aren't others, but I'm not sure there are others that anyone really uses. So I wonder if it is really even worth saying a language is "strongly typed" anymore, it's hardly ever a distinction. Might as well just say "not C".

C, JavaScript, PHP, lisp...

There are many popular and weakly typed languages in use today.

JS is strongly typed, not sure about PHP but I don't think so. lisp is not a language, it's a family of languages

> [] + {}

"[object Object]"

> {} + []

0

JS and PHP are the prototypical examples of weak typing.

Again, not sure about PHP. But no, JS is strongly typed. What you've shown there is coercion, not type-punning or anything of the sort.

Strongly typed is pretty precisely defined and Python is certainly strongly typed.

I agree that there are precise definitions of the phrase "strongly typed", but from my experience if you put 10 computer scientists in the same room, you'll hear 3 different definitions of what it means.

Defined as what? The Wikipedia article says the definition is unclear:

Languages are often colloquially referred to as "strongly typed" or "weakly typed". In fact, there is no universally accepted definition of what these terms mean. In general, there are more precise terms to represent the differences between type systems that lead people to call them "strong" or "weak".

True, but the complaint that people tend to come up with is that Python is not statically typed. What they are looking for here are things such as clear, accurate and reliable IntelliSense, and the ability to right click on a method definition, select "Rename", and be assured that the refactoring will be propagated through to every usage throughout your codebase with no false positives and no false negatives.

Strong typing saves you from a whole universe of obscure bugs at no extra cost.

Static typing would be nice, but not in a Java or C# or C++ way. The extra verbosity makes it not worth the benefits. Sure, you get slightly more reliable intellisense, but at the expense of a program that's 15-20% longer.

But Python is strongly typed. A language can be dynamically typed, and strongly typed - no problem with that. More details in http://eli.thegreenplace.net/2006/11/25/a-taxonomy-of-typing...

There are plenty of options for concurrent and parallel operations in Python[0]. It is heavily used in data analytics and the scientific programming communities. Though it does often need a little help from C to take advantage of SMP hardware.

[0] https://wiki.python.org/moin/ParallelProcessing

Python is compiled in the sense that it produces bytecode, but in being so it lacks the benefits of other compiled languages such as thorough compile time error checking. I've found that this is sometimes why people don't even notice the compiler.

[OS threads are] "no longer good for CPU-bound work" "Python will work just fine for 'enterprise' work"

These two statements conflict.