What is the future of Java? It is a popular language, perhaps a bit long in the tooth, yet still capable. It struggled under Sun. Now it is the property of Oracle.
Oracle is an interesting company, with a number of challenges. Its biggest challenge is the new database technologies that provide alternatives to SQL. Oracle built its fortune on the classic, ACID-based, SQL database, competing with IBM and Microsoft.
Now facing competition not only in the form of other companies but in new technologies, Oracle must perform. How will is use Java?
For the future of Java, I suggest that we look to Google and Android. Java is part of Android -- or at least the Java bytecode. Android apps are written in Java on standard PCs, compiled into Java bytecode, and then delivered to Android devices. The Android devices (phones, tablets, what-have-you) use not the standard JVM interpreter but a custom-made one named "Dalvik".
Oracle and Google have their differences. Oracle sued Google, successfully, for using the Java APIs. (A decision with which I disagree, but that is immaterial.)
Google now faces a decision: stay with Java or move to something else. Staying with Java will most likely paying Oracle a licensing fee. (Given Oracle's business practices, probably an exorbitant licensing fee.)
Moving to a different platform is equally expensive. Google will have to select a new language and make tools for developers. They will also have to assist developers with existing applications, allowing them to migrate to the new platform.
Exactly which platform Google picks isn't critical. Possibly Python; Google supports it in their App Engine. Another candidate is Google Go, which Google also supports in App Engine. (The latter would be a little more complicated, as Go compiles to executables and not bytecode, and I'm not sure that all Android devices have the same processor.)
Google's decision affects more that just Google and Android. It affects the entire market for Java. The two big segments for Java are server applications and Android applications. (Java as a teaching language is probably the third.) If Google were to move Android to another language, a full third of the Java market would disappear.
If you have a large investment in Java applications (or are considering building new Java applications), you may want to keep an eye on Google and Android.
Sunday, December 27, 2015
Saturday, December 26, 2015
Servers need RAM-based SSDs, not flash-based SSDs
How to store data? How to store data on servers? In the "good old days" (prior to 2012), servers used spinning platters of metal (disk drives) to store data. The introduction of SSDs complicated the issue.
SSDs (solid state disks) eliminate the spinning metal platters and use semiconductors to store data. Today one can purchase an SSD that plugs into a PC or server and acts just like a hard disk.
SSDs provide faster read and write times, lower power consumption, and greater reliability (mostly -- more on that later). Their cost has been higher than hard disks, but that has changed. Prices for SSDs are now in the same range as "classic" hard drives.
But life with SSDs is not perfect. The solid-state disks use flash RAM, which allows data to be stored after the power is off (something we want in our storage), but flash-based RAM is not that durable. The heavy workload that servers put on their storage systems causes failures in SSDs.
I'm sure that many folks are working on methods to improve the reliability of flash-based RAM. But for servers, I think there may be another path: classic (that is, non-flash) RAM.
We've been building RAM for decades. We know how to make it, in large quantities, and reliably. Classic RAM is typically faster than flash-based RAM, and typically cheaper. So why not use it?
The big difference in classic RAM and flash-based RAM is that classic RAM, when you remove power, forgets everything. An SSD built with classic RAM would work beautifully -- until you powered the unit off. (And even then you would notice the problem only when you powered it back on.)
The impression is that such an arrangement would be useless. I'm not so sure, for two reasons.
First, while desktop PCs are powered on and off regularly, servers are not. Servers are typically installed in data centers and kept on, twenty-four hours a day, every day of the year. If the server stays on, the data stays in RAM, and everything works.
Second, it is possible to build classic RAM SSDs with small, auxiliary power supplies. These small power supplies (usually batteries) can keep the RAM active, and therefore keep the data, while main power is not available.
RAM storage units are not new. They date back to the mid-1970s, and have been used on IBM mainframes, minicomputers, and even Apple II computers.
I suspect that at some point, someone will figure out that classic RAM makes sense for servers, and build SSDs for servers. This will be another step in the divergence of desktop PCs and server computers.
SSDs (solid state disks) eliminate the spinning metal platters and use semiconductors to store data. Today one can purchase an SSD that plugs into a PC or server and acts just like a hard disk.
SSDs provide faster read and write times, lower power consumption, and greater reliability (mostly -- more on that later). Their cost has been higher than hard disks, but that has changed. Prices for SSDs are now in the same range as "classic" hard drives.
But life with SSDs is not perfect. The solid-state disks use flash RAM, which allows data to be stored after the power is off (something we want in our storage), but flash-based RAM is not that durable. The heavy workload that servers put on their storage systems causes failures in SSDs.
I'm sure that many folks are working on methods to improve the reliability of flash-based RAM. But for servers, I think there may be another path: classic (that is, non-flash) RAM.
We've been building RAM for decades. We know how to make it, in large quantities, and reliably. Classic RAM is typically faster than flash-based RAM, and typically cheaper. So why not use it?
The big difference in classic RAM and flash-based RAM is that classic RAM, when you remove power, forgets everything. An SSD built with classic RAM would work beautifully -- until you powered the unit off. (And even then you would notice the problem only when you powered it back on.)
The impression is that such an arrangement would be useless. I'm not so sure, for two reasons.
First, while desktop PCs are powered on and off regularly, servers are not. Servers are typically installed in data centers and kept on, twenty-four hours a day, every day of the year. If the server stays on, the data stays in RAM, and everything works.
Second, it is possible to build classic RAM SSDs with small, auxiliary power supplies. These small power supplies (usually batteries) can keep the RAM active, and therefore keep the data, while main power is not available.
RAM storage units are not new. They date back to the mid-1970s, and have been used on IBM mainframes, minicomputers, and even Apple II computers.
I suspect that at some point, someone will figure out that classic RAM makes sense for servers, and build SSDs for servers. This will be another step in the divergence of desktop PCs and server computers.
Thursday, December 17, 2015
Indentation and brackets in languages
Apple has released Swift, an object-oriented language for developing applications. It may be that Swift marks the end of the C-style indentation and brace syntax.
Why is indentation and bracket style important? Maybe we should start with a definition of indentation and brace style, and go from there.
In the far past, programs were punched onto cards and the syntax of the programming language reflected that. FORTRAN and COBOL languages reserved columns 1 through 6 for line numbers, column 7 for line continuation and comments, and columns 73 to 80 for card sequencing. (The last was used to sort the card deck when it was dropped and cards spilled on the floor.)
The limitations of the punch card and the notion that one and only one statement may appear on one (or possibly more) cards had a heavy influence on the syntax of the language.
Algol introduced a number of changes. It introduced the 'begin/end' keywords that were later used by Pascal and became the braces in most modern languages. It removed the importance of newlines, allowing multiple statements on a single line, and allowing a single statement to span multiple lines without special continuation markers.
The result was the syntax we have in C, C++, Java, and C# (and a bunch of other languages). Semicolons (not newlines) terminate statements. Braces group statements. Indentation doesn't matter, statements can begin in any column we desire. All of these features come from Algol. (At the beginning of this essay I referred to it as "C-style indentation and brace syntax", but the ideas really originated in Algol.)
The "Algol revolution" threw off the shackles of column-based syntax. Programmers may not have rejoiced, but they did like the new world. They wrote programs gleefully, indenting as they liked and arguing about the "one true brace style".
Some programmers wanted this style:
function_name(params) {
statements
}
Others wanted:
function_name(params)
{
statements
}
And yet others wanted:
function_name(params)
{
statements
}
There were some programmers who wanted to use whatever style that felt comfortable at the time, even if that meant that their code was inconsistent and difficult to read.
It turns out that the complete freedom of indentation and brace placement is not always a good thing. In the past decades, we have taken some steps in the direction of constraints on indentation and braces.
For years, programming teams have held code reviews. Some of these reviews look at the formatting of the code. Inconsistent indentation is flagged as something to be corrected. Variants of the lint program warn on inconsistent indentation.
Visual Studio, Microsoft's IDE for professionals, auto-formats code. It did some with the old Visual Basic. Today it auto-indents and auto-spaces C# code. It even aligns braces according to the style you choose.
The Python language uses indentation, not braces, to mark code blocks. It reports inconsistent indentation and refuses to run code until the indentation is consistent.
The Go language uses braces to mark code blocks and it requires a specific style of braces (the first style shown above). It won't compile programs that use other styles.
We have designed our processes, out tools, and our languages to care about indentation and brace style. We are gradually moving to language syntax that uses them, that considers them significant.
As programmers, as people who read code, we want consistent indentation. We want consistent brace style. We want these things because it makes the code easier to read.
Which gets us back to Swift.
Swift has restrictions on brace style. It uses brace placement to assist in the determination of statements, visible in the syntax for if statements and for loops (and I suspect while loops). Indentation doesn't matter. Brace style does.
We now have three popular languages (Python, Go, and Swift) that care about indentation or brace style. That, I think, shows a trend. Language designers are beginning to care about these aspects of syntax, and developers are willing to work with languages that enforce them. We will not return to the harsh constraints of FORTRAN and COBOL, but we will retreat from the complete freedom of Algol, Pascal, and C. And I think that the middle ground allow us to develop and share programs effectively.
Why is indentation and bracket style important? Maybe we should start with a definition of indentation and brace style, and go from there.
In the far past, programs were punched onto cards and the syntax of the programming language reflected that. FORTRAN and COBOL languages reserved columns 1 through 6 for line numbers, column 7 for line continuation and comments, and columns 73 to 80 for card sequencing. (The last was used to sort the card deck when it was dropped and cards spilled on the floor.)
The limitations of the punch card and the notion that one and only one statement may appear on one (or possibly more) cards had a heavy influence on the syntax of the language.
Algol introduced a number of changes. It introduced the 'begin/end' keywords that were later used by Pascal and became the braces in most modern languages. It removed the importance of newlines, allowing multiple statements on a single line, and allowing a single statement to span multiple lines without special continuation markers.
The result was the syntax we have in C, C++, Java, and C# (and a bunch of other languages). Semicolons (not newlines) terminate statements. Braces group statements. Indentation doesn't matter, statements can begin in any column we desire. All of these features come from Algol. (At the beginning of this essay I referred to it as "C-style indentation and brace syntax", but the ideas really originated in Algol.)
The "Algol revolution" threw off the shackles of column-based syntax. Programmers may not have rejoiced, but they did like the new world. They wrote programs gleefully, indenting as they liked and arguing about the "one true brace style".
Some programmers wanted this style:
function_name(params) {
statements
}
Others wanted:
function_name(params)
{
statements
}
And yet others wanted:
function_name(params)
{
statements
}
There were some programmers who wanted to use whatever style that felt comfortable at the time, even if that meant that their code was inconsistent and difficult to read.
It turns out that the complete freedom of indentation and brace placement is not always a good thing. In the past decades, we have taken some steps in the direction of constraints on indentation and braces.
For years, programming teams have held code reviews. Some of these reviews look at the formatting of the code. Inconsistent indentation is flagged as something to be corrected. Variants of the lint program warn on inconsistent indentation.
Visual Studio, Microsoft's IDE for professionals, auto-formats code. It did some with the old Visual Basic. Today it auto-indents and auto-spaces C# code. It even aligns braces according to the style you choose.
The Python language uses indentation, not braces, to mark code blocks. It reports inconsistent indentation and refuses to run code until the indentation is consistent.
The Go language uses braces to mark code blocks and it requires a specific style of braces (the first style shown above). It won't compile programs that use other styles.
We have designed our processes, out tools, and our languages to care about indentation and brace style. We are gradually moving to language syntax that uses them, that considers them significant.
As programmers, as people who read code, we want consistent indentation. We want consistent brace style. We want these things because it makes the code easier to read.
Which gets us back to Swift.
Swift has restrictions on brace style. It uses brace placement to assist in the determination of statements, visible in the syntax for if statements and for loops (and I suspect while loops). Indentation doesn't matter. Brace style does.
We now have three popular languages (Python, Go, and Swift) that care about indentation or brace style. That, I think, shows a trend. Language designers are beginning to care about these aspects of syntax, and developers are willing to work with languages that enforce them. We will not return to the harsh constraints of FORTRAN and COBOL, but we will retreat from the complete freedom of Algol, Pascal, and C. And I think that the middle ground allow us to develop and share programs effectively.
Tuesday, December 15, 2015
The new real time
In the 1970s, people in IT pursued the elusive goal of "real time" computing. It was elusive because the term was poorly defined. With no clear objective, any system could be marketed as "real time". Marketing folks recognized the popularity of the term and anything that could remotely be described as "real time" was described as "real time".
But most people didn't need (or want) "real time" computing. They wanted "fast enough" computing, which generally meant interactive computing (not batch processing) that responded to requests quickly enough that clerks and bank tellers could answer customers' questions in a single conversation. Once we had interactive computing, we didn't look for "real time" and interest in the term waned.
To be fair to "real time", there *is* a definition of it, one that specifies the criteria for a real-time system. But very few systems actually fall under those criteria, and only a few people in the industry actually care about the term "real time". (Those that do care about the term really do care, though.)
Today, we're pursuing something equally nebulous: "big data".
Lots of people are interested in big data. Lots of marketers are getting involved, too. But do we have a clear understanding of the term?
I suspect that the usage of the term "big data" will follow an arc similar to that of "real time", because the forces driving the interest are similar. Both "real time" and "big data" are poorly defined yet sound cool. Further, I suspect that, like "real time", most people looking for "big data" are really looking for something else. Perhaps they want better analytics ("better" meaning faster, more frequent, more interaction and drill-down capabilities, or merely prettier graphics) for business analysis. Perhaps they want cheaper data storage. Perhaps they want faster development times and fewer challenges with database management.
Whatever the reason, in a few years (I think less than a decade) we will not be using the term "big data" -- except for a few folks who really need it and who really care about it.
But most people didn't need (or want) "real time" computing. They wanted "fast enough" computing, which generally meant interactive computing (not batch processing) that responded to requests quickly enough that clerks and bank tellers could answer customers' questions in a single conversation. Once we had interactive computing, we didn't look for "real time" and interest in the term waned.
To be fair to "real time", there *is* a definition of it, one that specifies the criteria for a real-time system. But very few systems actually fall under those criteria, and only a few people in the industry actually care about the term "real time". (Those that do care about the term really do care, though.)
Today, we're pursuing something equally nebulous: "big data".
Lots of people are interested in big data. Lots of marketers are getting involved, too. But do we have a clear understanding of the term?
I suspect that the usage of the term "big data" will follow an arc similar to that of "real time", because the forces driving the interest are similar. Both "real time" and "big data" are poorly defined yet sound cool. Further, I suspect that, like "real time", most people looking for "big data" are really looking for something else. Perhaps they want better analytics ("better" meaning faster, more frequent, more interaction and drill-down capabilities, or merely prettier graphics) for business analysis. Perhaps they want cheaper data storage. Perhaps they want faster development times and fewer challenges with database management.
Whatever the reason, in a few years (I think less than a decade) we will not be using the term "big data" -- except for a few folks who really need it and who really care about it.
Thursday, December 10, 2015
The types of standards for programming languages
A programming language must have a reference point, a standard, which is used to decide what is in the language and how it behaves. There are different ways to build and distribute this standard:
Independent committee In the past it was an ANSI committee, today it is an ISO committee. The committee, independent of vendors, defines the language and publishes the standard. Anyone can create an implementation of the standard; the committee often provides tests to verify compliance with the standard.
Benevolent dictator A single person decides what is in the language and what is not. He (it is usually a male) runs a team of people who develop the implementation and publish it. The implementation is usually open source. Tests are used by the development team to ensure compliance with the standard. There may be more than one implementation published; the development team may publish advance and legacy versions, and other individuals or companies may publish their own implementations.
Corporate closed source A corporation designs a language and builds and publishes it as a product. The language may change at any time to suit the needs of the corporation. Other entities can publish "clones" of the language but they do not have access to the source code.
Corporate open source A corporation designs a language, builds and publishes it as in the "closed source" model, and then provides the source code as open source. Other entities can use the source code. The language can still change to suit the needs of the corporation.
These four models cover almost all programming languages. Looking at some popular programming languages, the grouping is:
Independent committee: FORTRAN, COBOL, C, C++, SQL, Ada, JavaScript
Benevolent dictator: Forth, Pascal, AWK, Perl, Python, Ruby
Corporate closed source: APL, PL/I, Visual Basic, Delphi, VB.NET, SAS, Objective-C, Objective-C++
Corporate open source: Java, C#, Swift
Some languages change over time. For example, BASIC started as with the "benevolent dictator" model, but Microsoft's success changed the dominate form to "corporate closed source". Java started as "corporate closed source" and is shifting to "corporate open source".
What's interesting is that the languages governed by independent committee tend to have longer lives. Of the seven languages (Fortran, Cobol, C, C++, SQL, Ada, and JavaScript) all but Ada are in use today. (Yes, Ada may be in use somewhere, on some obscure legacy project, but that is true of just about every language. Ada is, for all intents and purposes, a dead language.)
Languages governed by a benevolent dictator fare less well. Python and Ruby enjoy success today, while Perl declines from its previous popularity. Forth, Pascal, and Awk are used rarely and I see no activity, no growth to those languages.
Corporate languages enjoy popularity ... as long as the corporation pushes them. APL and PL/I, developed by IBM, are in the "dead" list. Microsoft's Visual Basic is dead and VB.NET (purported to be a successor to Visual Basic) is languishing. Delphi is used only in legacy applications.
I expect that with Apple's introduction of Swift, Objective-C and Objective-C++ will drop to "dead" status. The Mac OS X platform was the only place they were used. The current index at tiobe.com confirms this drop.
What does all of this mean? For anyone developing a large, long-term project, the selection of a language is important. Committee-governed languages last longer than other languages.
Notice that Java is not a committee-governed language. It is managed by Oracle.
Independent committee In the past it was an ANSI committee, today it is an ISO committee. The committee, independent of vendors, defines the language and publishes the standard. Anyone can create an implementation of the standard; the committee often provides tests to verify compliance with the standard.
Benevolent dictator A single person decides what is in the language and what is not. He (it is usually a male) runs a team of people who develop the implementation and publish it. The implementation is usually open source. Tests are used by the development team to ensure compliance with the standard. There may be more than one implementation published; the development team may publish advance and legacy versions, and other individuals or companies may publish their own implementations.
Corporate closed source A corporation designs a language and builds and publishes it as a product. The language may change at any time to suit the needs of the corporation. Other entities can publish "clones" of the language but they do not have access to the source code.
Corporate open source A corporation designs a language, builds and publishes it as in the "closed source" model, and then provides the source code as open source. Other entities can use the source code. The language can still change to suit the needs of the corporation.
These four models cover almost all programming languages. Looking at some popular programming languages, the grouping is:
Independent committee: FORTRAN, COBOL, C, C++, SQL, Ada, JavaScript
Benevolent dictator: Forth, Pascal, AWK, Perl, Python, Ruby
Corporate closed source: APL, PL/I, Visual Basic, Delphi, VB.NET, SAS, Objective-C, Objective-C++
Corporate open source: Java, C#, Swift
Some languages change over time. For example, BASIC started as with the "benevolent dictator" model, but Microsoft's success changed the dominate form to "corporate closed source". Java started as "corporate closed source" and is shifting to "corporate open source".
What's interesting is that the languages governed by independent committee tend to have longer lives. Of the seven languages (Fortran, Cobol, C, C++, SQL, Ada, and JavaScript) all but Ada are in use today. (Yes, Ada may be in use somewhere, on some obscure legacy project, but that is true of just about every language. Ada is, for all intents and purposes, a dead language.)
Languages governed by a benevolent dictator fare less well. Python and Ruby enjoy success today, while Perl declines from its previous popularity. Forth, Pascal, and Awk are used rarely and I see no activity, no growth to those languages.
Corporate languages enjoy popularity ... as long as the corporation pushes them. APL and PL/I, developed by IBM, are in the "dead" list. Microsoft's Visual Basic is dead and VB.NET (purported to be a successor to Visual Basic) is languishing. Delphi is used only in legacy applications.
I expect that with Apple's introduction of Swift, Objective-C and Objective-C++ will drop to "dead" status. The Mac OS X platform was the only place they were used. The current index at tiobe.com confirms this drop.
What does all of this mean? For anyone developing a large, long-term project, the selection of a language is important. Committee-governed languages last longer than other languages.
Notice that Java is not a committee-governed language. It is managed by Oracle.
Tuesday, December 8, 2015
The PC Market Stabilizes
Once again we have a report of declining sales of personal computers, and once again some folks are worrying that this might signal the end of the personal computer. While the former is true, the latter certainly is false.
The decline in sales signals not an abandonment of the personal computer, but a change in the technology growth of PCs.
To put it bluntly, PCs have stopped growing.
By "PC" or "personal computer" I refer to desktop and laptop computers that run Windows. Apple products are excluded from this group. I also exclude ChromeBooks, smartphones, and tablets.
Sales of personal computers are declining because demand is declining. Why is demand declining? Let's consider the factors that drive demand:
Growth of the organization When a business grows and increases staff, it needs more PCs.
Replacement of failing equipment Personal computers are cheap enough to replace rather than repair. When a PC fails, the economically sensible thing to do is to replace it.
New features deemed necessary Some changes in technology are considered important enough to warrant the replacement of working equipment. In the past, this has included CD drives, the Windows (or perhaps OS/2) operating system, new versions of Windows, the 80386 and Pentium processors, and VGA monitors (to replace older monitors).
The recent economic recession saw many companies reduce their ranks and only now are they considering new hires. Thus, the growth of organizations has been absent as a driver of PC sales.
The basic PC has remained unchanged for the past several years, with the possible exception of laptops, which have gotten not more powerful but simply thinner and lighter. The PC one buys today is very similar to the PC of a few years ago. More importantly, the PC of today has no new compelling feature - no larger hard drive (well, perhaps larger, but the old one was large enough), no faster processor, no improved video. (Remember, I am excluding Apple products in this analysis. Apple has made significant changes to its hardware.)
The loss of these two drivers of PC sales means that the one factor that forces the sales of PCs is the replacement of failing equipment. Personal computers do fail, but they are, overall, fairly reliable. Thus, replacement of equipment is a weak driver for sales.
In this light, reduced sales is not a surprise.
The more interesting aspect of this analysis is that the technology leaders who introduced changes (Microsoft and Intel) have apparently decided that PCs are now "good enough" and we don't need to step up the hardware. Microsoft is content to sell (or give away) Windows 10 and designed it to run on existing personal computers. Intel designs new processors, but has introduced no new "must have" features. (Or if they have, the marketing of such features has been remarkably quiet.)
Perhaps Microsoft and Intel are responding to their customers. Perhaps the corporate users of computers have decided that PCs are now "good enough", and that PCs have found their proper place in the corporate computing world. That would be consistent with a decline in sales.
I expect the sales of PCs to continue to decline. I also expect corporations to continue to use PCs, albeit in a reduced role. Some applications will move to smart phones and tablets. Other applications will move to virtualized PCs (or virtual desktops). And some applications will remain on old-fashioned desktop (or laptop) personal computers.
* * * * *
Some have suggested that the decline of PC sales may also be explained, in part, by the rise of Linux. When faced with the prospect of replacing an aged PC (because it is old enough that Windows does not support it), people are installing Linux. Thus, some sales of new PCs are thwarted by open source software.
I'm certain that this is happening, yet I'm also convinced that it happens in very small numbers. I use Linux on old PCs myself. Yet the market share of Linux is in the one- and two-percent range. (For desktop PCs, not servers.) This is too small to account for much of the annual decline in sales.
The decline in sales signals not an abandonment of the personal computer, but a change in the technology growth of PCs.
To put it bluntly, PCs have stopped growing.
By "PC" or "personal computer" I refer to desktop and laptop computers that run Windows. Apple products are excluded from this group. I also exclude ChromeBooks, smartphones, and tablets.
Sales of personal computers are declining because demand is declining. Why is demand declining? Let's consider the factors that drive demand:
Growth of the organization When a business grows and increases staff, it needs more PCs.
Replacement of failing equipment Personal computers are cheap enough to replace rather than repair. When a PC fails, the economically sensible thing to do is to replace it.
New features deemed necessary Some changes in technology are considered important enough to warrant the replacement of working equipment. In the past, this has included CD drives, the Windows (or perhaps OS/2) operating system, new versions of Windows, the 80386 and Pentium processors, and VGA monitors (to replace older monitors).
The recent economic recession saw many companies reduce their ranks and only now are they considering new hires. Thus, the growth of organizations has been absent as a driver of PC sales.
The basic PC has remained unchanged for the past several years, with the possible exception of laptops, which have gotten not more powerful but simply thinner and lighter. The PC one buys today is very similar to the PC of a few years ago. More importantly, the PC of today has no new compelling feature - no larger hard drive (well, perhaps larger, but the old one was large enough), no faster processor, no improved video. (Remember, I am excluding Apple products in this analysis. Apple has made significant changes to its hardware.)
The loss of these two drivers of PC sales means that the one factor that forces the sales of PCs is the replacement of failing equipment. Personal computers do fail, but they are, overall, fairly reliable. Thus, replacement of equipment is a weak driver for sales.
In this light, reduced sales is not a surprise.
The more interesting aspect of this analysis is that the technology leaders who introduced changes (Microsoft and Intel) have apparently decided that PCs are now "good enough" and we don't need to step up the hardware. Microsoft is content to sell (or give away) Windows 10 and designed it to run on existing personal computers. Intel designs new processors, but has introduced no new "must have" features. (Or if they have, the marketing of such features has been remarkably quiet.)
Perhaps Microsoft and Intel are responding to their customers. Perhaps the corporate users of computers have decided that PCs are now "good enough", and that PCs have found their proper place in the corporate computing world. That would be consistent with a decline in sales.
I expect the sales of PCs to continue to decline. I also expect corporations to continue to use PCs, albeit in a reduced role. Some applications will move to smart phones and tablets. Other applications will move to virtualized PCs (or virtual desktops). And some applications will remain on old-fashioned desktop (or laptop) personal computers.
* * * * *
Some have suggested that the decline of PC sales may also be explained, in part, by the rise of Linux. When faced with the prospect of replacing an aged PC (because it is old enough that Windows does not support it), people are installing Linux. Thus, some sales of new PCs are thwarted by open source software.
I'm certain that this is happening, yet I'm also convinced that it happens in very small numbers. I use Linux on old PCs myself. Yet the market share of Linux is in the one- and two-percent range. (For desktop PCs, not servers.) This is too small to account for much of the annual decline in sales.
Subscribe to:
Posts (Atom)