حكاية ميل

مقالة جديدة كرست للجانب المتعجرف من البرمجة
أدلت بالتصريح الأجرد غير المصقول:

المبرمجون الحقيقيون يكتبون بلغة فورتران.

قد يكون هذا حقيقيا الآن،
في هذا العصر المنحط،
عصر البيرة اللايت والآلات الحاسبة الصغيرة، والبرمجيات "سهلة الاستخدام"
لكن زمان في الأيام الخوالي،
لما كان مصطلح "البرمجيات" كلمة مضحكة،
وكانت أجهزة الكمبيوتر الحقيقية كانت تصنع الطبل والصمامات المفرغة،
كان يكتب المبرمجون الحقيقيون بلغة الآلة.
ليست فورتران. ولا راتفور. ولا حتى أسمبلي.
لغة الآلة.
أرقام ست عشرية خام مبهمة غير مزينة.
مباشرةً.

وخوفا من أن ينشأ جيل جديد بكامله من المبرمجين
على جهل بذلك الماضي المجيد،
شعرت بأنني ملزم أن أوصف،
على قدر ما أستطيع خلال الفجوة بين الأجيال،
كيف كان يكتب المبرمج الحقيقي الكود.
سوف أسميه "ميل"،
لأن ذلك كان اسمه.

أول مرة قابلت فيها ميل كانت عندما ذهبت للعمل في مؤسسة Royal McBee للكمبيوتر،
كانت فرعا تابعا لشركة التيليتايب والذي أصبح ميتا الآن.
صنعت الشركة LGP-30،
كمبيوتر بذاكرة طبلة،
صغير ورخيص (بمعايير ذاك الزمن)،
وبدأت تصنع،
RPC-4000، كمبيوتر محسن أكتر بكتير،
وأكبر وأحسن وأسرع.
ذاكرة القلب الحديدي كانت مكلفة جدا،
ولم تكن جديرة بالبقاء، عموما.
(ولهذا لم تسمع عن "الشركة" أو "الكمبيوتر".)

وظيفتي كانت أن أكتب مترجما compiler للفورتران
من أجل عيون المعجزة الجديدة وميل كان دليلي لعجائبها.
ميل لم يكن موافقا على المترجمات.

"لو لم يستطع البرنامج إعادة كتابة كود نفسه"
تساءل ميل، "فماذا تكون فائدته؟"

ميل كان كاتب،
بالنظام الست عشري،
أشهر برنامج كمبيوتر للشركة،
كان البرنامج يعمل على LGP-30
وكان يلعب البلاك جاك مع الزبائن المحتملين
في عروض الكمبيوتر.
تأثيره كان دائما ما يكون دراميا.
وفي كل معرض كان الجانب الخاص بـ LGB-30 مزدحما دائما
وكان رجال مبيعات IBM يتجمعون حوله
وهم يتحدثون إلى بعضهم البعض
سواء كان أو لم يكن ذلك فعلا يؤدي إلى بيع أجهزة الكمبيوتر،
سؤال لم نناقشه أبداً.

كانت مهمة ميل هي إعادة كتابة
برنامج البلاك جاك على RPC-4000
(نَقْل؟ ماذا يعني هذا؟)
وكان الكمبيوتر الجديد يعمل
بأسلوب عنونة واحد زائد واحد
وفي هذا النظام يكون لكل تعليمة،
- بالإضافة إلى الأوبكود
وعنوان المعامل المطلوب-
عنوان آخر يشير إلى مكان على ذاكرة الطلبة الدوارة
حيث تقع التعليمة التالية.

بلغة اليوم،
كل تعليمة كانت متبوعة بـ GOTO!
ضع ذلك في ماسورة باسكال ودخنه.

ميل أحب RPC-4000
لإنه يستطيع أن يحسن الكود:
ذاك هو، يضع التعليمات على الطبلة
حيث تكون التعليمة التالية جاهزة تحت إبرة القراءة،
ومتاحة للتنفيذ الفوري،
بمجرد أن تنتهي التعليمة الحالية من عملها،
كان هناك برنامجاً يؤدي هذه الوظيفة
وهو الـ "optimizing assembler”،
لكن ميل رفض أن يستخدمه.

"أنت لا تعرف أبداً أين سيضع الأشياء"،
كان تفسيره، "ولهذا ستضطر لاستخدام ثوابت منفصلة"

لقد مر زمن طويل حتى فهمت هذا الكلام.
لأن ميل كان يعرف القيمة العددية
لكل أوبكود،
ولأنه كان يختار العناوين على الطبلة بنفسه،
فكل تعليمة يكتبها يمكن أيضاً اعتبارها
ثابت عددي.
فمثلا يمكنه أن يأخذ تعليمة add مسبقة،
ويستخدمها في عملية الضرب،
إذا كانت تمتلك القيمة العددية الصحيحة.
كود ميل لم يكن سهلا للتعديل بواسطة شخص آخر.

لقد قارنت برامج ميل المحسنة يدويا
بنفس الكود الذي يخرجه الـ optimizing assembler،
وبرامج ميل كانت الأسرع دائماً.
هذا كان بسبب أن طريقة تصميم البرامج "من أعلى إلى أسفل"
لم تكن قد اخترعت من قبل،
وعموما ميل لم يكن ليستعملها أصلا.
كان يكتب الأجزاء الداخلية للـ loops  أولاً،
بحيث يحصلون مبكرا على فرصة الاختيار
للعناوين المثلى على الطبلة.
لم يكن الـ optimizing assembler ذكيا بالقدر الكافي كي يقوم بها هكذا.

ميل أيضا لم يقم أبداً بكتابة كود لتأخير الزمن،
حتى عندما كانت طابعة Flexowriter العنيدة
تطلب زمن تأخير بين المحارف المخرجة حتى تعمل بشكل سليم،
كان يقوم باختيار أماكن التعليمات على الطبلة
بحيث تكون كل تعليمة تالية فقط تحت إبرة القراءة
عندما يكون هناك حاجة إليها؛
فكانت الطبلة تحتاج أن تقوم بعمل دورة كاملة،
لكي تجد التعليمة التالية.
أطلق ميل على هذا الأسلوب مصطلح لا يمكن أن يُنسى،
على الرغم من أن "optimum” هو مصطلح مطلق،
مثل "unique”، أصبح من الشائع أن
يتم جعله نسبياً:
"not quite optimum” أو "less optimum”
او "not very optimum”
ميل أطلق على مواقع تأخير الزمن القصوى
"most pessimum”.

بعد أن انتهى من برنامج البلاك جاك
وتمكن من تشغيله
("حتى الـ initializer محسن"،
كان يقولها بفخر)،
جاءه طلب تعديل من قسم المبيعات.
كان البرنامج يستخدم مولد أنيق (محسن)
للأرقام العشوائية
لكي يقوم بإعادة ترتيب "البطاقات" والسحب من "الرزمة"
شعر أحد رجال المبيعات بأنه كان عادلا أكثر من اللازم،
حيث أنه في بعض الأحيان كان الزبائن يخسرون.
فأرادوا من ميل أن يقوم بتعديل البرنامج،
بحيث عندما يكون مفتاح الـ sense الموجود على الكونسول في وضع set،
يمكنهم تغيير الاحتمالات ليفوز الزبون.

ميل أحجم عن ذلك،
لقد شعر أن هذا عمل غير أمين،
حيث كان كذلك،
وأن ذلك قد مس نزاهته الشخصية كمبرمج،
وهذا ما حدث،
لذا رفض أن يفعل ذلك.
تحدث رئيس رجال المبيعات إلى ميل،
والرئيس الكبير، وبطلب من الرئيس
تحدث إليه بعض زملائه المبرمجين.
ميل أخيرا تنازل وكتب الكود،
ولكنه عمل التيست معكوسا،
بحيث عندما يكون مفتاح الـ sense مشغلاً،
يقوم البرنامج بالغش، ويفوز كل مرة.
ميل كان مبتهجاً بذلك،
مدعياً أن اللاوعي لديه كان أخلاقياً بشكل لا يمكنه التحكم فيه،
وعاند ورفض أن يصلح البرنامج.

بعد أن ترك ميل الشركة، ليذهب إلى greener pa$ture$،
طلب مني الرئيس الكبير أن أنظر في الكود،
لأرى ما إذا كان يمكنني أن أجد التيست وأصلحه.
وافقت على مضض أن أنظر في الكود.
لقد كان تتبع كود ميل مغامرة حقيقية.

لقد شعرت دائماً أن البرمجة شكل من أشكال الفن،
يمكن تقدير قيمته الحقيقة  فقط
بواسطة ضليع آخر في ذلك الفن الغامض
فهناك من الجواهر الجميلة والأعمال الأستاذية المتألقة
ما هو مختفي عن أنظار البشر ومواضع إعجابهم، في بعض الأحيان للأبد
بفعل طبيعة العملية.
يمكنك أن تعرف كثيرا عن الفرد
فقط بقراءة كوده،
حتى لو بالست عشري.
أعتقد أن ميل كان عبقريا مغمورا.

ربما كانت صدمتي العظيمة قد وقعت
عندما اكتشفت loop بريئة ليس بها أي تيست.
لا يوجد أي تيست. لا يوجد مطلقا.
تقول الفطرة السليمة أن هذه الـ loop مغلقة،
يدور فيها البرنامج إلى الأبد بشكل لا نهائي.
وبالرغم من ذلك، كان البرنامج يخرج منها بشكل سليم،
وبأمان إلى الجانب الآخر.
لقد استهلكت أسبوعين لمعرفة ذلك.

كان لدى كمبيوتر RPC-4000 ميزة حديثة حقا
تسمى مسجل الفهرس index register.
مكنت المبرمج من كتابة الـ loop
باستخدام تعليمة مفهرسة indexed instruction داخل اللوب،
وفي كل لفة يتم تنفيذ التعليمة،
والرقم المخزن في مسجل الفهرس
يضاف إلى العنوان المخزن داخل التعليمة،
حيث يشير الناتج إلى
المعطى التالي في السلسلة.
يحتاج المبرمج فقط إلى زيادة مسجل الفهرس
في كل لفة.
ميل لم يستعمله أبداً.

في المقابل، كان يسحب التعليمة إلى مسجل من مسجلات الماكينة،
ويضيف ١ إلى العنوان الموجود داخل التعليمة،
ثم يعيد تخزين التعليمة.
ويمكنه بعد ذلك تنفيذ التعليمة المعدلة،
مباشرة من المسجل.
كانت الـ loop مكتوبة بحيث يكون وقت التنفيذ الإضافي هذا
كله مأخوذ في الحسبان -
فقط عندما تنتهي التعليمة من التنفيذ،
تكون التعليمة التالية تماما تحت إبرة القراءة الخاصة بالطبلة
وجاهزة للذهاب.
لكن الـ loop لم يكن بداخلها أي تيست.

جاء الدليل القاتل عندما لاحظت أن
البت الخاص بمسجل الفهرسة،
وهو البت الواقع بين العنوان الهدف،
والأوبكود داخل التعليمة،
كان مفعلاً -
مع أن ميل لم يستعمل أبداً مؤشر الفهرسة،
وكان يترك هذا البت بصفر طوال الوقت.
عندما جاء النور أصابني بالعمى تقريبا.

لقد قام باختيار مواقع البيانات التي يعمل عليها
بالقرب من أعلى الذاكرة
وهي آخر مواقع يمكن للتعليمات أن تعنونها،
وبالتالي بعد أن يتم معالجة آخر معطى،
وزيادة العنوان المخزن داخل التعليمة،
سيؤدي ذلك إلى الطفحان overflow.
سيضيف الـ carry الناتج واحداً إلى
الأوبكود، ليغيره إلى الأوبكود التالي في مجموعة التعليمات
وهو أوبكود تعليمة jump.
وبشكل مؤكد، فإن التعليمة التالية
كانت في العنوان صفر،
وبالتالي يستمر البرنامج بسعادة في طريقه.

لم أستمر في التواصل مع ميل،
ولذا لا أعرف إذا كان قد استسلم لتيار
التغيير الذي اجتاح تكنيكات البرمجة
مذ تلك الأيام البعيدة.
في أي حدث،
أكون متأثرا بما فيه الكفاية بأنني توقفت عن البحث على
التيست المهين،
مخبرا الرئيس الكبير أنني لم أسطتع إيجاده.
لم تبد عليه الدهشة.

عندما تركت الشركة،
كان برنامج البلاك جاك لازال يغش،
إذا قمت بتشغيل مفتاح الـ sense الصحيح،
وأعتقد ان هذا هو ما كان يجب أن يكون عليه.
أنا لم أشعر بالراحة
وأنا اخترق كود لمبرمج حقيقي.