Drawbacks of writing a compiler in Smalltalk

Sorry for the vague title, what I’m really asking is: when writing a compiler for a quantum DSL, many languages have chosen an imperative or functional host language. Few, if any, have chosen a purely object oriented language for research in QPL / Quantum compiler development, why? And is this necessity or preference? In industry, Cirq and Qiskit developed their frameworks using OOP methodology, circuits, gates, etc., all being objects, which seems intuitive. So, are there major reasons / research outcomes that show roadblocks for compiler development in a purely object oriented language like Smalltalk? I can see the interactive environment of Smalltalk being very useful for a bunch of software toolkit features. With a language built on top of that rich environment, that seems incredibly useful to an algorithm developer. Asking because I’m planning to start research on making a development toolkit for quantum algorithm developers written in Smalltalk and would like to know if there’s something I’ve missed in the literature that will end up deterring me from this. Let me be abundantly clear that I’m not talking about a quantum version of Smalltalk, I see the drawbacks there, I’m talking about Smalltalk as the host language for a compiler. This language would have its own syntax, type system, and semantics. That’s all for the main question, if you have thoughts and want more information, my plan is to: stay small and provide minimal abstractions to start, focus on the verification and optimization target multiple IRs: Matrix operations, QASM 2.0, Quil, QIR Focus on building visualization tools to help an algorithm developer make algorithms Focus on level 1 optimizations to stay hardware-agnostic for the time being If anyone currently researching quantum programming languages / level 1 compiler optimization could critique this plan or ask some critical questions that I may face that would be much appreciated. Likewise, if there are any algorithm developers who think this is fruitful, if you could comment SDK / environment features that you consider essential, or even nice to have, (maybe being able to pull up the current circuit representation of a function in different forms, QMDD, ZX Diagram, Gate Model, etc.), that would be very helpful as well. Your question is partly opinion-based. It is hard for someone with a partial view of your intents to make the call for you about which technology to use, even more so since a large part of this decision is a matter of taste and language fluency. I will try to address why the state of the art features this distribution of programming paradigms. OOP is good for a company codebase The main advantages of object oriented programming are modularity, code reusability and maintainability. The examples from industry you cited are developed by large companies (namely Google and IBM), whose approach to software development can be different from the approach chosen for a personal project. Maintainability is important when you need your codebase to be resilient to staff turnover and is certainly taken in consideration when choosing a technology for a project. There is certainly a case to be made about the structure brought by OOP to the codebase allowing newcomers (at least OOP-trained developers) to get a grasp on an object oriented codebase quicker than on an imperative/functional one. The same goes for the end-user to some extent: you find this approach "intuitive" because you have been introduced to OOP previously. The relative success of Cirq and Qiskit is in my opinion the consequence of the resources invested towards its development and the use of the fairly democratized Python language rather than an objective advantage of OOP for the tasks at hand. Researchers are not software developers I have no specific data to back up this claim, but I would be very surprised if a large portion of QPL audience chose to identify themselves mainly as "software developers". Both the set of required skills and targeted audience is different for researchers and developers. Researchers will be mainly interested in sharing their results with others researchers. These results tends to be theorems or proofs about the properties of their language, or proofs of concept of these languages being implemented. Even for longer-lived projects, the core programmers will remain a small-scale team that will probably favor its development comfort than the unadvised end user. Software developers ideally have the end user in mind at all time. They are more likely to be aware of advanced programming tools/concepts and it is the core part of their job to program. They are probably more likely to favor OOP than researchers are. I am not saying researchers do not understand software development (a large portion of them actually teach it as part of their position) but they probably do not often have their software development cap on when doing research work. OOP is probably harder to reason about One of the critics of OOP is that it makes it harder to "cleary [see] the flow of a program's instructions". It is not my area of expertise, but I can imagine mathematical proofs about algorithms being easier to formulate in the imperative or functional paradigm than in the object oriented paradigm. Proof techniques inherited from theoretical computing are probably tailored to these paradigms, which would make proofs about OOP algorithms more convoluted. Projects implementing papers ideas would thus naturally favor the imperative/functional paradigm, because it saves the need to adapt the results to another paradigm. This does not mean efficient software can not be written in this paradigm, but it will likely incur some implementation overhead. Your project By the way you refer to "SDK" and such, I am guessing your approach is the one of a software developer. You should thus probably think about your targeted audience. I have basically no knowledge about Smalltalk, but I would a priori not feel very inclined to install a Smalltalk software unless there is a clear advantage over other comparable popular framework (because it would be harder for me to experiment with it than with Python for example). If you target a small audience, or if you think people wouldn't mind this language, this is less of an issue. I cannot judge the adequacy of Smalltalk/OOP for your intended project. That being said, software programming is not monolithic and you could imagine using an object oriented language as the core of your software while using other languages for some specific tasks. This would require your primary language to be interfaced with the others, in the same way that it is possible to call C code from Python. This is often done for performance issues, or if you do not want to reinvent the wheel if you know of a piece of software that does the exact job you need: you will not want to implement a GUI yourself unless it stays very basic for example.