My (2) tips for readability: (1) avoid tacit programming, (2) if you cannot resist it, only use a few verbs, whether it is a fork or a hook.
R.E. Boss (Add your info to http://www.jsoftware.com/jwiki/Community/Demographics ) > -----Original Message----- > From: [email protected] [mailto:programming- > [email protected]] On Behalf Of 'Pascal Jasmin' via > Programming > Sent: zondag 13 juli 2014 17:15 > To: [email protected] > Subject: Re: [Jprogramming] Design goals readability and writeability? > > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
