See comments below.
On 2016-08-03 16:46, Nicholas Spies wrote:
Hi Erling: (I hope this makes it to chat on the J forums-- please forward
if only you get this)
Your statement on your web page:
"Another basic difference between explicit J and tacit J is that in tacit J
there is no reference to the nouns. The nouns are still there, but there is
nothing to denote them. It is like the persian language in which the vowels
are never printed. The reader has to guess vowels until the resulting word
makes sense in the context. In tacit J the reader has to construct the
nouns in his mind. There are a lot of different functions for routing nouns
to the right verb."
I love J but have never comprehended tacit programming, with its hooks,
forks and trains--which may lead to efficient interpreted code, but have
always seemed to be to be a kluge to achieve extreme brevity. I would
prefer tacit programming to explicit programming, because the latter seems
too much like just another ALGOL-like language such as C, Pascal, etc. I
like brevity, because, in coding, less is more--because shorter programs
are far easier to comprehend and debug.
The modified explicit J syntax is not same old explicit J. It is similar
to tacit J with Left and Right. I don't know in which of these notations
require the least number of syntax elements for a certain functionality.
The performance seems to be like tacit J.
You can split JWithATwist expressions(called noun definitions) over
several lines. You can use indentation between snippets. Still long
JWithATwist noun definitions are also hard to read.
My use of J has occurred in widely separated intervals, so I have had to
relearn it multiple times and have never really mastered it. However, I
never realized, per se, that tacit programming was just J abbreviated by
making nouns implicit. Whether or not this results in spectacular speed
increases, tacit J programs with their hooks, forks and trains are a devil
to decipher. In my opinion, this is a needless price to pay to gain
brevity.
With tacit J the composition default was also removed, and this
hook-and-fork logic was added, expressed in my words.
Now, this may sound completely crazy, but I would think that J would
benefit tremendously if it were rewritten to use parameter stacks for nouns
x and y, and explicit stack operators instead of a bunch of complicated
rules to handle passing around 'invisible' parameters. Why do I think this?
Because I co-authored a book with the late Mahlon Kelly "FORTH: A Text and
Reference" Kelly and Spies, 1986, Prentice Hall. Forth was ridiculed by
many for also having implicit values that were passed around on a parameter
stack (and, optionally, even the return stack) to 'words' (short routines),
each of which usually had requirements for something (one or more items)
on the stack and optionally left something on the stack with finished and
control passed to the next word, etc. This is expressed by a stack diagram
( x y -- z), which in some dialects (e.g. Factor) is used as a way of
verifying that the stack effects of words was actually as stated.
I must admit in most cases I prefer long variable names. I appreciate
brevity only for small snippets, then often with long documentation to
accompany them. Words are important tools of my thoughts. Before I have
the solution clearly described in words it is not likely to be good. I
expect programs to be like articles in newspapers.
I know the consequences of having important company information encoded
in programs no one can read, so I always try to sell my ideas of
self-documented code, tests as documentation and analysis documentation.
If you ask me, there is no reason to work at a prompt and use short
names of variables and functions. When I started working in APL at a
teletype in 1979 there was, now there isn't.
Humans are very bad at keeping things in their mind. We can
simultaneously keep 5 to 7 things in our mind. Out of sight, out of
mind. So I think the implicit variables of tacit J is a major mistake.
J doubtless uses the stacks for all sorts of things internally. Why not
adopt explicit stack operators to manipulate implicit data, without
sacrificing any of J's functionality. This would encourage a great deal
more factoring of code into short, reusable functions, retaining brevity
while increasing readability.
I am not saying stacks can not be used.
On Wed, Aug 3, 2016 at 3:24 AM, Erling Hellenäs <[email protected]>
wrote:
Yes.
My article is about JWithATwist and the choice of syntax between the tacit
J syntax and a modified explicit J syntax.
https://erlhelinfotech.wordpress.com/2016/08/01/jwithatwist-or-tacit-j/
My example concerns the use of notation for communication. Maybe the word
"specification" was not well chosen.
Anyway, good to know that APL can be compiled.
/Erling
On 2016-08-02 15:52, Robert Bernecky wrote:
On 16-08-02 03:29 AM, Erling Hellenäs wrote:
I would for example like to be able to take the result of my analysis
and give to the C programmer as a specification.
You can already do that, if you write the analysis code in APL, and hand
it to
an APL compiler, of which there are several about. Writing a J front end
for
the APEX compiler would not be a huge effort; the remainder of the
compiler
would just work (modulo rational numbers and other J-only features, which
could be added on an as-needed basis).
Bob
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
