The Array Cast – A podcast about the array programming languages

If you want a "more readable" array language, take a look at Nial.

PS: qualifying the Wolfram language (Mathematica) as obscure is a really, really myopic view of the programming world.

Yes, to you. Just like Chinese would be infinitely less readable to you, if you don't know Chinese.

Do you think this is a deep observation?

The real challenge is knowing whether it is worth it to learn k so that it becomes readable.

- How many characters is it? This is a useful metric when you realise bug/defect rate is proportional to the physical size (in rows and columns of source code) of a program given equivalent processes (Moore 1992; McConnell 1993) but that process matters more than anything else. Not tooling, not "memory safety", and certainly not "readability" by people unfamiliar with the language.

However "readable" you think your rust code is, did you notice the bug in your rust code? (hint: input is not supposed to be mutable)

- How fast is it? On my 2014 i7 macbook air, the supplied us averages 232 msec for 100k cycles. My version

    us:{$[x~(z;y);,"_";y]}[(*K;,"*")]':

- How quickly was it written? I can't speak for sa/atw on us since I didn't see them write it. I wrote mine in about 30 seconds including testing. Yes really. How long did your rust program take to write? Did you think simply because you thought you understood the requirements that you didn't need to test it?

- How quickly can someone familiar with the language read it? Again, I can't speak for anyone other than myself, but I'm not a k expert -- I program in it very infrequently, and the new amend-syntax in k9 I had not run across previously. And yet I read it as quickly as I said.

These four values (less code, fast run, fast write, fast read) are the biggest most important things to me. And anyone who shows me all four of things will get my attention.

Rust? Simply does not impress.

> Unreadable array languages are popular with quants because they work in a highly competitive, cut-throat industry where "write only" languages provide job security.

That's another interesting opinion. This one might even be true amongst some quants (Most of the ones I know that use k don't particularly like k). But I suggest you try not to expect the worst in people. Yes, some people are assholes, but most people aren't. And for what it's worth, I'm not a quant (I work in Advertising).

You would not be the first person tempted to try and separate the two, but I think it is impossible. Every attempt to do so I have ever seen has lost too much in the translation that the four-values I have for programming are no longer conserved.

If we had such objective metrics on APL or K, that would be an interesting discussion. But what I've seen here is just opinion and anecdote.

I also think that "looks like line noise" is a fair characterization of how J and K look on the surface, but that does not mean they are unreadable.

I'm hardly qualified to give any deep insight, but after reading the first half of Aaron Hsu's thesis and playing around with a Dyalog APL interpreter online for a few days, APL starts to look quite readable to me (much more so than J, thanks to the additional symbols) and I found it rather easy to learn (unlike mathematics, but for me the struggle there is not at all in syntax but in the concepts, methods, and meaning).

Listen: I don't think you're qualified to speak to the essence of a thing that you don't understand, and I think you know that. I am telling you this is not very difficult and it is very useful, and I think you're angry at yourself for not "getting it". You are so smart you know ten programming languages, so you assume there's something wrong with "it" because to think there's something wrong with you is unthinkable.

Relax. There's nothing wrong with you either. You can learn this, but you aren't going to be able to skim it; the knowledge you have gained learning ten other languages is not going to help you very much. What is going on is stranger than you can realise at this point, so many array-people believe it is easiest if you try to forget everything you know about programming when you try to learn an array language. I don't think I agree with that, but the myth that children learn languages faster than adults is pervasive. Maybe that helps.

> Geocar wrote about two pages to explain what is a trivial piece of code, and I still have no idea what it even does or how!

Try reading it again! It is not complicated (nor optimal) but you are likely skimming or skipping important parts. If you can tell me where I lost you, I can probably help you find your way.

You might find it easier to follow along with a k reference guide. These typically fit on a note-card and can be helpful in memorising the k operators. These are all of the operators in the above program:

    $[a;b;c] cond (if a then b else c)
    @[a;i;f] amend i indices in a with operation f

    &x where (are the 1-bits in x)
    #x count (the length of x)
    *x first (element of X)

    x&y min/and
    x~y atom-equivalent (like lisp's equalp)

    f':x call f with each pair of x

> Is it possible to develop an array-based language and use more "normal" syntax?

"Array-based" isn't exactly the same thing as an "array" language - I think people get too hung up on the power of vector-operators (which are indeed powerful!) and miss the fact that there are so few operators which to learn.

I don't expect you to understand exactly what I mean by that, but I hope that if you take the plunge to learn this properly, you'll remember that I said this and when it does make sense, it will be useful.

> Array based languages are the first time I've seen a high-level language that is less readable than the machine code that they are supposed to be abstracting away!

You can't read Arabic either, can you? Why do you think this is different?

Try to stop thinking in terms of "readable": You can only say something is "readable" to you, or perhaps if you are a hiring manager, "to most people". I can read it perfectly fine. Worrying about how "readable" a programming language at this point speaks only to how easy it is for you to acquire the ability to learn it, not how valuable it will be when you actually learn it.