5 ms·

How would people that use both Python and Ruby compare the tooling for both languages? I only am familiar with Python, and I end up using IPython most of the ti

How would people that use both Python and Ruby compare the tooling for both languages? I only am familiar with Python, and I end up using IPython most of the time. I'm curious whether I'm missing out, or maybe Python also has "terrible" tooling..

steveklabnik 11y ago
> LRT: Don't think Perl or Python gets off the hook for the tooling that @avdi > talks about. https://twitter.com/brianwisti/status/618815261580263425 https://twitter.com/brianwisti/status/618815261580263425
- hogu 11y ago
  what is wrong with IDEs like pycharm/intellij?
boardwaalk 11y ago
This is pretty specific, but Ruby has pretty terrible support for parsing Ruby. Libraries are either unmaintained or broken or for old versions. Python is great for parsing ('import ast'), compiling ('compile(...)') and executing ('exec(...)'). So it's much easier to write code generators, write linters and autocompletion tools and such.
- cremno 11y ago
  >but Ruby has pretty terrible support for parsing Ruby https://github.com/whitequark/parser https://github.com/whitequark/parser Neither unmaintained, broken nor just for old versions. It has some really minor incompatibilities though: https://github.com/whitequark/parser#known-issues https://github.com/whitequark/parser#known-issues The same person also wrote a Python parser because apparently the ast module doesn't provide precise location information of tokens: https://github.com/m-labs/pythonparser https://github.com/m-labs/pythonparser
- graffitici 11y ago
  I had looked into the 'ast' module a little while back, and I do agree that it's pretty neat. The main use I've seen it type checking, or adding language level features (that would typically be done by macros in LISP). I am not aware of many tools written using 'ast', that don't try to extend the language in some way. Any thoughts there?
- cheald 11y ago
  It's fine in MRI. > seq = RubyVM::InstructionSequence.compile("a = 1 + 2") => <RubyVM::InstructionSequence:<compiled>@<compiled>> > puts seq.disasm == disasm: <RubyVM::InstructionSequence:<compiled>@<compiled>>========== local table (size: 2, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1]) [ 2] a 0000 trace 1 ( 1) 0002 putobject_OP_INT2FIX_O_1_C_ 0003 putobject 2 0005 opt_plus <callinfo!mid:+, argc:1, ARGS_SIMPLE> 0007 dup 0008 setlocal_OP__WC__0 2 0010 leave => nil > seq.eval => 3
jbbarth 11y ago
I'd say Python tooling may be OK at language level, even slightly better (code introspection abilities are more recent in ruby I think, the fact you could get method docs, method def, etc.). The equivalent for IPython (shell version, not notebooks) in Ruby is pry and it's pretty good. On the other side, in Python higher-level tools are horrible from an operational perspective, and much worse than Ruby's if you ask me (pip vs bundler, rbtrace vs.. gdb-python(?), pry/pry_remote vs pdb, ...). Also +1 on boardwaalk's comment, this side of Python is pretty good.
- krakensden 11y ago
  Pip+virtualenv is great from an operational perspective- it makes building tarballs to ship super easy.
pjmlp 11y ago
In case you are on Windows, this is a good choice, https://www.visualstudio.com/en-us/features/python-vs.aspx https://www.visualstudio.com/en-us/features/python-vs.aspx
dehora 11y ago
Python is slightly easier in my experience to refactor and manage as the codebase grows, somewhat easier to get performance wins out of, somewhat easier to debug. But it's approximately in the same bucket as Ruby when it comes to tooling - put another way, you probably wouldn't switch to Python from Ruby because of the relative improvement in tool support. I think Avdi's right in the sense that weak tooling is inevitable due to the language's properties. With Ruby and Python, what you gain in near term productivity and effectiveness you pay for later - your tipping point may vary.

steveklabnik 11y ago

> LRT: Don't think Perl or Python gets off the hook for the tooling that @avdi > talks about. https://twitter.com/brianwisti/status/618815261580263425 https://twitter.com/brianwisti/status/618815261580263425

hogu 11y ago
what is wrong with IDEs like pycharm/intellij?

boardwaalk 11y ago

This is pretty specific, but Ruby has pretty terrible support for parsing Ruby. Libraries are either unmaintained or broken or for old versions. Python is great for parsing ('import ast'), compiling ('compile(...)') and executing ('exec(...)'). So it's much easier to write code generators, write linters and autocompletion tools and such.

cremno 11y ago
>but Ruby has pretty terrible support for parsing Ruby https://github.com/whitequark/parser https://github.com/whitequark/parser Neither unmaintained, broken nor just for old versions. It has some really minor incompatibilities though: https://github.com/whitequark/parser#known-issues https://github.com/whitequark/parser#known-issues The same person also wrote a Python parser because apparently the ast module doesn't provide precise location information of tokens: https://github.com/m-labs/pythonparser https://github.com/m-labs/pythonparser
graffitici 11y ago
I had looked into the 'ast' module a little while back, and I do agree that it's pretty neat. The main use I've seen it type checking, or adding language level features (that would typically be done by macros in LISP). I am not aware of many tools written using 'ast', that don't try to extend the language in some way. Any thoughts there?
cheald 11y ago
It's fine in MRI. > seq = RubyVM::InstructionSequence.compile("a = 1 + 2") => <RubyVM::InstructionSequence:<compiled>@<compiled>> > puts seq.disasm == disasm: <RubyVM::InstructionSequence:<compiled>@<compiled>>========== local table (size: 2, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1]) [ 2] a 0000 trace 1 ( 1) 0002 putobject_OP_INT2FIX_O_1_C_ 0003 putobject 2 0005 opt_plus <callinfo!mid:+, argc:1, ARGS_SIMPLE> 0007 dup 0008 setlocal_OP__WC__0 2 0010 leave => nil > seq.eval => 3

jbbarth 11y ago

I'd say Python tooling may be OK at language level, even slightly better (code introspection abilities are more recent in ruby I think, the fact you could get method docs, method def, etc.). The equivalent for IPython (shell version, not notebooks) in Ruby is pry and it's pretty good. On the other side, in Python higher-level tools are horrible from an operational perspective, and much worse than Ruby's if you ask me (pip vs bundler, rbtrace vs.. gdb-python(?), pry/pry_remote vs pdb, ...). Also +1 on boardwaalk's comment, this side of Python is pretty good.

krakensden 11y ago
Pip+virtualenv is great from an operational perspective- it makes building tarballs to ship super easy.

pjmlp 11y ago

In case you are on Windows, this is a good choice, https://www.visualstudio.com/en-us/features/python-vs.aspx https://www.visualstudio.com/en-us/features/python-vs.aspx

dehora 11y ago

Python is slightly easier in my experience to refactor and manage as the codebase grows, somewhat easier to get performance wins out of, somewhat easier to debug. But it's approximately in the same bucket as Ruby when it comes to tooling - put another way, you probably wouldn't switch to Python from Ruby because of the relative improvement in tool support. I think Avdi's right in the sense that weak tooling is inevitable due to the language's properties. With Ruby and Python, what you gain in near term productivity and effectiveness you pay for later - your tipping point may vary.