Seems unnecessarily complicated. The whole point of IRB is to always be in Ruby mode. Being able to "drop down" into other out-of-band evaluation modes seems like a useful idea, but that's the exception, not the main use case.
So this looks less like a REPL than a gdb-like interactive debugging tool. But unless it can be used for attaching to and inspecting live running processes, it doesn't seem all that useful.
Indeed, it started out as a debugging tool. Weighing in at 2800 lines, it's going the way of irb, giving you a lot of functionality you may never use. For a more modular irb alternative, see http://github.com/cldwalker/ripl. To attach to live running processes, see https://github.com/ileitch/hijack
It's actually built for this purpose. It's not supposed to be anything like ripl is. I'd also recommend using that as a lightweight IRB alternative. But Pry isn't supposed to be that.
Also, Pry is currently weighing in at less than 2 thousand lines. It's not going the way IRB is going, but it is indeed very feature full, and probably will contain stuff you may not use every day. It's also easy to extend, so moving commands out of core and abstracting them into their own external libraries would be simple, would we ever want/need to slim the library.
Is being "large" and feature-rich a bad thing for a command-line tool? I don't want gems with unnecessary features bloating my projects, but I have no issue with feature-rich gems that help me develop more effectively, even if I don't use all of the features present.
Comments
Seems unnecessarily complicated. The whole point of IRB is to always be in Ruby mode. Being able to "drop down" into other out-of-band evaluation modes seems like a useful idea, but that's the exception, not the main use case.
So this looks less like a REPL than a gdb-like interactive debugging tool. But unless it can be used for attaching to and inspecting live running processes, it doesn't seem all that useful.
Indeed, it started out as a debugging tool. Weighing in at 2800 lines, it's going the way of irb, giving you a lot of functionality you may never use. For a more modular irb alternative, see http://github.com/cldwalker/ripl. To attach to live running processes, see https://github.com/ileitch/hijack
It's actually built for this purpose. It's not supposed to be anything like ripl is. I'd also recommend using that as a lightweight IRB alternative. But Pry isn't supposed to be that.
Also, Pry is currently weighing in at less than 2 thousand lines. It's not going the way IRB is going, but it is indeed very feature full, and probably will contain stuff you may not use every day. It's also easy to extend, so moving commands out of core and abstracting them into their own external libraries would be simple, would we ever want/need to slim the library.
$ wc -l lib/pry/*.rb | tail -1 -> 2801 total
I guess you're referring to lines of code. But if we're talking about that then you're actually pretty close to the original irb in size.
"It's also easy to extend, so moving commands out of core and abstracting them into their own external libraries would be simple"
Moving code around is simple yet pry's current extendability and abstraction is all of one plugin
Is being "large" and feature-rich a bad thing for a command-line tool? I don't want gems with unnecessary features bloating my projects, but I have no issue with feature-rich gems that help me develop more effectively, even if I don't use all of the features present.
It seems unnecessary features is in the eye of the beholder.
This thread is about pry. Don't you think three separate comments pimping ripl is a bit much?
Downvotes for pointing out a fact about pry's size, comparing it to a relevant project (one I've made) and pointing to additional info. Really HN?