User talk:Dkf: Difference between revisions
Content added Content deleted
No edit summary |
No edit summary |
||
Line 45: | Line 45: | ||
::: (Need input from all you folks watching the recent changes feed here) I have noticed that vocabulary makes J difficult for me to understand. Is J's vocabulary such that it could be compared or related to other languages on a word by word basis, such as what one might find in a dictionary equating words in one language with words in another? Even if there aren't direct word-word equations, can a word be described as a phrase in another language? I could see such a thing as being equivalent to a study guide, key or legend. --[[User:Short Circuit|Short Circuit]] 14:47, 1 September 2009 (UTC) |
::: (Need input from all you folks watching the recent changes feed here) I have noticed that vocabulary makes J difficult for me to understand. Is J's vocabulary such that it could be compared or related to other languages on a word by word basis, such as what one might find in a dictionary equating words in one language with words in another? Even if there aren't direct word-word equations, can a word be described as a phrase in another language? I could see such a thing as being equivalent to a study guide, key or legend. --[[User:Short Circuit|Short Circuit]] 14:47, 1 September 2009 (UTC) |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
:::: |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
:::: |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
----- |
----- |
||
Line 100: | Line 76: | ||
Most of the J code presented in RC examples is considered good form - to J programmers. Ken Iverson The main issue is that programmers familiar with more traditional languages tend to expect an algorithm statement to consume several lines of code. overlook what is "good form" to a J programmer isn't necessarily |
Most of the J code presented in RC examples is considered good form - to J programmers. Ken Iverson The main issue is that programmers familiar with more traditional languages tend to expect an algorithm statement to consume several lines of code. overlook what is "good form" to a J programmer isn't necessarily |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
: |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
: |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | : For someone not familiar with J, the English word approach may be easier to read. However, a typical J programmer would never do this, because it would require too much typing. Anyone marginally familiar with J symbols would immediately grasp the original code much quicker than the English translation. The correct form for J programs is to use the primitive J symbols, which will make the resulting code terse. For J programmers the terse form is much easier to read than an English-substitute version. |
||
⚫ | : The issue here is: Just how far should the J programmer go towards expanding an elegant J expression into a verbose English translation, in order to help newbies understand what is going on? In my opinion, not very far. The whole purpose of an efficient notation is to allow a complex algorithm to be defined in a simple, concise way that can be scanned and understood in a single glance. It is true that this kind of proficiency in reading J code is not obtained overnight. However when one becomes proficient with J, you discover that you can deal with complex processes as a whole, that were not possible before you learned J. The notation you use to describe a problem shapes the way you think about the solution. J will change the way you think, and change how you approach the solution to problems. Whether this is good or bad depends on your viewpoint. [[User:Teledon|Teledon]] 1:46 10 September 2009 (Skip Cave) Ref. Notation as a Tool of Thought (Iverson) - [http://www.jdl.ac.cn/turing/pdf/p444-iverson.pdf] |