I have had considerable experience with APL
What I have found is that it is important, more than with many other
languages, to document the code. With J it is even more important. This
is a consequence of the power involved in a statement combined with what
the hell did I mean when I wrote it..
Other languages are more concerned with the"computer science structure"
than the problem that is being approached (hence APL and J are overall
considered as "lesser",.
When I think of a problem, I look at what is wanted and what is known
and the tools to get to the former from the latter. I don't give a damn
in defining something as integer vs floating point etc. If a number is
close to integer- treat it as such, APL and J do this. and the array
processing capabilities help with dealing with the problem of interest.
An example. is +/ (somelist_ of_ numbers)_
The downside is that one can become overly focused on tight tacit
programs and it might be better to have a documented explicit program
filed somewhere, even in the same script file, that spells out the
reasoning behind the tacit version.
Reading J is different from other languages because it removes much of
the overhead from the tiddly details that can be handled more
efficiently in the background by the idiot box.
Don
.
On 13/01/2014 1:08 PM, William Tanksley, Jr 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
