Build smaller, faster and better software ! (or “OOP is overrated”)

 

Watch Herb Sutters (Microsoft C++ expert) talk “Why C++?”  ( http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C ) and see how he describes the industries failure to develop software with performance in mind. Now as a long time Windows API developer myself, I will go one step further than Herb Sutter. I lay the blame on managed programming languages and the industries obsession with Object Oriented Programming. The majority of programmers will likely not agree with this observation, but I strongly feel that we have lost site of how to build software with a small footprint and excellent performance. I am not alone in this viewpoint either. How software is designed can determine whether it is efficient or not. Also targeting hardware directly using programming languages which can leverage the power of CPU as well as the operating system provides manufacturers the ability to build software with a small footprint and high performance which can significantly improve the user experience on tablet computers. There are those experienced in software development who recognize that current development methods, particularly object oriented programming, don’t always produce the high performance software end users desire.

What others are saying.

 

Alexander Stepanov

 

This quote attributed to Alexander Stepanov from an interview is quite interesting .

( http://www.stepanovpapers.com/LoRusso_Interview.pdf )

Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work: Bill Gosper’s Hakmem is one of the best things for a programmer to read. AI might not have had a serious foundation, but it produced Gosper and Stallman (Emacs), Moses (Macsyma) and Sussman (Scheme, together with Guy Steele). I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras – families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting – saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms – you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work. “

Also found at:

http://en.wikipedia.org/wiki/Alexander_Stepanov#cite_note-stepanov2-4
http://www.antiquark.com/escape/public_html/stepanovusa.html

A more balanced understanding of his views of OOP can be found in this paper of his:

http://www2.research.att.com/~bs/oopsla.pdf

Richard Mansfield

 

Consider one experienced programmer who has asked these questions, Richard Mansfield. His white paper entitled “Has OOP failed ?
( http://www.4js.com/files/documents/products/genero/WhitePaperHasOOPFailed.pdf )

broaches this subject. Richard Mansfield has a very long history in technology. He was the  editor of Compute magazine for about 7 years and has written dozens of computer / programming books which in total have sold about 500,000 copies. A number of his books were on Visual Basic dot.net so he obviously had plenty of experience using OOP based languages. To quote Mr. Mansfield “There’s no evidence that the OOP approach is efficient for most programming jobs. Indeed I know of no serious study comparing traditional, procedure-oriented programming with OOP. But there’s plenty of anecdotal evidence that OOP retards programming efforts. Guarantee confidentiality and programmers will usually tell you that OOP often just makes their job harder.”

Intel Blog:  by Asaf Shelly

 

I found this interesting blog on the Intel web site with an article entitled “Flaws of Object Oriented Modeling” .

( http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/ )
The author makes this comment about OOP:  “Now it is almost impossible to follow the execution flow. When you want to know what happened in your application when the error message popped up you have to go over all the objects and all the classes that the execution flow went through and many times execution flow travels between several member functions before leaving to another object. Following the execution flow today is almost impossible.”

Usenix article:  by Stephen C. Johnson (Melismatic Software)

 

To quote this article “Object-oriented programming (OOP) is an ancient (25-year-old) technology, now being pushed as the answer to all the world’s programming ills. While not denying that there are advantages to OOP, I argue that it is being oversold.”  and also “Object-oriented languages tend to burn CPU cycles, both at compile and execution time, out of proportion to the benefits they provide.”
( http://static.usenix.org/publications/library/proceedings/sf94/johnson.html )

From ATT web site: Bjarne Stroustrup

 

Bjarne Stroustrup said to be the designer and original implementor of C++ makes some interesting comments in an interview.

( http://www2.research.att.com/~bs/slashdot_interview.html )
To quote Bjarne : “Well. It was obvious to me 20-some years ago that OOP wasn’t a panacea. That’s the reason C++ supports several design and programming styles. “ and
“In the first edition of “The C++ Programming Language,” I didn’t use the phrase “object-oriented programming” because I didn’t want to feed the hype. One of the problems with OOP is exactly that unscrupulous people have hyped it as a panacea. Overselling something inevitably leads to disappointments. “
“That said, OOD/OOP is my favorite way of approaching design and programming. It just isn’t the right style for every program and for every detail of a program. Some good abstractions are best represented outside class hierarchies. Trying to force everything into a hierarchy – especially into a single-rooted hierarchy – can give truly contorted programs. “

Blogger and programmer Chris Turner

 

Chris Turner describes himself as “an agile architect and developer specialising in building large, scalable enterprise and Internet solutions” . In his blog he makes some interesting comments such as “I have therefore been moving away from the object-oriented development principles that have made up the bulk of my 17 year career to date. More and more I am beginning to feel that objects have been a diversion away from building concise, well structured and reusable software.”  and concludes by saying “I’m certainly building smaller, cleaner and better structured software than I ever was before.”

( http://skipoleschris.blogspot.co.uk/2012/04/life-without-objects.html )

Bitwise magazine:  Technical Editor Dermot Hogan

 

Dermot Hogan has some strong words about OOP in his article on Bitwise.
( http://www.bitwisemag.com/copy/bytegeist/bytegeist1.html )
To quote Dermot he says “in the twenty or so years since object-oriented programming emerged from the universities, there is not one single documented, cast-iron, nailed-to-the-ground, proven case study that OOP works.” and also “On the contrary, there is solid evidence that OOP doesn’t work. Just look around you at the numerous failed, over budget disasters in the IT industry.”

Department of Computer. Science and IT, University of Jammu

 

To quote a paper written by this universities CS dept
( http://www.csjournals.com/IJCSC/PDF1-2/9..pdf )
it says : “The use of object-oriented technology (OOT) has been shown to be of great value in many market sectors, but to the use of such technology within embedded systems remain a challenge. Such systems require high execution speed and have high memory constraints. “ and ” The object-oriented approach is known to introduce a significant performance penalty in terms of memory and time compared to classical procedural programming. In this paper, we have analyzed the execution speed of the different programs generated by the compilers of C and Java. The investigation shows that the speed of execution shows considerable difference between the Object Oriented and procedural programming languages. ”  and they come to an interesting conclusion when they say “It is concluded that the Object Oriented Programming languages proves to be slower than the procedural programming languages in terms of execution speed than there counterpart.”

Multicore CPU’s only mask the real problems !

 

Many of my peers will likely suggest that multicore CPU’s solve the problems with performance. True, developing software which leverages multicore CPU’s will make a big difference but I feel compelled to add that multicore CPU’s only mask the problem, rather the solve the problem. Why ?

( http://software.intel.com/en-us/articles/is-the-free-lunch-really-over-scalability-in-many-core-systems-part-1-in-a-series/ )

As a simple example, while I am writing this article on my Windows XP (sp3) computer, I have one instance of Windows Explorer 8.0 running, displaying the current betanews web page. When I run task manager IE actually runs two different instances (processes) of itself , one using about 16 meg ram, 7 meg virtual memory, 14 threads and the other using about 134 meg ram, 125 meg virtual memory, 24 threads. Just displaying one web page is costing me 150 meg ram, 132 meg virtual memory and 38 threads ! Rather than be an improvement, software for Windows 7 and Windows 8 will likely have similiar problems.

Now add to this all the background processes running on any typical Windows computer and you may have dozens of threads running using a significant amount of memory. While Windows 8 may have been improved overall, once you start running a few apps forget about performance and multicore CPU’s, while an improvement, don’t solve the core problem which is poorly designed software which over uses hardware resources

Have you ever wondered why at the build conference the tablet provided to developers had a heavy duty multicore CPU in it ? Because you need a powerhouse CPU to compensate for the performance lacking Visual Studio. I downloaded a recent Visual Studio beta and installed it on a system with a Pentium D 3.2 ghz Dual Core CPU (2 meg ram) which I had installed Windows 8. While Windows 8 runs very well on this computer, Visual Studio was so slow it amazed me. When the development tools programmers use today are so bloated that they require heavy duty multicore CPU’s just to run acceptably and they use as much disk space as some operating systems, then something is wrong.

End users often make comparisons between computing devices, such as tablets , by their hardware specifications. When you see a device with a quad core CPU instead of a dual core, one is quick to assume that you will get a significantly better experience. Sadly, some of the experience will be lost to software bloat. Yes, that better CPU means a faster computer, but will a percentage of that experience be lost to increasing software bloat ?

To take a quote from wikipedia:

“Niklaus Wirth has summed up the situation in Wirth’s Law, which states that software speed is decreasing more quickly than hardware speed is increasing.” 

( http://en.wikipedia.org/wiki/Software_bloat )

To take some quotes from IBM’s web site:

“Based on our 8 years of experience solving performance problems, we have found that runtime bloat in real Java applications is pervasive.”
“Bloat is a systemic problem, resulting from a software engineering culture encourages abstraction and layering, with a goal of rapid application development.”

http://researcher.watson.ibm.com/researcher/view_project.php?id=478 )

Go back to the basics !

 

Since the days of the early computers, something was lost along the way.

To quote the wikipedia article again:
“Software developers involved in the industry during the 1970s had severe limitations on disk space and memory. Every byte and clock cycle counted, and much work went into fitting the programs into available resources. Achieving this efficiency was one of the highest values of computer programmers, and the best programs were often called “elegant”—seen as a form of high art.” …
“This situation has now reversed. Resources are perceived as cheap, and rapidity of coding and headline features for marketing are seen as priorities.” …
“Niklaus Wirth has summed up the situation in Wirth’s Law, which states that software speed is decreasing more quickly than hardware speed is increasing.”

Why I use PowerBasic.

 

Call me old fashioned, but I just like a good old compiler with a langauge with a simple syntax. PowerBasic gives me the power I require, fast compilation speeds and produces small and fast applications.

( http://powerbasic.com )

 Note:  PowerBasic supports classes and COM objects, but one can also write purely 100% procedural style code with it.