Why I hate frameworks (2005)
benjismith.net
benjismith.net
Also, I can focus only on the solutions and features I need. I often don't have to build for the super general case, which often results in a simpler framework that helps rather than hinders.
Frameworks are not to be avoided, but generic frameworks are very dangerous, so usually a custom framework, built with generic libraries, is the better choice.
Main points: two frameworks can be very hard to use together, unless designed to be (both keep trying to keep the control), frameworks are a lot harder to use than library, as they impose their whole world view, and frameworks encourage tight coupling (there are about 3 patterns from Ralph's book with Erich Gama, Richard Helm and John Vlissides that have this kind of problem to solve).
I read somewhere (wish I could remember where, bizarrely I think it was on paper) that the very definition of a framework over a library is that inversion of control - ie your application runs inside the framework - you are beholden to its lifecycles and view of the world.
When on the JVM, I use scala - and I have found very little utility for frameworks. Libraries - oh yes, very much so.
I'm sure there's good reasons behind it, but setting up logging for a Java backend a while back was pretty crazy. Ended up choosing logback as the logger implementation, sl4j as the logger abstraction layer, and then added log4j and commons-logging replacement jars that emulated those API's and redirected them to sl4j, which redirected them to logback.
When I say many/most software written in Java is slow, people tend to laugh and direct me to the shootout benchmarks. This is actually sign of ignorance of what's really going on in the wild, which you can learn at operations btw. You don't put your stack of dependency injection, loggers and ORMs into a microbenchmark like shootout, while you do it for the typical Java web application. The insane amount of calls on stack - tens of thousands and above, and the insane amount of small classes which all have to be managed by classloader, takes your app out of cpu cache, takes your files out of os file cache, pumps the enormous memory usage, stresses the gc and causes your JVM to have its crawling moments - or crawling standards.
So it's not that JVM itself sucks, but the stuff you typically want to run on it makes it a horror.
I think it's worth considering that there's no such thing as "microsecond spent on few commands" alone. Every extra vm command competes with others in the cpu cache, similar for classes loaded in the os file cache. It seems to matter when you have thousands of typical calls on a stack instead of, say, dozens.
http://ptrthomas.wordpress.com/2006/06/06/java-call-stack-fr...
Just Wowwww :)
What I've found is that many IT departments feel pressured to use Java but don't really want to learn Java, so they try to find an IDE that will let them build the GUI without coding and a framework that will turn most of the job into configuration through XML. The result is that the solutions are a lot more complex and people hate Java.
I don't care if YouTube scales to hundreds of millions of users with Python, our 200-user website is mission-critical and demands scalability!
Except very little is tested (its getting better) and everything is so tightly coupled it dosnt make a difference anyway.
At one point I counted 23 layers of abstraction between the fairly simple JSP page through EJBs and a connector to eventually make a simple SOAP call to get the data to go on the page. Everyone of those layers had an interface, a factory and an implementation....
Imagine my delight when I found multiple jar files, all with the same name but with different contents, all included in the classpath for WebSphere.
Something like 98% of the code did nothing useful.
Because nothing is more enterprisey than "architecture astronautics". Also, it's a nice way to spend time doing nothing useful in a large bureaucracy.
Worse yet, many dyed-in-the-wool javaists also have mental blinkers (see: blub language) which prevents them from seeing outside the limits of the language, leading them to believe that it's perfectly natural and normal for an MVC application to require mountains of code, mountains of XML, and every detail reproduced in exacting triplicate across the depth of the framework. Simply because they lack the perspective to realize that they're missing out.
I think it is because of the whole corporate ecosystem that surrounds it. There's experts that need to make a name for themselves, consultants that need to make money, companies that need to sell services or consultants, etc. etc.
There is no way to have a function callback mechanism without introducing new classes. The very culture of using design patterns for everything is just a reflection on how things are solved in Java.
From what I can tell, SharePoint is another big layer of framework on top of ASP.NET, governing the way your application must be designed and function.
I program at the moment c# and java for a living and c# is fine (java too, if you can ignore all the frameworks). But sharepoint is a PITA. Don't get me started on complex webparts, getting them to work is weird - if there's a programmers hell I'm pretty sure you will have to program for sharepoint there.
(note: All information for sharepoint 2007)
Rails, .NET, various J2EE bloatware, etc. are all things that I've seen the same pattern with.
Eventually I realized that there was no such thing, really, as a good vs. a bad framework. All frameworks are bad frameworks. I realized that I should spend no time looking for a framework for the same reason that I should spend no time looking for a disease.
Instead of frameworks, we need better and richer platforms with better and richer libraries, support for a variety of good languages, etc.
Seems like this is what .NET and the JVM are trying to achieve. MS is putting up a lot of different languages (C#, VB, IronPython, IronRuby, etc) and the JVM is experiencing somewhat of a rebirth with languages like clojure and scala (not to mention good ol' boring java).