Talk:Quantum programming language
A bit lacking
No mention of Shor and his polynomial time factorising algorithm (which would render most public key encryption schemes useless)? OH THE HUMANITY!! Zyxoas (talk to me - I'll listen) 11:07, 24 May 2006 (UTC)
Isn't that an algorithm and not a language? --128.243.220.41 10:42, 21 July 2006 (UTC)
Merge with Quantum programming
I think this article should be merged with Quantum Programming, as is the case with Functional Programming Languages redirecting to Functional Programming. It should also be languageS, as there are clearly more than one. The quantum programming "stub" would act as a better introduction than the current one, which asserts that "every quantum machine has to be controlled by classical device", which simply isn't true. For a start, all physical computational devices are quantum mechanical in nature, and there are languages (such as QML mentioned in quantum programming) which follow the design "Quantum data and control". The quantum circuit model itself exhibits quantum control.
Also, I think some of the language descriptions are currently a little too concrete and POV - some should be split into their own entries, much like Haskell and Ocaml are from functional programming. QCL is also not regarded as "the most advanced" language in a theoretical sense! Rather, a short summary of the design goals, paradigms used, and basis of the language would be better, with maybe a small example of syntax.
Anyway, what does anyone else think? I might have a go at fixing it up a bit soon.
--128.243.220.41 10:42, 21 July 2006 (UTC)
I have merged the two articles, and redirected Quantum Programming to Quantum Programming Language (not the other way around). I think this is the better direction, because "quantum" is not really a programming paradigm like "imperative" or "functional", or even "high-level". Also, the article is not about programming, but about programming languages for quantum computing.
I agree that it should be plural. This seems to entail renaming the page, putting a forward in place, and then fixing all indirect links (double forwards are not allowed in Wikipedia). I am not volunteering.
I agree that the extended description of particular languages should be separated out into separate articles. Also, the English could be improved; the description of QCL could use a few "the" and "a".
Perhaps the article should be more explicit about the relative practical significance vs. theoretical significance of these languages. It seems clear that languages like QCL were designed as practical, featureful, and useable implementations, but not with theoretical design principles (such as type safety or semantics) in mind. On the other hand, languages like QPL and its friends are theoretically nice, but their data types are not designed for practical use, and these languages have been implemented only as prototypes and not with performance in mind.
Content Disclaimer
Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.
- The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
- There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
- It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
- Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
- Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.