From: "M. Edward (Ed) Borasky" Date: 2006-08-27T01:05:23+09:00 Subject: Re: Why Ruby does not nead an ide Chad Perrin wrote: > On Sat, Aug 26, 2006 at 07:40:20PM +0900, Huw Collingbourne wrote: >> 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. The same is true for Forth -- tersely expressed, an IDE built in from the ground up to support the language. Forth and Smalltalk have a few other things in common: 1. They were both subjects of a Byte magazine single issue devoted to the language in the "golden age" of personal computing. 2. They both still survive today in their niches, but aren't generally used as "general purpose" languages. 3. I suspect, though I don't know for sure, that a non-GUI Smalltalk core would be as compact and efficient as Forth's core is. I'm not sure about the converse, though -- I've got a full-blown Forth, Inc. SwiftForth package that totals well under 100 megabytes including the GUI IDE and two decent-sized PDF manuals. And I'm pretty sure most Smalltalk virtual machines don't include an assembler. :) >> >> 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 coding style -- small chunk coding, building a large program up from small chunks of core operations -- can be done in almost any language. It's the way most Forth programmers code, and probably most Lisp and Scheme programmers too. There's no reason you can't do this in any language, with or without an IDE. > 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. Where I think an IDE is absolutely crucial is two places: 1. Dealing with large quantities of other peoples' code, and 2. For building a *multi-language* project. I'm working on a project right now that uses five languages: GiNaC, C++, Ruby, Python and SWIG. I need an IDE to help me with five different syntax/semantics arrangements. I'm not even sure there *is* such a beast, but I suspect KDevelop is close. >> 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. I don't know percentages, but I tend to code the small-chunk way in most languages. I think the coding style you talk about here is one that comes from the "scripting" paradigm that Perl and to some extent Ruby came from. A typical "request" made of a scripting programmer is to convert a few million lines of arbitrary text into a CSV file and stuff that file into a database. And a typical project deadline is last Wednesday. Objects? Factor? Subroutines? An IDE? For ten lines of Perl code? Besides, when you get *that* script done, I've got five more that need to be done two months ago. :) >> 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. I tried to learn the Squeak IDE and got terribly frustrated quickly. It was so radically different from all the paradigms I was familiar with -- the mouse bindings alone were confusing beyond belief. Sure, I could drag windows around on the desktop and click buttons and tabs, but that was about it. I'm sure a Squeak programmer would have similar problems with SwiftForth. :) But to tie all of this back to Ruby and IDEs, it isn't so much that *Ruby* does or does not need an IDE as that some *projects* need an IDE. And I see absolutely nothing wrong with *requiring* all the programmers on that project to use the *same* IDE! So, my ideal IDE would support *all* languages -- even Scheme, Lisp, Smalltalk, Forth and APL. It would allow direct viewing and manipulation of the abstract syntax graph of the programs in a project, allowing the programmer to focus on what the program *does* and how that corresponds with what it is required to do. And it would allow one to build and debug programs in parallel, concurrent, non-deterministic and mobile paradigms as easily as in the standard serial paradigm. And of course it would be free as in freedom and free as in beer and end poverty and global warming too. :) >