জন ব্যাকাস ও FORTRAN: সেই ভাষা যা সফটওয়্যারকে স্কেল করতে সাহায্য করেছিল

কেন FORTRAN বড় কাজ ছিল

১৯৫০-এর দশকের শুরুতে কম্পিউটারগুলো দামী, বিরল যন্ত্র ছিল যা সরকার, বিশ্ববিদ্যালয় এবং বড় কোম্পানিগুলো ব্যবহার করত। তখনকার তুলনায় সেগুলো শক্তিশালীই ছিল—কিন্তু সেগুলো প্রোগ্রাম করা প্রচণ্ড ধীর ছিল। অনেক প্রোগ্রাম সরাসরি মেশিন কোড বা অ্যাসেমবলি-তে লেখা হতো, যেখানে প্রতিটি নির্দেশ হার্ডওয়্যারের ক্ষুদ্র অপারেশন সেটের সঙ্গে মিলতে ছিল। একটি সূত্রে সামান্য পরিবর্তনই কোডের বড় অংশ পুনরায় লেখার প্রয়োজন করত, এবং একটি ভুল পুরো রানটাকে ঘণ্টাব্যাপী অপেক্ষার পরও ক্র্যাশ করতে পারত।

জন ব্যাকাস এবং আইবিএমের অপ্রত্যাশিত ধারণা

জন ব্যাকাস IBM-এ একজন ইঞ্জিনিয়ার ছিলেন যিনি দেখতে পেয়েছিলেন কত সময় তুচ্ছ নিম্ন-স্তরের কোডিংয়ে নষ্ট হচ্ছে। তিনি একটি ছোট দল নেতৃত্ব দেন যাতে কিছু_radical পরীক্ষা করা যায়: প্রোগ্রামাররা গণিত-গুরুত্বপূর্ণ নির্দেশগুলো তাদের সমস্যার ধাঁচে লিখুক, এবং একটি কম্পাইলার তা দ্রুত মেশিন কোডে অনুবাদ করুক।

প্রকল্পটি FORTRAN (“Formula Translation”) নামে পরিচিতি পেল এবং এর লক্ষ্য ছিল IBM-এর বৈজ্ঞানিক গ্রাহকরা—যারা সংখ্যাতাত্ত্বিক কাজ করতেন। প্রতিশ্রুতি সহজ ছিল: কম কোড লিখুন, কম বাগ পাবেন, এবং IBM 704-এর মতো মেশিনে এখনও দ্রুত চলবে।

বড় প্রশ্ন: এটা কি যথেষ্ট দ্রুত হবে?

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

তাই FORTRAN কেবল নতুন সাইনট্যাক্স ছিল না। এটা ছিল একটা বাজি যে অটোমেশন দক্ষতা-সম্পন্ন মানুষকে প্রতিদ্বন্দ্বিতা করতে পারবে: একটি কম্পাইলার কি দক্ষ মানুষের দক্ষতার কাছাকাছি কোড তৈরি করতে পারবে—এটাই IBM ও ব্যাকাসের চেষ্টা ছিল।

এই প্রবন্ধে কী পাওয়া যাবে

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

উচ্চ-স্তরের ভাষার আগের সময়: শুধু অ্যাসেমবলি

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

মেশিন কোড ও অ্যাসেমবলি ছিল বাস্তবতা

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

বৈজ্ঞানিক গণনার জন্য তা মানে ছিল লুপ, মেমরি বিন্যাস এবং মধ্যবর্তী মানগুলো হাতে-ম্যানেজ করা। সূত্রে সামান্য পরিবর্তনও প্রোগ্রামের একাধিক অংশ পুনরায় লিখতে বাধ্য করত কারণ সব কিছু ঠিকানায় ও জাম্পে আন্তঃসংযুক্ত ছিল।

কষ্টের পয়েন্টগুলো: সময়, ত্রুটি, এবং লক-ইন

অ্যাসেমবলি প্রোগ্রামিং ধীর ও ভঙ্গুর ছিল। সাধারণ সমস্যা ছিল:

• সময় অপচয়: লেখা ও ডিবাগ করা প্রাক-গণিতের চেয়েও অনেক দীর্ঘ নিচে।
• ত্রুটিপ্রবণ বিবরণ: একটি ভুল ঠিকানা, মিসড ক্যারি, অথবা অফ-বাই-ওয়ান জাম্প ফলাফলকে বৈধতা হীন করতে পারে।
• হার্ডওয়্যার-নির্দিষ্ট কোড: প্রোগ্রামগুলো একটি মেশিন মডেলে দৃঢ়ভাবে বাঁধা ছিল (যেমন IBM 704)। অন্য সিস্টেমে স্থানান্তর করতে প্রায় নতুন করে শুরু করতে হতো।

দ্রুত পুনরাবৃত্তি কেন জরুরি ছিল

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

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

জন ব্যাকাস এবং IBM-এর নতুন ধরনের প্রোগ্রামিংয়ের বাজি

জন ব্যাকাস শুরুতে কোন নিপুণ “কম্পিউটার পায়নিয়ার” ছিলেন না। অস্থির একটি সময়কালের পরে ও ইউ.এস. আর্মিতে সময় কাটিয়ে তিনি ১৯৫০-এর দশকে IBM-এ পৌঁছান, যখন কম্পিউটারগুলো এখনও দুর্লভ এবং হাতে-কলমে প্রোগ্রামে করা হতো। ব্যাকাস দ্রুত দুটি জিনিসের জন্য খ্যাতি লাভ করলেন: বিরক্তিকর কাজের ওপর বাস্তববাদী অটলতা এবং সাহসী প্রকৌশল প্রচেষ্টাগুলো সংগঠিত করার প্রতিভা।

IBM-এর লক্ষ্য: 704-এর সুবিধা নেযে নিন

IBM-এর কাছে একটা সমস্যা ও সুযোগ ছিল—IBM 704। এটা তখনকার তুলনায় শক্তিশালী ছিল ও গণিত-মুখী কাজের জন্য সুবিধা (যেমন ফ্লোটিং-পয়েন্ট আরিথমেটিক) ছিল। কিন্তু প্রযুক্তিগত ও বৈজ্ঞানিক গ্রাহকরা অ্যাসেমবলি ভাষা লেখায় প্রচণ্ড সময় ব্যয় করছিল। যদি প্রোগ্রামিং এতই ধীরই থাকে, তাহলে দুর্দান্ত মেশিনও অব্যবহৃত পড়ে থাকবে।

IBM-এর বাজি সরল ও ঝুঁকিপূর্ণ: 704-কে ব্যবহারযোগ্য করে তুলুন প্রোগ্রাম করা সহজ করে, কিন্তু গতি হারাবেন না।

একটি দল কম্পাইলারের ওপর গড়ে তোলা

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

তখনকার অর্থে "উচ্চ-স্তর" মানে কি

একটি উচ্চ-স্তরের ভাষা কেবল সুন্দর সিনট্যাক্স নয়; এর মানে ছিল সূত্র, লুপ এবং গঠনমূলক নির্দেশগুলোকে সমস্যার গণিত ও লজিকের কাছাকাছি লেখা—তারপর কম্পাইলারের ওপর বিশ্বাস করা যেন তা দক্ষতার সঙ্গে অনুবাদ করে। IBM ও ব্যাকাস যে আস্থা অর্জন করতে চেয়েছিলেন সেটাই মূল লক্ষ্য ছিল।

FORTRAN কী প্রতিশ্রুতি দিল (এবং মানুষ কেন সন্দিহান ছিল)

FORTRAN-এর মূল প্রতিশ্রুতি সরল কিন্তু বিপ্লবী ছিল: ক্ষুদ্র ধাপে সব কিছু কিভাবে করতে হবে না বলে আপনি এমন বিবৃতি লিখতে পারবেন যা আপনার গণিতের ভাষার অনেক কাছাকাছি।

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

সাধারণ কথায় “কম্পাইলড” হওয়া

FORTRAN সরাসরি মেশিনে চলে না। একটি আলাদা প্রোগ্রাম—কম্পাইলার—FORTRAN সোর্স কোডকে মেশিনের নিজস্ব নিম্ন-স্তরের নির্দেশাবলীতে অনুবাদ করত।

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

নকশার লক্ষ্য: পাঠযোগ্য, দ্রুত, ব্যবহারযোগ্য

ব্যাকাসের দল একটি বিরল সমন্বয় লক্ষ্যমাত্রা করেছিল:

• পাঠযোগ্যতা: বিয়োগবোধ ও প্রচলিত বৈজ্ঞানিক নোটেশন-মতে কোড।
• গতি: হ্যান্ড-রাইটেন অ্যাসেমবলির কাছাকাছি রান-টাইম তৈরি করা।
• প্রায়োগিকতা: সংখ্যাতাত্ত্বিক কাজের জন্য বাস্তবিক প্রয়োজনীয় বৈশিষ্ট্য।

শেষটি গুরুত্বপূর্ণ ছিল—FORTRAN সবকিছুর জন্য চেষ্টা করছিল না; এটা বাস্তব গণনা দ্রুত ও কম ত্রুটিসহ শেষ করার লক্ষ্য রেখেছিল।

মানুষ কেন সন্দিহান ছিল

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

একটি স্পষ্ট লক্ষ্য শ্রোতা

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

কম্পাইলার চ্যালেঞ্জ: ইংরেজি-সদৃশ কোডকে কীভাবে দ্রুত করা যায়

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

কম্পাইলার কী (একটি দৈনন্দিন উপমা)

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

FORTRAN-কে সেই দুর্দান্ত অনুবাদক লাগছিল।

ভাষার সৌন্দর্যের চাইতে কম্পাইলারের গুণগত মান বেশী গুরুত্বপূর্ণ ছিল

প্রারম্ভিক প্রোগ্রামাররা FORTRAN বেছে নিচ্ছিলেন সৌন্দর্যের জন্য নয়; তারা এটা বেছে নিতেন যদি এটা ভাড়া চালিয়ে দিতে পারে: কম প্রোগ্রামিং ঘণ্টায় কোন রানটাইম জরিমানা না করে। দামী মেশিনে ফাঁকতালে CPU সময় অপচয় অর্থে টাকা অপচয়—এবং বৈজ্ঞানিক কাজে ধীর কোড ফলাফলকে সময়োপযোগী না করে দিতে পারে।

তাই প্রকৃত পণ্যটি ছিল ভাষার স্পেসিফিকেশন নয়; এটি ছিল কম্পাইলারের আউটপুট। যদি কম্পাইল করা প্রোগ্রাম প্রায় হ্যান্ড-রাইটেন অ্যাসেমবলির মতো দ্রুত না চলে, তাহলে দলগুলো FORTRAN ছেড়ে দিত।

মূল প্রযুক্তিগত বাধা: সূত্রকে দ্রুত মেশিন কোডে রূপান্তর

FORTRAN-এর বাজারযোগ্য পয়েন্ট—গণিতকে গণিতের মতো লেখা—কম্পাইলেশনকেও কঠোর করে তোলে। কম্পাইলারকে করতে হতো:

• গাণিতিক এক্সপ্রেশন সঠিকভাবে পার্স করা (অপারেটর অগ্রাধিকার সহ)
• মূল্যগুলো কখন রেজিস্টারে রাখবেন বনাম মেমরিতে—এই সিদ্ধান্ত নেওয়া
• গাণিতিক ক্রিয়াকলাপ নিরাপদভাবে পুনরায় বিন্যাস করে নির্দেশসংখ্যা কমানো
• টাইট লুপ জেনারেট করা যাতে সাইকেল নষ্ট না হয়

গ্রহণযোগ্যতাকে হত্যা করতে পারতো এমন সন্দেহ

অনেক ইঞ্জিনিয়ার ধরে নিতেন যে উচ্চ-স্তরের কোড per definition ধীর হবে। ব্যাকাসের দলকে সেই ধারণাকে প্রমাণ দিয়ে হারাতে হয়েছিল: কম্পাইল করা প্রোগ্রাম যা প্রতিযোগিতামূলক, পূর্বানুমেয় এবং বিশ্বাসযোগ্য। যদি পারফরম্যান্স বিশ্বাস যোগ্য না হত, FORTRAN কেবল একাডেমিক সান্ত্বনা হিসেবেই সীমাবদ্ধ হত।

অপটিমাইজেশন: সেই গোপন অস্ত্র যা ব্যবহারকারীদের জয় করল

FORTRAN-এর বড় প্রতিশ্রুতি ছিল না কেবল যে তা দ্রুত কোড লিখতে দেবে—বরং compiled প্রোগ্রাম এখনও দ্রুত চলবে। এটা গুরুত্বপূর্ণ কারণ প্রাথমিক গ্রাহকরা শখের ব্যবহারকারী ছিলেন না; তারা ইঞ্জিনিয়ার ও বিজ্ঞানী যাদের মূল্যায়ন মূলত মেশিন-ঘন্টার ও ফলাফলের উপর হত।

কি বোঝায় “অপটিমাইজেশন” (সোজা কথায়)

অপটিমাইজেশন হলো সেই অতিরিক্ত কাজ যা কম্পাইলার করে যাতে আপনাকে না করতে হয়। আপনি স্পষ্ট, গণিতসদৃশ বিবৃতি লিখেন, এবং কম্পাইলার নিঃশব্দে সেগুলোকে এমনভাবে পুনরায় লিখে দেয় যেটা কম নির্দেশ, কম মেমরি অ্যাকসেস এবং IBM 704-এ কম সময় নেয়।

গুরুত্বপূর্ণ হলো লক্ষ্য "চতুর" হওয়া নয়—বরং পূর্বানুমেয়ভাবে দক্ষ হওয়া যাতে মানুষ বিশ্বাস করতে পারে FORTRAN-এ লেখা হলে তাদের শাস্তি হিসেবে ধীর কোড পাবে না।

ব্যবহারকারীরা আক্ষরিকভাবে অনুভব করতে পারতেন এমন অপটিমাইজেশন

FORTRAN কম্পাইলার যে উন্নতিগুলো করত তা দৈনন্দিন বোধগম্য ছিল:

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

এর ফলে প্রোগ্রামারদেরকে ইনস্ট্রাকশন টাইমিং বা মেমরি ঠিকানার চিন্তা না করেই অ্যাসেমবলি প্রোগ্রামাররা যে সুবিধা পেতেন, একইরকম সুবিধা তারা পেলেন।

কেন এটি অ্যাসেমবলি প্রোগ্রামারদের জয় করল

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

ব্যাকাসের দল সেই সন্দেহকে একটি প্রোডাক্ট রিকোয়ারমেন্টের মতো নিয়ে নিল। অপটিমাইজেশন ছিল ন্যূনতম বৈশিষ্ট্য নয়; এটি ছিল প্রমাণ যে অ্যাবস্ট্রাকশন মানে নয় পারফরম্যান্স ছাড় দেওয়া।

সুনামগত প্রভাব

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

FORTRAN কী সহজ করে দিল: লুপ, সাবরুটিন ও অ্যারে

FORTRAN কেবল "দেখতে ভালো" ছিল না; এটি কয়েকটি ব্যবহারিক ধারনা প্যাকেজ করে যা বৈজ্ঞানিক ও ইঞ্জিনিয়ারিং কাজের সাথে সরাসরি মানায়: একটি হিসাব বারবার করা, একটি পদ্ধতি পুনরায় ব্যবহার করা, এবং অনেক সংখ্যার সংরক্ষণ এক নির্দিষ্ট প্যাটার্নে করা।

গণিতের সঙ্গে মিলে যাওয়া লুপ

বৈজ্ঞানিক প্রোগ্রামগুলোতে প্রচুর "N বার এটা কর" কাজ থাকে: পরিমাপ যোগ করা, সময়-ধাপে এগোনো, কোনো সমাধানের দিকে পুনরাবর্তন বা একাধিক ডেটা পয়েন্টে একই সূত্র চালানো। অ্যাসেমবলি-তে এই পুনরাবৃত্তি প্রায়ই ম্যানুয়াল জাম্প লজিক ছিল—ভুল করা সহজ এবং পরে পড়তেও কঠিন।

FORTRAN-এর DO লুপ সেই উদ্দেশ্যটিকে স্পষ্ট করে:

      SUM = 0.0
      DO 10 I = 1, 100
         SUM = SUM + X(I)
 10   CONTINUE

একাধিক জাম্প ও কাউন্টার ম্যানেজ করার বদলে প্রোগ্রামার রেঞ্জটি বলে দিত এবং সূত্রটির ওপর মনোযোগ রাখত।

পুনঃব্যবহারের জন্য সাবরুটিন (এবং দলগত কাজ)

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

আরও গুরুত্বপূর্ণ, সাবরুটিন বড় প্রোগ্রামকে ছোট অংশে ভাগ করতে উৎসাহ দেয়—যেগুলো আলাদা করে পরীক্ষা, পর্যালোচনা ও উন্নত করা যায়।

অ্যারে: বৈজ্ঞানিক ডেটার স্বাভাবিক আকার

পরিমাপ, ভেক্টর, টেবিল, গ্রিড ও ম্যাট্রিক্স—এসবই বৈজ্ঞানিক গণনার কেন্দ্রে থাকে। অ্যারেগুলো প্রোগ্রামারকে সেই কাঠামো সরাসরি উপস্থাপন করতে দেয়, আলাদা আলাদা ভেরিয়েবল বা ম্যানুয়াল ঠিকানা গণনা ছাড়াই।

কম “রহস্যময় জাম্প”, কম বাগ

অ্যাসেমবলি-ভিত্তিক কন্ট্রোল ফ্লোতে অনেক কন্ডিশনাল ও আনকন্ডিশনাল জাম্প relied করত। একটি ভুল টার্গেট লেবেল নীরবে ফলাফল ভাঙত। লুপ ও নামকৃত সাবরুটিনের মত গঠিত কনস্ট্রাক্ট দেওয়ার মাধ্যমে FORTRAN জটিল জাম্প লজিকের প্রয়োজন কমিয়েছিল—প্রোগ্রামগুলো যাচাই করা সহজ ও পরিবর্তনের সময় কম ভঙ্গুর হয়ে উঠত।

গবেষণা থেকে বাস্তব কাজ: FORTRAN কোথায় ব্যাপকভাবে গ্রহণ পেয়েছিল

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

প্রথম বড় ব্যবহারকারীরা: বিজ্ঞান ও ইঞ্জিনিয়ারিং

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

FORTRAN বিশেষত ভাল খাপ খায় কারণ তার মূল বৈশিষ্ট্যগুলো সমস্যাগুলোর রূপের সঙ্গে মিলে যায়: অ্যারে ম্যাট্রিক্স ও গ্রিডের জন্য, লুপ বারবার সংখ্যাসংক্রান্ত ধাপের জন্য, এবং সাবরুটিন ভারী গণিতকে ছোট অংশে ভাগ করতে।

প্রোগ্রাম ভাগ করে নেওয়া বাস্তবসম্মত হলো

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

পুনঃব্যবহার শুধু স্লোগান থাকল না

একবার প্রোগ্রামাররা উচ্চ-স্তরে হিসাব প্রকাশ করতে পারল, বিশ্বাসযোগ্য রুটিনের একটি লাইব্রেরি রাখা যৌক্তিক হয়ে উঠল। দলগুলো পুনঃব্যবহারযোগ্য সংখ্যা পদ্ধতি, ইনপুট/আউটপুট প্যাটার্ন, ও ডোমেইন-নির্দিষ্ট গণনা ব্যবহার করতে শুরু করল যতটা ভয় ছিল না যে এক লাইনের পরিবর্তনে সব কিছু ভেঙে পড়বে। এই পরিবর্তন—কোডকে রক্ষণাবেক্ষণযোগ্য ও পুনরায় ব্যবহারযোগ্য সম্পদ হিসেবে দেখা—প্রোগ্রামিংকে এক-আধারে কারিগরি কাজ থেকে পুনরাবৃত্তিমূলক কাজে পরিণত করতে সাহায্য করল।

FORTRAN-এর দীর্ঘ ছায়া: পরবর্তী ভাষাগুলোর ওপর প্রভাব

FORTRAN কেবল একটি মেশিনকে সহজে প্রোগ্রাম করার উপায় সৃষ্টি করেনি; এটি একটি সেট প্রত্যাশাও স্থাপন করল যে প্রোগ্রামিং ভাষাগুলোকে কি করা উচিত—এবং কম্পাইলারগুলো কি করতে পারে—সেই সময়ে যখন দুটোই বিতর্কিত ছিল।

ভাষা নকশা ও কম্পাইলার প্রযুক্তি আলাদা বিষয় নয়

FORTRAN-এর সাফল্য থেকে একটি মূল পাঠ হল ভাষা ডিজাইন ও কম্পাইলার ডিজাইন একটি অপরিহার্য জোড়া। প্রারম্ভিক সমালোচকরা কেবল “ইংরেজি-সদৃশ” কোডের বিরোধিতাই করছিল না; তারা সন্দেহ করছিল যে কম্পাইলার দক্ষভাবে তা মেশিনের উপযোগী করে তুলবে কি না। FORTRAN টিমের উত্তর ছিল—কম্পাইলেশন ও অপ্টিমাইজেশনে ব্যাপক বিনিয়োগ করা—এমন মনোভঙ্গি পরে অনেক ভাষা প্রকল্পে প্রতিধ্বনিত হয়েছে।

আপনি আজকের বেশ কয়েকটি সিস্টেমে দেখতে পাবেন যে উন্নত কম্পাইলার কৌশল ভালো ভাষাগুলোকে সম্ভব করে তোলে: নিরাপদ অ্যাবস্ট্রাকশন, পরিষ্কার সিনট্যাক্স, ও উচ্চ উৎপাদনশীলতা পারফরম্যান্স হারিয়েও নয়।

অপটিমাইজেশন এখন প্রত্যাশা হিসেবে

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

পোর্টেবিলিটি ও স্ট্যান্ডার্ড: ধীরে ধীরে কিন্তু অনিবার্য

প্রাথমিক FORTRAN গভীরভাবে IBM হার্ডওয়্যারের সঙ্গে জড়িত ছিল, এবং পোর্টেবিলিটি তখন প্রধান বিক্রয়বিন্দু ছিল না। কিন্তু FORTRAN যখন প্রতিষ্ঠান জুড়ে ছড়াতে শুরু করল, তখন একই বৈজ্ঞানিক কোডকে বিভিন্ন মেশিনে পুনরায় লেখার খরচ স্পষ্ট হলো। সময়ে সময়ে বিস্তৃত ঐতিহাসিক কনসেনসাস FORTRAN-কে এমন একটি শক্তি হিসেবে দেখে যা ইন্ডাস্ট্রিকে ভাষা স্ট্যান্ডার্ডাইজেশনের দিকে ঠেলে দিল।

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

সীমাবদ্ধতা ও সমালোচনা: FORTRAN কী সমাধান করে নি

FORTRAN একটি যন্ত্রণা দূর করল—জটিল গণনা অ্যাসেমবলি ছাড়া করা—কিন্তু এটি প্রোগ্রামিং “সহজ” করে তোলে নি। প্রাথমিক ব্যবহারকারীরা আবিষ্কার করল যে একটি উচ্চ-স্তরের ভাষা এক সেট ঝামেলা কমিয়ে অন্য সেট উন্মোচন করে।

পাঠযোগ্যতা বনাম পারফরম্যান্স কোনো ফ্রি লাঞ্চ নয়

FORTRAN-এর গতি-খ্যাতি সঙ্গে এসেছে কোড লেখার কিছু ট্রেডঅফ। প্রোগ্রামগুলো প্রায়ই এমনভাবে আকৃত হয়েছিল যা কম্পাইলারকে অপ্টিমাইজ করা সহজ করে—না যে সর্বোত্তমভাবে পাঠযোগ্য।

উদাহরণস্বরূপ: একজন বিজ্ঞানী পরিষ্কার একটি গণনা কয়েক ধাপে ভাগ করতে পারতেন বা বিবৃতি পুনরায় সাজাতে পারতেন কেবল কারণ তা দ্রুত চলে। ফলে কোডটি ভাল পারফরম্যান্স করলেও নতুন সহযোগীর জন্য পড়তে কঠিন হয়ে উঠত।

হার্ডওয়্যার-বহুল দুনিয়ায় পোর্টেবিলিটির সীমা

FORTRAN-কে প্রায়শই বিভিন্ন মেশিনে প্রোগ্রামগুলি স্থানান্তর করতে সহায়ক হিসেবে প্রশংসা করা হয়, কিন্তু শুরুতে “পোর্টেবল” হওয়ার পাশে একটা তারকাচিহ্ন থাকত। কম্পিউটারগুলো শব্দ-আকার, ইনপুট/আউটপুট ডিভাইস, এবং সংখ্যাতাত্ত্বিক আচরণে আলাদা ছিল। দলগুলো মাঝে মাঝে একই প্রোগ্রামের ভিন্ন ভিন্ন সংস্করণ রেখে দিত, বা বিশেষ ফিচারের দরকার হলে ভেন্ডর-নির্দিষ্ট অংশ যোগ করত।

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

ভাষা জটিলতা মুছে দেয় নি

FORTRAN বৈজ্ঞানিক গণনার জন্য তৈরি, সর্বকালের সবকিছুর জন্য নয়। বড় কোডবেস সংগঠনের জন্য শক্তিশালী সরঞ্জাম পরবর্তীকালে যোগ করা হয়। ডিবাগিং এখনও ধীর ও হতাশাজনক ছিল, এবং প্রাথমিক কম্পাইলার মাঝে মাঝে এমন রহস্যময় ত্রুটি দেখাত যা মনে করাত “আসলে অ্যাসেমবলি-তে ফিরে গেছি, কেবল আলাদা শব্দে।”

আজকের পুরোনো বিতর্ক এখনও পরিচিত শোনায়

FORTRAN এমন বিতর্ক শুরু করেছিল যা আধুনিক দলও এখনও চিন্তা করে: ডেভেলপাররা সর্বোচ্চ গতি অগ্রাধিকার দেবেন, না পরিষ্কার কোড ও উচ্চ-স্তরের অ্যাবস্ট্রাকশান? সেরা উত্তর প্রেক্ষাপটের ওপর নির্ভর করেছিল তখনও—এবং এখনও।

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

আধুনিক সফটওয়্যার টিমের জন্য পাঠ

FORTRAN সফল হল কারণ এটি প্রোগ্রামার সময়কে উপরোক্ত সংকটজনক সম্পদ হিসেবে দেখেছিল। ব্যাকাস ও IBM কেবল সুন্দর সিনট্যাক্স আবিষ্কার করেননি—তারা প্রমাণ করলেন যে টুলিং-এ বিনিয়োগ নতুন ধরনের সফটওয়্যারকে সম্ভব করে তোলে।

উৎপাদনশীলতা “চতুরতা” ছাড়িয়ে মূল্যবান

FORTRAN-এর মূল প্রস্তাব ছিল: কম লাইন লিখে, বেশি সঠিক প্রোগ্রাম পাঠান। আধুনিক দলগুলো নিয়মিত এটি পুনরায় শিখে: একটি সপ্তাহ নিরাপদ API, পরিষ্কার মডিউল বাউনডারি, বা এমন একটি স্ক্রিপ্ট গড়তে ব্যয় করলে সেটা প্রায়ই গরম লুপ থেকে ৩% সাশ্রয় করার চেয়ে বেশি মূল্য ফেরত দেয়।

বিমূর্ততার ওপর আস্থা অর্জন করুন

মানুষ FORTRAN-এ সন্দিহান ছিল কারণ অ্যাবস্ট্রাকশন মানে নিয়ন্ত্রণ ছেড়ে দেওয়া মনে হত। কম্পাইলার হস্তক্ষেপ করে পারফরম্যান্স হাতে-কলমে অ্যাসেমবলি-র সমীপে আনে—এভাবে আস্থা অর্জিত হল।

আধুনিক অনুরূপ ঘটনা হচ্ছে ফ্রেমওয়ার্ক, ম্যানেজড রানটাইম, ও ক্লাউড সার্ভিসে আস্থাভিত্তি—কিন্তু এই আস্থা অর্জিত হয়, فرض করা হয় না। যখন একটি বিমূর্ততা ভেঙে পড়ে, দলগুলো “ম্যানুয়াল মোড”-এ ফিরে যায়। প্রতিকারটা ১৯৫৭-এর মতই: পরিমাপযোগ্য পারফরম্যান্স, স্বচ্ছ আচরণ, এবং পূর্বানুমেয় ব্যর্থতার মোড।

টুলিং যা সম্ভব করে তোলে

FORTRAN কেবল ভাষা ছিল না—এটা একটি কম্পাইলার প্রচেষ্টা ছিল যা উচ্চ-স্তরের প্রোগ্রামিংকে স্কেলে বাস্তবায়নযোগ্য করে তুলল। আজকের সমতুল্যগুলো:

• অপ্টিমাইজ ও সতর্কতা দেওয়া কম্পাইলার ও ইন্টারপ্রেটার
• কোড রিভিউ দ্রুত করা লিন্টার ও ফরম্যাটার
• পরিবর্তনগুলো রুটিন ইভেন্টে পরিণত করা টেস্টিং ও সিআই

আরও নতুন টুলিং ক্যাটাগরি রয়েছে যা মূল FORTRAN বাজির অনুরূপ: কাজকে মানুষ থেকে “কম্পাইলার-সদৃশ” সিস্টেমে সরিয়ে নেওয়ার অটোমেশন। যেমন Koder.ai-এর মত ভিব-কোডিং প্ল্যাটফর্মগুলো চ্যাটে আপনি যা চান তা বর্ণনা করে, তারপর এজেন্ট-ভিত্তিক সিস্টেম বাস্তব অ্যাপ্লিকেশন (উদাহরণ: ওয়েবে React, ব্যাকএন্ডে Go + PostgreSQL, মোবাইলে Flutter) তৈরি ও পুনরাবৃত্তি করে। পরিকল্পনা মোড, স্ন্যাপশট, ও রোলব্যাকের মত ফিচারগুলো একই জিনিস দেওয়ার চেষ্টা করে যা FORTRAN-কে প্রমাণ করতে হয়েছিল: উচ্চ-স্তরের উদ্দেশ্য, অপারেশনাল নিয়ন্ত্রণ হারিয়ে না দিয়ে।

ভাল টুল শুধু বাগ প্রতিরোধ করে না; সেগুলো আকাঙ্ক্ষা বাড়ায়। ছোট টিমে বড় সিস্টেম বানানো সম্ভব করে।

সারমরহ

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