ट्यूरिंग की "हल करने की समस्या" को हल करने के लिए एल्गोरिथम

Question

"एलन ट्यूरिंग ने 1936 में साबित कर दिया कि सभी संभावित प्रोग्राम-इनपुट जोड़े के लिए हॉल्टिंग समस्या को हल करने के लिए एक सामान्य एल्गोरिदम मौजूद नहीं हो सकता है"

क्या मैं कुछ संभावित प्रोग्राम इनपुट जोड़े के लिए रुकने की समस्या को हल करने के लिए एक सामान्य एल्गोरिथ्म पा सकता हूं ?

क्या मुझे एक प्रोग्रामिंग भाषा (या भाषाएं) मिल सकती हैं, जहां मैं इस भाषा में हर तरह के कार्यक्रम के लिए यह तय कर सकता हूं कि क्या प्रोग्राम हमेशा के लिए समाप्त हो जाता है या चलता है?

Comments

इसी तरह के सवाल: stackoverflow.com/questions/8412741/…

CACM का मई में एक बहुत ही दिलचस्प लेख था: प्रोविंग प्रोग्राम टर्मिनेशन

— क्रिस्टोफ वेल्स

"एक सामान्य एल्गोरिथ्म [...] कुछ संभावित कार्यक्रम इनपुट जोड़े के लिए" - यह आत्म-विरोधाभासी होने के करीब है। मुझे लगता है कि आप अपने आप को सभी कार्यक्रमों के अनंत उपवर्ग तक सीमित रखना चाहते हैं?

— राफेल

Answer 1

क्या मैं कुछ संभावित प्रोग्राम इनपुट जोड़े के लिए रुकने की समस्या को हल करने के लिए एक सामान्य एल्गोरिथ्म पा सकता हूं?

हाँ यकीनन। उदाहरण के लिए आप एक एल्गोरिथ्म लिख सकते हैं जो किसी भी प्रोग्राम के लिए "हाँ, इसे समाप्त करता है" जिसमें न तो लूप होते हैं और न ही रिकर्सन और "नहीं, यह समाप्त नहीं होता है" किसी भी प्रोग्राम के लिए जिसमें एक while(true)लूप होता है जो निश्चित रूप से पहुंचता है और इसमें शामिल नहीं होता है एक ब्रेक स्टेटमेंट, और बाकी सब के लिए "डन्नो"।

क्या मुझे एक प्रोग्रामिंग भाषा (या भाषाएं) मिल सकती हैं, जहां मैं इस भाषा में हर तरह के कार्यक्रम के लिए यह तय कर सकता हूं कि क्या प्रोग्राम हमेशा के लिए समाप्त हो जाता है या चलता है?

नहीं तो वह भाषा ट्यूरिंग-पूर्ण है, नहीं।

हालाँकि गैर-ट्यूरिंग पूर्ण भाषाएं हैं जैसे उदाहरण के लिए Coq , Agda या Microsoft Dafny जिसके लिए Halting Problem decidable (और वास्तव में उनके संबंधित प्रकार सिस्टम द्वारा तय की जाती है, जिससे उन्हें कुल भाषाएं मिलती हैं (अर्थात ऐसा प्रोग्राम जो समाप्त नहीं हो सकता है) संकलन))।

Comments

आदिम-पुनरावर्ती कार्यों का वर्ग एक प्रसिद्ध "प्रोग्रामिंग भाषा" है, जिसके लिए हॉल्टिंग समस्या तुच्छ रूप से विश्वसनीय है।

— राफेल

कई " कुल कार्यात्मक प्रोग्रामिंग " भाषाएं हैं, जिसमें सभी कार्यक्रम काफी हद तक समाप्त हो रहे हैं।

— एंडरसन ग्रीन

Answer 2

मुझे लगता है कि यहां सभी जवाब पूरी तरह से और पूरी तरह से याद आते हैं। प्रश्न का उत्तर है: मान लिया गया है कि कार्यक्रम रुकने का इरादा है, तो हाँ आप इसे रोकना बेहतर दिखा सकते थे। यदि आप इसे आसानी से नहीं दिखा सकते हैं तो प्रोग्राम को गुणवत्ता नियंत्रण द्वारा बहुत बुरी तरह से लिखित और अस्वीकृत माना जाना चाहिए।

क्या आप वास्तव में एक उपयुक्त मशीन एल्गोरिदम लिख सकते हैं यह इनपुट प्रोग्रामिंग भाषा और आप कितने महत्वाकांक्षी हैं पर निर्भर करता है। यह एक प्रोग्रामिंग भाषा के लिए एक उचित डिज़ाइन लक्ष्य है जिससे समाप्ति को आसानी से संभव किया जा सके।

यदि भाषा C ++ है, तो आप शायद टूल नहीं लिख सकते हैं, वास्तव में यह संभावना नहीं है कि आप कभी भी पार्सर जा रहे हैं, अकेले समाप्ति को साबित करें। एक बेहतर संरचित भाषा के लिए, आपको प्रमाण बनाने में सक्षम होना चाहिए, या कम से कम कुछ मान्यताओं के साथ ऐसा करना चाहिए: बाद वाले मामले में उपकरण को इन मान्यताओं का उत्पादन करना चाहिए। एक समान दृष्टिकोण भाषा में समाप्ति के दावे को शामिल करना और जटिल परिस्थितियों में उनका उपयोग करना होगा जहां उपकरण विश्वासों पर भरोसा करेगा।

लब्बोलुआब यह है कि कोई भी यह समझने के लिए नहीं लगता है कि एक प्रोग्राम हाल्ट का सबूत वास्तव में संभव है क्योंकि (अच्छे) प्रोग्रामर ऐसे हॉल्टिंग प्रोग्राम को लिखने का इरादा हमेशा जानबूझकर करते हैं और एक मानसिक तस्वीर के साथ कि वे क्यों समाप्त करते हैं और सही तरीके से काम करते हैं: ऐसा कोड जानबूझकर पूरा नहीं होता है इसलिए यह स्पष्ट है कि वे रुक रहे हैं और सही हैं और यदि एक उचित एल्गोरिथ्म यह साबित नहीं कर सकता है, संभवतः कुछ संकेतों के साथ, तो कार्यक्रम को अस्वीकार कर दिया जाना चाहिए।

बिंदु: प्रोग्रामर मनमाने ढंग से प्रोग्राम नहीं लिखते हैं, इसलिए हॉलिंग प्रमेय की थीसिस संतुष्ट नहीं है और निष्कर्ष लागू नहीं होता है।

Comments

मुझे लगता है कि यह आप ही हैं जो पूरी तरह से और पूरी तरह से चूक गए। आपके उत्तर का पहला पैराग्राफ प्रश्न पर लागू नहीं होता है क्योंकि यह एल्गोरिदम के बारे में पूछ रहा है - ऐसा नहीं कि कोई मानव प्रमाण नहीं दे सकता है या नहीं। शेष उत्तर प्रश्न के पहले पैराग्राफ का उत्तर देता है, अर्थात क्या एल्गोरिथ्म कुछ कार्यक्रमों के लिए समाप्ति का सबूत दे सकता है। पिछले उत्तरों में से सभी ने पहले से ही "हां" कहा था।

— अप्रैल को sepp2k

आपका दावा है कि एक एल्गोरिथ्म लिखना संभव है जो पर्याप्त रूप से सरल ट्यूरिंग-पूर्ण भाषा में हर अच्छी तरह से लिखे गए प्रोग्राम को समाप्त कर सकता है। हर संभव एल्गोरिथम जो समाप्ति को प्रमाणित करने की कोशिश करता है, ऐसी समस्याएं हैं जहां हर प्रोग्राम जो उस समस्या को हल करता है, उस एल्गोरिथ्म को रोकना साबित नहीं किया जा सकता है। इसलिए जब तक आप यह नहीं कह रहे हैं कि उस समस्या को हल करने वाला हर प्रोग्राम परिभाषा (जो कि बहुत अजीब होगा) से बुरी तरह से लिखा गया है, जो आपकी बात को खारिज कर देता है।

— sepp2k

@Sam अगर कोई मुझसे पूछता है कि क्या कुछ कोड रुकता है, तो मैं कोड को देखूंगा और यह पता लगाने की कोशिश करूंगा। लेकिन मैं एक एल्गोरिथ्म नहीं हूं। और हां, एक एल्गोरिथ्म लिखना संभव है जो यह जांच सकता है कि क्या कोई प्रोग्राम बहुत सारे कार्यक्रमों के लिए रुकता है। लेकिन येट्रिल ने ऐसा नहीं कहा। यट्रिल ने कहा कि यह सभी लिखित कार्यक्रमों के लिए संभव है। और जैसा कि मैंने अपनी पिछली टिप्पणी में कहा था, यह केवल तब तक गलत है जब तक कि आप यह दावा नहीं करते हैं कि कुछ समस्याएं केवल बुरी तरह से लिखे गए प्रोग्राम (जो फिर से भद्दी होगी) से हल हो सकती हैं।

— sepp2k

@Sam "यह मुझे सीधा लगता है कि रुकने के लिए जानबूझकर लिखे गए कार्यक्रमों को हॉल्टिंग की स्थिति के लिए आसानी से विश्लेषण किया जा सकता है" - अगर ऐसा था, तो हमारे पास ऐसे उपकरण क्यों नहीं हैं? ऐसा नहीं है कि लोग कोशिश नहीं कर रहे थे। (एक अपराधी विधि ओवरराइडिंग है: संकलन समय पर, आपको सभी कोड नहीं पता होंगे जो निष्पादित किए जाएंगे।)

— राफेल

@ सम "एक अनंत लूप है" दृष्टिकोण के लिए एक कठिन चीज है, यहां तक ​​कि वास्तविक दुनिया के लूप के लिए भी। बेशक मुझे सिखाया गया था कि कैसे लूप-इनवेरिएंट्स को खोजा जाए, लेकिन इसका मतलब यह नहीं है कि मैं कई मामलों में एक (आसानी से) पा सकता हूं। जहां तक ​​मुझे पता है, अनुमान और साबित करना इन दिनों स्वर्ण-मानक है। फिर, अगर वहाँ थे यथोचित सामान्य एल्गोरिदम, मैं उम्मीद होती है उन्हें प्रमुख compiles या IDEs (जिसमें शामिल होने के लिए करना कुछ तुच्छ, वाक्य-जांच)। क्या आप एक काफी मजबूत एल्गोरिथ्म का संदर्भ दे सकते हैं?

— राफेल

Answer 3

उत्कृष्ट और (संभावित अनजाने में गहरा) सवाल। वास्तव में हाल्ट-डिटेक्टिंग प्रोग्राम हैं जो इनपुट के सीमित सेट पर सफल हो सकते हैं। अनुसंधान का एक सक्रिय क्षेत्र है। इसमें (स्वचालित) प्रमेय साबित करने वाले क्षेत्रों के लिए बहुत मजबूत संबंध हैं।

हालाँकि कंप्यूटर विज्ञान "कार्यक्रमों" के लिए एक सटीक शब्द नहीं है जो "कभी-कभी" सफल होता है। शब्द "एल्गोरिथ्म" आमतौर पर उन कार्यक्रमों के लिए आरक्षित होता है जो हमेशा रुकते हैं।

अवधारणा संभाव्य एल्गोरिदम की तुलना में अलग-अलग प्रतीत होती है जहां सीएस सिद्धांतकार जोर देते हैं कि उनके सफल होने पर कुछ ज्ञात या गणना योग्य संभावना हो।

एक शब्द अर्ध-एल्गोरिदम है जो कभी-कभी उपयोग किया जाता है, लेकिन इसका स्पष्ट रूप से पुनरावृत्ति करने योग्य या असंबद्ध के लिए एक पर्याय है।

इसलिए यहां उद्देश्यों के लिए, उन्हें क्वासिअलोरिदम कहें । अवधारणा अचूक बनाम अचूक से अलग है।

$A$$X$$B$$Y$$X \subset Y$$X$$Y$$B$$A$

सीएस में इस "अर्ध एल्गोरिथ्म पदानुक्रम" का अध्ययन ज्यादातर अनौपचारिक रूप से अब तक किया गया लगता है।

यह व्यस्त बीवर अनुसंधान [1] और पीसीपी समस्या [2] में दिखाई देता है। वास्तव में पीसीपी पर एक डीएनए आधारित कंप्यूटिंग हमले को क्वासिअल एल्गोरिदम के रूप में देखा जा सकता है। [३] और उसके अन्य क्षेत्रों में देखा पहले से ही इस तरह के रूप में उल्लेख किया प्रमेय [4] साबित।

[१] व्यस्त बीवर समस्या पर नई सहस्राब्दी का हमला

[2] से निपटना पोस्ट पत्राचार समस्या झाओ द्वारा (v2?)

[3] घिरा पोस्ट पत्राचार समस्या हल करने के लिए डीएनए का प्रयोग कारी एट अल द्वारा

[4] साबित कार्यक्रम समाप्ति कुक एट अल, कॉम द्वारा। एसीएम की

(इसलिए यह वास्तव में एक बहुत ही गहरा सवाल है जो कि TCS.SE पर होना करने के लिए योग्य है। शायद ... कोई इसे फिर से इस तरह से पूछ सकता है जैसे यह फिट बैठता है और रहता है)

Comments

कैसे क्स्मियाज़ोरिअम शक्तिशाली हो सकता है के एक प्रभावशाली उदाहरण के रूप में पीएस, एसीएम रेफरी ने दावा किया कि एकरमनिम्स फ़ंक्शन को क्वासियल एल्गोरिदम द्वारा रोकने के लिए सिद्ध किया जा सकता है, लेकिन यह सभी आदिम पुनरावर्ती कार्यों की तुलना में बड़ा (गणना योग्य नहीं) है।

— vzn

"शब्द" एल्गोरिथ्म "आमतौर पर उन कार्यक्रमों के लिए आरक्षित होता है जो हमेशा रुकते हैं।" - मुझे यकीन नहीं है कि यह सच है। वहाँ आंशिक रूप से समाप्त होने वाले एल्गोरिदम के बहुत सारे (esp। सत्यापन में) हैं और मैंने कभी किसी को "एल्गोरिथ्म" नहीं कहने के लिए सुना है।

— राफेल

"एल्गोरिथ्म" के अनौपचारिक उपयोग हैं। "आंशिक रूप से समाप्त करना" ठीक है, लेकिन प्रोब नॉनस्टीडी। जैसा कि कहा गया है, अभी तक कोई शब्द स्थिर नहीं है। विकिपीडिया एक एल्गोरिथ्म को एक प्रभावी विधि के रूप में परिभाषित करता है अर्थात निम्नलिखित विशेषताओं के साथ निर्णायक (1) हमेशा कोई जवाब न देने के बजाय कुछ उत्तर दें; (२) हमेशा सही उत्तर देना और कभी गलत उत्तर न देना; (३) हमेशा अनंत संख्या की बजाय, चरणों की एक सीमित संख्या में पूरा किया जाना चाहिए; (4) वर्ग की समस्याओं के सभी उदाहरणों के लिए काम करते हैं।

— vzn

और फिर बाद में एक ही लेख में यह कहा गया है कि "प्रभावी विधि" शब्द का एक और मायावीकरण उस आवश्यकता को शामिल कर सकता है, जब कक्षा के बाहर से कोई समस्या दी जाती है जिसके लिए विधि प्रभावी है, विधि बिना रुके हमेशा के लिए रुक या लूप हो सकती है , लेकिन एक परिणाम के रूप में अगर यह समस्या का जवाब था नहीं लौटना चाहिए। " यह लगभग खुद विरोधाभासी है!?! इतनी स्पष्ट रूप से, उल्लेखनीय रूप से, मुख्य मुद्दे पर कुछ वास्तविक भ्रम है और मौजूदा शब्दावली सख्त नहीं है। ध्यान दें कि "अल्गोरिदम" एक सहस्राब्दी पुराने या उससे अधिक के करीब है और काफी हद तक स्थानांतरित हो गया है ....

— vzn

यह सच है: पारंपरिक अर्थ शायद "प्रभावी तरीका" है जिस तरह से विकिपीडिया कहता है (आपके द्वारा उद्धृत वाक्य में कोई विरोधाभास नहीं है; यह थोड़ा अस्पष्ट है, हालांकि) - लोगों ने गर्भ धारण करने वाले कार्यों / एल्गोरिदम को समाप्त नहीं किया (के लिए) कुछ इनपुट्स)। मुझे लगता है कि यह 1950 के दशक से स्थानांतरित हो गया है; जैसा कि मैंने कहा, आज लोग स्पष्ट रूप से आंशिक रूप से समाप्ति विधि "एल्गोरिथम" कहते हैं।

— राफेल

Answer 4

जब तक प्रश्न में प्रोग्रामिंग भाषा पर्याप्त रूप से जटिल है (अर्थात यदि यह ट्यूरिंग पूर्ण है), तो भाषा में हमेशा ऐसे कार्यक्रम होते हैं जिन्हें कोई भी कार्यक्रम समाप्त करने के लिए साबित नहीं हो सकता है।

चूंकि सभी लेकिन सबसे आदिम भाषाएं ट्यूरिंग पूर्ण हैं (यह केवल चर और सशर्त की तरह कुछ लेती है), आप वास्तव में केवल बहुत छोटी खिलौना भाषाओं का निर्माण कर सकते थे, जिसके लिए आप रुकने की समस्या को हल कर सकते थे।

संपादित करें: टिप्पणियों के प्रकाश में, मुझे और अधिक स्पष्ट होने दें: कोई भी भाषा जिसे आप डिज़ाइन कर सकते हैं जिसके लिए आप रुकने की समस्या को हल कर सकते हैं, जरूरी है कि ट्यूरिंग-अधूरी हो। यह किसी भी भाषा को नियमबद्ध करता है जिसमें मूल अवयवों (जैसे "चर, सशर्त और छलांग" का एक उपयुक्त सेट होता है, या जैसा कि @ sepp2k कहता है, एक सामान्य "जबकि" -लूप)।

जाहिरा तौर पर कई व्यावहारिक "सरल" भाषाएं मौजूद हैं जैसे (जैसे कि प्रमेय सॉल्वर जैसे कॉक और एजडा)। यदि वे "प्रोग्रामिंग भाषा" की आपकी धारणा को संतुष्ट करते हैं, तो आप जांच कर सकते हैं कि क्या वे किसी तरह की पूर्णता को संतुष्ट करते हैं, या क्या उनके लिए समस्या हल करने योग्य है।

Comments

"के बाद से सभी लेकिन सबसे आदिम भाषाओं पूरा ट्यूरिंग कर रहे हैं (यह केवल चर और सशर्त, की तरह कुछ लेता है)" यह सच नहीं है। सबसे पहले आपको कम से कम पुनरावृत्ति या किसी प्रकार के लूपिंग निर्माण की आवश्यकता होगी (जो कि एक समय-लूप जितना शक्तिशाली होना चाहिए - एक साधारण गिनती लूप पर्याप्त नहीं है)। सभी का दूसरा मुझे नहीं लगता कि लोग हैं, जो Coq या AGDA जैसी भाषाओं (जो कुल कर रहे हैं और इस तरह पूरा ट्यूरिंग नहीं) आदिम या खिलौना भाषाओं कहेंगे का एक बहुत देखते हैं है।

— sepp2k

@ sepp2k: ठीक है, हाँ। पीनो अंकगणित भी काफी उपयोगी है और ट्यूरिंग पूर्ण नहीं है। एक सरलीकृत बयान, मुझे लगता है। यदि ओपी समस्या से पर्याप्त रूप से परिचित है, तो वह उम्मीद है कि तकनीकी विवरण भरने में सक्षम होगा।

"पर्याप्त रूप से जटिल" होने और ट्यूरिंग-पूर्ण होने के बीच एक बड़ा अंतर है। Coq वास्तव में जटिल है, और यह व्यावहारिक कार्यों की एक विस्तृत श्रृंखला के लिए उपयुक्त है।

@ केरेक एसबी यह संभव है कि ट्यूरिंग-पूर्ण भाषा का उपयोग उन तरीकों से किया जाता है जो समाप्ति के लिए उपयुक्त हैं। यदि आप यह साबित कर सकते हैं कि एक पुनरावर्ती सूत्र हमेशा अपनी समाप्ति स्थिति (जैसे कि फैक्टरियल फ़ंक्शन) से संपर्क करता है, तो आप यह साबित कर सकते हैं कि आप हर प्रकार की पुनरावृत्ति को संभालने में सक्षम नहीं होंगे।

@ArtB: यकीन है, हमेशा कुछ कार्यक्रम होते हैं जिन्हें समाप्त करने के लिए सिद्ध किया जा सकता है। ओपी का पहला सवाल उस पर इशारा कर सकता है, हालांकि मुझे यकीन नहीं है कि मैं इसका पूरी तरह से पालन करूंगा। उदाहरण के लिए, आप एक "सामान्य एल्गोरिथ्म" निर्धारित करता है कि नहीं सकता है अगर कार्यक्रमों समाप्त के किसी भी परिवार है, जबकि इसके विपरीत आप सकता है शायद कार्यों की एक सीमित परिवार का निर्माण ऐसी है कि एक समारोह यह सोचते हैं कि परिवार से है, आप एल्गोरिदम रूप से है कि क्या यह बता सकते हैं समाप्त हो जाता है। (। मुझे यकीन है कि ऐसा नहीं है कि परिवार, गैर तुच्छ हो सकता है या नहीं, हालांकि मुझे लगता है कि यह कर सकते हैं, लेकिन मैं एक उदाहरण नहीं बना सकता हूँ।)

Answer 5

$T$$T$ कि वे रुकते नहीं हैं / रुकते नहीं हैं। फिर हम यह तय कर सकते हैं कि क्या एक टीएम प्रूफ जोड़ी प्रूफ को सत्यापित करके रोक रही है। (Sepp2k के उत्तर में दिए गए उदाहरण विशेष मामले हैं)।

यह काफी तुच्छ है। यदि हम TM को रोकने के किसी भी उप सबसेट के संघ को लेते हैं और गैर-रोकने वाले TM के किसी भी उप सबसेट का परिणाम लेते हैं, तो परिणाम TM का सेट होगा, जिसके लिए रुकने की समस्या विकट है (समानांतर में दोनों मशीनों को चलाएँ, यदि पहली बार TM स्वीकार नहीं करता है हॉल्ट, यदि दूसरा स्वीकार करता है तो मशीन रुकती नहीं है)। हालांकि यह बहुत दिलचस्प भाषाओं को नहीं ले जाएगा।

$\mathsf{ALogTime}$$c$$M$

Answer 6

हां, आप कर सकते हैं, लेकिन मुझे संदेह है कि यह उपयोगी होगा। आपको शायद यह मामला विश्लेषण करना होगा और फिर आप केवल सबसे स्पष्ट मामलों की तलाश कर पाएंगे। उदाहरण के लिए, आप कोड के लिए फ़ाइल को grep कर सकते हैंwhile(true){} । यदि फ़ाइल में वह कोड है तो वह कभी भी समाप्त नहीं होगा ^। आम तौर पर आप कह सकते हैं कि बिना लूप या रिकर्सन वाला एक कार्यक्रम हमेशा समाप्त होगा और कई ऐसे मामले हैं जो आप कर सकते हैं कि गारंटी दे सकते हैं कि कोई कार्यक्रम समाप्त होगा या नहीं, लेकिन यहां तक ​​कि एक मध्य आकार के कार्यक्रम के लिए यह बहुत मुश्किल होगा कई मामलों में आप जवाब नहीं दे पाएंगे।

tl; dr: हाँ, लेकिन आप इसे सबसे उपयोगी कार्यक्रमों के लिए उपयोगी नहीं पाएंगे।

---

^ हां, तकनीकी रूप से यदि वह कोड कोड-पथ पर नहीं है या ऐसे अन्य धागे हैं जो अभी भी समाप्त हो सकते हैं, लेकिन मैं यहां एक सामान्य बिंदु बना रहा हूं।

Comments

आपको क्या लगता है कि Coq और Agda उपयोगी नहीं हैं? आप ट्यूरिंग-पूर्णता के मूल्य को कम कर रहे हैं।

मैंने Coq का उपयोग किया है, लेकिन मेरा दावा जावा / C ++ / Ruby / C # में अधिकांश व्यावसायिक सॉफ़्टवेयर लिखे जाने के बाद से बना हुआ है, जिसके लिए मेरे दावे सत्य हैं। 90% लोग जिस तरह के कार्यक्रम लिखने में रुचि रखते हैं, उससे कोई फायदा नहीं होगा। मूल रूप से, यदि आप Coq / Agda आदि के बारे में नहीं जानते हैं तो आप इसके लिए लक्षित बाजार नहीं हैं।

मैं कहूंगा कि वास्तविक दुनिया के 99% कार्यक्रमों को किसी भाषा के गैर-ट्यूरिंग-पूर्ण सबसेट में कार्यान्वित होने से लाभ होगा। आप प्रतिदिन एकरमैन कार्य को लागू नहीं करेंगे। 100% CRUD को "वास्तविक" भाषा की आवश्यकता नहीं है। डाटा प्रोसेसिंग लगभग हमेशा तुच्छ है। टर्मिनेटर प्रोजेक्ट देखें - वे संभावित सी ++ प्रोग्रामों का एक अच्छा उपसमुच्चय भी परोस रहे हैं, जो वास्तविक दुनिया के सामान (ड्राइवरों और अन्य निम्न स्तर कोड सहित) के लिए पर्याप्त से अधिक है।

अधिकांश वास्तविक विश्व परियोजनाएं पुस्तकालयों का पुन: उपयोग करना चाहती हैं जो ट्यूरिंग-पूर्ण भाषाएं लिखी जाती हैं और उनके आईडीई और डीबगर्स और ट्यूटोरियल का उपयोग करती हैं। हां, आप गैर-ट्यूरिंग भाषाओं में चीजों को पूरा कर सकते हैं, लेकिन मैं वास्तव में "मैं एक्स करना चाहता हूं" कहकर कुछ नहीं सोच सकता और मेरा जवाब "यूज कोक" है। ps- टर्मिनेटर प्रोजेक्ट से मुझे परिचित कराने के लिए धन्यवाद ।

एक गैर-ट्यूरिंग-पूर्ण SQL में व्यावसायिक तर्क का एक बहुत बड़ा अनुपात पहले से ही लागू है। और डीएसएल और ईडीएसएल अब बढ़ रहे हैं। इसलिए, जल्द ही अधिकांश व्यावसायिक ऐप प्रोग्रामर सभी "सामान्य उद्देश्य" भाषाओं के बारे में भूल जाएंगे।