User talk:Dkf: Difference between revisions
m
→Your discussion about J
Line 39:
This can be an issue with any kind of code but I'd like to give you an e-high-five for recognizing it with J and pointing it out. --[[User:Mwn3d|Mwn3d]] 12:42, 31 August 2009 (UTC)
::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). [[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!
| |||