User talk:Dkf: Difference between revisions

→‎Your discussion about J: link to JforC foreword
(→‎Your discussion about J: Learning resources)
(→‎Your discussion about J: link to JforC foreword)
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)
 
:::: 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)
 
:The more I write code and work with other peoples', the more I find that terseness isn't a virtue. Clarity of expression is much better, especially since its usually the case that clear code is easier for compilers/optimizers to do something good with. The other thing I've learned (and keep learning) is that getting over clever is not a good idea if it just ends up defeating the hardware's cache management; the core of the Tcl <code>string map</code> command is very stupidly implemented, but switching to a fancy Rabin-Karp implementation was actually a slow down in practice because of the overhead of building the matchers and the difference in memory access patterns. Doing it the stupid way worked best because it allowed the hardware L1 cache predictor in modern CPUs to function most effectively; a real eye opener that indicates why its always worth measuring performance rather than guessing!
892

edits