[Jprogramming] Design goals readability and writeability?

[Don Kelly]

Point taken:
However, I do like to save some things that are not always used- along 
with variations and reminders-such as why @: works and @ doesn't in the 
context of concern. Sometimes I have a nice tacit string (or a multiline 
explicit form) which I have saved in a script along with comments and 
how-to-use information and example(s). This documentation  does help me 
when I haven't used the verbs  for some time. I did this for APL.
I see a lot of 1-line fairly complex verbs on this forum and often have 
trouble sorting them out-when I do, I have learned something, when I 
can't I haven't learned anything and crawling the dictionary doesn't 
always help.

It is true that comments are important in any language but the 
difference is that APL and, more to the point, J  inherently pack a lot 
more punch to a line- due to the array power as well as the large range 
of primitives- instead of reading a number of simple statements, often 
in a loop, and often where the grammar is stilted and simple, one is 
faced with a great deal of power and many ways to deal with the same 
problem- as evidenced by the variations of some verb presented on this 
forum.

Don Kelly




On 13/07/2014 6:39 PM, Ian Clark wrote:
> "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 <dhky at shaw.ca> 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 <
>>> erling at erlinghellenas.se>
>>> 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