User talk:Dkf: Difference between revisions
→Your discussion about J
Line 43:
: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!
:I suppose it all comes down to the principle of always try the simplest clearest thing that could possibly work, as that's the best option in such a huge number of cases. And there's a real tendency of many programmers (yes, myself included) to lose sight of these things. Which brings us back to [[J]]. They've clearly chosen to go down the short/very expressive path, and the language will attract a number of very smart people who will do amazing things with it in very little code. But they'll only ever attract the very smart, and the very smart are known for being fickle. The language is doomed to remain esoteric, rather like [[APL]]. —[[User:Dkf|Donal Fellows]] 14:27, 31 August 2009 (UTC)
:: I think terseness is a virtue unless it obscures clarity. As you point out it is usually best to make things simple. If you can express a concept in a couple of words rather than a couple of sentences it is easier to digest and quickly get a feel for what is important. Then you can start investigating the "but what if" questions. It is much quicker and easier to keep focused on answering those questions if getting the answer doesn't require you to write half a page of code first or think too much about the details of how the computer might implement it. One of the comments frequently made by people having learned J and APL, is how it helps them think differently about problems even when coding in scalar languages. You may find the following papers interesting: [http://www.jsoftware.com/papers/tot.htm Notation as a Tool of Thought] (Ken Iverson's Turing Award Lecture), [http://www.dbmcintyre.pwp.blueyonder.co.uk/index_f/menu_f/j_f/sysj_r_29.pdf Language as an Intellectual Tool: From Hieroglyphics to APL](4MB).
:: Of course as has been pointed out, you first have to learn the language. In the case of [[J]] (and APL), "learning the language" means just that (vocab, grammar, etc.), not just syntax. That doesn't mean it takes forever to gain any proficiency - just like any human language, you can usually get a lot of things done even with a limited vocabulary. --[[User:Tikkanz|Tikkanz]] 23:13, 31 August 2009 (UTC)
| |||