I think that the vast majority of people who complain that these languages are unreadable and who insinuate that people who use and like them are basically just showing off are fundamentally uninterested in the possibility that there are possible positive trade offs to this style but for those who are genuinely interested in why some people like to program this way: Imagine having to do math with no symbols. that means 1+1 is now one plus one. Now imagine having to do that in the context of graduate levels mathematics. I am quite sure nobody calls a2+b2=c2 unreadable as compared to a squared plus b squared equals c squared and I dont know any one who wants to do algebra that way. Well the same principle is why array programmers like this style. I dont expect you to take my word for it im just letting you know what these other weird crazy people see in array languages that you dont. This allows one to think faster and further than they could encumbered but a heavier syntax. Is this way of programming the best no. Should everyone learn it no. Are there trade offs yes. Is it worth your time, quite possibly not. But thats true about literally everything in programming.
jasonwatkinspdx · 52m ago
Iverson's Notation as a Tool for Thought is an argument in favor of the above. I don't think it's flatly wrong, but I am skeptical of the more strong forms of it.
I think it's important to remember that APL was born of an era where having a keyboard dedicated to a single programming language was reasonable.
I think there's a lot of middle ground between the more line noise syntax of say jsoftware, or a pure lisp style prefix notation.
This is a little snippet from Stevan Apter, a k programmer that has an old school home page with a lot of array language curiosities:
If you look at the pseudo code example at the end using words vs ascii glyphs, I think that's quite readable while also concise. It uses k's bracket notation to easily specify slices of nested arrays.
Interestingly kxsoftware themselves went this route with q (Stevan's essay predates this I believe). There they kept nearly all the power of k but exposed it va a more approachable sql like syntax.
nine_k · 24m ago
Mathematical notation actually pays quite a bit of attention to readability, to visual separation of things to make the whole easier to parse. Multi-story fractions, subscripts and superscripts, oversized or miniature symbols, parens, etc, etc. This is why math in a textbook very often looks much more readable than the same math in typical Python or Fortran code.
I wish APL derivatives embraced some of these ideas, and made their magic spells easier to parse visually, and to format for readability. I don't know how to achieve that easily. Mathematical notation took centuries to develop. It took quarter of a century for programming languages to normalize indentation. Maybe APLesque languages will eventually come up with a notation that's less impenetrable than APL / K / Q, but less verbose than Pandas.
why218 · 12m ago
Well some of what you mentioned has been implemented in array languages and some like superscript and sub script was part of the original apl book (the book on the notation pre the implentation). Its somewhat ironic, orignally apl was supposed to make math notation more readable (it was originally just a math notation) but many people dont see it that way. if you are interested in super scripts and the like you might check out bqn and uiua which both are doing interesting things with the symbols. although uiua in particular suffers from having to choose from a set of symbols that comes from unicode and therefore sometimes look a little off to me
sundarurfriend · 53m ago
> Imagine having to do math with no symbols. that means 1+1 is now one plus one. Now imagine having to do that in the context of graduate levels mathematics.
That's a good way to put it. It's pretty hard to convey this to someone who hasn't actively tried and solved real problems in such languages though. You don't realize how much the "words get in the way" (as Granny Weatherwax would say) until you give an array language a good chance.
Another pop-culture quote that resonated in this regard is from The Matrix:
> Your brain does the translating. I don't even see the code. All I see is blonde, brunette, redhead.
All I see is range, sum-over, divide. The symbols turn into the concepts directly in your head - not as conscious translation, but in the way I imagine Chinese or Japanese kanji characters translate directly in the head of a native speaker.
why218 · 8m ago
Yes as someone who was exposed to kanji as a child I can say that at least for me the experience is nearly identical
nkrisc · 51m ago
I thought it was another one of those cryptic, inscrutable languages, but following along the explanation of the prime function reveals it’s not actually as complex as it looks, and is a quite straightforward right to left application of operators. Not nearly as bad as I first thought.
MontyCarloHall · 31m ago
I understand the appeal of array languages — they provide very convenient shortcuts to common loop operations in traditional imperative scalar languages. Their usefulness is manifest in the popularity of NumPy (and its derivatives, e.g. TensorFlow, PyTorch, JAX, etc.), MATLAB, Julia, R, and other Iverson Ghosts [0]. The rise of map/reduce/filter operations in common scalar programming languages is also testament to array languages' usefulness.
I can understand (though do not personally agree with) the appeal of extreme terseness — there are arguments to be made that maximizing information density minimizes context switching, since it reduces the amount of scrolling. Personally, I find that large displays and split buffers mitigate this issue, whereas the mental overhead of using my short-term memory to map of dozens of single letter variables to semantic definitions is much higher than having to flip between splits/marks in my text editor. (The fact that the aforementioned Iverson Ghost languages are popular whereas APL and its derivatives are not is evidence that I'm aligned with most people in this regard.)
I don't understand why people rarely make the terseness argument for non-array languages, even though it's just as easy to write tersely in them — the Obfuscated C Competition is a prime example [1]. Is it just due to the influence of APL, or is there something special about array languages that gives them a unique proclivity for terseness?
I just fail to see the point. I could see the use for some convenient functions for array manipulation, but why not just implement these as a library in any existing language?
>This allows one to think faster and further than they could encumbered but a heavier syntax.
How does the programming language limit your ability or speed of thinking, lest when the fundamental data types and operations are the same? The hard work is always knowing what to implement. Saving some keystrokes for reversing an array or whatever other array manipulation is hardly a game changer.
why218 · 28m ago
I think there is literally nothing I could say that would change your mind. You've already decided what you think. There are a number of benefits but none that I could write out and have you someone who is uninterested immediately take my word for it and go home a fan. But I'll try to answer your (probably rhetorical) direct question. "How does the programming language limit your ability or speed of thinking". Again tell me how it is you do difficult math? Do you write out english or do you work with notation that makes it easier to feel and calculate your way through a problem. if you wanted to write a program in a new domain do you honestly think you would come to the same level of understanding of the topic at the same speed if you use assembly vs python. Yes the hard work is knowing what to implement; arrays languages help its users know what to implement. Ultimately, these are all just claims I can't prove to you what experiences you will or wont have if you learn the languages. You wont just believe and you shouldn't just believe me. If you are interested, learn more and try it out! (theres the apl and k wikis, a discord called the aplfarm a podcast called the arraycast etc.) If not just write array languages off and move on.
andoando · 14m ago
Most programmers don't do any math at all, so maybe this is just a niche thats not relevant to most of us, but to answer your question:
If I am thinking about any problem, its outside the scope of any programming language in the first place. My point is, modern functions already make array manipulations simple enough. Even if you're doing something like coding LLMs from scratch, numpy, list concatenations, list comprehension, lambdas, stream/map/reduce all exist and its not nearly an issue to implement them, as is the case for writing assembly vs python.
The prime example in python for example looks like this:
all(x % i != 0 for i in range(2, x))
This pretty much does the same operations in the same order on the same fundamental data structure, so I just don't see what's fundmenetally different about the Klong way of thinking.
Anyway, I don't mean to argue, if it works for you great, I wish I had something new
sundarurfriend · 45m ago
> library in any existing language
An example of this is APL.jl [1][2]
It seems more of a proof-of-concept than a real implementation though - at least, the APL wiki calls it a "toy dialect of APL" and says that it "works on a minor subset of APL". [3]
This looks more like an interpreter.
What I mean is just take the symbols in Klong and write them as methods on arrays. Sure the syntax won't be the same, but does that really warrant a whole new language?
nine_k · 36m ago
> why not just implement these as a library in any existing language?
I bet you heard about NumPy :) (Also Pandas, Polars, etc.)
etbebl · 1h ago
I wonder how much overlap there is between users of array languages and of scientific programming languages/dialects like MATLAB, Numpy, and Julia, which are also optimized to operate over arrays. In other words, do K/Klong/whatever proponents realize that there is already a huge community of people who appreciate and utilize powerful operations on arrays to do real work, but just prefer to write something like "max(diff(x))" instead of "|/--:'x"? It's almost the same number of characters and it doesn't require learning a new writing system.
mlochbaum · 1h ago
"already": APL dates back to about 1966, and even K from 1993 predates Numpy and Julia. But yes, we do not live in caves and are familiar with these languages. Klong has even been implemented in Numpy, see https://github.com/briangu/klongpy.
horsellama · 46m ago
Julia is fun when used with the “array” mindset. It can also get very terse [0]
The world is big enough for people to safely experiment with programming languages. I don’t think there’s any risk to Matlab/Python/Julia (and indeed, many people did and still argue that Julia is excess baggage).
Aken · 1h ago
> If you don't know any array languages, it might explode your brain. Use at your own risk!
I've been around the block, don't think it'll be a problem picking up something new
> Here is a program that checks whether a number x is prime (for x>2): {&/x!:\2+!_x^1%2}
(closes laptop and goes outside)
andoando · 52m ago
I mean its not that bad.
You just go right to left. 1/2 applied to x^ so x^(0.5), _ is floor so floor of x^0.5. ! creates an array of numbers up until floor of x^0.5. 2+ just adds 2 to every number, and then I lost interest in learning the rest lol.
Yeah I like the python equivalent
def is_prime(x):
return x > 1 and all(x % i != 0 for i in range(2, x))
nils-m-holm · 1h ago
No idea why emorning3's comment is marked [dead]. It's a good question and in fact Klong arrays are very much like S-expressions. In fact their implementation is pretty much the same, down to using CAR and CDR to manipulate them.
Klong could easily be implemented as a bunch of LISP functions and macros.
Jtsummers · 1h ago
> No idea why emorning3's comment is marked [dead].
It's [dead] because they were banned, not because of the comment itself. It can still be vouched for.
haolez · 2h ago
I wonder if these extremely terse languages might see a rise in popularity with LLMs, since they save a lot of tokens. The hard part would be training on them, since training data is not as comprehensive as JavaScript, for example.
Fun times! :)
Qem · 2h ago
> The hard part would be training on them, since training data is not as comprehensive as JavaScript, for example
From terse languages surely there is a lot of training data for Perl. Not nearly as terse as J, K or Klong, although.
cosmic_quanta · 3h ago
There's a niche out there where this kind of technology is appreciated. I can even appreciate the technical challenges in making an array language interpreter run fast!
However, unfortunately, the notation is so terse that I can't imagine spending the time to learn this. This looks write-only.
Is there an obvious reason to prefer a k-like language like Klong, over e.g. Futhark[0] or Accelerate[1]?
the terseness is magical when you are in the repl and it just takes typing 1, 2 or a hand-full of characters to try an idea you have
edit: and when you want to understand a larger program the terseness means you might be able to actually see it as a whole, in one page or screen
kazinator · 56m ago
I can't read anything that is too far out of my fovea. If I look at a word in the middle of a sentence, I can read it, and the two immediately adjacent words. After that, the ability rapidly declines. If the next words after those two are simple like "and" and "the", I can still read them while staring at the middle word. Beyond that, I am aware that there are letters and words, but no decoding takes place. If something fits on the screen, it's nice that I don't have to scroll around, but I certainly cannot see it all at once in a semantic way, only as a picture.
"The braces around an expression denote a function. Because this function contains a single variable, x, it is a monadic function or a monad."
I never understood that about monads, even if it's litterally their name.
kragen · 57m ago
A monadic function in APL-family languages is not related to monads from category theory, which are the ones you see in Haskell, nor to Leibniz's monads.
kazinator · 51m ago
In this context it just means "one parameter function".
It looks like every apparently free variable in a Klong brace expression is actually bound as a function parameter.
This is so in basic algebra in that we can think of, say, x^2 + y^2 as a two parameter function, even without writing out the full f(x, y) = x^2 + y^2 notation with the f(x, y) head.
A two parameter function would be called "dyadic" in the jargon which calls one argument functions "monadic".
emorning3 · 2h ago
Google tells me that Klong and Lisp are not the same thing.
But can someone tell me why an array in Klong is NOT like an s-expression in Lisp?...
thomasmg · 3h ago
> If you try to use it like your favorite functional/procedural/OO programming language, you will only get frustrated.
For me personally, the sentence could be shortened to just: "If you try to use it, you will only get frustrated."
nils-m-holm · 1h ago
So the sentence served its purpose and saved you the frustration :)
thomasmg · 1h ago
I appreciate the features of these languages (J, K, and Klong), but I do not understand the reason why they have such a hard to read syntax. I think it is a pity; I could see myself using it otherwise. Maybe it is by design, but I do not understand it.
I think it's important to remember that APL was born of an era where having a keyboard dedicated to a single programming language was reasonable.
I think there's a lot of middle ground between the more line noise syntax of say jsoftware, or a pure lisp style prefix notation.
This is a little snippet from Stevan Apter, a k programmer that has an old school home page with a lot of array language curiosities:
https://nsl.com/papers/kisntlisp.htm
If you look at the pseudo code example at the end using words vs ascii glyphs, I think that's quite readable while also concise. It uses k's bracket notation to easily specify slices of nested arrays.
Interestingly kxsoftware themselves went this route with q (Stevan's essay predates this I believe). There they kept nearly all the power of k but exposed it va a more approachable sql like syntax.
I wish APL derivatives embraced some of these ideas, and made their magic spells easier to parse visually, and to format for readability. I don't know how to achieve that easily. Mathematical notation took centuries to develop. It took quarter of a century for programming languages to normalize indentation. Maybe APLesque languages will eventually come up with a notation that's less impenetrable than APL / K / Q, but less verbose than Pandas.
That's a good way to put it. It's pretty hard to convey this to someone who hasn't actively tried and solved real problems in such languages though. You don't realize how much the "words get in the way" (as Granny Weatherwax would say) until you give an array language a good chance.
Another pop-culture quote that resonated in this regard is from The Matrix:
> Your brain does the translating. I don't even see the code. All I see is blonde, brunette, redhead.
All I see is range, sum-over, divide. The symbols turn into the concepts directly in your head - not as conscious translation, but in the way I imagine Chinese or Japanese kanji characters translate directly in the head of a native speaker.
I can understand (though do not personally agree with) the appeal of extreme terseness — there are arguments to be made that maximizing information density minimizes context switching, since it reduces the amount of scrolling. Personally, I find that large displays and split buffers mitigate this issue, whereas the mental overhead of using my short-term memory to map of dozens of single letter variables to semantic definitions is much higher than having to flip between splits/marks in my text editor. (The fact that the aforementioned Iverson Ghost languages are popular whereas APL and its derivatives are not is evidence that I'm aligned with most people in this regard.)
I don't understand why people rarely make the terseness argument for non-array languages, even though it's just as easy to write tersely in them — the Obfuscated C Competition is a prime example [1]. Is it just due to the influence of APL, or is there something special about array languages that gives them a unique proclivity for terseness?
[0] https://dev.to/bakerjd99/numpy-another-iverson-ghost-9mc
[1] https://www.ioccc.org, https://github.com/ioccc-src/winner/blob/master/2020/ferguso...
>This allows one to think faster and further than they could encumbered but a heavier syntax.
How does the programming language limit your ability or speed of thinking, lest when the fundamental data types and operations are the same? The hard work is always knowing what to implement. Saving some keystrokes for reversing an array or whatever other array manipulation is hardly a game changer.
If I am thinking about any problem, its outside the scope of any programming language in the first place. My point is, modern functions already make array manipulations simple enough. Even if you're doing something like coding LLMs from scratch, numpy, list concatenations, list comprehension, lambdas, stream/map/reduce all exist and its not nearly an issue to implement them, as is the case for writing assembly vs python.
The prime example in python for example looks like this: all(x % i != 0 for i in range(2, x)) This pretty much does the same operations in the same order on the same fundamental data structure, so I just don't see what's fundmenetally different about the Klong way of thinking.
Anyway, I don't mean to argue, if it works for you great, I wish I had something new
An example of this is APL.jl [1][2]
It seems more of a proof-of-concept than a real implementation though - at least, the APL wiki calls it a "toy dialect of APL" and says that it "works on a minor subset of APL". [3]
[1] demo: https://nbviewer.org/gist/shashi/9ad9de91d1aa12f006c4 [2] repo: https://github.com/shashi/APL.jl [3] https://aplwiki.com/wiki/APL.jl
I bet you heard about NumPy :) (Also Pandas, Polars, etc.)
[0] https://code.golf/wiki/langs/julia
I've been around the block, don't think it'll be a problem picking up something new
> Here is a program that checks whether a number x is prime (for x>2): {&/x!:\2+!_x^1%2}
(closes laptop and goes outside)
You just go right to left. 1/2 applied to x^ so x^(0.5), _ is floor so floor of x^0.5. ! creates an array of numbers up until floor of x^0.5. 2+ just adds 2 to every number, and then I lost interest in learning the rest lol.
Yeah I like the python equivalent def is_prime(x): return x > 1 and all(x % i != 0 for i in range(2, x))
https://news.ycombinator.com/item?id=44231847
It's [dead] because they were banned, not because of the comment itself. It can still be vouched for.
Fun times! :)
From terse languages surely there is a lot of training data for Perl. Not nearly as terse as J, K or Klong, although.
However, unfortunately, the notation is so terse that I can't imagine spending the time to learn this. This looks write-only.
Is there an obvious reason to prefer a k-like language like Klong, over e.g. Futhark[0] or Accelerate[1]?
[0]: https://futhark-lang.org/
[1]: https://hackage.haskell.org/package/accelerate
edit: and when you want to understand a larger program the terseness means you might be able to actually see it as a whole, in one page or screen
"The braces around an expression denote a function. Because this function contains a single variable, x, it is a monadic function or a monad."
I never understood that about monads, even if it's litterally their name.
It looks like every apparently free variable in a Klong brace expression is actually bound as a function parameter.
This is so in basic algebra in that we can think of, say, x^2 + y^2 as a two parameter function, even without writing out the full f(x, y) = x^2 + y^2 notation with the f(x, y) head.
A two parameter function would be called "dyadic" in the jargon which calls one argument functions "monadic".
But can someone tell me why an array in Klong is NOT like an s-expression in Lisp?...
For me personally, the sentence could be shortened to just: "If you try to use it, you will only get frustrated."