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

Eric Lee Green wrote:

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

I don't. I don't even think I'd want to :) What I was (tersely) pointing
out that the particular example you gave probably needed a 'protocol'
for lifetime management anyway. But I know, not all issues are known up
front, and in such cases tricks like using garbage collection to manage
resources can be a big help. I just don't think it's the right solution
if you know going in that you're going to need it. As much as it is
convenient that things disappear when appropriate, I can imagine the
frustration when you notice that it doesn't disappear because someone,
somewhere is still holding a handle on your resource. Much fun.

> 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 

I'm not saying I'd do it in Ruby either. I tend to agree that for
large projects, or even small projects where people drift in and out,
the flexibility the Ruby (or Perl) syntax allows has negative
benefits.

And yes, I know the short-path-between-thought-and-code-with-Ruby argument.
For larger projects I would want
short-path-between-reading-and-understanding instead. An entirely
different matter.

> have done it in C++, we'd still be tracking down memory leaks today :-). 

Count your blessings you're allowed to use Python. The projected I
drifted into uses VB.

> 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.,

Right, but important data that's going to be passed around a lot has
the right characteristics to have a decent shot to be determined
early. Anyhow, given complex and fuzzy requirements (and you're
right, I haven't seen them any way else) it's a good way to handle the
chaos. Still, as noted above, I don't think it's the right strategy to
start out with. It's an excellent backup plan.

> 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"). 

We understand each other :)

Emile