Mat Schaffer wrote: > > On Aug 18, 2006, at 9:43 AM, M. Edward (Ed) Borasky wrote: >> Yes, that's a contrived example, but as far as I'm concerned, if end of >> line terminates a "statement", then continuation of a line should >> require an *explicit* continuation designator, such as "\". > > But then you open up the reverse problem with an example like > > if (very long condition that hangs off the end of the page) > || (another condition) > > Raising a syntax error that you have to go back and add a \ to. I don't > know if you can say for sure which is the lesser of two evils. > Requiring ;'s to terminate statements or requiring \'s to continue > them. So ruby just avoids them both by having really flexible syntax. > > As for my opinion/idea on the topic, what about adding some lint > checking when you use ruby -c ? That way a regular app wouldn't incur > the memory, but you could still get the job done without requiring an > external lint program. Obviously someone would have to write this, and > it's not gonna be me. Just trying to get ideas circulating. > > -Mat > > I guess the *real* answer is that every multi-lingual programmer evolves a programming style that allows (somewhat) rapid switching between languages and allows *easy* reading of the source by the programmer and any colleagues that might need to do so. I started with macro assembler and FORTRAN, so a one-line statement with a continuation required is "natural" to me. For a long time, when I migrated from Perl to R, I put in lots of extra semicolons in the R code to make it easier for me to remember them when I went back to Perl. And if I find a huge expression or condition, I try to factor it into meaningful functions/methods/procedures. So I would write (in R): valid-date <- function(x) { x$date <="2006-08-01" & x$date >= "2006-05-01"; } valid-utilization <- function(x) { x$util < 104.0; } valid-data <- function(x) { valid-date(x) & valid-utilization(x); } ... qx <- subset(qz, valid-data(q)); ... Now R is a functional language with (two kinds of) objects, not an "object-oriented language". But I think I'd write the same way in Ruby.