Thinking in an array language (2022)
github.com
github.com
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.
> "They could choose symbols that don't look so ugly next to each other,"
Not as easily as you might think, given all the Unicode symbols exist because they already have a meaning to someone, and many of those might not render in typical font which computers already have installed.
You say "a symbol soup with multiple paragraphs explaining what the soup does and why it is good" - honestly, do you think people write multiple paragraphs explaining the code to beginners who can't read APL every single time they write any APL? Of course they don't! Your proposal relies on "symbol soup" being a fair and accurate description, which it isn't.
And, are you suggesting that people don't write comments explaining their code in common popular languages? Of course they do! (and should)
And, are you suggesting that people don't have to learn and practise to be able to read common popular languages when they learn to program? Of course they do, look at posts around the internet on people learning Java and Rust and C# and C++ and Python asking what some code means, what some syntax means, and not only beginners, lots of people ask like "I can code but what is this syntax?" and it's a Python generator comprehension, or a ternary operator, or a C# LINQ SQL style or a pattern match or an anonymous function or a compiler hint or a documentation generator template or a generic type or a turbofish or whatever thing they hadn't seen before in their previous languages or codebases.
And, are you suggesting that comments getting out of sync with code is only a problem in array languages? Of course it isn't.
Or that nobody ever complains about the readability of Java because it's so verbose and has so much abstraction you can't see what's supposed to be happening? People do. I do.
And as always, what about regex? It's so useful as a text processing language that it's often still shorter and cleaner to write a complex regex and paragraphs of comments explaining it, than to code the equivalent in classic string indexing and slicing and if/else branches. You'd end up writing a Greenspun-esque ad hoc, informally-specified, bug-ridden, slow implementation of half a regex engine.
That's not to say there is no criticism of APL's style possible, but if you want people to take the criticism seriously, have something new to say about it or some solid support and explanation for it. "Whenever you look at a problem somebody’s been working on for a week or a month or maybe years and propose a simple, obvious solution that just happens to be the first thing that comes into your head, then you’re also making it crystal clear to people what you think of them and their work." - https://exple.tive.org/blarg/2019/04/17/why-dont-you-just/
Either way it takes time to consume the logic, but it's nice to have it all in one place than scattered about all over creation. I think that's what he's getting at with Aaron's more macro based view. He wrote thousands and thousands of loc before being able to whittle it down to such a terse amount. I can't read it, but that's less to do with APL and a lot more to do with knowing nothing of the domain of compilers.
The symbols actually make a lot of sense and can help you remember what they do. I can remember quite a few after only playing around with it a bit and reading a book on it ages ago.
For J, I read a good bit of "Numerical Programming in J" or something along those lines. I've found J to be more difficult than APL or K to pick up tbh. The tacit trains is just a bit too hard for me to follow.
Which is better, compact or verbose code? That's a style issue and it all depends on who you ask. Verbose code requires you to read more. And more code to maintain.
Writing a mutex, or any number of distributed search/sort algos with disk io approaching dbs isn't. Network io isn't either is any natural sense
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.
It also makes differences stand out so logic bugs are more visually obvious.
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.
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 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
Thanks for that follow up comment.
Other languages support regex for example, but perl takes it to a different level that changes the language experience.
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.
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.
It's unfortunate that the serious Haskell I've seen at work/in the wild is rarely friendly to vertical screen realestate in this way.
(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?
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).
1. The primitive p: generates the nth prime number so, p:0 generates the first prime number 2, p:1 generates the 2nd prime number.
P: 6 generates the 6th prime number 17.
2. P: supports arrays so p: 0 1 2 3 will print the prime numbers at index 0, 1, 2 & 3. Which are 2 3 5 7.
3. The primitive/verb i. Generates a sequential list. So i. 5 will generate 0 1 2 3 4
4. p: can consume other verbs like i:*
So to print the first 1,000 prime numbers, it is simply p: (i.1000)
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.
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:
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.
Close, they are called "idioms".
> +|x
The plus should be an asterisk, but yes, that is an idiom the ngn/k interpreter recognizes.
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...
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.
If the necessary temporary arrays are really huge, array programmers will just do the computation in chunks that fit comfortably in memory.
- 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.
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
P::[2 3 4]
Q::[1 0 2]
dot(P;Q)You can also write P dot Q.
dot←+.×
dot = (sum.) . zipWith (\*)
p = [2, 3, 4]
q = [1, 0, 2]
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 ⌽.
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 <- Just 1
y <- Just 2
Just (x + y)
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".
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.
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).
Thinking in an array language - https://news.ycombinator.com/item?id=31377262 - May 2022 (66 comments)
Regarding interesting programming paradigms I am biased toward SMTs and things alike where you just specify your problem and a solution and tests are generated. Not saying that you can build a big part of a system using logic now but I think will be evolving to more areas of expertise in the future. In a way, from a software engineer point of view, I see AI in the same vein: a black box that could produce interesting results for speeding up software development.
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 valueArray-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.
EDIT: someone beat me to it in a comment further down or up the thread...
Major dialects in the Lisp family are languages with built-in support for more than one kind of data type, not only lists.
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
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.
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/
Do a search for "haskell strongly typed tensor programming."
"Multidimensional arrays inspired by APL"
Including negative exponents, namely automated computation of the inverse function!
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.
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.
> 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.
This means to sort an array you do x@<x, where @ is apply (indexing - for more info on k's indexing read https://beyondloom.com/blog/slicedice.html)
At first this is a bit counterintuitive. But then you realise, x@<x is sort. y@<x is sort by. <<x is 'rank'. There are all these 'recipes' that are based on <, and some of them you may not discover using numpy, as there would be another function that did it for you. You don't typically solve things by composing simple elements, as that would be far too verbose, instead using complicated built in functions, often with many parameters to describe the desired behaviour.
I'm sure other people will have other opinions on what the benefits are, but that was just one example off the top of my head.
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.
can't resist ...
de gustibus ...
https://en.m.wikipedia.org/wiki/De_gustibus_non_est_disputan...
oops, double pun there ;)
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.