Tracy, The subject of your question in your message below concerns a controversial subject; for what it is worth, my personal view and experience follow.
The reason why we always program tacitly and we generate implementation function-level code in my company is that I find easier to do it this way. As Roger mentioned, I have stated this before (see, for example, http://www.jsoftware.com/pipermail/programming/2005-November/000137.html , http://www.jsoftware.com/pipermail/programming/2005-November/000149.html and http://www.jsoftware.com/pipermail/general/2003-April/014504.html ). (Nevertheless, we allowed ourselves the liberty to occasionally call explicit (hybrid) utilities distributed with the J system; after all, some J facilities were clearly not designed for full functional programmers (e.g., GUI).) My turning point occurred shortly after I realized that there is always a way to program any verb tacitly, in other words, J tacit programming is Turing complete (see http://www.jsoftware.com/pipermail/general/1999-December/002736.html ). Some practical implications of tacit programming that I like are: 0. Self-contained function-level verbs are generated by f. (there is no need for the Project Manager which I have never used). 1. We have virtually no name conflicts (we only need to worry about the names being used in the body of the verb at hand). 2. Large systems are built by means of loading and dynamically execute (very long one-liners, if necessary) fixed self-contained code. 3. Modular (even remote) maintenance and upgrading of large systems, is straightforward. 4. There is no need to think about global or local definitions, locales, etc. 5. Performance is very competitive, to say the least (some code optimization, implemented by the best one, is automatically done when is appropriate). 6. I do not have to be, and I am certainly not, an expert about the J rules of execution. I simply ask J to display a tacit verb in box form and all is as clear to me as it can ever be. 7. A potential future benefit, as pointed out by John Randall recently http://www.jsoftware.com/pipermail/general/2007-February/029036.html , is that functional programs are well perched for parallel execution (although forks would have to be reverted back to the good old-fashion way to take a better advantage). 8. It seems that often tacit coding naturally yields to space savings. For example, a coding of the D4 wavelet transform recently posted ( http://www.jsoftware.com/pipermail/programming/2006-December/004523.html ) performs as follows, FF=. ?(2^20)$0 ts 'D4a FF' 0.682162 1.17477e8 A straightforward tacit translation quickly yields some savings, ts 'd4a FF' 0.679793 8.38959e7 and with a little more tweaking results in, ts 'd4 FF' 0.684995 6.71186e7 not bad, I think. However, the often cited issue with tacit programming is that, C1=: 1.7320508075688772 C2=: 0.4330127018922193 C3=: -0.066987298107780702 C4=: 0.51763809020504137 C5=: 1.9318516525781364 D4a=: 3 : 0 e=. y#~(#y)$1 0 d=. (y#~(#y)$0 1) - C1*e s=. e+(C2*d)+C3*1|.d , (D4a^:(2<#y) C5*s) ,. C4*d+_1|.s ) is obviously more readable than, d4=. (,@:(((2 < 3&({::)) $:@:]^:[ 1.9318516525781364"_ * 1&({::)) ,. 0.51763809020504137"_ * 2&({::) + _1 |. 1&({::))@:((<@:(1&({::) + (0.4330127018922193"_ * 2&({::)) + _0.066987298107780702"_ * 1 |. 2&({::)) 1} ])@:((<@:(((3&({::) $ 0 1"_) # 0&({::)) - 1.7320508075688772"_ * 1&({::)) 2} ])@:((<@:((3&({::) $ 1 0"_) # 0&({::)) 1} ])@:((<@:(#@:(0&({::))) 3} ])@:(3&(] , [ # a:"_)@:<)))))) just as, Is it you?, are you real? Some had talked nonsense oh, you, by whom everything lives, Is it real?, Is it not real? This is how they say it Do not have anguish in our hearts! I will make disdainful oh, you, by whom everything lives, Do not have anguish in our hearts! is obviously more readable than, Zan te te yenelli aca zan tlahuaco in ipal nemoani In cuix nelli ciox amo nelli? Quen in conitohua in ma oc on nentlamati in toyollo.... zan no monenequi in ipal nemoani Ma oc on nentlamati in toyollo That is, if you are not familiar with the latter forms of expression. (I find ironic that non-J programmers often criticize J's readability.) I hope the above helps. I have thought recently about writing a lab regarding tacit completeness but I have opted for indulging myself with some deliciously decadent activities instead. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:programming- > [EMAIL PROTECTED] On Behalf Of Tracy Harms > Sent: Saturday, February 24, 2007 10:57 PM > To: [email protected] > Subject: [Jprogramming] function-level programming (was: tacit vs > explicitdefinition) > > Thank you, Raul and Roger, for your replies on the > roles of explict and tacit techniques of verb > definition. > > As I studied this topic tonight it occurred to me that > tacit programming seems to be necessary to (but > perhaps not sufficient for) function-level > programming. The topic of tacit definition seems to > open naturally to the question: When is > function-level programming a better way to use J, and > what discipline needs to be maintained to accomplish > it? > > The distinction between functional programming and > function-level programming was something I first > encountered in the Wikipedia article on J, which was > where I first became aware of J. (I linked there > while reading on the topic of functional programming.) > The distinction was one I had never heard drawn > before, and my interest in J was greatly piqued by the > indication that it better fits Backus' prescription > than do "standard" functional languages. I didn't > quite follow the distinction, and some confusion > remains for me today, but it does seem to me that my > recent attention to J has made the topic more > tractable. > > To date I'm relying on the Wikipedia article, > Function-level programming: > http://en.wikipedia.org/wiki/Function-level_programming > > NB. That article names J as a "canonical > function-level programming language". > > Roger, you listed four considerations in deciding > between tacit and explicit definition. It looks to me > that the second and fourth of these are relevant to a > function-level approach. ("Tacit is more amenable to > formal manipulations" and "Tacit encourages building > up a more complex function from components.") > > More information on the relationship between J and > function-level programming would be welcome. (Perhaps > I've missed references to applicable papers?) > > > Tracy Harms > > > > __________________________________________________________________________ > __________ > Want to start your own business? > Learn how on Yahoo! Small Business. > http://smallbusiness.yahoo.com/r-index > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
