From: gabriele renzi Date: 2004-10-21T09:49:18+09:00 Subject: Re: Python vs. Ruby (Re: A concise description of Ruby?) Nikolai Weibull ha scritto: > * gabriele renzi [Oct 21, 2004 00:40]: > >>>Counter examples are (somewhat) welcome ;-) > > >>I know some, the points I remember are: > > > And here is what you should respond to their counterexamples: given than I actually usually give the same answers you did, I'll reply like they do ;) notice that: - I'm running to bed - where not specified differently you should intend as my pythoneers friends talking - you /should/ not answer again or we would replicate any of the usual threads :D >>- @vars sux >>- $vars too >What can be better than that? self.var , I mean is a var in self , what @ is supposed to mean?? global var *this* is descouraging! >>- why should I write 'end'?? > > > Because you're telling both Ruby and yourself where something ends? > Sure, Python uses indentation (and thus whitespace) for these things and > we all know what problems people have with indentation and whitespace > (tabs vs. spaces, make, and so on). we do? a wise pythoneer would not ever use tabs, if he does I won't use it's code cause it would sux anyway. And you're going to indent anyway, don't you, so why bother with specifying writing ends? (my arguments here is to show [1,2,3].map do .... end.compact ) Anyway tabs will be prohibited in python3k >>- functions should be objects and __call__ is cool (the function >>aplication operator, () ) > > > This is a joke, no? I'll assume it is and will stop here. (pythoneers do really strange tricks with function objects that we just would never think of.. I'd like some more syntax sugar for Proc#call anyway ) >>- multiple inheritance is a good thing > > > Multiple inheritance has its merits, but generally it makes class > hierarchies both harder for the compiler and for the programmer to > understand. Very few objects one may want to model require multiple > inheritance (mostly geometrics). You can do fine without it. >>- __nonzero__ is sometimes useful (#to_bool for rubyists ) > > > Why? In Ruby, everything but false and nil is true, so why would you > want this? If you would want a #to_bool, then use that instead. Using > pseudo-truthvalues on objects is both bad style and confuses the > intention of the code. he>personal opinion (*I* agree, but there are even rubyists asking for to_bool from time to time :) >>- blocks are useless > > > You are surely joking again, no? Blocks are probably the _one single > thing_ that makes Ruby great. Blocks, or closures as they are often > called, are what makes Lisp/Scheme great. They are basically what > defines both Ruby and Lisp/Scheme. If you find them useless you surely > shouldn't be using Ruby. he> Python has lambda me> python's lambda sux he> true, that's why I use functions me> but why use a function! he> why not? me> well, suppose you have somefunc(func): func(a) you'd use a lambda! he> no, I'd just pass the function object me> well, but what if you don't have one good function? he> I write one me> well, suppose it is as easy as lambda a: existing(a,2) he> I'd write it as somefunc(func, *args) func(a,*args) somefunc(existing,2) me> yes but.. Also, if they are useless, why does Python have them? yeah, they're going to disappear in python 3k, luckily >>- python's metaclasses are great > > > Why are they better than Ruby's? they're basically a different concept, if you're talking of singleton classes. Python's metaclasses allows you to build object hierarchy's where Klass.class != Class. (You can do the same in ruby, with different approaches, usually, but somewhat they seem cool) >>- list comprehensions are far better than map() and the likes > > > Yes, that's why Ruby doesn't have map(); that's why we have .map. Why > do you find that > > l = [1, 2, 3] > [i * 2 for i in l] > > is far better than > > l = [1, 2, 3] > l.map{ |i| i * 2 } > > ? It's not like one version is longer than the other, or one is easier > to follow than the other? In fact, the Python version requires the use > of two keywords and an additional feature of list creation. because I can do: l=[ x**2 for x in list if x >0] one iteration unifies both filtering and transformation (I really think we should have something like that in ruby :/ ) Oh, and nowadays we have generator expressions, so we can even have lazy generators done this way, while in ruby you have stuff like zip that would end up as a memory hog (here you show generator.rb, but call/cc performance is bad) And I can write quicksort in three lines (splitted cause I don't understand how thunderbird works) def qs(L): if len(L) <= 1: return L return qs([lt for lt in L[1:] if lt < L[0]]) + \ [ L[0] ] + qs( [ ge for ge in L[1:] if ge >= L[0] ] ) (my best effort is 6 line, but more readable :) >>- hey, writing self is good, you can name it cls or ignore it when non >>writing instance methods > > > How is that a good thing? If you want to ignore it, then wouldn't you > rather simply not mention it at all? In static methods you ignore self. In class and metaclass methods you use cls. > If you had given a decent argument > for this, such as "I use it as a reminder that obj.method(...) is more or > less like writing method(obj, ...) as : is in Lua", then at least you > would have made an argument for your point. Of course you argument also holds, and relates to the tricks we can do in python, such as foo=module.module.object.foo foo(a) #equals to object.foo(a), but saves 3 lookups >>- having separated concepts for statements and expressions is useful >>(just heard once) > > > What do you mean? That everything shouldn't have a value? If so, why? > I admit that it's not always useful, but there certainly are times that > one appreciates this and there's no reason it shouldn't be this way. It > only simplifies the concepts, both for the programmer, the language > designer, and the compiler. Writing a denotational semantics for the > language. ( can't remember sorry :/) > >>- callcc is the devil > > > Yes, certainly, and look how easy it is to simulate in Python: > > http://www.ps.uni-sb.de/~duchier/python/continuations.html good reason to not have it in the language > You obviously don't understand what you're talking about. You just > followed some of the threads about continuations and thought to yourself, > "Boy, I'm certainly not following this discussion. I'll just say that I > think that call/cc is evil and people will think that I've thought this > through and that I am somehow gifted." I think this cause We had continuations in stackless python and we removed 'em cause tasklets are better, simpler and does not reinvent wheels. > >>- TIMTOWTDI is a wrong concept > > > That's why Ruby isn't Perl. I can't really tell what you are getting at > with this point. having: %{foo} %.foo. %q{foo} %Q{foo} %q miao "foo" 'goo' is useless timtoetidy >>- general dislike of %stuff literals > > > You mean like %{literal}? Don't use them then. don't using is not a chance, I may encounter code written by others using it. > Is it better to have '''literal''', """literal""", r"literal", > u"literal", ur"literal", U"literal", UR"literal", Ur"literal", and > uR"literal". Yeah, that's certainly _a lot_ better. it's just u and r and this is just a case. timotoetidy is everywhere in ruby, just think of ho many ways you can read lines from a file in ruby. > >>- lack of named arguments > > > While it is true that Ruby doesn't have named arguments as such atm (you > may use hashes instead), there is a nice syntax in the works for later > versions. see? you just copy! >>- docstrings are cool > > > Yes, they are. Finally, an argument that actually stands up against > simple critique. Ironic that it should be your last choice ;-). me> deheheh :) > >>note that not all of them think all this, I just summed all the >>different critics. > > >>But I think they just had a quick look at ruby, not a deep one, and they >>usually agree that in the end there are far more similarities than >>differences. > > > Hopefully not too many similarities ;-), > nikolai I actually hope for more, like having blocks and implicit things in python :D