# Modern language design and the battle for AI dominance

**URL:** <https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105>\
**Category:** Uncategorized\
**Created:** [September 19, 2026, 6:28am UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105 "2026-09-19T06:28:32Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![eelis](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@eelis](https://fortran-lang.discourse.group/u/eelis)\
**Post date:** [September 19, 2026, 6:28am UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/1 "2026-09-19T06:28:32Z")

</div>

I have been thinking about @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 '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:

- execution performance;
- semantic precision;
- ease of static verification;
- compiler diagnostics and feedback;
- ability to express high-level abstractions without runtime overhead;
- compactness of the representation;
- predictability of semantics;
- and, perhaps most importantly, how reliably an AI can generate _correct_ code.

This makes some of Fortran’s characteristics considerably more interesting than they might appear from today’s programming-language rankings.

## AI does not necessarily need a large language-specific ecosystem

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.

## This makes Traits particularly interesting

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:

```auto
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.

## This also changes how we should think about language complexity

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:

- interactions between features;
- special cases;
- syntax the AI must distinguish;
- semantic possibilities;
- compiler behaviour to understand;
- opportunities for subtly incorrect code.

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’s stubbornness may be an asset

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.

## The goal should therefore perhaps be selective modernisation

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.

## Fortran has an unusual combination

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

- static semantic guarantees
- zero-cost abstractions
- predictable native performance
- excellent array semantics
- decades of numerical knowledge
- enormous existing scientific code
- a comparatively restrained language design\*\*

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.

## Perhaps this is the strategic opportunity

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:

- numerical performance,
- predictable execution,
- efficient memory use,
- strong compiler optimisation,
- mathematical expressiveness,
- and highly reliable generated code.

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.

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [September 19, 2026, 7:05am UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/2 "2026-09-19T07:05:29Z")

</div>

I agree. I think that features that used to make things easy to write for a human are now much less important than features to make it easy to read. So what Python calls “syntactic sugar” is now much less important, because AI can easily write the “de-sugared syntax”. The key is if things are still easy to read. And less complex language I think is always good, for both AI and humans, as it makes it easier to reason about.

And yes, I think @kkifonidis’s proposal is solid, so that’s why I want to prototype it very soon, so that we can all play with it and see.

---

<div class="post-metadata">

**Author:** ![kkifonidis](https://avatars.discourse-cdn.com/v4/letter/k/898d66/32.png) [@kkifonidis](https://fortran-lang.discourse.group/u/kkifonidis)\
**Post date:** [September 19, 2026, 8:25am UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/3 "2026-09-19T08:25:04Z")

</div>

> [@eelis](#):
>
> 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 has actually always been true, even before AI, and it is regarded as being a sign of good language design. It is probably most perfectly exemplified by Niklaus Wirth’s work and school of thought.

> [@eelis](#):
>
> Semantic minimalism says:
> 
> > Add powerful capabilities, but make them coherent, orthogonal and predictable.

See above. Wirth’s languages were as minimalistic as he could get them. But at the same time they were very powerful because he followed exactly this same path of finding the right (minimal) set of abstractions to base them on.

I think that traits fit very nicely into this overall language design philosophy. After all the unification of run-time and compile-time polymorphism, that they afforded us, even we were recently surprised to see how naturally they also subsume @FortranFan’s proposed “KART” genericity.

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [September 20, 2026, 3:41am UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/4 "2026-09-20T03:41:50Z")

</div>

Excellent point by @kkifonidis that most of these design choices were true before AI also, i.e., AI just exposes a lot of these truths more clearly. And that the fundamentals didn’t really change.

---

<div class="post-metadata">

**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\
**Post date:** [September 20, 2026, 11:25pm UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/5 "2026-09-20T23:25:02Z")

</div>

Many high-level languages today compile to an intermediate language such as LLVM IR or GIMPLE, which I think is still hardware independent. In the future, can we expect AI to take instructions from a human and produce directly the intermediate language code?

---

<div class="post-metadata">

**Author:** ![jorgeg](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jorgeg/32/6835_2.png) [@jorgeg](https://fortran-lang.discourse.group/u/jorgeg)\
**Post date:** [September 20, 2026, 11:33pm UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/6 "2026-09-20T23:33:58Z")

</div>

> [@RonShepard](#):
>
> In the future, can we expect AI to take instructions from a human and produce directly the intermediate language code?

I think there’s still a way to go for this, maybe in a certain future (10-15 years). At this point I see those languages that are small and have a low semantic extent to be very powerful for AI driven development. There’s less patterns it can invent with Fortran as opposed to C++

---

<div class="post-metadata">

**Author:** ![eelis](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@eelis](https://fortran-lang.discourse.group/u/eelis)\
**Post date:** [September 21, 2026, 9:58am UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/7 "2026-09-21T09:58:17Z")

</div>

I think none of the “metrics”, provided in the first post, would be improved by the “low-level” IR properties compared to “high-level languages” in the AI use. Abstraction is a good thing also for AIs. Maybe in the future there could be some “high-level AI language” that could beat all the “human-driven languages”.

---

<div class="post-metadata">

**Author:** ![timofeymukha](https://avatars.discourse-cdn.com/v4/letter/t/d2c977/32.png) [@timofeymukha](https://fortran-lang.discourse.group/u/timofeymukha)\
**Post date:** [September 25, 2026, 2:57pm UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/8 "2026-09-25T14:57:33Z")

</div>

Not to be that guy, but to me this seems like a canonical example of an LLM defaulting to be supportive of the opinion of the user. Fortran’s greatest strength is arguably the built-in arrays, which is great for humans, but is essentially the syntactic sugar an LLM does not care about. Moreover, their value is diminished heavily by GPU computing, since all the fancy slicing etc. is host only anyway. It also suffers from a large number of its standardized features not being properly supported by compilers, leading to obscure errors in what should be valid code. This is exactly the type of thing that an LLM would have trouble internalizing. So, sadly, I think even C would be a better AI language, and a constrained subset of C++ superior by far.

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [September 25, 2026, 5:01pm UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/9 "2026-09-25T17:01:44Z")

</div>

@timofeymukha if you follow the argument you wrote to its natural conclusion, then LLM should just generate the binary directly and skip the C language also. And that is indeed what many predict will happen.

However, my guess is that we (and LLMs!) will still want to have a reference implementation (in addition to the ability to generate the binary directly). And for that, the “simpler/shorter/easier to reason about” it is, the better. I would argue Fortran is better than C for that, for both humans and LLMs.

> This /compilers support for the standard/ is exactly the type of thing that an LLM would have trouble internalizing.

I am not sure that’s true, AI agents have been excellent at writing Fortran for me and had no problem handling the case when a certain compiler didn’t support some feature.

> Moreover, their value is diminished heavily by GPU computing, since all the fancy slicing etc. is host only anyway.

I am not sure that’s true, as I have recently implemented in LFortran a lot of such support for fancy slicing and GPU offloading. I am guessing other compilers have also.

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [September 25, 2026, 5:04pm UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/10 "2026-09-25T17:04:08Z")

</div>

> [@timofeymukha](#):
>
> Fortran’s greatest strength is arguably the built-in arrays, which is great for humans, but is essentially the syntactic sugar an LLM does not care about. Moreover, their value is diminished heavily by GPU computing, since all the fancy slicing etc. is host only anyway.

I would politely push back on a few claims here.

To the best of my knowledge array expressions are allowed within OpenMP-annotated loops, OpenACC kernel and loop regions and CUDA Fortran kernels.The new `!$omp target workdistribute` construct has been introduced specifically to bring array expressions onto GPU with ease. The lack of proper compiler support is a fair critique.

I’m not too deep into AI programming, but the introduction of languages like Triton, Mojo, and cuTile Python/C++, appear to be motivated by the need to program and _reason_ at a higher-level, without the burden of explicit GPU thread management, linear array indexing, and overly-complicated kernel launch boilerplate that trouble C and C++ frameworks (OpenCL, Metal, …).

A good C++ abstraction layer does help a lot, but I still find the idea of the compiler having to process these sort of variadic indexing templates to have nice multi-dimensional array access surprising to say the least:

```cxx
// ---------------------------------------------------------------------------
// ndview: zero-overhead multi-dimensional accessor, compile-time extents.
// No __host__  __device__ annotations: everything is constexpr and touches
// only template parameters. Under nvcc compile with --expt-relaxed-constexpr;
// clang CUDA / hipcc need no flag; plain C++ (OpenMP, Kokkos host) is
// unaffected.
// ---------------------------------------------------------------------------
template <typename T, int... Extents>
struct ndview {
    static constexpr int rank = sizeof...(Extents);
    static constexpr int size = (Extents * ...);

    T* data;

    template <typename... Is>
    constexpr T& operator()(Is... is) const {
        static_assert(sizeof...(Is) == rank, "index count must match rank");
        int idx = 0;
        ((idx = idx * Extents + static_cast<int>(is)), ...);
        return data[idx];
    }
};

```

Not every scientific programmer has the time or desire to learn how to write such variadic template accessors.

When it comes to C++ array abstractions, which one do I pick, mdspan, Eigen++, Armadillo, Kokkos, RAJA, Blitz, Blaze, … ? There are so many array libraries, one ends-up having to port between libraries eventually. The heavy template instantiation in these libraries drives compile times up, making the compiled-edit-cycle slow. Debugging becomes slow, because under `-O0 -g` the templates are not inlined and dozens of tiny functions are invoked.

When you want to profile your C++ code, the profiler points you to a chain of 10 lambda functions (some of which may be anonymous):

```txt
typeinfo name for sycl::_V1::event Kokkos::Impl::ParallelFor<
   Parallel::Kokkos_BwdTransHexKernel_QP_2D_BLOCKS_pq_SimpleMap<float, 10u, 10u, 10u>(float const*, float const*, float const*, float const*, float const*, float*, unsigned int, unsigned int, unsigned int, unsigned int)::{
      lambda(Kokkos::Impl::SYCLTeamMember)#1}, Kokkos::TeamPolicy<>, Kokkos::SYCL>::sycl_direct_launch<
         Kokkos::Impl::SYCLFunctionWrapper<
             Parallel::Kokkos_BwdTransHexKernel_QP_2D_BLOCKS_pq_SimpleMap<float, 10u, 10u, 10u>(float const*, float const*, float const*, float const*, float const*, float*, unsigned int, unsigned int, unsigned int, unsigned int)::{
                lambda(Kokkos::Impl::SYCLTeamMember)#1},
                    Kokkos::Impl::SYCLInternal::USMObjectMem<(sycl::_V1::usm::alloc)0>, false>>(sycl::_V1::multi_ptr<char, (sycl::_V1::access::address_space)4, (sycl::_V1::access::decorated)2>, float const&, sycl::_V1::event const&) const::{
                       lambda(sycl::_V1::handler&)#1}::operator()(sycl::_V1::handler&) const::{lambda(sycl::_V1::nd_item<2>)#1}

```

(I’m aware that Kokkos-Tools have hooks to solve this particular problem.)

I’m skeptical about the LLM not caring about array syntax and indexing. The volume of code that uses array abstractions (numpy, MATLAB, R, …) would perhaps improve the quality of LLMs when it comes to generating these sort of algorithms.

I do agree a constrained set of C++ is a very powerful language and occasionally I also like using it.

---

<div class="post-metadata">

**Author:** ![kkifonidis](https://avatars.discourse-cdn.com/v4/letter/k/898d66/32.png) [@kkifonidis](https://fortran-lang.discourse.group/u/kkifonidis)\
**Post date:** [September 25, 2026, 5:23pm UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/11 "2026-09-25T17:23:47Z")

</div>

> [@ivanpribec](#):
>
> When it comes to C++ array abstractions, which one do I pick, mdspan, Eigen++, Armadillo, Kokkos, RAJA, Blitz, Blaze, … ?

At least one of them (Blitz) was abandoned, rotting, software the last time I checked. While others supported only 1d and 2d arrays (“vectors”, and “matrices”, respectively). Good luck to anyone who’s going to depend on these for scientific projects where longevity is crucial.

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [September 25, 2026, 5:45pm UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/12 "2026-09-25T17:45:45Z")

</div>

Thanks for bringing that up, indeed higher-order tensors are not that common in C++ libraries, at least not the ones I’m aware of.

The Kokkos way of representing the array rank with a pointer template parameter,

```cxx
using tensor = Kokkos::View<double***>;

```

is kind of innovative, but I still find it to be an eyesore compared to Fortran,

```auto
real(dp), dimension(3), allocatable :: A

```

Granted, the C++ way is to define the typedef and use that instead.

I haven’t checked what maximum rank do [`View`](https://kokkos.org/kokkos-core-wiki/API/core/view/view.html)’s support. Gemini says it is rank 8. The possibility of having a View to have both runtime- and compile-time dimensions does seem useful however.

The way PyTorch represents arrays in the underlying C++ library is quite interesting: [Understanding ATen: PyTorch’s tensor library](https://developers.redhat.com/articles/2026/02/19/understanding-aten-pytorchs-tensor-library).

---

<div class="post-metadata">

**Author:** ![kkifonidis](https://avatars.discourse-cdn.com/v4/letter/k/898d66/32.png) [@kkifonidis](https://fortran-lang.discourse.group/u/kkifonidis)\
**Post date:** [September 25, 2026, 5:52pm UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/13 "2026-09-25T17:52:25Z")

</div>

> [@ivanpribec](#):
>
> Thanks for bringing that up, indeed higher-order tensors are not that common in C++ libraries, at least not the ones I’m aware of.

This was the point that held me back from jumping ship to C++ more than a decade ago.

How is one supposed to write an efficient 3d CFD solver, or a Boltzmann transport solver (six dimensions) if the only thing you’ve got are “vectors” and “matrices”?

---

<div class="post-metadata">

**Author:** ![jorgeg](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jorgeg/32/6835_2.png) [@jorgeg](https://fortran-lang.discourse.group/u/jorgeg)\
**Post date:** [September 25, 2026, 10:46pm UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/14 "2026-09-25T22:46:23Z")

</div>

> [@timofeymukha](#):
>
> Moreover, their value is diminished heavily by GPU computing, since all the fancy slicing etc. is host only anyway.

Not necessarily, using openacc/openmp for data mapping you can still make arrays behave almost as if they were host-like

> [@ivanpribec](#):
>
> To the best of my knowledge array expressions are allowed within OpenMP-annotated loops, OpenACC kernel and loop regions and CUDA Fortran kernels.

I can confirm this. I use it extensively.

---

<div class="post-metadata">

**Author:** ![eelis](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@eelis](https://fortran-lang.discourse.group/u/eelis)\
**Post date:** [October 22, 2026, 9:38am UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/15 "2026-10-22T09:38:01Z")

</div>

FYI [How does programming language affect token efficiency and correctness?](https://danluu.com/pl-tokens/)

---

<div class="post-metadata">

**Author:** ![eelis](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@eelis](https://fortran-lang.discourse.group/u/eelis)\
**Post date:** [October 22, 2026, 9:44am UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/16 "2026-10-22T09:44:44Z")

</div>

I asked an AI assistant to analyze the article and summarize its implications for a specialized language community like ours. Here is the analysis it provided:

"Dan Luu’s recent benchmarking reveals a critical reality for non-mainstream programming languages in the age of LLMs. In his testing using GPT-5.6 Sol on complex tasks, Luu debunked the popular internet myth that dynamic or concise languages are inherently more token-efficient than static ones. Instead, the data showed a clear positive correlation between a programming language’s mainstream popularity and the LLM’s ability to generate cheap, fast, and correct code.

Mainstream languages excel because major AI labs invest heavily in feeding them high-quality synthetic training data and Reinforcement Learning environments. Conversely, niche or specialized languages suffer an LLM performance penalty because they lack this massive training footprint.

For the Fortran community, this analysis highlights two major takeaways:

1. The Popularity Penalty: Because LLMs rely on massive code volume, they face a steep difficulty curve with Fortran. The models might handle basic syntax but struggle with sophisticated modern Fortran paradigms or idiosyncratic toolchains due to a lack of deep RL training data.
2. The Necessity of Strict Specs: Luu found that LLMs perform drastically better when provided a clean, canonical specification rather than being left to infer intent. For Fortran engineering and scientific applications, feeding the LLM highly precise mathematical or physical specifications is critical to overcoming the training data gap."

Given this perspective, I am curious about your experiences. Have you noticed a steep performance drop-off when asking LLMs to move from boilerplate to complex Fortran logic? How do you structure your prompts to compensate for the lack of public Fortran training data?

---

<div class="post-metadata">

**Author:** ![eelis](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@eelis](https://fortran-lang.discourse.group/u/eelis)\
**Post date:** [October 22, 2026, 9:49am UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/17 "2026-10-22T09:49:21Z")

</div>

The second point is also what we have been discussing here earlier and over all supports what Fortranners have been suggesting in support for Fortran. The future for Fortran (relative to other languages) looks brighter with LLM support (and in general the age of AI) than with out in my opinion.

---

<div class="post-metadata">

**Author:** ![eelis](https://avatars.discourse-cdn.com/v4/letter/e/c6cbf5/32.png) [@eelis](https://fortran-lang.discourse.group/u/eelis)\
**Post date:** [October 22, 2026, 10:06am UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/18 "2026-10-22T10:06:37Z")

</div>

There is also the interesting question about “Abstraction vs no Abstraction” (point implicitly made by @timofeymukha and explicitly clarified by @certik ). I think there will be abstraction regardless what the output language is. Either the abstraction lives in the AI neural network, or in the language we use. I have not made up my mind which is ultimately better. But my intuition says that abstraction in the level of the language should be beneficial for the correctness of code. Maybe there are some benefits in code performance when moving the abstraction to AI neural net. Perhaps AI can find some funky way of treat special cases.

---

<div class="post-metadata">

**Author:** ![timofeymukha](https://avatars.discourse-cdn.com/v4/letter/t/d2c977/32.png) [@timofeymukha](https://fortran-lang.discourse.group/u/timofeymukha)\
**Post date:** [October 22, 2026, 12:46pm UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/19 "2026-10-22T12:46:59Z")

</div>

I guess you either use mdspan or as the AI to write your own tensor type, which should be relatively easy.

---

<div class="post-metadata">

**Author:** ![timofeymukha](https://avatars.discourse-cdn.com/v4/letter/t/d2c977/32.png) [@timofeymukha](https://fortran-lang.discourse.group/u/timofeymukha)\
**Post date:** [October 22, 2026, 12:48pm UTC](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105/20 "2026-10-22T12:48:42Z")

</div>

@jorgeg I would argue that OpenMP (in the GPU context) and OpenACC are by themselves more or less just syntactic sugar so that one does not have to learn how to write CUDA / HIP kernels. Something the LLM does not need.

[Next page](https://fortran-lang.discourse.group/t/modern-language-design-and-the-battle-for-ai-dominance/11105.md?page=2)