Isn't that what Smalltalk does? It combines the language and the IDE in
one convenient package.
Most, but maybe not all, Smalltalk implementations combine the
language, the run-time and the development environment. In typical
Smalltalk implementation:
* The compiler is written in Smalltalk, methods are compiled to
objects (usually instances of a class called something like
CompiledMethod which contains a reference to the compiled byte codes,
and information about the bindings of references to local variables
and the like.
* The tools run in the same execution environment as the application.
The information needed by the compiler and other development tools is
kept by Smalltalk objects which model the code (Classes, Metaclasses,
Behavior, CompiledMethods). The IDE can do things like get a list of
all implementors of a particular method selector, or all the methods
which invoke that selector by querying the run-time environment. The
source code is located through these objects as well. One of the
things which newbies to Smalltalk find strange is that there are no
explicitly edited source files. In the original Smalltalk-80
implementation, source code was kept in a changes-log file and methods
had a pointer into that file so that they could find their source.
Often this is supplanted by a shared source database which provides
SVN like function. EnvyDeveloper which worked with a variety of
Smalltalk implementations including (Smalltalk/V, VisualWorks (later
merged), and IBM Smalltalk) was the most popular implementation of
this.
* Another thing which some find strange is that the run-time state is
persistent and is saved as an image. You can terminate Smalltalk,
restart it and you're right back where you were, complete with any
existing instances of objects, suspended threads (Smalltalk calls them
Processes) etc.
* The reflection capabilities in Smalltalk are more powerful than in
Ruby, this enables quite a few of the tools. Smalltalk programs can
reflect not only on the class definitions and other semi-static
properties, but can also reflect on and manipulate the run-time
execution state. As an example of the difference, in Ruby, although
one can access a representation of the current process stack frame
using Kernel#caller, this representation is textual and only really
describes which methods are on the stack. In Smalltalk the process
stack can be examined in detail, and manipulated (usually by the
debugger, which like all of the other Smalltalk development tools is
written in Smalltalk). In the Smalltalk debugger you can do things
like change the values variables, or even change the source of a
method and recompile it, then resume execution from the point of
change. For efficiency the VM only reifies stack information as
objects when it is needed, but the key is that a rich set of
information about the run-time is available as objects.
This approach has it's plusses and minuses, but for many it's the
sine-qua-non of what constitutes an INTEGRATED Development
Environment.
