D — Dennis Ritchie \(1941–2011\)

إذا كان Claude Shannon في مدخلك يمثل طبقة الأساس الرياضي والمنطقي للحوسبة، وBill Gates يمثل البرمجيات بوصفها صناعة للحاسوب الشخصي، فإن Dennis Ritchie يمثل شيئًا آخر أكثر مباشرة: لغة البرمجة ونظام التشغيل اللذان شكّلا جزءًا هائلًا من البنية الداخلية للحوسبة الحديثة.

وهنا يصبح إدراجه في مسرد «أعظم 26 مبرمجًا أمريكيًا» أكثر مباشرة من حالة شانون؛ لأن ريتشي كان مبرمجًا ومصمم لغة ومهندس نظم بالمعنى الحرفي، ولم تكن مساهمته مجرد تأثير نظري لاحق على البرمجة.

وقد حصل على جائزة ACM Turing Award عام 1983، كما حصل في العام نفسه على ACM Software System Award، إضافة إلى جائزة ACM Programming Systems and Languages Paper Award عام 1975. جوائز ACM

---

1. C — أهم إرث ريتشي البرمجي

بدأ تطوير C في Bell Labs خلال الفترة 1969–1973، وكانت سنة 1972 هي المرحلة الأكثر كثافة في تطورها، بحسب ريتشي نفسه. نشأت اللغة أساسًا بوصفها لغة لتنفيذ نظام Unix الناشئ. Nokia.com

وهذه النقطة شديدة الأهمية:

C لم تُصمم أولًا كـ«لغة برمجة عامة» بالمعنى الذي نعرفه اليوم.

كانت المشكلة العملية هي:

كيف يمكن بناء نظام تشغيل كامل بلغة أعلى مستوى من لغة التجميع، مع الاحتفاظ بدرجة عالية من التحكم في الآلة؟

كانت لغات سابقة مثل BCPL ثم B جزءًا من السلسلة التي قادت إلى C. ويشرح ريتشي بنفسه أن C تطورت من BCPL عبر B، مع إضافة بنية للأنواع، ثم توسعت تدريجيًا حتى أصبحت لغة واسعة الاستخدام. Nokia.com

وهذا يجعل C حالة نادرة جدًا في تاريخ البرمجة: لغة نشأت من احتياج هندسي محدد، ثم تحولت إلى إحدى اللغات المركزية في تاريخ الحوسبة.

---

2. لماذا كانت C مهمة إلى هذه الدرجة؟

الميزة الأساسية ليست أن C «سهلة»؛ بالعكس، جزء من قوتها التاريخية جاء من قدرتها على العمل قريبًا من الآلة مع توفير بنية أعلى مستوى من Assembly.

يمكن للمبرمج في C أن يتعامل مع:

• الذاكرة مباشرة عبر المؤشرات.
• أنواع البيانات.
• العمليات البتية.
• العناوين.
• البنى struct.
• المصفوفات.
• الاستدعاء الدالي.
• التعامل منخفض المستوى مع النظام.

وفي الوقت نفسه يستطيع كتابة برامج ذات بنية أعلى بكثير من برامج Assembly التقليدية.

وهذا أنتج طبقة وسطى شديدة الأهمية:

Hardware ⇨ Assembly ⇨ C ⇨ Software

ولذلك أصبحت C مناسبة بصورة استثنائية للبرمجيات التي تحتاج إلى أداء مرتفع وتحكم دقيق في الموارد.

---

3. الإنجاز الأعمق: Unix + C

هنا تظهر عظمة ريتشي بصورة أوضح.

C وحدها شيء مهم.

لكن C + Unix شيء مختلف تمامًا.

كان ريتشي جزءًا أساسيًا من الفريق الذي طور Unix في Bell Labs، بالتعاون الوثيق مع Ken Thompson.

والتفصيل التاريخي المهم أن Unix نفسه بدأ في صورة أكثر ارتباطًا بلغة التجميع؛ ثم أعيدت كتابة أجزاء كبيرة منه باستخدام C. ويشرح ريتشي أن الفترة بين 1972 و1973 شهدت تطور C بالتوازي مع تطوير Unix. Nokia.com

وهذا أدى إلى فكرة شديدة التأثير:

نظام تشغيل قابل للنقل بدرجة كبيرة لأنه مكتوب بلغة عالية المستوى نسبيًا.

قبل ذلك كان نظام التشغيل مرتبطًا بصورة وثيقة بمعمارية الجهاز.

أما مع Unix وC، أصبح بالإمكان نقل النظام إلى معمارية أخرى مع إعادة كتابة الجزء الخاص بالآلة بدل إعادة بناء النظام كله من الصفر.

وكان هذا أحد الأسباب المهمة وراء الانتشار اللاحق لـUnix خارج البيئة التي نشأ فيها.

---

4. ريتشي لم يكن «مخترع C» فقط

هذه نقطة أعتقد أنها مهمة جدًا لمسردك.

اختزال Dennis Ritchie إلى:

«مخترع لغة C»

يقلل من حجم إنجازه.

الأدق هو:

مصمم لغة + مبرمج نظم + مطور نظام تشغيل + مؤلف تقني + مهندس برمجيات قابلية نقل.

لأن مشروعه الحقيقي كان منظومة مترابطة:

C ⇨ Unix ⇨ Portability ⇨ Systems Programming

وهذه السلسلة أثرت لاحقًا في أجيال من أنظمة التشغيل واللغات والأدوات البرمجية.

---

5. علاقته بـ Ken Thompson

من الخطأ تاريخيًا فصل ريتشي عن Ken Thompson.

كان Thompson الشخصية الأساسية في البداية في مشروع Unix، بينما أصبح ريتشي شريكًا محوريًا في تطوير C وإعادة صياغة أجزاء من Unix بهذه اللغة.

وفي مقابلة لاحقة، لخّص Thompson الأدوار بصورة مفيدة: قال إنه قام بالنسخ الأولى من Unix، بينما عمل ريتشي أساسًا على اللغة ونظام الإدخال والإخراج، ثم جاءت إعادة الكتابة بلغة C. ACM Hosting

لذلك فإرث Unix هو حالة نموذجية لـالإنجاز الجماعي ذي المساهمات الفردية القابلة للتمييز.

ولا يصح نسب Unix كله إلى ريتشي، كما لا يصح فصل مساهمته في C عن البيئة الهندسية التي نشأ فيها Unix.

---

6. كتابه الأشهر: The C Programming Language

The C Programming Language

1978

المؤلفان:

Brian W. Kernighan & Dennis M. Ritchie

وهو الكتاب المعروف تاريخيًا باسم:

K&R

وصفه ريتشي في مقاله التاريخي عن تطور C بأنه أول وصف واسع الانتشار للغة، وظهر في منتصف المرحلة التي كانت فيها قابلية نقل Unix تُثبت عمليًا. Nokia.com

وهنا توجد مفارقة جميلة في تاريخ البرمجة:

اللغة كانت موجودة قبل الكتاب، لكن الكتاب ساعد في تثبيت الطريقة التي يتعلم بها العالم C ويفهمها.

ولم يكن مجرد manual ضخمًا؛ كان موجزًا نسبيًا ومركزًا، وقدم اللغة من خلال أمثلة وبرامج عملية.

والكتاب مهم أيضًا تاريخيًا لأنه يوضح أن لغة C لم تكن مشروعًا فرديًا بالكامل؛ فاسم Brian Kernighan مرتبط ارتباطًا وثيقًا بتوثيق اللغة وشرحها وتعليمها، بينما كان ريتشي مصممها ومطورها الأساسي.

---

7. كتاب آخر مهم: The Development of the C Language

هذا ليس كتابًا بالمعنى التقليدي، وإنما بحث تاريخي كتبه ريتشي نفسه عام 1993 عن تطور C.

وهو من أهم النصوص الأولية لفهم تاريخ اللغة؛ لأنه لا يقدم C كمنتج مكتمل ظهر فجأة، وإنما يتتبع:

BCPL ⇨ B ⇨ C

والظروف التي نشأت فيها اللغة، والعلاقة بين تطورها وتطور Unix.

والنص مهم جدًا لمسردك تحديدًا لأنك تستطيع من خلاله الانتقال من الأسطورة التاريخية حول C إلى شهادة مصممها نفسه. Nokia.com

---

8. مؤلفات ريتشي الأخرى

إنتاج ريتشي المنشور أقل بكثير من إنتاج أكاديمي مثل شانون، لكنه غني جدًا من ناحية الأوراق التقنية.

من أهم ما يرتبط به:

The C Programming Language

مع Brian Kernighan — 1978، ثم طبعة ثانية عام 1988.

The Development of the C Language

بحث تاريخي/تقني — 1993.

Unix Programmer’s Manual

شارك ريتشي في تطوير وتوثيق منظومة Unix وأدواتها، ضمن العمل الجماعي في Bell Labs.

أبحاث Unix والأنظمة

ترك مع زملائه عددًا من الأوراق التقنية التي توثق بنية Unix وفلسفة النظام وتطور C والبرمجيات المرتبطة بها.

لكن من المهم عدم تحويل كل وثيقة Bell Labs تحمل اسمه إلى «كتاب»؛ فجزء كبير من إرثه الأدبي عبارة عن papers، technical reports، manuals، ومقالات تاريخية.

---

9. الجوائز: الاعتراف لم يكن بلغة C وحدها

حصل ريتشي على:

ACM Turing Award — 1983

بالاشتراك مع Ken Thompson، تقديرًا لإسهاماتهما في تطوير النظرية العامة لأنظمة التشغيل، وبصفة خاصة تطوير Unix. جوائز ACM

كما حصل الاثنان في العام نفسه على:

ACM Software System Award

وهذا مهم جدًا لمسردك؛ لأن الاعتراف الرسمي بإنجاز ريتشي لم يكن متعلقًا فقط بتصميم لغة، بل بمنظومة Unix أيضًا. جوائز ACM

بل إن ACM منحت ريتشي أيضًا Programming Systems and Languages Paper Award عام 1975، قبل جائزة تورنغ بثماني سنوات. جوائز ACM

---

10. أثر C بعد ريتشي

هنا يصبح أثر ريتشي أكبر بكثير من عدد البرامج التي كتبها بنفسه.

نشأت حول C عائلة كاملة من اللغات والتقاليد البرمجية، من بينها:

C ⇨ C++

C ⇨ Objective-C

C ⇨ C# بدرجات مختلفة من التأثير اللغوي والتاريخي

والأهم أن C أصبحت لغة مركزية في:

• أنظمة التشغيل.
• البرمجيات المضمنة.
• البرمجيات منخفضة المستوى.
• المترجمات.
• قواعد البيانات.
• الشبكات.
• الأدوات النظامية.
• البرمجيات التي تتطلب تحكمًا دقيقًا في الذاكرة والموارد.

بل إن كثيرًا من البنية البرمجية التي تقوم عليها أنظمة حديثة لا تزال تعتمد على C بصورة مباشرة أو غير مباشرة.

---

11. نقطة شديدة الأهمية: لماذا لم يجعل ريتشي C «أكثر أمانًا»؟

هذه من أكثر المسائل إثارة للاهتمام عند دراسة C تاريخيًا.

لغة C منحت المبرمج قوة هائلة في التعامل مع الذاكرة والآلة، لكن هذه القوة تأتي مع مسؤولية كبيرة.

أخطاء مثل:

• buffer overflow
• use-after-free
• dangling pointers
• memory corruption

يمكن أن تنشأ من الاستخدام غير الصحيح للذاكرة.

لكن وضع هذه المسائل في سياقها التاريخي مهم: C صُممت في بيئة كانت فيها الكفاءة، والتحكم، وإمكان تنفيذ نظام تشغيل بلغة عالية المستوى نسبيًا أهدافًا مركزية.

لا يصح تقييم تصميم 1972 بالكامل وفق افتراضات أمن البرمجيات الحديثة.

وهنا تكمن إحدى المفارقات الكبرى في إرث ريتشي:

الخصائص التي جعلت C قوية جدًا هي نفسها التي جعلت استخدامها يتطلب انضباطًا شديدًا.

---

12. هل كان Dennis Ritchie مبرمجًا أم عالم حاسوب؟

هذه في رأيي حالة مختلفة عن Claude Shannon.

لذلك فإن وجوده في مسردك لا يحتاج إلى توسيع تعريف «المبرمج» كما احتجنا مع شانون.

بل العكس:

Ritchie هو تقريبًا النموذج المثالي للمبرمج الذي يجمع بين اللغة والنظام والآلة.

---

13. المدخل D داخل مسردك

حتى الآن، بدأت قائمتك بثلاثة أنواع شديدة الاختلاف:

A — Aaron Swartz
الويب المفتوح، أدوات الويب، معايير المعلومات، البرمجة والنشاط الرقمي.

B — Bill Gates
البرمجيات التجارية، الحاسوب الشخصي، BASIC، بناء صناعة البرمجيات.

C — Claude Shannon
المنطق الرقمي، نظرية المعلومات، التشفير، الأساس الرياضي للحوسبة.

D — Dennis Ritchie
C، Unix، برمجة الأنظمة، قابلية النقل، هندسة البرمجيات منخفضة المستوى.

وهذا يجعل بداية المسرد مثيرة جدًا؛ لأنك لا تكرر النوع نفسه من المبرمجين.

وبالنسبة لريتشي تحديدًا، فإن جوهر المدخل ليس «لقد اخترع C».

بل:

لقد ساعد في إنشاء اللغة والنظام والنهج البرمجي الذي أصبحت من خلاله كتابة البرمجيات النظامية المحمولة عملية عملية وقابلة للتوسع.

وهذا يفسر لماذا يُعد إرثه من أكثر الإرثات التصاقًا بالبنية الفعلية للحوسبة الحديثة. Nokia.com

 

 

 

E — Elon Musk \(1971–\)

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

وهذا تحديدًا ما يجعل إدراجه في مسردك يستحق تحليلًا دقيقًا بدل التعامل معه باعتباره «مؤسس شركات تقنية» فقط.

1. البداية: Blastar

أول أثر برمجي موثق له هو لعبة Blastar، التي كتبها وهو في سن مبكرة جدًا، ونُشر كودها في مجلة PC and Office Technology في ديسمبر 1984 تحت اسم E. R. Musk. وتوجد صورة للكود الأصلي المنشور. ويكيميديا كومنز

اللعبة مكتوبة بلغة BASIC لجهاز Spectravideo، وكانت لعبة إطلاق نار فضائية بسيطة: مركبة اللاعب تواجه سفينة فضائية معادية وتطلق عليها النار. ويكيميديا كومنز

لكن أهمية Blastar ليست في تعقيد اللعبة؛ بل في أنها تقدم دليلًا مبكرًا مباشرًا على أن ماسك كان يكتب برامج فعلية في سن صغيرة.

وهناك نقطة تستحق التنبيه: كثير من السير تذكر أنه حصل على 500 دولار مقابل نشر البرنامج، لكن هذا الرقم يعتمد أساسًا على الروايات الثانوية، وهناك مناقشات حول دقته التاريخية. VICE

---

2. Blastar كقطعة برمجية

المثير هنا أن الكود ليس مجرد «برنامج طفل» بالمعنى السطحي.

النسخة الأصلية تتعامل مع:

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

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

لذلك يمكن بالفعل دراسة Blastar بوصفها قطعة برمجية تاريخية، وليس مجرد حكاية عن طفولة ماسك.

لكن من المهم أيضًا عدم المبالغة: اللعبة نفسها بسيطة، ولا تمثل ابتكارًا خوارزميًا كبيرًا في تاريخ ألعاب الفيديو.

---

3. Zip2: هنا يصبح ماسك مبرمجًا محترفًا

التحول الحقيقي في مسيرته البرمجية جاء مع Zip2.

أسس ماسك الشركة مع شقيقه Kimbal Musk وGreg Kouri عام 1995، وكانت تبني برمجيات وخدمات إنترنت تتضمن أدلة للمدن والخرائط والاتجاهات والإعلانات المحلية للصحف. واستحوذت Compaq على الشركة عام 1999. Tesla Investor Relations

وهنا توجد شهادة شديدة الأهمية من ماسك نفسه عن دوره البرمجي المبكر: يقول إنه كتب قاعدة الكود الأولية كاملة بنفسه في بداية Zip2، وأنه كان يبرمج ليلًا بينما يعمل الموقع خلال النهار. The Book of Elon Musk

وهذا أكثر أهمية بكثير من Blastar.

لأننا انتقلنا من:

مراهق يكتب لعبة BASIC

إلى:

مبرمج يبني نظام ويب حقيقيًا من الصفر تقريبًا.

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

---

4. هل كان ماسك هو مبرمج Zip2 الوحيد؟

في البداية، كان له دور برمجي كبير جدًا، لكن لا ينبغي تحويل ذلك إلى القول إنه كتب كل النظام النهائي للشركة.

فمع نمو Zip2 توسع الفريق، ودخل مهندسون وموظفون آخرون في تطوير النظام.

وهذه نقطة مهمة جدًا عند كتابة تاريخ تقني دقيق:

Musk كان المبرمج الرئيسي في المرحلة المبكرة، وليس «المبرمج الوحيد لكل Zip2».

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

---

5. X.com وPayPal

بعد بيع Zip2، شارك ماسك في تأسيس X.com عام 1999، وهي شركة خدمات مالية ودفع عبر الإنترنت، ثم اندمجت مع Confinity، التي أصبح منها PayPal. وتوثق Tesla أن ماسك شارك في تأسيس PayPal قبل استحواذ eBay عليها عام 2002. Tesla Investor Relations

لكن هنا يبدأ الفصل بين المبرمج والمؤسس/المهندس/رجل الأعمال يصبح أكثر ضرورة.

لا يمكن ببساطة القول:

«Elon Musk هو مبرمج PayPal.»

هذا غير دقيق.

الأدق أن نقول إنه كان أحد المؤسسين وقاد جوانب من المنتج والشركة، بينما كان تطوير النظام نفسه عملًا جماعيًا قام به مهندسون ومبرمجون متعددون.

وهذا يختلف جوهريًا عن حالة Dennis Ritchie، الذي يمكن تتبع مساهمته الشخصية مباشرة إلى تصميم C وكتابة البرمجيات النظامية.

---

6. SpaceX: هل يُحسب عمله البرمجي هنا؟

هنا يجب أن نكون أكثر تحفظًا.

SpaceX شركة هندسية وبرمجية هائلة، وتستخدم البرمجيات في:

• التحكم بالمركبات.
• الملاحة.
• التوجيه.
• الاتصالات.
• المحاكاة.
• أنظمة الإطلاق.
• أنظمة الطيران.
• إدارة المركبات.

لكن وجود البرمجيات في SpaceX لا يجعل ماسك مبرمجًا لكل هذه الأنظمة.

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

وتصف Tesla دوره في SpaceX بأنه كان المؤسس والرئيس التنفيذي ورئيس التكنولوجيا منذ 2002. Tesla Investor Relations

إذن، إذا كان مسردك عن أفضل المبرمجين، فمن الخطأ احتساب نجاح Falcon 9 أو Starship بالكامل كإنجاز برمجي شخصي لماسك.

لكن إذا كان المسرد يقيس الأثر التقني للمبرمج عبر حياته المهنية، فإن مسيرته بعد Zip2 تصبح ذات صلة بالسياق، مع ضرورة فصل القيادة التقنية عن كتابة الكود.

---

7. Tesla وNeuralink وغيرها

ينطبق الشيء نفسه على Tesla وNeuralink وThe Boring Company.

Tesla نفسها تصف ماسك بأنه أصبح CEO في 2008، وعضوًا في مجلس الإدارة منذ 2004، كما تربطه بقيادة SpaceX وTesla ومشروعات أخرى. Tesla Investor Relations

لكن هذا لا يساوي تأليف الشيفرة.

ولهذا، في مسردك، أعتقد أن من المهم جدًا أن يكون لديك عمود منفصل مثل:

Direct Programming Contribution

وآخر:

Technical Leadership

لأن ماسك سيكون مختلفًا جدًا في هذين العمودين.

---

8. مؤلفاته؟

هنا توجد مفارقة واضحة مقارنة بغيتس وريتشّي.

Elon Musk ليس له corpus من الكتب التقنية أو البرمجية التي ألّفها بنفسه مثل K&R.

أشهر الكتب عنه هي سير وأعمال صحفية كتبها آخرون، وليست مؤلفات برمجية له.

Elon Musk — Ashlee Vance

2015

سيرة صحفية واسعة عن حياته ومشروعاته، وهي أحد المصادر الأساسية لرواية تاريخ Blastar وZip2 وبدايات SpaceX وTesla.

لكنها ليست من تأليف ماسك.

Elon Musk — Walter Isaacson

2023

سيرة أخرى واسعة مبنية على مقابلات ومتابعة طويلة لحياة ماسك وأعماله.

أيضًا ليست مؤلفًا لماسك.

وهذا مهم جدًا في مسردك: لا ينبغي إدراج هذين الكتابين تحت «مؤلفات Elon Musk»، وإنما تحت Biographies / Sources about him.

---

9. إذن ما هو «Elon Musk المبرمج»؟

إذا عزلنا تمامًا صورته الحالية كرجل أعمال، تظهر لنا شخصية مختلفة:

المرحلة الأولى

Blastar

مبرمج طفل، BASIC، ألعاب، حاسوب منزلي.

المرحلة الثانية

Zip2

مبرمج ويب، قواعد بيانات، خرائط، خدمات إنترنت، تطوير قاعدة كود فعلية.

المرحلة الثالثة

X.com

مؤسس تقني يشارك في بناء منتج مالي عبر الإنترنت، لكن مع انتقال واضح نحو الإدارة والقيادة.

المرحلة الرابعة

SpaceX / Tesla / Neuralink

قائد تقني ومهندس منتجات ومؤسس شركات تقنية، مع تراجع إمكانية نسبة الكود التفصيلي إليه شخصيًا.

وهذا يعطينا خطًا تطوريًا واضحًا:

Programmer → Software Founder → Technical Executive → Technology Entrepreneur

---

10. وهنا تأتي المشكلة الحقيقية في حرف E

إذا كان عنوان قائمتك حرفيًا:

أعظم 26 مبرمجًا أمريكيًا في التاريخ

فإدراج ماسك يحتاج إلى تعريف واضح لما تقصده بـ«مبرمج».

لأن مساهمته البرمجية المباشرة الموثقة قوية في Blastar وخصوصًا Zip2، لكن الجزء الأكبر من شهرته التاريخية اللاحقة لا يأتي من كتابة البرمجيات بنفسه.

وهذا يختلف جذريًا عن:

Dennis Ritchie

الذي يمكن اختزال جزء هائل من إرثه مباشرة إلى:

كتب كودًا ⇨ صمم لغة ⇨ بنى نظامًا ⇨ غيّر البرمجة.

أما ماسك فالمسار هو:

كتب كودًا ⇨ أسس شركة إنترنت ⇨ انتقل إلى قيادة شركات تقنية وهندسية ضخمة ⇨ أصبح تأثيره أكبر بكثير من مقدار الكود الذي يمكن نسبته إليه شخصيًا.

وهذا يجعل Elon Musk من أكثر الأسماء التي ستختبر معيار مسردك نفسه، وليس مجرد مدخل آخر.

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

 

 

 

F — Fred Brooks

Fred Brooks (1931–2022) من الأسماء التي تبدو في البداية «إدارية» أكثر من كونها برمجية، لكن عند النظر إلى ما فعله فعليًا في IBM يتضح أنه من الشخصيات المركزية في تاريخ هندسة البرمجيات، أنظمة التشغيل، ومعمارية الحاسوب. حصل على جائزة تورنغ عام 1999 تحديدًا عن إسهاماته في computer architecture وoperating systems وsoftware engineering. CHM

1. IBM System/360

أهم إنجازاته العملية هو قيادته لمشروع IBM System/360 بين 1961 و1964، ثم انتقاله إلى إدارة تطوير نظام التشغيل OS/360. كان المشروع محاولة لبناء عائلة كاملة من الحواسيب المتوافقة بدل أن يكون لكل جهاز نظام وبرمجيات منفصلة.

وكانت الفكرة ثورية: يمكن للبرنامج أن ينتقل بين نماذج مختلفة من العائلة دون إعادة كتابته بالكامل. IBM نفسها تصف System/360 بأنه غيّر تصور الحاسوب من جهاز منفرد إلى منصة متوافقة. IBM

وهنا تظهر مساهمة Brooks الحقيقية: لم يكن مجرد مدير مشروع بالمعنى الإداري الحديث؛ كان يعمل في الهندسة والمعمارية والبرمجيات معًا. كان مسؤولًا عن تطوير العائلة، ثم تولى إدارة OS/360 عندما أصبحت البرمجيات هي عنق الزجاجة للمشروع. CHM

2. OS/360: البرمجيات بوصفها نظامًا هندسيًا

كان OS/360 أحد أضخم مشاريع البرمجيات في عصره. وعندما تولى Brooks المشروع كان أكثر من ألف مبرمج يعملون عليه بالفعل. CHM

وهذه التجربة هي التي ستنتج لاحقًا أحد أهم النصوص في تاريخ البرمجيات: The Mythical Man-Month.

المثير هنا أن Brooks لم يخرج من المشروع باعتباره «مديرًا نجح في تسليم برنامج»، بل خرج منه بفكرة أعمق: البرمجيات ليست مجرد كمية من أسطر الكود يمكن تسريع إنتاجها بإضافة مزيد من المبرمجين.

وهذا هو أصل Brooks’s Law:

إضافة أفراد إلى مشروع برمجي متأخر تجعله أكثر تأخرًا.

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

---

3. The Mythical Man-Month

نُشر الكتاب عام 1975، وهو أهم مؤلفات Brooks وأحد النصوص المؤسسة لهندسة البرمجيات الحديثة. Computer Pioneers

لكن أهميته لا تأتي من Brooks’s Law وحدها.

الكتاب يحاول الإجابة عن سؤال أكبر:

لماذا يصبح بناء البرمجيات الكبيرة صعبًا بصورة غير متناسبة مع حجم الفريق؟

ويرى Brooks أن الصعوبة الأساسية ليست في كتابة التعليمات البرمجية ذاتها، وإنما في بناء التصور المفاهيمي للنظام، تحديد مواصفاته، تصميمه، واختباره والمحافظة على اتساق أجزائه.

وهذا يقوده إلى فكرة شديدة الأهمية تاريخيًا: البرمجيات الكبيرة تعاني من التعقيد conceptual complexity أكثر مما تعاني من مجرد نقص في العمالة.

ولهذا بقي الكتاب حاضرًا في هندسة البرمجيات بعد عقود من كتابته؛ فهو ليس دليلًا على لغة برمجة معينة، بل تحليل لطبيعة العمل البرمجي الجماعي واسع النطاق.

---

4. «No Silver Bullet»

في 1986 كتب Brooks مقالته الشهيرة No Silver Bullet—Essence and Accidents of Software Engineering، ونُشرت عام 1987.

فكرتها المركزية أكثر عمقًا من مجرد الإدارة: لا توجد تقنية واحدة ستجعل تعقيد البرمجيات يختفي.

يميّز Brooks بين:

• Essential complexity — التعقيد الملازم للمشكلة التي نحاول حلها.
• Accidental complexity — التعقيد الناتج عن الأدوات واللغات والبيئة وطريقة التنفيذ.

وبالتالي، حتى لو تحسنت اللغات والمترجمات والأدوات بدرجة هائلة، سيبقى جزء أساسي من صعوبة البرمجيات نابعًا من تعقيد العالم الذي نحاول نمذجته.

وهذه الفكرة أصبحت من أكثر أفكار Brooks تأثيرًا في فلسفة هندسة البرمجيات. إنفورميت

---

5. ليس OS/360 فقط

مسيرته في IBM بدأت قبل System/360.

عمل Brooks في IBM 7030 Stretch وHarvest، وكان له دور في معمارية Stretch، كما شارك في تطوير نظام للمقاطعة (interrupt system) حصل عليه على براءة اختراع مع Dura Sweeney. CHM

وهنا تظهر نقطة مهمة جدًا في تصنيفه كمبرمج:

Brooks لم يكن «مبرمج تطبيقات» بالمعنى الذي قد نفهمه اليوم، بل كان يعمل في المنطقة التي تتقاطع فيها:

Hardware → Architecture → Operating System → Software Engineering

وهذا بالضبط ما يجعل موقعه التاريخي مميزًا.

---

6. حتى مصطلح Computer Architecture

منسوب إلى Brooks أنه صاغ مصطلح “computer architecture” في سياق العمل على System/360. IBM نفسها تذكر ذلك صراحة. IBM

والأهم من المصطلح هو أنه جسّد مفهومًا جديدًا نسبيًا: أن تصميم الحاسوب ليس مجرد تصميم الدوائر والمعالج، بل تصميم الواجهة والتنظيم الذي يجعل العتاد والبرمجيات يعملان كنظام واحد.

وفي System/360 ارتبط اسمه أيضًا بقرار 8-bit byte ودعم مجموعة الحروف التي أصبحت أساسًا مهمًا لتمثيل النصوص على الحواسيب اللاحقة. ACM SIGGRAPH

---

7. المرحلة الجامعية والرسوميات ثلاثية الأبعاد

بعد IBM، أسس Brooks عام 1964 قسم علوم الحاسوب في University of North Carolina at Chapel Hill وترأسه لعشرين عامًا. CHM

وهنا بدأ فصل مختلف تمامًا من عمله.

ركز على:

• interactive 3-D computer graphics
• virtual environments
• human-computer interaction
• scientific visualization
• computer architecture
• أدوات التصميم والتصور العلمي.

وكانت بعض أعماله في الرسوميات الجزيئية تهدف إلى تمكين العلماء من رؤية البنية ثلاثية الأبعاد للجزيئات والتعامل معها، كما استُخدمت البيئات الافتراضية في تصور المباني والفضاءات. إنفورميت

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

---

8. أهم مؤلفاته

أبرز أعماله المكتوبة:

• Automatic Data Processing (1963، مع Kenneth E. Iverson).
• The Mythical Man-Month: Essays on Software Engineering (1975؛ ثم طبعات موسعة لاحقًا).
• No Silver Bullet—Essence and Accidents of Software Engineering (1987).
• Computer Architecture: Concepts and Evolution، مع Gerrit A. Blaauw، وهو عمل تاريخي/تحليلي مهم في تطور معمارية الحاسوب. Curation من جامعة مانشستر

والفارق بين كتابه عن System/360 وكتاب Ritchie مثلًا مهم جدًا:

Ritchie وثّق كيف تُبنى لغة ونظام؛ Brooks وثّق لماذا يصبح بناء الأنظمة البرمجية الكبيرة صعبًا أصلًا.

---

9. الجوائز والاعتراف

حصل Brooks على عدد كبير من الجوائز، أبرزها:

• National Medal of Technology — 1985 مع Bob Evans وErich Bloch عن System/360. IBM
• IEEE John von Neumann Medal — 1993.
• ACM Turing Award — 1999.
• وكان عضوًا في National Academy of Sciences، إضافة إلى تكريمات ACM وIEEE الأخرى. CHM

وجائزة تورنغ نفسها تلخص مكانته بدقة: computer architecture + operating systems + software engineering، أي أنه يقع عند تقاطع ثلاثة فروع كبرى من تاريخ الحوسبة. جوائز ACM

موقع Fred Brooks في مسردك

وجوده هنا طبيعي جدًا، بل إن دخوله يوضح اتساع معنى «مبرمج» في المسرد بصورة ممتازة.

إذا كان Dennis Ritchie يمثل المبرمج الذي صنع لغةً ونظام تشغيل، فإن Fred Brooks يمثل الشخص الذي نقل البرمجة إلى مستوى آخر: هندسة البرمجيات واسعة النطاق وإدارة تعقيد الأنظمة.

وبالتالي أصبح لدينا حتى الآن خط تاريخي مثير للاهتمام:

C — Claude Shannon → الأساس المنطقي والمعلوماتي
D — Dennis Ritchie → اللغة والنظام
E — Elon Musk → البرمجة المباشرة ثم القيادة التقنية
F — Fred Brooks → الأنظمة واسعة النطاق وهندسة البرمجيات

وهذا يجعل Brooks إضافة منطقية جدًا إلى المسرد، وليس حالة تحتاج إلى تبرير استثنائي.

 

 

G — Gary Kildall

Gary Arlen Kildall (1942–1994) ليس مجرد اسم مناسب لحرف G؛ هو أحد الأسماء التي تكاد تختصر مرحلة كاملة من تاريخ البرمجة: انتقال البرمجيات من كونها ملحقًا خاصًا بالآلة إلى كونها نظامًا مستقلًا يمكن نقله بين أجهزة مختلفة.

وقد كان أثره مباشرًا جدًا: لغة برمجة، مترجمات وأدوات تطوير، نظام تشغيل، مفهوم العزل بين نظام التشغيل والعتاد، ثم شركة برمجيات أصبحت CP/M فيها معيارًا فعليًا للحواسيب الدقيقة قبل هيمنة MS-DOS. CHM

1. PL/M — لغة البرمجة التي سبقت عصر الحاسوب الشخصي

أحد أهم أعمال Kildall المبكرة كان PL/M — Programming Language for Microcomputers، التي طورها في Intel في أوائل السبعينيات.

الفكرة كانت بالغة الأهمية: بدل أن يكتب المبرمج برامج المعالجات الدقيقة مباشرة بلغة التجميع، يمكن استخدام لغة عالية المستوى مخصصة للأنظمة الدقيقة.

وكانت PL/M متأثرة بـPL/I وALGOL وXPL، لكنها صُممت مع إبقاء إمكانية الوصول إلى وظائف المعالج والعتاد. CHM

وهذا مهم لأن Kildall لم يكن يحاول ببساطة جعل البرمجة «أسهل».

كان يحاول حل مشكلة أعمق:

كيف تكتب برمجيات نظامية عالية المستوى دون أن تفقد السيطرة على المعالج؟

وهذه بالضبط المشكلة التي ستصبح لاحقًا مركزية في لغات مثل C.

بل إن المفارقة التاريخية جميلة هنا:

Kildall → PL/M → CP/M

بينما المسار الآخر الذي نعرفه:

Thompson/Ritchie → B/C → Unix

كلاهما يحاول إيجاد مستوى وسيط بين لغة الآلة والبرمجة عالية المستوى.

---

2. CP/M — العمل الذي وضع Kildall في تاريخ أنظمة التشغيل

هنا تأتي مساهمته الأشهر.

طور Kildall CP/M في السبعينيات ليعمل على حواسيب تعتمد على المعالجات الدقيقة، وخصوصًا Intel 8080. وتصفه Computer History Museum بأنه أول نظام تشغيل ناجح تجاريًا للحواسيب الشخصية. CHM

والأهم من مجرد كونه «نظام تشغيل مبكرًا» هو ما فعله معماريًا.

قبل CP/M، كان البرنامج في كثير من الأحيان شديد الارتباط بالحاسوب الذي كُتب له.

أما Kildall فكان يتحرك باتجاه فكرة:

Operating System → Hardware Abstraction → Applications

أي أن البرنامج التطبيقي لا يحتاج إلى معرفة التفاصيل الدقيقة لكل جهاز.

وهذه إحدى الأفكار المؤسسة للحوسبة الشخصية الحديثة.

---

3. الـBIOS — الجزء الذي يجعل CP/M قابلًا للنقل

وهنا تظهر عبقرية Kildall البرمجية بصورة أوضح.

مع انتشار CP/M على أجهزة مختلفة، ظهرت المشكلة الطبيعية:

كل جهاز لديه عتاد مختلف.

فبدل إعادة كتابة النظام كله لكل جهاز، فصل Kildall الجزء المتعلق بالعتاد في طبقة مستقلة عُرفت باسم BIOS — Basic Input/Output System.

وهكذا أصبح الهيكل بصورة مبسطة:

CP/M kernel / system

⇩

BIOS

⇩

Hardware

وهذا سمح لنفس نظام التشغيل بأن ينتقل بين أجهزة متعددة بمجرد تكييف طبقة الإدخال والإخراج الخاصة بالعتاد. digitalresearch.biz

وهذه ليست مجرد حيلة هندسية صغيرة.

إنها فكرة مبكرة جدًا من أفكار abstraction layer التي أصبحت لاحقًا أساسية في تصميم أنظمة التشغيل.

ومن هنا يمكن النظر إلى Kildall باعتباره أحد رواد:

Portable System Software

وليس فقط «صاحب CP/M».

---

4. CP/M كان منصة برمجية، لا مجرد DOS

بحلول أواخر السبعينيات أصبح CP/M معيارًا فعليًا في سوق الحواسيب الدقيقة، وظهرت حوله منظومة واسعة من البرامج. digitalresearch.biz

وهنا تظهر أهمية Kildall بالنسبة إلى تاريخ البرمجة:

لم يصنع نظام تشغيل وحسب؛ صنع بيئة تشغيل يستطيع مطورو البرمجيات البناء عليها.

فأصبح بالإمكان كتابة برامج تستهدف CP/M بدل استهداف كل جهاز منفردًا.

وهذا يخلق طبقة وسيطة:

Hardware

→ CP/M

→ Application software

وهذه البنية هي إحدى اللبنات الأساسية لفكرة software platform التي أصبحت لاحقًا جوهر صناعة البرمجيات.

---

5. لم يتوقف عند نظام التشغيل

Kildall كان مبرمج أدوات أيضًا.

وفق Computer History Museum، عمل على:

• assemblers
• interpreters
• compilers
• programming-language tools
• operating systems

ومن أعماله المبكرة أدوات للمعالجات الدقيقة، ومفسرات BASIC، ومترجم PL/M. CHM

أي أن مساره لم يكن:

مبرمج → كتب CP/M

بل أقرب إلى:

Compiler/Language Developer → Systems Programmer → OS Architect → Software Platform Builder

وهذا يجعل موقعه في مسردك قويًا جدًا.

---

6. العلاقة بين CP/M وMS-DOS

وهنا تدخل واحدة من أشهر التحولات في تاريخ صناعة البرمجيات.

عندما كانت IBM تطور الـPC الأصلي، كان CP/M هو نظام التشغيل البارز في سوق الحواسيب الدقيقة، ولذلك كانت IBM مهتمة بنسخة منه. لكن المفاوضات مع Digital Research لم تنتهِ إلى اتفاق، وأصبحت Microsoft هي المورد لنظام التشغيل الذي تحول إلى PC-DOS/MS-DOS. computinghistory.org.uk

لكن ينبغي عدم اختزال التاريخ إلى العبارة الشعبية:

«Microsoft سرقت CP/M وغيّرت الاسم.»

التاريخ التقني أكثر تعقيدًا من ذلك.

MS-DOS نشأ من 86-DOS/QDOS الذي طوره Tim Paterson في Seattle Computer Products، ثم حصلت Microsoft على حقوقه وطوّرته/سوّقته لـIBM وللمصنعين الآخرين.

في الوقت نفسه، توجد تشابهات واضحة ومهمة تاريخيًا بين CP/M و86-DOS، بما فيها بنية الأوامر وبعض مفاهيم واجهة النظام.

لذلك فإن الأثر الحقيقي لـKildall هنا ليس أن MS-DOS «كان CP/M»، بل أن CP/M كان النموذج البرمجي والتجاري الذي تشكل حوله سوق أنظمة تشغيل الـPC المبكرة.

---

7. المفارقة التاريخية

المفارقة أن Kildall صنع شيئًا كان ناجحًا جدًا قبل IBM PC:

CP/M

ثم جاءت منصة IBM PC وأعادت تشكيل السوق حول نظام آخر.

وبعد ذلك طورت Digital Research:

• CP/M-86
• Concurrent DOS
• DR DOS
• وغيرها من أنظمة التشغيل.

وأصبح DR-DOS منافسًا مباشرًا لـMS-DOS في الثمانينيات والتسعينيات. ويكيبيديا

أي أن Kildall لم يكن مجرد «الشخص الذي خسر أمام Microsoft».

هذه صياغة تختزل مسيرته بصورة شديدة.

الأدق:

Kildall كان أحد صانعي نموذج PC operating system نفسه، ثم أصبح نظامه جزءًا من الصراع الذي أعاد تحديد السوق حول IBM PC وMS-DOS.

---

8. Digital Research

أسس Kildall مع Dorothy McEwen شركة Digital Research لتطوير وتسويق CP/M والبرمجيات المرتبطة به. digitalresearch.biz

وهنا أيضًا يوجد تحول مهم في تاريخ البرمجة.

قبل ذلك كان النموذج الشائع أقرب إلى:

Hardware company → Software accompanies hardware

أما Digital Research فكانت:

Software company → Software is the product

وCP/M كان من أوائل المنتجات التي أثبتت أن نظام التشغيل نفسه يمكن أن يصبح منتجًا تجاريًا مستقلًا يُرخص لعشرات الشركات المصنعة.

وهذه مساهمة تاريخية في اقتصاد البرمجيات بقدر ما هي مساهمة تقنية.

---

9. كتاباته

ليس لدى Kildall قائمة كتب ضخمة مثل بعض الأسماء في المسرد، لكن لديه مواد أصلية مهمة جدًا.

أبرزها:

The History of CP/M — 1980

وهو مقال/مذكرات تقنية نشرها Kildall في Dr. Dobb’s Journal، يروي فيها بنفسه نشأة CP/M وتطوره. US Patent Trademark Search

وقيمته كبيرة لأننا لا نعتمد هنا على مؤرخ يفسر ما فعله Kildall؛ لدينا Kildall نفسه يشرح نشأة النظام.

وله كذلك وثائق PL/M وأدلة تقنية مرتبطة باللغة وأدوات Intel.

---

10. علاقته بـDennis Ritchie

وهنا يصبح وجود الاسمين معًا في مسردك مثيرًا للاهتمام جدًا.

Dennis Ritchie:

C → Unix → Portable Systems

Gary Kildall:

PL/M → CP/M → Portable Microcomputer Systems

كلاهما تعامل مع المشكلة نفسها تقريبًا من زاويتين مختلفتين:

كيف نمنع البرمجيات النظامية من أن تصبح أسيرة للآلة؟

Ritchie وصل إلى ذلك عبر اللغة والنظام.

Kildall وصل إليه عبر لغة الأنظمة + نظام التشغيل + طبقة التجريد عن العتاد.

ولهذا فإن Kildall ليس هامشيًا بالنسبة لتاريخ البرمجة؛ إنه أحد الأشخاص الذين ساعدوا في نقل البرمجيات النظامية من عالم الحواسيب الكبيرة إلى المعالج الدقيق والحاسوب الشخصي.

---

11. مكانته في المسرد

إذا أخذنا الأسماء التي وضعتها حتى الآن، فـKildall يضيف طبقة تاريخية لا يمثلها الآخرون بالضبط:

وأهم ما يميزه أنه مبرمج بصورة مباشرة جدًا: طور لغة، كتب أدوات تطوير، أنشأ نظام تشغيل، وصمم بنية جعلت النظام قابلاً للنقل بين أجهزة متعددة. Computer History Museum يصفه صراحة بأنه من رواد برمجيات الحاسوب الشخصي، وأن CP/M كان لسنوات نظام التشغيل المهيمن على الحواسيب الدقيقة. CHM

لذلك فإن G = Gary Kildall ينسجم مع المسرد بصورة طبيعية جدًا، وربما يكون من أكثر الأسماء وضوحًا فيه من ناحية «المبرمج» بالمعنى المباشر.

 

 

 

 

Hamilton, Margaret

 

H — Margaret Hamilton

Margaret Heafield Hamilton (1936– ) واحدة من أكثر الأسماء اتساقًا مع مسردك حتى الآن؛ ليس فقط لأنها قادت تطوير البرمجيات على متن مركبات Apollo، بل لأنها ساهمت في تحويل البرمجة نفسها من نشاط يُنظر إليه كعمل تابع للهندسة إلى تخصص هندسي له منهجياته الخاصة. ويُنسب إليها على نطاق واسع تعميم مصطلح Software Engineering في هذا السياق. NASA Science

لكن قيمتها التاريخية أكبر من الصورة الشهيرة لها بجوار رزمة كود Apollo.

1. قبل Apollo: كانت مبرمجة بالفعل

بدأت Hamilton في MIT بكتابة برامج للتنبؤ بالطقس مع عالم الأرصاد Edward Lorenz، على حواسيب مثل LGP-30 وPDP-1. ثم عملت في مشروع SAGE للدفاع الجوي، حيث كانت البرمجيات تتعامل مع بيانات الرادار وتميّز إشارات الطائرات عن الضوضاء الإلكترونية. CHM

وهذه المرحلة مهمة جدًا لفهمها: اهتمامها المبكر لم يكن بمجرد «جعل البرنامج يعمل»، بل بما يحدث عندما يفشل البرنامج.

في SAGE كان انهيار البرنامج ظاهرًا ومباشرًا؛ ولذلك بدأت تتعامل مع البرمجيات باعتبارها أنظمة ينبغي فهم سلوكها تحت الخطأ، لا فقط في الحالة الطبيعية.

وهذه الفكرة ستصبح لاحقًا جوهر عملها في Apollo.

---

2. Apollo: البرمجيات التي لا تملك رفاهية الفشل

في MIT Instrumentation Laboratory أصبحت Hamilton مديرة Software Engineering Division، وقادت الفريق المسؤول عن البرمجيات الموجودة على متن Apollo Command Module وLunar Module. NASA Science

وهنا نحن أمام بيئة برمجية استثنائية:

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

ولهذا أصبحت إدارة الأخطاء والاسترداد جزءًا من تصميم البرنامج نفسه، وليس مرحلة لاحقة من الاختبار.

---

3. قصة Apollo 11 ليست مجرد «برنامج أعاد التشغيل»

أشهر مثال هو إنذارات 1201 و1202 أثناء هبوط Apollo 11.

كان Apollo Guidance Computer يتلقى كمية من المهام في لحظة حرجة. وعندما أصبح الحمل أعلى مما يستطيع التعامل معه، لم يكن الحل أن «يتوقف الكمبيوتر».

التصميم البرمجي كان قادرًا على:

اكتشاف الحمل الزائد → تحديد الأولويات → إسقاط المهام الأقل أولوية → الاستمرار في المهام الحرجة.

وهذه نقطة جوهرية في هندسة Hamilton.

فالبرنامج لم يكن مصممًا فقط لكي يعمل في الظروف المثالية، وإنما لكي يفشل بطريقة يمكن السيطرة عليها.

وقد وصفت Computer History Museum هذا النظام بأنه يتضمن برامج لاكتشاف الخطأ وتنفيذ عملية استرداد تعيد إعطاء الأولوية للمهام المهمة. CHM

وهذا يقترب كثيرًا من مفاهيم نعرفها اليوم مثل:

fault tolerance
priority scheduling
graceful degradation
real-time recovery

لكن Hamilton وفريقها كانوا يطبقون هذه الأفكار في نظام فضائي محدود الموارد في الستينيات.

---

4. الإنجاز الحقيقي: تصميم السلوك تحت الفشل

وهنا أرى أن اختزال Hamilton إلى:

«المرأة التي كتبت كود الوصول إلى القمر»

يظلم إنجازها تقنيًا.

الأهم هو أنها ساعدت على تطوير طريقة تفكير في البرمجيات.

السؤال لم يعد:

هل البرنامج يعمل؟

بل:

ماذا سيفعل البرنامج عندما لا تسير الأمور كما صُممت؟

وهذا فرق هائل.

يمكن تمثيل منهجها تقريبًا هكذا:

Normal operation

⇩

Unexpected condition

⇩

Detect

⇩

Prioritize

⇩

Recover

⇩

Continue critical operation

وهذا هو السبب في أن اسم Hamilton مهم جدًا في تاريخ software reliability.

---

5. Software Engineering

مصطلح software engineering كان موجودًا في النقاشات التقنية في تلك الفترة بصورة أوسع، ولذلك الأدق تاريخيًا ألا نقول إن Hamilton «اخترعت المجال من العدم».

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

وهذه نقطة مهمة جدًا في مسردك:

Brooks جاء لاحقًا ليحلل هندسة البرمجيات واسعة النطاق.

أما Hamilton فكانت من الشخصيات التي ساعدت أصلًا على ترسيخ فكرة أن البرمجيات يمكن التعامل معها كعملية هندسية منهجية.

---

6. البرمجة المسبقة للخطأ

من أهم أفكار Hamilton أن اختبار البرنامج بعد بنائه ليس دائمًا أفضل نقطة للتعامل مع الأخطاء.

من تجربتها في Apollo انتقلت إلى محاولة منع الخطأ من الدخول إلى النظام من الأساس.

وهذا قاد لاحقًا إلى أعمالها في:

• formal methods
• system specification
• error prevention
• software reliability
• automated software development

وتذكر NASA أن تجربة Apollo قادت Hamilton وزملاءها إلى تحليل منهجي للأخطاء، وهو ما أصبح أساسًا لأعمال لاحقة في تطوير أنظمة أكثر موثوقية. NASA Spinoff

---

7. Higher Order Software

بعد Apollo، شاركت Hamilton مع Saydean Zeldin في تأسيس Higher Order Software (HOS) عام 1976.

الهدف كان تحويل الدروس المستخلصة من Apollo إلى أدوات ومنهجيات قابلة للاستخدام في مشاريع أخرى.

ومن أعمالها هناك USE.IT، وهو نظام/أداة هندسة برمجيات بمساعدة الحاسوب ركزت على بناء مواصفات متسقة وكاملة، وعلى اكتشاف الأخطاء في مرحلة مبكرة من دورة التطوير. CHM

وهذا امتداد منطقي جدًا لمسارها:

Apollo → دراسة أسباب الأخطاء → نمذجة الأخطاء → منعها قبل التنفيذ.

---

8. Universal Systems Language

لاحقًا أسست Hamilton Technologies عام 1986، وطورت Universal Systems Language (USL) وبيئة 001 Tool Suite.

وهنا أصبحت Hamilton تعمل على مستوى أكثر تجريدًا بكثير من مجرد كتابة البرامج.

فكرة USL هي وصف النظام بطريقة تسمح ببناء العلاقة:

System → Specification → Software

مع محاولة جعل الأخطاء المنطقية وأخطاء الواجهات قابلة للاكتشاف أو المنع قبل مرحلة التنفيذ المتأخرة. CHM

وقد وصفت NASA أدوات Hamilton اللاحقة بأنها تهدف إلى تطوير نماذج وبرمجيات عالية الاعتمادية مع التركيز على منع أخطاء الواجهات والتناقضات في مرحلة مبكرة. NASA Spinoff

وهذا يجعل مسيرتها غير محصورة إطلاقًا في Apollo.

---

9. ماذا عن «الكود الذي يقف أطول منها»؟

الصورة الشهيرة لها بجوار رزمة هائلة من الأوراق هي صورة حقيقية مرتبطة بكود Apollo، لكن هناك تصحيح مهم للصورة الشائعة:

Hamilton لم تكتب وحدها كل ذلك الكود.

كانت قائدة قسم وفريق، والصورة تمثل الكود الذي طورته Hamilton وفريقها للبرمجيات الموجودة على المركبة. NASA Science

وهذا لا يقلل من إنجازها؛ بالعكس، يوضح نوعه بدقة:

Software architect + programmer + team leader + software-engineering theorist.

---

10. الجوائز والمكانة

من أبرز تكريماتها:

• NASA Exceptional Space Act Award — 2003
• Presidential Medal of Freedom — 2016
• Computer History Museum Fellow — 2017. CHM

وتكريم Computer History Museum مهم تحديدًا لمسردك؛ فالمتحف منحها الزمالة عن قيادتها وعملها في برمجيات Apollo وبرمجيات الدفاع، وعن إسهاماتها الأساسية في هندسة البرمجيات. CHM

---

11. مكانها بين الأسماء السابقة

وهنا يصبح ترتيبك حتى H غنيًا جدًا من ناحية تاريخ البرمجة:

والجميل أن Hamilton وBrooks ليسا تكرارًا:

Brooks:
كيف ندير ونبني البرمجيات الكبيرة؟

Hamilton:
كيف نجعل النظام البرمجي يعمل بصورة موثوقة عندما تكون عواقب الخطأ كارثية؟

بينما Kildall ركز على جعل البرمجيات النظامية قابلة للنقل بين آلات مختلفة، وRitchie على اللغة والنظام نفسه.

لذلك Margaret Hamilton تمثل محورًا تاريخيًا مستقلًا بوضوح: هندسة البرمجيات عالية الاعتمادية والبرمجيات الزمنية الحرجة.

 

 

 

 

 

 

 

I — James Gosling

James Gosling هو من الأسماء التي تكاد تختصر وحدها تاريخ لغات البرمجة الحديثة. وإذا كان Dennis Ritchie قد جعل اللغة أداة قريبة من الآلة، وMargaret Hamilton جعلت البرمجيات أكثر موثوقية في الأنظمة الحرجة، فإن Gosling دفع بفكرة أخرى إلى مركز الحوسبة: أن يكون البرنامج نفسه قابلًا للحركة بين الآلات من خلال طبقة تنفيذ مجردة.

وهذا هو جوهر Java، لكنه ليس إلا الجزء الأشهر من مسيرته.

1. قبل Java: كان Gosling مبرمج أنظمة بالفعل

أحد أسباب قوة إدراجه في مسردك أن Java لم تكن بدايته.

في جامعة Carnegie Mellon، طور نسخة من Emacs عُرفت لاحقًا باسم Gosling Emacs، وكتب نظام Unix لأنظمة متعددة المعالجات، كما عمل على محاكاة بيئة PERQ بحيث يمكن تشغيل UCSD Pascal p-code على DEC VAX. وهذه الأخيرة مهمة جدًا لأنها تكشف أن فكرة الآلة الافتراضية لم تظهر عنده فجأة مع Java؛ كان قد تعامل بالفعل مع مشكلة فصل البرنامج عن الجهاز الذي ينفذه. CHM

Gosling Emacs نفسه ليس مجرد نسخة من Emacs الموجود اليوم. كتبه Gosling حوالي 1980، وكان محررًا قابلًا للتمديد وله لغة شبيهة بـLisp، ثم أصبح لاحقًا UniPress Emacs. أرشيف Computer History Museum يحفظ جزءًا من تاريخه وكوده. softwarepreservation.computerhistory.org

وهنا يظهر جانب مهم في شخصيته البرمجية: كان يبني الأدوات التي يحتاج إليها هو نفسه، لا يكتفي باستخدام الأدوات الموجودة.

---

2. Java لم تبدأ باسم Java

بدأ المشروع في Sun Microsystems سنة 1991 ضمن Green Project.

وكان الاسم الأول للغة هو Oak.

الهدف الأصلي لم يكن الويب أصلًا؛ صُممت Oak لبيئات الأجهزة الإلكترونية الاستهلاكية والأنظمة المضمنة. ثم أعيد توجيه المشروع عندما أصبح واضحًا أن الإنترنت يوفر البيئة المناسبة لفكرة اللغة. Oracle Docs

وهذا التحول مهم جدًا في تاريخ البرمجة:

Gosling لم يبدأ بمحاولة صنع «لغة ويب».

بل بدأ بمحاولة حل مشكلة أعمق:

كيف تكتب برنامجًا لا يرتبط ارتباطًا قاتلًا بالمعالج ونظام التشغيل اللذين يعمل عليهما؟

---

3. الابتكار الحقيقي: اللغة + الآلة الافتراضية

هنا تقع مساهمته الأهم.

الـJava التي نعرفها لم تكن مجرد لغة object-oriented جديدة. بنيت حول مفهوم أكثر شمولًا:

Source Code → Java Compiler → Bytecode → JVM → Hardware/OS

بدل:

Source Code → Native Machine Code → Specific Machine

وبالتالي يستطيع البرنامج نفسه، من حيث المبدأ، أن يعمل على أنظمة مختلفة ما دامت تملك تنفيذًا متوافقًا للـJVM.

واللافت أن وثائق Java الرسمية تنسب إلى Gosling تصميم الـVM الأولية التي تطورت منها JVM، والتي صممها سنة 1992 لدعم Oak. Oracle Docs

هذا يجعل مساهمته أكبر بكثير من مجرد «مخترع Java».

إنه أحد الأشخاص الذين ساعدوا على ترسيخ نموذج:

البرنامج لا يحتاج إلى معرفة الآلة التي سينفذ عليها.

---

4. تصميم Java نفسه

كانت Java محاولة للجمع بين عدة خصائص كانت تبدو متعارضة نسبيًا في ذلك الوقت:

• Object-oriented programming
• Automatic memory management
• Garbage collection
• Portability
• Security
• Threads
• Dynamic loading
• Runtime environment
• تقليل الاعتماد على تفاصيل المعالج ونظام التشغيل

وتصف وثيقة The Java Language Environment أهداف اللغة صراحة بأنها تشمل البساطة، وobject orientation، والمتانة والأمان، والحياد المعماري وقابلية النقل، والأداء، والتنفيذ الديناميكي. Oracle

وهنا يظهر تأثير خلفية Gosling السابقة.

فهو لم يأتِ إلى Java باعتباره مصمم syntax فقط؛ بل كان يحمل خبرة في:

operating systems + editors + emulation + compilers + hardware abstraction

ولذلك جاءت Java كـبيئة برمجية متكاملة أكثر من كونها مجرد لغة.

---

5. لكنه لم يصنع Java وحده

وهذه نقطة تاريخية مهمة دون أن تقلل إطلاقًا من موقعه.

الوثائق الرسمية لـJava تقول بوضوح إن اللغة بدأت كـOak من تصميم Gosling، ثم ساهم فيها بصورة كبيرة Ed Frank وPatrick Naughton وJonathan Payne وChris Warth، وبعد إعادة توجيهها إلى الإنترنت وإعادة تسميتها، شارك في تحديد صورتها النهائية Gosling وBill Joy وGuy Steele وRichard Tuck وFrank Yellin وArthur van Hoff، مع مساهمين آخرين. Oracle Docs

لذلك الصياغة الأدق هي:

Gosling هو الشخصية المحورية في conception/design/implementation لـJava، وليس المؤلف البرمجي الوحيد لكل ما أصبح Java لاحقًا.

وهذا متسق أيضًا مع تكريم Computer History Museum له تحديدًا عن conception, design, and implementation of the Java programming language. CHM

---

6. NeWS: مشروع أقل شهرة لكنه شديد الأهمية

قبل أن تصبح Java أشهر أعماله، كان Gosling أحد الأسماء الرئيسية في NeWS — Network extensible Window System.

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

الفكرة كانت جريئة جدًا بالنسبة إلى عصرها:

بدل أن تكون واجهة المستخدم مجرد مجموعة أوامر محلية، يمكن أن تكون بيئة برمجية موزعة وقابلة للتمديد.

ولهذا تضع ACM NeWS وEmacs إلى جانب Java وNetBeans في توصيف مساهمات Gosling في لغات البرمجة والأدوات والبيئات. جوائز ACM

وهذا يكشف شيئًا مهمًا عن مساره:

هو مهتم بالـenvironment الذي يعيش فيه البرنامج، وليس باللغة بمعزل عن بيئة التنفيذ.

---

7. NetBeans

من المشاريع التي ارتبط بها Gosling أيضًا NetBeans، وهو ما يفسر وجوده في توصيف ACM الرسمي لإنجازاته. جوائز ACM

لكن NetBeans مهم هنا ليس لأنه «برنامج آخر مشهور صنعه Gosling»، وإنما لأنه يوضح اتساع مشروعه:

لغة → runtime → أدوات → IDE → بيئة تطوير.

أي أن اهتمامه امتد إلى الطبقات التي تجعل اللغة قابلة للاستخدام الفعلي من قبل مجتمع المطورين.

---

8. الكتب والأعمال المكتوبة

لا يمتلك Gosling corpus كتبًا ضخمة بالمعنى الذي نجده عند Fred Brooks، لكن لديه عدد من النصوص التقنية المهمة.

الأبرز:

The Java Language Environment

1996، مع Henry McGilton.

وهو من أهم الوثائق المبكرة التي تشرح فلسفة Java وأهداف تصميمها: portability، security، robustness، object orientation، garbage collection وغيرها. Oracle

The Java Programming Language Specification

كان Gosling من المؤلفين الأصليين مع Bill Joy وGuy Steele، وهي وثيقة ذات أهمية مختلفة تمامًا عن الكتب التعليمية؛ فهي محاولة رسمية لتحديد اللغة نفسها.

وهذا ينسجم مع طبيعة إنجازه: لم يصنع لغة فحسب، بل شارك في بناء مواصفة يمكن أن يتعامل معها مجتمع برمجي عالمي كمرجع.

---

9. جوائز واعتراف مؤسسي

الاعتراف المؤسسي به قوي جدًا:

• ACM Software System Award — 2002 عن Java وJava runtime system. جوائز ACM
• ACM Fellow — 2013 عن Java وNeWS وEmacs وNetBeans وغيرها من مساهماته في لغات البرمجة والأدوات والبيئات. جوائز ACM
• Computer History Museum Fellow — 2019، مع توصيف التكريم بأنه عن conception, design and implementation of Java. CHM

وهذه الجوائز تعكس شيئًا مهمًا: الاعتراف به ليس قائمًا على شعبية Java فقط، وإنما على مجموعة متراكمة من أعمال الأنظمة واللغات والأدوات.

---

10. ما الذي جعل Java تاريخية إلى هذه الدرجة؟

ليس مجرد syntax.

هناك لغات سبقتها في object orientation، ولغات كانت أكثر أناقة في بعض الجوانب، ولغات كانت أسرع في بعض البيئات.

لكن Java جمعت بين:

لغة + runtime + garbage collection + VM + portability + security + standard libraries + أدوات + ecosystem

ثم جاءت في اللحظة التاريخية المناسبة: صعود الإنترنت والويب.

وهنا تحولت عبارة:

Write Once, Run Anywhere

من شعار تسويقي إلى تصور هندسي واسع الانتشار.

حتى Oracle نفسها، في تاريخ Java الرسمي، تربط انتقال Oak إلى Java بالتحول نحو الإنترنت، ثم انتشارها على أجهزة وأنظمة شديدة التنوع. education.oracle.com

---

11. علاقته بالأسماء السابقة في مسردك

والعلاقة مع Ritchie تحديدًا مثيرة:

Ritchie جعل لغة C قريبة جدًا من الآلة مع الحفاظ على قابلية نقل غير مسبوقة نسبيًا.

Gosling ذهب خطوة أخرى: جعل البرنامج يستهدف آلة افتراضية، بحيث يصبح الفصل عن العتاد جزءًا من نموذج التنفيذ نفسه.

وبهذا يمكن النظر إلى Java كإحدى الإجابات التاريخية على مشكلة ظهرت بصورة مختلفة في مشروع C/Unix:

كيف نجعل البرنامج قابلًا للنقل دون أن نفقد قدرته العملية؟

Ritchie أجاب من خلال لغة صغيرة نسبيًا وطبقة تجريد قريبة من النظام.

Gosling أجاب من خلال لغة + runtime + VM.

---

12. مكان Gosling داخل المسرد

إذا كان Dennis Ritchie يمثل systems programming، وGary Kildall يمثل microcomputer operating systems، وFred Brooks يمثل software engineering at scale، وHamilton تمثل mission-critical software، فإن Gosling يمثل شيئًا مختلفًا:

Programming-language environments

وليس Java وحدها.

أعماله المبكرة في Emacs وNeWS، وتجربته في المحاكاة والأنظمة، ثم Oak/Java وJVM، ثم NetBeans، كلها تنتمي إلى خيط واحد تقريبًا:

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

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