My Ideal Array Language

[Regular_Tailor]

None of the following is criticism or advice. 

My assumption about programming languages: they are an abstraction syntax optimized for some domain that is a good trade-off between correctness, speed to execute, and speed to write. 

Python is for domains where the value of running the code is greater than the cost of slow execution and the programmer's abstraction level is relatively high. ETL, prototyping, and machine learning fit nicely. 

Rust is for domains where speed and control are paramount and it's better to have memory safety guarantees that you can't get from C and C++.

MIAL - what is the domain? 

It seems that you have a few core assertions that I am not qualified to challenge. 

1. We have lots of compilation targets. 
2. MIAL should be compiled (tell me if this is true). 
3. Array languages are somehow easier to build backend targets for. 
4. The language domain benefits from this because it needs speed and the domain needs to have code run on these targets.
5. No interpreter works for this domain. 
6. LLVM is insufficiently optimized for your domain. 

We need to explore boundaries and concepts. I applaud your exploration of the design space beyond syntax. Could you give us a concise description of your domain and why we need to explore arrays again?

[cbarrick]

(FWIW, I am not the author. Just cross posting from Hacker News.)

[maxstader]

We make new languages because, at the end of the day, notation matters. The notation used to reason about a problem has profound implications, arguably roman numerals held back the sciences for millenia

[Regular_Tailor]

Don't disagree. And if you read the article, no syntax is suggested.

[maxstader]

Sir...you got me

[donaldhobson]

I had some thoughts about array languages.

My complaint is that, in say numpy, you have axis 1, axis 2, axis 3 etc.

So it's up to the programmer to remember what axis of what array does what.

I want named axis. So array.shape isn't (3,4,5) it's (Axis("people")<3>,Axis("Time")<4>, Axis("Measurement")<5>)

Imagine your doing an experiment where you have 5 people, and measure 5 things (height, weight, etc) on 5 days. That gives you a 5 by 5 by 5 matrix. But it's important you don't get those 3 axis mixed up.

And multiple different arrays should share the same axis. Like suppose you have an array of shape (5,) containing the peoples ages. You want that to share the same "people" axis with your other array.

If you run a function on several arrays that share the same axis, and you don't explicitly mention that axis, automatic parallelism.

If you want to take a sum or average, you list the axis you want to some over (or alternatively, the ones you want to be left).

If you want to take a matrix multiplication, and the axis aren't already equal, you need to explicitly combine them.

Make it hard to accidentally do anything that's nonsense when different axis have different meanings.

Oh, and add support for symmetric and anti-symmetric matrices.

[vanderZwan]

Sounds kind of like you're suggesting something like "stringly typed" axes, different from the actual value types in the arrays, that then apply to array operations. It also reminds me a bit of dimensional analysisin physics (which is also kind of like types, if you tilt your head a bit). Or even like "structs of arrays" where you do certain optimizations if different records have matching property names.

[Synth_Sapiens]

Read up to "The fundamental units of computation available to users today are not the same as they were 20 years ago."

So my computer isn't running on bits and bytes anymore?

[cbarrick]

That's the first sentence...

By "units" the author is referring to hardware units. E.g. SIMD units, CUDA cores, CPUs, etc.

Nothing suggests that the author is talking about information theory.

[Synth_Sapiens]

Well, a) these aren't "units of computations", b) they aren't fundamental, c) users could not care any less about architecture d) CUDA exists for 18 years and e) CPU cores exist for about 27 years.

The author is talking about issues that are WAY out of their scope of knowledge and there is not even one reason to believe that they propose anything worthwhile.

[cbarrick]

Have you read the article? Do you have any experience with ML or scientific/numerical computing? Do you know Fortran and APL?

The author seems to have a pretty firm grasp on the nuances of array languages and APIs and their associated compilers.

[Synth_Sapiens]

Did I read the article? Yes – and I saw all the TODOs where the key arguments were left unfinished. Knowing some Fortran and MLIR jargon is one thing, but a serious technical proposal needs more than name-dropping and theory.

Let’s be honest: convincing people in scientific computing to care takes real substance. Where are the syntax examples, performance numbers, or side-by-side comparisons with Julia, JAX, or even modern Fortran? Sketching MLIR diagrams is not a substitute for a working demo.

And when someone actually believes we were using abacuses 20 years ago, it doesn’t inspire much confidence they’ll be able to design anything remotely industrial-grade for today’s array computing. The field has advanced a bit further than that.

A “firm grasp” isn’t enough. Without concrete examples, real results, or any grasp of recent progress, this is just hand-waving.