HP should save the enterprise from Windows 8
With Microsoft bringing their own branded tablets to market, what is left for major OEMs like Hewlett Packard? One's first reaction may be to consider trying to do one better with the hardware. While this is still possible, maybe HP should consider getting back into the software business.
HP is making a good decision by concentrating on the x86 platform, rather than ARM in future tablets. Windows RT is untested at this point. Also Windows RT will not run the huge existing x86 based Windows software base that dwarfs any current app store in quantity and quality. There can be many advantages to HP's current decision.
Microsoft has made some choices in the past decade that demonstrate they have lost appreciation for the value of backward compatibility. This was once Windows biggest strength, but it is now changing. Dropping classic Visual Basic for VB.NET was the first step. Pushing managed programming languages (aka. .NET) and the .NET frameworks was the next step. Windows 8 and its new Metro interface has been the pinnacle of this mindset. While consumers may flock to Metro and the App Store model, power users and especially business users will be more concerned with a more practical approach of backward compatibility. To appreciate the significance of backward compatibility and how it made Windows what it is today read Joel Spolsky's discussion about this.
HP has an opportunity to build its own unique software, to go with its hardware, which can give it an edge over Microsoft. How? Microsoft sadly has lost appreciation of how important backward compatibility is, but HP can use this to their advantage. How?
While Microsoft in their own software development has to a degree abandoned backward compatiblity, the operating system hasn't totally lost this. Windows 8, aside from Metro, still supports the Desktop. The interesting thing about the Windows 8 desktop is that it does an amazing job of running older software and the WIN32 APIs are still quite intact. I have done extensive testing of this and I have found that one can easily write complex software that can run on a wide-range of Windows platforms from Windows 95 to Windows 8. Now HP really only needs to concentrate on Windows XP to Windows 8, which is actually not that difficult. Business users will appreciate modern software that will run just as well on their Windows XP machines as it does in Windows 8. Software can also be designed to poll the operating system and then dynamically impliment features based on which ever version of Windows it is being run on.
Build Better Software
Can an OEM like HP build better software than Microsoft ? If they want to, absolutely! Watch Herb Sutters (Microsoft C++ expert) talk "Why C++?" and see how he describes the industry's failure to develop software with performance in mind. Now as a long-time Windows API developer myself, I will go one step further than Sutter. I lay the blame on managed programming languages and the industry's obsession with Object Oriented Programming. The majority of programmers will likely not agree with this observation, but I strongly feel that we have lost sight 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 that 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 that 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
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:
His white paper entitled "Has OOP failed ?" 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 .NET so he obviously had plenty of experience using OOP based languages.
To quote 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",
Asaf Shelly:
I found this interesting blog on the Intel web site with an article entitled "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".
Stephen C. Johnson (Melismatic Software):
"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".
Said to be the designer and original implementor of C++ makes some interesting comments in an interview: "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".
He 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".
Dermot Hogan (Bitwise magazine technical editor):
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:
"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 that 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?
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 16MB RAM, 7MB virtual memory, 14 threads and the other using about 134MB RAM, 125MB virtual memory, 24 threads. Just displaying one web page is costing me 150MB RAM, 132MB 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.
What this means for Hewlett Packard is that the hardware specs alone won't make the difference. If they want to build better tablets than Microsoft, the software experience also has to improve. Now does anyone really expect the Windows 8 Pro Surface tablet to cost much less than a $1,00 ? Not likely. Why? Because to provide the proper-end user experience, heavy-duty hardware is required. 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.2GHz dual-core CPU (2MB RAM), on which I had installed Windows 8. While Windows 8 runs very well on this computer, Visual Studio is so slow it amazes me. When the development tools programmers use today are so bloated that they require heavy-duty multicore CPUs 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".
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".
HP, 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".
While HP likely can produce a simliar quality Windows tablet compared to Microsofts Surface, maybe what they really need to do is concentrate on the entire end-user experience. By building better software with a small footprint and significant performance, HP could even offer lower-cost tablets that would better appeal to businesses and consumers alike. Editor: Didn't HP already try this, and give up, with TouchPad and webOS?
Netbooks became popular, not just because of their small form factor, but also because of their extremely low price. Could HP be the first to build a $200 Windows 8 (x86) tablet? It may be possible. Intel's StudyBook tablet concept is a great idea, but the cost is too high. A 7-inch Windows 8 (x86) tablet in the $200 range is definitely possible, but it would require the software to match. Even Microsoft's Windows RT Surface tablet is likely going to be in the $500 range from what I gather so far, which is not that impressive to me.
If Microsoft can get into the hardware business, maybe HP needs to get into the software business. There are advantages of building the software to match the hardware. While Microsoft is likely building the hardware to match their software, HP could do the reverse and start building the software to match their hardware, but just doing it one better and opting for a small footprint and performance.
Build a Bridge Between the Desktop and Metro
Metro will be a big change for many people, while the desktop, refered to as legacy, is not dead yet and may have a much longer life span than even Microsoft may think. What is needed is a better bridge between the two. HP could provide this with well-designed software that better bridges the two. Businesses shouldn't have to replace all their computers with Windows 8 PCs (or upgrade them all), but they should be able to easily integrate a few new Windows 8 computers (and the software) with their existing computer base. Obviously some software must be designed for Metro, but the desktop is not dead yet and that needs to be concentrated on.
While Metro apps will only run on Windows 8, desktop apps can run on many current versions of Windows, too. Why would a business want an application that can only run on Windows 8? Now if HP could design software that could span all the different versions of Windows, including Metro, to provide a better overall experience, this could provide them with an advantage. HP can build for the desktop first, while building secondary apps (with similiar functionality) which support Metro as well. The enterprise would definitelly appreciate this and HP could offset low-profit margins of the hardware by selling more software.
For example, imagine buying an HP Windows 8 tablet that comes with a DVD with a suite of tools which not only runs on Metro (Metro versions), but also can run on Windows XP, Vista and 7 machines (desktop versions). If you buy their tablet, they could offer a special OEM price for buying extra DVDs of the same software suite to run on your Windows XP or 7 desktops. In the end, software is what makes the difference!
If HP wants to move into the twenty-first century, then maybe they, too, should become a hardware and software business -- the latter, again. Apple does it. Google is now doing it and so is Microsoft.
Photo Credit: drserg/Shutterstock
Chris Boss is an advanced Windows API programmer and developer of 10 year-old EZGUI, which is now version 5. He owns The Computer Workshop, which opened for businesses in the late 1980s. He originally developed custom software for local businesses. Now he develops programming tools for use with the PowerBasic compiler.