________________________________________ From: [email protected] [[email protected]] On Behalf Of Henry Rich [[email protected]] Pepe Quintana writes large tacit systems. Maybe he can tell you to do it. ________________________________________
Well, I probably would neither tell anybody to do it tacitly, nor in J, for that matter (unless he or she is an employee of the firm). However, I can give an insight why I decided to do so, and I also can say that I have never regretted it; on the contrary, I have always enjoyed the ride. It has been a decade since I decided to migrate, a trading system, from APL to tacit J. There were two main reasons: it was intellectually challenging and therefore amusing; and point-free, or pointless (depending on your viewpoint), programming surely would have its benefits (see, for example, http://www.jsoftware.com/pipermail/programming/2007-February/005315.html and references therein). A group of us continues to develop, maintain and operate the system without difficulty. We had to create our own tools to facilitate the process because it is apparent that J was not designed to be used, or abused, in this way. However, it has been happily crunching numbers, and characters, this way without any complaints. I cannot pass the opportunity to note that after all these years the seemingly innocuous change from x. y. … to x y … remains a mischievous troublemaker. I thought that I was immune to these side effects (see, http://www.jsoftware.com/pipermail/beta/2006-April/000825.html ) but not so long ago, while experimenting, I stared hopelessly for an awful long time trying to make sense of something similar to this: v=. ] 7!:2 'v 0' 704 w=. v f. 7!:2 'w 0' 768 I could have been bitten because I usually smile and move on when I browse reports of problems involving x y n … ________________________________________ From: [email protected] [[email protected]] On Behalf Of Henry Rich [[email protected]] Sent: Monday, September 26, 2011 8:54 PM To: Programming forum Subject: Re: [Jprogramming] Tacit vs. Explicit Paradigm and its Long-Term Impact I think it is a mistake to use tacit programs for anything that might possibly be rewritten. When you have a well-defined task, you can make it a tacit verb. For normal work, write explicit verbs. The problem with large tacit systems is just as you said: maintainability. And, there's not much to gain from tacit verbs. The important thing is to get the design right, and implement for ease of debugging and maintenance. That doesn't mean that tacit programming is useless. Whenever you write a hook, fork, or compound verb, you're doing a little bit of tacit programming. Just don't go overboard. I keep a file with all my well-thought-out tacit programs, which I use as utilities in the (explicit) rest of my code. Perhaps 2% of a large system will be tacit verbs. The reasons to use J are speed of coding, ease of debugging, robust implementation, ability to fix bugs instantly, expressiveness. To me, large tacit systems forfeit some of those advantages. Pepe Quintana writes large tacit systems. Maybe he can tell you to do it. Henry Rich On 9/26/2011 8:38 PM, Christopher McIntosh wrote: > (Despite the conversations that have brought us to this point -- and > ignoring that scenario altogether) I have a hypothesis that for the > long-term, a team equipped in a J-focused environment needs to have a very > detailed design-time road map to avoid a possible scenario in its project > whereby re-designing one aspect has a negative and significant impact on > unrelated aspects of the project. For our team, we had become interested > in J because of highly regarded recommendations about its fit into an XP > environment. At the same time, it appears that folks are suggesting that > design decisions are required to be made earlier (moreso comparable to the > waterfall paradigm). And this is important to the long-term maintainability > (in terms of cost and time) of the project. > > For example, when considering a function (or function group) and choosing > the tacit implementation, I have been advised from 2 (seemingly?) > incompatible perspectives. > > One one hand, it is my understanding that one of the primary advantages to a > tacit design is the ability to abstract a dependency on names. On the other > hand, I understand that, in an ambivalent function, such is not the case. > That, unfortunately, this won't work for the dyadic half, since it could > not distinguish between local x and global x, as x is defined locally in > both the verb and the adverb. > > And when I look at some implementations, I see that this appears to be the > case. > > NB.*nl v selective namelist > NB. Form: [mp] nl sel > > NB. > NB. sel: one or more integer name classes, or a name list. > NB. if empty use: 0 1 2 3. > NB. mp: optional matching pattern. If mp contains '*', list names > NB. containing mp, otherwise list names starting mp. If mp > NB. contains '~', list names that do not match. > NB. > NB. e.g. 'f' nl 3 - list verbs that begin with 'f' > NB. '*com nl '' - list names containing 'com' > nl1=.(([:4!:1])&(]`(0 1 2 3"_)@.(0=#))) :: cutopen_*z*_ > nlz=:(nl1 : ((4 : 0)nl1)) f. > if. 0 e. #y do. y return. end. > > if. #t=. x -. ' ' do. > 'n s'=. '~*' e. t > t=. t -. '~*' > b=. t&E.&> y > if. s do. b=. +./"1 b > else. b=. {."1 b end. > y=. y #~ n ~: b > end. > ) > > I see that (on the dyad side of the picture) there is still reference to > local x. But, this should not be an issue, should it? Since we could go > ahead and reference x__anotherlocale. In my prima facie testing, I don't > notice the issue. Tests which had failed in previous tests, pass with this > example. > > I realize that the road ahead is a long one to become proficient at > recognizing some of the subtleties that, presently, have us perplexed. > ---------------------------------------------------------------------- > 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
