On Sat, Aug 26, 2006 at 07:40:20PM +0900, Huw Collingbourne wrote:
> 
> OK, let me say up front that (for, perhaps, obvious reasons) I have very 
> strong views on IDEs. ;-)

You don't say . . . !


> 
> If you want to find a tersely expressed language, you need look no further 
> than Smalltalk. Then look at the Smalltalk IDE. This is built from the 
> ground up to support the language - editing, browsing, debugging, 
> evaulating, inspecting, navigating the code. The Smalltalk language is an 
> intrinsic part of its IDE.
> 
> Now look at the way that Smalltalk code is structured. Typically it has lots 
> of classes with many 'levels' of descent. Each class has many methods that 
> rely upon ancestor classes. The code in any one method is often just 1 or 2 
> lines long. A really long method may be 10 lines or so long.

This is, as you hint below, pretty damned difficult to navigate and work
with outside of an IDE.  Unfortunately, it also tends to require that
everyone use the same IDE for everything to work out nicely.  This is
fine when working in a closed shop that standardizes on specific
toolsets as well as specific languages, but is less than perfectly
optimal for highly distributed open source software development projects
and the like.


> 
> Now look at Ruby code. In my experience, most Ruby coders write big classes 
> with very few ancestors. Moreover, Ruby methods are typically (by comparsion 
> with Smalltalk) huge. In my view, this style of coding is relatively verbose 
> and takes little advantage of the real benefits of OOP.
> 
> So why do people code Ruby (typically) in a more verbose manner than 
> Smalltalk? In my view, this has nothing do do with the language itself and 
> everything to do with the environment. Lacking a really good IDE, Ruby makes 
> it hard to navigate the class hierarchy, to find the methods of ancestors 
> and derive new methods from them. So people do a lot of unnecessary 
> recoding. If Ruby had a Smalltalk-like IDE, I am sure that people would 
> rapidly start coding in a much terser style taking greater advantage of the 
> ancestor/descendent relationship of classes.

Frankly, it's more the "framework" aspect of environments like Squeak
that provides this than the IDE aspect (though both characteristics do
play a part).  I don't mean that a framework in the Rails idiom is
necessarily appropriate to general-purpose programming or necessary for
allowing such fine-grained decoupling and code segregation.  I mean that
a set of pre-existing code generation defaults that is well designed and
relatively comprehensive within the realm of the sort of work you're
doing is what's needed to provide that sort of convenience.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
print substr("Just another Perl hacker", 0, -2);