> Pretty sure this has to do with more than just the number of > characters/words. :)
Of course it has. :) My point is, when we read... anything... we're separating contexts (sections, paragraphs, sentences, injected sentences) and our wonderful pattern matching brain needs but a tiny glimpse of the words in order to extract semantics. > I think having to make sure that the human can parse the raw Java AST > is the fallacy here. Further, this is particularly why DSLs have > gotten to be so popular. The AST is 100% necessary for the > conversation between the developer and the computer. For the > developer to the developer, it often gets in the way. There's a difference between "making sure" and "catering to". In source code, we should first and foremost target human perception - and to me, this includes avoiding a gazillion small temporary objects polluting the scope, which inevitably makes our brain use reference counting to assert what's used and not. Apart from controlling mutability, that's something the builder pattern, via method chaining, caters too. > I think line-wrapping could be a pipe-dream here. The problem is > more than just "this should be on the next line." There are > consideration of what to keep together without destroying white space. > With emails and such, line-wrapping works because the fundamental > unit is a paragraph, not a character or "node." More directly put, > developers haven't even come up with a way that we can agree > line-wrapping works in code, how do you plan to codify it? The big mistake here is to think in lines. There ARE no lines, only nodes we have come to interpret by reading many thousands source files. Line wrapping would at least allow developers to remain focused on the scope/block, rather than the line at hand. A correct implementation of line wrap, would wrap to the existing indentation scope (unlike i.e. Visual Studio, which wraps to column 0). I also believe, with increased focus on "what's to be done" (declarative and functional code), we'll get rid of much of the explicit details revolving around "how it's done" (imperative code). -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
