He hits mainly on the layers of complexity and abstraction, but the biggest problem I have using frameworks is the inversion of encapsulation and control. When I want a hammer to stick in my app, what I don't want is a big Hammering Framework that wants my app to go inside of it. It's particularly problematic if you want both hammers and saws, and both the Hammering Framework and the Sawing Framework want to be the top level.
I prefer creating customized frameworks from libraries. I tend to know more about my particular problem than any generic framework writer.
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.
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.
Yeah, I think that might actually be the definition now that I think of it. I do think there are some cases where that inversion of control makes sense, but it really has to be cases where there's no sensible way to proceed with anything other than total buy-in to a particular way of doing things. For example, it's fine that something like the Unreal Tournament engine is a framework. If you're going to write your game in the UT engine, you're really going to have to write it in the UT engine, and commit to doing things the way it does things; there's no sensible way for you to just use the UT engine as a library subordinate to your game. But I don't want to do that sort of thing very often or lightly.
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).
The reason why I submitted this (beyond the fact that I totally subscribe to his views) is to ask if anyone knows something about this guy. I used to follow his stuff, especially the 30 ideas in 30 days, then he stopped posting 2 years ago.
I worked with him at an AI-focused defense contractor in Cambridge till about a year ago (when I left). He's a pretty cool guy - what did you want to know?
Yeah, but he was writing frequent updates about his startup, then it just ended abruptly. I was curious how the project worked out and also hope he is ok.
The layers of abstraction for Java projects are getting almost comical.
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.
Yes and that's why many Java applications esp. in the corporate world are slow, contrary to the common belief.
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 respectfully disagree that frameworks are causing corporate java applications to exhibit poor performance. I've never seen evidence of it. The extra layers of abstraction added by the framework certainly do slow things down, but in the corporate world it's the database that has the biggest impact on app performance. The microseconds spent executing a few extra commands is negligible. Bad programmers will always create poorly performing software and the corporate world is full or bad programmers who are using frameworks. To place the blame on the frameworks and not the programmers is misguided in my opinion.
it.s combination of factors: most custom software vendors combine pretty incompetent programmers (on average) with crappy inhouse frameworks built by these programmers.
Well I have seen such evidence a couple of times. Some profiling of code using huge library stacks gave really surprising results.
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.
Hahaha I love that sentence : In the process, I’m evaluating a bunch of J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container frameworks...
I've read this before and it's an excellent diatribe. However, it's as much of a knock against Java's limitations as it is against frameworks in general. Frameworks in other languages are not nearly so onerous or convoluted.
I don't understand why this culture of making things ever more complicated has grown up around Java. I've given up using these trendy frameworks and make do with just Struts/Tiles and plain JSPs. I've recently rewritten an application that used Oracle ADF and it came out 10% the size of the original.
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.
But.. but... but... we're an Enterprise! Any language that doesn't require writing a Dao and a DaoImpl and a Service and a ServiceImpl and a Controller and a ControllerImpl and an extremely verbose JSP template and about a hundred lines of XML to do something trivial is a toy!
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!
The above comment describes everything I work with on a day to day basis at my job. Every solution contains multiple layers of abstraction from the aspx to the code behind, to a controller to multiple services to multiple daos and with all of them implementing something to allow for testing.
Except very little is tested (its getting better) and everything is so tightly coupled it dosnt make a difference anyway.
I once had to try and salvage something useful from a huge J2EE application where the development team were obviously as they say "taking the p*ss".
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....
Some of the source code was missing too - so I had to decompile great chunks of stuff and wade through the resulting code to find out what was going on.
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.
I don't understand why this culture of making things ever more complicated has grown up around Java.
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.
Java is a fine language, but it has some significant limits. Unfortunately Java has become the de facto general purpose language in many places, especially in "the enterprise". So a lot of tools have been built in and on top of Java which allow you to do anything and everything with it, even when other languages would be a far more natural fit and would require drastically less development effort.
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.
What about the fact that everything needs to be a class? This works on Javascript or Smalltalk, which are dynamic languages, but not in a static language.
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.
The experience at our company with .NET kind of illustrates the subtle differences between "frameworks" and "collections of libraries". Microsoft bills .NET as a framework, but from a practical perspective it's really a big collection of libraries (and languages) which is great. ASP.NET, and to a lesser extent ADO.NET, although theoretically sub-collections of libraries, are really more like frameworks. And while some of their features are nice (e.g. forms authentication), you recognize the maze of factories building factories when something cleaner (like jQuery) comes along. Frameworks can be like training wheels. They can help you get started and keep you going, but as you get more sophisticated you realize they are in the way.
I'm curious to hear your opinion of SharePoint, if you have one. I'm new to the C# world and I'm pleasantly surprised that it's not as bad as Java like I thought it would be, but I've mostly been focused on the language and core libraries. I think I like it for the reason you describe: it's libraries, rather than frameworks. But I've started getting into some ASP.NET code and the frameworkiness is starting to appear. In my case it's entity objects which don't seem to do more than structs, interfaces for classes which talk to the entity objects, implementation classes to implement the interfaces which just copy data from entity objects into their own properties, business objects which talk to the interfaces to get to the entity data, and UI objects/templates that talk to the business objects, probably through another layer of interface/implementation.
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.
It is another big layer of framework on top of ASP.NET which does _not_ work reliably. Be prepared to spend your time producing bugfixes for subtle and/or obscure bugs which you will have on one sharepoint installation but not on another. Install sharepoint twice on different systems and there will be differences right after the installation.
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.
Frameworks are like crack. At first they make things feel great and quick and easy, but eventually the framework forces you to work around it and adds layers of complexity. It invades your application and forces you to do elaborate dances when you need to do something a bit differently than the framework thinks you should do it. Eventually you wind up spending more time fighting the framework than writing your app.
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.
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).
I don't like frameworks, but they have their place. If you know enough to create a framework, you should better do itself. However there are two situations when they are necessary: (1) people who have not enough knowledge to build one and don't want/need to acquire that knowledge; (2) quick applications where there is no justification for the time invested in working at a lower level.
I like to think about frameworks in terms of those long tail distributions. They do well for many common cases but as you go further and further out in the distribution it becomes more and more convoluted to get your solution written in terms of the framework. In most cases the users end up asking for very unique features that never occurred to the framework designers.
