घोषणात्मक प्रोग्रामिंग का सपना [बंद]

Question

घोषित प्रोग्रामिंग का सपना साकार क्यों नहीं हुआ? रास्ते में कुछ ठोस बाधाएं क्या आ रही हैं? एक साधारण उदाहरण के लिए मैं क्यों नहीं कह सकता

sort(A) is defined by sort(A) in perm(A) && asc(sort(A))

और स्वचालित रूप से इसे से एक छँटाई एल्गोरिथ्म मिलता है। permमतलब क्रमपरिवर्तन और ascसाधन आरोही।

Comments

वैसे आपका विशिष्ट उदाहरण पहले से ही उपलब्ध है: gkoberger.github.io/stacksort

— Den

क्या आपने प्रोलोग के बारे में सुना है? बस "उत्तर सेट प्रोग्रामिंग" के लिए देखो। डिफ़ॉल्ट लॉजिक पर बहुत सारी प्रणालियाँ निर्मित होती हैं।

— १०:०५ पर स्किंगेल

वैसे इस सवाल का जवाब आसानी से मिल जाता है। ऐसी व्यवस्था को लागू करने का प्रयास । आपने इसे सफलतापूर्वक करने से क्या रोका? ऑड्स अच्छा है कि आपने जो कुछ भी रोका है वह बाकी सभी को रोक दिया है।

— एरिक लिपपर्ट

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

— पैन्ज़रक्रिसिस

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

— बेंजामिन हॉजसन

Answer 1

कुछ बहुत अच्छे जवाब हैं। मैं चर्चा में योगदान देने का प्रयास करूंगा।

प्रोलॉग में डिक्लेरेटिव, लॉजिक प्रोग्रामिंग के विषय पर रिचर्ड ओ'कीफ की महान पुस्तक "द क्राफ्ट ऑफ प्रोलॉग" है । यह एक प्रोग्रामिंग भाषा का उपयोग करके कुशल प्रोग्राम लिखने के बारे में है जो आपको बहुत ही अक्षम प्रोग्राम लिखने देता है। इस पुस्तक में, कई एल्गोरिदम के कुशल कार्यान्वयन पर चर्चा करते हुए (अध्याय "प्रोग्रामिंग के तरीके") में, लेखक निम्नलिखित दृष्टिकोण लेता है:

• अंग्रेजी में समस्या को परिभाषित करें
• एक कार्यशील समाधान लिखें जो यथासंभव घोषित हो; आमतौर पर, इसका मतलब है कि आपके प्रश्न में वास्तव में बहुत कुछ है, बस प्रोलॉग को सही करें
• वहां से, इसे और तेज करने के लिए कार्यान्वयन को परिष्कृत करने के लिए कदम उठाएं

सबसे अधिक ज्ञानवर्धक (मेरे लिए) अवलोकन मैं इन के माध्यम से अपने तरीके से काम करते हुए बनाने में सक्षम था:

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

दूसरे शब्दों में, एक समाधान को लागू करते समय, हमने समस्या के बारे में अपने ज्ञान का उतना ही उपयोग किया है जितना हम कर सकते हैं। की तुलना करें:

किसी सूची का क्रमांकन खोजें जैसे कि सभी तत्व आरोही क्रम में हैं

सेवा मेरे:

दो सॉर्ट की गई सूची को मर्ज करने के परिणामस्वरूप एक सॉर्ट की गई सूची होगी। चूँकि वहाँ पहले से ही सॉर्ट किए जा सकने वाले सब्लिस्ट्स हो सकते हैं, इन्हें 1 के सब्लिस्ट्स के बजाय एक शुरुआती बिंदु के रूप में उपयोग करें।

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

असली सवाल के रूप में: आगे कैसे बढ़ना है? खैर, एक तरीका यह है कि हम कंप्यूटर को घोषित होने वाली समस्या के बारे में अधिक से अधिक ज्ञान प्रदान करें।

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

• प्रत्येक अच्छी तरह से परिभाषित परिवर्तन बाधाओं का एक शोधन है जो पहले से ही मौजूद हैं (गुण जो ज्ञात हैं);
• हमने कंप्यूटर को यह तय करने दिया कि मौजूदा बाधाओं के आधार पर कौन सा परिवर्तन इष्टतम है।

जैसा कि यह काफी हद तक अभी तक नहीं हुआ है, ठीक है, कंप्यूटर विज्ञान वास्तव में एक युवा क्षेत्र है, और हम अभी भी इसमें से अधिकांश की नवीनता की सराहना कर रहे हैं।

पुनश्च

"कार्यान्वयन को निखारने" से मेरा क्या मतलब है, इसका स्वाद आपको देने के लिए: उदाहरण के लिए, सूची में अंतिम तत्व प्राप्त करने की आसान समस्या के लिए प्रोलाग में लें। कहने के लिए विहित घोषणात्मक समाधान है:

last(List, Last) :-
    append(_, [Last], List).

यहाँ, का घोषित अर्थ append/3है:

List1AndList2का संयोजन है List1औरList2

चूंकि दूसरे तर्क में append/3हमारे पास केवल एक तत्व के साथ एक सूची है, और पहले तर्क को अनदेखा किया गया है (अंडरस्कोर), हमें मूल सूची का एक विभाजन मिलता है जो सूची के सामने ( List1संदर्भ में append/3) का खुलासा करता है और मांग करता है कि पीछे ( List2संदर्भ में append/3) वास्तव में केवल एक तत्व के साथ एक सूची है: इसलिए, यह अंतिम तत्व है।

वास्तविक SWI-Prolog द्वारा प्रदान की कार्यान्वयन , तथापि, का कहना है:

last([X|Xs], Last) :-
    last_(Xs, X, Last).

last_([], Last, Last).
last_([X|Xs], _, Last) :-
    last_(Xs, X, Last).

यह अभी भी अच्छी तरह से घोषणात्मक है। ऊपर से नीचे तक पढ़ें, यह कहता है:

सूची का अंतिम तत्व केवल कम से कम एक तत्व की सूची के लिए समझ में आता है। पूंछ और एक सूची के प्रमुख की जोड़ी के लिए अंतिम तत्व, तब है: सिर, जब पूंछ खाली होती है, या गैर-खाली पूंछ के अंतिम।

इस कार्यान्वयन को प्रदान करने का कारण प्रोलॉग के निष्पादन मॉडल के आसपास के व्यावहारिक मुद्दों पर काम करना है । आदर्श रूप से, यह अंतर नहीं होना चाहिए कि किस कार्यान्वयन का उपयोग किया जाता है। इसी तरह, हम कह सकते थे:

last(List, Last) :-
    reverse(List, [Last|_]).

किसी सूची का अंतिम तत्व प्रत्यावर्तित सूची का पहला तत्व है।

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

Comments

+1 यह दर्शाने के लिए कि कैसे एक घोषणात्मक डिजाइन एक साधारण अमूर्तता से अधिक ठोस कार्यान्वयन के लिए पुनरावृत्त डिजाइन प्रक्रिया के माध्यम से प्रगति कर सकता है।

— इसका मारब

@ बोरिस यह एक अच्छा जवाब है। वह किताब मेरे बुकशेल्फ़ पर बैठी है। शायद यह समय है जब मैंने इसे खोला।

— davidk01

@ davidk01 बेहतर पुस्तकों में से एक है। यह मानता है कि आप सामान्य रूप से प्रोलॉग और प्रोग्रामिंग के साथ काफी सहज हैं, लेकिन प्रोग्रामिंग के लिए यह दृष्टिकोण व्यावहारिक और बहुत गहन दोनों है।

— XXX

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

— इसकी मारू

+1 के लिए "क्या अच्छा है, घोषित प्रोग्लॉग" के बारे में अनिर्णायक चर्चाओं का अपना विवरण प्राप्त करें ... बहुत सही है कि हम असहमत हैं!

— डैनियल ल्योन

Answer 2

तार्किक भाषाएँ पहले से ही ऐसा करती हैं। आप उसी तरह से परिभाषित कर सकते हैं जैसे आप कर रहे हैं।

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

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

यह प्रोग्रामर का काम है कि वह तय करे कि अमूर्त के किस स्तर का उपयोग करना है। आपके द्वारा किए जा रहे एप्लिकेशन के लिए, क्या आप उच्च-स्तर पर जा रहे हैं और इसे सार तरीके से वर्णन करते हैं और प्रदर्शन को हिट करते हैं या कम और गंदे जाते हैं, उस पर 10x अधिक समय खर्च करते हैं, लेकिन एल्गोरिथ्म प्राप्त करें जो 1000x अधिक प्रदर्शनकारी है?

Comments

यह जानने में मदद मिल सकती है कि Golem םול means शब्द का वास्तव में अर्थ है "कच्चा माल" यानी सबसे बुनियादी अवस्था जिस पर मशीन / इकाई हो सकती है।

— 11

घोषणात्मक भाषाएँ स्वाभाविक रूप से अमूर्तता के निचले स्तरों के लिए एक बाधा नहीं हैं। हास्केल और स्टैंडर्ड एमएल दोनों, अपने अलग-अलग तरीकों से, आपको एक ही स्थान पर प्रकार / कार्यों के बारे में सरल घोषणात्मक वक्तव्य देने की अनुमति देते हैं, एक अलग जगह में ठोस और विशिष्ट फ़ंक्शन कार्यान्वयन की एक श्रृंखला प्रदान करते हैं और अभी तक किसी अन्य में कार्यान्वयन के प्रकारों के मिलान के तरीके। इस बीच, ऊ / इंपीरियल भाषाओं में सर्वोत्तम अभ्यास अब उच्च / सरल शुरू करने और फिर कार्यान्वयन विवरण जोड़ने के बारे में बहुत अधिक है। अंतर यह है कि एफपी में उच्च अमूर्तता आसान है, निम्न स्तर आसान है।

— मारू

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

— इसका कर्क

@BAR गोलेम! = गोलम गोलेम यहूदी लोकगीत

— यूफोरिक

इस उत्तर से मेरा तरीका मेरे लैपटॉप पर אמת लिखना है।

— दान जे

Answer 3

यूफोरिक के उत्कृष्ट बिंदु के अलावा , मैं यह जोड़ना चाहूंगा कि हम पहले से ही कई जगहों पर घोषणात्मक भाषाओं का उपयोग कर रहे हैं, जहां वे अच्छी तरह से काम करते हैं, अर्थात राज्य का वर्णन करते हैं जो कुछ को बदलने या अनुरोध करने की संभावना नहीं है जिसके लिए कंप्यूटर वास्तव में कुशल कोड उत्पन्न कर सकता है। अपने दम पर:

• HTML घोषित करता है कि वेब पेज की सामग्री क्या है।

• CSS घोषणा करता है कि वेब पेज में विभिन्न प्रकार के तत्वों को किस तरह देखना चाहिए।

• हर संबंधपरक डेटाबेस में एक डेटा परिभाषा भाषा होती है जो यह घोषणा करती है कि डेटाबेस की संरचना क्या है।

• एसक्यूएल अनिवार्य की तुलना में घोषणात्मक के बहुत करीब है, क्योंकि आप यह बताते हैं कि आप क्या देखना चाहते हैं और डेटाबेस के क्वेरी प्लानर के आंकड़े बताते हैं कि वास्तव में यह कैसे होता है।

• एक तर्क दे सकता है कि अधिकांश कॉन्फ़िगरेशन फाइलें (.vimrc, .profile, .bashrc, .gitconfig) एक डोमेन-विशिष्ट भाषा का उपयोग कर रही हैं जो काफी हद तक घोषणात्मक है।

Comments

मैं GNU मेक, XSLT, Angular.js का व्यापक रूप से उपयोग की जाने वाली चीजों के रूप में उल्लेख करूंगा जो कि घोषणात्मक भी हैं (हालांकि कोणीय शायद परिभाषा को थोड़ा धक्का देता है)।

— मार्क के कोवान

मुझे उस सूची में नियमित अभिव्यक्तियाँ जोड़ने दें।

— Schwern

लोग यह भूल जाते हैं कि घोषणात्मक भाषाएँ आम हैं । वे आम तौर पर पूर्ण भाषाओं को ट्यूरिंग नहीं कर रहे हैं। उस सूची में regex जोड़ें।

— स्लीपबेटमैन

थोड़ा पांडित्यपूर्ण, लेकिन फिर भी: हर डेटाबेस में DDL नहीं होता है, बस बड़ी संख्या में स्कीमालेस NoSQL डेटाबेस के बारे में सोचें। हर रिलेशनल डेटाबेस हो सकता है, लेकिन हर डेटाबेस नहीं।

— मोनिका को बहाल करना -

@dirkk उस के बारे में नहीं सोचा था। मेरा उत्तर ठीक कर दिया।

— Ixrec

Answer 4

सार छलकते हैं

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

आपके विशेष उदाहरण में, आपको एक छँटाई एल्गोरिथ्म मिलेगा - इसका मतलब यह नहीं है कि आपको एक अच्छा या यहां तक ​​कि कुछ उपयोग करने योग्य भी मिलेगा। आपकी दी गई परिभाषा, अगर शाब्दिक रूप से लागू की जाती है (एक संकलक संभावना के रूप में) http://en.wikipedia.org/wiki/Bogosort में परिणाम होता है जो बड़े डेटासेट के लिए अनुपयोगी है - यह तकनीकी रूप से सही है, लेकिन एक हजार संख्याओं को क्रमबद्ध करने के लिए अनंत काल की आवश्यकता है ।

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

Comments

जब तक आप कहते हैं कि यह अनिवार्य रूप से सच है, खराब प्रदर्शन एक अस्थिरता का संकेत नहीं है जब तक कि इंटरफ़ेस / अनुबंध आपको गारंटी नहीं देता है जैसे निष्पादन के समय के बाद।

— वलंटेरी

पीटर्स यह नहीं कह रहे हैं कि खराब प्रदर्शन टपका हुआ अमूर्त, @valenterry का संकेत है। अगर कुछ भी हो, तो वह इसके विपरीत कह रहा है: अच्छा प्रदर्शन प्राप्त करने के लिए, कार्यान्वयन विवरण लीक करने के लिए मजबूर किया जाता है।

— इसका कर्क

मुझे लगता है कि यह कहना भ्रामक है कि अमूर्त सिर्फ इसलिए लीक हो जाता है क्योंकि आपको यह समझने के लिए कार्यान्वयन को समझने की आवश्यकता है कि यह प्रदर्शन को कैसे प्रभावित करता है। एक अमूर्तता का उद्देश्य आपको प्रदर्शन के बारे में सोचने से नहीं रोकता है।

— डोभाल

@jamesqf घोषणात्मक प्रोग्रामिंग में, आप बस यह बताएंगे कि कुछ क्रमबद्ध है। आप कुछ वैरिएबल / प्रॉपर्टी के लिए सॉर्ट ऑर्डर की घोषणा कर सकते हैं। और फिर ऐसा ही होगा। हर बार नए डेटा को जोड़ने या क्रम परिवर्तन को क्रमबद्ध करने के लिए स्पष्ट रूप से कॉल करने की आवश्यकता नहीं होती है।

— हाईड

@jamesqf आप वास्तव में खुद को आजमाए बिना बिंदु नहीं देख सकते हैं (मैं घोषणात्मक विचारों के साथ खेलने के लिए Qt की QML की सिफारिश करूंगा)। किसी ऐसे व्यक्ति की कल्पना करें जो केवल अनिवार्य प्रोग्रामिंग जानता है, और वे वास्तव में वास्तविक की कोशिश किए बिना ओओपी या कार्यात्मक प्रोग्रामिंग के बिंदु को समझने की कोशिश कर रहे हैं।

— १०:१५ को

Answer 5

कम्प्यूटेशनल डिसिडेबिलिटी सबसे महत्वपूर्ण कारण है कि डिक्लेरेटिव प्रोग्रामिंग उतना आसान साबित नहीं हुआ है जितना लगता है।

कई समस्याएं जो राज्य के लिए अपेक्षाकृत आसान हैं, वे अनिर्दिष्ट साबित हुई हैं या हल करने के लिए एनपी-पूर्ण जटिलता है। यह अक्सर तब होता है जब हम नकारात्मक वर्गों और वर्गीकरण, गणना और पुनरावृत्ति को ध्यान में रखते हैं।

मैं कुछ डोमेन के साथ इसकी जांच करना चाहता हूं जो अच्छी तरह से ज्ञात हैं।

निर्णय जिस पर उपयोग करने के लिए सीएसएस वर्ग को सभी सीएसएस नियमों के ज्ञान और विचार की आवश्यकता है। नए नियमों को जोड़ने से अन्य सभी निर्णय अमान्य हो सकते हैं। एनपी-पूर्ण समस्याओं के कारण नकारात्मक सीएसएस कक्षाएं जानबूझकर भाषा में नहीं जोड़ी जाती हैं, लेकिन नकारात्मक कक्षाओं की कमी सीएसएस डिजाइन निर्णयों को जटिल बनाती है।

(SQL) क्वेरी ऑप्टिमाइज़र के भीतर, यह तय करने की शुद्ध समस्या है कि किस क्रम में शामिल होना है, किस अस्थायी उपयोग के लिए और किस मेमोरी को आवंटित करना है। यह एक ज्ञात एनपी-पूर्ण समस्या है और डेटाबेस-डिज़ाइन और क्वेरी फॉर्मूलेशन को जटिल करता है। इसे अलग तरीके से तैयार करने के लिए: जब एक डेटाबेस या एक क्वेरी डिजाइन करते हैं, तो डिज़ाइनर को क्रियाओं और क्रियाओं के क्रम को जानने की आवश्यकता होती है जो क्वेरी ऑप्टिमाइज़र को लेने की संभावना होती है। एक अनुभवी इंजीनियर को प्रमुख डेटाबेस विक्रेताओं द्वारा उपयोग किए जाने वाले अनुमानों के ज्ञान की आवश्यकता होती है।

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

परिणाम यह है कि ये जटिलताएं आश्चर्यचकित करती हैं, वे घोषणात्मक प्रोग्रामिंग की 'सुंदरता' को तोड़ती हैं और वे कुछ इंजीनियरों को अन्य समाधान खोजने के लिए प्रेरित करते हैं। SQL से NoSQL में अनुभवहीन इंजीनियरों का प्रवासन संबंधपरक डेटाबेस की अंतर्निहित जटिलताओं से शुरू हो सकता है।

Comments

"एनपी-पूर्ण समस्याओं के कारण नकारात्मक सीएसएस कक्षाएं जानबूझकर भाषा में नहीं जोड़ी जाती हैं" - क्या आप विस्तृत कर सकते हैं?

— जॉन ड्वोरक

यह थोड़ा सा व्यायाम है, लेकिन नकारात्मक सीएसएस चयनकर्ताओं के साथ इसे 3SAT समस्या के साथ फिर से लिखना संभव है (अंतिम क्लॉज डोम के साथ), जिसमें सभी संभावित संयोजनों की कोशिश करने की आवश्यकता होगी, यह देखने के लिए कि क्या यह मेल खाता है।

— डिब्बेके

छोटा जोड़। CSS 3 और 4 में, नकारात्मक चयनकर्ताओं को अनुमति दी जाती है, लेकिन नहीं: छद्म वर्गों को नेस्टेड नहीं किया जा सकता है।

— डिब्बेके

Answer 6

हमारे पास प्रोग्रामिंग भाषाओं की विकृति में अंतर है जो डिजिटल लॉजिक के सत्यापन में अच्छे उपयोग के लिए रखा गया है।

आम तौर पर डिजिटल लॉजिक को रजिस्टर ट्रांसफर लेवल (RTL) में वर्णित किया जाता है, जहां रजिस्टरों के बीच सिग्नल के लॉजिक स्तर को परिभाषित किया जाता है। यह जाँचने के लिए कि हम अधिक अमूर्त और घोषित तरीके से परिभाषित गुणों को बढ़ा रहे हैं।

अधिक घोषित भाषाओं / भाषा उप - श्रेणियों में से एक को संपत्ति विशिष्टता भाषा के लिए पीएसएल कहा जाता है । एक गुणक के आरटीएल मॉडल का परीक्षण करते समय जिसमें, उदाहरण के लिए पाली के सभी तर्क संचालन और कई घड़ी चक्रों को जोड़ने की आवश्यकता होती है; आप के तरीके से एक संपत्ति लिख सकते हैं assert that when enable is high, this output will equal the multiplication of these two inputs after no more than 8 clock cycles। PSL विवरण को एक सिमुलेशन में RTL के साथ एक साथ जांचा जा सकता है, या PSL औपचारिक रूप से RTL विवरण के लिए धारण करने के लिए साबित हो सकता है।

अधिक घोषणात्मक पीएसएल मॉडल आरटीएल विवरण के समान व्यवहार का वर्णन करने के लिए मजबूर करता है, लेकिन पर्याप्त रूप से अलग तरीके से जिसे देखने के लिए आरटीएल के खिलाफ स्वचालित रूप से जांच की जा सकती है कि क्या वे सहमत हैं।

Answer 7

ज्यादातर समस्या यह है कि आप डेटा को कैसे मॉडल करते हैं; और घोषणात्मक प्रोग्रामिंग यहाँ मदद नहीं कर रहा है। अनिवार्य भाषाओं में आपके पास पहले से ही कई पुस्तकालय हैं जो आपके लिए बहुत सारे सामान करते हैं, इसलिए आपको केवल यह जानना होगा कि क्या कॉल करना है। एक विशेष तरीके से कोई इस घोषणात्मक प्रोग्रामिंग पर विचार कर सकता है (शायद इसके लिए सबसे अच्छा उदाहरण जावा 8 में स्ट्रीम एपीआई है )। इसके बाद, एब्सट्रैक्शन पहले से ही हल हो गया है और घोषणात्मक प्रोग्रामिंग आवश्यक नहीं है।

इसके अलावा, जैसा कि कहा गया है, लॉजिक प्रोग्रामिंग लैंग्वेज पहले से ही वही करती हैं जो आप चाहते हैं। कोई कह सकता है कि समस्या प्रदर्शन है, लेकिन इस क्षेत्र में हार्डवेयर और अनुसंधान के साथ, उत्पादन के उपयोग के लिए तैयार होने के लिए चीजों में सुधार किया जा सकता है; वास्तव में प्रोलॉग का उपयोग एआई सामान के लिए किया जाता है, लेकिन मेरा मानना ​​है कि केवल शिक्षाविदों द्वारा।

यह ध्यान दिया जाना है कि यह सामान्य-प्रयोजन प्रोग्रामिंग भाषाओं के लिए लागू होता है। डोमेन विशिष्ट भाषाओं के लिए, घोषणात्मक भाषाएं बेहतर हैं; SQL शायद सबसे अच्छा उदाहरण है।

Comments

डेटा मॉडलिंग? तुम बात की अनिवार्यता सबसे खराब है उठाया। डेटा मॉडलिंग में हास्केल और एमएल एक्सेल जैसी घोषणात्मक कार्यात्मक भाषाएं। बीजगणितीय डेटा प्रकार और पुनरावर्ती डेटा प्रकार, उदाहरण के लिए, आमतौर पर एक या दो लाइनों में बड़े पैमाने पर परिभाषित किया जा सकता है। निश्चित रूप से, आपके पास लिखने के लिए अभी भी कार्य हैं, लेकिन उनके कोड प्रकार की परिभाषा से स्पष्ट रूप से अनुसरण करते हैं और इसके द्वारा विवश हैं। विचित्र तुलना करने के लिए।

— इसका मारु

@itsbruce सबसे वास्तविक डेटा ADT पर आसानी से मैप नहीं किया जाता है; सोचें कि अधिकांश डेटाबेस कैसे काम करते हैं। जैसा कि प्रोलॉग - एरलैंग, आप सही हैं, वे अलग-अलग भाषाएं हैं। मैंने उल्लेख किया कि एक कार्यात्मक है जबकि दूसरा तार्किक है लेकिन सबसे अच्छा है अगर मैं पूरी तुलना को हटा दूं।

— m3th0dman

@ m3th0dman एक डेटाबेस ट्यूपल्स / रिकॉर्ड्स का एक टन है। हास्केल वहाँ थोड़ा अपंग है, क्योंकि उसके पास रिकॉर्ड्स की कमी है, लेकिन उसके पास ट्यूपल्स हैं, और एमएल के पास दोनों हैं। और हास्केल के मामले में एक नए छद्म रिकॉर्ड डेटाटाइप को घोषित करने के लिए आवश्यक बॉयलरप्लेट की मात्रा अभी भी औसत सांख्यिकीय-टाइप ओओपी भाषा में एक अशुद्ध-संरचना बनाने की तुलना में बहुत छोटी है। क्या आप इस बात की विस्तृत जानकारी दे सकते हैं कि कैसे सबसे अधिक डेटा आसानी से ADTs में मैप नहीं किया जाता है?

— डोभाल

@ m3th0dman आह, इसीलिए डेटाबेस स्कीमास को कार्य के अनुकूल एक अनिवार्य भाषा में परिभाषित किया गया है। ओह, नहीं, यह घोषणात्मक DDL होगा। वास्तव में, डेटा मॉडलिंग की समग्र प्रक्रिया उस एप्लिकेशन के लिए प्रासंगिक है जो इसके साथ काम करेगी, डेटा प्रवाह और संरचनाएं, न कि एप्लिकेशन को लागू करने वाली भाषा। कभी-कभी वे किसी भाषा की OO विशेषताओं से मेल खाने के लिए विकृत होते हैं और इसका ORM समर्थन करता है, लेकिन यह आमतौर पर एक बुरी बात है, एक विशेषता नहीं। वैचारिक / तार्किक डेटा मॉडल को व्यक्त करने के लिए घोषणात्मक भाषाएँ बेहतर अनुकूल हैं।

— इसकी

@itsbruce मैं यह नहीं कह रहा था कि प्रक्रियात्मक प्रतिमान डेटा को परिभाषित करने की घोषणा से बेहतर है; मैं कह रहा था कि प्रक्रियात्मक एक (सामान्य प्रयोजन की भाषाओं के लिए) की तुलना में घोषणात्मक प्रतिमान बेहतर (न ही बदतर) है। डेटा में हेरफेर करने के लिए, वास्तविक जीवन के अनुप्रयोगों के लिए एसक्यूएल का घोषित हिस्सा पर्याप्त नहीं है; अन्यथा किसी ने भी प्रक्रियात्मक विस्तार का आविष्कार और उपयोग नहीं किया होगा। लेख के लिए, मैं इसे सार से असहमत हूं जहां यह ब्रूक्स का विरोध करता है; उन्होंने वास्तविक परियोजनाओं से अपने विचारों का निर्माण किया, जबकि उन लोगों ने अपने सिद्धांत को साबित करने के लिए कुछ भी उत्कृष्ट नहीं बनाया।

— m3th0dman 21

Answer 8

यह कुछ इस तरह दिखेगा .. {(जो भी => एक फ़ाइल पढ़ें और एक यूआरएल कॉल करें) | एक url को कॉल करें और एक फ़ाइल पढ़ें} हालांकि, ये निष्पादित करने के लिए क्रियाएं हैं, और परिणामस्वरूप सिस्टम की स्थिति बदल जाती है, लेकिन यह स्रोत से स्पष्ट नहीं है।

घोषणाएं एक परिमित राज्य मशीन और उसके संक्रमण का वर्णन कर सकती हैं। FSM क्रियाओं के बिना घोषणाओं के विपरीत की तरह है, भले ही कार्रवाई को अगले राज्य में बदलना है।

इस पद्धति का उपयोग करने का लाभ यह है कि संक्रमण और कार्यों को केवल एक के बजाय कई संक्रमणों पर लागू होने वाले विधेय द्वारा निर्दिष्ट किया जा सकता है।

मुझे पता है कि यह थोड़ा अजीब लगता है, लेकिन 2008 में मैंने एक प्रोग्राम जनरेटर लिखा था जो इस पद्धति का उपयोग करता है, और उत्पन्न सी ++ स्रोत से 2 से 15 गुना अधिक है। अब मेरे पास 20,000 लाइनों के इनपुट से C ++ की 75,000 से अधिक लाइनें हैं। इसके साथ दो चीजें चलती हैं: स्थिरता और पूर्णता।

निरंतरता: कोई भी दो भविष्यवाणी नहीं करता है जो एक ही समय में सच हो सकते हैं, असंगत कार्यों को लागू कर सकते हैं, जैसा कि दोनों x = 8 और x = 9, और न ही अगले राज्यों में।

पूर्णता: प्रत्येक राज्य संक्रमण के लिए तर्क निर्दिष्ट है। एन सबलेट्स के साथ सिस्टम के लिए जांच करना मुश्किल हो सकता है,> 2 ** एन राज्यों के साथ, लेकिन दिलचस्प कॉम्बिनेटरियल तरीके हैं जो सब कुछ सत्यापित कर सकते हैं। 1962 में मैंने 7070 मशीनों के लिए एक सिस्टम प्रकार का चरण 1 लिखा, इस तरह के सशर्त कोड जनरेशन और कॉम्बिनेटरियल डिबग का उपयोग करते हुए। सॉर्ट में 8,000 लाइनों में से, पहली रिलीज के दिन से बग की संख्या हमेशा के लिए शून्य थी!

12,000 लाइनों में से दो चरण में, पहले दो महीनों में 60 से अधिक त्रुटियां थीं। इस बारे में कहने के लिए बहुत कुछ है, लेकिन यह काम करता है। यदि कार निर्माता फर्मवेयर की जांच करने के लिए इस पद्धति का उपयोग करते हैं, तो हम उन विफलताओं को नहीं देखेंगे जो अब हम देखते हैं।

Comments

यह वास्तव में मूल प्रश्न का उत्तर नहीं देता है। इस तथ्य में स्थिरता और पूर्णता का कारक कैसे है कि अधिकांश प्रोग्रामिंग अभी भी प्रक्रियात्मक है, घोषित नहीं है?

— जे एलस्टन

आपका आरंभिक पैराग्राफ़ अर्नॉड के उत्तर प्रोग्रामर्स में एक बिंदु का उत्तर प्रतीत होता है ।stackexchange.com/a/275839/67057 , सवाल ही नहीं। यह वहाँ एक टिप्पणी होनी चाहिए (मेरी स्क्रीन पर, आपका जवाब अब उसके नीचे नहीं है, एक बात के लिए)। मुझे लगता है कि आपका बाकी का जवाब इस बात का चित्रण है कि थोड़ी मात्रा में घोषणात्मक कोड कितनी बड़ी मात्रा में समान अनिवार्यता उत्पन्न कर सकता है लेकिन यह स्पष्ट नहीं है। आपके उत्तर को विशेष रूप से मुख्य बिंदुओं के संबंध में कुछ ख़ुशी की आवश्यकता है।

— इसका कर्कट

Answer 9

हर चीज को घोषणात्मक तरीके से नहीं दिखाया जा सकता है।

अक्सर, आप स्पष्ट रूप से निष्पादन के प्रवाह को नियंत्रित करना चाहते हैं

उदाहरण के लिए छद्म संहिता का पालन if whatever read a file call an URL else call an URL write a file करना : आप इसे कैसे घोषित करेंगे?

यकीन है, वहाँ शायद यह करने के लिए कुछ विदेशी तरीके हैं। सन्यासी की तरह । लेकिन ये आमतौर पर अपने प्रक्रियात्मक भाग की तुलना में अधिक बोझिल, जटिल और बहुत कम सहज होते हैं।

यह सब इस तथ्य से उबलता है कि आपके पर्यावरण / प्रणाली के साथ "बातचीत" घोषणात्मक नहीं है । I / O से संबंधित सब कुछ सार रूप से प्रक्रियात्मक है। आपको यह बताना होगा कि कब और क्या होना चाहिए, और किस क्रम में होना चाहिए।

घोषणात्मक हर चीज के लिए महान है जो विशुद्ध रूप से गणना से संबंधित है। एक विशाल समारोह की तरह, आप एक्स को अंदर डालते हैं और आपको वाई मिलता है। यह बहुत अच्छा है। इसका एक उदाहरण HTML है, इनपुट टेक्स्ट है, आउटपुट वह है जो आप अपने ब्राउज़र में देखते हैं।

Comments

मैं इसे नहीं खरीदता। आपका उदाहरण घोषणात्मक क्यों नहीं है ? क्या यह if/ else, किस स्थिति में एक घोषणात्मक वैकल्पिक जैसा दिखेगा? यह निश्चित रूप से read/ write/ callभागों नहीं है, क्योंकि वे मूल्यों की अच्छी घोषणात्मक सूची हैं (यदि आप आसन्न हैं कि वे किसमें लिपटे हुए हैं {...; ...}, तो वे क्यों नहीं लिपटे [..., ...]हैं;) कई अन्य भी करेंगे। मैं यह नहीं देखता कि भिक्षु यहां प्रासंगिक क्यों हैं; वे सिर्फ एक एपीआई हैं। हास्केल धारा रचना -> मोनड्स से मैनुअल संरचना की सहायता के लिए गया था, लेकिन तर्क भाषाएं सूचियों को स्वचालित रूप से क्रमबद्ध कर सकती हैं।

— वारबो

-1 मोनाड्स के लिए। 1. वे वास्तव में विदेशी नहीं हैं (सूची और सेट मोनड हैं और हर कोई उनका उपयोग करता है)। 2. वे बातें एक विशिष्ट क्रम में किया जा करने के लिए मजबूर साथ लेना देना नहीं है (हास्केल कर अंकन दिखता अनिवार्य लेकिन नहीं है)। घोषणात्मक / कार्यात्मक भाषाएं संबंधों और निर्भरता को निर्दिष्ट करती हैं। यदि फ़ंक्शन X को इनपुट Y की आवश्यकता है, तो X से पहले Y उत्पन्न होगा। निर्भरताएं सही प्राप्त करें और घटनाओं का उचित क्रम स्वयं को परिभाषित करेगा। बहुत अधिक बातचीत ईवेंट संचालित है, एक सेट अनुक्रम में नहीं। घोषणा की भाषाएँ कठिन घटनाओं पर प्रतिक्रिया नहीं करती हैं।

— इसका मार्ब

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

— इसका मारब

@Itsbruce उदाहरण के अलावा प्रतिक्रियाशील प्रोग्रामिंग घोषणात्मक माना जाता है और पर्यावरण के साथ बातचीत के बारे में है।

— मिकीज पीचोटका