User talk:Dkf: Difference between revisions

m
no edit summary
(Can we close this discussion now? Please?)
mNo edit summary
Line 44:
 
::: (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)
 
 
::::: It's all your (collective) call. I'm just of the opinion that for the purposes of ''this site'' it is worth being more verbose than you otherwise would. Increased comment length is one of the best ways of doing this IMO (not that this is a specific comment). The other thing to watch for is where code is making use of assumptions that are obvious to experts in the implementation language, but which are mysterious to everyone else. Again, it's a universal problem but the more a language has implicit things, the harder it is to grasp a particular solution at a glance. (Of course, you and I probably differ over the definition of the correct level of implicit-ness, but that's just both of our opinions differing. I expect neither of us to change.) —[[User:Dkf|Donal Fellows]] 08:20, 10 September 2009 (UTC)
 
:::: There is the Vocabulary page of the J Dictionary, however the J Dictionary is not very enlightening for beginners - understandable given its primary purpose is to serve as a specification for the language implementation, rather than a study guide. Instead I'd recommend the book [http://www.jsoftware.com/jwiki/Books J for C programmers] (available free online or as hard copy) as a well written intro to J and array languages, especially for those coming from scalar-oriented languages, not just C. Don't skip [http://www.jsoftware.com/help/jforc/foreword.htm the Foreword]!!. If you're wanting a Quick Reference, then I'd suggest the [http://www.jsoftware.com/jwiki/HenryRich?action=AttachFile&do=view&target=J602_RefCard_color_letter_current.pdf J Reference Card]. --[[User:Tikkanz|Tikkanz]] 21:53, 1 September 2009 (UTC)
Line 101 ⟶ 98:
: 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]
 
::::: It's all your (collective) call. I'm just of the opinion that for the purposes of ''this site'' it is worth being more verbose than you otherwise would. Increased comment length is one of the best ways of doing this IMO (not that this is a specific comment). The other thing to watch for is where code is making use of assumptions that are obvious to experts in the implementation language, but which are mysterious to everyone else. Again, it's a universal problem but the more a language has implicit things, the harder it is to grasp a particular solution at a glance. (Of course, you and I probably differ over the definition of the correct level of implicit-ness, but that's just both of our opinions differing. I expect neither of us to change.) —[[User:Dkf|Donal Fellows]] 08:20, 10 September 2009 (UTC)
Anonymous user