It turns out that most people who care to comment are, to use the common phrase, creeped out at the thought of not knowing whether they are talking to an AI or a human being. I get that, although I don’t think I’m myself bothered by such a notion. After all, what do we know about people during a casual phone conversation? Many of them probably sound like robots to us anyway.

And this article in the New York Times notes that Google was only able to accomplish this feat by severely limiting the domain in which the AI could interact with – in this case, making dinner reservations or a hair appointment. The demonstration was still significant, but isn’t a truly practical application, even within a limited domain space.

Well, that’s true. The era of an AI program interacting like a human across multiple domains is far away, even with the advances we’ve seen over the last few years. And this is why I even doubt the viability of self-driving cars anytime soon. The problem domains encountered by cars are enormously complex, far more so than any current tests have attempted. From road surface to traffic situation to weather to individual preferences, today’s self-driving cars can’t deal with being in the wild.

You may retort that all of these conditions are objective and highly quantifiable, making it possible to anticipate and program for. But we come across driving situations almost daily that have new elements that must be instinctively integrated into our body of knowledge and acted upon. Computers certainly have the speed to do so, but they lack a good learning framework to identify critical data and integrate that data into their neural network to respond in real time.

Author Gary Marcus notes that what this means is that the deep learning approach to AI has failed. I laughed when I came to the solution proposed by Dr. Marcus – that we return to the backward-chaining rules-based approach of two decades ago. This was what I learned during much of my graduate studies, and was largely given up on in the 1990s as unworkable. Building layer upon layer of interacting rules was tedious and error-prone, and it required an exacting understanding of just how backward chaining worked.

Ultimately, I think that the next generation of AI will incorporate both types of approaches. The neural network to process data and come to a decision, and a rules-based system to provide the learning foundation and structure.

Let’s face it, to most developers, databases are boring and opaque. As long as I can create a data object to call the database and bring data into my application, I really don’t care about the underlying structures. And many of us have an inherent bias against DBAs, for multiple reasons. Years ago, one of my computer science graduate students made the proclamation, “I’m an engineer; I write technical applications. I have no need for databases at all.”

I don’t think this is true anymore, if it ever was. The problem was in the predominance of SQL relational databases. The mathematical and logical foundation of relational databases is actually quite interesting, but from a practical standpoint actually setting up a database, whether through E-R diagrams or other approach, is pretty cut and dried. And maintaining and performance tuning databases can often seem like an exercise in futility.

Certainly there were other types of databases and derivative products 20 or 30 years ago. My old company, Progress Software, still makes a mint off its OpenEdge database and 4GL environment. Sybase PowerBuilder was popular for at least two decades, and Borland Delphi still has a healthy following. OLAP engines were available in the 1990s, working with SQL relational databases to quickly extract and report on relational data.

But traditional relational databases have disadvantages for today’s uses. They are meant to be a highly reliable storage and retrieval system. They tend to have the reliable part down pat, and there are almost universal means of reading, writing, modifying, and monitoring data in relational tables.

The world of data has changed. While reliability and programming access of relational databases remains important in traditional enterprise applications, software has become essential in a wide variety of other areas. This includes self-driving cars, financial trading, manufacturing, retail, and commercial applications in general.

Relational databases have been used in these areas, but have limitations that are becoming increasingly apparent as we stress them in ways they weren’t designed for. So instead we are seeing alternatives that specialize in a specific area of storage and retrieval. For example, the No-SQL MongoDB and MapReduce in general are making it possible to store large amounts of unstructured data, and to quickly search and retrieve data from that storage. The open source InfluxDB provides a ready store for event-driven data, enabling applications to stream data based on a time series. Databases such as FaunaDB can be used to implement blockchain.

All of these databases can run in the cloud, or on premises. They tend to be easy to set up and use, and you can almost certainly find one to meet your specific needs.

So as you develop your next ground-breaking application, don’t find yourself limited by a relational database. You’re not stuck in the same rut that you were ten years ago. Take a look at what has to be called the Golden Age of databases.

I was 13 years old, at Forbes Field, and rose with the crowd as Roberto Clemente hit a walk-off home run in the ninth inning to win an important game in the 1971 World Series hunt. Clemente was a very good hitter for average, but had relatively few home runs. He delivered in the clutch, as we say.

Moneyball ultimately works in baseball because of the importance of individual achievement in the outcome of games, and the length of the season. 162 games enables carefully thought out probabilities to win out over the long haul.

But teams practicing Moneyball learned that analytics weren’t enough once you got into the postseason. Here’s the problem. Probabilities are just that; they indicate a tendency or a trend over time, but don’t effectively predict the result of an individual event in that time series. Teams such as the Boston Red Sox were World Series winners because they both practiced Moneyball and had high-priced stars proven to deliver results when the game was on the line.

Machine learning and advanced analytics have characteristics in common with Moneyball. They provide you with the best answer, based on the application of the algorithms and the data used to train them. Most of the time, that answer is correct within acceptable limits. Occasionally, it is not. That failure may simply be an annoyance, or it may have catastrophic consequences.

I have disparaged Nicholas Carr in these pages in the past. My opinion of him changed radically as I watched his keynote address at the Conference for the Association of Software Testing in 2016 (this talk is similar). In a nutshell, Carr says that we can’t automate, and trust that automation, without first having experience with the activity itself. Simply, we can’t automate something that we can’t do ourselves.

All events are not created equal. Many are routine, but a few might have significant consequences. But analytics and AI treat all events within their problem domain as the same. The human knows the difference, and can rise to the occasion with a higher probability than any learning system.

Learning systems are great. On average, they will produce better results than a human over time. However, the human is more likely to deliver when it counts.

When I was taking graduate computer science classes, back in the late 1980s, we spent some time talking about SIMD and MIMD (Single Instruction Multiple Data and Multiple Instruction Multiple Data) computer architectures, with the inevitable caveat that all of this was theoretical, because of the Von Neumann Bottleneck. John Von Neumann, as students of computer science know, was a renowned mathematician who made contributions across a wide range of fields. In a nutshell, the Von Neumann Bottleneck defined processor architecture in such a way that the bandwidth between the CPU and memory is very small in comparison with the amount of memory and storage available and ready for CPU use.

I’ve recently returned from Supercomputing 2012, and I’m pleased to say that while we are not breaking the Von Neumann Bottleneck, new computing architectures are bending the heck out of it. You can argue that the principle of parallel processing addresses the bottleneck, and parallel processing is so mainstream in the world of supercomputing that it barely rates a mention.

Programmers are well aware that writing parallel code is difficult and error-prone; we simply don’t naturally think in the sort of way that provides us with parallel ways to solve problems. But with multiple processors and cores, we end up with more busses between memory and processor (although it’s certainly not a one-to-one relationship).

Because writing parallel code is so difficult, there are a growing number of tools that claim to provide an easy(ier) path to building parallelism into applications. One of the most interesting is Advanced Cluster Systems. It provides a software solution called SET that enables vendors and engineering groups with proprietary source code to easily parallelize that code. In some cases, if the application is constructed appropriately, source code may not even be required.

In addition to parallel processing, we can look to other places for moving more data, and more quickly, into the processors. One place is flash storage, which becomes virtual memory for an application, with only the working set loaded into main memory. FusionIO offered a partial solution to that bottleneck with a flash memory storage device that was software-configured to act as either storage or an extension of main memory, with separate busses into the processor space. The advantage here is that program instructions and data can be stored on these flash memory devices, which then have direct access to main memory and processor space. The single bus isn’t such a bottleneck any more.

All of this doesn’t mean that we’ve moved beyond the Von Neumann architecture and corresponding bottleneck. But it does mean that we’ve found some interesting workarounds that help get the most out of today’s processors. And as fast as we think computers are today, they will be far faster in the future. We can only imagine how that will change our lives.

When PC software development meant working in MS DOS, programmers had to make a choice between using the small, medium, or large (and later huge) memory models. These models required the use of different structures and pointers, and added an additional layer into architecting an application. They had to do with the fact that Intel 80XXX processors segmented memory addressing into 64KB chunks. Crossing a segment extracted a performance penalty, so you wanted to minimize the number of times you had to do that. In time, it made software design more convoluted than it needed to be.

Fast-forward about ten years or so. Intel 32-bit processors were able to abstract over this legacy structure, but the fundamental segmented architecture still exists under the covers. Intel recognizes that it’s messy, and could possibly limit processor designs in the future.

So it starts over again, with a 64-bit processor called the Itanium (and later, Itanium 2). I had a dog in this hunt; around 2000 Intel contracted with Compuware’s NuMega Lab, where I was a product manager, to make Itanium versions of its acclaimed SoftICE and BoundsChecker developer tools. The Itanium used a completely different instruction set, but Intel implemented the x86 instruction set in microcode on top of it for the sake of backward compatibility.

It should also be noted at HP, shedding itself of its PA-RISC and DEC Alpha processor families, needed a high-performance replacement architecture, and invested heavily in Itanium systems and software.

As it turned out, there was no real business reason for reengineering the industry standard processor architecture. It was an engineering decision, to make a better design, rather than to rally users around. Intel spent billions of dollars over several years because its chip designers wanted something better than they had.

The Itanium was actually slower running x86 code than the best x86 processors at the time. Other than HP, few system manufacturers adopted it. And when AMD showed the way to 64-bit extensions to the x86, Intel made the same leap with the legacy processor architecture.

I’m reminded of this story by an ongoing lawsuit between HP and Oracle surrounding the availability of the latter’s flagship database on HP’s Itanium systems. Oracle would like to cease supporting the Itanium, and cites HP’s substantial financial support to Intel to keep the Itanium alive.

I have no opinion on the lawsuit, except that it seems like a waste of good time and money. But the story of the Itanium is of a project in which engineering triumphed over market requirements. And it turned out badly for Intel, as well as HP and others. If you build it, they won’t necessarily come.

As a young adult, I was intrigued by computers, but didn’t have that focus to actually learn more about them. A part of the problem was that computers were largely inaccessible to individuals at the time, and I lacked the ability to purchase one early in life.

So I largely missed out on the Commodore 64 revolution. Sure, I had friends with them, but we mostly played games; I first encountered Zork on a Commodore 64. I used timesharing systems in undergraduate and graduate school, but my first computer was an original 128KB Apple Mac (which I still have, and which still boots). Commodore remained in business until the 1990s with the popular though niche Amiga, eventually folding for good.

Now it seems that the Commodore 64 is rising from the dead. It looks like a Commodore 64, with only a keyboard in a small form-fitting console. The original Commodore 64 had an eight-bit processor, 64 kilobits of memory, and required external units for display and storage.

This unit, manufactured by a licensee of the name called Commodore USA, is basically providing a low-end Intel machine in the Commodore 64 form factor. It includes an Intel Atom processor, Nvidia graphics, an HDMI port, and optional Wi-Fi and Blu-ray drive. A new and potentially interesting distro of Linux is promised, but not yet available, so the company may initially ship Ubuntu Linux. Alternatively, once you get one, you can load Windows on it, but it doesn’t come with a Windows license.

The announced price is $595, the same as the original Commodore 64. The linked article above describes how the most difficult part of the process was replicating the exact color of the case, and the enormous cost in doing so.

It’s potentially an interesting concept if it had a functional niche. As it is, it’s a PC; Linux, it’s true, but a PC nonetheless. The niche seems to be simply nostalgia for my generation, to remind us that we were young once, when the world was simple and we played computer games. Commodore USA thinks they can sell a lot of them, simply with the name and an exact replica of the system case.

I’m not nostalgic. I know there are people who will buy into this, but it simply doesn’t make any sense to me. A computer is a tool, not an icon (well, you know what I mean). It doesn’t get style points (unless it’s from Apple). I imagine that some will be sold, but the attraction will wear off as the technology ages still further. Um, just like its buyers.

NVIDIA reminds me that its GPU Technology Conference is 11 weeks away (I submitted a proposal to speak; I’ll certainly mention if it’s accepted). It’s September 20-23 at the San Jose Convention Center in San Jose, CA. In the meantime, the company is hosting a Live Chat series, featuring high-profile GPU technology personalities. Each Live Chat is 30 minutes long and open to the public. This is a great opportunity for anyone interested in GPU computing to get some virtual one-on-one time with the industry’s top GPU scientists, researchers and developers.

The first Live Chat first guest is Ian Buck, inventor of the Brook project and CUDA. He’s currently Software Director of GPU Computing at NVIDIA. Ian’s talk at GTC last year, From Brook to CUDA, highlighted a perspective on how GPU computing has evolved and what the current innovations are in GPU technology. During his Live Chat, Ian will give a preview of his GTC talk and will be taking questions about the future of CUDA and GPU computing.

I attended this conference last year, and found it to be one of the most energetic and informative conferences I have attended in many years. You can tell the state of a particular technology by the enthusiasm of the attendees, and this conference has all the earmarks of a celebration for a significant new technology.

So says this article on MSNBC.com. Actually, it refers to them as constitutional issues, which I suppose they are, in a broad way. But while they can likely be overcome without changing the Constitution, they should be in the back of the mind of anyone using or advocating cloud computing.

Here’s the deal (disclaimer: I’m not a lawyer, so take what I say with appropriate skepticism). Let’s say you work for a company that does some computing in your data center, but also lease server time in the cloud. It turns out that current US legal practice is that any data inside your data center requires a search warrant to access; the data in the cloud generally requires a subpoena to the cloud provider.

The difference is a big one. As we learned years ago when various Web sites propagated information that was proprietary or incorrect (or sometimes merely annoying to its target), it took relatively little effort to shut it down. A court order to the ISP was typically sufficient, a result of a petition to a court and no trial or even representation by the accused party.

We make a legal distinction between things kept at a physical location we can call our own, and things placed outside of that location. Law authorities can’t come into our homes or offices, or look at our records, without a warrant (whether or not authorities don’t occasionally deviate from that standard is a different story, and not mine to say). That also works for a remote data center where we own or even rent the servers; we have ownership of the physical container.

That’s different in cloud computing. We rent server time, not the server itself. The box remains firmly in control of the cloud provider; our code just so happens to run on it. Do we know how our cloud provider will respond if someone shows up at the door with a subpoena or search warrant?

This is what virtualization has wrought.

Surely this is no different than the mainframe timesharing systems of three decades ago. After all, that’s where virtualization was invented (I was a VM/MVS programmer for a brief time in my career). That’s true, but what we are doing on computers today is much more interesting and important in the grand scheme of things, and more people have a better understanding of it.

And it’s not just a corporate issue. Many of us use Gmail or one of the other Web-based email services; the same principles, or lack of principles, apply. Same with social network sites.

It is important enough so that a wide variety of corporations, public interest groups, and individuals have created Digital Due Process. As the name implies, its goal is to apply the same expectations we have concerning searches in physical locations to virtual locations.

This may or may not have a lot of impact on our lives right now, but often new laws, or new interpretations of existing laws, take a long time to come to fruition. And we would like to know that the data we store under our names on far-away servers has similar protections to the that on the computer right in front of us.