<i>Do you think the APL family can exist without the terse syntax?</i><p>I have yet to meet a programming model that can only exist in one specific syntax. The closest I&#x27;ve seen is lisp-style metaprogramming, which requires syntax that makes its nesting structure obvious (you&#x27;re <i>operating on</i> pieces of syntax, so of course you need to know <i>something</i> about it); of course, you could use indentation instead of parens to show that structure if you like. APL-like operator lifting is entirely a semantic issue. It can exist just fine in s-expressions, ML-like syntax, Python-like syntax, etc.<p>APL-family languages typically even tie their own hands in terms of semantic flexibility because of their syntax. They have separate syntactic classes for (first-order) data, first-order functions, and second-order functions. The parser doesn&#x27;t know what to do with an identifier unless it knows that identifier&#x27;s definition, which makes compiling APL pretty awkward (ever seen a parser that tries to do data flow analysis?). It also limits their flexibility as functional programming languages. J, at least, by keeping a symbolic representation of all functions at run time, enables a sort of workaround where you can package up a vector of first-order functions, but this is much more awkward to work with than actual first-class functions.<p>But what really disappoints me about APL-style syntax is limiting its flexibility as an array-processing language. The language semantics offer this great ability to automatically &quot;lift&quot; any operation to work on arbitrarily high-dimensional arrays. Want the square root of every number in a 3-tensor? Go for it! Want to average every column in a matrix? Just average it! In more recent incarnations, you can even mix and match the shapes you&#x27;re lifting up to, like adding a vector to every column in a matrix.<p>But that flexibility stops short if your function needs three inputs. Infix-only syntax has no way to write function application with more than two arguments, so you&#x27;re forced to pack some of those inputs together into a single argument. Now you can&#x27;t choose to lift the operation to every argument separately: you&#x27;re forced to put the same array structure around multiple arguments. If you try to get around this by writing a second-order function (rather like currying), you now have one argument you <i>can&#x27;t</i> lift to because only first-order functions get the dimension lifting.<p>So not only is the programming model not inextricably tied to this particular syntax, I&#x27;m not even convinced it&#x27;s the best syntax for the programming model.