Les Mikesell wrote: > <div class="moz-text-flowed" style="font-family: -moz-fixed">On > 12/18/10 3:24 PM, Sean wrote: >> >>> >>> Or, you might move to java for a more self-contained, OS/distribution >>> independent way of doing things. >>> >> Why Perl? Because writing/maintaining 20,000 lines of terse Perl code is >> manageable, whereas the equivalent 200,000+ in Java ruled itself out at >> the very beginning, (even at a time when I knew some Java but no Perl). >> A practical decision I clap myself on the back for every single day >> despite knowing that had I gone with Java (and this project fallen over >> long ago) I could now be getting big quids from some corporate developer >> who needs a team of new Java graduates overseen.....(hmmmmm or was it >> the right decision?)..... > > Starting from scratch now or recently, it would be hard to argue > maintainability for perl vs. java, but back in java 1.4 days or > before, it was probably the right choice. But java sort of isolates > you from changes in the rest of the platform. And groovy eliminates > most of the unnecessary verbosity if you don't mind a bit of a > performance hit. > Groovy is new one on me -- what is it? And surely the driver behind widespread Java adoption is still that others maintain your code more easily (ie the corporate/factory model), implying a price still to pay for a developer who just needs to maintain own code suite? Besides being anathema to me, strong data typing, for example, is also just one feature that explodes code size, but fits perfectly with the factory model. In 5+ years of intense coding with non-typed R/Basic I recall a total of maybe 3 compile-crashes from trying to do math on a string (seriously a non-issue for the die hard maverick!) Is code size under-rated?, conveniently swept under the carpet? >> Core Perl stability? I agree. >> >> Why BerkeleyDB? I dont know of an embedded-db equivalent that will store >> 'any and every data exactly as is'. > > I'd think sqlite first - these days anyway. BerkelyDB had bugs in > growing existing items way to long for me to ever trust it again. Or > use a server instead of embedding anything. Either postgresql or > mysql are fairly trouble-free although they've had their own > version-specific issues. Or if you need scale, look at something > like riak. I do use postgresql for data that is person-entered, ie where interactivity facilitates personal on-the-spot correction of rejected inputs. The inbuilt constraints of the server db-model clearly targets multi-person updaters who may or may not be focussing on what they are doing. Great for keeping mega stores of artificially structured (simple) stuff like phone lists, not so good at accepting all the vagaries the real world may throw at it in automated background capture scenarios, sometimes from suspect sources. BerkeleyDB may break occasionally, but is recoverable with basic OS tools and text-editor if provided recovery tools fail (not locked in a proprietary binary closet -- been there, done that, still hurting!). > >> Originally on RH8 for 3/4 years, the first attempt to port onto a brand >> new release of FC4 broke everywhere. The second attempt a year or so >> later went better and remains. In the meantime FC support philosophy has >> tightened/altered to the point where I simply must abandon it. I believe >> it has become just an 'alpha test ground' for RHEL. Reminds me of the >> painful Dos saga -- the first version to work properly (Dos-6) was just >> about irrelevant when finally released. So yes, CentOS has come into my >> sights ... (and I'm a bit long in the tooth to tiptoe around as you may >> have gathered!). > > If you had moved to Centos3 as the first step, you could have run that > with nothing more drastic than a periodic 'yum update' for years, then > jumped to Centos5 with no rush to change again even now. Ah, now you tell me! Sean