From: Francis Cianfrocca Date: 2006-05-03T15:40:40+09:00 Subject: Re: Sharp knives and glue ------=_Part_8611_10597534.1146638435566 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I broadly agree with most of this, inlcuding your rants on stability. But are we missing something more fundamental? I came to Ruby three years ago from many years of C++, C and assembler, including large commercial systems. As far as Java is concerned, it's obviously been validated by the marketplace and your experience (among others) proves its value for critical systems. But I've never been convince= d by Java and have generally avoided it for my own development teams. Java incrementally improves on C/C++ in many ways. But fundamentally, it ha= s a very dangerous tendency to encourage sloppy thinking among less-experienced programmers, because the language takes care of so many things for you. Well, that comment can be read two ways, can't it? You have to be a lot more careful with a straight razor than with a Norelco, but having deep experience with dangerous and powerful shaving systems isn't necessarily all that valuable from a business point of view. In other words= , the Norelco represents progress precisely because it lets you be somewhat sloppy, without getting a bloody mess. Now with Ruby the perception is that we're going back to the straight razor= . You're arguing for tools and mechanisms to scale to enterprise-sized projects. I spent most of the last three years writing Ruby programs that looked very much like incrementally-improved C++ programs. It took me a lon= g time to grok duck-typing, but when the penny finally dropped it really changed everything. People coming to Ruby without the baggage of many years of commercial C/C++/Java experience don't seem to have this problem, nor do they have the mental blocks against metaprogramming that people like me have. (I learned to avoid self-modifying code way back in the assembler days.) My point is that if we try to make Ruby fit into established large-team methodologies, we may be throwing away what makes Ruby special in the first place. And we'll end up with an incrementally-better Java. And in a corporate environment, there are always more reasons not to rock the boat than to do so. Which means that if we accept that model, Ruby will simply not succeed in the enterprise. What I believe is happening, but has yet to fully emerge into visibility, i= s that Ruby is successfully extending the same kind of partitioned developmen= t model that has worked so well in the open-source world generally. If you accept that Ruby may be revolutionary rather than evolutionary, then ask yourself why that may be so. To me the value of metaprogramming and duck-typing are that they permit a tremendously powerful way to re-imagine the mapping of elements from real-world problem domains to elements of computer programs. They help us model the world better. And yes, that can mean changing the behavior of already-established and stable objects. But t= o many, that is exactly the problem! What are "large systems," really, and why is Java perhaps the better tool for them? Well, one model is to think of a large system as a relatively large collection of fine-grained, domain-specific elements. Problems arise both because of the size of the set (and the number of interactions) and th= e fact that they are domain-specific, which means they only matter to a small number of organizations, perhaps no more than one. So in turn, they don't benefit from the evaluation of a broad community. Well, if you think of a large system that way, you are really facing an essentially insurmountable design challenge. There are too many moving parts. So people respond with ideas like "Design by Contract," which seek to automate and "freeze" the interactions among various system components. Well, the rigor which with this is done may actually be part of the reason that large systems get larg= e in the first place! You end up adding more components because you have no ability to modify the existing ones in a context that won't arbitrarily break their existing contracts. There may in fact be a tipping point at which system size starts to conflict directly with constructability. But we know from real-world experience that this is not true in other engineering disciplines, so the question becomes: is there a different way to do this? And Ruby may be part of the answer. If I sound like an advocate for enterprise SOAs, well I am. But I have a long background in large distributed systems, and what I see with SOA today is first-generation thinking, focused primarily on transport protocols rather than on finding a more organic way for large ordered systems to spontaneously emerge, which is what should be happening. And the way we think about traditional large-systems development may be the stumbling block. I've been thinking a lot about building a distributed object framework in Ruby. Two of biggest (and least-appreciated) technical reasons why this hasn't worked in the past are the "fragile superclass" problem and the "destruction at a distance" problem. Ruby potentially relaxes both of these problems. I think the "aspect-oriented" stuff that Java people love so much really doesn't work in any other context, because it tries to established horizontal levels across large chunks of code that have direct textual visibility to all the other chunks. It's just not natural to the way Ruby should work at large scales. Anyway I don't have the answers (yet) and there is a long way to go. But I don't think Ruby should be "improved" to fit traditional large-system methodology. I think the reverse (somehow) is closer to true. ------=_Part_8611_10597534.1146638435566--