Maybe sometime in the future it will get sensible error messages. "unexpected tUPLUS"? What the f..k? And that's one of the least cryptic I've seen.
Maybe in a few years the Ruby folk gets through the discussion that was hot in the Perl community some eight years ago and add variable declaration and use strict. (There is currently no way to know whether an "x" used in a block is a new local one or shared with a bigger scope. And no way to specify that. And to make things more interesting the locality of the block parameters is currently context dependent, in the upcomming version they will always be local. Sweet.) Currently all you get is a runtime check that the first thing you do to a variable is some kind of assignment.
1) The exact syntactical rules don't matter that much, because once you get used to Ruby, it feels natural to write code in a certain way. I'm sure Python is even more unusual from Perl's point of view. I have never had a problem with the problem you present in Ruby. And finishing each intermediary line in a multi-line expression with an operator is a good practice.
2) Ruby doesn't need 'use strict' the way Perl does, because in Ruby uninitialized variables don't 'spring to life' when referenced. Variables must be initialized before use, otherwise you get an exception. In this sense Ruby is very much like Lisp, and you don't hear people complaining about the lack of the 'strict' module in Lisp.
is a good practice? With the operators hidden all the way to the right, each at a different column, forcing you to scan for the end of the lines to find out where does the statement end? Well, up to you. I find this incredibly ugly.
Ad 2) Sorry, no that's not true. All Ruby does is it makes the warnings turned on by use warnings 'uninitialized'; fatal. It has no way whatsoever to catch even something as simple as
result = foo(...)
do something with result
resutl = bar(...)
do something with result
There is no way to specify that one assignment is supposed to be "initialization" and another not. Which means that some operations on variables are kinda guarded, others are not. Because they are undistinguishable from intended initializations.
Another problem is that you CAN'T declare a variable as being private for a block. You can only hope you do not stomp on an outer variable accidentaly. Or create an outer variable later and break stuff. At least the block parameters will always be local to the block starting with 1.9, but I still will not be able to start using a variable within a block without having to look elsewhere to make sure it really is a new variable. And no, all methods cannot be those advertised 5 lives long, if only because of data literals.
We are trying to install a pre-existing ruby on rails.
We are new to ruby so we have a new install. We have already had to update the code in this app from 'require_gem' to 'gem' and now we are getting variable not initialized errors.
Was there a previous ruby version that was by default was loose and allowed you 'spring to life' variables? Is there a way to tell ruby to be loose about its variable declaration?
i know this is a perl site, but you are talking about our exact problem. hoping you can help.