Thinking in an array language (2022)
Array programming languages like K, APL, J, and BQN promise extremely terse, mathematically flavored code and powerful composition over whole arrays, but many programmers question whether this pays off compared to modern functional features like map/filter/reduce in mainstream languages. Commenters weigh the benefits—semantic density, faster refactoring, clearer high‑level patterns, and good performance via SIMD and vectorization—against steep learning curves, unusual glyph-based syntax, heavy use of temporary arrays, and concerns about long-term maintainability and team adoption. Several note that even if these languages remain niche, learning to “think in arrays” can change how you structure data and loops in more conventional environments such as NumPy, R, or Haskell.
Resources and ecosystem
- Several comments link to tutorials, podcasts, and chat rooms for learning array languages (APL, K, J, BQN).
- There are examples of array-like systems embedded in other languages (e.g., APL-on-Lisp, Python-hosted KlongPy).
- Numpy, R, Matlab/Octave, and PyTorch are seen as “array frameworks” rather than full array languages.
Terseness, notation, and readability
- Supporters argue terseness enables “semantic density”: more logic on one screen, fewer indirections, easier refactoring, and faster pattern recognition.
- Concise code is said to make bugs stand out and enable “fearless refactoring,” especially at a REPL.
- Critics see symbol-heavy code as “symbol soup,” hard to read and maintain, and requiring long explanations alongside tiny expressions.
- Some worry that this style encourages cleverness over long-term maintainability and is off‑putting to newcomers.
Comparison with FP and mainstream languages
- Many benefits claimed for array languages (map/filter/reduce style, composition, tacit programming) also exist in functional languages like Haskell, F#, and Clojure.
- Some commenters say once they learned point‑free FP, J/K/APL felt less compelling.
- Others stress that array languages unify operations across all ranks and shapes, and heavily reuse a small set of composable primitives, unlike typical libraries.
Performance, memory, and temporaries
- A key debate: array languages often materialize large intermediate arrays. Concern: wasted memory and bandwidth for problems like “filter numbers < N with predicate P.”
- Responses:
- Memory is usually cheap; when it isn’t, users can manually block computations (process in chunks).
- Some implementations use laziness, loop fusion, idiom recognition, and in‑place reuse of temporaries.
- Array style maps well to SIMD and parallel hardware; even with temporaries, it can outperform scalar loops that aren’t vectorized.
- Critics counter that cache behavior and bandwidth still matter and that naive materialization can lose to streaming scalar code.
Type systems and dimensional correctness
- There is interest in type systems that can express array ranks and shapes (e.g., ensuring matrix dimensions line up, safe broadcasting).
- Discussion mentions dependent/shape types and research languages, but it is unclear how well current systems capture the full generality of array-language operators.
Use cases, learning curve, and adoption
- Array languages are seen as extremely powerful for numeric, linear algebra, and data‑parallel tasks, but “not suited to every problem.”
- Some find them mind‑expanding and report that array thinking improves their coding in other languages.
- Others feel the “everything is an array” bias makes some problems harder than in languages with richer data structures.
- There is skepticism about large, multi‑person, long‑lived codebases in APL/J/K; maintainability practices in such settings are largely unclear from the thread.