> 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 ...
I think there is an over-emphasis on tacit programming in the J forums. There is the desire to look cool and keep emails short, but I agree that this can sacrifice readability. In production systems, most programs are explicit, and tacit used only where appropriate. For myself, when creating a new function, I quickly consider whether this is a trivial tacit definition such as isboxed=: 0 < L. and failing that use explicit. I rarely go to the trouble of building a long and complex tacit definition in a production system (but admit to having done so occasionally, more from curiosity than anything else). Efficiency is rarely a consideration nowadays. Browse through the J addons to get a feel for this, as a typical example in the plot source: jsoftware.com/websvn/wsvn/public/trunk/graphics/plot/source/base/draw/draw.ijs On 3 August 2016 at 07:46, Nicholas Spies <[email protected]> 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. > > 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. > > 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. > > 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. > > > 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
