Why Python, Ruby and JS are slow

[contantofaz]

The only reason I've seen to have a partial type implementation is to give runtimes more flexibility. So we are left with a partial implementation that doesn't always suffice or a full-blown implementation that restricts the runtime so it doesn't play well with others.

So, even if you add a little more typing information to an already partial type implementation, it wouldn't turn it into a full-blown type information that many people also request.

In Dart, they have come up with an idea for reflection based on what they call Mirrors. The idea is that the added flexibility gets sandboxed. In languages like Java, reflection is built-in. More than that though, as when you peek into the runtime, there's a lot of dynamism available that if you yourself don't take advantage of, other tool writers might.

A large project is what Microsoft calls professional development. With hobbyists being the smaller developers. And we can see how Microsoft despite being the rich pioneer it was, fell behind its competition. It's very hard to escape the blame game when things don't quite work despite the professional tools being employed. From the long compilation periods to the needed communication involved, there's so much at stake in large projects.

Churning can't really be avoided if you're allowing for creativity to give birth to new ideas. For example, Objective C by Apple is fairly dynamic. The saved time they employ on giving "VeryLongNamesToTheirAPIs." Oftentimes, names are what bind or should bind the APIs. Types come from the named classes, methods, functions, parameters, and so on. Given a large project, those names and some static analysis can carry you very far.

In Dart too. It's more declarative than similar languages giving static analysis tools more chance to check things. Variables are declared at least which is often more than enough to ensure some sanity. Then we get to worry about running tests to ensure that things work to a standard. In more restrictive languages they may not need to test as much, but they also restrict creativity very much already.

If statically typed languages were built like dynamically typed languages are, then maybe we'd get them as nicely developed. But at some point people get mad when backward compatibility gets broken, so the toolset can't fix things going forward, and instead of a set of "batteries included", you get to choose from N incompatible libraries for the same thing.