What a nice way to make 1d -> 2d. I made my MSc thesis about data visualization and the thing I found useful was excess entropy, which means how well you can you predict the next bit better, if you take one bit more into the sliding window you use to predict the next bit/byte. That is usually really dependent about the sliding window size. Imagine what happens with text written in 8 bit characters. With that trick one could make a 3d visualization.
But I bet Python has a loopholes in the type system as well. I mean you can take the stack, and modify the running code in every way possible at runtime, but it is a slightly mad thing to do.
Yeah, the type system helps in that, but for a unit testable product you need factory methods, which produce some valid and invalid cases. If you write simple tests for those it is a type checker on it's own and the type checker is just overhead. If I could choose my next project from two similar implementations where the other would be type checked and the other unit tested with basic datatype factors (at least) I would choose the unit tested one.
I would use typed API's though, because it saves documentation reading time and makes the editor autocomplete to work like magic.
'strongly typed language increases the productivity' How was this tested? Was there a control group? I would argue that currently Javascript and Python have been greatly improving the productivity. The type system works well in the maintenance, API definitions and 'no unit tests' scenarios, but when you have to do something you don't have yet any clue about -for exmple at the start of a years long app development project, the type system is just in the way.
And if you think how wood turns twisted, when it grows faster on the other side and slower on the other, it is not that big leap to think how a wave function would turn if it is evaluated faster on some side. I am proposing here, that the wave function evaluation speed differential causes the gravity.