Python vs. Ruby

We would like to move to a higher-level language in future versions of Campcaster. Current debate is over Python vs. Ruby. They are both good languages, but we need to know whether each one will do what we need it to do.

Libraries

Currently, the C++ code uses the following libraries. Make notes next to each as to whether they are supported in each language.

  • unixodbc (Python:  here, Ruby:  here)
  • xml-rpc (Python: built-in to the language, see  this, Ruby: also built-in to the language, see  this)
  • curl (Python:  here, Ruby:  here)
  • tar (Python:  part of the standard library, Ruby: ???)
  • libxml (Python:  here and  here, Ruby:  here)
  • libicu (Python: Unicode support built-in, Ruby: Unicode built-in)
  • gtk (Python:  here, Ruby:  here but may not support everything, see:  here)
  • taglib (Python:  here and  here, Ruby:  here)
  • gstreamer (Python:  here, Ruby: unknown… the Gnome Ruby/Gstreamer project was cancelled, there seems to be something flacky  here)
  • libserial (Python:  here, Ruby:  here)

Future Libraries of Benefit

One language may have libraries that we want to use in the future. Make notes of those here.

  • qt (Python:  commercial support for QT4, Ruby:  here (seems to support QT4) and a  book)
  • audio libs…

Other Considerations

Advantages of Python:

  • Speed: Python seems to be 2-3 times faster than Ruby. Python also has  Psyco, which claims to speed up python by 2-100x. Rumor has it that Ruby 2.0 will be more speedy, but no indication of when 2.0 is coming out. Websites with comparisons of speed:
  • Python supports native threads: the most notable difference is that blocking system calls block all threads in Ruby, and just the calling thread in Python. If you invoke a long-running call in Ruby (such as a socket read), all other threads are blocked. Python releases the global interpreter lock for such calls, allowing other threads to run. With Python each thread gets scheduled by the OS separately and so threads will not become starved. Though Python supports native threads, Python threads cannot take advantage of multiprocessors since only one thread can run at a time.
  • Python has better debugging messages (this one needs to be verified, could be outdated…put examples of debugging messages below)
  • Python can run on top of the Java JVM using Jython ( http://www.jython.org/Project/index.html) and re-use Java classes
  • You can bundle Python programs into single executables using PyInstaller ( http://pyinstaller.python-hosting.com/)

Advantages of Ruby:

  • Speed: Ruby 2.0 approaching; dramatic speed increase expected (does not exist yet, no date for release known. -Paul)
  • Pure object oriented language: Everything is an object. (More or less the same with Python:)
    a=1
    a.__add__(3)
    
  • “Self” is implicit. No need to write self.foobar().
  • Built-in Regexps (not an advantage since Python has these as well. -Paul)
  • Iterators and closures (based on passing blocks of code) (not an advantage since Python has these as well. -Paul)
  • Introspection, reflection and meta-programming (not an advantage since Python has these as well. -Paul)

Misc Interesting Stuff

  • Comparison of same code in Python, Ruby, Java, and C++ :  http://www.dmh2000.com/cjpr/cmpframe.html
  • A small  calendar application in C++/libglade and Ruby/Libglade. I am planning to write the same in other combinations, like Ruby/Qtdesigner, Python/Qtdesigner etc, time permitting.
  • Interesting Python behavior:
    • x = x + y is not the same as x += y for mutable objects:
      def f(x): x = x + [ "B" ]
      def g(x): x += [ "B" ]
      l = [ "A" ] ; f(l) ; print l    # prints ['A']
      l = [ "A" ] ; g(l) ; print l    # prints ['A', 'B']
      
    • but it is the same for immutable objects:
      def f(x): x = x + "B"
      def g(x): x += "B"
      l = "A" ; f(l) ; print l        # prints A
      l = "A" ; g(l) ; print l        # prints A
      
  • Ruby is currently the programming language  with the fastest growing popularity.

The Zen of Python:

  • Explicit is better than implicit.
  • Simple is better than complex.
  • Complex is better than complicated.
  • Flat is better than nested.
  • Sparse is better than dense.
  • Readability counts.
  • Special cases aren’t special enough to break the rules.
  • Although practicality beats purity.
  • Errors should never pass silently.
  • Unless explicitly silenced.
  • In the face of ambiguity, refuse the temptation to guess.
  • There should be one– and preferably only one –obvious way to do it.

Zen of Ruby

  • The Human Factor

“We need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.”

  • Principle of least surprise

“Everyone has an individual background. Someone may come from Python, someone else may come from Perl, and they may be surprised by different aspects of the language. Then they come up to me and say, “I was surprised by this feature of the language, so therefore Ruby violates the principle of least surprise.” Wait. Wait. The principle of least surprise is not for you only. The principle of least surprise means principle of least my surprise. And it means the principle of least surprise after you learn Ruby very well.”