Frameworks simplify coding at the cost of speed and obfuscation of the OS. With the passing of Moore's law do you thing that there might be a shift away from Frameworks?

Question

Frameworks simplify coding at the cost of speed and obfuscation of the OS. With the passing of Moore's law do you thing that there might be a shift away from Frameworks?

I suspect that one of the reasons for Vista not being an outstanding success was that it ran much slower than XP, and, because computers had not improved as greatly in speed as in the past, this change seemed like a step backwards.

For years CPU speed outstripped the speed of software so new frameworks that added layers of OS obfuscation and bloat did little harm. Just imagine how fast Windows 95 would run on today's hardware (given a few memory tweaks). Win2K then WinXP were great improvements, and we could live with them being slower because of faster computers.

However, even years ago, I noticed that programs written in MS foundation classes didn't seem quite as crisp as code doing the same thing written directly to the API. Since the proliferation of these frameworks like .Net and others can only have made this situation worse, is it possible that we might discover that being able to write code in 'C' directly to the Win32 API (or the equivalent in other OS's) will become a strong competitive advantage, even if it does take longer to write? Or will the trade off in longer development time just not ever be worth it?

Answer 1

Stepping away from frameworks would be a step backwards and I think and hope that this won't happen.

Answer 2

If there is selective pressure to make apps faster, I think that people will become better at writing frameworks that encapsulate functionality without slowing down the system too much.

The Boost::Gil framework that handles pixels is a nice template-based system that boils down to many inlined functions - the compiler creates the same output as it would if you had no wrapper for the pixels and accessed the values directly.

So - as for your question, I think the ball is in the court of the framework writers to ensure that their frameworks are fast and lean. This might mean that they detect which features are in use and remove code relating to unused features.

Answer 3

frameworks exist to encapsulate common functionality; this will never change

and what makes you think moore's law is dead? with MIT students growing bacteria that self-assemble nanowire circuits, moore's not dead yet...

Answer 4

What exactly do you mean by "frameworks". This word is overloaded so much in our industry. If you mean something like MFC or .Net then I think they are here to stay. They have nothing to do with performance at runtime. They have everything to do with code reuse, maintainability and separation of concerns.

By the way Vista is not slow because it uses frameworks; it is slow because it uses a lot of useless frameworks like DRM. It might also suffer from low quality since MS is slowly becoming a more bureaucratic corporation - my perception. Vista also suffers from a lack of purpose. It doesn't bring anything worth upgrading for. It tried to compensate with GUI frosting.

Answer 5

The challenge I think for this to happen would be to find enough developers who are confident writing code without the 'crutch' of the many frameworks that there are out there today. More and more computer science/software engineering academic courses are ignoring the C's of the world in favour of the Java and .NET's (not that I have anything against Java or .NET, I earn a living from .NET as I'm sure many, many others do) because that is what the industry demands today.

As a result, recent graduates take many frameworks for granted (unless they have enough interest to find out for themselves what happens 'under the hood'). Self-taught developers would also more than likely go for stuff that is easier to learn and easier to use. Again, this is notwithstanding the folks who are really keen and take the trouble to learn what happens behind the scenes of any framework that they use.

And so I agree with a previous post, it'll probably be down to the writers of the framework to come up with creative ways to ensure that their stuff runs efficiently. My impression is that a sizeable number of developers aren't really interested in how a framework does X, they just want it to do it for them so that it helps them do their work quicker. Having to move away from frameworks would not be easy for many people, in my opinion.

Answer 6

"This word is overloaded so much in our industry. If you mean something like MFC or .Net then I think they are here to stay. They have nothing to do with performance at runtime. They have everything to do with code reuse, maintainability and separation of concerns."

I have to say they do have a lot to do with performance at runtime, in many cases. Even if you called the framework, and it directly called the API call (in which case there would be no point, but this is the best possible case for speed), there would still be the performance penalty for an extra function call, which can be significant at times.

Also, I have to admit, wish respect to the original poster, Vista is a step backwords. It is slow due to things like DRM that are not "features". Windows XP was actually faster than windows 2000 in many respects. Vista certainly is not.

Answer 7

For many pieces of software performance isn't the problem, it's time to market. This is often the case 'in-house' where a team may care much more about getting an initial version of an app in front of the users quickly than about how fast (or even how stable) it is. Add to this the fact that a well written framework will simplify development of applications that are the target of the framework's design and you'd often be mad NOT to use a framework if one is available. Of course you're taking the risk that the framework will allow you to get 80% of the way to your goal and then leave you high and dry, but, well, you can usually mitigate that by working outside of the framework for that last 20%. Like everything good in software it's often all about layering; you might first select .Net as a 'framework' and then decide to use a particular .Net GUI 'framework' for parts of your app and then, perhaps, a separate socket's 'framework' for other parts. Or, you might decide to work in C++ and use boost as a framework, or, perhaps pick a more focused framework that offers you more abstraction and (hopefully) greater coding speed.

The problem is, often, selecting the right framework and deciding how much performance you are willing to sacrifice for ease of development.