Tacit programming becomes more natural when following funtional(or
funtion-level) paradigm.

However, if you really want a tacit version:

items=...@#@".@('TT'"_)

(If hiding TT is that important, I might use OOP approach in J)


On Mon, Dec 21, 2009 at 4:01 AM, Ian Clark <[email protected]> wrote:
> Too right.
>
> My aim in using a function to calculate "items" based on the (current)
> TT was to avoid using a global variable as a cache, like this: items
> =: i. #TT
>
> It seems that:
>
>   items=: 13 : 'i. #TT'
>
> is no better / no different, because it explicitly snapshots the value
> of #TT. (...Sometimes.)
>
> What's the correct way of implementing "items" tacitly? ... Is there one?
>
> Ian
>
>
> On Sun, Dec 20, 2009 at 6:46 PM, Jose Mario Quintana
> <[email protected]> wrote:
>>>BTW Who'd care to volunteer what was wrong with my whole approach to
>>>"items"? I bet I get a different answer from everybody. I have my own
>>>answer of course. But I'd like to hear others' first.
>>
>>    items
>> "_1
>>    erase'items'
>> 1
>>
>>    items=: 13 : 'i. #TT'
>>    items
>> 3 : 'i. #TT'
>>
>>    TT=. i.2 3
>>    items=: 13 : 'i. #TT'
>>    items
>> 0 1"_
>>
>>
>>
>>
>>
>> ________________________________
>> From: Ian Clark <[email protected]>
>> To: Programming forum <[email protected]>
>> Sent: Sun, December 20, 2009 11:02:01 AM
>> Subject: Re: [Jprogramming] Tacit exercise
>>
>> Let me take issue with Björn (amicably :) over this. It's not just a
>> matter of taste. It is what suits you -- for the sort of coding you
>> do. Number theory research? You'll love J for its freedom from anal
>> clutter.
>>
>> If you're like me, mostly building products for sale, then Andrew is
>> right. Psychology holds the key. Gerry Weinberg (in "The Psychology of
>> Computer Programming" http://tinyurl.com/2mvj57) tells the tale of
>> $K's being spent (at 60's costs) to track down a single bug: a memory
>> location labelled ONE which once in a while held the value 2.
>>
>> To me, what distinguishes software developers from bit-pushers is the
>> lengths they'll go to avoid the Weinberg Bug.
>>
>> I've coded in anger with scores of languages, most now thankfully
>> defunct. What makes a bad language for me (or a construct to avoid) is
>> one that "says" something else than what it actually does.
>>
>> To me, programming is all about Binding. Names to entities. Arguments
>> to functions. Values to variables. Numerals to each other to make
>> vectors. And eventually $$$ to my wallet. What matters is when the
>> binding happens. Strictly right-to-left in an expression? When the
>> expression is executed? When the function is called? When the app is
>> run -- or actually when it's written?
>>
>> This is why I get a bad feeling with code residing in strings executed
>> at run-time. Also global vars. They save you having to think too hard
>> when writing the code in the first place. But all that's wasted when
>> you have to manage a bug-farm. 'Cos globals are caches -- and there's
>> always sometime when a cache is out of date.
>>
>> That's why I was deeply unhappy recently when I found myself writing:
>>
>>   items=: 3 : 'i. #TT'    NB. the valid indexes of rows of TT, a
>> user-loaded table, which can vary.
>>
>> Why was I unhappy? For every single one of the reasons I've stated.
>>
>> So, being a J rabbit, I thought I'd be clever and "go tacit", making
>> that instead:
>>
>>   items=: 13 : 'i. #TT'
>>
>> and (shame!) I neglected to look at how "items" actually got coded.
>> Oh-no! The Weinberg bug. To me the two expressions "say" the same
>> thing -- but they aren't!
>>
>> I spent the whole evening writing code that tested-out ok -- as I
>> thought. Until I started up J the next day. That's when the bug first
>> appeared.
>>
>> MORAL: go tacit where you can... but go canny!
>>
>> BTW Who'd care to volunteer what was wrong with my whole approach to
>> "items"? I bet I get a different answer from everybody. I have my own
>> answer of course. But I'd like to hear others' first.
>>
>> Ian
>>
>>
>> 2009/12/20 Björn Helgason <[email protected]>:
>>> I think it is rather the opposite that most objections to J has been
>>> from people who do not understand tacit.
>>> The explicit definitions are not at all ugly either.
>>> I think it is more a matter of taste and understanding.
>>>
>>> The explcit definitions and comments are often much better and
>>> especially for beginners.
>>>
>>> Tacit programming can be very nice and it can also be horribly complex
>>> and scary looking.
>>>
>>> 2009/12/20 Andrew Nikitin <[email protected]>:
>>>>
>>>> I think the reason that so many people dislike explicit definitions is 
>>>> because they are syntactically ugly. Multiline is only mildly ugly, but 
>>>> single line is a freak. Come on,
>>>>
>>>> length=:3 : '%: +/ *: y' ?
>>>>
>>>> Bleah. Clean, easy to read and still bleah.
>>>>
>>>> This and only this fuels myth of alleged superiority of purely tacit 
>>>> expressions.
>>>> Because ugly cannot be good.
>>>>
>>>> _________________________________________________________________
>>>> Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
>>>> http://clk.atdmt.com/GBL/go/171222985/direct/01/
>>>> ----------------------------------------------------------------------
>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>>
>>>
>>>
>>>
>>> --
>>> Björn Helgason, Verkfræðingur
>>> Fornustekkum II
>>> 781 Hornafirði
>>> Po Box 127,801 Selfoss ,
>>> t-póst: [email protected]
>>> gsm: +3546985532
>>> sími: +3544781286
>>> http://groups.google.com/group/J-Programming
>>>
>>>
>>> Tæknikunnátta höndlar hið flókna, sköpunargáfa er meistari einfaldleikans
>>>
>>> góður kennari getur stigið á tær án þess að glansinn fari af skónum
>>>          /|_      .-----------------------------------.
>>>         ,'  .\  /  | Með léttri lund verður        |
>>>     ,--'    _,'   | Dagurinn í dag                     |
>>>    /       /       | Enn betri en gærdagurinn  |
>>>   (   -.  |        `-----------------------------------'
>>>   |     ) |         (\_ _/)
>>>  (`-.  '--.)       (='.'=)   ♖♘♗♕♔♙
>>>   `. )----'        (")_(") ☃☠
>>> ----------------------------------------------------------------------
>>> 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
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to