Re: [Jprogramming] Code clarity

2014-01-13 Thread Roger Hui
I find that it helps to describe the J or APL code as if you are writing a paper about it for the expert. For example, see the essays in the J wiki. If carried to the extreme, it becomes the Literate Programmingof Knuth. In such writing it is u

Re: [Jprogramming] Code clarity

2014-01-13 Thread Don Kelly
I have had considerable experience with APL What I have found is that it is important, more than with many other languages, to document the code. With J it is even more important. This is a consequence of the power involved in a statement combined with what the hell did I mean when I wrote it

Re: [Jprogramming] Code clarity

2014-01-13 Thread Raul Miller
Ok, I think I understand. The basic issue, here, seems to be that PicoLisp is stream oriented and this is a stream oriented task. No one in the J community has cared enough to build a stream oriented library for J. J has enough to do stream oriented design for academic purposes, but ... Consider x

Re: [Jprogramming] Code clarity

2014-01-13 Thread Joe Bogner
Yes, it is complete. I didn't write it or test it as it was already posted to rosettacode. I will explain how it works assuming there is interest It uses some uncommon tricks. It leverages the read function which is the same function used in the repl to read input characters. So the goal is to ta

Re: [Jprogramming] Code clarity

2014-01-13 Thread Raul Miller
On Mon, Jan 13, 2014 at 8:32 PM, Joe Bogner wrote: > PicoLisp > > (de rdConf (File) >(pipe (in File (while (echo "#" ";") (till "^J"))) > (while (read) > (skip) > (set @ (or (line T) T)) ) ) ) Is that complete? I learned lisp back in highschool, and I've used drracket

Re: [Jprogramming] Code clarity

2014-01-13 Thread Devon McCormick
Dan's question is relevant and, for me, very timely as I am preparing a talk for a week from now and am wrestling with how to convey the notion of J as a tool of thought. It's hard because what Dan wrote, for instance, looks like gibberish unless you know enough J to make sense of it but who would

Re: [Jprogramming] Code clarity

2014-01-13 Thread Pascal Jasmin
 deb L:0@:(({.~ ; [: < [: ;^:(1=#) ',' cut (}.~>:)) i.&1@:e.&' =')&>@(#~ > a:&~: > ';#'e.~{.&>)@:(dlb&.>)@:(LF&cut) completely untested if the following is equivalent, but: 3 : ' deb leaf (({.~ ; [: < [: ;^:(1=#) ',' cut (}.~>:)) i.&1@:e.&' =')&>@(#~ > a:&~: > ';#' e.~ {.&>) dlb each LF cut y'

Re: [Jprogramming] On benchmarking results from J programming styles

2014-01-13 Thread Pascal Jasmin
the pfns timings surprised me. pfns =: 3 : '({.,_1&+@({.@}.),{:)`(_1&+@{.,15"_,{:)@.(0&=@({.@}.)) y' On simple function tests where I take an implicit definition and just make it explicit by adding y at the end, I've gotten an under 10% slowdown. I would guess that you could see a comparable re

Re: [Jprogramming] Code clarity

2014-01-13 Thread Joe Bogner
Great question! > So, how would you write an configuration file parser in J, if clarity were > an important concern? I find it helpful to identify the audience when writing - code or non-code. I then try to write for the audience. If there won't be an audience other than a computer and I will nev

Re: [Jprogramming] Code clarity

2014-01-13 Thread William Tanksley, Jr
Raul Miller wrote: > I'll counter your suggestion that it's easier to write unreadable code > in APL derivatives with an observation that looks to me like a social > issue rather than anything intrinsic in the language. Fascinating and very plausible. But I wasn't intending to talk about ease of

Re: [Jprogramming] Code clarity

2014-01-13 Thread Raul Miller
I'll counter your suggestion that it's easier to write unreadable code in APL derivatives with an observation that looks to me like a social issue rather than anything intrinsic in the language. I say this because with minimal training (one class in APL at a community college, and occasional use i

Re: [Jprogramming] Tacit?

2014-01-13 Thread Raul Miller
It's clear that the interpreter does delete old copies sooner or later, otherwise J would crash from out of memory errors after extended operations. (It's a reference counting implementation - not so good for fine grained performance but excellent for large flat arrays.) I will agree that some nu

Re: [Jprogramming] Code clarity

2014-01-13 Thread William Tanksley, Jr
Dan Bron wrote: > We often say the APL family of languages allow us to use language as a tool > of thought. How does this play out in practice? Do we approach reading J > programs differently from those written in other languages? If so, how? I think this is a fantastic question. I completely

Re: [Jprogramming] Code clarity

2014-01-13 Thread Björn Helgason
I often write something clear and commented. Then try to make it look smart -sort of looking compiled - and stop understanding it. Ok maybe not often... On 13 Jan 2014 19:31, "km" wrote: > An important consideration is, "clarity for who"? I want the code to be > clear to me when I come ba

Re: [Jprogramming] Tacit?

2014-01-13 Thread Henry Rich
You have a point, IF the interpreter can figure out when a copy can be deleted. Often it can't. We would need the exact code to be sure. Code that modifies part of an array is often - I would say usually - faster when explicit. Henry Rich On 1/13/2014 3:14 PM, Raul Miller wrote: Could you

Re: [Jprogramming] Tacit?

2014-01-13 Thread Raul Miller
Could you explain your reasoning? I understand O(n^3) time from the multiple copies - you have O(n^2) time cost multiplied by n repetitions. But space cost should be O(n^2) -- the number of copies of the array needed should have a fixed upper bound, because previous temporary copies do not need to

Re: [Jprogramming] Tacit?

2014-01-13 Thread Henry Rich
In Kip's context (repeatedly amending an array), m} is still going to create new copies of the array, leading to memory use of O(n^3). An explicit version that uses assignment in place will be leaner for large n. Henry Rich On 1/13/2014 2:50 PM, Raul Miller wrote: This is probably too much

Re: [Jprogramming] Tacit?

2014-01-13 Thread Raul Miller
This is probably too much information, and unnecessary, but maybe someone will find some part of it useful. http://www.jsoftware.com/help/dictionary/d530n.htm says If m is a gerund, one of its elements determines the index argument to the adverb } , and the others modify the arguments x and y : x

Re: [Jprogramming] Tacit?

2014-01-13 Thread Jose Mario Quintana
Also, for all those tricky sentences such as, ( X=. 2 3 0 ) 'x ({. x)} y'(13 :) ( Y=. i. 3 3 ) 0 1 2 3 4 5 2 3 0 'x ({. x)} y'(13 :) 4 : 'x ({. x)} y' There is always an underground (no tears for the brave) alternative: construct the atomized version (so to speak) of the previously proble

Re: [Jprogramming] Code clarity

2014-01-13 Thread km
An important consideration is, "clarity for who"? I want the code to be clear to me when I come back to it later. For that reason I usually code explicitly, calling explicit helper verbs, although many of the lines are "tacit in spirit". Suggestive names help. --Kip Murray Sent from my iPad

Re: [Jprogramming] Code clarity

2014-01-13 Thread Dan Bron
Sure, but the C compiler doesn't write its code for human eyes to read. The programs we write in J are (usually) intended for both computers (i.e. the J interpeter) and people (e.g. ourselves, our code maintainers, people we're bragging to, etc). -Dan - Original Message --- Subj

Re: [Jprogramming] Code clarity

2014-01-13 Thread Raul Miller
I find that my experiences and insights from working with J transport to other languages (often with some frustrations, but life is full of frustrations) in a useful fashion. It would take some time, but I imagine you could translate that code you wrote into another language (perhaps paraphrasing

Re: [Jprogramming] Code clarity

2014-01-13 Thread Björn Helgason
If you try to read compiled executable code from C it would not be very readable. On 13.1.2014 18:45, "Dan Bron" wrote: > We often say the APL family of languages allow us to use language as a tool > of thought. How does this play out in practice? Do we approach reading J > programs differently

[Jprogramming] Code clarity

2014-01-13 Thread Dan Bron
We often say the APL family of languages allow us to use language as a tool of thought. How does this play out in practice? Do we approach reading J programs differently from those written in other languages? If so, how? These questions occurred to me today while I was knocking together an imple

Re: [Jprogramming] Tacit?

2014-01-13 Thread km
Linda, see the definition of Amend } . Below the two gray boxes there is a paragraph beginning "If m is a gerund". --Kip http://www.jsoftware.com/docs/help701/dictionary/d530n.htm Sent from my iPad > On Jan 13, 2014, at 3:17 AM, "Linda Alvord" wrote: > > Raul, What happens to M when you in

Re: [Jprogramming] Tacit?

2014-01-13 Thread Linda Alvord
Raul, What happens to M when you involve } I don't understand how and what definition of } is used. u=:2 3 0 v=:i.3 3 GG=: 13 :'x`({.x)`y' ]M=: u GG v 2 3 0 2 0 1 2 0 3 4 5 0 6 7 8 0 HH=: [`([:{.[)`]} u HH v 0 1 2 3 4 5 2 3 0 5!:4 <'GG' -- 4