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
