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.
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
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.
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.
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.
(Of course, using a spreadsheet may also be a good way to handle a
problem
like this.)
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.
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.
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
>
--
Devon McCormick, CFA
^me^ at acm.
org is my
preferred e-mail
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
