It seems like chat is fine to share things created with J (as I've done
that before myself). Ideally we'd have the author or some other volunteer
curate meaningful content into the wiki. If there's at least some positive
response on chat then it would seem to indicate it's worthy of putting it
on the wiki -- probably some link under:
http://www.jsoftware.com/jwiki/Showcase, possibly
http://www.jsoftware.com/jwiki/Studio
On Wed, Sep 10, 2014 at 1:49 PM, Raul Miller <rauldmil...@gmail.com> wrote:
> 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
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
