From: gabriele renzi Date: 2004-04-05T15:24:18+09:00 Subject: Re: deciding between ruby and python il Mon, 5 Apr 2004 08:39:32 +0900, Gavin Sinclair ha scritto:: >It's not equivalent. Ruby's approach is more OO: you can chain >methods. What you present on Python's side are functions. To combine >those in a meaningful way, I foresee list comprehensions :) Or the >good old Perlish: > > for s in uniq(sort(map(grep(........))))) :) ok, I can agree, cause I like consistency, but I think you can agree with me that having map(func,itr) or itr.map(func) does not really add anything.. >> Ruby iterator/blocks and python iterators/generator are very different >> approaches that yield similar results somehow, but both are really >> valuable and I don't think one is inherently better than the other. > >I argue that Ruby's is better because it's more general (provides >features beyond mere iteration), it's not more general. It's general in a different way. Python with the introduction of generators gained some of the power we got with call/cc cause they're actually coroutines (or semi-coroutines). You can use them as state machines. You can build thread out of generators. some things you do with esplicit iterators can't be done with implicit ones, say: We have Enumerable#zip(anEnumerable), while python has izip(anIterable,anIterable). In ruby you're forced to build a huge array any time you use zip, whle in python you can delay the creation of the yielded pair till they're actually useful. You can't use zip() with Prime.new in ruby, but you can in python. Well you can in ruby cause we have call/cc :) In the end I just think that there is reason for having generator.rb in the core lib :)