4 ms·
Static subset of <language> While many here correctly observe that the "too much dynamism" can become a performance bottleneck, one has to analyze the common s
by adsharma 6y ago
Static subset of <language>
While many here correctly observe that the "too much dynamism" can become a performance bottleneck, one has to analyze the common subset of python that most people use and see how much dynamism is intrinsic to those use cases.
Other languages like JS have tried a static subset (Static typescript is a good example), that can be compiled to other languages - usually C.
Python has had RPython, but no one uses it outside of the compiler community.
The argument here is that python doesn't have to be one language. It could be 2-3 with similar syntax catering to different use cases and having different linters.
* A highly dynamic language that caters to "do this task in 10 mins of coding" use case. This could be used by data scientists and other data exploration use cases.
* A static subset where performance is at a premium. Typically compiled down to another language. Strict typing is necessary. Performance sensitive and a large code base that lives for many years.
* Some combination of the two (say for a template engine type use case).
A problem with the static use case is that the typing system in python is incomplete. It doesn't have pattern matching and other tools needed to support algebraic data types. Newer languages such as swift, rust and kotlin are more competitive in this space.