On Tue, October 23, 2007 12:12 pm, James G. Sack (jim) wrote: > Christian Seberino wrote: >> Stewart Stremler wrote: >> >>> The second-system effect does not result in an improvement over the >>> original. >> >> But Subversion is the exception to your rule. Perhaps they threw out a >> couple of designs on the way to the final product thereby moving beyond >> the 'second-system'. >> > > I would argue that > Second System implies Second System Syndrome > however common, is *not* a universal truth > > I suppose It Depends (tm) on how you define second system. _I_ assume SS > means a reimplemention with significant design differences in some part > of the [infra]structure which is intended to roughly satisfy the same > requirements (specs) of the original. > > Mealy-mouthed disclaimer: for _some_ definitions of 'significant' , > '[infa]structure' and 'roughly' <heh>. > > There presumably are additional goals as well, otherwise why change? >
Lots of reasons. Like the way drug companies invent new, less effective antidepressants and antibiotics just to have something to patent. But to me, 2nd system just points out that the designers have a tested design to emulate or improve on. It doesn't mean they'll be successful. This is true in commercial SW as well. Tichy invented rcs and changed the world. And today (to pick a commercial example), p4 still uses the rcs file structure to store the code deltas, although all metadata in p4 is in a Berkeley DB back end IIRC. > I would argue that SVN is a success in achieving its goals of replacing > CVS with equivalent functionality plus reduced constraints/problems and > some extra capabilities (if that's a reasonable way of paraphrasing its > goals). > Well, in the case of svn, they stated their design goals in a manefesto, which (from flawed memory) was something like a "compelling drop-in replacement for cvs with as few operational changes as possible." So their limitations (just like cvs only better) were built in. > Please note that I haven't said I think SVN is the greatest thing since > <preferred-hackneyed-term, default="sliced bread">. > > Some excuse for writing this, is to make the following observation: > >>From the stimulating (and entertaining) talk given by Damien Conway at > the last LPSG-transplanted-to-PerlMongers meeting, I would say that > perl-6 [1] is promising to be a pretty good SS. > > > [1] aka perl-6-oh-no! > > And I thought perl 6 was the poster child for NOT breaking the mold. But my current use of perl, much as I have loved it, is in supporting other people's scripts at work. Tcl/Tk which I know much more about (albeit not everything) has done a temendous amount of internal evolution while striving to always be true to the original spirit of the language. For example, internal data representation is now a "lazy" binary/string structure greatly improving performance but remaining true to the original "everything's a string" paradigm. Similarly, the core development team is presently working on internal OOP primitives to make OOP capabilities a matter of design rather than extensions (like I could care, being OOP tone deaf -- but I won't _have_ to use them). So in Tcl, the insides get better and the outside stays true. But svn is definitely a 2nd program because it took cvs's approach (for better or worse) and rewrote it in true C/S with a data base back end. And both of these needed to be done. What I don't like about svn is that they fell in love with their lazy copy facility (it is way-cool for copies) and now use it for branches and version labels, neither of which it really is. But just like the cvs team before them, they reject this criticism, seem to take it personally, and refuse to entertain thoughts of adding these features. And, no, I'm not gonna grab the source and do it for them. I've always thought that reply to people with valid criticisms was pretty snarky: "if you don't like the cars Detroit is making, dismantle a few and use the parts to make your own, whiner." Not very realistic for most of us. We vote with our feet. -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
