Sorry, Dan -- none of that would work for me if I were a product manager. One with some control over which language to choose and to recruit my programmers for. Or more like it: which language to avoid. One sight of this thread and I'd say "toy language -- my staff will be spending all their time fighting the interpreter, not working with it." As I've seen in practice with APL. More than once.
Which is sad, because I see J as overcoming many of the problems of APL (any vendor's) when used as the development language for a commercial product with industrial-strength data. But you have to soak in J a bit before you become convinced of that. It won't have escaped notice that I'm fixated on improving J's uptake via documentation. On Wed, Sep 10, 2014 at 4:41 PM, Dan Bron <j...@bron.us> wrote: > When I see a newcomer (not you, Ian, obviously) raise such concerns as "how > do I do updates in place?", my typical response to this is: > > J is a function-level language. It expresses computations in terms of data > flow. Verbs (functions) are primary; nouns (data) are secondary. > > STOP THINKING IN TERMS OF UPDATING MUTABLE STATE. > > ---- > > Of course, like many programming languages, a number of optimizations have > been made in the background, as you (Ian) and Henry have so carefully > enumerated. > > In-place amendment, where appropriate, is one of these optimizations. But > that's an implementation detail; the problem is in the mindset that gives > priority to the question. > > --- > > Focus your attention on learning J *as a notation*, as a *language for > expressing yourself*, first. Un-C yourself; un-FORTRAN yourself; un-APL > yourself. Let J in. > > Worry about learning how to make J work, before you worry about how to make > J fast. > > --- > > And finally, that old chestnut about premature optimizaton. Get it > working, then profile it. Optimize the parts that are observably, > empirically, the slowest (perhaps using the list of special code mentioned > above). > > If it's still too slow, complain on the Forums. We're here to help. One > form of help might be, ultimately, adding a new optimization to the > language proper, as with Pepe's TCO adverb. But in most cases, that will > be overkill, and we'll show you other ways to express yourself. > > -Dan > > ----- Original Message --------------- > > Subject: Re: [Jprogramming] Replace one item of a list > From: Ian Clark <earthspo...@gmail.com> > Date: Wed, 10 Sep 2014 16:18:34 +0100 > To: programm...@jsoftware.com > > >> Then it actually does in-place updating (even though, at face value, J > syntax does not permit such a thing). > > > Please explain why this is not permitted by J syntax. > > My use of the word "permit" was misleading -- "suggest' might have been > better. Roger is right to challenge me on that point. > > When I wrote this I wasn't chiselling a tablet-of-stone, but trying to say > how things look to a newcomer to J, especially one who's already an > experienced programmer. I wanted to avoid the informal turn-of-phrase one > hears even from experienced programmers: "does J let you do in-place > updating?" > > Now this is inappropriate to ask of J. It "lets you do" whatever the syntax > permits -- and I think I'm using "permits" correctly now. As with any > post-1960 language, syntax is a poor indication of implementation. But what > else is a newcomer supposed to go by? RTFC? People still have the a-priori > assumption that what you tell an interpreter to do is what it does. Is this > being unreasonable? > > Consider: > > APL syntax: a[2] <- 100 > J syntax: a=: 100 (2)}a > > Does J syntax *preclude* in-place updating? No. > > I didn't say it did -- and J sees its way to doing precisely that (...which > is something I did say). > > Conversely, does APL syntax *compel* it to perform in-place updating? No > again. > > It might in fact write out the entire contents of (a) afresh, with entry > [2] replaced by 100. This was precisely what Dyalog APL once did whenever > (a) was Boolean. And -- what's worse! -- temporarily converted it all from > Boolean (1 byte per entry) to integer (4 bytes per entry), giving WS FULL > unexpectedly if (a) was large enough. > > This was 1996. I think that oddity has now been fixed. But, back then, the > Adaytum team had to write a whole external package in C to take over from > APL the task of managing a massive Boolean array, just to be able to flip a > single bit without the need to keep an additional 400% of workspace in > reserve. This wasn't a peripheral feature. Though only a single line of > code, it lay at the bleeding heart of the (OLAP) project. > > So this sort of question does matter. It once mattered enough nearly to > force the abandonment of APL for C halfway through a $million project. My > point of mentioning it on a thread where a newcomer asks for the "best > practice" of replacing one element of a list was not to flaunt my > smattering of arcane J knowledge but to pre-empt the typical newcomer's > forgivable misgiving about J, going by its syntax -- that it's a toy > language with no real answer to real-world problems. > > On Tue, Sep 9, 2014 at 9:54 PM, Henry Rich <henryhr...@nc.rr.com> wrote: > > > I don't think Ian meant, or said, that amend-in-place violates any rules. > > He said > > > > [J] actually does in-place updating (even though, at face value, > > J syntax does not permit such a thing). > > > > The key words are "at face value". I take that to mean that a > > beginner-to-advanced user, looking at the description of m}, would think > > that it always produces a complete new array. > > > > Ian's post makes it clear that he considering the inexpert J programmer's > > view of J. > > > > Henry Rich > > > > > > On 9/9/2014 12:35 PM, Roger Hui wrote: > > > >> I don't believe the messages you cited explained it. J syntax consists > of > >> word formation as defined by ;: and parsing rules as defined by Section > >> IIE > >> of the dictionary. How is amend-in-place not permitted by either part? > >> > >> > >> > >> On Tue, Sep 9, 2014 at 8:56 AM, Dan Bron <j...@bron.us> wrote: > >> > >> Ian wrote: > >>> > >>>> Then it actually does in-place updating (even though, > >>>> at face value, J syntax does not permit such a thing). > >>>> > >>> > >>> Roger responded: > >>> > >>>> Please explain why this is not permitted by J syntax. > >>>> > >>> > >>> I believe Ian is expressing a thought recently raised by Erling > Hellenas > >>> in > >>> [1], which I responded to here: > >>> > >>> > http://www.jsoftware.com/pipermail/programming/2014-July/038030.html > >>> > >>> -Dan > >>> > >>> [1] "J and indexed replacement": > >>> http://www.jsoftware.com/pipermail/programming/2014- > >>> July/038068.html > >>> > >>> "In most languages indexed replacement is indexed replacement? > In J > >>> and > >>> in most functional languages it is not? You get a brand new > >>> variable? > >>> So, why give the user the flawed impression he can still do > >>> indexed > >>> replacement and do amendments to variables/nouns? And at the > same > >>> time > >>> in tacit code we pretend to only have functions? No > >>> variables/nouns > >>> to > >>> be amended? Just functional transformations?" > >>> > >>> ---------------------------------------------------------------------- > >>> 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
