User talk:Dkf: Difference between revisions

::I believe people are mis-identifying a vocabulary problem, here. People have problems reading J, people see J is terse, people think their problem is J's terseness. But, they would have the same problems, or worse problems, if J was not terse. (Given any J expression, expanding it into a more verbose expression is a trivial exercise. But you still need to know what the words mean, no matter how they are spelled.) Meanwhile, teaching J to non-programmers is easy, but teaching J to programmers can be difficult because programmers "know" things they learned from other languages -- things which usually turn out to be mistakes, in J (for example: how to implement algorithms efficiently using loops or recursion -- that said, programmers with some background in SQL might be more comfortable with this issue). [[User:Rdm|Rdm]] 21:10, 31 August 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!

::: A similar argument can be made for comments. If the reader is very familiar with a specific programming language, well-written code in that language will self-describe its' processes to that reader. Of course, code can be written to disguise its function, and poorly-written code can still be difficult to read. Comments are still useful for readers who are not proficient with a specific language, but who must maintain that unfamiliar code. -- [[User:Teledon|Teledon]] 1:46 1 September 2009