From: Eleanor McHugh <eleanor@...>
Date: 2010-11-30T22:08:39+09:00
Subject: Re: Ruby's "More than one way to do things."

On 29 Nov 2010, at 22:21, Michal Suchanek wrote:
> On 29 November 2010 19:40, deepak <kannan.deepak@gmail.com> wrote:
>> Not really sure how the python zen works. Maybe having no choice in
>> indentation, multi-line lambdas etc are obvious. i dunno. If it comes
>> with experience and then it is no better than having options and
>> discovering the best option through experience, irc, mail-group,
>> benchmarks, awesome community, pretty ok docs and your own common
>> sense and good taste.
> 
> The point is that there is no one right way, the right way depends on context.
> 
> The python zen does not work for me at least. Take a small example:
> 
> Python is supposedly an object oriented language but you don't have
> 
> "string".len
> 
> you only have
> 
> len("string")
> 
> supposedly for the case when an object does not implement len by
> itself but the length can still be determined (possibly to be 1 or or
> 0 on scalars).

Funnily enough this "special case" style is one of my single greatest annoyances with OO in Go, and yet to the Python programmers who constitute a large part of that community it's considered a plus point.

> Sure, in Python you can't just monkey-patch a len to something that
> could have it determined but does not implement it so to have only one
> true way you need a procedural len() which goes against OO.

Technically this doesn't break OO per se, rather it's a special form known to the compiler/interpreter which mirrors object manipulations as the application of functions rather than the sending of messages. Instead of asking if a particular object can respond to a particular method this styles asks whether that object is the right "shape" to be passed to a given function. From what I recall of Python it doesn't do a huge amount with this concept, but Go really runs with it thanks to its combination of interfaces and type inference.

This is great for a statically typed language that wants to feel like a dynamic language, but the downside is that a programmer needs to keep that model in their head as well as any others that the language supports. As both Python and Go allow message passing syntax as well that means supporting two world views where in Ruby or Smalltalk we'd only need the message passing model.

> In Ruby you have "string".length and you can always write procedural
> len() if it makes your code look nicer and you can also add length to
> any object you want (well, except for integers but you could use some
> voodoo if you really insisted).


One of the great strengths of Ruby is that it exposes the interpretation infrastructure to programs in a very clean and manipulable manner which is why it's so DSL friendl. We pay a certain performance and memory footprint cost for this flexibility but it puts more constrained languages at a great disadvantage for real-world problems. And of course we need to put that bit more care into how code if we want it to be maintainable.


Ellie

Eleanor McHugh
Games With Brains
twitter: @feyeleanor
----
raise ArgumentError unless @reality.responds_to? :reason