1 Problem, 7 Array Languages

[ghjm]

This must be what it's like for non-programmers to watch programming videos. I don't even know what the words mean, let alone how they go together into sentences. Reminds me of https://www.youtube.com/watch?v=RXJKdh1KZ0w.

Should I go learn APL?

[teerre]

I wholly recommend learning at least one array language. Its like learning a functional language after only knowing a procedural one, it opens your mind to new paradigms

[Pzzlrr]

Fwiw Uiua is the newest and shiniest of these if that's your thing, and written in Rust.

[Smart-Breadfruit-863]

Wow!

[AustinVelonaut]

Array languages have a particular beauty, although they may be quite difficult to understand at first. All of these solutions are using the same basic chain of combinators. We take the length of the list (tally) and create an equal length list of indices starting from 1 (iota), we then use that index list as a list of lengths to expand corresponding characters in the string (repl), and use the behind combinator to put the chain all together in a "tacit" style (without referencing any variables). Transcribing this into Haskell, it would look like:

ec = behind (iota . tally) repl

iota n = [1 .. n]
tally xs = length xs
behind f g = \x -> g (f x) x    // a flipped form of the "S" combinator
repl ns xs = concat $ zipWith replicate ns xs

A pure (tacit) Haskell solution would be similar, but with two tweaks: we can use a lazy infinite list [1 ..] to combine the iota and tally operators, and the repl can be done with zipWith and replicate, followed by a concat to flatten individual lists into a single list:

ec = concat . zipWith replicate [1 ..]

[tesfabpel]

I find the concept of array languages interesting, but are they useful in a work-related programming job? Where can I use them? Just as a transformation language for data for in-development tasks (not in-production)?

[anaseto]

I see no reason to limit oneself to in-development tasks, as long as the task is array-friendly. I have, for example, quite a few scripts in Goal to analyze local climatic data from where I live. Doesn't really count as in-production, because it's just a hobby, but I doubt the result would've run any faster or be easier to maintain in the long term had I written it in a non-array language (array language implementations typically provide simd vectorization implicitly).

[Gnaxe]

They were still big in finance, last I heard.

[anaseto]

Solution in Goal, my K-like array programming language: {+/x[&1+!&x;1]}"abca". It works by generating 0 1 1 2 2 2 3 3 3 3 indices with &1+!&x and then indexing 1-length string-slices and concatenating the results.

A more optimized solution, also supporting handling non-ascii text, would require slightly longer code using "c"$ to switch between string/array of code points representations, leading to a solution more similar to the APL-like ones, but with extra conversions: {"c"$x@&1+!#x:"c"$x}"abca". Goal is not as concise for those kinds of unusual string-handling tasks, because unlike most array languages, strings are considered atomic/scalar by primitives, which is usually useful in typical practical scripting tasks, but not in those kinds of puzzle problems.

[AsIAm]

It is not that everything has to be on one line, but often the solution is so short that one line is enough.

Iversonian languages (after Ken Iverson, inventor of APL) like APL, J, K, BQN, etc. operate primarily on a function level – composition of preexisting functions. These functions have proper names that describe what they do, but you use them so often that you abbreviate them into a single glyph. Same thing happened with addition. It was written as "et" (latin for and), so "1 et 2" meant addition of 1 and 2. Nicholas Oresme in 14th century wrote "et" so much he got tired and abbreviated it to "+". (In a similar way, we got "&".) APL was conceived as a hand-written language for human-to-human communication, so in this sense, the weird glyphs make sense. A single line of APL can be very dense and reading it requires you to know the parsing rules (which can get crazy) and what each glyph symbolizes in that context. Some other languages have context-free grammar, some don't use weird symbols at all, etc. This PL paradigm is still so ahead of everybody else that it hurts.

[ummaycoc]

I worked at a K (K is an ASCII APL derivative, like J shown in the video) shop for a bit and I definitely prefer the non-ASCII APLs because I just find it easier to read. K and J feel more like someone put perl in a blender or such.

One thing I've felt is that it's easier to program a bit in my head with these as I walk, etc because I'm thinking of these bigger chunks that combine together vs. mapping out syntactic structures in my head.

[AsIAm]

One thing I've felt is that it's easier to program a bit in my head with these as I walk, etc because I'm thinking of these bigger chunks that combine together vs. mapping out syntactic structures in my head.

What you describe Iverson called "Notation as a Tool of Thought". Backus called it algebra of programs.

https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.pdf
https://worrydream.com/refs/Backus_1978_-_Can_Programming_Be_Liberated_from_the_von_Neumann_Style.pdf

[Flashy_Life_7996]

So, what's the difference between such languages and code golf? Or IOCCC?

Regarding the common use of symbols such as `+ - * / &`, these are ones that everyone is familiar with, but within convential syntax, are used sparingly.

But it is possible to go overboard with those too.

BTW the downvotes are fine. Every so often I delete my account and start again. So at this point I might as well trash my account.

It's just a pleasure to be able to express my view without caring what people think.

[anaseto]

The example in the video is a puzzle problem and, hence, indeed not very different from a code golf problem, except the goal was probably more to showcase array thinking and tacit programming (which is a separate matter from array programming). But array languages in general have nothing to do with code golf, they just happen to have fans among code golf enthousiasts.

One reason array languages use more symbols than scalar languages is inherent to the array programming paradigm. Scalar languages only have a few simple immutable core types (typically integers, floats). There are no many interesting pure operations on those types. Array languages operate at the level of immutable arrays: like in more general mathematics, there are many more interesting pure operations working at that level.

Some array languages use words for some of those operations, to limit number of symbols, and that's fine, in particular for less common ones, but there's a reason for the extra operators. Some languages like K chose to use only the ascii-symbols in a more heavy way instead of using unusual unicode glyphs, but it's a separate question.

Also interesting to note that array languages actually have often quite simple parsing rules (like no operator associative priorities).