# Modern language design and the battle for AI dominance > Source: > Published: 2026-09-19 06:28:32+00:00 I have been thinking about [@kkifonidis](https://fortran-lang.discourse.group/u/kkifonidis) proposal for modern OOP. I think it is an excellent proposal. Not only because it adds very attractive and elegant semantics and features potentially solving a large number of “human driven issues” in generic programming but because It might actually be beneficial in AI dominated coding where Fortran might actually possess surprising advantages over other languages. I have had discussions with AI agents and below is an AI generated “summary” of it. At first I meant to add this as an answer to [@kkifonidis](https://fortran-lang.discourse.group/u/kkifonidis) 's traits thread, but then thought that I don’t want to derail the discussion there. I’ll simply add a link from there to here. here is the text: There is perhaps a larger question behind the discussion of Traits, generics, OO and other proposed additions to Fortran: **What properties should a programming language optimize for when AI becomes the primary producer of software?** For most of programming-language history, language design has been optimized largely around human programmers. Features are justified because they make programs easier to write, easier to read, or more expressive for humans. AI changes the equation. An LLM can learn almost any syntax. It can translate between languages. It can read documentation and standards. It can generate code, compile it, inspect diagnostics, run tests, profile the result, and iterate. That means the future competitive advantages of programming languages may increasingly be things such as: This makes some of Fortran’s characteristics considerably more interesting than they might appear from today’s programming-language rankings. One argument against Fortran in an AI-dominated world is that its ecosystem is much smaller than those of C++, Python, JavaScript, etc. I think this argument deserves reconsideration. An AI does not necessarily need to have seen a Fortran implementation of every useful abstraction. Suppose a mature library in another language provides a sparse matrix, automatic differentiation framework, PDE solver, numerical optimizer, tensor abstraction, or parallel algorithm. An AI that understands both the source and target language can potentially perform: **concept → semantics → target-language implementation** rather than merely: **search for existing target-language code → copy → modify** In other words, the relevant resource is not necessarily *language-specific training data*. It is increasingly **semantic knowledge plus a precise specification of the target language**. Of course, ecosystem knowledge still has value. Undocumented behavior, subtle numerical issues, platform-specific optimizations and battle-tested implementation techniques cannot always be reconstructed from a specification. But AI substantially reduces the penalty associated with an ecosystem being smaller. This potentially changes the relative importance of language design itself. The Traits proposal seems relevant to this future for a reason that goes beyond simply bringing Fortran closer to Rust, Go or Swift. Traits provide a way of expressing **what an abstraction requires**, independently of the particular implementation. For an AI, this is extremely attractive. Instead of asking: Find or invent a type that works with this algorithm. the language can express: Construct a type satisfying this precisely defined contract. The compiler can then act as a semantic oracle. The resulting loop becomes something like: ``` AI generates code ↓ compiler checks semantics ↓ diagnostics constrain the search ↓ AI repairs code ↓ tests verify behaviour ↓ profiler verifies performance ↓ AI optimizes ``` In that environment, a strong type system and a coherent generic model aren’t merely conveniences for human programmers. They become **constraints that make AI-generated programs more reliable**. That may ultimately matter more than how many examples of the language were present in the model’s training corpus. There is a potential paradox here. For decades, adding language features has often been seen as making a language more capable. But every feature also increases the language’s semantic surface. More features mean more: Consequently, the ideal AI-oriented language may not be the language with the largest number of features. It may be the language with the **smallest coherent semantic system that is sufficiently expressive**. This is where Fortran’s historical conservatism could potentially become an advantage. Fortran has famously resisted adding features simply because another language has them. That has sometimes made Fortran look old-fashioned. But perhaps the relevant question is not: How many modern features does Fortran have? It is: How much unnecessary semantic complexity does Fortran avoid while still providing the abstractions that modern software actually needs? There is an important distinction between **feature minimalism** and **semantic minimalism**. Feature minimalism says: Add as little as possible. Semantic minimalism says: Add powerful capabilities, but make them coherent, orthogonal and predictable. I think the latter could be a very good strategy for Fortran. A feature such as Traits may be quite substantial, but if it gives Fortran one coherent abstraction mechanism for generic programming, static polymorphism and runtime polymorphism, it can actually reduce conceptual fragmentation. The same question applies to smaller proposed features such as `:=`: if a new construct provides a strong and unambiguous semantic signal, its value may be greater in an AI-generated-code world than it would appear from human syntax alone. I don’t think the lesson is that Fortran should suddenly acquire every feature found in Rust, C++, Swift, Julia and other languages. Quite the opposite. The opportunity may be to identify a relatively small number of **high-leverage features** that substantially increase abstraction power while preserving Fortran’s relatively coherent semantic model. Traits/generics appear to me to belong to this category. Potentially other features do as well. But there should also be a strong presumption against features that merely provide another way of expressing something without materially improving abstraction, correctness, performance or AI-generation precision. If the language can acquire sufficiently powerful modern abstraction mechanisms while retaining its existing strengths, it could end up with a rather unusual combination: **high-level mathematical expression That combination could be particularly valuable for AI-generated scientific and HPC software. The AI does not have to love Fortran. It does not even have to prefer writing Fortran. It merely has to be able to **reliably translate a high-level computational intention into Fortran and then use the compiler and test system to verify the result**. If that becomes possible, the language’s execution model and semantic quality may matter considerably more than its popularity among human programmers. The objective should not necessarily be to make Fortran the language that humans choose for every new application. It could instead become one of the languages that AI chooses when the final program needs: That suggests a potentially different way of evaluating proposals such as Traits. Rather than asking only: “Does this make Fortran nicer for programmers?” we should also ask: **“Does this make the semantic space of Fortran easier for a machine to reason about while making the resulting programs more powerful and more efficiently executable?”** If the answer is yes, then a feature may have considerably more strategic value than its immediate human-facing convenience suggests. The irony is that Fortran’s long-standing resistance to indiscriminate language growth could turn out to be one of its strengths. **In an AI-dominated programming world, the winning language may not be the language with the most features. It may be the language with the best ratio of expressive power, execution efficiency and semantic precision per unit of complexity.** That is a very interesting position for Fortran to be in.