Ian Bicking: the old part of his blog

Re: Ruby python power comment 000

I'd go further than this. "Readability" has as much to do with symmetrical constructs as it does algolishness. I don't believe that it's a larger hurdle for an algol-family programmer to grok blocks than it is for them to grok list comprehensions or lambdas. And I think it's a smaller hurdle for them to grok blocks than it is for them to grok both list comprehensions and lambdas.

Ruby readability is also greatly enhanced by its perl heritage. The lack of =~ and similar is what prevent python from succeeding perl years ago. You may call these things sugar, but these are all Turing compatible languages so at the end of the day it's all sugar.

Comment on Ruby python power comment 000
by Peter Merel

Comments:

I love when people talk about turing compliance ;). The argument that any languages that are Turing compliant must be equivalent is IMO very misunderstood, by this reasoning there is no difference between any two languages (besides syntax). This simply isn't true, take for example C++ and Java, both are Turing compliant and both are OO, however there's a big difference in what you can do with them.

Another example? How about Lisp and Java, both are Turing compliant yet the list of things Java can't do is longer than my arm, one example being closures. Taking this into account obviously not all languages are equal so I would love very much for people to stop throwing Turing compliance about in this way :).

Last one, how about Python and Lisp. I read above that Python has full support for lexical closures now however I'd like to point out that this isn't exactly true as Paul Graham pointed out in the article below.

As an illustration of what I mean about the relative power of programming languages, consider the following problem. We want to write a function that generates accumulators-- a function that takes a number n, and returns a function that takes another number i and returns n incremented by i. ... In Common Lisp this would be (defun foo (n)

System Message: ERROR/3 (<string>, line 12)

Unexpected indentation.
(lambda (i) (incf n i)))

System Message: WARNING/2 (<string>, line 13)

Block quote ends without a blank line; unexpected unindent.

... If you try to translate the Lisp/Perl/Smalltalk/Javascript code into Python you run into some limitations. Because Python doesn't fully support lexical variables, you have to create a data structure to hold the value of n. And although Python does have a function data type, there is no literal representation for one (unless the body is only a single expression) so you need to create a named function to return. This is what you end up with: def foo(n):

System Message: ERROR/3 (<string>, line 16)

Unexpected indentation.

s = [n] def bar(i):

System Message: ERROR/3 (<string>, line 18)

Unexpected indentation.
s[0] += i return s[0]

System Message: WARNING/2 (<string>, line 20)

Block quote ends without a blank line; unexpected unindent.

return bar

System Message: WARNING/2 (<string>, line 21)

Block quote ends without a blank line; unexpected unindent.

Python users might legitimately ask why they can't just write def foo(n):

System Message: ERROR/3 (<string>, line 23)

Unexpected indentation.
return lambda i: return n += i

System Message: WARNING/2 (<string>, line 24)

Block quote ends without a blank line; unexpected unindent.

or even def foo(n):

System Message: ERROR/3 (<string>, line 26)

Unexpected indentation.
lambda i: n += i

System Message: WARNING/2 (<string>, line 27)

Block quote ends without a blank line; unexpected unindent.

and my guess is that they probably will, one day. (But if they don't want to wait for Python to evolve the rest of the way into Lisp, they could always just...)

http://www.paulgraham.com/pypar.html

Arguing over which is the most OOP language is somewhat silly in itself :). OOP is not an abstraction that suits every task and yet it's used everywhere now – with varying results of course. I've read a lot of code written using OO and it instantly occurs to me that the same task could be accomplished with less work and while maintaining the same amount of modularity WITHOUT all the extra work of writing classes for types and defining methods, attributes etc.

OOP is good for some things and truly horrible for others – I wish the world would realize this. All in all though they're both good languages, personally I like Ruby more. I used Python for 4 years [think it was my 4th or 5th language] and by the end just found it way to restricting to bear :).

If you haven't already you should learn both, hell you should probably learn every language that crosses your path anyway but still. Learn Ruby if your a Python user, learn Python if your a Ruby user and then you'll be better equipped to judge both languages. That and you'll learn useful concepts that may carry over?

Enjoy guys,

Mark.

# Mark Smith

Umm... What?

Python 2.3.5 (#2, Nov 20 2005, 16:40:50)
>>> def f(n):
...     return lambda x: n + x
...
>>> inc5 = f(5)
>>> inc5(10)
15
>>>

In which way isn't that lexical closure?

Oh, you mean the fact . Of course it does, but it doesn't matter.that ints are immutable in Python? Or the fact that names are just that in Python: names for objects, rather than references to slots?

That doesn't have anything to do with closure. It's just the way assignments work in Python.

Lisp requires you to declare names, distinguishing assignment from binding. Python doesn't. Is Lisp's way of doing things different? Yes, it is. Is it better? I don't think so.

Why do I think so? Your example is clearly much more elegant in Lisp than it is in Python, after all. But that's not the point. A Python programmer wouldn't use functions to represent incrementors: they would use objects (ignoring the fact that, up to now, I haven't needed an accumulator in my whole life, ever). In the context of object-orientation, Python's assignment behaviour makes a lot more sense than Lisp's. Stating that Lisp deals with functions more elegantly than Python does isn't a valid point, because it doesn't matter. It's like saying that a webcam isn't well suited for typing text: true, but not very interesting.

By the way, anonymous procedures will probably disappear from Python at some point anyway. If you really think that Python converges towards Lisp, you're probably wrong.

# Matthias Benkard

Oops... How did that happen?

s/. Of course it does, but it doesn't matter.//
# Matthias Benkard

I love when people talk about turing compliance ;). The argument that any languages that are Turing compliant must be equivalent is IMO very misunderstood, by this reasoning there is no difference between any two languages (besides syntax). This simply isn't true, take for example C++ and Java, both are Turing compliant and both are OO, however there's a big difference in what you can do with them.

I think you misunderstood Peter's post. He wasn't saying that all these languages are turing complete and, therefore, equal. In fact, he was implying the opposite of that!

Please read his post again...

He was implying that Pythonistas attack PERL's =~ operator by calling it syntactic sugar. He defended PERL by pointing out that the whole syntax of the language boils down to syntactic sugar in the face of Turing completeness. You see, he was using Turing completeness to compare the features of the language that we like to syntactic sugar to show that the =~ operator is more than just sugar. It is a legitimate feature of a language that gives it an advantage over languages that lack it. So, in the end, he's saying that Turing completeness doesn't make all languages equal...

# Id Kong