[ruby-talk:23101] Re: Bruce Eckel's opinion of Ruby

On Tuesday 23 October 2001 14:11, you wrote:
> On Tuesday 23 October 2001 22:43, you wrote:
> > While nice in its context, this does not work for many paradigms. For
> > (hypothetical) example, I have a class which maintains some state
> > information in a database. When an instance is destroyed, I want the
> > corresponding state deleted out of the database. But I don't know
> > beforehand when an instance is going to be destroyed, because I am one
> > programmer on a team of 50 programmers working on this product. It is
> > clear that a destructor is the most useful way of handling this
> > situation.
>
> No offence but I think that a good design up front would be the most useful
> way of handling this situation.

And you work in which mythical shop that does everything "right"? :-)

(Just thinking of one project I've worked on... I asked for the MRD so I 
could do a functional spec, my manager said "I'll get you one but here's what 
we want", so I prototyped a design, said "Will this work?", "Yes... no, the 
customer says that's not what he wants..." I repeat request for MRD, manager 
says "I'll get you one but here's what we want" .... sigh). 

In the big project that I did in Python, we overlapped design and 
implementation phases to great extent. The first thing I did was draw the 
architecture on the whiteboard along with data flows within that 
architecture, and listed the basic criteria and functionality of the program 
(the latter was a massive document that I spent a week of meetings and a week 
of writing to put together). Then we assigned boxes of that architecture to 
various people, but the innards of chunks were not designed in detail by the 
project architect and the team leads. Rather, those designs were assigned to 
the people who "owned" various modules, who were required to document them 
prior to implementing them (and yes this was enforced :-). People had wide 
lattitude in how they designed and implemented their particular chunk, as 
long as they got together with the people at the interfaces to properly 
document the data being passed and make sure that it met the requirements of 
all consumers. We managed to write a fairly large-scale enterprise-class 
program in under six months with a manpower budget that was hilariously 
undersized for the task we'd been assigned, and I don't know if we could have 
done it in Ruby. It was doable -- barely -- in Python. I know we couldn't 
have done it in C++, we'd still be tracking down memory leaks today :-). 

Point: The "right" way is any way that gets things done in a reasonable way 
in the least amount of time. Having destructors makes this easier in many 
cases. A "good design up front" is one of those things that in my opinion is 
utterly impossible -- designs are created via a process of successive 
refinement (i.e., top-down), and there's no way up front that you can know 
everything that's going to be necessary at the very bottom of the design 
heirarchy. The most you can do is set up a good strong architecture up front 
where the pieces can be isolated so that each individual piece can be 
individually designed and etc., because no plan of battle survives contact 
with the enemy^h^h^h^h^hactual customer. You can request MRD's and spew out 
functional specs until you're blue in the face and this will still remain 
true, though of course I do *NOT* recommend going into any project without 
MRD's and functional specs! (For one thing, when marketing wants "one more 
feature", it makes it that much easier to tell them "No, we've done 
everything on our MRD and functional spec, put it on the wish list for 
version 1.1"). 

In my opinion, this is why Unix is still with us 30 years later -- its 
componetized design allowed it to move forward into different market niches 
as the world changed, even though Unix was never really formally "designed". 
All projects are organic in the end, and must be designed as such. Requiring 
high-end consumers to know anything about low-level design of individual 
modules is hardly something that will enhance future maintainability and 
added functionality for the program. 

-- 
Eric Lee Green          GnuPG public key at http://badtux.org/eric/eric.gpg
           mailto:[e-mail]  Web: http://www.badtux.org
             You do not save freedom by destroying freedom