3 ms·
Java is a fine language, but the community suffers from rampant over-engineering and frameworkitis. There's this belief that frameworks save time by saving you
by api 16y ago
Java is a fine language, but the community suffers from rampant over-engineering and frameworkitis. There's this belief that frameworks save time by saving you from writing code, but in the end the amount of time you have to spend learning and applying the confusing bloated over-engineered framework exceeds the time it would have taken to just write the damn thing yourself.
But, they say, if it's written with frameworks then it's written in a "standard" way. You don't want to sift through a bunch of "cowboy code!"
I have never seen this work in practice. Framework spaghetti is every bit as opaque as badly written uncommented crap code. At least the latter tends to be concentrated in one place, rather than shotgun-scattered all over a bunch of weird .XML configuration files and different projects all over the place.
I routinely find myself asking: "what problem does this solve?"
"But it's enterprise!"
Edit: just remembered the best term for what afflicts the Java community: architecture astronautism.
- arethuza 16y agoI remember seeing a possible explanation for this behavior on Joel on Software a few years back - Java seems to be particularly popular in environments where the design is handed down to developers as a finished spec, so the only outlet people have for any kind of creative expression is in the structure of the application rather than in what the application is actually doing. Not that this excuses the mad world of enterprise Java applications....
- SergeyHack 16y agoThe bare Java is not very fine as I see after comparing it with more concise languages, like Clojure. The enterprise Java conventions are even worse, like a convention for mandatory getters/ setter. Good framework in a good language can save a lot of work even for a big complex application.
- wisty 16y agoI can't help thinking that design patterns are often used as an excuse to avoid documenting the API. Extreme programmers are bad enough, but at least they encourage things like minimal interfaces, test suites, and pair-programming to stop the API becoming unreadable.
- retube 16y agoI agree with your points on frameworks. I deplore the over-use and reliance on huge swathes of code to accomplish what is a simple task in vanilla code (want to select a div in js? use jquery - come on!) But this is not an affliction limited to Java.
- amnigos 16y agoThis is a problem of too much abstraction.
- geebee 16y agoYou right stranger, but whartarewegonnadeuh? What do you think of avoiding frameworks and just going with the servlet spec? I'm not kidding here. I got fed up with Java about 5 years ago and taught myself Rails and Ruby, but I kept programming in Java largely because of work requirements. Every time I got to write nice, clean POJOs, life was pretty good, and I felt productive and enjoyed coding for long stretches. Every time I was deep in frameworks (spring, struts, hibernate, etc), I felt like checking email or HM or just going home. I like Rails, but even then I find myself fighting with the framework eventually. I'd say with Rails, the trade-off is easier to stomach - I get so much out of Rails that I'm not as unhappy when I have to figure out how rails does something. With Java, I'm even more tempted to just use the lowest level I possibly can, in the belief that the up-front cost to productivity will be offset when I need to do something that isn't easy with the existing frameworks. Another factor in all this is mental space. I can keep the core language in my head, but I can't possibly keep all the frameworkish stuff in there, and in Java, even if you find an article on using spring to do something, the example never works (strangely, in Rails, it usually does). The problem is... I still do need these things in Java as well. It does feel a little dumb to write my own MVC framework. I like auto-generating the dev database from annotations. I don't like Spring, but Dependency Injection actually is pretty damn useful for swapping out different implementations of a constant interface. I could go with something else, I guess... This is a tough one, and it's typical of complexity creep. Each individual decision makes sense, but after a thousand little tiny pieces of complexity are added, you step back and realize you have a monster on your hands.