- Notation विचार में मदद करने वाला एक महत्वपूर्ण उपकरण है, और गणित तथा programming languages दोनों में केंद्रीय भूमिका निभाता है
- APL भाषा को इस प्रयास के रूप में विकसित किया गया था कि गणितीय notation के लाभों को programming language की executable प्रकृति और universality के साथ जोड़ा जा सके
- अच्छे notation की विशेषताएँ हैं संक्षिप्तता, स्पष्टता, suggestiveness, विवरणों का subordinating, और औपचारिक प्रमाण की क्षमता
- विभिन्न गणितीय संरचनाओं (polynomials, transformations, graphs आदि) को APL में कुशलतापूर्वक व्यक्त और रूपांतरित किया जा सकता है
- Notation का परिचय और उसका अधिगम संदर्भ के भीतर स्वाभाविक रूप से होना चाहिए, और notation की संरचनात्मकता तथा सार्वभौमिकता भी महत्वपूर्ण हैं
विचार के उपकरण के रूप में Notation
- रसायन, वनस्पति विज्ञान जैसे वैज्ञानिक क्षेत्रों में भी व्यवस्थित nomenclature ने ज्ञान-विकास को तेज किया है
- जॉर्ज बूल ने इस बात पर जोर दिया कि भाषा स्वयं विचार का एक साधन है
- गणितीय notation, विचार का समर्थन करने वाली भाषा का एक प्रतिनिधि उदाहरण है, जो मानसिक बोझ को कम करता है और सोचने की क्षमता को बढ़ाता है
- A.N. Whitehead और Charles Babbage ने गणितीय notation के महत्व पर जोर दिया था
विचार के उपकरण के रूप में programming language की संभावना
- programming languages में universality और clarity जैसी ताकतें होती हैं
- कंप्यूटर के माध्यम से ideas का परीक्षण और स्पष्ट thought experiments संभव हैं
- लेकिन अधिकांश programming languages, गणितीय notation की तुलना में, विचार के उपकरण के रूप में अपेक्षाकृत कमजोर हैं
- APL को स्पष्टता और precision की दिशा में, विचार का समर्थन करने वाले notation के रूप में डिज़ाइन किया गया था
अच्छे notation की प्रमुख विशेषताएँ
- समस्या को व्यक्त करने में सहजता: समस्या से सीधे निकली संरचनाओं को आसानी से व्यक्त किया जा सके
- Suggestiveness: व्यक्त किया गया रूप समान या विस्तारित समस्याओं की ओर संकेत करे
- विवरणों का अधीनस्थीकरण: जटिल विवरणों को सरल बनाकर सोच में मदद करने वाली संरचना दे
- संक्षिप्तता: न्यूनतम symbols और rules से व्यापक अभिव्यक्ति संभव हो
- औपचारिक प्रमाण की क्षमता: notation औपचारिक proof और deductive reasoning के लिए अनुकूल हो
APL की मूल notation तकनीकों का परिचय
- vector, matrix जैसी array-based संरचनाओं का स्वाभाविक उपयोग
- functions और operators vector/matrix पर element-wise अपने-आप लागू होते हैं
- reduction(
/), scan(\), inner product(.) जैसे operators के माध्यम से function composition व्यक्त किया जाता है ⍳,⌽,⍴,+,×,*जैसे मूल symbols से समृद्ध expressions बनाए जा सकते हैं- सभी functions right-to-left precedence rule का पालन करते हैं, जिससे बिना parentheses के स्वाभाविक expressions लिखे जा सकते हैं
समस्या-समाधान और सोच को बढ़ावा देने वाले उदाहरण
- triangular numbers, factorial जैसी गणितीय श्रेणियों को सरल expressions से व्यक्त किया जा सकता है
- polynomial representation, multiplication, differentiation जैसी क्रियाओं को एकसमान नियमों से संक्षिप्त रूप में संभाला जा सकता है
- graph theory (trees, transitive closure, spanning tree) को भी array operations से स्पष्ट रूप में व्यक्त किया जा सकता है
- permutations, Boolean algebra, number-system conversion (prime factorization) जैसे अनेक क्षेत्रों तक विस्तार संभव है
औपचारिक प्रमाण और संरचित चिंतन
- सभी operations और expressions स्पष्ट रूप से executable रूप में व्यक्त होते हैं, इसलिए कंप्यूटर के माध्यम से automatic verification संभव है
- mathematical induction, exhaustive search, identity enumeration के माध्यम से विभिन्न औपचारिक proofs के उदाहरण दिए गए हैं
- reduction और scan की partition identities तथा inner product operations की associativity और distributivity के औपचारिक proofs
- Newton symmetric functions, polynomial multiplication और differentiation formulas के प्रत्यक्ष proofs
APL और पारंपरिक गणितीय notation की तुलना
- APL functions की स्पष्ट परिभाषा, एकसमान array operations, और समृद्ध symbol system प्रदान करता है
- सभी operations पर precedence rules के बजाय right-to-left execution rule लागू होता है
- गणितीय symbols के उपयोग की जटिलता कम होती है और formal manipulation को समर्थन मिलता है
- syntax संक्षिप्त है और rules एकसमान हैं, इसलिए यह beginners और experts दोनों के लिए लाभकारी है
notation के परिचय और सीखने की विधि
- अलग से "language lecture" दिए बिना, संदर्भ के भीतर आवश्यक notation को स्वाभाविक रूप से परिचित कराने की पद्धति पर जोर
- ठोस समस्या-स्थितियों के भीतर नए symbols को सहज रूप से सीखा जाता है
- notation की कठिनाई से अधिक महत्वपूर्ण यह पहचानना है कि वह किन विविध संभावनाओं और विस्तारों का संकेत देता है
APL की विस्तार-क्षमता और प्रस्ताव
- complex numbers को संभालने सहित functions के विस्तार का प्रस्ताव
- unique elements और summary functions के standardization की आवश्यकता
- अधिक generalized operators के माध्यम से vector calculus जैसे अतिरिक्त विषयों का समर्थन संभव
- भाषा-डिज़ाइन में स्पष्टता और reasoning क्षमता बढ़ाने का लक्ष्य
दक्षता और स्पष्टता का संतुलन
- पहले स्पष्ट और विश्लेषणयोग्य notation को परिभाषित करना, फिर optimization के माध्यम से efficiency बढ़ाने का तरीका सुझाया गया है
- algorithm को स्पष्ट बनाना बाद की optimization और compiler optimization में भी मदद करता है
- APL में लिखी गई बुनियादी अभिव्यक्तियाँ शैक्षणिक अनुसंधान और औद्योगिक अनुप्रयोग, दोनों में योगदान दे सकती हैं
1 टिप्पणियां
Hacker News टिप्पणियाँ
notation को shell expansion की तरह “एक expression को दूसरे expression से बदलना” भर समझ लेना आसान है, लेकिन असल में यह कहीं ज़्यादा गहरा है
मेरे प्रोफेसर ने समझाया था कि महान खोजें अक्सर नई notation के साथ सामने आती हैं, और नई notation का मतलब होता है “इस समस्या के बारे में सोचने का नया तरीका”
मुझे लगता है कि आज की कई अनसुलझी समस्याएँ भी किसी शक्तिशाली notation के आने पर हल हो सकती हैं
यह सचमुच ताकतवर है, लेकिन Lisp-शैली के करीब है; APL या Clojure-शैली बुनियादी types को सच में उपयोगी बनाने की दिशा में है
10 data structures पर 10-10 functions रखने के बजाय, 1 data structure पर 100 functions रखने का तरीका है; इसलिए APL में DSL बनाने की बजाय अगर data को बहुत सावधानी से design और arrange किया जाए, तो बाकी चीज़ें अपने-आप फिट हो जाती हैं
Richard Feynman ने किशोरावस्था में trigonometry सीखते समय sine और cosine की notation पसंद न आने पर formulas को सरल बनाने और noise घटाने के लिए अपने mathematical symbols बनाए थे
बाद में भी उन्होंने Feynman diagrams या slash notation की तरह physics को सोचने और व्यक्त करने के तरीके साथ-साथ नए बनाए
छोटे उदाहरण के तौर पर, जब CoffeeScript आया, तो lambda shorthand और कई syntax सुविधाओं की वजह से JavaScript लिखने का तरीका काफी बदल गया, और सोचना, पढ़ना तथा सुधारना आसान हो गया
SML/Haskell और Lisp परिवार भी कुछ ऐसे ही लगते हैं
Brian Greene और Barry Mazur की यह छोटी clip भी आपको पसंद आ सकती है: https://youtu.be/8wQepGg8tHA
ऐतिहासिक रूप से APL को किनारे करने वाली चीज़ अजीब keyboard ही नहीं थी, बल्कि IBM का Lotus 1-2-3 और उसके तुरंत बाद आया MS Excel भी था
engineers, academia, accountants और MBAs को TI-59 या HP-12C से बेहतर tools चाहिए थे, जबकि computer science पक्ष symbolic processing, AI और LISP में डूबा हुआ था, और अंततः industry ने वह जगह ले ली
अफसोस की बात है कि APL का spreadsheets से कहीं बड़ा असर हो सकता था और वह कहीं ज़्यादा समस्याएँ हल कर सकता था
मूल vision हाथ से लिखी जाने वाली, consistent और executable mathematical notation का था, लेकिन वह आखिर तक हासिल नहीं हो पाया
दिलचस्पी हो तो यह लेख पढ़ने लायक है: https://mlajtos.mu/posts/new-kind-of-paper
आप बिना पैसे दिए problem solving कर सकते हैं, और जब paid customers के सामने compiled result deploy करते हैं तब cost आती है
अगर solution किसी खास subset में fit हो जाए, तो उसे April में ले जाकर Common Lisp से provide करने वाला रास्ता भी अपनाया जा सकता है
हालांकि APL वाले लोग आम तौर पर बहुत academic होते हैं, इसलिए वे engineering काम तेज़ और संक्षिप्त तरीके से कर सकते हैं, लेकिन औसत software company में अगर आप function ranks या Naperian functors की बात छेड़ दें, तो colleagues को शक हो सकता है कि आपको medical help की ज़रूरत है
software development का बड़ा हिस्सा एक कुछ हद तक formal technical language गढ़ने का काम है, जो customers और users के बोलने और सोचने के तरीके को व्यक्त करे; Iverson-परिवार की languages में यह आसान नहीं है
Java ने लंबे समय तक हर method में यह स्पष्ट करवाया कि कौन-से business words अंदर आते हैं और बाहर जाते हैं, और इस लिहाज से organization की concepts को code में map करना आसान था
APL में भी data और functions को names दिए जा सकते हैं, लेकिन जैसे ही आप लंबे names और namespace structures लाकर बाहरी organization को code में map करते हैं, उसकी conciseness और elegance खो जाती है
ML परिवार के sophisticated type systems में भी developers को invented quasi-linguistic ontology और organization/process को सीधे जोड़ने में कठिनाई होती है, और वे अधिक बार mathematical या academic concepts चुनते हैं
अगर कोई व्यक्ति दोनों काम कर सके तो संभव है, लेकिन आम तौर पर सिर्फ customer की दुनिया में translate करना ही अच्छी तरह कर लेना काफी होता है
पिछले साल The Array Cast ने 1982 का Iverson interview फिर से publish किया: https://www.arraycast.com/episodes/episode92-iverson
यह काफी रोचक है और Turing lecture की तुलना में ज्यादा accessible है
1979 का APL आज जैसा अजीब और fringe language नहीं था
उस समय programming languages आज की तरह worldwide mass phenomenon नहीं थीं, इसलिए लगभग सभी कुछ हद तक अजीब और fringe जैसी थीं, और C भी तब काफी नया था
थोड़ी उदार नज़र से देखें तो APL dense C से बहुत दूर की abstraction नहीं लगता, और यह arrays पर pointer manipulation खुद implement किए बिना computer को program करने देता था
APL [1] या J [2] syntax से mathematics सिखाने वाली textbooks भी काफी हैं
Iverson ने मूल रूप से APL को mathematics के लिए बेहतर syntax के रूप में इस्तेमाल किया था, और programming implementation कुछ साल बाद आया
[1] https://alexalejandre.com/about/#apl
[2] https://code.jsoftware.com/wiki/Books#Math_for_the_Layman
पहले मैंने अब बंद हो चुका type theory podcast सुना था, जिसकी सामग्री बेहद abstruse थी
बुनियादी अवधारणा दूसरी उपयोगी अवधारणाओं से जुड़ी हुई है
Sapir-Whorf hypothesis भी कुछ वैसी ही है, लेकिन इसे उलटकर सोचना ज़्यादा दिलचस्प है
किसी अपूर्ण भाषा में कुछ चीज़ें ऐसी होती हैं जिनके बारे में सोचा नहीं जा सकता या सोचना कठिन होता है, और तब सवाल उठता है कि क्या हमारी इस्तेमाल की जाने वाली भाषा में ऐसी चीज़ें हैं जिन्हें हम न व्यक्त कर सकते हैं, न सोच सकते हैं
यहाँ “भाषा” और “सोच” को सामान्य से व्यापक अर्थ में देखा जा सकता है
उदाहरण के लिए, क्या सामाजिक interaction के नियम यह तय करते हैं कि हम कैसे interact करते हैं? Zeynep Tufekci “Twitter and Teargas” में कहती हैं कि Twitter flash mob को संभव बनाता है, लेकिन टिकाऊ सामाजिक बदलाव को कठिन बना देता है
किसी को follow करना, comment करना, या like दबाना जैसे सामाजिक mechanisms क्या आपसी interaction के तरीके को तय या संभव बनाते हैं? अलग mechanisms शायद बेहतर सामूहिक सोच को संभव बना सकते हैं
संगीत भी है। notation की बात नहीं, बल्कि क्या संगीत ऐसी किसी चीज़ को व्यक्त करता है जिसे किसी और तरीके से अच्छी तरह व्यक्त नहीं किया जा सकता?
कई विदेशी भाषाएँ सीखने के अनुभव से, ऐसी बहुत-सी चीज़ें हैं जिनके बारे में मैं सिर्फ किसी खास भाषा में सोच सकता हूँ और अपनी मातृभाषा English में सोचना कठिन है
उदाहरण के लिए Ukrainian और Russian का “гулять” ऐसे कई अर्थ रखता है जिन्हें English पकड़ नहीं पाती, इसलिए उन भाषाओं को सीखने से पहले मैंने उन अर्थों के बारे में कभी सोचा ही नहीं था
“Гулять” का शाब्दिक अर्थ “चलना” है, लेकिन इसका इस्तेमाल अनुभवों की तलाश में घूमने, sexual experiences समेत, के अर्थ में भी होता है
कोई किसी के बहुत जल्दी शादी करने पर “не нагулялся”, यानी “काफी नहीं चला”, कहकर शिकायत कर सकता है
English में भी “sow his wild oats” जैसी मिलती-जुलती expression है, लेकिन जब “चलना” जैसे एक ही verb में इतने अर्थ समा जाते हैं, तो जीवन में चलते जाने की सोच ही बदल जाती है
Arabic सीखते समय भी ऐसे कई अर्थ और विचार बने जो सिर्फ उस भाषा में पैदा होते हैं; इसलिए नहीं कि उन्हें English में समझाना असंभव है, बल्कि इसलिए कि उन्हें संक्षेप में व्यक्त करने वाली notation नहीं है, इसलिए लंबा लेख चाहिए
कुछ लोग भाषा के जरिए दूसरी सोचों में यात्रा करना पसंद करते हैं, और कुछ लोग उस संभावना के सामने जड़ हो जाते हैं
हमेशा की तरह सफलता संतुलन और दोनों पक्षों में है
गणितज्ञों या computer scientists के लिए यह बात बेहद स्पष्ट है, फिर भी यह विचार linguists और “educators” के बीच बहुत विवादास्पद है
इसका linguistic analogue Sapir-Whorf hypothesis है, यानी यह दावा कि आप कौन-सी भाषा सीखते हैं, वह आपकी सोचने की शैली तय करती है
natural language एक cultural object है, और culture को कमज़ोर partial order के रूप में भी map करना academia में लगभग taboo माना जाता है
शिक्षा में भी इसके बड़े परिणाम हैं, क्योंकि कई बार छात्रों को ऐसी notation सीखने से रोक दिया जाता है जो उन्हें सामने आने वाली समस्याओं पर सचमुच reasoning करने दे सकती थी
सच कहूँ तो यह हिस्सा मुझे ठीक से समझ नहीं आता
किसी भी भाषा का speaker वही mathematics या computer program सीख सकता है, यह बात यही दिखाती है
यह भी सवाल है कि बोलकर या लिखकर इस्तेमाल होने वाली भाषा सोच के लिए ज़रूरी भी है या नहीं
कम-से-कम सोच का एक बड़ा क्षेत्र भाषा के बिना भी संभव है, और इंसान भी कभी बिना भाषा या बहुत कम भाषा वाले थे; संवाद करने की सोच और मंशा ने words और language बनाए
इसलिए सीखी हुई भाषा को सोच का basic model मानना अजीब लगता है
उदाहरण के लिए, अगर कोई समाज समुद्र के रंग और घास के रंग को एक ही शब्द से बुलाता है, तो कुछ लोग दावा करते हैं कि वे दोनों रंगों का फर्क अनुभव ही नहीं कर सकते
बात सिर्फ इतनी नहीं कि experience को memory में मिलते-जुलते ढंग से encode किया जाता है, बल्कि यह कि वे फर्क देख ही नहीं सकते
किसी भाषा में जो sounds नहीं हैं, उन्हें लोग सुन ही नहीं सकते—यह दावा भी वैसा ही है
यहाँ notation की चर्चा इससे ज़्यादा इस बात के करीब है कि vocabulary exploration में काम आ सकती है
जैसे आप सिर्फ यह नहीं कह पाते कि कोई sound सुनी, बल्कि यह कह पाते हैं कि music सुना, और कोई specific chord progression आदि सुनी
अभी APL में एक project develop कर रहा हूँ
यह लंबे समय से backlog में था, लेकिन अब सच में code लिख रहा हूँ
इसमें रुचि पैदा होने और one-liners से ज़्यादा लिख पाने के बीच काफी लंबा समय रहा
उस process की शुरुआत में यह paper मिला और मैंने उसे सोख लेने जैसा पढ़ा; अब वे concepts मेरी सोच की पूरी नींव बन गए हैं
सचमुच architecture program में NAATOT पढ़ा रहा हूँ
software architecture नहीं, बल्कि building design वाला architecture
मैं Iverson के core को बचाए रखने के लिए edit किया हुआ version इस्तेमाल करता हूँ, और वास्तविक math/programming को बस इतना रखा है कि point दिख जाए और students design और expression tools की संभावनाओं के बारे में अलग तरह से सोचने की चुनौती लें
यानी यह ideas बनाने की process, उन्हें खुद और दूसरों के सामने express करने के तरीके जैसी चीज़ों से जुड़ा है
अगर किसी ज़्यादा loose और open program में मौका मिले, तो मैं ऐसा course चलाना चाहूँगा जिसमें students architecture design domain में लागू करने के लिए अपनी खुद की symbol/notation system बनाएँ
पहले जो Freeform notes app बना रहा था, उसे पूरा न कर पाने का अफसोस है
वह SVG के जरिए standalone webpage में compile होने वाला app था, और मुझे लगता है कि STEM fields में आम technical content के लिए वह सचमुच शानदार idea था
पुराने chemistry notes का example यहाँ है: https://colbyn.github.io/old-school-chem-notes/dev/chemistry-1010---fall-2021/week-14-acids-and-bases.html
जानना चाहूँगा कि अब वे कौन-सा system इस्तेमाल करते हैं
कई सालों तक APL को एक तरह के जादू की तरह देखने के बाद, इस साल की शुरुआत में समय निकालकर इसे सीखा
APL में एक ट्वीट में समा जाने जितना बेहद ज़्यादा code लिखा जा सकता है, यह देखकर हैरानी हुई
मज़ेदार है, लेकिन इस्तेमाल करना कठिन था
लिखने के बाद लगभग हमेशा लगता है, “इसे लिखने में इतना समय लग गया?” और सोचता हूँ कि क्या कोई दूसरा tool इस्तेमाल करना चाहिए था
लेकिन असल में यह बात सहज रूप से समझ में नहीं आती कि दूसरा tool शायद कहीं ज़्यादा समय लेता
जो हिस्सा कठिन और समय खा जाने वाला लगता है, वह दरअसल problem specification को ज़्यादा संकुचित तरीके से व्यवस्थित करने के लिए मजबूर किए जाने की प्रक्रिया है
यह ज़्यादा खड़ी, लेकिन बहुत छोटी चढ़ाई चढ़ने जैसा है; ज़्यादा मुश्किल लगता है, लेकिन असल में काम कम होता है
इसलिए लगता है कि APL सीखकर इस्तेमाल करना चाहिए
पेपर की इस धारणा से मैं व्यक्तिगत रूप से सहमत नहीं हूँ कि “गणितीय notation में सार्वभौमिकता की कमी होती है, और उसे विषय, लेखक और संदर्भ के अनुसार अलग-अलग तरह से समझना चाहिए”
मेरे हिसाब से problem visualization और ergonomics से अलग की गई notation की लागत बड़ी होती है
कुछ विद्वान ऐसी notation पसंद करते हैं जो बहुत-सी complexity छिपाकर “यूरेका” जैसी समझ या अप्रत्याशित समानताएँ पैदा कर सके, लेकिन कुछ मामलों में यह उल्टा धुंधली और error-prone हो सकती है
फिर भी यह सही है कि यह सोचने की प्रक्रिया को व्यक्त करने का एक महत्वपूर्ण tool है
मुझे लगता है कि किसी domain या निकटवर्ती domains के लिए सिर्फ एक standard notation रखना reasoning और problem solving के रचनात्मक, कलात्मक और exploratory पहलुओं को काफी दबा देता है
Terry Tao की notation से जुड़ी एक शानदार व्याख्या भी है: https://news.ycombinator.com/item?id=23911903
गणित में Lean, Coq जैसे “enterprise” reasoning systems बनाने की कोशिशें हैं, और ऐसे मामलों में universal notation system उचित है
लेकिन निजी exploration के लिए, कुछ भी जोड़-तोड़कर इस्तेमाल करना बेहतर हो सकता है
व्यक्तिगत रूप से शिक्षा में यह मेरे लिए ज़्यादा कठिन रहा
algebra classes वगैरह में अगर शिक्षक notation को लेकर अपने निजी फैसलों और पसंदों को consistent या ईमानदार ढंग से नहीं संभालते थे, तो मुश्किल होती थी; और type theory तथा mechanical proof theory पढ़ते हुए मेरी गणितीय क्षमता काफी बेहतर हुई
मुझे लगता है कि पेपर में “विवरणों की अधीनता” की अवधारणा को पर्याप्त गहराई से नहीं खंगाला गया
APL एप्लिकेशन को लंबे समय तक पढ़ने और लिखने के बाद समझ आया कि यह अवधारणा abstraction से मूल रूप से अलग complexity management के तरीके की ओर इशारा करती है
हम API, library, module, package, interface जैसे abstraction barriers से घिरे हुए हैं, और इसका परिणाम ऊंचे abstraction towers, API जोड़ने वाले developers, hardware से कटाव, performance reasoning की कठिनाई जैसी परिचित समस्याएं हैं
APL एक अलग approach को बहुत आसान बना देता है
abstraction डिजाइन करने के बजाय, data को सावधानी से इस तरह design किया जाता है कि उसे सरल expressions से आसानी से manipulate किया जा सके
आम तौर पर जहां library function या DSL term होता, वहां primitive operations सीधे इस्तेमाल किए जाते हैं
उदाहरण के लिए, string table, key array और value array से vector values और interned keys वाला hashmap-जैसा structure बनाया जा सकता है, और insert·output·delete को सीधे APL expressions से handle किया जा सकता है
इस तरीके की अच्छी बात यह है कि हर expression black box नहीं होता, इसलिए किसी खास जरूरत के हिसाब से उसे स्वाभाविक रूप से adjust किया जा सकता है
सामान्य hashmap insertion में new key जोड़ने का code चाहिए होगा, लेकिन यहां यह common invariant इस्तेमाल किया जाता है कि existing key में सिर्फ value जोड़नी है
library API होता तो unused code paths, insertion functions के कई variants, या dead code elimination के लिए sophisticated type inference की जरूरत पड़ती
ऐसा approach domain से असंबंधित concerns को codebase में leak कर देता है
विवरणों को छिपाने के बजाय उन्हें अधीन कर दें, तो जरूरत भर domain-specific details तक पहुंच मिलती है, और unrelated details जरूरत पड़ने तक background में चुपचाप रह सकती हैं
बेशक APL expressions से बहुत परिचित होना पड़ता है, लेकिन मुझे नहीं लगता कि यह Python ecosystem जैसी चीज को गहराई से सीखने से बहुत बड़ा बोझ है
असल में APL symbols background में गायब होने लगते हैं, और English words को अक्षर-दर-अक्षर नहीं बल्कि शब्द·वाक्यांश इकाइयों में पढ़ने की तरह वे अर्थपूर्ण syntax के रूप में दिखने लगते हैं
ज्यादातर भाषाओं में यह असंभव है, लेकिन अगर भाषा पर्याप्त concise और expressive हो तो काफी बड़े दायरे में यह फिर संभव हो जाता है
Arthur Whitney को scrolling से सचमुच नफरत है, यह खयाल हमेशा याद आता है
20 files खोलकर “go to definition” के पीछे-पीछे जाने की भी जरूरत नहीं
जब पूरा program एक page में आ जाए, तो ऐसी चीजें गायब हो जाती हैं और navigation आंखों की movement से होने लगता है
सच में समय लगाकर इसे सीखना चाहिए, ऐसा महसूस होता है
यह पिछले कुछ हफ्तों में झेली गई परेशानी से भी गहराई से जुड़ा है
मैं बहुत tightly coupled legacy Python code देख रहा हूं, जहां पहले की सारी “improvement” कोशिशें गलत data model के ऊपर और abstraction चढ़ाने वाली थीं
code को linearly पढ़कर यह पता नहीं चलता कि कौन सा method input object को बदलता है
कुछ बदलते हैं, कुछ नहीं बदलते, और कभी-कभी बिना बदले वही input argument लौटाते भी हैं
ऐसे detours के समुद्र से, जहां factory ऐसे कई calculators लौटाती है जो एक ही interface तक share नहीं करते, बेहतर तो magic strings हैं जिन्हें analyse और understand किया जा सके
क्योंकि सभी operations O(n) हैं
general operators इस्तेमाल किए जा सकते हैं, लेकिन value pairs domain logic में क्या मतलब रखते हैं, और हर operation में सही structure कैसे maintain करना है, इसे सावधानी से समझना पड़ेगा
program को पहली बार पढ़ने वाला व्यक्ति primitive operations नहीं, बल्कि business domain semantics समझने में उतनी ही कठिनाई झेलेगा
अगर कोई improvement है, तो वह complexity को कहीं और रखने से नहीं, बल्कि code और actual values के साथ-साथ दिखने से है
complex programming को आसान बनाने वाली चीज runtime data और code operations का side by side दिखना है, इसलिए IDE tools debuggers और inspectors को लगातार बेहतर बनाते हैं ताकि दिखा सकें कि program हर step पर क्या कर रहा है
इस context में, operations के कुछ हिस्सों को abstract करें या data structure के कुछ हिस्सों को, अच्छा और concise नया abstraction बनाना अब भी अच्छी बात है
example का insertion code ज्यादातर वह desired add operation नहीं है, बल्कि interpreter जिस form में input करवाता है उसे needed form में बदलने वाली data cleanup है
⍪←असली add है, और↓⍉↑()()()APL और interpreter input parser की limitations को bypass करने के लिए input parsing और transformation के ज्यादा करीब हैdelete code में भी
'buggy'को nested array के single element के रूप में ढूंढने के लिए wrap करना पड़ता है, आदि; problem domain से असंबंधित Boolean array बनानी पड़ती है“vector values का hashmap बनाना” कहना भी misleading है, क्योंकि असल hashing नहीं है
duplicate key check भी नहीं, hash selection या speed और distribution tuning भी संभव नहीं, और keys क्रम से append होती हैं इसलिए search भी slow हो जाती है
Dyalog APL में fast lookup के लिए array को internal hashing target के रूप में mark करने वाला magic interpreter command I-Beam 1500 भी है, लेकिन internal abstraction leak हो रहा है, यह लगातार याद रखना पड़ता है
“pit of success”, “एक ही तरीका”, “पहला सूझा तरीका सही तरीका होना चाहिए”, “अलग काम अलग दिखना चाहिए” जैसे language·tool design के अच्छे ideas APL में missing हैं
Python या C# में
kv={'a':1, 'b':2}जैसा syntax बस काम करता है, और parentheses या colon भूल जाएं तो साफ गलत दिखता है तथा editor और compiler मदद करते हैंAPL implementation input/output के लिए
⎕NGET,⎕CSV,⎕JSONजैसे magic interpreter functions पर निर्भर है, और error handling·logging·debugging भी कमजोर हैंपूरा expression एक साथ execute होता है, और hooks और forks की वजह से उसे आसानी से तोड़ना भी मुश्किल है
आखिर में अलग-अलग array shapes,
⊂3क्यों ऐसा दिखता है जैसे कुछ कर ही नहीं रहा,⊆और⊂का फर्क, scalar extension आदि को ठीक-ठीक intuition से जानना पड़ता है, तभी experimentation और learning संभव होती है“key हो तो update करो, न हो तो add करो” जैसे तुरंत accessible pattern में भी APL में branching के तरीके से फिर से सोचना पड़ता है
Python में
if/elseऔरkey in map, C# मेंif/elseऔरmap.Contains(key)से निकल जाने वाली बात APL में basic feature को reimplement करने की चिंता में फंसा देती हैAaron Hsu के दावे से मिलता-जुलता है, लेकिन ऐसा महसूस होता है जैसे Up-Goer 5 या Toki Pona, जहां “fire truck” नहीं कह सकते और “आग रोकने का काम करने वाले लोगों की गाड़ी” कहना पड़ता है
[1] https://docs.dyalog.com/latest/CheatSheet%20-%20I-Beams.pdf
[3] https://aplwiki.com/wiki/Scalar_extension
[4] https://xkcd.com/1133/