4 ms·

From my observation, the ruby community is heavily skewed by the recent influx of Rails programmers, which is web dev and younger. Old-school ruby folks (the g

From my observation, the ruby community is heavily skewed by the recent influx of Rails programmers, which is web dev and younger. Old-school ruby folks (the guys who were ruby gurus when Rails was still an infant) have different characteristics: older, less confrontational, veteran programmers, Matz-like. A generalization for sure but my impression. The python community has done significant development in science/math so they have stronger libraries in those fields. Python has had an influx of Railsy people due to Django and might get a shot in the arm from Google App Engine. From a language perspective, I like the wealth of libraries for python. I like that many reference/experimental applications on web stuff is in python. The whitespace issue for me has disappeared and I'm actually leaning toward liking it more than ruby's block delimiters. The template/erb issue can be diffused by looking at HAML. (That's a cool way of incorporating pythonic indentation to templates.) Unicode is solid in python. Ruby is a better choice if you like to reshape the language into something that could potentially look un-Ruby. It's possible I haven't gotten far enough into python yet, but I can see why metaprogramming and DSLs are more prevalent in ruby than python, and it's not just "one way" culture. (Ruby's optional parentheses for method calls is an example of a language feature that fosters DSL use.)

aristus 18y ago
I have to agree. Ruby has incredible flexibility, but how it's been used by "the kids" in things like Rails (and especially Rails extensions) makes my skin crawl. This also bugs me to no end: nil.to_i == 0, 0 evals true, but nil evals false. Python's lack for me is anonymous functions. It's cumbersome to set up 40 slightly different named functions and a hash table (or some "factory pattern" thing) to do the same job as 3-4 lines of Ruby. Symbols are nice too. But for my personal work I choose Python for the libraries, cleanliness, and performance.
- DocSavage 18y ago
  What are you doing that can't be done with python's lambda functions?
  - aristus 18y ago
    Anything that is not a simple expression. assignment, if..else, etc.
    - kashif 18y ago
      Then use a function with some introspection and pass it some parameters.
      - cturner 18y ago
        You can but you shouldn't need to. Sometimes I want to do something like: dict['item'] = def _(var1, var2): fn_var = 1 do_some_magic(fn_var, var1, var2) There's no good reason why I should instead have to do: def fn(var1, var2): blah dict['item'] = fn .. or write a decorator. I'm frequently tempted to write a python-like scheme syntax to sit in my python programs so I can just do this stuff and to hell with the excuses used to prevent my first code block from above from working.
        LogicHoleFlaw 18y ago
        It's been a while since I wrote any Python but... here's a shot in Lua. Lua: function dict.item (var1, var2) local fn_var = 1 do_some_magic(fn_var, var1, var2) end -- note that: function dict.item (arg) return arg end -- is syntax sugar for: dict.item = function (arg) return arg end -- for an implicit "self" parameter use a : in your declaration and invocations: function dict:item (arg) return self(arg) end -- is sugar for dict.item = function (self, arg) return self(arg) end You can in fact call functions with the implicit (via :) self parameter with any desired "self" by using the "." rather than ":" invocation syntax and providing an explicit self. ":" is purely sugar which is optional in all cases. function table:swap() local swapped = {} for k, v in pairs(self) do swapped[v] = k end return swapped end -- assume "Table()" returns a table which routes "method_missing" calls -- (which is actually the __index metamethod in Lua) -- to `table` t = Table { a = "foo", b = "bar" } a = t:swap() b = table.swap(t) -- a and b are both equal to: -- { foo = "a", "bar" = b } One neat thing about Lua is that the user can define basically arbitrary semantics for inheritance, mixins, and all sorts of meta stuff very simply. And you can define them on a per-object basis. It's very powerful. The drawback is that you have to implement these things yourself (unless you use a 3rd-party lib which provides some common patterns like you'd see in Python or Ruby).
olefoo 18y ago
Another factor that pushes python forward among people for whom programming is a means not an end is that it is a primary scripting language for Ubuntu and is heavily used in the Red hat descended distros as well... On some level choice of programming language is irrelevant, since any specified functionality can be written in any turing complete language. Arguments about programming language are arguments about style rather than substance. I suspect that the python vs. ruby debate is like arguing about whether keyboards or guitar are superior musical instruments. They both have their place and the world would be sadder and smaller place if either one went missing.

aristus 18y ago

I have to agree. Ruby has incredible flexibility, but how it's been used by "the kids" in things like Rails (and especially Rails extensions) makes my skin crawl. This also bugs me to no end: nil.to_i == 0, 0 evals true, but nil evals false. Python's lack for me is anonymous functions. It's cumbersome to set up 40 slightly different named functions and a hash table (or some "factory pattern" thing) to do the same job as 3-4 lines of Ruby. Symbols are nice too. But for my personal work I choose Python for the libraries, cleanliness, and performance.

DocSavage 18y ago
What are you doing that can't be done with python's lambda functions?
- aristus 18y ago
  Anything that is not a simple expression. assignment, if..else, etc.
  - kashif 18y ago
    Then use a function with some introspection and pass it some parameters.
    - cturner 18y ago
      You can but you shouldn't need to. Sometimes I want to do something like: dict['item'] = def _(var1, var2): fn_var = 1 do_some_magic(fn_var, var1, var2) There's no good reason why I should instead have to do: def fn(var1, var2): blah dict['item'] = fn .. or write a decorator. I'm frequently tempted to write a python-like scheme syntax to sit in my python programs so I can just do this stuff and to hell with the excuses used to prevent my first code block from above from working.
      - LogicHoleFlaw 18y ago
        It's been a while since I wrote any Python but... here's a shot in Lua. Lua: function dict.item (var1, var2) local fn_var = 1 do_some_magic(fn_var, var1, var2) end -- note that: function dict.item (arg) return arg end -- is syntax sugar for: dict.item = function (arg) return arg end -- for an implicit "self" parameter use a : in your declaration and invocations: function dict:item (arg) return self(arg) end -- is sugar for dict.item = function (self, arg) return self(arg) end You can in fact call functions with the implicit (via :) self parameter with any desired "self" by using the "." rather than ":" invocation syntax and providing an explicit self. ":" is purely sugar which is optional in all cases. function table:swap() local swapped = {} for k, v in pairs(self) do swapped[v] = k end return swapped end -- assume "Table()" returns a table which routes "method_missing" calls -- (which is actually the __index metamethod in Lua) -- to `table` t = Table { a = "foo", b = "bar" } a = t:swap() b = table.swap(t) -- a and b are both equal to: -- { foo = "a", "bar" = b } One neat thing about Lua is that the user can define basically arbitrary semantics for inheritance, mixins, and all sorts of meta stuff very simply. And you can define them on a per-object basis. It's very powerful. The drawback is that you have to implement these things yourself (unless you use a 3rd-party lib which provides some common patterns like you'd see in Python or Ruby).

olefoo 18y ago

Another factor that pushes python forward among people for whom programming is a means not an end is that it is a primary scripting language for Ubuntu and is heavily used in the Red hat descended distros as well... On some level choice of programming language is irrelevant, since any specified functionality can be written in any turing complete language. Arguments about programming language are arguments about style rather than substance. I suspect that the python vs. ruby debate is like arguing about whether keyboards or guitar are superior musical instruments. They both have their place and the world would be sadder and smaller place if either one went missing.