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 <[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
