Basically it boils down to the semantics of the language. Languages like Java and C# can be well supported by IDEs because the syntax is declarative. A class definition in Java isn't executable, it's just data that describes the class.
In Ruby, on the other hand, a class definition is executable. That makes meta-programming easy (eg. ActiveRecord's #has_many), but it makes tool support difficult. An IDE can't just parse the source code, it has to actually execute it find out what classes are defined.
But that's a huge can of worms! What if you wrap your class definition in "if Date.today.tuesday?" What if the script has side effects you don't want to trigger every time you open your IDE? On the other hand, once the metaprogram has executed, the program that actually executes at runtime isn't something the programmer wants to see. Imagine trying to work with a Rails app that had all the the metaprogramming flattened out of it? Tedious.
What's unique about Smalltalk is that it has both executable class definitions and an IDE. It works because the IDE only lets the programmer work with the runtime representation of the program, and not the on-disk representation. The whole ecosystem - language, libraries and tools - are designed around that paradigm.
An IDE can't just parse the source code, it has to actually execute it find out what classes are defined.
There have been a few -- I think more than 3 -- Smalltalk projects where the parser was modified so that Class definition and other code could be executed but only result in a "shadow" Class being instantiated, so that the code could be browsed before being committed to the actual image.
only lets the programmer work with the runtime representation of the program, and not the on-disk representation. The whole ecosystem - language, libraries and tools - are designed around that paradigm.
It should be possible to have it both ways with Ruby. ObjectStudio Smalltalk had declarative class files. You don't want the runtime changes to be written back to the declarative files, however. This caused lots of problems in ObjectStudio. A better approach would be to have some way of flagging the runtime change, perhaps by outputting another file, then let the user merge changes back.
From the blog post.
I'd much rather see a Smalltalk that let me create small, headless images, tens or hundreds of kilobytes in size, with just the little bits of functionality I need for a particular task. If they had good libraries for file I/O, processing text on stdin/stdout and executing other commandline programs, they'd fill the "scripting language" niche very well. If they could be created and edited by a larger IDE image, they'd have the Smalltalk tools advantages as well.
Apparently someone at Digitalk did exactly this years ago, with images as small as 45kB. I think the project was called "Firewall." This technology will never see the light of day, but it shows what is possible.
In Ruby, on the other hand, a class definition is executable. That makes meta-programming easy (eg. ActiveRecord's #has_many), but it makes tool support difficult. An IDE can't just parse the source code, it has to actually execute it find out what classes are defined.
But that's a huge can of worms! What if you wrap your class definition in "if Date.today.tuesday?" What if the script has side effects you don't want to trigger every time you open your IDE? On the other hand, once the metaprogram has executed, the program that actually executes at runtime isn't something the programmer wants to see. Imagine trying to work with a Rails app that had all the the metaprogramming flattened out of it? Tedious.
What's unique about Smalltalk is that it has both executable class definitions and an IDE. It works because the IDE only lets the programmer work with the runtime representation of the program, and not the on-disk representation. The whole ecosystem - language, libraries and tools - are designed around that paradigm.