Mr. Bron, thank you for that most interesting reply which I must admit,
I will have
to read several times more to fully grasp all the concepts you demonstrated.
> This sounds like an apologia; you praise Clojure for being terser than
> other languages, but upon encountering a language terser yet, you condemn
> it (or, conversely, defend Clojure). Do believe Clojure has found "the
> perfect amount of brevity"?
>
>
Yes - Clojure has struck the perfect balance, making it possible for a
team of diverse
skills to quickly read, understand and work with each others code. For
certain expressions
of data-parsing I now see that J does this with superior elegance.
> vs J:
>
> (, '\' #~ '\'~:{:) pathString
>
>
As you mention in your footnote, its important to stick with what I
would label idiomatic use
of the language.
I believe an idiomatic Clojure expression would be
(str pathString (when-not (= \\ (last pathString)) \\))
Which uses about the same screen-real-estate, but reads more fluently.
Though I might change
perspective once I get a better handle on J - Green and uninitiated as I
am :)
> Or how about this:
>
> (;:'BAD OK') {::~ checkInput
>
>
>
That's pretty clear, so I would say very easy to compare with
(println (if (checkInput?) "OK" "BAD"))
Standard if-statement, but without the need for explicit then/else as it
takes 2 bodies of code.
> Or, have you seen the power operator?
>
Yes, and have been very impressed. If you noticed how much more compact
my Lisp
version of Mr. Harms Life1D program was, compared to the original Common
Lisp
implementation then you also get a sense of the pull J has on me. There
was not an idiomatic
out-of-the-box way I could port that operator.
> See how "flow control" isn't special syntax of the language. It isn't even
> a seperate concept in a J program. It's just a flowing part of the
> design. So I'm not sure why you think "terse flow control looks awful" [1].
>
>
I think it looks awful I think, primarily because I have not seen an
introduction such as the
one you have posted here before. 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
if. 1 > NUMtoFLIP do.
NUMtoFLIP=: 1
end.
for_a. |. i. NUMtoFLIP <. # fliptable do.
glpixels pos, cardWH, ,(a { fliptable) { CARDS
pos=. pos + 15 3
end.
end.
for_b. i. # acetable do.
Ace=. {: > b { acetable
if. 1 <: # > b { acetable do.
glpixels (((cardOVER + 3 * cardSPACE), cardDOWN) + b * cardSPACE, 0
), cardWH, ,Ace { CARDS
end.
end.
This to me is as vile and verbose as any other imperative structure. In
fact the whole program is littered
with intermediate value storage in variables which are mutated over and
over again, very poor style of
coding in my opinion.
But you have helped me far along the way with your reply, which is truly
appreciate. When first
tackling J, it seems I need all the help I can get.
So far I've hooked up with the J Engine via Java JNA, but am unable to
make a correct call for lack
of documentation. Your link provided example which made sense when
calling from J but not from Java.
Hopefully I'll skip past the beginners difficulty soon.
Thanks,
Lau
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
