I'll counter your suggestion that it's easier to write unreadable code in APL derivatives with an observation that looks to me like a social issue rather than anything intrinsic in the language.
I say this because with minimal training (one class in APL at a community college, and occasional use in other classes, like biology), I was able to debug and improve other people's APL code in a large codebase. >From my point of view the thing that has been holding back APL is that it is too valuable and too productive. Consider, for example, the impact of Arthur Whitney on wall street. Things like that tend to drive up the price of the implementations which makes business people nervous. And when a business tries to switch away, and fails? That makes them even more nervous. Meanwhile, most schools do not teach APL. If there were a large supply of programmers, the above issues would not be such a problem. (Instead, we'd have the problem of lots of code much of which would not address most people's needs, sometimes colloquially called "bad code" - popular languages suffer this issue and people mistakenly attribute that kind of problem to the language, also.) The problem with APL is mostly a lack of source material, for people who might be interested in using the language. This leads to people being intimidated and also leads to a lack of implementations. So that probably means that admirable books and examples would help. Thanks, -- Raul On Mon, Jan 13, 2014 at 4:08 PM, William Tanksley, Jr <wtanksle...@gmail.com> wrote: > Dan Bron <j...@bron.us> wrote: >> We often say the APL family of languages allow us to use language as a tool >> of thought. How does this play out in practice? Do we approach reading J >> programs differently from those written in other languages? If so, how? > > I think this is a fantastic question. > > I completely agree that it's very easy to write unreadable programs in > J. Some people have pushed back that it's easy to write unreadable > programs in any language; but I would actually counter that it's > easier in APL derivatives. > > But I would contend that this is actually a consequence of APL > derivatives being developed as a tool of thought rather than a tool of > communication (or a tool of command). > > Thinking is hard. Communicating is also challenging, but it's not the > same as thinking. > > I would like to point to the general teaching that APL people give for > reading APL code -- what they say (I don't have a link) is that you > can best understand APL code by rewriting it, and then comparing what > you write with what was originally written. In other words, you learn > to THINK about what the author was thinking about, and then you try to > understand the WAY the author was thinking. > > This reminds me of Chuck Moore's approach to program design, which he > called "Thoughtful Programming". He advocated using many prototypes to > cull out decent and unacceptable designs. > > My brain is refusing to give me the name of the guy who's developing a > thinking system using an APL derivative. > >> -Dan > > -Wm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
