क्या UNIX दर्शन में प्रोग्रामिंग कार्यात्मक प्रोग्रामिंग के समान है?


30

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

बस लिनक्स प्लेटफ़ॉर्म का उपयोग करते हुए, अवधारणा बहुत स्पष्ट है और हर समय उपयोग किया जाता है। कमांड लाइन पर कोई भी अभिव्यक्ति जो I / O को पुनर्निर्देशित करती है, सिस्टम टूल जैसे ls, grep, more, और इसी तरह यह दर्शाता है कि यह अवधारणा कितनी शक्तिशाली है।

मुझे भ्रमित करने वाली बात यह है कि इन कार्यक्रमों में से कई सी में लिखे गए हैं, एक अनिवार्य / प्रक्रियात्मक प्रोग्रामिंग शैली का उपयोग करते हुए, फिर भी जिस तरह से वे उपयोग किए जाते हैं और कमांड लाइन पर एक साथ जुड़ते हैं, वह मुझे और अधिक कार्यात्मक प्रोग्रामिंग की तरह लगता है, जहां प्रत्येक कार्यक्रम है एक अलग-थलग कार्य जो किसी भी अन्य कार्यक्रम की स्थिति पर निर्भर नहीं करता है, वह इसमें शामिल हो सकता है।

क्या यह सटीक है, UNIX प्रोग्रामिंग दर्शन को समझना मूल रूप से कार्यात्मक प्रोग्रामिंग का उपयोग करना है जो कि अनिवार्य प्रोग्रामिंग शैली का उपयोग करके बनाया गया हो सकता है?


5
मुझे नहीं लगता कि यह महत्वपूर्ण है कि सादृश्य सटीक है या नहीं। सवाल यह है कि क्या यह आपके लिए एक उपयोगी उपमा है? क्या उन शर्तों के बारे में सोचने से आपको कार्यक्रम लिखने और काम करने में मदद मिलती है?

जवाबों:


19

मैं तुम्हें एक मतलब नहीं पहुंच चुका है, लेकिन cp, rm, cdऔर दूसरों के एक बहुत, स्थिति बदल तो वे वास्तव में काम करता है नहीं कर रहे हैं। UNIX दर्शन केवल एक ही काम करने के बारे में अधिक है, लेकिन यह अच्छी तरह से कर रहा है; अक्सर इसे अच्छी तरह से करने का अर्थ है कार्यात्मक उपयोग की अनुमति देना, लेकिन हमेशा नहीं।


9

इसका जवाब ओलेग किसलीव द्वारा "मोनाडिक i / o और UNIX शेल प्रोग्रामिंग" में है।

यह फिलिप वाडलर के पेपर "हाउ टू डिक्लेयर ए इंपीरेटिव " [ Wadler97 ] से प्रेरित निबंध है । हम हास्केल में मोनैडिक i / o, और UNIX फ़िल्टर रचनाओं के बीच पाइप और पुनर्निर्देशन के बीच असमान समानताएं दिखाएंगे। UNIX पाइप (अस्थायी फ़ाइलों के लेखन के रूप में शब्दशः) मोनाड के समान हैं। इसके अलावा, UNIX प्रोग्रामिंग के स्तर पर, सभी i / o को विवादास्पद माना जा सकता है ...


6

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


1
क्या आपको वाकई हवाई जहाज मिला है ?? ;) (
अपमानजनक

@BlackBear मेरा अपना व्यक्तिगत नहीं है। मैं एक ऐसे क्लब में हूँ जहाँ हममें से लगभग 50 लोग सामूहिक रूप से 4 हवाई जहाज रखते हैं। यह उस तरह से थोड़ा अधिक सस्ती है। :-)
ब्रायन नोब्लाच

@Brian Knoblauch: मैं भविष्य में एक हवाई जहाज रखना चाहता हूँ .. पैसे की अनुमति: P
ब्लैकबियर

5
कार्यात्मक प्रोग्रामिंग का अर्थ "कोई साइड-इफेक्ट" नहीं है। वह अवधारणा जहां एक ही कार्य हमेशा एक ही परिणाम उत्पन्न करता है, उसे "idempotence" कहा जाता है और एक कार्यक्रम के कार्यात्मक होने के लिए यह आवश्यक शर्त नहीं है। इसे "शुद्ध कार्यात्मक" के रूप में भी जाना जाता है।

2

एक हद तक आप ऐसा कह सकते हैं। लेकिन यह सच नहीं है। मुझे लगता है कि आपको एक सरलीकृत डिजाइन दृष्टिकोण के साथ 'और अधिक प्राप्त करने की क्षमता' के रूप में पढ़ना चाहिए। और सरल होने के लिए आपको कार्य को आसानी से समझने योग्य और भागों को इकट्ठा करने के लिए आसान में विभाजित करना होगा। UNIX दर्शन आपके साथ स्पष्ट होना चाहिए, निम्नलिखित उदाहरण के साथ समझाया जा सकता है।

सभी प्रोग्रामिंग डेटा हेरफेर के कुछ प्रकार है! और कुछ मामलों में प्रोग्रामिंग भी प्रोग्राम हेरफेर ही है (मेटा प्रोग्रामिंग)। अब जिस तरह से UNIX दर्शन काम करता है, इमेज प्रोसेसिंग टेक्स्ट है। पाठ क्या है? पाठ किसी प्रकार का डेटा है। जब संगठित परिभाषा में इकट्ठा होता है तो पाठ XML का और JSON का भी हो जाता है। पाठ भी संख्याओं की एक सूची हो सकती है, पाठ भी हो सकता है csv, tsv का और क्या नहीं! अन्य पाठ या स्ट्रिंग में प्रोग्रामिंग डेटा के एक वास्तविक विशाल क्षेत्र का प्रतिनिधित्व कर सकते हैं, सिर्फ इसलिए कि इसका संदर्भ मुड़ सकता है और हम जो चाहते हैं उसमें बदल सकते हैं!

सभी प्रोग्रामिंग के लिए किसी प्रकार के डेटा संगठन की आवश्यकता होती है। आयोजन के लिए खोज की आवश्यकता है ...

ए। वहाँ आप बस 'grep', 'fgrep' और उसके परिवार के साथ जाते हैं।

एक बार जब आप खोज करते हैं तो आपको कुछ छांटने की जरूरत होती है।

ख। अब हमारे पास ऐसा करने के लिए 'सॉर्ट' कमांड है।

आपने अभी दो फ़ाइलों को सॉर्ट किया है, अब आप उनकी तुलना करना चाहते हैं।

सी। अब हमारे पास ऐसा करने के लिए 'diff', 'cmp' et al है।

आपने अभी-अभी पाया है कि फाइलों में कोई अंतर नहीं है। अब आपको संगठित डेटा की अधिक आवश्यकता है।

घ। आपके पास फ़ाइल में लिखने के लिए 'कैट', पाइप और पुनर्निर्देशन ऑपरेटर हैं।

आपको अधिक विशिष्ट पार्सिंग की आवश्यकता है ..

ई। आपके पास सिर, पूंछ, अधिक, कम, कट करने के लिए एट अल है कि ...

यह सब एक साथ 'का उपयोग कर सीना।' किसी भी कोड को लिखने के बिना कुछ समय के लिए वास्तविक शक्तिशाली सामान उत्पन्न करने के लिए। अधिक खोज और सिलाई के लिए आपके पास ।।

च। awk, shell और sed।

awk, shell और sed आपको पाठ पर अधिक नियंत्रण देते हैं कि क्या कट, diff एट अल आपको दे सकता है। क्या आपने कभी सोचा है कि कमांड 1 | कमांड 2 | कमांड 3 ... श्रृंखला एक प्रकार का वर्कफ़्लो तंत्र है। इफ के साथ संयुक्त होने पर यह अधिक शक्तिशाली हो जाता है।

अब और मज़ा आता है।

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

इसलिए मुझे लगता है कि UNIX एक ऑपरेटिंग सिस्टम से अधिक है। यह सबसे सरल तरीके से समस्याओं को हल करने के लिए डिज़ाइन किए गए उपकरणों और पर्यावरण का एक संग्रह है। एक सरल तरीका जरूरी नहीं कि समाधान के कार्यान्वयन की सादगी है। लेकिन सादगी ही आपको बहुत दूर तक नहीं ले जाती है।

मैंने इसे रेडिट पर कुछ पढ़ा।

"यदि आपका एकमात्र डिजाइन लक्ष्य सादगी है, तो आपको प्लान 9 के रूप में कई उपयोगकर्ता मिलेंगे"


1

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

उम्मीद है की यह मदद करेगा,

-tjw

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.