Ben Giddings wrote:


> 
> def retrieve_good_status_val
>   :good_status
> end
> 
> def retrieve_bad_status_val
>   :bad_status
> end
> 
> def get_status(good, bad)
>   if rand > 0.2
>     good
>   else
>     bad
>   end
> end
> 
> good_status = retrieve_good_status_val
> bad_status = retrieve_bad_status_val
> while good_status = get_status(good_status, bad_status)

I guess you mean you would write this as
  while get_status(good_status, bad_status) = good_status
so that ruby could detect the problem...

But what if this was written as
  good_status = retrieve_good_status_val
  bad_status = retrieve_bad_status_val
  status = get_status(good_status, bad_status)
  while status = good_status

?

>   puts "Still good"
>   sleep 0.1
> end
> puts "Bad status"
> 
> Ruby can get the simple cases like 'if x = 1' but it can't get all the 
> variations.

And you can't write all cases backwards. It's better to be always very
careful with '=' vs. '==' instead of missing the really nasty cases
because "my syntax is safe[tm]"

> 
> At first, it might look ugly to have the un-assignable operand first, but 
> you get used to it quickly, and a bit of ugliness is a small price to pay 
> for more robust programs.

Since you have to test your programs in either case (especially with
ruby since a lot of errors are only detected at runtime) I don't see why
programs get more robust.

On the contrary, your programs become harder to read and piss off a lot
of codevelopers (well, at least me ;) )

> 
> I write for C compilers all the time, but when I write Ruby there are still 
> a lot of things I keep, even with its smarter interpreter.  In the end, I 
> think using '=' as the assignment operator and '==' as the comparison 
> operator is bad human-interface design.  What do you call that key?  
> "equals", not "assigns" or something, but it's hardly a flaw unique to 
> Ruby.  :)

Well, you are somewhat correct here. I, for one, would prefer a ":=" or
"<-" operator as assignment. But with current ruby syntax it is better
to use an editor/font which clearly distinguishes between '=' and '=='
so that such errors are highly unlikely.

> 
> Ben
> 
> 

Sebastian