I don't know about Ruby but Perl certainly isn't strongly typed. You can run 'print "5.0" + 6' and get 11 as the answer. That's weak typing and types are implicitly converted to whatever.

Python is strongly typed only for the basic scalar types. With objects and classes there are just objects that may or may not have certain bound functions and attributes. Duck-typing is mostly perfectly sufficient since any errors do come out in practice, and there's no need for interfaces or classes as unique types, but what would be really helpful would be to have Clojure-like multimethods where dispatching of a function is itself a function of the arguments given in. That would be what would most alleviate the problems that arise from everything being a object() in Python.

Ruby is strongly typed. I am not sure that's static or dynamic, but regardless of how it is implemented, Ruby lacks ability to offer type information to code-writing level toolsets because it doesn't force retaining of type information on field and function parameters.

So regardless of whatever actually happens, to the tools, each Ruby function is just all dealing with unknown type parameter objects.

As a conclusion, Ruby has type, but has no way to utilize it. I think any other popular scripting language - such as Python, JS, Lua… are in same situation. V8 does speculative strong dynamic typing, but the those generated informations are completely useless to code-writing level tools.

And users of dynamically typed languages will sometimes argue that the need for code generation tools is less necessary. You lose the ability to have tools do a lot of the work, but you also lose the need to have tools do a lot of the work. It's a trade off.

Type [an]notations are also useful for compilers when generating performant code. But projects like pypy and V8 (javascript) show that a well written interpreter can do run-time analysis, and generate performant code, just like a static analysis.

Sorry, but what are the problems with everything being an object? That's a feature. Python 3.4 now has @singledispatch, though I don't know where I'd use that yet.

To be pedantic, assembly languages do generally have multiple types, if by 'type' we mean 'a set of values disjoint from other sets of values'. For example, x86 has the types integer, floating point, MMX, SSE, and registers of these types cannot be confused for each other. It's just that these classifications/types aren't so useful, and we can't make our own (and perhaps all we really wanted was a distinction between integer and pointer)

Historically they didnt, until hardware floating point wired up some registers to special hardware. Which is why C lets you cast; BCPL just has bit patterns.

Yeah, sorry, I should've used the term dynamic typing.

I think you originally intended explicit type notation. I recently discovered actual type doesn't matter that much, and the point is having an interface/protocol which enable compiler validation and tooling support. I learned this truth from Objective-C and Go. That's why I told actual typing system itself not important. Objective-C protocol is nothing about type, but defines nice interface for tooling support. Go interface defines set of promises, so actual object structure doesn't matter.

Furthermore, recent languages offer automatic type inference - Haskell, Go, C++11. They force to retain type information, but also permit to elide them where accurately inference-able/deduce-able.

This is completely different with not forcing type notion such as Python, Ruby, Lua, JS. In these languages, it is fundamentally impossible to track complete type information. But in explicitly type notated languages, it's possible to track complete type informations even they're elided.

I think those type-(notation)-less languages are making some efforts to offer type informations by adding annotations. But I don't think that's really meaningful, because that's not enforced, and community doesn't care much.

What about javascript?

Javascript is,

1. Dynamically strongly typed, but typing is limited to primitive types. 2. So actually it's untyped for objects which is really needs type information. 3. As it lacks class/interface concept at all, type (an)notation is fundamentally impossible, type tracking is also impossible. 4. So lacks ability to offer type information to toolset.

You don't have automated tooling support on Javascript about type, and it will degrade your productivity. So big companies interested on JS platform, are all offering JS with type notation -

1. Google = Dart, 2. MS = TypeScript, 3. Mozilla = Emscripten(in very unique way!)

Javascript is typically described as weakly typed; e.g., "2" + 2 is valid Javascript.