I wrote: > invocated valence I meant "invoked".
> Without knowing the types and definitions of all the entities involved, > you > cannot know what an executable statement DOES. What I meant to emphasize here is that you're usually not interested in the result of the statement per se. When reading code, you want to know what the code means, what the statement will do. Not the same way the compiler wants to know what the statement will do, but in a human, conceptual sense. So when I said this: > J and Java have different obstacles to this goal, and > different opinions about what's relevant and what's immutable, > but the result is the same, so the differences don't matter. The idea was that even a compiler, without sufficient information, couldn't tell what a line of J or Java will do. The reasons are different: with Java, you don't know what type of object the line will output; with J you can't even know what part of speech. On the other hand, noun (object) type is very important in Java, and a lot less important in J, so the level of ambiguity is probably on par. But the point was that ambiguity at that level is irrelevant; we are not compilers. We don't want to know what kind of thing the line will output, we want to know what the line means. So even though J's ambiguity is at a different level than Java's, the problem is identical. Hence J, in this sense, is no harder to read than Java. (The simile is not restricted to Java) -Dan PS: Assembler has few, if any, ambiguities. But I doubt anyone would vote assembler the most readable language. Broad concepts are precisely what allow a short statement to carry a lot of meaning. Details obscure. -- View this message in context: http://www.nabble.com/Pythagorean-triples-tp14896594s24193p14925478.html Sent from the J Programming mailing list archive at Nabble.com. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
