Amongst many other reasons that I like J (very consistent, expressive and mind bending!) better than most other languages is the ability to easily modify the shapes of all sorts of data to see how function[s] will behave with the modified data. I'm by no means an expert programmer (doing it as a hobby for about 10 years now...and J only since 2012...no APL experience!!) but this one aspect makes experimenting for solutions so much better than any other alternatives! If lisp/perl/python/ruby make a programmer more productive/efficient by providing REPL then J/APL make a programmer more enlightened by providing a set of functions to easily modify/reshape data for exploration. At least, in my opinion. I still cannot do anything useful in J (yet! I'll get there though...I think) but it has helped me get better (enormously) in R and python (with numpy/scipy)! So, for the benefits that I get from learning J I'm willing to pay the costs (uncertainty, and the constant necessity to reference documentation...more so than other languages).
On a side note check out https://research.microsoft.com/en-us/um/people/lamport/pubs/euclid.pdf (by Leslie Lamport ... of LaTeX fame) describe what Euclid would feel of contemporary programming. Pardon me if I've merely created noise. On Sun, Jul 13, 2014 at 7:19 PM, Raul Miller <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
