জানুন কিভাবে গ্রেস হপার কম্পাইলার উদ্ভাবনে সাহায্য করেছিলেন, পাঠযোগ্য কোডের পক্ষে তৎপর ছিলেন, এবং COBOL-এর মতো ভাষাগুলোকে গতনির্ধারণ করে সফটওয়্যার কীভাবে লেখা ও রক্ষণাবেক্ষণ করা হয় তা বদলে দিয়েছিলেন।
অধিকাংশই আমরা কোড লিখি এমন প্রত্যাশায় যে তা পড়তে সুবিধা হবে, পুনঃব্যবহারযোগ্য হবে, এবং তুলনামূলকভাবে পোর্টেবল হবে। আমরা ভেরিয়েবল নাম দিই, লাইব্রেরি কল করি, এবং ধরে নেই আমাদের প্রোগ্রাম এমন মেশিনেই চলবে যেগুলো আমরা কখনোও দেখিনি। এই প্রত্যাশা দৈবক্রমে এসেছে না। এটা মানুষের ও কম্পিউটারের মধ্যকার কাজ ভাগ করার একটি বড় পরিবর্তনের ফল—এবং কম্পাইলারই সেই সেতু।
শুরুর যুগে প্রোগ্রামাররা আজকের মত "কোড টাইপিং" করতেন না। তারা এমন এক স্তরে কম্পিউটার পরিচালনা করতেন যা এত বিস্তারিত ও ভঙ্গুর ছিল যে প্রতিটি নির্দেশ এক ধরণের হাতে তৈরি যন্ত্রের মত ছিল। মূল প্রশ্ন হলঃ
কিভাবে প্রোগ্রামিং হার্ডওয়্যার-নির্দিষ্ট কৃতিত্ব থেকে একটি মানুষের-কেন্দ্রিক অনুশীলনে পরিণত হলো যা দল-বদ্ধভাবে দীর্ঘকাল ধরে বজায় রাখা যায়?
গ্রেস হপার সেই পরিবর্তনের কেন্দ্রীয় কারণ ছিলেন কারণ তিনি তার যুগের জন্য একটি উদ্ভাবনী ধারণা প্রচার করেছিলেন: কম্পিউটারকে অনুবাদ বেশি করতে দেব। একক মেশিনের জন্য সাজানো দীর্ঘ, ত্রুটিপূর্ণ সিকোয়েন্স লেখার বদলে, হপার প্রারম্ভিক কম্পাইলার কাজের পথপ্রদর্শক ছিলেন—সিস্টেমগুলো যা মানুষের পড়ার উপযোগী নির্দেশনাকে মেশিনের নিম্ন-স্তরের ধাপে রূপান্তর করতে পারে।
তার কাজ প্রমাণ করেছিল যে “অনুবাদ” একটি বিলাসিতা নয়—এটি উৎপাদনশীলতায় বিপ্লব। একবার আপনি উদ্দেশ্য স্পষ্টভাবে প্রকাশ করতে পারেন, আপনি করতে পারেন:
আমরা দেখাবো কিভাবে কম্পাইলার আগের দিনগুলোকে বদলে দিয়েছিল, একটি কম্পাইলার বাস্তবে কি করে (জার্গন ছাড়া), এবং কিভাবে হপার-এর A-0 কাজ ও COBOL-এর উত্থান সফটওয়্যারকে পাঠযোগ্য, স্ট্যান্ডার্ড ভাষার দিকে ঠেলে দিয়েছিল। পথে আপনি আধুনিক ডেভেলপমেন্টে যে বাস্তব প্রভাবগুলো আছে তা দেখবেন: পোর্টেবিলিটি, দলবদ্ধ কাজ, দীর্ঘমেয়াদি রক্ষণাবেক্ষণ, এবং প্রতিদিনের ধরে নেওয়া ভাবনা যে কোড মানুষের জন্য বুঝতে যোগ্য হওয়া উচিত—শুধু মেশিনের জন্য নয়।
আপনি যদি কখনো পরিষ্কার এরর মেসেজ, পোর্টেবল কোড, বা এমন একটি ভাষার সুবিধা ভোগ করে থাকেন যা নির্দেশের মত পড়ে, তাহলে আপনি সেই পৃথিবীতে আছেন যা হপার তৈরি করতে সাহায্য করেছিলেন।
গ্রেস হপার প্রোগ্রামিং “সহজ” করতে শুরু করেননি। তিনি শুরু করেছিলেন যেখানে প্রারম্ভিক কম্পিউটিং আপনাকে শুরু করতে বলেছে: মেশিনের সীমা থেকে। একজন গণিতবিদ হিসেবে প্রশিক্ষিত, তিনি দ্বিতীয় বিশ্বযুদ্ধের সময় যুক্তরাষ্ট্রি নেভিতে যোগ দিয়েছিলেন এবং Harvard Mark I-এ কাজ করতে নিয়োগপ্রাপ্ত হন, যা প্রথম বড়-স্কেল ইলেকট্রোমেকানিক্যাল কম্পিউটারগুলোর একটি ছিল।
Mark I কোনো ল্যাপটপ ছিল না যা ভুল হলে রিবুট করা যেত—এটি একটি রুম-আকারের সম্পদ ছিল যা একাধিক দলের দ্বারা ভাগ করা হতো, যত্নসহকারে সময়সূচি করা হতো, এবং ব্যয়বহুল ল্যাব সরঞ্জামের মত আচরণ করা হতো।
কম্পাইলার আগে প্রোগ্রামিং ছিল নিয়ন্ত্রণ প্যানেল ওয়্যারিং করার মত কাছাকাছি। নির্দেশগুলোকে হার্ডওয়্যারের চাহিদার সাথে ঠিক মিলতে হতো, প্রায়শই সংখ্যাসূচক কোড বা খুব নিম্ন-স্তরের অপারেশন হিসেবে। যদি আপনি মেশিনকে যোগ করতে, তুলনা করতে, বা মান স্থানান্তর করতে বলতেন, আপনি সেটা মেশিনের নিজস্ব শব্দভাণ্ডারে—ধাপ ধাপে—প্রকাশ করতেন।
ওই কাজ ছিলঃ
প্রারম্ভিক কম্পিউটারদিগুলো দুর্লভ ছিল, এবং “কম্পিউটার টাইম” একটি বাজেট আইটেম ছিল। আপনি অপ্রতিহতভাবে একটি প্রোগ্রাম দশ বার চালাতে পারতেন না দেখে কি হয়। দলগুলো সাবধানে প্রস্তুতি নিত, সবকিছু দ্বি-তদন্ত করত, তারপর রান করার পালার জন্য অপেক্ষা করত। অনবহিত ত্রুটিতে প্রতিটি মিনিট নষ্ট হওয়া মানে প্রকৃত সমস্যার সমাধান করতে সময় কম পাওয়া।
এই চাপ হপার-এর চিন্তায় প্রভাব ফেলে: যদি মানুষরা মেশিনের ভাষা বলার চেয়ে কাজটি সমাধান করতে বেশি শ্রম দিচ্ছে, তাহলে বোতলগলাটি কেবল হার্ডওয়্যার নয়—এটি পদ্ধতি।
কম্পাইলার-আগে প্রোগ্রামাররা কম্পিউটারের নিজস্ব “নেটিভ” ভাষায় কথা বলত।
মেশিন কোড হলো 0 ও 1-এর স্ট্রিম যা প্রসেসর সরাসরি এক্সিকিউট করতে পারে। প্রতিটি প্যাটার্নের মান আছে—যেমন “এই দুটি সংখ্যা যোগ কর”, “এই মানটি সরাও”, বা “অন্য ধাপে লাফ দাও।” এটা সঠিক—কিন্তু মানুষের জন্য পড়া, লেখা ও ডিবাগ করা ভয়ানকভাবে কষ্টসাধ্য।
অ্যাসেম্বলি ভাষা হলো মেশিন কোডকে টুকটাক নাম দেওয়া। কাঁচা বিট লেখার বদলে আপনি ছোট শব্দ লেখেন যেমন LOAD, ADD, বা JUMP, এবং মেমরি অ্যাড্রেস। একটি assembler সেই শব্দগুলোকে নির্দিষ্ট মেশিনের 0 ও 1-এ অনুবাদ করে।
অ্যাসেম্বলি মেশিন কোডের চেয়ে সহজ ছিল, কিন্তু এটাও মানুষকে হার্ডওয়্যারের মতো চিন্তা করতে বাধ্য করতো: রেজিস্টার, মেমরি লোকেশন ও সঠিক অপারেশন ক্রম।
প্রারম্ভিক কম্পিউটারগুলো বিনিমেয় ছিল না। ভিন্ন মেশিনগুলোর ইনস্ট্রাকশন সেট, মেমরি লেআউট, এমনকি সংখ্যার উপস্থাপনায়ও পার্থক্য ছিল। একটি প্রসেসরের জন্য লেখা প্রোগ্রাম প্রায়ই অন্যটিতে চলতই না।
সফটওয়্যার ছিল একটি "রেসিপি" নয় বরং একক লকের জন্য কাস্টম-করা চাবির মত।
কারণ প্রোগ্রামগুলো নিম্ন-স্তরের ধাপগুলোর উপর গড়ে উঠেছিল, একটি "সহজ" অনুরোধ—যেমন নতুন রিপোর্ট কলাম যোগ করা, ফাইল ফরম্যাট বদলানো, বা রাউন্ডিং কিভাবে হবে তা সামঞ্জস্য করা—পুরো প্রোগ্রামে ঢেউ তুলতে পারত।
একটি নতুন ফিচার অতিরিক্ত নির্দেশ চাইলে আপনাকে মেমরি ঠিকানাগুলো পুনর্বিন্যাস করতে হতে পারে, লাফ-টার্গেট আপডেট করতে হতে পারে, এবং প্রতিটি স্থানে পুনরায় পরীক্ষা করতে হতে পারে যে পুরনো লেআউট ধরে আছে কিনা। কম্পিউটারের সময় মূল্যবান ছিল, কিন্তু মানবিক সময়ই প্রকৃত বোতলগলি ছিল—এবং সেটাই এমন অনেক বিবরণে পাততে লাগছিল যা ব্যবসায়িক সমস্যার সাথে তেমন সম্পর্ক রাখে না।
প্রারম্ভিক কম্পিউটার শক্তিশালী ছিল, কিন্তু বেদনাদায়কভাবে literal। এগুলো কেবল তাদের হার্ডওয়্যার বুঝে এমন ছোট অপারেশন সেটেই কাজ করত। ফলত প্রোগ্রামিং প্রায়ই প্রতিটি ধাপে মেশিনকে সরাসরি বলা-মতোই দেখাত।
একটি কম্পাইলার কাজের প্যাটার্ন উল্টে দেয়: মানুষেরা যদি “মেশিন” বলার বদলে মানুষের পঠন-যোগ্য ফর্মে নির্দেশ লেখে, সফটওয়্যার তখন সেই অনুবাদ নিজেই করতে পারে। বাস্তবভাবে, এটি এমন একটি প্রোগ্রাম যা প্রোগ্রাম তৈরিতে সাহায্য করে।
কম্পাইল করা হলো মানুষের পড়া ও লেখা কোডকে সেই মেশিন নির্দেশে পরিণত করা যা কম্পিউটার চালাতে পারে। আপনি এটাকে একটি রেসিপিকে নির্দিষ্ট বাটন-চেপে রান করা কিচেন রোবটের জন্য রূপান্তর করা হিসেবে ভাবতে পারেন।
উচ্চ-স্তরে, একটি কম্পাইলার সাধারণত:
ম্যাজিকটা এটা নয় যে কম্পিউটার হঠাৎ "ইংরেজি" বুঝতে পারে। ম্যাজিকটা হলো কম্পাইলার দ্রুত ও ধারাবাহিকভাবে যেই ক্লান্তিকর, ত্রুটিপূর্ণ কাজ করতে পারে।
মানুষ প্রায়শই কম্পাইলার ও ইন্টারপ্রেটার মিশিয়ে ফেলে কারণ দুটিই মানুষ-বান্ধব কোড চালাতে সাহায্য করে।
সহজ আলাদা করার উপায়:
বহু আধুনিক সিস্টেম দুটোই মিলিয়ে ব্যবহার করে, কিন্তু হপারের গল্পে মূল বিষয় হলো: কম্পাইলেশন লেখাকে হার্ডওয়্যার-বিস্তারিত থেকে অন্তত এক ধাপ উঁচুতে নিয়ে আসে, যেখানে কোডের লক্ষ্যও মানুষের জন্য পরিষ্কার করে প্রকাশ করা যায়।
গ্রেস হপার-এর A-0 সিস্টেম (প্রায় 1952 সাল হিসেবে ইংগিত করা হয়) প্রাথমিক "কম্পাইলার-সদৃশ" টুলগুলোর মধ্যে একটি—যদিও এটা আধুনিক কম্পাইলারের মতো সম্পূর্ণ মানুষের পড়ার ভাষাকে মেশিন-কোডে অনুবাদ করত না।
প্রতিটি ইনস্ট্রাকশন নিজে লিখার বদলে, একজন প্রোগ্রামার এমন একটি প্রোগ্রাম লিখতে পারত যা পূর্বনির্মিত রুটিনগুলোকে একটি আইডেন্টিফায়ার দিয়ে রেফার করে। A-0 তখন:
তাই প্রোগ্রামার এখনও কম্পিউটারকে "ইংরেজি-সদৃশ" নির্দেশ বোঝাতে বলছিলেন না। তিনি কেবল অনুরোধ করছিলেন যে পুনরাবৃত্তিমূলক, ত্রুটিপূর্ণ অ্যাসেম্বলি কাজটি অটোমেট করা হোক: পরিচিত বিল্ডিং ব্লকগুলো নির্বাচন ও সংযুক্ত করা।
A-0 একটি শক্তিশালী ধারণার উপর নির্ভর করেছিল: সাবরুটিন। যদি আপনার কাছে ইনপুট/আউটপুট, গাণিতিক কাজ, বা ডেটা স্থানান্তরের জন্য ইতিমধ্যেই টেস্ট করা একটি রুটিন থাকে, আপনাকে প্রতিবারই সেটা আবার লিখতে হবে না।
এটি দৈনন্দিন কাজকে দুটি বড় দিক থেকে বদলে দেয়ঃ
A-0-এর গভীর প্রভাব কেবল প্রযুক্তিগত ছিল না—এটি সাংস্কৃতিকও ছিল। এটি ইঙ্গিত করেছিল যে প্রোগ্রামিং হতে পারে এমন একটি কাজ যেখানে আপনি বিশ্বাসযোগ্য উপাদানগুলোর সমন্বয় বর্ণনা করবেন এবং টুলগুলো যান্ত্রিক কাজটি করবে।
এই মনোভাব—লাইব্রেরি reuse, মানক রুটিন, অটোমেটেড অনুবাদ—কম্পাইলার, মানক ভাষা, এবং আধুনিক সফটওয়্যার প্র্যাকটিসের ভিত্তি হয়ে ওঠে।
প্রারম্ভিক প্রোগ্রামাররা কেবল মেশিনের সঙ্গে লড়াই করেননি—তারা একে অপরের ধারণার সঙ্গেও লড়াই করছিলেন যে "সত্যিকারের" প্রোগ্রামিং কেমন হওয়া উচিত। অনেক ইঞ্জিনিয়ারের কাছে গুরুতর কাজ মানে হার্ডওয়্যারের মতো ঘন, সংখ্যাসূচক, এবং স্পষ্ট নির্দেশ; যে কোনো ইংরেজি-সদৃশ কিছু অনায়াসে অনিশ্চিত মনে হতো।
গ্রেস হপার যুক্তি দিলেন যে কম্পিউটার মানুষদের সেবা করা উচিত—not উল্টো। পাঠযোগ্য নোটেশনের জন্য তার চাপ—বাণিজ্যিক টার্মের কাছাকাছি বিবৃতিগুলো—প্রতিবাদ ডেকেছিল কারণ এটি সেই মূল বিশ্বাসকে চ্যালেঞ্জ করেছিল: দক্ষতায় মানবকে মেশিন-আকৃতির ধাপে ভাবতে বাধ্য করা দরকার।
সন্দেহবাদীরা ভাবতেন যে ইংরেজি-সদৃশ কমান্ডগুলো অস্পষ্ট হবে, গুরুত্বপূর্ণ বিবরণ লুকিয়ে রাখবে, এবং অলস চিন্তার পথপ্রদর্শন করবে। হপার-এর প্রতিদ্বন্দ্বী বক্তব্য ছিল ব্যবহারিক: প্রোগ্রামিং সময়ের বড় অংশ টাইপিং-এ নয়—পরবর্তী সময়ে বুঝতে কেমন লাগে তা বোঝাতে যায়।
পাঠযোগ্য কোড প্রোগ্রামকে "সহজ" বানানোর বিষয়ে নয়; এটি তাকে টিকে থাকার যোগ্য করে তোলে। যখন কোড উদ্দেশ্য প্রকাশ করে, দলগুলো দ্রুত পরিবর্তন পর্যালোচনা করতে পারে, নতুন সদস্যদের অনবোর্ড করা সহজ হয়, এবং প্রত্যেকটি সিদ্ধান্ত উল্টে দেখা ছাড়াই সমস্যাগুলো নির্ণয় করা যায়।
এটি বছরের পর বছর গুরুত্বপূর্ণ হয়ে ওঠে। সফটওয়্যার চাকরির ভূমিকা, বিভাগ, এবং এমনকি মূল উদ্দেশ্যকে ছাড়িয়ে বাঁচে। মানুষের উপযোগী গঠন ও নামকরণ পরিবর্তনের খরচ কমায়, যা সফটওয়ারের সবচেয়ে বড় খরচ হতে পারে।
হপার-এর পদ্ধতিটির সীমাও ছিল। প্রারম্ভিক কম্পাইলার ও টুলিং অপরিপক্ক ছিল, এবং উচ্চ-স্তরের কোড হাতে-তৈরি অ্যাসেম্বলি-র তুলনায় ধীর বা বড় আকারের প্রোগ্রাম তৈরি করতে পারত। ডিবাগিংও ঘন হতে পারে: এররগুলি সোর্স টেক্সটের পরিবর্তে কম্পাইল্ড আউটপুটে ঘটতে পারে।
তবুও, দীর্ঘমেয়াদি লাভ স্পষ্ট ছিল: পাঠযোগ্য সোর্স কোড বড় সিস্টেমগুলোকে বেশি মানুষের দ্বারা বানানো ও বজায় রাখা সম্ভব করে—এবং প্রথম সংস্করণ শিপ হওয়ার অনেক বছর পরে পর্যন্ত সেগুলো কাজ করে রাখা যায়।
COBOL (Common Business-Oriented Language) একটি সহজ লক্ষ্য নিয়ে তৈরি করা হয়েছিল: প্রোগ্রামগুলোকে ব্যবসায়ীদের জন্য পড়বার মতো করা, কেবল মেশিন-ওয়্যারিং জানে এমন লোকদের জন্য নয়। গ্রেস হপার এই ধারণাটি দৃঢ়ভাবে সমর্থন করতেন—যদি কোড বছর ধরে বাস করবে, দল বদলবে, এবং কর্মী পরিবর্তন সইবে, তবে তা বুঝবার যোগ্য হতে হবে।
COBOL ব্যবসায়িক ডেটা প্রসেসিং—পে-রোল, ইনস্টক, বিলিং—এর জন্য ডিজাইন করা হয়েছিল এবং ডেটার "আকৃতি" গাণিতিক কাজের চেয়েও জরুরি ছিল। তাই COBOL রেকর্ড, ফিল্ড, এবং যা প্রোগ্রাম করছে তার স্পষ্ট বর্ণনার ওপর জোর দিয়েছিল।
বৃহৎ অংশটা ছিল স্পষ্টতা। COBOL ইংরেজি-সদৃশ কাঠামো গ্রহণ করেছিল যাতে কেউ প্রোগ্রামটি আংশিকভাবে স্কিম করতে পারলে উদ্দেশ্য বুঝতে পারে। এটি প্রোগ্রামিংকে "সহজ" করা নয়—বরং এটি পাঠযোগ্য ও রক্ষণাবেক্ষণযোগ্য করা—খুব গুরুত্বপূর্ণ যেখানে ব্যবসায়িক সিস্টেমে ভুলের মূল্য অনেক বড় হতে পারে।
COBOL-এর প্রকৃত সাফল্য কেবল সিন্ট্যাক্স নয়। এটি স্ট্যান্ডার্ডাইজেশনের দিকে অগ্রসর হয়েছিল।
একটি ভেন্ডারের ব্যক্তিগত ভাষা বা মেশিনের সাথে আবদ্ধ না থেকে, COBOL কমিটি ও আনুষ্ঠানিক স্পেসিফিকেশন দ্বারা গঠিত হয়েছিল। প্রক্রিয়াটি ধীর ও রাজনৈতিক ছিল, কিন্তু একাধিক ভেন্ডার একই লক্ষ্য বাস্তবায়ন করলে একটি ভাগ করা লক্ষ্যমাত্রা তৈরি হয়।
এটি বাস্তবে মানে ছিল যে প্রতিষ্ঠানগুলি COBOL-এ বিনিয়োগ করতে বেশি আত্মবিশ্বাসী হতে পারত: প্রশিক্ষণ সামগ্রী দীর্ঘদিন টিকে থাকে, নিয়োগ সহজ হয়, এবং হার্ডওয়্যার পরিবর্তনে কোড টিকে থাকার সম্ভাবনা বাড়ে।
স্ট্যান্ডার্ডাইজেশন প্রত্যাশাকে বদলে দেয়। ভাষাগুলো আর শুধু যে টুল আপনার মেশিনের সঙ্গে আসে তা নয়—এগুলো মানব-পাঠ্য নীতির উপর ভিত্তি করে গণসাক্ষরিত চুক্তি হয়ে ওঠে: কিভাবে মানুষ নির্দেশ লিখবে এবং কিভাবে কম্পাইলার সেগুলো অনুবাদ করবে।
COBOL-এর শক্তি বোঝানো সহজ: এটি স্পষ্ট, তার ডেটা স্ট্রাকচার কেন্দ্রীয়, এবং এটি দীর্ঘমেয়াদি ব্যবসায়িক সিস্টেমকে সমর্থন করে। ঐ জীবনকাল দুর্ঘটনা নয়; এটি এমন নকশার ফল যেখানে স্পষ্টতা ও স্থিতিশীলতাকে অগ্রাধিকার দেওয়া হয়েছে।
সমালোচনাও আছে। COBOL verbose হতে পারে, এবং এর পাঠযোগ্যতা আধুনিক ভাষার তুলনায় কঠোর মনে হতে পারে। কিন্তু verbosity প্রায়শই উদ্দেশ্যই ছিল: কোড তার কাজ দেখায়, যা অডিটিং, রক্ষণাবেক্ষণ এবং হ্যান্ডঅফে সহায়ক।
COBOL একটি মোড়খানা চিহ্ন করে—যেখানে প্রোগ্রামিং ভাষাগুলো আর ব্যক্তিগত শর্টকাট নয়, বরং মান-চালিত অবকাঠামো: ভাগ করা, শেখার যোগ্য, এবং টিকে থাকার মতো করে ডিজাইন করা।
প্রারম্ভিক প্রোগ্রামগুলো প্রায়ই একটি নির্দিষ্ট মেশিনের সাথে বিবাহবন্ধনে আবদ্ধ ছিল। যদি আপনি কম্পিউটার বদলাতেন, আপনি শুধু ফাইল স্থানান্তর করতেন না—প্রায়ই আপনাকে প্রোগ্রামটি আবার লিখতেই হত, কারণ ইনস্ট্রাকশন ও কনভেনশনগুলো ভিন্ন ছিল। এটি সফটওয়্যারকে নাজুক ও ব্যয়বহুল করে তুলেছিল, এবং নতুন হার্ডওয়্যার গ্রহণ ধীর করে দিয়েছিল।
কম্পাইলার একটি শক্তিশালী বিভাজন পরিচয় করায়: আপনি উচ্চ-স্তরের ভাষায় আপনার প্রোগ্রাম লিখেন, আর কম্পাইলার সেটাকে নির্দিষ্ট কম্পিউটারের নেটিভ নির্দেশে অনুবাদ করে।
এটাই মানুষ যখন পোর্টেবিলিটি বলবে: একই সোর্স কোড বিভিন্ন মেশিনের জন্য তৈরি করা যায়—যতক্ষণ প্রতিটি টার্গেটের জন্য একটি উপযুক্ত কম্পাইলার আছে (এবং আপনি মেশিন-নির্দিষ্ট অনুমান এড়ান)। এক একে পে-রোল সিস্টেম প্রতিটি নতুন কম্পিউটারের জন্য আবার লিখতে হতো না; প্রতিষ্ঠাগুলো লজিকটা রেখে কেবল পুনঃকম্পাইল করতে পারত।
এই পরিবর্তন হার্ডওয়্যার উন্নতির অর্থনীতিকে বদলে দেয়। নির্মাতারা দ্রুততর বা অধিক সক্ষম মেশিন ছেড়ে দিতে পারে, এবং গ্রাহকরা তাদের বছরের পুরনো সফটওয়্যার বিনিয়োগ নষ্ট করতে বাধ্য নয়।
কম্পাইলার এক ধরনের "অ্যাডাপ্টার লেয়ার" হয়ে ওঠে স্থিতিশীল ব্যবসায়িক চাহিদা ও দ্রুত পরিবর্তিত টেকনোলজির মধ্যখানে। আপনি প্রসেসর, মেমোরি মডেল, এবং পেরিফেরালগুলো আপগ্রেড করতে পারেন যখন অ্যাপ্লিকেশনের উদ্দেশ্য অক্ষত থাকে। কিছু পরিবর্তন এখনও আপডেট দাবি করে—বিশেষ করে ইনপুট/আউটপুট-সংক্রান্ত—কিন্তু মূল ধারণা আর এক নির্দিষ্ট opcode সেটে আবদ্ধ নয়।
যখন ভাষাটি স্ট্যান্ডার্ডাইজড হয়, পোর্টেবিলিটি আরও উন্নত হয়। নিয়মগুলো ভাগ করলে একটি কম্পাইলারের জন্য লেখা কোড আরেকটিতে কম সম্ভাব্য সমস্যা ছাড়াই কম্পাইল হয়—ভেন্ডার লক-ইন কমে এবং সফটওয়্যার শেয়ার করা সহজ হয়।
এ কলির উত্তরস্বর আজও আমাদের চারপাশে আছে:
গ্রেস হপার-এর মানুষ-বান্ধব, বিস্তৃত ব্যবহারযোগ্য প্রোগ্রামিং-এর ধাক্কা কেবল সুবিধার জন্য নয়; এটি সফটওয়্যারকে এমন একটি পোর্টেবল সম্পদ করে তুলেছে যা হার্ডওয়্যার প্রজন্ম পেরিয়েও টিকে থাকতে পারে।
কম্পাইলার কেবল প্রোগ্রামিং দ্রুত করেনি—এটি সফটওয়্যার টিমের সংগঠনকেই রূপান্তরিত করেছে। যখন কোড ব্যবসায়িক নিয়মের কাছাকাছি উচ্চ-স্তরে লেখা যায়, ভিন্ন লোকেরা আরও কার্যকরভাবে অবদান রাখতে পারে।
শুরুতেই প্রজেক্টগুলো প্রায়ই বিশ্লেষক (কারা সিস্টেম কি করবে নির্ধারণ করে), প্রোগ্রামার (যারা সেটাকে কোডে অনুবাদ করে), এবং অপারেটর (রান টাইমে কাজ চালায় ও মেশিন টাইম পরিচালনা করে) এর মতো আলাদা কাজ ভাগ করত। কম্পাইলারের সঙ্গে, বিশ্লেষকরা বেশি গঠনমূলকভাবে ও ধারাবাহিকভাবে কাজ বর্ণনা করতে পারে, আর প্রোগ্রামাররা কম সময় কাটায় "হাতে-হাতে" ইনস্ট্রাকশন গঠন করে এবং বেশি সময় ডিজাইন নিয়ে ভাবতে পারে—যা সেই ওয়ার্কফ্লো: Requirements → readable source code → compiled program তৈরিতে পরিষ্কার হ্যান্ডঅফ তৈরি করে।
এর ফলে বড় প্রজেক্টগুলো কয়েকজন বিশেষজ্ঞের ওপর কম নির্ভরশীল হয় যাঁরা একটি নির্দিষ্ট মেশিনের কূটকৌশল জানতেন।
সফটওয়্যার যখন বছর ধরে বাস করতে শুরু করে—না শুধু সপ্তাহ—তখন রক্ষণাবেক্ষণ প্রধান খরচ হয়ে ওঠে। ফিক্স, আপডেট, ছোট নীতিগত পরিবর্তনগুলো যোগ করলে খরচ বাড়ে। পাঠযোগ্য সোর্স কোড তা টেকসই করে তোলে: নতুন কেউ সিস্টেমের উদ্দেশ্য বুঝতে পারে হাজার হাজার নিম্ন-স্তরের ধাপ উল্টে না করে।
কম্পাইলারগুলি এই কাজটিকে উৎসাহ দেয় কুশলতা দ্বারা: নামকৃত ভেরিয়েবল, পুনঃব্যবহারযোগ্য রুটিন, এবং পরিষ্কার কন্ট্রোল ফ্লো। যখন কোড নিজে নিজে ব্যাখ্যা করে, রক্ষণাবেক্ষণ আর পুরাতন নরথের খনন কাজ থাকে না।
ইউজার-বান্ধব abstraction গুলো টেস্টিং ও ডিবাগিংকেও উন্নত করে। একটি একা ভুল মেশিন ইন্সট্রাকশনে শিকার হওয়ার বদলে দলগুলো ফিচার ভিত্তিক ভাবে চিন্তা করতে পারে ("ছাড় ফেরতের গণনা ভুল") এবং একটি মডিউল বা ফাংশনে সমস্যা আলাদা করে নির্ধারণ করতে পারে।
প্রারম্ভিক দিনে কম্পাইলার যখন cryptic error দিত, তখনও এটি একটি মূল্যবান শৃঙ্খলা চাপত: সোর্স কোডকে সংগঠিত রাখুন, ধাপে ধাপে আচরণ যাচাই করুন, এবং যেখানে অর্থ প্রকাশিত হয় সেখানে পরিবর্তন করুন—নির্দিষ্ট বীটগুলোতে নয়।
কম্পাইলার মানব-বন্ধু নির্দেশকে মেশিনে অনুবাদ করে। এই পরিবর্তন কোড লেখা দ্রুত ও শেয়ারযোগ্য করেছে—কিন্তু এটি কিছু মিথও তৈরি করেছে যা আজও কথোপকথনে উঠে আসে।
একটি কম্পাইলার মূলত দেখে যে আপনার কোড ভাষার নিয়ম মেনে চলে এবং অনুবাদযোগ্য কি না। যদি আপনার লজিক ভুল থাকে, কম্পাইলার প্রায়শই একটি বৈধ্য প্রোগ্রাম উৎপন্ন করবে যা ভুল কাজ করবে।
উদাহরণস্বরূপ, একটি পে-রোল ক্যালকুলেশন ঠিক মত কম্পাইল হতে পারে কিন্তু ভুল সূত্রের কারণে সঠিক পরিশোধ না করতে পারে—কারণ একটি ভুল ফর্মুলা, অনুপস্থিত এজ-কেস, বা টাইম-জোন অনুমান থাকতে পারে।
উচ্চ-স্তরের ভাষা কিছু ধরনের ত্রুটি—যেমন CPU ইনস্ট্রাকশন গুলোর ভুল ব্যবহার বা মেমরি ম্যানেজমেন্টের ছোট ভুল—কমিয়ে দেয়, কিন্তু বাগ দূর করে না। আপনি এখনও করতে পারেন:
পাঠযোগ্য কোড বড় জয়, কিন্তু পাঠযোগ্যতা মানে সঠিকতা নয়।
কোড সুন্দর নামকরণ ও ফর্ম্যাটিং সহ থাকতে পারে, তবু অনিরাপদ (ব্যবহারকারীর ইনপুট বিশ্বাস করে), ধীর (উদাহরণস্বরূপ লুপে বারবার DB কল), বা ভঙ্গুর (অদৃশ্য নির্ভরশীলতা) হতে পারে।
ভাল ফ্রেমিং হলো: পাঠযোগ্য কোড সমস্যাগুলো খুঁজে পেতে ও মেরামত করতে সহজ করে দেয়, কিন্তু নিজেরাই সেগুলো মুছে দেয় না।
কম্পাইলার টুল মাত্র—বেবিসিটার নয়। নির্ভরযোগ্যতা আসে মানুষের কাজ করার ধরন থেকে:
গ্রেস হপার যা চাপ দিয়েছিলেন—মানুষ বোঝার যোগ্য কোড—তার সর্বোত্তম সম্পাদনা হলো এই পাঠযোগ্যতাকে শৃঙ্খলাবদ্ধ প্র্যাকটিসের সঙ্গে জোড়া দিয়ে "অতিসামান্য" না হয়ে যাওয়া।
হপার-এর মূল অনুমান সহজ ছিল: যদি আমরা কাজকে মানুষের বোঝার ভাষায় বর্ণনা করতে পারি, মেশিনগুলো অনুবাদ সামলাবে। সেই ধারণা প্রায় প্রতিটি আধুনিক প্রোগ্রামিং অভিজ্ঞতার মধ্যে তৈরি—আপনি পাইটন বা জাভাস্ক্রিপ্ট লিখুন বা বড় ইন্ডাস্ট্রিয়াল কম্পাইলার টুলচেইন দিয়ে অ্যাপ শিপ করুন।
আজকাল, একটি “কম্পাইলার” সাধারণত একক প্রোগ্রাম নয়। এটা একটি পাইপলাইন: আপনার কোড পার্স করা, চেক করা, পরিবর্তন করা, অপ্টিমাইজ করা, এবং runnable কিছু (মেশিন কোড, bytecode, বা একটি optimized bundle) তৈরি করা। আপনি Go, Rust, Swift, বা C# লিখুন, আপনি সেই একই প্রতিশ্রুতির সুবিধা পাচ্ছেন যা হপার চাপ দিয়েছিলেন: মানুষের পেশাজীবনিক কাজ থেকে ক্লান্তিকর অনুবাদ সরিয়ে নিন এবং উদ্দেশ্য পরিষ্কার রাখুন।
এটি কেনইনা যে আজকের উন্নত প্ল্যাটফর্মগুলো আরও উচ্চ-স্তরের ইন্টারফেসের দিকে যাচ্ছে যা সত্যিকারে deployable সিস্টেম তৈরি করে। উদাহরণস্বরূপ, প্ল্যাটফর্মগুলোর মধ্যে Koder.ai-এর মত সিস্টেমে আপনি একটি চ্যাট ইন্টারফেসে যা চান তা বর্ণনা করেন, এবং একটি এজেন্ট-ভিত্তিক ওয়ার্কফ্লো অ্যাপ তৈরি ও পরিমার্জন করতে সাহায্য করে—এবং তবুও exportable সোর্স কোড তৈরি করে। খুব হপার-সদৃশভাবে লক্ষ্য একই: ক্লান্তিকর অনুবাদ থেকে উদ্দ্যেশ্যের দিকে শ্রম সরানো, পর্যালোচনাযোগ্য আউটপুট রাখা, এবং দ্রুত iteration।
আধুনিক কম্পাইলার শুধু অনুবাদ করে না—তারা শিক্ষা দেয় ও রক্ষা করে।
যখন আপনি একটি এরর মেসেজ পান যা সঠিক লাইনের দিকে নির্দেশ করে এবং সমাধানের পরামর্শ দেয়, সেটি সেই ধাঁচের উত্তরাধিকার।
অপ্টিমাইজেশন আরেকটি নীরব বিজয়: কম্পাইলার কোডকে দ্রুত বা ছোট করে তুলতে পারে আপনার প্রতিটি ইনস্ট্রাকশন হাতে-হাত না টিউন করেও।
স্ট্যাটিক বিশ্লেষণ (কম্পাইলারের ভিতরে বা পাশের টুল হিসেবে) সমস্যা আগে খুঁজে পায়—টাইপ mismatch, অপব্যবহৃত কোড, সম্ভাব্য null ত্রুটি—ক্রেতার কাছে পৌঁছানোর আগে।
এসব সব মিলে দ্রুত ডেভেলপমেন্ট সাইকেল তৈরি করে: আপনি পরিষ্কার কোড লিখেন, টুলগুলো ত্রুটি আগেই দেখায়, এবং বিল্ডগুলো বিভিন্ন পরিবেশে নির্ভরযোগ্য আউটপুট দেয়। আপনি হয়ত কখনো "কম্পাইলার" শব্দটা বলেন না, তবুও প্রতিটি বার আপনার IDE একটি বাগ আন্ডারলাইন করলে, আপনার CI build নির্দিষ্ট ডায়াগনস্টিক দেয়, বা টুলচেইন আপডেটের পর আপনার রিলিজ দ্রুত চলে—সেইটাই হপার-এর ভিশন প্রতিদিনের অনুশীলনে ফিরে আসে।
গ্রেস হপার-এর কম্পাইলার কাজ কেবল কম্পিউটারকে সহজে প্রোগ্রাম করা শেখায়নি—এটি বদলে দিয়েছে সফটওয়্যার কী হতে পারে। কম্পাইলারের আগে প্রতিটি উন্নতি ধাপে ধাপে হস্তনির্মিত, নিম্ন-স্তরের প্রচেষ্টার উপর নির্ভর করত। কম্পাইলারের পর মানুষের সময় বড় অংশ ধারণা, নিয়ম, ও আচরণে যেতে পারল, একে একে প্রতিটি নির্দেশ অনুবাদ করার চেয়ে।
দুটি পরিবর্তন সবচেয়ে বড় প্রভাব ফেলেছে:
এই সুবিধাগুলো একে অপরকে শক্তিশালী করে। যখন কোড পড়তে সহজ, তা উন্নত করা সহজ হয়। যখন অনুবাদ অটোমেটেড, দলগুলো রিফ্যাক্টর ও অভিযোজিত হতে পারে। এ কারণেই কম্পাইলার একটি একবারের ট্রিক নয়—এগুলো আধুনিক ভাষা, টুলিং, এবং সহযোগিতার ভিত্তি হয়ে উঠেছে।
একটি কম্পাইলার "প্রোগ্রামিং সহজ করে" বলতে কম—এটি প্রোগ্রামিংকে স্কেলেবল করে। এটি একজন ব্যক্তির উদ্দেশ্যকে দীর্ঘ পথে পাঠাতে দেয়: বড় প্রজেক্ট, বড় দল, দীর্ঘ সময়, এবং একাধিক মেশিন জুড়ে।
যদি আপনার টিমে একটা নতুন লোক কালকে যোগ দেয়, আপনি কোন এক ছোট পরিবর্তনটি করতে পারেন যাতে তিনি আপনার কোড দ্রুত বুঝে—ভালো নাম, পরিষ্কার কাঠামো, না কি একটি ছোট মন্তব্য যা “কেন” ব্যাখ্যা করে?
গ্রেস হপার হার্ডওয়্যার-নির্দিষ্ট নির্দেশ থেকে মানুষ-কেন্দ্রিক সোর্স কোডের দিকে প্রোগ্রামিং পরিবর্তনে গুরুত্বপূর্ণ ভূমিকা পালন করেছেন। তিনি প্রমান করেছিলেন যে টুলগুলো মানুষের উদ্দেশ্যকে মেশিন-স্তরের ধাপে অনুবাদ করতে পারে — ফলে সফটওয়্যার দ্রুত লেখা, সহজে শেয়ার করা এবং দীর্ঘকাল পরিচালনাযোগ্য হয়ে ওঠে।
কম্পাইলার আগমনের আগে প্রোগ্রামিং মানে ছিল প্রায়ই মেশিন কোড বা খুবই নিম্ন-স্তরের নির্দেশ লেখা, যা বিশেষ একটি কম্পিউটারের জন্য তৈরি করা হত। কাজটি ছিল ম্যানুয়াল, ভঙ্গুর, এবং পরিবর্তন করা ধীর — ছোট একটা ফিচারও ব্যাপক পুনর্লিখনের দরজা খুলে দিত কারণ অ্যাড্রেস, লাফ (jump) এবং মেমোরি লেআউট হার্ডওয়্যার-নির্ভর ছিল।
মেশিন কোড হলো CPU যে কাঁচা বিট প্যাটার্নগুলো (0 ও 1) সরাসরি চালায়। Assembly হলো সেই মেশিন কোডকে সংক্ষিপ্ত, পড়ার যোগ্য নাম দেওয়া—যেমন LOAD বা ADD—তবে তা নির্দিষ্ট মেশিনের ইনস্ট্রাকশন সেটের সঙ্গে আবদ্ধ এবং আপনাকে রেজিস্টার, অ্যাড্রেস ও কাজের সঠিক ক্রম নিয়ে চিন্তা করতে বাধ্য করে।
কম্পাইলার মানব-লিখিত সোর্স কোডকে এমন নিম্ন-স্তরের আকারে অনুবাদ করে যা মেশিন চালাতে পারে (অften একটি executable)। এটি ভাষার নিয়মগুলোর বিরুদ্ধে কোড পরীক্ষা করে এবং ফলাফল অপ্টিমাইজও করতে পারে, ফলে মানুষকে বারবার একটিই বিরক্তিকর অনুবাদ কাজ করতে হয় না।
একটি কম্পাইলার সাধারণত পুরো প্রোগ্রাম (বা বড় অংশ) আগেই অনুবাদ করে runnable আউটপুট তৈরি করে। একজন interpreter মাঝখানে-মাঝখানে অনুবাদ ও এক্সিকিউশন করে—প্রতিটি স্টেপে। বাস্তবে অনেক আধুনিক সিস্টেম বলেই মিলিত পদ্ধতি ব্যবহার করে, তবে কর্মপ্রবাহ এবং পারফরম্যান্সের দিক থেকে পার্থক্য থাকে।
A-0 প্রোগ্রামারকে প্রি-বিল্ট রুটিনগুলোকে আইডেন্টিফায়ার প্রদানের মাধ্যমে রেফার করতে দিয়েছে। এরপর A-0 সেই রুটিনগুলোর মেশিন-কোড ব্লক খুঁজে বের করে, সেগুলো একসাথে জোড়া দিয়ে একটি সম্পূর্ণ executable গঠন করত (এখনকার ভাষায় linking বলা যেত)। এটি এখনও ইংরেজি-সদৃশ ভাষা অনুবাদ করতো না, তবে অটোমেশন ও পুনর্ব্যবহারের ধারণা প্রমাণ করে দিল।
সাবরুটিন reuse মানে আপনি একবার পরীক্ষিত ব্লকগুলো বারবার ব্যবহার করেন, ফলে:
COBOL ব্যবসায়িক ডেটা প্রক্রিয়াকরণ—পে-রোল, ইনভেন্টরি, বিলিং—এর জন্য ডিজাইন করা হয়েছিল এবং কোডকে আরও পাঠযোগ্য ও স্থিতিশীল করতে চেয়েছিল। বড় অর্জন ছিল স্ট্যান্ডার্ডাইজেশন: বহু ভেন্ডার একই স্পেসিফিকেশন বাস্তবায়ন করলে কোড ও দক্ষতা হার্ডওয়্যার পরিবর্তনের মধ্যেও টিকবে।
পোর্টেবিলিটি মানে একই সোর্স কোড বিভিন্ন মেশিনের জন্য কম্পাইল করা যায়—যদি প্রতিটি টার্গেটের জন্য কম্পাইলার থাকে এবং আপনি মেশিন-নির্দিষ্ট অনুমান এড়ান। এর ফলে প্রতিষ্ঠানগুলো হার্ডওয়্যার আপগ্রেড করলে পুরো সিস্টেম পুনর্লিখন করতে হয় না; কেবল পুনঃকম্পাইল বা সামান্য আপডেট লাগতে পারে।
কম্পাইলার ভাষার নিয়মগুলো প্রয়োগ করে এবং কোড অনুবাদ করে, কিন্তু এটি স্বয়ংক্রিয়ভাবে Correctness নিশ্চিত করে না। বাস্তবে বাগ কমাতে কার্যকর উপায়গুলো:
