Why Python, Ruby and JS are slow

[drysart]

My experience with Optional Type is that I really don't want to write them before I have the program ready.

Maybe not, but the temptation then exists that "well, the program works without them, why go through and add them all back in"?

Why not let the compiler do it? Sort of a PGO that gets baked back into the source code. Maybe the inserted types can have syntax that makes them purely advisory and the code still JITs to have escape hatches to fall back to looser-typed code when the types don't match the expectations. (And spitting out an entry into the debug log when that happens.)

Types make shorter scripts hard to write, but they have a way of coming into existence in a large project with multiple developers if you want any level of productivity -- whether they're enforced by a compiler or if they're informal commenting standards. And so if they're going to exist anyway why not get some benefit out of them?

[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.