Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python for Ruby Programmers (LA RubyConf 2013)

speakerdeck.com

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Python for Ruby Programmers (LA RubyConf 2013)

#31

Post by dagw »

untothebreach wrote: post #29
throwa wrote: post #11

Earlier quoted context omitted.

Except if you have a good reason for wanting to learn Python, I will say as a rubyist you should learn a functional programming language like clojure or scala if you don't know them already. This is because both Python and Ruby are OO and similar in alot of ways.

I would say you are right except in one case, which is scientific computing. The OP touched on it, but that is definitely the "killer app" of the Python ecosystem, IMHO. Not that the languages you mentioned don't have equivalents, but if you are a rubyist who just wants to do some heavy-duty scientific/data-intensive computing without stepping too far out of your comfort zone, I can see Python being an attractive opt…

I would say you are right except in one case

I would add GIS as a second (if somewhat niche) case. The two big commercial players in the field (ESRI and Safe) as well as most of the open source players all have Python as a scripting language

Re: Python for Ruby Programmers (LA RubyConf 2013)

#32

Post by untothebreach »

dagw wrote: post #31
untothebreach wrote: post #29

Earlier quoted context omitted.

I would say you are right except in one case, which is scientific computing. The OP touched on it, but that is definitely the "killer app" of the Python ecosystem, IMHO. Not that the languages you mentioned don't have equivalents, but if you are a rubyist who just wants to do some heavy-duty scientific/data-intensive computing without stepping too far out of your comfort zone, I can see Python being an attractive opt…

I would say you are right except in one case I would add GIS as a second (if somewhat niche) case. The two big commercial players in the field (ESRI and Safe) as well as most of the open source players all have Python as a scripting language

Interesting! I don't really have _any_ experience with that field, so I definitely would not have guessed that Python was so prevalent. Thanks!

Re: Python for Ruby Programmers (LA RubyConf 2013)

#33

Post by masklinn »

untothebreach wrote: post #24
masklinn wrote: post #16

Earlier quoted context omitted.

> I don't really see where you're getting at as far as substitutes for 'reduce' are concerned. Reduce simply isn't used much in Python code, as a product of both culture and rather lacking lambdas. It's used so little (pretty much the only "usual use case" is covered by `sum`) it's been moved out of the builtins and to the functools module in Python 3 (whereas `map` and `filter` have remained)

Thank you, that was much more eloquently put than I could have provided. Indeed, `sum` was the one common use case I could think of, so I didn't bother including it as an example. I honestly can't say I miss `reduce` at all when writing python.

> Indeed, `sum` was the one common use case I could think of

There are 4 other not-completely-uncommon cases in the builtins, implemented in a significantly more efficient manner for the latter 2 (ignoring Python v C): min, max, any and all. And map and filter technically but repeatedly concatenating lists together (in python) isn't the most useful way to peg your CPU.

Re: Python for Ruby Programmers (LA RubyConf 2013)

#34

Post by tommy_m »

untothebreach wrote: post #29
throwa wrote: post #11

Earlier quoted context omitted.

Except if you have a good reason for wanting to learn Python, I will say as a rubyist you should learn a functional programming language like clojure or scala if you don't know them already. This is because both Python and Ruby are OO and similar in alot of ways.

I would say you are right except in one case, which is scientific computing. The OP touched on it, but that is definitely the "killer app" of the Python ecosystem, IMHO. Not that the languages you mentioned don't have equivalents, but if you are a rubyist who just wants to do some heavy-duty scientific/data-intensive computing without stepping too far out of your comfort zone, I can see Python being an attractive opt…

I am in the exact same situation. I know Ruby, as my first language, but keep running into scientific applications where Python or R is used. The languages are so similar, it is pretty easy to move between the two at a superficial level, but does take away some bandwidth trying to stay current in them both. It seems that if you are going to do web based work, Ruby is a good choice, but it you are going to be actively involved in non-weby stuff, Python is a better choice. I say this as a dedicated Ruby guy, who would rather stay with it, but am being pushed into more and more Python....

Re: Python for Ruby Programmers (LA RubyConf 2013)

#35

Post by emidln »

dstywho wrote: post #10

One of the things that bothers me about python is the way you have to specify 'self' for instance methods. Instance methods should be the norm not the exception.

Methods are type specialized functions, just syntactic sugar for calling functions with a context (provided by an instance of the required type) that you defined elsewhere.

    class Foo(object):
        def __init__(self, bar):
            self.bar = bar
        def something(self, arg):
            return [self.bar, arg]
I can do this:

    assert(Foo('spam').something('eggs') == Foo.something(Foo('spam'), 'eggs')
But I could also do this:

   assert(Foo('spam').something(Foo('ham'), 'eggs') == ['ham', 'eggs'])

Re: Python for Ruby Programmers (LA RubyConf 2013)

#36

Post by masklinn »

untothebreach wrote: post #32
dagw wrote: post #31

Earlier quoted context omitted.

I would say you are right except in one case I would add GIS as a second (if somewhat niche) case. The two big commercial players in the field (ESRI and Safe) as well as most of the open source players all have Python as a scripting language

Interesting! I don't really have _any_ experience with that field, so I definitely would not have guessed that Python was so prevalent. Thanks!

This influence/importance can also be seen in the existence of GeoDjango, which is shipped with Django itself[0], where Ruby seems to have the old GeoRuby[1], the rather recent (and with unsure following) RGeo[2] or doing raw PostGIS.

Also in OpenGEO, looking at their projects, aside from PostGIS it's either Python (and JS) or Java (and JS)

[0] https://docs.djangoproject.com/en/dev/ref/contrib/gis/

[1] http://rubyforge.org/projects/georuby/

[2] http://dazuma.github.com/rgeo/

Re: Python for Ruby Programmers (LA RubyConf 2013)

#37

Post by ufo »

masklinn wrote: post #21
ufo wrote: post #3

Broke my heart when he said you shouldn't need powerful anonymous functions :(

It's so highly unlikely you'll get them, you should probably resign yourself (or use a different language, or try to approach it from the other direction: convert Python statements to expressions so you can use them in existing lambdas, after all Python's current lambdas are no more restricted than Haskell's, it's just that the rest of Python doesn't play nice with them)

I know Python will probably always have shitty suport for functional stuff. What bothered me the most was the bit in his presentation where he said using anon functions are "harder to test", "harder to follow" and lead to code duplication, implying you should instead create a stupid named func like "process_num" instead of passing a lambda to map directly.

Re: Python for Ruby Programmers (LA RubyConf 2013)

#38

Post by csense »

untothebreach wrote: post #25
masklinn wrote: post #23

To add to other comments, things the author could have expanded upon: * vararg keyword arguments ( kwargs) * Keyword-only arguments (Python 3) * help, vars, a few other nice introspective builtins * Assignment unpacking (multiple names as left-hand side of an assignment) * The strangest "first blush" difference between Ruby and Python, or at least the one which I found oddest when I first started switching, is that a…

> Python's reflection and metaprogramming are roughly on par with Ruby's, their lack of use is more of a cultural artefact than a technical one. +1 on everything you listed, but especially this. You _do_ see some examples of monkey-patching in Python, but at least in my very limited experience, it tends to be much less prevalent in Python than it does in Ruby. Any data to contradict this is welcome, however.

This also might fall along the lines of "you usually don't want to do this, because anyone else who works on the codebase afterwards will hate you for it."

Monkey-patching also makes it harder to easily determine which names come from which source files, which is one of the strengths of Python code: Python's import system or explicitly using "self" make Python much superior to other languages.

Re: Python for Ruby Programmers (LA RubyConf 2013)

#39

Post by csense »

arxanas wrote: post #9

The presentation incorrectly identified Python dictionaries as “lists”. It also identified actual Python lists as lists. The presentation states that tuples are “immutable lists“ and that they ”should be homogeneous, but [this is] not enforced“. I disagree: tuples are meant to act as “records“ (as in a database or other set of data), which are neither lists nor homogeneous. The presentation brought up multiple times…

> it is far easier to dynamically define a method in Ruby than in Python

I don't know Ruby. But it's hard for me to imagine a syntax that could express any of several related operations which could reasonably be called "dynamically defining a method" in a "far easier" way than Python does. So please enlighten me, and the other "Pythonistas" who may be reading this article, as to exactly what this magical syntax is. (The clearest explanation would include some equivalent Python code or at least a plain-English explanation of what the Ruby code does -- the Ruby language's syntax has been a bit of a barrier to me.)

Re: Python for Ruby Programmers (LA RubyConf 2013)

#40

Post by pwim »

One point about "Functions as variables". Ruby actually does have method objects, which you can access via the method method.

  def add(a,b)
    a+b
  end

  def process_numbers(a,b,method)
    func.call(a,b)
  end

  method(:add) => #
  process_numbers(1,2,method(:add)) => 3
This isn't a normal programming paradigm in Ruby though.
Post reply on HN