यूनिक्स / सी में असंगति और अपूर्णता के उदाहरण क्या हैं?


20

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

एक अन्य उदाहरण जो मैं लेकर आया हूं वह संख्याओं के अलग-अलग तरीके हैं। लिस्प मनमाने ढंग से बड़ी संख्या (स्मृति के आकार तक) का प्रतिनिधित्व कर सकता है, जबकि सी एक निश्चित संख्या में बिट्स (आमतौर पर 32-64) तक सीमित करता है। मुझे लगता है कि इससे शुद्धता का पता चलता है।

स्थिरता और पूर्णता के लिए कुछ उदाहरण क्या हैं? यहाँ गेब्रियल के सभी विवरण दिए गए हैं (जो वह मानते हैं कि वे कारिसे हैं):

MIT / स्टैनफोर्ड दृष्टिकोण

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

न्यू जर्सी दृष्टिकोण

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

कृपया ध्यान दें कि मैं यह नहीं पूछ रहा हूं कि क्या गेब्रियल सही है (जो स्टैकएक्सचेंज के लिए उपयुक्त नहीं है), लेकिन उदाहरण के लिए कि वह किस बात का जिक्र कर रहा होगा।


6
यदि आप उत्सुक हैं, तो यह एक होमवर्क समस्या नहीं है। मैं शिक्षक हूं। :-) दूसरे विचार पर, शायद इससे मेरा होमवर्क हो जाता है।
एलेन स्पार्टस

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

क्या यह सवाल programmers.stackexchange.com पर अधिक उपयुक्त नहीं है ?
बेसिल स्टायरेंविच

मैंने इसे CS में पोस्ट किया क्योंकि मैं भाषा डिजाइन को कंप्यूटर विज्ञान के मूलभूत गहरे क्षेत्रों में से एक मानता हूं, जिसमें कम्प्यूटेबिलिटी, जटिलता, वास्तुकला, प्रयोज्य, आदि को शामिल किया गया है, जिसे मैं यूनिक्स / लिनक्स में पोस्ट कर सकता था, हालांकि मैं एक व्यापक की तलाश में था। राय। प्रोग्रामर के रूप में, लोग मेरे साथ लगभग हमेशा शत्रुतापूर्ण होते हैं जब मैं वहां पोस्ट करता हूं, तब भी जब मुझे लगता है कि मैं विषय पर हूं, इसलिए मैं वहां से दूर रहता हूं।
एलेन स्पार्टस

जवाबों:


15

प्रश्न के शीर्षक से पता चलता है कि कुछ बुनियादी यूजर इंटरफेस विसंगतियां आपकी रुचि ले सकती हैं:

यूनिक्स कमांड विकल्प और झंडे को निर्दिष्ट करने के लिए किसी विशेष वाक्यविन्यास का पालन नहीं करते हैं। उदाहरण के लिए, अधिकांश कमांड ध्वज के रूप में '-' से पहले के एकल अक्षरों का उपयोग करते हैं: cat -n some_fileलेकिन अपवाद सामान्य रूप से उपयोग किए जाने वाले आदेशों की तरह हैं tar tf some_file.tarऔर dd in=some_file out=some_other_file count=2मौजूद हैं।

यूनिक्स और उसके वंशज और रिश्तेदारों के पास कई अलग-अलग नियमित अभिव्यक्ति वाक्यविन्यास हैं। गोले "*" का उपयोग करते हैं जहां अन्य कार्यक्रम (grep, egrep, vi) '*।' का उपयोग करते हैं। egrep में '+' और '|' ऑपरेटरों के रूप में, grep नहीं करता है।

मूल "सब कुछ एक फ़ाइल है" सिस्टम कॉल इंटरफ़ेस को अपूर्ण के रूप में देखा जा सकता है: पढ़ना / लिखना / तलाश करना / बंद करना हर I / O डिवाइस के लिए उपयुक्त नहीं है। बुरी तरह से आवश्यक अपवाद "ioctl" कॉल में लुप्त हो जाते हैं, लेकिन साउंड कार्ड जैसे उपकरण बहुत अच्छी तरह से फिट नहीं होते हैं।


अच्छा उत्तर। जब मैंने शीर्षक देखा तो मैं तुरंत "ioctl" (और fcntl) सोच रहा था, लेकिन अब मुझे जवाब लिखने की जरूरत नहीं है।
लुईस

1
ग्लोब पैटर्न regexs
jk

8

संगति

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

संपूर्णता

लिस्प में, यदि आपके पास कोई विशिष्ट भाषा विशेषता नहीं है जिसकी आपको आवश्यकता है, तो आप इसे मैक्रोज़ के साथ स्वयं लागू कर सकते हैं। सी में भी प्रीप्रोसेसर है, लेकिन यह बहुत ही खराब है।


8

C के तार में वर्ण 0 नहीं हो सकता है और इसके लाइब्रेरी फ़ंक्शंस बाइनरी डेटा से निपटने के लिए अनुपयुक्त हैं।

यूनिक्स सिस्टम पर फाइल में वर्ण 0 या वर्ण 47 (स्लैश) नहीं हो सकता है।

यूनिक्स के मूल कार्यान्वयन में, फ़ाइलनाम 14 वर्णों तक सीमित थे। बाद के संस्करणों ने केवल इस सीमा में ढील दी; उन्होंने इसे खत्म नहीं किया।

जोड़ा गया : E2BIGसिस्टम त्रुटि स्थिति, जब किसी ने execएक तर्क सूची के साथ प्रयास किया, जिसमें बहुत सारे तर्क थे, या बहुत अधिक स्मृति पर कब्जा कर लिया था, या एक वातावरण जो बहुत बड़ा था।

यूनिक्स इस प्रकार की मनमानी सीमा के लिए कुख्यात है। 1987 में पर्ल के आगमन तक, बड़े डेटा सेट, या डेटा रिकॉर्ड लंबे रिकॉर्ड, या बाइनरी डेटा से निपटना बेहद अविश्वसनीय था।


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

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

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

मुझे समझ नहीं आ रहा है कि आपकी बात क्या है। सवाल "यूनिक्स / सी में असंगति और अपूर्णता के उदाहरण" के लिए पूछता है; इसमें प्रदर्शन का उल्लेख नहीं है।
मार्क डोमिनस

1
@ राफेल: आप एक pathअमूर्त डेटा प्रकार को परिभाषित करके मूर्खतापूर्ण विभाजक समस्याओं से छुटकारा पा लेते हैं , और एक विशेष कार्यान्वयन (अशक्त-असाइसी स्ट्रिंग्स) को उजागर करने के बजाय अपने इंटरफेस में उपयोग करते हैं।
भटकते हुए तर्क

4

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


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

3

मेरे पास सबसे अच्छा उदाहरण गरीब उपयोगकर्ता है, जिसके पास एक फ़ाइल है जिसका नाम .. -rऔर टाइप किया गया है rm *

यह कहानी सच है या नहीं, यह एक यूनिक्स हेटर्स क्लासिक बन गया है।

यूनिक्स-हैटर्स हैंडबुक देखें , जिसमें कई उदाहरणों के लिए खुद डेनिस रिची द्वारा एक परिचय है।

मैं आगे जोड़ूंगा कि इस प्रकार की समस्याओं से बचना Microsoft के Power Shell के डिजाइन में एक बड़ी ताकत थी।


मैंने द यूनिक्स-हैटर्स हैंडबुक के पीछे रिचर्ड गेब्रियल का निबंध पढ़ा। :-)
एलेन स्पार्टस

3
  • निश्चित रूप से आदेशों के लिए एक ही (लघु) झंडे के असंख्य अर्थ एक असंगतता है।
  • प्रत्येक प्रोग्राम जो नियमित अभिव्यक्ति का उपयोग करता है, यह उनके लिए स्वयं का वाक्यविन्यास है
  • सेवाओं के लिए कॉन्फ़िगरेशन फ़ाइलें सभी अलग-अलग सिंटैक्स हैं (जो कि भाग में माफ की जा सकती हैं, आपके मेलर डेमन में आपके वेबसर्वर या सिस्टम स्टार्टअप के साथ बहुत कम है, लेकिन फिर भी)
  • अलग-अलग संपादक हैं! उपयोगकर्ता विभिन्न गोले का उपयोग करते हैं !! इतने सारे डेस्कटॉप वातावरण क्यों हैं?!?

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

तो, हाँ, यूनिक्स असंगत है। तो अन्य सिस्टम हैं, बस अलग ;-)


2

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

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

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