ah .. re the "long one liners comprehensability" problem... how about relating it to the long german words comprehensibilty problem.
eg. : Donaudampfschiffahrtskapitänswitwe vs. Donau dampf schiffahrts kapitäns witwe the first expression looks as scary as a long J expression void of spacing. the second expression looks manageable and meaningful. There are just as many letters in the second version as the first one. So it's not really a matter of how many characters there are on a line. It's a matter of clear grouping. ... just a thought ... On 2011-08-16 22:12, Mark Niemiec wrote: > One problem with APL (that also exists in J) is the temptation to write > extremely long "one-liners" that encompass the entire solution to a > problem within a single line of code. While concise and efficient, this > produces the same kind of problem as run-on sentences create in writing > prose: they are too large for the human mind to comfortably understand > at once. The brain has to break them down into smaller pieces to > comprehend. It is much more straight forward to just break them into > several smaller bite-sized pieces in the first place - either close by > (so they can be examined in context), or in a function library that > implements several well-understood idioms. > > I personally find around 80 characters to be a nice happy medium - > I can usually understand lines that long or shorter in my head, while > I need to break down much longer lines, and can easily combine much > shorter ones. Of course, certain factors tend to affect this: long > variable names or constants make a line longer without increasing the > complexity, as do long trains, or compositions like a@b@c@d, or short > unnested parentheses like (a b c),(d e f),(g h i). Others, like hooks, > multiple nested parenthesized expressions, or sub-expressions involving > side-effects can make something harder to understand. Also, tacit > expressions can be harder to understand than explicit ones until one > becomes fluent in writing tacit code. > > If a line of code becomes difficult to read, it becomes that much more > difficult to edit and maintain. APL had developed a reputation as a > "write-only" language for this reason. Given how expensive software > development is, it's much better to write something that takes several > lines that are easy to maintain, rather than one line that is a work of > art chiseled in granite. > > -- Mark D. Niemiec<[email protected]> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
