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
