Well, one of the very first differences I think of between Lisp/smalltalk and Java is dynamic vs static typing. In Java, you have to write extra boilerplate code to satisfy the type system. This slows you down when you're writing code. However, when you're figuring out someone else's code, static types can be a big help. Often times, you can guess the right way to call a method based solely off the signature, and if pass the wrong thing, your IDE can highlight your mistake almost instantly.
So when you're working on your own freshly written code here and now, static typing is usually a hindrance. When you're working on 3 year old undocumented code written by someone you've never met, static typing is a key source of information on how things work. The bigger the team/project, the more likely it is you're working on code that's not familiar, so it would follow that static typing helps scalability.
- Int and float from numpy arrays are np.int/float32/64. And round(np.floatXX) returns a float, but round(float) returns an int in Python 3.
- ruamel.yaml loads CommentedMap and some custom scalar types. CommentedMap is not a subclass of dict.
That's true, but that's not what the article is about. He specifically calls out PHP, Python, and Ruby as examples of languages which do scale well to larger teams.
It seems that there's something else in the space between Ruby and Smalltalk that he thinks is responsible for a language being able to scale or not. I just can't figure out what it is.
My guess: maybe a Smalltalkish language in a conventional environment? Don't underestimate the power of being close to what the average programmer used to experience in the years before a new language is released.
Python is from the end of the 80s and its classes look like OO in C (without ++, I mean the explicit self), plus functional methods (len, etc). Ruby and Java are from the middle 90s and take that for granted and hide self and go all in with method calls. They take small steps and adopt a syntax similar to other existing languages. Too much change and developers won't follow en masse.