अगर 21 वीं सदी की एक प्रोग्रामिंग भाषा का आविष्कार करना है

लेख के लेखक आधुनिक प्रोग्रामिंग भाषाओं की समस्याओं और कमियों को ठीक करने के तरीकों के बारे में चर्चा करते हैं।


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

"नवीनता की कमी" को एक मूल्यवान विशेषता माना जा सकता है, लेकिन यह स्थिति एक सवाल उठाती है। क्या हम वास्तव में नई 21 वीं सदी की भाषाओं का सामना कर रहे हैं, या यह सब सिर्फ 20 वीं शताब्दी की खराब प्रोग्रामिंग आदतों का प्रतिबिंब है?

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

सिंटेक्स के साथ नीचे!

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

कीबोर्ड से टेक्स्ट दर्ज करना अब मुश्किल नहीं है। हमें खुद को ऐसी स्थिति में रखने की आवश्यकता नहीं है जहां वाक्यविन्यास के अर्थ का अनुमान लगाना आवश्यक है। टुकड़े जैसे (($: @ (<# []), (= # [], $: @ (# # [) ({~? @ #)) ^: (1 <#) - एक बहुत ही संक्षिप्त और संस्कारी रिकॉर्डिंग प्रारूप? (यह, वैसे, वास्तविक भाषा में कोड का एक वास्तविक टुकड़ा है), लेकिन यह किसी भी तरह से पठनीयता में सुधार नहीं करता है। और, इससे भी महत्वपूर्ण बात यह है कि इसे "गूगल" करना मुश्किल है या स्टैकओवरफ्लो पर इसे ढूंढना है।

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

कुछ इस तरह

FILE * test_file = fopen("/tmp/test.txt", "w+");

में रूपांतरित किया जाना चाहिए

create file /tmp/test.txt for input and output as test_file

हमें इन सभी कोष्ठकों, उद्धरण चिह्नों, तारांकनों और अर्धविरामों की आवश्यकता नहीं है (जब तक, निश्चित रूप से, वे वास्तव में विचार को अधिक स्पष्ट रूप से व्यक्त नहीं करते हैं)। सिंटैक्स हाइलाइटिंग पूरी तरह से सिंटैक्स नोटेशन को बदलने में सक्षम है।

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

बिल्ट-इन प्रकारों के साथ नीचे!

आप शायद जावास्क्रिप्ट विरोधाभासों से परिचित हैं। उदाहरण के लिए, जैसे:

> 10.8 / 100
0.10800000000000001

यह परिणाम जावास्क्रिप्ट के लिए अद्वितीय नहीं है। और यह बिल्कुल विरोधाभास नहीं है, लेकिन सम्मानित IEEE 754 मानक के बिल्कुल सही पालन का एक उदाहरण है। फ़्लोटिंग-पॉइंट नंबरों का एक समान कार्यान्वयन लगभग सभी आर्किटेक्चर में पाया जाता है। और यह इतना बुरा नहीं है, यह देखते हुए कि हम 32, 64 या 256 बिट्स में अनंत संख्या में वास्तविक संख्याओं को रटना चाह रहे हैं।

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

न केवल फ्लोटिंग पॉइंट नंबरों में समान विशेषताएं हैं। एंबेडेड पूर्णांकों को बेहतर तरीके से लागू नहीं किया जाता है। क्या आप जानते हैं कि अगर आप दो ऐसी 16-बिट संख्याओं को जोड़ने की कोशिश करते हैं तो क्या होता है?

0xFFFF + 0x0001

कोई भी सटीक उत्तर नहीं देगा। एक वृत्ति हमें बताती है कि अतिप्रवाह 0x0000 देगा। हालांकि, इस तरह के परिणाम को किसी भी अंतरराष्ट्रीय मानक में प्रलेखित नहीं किया गया है। इस ऑपरेशन को संभालने में, सी दृष्टिकोण और x86 प्रोसेसर परिवार द्वारा सभी को निर्देशित किया जाता है। वैकल्पिक रूप से, 0xFFFF का परिणाम हो सकता है, या एक बाधा को ट्रिगर किया जाएगा, या कुछ विशेष बिट का संकेत होगा जो अतिप्रवाह एक विशेष स्थान पर संग्रहीत किया जाएगा।

ऐसे क्षणों को आम तौर पर कहीं भी नहीं माना जाता है, और इस तरह के संचालन के प्रसंस्करण के नियम भाषा से भाषा में भिन्न होते हैं। यदि फ्लोटिंग पॉइंट विषमता कम से कम मानक द्वारा तय की जाती है, तो उठाया गया अंतिम प्रश्न, सिद्धांत रूप में, अप्रत्याशित है।

इसके बजाय, संख्यात्मक गणनाओं के लिए, मैं एक निश्चित बिंदु के साथ एक निश्चित मूल्य के डेटा प्रकारों को प्रस्तुत करने और सटीकता के नुकसान के मामले में मानकीकृत व्यवहार के साथ या ऊपरी या निचली सीमा से परे जाने का सुझाव दूंगा। कुछ इस तरह:

1.000 / 3.000 = 0.333
0001 + 9999 = overflowed 9999
0.001 / 2 = underflowed 0

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

क्या ऐसी गणना अधिक धीमी गति से नहीं चलेगी? हाँ वे करेंगे। लेकिन अपने आप से पूछें: आपको कितनी बार उच्च-प्रदर्शन कंप्यूटिंग का कार्यक्रम करना है? मेरा मानना ​​है कि यदि आप इस क्षेत्र के विशेषज्ञ नहीं हैं, तो यह बहुत दुर्लभ है। और यदि आप ऐसे कार्यों में लगे हुए हैं, तो आप इन उद्देश्यों के लिए विशेष उपकरण और संकलक का उपयोग करते हैं। जहां तक ​​मैं बता सकता हूं, 21 वीं सदी का एक विशिष्ट प्रोग्रामर अंतर समीकरणों को शायद ही कभी हल करता है।

ऐसा हो कि जैसा कि हो सकता है, कुछ भी नहीं विकल्प के रूप में अतीत से तेज, जटिल, और अप्रत्याशित अंतर्निहित प्रकारों के उपयोग को रोकता है, बजाय डिफ़ॉल्ट विकल्प के रूप में।

मेटलंगज के अभ्यास के साथ नीचे!

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

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

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

80 के दशक में लिस्प लोग इससे गुजरते थे। उन्होंने महसूस किया कि अधिक लागू भाषा तत्व मानकीकृत हैं, बेहतर है। इस प्रकार कॉमन लिस्प में अस्तित्व में आया।

और वह बहुत बड़ा था। INCITS 226-1994 मानक में 1,153 पृष्ठ हैं। यह रिकॉर्ड 17 साल बाद केवल मानक ++ / IEC 14882: 2011 (1338 पृष्ठों) के साथ C ++ द्वारा तोड़ा गया था। सी ++ को एक असहनीय विरासत को खींचना पड़ता है, भले ही वह हमेशा इतना बड़ा न हो। सामान्य लिस्प को खरोंच से अधिकांश भाग के लिए बनाया गया था।

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

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

इसलिए ...

21 वीं सदी की भाषा व्यवसाय-उन्मुख होनी चाहिए, स्पष्ट भाषा के भावों का उपयोग करें और अंतर्निहित प्रकारों पर निर्भर न हों। यह बहुत अच्छी बात है कि ऐसी भाषा पहले से मौजूद है! आप क्या सोचते हैं, हम किस बारे में बात कर रहे हैं?

हाँ, यह COBOL है।

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

यह सोचना भोला है कि भाषा कोड की गुणवत्ता के लिए ज़िम्मेदार है, और यह कि कुछ गैजेट्स को जोड़ने (या उन्हें हटाने) स्वचालित रूप से सब कुछ हो सकता है। एक समय में, प्रोग्रामर को फोरट्रान और कोबोल पसंद नहीं थे, इसलिए, उन्होंने सी ++ और जावा का आविष्कार किया, अंत में ऐसी स्थिति में आने के लिए, जहां 20 या 30 साल बाद, उन्होंने भी सभी को नापसंद किया।

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

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

लेकिन सबसे अधिक संभावना है कि यह दिन कभी नहीं आएगा।

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