This is not unique to APL. I've seen similar issues with .Net programs, with C programs, with Java programs with Ruby programs, with CP/M programs, etc. etc.
For that matter, I've seen analogous issues in non-programming contexts. In the context of APL, I've often found that finding representative example data, and watching how it gets transformed, tends to help make clear all sorts of issues. Ideally you want something complex enough to be interesting but small enough that you can see all of it. But it really doesn't matter what language I'm working with - I almost routinely need to review the definitions and reference documentation. Whenever I feel I don't understand something adequately it's time to go back and review the basics. It's a good way of getting unstuck (but not the only way - for example: performing experiments is also important, and sometimes sketching out details on a piece of paper or in a text editor or just talking with someone can be the right thing to do). FYI, -- Raul On Sun, Jul 13, 2014 at 6:58 PM, Erling Hellenäs <[email protected]> wrote: > Yes. and I remember an APL program neither I nor anyone else available could > understand. Terse code, all one or two character variables. Without any > documentation whatsoever. With one for the customer very annoying bug. After > quite some time someone made an interpreter for the output where he could > patch it to get rid of the bug. /Erling > > > On 2014-07-14 00:43, Don Kelly 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
