जानें कि एलन केय के Smalltalk और शुरुआती GUI के पीछे के मुख्य विचार कैसे आज के सॉफ़्टवेयर को "इंटरैक्टिंग सिस्टम्स" के रूप में देखने पर असर डालते हैं, और आप उनसे क्या व्यवहारिक सबक ले सकते हैं।
एलन केय सिर्फ़ प्रोग्रामिंग इतिहास का एक नाम नहीं हैं। कंप्यूटर्स के बारे में हमारे कई रोजमर्रा के धारणाएं—"विंडो" क्या है, सॉफ़्टवेयर को इंटरैक्टिव क्यों होना चाहिए, कैसे प्रोग्राम सहयोगी हिस्सों से बने—उनमें से कई विचार उन्होंने आगे बढ़ाए (अक्सर Xerox PARC की टीमों के साथ)।
यह पोस्ट ट्रिविया नहीं बल्कि अवधारणाओं के बारे में है। आपको इसे समझने के लिए कोडिंग आनी ज़रूरी नहीं है, और यहाँ किसी दुर्लभ तकनीकी विवरण का दौरा नहीं मिलेगा। इसके बदले हम कुछ मानसिक मॉडलों पर फोकस करेंगे जो आज के टूल्स और प्रोडक्ट्स में अभी भी दिखते हैं: सॉफ़्टवेयर को समझना, बदलना और सीखना कैसे आसान बनता है।
पहला, Smalltalk: सिर्फ़ एक प्रोग्रामिंग भाषा नहीं, बल्कि एक पूरा वर्किंग एनवायरनमेंट जो खोज और सीखने को प्रोत्साहित करता था।
दूसरा, GUI (ग्राफिकल यूज़र इंटरफ़ेस): विंडो, आइकॉन्स, मेन्यू—इंटरैक्टिव सॉफ़्टवेयर कुछ ऐसा जिसे आप सीधे संभाल सकते हैं, सिर्फ़ निर्देश देना नहीं।
तीसरा, सिस्टम सोच: सॉफ़्टवेयर को वस्तुओं के इंटरैक्टिंग हिस्सों के सेट के रूप में देखना, न कि कोड फ़ाइलों के ढेर के रूप में।
यह केय को अकेले प्रतिभाशाली के रूप में पेश नहीं करेगी, और यह दावा भी नहीं करेगी कि एक "सही" पैरेडाइम सब कुछ ठीक कर देता है। कुछ विचार शानदार काम करते थे, कुछ गलत समझे गए, और कुछ उतने व्यापक रूप से नहीं फैले जितना हो सकता था।
लक्ष्य व्यावहारिक है: अंत तक आप आधुनिक ऐप्स और कोडबेस को इस बात के स्पष्ट एहसास के साथ देख पाएंगे कि वे क्यों वैसे महसूस करते हैं—और आप अपनी अगली परियोजना के लिए क्या उधार ले सकते हैं।
एलन केय एक ऐसी कंप्यूटिंग संस्कृति में आए जहाँ कंप्यूटर शक्तिशाली, महंगे और आम लोगों के लिए ज्यादातर अप्रासंगिक थे। कंप्यूटर को साझा इन्फ्रास्ट्रक्चर की तरह माना जाता था: समय बुक करते, काम सबमिट करते और परिणाम का इंतजार करते। उस मॉडल ने सब कुछ आकार दिया—प्रोग्राम्स कैसे दिखते थे, कौन उन्हें उपयोग कर सकता था, और "सफलता" का क्या अर्थ था।
अधिकांश उपयोगकर्ताओं के लिए कंप्यूटिंग का मतलब मशीन को एक काम सौंपना (अक्सर पर्चियों या कतार वाले टर्मिनलों के माध्यम से) और बाद में आउटपुट पाना था। अगर कुछ गड़बड़ होता, तो आप "खोजबीन" नहीं कर पाते—आप फिर से सबमिट करते और दोबारा इंतजार करते। खोज धीमी थी, और कंप्यूटर एक विचार करने वाले उपकरण की बजाय दूरस्थ सेवा जैसा लगता था।
केय का लक्ष्य केवल "छोटे कंप्यूटर" नहीं था। यह एक अलग संबंध था: कंप्यूटर को एक व्यक्तिगत माध्यम के रूप में देखना—सीखने, लिखने, सिमुलेट करने, ड्रॉ करने और विचार बनाने के लिए—खासकर बच्चों और गैर-विशेषज्ञों के लिए। इसके लिए तत्कालता चाहिए थी। आपको यह देखने की ज़रूरत थी कि आपके कार्यों का क्या नतीजा होता है, जल्दी संशोधन कर सकें, और रचनात्मक फ्लो में बने रहें।
ऐसा परिवर्तन लागू करने के लिए आपको हार्डवेयर, सॉफ़्टवेयर और इंटरैक्शन डिज़ाइन को साथ में प्रयोग करने की जगह चाहिए थी। Xerox PARC जैसे रिसर्च लैब्स ने लंबे दांव लगाने के लिए संसाधन दिए: नए डिस्प्ले, नए इनपुट डिवाइस, नए प्रोग्रामिंग मॉडल, और इन्हें एक सुसंगत अनुभव में पैकेज करने के तरीके। लक्ष्य फीचर शिप करना नहीं था—एक नए तरह के कंप्यूटर उपयोग का आविष्कार करना था।
अगर कंप्यूटर सीखने और निर्माण मशीन होने वाली थी, तो प्रयोज्य (usability) गौण नहीं रह सकती थी। इंटरफ़ेस को खोज, प्रतिक्रिया और समझने योग्य क्रियाओं का समर्थन करना चाहिए था। उसी फोकस ने केय को उन सिस्टमों की ओर धकेला जहाँ इंटरैक्शन का "फील"—आप क्लिक करते हैं, संपादित करते हैं, या एक्सप्लोर करते हैं तो क्या होता है—सॉफ़्टवेयर की संरचना से घनिष्ट रूप से जुड़ा होता।
एलन केय ने यह नहीं सोचा कि "ऑफिस का काम कैसे तेज करें।" उन्होंने एक अलग प्रश्न से शुरुआत की: क्या होगा अगर एक बच्चा किताब की तरह एक व्यक्तिगत कंप्यूटर ले जा सके और विचारों का अन्वेषण, चीज़ें बनाना और सीख कर सके? यह विचार Dynabook बना—कम एक उत्पाद स्पेक, और अधिक व्यक्तिगत कंप्यूटिंग के लिए एक उत्तर दिशा।
Dynabook को हल्का, बैटरी-चालित और हमेशा उपलब्ध कल्पना किया गया था। लेकिन सबसे महत्वपूर्ण शब्द "पोर्टेबल" नहीं था—वह "व्यक्तिगत" था। यह कंप्यूटर उपयोगकर्ता का वह चीज़ होगी जैसे एक नोटबुक या वाद्ययंत्र—एक ऐसी वस्तु जिसे आप समय के साथ आकार देते हैं, न कि सिर्फ़ संचालित करते हैं।
इतना ही जरूरी: इसे सीखा जा सकना चाहिए। केय का लक्ष्य कंप्यूटिंग को मेन्यू की दीवार के पीछे छिपाना नहीं था; वह चाहत थे कि लोग धीरे-धीरे लेखक बनें, सिर्फ़ उपभोक्ता नहीं।
Dynabook के "किलर ऐप्स" पढ़ना, लिखना, ड्रॉ करना, संगीत रचना, विज्ञान प्रयोगों का सिमुलेशन और इंटरैक्टिव कहानियाँ बनाना थे। इसने प्रोग्रामिंग को एक साक्षरता माना—विचार व्यक्त करने का एक और तरीका—न कि केवल पेशेवरों का आरक्षित व्यापार।
यह फोकस यह बदल देता है कि "अच्छा सॉफ़्टवेयर" क्या होता है। एक सीखने वाला टूल टिंकering को आमंत्रित करेगा, तेज़ फीडबैक देगा, और फिर से कोशिश करना सुरक्षित बनाएगा।
यहाँ Smalltalk और शुरुआती ग्राफिकल यूज़र इंटरफेस फिट होते हैं। अगर आप चाहते हैं कि लोग बनाएं, तो आपको डायरेक्ट मैनिपुलेशन, तुरंत परिणाम और ऐसा वातावरण चाहिए जहाँ प्रयोग करना स्वाभाविक लगे। Smalltalk का लाइव, इंटरैक्टिव सिस्टम और GUI के दृश्य रूपक एक ही लक्ष्य का समर्थन करते थे: विचार और काम करने योग्य परिणाम के बीच की दूरी को कम करना।
Dynabook "टैबलेट की भविष्यवाणी" नहीं कर रहा था। यह कंप्यूटिंग के साथ नया संबंध प्रस्तावित कर रहा था: सोच और निर्माण के लिए एक माध्यम। कई उपकरण इसका अनुमान लगा सकते हैं, पर विज़न उपयोगकर्ताओं को सशक्त बनाने के बारे में है—खासकर शिक्षार्थियों को—न कि किसी विशेष स्क्रीन आकार या हार्डवेयर डिज़ाइन के बारे में।
जब लोग "Smalltalk" सुनते हैं, तो अक्सर वे एक प्रोग्रामिंग भाषा की कल्पना करते हैं। केय की टीम ने इसे कुछ बड़ा माना: एक पूरा कार्यशील सिस्टम जहाँ भाषा, टूल और उपयोगकर्ता अनुभव एक साथ डिज़ाइन किए गए थे।
साधारण शब्दों में, Smalltalk एक ऐसा सिस्टम है जहाँ सब कुछ एक ऑब्जेक्ट है. स्क्रीन पर विंडोज़, आप जो टेक्स्ट टाइप करते हैं, आप जो बटन क्लिक करते हैं, आपके द्वारा किए गए कैलकुलेशन—प्रत्येक एक ऑब्जेक्ट है जिसे आप किसी काम के लिए कह सकते हैं।
Smalltalk सीखने-करने के लिए बनाया गया था। कोड लिखने, कंपाइल करने और आशा करने के बजाय कि यह काम करेगा, आप सिस्टम चलाते समय ऑब्जेक्ट्स का निरीक्षण कर सकते थे, उनकी वर्तमान स्थिति देख सकते थे, उन्हें बदल सकते थे, और तुरंत नया विचार आजमा सकते थे।
उस जीवंतता का महत्व यह था कि इसने प्रोग्रामिंग को खोज में बदल दिया। आप सिर्फ़ फ़ाइलें उत्पादन नहीं कर रहे थे; आप एक चलती दुनिया को आकार दे रहे थे। यह जिज्ञासा को प्रोत्साहित करता था: “यह चीज़ क्या है?” “इसमें क्या है?” “अगर मैं इसे थोड़ा बदलूँ तो क्या होगा?”
Smalltalk के डेवलपमेंट टूल्स अलग ऐड-ऑन नहीं थे। ब्राउज़र्स, इंस्पेक्टर, डिबगर और एडिटर्स उसी ऑब्जेक्ट-आधारित ब्रह्मांड का हिस्सा थे। टूल्स सिस्टम के अंदर से उसे समझते थे, क्योंकि वे उसी माध्यम में बने थे।
उस घनिष्ठ एकीकरण ने "सॉफ़्टवेयर पर काम करना" कैसा महसूस होता है, बदल दिया: दूरस्थ सोर्स कोड प्रबंधन की तरह कम, और आप जिस सिस्टम पर काम कर रहे हैं उसके साथ सीधे इंटरैक्ट करने जैसा अधिक।
एक खुली और उत्तरदायी दस्तावेज़ को संपादित करने की कल्पना करें—फॉर्मेटिंग तुरंत बदलती है, आप खोज सकते हैं, पुन: व्यवस्था कर सकते हैं और बिना "पुनः बनाये" डॉक्यूमेंट में सुधार कर सकते हैं। Smalltalk उस तरह की तत्कालता चाहता था, पर प्रोग्राम्स के लिए: आप चलती चीज़ को संपादित करते हैं, परिणाम तुरंत देखते हैं, और चलते रहते हैं।
केय का सबसे उपयोगी मानसिक मॉडल "क्लासेस और इनहेरिटेंस" नहीं है। यह विचार है कि एक ऑब्जेक्ट एक छोटा, स्व-संपन्न कंप्यूटर है: यह अपनी स्थिति रखता है (अब क्या जानता है) और यह तय करता है कि जब आप इसे कुछ करने के लिए कहेंगे तो कैसे प्रतिक्रिया देगा।
प्रत्येक ऑब्जेक्ट को इस तरह सोचें:
यह फ्रेमिंग व्यावहारिक है क्योंकि यह आपका ध्यान "डेटा कहाँ रखा है?" से हटा कर "किसकी जिम्मेदारी है?" की तरफ मोड़ता है।
एक सामान्य भ्रम ऑब्जेक्ट्स को सजे हुए डेटा रिकॉर्ड्स की तरह देखना है: फील्ड्स का समूह और कुछ हेल्पर फंक्शन्स। उस दृष्टिकोण में प्रोग्राम के अन्य हिस्से स्वतंत्र रूप से आंतरिक में झाँकते और उन्हें बदलते हैं।
केय का दृष्टिकोण अधिक एक्टर्स जैसा है। आप किसी ऑब्जेक्ट के अंदर नहीं घुसते और उसकी ड्रॉर्स नहीं खोलते। आप उसे अनुरोध भेजते हैं और वह अपनी स्थिति खुद संभालता है। यही अलगाव सार है।
मैसेज पासिंग बस एक अनुरोध/प्रतिक्रिया है।
एक कैफे की कल्पना करें: आप रसोई में जाकर अपना खुद का खाना नहीं बनाते। आप ऑर्डर देते हैं ("मुझे सैंडविच बनाइए"), और आपको परिणाम मिलता है ("यह रहा आपका सैंडविच" या "हमारे पास ब्रेड खत्म है")। कैफे यह तय करता है कि ऑर्डर कैसे पूरा होगा।
सॉफ़्टवेयर ऑब्जेक्ट्स भी ऐसा ही करते हैं: आप संदेश भेजते हैं ("कुल निकालो", "सहेजें", "अपने आप को रेंडर करो"), और ऑब्जेक्ट जवाब देता है।
जब सिस्टम के अन्य हिस्से केवल संदेशों पर निर्भर होते हैं, तो आप किसी ऑब्जेक्ट के आंतरिक कामकाज को बदल सकते हैं—एल्गोरिद्म बदलना, स्टोरेज बदलना, कैश जोड़ना—बिना पूरे सिस्टम को फिर से लिखे।
यही तरीका है जिससे सिस्टम बिना सब कुछ तोड़े बढ़ते हैं: सीमाओं पर स्थिर समझौते और घटकों के अंदर स्वतंत्रता।
लोग अक्सर "ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग" को "क्लासेस का उपयोग" के समान समझ लेते हैं। यह समझ में आता है—अधिकांश भाषाएँ OOP को क्लास डायग्राम और इनहेरिटेंस पेड़ों के माध्यम से सिखाती हैं। लेकिन केय की मूल प्राथमिकता अलग थी: बातचीत करने वाले हिस्सों के रूप में सोचना।
एक क्लास एक खाका है: यह बताती है कि कोई चीज़ क्या जानती है और क्या कर सकती है।
एक इंस्टेंस (या ऑब्जेक्ट) उस खाके से बनी एक ठोस चीज़ है—आपका विशेष "वह"।
एक मेथड वह ऑपरेशन है जो ऑब्जेक्ट किसी संदेश पर कर सकता है।
स्टेट ऑब्जेक्ट का वर्तमान डेटा है: वह अभी क्या याद रखता है, जो समय के साथ बदल सकता है।
Smalltalk ने एक एकसमान ऑब्जेक्ट मॉडल को लोकप्रिय किया: सब कुछ एक ऑब्जेक्ट है, और आप ऑब्जेक्ट्स के साथ एक सुसंगत तरीके से इंटरैक्ट करते हैं। इसने संदेश प्रेषण पर भी जोर दिया—आप किसी दूसरे ऑब्जेक्ट के अंदर तक नहीं पहुँचते; आप उसे संदेश भेजते हैं और वह तय करता है कि क्या करना है।
यह शैली स्वाभाविक रूप से लेट बाइंडिंग (डायनामिक डिस्पैच) के साथ मिलती है: प्रोग्राम रनटाइम पर तय कर सकता है कि किस ऑब्जेक्ट द्वारा कौन सा मेथड वास्तविक रूप से संभालेगा। व्यावहारिक लाभ लचीलापन है: आप कॉलर को फिर से लिखे बिना व्यवहार बदल सकते हैं।
एक उपयोगी संकेत: डिज़ाइन को इंटरैक्शन्स के इर्द-गिर्द रखें। पूछें "कौन से संदेश होने चाहिए?" और "कौन इस स्टेट का मालिक होगा?" यदि ऑब्जेक्ट्स साफ़-सुथरे तरीके से सहयोग करते हैं, तो क्लास संरचना अक्सर सरल और परिवर्तन-मैत्रीभूत बन जाती है—लगभग नतीजे के रूप में।
ग्राफिकल यूज़र इंटरफ़ेस (GUI) ने यह बदला कि "सॉफ़्टवेयर उपयोग करना" कैसा महसूस होता है। कमांड याद रखने की बजाय आप चीज़ों की ओर इंगित कर सकते हैं, उन्हें ले जा सकते हैं, खोल सकते हैं और तुरंत परिणाम देख सकते हैं। विंडोज़, मेन्यू, कंट्रोल्स, ड्रैग-एंड-ड्रॉप ने कंप्यूटिंग को फ़िज़िकल ऑब्जेक्ट्स को संभालने जितना निकट कर दिया—डायरेक्ट मैनिपुलेशन बनाम अमूर्त निर्देश।
उस "चीज़-नुमा"पन का मिलान स्वाभाविक रूप से ऑब्जेक्ट मॉडल से होता है। एक अच्छी तरह डिज़ाइन किए हुए GUI में, लगभग हर दिखाई देने वाली और इंटरेक्ट करने योग्य चीज़ को एक ऑब्जेक्ट माना जा सकता है:
यह केवल प्रोग्रामिंग सुविधा नहीं है; यह वैचारिक पुल है। उपयोगकर्ता ऑब्जेक्ट्स के संदर्भ में सोचता है ("इस विंडो को घसीटो", "उस बटन पर क्लिक करो"), और सॉफ़्टवेयर ऑब्जेक्ट्स से बना होता है जो वास्तव में वे क्रियाएँ कर सकते हैं।
जब आप क्लिक करते, टाइप करते या ड्रैग करते हैं, प्रणाली एक ईवेंट जेनरेट करती है। ऑब्जेक्ट-ओरिएंटेड दृष्टिकोण में, एक ईवेंट मूलतः किसी ऑब्जेक्ट को भेजा गया संदेश होता है:
फिर ऑब्जेक्ट्स संदेशों को अन्य ऑब्जेक्ट्स को आगे भेज सकते हैं ("डॉक्युमेंट को सेव करने के लिए कहो", "विंडो को फिर से ड्रॉ करने के लिए कहो"), जिससे समझने योग्य इंटरैक्शन्स की एक श्रृंखला बनती है।
क्योंकि UI दृश्यमान स्थिति वाले स्थायी ऑब्जेक्ट्स से बना है, यह एक वर्कस्पेस में प्रवेश करने जैसा लगता है न कि एक-बार के कमांड चलाने जैसा। आप विंडोज़ खुली छोड़ सकते हैं, टूल्स को व्यवस्थित कर सकते हैं, दस्तावेज़ पर लौट सकते हैं और उसी जगह से फिर काम शुरू कर सकते हैं। GUI एक सुसंगत वातावरण बन जाता है—जहाँ क्रियाएँ उन ऑब्जेक्ट्स के बीच बातचीत होती हैं जिन्हें आप देख सकते हैं।
Smalltalk के सबसे विशिष्ट विचारों में से एक सिंटेक्स फीचर नहीं था—यह इमेज था। प्रोग्राम को "सोर्स कोड जो कम्पाइल होकर ऐप बनता है" मानने के बजाय, Smalltalk सिस्टम को एक चलती दुनिया के रूप में देखता था। जब आप सेव करते, आप पूरे जीवित वातावरण को सहेज सकते थे: मेमोरी में ऑब्जेक्ट्स, खुले टूल्स, UI स्टेट और आपके काम की वर्तमान स्थिति।
इमेज-आधारित सिस्टम एक फिल्म को रोक कर न सिर्फ स्क्रिप्ट बल्कि ठीक फ्रेम, सेट और हर अभिनेता की स्थिति भी सहेजने जैसा है। जब आप फिर से शुरू करते हैं, तो आप वहीं वापस आ जाते हैं जहाँ छोड़ा था—आपके टूल्स खुले रहते हैं, आपके ऑब्जेक्ट्स मौजूद रहते हैं, और आपके परिवर्त already क्रियाशील होते हैं।
इससे तंग फीडबैक लूप संभव हुए। आप व्यवहार बदल सकते हैं, तुरंत आज़मा सकते हैं, जो हुआ देख सकते हैं और परिष्कृत कर सकते हैं—बिना उस मानसिक रीसेट के कि "पुनर्निर्माण करो, पुनः लॉन्च करो, डेटा फिर से लोड करो, स्क्रीन तक फिर नेविगेट करो।"
यह सिद्धांत आधुनिक "वाइब-कोडिंग" वर्कफ़्लो में भी दिखता है: जब आप किसी बदलाव का वर्णन सामान्य भाषा में कर सकते हैं, उसे तुरंत लागू होते देखते हैं और जल्दी दोहराते हैं, तो आप सिस्टम को तेज़ी से सीखते हैं और गतिशील बने रहते हैं। प्लेटफ़ॉर्म जैसे Koder.ai इसे प्रयोगात्मक चैट-आधारित लूप में बदलते हैं—योजना बनाओ, समायोजित करो, प्रीव्यू करो—फिर भी वास्तविक कोड एक्सपोर्ट करने योग्य।
आप Smalltalk इमेज विचार के अनुनाद आज भी कुछ फीचर्स में देख सकते हैं:
ये Smalltalk इमेज के समान नहीं हैं, पर इनका लक्ष्य वही है: विचार और उसके परिणाम के बीच की दूरी कम रखना।
पूरे रनिंग वर्ल्ड को सहेजना कठिन सवाल उठाता है। अगर "सत्य" म्यूटेबल स्टेट में रहता है बजाय साफ़ बिल्ड प्रोसेस के, तो पुनरुत्पादन मुश्किल हो सकता है। डिप्लॉयमेंट जटिल होता है: एक इमेज शिप करना ऐप, डेटा और वातावरण के बीच की रेखा धुंधला कर सकता है। बग्स भी जटिल हो सकते हैं जब वे किसी विशेष इंटरैक्शन अनुक्रम और जमा हुए स्टेट पर निर्भर हों।
Smalltalk का दांव यह था कि तेज़ सीखना और इटरेशन उन जटिलताओं के लायक था—और वह दांव आज भी कई टीमों की डेवलपर अनुभव (DX) सोच को प्रभावित करता है।
जब एलन केय ने सॉफ़्टवेयर के बारे में कहा, तो वे अक्सर उसे एक कोड के ढेर की बजाय एक प्रणाली के रूप में देखते थे: कई हिस्से जो समय के साथ इंटरैक्ट करते हैं और वह व्यवहार उत्पन्न करते हैं जिसकी आपको परवाह है।
कोई सिस्टम किसी एक घटक द्वारा परिभाषित नहीं होता। यह परिभाषित होता है रिश्तों द्वारा—कौन किससे बात करता है, वे क्या मांग कर सकते हैं, और उन वार्तालापों के दोहराव के साथ क्या होता है।
कुछ सरल कंपोनेंट्स दोहराव और फीडबैक जोड़ते ही जटिल व्यवहार पैदा कर सकते हैं। एक टाइमर जो टिक करता है, एक मॉडल जो स्टेट अपडेट करता है, और एक UI जो फिर से ड्रॉ करता है—हर एक सरल हो सकता है। इन्हें मिलाकर आपको एनिमेशन, undo/redo, ऑटोसैव, अलर्ट्स और "अब यह क्यों बदल गया?" जैसे पल मिलते हैं।
इसलिए सिस्टम सोच व्यावहारिक है: यह आपको लूप्स खोजने के लिए प्रेरित करती है ("जब A बदलेगा, B प्रतिक्रिया देगा, जो C को ट्रिगर करेगा…") और समय के बारे में सोचने के लिए ("10 मिनट के उपयोग के बाद क्या होता है?"), सिर्फ़ सिंगल फ़ंक्शन कॉल नहीं।
एक सिस्टम में, इंटरफेस लागू करने से ज़्यादा मायने रखते हैं। अगर एक हिस्सा दूसरे से केवल स्पष्ट संदेशों के माध्यम से इंटरैक्ट कर सकता है ("काउंट बढ़ाओ", "रेंडर करो", "इवेंट रिकॉर्ड करो"), तो आप आंतरिक हिस्सों को बदले बिना सब कुछ बदल सकते हैं।
यह केय के संदेश प्रेषण पर जोर के बहुत करीब है: आप दूसरे हिस्सों को सीधे नियंत्रित नहीं करते; आप पूछते हैं, वे जवाब देते हैं।
तीन ऑब्जेक्ट्स की कल्पना करें:
समय के साथ प्रवाह:
clicked भेजता है।increment भेजता है।changed(newValue) भेजता है।changed सुनकर रेंडर करता है।record("increment", newValue) प्राप्त करता है।किसी भी घटक को दूसरे के अंदर झाँकने की ज़रूरत नहीं। व्यवहार बातचीत से उभरता है।
एलन केय ने एक सरल विचार पर जोर दिया जो आज भी अजीब तरह से क्रांतिकारी लगता है: सॉफ़्टवेयर को सीखना आसान होना चाहिए, सिर्फ़ शक्तिशाली नहीं। "चतुर" डिज़ाइन अक्सर निर्माता की संतुष्टि के लिए ऑप्टिमाइज़ करता है—शॉर्टकट्स, छिपे हुए ट्रिक्स, घने अमूर्तियों—जबकि साधारण उपयोगकर्ता अनिश्चित इशारों को याद रखने में फँस जाते हैं।
केय सादगी के बारे में इसलिए परवाह करते थे क्योंकि यह स्केल करती है: एक अवधारणा जिसे शुरुआती आसानी से समझ लेते हैं, वह टीमों द्वारा सिखाई, साझा की और विस्तारित की जा सकती है।
बहुत सा सॉफ़्टवेयर उपयोगकर्ताओं को ऑपरेटर की तरह मानता है: सही बटन दबाओ, आउटपुट पाओ। केय का लक्ष्य सोचने वाले टूल के करीब था—ऐसा कुछ जो खोज को आमंत्रित करे, त्रुटि-आधारित परीक्षण का समर्थन करे, और लोगों को मानसिक मॉडल बनाने दे।
इसीलिए वे इंटरैक्टिव सिस्टम्स को महत्व देते थे जहाँ आप देख सकते हैं क्या हो रहा है और जैसे-जैसे आप चलते हैं समायोजन कर सकते हैं। जब सिस्टम तुरंत और अर्थपूर्ण तरीके से प्रतिक्रिया करता है, तो सीखना उपयोग का हिस्सा बन जाता है।
केय अक्सर सीखने का उपयोग करते थे—कभी बच्चों को उपयोगकर्ता मानकर—एक मजबूर करने वाले फ़ंक्शन के रूप में स्पष्टता के लिए। अगर किसी अवधारणा को सीधे हिलाया-डुबाया जा सके, निरीक्षण किया जा सके और बिना बहाने के समझाया जा सके, तो यह सभी के लिए बेहतर काम करता है।
इसे "केवल बच्चों के लिए डिज़ाइन" मत समझिए। इसका मतलब है कि सिखाने योग्यपन को एक गुणवत्ता जाँच के रूप में उपयोग करें: क्या सिस्टम अपनी स्वयं की तर्कसंगति प्रकट कर सकता है?
सीखने की क्षमता एक प्रोडक्ट फीचर है। आप इसे डिज़ाइन कर सकते हैं:
मुनाफा सिर्फ़ खुश शुरुआती उपयोगकर्ता नहीं है। यह तेज़ ऑनबोर्डिंग, कम सपोर्ट टिकट्स और एक उत्पाद है जिसे लोग आत्मविश्वास से बढ़ा सकते हैं—वही उपयोगकर्ता एजेंसी जिसे केय सॉफ़्टवेयर में बढ़ाना चाहते थे।
केय का काम "आज हम जो उपयोग करते हैं वो सब कुछ नहीं बनाया," पर उसने उन तरीकों पर गहरा प्रभाव डाला जिनसे कई लोग सॉफ़्टवेयर बनाएंगे—ख़ासकर मानव केंद्रित सॉफ़्टवेयर।
काफी आधुनिक प्रैक्टिस उन विचारों की गूँज है जिन्हें Smalltalk और Xerox PARC ने ठोस और लोकप्रिय बनाया:
मूल विज़न के कुछ हिस्से सीधे-सीधे नहीं टिके:
यदि आप ज़ोर से देखेंगे, तो कई वर्तमान पैटर्न संदेश प्रेषण के साथ तालमेल खाते दिखते हैं: कम्पोनेंट-आधारित UI (React/Vue), इवेंट-ड्रिवन ऐप्स, और यहां तक कि माइक्रोसर्विसेज जो HTTP या क्यूज़ के ज़रिये बात करते हैं। वे एक जैसे नहीं हैं—पर वे केय के मूल विचार (इंटरैक्टिंग पार्ट्स के रूप में सिस्टम) को आधुनिक बाधाओं के तहत फिर से व्याख्यायित करते हैं।
यदि आप इतिहास से प्रैक्टिकल ब्रिज चाहते हैं, तो अंतिम सेक्शन देखें (देखें /blog/practical-takeaways) जो इन प्रभावों को उन डिज़ाइन आदतों में बदल देता है जिन्हें आप तुरंत उपयोग कर सकते हैं।
केय का कार्य दार्शनिक लग सकता है, पर यह बहुत व्यावहारिक आदतों में बदलता है। आपको Smalltalk या यहाँ तक कि "OOP" करने की ज़रूरत नहीं है ताकि लाभ मिल सकें। लक्ष्य सॉफ़्टवेयर बनाना है जो बढ़ते समय भी समझने योग्य रहे।
जब आप शुरू कर रहे हों (या रिफैक्टरिंग कर रहे हों), सिस्टम का वर्णन उन भूमिकाओं के सेट के रूप में करने की कोशिश करें जो साथ में काम करती हैं:
यह आपको ज़िम्मेदारियों पर केंद्रित रखता है, न कि "क्लासेस क्योंकि हमें क्लासेस चाहिए" जैसे तर्कों पर।
डेटाबेस तालिकाओं या क्लास हाइरार्की पर बहस करने से पहले संदेश परिभाषित करें—एक हिस्सा दूसरे से क्या करने के लिए कहेगा।
एक उपयोगी अभ्यास: एक उपयोगकर्ता क्रिया के लिए छोटा "वार्तालाप" लिखें:
फिर ही तय करें कि वे भूमिकाएँ कैसे इंप्लीमेंट होंगी (क्लासेस, मॉड्यूल्स, सर्विसेज)। यह केय के "संदेश प्रेषण" पर जोर के अधिक निकट है: पहले व्यवहार, फिर संरचना।
केय लाइव सिस्टम्स की परवाह करते थे जहाँ आप परिवर्तनों के प्रभाव शीघ्र देख सकें। आधुनिक टीम में इसका मतलब अक्सर:
अगर आप यह नहीं बता सकते कि क्या बदला—या क्या बेहतर हुआ—तो आप अंधाधुंध तरीके से काम कर रहे हैं।
यदि आप चैट-आधारित वर्कफ़्लो (उदा. Koder.ai) के साथ बना रहे हैं, तो वही सलाह लागू होती है: प्रॉम्प्ट्स और जनरेटेड आउटपुट को तेज़ इटरेशन के तरीके के रूप में उपयोग करें, पर सीमाएँ स्पष्ट रखें, और स्नैपशॉट/रोलबैक तथा सोर्स-कोड एक्सपोर्ट जैसे सुरक्षात्मक उपाय रखें ताकि सिस्टम समय के साथ समझने योग्य बना रहे।
यदि यह खंड आपके साथ गूँजा, तो इन विषयों का अन्वेषण करें:
ये विषय नॉस्टैल्जिया से ज़्यादा स्वाद विकसित करने के बारे में हैं: ऐसा सॉफ्टवेयर बनाना जो सीखने योग्य, अनुवर्ती और प्रणालीगत रूप से सुसंगत हो।
एलन केय ने कंप्यूटर के साथ एक अलग संबंध की पैरवी की: कतार वाले बैच कार्यों के बजाए इंटरैक्टिव, व्यक्तिगत माध्यम—एक ऐसा माध्यम जो सीखने और बनाने के लिए अनुकूल हो।
यह दृष्टिकोण सीधे उन अपेक्षाओं को आकार देता है जिन्हें हम आज सामान्य मानते हैं—तुरंत प्रतिक्रिया, मनगढ़ंत इंटरफेस और ऐसा सॉफ़्टवेयर जिसे काम करते वक्त एक्सप्लोर और मॉडिफाई किया जा सके।
Dynabook एक पोर्टेबल, व्यक्तिगत कंप्यूटर का विज़न था जो मुख्यतः सीखने और रचनात्मकता (पढ़ना, लिखना, ड्रॉ करना, सिमुलेशन) के लिए डिज़ाइन किया गया था।
यह केवल "टैबलेट का पूर्वानुमान" नहीं था; यह इस बात को परिभाषित करता था कि सशक्त कंप्यूटिंग कैसा महसूस होनी चाहिए: उपयोगकर्ता ऑपरेटर नहीं, लेखक होने चाहिए।
Smalltalk में भाषा, टूल और UI एक समेकित वातावरण बनाते थे।
व्यवहारिक तौर पर इसका मतलब है कि आप रनिंग ऑब्जेक्ट्स को निरीक्षण कर सकते हैं, व्यवहार बदल सकते हैं, इंटरैक्टिवली डिबग कर सकते हैं और बार-बार रीबिल्ड/रिस्टार्ट किए बिना काम जारी रख सकते हैं—जिससे विचार और परिणाम के बीच की दूरी कम हो जाती है।
केय का मूल विचार "क्लासेस और इनहेरिटेंस" नहीं था, बल्कि ऑब्जेक्ट्स को स्वतंत्र एजेंट के रूप में देखना था जो संदेश भेजकर संवाद करते हैं।
डिज़ाइन के लिहाज से यह आपको स्पष्ट सीमाएँ परिभाषित करने के लिए प्रेरित करता है: कॉलर्स को उस चीज़ पर निर्भर रहना चाहिए जो ऑब्जेक्ट स्वीकार करता है, न कि उसकी आंतरिक डेटा संरचना पर।
आम गलतफहमी यह है कि OOP केवल एक प्रकार की टैक्सोनॉमी है: बहुत सी क्लासेस, गहरी इनहेरिटेंस और साझा म्यूटेबल डेटा।
केय के नजरिए से बेहतर नियम:
GUI सॉफ़्टवेयर को ऐसा बनाते हैं कि आप चीज़ों को हिलाते-घुमाते महसूस करें (विंडोज़, बटन्स, आइकॉन्स)। यह स्वाभाविक रूप से ऑब्जेक्ट मॉडल से मेल खाता है: हर UI तत्व की अपनी स्थिति और व्यवहार होता है।
उपयोगकर्ता क्रियाएँ (क्लिक, ड्रैग, कीबोर्ड इनपुट) घटनाएँ बन जाती हैं जो वस्तुतः ऑब्जेक्ट्स को भेजे गए संदेशों की तरह होती हैं, और वे फिर सिस्टम में अनुरोध अग्रेषित कर सकती हैं।
Smalltalk image पूरे रनिंग वर्ल्ड को सहेजता है: मेमोरी के ऑब्जेक्ट्स, खुले टूल्स, UI स्थिति और आपका वर्तमान काम।
फायदे:
ट्रेडऑफ़्स:
सिस्टम सोच समय के साथ व्यवहार पर केंद्रित होती है: फीडबैक लूप, परस्पर क्रियाएँ और कौन किससे बात करता है।
व्यवहार में, यह स्पष्ट इंटरफेस (संदेश) और कम छुपी निर्भरताओं वाली डिज़ाइन्स की ओर ले जाती है, क्योंकि आप ऐप को अलग-अलग भागों के रूप में देखते हैं—न कि सिर्फ़ अलग फ़ंक्शन्स के रूप में।
केय के विचारों को अपनाने के लिए Smalltalk की ज़रूरत नहीं है। कुछ व्यावहारिक कदम:
getTotal, isAvailable, authorize).फिर ही इंप्लीमेंटेशन चुनें (क्लासेस, मॉड्यूल, सर्विसेज)। पोस्ट के चेकलिस्ट को देखें: /blog/practical-takeaways।
आधुनिक उपकरण अक्सर केय के लक्ष्यों के अनुरूप होते हैं, भले ही लागू करने का तरीका अलग हो:
वे Smalltalk images जैसे नहीं हैं, पर लक्ष्य वही है: परिवर्तन और सीखना सस्ता बनाना।