21–30 of 127 posts
Earlier quoted context omitted.
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
Well, not quite... that's a bad analogy too, actually... Rails isn't IKEA - and most java frameworks are definitely not IKEA. Frameworks are tools, not end products.
On a related note, I saw this on reddit this morning: http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server... What's sad is that I have no idea if this is a joke or not.
EDIT: OK, so instead of Java, that should read "to know if enterprisey Java frameworks are a good fit for their problem." The irony is, that I just was IM'ing a friend about how this isn't the fault of Java the Language, but the "enterprise architecture" community that write Java frameworks like this.
Rails: Here's a kick-ass hammer, a kick-ass saw, a kick-ass measure tape, etc... Oh, and if you need them to be different from the default, you can modify them as you want, but we think the default works for most people.
"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...
Why do I need to have 5 different objects when one would do? Having 5 different objects did absolutely nothing for the client code except make it more complex. (And this actually complicates good coding for the user experience. When we notify the user of network problems, I have to add additional code to see if objects exist in the first place just to prevent exceptions.)
It would've made no difference if there was just one Object. (Except for shorter code.) I could use it to login to a server. I could use it to register interest in a topic then ask for messages on that topic. If I want to connect to a different server, then I could instantiate a second object. Why do I need 5 freaking instances to do the most basic thing possible?
On a related note, I saw this on reddit this morning: http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server... What's sad is that I have no idea if this is a joke or not.
Perfect thing to show people, when they want to know if Java is a good fit for their problem. Even a Pointy Haired Boss, shown this, might understand why Rails or Django or something might be a better way to go than dealing with this. EDIT: OK, so instead of Java, that should read "to know if enterprisey Java frameworks are a good fit for their problem." The irony is, that I just was IM'ing a friend about how this is…
I've seen good frameworks (OWL, Nitrogen + Powerplant, maybe 1 or 2 more), and I've seen a crap-ton of bad frameworks (any web framework on java, minus maybe WebObjects). They're necessary, but they're hard to do right. The man who did Powerplant said he went through about a dozen different designs before getting one he liked. That's why it was often so useful. Most times, people say "hey, let's take these APIs and l…
What made WO great were the tools. There was still complexity there, but WOBuilder and EOModeler made the whole process very productive. You could think of your data model, your interface, and your business logic independently of each other, and then use the tools to hook them together in a way that made sense. Because of the way the tools were designed, they actually made using good design for your application easier than using bad design.
That's the main thing missing from all the frameworks I see today, integrated tools that automate the tedious parts and encourage good design practices.
To me, the WO tools go on the heap with the Lisp Machine, the Xerox Park Smalltalk environment and HyperCard, as old development technologies that are still ahead of today's state of the art.
EDIT: spelling correction
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 programmers.
But think about it, my fellow top 10% (lol), do you really need all this stuff? If you're working alone or on a small team with a clear objective, haven't you always had everything you needed with low level tools? If you need any higher level tools or reuseable components, haven't you already been building these all along?
Sure it's fun to play with new things and learn from others, but when it comes time to really produce, don't we all know how to (and need to) roll with what we know?
The need for frameworks and high level languages only becomes apparent when we grow so large that we can't find enough senior hackers. Only when you dip down into the mediocre masses do you need this help.
Frameworks can sometimes be annoying. It's like learning a new sub-language on top of the programming language as there is a certain amount of familiarity you need with a framework's calls (ex. to program in Python, it goes a lot faster if you know that it's len(list) not list.length() and similarly if you're using Rails it's important to know that there is no validates_is_number, but there is validates_numericality_…
In other words, by installing frameworks, you will be able to experience the power of frameworks?
I've seen good frameworks (OWL, Nitrogen + Powerplant, maybe 1 or 2 more), and I've seen a crap-ton of bad frameworks (any web framework on java, minus maybe WebObjects). They're necessary, but they're hard to do right. The man who did Powerplant said he went through about a dozen different designs before getting one he liked. That's why it was often so useful. Most times, people say "hey, let's take these APIs and l…
"minus maybe WebObjects" What made WO great were the tools. There was still complexity there, but WOBuilder and EOModeler made the whole process very productive. You could think of your data model, your interface, and your business logic independently of each other, and then use the tools to hook them together in a way that made sense. Because of the way the tools were designed, they actually made using good design f…