Skilldrick

arrays and hashes don’t need brackets and braces. I mean, what else could :a => 5 be other than a hash? The syntax is unambiguous, so there’s no need to insist.

This is a little misleading. It is only within method calls that you can leave the curly braces off of hashes. As for arrays, I assume you mean passing in a list of arguments to a method which takes a variable length parameter. It seems like a stretch to say that means arrays don’t need brackets.

And => is also used in rescue clauses.

Python has plenty of “syntactic sugar” for special cases. Off the top of my head, there are list comprehensions, context managers for the ‘with’ statement, and decorators. Even interpolation as an operator qualifies. Perhaps Ruby has more (I have only a passing familiarity with it, but the fact that it has a `case) but Python is hardly innocent.

Great set of comparisons. Thanks for the write up.

Is it worth keeping all syntax consistent, or is it OK to introduce special forms for certain common circumstances? Before I started using Ruby, I was probably in the former camp, but I’ve been convinced of the advantages of the latter now.

You’ve been incorrectly convinced I fear. Consider a third option of making blocks first-class objects, therefore having:

a = { 'foo' }

instead of the current

a = Proc.new { 'foo' }

and

a = { 'foo' }

being a syntax error.

All of a sudden, you can easily provide multiple blocks to a single method or even call methods directly on blocks ({ a < b }.whileTrue { puts 'Free while' }), the language is more consistent, simpler and better handles complex cases, letting you build more control structures. It also removes the magical special cases of the ampersand in both parameter (a block is a normal param) and method call (a block is a normal param). Better, that also removes the current need for block_given? and yield.

You get rid of 3 or 4 (depending on whether you get rid of sym#to_proc, which I’d probably recommend) constructs in the language *and* you get a more general and flexible feature, what’s not to like.

That’s what Smalltalk does, and as a result not only doesn’t smalltalk need a for, it doesn’t need a while or a if statement either.

Damn, I’d missed a lot of incorrect stuff, I have to go but I can still do at least one:

And because direct access to object attributes is impossible, you’re able to write code that looks like direct attribute access with all the benefits of accessor methods. That is a huge win for me.

Hello, you can do that in Python. There is @property (and more generally descriptors) for explicit virtual members (methods used as attributes), and __getattr__ for the (rough) equivalent to method_missing.

Something else that’s nice with Ruby’s implicitness is the fact that arrays and hashes don’t need brackets and braces. I mean, what else could :a => 5 be other than a hash? The syntax is unambiguous, so there’s no need to insist.

I’m pretty sure arrays do need brackets:

> irb
>> 1, 2, 3
SyntaxError: compile error
(irb):1: syntax error, unexpected ',', expecting $end
1, 2, 3
  ^
    from (irb):1

In fact so do hashes outside method calls as far as I know (though I might be wrong), this is (another) special case of Ruby, which in this case serves to emulate Python’s kwargs. Except it doesn’t look quite as good when forwarding a dict and adding new keys to it. And it has an other annoying issue (not sure whether that’s been fixed in 1.9) of not being able to provide both va_args (*foo) and keyword arguments to Ruby methods (or not in a sane way anyway)

And it has an other annoying issue (not sure whether that’s been fixed in 1.9) of not being able to provide both va_args (*foo) and keyword arguments to Ruby methods (or not in a sane way anyway)

In ruby 1.9:

 def f(*a)
     a
 end
 arr = [3,4]
 f(1, 2, *arr, :a=>"one", :b=>"two") #=> [1, 2, 3, 4, {:a=>"one", :b=>"two"}]

@Adam

OK it hasn’t changed, it still isn’t sane/clean, as in 1.8.

Decent GUI

I’ve made a little framework that hopefully will help reduce the divide. It’s called Freightrain and you can find it here => http://github.com/bolthar/freightrain

For example, instead of saying if myArray.length you’d use if myArray.empty? which is obviously more readable.

Python:

if not my_array: ...

Every method in Python needs self as its first argument

This makes scope obvious and nothing special. It also works well with multiple inheritance, just pass our self to a parent’s method. It lets us reference instance methods without having the instance, for example map(str.upper, ['list', 'of', 'strings']).

The case statement is AWESOME

case = lambda x: y == x
if case(a):
    pass
elif case(b):
    pass

Being able to match against ranges

>>> 2 in range(10)
True

You could simulate Ruby’s === (what it uses for case matching) as a generic function in Python. Though I find it a rare need to do different kind of matches in a case switch.

There’s a lot of smell in Ruby too:

• The global namespace (require etc)
• The modules are separate from the import system, syntactically ugly if you ask me (CamelCase::), requires an extra indentation level but are highly needed due to the above point, only way to do multiple inheritance
• Inability to selectively import parts of a file
• Block heavy DSLs are imperative rather than declarative leading to confusing APIs compared to Python’s decorators which almost exclusively return a function.
• Subjective perhaps but I think Python’s focus on attributes leads to prettier and better code than Ruby’s focus on methods

Been a while since I thought about this so I probably forgot some points.

The use of self in standard python methods also makes classmethod and staticmethod decorators easier to work with.

@masklinn

Yes it has changed in 1.9, hash args work a lot better with var args now:

def hello(*args, options)
  puts args
  puts options
end

hello(1,2,3,4,5, name: :masklin, age: 37)
#=> [1,2,3,4,5]
#=> { :name => :masklin, :age => 37)

both are great languages, I’ve use both and I feel than ruby is python with steroids…It’s so great but so young too….