Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[CptFastbreak]

Ruby is just Python's Japanese brother. Same league feature-wise and performance-wise. Even same problems (like GIL) in their c interpreters.

While that is true performance-wise and regarding the GIL, it's total BS WRT to syntax and features. Ruby has unique features such as blocks that are not found in any other language, and most importantly if you want to compare it with Python, it has proper OOP support.

Bjarne Stroustrup has no more right to declare his language the one true successor to C than anyone else has...

I don't recall him ever making such claim.

[Baughn]

Blocks don't seem very different from lambdas. If I understood these right, some equivalent code..

Code: [Select]

-- Ruby, with possibly broken code but you get the idea
def blocky(a)
  b = a + 2
  yield (a,b)
  return b

-- Haskell; first some extra code to make it blockier
type Block a = Maybe (a -> IO ())
yield :: Block a -> a -> IO () -- Optional
yield Nothing _ = return ()
yield (Just f) a = f a

-- Ruby equivalent
blocky :: (Block (Int,Int)) -> Int -> IO Int -- Still optional
blocky block a = do
  let b = a + 2
  yield block (a,b)
  return b

It doesn't get quite as implicit, but IMO that's an advantage.

[Scarpa]

I thought the real differentiating part of Ruby was the closures, not the blocks. Only reason I know this is I'm trying to learn Ruby and I can't yet figure the difference between closures and blocks.

[madman]

It's up to you, as a developer, when your errors will show themselves; unit testing is one way, and neat little tools like Toady's arena are another.  Very simple errors will be caught by a compiler, but they'll rarely go unnoticed by a capable programmer for long.  I don't think I've lost more than an hour or two in every hundred to tracking down bugs caused by typos (in languages without declarations) and I've certainly gained more than that by not feeling constrained by declarations.  It's all a matter of style and self-discipline in the end, even in C.  (It's amazing what you can get away with.)

Have you ever tried a really high level language like Mercury or Haskell? I've had the compiler catch some pretty deep bugs that would have been a real pain to track down. I'm not just talking easy to catch type mismatches - Mercury for instance also tests the determinism if the code (is there a case that might fail? Is there an undeclared ambiguity?). I've found that once it compiles, it probably works (although the error messages are even worse than the ones given by C++ when using STL, which can make the learning curve horrible). Testing, unit tests, etc. are still important, but even as a very experienced programmer, I'll take all the help I can get to keep the bugs out of my code.

I agree that C and C++ are different languages (I use both, and declare them separately on my CV). C is great for embedded stuff, C++ for larger projects, and it's a travesty when C++ is taught as 'C with nicer output functions'.

[CptFastbreak]

Blocks don't seem very different from lambdas.

Well I don't know a lot (i.e. close to nothing) about lambda calculus, also I don't really understand the Haskell code. But the way it was explained to me, blocks are more like iterators. I don't know if I was using the wrong terminology, but this is about what I meant:

Code: [Select]

// C++
class Foo {
   class iterator {
      friend class Foo;
      std::string operator*();
      iterator operator++();
      bool operator!=( const Foo::iterator& ) const;
      // etc.
   }
   iterator begin();
   iterator end();
}

for( Foo::iterator i = Foo.begin(); i != Foo.end(); i++ ) {
    // do stuff with *i
}


Code: [Select]

# ruby
class Foo
   def each
      # do stuff resulting in somevar being assigned a value
      yield somevar
   end
end

Foo.each do |i|
   # do stuff with i
end

To my knowledge, this is a specific Ruby-ism. You can also treat a block of code as a value, that's probably more like lambda and maybe what you meant.

[Baughn]

Yep, definitely the same thing.

It's dressed up a little, but that's really just passing in a closure to execute whenever yield is called. Possibly with a bit of continuations in the background, though none of the examples here would require that.

[CptFastbreak]

So I stand corrected with the uniqueness. Still, I don't know of any equivalent construct in Python which was kind of my original point.

[languard]

As an interesting side note, there were two sessions at this year's Game Developer Conference devoted to talking about why C++ sucks for game programming.  I unfortunately did not get to attend those talks but my college did.  The basic conclusion was that yes C++ sucks for game development, but there's not way around it for certain parts of the game, like physics and rendering.  For anything else, almost *any* language is better.

Really wish I had attended that talk.

Oh and C# rules.  They even have XNA working on Mono now.

[BitLooter]

Still, I don't know of any equivalent construct in Python which was kind of my original point.

Correct me if I'm wrong, but it seems like this Python code should do the trick:

Code: [Select]

def foo():
    # code to assign somevar
    yield somevar

for i in foo():
    # do stuff to i

Note that you don't even need to write a class, the yield statement does that for you. You could even do it like this if you're processing an iterator:

Code: [Select]

for i in (bar(somevar) for somevar in stuff_to_process):
    # do stuff to i

Both those methods create generators; I'm not familiar with Ruby, but I think that's roughly equivalent to using a block of code as a value, as you describe.

[numerobis]

I've used both Ruby and Python.  The only difference I've seen between today's Ruby interpreter and a five-year-old Python interpreter is the syntax.  This makes me hate Ruby very slightly more than Python.  I dearly wish python would have even the rudimentary static checking that C++ offers.  Nevertheless, in recent experience, I've been whipping out functionality 3x faster in python than in C++, in some part because I don't have to type as much boilerplate, but in greater part because I hit fewer memory bugs.  The ratio would be less extreme if I could use boost for the C++ code, but for this particular project I can't, and the ratio would anyway still be greater than 1.

SML would be my favourite language system if it had any libraries.  O'Caml is decent but not as good.  Next new project I start will probably be in Haskell, in particular DPH, because it has the buzz now.  I'm not sure why SPJ got so many people excited and Bob Harper didn't, but that's how things are.

C# is on my list of languages to look at more closely.  Seems like a version of java that is both less boneheaded from the outset and less ossified in its evolution.

[macdonellba]

Both those methods create generators; I'm not familiar with Ruby, but I think that's roughly equivalent to using a block of code as a value, as you describe.

In the case of ruby, you're passing a closure to a function / method (_not_ creating a generator), whereas in the python version you're using something more akin to a specialized class of continuation to freeze the state of the yielding function. There's a subtle difference between making multiple calls into a closure vs. resuming a function - consider the following:

Code: [Select]

# Python example
def foo():
  yield 1
  yield 2
  yield 3

def bar():
  for i in foo():
    return i

bar() # => bar returns 1

for i in foo():
  return i # SyntaxError: 'return' outside function.

----------------------------------------------------

# Gross ruby example
def foo()
  yield 1
  yield 2
  yield 3
end

def bar()
  foo {|i| break i}
end

bar() # => bar returns 1
foo {|i| break i} # => foo returns 1

The small distinction is because of the construction of the call stack. In the python version, the bar calls foo, which returns a value to use by the loop, whereas in the ruby version foo passes a value to the block, which itself may use a break statement to escape from foo's execution context. Strangely, ruby blocks aren't just anonymous first-class functions, as they can't directly return values - attempting to use a return above in place of the break would have made for a clearer example of the difference, but would have resulted in a LocalJumpError.

[Urist McDepravity]

it's total BS WRT to syntax and features. Ruby has unique features such as blocks that are not found in any other language, and most importantly if you want to compare it with Python, it has proper OOP support.

Syntax does not matter. Its all AST for interpreter.
At byte-code level, they are same.
Feature-wise - only differences i see are syntax sugar ruby offers, like there blocks. You can implement that in python, but it will not look as short and nice.

In the case of ruby, you're passing a closure to a function / method (_not_ creating a generator), whereas in the python version you're using something more akin to a specialized class of continuation to freeze the state of the yielding function. There's a subtle difference between making multiple calls into a closure vs. resuming a function

Yes, because ruby's yield and python's yield are completely different things.

Spoiler (click to show/hide)

irb(main):001:0> def foo()
irb(main):002:1>   yield 1
irb(main):003:1>   yield 2
irb(main):004:1>   yield 3
irb(main):005:1> end
=> nil
irb(main):006:0> foo()
LocalJumpError: no block given
   from (irb):2:in `foo'
   from (irb):6

In python, this would look like

Spoiler (click to show/hide)

>>> def foo(closure):
...     closure(1)
...     closure(2)
...     closure(3)
...
>>> foo(lambda x: x)

But with way to break execution from the lambda and return its value. I'm not too sure how ruby break works and too lazy to learn. Definitely working way is to just raise exception, but thats hardcore.

Edit. Actually, iterators and generators already use exceptions as signals to callers. So thats 'normal' for python

[CptFastbreak]

Correct me if I'm wrong, but it seems like this Python code should do the trick:

Of course you can come up with examples that accomplish about the same stuff (like a for..in loop) in any language, the point is how elegant or clumsy it is expressed in a language. Also, Ruby blocks do not need to have classes defined either, but my use case was to create something similar to an iterator over a user defined class which is done in a very elegant manner in Ruby.

Syntax does not matter.

I would disagree here. IMO, how you express concepts in a programming language influences how you think about them. There's a reason why GWBasic is not used anymore.

[Urist McDepravity]

Ok, here's decorator which will make it work like blocks.

Spoiler (click to show/hide)

from rbblock import ruby_block, rbbreak

@ruby_block
def foo(*args):
    yield 1
    yield 2
    yield 3

print foo(lambda x: rbbreak(x))
---- rbblock.py :
from decorator import decorator

class RubyBlockBreak(Exception):
    _result = None
    def __init__(self, result):
        Exception.__init__(self)
        self._result = result

def rbbreak(*args, **kw):
    raise RubyBlockBreak(*args, **kw)

@decorator
def ruby_block(func, closure, *args, **kw):
    gen = func()
    for vals in gen:
        try:
            if type(vals) != list and type(vals) != tuple:
                vals = [vals]
            closure(*vals)
        except RubyBlockBreak, e:
            return e._result

the point is how elegant or clumsy it is expressed in a language

Using python's decorators and metaclasses, you can achieve quite close syntax, being as `elegant` as needed.

[BitLooter]

Hmm, I think I understand now how the Python code and Ruby code is different. I still fail to see how Ruby is better for this, but I believe that's because the example is rather simplistic and not due to a failure on Ruby's part.

I'm a Python fan myself, but one of these days I'm going to learn Ruby if only so I can understand the code samples people supply when they argue over which language is better.