How does your choice of typing affect object-oriented language performance?

Performance wise many dynamic type languages are sufficient for most use cases. Unless you need to provide real time performance where every nano second counts then choosing a dynamically typed language won’t matter much. In my opinion the greatest caveat to dynamically typed languages is in large projects running for years, where the code base becomes very large and complex. The problem is in understanding the code flows. IDEs sometimes have a hard time helping you figure out which exact function is getting called when you work with multi project of distributed components. Because there is no type safety, function reference passed as arguments might confuse the IDE making it difficult to figure out which function is about to be called.

The choice of typing in object-oriented languages, between static typing (e.g., Java, C ) and dynamic typing (e.g., Python, JavaScript), affects performance and other aspects. Static Typing: Requires explicit type declaration at compile time. Enables aggressive optimizations for faster and more efficient code execution. Catches type-related errors at compile time for improved reliability. Allows better memory allocation decisions and predictable performance. Dynamic Typing: Allows variables to hold values of any type with runtime type checks. It may introduce overhead due to runtime type checks. Type-related errors might be detected only at runtime. It offers flexibility and productivity for developers but can lead to higher memory usage.

Dynamic type programs can be automatically transformed into static type using compiler and artificial intelligence techniques. Machine learning models can be trained to predict types in dynamic type systems by training on a large corpus of annotated codes snipped during the execution time. A compiler is then used to convert the static type program into object code. This way, the high flexibility of developing code with dynamic type programming language is achieved while the runtime performance of the program is preserved. By predicting the types of variables, objects, functions, and expressions in the code, machine learning can help improve the readability, maintainability, and performance of the code.

Strong typing might make it seem that interoperability is difficult, but if you're careful with your inheritance design (and design patterns), you can mitigate the vast majority of this. For languages without explicit inheritance, you can wrap an instance of the "parent" type in the child type definition, giving you the ability to call parent methods and access parent data. With weak typing, I've found code faster to hack together, but flakier and harder to scale to large applications. Finally, I'll disclose that the vast majority of my professional (and personal) coding has been in strongly-typed languages, so I have an experience bias: I know I prefer strong typing!

Weak typing requires more discipline and more extensive tests to be prepared (which is good by itself). However, if missed, some of conversion or wrong usage errors will be seen in runtime only.

Usually, one uses static typing to avoid the vtable lookup cost. However, if you are in the business of writing libraries and you want to shield your customer base from re-linking every time there's a new version of a library, you tend to use the pimple idiom, which in a way is another indirect lookup. People may argue its cost but it has its benefits. Best is to profile you application to find out the hot spots. Case by case.

You talk about "enable dynamic dispatch, composition and extensions". But, look... it is not "enabling" dynamic dispatch. It is required simply because the object type is not well known... that is not an advantage, that's one of the issues. Composition... I got confused, as composition can be used in any strongly typed/nominal programming language. Finally, I am not sure what you mean by extension.

When choosing a typing system, performance is not the only thing to consider. The requirements are different in the phases of SDLC. During prototyping, a less restrictive system is preferred due to the short learning curve, flexibility, and agility. However, a restrictive system is more critical once it is on production because of the reliability, sustainability, and scalability. The dilemma here is using a restrictive system might slow down the prototyping and miss the opportunity in such a competitive market today. One the other hand, developing a prototype quickly could end up with unexpected costs on sustaining and scaling later. Having a better evaluation of the idea, project and market trend would be the key to make the decision.

Oh but there is a definitive answer. A typing system is nothing but a constraint placed on the code. The more restrictive it is, the better you do in the task of limiting and left-shifting errors. Robin Milner - "well-typed programs cannot go wrong". But more restrictive also means less performant. Cause restrictions take time to apply. Steeper learning curve, longer compilation times, etc. To me this is a major argument for picking strongly statically typed languages for long-term large projects, where maintainability outweighs low entry threshold.

This conclusion doesn't really helper most of the readers. When developers choose a programming language, the performance is not always the first factor they would consider. More important things are around maintainability, readability, extensibility, etc. The bulletin points in this article didn't explain much about performance. Maybe the title should be rewritten.

While the title of the document refers to only "performance", the body of the article evaluates various criteria, such as complexity, verbosity, readability, flexibility, security, consistency.

Compiler II (white-box compilers) and Software II (large language models) shape the future of programming systems. Programs are first written in high-level dynamic type languages or even natural languages, then are transformed into low-level static type languages, and finally compiled into the object code. Type prediction with machine learning and LLMs complements type inference systems used in compilers. Different views of a source code, including the high-level, type annotated, and low-level codes are available for both development and maintenance tasks depending on the developers' needs. White-box compilers provide various APIs to change and refactor the source code effectively in such different levels of abstraction.