Rick DeNatale wrote:
> On 4/14/07, Chad Perrin <perrin / apotheon.com> wrote:
>> On Sun, Apr 15, 2007 at 01:27:28AM +0900, M. Edward (Ed) Borasky wrote:
> 
>> > But what I'd *really* like is a language and an implementation of that
>> > language that *was* an IDE! The closest thing to that I've ever seen is
>> > the intricate entwining of Lisp and Emacs, and that, in a kind of
>> > linear, one-dimensional, "auditory" way, is the core concept. But 
>> expand
>> > that -- data structures other than the linked list, two-dimensional and
>> > three-dimensional diagrams, color, stereo sound, animation. And, of
>> > course, it needs to be open source. :)
>>
>> 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.
> 

A lot of this sounds like what Business Basic has been doing for over 20 
years.  Along with being able to modify code and variables while running 
a program you can also tell the program to go back to an earlier 
statement before continuing, this makes it very easy to debug a program 
and make sure that any changes you make work.
Another thing that I really like about Business Basic is that it has 
screen handling for normal 80 character by 24 character displays built 
in so that you don't have to work with a third-party add-in like curses. 
  It also has integrated flat file handling built in, again obviating 
the need for add-ins like C-Tree.


> This approach has it's plusses and minuses, but for many it's the
> sine-qua-non of what constitutes an INTEGRATED Development
> Environment.