Devon McCormick wrote:
Randy -
I think it's a mis-characterization to say that J "isn't meant for user
input".
In fact, due to its interpretive nature, J handles user input beautifully
compared
to any conventional language, if you use the language itself. Of
course, as
an avid APLer, I'm sure this isn't news to you.
Your statement is, of course, true. That it uses a different notion of
"meant for user input" than I did is also true.
But this prompt-based notion won't die, no matter how crippled it is
compared
to simply using native J. Take, for instance, the outline of the program
that
Amelia is writing: allow someone to enter some numbers, then return some
descriptive statistics about them. Using J, I would naturally do
something
like
(<./,>./,mean,stddev) 97.1 4.7 33 1.3 22 60 27.6 96.4 87.1 67.5
1.3 97.1 49.67 36.744585
...as would I, except perhaps for adding something to show the count.
However, as Amelia's professor has constrained the problem, the "correct"
session might look more like this:
Enter some numbers: 97.1 4.7 33 1.3 22 60 27.6 96.4 87.1 67.5
** Error: can only accept 5 numbers.
Enter some numbers: 97.1 4.7 33 1.3 22
The minimum is 1.3.
The maximum is 97.1.
The mean is 31.62.
The standard deviation is 38.813876.
The limitation to 5 numbers wasn't something I recall seeing in the
problem statement, although I don't recall seeing the problem statement.
or some such limited, simplistic implementation. Notice how thoroughly
inadequate this prompt-based paradigm is for getting any serious work
done:
it's probably constrained to some fixed number of entries or necessitates
added complexity to acommodate a variable number of entries.
Characterizing the problem as not worth solving raises its own
concerns. I hesitate to do that to someone who comes with a question.
If I didn't, I'd deserve to be a Perl monk.
Furthermore,
an input mistake can only be corrected by re-typing the entire set of
entries
and the result can only be used by manually transferring it.
That depends on the nature of the prompting interface. Note also these
are problems solved by the J session manager, not J itself.
(Of course, using a spreadsheet may also be a good way to handle a
problem
like this.)
I thought you were against limited, simplistic, crippled even,
implementations...
This prompt+manual input notion is a lousy paradigm that is encumbered by
widely-accepted, unnecessary limitations of the past 50 years. Today, we
have
scalpels and laser beams but most people still insist on using sticks and
rocks.
You mean, stone knives and bearskins :-) or was it spreadsheets and GUI's ?
However true all this all is, the problem of user input seems to be a
recurring one in J.
Those of us who use the language a lot have solved it for ourselves
but it
recurs
regularly for beginners. We've talked about this a bit in the NYCJUG and
the
consensus seems to be 1) use file-based input, or 2) use a spreadsheet
front-end.
One other idea is to use the GUI-building capabilities of some other
language,
like Java or VB, and
interface the resulting GUI with J. Until get something like
this fully fleshed out on the Wiki, we may have to make do by referring
people to
the character-based solutions for Amelie that came out of this thread.
This, to me, points to the elephant in the room: I've been underwhelmed
by the J's wd pretty much since it came out. Perhaps I was too far gone
in having a GUI platform on Windows APL.
Devon
On 4/15/07, ramacd <[EMAIL PROTECTED]> wrote:
Dan Bron wrote:
> This is easy to see if we take a reductionist approach: a single J
> token is either a built-in J primitive, or it's a user-defined name
> with an arbitrary definition. Primitives never change their definition
> (good thing!). And the dictionary of J explicitly states, at
> http://www.jsoftware.com/help/dictionary/dict2.htm that:
Primitives don't change their definition over a single version of J,
that is true. Over multiple versions it is a different story. In fact,
I long ago coined a term ("getting henked") for the suffering one
undergoes when one assumes upward compatibility.
On the original idea of this thread, having a REPL facility, which
doesn't come in primitive-only J, doesn't strike me as a stretch of its
capabilities. I do wonder at the (if you want a responsive computer,
don't let a user near J) attitude, and where it comes from. Amelia's
note that J "isn't meant for user input." crystallizes a big misgiving I
have about J, even though I have been pro-J since J has been around.
>: ...
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
