A — Ada Lovelace

1. لماذا تبدأ بها القائمة؟

Ada Lovelace (1815–1852) ليست مجرد اختيار مناسب لحرف A؛ بل هي، من حيث التسلسل التاريخي للبرمجة، واحدة من أكثر الشخصيات منطقية لافتتاح مسرد كهذا. فقد ظهرت في أربعينيات القرن التاسع عشر، قبل وجود الحاسوب الإلكتروني بنحو قرن، ومع ذلك ارتبط اسمها بأحد المفاهيم الجوهرية في البرمجة: كتابة تعليمات منظمة لكي تنفذها آلة قابلة للبرمجة. ويصفها Computer History Museum بأنها صاحبة ملاحظات أضيفت إلى شرح آلة Babbage التحليلية عام 1843، بينما يصفها Science Museum بأنها صاحبة أول خوارزمية منشورة للآلة. CHM

2. الأهم أنها ليست «عالمة رياضيات ظهرت في قصة الحاسوب» فقط

Ada، واسمها عند الميلاد Augusta Ada Byron، كانت الابنة الوحيدة الشرعية للشاعر Lord Byron وAnnabella Milbanke. وقد تلقت تعليمًا رياضيًا خاصًا كان استثنائيًا لامرأة من طبقتها وزمنها. هذه النقطة مهمة لأن تكوينها لم يكن مجرد خلفية أدبية أو اجتماعية؛ الرياضيات أصبحت بالفعل الأداة التي استخدمتها لفهم إمكانات آلة Babbage. CHM

3. اللقاء الذي غيّر مسارها

في عام 1833، وكانت في السابعة عشرة، التقت Charles Babbage وشاهدت نموذجًا عاملًا من Difference Engine. لم يكن انجذابها إلى الآلة مجرد انبهار بآلة ميكانيكية معقدة؛ بدأت تهتم بالرياضيات الكامنة خلفها، ثم انتقلت إلى الآلة الأكثر طموحًا: Analytical Engine. ويذكر Science Museum أنها وصفـت الآلة الأولى بأنها «جوهرة كل الآليات»، ثم اتجه اهتمامها إلى الإمكانات الرياضية للآلة التحليلية. Science Museum Blog

4. هنا يبدأ الفرق الحقيقي بين Babbage وLovelace

كان Babbage مهندس الآلة وصاحب التصميم الأساسي لها، ولذلك سيكون من الخطأ تاريخيًا تقديم Ada باعتبارها اخترعت Analytical Engine. لكن إسهامها كان من نوع آخر: فهم ماذا يمكن أن تعني هذه الآلة إذا تجاوزنا استخدامها كآلة للحساب العددي. فالآلة التي صممها Babbage كانت تتضمن، على المستوى المفاهيمي، عناصر شبيهة بالذاكرة ووحدة المعالجة والإدخال بواسطة البطاقات المثقبة والطباعة. Science Museum Blog

5. التحول من «آلة حاسبة» إلى «آلة عامة»

وهنا أرى أن سبب إدراج Ada في مسرد المبرمجين أقوى بكثير من مجرد العبارة الشهيرة «أول مبرمجة». فقد فهمت أن الآلة يمكنها التعامل مع رموز تمثل أشياء غير الأرقام ذاتها. فالأرقام يمكن أن تمثل حروفًا أو رموزًا أو حتى نغمات موسيقية، وبالتالي يصبح الحساب نفسه وسيلة لمعالجة تمثيلات مجردة. Science Museum يصف هذه النقلة تحديدًا باعتبارها انتقالًا من مجرد number crunching إلى تصور الحاسوب كآلة ذات أغراض عامة. Science Museum Blog

6. «الخوارزمية الأولى» — مع ضرورة الدقة

في ملاحظاتها المنشورة سنة 1843 أدرجت Ada خوارزمية لحساب أعداد Bernoulli باستخدام Analytical Engine. ولهذا توصف كثيرًا بأنها صاحبة أول برنامج حاسوبي منشور. Computer History Museum يعرض بالفعل ما يسميه Bernoulli number algorithm, Ada Lovelace, 1843. CHM

لكن توجد هنا دقة تاريخية مهمة جدًا: ليس من الدقيق القول إن Ada اخترعت مفهوم الخوارزمية أو أن Babbage لم يكتب أي خوارزميات قبلها. فـScience Museum يشير صراحة إلى أن Babbage كان قد رسم خوارزميات مشابهة في دفاتره. ما يميز Ada هو أنها نشرت خوارزمية بصورة مرتبطة بآلة قابلة للبرمجة، ضمن نص متكامل يشرح إمكاناتها. Science Museum Blog

7. لماذا يُعد ذلك «برمجة» أصلًا؟

لأن جوهر البرمجة ليس وجود لغة مثل Python أو C أو Java؛ جوهرها هو تحويل عملية عامة إلى سلسلة تعليمات قابلة للتنفيذ بواسطة آلة. وفي هذا المعنى، فإن عمل Ada يقع داخل النسب التاريخي المباشر للبرمجة، حتى وإن كانت الآلة ميكانيكية ولم تُبنَ كاملة في حياتها. وهذا تحديدًا ما يجعل وضعها في مسرد للمبرمجين أكثر قابلية للدفاع عنه من تصنيفها فقط تحت «الرياضيات». CHM

8. علاقتها بالبرمجة الحديثة

المدهش في Ada ليس فقط البرنامج نفسه، وإنما التصور النظري للآلة التي سينفذ عليها البرنامج. لقد تعاملت مع Analytical Engine باعتبارها شيئًا يمكنه معالجة عمليات رمزية عامة، وليس مجرد جهاز لإجراء عمليات حسابية أسرع. لذلك يرى Science Museum أن أفكارها كانت سابقة بصورة لافتة للتطور اللاحق للحوسبة، خصوصًا في تصور استخدام الحاسوب في الموسيقى والفنون والمعالجة الرمزية. Science Museum Blog

9. البعد الموسيقي مهم جدًا

في ملاحظاتها طرحت إمكانية استخدام الآلة في إنتاج تراكيب موسيقية معقدة إذا أمكن التعبير عن العلاقات الرياضية في الموسيقى بطريقة مناسبة. هذه ليست ملاحظة جانبية؛ إنها تكشف أن Ada كانت تفكر في التمثيل representation: إذا أمكن تحويل شيء إلى صورة عددية/رمزية، فإن الآلة تستطيع معالجة تلك الصورة. وهذه الفكرة أصبحت لاحقًا من أسس الحوسبة الرقمية: النص والصوت والصورة والفيديو كلها يمكن تمثيلها داخل أنظمة حسابية. Science Museum Blog

10. لذلك فإسهامها ليس «كتابة كود» بالمفهوم المعاصر

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

11. علاقتها بـ Luigi Menabrea

العمل الأشهر لها لم يبدأ كنص مستقل كتبته من الصفر. فقد ترجمت إلى الإنجليزية مقال Luigi Federico Menabrea عن Analytical Engine، ثم أضافت إليه مجموعة طويلة من ملاحظاتها الخاصة. والأهم أن ملاحظاتها أصبحت أكبر بكثير من النص الأصلي؛ Computer History Museum يذكر أن الملاحظات امتدت إلى نحو ثلاثة أضعاف طول المقال الذي ترجمته. CHM

12. وهنا تظهر أهمية «الملاحظات» نفسها

عنوان العمل المنشور هو:

Sketch of the Analytical Engine, invented by Charles Babbage, by L. F. Menabrea … with Notes upon the Memoir by the Translator

أي أن كلمة Notes ليست ملحقًا هامشيًا. إنها الجزء الذي أصبحت Ada معروفة بسببه تاريخيًا. وفي هذه الملاحظات نجد الخوارزمية، ومناقشة طبيعة الآلة، وإمكان التعامل مع الرموز، والتأمل في تطبيقات تتجاوز الحساب العددي. النسخة المنشورة تعود إلى 1843 في Taylor’s Scientific Memoirs. أرشيف تاريخ الحاسوب

13. هل كانت فعلًا «أول مبرمجة في التاريخ»؟

بوصفها صاحبة أول خوارزمية منشورة مخصصة لآلة قابلة للبرمجة: نعم، هذا وصف تاريخي قوي جدًا لها. أما بصيغة «أول شخص في التاريخ فكر في خوارزمية لحاسوب»، فالأمر أكثر تعقيدًا بسبب أعمال Babbage السابقة. لذلك الصياغة الأكثر دقة هي أن Ada كانت أول شخصية ارتبطت بصورة موثقة بمنشور برمجي منشور ومفصل لآلة حوسبة عامة التصميم، مع وجود أسبقية جزئية لـBabbage في بعض الخوارزميات. وهذا لا يقلل من أهميتها؛ بل يجعل توصيفها التاريخي أكثر دقة. Science Museum Blog

14. مكانتها داخل مسردك تحديدًا

إذا كان معيار المسرد هو «أعظم المبرمجين البريطانيين» وليس «أعظم علماء الحاسوب البريطانيين»، فإن Ada حالة شديدة الأهمية؛ لأنها تمثل الطبقة الجنينية للبرمجة نفسها. وبالترتيب الذي اخترته، وجودها في A يخلق بداية تاريخية ممتازة: قبل Turing، قبل Wilkes، قبل Strachey، قبل لغات البرمجة الحديثة، هناك Ada التي تعاملت مع فكرة البرنامج والآلة العامة في القرن التاسع عشر.

والأكثر إثارة أن المسرد إذا انتهى لاحقًا بأسماء مثل Tim Berners-Lee أو مبرمجي الأنظمة واللغات المعاصرين، فإن Ada ستكون بمثابة نقطة البداية التي يمكن أن يُرسم منها خط كامل: الخوارزمية ⇨ الآلة القابلة للبرمجة ⇨ الحاسوب العام ⇨ البرمجيات ⇨ لغات البرمجة ⇨ الشبكات والويب.

أهم أعمال Ada Lovelace

هنا توجد ملاحظة مهمة جدًا بالنسبة لصيغة مسردك: Ada لم تؤلف كتبًا مستقلة بالمعنى المعتاد. إنتاجها البرمجي/العلمي الأساسي كان في صورة ترجمة علمية وملاحظات ومراسلات. ولذلك لا يصح أن أضع لك قائمة كتب وهمية باسمها لمجرد أن نختم كل شخصية بالكتب.

1. Sketch of the Analytical Engine… with Notes upon the Memoir by the Translator — 1843

هذا هو العمل المركزي في إرث Ada، وهو ترجمة مقال Menabrea مع ملاحظاتها المطولة. وفيه توجد خوارزمية Bernoulli الشهيرة، ولذلك يمكن اعتباره أهم «منشور برمجي» في مسيرتها. أرشيف تاريخ الحاسوب

2. خوارزمية Bernoulli Numbers — 1843

ليست كتابًا مستقلًا، بل جزء من الملاحظات السابقة، لكنها أهم قطعة برمجية مرتبطة باسم Ada. ولهذا تستحق أن تُعامل كعمل مستقل في المسرد عند الحديث عن إرثها البرمجي. CHM

3. مراسلات Ada Lovelace العلمية

تركت أيضًا مراسلات كثيرة تكشف تطور تفكيرها الرياضي والعلمي، ومنها مراسلاتها مع Babbage وغيره من العلماء. Science Museum يشير إلى أن رسائلها كانت وسيلة مهمة لتوثيق اهتماماتها العلمية وعملها على Analytical Engine. Science Museum Blog

الحكم على إدراجها في المسرد

Ada Lovelace ليست مجرد اختيار صحيح لحرف A؛ بل هي من الحالات التي تجعل تعريف «المبرمج» نفسه تاريخيًا مهمًا.

هي لم تبنِ الحاسوب، ولم تكن صاحبة Analytical Engine، ولم تكن أول من وضع كل خوارزمية مرتبطة به. لكن إسهامها الأكثر أهمية كان تحويل الآلة من فكرة حسابية إلى مفهوم برمجي أوسع: آلة تنفذ إجراءات رمزية عامة وفق تعليمات منظمة.

ولهذا أضعها في مسردك بوصفها أحد الجذور المؤسسة للبرمجة البريطانية والعالمية، مع ضرورة الحفاظ على التمييز التاريخي بينها وبين Babbage بدل تحويل قصة الاثنين إلى أسطورة «المبرمجة التي اخترعت الحاسوب». Science Museum Blog

Babbage

B — Charles Babbage

1. إذا كانت Ada هي بداية المسرد، فإن Babbage هو البنية التي جعلت ظهورها ممكنًا

Charles Babbage (1791–1871) حالة مختلفة تمامًا عن Ada Lovelace. فإذا كانت Ada تمثل مبكرًا جدًا مفهوم البرنامج والخوارزمية، فإن Babbage يمثل الانتقال إلى شيء أكبر: تصميم آلة حوسبة عامة قابلة للبرمجة. ولذلك فإن وضعه مباشرة بعد Ada في مسردك ليس مجرد ترتيب أبجدي؛ بل يصنع بالفعل افتتاحية تاريخية متماسكة: Ada ⇨ Babbage. فقد صمم Babbage آلتين رئيسيتين: Difference Engine وAnalytical Engine، وتصفه Computer History Museum بأنه رائد حاسوبي صمم أولى آلات الحوسبة الآلية. CHM

2. بدأ من مشكلة تبدو اليوم بسيطة جدًا

المشكلة التي دفعت Babbage إلى مشروعه لم تكن «اختراع الكمبيوتر» بمعناه الحديث، بل الأخطاء البشرية في الجداول الرياضية. كانت الجداول الفلكية والملاحية والهندسية والمالية تعتمد على حسابات بشرية ضخمة، والخطأ في رقم واحد يمكن أن يفسد سلسلة كاملة من النتائج. بعد رؤيته للأخطاء المتكررة في الجداول، بدأ يفكر في نقل الحساب من الإنسان إلى الآلة. ويصف Computer History Museum هذه اللحظة باعتبارها نقطة انطلاق عمله في الحوسبة الآلية. CHM

3. Difference Engine كانت ثورة، لكنها ليست حاسوبًا عامًا

في عام 1821 تقريبًا بدأ مشروع Difference Engine، وهي آلة مخصصة لحساب الجداول باستخدام طريقة الفروق المنتهية. العبقرية هنا هندسية بقدر ما هي رياضية: يمكن تنفيذ العمليات اللازمة بواسطة الجمع المتكرر بدل الاعتماد على الضرب والقسمة الميكانيكيين الأكثر تعقيدًا. ولهذا تميزت الآلة بإمكان أتمتة إنتاج الجداول. لكن Computer History Museum يشدد على أنها كانت في جوهرها آلة حاسبة متخصصة، وليست حاسوبًا عامًا. CHM

4. المفارقة أن الجزء الذي بُني أثبت أن الفكرة كانت قابلة للتحقيق

في 1832 أُنجز جزء من Difference Engine، وهو جزء صغير لكنه عامل، وأصبح برهانًا عمليًا على سلامة التصميم. Computer History Museum يصفه بأنه أول حاسب آلي ناجح بالمعنى التاريخي للآلة الحاسبة الآلية، وأحد أعظم أمثلة الهندسة الدقيقة في عصره. المشكلة لم تكن إذن أن Babbage تخيل آلة مستحيلة تمامًا؛ بل أن تحويل التصميم إلى آلة كاملة كان أصعب بكثير من إثبات المبدأ. CHM

5. ثم حدثت القفزة الكبرى: Analytical Engine

في 1834، وبعد تعثر مشروع Difference Engine، بدأ Babbage التفكير في آلة مختلفة جذريًا: Analytical Engine. هنا بالذات يصبح من المشروع إدخاله في تاريخ البرمجة وليس تاريخ الآلات الحاسبة فقط. Computer History Museum يصفها بأنها general-purpose programmable computing machine، ويرى في تصميمها انتقالًا من الحساب الميكانيكي إلى الحوسبة العامة. CHM

هذه النقلة هي أعظم ما في Babbage.

فهو لم يقل ببساطة: «سأجعل آلة تحسب الأرقام بصورة أسرع». بل انتقل إلى سؤال أكثر عمقًا:

هل يمكن بناء آلة تستطيع تنفيذ عمليات مختلفة تبعًا لتعليمات تُعطى لها؟

وهذا هو السؤال الذي يقع في قلب البرمجة.

6. بنية Analytical Engine تكاد تبدو كأنها مخطط لحاسوب لاحق

تصميم Babbage تضمن عناصر أصبحت مألوفة جدًا في الحاسوب الحديث: وحدة لإجراء العمليات الحسابية، وذاكرة لتخزين القيم، وآلية للتحكم في تسلسل العمليات، وإدخال التعليمات بواسطة البطاقات المثقبة المستوحاة من نظام Jacquard. ولهذا فإن وصف Analytical Engine بأنها مجرد «آلة حساب كبيرة» يظلمها بشدة. كانت محاولة لبناء نظام حوسبة قابل لإعادة البرمجة قبل ظهور الإلكترونيات بأكثر من قرن. CHM

7. وهنا يصبح Babbage أحد أهم أسلاف هندسة الحاسوب

يمكن النظر إلى Analytical Engine بوصفها معمارية حاسوبية ميكانيكية أكثر منها آلة بعينها. فكرة فصل تخزين القيم عن تنفيذ العمليات، ثم التحكم في سلسلة التعليمات، تعني أن Babbage كان يفكر في الآلة على مستوى architecture وليس على مستوى وظيفة واحدة.

وهذا مهم جدًا في تقييمه كمبرمج: هو لم يكن مجرد شخص يكتب تعليمات لآلة؛ لقد صمم الآلة التي تجعل البرامج ممكنة أصلًا.

وهذا يضعه في طبقة مختلفة عن Ada، وليس بالضرورة طبقة أدنى أو أعلى: Ada تمثل البرنامج، بينما Babbage يمثل الآلة القابلة للبرمجة.

8. لكنه لم يكن ينتظر Ada كي يفكر في الخوارزميات

وهذه نقطة مهمة جدًا بعد تحليلنا لـAda. Babbage نفسه كان يعمل على إجراءات حسابية منظمة، وتوجد في أوراقه خوارزميات مرتبطة بآلاته قبل نشر Notes الخاصة بـAda. لذلك فإن الرواية البسيطة «Babbage اخترع الآلة وAda اخترعت البرمجة» غير دقيقة.

الأدق أن Babbage كان مهندس النظام الحسابي والآلة والخوارزميات المبكرة، بينما قدمت Ada صياغة منشورة وموسعة جدًا لإمكانات الآلة وبرنامجها. Computer History Museum يذكر أن Notes الخاصة بـAda تضمنت أول أوصاف منشورة من ذلك النوع للإجراءات التي تنفذها الآلة. CHM

9. علاقته بـAda تكشف اختلاف نوعي الإسهامين

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

Babbage ⇨ تصميم الآلة

Lovelace ⇨ صياغة الخوارزمية والبرنامج وتوسيع مفهوم ما يمكن للآلة معالجته

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

10. أكثر ما يثير الإعجاب: أن التصميم ظل قابلًا للبناء بعد أكثر من قرن

لم يكن Babbage محظوظًا بما يكفي لرؤية Difference Engine No. 2 تعمل كاملة. لكنه ترك تصميمًا تفصيليًا بصورة تكفي لأن يبني Science Museum آلة كاملة وفق مخططه في العصر الحديث.

في عام 2002 اكتمل بناء Difference Engine No. 2، التي تتكون من نحو 8,000 جزء، وتزن حوالي خمسة أطنان، وتعمل وفق التصميم الأصلي. وهذه ليست إعادة تصور تقريبية لفكرته؛ بل بناء مخلص للمخططات. CHM

هذه واحدة من أقوى الشهادات المادية على جودة عمله الهندسي.

11. لكن Babbage لم يكن «ناجحًا» بالمعنى التقليدي

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

لم يبنِ Babbage آلة حاسوب كاملة في حياته.

فشل Difference Engine كمشروع كامل، ولم تُبنَ Analytical Engine إطلاقًا. وتذكر Computer History Museum مجموعة عوامل وراء ذلك: ارتفاع التكاليف، الحاجة إلى دقة تصنيع استثنائية، الخلاف مع المهندس Joseph Clement، تقلب التمويل، المشكلات السياسية، وتأخر المشروع سنوات طويلة. CHM

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

12. شخصيته جزء من تفسير هذا المصير

Babbage كان شخصية شديدة القوة فكريًا، لكنها صعبة سياسيًا ومهنيًا. كان ينتقد المؤسسات العلمية بصورة حادة، ويميل إلى الصدام، ولم يكن بارعًا في تسويق مشروعه أو بناء التوافق حوله. Computer History Museum يصفه بأنه كان سريع الغضب، شديد المبدئية، وقادرًا على شن هجمات علنية قاسية على خصومه. CHM

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

13. والأهم أنه كان أوسع من الحوسبة

لو صنفنا Babbage فقط باعتباره «مخترع الكمبيوتر»، فسوف نفقد جزءًا كبيرًا من شخصيته الفكرية. كان رياضيًا، مهندسًا، اقتصاديًا، مصلحًا للعلم، مخترعًا، وكاتبًا. يذكر Computer History Museum أنه نشر بين 1813 و1868 ستة كتب كاملة ونحو تسعين بحثًا، وأن اهتماماته امتدت من الإشارات والمنارات إلى العمل الصناعي والعملة العشرية والسكك الحديدية والتشفير وغيرها. CHM

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

14. كتابه عن الاقتصاد الصناعي مهم جدًا لفهم طريقة تفكيره

في On the Economy of Machinery and Manufactures لم يتعامل Babbage مع الآلات كأجهزة منفردة، بل درس تقسيم العمل، تنظيم المصانع، استخدام الآلات، تكلفة الإنتاج، المهارات، وكفاءة العمليات. وهذا الكتاب مهم لأنه يكشف أن تفكيره في Analytical Engine لم يكن منفصلًا عن رؤيته الأوسع: تحويل العمليات المنظمة إلى أنظمة يمكن تحليلها وأتمتتها. وتدرجه University of Minnesota ضمن أبرز منشوراته. College of Science and Engineering

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

15. The Ninth Bridgewater Treatise يكشف جانبًا فلسفيًا آخر

في 1837 نشر Babbage The Ninth Bridgewater Treatise: A Fragment. ظاهريًا يبدو الكتاب بعيدًا عن الحوسبة، لأنه يتناول العلم والدين والطبيعة والقوانين والخلق والمعجزات. لكن توجد فيه أيضًا ملاحظات عن Calculating Engine. وتظهر فهرسة الكتاب أن أحد أقسام الملاحظات مخصص للآلة الحاسبة. Google Books

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

16. Passages from the Life of a Philosopher مهم بوصفه وثيقة عن عقل المبرمج-المخترع

في 1864 نشر Babbage مذكراته Passages from the Life of a Philosopher. وهو من أهم مصادر فهم شخصيته ومشروعاته، ويتضمن وصفًا لحياته واختراعاته وتجربته مع الآلات الحاسبة. النسخة الأولى صدرت في لندن عن Longman عام 1864، وتضم صورة أمامية مرتبطة بـDifference Engine.

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

أهم مؤلفات Charles Babbage

1. A Letter to Sir Humphry Davy… on the Application of Machinery to the Purpose of Calculating and Printing Mathematical Tables — 1822

من أقدم النصوص المهمة في مشروعه الحوسبي؛ يعرض فيه فكرة استخدام الآلات لأتمتة الحساب وطباعة الجداول. وتدرجه Online Books Page ضمن أعماله المنشورة. مكتبة بنسلفانيا للكتب الإلكترونية

2. Table of Logarithms of the Natural Numbers from 1 to 108,000 — 1827

عمل مرتبط مباشرة بمشكلة الجداول الحسابية التي كانت منطلق مشروعه في الأتمتة. وتدرجه قائمة منشورات Charles Babbage Institute ضمن أعماله الأساسية. College of Science and Engineering

3. Reflections on the Decline of Science in England, and on Some of Its Causes — 1830

كتاب يكشف اهتمام Babbage بإصلاح المؤسسة العلمية البريطانية، وليس بمجرد الاختراع التقني. وهو من أعماله الأساسية المدرجة في قوائم منشوراته. College of Science and Engineering

4. On the Economy of Machinery and Manufactures — 1832

أهم أعماله في الاقتصاد الصناعي وتحليل الآلات والتصنيع. وهو أيضًا من أكثر كتبه ارتباطًا بفلسفة Babbage الأوسع حول تفكيك العمليات وتحليلها وأتمتتها. College of Science and Engineering

5. The Ninth Bridgewater Treatise: A Fragment — 1837

عمل فلسفي/علمي غير تقني ظاهريًا، لكنه مهم لفهم طريقته في التفكير في القوانين والآلة والحساب. صدر أول مرة عام 1837 عن John Murray. Google Books

6. Passages from the Life of a Philosopher — 1864

وهو أهم كتبه السيرية والتأملية، ومن أهم الوثائق المباشرة لفهم مشاريعه وآرائه وشخصيته. صدرت طبعته الأولى عام 1864.

الخلاصة داخل مسردك

Charles Babbage اختيار بالغ القوة لحرف B.

بل إن وضعه بعد Ada تحديدًا ينتج ثنائيًا تاريخيًا ممتازًا:

Ada Lovelace = البرنامج والخوارزمية المبكرة
Charles Babbage = الآلة العامة القابلة للبرمجة

لكن إذا أردنا تحديد مركز ثقل Babbage بدقة، فلن أختزله في «أبو الكمبيوتر». أهم إنجاز له هو أنه حوّل فكرة الحساب الآلي من آلة متخصصة لإنتاج الجداول إلى تصور لآلة عامة يمكن تغيير سلوكها بواسطة التعليمات. ولهذا فإن Analytical Engine هي قلب إرثه، أكثر من Difference Engine نفسها. CHM

ومن هذه الزاوية، فإن Babbage ليس فقط مبرمجًا مبكرًا؛ إنه أحد الأشخاص الذين جعلوا مفهوم «البرمجة» ممكنًا من الناحية المعمارية أصلًا.

C — Christopher Strachey

1. الاسم الذي ينقل المسرد من «رواد الحوسبة» إلى المبرمجين بالمعنى الحديث

Christopher Strachey (1916–1975) اختيار شديد الأهمية لحرف C، وربما أكثر أهمية مما يوحي به شهرته العامة. فإذا كان Babbage يمثل مرحلة اختراع الآلة القابلة للبرمجة، فإن Strachey يمثل مرحلة مختلفة تمامًا: تحويل البرمجة إلى موضوع علمي مستقل له لغاته، ودلالاته، ونظرياته، وأنظمة تشغيله، وممارساته الخاصة. جامعة أكسفورد تصفه بأنه رائد في علوم الحاسوب، ومؤسس Programming Research Group، وأن أثره النظري الأكثر دوامًا تمثل في تأسيسه، مع Dana Scott، لنهج الدلالات التصويرية/الدلالات الدلالية (denotational semantics) للغات البرمجة. قسم علوم الحاسب

وهذا يجعل وجوده في قائمتك مهمًا جدًا؛ لأن المسرد ينتقل معه من Lovelace ⇨ Babbage ⇨ Strachey إلى ثلاثة مستويات مختلفة تمامًا من تاريخ البرمجة.

2. تكوينه كان غير تقني بالمعنى الضيق

وُلد Strachey عام 1916 لعائلة بريطانية فكرية وفنية بارزة، وكان عمه الكاتب Lytton Strachey من شخصيات Bloomsbury الشهيرة. درس في Cambridge، وعمل خلال الحرب في مجال الرادار، ثم عمل مدرسًا قبل أن يدخل الحوسبة بصورة جدية في أوائل خمسينيات القرن العشرين. معهد الرياضيات

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

3. أولى مشاريعه كشفت مبكرًا طبيعة عقله البرمجية

في أوائل الخمسينيات بدأ العمل على الحواسيب البريطانية المبكرة، ومن أشهر أعماله برنامج لعبة الداما (draughts) للحاسوب Pilot ACE عام 1951. وتذكر أكسفورد هذا البرنامج صراحة باعتباره أحد برامجه المعقدة المبكرة. قسم علوم الحاسب

وهنا تظهر نقطة مهمة جدًا بالنسبة إلى مسردك: Strachey لم يكن مجرد منظّر كتب عن البرمجة من الخارج. لقد كان مبرمجًا فعليًا.

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

4. وهناك قصة شهيرة أخرى: برنامج الحب

Strachey ارتبط أيضًا بأحد أكثر البرامج غرابة وطرافة في تاريخ الحوسبة المبكرة، وهو Love Letter Generator، وهو برنامج كان يولد رسائل حب باستخدام مخزون من العبارات والقوالب.

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

وهذه النقطة ستصبح لاحقًا مهمة جدًا عند النظر إلى تاريخ البرمجة: البرنامج لا يحتاج إلى أن يكون «حاسبة أرقام». يمكنه أن يعالج لغة ورموزًا وبنى مجردة.

5. لكن أهميته الحقيقية تبدأ عندما بدأ يفكر في «ما هي البرمجة؟»

هذه ربما أهم نقطة في مسيرته كلها.

Strachey لم يكن راضيًا عن الفصل بين الشخص الذي يبني النظام والشخص الذي يدرس الأسس النظرية له. كان يرى أن هناك انفصالًا ضارًا بين الممارسة البرمجية والنظرية الرياضية.

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

هذه ليست مجرد فلسفة شخصية؛ لقد أصبحت برنامجًا مؤسسيًا عند Strachey.

6. ومن هنا جاء Programming Research Group

في 1965 أصبح Strachey أول قائد لـ Programming Research Group (PRG) في Oxford University Computing Laboratory، ثم أصبح أول Professor of Computation في أكسفورد. قسم علوم الحاسب

وهنا يمكن رؤية أهميته التاريخية بصورة أوضح:

لم يؤسس فقط برنامجًا أو لغة.

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

ومن هذه البيئة خرجت أبحاث أثرت في لغات البرمجة، والدلالات، والأنظمة، والمترجمات، ونظرية الأنواع، والبرمجة الوظيفية.

7. CPL هو أحد أكبر أسباب وجوده في قائمتك

كان Strachey أهم مساهم في تصميم وتنفيذ CPL — Combined Programming Language، وهو مشروع بدأ في Cambridge في أوائل الستينيات بالتعاون مع Peter Landin وآخرين. وتصف أكسفورد Strachey بأنه أهم مساهم في تصميم وتنفيذ اللغة. بودكاست أكسفورد

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

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

8. CPL لم تصبح لغة ناجحة تجاريًا

وهذا من أجمل الأمثلة التي تجعل تقييم Strachey أكثر جدية.

مشروع CPL نفسه لم ينتج مترجمًا عمليًا usable compiler بالصورة التي كان الفريق يريدها. وتذكر أكسفورد أن اللغة أصبحت كبيرة ومعقدة جدًا، ولم يكن هناك عدد كافٍ من الأشخاص لتنفيذ المترجم، كما اضطر المشروع إلى الانتقال من EDSAC 2 إلى Titan أثناء العمل. بودكاست أكسفورد

لكن المفارقة أن فشل CPL في الانتشار لا يعني فشل أفكارها.

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

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

9. BCPL هو الامتداد الأكثر أهمية

من رحم CPL ظهرت لاحقًا BCPL التي طورها Martin Richards، مع احتفاظها بجزء مهم من الأفكار التي نشأت في مشروع CPL.

وتوثق Computer History Museum تاريخ BCPL، كما توثق أعمال Martin Richards حول كيفية تطور BCPL من CPL. Software Preservation Group

والأهم أن Strachey نفسه حافظ على علاقة وثيقة بـBCPL؛ فقد قام بتشغيلها على KDF9 ثم استخدمها في بيئة Programming Research Group، كما ارتبط بها في تطوير نظام التشغيل OS6. قسم علوم الحاسب

وبالتالي فإن خط:

CPL ⇨ BCPL ⇨ عائلة لغات لاحقة

هو أحد أهم خطوط التأثير التي تجعل اسم Strachey يتجاوز مجرد التاريخ الأكاديمي للبرمجة.

10. ثم تأتي مساهمته الأعمق: Denotational Semantics

إذا كان CPL يفسر جانب Strachey المبرمج ومصمم اللغات، فإن denotational semantics تفسر لماذا أصبح اسمه حاضرًا في النظرية الحديثة للغات البرمجة.

بالتعاون مع Dana Scott، أسس Strachey النهج الذي أصبح يعرف باسم denotational semantics: محاولة إعطاء البرامج واللغات البرمجية معنى رياضيًا دقيقًا، بحيث لا يكون معنى البرنامج مجرد «ما يحدث عندما نشغله»، بل يمكن وصفه بطريقة رياضية مجردة.

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

11. هذه النقطة تجعل تأثيره يتجاوز لغة بعينها

هناك مبرمجون يتركون لغة.

وهناك مبرمجون يتركون نظام تشغيل.

وهناك مبرمجون يتركون خوارزمية.

Strachey ترك شيئًا مختلفًا: طريقة للتفكير في معنى البرنامج نفسه.

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

فبدل أن يكون السؤال:

ماذا يفعل هذا البرنامج عندما أشغله؟

يمكن أن يصبح السؤال:

ما الشيء الرياضي الذي يمثل معنى هذا البرنامج؟

وهذه النقلة أساسية في بناء علم نظري للبرمجة.

12. وهو أيضًا من أوائل من فكروا في الـTime-Sharing

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

وهذا مهم لأن Strachey هنا يعود مرة أخرى إلى المنطقة الفاصلة بين البرنامج والنظام.

لم يكن اهتمامه مقتصرًا على كتابة برنامج منفرد؛ كان يفكر في كيف تُدار بيئة تنفيذ البرامج نفسها.

13. OS6 يثبت أن اهتمامه بالنظم لم يكن نظريًا فقط

بالتعاون مع Joseph Stoy، ارتبط Strachey بتطوير OS6 — An Experimental Operating System for a Small Computer في Oxford.

وتوجد وثائق أصلية للمشروع محفوظة ضمن أرشيف Programming Research Group، كما نُشرت ورقتان عن OS6 في The Computer Journal عام 1972: الأولى حول المبادئ والبنية، والثانية حول الإدخال/الإخراج ونظام الملفات. Software Preservation Group

إذن لدينا هنا سلسلة واضحة:

Program ⇨ Programming Language ⇨ Compiler ⇨ Operating System ⇨ Mathematical Semantics

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

14. قوته الكبرى كانت في الجمع بين المستويات

وهذه في رأيي أهم خاصية يجب أن تظهر في مسردك.

Strachey يستطيع أن يظهر في تاريخ:

• البرمجة التطبيقية.
• ألعاب الحاسوب.
• توليد النصوص.
• لغات البرمجة.
• تصميم المترجمات.
• أنظمة التشغيل.
• time-sharing.
• الدلالات الرياضية.
• التعليم الأكاديمي للبرمجة.

وهذا يفسر لماذا أصبحت Oxford نفسها مرتبطة باسمه إلى هذا اليوم؛ فـStrachey Lectures تحمل اسمه، كما أن أقدم كرسي في قسم علوم الحاسوب بجامعة أكسفورد هو Christopher Strachey Professorship of Computing. قسم علوم الحاسب

15. ومن الناحية التاريخية، هو جسر بين جيلين

إذا كان Babbage قد حاول بناء الآلة التي يمكن أن تنفذ البرامج، فإن Strachey وصل إلى عصر أصبحت فيه الآلات موجودة بالفعل وأصبح السؤال:

كيف نصمم البرامج نفسها؟

ثم تطور السؤال عنده إلى:

كيف نصمم لغة مناسبة لكتابة البرامج؟

ثم:

كيف نحدد معنى تلك اللغة؟

ثم:

كيف نبني نظامًا يجعل البرامج قابلة للتنفيذ بصورة عملية؟

هذا التسلسل هو الذي يجعل Strachey من الأسماء التي يصعب وضعها في خانة واحدة.

16. «المبرمج» هنا ليس توصيفًا مجازيًا

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

في حالته تحديدًا هذا غير دقيق.

لدينا برنامج الداما، وبرامج توليد النصوص، ومساهمته المباشرة في CPL، والعمل على أنظمة التشغيل، وتجارب على KDF9، والعمل على GPM وBCPL في بيئة PRG. وتوضح مواد Oxford أن نشاطه العملي كان متداخلًا باستمرار مع نشاطه النظري. قسم علوم الحاسب

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

17. وحتى موته المبكر لم يسمح لمشروعه بأن يكتمل

توفي Strachey عام 1975 عن عمر 58 عامًا بصورة مفاجئة بعد إصابته بالتهاب الكبد، وفق Mathematical Institute في أكسفورد. معهد الرياضيات

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

والأهم أن كثيرًا من عمله لم يتحول إلى «منتج» يحمل اسمه؛ بل انتشر عبر أفكار ومفاهيم وأشخاص وطلاب ولغات وأبحاث.

أهم أعمال Christopher Strachey

هنا توجد نقطة يجب أن ننتبه إليها في قائمتك: Strachey لم يكن مؤلف كتب تقنية ضخمة بالمعنى التقليدي. إنتاجه الأساسي جاء في صورة أوراق بحثية، تقارير، محاضرات ومشروعات برمجية. لذلك سيكون من الخطأ اختراع «كتب Strachey» فقط حتى تتطابق البنية مع Babbage.

1. Fundamental Concepts in Programming Languages — 1967

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

2. Towards a Formal Semantics — 1964

يمثل مرحلة مهمة في الطريق نحو الصياغة الرياضية لمعاني لغات البرمجة. وتظهر هذه الورقة ضمن التسلسل الفكري لأعماله في أوائل الستينيات. قسم علوم الحاسب

3. Advances in Programming — 1963

عمل مبكر يعكس انتقال Strachey من مجرد ممارسة البرمجة إلى محاولة بناء علم للبرمجة. وتظهره مواد Oxford ضمن سلسلة أعماله الأساسية في الفترة السابقة لتأسيس PRG. قسم علوم الحاسب

4. The Varieties of Programming Languages — 1973

هذا من أكثر نصوصه أهمية بالنسبة إلى تاريخ لغات البرمجة؛ وهو تحليل للمجالات التي تستخدمها لغات البرمجة وكيف تختلف اللغات في تعريف تلك المجالات. النسخة الموجودة في أرشيف Oxford تعرّفه باعتباره monograph منقحًا وموسعًا من ورقة قدمها في International Computing Symposium في البندقية عام 1972. قسم علوم الحاسب

5. OS6 — An Experimental Operating System for a Small Computer — 1972

عمل تطبيقي مهم يثبت أن اهتمام Strachey بأنظمة التشغيل لم يكن تنظيرًا مجردًا. نُشر العمل في جزأين في The Computer Journal عام 1972. Software Preservation Group

6. The text of OS6Pub — 1972

مع Joseph Stoy، وهو توثيق أقرب إلى النص البرمجي والوثيقة التقنية لنظام OS6 نفسه، ومحفوظ ضمن أرشيف Programming Research Group. Software Preservation Group

هل توجد «كتب» لـStrachey يمكن وضع صور أغلفتها؟

ليس بالمعنى نفسه الذي فعلناه مع Babbage.

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

الخلاصة

Christopher Strachey اختيار قوي جدًا لحرف C، وبالأخص إذا كان معيار قائمتك هو «المبرمج» وليس فقط «عالم الحاسوب».

ما يميزه عن Ada وBabbage أن الاثنين أسسا إمكان البرمجة، بينما Strachey ساعد على تأسيس البرمجة كعلم وممارسة ولغة وموضوع رياضي.

والتسلسل حتى الآن أصبح مثيرًا جدًا:

A — Ada Lovelace: الخوارزمية والبرنامج المبكر
B — Charles Babbage: الآلة العامة القابلة للبرمجة
C — Christopher Strachey: لغة البرمجة، البرنامج، النظام، والدلالة الرياضية

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

D — Donald Davies

1. Donald Davies يغيّر طبيعة المسرد مرة أخرى

Donald Watts Davies (1924–2000) اختيار مثير جدًا لحرف D، لأننا ننتقل معه من تاريخ الآلة والبرمجة واللغات إلى تاريخ الشبكات والاتصال بين الحواسيب. وإذا كانت Ada Lovelace قد ساهمت في تصور البرنامج، وBabbage في تصور الآلة العامة، وStrachey في بناء علم البرمجة ولغاتها، فإن Davies ساهم في حل سؤال آخر: كيف تتبادل الحواسيب البيانات عبر شبكة؟

كان عمله في National Physical Laboratory (NPL) على packet switching من أهم التحولات في تاريخ الشبكات، وتقول NPL نفسها إن عمله في الاتصالات المعتمدة على الحزم أثّر بصورة كبيرة في تطور الإنترنت. National Physical Laboratory

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

2. بدايته كانت في الرياضيات والفيزياء

حصل Davies على بكالوريوس في الفيزياء عام 1943 ثم درجة أخرى في الرياضيات عام 1947 من Imperial College London، وحصل على Lubbock Memorial Prize بوصفه أفضل طالب رياضيات في سنته بجامعة لندن. ثم التحق بـNPL عام 1947. National Physical Laboratory

وهذا المسار مهم جدًا لفهمه: Davies لم يكن «مبرمجًا» نشأ داخل مدرسة برمجة بالمعنى الحديث، بل كان من الجيل الذي تشكل فيه علم الحاسوب من تداخل الرياضيات والفيزياء والهندسة والاتصالات.

وهذه تحديدًا إحدى سمات الجيل البريطاني الذي خرج منه.

3. عمله المبكر في NPL وضعه بالقرب من Turing

عندما وصل إلى NPL، بدأ في قسم الرياضيات، وكان لفترة قصيرة مساعدًا لـAlan Turing، ثم انتقل إلى العمل على Test Assembly وPilot ACE، وساهم لاحقًا في تطوير ACE الكامل. National Physical Laboratory

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

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

4. وكان بالفعل مبرمجًا قبل أن يصبح رجل الشبكات

هذه النقطة مهمة جدًا في سياق قائمتك.

أحيانًا يُختزل Davies إلى عبارة «مخترع packet switching»، فيبدو وكأنه مهندس اتصالات أكثر منه مبرمجًا. لكن سجله المبكر يحتوي على أعمال برمجية فعلية؛ ومن بينها بحثه عام 1956 عن Sorting Data on an Electronic Computer، كما كان يستخدم Pilot ACE في محاكاة حركة المرور. وتسجل IEEE Computer Society هذا البحث ضمن منشوراته المهمة. Computer Pioneers

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

بل كان هناك أساس برمجي مباشر في تكوينه المهني.

5. حتى اهتمامه المبكر بالألعاب كان خوارزميًا

في عام 1950 نشر Davies بحثًا بعنوان:

A Theory of Chess and Noughts and Crosses

أي أنه كان مهتمًا منذ وقت مبكر بتمثيل الألعاب وإجراءات اتخاذ القرار على الحاسوب. وتضع IEEE Computer Society هذا البحث ضمن قائمة منشوراته المهمة. Computer Pioneers

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

ثم انتقل Davies من هذه المسائل إلى مسائل أكثر واقعية بكثير: كيف تجعل الحواسيب تتواصل؟

6. الفكرة التي جعلت اسمه عالميًا: Packet Switching

في منتصف الستينيات كان Davies يفكر في مشكلة الاتصال بالحواسيب التفاعلية وأنظمة time-sharing.

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

فإذا حجزت قناة كاملة لكل اتصال، فإن جزءًا كبيرًا من السعة سيظل غير مستعمل.

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

هذه الوحدات أصبحت packets.

NPL تؤرخ تطوير packet switching إلى عام 1965، وتشرح أن البيانات تُقسم إلى حزم صغيرة ثم يعاد تجميعها عند المستقبل. National Physical Laboratory

7. العبقرية هنا ليست في «تقسيم البيانات» وحده

من السهل جدًا اليوم أن نشرح packet switching بجملة:

«البيانات تنقسم إلى packets.»

لكن هذا ليس جوهر الابتكار.

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

وهذا يتطلب:

عنوانًا ⇨ تخزينًا مؤقتًا ⇨ توجيهًا ⇨ إدارة ازدحام ⇨ نقلًا ⇨ إعادة بناء

أي أن Davies كان ينتقل من التفكير في البرنامج المنفرد إلى التفكير في النظام الموزع.

وهذه نقلة ضخمة في تاريخ الحوسبة.

8. يجب أيضًا وضع Davies داخل التاريخ الصحيح للاختراع

هنا يلزم قدر من الدقة التاريخية.

لم يكن Davies الشخص الوحيد الذي توصل بصورة مستقلة إلى أفكار packet switching. ففي الولايات المتحدة كان Paul Baran يعمل بالتوازي تقريبًا على شبكات الاتصالات الموزعة. وتؤكد Computer History Museum أن Baran وDavies وغيرهما عملوا بصورة متوازية في ستينيات القرن العشرين. CHM

لذلك فإن الصياغة التاريخية الأكثر دقة ليست:

«Davies اخترع الإنترنت وحده.»

ولا:

«Davies اخترع كل packet switching من الصفر دون أي عمل موازٍ.»

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

9. ما فعله بعد ذلك أهم من مجرد الفكرة

في عام 1967 نشر Davies مع K. A. Bartlett وRoger Scantlebury وP. T. Wilkinson ورقة:

A Digital Communication Network for Computers Giving Rapid Response at Remote Terminals

وهي من المنشورات الأساسية في تاريخ شبكة NPL. وتدرجها IEEE Computer Society ضمن أهم أعمال Davies. Computer Pioneers

هنا يتحول الأمر من نظرية إلى هندسة شبكة فعلية.

ثم بدأ بناء شبكة NPL packet-switched، التي أصبحت من أوائل الشبكات العملية من هذا النوع.

10. NPL Mark I هي اللحظة التي أثبتت فيها الفكرة نفسها عمليًا

بحلول عام 1970 كانت NPL قد طورت شبكة محلية packet-switched تقدم مجموعة من الخدمات لنحو 200 مستخدم. وتصف NPL الشبكة بأنها أول Local Area Network تستخدم packet switching، كما أصبحت لاحقًا مرتبطة بأبحاث الشبكات الدولية. National Physical Laboratory

وهنا تكمن أهمية Davies بالنسبة لمسردك.

Babbage صمم آلة لم تكتمل.

أما Davies فكان لديه مفهوم نظري ⇨ تصميم ⇨ شبكة عاملة ⇨ مستخدمون حقيقيون.

أي أن عمله انتقل إلى مستوى النظام الكامل.

11. وتأثير NPL وصل إلى ARPANET

في عام 1967 عرض Roger Scantlebury عمل فريق NPL في اجتماع ACM، ووصلت أفكار الشبكة إلى باحثي ARPA، ومن بينهم Larry Roberts. وتوثق Computer History Museum أن NPL كانت واحدة من الشبكات packet-switched التي ظهرت بالتوازي مع ARPANET، وأن شبكة NPL أثرت في مسار أبحاث الشبكات. CHM

وهنا يجب تجنب رواية مبسطة أخرى:

Davies لم يبنِ ARPANET.

لكن NPL كانت جزءًا مهمًا من البيئة التقنية التي تطورت فيها أفكار الشبكات packet-switched في أواخر الستينيات.

وهذا يجعل أثره عالميًا حتى وإن كان المشروع نفسه بريطانيًا.

12. والأهم أنه كان يفكر في الشبكات باعتبارها بيئة للحوسبة

هذه النقطة تجعل Davies أكثر ارتباطًا بالبرمجة مما قد يبدو.

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

أما في تصور Davies، فالشبكة نفسها أصبحت نظامًا حسابيًا موزعًا له:

• عقد.
• تخزين.
• عناوين.
• بروتوكولات.
• طوابير.
• قرارات توجيه.
• قواعد لإدارة البيانات.

وهذا انتقال من Computer Programming إلى Network Programming/System Design.

ولذلك فإن وضع Davies بعد Strachey في مسردك منطقي جدًا من الناحية التاريخية:

Strachey: ماذا يعني البرنامج؟

Davies: كيف تتواصل البرامج والحواسيب؟

13. ثم انتقل إلى مستوى أكثر حساسية: أمن الشبكات

في أواخر السبعينيات عاد Davies إلى البحث، وركز بصورة متزايدة على أمن شبكات الحاسوب والتشفير. وتوثق أرشيفاته أبحاثًا واسعة في التشفير، والتوقيعات الرقمية، وبطاقات الهوية الذكية، وطرق المصادقة. Centre for Scientific Archives

ومن أبرز أعماله في هذه المرحلة، بالتعاون مع David O. Clayden، تطوير Message Authenticator Algorithm (MAA) عام 1983.

وأصبح MAA لاحقًا معيارًا دوليًا تحت ISO 8731-2 عام 1987. Centre for Scientific Archives

وهذا مثير جدًا في مساره:

الحوسبة ⇨ الاتصالات ⇨ الشبكات ⇨ أمن الشبكات ⇨ المصادقة

أي أنه ظل يتتبع المشكلة التقنية إلى طبقة أعمق كلما تطورت التكنولوجيا.

14. اهتمامه بالـSmart Cards يكشف اتساع رؤيته

لم يتوقف الأمن عند الخوارزميات النظرية.

عمل Davies على تقنيات للاتصال الآمن وتطبيقات مرتبطة بـsmart cards، وكانت أرشيفاته تحتوي على أعمال حول حماية البطاقات، والتحقق من الهوية، والتوقيعات الرقمية، وأنظمة الأطراف الموثوقة. Centre for Scientific Archives

وهذا يجعله شخصية مبكرة مهمة في تاريخ ما نسميه اليوم security engineering.

فهو لم يكن يدرس التشفير بمعزل عن الشبكات؛ بل كان يتعامل معه باعتباره جزءًا من منظومة معاملات إلكترونية حقيقية.

15. وهنا تظهر واحدة من أجمل خصائصه: الاستمرارية التقنية

Davies لم ينتقل عشوائيًا بين موضوعات مختلفة.

المسار كله يمكن قراءته كخط واحد:

البرنامج ⇨ البيانات ⇨ الاتصال ⇨ الشبكة ⇨ البروتوكول ⇨ الأمن ⇨ المصادقة

وهذا في رأيي هو أفضل مفتاح لفهم مكانته.

فهو ليس مجرد «الرجل الذي اخترع packet switching».

إنه أحد الأشخاص الذين ساعدوا على نقل الحاسوب من كونه آلة مستقلة إلى كونه عقدة داخل منظومة حوسبية متصلة.

16. ومن هنا تأتي علاقته غير المباشرة بتاريخ الإنترنت

الإنترنت الحديث ليس مساويًا لـpacket switching.

هناك TCP/IP، وrouting، وDNS، وEthernet، وWeb، وغيرها من الطبقات والتقنيات التي تطورت على أيدي أشخاص وفرق كثيرة.

لكن packet switching كان أحد الأسس التي جعلت شبكات البيانات الحديثة ممكنة، وNPL نفسها تقول إن هذه التقنية «underpins the Internet we know today». National Physical Laboratory

لذلك فمكان Davies في التاريخ لا ينبغي أن يكون:

«مخترع الإنترنت».

بل:

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

وهذه صياغة أدق بكثير.

17. مكانته كمبرمج تحديدًا

وهنا أصل إلى النقطة الأكثر صلة بمسردك.

لو كان المسرد بعنوان «أعظم علماء الشبكات البريطانيين» لكان Davies اختيارًا بديهيًا.

لكن عنوانك هو «أعظم 26 مبرمجًا بريطانيًا».

وهنا يجب أن نلاحظ أن Davies ليس مثل Strachey أو Turing من حيث كون البرمجة ذاتها هي مركز شهرته التاريخية.

مع ذلك، توجد لديه أعمال برمجية موثقة: sorting على الحاسوب الإلكتروني، محاكاة المرور باستخدام Pilot ACE، وبرامج الألعاب المبكرة، ثم انتقلت مساهمته إلى البرمجة على مستوى الأنظمة والشبكات. Computer Pioneers

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

أهم أعمال Donald Davies المكتوبة

وهنا Davies أقوى من Strachey من ناحية الكتب؛ فقد ألّف وشارك في تأليف أربعة كتب رئيسية، وفق MacTutor. Maths History

1. Digital Techniques — 1963

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

2. Communication Networks for Computers — 1973

هذا هو أهم كتاب في إرث Davies على الأرجح.

شارك في تأليفه Derek L. A. Barber، وصدر عن John Wiley عام 1973. وتذكر MacTutor أن الكتاب كان في الأساس نسخة مكتوبة من سلسلة محاضرات ألقاها Davies في اليابان عام 1969 حول packet switching. Maths History

وبذلك فالكتاب ليس مجرد textbook عن الشبكات؛ إنه وثيقة من مرحلة كانت فيها packet-switched networking نفسها فكرة جديدة.

3. Computer Networks and Their Protocols — 1979

صدر عام 1979 بمشاركة W. L. Price وD. L. A. Barber وC. M. Solomonides. وتظهر قائمة IEEE لهذا العمل ضمن المنشورات المهمة لـDavies. Computer Pioneers

وهذا الكتاب مهم لأنه يأتي في مرحلة أصبحت فيها الشبكات تنتقل من التجارب الأولى إلى قضية أكثر تعقيدًا: البروتوكولات وكيفية جعل الشبكات تتواصل بطريقة منظمة.

4. Security for Computer Networks: An Introduction to Data Security in Teleprocessing and Electronic Funds Transfer — 1984

كتبه مع W. L. Price، وصدر عام 1984. وتدرجه IEEE Computer Society وMacTutor ضمن أعماله الرئيسية. Computer Pioneers

والكتاب مهم جدًا في قراءة مسيرته لأنه يمثل المرحلة الأخيرة من خطه الفكري:

شبكة البيانات لا تكفي؛ يجب أن تكون البيانات والمعاملات آمنة.

أهم الأوراق البرمجية/التقنية

وبالنسبة إلى مسردك تحديدًا، أعتقد أن بعض أوراق Davies أهم من كتبه عند قياس إرثه البرمجي:

1956 — Sorting Data on an Electronic Computer
يمثل Davies المبرمج المبكر، قبل تحوله الكبير إلى الشبكات. Computer Pioneers

1967 — A Digital Communication Network for Computers Giving Rapid Response at Remote Terminals
مع Bartlett وScantlebury وWilkinson؛ وهو من النصوص المؤسسة لشبكة NPL. Computer Pioneers

1968 — The Principles of a Data Communication Network for Computers and Remote Peripherals
من النصوص التي بلورت مبادئ شبكة البيانات packet-switched. وتظهر الورقة ضمن الببليوغرافيا التاريخية للشبكات. Bitsavers

1971 — Packet Switching in a Public Data Network
يمثل انتقال التفكير من التجربة المختبرية إلى تصور شبكات بيانات عامة. Bitsavers

الخلاصة: لماذا Donald Davies مهم في مسردك؟

إذا قرأنا الأسماء الأربعة حتى الآن كسلسلة واحدة، تصبح القائمة أكثر إثارة:

A — Ada Lovelace
البرنامج والخوارزمية.

B — Charles Babbage
الآلة العامة القابلة للبرمجة.

C — Christopher Strachey
اللغة والدلالة والنظام البرمجي.

D — Donald Davies
الشبكة التي تجعل الحواسيب والبرامج تتواصل.

وهذا يجعل Davies اختيارًا له وظيفة تاريخية واضحة جدًا داخل المسرد.

لكن الأهم بالنسبة لي هو أن عدم شهرته الجماهيرية مقارنة بـTuring لا يعكس حجم التحول الذي أحدثه: قبل Davies كان الحاسوب يمكن النظر إليه بوصفه جهازًا مستقلًا؛ بعد تطور packet switching أصبح من الطبيعي التفكير في مجموعة حواسيب باعتبارها نظامًا واحدًا متصلًا.

وإذا كان Babbage قد ساعد على جعل الآلة قابلة للبرمجة، فإن Davies ساعد على جعل الآلة قابلة للاتصال.

وهذه نقلة من Computer ⇨ Computer Network لا تقل تاريخيًا أهمية عن الانتقال من Calculator ⇨ Computer. National Physical Laboratory

E — Edgar F. Codd

1. لماذا Edgar Codd مهم جدًا داخل مسرد المبرمجين؟

Edgar F. Codd يمثل انتقالًا مهمًا جدًا في مسردك: من المبرمج الذي يكتب برامجًا أو يبني أنظمة تشغيل وشبكات، إلى المبرمج الذي يغيّر الطريقة التي تُنظَّم بها المعلومات نفسها داخل الحاسوب.

وهذا بالضبط ما يجعل اختياره لحرف E قويًا جدًا. فـCodd ليس مجرد صاحب “نظرية قواعد بيانات”؛ بدأ أصلًا حياته المهنية بوصفه mathematical programmer في IBM سنة 1949، وعمل على آلات مبكرة مثل Selective Sequence Electronic Calculator، ثم شارك في IBM 701، وأسهم لاحقًا في تصميم IBM 7030 STRETCH، وقاد فريقًا طور نظامًا من أوائل أنظمة multiprogramming. IBM

2. المبرمج قبل عالم قواعد البيانات

هذه المرحلة المبكرة مهمة لأنها تمنع اختزال Codd في صورة “عالم قواعد بيانات ظهر فجأة سنة 1970″.

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

وهنا تظهر صلة جميلة بينه وبين الأسماء السابقة في مسردك: Codd لم يبدأ من البيانات؛ بدأ من البرنامج والنظام، ثم انتهى إلى سؤال أعمق: كيف ينبغي للحاسوب أن يمثل المعلومات التي تتعامل معها البرامج؟

3. من البرمجة إلى الرياضيات

حصل Codd على الدكتوراه في علوم الحاسوب من University of Michigan بعد دراسته هناك بمنحة من IBM، وانضم إلى مختبر IBM في سان خوسيه سنة 1968. IBM

هذه النقلة جعلت عمله مختلفًا عن كثير من المبرمجين المعاصرين له. لم يعد السؤال بالنسبة إليه:

كيف أكتب برنامجًا أسرع؟

بل أصبح:

ما البنية الرياضية التي يجب أن تكون عليها البيانات حتى تصبح البرامج التي تتعامل معها أكثر استقلالًا عن طريقة تخزينها؟

وهذا السؤال هو قلب مشروعه كله.

4. ورقته التي غيرت قواعد اللعبة: 1970

في يونيو 1970 نشر Codd ورقته الشهيرة:

A Relational Model of Data for Large Shared Data Banks

في Communications of the ACM. IBM Research

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

بدلًا من أن تقول للبرنامج تقريبًا:

اذهب إلى هذا المكان، ثم اتبع هذا المسار، ثم انتقل إلى ذلك السجل…

أصبح بالإمكان التفكير في البيانات باعتبارها علاقات Relations يمكن إجراء عمليات رياضية عليها.

5. هنا تظهر عبقرية “الاستقلال عن التنفيذ”

أهم ما في نموذج Codd ليس مجرد تحويل البيانات إلى جداول.

الفكرة الأعمق هي Data Independence.

أي أن التطبيق ينبغي ألا يتحطم كلما تغيرت الطريقة الداخلية التي يخزن بها نظام قاعدة البيانات المعلومات. وقد كانت هذه الفكرة صريحة في ورقته الأصلية: تغيّر التمثيل الداخلي للبيانات لا ينبغي أن يفرض تغييرات على معظم برامج التطبيقات. IBM Research

وهذه فكرة برمجية عميقة جدًا؛ لأنها تفصل بين:

ما تعنيه البيانات

و

كيف يخزنها الحاسوب فعليًا.

ومن هذه الزاوية يمكن النظر إلى Codd باعتباره أحد كبار مهندسي abstraction في تاريخ البرمجة.

6. الجداول ليست جوهر النظرية وحدها

من السهل جدًا اختزال النموذج العلائقي في الصورة المدرسية:

Table A + Table B + JOIN

لكن Codd كان يفكر في شيء أكثر تجريدًا بكثير.

العلاقة Relation هي كيان رياضي، والجدول هو إحدى الطرق العملية لتمثيلها. وقد قدم في الورقة الأصلية عمليات على العلاقات، كما أدخل مفهوم normal form لمعالجة التكرار والمشكلات الناتجة عنه. IBM Research

لذلك فقول “Codd اخترع الجداول” تبسيط شديد.

الأدق هو:

Codd وضع نموذجًا رياضيًا عامًا لإدارة البيانات، وأصبحت الجداول الواجهة العملية الأشهر لهذا النموذج.

7. التطبيع Normalization

وهنا تأتي واحدة من أعظم إضافاته البرمجية.

في 1971 نشر:

Normalized Data Base Structure: A Brief Tutorial

ثم طور الموضوع بصورة أعمق في:

Further Normalization of the Data Base Relational Model. IBM Research

التطبيع لم يكن مجرد طريقة لترتيب الجداول بشكل “جميل”، بل محاولة رياضية ومنهجية لتقليل redundancy ومنع أنواع من عدم الاتساق أثناء الإدخال والتعديل والحذف.

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

8. وهذه نقطة تجعل Codd مبرمجًا من طراز خاص

إذا كان Strachey جعل البرمجة موضوعًا يمكن أن تكون له لغة ودلالات رياضية، فإن Codd جعل البيانات نفسها قابلة للتعامل معها باعتبارها بنية رياضية يمكن للبرامج أن تعمل عليها بصورة مجردة.

هذه المقارنة مهمة داخل مسردك:

Strachey → معنى البرنامج.
Codd → بنية البيانات التي يعمل عليها البرنامج.

ولهذا فإن Codd ليس هامشيًا في تاريخ البرمجة؛ إنه أحد الأشخاص الذين غيّروا طبقة التجريد التي تكتب البرامج فوقها.

9. اللغة التي تقف فوق النموذج

Codd لم يخترع SQL؛ وهذه نقطة يجب الحفاظ عليها بدقة.

فـIBM طورت لاحقًا في مشروع System R لغة SEQUEL، المرتبطة خصوصًا بـDon Chamberlin وRaymond Boyce، ثم أصبحت SQL. وكان System R محاولة عملية لإثبات إمكانية بناء نظام صناعي على أفكار Codd العلائقية. IBM

لكن Codd كان مهتمًا تحديدًا بمشكلة لغة الاستعلام نفسها. ففي 1971 نشر A Data Base Sublanguage Founded on the Relational Calculus، وناقش فيه أفضلية لغة مبنية على relational calculus مقارنة بالمقاربات الإجرائية منخفضة المستوى. دوى

وهنا يظهر الفرق:

Codd وضع النظرية التي تحدد ما ينبغي أن تستطيع لغة البيانات فعله؛ آخرون بنوا اللغة الصناعية التي أصبحت SQL.

10. الصراع مع قواعد البيانات القديمة

قوة فكرة Codd تظهر أكثر إذا وضعناها في سياق عصرها.

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

Codd قلب اتجاه التفكير:

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

وهذه الفكرة أصبحت لاحقًا من المسلمات، لكنها في وقت طرحها لم تكن كذلك.

11. المفارقة: IBM نفسها لم تتحول فورًا

وهذه من أكثر التفاصيل إثارة في قصة Codd.

IBM كانت تملك نظامًا هرميًا ناجحًا هو IMS، ولذلك لم تتحول فورًا إلى النموذج العلائقي. وفي 1973 بدأ مختبر سان خوسيه مشروع System R لإثبات أن النموذج يمكن تحويله إلى نظام عملي ذي مستوى صناعي. IBM

ومن System R خرجت أفكار وتجارب مهمة جدًا في الاستعلام والتحسين والتنفيذ، وأسهمت في الطريق الذي قاد إلى منتجات IBM العلائقية، ومنها DB2 الذي ظهر سنة 1983. IBM

وهنا توجد مفارقة تاريخية جميلة: النظرية سبقت المؤسسة التي كان يعمل فيها صاحبها.

12. Codd والـDatabase Optimizer

أهمية Codd لا تنتهي عند تصميم البيانات.

بمجرد أن تقول لنظام قاعدة البيانات:

أعطني نتيجة هذا الاستعلام.

فأنت لم تعد تحدد له بالضرورة كيف يصل إليها.

وهذا يفتح الباب أمام optimizer لاختيار طريقة التنفيذ بنفسه. وقد ساهمت أبحاث System R اللاحقة، ومنها عمل Patricia Selinger، في تطوير التحسين القائم على التكلفة. IBM

أي أن فلسفة Codd ساعدت على خلق طبقة جديدة من البرمجة:

المبرمج يصف المطلوب، والنظام يقرر كيف ينفذه.

وهذا قريب جدًا من الفلسفة التي ستظهر لاحقًا في لغات الاستعلام، والمترجمات، والأنظمة التصريحية Declarative Systems.

13. لم يتوقف Codd عند نموذج 1970

من الأخطاء الشائعة التعامل مع ورقة 1970 وكأنها كل مشروع Codd.

لقد واصل تطوير النموذج لعقود، وناقش مسائل مثل semantics، والاعتماديات، والتطبيع، والأنظمة الفرعية للاستعلام، ثم قدم في 1979 بحثه:

Extending the Database Relational Model to Capture More Meaning

حيث حاول توسيع النموذج ليعبر بصورة أفضل عن المعنى الدلالي للبيانات. IBM Research

وهذا مهم جدًا: Codd لم يكن يحاول فقط أن يجعل قواعد البيانات تعمل؛ كان يحاول أن يجعل النموذج الرياضي وراءها أكثر قدرة على التعبير عن العالم الذي تمثله البيانات.

14. Codd وقواعده الاثنتا عشرة

في الثمانينيات أصبح Codd أكثر صراحة في الدفاع عن المعنى الحقيقي للنموذج العلائقي، خصوصًا في مواجهة الأنظمة التي تستخدم كلمة “relational” بينما لا تحقق جميع مبادئه.

ومن هنا ظهرت Codd’s Twelve Rules، التي أصبحت من أشهر محاولات تحديد ما الذي يجعل نظامًا ما علائقيًا بالمعنى الكامل.

والأهمية هنا ليست في حفظ القواعد واحدة واحدة، وإنما في المبدأ:

Codd لم يكن يرى “relational” كاسم تجاري، بل كخصائص نظرية يجب أن يحققها النظام.

15. الكتاب الذي جمع مشروعه

في 1990 نشر كتابه الرئيسي:

The Relational Model for Database Management: Version 2

وهو ليس كتابًا تعليميًا بسيطًا عن SQL، بل محاولة متأخرة لصياغة النموذج العلائقي كما كان Codd يراه بعد عقود من التطوير. الكتاب صدر عن Addison-Wesley ويتكون من 538 صفحة في الطبعة المسجلة بالمكتبات. كتالوج المكتبة

وهذا الكتاب مهم جدًا لمسردك لأنه يمثل النص الأكثر اكتمالًا الذي تركه Codd لتصوره الخاص للنموذج العلائقي.

16. علاقته بـChris Date

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

كان C. J. Date أحد أهم المتعاونين والمفسرين لأفكار Codd، وظهرت بينهما أعمال مشتركة حول النموذج العلائقي، ومنها مقارنة المقاربة العلائقية بالمقاربة الشبكية سنة 1974. IBM Research

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

17. لماذا حصل على Turing Award؟

حصل Codd على ACM Turing Award سنة 1981، وتحدد ACM سبب التكريم بإسهاماته الأساسية والمستمرة في نظرية وممارسة نظم إدارة قواعد البيانات، خصوصًا قواعد البيانات العلائقية. ACM

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

وهذا يضعه تاريخيًا في سلسلة مهمة جدًا داخل مسردك:

Babbage → Strachey → Davies → Codd

مع اختلاف المجالات، لكن هناك خط واحد بينهم: تحويل فكرة مجردة إلى بنية حاسوبية قابلة للتعميم.

18. أثره يتجاوز SQL

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

لكن التأثير الأعمق ليس “وجود MySQL أو PostgreSQL أو DB2″.

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

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

19. Codd بوصفه “مبرمج البيانات”

وهنا أرى أن إدخاله في قائمتك يصبح مثيرًا جدًا من ناحية التصنيف.

Ada Lovelace مثلًا ارتبطت بالبرنامج بوصفه تعليمات مجردة.

Strachey ارتبط بالبرنامج بوصفه لغة ودلالة.

Davies وسّع البرنامج إلى الاتصال بين الأنظمة.

أما Codd فذهب إلى طبقة مختلفة:

كيف نمثل العالم الذي تتعامل معه البرامج؟

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

20. الحكم التاريخي على موقعه في قائمتك

بالنسبة لمسرد أعظم 26 مبرمجًا بريطانيًا، Codd اختيار ذو ثقل خاص لأن مساره يثبت أنه لم يكن مجرد منظّر قواعد بيانات منعزل عن البرمجة.

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

بل إن مساره يمثل تحولًا من:

Programming → Operating Systems → Data Representation → Database Theory → Query Languages → Data Management

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

أهم أعمال Edgar F. Codd

1. A Relational Model of Data for Large Shared Data Banks — 1970
   العمل المؤسس للنموذج العلائقي. IBM Research
2. Normalized Data Base Structure: A Brief Tutorial — 1971
   من الأعمال الأساسية في صياغة مفهوم التطبيع. IBM Research
3. Further Normalization of the Data Base Relational Model — 1972
   تطوير أعمق لنظرية التطبيع. دوى
4. A Data Base Sublanguage Founded on the Relational Calculus — 1971/1972
   من أعماله المهمة في لغة الاستعلام العلائقية. دوى
5. Interactive Support for Non-Programmers: The Relational and Network Approaches — 1974، مع C. J. Date. IBM Research
6. The Relational and Network Approaches: Comparison of the Application Programming Interfaces — 1974، مع C. J. Date. IBM Research
7. Extending the Database Relational Model to Capture More Meaning — 1979
   محاولة لتوسيع النموذج نحو تمثيل دلالي أغنى. IBM Research
8. The Relational Model for Database Management: Version 2 — 1990
   كتابه الرئيسي والأكثر شمولًا في عرض النموذج كما استقر لديه. Software Preservation Group

الخلاصة داخل مسردك: Codd ليس مجرد “رجل قواعد بيانات”. أهميته البرمجية تكمن في أنه نقل التجريد من تعليمات البرنامج إلى بنية البيانات التي يتعامل معها البرنامج؛ ومن هنا أصبح أثره ممتدًا إلى لغات الاستعلام، وتحسين التنفيذ، وهندسة البرمجيات، وأنظمة المعلومات بأكملها. وهذا يجعل E = Edgar Codd اختيارًا ذا أساس تاريخي وبرمجي قوي جدًا.

Fowler, Martin

F — Martin Fowler

إذا كان Edgar Codd قد أعاد صياغة الطريقة التي تتعامل بها البرامج مع البيانات، فإن Martin Fowler يمثل شيئًا مختلفًا تمامًا: إعادة صياغة الطريقة التي يُكتب بها البرنامج نفسه ويُصان ويُعاد تشكيله.

وهذا يجعله اختيارًا مهمًا جدًا لحرف F في مسردك، خصوصًا إذا كان معيارك هو “المبرمج” بمعناه الواسع: الشخص الذي مارس البرمجة فعلًا، ثم أثّر في تقنيات كتابة البرمجيات وهندستها وبنيتها على نطاق واسع.

1. من هو Fowler؟

وُلد Martin Fowler في Walsall بإنجلترا عام 1963، ودرس الهندسة الإلكترونية وعلوم الحاسوب في University College London بين 1983 و1986. عمل بعد التخرج في Coopers & Lybrand ثم في شركة Ptech، وأصبح مستشارًا مستقلًا سنة 1991، وانتقل إلى الولايات المتحدة سنة 1994، قبل أن ينضم إلى Thoughtworks سنة 2000. ويحتفظ بالجنسيتين البريطانية والأمريكية. martinfowler.com

لكن هذه السيرة المهنية لا تفسر وحدها سبب وجوده في مسردك. الأهم أن Fowler قضى عقودًا في البرمجة الفعلية، وتحليل الأنظمة، وتصميم البرمجيات، والاستشارات التقنية، ثم حوّل ما تعلمه من تلك الممارسة إلى نماذج قابلة للتدريس وإعادة الاستخدام. وهو نفسه يصف اهتمامه الأساسي بأنه تصميم الأنظمة البرمجية بحيث تستطيع إضافة قدرات جديدة لسنوات طويلة. martinfowler.com

2. المثير في Fowler أنه لم يخترع لغة برمجة

وهذه أول نقطة يجب وضعها بوضوح.

Fowler ليس من نمط Lovelace أو Strachey أو Codd؛ لم يخترع لغة برمجة شهيرة، ولم يضع نموذجًا رياضيًا للحوسبة، ولم يصمم معمارية حاسوب.

لكن هذا لا يقلل من كونه مبرمجًا؛ بل يكشف نوعًا مختلفًا من التأثير البرمجي.

Fowler جعل موضوعًا كان المبرمجون يتعاملون معه غالبًا بوصفه خبرة شخصية — كيف أجعل الكود قابلًا للتغيير؟ كيف أعرف أن تصميمي سيصمد؟ كيف أعيد تنظيم برنامج موجود دون كسره؟ — إلى مجموعة من التقنيات والمفاهيم والأسماء والقواعد التي يمكن نقلها بين المشاريع.

وهنا تحديدًا تكمن أهميته.

3. من Object-Oriented Programming إلى Object-Oriented Design

نشأ Fowler في فترة أصبحت فيها البرمجة الكائنية Object-Oriented Programming مركزية في تصميم البرمجيات.

وقد عمل في بيئة شهدت صعود Smalltalk وC++ ثم Java. ويذكر Fowler نفسه أن Smalltalk وC++ كانتا من أهم لغات البرمجة الكائنية في بداياته، وأن Java أصبحت لاحقًا لغة مناسبة جدًا لشرح أفكاره البرمجية لجمهور واسع؛ ولذلك استخدمها في النسخة الأولى من Refactoring. martinfowler.com

لكن اهتمامه لم يكن باللغة بوصفها لغة فقط.

كان السؤال:

كيف نحول البرنامج الكائني من مجموعة classes إلى بنية يمكن فهمها وتغييرها؟

وهذا هو السؤال الذي سيصبح محور أعماله كلها تقريبًا.

4. Analysis Patterns — البداية الحقيقية لمشروعه الفكري

أول كتبه الكبرى كان:

Analysis Patterns: Reusable Object Models

الصادر سنة 1996.

الكتاب لم يكن عن كتابة syntax أو API معين، بل عن استخراج أنماط متكررة في نمذجة مجالات الأعمال.

وقد استند إلى خبرته في مجالات مثل الرعاية الصحية والتداول المالي والمحاسبة، وحاول تحويل النماذج التي تتكرر في هذه المجالات إلى Reusable Object Models. martinfowler.com

وهذه خطوة مهمة جدًا تاريخيًا: Fowler لم يعد يتعامل مع الكود كحل لمشكلة واحدة، بل بدأ يبحث عن البنية المتكررة وراء مجموعة من المشكلات.

5. Pattern Thinking

وهنا يصبح Fowler جزءًا من حركة أكبر في تاريخ البرمجة.

كان مفهوم Design Patterns قد اكتسب قوة هائلة بعد كتاب Gamma وHelm وJohnson وVlissides الشهير Design Patterns سنة 1994.

لكن Fowler أخذ التفكير بالنمط إلى مناطق أخرى:

Analysis Patterns
ثم
Enterprise Application Patterns
ثم
Refactoring Patterns
ثم
Architecture Patterns.

أي أنه ساعد في تحويل البرمجة من:

“كيف أكتب هذا البرنامج؟”

إلى:

“ما النمط البنيوي الذي تتكرر هذه المشكلة وفقه؟”

وهذه طريقة تفكير مختلفة تمامًا في البرمجة.

6. UML Distilled

بعد ذلك جاء أحد أكثر كتبه تأثيرًا:

UML Distilled: A Brief Guide to the Standard Object Modeling Language

كانت مشكلة UML في بداياتها أن عالم النمذجة الكائنية أصبح مليئًا باللغات والرموز والأساليب المختلفة.

وقد ظهر UML سنة 1997 كمحاولة لتوحيد هذا المشهد. ويصف Fowler كتابه بأنه كان من أوائل الكتب التي قدمت عرضًا مختصرًا وعمليًا للغة UML، مع التركيز على الجزء الذي رآه مفيدًا فعليًا للمطورين. martinfowler.com

وهذا أسلوب Fowler النموذجي:

لا يحاول أن يشرح كل شيء.

بل يحاول الإجابة عن سؤال:

ما الذي يحتاجه المبرمج فعلًا؟

7. ثم جاء الكتاب الذي جعل اسمه عالميًا: Refactoring

هنا يصل Fowler إلى أهم نقطة في مسيرته البرمجية.

في 1999 صدر:

Refactoring: Improving the Design of Existing Code

مع مساهمات من Kent Beck وغيرهما، ثم ظهرت طبعة ثانية موسعة سنة 2018. martinfowler.com

الفكرة تبدو بسيطة جدًا:

غيّر بنية الكود دون تغيير سلوكه الخارجي.

لكن Fowler حوّلها إلى منهج برمجي كامل.

8. لماذا Refactoring مهم إلى هذه الدرجة؟

لأن البرنامج ليس شيئًا ينتهي بمجرد أن يعمل.

هذه نقطة مركزية في مشروع Fowler.

البرنامج الذي يعمل اليوم قد يصبح بعد عامين:

• أصعب في القراءة؛
• أصعب في الاختبار؛
• أصعب في إضافة وظيفة جديدة؛
• مليئًا بالتكرار؛
• متشابك الاعتماديات؛
• أو يحمل تصميمًا لم يعد مناسبًا للنظام.

الحل التقليدي قد يكون “إعادة كتابة النظام”.

لكن Fowler قدم بديلًا أكثر دقة:

إعادة تشكيل البرنامج تدريجيًا.

وذلك من خلال سلسلة من التحويلات الصغيرة التي تحافظ على السلوك. يصف Fowler جوهر refactoring بأنه سلسلة من التحويلات الصغيرة المحافظة على السلوك، بحيث يؤدي تراكمها إلى تغيير معماري كبير دون الحاجة إلى هدم النظام دفعة واحدة. martinfowler.com

وهذه فكرة برمجية عميقة جدًا.

9. Code Smells

من أقوى مفاهيم الكتاب أيضًا Code Smells.

فالبرنامج لا يحتاج دائمًا إلى خطأ صريح حتى تعرف أن تصميمه يعاني مشكلة.

قد ترى:

• Method طويلة جدًا؛
• Class تحمل مسؤوليات كثيرة؛
• Duplicate Code؛
• Feature Envy؛
• Long Parameter List؛
• Switches متكررة؛
• اعتماديات غير مناسبة.

هذه ليست بالضرورة bugs.

إنها إشارات إلى مشكلة في التصميم.

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

10. والأهم: Refactoring ليس “تنظيف الكود”

هنا يجب عدم اختزال Fowler في عبارة “ينظف الكود”.

Refactoring عنده عملية مضبوطة.

الفكرة أن كل تحويل يجب أن يكون صغيرًا بما يكفي لفهم أثره، وقابلًا للتحقق، ثم يمكن تركيب عشرات التحويلات الصغيرة للحصول على تغيير كبير.

وهذا يربط Fowler مباشرة بثقافة automated testing.

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

ولهذا أصبح refactoring جزءًا عضويًا من نموذج البرمجة الحديث الذي يجمع:

Tests → Refactoring → Continuous Integration → Evolutionary Design

وليس مجرد نشاط تجميلي بعد الانتهاء من البرمجة. Thoughtworks

11. Fowler وAgile

في سنة 2001 كان Fowler واحدًا من الموقعين السبعة عشر على Manifesto for Agile Software Development. بيان أجايل لتطوير البرمجيات

وهنا يجب التفريق بين شيئين:

Fowler لم يخترع Agile وحده.

لكن وجوده ضمن المجموعة المؤسسة جزء موثق من التاريخ، وكانت مساهمته التقنية مهمة لأن أفكارًا مثل refactoring وevolutionary architecture جعلت التغيير المستمر في البرمجيات أكثر قابلية للممارسة.

بعبارة أخرى:

Agile يقول: يجب أن نستطيع التكيف مع التغيير.

بينما تقول تقنيات Fowler:

إليك كيف تجعل الكود نفسه قابلًا للتغيير.

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

12. Patterns of Enterprise Application Architecture

في 2002 ظهر أحد أعماله الكبرى:

Patterns of Enterprise Application Architecture

مع Dave Rice وMatthew Foemmel وEdward Hieatt وRobert Mee وRandy Stafford.

وهنا اتسع نطاق Fowler من الكود والـclasses إلى الأنظمة المؤسسية الكاملة.

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

وهذا مهم لأن البرمجة الحديثة لا تتمحور حول function منفردة.

إنها تتعامل مع أنظمة تحتوي على:

واجهة + منطق أعمال + بيانات + معاملات + خدمات + تكاملات.

Fowler حاول تقديم قاموس لهذه الطبقات.

13. Fowler والـArchitecture

من هنا تظهر مساهمته الأوسع.

هو لا ينظر إلى Architecture باعتبارها رسمًا يوضع قبل كتابة البرنامج ثم ينتهي.

بل ينظر إليها بوصفها شيئًا يتطور مع النظام.

وهذا ما يسميه في كتاباته Evolutionary Architecture: العمارة ليست شيئًا جامدًا بالضرورة، بل يمكن تطويرها تدريجيًا عندما تتغير المعرفة والمتطلبات.

وهذا مرتبط مباشرة بفكرته الأهم:

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

وهذه من أكثر أفكاره نضجًا.

14. Domain-Specific Languages

في 2010 نشر Fowler مع Rebecca Parsons:

Domain-Specific Languages

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

DSL هي لغة صغيرة مصممة لمجال محدد بدل محاولة أن تكون لغة عامة لكل شيء.

Fowler يناقش نوعين رئيسيين:

External DSL
لغة مستقلة لها parser خاص بها.

و

Internal DSL
لغة داخل لغة عامة، تعتمد على قدرات اللغة المضيفة مثل APIs وfluent interfaces.

كما يناقش parsing وcode generation وlanguage workbenches. martinfowler.com

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

15. Fowler والمبرمج نفسه

هناك جانب مهم جدًا في مشروعه: Fowler لا يتعامل مع المبرمج باعتباره آلة لإنتاج الأسطر.

هو يهتم بما يجعل الكود قابلًا للقراءة من إنسان آخر.

وهذا واضح جدًا في فلسفة Refactoring، حيث تصبح readability وmaintainability جزءًا من جودة البرنامج، وليس مجرد مسألة ذوق.

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

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

16. لكن هناك نقطة نقدية مهمة جدًا

Fowler نفسه يعترف بشيء مهم في وصفه لعمله: هو لا يدعي أنه صاحب كل الأفكار التي يعرضها.

بل يصف دوره بأنه يتمثل كثيرًا في التعرف على الأفكار الجيدة، وتنظيمها، وتغليفها، وجعلها قابلة للنقل. martinfowler.com

وهذا يضعه في مكان مختلف عن Codd مثلًا.

Codd جاء بنموذج رياضي أصلي أحدث تحولًا في مجال قواعد البيانات.

أما Fowler فكثير من قوته تأتي من synthesis:

اكتشاف الممارسة → استخراج النمط → إعطاؤه اسمًا → توثيقه → نشره → جعله قابلًا للتطبيق في مشروع آخر.

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

17. لماذا هذا مهم لمسرد “المبرمجين”؟

لأن Fowler يمثل المبرمج الذي جعل خبرة البرمجة نفسها قابلة للتراكم.

قبل هذا النوع من التفكير، كان جزء كبير من مهارة تطوير البرمجيات ينتقل شفهيًا:

“أنا أتعامل مع هذه المشكلة بهذه الطريقة.”

Fowler يحولها إلى:

Pattern → Name → Explanation → Example → Transformation

وبذلك يستطيع مبرمج في لندن أن يتعلم أسلوبًا طوره فريق في بوسطن، ويستطيع فريق آخر أن يستخدم المفهوم نفسه بعد سنوات.

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

18. موقعه بالنسبة إلى الأسماء السابقة في مسردك

وهنا أراه مثيرًا جدًا مقارنةً بـCodd.

Codd غيّر ماهيّة البيانات بالنسبة إلى البرنامج.

Fowler غيّر ماهيّة البرنامج بالنسبة إلى المبرمج الذي سيستمر في تطويره.

Codd:

Data → Relation → Query → Abstraction

Fowler:

Code → Pattern → Refactoring → Architecture → Evolution

وهذا يجعل F امتدادًا منطقيًا جدًا بعد E.

19. والأهم أنه مبرمج فعليًا، لا مجرد منظّر

هذه نقطة أراها مهمة جدًا في قائمتك تحديدًا.

Fowler يكتب عن البرمجة، لكنه أيضًا مارسها. وهو نفسه يوضح أنه لا يكتب كثيرًا من production code في الوقت الحالي، لكنه ظل يكتب كودًا باستمرار، خصوصًا الكود المستخدم لشرح الأفكار البرمجية في كتبه. martinfowler.com

أي أن انتقاله لاحقًا إلى دور الكاتب والمستشار والمفكر التقني لا يمحو هويته الأصلية كمطور.

بل يمكن القول إن مسيرته تطورت من:

Programmer → Consultant → Software Designer → Pattern Cataloger → Software Engineering Author

20. الأثر التاريخي الحقيقي لـFowler

إذا أردنا تحديد أثره بدقة، فلن يكون:

“اخترع البرمجة الكائنية.”

ولن يكون:

“اخترع Agile.”

ولن يكون:

“اخترع Refactoring من الصفر.”

الأدق هو:

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

وبالأخص، جعل Refactoring جزءًا مستقرًا من قاموس البرمجة الحديثة؛ حتى إن أدوات التطوير أصبحت تؤتمت عددًا كبيرًا من التحويلات التي وثقها كتابه. martinfowler.com

21. الحكم على اختياره في مسردك

F = Martin Fowler اختيار قوي جدًا إذا كان المسرد يقيس عظمة المبرمج بمدى تأثيره في الممارسة البرمجية نفسها، وليس فقط بمن اخترع لغة أو نظامًا من الصفر.

فowler ليس Codd آخر، وليس Strachey آخر، ونوع مساهمته مختلف.

لكن لديه إنجاز نادر:

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

ومن هنا تصبح سلسلة الحروف حتى الآن ذات بنية مثيرة:

A — Lovelace: البرنامج كخوارزمية.
B — Babbage: البرنامج كتعليمات لآلة عامة.
C — Strachey: البرنامج كلغة ودلالة.
D — Davies: البرنامج كنظام اتصال.
E — Codd: البرنامج فوق نموذج بيانات مجرد.
F — Fowler: البرنامج كشيء قابل لإعادة الهيكلة والتطور.

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

أهم أعمال Martin Fowler

1. Analysis Patterns: Reusable Object Models — 1996
   أول كتبه الكبرى، حول الأنماط القابلة لإعادة الاستخدام في نمذجة المجالات. martinfowler.com
2. Refactoring: Improving the Design of Existing Code — 1999، مع مساهمات من Kent Beck وآخرين
   أهم أعماله البرمجية وأكثرها تأثيرًا في ممارسة تطوير البرمجيات. martinfowler.com
3. UML Distilled — 1997، ثم طبعات لاحقة
   كتابه المختصر المؤثر في UML والنمذجة الكائنية. martinfowler.com
4. Planning Extreme Programming — 2000، مع Kent Beck.
5. Patterns of Enterprise Application Architecture — 2002
   من أهم المراجع في هندسة تطبيقات المؤسسات. martinfowler.com
6. Domain-Specific Languages — 2010، مع Rebecca Parsons
   مرجع مهم في تصميم وتنفيذ DSLs الداخلية والخارجية. martinfowler.com
7. NoSQL Distilled — 2012، مع Pramod J. Sadalage. martinfowler.com
8. martinfowler.com — ليس كتابًا، لكنه جزء أساسي من إرثه؛ فقد تحول الموقع إلى مستودع ضخم لمقالات ومناقشات حول patterns وrefactoring وarchitecture وagile وmicroservices وDSL وغيرها. martinfowler.com

وبالتالي، إذا كان Codd هو الرجل الذي جعل البيانات أكثر تجريدًا، فإن Fowler هو الرجل الذي جعل عملية تطوير الكود نفسها أكثر قابلية للفهم والتسمية وإعادة الاستخدام. وهذا تحديدًا هو سبب أهمية وجوده في مسردك بوصفه مبرمجًا ومهندس برمجيات، لا مجرد مؤلف تقني.

G — Geoffrey Hinton

1. لماذا Hinton مهم جدًا في مسرد المبرمجين؟

مع Geoffrey Hinton ينتقل مسردك إلى مرحلة مختلفة جذريًا: لم يعد السؤال فقط كيف نكتب برنامجًا يحدد القواعد مسبقًا، بل كيف نجعل البرنامج يتعلم القواعد من البيانات.

وهذه النقلة تجعل Hinton واحدًا من أكثر الأسماء أهمية في تاريخ البرمجة الحديثة، حتى وإن كانت شهرته الأكاديمية تأتي تحت عناوين الذكاء الاصطناعي والتعلم الآلي والشبكات العصبية. سيرته الرسمية في University of Toronto تصفه صراحة بأنه يصمم خوارزميات للتعلم الآلي، وكان هدفه إيجاد إجراءات تعلم تستطيع اكتشاف البنية المعقدة في البيانات عالية الأبعاد. علوم الحاسوب – جامعة تورونتو

والأهم لمسردك أن مساهماته ليست مجرد أفكار فلسفية عن الذكاء الاصطناعي؛ إنها خوارزميات وبنى حسابية قابلة للتنفيذ: backpropagation، وBoltzmann machines، وdistributed representations، وmixture of experts، وdeep belief nets وغيرها. علوم الحاسوب – جامعة تورونتو

2. مبرمج بريطاني، لكن مسيرته عابرة للقارات

وُلد Hinton في Wimbledon في لندن سنة 1947، ودرس في جامعة Cambridge ثم حصل على الدكتوراه من University of Edinburgh، قبل أن يعمل في بريطانيا والولايات المتحدة وكندا.

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

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

3. لكنه ليس “مبرمج تطبيقات”

هنا يجب أن نحدد نوع البرمجة التي يمثلها Hinton.

لو استخدمنا كلمة programmer بمعنى:

شخص يكتب تطبيقات أو أنظمة تجارية ضخمة يوميًا

فلن يكون Hinton من هذا النوع.

أما إذا كان المقصود:

الشخص الذي يصمم الخوارزميات والبنى القابلة للتنفيذ التي تغير ما تستطيع البرامج فعله

فإنه يصبح حالة شديدة القوة.

بل إن سيرته الرسمية تختصر جوهر عمله بعبارة شديدة الدلالة: “Geoffrey Hinton designs machine learning algorithms.” علوم الحاسوب – جامعة تورونتو

وهذه بالضبط برمجة من مستوى أعلى: بدل كتابة كل قرار يدويًا، أنت تكتب إجراء التعلم نفسه.

4. المشكلة التي حاول حلها

البرمجة التقليدية تبدأ غالبًا من قاعدة:

المبرمج يعرف القاعدة → يكتبها → الحاسوب ينفذها.

Hinton انطلق من اتجاه مختلف:

المبرمج يحدد بنية التعلم → النظام يرى أمثلة → تتغير الأوزان → تظهر القاعدة من داخل النموذج.

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

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

أما الشبكة العصبية التي طور Hinton وأقرانه منهجيات تدريبها فتتعلم تمثيلات داخلية للخصائص من البيانات نفسها.

وهنا يبدأ التاريخ الذي سيقود لاحقًا إلى computer vision الحديثة، speech recognition، embeddings، ثم deep learning والنماذج التوليدية.

5. الخلفية النظرية: Connectionism

ظهر Hinton في فترة كان فيها الاتجاه connectionist في الذكاء الاصطناعي بعيدًا عن التيار الرمزي المهيمن.

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

لكن المشكلة كانت:

كيف تتعلم هذه الشبكة؟

وهنا أصبح Hinton جزءًا من مجموعة من الباحثين الذين حاولوا جعل الشبكات العصبية أكثر من مجرد نموذج مستوحى من الدماغ.

كان المطلوب هو خوارزمية تعلم قابلة للتنفيذ بكفاءة.

وهنا نصل إلى أهم اسم في مسيرته.

6. Backpropagation

في 1986 نشر Hinton مع David Rumelhart وRonald Williams الورقة الشهيرة:

Learning representations by back-propagating errors

في Nature. دوى

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

أي:

Input → Network → Output → Error → Backward propagation → Weight updates

وبتكرار العملية تتعلم الشبكة تمثيلات داخلية مفيدة للمهمة.

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

7. لكنه لم “يخترع backpropagation” وحده

وهذه نقطة تاريخية ضرورية.

من الخطأ اختزال التاريخ إلى:

Geoffrey Hinton invented backpropagation.

الخوارزمية لها تاريخ سابق، وظهرت أفكار مشابهة قبل 1986.

الأهمية الحقيقية لـHinton وRumelhart وWilliams كانت في إظهار قوة الإجراء بصورة واضحة ومؤثرة للشبكات ذات الطبقات المخفية، وإعادة إدخاله بقوة إلى مجال التعلم العصبي.

والأهم أن Hinton نفسه لم يتعامل مع backpropagation بوصفه نهاية القصة.

كان بالنسبة إليه وسيلة للوصول إلى شيء أهم:

Learning representations.

8. Representation هو جوهر مشروع Hinton

هذه ربما أهم كلمة لفهمه كله.

البرنامج التقليدي يستطيع أن يمثل مفهومًا بصورة صريحة:

CAT = animal + four legs + ...

لكن Hinton اهتم بتمثيل المفاهيم في فضاء موزع Distributed Representation.

أي أن المفهوم لا يكون بالضرورة في متغير واحد أو عقدة واحدة؛ بل يتم تمثيله بواسطة نمط من النشاط موزع على مجموعة من الوحدات.

وقد نشر Hinton وRumelhart وMcClelland سنة 1986 فصلًا بعنوان Distributed Representations في Parallel Distributed Processing. جامعة تورونتو

وهذه الفكرة أصبحت لاحقًا شديدة الأهمية لفهم embeddings في الشبكات العصبية الحديثة.

9. ومن هنا يمكن ربط Hinton مباشرة بعصر الـLLM

هناك خط تاريخي مهم جدًا:

Distributed representations

↓

Neural representations

↓

Word embeddings

↓

Deep neural networks

↓

Transformer representations

↓

Large Language Models

لا يعني ذلك أن Hinton اخترع Transformers أو LLMs؛ لم يفعل.

لكن فكرة أن الكلمات والمفاهيم يمكن تمثيلها في فضاء متعلم عالي الأبعاد أصبحت واحدة من الركائز التي بنيت عليها أجيال لاحقة من النماذج.

والأكثر دلالة أن السيرة الرسمية لـHinton تشير إلى أنه كان من أوائل الباحثين الذين استخدموا backpropagation لتعلم word embeddings. علوم الحاسوب – جامعة تورونتو

10. Boltzmann Machine

لكن Hinton لم يكن باحث backpropagation فقط.

مع Terry Sejnowski وDavid Ackley طوّروا Boltzmann machine في الثمانينيات.

من أعمالهم الأساسية:

A Learning Algorithm for Boltzmann Machines — 1985. جامعة تورونتو

هنا أصبح التعلم احتماليًا stochastic بدل أن يكون مجرد ضبط مباشر للأوزان بطريقة deterministic بسيطة.

الفكرة كانت أن الشبكة تستطيع أن تتعلم توزيعًا احتماليًا للبيانات، وبالتالي لا تتعلم فقط:

ما المخرج الصحيح؟

بل يمكنها تعلم:

ما البنية الاحتمالية التي أنتجت هذه البيانات؟

وهذا الطريق مهم جدًا تاريخيًا نحو النماذج التوليدية.

11. Mixture of Experts

من مساهماته الأخرى Mixture of Experts، التي طورها مع آخرين في أواخر الثمانينيات وبدايات التسعينيات.

الفكرة جذابة جدًا من منظور البرمجة:

بدل أن يكون لديك نموذج واحد يحاول معالجة كل شيء بالطريقة نفسها، يمكن أن يكون لديك عدة experts، ويقوم نظام gating بتحديد أي منها ينبغي أن يتعامل مع الحالة.

أي تقريبًا:

Input → Gating → Expert 1 / Expert 2 / Expert 3 …

وهذا المفهوم عاد بصورة لافتة في النماذج الحديثة ذات البنية Mixture-of-Experts.

لذلك فبعض أفكار Hinton القديمة لا تبدو تاريخية فقط؛ بل تظهر بأشكال جديدة في بنية أنظمة الذكاء الاصطناعي الحديثة.

12. Deep Belief Networks

في منتصف العقد الأول من القرن الحادي والعشرين عاد Hinton إلى فكرة الشبكات العميقة بقوة.

ومن أعماله المهمة:

A Fast Learning Algorithm for Deep Belief Nets — 2006، مع Simon Osindero وYee-Whye Teh.

وهذه المرحلة شديدة الأهمية لأنها ساعدت على إعادة إحياء الاهتمام بـDeep Neural Networks بعد سنوات طويلة كان فيها التعلم العميق أصعب من الناحية العملية.

الفكرة الأساسية كانت استخدام طبقات من Restricted Boltzmann Machines للتعلم التمهيدي، ثم استخدام backpropagation لتحسين الشبكة.

وهنا ظهر شيء مهم جدًا:

Depth لم يعد مجرد زيادة عدد الطبقات؛ بل أصبح شيئًا يمكن تدريبه بطريقة عملية.

13. لماذا كانت مرحلة 2006 حاسمة؟

لأن الشبكات العصبية لم تكن جديدة.

الشبكات العصبية موجودة منذ عقود.

وbackpropagation لم يكن جديدًا تمامًا في 2006.

إذن لماذا أصبح Hinton محوريًا؟

لأنه ساعد في حل المشكلة العملية:

كيف نجعل الشبكات متعددة الطبقات تتعلم تمثيلات مفيدة فعلًا؟

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

بعد ذلك بسنوات قليلة أصبحت GPU، والبيانات الضخمة، والخوارزميات المحسنة، والـdeep learning تتلاقى في لحظة تاريخية واحدة.

14. AlexNet

وهنا نصل إلى نقطة تكاد تكون مفصلية في تاريخ الذكاء الاصطناعي الحديث.

في 2012 فاز AlexNet بفارق هائل في مسابقة ImageNet، وكان الفريق بقيادة Alex Krizhevsky وIlya Sutskever وتحت إشراف Geoffrey Hinton.

الورقة:

ImageNet Classification with Deep Convolutional Neural Networks

أصبحت واحدة من أكثر أوراق computer vision تأثيرًا في العصر الحديث.

وهنا حدث شيء تاريخي:

لم تعد الشبكات العميقة مجرد مدرسة بحثية هامشية.

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

ومن هذه اللحظة بدأ التحول الصناعي الكبير نحو deep learning.

15. Hinton ليس مجرد “أبو الذكاء الاصطناعي”

هذا اللقب الإعلامي شائع جدًا، لكن استخدامه وحده لا يشرح مساهمته.

الأدق هو أن نقول إن Hinton كان أحد المهندسين الفكريين الرئيسيين للثورة الحديثة في الشبكات العصبية والتعلم العميق.

جامعة Toronto تصف أبحاثه بأنها قادت إلى اختراقات في speech recognition وobject classification وغيرها، كما أن قائمة أبحاثه الرسمية تمتد عبر backpropagation وBoltzmann machines وdistributed representations وmixture of experts وdeep belief nets وغيرها. علوم الحاسوب – جامعة تورونتو

إذن قوته ليست في خوارزمية منفردة.

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

16. والأهم أنه مبرمج على مستوى “خوارزمية التعلم”

وهنا أعود إلى معيار قائمتك.

لو كان Fowler قد جعل المبرمج قادرًا على إعادة تشكيل الكود، فإن Hinton فعل شيئًا مختلفًا:

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

في البرنامج التقليدي:

Code → Data → Output

أما في نموذج Hinton:

Architecture + Learning Algorithm + Data → Learned Parameters → Behavior

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

فالـprogram لم يعد بالضرورة مجموعة قواعد مكتوبة يدويًا تحدد كل سلوك.

يمكن أن يكون:

خوارزمية + بنية + أوزان متعلمة.

وهذا أحد أكبر التحولات في تاريخ البرمجة.

17. علاقته بـRumelhart وLeCun وBengio

لا ينبغي كتابة تاريخ deep learning باعتباره قصة Hinton وحده.

David Rumelhart وRonald Williams كانا شريكين أساسيين في ورقة 1986.

Yann LeCun طور convolutional neural networks بصورة محورية، خصوصًا في التعرف على الصور.

Yoshua Bengio قدم مساهمات أساسية في التعلم العميق والتمثيلات.

ثم جاء جيل لاحق مثل Sutskever وKrizhevsky وغيرهما.

ولهذا فإن Turing Award سنة 2018 ذهبت إلى Hinton وLeCun وBengio تقديرًا لإسهاماتهم المفاهيمية والهندسية في deep neural networks، وهي مساهمات أصبحت مكونًا حاسمًا للحوسبة الحديثة. وتظهر قائمة Hinton الرسمية حصول الثلاثة على الجائزة في 2018. جامعة تورونتو

18. ثم جاءت Nobel Prize

في 2024 حصل Hinton مع John Hopfield على Nobel Prize in Physics عن الاكتشافات والاختراعات الأساسية التي مكنت التعلم الآلي باستخدام الشبكات العصبية الاصطناعية. وتؤكد University of Toronto حصوله على الجائزة في 2024. جامعة تورونتو

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

لكن بالنسبة إلى مسردك، الأهم ليس الجائزة.

الأهم هو أن Hinton أصبح واحدًا من الأشخاص الذين غيّروا ماهية البرنامج نفسه.

19. الكتاب الذي يمثل مرحلته الأولى: Parallel Distributed Processing

من أهم الكتب المرتبطة بـHinton:

Parallel Distributed Processing: Explorations in the Microstructure of Cognition

الذي حرره مع David Rumelhart وJames McClelland، وصدر في مجلدين سنة 1986.

هذا العمل ليس كتابًا كتبه Hinton منفردًا، لكنه من أهم الوثائق الفكرية لحركة parallel distributed processing / connectionism التي كان Hinton أحد أهم ممثليها.

وفيه يظهر عدد من مساهماته المباشرة، ومنها Distributed Representations وLearning and Relearning in Boltzmann Machines وLearning Internal Representations by Error Propagation. جامعة تورونتو

20. Unsupervised Learning

ومن الكتب المرتبطة مباشرة به أيضًا:

Unsupervised Learning: Foundations of Neural Computation

الطبعة المسجلة للكتاب صدرت سنة 1999 عن MIT Press، وهو يجمع أعمالًا حول التعلم غير الخاضع للإشراف والأسس الحسابية للتعلم العصبي.

وهذا مهم لأنه يكشف أن مشروع Hinton لم يكن محصورًا في:

Input → Label → Prediction

بل كان مهتمًا منذ وقت مبكر بسؤال أكثر صعوبة:

كيف يكتشف النظام البنية الموجودة في البيانات من دون أن نعطيه الإجابة الصحيحة لكل مثال؟

21. أهم أعماله البحثية

من أهم أعمال Hinton، بالترتيب التاريخي التقريبي:

1. Learning and Relearning in Boltzmann Machines — 1986
2. Learning Distributed Representations of Concepts — 1986
3. Learning Representations by Back-Propagating Errors — 1986، مع Rumelhart وWilliams. جامعة تورونتو
4. Distributed Representations — 1986، مع McClelland وRumelhart. جامعة تورونتو
5. Connectionist Learning Procedures — 1989. جامعة تورونتو
6. Keeping Neural Networks Simple by Minimizing the Description Length of the Weights — 1993، مع David van Camp. جامعة تورونتو
7. A Fast Learning Algorithm for Deep Belief Nets — 2006.
8. Reducing the Dimensionality of Data with Neural Networks — 2006، مع Salakhutdinov، حول deep autoencoders.
9. ImageNet Classification with Deep Convolutional Neural Networks — 2012، مع Krizhevsky وSutskever.
10. Distilling the Knowledge in a Neural Network — 2015، مع Oriol Vinyals وJeff Dean.

وقائمة Hinton الرسمية تضم مئات الأعمال وتتيح تصنيفها بحسب موضوعات مثل backpropagation وBoltzmann machines وdistributed representations وdistillation وlanguage modeling وimage generation وغيرها. علوم الحاسوب – جامعة تورونتو

22. مكانه داخل مسردك

وهنا يصبح تسلسل A → G مثيرًا للغاية:

Ada Lovelace
البرنامج بوصفه خوارزمية.

Charles Babbage
الآلة العامة التي يمكن برمجتها.

Christopher Strachey
البرنامج بوصفه لغة ودلالة.

Donald Davies
البرنامج داخل شبكة اتصال.

Edgar Codd
البرنامج فوق نموذج بيانات مجرد.

Martin Fowler
البرنامج بوصفه كيانًا يمكن إعادة تشكيله وتطويره.

Geoffrey Hinton
البرنامج الذي يتعلم بدل أن تُكتب قواعده كاملة يدويًا.

وهنا أرى أن Hinton لا يضيف مجرد تخصص جديد إلى القائمة؛ بل يمثل تحولًا في تعريف البرمجة نفسها.

23. التقييم النهائي لـG

اختيار Geoffrey Hinton لحرف G قوي جدًا، وخصوصًا إذا كانت قائمتك لا تحصر “المبرمج العظيم” في مطور لغة أو نظام تشغيل.

لأن Hinton نقل البرمجة من نموذج:

“اكتب لي القواعد التي أريد من الحاسوب اتباعها”

إلى نموذج:

“اكتب لي الآلية التي يستطيع الحاسوب من خلالها اكتشاف القواعد بنفسه.”

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

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

Hassabis

H — Demis Hassabis

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

1. البداية: مبرمج قبل أن يكون رجل أعمال أو عالمًا

وُلد Demis Hassabis في لندن سنة 1976، وبدأ البرمجة في طفولته، ثم أصبح في سن مبكرة جدًا لاعب شطرنج بارزًا. درس علوم الحاسوب في University of Cambridge، وتخرج سنة 1997، ثم حصل على PhD في علم الأعصاب المعرفي من University College London سنة 2009.

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

في سن المراهقة عمل في صناعة الألعاب، وكان من أبرز أعماله المبكرة تصميم وبرمجة لعبة Theme Park مع Bullfrog Productions، وهي لعبة تجارية ناجحة للغاية بالنسبة إلى مطور في ذلك العمر.

2. Theme Park ليست مجرد حكاية طفولة

هذه النقطة مهمة لأن قصة Hassabis كثيرًا ما تُروى باعتبارها حكاية “عبقري طفل”.

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

Theme Park لم تكن لعبة تعتمد على حركة شخصية في شاشة فحسب؛ كانت محاكاة لنظام معقد يضم اقتصادًا، زوارًا، موظفين، قرارات، موارد، أسعارًا، رضا العملاء، وتفاعلات بين عناصر كثيرة.

أي أن Hassabis كان يتعامل مبكرًا مع مشكلة:

كيف أبني نظامًا تتفاعل داخله مجموعة كبيرة من الوكلاء والقواعد بحيث ينتج عنها سلوك معقد؟

وهذا السؤال سيعود بصورة أكثر طموحًا في DeepMind.

3. من الألعاب إلى علم الأعصاب

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

وهذه النقلة تبدو للوهلة الأولى بعيدة عن البرمجة، لكنها في الحقيقة كانت جزءًا من مشروعه الأكبر:

كيف يعمل الذكاء؟

ولذلك أصبح الجمع بين:

Computer Science + Neuroscience + Games + AI

ميزة أساسية في مسيرته.

دراسة علم الأعصاب لم تكن بالنسبة إليه نهاية البرمجة؛ بل أصبحت مصدرًا لنماذج وأسئلة عن الذاكرة، والتخطيط، والتعلم، واتخاذ القرار.

4. DeepMind

في سنة 2010 أسس Hassabis مع Shane Legg وMustafa Suleyman شركة DeepMind في لندن، بهدف بناء أنظمة ذكاء اصطناعي قادرة على التعلم والتفكير بطرق أكثر عمومية.

وهنا يبدأ الجزء الذي يجعل Hassabis مختلفًا عن معظم الأسماء السابقة في قائمتك.

فهو لم يركز على خوارزمية واحدة فقط.

بل حاول إنشاء مختبر برمجي/بحثي يمكنه تطوير مجموعة من الخوارزميات والنظم التي تتعلم في بيئات مختلفة.

وهذا يجعل مساهمته أقرب إلى هندسة منظومة للذكاء الاصطناعي.

5. Atari والـDeep Reinforcement Learning

أحد الأعمال التي جعلت DeepMind محط أنظار مجتمع الذكاء الاصطناعي كان نظام التعلم الذي استطاع تعلم ألعاب Atari من البكسلات مباشرة.

الورقة الشهيرة:

Playing Atari with Deep Reinforcement Learning

ظهرت سنة 2013، ثم نشرت بصورة أوسع في 2015 بواسطة DeepMind. وكان الفريق يضم Volodymyr Mnih وKoray Kavukcuoglu وDavid Silver وغيرهم.

الفكرة الأساسية كانت دمج:

Deep Neural Networks + Reinforcement Learning

بحيث يتعلم النظام من الحالة والنتيجة والمكافأة بدل أن يُبرمج له الحل يدويًا لكل لعبة.

وهذا مهم جدًا بعد Hinton:

Hinton أعاد الشبكات العصبية إلى مركز التعلم.
DeepMind بدأ يربط التعلم العميق بالتفاعل واتخاذ القرار.

6. DQN

أصبح النظام يعرف باسم Deep Q-Network (DQN).

وهنا لدينا انتقال مهم:

الشبكة العصبية لا تقوم فقط بتصنيف صورة.

بل تتعلم:

أي فعل ينبغي اتخاذه في هذه الحالة؟

أي:

State → Action → Reward → Updated Policy

وهذا أقرب إلى بناء وكيل Agent من مجرد بناء مصنف.

وهذه النقلة ستصبح شديدة الأهمية في مسيرة Hassabis.

7. AlphaGo

ثم جاءت النقلة التاريخية الكبرى: AlphaGo.

في 2016 هزم AlphaGo لاعب Go العالمي Lee Sedol في مباراة شهيرة بنتيجة 4–1.

لكن أهمية AlphaGo لا تختصر في النتيجة.

النظام جمع بين عدة أفكار:

Deep Neural Networks + Reinforcement Learning + Tree Search

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

وهذا يمثل شيئًا مهمًا جدًا بالنسبة إلى تاريخ البرمجة:

النظام لا ينفذ استراتيجية كتبها الإنسان؛ بل يطور استراتيجية من خلال التعلم والبحث.

8. Move 37

أصبحت الحركة رقم 37 في المباراة الثانية من AlphaGo وLee Sedol واحدة من أشهر لحظات تاريخ الذكاء الاصطناعي.

لم تكن أهميتها أن النظام “لعب حركة غريبة” فقط.

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

وهنا ظهر سؤال أصبح مركزيًا في الذكاء الاصطناعي الحديث:

إذا كان النظام يستطيع اكتشاف استراتيجيات لم يبرمجها الإنسان، فماذا يعني أن نفهم البرنامج؟

وهذا سؤال برمجي وفلسفي في آن واحد.

9. AlphaZero

بعد AlphaGo جاء AlphaZero، الذي وسع الفكرة إلى ألعاب متعددة.

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

وهنا تظهر واحدة من أكثر أفكار Hassabis أهمية:

Self-play.

النظام يولد خبرته بنفسه.

بدل:

Human examples → model

نصبح أمام:

Rules → self-play → experience → learned strategy

وهذا تحول ضخم في كيفية بناء بعض أنظمة الذكاء الاصطناعي.

10. AlphaFold: حين خرج الذكاء الاصطناعي من اللعبة

لكن الإنجاز الذي يجعل Hassabis مختلفًا جذريًا عن مبرمجي الألعاب أو حتى باحثي reinforcement learning هو AlphaFold.

في 2020 أعلنت DeepMind أن AlphaFold حقق تقدمًا كبيرًا في مشكلة التنبؤ ببنية البروتين، ثم جاءت AlphaFold 2 لتقدم أداءً شديد القوة في تقييم CASP14.

وهنا حدث شيء مهم جدًا:

الخوارزمية التي تطورت من أفكار الألعاب والتعلم المعزز أصبحت أداة في علم الأحياء البنيوي.

أي أن البرنامج لم يعد مجرد لاعب.

أصبح أداة لاكتشاف بنية العالم الطبيعي.

11. AlphaFold 2

ورقة AlphaFold 2 الرئيسية:

Highly accurate protein structure prediction with AlphaFold

نشرت في Nature سنة 2021، وكان المؤلفون الأساسيون من DeepMind وMRC Laboratory of Molecular Biology.

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

وهنا يجب أن نميز بين Hassabis بوصفه مؤسسًا وقائدًا علميًا وبين كل التفاصيل التقنية التي نفذها أفراد فريق AlphaFold.

لم يكتب Hassabis وحده AlphaFold.

لكن مشروع AlphaFold يقع بوضوح داخل المشروع البحثي الذي بناه وقاده في DeepMind.

12. Nobel Prize in Chemistry 2024

وهذه المرة أصبح الأمر رسميًا على أعلى مستوى.

في 2024 مُنحت جائزة نوبل في الكيمياء إلى Demis Hassabis وJohn Jumper من DeepMind وإلى David Baker، مع تكريم Hassabis وJumper تحديدًا عن protein structure prediction. (nobelprize.org)

وهذا مهم في مسردك ليس بسبب الجائزة نفسها، بل بسبب المسافة التاريخية التي قطعها البرنامج:

لعبة فيديو → تعلم معزز → Go → بحث ذاتي → بروتين → علم الأحياء.

هذا من أغرب المسارات في تاريخ البرمجة الحديثة.

13. Gemini

بعد استحواذ Google على DeepMind واندماجه لاحقًا مع Google Brain، أصبح Hassabis أحد القادة الرئيسيين في Google DeepMind.

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

لكن من المهم هنا ألا ننسب إليه وحده كل هندسة Gemini.

كما في AlphaGo وAlphaFold، Hassabis هو المؤسس والقائد البحثي للمؤسسة التي طورت هذه الأنظمة، بينما شارك عدد كبير من الباحثين والمهندسين في تصميمها وتدريبها.

وهذا الفرق مهم جدًا إذا كنا نريد مسردًا تاريخيًا دقيقًا للمبرمجين.

14. ما الذي يجعل Hassabis “مبرمجًا” تحديدًا؟

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

Hassabis ليس مبرمجًا بالمعنى نفسه الذي كان عليه Strachey أو Fowler.

هو يمثل جيلًا أصبحت فيه البرمجة نفسها أكثر تركيبًا:

Algorithm → Learning System → Agent → Environment → Self-play → Emergent Strategy

المبرمج هنا لا يكتب كل خطوة.

إنه يصمم الآلة التي تنتج الخطوات.

وهذا يجعل Hassabis امتدادًا طبيعيًا جدًا لـHinton، ولكن مع فارق جوهري:

Hinton ركز على آليات التعلم والتمثيل.
Hassabis ركز على تحويل تلك الآليات إلى وكلاء وأنظمة قادرة على حل مشكلات معقدة في بيئات مختلفة.

15. الألعاب كانت مختبرًا للذكاء

وهذه إحدى أكثر الأفكار تميزًا في مسيرته.

بالنسبة إلى Hassabis، الألعاب لم تكن مجرد صناعة ترفيهية.

كانت بيئات تجريبية للذكاء.

لعبة Atari تعطيك:

حالة → فعل → مكافأة.

Go يعطيك:

حالة → ملايين الاحتمالات → نتيجة بعيدة المدى.

الشطرنج يعطيك:

حالة → بحث → تخطيط → نتيجة.

ثم يمكن أخذ تقنيات التعلم من هذه البيئات ونقلها إلى مسائل علمية.

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

16. لكنه ليس مجرد نسخة من Hinton

لو كان Hinton يمثل:

Neural Networks

فإن Hassabis يمثل:

AI Systems.

Hinton ساعد في جعل الآلة قادرة على التعلم من التمثيلات.

Hassabis حاول بناء نظام يستطيع:

التعلم + التخطيط + البحث + اتخاذ القرار + التفاعل مع بيئة + نقل القدرة إلى مجال جديد.

وهذا فرق مهم في المسرد.

17. نقطة القوة ونقطة الحذر

القوة التاريخية الكبرى لـHassabis هي أنه استطاع جمع مدارس مختلفة داخل نظام واحد:

علم الأعصاب، التعلم العميق، التعلم المعزز، البحث، الألعاب، ثم العلوم الطبيعية.

لكن عند تقييمه كمبرمج فردي، يجب ألا ننسب إليه شخصيًا كل ما أنتجته DeepMind.

AlphaGo نتاج فرق.

AlphaFold نتاج فرق.

Gemini نتاج فرق.

ولهذا فإن أفضل وصف له ليس:

“Hassabis كتب وحده أهم برامج الذكاء الاصطناعي الحديثة.”

بل:

“Hassabis كان من أهم المبرمجين/علماء الحاسوب الذين أسسوا وقادوا بيئة بحثية أنتجت بعض أكثر الأنظمة تأثيرًا في تاريخ الذكاء الاصطناعي الحديث.”

وهذا في حد ذاته شكل مختلف من العظمة البرمجية.

18. أهم أعماله المبكرة

من منظور البرمجة الخالصة، من المفيد ألا ندفن أعماله المبكرة تحت AlphaGo وAlphaFold:

• Theme Park — 1994، عمل مبكر في تصميم وبرمجة لعبة محاكاة معقدة.
• Republic: The Revolution — مشروع Elixir Studios الكبير، صدر سنة 2003.
• أبحاث الدكتوراه في علم الأعصاب المعرفي، خصوصًا الذاكرة والتخيل والتخطيط.
• DeepMind — تأسيس المختبر سنة 2010.
• DQN / Deep Q-Learning — أحد المسارات المبكرة التي ساهمت في نجاح التعلم المعزز العميق.
• AlphaGo.
• AlphaZero.
• AlphaFold.
• Gemini ضمن مرحلة Google DeepMind.

19. هل لديه “كتب” مثل Fowler أو Codd؟

هنا تختلف الصورة.

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

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

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

• Playing Atari with Deep Reinforcement Learning — 2013.
• Human-level control through deep reinforcement learning — Nature, 2015.
• Mastering the game of Go with deep neural networks and tree search — Nature, 2016.
• Mastering Chess and Shogi by Self-Play with a General Reinforcement Learning Algorithm — 2017.
• A general reinforcement learning algorithm that masters chess, shogi, and Go through self-play — 2018.
• Highly accurate protein structure prediction with AlphaFold — Nature, 2021.

20. موقع H في المسرد

وهنا يصبح التسلسل أكثر وضوحًا:

G — Geoffrey Hinton
جعل التعلم العصبي العميق ممكنًا على مستوى عملي واسع.

H — Demis Hassabis
حوّل التعلم العميق والتعلم المعزز إلى أنظمة قادرة على اللعب، والتخطيط، والتعلم الذاتي، ثم معالجة مسائل علمية حقيقية.

أي أن H لا يكرر G.

بل يبني عليه.

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

وهذا يجعل H = Hassabis اختيارًا ذا منطق قوي جدًا داخل مسردك، خصوصًا لأن جذوره كمبرمج سبقت بكثير شهرته كقائد لـDeepMind.

ian Bell

I — Ian Bell

إذا كان H — Demis Hassabis يمثل في قائمتك انتقال البرمجة من الخوارزمية إلى النظام الذكي واسع النطاق، فإن I — Ian Bell يمثل شيئًا مختلفًا تمامًا: البرمجة بوصفها هندسة لعالم كامل داخل ذاكرة شديدة الضآلة. Bell ليس مشهورًا لأنه أسس شركة ضخمة أو اخترع لغة برمجة؛ أهميته تأتي من أنه، وهو طالب في العشرين تقريبًا، شارك في كتابة Elite، إحدى أكثر التجارب البرمجية طموحًا في الحوسبة المنزلية في الثمانينيات. مركز تاريخ الحوسبة

1. لماذا Ian Bell مهم في مسرد المبرمجين؟

وجود Bell في خانة I قوي جدًا لأن Elite ليست مجرد لعبة ناجحة تاريخيًا. هي مثال نادر على برنامج استطاع أن يحوّل قيود العتاد إلى مشكلة خوارزمية: كيف تنشئ فضاءً ضخمًا، وسفنًا ثلاثية الأبعاد، وحركة، وقتالًا، وتجارة، ونظام تقدم، وعالمًا يبدو أوسع بكثير من البيانات الفعلية المخزنة؟

ولهذا فإن Bell يمثل نوعًا من المبرمجين يختلف عن Codd أو Strachey أو Hinton. Codd كان يبرمج المعلومة على مستوى النموذج، Strachey كان يبرمج المعنى والسلوك، Hinton كان يبرمج آلية التعلم؛ Bell كان يبرمج الفضاء نفسه: عالمًا افتراضيًا يستطيع البرنامج توليده وتشغيله بدل تخزينه بالكامل.

2. البداية: مبرمج قبل أن يكون “مصمم ألعاب”

ولد Ian Colin Graham Bell عام 1962 في هيرتفوردشاير، ودرس في Jesus College بجامعة كامبريدج، حيث حصل على درجة أولى في الرياضيات عام 1985 ثم دبلوم في علوم الحاسوب عام 1986. والمهم هنا أن مساره لم يبدأ من صناعة الألعاب التجارية؛ كان اهتمامه بالحوسبة والخوارزميات متداخلًا مع الرياضيات منذ البداية. ويكيبيديا

وفي كامبريدج بدأ بكتابة الألعاب على حواسيب Acorn ذات معالج 6502. ومن أعماله المبكرة Free Fall، التي صدرت على BBC Micro عام 1983. وهذا مهم لأن Free Fall تُظهر أن Elite لم تظهر فجأة من العدم؛ Bell كان بالفعل يحاول استغلال الحاسوب لصناعة تجربة تعتمد على الحركة والرسوم والمحاكاة قبل تعاونه مع David Braben. ويكيبيديا

3. ثم ظهر David Braben

التعاون بين Bell وBraben من أكثر الشراكات إثارة في تاريخ البرمجة المبكرة، لأن الاثنين لم يكونا فريقًا تقليديًا داخل شركة. كانا طالبين جامعيين يتبادلان الأقراص المرنة ويطوران البرنامج في أوقات فراغهما.

Bell نفسه وصف تقسيم العمل بأنه لم يكن صارمًا: كان أقوى في الرياضيات، بينما كان Braben أقوى في العتاد في البداية، ثم أخذ كل منهما يتعلم من الآخر. وفي مقابلة لاحقة أوضح أن العمل كان يتم بإرسال أقراص 5¼ بوصة بالبريد ثم دمج أجزاء البرنامج. Kean W

وهذا تفصيل مهم جدًا لفهم Bell: هو ليس مبرمجًا يعمل منفردًا على “تحفة غامضة”، بل جزء من نظام تطوير بدائي جدًا اضطر فيه المبرمجان إلى تصميم طريقة تعاون تناسب غياب أدوات التعاون الحديثة نفسها.

4. Free Fall: المختبر الذي سبق Elite

Free Fall مهمة في مسرد Bell لأنها تكشف شيئًا عن منهجه: لم يكن اهتمامه منصبًا فقط على “اللعبة” كمنتج، بل على إمكانات الحاسوب الرسومية والحركية.

كان يريد تجربة ثلاثية الأبعاد، ومن هذه الرغبة تطورت فكرة Elite. وتذكر مواد Acorn المعاصرة أن Bell كان صاحب الفكرة الأولية لمتابعة Free Fall بلعبة محاكاة ثلاثية الأبعاد في الفضاء، بينما أضاف Braben سيناريو التجارة والسفن. أكورني

إذن Free Fall يمكن النظر إليها باعتبارها مرحلة إثبات مفهوم: Bell يختبر ما يمكن للحاسوب فعله، ثم ينتقل إلى مشروع أكبر بكثير.

5. Elite: البرنامج الذي رفض أن يكون بحجم جهازه

صدر Elite عام 1984 على BBC Micro، وكتبه Bell وBraben بلغة Assembly لمعالج 6502. وكان الجهاز نفسه محدودًا بصورة تجعل طموح المشروع شبه غير معقول بمقاييس اليوم.

لكن المفاجأة ليست أن البرنامج كان مضغوطًا؛ المفاجأة أنه لم يتعامل مع الذاكرة الصغيرة باعتبارها مجرد عائق. Bell وصف التحدي لاحقًا بوضوح: كان الأمر يصل إلى توفير بايتات مفردة، وليس حتى كيلوبايتات. Kean W

وهنا تظهر شخصية Bell البرمجية بوضوح: التفكير ليس “كيف أكتب هذا البرنامج؟”، وإنما:

ما أقل تمثيل ممكن للشيء الذي أريد أن أجعله موجودًا؟

وهذا فرق جوهري بين البرمجة في بيئة وفيرة الموارد والبرمجة على أجهزة 8-bit.

6. الخدعة الكبرى: لا تخزن العالم، ولّد العالم

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

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

وهنا تتقاطع مساهمة Bell مع الرياضيات بصورة مباشرة: الخوارزمية تصبح وسيلة ضغط للواقع.

بدل:

بيانات ضخمة ⇨ تخزين ⇨ استرجاع

نحصل على:

بذرة/حالة ⇨ خوارزمية ⇨ عالم

وهذه الفكرة ستصبح لاحقًا مركزية في procedural generation، وألعاب العوالم المفتوحة، والمحاكاة، وحتى بعض أشكال توليد المحتوى الحديثة.

7. الثلاثية الأبعاد دون نموذج ثلاثي الأبعاد ضخم

المشكلة الثانية كانت الرسوم.

كان على البرنامج أن يعرض سفنًا يمكنها الدوران والحركة في فضاء ثلاثي الأبعاد، بينما قدرات الجهاز الرسومية محدودة جدًا. النتيجة لم تكن “ثلاثية الأبعاد” بالمعنى الحديث القائم على rasterized polygons وGPU، وإنما هندسة خطوطية محسوبة برمجيًا.

وهنا تصبح الرياضيات التي درسها Bell جزءًا من البرمجة نفسها: إحداثيات، دوران، إسقاط، ترتيب، وحساب ما ينبغي رسمه وما لا ينبغي رسمه.

وتوضح المصادر البرمجية الحديثة التي أعادت توثيق الكود الأصلي أن Elite ما زال قابلًا للدراسة على مستوى كل سطر من Assembly الخاص بـ6502، وهو أمر نادر جدًا في أعمال من تلك الفترة. Elite

8. لكن مساهمة Bell ليست مساهمة Braben

وهنا توجد نقطة تستحق الدقة لأن تاريخ Elite كثيرًا ما يختزل الرجلين إلى “مؤلفين مشتركين”.

Bell نفسه أوضح في مقابلة حديثة أن Braben قام بالـ original ship plot ثم universe generation والتجارة، بينما قام Bell بجزء كبير من البرمجة، وخاصة في بعض الإصدارات اللاحقة. وفي نسخة NES تحديدًا قال Bell إنه قام بمعظم البرمجة. theregister

إذن لا يصح تحويل Elite إلى “اختراع Bell وحده”، كما لا يصح اختزاله في Braben وحده. قوته التاريخية تحديدًا تأتي من تكامل نمطين من التفكير: Braben في تصور النظام والعتاد وبعض البنى الأساسية، وBell في الرياضيات والبرمجة وتنفيذ عدد هائل من التفاصيل داخل القيود.

9. Bell كمبرمج Assembly

هذا هو السبب الذي يجعل وضع Bell بين كبار المبرمجين أكثر إثارة من وضعه فقط بين كبار مصممي الألعاب.

في عصر اليوم، يمكن للمبرمج أن يكتب:

createUniverse()
renderShip()
moveShip()

ويترك المترجم والمكتبات ونظام التشغيل وGPU تتكفل بالباقي.

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

10. المثير أن الكود نفسه أصبح أثرًا تاريخيًا

اليوم يمكن دراسة المصدر الأصلي لـElite بصورة لم تكن ممكنة بالنسبة إلى كثير من ألعاب العصر. موقع Elite on the 6502 يحتوي على المصدر الأصلي للإصدارات المختلفة مع توثيق سطر بسطر تقريبًا، ويشمل BBC Micro وAcorn Electron و6502 Second Processor وCommodore 64 وApple II وNES وغيرها. Elite

وهذا يجعل Bell حالة مميزة في قائمتك: نحن لا نعتمد فقط على وصف تاريخي لعمله؛ يمكننا فتح الكود نفسه ودراسة الطريقة التي كتب بها البرنامج.

بل إن بعض النسخ التي لم تُنشر مصادرها الأصلية أعيد بناؤها من خلال disassembly للنسخ الثنائية، وهو ما يجعل Elite أيضًا موضوعًا مهمًا في software archaeology. Elite

11. Elite لم تكن لعبة فضاء فقط

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

وهذا يجعل Bell أقرب إلى system programmer منه إلى مبرمج ألعاب بالمعنى الضيق.

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

12. الانتقال بين المنصات كان اختبارًا آخر

لم يتوقف العمل عند BBC Micro. انتقلت Elite إلى Commodore 64 ثم Apple II ثم NES، وكان على Bell وBraben التعامل مع منصات مختلفة جذريًا في قدراتها وتخطيطها.

المثير هنا أن تطوير نسخ Commodore 64 وApple II تم من بيئة BBC Micro باستخدام Programmer’s Development System، أي أن جهاز التطوير نفسه لم يكن بالضرورة الجهاز المستهدف. Elite

وهذا يضع Bell في سلسلة تاريخية مهمة جدًا: cross-platform development قبل أن تصبح أدوات التطوير متعددة المنصات أمرًا طبيعيًا.

13. NES تحديدًا يكشف حجم دوره

نسخة NES مهمة لأنها تثبت أن Bell لم يكن مجرد صاحب لعبة 1984 ثم اختفى.

بحسب Bell نفسه، قام بمعظم برمجة نسخة NES، بينما كان الأصل قد تطور إلى مشروع مختلف من ناحية العتاد وطريقة التعامل مع النظام. كما أن المصادر البرمجية الحديثة توثق نسخة NES ضمن سلسلة المصادر الأصلية المرتبطة بـBell وBraben. theregister

وهذا يعزز وصفه كمبرمج، لا مجرد “مؤلف لعبة”.

14. لماذا I = Ian Bell تعمل جيدًا بعد Hassabis؟

هناك خط تاريخي جميل جدًا في قائمتك هنا:

H — Hassabis ⇨ I — Bell

Hassabis يعمل في بيئة تستطيع فيها الحوسبة أن تتعلم وتبحث وتولد حلولًا معقدة باستخدام موارد هائلة.

Bell فعل شيئًا يكاد يكون معاكسًا:

موارد قليلة جدًا ⇨ خوارزمية ذكية جدًا ⇨ عالم يبدو ضخمًا.

إذا كان Hassabis يمثل توسيع القدرة الحسابية، فإن Bell يمثل تكثيف القدرة الحسابية.

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

15. Bell والبرمجة باعتبارها “ضغطًا”

يمكن حتى صياغة فلسفة Bell البرمجية بمفهوم واحد: compression through computation.

كلما استطاع البرنامج أن يحسب بدل أن يخزن، قلّت حاجته إلى الذاكرة.

كلما استطاع تمثيل جسم هندسي بمجموعة قليلة من النقاط والخطوط، قلّت البيانات.

كلما استطاع توليد مجرة من خوارزمية بدل جدول ضخم، أصبح العالم أكبر من حجم البرنامج.

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

16. مسيرته بعد Elite مختلفة عن Braben

وهنا تظهر إحدى أكثر النقاط إثارة في شخصيته.

Braben ذهب إلى تأسيس Frontier Developments وبناء سلسلة Elite الحديثة، بينما اتخذ Bell مسارًا أكثر هدوءًا، وعمل لاحقًا في هندسة البرمجيات، ومن بينها عمله في Autodesk. المصادر الحديثة تصفه بأنه انتقل من صناعة الألعاب إلى مجال computer-aided design. theregister

وهذا يجعل إدراجه في المسرد مختلفًا عن شخصيات مثل Hassabis: Bell لم يحاول تحويل نجاحه المبكر إلى إمبراطورية تقنية. أثره الأكبر ظل مركزًا في الكود والخوارزمية والبرنامج الذي صنعه.

17. والأهم: أنه لم يتخل عن الكود القديم

من أجمل التفاصيل التاريخية أن Bell أتاح مصادر Elite القديمة مجانًا عبر موقعه، الأمر الذي سمح لاحقًا لمجتمعات البرمجة والهندسة العكسية بدراستها وإعادة بنائها.

المشروع الحالي لتوثيق المصدر يؤكد أن ملفات BBC Micro cassette المنشورة من Bell هي المصدر الأصلي، وأن أجزاء من الإصدارات الأخرى أعيد بناؤها من binary disassembly. Elite

وهذا يعني أن Bell لم يترك لنا فقط نتيجة برمجية؛ ترك أيضًا إمكانية فحص عملية البرمجة نفسها.

18. ما الذي يجعل Elite عظيمة برمجيًا؟

ليست النقطة الأساسية أن Elite كانت “رسومها مبهرة بالنسبة لوقتها”، رغم صحة ذلك.

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

يمكن اختزال إنجاز Bell في:

6502 Assembly
⇨ هندسة ثلاثية الأبعاد
⇨ توليد إجرائي
⇨ محاكاة
⇨ إدارة ذاكرة شديدة الصرامة
⇨ تعدد أنظمة
⇨ قابلية نقل

وهذه تركيبة تجعل Elite أقرب إلى مختبر خوارزميات تفاعلي منه إلى لعبة تقليدية.

19. النقد التاريخي لمكانته

التحفظ الوحيد الذي ينبغي وضعه ليس على كونه مبرمجًا — فهذا واضح — وإنما على طبيعة نسبة الإنجاز إليه.

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

لكن هذا لا يقلل من قيمة Bell؛ بل يجعل توصيفه أدق: هو أحد المبرمجين المركزيين الذين جعلوا Elite ممكنة، وكان له دور كبير في التنفيذ البرمجي وفي النسخ اللاحقة.

وهذا في الحقيقة أكثر إثارة من أسطورة “العبقري المنفرد”: Elite نتاج تعاون هندسي حقيقي بين مبرمجين شابين يعملان في ظروف تقنية بدائية للغاية.

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

أرى أن Ian Bell مناسب جدًا لـ I، والأهم أن حرف I لا يحتاج إلى اسم مثل “IBM” أو شخصية مؤسسية لتبرير نفسه. Bell يعطي الحرف شخصية تقنية واضحة:

I — Ian Bell = Procedural / 3D / Low-level Game Programming

وهو أيضًا يضيف شيئًا لم يكن موجودًا في الأسماء السابقة: البرمجة كوسيلة لبناء عالم قابل للاستكشاف.

فإذا كان Codd قد جعل البيانات قابلة للبرمجة، وStrachey جعل معنى البرامج قابلًا للصياغة الرياضية، وHinton جعل البرنامج قادرًا على التعلم، فإن Bell جعل العالم نفسه ناتجًا عن البرنامج.

أهم أعمال Ian Bell

1. Free Fall (1983)

أول عمل بارز لـBell، ويمثل المرحلة التي كان فيها يختبر أفكار الحركة والفضاء والرسوم على BBC Micro قبل Elite. ويكيبيديا

2. Elite (1984)

العمل المركزي في مسيرته، بالاشتراك مع David Braben. كتبت النسخة الأصلية بلغة 6502 Assembly، ونُشرت بواسطة Acornsoft على BBC Micro. Elite

3. Elite — Commodore 64 (1985)

نقل البرنامج إلى منصة مختلفة، مع استخدام بيئة تطوير BBC Micro/PDS في عملية التطوير. Elite

4. Elite — Apple II (1986)

نسخة أخرى ضمن سلسلة النقل إلى معماريات 6502 مختلفة، وتوثقها مصادر الكود الحالية ضمن الأعمال الأصلية لـBell وBraben. Elite

5. Elite — NES (1991/1992)

أحد أهم أعمال Bell البرمجية اللاحقة في السلسلة؛ وقد ذكر أنه قام بمعظم برمجتها. theregister

6. مصدر Elite الأصلي

وهذا ربما أهم “منشور” تقني له: ليس كتابًا، وإنما source code يمكن دراسته وإعادة بنائه. الموقع الحالي يوثق المصدر الأصلي سطرًا بسطر تقريبًا، ويتيح دراسة بنية البرنامج الداخلية بدل الاكتفاء بلعبه. Elite

الخلاصة: Ian Bell ليس مجرد “مبرمج ألعاب ناجح”. أهميته في تاريخ البرمجة أنه أحد أوضح الأمثلة على المبرمج الذي يستخدم الرياضيات والخوارزميات لتعويض نقص الموارد. Elite لم تكن كبيرة لأن الحاسوب كان قادرًا على تخزين عالم كبير؛ كانت كبيرة لأن Bell وBraben وجدا طريقة تجعل الحاسوب الصغير يتصرف كما لو أنه يحتوي عالمًا أكبر بكثير منه. وهذا بالضبط نوع الإنجاز البرمجي الذي يجعل Bell مناسبًا جدًا لمسردك. Kean W

J — Jon Skeet

إذا كان Ian Bell يمثل في حرف I البرمجة منخفضة المستوى وصناعة عوالم كاملة تحت قيود 8-bit، فإن Jon Skeet يمثل في حرف J ظاهرة مختلفة تمامًا: المبرمج الذي أصبح مرجعًا عمليًا للغة من خلال الإجابة، والشرح، واختبار حدودها، وكتابة الكود نفسه.

وهنا تكمن قيمة Skeet في مسردك: تأثيره لم يأتِ من اختراع لغة أو تأسيس شركة أو بناء نظام تشغيل، وإنما من كونه أحد أكثر المبرمجين تأثيرًا في الثقافة العملية للبرمجة الحديثة، وخصوصًا C# و.NET. وهو مثال قوي على أن المبرمج العظيم يمكن أن يؤثر في أجيال من المبرمجين عبر المعرفة القابلة للتطبيق، لا عبر منتج برمجي واحد فقط.

1. من هو Jon Skeet؟

Jon Skeet هو مهندس برمجيات بريطاني، ارتبط اسمه بصورة خاصة بـ C# و.NET وStack Overflow، وعمل طويلًا في Google، كما ألّف سلسلة C# in Depth. وقد أصبح اسمه داخل مجتمع البرمجة مرادفًا تقريبًا للأسئلة العميقة حول التفاصيل الدقيقة للغة C# وسلوك بيئة .NET.

وهنا ينبغي التمييز بين نوعين من الشهرة البرمجية:

مبرمج مشهور لأن الناس يستخدمون برنامجه
مقابل
مبرمج مشهور لأن المبرمجين أنفسهم يستخدمون معرفته لفهم برامجهم.

Skeet ينتمي بقوة إلى النوع الثاني.

2. لماذا Stack Overflow مهم في قصته؟

ظهور Stack Overflow عام 2008 خلق نوعًا جديدًا من المكانة التقنية. لم يعد المبرمج يحتاج إلى أن يكون مؤلف نظام تشغيل أو لغة حتى يصبح شخصية مؤثرة؛ يمكنه أن يصبح مرجعًا لأن إجاباته نفسها تتحول إلى قاعدة معرفة يستخدمها الملايين.

وهنا كان Skeet استثنائيًا.

ملفه في Stack Overflow أصبح من أشهر الملفات في تاريخ الموقع، مع عدد ضخم جدًا من الإجابات والتصويتات. لكن الرقم وحده ليس هو النقطة الأهم؛ الأهم هو أن كثيرًا من إجابات Skeet لا تكتفي بـ:

“استخدم هذه الدالة.”

بل تشرح لماذا يحدث السلوك أصلًا.

وهذا فارق مهم جدًا بين إجابة برمجية وحل قابل لإعادة الاستخدام.

3. البرمجة عند Skeet = فهم اللغة نفسها

في حالة Ian Bell، كان السؤال:

كيف أجعل هذا الحاسوب الصغير يفعل شيئًا يبدو مستحيلًا؟

أما عند Skeet فالسؤال غالبًا:

ماذا يعني هذا الكود بالضبط؟

وهذا يقوده إلى الطبقات الداخلية للغة:

• type system
• generics
• delegates
• LINQ
• iterators
• async
• exceptions
• equality
• nullable types
• overload resolution
• closures
• reflection
• date/time
• concurrency

أي أن Skeet لا يتعامل مع C# باعتبارها مجموعة أوامر فقط، بل باعتبارها نظامًا لغويًا له دلالات دقيقة.

4. C# in Depth

أهم عمل أدبي وتقني مرتبط بـSkeet هو بلا شك:

C# in Depth

الكتاب بدأ في عصر C# 2.0، ثم تطور مع تطور اللغة عبر إصدارات متعددة.

وهذه نقطة مهمة: الكتاب ليس كتابًا لتعلم كتابة:

Console.WriteLine("Hello");

بل يحاول الوصول إلى المنطقة التي يبدأ فيها المبرمج في التساؤل:

لماذا صممت اللغة هذه الخاصية بهذه الطريقة؟ وماذا يحدث عندما تتفاعل هذه الخاصية مع خاصية أخرى؟

وهنا تظهر موهبة Skeet الحقيقية.

5. الكتاب ليس مجرد Manual

الـmanual يقول لك ماذا تفعل.

أما C# in Depth فيحاول أن يقول لك:

كيف تفكر في اللغة؟

وهذا فرق كبير.

فمثلًا، حين يناقش Skeet LINQ أو generics أو delegates، لا يقدمها كميزات منفصلة فقط، بل يضعها داخل التطور التاريخي للغة، ويشرح المشاكل التي كانت موجودة قبل ظهور الميزة، ثم يوضح ما الذي حلته، وما الحدود التي بقيت.

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

6. Skeet والمفارقة في شهرة المبرمج

المثير أن كثيرًا من المبرمجين الذين يتصدرون التاريخ هم أشخاص اخترعوا شيئًا جديدًا.

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

وهذه ليست مساهمة ثانوية.

اللغات الحديثة معقدة جدًا؛ ويمكن لمبرمج أن يستخدم C# سنوات دون أن يفهم بدقة كيفية تفاعل:

generic type inference + overload resolution + covariance/contravariance + closures

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

7. علاقته بـC# ليست علاقة مستخدم عادي

Skeet ليس من مؤلفي C# الأصليين، وهذه نقطة مهمة جدًا.

C# نشأت داخل Microsoft بقيادة Anders Hejlsberg وفريق اللغة، ولذلك لا ينبغي نسب اختراع C# إلى Skeet.

لكن مساهمته تقع في طبقة أخرى:

مصمم اللغة ⇨ مبرمج محترف ⇨ شارح عميق ⇨ مجتمع المبرمجين

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

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

8. علاقته بـJava أيضًا مثيرة

قبل أن يصبح اسمه مرتبطًا بـC#، عمل Skeet في بيئات Java أيضًا.

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

وهذا يظهر في أسلوبه التعليمي: لا يتعامل مع C# باعتبارها جزيرة منفصلة، بل يشرح كثيرًا من خصائصها ضمن تاريخ لغات البرمجة والـruntime والـAPI.

9. Google

عمل Skeet في Google، وهو ما يضعه في بيئة برمجية مختلفة تمامًا عن البيئة التي جعلته مشهورًا عبر Stack Overflow.

وهذه النقطة مهمة لأن Stack Overflow قد يعطي انطباعًا بأنه “كاتب إجابات” فقط.

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

وهذا يفسر أيضًا لماذا تأتي كثير من إجاباته من زاوية هندسية عملية بدل أن تكون تنظيرًا لغويًا مجردًا.

10. Skeet والمشكلة الأصعب: التفاصيل الصغيرة

من أهم خصائصه أنه لا يتوقف عند المستوى الذي يكون فيه الكود “يعمل”.

المبرمج المتوسط قد يقول:

الكود يعمل.

أما Skeet فيسأل:

لماذا يعمل؟
هل سيظل يعمل إذا تغير النوع؟
ماذا يحدث عند null؟
ماذا يحدث في حالة inheritance؟
ماذا يفعل compiler؟
ماذا يفعل runtime؟
هل السلوك مضمون في specification أم مجرد implementation detail؟

وهذا النوع من التفكير مهم جدًا في البرمجة الاحترافية.

فالبرنامج الذي يعمل بالصدفة ليس مساويًا للبرنامج الذي يعمل بسبب فهم صحيح لدلالات اللغة.

11. وهذا يقربه من Christopher Strachey

هنا تظهر صلة جميلة جدًا داخل قائمتك.

Christopher Strachey كان مهتمًا بالسؤال:

ما المعنى الرياضي لما يفعله البرنامج؟

أما Jon Skeet فيمارس نسخة عملية حديثة من هذا النوع من التفكير:

ما المعنى الدقيق لهذا التعبير في C#؟

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

لكن هناك قرابة منهجية واضحة:

الكود ليس مجرد نص ⇨ للكود دلالة ⇨ والدلالة يجب فهمها بدقة.

12. Skeet والتعليم من خلال الأمثلة

واحدة من أقوى أدواته هي المثال الصغير.

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

هذه طريقة ممتازة في تعليم البرمجة لأن المثال يصبح تجربة.

تغير سطرًا واحدًا ⇨ يتغير الناتج ⇨ فتكتشف قاعدة اللغة.

ومن هنا يمكن النظر إلى جزء كبير من أعمال Skeet باعتباره نوعًا من experimental programming.

13. Noda Time

وهنا نصل إلى مساهمة برمجية أكثر مباشرة.

Skeet هو المؤلف الأساسي لـ Noda Time، وهي مكتبة .NET للتعامل مع التاريخ والوقت.

لماذا التاريخ والوقت تحديدًا؟

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

“الساعة 10 صباحًا” ليست كيانًا واحدًا بالضرورة.

لدينا:

• instant
• local date
• local time
• time zone
• offset
• duration
• period
• calendar

وهذا قريب جدًا من فلسفة Skeet العامة:

لا تجعل الكائن البرمجي يخفي اختلاف المفاهيم الحقيقية.

وهنا تتحول مساهمته من التعليم إلى تصميم API.

14. Noda Time أكثر أهمية مما يبدو

يمكن النظر إلى Noda Time كامتداد طبيعي لأفكار C# in Depth.

في الكتاب:

يفكك اللغة.

في Noda Time:

يفكك مفهوم الزمن نفسه إلى نماذج برمجية واضحة.

وهذا فارق مهم.

Skeet لا يكتفي بإخبارك بأن التعامل مع الوقت صعب؛ بل يعيد تصميم الـAPI بحيث يصبح من الصعب على المبرمج أن يخلط بين مفاهيم مختلفة.

وهذه ممارسة ناضجة جدًا في هندسة البرمجيات.

15. كتابه عن Noda Time

ألف Skeet أيضًا كتابًا حول Noda Time بعنوان:

More Effective C#

لكن الأهم في هذا السياق هو أن Noda Time ظهرت في كتاباته ومشاريعه كحالة تطبيقية لفكرة أوسع: تصميم الأنظمة بحيث تعكس الأنواع المفاهيم الحقيقية بدل استخدام أنواع عامة لكل شيء.

وهذا يربط بين Skeet وبين تقاليد قوية في typed programming.

16. لماذا لا أضعه فقط تحت “كاتب تقني”؟

لأن ذلك سيكون تقليلًا لدوره.

لدينا ثلاثة مستويات في عمله:

1. Programmer
كتب برامج ومكتبات حقيقية.

2. Software engineer
عمل في بيئات إنتاجية كبيرة.

3. Programming authority
ساهم في تشكيل الطريقة التي يتعلم بها عدد هائل من المبرمجين C# و.NET.

والميزة النادرة هنا أن المستويات الثلاثة متداخلة.

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

17. موقعه بين أسماء قائمتك

يمكن بناء خط مثير:

Babbage ⇨ Strachey ⇨ Codd ⇨ Fowler ⇨ Bell ⇨ Skeet

Babbage: كيف نجعل الآلة قابلة للبرمجة؟

Strachey: ما هي طبيعة البرنامج واللغة؟

Codd: كيف نمثل المعلومات؟

Fowler: كيف نحافظ على بنية البرامج ونطورها؟

Bell: كيف نضغط عالمًا كاملًا داخل برنامج صغير؟

Skeet: كيف نفهم اللغة التي نكتب بها هذا البرنامج بأقصى دقة؟

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

18. نقطة القوة الأساسية في Skeet

لو اضطررت إلى تحديد أهم شيء في إرثه فلن أختار عدد إجاباته ولا حتى شهرة C# in Depth وحدها.

سأختار:

تحويل التفاصيل الخفية للغة إلى معرفة عامة قابلة للتدريس.

وهذا مهم لأن كثيرًا من أخطاء البرمجة لا تأتي من عدم معرفة syntax، بل من النموذج الذهني الخاطئ.

Skeet قوي تحديدًا في إصلاح النموذج الذهني.

19. حدود مكانته

لكن تاريخيًا يجب ألا ننسب إليه ما لم يفعله.

هو ليس مخترع C#، ولا مصمم .NET الأصلي، ولا صاحب Stack Overflow، ولا مؤسس نموذج البرمجة الحديثة الذي تستخدمه C#.

قيمته مختلفة: هو واحد من أبرز الممارسين والمفسرين والمصممين والمساهمين في بيئة C#/.NET.

وهذا في حد ذاته نوع مشروع من العظمة البرمجية، لكنه عظمة من نوع مختلف عن Babbage أو Strachey.

20. الحكم داخل مسردك

J — Jon Skeet اختيار قوي جدًا إذا كان معيارك هو “أعظم المبرمجين البريطانيين”، خصوصًا إذا كنت لا تحصر العظمة في اختراع لغة أو نظام تشغيل.

بل إن اختيار Skeet يعطي المسرد شيئًا كان ينقصه: المبرمج الذي جعل المعرفة البرمجية نفسها منتجًا هندسيًا.

يمكن تلخيص نوعه هكذا:

Jon Skeet = Deep language understanding + .NET engineering + programming pedagogy + API design

وهذا يختلف جذريًا عن Ian Bell، لكنه يكمل السلسلة بصورة ممتازة.

أهم أعمال Jon Skeet

C# in Depth

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

Noda Time

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

Stack Overflow contributions

ليست “مؤلفًا” بالمعنى التقليدي، لكنها جزء أساسي من إرثه؛ فقد أصبحت إجاباته مصدرًا مرجعيًا هائلًا لفهم C# و.NET، خصوصًا في المسائل الدقيقة التي لا تكفي فيها معرفة syntax.

Code samples / experiments

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

وبذلك، إذا كان Ian Bell هو مبرمج “العالم المتولد خوارزميًا”، فإن Jon Skeet هو مبرمج “اللغة المفككة إلى مبادئ”. وهذا يجعله اختيارًا مميزًا جدًا لحرف J.

K — Karen Spärck Jones

اختيار Karen Spärck Jones لحرف K قوي جدًا، بل إنه يفتح في مسردك مجالًا لم يكن قد ظهر بهذه الصورة الصريحة من قبل: البرمجة باعتبارها تنظيمًا للمعرفة والبحث فيها.

هي ليست مبرمجة بالمعنى التقليدي لمبرمج أنظمة التشغيل أو الألعاب، لكنها من الشخصيات التي جعلت الحاسوب قادرًا على التعامل مع النصوص والوثائق واللغة والمعلومة بصورة منهجية. بدأت أبحاثها في أواخر الخمسينيات، وأصبحت من الرواد في Information Retrieval (IR) وNatural Language Processing (NLP). كامبردج

والأهم أن أحد المفاهيم التي ارتبطت بعملها — Inverse Document Frequency (IDF) — أصبح جزءًا أساسيًا من تاريخ محركات البحث واسترجاع المعلومات، ثم دخل لاحقًا في تطبيقات لغوية وحاسوبية واسعة. كامبردج

1. لماذا Karen Spärck Jones مهمة في قائمة المبرمجين؟

إذا كان Jon Skeet في J يمثل المبرمج الذي يفكك لغة البرمجة ويفهم دلالاتها الدقيقة، فإن Spärck Jones في K تمثل خطوة مختلفة:

كيف نجعل الحاسوب يفهم أي المعلومات أهم من غيرها؟

وهذا سؤال يبدو بسيطًا، لكنه في الحقيقة أحد الأسئلة المؤسسة للبحث الرقمي.

محرك البحث لا يحتاج فقط إلى العثور على الكلمات الموجودة في الوثائق. المشكلة الأصعب هي:

إذا وجدت الكلمة نفسها في ألف وثيقة، فهل هي مفيدة فعلًا في التمييز بينها؟

هنا تبدأ مساهمة Spärck Jones.

2. البداية لم تكن بمحركات البحث

بدأت Spärck Jones أبحاثها في Cambridge Language Research Unit في أواخر الخمسينيات، في بيئة كانت مهتمة بالترجمة الآلية ومعالجة اللغة.

وكان العمل المبكر يدور حول استخدام thesauri والتصنيف الدلالي للغة.

وهنا توجد نقطة تاريخية شديدة الأهمية: الحوسبة اللغوية في ذلك الوقت لم تكن تشبه NLP الحالي. لم يكن هناك Transformer ولا embeddings ولا LLMs.

كان السؤال الأساسي:

كيف يمكن تحويل اللغة البشرية إلى تمثيل يمكن للآلة التعامل معه؟

وهذا يضع Spärck Jones في طبقة مبكرة جدًا من السلسلة التي ستؤدي بعد عقود إلى Google وBERT وChatGPT.

3. أطروحتها كانت مبكرة جدًا

كانت أطروحتها للدكتوراه بعنوان:

Synonymy and Semantic Classification

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

وهذا مثير جدًا بالنسبة إلى قائمتك.

لأننا اليوم نتحدث كثيرًا عن الجمع بين:

symbolic AI + statistical / neural AI

لكن Spärck Jones كانت تعمل على مشكلة مشابهة في مرحلة مبكرة جدًا، وإن كانت الأدوات والمفاهيم مختلفة جذريًا.

أي أنها لم تكن فقط “باحثة استرجاع معلومات”؛ كان لديها منذ البداية اهتمام بالسؤال الأوسع:

كيف نمثل المعنى بحيث تستطيع الآلة استخدامه؟

4. ثم انتقلت إلى Information Retrieval

في الستينيات انتقلت Spärck Jones إلى مجال استرجاع المعلومات. وتوضح جامعة كامبريدج أنها بدأت العمل فيه خلال تلك الفترة وركزت على المقاربات الإحصائية، مع مساهمات مبتكرة في term weighting. كامبردج

وهنا حدث التحول الأساسي في مسيرتها.

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

ما معنى الكلمة؟

بل أصبح:

ما قيمة الكلمة بالنسبة إلى مجموعة الوثائق؟

وهذا تغيير عميق.

5. الفكرة الأشهر: IDF

لنفترض أن لدينا مليون وثيقة.

كلمة مثل:

the

ستظهر في عدد هائل منها.

إذن وجودها في وثيقة معينة لا يخبرنا بالكثير.

لكن كلمة متخصصة مثل:

photosynthesis

قد تظهر في عدد أقل بكثير من الوثائق.

إذن ظهورها قد يكون أكثر فائدة في تحديد موضوع الوثيقة.

هذه هي الفكرة التي تقف خلف Inverse Document Frequency:

كلما كان المصطلح منتشرًا في عدد أكبر من الوثائق ⇨ قلت قدرته على التمييز.

وبالعكس:

كلما كان نادرًا نسبيًا ⇨ زادت قيمته التمييزية.

وهذه ليست مجرد ملاحظة لغوية؛ إنها تحويل لمفهوم “الأهمية” إلى وزن رياضي يمكن للبرنامج استخدامه.

6. لماذا هذه الفكرة عظيمة برمجيًا؟

لأن Spärck Jones لم تكن تحاول تعليم الآلة معنى الكلمة بالطريقة التي نتخيلها اليوم.

هي فعلت شيئًا أكثر تواضعًا وأكثر عملية:

أعطت الآلة طريقة لقياس قيمة الكلمة.

وهذه نقطة فارقة.

فبدل أن نقول:

هذه الوثيقة تتحدث عن X.

يمكن للنظام أن يحسب:

المصطلحات الموجودة هنا أكثر تمييزًا من المصطلحات الموجودة في معظم الوثائق الأخرى.

وهكذا يتحول الاستدلال على الصلة relevance إلى عملية حسابية.

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

7. المعادلة الشهيرة ليست مجرد رياضيات

في الصياغات الشائعة لـTF-IDF، لدينا تقريبًا:

TF ⇨ كم يظهر المصطلح في الوثيقة

و

IDF ⇨ مدى ندرة المصطلح عبر مجموعة الوثائق

ثم:

TF-IDF ⇨ أهمية المصطلح داخل الوثيقة بالنسبة إلى المجموعة كلها

لكن الأهم فلسفيًا هو أن Spärck Jones ساعدت في تحويل مفهوم لغوي غامض مثل specificity إلى متغير قابل للحساب.

وهذا بالضبط نوع التحول الذي يميز علوم الحاسوب:

مفهوم بشري ⇨ نموذج رياضي ⇨ خوارزمية ⇨ نظام قابل للتنفيذ.

8. ورقتها المؤسسة

من أهم أعمالها:

“A statistical interpretation of term specificity and its application in retrieval” (1972)

ونشرت في Journal of Documentation. وتظهر الورقة ضمن قائمة منشوراتها الرسمية في كامبريدج، كما أعيد نشرها لاحقًا في مجموعات أوراق أساسية في علم المعلومات. كامبردج

هذه الورقة مهمة لأنها تضع specificity في إطار إحصائي يمكن استخدامه في retrieval.

ومن هنا يأتي الرابط المباشر بينها وبين أنظمة البحث التي ستظهر لاحقًا.

9. من IDF إلى محركات البحث

ينبغي هنا تجنب تبسيط التاريخ إلى:

Spärck Jones ⇨ Google

فهذا غير صحيح.

Google لم تُبن ببساطة على معادلة واحدة، ومحركات البحث الحديثة تستخدم طبقات ضخمة من تقنيات الترتيب والفهرسة والدلالات والتعلم الآلي.

لكن مساهمة Spärck Jones تقع في السلالة الفكرية التي تجعل البحث الآلي ممكنًا:

وثائق ⇨ مصطلحات ⇨ أوزان ⇨ صلة ⇨ ترتيب نتائج

وهذا هو السبب الذي يجعل اسمها حاضرًا في تاريخ information retrieval حتى لو لم تكتب هي محرك بحث تجاريًا عالميًا.

10. علاقتها بـStephen Robertson

أحد أهم تعاوناتها كان مع Stephen Robertson.

معًا عملا على relevance weighting، وهي خطوة مهمة في تطور النماذج الاحتمالية لاسترجاع المعلومات. وتدرج كامبريدج عملهما المشترك Relevance weighting of search terms المنشور عام 1976، إضافة إلى أعمال لاحقة حول النماذج الاحتمالية للاسترجاع. كامبردج

وهنا تتوسع الفكرة:

IDF يسأل:

ما مدى تمييز هذا المصطلح؟

لكن relevance weighting يسأل:

ما مدى صلة هذا المصطلح تحديدًا بما يبحث عنه المستخدم؟

وهذا انتقال من خصائص النص إلى العلاقة بين النص واحتياج المستخدم.

11. هنا تظهر فلسفة Spärck Jones الحقيقية

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

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

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

وهذه الفكرة شديدة الحداثة.

فهي تقول ضمنيًا:

لا تستخدم الذكاء الاصطناعي لمجرد أنك تستطيع استخدامه.

افهم طبيعة المهمة أولًا.

وهذا موقف مختلف جدًا عن النزعة التي تفترض أن كل مشكلة تحتاج نموذجًا أكثر تعقيدًا.

12. وهذا يجعلها مثيرة جدًا بالنسبة لعصر LLM

يمكن وضع Spärck Jones في بداية سلسلة تصل اليوم إلى:

TF-IDF ⇨ probabilistic retrieval ⇨ BM25 ⇨ vector retrieval ⇨ embeddings ⇨ neural search ⇨ RAG

طبعًا لا يعني هذا أن كل خطوة من هذه اخترعتها هي؛ ذلك سيكون اختزالًا للتاريخ.

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

ولهذا، حين تستخدم اليوم نظامًا يسترجع وثائق من قاعدة معرفة، فأنت تعمل داخل مشكلة كانت Spärck Jones تدرس بنيتها قبل ظهور الويب أصلًا.

13. لم تكن IR فقط

بعد ذلك توسعت أبحاثها إلى مجالات كثيرة:

• automatic summarisation
• spoken document retrieval
• database querying
• user modelling
• information-system evaluation
• multimedia retrieval
• natural-language interfaces

وتذكر كامبريدج مشاريعها في Automatic Summarising، Belief Revision for Information Retrieval، Video Mail Retrieval، Multimedia Document Retrieval وغيرها. كامبردج

إذن IDF لم تكن نهاية مشروعها؛ كانت واحدة من اللبنات التي انطلقت منها إلى سؤال أكبر:

كيف نجعل الآلة تستقبل سؤال الإنسان وتبحث في المعرفة المناسبة ثم تعيدها إليه؟

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

14. التلخيص الآلي

كان automatic summarisation من اهتماماتها المتأخرة.

وهذا منطقي جدًا بالنسبة إلى مسارها.

إذا كانت المرحلة الأولى:

أين توجد الوثيقة؟

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

ما الوثيقة الأكثر صلة؟

فالسؤال التالي:

ما الجزء الأكثر أهمية داخل الوثيقة؟

ثم:

كيف أختصره؟

وهكذا ينتقل النظام من retrieval إلى selection ثم summarisation.

وهذا يقرب أعمالها بصورة لافتة من سير العمل الذي تستخدمه أنظمة البحث الحديثة.

15. Natural Language Interfaces to Databases

من أعمالها أيضًا البحث في natural language interfaces to databases، ومن بينها تعاونها مع Ann Copestake في Inference in a natural language front end for databases وNatural language interfaces to databases. كامبردج

هذه نقطة مهمة جدًا في قائمتك لأنها تربطها مباشرة بـ Codd.

Codd قال تقريبًا:

كيف نمثل البيانات بصورة مجردة ومنظمة؟

Spärck Jones تسأل:

كيف يستطيع الإنسان أن يسأل النظام عن تلك البيانات بلغته الطبيعية؟

إذن:

Codd ⇨ data model

ثم:

Spärck Jones ⇨ human-language access to information

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

16. التقييم عندها كان جزءًا من العلم نفسه

من أهم ما فعلته Spärck Jones أنها لم تكتفِ ببناء أنظمة retrieval؛ كانت مهتمة جدًا بـ كيفية تقييمها.

كانت عضوًا في لجان DARPA/NIST Text Retrieval Conferences (TREC) منذ 1994، وشاركت كذلك في برامج تقييم التلخيص الآلي. وتصفها كامبريدج بأنها كانت شخصية محورية في مجتمع التقييم، وأسهمت في وضع معايير أثرت في قدر كبير من أبحاث NLP. كامبردج

وهذا بالغ الأهمية.

لأن البحث الذي لا يُقاس قد يتحول إلى انطباعات:

“هذا النظام يبدو أفضل.”

أما Spärck Jones فالسؤال يصبح:

أفضل وفق أي معيار؟ وبأي مجموعة اختبار؟ وبأي طريقة مقارنة؟

وهذا أحد أسباب أهمية إرثها حتى خارج IDF.

17. وهذه نقطة تربطها مباشرة بمشروعك في البحث

إذا أخذنا مفهومك عن Zero Search بوصفه نظامًا يعتمد على التصنيف والفهرسة والـretrieval، فإن Spärck Jones تقع في جذور المشكلة نفسها.

لكنها كانت تبدأ من:

term → document relevance

بينما مشروعك يتحرك نحو:

intent → category → index → document/answer

أي أن هناك تطورًا مفاهيميًا:

الكلمة

⇨

الوثيقة

⇨

الاستعلام

⇨

نية المستخدم

⇨

مسار معرفي

ومن هذه الزاوية تحديدًا، وجود Spärck Jones في مسردك ليس مجرد تكريم تاريخي؛ هي واحدة من الشخصيات التي جعلت البحث نفسه موضوعًا هندسيًا وعلميًا.

18. مكانتها كعالمة ومبرمجة

هناك نقطة تستحق الحسم في تصنيفها داخل قائمتك.

Spärck Jones ليست “programmer” بالمعنى الضيق لمبرمج التطبيقات التجارية.

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

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

لذلك نوع برمجتها يمكن تسميته:

Information Retrieval Programming / Computational Linguistics / NLP

19. علاقتها بـAda Lovelace

وهنا توجد مصادفة جميلة جدًا في مسردك.

Ada Lovelace في A كانت من أوائل من تصوروا أن الآلة يمكن أن تتعامل مع رموز تتجاوز الحساب العددي.

بعد أكثر من قرن:

Karen Spärck Jones تجعل الآلة تتعامل مع الكلمات والوثائق والمعنى الإحصائي للمصطلحات.

أي أن الخط التاريخي يمكن قراءته هكذا:

Lovelace: الرموز ⇨ Spärck Jones: اللغة ⇨ Hinton: التمثيل المتعلم ⇨ Hassabis: أنظمة الذكاء الاصطناعي

وهذا يجعلها حلقة مهمة جدًا في قائمتك.

20. وهي أيضًا جسر بين الرمزي والإحصائي

هذا ربما أفضل وصف فكري لها.

في بدايتها كانت تعمل على semantic classification وthesauri، أي أن هناك بنية لغوية ودلالية صريحة.

ثم انتقلت إلى:

statistics + term weighting + retrieval

ثم إلى NLP، summarisation، user modelling، evaluation وغيرها.

أي أنها لم تكن أسيرة مدرسة واحدة.

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

21. كتبها وأعمالها المنشورة

تذكر السيرة الرسمية في كامبريدج أن Spärck Jones نشرت نحو 230 عملًا، منها 9 كتب. كامبردج

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

Automatic Keyword Classification for Information Retrieval — 1971

عمل أساسي في تطور أفكار التصنيف الآلي والاسترجاع.

Readings in Information Retrieval — 1997

بالاشتراك مع Stephen Walker وStephen Robertson وآخرين بحسب الطبعة/المادة، ويعكس دورها في تأسيس corpus معرفي لمجال IR.

Evaluating Natural Language Processing Systems — 1996

بالاشتراك مع Julia Galliers، وهو مهم لأنه يركز على المشكلة التي أصبحت إحدى قضايا NLP الأساسية: كيف نعرف أن النظام جيد؟

Some Points in a Time — 2005

مقالة/خطاب تأملي مهم يلخص جانبًا من مسيرتها الفكرية، ونشر في Computational Linguistics. كامبردج

22. أهم أوراقها

إذا أردنا اختزال إرثها إلى مجموعة صغيرة جدًا من الوثائق:

1. A statistical interpretation of term specificity and its application in retrieval (1972)
2. Relevance weighting of search terms (1976) — مع Stephen Robertson
3. Information retrieval test collections (1976) — مع C. J. van Rijsbergen
4. Experiments in relevance weighting of search terms (1979)
5. The role of artificial intelligence in information retrieval (1990/1991)
6. Automatic summarising: factors and directions (1999)
7. Information retrieval and artificial intelligence (1999)
8. Some points in a time (2005)

وكل هذه مدرجة ضمن السجل الرسمي لمنشوراتها في كامبريدج. كامبردج

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

مستوى الاعتراف العلمي بها كان استثنائيًا:

• ACM SIGIR Salton Award — 1988
• Fellow of the American Association for Artificial Intelligence — 1993
• Fellow of the British Academy — 1995
• ACL Lifetime Achievement Award — 2004
• ACM–AAAI Allen Newell Award — 2006
• ACM Athena Lecturer — 2007
• BCS Lovelace Medal — 2007 كامبردج

واللافت أن Lovelace Medal تحديدًا أعاد اسمها إلى بداية قائمتك: Ada Lovelace.

24. التقييم النهائي لمكانها في المسرد

Karen Spärck Jones من الأسماء التي ترفع المستوى المفاهيمي للمسرد.

ليست قوتها في أنها كتبت ملايين الأسطر من الكود، ولا في أنها أنشأت منتجًا تجاريًا ضخمًا.

قوتها في أنها أخذت سؤالًا بشريًا غامضًا:

“أي الكلمات والمعلومات أكثر أهمية بالنسبة إلى ما أبحث عنه؟”

وحولته إلى:

تمثيل ⇨ وزن ⇨ استرجاع ⇨ ترتيب ⇨ تقييم

وهذه سلسلة تكاد تكون هي البنية التحتية الفكرية للبحث المعلوماتي الحديث.

ولهذا فإن K — Karen Spärck Jones ليست مجرد اختيار مناسب؛ إنها تمثل في قائمتك نوعًا بالغ الأهمية من البرمجة:

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

وهذا يجعلها حلقة شديدة القوة بين Codd في نمذجة البيانات، وFowler في هندسة البرمجيات، وHinton في التعلم الآلي، ثم لاحقًا أنظمة البحث والاسترجاع العصبية الحديثة. كامبردج

Lee, Tim Berners

L — Tim Berners-Lee

Tim Berners-Lee هو أحد أقوى الأسماء في مسردك حتى الآن، ليس فقط لأن اسمه ارتبط بالـWorld Wide Web، بل لأن مساهمته تجمع عدة طبقات من البرمجة في شخص واحد: أنظمة التشغيل، البرمجة الشبكية، البرمجة الموزعة، hypertext، لغة توصيف، بروتوكول اتصال، عناوين موارد، متصفح، خادم، ثم هندسة معايير عالمية. وهو لذلك ليس مجرد “مخترع الويب”، بل مبرمج بنى نموذجًا برمجيًا جديدًا للمعلومات المتصلة.

والأهم أن هذا الوصف لا يعتمد على الأسطورة اللاحقة. فـW3C وCERN يوثقان أنه اخترع الويب في CERN عام 1989، وكتب أول خادم ويب وأول عميل/متصفح ومحرر عام 1990، ووضع الصيغ الأولية لـHTML وHTTP وURI. W3C

1. لماذا Berners-Lee مهم جدًا في مسرد المبرمجين؟

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

وهذا بالضبط ما يجعل Berners-Lee مختلفًا.

Ian Bell أخذ حاسوبًا محدودًا وصنع منه عالمًا افتراضيًا.
Karen Spärck Jones جعلت الآلة أكثر قدرة على العثور على المعلومات.
أما Berners-Lee فذهب خطوة أخرى:

كيف نجعل المعلومات الموجودة على حواسيب مختلفة تبدو كأنها فضاء معلومات واحد؟

هذه هي الفكرة الجوهرية للويب.

2. لكنه كان مبرمجًا قبل الويب بوقت طويل

وصف Berners-Lee بأنه “مخترع الإنترنت” خطأ شائع؛ فالإنترنت كان موجودًا قبله. مساهمته كانت World Wide Web فوق الإنترنت.

لكن الأهم في سياق قائمتك أن البرمجة لم تكن حادثة عرضية في حياته.

بعد تخرجه في الفيزياء من Oxford عام 1976، عمل في Plessey Telecommunications، حيث اشتغل على أنظمة المعاملات الموزعة، وترحيل الرسائل وتقنيات الباركود. ثم انتقل إلى D.G. Nash، حيث كتب برامج لتنضيد النصوص وطوّر نظام تشغيل متعدد المهام. W3C

أي أن الويب جاء بعد سنوات من هندسة البرمجيات والاتصالات والأنظمة.

3. وحتى حاسوبه الأول كان مشروعًا برمجيًا-عتاديًا

في الجامعة بنى Berners-Lee حاسوبه بنفسه باستخدام M6800 processor، ودوائر TTL وتلفاز قديم كشاشة. وتذكر سيرته في W3C أن هذه التجربة كانت جزءًا من بدايته مع الحوسبة. W3C

هذه المعلومة مهمة لأنها تكشف نمطًا سيستمر لاحقًا:

لا ينتظر طبقة جاهزة.

إذا احتاج إلى حاسوب، يبنيه.
إذا احتاج إلى نظام معلومات، يبرمجه.
إذا احتاج إلى لغة مستندات، يصوغها.
إذا احتاج إلى بروتوكول، يضعه.

وهذه إحدى أكثر السمات وضوحًا في مسيرته.

4. ENQUIRE: الويب كان موجودًا في ذهنه قبل أن يكون على الإنترنت

في عام 1980، أثناء عمله الاستشاري في CERN، كتب Berners-Lee برنامجًا شخصيًا اسمه ENQUIRE.

كان الهدف تنظيم المعلومات باستخدام روابط بين كيانات ومعلومات مختلفة. وكان يستطيع المستخدم الانتقال من عنصر إلى عنصر آخر عبر الروابط، بدل التعامل مع المعلومات باعتبارها ملفات مستقلة. W3C

وهنا تظهر الجذور الحقيقية للويب.

فالويب لم يبدأ بفكرة:

“سأصنع موقعًا.”

بل بفكرة أعمق:

سأجعل المعلومات شبكة من العلاقات.

5. ENQUIRE ليس World Wide Web

وهذه نقطة مهمة جدًا.

ENQUIRE لم يكن الويب الأول، ولم يكن بروتوكولًا عالميًا، ولم يكن نظامًا مفتوحًا للإنترنت.

لكنه كان النموذج الفكري الأول الذي سيكبر لاحقًا.

في ENQUIRE كانت هناك:

معلومات ⇨ كيانات ⇨ علاقات ⇨ روابط

وفي الويب أصبحت:

وثائق ⇨ موارد ⇨ URIs ⇨ روابط ⇨ شبكة عالمية

إذن الويب لم يظهر كاختراع منفصل في 1989؛ كان هناك أكثر من عقد من تراكم التفكير البرمجي خلفه.

6. CERN أعطاه المشكلة المثالية

عاد Berners-Lee إلى CERN عام 1984، وعمل في أنظمة الحوسبة والاتصالات وجمع البيانات العلمية. وفي مؤسسة ضخمة كهذه كانت المشكلة واضحة:

هناك حواسيب مختلفة، وأنظمة مختلفة، ووثائق مختلفة، ومجموعات بحثية مختلفة، ومعلومات تتغير باستمرار.

المشكلة لم تكن نقص المعلومات.

كانت تشتت المعلومات.

وهنا جاءت الفكرة التي ستغير الحوسبة.

7. اقتراح مارس 1989

في مارس 1989 قدم Berners-Lee إلى مديره Mike Sendall وثيقة بعنوان:

Information Management: A Proposal

وكانت الوثيقة تقترح نظامًا لإدارة المعلومات الموزعة داخل CERN.

كتب Sendall على المقترح العبارة الشهيرة:

“Vague, but exciting.”

لكن أهمية الوثيقة ليست في العبارة الشهيرة؛ بل في أنها تكشف أن Berners-Lee كان يفكر في بنية معلومات موزعة قبل أن تصبح WWW مشروعًا مكتمل الاسم والمواصفات. الموقع الرسمي للهجرة

8. الفكرة العبقرية: لا تجعل المستخدم يهتم بمكان المعلومة

هذه ربما أهم نقطة تقنية في اختراع الويب.

في الأنظمة التقليدية كان المستخدم يحتاج إلى معرفة:

أين توجد المعلومة؟

أي جهاز؟
أي خادم؟
أي نظام ملفات؟
أي بروتوكول؟
أي برنامج؟

Berners-Lee أراد أن يتحول السؤال إلى:

ما المعلومة؟

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

الـURI يفصل هوية المورد عن الطريقة التي يفكر بها المستخدم في مكانه.

وبذلك يصبح الرابط مفهومًا مجردًا:

Resource ⇨ Identifier

بدل:

Resource ⇨ physical machine ⇨ filesystem path

وهذه قفزة كبيرة في abstraction.

9. HTML: لغة الوثيقة

كان على Berners-Lee أن يحل مشكلة أخرى:

إذا كانت المعلومات ستنتقل بين أجهزة وأنظمة مختلفة، كيف نصف الوثيقة نفسها؟

فجاءت HTML — HyperText Markup Language.

HTML لم تكن في البداية لغة برمجة عامة، بل لغة توصيف/ترميز للمستندات ذات الروابط.

وهذه نقطة مهمة جدًا لفهم إنجازه.

هو لم يقل:

سأصمم لغة جديدة لتنفيذ الخوارزميات.

بل:

سأصمم لغة يستطيع بها الناس وصف الوثائق، وربطها بوثائق أخرى.

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

W3C يؤكد أن Berners-Lee كتب النسخة الأولى من HTML وأنها كانت لغة تنسيق مستندات تدعم روابط hypertext. W3C

10. HTTP: اللغة التي تتحدث بها الوثائق عبر الشبكة

لكن HTML وحدها لا تكفي.

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

هنا يأتي HTTP — HyperText Transfer Protocol.

Berners-Lee كتب أول خادم ويب، httpd، وبنى معه العميل الأول. وكانت مواصفات HTTP الأولية جزءًا من النظام الذي صممه. W3C

وهكذا أصبحت لدينا ثلاث طبقات شديدة الأهمية:

HTML ⇨ ماذا يوجد في الوثيقة؟

URI ⇨ أي مورد أريد؟

HTTP ⇨ كيف أطلبه وأنقله؟

وهذه الثلاثية هي قلب التصميم الأول للويب.

11. المتصفح الأول لم يكن مجرد Browser

وهنا تظهر عبقرية أخرى في التصميم.

البرنامج الأول لم يكن مجرد قارئ صفحات.

كان اسمه:

WorldWideWeb

وكان browser/editor في الوقت نفسه.

أي أنه يستطيع عرض المستندات وإنشاءها وتحريرها وربطها.

W3C وCERN يوثقان أن البرنامج الأول كان عميلًا يعمل كمتصفح ومحرر، وكتب على حاسوب NeXT في CERN عام 1990. W3C

وهذا يكشف أن التصور الأول للويب لم يكن:

استهلاك صفحات

بل:

قراءة ⇄ كتابة ⇄ ربط ⇄ مشاركة

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

12. أول Web Server وأول Website

بحلول عيد الميلاد عام 1990 كان النظام الأساسي يعمل في CERN.

الخادم الأول كان على حاسوب NeXT في مكتب Berners-Lee.

وعنوان الموقع الأول كان:

info.cern.ch

وكانت الصفحة الأولى مخصصة لشرح مشروع World Wide Web نفسه. تسلسل الأحداث

وكان على الجهاز ملصق مكتوب عليه:

“This machine is a server. DO NOT POWER IT DOWN!!”

التفصيل يبدو طريفًا اليوم، لكنه يوضح مدى بدائية البنية الأولى مقارنة بالبنية السحابية الحالية.

لم تكن هناك مراكز بيانات عالمية.

كان هناك حاسوب في مكتب رجل واحد يحمل أول خادم ويب في التاريخ.

13. والكود نفسه يستحق الدراسة

من أجمل ما يميز حالة Berners-Lee أن CERN لم يحتفظ فقط بقصة الاختراع، بل أعاد بناء البيئة البرمجية الأولى وجعل تفاصيل الكود قابلة للدراسة.

في مشروع WorldWideWeb NeXT Application يمكن دراسة كيفية تحليل HTML في البرنامج الأول، وحتى بنية style sheets القديمة وكيف كان البرنامج يتعامل مع عناصر المستند.

وهذا مهم جدًا لمسردك:

نحن لا نتحدث فقط عن “اختراع الويب” كمفهوم.

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

14. 1991: خروج الويب من CERN

في البداية كان الويب مشروعًا داخليًا.

لكن في 1991 بدأ ينتشر خارج CERN، وأصبح متاحًا لمجتمع الفيزياء عالي الطاقة ثم لمستخدمين آخرين على الإنترنت. وفي ذلك العام أصبح Line Mode Browser متاحًا، وهو أبسط من متصفح NeXT لكنه يعمل على نطاق أوسع من الحواسيب. تسلسل الأحداث

وهنا حدث التحول الحاسم:

برنامج محلي ⇨ نظام قابل للتعميم.

وهذه اللحظة أهم من مجرد كتابة أول نسخة من الكود.

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

15. Robert Cailliau مهم جدًا في هذه القصة

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

Robert Cailliau كان شريكًا مهمًا جدًا في تطوير المشروع، وساهم في صياغة المقترح الرسمي في نوفمبر 1990، وفي دفع المشروع داخل CERN، وتنظيم جوانب كثيرة من تبنيه. Berners-Lee نفسه يذكر أن Cailliau بذل جهدًا كبيرًا للحصول على تمويل ودعم للمشروع واستقطاب الطلاب والمساهمين. تسلسل الأحداث

لذلك:

اختراع الفكرة الأساسية ⇨ Berners-Lee

لكن:

تحويلها إلى مشروع مؤسسي قابل للنمو ⇨ Berners-Lee + Cailliau + فريق CERN

وهذا توصيف أدق تاريخيًا.

16. القرار الذي غيّر التاريخ: جعل الويب مفتوحًا

في 30 أبريل 1993 وضع CERN برنامج World Wide Web في public domain، ثم أصدره لاحقًا بترخيص مفتوح بهدف تعظيم انتشاره. CERN نفسه يربط هذه الخطوة مباشرة بالانتشار السريع للويب. الموقع الرسمي للهجرة

هذه ليست مجرد مسألة قانونية.

إنها جزء من الهندسة نفسها.

لو كان الويب نظامًا مغلقًا، لكان تاريخ الشبكة مختلفًا جذريًا.

لأن قيمة الويب لا تأتي من وجود خادم Berners-Lee؛ بل من قدرة أي شخص على بناء:

خادم + متصفح + وثائق + روابط

وفق معايير مشتركة.

وهنا يتحول الاختراع من برنامج إلى منظومة.

17. وهنا تحديدًا يتفوق مفهوم “Web” على مفهوم “Website”

هذه نقطة أحب أن أضعها في صميم تقييمه.

Berners-Lee لم يخترع “الموقع الإلكتروني”.

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

الـWebsite هو تطبيق.

أما الـWeb فهو بنية علاقات.

يمكن تمثيلها هكذا:

Document A ⇄ Document B ⇄ Document C ⇄ Document D

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

هذه اللامركزية هي جوهر الاختراع.

18. الويب ليس الإنترنت

وهذا التفريق مهم جدًا في تقييم Berners-Lee.

Internet هو البنية الشبكية الأساسية.

Web هو نظام معلومات مبني فوقها.

الإنترنت سبق Berners-Lee بسنوات طويلة، وHTTP ليس TCP/IP، وHTML ليست الإنترنت.

إنجازه كان إنشاء طبقة معلوماتية hypertext فوق البنية الشبكية الموجودة.

ولهذا يمكن أن نقول:

Internet ⇨ نقل الاتصال

Web ⇨ تنظيم المعلومات والروابط فوق الاتصال

وهذا أيضًا يفسر لماذا استطاع الويب الانتشار بسرعة: لم يحتج إلى إعادة اختراع شبكة الاتصال نفسها.

19. W3C: من المبرمج إلى مهندس النظام البيئي

في 1994 أسس Berners-Lee World Wide Web Consortium (W3C) في MIT، بالتعاون مع CERN، ثم أصبح الكيان الرئيسي لتطوير معايير الويب. W3C

وهنا حدث انتقال مهم في نوع عمله.

في البداية:

أكتب الكود.

ثم:

أضع البروتوكول.

ثم:

أحدد اللغة.

ثم:

أحتاج إلى ضمان أن الآخرين سيطبقون هذه الأشياء بطريقة متوافقة.

ومن هنا تأتي أهمية W3C.

لم يعد Berners-Lee يبني برنامجًا واحدًا؛ بل صار يعمل على قواعد تسمح لبرامج مستقلة من شركات ومؤسسات مختلفة بأن تتفاهم.

20. وهذه ربما أهم نقطة في إرثه بعد اختراع الويب

يمكن لأي شخص أن يكتب برنامجًا رائعًا.

لكن بناء standard أصعب بكثير.

المعيار يجب أن يسمح باختلاف التنفيذ مع الحفاظ على التوافق.

وهذا يعني:

Specification ⇨ Implementations متعددة ⇨ Interoperability

وهذا قريب جدًا من فلسفة Strachey، لكن على مستوى مختلف:

Strachey كان يسأل عن المعنى الرسمي للبرنامج.

Berners-Lee أصبح يعمل على المعنى المشترك الذي يجب أن تتفق عليه آلاف البرامج.

21. العلاقة مع Karen Spärck Jones

وهنا يصبح وضع الاسمين متتاليين في قائمتك ممتازًا جدًا:

K — Karen Spärck Jones

ثم:

L — Tim Berners-Lee

Spärck Jones درست:

كيف نعثر على المعلومات؟

Berners-Lee بنى:

كيف نجعل المعلومات شبكة عالمية قابلة للربط؟

وبالتالي:

IR ⇨ Web

ليسا نفس المجال، لكنهما يقعان داخل تحول واحد:

المعلومة لم تعد شيئًا محفوظًا داخل جهاز؛ أصبحت كيانًا يمكن البحث عنه وربطه والوصول إليه عبر شبكة.

وهذه إحدى أهم التحولات في تاريخ الحوسبة.

22. علاقته بـCodd أيضًا عميقة

Codd جعل البيانات مستقلة نسبيًا عن طريقة تخزينها.

Berners-Lee أخذ فكرة abstraction إلى الشبكة:

المورد ليس مجرد ملف في جهاز؛ له هوية يمكن الوصول إليها من أماكن مختلفة.

يمكن النظر إلى التطور هكذا:

Codd: data ⇨ abstract relation

Berners-Lee: information ⇨ abstract resource

وهذا التشابه ليس تطابقًا تقنيًا، لكنه مهم فكريًا.

كلاهما أخذ شيئًا كان مرتبطًا ببنيته الفيزيائية، ثم أعطاه طبقة تجريد مستقلة.

23. ثم جاء Web 2.0 والويب الديناميكي

من المهم ألا ننسب إلى Berners-Lee كل ما ظهر لاحقًا.

الويب الحديث يحتوي على JavaScript وCSS وAJAX وWebAssembly وWebRTC وWebGPU وواجهات API وخدمات سحابية وغيرها، ولم يخترع Berners-Lee هذه كلها.

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

أي أنه لم يبنِ كل مدينة الويب.

لكنه وضع شبكة الشوارع التي سمحت للمدينة أن تنمو.

24. Semantic Web

بعد نجاح الويب، لم يتوقف اهتمام Berners-Lee عند ربط الوثائق.

انتقل إلى فكرة أعمق:

ماذا لو كانت البيانات نفسها قابلة للربط بطريقة يفهمها النظام؟

ومن هنا جاءت أفكار Semantic Web وLinked Data.

فبدل:

صفحة ⇨ صفحة

تصبح:

كيان ⇨ علاقة ⇨ كيان

أي أن الشبكة تتحول تدريجيًا من شبكة وثائق إلى شبكة بيانات ومعانٍ.

وهذا يعيدنا بصورة مذهلة إلى Karen Spärck Jones وCodd، ثم إلى NLP وAI.

25. Solid: محاولة إعادة التفكير في طبقة البيانات

في مرحلة لاحقة أسس Berners-Lee مع آخرين مشروع Solid، الذي يهدف إلى إعطاء المستخدمين قدرًا أكبر من التحكم في بياناتهم، عبر فصل التطبيقات عن أماكن تخزين البيانات واستخدام طبقة ويب أكثر قابلية لنقل البيانات بين التطبيقات. وتصف W3C سيرته Solid بأنه امتداد بحثي من عمله في MIT حول Decentralized Information Group. W3C

وهذا مثير لأنه يعكس استمرار الفكرة الأصلية:

في 1989:

كيف نربط المعلومات؟

وفي Solid:

كيف نعيد توزيع السيطرة على المعلومات المرتبطة؟

أي أنه لم يتوقف عن التفكير في بنية المعلومات.

26. لماذا Berners-Lee مبرمج عظيم تحديدًا؟

لأن مساهمته لم تكن فكرة مجردة.

لقد نفذ:

browser/editor

web server

HTML

HTTP

URI architecture

ثم عمل على:

standards

Web APIs

Semantic Web

Linked Data

وهذا يجعله مثالًا نادرًا للمبرمج الذي بدأ من الكود ثم ارتقى إلى بنية النظام ثم إلى المعيار العالمي.

27. لكن يجب ألا ننسب إليه ما ليس له

مثلما فعلنا مع Karen Spärck Jones، الدقة هنا مهمة.

Berners-Lee لم يخترع الإنترنت.

ولم يخترع hypertext من الصفر؛ كانت هناك أعمال وأفكار سابقة، من بينها Vannevar Bush وDouglas Engelbart وغيرهما.

ولم يكن تطوير الويب جهدًا فرديًا بعد المرحلة الأولى؛ Robert Cailliau وأعضاء آخرون في CERN لعبوا أدوارًا مهمة، ثم جاء عدد كبير من المطورين الذين جعلوا الويب منصة واسعة الانتشار. Berners-Lee نفسه يقر بدور Cailliau وفريق المشروع. W3C

لكن هذه الحقائق لا تقلل من نسبة الاختراع الأساسية إليه؛ بل تجعلها أكثر تحديدًا:

هو الذي جمع hypertext + Internet + resource addressing + HTTP + HTML + browser/server في منظومة واحدة قابلة للتعميم.

28. وهذا هو الفارق بين “اختراع تقنية” و”اختراع طبقة”

Babbage اخترع نموذجًا لآلة حساب قابلة للبرمجة.

Bell صنع نظامًا برمجيًا شديد الكثافة.

Codd اخترع نموذجًا تجريديًا للبيانات.

Spärck Jones طورت نماذج حسابية لاسترجاع المعلومات.

Berners-Lee فعل شيئًا مختلفًا:

اخترع طبقة كاملة بين الإنسان والشبكة والمعلومة.

وهذه الطبقة هي التي أصبحت الويب.

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

29. أهميته في تسلسل قائمتك

يمكن الآن رؤية A–L كخط تاريخي شديد القوة:

Ada Lovelace
البرنامج كخوارزمية.

Babbage
الآلة العامة القابلة للبرمجة.

Strachey
لغة البرمجة ودلالتها.

Davies
الاتصال الشبكي وحزم البيانات.

Codd
البيانات كنموذج مجرد.

Fowler
هندسة البرمجيات وتطور الكود.

Hinton
البرنامج الذي يتعلم.

Hassabis
النظام الذكي الذي يجمع التعلم والتخطيط.

Ian Bell
العالم المتولد بالخوارزمية.

Jon Skeet
الفهم العميق للغة والـAPI.

Karen Spärck Jones
استرجاع المعلومات وتمثيل أهمية الكلمات.

Tim Berners-Lee
المعلومات المترابطة على نطاق عالمي.

وهنا يصبح L نتيجة طبيعية جدًا لما سبقه.

30. أهم أعمال Tim Berners-Lee

1. Information Management: A Proposal — 1989

الوثيقة التي بدأت مشروع الويب، وقدمت تصورًا لنظام معلومات موزع قائم على hypertext. الموقع الرسمي للهجرة

2. WorldWideWeb: Proposal for a HyperText Project — 1990

المقترح الرسمي الذي قدمه Berners-Lee وRobert Cailliau إلى CERN في نوفمبر 1990. CERN Document Server

3. WorldWideWeb — 1990

أول browser/editor، ويمثل أول تطبيق عملي كامل لفكرة الويب.

4. httpd — 1990

أول Web Server.

5. HTML

النسخة الأولى من لغة توصيف مستندات الويب.

6. HTTP

البروتوكول الأساسي لنقل مستندات الويب.

7. URI

نظام التعريف المجرد للموارد، وهو عنصر مركزي في بنية الويب.

8. World-Wide Web: Information Universe — 1992

من أوراقه المبكرة المهمة حول تصور الويب كنظام معلومات عالمي. W3C

9. The World Wide Web — 1994

ورقة مبكرة مهمة عن الويب، شارك فيها Berners-Lee وآخرون، ونُشرت في Communications of the ACM. W3C

10. Weaving the Web — 1999

كتابه الرئيسي، بالاشتراك مع Mark Fischetti، وفيه روايته لتصميم الويب وتطوره ورؤيته لمستقبله. W3C

الخلاصة

L — Tim Berners-Lee من الأسماء التي يصعب أن تجد لها نظيرًا مباشرًا في القائمة، لأن معظم المبرمجين يتركون وراءهم برنامجًا أو لغة أو خوارزمية.

Berners-Lee ترك وراءه بيئة تستطيع برامج ولغات وخوارزميات لا حصر لها أن تعمل داخلها وتتخاطب من خلالها.

وهذا هو جوهر إنجازه:

ENQUIRE
⇨ المعلومات المرتبطة

1989 Proposal
⇨ نموذج عالمي للمعلومات

HTML + URI + HTTP
⇨ اللغة + الهوية + النقل

Browser + Server
⇨ التنفيذ

CERN → Internet
⇨ الانتشار

W3C
⇨ المعايير

Semantic Web / Linked Data
⇨ محاولة جعل شبكة المعلومات نفسها أكثر قابلية للمعالجة الآلية

لذلك فإن Berners-Lee في مسردك ليس ببساطة “الرجل الذي اخترع مواقع الإنترنت”؛ هذا توصيف سطحي جدًا. هو مبرمج الأنظمة الذي حوّل الشبكة من وسيلة اتصال بين الحواسيب إلى فضاء عالمي مترابط للمعلومات. وهذا يجعله، من حيث نوع الإنجاز البرمجي، واحدًا من أكثر الأسماء اختلافًا عن كل من سبقه في قائمتك. W3C

Molyneux

M — Peter Molyneux

بعد Tim Berners-Lee، الانتقال إلى Peter Molyneux يصنع تحولًا حادًا جدًا في نوع البرمجة الذي تمثله القائمة. فإذا كان Berners-Lee قد برمج فضاء المعلومات العالمي، فإن Molyneux برمج عوالم افتراضية لها سكان وقواعد وسلوكيات. وهو لذلك مهم جدًا في قائمتك، خصوصًا إذا كنا نتعامل مع البرمجة بمعناها التاريخي الواسع، لا باعتبارها مجرد كتابة أنظمة تشغيل أو لغات.

Peter Molyneux هو مبرمج ومصمم ألعاب بريطاني، اشتهر خصوصًا بتأسيس Bullfrog Productions والمشاركة في صناعة Populous ثم Powermonger وTheme Park وDungeon Keeper، ولاحقًا تأسيس Lionhead وصناعة Black & White وFable. وقد منحته BAFTA زمالتها عام 2011 تقديرًا لإسهامه الاستثنائي في الألعاب. Bafta

1. Molyneux يمثل نوعًا مختلفًا من المبرمج

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

أما Molyneux فمساهمته الأساسية تقع في برمجة السلوك والأنظمة التفاعلية.

اللعبة عنده ليست مجرد مجموعة رسومات مع تعليمات:

زر ⇨ حركة ⇨ نتيجة

بل يمكن أن تصبح:

قواعد ⇨ كائنات ⇨ دوافع ⇨ تفاعل ⇨ نتائج ناشئة ⇨ عالم يتغير

وهذا فارق جوهري.

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

2. البداية لم تكن في الألعاب أصلًا

المفارقة أن دخول Molyneux إلى صناعة الألعاب جاء، بحسب روايته، من خلال البرمجيات التجارية؛ وقد وصف في محاضرة BAFTA دخوله إلى صناعة الألعاب بأنه حدث “بالخطأ”. كان يعمل في برمجة business software عندما بدأت فكرة Populous تتشكل لديه. Bafta

وهذا مهم لأن Populous لم يكن مشروعًا تقنيًا نشأ داخل صناعة ألعاب ناضجة.

كان محاولة من مبرمج جاء من البرمجيات التجارية لكي يقول:

ماذا يحدث لو جعلنا الحاسوب يحاكي عالمًا بدل أن يحسب معاملات؟

وهذه هي النقلة التي ستحدد مسيرته كلها.

3. Populous — نقطة التحول

صدر Populous عام 1989، وأسس ما صار يعرف بـGod game: اللاعب لا يتحكم في شخصية واحدة فقط، بل يمتلك سلطات واسعة على عالم وسكان ومجتمع. BAFTA تصفه بأنه اللعبة التي ابتكرت هذا النوع من الألعاب، ووضع اللاعب في موقع السيطرة على عالم واسع النطاق. Bafta

لكن القيمة البرمجية الحقيقية لـPopulous ليست في فكرة “الإله”.

إنها في المحاكاة.

الناس يتحركون.
الأرض تتغير.
المستوطنات تنمو.
السكان يتكاثرون.
البيئة تؤثر في السلوك.
واللاعب يتدخل في النظام.

أي أن اللعبة ليست سلسلة مراحل ثابتة بالمعنى التقليدي.

إنها نظام ديناميكي.

4. والمثير أن أحد أشهر عناصر Populous جاء من مشكلة برمجية

وهنا تظهر واحدة من أكثر القصص دلالة على Molyneux كمبرمج.

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

هذه ليست مجرد حكاية طريفة.

إنها تكشف أسلوبًا مهمًا جدًا في تصميم الأنظمة:

بدل أن تقول:

كيف أجعل الخوارزمية تحل المشكلة؟

يمكن أن تقول:

هل أستطيع تغيير قواعد النظام بحيث تختفي المشكلة أصلًا؟

وهذه عقلية مبرمج أنظمة، حتى عندما تكون النتيجة في النهاية ميكانيكية لعب.

5. Populous إذن ليس مجرد “لعبة استراتيجية”

لو نظرنا إليه من منظور برمجي، فهناك عدة طبقات:

Terrain system
⇨ الأرض قابلة للتغيير.

Population simulation
⇨ عدد كبير من الكائنات يتحرك داخل العالم.

Economic/social progression
⇨ الحضارات تتغير.

AI behavior
⇨ الوحدات لا تتعامل مع العالم كصور ثابتة.

Player intervention
⇨ اللاعب يغير قواعد البيئة نفسها.

وهنا بدأ Molyneux في بناء ما يمكن تسميته:

Programmable World Simulation

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

6. Powermonger: توسيع فكرة العالم المحاكى

جاء Powermonger بعد Populous، وواصل فكرة العالم الذي يتحرك بناءً على أنظمة متعددة.

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

أي أن Molyneux كان يختبر سؤالًا مستمرًا:

إلى أي حد يمكن تحويل العالم إلى مجموعة من القواعد البرمجية، ثم جعل اللاعب يتعامل معها بدل أن يتعامل مع قصة خطية؟

وهذا السؤال سيصل لاحقًا إلى Black & White.

7. Theme Park — برمجة الاقتصاد كسلوك

في Theme Park، تغير الموضوع، لكن البنية بقيت.

بدل إدارة حضارة، يدير اللاعب مدينة ملاهٍ.

وهنا تتحول البرمجة إلى محاكاة:

الزوار لديهم رغبات.
الأسعار تؤثر فيهم.
المرافق تؤثر في تجربتهم.
الموظفون يعملون.
الاقتصاد يتغير.

أي أن Molyneux اكتشف أن جوهر اهتمامه ليس “الإله” حرفيًا.

بل النظام الذي يستطيع اللاعب التدخل فيه.

ولهذا فإن Theme Park مهم جدًا في فهم مسيرته؛ فهو يثبت أن فكرة Molyneux لم تكن مرتبطة بموضوع ديني أو خيالي، وإنما بـsimulation design.

BAFTA تضع Theme Park ضمن سلسلة أعماله الأساسية إلى جانب Populous وDungeon Keeper وBlack & White. Bafta

8. Dungeon Keeper — قلب الفكرة ينقلب

ثم جاءت Dungeon Keeper عام 1997، وهي من أهم أعماله من ناحية الفكرة البرمجية.

هنا لا يلعب المستخدم دور البطل.

بل يلعب دور الشرير.

Molyneux تحدث عن هذه الفكرة في محاضرته لدى BAFTA، موضحًا أن العمل كان من أوائل المشاريع التي جعلته وفريقه يفكرون في إمكانية أن يكون “الجانب السيئ” هو الذي يتحكم به اللاعب. ذا جارديان

لكن الأهم برمجيًا هو أن اللاعب لا يحدد كل حركة.

هناك مخلوقات.

وهذه المخلوقات لها سلوك.

والسلوك يتأثر بالبيئة وبما يفعله اللاعب.

وهنا نقترب أكثر من مفهوم:

Emergent Gameplay

9. من التحكم المباشر إلى التحكم غير المباشر

وهذه ربما أهم فكرة تقنية في Molyneux كله.

في لعبة تقليدية:

أضغط ⇨ الشخصية تتحرك

أما في ألعاب Molyneux:

أغير البيئة ⇨ النظام يتغير ⇨ الكائنات تستجيب ⇨ نتيجة غير محددة بالكامل مسبقًا

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

إنه يشبه الانتقال من كتابة:

if player presses X, do Y

إلى بناء:

state + rules + agents + environment

ثم ترك النتيجة تظهر من تفاعل هذه العناصر.

ولهذا يمكن وضع Molyneux في تاريخ برمجة الوكلاء والمحاكاة التفاعلية، حتى لو لم يكن عمله بحثًا أكاديميًا في AI.

10. Black & White — الذكاء الاصطناعي يصبح الشخصية

ثم وصل المشروع إلى أكثر أشكاله طموحًا مع Black & White عام 2001.

الفكرة كانت أن يمتلك اللاعب مخلوقًا ضخمًا يمكنه التعلم من أفعال اللاعب والبيئة.

وهنا أصبح السؤال:

ماذا لو لم أكتب للشخصية كل السلوكيات الممكنة، بل جعلتها تتعلم بعض السلوكيات؟

هذا يختلف عن AI التقليدي الذي يجعل العدو يتبع شجرة قرارات ثابتة.

الفكرة أصبحت:

Observation ⇨ Action ⇨ Consequence ⇨ Learning

وبالتالي صار المخلوق جزءًا من التجربة وليس مجرد أداة تحكم.

11. واجهة المستخدم نفسها أصبحت جزءًا من البرمجة

من الأفكار التي تحدث عنها Molyneux في محاضرته أن طموح Black & White كان تقليل الاعتماد على الواجهات التقليدية والأيقونات، بحيث يصبح الماوس نفسه وسيلة أساسية للتفاعل مع العالم. ذا جارديان

وهذا مهم جدًا.

لأن تصميم اللعبة عادة يفصل بين:

Game World

و

User Interface

لكن Molyneux حاول جعلهما شيئًا أقرب إلى بعضهما:

حركة المؤشر ⇨ فعل داخل العالم

وهذا اتجاه ستراه لاحقًا في ألعاب كثيرة تعتمد على gesture-based interaction وcontextual interaction.

12. Fable — النظام يصبح شخصية اجتماعية

مع Fable، انتقل Molyneux من محاكاة العالم إلى محاكاة هوية اللاعب داخل العالم.

اللاعب لا يكتفي بإنجاز المهمة.

أفعاله تؤثر في الطريقة التي يُرى بها.

وتتفاعل الشخصية مع العالم ومع الشخصيات الأخرى.

وبالتالي أصبح لدينا:

Player actions ⇨ persistent state ⇨ character/world reaction

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

13. لكن هنا تظهر حدود Molyneux أيضًا

وهنا ينبغي ألا يتحول التحليل إلى أسطورة.

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

لكن هذا لا يعني أنه لم يكن مبرمجًا.

بل يعني أن نوع قوته لم يكن هو التفوق في الخوارزميات منخفضة المستوى مثل Ian Bell، ولا في تصميم اللغات مثل Strachey.

قوته كانت في:

ترجمة فكرة مجردة ⇨ إلى نظام قابل للبرمجة ⇨ ثم تحويل النظام إلى تجربة تفاعلية.

وهذه مهارة برمجية مختلفة.

14. وهو نفسه يعترف بأن الألعاب عمل جماعي

في المحاضرة نفسها كان حريصًا على استخدام “we” عندما يتحدث عن الألعاب، حتى عندما يقول “I”، لأنه يرى أن الألعاب التي ارتبط اسمه بها نتاج فرق كاملة. ذا جارديان

وهذه نقطة مهمة جدًا عند وضعه في مسرد تاريخي.

لا يصح أن ننسب كل سطر كود في Populous أو Dungeon Keeper أو Black & White إلى Molyneux شخصيًا.

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

وهذا مشابه لما قلناه عن Berners-Lee، ولكن في صناعة الألعاب.

15. Bullfrog: الأهم من شخص Molyneux

تأسست Bullfrog Productions عام 1987، وأصبحت البيئة التي خرج منها عدد كبير من أعمال Molyneux. BAFTA توثق تأسيسه للشركة ومسيرتها التي شملت Populous وPowermonger وTheme Park وMagic Carpet وDungeon Keeper. Bafta

وهنا توجد ظاهرة تاريخية مهمة:

Molyneux لم يترك وراءه ألعابًا فقط.

ترك مدرسة تصميم.

Bullfrog أصبحت مرتبطة بنوع من الألعاب التي لا تقول للاعب:

“نفّذ المهمة التي أعطيك إياها.”

بل تقول:

“إليك نظامًا، وانظر ماذا تستطيع أن تفعل داخله.”

16. Lionhead: استمرار التجربة

بعد Bullfrog أسس Molyneux Lionhead Studios عام 1996، ثم أصبحت Black & White أحد أبرز مشروعاتها، تلتها سلسلة Fable. وقد ظلت Lionhead مستقلة نحو عقد قبل استحواذ Microsoft عليها، ثم أغلقت عام 2016. ذا جارديان

وهذا يجعل مسيرته مقسومة تقريبًا إلى مرحلتين:

Bullfrog ⇨ simulation

Lionhead ⇨ simulation + personality + narrative

أي أن اهتمامه لم يتغير جذريًا.

إنما أصبح النظام أكثر ارتباطًا بـاللاعب نفسه.

17. ما الذي جعل Molyneux مؤثرًا في البرمجة؟

يمكن تلخيص أثره في أربعة محاور:

1. Simulation Programming

برمجة العالم باعتباره مجموعة من الأنظمة المتفاعلة.

2. Artificial Intelligence

إعطاء الكائنات سلوكًا مستقلًا نسبيًا.

3. Emergent Systems

ترك النتائج تنشأ من تفاعل القواعد بدل كتابة كل نتيجة يدويًا.

4. Human–Computer Interaction

جعل واجهة التحكم نفسها جزءًا من العالم.

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

18. Molyneux وIan Bell: مقارنة مثيرة

وجود Ian Bell في I ثم Peter Molyneux في M يسمح بمقارنة جميلة جدًا.

Bell كان مهتمًا بالسؤال:

كيف أستخرج أقصى قدر ممكن من الحاسوب المحدود؟

ولهذا استخدم الخوارزميات والضغط والإجراءات التوليدية لصناعة Elite.

Molyneux كان يسأل:

كيف أجعل الحاسوب يحاكي عالمًا كاملًا؟

Bell:

Computation ⇨ Space

Molyneux:

Computation ⇨ Simulation

كلاهما مبرمجا ألعاب، لكنهما يمثلان مدرستين مختلفتين تمامًا.

19. Molyneux وHassabis

والأكثر إثارة أن H — Demis Hassabis وM — Peter Molyneux يتقاطعان في الألعاب أيضًا.

Hassabis بدأ من الألعاب والبرمجة ثم انتقل إلى AI.

Molyneux بقي داخل الألعاب لكنه دفعها باتجاه:

AI + Simulation + Learning + Agency

ولهذا يمكن النظر إلى Black & White كحلقة تاريخية صغيرة في المسار الطويل الذي جعل سلوك الكائنات الاصطناعية جزءًا أساسيًا من تصميم الألعاب.

لكن بالطبع لا ينبغي مساواة ذلك بأبحاث التعلم العميق عند Hinton أو Hassabis؛ إنما العلاقة هي في محاولة جعل السلوك المحوسب يبدو أقل خطية وأكثر استقلالًا.

20. حتى فشل المشاريع اللاحقة يكشف شيئًا عن منهجه

بعد مغادرته Lionhead، أسس Molyneux 22Cans، وظهر مشروع Godus بوصفه عودة إلى فكرة Populous. وقد تعرض المشروع لاحقًا لانتقادات ومشكلات تتعلق بالفجوة بين الطموحات المعلنة والمنتج النهائي؛ وتناولت الصحافة هذا الجدل على نطاق واسع. ذا جارديان

لكن من الناحية التاريخية، هذا مثير للاهتمام لأن المشروع لم يكن خروجًا عن فلسفته.

حتى بعد عقود ظل السؤال نفسه:

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

أي أن الفكرة المركزية بقيت ثابتة حتى عندما اختلفت جودة التنفيذ والنتائج.

21. أهم إنجازاته ليست “الألعاب”، بل مفهوم اللعبة كنظام

وهنا أعتقد أن هذا هو أفضل موضع لـMolyneux في قائمتك.

لو حذفنا أسماء الألعاب والأجهزة والشركات، يبقى لدينا مفهوم:

اللعبة باعتبارها نظامًا قابلًا للمحاكاة والتفاعل.

وهذا مفهوم أكبر من Populous نفسه.

يمكن أن نراه اليوم في:

• ألعاب المحاكاة.
• ألعاب المدن.
• ألعاب الاستراتيجية.
• ألعاب الـsandbox.
• الأنظمة القائمة على الوكلاء.
• السلوك الناشئ.
• ألعاب الذكاء الاصطناعي.
• أنظمة العالم المفتوح.

ليس كل ذلك “من اختراع Molyneux”، بالطبع، لكنه كان أحد أهم المبرمجين والمصممين البريطانيين في تحويل هذه الفلسفة إلى ألعاب جماهيرية.

22. موقعه في قائمتك

إذا كان Tim Berners-Lee هو:

مبرمج الشبكة العالمية للمعلومات

فإن Peter Molyneux هو:

مبرمج العالم الافتراضي القابل للمحاكاة.

وهذا يجعل حرف M قويًا جدًا من ناحية التنوع.

L — Berners-Lee:
المعلومات ⇨ شبكة ⇨ روابط ⇨ عالم عالمي.

M — Molyneux:
القواعد ⇨ محاكاة ⇨ كائنات ⇨ سلوك ⇨ عالم افتراضي.

وبالتالي لا يبدو M مجرد استمرار لألعاب Ian Bell؛ بل يمثل انتقالًا من برمجة العالم كفضاء إلى برمجة العالم كنظام حيّ.

أهم أعمال Peter Molyneux

Populous (1989)

أهم أعماله تاريخيًا؛ أسس نموذج الـGod Game، وجعل التضاريس والسكان والسلطة الإلهية جزءًا من نظام محاكاة واحد. Bafta

Powermonger (1990)

توسيع لأفكار المحاكاة والسيطرة الاستراتيجية.

Theme Park (1994)

تحويل الإدارة الاقتصادية وسلوك الزوار إلى نظام لعب ومحاكاة.

Dungeon Keeper (1997)

من أهم أعماله في السلوك الناشئ؛ اللاعب يدير زنزانته ومخلوقاته بدل التحكم التقليدي بالبطل. Bafta

Black & White (2001)

التجربة الأكثر وضوحًا في الجمع بين AI والسلوك والتعلم والتفاعل مع البيئة.

Fable (2004)

نقل فكرة النظام التفاعلي إلى عالم RPG، مع التركيز على شخصية اللاعب وعواقب أفعاله.

Fable II (2008)

تطوير أكبر لفكرة العالم الذي يستجيب لتاريخ اللاعب وخياراته.

Fable III (2010)

استمرار مشروع Fable، وكان من الأعمال التي كرست اسمه في المرحلة الأخيرة من Lionhead. Bafta

Godus (2013)

عودة مباشرة إلى جذور Populous ومحاولة إعادة بناء مفهوم الـGod Game في عصر جديد. ذا جارديان

الحكم التاريخي على M

Peter Molyneux ليس من نوع المبرمجين الذين تقاس أهميتهم بعدد الخوارزميات المنشورة أو اللغات التي صمموها.

أهميته تكمن في شيء آخر:

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

ومن Populous إلى Dungeon Keeper ثم Black & White، ظل سؤاله الأساسي تقريبًا ثابتًا:

ماذا يحدث عندما لا أكتب للاعب النتيجة، بل أكتب النظام الذي ينتج النتيجة؟

وهنا تحديدًا يصبح وجوده في مسرد أعظم المبرمجين البريطانيين منطقيًا جدًا: فهو يمثل Game Systems Programming + Simulation + AI Behaviour + Emergent Gameplay، وهي مدرسة برمجية كاملة داخل تاريخ ألعاب الفيديو. وقد كرّمت BAFTA هذا المسار بمنحه Fellowship عام 2011، وهو أعلى تكريم تقدمه الأكاديمية للمساهمة الاستثنائية في الألعاب. Bafta

Needham

N — Roger Needham

Roger Michael Needham (1935–2003) اختيار قوي جدًا لحرف N، بل إن وضعه بعد Karen Spärck Jones له قيمة تاريخية خاصة جدًا: كلاهما من قلب مدرسة Cambridge الحاسوبية، وكانا زوجين منذ 1958، لكنهما سلكا مسارين مختلفين تمامًا؛ Karen اتجهت إلى استرجاع المعلومات واللغة، بينما Needham اتجه إلى أنظمة التشغيل، الحوسبة الموزعة، الحماية، الشبكات والأمن الحاسوبي. جامعة كامبريدج

وإذا كان Berners-Lee قد جعل الحواسيب تتبادل المعلومات على نطاق عالمي، فإن Needham كان من الذين واجهوا السؤال الذي أصبح حتميًا بعد ذلك: كيف تتبادل الحواسيب المعلومات والموارد دون أن يثق كل جهاز بكل جهاز آخر؟ هذه النقلة تجعل Needham من أهم الأسماء البريطانية في تاريخ systems programming وcomputer security.

1. مبرمج أنظمة قبل أن يكون متخصص أمن

ولد Needham عام 1935، ودرس الرياضيات والفلسفة في Cambridge، ثم حصل عام 1957 على دبلوم في Numerical Analysis and Automatic Computing، ونال الدكتوراه عام 1961 عن تطبيق الحواسيب الرقمية في التصنيف والتجميع. جامعة كامبريدج

ثم دخل مختبر Cambridge الحاسوبي في وقت كانت فيه Computer Science نفسها ما تزال تتشكل كتخصص.

وهذا مهم لفهمه: لم يبدأ من عالم فيه Linux وWindows وTCP/IP وcryptographic libraries وcloud computing. كان يعمل عندما كان السؤال الأساسي هو:

ما الذي ينبغي أن تكون عليه أنظمة الحاسوب أصلًا؟

2. TITAN والحوسبة كنظام تشغيل

في الستينيات شارك Needham في أعمال مرتبطة بنظام TITAN في Cambridge، وتذكر سيرته الأكاديمية أنه عمل على أنظمة التشغيل، والـtime-sharing، وحماية الذاكرة، والحوسبة الموزعة. كامبردج

وهنا يبدأ شكل مساهمته الحقيقي.

Needham لم يكن مبرمج تطبيقات بالمعنى الحديث.

كان يعمل على الطبقة التي تجعل البرامج الأخرى قادرة على الوجود أصلًا:

Processor → Memory → Protection → Operating System → Programs

وهذه طبقة شديدة العمق في تاريخ البرمجة.

3. من البرنامج إلى “من يحق له أن يفعل ماذا؟”

من أهم اهتماماته المبكرة protection، وخصوصًا الأنظمة القائمة على capabilities.

وهنا يظهر السؤال الذي سيصبح محور عمله لاحقًا:

إذا كان لدي برنامجان يعملان على النظام نفسه، كيف أمنع أحدهما من الوصول إلى موارد لا يملك حق استخدامها؟

المشكلة ليست مجرد تشفير.

التشفير يحمي المعلومة أثناء التخزين أو النقل.

أما protection فيسأل:

من يملك الحق في الوصول أصلًا؟

وهذا فرق أساسي.

Needham عمل على مشروع CAP، وهو من أهم الأنظمة المبكرة في أبحاث architecture-based protection، قبل أن يتحول الأمن الحاسوبي إلى الصناعة الضخمة التي نعرفها اليوم. كامبردج

4. Cambridge Ring والحوسبة الموزعة

ثم انتقل اهتمام Needham إلى distributed systems.

عمل على Cambridge Ring وعلى Cambridge Model Distributed System ومشروعات أخرى مرتبطة بالحوسبة الموزعة. كامبردج

وهنا تصبح مسيرته شديدة الصلة بما جاء بعده عند Berners-Lee.

في الحاسوب المنفرد:

المورد موجود هنا.

في النظام الموزع:

المورد قد يكون هناك.

وهذا يخلق مشاكل جديدة تمامًا:

• كيف أعرف الطرف الآخر؟
• كيف أتأكد من هويته؟
• كيف أمنحه الصلاحيات؟
• كيف أمنع انتحال هويته؟
• كيف أتأكد أن الرسالة لم يتم العبث بها؟

وهكذا بدأت security تظهر عند Needham باعتبارها نتيجة طبيعية لمشكلة الأنظمة الموزعة.

5. Grapevine: نموذج بالغ الأهمية

خلال عمله مع Xerox PARC، شارك Needham مع Andrew Birrell وMike Schroeder وRoy Levin في أعمال Grapevine، وهو نظام موزع مبكر مهم جدًا. ومن منشورات Microsoft Research نرى ورقة Grapevine: An exercise in distributed computing المنشورة عام 1982، إلى جانب دراسة لاحقة عن نمو النظام. مايكروسوفت

وهذا ليس تفصيلًا ثانويًا.

Grapevine يمثل نوعًا من الأنظمة التي تجمع:

Naming + Communication + Authentication + Distributed Resources

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

6. Needham-Schroeder: هنا أصبح اسمه تاريخًا في الأمن

عام 1978 نشر Roger Needham وMichael Schroeder ورقتهما الشهيرة:

Using Encryption for Authentication in Large Networks of Computers

وكانت فكرتها الأساسية تصميم بروتوكولات تستخدم التشفير من أجل authentication في شبكات كبيرة من الحواسيب. وتضع Cambridge هذه الورقة ضمن القراءات المؤسسة في أمن الحاسوب، بينما تصفها Microsoft Research بأنها من الأعمال الرائدة في هذا المجال. مايكروسوفت

وهنا تغير السؤال من:

كيف أشفر الرسالة؟

إلى:

كيف أعرف أن الطرف الذي أتحدث معه هو فعلًا الطرف الذي أعتقد أنني أتحدث معه؟

وهذا فرق ضخم.

7. Authentication ليست Encryption

وهذا ربما أهم مفهوم لفهم Needham.

التشفير يقول:

الآخرون لا يستطيعون قراءة الرسالة.

أما authentication فيقول:

أستطيع تحديد هوية الطرف الذي يتعامل معي.

وهناك سؤال ثالث:

Authorization ⇨ ماذا يُسمح له أن يفعل؟

Needham اشتغل عبر هذه المنطقة بأكملها:

Identity → Authentication → Authorization → Protection

وهذا هو السبب في أن أثره يمتد من operating systems إلى distributed systems إلى network security.

8. Needham–Schroeder لم تكن النهاية

ومن الأشياء التي تجعل تاريخ Needham أكثر أهمية أنه لا يمكن اختزاله في “اخترع بروتوكولًا ناجحًا”.

النسخة ذات المفتاح العام من Needham–Schroeder عُثر لاحقًا على ثغرة فيها بواسطة Gavin Lowe عام 1995.

وهذا لا يمحو أهمية البروتوكول؛ بالعكس، أصبحت الحالة مثالًا كلاسيكيًا على صعوبة تصميم بروتوكولات الأمان.

وتوثق Cambridge أن النسخة الأصلية كانت عرضة لـLowe’s attack، وأن هناك نماذج رسمية مختلفة للبروتوكول وإصلاحه. كامبردج

وهنا تظهر قيمة تاريخية عميقة:

Needham ساعد على إنشاء لغة المشكلة؛ ثم أصبحت البروتوكولات التي تنتمي إلى مدرسته نفسها موضوعًا للـformal verification.

9. BAN Logic

في 1989 نشر Michael Burrows وMartín Abadi وRoger Needham العمل الذي أصبح يعرف باسم:

BAN Logic — Burrows–Abadi–Needham Logic

وكان هدفه إعطاء طريقة أكثر رسمية لتحليل beliefs and assumptions في بروتوكولات المصادقة.

Cambridge تصف الورقة بأنها طورت formalism مخصصًا لتحليل authentication protocols، وأظهرت كيف يمكن لبروتوكولات مختلفة أن تختلف بصورة دقيقة في افتراضات الثقة والنتائج التي يستطيع المشاركون استنتاجها. كامبردج

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

بدل أن نقول:

“يبدو أن هذا البروتوكول آمن.”

نبدأ بالسؤال:

ما الذي يستطيع كل طرف إثباته أو استنتاجه بعد تنفيذ البروتوكول؟

وهذا يقرب أمن الحاسوب من المنطق الرسمي.

10. وهنا تظهر صلة Needham بـChristopher Strachey

هذه واحدة من أجمل الروابط داخل قائمتك.

Strachey كان مهتمًا بالمعنى الرسمي للبرامج.

Needham صار مهتمًا بالمعنى الرسمي لتفاعلات الأنظمة الأمنية.

في الأول:

Program → Semantics

وفي الثاني:

Protocol → Beliefs → Authentication properties

كلاهما يدفع البرمجة بعيدًا عن “الكود الذي يعمل” نحو:

ما الذي يمكن إثباته عن هذا الكود أو البروتوكول؟

وهذه إحدى السمات المميزة للـCambridge School.

11. TEA وXTEA

ولم يقتصر Needham على البروتوكولات والمنطق.

بالتعاون مع David Wheeler، شارك في تصميم TEA — Tiny Encryption Algorithm، ثم XTEA.

Microsoft Research تدرج TEA وXTEA صراحة ضمن إسهاماته في التشفير. مايكروسوفت

والفكرة هنا مختلفة عن Needham–Schroeder.

هناك:

Protocol Design

وهنا:

Cryptographic Primitive

أي أن Needham عمل على مستويين:

كيف تتبادل الأطراف المفاتيح وتثبت هويتها؟

و

كيف نشفر البيانات نفسها؟

12. حماية كلمات المرور

من الإسهامات الأخرى التي تنسبها Microsoft Research إلى Needham أنه كان من رواد استخدام one-way hash functions لحماية كلمات المرور. مايكروسوفت

وهذا مبدأ أصبح اليوم بديهيًا:

لا ينبغي للنظام أن يحتاج إلى الاحتفاظ بكلمة المرور الأصلية لكي يتحقق منها.

بل:

Password → Hash → Stored value

ثم عند تسجيل الدخول:

Entered password → Hash → Compare

والفكرة الأساسية هنا أن النظام لا يحتاج إلى معرفة السر نفسه؛ يحتاج إلى إثبات امتلاك السر.

هذه فلسفة Needham بالكامل تقريبًا:

قلل ما يجب أن تثق به، ولا تجعل النظام يعتمد على افتراضات غير ضرورية.

13. Needham كمهندس أنظمة وليس “خبير تشفير” فقط

وهنا أعتقد أن وصفه بـcryptographer وحده سيكون تقليلًا من نطاقه.

مسيرته شملت:

Operating Systems

Time-sharing

Memory Protection

Capability Systems

Distributed Systems

Local Area Networks

Authentication

Cryptographic Protocols

Formal Security Logic

Research Management

Microsoft Research نفسها تعدد هذه المجالات ضمن مسيرته. مايكروسوفت

أي أن الأمن بالنسبة إليه لم يكن تخصصًا منفصلًا عن أنظمة الحاسوب.

كان نتيجة منطقية لتعقيد الأنظمة.

14. رأس مختبر Cambridge

في 1980 أصبح Needham رئيس Cambridge Computer Laboratory، واستمر في هذا الدور حتى 1995. وفي 1981 أصبح Professor of Computer Systems. جامعة كامبريدج

وهذه فترة مهمة جدًا.

فهو لم يكن مجرد باحث يكتب أوراقًا.

كان يدير بيئة أنتجت أجيالًا من علماء الحاسوب، وأصبح له تأثير مباشر على اتجاه البحث الحاسوبي البريطاني.

بل تشير المصادر إلى مشاركته في لجان وبرامج وطنية مثل Alvey Programme، الذي كان من المشاريع البريطانية المهمة لدفع البحث في تقنيات المعلومات. كامبردج

15. Microsoft Research Cambridge

ثم جاءت المرحلة الأخيرة التي تكشف شيئًا مهمًا عن مكانته.

عام 1997 أنشأ Needham مختبر Microsoft Research في Cambridge وأصبح مديره الإداري. جامعة كامبريدج

أي أن Microsoft لم تستدعِه فقط كباحث أمني.

بل جعلته الشخص الذي يبني المؤسسة البحثية نفسها في بريطانيا.

وهذا يفسر لماذا كان تأثيره مؤسسيًا بقدر ما كان تقنيًا.

لقد انتقل من:

كتابة الأنظمة

إلى:

تأسيس البيئة التي تكتب فيها الأنظمة المستقبلية.

16. وهنا تزداد أهمية وجوده بعد Karen

هناك مفارقة جميلة جدًا في قائمتك:

K — Karen Spärck Jones

ثم:

N — Roger Needham

وبينهما اسمان آخران، لكن تاريخيًا هما متصلان مباشرة.

Karen كانت باحثة في:

Information Retrieval + NLP

Needham كان باحثًا في:

Systems + Security + Distributed Computing

كأن Cambridge أنتجت داخل البيت نفسه مسارين مختلفين للحوسبة:

المعلومة وكيف نعثر عليها

مقابل:

النظام وكيف نحميها وننظم الوصول إليها

وهذا يجعل Needham اختيارًا ذا قيمة أكبر من مجرد كونه اسمًا مشهورًا.

17. علاقته بـTim Berners-Lee

والآن تصبح السلسلة K → L → N أكثر إثارة.

Berners-Lee يقول:

كيف أربط الموارد والمعلومات عالميًا؟

Needham يسأل:

كيف أثق في الأطراف التي تصل إلى هذه الموارد؟

الويب:

Resource → URI → HTTP

الأمن:

Principal → Authentication → Authorization

ولهذا فإن كثيرًا من المشكلات التي أصبحت أساسية في الويب الحديث — الهوية، الجلسات، authentication، access control، secure communication — تقع داخل المنطقة التي ساهم Needham في تأسيس أدواتها الفكرية والتقنية.

18. أهميته بالنسبة للبرمجة نفسها

Needham يمثل نوعًا من البرمجة لا يظهر دائمًا للمستخدم.

لن ترى اسم Needham على الشاشة عندما تسجل الدخول إلى نظام آمن.

لكن خلف ذلك قد توجد أفكار من نوع:

Who are you?

How do I know?

Who vouches for you?

What are you allowed to access?

Can another machine impersonate you?

Can this protocol survive an attacker?

هذه هي البرمجة التي تجعل النظام جديرًا بالثقة.

ولذلك أراه من أفضل الأمثلة في قائمتك على:

Security Systems Programming

مع امتداده إلى:

Distributed Systems + Operating Systems + Cryptographic Protocols

19. لكن يجب ألا ننسب Kerberos إليه وحده

هذه نقطة دقة مهمة.

Microsoft Research تذكر أن Needham–Schroeder يشكل أساسًا لبروتوكول المصادقة وتبادل المفاتيح المستخدم في Kerberos، لكن Kerberos نفسه نتاج عمل لاحق ومؤسسي في MIT وغيرها، وليس “اختراع Roger Needham”. مايكروسوفت

إذن الصياغة الصحيحة:

Needham–Schroeder ⇨ أحد الأسس الفكرية والتقنية لمسار أدى إلى Kerberos

وليس:

Needham اخترع Kerberos.

وهذه الدقة مهمة خصوصًا في قائمة تاريخية كهذه.

20. ومن المفارقات أن عمله يثبت أن الأمن ليس مجرد تشفير

لو كان الأمن هو التشفير فقط، لكان TEA وXTEA كافيين لتلخيص عمله.

لكن أكبر إرثه ربما يقع في مكان آخر:

البروتوكول.

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

وهذا ما كشفته لاحقًا هجمات وتحليلات Needham–Schroeder.

إذن الدرس الذي تركه Needham هو:

Security ≠ Encryption

بل:

Security = Architecture + Protocol + Identity + Trust + Access Control + Cryptography

وهذا أكثر نضجًا بكثير.

21. مكانته التاريخية

انتُخب Needham عضوًا في Royal Society عام 1985، وأصبح Fellow of the Royal Academy of Engineering عام 1993، وFellow of ACM عام 1994، وحصل على CBE عام 2001 تقديرًا لإسهاماته في الحوسبة. مايكروسوفت

لكن الجوائز هنا أقل أهمية من اتساع أثره.

فهو ينتمي إلى الجيل الذي نقل الحاسوب من:

آلة منفردة

إلى:

نظام متعدد المستخدمين

ثم:

شبكة

ثم:

نظام موزع

ثم:

نظام يحتاج إلى نموذج ثقة وأمن.

وهذا مسار تاريخي بالغ الأهمية.

22. أهم أعمال Roger Needham

1. Using Encryption for Authentication in Large Networks of Computers — 1978

مع Michael Schroeder. من أهم الأعمال المبكرة في بروتوكولات authentication للشبكات الكبيرة. وتعدها Cambridge من القراءات المؤسسة في Computer Security. كامبردج

2. The Needham–Schroeder Authentication Protocol

النظام البروتوكولي الذي أصبح من أشهر الأمثلة في تاريخ authentication protocols، وأصبح لاحقًا مادة أساسية للبحث في التحقق الرسمي من البروتوكولات. مايكروسوفت

3. Grapevine: An Exercise in Distributed Computing — 1982

مع Birrell وLevin وSchroeder، وهو من الأعمال المهمة في تجربة وتصميم الأنظمة الموزعة. مايكروسوفت

4. A Global Authentication Service without Global Trust — 1986

مع Andrew Birrell وButler Lampson وMike Schroeder، ويقدم نموذجًا لخدمة authentication واسعة النطاق دون افتراض وجود ثقة عالمية موحدة. وقد نال العمل لاحقًا تقديرًا تاريخيًا ضمن IEEE. مايكروسوفت

5. Authentication: A Practical Study in Belief and Action — 1988

مع Michael Burrows وMartín Abadi؛ العمل الذي ارتبط بتأسيس BAN Logic لتحليل بروتوكولات المصادقة. كامبردج

6. Authentication Revisited — 1987

عمل لاحق ناقش مشكلات في بروتوكولات Needham–Schroeder والحلول المقترحة لها، وهو مثال جيد على أن عمله لم يكن “اختراع بروتوكول ثم الانتهاء”، بل عملية مستمرة من التحليل والتصحيح. مايكروسوفت

7. The Cambridge Distributed Computing System

كتاب/عمل شارك فيه Needham مع Andrew Herbert حول النظام الموزع في Cambridge، ويعكس الجانب الأنظمة-موزعة من مشروعه، بعيدًا عن اختزاله في الأمن. مايكروسوفت

8. TEA / XTEA

خوارزميات تشفير صممها مع David Wheeler، وأصبحت جزءًا من تاريخ التشفير التطبيقي، خصوصًا بسبب بساطتها وصغر حجم تنفيذها. مايكروسوفت

9. Computer Systems: Theory, Technology, and Applications

كتاب Festschrift ضخم صدر تكريمًا لمسيرته، ويضم عشرات الأوراق التي تعكس المجالات التي أثر فيها Needham. Cambridge توثق اجتماع 50+5 والكتاب المرتبط به. كامبردج

الخلاصة

N — Roger Needham اختيار مختلف جدًا عن Molyneux، ومفيد جدًا لبنية قائمتك.

Molyneux يمثل:

العالم الافتراضي ⇨ المحاكاة ⇨ السلوك ⇨ التفاعل

أما Needham فيمثل:

النظام ⇨ التوزيع ⇨ الهوية ⇨ الثقة ⇨ الحماية ⇨ الأمن

وإذا كان Berners-Lee قد ساهم في جعل العالم المعلوماتي متصلًا، فإن Needham ساهم في جعل السؤال التالي ممكنًا:

كيف نعرف أن الطرف الذي يتصل بهذا العالم هو فعلًا من يقول إنه هو؟

ولهذا فإن التصنيف الأنسب له في مسردك ليس مجرد Computer Scientist، بل:

Systems Programming — Distributed Systems — Operating Systems — Computer Security — Authentication Protocols — Cryptographic Systems

وما يجعله قويًا جدًا هو أنه لم يدخل الأمن من باب التشفير وحده؛ بل وصل إليه من جوهر هندسة النظام نفسه. وهذا بالضبط ما يفسر اتساع أثره من TITAN وCAP وCambridge Ring إلى Needham–Schroeder وBAN Logic وTEA، ثم إلى تأسيس Microsoft Research Cambridge. مايكروسوفت

O’Hearn, Peter

O — Peter O’Hearn

Peter William O’Hearn اختيار شديد القوة لحرف O، لأنه يمثل مرحلة مختلفة تمامًا في تاريخ البرمجة البريطانية: البرمجة بوصفها شيئًا يمكن إثبات خصائصه رياضيًا. وإذا كان Roger Needham في N قد ركز على حماية الأنظمة والبروتوكولات، فإن O’Hearn ينتقل إلى سؤال أعمق: كيف نثبت أن البرنامج نفسه يفعل ما ينبغي أن يفعله؟ وهو باحث بريطاني في علوم الحاسوب، أستاذ في UCL وباحث في Meta، وانتُخب Fellow of the Royal Society عام 2018. royalsociety.org

1. موقعه في تاريخ البرمجة

O’Hearn ليس من المبرمجين الذين ترتبط شهرتهم بتطبيق جماهيري واحد. قوته تقع في منطقة أكثر تجريدًا:

Program → Logic → Proof → Verification → Automated Analysis

وهذه السلسلة بالذات تجعل وجوده بعد Needham منطقيًا جدًا. Needham كان يسأل عن أمن النظام والبروتوكول؛ O’Hearn جعل السؤال يمتد إلى صحة البرنامج نفسه.

ولهذا تصفه Royal Society بأنه صاحب مساهمات رئيسية في science and engineering of program correctness، وأن عمله يمتد من المنطق الرياضي المجرد إلى التحليل الآلي لبرمجيات صناعية تستخدم على نطاق واسع. royalsociety.org

2. خلفيته ليست بريطانية بالميلاد، لكنها بريطانية بوضوح في مساره العلمي

وُلد O’Hearn عام 1963 في Halifax, Nova Scotia في كندا، ثم تلقى جزءًا أساسيًا من تكوينه الأكاديمي في كندا، قبل أن ينتقل إلى المملكة المتحدة ويصبح أحد أبرز أعلام مدرسة المنطق والبرمجة فيها. حصل على الدكتوراه في علوم الحاسوب من Queen’s University، وكان موضوع أطروحته Semantics of Non-interference: A Natural Approach تحت إشراف Robert D. Tennent. ويكيبيديا

ثم عمل في Syracuse، وبعدها Queen Mary University of London، ثم أصبح أستاذًا في UCL، قبل انتقاله إلى القطاع الصناعي عبر Monoidics ثم Facebook/Meta. ACM

إذن وضعه في مسرد British programmers يرتبط أساسًا بمسيرته العلمية والمهنية البريطانية وتأثيره في علوم الحاسوب البريطانية، لا بمكان الميلاد.

3. البداية الحقيقية: المنطق والبرمجة

منذ بداياته كان O’Hearn يعمل في منطقة Programming Languages + Logic.

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

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

أما السؤال الذي يهم عالم التحقق الرسمي فهو:

ما الذي يمكنني إثباته عن البرنامج؟

والفرق بين الاثنين هائل.

قد تجرب برنامجًا مليون مرة ولا تجد خطأً، لكن هذا لا يثبت عدم وجود خطأ.

أما البرهان فيحاول إعطاءك شيئًا أقوى:

إذا تحققت الشروط X، فإن البرنامج يضمن النتيجة Y.

هنا تتحول البرمجة من ممارسة تجريبية إلى موضوع للاستدلال الرياضي.

4. من Hoare Logic إلى مشكلة الذاكرة

المشكلة القديمة في التحقق من البرامج كانت مناسبة نسبيًا عندما نتعامل مع متغيرات وقيم بسيطة.

لكن البرامج الحديثة تتعامل مع:

Pointers

Heap

Linked Lists

Trees

Objects

Shared Mutable State

وهنا تصبح الأمور أكثر تعقيدًا بكثير.

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

وهنا ظهر العمل الذي سيصبح محور اسم O’Hearn:

Separation Logic

5. Separation Logic

طوّر O’Hearn مع John C. Reynolds نظرية Separation Logic، والتي أصبحت واحدة من أهم التطورات في reasoning about programs. Royal Society تصفها بأنها نظرية فتحت إمكانات جديدة لتوسيع نطاق الاستدلال المنطقي على الكود. royalsociety.org

الفكرة الأساسية يمكن تبسيطها هكذا:

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

أي بدل أن أفكر في:

Program = giant indivisible state

أستطيع التفكير في:

Program = أجزاء + موارد + علاقات + استقلال نسبي

وهذه فكرة شديدة القوة.

6. كلمة “Separation” هنا هي قلب النظرية

لنفترض أن لدينا:

P ⇨ memory region A

و

Q ⇨ memory region B

وكان:

A ∩ B = ∅

فيمكننا تحليل P وQ بصورة منفصلة بدرجة كبيرة.

لكن إذا كان:

P ⇨ A

و

Q ⇨ A

فالمشكلة تصبح مختلفة تمامًا؛ لأن الاثنين يتشاركان المورد نفسه.

إذن Separation Logic لا تقول فقط:

“هناك ذاكرة.”

بل تسأل:

من يملك أي جزء من الحالة؟ وكيف يمكن إثبات أن هذا الجزء منفصل عن ذاك؟

وهذه طريقة جديدة للنظر إلى البرنامج نفسه.

7. لماذا كانت الفكرة مهمة إلى هذا الحد؟

لأن إحدى أكبر مشكلات formal verification هي scalability.

يمكنك نظريًا إثبات صحة برنامج صغير.

لكن ماذا تفعل مع برنامج يتكون من:

ملايين الأسطر؟

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

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

وهذا بالضبط ما جعل Separation Logic مهمة: local reasoning.

أي:

أثبت ما يحدث هنا ⇨ ثم استنتج ما يمكن أن يحدث للنظام الأكبر.

وتشرح دراسة شارك فيها O’Hearn وDavid Pym وJonathan Spring أن قوة Separation Logic تأتي من الجمع بين نموذج مهندس البرمجيات لمعالجة الذاكرة والنموذج المنطقي، مع proof theory يساعد على توسيع عملية الاستدلال. Springer Nature

8. Bunched Logic: الأساس الذي سبق Separation Logic

قبل Separation Logic كانت هناك مرحلة أساسية في تعاون O’Hearn مع David Pym حول ما يعرف بـBunched Logic وLogic of Bunched Implications (BI).

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

لكن موارد الحاسوب ليست كذلك دائمًا.

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

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

وهذا ما وفر أساسًا نظريًا مهمًا للعمل اللاحق في Separation Logic؛ وRoyal Society تشير صراحة إلى أن Separation Logic بنيت على العمل السابق لـO’Hearn وPym في logic for resources. royalsociety.org

9. ثم جاءت Concurrent Separation Logic

المشكلة التالية كانت Concurrency.

إذا كان لديك برنامج واحد، فالأمر صعب.

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

عمل O’Hearn مع Stephen Brookes على Concurrent Separation Logic، التي وسعت أفكار Separation Logic للتعامل مع البرامج المتزامنة. وتذكر ACM أن هذا العمل كان من التطورات الرئيسية في التحقق من البرامج المتزامنة. ACM

وهنا يظهر اتساع مشروعه:

Separation Logic

⇨ الذاكرة

ثم:

Concurrent Separation Logic

⇨ الذاكرة + التزامن

أي أن النظرية أصبحت أكثر قربًا من البرامج الحقيقية.

10. وهذه النقطة تربطه بـRoger Needham

هنا تصبح N → O من أقوى الانتقالات في قائمتك.

Needham كان يعمل على:

Operating Systems

Distributed Systems

Authentication

Security

O’Hearn يعمل على:

Program Logic

Memory

Concurrency

Verification

كلاهما يتعامل مع الأنظمة التي أصبحت معقدة بسبب التفاعل بين أجزاء متعددة.

لكن Needham يسأل:

كيف أجعل النظام آمنًا؟

O’Hearn يسأل:

كيف أستطيع أن أثبت خصائص ما يفعله النظام؟

وهذا انتقال من:

System Security

إلى:

Program Correctness

11. من النظرية إلى الصناعة: Monoidics

بعد أكثر من عشرين عامًا في الوسط الأكاديمي، شارك O’Hearn في تأسيس Monoidics، وهي شركة متخصصة في تقنيات verification وتحليل البرمجيات.

وهنا حدث التحول الأهم في مسيرته:

نظرية رياضية ⇨ منتج برمجي.

لم تعد Separation Logic ورقة بحثية.

أصبحت أساسًا لأدوات تستطيع فحص كود حقيقي واسع النطاق.

واستحوذت Facebook على Monoidics عام 2013، وانتقل O’Hearn إلى Facebook مع هذا الاستحواذ. royalsociety.org

12. Infer: اللحظة التي أصبحت فيها النظرية أداة للمبرمج

هنا نصل إلى أهم مرحلة في مسيرته البرمجية التطبيقية:

Infer

وهو static analyzer طوره فريق O’Hearn في Facebook، يعتمد على أفكار في Separation Logic والتحليل الآلي للبرامج.

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

وقد ذكرت Meta أن Infer كان يكشف أكثر من ألف bug شهريًا في مرحلة مبكرة من استخدامه داخل Facebook، بينما تذكر Royal Society أن استخدامه أدى إلى إصلاح عشرات الآلاف من المشكلات قبل وصولها إلى الإنتاج. Engineering at Meta

هنا تصبح أهمية O’Hearn واضحة جدًا:

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

13. Bi-abduction: الآلية التي جعلت التحليل قابلًا للتوسع

من أهم الأعمال التي قادت إلى Infer ورقة:

Compositional Shape Analysis by Means of Bi-Abduction

بمشاركة Cristiano Calcagno وDino Distefano وPeter O’Hearn وHongseok Yang.

وقد حصل هذا العمل على ACM SIGPLAN Most Influential POPL Paper Award 2019. وتوضح Meta أن التقنيات الواردة فيه أصبحت جزءًا من تطوير Infer، الذي يفحص الكود بحثًا عن الأخطاء قبل الشحن. Engineering at Meta

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

Bi-abduction يحاول استنتاج هذه المعلومات تلقائيًا.

أي:

Unknown precondition + known effect ⇨ infer missing assumptions

وهذا يقلل مقدار المعلومات التي يجب على الإنسان كتابتها يدويًا.

14. هنا يتحول O’Hearn من “منظّر” إلى مهندس أدوات

وهذه ربما أهم نقطة في تقييمه.

كثير من الباحثين في formal methods يقدمون نظريات قوية، لكن المسافة بين النظرية والكود الصناعي قد تبقى كبيرة.

مشروع O’Hearn مختلف:

Logic

⇨

Proof rules

⇨

Static analysis

⇨

Automation

⇨

Industrial codebases

Royal Society تصف مسيرته تحديدًا بأنها تمتد من abstract mathematical logics إلى automated analysis of industrial software. royalsociety.org

وهذه ليست مجرد عبارة عن “تأثير أكاديمي”؛ إنها وصف لطبيعة المشروع نفسه.

15. Incorrectness Logic: قلب السؤال ينقلب

في مرحلة لاحقة طور O’Hearn اتجاهًا آخر مهمًا هو Incorrectness Logic.

وهنا تحدث حركة فكرية جميلة جدًا.

في correctness reasoning نسأل:

هل أستطيع إثبات أن البرنامج لا يخالف الخاصية؟

أما incorrectness reasoning فيسأل:

هل أستطيع إثبات وجود مسار يؤدي إلى خطأ؟

وهذا تغيير في الهدف.

فبدل محاولة إثبات أن البرنامج صحيح في كل الحالات، يمكن للأداة البحث عن أخطاء حقيقية قابلة للإثبات.

UCL تصف O’Hearn بأنه صاحب إسهامات في كل من Separation Logic وIncorrectness Logic، وتضعهما ضمن أعماله في إعادة تشكيل reasoning tools المستخدمة صناعيًا. University College London

16. وهذا مهم جدًا لعصر أدوات تحليل الكود

لأن البرمجيات الصناعية ليست مسألة:

Correct / Incorrect

فقط.

المهندس يريد معرفة:

أين الخطأ؟

كيف أصل إليه؟

ما المسار الذي ينتج عنه؟

هل الخطأ حقيقي أم مجرد إنذار كاذب؟

هل يمكن اكتشافه آليًا؟

وهنا تصبح Incorrectness Logic أقرب إلى فلسفة:

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

وهذا يجعل عمل O’Hearn متصلًا مباشرة بأدوات static analysis الحديثة.

17. علاقته بـProgramming Languages

O’Hearn ليس متخصصًا في verification بمعزل عن Programming Languages.

أبحاثه تقع في منطقة تلتقي فيها:

Programming Languages

Semantics

Logic

Program Analysis

Formal Verification

وهذا مهم جدًا لأن البرنامج بالنسبة إليه ليس مجرد نص.

إنه كائن رياضي يمكن دراسة سلوكه.

ومن هنا تأتي علاقته الفكرية مع Christopher Strachey في حرف C.

Strachey كان من رواد تحويل البرامج إلى موضوع للـformal semantics.

O’Hearn أخذ الفكرة إلى مستوى آخر:

إذا كان للبرنامج معنى رسمي، فيمكننا استخدام هذا المعنى للاستدلال على صحة البرنامج.

18. علاقته بـCodd أيضًا مثيرة

Codd في حرف E جعل البيانات موضوعًا للتجريد الرياضي.

O’Hearn يفعل شيئًا مشابهًا مع حالة البرنامج وذاكرته.

Codd:

Data → Relations → Algebra

O’Hearn:

Program State → Resources → Logic → Proof

كلاهما يأخذ شيئًا عمليًا جدًا — البيانات في حالة Codd، والذاكرة والسلوك البرمجي في حالة O’Hearn — ويضعه داخل إطار تجريدي يسمح بالتعامل معه بصورة منهجية.

19. منطق الموارد عند O’Hearn بالغ الأهمية

هناك كلمة واحدة يمكن أن تلخص الكثير من مشروع O’Hearn:

Resource.

الذاكرة مورد.

الـpointer مورد.

الـlock مورد.

حق الوصول مورد.

ملكية جزء من الحالة مورد.

وبمجرد أن تعامل الموارد بهذه الطريقة، تستطيع أن تبدأ في صياغة أسئلة دقيقة:

من يملك المورد؟

من يستطيع تغييره؟

هل يستطيع thread آخر الوصول إليه؟

هل يمكن تحريره مرتين؟

هل يمكن فقدانه؟

هل يمكن إثبات أن موردًا معينًا لا يُستخدم بعد تحريره؟

وهكذا تصبح أخطاء مثل memory leaks وuse-after-free وresource misuse أشياء يمكن للنظام أن يستدل عليها بدل انتظار حدوثها.

20. وهذا هو السبب في أن Infer مهم

في الاستخدام الصناعي، لا يريد المبرمج “منطقًا جميلًا”.

يريد:

Commit → Analysis → Bug → Fix

وهذا بالضبط ما جعل انتقال O’Hearn إلى الصناعة ذا أهمية تاريخية.

فالفكرة التي بدأت كبحث في المنطق أصبحت أداة تستطيع فحص ملايين الأسطر من الكود بصورة آلية؛ وتذكر Imperial College أن Infer استُخدم لفحص ملايين الأسطر في بيئات صناعية، بينما تشير Meta وRoyal Society إلى نطاق استخدامه وإلى أعداد كبيرة من المشكلات التي ساعد في اكتشافها. VTSS

21. ثم عاد إلى Meta والـAI

O’Hearn عاد إلى Meta في خريف 2024 للانضمام إلى فريق AI، بعد مرحلة عمل في Lacework في مجال أمن البرمجيات. وتضع Royal Society حاليًا منصبه كـProfessor في UCL وResearch Scientist في Meta. royalsociety.org

وهذه العودة مثيرة جدًا من الناحية الفكرية.

لأن AI يعيد إنتاج المشكلة القديمة نفسها ولكن على نطاق جديد:

كيف نعرف ما الذي يفعله النظام؟

كيف نتحقق من سلوكه؟

كيف نبحث عن أخطاء في نظام معقد؟

والانتقال من program verification إلى reasoning about AI systems يبدو امتدادًا طبيعيًا جدًا لمشروعه، وإن كان المجال نفسه لا يزال يتطور.

22. تكريماته تكشف طبيعة تأثيره

حصل O’Hearn على عدد من أهم الجوائز في علوم الحاسوب النظرية والتطبيقية، منها:

• Royal Society Wolfson Research Merit Award — 2007
• Gödel Prize — 2016
• Computer Aided Verification Award — 2016
• Fellow of the Royal Academy of Engineering — 2016
• Fellow of the Royal Society — 2018
• Most Influential POPL Paper Award — 2011 و2019 لأعمال مرتبطة بمساره البحثي.
• ACM Fellow ضمن دفعة 2024، تقديرًا لإسهاماته في reasoning about programs. royalsociety.org

واللافت أن الجوائز تغطي الطرفين معًا:

Theory ⇄ Engineering

وهو بالضبط محور مسيرته.

23. لذلك O’Hearn يمثل شيئًا مختلفًا عن Needham

Needham:

كيف أحمي النظام؟

O’Hearn:

كيف أثبت ما يفعله النظام؟

Strachey:

ما معنى البرنامج؟

O’Hearn:

ماذا يمكنني أن أستنتج منطقيًا عن البرنامج؟

Fowler:

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

O’Hearn:

كيف أتحقق آليًا من خصائص البرنامج؟

وهكذا فإن وجوده في القائمة يضيف طبقة لم تكن واضحة بالقدر نفسه في الأسماء السابقة:

The Program as a Mathematical Object

24. والأجمل أنه لم يتوقف عند الرياضيات

لو بقي O’Hearn عند Separation Logic وحدها، لكان أثره النظري ضخمًا بالفعل.

لكن ما يجعل مسيرته أكثر تميزًا هو المسار:

Bunched Logic

⇨ Separation Logic

⇨ Concurrent Separation Logic

⇨ Bi-abduction

⇨ Monoidics

⇨ Infer

⇨ Incorrectness Logic

أي أن هناك خطًا واضحًا من المنطق إلى الأداة.

ولهذا فإن وصفه بأنه “عالم نظري” فقط لا يلتقط الجزء الأهم من مسيرته.

25. أهم أعمال Peter O’Hearn

1. The Logic of Bunched Implications — 1999

مع David Pym، وهو من الأعمال المؤسسة للمنطق الذي سبق Separation Logic وقدم إطارًا للتعامل المنطقي مع الموارد.

2. Separation Logic: A Logic for Shared Mutable Data Structures

مع John C. Reynolds؛ العمل المركزي في تأسيس Separation Logic وتطبيقها على هياكل البيانات ذات الذاكرة المشتركة.

3. Concurrent Separation Logic

مع Stephen Brookes؛ توسيع النظرية إلى البرامج المتزامنة.

4. Separation and Information Hiding

مع Hongseok Yang وJohn Reynolds، ويدرس قواعد الإثبات الخاصة بإخفاء المعلومات باستخدام Separation Logic. دوى

5. Compositional Shape Analysis by Means of Bi-Abduction

مع Cristiano Calcagno وDino Distefano وHongseok Yang؛ أحد أهم الأعمال التي قادت إلى التقنية التي أصبحت جزءًا من Infer، وحصل على Most Influential POPL Paper Award عام 2019. Engineering at Meta

6. Separation Logic — 2019

مقالته التركيبية المهمة في Communications of the ACM، والتي يقدم فيها نظرة شاملة على النظرية وتاريخها وأفكارها. UCL Discovery

7. Incorrectness Logic

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

8. Infer

ليس ورقة واحدة، بل منظومة برمجية تطبيقية أصبحت التجسيد الصناعي الأوضح للمسار الذي بدأ من Separation Logic. Engineering at Meta

الخلاصة

O — Peter O’Hearn يمثل في قائمتك البرمجة القابلة للإثبات.

ليس إنجازه الأساسي أن يكتب برنامجًا أسرع، أو نظامًا أكثر انتشارًا، أو لعبة أكثر تعقيدًا؛ بل أن يجعلنا قادرين على الانتقال من:

“أظن أن البرنامج صحيح”

إلى:

“أستطيع أن أبرهن خصائص محددة عنه.”

ثم ذهب أبعد من ذلك:

Logic → Proof → Analysis → Automation → Industrial Software

وهذا المسار هو الذي يجعل O’Hearn اسمًا مهمًا جدًا في تاريخ البرمجة البريطانية الحديثة. والأهم أن Separation Logic لم تبقَ نظرية أكاديمية؛ لقد أصبحت جزءًا من الطريق الذي أدى إلى Infer، أي إلى أدوات تفحص البرمجيات الصناعية وتكتشف مشكلات قبل وصولها إلى المستخدمين. Royal Society تلخص مسيرته تحديدًا بهذه الرحلة من المنطق الرياضي المجرد إلى التحليل الآلي للبرمجيات الصناعية. royalsociety.org

وبهذا يصبح تسلسل N → O ممتازًا جدًا:

Roger Needham:
النظام الموزع يحتاج إلى هوية وثقة وأمن.

Peter O’Hearn:
البرنامج المعقد يحتاج إلى منطق وإثبات وتحليل آلي.

أي أن Needham جعلنا نسأل هل نستطيع الوثوق بالنظام؟، بينما O’Hearn جعلنا نسأل هل نستطيع إثبات ما يفعله النظام؟ — وهذه نقلة عميقة جدًا داخل تاريخ علوم البرمجة.

Paul Graham

P — Paul Graham

Paul Graham يمثل في قائمتك نوعًا مختلفًا جدًا من المبرمجين. فهو ليس أساسًا مبرمج أنظمة مثل Roger Needham، ولا باحثًا في صحة البرامج مثل Peter O’Hearn، ولا مهندس ويب بالمعنى الذي يمثله Tim Berners-Lee؛ بل هو مبرمج لغات، ومبرمج تطبيقات، ومصمم أدوات، ومهندس برمجيات يرى اللغة نفسها جزءًا من البرنامج. وهذا تحديدًا هو المدخل الصحيح لفهمه.

1. البداية: مبرمج يفكر في اللغة قبل التطبيق

غراهام درس علوم الحاسوب في Cornell ثم حصل على الدكتوراه من Harvard، وتصف سيرته الرسمية نفسها بوضوح: programmer, writer, and investor. والأهم أن اهتمامه البرمجي لم يكن عرضيًا؛ فقد قال لاحقًا إنه كان متخصصًا أساسًا في لغات البرمجة، وخصوصًا لهجات Lisp. بول غراهام

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

2. On Lisp: هنا تظهر فلسفته البرمجية كاملة

كتاب On Lisp الصادر سنة 1993 هو ربما أهم وثيقة لفهم غراهام كمبرمج. الكتاب ليس مجرد شرح لـ Lisp، وإنما دفاع تقني عن فكرة أن المبرمج يستطيع استخدام اللغة لكي يبني لغة أخرى فوقها: macros، abstraction، embedded languages، bottom-up programming وغيرها. بول غراهام

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

3. Bottom-up programming

في مقاله Programming Bottom-Up، الذي كان مقدمة لـ On Lisp، يشرح غراهام الفرق بين التصميم التقليدي top-down وبين ما يسميه bottom-up: بدل أن تقسم المشكلة تدريجيًا إلى إجراءات أصغر، تبني أثناء العمل مجموعة من operators وabstractions تجعل المشكلة نفسها أسهل في التعبير. بول غراهام

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

4. وهذا يقود مباشرة إلى Viaweb

في 1995 أسس غراهام مع Robert Morris شركة Viaweb. وكانت الفكرة الأساسية أن المستخدم يستطيع بناء متجر إلكتروني عبر الويب، بينما يعمل البرنامج على الخادم بدلًا من أن يكون برنامجًا يُثبَّت على جهاز العميل. تصف سيرة غراهام Viaweb بأنها أول شركة SaaS، بينما يصف غراهام نفسه النظام بأنه، بحسب علمه، أول تطبيق Web من هذا النوع. بول غراهام

المهم هنا ليس لقب “الأول” بقدر ما حدث برمجيًا. كان غراهام وموريس يبنيان برنامجًا تجاريًا حقيقيًا في لحظة كان فيها Web application model نفسه لا يزال جديدًا. والأهم أن الجزء الأساسي من النظام كان مكتوبًا بـ Lisp.

5. Lisp لم تكن عنده هواية أكاديمية

هذه النقطة هي التي تجعل Viaweb مهمة في تاريخ غراهام. لم يكن يستخدم Lisp لأنه يحب اللغة فحسب؛ كان يختبر فرضية عملية: هل يمكن للغة أكثر تعبيرًا أن تمنح فريقًا صغيرًا قدرة تطويرية أكبر من فريق كبير يستخدم لغة أكثر تقليدية؟

في Beating the Averages يشرح أن Viaweb استخدمت Lisp أساسًا بسبب سرعة التطوير، وأن الطبيعة server-side للتطبيق سمحت بإطلاق التغييرات فورًا. ويذكر أن محرر Viaweb كان مكتوبًا أساسًا بـ Lisp، بينما استُخدم C لأجزاء أخرى مثل نظام الطلبات. Ask Graham

6. الـ macros كانت قلب الحجة

أكثر ما يجعل تجربته مع Lisp مثيرة هو أن غراهام لم يكن يتحدث عن “لغة أعلى مستوى” بالمعنى التسويقي المعتاد. كان يقصد تحديدًا قدرة Lisp على البرمجة بالبرامج عبر macros.

بحسب عرضه عن Viaweb، كان نحو 20–25% من كود محررها macros. وهو يستخدم هذه النسبة للدلالة على أن جزءًا معتبرًا من النظام كان يفعل أشياء يصعب التعبير عنها بسهولة في لغات أخرى. بول غراهام

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

7. The Blub Paradox

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

هذه فكرة أعمق من مجرد “Lisp أفضل من Java”. غراهام يحاول شرح مشكلة معرفية في مقارنة لغات البرمجة: كيف تقارن قدرتين عندما تكون اللغة التي تستخدمها تحدد ما تستطيع التفكير فيه بسهولة؟

وهذا يربط غراهام مباشرة بتاريخ فلسفة لغات البرمجة. فاللغة عنده ليست syntax فقط؛ إنها وسط تفكير computational medium.

8. ANSI Common Lisp

بعد On Lisp جاء ANSI Common Lisp عام 1995، وهو مختلف في وظيفته. فبدل التركيز على التقنيات المتقدمة وحدها، قدم غراهام كتابًا يجمع بين تعليم Lisp والمرجع العملي للغة وفق معيار ANSI. يحتوي على أمثلة للـ ray tracing، توليد النصوص، pattern matching، logical inference، HTML generation، compression وغيرها.

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

9. ثم انتقل من اللغة إلى مشكلة تصنيف النصوص

في 2002 كتب A Plan for Spam بعد بناء نظام لمكافحة الرسائل المزعجة. وهنا نرى غراهام يتحول من metaprogramming إلى تصنيف إحصائي للنصوص.

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

لكن من المهم تاريخيًا ألا ننسب إليه اختراع Bayesian spam filtering من الصفر. هو نفسه أشار إلى أعمال سابقة في تصنيف النصوص وإلى ورقتين عن Bayesian spam filtering قُدمتا عام 1998. مساهمته كانت في هندسة الفكرة وتطبيقها عمليًا وصياغتها بصورة جعلتها شديدة الانتشار بين المبرمجين. بول غراهام

10. هذه مرحلة مهمة في تاريخ البرمجة التطبيقية

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

وهذا يكشف سمة متكررة في مسيرته: اهتمامه ليس فقط بـ “هل الخوارزمية صحيحة؟”، بل أيضًا بـ هل يمكن أن تجعل البرنامج أفضل فعلًا؟ وهل تستطيع البنية البرمجية أن تجعل الفكرة قابلة للتطبيق بسرعة؟

11. Arc ثم Bel

اهتمامه باللغات لم يتوقف عند Common Lisp. شارك في تطوير Arc، وهي Lisp dialect موجهة بدرجة كبيرة إلى البرمجة العملية على الويب. ثم في 2019 نشر Bel، وهي تجربة أكثر جذرية: لغة Lisp جديدة مكتوبة بنفسها. بول غراهام

Bel مهمة جدًا في تقييمه كمبرمج؛ لأنها تُظهر أن مشروعه لم يكن مجرد حنين إلى Lisp الكلاسيكية. بعد عقود من العمل، عاد إلى السؤال الأساسي نفسه: ما أقل بنية تحتاجها لغة برمجة قوية؟

وكون Bel مكتوبة في نفسها يعيد غراهام تقريبًا إلى أصل Lisp التاريخي: اللغة التي تصف نفسها وتنفذ نفسها، فتختفي الحدود بين specification وimplementation وprogram.

12. من هنا يصبح غراهام “مبرمجًا للغات” بامتياز

إذا أردنا وضعه داخل مسردك، فأنا لا أضعه تحت خانة “مبرمج تطبيقات ويب” فقط؛ هذه ستكون قراءة ضيقة جدًا.

الأدق:

Paul Graham = Language-oriented programmer + Metaprogrammer + Web application programmer + Applied statistical programmer.

والخيط الذي يصل كل هذه المجالات هو واحد: محاولة جعل البرنامج أكثر تعبيرًا من خلال تغيير الأدوات التي يُكتب بها.

13. المفارقة: أشهر أعماله خارج البرمجة المباشرة

بعد بيع Viaweb إلى Yahoo عام 1998، أصبح إنتاج غراهام الكتابي أكثر بروزًا. ومنذ 2001 نشر سلسلة طويلة من المقالات عن البرمجة، واللغات، والـ hackers، والشركات الناشئة، والتصميم، والبحث. وتضم قائمته أعمالًا مثل The Roots of Lisp، Five Questions about Language Design، Beating the Averages، Programming Bottom-Up، Hackers & Painters وA Plan for Spam. بول غراهام

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

14. Y Combinator: الأثر غير المباشر للمبرمج

في 2005 أسس غراهام مع Jessica Livingston وRobert Morris وTrevor Blackwell Y Combinator. ووفق بيانات YC الحالية، موّلت المؤسسة أكثر من 3000 شركة ناشئة، من بينها Airbnb وDropbox وStripe وReddit. بول غراهام

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

وبالتالي فإن أثر غراهام أصبح طبقتين: طبقة مباشرة تتمثل في Lisp وViaweb وspam filtering وArc وBel، وطبقة غير مباشرة تتمثل في البنية المؤسسية التي ساعدت عددًا هائلًا من المبرمجين على تحويل البرامج إلى شركات.

15. وحتى مفهوم “Founder Mode” خرج من هذا العالم

في 2024 أعاد غراهام طرح مفهوم Founder Mode في مقال أثار نقاشًا واسعًا حول إدارة الشركات التقنية، مستندًا إلى حديث Brian Chesky في فعالية لـ Y Combinator.

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

16. مكانته داخل خط قائمتك

وهنا يصبح وجوده بعد O’Hearn مثيرًا جدًا. O’Hearn أخذ البرنامج إلى مستوى المنطق الرياضي والتحقق الآلي؛ غراهام أخذه إلى مستوى آخر: اللغة التي تجعل البرنامج ممكنًا أصلًا.

Strachey كان يبحث في semantics واللغات؛ Codd أعاد تعريف كيفية التعامل البرمجي مع البيانات؛ Hinton جعل البرنامج يتعلم التمثيلات؛ Berners-Lee أعاد تعريف البنية التي تعمل عليها تطبيقات الشبكة؛ Needham بنى عالم الأنظمة الموزعة والأمن؛ O’Hearn جعل صحة البرامج موضوعًا للتحليل الآلي. أما Graham فمحوره هو:

اللغة → التعبير → abstraction → metaprogramming → التطبيق.

وهذا يجعل اختياره لحرف P قويًا جدًا من ناحية تمثيل مدرسة كاملة من البرمجة البريطانية: البرمجة التي لا تكتفي باستخدام اللغة، بل تعتبر اللغة نفسها مادة هندسية قابلة لإعادة البناء.

أهم الأعمال البرمجية والفكرية

1. On Lisp (1993) — الكتاب الأهم لفهم metaprogramming وmacros وbottom-up programming عند غراهام. بول غراهام
2. ANSI Common Lisp (1995) — مرجع وتعليم شامل لـ Common Lisp.
3. Viaweb (1995–1998) — تطبيق تجارة إلكترونية Web-based بُني أساسًا باستخدام Lisp، ثم أصبح Yahoo Store بعد الاستحواذ. Ask Graham
4. Programming Bottom-Up (1993) — صياغة مبكرة ومركزة لفلسفته في بناء اللغة بالتوازي مع بناء البرنامج. بول غراهام
5. Beating the Averages (2001) — الوثيقة الأشهر عن تجربة Lisp داخل Viaweb. بول غراهام
6. A Plan for Spam (2002) — تطبيق Bayesian filtering لمكافحة البريد المزعج. بول غراهام
7. Better Bayesian Filtering (2003) — تطوير منهجي لخوارزمية التصنيف وتحليل نقاط قوتها. بول غراهام
8. Hackers & Painters (2004) — مجموعة مقالات تربط البرمجة بالتصميم والإبداع وبناء المنتجات.
9. Arc — لهجة Lisp صممها للاستخدام البرمجي العملي، خصوصًا في سياق الويب.
10. Bel (2019) — مواصفة ولغة Lisp مكتوبة في نفسها، تمثل عودة غراهام إلى جوهر مشروعه اللغوي. بول غراهام

الخلاصة التقنية: Paul Graham ليس مجرد “مبرمج كتب Lisp جيدًا”. مشروعه الأعمق هو جعل المبرمج قادرًا على إعادة تشكيل اللغة بحيث تصبح المشكلة نفسها أبسط. وهذا بالضبط ما يجعل وجوده في مسردك مختلفًا عن مجرد إضافة مبرمج Web أو مؤسس شركة: غراهام ينتمي إلى تقليد الـ programmer-as-language-designer، حيث تكون كتابة البرنامج وكتابة اللغة التي سيُكتب بها البرنامج عمليتين متداخلتين.

Quentin Stafford-Fraser

Q — Quentin Stafford-Fraser

Quentin Stafford-Fraser حالة شديدة الخصوصية في مسردك؛ لأن شهرته العالمية مرتبطة بقطعة تقنية تبدو اليوم شديدة البساطة: كاميرا تصور إبريق قهوة. لكن اختزال الرجل في “مخترع أول Webcam” يظلمه برمجيًا؛ فالمثير في مسيرته هو أنه كان يعمل عند تقاطع الشبكات، والواجهات، والوسائط، والأنظمة العميلة/الخادمة، والتفاعل بين الإنسان والحاسوب. وما فعله في غرفة القهوة كان نموذجًا مبكرًا جدًا لفكرة ستصبح لاحقًا جوهر الإنترنت التفاعلي: تحويل حالة فيزيائية إلى معلومة مرئية يمكن الوصول إليها عن بُعد. CST Cambridge

1. كامبريدج قبل الـ WebCam

درس Stafford-Fraser علوم الحاسوب في جامعة كامبريدج، وأصبح عام 1989 أول Computer Officer لكلية Gonville & Caius، ثم انتقل إلى مجموعة الأنظمة في مختبر الحاسوب بجامعة كامبريدج. وتشير المصادر إلى أنه شغّل أول خادم Web في الجامعة عام 1992. ويكيبيديا

هذه التفاصيل مهمة لأن قصة الـ Coffee Pot لم تبدأ من فراغ. كان يعمل داخل بيئة تقنية كان فيها Unix، X Window System، الشبكات المحلية، الحوسبة الموزعة، ومحطات العمل الرسومية تتطور بسرعة. ولذلك لم تكن فكرته “ضع كاميرا على الإنترنت”، بل كانت أقرب إلى سؤال هندسي: كيف أجعل جهازًا بعيدًا يرسل حالة مرئية إلى أجهزة أخرى داخل الشبكة؟

2. البداية لم تكن Webcam أصلًا

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

وهنا تكمن أول نقطة تجعل Stafford-Fraser مبرمجًا مهمًا: هو لم يخترع الكاميرا، ولم يخترع الشبكة، ولم يخترع الصورة الرقمية؛ بل كتب طبقة البرمجيات التي جعلت هذه العناصر تتصرف كنظام واحد.

3. XCoffee

برنامج XCoffee هو قلب مساهمته الأصلية. كان البرنامج يتعامل مع الصورة القادمة من الكاميرا ويجعلها قابلة للعرض عبر بيئة X Window System. وتوضح المصادر التاريخية أن XCoffee كان يتعامل مع طرفين مختلفين من الاتصال، ويحوّل استجابة الكاميرا إلى أوامر بروتوكول X11 لعرض النافذة. Kiwix Server

أي أن “كاميرا القهوة” لم تكن مجرد بث فيديو بالمعنى الحديث. كانت سلسلة معالجة بيانات:

Camera ⇨ Network/RPC ⇨ XCoffee ⇨ X11 ⇨ شاشة المستخدم

وهذه نقطة تستحق الانتباه؛ لأن ما يبدو اليوم كـ “صورة على صفحة” كان آنذاك مشكلة برمجية متعددة الطبقات.

4. ولم تكن الصورة Live Video

من الأخطاء الشائعة في رواية القصة إسقاط مفهوم البث الحديث على النظام القديم. في البداية كانت الصور تُلتقط على فترات متباعدة جدًا؛ وتشير وثيقة Cambridge Computer Lab Ring إلى ثلاث صور تقريبًا في الدقيقة. كامبردج

إذن الابتكار لم يكن في معدل الإطارات، وإنما في إتاحة الحالة المرئية عن بُعد. وهذه نقطة أعمق من مجرد “أول فيديو على الإنترنت”.

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

وهذه بالضبط إحدى اللبنات المفاهيمية التي ستصبح لاحقًا Web monitoring، dashboards، IoT، remote sensors، live feeds، security cameras وغيرها.

5. اللحظة التي غيّرت تاريخ المشروع

عندما بدأ متصفحا الويب في التعامل مع الصور، أصبح من الممكن أخذ النظام الموجود أصلًا وربطه بالـ HTTP والـ Web بدل أن يبقى أداة داخل بيئة X11 المحلية. وفي 1993 أصبحت صورة إبريق القهوة متاحة لمستخدمي الإنترنت. وتصف جامعة كامبريدج هذا التحول باعتباره اللحظة التي جعلت صورة ماكينة القهوة مرئية لمستخدمي الإنترنت حول العالم. كامبردج

وهنا تظهر براعة Stafford-Fraser بطريقة مختلفة: لم يحتج إلى اختراع نظام جديد بالكامل؛ بل أدرك أن بنية جديدة ظهرت في الخارج يمكن أن تستوعب النظام الموجود.

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

6. من X Window إلى Web

يمكن النظر إلى تاريخ Coffee Pot باعتباره انتقالًا بين نموذجين:

محطة عمل ⇨ شبكة محلية ⇨ X11

ثم:

متصفح ⇨ HTTP ⇨ Web ⇨ صورة

وهذا يجعل Stafford-Fraser قريبًا جدًا، من ناحية تاريخية، من Tim Berners-Lee، لكن مساهمته مختلفة. Berners-Lee بنى البنية العامة التي تسمح للوثائق والمعلومات بالارتباط عبر الشبكة؛ Stafford-Fraser أخذ تلك البنية وأظهر بصورة مبكرة جدًا أن الويب يمكن أن يكون نافذة على حالة فيزيائية حية.

ولهذا فإن CoffeeCam ليست مجرد طريفة تاريخية. إنها واحدة من البدايات المبكرة لفكرة Web as sensor interface.

7. المفارقة الجميلة: مشروع صغير جدًا، أثره ضخم جدًا

لم يكن المشروع مصممًا لكي يصبح منتجًا عالميًا. كان يحل مشكلة داخلية صغيرة: هل هناك قهوة أم لا؟

لكن هذا تحديدًا يكشف شيئًا مهمًا عن تاريخ البرمجة البريطانية في كامبريدج: كثير من الابتكارات لم تبدأ كمحاولات لبناء “الشيء الذي سيغير العالم”، بل كحلول عملية لمشكلات صغيرة داخل المختبر.

ولهذا فاختيار Stafford-Fraser لحرف Q ليس مجرد الاعتماد على شهرة الـ webcam. الرجل يمثل مدرسة المشكلة الصغيرة التي تكشف بنية تقنية جديدة.

8. VNC: وهنا تتضح أهميته أكثر

لو توقف Stafford-Fraser عند CoffeeCam لكان اسمه مرتبطًا بإنجاز تاريخي واحد فقط. لكن مسيرته اللاحقة أكثر أهمية برمجيًا مما توحي به شهرة القهوة.

في مختبر Olivetti Research Laboratory شارك في تطوير Virtual Network Computing (VNC)، وكتب العميل والخادم الأصليين لنظام Windows وفق المصادر التاريخية المتاحة عنه. كما شارك في أعمال لاحقة حول الأنظمة العميلة عديمة الحالة والتعاون الشبكي. ويكيبيديا

وهنا ينتقل من:

رؤية جهاز بعيد

إلى:

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

وهذا انتقال ضخم.

9. VNC كفكرة برمجية

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

وهذا يجعل العلاقة:

Remote machine ⇨ framebuffer ⇨ network ⇨ local display

مع الاتجاه المعاكس:

local keyboard/mouse ⇨ network ⇨ remote machine

وهنا نرى استمرارًا واضحًا في تفكير Stafford-Fraser: فصل واجهة العرض عن المكان الذي يحدث فيه التنفيذ.

وهو المبدأ نفسه الذي يظهر في أعماله حول stateless client systems؛ إذ تصف إحدى أوراقه النظام العميل عديم الحالة بأنه يفصل واجهة العرض عن منطق التطبيق، بحيث ينفذ الخادم التطبيقات بينما يعرض العميل الإطارات ويستقبل إدخال المستخدم. كامبردج

10. هذه ليست مصادفة

إذا وضعت XCoffee وVNC بجانب بعضهما، تظهر مسيرة تقنية متماسكة جدًا:

XCoffee:
جهاز فيزيائي بعيد ⇨ صورة ⇨ شاشة محلية.

VNC:
حاسوب بعيد ⇨ واجهة رسومية ⇨ شاشة محلية + إدخال عكسي.

أي أن Stafford-Fraser كان يعمل مرارًا على السؤال نفسه تقريبًا:

كيف أجعل المسافة بين المستخدم والشيء الذي يتعامل معه غير مهمة؟

وهذا في رأيي هو المفتاح الأفضل لقراءة مسيرته كلها.

11. Brightboard

في الدكتوراه عمل Stafford-Fraser مع Peter Robinson على Brightboard، وهو نظام لبيئة تفاعلية تجمع الفيديو والواجهات الرسومية. وتسجل كامبريدج أطروحته بعنوان Video Augmented Environments، المنجزة عام 1995/1996، كما تسجل ورقة Brightboard المنشورة في CHI عام 1996. كامبردج

هنا ينتقل اهتمامه من “كيف أعرض شيئًا بعيدًا؟” إلى سؤال أكثر تعقيدًا:

كيف يمكن للفيديو نفسه أن يصبح جزءًا من واجهة المستخدم؟

وهذا يقربه من Human-Computer Interaction وComputer Vision أكثر من كونه مجرد مبرمج شبكات.

12. لذلك تصنيفه البرمجي ليس Web programmer فقط

لو أردنا تصنيف Stafford-Fraser بدقة داخل مسردك، فالتسمية الأقرب ستكون:

Networked Interactive Systems Programmer

مع امتدادات إلى:

• Human–Computer Interaction
• Remote Desktop Systems
• Multimedia Systems
• Computer Vision Interfaces
• Client/Server Computing
• Web Applications

وهذا يميزه عن Berners-Lee: Berners-Lee جعل المعلومات مترابطة؛ Stafford-Fraser جعل الأشياء والواجهات قابلة للرؤية والتفاعل عبر المسافة.

13. لاحقًا: Pico والأمن

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

وهذا جانب أقل شهرة لكنه مهم؛ لأنه يوضح أن مسيرته ليست سلسلة من “اختراعات Web لطيفة”، بل مسار أوسع في بناء أنظمة تفاعل وشبكات وخدمات تعتمد على المستخدم والسياق.

14. Ndiyo والأنظمة العميلة الخفيفة

شارك كذلك في مشروع Ndiyo، المرتبط بفكرة الحوسبة ذات العميل الخفيف وتقليل تكلفة الوصول إلى الحوسبة والشبكات. كما تشير مصادر كامبريدج إلى ارتباطه بمشاريع وشركات أخرى مثل Newnham Research وExbiblio وTelemarq. ويكيبيديا

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

15. تأثيره الحقيقي ليس في “الكاميرا”

وهنا أرى أن أهم تصحيح تاريخي في تقييم Stafford-Fraser هو التالي:

اختزاله في أول Webcam يقلل من أهميته.

لكن العكس أيضًا صحيح: لا ينبغي تحويل CoffeeCam إلى اختراع أعظم مما كان عليه تقنيًا. فهو لم يخترع HTTP، ولا HTML، ولا الكاميرات الرقمية، ولا streaming video، ولا الشبكات الحاسوبية. قوته كانت في دمج مكونات تقنية موجودة وإعطائها نموذج استخدام جديدًا، ثم الاستمرار في نفس الفكرة عبر VNC والواجهات التفاعلية والأنظمة العميلية. CST Cambridge

وهذا نوع حقيقي ومهم من البرمجة: systems integration as invention.

16. وأهميته في مسردك

إذا كانت Ada Lovelace عندك تمثل البرنامج قبل الحاسوب، وBabbage يمثل آلة الحساب القابلة للبرمجة، وStrachey يمثل لغة البرمجة، وNeedham يمثل النظام الموزع الآمن، وBerners-Lee يمثل الويب، فإن Stafford-Fraser يمثل شيئًا مختلفًا:

الحاسوب الذي يصبح نافذة على العالم الفيزيائي، ثم نافذة على حاسوب آخر.

من Coffee Pot إلى VNC، هناك خط واحد:

Observe ⇨ transmit ⇨ display ⇨ interact.

وهذا يجعل Q في قائمتك حرفًا له شخصية تقنية واضحة جدًا، لا مجرد اسم جرى اختياره لأن شهرته مرتبطة بكلمة “webcam”.

أهم الأعمال والمنشورات

1. XCoffee / Trojan Room Coffee Pot — 1991
العمل الذي ارتبط به تاريخيًا: برنامج لعرض صورة ماكينة القهوة على محطات العمل، ثم تطور النظام ليصبح متاحًا عبر الويب. كامبردج

2. Brightboard: A Video-Augmented Environment — 1996
عمل أساسي في الواجهات التفاعلية المعتمدة على الفيديو، وامتداد لأطروحته Video Augmented Environments. كامبردج

3. Virtual Network Computing — 1998
من أهم أعماله البرمجية؛ نظام يجعل واجهة الحاسوب قابلة للوصول والتفاعل عبر الشبكة. وتدرج كامبريدج وIEEE أعماله المرتبطة بـ VNC ضمن منشوراته. CST Cambridge

4. The Life and Times of the First Web Cam — 2001
مقاله في Communications of the ACM، وهو المصدر الشخصي/التاريخي الأهم لفهم قصة CoffeeCam من منظور أحد المشاركين فيها. CST Cambridge

5. Integrating Synchronous and Asynchronous Collaboration with Virtual Network Computing — 2000
بحث يوسع VNC نحو التعاون والعمل الجماعي. CST Cambridge

6. Applications of Stateless Client Systems in Collaborative Enterprises — 1999
عمل مهم لفهم اهتمامه بفصل العرض عن منطق التطبيق وبناء الأنظمة العميلية الرقيقة. كامبردج

الخلاصة: Quentin Stafford-Fraser ليس “رجل الكاميرا التي صورت القهوة” فحسب؛ بل هو مبرمج حوّل المسافة إلى مشكلة برمجية قابلة للحل. بدأ بعرض جسم مادي بعيد، ثم انتقل إلى عرض حاسوب بعيد والتحكم فيه، ثم إلى الواجهات المرئية والتعاون الشبكي والأنظمة العميلية. لذلك فإن أفضل وصف لدوره في تاريخ البرمجة هو: مهندس الأنظمة التفاعلية الموزعة التي تجعل الشيء البعيد حاضرًا على شاشة المستخدم. CST Cambridge

Richard Bartle

R — Richard Bartle

Richard Bartle حالة مهمة جدًا في قائمتك، وربما من أكثر الأسماء التي يتغير معناها إذا نظرنا إليها من زاوية البرمجة بدل زاوية “تصميم الألعاب”. فشهرة Bartle الحديثة ترتبط بنظرية أنماط اللاعبين وبكتابه Designing Virtual Worlds، لكن الأصل الحقيقي لمكانته هو أنه مع Roy Trubshaw شارك في بناء MUD1 عام 1978، أحد الأسس المباشرة لعالم الألعاب متعددة المستخدمين والـMMORPGs اللاحقة. جامعة Essex نفسها تصفه بأنه شارك في كتابة أول virtual world، وتذكر أن نموذج أنواع اللاعبين الذي نشره عام 1996 أصبح واسع الاستخدام في صناعة الـMMO. جامعة إسكس

1. قبل أن يصبح “مصمم ألعاب”

ولد Bartle عام 1960، ودرس علوم الحاسوب في جامعة Essex، وهناك التقى Roy Trubshaw. وفي 1978، وهما طالبان، بدأ الاثنان بناء MUD على جهاز DEC PDP-10. حصل Bartle لاحقًا على الدكتوراه في الذكاء الاصطناعي من Essex عام 1988. جامعة إسكس

لكن أهمية اللحظة لا تكمن في أن شابين بنيا لعبة نصية. كانت ألعاب الحاسوب متعددة المستخدمين موجودة قبل MUD، ولذلك من الأفضل تجنب العبارة المبسطة “أول لعبة متعددة المستخدمين”. ما كان جديدًا هو العالم المشترك المستمر الذي يستطيع عدد من اللاعبين دخوله والتفاعل داخله عبر الشبكة. حتى تاريخ MUD نفسه يوضح أن وصفه كأقدم “multi-user game” سيكون غير دقيق، بينما يبقى وصفه كأقدم virtual world أكثر دقة. Mud1

2. MUD كان برنامجًا قبل أن يكون نوعًا أدبيًا

MUD1 لم يكن مجرد نصوص متصلة ببعضها مثل adventure game تقليدية. كان هناك حالة عالم state، ومواقع، وأشياء، ولاعبون، وأفعال، وقواعد، وصلاحيات، واقتصاد داخلي للموارد، ونظام يحافظ على استمرار العالم بينما يدخل ويخرج اللاعبون.

وهنا تحديدًا تظهر براعة Bartle البرمجية: لقد ساعد في الانتقال من نموذج:

برنامج ⇨ لاعب ⇨ نهاية اللعبة

إلى:

برنامج ⇨ عالم مستمر ⇨ عدة لاعبين ⇨ حالة مشتركة ⇨ تفاعلات غير محدودة مسبقًا.

وهذه نقلة في معمارية البرنامج قبل أن تكون نقلة في تصميم الألعاب.

3. دور Roy Trubshaw ودور Bartle

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

وهذا يجعل Bartle مثالًا ممتازًا لنوع من البرمجة لا يختزل في كتابة النواة التنفيذية: برمجة العالم نفسه.

4. من الكود إلى World Model

يمكن النظر إلى مساهمته في MUD باعتبارها بناء نموذج حاسوبي لعالم قابل للحياة.

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

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

وهذا هو السبب في أن MUD يمثل مرحلة مهمة جدًا في تاريخ simulation programming.

5. البرمجة هنا تصبح اجتماعًا

وهذه ربما أعظم فكرة ضمنية في MUD.

في البرامج التقليدية، المستخدم يتفاعل مع البرنامج.

في MUD، المستخدم يتفاعل مع البرنامج واللاعبين الآخرين في الوقت نفسه.

وبالتالي تصبح البرمجة مسؤولة عن خلق فضاء ثالث:

User ↔ System ↔ User

ومن هنا يمكن تتبع خط تاريخي مباشر إلى MMORPG، ثم الشبكات الاجتماعية، ثم العوالم الافتراضية، ثم metaverse، وحتى بعض أشكال الألعاب الاجتماعية الحديثة.

لم يكن Bartle يبني “لعبة جماعية” فحسب؛ كان يبني بنية برمجية للعلاقات البشرية داخل فضاء اصطناعي.

6. BCPL والقيود التي صنعت التصميم

كان MUD مرتبطًا تاريخيًا بـ BCPL، وهي اللغة التي كانت تُستخدم على أنظمة Cambridge وEssex وغيرها في تلك الفترة، والتي سبقت C تاريخيًا. إعادة كتابة MUD في BCPL ساعدت على تقليل استهلاك الذاكرة وجعل صيانة البرنامج أسهل، وفق التاريخ المتاح للمشروع. ويكيبيديا

وهذا مهم لأن أجهزة تلك الفترة كانت شديدة المحدودية مقارنة بما نعده اليوم. لذلك فإن MUD ليس مشروعًا يمكن فهمه بمعايير Minecraft أو World of Warcraft.

إنه مشروع نشأ في بيئة يكون فيها كل byte تقريبًا جزءًا من التصميم.

والنتيجة أن كثيرًا من أفكار العالم جاءت من ضرورة بناء نظام صغير نسبيًا يستطيع تمثيل فضاء كبير ومفتوح.

7. MUD2: الانتقال من التجربة إلى النظام

بعد انتقال Trubshaw، واصل Bartle العمل على MUD، وشارك مع Trubshaw وSimon Dally في تأسيس Multi-User Entertainment Limited والعمل على MUD2، الذي ظهر عام 1985 وكان موجهًا للعمل كخدمة. ويكيبيديا

وهنا حدث التحول الأهم في مسيرته: لم يعد MUD مجرد تجربة جامعية. أصبح نموذجًا لما يمكن أن يسمى اليوم online service architecture.

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

وهذه فكرة ستصبح لاحقًا أساسية في EverQuest وUltima Online وWorld of Warcraft، ثم في الألعاب التي تُعامل كخدمات مستمرة.

8. الشيء الأهم: Bartle لم يصمم لعبة فقط، بل صمم “سلوكًا”

في عام 1996 نشر Bartle مقالته الشهيرة Hearts, Clubs, Diamonds, Spades: Players Who Suit MUDs.

ومن هنا جاءت تصنيفاته الأربع المعروفة:

• Achievers
• Explorers
• Socializers
• Killers

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

فالـExplorer لا يحتاج اللعبة نفسها التي يحتاجها Achiever، والـSocializer لا يبحث عن الشيء نفسه الذي يبحث عنه Killer.

وهنا يتحول Bartle من مبرمج للعالم إلى مبرمج العلاقة بين الإنسان والعالم.

9. وهذا يفسر لماذا استمر تأثيره

جامعة Essex تصف نموذج 1996 بأنه أصبح واسع الاستخدام في صناعة MMO. جامعة إسكس

لكن ينبغي عدم معاملته كنظرية نفسية نهائية عن البشر. هو في الأساس أداة تصميم نشأت من خبرة Bartle الطويلة مع MUDs، وليست تشخيصًا علميًا جامعًا لكل سلوك بشري.

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

10. Designing Virtual Worlds

ثم جاء العمل الذي يلخص مشروعه كله: Designing Virtual Worlds، المنشور أصلًا عام 2003.

الكتاب ضخم جدًا؛ الطبعة الأولى تقع في نحو 741 صفحة، ويتناول التاريخ والتكنولوجيا والاقتصاد والمجتمع وعلم النفس والأخلاق والعمارة والتفاعل وتصميم المحتوى والـMUDs والـMOOs والـMMORPGs. Google Books

وهنا يتحول Bartle من مبرمج ومصمم إلى منظّر كامل للوسط الذي أنشأه.

إنه لا يشرح كيف تكتب server فقط، بل يسأل:

ما الذي يجعل العالم عالمًا؟

كيف يتغير عندما يدخله آلاف البشر؟

ما العلاقة بين قواعده واقتصاده ومجتمعه؟

كيف تتغير هوية اللاعب داخله؟

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

11. الكتاب نفسه يثبت اتساع المشروع

اللافت في Designing Virtual Worlds أنه لا يتعامل مع العالم الافتراضي باعتباره “لعبة فيديو أكبر”.

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

وهذا يكشف شيئًا أساسيًا عن Bartle: هو يفكر في الـvirtual world كنظام اجتماعي-حاسوبي كامل.

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

12. وهناك تطور مهم جدًا في 2025

في 2025 ظهرت الطبعة الثانية من Designing Virtual Worlds، وأعيد تقسيم العمل إلى مجلدات. والنسخة الجديدة توسع المشروع التاريخي من MUDs الأولى حتى العوالم الافتراضية الحديثة. وتعرض CRC Press المجلد الأول بوصفه معالجة تمتد من الأسس التاريخية والتقنية إلى الجوانب الاجتماعية والنفسية والأخلاقية. راؤتلدج

وهذا مثير بالنسبة لمسردك لأن Bartle لم يصبح مجرد شخصية تاريخية من عصر MUD؛ ما زال يعيد صياغة نظريته بعد قرابة نصف قرن من التجربة.

13. Bartle والـMMORPG

من الصعب فهم تاريخ MMORPG دون المرور بـBartle، لكن يجب صياغة العلاقة بدقة.

لم يصنع World of Warcraft، ولم يخترع MMORPG الحديث، ولم يكن MUD وحده سبب ظهوره. بل كان MUD واحدًا من السلالات البرمجية والفكرية التي تطور منها هذا النوع.

لكن MUD قدّم مبكرًا عناصر أصبحت مركزية لاحقًا:

persistent world + multiple users + text commands + player interaction + economy + progression + shared state.

ولهذا يمكن النظر إلى Bartle باعتباره أحد الأسلاف البرمجيين المباشرين للـMMO.

14. المدهش أن البرمجة عنده أصبحت “تصميم قوانين”

وهذه في رأيي أفضل طريقة لإدراجه في قائمتك.

المبرمج التقليدي يكتب:

ما الذي يجب أن يفعله البرنامج؟

أما Bartle فيضيف:

ما القواعد التي إذا نفذها البرنامج نشأ عالم كامل من التفاعلات؟

هذه نقلة من instruction programming إلى rule-system programming.

أنت لا تكتب كل حدث؛ تكتب القوانين التي تسمح للأحداث بالحدوث.

وهذه الفكرة قريبة جدًا من البرمجة المحاكياتية، والأنظمة القائمة على الحالات، والـagent systems، وحتى بعض طرق التفكير في الذكاء الاصطناعي والألعاب الاجتماعية.

15. ولهذا يأتي R بعد Quentin Stafford-Fraser بشكل منطقي

هناك صلة جميلة جدًا بين الاسمين في قائمتك.

Stafford-Fraser عمل على جعل العالم البعيد حاضرًا على الشاشة.

Bartle عمل على جعل العالم الاصطناعي مكانًا يمكن للناس أن يعيشوا داخله معًا.

الأول يعالج:

Remote Presence

والثاني يعالج:

Virtual Presence

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

16. التقييم النهائي لمكانته كمبرمج

إذا قُيّم Bartle فقط بعدد الأسطر البرمجية أو عدد اللغات التي كتب بها، فلن يظهر في المكان الذي يستحقه.

أما إذا كان معيارنا هو ما الذي تغير في مفهوم البرنامج نتيجة عمله؟ فالقصة مختلفة تمامًا.

MUD جعل البرنامج قادرًا على تمثيل عالم مستمر متعدد المستخدمين، ثم جاء Bartle ليحول خبرة هذا النظام إلى نظرية في تصميم العوالم الافتراضية.

لذلك أضعه في قائمتك تحت:

Virtual World Programming / Multiplayer Systems / Game-World Architecture

وليس فقط “Game Designer”.

أهم الأعمال

1. MUD1 — 1978
العمل المؤسس في مسيرته: عالم افتراضي متعدد المستخدمين، شارك Bartle في تطويره مع Roy Trubshaw. أصبح الكود الأصلي التاريخي متاحًا لاحقًا للأرشفة والدراسة، كما أودع تنفيذ تاريخي منه في Stanford. Mud1

2. MUD2 — 1985
التطوير اللاحق لمشروع MUD وتحويله إلى نظام أكثر نضجًا كخدمة online world. ويكيبيديا

3. Hearts, Clubs, Diamonds, Spades: Players Who Suit MUDs — 1996
النص الذي قدم تصنيف Achievers / Explorers / Socializers / Killers، وأصبح أساسًا مؤثرًا في التفكير بتصميم MMO. جامعة إسكس

4. Designing Virtual Worlds — 2003
أهم مؤلفاته وأوسعها؛ موسوعة عملية ونظرية تقريبًا لبناء العوالم الافتراضية، من الـMUD إلى MMORPG. Google Books

5. Designing Virtual Worlds, 2nd ed. — 2025
إعادة صياغة موسعة للمشروع، والطبعة الجديدة بدأت بمجلد أول يعيد بناء تاريخ ونظرية تصميم العوالم الافتراضية من جذورها حتى الأشكال الحديثة. راؤتلدج

الخلاصة: Richard Bartle ليس مهمًا لأنه “اخترع الـMMORPG” بالمعنى المبسط، بل لأنه كان من أوائل المبرمجين الذين جعلوا البرنامج عالمًا مستمرًا يسكنه عدة أشخاص في الوقت نفسه. ثم أمضى العقود التالية في دراسة ما يحدث عندما يتحول الكود من أداة يستخدمها شخص إلى مكان يعيش فيه آلاف الأشخاص ويتفاعلون داخله. وهذه، بالنسبة لمسردك، مساهمته البرمجية الحقيقية.

Sophie Wilson

S — Sophie Wilson

إذا كان Richard Bartle يمثل في قائمتك برمجة العالم الافتراضي، فإن Sophie Wilson تمثل شيئًا يكاد يكون نقيضه: برمجة الآلة نفسها. وهي من أقوى الأسماء في قائمتك من حيث اتساع الأثر؛ لأن Wilson لم تكتفِ بكتابة برامج تعمل على المعالج، بل صممت اللغة التي يتحدث بها المعالج، والبرمجيات التي تعمل عليه، ثم ساهمت في تصميم المعالج نفسه. ولهذا فإن وصفها بأنها “مبرمجة ARM” فقط يقلل من طبيعة إنجازها؛ فهي تقع عند الحد الفاصل بين software engineering وcomputer architecture وinstruction-set design.

Sophie Wilson حصلت على تعليمها في علوم الحاسوب بجامعة كامبريدج، وبدأت مسيرتها في Acorn Computers. وتوثق Computer History Museum أنها صممت Acorn System 1، ثم شاركت Steve Furber في تصميم BBC Micro، قبل أن يشتركا في تصميم ARM عام 1985. CHM

1. المبرمجة التي بدأت من الأسفل جدًا

من المثير أن مسار Wilson لم يبدأ من “برمجة التطبيقات”. ففي فترة مبكرة من حياتها الجامعية طورت نظامًا آليًا لتغذية الأبقار، ثم انتقلت إلى تصميم Acorn System 1. وتذكر BCS أنها كانت قد بدأت بناء المعالجات الدقيقة في سن مبكرة، وأنها كتبت نظام تشغيل Acorn System 1 حتى مستوى البرمجة الثنائية قبل أن تطور assembler وMOS وBASIC. BCS

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

وهذا خط نادر جدًا حتى بين المبرمجين الكبار.

2. Acorn System 1

كان Acorn System 1 أحد أوائل الحواسيب البريطانية الصغيرة، وقد صممته Wilson في مرحلة مبكرة من عملها. وكان مبنيًا حول معالج MOS 6502، وهو معالج سيصبح مهمًا جدًا في تاريخ الحواسيب الشخصية.

لكن قيمة Wilson هنا ليست فقط أنها ساعدت في “تصميم كمبيوتر”. هي بنت الطبقات البرمجية التي تجعل العتاد قابلًا للاستخدام.

فالكمبيوتر من دون software stack ليس منتجًا حاسوبيًا بالمعنى العملي. Wilson اشتغلت على:

Hardware → Operating System → Assembler → BASIC

أي أنها كانت تتحكم في السلسلة كاملة تقريبًا.

وهذه السمة ستظهر مرة أخرى بصورة أكثر ضخامة في BBC Micro ثم ARM.

3. BBC Micro: هنا تصبح مبرمجة جماهيرية

في 1981 طورت Wilson نسخة أكثر تقدمًا من BASIC المستخدمة في Acorn، وأصبح المشروع الذي كان يسمى Proton أساسًا لـ BBC Micro بعد أن اختارته BBC لمشروع Computer Literacy Project. مركز تاريخ الحوسبة

وتذكر Computer History Museum أن Wilson وSteve Furber صمما النموذج الأولي لـBBC Micro في أقل من أسبوع، ثم أمضيا الصيف في تحسين التصميم؛ Wilson صممت نظام التشغيل وكتبت BBC BASIC interpreter. CHM

وهنا حدث شيء تاريخي مهم: برمجتها لم تبق داخل مختبر هندسي؛ دخلت آلاف المدارس البريطانية.

تبيع Acorn في النهاية أكثر من مليون BBC Micro، واستخدم الجهاز في آلاف المدارس البريطانية خلال العقد التالي. CHM

4. BBC BASIC ليست مجرد لغة تعليمية

من السهل أن ننظر إلى BBC BASIC اليوم باعتبارها “لغة BASIC قديمة”، لكن ذلك يخفي مستوى التصميم البرمجي الذي كانت تمثله.

Wilson لم تكن تكتب interpreter بسيطًا لكي يتمكن الطفل من تنفيذ:

10 PRINT "HELLO"

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

وتشير BCS إلى أنها استمرت في تصميم وتنفيذ إصدارات BBC BASIC من 1 إلى 6 لمعالجات مختلفة، منها 6502 وNS32016 وARM. BCS

وهذه نقطة مهمة جدًا: BBC BASIC نفسها كانت منصة عابرة للأجيال المعمارية.

5. ثم حدث التحول الكبير: ARM

بعد BBC Micro واجهت Acorn مشكلة جوهرية: المعالجات المتاحة في السوق لم تكن تمنحها مزيج الأداء والكفاءة الذي تريده للجيل التالي من الحواسيب.

وهنا بدأت قصة ARM.

في 1983 تقريبًا بدأت Wilson العمل على instruction set لمعالج RISC جديد، ثم شاركت مع Furber في تصميم المعالج الذي أصبح ARM1. وتوثق Computer History Museum أن ARM1 صُمم عام 1985 بواسطة Wilson وFurber، وأنه أصبح أساسًا لعائلة ARM. CHM

وهنا يجب التوقف عند كلمة instruction set.

لأن هذه هي المنطقة التي تجعل Wilson مبرمجة بمعنى عميق جدًا.

6. تصميم instruction set هو تصميم لغة

يمكن تشبيه مجموعة تعليمات المعالج بلغة برمجة شديدة الانخفاض المستوى.

فالمعالج يفهم:

ADD، SUB، LOAD، STORE، BRANCH…

لكن طريقة تنظيم هذه العمليات، وعدد السجلات، وطريقة الوصول إلى الذاكرة، والـflags، والـbranching، وحجم التعليمات، كلها تحدد ما الذي يستطيع البرنامج فعله وبأي تكلفة.

وهنا صممت Wilson instruction set ARM.

IEEE Spectrum يذكر تحديدًا أن Wilson هي التي صممت instruction set، وأن فلسفة التصميم ركزت على البساطة؛ وكان ARM صغيرًا ومنخفض الاستهلاك وسهل البرمجة. IEEE Spectrum

لذلك فإن ARM في جزء منه تصميم لغة برمجية للآلة.

وهذا يجعل صلة Wilson بـPaul Graham في قائمتك مثيرة جدًا:

• Graham: يعيد تشكيل اللغة لكي يصبح البرنامج أكثر تعبيرًا.
• Wilson: تصمم لغة الآلة لكي يصبح البرنامج أكثر كفاءة.

كلاهما يعمل على اللغة كأداة هندسية، لكن أحدهما في أعلى stack والآخر في أسفله تقريبًا.

7. العبقرية لم تكن في زيادة التعقيد

الجانب الأكثر أهمية في ARM هو أن Wilson وفريق Acorn لم يحاولوا بناء معالج أكثر تعقيدًا من منافسيهم.

بل العكس.

كان الرهان هو أن البساطة يمكن أن تنتج أداءً ممتازًا.

تقول Wilson في تاريخها الشفهي لدى Computer History Museum إن الفريق توقع أن يصطدم بعوائق كبيرة، ولذلك وضع قدرًا كبيرًا من الجهد في verification وmodeling مبكرًا، ثم اكتشف أن عملية التصميم نفسها كانت أسهل مما توقع. أرشيف تاريخ الحاسوب

وهذه النقطة تكشف فلسفة هندسية مهمة:

لا تضف التعقيد إلا إذا كان العائد يستحقه.

وهذه الفلسفة ستصبح لاحقًا واحدة من أسرار نجاح ARM.

8. المحاكاة قبل السيليكون

من أكثر التفاصيل إثارة في قصة ARM أن Wilson كتبت محاكاة لمجموعة تعليمات المعالج في BBC BASIC قبل وجود المعالج فعليًا.

وتشير المصادر التاريخية إلى أن هذه المحاكاة عملت على BBC Micro مزودًا بمعالج 6502 ثانٍ، واستخدمتها Wilson للتحقق من أن تصميم instruction set يسير في الاتجاه الصحيح. ويكيبيديا

وهنا نرى شيئًا شديد الحداثة بالنسبة إلى عصره:

Software ⇨ simulates future hardware ⇨ validates architecture ⇨ hardware is built later.

أي أنها لم تنتظر تصنيع الشريحة لكي تعرف إن كانت فكرتها جيدة.

لقد استخدمت البرمجة كأداة لتصميم المعالج.

وهذه ربما واحدة من أهم النقاط التي تجعلها مناسبة جدًا لمسرد “المبرمجين”.

9. لحظة ARM1

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

تشير IEEE إلى أن أول اختبار شغّل البرنامج:

PRINT PI

وظهرت النتيجة الصحيحة، ثم احتفل الفريق بالنجاح. IEEE Spectrum

هذه اللقطة جميلة تاريخيًا لأنها تختزل علاقة البرمجيات بالعتاد:

كل تلك الأشهر من architecture وlogic وverification وlayout انتهت في النهاية إلى سؤال صغير جدًا:

هل ينفذ المعالج برنامجًا حقيقيًا كما ينبغي؟

والإجابة كانت نعم.

10. Archimedes

ظهر ARM لاحقًا في Acorn Archimedes، أول عائلة حواسيب عامة تعتمد هذه المعمارية من Acorn. ثم انتقلت ARM إلى منتجات خارج منظومة Acorn نفسها، ومنها Newton من Apple. CHM

وهنا حدث التحول من “معالج حاسوب بريطاني” إلى architecture قابلة للترخيص وإعادة الاستخدام.

لم تعد Wilson تصمم جهازًا واحدًا.

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

وهذه خطوة أكبر بكثير من تصميم microcomputer منفرد.

11. لماذا ARM أهم من BBC Micro في تقييم Wilson؟

BBC Micro كان نجاحًا تقنيًا وتعليميًا هائلًا، لكن ARM أحدث تغييرًا بنيويًا في صناعة الحوسبة.

فالمعمارية أصبحت أساسًا لعدد هائل من الأجهزة. وتصف Royal Society ARM بأنها معمارية موجودة في أكثر من نصف الإلكترونيات الاستهلاكية في العالم، بينما تشير EPO إلى أن عدد شرائح ARM المباعة تجاوز 200 مليار وفق بياناتها. Royal Society

والأرقام التاريخية تتغير مع الزمن، لكن المبدأ لا يتغير:

Wilson ساهمت في تصميم بنية معالج أصبحت طبقة تحتية للحوسبة الحديثة.

الهاتف، الجهاز اللوحي، الأنظمة المضمنة، الأجهزة المنزلية، السيارات، وغيرها؛ كلها استفادت من سلالة ARM.

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

12. ARM والبرمجة

هناك مفارقة عميقة هنا.

المستخدم العادي يرى ARM كـ“hardware”.

لكن ARM في الحقيقة يحدد جزءًا من اللغة التي تُترجم إليها البرامج.

المترجم Compiler يأخذ:

C / C++ / Rust / Swift…

ويحولها إلى تعليمات ARM.

وبالتالي فإن قرار Wilson بشأن instruction set يؤثر بصورة غير مباشرة على:

• compiler design
• operating systems
• calling conventions
• optimization
• embedded software
• performance
• energy consumption

أي أن تصميمها للمعالج أصبح قيودًا وإمكانات يعيش داخلها ملايين المبرمجين.

وهذه إحدى أعلى درجات التأثير التي يمكن أن يبلغها مبرمج: أن تجعل قراراتك المعمارية جزءًا من البيئة التي يبرمج فيها الآخرون.

13. ARM3 وARM610 وARM700 وغيرها

لم تتوقف Wilson عند ARM1.

تذكر BCS أنها شاركت في تصميم ARM3 وARM610 وARM700 وARM7500FE، كما صممت منفردة نظام تشغيل للمعالج الثاني ARM، واستمرت في تطوير طبقات البرمجيات والمعمارية. BCS

وهذا مهم لأنه يمنع تحويل قصتها إلى “صممت ARM ثم انتهى الأمر”.

هي كانت تعمل عبر الطبقات:

ISA → CPU → OS → compiler/programming environment → applications

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

14. Acorn Replay والوسائط

في 1990 صممت Wilson Acorn Replay، وهو نظام برمجي للوسائط المتعددة سمح بتشغيل الفيديو على أجهزة منخفضة القدرة نسبيًا. وتذكر BCS وIET أن النظام كان قادرًا على تحقيق تشغيل فيديو بكفاءة عالية على عتاد محدود، وأنه كان منافسًا تقنيًا مثيرًا للاهتمام لحلول مثل QuickTime. BCS

وهذا يكشف جانبًا آخر من فلسفتها:

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

وهذه الفكرة تتطابق تمامًا مع فلسفة ARM نفسها.

15. Firepath

لاحقًا شاركت Wilson في تطوير Firepath، وهي معمارية معالج VLIW/SIMD موجهة إلى تطبيقات مثل ADSL. وأسست مع فريقها Element 14 لاستغلال هذه التقنية، ثم استحوذت Broadcom على الشركة. وتذكر University of York أنها قادت تصميم instruction set لـFirepath وكتبت Architecture Guide وقادت أعمال SoC. جامعة يورك

وهذا الجزء من مسيرتها مهم لأنه يثبت أن ARM لم تكن “ضربة حظ تاريخية”.

حتى بعد ARM، استمرت في السؤال نفسه:

كيف نصمم بنية حوسبية تحقق أكبر قدر من العمل بأقل تكلفة طاقية وتعقيدية ممكنة؟

16. Wilson كحلقة بين البرمجيات والعتاد

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

Ada Lovelace كانت تفكر في البرنامج قبل وجود الحاسوب العملي.

Babbage كان يفكر في آلة يمكنها تنفيذ البرنامج.

Strachey اشتغل على لغات البرمجة والـsemantics.

Paul Graham جعل اللغة نفسها أداة لصنع لغات وبرامج جديدة.

لكن Wilson تفعل شيئًا مختلفًا:

هي تجعل تصميم البرنامج وتصميم الآلة عمليتين متداخلتين.

وهذا هو معنى hardware/software co-design قبل أن يصبح المصطلح واسع الانتشار.

17. ولماذا هي “مبرمجة” بامتياز؟

لأن مساهمتها لا تتوقف عند RTL أو transistor design.

لقد كتبت:

• أنظمة تشغيل؛
• assemblers؛
• interpreters؛
• محاكيات instruction sets؛
• برمجيات multimedia؛
• وأدلة معمارية؛

وفي الوقت نفسه صممت instruction sets ومعماريات معالجات.

BCS توثق تحديدًا انتقالها من البرمجة الثنائية إلى assembler وMOS وBASIC، ثم BBC BASIC، ثم محاكاة ARM ودعم المعمارية برمجيًا. BCS

إذن البرمجة هي إحدى مواد تصميمها الأساسية، لا مجرد وسيلة ثانوية لخدمة الهندسة الإلكترونية.

18. مكانتها في قائمتك

Sophie Wilson، في رأيي من ناحية النوع البرمجي الذي تمثله، من أهم التحولات في قائمتك حتى الآن.

هي تمثل:

Computer Architecture Programming

أو بصورة أدق:

Instruction-Set & Systems Programming

لأنها تقع في المكان الذي تتوقف فيه البرمجيات عن كونها شيئًا “يعمل على الحاسوب”، وتصبح شيئًا يحدد ما هو الحاسوب نفسه.

وهذا يجعلها امتدادًا مثاليًا لسلسلة الأسماء السابقة:

Bartle: برمجة عالم افتراضي.
Stafford-Fraser: برمجة الحضور عن بُعد.
Wilson: برمجة الآلة التي تجعل كل ذلك ممكنًا بكفاءة.

أهم الأعمال والمشروعات

1. Acorn System 1 — أحد أوائل تصاميمها للحاسوب الصغير، مع نظام التشغيل والبرمجيات الأساسية. CHM

2. BBC Micro / BBC BASIC — مشروعها البرمجي الأشهر قبل ARM؛ صممت نظام التشغيل وكتبت interpreter لـBBC BASIC وطورت إصدارات متعددة منه. CHM

3. ARM Instruction Set — ربما أهم عمل لها على الإطلاق؛ التصميم المعماري الذي سبق بناء ARM1، واختبرته برمجيًا قبل وجود الشريحة. ويكيبيديا

4. ARM1 — 1985 — أول تنفيذ للمعمارية التي صممتها مع Steve Furber، وأصل سلسلة ARM. CHM

5. ARM3 / ARM610 / ARM700 / ARM7500FE — سلسلة من المعالجات والمعماريات التي شاركت Wilson في تصميمها. BCS

6. Acorn Replay — 1990 — نظام multimedia برمجي عالي الكفاءة للعتاد محدود الموارد. IET

7. Firepath — معمارية VLIW/SIMD لاحقة، قادت Wilson تصميم instruction set لها ضمن Element 14. جامعة يورك

الخلاصة

Sophie Wilson ليست فقط مبرمجة BBC BASIC، وليست فقط مهندسة ARM. أهم ما يميزها أنها أزالت الحد الفاصل بين “المبرمج” و”مصمم الحاسوب”.

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

ولهذا فإن S في مسردك تمثل مرحلة شديدة العمق من تاريخ البرمجة:

البرنامج لم يعد مجرد شيء يعمل على الآلة؛ البرنامج أصبح أداة لتصميم الآلة نفسها. CHM

Turing

T — Alan Turing

Alan Turing ليس مجرد اسم مناسب لحرف T؛ بل هو أحد الأسماء التي تجعل كلمة programmer نفسها قابلة لإعادة التعريف. فقبل Turing لم تكن هناك بعد مهنة مستقلة ومستقرة اسمها “مبرمج حاسوب” بالمعنى الحديث. ومع ذلك، نجد في عمله تقريبًا كل طبقات الفكرة التي ستصبح لاحقًا جوهر البرمجة: الخوارزمية، الآلة العامة، البرنامج المخزن، المترجم، المحاكاة، الذكاء الاصطناعي، الحوسبة الرمزية، والبرمجة الآلية.

Alan Turing كان رياضيًا بالأساس، لكن أثره البرمجي يتجاوز بكثير حدود الرياضيات النظرية. وإذا كانت Ada Lovelace عندك تمثل فكرة البرنامج قبل الحاسوب الإلكتروني، فإن Turing يمثل اللحظة التي أصبحت فيها فكرة البرنامج نموذجًا رياضيًا عامًا لما يمكن للحاسوب أن يفعله.

1. آلة تورنغ: البرنامج قبل أن يكون برنامجًا

في 1936 نشر Turing بحثه الشهير:

On Computable Numbers, with an Application to the Entscheidungsproblem.

وهنا قدم ما أصبح يعرف بـ Turing Machine.

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

أي:

Input ⇨ State ⇨ Rule ⇨ Action ⇨ New State

هذه البنية البسيطة للغاية تكفي من حيث المبدأ لتمثيل عدد هائل من العمليات الحسابية.

2. Universal Machine

لكن أعظم فكرة في الورقة لم تكن مجرد آلة تورنغ العادية، بل Universal Turing Machine.

وهنا تحدث القفزة الحقيقية.

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

أي:

Program + Data ⇨ Universal Machine ⇨ Result

وهذه إحدى أعمق جذور الحاسوب الحديث.

فالحاسوب العام لا يحتاج إلى إعادة بناء دوائره كي ينتقل من لعبة إلى محرر نصوص إلى متصفح إلى نظام ذكاء اصطناعي؛ بل يكفي تغيير البرنامج.

ولهذا فإن Turing لم يصف فقط “آلة للحساب”، وإنما ساعد في صياغة مفهوم الآلة القابلة للبرمجة عمومًا.

3. الفرق بين Turing وBabbage

وهنا تظهر صلة مباشرة جدًا بحرف B عندك.

Babbage تصور Analytical Engine كآلة عامة تحتوي على Store وMill وتحكم بالبطاقات.

Turing جاء بعد قرن تقريبًا وصاغ المسألة بصورة رياضية أكثر تجريدًا.

لكن هناك فرق مهم:

Babbage: كيف يمكن بناء آلة عامة؟

Turing: ما معنى أن تكون العملية قابلة للحساب أصلًا؟

ومن هنا انتقل مفهوم الحوسبة من الهندسة الميكانيكية إلى نظرية الحساب.

ولهذا فإن وجود Babbage ثم Turing في المسرد ليس تكرارًا إطلاقًا؛ إنهما يمثلان طرفين من السلسلة نفسها:

Programmable Machine ⇨ Mathematical Computability

4. Turing لم يكن مجرد منظّر

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

Turing انتقل من النموذج الرياضي إلى الآلة الفعلية.

خلال الحرب العالمية الثانية عمل في Bletchley Park، وساهم في تطوير أساليب وآلات لفك تشفير الاتصالات الألمانية، خصوصًا المتعلقة بـEnigma. وتصف Bletchley Park دوره في Hut 8 وفي تطوير Bombe.

وهنا أصبح السؤال:

كيف نحول الخوارزمية إلى عملية آلية تعمل آلاف المرات دون تدخل بشري؟

وهذا سؤال برمجي بامتياز.

5. Bombe: البرمجة كبحث آلي

الـBombe لم تكن حاسوبًا عامًا بالمعنى الحديث، ولذلك من الخطأ وصفها بأنها “أول كمبيوتر”. كانت آلة متخصصة في البحث عن إعدادات Enigma المحتملة.

لكن من منظور تاريخ البرمجة، أهميتها ضخمة لأنها تجسد:

Human cryptanalytic insight + formalized procedure + machine search

أي أن الإنسان يكتشف البنية، ثم تقوم الآلة بتنفيذ مساحة هائلة من الاحتمالات.

وهذا نموذج سيصبح لاحقًا جوهرًا في:

• brute-force search
• constraint solving
• automated theorem proving
• optimization
• AI search

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