On Wed, 19 Sep 2007 16:46:50 +0100, Pratik wrote: > I release Plugin A. Joe release Plugin B which uses "your" > functionality to depend on my Plugin A. One fine morning I get > enormous motiviation to improve performance of my Plugin. So I take a > day off at work and rewrite the entire damn thing and release it. Poor > Joe has no clue what I did. So every person installing his Plugin B, > will have broken functionality because noone has a goddman idea about > what I did with Plugin A last night.
I see what you're saying, and I don't disagree. There's always going to be a tension between reuse and incompatibility; it's been true with UNIX shared libraries, it's true for Windows "DLL hell", I imagine it's true for managed .NET and Java applications, and it will be true in Ruby and Rails. It's why we freeze gems and Rails into our apps, and it's why 3rdRail comes with not only its own copy of Eclipse but its own copy of Java. And that's the problem with the nothing-shared rule - just how much of your dependencies do you include? What stable, sane environment can you count on? Should plugins include Ruby? After all, 1.8.5 to 1.8.6 broke quite a few things. But packaging everything can destabilize you too, because you won't pick up bug fixes to the core libraries. On Windows, nearly everything includes its own "gdiplus" DLL. Well, when Microsoft found a security hole in gdiplus, the world went crazy trying to release new versions of everything with an updated gdiplus. I'm pretty sure there's something somewhere on my hard drive that's vulnerable. These aren't new problems, and we'll do well to learn from past mistakes and experiments as we carve out solutions. > If I were you, I'd refrain from personal attacks. I didn't intend my post to be a personal attack, and I'm sorry that it made you feel attacked. I didn't make any statements about your person; it's your position that I questioned. Perhaps it was a bit hyperbolic to suggest we all invent our linked-list libraries, but in fact 15 years ago that's exactly where we were. It took ages (and IIRC several core language improvements!) for the C++ STL to become adopted and truly standardized, because reuse, versioning and efficency (developer AND system) are huge hairy issues. I'm sure the same happened before that with stdlib, and after that with Java, and it's happening here now. Java was born in an age where complex programs solved complex problems, and the idea of perfect portability and modular object reuse was going to save us all. It didn't. Rails comes at the problem a different way, and perhaps as a result, Rails developers have a strong cultural bias against reuse. Maybe it's because it's often as easy to write something from scratch as it is to reuse it. Maybe it's because we're learning and reinventing so quickly that any rewrite is going to be a huge improvement. Maybe it's a rebellion against the idea of "one true way" to do something. Maybe it's because we haven't started building complex Rails apps yet; maybe it's because we *shouldn't* build any. Or maybe it's because we just haven't hit the pain point, but we're about to. What I find really fascinating is that Perl, which comes from a very similar TIMTOWTDI perspective, has begat CPAN, which (from what I can tell) very often has One Good Library for a given function. I would love to understand more about how that evolved, and see what we can borrow. Sorry for the novel. Executive summary: These aren't new problems. Let's learn from at old solutions. -- Jay Levitt | Boston, MA | My character doesn't like it when they Faster: jay at jay dot fm | cry or shout or hit. http://www.jay.fm | - Kristoffer --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
