Quantum Computing and the UNIX Philosophy
Write programs that do one thing and do it well
We’re living at the dawn of quantum computing era. It gives us the flashback of early, nice days of computing, when programmers were real programmers and wrote their own device drivers. The wheels of history and the wheels of change have been set in motion. Then what can we learn from the past? How can we build the great quantum computing ecosystem, like 1970’s legends? There are lots of them, but the UNIX Philosophy may briefly summarize it.
1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.
2. Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
“The Unix philosophy is documented by Doug McIlroy in the Bell System Technical Journal from 1978.”
This gives us many thoughts. In fact, I reckon that this philosophy fits very well with quantum computing’s purpose; do one thing and do it well. Quantum Computer is not a general-purpose computer but a brilliant device which can solve some specific problems amazingly fast. It’s indeed a computer that does one thing and does it well.
To be brief, in my humble opinion, writing a short, small quantum computing program is always a great idea. You don’t have to learn every little thing about every little field and build everything yourself. Just make a small set of programs(or program) which implements your idea. Remember, less is more.
And our Quantum Computing community is talented. We have many people with specific skill sets, so we can build another great thing with those small and robust programs.
To achieve that, programs should be written by working with other programs in mind. And one of the most basic, foundational(and easy) format for programs to communicate is text streams. It requires no further study, no prior protocol in advance, no additional libraries we have to learn(We’re already busy learning qiskit!).
By following these simple suggestions, we can build a program (or even an ecosystem) which can be maintained easily and flexibly. This way of thinking will help many newbies and experts build something without hesitation.
Thanks for reading.
