Each of us has our own little rules we try to apply, when we want to
understand the code. Just having something different to do with the code
gives us an opportunity to go in and play with it, to see how it works, and
to understand it.
In my case, I place the highest priority on understanding how it works.
And, for me, that means having an idea of what has happened with some
sample data at each stage of the computation. I don't memorize that, but I
feel a need to learn about some piece of code on a fairly frequent basis.
I also like eliminating "unnecessary" elements. This is not always a good
thing, but it's great for learning.
So, for example:
(#~ (1: |. (> </\)))@(' '&~:)) ' this is a test '
this is a test
(1: |. (> </\))@(' '&~:) ' this is a test '
0 1 1 1 1 0 0 1 1 1 0 0 1 1 0 0 1 1 1 1 1 0 0 0
That 1: shows that this is old code, we can use 1 now (without the :) to
achieve the same end on current J interpreters.
(> </\)@(' '&~:) ' this is a test '
0 0 1 1 1 1 0 0 1 1 1 0 0 1 1 0 0 1 1 1 1 1 0 0
</\@(' '&~:) ' this is a test '
0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
These experiments reveal, to me, the structure and intent of the code.
Rephrased in english:
Select all the non-space characters, and select spaces which are
immediately to the left of a non-space character (but specifically
excluding the space which is to the left of the first non-space character).
Because we don't select the space to the left of the first non-space
character, we can use rotate (instead of the more verbose shift) to deal
with the adjacency issue (we always rotate a zero to the right end of the
expression).
The result has an economy of expression which "fits" the language. This
sort of micro-optimization (using rotate instead of shift) happens with
code written in any language, and can be thought of as being analogous to
an accent or a lilt. It's not functional in an abstract sense, and doesn't
need to be retained in a translation. Instead, it arises from the economies
necessary for existence. [You always have to make choices.]
But of course there are always other ways of doing things. Here's another
way to implement deb:
#~ 1|.(' '~:{:,{.),_1 }. 0=' 'E.}.
In other words: delete the first of each pair of spaces, and also delete
the first character if it is a space and the last character if it is a
space.
This takes advantage of E. which did not exist in APL:
The deb (delete extra blanks) utility in APL was more or less directly
translated to J. (Except of course, there's no J compiler, and in APL we
used a compiled version of deb, because we used it so often.)
(And, no, I didn't remember this sort of detail when I started writing this
response, the memories seem to be tied in with thinking about the code, and
might even be tied in with my fingers.)
Thanks,
--
Raul
On Mon, Jul 14, 2014 at 2:18 AM, Linda Alvord <[email protected]>
wrote:
> Here's deb without @ and &
>
> deb
> #~ (+. (1: |. (> </\)))@(' '&~:)
> deb2
> #~ ([: (+. (1 |. (> </\))) ' ' ~: ])
>
> However it seems as though there should be a better explicit version than:
> f=: 13 :'(#~[:(+. 1 |. (> </\)) '' ''~:])y'
>
> Linda
>
>
> -----Original Message-----
> From: [email protected] [mailto:
> [email protected]] On Behalf Of Linda Alvord
> Sent: Sunday, July 13, 2014 11:43 PM
> To: [email protected]
> Subject: Re: [Jprogramming] Design goals readability and writeability?
>
> I enjoyed your article:
>
> <"1 toupper"0>"0;:'alpha beta gamma'
> ┌─────┬─────┬─────┐
> │ALPHA│BETA │GAMMA│
> └─────┴─────┴─────┘
>
> Linda
>
> -----Original Message-----
> From: [email protected] [mailto:
> [email protected]] On Behalf Of Ian Clark
> Sent: Sunday, July 13, 2014 9:40 PM
> To: [email protected]
> Subject: Re: [Jprogramming] Design goals readability and writeability?
>
> "The alleged unreadability of J - and what to do about it"
> http://www.jsoftware.com/jwiki/Vocabulary/Unreadability
>
>
> On Sun, Jul 13, 2014 at 11:43 PM, Don Kelly <[email protected]> wrote:
>
> > Absolutely!!
> > J suffers from the same problem as its precurser APL- in spades.. One can
> > write very terse code because of its power. Often, 6 moths later the
> > original writer has to spend time interpreting what was written. I have
> > come up with some terse code and , more often terse code from others- all
> > of which has been put in a utility script wrapped in comments so that
> when
> > I want to use it-I do have such guidance. This is something one has to do
> > to a great extent with any programming language. It is even more
> important
> > with J tacit.
> >
> > Don Kelly
> >
> >
> > On 12/07/2014 11:44 AM, Don Guinn wrote:
> >
> >> Readability depends on a person's background. I can't read Chinese. Does
> >> that mean it's not a readable language?
> >>
> >> When writing a program or a document one must assume some level of
> >> knowledge of the reader. J tends to assume readers have a greater
> >> knowledge
> >> of mathematics than most other programming languages require.
> >>
> >> 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
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
