{"slug": "modern-language-design-and-the-battle-for-ai-dominance", "title": "Modern language design and the battle for AI dominance", "summary": "A Fortran community proposal to add modern object-oriented programming features, including traits and generics, could give Fortran an advantage in AI-dominated coding, according to a forum post on the Fortran-lang Discourse site. The post argues that because large language models can translate semantics between languages rather than relying on language-specific training data, Fortran's smaller ecosystem matters less, and that traits let a compiler act as a semantic oracle constraining AI-generated code. The author frames the discussion around the question of what properties a programming language should optimize for when AI becomes the primary producer of software.", "body_md": "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.\n\nI have had discussions with AI agents and below is an AI generated “summary” of it.\n\nAt 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.\n\nhere is the text:\n\nThere is perhaps a larger question behind the discussion of Traits, generics, OO and other proposed additions to Fortran:\n\n**What properties should a programming language optimize for when AI becomes the primary producer of software?**\n\nFor 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.\n\nAI changes the equation.\n\nAn 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.\n\nThat means the future competitive advantages of programming languages may increasingly be things such as:\n\nThis makes some of Fortran’s characteristics considerably more interesting than they might appear from today’s programming-language rankings.\n\nOne argument against Fortran in an AI-dominated world is that its ecosystem is much smaller than those of C++, Python, JavaScript, etc.\n\nI think this argument deserves reconsideration.\n\nAn AI does not necessarily need to have seen a Fortran implementation of every useful abstraction.\n\nSuppose a mature library in another language provides a sparse matrix, automatic differentiation framework, PDE solver, numerical optimizer, tensor abstraction, or parallel algorithm.\n\nAn AI that understands both the source and target language can potentially perform:\n\n**concept → semantics → target-language implementation**\n\nrather than merely:\n\n**search for existing target-language code → copy → modify**\n\nIn 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**.\n\nOf 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.\n\nThis potentially changes the relative importance of language design itself.\n\nThe Traits proposal seems relevant to this future for a reason that goes beyond simply bringing Fortran closer to Rust, Go or Swift.\n\nTraits provide a way of expressing **what an abstraction requires**, independently of the particular implementation.\n\nFor an AI, this is extremely attractive.\n\nInstead of asking:\n\nFind or invent a type that works with this algorithm.\n\nthe language can express:\n\nConstruct a type satisfying this precisely defined contract.\n\nThe compiler can then act as a semantic oracle.\n\nThe resulting loop becomes something like:\n\n```\nAI generates code\n       ↓\ncompiler checks semantics\n       ↓\ndiagnostics constrain the search\n       ↓\nAI repairs code\n       ↓\ntests verify behaviour\n       ↓\nprofiler verifies performance\n       ↓\nAI optimizes\n```\n\nIn 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**.\n\nThat may ultimately matter more than how many examples of the language were present in the model’s training corpus.\n\nThere is a potential paradox here.\n\nFor decades, adding language features has often been seen as making a language more capable.\n\nBut every feature also increases the language’s semantic surface.\n\nMore features mean more:\n\nConsequently, the ideal AI-oriented language may not be the language with the largest number of features.\n\nIt may be the language with the **smallest coherent semantic system that is sufficiently expressive**.\n\nThis is where Fortran’s historical conservatism could potentially become an advantage.\n\nFortran has famously resisted adding features simply because another language has them.\n\nThat has sometimes made Fortran look old-fashioned.\n\nBut perhaps the relevant question is not:\n\nHow many modern features does Fortran have?\n\nIt is:\n\nHow much unnecessary semantic complexity does Fortran avoid while still providing the abstractions that modern software actually needs?\n\nThere is an important distinction between **feature minimalism** and **semantic minimalism**.\n\nFeature minimalism says:\n\nAdd as little as possible.\n\nSemantic minimalism says:\n\nAdd powerful capabilities, but make them coherent, orthogonal and predictable.\n\nI think the latter could be a very good strategy for Fortran.\n\nA 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.\n\nThe 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.\n\nI don’t think the lesson is that Fortran should suddenly acquire every feature found in Rust, C++, Swift, Julia and other languages.\n\nQuite the opposite.\n\nThe 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.\n\nTraits/generics appear to me to belong to this category.\n\nPotentially other features do as well.\n\nBut 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.\n\nIf the language can acquire sufficiently powerful modern abstraction mechanisms while retaining its existing strengths, it could end up with a rather unusual combination:\n\n**high-level mathematical expression\n\nThat combination could be particularly valuable for AI-generated scientific and HPC software.\n\nThe AI does not have to love Fortran.\n\nIt does not even have to prefer writing Fortran.\n\nIt 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**.\n\nIf that becomes possible, the language’s execution model and semantic quality may matter considerably more than its popularity among human programmers.\n\nThe objective should not necessarily be to make Fortran the language that humans choose for every new application.\n\nIt could instead become one of the languages that AI chooses when the final program needs:\n\nThat suggests a potentially different way of evaluating proposals such as Traits.\n\nRather than asking only:\n\n“Does this make Fortran nicer for programmers?”\n\nwe should also ask:\n\n**“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?”**\n\nIf the answer is yes, then a feature may have considerably more strategic value than its immediate human-facing convenience suggests.\n\nThe irony is that Fortran’s long-standing resistance to indiscriminate language growth could turn out to be one of its strengths.\n\n**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.**\n\nThat is a very interesting position for Fortran to be in.", "url": "https://wpnews.pro/news/modern-language-design-and-the-battle-for-ai-dominance", "canonical_source": "https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105#post_1", "published_at": "2026-09-19 06:28:32+00:00", "updated_at": "2026-09-19 06:53:36.852085+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "developer-tools"], "entities": ["Fortran", "Fortran-lang Discourse", "kkifonidis", "Rust", "Go", "Swift", "C++", "Python"], "alternates": {"html": "https://wpnews.pro/news/modern-language-design-and-the-battle-for-ai-dominance", "markdown": "https://wpnews.pro/news/modern-language-design-and-the-battle-for-ai-dominance.md", "text": "https://wpnews.pro/news/modern-language-design-and-the-battle-for-ai-dominance.txt", "jsonld": "https://wpnews.pro/news/modern-language-design-and-the-battle-for-ai-dominance.jsonld"}}