| ▲ | gobdovan an hour ago | ||||||||||||||||
Thanks for the response. I'd interpret it as a valid technical caveat, but it feels somewhat orthogonal to what I was pointing out. You focus on the 'often inefficient' parenthetical, yet, to me, your response highlights the puzzle nature of the thinking APL encourages. If anything, it shifts the question from 'how do I express this tersely' to a still narrower 'how do I express this tersely in a way the interpreter can also optimize'. | |||||||||||||||||
| ▲ | tosh an hour ago | parent [-] | ||||||||||||||||
I think every programming language to a degree has some kind of puzzle aspect I'm not sure APL has more or less of it compared to other languages for example in Python, even though the language has a concept of "There should be one-- and preferably only one --obvious way" (PEP 20) it is quite multi paradigm, which I think is a strength of Python oop, functional, imperative, … and you get tons of libraries to choose from e.g. numpy, pandas, polars, pytorch, keras, jax, … etc but you still also have to figure out the algorithm and data structures you want to use (like in any language) and you also kinda want to know (if you care about performance) how pytorch differs from numpy and how that differs from using a list with boxed values Not saying this is not the case with APL it definitely helps if you are familiar with the APL implementation you're using if you care about performance I just don't think it's a disadvantage of APL over other languages | |||||||||||||||||
| |||||||||||||||||