User talk:Dkf: Difference between revisions

no edit summary
No edit summary
No edit summary
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)
 
:::: J symbols can easily be assigned English words, just as mathematical symbols can be assigned words.
:::: For example, take the mathematical equation x = y ^ 2 + 3 * z
:::: One can write this this in pure English as: "x equals y squared plus three times z"
:::: However, this is not typically done, because the result is more verbose than necessary.
:::: This is even more true with J. Take the J expression to calculate the average of a group of numbers:
:::: avg =. +/ % #
:::: avg 45 66 35 86 24
:::: 51.2
:::: avg i. 100 NB. Find the average of the number sequence from 0 to 99
:::: 49.5
::::
:::: For "clarity", one could assign each J symbol or expression an English name:
:::: sum_up_all_numbers =. +/
:::: divide_by =. %
:::: count_the_number_of_numbers =. #
::::
:::: Now we can write our J function in English words:
:::: avg1 =. sum_up_all_numbers divide_by count_the_number_of_numbers
:::: avg1 45 66 35 86 24
:::: 51.2
:::: avg1 i. 100 NB. Find the average of the number sequence from 0 to 99
:::: 49.5
:::: 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 1 September 2009 (Skip Cave)
 
-----
Line 100 ⟶ 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
 
:::: J symbols can easily be assigned English words, just as mathematical symbols can be assigned words.
:::: For example, take the mathematical equation x = y ^ 2 + 3 * z
:::: One can write this this in pure English as: "x equals y squared plus three times z"
:::: However, this is not typically done, because the result is more verbose than necessary.
:::: This is even more true with J. Take the J expression to calculate the average of a group of numbers:
:::: avg =. +/ % #
:::: avg 45 66 35 86 24
:::: 51.2
:::: avg i. 100 NB. Find the average of the number sequence from 0 to 99
:::: 49.5
:
:::: For "clarity", one could assign each J symbol or expression an English name:
:::: sum_up_all_numbers =. +/
:::: divide_by =. %
:::: count_the_number_of_numbers =. #
:
:::: Now we can write our J function in English words:
:::: avg1 =. sum_up_all_numbers divide_by count_the_number_of_numbers
:::: avg1 45 66 35 86 24
:::: 51.2
:::: avg1 i. 100 NB. Find the average of the number sequence from 0 to 99
:::: 49.5
:::: 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 110 September 2009 (Skip Cave) Ref. Notation as a Tool of Thought (Iverson) - [http://www.jdl.ac.cn/turing/pdf/p444-iverson.pdf]
Anonymous user