TweetFollow Us on Twitter

May 93 - The Future of OOP: One Man's Crystal Ball

The Future of OOP: One Man's Crystal Ball

Jeff Alger

This year marks a turning point in the object-oriented community. A future that seemed so clear and so certain until recently is now clouded by a haze of conflicting products, markets, and philosophies. Although no one can claim to have perfect vision of the future, I will give it a try, and the right place to start is not by looking forward, but backward at the history of our industry. For, as the saying goes, "those who do not learn the lessons of history are doomed to repeat them."

Lessons from the History of OOP

In the 1970's, a small, talented group of researchers at a place called the Xerox Palo Alto Research Center, or PARC, invented the personal computer and with it, the first true object-oriented programming language, Smalltalk. Computer hardware wasn't far enough along for their invention to be practical. Xerox as a company wasn't ready for it. And there really wasn't much of a perception in the software community that there was a need for it, anyway. Remember that at that time database technology and information engineering were just coming into their own and minicomputers were sprouting like weeds. So the Star workstation and Smalltalk languished, in my opinion more because the market didn't see the need than because of any failure of Xerox to follow through.

Soon thereafter, a brash young entrepreneur named Steve Jobs visited the PARC labs and turned what he saw into the Lisa computer. It flopped, again because it was ahead of the curve on hardware and there was no groundswell of support for new ways of developing software. Even when the most egregious problems of the Lisa were corrected in the Macintosh, it was a hard sell for Apple Computer to convince the public that new techniques were needed, especially after IBM weighed in with its own personal computer. The IBM PC was certainly less imaginative than the Macintosh, but it was closer to traditional architectures both in terms of hardware and software, so it was easier for the systems community to gets its hands around. A toy mainframe that sold because it reminded people of the real thing.

About the time of the Macintosh and Lisa, a small group within Apple recognized the potential, not just of the human interface and hardware aspects of what the PARC group had created, but of the software techniques they had used to program their machines. Object-oriented software seemed such a natural way to handle an iconic, event-driven graphical user interface that they created in succession Object Pascal, the Lisa Toolkit, the original MacApp, even an abortive Smalltalk for the Macintosh. There was talk even of object-oriented operating systems, objects from soup to nuts. Their work was only mildly influential in determining the course of Macintosh software development tools, as we saw a steady progression of procedural operating systems, languages, tools and techniques. How many people are aware that as recently as three and a half years ago, at a time when the then-MacApp Developers Association had about a thousand members worldwide, that there were only two - count 'em - engineers in all of Apple working on MacApp?

Apple had the option of going object-oriented all the way at any time up to the advent of Multifinder. There are those that disagree with me, but I and many others there at the time feel that had they done so, there would have been no need for a Taligent today and we would perhaps already be programming to the tune of Rhapsody in Pink. But even within Apple, champion of new ideas, counterculture of the computer industry, conservatism won; there were just too many people who did not even see the problems, let alone the value of object-oriented solutions.

But I'm getting ahead of myself. Across the continent, squired away in an obscure corner of Bell Telephone Laboratories, a fellow by the name of Bjarne Stroustrup spent his time writing software to simulate… exactly what, I don't know, but the Labs have always done a lot of simulations work. He used a language called Simula, an offshoot of Algol designed specifically to simulate real-time stochastic processes and arguably one of the first true object-oriented languages before that term had been coined. But Bell Labs did other things beyond simulations. And like any large organization, they developed software in a variety of languages: COBOL, Fortran, and lots of obscure languages like Simula and Snobol. The breakup of the phone system was forcing all of AT&T to think about new ways of making money and Unix looked a good bet. But there was a problem: how could AT&T tell everyone else in the world to use Unix and its companion language, C, if they themselves weren't? So, the order came down from on high: henceforth, all software will be written in C. Now, I have heard conflicting stories as to whether this order directly prompted Stroustrup to migrate to C or whether it merely built a critical mass that made C more acceptable as a delivery vehicle. It doesn't matter, because AT&T just wasn't interested in any language that wasn't C. C++, as with most other object-oriented innovations, was ignored by its own company. Today there are many within AT&T that speak of the fish that got away.

Wherever you look, the history of object-oriented technology has not been pretty. Microsoft was smart enough to recognize an object-oriented image problem when they saw it. Windows is as object-oriented as one can get without an object-oriented language, yet nowhere in the early literature of Windows was the term "object" even used. They recognized the merits of the approach but realized that few others did. Operating systems designers have been doing what could arguably be called object-oriented programming - attaching function vectors to packets of data - since the 50's but remain, perhaps for the very reason that they've done so well without, curiously skeptical of the need for object-oriented languages. Computer scientists have been pushing the use of abstract data types - encapsulating data behind functional interfaces - for decades but no one in the commercial arena has been there to listen, with the singular exception of Ada. Even in the rarefied world of databases, where challenges to the data-driven approach are quickly shown the door, the trend has been strongly toward what arguably could be called object-oriented architectures. Call them triggers, stored procedures, or what have you, but the fact remains that modern data modeling requires associating functions with packets of data, the core concept of OOP. Yet, few in the database community are willing to call a spade a spade: most so-called "object-oriented databases" are, in fact, nothing more than glorified network or relational models that support complex data types, and many so-called "object-oriented methodologies" are nothing more than recycled information engineering.

Even today, with magazines, training classes, programming languages, conferences, college curricula and associations devoted to object-oriented technology, it is easy to get fooled into thinking that the war is won and that the ramparts themselves are now object-oriented. The problem is that OOPers tend to talk mostly to other OOPers and forget how much resistance there is to the idea outside our own mutual support group. Well, as one who advises companies on these issues, I can tell you that outside our own ranks OOP is still viewed as either snake oil or a silver bullet, but not as a practical tool for solving everyday problems.

Throughout its history, OOP has been the Rodney Dangerfield of software: it gets no respect.

There are, of course, reasons for this history, and they are important to understand if we are to anticipate the future, for there is little reason to think they are about to change after all this time. Throughout, little emphasis has been laid on solving real problems that translate to real market share. That is, the OOP community has tended to be internally focused, developing great ideas and products and only then trying to convince the world that there is a need for them. Accompanying this has been more than a little arrogance, especially in waiving off the very real concerns of managers everywhere: integration with existing systems and techniques; leveraging skill sets already in place; having measurable, controllable and repeatable processes rather than a few smart people locked in a room arguing with each other. In Marketing 101 they teach you what happens when you try to bully the market. I am reminded of the story of the then-Chairman of the Great Atlantic and Pacific Tea Company being approached earlier in this century about sponsoring a Sunday afternoon radio show. He declined, saying that he doubted anyone would listen during that time slot. After all, everyone he knew played polo on Sunday afternoon. Well, everyone I know in the object-oriented community thinks polymorphism is really important.

Wild, unsubstantiated and often patently false claims have been made about the benefits of object orientation. Where, for example, are the case studies of large-scale code reuse to back up all the popular literature on the subject? Why, if this is so "natural," did the organizers of OOPSLA a couple of years ago feel compelled to hold a panel on the subject, "Why Is Object-Oriented So Difficult?" And why, if the payback is so quick and dramatic, is it quietly understood in the OOP community that it takes two years to develop a good object-oriented engineer?

We have done a very poor job of articulating why technology managers should believe us when, like Charley Brown running up to kick the football every fall only to have Lucy once again yank it away at the last second, they have been consistently let down by other, similar, claims in the past. A good friend of mine, John Brugge of IDS Financial Services, circulated a paper in his company explaining the relative merits of object-oriented technology. It spoke of dramatic increases in productivity, lower maintenance costs, better results, higher quality. Reading the paper at his urging I felt it to be quite mainstream, the sorts of claims to be found throughout the literature on the subject. After five pages, however, the paper broke off in mid-sentence. "…I can't go on with this. This really is not my paper." He explained that the paper was, in fact, from a book by Edward Yourdon from the 1970s that dealt with the structured programming revolution; John had literally done a bulk search-and-replace of "object-oriented" for "structured" and otherwise left the wording unchanged. Little wonder that we are viewed with suspicion.

Another problem has been a lack of focus. 75% of development costs, and an even higher percentage of software lifecycle costs, are tied up in analysis and design but, as Yourdon points out in his new book, "The Decline and Fall of the American Programmer," the OOP community seems stuck in the backwaters of code. Even within that limited domain the focus has tended to be more on piling feature after feature into the syntax of languages while giving short shrift to the problems that really consume programmer time: memory management, debugging, object persistence ("you mean you actually want to store your data?") and integration with non-OOP technologies. Even worse, OOP has often been the excuse used for working without any methodology whatever. I call this the "Brilliant Pebbles" approach to software development, named after the Strategic Defense Initiative program of the same name, because it relies on training a few smart people to hurtle themselves at oncoming problems. Little wonder that people don't want to trust us with critical projects.

Finally, and to me this is the most important, the OOP community seems to lurch about from place to place because it is largely blinded to the real reason it exists. Have you ever stopped to wonder why all major components of the software community - systems programming, simulations, theory of algorithms, database, artificial intelligence and human factors - have drifted in the same direction independently of one another? It was not until the advent of C++ that there was even much talk between these groups, and then it was to argue over details. It cannot be random chance. Clearly there is some underlying force guiding this evolution, and it is squarely this: Our systems and systems development efforts are so complex today that they are limited by grayware, the stuff of the human. Put simply, we have reached the point where our own ability to understand what we are doing and what we have done is the principle constraint on software development. To quote Pogo, "We have met the enemy, and it is us." Yet, this isn't a very comfortable subject to talk about because it takes us out of the ivory tower world of formal grammars and correctness proofs and into the various "soft" disciplines that come under the general heading "Cognitive Science." And when we look under that rock, we may see something that makes us uncomfortable. Maybe, just maybe, object-orientation isn't really as natural as all that, even if it is an improvement. Maybe, just maybe, the history of computer science did not, after all, stop with the advent of objects. Maybe we've just positioned ourselves for even harder work to come.

It is important to take this look backward at the history of object-oriented technologies to understand where we are likely to go in the future. There is by now enough experience with the technology to see many of its limits. Eventually, market forces will be heard whether we listen actively or cover our ears, and that will force the OOP industry to face a series of problems we've collectively swept under the rug until now.

Problem-solving Focus

First and foremost in the coming years the OOP community will become more focused on customers and problems, not technology. It has to. There are only so many executives and purchasing managers willing to buy technology and stunning leaps of faith, and as one who advises them I can tell you that even they are starting to turn up their radios to mask the noise. There are many ways to segment the potential market for OOP: small vs. large, commercial products vs. in-house, standalone systems vs. networks and groupware, GUI vs. … what is the antonym for GUI, anyway, "slick"? …, leading edge vs. mainstream, data-intensive vs. process-intensive… I could go on for some time without pausing for breath. In each case there are clearly identifiable customers and needs that we can and will address without dwelling so much on what Neal Goldstein and I like to call OOTB: object-oriented technobabble.

There are two specific companies I would like to single out in this regard. There is much that I admire about the way Taligent is approaching the future, but I think their greatest strength is their grasp of these market forces. Ten years from now when the definitive history of Taligent is written, whatever success they achieve will be attributed more to their business acumen than their technology. Tiny Component Software is another company that has done a good job of positioning themselves as solvers of specific business problems, rather than as a vendor of "YAOOL": "yet another object-oriented language." It is companies like these that we should study and emulate.

The Problem With Classes

As the OOP community enters the second phase of its business cycle, there is growing recognition that classes, inheritance and polymorphism may not be the miracle cures many thought them to be. There is increasing talk of the more general mechanisms of delegation and aggregation. Deep class hierarchies are definitely passé. Inheritance brings with it inherent problems with modularity and code reuse when compared to delegation models.

Classification is also losing its luster as a way of building semantic models, not least because the hard evidence in the cognitive science community is that grouping things according to the properties they share - the foundation of classes - is a distinctly unnatural way for humans to describe their world.

At the same time, we are rapidly coming to a good understanding of how humans really group concepts, a subject known as "categorization" in the cognitive science community. Our groupings turn out to be far more than random. They are consistent enough to allow children all over the world to learn languages in pretty much the same ways and to allow for a large number of what the linguists call "universals," grammatical constructs common to all known languages. Their structures are much more complex than simple classification can easily represent, but that should be no surprise; the artificial intelligence community came to that conclusion in the 1970's. The object-oriented community just hasn't bothered, it would seem, to hit the literature before asserting the "naturalness" of classification. But the real point here is that as we learn more about human cognitive processes, we will also find ways to more directly represent them in software. Objects, but not classes, will play an important role in that next step.

Visualization

Another frontier of object-oriented and non-object-oriented software development is to learn how to properly visualize information. I must betray a bias here, for much of my own work has been in this area. To develop our own notational system, the Visual Design Language, Neal Goldstein and I did what we felt was the natural thing: we engaged the help of an expert in graphic communication. The entire emphasis from day one was on communicating. Not painting pretty pictures (though that turns out to be important to comprehension and retention) and not expressing every technical concept that comes along, but real communication. That means minimizing loss and distortion of information. Increasing comprehension and retention rates for project documents. One can easily show by experiment that comprehension and retention of typical software documentation is an abysmal 10%-20% for most forms. We must not just capture information, but also make it understandable and useful. One of my favorite anecdotes is of the kindergartner who came home from school one day and announced excitedly, "Mommy, I learned how to write in school today!" "That's great," replied the proud mother. "What did you write?" "I don't know, I can't read yet." In software development, we are great at accumulating documents we can't read or understand.

This is almost pure grayware. And it is far less than rocket science to trace the sort of path Neal and I took. There are entire industries based on the premise that one can communicate better through visualization.

To give you some idea of how primitive software notational systems generally are by the standards of the experts, let me relate our first meeting with our graphics consultants. We came to the session armed with what we thought were the best features of several leading object-oriented notational systems. I won't name names because my point is not to embarrass particular competing approaches, but you can well imagine what such a short list would look like. Our graphics consultants looked hard at them and… laughed. Really. They accused us of deliberately presenting the worst possible visualizations from the competition and wanted something more representative. We had already chosen what we thought were the best! As we worked with them I came to understand their perspective for myself. I also came to appreciate that they are at least as good at their jobs-visual communication-as we are at ours.

But before we can even get to visualizations, the industry must recognize the need. Isn't it remarkable that browsers for object-oriented development tools-for that matter, most software development tools-are still based on text? We know that people deal poorly with text as a general rule. The time is drawing near when we will no longer consider ourselves exempt from the rules that seem to guide the rest of the human race in this regard. Already there are some noteworthy contributions to visualization of software: Microsoft's Visual Basic and Prograph. There is also no end of notational systems for analysis and design, object-oriented and not. But they have yet to take the one step that really counts: go to the experts in graphic communication and ask their advice.

Death of the Application

One common feature of advanced dynamic languages such as Smalltalk and Lisp is that one does not so much develop an "application" as extend the one, the only, "environment." Take Macintosh Common Lisp as a good example. An "application" is really nothing more than an alternative menu bar within the development environment. For that matter, you can create an arbitrary number of "applications" by this same stratagem. The application as a unit of software engineering disappears in this environment, leaving only user interface paradigms to justify the term.

This is powerful as far as it goes, but imagine now entire machines and even networks in which there are no applications per se, just bundles of objects firing off messages to one another. A world where even menu bars and windows are assembled from components on the fly, discarding the last vestige of applicationness. I call this environment "object soup," a vast sea of memory thinly populated by occasional lumps we call objects.

Well, get ready, because this is coming faster than you think. There are already several companies at work on this and the first generation of real object-oriented operating systems are just over the horizon.

This reveals the application for what it has always been: an anachronism of our operating systems. But before you get too excited, stop and think for a moment about what kind of problems this approach might invite along to the dinner party. Throughout the history of the computer industry, we have set budgets, organized projects and deliverables, trained and rewarded employees, and defined products according to this single concept of the "application." To drop the application like a hot rock just isn't realistic, if for no other reason than that we have nothing to put in its place. Instead, we are in for a prolonged and wrenching period of readjustment, in which we must rethink our concepts of methodology, project management, software economics and the software lifecycle. It is certain that many people will be left behind by this sea change and that huge and powerful entrenched interests will oppose it altogether. (I stole that from a recent Wall Street Journal editorial, but I think it appropriate here.) It is not even clear that object soup can win in the end, though I think it can. This is the classic yin and yang of new technology: the new problems will hurt many but also bring tremendous opportunities for innovation and entrepreneurship to those who can handle the change.

Death of the Linker

Speaking of anachronisms, why do we still have linkers? Especially in the world of objects, where there are so many ways to dynamically link one object or class to the rest. The traditional coding cycle - run/test/change source/compile/link/go for a walk/run again - just doesn't make any sense anymore. The technology of dynamic languages has progressed to the point where traditional objections have been or soon will be silenced: performance, application size, and shrink-wrapping of applications. It will become increasingly difficult for development tools vendors to justify why they, too, haven't caught the dynamic wave. I give the linker only a few more years.

Reuse (of Analysis and Design, That is)

Way too much attention has been directed at the idea of code reuse. Who cares? Coding is a period in the novel of software development, and it's shrinking all the time. The bulk of software development dollars go to analysis, design and maintenance, not code. Even if we completely eliminated the need for code, it would only reduce overall lifecycle costs by perhaps 10%-15%, and that is a pretty generous estimate. I don't know anyone who believes we will obviate the need for programming even in the best of reusable worlds, so invariably the market for software techniques will refocus on the pot of gold: reuse of analysis and design.

There are many reasons to think this is possible, many more than the often flimsy justifications given for investing heavily in code reuse. First, much of analysis and design is independent of particular machines and languages, but code is, at some point, always dependent on both. Second, tremendous industry-specific expertise is already available in academia, management consultancies, and within industries themselves. This expertise is tugging at the chains of current technology, trying to find new delivery vehicles. The same cannot be said of code; we don't do it very well to begin with and that which is done well isn't very well understood. Third, object-oriented analysis and design, despite their stutter steps in infancy, hold the potential to replace textual documents with diagrams. What's the big deal about diagrams? Look beyond the pretty pictures: those are a specialized form of data model, used to modularize analysis and design information. Once information is expressed in this form, it becomes possible to pick and choose pieces and reassemble them into new works, something that does not work well if one has to copy/paste paragraphs from a textual document.

Object Bases

One of the principle contributions of the data modeling era was to make practical a philosophy that data are really corporate assets, not just project assets. In fact, databases have been the only real success story in the world of code reuse and the success has been spectacular. Yet, in all the literature of data modeling one cannot find an adequate answer to a simple question: what's so special about data? What about processes? Can't they and shouldn't they, too, be treated as corporate assets? The answer to these questions is that data is special in only one sense: we've figured out how to consolidate data and the same traditionally hasn't been true of processes. But that is a limitation of our techniques, not anything inherent in data or processes. Object orientation goes a long way toward bringing sharing of processes up to the same level.

Object-oriented approaches have the potential to enable this rethinking of the role of process modeling in an organization. I call this the "corporate assets" model of object-oriented software engineering. Instead of databases we will soon see the emergence of corporate object bases. The problems should not be taken lightly: we still don't know how to optimize queries against a database of objects that may use polymorphism to change the ways values are computed or stored; methodologies have yet to really come to grips with this objective without compromising the benefits of object-orientation by using what has been derisively called "recycled information engineering." I think our own methodology, Solution-Based Modeling, has a good headstart, but there is much work to be done. But the potential is clearly there and it remains only to see more efforts directed at a concept that has enormous potential benefits.

Standards

Finally, I expect the future to bring a new emphasis on standards on several fronts, especially where object technology enables standards in related fields. How much longer can it be before we finally have a single, widely accepted standard for graphics environments? Other than the fact that some are 2D and others 3D, there really isn't enough difference in the major offerings of today to support several competing standards. Object orientation is likely to be a catalyst for this convergence because of its ability to conveniently implement abstractions of interfaces while preserving machine-specific details. It may be awhile before similar standards take hold for multi-media software development, but those, too, can be expected to emerge and consolidate over time.

Graphical user interfaces are another area ripe for consolidation. There is a lot of sniping these days over competing GUIs but be honest, now, is there really that much difference, personal and corporate allegiances aside? Certainly not enough to support several competing standards in a world where most shops develop for more than one platform. Again, OOP is uniquely poised to drive competitors either together or out of business.

Object persistence and distribution over networks is another area that will eventually standardize, though progress may be slow until operating systems come shipped with de facto treatments. At that time, the few major approaches are likely to be made at least interoperable, if not identical.

No, I did not omit languages by mistake. It is the one area in which I do not expect to see standards emerge beyond the dominance of C++, the COBOL of the 90's. Languages have always evolved to address the problems of the day; as the problems change, so do the languages. This will not change. In particular, I expect decreasing emphasis on inheritance and more emphasis on delegation and aggregation, something not very well addressed by any of the major OOP languages of today. And, as I said earlier, visualization will play an increasing role in the way we create programs in the future.

How to Prepare for the 90's

Let me conclude with some observations about who the winners and losers will be should my crystal ball not prove too out of focus. Anytime a major change takes place, there is lots of money to be made in training, consulting, and publications. This will be as true for the coming generation of object-oriented technology as it was for databases in the 70's and 80's. Programming will be quite different, not just in content and process but in perception as well and organizations will have to spend heavily on technology assimilation. The ones who will make the most money are the ones who figure out earliest how to price and sell products in the age of object soup. There are really no economic models for this market, so a few people will have to blaze the trail while the rest follow. However, as with most innovations, it is the people that follow closely behind the leaders who will gain the most, armed with business acumen and a keen eye for what is catching. There may well be a couple of Bill Gates or Steve Jobs waiting to reap their fortunes, but overall those Harvard MBAs always seem to make the most money while technical innovators get the pats on the back. To those of you who are technologists, I say, "Hire those MBAs before they hire you." Fortunes will be made in reusable, shrink-wrapped analysis and design "packages" expressed using the paradigm of objects, especially to those who figure out first how the market for such products will work. But above all, those who accurately read the deep-rooted conservatism of the industry will be far more successful than those who come charging in the front door with guns blazing. OOP will still be the Rodney Dangerfield of the industry; we'd better get used to it and learn to make money, anyway. All in all, it should be a very interesting decade.

Copyright © 1993 by Jeff Alger. All rights reserved.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

BBEdit 11.1.1 - Powerful text and HTML e...
BBEdit is the leading professional HTML and text editor for the Mac. Specifically crafted in response to the needs of Web authors and software developers, this award-winning product provides a... Read more
CrossOver 14.1.3 - Run Windows apps on y...
CrossOver can get your Windows productivity applications and PC games up and running on your Mac quickly and easily. CrossOver runs the Windows software that you need on Mac at home, in the office,... Read more
Little Snitch 3.5.3 - Alerts you about o...
Little Snitch gives you control over your private outgoing data. Track background activity As soon as your computer connects to the Internet, applications often have permission to send any... Read more
OmniGraffle Pro 6.2.3 - Create diagrams,...
OmniGraffle Pro helps you draw beautiful diagrams, family trees, flow charts, org charts, layouts, and (mathematically speaking) any other directed or non-directed graphs. We've had people use... Read more
OmniFocus 2.2 - GTD task manager with iO...
OmniFocus helps you manage your tasks the way that you want, freeing you to focus your attention on the things that matter to you most. Capturing tasks and ideas is always a keyboard shortcut away in... Read more
Cocktail 8.4 - General maintenance and o...
Cocktail is a general purpose utility for OS X that lets you clean, repair and optimize your Mac. It is a powerful digital toolset that helps hundreds of thousands of Mac users around the world get... Read more
PDFKey Pro 4.3 - Edit and print password...
PDFKey Pro can unlock PDF documents protected for printing and copying when you've forgotten your password. It can now also protect your PDF files with a password to prevent unauthorized access and/... Read more
Kodi 15.0.beta1 - Powerful media center...
Kodi (was XBMC) is an award-winning free and open-source (GPL) software media player and entertainment hub that can be installed on Linux, OS X, Windows, iOS, and Android, featuring a 10-foot user... Read more
DiskCatalogMaker 6.4.12 - Catalog your d...
DiskCatalogMaker is a simple disk management tool which catalogs disks. Simple, light-weight, and fast. Finder-like intuitive look and feel. Super-fast search algorithm. Can compress catalog data... Read more
Macs Fan Control 1.3.0.0 - Monitor and c...
Macs Fan Control allows you to monitor and control almost any aspect of your computer's fans, with support for controlling fan speed, temperature sensors pane, menu-bar icon, and autostart with... Read more

Moleskine Timepage – Calendar for iCloud...
Moleskine Timepage – Calendar for iCloud, Google & Exchange 1.0 Device: iOS iPhone Category: Productivity Price: $4.99, Version: 1.0 (iTunes) Description: The most elegant calendar for your pocket and wrist, Timepage is a... | Read more »
QuizUp Gets Social in its New Update
Plain Vanilla Corp has released a new and improved version of their popular trivia game, QuizUp. The app now emphasizes social play so you can challenge friends from all over the world. [Read more] | Read more »
The Deep (Games)
The Deep 1.0 Device: iOS Universal Category: Games Price: $1.99, Version: 1.0 (iTunes) Description: Swipe Controls Delve into the deep in this retro rogue-like! Swipe to move your diver around and keep away from the enemies as you... | Read more »
Battle of Gods: Ascension (Games)
Battle of Gods: Ascension 1.0 Device: iOS Universal Category: Games Price: $2.99, Version: 1.0 (iTunes) Description: TURN-BASED TACTICAL COMBATFight tactical battles against the forces of Hades! In Battle of Gods: Ascension you play... | Read more »
Shadowmatic's Latest Update Adds a...
Shadowmatic's shadowy shadow-ness is getting a little shadowy-er thanks to a recent update that adds an Arcade Mode. [Read more] | Read more »
Sunrise Calendar and Slack Have Assimila...
Wunderlist is perhaps one of the most populat and beloved productivity apps on the App Store - and now it's gone and incorporated itself into other useful services like Sunrise Calendar and Slack. [Read more] | Read more »
Crossy Road Devs Hipster Whale are Bring...
Hipster Whale, the minds behind the rather popular (and rather great) Crossy Road, have teamed-up with Bandai Namco to create PAC-MAN 256: an absolutely bonkers looking maze runner chaser thing. | Read more »
Meet the New Spotify Music
Spotify Music  has a lot going on. They're introducing 3 new modes to serve all your musical needs, with the "Now" start page  gives you curated playlists based on your particular tastes. As you listen the app will learn more about your tastes and... | Read more »
What the Apple Watch Gets Right, and Wha...
| Read more »
Celebrate PAC-MAN's 35th Birthday W...
BANDAI NAMCO Entertainment America is celebrating PAC-MAN's 35th anniversary by releasing updates for PAC-MAN and PAC-MAN Lite for iOS. [Read more] | Read more »

Price Scanner via MacPrices.net

Apple refurbished 2014 13-inch Retina MacBook...
The Apple Store has Apple Certified Refurbished 2014 13″ Retina MacBook Pros available for up to $400 off original MSRP, starting at $979. An Apple one-year warranty is included with each model, and... Read more
What Would the ideal Apple Productivity Platf...
For the past four years I’ve kept a foot in both the Mac and iPad camps respectively. my daily computing hours divided about 50/50 between the two devices with remarkable consistency. However, there’... Read more
PageMeUp 1.2.1 Ten Dollar Page Layout Applica...
Paris, France-based Softobe, an OS X software development company, has announced that their PageMeUp v. 1.2.1, is available on the Mac App Store for $9.99. The license can be installed on up to 5... Read more
Eight New Products For USB Type-C Application...
Fresco Logic, specialists in advanced connectivity technologies and ICs, has introduced two new product families targeting the Type-C connector recently introduced across a number of consumer... Read more
Scripps National Spelling Bee Launches Buzzwo...
Scripps National Spelling Bee fans can monitor the action at the 2015 Spelling Bee with the new Buzzworthy app for iOS, Android and Windows mobile devices. The free Buzzworthy app provides friendly... Read more
13-inch 2.5GHz MacBook Pro on sale for $120 o...
B&H Photo has the 13″ 2.5GHz MacBook Pro on sale for $979 including free shipping plus NY sales tax only. Their price is $120 off MSRP, and it’s the lowest price for this model (except for Apple’... Read more
27-inch 3.3GHz 5K iMac on sale for $1899, $10...
B&H Photo has the new 27″ 3.3GHz 5K iMac on sale for $1899.99 including free shipping plus NY tax only. Their price is $100 off MSRP. Read more
Save up to $50 on iPad Air 2, NY tax only, fr...
B&H Photo has iPad Air 2s on sale for up to $50 off MSRP including free shipping plus NY sales tax only: - 16GB iPad Air 2 WiFi: $469 $30 off - 64GB iPad Air 2 WiFi: $549.99 $50 off - 128GB iPad... Read more
Updated Mac Price Trackers
We’ve updated our Mac Price Trackers with the latest information on prices, bundles, and availability on systems from Apple’s authorized internet/catalog resellers: - 15″ MacBook Pros - 13″ MacBook... Read more
New 13-inch 2.9GHz Retina MacBook Pro on sale...
B&H Photo has the 13″ 2.9GHz/512GB Retina MacBook Pro on sale for $1699.99 including free shipping plus NY tax only. Their price is $100 off MSRP, and it’s the lowest price for this model from... Read more

Jobs Board

*Apple* Solutions Consultant - Retail Sales...
**Job Summary** As an Apple Solutions Consultant (ASC) you are the link between our customers and our products. Your role is to drive the Apple business in a retail Read more
*Apple* Watch SW Application Project Manager...
**Job Summary** The Apple Watch software team is looking for an Application Engineering Project Manager to work on new projects for Apple . The successful candidate Read more
Engineering Manager for *Apple* Maps on the...
…the Maps App Team get to take part in just about any new feature in Apple Maps, often contributing a majority of the feature work. In our day-to-day engineering work, we Read more
Senior Software Engineer - *Apple* SIM - Ap...
Changing the world is all in a day039s work at Apple . If you love innovation, here039s your chance to make a career of it. You039ll work hard. But the job comes with Read more
Lead *Apple* Solutions Consultant - Retail...
**Job Summary** Job Summary The Lead ASC is an Apple employee who serves as the Apple business manager and influencer in a hyper-business critical Reseller's store Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.