I do not see a conflict here.
Thanks,
--
Raul
On Wed, Sep 10, 2014 at 1:41 PM, Dan Bron <j...@bron.us> wrote:
> I'd be up for that. But probably a better medium is the Wiki, as art is
> typically an iterative process?
>
> -Dan
>
> ----- Original Message ---------------
>
> Subject: Re: [Jprogramming] Replace one item of a list
> From: Raul Miller <rauldmil...@gmail.com>
> Date: Wed, 10 Sep 2014 13:27:51 -0400
> To: Programming forum <programm...@jsoftware.com>
>
> Product managers, in general, do not make their decisions on technical
> grounds, but on popularity grounds.
>
> That means we need to support people generating media - art (images
> and image manipulating tools), games (games themselves but also tools
> for working with the data used in games), music (sounds, rhythms,
> samples, sequencers, ...), video (just reading and writing video
> format data would be a big step), writers (outlining tools?), ...
>
> In other words, tools like "plot" are great examples of the sort of
> thing we should be working on (and tying into external tools is also
> really good). But I think we need to focus more on things created with
> J than on the language itself.
>
> Perhaps the right first step would be to make an "art" mailing list,
> for people to show off things they have created using J? If our
> current population is anything like me, our initial traffic on such a
> list might be more doodles and drivel than masterworks and multimedia,
> but you have to start somewhere.
>
> Thanks,
>
> --
> Raul
>
> On Wed, Sep 10, 2014 at 12:59 PM, Dan Bron <j...@bron.us> wrote:
>> Product managers, in general, aren't going to base their decisions on what
>> some random internet stranger wrote on an obscure mailing list. More
>> likely to influence their decision is the very fact that the primary
>> mailing list for the language is obscure.
>>
>> In other words: if our goal is to get people to use J for serious,
>> commercial, purposes, then to borrow (steal) a phrase from Tracy: we need
>> to go to them. The absolute best documentation in the history of
>> documentation won't matter a bit if no one ever reads it.
>>
>> That said, once we go to them, we'll have to convince them we have
>> something interesting to say. One way to do that is to tell them,
>> straight off, that J is unlike anything they've seen before ("un-C
>> yourself, un-FORTRAN yourself...").
>>
>> And then prove it.
>>
>> -Dan
>>
>> PS: Now you can see why I've taken the tactic I've taken on RosettaCode,
>> for example (I am honestly trying to bait people into calling bullshit;
>> which is how, incidentally, I've become undisputed champion of Liar's
>> Poker around the office.)
>>
>>
>>
>> ----- Original Message ---------------
>>
>> Subject: Re: [Jprogramming] Replace one item of a list
>> From: Ian Clark <earthspo...@gmail.com>
>> Date: Wed, 10 Sep 2014 17:38:21 +0100
>> To: programm...@jsoftware.com
>>
>> 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
>> ----------------------------------------------------------------------
>> 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
