Ah yes, but you can write a large project tacitly before you're fully
equipped to do so. I did that on my first J project, and it was a real
trial by fire. A hundred tacit verbs, each dependent on the ones above
(the application was texture-map filtering for a flight-simulator database).
It worked great. It was fast. It was virtually unmaintainable. I
would hate for a new user to try that and give up on J.
It was a great experience, and I'd say it got me about 25% of the way to
being proficient at tacit programming, but I think being a stylite is an
easier job if self-improvement is what you're after.
J is fast to code and easy to change. Large tacit programs are hard to
change. Why go there?
Henry Rich
On 9/26/2011 9:16 PM, bill lam wrote:
> I guess it is too early to ask. Until you can write a large project with
> tacit form only, you do not have to choose.
>
> Пнд, 26 Сен 2011, Christopher McIntosh писал(а):
>> (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
