मॉस्को 201 में लुआ: रॉबर्टो यरूशलेम के साथ साक्षात्कार

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

- आइए एक शुरुआत के लिए दर्शन करें। यदि आप स्क्रैच से फिर से लुआ का निर्माण करने वाले थे, तो आप इस भाषा में किन तीन चीजों को बदलेंगे?

- वाह! कठिन प्रश्न। भाषा के निर्माण और विकास के पीछे एक पूरी कहानी है। यह एक बड़ा फैसला नहीं था। ऐसे फैसले थे, जिन पर मुझे पछतावा हुआ और जो कुछ वर्षों में मैं ठीक कर पाया। और प्रोग्रामर हर समय इसके बारे में शिकायत करते हैं क्योंकि संगतता टूट गई है। हमने कई बार ऐसा किया है। और मैं केवल कुछ छोटे कार्यों के बारे में सोचता हूं।

- वैश्विक चूक (Global-by-default)? क्या आपको लगता है कि यह सही तरीका है?

- शायद। लेकिन गतिशील भाषाओं के लिए यह रास्ता बहुत कठिन है। शायद आपको "डिफ़ॉल्ट" की अवधारणा को पूरी तरह से छोड़ देना चाहिए, लेकिन तब चर का उपयोग करना मुश्किल होगा।
उदाहरण के लिए, आपको किसी तरह सभी मानक पुस्तकालयों की घोषणा करनी होगी। आपको one-liner , print(sin(x)) , और फिर आपको "प्रिंट" और एक और "पाप" घोषित करने की आवश्यकता है। ऐसी लघु लिपियों के लिए विज्ञापन देना अजीब है।

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

शायद डिफ़ॉल्ट वैश्विकता सही नहीं है, लेकिन डिफ़ॉल्ट स्थानीयता निश्चित रूप से एक विकल्प नहीं है। मुझे लगता है कि किसी प्रकार की घोषणा, शायद वैकल्पिक ... हमने कई बार किसी तरह की वैश्विक घोषणा करने का इरादा किया है। लेकिन अगर हम आँख बंद करके अपना सब कुछ मांग लेते हैं, तो इससे अच्छा कुछ नहीं होगा।

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

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

- छोटी कॉन्फ़िगरेशन फ़ाइलों के लिए डिफ़ॉल्ट वैश्विकता अभी भी सुविधाजनक है।

"हां, छोटी स्क्रिप्ट और पसंद के लिए सच है।"

- और इस मामले में कोई समझौता नहीं?

- हमेशा समझौते होते हैं। इस मामले में, छोटी स्क्रिप्ट और वास्तविक कार्यक्रमों के बीच एक समझौता, ऐसा कुछ।

- और यहां हम पहले बड़े सवाल पर लौटते हैं: अगर ऐसा कोई अवसर होता तो आप तीन चीजें क्या बदलते? यह मुझे लगता है कि आप चीजों की वर्तमान स्थिति से काफी खुश हैं, है ना?

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

- शून्य मान?

- बिल्कुल सही। मुझे लगता है कि इसे तालिकाओं में शून्य कहा जाता है - अर्थात, शून्य। हमने संगतता सुनिश्चित करने के लिए व्याकरण हैक किया।

- इसकी आवश्यकता क्यों है?

"मैं वास्तव में आश्वस्त हूं कि यह पूरी समस्या है ... मुझे लगता है कि सरणियों में नील के साथ अधिकांश समस्याएं गायब हो जाती हैं अगर हम [तालिकाओं में शून्य] हो सकते हैं ... अधिक सटीक रूप से, समस्या सरणियों में शून्य के साथ नहीं है। वे मुझे बताते हैं कि सरणियों में शून्य नहीं हो सकता है, इसलिए सरणियों को तालिकाओं से अलग किया जाना चाहिए। असली समस्या यह है कि हम तालिकाओं में शून्य नहीं रख सकते हैं! इसलिए, समस्या यह नहीं है कि हम सरणियों का प्रतिनिधित्व कैसे करें, बल्कि तालिकाओं में। यदि हम तालिकाओं में शून्य कर सकते हैं, तो हम बिना सब कुछ के सरणियों में शून्य कर सकते हैं। इसलिए मुझे इसके बारे में बहुत खेद है, और बहुत से लोग यह नहीं समझते हैं कि अगर लूआ को तालिकाओं में रखने की अनुमति दी जाती है तो चीजें कैसे बदल सकती हैं।

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

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

- संगतता की समस्या के अलावा आपको क्या कमियां दिखती हैं?

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

- क्या आपने व्यावहारिक नवाचारों में इन नवाचारों के प्रभाव का विश्लेषण किया है?

- हां, हमने लुआ का ऐसा संस्करण जारी किया। जैसा कि मैंने कहा, यह चुपचाप कोड तोड़ दिया। कुछ table.insert(f(x)) फ़ंक्शन कॉल का उपयोग करते हैं। और जानबूझकर ऐसा किया जाता है कि यदि फ़ंक्शन कुछ भी सम्मिलित नहीं करना चाहता है, तो यह शून्य देता है। इसलिए एक अलग जांच के बजाय, "क्या मैं एम्बेड करना चाहता हूं?" मैं table.insert कॉल करता table.insert , और अगर मुझे शून्य मिलता है, तो मुझे पता है कि यह डाला नहीं जाएगा। किसी भी अन्य भाषा की तरह, बग एक विशेषता में बदल गया है, और लोग इसका उपयोग करते हैं। लेकिन अगर आप फीचर बदलते हैं, तो यह कोड को तोड़ देगा।

- शून्य प्रकार के बारे में क्या? शून्य की तरह, केवल शून्य?

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

- इसके लिए आपके पास एक हैक है :)

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

- शून्य का उपयोग करते हुए, आप स्पष्ट रूप से कह सकते हैं कि कुंजी को तालिका में संग्रहीत किया जाना चाहिए, मूल्य शून्य के साथ कुंजी। और शून्य पहले की तरह काम कर सकता है।

"हां, मेरा यही मतलब है।" पुस्तकालयों में इन सभी कार्यों को शून्य या शून्य वापस करना चाहिए।

"वे शून्य भी लौटा सकते हैं, क्यों नहीं?"

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

"लेकिन हमारे पास पहली कुंजी नहीं होगी, केवल दूसरी होगी।"

- नहीं, कोई दूसरा नहीं होगा, क्योंकि गणना गलत तरीके से की जाएगी और सरणी में एक छेद दिखाई देगा।

- तो आप कहना चाहते हैं कि आपको एक नकली मेटामेथोड की आवश्यकता है?

- हां। मैं इस बारे में सपना देखता हूं:

{f(x)}

आपको f(x) द्वारा दिए गए सभी परिणामों को इंटरसेप्ट करना होगा। और फिर मैं %x या #x कह सकता हूं, और इस तरह से मैं लौटे परिणामों की संख्या जानता हूं। इस तरह एक सामान्य भाषा को काम करना चाहिए। तो एक शून्य बनाने से समस्या का समाधान नहीं होगा जब तक कि एक बहुत ही सख्त नियम नहीं है कि फ़ंक्शन कभी भी शून्य नहीं लौटाते हैं। लेकिन फिर हमें शून्य की भी आवश्यकता क्यों है? शायद यह इसे देने लायक है।

- रॉबर्टो, क्या लूआ में स्थैतिक विश्लेषण के लिए अधिक मजबूत समर्थन होगा? जैसे लुआ चेक ऑन स्टेरॉयड? बेशक, मैं समझता हूं कि इससे सभी समस्याओं का समाधान नहीं होगा। आपने कहा था कि यह सुविधा 6.0 संस्करण में दिखाई देगी, यदि बिल्कुल सही है? और अगर 5.x में स्थैतिक विश्लेषण के लिए एक शक्तिशाली उपकरण होगा - अगर इसमें मानव-घंटे का निवेश किया जाता है - तो क्या यह मदद करेगा?

"नहीं, मेरा मानना ​​है कि वास्तव में शक्तिशाली स्थैतिक विश्लेषण उपकरण कहा जाता है ... एक प्रकार की प्रणाली!" यदि आपको वास्तव में शक्तिशाली उपकरण की आवश्यकता है, तो Haskell, या आश्रित प्रकार के साथ किसी प्रकार की भाषा की तरह एक सांख्यिकीय टाइप भाषा का उपयोग करें। तब आपके पास निश्चित रूप से एक शक्तिशाली विश्लेषण उपकरण होगा।

"लेकिन तब मेरे पास लुआ नहीं होगा।"

- यह सही है, लूआ की जरूरत है ...

- अनिश्चितताओं? मुझे स्थिर और गतिशील प्रकारों के बारे में जिराफ़ के साथ आपकी तस्वीर पसंद है।

- हाँ, यह प्रस्तुति से मेरी आखिरी स्लाइड है।


रॉबर्टो जेरूसलम की बात "क्यों लुआ? (और क्यों नहीं) ”मास्को 2019 सम्मेलन में लुआ में।

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

- नहीं, मेरा मानना ​​है कि आप कुछ बड़ी समस्याओं को हल कर सकते हैं, लेकिन स्थैतिक विश्लेषण को शामिल नहीं कर सकते। मैं अपने पूरे दिल से परीक्षणों में विश्वास करता हूं। वैसे, मैं कवरेज के संबंध में आपसे सहमत नहीं हूं, कि हमें कवरेज का पीछा नहीं करना चाहिए ... मैं कहना चाहता हूं, मैं इस दृष्टिकोण से पूरी तरह सहमत हूं कि कवरेज पूर्ण परीक्षण प्रदान नहीं करता है, लेकिन कवरेज की कमी परीक्षण की अनुमति नहीं देती है। मैंने स्टॉकहोम में टेस्ट रूम के बारे में बात की थी, आप वहां थे। मैंने [कई] बगों के साथ परीक्षण शुरू किया - यह सबसे अजीब बात है - उनमें से एक व्यापक रूप से ज्ञात था, और बाकी पूरी तरह से अज्ञात थे। Microsoft, C और C ++ हेडर फ़ाइल में कुछ पूरी तरह से टूट गया। मैंने नेट की खोज की, लेकिन कोई भी इसके बारे में चिंतित नहीं था या इसे देखा भी नहीं था।

उदाहरण के लिए, एक गणितीय फ़ंक्शन मोडफ़ () है , जिसे एक पॉइंटर को दोहरे मूल्य पर पारित करने की आवश्यकता है, क्योंकि यह दो डबल्स लौटाता है। हम किसी संख्या के पूर्णांक या भिन्नात्मक भाग को परिवर्तित करते हैं। यह सुविधा लंबे समय से मानक पुस्तकालय का हिस्सा है। फिर सी 99 आया, और यह फ़ंक्शन अब फ्लोट संख्या के लिए आवश्यक है। और Microsoft हेडर फ़ाइल ने केवल इस फ़ंक्शन को सहेजा और एक दूसरे को मैक्रो घोषित किया। यही है, पहला कार्य निहित प्रकार रूपांतरण से गुजरता है। डबल को एक फ्लोट में बदल दिया गया था, और फिर एक पॉइंटर को एक पॉइंटर को एक फ्लोट में बदल दिया गया था!

- इस तस्वीर में कुछ गड़बड़ है।

- यह विजुअल C ++ और विजुअल C 2007 की हेडर फाइल है। यदि आप इस फ़ंक्शन को एक बार, किसी भी पैरामीटर के साथ कॉल करते हैं, और फिर परिणाम की जांच करते हैं, तो यह गलत होगा, जब तक कि यह 0. कोई अन्य मान सत्य नहीं होगा। आप इस सुविधा का उपयोग कभी नहीं कर सकते। शून्य कवरेज। और फिर परीक्षण के बारे में बहुत चर्चा हुई ... बस एक बार फ़ंक्शन को कॉल करें और परिणाम की जांच करें! यह समस्या लंबे समय से मौजूद थी, कई सालों तक इसने किसी को परेशान नहीं किया। Apple का एक बहुत प्रसिद्ध बग था, " if… what… goto… ok " जैसा कुछ । किसी ने यहां एक और अभिव्यक्ति डाली, और सब कुछ सामान्य हो गया। और फिर उन्होंने इस बारे में बहुत तर्क दिया कि क्या नियमों की आवश्यकता थी, क्या घुंघराले ब्रेसिज़ का उपयोग कोड शैली में किया जाना चाहिए, और इसी तरह आगे भी। किसी ने उल्लेख नहीं किया कि कई अन्य "इफ्स" हैं। किसी ने नहीं किया ...

- एक सुरक्षा समस्या भी है, जैसा कि मुझे याद है।

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

- क्या आप जानते हैं कि टारनटूल में कौन सा परीक्षण कवरेज है? 83%! लुआ में कवरेज क्या है?

- लगभग 99.6%। आपके पास कोड की कितनी लाइनें हैं? एक लाख, सैकड़ों हजारों? यह एक बड़ी रकम है। एक सौ में से 1% कोड की एक हजार लाइनें हैं जिनका कभी परीक्षण नहीं किया गया है। आपने उन्हें बिल्कुल भी निष्पादित नहीं किया। आपके उपयोगकर्ता कुछ भी परीक्षण नहीं कर रहे हैं।

- अर्थात, टारनटूल कार्यों का लगभग 17% अब उपयोग नहीं किया जाता है?

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

- हमारे पास लुआ मॉड्यूल के परीक्षण के बारे में एक प्रश्न है। एक डेवलपर के रूप में, मैं कुछ स्थानीय कार्यों का परीक्षण करना चाहता हूं जिन्हें मैं बाद में उपयोग कर सकता हूं। प्रश्न: आपको 99% के स्तर पर कवरेज की आवश्यकता है, लेकिन एपीआई के लिए मॉड्यूल की कार्यात्मक स्थितियों की संख्या आंतरिक रूप से समर्थन करने वाली कार्यक्षमता की मात्रा से बहुत कम है।

- मुझे माफ करना, क्यों?

- ऐसी कार्यक्षमता है जो सार्वजनिक इंटरफेस के लिए उपलब्ध नहीं है।

"वह वहाँ नहीं होना चाहिए, बस इस कोड को हटा दें।"

- बस इसे हटा दें?

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

- कोड निकालना अच्छा है, यह जटिलता को कम करता है। कम जटिलता - उच्च स्थिरता और रखरखाव में आसानी। जटिल मत करो।

- हां, चरम प्रोग्रामिंग में ऐसा नियम है। यदि किसी चीज का परीक्षण नहीं किया जा सकता है, तो वह मौजूद नहीं है।

- लुआ बनाने के लिए आप किन भाषाओं से प्रेरित थे? क्या प्रतिमान, या कार्यात्मक विशेषताएं, या कौन सी भाषाएं आपको पसंद हैं?

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

"मुझे आश्चर्य है कि आप किन भाषाओं को लुआ में शामिल करना चाहते हैं।"

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

- और लुआ में अभी भी मैक्रोज़ नहीं हैं!

- हाँ, वाक्यविन्यास पूरी तरह से अलग है। संभवतः पहली भाषा फोरट्रान थी ... नहीं, मेरी पहली भाषा कोडांतरक थी, और फिर फोरट्रान। मैंने पढ़ाई की, लेकिन कभी सीएलयू का इस्तेमाल नहीं किया। स्मॉलटाकल और एसएनओबीओएल पर बहुत प्रोग्राम किया। इसके अलावा अध्ययन किया, लेकिन आइकन का उपयोग नहीं किया, एक बहुत ही दिलचस्प भाषा भी। मैंने पास्कल और सी से बहुत उधार लिया। जब मैंने लुआ बनाया, सी ++ पहले से ही मेरे लिए बहुत जटिल था, यह टेम्प्लेट और अन्य चीजों से पहले था। मैंने 1991 में काम शुरू किया और 1993 में लुआ को रिलीज़ किया।

- USSR ध्वस्त हो गया और आपने Lua बनाना शुरू कर दिया :) जब आप Rua शुरू किया तो आप अर्धविराम और वस्तुओं की तरह नहीं थे? मुझे ऐसा लग रहा था कि इसका सिंटैक्स C के समान होगा, क्योंकि Lua इसमें एकीकृत है। हालांकि ...

- मेरा मानना ​​है कि वाक्यविन्यास अलग होना चाहिए, फिर आप भ्रमित नहीं होंगे, क्योंकि ये दो अलग-अलग भाषाएं हैं।

यह वास्तव में मज़ेदार है, और एक के साथ शुरू होने वाले सरणियों के बारे में जवाब के साथ जुड़ा हुआ है, जिसे आपने मुझे [सम्मेलन में] व्यक्त नहीं करने दिया। मेरा जवाब बहुत लंबा था।

जब लुआ रिलीज़ हुई, दुनिया अलग थी। सभी भाषाएं सी के समान नहीं थीं। अभी भी जावा और जावास्क्रिप्ट नहीं था, पायथन एक बच्चा था और 1.0 संस्करण से परे नहीं गया था। इसलिए सभी भाषाएँ C के समान नहीं थीं, इसका वाक्यविन्यास कई में से एक था।

सरणियों के साथ एक ही बात। यह हास्यास्पद है कि इस बारे में अधिकांश लोग अवगत नहीं हैं। 0 और 1 से शुरू होने वाली एरर्स की अपनी खूबियां हैं।

यह सी के लिए धन्यवाद है कि आज अधिकांश लोकप्रिय भाषाएं 0. से शुरू होने वाले सरणियों का उपयोग करती हैं। उनके निर्माता सी से प्रेरित थे और यह हास्यास्पद है कि सी में कोई अनुक्रमण नहीं है। , , . , — , (offset). , , , , .

, , . Java, JavaScript — . 0, . , « ».

— , , . -, , , - , , . , Lua ? ?

— ?

— .

— . , , . . ? , , . . .

— Lua C.

— , , . , , … , , - . : , … .

, . , ? , - … ?

— .

— . ? C , , … ?

— 16 ?

— , .

— , , .

— , . , , … , , . — , . , , . , … : ?

— C++ .

— , C++ .

— ? ptrdiff_t ?

— ptrdiff_t — (signed type). , , . ?

, diff , . . , ? कोई रास्ता नहीं। , , . 2 , .

, . , . diff , .

, ++.

— Lua ?

— , C++, - , . , - ++, … .

— , ?

— . , . , , . , .

— JVM?

— , JVM. , … — , . JVM , .NET, . JVM , Lua. , . JVM, . JVM . Java-, 10 . , JVM , .

— JVM, , Mobile JVM?

— , JVM. - Java, Java.

— , Go Oberon? Lua, ?

— Oberon… … Go , runtime- Lua. Oberon , . , , . , , const Pascal Oberon. , . .
, 1994- Oberon Self. Self? JIT- . Self , , . - , — ! — , - . , …

Oberon, , 10 Self, . Oberon , , .

, .

— Haskell?

— Haskell, , Lua.

— Python, R Julia Lua?

— , .

R . , .

Python , . , . , .

Python , , . , , - . API… , Python, . , , « ».

, -: , , , -. . , API , - . , . , , …

- , (pattern matching). , , , . , , .

: Perl. Lua, . , Python . , , . - .

— ?

— Python. Perl : $1, $2, $3. Perl, …

— Python, , ( Tarantool).

— , , , API, . Python , .

Julia, LuaJIT, , . , , . , . , , , . , , . : , - . , , - , .

Julia, : , , . , - . , double, []… . .

() «, , , , , . , ». , , .

. R, Python.

— Erlang?

— . , . , , , - . Erlang , , . , .

, . , . ? , . .

— , Erlang , Python . Lua?

— , . Lua , , Lua , .

— ?

— Forth, .

— Lua?

— , . , . - , . Lua, Lua, .

Java. Java, ? नहीं। (reflection)? नहीं। ? Java, , Java. , , Java, .

, Lua, … , , FFI.

— Lua?

— , .

— Lua ? ?

— , . , Haskell. , , … Lua, , , , , .

— , Lua.

— , , . . , .

— , . Lua ?

— , , …

— « »? , ?

— , . , , , . , .

— Lua?

— . , , LaTex DocBook. , … LaTex, . @, . Gsub , , - - . , , , .

— LaTeX?

— LaTeX? -, , . , , LaTex. , inline-. /, . — . , , , . , . , .

— LaTeX?

— , . , , . , 3+1, . , , . , . , , . , 1 «and», . . , .

— ?

— , git . 2html . HTML… , . , , . , , . , TeX. TeX- TeX.

— ?

— , . , TeX. , . DocBook, . , .

— 2html DocBook?

— , DocBook.

— , , !

— .

---

- , Lua Mailing List .