-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Terrence,
On 2/14/13 1:23 AM, Terence M. Bandoian wrote: > I probably should have said there is a "potential for lost > knowledge". Here are a couple of anecdotal examples that I hope > will help illustrate what I mean. > > - I was told recently by a person in a software architect position > that they use Hibernate because it prevents SQL injection. :) So, it doesn't support custom WHERE clauses? Sounds like a deal-breaker for me. If it does support custom WHERE clauses, then it's open to SQL Injection because programmers can still suck. > - A JavaScript programmer told me not too long ago that you really > have to use a JavaScript library (e.g. jQuery) if you're going to > use AJAX in an interface because it's just too complicated. Is > instantiating and using an XMLHttpRequest object really that > difficult? No, but if you've ever done your own AJAX work (and not just something silly like sending a ping to the server or trading a 2-line XML document), you'll know that using a support library makes your life soooo much easier, especially when you have to support multiple browsers/versions/etc. Good news is that you can mix-and-match: if jQuery (et al) doesn't support some feature, you can write it yourself and (probably) not interfere. > Still another says that one of the reasons their organization uses > a full-blown framework is that their programmers can't develop > cross-browser compatible JavaScript. It *is* very difficult: when you can leverage the work others are doing, I think everybody wins. Let the jQuery folks figure out how to make XML parsing and call-backs work on both MSIE 6 and NCSA Mosaic: NMFP. ;) > What I'm saying is there should be a good reason (really good) to > add significant complexity, performance overhead, memory > requirements and megabytes of code to an application. Leverage is a powerful thing. >> In my experience, by far the biggest time waster is trying to >> deal with code that is (or has become) unmaintainable. Re-writing >> just because a piece of code has become out-of-touch with current >> standards or because nobody understands how it works is entirely >> wasted effort. We have lots of places in our code where we have >> been spending - literally - years recording from bad decisions in >> the past. > > Granted. Reading other people's code is a learned skill and can > be problematic. Isn't that where design and code reviews and > coding standards come into play? Also, apples and oranges. Energy > is precious resource that deserves special consideration. I'm just > blue-skying here and don't have the answers but how much > electricity is wasted by inefficient programming? We may have to > factor that in some day. Future-proofing is not possible, but it is a reasonable goal. All software rots, even if it's great software. Take Java code: anything written before generics were introduced and uses a lot of collections, etc. will now be a PITA to work with. I have code like this: we are updating it as we have to edit it for other reasons (e.g. we aren't going on a S&D mission for non-generic-y code just to "fix" it), but it does represent some technical dept that does need to be paid at some point. Maybe the existing code is so good that it never needs to be edited, so it sits there and rots, and there are more things "wrong" with the code but it works perfectly well. It becomes something that irritates everyone but everyone tolerates because it's "good" code. If you can make some code someone else's problem, I think that's a win. It's very cynical, but having grown-up in the Java world before any "good" libraries were available (other than the standard Java API, which is great by any standard IMO), I've been party to a lot of time and energy spent just doing simple things like trashing some cowboy's home-grown logging API, O-R mapper, and (yes, true story) XML transformation engine. "Not invented here" is a pesky disease and it's really okay to leverage other people's code. There are always exceptions (I've written my own rules engine from scratch when DROOLS, JESS, etc. already existed) but you (not YOU) are a fool if you don't consider using something off-the-shelf -- especially if that shelf contains lots of great OSS and you can help support it. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEdF9UACgkQ9CaO5/Lv0PAQlQCgteFyWEhnbU+qNIXX8CGzmKWp nUYAn2TcezTK6fspfcMV9JiHEA7SRUL6 =MMge -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
