জন ম্যাকার্থি, লিস্প এবং সিম্বলিক এআই ডিজাইনের মূল

কেন ম্যাকার্থি ও লিস্প এখনও প্রাসঙ্গিক

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

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

ম্যাকার্থির উত্তরাধিকারকে পড়ার একটি কার্যকরি উপায় হলো একটি প্রশ্ন যা আজও গুরুত্বপূর্ণ: কতটা সরাসরি আমরা অভিপ্রায়কে একটি কার্যকর সিস্টেমে পড়াতে পারি—বিনা অতিরিক্ত বয়লারপ্লেট, ঘর্ষণ, বা দুর্ঘটনাক্রমে জটিলতার ভিড়ে ডুবে না যায়? এই প্রশ্নটি লিস্পের REPL থেকে আধুনিক “চ্যাট-টু-অ্যাপ” ওয়ার্কফ্লো পর্যন্ত প্রতিধ্বনিত হয়।

জন ম্যাকার্থির বড় ধারণা: যুক্তি প্রোগ্রামযোগ্য বানান

জন ম্যাকার্থি কেবলমাত্র AI গবেষণার সূচনা করেছেন বলে স্মরণীয় নন; তিনি একটি নির্দিষ্ট ধরনের AI উপর জোর দিয়েছিলেন: এমন সিস্টেম যা ধারণাগুলোকে পরিচালনা করতে পারে, কেবল উত্তর গণনা নয়। 1950-এর দশকের মাঝামাঝি তিনি ডার্টমাউথ সামার রিসার্চ প্রজেক্ট আয়োজন করেন (যেখানে “artificial intelligence” টার্মটি প্রস্তাবিত হয়) এবং পরবর্তীতে MIT ও স্ট্যানফোর্ডে AI কাজকে আকৃত দিয়েছেন। কিন্তু তাঁর সবচেয়ে স্থায়ী অবদান হতে পারে সেই প্রশ্ন যা তিনি বারবার করেছেন: ধারণাকে নিজেই কি একটি প্রোগ্রামে প্রকাশ করা যায়?

সংখ্যার থেকে প্রতীক পর্যন্ত

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

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

ম্যাকার্থির পদ্ধতি জ্ঞানকে প্রতীকে (নাম, সম্পর্ক, শ্রেণি) হিসেবে বিবেচনা করেছিল এবং চিন্তাকে প্রতীকগুলোর উপর নিয়ম-ভিত্তিক রূপান্তর হিসেবে দেখেছিল।

উচ্চ-স্তরেরভাবে কল্পনা করলে: সংখ্যামূলক পদ্ধতি জিজ্ঞাসা করে “কতটা?” আর প্রতীকী পদ্ধতি চেষ্টা করে উত্তর দিতে “এটা কী?” এবং “আমাদের জানা থেকে কি অনুসরণ করে?”

কাজের জন্য লিস্প

একবার আপনি বিশ্বাস করবেন যে যুক্তি প্রোগ্রামযোগ্য করা যায়, তখন আপনাকে একটি ভাষা দরকার যা নিয়ম, যৌক্তিক বিবৃতি, এবং নেস্টেড সম্পর্কগুলোর মতো এক্সপ্রেশনগুলো আরামদায়কভাবে উপস্থাপন করতে পারে—এবং সেগুলো প্রক্রিয়াকরণ করতে পারে।

লিস্প সেই লক্ষ্য পূরণের জন্য নির্মিত। কাঁচা ধারণাগুলোকে কড়া, পূর্ব-নির্ধারিত ডাটা স্ট্রাকচারের মধ্যে জবরদস্তি করার বদলে, লিস্প কোড ও জ্ঞানকে একই ধরনের আকারে উপস্থাপন করতে স্বাভাবিক করে তুলেছিল। সেই পছন্দটি কেবল শৈল্পিক ছিল না—এটি “একটি চিন্তা বর্ণনা করা” এবং “একটি প্রক্রিয়া চালানো”—এই দুইয়ের মধ্যে একটি ব্যবহারিক সেতু, যা ম্যাকার্থি চাইতেন AI-কে অতিক্রম করাতে।

প্রতীকী চিন্তা, সাধারণ ভাষায়

ম্যাকার্থি ও প্রারম্ভিক AI গবেষকরা যখন “symbolic” বলতেন, তারা রহস্যময় গণিত নয় বোঝাতেন। একটি প্রতীক হলো সাধারণত একটি অর্থবহ লেবেল: একটি নাম যেমন customer, একটি শব্দ যেমন hungry, বা একটি ট্যাগ যেমন IF এবং THEN। প্রতীকগুলো গুরুত্বপূর্ণ কারণ তারা একটি প্রোগ্রামকে ধারণাগুলোর (শ্রেণি, সম্পর্ক, নিয়ম) সাথে কাজ করার সুযোগ দেয় কেবল কাঁচা সংখ্যার বদলে।

সহজভাবে: স্প্রেডশীট দুর্দান্ত যখন আপনার বিশ্ব কলাম ও হিসাবঘটিত। প্রতীকী সিস্টেমগুলো দুর্দান্ত যখন আপনার বিশ্ব নিয়ম, শ্রেণীবিভাগ, ব্যতিক্রম, এবং গঠন দিয়ে ভরা।

প্রতীক: উদ্দেশ্যসহ নাম

অনেক প্রোগ্রামে, 42 এবং "age" এর মধ্যে পার্থক্য কেবল ডেটা টাইপ নয়—এটা যে মানটি কি নির্দেশ করে। একটি প্রতীক আপনাকে এমন কিছু দেয় যা আপনি তুলনা, সংরক্ষণ, এবং মিলিয়ে নিতে পারেন বিহীন অর্থ হারানোর।

এটা ‘প্যারিস একটি শহর’ অথবা ‘ব্যাটারি কম হলে চার্জার খুঁজো’ এর মতো জিনিসগুলো উপস্থাপন করা সহজ করে তোলে।

লিস্ট: “অংশ নিয়ে গঠিত” এর জন্য সহজতম কাঠামো

কোন কিছু ব্যবহারিকভাবে প্রতীক দিয়ে করতে, আপনাকে কাঠামো দরকার। লিস্প খুবই সাদাসিধে একটি কাঠামো প্রচলিত করেছিল: লিস্ট। একটি লিস্ট হলো কেবল আইটেমগুলোর একটি ক্রমান্বয়িত দল, এবং সেই আইটেমগুলো নিজেও লিস্ট হতে পারে। এই এক ধারণা দিয়ে আপনি বাক্য, ফর্ম, এবং ট্রি-আকৃতির জ্ঞান উপস্থাপন করতে পারেন।

এখানে একটি ছোট ধারণাগত উদাহরণ (লিস্প-স্টাইল প্রদর্শন):

(sentence (subject robot) (verb needs) (object power))

এটি প্রায় ইংরেজির মতো পড়ে: একটি বাক্য যার subject, verb, এবং object আছে। এটি স্ট্রাকচার্ড হওয়ায়, একটি প্রোগ্রাম (subject robot) তুলে নিতে পারে বা (object power) কোথাও প্রতিস্থাপন করতে পারে।

স্ট্রাকচার থেকে যুক্তি: নিয়ম, পরিকল্পনা, সার্চ

একবার তথ্য প্রতীকী স্ট্রাকচারে গেলে, ক্লাসিক AI কাজগুলো অ্যাপ্রোচেবল হয়ে ওঠে:

• নিয়ম: যদি একটি প্যাটার্ন মিলে যায়, তখন নতুন কিছু নির্ধারণ কর (IF/THEN)।
• পরিকল্পনা: লক্ষ্য এবং ক্রিয়াগুলোকে তালিকার আকারে দেখাও, তারপর লক্ষ্য পৌঁছাতে ক্রিয়াগুলোর চেইন বানাও।
• সার্চ: সমাধান খুঁজতে বিভিন্ন প্রতীক সংমিশ্রণ (স্টেট) অন্বেষণ কর।

মূল পরিবর্তন হল যে প্রোগ্রাম কেবল হিসাব করছে না; এটি অর্থবহ জ্ঞানের টুকরোগুলো এমনভাবে অনলাইনে পরীক্ষা ও রূপান্তর করছে যেগুলোকে এটি ইন্সপেক্ট ও বদলাতে পারে।

কেন ভাষা ডিজাইনের পছন্দ দশক ধরে প্রতিধ্বনিত হয়

লিস্পের ডিজাইন সিদ্ধান্তগুলো একাডেমিয়ার মধ্যে আটকে থাকেনি। সেগুলো প্রভাব ফেলেছে কিভাবে মানুষ টুল তৈরি করেছে এবং কত দ্রুত তারা ধারণা পরীক্ষা করতে পেরেছে:

• অভিব্যক্তিমূলকতা: লিস্প কাঠামোগত জ্ঞান উপস্থাপন ও রূপান্তর করা সহজ করে।
• দ্রুত ইটারেশন: ইন্টারেক্টিভ ডেভেলপমেন্ট “চিন্তা” ও “চেষ্টা”র লুপ ছোট করে।
• প্রসার্যযোগ্যতা: ভাষা নতুন বিমূর্ততা গড়তে উৎসাহ দেয়, পুনরাবৃত্তি কমায়।

এই গুণগুলো এমন ইকোসিস্টেম তৈরি করে যেখানে পরীক্ষা-নিরীক্ষা সস্তা হয়, প্রোটোটাইপগুলো দ্রুত প্রোডাক্টে পরিণত হতে পারে, এবং দলগুলো পরিবর্তনশীল চাহিদার সাথে মানিয়ে নিতে পারে।

লিস্পের ডিজাইন লক্ষ্যসমূহ

লিস্প শুরু হয়েছিল একটি খুব ব্যবহারিক ডিজাইন সমস্যায়: কিভাবে এমন প্রোগ্রাম লিখবেন যা প্রতীকগুলোর সাথে কাজ করতে পারে ঠিক যেমন সংখ্যার সাথে কাজ করে?

ম্যাকার্থি “ভাল ক্যালকুলেটর” বানাতে চেষ্টা করছিলেন না। তিনি এমন একটি ভাষা চেয়েছিলেন যেখানে (is (parent Alice Bob)) এর মতো এক্সপ্রেশনটি (+ 2 3) এর মতো সহজে সংরক্ষণ, পরীক্ষা, বদলানো, এবং যুক্তি করা যায়।

প্রতীকী ডাটার জন্য নির্মিত ভাষা

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

নমনীয়তা অনলক করা সহজতা

আরও একটি লক্ষ্য ছিল ভাষার কোর ছোট ও কনসিস্টেন্ট রাখা। যখন একটি ভাষার অনেক “বিশেষ কেস” কম থাকে, আপনি কম সময়ে নিয়ম স্মরণ করবেন এবং বেশি সময় ধারণা গঠনে ব্যয় করবেন। লিস্প ছোট কোর বিল্ডিং ব্লকে ভর করেছিল যা বড় বিমূর্ততা গঠন করার সুবিধা দেয়।

ডেটার মতো গঠিত প্রোগ্রাম

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

এর ফলে আপনি:

• একটি প্রোগ্রাম জেনারেট করতে পারেন (স্ট্রাকচার্ড ডেটা হিসেবে)
• এটিকে মডিফাই করতে পারেন (যে কোনো ডেটার মতো)
• তারপর ফলাফল চালাতে পারেন

ভাষা ডিজাইনে সাংস্কৃতিক পরিবর্তন

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

এস-এক্সপ্রেশন: একটি সহজ কাঠামোর বড় ফলাফল

S-এক্সপ্রেশন (symbolic expressions-এর সংক্ষিপ্ত) লিস্পের স্বাক্ষর ধারণা: কোড ও ডেটা উভয়কেই নেস্টেড লিস্ট হিসেবে উপস্থাপনের একটি একক, নিয়মিত উপায়।

এক নজরে, একটি S-এক্সপ্রেশন কেবল প্যারেনথেসিসে থাকা আইটেম—কিছু আইটেম অ্যাটম (নাম এবং সংখ্যা), কিছু আইটেম আবার লিস্ট—এর সমন্বয়। “লিস্টের মধ্যে লিস্ট” নিয়মই গুরুত্বপূর্ণ।

সবকিছুর জন্য একটি আকৃতি

অভ্যস্ত কাঠামো থাকার কারণে, লিস্প প্রোগ্রামগুলো একই বিল্ডিং ব্লক দিয়ে গঠিত হয়। একটি ফাংশন কল, একটি কনফিগারেশনের কৌণিক অংশ, এবং প্রোগ্রামের অংশ—all এগুলোই এক তালিকা হিসেবে প্রকাশ করা যায়।

এই সঙ্গতি মুহূর্তেই লভ্য হয়:

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

আপনি যদি কখনো লিস্প না লেখেন তবুও এই ডিজাইন পাঠটি গুরুত্বপূর্ণ: যখন একটি সিস্টেম এক বা দুইটি পূর্বানুমানীয় ফর্ম থেকে গঠিত, আপনি কম এজ কেস নিয়ে সময় ব্যয় করেন এবং বেশি নির্মাণে ব্যয় করেন।

অনুভূতিগত সংযোজন

S-এক্সপ্রেশন ছোট, পাঠযোগ্য অংশগুলো বড় অংশে মিলিয়ে দেয়। আপনার প্রোগ্রাম “কেবল নেস্টেড লিস্ট” হলে, ধারণা মিলানো প্রায়শই একটি এক্সপ্রেশনকে অন্যটির মধ্যে নেস্ট করা অথবা পুনঃব্যবহারযোগ্য অংশগুলো থেকে লিস্ট গঠন করা।

এটি আপনাকে মডিউলার শৈলীর দিকে ঠেলে দেয়: ছোট অপারেশনগুলো লিখুন যা এক কাজ করে, তারপর সেগুলো একত্র করে বড় অভিপ্রায় প্রকাশ করুন।

ট্রেড-অফ: বন্ধনী

সত্যিই অসুবিধা হলো অপরিচিতি। অনেক নতুন ব্যবহারকারীর কাছে বন্ধনীগুলো অদ্ভুত লাগে।

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

রিকার্সন ও লিস্ট প্রসেসিং: মূল বিল্ডিং ব্লক

রিকার্সন বোঝার সহজ উপমা: একটি গুলজায়মান ঘর পরিষ্কার করা—আপনি সবকিছু একসাথে সমাধান করেন না। আপনি ছোট ছোট ‘ঘর’ বানান, প্রতিটি আইটেম নিয়ে তার জায়গায় রাখেন, এবং বাকি অংশে একই নিয়ম প্রয়োগ করেন। ধাপগুলো সহজ; শক্তি আসে বারবার প্রয়োগ করার মাধ্যমে যতক্ষণ না কিছুই বাকি থাকে।

লিস্প এই ধারণাটিতে ঝোঁক রাখে কারণ তার ডাটা প্রায়শই লিস্ট থেকে গঠিত: একটি লিস্টের “প্রথম জিনিস” ও “বাকী” থাকে। সেই আকৃতি রিকার্সিভ চিন্তার সাথে নিখুঁতভাবে মেলে।

একটি লিস্ট প্রক্রিয়াজাত করতে, আপনি প্রথম উপাদানটি হ্যান্ডেল করেন, তারপর একই লজিক বাকীর উপরে প্রয়োগ করেন। লিস্ট খালি হলে থামুন—এটাই সেই পরিষ্কার “কিছুই বাকি নেই” মুহূর্ত যা রিকার্সনকে রহস্যময় ন করে তোলে।

ধারণাগত ছোট উদাহরণ: একটি লিস্টের যোগফল

ধরুন আপনি সংখ্যার একটি লিস্টের মোট চান।

• যদি লিস্ট খালি, মোট = 0।
• অন্যথায়, মোট = প্রথম সংখ্যা + বাকীর মোট।

এটাই। সংজ্ঞাটি সাধারণ ইংরেজির মতো পড়ে, এবং প্রোগ্রামের গঠন ধারনাটিরই প্রতিফলন।

“ট্রি হাঁটা” চিন্তাভাবনা

প্রতীকী AI প্রায়শই এক্সপ্রেশনগুলোকে ট্রি-স্ট্রাকচার হিসেবে উপস্থাপন করে (একটি অপারেটর ও উপ-এক্সপ্রেশন)। রিকার্সন হল সেই ট্রি “হাঁটানোর” প্রাকৃতিক উপায়: বাম অংশ একইভাবে মূল্যায়ন করুন যেমন আপনি ডান অংশ মূল্যায়ন করেন, এবং চলতে থাকুন যতক্ষণ না একটি সহজ মানে পৌঁছান।

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

গারবেজ কালেকশন: একটি প্রোডাকটিভিটি ফিচার

শুরুতে প্রোগ্রামারদের মেমরি ম্যানেজ করতে হতো হাতে: অ্যলোকেট করা, কে ‘মালিক’ তা ট্র্যাক করা, এবং ঠিক সময়ে ফ্রি করা মনে রাখা। সেই কাজ কেবল ডেভেলপমেন্ট ধীর করে না—এটি এমন বাগ তৈরি করে যা পুনরুত্পাদন করা কঠিন এবং পাঠ্যযোগ্য: লিক যা ধীরে ধীরে পারফরম্যান্স কমায়, এবং ড্যাংলিং পয়েন্টার যা দীর্ঘ সময় পর প্রোগ্রাম ক্র্যাশ করে।

গারবেজ কালেকশন কি করে (সরল ভাষায়)

জন ম্যাকার্থি লিস্পের জন্য গারবেজ কালেকশন প্রবর্তন করেছিলেন যাতে প্রোগ্রামাররা অর্থ নিয়ে কাজ করতে পারেন, বই-নথিপত্র-রক্ষণাবেক্ষণ নিয়ে না।

উপরিল্লিখিতভাবে, গারবেজ কালেকশন স্বয়ংক্রিয়ভাবে সেই মেমরি খুঁজে বের করে যা রানিং প্রোগ্রাম থেকে আর পৌঁছনীয় নয়—মানে এমন মান যেটা আর কখনও ব্যবহার হবে না—এবং সেই স্পেস পুনঃপ্রাপ্ত করে।

আপনি যদি প্রতিটি অবজেক্ট সঠিকভাবে একবার ফ্রি করেছেন কি না তা না ভাবেন; পরিবর্তে জিজ্ঞাসা হবে “এই অবজেক্টটি কি এখনও অ্যাক্সেসযোগ্য?” যদি না হয়, এটি গারবেজ ধরা হবে।

কেন এটা প্রকৃতপক্ষে প্রোডাকটিভিটির ব্যাপার

প্রতীকী AI কাজে লিস্প প্রোগ্রামগুলো প্রায়ই অনেক স্বল্প-জীবী লিস্ট, ট্রি, এবং মধ্যবর্তী ফলাফল তৈরি করে। হাতে মেমরি ম্যানেজমেন্ট থাকলে পরীক্ষানিরীক্ষাকে ধৈর্যের লড়াই বানিয়ে দিত।

GC দিন-প্রতি-দিবসের অভিজ্ঞতা বদলে দেয়:

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

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

দীর্ঘমেয়াদি প্রভাব

ম্যাকার্থির পছন্দ লিস্পের ভিতরে আটকে থাকেনি। বহু পরবর্তী সিস্টেম GC গ্রহণ করেছে—কারণ ট্রেড-অফ প্রায়শই নিজেকে মিটায়: Java, C#, Python, JavaScript runtimes, এবং Go সবই বড়-স্কেলে ডেভেলপমেন্টকে নিরাপদ ও দ্রুত করতে GC-তে নির্ভর করে—এমনকি পারফরম্যান্সকে গুরুত্ব দিলেও।

ইভালুয়েশন ও ম্যাক্রো: ভাষাকে ভেতর থেকেই প্রসারিত করা

“ইভালুয়েশন” মানে কী (জার্গন ছাড়া)

লিস্পে, একটি এক্সপ্রেশন হলো একটি কোড টুকরা যা একটি কনসিস্টেন্ট আকারে লেখা (অften একটি লিস্ট)। ইভালুয়েশন কেবলমাত্র সেই এক্সপ্রেশনের মানে এবং ফলাফল কি হবে তা নির্ধারণের প্রক্রিয়া।

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

ছোট, কনসিস্টেন্ট ইভালুয়েটর কেন সুপারপাওয়ার

ম্যাকার্থির মূল চালটি কেবল নতুন সিনট্যাক্স উদ্ভাবন নয়—তিনি “মানে যন্ত্র” কে ছোট ও নিয়মিত রেখেছিলেন। ইভালুয়েটর যদি কয়েকটি পরিষ্কার নিয়ম থেকে গঠিত হয়, দুইটি ভাল জিনিস ঘটে:

• ভাষা বোঝা সহজ হয়, কারণ আপনি বহু বিশেষ কেস নিয়ে লড়াই করছেন না।
• আপনি ভাষা প্রসারিত করতে পারেন সিস্টেম পুরোপুরি রিরাইট না করেই, কারণ নতুন ফিচারগুলো বিদ্যমানগুলোর মাধ্যমে প্রকাশ করা যায়।

এই সঙ্গতি লিস্পকে প্রতীকী AI-এর জন্য একটি পরীক্ষাগার বানিয়েছে: গবেষকরা নতুন প্রতিনিধিত্ব ও কন্ট্রোল স্ট্রাকচার দ্রুত পরীক্ষা করতে পেরেছেন, কম্পাইলার টিমের উপর অপেক্ষা না করেই।

ম্যাক্রো: কোড প্যাটার্নের জন্য অটোমেশন

ম্যাক্রো হলো লিস্পের উপায় আপনাকে পুনরাবৃত্ত কোড আকার অটোমেট করতে দেয়—শুধু পুনরাবৃত্ত মান নয়। যেখানে একটি ফাংশন আপনার গণনা পুনরাবৃত্তি হওয়া থেকে রক্ষা করে, একটি ম্যাক্রো আপনার কোডের স্ট্রাকচার পুনরাবৃত্তি হওয়া থেকে রক্ষা করে—সাধারণ নিদর্শন যেমন “X কর, কিন্তু লগও কর,” বা “নিয়মের জন্য একটি মিনি-ভাষা সংজ্ঞায়িত কর।”

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

যদি আপনি জানতে চান এই মাইন্ডসেট কিভাবে দৈনন্দিন ডেভেলপমেন্টে প্রভাব ফেলেছে, দেখুন /blog/the-repl-and-fast-feedback-loops।

REPL এবং দ্রুত ফিডব্যাক লুপ

লিস্পের আকর্ষণের বড় অংশ ছিল কেবল ভাষা নয়—এটি কিভাবে আপনি এর সাথে কাজ করেন। লিস্প REPL-কে প্রসারিত করেছিল: Read–Eval–Print Loop। সাধারণ ভাষায়, এটি কম্পিউটারের সাথে কথোপকথনের মতো—আপনি একটি এক্সপ্রেশন টাইপ করেন, সিস্টেম তা চালায়, ফলাফল মুদ্রণ করে, এবং পরের ইনপুটের অপেক্ষা করে।

কাজের ধরণ সাধারণভাবে

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

এই রিদম অন্বেষণকে উৎসাহ দেয়, যা প্রারম্ভিক AI কাজের জন্য খুবই গুরুত্বপূর্ণ যেখানে প্রায়শই আপনি সঠিক পদ্ধতি আগে থেকেই জানেন না।

তীব্র ফিডব্যাক লুপ কেন ফলাফল বদলায়

দ্রুত ফিডব্যাক বড় বাজেটকে ছোট চেকে পরিণত করে। গবেষণার জন্য, এটি হাইপোথেসিস পরীক্ষা ও মধ্যবর্তী ফলাফল নিরীক্ষা করা সহজ করে তোলে।

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

এটাই আধুনিক vibe-coding টুলগুলোর আকর্ষণ: সেগুলো মূলত ফিডব্যাক-লুপ কম্প্রেশন। উদাহরণস্বরূপ, Koder.ai একটি চ্যাট ইন্টারফেস (Agent-ভিত্তিক আর্কিটেকচারের সাথে) ব্যবহার করে প্রোডাক্ট অভিপ্রায়কে দ্রুত কাজ করা ওয়েব, ব্যাকেন্ড, বা মোবাইল কোডে পরিণত করে—অften “try → adjust → try again” লুপকে একটি REPL-এর মতো অনুভব করায়।

আপনি ইতিমধ্যেই জানেন এমন আধুনিক সমতুল্য

REPL ধারণাটি আজ দেখতে পাই:

• Python/Node ইন্টারেক্টিভ শেল
• Jupyter ও অন্যান্য নোটবুক
• ব্রাউজার ডেভটুলস কনসোল
• ওয়েব অ্যাপে “লাইভ রিলোড” ও হট মডিউল রিপ্লেসমেন্ট

বিভিন্ন টুল; একই নীতি: চিন্তা ও দেখা মধ্যকার দূরত্ব কমাও।

কখন ইন্টারেক্টিভ ডেভেলপমেন্ট সবচেয়ে সহায়ক

টীমগুলো REPL-সদৃশ ওয়ার্কফ্লো থেকে সবচেয়ে বেশি লাভ পায় যখন তারা অস্পষ্ট চাহিদা অন্বেষণ করছে, ডেটা-ভারী ফিচার বানানো, API ডিজাইন করা, বা জটিল লজিক ডিবাগ করছে। কাজ যদি দ্রুত শেখার সাথে জড়িত হয়—ব্যবহারকারী, ডেটা, বা এজ কেস নিয়ে—তাহলে ইন্টারেক্টিভ ফিডব্যাক বিলাসিতা নয়; এটি একটি গুণগুণ।

কিভাবে লিস্প ধারণা প্রোগ্রামিং জুড়ে ছড়িয়েছে

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

প্রতিদিনের কোডে ফাংশনাল প্যাটার্ন

লিস্প যা ডিফল্ট হিসেবে নিয়েছিল—ফাংশনকে মান হিসেবে গ্রহণ, উচ্চ-অর্ডারের অপারেশন, ছোট অংশগুলোকে রচনা করে প্রোগ্রাম গঠনের প্রবণতা—এগুলো এখন ব্যাপকভাবে দেখা যায়। এমনকি লিস্পের মতো না দেখানো ভাষাগুলোও map/filter-শৈলীর রূপান্তর, ইমিউটেবল ডাটা অভ্যাস, এবং রিকার্সিভ চিন্তাভাবনা (ইটারেটর বা fold-এর মাধ্যমে) উৎসাহ দেয়।

কী পরিবর্তন হল মানসিকতা: ডাটা রূপান্তরগুলোকে পাইপলাইন হিসেবে বিবেচনা করুন, এবং আচরণকে এমন কিছু হিসেবে দেখুন যা আপনি পাস করে প্রবাহে রাখতে পারেন।

প্রতীকী উপস্থাপন: AI থেকে কম্পাইলার ও টুলিং

লিস্প প্রোগ্রামগুলোকে ডেটা হিসেবে উপস্থাপন করা সহজ করেছিল। সেই মানসিকতা আজ দেখা যায় কিভাবে আমরা AST (abstract syntax trees) দিয়ে কম্পাইলার, ফরম্যাটার, লিন্টার, এবং কোড জেনারেটর তৈরি করি। যখন আপনি AST নিয়ে কাজ করেছেন, আপনি “কোড-অ্যা-ডাটা” নামক একটি কাছের আত্মীয় নিয়ে কাজ করছেন, যদিও স্ট্রাকচারগুলো JSON অবজেক্ট, টাইপড নোড, বা বাইটকোড গ্রাফ হতে পারে।

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

DSL এবং পুনরায় লেখা ছাড়া প্রসার্যযোগ্যতা

আধুনিক লিস্প-ফ্যামিলি ভাষা (প্রস্তুত ভাবেই: সমসাময়িক লিস্প ও লিস্প-প্রেরিত টুল) ইন্টারনাল DSL কিভাবে ডিজাইন করা হয় তা প্রভাবিত করে—টেস্ট, ডিপ্লয়মেন্ট, ডাটা র‍্যাঙ্গলিং, বা UI-এর জন্য ছোট, ফোকাসড মিনি-ভাষা।

লিস্পের বাইরে, ম্যাক্রো সিস্টেম, মেটা-প্রোগ্রামিং লাইব্রেরি, এবং কোড জেনারেশন ফ্রেমওয়ার্ক একই ফলাফল লক্ষ্য করে: সমস্যা মেটাতে ভাষা প্রসারিত করা।

একটি বাস্তববাদী পাঠ: সিনট্যাক্স পছন্দ বদলায়, কিন্তু স্থায়ী ধারণাগুলো—প্রতীকী স্ট্রাকচার, রচনাযোগ্য ফাংশন, এবং প্রসার্যযোগ্যতা—দীর্ঘকাল ধরে উপকার দেয়।

লিস্প সম্পর্কে ট্রেড-অফ ও ভুল ধারণা

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

“অত্যধিক বন্ধনী” (পাঠযোগ্যতার প্রশ্ন)

নতুনদের কাছে লিস্পের ইউনিফর্ম সিনট্যাক্স প্রোগ্রামের “ভিতরের” মতো দেখতে পারে, না যে একটি পোলিশ-কাঠামোর পৃষ্ঠ। সেই অস্বস্তি বাস্তব, বিশেষত যদি আপনি এমন ভাষার অভ্যাসে থাকেন যেখানে সিনট্যাক্স ভিন্ন কনস্ট্রাক্ট আলাদা করে।

তবে ঐতিহাসিকভাবে, লিস্পের গঠনই মূল লক্ষ্য: কোড ও ডাটা একই আকার ভাগ করে, ফলে প্রোগ্রামগুলো রূপান্তর, জেনারেট ও বিশ্লেষণে সহজ হয়। ভাল এডিটর সাপোর্ট (ইন্ডেন্টেশন, স্ট্রাকচারাল নেভিগেশন) থাকলে লিস্প কোড প্রায়ই আকারের মাধ্যমে পড়া যায়, কেবল বন্ধনীর গণনা নয়।

পারফরম্যান্স: মিথ, ইতিহাস, এবং সাম্প্রতিক বাস্তবতা

একটি প্রচলিত স্টেরিওটাইপ হলো লিস্প ধীর। ইতিহাসগতভাবে কিছু ইমপ্লিমেন্টেশন নিম্ন-লেভেল ভাষার তুলনায় বেশি কষ্ট পেয়েছে, এবং ডায়নামিক ফিচারগুলো অতিরিক্ত ওভারহেড যোগ করতে পারে।

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

ইকোসিস্টেম ও হায়ারিং: ব্যবহারিক সীমাবদ্ধতা

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

একটি ভারসাম্যপূর্ণ উপসংহার

লিস্পকে সেকেলের ভিত্তিতে বিচার করার বদলে, এর মৌলিক ধারণাগুলো আলাদাভাবে মূল্যায়ন করুন: ইউনিফর্ম স্ট্রাকচার, ইন্টারেক্টিভ ডেভেলপমেন্ট, এবং ভাষার ভিতর থেকে প্রসার্যতা গড়ার ব্যবস্থা। আপনাকেও না-লিস্প-শিপ করলেও এই ধারণাগুলো যেকোনো ভাষায় কিভাবে কোড লিখবেন তা ধারালো করতে পারে।

ভাষা ডিজাইন ও দৈনন্দিন কোডিংয়ের জন্য ব্যবহারিক উপসংহার

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

চুরি করার মত 6টি পাঠ

1. চতুর পৃষ্ঠভূমির চেয়ে সরল কোর পছন্দ করুন। অল্প সংখ্যক অর্থোপযোগী বিল্ডিং ব্লক শেখার সহজ এবং ভাঙা কঠিন।

2. ডাটা শেপগুলো একরূপ রাখুন। বহু জিনিস একই প্রতিনিধিত্ব ভাগ করলে টুলিং সহজ হয়: প্রিন্টার, ডিবাগার, সিরিয়ালাইজার, ট্রান্সফর্মার এগুলো পুনঃব্যবহারযোগ্য হয়।

3. প্রোগ্রামকে ডাটা হিসেবে বিবেচনা করুন (এবং ডাটাকে প্রোগ্রাম হিসেবে) যেখানে সাহায্য করে। যদি আপনি স্ট্রাকচারগুলো ইন্সপেক্ট ও ট্রান্সফর্ম করতে পারেন, আপনি নিরাপদ রিফ্যাক্টর, মাইগ্রেশন, এবং কোড জেনারেটর বানাতে পারেন।

4. কোথাও বিরক্তিকর কাজ অটোমেট করুন। গারবেজ কালেকশন ক্লাসিক উদাহরণ, কিন্তু বিস্তৃত পয়েন্ট হলো: এমন অটোমেশন এতে বিনিয়োগ করুন যা পুরো শ্রেণির ভুল প্রতিরোধ করে।

5. ফিডব্যাক লুপের জন্য অপ্টিমাইজ করুন। ইন্টারেক্টিভ ইভালুয়েশন (REPL-স্টাইল) ছোট পরীক্ষা, দ্রুত যাচাই, এবং আচরণ সম্পর্কে উন্নত অন্তর্যাম দেয়।

6. প্রসার্যকে প্রথম-শ্রেণীর ডিজাইন লক্ষ্য করুন। লিস্প ম্যাক্রো একটি উত্তর; অন্য পরিবেশে এটি প্লাগইন, টেমপ্লেট, DSL, বা কম্পাইল-টাইম রূপান্তর হতে পারে।

একটি ছোট অনুশীলন (10 মিনিট)

লাইব্রেরি বা আর্কিটেকচার বেছে নেওয়ার আগে একটি বাস্তব ফিচার—ধরুন “ডিসকাউন্ট নিয়ম”—নিন এবং এটিকে:

• ট্রি আকারে আঁকুন
• তারপর সেই ট্রিটি নেস্টেড লিস্ট (বা JSON) হিসেবে লিখুন
• প্রশ্ন করুন: নোডগুলো কি, পাতাগুলো কি, এবং আপনি কোন রূপান্তরগুলো প্রয়োগ করতে চান?

এই অনুশীলন প্রায়শই দেখায় কোথায় ‘কোড-অ্যা-ডাটা’ প্যাটার্ন, রুল ইঞ্জিন, বা DSL-আধারিত কনফিগ সিস্টেম সুবিধা দেবে।

যে কোনো স্ট্যাকেই লিস্প ধারণা আনা

লিস্প না থাকলেও আপনি মাইন্ডসেটটি গ্রহণ করতে পারেন: AST-ধাঁচ উপস্থাপন তৈরি করুন, পুনরাবৃত্ত গ্লু-চালাকির জন্য কোড জেনারেশন ব্যবহার করুন, এবং ডাটা-ফার্স্ট পাইপলাইন (parse → transform → evaluate) স্ট্যান্ডার্ডাইজ করুন। অনেক টীম মধ্যবর্তী প্রতিনিধিত্বগুলো স্পষ্ট করে এই সুবিধা পায়।

যদি আপনি REPL নীতি পছন্দ করেন কিন্তু মেইনস্ট্রিম স্ট্যাকে প্রোডাক্ট ফিচার শিপ করছেন, আপনি টুলিং থেকে চিন্তাধারাটা ধার নিতে পারেন: টাইট ইটারেশন লুপ, স্ন্যাপশট/রোলব্যাক, এবং এক্সিকিউশনের আগে স্পষ্ট পরিকল্পনা। উদাহরণস্বরূপ, Koder.ai-তে প্ল্যানিং মোড, স্ন্যাপশট এবং রোলব্যাক আছে যাতে দ্রুত ইটারেশন নিরাপদ থাকে—এর অপারেশনাল echo লিস্পের “দ্রুত পরিবর্তন, কিন্তু নিয়ন্ত্রণে থাক” নীতির সাথে সম্পর্কিত।

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