অ্যালান কেয়ের বড় ধারণা: স্মলটক, GUI এবং সফটওয়্যার সিস্টেম

কেন অ্যালান কেয় আজও প্রতিদিনের সফটওয়্যারের জন্য গুরুত্বপূর্ণ

অ্যালান কেয় শুধুমাত্র প্রোগ্রামিং ইতিহাসের একটি নাম নয়। কম্পিউটার সম্পর্কে আমরা প্রতিদিন যে অনেক অনুমান করি—কি একটি “উইন্ডো”, কেন সফটওয়্যারই ইন্টারঅ্যাকটিভ হওয়া উচিত, কীভাবে প্রোগ্রাম সমবায় অংশগুলো থেকে গঠিত হতে পারে—এসবের বেশিরভাগ কেয় এবং তার টিম (প্রধানত Xerox PARC-এ) এগিয়ে দেওয়া ধারণাগুলোর দ্বারা আকৃত।

এই পোস্টটি ট্রিভিয়াল নয়; এটা ধারণাগুলো সম্পর্কে। আপনার কোডিং জানা লাগবে না যাতে বোঝা যায়, এবং এখানে বিরল টেকনিক্যাল বিশদ দেখানো হবে না। পরিবর্তে আমরা কয়েকটি মেন্টাল মডেলের উপর ফোকাস করব যা আজকের টুল এবং প্রোডাক্টগুলোতেও দেখা যায়: সফটওয়্যার কিভাবে বোঝা যায়, পরিবর্তিত করা যায় এবং শেখা যায়।

তিনটি থিম যেগুলো আমরা বারবার স্পর্শ করব

প্রথমত, Smalltalk: কেবল একটি প্রোগ্রামিং ভাষা নয়, বরং একটি পূর্ণমানের ওয়ার্কিং এনভায়রনমেন্ট যা অন্বেষণ ও শেখার উৎসাহ দেয়।

দ্বিতীয়ত, GUI (গ্রাফিক্যাল ইউজার ইন্টারফেস): উইন্ডো, আইকন, মেনু—ইন্টারঅ্যাকটিভ সফটওয়্যার এমন কিছু যা আপনি সরাসরি ম্যানিপুলেট করতে পারেন, কেবল নির্দেশ দেওয়ার চাইতে বেশি।

তৃতীয়ত, সিস্টেম চিন্তা: সফটওয়্যারকে কোড ফাইলের গাদা হিসেবে না দেখে আন্তঃক্রিয়াশীল অংশগুলোর একটি সেট হিসেবে দেখা।

পোস্টটি কী করবে না

এটি কেয়কে একক প্রতিভা হিসেবে উপস্থাপন করবে না, এবং বলবে না যে কোনো এক "সঠিক" প্যারাডাইমই সবকিছু ঠিক করে। কিছু ধারণা অসাধারণভাবে কাজ করেছে, কিছু ভুলভাবে বোঝা হয়েছে, এবং কিছু যতটা বিস্তার হওয়া উচিত ছিল ততটা ছড়ায়নি।

লক্ষ্যটা বাস্তবসম্মত: শেষে আপনি আধুনিক অ্যাপ এবং কোডবেসগুলোকে একটু পরিষ্কারভাবে দেখতে সক্ষম হবেন—কেন সেগুলো এমন অনুভূত হয়—এবং আপনার পরবর্তী প্রজেক্টে কী নিতে পারেন।

তিনি কোন সমস্যাটার সমাধান করতে চেয়েছিলেন

অ্যালান কেয় এমন এক কম্পিউটিং সংস্কৃতির মধ্যে ঢুকেছিলেন যা শক্তিশালী, ব্যয়বহুল এবং সাধারণ মানুষেদের প্রতি অধিকাংশ সময় উদাসীন ছিল। কম্পিউটারগুলোকে একটি শেয়ার করা অবকাঠামো মনে করা হত: সময় বুক করা, কাজ সাবমিট করা, এবং ফলাফলের জন্য অপেক্ষা করা। সেই মডেল সবকিছুকে প্রভাবিত করত—প্রোগ্রামের রূপ, কে ব্যবহার করতে পারে, এবং “সাফল্য” কী বোঝায়।

ব্যাচ কনফিগারেশন: ইন্টারঅ্যাকশন ছিল ব্যতিক্রম

বহু ব্যবহারকারীর জন্য কম্পিউটিং মানে ছিল মেশিনে একটি কাজ হস্তান্তর করা (প্রায়ই পাঞ্চ কার্ড বা কিউযুক্ত টার্মিনাল মাধ্যমে) এবং পরে আউটপুট পাওয়া। কিছু ভুল হলে আপনি ঘেঁচড়ে দেখেন না—আপনি পুনরায় সাবমিট করতেন এবং আবার অপেক্ষা করতেন। অন্বেষণ ধীর ছিল, এবং কম্পিউটারটি একটি দূরের সার্ভিসের মতো অনুভূত হত, এমন একটি টুল নয় যেটা নিয়ে আপনি চিন্তা করতে পারেন।

ব্যক্তিগত কম্পিউটিং: ভিন্ন লক্ষ্য

কেয়ের লক্ষ্য কেবল “ছোট কম্পিউটার” বানানো ছিল না। এটি সম্পর্কটাই আলাদা করে দিতে চেয়েছিল: একটি কম্পিউটার ব্যক্তিগত মাধ্যম হিসেবে, শেখা, লেখা, সিমুলেট করা, আঁকা এবং ধারণা গঠনের জন্য—বিশেষ করে শিশু ও অ-বিশেষজ্ঞদের জন্য। তার জন্য তাৎক্ষণিকতা দরকার ছিল। আপনার দেখতে হবে আপনার ক্রিয়াগুলো কী করছে, দ্রুত সংশোধন করতে হবে, এবং সৃজনশীল প্রবাহ বজায় রাখতে হবে।

কেন Xerox PARC-এর মতো জায়গাগুলো জরুরি ছিল

এ ধরনের পরিবর্তন অনুসরণ করতে হলে হার্ডওয়্যার, সফটওয়্যার এবং ইন্টারঅ্যাকশন ডিজাইন একসাথে পরীক্ষার জন্য জায়গা দরকার। Xerox PARC-এর মতো রিসার্চ ল্যাব দীর্ঘসময়ের শর্তে বাজি ধরার সুযোগ দিয়েছিল: নতুন ডিসপ্লে, নতুন ইনপুট ডিভাইস, নতুন প্রোগ্রামিং মডেল, এবং এগুলোকে একটি সঙ্গত অভিজ্ঞতায় প্যাকেজ করার উপায়। লক্ষ্যটি কোনো ফিচার বের করা ছিল না—বরং নতুন ধরণের কম্পিউটার ব্যবহার আবিষ্কার করা।

ইউজার এক্সপেরিয়েন্সকে প্রথম সারির সমস্যা করা

কম্পিউটার যদি শেখার ও সৃষ্টির মেশিন হতে চায়, usability আর পরের কাজ হতে পারে না। ইন্টারফেসকে আবিষ্কার, প্রতিক্রিয়া এবং বোঝার ক্ষমতা দিতে হবে। সেই ফোকাস কেয়কে এমন সিস্টেমগুলোর দিকে ঠেলে দিল যেখানে ইন্টারঅ্যাকশনের “ফিল”—আপনি ক্লিক করলে, এডিট করলে বা অন্বেষণ করলে কী ঘটে—সফটওয়্যারের গঠনগত পরিকল্পনার সঙ্গে ঘনিষ্ঠভাবে যুক্ত।

Dynabook ভিশন: শেখা ও সৃষ্টির জন্য একটি কম্পিউটার

অ্যালান কেয়ে শুরু করেন না “কিভাবে অফিস ওয়ার্ক দ্রুত করা যায়?” দিয়ে। তিনি একটি আলাদা প্রশ্ন দিয়ে শুরু করেছিলেন: যদি কোনো শিশু একটি বইয়ের মতো একটি ব্যক্তিগত কম্পিউটার বহন করতে পারে, এবং সেটি আইডিয়া অন্বেষণ, কিছু তৈরি করা এবং ডু করে শেখার জন্য ব্যবহার করতে পারে তাহলে কী হবে? ধারণাটি Dynabook-এ পরিণত হয়—বেশি হলেও একটি পণ্য স্পেস নয়, একটি উত্তর-তারকা ব্যক্তিগত কম্পিউটিংয়ের জন্য।

পোর্টেবল, ব্যক্তিগত এবং শেখার যোগ্য

Dynabook কল্পনা করা হয়েছিল হালকা, ব্যাটারি-চালিত এবং সর্বদা উপলব্ধ। কিন্তু সবচেয়ে গুরুত্বপূর্ণ শব্দ ছিল “পোর্টেবল” নয়—বলেছিল “ব্যক্তিগত।” এই কম্পিউটারটি ব্যবহারকারীর নিজের মতোই হবে, যেভাবে একটি নোটবুক বা যন্ত্র উপভোগ করা হয়—কিছু যা আপনি সময়ের সঙ্গে গঠন করেন, কেবল অপারেট করেন না।

ততটাই গুরুত্বপূর্ণ: এটি শেখার যোগ্য হতে হবে। কেয়ের লক্ষ্য ছিল কম্পিউটিংকে মেনুদের দেয়াল দিয়ে আড়ালে রেখে দেওয়া নয়; বরং মানুষকে ক্রমে লেখক হওয়ার সুযোগ দেওয়া।

শিক্ষা এবং সৃজনশীলতা, কেবল উৎপাদনশীলতা নয়

Dynabook-এর 'কিলার অ্যাপস' ছিল পড়া, লেখা, অঙ্কন, সঙ্গীত রচনা, বিজ্ঞান-সম্পর্কিত সিমুলেশন এবং ইন্টারঅ্যাকটিভ গল্প বানানো। এটি প্রোগ্রামিংকে একটি সাক্ষরতার মতো বিবেচনা করত—ধারণা প্রকাশের অন্য একটি উপায়—পেশাদারদের জন্য সংরক্ষিত বিশেষ ট্রেড নয়।

এই ফোকাসই বদলে দেয় 'ভাল সফটওয়্যার' কী মানে। একটি শেখার টুলকে টিঙ্কারিং আমন্ত্রণ জানাতে হবে, দ্রুত ফিডব্যাক দিতে হবে, এবং আবার চেষ্টা করা নিরাপদ করতে হবে।

ভিশনটি কোন এক ডিভাইসের চেয়েও বড়

Dynabook ট্যাবলেট ভবিষ্যদ্বাণী করছিল না; এটি কম্পিউটিংয়ের সঙ্গে একটি নতুন সম্পর্ক প্রস্তাব করছিল: চিন্তা ও সৃষ্টির জন্য একটি মাধ্যম। অনেক ডিভাইস এটি অনুকরণ করতে পারে, কিন্তু ভিশনটি ব্যবহারকারীকে ক্ষমতাবান করা সম্পর্কে—বিশেষ করে শিক্ষার্থীদের—নিয়ে, নির্দিষ্ট স্ক্রিন সাইজ বা হার্ডওয়্যার ডিজাইনের ব্যাপার নয়।

Smalltalk: কেবল ভাষা নয়, পুরো পরিবেশ

লোকেরা যখন “Smalltalk” শুনে, প্রায়শই একটি প্রোগ্রামিং ভাষার কথা ভাবেন। কেয়ের টিম এটা বড়ভাবে দেখত: একটি সম্পূর্ণ কাজের সিস্টেম যেখানে ভাষা, টুল এবং ব্যবহারকারীর অভিজ্ঞতা একসাথে ডিজাইন করা হয়।

সহজভাবে বলতে গেলে, Smalltalk এমন একটি সিস্টেম যেখানে প্রতিটি কিছুই একটি অবজেক্ট। স্ক্রিনের উইন্ডো, আপনি টাইপ করা টেক্সট, আপনি ক্লিক করা বাটন, আপনি গণনা করা সংখ্যা—প্রত্যেকটি এমন একটি অবজেক্ট যাকে আপনি কোনো কাজ করতে বলতে পারেন।

অন্বেষণের জন্য একটি "লাইভ" সিস্টেম

Smalltalk শেখার মাধ্যমে করার জন্য তৈরি করা হয়েছিল। কোড লিখে কম্পাইল করে আশা করার পরিবর্তে, আপনি চলমান সিস্টেমের অবজেক্টগুলো ইনস্পেক্ট করতে পারতেন, তাদের বর্তমান অবস্থা দেখতেন, পরিবর্তন করতেন এবং নতুন ধারণা তাৎক্ষণিকভাবে পারখ করতে পারতেন।

এই জীবন্ততা গুরুত্বপূর্ণ ছিল কারণ এটি প্রোগ্রামিংকে অন্বেষণে পরিণত করেছিল। আপনি কেবল ফাইল উৎপাদন করছেন না; আপনি একটি চলমান জগত গঠন করছেন। এটি কৌতুহল উত্সাহ দেয়: “এই জিনিসটা কী?” “এর ভিতরে কী আছে?” “এটি একটু টুইক করলে কী হবে?”

ভাষা + টুল + পরিবেশ, ঘনিষ্ঠভাবে যুক্ত

Smalltalk-এর ডেভেলপমেন্ট টুলগুলো আলাদা অ্যাড-অন ছিল না। ব্রাউজার, ইনস্পেক্টর, ডিবাগার, এবং এডিটরগুলো একই অবজেক্ট-ভিত্তিক জগতের অংশ ছিল। টুলগুলো সিস্টেমকে ভেতর থেকেই বুঝত, কারণ সেগুলোই একই মাধ্যমে তৈরি করা হয়েছিল।

এই ঘনিষ্ঠ ইন্টিগ্রেশন বদলে দিয়েছিল কাজ করার অনুভূতিটা: দূরের সোর্স কোড ম্যানেজ করা নয়, বরং আপনি যে সিস্টেম তৈরি করছেন তার সঙ্গে সরাসরি ইন্টারঅ্যাক্ট করা।

একটি মিলনীয় উপমা

একটি খোলা এবং প্রতিক্রিয়াশীল ডকুমেন্ট এডিট করার কথা ভাবুন—ফরম্যাটিং তৎক্ষণাৎ বদলায়, আপনি সার্চ, পুনরায়রচনা এবং আনডো করতে পারেন কোনো "বিল্ড" করার আগে। Smalltalk সেই ধরনের তাৎক্ষণিকতা চাইত, কিন্তু প্রোগ্রামের জন্য: আপনি চলমান জিনিস এডিট করেন, ফলাফল সঙ্গে সঙ্গে দেখেন, এবং চলতে থাকেন।

অবজেক্ট এবং মেসেজ পাসিং: মূল মেন্টাল মডেল

কেয়ের সবচেয়ে দরকারী মেন্টাল মডেলটি হলো “ক্লাস ও ইনহেরিট্যান্স” নয়—বস্তু হলো একটি ছোট, নিজস্ব গণনা-ক্ষমতাসম্পন্ন মেশিন: এটি নিজের স্টেট রাখে (এখন কী জানে) এবং যখন আপনি কিছু করতে বলবেন তখন নিজেই সিদ্ধান্ত নেয় কিভাবে প্রতিক্রিয়া জানায়।

অবজেক্টগুলোকে 'ছোট কম্পিউটার' হিসেবে ভাবুন

প্রতিটি অবজেক্টকে ভাবুন যা আছে:

• প্রাইভেট মেমরি (তার স্টেট)
• কিছু সক্ষমতা (যে কার্যগুলো করতে পারে)
• একটি সামনের দরজা (একটি উপায় অনুরোধ পাওয়ার)

এই ফ্রেমিংটি প্রায়োগিক কারণ এটি আপনার দৃষ্টি পরিবর্তন করে: “ডেটা কোথায় সংরক্ষিত?” থেকে “কে এই জবাবদিহি নেবে?” এ চলে যান।

দুইটি দৃষ্টিভঙ্গি: ডেটা স্ট্রাকচার বনাম অভিনেতা

একটি সাধারণ বিভ্রান্তি হলো অবজেক্টকে শুধু ফিল্ডের একটি বান্ডিল হিসেবে দেখা: কয়েকটি হেল্পার ফাংশনসহ। ঐ দৃষ্টিভঙ্গিতে, প্রোগ্রামের অন্যান্য অংশগুলো অবজেক্টের অন্তর্গত অবস্থা ফ্রিক করে এবং বদলে দেয়।

কেয়ের দৃষ্টিভঙ্গি_actor_ ধারণার কাছাকাছি: আপনি একটি অবজেক্টের ভিতরে ঢুকে তার আলমারিগুলো সাজান না। আপনি একটি অনুরোধ পাঠান এবং এটি নিজের স্টেট পরিচালনা করতে দেয়। এই বিভাজনটাই উদ্দেশ্য।

মেসেজ পাসিং—একটি দৈনন্দিন উদাহরণ

মেসেজ পাসিং মানে সহজভাবে অনুরোধ/প্রতিক্রিয়া।

একটি ক্যাফে কল্পনা করুন: আপনি রান্নাঘরে ঢুকে নিজের খাবার রান্না করেন না। আপনি অর্ডার দেন ("একটা স্যান্ডউইচ বানাও"), এবং আপনি ফল পান ("নিচ্ছে স্যান্ডউইচ" বা "রুটিতে নেই")। ক্যাফে সিদ্ধান্ত নেয় কিভাবে অর্ডার পূরণ করবে।

সফটওয়্যার অবজেক্টগুলোও একইভাবে কাজ করে: আপনি একটি বার্তা পাঠান ("মোট হিসাব কর", "সংরক্ষণ কর", "নিজেকে রেন্ডার কর") এবং অবজেক্ট প্রতিক্রিয়া দেয়।

কেন বার্তাগুলো সিস্টেমকে বৃদ্ধি করায় সাহায্য করে

যখন সিস্টেমের অন্যান্য অংশগুলো কেবল বার্তাগুলোর উপর নির্ভর করে, আপনি একটি অবজেক্টের অভ্যন্তরীণ কাজ পরিবর্তন করতে পারেন—অ্যালগরিদম বদলান, সংগ্রহস্থল বদলান, ক্যাশ যোগ করুন—বিনা পরিমার্জন করে সবখানে।

এভাবেই সিস্টেম বড় হয় ভাঙে না: সীমানায় স্থির চুক্তি এবং ভেতরে স্বাধীনতা।

'অবজেক্ট-ওরিয়েন্টেড' আসলে কী (এবং প্রচলিত বিভ্রান্তি)

লোকেরা প্রায়ই 'অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিং'কে ক্লাস ব্যবহারের সমতুল্য ধরে। এটা বোঝা যায়—অনেক ভাষা OOP ক্লাস ডায়াগ্রামের মাধ্যমে শেখায়। কিন্তু কেয়ের মূল জোরটা ছিল আলাদা: যোগাযোগকারী অংশগুলো নিয়ে চিন্তা করা।

কয়েকটি টার্ম, সহজভাবে

একটি ক্লাস হলো একটি ব্লুপ্রিন্ট: কি কিছু জানবে এবং কি করতে পারবে তা বর্ণনা করে।

একটি ইনস্ট্যান্স (অথবা অবজেক্ট) হলো ওই ব্লুপ্রিন্ট থেকে তৈরি একটি কংক্রিট জিনিস—আপনার নির্দিষ্ট "ওটাই"।

একটি মেথড হলো একটি অপারেশন যা অবজেক্টকে অনুরোধ করা হলে এটি করতে পারে।

স্টেট হলো অবজেক্টের বর্তমান ডেটা: সেটি এখন কী মনে রাখে, যা সময়ের সাথে বদলে যেতে পারে।

Smalltalk যা এগিয়ে এনেছে

Smalltalk একটি একরকম অবজেক্ট মডেল জনপ্রিয় করে তুলেছিল: সবই অবজেক্ট, এবং অবজেক্টগুলোর সঙ্গে ইন্টারঅ্যাকশন সঙ্গতিপূর্ণভাবে করা যায়। এটি মেসেজ পাসিং-এও জোর দেয়—অন্যের অভ্যন্তরীণ অংশে পৌঁছানোর বদলে আপনার বার্তা পাঠাবেন এবং এটি নিজে ঠিক করবে কী করা দরকার।

এই স্টাইলটি প্রায়শই লেট বাইন্ডিং (রানটাইমে সিদ্ধান্ত নেওয়া) এর সঙ্গে মিলে যায়: প্রোগ্রাম রানটাইমে ঠিক করে কোন মেথড কোন বার্তা হ্যান্ডেল করবে। ব্যবহারিক সুবিধা হলো নমনীয়তা: আপনি কলার বদল না করে আচরণ বদলাতে পারেন।

প্রচলিত বিভ্রান্তি (এবং বদলে কী করা উচিত)

• OOP হলো "ক্লাস+ইনহেরিট্যান্স" না। ইনহেরিট্যান্স একটি টুল, এবং প্রায়ই অতিরিক্ত ব্যবহৃত হয়।
• OOP হলো ট্যাক্সোনমি নয়। টাইপের নাম ও সংগঠন গুরুত্বপূর্ণ, কিন্তু সেটাই উদ্দেশ্য নয়।

একটি ব্যবহারযোগ্য রুল অফ থাম্ব: ইন্টারঅ্যাকশন ঘিরে ডিজাইন করুন। প্রশ্ন করুন "কোন কোন বার্তাগুলো থাকা উচিত?" এবং "কে এই স্টেটের দায়িত্বে থাকবে?" যদি অবজেক্টগুলো সুন্দরভাবে সহযোগিতা করে, ক্লাস স্ট্রাকচার সাধারণত সহজে এবং পরিবর্তনবান্ধবভাবে গড়ে ওঠে।

GUI কীভাবে অবজেক্ট মডেলের সঙ্গে সংযুক্ত

একটি গ্রাফিক্যাল ইউজার ইন্টারফেস (GUI) সফটওয়্যার ব্যবহারের অনুভূতিটা বদলে দেয়। কমান্ড মনে রাখার পরিবর্তে আপনি পয়েন্ট ও ম্যানিপুলেট করতে পারেন, বস্তুগুলো সরান, খুলুন এবং তাৎক্ষণিক ফল দেখেন। উইন্ডো, মেনু, কন্ট্রোল ও ড্র্যাগ-অ্যান্ড-ড্রপ সবই এমন বিশ্বাস প্রতিফলিত করে: ইন্টারফেসটি অন্বেষণ করে শেখার উপযোগী হওয়া উচিত।

ডাইরেক্ট ম্যানিপুলেশন একটি অবজেক্ট ধারণা

"বস্তু-হিসেবের" ধারণা অবজেক্ট মডেলের সঙ্গে মিল খায়। একটি ভাল ডিজাইনের GUI-তে দেখা ও ইন্টারঅ্যাক্ট করা প্রায় প্রতিটি জিনিসকে অবজেক্ট হিসেবে বিবেচনা করা যায়:

• একটি উইন্ডো হলো এমন একটি অবজেক্ট যার স্টেট আছে (আকার, অবস্থান, শিরোনাম) এবং আচরণ আছে (খোলা, বন্ধ, রিসাইজ)।
• একটি মেনু হলো একটি অবজেক্ট যে অপশন প্রদর্শন করে এবং সিলেকশনে প্রতিক্রিয়া করে।
• একটি আইকন হলো একটি অবজেক্ট যা সিলেক্ট, ড্র্যাগ এবং অ্যাক্টিভেট করা যায়।

এটা কেবল প্রোগ্রামিং সুবিধা নয়; এটি ধারণাগত সেতু। ব্যবহারকারী ‘উইন্ডো সরাও’, ‘বাটনে ক্লিক কর’—এমন ভাবেই চিন্তা করে, এবং সফটওয়্যারটি এসব কাজ বাস্তবে করতে পারে।

ইভেন্টগুলি অবজেক্টগুলোর মধ্যে বার্তা হয়ে ওঠে

আপনি ক্লিক করলে, টাইপ করলে বা ড্র্যাগ করলে সিস্টেম একটি ইভেন্ট তৈরি করে। অবজেক্ট-ওরিয়েন্টেড দৃষ্টিভঙ্গিতে, একটি ইভেন্ট হলো মূলত একটি বার্তা:

• একটি ক্লিক হলো একটি বাটনে পাঠানো বার্তা: "তুমি প্রেসড হয়েছ।"
• টাইপিং হলো টেক্সট ফিল্ডকে পাঠানো চর একটির ধারাবাহিক বার্তা: "এই অক্ষর ইন্সার্ট করো।"
• ড্র্যাগিং হলো বারবার বার্তা: "পয়েন্টার সরল; তোমার অবস্থান আপডেট করো।"

তারপর অবজেক্টগুলো বার্তাগুলো অন্যদের কাছে ফরোয়ার্ড করতে পারে ("ডকুমেন্টকে বলো সেভ কর", "উইন্ডোকে বলো রিড্র করে"), ফলে একটি বোঝানোর যোগ্য অন্তঃক্রিয়া শৃঙ্খলা তৈরি হয়।

কেন এটি "কাজ করার একটি জায়গা" মনে হয়

UI টিকে ধারাবাহিক অবজেক্ট হিসেবে দেখায়, তাই এটি একটি কার্যক্ষেত্র প্রবেশের মতো মনে হয়—একটি একবারের কমান্ড চালানোর বদলে। উইন্ডো খোলা রাখতেই পারেন, টুলগুলো সাজাতে পারেন, একটি ডকুমেন্টে ফিরে এসে যেখানে ছিলেন সেখানে কাজ চালিয়ে যেতে পারেন। GUI একটি সঙ্গতিপূর্ণ পরিবেশ হয়ে ওঠে—একটি যেখানে কাজগুলো দৃশ্যমান অবজেক্টগুলোর মধ্যে কথোপকথন।

'লাইভ সিস্টেম' ধারণা: ফিডব্যাক লুপ এবং ইমেজ

Smalltalk-এর সবচেয়ে আলাদা ধারণাগুলোর একটি ছিল ইমেজ। সোর্স কোডকে কম্পাইল করে একটি অ্যাপে পরিণত করার বদলে, Smalltalk সিস্টেমটিকে একটি চলমান জগত হিসেবে দেখত। যখন আপনি সেভ করতেন, আপনি সম্পূর্ণ জীবন্ত পরিবেশই সেভ করতে পারতেন: মেমরির অবজেক্ট, খুলে থাকা টুল, UI স্টেট এবং আপনার কাজের বর্তমান অবস্থা।

পুরো চলমান জগতকে সংরক্ষণ করা

একটি ইমেজ-ভিত্তিক সিস্টেম হলো একটি চলমান চলচ্চিত্র পজ করে কেবল স্ক্রিপ্ট নয়, সঠিক ফ্রেম, সেট এবং প্রতিটি অভিনেতার অবস্থাও সেভ করা। যখন আপনি পুনরায় চালু করেন, আপনি ঠিক সেখানে ফিরে আসেন যেখানে ছেড়ে ছিলেন—আপনার টুলগুলো খোলা, অবজেক্টগুলো এখনও আছে, এবং আপনার পরিবর্তনগুলো ইতিমধ্যেই কার্যকর।

কেন এটি দ্রুত ফিডব্যাক দেয়

এটি কঠোর ফিডব্যাক লুপকে সমর্থন করে। আপনি আচরণ পরিবর্তন করতে পারেন, তা তাৎক্ষণিকভাবে চেষ্টা করতে পারেন, কী হচ্ছে তা পর্যবেক্ষণ করতে পারেন, এবং পরিমার্জন করতে পারেন—বারবার "রিবিল্ড, রিলঞ্চ, ডেটা রিলোড, স্ক্রিন নেভিগেট" করার মানসিক রিসেট ছাড়া।

এই একই নীতি আধুনিক "vibe-coding" ওয়ার্কফ্লোতেও দেখা যায়: যখন আপনি সাধারণ ভাষায় একটি পরিবর্তন বর্ণনা করতে পারেন, তা তাৎক্ষণিকভাবে প্রিভিউ দেখতে পান এবং পুনরাবৃত্তি করেন, তখন আপনি সিস্টেমকে দ্রুত শিখেন এবং গতি ধরে রাখতে পারেন। প্ল্যাটফর্মগুলি যেমন Koder.ai কথ্য-ভিত্তিক প্রক্রিয়ায় এটির উপর নির্ভর করে—পরিকল্পনা, সামঞ্জস্য, প্রিভিউ—এবং সত্ত্বেও বাস্তব কোড রপ্তানি ও বজায় রাখা যায়।

আধুনিক মিল—তথ্যগত হলেও একই নয়

এখানে Smalltalk ইমেজের অনুরণন পাওয়া যায়:

• অ্যাপগুলোতে অটোসেভ ও স্টেট রিস্টোরেশন
• কিছু ডেভেলপমেন্ট টুলে হট রিলোড
• ইন্টারেক্টিভ নোটবুক যেখানে কাজ করতে করতে ফলাফল দেখা যায়

এসব Smalltalk ইমেজের সম-ই নয়, কিন্তু উদ্দেশ্য একই: একটি ধারণা ও তার ফলাফলের মধ্যে দূরত্ব যতটা সম্ভব ছোট করা।

ট্রেডঅফ: ক্ষমতা কিন্তু ধারালো ধার

পুরো চলমান জগত সংরক্ষণ করা কঠিন প্রশ্ন তোলে। যদি "সত্য" একটি মিউটেবল স্টেটে থাকে, পরিষ্কার বিল্ড প্রসেসের বদলে, পুনরুত্পাদনশীলতা দুর্বল হতে পারে। ডিপ্লয়মেন্ট জটিল হয়: একটি ইমেজ শিপ করলে অ্যাপ, ডেটা এবং পরিবেশের মধ্যে সীমানা ঝাপসা হয়ে যায়। নির্দিষ্ট ক্রিয়াকলাপ ও সামঞ্জস্যপূর্ণ স্টেটের উপর নির্ভরশীল বাগ ডিবাগ করাও জটিল হতে পারে।

Smalltalk-এর শর্ত ছিল দ্রুত শেখা ও পুনরাবৃত্তি করা সেই জটিলতাগুলোকে মূল্যবান করে—এবং সেই শর্তটি আজও অনেক টিমের ডেভেলপার এক্সপেরিয়েন্সের চিন্তাভাবনায় ছাপ ফেলে।

সিস্টেম চিন্তা: আন্তঃক্রিয়াশীল অংশ হিসেবে সফটওয়্যার

অ্যালান কেয়ে যখন সফটওয়্যার নিয়ে কথা বলতেন, তিনি তা প্রায়শই একটি সিস্টেম হিসেবে বিবেচনা করতেন: অনেক উপাদানসমূহ যা সময়ের সঙ্গে একে অপরের সঙ্গে মিশে আচরণ তৈরি করে।

একটি সিস্টেম কোনো একক উপাদান দ্বারা সংজ্ঞায়িত হয় না। এটি সংজ্ঞায়িত হয় সম্পর্কগুলো দ্বারা—কে কার সাথে কথা বলে, তারা কী অনুরোধ করতে পারবে, এবং সেই কথোপকথনগুলো বারবার ঘটলে কী ঘটে।

ছোট অংশ, অপ্রত্যাশিত ফল

কয়েকটি সহজ উপাদানই জটিল আচরণ তৈরি করতে পারে যখন আপনি পুনরাবৃত্তি ও ফিডব্যাক যোগ করেন। একটি টাইমার, একটি মডেল যা স্টেট আপডেট করে, এবং একটি UI যা পুনরায় আঁকে—প্রতিটি সহজ হলেও একত্রে তারা অ্যানিমেশন, আনডো/রিডো, অটোসেভ, এলার্ট এবং “এটা কেন বদলে গেল?” ধরনের আচরণ তৈরি করতে পারে।

এজন্য সিস্টেম চিন্তা ব্যবহারিক: এটা আপনাকে লুপগুলো খুঁজে বের করতে বলে ("A বদলে গেলে B কীভাবে প্রতিক্রিয়া করে, যা C-কে ট্রিগার করে…") এবং সময়কে বিবেচনা করতে বলে ("১০ মিনিট ব্যবহারির পর কী ঘটে?")—কেবল একক ফাংশন কল নয়।

ইন্টারফেস (বার্তা) অভ্যন্তরীণ বিবরণ ছাড়িয়ে গুরুত্ব পায়

একটি সিস্টেমে, ইন্টারফেসগুলো বাস্তবে ইমপ্লিমেন্টেশনের চাইতে বেশি গুরুত্বপূর্ণ। যদি একটি অংশ অন্যটিকে স্পষ্ট বার্তাগুলোর মাধ্যমে ইন্টারঅ্যাক্ট করে ("কাউন্ট বাড়াও", "রেন্ডার করো", "ইভেন্ট রেকর্ড করো"), আপনি অভ্যন্তরীণ পরিবর্তন করে দিতে পারেন বাকি সিস্টেম ছেড়ে দিয়ে।

এটি কেয়ের মেসেজ পাসিং জোরের সঙ্গে মিলছে: আপনি অন্য অংশ নিয়ন্ত্রণ করেন না; আপনি জিজ্ঞেস করেন, তারা উত্তর দেয়।

সহজ উদাহরণ: বাটন → মডেল → লগ

ধরুন তিনটি অবজেক্ট আছে:

• Button: শুধু ক্লিক ঘোষণা করতে জানে।
• CounterModel: বর্তমান কাউন্ট এবং বাড়ানোর নিয়ম জানে।
• EventLog: গুরুত্বপূর্ণ ঘটনা রেকর্ড করে।

সময়ের উপর প্রবাহ:

1. Button clicked পাঠায়।
2. কন্ট্রোলার (অথবা বাটন) increment পাঠায় CounterModel-কে।
3. CounterModel স্টেট আপডেট করে, তারপর changed(newValue) পাঠায়।
4. UI changed শুনে রেন্ডার করে।
5. EventLog record("increment", newValue) গ্রহণ করে।

কোনো উপাদান আরেকটির ভেতর ঢুকে দেখছে না। আচরণ কথোপকথন থেকে উদ্ভূত হয়।

মানুষের জন্য ডিজাইন: শেখবার যোগ্যতা বেছে নেওয়া

অ্যালান কেয়ে একটি সরল ধারণা প্রস্তাব করেছিলেন যা আজও কিছুটা বিপ্লবী মনে হয়: সফটওয়্যারকে শক্তিশালী করার বদলে শেখা সহজ হওয়া উচিত। “চতুর” ডিজাইন প্রায়ই নির্মাতার সন্তুষ্টির জন্য অপ্টিমাইজ করে—শর্টকাট, লুকোনো কৌশল, ঘন আবস্ট্রাকশন—এবং সাধারণ ব্যবহারকারীদের চলে যায় মনের মধ্যে আচরণ শিড়িয়ে নেওয়ার দিকে।

কেয়ে সরলতাকে গুরুত্ব দিয়েছেন কারণ এটি স্কেল করে: একটি ধারণা যা একজন শিক্ষার্থী দ্রুত ধরতে পারে, তা টিমে শিখানো, ভাগ করা এবং উপর ভিত্তি করে নির্মাণ করা সহজ করে।

ব্যবহারকারী ক্ষমতায়ন: মানুষের চিন্তা সাহায্য করে এমন টুল

অনেক সফটওয়্যার ব্যবহারকারীদের অপারেটর হিসেবে দেখে: সঠিক বোতাম চাপলে আউটপুট পাবেন। কেয়ের লক্ষ্য ছিল চিন্তা-সহায়ক টুল—এমন কিছু যা অন্বেষণ আমন্ত্রণ জানায়, পরীক্ষা-নিরীক্ষা সমর্থন করে, এবং মানুষের মেন্টাল মডেল বানাতে দেয়।

এই কারণে তিনি ইন্টারঅ্যাকটিভ সিস্টেমকে মূল্য দিয়েছেন যেখানে আপনি কী হচ্ছে তা দেখতে পান এবং চলতে চলতে সামঞ্জস্য করতে পারেন। যখন সিস্টেম তাৎক্ষণিক ও অর্থপূর্ণ প্রতিক্রিয়া দেয়, শেখা ব্যবহার করার অংশে পরিণত হয়।

শিক্ষা ডিজাইনের একটি চালক হিসেবে (বিশেষ করে শিশুদের জন্য)

কেয়ে প্রায়ই শেখাকে (কখনও কখনও শিশুদের ব্যবহারকারী হিসেবে কল্পনা করে) ক্লারিটি শক্তির জন্য ব্যবহার করতেন। যদি কোনও ধারণা সরাসরি ম্যানিপুলেট করা যায়, ইন্সপেক্ট করা যায় এবং ব্যাখ্যা করা যায়—হাত ঝাপটা ছাড়াই—তাহলেই সেটি সবার জন্য কাজ করার সম্ভাবনা বেশি।

এটার মানে নয় "শুধু বাচ্চাদের জন্য ডিজাইন করা"। এর মানে হলো শেখাতে সক্ষমতা একটি মান নির্দেশক: সিস্টেম নিজের যুক্তি প্রকাশ করতে পারে কি না?

প্রোডাক্ট ডিসিশনে অনুবাদ করা

শিখার যোগ্যতাকে একটি প্রোডাক্ট ফিচার হিসেবে বিবেচনা করুন। আপনি ডিজাইন করতে পারেন:

• প্রথম ব্যবহার মুহূর্তে ঘর্ষণ কমান: কম ধাপ, কম অবাক করা, পরিষ্কার ডিফল্ট
• মূল ধারণাগুলো দৃশ্যমান করুন: স্টেট দেখান, সম্পর্ক দেখান, কী ঘটবে তা দেখান
• আবিস্কারযোগ্য অ্যাকশনকে লুকোনোদের উপরে প্রাধান্য দিন: মেনু, অ্যাফোর্ড্যান্স, প্রিভিউ ছদ্ম-জেসচারের চাইতে ভালো

ফলাফল শুধু সুখী শিক্ষার্থীরা নয়। দ্রুত অনবোর্ডিং, কম সাপোর্ট টিকট এবং এমন একটি প্রোডাক্ট যাকে লোকেরা আত্মবিশ্বাসের সঙ্গে বাড়াতে পারে—এগুলোই কেয় চেয়েছিলেন সফটওয়্যার দিয়ে বাড়ানো।

আধুনিক সফটওয়্যার কি গ্রহণ করেছে (এবং কি গ্রহণ করেনি)

কেয়ের কাজ সবকিছু আবিষ্কার করেনি, তবে এটি অনেককিছুর উপর গভীর প্রভাব ফেলেছে—বিশেষ করে মানুষের জন্য তৈরি সফটওয়্যার কীভাবে বানানো হয় তা নিয়ে।

যা অগ্রসর হয়ে গিয়েছে

অনেক আধুনিক অনুশীলন তাদের ভিত্তি পায় Smalltalk এবং Xerox PARC-সংস্কৃতি থেকে:

• অবজেক্টগুলো সক্রিয় সহযোগী: একটি প্রোগ্রামকে একক ধাক্কা নয়, বরং অংশগুলোর আন্তঃক্রিয়া হিসেবে মডেল করা।
• মেসেজ-স্টাইল কমিউনিকেশন: কেবল literal Smalltalk মেসেজ না হলেও API এবং ইভেন্টগুলোকে অংশগুলোর মধ্যে অনুরোধ হিসেবে ডিজাইন করা হয়।
• GUI প্যাটার্ন: উইন্ডো, মেনু, কন্ট্রোল, ড্র্যাগ-এন্ড-ড্রপ—এসব অন্বেষণভিত্তিক শেখার ইচ্ছাকে প্রতিফলিত করে।
• টুলগুলো যা ফিডব্যাক লুপ সংক্ষিপ্ত করে: ইন্টারেক্টিভ ডিবাগার, ইনস্পেক্টর, হট রিলোড, REPL—সবাই একই লক্ষ্য রাখে: পরিবর্তন সস্তা করা এবং শেখাকে ধারাবাহিক রাখা।

যা বদলেছে (বা টিকেনি)

মূল ভিশনের কিছু অংশ সোজা করে চলে আসেনি:

• স্কেল ও ডিস্ট্রিবিউশন: Smalltalk একটি সম্পর্কতঃ সামঞ্জস্যপূর্ণ, লোকাল "ওয়ার্ল্ড" কল্পনা করত। আধুনিক সিস্টেম ডিভাইস, নেটওয়ার্ক এবং টিম জুড়ে ছড়িয়ে আছে।
• পারফরম্যান্স সীমাবদ্ধতা: আজকার প্রত্যাশা (তাতক্ষণিক স্টার্টআপ, ব্যাটারি দক্ষতা, বিশাল ডেটাসেট) প্রায়ই ডিজাইনকে ক্যাশিং, ব্যাচিং ও রিসোর্স কন্ট্রোলে ঠেলে দেয়।
• 'পুরো এনভায়রনমেন্ট' পদ্ধতি: অধিকাংশ ডেভেলপার এখন একক শেয়ারড ইমেজে বাস করে না; আমরা রিপোজিটরি, সার্ভিস, কনটেইনার এবং CI পাইপলাইন নিয়ে কাজ করি।

আধুনিক অনুরণন—সাবধানে ব্যবহৃত

আপনি যদি নজরদারি করেন, অনেক বর্তমান প্যাটার্ন মেসেজ পাসিংয়ের সঙ্গে অনুরণন করে: কম্পোনেন্ট-ভিত্তিক UI (React/Vue), ইভেন্ট-চালিত অ্যাপ, এমনকি মাইক্রোসার্ভিসগুলো HTTP বা কিউজের মাধ্যমে যোগাযোগ করে। এগুলো একই নয়—কিন্তু কেয়ের মূল ধারণা (অন্তঃক্রিয়াশীল অংশ হিসেবে সিস্টেম) আধুনিক সীমাবদ্ধতার মধ্যেই পুনরায় ব্যাখ্যা হচ্ছে।

যদি আপনি ইতিহাস থেকে অনুশীলনে সরাসরি পুল করতে চান, পোস্টের শেষ অংশটি (দেখুন /blog/practical-takeaways) এই প্রভাবগুলোকে এমন ন্যায়সঙ্গত ডিজাইন অভ্যাসে রূপান্তর করে যা আপনি অবিলম্বে ব্যবহার করতে পারবেন।

ব্যবহারযোগ্য বাস্তব টেকনিকস — আপনার পরবর্তী প্রজেক্টে কী নিতে হবে

কেয়ের কাজ দার্শনিক শুনাতে পারে, কিন্তু তা খুবই ব্যবহারিক অভ্যাসে অনুবাদ করা যায়। আপনাকে Smalltalk ব্যবহার করার দরকার নেই—এমনকি কঠোরভাবে OOP করবেই না বলে কেয়ের লাভ মিলবে। লক্ষ্যটি এমন সফটওয়্যার তৈরি করা যা বেড়ে ওঠার সঙ্গে বোঝা সহজ থাকে।

একটি দ্রুত চেকলিস্ট: সমস্যাটিকে সহযোগী ভূমিকা হিসেবে মডেল করুন

শুরুতে (অথবা রিফ্যাক্টরিংয়ে) চেষ্টা করুন সিস্টেমটিকে এমন ভূমিকা-সমষ্টি হিসেবে বর্ণনা করতে:

• ভূমিকা গুলোকে সাধারণ ভাষায় নাম দিন (যেমন Cart, PricingRules, Inventory, Payment, Notification)।
• প্রতিটি ভূমিকার জন্য লিখুন: "এটি কী জানে?" এবং "এটি কী করতে পারে?"
• প্রতিটি ভূমিকা কিছুটা সংক্ষিপ্ত রাখুন—কয়েক বাক্যে বোঝানো যায় এমন।
• নিশ্চিত করুন ভূমিকা গুলো আচরণ নির্ভর হয়, পরস্পরের অভ্যন্তরীণ ডেটার উপর নয়।

এতে আপনি ক্লাস দরকার এয়ারোপার্কে নয়, দায়িত্বে ফোকাস রাখেন।

মেসেজ-প্রথম চিন্তাভাবনা: স্ট্রাকচারের আগে ইন্টারঅ্যাকশন নির্ধারণ করুন

ডেটাবেস টেবিল বা ক্লাস হায়ারার্কি নিয়ে ঝগড়ার আগে বার্তাগুলো সংজ্ঞায়িত করুন—একটি অংশ অন্যটি কী ধরনের অনুরোধ করবে তা।

একটি ব্যবহারযোগ্য ব্যায়াম: একটি ব্যবহারকারীর কার্যক্রমের ছোট “কনভারসেশন” লিখুন:

• “Checkout getTotal জানে।”
• “PricingRules Inventory-কে isAvailable জিজ্ঞাসা করে।”
• “Checkout Payment-কে authorize বলবে।”
• “Checkout Notification-কে রসিদ পাঠাতে বলবে।”

তারপরই সিদ্ধান্ত নিন কিভাবে ভূমিকা বাস্তবায়িত হবে (ক্লাস, মডিউল, সার্ভিস)। এটি কেয়ের জোর—মেসেজ পাসিং: আগে আচরণ, পরে কাঠামো।

টিমের জন্য পরামর্শ: পরিষ্কার সীমানা ও ছোট ফিডব্যাক লুপ

কেয় লাইভ সিস্টেম পছন্দ করতেন যেখানে পরিবর্তনের প্রভাব দ্রুত দেখা যায়। আধুনিক টিমে এর মানে সাধারণত:

• পরিষ্কার সীমানা: একটি কম্পোনেন্ট কী প্রতিশ্রুতি দেয় তা সংজ্ঞায়িত করুন, এবং অন্যরা তার অভ্যন্তরীণ অংশে অনুপ্রবেশ করে না।
• সংক্ষিপ্ত ফিডব্যাক লুপ: দ্রুত টেস্ট, প্রিভিউ পরিবেশ, ছোট পুল রিকোয়েস্ট, ঘন ইন্টিগ্রেশন।
• দৃশ্যমান আচরণ: লগ ও মেট্রিক্স যা বলে দিচ্ছে বার্তা ও ওয়ার্কফ্লো সফল হচ্ছে কি না।

আপনি যদি একটি চ্যাট-চালিত ওয়ার্কফ্লো (উদাহরণস্বরূপ Koder.ai) দিয়ে নির্মাণ করেন, একই উপদেশ প্রযোজ্য: প্রম্পট ও উৎপাদিত আউটপুটকে দ্রুত পুনরাবৃত্তির উপায় হিসেবে ব্যবহার করুন, কিন্তু সীমানাগুলো স্পষ্ট রাখুন, এবং স্ন্যাপশট/রোলব্যাক ও সোর্স-কোড এক্সপোর্টের মত সেফগার্ড রাখুন যাতে সিস্টেম বুঝতে সহজ থাকে।

যদি আপনি গভীরে যেতে চান

এই বিষয়গুলো আরও অন্বেষণ করুন:

• Smalltalk (পরিবেশ হিসেবে, শুধু সিনট্যাক্স নয়)
• Xerox PARC এর রিসার্চ ও প্রোটোটাইপ
• Dynabook ধারণা ও “কম্পিউটিং একটি মাধ্যম” চিন্তা
• সফটওয়্যার সিস্টেম চিন্তাভাবনা (কিভাবে আন্তঃক্রিয়াশীল অংশগুলো ফলাফল তৈরি করে)

এই বিষয়গুলো নস্টালজিয়া নয়—এগুলো স্বাদের উন্নয়নের বিষয়ে: এমন সফটওয়্যার বানানো যা শেখার যোগ্য, অভিযোজনশীল এবং একটি সিস্টেম হিসেবে সঙ্গতিপূর্ণ।