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
