# Re: Why is there no Smalltalk-like IDE for Ruby? **URL:** \ **Category:** Ruby\ **Created:** [June 25, 2006, 10:56am UTC](https://www.ruby-forum.com/t/re-why-is-there-no-smalltalk-like-ide-for-ruby/64401 "2006-06-25T10:56:15Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![wirelesspower](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/58956e/32.png) [@wirelesspower](https://www.ruby-forum.com/u/wirelesspower)\ **Post date:** [June 25, 2006, 10:56am UTC](https://www.ruby-forum.com/t/re-why-is-there-no-smalltalk-like-ide-for-ruby/64401/1 "2006-06-25T10:56:15Z")
On Sun, 2006-06-25 at 05:20 +0900, Joseph M. wrote: > Ruby should have IDE support approaching Smalltalk’s based on the > following gross generalization: Ruby and Smalltalk are pretty much the > same. Yes, I know there are many differences, and not trying to > provoke a Ruby vs. Smalltalk cage-match, but based on language features > and constructs, they are very similar. > > What is holding Ruby back? I agree. People who say they don’t want code completion or refactoring just haven’t used it enough to know how much time it saves. I’m wicked fast with vim search and replace, but it’s not nearly as smart as it needs to be in order to be comparable to even a simple method-rename. One major problem with just about every IDE that causes resistance is that the editor component sucks in comparison to vim or emacs, which is what many people know. Once you have wired your brain to speak through your fingers the mouse just doesn’t work, and at least for me I think it’s going to take something real amazing to move away from a moded editor. (Vim 7 just came out with back-end support for code completion…) What makes this hard in ruby? I think loose typing and run-time generation/manipulation of code. That’s pretty much the big barrier to creating tools at the level of the Java world, but it is also one of the main reasons ruby is such a joy to use. Smalltalk gets around the issue by being inside a live environment, and having a unique sort of program life cycle. (You don’t really generate methods at run-time, because it is always run-time…) The tool can inspect live memory to make sure that it refactors correctly. Also, in a Smalltalk environment every class is defined in the browser, which gives you a much cleaner perspective to work from. In Java the IDEs use the front end of a compiler to build an abstract model of your program. The refactorings are actually applied to the model in a provably correct way, and then the changes are reflected back in the code. Having things like method generators, method\_missing and dynamic structs makes this impossible to do without being inside a running program that can be inspected, which just won’t work for a ruby IDE unless you turn it into a live memory type environment. Even with those problems though, I think many people agree that a best effort type of approach could still be successful for a large number of problems. If you search the list you’ll find that there are people who are collecting refactorings for ruby. Google for the ‘ruby inertia’ project and you’ll find a pretty cool start to an openGL based environment ala squeak. Once YARV is out it will help make all ruby systems like that more realistic too. The RadRails project is doing great stuff, but I have a feeling that many people in the ruby community are allergic to bloated beasts like Eclipse that require a gig of ram to be useful. Seems to me like any self respecting ruby-ide is going to have to be written in ruby. (At least most of it.) The freeride project seems to be moving along though, and I think with their pluggable architecture it’s not too hard to jump in and add new features. You might want to start there. Hopefully that helps. -Jeff ---
**Author:** ![wirelesspower](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/58956e/32.png) [@wirelesspower](https://www.ruby-forum.com/u/wirelesspower)\ **Post date:** [June 25, 2006, 6:07pm UTC](https://www.ruby-forum.com/t/re-why-is-there-no-smalltalk-like-ide-for-ruby/64401/2 "2006-06-25T18:07:14Z")
Hello Jeff, JR\> One major problem with just about every IDE that causes resistance is JR\> that the editor component sucks in comparison to vim or emacs Well this is your opinion. JR\> main reasons ruby is such a joy to use. Smalltalk gets around the issue JR\> by being inside a live environment, and having a unique sort of program Have you ever used SmallTalk ? It does not get around this. JR\> life cycle. (You don’t really generate methods at run-time, because it JR\> is always run-time…) The tool can inspect live memory to make sure JR\> that it refactors correctly. Also, in a Smalltalk environment every JR\> class is defined in the browser, which gives you a much cleaner JR\> perspective to work from. The most important is that Smalltalk names are not as short as the ruby ones and so you have less conflicts. Remember that Smalltalk methods names include parts of the parameter signature. And Smalltalk is far from being so overloaded. Also while possible the coding style of Smalltalk is much cleaner then the ruby one where people like to use the run-time features much more. This has indeed to do with the fact that Ruby does not live in an image. JR\> be useful. Seems to me like any self respecting ruby-ide is going to JR\> have to be written in ruby. (At least most of it.) Well the two projects FreeRide and Mondrian shows that you are wrong here.