On 2/12/2013 9:36 AM, Christopher Schultz wrote:
On 2/11/13 4:30 PM, Terence M. Bandoian wrote:
I understand the considerations above and they are a part of the
prevailing thinking. However, one underlying assumption of the
supporting argument appears to be that today's programmers are not
capable of developing maintainable code which I don't believe is
true. As I understand it, programmer productivity is one of the
most significant factors in the decision making process and it is a
valid concern. IF (that's a big if) an application can be developed
in half the time using a generalized solution, then that approach
has to be considered along with a host of other concerns including
the end product and the effect on the organization. I say reliance
on generalized solutions is short-sighted because knowledge of the
underlying technologies is lost, or never gained, along with the
skills to work in those spheres.
Are you suggesting that people who program using Java are oblivious to
the innards of hardware architecture and are remain ignorant of these
important details? That's the logical conclusion to your argument.
I'm not saying you're wrong, but you have to admit that a Java
programmer (of which I'm one) saying that using a generalized solution
makes you ignorant is a bit like the pot calling the kettle black.
Not at all. 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. I'll give them
the benefit of the doubt and assume they have other motivations but
still, is escaping the input strings to a query really advanced
knowledge? Think about that from the perspective of a junior or
mid-level programmer who has only ever used an ORM. What happens when
something goes wrong or performance has to be optimized. For that
matter, what does happen? Now you have to know SQL, the DBMS, and HQL
and understand Hibernate behavior. Double the complexity?
Disclaimer: I don't have anything against Hibernate or JPA. I worked
with an early implementation of JDO for a short time and am beginning
some work with Hibernate.
- 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? What about those
programmers who have only ever used a JavaScript library? Another
developer says he tells clients that they shouldn't consider a feature
if it isn't supported by jQuery. 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.
Disclaimer: I think jQuery is a wonderful library and, if you plan to
make good use of the features available, it should definitely be considered.
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.
Efficiency, flexibility, repairability, extensibility and
reliability are all components of software quality and all are
affected by complexity. Less complex systems are easier to
maintain.
To continue the aside, wasted energy is wasted energy and it may
become a factor in software development at some point. I think
decision makers should be taught that there is more to the bottom
line than dollars and cents.
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.
-Terence
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
