On 12/19/10 2:40 PM, Sean wrote: > > >> 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? Groovy is java to the extent that it runs under the same jvm and has access to compiled code in standard jars. But it can be run without compiling and is more dynamic and less verbose. See http://groovy.codehaus.org/ - their description is that it is the language java would be if it had been invented in this century. It adds a runtime method dispatcher so there's a bit of overhead to straight java. There's also a companion 'grails' which is the equivalent of rails for ruby (web site mostly by convention) but again, running under a stable jvm. > 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? And that you get some massive libraries - spring/hibernate,lucene, etc. plus jdbc drivers for about every DB known to man. And there are IDEs like eclipse that do a lot of the grunge work boilerplate for you, and maven to manage components as you scale up. I do agree personally - I can't think in java and do much better when you can squeeze the logic of a routine onto one page where you can see it all at once. > 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? I'd relate the importance of code size to the amount of RAM you can afford. For a long time now it has been cheaper to buy RAM than to hire someone capable of shrinking your code base - unless maybe you have a mass-market application that will run on millions of boxes. >>> 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. You can always do input into temporary tables structured more like the input data and process to normalized form later (if needed). > 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!). Sqlite should be equally usable - and easier to convert to/from server backends. That might not have been true long ago, though. >> 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! You should have asked sooner. I still have a few centos3 boxes going strong. I had problems with perl modules and a few other things in the early stages of centos4 and skipped over that for most systems. -- Les Mikesell lesmikesell at gmail.com -- Les Mikesell lesmikesell at gmail.com