Colocando meus dois centavos nas linguagens de programação de array , J e APL em particular.
K / Kona, Q e Nial também se enquadram nessa categoria, mas geralmente têm os mesmos benefícios e críticas. Use discrição. Usarei exemplos J abaixo, principalmente porque estes são ASCII e, portanto, fáceis de digitar - lembre-se de que os caracteres APL contam como bytes únicos; portanto, não deixe que esse seja seu problema com o idioma como opção para jogar golfe.
- Problemas de matemática
- Resolvendo quebra-cabeças numéricos
- Executando métodos numéricos
- Problemas complicados da matriz 2D
Essas duas são linguagens muito boas de matemática e manipulação de dados, porque lançam matrizes em torno de um nível alto e muitas repetições são feitas implicitamente , dizendo, por exemplo, adicione dez a cada um de 3, 4 e 5 ( 10 + 3 4 5
) ou some cada linha de uma matriz ( +/"1 arr
- o loop está no "1
).
- Problema ao lidar com números primos
Com problemas com números primos em particular, J possui primitivas rápidas e curtas, assim como alguns dialetos da APL. (Edit: Estou pensando no Nars2000, que é parte do dialeto e parte da implementação completamente diferente. A APL não tem um builtin para números primos.) N-ésimo primo ( p:
), não. de números primos até ( _1&p:
), fatoração ( q:
), GCD e LCM ( +.
e *.
) e assim por diante, há muito por aí. No entanto, na prática, a pergunta geralmente especifica que você precisa preparar suas próprias implementações principais, para que elas não sejam muito usadas. Ainda existem maneiras elegantes e sofisticadas de obter o material principal de que você precisa, isso se torna um pouco menos fácil de copiar e colar.
- Processamento de String
- Processamento de matriz
O processamento de matrizes e strings é meio complicado: se é algo em que o APL / J é bom ou tem um idioma primitivo ou comum, é quase trivial; se é algo que é muito seqüencial e não muito paralelo, você vai se divertir muito. Qualquer coisa entre elas está no ar, embora geralmente elas respondam favoravelmente.
- Problemas que requerem solução de E / S, console ou arquivo
- Problemas que exigem que você escreva sua solução como uma definição de função
IO é estranho. APL tem uma expressão de entrada de um único caractere, mas com J você tem que gastar pelo menos 8 a ler em um número: ".1!:1]1
. A saída é um pouco menos detalhada, mas na prática você ainda está perdendo 6 ou 7 caracteres. J, em particular, realmente gosta muito se você pode receber a entrada como argumentos para uma função, em vez de ter que mexer com o próprio IO.
Na prática, com J e APL, geralmente a solução é escrita como uma função que você chama no console. Com o APL, você pode basicamente colocar nomes de variáveis para seus argumentos e agrupar a expressão com a qual estava trabalhando entre chaves e chamá-la por dia.
Mas com J, há um pouco de sobrecarga para definir funções explicitamente 3 :'...'
- e você precisa escapar de todas as strings internas - então o que geralmente é feito é algo chamado programação tácita: você programa no nível da função, combinando primitivas de uma maneira não muito diferente do de Haskell. Isso pode ser uma bênção e uma maldição, porque você não precisa gastar tantos caracteres se referindo aos seus argumentos, mas é fácil se afogar entre parênteses e acabar perdendo dezenas de caracteres tentando invadir sua solução curta e inteligente para algo que funciona.
- Problemas que requerem análise
- Geometria computacional
Não tenho experiência em resolver esses problemas em particular, mas vou dizer o seguinte: no final, as linguagens de programação de array são muito boas em canalizar e transformar muitos dados da mesma maneira. Se você pode transformar o problema em um exercício de ordenação de números, pode torná-lo um problema de APL / J, sem suor.
Dito isto, nem tudo é um problema APL / J. Ao contrário do Golfscript, APL e J por acaso eram bons para jogar golfe, juntamente com seus outros benefícios;)