There's actually a wealth of literature on defining levels of software automation (such as: https://doi.org/10.1016/j.apergo.2015.09.013).

That is, the architectures of today are chosen to yield the best results given the textual data around today and the problems we want to solve today.

I'd argue that this lack of bias would need to be researched (if it hasn't been already) before this kind of model has credence.

LLMs aren't my area of expertise but during my PhD we were able to encode a lot of a priori knowledge through the design of neural network architectures.

For someone to shake these bad practices, they need to fight an uphill battle and ultimately sacrifice their research time so that others will have an easier time understanding and using their codes. Another battle that people trying to write "good" code would need to fight is that a lot of academics aren't interested in programming and see coding as simply as means to an end to solve a specific problem.

Also, another bad practice few bad practices to add to the list:

* Not writing documentation.

* Copying, cutting, pasting and commenting out lines of code in lieu of version control.

* Not understanding the programming language their using and spending time solving problems that the language has a built in solution for.

This is at least based on my own experience as a PhD student in numerical methods working with Engineers, Physicists, Biologists and Mathematicians.

The former boils down to, there's little point saving time in the writing of new code when new versions of the language hinder the use of old codes. Julia, being a very young language, simply does not have the legacy of backwards compatibility that Fortran has and as a result libraries written today are unlikely to work in 10 years time. Partly because of Julia's age and partly because backwards compatibility is not valued as much as it is in Fortran. The GNU Fortran compiler can still compile code written nearly 50 years ago (https://gcc.gnu.org/fortran/).

The second point is that benchmarks like this seem to focus on tuned implementations, which is really important, but another important aspect is how easy is it write fast code. With Fortran, it is very easy to write very fast code as a lot is abstracted away from the programmer so they can focus on FORmula TRANslation. My experience with Julia has not been the same and thus for people don't have the time to perform such optimisations, Fortran may still be the better choice.

I do look forward to watching the development of Julia but for now I'll stick with using Fortran as the high performance numerical language in my tech stack.

I'll finish with something I've read but I can't remember from where:

Over the years there have been many examples of "X with replace Fortran" and the only thing that ends up getting replaced is X.

For a comparison on array indexing in different programming languages see here: https://en.wikipedia.org/wiki/Comparison_of_programming_lang...

From personal experience, I wouldn't let something as simple as starting index getting in the way of programming for a language as you'll soon start automatically switching to thinking in 1 based and 0 based indexing depending on the programming language.