Frameworks - used properly - can be INCREDIBLY helpful. Why develop my own routing code when there's already a robust, well-tested version available? Or validation code? Or payment authorization code? Though it needs to be said that the number one thing a good framework does is GET OUT OF YOUR WAY. I've seen some Java frameworks that take an hour to put together a simple Hello World and that's just nonsense. Currentl…
Unfortunately, JSR-168 compliant portlets are perhaps the crowning example of horrible implementations of an insane standard.
This also makes unit testing extremely diffcult since you have the joy of creating mock objects for your Context, ConnectionFactory and Connection. I have all but given up writing test code at work. The various j2ee frameworks I have to use make it almost impossible.
Drop Classic J2EE and learn Spring. It will make things sooo much easier and manageable.
Spring is definitely an improvement, however we had a serious problem getting it up and running in our environment (it was a while ago so I can't remember what it was exactly) and had to give up on it.
It really does not help that all of our web projects are struts 1 and we have still have a fair amount of torque projects hanging around.
If Rails were a toolbox, all of its tools would break under duress. Regarding Ruby: "And furthermore, for me, programming languages and their runtimes are tools. I think they are for a lot of us. You wouldn’t continue to use a hammer whose head keeps flying off when you take a swift backswing, would you?" Good read: http://cbcg.net/2007/04/22/python-up-ruby-down-if-that-runti...
He also goes on to say: I am discounting Rails here: I think Rails is great for what it is and I’ve had nothing but good experiences with it precisely because it is so “opinionated”. Its a very productive environment and manages to successfully avoid the runtime problems that I’ve personally hit in the past. So... are you trying to make a point about Ruby or about Rails? Dare I give out the clichéd "Rails != Ruby" re…
No, that mistake typically is a result of somebody faulting Ruby for Rails' problems. As the parent to my comment said,
Rails: Here's a kick-ass hammer, a kick-ass saw, a kick-ass measure tape, etc...
My point is that those kick-ass tools may be made of balsa. The editorial that I linked immediately came to mind because it too used tools as an analogy.
Exactly. This is why the article is such a bad analogy - frameworks makes things simpler by handling things you'd already do without them. If you're making a spice rack: Without framework: DIY shed filled with tools Framework: IKEA
I think the issue is, a spice rack from IKEA may work, but it's not going to look great, or last long. Any flat pack spice rack, will be shoddy quality, and probably break. You don't get good furniture by mass producing it like that. Same with software. What if I want a custom spice rack, with some secret compartment, in solid oak.
The idea that using well tested, widely spread open source software is somehow less reliable than writing your own is the kind of baseless FUD I wouldn't expect from you, axod.
Next, you'll be suggesting that people write their own web server instead of using Apache? Or perhaps they can trust other people's code so long as they pay for it, so you'll send them towards IIS?
He also goes on to say: I am discounting Rails here: I think Rails is great for what it is and I’ve had nothing but good experiences with it precisely because it is so “opinionated”. Its a very productive environment and manages to successfully avoid the runtime problems that I’ve personally hit in the past. So... are you trying to make a point about Ruby or about Rails? Dare I give out the clichéd "Rails != Ruby" re…
No, that mistake typically is a result of somebody faulting Ruby for Rails' problems. As the parent to my comment said, Rails: Here's a kick-ass hammer, a kick-ass saw, a kick-ass measure tape, etc... My point is that those kick-ass tools may be made of balsa. The editorial that I linked immediately came to mind because it too used tools as an analogy.
Struck a nerve, huh? This was partially in jest (notice the lol), and I realize this is sometimes hard to convey in writing. Sorry. But there's also a lot of truth in it, too. No one is born a mediocre programmer. It's a choice. Notice I didn't say a "junior" programmer. There's a difference. A junior programmer has less experience, but has a good attitude, is willing to learn, and practice his or her craft to get be…
"Struck a nerve, huh?" Yes. I am not a great programmer. I only started caring about it a couple of years ago and since I don't have a real education in it I am very behind in many areas. I am trying to get better, but it's not easy. "No one is born a mediocre programmer. It's a choice." I don't know if I agree with this. Some people are born with incredible talent in various areas. Some people are just born musician…
As my boss used to say, "the best people I've worked with have all been self taught." I've found this to be true myself. A college degree (especially (?) in CS) is not the cause of, nor (in my experience) even correlated with, great programming. I think even being aware of and caring about the issues that have been mentioned makes one above average, even if you don't (yet) have the experience to solve it all.
No, that mistake typically is a result of somebody faulting Ruby for Rails' problems. As the parent to my comment said, Rails: Here's a kick-ass hammer, a kick-ass saw, a kick-ass measure tape, etc... My point is that those kick-ass tools may be made of balsa. The editorial that I linked immediately came to mind because it too used tools as an analogy.
Here's the dirty little secret that no one wants to talk about... The purpose of "assisters" like frameworks and higher level languages is NOT to make good progammers more efficient. It's to make mediocre programmers more likely to produce something of value and to make poor programmers capable of producing anything at all. And if the bell curve tells us anything at all, it's that these "tools" target 90% of all prog…
I agree completely. Web frameworks add a layer of code bureaucracy that really doesn't need to be there in most cases. Reading and setting browser cookies is not that hard. Creating and reading web forms and validating inputs is not hard. Creating a relational database schema and objects that store themselves in that schema is not hard. You can do all of this directly in mod_python, essentialy by buildng your own fra…
My biggest problem with frameworks is that, although they save you a lot of time upfront, you need to spend a lot of energy learning concepts that may not be necessary for your application. So, the time you save coding is partly spent in learning things you may or may not need.
If you do everything by yourself initially, at least you will know when it makes sense to use the framework. This is my approach with web development: Try to do whatever I need without the help of a framework. Then, I will know where a framework can help or not, and use it the next time I need a specific functionality.
"essentially by building your own framework" Why build your own framework when there's one already there? Already well-used, well-tested, well-extended? Sure it may be easy enough to do, but is it really worth it? I, for one, would much prefer to be spending my coding time writing application logic than Yet Another Validation Library.
Because frameworks aren't optimized to your use case.
Hell, programming languages (typically) aren't optimized to your use case. You modify them to make them so.
Good frameworks are the same way. I've already extended the hell out of Kohana to make it more useful to me. This is work I would have had to have done if I weren't using it, sure, but all the basic stuff is there all the same.