Why I Hate Frameworks • Hacker News Board

Re: Why I Hate Frameworks

#111

Post by fizx » Wed, Jan 14, 2009, 12:19 AM UTC

patio11 wrote: post #2

An oldie (2005) but goodie. Although it is less about frameworks and more about a disease which was largely contained to Java enterprise-y architecture stuff. (I say as a practitioner in that field... remind me why we are using the Factory pattern here, again?)

In fairness, the Factory pattern is useful when you want to unit test classes with mocks. In dynamic languages, this is easy, but more static languages require jumping through hoops.

Alternately, you could use something like Google Guice, but that's (sorta) a factory-factory.

Basically, no one likes the situation, but they've chosen their tradeoffs, which they see as the lesser of N evils.

Re: Why I Hate Frameworks

#112

Post by Andys » Wed, Jan 14, 2009, 12:32 AM UTC

dgabriel wrote: post #25

jimbokun wrote: post #22

Earlier quoted context omitted.

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…

Java is not the problem, the architecture is the problem. If you try hard enough, you can make something unwieldy and atrocious in ANY language. That's why enterprise architects get the big bucks.

The thing is, if you're writing a Ruby framework and there's a tiny chance someone will want to extend some part of it, they can do it without you needing layers of ClassFactoryFactory crud.

Re: Why I Hate Frameworks

#113

Post by azanar » Wed, Jan 14, 2009, 12:45 AM UTC

dallasrpi wrote: post #43

edw519 wrote: post #27

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…

Lets see I can use Rails and build something or I can spend my time building something like Rails from scratch. Not a tough choice. The top ten percent probably don't reinvent the wheel when they don't have to. Do you write all your own libraries too? Maybe your situation doesn't fit the mold but your claims about efficiency and programming prowess are a bit absurd.

> The top ten percent probably don't reinvent the wheel when they don't have to.

True, but they can invent the wheel because there isn't one, and they can do so in a way that others will find it useful as well. It is a different point than edw519 is making, but what he said made me think about where I disagreed and why. The purpose of code libraries, is to make everyone more efficient, by solving a problem so others don't have to. If that means a programmer can produce twice as much functionality within a given time frame, or is able to produce any functionality at all where he couldn't otherwise, there is still a net benefit for everyone. This should not be scoffed at; it is the reason why we are able to produce software as featureful and useful as we do. Imagine each of the XFCE, KDE, and GNOME teams having to rewrite X.org all over again, and how much less each of those desktops would have to offer right now if they did. I'm willing to trade useful functionality sooner for less machismo.

But libraries don't always achieve this, and the degree to which it doesn't determines which people will be motivated to create a replacement. If a framework solves a common problem, but does so in a painful, unwieldy, or hard to understand way, some hacker out there will probably think it a better, more efficient choice to just write and use a new solution. It might be a fork of or series of patches to the original framework, or it may be an entirely new codebase -- which of these routes to follow is a judgement call. Nevertheless, it requires what I think is an important distinction, which is the ability to not just understand what problem the framework solves, but how it solves that problem. And not understanding it just in following what each line of code does, but why what steps it takes work. At that point, you end up leveraging a framework far more that relying on it. If something tomorrow were to happen that required you leave it behind, it would be a pain in the ass, but not a brick wall.

There is also the question, more important that the above in my mind, of understanding if you actually have the problem the framework solves, or if you are attempting to shoe-horn. But I worry that might be a bit off-topic of this particular thread, and would probably warrant another 3-4 paragraphs of musing.

Re: Why I Hate Frameworks

#114

Post by blasdel » Wed, Jan 14, 2009, 12:51 AM UTC

swombat wrote: post #64

axod wrote: post #36

Earlier quoted context omitted.

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? Come on, now.

That's a bad example to bring up, considering how Apache httpd is such a massive pile of shit.

Re: Why I Hate Frameworks

#115

Post by indiejade » Wed, Jan 14, 2009, 1:28 AM UTC

chez17 wrote: post #59

edw519 wrote: post #49

Earlier quoted context omitted.

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…

Good for you, standing up for yourself.

I think if you hang out with "programmers" long enough, you'll learn that the worst ones spend the majority of their time complaining about the shortcomings of others' "programming" techniques or methodologies. In reality, there is no de facto standard modus operandi for the nirvana of any code, and if you want to learn, it's best to just keep an open mind.

Re: Why I Hate Frameworks

#116

Post by dpifke » Wed, Jan 14, 2009, 3:06 AM UTC

st3fan wrote: post #54

arockwell wrote: post #45

Earlier quoted context omitted.

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's dependence on XML files always bugged the hell out of me. I like to be able to see what a piece of code does by looking at the code. Every time I tried to get excited about Spring I instead felt like at I was more and more at the mercy of my IDE.

Re: Why I Hate Frameworks

#117

Post by EliAndrewC » Wed, Jan 14, 2009, 3:22 AM UTC

arockwell wrote: post #15

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.

On a similar note, the code parse an XML document in Java:

    Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse("test.xml");

That's not even a framework; it's just what's in the standard library for parsing XML.

Re: Why I Hate Frameworks

#118

Post by lallysingh » Wed, Jan 14, 2009, 4:06 AM UTC

jm4 wrote: post #107

st3fan wrote: post #80

Earlier quoted context omitted.

"""Over-complexity is common in the Java space.""" Yes, in a SPECIFIC area of the Java space. There is a huge group of people who believe that J2EE and its complexities are a major pain the ass. That is why great frameworks like Spring, Guice or Stripes exist. Sun loves you when you use J2EE/JSF/EJB/JMS/JWHATEVER. But there are serious alternatives that are more lightweight, easier and less intrusive. Of course you w…

Have you seen Spring lately? I'm not sure it's much of an improvement. Stripes is nice as far as Java web frameworks go, but it's fairly simple and this is where the problem lies. Someone comes up with a tool that's great for a specific job. Later, someone else comes along with a slightly different problem and the tool changes a little to accomodate them. Then a few others. Before you know it every feature under the…

Just finished a Struts 2/Spring app. Hey, I had to cover tuition somehow.

The biggest problem with the entire stack is that every piece would rather overengineer a solution to a small part of the problem, instead of giving us a simple solution for the whole thing.

Look, just have a stock web.xml, and don't touch interceptors. Instead, put together a single, coherent system for dispatching a URL to the right object, and the same for security requirements. If you need more, abstract once, there for the URL. That's it.

After months of reading through crap documentation (Hibernate, I'm looking at you), it's obvious that the frameworks are 90% of the problem, and your actual set of requirements are the last 10.

Re: Why I Hate Frameworks

#119

Post by ynd » Wed, Jan 14, 2009, 5:49 AM UTC

EliAndrewC wrote: post #117

arockwell wrote: post #15

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.

On a similar note, the code parse an XML document in Java: Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse("test.xml"); That's not even a framework; it's just what's in the standard library for parsing XML.

I bet they were looking for extensibility.

I wonder if they ever thought of providing two interfaces.

1. The first is the common case.

    Document doc = new DocumentBuilder().parse("test.xml");

2. The second is more cumbersome but provides options.

    Document doc = DocumentBuilderFactory.newInstance(opts).newDocumentBuilder(opts2).parse("test.xml");

Re: Why I Hate Frameworks

#120

Post by ynd » Wed, Jan 14, 2009, 6:07 AM UTC

st3fan wrote: post #48

I stopped reading after "In the process, I'm evaluating a bunch of J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container frameworks."

That was humor :)

The rest is funnier. Give it a try.