Solitaire was written by a grade 10 high school student with 0 programming
experience and minimal quidance. Probably not a good source for summary
comments on a language.

On Mon, Nov 30, 2009 at 8:27 PM, Dan Bron <[email protected]> wrote:

> Lau B. Jensen wrote:
> >  I will have to read several times more to fully grasp
> >  all the concepts you demonstrated.
>
> Yes, it's a big conceptual shift to get one's head around.
>
> > Clojure has struck the perfect balance
>
> You can tell I'm a J enthusiast (ok: evangelist), but even I wouldn't make
> such a claim about J.  But then, I don't think Utopia is possible, either.
>
> >  For certain expressions of data-parsing I now
> >  see that J does this with superior elegance.
>
> Funny, I would say parsing is one of J's weakest domains.  I generally
> equate "parsing" with "string processing" and hence "irregular data that
> may need different treatment per element", which implies lots of small
> decisions (J is better at thinking big).
>
> Can I ask what particular expressions/programs led you to this decision?
> What do you mean by data-parsing?
>
> > , '\' #~ '\'~:{:
> >
> > I believe an idiomatic Clojure [equivalent] would be
> > (str pathString (when-not (= \\ (last pathString)) \\))
> >  Which uses about the same screen-real-estate, but reads more fluently.
>
> I differ, on two points.
>
> First, objectively:  it does not use "about the same real estate",
> particularly since this is an ancillary input-cleanser, to be embedded in
> a larger, more important context. I could easily tag the J function onto
> the end of a line and not have a twinge of conscience.  But if the J were
> as long as the Clojure idiom, I would likely give name it and call it (at
> 55 chars it's approaching the limit of a line, and since it is such a
> simple function, I expect the code that depends on it [presumably a file
> processor] would be much longer).
>
> Second, subjectively:  I do not agree it reads more fluently.  But that may
> be a function your relative newness to J, and your relative experience and
> comfort with Lisp.  (Anyway, I, personally, would be hestitant to make
> such claims in general [for a language I do not know, anyway].)
>
>
> >     (;:'BAD OK') {::~ checkInput
> > That's pretty clear, so I would say very easy to compare with
> >     (println (if (checkInput?) "OK" "BAD"))
>
> Can you show the idiomatic extension to a 3rd possible response?  As I
> said, in J this would be:
>
>     (;:'BAD OK OTHER') {::~ checkInput
>
> what would the natural, idiomatic Clojure read?
>
> >  I read through the source to the
> >  solitare game which comes
> >  with the J distribution as was really put off by it:
>
> >  if. 1 <: # fliptable do.
> >   pos=. (cardOVER + cardSPACE), cardDOWN
> >     ...
> >
> >  This to me is as ... verbose as any other imperative structure.
>
> I should make two points.  First, Solitaire is neccesarily a stateful
> (deck) and side-effected (graphics) program.  J is clearest and tersest
> when expressing truly functional programs.
>
> If Lisp can offer me a way to express such non-functional programs with a
> consistent, clear extension of the functional syntax, that would be a big
> motivator for me to try it out.  I hear this is possible and common in
> Haskell, using monads, but so far no one has been able to give me a
> straightforward definition of a monad (for someone unfamiliar with
> Haskell, and maybe that's the problem.)
>
> Second, I was hasty when I said control structures were the last refuge of
> a J programmer.  Many J programmers choose to use the explicit style (I
> don't prefer it), and in this style of programming if statements are not
> uncommon (though other control structures, in particular loops, still
> are).
>
> Explicit code is essentially unavoidable if your program requires state or
> handles side-effects (though one can keep the explicit code minimal, to
> handle just these aspects, and express the rest tacitly).
>
> >  Your link provided example which made sense when
> >  calling from J but not from Java.
>
> I suspect you'll need JNI.  There's also a higher-level COM interface, if
> that helps.
>
> -Dan
>
>
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to