5 ms·

I'm most familiar with Dyalog APL so my comments are based on that. I believe that Dyalog has about 100 primitives. (But APL's relatively challenging semantics

I'm most familiar with Dyalog APL so my comments are based on that. I believe that Dyalog has about 100 primitives. (But APL's relatively challenging semantics are somewhat offset but truly simple syntax.) As in most language learning, one starts with a small number (20?) of words and expands from there. APL also requires the neophyte to develop a mind mapping from abstract symbol to function. This may double initial learning time but I don't think that it's much worse than that. Mnemonics exist for many of the symbols. But more fundamental is learning to map the problem space into an array formulation. This, not symbol application, is where a white board may come in handy. Dyalog provides a free web-based tutorial that is quite comprehensive. [1] I daresay that spending a couple of hours with this tool will give you a great taste for APL. Spend a couple of days and you'll be quite proficient in both array-think and APL semantics. Other useful tools include the wiki [2], a cloud server [3], and a neat examples wiki [4]. BTW, the "library of useful components" that the OP desires exists both as a compilation of useful idioms (code fragments) [5]. [1] https://tutorial.dyalog.com/ https://tutorial.dyalog.com/ [2] https://aplwiki.com/ https://aplwiki.com/ [3] http://www.aplcloud.com/ http://www.aplcloud.com/ [4] http://www.jsoftware.com/papers/50/ http://www.jsoftware.com/papers/50/ [5] https://aplwiki.com/FinnAplIdiomLibrary https://aplwiki.com/FinnAplIdiomLibrary

fusiongyro 8y ago
What I really want (and I will annoy you by talking about J instead of Dyalog) is resources for intermediate users, because there is a significant amount of literature for beginners and experts but I agree with Hillel that the road between the two levels seems to be unmitigated struggle. The Finn idiom library may be useful for APL users but even looking at it, I don't see what the purpose of it is, unless perhaps you're just supposed to read the expressions and learn novelties about how to use the built-ins. The approach I've taken, which I think is common and slow and easy to "fall off the bandwagon", is to write my solutions to my problems on my blog or email the J mailing list and see if the experts can improve on my code. They always can, if they care enough to show me, and they usually do. But as I mentioned in my other comment, I think one of the wonders of APL/J/etc. is that it seems to share even less with conventional programming languages than it seems to at first because the way APL programmers decompose problems is radically different. I often find myself trolling through the dictionary looking for things that I wouldn't need if I didn't break the program down into as small pieces. Choosing the right verb is partly tactical, but the whole strategy for attacking problems is so unconventional you are often looking from the wrong vantage point. I don't know if there is a royal road to APL that addresses this, but I share Hillel's desire for one. I suspect there isn't, and the only way to really get better is: read lots of code, write lots of code, get feedback on your code, repeat.

fusiongyro 8y ago

What I really want (and I will annoy you by talking about J instead of Dyalog) is resources for intermediate users, because there is a significant amount of literature for beginners and experts but I agree with Hillel that the road between the two levels seems to be unmitigated struggle. The Finn idiom library may be useful for APL users but even looking at it, I don't see what the purpose of it is, unless perhaps you're just supposed to read the expressions and learn novelties about how to use the built-ins. The approach I've taken, which I think is common and slow and easy to "fall off the bandwagon", is to write my solutions to my problems on my blog or email the J mailing list and see if the experts can improve on my code. They always can, if they care enough to show me, and they usually do. But as I mentioned in my other comment, I think one of the wonders of APL/J/etc. is that it seems to share even less with conventional programming languages than it seems to at first because the way APL programmers decompose problems is radically different. I often find myself trolling through the dictionary looking for things that I wouldn't need if I didn't break the program down into as small pieces. Choosing the right verb is partly tactical, but the whole strategy for attacking problems is so unconventional you are often looking from the wrong vantage point. I don't know if there is a royal road to APL that addresses this, but I share Hillel's desire for one. I suspect there isn't, and the only way to really get better is: read lots of code, write lots of code, get feedback on your code, repeat.