Pensar em uma linguagem de arrays (2022)

Artigo original ↗ Discussão no Hacker News ↗

Linguagens de programação de arrays como K, APL, J e BQN prometem código extremamente conciso, com sabor matemático, e composição poderosa sobre arrays inteiros, mas muitos programadores questionam se isso compensa em comparação com recursos funcionais modernos como map/filter/reduce em linguagens mainstream. Os comentaristas avaliam os benefícios — densidade semântica, refatoração mais rápida, padrões de alto nível mais claros e bom desempenho via SIMD e vetorização — contra curvas de aprendizado íngremes, sintaxe incomum baseada em glifos, uso intenso de arrays temporários e preocupações com manutenibilidade de longo prazo e adoção em equipe. Vários observam que, mesmo que essas linguagens continuem de nicho, aprender a “pensar em arrays” pode mudar a forma como você estrutura dados e loops em ambientes mais convencionais, como NumPy, R ou Haskell.

Recursos e ecossistema

  • Vários comentários apontam para tutoriais, podcasts e salas de chat para aprender linguagens de arrays (APL, K, J, BQN).
  • Há exemplos de sistemas semelhantes a arrays incorporados em outras linguagens (por exemplo, APL-on-Lisp, KlongPy hospedado em Python).
  • Numpy, R, Matlab/Octave e PyTorch são vistos como “frameworks de arrays”, e não como linguagens de arrays completas.

Concisão, notação e legibilidade

  • Defensores argumentam que a concisão permite “densidade semântica”: mais lógica em uma tela, menos indireções, refatoração mais fácil e reconhecimento de padrões mais rápido.
  • Diz-se que código conciso faz bugs se destacarem e permite “refatoração sem medo”, especialmente em um REPL.
  • Críticos veem código carregado de símbolos como “sopa de símbolos”, difícil de ler e manter, e que exige longas explicações ao lado de expressões minúsculas.
  • Alguns temem que esse estilo incentive esperteza em vez de manutenibilidade de longo prazo e afaste iniciantes.

Comparação com FP e linguagens mainstream

  • Muitos dos benefícios atribuídos às linguagens de arrays (estilo map/filter/reduce, composição, programação tácita) também existem em linguagens funcionais como Haskell, F#, e Clojure.
  • Alguns comentaristas dizem que, depois de aprender FP point-free, J/K/APL pareceram menos atraentes.
  • Outros enfatizam que as linguagens de arrays unificam operações em todos os ranks e formas, e reutilizam intensamente um pequeno conjunto de primitivas composáveis, ao contrário de bibliotecas típicas.

Desempenho, memória e temporários

  • Um debate central: linguagens de arrays frequentemente materializam grandes arrays intermediários. Preocupação: memória e largura de banda desperdiçadas em problemas como “filtrar números < N com predicado P”.
  • Respostas:
    • Memória normalmente é barata; quando não é, os usuários podem dividir os cálculos manualmente (processar em blocos).
    • Algumas implementações usam preguiça, fusão de loops, reconhecimento de idioms e reutilização in-place de temporários.
    • O estilo de arrays se adapta bem a SIMD e hardware paralelo; mesmo com temporários, pode superar loops escalares que não são vetorizados.
    • Críticos contra-argumentam que o comportamento de cache e a largura de banda ainda importam e que a materialização ingênua pode perder para código escalar em streaming.

Sistemas de tipos e correção dimensional

  • Há interesse em sistemas de tipos que consigam expressar ranks e formas de arrays (por exemplo, garantir que dimensões de matrizes se alinhem, broadcasting seguro).
  • A discussão menciona tipos dependentes/de forma e linguagens de pesquisa, mas não está claro o quão bem os sistemas atuais capturam a generalidade total dos operadores de linguagens de arrays.

Casos de uso, curva de aprendizado e adoção

  • Linguagens de arrays são vistas como extremamente poderosas para tarefas numéricas, álgebra linear e paralelismo de dados, mas “não servem para todo problema”.
  • Alguns acham que elas expandem a mente e relatam que pensar em arrays melhora seu código em outras linguagens.
  • Outros sentem que o viés de “tudo é um array” torna alguns problemas mais difíceis do que em linguagens com estruturas de dados mais ricas.
  • Há ceticismo quanto a bases de código grandes, com várias pessoas e longa duração em APL/J/K; as práticas de manutenção nesses contextos são amplamente pouco claras a partir do fio.