Inverse Sapir-Whorf और प्रोग्रामिंग भाषाएँ

 (lukeplant.me.uk)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Inverse Sapir-Whorf इस बात पर नहीं, कि भाषा किन चीज़ों के बारे में सोचना कठिन बनाती है, बल्कि इस पर ध्यान देता है कि वह किन चीज़ों को बिना कहे छोड़ना कठिन बनाती है और कौन-सी जानकारी प्रकट करने के लिए मजबूर करती है
  • अंग्रेज़ी का वर्तमान काल, gendered pronouns, फ़्रेंच के gendered nouns, और तुर्की का mış भूतकाल बोलने वाले को अस्थायित्व, gender, या सूचना के स्रोत और विश्वसनीयता जैसी बातें बताने की ओर धकेलते हैं
  • प्रोग्रामिंग भाषाओं में भी अक्सर डेवलपर को ऐसे विषय कोड में शामिल करने के लिए मजबूर किया जाता है जिनमें उसकी रुचि न भी हो, जैसे calculation order, async होना या न होना, memory allocation और release, scope, और type
  • Python या Javascript का async, C का memory management, Rust के lifetime, और static type भाषाओं में type annotation जैसी चीज़ें चुनाव को स्पष्ट रूप से लिखवाती हैं, जबकि Haskell non-strict semantics और strictness analysis के ज़रिए कुछ चुनाव भाषा पर छोड़ सकता है
  • अधिक सुलभ प्रोग्रामिंग भाषाओं में Inverse Sapir-Whorf barrier कम हो सकता है, यानी वे उन विषयों पर बोलने के लिए कम मजबूर करती हैं जिन्हें आप अभी तक समझते नहीं हैं या जिन पर आपकी कोई राय नहीं है

Inverse Sapir-Whorf का मतलब क्या है

  • Sapir-Whorf hypothesis को सरल रूप में कहें तो यह विचार है कि हम जो भाषा इस्तेमाल करते हैं, वह हमारी सोच को प्रभावित करती है
  • Sapir-Whorf का मज़बूत रूप, खासकर यह विचार कि भाषा सोच को नियंत्रित करती है या कुछ खास विचारों के लिए खास भाषा चाहिए, यानी linguistic determinism, आज की भाषाविज्ञान में व्यापक रूप से गंभीरता से स्वीकार नहीं किया जाता
  • किसी भाषा में grammatical tense न होने से यह निष्कर्ष नहीं निकलता कि उसके बोलने वाले समय के बारे में अधिक सीमित ढंग से सोचते हैं; समय व्यक्त करने के दूसरे तरीके हमेशा होते हैं
  • इस बात के काफ़ी प्रमाण हैं कि बोली जाने वाली भाषा कुछ क्षेत्रों में perception, skill, और attitude को प्रभावित कर सकती है, लेकिन बड़े सीधे प्रभाव साबित करना आमतौर पर कठिन होता है
  • Inverse Sapir-Whorf इस पर केंद्रित है कि भाषा क्या कहना या सोचना कठिन बनाती है, इस पर नहीं, बल्कि इस पर कि क्या बिना कहे छोड़ना कठिन बना देती है
  • इस नज़रिए में असली बात यह है कि भाषा आपको कौन-सी जानकारी कहने के लिए धकेलती है, या किन विचारों से बचना कठिन बना देती है

प्राकृतिक भाषाओं में दिखने वाली मजबूरी

  • अंग्रेज़ी के वर्तमान काल में अस्थायित्व और स्थायित्व

    • “I’m living in London” और “I live in London” दोनों का मतलब है कि कोई लंदन में रहता है, लेकिन पहला वाक्य यह जानकारी भी देता है कि यह स्थिति अस्थायी है
    • गैर-देशज बोलने वाले इस फ़र्क़ को नोटिस न करें, और देशज बोलने वाले भी इसे केवल अवचेतन रूप से ग्रहण कर सकते हैं
    • “अस्थायी” का अर्थ असल निवास अवधि से ज़्यादा इस बात से जुड़ा हो सकता है कि व्यक्ति लंदन को कितना पसंद करता है
    • अंग्रेज़ी में tense चुनना पड़ता है, और यह चुनाव अक्सर अनजाने में होता है, इसलिए भाषा निवास अवधि या भावना जैसी जानकारी प्रकट करवा देती है

  • अंग्रेज़ी, तुर्की और फ़्रेंच में gendered pronouns और nouns

    • अंग्रेज़ी की रोज़मर्रा की बोली में किसी खास व्यक्ति के लिए आमतौर पर “he” या “she” कहना पड़ता है
    • “singular they” मौजूद है, लेकिन जब आप किसी ऐसे खास व्यक्ति की बात कर रहे हों जिसका gender आपको पता हो या आप अनुमान लगा रहे हों, तब यह बहुत स्वाभाविक नहीं लगता
    • तुर्की में he/she/it के लिए एक ही शब्द “o” इस्तेमाल होता है, और ऐसे gendered pronouns की अनुपस्थिति लोगों के gender के बारे में सोचने या बोलने को नहीं रोकती
    • इस बिंदु पर सामान्य Sapir-Whorf को समर्थन देना कठिन है, लेकिन अंग्रेज़ी pronouns इस अर्थ में साफ़ तौर पर Inverse Sapir-Whorf दिखाते हैं कि वे चाहें या न चाहें, gender बताने के लिए धकेलते हैं
    • जब आप किसी परिचित व्यक्ति का ज़िक्र गुमनाम रूप में करना चाहें, तब भी अगर अनजाने में “him” या “her” कह दिया तो gender उजागर हो सकता है और पहचान आसान हो सकती है
    • फ़्रेंच में nouns का gender होता है, इसलिए “my friend” का अनुवाद करते समय “mon ami” और “mon amie”, या “mon copain” और “ma copine” में से एक चुनना पड़ता है, जिससे जानकारी सामने आ जाती है
    • possessive pronouns अंग्रेज़ी और फ़्रेंच दोनों में gendered हैं, लेकिन अंग्रेज़ी में his/her मालिक के gender को दिखाते हैं, जबकि फ़्रेंच में son/sa उस वस्तु या व्यक्ति के gender को दिखाते हैं जिस पर स्वामित्व है; इसलिए दोनों अलग जानकारी उजागर करते हैं

  • तुर्की का “mış” भूतकाल

    • तुर्की में, सरल रूप में कहें तो, अंग्रेज़ी के simple past जैसा एक सामान्य भूतकाल और “mış” रूप, ये दो प्रमुख भूतकाल हैं
    • “mış” रूप के कई कार्य हैं, और जब अतीत की घटना बताई जाती है तो यह तब इस्तेमाल होता है जब जानकारी सुनी-सुनाई हो या उसकी विश्वसनीयता कम हो
    • “क्या Fred सोमवार को काम पर आया था?” जैसे सवाल पर अगर आपने खुद देखा हो तो सामान्य भूतकाल “geldi” इस्तेमाल होगा, और अगर सुना हो तो “gelmiş”
    • अंग्रेज़ी में simple past से सूचना के स्रोत या विश्वसनीयता को स्पष्ट किए बिना भी बात कही जा सकती है, लेकिन तुर्की में कुछ स्थितियों में certainty level या direct witness होने-न-होने को शामिल करना पड़ता है
    • “mış” रूप मौजूद होने के कारण सामान्य भूतकाल कोई neutral choice नहीं रह जाता, और जब दो विकल्पों में से कोई पूरी तरह उपयुक्त न हो तो वाक्य अप्राकृतिक लगने लगता है
    • तुर्की में “mış” suffix अक्सर वाक्य के आख़िरी शब्द के अंत में आता है, इसलिए ऐसी आदत भी बन सकती है कि अंग्रेज़ी में वाक्य पूरा करने के बाद अचानक याद आए कि “यह सुनी-सुनाई जानकारी है, मैंने खुद नहीं देखा”, और फिर अंत में “mış” जोड़ने जैसा मन हो
    • अंग्रेज़ी में भी “apparently” जैसे शब्दों से वही बात आसानी से कही जा सकती है, लेकिन अंग्रेज़ी इसे स्पष्ट करने के लिए मजबूर नहीं करती, जबकि तुर्की काफ़ी हद तक करती है

  • देशज बोलने वालों को अक्सर न दिखने वाली भाषाई मजबूरी

    • ऐसे फ़र्क़ों को तब तक पहचानना मुश्किल होता है जब तक आप दूसरी भाषा सीखना शुरू न करें या अपनी भाषा विदेशियों को सिखाने की कोशिश न करें
    • simple present और present progressive के बीच चुनाव के अधिकतर क्षणों में लोग सचेत रूप से यह नहीं सोचते कि उनका चुनाव क्या संकेत दे रहा है
    • जब भाषा किसी अभिव्यक्ति को मजबूर करती है, तो वह हमेशा कुछ जोड़ने के रूप में नहीं दिखती; छोड़ देने के ज़रिए भी अर्थ तय हो सकता है
    • “I love cake” का मतलब सामान्य रूप से cake पसंद होना है, जबकि “I love the cake” किसी खास cake की ओर इशारा करता है
    • पहले वाक्य में “the” नहीं होने से यह साफ़ हो जाता है that बात cake सामान्य रूप में हो रही है; अगर किसी खास cake की बात होती, तो “the” या “this” जैसा चिह्न ज़रूर लगाना पड़ता
    • दूसरी भाषाओं में इस भेद का सीधा समकक्ष न भी हो सकता है

प्रोग्रामिंग भाषाओं में Inverse Sapir-Whorf

  • प्रोग्रामिंग भाषाओं में सामान्य Sapir-Whorf भी कुछ हद तक अधिक लागू हो सकता है
  • Python या Haskell जैसी भाषाओं में memory allocation के बारे में कहना कठिन हो सकता है, लेकिन असंभव नहीं
  • प्रोग्रामिंग भाषाओं की सीमाओं पर बात आमतौर पर उन चीज़ों के संदर्भ में होती है जिन्हें उस भाषा में व्यक्त करना कठिन है
  • Hillel Wayne का Sapir-Whorf does not apply to Programming Languages इस विषय को और विस्तार से देखता है
  • Inverse Sapir-Whorf के नज़रिए से मुख्य सवाल यह है कि क्या प्रोग्रामिंग भाषा आपको उन विषयों पर भी बोलने के लिए मजबूर करती है जिनमें आपकी वास्तव में रुचि नहीं है
  • ऐसी मजबूरी अक्सर तभी साफ़ दिखती है जब आप कई भाषाएँ सीखते हुए विदेशी भाषा सीखने वाले जैसी नज़र विकसित करते हैं

प्रोग्रामिंग भाषाओं के प्रमुख उदाहरण

  • calculation order

    • ज़्यादातर भाषाएँ आपको यह व्यक्त करने के लिए मजबूर करती हैं कि computation किस क्रम में होगा
    • Python का x = some_func(y + 1, z + 2) यह बताता है कि पहले y + 1 compute होगा, फिर z + 2, और उसके बाद दोनों मान some_func को argument के रूप में दिए जाएँगे
    • आप इस क्रम के बारे में सचेत न हों, फिर भी Python में ऊपर वाली computation को क्रम बताए बिना व्यक्त करने का कोई तरीका नहीं है
    • ज़्यादातर भाषाएँ ऐसी ही हैं, लेकिन कुछ भाषाओं में evaluation order बहुत जटिल हो जाता है
    • Haskell में some_func (y + 1) (z + 2) जैसा समान expression non-strict semantics की वजह से evaluation order को बिल्कुल निर्दिष्ट नहीं करता
    • यही गुण Tying the knot जैसी तकनीक को संभव बनाता है, जहाँ अभी तक परिभाषित न किए गए मानों का reference लिया जा सकता है

  • async function color

    • async function color इसका अच्छा उदाहरण है
    • Javascript या Python जैसी भाषाओं में, जहाँ साफ़ async keyword है, वहाँ कोड synchronous है या asynchronous, यह बताना पड़ता है
    • synchronous function में यह बात async keyword छोड़ देने से व्यक्त होती है, लेकिन तब भी आप दो विकल्पों में से एक चुन रहे होते हैं
    • ऐसा कोड लिखने का कोई तरीका नहीं है जो इस प्रश्न पर ambivalent हो

  • memory allocation और release

    • garbage collection) के बिना ज़्यादातर भाषाएँ memory allocation और release के बारे में बोलने के लिए मजबूर करती हैं
    • C जैसी भाषाओं में इसे आमतौर पर काफ़ी स्पष्ट रूप से संभाला जाता है, या implicitly stack allocation का इस्तेमाल होता है; लेकिन दोनों ही हालात में चुनाव करना पड़ता है
    • दूसरी भाषाओं में यह समस्या ज़्यादा छिपी हुई हो सकती है, मगर गायब नहीं होती
    • Rust में यही प्रश्न lifetime या explicit reference counting की चर्चा में बदल जाता है
    • “मुझे परवाह नहीं कि यह memory कब allocate और free होगी, आप खुद संभाल लें” जैसा विकल्प वास्तव में उपलब्ध नहीं होता
    • memory allocation के बारे में न बोलने की भी एक लागत होती है
    • ऐसी भाषाएँ लगभग निश्चित रूप से बहुत-सी values को heap पर रखेंगी और runtime garbage collector की ज़रूरत होगी
    • बदले में भाषा को चुनाव करने की काफ़ी अधिक स्वतंत्रता मिलती है, और Haskell उदाहरण के लिए strictness analysis के माध्यम से अक्सर ऐसे चुनाव करता है

  • scope

    • ज्ञात सभी आधुनिक भाषाएँ आपको scope के बारे में सोचने पर मजबूर करती हैं
    • कई मामलों में scope variables की भौतिक स्थिति से व्यक्त होता है, और अगर आप अलग behavior चाहते हैं तो Python के global या nonlocal जैसे अतिरिक्त syntax का उपयोग करना पड़ता है
    • अगर आप scope के बारे में बिल्कुल नहीं सोचना चाहते, तो संभवतः आपको assembly तक उतरना पड़ेगा और एक single global address space स्वीकार करना होगा

  • type

    • static type भाषाएँ आमतौर पर आपको हर variable के type के बारे में सोचने और बोलने के लिए मजबूर करती हैं
    • type inference इस बोझ को वैसे कम करता है जैसे कोई अधिक बुद्धिमान श्रोता context से ज़्यादा बातें समझ ले, लेकिन संवाद फिर भी बना रहता है
    • पूरी तरह dynamic type भाषाएँ भी आपको Python के isinstance check जैसी चीज़ों से type की बात करने देती हैं, लेकिन यह कम स्वाभाविक और तकनीकी रूप से अलग होता है
    • gradual typing वाली भाषाओं का एक आकर्षण यह है कि वे सचमुच Inverse Sapir-Whorf समस्या से बचने की कोशिश करती हैं और पसंद के अनुसार type के बारे में बोलने या न बोलने की स्वतंत्रता देती हैं
    • यह व्यवहार में कितना अच्छा काम करता है, यह निश्चित नहीं है, और मौजूदा codebase की conventions तथा इस्तेमाल होने वाला linter अक्सर किसी-न-किसी दिशा में दबाव डालते हैं

अधिक सुलभ भाषाएँ और कम barrier

  • अधिक “सुलभ” या “पढ़ने में आसान” प्रोग्रामिंग भाषाओं की बहुत-सी विशेषताओं का विश्लेषण Inverse Sapir-Whorf के नज़रिए से किया जा सकता है
  • ऐसी भाषाओं में Inverse Sapir-Whorf barrier कम हो सकता है, यानी वे आपको उन चीज़ों के बारे में बोलने के लिए मजबूर नहीं करतीं जिन पर आपकी अभी राय नहीं है या जिन्हें आप अभी तक समझते नहीं हैं
  • प्रोग्रामिंग भाषा जिन विषयों पर आपको मजबूर करती है, वे उस भाषा के प्रति आपकी समझ और चुनाव को प्रभावित कर सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2 시간 전
Lobste.rs टिप्पणियाँ

  • भाषा डिज़ाइन, चाहे वह programming language हो या natural language, इसे इस रूप में देखा जा सकता है कि भाषा में किन तत्वों को शामिल किया जाता है ताकि यह तय हो सके कि उपयोगकर्ता को अपना ध्यान कहाँ लगाना चाहिए
    C मानो अप्रत्यक्ष रूप से कहती है, “memory management पर ध्यान दो”, और Haskell कहती है, “उन types पर ध्यान दो जिन्हें variables और expressions धारण कर सकते हैं”
    अगर कोई भाषा मुझे वास्तव में जिस दिशा में ध्यान देना है उसी ओर ले जाए, तो वह उस काम के लिए सही tool जैसी लगती है; और अगर नहीं, तो यह ऐसा लगता है जैसे cocktail party में किसी धीमे बोलने वाले को सुनने की कोशिश कर रहे हों और कमरे के उस पार कोई चिल्ला रहा हो
    ध्यान सबसे कीमती संसाधन है, इसलिए यह समझना ज़रूरी है कि tools उसे कैसे दिशा देते हैं और आकार देते हैं

    • “भाषा उन चीज़ों को सीमित करती है जिन्हें कहा नहीं जा सकता” इस विचार को शायद अभिव्यक्ति की non-neutrality जैसा कोई नाम दिया जा सकता है
      अंग्रेज़ी में “the” का प्रयोग करना या छोड़ देना इस बात पर neutral नहीं है कि कोई चीज़ विशिष्ट है या नहीं, और तुर्की में miş का प्रयोग करना या न करना इस बात पर neutral नहीं है कि जानकारी सीधे प्राप्त हुई है या सुनी-सुनाई
      इसे मानक Sapir-Whorf परिकल्पना, यानी “भाषा उन चीज़ों को सीमित करती है जिन्हें कहा जा सकता है”, या अभिव्यक्ति की neutrality के उलट पक्ष के रूप में भी देखा जा सकता है
      तब हम समझा सकते हैं कि किसी विशेष विषय पर कोई भाषा neutral है या नहीं, और language designer के रूप में उपयोगकर्ता का ध्यान बिखेरने या केंद्रित करने के लिए उसे समायोजित कर सकते हैं। उदाहरण के लिए garbage collection heap allocation के बारे में अभिव्यक्ति को neutral बनाता है, जबकि effect tracking side effects और input/output के बारे में अभिव्यक्ति को non-neutral बनाता है

  • पता नहीं मैंने लेख का मूल बिंदु पूरी तरह पकड़ा है या नहीं, लेकिन इससे Rust के बारे में मेरा बहुत पुराना और बार-बार लौटने वाला विचार याद आता है
    Rust references के साथ काम करने देता है, लेकिन memory safety सुनिश्चित करने के लिए कड़े नियम लगाकर एक अजीब-सी स्थिति में खड़ा है
    C++ में अगर आपको लगता है कि कोई चीज़ reference होनी चाहिए, तो आप बस उसे reference बना देते हैं और उम्मीद करते हैं कि सब ठीक रहेगा; Python में आपके पास वह control ही नहीं होता, इसलिए आप बेझिझक data copy कर देते हैं
    लेकिन Rust में आप “copy inefficient है, तो इसे reference बना देते हैं” वाले optimization pit में गिर सकते हैं, और जब borrow checker चिल्लाने लगता है, तो इस भरोसे के बावजूद कि यह reference सुरक्षित है, आप एक घंटे तक code refactor करते रहते हैं
    अच्छे Rust programmers कहते हैं, “बस .clone, RC, Box वगैरह इस्तेमाल करो”, और मैं इससे सहमत भी हूँ, लेकिन reference सामने मौजूद है और लगता है कि इसे सुरक्षित रूप से इस्तेमाल किया जा सकता है
    इसलिए यह अजीब एहसास रह जाता है कि borrow checker को शांत करने के लिए चीज़ों को और खराब बनाना पड़ा, और यह भी समझ आता है कि लोग क्यों कह देते हैं, “borrow checker मेरे लिए कुछ ज़्यादा ही है”

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

  • विषय अच्छा है, और तुर्की grammar की थोड़ी-सी चर्चा आना भी अच्छा लगा
    एक और आम उदाहरण यह है कि कुछ भाषाओं में plurality जैसी बारीक जानकारी छोड़ी जा सकती है, और Vietnamese ऐसा ही एक मामला है
    “exaggerated” शब्द पर लिंक देखकर मैंने सोचा, “क्या यह शायद Arrival से जुड़ा लेख है?”, और सच में वही निकला, यह भी मज़ेदार था
    बहुतों को वह फ़िल्म पसंद है, लेकिन व्यक्तिगत रूप से मेरे लिए उसमें विश्वास बनाए रखना मुश्किल था। वह science fiction कहलाती है, लेकिन उसका “science” मुझे किसी जादुई linguistics जैसा लगा

    • मेरा मानना है कि plurality वही बिंदु है जिसे APL, Pandas, SQL जैसी चीज़ें ढकने की कोशिश करती हैं
      ज़्यादातर application programming languages एकल value को किसी तरह की atomic नींव मानती हैं। आप उसके ऊपर list या map बना सकते हैं, लेकिन वे भी आख़िरकार एक-एक single चीज़ ही होती हैं और अक्सर सूक्ष्म तरीक़े से एक-दूसरे के साथ compatible नहीं होतीं
      Rust में इन संरचनाओं के बीच copy करना बार-बार होता है, जबकि SQL में उस समस्या की चिंता कम करनी पड़ती है, लेकिन उसके बदले indexes और query planner की चिंता करनी पड़ती है। ख़ासकर तब, जब database कोई साफ़ तौर पर मूर्खतापूर्ण plan बना ले जो उस चीज़ को जटिल बना दे जिसे मैं पूछना चाहता हूँ, और SQL NULL की तो बात ही न करें
      नतीजे में हमारा ज़्यादातर software individual values के स्तर तक अविश्वसनीय रूप से over-specified है, और PC की performance 1000 गुना बेहतर होने के बावजूद सबसे अच्छा UI latency पहले से 10 गुना ज़्यादा है
      object-oriented programming की कट्टरता भी आंशिक रूप से ज़िम्मेदार है। async भी एक बार आज़माया गया, लेकिन यह बहुत आसानी से ऐसी स्थिति में गिर जाता है जहाँ स्वतंत्र कामों को एक-एक करके await किया जाता है और जंगल छोड़कर सिर्फ़ पेड़ देखे जाते हैं
      https://www.uiua.org/ को खुश मानकर चलना चाहिए

  • अच्छे बिंदु हैं। हर modern language programmer को जैसे किसी झाड़-झंखाड़ में घुसना पड़े, वैसे details से निपटने के लिए मजबूर करती है या बहुत ज़ोर से उकसाती है
    scripting languages program या web page जैसी थोड़ी कम detail वाली चीज़ों पर operations देती हैं, लेकिन फिर भी details को हटाती नहीं हैं
    वे अब भी आपको numbers, strings, error codes जैसी बहुत छोटी details के बारे में सोचने और उन्हें manage करने पर मजबूर करती हैं
    वर्षों की training और practical work के कारण हम details manage करने के इतने अभ्यस्त हो गए हैं कि detail के नज़रिए से अलग सोच पाना बहुत कठिन हो गया है

  • मेरे दिमाग़ में सबसे पहले objects या modules के interface आए
    programming languages में यह बहुत ठोस होता है, जबकि natural language बातचीत में यह कहीं ज़्यादा धुंधला होता है
    एक और उदाहरण C++ generics और Python generics का अंतर है। C++ में आपको इसे बहुत जानबूझकर संभालना पड़ता है, जबकि Python में अगर type hints को नज़रअंदाज़ कर दें तो यह काफ़ी implicit तरीके से संभल जाता है

  • “inverse Sapir-Whorf भाषा जिन चीज़ों को कहा नहीं जा सकता उन्हें सीमित करती है, या कुछ बातों को न कहना कठिन बना देती है, यहाँ तक कि कुछ बातों के बारे में न सोचना भी कठिन बना देती है” — यह मुझे grammar > idiom > standard library > third-party library > ecosystem वाली एक pyramid जैसा लगता है
    “न सोचना कठिन है” वाला हिस्सा उन समस्याओं पर focus करता लगता है जिन्हें व्यक्त करना कठिन है या जिन पर महत्वपूर्ण constraints हैं
    familiarity ऊपर और नीचे, दोनों दिशाओं से भीतर की ओर काम करती है, और लोग हर परत पर code लिखने के तरीक़े से अपनी पृष्ठभूमि उजागर करते हैं

  • मैंने 15 साल से ज़्यादा समय तक अंग्रेज़ी पढ़ी, लिखी और बोली है, फिर भी मुझे नहीं पता था कि “I live in London” और “I'm living in London” में फ़र्क है
    अब तो मुझे यह भी नहीं पता कि मैं London में रहता हूँ, या अभी London में रह रहा हूँ 😅

    • “I'm living in London” को “I am living in London” के रूप में फैलाकर देखें, तो थोड़ा मदद मिलती है
      यहाँ अगर gerund रूप को साधारण adjective से बदलकर “I am cold” कहें, तो हम इसे इस अर्थ में लेंगे कि अभी ठंड लग रही है, न कि कोई supervillain की तरह हमेशा के लिए ठंडे हैं
      उसी तरह “I am living in London” यह संकेत देता है कि आप अभी London में रह रहे हैं, लेकिन भविष्य में यह बदल सकता है
      इसमें यह भाव भी है कि आप हमेशा से London में नहीं रहे हैं। यह कुछ वैसा ही है जैसे “I am cold” में यह हल्का-सा निहित होता है कि आपने कम-से-कम एक बार पर्याप्त गर्म तापमान का अनुभव किया है, इसलिए आप अपनी वर्तमान स्थिति को “सामान्य” नहीं बल्कि “ठंडा” पहचानते हैं