mijj <[email protected]> wrote: > re display on a line like a typewriter. > > I think J's terse, one line approach to expressions *improves* readability. > > Having an entire expression for analysis within a steady gaze without > having to search around on a screen (or, god forbid, several screenfuls) > for related parts (i find) helps quite a lot with keeping a clear mind > on the problem. It avoids the hazzards of being distracted by the > mechanics of searching round for that "other bit that's somewhere round > here that has something to do with this bit". > > People who criticise J for it's terse nature and imply this makes it > incomprehensible have it exactly wrong.
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
