> In the second case, there's one shell task. You tell it which runtime > to use. It's like throwing a toggle switch, the same way I run specs > with Ruby and JRuby (have to test with both), I can run the same shell > task with either one. > > I'm not convinced we need a lot of shell tasks. I can see the utility > in being able to flip that switch, maybe I like using irb and you like > using jirb, or I need to run with both for testing purposes. It's > easier to flip the switch from the command line than edit the > buildfile, so it's a nice feature to have. > > I guess what it boils down to is, I see myself using shell a lot, I > don't see myself using a lot of shells.
This is the situation I envision. I like to test out stuff as I develop (in Java) using an interactive shell. Most of the time I want to use Scala's shell for that. However, there are a lot of times when a dynamic type system is helpful. In those cases, I prefer to use jirb since I like the syntax better than groovysh. However, when developing in Scala, I will almost *always* use scala's shell. Likewise, when developing in Groovy, I will almost always use groovy's shell. I see the "lots of shells" as more useful under Java development, which doesn't have a de facto standard shell. I do see your point though that most users will probably stick with just one (usually the language default). Daniel
