Smalltalk की सरलता और सुसंगतता बनाम अन्य भाषाएँ (2022) [वीडियो]

सरलता, सिंटैक्स, और समझौते

• Smalltalk का सिंटैक्स बेहद न्यूनतम और एकरूप है, लेकिन टिप्पणीकार ज़ोर देते हैं कि इससे अपने आप कोड पढ़ना/लिखना आसान नहीं हो जाता, और न ही कंपाइलरों के लिए अनुकूलन आसान हो जाता है।
• Blocks और message-passing नियंत्रण संरचनाओं को सामान्य method calls के साथ एकीकृत करते हैं, लेकिन बड़ी धीमापन से बचने के लिए compiler के विशेष मामलों की ज़रूरत पड़ती है (जैसे ifTrue: / whileTrue: का inlining)।
• “सब कुछ receiver को भेजा गया message है” वाला मॉडल डिज़ाइन को class hierarchies/traits के भीतर व्यवहार बाँटने की ओर धकेलता है, जिसे कुछ लोग elegant मानते हैं और कुछ इसे अन्य भाषाओं के simple functions की तुलना में अधिक जटिलता मानते हैं।
• परिचय/परिचितता बहुत प्रभावित करती है कि क्या “सरल” लगता है; बहुत अधिक minimal भाषा समाधान को जटिल बना सकती है।

प्रदर्शन और VM अनुकूलन

• Smalltalk VMs ऐतिहासिक रूप से उच्च-प्रदर्शन JS engines से पीछे क्यों रहे, इस पर जीवंत बहस है।
• एक पक्ष इसे आंशिक रूप से भाषा/VM डिज़ाइन (जैसे blocks, dynamic dispatch) को JIT करना कठिन होने से जोड़ता है, और Smalltalk की trajectory की Python से तुलना करता है।
• दूसरे लोग तर्क देते हैं कि प्रदर्शन का अंतर मुख्यतः निवेश का है: JS के पास बड़े, अच्छी तरह-funded दल हैं; OpenSmalltalk volunteer-driven है। Squeak/Pharo को performance benchmark के रूप में लेना भ्रामक बताया गया है।
• उच्च-प्रदर्शन Smalltalk-जैसी प्रणालियों (Self, Strongtalk, Truffle/Graal-आधारित SOM variants, TruffleSqueak) के उदाहरण दिए गए हैं, जो कुछ benchmarks पर JS के बराबर या उससे बेहतर हो सकते हैं, और “Smalltalk धीमा है” दावों को चुनौती देते हैं।
• Python के लिए, optimization कठिन होने के अंतर्निहित कारण अस्पष्ट बताए गए हैं; CPython का C extensions के साथ घनिष्ठ जुड़ाव उल्लेखित है, लेकिन इसका निष्कर्ष नहीं निकाला गया।

Live Programming परिवेश

• कई लोग Smalltalk के image-based, live environment से आकर्षित हैं, जहाँ code, GUI, debugger, और tools सब एकीकृत हैं और हमेशा चल रहे होते हैं।
• इसकी तुलना mainstream workflows से की जाती है, जिनमें rebuilding/restarting की ज़रूरत होती है, जिसे एक कदम पीछे माना जाता है।
• Emacs और Lisp/Interlisp प्रणालियों का उल्लेख spiritually समान के रूप में किया गया है (extensible, live, image-based history), लेकिन अनुभव में वे एक जैसे नहीं हैं; Smalltalk को अधिक coherent, Emacs को अधिक “kludgy” माना गया है।
• कमियाँ: modern Smalltalk environments भारी हो सकते हैं (जैसे 1GB+ RAM) और deploy करना awkward हो सकता है क्योंकि VM/image को साथ ship करना पड़ता है।

व्यावहारिकता, टूलिंग, और प्रोजेक्ट अनुभव

• किस्से Smalltalk प्रणालियों में प्रभावशाली productivity और tooling का वर्णन करते हैं (OO databases, workflow engines, IDE-embedded automation)।
• विरोधी किस्सा: एक बड़ा गुप्त Smalltalk प्रोजेक्ट जिसने लगभग कुछ भी demo करने योग्य नहीं बनाया; भाषा अकेली समस्या नहीं थी, लेकिन secrecy, vetting की कमी, और Smalltalk में ऐतिहासिक SCM/configuration कठिनाइयों ने भूमिका निभाई।
• आधुनिक Smalltalk की व्यावहारिकता पर चिंताएँ उठाई गईं: batteries-included libraries की कथित कमी, common FOSS implementations में weak या absent multithreading, और clunky UIs (छोटे editors, mouse-centric workflows)।
• अन्य लोग नोट करते हैं कि पहले के commercial Smalltalks अपने युग के लिए “batteries included” थे; क्या व्यावहारिक है, यह दशक के साथ बदलता है।

भाषा-दर्शन और करियर की वास्तविकता

• कुछ प्रतिभागियों को लगता है कि mainstream भाषाएँ (Python, C++, Java) Smalltalk, Lisp, F#, Elixir आदि की तुलना में कहीं कम सुखद या expressive हैं, लेकिन करियर कारणों से उन्हें इस्तेमाल करना पड़ता है।
• दी गई सलाह:
  • अपनी पसंदीदा भाषा में prototype बनाइए और stack choices को प्रभावित करने के लिए dramatic productivity/value दिखाइए।
  • यदि आप कोई niche भाषा introduce करते हैं तो coworkers को सिखाने के लिए तैयार रहिए।
  • वैकल्पिक रूप से, popular tools अपनाइए लेकिन design style और abstractions में “बेहतर” भाषाओं के विचारों का उपयोग कीजिए।
• tools से प्रेम बनाम problem-solving पर तनाव है:
  • एक पक्ष कहता है tool aesthetics distraction हैं; effectiveness ही मायने रखती है।
  • दूसरा तर्क देता है कि उच्च-गुणवत्ता वाले tools समस्याओं को “dissolve” कर देते हैं और tools में mastery महत्वपूर्ण है।
  • कुछ लोग बीच का रास्ता सुझाते हैं: tools से भावनात्मक रूप से न चिपकें, लेकिन उनके प्रभाव को नज़रअंदाज़ भी न करें।

अन्य भाषाओं और प्रणालियों से तुलना

• Smalltalk की बार-बार तुलना की जाती है:
  • Lisp और पुराने Lisp machines/Interlisp प्रणालियों से (images, GC, interactive development)।
  • JS, Python, Ruby, और dynamic dispatch models से; dictionary-based method lookup को शक्तिशाली भी और performance पर बोझ भी माना जाता है।
  • Tcl और GNU Smalltalk scripting विकल्पों के रूप में; GNU Smalltalk को पूर्ण Smalltalk environment के बजाय अधिक “Smalltalk-flavored scripting” बताया गया है, और इसकी maintenance स्थिति संदिग्ध मानी गई है।
• “Homoiconicity” पर बहस होती है:
  • कुछ लोग दावा करते हैं कि Smalltalk Lisp की तरह homoiconic है; दूसरे कहते हैं कि compiled Lisps और modern environments में classic “code as data with same representation” धारणा वास्तव में लागू नहीं होती।

सीखना, न्यूनतम सेटअप, और प्रयोग

• लोग और अधिक “live coding” Smalltalk वीडियो माँगते हैं; Pharo tutorials, game/live-editing talks, और introductory Smalltalk demos के लिंक साझा किए जाते हैं।
• Glamorous Toolkit (Pharo पर) को एक आधुनिक “moldable development” environment के रूप में उजागर किया जाता है, जहाँ documentation स्वयं live, editable code है।
• कुछ लोग ultra-minimal Squeak setups चाहते हैं (graphics/sound नहीं, केवल REPL, छोटे devices जैसे Raspberry Pi Zero पर); इसे non-trivial बताया गया है, और thread में इसका कोई सरल, documented path नहीं है।
• विचार प्रस्तावित किए जाते हैं:
  • concurrency और distribution पाने के लिए Erlang/Elixir BEAM VM पर Smalltalk-जैसी प्रणाली।
  • Smalltalk के deployment targets के रूप में JS VMs का उपयोग (जैसे squeak.js)।
  • आज के लिए अधिक practical dynamic alternative के रूप में Objective-C (जो Smalltalk से प्रेरित है) पर विचार; इसका उल्लेख किया गया है लेकिन विस्तार से चर्चा नहीं हुई।