A tip for readability, applogies for mentioning previously, is to avoid writing
hooks. Use forks instead. Put spaces between the fork elements, and use a
capitalization scheme for nouns and modifiers.
If you can assume you are reading a fork, you can skip the counting part. You
will know the even thongs are dyadic, and you should be able to guess from the
odd thongs whether the verb is meant to be called monadically and/or
dyadically. The presense of @:] or [ ] being the biggest clues.
If you can assume you are reading a fork, then you can examine odd thongs from
the left or right. If you can identify one odd thong as implying that it is
monad or dyad, then you know the valence of the whole expression (and other
thongs)
When you see @ or @:, you should know that everything to the left is called
monadically. & can be more mysterious, but if it is between 2 verbs, you
should assume that it is dyadic because @ or @: would normally be used
monadically. If & is between noun and verb, you can presume (special code
makes the assumption sometimes wrong) that it is a monad.
With experience, you may make first assumptions regarding common verbs. In odd
fork thongs, i., #, I. {. {: ". are somewhat more likely to be monadic. + - *
<.@% { {:: | ~: are likely dyadic.
Make no assumptions if you see ~ or / . ~ can be too many things. Though it
is most frequently passive (dyad), you will feel like staring at goats if you
always conclude that it is passive when its not. Some combinations (/:~) are
more likely to be monadic or (i.~ #~) dyadic. / is commonly monad, but is also
a special efficiency enhancement for dyadic "0 1.
While I just mentioned that ~ can make code less readable, it could also be
used to strategically make code more readable (as to dyad vs. monad). i. and #
in an odd fork thong might be presumed monadic, but since i.~ and #~ are mostly
likely dyadic, it may be a useful readability convention for you.
With these strategies, I might claim that a long fork is more readable than a
short fork (or several short forks combined) because a long fork needs only
have its valence pass done once, and there are more clues (odd thongs)
available to make the decision.
On another note, it would be helpful to have a valence error be its own error
instead of domain error, at least for 3 : and : [: . But calling a function
with something and getting a domain error may most likely be either a valence
error or an invalid argument type. Calling with i.0 as the something will
often not cause an invalid argument type (domain) error as both string and
number arguments can sometimes pass. Calling with a: may let the function pass
if it expects boxed string or number.
----- Original Message -----
From: Erling Hellenäs <[email protected]>
To: [email protected]
Cc:
Sent: Sunday, July 13, 2014 6:41:14 AM
Subject: Re: [Jprogramming] Design goals readability and writeability?
Most of the &'s and @'s are written not because they are needed as
operators, but are used only as padding, to avoid the othervise
automatic creation of hooks and forks?
When you analyse a train, the first thing you have to do is count the
number of verbs? Dependant on if it starts with a hook or a fork the
interpretation is very different? Counting verbs is not that easy since
you have to consider what is adverbs, conjunctions and corresponding
m's, n's, u's and v's?
The consequenses is you can't read a train, but have to try to pick out
pieces and verify them in the console?
Of what use is a notation that is unreadable? /Erling
On 2014-07-13 11:45, mvillarino wrote:
> Being a novice on J my oppions should be take with a grain of salt,
> but here we go:
>
> Most of the J code I read takes me a not so short time as desirable
> to be understood. Then the moment I'm able to get understand (?) it
> is more an aha! moment than the typical "oh, I see" you get with other
> languages like python, lucid, or, well, you name it.
> In order to speed up a little code samples posted to this list - for
> me the main source of examples to learn from- , most of the time I
> make use of online tools (touchquery; the one from uni-potsdam). The
> acceleration comes from two sides:
> a) Immediate access to J vocabulary docs.
> b1) No need to figure out if a verb is in the monadic or diadic case,
> b2) Grouping (tree viewing) is made explicit, so the "intent" is a
> little clearer.
>
> Two other factors seems to make the code I have seen written with J criptic
> are:
> . Not using of mnemonic names for concepts used within expressions.
> . In general, definition of verbs in a "where"-language manner is not
>used.
> . Tacit definitions appearance. They look like non tacit but with @
> and & instead of x and y. Much more at and et that x or y!
>
> Regards,
> Marcelino
>
>> But readability is a real problem. What is usually missing from many
>> programs, especially J tacit, is the intent of something. Say I see
>> something like this:
>>
>> < @ (({. + i.@{:)@[ { ] )
>>
>> It would certainly help to have some idea what this is supposed to do. What
>> its arguments are and what it returns. Documentation really helps.
>>
>> But J expressions can be intimidating. It has always bothered me that I
>> could attack a FORTRAN program spanning several pages comfortably. But a J
>> program of just a few lines which do exactly the same thing is hard for me
>> to get into.
>>
>>
>> On Sat, Jul 12, 2014 at 12:23 PM, Erling Hellenäs <[email protected]>
>> wrote:
>>
>>> Hi all !
>>>
>>> Yes, maybe we should all be concerned about writing readable code instead
>>> of the shortest and most cryptic code? Maybe we should also write writeable
>>> code? Find a way to write that allows us to get the expressions right the
>>> first time?
>>> J is more of a notation than a language? The value of a notation is
>>> determined by clarity, but also readability? Maybe readability and
>>> writeability, in the sense I explained above, should get higher priority as
>>> design goals for our future J?
>>>
>>> Cheers,
>>>
>>> Erling Hellenäs
>>>
>>>
>>>
>>> On 2014-07-12 07:40, Raul Miller wrote:
>>>
>>>> I would not generalize to higher rank arrays without a model of why I'd be
>>>> using them.
>>>>
>>>> In other words, v=: {"_1 |:~&0 2 is probably good enough.
>>>>
>>>> There are some interesting contradictions here - while one needs to be
>>>> comfortable thinking mathematically to get decent performance out of a
>>>> system, usually what we are building is a mix of instant and delayed
>>>> gratification and we usually assume our audience has no direct interest in
>>>> the math we are performing (indirect interest, yes - sometimes).
>>>>
>>>> Often I think we go overboard, and we should throw back in some exposure
>>>> to
>>>> some of the more robust concepts (especially for the kids, so they have
>>>> something interesting to play with). But professional adults tend to be
>>>> under a lot of time pressure, and as a result their needs often seem to be
>>>> a mix of the very basic and the childish.
>>>>
>>>> Meanwhile, it seems like anything worthwhile takes time and effort.
>>>>
>>>> Anyways, professional software design often centers around use cases and
>>>> similar models which are aimed at extracting the important concepts about
>>>> what people need to get done and how they want to work. And that kind of
>>>> information is what you need if you are going to properly generalize
>>>> application code.
>>>>
>>>> Thanks,
>>>>
>>>>
>>> ----------------------------------------------------------------------
>>> 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
