"Rick DeNatale" <rick.denatale / gmail.com> writes:

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

I've never done smalltalk, but a lot of what you have written reminds me of
some of the lisp environments I've used. 

One of the things I grew to love in lisp and have often missed in other
languages is conditional restarts and error trapping. It is one of the few
languages I've used that really gives you the ability to step back, make
changes and recover rather than simply 'trap and report'.

Getting back to Ruby, I have to say, the more I use this language the more I
like it. I got into a bit of perl's OO some years back, which at the time, I
liked in preference to using Java. However, I really do think ruby has gotten
the whole OO stuff nailed, particularly from the perspective of a scripting
language. Despite my contributions to threads on IDEs etc, I have to say that
using ruby and emacs is for me a nice environment. I can see potential for an
even more powerful integrated emacs+ruby environment and once I get a better
appreciation of the language, may even try and see about using my emacs
knowledge/experience to contribute to the ruby mode for emacs. 

Tim

-- 
tcross (at) rapttech dot com dot au