> LRT: Don't think Perl or Python gets off the hook for the tooling that @avdi
  > talks about.

https://twitter.com/brianwisti/status/618815261580263425

what is wrong with IDEs like pycharm/intellij?

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.

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

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.

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.

>but Ruby has pretty terrible support for parsing Ruby

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

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

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

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?

In case you are on Windows, this is a good choice,

https://www.visualstudio.com/en-us/features/python-vs.aspx