जीयूआई बनाम सीएलआई - अंतिम लड़ाई

वास्तविक प्रोग्रामर का मानना ​​है कि उन्होंने कमांड लाइन इंटरफेस की तुलना में बेहतर कुछ भी नहीं खोजा है और कभी नहीं होगा, क्योंकि वहाँ कहीं भी बेहतर नहीं है। स्वाभाविक रूप से, मैं बहस करना चाहता हूं।

एक दूसरे को बेहतर ढंग से समझने के लिए, आइए सार संतरे के बारे में बात करते हैं। अगर आपने सुना या कोई कोशिश की थी तो ऑटोकैड की कल्पना करें। आप Illustrator या CorelDro, प्रोग्रामिंग से कुछ दूर, अमूर्त और खुले तौर पर कारण बता सकते हैं। वे कंसोल में काम क्यों नहीं कर सकते?


अंजीर। 1. एक वैक्यूम में सार इंटरफ़ेस।

पहला: आपको जो कुछ हो रहा है उसकी एक सामान्य तस्वीर होनी चाहिए। एक कमांड लिखना (get-lines) और एक ईमानदार सूची प्राप्त करना (((0 12) (5 12)) ...) एक व्यक्ति के लिए असुविधाजनक है। आदेशों की मदद से वर्तमान स्थिति को समझने की कोशिश कीहोल के माध्यम से नोट्स का आदान-प्रदान करना है कि कैसे हवा बदबू आती है और कैसे संगीत (अभिव्यंजना के संदर्भ में) और विधि का उपयोग करते हुए नौकरशाही की तरह शुद्ध पानी ध्वनि जब एक प्रमाण पत्र केवल एक सही ढंग से लिखित बयान द्वारा जारी किया जाता है, तो आप केवल अपनी गलती के बारे में पता लगाएंगे। दाखिल करने के बाद, और भविष्य में आवेदन को बार-बार लिखना होगा। और, हां, यह पता लगाने के लिए कि किस तरह के अनुरोधों को बिल्कुल प्रस्तुत किया जा सकता है, आपको एक अलग अनुरोध करने की आवश्यकता है।

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

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

यह कुछ ऐसा प्रतीत हो सकता है, इसके विपरीत, एक अनुरोध-प्रतिक्रिया शैली इंटरफ़ेस एक व्यक्ति के लिए अधिक स्वाभाविक है - आखिरकार, यह है कि हम जीवन में लोगों के साथ एक संवाद कैसे बनाते हैं। कार्यों की संख्या की गणना करें और तुलना करें। एक काल्पनिक सांत्वना में, मैं:

1. यह किसी तरह इंगित करना होगा कि किस खंड को स्थानांतरित करना है, अर्थात एक अद्वितीय विशेषता द्वारा खंड के लिए एक खोज अनुरोध की रचना और जांच; एक संकेत का भी आविष्कार किया जाना है;
2. इसी तरह दूसरे खंड के अंत का पता लगाएं;
3. एक कमांड दें और पिछले कमांड के परिणाम को पास करें;
4. किसी तरह सुनिश्चित करें कि क्या आवश्यक है, और केवल वही है जो आवश्यक है;
5. सुनिश्चित करें कि यह वही है जो मैं चाहता था।

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


अंजीर। 2. git log --graph --pretty=oneline --abbrev-commit का आउटपुट git log --graph --pretty=oneline --abbrev-commit । स्मृति से खेलें?

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

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

और अब अच्छे के लिए। लचीलापन। पावर। पकौड़ी। मैं बेवकूफ नहीं हूं और मैं यह तर्क नहीं देता हूं कि बैश + यूनिक्स बर्तन एक शक्तिशाली गुच्छा है। यहां केवल उत्साह आमतौर पर इस तथ्य से जुड़ा होता है कि बैश फ़ाइल सिस्टम के लिए स्क्रिप्टिंग भाषा की ऐसी REPL है जिसका इंटरफ़ेस सफलतापूर्वक कंप्लीट करता है (देखें, उदाहरण के लिए, इसे mc या Far में कैसे बनाया गया है, और हाँ, ये कमांड लाइन इंटरफेस नहीं है)। कार्यक्रम में REPL के साथ एक स्क्रिप्टिंग भाषा होना अच्छा है, इससे इंटरफ़ेस अधिक जटिल कार्यों के लिए उपयुक्त है। (एक पुराना पाठक जानता है कि ऑटोकैड में एक लिस्प कंसोल भी है, और इसमें सूचीबद्ध सभी भयानक चीजें की जा सकती हैं - वस्तुओं की तलाश करें, लाइनों को स्थानांतरित करें)। लेकिन ऊपर वर्णित कारणों के कारण, याद रखें कि यह लचीलेपन के लिए प्रयोज्य का एक आदान-प्रदान है, यही कारण है कि क्ली में केवल सबसे सरल उपयोगिता कार्य संभव हैं। और यह बिल्कुल ग्राफिकल इंटरफेस का सार और प्रतिभा है।


अंजीर। 3. टीम मोड ऑटोकैड।