1. Array languages aren't well suited to *every* problem.
   2. They *are* ridiculously capable for many types of problem.
   3. The people using array languages are generally insanely smart.
   4. Learning how array languages work is a steep challenge. As shown in the linked article, it's possible to write "procedural" code in an array language, and that is a Very Bad Thing. It's like using a screwdriver as a hammer.
   5. In particular, understanding how tacit programming works is an awesome mind-expander
   6. Likewise when you internalize verb trains
   7. Likewise when you realize how array-based languages handle *any* dimension array.
   8. Likewise when you comprehend how "under" works
   9. Likewise when you understand how function exponents work

Also, have to shout out the APL Orchard, where Adám will give any visitor a personal tutorial: https://chat.stackexchange.com/rooms/52405/the-apl-orchard

The reason to do this is that it allows one function to do more things. As you guessed, the matmul function from the tutorial works if the right argument has rank 1 or more, which means it also does matrix-vector products. Less code is another form of safety, the theory goes. And handling more things with the same function also lets you draw higher-level connections.

Of course you can type the arrays anyway. Remora is one attempt. To me it feels like just a technical exercise and I think this question calls for more high-level investigation of what exactly the goals are before jumping into PL theory details.

EDIT: Tali Beynon's rainbow arrays don't have all the answers, but I think they're a good example of the sort of investigation I mean: https://math.tali.link/classical-array-algebra/

  val matmul : ((float,'a) fixed_length, 'b) fixed_length -> ((float,'c) fixed_length, 'a) fixed_length -> ((float,'c) fixed_length, 'b) fixed_length

  val compose : ('a -> 'b) -> ('c -> 'a) -> ('c -> 'b)

I think the problems are more things like:

- that type only works on matrices, you can’t so easily express that eg * in APL works on two scalars, or two vectors of the same length, or a matrix and a rank-3 array so long as their dimensions line up appropriately.

- handling operations that change lengths is hard: concat probably wants you to be able to unify through certain arithmetical expressions, and the filter operation (take an vector and a bitvector the same length, and produce the vector of elements where the bit was set) means you probably want a natural way to handle those kinds of existential types for lengths: you get a vector, and it has a length, but you’re not sure what it is.

Do a search for "haskell strongly typed tensor programming."

"Multidimensional arrays inspired by APL"

Grab python+numpy or matlab/octave - it's all the same stuff (likely inspired by K) but with readable syntax, bigger community and so on.

As a great example, look at old computers: they are pretty popular (there is one link on HN front page right now about N64!) and people are super passionate about it, and yet you would not recommend "everyone to play at least one Nintendo 64 game".

For non-computer examples, somehow a number of my friends are extremely passionate about super hot (as in spicy) sauces. They bring a new bottle for every meal, and they can talk about the kinds of peppers for hours. It's interesting to hear, but I would not want to try them myself, nor would I recommend this to everyone.

can't resist ...

de gustibus ...

https://en.m.wikipedia.org/wiki/De_gustibus_non_est_disputan...

oops, double pun there ;)

> Learning array languages makes you a better programmer in any other language. The way you think changes. We are taught to approach a problem procedurally. Actually the for loop is your enemy.

I happen to strongly agree with most of this: learning array-based "operations", writing the code where "the for loop is your enemy" is a very valuable experience, and if will make you a better programmer in any language. Everyone should try writing some code like this.

The problem is K is a mix of three things: array-based operations, point-free style / tacit programming, and extreme brevity via punctuation abuse and lack of types. And not all of them are equally useful.

It's like trying to introduce someone to Chinese cuisine and giving them the spiciest Hunan dish there is. Unless the person already happened to love spicy food, the chances they will just write-off the entire cuisine.

I bet there people today who associate "array programming" with obscure character soup of APL/J/K and ignore it because of that. Who knows, maybe if they knew that numpy/octave offers the same thing in more palatable package, there would be more arrays and less "for" loops in the world.

As far as I can tell (correct me if I'm wrong) you haven't learned an array language, yet you're telling someone who has (and anyone else who reads your message) not to bother.

To use your food analogy, this is like saying "Don't try real Chinese food in a restaurant, just cook some rice at home. Same thing."

It's not the same thing. The flavour is completely different.

The APL/J/K and Python + Library philosophies for programming are super different and if this doesn't make sense to you, I'd recommend downloading Dyalog (it's free to play around with) and go through some tutorials and see if you still feel the same way.

Yes it's all programming like how rice and french fries are both food. They're both awesome too. With Python you have a general purpose language that lets you build up a matrix in a manner you're used to. You've then got an object you call methods on to delete columns or update an entry or whatever. With APL, you've got what is like a hyper optimized DSL for doing that. I'm a lot more proficient with the Python option and it's both popular and free, so it's probably the only option I'll ever have to use at work. Using the APL/J/K options are a ton of fun and I think I could get hyper efficient with them as well given the time. Using the APL is so alien compared to what I'm used to though. The idioms (e.g. ohh you want to do that...just use an outer product which is these two characters combined) are just so different than how I'd typically think about solving the problem (e.g. I'd use a nested couple of for loops or whatever). It really does change the way you think.

Off topic: I work with a lot of extremely large sparse matrices though (like 40,000 x 40,000 with most being 0s), so I'm not sure if APL is as optimized here and as a result it's also easier to stick to Python.

Including negative exponents, namely automated computation of the inverse function!

Deserves to be ranked higher, especially for the "blub" programmer. With specific examples. I not-so-recently saw an implentation of euler's method that replaced the ODE solvers of MATLAB for pegagogical reasons. I return to it when I want to think about generalizing in that way.

In college, they were teaching assembly language (IBM/370) and Fortran. I dabbled with the APL interpreter on the mainframe, but had little time to do more. There just wasn't any support/community around APL on campus (that I was aware of). Nevertheless, I'm still very fond of APL.

>1. Array languages aren't well suited to every problem.

No language is suited to every problem?

>2. They are ridiculously capable for many types of problem.

Irrelevant? It only matters if it is more capable than other languages.

>3. The people using array languages are generally insanely smart.

Folklore. Impossible to quantify. Most of all, there are really smart people using all languages.

>4. Learning how array languages work is a steep challenge.

This is not persuasive.

>5. It’s awesomely mind expanding.

Like philosophy and psychedelics? People care about GTD.

Seriously, I’m listening. What’s the real competitive, objective, case for k?

Interviewers know to hire/no-hire within first 10 minutes of talking to candidates.

Similarly, the best LLMs nowadays are probed only with some prompts.

Just last time I see LLM midwit meme on quantifying best scores on all benchmarks vs idiots/geniuses who just prompt something for some while.

Do not try to put numbers on everything.

I said it was impossible to quantify, not that it should be quantified.

In general I just don’t think it’s a reason to decide on a programming language.

He has also written many comments (arcfide on HN) about this stuff before, e.g. discussing "semantic density" [1]

> The compiler is designed so that I can see as much as possible with as little indirection as possible, so that when I see a piece of code I not only know how it works in complete detail, but how it connects to the world around it, and every single dependency related to it in basically one single half screen full of code (usually much less than that) without any jumps, paging, scrolling or any movement. [...] The idea of semantic density is critical to this point. The semantic density of the APL code I'm using to solve the problem is at a certain rate. I maintain a consistent density rate by choosing my variable names in such a way that they visually align with the expressivity per character of the built in primitive symbols.

And

> [...] idiomatic programming methods that are so concise, they can begin to be read as we read and chunk English phrases. By doing so, it becomes actually easier to just write out most algorithms, because the normal name for such an algorithm is basically as long as the algorithm itself written out. This means that I start to learn to chunk idioms as phrases and can read code directly, without the cost of name lookup indirection. I can get away with this because I've made reusability and abstraction less important (vastly so) because I can literally see every use case of every idiom on the screen at the same time. It literally would take more time to write the reusable abstraction than it would to just replace the idiomatic code in every place.

[0] https://github.com/Co-dfns/Co-dfns

[1] https://news.ycombinator.com/item?id=13571159

That is not good code, sorry. His average variable name length is about 2.5. He can't "literally see every use case of every idiom". He's fooling himself, seemingly convinced by his own brilliance. He:

- Brags about using Notepad instead of the fancy IDEs that us weak-minded plebians use

- Brags about how easily he understands his giant ball of overly messy code (2- letter variables in the name of "semantic density")

- Uses an obscure (in the modern era) outdated language like some Cinema aficionado who refuses to watch movies in color like all those plebians

- Publishes articles in journals that everyone else in our industry would just write as blog posts

- Brags about how he can understand his own code. We can all understand our own code. Good code is understandable by others.

Any one of these alone wouldn't be that weird, but taken together it sure seems like he's optimizing for self-promotion and feeling infinitely superior to all us mere mortal programmers.

[0] https://mlochbaum.github.io/BQN/implementation/codfns.html#i...

@arcfide left one of my favorite comments ever, in response to another comment similar to yours (for which the author apologized). I refer to this often.

https://news.ycombinator.com/item?id=13571159

Just a couple of snippets:

“Don't complain that Chinese is ugly and unreadable just because you speak English as your native tongue.”

“The cost for replacing or deleting code should be as low as possible.”

“How can I get a code base that has more features but continues to shrink? By chasing smaller code. :-)”

The analogy here slightly breaks down since there are billions of people who speak and read Chinese already, while apparently the coding style in question is more of a niche thing trying to justify itself.

I don't know enough about APL or using 2-letter variables to comment on whether they're actually justified, but my personal hunch is that their usefulness is going to be limited to particular problem domains and people with particular inclinations. (The same goes for verbosity on the other extreme like particular Java projects...)

He's also built the world's first APL compiler which runs on a GPU and outputs GPU code.

> - Brags about using Notepad instead of the fancy IDEs that us weak-minded plebians use

One of his points is that he's convinced programming as an industry went wrong by sidelining array languages, and we shouldn't need to be writing so much code to get things done. It's not so much bragging about using Notepad, as making a point that a) Notepad is enough for a complex piece of code, b) IDEs can't help much with tacit array code because there isn't tons of boilerplate to autocomplete, and c) concentrating on the code is easier without a lot of distractions.

> - Brags about how he can understand his own code. We can all understand our own code. Good code is understandable by others.

Another one of his points is that people who have not learned traditional programming find array-based programming much easier to pick up. And that's aside from the usual discussions here where you're basically saying "Brags about understanding Chinese. We can all understand our own native language, Good writing is written in English". Other people have contributed pull requests to co-dfns (apparently).

> - Brags about how easily he understands his giant ball of overly messy code

Given your previous criticism is that it's "not understandable", emphasising how it not only is understandable it's quite easy to understand, seems like a reasonable rebuttal for him to make. Apparently he's damned if he does, and damned if he doesn't.

> - (2- letter variables in the name of "semantic density")

That is the array style; his compiler is tacit (no variables) as much as he can make it, which means the few variables which are left are much easier to keep track of in memory. Regardless of that, there's a big gap between languages where people write 'k[i]=m[j]uv' and languages where people write 'pyramidPointVector[pyramidPointVectorOffset]=adjustedShadowMaskBools[rowAlignmentCounter]...' or whatever.

> - Uses an obscure (in the modern era) outdated language like some Cinema aficionado who refuses to watch movies in color like all those plebians

But also like someone who uses any highly specific tool for experts instead of the standard thing an ordinary person might find at Walmart.

I have had the same experience when teaching SQL.

I feel like it is difficult for people who have worked with imperative languages to grasp, while people who come from the Excel school (e.g. business people or researchers) actually enjoy it and may even pick it up faster.

I believe SQL and array languages have this and probably much more in common. I am probably out of my league here, but I think I'd call SQL a set language rather than array language. But feels like they are related.

I am thinking about map/reduce types of jobs.

Is that something you have solved?

The Array Cast https://www.arraycast.com/episodes/

RSS address: https://www.arraycast.com/episodes?format=rss

They downplayed the terseness and non-ASCII symbols of the array languages as something you get used to and something that's worth it to get the benefits of array languages, but the benefits they listed were mostly ones that I'm already very familiar with from working with higher-order functions in most mainstream languages today.

It felt like the hosts had missed that map/filter/reduce have gone mainstream and are now available ~everywhere without having to learn a whole logographic writing system first.

However I still find them useful (and fun!) because of the terseness, not in spite of it. Terseness means array languages are very mathematical in nature + can be really ergonomic to write, especially with the repl. If someone said "learn an array language, they're easy to write on paper" everyone would think they were insane... but there is something to it, in certain cases. The idea of "fearless refactoring" is popular in the FP world, but it can also be true in the array language world too.

Indeed, and sometimes not needing a computer to quickly splash out an idea you're thinking/talking about is extremely useful!

Over Christmas, I showed my brother {+⌿⍤2(∘.≤)⍤1⍨⍵} as a small expression to explore attribute to pick playing Top-Trumps admist a discussion. Not something you'd be able to do in many other languages!

  {+⌿⍤2(∘.≤)⍤1⍨⍵}

  {            ⍵} ⍝ single argument (monadic) function with argument ⍵
  {           ⍨⍵} ⍝ "selfie" - ⍵ f ⍵ where f is (∘.≤)⍤1
  {         ⍤1⍨⍵} ⍝ on each row (1 dimensional element)
  {    (∘. )⍤1⍨⍵} ⍝ cartesian (outer) product of each row with itself
  {    (∘.≤)⍤1⍨⍵} ⍝ ≤ comparison of those elements - produces 6 30×30 boolean matrices
  {  ⍤2(∘.≤)⍤1⍨⍵} ⍝ on each of those matricies (2 dimensional element)
  {+⌿⍤2(∘.≤)⍤1⍨⍵} ⍝ sum the columns

That make sense?

So, usage would be something like:

CardPower ← {+⌿⍤2(∘.≤)⍤1⍨⍵}

CardPower cardMatrix

It also makes differences stand out so logic bugs are more visually obvious.

Understanding that your logic bug is obviously somewhere within a handful of lines of K/Q/etc that fit neatly on a single screen vs scrolling through 200 lines of logic in Python/Java/whatever is focussing.

Sure each line is more compact and may take more time to digest, but that is a reasonable trade-off in most cases.

For me, 10 lines you need to read carefully beats 100 lines of having your eyes glaze over and repeatedly skip over the bug because you are so dulled to all the boilerplate.

However the most popular professional style of Haskell code is far too verbose for me to be able to "see the essence" in many cases without a round of refactoring.

Its far worse and far more grating for Java code that makes you do so much for so little.

Still, there is a fun about a desk calculator on so many steroids that it's a Turing-complete programming language. One of the ArrayCast podcast guests said array languages were "like a Domain Specific Language (DSL) with an enormously wide domain". How many mainstream languages will let you fork and hook and have inverses and over and under and recursively descend into anonymous functions, without ceremony or boilerplate code? You could have that now to play with, without waiting for it to go mainstream, just by learning a two or three dozen unfamiliar glyphs - compare that to the effort of learning a whole new framework for making web applications and it's much smaller.

Other languages support regex for example, but perl takes it to a different level that changes the language experience.

Haskell is so much better at this, being completely pure and typed throughout, and is even more fun and powerful than APL; I've used it to write a lot of small and medium-sized projects, prototype LLVM Flang's parser to prove the concept of using parser combinators for Fortran, and do Advent of Code each year in a few hundred lines of code total. If you like APL, try Haskell.

Today, I think that the whole "notation as a tool of thought" aspect of APL is a rationalization for excessive brevity -- which can be a good way to demonstrate the power of composition, but which can work against clarity.

- Verbs are algorithms. Imperative and object-oriented languages require the implementation of common algorithms (e.g. find, sort, and group).

- A sequence of verbs (or adverbs) is the most direct form of composition I've ever used. Composition is easy and fluent.

- Programs are the composition of algorithms and not a collection of statements & expressions.

- The concept of domain and range treated uniformly across arrays, maps, and functions simplifies my design choices.

- Left of right evaluation means that my eyes don't have to "jump around" when reading code.

- Sending code to data is possible & preferred. Most of my significant k projects fit in a network MTU (i.e. 1540 bytes), not including comments.

K bonus:

- Views (i.e. dependencies) can implement functional relationships directly.

- Hot code (via the interpreter) loading makes "forever" applications possible.

(to be clear, this is in the general case where you don't know exactly what P is. for the specific problem of finding primes smaller than N, you could obviously use sieves and stuff, but i'm more curious about the general pattern of problems like this)

Having only had limited exposure to array languages, my understanding is that in general the way to do that would be to do something like:

1. Generate an array from 1 to N

2. Test the array against the predicate, getting a new array with 0s and 1s (a mask, essentially)

3. Apply that mask to the array to get only elements where the predicate is true

Which is all fine, and I imagine that it takes a stupendously small amount of characters to do this. But my question is: what if N is large, and the predicate isn't true very often? Like, what if N is a billion or something? This is not an issue in the imperative/functional cases, because they don't have to generate the array in step 1, they can just loop/recurse/lazily generate the values (i.e. memory is O(1) for this). But it seems extraordinarily wasteful in array languages both of memory and resources to generate two different billion element arrays (the 1..N array and the mask) just to get out a handful of values.

That question is pretty specific, but this is one of my biggest questions about array languages in general. Aren't you always generating TONS of temporary arrays for no real reason, that will just pass through the calculation? Isn't that really slow? Or does the implementation somehow optimize this stuff away, maybe by using something like lazy evaluation?

Scalar languages have a different problem: the default is to process one value at a time, which wastes the potential parallelism that array languages take advantage of with SIMD algorithms. Because this is the status quo, it's not as easy to see this as a big concern. And the solution is also blocking. That is, the best algorithm for SIMD-friendly stuff is generally a blocked array method.

In practice, whether an array language is good or not really depends on the specific problem. Of course, for most practical uses performance doesn't matter at all; I believe k's reputation mostly comes from kdb being fast as a database rather than k implementations being fast languages. But array languages can be surprisingly fast just by focusing on elegant array algorithms rather than machine-specific considerations. I have comments and benchmarks comparing with C here:

https://mlochbaum.github.io/BQN/implementation/versusc.html

Languages that can stay in L1 cache for the duration of a computation will run circles around a language that explicitly computes and stores all intermediate values in full.

Also, array-based languages can easily hit the wall of system memory capacity whereas traditional code tends to be streaming and can handle unbounded input lengths.

Then there's the slightly simpler option of splitting the operation in chunks of a couple dozen kilobytes of input/output arrays such that unnecessary temporary memory usage is bounded; as far as I know no array language does this, but I hope to one day do something like this for CBQN. And this is even a thing that a user can manually do in an array language (and indeed often have to for maximizing perf).

[0]: https://aplwiki.com/wiki/KAP

Close, they are called "idioms".

> +|x

The plus should be an asterisk, but yes, that is an idiom the ngn/k interpreter recognizes.

If the necessary temporary arrays are really huge, array programmers will just do the computation in chunks that fit comfortably in memory.

It's of course possible to do it in a different way to deal with that issues but those solutions can be a bit longer and less pretty.

The APL dialect I'm working on (Kap) solves this problem in many cases by delaying the computation until the result is needed, which means that you can write the code using the straightforward approach but still avoid computing results that will be thrown away.

My question is: will J cleverly optimize away the i.1000 array? Is it lazily generated, like in Haskell? Or is this just one of those "we don't really care about the memory of the i.1000 array, it's usually small in practice"? Like, for high performance stuff, it seems relevant to me that you spend an extra O(n) memory for no real reason.

That may or may not be prime? And you want to know how many are prime? (Let me know if I am wrong)

1. Pick the highest number, H in the arbitrary list of 1000 numbers.

2. Generate all prime numbers up to the highest number, H.

3. Use e., Verb also known as member of to check for prime numbers present in arbitrary list. +/(all prime numbers up to H e. arbitrary list of 1000 numbers) will give you the number of items in the arbitrary list that are prime.

> will J cleverly optimize away the i.1000 array?

The primitives & verbs in array languages are designed to be as fast and efficient as possible.

So even if your code is mediocre, it will perform better that any mediocre imperative code.

You're right, but it's not just codegolf; ideally the few characters are a clean high level way to express intent - and that is in tension with caring how a machine executes the algorithm most quickly.

> "This is not an issue in the imperative/functional cases, because they don't have to generate the array in step 1, they can just loop/recurse/lazily generate the values (i.e. memory is O(1) for this)"

It kind of is the same problem, just pushed down a level or two; writing it casually in Python will not get you the fastest performance, you should be working in C or you're wasting a lot of potential running the Python layer, then care about how you can parallelize the computation or you're wasting 7/8ths of an 8-core processor, then caring how you can make best use of the CPU SIMD instructions or you're wasting another half or more of the machine potential, caring about branch predictors, and caches, etc. That a loop written in Python is "not wasteful" but materializing a large array "is wasteful" is where the industry draws a fairly arbitrary line. The ArrayCast podcast episode 52 touches on this[1], me cutting/editing some relevant parts from the transcript; [ML] is Marshall Lochbaum who did performance optimizing work on Dyalog APL and designs/implements the BQN array language, and [CH] is Conor Hoekstra who hosts the podcast and works in nVidia research:

> ML: "using linear memory is just how array languages work. For any problem, pretty much, you're going to have to make a bunch of new arrays."

> CH: "there could be an array language that avoids [materializing] arrays when possible."

> ML: "it's going very much against the grain of the language to say, "All right, I've specified my answer in these high-level array terms, and now I want you to turn it into a C program for me"."

> ML: "it's still nice to specify a problem this way, but this array form for specifying gives you some pretty big advantages. [...] if you try to pack that all into a big iteration, your algorithm is no longer expressed as an array operation - and these array operations are things that we know how to do really quickly. You are giving up some performance information if you tell it, well, yes, I'm in an array language, but don't actually make me any arrays."

> CH: "my dream is that I want to be able to write like the most expressive solutions to problems and then have [the array language implementation] do the most performant thing. Like for Kadane's [algorithm], for example, the most performant thing is to hand roll that reduction yourself. It's going to be faster than materialize."

> ML: "I'm not convinced of that"

> CH: [where I work we have to optimize for teams working on large problems, recently had a discussion where 2 billion items is a small number]

> ML: "2 billion /is/ a small number"

> ML: "what you can do, even when you have an array algorithm, you can split it into to smaller arrays. this is often a lot better because you get to use vector operations with these. So for Kadane's algorithm in particular, I don't know how to express that purely with vector operations, but I think there probably is a way. And in that case, if you write it in C style, where you interleave scan and reduction, then it's much harder to go from that to a vectorized algorithm which (if it exists) would almost definitely be the fastest way. The way you would get the array thing to be cache friendly is that you run it blocks. And then within a block, it's doing a bunch of vector operations, but what you really want is like, you know, working on two vector registers, say at a time. the array language doesn't automatically chunk, but it's not that hard"

> ML: "Yeah, and I think the way for the implementation to get the best [performance] - maybe not with this particular problem - but definitely for things that are friendlier to arrays where you don't have any compound functions inside scans. The way to optimize those is not to immediately break it down into a series of scalar operations, but instead to be more careful and start with your whole array stuff and break that as necessary, and maybe even compile these array operations into operations of individual registers, which is hard. Nobody's really done that, but coming from the other side, from C, there have been who knows how many man hours poured into work on auto vectorization. And it's still pretty terrible. It would have absolutely no chance of handling something like Kadane's algorithm."

> ML: "getting the best implementation of an idea is pretty difficult. But I think actually starting from an array representation, you do have a pretty good chance without going through a C style scalar representation first."

That's edited parts from a longer chat; but yes if you want to write X algorithm without wasting machine resources, that's a hard problem and takes a lot of low level C/SIMD/CPU skills and time. Array languages can vector-accelerate the primitives of array symbols much easier than C compilers can identify vector-accelerate arbitrary looping code.

You can read more interesting things about the implementing of BQN and comparing with co-dfns and performance here: https://mlochbaum.github.io/BQN/implementation/codfns.html

[1] https://www.arraycast.com/episode-52-transcript - around 00:39:21*

Troels Henriksen (Futhark developer) pointed out to me that in expanding the state to make the scan associative I'd reinvented a fairly well-known method. The transformation from a specification as "maximum over the sums of each subarray" to the associative scan is very often used as an example of the power of the Bird-Meertens formalism or Squiggol[0], and some newer papers have demonstrated that it can be derived automatically, although not very quickly. Troels also wrote a simpler ISPC[1] implementation[2] that tested slower than C on an older CPU and faster on a newer one. Then I translated that to BQN and found it was about 4x slower than sequential C.

[0] https://en.wikipedia.org/wiki/Bird%E2%80%93Meertens_formalis...

[1] https://ispc.github.io/index.html

[2] https://gist.github.com/athas/f016084ea749602476b96c05ae415a...

I’m not sure it helps —- as a tool of thought —- to conceive every problem as a nesting of arrays. IMO, having freedom to produce data structures which capture your problem can greatly simplify the algorithmic part.

I think you do have to be smarter to use APL/J/K because of this bias: it’s often the case that a direct approach available in a more flexible language will not be available, and you have to transform the problem, which may require a lot more thought.

   dot =: +/ . *
   P =: 2 3 4
   Q =: 1 0 2
   P dot Q

    dot←+.×

    dot = (sum.) . zipWith (\*)
    p = [2, 3, 4]
    q = [1, 0, 2]
    p `dot` q

    P::[2 3 4]
    Q::[1 0 2]
    dot(P;Q)

https://pypi.org/project/klongpy/

You can also write P dot Q.

The syntax for matrix multiplication is shorter, but that’s only because there is a bunch of built in context you have to keep in your head about how the K language works.

I’d have to know a lot more and spend a lot of time before judging.

But I am not impressed seeing a single example. I could hypothetically write a language where mergesort is the operator * and reversing an array is the operator + and showcase how in my language 30 lines of code becomes 1. That would be insanely nice if you’re doing something which just requires thinking about sorting and reversing arrays but all together, very poor thing to build a standard language on.

> "That would be insanely nice if you’re doing something which just requires thinking about sorting and reversing arrays but all together, very poor thing to build a standard language on."

Prolog has linked lists as its main data structure, which means prepend is more performant than append. In the SWI Prolog documentation for foldl[1] it says "No implementation for a corresponding foldr is given. A foldr implementation would consist in first calling reverse/2 on each of the m input lists, then applying the appropriate foldl. This is actually more efficient than using a properly programmed-out recursive algorithm that cannot be tail-call optimized". i.e. you don't have to have a problem which involves reversing arrays, for reverse to be a useful part of a solution.

In APL reverse is one character ⌽. In C# to find the first comma in a string you use IndexOf(',') and to get the last one you use LastIndexOf(','). In APL you would use the equivalent of indexOf(Reverse(string)) and then you wouldn't need the specialised LastIndexOf - and wouldn't every other function which works from the left of a string or array to have an equivalent which works from the right. https://aplcart.info/ is a database of idioms and samples of useful APL and it has 168 pieces of code using ⌽.

[1] https://www.swi-prolog.org/pldoc/man?predicate=foldl/4

It's useful to play around with an array language until the paradigm clicks. Often, imperative code can be better handled in an array style. Sometimes long, fiddly functions can be greatly simplified if you use array operations instead or in conjunction with other styles.

Here's a Haskell example:

    (+)  Just 1  Just 2

    do x 

If I had something more complex, I'd prefer to factor that operation into functions small enough that the first variation makes sense over using the second.

This does trade "beginner+ can read this quickly" for "some beginners can read this".

I'm of the opinion you shouldn't optimize for "some beginners can read this" because of very diminishing returns.

Instead I aim for "beginner+ can read this" or in some cases "intermediate+ can read this".

Thinking in an array language - https://news.ycombinator.com/item?id=31377262 - May 2022 (66 comments)

EDIT: someone beat me to it in a comment further down or up the thread...

Array-oriented languages (or Vector-oriented languages, if you like) are generally distinguished by features like concise syntax, implicit conforming/mapping over homogenous collections, and a strong de-emphasis on explicit looping or recursion in favor of abstract (and often parallel) iteration.

Some of these features could be implemented- to an extent- in a Lisp, but they do not reflect normal Lisp programming style.

That being said, I really really like Array Languages for certain subsets of problems over anything else.

I kinda think every language and have an embedded Array Language engine, kinda like how Regex works so well for text processing.

Array languages try to get you to formulate your problem in terms of batch applications across whole vectors at a time, rather than piece by piece.

Which is actually potentially insanely faster on modern hardware where branches are expensive and we have special SIMD and/or vector hardware support.

Major dialects in the Lisp family are languages with built-in support for more than one kind of data type, not only lists.

a cool example is April (Array Programming Re-Imagined in Lisp), which runs on top of Common Lisp...

https://github.com/phantomics/april

One can see that the Lisp macro APRIL-F compiles APL-like code to Lisp.

  APRIL> (macroexpand '(april-f "3r4J9r5×⍳4"))
  (LET ((OUTPUT-STREAM *STANDARD-OUTPUT*))
    (DECLARE (IGNORABLE OUTPUT-STREAM))
    (SYMBOL-MACROLET ((INDEX-ORIGIN APRIL-WORKSPACE-COMMON::*INDEX-ORIGIN*)
                      (PRINT-PRECISION APRIL-WORKSPACE-COMMON::*PRINT-PRECISION*)
                      (COMPARISON-TOLERANCE
                       APRIL-WORKSPACE-COMMON::*COMPARISON-TOLERANCE*)
                      (DIVISION-METHOD APRIL-WORKSPACE-COMMON::*DIVISION-METHOD*)
                      (RNGS APRIL-WORKSPACE-COMMON::*RNGS*))
      (A-OUT (A-CALL (APL-FN-S ×) (A-CALL (APL-FN ⍳ INDEX-ORIGIN) 4) #C(3/4 9/5))
             :PRINT-PRECISION PRINT-PRECISION :PRINT-TO OUTPUT-STREAM)))
  T

  APRIL> (april-f "3r4J9r5×⍳4")
  3r4J9r5 3r2J18r5 9r4J27r5 3J36r5
  #(#C(3/4 9/5) #C(3/2 18/5) #C(9/4 27/5) #C(3 36/5))

  APRIL> (describe *)
  #(#C(3/4 9/5) #C(3/2 18/5) #C(9/4 27/5) #C(3 36/5))
    [simple-vector]

  Element-type: T
  Length: 4
  ; No value

Basic list operations might have a roughly-1:1 mapping to simple RVV loops, but many others still require a decent bit of extra code (all search functions (hash- or lookup tables), narrow matrix ops (processing multiple rows at a time); even compress operations get questionable when there's multiple of them due to their variable-length nature).

But the problem is not the terseness or the relevant clarity of any language or its ability to compile to fast code. It is the ability of any programmer who comes along later to make changes to that code in support of its use.

All too often, programmers want to show their [leet] skills and fail to take into consideration the poor sods who have to come after to support that code. The reality is that much [leet] code has to be discarded or completely rewritten to get something that is supportable long term.

It took me a long time to understand this and after this, I made sure that my code could be supported by others - clean, simple and comprehensible. Too much throwaway code becomes the basic infrastructure used in organisations and becomes entrenched and incomprehensible to following generations.