>Why aren't we all writing in APL/K/J if it matters that much?
In all seriousness I think writing more code in APL would probably cut down on bugs, but array-oriented languages are so far beyond how most programmers think about programming, and look so obscure, that I don't think there's any hope of them seeing widespread adoption. Most people loathe point-free Haskell, so I can only imagine what they'd think of the APL family.
Not really; a direct descendent of APL is very widely used, and it's called Numpy. It's just that array-orientation, while great (especially for numerics), is insufficiently general to comfortably express arbitrary algorithms. You can write "APL" in many modern languages, but people still prefer to use traditional control flow for many purposes; hell, even APL provides this "escape hatch" (though it looks bolted-on).
Numpy is definitely not as powerful (read: concise) as APL, and you really can’t write “APL” in most modern languages. The operators are rank-polymorphic, for one.
Well I've had a few lesson in APL a long time ago and what I remember is that APL is a write-only language.
So I doubt that it would 'cut down on bugs'
>Well I've had a few lesson in APL a long time ago and what I remember is that APL is a write-only language.
This is not how everyone who writes APL feels about it. It is recognized that it takes quite a while to really internalize how the operators work and compose, though. One advantage of APL stated by Aaron Hsu is that because the code is so small, if you find it confusing, you get in the habit of rewriting it frequently, and at least for him, it gets clearer over time. I have only dabbled myself (Primarily an OCaml and Elixir/Erlang programmer), but what understanding I have about empirical studies of software engineering suggests lines of code is more or less the only consistent predictor of defect count.
It becomes less "write-only" as you build up experience. It's just not as readily learnable (if you're already a programmer) as most other languages. I mean, procedural and OO languages seem to have largely adopted a variation of Algol or C syntax with roughly comparable semantics to others in the same family. A programmer in C, Java, JavaScript, Fortran, Ada, Pascal, Go, Rust, Python, Ruby, etc. can mostly jump to the others and be able to at least read the program without much difficulty, though learning to write and extend the program (especially idiomatically) will take more time.
APL's syntax and semantics are much different so it has a larger barrier for getting to the level of reading or extending programs written in it, but it's not impossible to reach that level with a bit of practice. I spent a few months doing APL for 2-3 hours a week in the evenings and I was able to develop a reasonable level of competence in it (though not so much I'd drop it on my CV), I can still read it pretty easily now a couple years later and without really touching it since then.
In all seriousness I think writing more code in APL would probably cut down on bugs, but array-oriented languages are so far beyond how most programmers think about programming, and look so obscure, that I don't think there's any hope of them seeing widespread adoption. Most people loathe point-free Haskell, so I can only imagine what they'd think of the APL family.