Hi Emanuel!
first, I want to thank you for contributing feedback here: Javaranch is a friendly community of engineers, and we try to open up our ideas for useful discussion. As one of the moderators here, I help enforce that policy. Now, I want to talk about some of the interesting and valid points you raised.
I was always taught that the best engineers find the right balance/compromise in complex, multidimensional situations.
We must have gone to similar schools: I was taught something similar. To wit, use the simplest thing that works.
Since 'right', 'balance', 'compromise','complex', etc are highly subjective concepts, I was taught to work for an objective goal: meeting all of my requirements, and being able to justify all of the complexity
directly towards my requirements.
Why bother with an inherently slow, half compiled bunch of crap that can't even run directly on the system? Why don't I just write it in assembly?
It seems that you're suggesting that since the use of Java over assembly is justified, then, correspondingly, the use of complicated frameworks over less complicated frameworks are similarly justified. If I'm reading you correctly, this is, in essence, argument by analogy. I'm not convinced that the analogy holds, either generally, or specifically.
In general, the usage of one expenditure does not justify a second expenditure. Just because you choose to have an expensive steak one night doe not mean that
you should do so ever night.
Specifically, in comparing Java to Assembly, I would argue that Java is significantly easier then Assembly: both to learn, and to use. Granted, this
is a subjective judgement, but it's one I would be willing to defend.(in another thread, of course).
if you're writing an application where you need to access multiple databases ... if your transactions span multiple servers (and maybe countries),....if you have a 100+ complicated pages.... and you could really use AOP because your logging, ...and a few other things take up the other 20% of your code.... you will think frameworks are miracles
There are a lot of ifs in that last statement, followed by an assumption that is not based on objective evidence, AFIK: there is no evidence so support the contention that I would be glad about this-or-that, or [for that matter], that I might resent the limitations of the framework.
Of course, some frameworks are better then others, and, of course, it's always possible to contrive a context in which the framework in question is the
only thing that works. As a matter of fact, there are often legitimate context in which a given framework is a perfect fit.
But generally, it seems to me, that simple answers are better then complex answers. A Einstein said:
Everything should be as simple as possible. But no simpler.
There is another point in your article which really enraged me.
I'm sorry to hear that: I certainly didn't mean to upset anyone with my thoughts.
The XYZ you speak of which you claim can do the 90% of the work is still there, untouched, ready and willing to be used. Why, then, do you criticize the ZYX?
As an engineer, I dislike things that do not have a function. If ZYX is not solving a problem, then it's just
fat, in my opinion.
Maybe it took away focus from XYZ, because many people believe that XYZ not really responsible for the 90% but more like 50-60 and because whatever the XYZ does not cover (be it 10% or 50%) is a real pain in the ass...
Except that it's not: remember, I was the one that came up with the analogy
. If you're talking about a case where the ZYX is 50%, then you're not talking about the article I wrote.
And that simple craftsman you speak of must be a simpleton if he acquiesces to using a complex framework where it's not needed....Perhaps he needs to see a psychiatrist.
well, maybe. Actually, I'm
sure of it.
[ March 27, 2006: Message edited by: Max Habibi ]