COBOL मेरी सीखी गई पहली भाषाओं में से एक थी - यदि आप बेसिक, तीन या चार कोडर भाषाओं के अनगिनत संस्करणों और फोर्थ के एक संस्करण को अनदेखा करते हैं, तो यह मेरे पहले पांच में था, और पास्कल के साथ समवर्ती रूप से सीखा। IOW, मैं भाषा का उपयोग करते हुए व्यक्तिगत अनुभव से उत्तर दे रहा हूं।
EDIT मैं प्राचीन अनुभव कहना चाहिए । मैंने 80 के दशक के अंत के बाद भाषा का इस्तेमाल कभी नहीं किया, हालांकि मैंने एक नई किताब खरीदी थी (पुरानी को हटाने के लिए जिसे मैंने घृणा में फेंक दिया था) ताकि मुझे कुछ संदर्भित हो ताकि मेरी डरावनी कहानियाँ बहुत विकृत न हों। लेकिन मुझे नहीं पता कि कम से कम पिछले 20 वर्षों में भाषा कैसे विकसित हुई है।
जाहिर है, कई लोगों के लिए, यह है और यह भी बहुत अधिक एक तीसरे हाथ पारित मुझे-नीचे नजरिए बात - सिर्फ इतना है कि "पुराने खराब है" देखने कि jonsca पहले से ही वर्णन किया है। लेकिन वास्तविक मुद्दे अंतर्निहित हैं।
बहुत अधिक चिंताजनक होना एक वास्तविक समस्या है - कोड को समझने के तरीके में बहुत अधिक अव्यवस्था है। यह अब तक का सबसे बड़ा मुद्दा है। जो लोग को देखो MOVE, ADDऔर MULTIPLYआतंक में आदि बयान, इस बात का एक थोड़ा अतिरंजित भय व्याप्त है सच - COMPUTEबयान अन्य भाषाओं में कार्य के करीब है। लेकिन उन सभी डिवीजनों और वर्गों में अभी भी बहुत अव्यवस्था है। COBOL में सीखी गई पहली चीजों में से एक हमेशा एक मानक पृष्ठ-ए-4-लॉन्ग SKELETON.COB की प्रतिलिपि बनाकर शुरू करना था।
कोबोल करता है कुछ दिलचस्प सुविधाओं है, लेकिन उन सुविधाओं (जैसे PICबात) चीजें हैं जो डीबीएमएस के बजाय प्रोग्रामिंग भाषा के अब और अधिक हिस्सा हैं हो जाते हैं, और कहा कि करने के लिए मुझे लगता है आम तौर पर एक बेहतर तरीका उन ज़िम्मेदारियों को अलग करने के लिए हो सकता है। साथ ही, अन्य भाषाओं की कुछ लाइब्रेरी कुछ तुलनात्मक उपयोग करती हैं PIC(जैसे C मानक लाइब्रेरी में प्रिंटफ़ और स्कैनफ़)। यकीनन, सबसे अच्छा रखा गया है, लेकिन सबसे खराब है।
इसके अलावा, हर अच्छी सुविधा के लिए, कम से कम एक असहनीय था। उदाहरण के लिए, चाहे कितना ही तुच्छ क्यों न हो, आपको शरीर को एक अलग प्रक्रिया में ले जाना होगा। PERFORM ... UNTIL ...और इसी तरह के बयान कर रहे हैं एक बयान - संरचनाओं ब्लॉक नहीं। एक अर्थ में, COBOL संरचित प्रोग्रामिंग का आविष्कार करने से पहले संरचित प्रोग्रामिंग का एक स्वाद था - एक थाGO TO , लेकिन इसका उपयोग हतोत्साहित किया गया था (कम से कम जब मैं कॉबोल का उपयोग करता था), लेकिन विशेष रूप से लूपिंग को अच्छी तरह से संभाला नहीं गया था।
वास्तव में, जो भाषा मैंने COBOL के बाद इस्तेमाल की थी, जो मुझे सबसे ज्यादा याद दिलाती थी ... dBase। जैसा कि एश्टन-टेट dBase III + में है। इन दिनों, लोगों को अब सभी मृत-या-मरने वाले क्लोन (क्लिपर, फॉक्सप्रो आदि) को याद करने की अधिक संभावना है, जिससे जेनेरिक नाम xBase हुआ - और अभी भी xHarbour में एक जीवित वंशज है। मुद्दा यह है कि ये डेटाबेस भाषाएं थीं, लेकिन एसक्यूएल जैसा कुछ भी नहीं है।
फिर भी, जहां एक विशेष डेटाबेस पर काम करने वाले प्रत्येक COBOL कार्यक्रम में उस डेटाबेस के विनिर्देश की एक प्रति (और प्रतियां असंगत समाप्त हो सकती हैं) को शामिल करने की आवश्यकता होती है, जो कि वास्तव में xBase में ऐसा नहीं है जहां डेटाबेस को पता है कि यह स्वयं की संरचना है।
उस खाते को ध्यान में रखते हुए, COBOL इतना भयानक नहीं है यदि आप इसे स्वीकार करते हैं कि यह क्या है। लेकिन यह डेटा संरचनाओं को लिखने के लिए एक भाषा नहीं है। यह इसलिए हो सकता है कि सी बनाम पास्कल पवित्र युद्धों के समय में कोबोल को बहुत नुकसान उठाना पड़ा - दोनों पक्ष इस बात से सहमत हो सकते हैं कि बाइनरी पेड़ को फिर से मजबूत करने के लिए कोबोल अच्छा नहीं था।
ओह - और एक बात जो मैं कभी नहीं भूल पाऊंगा कि मेरी पहली कोबोल पाठ्यपुस्तक में SORTकमांड का वर्णन कैसे नहीं किया गया , यह कहते हुए कि यह पुस्तक के दायरे से बाहर है - जाहिर है, या तो लेखक छँटाई के विचार से सामना नहीं कर सकता, या यह माना जाता है कि COBOL छात्रों के छोटे से छोटे दिमागों का सामना करना पड़ सकता है [अंत में देखें संपादित करें]। इस तरह की बात ने COBOL को गंभीरता से लेना बहुत मुश्किल बना दिया।
इसका एक अजीब पहलू था जैक्सन स्ट्रक्चर्ड प्रोग्रामिंग, जिसे मैं भी लगभग उसी समय सीखने के लिए मजबूर था, और विशेष रूप से बीआरओएल के साथ उपयोग करने के लिए। इसका एक भाग इनपुट के लिए एक संरचना आरेख, फिर आउटपुट के लिए एक संरचना आरेख, फिर कोड के लिए बीच में संरचना आरेख आरेखित कर रहा था। सॉर्टिंग से स्पष्ट रूप से पहले से ही हल की गई समस्या होने की उम्मीद थी - आप इस तरह से एक सॉर्टिंग एल्गोरिथ्म प्राप्त नहीं कर सकते। इसलिए अनुशंसित पाठ-पुस्तक के द्वारा यह बताया जाना अजीब था कि छंटाई की पूरी अवधारणा मेरे छोटे से दिमाग से परे थी, जबकि एक ही समय में एक दर्जन अलग-अलग छंटाई एल्गोरिदम जैसे कुछ सिखाया जा रहा था और उन्हें पास्कल में कैसे लागू किया जाए।
जो समस्याएं जेएसपी संभाल सकती हैं, वे शायद उन चीजों के लिए एक अच्छी मार्गदर्शिका हैं जो कॉबोल अपेक्षाकृत अच्छी तरह से कर सकती हैं। लेकिन फिर भी, इसका मतलब यह नहीं है कि या तो JSP या COBOL उन समस्याओं को संभालने के अच्छे तरीके हैं।
संपादित करें 30 वीं जुलाई 2014 को
मुझे बस इसी से प्रतिष्ठा मिली, मुझे याद दिलाते हुए कि यह यहाँ है। जैसा कि होता है, कुछ पुरानी यादों के कारण, प्राचीन पुस्तक संग्रह के लिए, मैं अब एक बिंदु WRT को सही कर सकता हूं SORT।
जब मैं सीखी गई पुस्तक को मूल रूप से अनुशंसित पाठ के रूप में इस्तेमाल किया गया था, जब रे वेलैंड द्वारा "COBOL में विधायी प्रोग्रामिंग" किया गया था। यह COBOL 85 को कवर नहीं करता है (हालांकि बाद के संस्करण "COBOL-85 में मैथडिकल प्रोग्रामिंग" था जिसे मैंने अभी तक नहीं देखा है)।
नीचे दिए गए टिप्पणी के प्रकार "आप उन्हें पढ़ने से पहले इनपुट फ़ाइलों को सॉर्ट करना चाहते थे, या ओएस के साथ आए सॉर्ट यूटिलिटी का उपयोग करके, इसे उत्पन्न करने के बाद आउटपुट फाइल को सॉर्ट करना चाहिए"। उस पर मेरे जवाब से, मैं "ओएस के साथ आया" बिंदु को याद किया। Kindall यूनिक्स दर्शन AFAICT को कुछ सुझाव दे रहा था, बिट्स के लिए इस्तेमाल की जाने वाली COBOL के साथ, यह कुछ अन्य चीजों के लिए उपयोग की जाने वाली OS उपयोगिता जैसे एक सॉर्ट उपयोगिता है, और संभवतः बिट्स को एक साथ गोंद करने के लिए एक बैच / स्क्रिप्टिंग / शेल भाषा का उपयोग किया जाता है। यह एक प्राचीन दुनिया में बहुत अधिक समझ में आता है जहां इंटरैक्टिव सॉफ्टवेयर गैर-मौजूद नहीं था, इसलिए आप वैसे भी काम के बैच जमा कर रहे होंगे (इसलिए "बैच भाषा")।
निम्नलिखित "COBOL में मैथडिकल प्रोग्रामिंग" के पृष्ठ 165-166 से उद्धृत किया गया है ...
ऑर्डर की गई सीरियल फ़ाइलों का उपयोग यह दर्शाता है कि किसी फ़ाइल के भीतर रिकॉर्ड को रिकॉर्ड करने का एक साधन होना आवश्यक है। अधिकांश बड़े कंप्यूटर सिस्टम में एक सॉर्ट यूटिलिटी होती है, जो फाइल को सॉर्ट करते हुए प्रत्येक डेटा-आइटम की स्थिति, प्रकार और आकार को बताती है।
COBOL प्रोग्राम के भीतर से रिकॉर्ड को छांटने की भी सुविधा है लेकिन यह दो कारणों से इस पुस्तक के दायरे से बाहर है:
(ए) ऑपरेटिंग सिस्टम का इंटरफ़ेस अक्सर काफी जटिल होता है और सिस्टम से सिस्टम में भिन्न होता है,
(b) सॉर्ट मॉड्यूल ANS '74 COBOL का एक वैकल्पिक हिस्सा है और छोटे कंप्यूटरों के लिए COBOL सिस्टम में लागू नहीं किया जा सकता है।
इसलिए यह माना जाएगा कि एक निर्दिष्ट क्रम में फ़ाइलों को छांटने के लिए सुविधाएं मौजूद हैं और ऐसी फ़ाइलों को अपडेट करने की समस्या पर विचार किया जाएगा।
संक्षेप में, किंडल सही है - धारणा यह थी कि आमतौर पर छंटनी COBOL के बाहर की जाएगी। यहां तक कि छोटे कंप्यूटरों के लिए 1974 के आसपास एक प्रोग्रामिंग भाषा से छंटनी करने का वास्तविक औचित्य भी हो सकता है।
ऊपर मैंने जो कहा था, वह मूल रूप से था जो आपको पुस्तक को फेंकने के कारण तथ्यों की जांच करने में सक्षम नहीं होने के लगभग 20 वर्षों के बाद मिलता है।
मुझे अभी भी इस ओर ध्यान देना चाहिए, कि मैंने 1988 और 1989 में 1974 की मानक (न कि 1985 के मानक) को कवर करने वाली इस अनुशंसित पुस्तक से COBOL का औपचारिक अध्ययन किया था। "COBOL फॉर स्टूडेंट्स" (पार्किंन, योर्क, बार्न्स) का तीसरा संस्करण - COBOL 85 को कवर करने वाला पहला संस्करण - 1990 तक प्रकाशित नहीं हुआ था। मुझे यकीन नहीं है, लेकिन मुझे लगता है कि "मेथोडिकल प्रोग्रामिंग" का COBOL 85 संस्करण 1994 तक प्रकाशित नहीं हुआ था।
लेकिन यह जरूरी नहीं है कि COBOL दुनिया को अपने पैरों को खींचता है - वैसे भी, उतना भी नहीं। नए मानकों को अपनाने में अभी भी, किसी भी भाषा के लिए समय लगता है।