Anonymous user
User talk:Dkf: Difference between revisions
no edit summary
(→Your discussion about J: Maintenance categories) |
No 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)
:::: 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)
-----
:::: 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 71 ⟶ 98:
:::: At one time I was in the Texas Instruments camp against the HP Reverse-Polish Notation calculators. Then I learnt all about Reverse-Polish when writing an interpreter and revisited my earlier conclusions on RPN and new that they were rubbish. Later, before I learnt a Lisp-like language I was careful not to reject their claims, and I did learn what made it so good to program in at the time. But now I prefer Python for most things, and am being 'tickled' by Haskell/OCaml/D/Oz. --[[User:Paddy3118|Paddy3118]] 11:07, 1 September 2009 (UTC)
::::: Writing code that is both idiomatic and maintainable is a good target. (Indeed, that's the case for any language but some have more of a culture of it than others.) Which leaves a suggested thing for the J community to do: go through the existing solutions in J and evaluate whether they are good style (from both technical and pedagogic perspectives, of course); I've already been doing this with the Tcl solutions, but I'm not in a position to be able to do it for every language. There's only a fixed number of hours in the day... ☺ —[[User:Dkf|Donal Fellows]] 12:28, 1 September 2009 (UTC)
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
| |||