In a language where trains of primitives have powerful meanings: hooks, forks and other tacit constructs - the idea that "one symbol = one token" is not intrinsically more readable than variable-length sequences involving punctuation marks, is very hard for me to get my head round. But I'm happy to admit it could just be "old APL dog" syndrome.
However, Mark D. Niemiec wrote: > J has abandoned a lot of the ugly and irregular archaism of APL, > making its syntax more elegant. To wit: > - bracket indexing y[x] being unlike other functions; replaced by regular x}y > - bracket syntax u[n] being unlike other operators; replaced by u"n > - irregular axis-operator semantics replaced by regular rank-operator > semantics > - many APL primitives (such as rotate/reverse, compress/reduce, expand/scan) > have two versions with different default axes. J eliminate this redundancy > by the more general and consistent rank mechanism. > - ; having different precedence from all other verbs > - unique syntax of outer product. > - while APL has some adverb (/ \) and conjunctions (.), > these are special-cased to only work on certain subset of primitives, > while J allows them to be used generally. > - APL's scan operator \ is replaced by the much more useful J prefix operator, > which can emulate scan (via /\) but the converse is not possible. > - J's tacit verb mechanism allows an entire level of elegance and > succinct expression of functional concepts totally unheard of in APL. J has indeed abandoned much of what one could argue is was shown to "bad" design in original APL (mostly in terms of making it harder to extend the language - not necessarily in terms of making the language easy to use). While APL systems have not abandoned anything due to the installed user base, many more modern alternatives are now available. J grew out of the APL community 20 years ago, and much of the bad or inconsistent design was well recognized at the time. Many of the fundamental ideas like rank, dual and "from" were designed and implemented in SHARP APL (with Ken Iverson as a driving force). So although much "special syntax" involving square brackets and semicolons does remain, some of the items on the above list is are not really fair to APL: - In APL, indexing can be done with "squad" and "pick" indexing (no merge - yet) - Rank was actually implemented in SHARP APL before it appeared in J. Although the APL2 paradigm of axis specification has been dominant in the rest of the APL community, I think we will see rank in other APL interpreters in the future. (And for some expressions, the use of axis does allow slightly more elegant code than rank - even if it is less "general"). - It is simply not true that APL operators are limited to certain primitives, at least not in the APL I use. We have user-defined operators, too. The one really nice thing J has done that I don't see how APL can follow (due to the installed user base) it to make the first dimension the default for many operations. The interaction between this and notion of rank is really elegant. The road to hooks, forks and other tacits is still open in APL parsers (I think) - but the last few times we've discussed them, most APL implementors feel that they are "a bridge too far" in terms of succintness. Yes they are beautiful and awesome but the price seems very high, and even seasoned J programmers I have talked with seem to think of them as a form of "object code" that you gradually refine and "assemble", but often have to "dis-assemble" again if you want to modify them. Dyalog APL has "Dynamic Functions" (lambda-style expressions similar in spirit to KEI's "Direct Definition" ideas), and they SEEM to bring us much of the practical benefits that tacits provide, in a less succinct, but more easily digestible form. This may be because we are reaching for a slightly broader programming audience, with a bit less focus on the mathematical aspects of the notation. So although I would agree that J is a nicely rationalized and arguably more powerful notation, it still feels like a very close cousin to APL. Certainly, the differences that exist between APL and J at the language level do not feel decisive in choosing one over the other except for very particular applications. Factors like availability of resource, integration with specific components, and other "business issues" are more likely to be decisive. The reasons that people give for leaving APL are VERY RARELY that it isn't sufficiently succinct and powerful :-) Morten ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
