 Hi, everyone, and thank you so much for joining us today. My name is Amanda Carl. I'm part of the IBM Research Communications Team, and I'll be your host today. We're looking forward to a lively discussion about the future of quantum software development. This panel is actually the first in a series of panels related to quantum computing that we'll be hosting throughout the summer. Before we get started, though, I did just want to acknowledge the new virtual reality we find ourselves in in the wake of the COVID-19 pandemic, and we hope each of you is safe and healthy wherever you are. With that said, I do want to take a quick minute to run through a couple of items and reminders for today's discussion. Throughout the event, you'll have the ability to submit questions for the panelists. If you'd like to address a specific panelist, please indicate who your question is for. You should see a little Q&A window on your screen, and that's where you can submit your questions. We definitely encourage you to submit your questions throughout the panel discussion, and we'll save the last 10 minutes or so to address as many as we can. For any questions we don't get to, or follow-ups that are required, please just work with your IBM representative, and we will get back to you and arrange time with some of the panelists afterwards. Within the next 24 hours, we expect that we'll be able to share the playback of the event, and we'll also send over to each of you via email any other relevant resources related to today's talk. With that said, I'm going to go ahead and turn it over to today's moderator, Foresters Jeffrey Hammond, Vice President, Principal Analyst, Serving CIO Professionals. Jeffrey? Thanks, Amanda. It's great to be here today. So as I've been starting to look at quantum technology, it's really been interesting. I've been in the application development space for almost 30 years now as a developer. I've built developer tools, and for the last 14 years, I've been at Forester Research Writing for application that developers and software professionals. And for those of us that are in the enterprise, a lot of times we view the relentless march of software technology as just something that we deal with and we learn about, and we get new disruptive changes, whether it's mobile or the cloud or AI, and we deal with them, we figure them out, and then we use them productively. It's easy to look at quantum that way and say, hey, it's just another long string of technologies that we have to deal with and learn. But when you dig into it and start to look at it, there's also the idea that it might be a pretty disruptive change, I mean, a major change in the way that developers have to think about technology and work with it. And so one of the things I'm hoping to do today from my own edification is to unpack some of that with folks who are far smarter than I am with respect to quantum technology, but I think are able to bring it down to the level of an enterprise developer or an executive that is running a large business. So with that, I'd like to start with introductions and why don't we go to you first, Dr. Narangpreet, would you like to introduce yourself? Absolutely, hi, thank you for having me here. My name is Prené Hanarek, almost no one calls me that, so you're welcome to call me Pry. I am on the faculty here at Harvard and I'm also the CTO and co-founder of Alira. So excited about all things quantum and excited to tell you about some of them here today. Thanks for being here. Now, I know our second guest today because I met him years ago when we were both talking about mobile application development technologies. Merlee, you want to say hello and tell me how the heck you got from building iPhone applications to running a company that is looking at quantum applications of technology? That's great. So I'm Merlee, I'm the founder and CEO of StrangeWorks. It's simple. Jeffrey, I see this in the same way I saw, if you think back to that iPhone dev camp where we got everybody together a week after it came out with the 400 or so developers and Steve Jobs at the time saying there'd be no apps, there'd be no stuff. I see this changing even more dramatically all areas of science and research and our livelihoods just like we saw, and it's by the way, it's the same team that did the last two companies just like we saw the mobile stuff all the way back in 2006, 2007 before there were app stores or anything. And so I think there's 23 million developers worldwide and I'd like to democratize this as much as possible and make it as accessible to everyone so that we're not going to try to win a Nobel Prize with any quantum stuff. We're not going to ever probably be recognized for any of the very small quantum talent we have, but we might be a catalyst for everybody else and that's my focus. So I'm bringing all of the Linux Foundation, Apache, Nagios, iPhone dev camp, all of that kind of stuff to quantum in an effort to fulfill that. Cool. Well, we're glad to have you here today. Our last panelist today is Blake Johnson. Blake, do you want to say hello? Yeah, thanks for bringing us together. So I'm Blake Johnson. I am the lead of control systems area at IBM Quantum. I'm a relatively recent IBMer just joined last year, but I've been working on quantum computing essentially my entire adult life and control systems is an interesting area, particularly because it is immediately points to one of the areas that quantum technology is different from classical processors because in your classical processor, your control and your bits are co-located and the quantum processors, at least once we build today, these things are separated by many meters of cable. So my team is responsible for effectively executing the quantum program, which means converting the user, the developer's intent of what they want to happen into the electrical signals that make that happen on the qubits themselves. So if I had to grossly simplify, you build the digital to quantum converters? That's right. We're at the classical quantum interface in some ways to orchestrate all the electrical signaling that needs to happen to make the quantum compute work. Cool. So when I think about a technology like this that is potentially so disruptive as a developer, I look for hooks and I look for patterns and I look for ways to kind of translate what I know to the new world. And hopefully I can find something that helps me understand it a little bit better. And so for my first question, I wanna start with you Blake, because I noticed in your history, you've worked with quantum programming languages. So I know programming languages, at least a few. What is a quantum programming language? Is it just Python with a few set of libraries or is there something that is distinct to that space? And so as a developer, what do I have to know to be able to use a quantum programming language? It's a great question. So my colleagues recognizing that there was something maybe intimidating about quantum when they first started, chose to develop first a graphical interface, a graphical drag and drop way to build quantum circuits where they're kind of the fundamental unit of quantum compute. So that is available today in IBM quantum experience where you can drag and drop gates, which are the logical operations that manipulate qubits, which are quantum bits to build up a program. But that's a great way to learn and you can kind of get intuition about how a quantum circuit operates with that way. But for more real tasks, you need a real programming interface. And so we have a Qiskit, which is an open source quantum computing framework, developed at IBM, which is a Python interface for building quantum circuits and for building algorithms that take advantage of quantum processors. Why is Python a preferred language for quantum programming? Are there other options as well? Pre, whirling? Pre? All right, stop. Do it. Okay, go ahead. Go ahead, no. Go ahead. No, please you. So I think as we're thinking about programming various different quantum computers, part of what I like about Qiskit is that it's very, very accessible. I find students asking me, hey, how do I go in and do something complicated sounding? But if it's just Python, I can get in there and make something happen. I think the challenge is with that abstraction, you lose a lot of the control over the actual hardware. So maybe you don't necessarily have all of the tools that'd be available if you could directly program the system. So the pulse level control that IBM has made available, it's certainly a good way to bridge that. I wonder if as we go towards other types of hardware, not just superconducting circuits, how some of the programs that are written for superconducting circuits would be translated to those. And if everything is not based off of the same pulse level control scheme, what would be a good way of translating? And I don't have an answer to this, and maybe Worley does, but yeah, that's just something I wanted to add, building on what Blake just said. No, I mean, I don't have an answer to that. I mean, our approach is, of course, is to let all of the languages battle it out. We're big Qiskit fans. I say that not because we're on IBM, but when we first started, same reason. There was already a community, there's tons of people working with it. We're big supporters, slash soon to be making our first contributions to it. But I think, we have to focus when you think about developers and you think about, you can't take a developer and make them a quantum developer overnight. If you go back when I first launched a company in 2018, I got on the stage at South by, and that was the goal. And about six months later, that goal was much harder. And about a year into it, it was like there's just some things that are fundamentally different. So for example, if I'm programming on any other platform that's possible in the world, and I run into that error, like you described, Jeffrey, and I say, oh, I've got an error with this. I can find it or I know how it works. Whereas, what we see happen with developers coming over is, they get in and they can instantiate a teleportation thing through Microsoft Kata's or IBM Qiskit or whatever. And then the moment it breaks, if they don't understand the fundamental physics behind it, then they're kind of at a dead end, right? So it's very interesting. It sounds like low code developers when they try to use low code tools and they break out of the machine, you know? Both of us got that, Jeffrey, but yeah, I mean, it is. And so I think our approach has been to build a spanning layer across hardware and software that's agnostic. So, pre could put solutions in it, Blake and his team would say, oh, here's a pulse control, whatever, to kind of let the technologies kind of float to the top. And then this is what we've seen in our history, right? This is what you saw when the NCSA was gonna like, we're gonna make a web server that costs $5,000 and Apache was like, no, we're gonna give one away for free and then development communities build. And sometimes you have conflict, right? I mean, IBM had Watson and Google's battle was to try to take all these developers from, you know, and put them in TensorFlow to build that as a solution. So, you know, we're trying to be a little bit more Switzerland. We see everybody in the space as collaborative. And as far as developers go, I just think it's really no, it's the programming language question and what tools are becoming popular is important. But it's important to realize there's 23 million developers in just like Apple's ecosystem. There's probably 40 million worldwide. And when you think of the enterprise, there's a much bigger gap than, oh, are you using Python or, you know, some other language or whatever. I mean, there's a fundamental relearning and retooling that developers are gonna have to do in order to take advantage of these machines. So let's poke at that as I was looking at it. And again, I'm a guy who, you know, when I dig into it and the first thing I see is, oh, you know, here's some linear algebra for you. I'm like, okay, we didn't have that in college. So this may be a little challenging. But, you know, one of my takeaways was that for the last 50 years, we've essentially been thinking in zeros and ones in digital computing, you know, essentially two states. And fundamentally, what we're going to is what 26 states in the qubit or something like that. So, you know, is it essentially moving, re-imagining computing as we know it and moving away from the fundamental digital technology here so that eventually we don't have these digital to quantum converters anymore. And we have a domain-specific language that understands how to write these circuits. Is it that big of a change or is it simpler than that? I think it's a bit simpler than that. I mean, still fundamentally when you read out a qubit, you still get a binary answer, right? So there's still zeros and ones in the interface. But the state of the world today when you go to use a quantum computer is kind of like the analogy to classical computers. Someone wanted to do classical programming and someone handed them a watchable engineer textbook saying, this is how you put together flip-flops and latches to build a name here. You don't need to know that to program, but that's kind of where we start with quantum computing. We need to exit that model, right? Yeah, so abstraction is key. Right. There are also, I think a lot of things that are, you know, not yet possible with hardware, but we take for granted in classical computing. So, you know, thinking about conditional statements and intermediate measurements, not something that is trivial to do in a quantum circuit at the moment, certainly not in a superconducting circuit, but that's going to be very important to write more complex quantum programs in future. And as those advances come from the hardware side, what we think about is how do you translate those into something that you can use on the software side? And it's not so obvious how you take advantage of, say, intermediate measurement or how you use the fact that, you know, you might have a very large circuit, but you could train on a smaller circuit and then use that to know something about this larger circuit. There's a whole bunch of interesting stuff. Could be done, but it's not yet done. I mean, I think, you know, I... Go ahead. Go ahead, Geoffrey. I was just gonna say, I mean, I think, you know, you have to realize where we're actually at. We're not in the days of AMD versus Intel. We're in the days of like little mechanical gates versus like vacuum tubes and other solutions. And so, you know, these things aren't computers in, you know, from my like kind of pure developer standpoint, at the moment of time, they're really great equipment for exploring the quantum landscape that are the foundation to building machines. But all the things preset and Blake said, I agree. I mean, I think you need layers of abstraction. And I think there's even a question of, at what point is a gate so complicated that a developer is never gonna touch it or understand it anyway? Is that a thousand, you know, is it a hundred thousand? Is it a million? Cause you hear people, you know, the press goes crazy with all these stories about, you know, millions of qubit machines and all this stuff. And it's like, yeah, if you had it, you know, my question is who would program it? Cause that sounds really difficult based on where we're at and where we're trying to go. Right. And how do you benchmark or validate an outcome, right? So as you get to more complex circuits, you're not even the largest supercomputers that are struggling, right? And you can say, well, I want, you know, six months of time on this system. And sure, somebody might give you that for one circuit, but not regularly. So how do you know what your computing is actually real? Well, Priya, I think, you know, I think, you know, the answer to that, which is I write a classical solver that's highly optimized, but then I don't optimize the quantum components. Sure. That's a joke. Exactly. I mean, the benchmarking is something that's missing that is going to be hugely impactful to developers and to enterprise developers, especially trying to build solutions. So if we're at that early stage, I'm curious, why are you involved now for the, you know, kind of mainstream inflection point? You know, when you go back to the mobile space where early when Jobs unveiled the iPhone and said, wow, you can use web style technologies to build apps for it. That was a level of abstraction that 23 million developers could say, okay, I can use this now. And you just said, we're not there yet. So why spend time with it now? I mean, well, it wasn't, right? Because remember what Steve said, right? So he said, there's not going to be any apps. And if there are, you're going to get them from us, right? And what we'll let you do is we'll let you do stuff that already happens on the web. And so there was a little bit of a disconnected ecosystem there that they got over much faster than we will in quantum. But why am I here? The best way to invent the future, you know, to predict the future is to be part of the invention of it. So we're looking, you know, for most of the people on the team, this is our third startup together, building large scale, you know, kind of platforms. And we wanted something that was a big challenge. We are not trying to sell a company in a year, flip it or do some other thing. Like this is, this is, this is our last startup. And we're going to do something impactful on humanity. Like Keatec Moon was for fun and profit. It was awesome. Honest dollar helped, you know, change savings in America, which was great. We found out the mythical founder is kind of this myth. We needed a big problem space that had a lot of problems that was disconnected from the normal kind of Oda feedback loop that happens. And quantum's there. I mean, most of the people building machines aren't actually talking to developers. They're talking to physicists who can download development tools and they're playing the world of developers. And I think what you're going to see is when you reach that, okay, we've got a purpose for it. And now we want it, it's going to blow up. When you see that inflection point in this, you're going to quickly find that, you know, software developers, not necessarily the greatest physicist and physicist, not all the greatest software developers either, right? It's like, you know, a physicist downloading a, you know, pie torch or something and saying like, we're ready to ship this is equivalent of, you know, I wrote quantum computing for babies. So clearly I am a quantum physics expert, right? And that is not nothing can be farther from the truth. I mean, this is the moment to be involved, to drive this to a point where it's not exclusive, it's inclusive, to drive it to a point where it's not 200 people who can program the machines. It's, you know, 2 million people, all of the things that will make, you know, the world a better place. I believe this is the first real leap, you know, and then in the next 10 years, computing will change more than it has in the last 100. I believe that, you know, quantum is the thing I'm placing the bet on is being that exotic computing technology that brings about that change. And, you know, I've got young kids and I want to see the world be a better place. And so why would you not take your experience and get in there? Sure. Word is in your mouth here and see if you agree with it. It sounds like you think that quantum is a truly revolutionary change in computing technology. 100%. I mean, I think we're stepping away from a lot of the classical von Neumann type stuff. I think it provides a bunch of, I think it's a limited problem set, but I think those are really big problems that are super important to kind of the human condition, if you will. And yeah, that's what drives us to get into this. That's what's driving us to try to do this. And that's why we're playing more of a, even though we're a company, we've got investors or for profit, we look more like an open source project, just trying to get as many people involved and as many people collaborating as possible, right? And try to be a catalyst to really bring about that change. Brian Blake, would you agree with that assessment? This is revolutionary change, not evolutionary change? Pretty hard for us. Yeah, yeah, I agree with that. And I want to add to the point with, people being interested in programming quantum computers that don't have physics backgrounds. I see a lot of computer science students here at Harvard say, hey, I'm a really talented computer scientist. I've interned with companies and I want to know the bare minimum amount of physics, such that I can start programming a quantum computer. And that's an interesting experience to see some of those students enter the field and actually realize how much you need to know about the hardware. And I think we'll see a major change from that in the near future. And yeah, we're already seeing, I think a lot of valuable problems being solved on small-term quantum devices is a really nice result and paper from Bravi and the IBM folks that I was just announced in major physics. I think that we know that near-term devices will show us a quantum advantage. We know that there are problems that people have been trying to solve for decades. There are problems in condensed matter, in chemistry, holy grail problems that are now actually within reach. And 10 years ago, you just said, hmm, sure, someday we'll have a quantum computer and life will be better, but that's not going to happen. So we got to keep going on this trajectory we're on. And I think we're on a fundamentally different trajectory now. So yeah, go ahead, Blake. So before I ask my next question, I just want to let the folks that are online know that if you have questions that you want to ask, you can ask them in the Q&A panel and we'll get a chance to put them up to our panelists when we get a little bit further into today's session. But I want to go back to what you just said about the quantum advantage. Anybody want to care to hazard a prediction as to what type of timeframe we're looking at until we see the first quantum advantage for a specific workload? Is it two years? Is it five years? Is it seven years? What do you think? And I'm not sure. What we, the problem is that we don't know exactly how powerful a quantum machine needs to be in order to get to quantum advantage. We've committed to and have been on a track of doubling quantum volume every year. We just put up our, made a publicly available the first machine with a quantum volume of 32 back in April. And already since that first one went up, we now have eight machines with quantum volume of 32 that are available in the IBM quantum experience. And we continue to march along that path of doubling. At what point is it a powerful enough machine for quantum advantage? We're not sure, but I would say personally, I'd be surprised if we have to get all the way of fault tolerance to find a single application where you can do something with advantage, whether from its time cost or whatever against the cost of resource. I mean, I think it's an unfair question, Jeffrey, because you're asking Thomas Watson in 1943, like, hey, how many computers do you think the world will need? He's gonna be like four, like no more than four for sure. Yeah, exactly. I mean, that's the thing is, I think Blake made a good point. It's like, if you're in this industry, if you wanna be a developer in this industry, it needs to be a long-term kind of play, a long-term vision you have, because what I always tell people is, it's like that old Viking saying about sales, right? pessimist thinks it's 20 years out, the optimist think it's three years out. And the reality is, if you wanna be involved in it, you should be preparing now, because all I can tell you is at some point between tomorrow and some future tomorrow, Blake and his team or pre-inher team or somebody is going to connect all the right pieces, and that is gonna go up and you're gonna hit that quantum advantage. And when that happens, it will be too late to be like, now I'm very interested in being heavily involved in this space, because I think it's gonna take off incredibly fast. I'll translate that to say, you think there's gonna be a very steep inflection curve once we hit that quantum advantage point? Look, I'm writing a white paper on it now. My prediction is the inflection point based on a hundred years of computing technology is going to be steeper than any inflection point we have ever seen. It's gonna make the internet hitting corporate America look silly. It's gonna look like that took forever for them to adopt by comparison. It's gonna be a very, very, very steep inflection point. I mean, I think this actually is connected a bit to the developer experience we've been talking about, right? Those of us that build hardware understand that the most critical thing that's preventing us from reaching quantum advantage is the call to the hardware. And so our first tools we built were really focused at those domain experts to giving them the tools that they needed to build better hardware. And that's an important audience. We will continue to make better and better tools to serve that audience. But as Prie mentioned, people are doing applications research with the devices ZIX today and are finding, they maybe can't yet solve a system, problem better than they go with a classical resource, but they can solve problems. And they're starting to figure out what the limitations are, how they can squeeze out the most utility out of the devices is today. And then they're getting ready for the devices that will exist tomorrow. And so we're starting to build tools that try to lower these barriers to entry for those people that are doing applications, that are doing applications development, right? Not the domain experts, but a new audience. And we want the tools, we don't want them to have to learn everything about quantum computing in order to be able to get started. So our team is actually with our last Qiskit release made a first step towards a vision of really bringing the tools to the language that an application developer understands. And I don't necessarily just mean a programming language, but really the language of the problem they're trying to solve. So actually Amanda, could you pull up the graphic on how it works for the optimization module? So in our last Qiskit release, we introduced a new optimization module. And the idea here was to try to reach out to this new audience of developers that can program, they can write their program by describing the problem that they wanna solve. In this case, an optimization problem. So they can write down like a quadratic formula. They can write down some description of the constraints of their optimization problem. They can choose different solvers in both quantum solvers and classical solvers because a lot of these developers are trying to answer this question exactly like what is the value today? How does the quantum work versus the classical? But based on that choice of solver type, they send that workload to the IBM cloud. And then we distribute it to the appropriate quantum or classical hardware and deliver the result back. So I think this is maybe the first time that you can use a gate-based quantum computer where you program it just at the level of what is at the problem interface as opposed to at the circuit interface. So this is a level of abstraction above the circuit? Absolutely. I mean, for this particular case, like I mean, you can compare different solution methods, but you're not actually programming gates. You're programming your problem. So what I hear you doing here is starting to talk about the abstractions in the quantum world that create the language that we'll end up talking about as we write software as developers. So we've got circuits. We've got these higher-level constructs as well for specific domains like optimization. Do these things end up becoming open-source GitHub libraries? Do they become things that you get in a quantum app store? How do developers begin to share this sort of information or take advantage of it? I mean, open-source I think is a critical piece to accelerating these kinds of developments because we want these tools to be available to the broadest audience possible. And open-source is a great accelerator for making that happen on the fastest time scales. We're a long way off from the app store experience where on my phone, I can get an app that takes advantage of quantum resources, but I think we're not that far away from the developer equivalent of that, which is package management systems that I can just say pip install or brew install, some package, which is a quantum library for some application domain. And so the goal is to come back to something worthy of said at the beginning about the equivalent of the iPhone experiences today. I might be an iPhone developer and I want to develop a new app that needs to like an augmented reality app that tracks, I wanna track the position of a basketball. That itself has a non-trivial machine vision task, but we don't ask every iPhone developer to be a machine vision expert. They plug in index code that they wanna use ARKit, which is Apple's augmented reality solution, and off they go. Like they get something in which can do that thing without them being like a machine vision expert. We need to get to that point and I don't think it's that far away where a developer can use quantum resources without having to be an expert in quantum computing. Yep, and that's super important to that inflection point, right? I agree a hundred percent. If you think back to 2007, okay, there were 400 of us a week later with iPhones and people hacking on them. When you think about that, it went to tens of thousands almost instantly, right? Within six months to a year. And then over the course of 10 or 11 years, you get to 23 million people who are doing that. And that mass of developers being involved drives exactly what Blake just said. And that's part of what we really wanna be a part of driving, which is, if you look at something like Shor's algorithm, okay, there's five steps, but step four is where the quantum, the non-deterministic magic is, right? I mean, I could write an iPhone app to stick with that analogy. It can tell you if it's an even at our number, so fast it'd be a waste of time and money to run that on a supercomputer or a quantum computer. So Blake makes a really good point. I think pre, and I have a similar view on that as well. I'd love to hear what her opinion is on that, but it's like you have to have a mass of developers to do that, to do that. That's where quantum competing faces its biggest challenge. When it gets out into what I call kind of out of the lab into the real world, and all of a sudden there's a million developers who are like, hey, I got a question for you. Why doesn't it do this? Or why do I have to do that? And it's like, there's gonna be a lot of work that needs to be done at that point. And that's gonna be a big, big wake-up call for everyone, including us in quantum computing because think developers rarely use things in the exact way they were intended to be used, right? They will find the bugs, they will find the weaknesses, they will find the problems. And so the faster we can get to that point, Blake is describing the better. I mean, pre, what are your thoughts on that? Yeah, we've certainly noticed, especially as we're taking some of the circuits we run on superconducting to trap time and realize that somethings don't work the same way. And you forget about developers breaking things in new ways. Even experienced people break things in ways they didn't anticipate and have to call an engineer and say, hey, how do I fix this? And I think if we expect a million developers entering the community to have answers from an expert engineer, that's probably not a very scalable model. So something that could be useful is of course having better simulators that people can try more things on, especially simulators that allow you to replicate some of the noise associated with current hardware, see how things are performing. Also simple stuff, like getting runtime estimates, getting, you know, a year and a like, is your circuit going to actually fit on the device you're trying to run it on? That's a problem I've seen a lot of people have. They have a beautiful idea and they assume that it can run on this really tiny device. You're like, that could have been done slightly differently. So I think there's like different levels to how do we make it easier for developers who are entering the field to get there? Of course, some of the educational content that IBM has developed is of course, very helpful towards that as well. You're introducing people to how do you do open quantum systems on a quantum device? I think you guys the only ones who make that available. Or how do you think about various types of molecules and mapping them onto a quantum device? So I don't want to say here that those are the only ways that people would use a quantum device, but giving people an idea of, you know, your problem is well suited for a device that looks like this or your problem is better suited for advice that looks like that. Like a simple answer like that might be helpful. I don't know if I answered any of your questions, but. You did, you did. I actually had a question from Michael Brooks in the UK, and I'm going to go ahead and ask that here. Pre, you mentioned that some things are less easy to implement on the superconducting circuit. And the question is how far developers from not having to necessarily worry about what they're doing and whether or not it's going to work in a quantum environment or not. So when do we see guide posts that kind of tell us what workloads are going to work or what loads of workloads are not going to work or that we don't necessarily have to care about matching that. Right. Yeah, so it's not only, I guess, the workload, but also, you know, trap time is all to all that has its own challenges. Not all superconducting systems can or will be all to all. So how do you discretize a problem such that it can one on those different topologies? I think that's an interesting question. We, you can imagine, you know, coming up with simple figures of merit with known types of circuits and saying, you know, this type of circuit in our experience has run better on a system that, you know, looks as follows. But I don't know in terms of very, very general guide posts, if you could say, you know, if you have a circuit that looks like this, it will always run on a superconducting circuit with X fidelity. I think that answer might be harder than saying, hey, you might want to simplify this part of your circuit in order to actually run on the device you're trying. So. Well, we have an explosion of different types of machines and, you know, that, you know, there's going to be this complexity of matching circuits to hardware or, you know, will we get to essentially the quantum equivalent of Intel, you know, Spark and, you know, arm pretty quickly. So that's a tricky question. I'm trying to see how to answer it without making all of my colleagues angry at me. But I suspect this is my personal view that there will be certain problems that will run just fine on a variety of hardware and some that might be more specialized to particular types of hardware. And that's just associated with the physics that is underlying that type of hardware. And this will be especially important as we try and map problems from condensed matter and chemistry onto some of these devices. We'll see that not everything is ideal or even possible for all kinds of problems. But we don't have that kind of experience yet. There are only a few different Traptite systems out there. It's very hard to get access to those and not many of them have gone the route that IBM did with making at least the smallest devices available very, very broadly. So there's a whole lot more that needs to be done on a simulator before you can actually try it on girl hardware. And of course, systems like Cold Atom or Photonic Circuits are really, really niche. So getting time on those is very expensive and almost unaffordable for the average developer out there. So the best you can hope to offer to them is say, hey, if you write something that works on this genre of systems, we can get you to a point where it runs on other systems. And that's something that Starbatterfly Group is trying to accomplish at the moment. You also want to tell people, especially a customer like the Air Force, that if you write and spend a lot of energy developing something that nobody else can see or nobody else can touch that runs at this particular type of hardware and it goes away, that work is not all wasted. So these are questions that have come up in many conversations. I'm sure Raleigh has more to say about this. That's a really, I agree. You kind of threw her the question bomb there, which I was kind of glad for. That's a little, it's not an unfair question, but it's a very pointed question. But the thing is, think of it this way. I have on my desk an iPhone and iPad and a 16 inch laptop, okay? And those things can all do email and they can all surf the web and they can do them really well. But I can't open Xcode and compile a big program on my iPhone. And I probably don't want to do that on my iPad either. So as these technologies advance and as the experimentation advance, there's going to be unlikely discovery. It's going to be like, quantum is going to be like the Wright brothers. It's like they didn't discover flight. There were hundreds of people working on that, right? But they made a three-axis device and all of a sudden now they didn't crash and that helped everybody. There's going to be hundreds of those in quantum computing and it's going to take it in directions that none of us can imagine. It would be, it would be foolish to try. And there's even already 16 startups I'm following who are making quantum processors for specific applications, exactly like pre-described where the like, this is just going to be quantum for this one very, you know, vertical industry or even for a subsection in a vertical industry. And so, you know, I think my follow-up was we're going to see I'm kind of anticipating your follow-up, right? Yeah, I kind of, yep. Does that become a specific, hardwired piece of hardware or is that something that you can configure and tune to match that workload? Blake, I mean, you're probably in the middle of this. What, you know. I think there's both. I think there's software configured systems and, you know, software configured quantum systems in the future. And I think there's, you know, systems that are very, very specific. I mean, even look at supercomputing today and high performance computing. There are computers built on Wall Street just for doing trades or a type of trade. So we've seen this throughout computing history, right? And I don't think quantum will be any different. I hope that there's as many hardware and software solutions available as possible. Because again, I think this is the first really big step that we've made in computing technology. I think the material sciences needed to go to Mars, the research and drug discovery to combat cancers and things like that, the environment, all of these things. Now you're talking about the computing horsepower to really address those. And so, you know, the more the merrier. But I mean, as far as what that ends up looking like, I mean, I think it still follows some fundamental development rules that classical computing has followed, which is you do have specified, right? You have FPGAs and you have TPUs and GPUs. And you have things, think about GPUs. We talk about GPUs now, like they're great for processing, but that's not what they were made for, right? You know what I mean? They were somebody said, whoa, these processors on these graphic cards are super awesome and cheap. Let's stream them together. And there will be people who do that. There will be the hackers and painters of quantum, if you will, right? And they'll do those same things. Yeah, I mean, I wouldn't be surprised if all this comes to pass. But I would say the specific focus today, I think is a bit of, it's relating to this pre-fault tolerant era, right? We're kind of programming machines where I have to count every instruction. It's like the really, really early days of classical computing where I only like one kilobyte of memory, if that. And so I had to like every bit count it, right? We're kind of there. And that sort of forces the programmer to fit in very narrow boxes, right? Like in order to get something to work. But as the machines become more capable and these abstraction layers become, you know, I don't worry about their cost, then I think that will change the world a lot. Another thing that will happen though, is like once we get the fault tolerance, once we're not talking about operations on physical qubits, but operations on error corrected qubits, error correction comes with a big overhead in cost of like as a hardware developer of how many qubits I need and the control system that I have to build in order to correct the errors as the system is executing. But most error correction comes with an enormous advantage, which is that the connections, the virtual connections between error corrected qubits are often all to all or very, very cheaply all to all. I can move qubits around, I can teleport them around on this logical lattice of qubits for almost no additional cost based above what I do for error correction. So when we get to that regime, I think we'll become a lot less focused on needing to specialize the hardware for this application or that application and so on. I wanna remind those of us that are listening that you can ask questions and we're kind of coming to the end of the questions that I was dying to know, but I'm gonna have one more here. And that's what's the most common misconception about quantum development that you've run into? Priya, I'll start with you. Oh my gosh. I think the biggest is that this is going to take me two years to even do my first calculation or first circuit. It's the expectation that the first step is going to be on the order of say yours rather than, you know, like, hey, go get Kiske going, you're in good shape. Worley, how about you? I mean, I think it's that, you know, I don't, I agree with Priya, I see that where people are like, they're looking for the like, hey, I downloaded the Apple Dev Kit and I did Hello World, boom, it all compiled. And it's like, oh, it's a little more complicated than that. So I agree with that. But I think in addition to that, it's this view by some developers that quantum computers will be like the thing that you program, it'll be just on those quantum machines. And I think we all see that there's going to be a blended architecture, right? There's going to be, the classical components aren't going away. And the way I like to think about it is, you know, think about traveling across the US 100 years ago, right? You did it by wagon, it took six, eight weeks, somebody died, maybe eight on who knows? And then, you know, all of a sudden we had trains and you did it in a week, right? But no matter how far you go, eventually reach an ocean. And so now we have air travel. Air travel didn't get rid of trains around the world, right? You know, and quantum computing, I don't think it's going to get rid of massive hunks of classical infrastructure. And I say that from a pretty, having worked at Tivoli and IBM and BMC, I know how many mainframes in the world are still running very critical components of all of our lives. So if we haven't been able to get rid of all of those yet, then it's probably going to be a very long, long tail for that to happen. And I think that's the thing is people, you know, people are like, oh, I'll do quantum computing. It's like, well, you still, you're going to have to know all of this, right? You're going to be programming across infrastructure. You're going to be doing it probably with some smart routing system on what resources you're using at what time. And it is going to be new, but it's going to be things you need to know in addition to that for now. And then like Blake said, I think he made the best point of the talk, which is eventually there'll be that Apple AR kit or whatever. And we'll say, hey, I'm writing code. I've got this kind of complex area of the code. The computer's going to find it and say, this is computationally complex. It's computationally complex in a way that if I add a few variables, the evaluation time source, I can take that out, send it to a quantum machine, get a reply back, and then continue programming, right? I think there's going to be a lot more of that than maybe people imagine. I think people maybe are putting too much of a burden on the quantum system and not understanding that that's a specialized tool for a specialized purpose. Yeah, just to add on to that, I mean, there are certain problem domains where we don't actually expect any advantage from having quantum resources available. And given that, I mean, we have to understand that classical Peters are about cheap and fast at problems that they're good for. And so it won't make sense. Like you'll actually be slower in some cases for choosing the quantum resource over the classical one. And so, we predict that very far into the future, these blended environments, these hybrid environments where you have access to both quantum and classical resources will be the norm. Jeffrey, I think just to tag on to like, think of it this way, as a developer, you want me to do something for you. So there's three factors. You can have it, it can be good, it can be fast, or it can be cheap. And you get to pick any two. And as a developer, I get to pick the other one. And that won't change with quantum. I mean, if a quantum computer is a million times faster at a task that has a minor impact on return on investment or doing something, and a classical system is, you know, cost a million times less and it'll take longer, but it'll get the job done, enterprises will still default to that classical system. Right? They're, especially now, I mean, enterprises 10 years ago had more of an R and D flare than they do today. Today, they're moving their stuff into clouds, even though, you know, I thought that was the 90s as I'm sure you did, Jeffrey, but you know, there's still people making that transition. There's a lot of ways to look at this that say, look, it's going to change the world. It's going to be one of the most impactful things that's happened in computer science ever, right? Definitely in our lifetimes, but there's going to be a whole bunch of factors to get it adopted that we're going to have to address. And one of those is exactly what's Blake saying. We're going to have to identify where it has an advantage, where it doesn't. And we're going to have to build systems that automate and guide people through that, including developers with abstraction. Because if we don't, we're not going to have the adoption we need to reach any kind of critical impact. That's right. I guess, Jeffrey, one of the things that I'm often surprised about is the number of people that believe that quantum programming today is done only with simulators. And certainly there's a lot of value to having simulators, having better simulators with good noise models is extremely valuable. I don't deny that. But I mean, real quantum hardware exists, right? There's 18 quantum systems available today on the IBM quantum experience. And people that are doing applications research often have to pay attention to, if they want to get their problem to work, they have to pay attention to some details of that resource. They need to, these devices today have noise. They have imperfections. And so they need to employ techniques sometimes to mitigate those errors. And if I can't capture that behavior exactly with the simulator, the only way to really find out if it works is on real hardware. And so having real hardware today is critical. It's something that exists and it's critical to actually finding out whether or not your idea really has value. So one of the questions that we have from the listeners today is about the nature of the first quantum, recognizably quantum workloads. Any sort of prediction as to what the first quantum powered apps might end up being or quantum enriched apps, maybe I should say, given the way that our discussion is going? So I mean, there's a few domains that we suspect will have early use of quantum machines, early successful use of quantum machines. And those are kind of the domains of quantum simulation, particularly chemistry. There's systems that take advantage of linear algebra because that's something that quantum machines kind of do natively. And so that often happens in optimization problems or finance problems, which are also tend to be optimization problems. And so those are the domains that we're looking at first effectively for finding value of quantum resources. So here's another one. So despite the enthusiasm expressed by those of us on the panel today, it still sounds like quantum advantages is far off, years off. And the mainstream quantum computing, even around a niche problem set is at least a decade away. Is this wrong? Decade feels like it might be a little bit too long to me, but I'll let the experts weigh in. Decade feels a bit pessimistic to me. Yeah, look, as the, you know, I have two amazing panelists that are both far more quantum experts than me. So looking at it from a pure 30 years of seeing new tech coming down and doing the development, I think 10 years sounds very pessimistic. Now, is it what most people imagine as a quantum computer in 10 years? Is it a full general purpose machine, whatever? Who knows? But I don't think you're gonna wait 10 years. I think it's more in the two to five year range to where there's things that start to become economically advantageous to enterprises. And it'll probably be in chemistry and material science and I mean, I agree with the direction Blake was going there. But it's like, as you see those advantages, the reason to get involved in quantum now is it will not be like, hey, you know, Amazon has a website and Barnes and Noble is like, no worries, we can take a few years, we'll wait, we'll see how that works. Okay, now we have a website, right? And we know how that turned out. It will be, you know, a much more dramatic inflection point in a much, much shorter period of time. If you were in aerospace and your competitors using quantum and you've decided to take a wait and see approach, it's not gonna be something where we see it 24, 36 months out. It's literally just gonna be like, oh, IBM released a new version of KidsKit and a new machine and it's magic. And if you've been in that path for workflow, then you're taking advantage of that tremendously. And if you haven't, then you're a year or two behind the moment that transition happens. So I mean, I think, you know, it's like any other technology, right? Look at the iPhone of 10 years ago. Would you have said, hey, do you think iPhones do augmented reality in 10 years? I mean, who knows, right? The developers, the users, they'll drive that. I mean, one of the weak points of quantum computing is we don't have enough people from outside of quantum computing asking the tough questions, doing the feature requests, you know, pushing it forward in my opinion. But it's like, you know, 10 years, I would agree with Blake. I think that's really pessimistic. And I think that we don't know and you won't know. It'll be, you'll read about it and literally out of nowhere, it'll be picked up. And if you want an example of that, think of machine learning. Machine learning was all the rage when I was getting out of high school in the 80s, right? In the late 80s. And then it didn't do anything, it didn't do anything, didn't do anything. And then look at where, just in Google Zeitgeist or wherever, all of a sudden like something worked and it just skyrocketed. And if you were on that train, that was great for you. And if you weren't, then you're still playing catch up, you know, six or seven years later. Right. I think that's especially true for, you know, people working on quantum chemistry problems that use quantum computers, folks working in predicting new molecules, new pharmaceuticals, they do anything to get that 10%, 5% advantage. It's not, you know, so I think if somebody is able to make very high fidelity predictions or predict something, you really wouldn't have incrementally improved on using your classical resources. You're somewhat, what I would call an existential point there. So, so I agree with Wally on that, you know, 10 years is very pessimistic. I tend to be really optimistic, so I won't make a prediction here, but I think one of the, you know, I heard pre say next year, I heard pre say next year, that's what I heard. She said, I'm not going to make a prediction. I hear August, 2021. I'm going to tweet that out right quick. Don't worry, just give me a second. No worries. One of the consistent things I'm hearing here though is that, you know, if somebody is used to being a fast follower and saying, you know, I'll wait until the technology gets to the point where it's proven and then I'll learn it, that might not be a strategy that works as well in this particular space. First mover that seemed to have more of an advantage given the nature of the changes. Exactly, and I think, you know, there are examples from other parts of quantum technology, quantum communication being one of them where you can show there's unconditionally secure communication that lies on one side, right? So that's not something you're going to wait for somebody else to show before you think about it. Because once that access is out there, that's not something you can really catch up to. So I think quantum information, quantum computing, it has some parallels with the communication side of things, not exactly the same, but, you know, there is a step change that once you have access to, say, a larger quantum resource where you've figured out how to do a valuable problem, you're also much less likely to, you know, share that immediately. For example, if you, you know, find a way to do a large biomolecule, the era of pandemics, I feel like biomolecules is something a lot of us are thinking about more than we would have normally. Yeah, that's advantage that somebody else might find extremely hard to overcome if ever. So that's, and I think that's why there's interest from people who normally would not be early adopters of technology in this space at least. Well, and just think about, you know, just right quick to stick to the transportation thing, think about all of the horses in use when cars came along and what were cars? They were prohibitively expensive. They weren't as reliable. They were all these things. And then as commoditization happened, as democratization of all of the things we know about automotive history, it literally, if you look at the time where they overlap, that's a very, very small amount of time. It was just like, you know, horses are in fields and everybody has some sort of automobile. When you look at it from a historical perspective, I think it's the same thing. I don't think you can't be a fast follower. You have to either be placing a bet in it now or deciding to take the risk of not being involved in it at the point where something that is clearly a tremendous evolutionary change in computing happens. And if that's a risk you wanna take with your business, that's totally fine, right? I mean, people did that with the internet. They've done it with every technological advantage. The only problem is that as we move further in the future, these changes become bigger, the delta between the existing and the new, the incumbent and the new become larger and it happens much over a much shorter period of time. So I just, I think, you know, again, you know, not to pick on Barnes and Noble or whatever, but if you think of a Barnes and Noble border Amazon example, it's like, oh, cute selling books on the internet. They'd be like, oh, wow, they've got this new fancy computer and then you'll be like, shit, we don't have one, what are we gonna do? Right? Like you can't catch up because now I'm a financial trade one person. You know? Right, well, I mean, just go back 10 years and tell somebody, hey, in the future, there'll be a pandemic and we'll only meet on video and people would think you were nuts. So I mean, this is gonna be a million, a trillion times the impact is any of those. So I just want to go tack on one thought here, which is that I do think that inflection point will happen and my colleagues at IBM, we're working every day to make the harbor better, to hasten that the arrival of that point from a harbor standpoint, but it'll also be a mistake to have the harbor capable of it of quantum advantage and not realize it because we didn't have the software ecosystem ready to try different applications, try different spaces to try to find quantum advantage on the hardware that exists. And so that's why we're not waiting, we're working with partners such as my colleagues at the panel today to develop that and grow that software ecosystem to make the systems accessible to a broader audience. So that we can find quantum advantage by trying different spaces of applications, of application areas. I want to thank you all today. This has been awesome. I've gotten a lot of my burning questions answered. It's been very edifying for me. I hope for the other folks that have been listening in today, thank you for sharing your experience and your wisdom with us. Yeah, thank you for having us here. My pleasure. Thanks. Thanks for having us.