مجلة حكمة
علوم الحاسب الآلي الحاسب الالي

فلسفة علوم الحاسب الآلي – موسوعة ستانفورد للفلسفة / ترجمة: مالك آل فتيل

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



تهتم فلسفة علوم الحاسب الآلي بالقضايا الأنطولوجية (الوجودية) والمنهجية الناشئة عن تخصص علوم الحاسب الآلي الأكاديمي، ومن ممارسة تطوير البرامج وتفعيلها تجاريًّا وصناعيًّا. وبمعنى أكثر تحديدًا، تدرس فلسفة علوم الحاسب الآلي النظمَ الحسابية أنطولوجيًّا وابستمولوجيًّا، مع التركيز على المسائل المرتبطة بمواصفاتها وبرمجتها وتنفيذها والتحقق منها واختبارها. تؤكد الطبيعة المعقدة لبرامج الحاسب الآلي صلة العديد من الأسئلة المفاهيمية التي أثارتها فلسفة علوم الحاسب الآلي بفلسفة الرياضيات وفلسفة العلوم التجريبية وبـ فلسفة التقنية. سوف نستعرض في الأقسام الخمسة الأولى تحليلاً لهذه الموضوعات، التي تعكس الطبيعة الطبقية لأنطولوجيا النظم الحسابية؛ ثم في الأقسام اللاحقة سنناقش الموضوعات المتعلقة بمنهجيتها.

جدول المحتويات


1- النظم الحسابية في الحاسب الآلي

تتغلغل النظم الحسابية في أدق تفاصيل حياتنا اليومية. يهدف تخصص علوم الحاسب الآلي إلى دراسة تصميمها وتطويرها وتحليلها. أما فلسفة علوم الحاسب الآلي فتتعامل مع هذه النظم على أنها مادة للتحليل النظري. ينصب هدفها الرئيس على تعريف هذه النظم، أي تطوير أنطولوجيا للنظم الحسابية. تطرح أدبيات هذا المجال نهجين رئيسيين حول هذا الموضوع: الأول يفهم النظم الحسابية من خلال التمييز الأنطولوجي (الوجودي) بين البرامج (Software) والأجهزة (Hardware)، والتي تعتبر عادةً كمكونات أولية لهذه النظم. بينما يرى نهج آخر أن النظم الحسابية تشتمل على العديد من العناصر الأخرى متجاوزةً بذلك ثنائية البرامج والأجهزة، في ظل هذا المنظور، تعرَّف النظم الحسابية كمستويات مجردة متسلسلة هرميًا، بحيث تحتل الأجهزة المستويات الدنيا من هذا التسلسل، ثم يتوسع التسلسل إلى أعلى حيث عناصر التصميم، وإلى أسفل لتضم المستخدم. لنستعرض فيما يلي هذين النهجين.

1-1 البرامج وأجهزة الحاسب الآلي

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

يرى مور (1978) بأن هذه الثنائية (البرامج والأجهزة) هي واحدة من الأساطير الثلاثة في علوم الحاسب الآلي، ورغم تأكيده على المنفعة العلمية لهذا التقسيم، إلا أنه لا يراه ذا مغزى وجوديًّا. فبرامج الحاسب الآلي يمكن دراستها باعتبارها مجموعة من التعليمات التي قد ينفذها الحاسب، هذا على المستوى الرمزي، أي كتعليمات مشفرة، أما على المستوى المادي فتدرس كمجموعة من التعليمات المخزنة في وسيط مادي. يشدِّد مور على أنه ليس يوجد برنامجًا موجود ككيان مجرد بشكل محض؛ أي بدون وجود مادي (محرك أقراص محمول أو قرص ثابت على الخادم أو حتى قطعة من الورق). حتى أن البرامج المبكرة كانت تربط سلكيَّاً بشكل مباشر بالأجهزة. وفي بداياتها، كانت تتكون من مجموعات من الروافع المادية فقط. في ثنائية البرامج والأجهزة، عادةً ما يميِّز الدارس بين المستوى الرمزي للبرامج وبين المستوى المادي المقابل للأجهزة. ومع ذلك، فإن هذا التمييز يمكن تبريره بشكل عملي فقط لأنه يحدد المهام المختلفة للمطورين. بالنسبة لهم، البرامج تتشكل من الخوارزميات وكود المصدر الذي ينفذها، بينما الأجهزة تتكون من كود الآلة والمعالجات الدقيقة القادرة على تنفيذ ذاك الكود. على النقيض، قد يميل المهندسون الذين لديهم معرفة بالدوائر الإلكترونية المتصلة سلكيًّا بأجهزة الحاسب الآلي إلى النظر إلى البرامج على أنها مكونات مادية أيضًا. بمعنى آخر، ما يعتبر برنامجًا لأحد الممتهنِين يمكن أن يعتبر جهازًا لشخص آخر.

يذهب سوبير (1988) إلى أبعد من ذلك، حيث يؤكد على أن الأجهزة ما هي إلا نوع من أنواع البرامج. فيعرَّف البرامج على أنها أي نموذج قابل لأن ينصاع لأوامر القراءة والتشغيل: بمجرد أن يدرك المرء أن المكونات المادية ما هي إلا نماذج، سيقبل باستنتاج أن الأجهزة، وهي الكائنات مادية، هي أيضًا برامج. يعرّف سوبير النموذج بأنه “بنية محددة، لا بالمعنى الضيق الذي يتطلب التكرار أو الانتظام أو التناظر” (1988، 90) ويؤكد بأن أي بنية من هذا القبيل يمكن لها أن تكون قابلة للقراءة وللتنفيذ: لأي نموذج محدد دون ارتباطه بمعنىً ما، من الممكن دائمًا تصور بناء جملة ودلالات ذات معنى، وبالتالي جعل النموذج برنامجًا قابلاً للتنفيذ.

يؤكد كولبرن (1999، 2000 Colburn)، رغم تمسكه بفكرة التمييز بين البرامج والأجهزة، أن البرامج لها طبيعة مزدوجة، فهي “تجريد ملموس” فيمكن اعتبارها مجرّدةً وملموسةً في الوقت نفسه. لتعريف البرنامج، يحتاج المرء إلى الرجوع إلى وسيطين: “وسيط الوصف”، وهي اللغة المستخدمة للتعبير عن الخوارزمية، و “وسيط التشغيل”، وهي الدوائر الإلكترونية التي تتكون منها الأجهزة. ولأن البرامج دائمًا ما تكون ملموسة، إذ لا وجود لبرنامج بدون تجسيد مادي له في الوسائط المادية، إلا أنها مع ذلك مجردة، لأن المبرمجين لا يأخذون في حسبانهم الآلات المنفذة للبرامج، فهم يفضلون تطوير البرامج القابلة للتنفيذ بواسطة أي جهاز. يسمي كولبرن (1999 Colburn) هذا المفهوم بمصطلح “توسيع المحتوى” وهو يعرِّف التجريد في علوم الحاسب الآلي بأنه “تجريد للمحتوى”: يتم توسيع المحتوى بدلاً من حذفه، تمامًا كما يحدث مع التجريد الرياضي Mathematical Abstraction.

ينتقد إرماك (2012 Irmak) فكرة الطبيعة الثنائية للبرامج التي اقترحها كولبرن (1999، 2000 Colburn).  إذ يرى أن الكيانات المجردة تفتقر إلى الخصائص المكانية والزمانية التي يمتلكها الملموس. وبالتالي، فإن تعريف البرامج على أنها “تجريد ملموس” يعني ضمناً أن تكون للبرامج خصائص متناقضة. كما أنه يرى أن للبرامج خصائص زمنية: لكونها كيانات صنعها الإنسان فهي تبدأ وجوديًّا في وقت ما، وهو وقت تصورها وتنفيذها؛ ويمكن أن تزول عن الوجود في وقت لاحق معين. تزول البرامج عن الوجود عندما تتلف جميع النسخ، ويموت مؤلفوها ولا يتذكر أي شخص آخر خوارزمياتها. ولأنها كيانات أوجدها الإنسان، فإن البرامج تعد كيانات اصطناعية Artifact. ورغم افتقار البرامج إلى الخصائص المكانية؛ إذ لا يمكن تحديدها بأي إدراك ملموس، فهذا لا يعني أن إتلاف جميع النسخ المادية لبرنامج ما أنه ما عاد في الوجود، كما هو مذكور أعلاه. وللسبب نفسه، سيظل البرنامج موجودًا، حتى لو حذفت جميع رموزه المصدرية التي تطبق خوارزميات البرامج المكتوبة باللغة البرمجية عالية المستوى. وبالتالي فإن البرامج يمكن اعتباراها كيانات مجردة تتمتع بخصائص زمنية. لهذه الأسباب، يعرّف إرماك (2010 Irmak) البرامج على أنها كيانات اصطناعية مجردة.

يشير دنكان (2011 Duncan) إلى أن تمييز البرامج عن الأجهزة يتطلب وجودًا أنطولوجيًّا أدق من ذلك الذي تنطوي عليه الثنائية البسيطة: مجرد وملموس. يهدف دنكان (2017 Duncan) إلى تقديم مثل هذه الأنطولوجيا من خلال التركيز على مفهوم تيرنر (2011 Turner) للمواصفات كتعبير يحدد من خلاله شروط صحة البرامج (عاين الفقرة رقم 2). يؤكد دنكان (2017 Duncan) أن البرنامج يعمل أيضًا كمواصفات للجهاز المنفِّذ، مما يعني أن البرنامج سيحدد جميع السلوكيات الصحيحة التي يتعين على الجهاز تنفيذها. فإذا كانت الآلة تعمل بشكل غير متسق مع البرنامج، سيقال إن الآلة بها عطل Malfunction. بالطريقة نفسها سيشار إلى البرنامج بأنه يحتوي على خطأ Bug أو خلل حين يكون غير سليم بالنظر إلى مواصفاته.

توجد سمة وجودية أخرى ضرورية لتحديد التمييز بين البرامج والأجهزة، وهي سمة “الاصطناعية”. عرَّفَ دنكان (2017 Duncan) الاصطناعي على أنه كيان مادي، مكاني – زماني، صنعَ بهدف تحقيق وظيفة محددة بشرط وجود مجتمع يعترف بـه كأداة لهذه الوظيفة. ما يعني إمكانية تعريف البرنامج على أنه مجموعة من التعليمات المشفرة المكتوبة بلغة برمجية معينة، والذي يقوم بدور المواصفات الخاصة بأداة اصطناعية قادرة على قراءة تلك التعليمات؛ لذا تعرَّف الأجهزة على أنها أدوات اصطناعية وظيفتها إجراء حسابات محددة.

1.2 منهج مستويات التجريد

من أعلاه، فإن المنهج الذي يعتمد على التمييز بين البرامج والأجهزة ليس صارمًا في تحديد ماهية النظم الحسابية. هناك نهج وجودي آخر يعتمد على دور التجريد في هذا المسعى. يعتبر التجريد عنصرًا حاسمًا في علوم الحاسب الآلي، ويتخذ عدة أشكال متنوعة. يصف جوجين وبورستول (1985 Goguen & Burstall) بعضًا من هذا التنوع في الأمثلة التالية: يمكن تكرار الكود أثناء البرمجة، عن طريق تسمية النص والبارامتر، وهي ممارسة تعرف باسم التجريد الإجرائي Procedural Abstraction. هذه الممارسة لها أساسها الرسمي في عملية التجريد الخاص بحساب لامدا Lambda Calculus (راجع مدخل “حساب لامدا” في الموسوعة) وتسمح بآلية رسمية تعرف باسم تعدد الأشكال Polymorphism (2004 Hankin). مثال آخر وهو الكتابة النموذجية للبرمجة الوظيفية، والتي توفر نظامًا معبرًا لتمثيل تراكيب اللغة النحوية. وإلا ستجرَّد النماذج، في التصميم الموجه للكائنات، من الهياكل الشائعة الموجودة في أنظمة البرامج وتستخدم كواجهة بينية بين تنفيذ الكائنات ومواصفاتها (Gamma et al. 1994).

تشترك جميع الأمثلة أعلاه في منهجية أساسية وهي “مستويات التجريد” المستخدمة كذلك في الرياضيات (Mitchelmore and White 2004) والفلسفة (Floridi 2008). تتراكم التجريدات في الرياضيات طبقيًّا في سعي لا ينتهي للبحث عن المزيد والمزيد من المفاهيم المجردة. بهذا الفهم، يكون التجريد موضوعًا قائمًا بذاته: الموضوع الرياضي المجرد يأخذ معناه -فقط- من النظام المعرَّف من خلاله، بضابط وحيد وهو ترابط جميع الموضوعات واتساقها في النظام نفسه. وبذلك يمكن تداوله دون العودة إلى مرجع سابق أو خارجي للمعاني. يجادل البعض، في هذه النقطة على الأقل، أن التجريد في علوم الحاسب الآلي (التجريد الحسابي) يختلف اختلافًا جوهريًا عن التجريد في الرياضيات: التجريد الحسابي Computational Abstraction  لا بد أن يترك وراءه أثرًا بعد تنفيذه، وهذا يعني أن المعلومات ستختبئ ولن تنعدم (Colburn & Shute 2007). أي أن أي تفصيل تمَّ تجاهله في مستوى مجرد ما يجب ألَّا يتم تجاهله في المستوى الأدنى منه: مثلاً، لا يحتاج المبرمجون إلى الاهتمام بشأن الموقع الدقيق لمتغير ما في الذاكرة، بينما الجهاز الظاهري Virtual Machine يتطلب التعامل مع جميع عمليات تخصيص الذاكرة.

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

صيغت مستويات التجريد الخاصة بأنطولوجيا نظم الحاسب الآلي بشكل كامل على يد بريميرو (Primiero 2016)، وقد شَملت:

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

أما المواصفات فهي صياغة مجموعة المتطلبات اللازمة لحل المشكلة الحسابية المعطاة: تتعلق المواصفات بالتحديد المنظم المحتمل للعمليات التي يجب أن يقوم بها البرنامج، من خلال العملية المعروفة باسم استنباط المتطلبات Requirements Elicitation. أما الخوارزميات فتحدد الإجراء الذي سيقدم حلاً للمشكلة الحسابية المقترحة، ويفي بمتطلبات المواصفات. بينما تشكل تعليمات لغة البرمجة عالية المستوى (مثل C أو Java أو Python) التنفيذ اللغوي للخوارزمية المقترحة، غالبًا ما تسمى بكود المصدر Source Code، ويمكن للمبرمجين المدرَّبين فهمها، ولكن لا يمكن تنفيذها مباشرة بواسطة الحاسب الآلي. ثم يتم تجميع تلك التعليمات، أي ترجمتها بواسطة مترجم Compiler إلى كود تجميع ثم إلى عمليات بلغة الآلة، والتي يمكن للمعالج أن يشغلها مباشرة. أخيرًا، يأتي دور مستوى التشغيل وهو المستوى المجرد المادي للبرنامج، أي أنه يمثل بنية جهاز الحاسب الآلي المشغل للتعليمات.

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

2. المقاصد والمواصفات في الحاسب الآلي

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

2.1 المقاصد في علوم الحاسب الآلي

تبلور المقاصد المعايير المحددة لملائمة النظام الحسابي (أي صحته، عاين الفقرة رقم 7)، وبالتالي فالمقاصد تعتبر أول مستوى مجرد لنظام حسابي يلائم المشكلة المعطاة. مثلًا: قد يطلب العملاء والمستخدمون تطبيقًا لهاتف ذكي قادر على ترشيح المكالمات المزعجة للأرقام المحفوظة في مراكز الاتصال؛ يشكِّل هذا الطلب مستوى القصد المجرد في عملية تطوير نظام حسابي قادر على أداء هذه المهمة. أثناء تطوير البرامج في النظم غير البسيطة Non-Naive Systems، عادةً ما يتم صياغة المقاصد بعدة تقنيات كالعصف الذهني والاستطلاعات والنماذج الأولية وحتى فرق النقاش (Clarke and Moreira 1999)، بهدف تحديد قائمة متسقة من مقاصد الأطراف المعنية المختلفة. في هذا المستوى، لن يشار إلى كيفية حل المشكلة الحسابية، بل سيكتفى بتقديم وصف وافٍ لها.

في الأدبيات المعاصرة، طرحتْ المقاصد كموضوع للبحث الفلسفي، على الأقل منذ أنسكومب (1963 Anscombe). فقد قام الفلاسفة بالتدقيق في مقاصد الأنشطة المنفَّذة (Davidson 1963)، ومقاصد الأنشطة المستقبلية (Davidson 1978)، والأنشطة المقصودة (Anscombe 1963، Baier 1970، Ferrero 2017). نشأت من ذلك عدة مسائل: أي من الأنواع الثلاثة السابقة يمكن اعتباره نوعًا أساسيًّا؟، كيف ترتبط الأنواع الثلاثة ببعضها؟، ما هي طبيعة العلاقة بين المقصد والمعتقد؟، هل المقاصد هي حقًّا حالات ذهنية؟ أم نحن نفترض ذلك؟، وهل المقاصد هي عِلل للأفعال؟ (راجع مدخل “المقصد” في الموسوعة). أكثر المشكلات الرسمية في هذا الصدد تتعلق بإمكانية وجود عميل Agent بمقاصد غير متسقة ومع ذلك تعتبر مقاصد عقلانية (Bratman 1987، Duijf et al. 2019).

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

2.2 المحددات والمواصفات

لنعد إلى مثالنا، تطبيق مرشح المكالمات المزعجة؛ قد تتطلب المواصفات إنشاء قائمة سوداء بأرقام الهواتف المزعجة مرتبطة بمراكز الاتصال؛ ستتحدث القائمة كل (ن) من الأيام؛ عندما تَرد مكالمة، يجري التطبيق عملية التحقق من وجود الرقم ضمن القائمة السوداء أم لا؟، في حالة الرد الإيجابي، يتواصل التطبيق مع نظام إدارة المكالمات لعدم السماح للمكالمة الواردة، والسماح لها في حالة الرد السلبي.

يمكن اعتبار التوصيف السابق توصيفًا وافيًا على الرغم من أنه عبِّرَ عنه بلغة طبيعية. غالبًا ما يتم تقديم المواصفات بلغة طبيعية لتكون أقرب إلى مقاصد الأطراف المعنية وبعد ذلك يمكن إضفاء الطابع الرسمي عليها بلغة رسمية مناسبة. كما يمكن التعبير عن المواصفات عن طريق اللغات الرسومية كلغة النمذجة الموحدة UML (Fowler 2003)، أو أكثر رسمية كالمنطق الإسنادي النوعي TPL (Turner 2009a)، وما تسمى بطريقة فيينا للتطوير VDM (Jones 1990)، أو باستخدام المنطق الإسنادي Predicate Logic، أو اللغة الرياضية زد Z (Woodcock and Davies 1996)، مع الأخذ بعين الاعتبار نظرية المجموعات. مثلًا، يعبر المنطق الإسنادي النوعي (TPL) عن متطلبات النظم الحسابية باستخدام صيغ المنطق الإسنادي، حيث يتم تحديد نوع المتغيرات الكمية. يسمح اختيار أنماط المتغيرات بتحديد المواصفات على المستوى المجرد الأكثر ملاءمة. غالبًا ما يعتمد التعبير عن المواصفات بشكل غير رسمي أو رسمي بناءً على طريقة التطوير المتبعة، مع تفضيل المواصفات الرسمية عادةً في سياق أساليب التطوير الرسمية. علاوة على ذلك، فالمواصفات الرسمية تسهل عملية التحقق من صحة النظم الحسابية لاحقًا (عاين الفقرة رقم 6).

تساءل تيرنر (2018 Turner) عن الفرق بين النماذج Models والمواصفات Specifications المستخدمَين على نطاق واسع في علوم الحاسب الآلي. يقع الاختلاف فيما يسميه تيرنر بالموقف المقصود Intentional Stance: فالنماذج تصف النظام المزمع تطويره، ويتوجب تنقيحها في حالة عدم التوافق بينهما؛ بينما تحدِّد المواصفات كيفية بناء النظام بحيث يتوافق مع الوظائف المقصودة، وفي حالة عدم التطابق، فيجب تحسين النظام نفسه (2011 Turner).

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

بكلمات تيرنر (2011 Turner)، “يعتبر الشيء مواصفة عندما يحكم من خلاله على صحة منتج ما”، أي أن المواصفات توفر معايير للتأكد من صحة النظم الحسابية. وبالتالي فإن النظم الحسابية صحيحة عندما تتوافق مع مواصفاتها، أي عندما تتصرف وفقًا لها. وفي حالة العكس، فإنها توفر معايير لتحديد الأعطال (عاين الفقرة رقم 7.3)، أي أعطال النظام عندما لا يتصرف بشكل متوافق مع مواصفاته. يحرص تيرنر (2011 Turner) على ملاحظة أن مثل هذا التعريف للمواصفات هو تعريفٌ مثالي: ففي بعض الحالات، تراجع المواصفات ذاتها؛ مثل حالة تعذر إنتاج النظم بسبب قيود قوانين الفيزياء أو قيود التكلفة، أو عندما يتضح أن المواصفات لم تصاغ بشكل يناسب مقاصد العملاء والمستخدمين.

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

2.3 المواصفات والوظائف لعلوم الحاسب الآلي

تعتبر النظم الحسابية مكتملة الإنجاز والإعداد منتجات تقنية اصطناعية، أي نظم صنعها الإنسان، صممت ونفذت بهدف صريح وهو أداء وظائف محددة (Kroes 2012). تشمل المصنوعات التقنية المحددة على هذا النحو: المناضد، والمفكات، والسيارات، والجسور، وأجهزة التلفزيون. وهي تختلف عن الكيانات الطبيعية مثل: الصخور، والقطط، وجزيئات أول أكسيد الهيدروجين، التي ليست من صنع الإنسان. وكذلك الأعمال الفنية التي لا تؤدي مهامًا معينة. على هذا النحو، فإن أنطولوجيا النظم الحسابية تندرج تحت المصنوعات التقنية (Meijers 2000) التي تتميز بالازدواجية، حيث يمكن تعريفها من خلال الخصائص الوظيفية والخصائص الهيكلية (Kroes 2009، راجع مدخل “فلسفة التقنية” في الموسوعة). تحدد الخصائص الوظيفية الوظائف المطلوب من المنتج القيام بها، بينما تعبر الخصائص الهيكلية عن الخصائص الفيزيائية التي يمكن للمنتج أن يؤدي وظائفه من خلالها. تأمل مفك البراغي: قد تتضمن الخصائص الوظيفية وظيفة الربط والفك، بينما ستشير الخصائص الهيكلية إلى قطعة معدنية يمكن تثبيتها على رأس البرغي، بمقبض بلاستيكي يسمح بالحركة في اتجاه عقارب الساعة وعكس اتجاه عقارب الساعة. يمكن أن تتحقق الوظائف بطرق متعددة من خلال الخصائص الهيكلية. مثلاً: يمكن تحقيق وظيفة فك البراغي بواسطة مفك براغي معدني، أو بواسطة مفك براغي كهربائي محدد بخصائص هيكلية مختلفة كليًّا.

يبدو أن الأنطولوجيا الطبقية للنظم الحسابية التي تتميز بالعديد من المستويات المجردة المختلفة تعمل على توسيع الأنطولوجية الثنائية التي تميِّز المنتجات الاصطناعية التقنية (Floridi et al. 2015). يرى تيرنر (2018 Turner) بأن النظم الحسابية لا تزال منتجات اصطناعية باعتبار (Kroes 2009، 2012) أن كل مستوى مجرد هو مستوى وظيفي للمستويات المجردة الأدنى منه، وفي الوقت نفسه، هو مستوى هيكلي للمستويات المجردة الأعلى منه:

  • تعبر عن الوظائف التي يجب أن يحققها النظام وتنفَّذ من خلال المواصفات؛

يترتب على ذلك، وفقًا لتيرنر (2018 Turner)، أن المستويات الهيكلية ليست بالضرورة مستويات مادية، وأن فكرة الأداة المجردة Abstract Artifact موجودة في علوم الحاسب الآلي. لهذا السبب، يأتي تيرنر (2011 Turner) لتعريف البرامج المكتوبة باللغات البرمجية عالية المستوى ليعتبرها منتجات اصطناعية تقنية، من حيث إنها تشكل مستوى هيكلي لتنفيذ المواصفات التي تعتبر، في هذه الحالة، كمستوى وظيفي لها (عاين الفقرة رقم 4.2).

ينتج مما سبق عدة نتائج، النتيجة الأولى: أن كل مستوى مجرد (والذي يعبر عن وظيفة ما يجب إنجازها) يمكن تحقيقه من خلال تعدد المستويات الهيكلية المحتملة التي تعبر عن كيفية إنجاز هذه الوظيفة: فيمكن تحقيق الوظيفة المبتغاة من خلال المواصفات بطرق متعددة، ويمكن أن تحل مشكلة حسابية معينة -كان قد تم التعبير عنها بواسطة مواصفة محددة- بواسطة خوارزميات مختلفة، والتي يمكن أن تختلف بالنسبة لبعض الخصائص المهمة ولكنها جميعها  في النهاية صالحة بشكل متساوٍ (عاين الفقرة رقم  3)؛ ويمكن تنفيذ خوارزمية ما في برامج مختلفة مكتوبة بلغات مختلفة، وكلها تعبر عن البرنامج نفسه إذا نفذوا الخوارزمية ذاتها (Angius and Primiero 2019)، وكذلك الكود المصدري يمكن تجميعه في العديد من لغات الآلة التي تعتمد على أساليب مختلفة ضمن معمارية مجموعة التعليمات الخاصة بها ISA. بعد ذلك، يمكن تثبيت التعليمات البرمجية القابلة للتنفيذ وتشغيلها على العديد من الأجهزة، بشرط أن تشترك هذه الأجهزة في معمارية تعليمات واحدة.

أما النتيجة الثانية فهي أن كل مستوى مجرد باعتباره مستوىً وظيفيًّا سيوفر معايير لتحقق من صحة المستويات الأدنى منه (Primiero 2020). ليس على مستوى التنفيذ وحسب، فالتحقق من الصحة مطلوب في كل المستويات، بدءًا بالمواصفات حتى التشغيل. فقد يكون سبب الأعطال موجودًا في أي مستوى لا ينفذ المستوى الوظيفي المناسب الخاص به بشكل صحيح (عاين الفقرة رقم 7.3 وFresco، Primiero (2013)). وفقًا لتيرنر (2018 Turner)، يمكن التحقق من صحة مستوى المواصفات بالنظر للمقاصد، على الرغم من صعوبة ذلك. ويمكن التحقق من صحة أي مستوى غير مادي رياضيًا من خلال التحقق الأساسي Formal Verification، والتحقق من صحة مستوى التشغيل المادي تجريبياً عن طريق اختباره Testing (عاين الفقرة رقم 6). يمكننا التحقق من صحة المواصفات بمراجعة مقاصد العملاء بدلاً من محاولة الوصول إلى ذهنية المعنيين.

تتعلق المسألة الأخيرة بمسألة أكثر عمومية والتي تتمثل في تحديد كيفية حيازة المنتجات الاصطناعية لوظائفها، وما الذي يعنيه ارتباط الخصائص الهيكلية بمقاصد الأطراف المعنية. المسألة معروفة كذلك في فلسفة علم الأحياء وعلم الإدراك، وقد طرحت نظريتان رئيسيتان كحل لهذ المسألة. وفقًا للنظرية السببية في الوظائف The Causal Theory Of Function (Cummins 1975)، يتم تحديد الوظائف من خلال القدرات الفيزيائية للمنتجات الاصطناعية، مثلًا: تحدِّد قدرة القلب الفيزيائية على الانقباض والانبساط وظيفتَه بضخ الدم في الدورة الدموية. ومع ذلك، تواجه هذه النظرية صعوبات حقيقية عند تطبيقها على المصنوعات التقنية. أولاً: النظرية تعيق تحديد الصحة والعطل (Kroes 2010)؛ لنفترض أن تطبيق مرشح المكالمات المثبت على هاتفنا الذكي بدأ في حظر المكالمات المحفوظة في جهات الاتصال الخاصة بنا؛ وِفقًا للنظرية السببية للوظيفة، ستعتبر هذه الوظيفة بمثابة وظيفة جديدة للتطبيق. ثانيًا: لا تميز النظرية الوظائف المقصودة عن الآثار الجانبية (Turner 2011): إن كانت لدينا مكالمة طويلة جدًا، سترتفع حرارة هاتفنا الذكي بالتأكيد؛ هذه ليست وظيفة مقصودة للعملاء أو المطورين. وفقًا للنظرية القصدية في الوظائف Intentional Theory Of Function (McLaughlin 2001، Searle 1995)، فإن الوظيفة التي حددها المصمم أو المستخدم هي الوظيفة المقصودة من المنتج الاصطناعي، وتختار الخصائص الهيكلية للمنتجات كي تتمكن من تحقيقها. هذه النظرية قادرة على التمييز بين الصحة والعطل، وكذلك التمييز بين الآثار الجانبية والوظائف المنشودة، لكنها لا تحدد مكان تواجد الوظيفة بالفعل، سواء كان في المنتج نفسه أو في ذهن الوكيل (الأطراف المعنية والمستخدمين والمطورين). في الحالة الأولى، يعود المرء إلى السؤال عن كيفية حيازة المنتجات الاصطناعية للوظائف. في الحالة الثانية، هناك حاجة إلى شرح إضافي حول كيفية ارتباط الحالات الذهنية بالخصائص الفيزيائية للمنتجات الاصطناعية (Kroes 2010). يرى تيرنر (2018 Turner) أن الحدس الكامن وراء كل من النظريتين، السببية والقصدية، مفيد لفهم العلاقة بين الوظيفة والخصائص الهيكلية في النظم الحسابية، ويقترح دمج النظريتين في نظرية واحدة. من ناحية أخرى، لا توجد وظيفة بدون عملية تنفيذ؛ ومن ناحية أخرى، لا توجد مقاصد بدون عملاء ومطورين ومستخدمين.

3. الخوارزميات في الحاسب الآلي

على الرغم من كونها معروفة ومستخدمة على نطاق واسع منذ العصور القديمة، إلا أن مشكلة تحديد ماهية الخوارزميات ما زالت قائمة (Vardi 2012). نشأت كلمة “خوارزمية” من اسم عالم الرياضيات الفارسي، القرن التاسع، أبو جعفر محمد بن موسى الخوارزمي، الذي قدَّم قواعد لإجراء العمليات الحسابية باستخدام الأرقام العربية. في الواقع، القواعد التي يتبعها المرء لإجراء العمليات الحسابية الأساسية مثل الضرب أو القسمة، هي أمثلة يومية للخوارزميات. تشمل الأمثلة المعروفة الأخرى قواعد تقسيم الزاوية باستخدام البوصلة والمسطرة، أو خوارزمية إقليدس لحساب القاسم المشترك الأكبر. بشكل بديهي، الخوارزمية هي مجموعة من التعليمات التي تمكِّننا من تنفيذ مهمة معينة. على الرغم من أنه تقليد قديم في الرياضيات، إلا أن مجالي المنطق والفلسفة هما اللذان طرحا مهمة تقديم تعريف لماهية الخوارزمية أبان الأزمة التأسيسية للرياضيات في أوائل القرن العشرين (راجع مدخل “فلسفة الرياضيات” في الموسوعة). نشأ مفهوم القدرة الحسابية الفعالة Effective Calculability من البحث المنطقي، حيث قدم مفهومًا رسميًّا للخوارزمية بدلاً من المفهوم البديهي، الأمر الذي آذن ببزوغ نظرية الحساب. منذ ذلك الحين، اقترحت تعريفات مختلفة للخوارزميات، تتراوح بين المقاربات الرسمية وغير الرسمية، كما سيتضح في الأقسام التالية.

3.1 المقاربات الكلاسيكية

قدَّم ماركوف (1954 Markov) أول تعريف دقيق للخوارزمية: فهي عملية حسابية حتمية، قابلة للتطبيق، وفعالة. تعتبر العملية الحسابية حتمية إذا تضمنت تعليمات دقيقة لا تسمح بأي “اختيار اعتباطي” في تنفيذها. كما يجب ألا يكون الحاسب (البشري أو الاصطناعي) غير متيقن من الخطوة التالية التي يجب عليه تنفيذها. وتعتبر الخوارزميات قابلة للتطبيق، حسب ماركوف، إذا احتوت على فئات من المدخلات (مثلاً، الأعداد الطبيعية للعمليات الحسابية الأساسية) بدلاً من المدخلات الفردية (أرقام طبيعية محددة). يعرِّف ماركوف (1954: 1 Markov) الفعالية على أنها “ميل الخوارزمية للحصول على نتيجة محددة”. بعبارة أخرى، تكون الخوارزمية فعالة إذا كانت ستنتج في النهاية حلاً للمشكلة الحسابية.

يحدد كلين (1967 Kleene) المحدودية كخاصية مهمة أخرى: الخوارزمية هي إجراء يمكن وصفه عن طريق مجموعة محدودة من التعليمات، وتحتاج إلى عدد محدود من الخطوات، وتهدف إلى تقديم حل للمشكلة الحسابية. كمثال تفنيدي لهذه الفكرة، لنفترض وجود حلقة التكرار while المحددة بواسطة عدد محدود من الخطوات، ولكنها تستمر في تكرارها إلى الأبد نظرًا لأن شرطها مستوفى دائمًا. يجب أيضًا أن تكون التعليمات قابلة للتنفيذ الميكانيكي، أي أن الآلة لا تحتاج إلى وعي أو إدراك خاص لتنفيذ هذه التعليمات. بالإضافة إلى حتمية ماركوف وفعاليته، يرى كلين (1967 Kleene) أن التعليمات يجب أن تكون قادرة على إدراك أن حل المشكلة الحسابية قد تم تحقيقه، ومن ثمَّ إيقاف عملياتها الحسابية.

يعمِّق نوث (1973 Knuth) تحليلات ماركوف (1954 Markov) وكلين (1967 Kleene) بالآتي:

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

  1. المحدودية: يجب أن تنتهي الخوارزمية دائمًا بعد عدد محدود من الخطوات. […]
  2. القطعية: يجب تحديد كل خطوة في الخوارزمية بدقة؛ يجب تحديد الإجراءات التي سيتم تنفيذها بدقة وبشكل قاطع لا لبس فيه في كل حالة. […]
  3. المدخلات: تحتوي الخوارزمية على صفر أو أكثر من المدخلات. […]
  4. المخرجات: تحتوي الخوارزمية على صفر أو أكثر من المخرجات. […]
  5. الفعالية: من المتوقع أيضًا أن تكون الخوارزمية فعالة بشكل عام، أي يجب أن تكون جميع عملياتها بسيطة بما يكفي بحيث يمكن من حيث المبدأ تنفيذها بشكل صحيح في فترة زمنية محدودة بواسطة شخص يستخدم قلم الرصاص والورقة. (1973: 4-6 Knuth) […]

حسب رأي كلين (1967 Kleene)، فالمحدودية تؤثر على كل من عدد التعليمات وعدد الخطوات الحسابية المنفذة. وكما هو الحال في حتمية ماركوف، يتطلب مبدأ التحديد عند نوث تحديد كل خطوة حسابية تالية بشكل لا لبس فيه. علاوة على ذلك، يتطلب نوث (1973 Knuth) بشكل أكثر صراحة أن تحتوي الخوارزميات على (مع احتمال خلوها) عدد من المدخلات والمخرجات. أما بالنسبة للخوارزميات التي لا تحتوي على مدخلات أو مخرجات، فيرى نوث أنها قد تستخدم البيانات المخزنة داخليًا كمدخلات لها، ولا تعيد البيانات إلى مستخدم خارجي (Rapaport 2019، الفصل 7، في مصادر الإنترنت الأخرى). بالنسبة للفعالية، إلى جانب ميل ماركوف “للحصول على نتيجة معينة”، يتطلب نوث الحصول عليها في فترة زمنية محدودة وأن تكون التعليمات ذرية، أي بسيطة بما يكفي لتكون مفهومة، ويمكن للإنسان أو الحاسب الاصطناعي تنفيذها.

3.2 المقاربات الرسمية لـ علوم الحاسب الآلي

يؤكد جورفيتش (2011 Gurevich)، من ناحية ما، أنه من غير الممكن تقديم تعريفات رسمية للخوارزميات، إذ ستستمر الفكرة في التطور مع مرور الوقت: تأمل كيف كانت الخوارزميات المتسلسلة، المستخدمة في الرياضيات القديمة، المحصورة بالتوازي والتناظر، وكيف هي الخوارزميات الكمومية في علوم الحاسب الآلي حاليًّا، وما الذي من المحتمل أن يتولَّد من أنواع جديدة في المستقبل القريب. من ناحية أخرى، يمكننا إجراء تحليل رسمي إذا كان هدفنا، فقط، هو الخوارزميات المتسلسلة الكلاسيكية. بالتفصيل، يقدم جورفيتش (2000 Gurevich) تعريفًا بديهيًا لهذه الفئة من الخوارزميات.

يمكن محاكاة أي خوارزمية متسلسلة بواسطة آلة الحالة المجردة التسلسلية Sequential Abstract State Machine لتفي بثلاث مسلمات:

  1. تفترض فكرة التتابع الزمني Sequential-Time وجود ترابط بين أية خوارزمية (أ) كمجموعة من الحالات ت(أ)، بمجموعة من الحالات الأولية أ(أ) كمجموعة فرعية من ت(أ)، وتطبيق منطلق من ت(أ) إلى ت(أ) بتحويلات أحادية الخطوة للخوارزمية (أ). يمكن اعتبار الحالات على أنها أوصاف لحظية لخوارزميات قيد التنفيذ. فتنفيذ الخوارزمية (أ) (من المحتمل أن تكون غير محدودة) سينتج سلسلة من الحالات، تبدأ من الحالة الأولية، ثم تخضع إلى تحويل أحادي الخطوة يحولها من حالتها الأولى إلى الحالة التالية في التسلسل. إنهاء التنفيذ حالة غير مفترضة ضمن تعريف جورفيتش، فلا يلزم أن تكون التحويلات أحادية الخطوة تحويلات ذرية، ولكنها قد تتكون من مجموعة محدودة من العمليات الذرية.
  • وفقًا لفرضية الحالة المجردة، فإن الحالات في ت(أ) هي عبارة عن بنى من الدرجة الأولى First-Order Structures، كما هو معرَّف بشكل شائع في المنطق الرياضي؛ بعبارة أخرى، تقدم الحالات دلالات لعبارات من الدرجة الأولى.
  • أخيرًا، تنص فرضية الاستقراء المحدود Bounded-Exploration على أنه إذا نتج عن الحالة (أ) حالتين (س) و (ص)، فهناك دائمًا مجموعة (م) مكونة من عدة حدود بحيث: عندما يتزامن (س) و (ص) مع (م)، فإن مجموعة تحديثات (س) ستتوافق مع مجموعة تحديثات (ص). ويتطابق (س) و (ص) مع (م) عندما يكون تقييم (ع) في (س)، لكل (ع) في (م)، هو تقييم (ع) في (ص). وهذا يسمح للخوارزمية (أ) باستكشاف الحالات التي ترتبط، فقط، بحدود المجموعة (م).

يعترض موسكوفاكيس (2001 Moschovakis) على ما سبق إذ يرى أن المفهوم البديهي للخوارزمية لم يستوعب بالكامل من خلال فكرة الآلات المجردة. بالنظر إلى الدالة التكرارية العامة د: ن -> ن المعرَّفة على الأعداد الطبيعية، عادة ما يتوفر العديد من الخوارزميات لحسابها؛ فـ”الخصائص الأساسية المستقلة عن التنفيذ” لا تستوعب بواسطة الآلات المجردة، ولكن يمكن استيعابها بنظام المعادلات التكرارية. بالنظر إلى خوارزمية الفرز بالدمج Merge Sort Algorithm الخاصة بتصنيف القوائم؛ هناك العديد من الآلات المجردة المختلفة تصنِّف بطريقة الفرز بالدمج، لكن السؤال الذي يطرح هنا: أي من هذه الآلات ستختار كخوارزمية للفرز بالدمج. تعتبر خوارزمية الدمج بديلًا لنظام المعادلات التكرارية في تحدد الوظيفة المعنية، في حين أن الآلات المجردة التي تجري الفرز بالدمج ما هي إلا تطبيقات مختلفة للخوارزمية نفسها. في تحليله الرسمي، يطرح موسكوفاكيس مسألتين: التطبيقات المختلفة للخوارزمية نفسها يجب أن تكون تطبيقات متكافئة، ومع ذلك، يجب تحديد علاقة التكافؤ هذه رسميًّا. مع ذلك، ما يزال يتعين علينا توضيح ما تعنيه الفكرة البديهية للخوارزمية التي تشكَّلت بواسطة أنظمة المعادلات التكرارية.

يقترح بريميرو (2020 Primiero) دراسة طبيعة الخوارزميات عبر ثلاثة مستويات مختلفة من التجريد. في المستوى العلوي، يمكن تعريف الخوارزميات على أنها تجريد للإجراء الموصوف المتضمن للعديد من المجموعات المختلفة من الحالات والتحويلات. وهذا المستوى، يمكن فهم الخوارزميات على أنها مواصفات غير رسمية، أي كأوصاف غير رسمية للإجراء (أ). في المستوى الأوسط، تحدِّد الخوارزميات التعليمات اللازمة لحل مشكلة حسابية معينة؛ أي أنها تعيِّن الإجراء بالتحديد. وبالتالي يمكن تعريف الخوارزميات على أنها إجراءات أو أوصاف مقدمة بلغة رسمية معينة (ل) لطريقة تنفيذ الإجراء (أ). لا يمكن تحديد العديد من الخصائص المهمة للخوارزميات، بما في ذلك تلك المتعلقة بفئات التعقيد وهياكل البيانات في هذا المستوى الإجرائي، بل سيعوض ذلك بالإشارة إلى آلة مجردة تنفذ الإجراء. في المستوى السفلي، يمكن تعريف الخوارزميات على أنها آلات مجردة قابلة للتنفيذ، أي كمواصفات، مكتوبة بلغة رسمية (ل) لعمليات ينفذها برنامج (ب) في آلة مجردة معينة (آ). يسمح التعريف الثلاثي للخوارزميات لـبريميرو (2020 Primiero) بطرح تعريف رسمي جبري لعلاقتي المحاكاة والمحاكاة الثنائية بين الخوارزميات (Milner 1973، انظر أيضًا Angius and Primero 2018). تنفذ الآلة (آل) البرنامج (بل) بالخوارزمية نفسها للآلة (آم) التي تنفذ البرنامج (بم)، إذا وفقط إذا، كانت الآلات المجردة التي تترجم كود المصدر للآلتين (آل) و(آم) في علاقة محاكاة ثنائية.

3.3 المقاربات غير الرسمية لـ علوم الحاسب الآلي

يؤكد فاردي (2012 Vardi) على أنه برغم وجود العديد من التعريفات، الرسمية وغير الرسمية، إلا أنه لا يوجد إجماع عام على ماهية الخوارزمية. إن مقاربتي جورفيتش (2000 Gurevich) وموسكوفاكيس (2001 Moschovakis)، اللتين يمكن إثبات أنهما متكافئتين منطقيًا، تقدمان، فقط، البنى المنطقية للخوارزميات، تاركةً السؤال الرئيسي دون إجابة. يقترح هيل (2013 Hill) أن التعريف غير الرسمي للخوارزميات، مع الأخذ بعين الاعتبار الفهم البديهي للخوارزميات، قد يكون أكثر فائدة، خاصة للخطاب العام وللتواصل بين الممارسين والمستخدمين.

يقدم رابابورت (2012 Rapaport، الملحق) محاولة لتلخيص التعريفات الكلاسيكية الثلاثة للخوارزمية:

الخوارزمية (بالنسبة للمشغِّل (م) بغرض تحقيق الهدف (ه)) هي:

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

and unambiguous for E—that is,

E knows how to do it

E can do it

it can be done in a finite amount of time

and, after doing it, E knows what to do next—

which procedure takes a finite amount of time (that is, it halts),

and that ends with G accomplished.

يهدف هيل (2016 Hill) إلى تقديم تعريف غير رسمي للخوارزمية، معتمدًا على تعريف رابابورت (2012 Rapaport):

"الخوارزمية هي بنية تَحَكّم مركَّبة، حتمية، محدودة، مجردة، فعالة، تحقق غرضًا معينًا، بموجب شروط معينة" (Hill 2016: 48).

بادئ ذي بدء، الخوارزميات هي بنى مركَّبة وليست بسيطة، أي أنها مركبة من وحدات من الخطوات حسابية. هذه البنى محدودة وفعالة، كما ذكر صراحة ماركوف وكلين ونوث. وعلى الرغم أنهم لا يذكرون أنها مجردة بشكل صريح، إلا أن هيل (2016 Hill) يؤكد أنها ضمن تحليلهم، لأنهم أشاروا إلى افتقارها إلى الخصائص المكانية والزمانية واستقلاليتها عن مثيلاتها. الخوارزميات توفر التحكم، أي “المحتوى الذي يحدث نوعًا من التغير من حالة إلى أخرى، معبرًا عنه في قيم المتغيرات والإجراءات اللاحقة” (ص 45).  وهي حتمية، لأنها تأمر الحالة بالانتقال لتنفيذ عمليات محددة. أخيرًا، تعمل الخوارزميات لتحقيق أغراض معينة بموجب بعض الأحكام أو الشروط المسبقة المحددة بشكل جيد. يجادل المؤلف أن الخوارزميات، بناءً على هذا التعريف، مماثلة للمواصفات فيما يتعلق بتحديد هدف ما تحت موارد معينة. إلا أن التعريف يميِّز الخوارزميات عن بنى التحكم المركبة الأخرى. مثلًا: الوصفات لا تعتبر خوارزميات لأنها غير فعالة؛ وكذلك الألعاب لأنها غير حتمية.

4. البرامج في علوم الحاسب الآلي

ترتبط أنطولوجيا برامج الحاسب الآلي ارتباطًا وثيقًا بالطبيعة التصنيفية للنظم الحسابية (عاين الفقرة رقم 1). إذا عرِّفَت النظم الحسابية على أساس ثنائية البرامج والأجهزة، فإن البرامج ستكون عبارة عن كيانات مجردة تترجم مقاصد منشئها وتعارض الطبيعة الملموسة للأجهزة. طرحت عدة أمثلة لهذه التفسيرات في الفقرة رقم 1.1، كما تضمَّنت تعريفَ “التجريد الملموس” الخاص بكولبرن (2000 Colburn)، وتوصيفَ إرماك لـ”الأداة المجردة” (2012 Irmak)، واعتبار البرامج كمواصفات للآلات التي اقترحها دنكان (2011 Duncan). يقابل ذلك، وفي ظل تفسير النظم الحسابية من خلال التسلسل الهرمي للمستويات المجردة، فإن البرامج هي تطبيقات للخوارزميات. لتحليل أنطولوجيا البرامج بهذا المعنى، يمكن الرجوع إلى الفقرة رقم 5، التالية في هذا المدخل، الخاصة بمفهوم التنفيذ. يركز هذا القسم على التعريفات المهمة المتداولة في أدبيات هذا الباب، وبالتحديد تلك الآراء التي تعتبر البرامج كنظريات أو كمنتجات اصطناعية، مع التركيز على مسألة علاقة البرامج بالعالم.

4.1 البرامج كنظريات

يعود الرأي القائل بأن البرامج هي نظريات إلى مقاربات علم الإدراك. في سياق ما يسمى بعلم نفس معالجة المعلومات (IPP) الخاص ببحوث محاكاة العمليات الإدراكية البشرية، فقد قدم نيويل وسيمون (1972 Newell and Simon) أطروحة مفادها أن برامج المحاكاة هي نظريات تجريبية بالنسبة لأنظمتها المحكيَّة. كما عيّن نيويل وسيمون لبرنامج الحاسب الآلي دور النظرية للنظامين: الحاكي والمحكي، أي الآلة التي تشغل البرنامج، بهدف استنباط تنبؤات تخص النظام المحكي. وبالأخص عندما يتم تتبع تشغيل برنامج المحاكاة، بالنظر إلى حل مشكلة محددة، للتنبؤ باستراتيجيات العملية العقلية التي سيتَّبعها الإنسان، موضوع الدراسة، عندما يطلب منه إنجاز المهمة نفسها. فإذا لم تتطابق آثار تتبع التشغيل والتقارير الشفهية لاستراتيجيات العملية الخاصة بالإنسان، تراجع النظرية التجريبية التي قدَّمها برنامج المحاكاة. يمكن مقارنة الاستخدام التنبئي للبرامج، وفقًا لنيويل وسيمون، بالاستخدام التنبئي لقوانين التطور الخاصة بالنظام التي يعبَّر عنها بالمعادلات التفاضلية أو الفَرقية.

شارك عالما الإدراك بيليشين  (1984 Pylyshyn)  وجونسن لايرد (1988 Johnson-Laird)الفكرة التي طرحها نيويل وسيمون حول البرامج. اتفقا على أن البرامج بعكس النظريات النموذجية هي أفضل في مواجهة تعقيد نمذجة عملية المحاكاة التي يجبر موضوع الدراسة فيها على ملء جميع التفاصيل اللازمة لتنفيذ البرنامج، الأمر الذي قد يؤول إلى طرح نظريات غير مكتملة أو غير متماسكة في مرحلة ما من مراحل البحث العلمي، بينما البرامج تتفادى هذه الحالة.

من ناحية أخرى، رأى مور (1978 Moore) إن اعتبار البرامج كنظريات ما هي إلا أسطورة من أساطير علوم الحاسب الآلي. نظرًا لأن البرامج كل ما يمكنها هو محاكاة مجموعة معينة من الظواهر التجريبية، فهي على أكثر تقدير يمكنها أن تلعب دور النماذج الحسابية لتلك الظواهر. لاحظ مور أن هناك حاجة إلى الدوال الدلالية لتفسير النظام التجريبي المحكي لكي يتم الاعتراف بالبرامج كنماذج. ومع ذلك، فإن الرأي القائل بأن البرامج هي عبارة عن نماذج لا ينبغي أن يخطَّأ مقابل تعريفها على أنها نظريات: فالنظريات تفسِّر وتتنبأ بالظواهر التجريبية التي تحاكيها النماذج، بينما المحاكاة بواسطة البرامج لا تقدم ذلك.

وفقًا لعالم الحاسب الآلي بول ثاجارد (1984 Paul Thagard)، فإن فهم البرامج كنظريات يتطلب رؤية نحوية أو دلالية للنظريات (راجع مدخل “بنية النظريات العلمية” في الموسوعة)، إلا أن البرامج لا تتوافق مع وجهتي النظر هاتين. فوفقًا لوجهة النظر النحوية (Carnap 1966، Hempel 1970)، فإن النظريات عبارة عن مجموعة من الجمل عبِّرَ عنها بلغة محددة بهدف وصف النظم التجريبية المستهدفة؛ بعض هذه الجمل تحدِّد بديهيات النظرية، وبعضها عبارة عن عبارات شبيهة بالقانون تعبر عن انتظام تلك النظم. بينما البرامج عبارة عن مجموعة من التعليمات المكتوبة بلغة برمجية محددة والتي لا تصف أي نظام، فبقدر ما هي كيانات لغوية إجرائية، لكنها ليست كيانات توضيحية. لهذا السبب، يعترض رابابورت (2020 Rapaport، راجع مصادر الإنترنت الأخرى) على أن لغات البرمجة الإجرائية يمكن، بالغالب، ترجمتها إلى لغات توضيحية وأن هناك لغات، كلغة برولوغ Prolog، يمكن تفسيرها إجرائيًا وتوضيحيًّا في آنٍ واحد. أما بالنسبة لوجهة النظر الدلالية (Suppe 1989، Van Fraassen 1980)، فالنظريات تطرح من خلال زمرة من النماذج، معرَّفة على أنها بنى من نظرية المجموعة مستوفية في صياغتها للجمل النظرية. ومع ذلك، وعلى النقيض من مور (1978 Moore)، يرفض ثاجارد (1984 Thagard) أن توصف البرامج على أنها حالة معرفية للنماذج: فالبرامج تحاكي النظم الفيزيائية بدون الاعتناء بالقوانين النظرية والمسلمات، بل أنها تتضمن تفاصيل تنفيذية تخص اللغة البرمجية المستخدمة، وليس النظام المحكي المستهدف.

توجد مقاربة مختلفة لمسألة ما إذا كانت البرامج نظريات أم لا، تأتي هذه المرة من عالم الحاسب الآلي بيتر نور (1985 Peter Naur). وفقًا لـنور، فإن البرمجة بحد ذاتها هي عملية بناء لنظرية ما، هذا لا يعني أن البرامج هي نظريات، ولكن لأن عملية التطوير الناجحة للبرامج ودورات حياتها تتطلب أن يكون لدى المبرمجين والمطورين نظريات عن البرامج المتاحة. تفهم النظرية هنا، وفقًا لرايل (2009 Ryle)، على أنها مجموعة من المعارف التي يتشاركها المجتمع العلمي حول مجموعة من الظواهر التجريبية، ولا يتم التعبير عنها بالضرورة بشكل بديهي أو رسمي. النظريات الخاصة بالبرامج ضرورية خلال دورة حياة البرنامج ليتمكن فريق التطوير من إدارة التعديلات المطلوبة حال كان هناك خطأٌ حسابي أو حلول غير مرضية للمشكلة الحسابية المراد حلها. يجب أن تسمح هذه النظريات للمطورين بتعديل برامجهم بحيث يمكن توفير حلول بديلة للمشكلة المطروحة. لهذا السبب، يرى نور (1985 Naur) أن مثل هذه النظريات أكثر جوهرية في تطوير البرامج من إجراءات التوثيق والتوصيف.

بالنسبة إلى تيرنر (2010 Turner، 2018 الفصل 10)، فهو يرى أن لغات البرمجة هي كيانات رياضية محددة بقواعد نحوية ودلالية رسمية. عمليًّا، يتم تعريف كل بناء نحوي، مهمة مثلاً، أو حلقة شرطية أو تكرارية، من خلال قاعدة نحوية تحدد تركيبها، وبقاعدة دلالية تربطها بمعنىً ما. واعتمادًا على ما إذا كانت الدلالات المفضلة هي من النوع التشغيلي أو الدلالي، يتم إعطاء المعنى لكونها عمليات لآلة مجردة أو دوال رياضية جزئية لمجموعة من الحالات إلى مجموعة أخرى من الحالات. على سبيل المثال، فعبارة التخصيص البسيط (س: =ت س:= ت) هي عبارة مرتبطة، وذلك وفق الدلالات التشغيلية، وبعملية تحديث(ل، س، ف) على مستوى الآلة، بحيث يتم تعيين المتغير (ف) المترجم إلى (ت) في العبارة السابقة إلى المتغير (س) في الحالة (ل).  في كلا الحالتين التشغيلية والدلالية، يمكن فهم البرامج على أنها نظريات رياضية تعبر عن عمليات آلة التنفيذ. بالنظر للدلالات التشغيلية: القاعدة النحوية للنموذج (ب، س) ⇓ ص ينص دلاليًّا على أن البرنامج (ب) سينفذ في حالة (س) لينتج (ص).

وفقًا لـتيرنر (2010، 2018 Turner)، تعتبر لغة البرمجة ذات الدلالات التشغيلية مماثلة للنظرية البديهية في العمليات Axiomatic Theory Of Operations حيث توفر مسلمات للعلاقة ⇓.

4.2 البرامج كمنتجات اصطناعية تقنية في علوم الحاسب الآلي

يمكن فهم البرامج على أنها منتجات اصطناعية تقنية لأن لغات البرمجة تعرَّف، مثل أي منتج اصطناعي، بناءً على الخصائص الوظيفية والهيكلية (Turner 2014، 2018 ch.5). تقدَّم الخصائص الوظيفية للغات البرمجة عالية المستوى من خلال الدلالات المرتبطة بالبناء النحوي للغة. يشير تيرنر (2014 Turner) إلى أنه يمكن بالفعل فهم لغات البرمجة على أنها نظريات بديهية فقط عندما يكون مستوى وظيفتها معزولًا. من ناحية أخرى، يتم تحديد الخصائص الهيكلية وفق عملية التنفيذ دون أي تحديد للمكونات المادية الخاصة بآلات الحوسبة: بالنظر لتركيب نحوي ما مع وصف وظيفي مرتبط به، يتم تحديد خصائص اللغة الهيكلية بواسطة العمليات الفيزيائية التي تقوم بها الآلة لتنفيذ التعليمات المطلوبة. على سبيل المثال، التعبير (س:= ه) سيتم ربطه ماديَّا من خلال وضع قيمة (ه) في الموقع المادي لـ (س).

هناك مطلب آخر لاعتبار لغة البرمجة منتجًا اصطناعيًا تقنيًا وهو وجوب تزويدها بدلالات توفر معايير التحقق من صحة عملية التنفيذ. يصادق المبرمج على الخصائص الوظيفية والهيكلية للبرنامج من خلال التأكد من صحة البرنامج دلاليًّا بالكامل.

4.3 البرامج وعلاقتها بالعالم

تتعلق مسألة ما إذا كانت برامج الحاسب الآلي عبارة عن نظريات أو لا بعلاقتها بالعالم الخارجي. إذا كانت البرامج نظريات، فسيتعين عليها تمثيل بعض النظم التجريبية، ونشوء علاقة دلالية مباشرة بين البرامج والعالم. على النقيض من ذلك، جادل البعض بأن العلاقة بين البرامج والنظم الطبيعية تتم بوساطة نماذج من العالم الخارجي (Colburn et al. 1993 ، Smith 1985). فقد جادل سميث (1985 Smith) بأن النماذج هي أوصاف مجردة للأنظمة التجريبية، وأن النظم الحسابية التي تعمل فيها لها برامج تعمل كنماذج للنماذج، أي أنها تمثل نماذج مجردة للواقع. ستكون هذه النظرة لأنطولوجيا البرامج مفيدةً عند مناقشتنا لموضوع الصحة Correctness في علوم الحاسب الآلي (عاين الفقرة رقم 7): إذا أعتبر أن المواصفات نماذج تتطلب سلوكيات معينة من النظم الحسابية، فيمكن النظر إلى البرامج على أنها نماذج للإيفاء بالمواصفات.

يمكن طرح وجهتي النظر حول البرامج (كنظرية، أو كمنتج اصطناعي تقني) اعتمادًا على نظرتنا لعلاقة البرامج بالعالم (Rapaport 2020، الفصل 17، انظر موارد الإنترنت الأخرى). فوفقًا لوجهة النظر الأولى، تكون البرامج “واسعة” و”خارجية” و”دلالية”: فهي تمنح إشارة مباشرة إلى عناصر نظام تجريبي ما وإلى العمليات عليها. ووفقًا لوجهة النظر الأخرى، فإن البرامج “ضيقة” و”داخلية” و”نحوية”: فهي تشير فقط إلى العمليات الذرية لآلة التنفيذ الحسابية. يجادل رابابورت (2020 Rapaport، راجع موارد الإنترنت الأخرى) بأن البرامج لا تحتاج إلى أن تكون “خارجية” ولا “دلالية”. أولاً: يجب ألا يكون الحساب نفسه “خارجيًا”: تقوم آلة تورينج Turing machine بتنفيذ التعليمات الواردة في جدولها المحدد باستخدام البيانات المكتوبة على شريطها، ثم تتوقف بعد كتابة نواتج حساباتها على الشريط. فالبيانات، بالمعنى الدقيق للكلمة، ليست مدخلة ولا مخرجة إلى مستخدم خارجي. علاوة على ذلك، وفق نوث (1973 Knuth) يتطلب أن يكون للخوارزميات صفر أو أكثر من المدخلات والمخرجات (عاين الفقرة رقم 3.1). قد يكون برنامج الحاسب الآلي الذي لا يتطلب مدخلات برنامجًا، كالبرنامج الذي عليه أن يستخرج جميع الأعداد الأولية ابتداءً من الرقم واحد؛ ويمكن أن يكون البرنامج الذي لا يحتوي على مخرجات برنامجًا، أيضًا، كالبرنامج الذي عليه أن يحسب قيمة متغير معين (س) دون إرجاع القيمة المخزنة كناتج. ثانيًا: لا يلزم أن تكون البرامج “خارجية” أو غائية، أي موجهة نحو هدفٍ ما. بالطبع، فهذا الرأي يتعارض مع المواقف الأخرى المعروفة في أدبيات هذا الفصل. يجادل سوبير (1988 Suber) أنه بدون مراعاة للأهداف وللأغراض، لن يكون من الممكن تقييم ما إذا كان البرنامج صحيحًا أم لا؛ أي يتصرف على النحو المنشود أو غير ذلك. وكما هو مذكور في الفقرة رقم 3.3، يحدد هيل (2016 Hill) في تعريفه غير الرسمي أن الخوارزميات يجب أن تحقق “غرضًا معينًا، بموجب شروط معينة” (هيل 2016: 48). بناءً على هذه الآراء، يجيب رابابورت (2020 Rapaport، الفصل 17، راجع موارد الإنترنت الأخرى) إن كانت الأهداف والأغراض ومقاصد المبرمجين مفيدة جدًا للحاسب البشري لفهم البرنامج، فإنها ليست ضرورية لجهاز الحاسب الاصطناعي الذي عليه إجراء الحسابات التي يطلبها منه كود برمجي. في الواقع، يتطلب مبدأ الفعالية الذي تتطلبه المقاربات الكلاسيكية للخوارزميات (عاين الفقرة رقم 3.1)، من بين خصائص أخرى، أن يتم تنفيذ الخوارزميات دون أي لجوء إلى الحدس. بعبارة أخرى، فالآلة التي تنفذ برنامجًا لإضافة الأعداد الطبيعية لا “تفهم” أنها تجري عملية إضافة؛ في الوقت نفسه، فمعرفة أن برنامجًا ما يقوم بإجراء عملية إضافة قد يساعد المعني البشري على فهم كود البرنامج.

ووفقًا لهذا الرأي، فإن الحوسبة تنطوي على رموز، ليس إلا، بلا معانٍ. تصبح آلات تورينج معالِجات للرموز ولا يمكن ربط معنًى واحدًا بعملياتها. هنا يطرح سؤال: كيف يمكن عندئذٍ تحديد ما إذا كان برنامجان هما البرنامج نفسه، إن لم يكن من خلال معانيهما، أي بالنظر إلى الوظيفة التي يؤديانها؟ تأتي إحدى الإجابات من تحليل بيتشيني للحساب و”دلالاته الداخلية” (Piccini 2008، 2015 الفصل 3): يمكن الإقرار بأن برنامجين متطابقان من خلال تحليل بناء الجملة والعمليات التي تنفذها البرامج على رموزهما فقط. يمكن اعتبار تأثيرات العمليات على النصوص دلالات داخلية للبرنامج. يمكن تحديد الأخيرة بسهولة عن طريق عزل الإجراءات الفرعية Subroutines أو الأساليب Methods في كود البرنامج ثم استخدامها لتحديد برنامج أو لتحديد ما إذا كان هناك برنامجان متماثلان، أي عندما يتم تحديدهما بواسطة الإجراءات الفرعية نفسها.

ومع ذلك، هناك نزاع حول بعض الحالات التي لا يمكن فيها التيقن من تماثل برنامجين دون الإشارة إلى الدلالات الخارجية. يقترح سبريفاك (2010 Sprevak) عند دراسة برنامجين يقومان بإجراء عملية الإضافة سيختلفان في الحقيقة إن كان أحدهما يعمل بالأرقام العربية والآخر بالأرقام الرومانية. يؤدي البرنامجان الوظيفة نفسها، أي عملية الجمع، ولكن لا يمكن دائمًا إثبات ذلك من خلال فحص الكود والإجراءات الفرعية الخاصة به؛ بل يجب إثبات ذلك من خلال تحديد سلاسل المحتوى للمدخلات والمخرجات، وترجمة الأعداد العربية والرومانية إلى أرقام. في هذا الصدد، يؤكد انجيوس وبريميرو (2018 Angius and Primiero) أن مسألة تحديد هوية برامج الحاسب الآلي لا تختلف عن مسألة تحديد هوية الأنواع الطبيعية (Lowe 1998) والمصنوعات التقنية (Carrara et al. 2014). يمكن مقاربة المسألة من خلال تحديد معيار للهوية Identity Criterion، أي علاقة رسمية، بحيث يستوعبها أي برنامجين بغرض تعريفهما على أنهما متطابقان. يوضح انجيوس وبريميرو (2018 Angius and Primiero) كيفية استخدام العلاقة الجبرية في المحاكاة الثنائية بين الجهازين بواسطة برنامجين قيد الفحص كمعيار للهوية. تسمح المحاكاة الثنائية بإنشاء خصائص هيكلية لمطابقة البرامج التي تنفذ الوظيفة نفسها، وتوفير معايير أقل صرامة للنسخ من حيث المحاكاة. وهذا يعيد المناقشة إلى مفهوم البرامج كعمليات تنفيذ. لننتقل الآن لتحليل هذا المفهوم الأخير.

5. التنفيذ في الحاسب الآلي

غالبًا ما ترتبط كلمة “تنفيذ” بالإجراء المادي في نظام الحوسبة، أي بآلة تنفِّذ برنامج ما. ووفقًا للأنطولوجيا المزدوجة لنظم الحاسب الآلي التي نوقشت في الفقرة رقم 1.1، فإن مفهوم التنفيذ بهذا المعنى مقتصر على الأجهزة وليس على البرامج. خلافًا لذلك، باتباع مقاربة مستويات التجريد (عاين الفقرة رقم 1.2)، يصبح للتنفيذ مفهومًا أوسع كعلاقة تربط أي مستوى مجرد بالمستويات الأعلى منه في التسلسل الهرمي. وفقًا لذلك، يمكن اعتبار الخوارزمية بمثابة تنفيذ للمواصفات؛ كما يمكن تعريف البرنامج المكتوب بلغة برمجية عالية المستوى على أنه تنفيذ لخوارزمية ما (عاين الفقرة رقم 4)؛ ويمكن اعتبار تعليمات التجميع ولغة الآلة بمثابة تنفيذ لتعليمات لغة البرمجة عالية المستوى بالنسبة لهيكلة معينة من هياكل التعليمات؛ أخيرًا، عملية التشغيل هي تطبيق مادي مدرَك لتعليمات لغة الآلة تلك. على المنوال نفسه، فإن البرامج المكتوبة بلغة عالية المستوى هي تنفيذ للمواصفات أيضًا. وكما نوقش في الأنطولوجيا المزدوجة، فإن عملية التشغيل هي تنفيذ لتعليمات لغة البرمجة عالية المستوى. وفقًا لـتيرنر (2018 Turner)، حتى المواصفات يمكن فهما على أنها تنفيذ للمقاصد.

ما تبقى للفحص هنا هو طبيعة علاقة التنفيذ المحددة بهذا النحو. تحليل هذه العلاقة ضروري لتعريف مفهوم الصحة Correctness (عاين الفقرة رقم 7). في الواقع، البرنامج الصحيح يعادل التنفيذ الصحيح للخوارزمية؛ فنظام الحوسبة الصحيح ناتج عن تنفيذ صحيح لمجموعة من المواصفات. بعبارة أخرى، وفي ظل هذا الرأي، يقترن مفهوم صحة البرنامج بمفهوم التنفيذ لأي مستوى من مستويات التجريد: يمكن القول إن مستوى ما صحيح بالنسبة للمستويات العليا إذا وفقط إذا كان منفِّذًا بشكل صحيح لها.

سنناقش في الأقسام الفرعية الثلاثة التالية ثلاث تعريفات رئيسية حول علاقة التنفيذ التي طوِّرت في أدبيات فلسفة علوم الحاسب الآلي.

5.1 التنفيذ كتفسير دلالي

قَدَّمَ رابابورت أولَ تحليل فلسفي لمفهوم التنفيذ في علوم الحاسب الآلي (1999، 2005 Rapaport). إذ عرَّف التنفيذ (ت) على أنه تفسير دلالي لمجال نحوي أو مجرد (م) في وسيط التنفيذ (و). إذا كان التنفيذ يفهم على أنه علاقة بين مستوى مجرد معين وأي مستوى أعلى منه في الأنطولوجيا الهرمية للنظام الحسابي؛ يترتب على ذلك أن تعريف رابابورت يمكن أن يطبق هنا، إذاً فهو فالمستوى يقدم تفسيرًا دلاليًا للمستويات الأعلى منه في وسط تنفيذي معين. في ظل هذا الرأي، توفر المواصفات تفسيرات دلالية للمقاصد التي عبَّرت عنها الأطراف المعنية بالغة الرسمية للمواصفات، وتوفر الخوارزميات تفسيرات دلالية للمواصفات باستخدام واحدة من لغاتها العديدة التي يمكن صياغتها بـاللغات الطبيعية، أو شبه المشفرة، أو اللغات المنطقية، أو اللغات الوظيفية وما إلى ذلك، هنا يمكن أن تكون وسيلة التنفيذ مجردة أو ملموسة. برنامج الحاسب الآلي هو تنفيذ للخوارزمية حيث يوفر البرنامج تفسيرًا دلاليًا للتركيبات النحوية للخوارزمية في لغة برمجة عالية المستوى كوسيلة للتنفيذ. تفسر تعليمات البرنامج مهام الخوارزمية بلغة برمجية، كما يوفر التنفيذ في مستوى مجرد ما تفسيرًا دلاليًا لعمليات التجميع ولغة الآلة في الوسيط الذي توفره الخصائص البنائية للآلة المادية. وفقًا لتحليل رابابورت (Rapaport 1999، 2005)، فإن مفهوم التنفيذ هو علاقة غير متناظرة: إذا كان (ت) تنفيذًا لـ (أ)، فلا يمكن أن يكون (أ) تنفيذًا لـ (ت). ومع ذلك، يرى المؤلف بأن أي مستوى مجرد يمكن أن يكون مستوى نحوي ودلالي في الوقت نفسه. أي أنه يمكن أن يلعب دورَ كلٍّ من التنفيذ (ت) والمجال النحوي (أ). فعندما تفسِّر الخوارزمية دلاليًّا بواسطة برنامج مكتوب بلغة عالية المستوى، حينها توفر الخوارزمية تفسيرًا دلاليًا للمواصفات. ويترتب على ذلك أن علاقة التجريد والتنفيذ هي علاقة تزاوج بين الوظيفية والهيكلية في نظم الحاسب الآلي.

يَعتبر بريميرو (2020 Primiero) أن الجانب الأخير هذا يمثل حدًا رئيسيًا واحدًا من نظرة رابابورت (1999،2005 Rapaport) لمفهوم التنفيذ: يختزل (رابابورت) التنفيذ إلى علاقة فريدة بين المستوى النحوي وتفسيره الدلالي ولا يأخذ في الحسبان الأنطولوجيا متعددة المستويات للأنظمة الحسابية المناقشة في الفقرة رقم 1.2. من أجل توسيع التعريف الحالي للتنفيذ ليشمل جميع مستويات التجريد يجب إعادة النظر إلى كل مستوى في كل مرة، إما كمستوى نحوي أو كمستوى دلالي. وهذا بدوره له تداعيات على العقبة الثانية التي تميز، وفقًا لـبريميرو (2020 Primero)، مفهوم التنفيذ كتفسير دلالي: من ناحية، لا يأخذ هذا النهج في الاعتبار عمليات التنفيذ غير الصحيحة؛ وكذلك، بالنسبة لتطبيق غير صحيح معين، يمكن للعلاقة الفريدة المعرفة على هذا النحو أن تربط عدم الصحة Incorrectness بمستوى نحوي واحد فقط، باستثناء جميع المستويات الأخرى كمواقع أخطاء محتملة.

أما تيرنر (2018 Turner) فلم يفنِّد فكرة أن التفسير الدلالي لا يفسر مفهوم التنفيذ في حالة الخطأ فحسب، بل وحتى في حالة صحته أيضًا. يقدم مثالٌ لذلك في حالة تنفيذ لغة من داخل لغة أخرى: لغة التنفيذ هنا لا تقدم تفسيرًا دلاليًا للغة المنفَّذة، إلا إذا كانت الأولى مرتبطةً بدلالات توفر معنىً ومعايير صحة للأخيرة. ستبقى هذه الدلالات خارجية بالنسبة لعلاقة التنفيذ: رغم ارتباط الصحة بالتفسير الدلالي، إلا أن التنفيذ لا يقدم دائمًا تفسيرًا دلاليًّا. يمكن تقديم مثال آخر بدراسة رزمة مجردة Abstract Stack منفَّذة بواسطة مصفوفة Arrays؛ مرة أخرى، لا تقدم المصفوفة معايير صحة للرزمة. بل على العكس تمامًا، فالرزمة هي التي ستحدد معايير الصحة لأي عملية من عمليات التنفيذ، متضمنة في ذلك المصفوفات.

5.2 التنفيذ كعلاقة بين المواصفات والمنتج

الحقيقة أن تيرنر (2012، 2014، 2018 Turner) طرح معايير الصحة لعلاقة التنفيذ ضمن المستوى المجرد، وذلك لتعريف التنفيذ على أنه علاقة بين المواصفات والمنتج النهائي. كما نوقشت في الفقرة رقم 2، تتمتع المواصفات بسلطة معيارية على المنتجات الاصطناعية، أي أنها تحدد سلوكيات المنتجات المسموح بها. وإذا تذكرنا أن المنتجات الاصطناعية يمكن أن تكون كيانات مجردة وملموسة، وأن أي مستوى مجرد يمكن أن يلعب دور المواصفات للمستويات الأدنى منه، يؤول هذا إلى القول بأن علاقة المواصفات بالمنتج الاصطناعي قادرة على تحديد أي علاقة تنفيذ عبر أنطولوجيا المستويات المتعددة للنظم الحسابية.

اعتمادًا على كيفية تعريف علاقة المواصفات بالمنتج، يميز تيرنر (2012 Turner) بين ثلاثة مفاهيم مختلفة للتنفيذ. لنضع في اعتبارنا حالة الآلة المادية التي تنفِّذ آلة مجردة معينة. وفقًا لمفهوم التنفيذ المتعمَّد، تعمل الآلة المجردة كمواصفات للآلة المادية، بشرط أن توفر جميع المتطلبات الوظيفية التي يجب أن تفي بها الأخيرة، أي أنها تحدد، من حيث المبدأ، جميع السلوكيات المسموح بها للآلة المادية المنفِّذة. أما وفقًا لمفهوم التنفيذ الموسَّع، فإن الآلة المادية ستكون بمثابة تنفيذ صحيح للآلة المجردة، إذا وفقط إذا، كان من الممكن إنشاء حالات مماثلة للأخيرة لحالات الأولى، وأن انتقالات الآلة المجردة تتوافق مع عمليات التشغيل الفعلية (آثار تتبع التشغيل) للمنتج النهائي. أخيرًا، تتطلب الفكرة التجريبية للتنفيذ أن تعرض الآلة المادية حسابات تتطابق مع تلك الموصوفة بواسطة الآلة المجردة؛ وهذا يعني أن التنفيذ الصحيح يجب أن يقيَّم تجريبياً من خلال الاختبار.

يؤكد بريميرو (2020 Primiero) على الكيفية التي تعالِج فيها هذه المقاربة مسألة الصحة والخلل الحسابي إذ أنها تسمح بالتمييز بين التنفيذ الصحيح وغير الصحيح، إلا أنها لا تزال تحدد علاقة تنفيذ فريدة بين مستوى المواصفات ومستوى الأداة. مرة أخرى، إذا سمح لهذا الفهم بإشراك منهج أنطولوجيا المستويات عن طريق إعادة تفسير المستوى المجرد في كل مرة إما كمواصفات أو كمنتجات اصطناعية، فإن مقاربة تيرنر ستمتنع عن الإشارة إلى أكثر من مستوى واحد في حالة الخلل الحسابي: يحدث دائمًا أن تخطئ الأداة في تنفيذ المواصفات. من خلال تعريف التنفيذ كعلاقة عابرة بين المستويات المجردة، حينها يمكننا أن نحدد العديد من عمليات التنفيذ غير الصحيحة التي لا تشير مباشرة إلى المواصفات المجردة. قد يكون سبب الخلل الحسابي هو التنفيذ غير الصحيح للمستويات الأدنى والتي يتم توريثها للأعلى وصولاً إلى مستوى التشغيل.

5.3 التنفيذ في مستويات التجريد

يقترح بريميرو (2020 Primiero) تعريفاً للتنفيذ ليس كعلاقة بين مستويين ثابتين، ولكن كعلاقة عابرة بين المستويات. في ظل هذا الرأي، فإن التنفيذ (ت) هو علاقة تمثيل بين مستوى مجرد ما والمستوى الذي يعلوه في التسلسل الهرمي التجريدي. وفقًا لذلك، فإن آلة الحوسبة المادية هي عبارة عن تنفيذ لعمليات التجميع ولغة الآلة؛ وبالتعدي، يمكن اعتبارها أيضًا بمثابة تمثيل لمجموعة من التعليمات المعبّر عنها في تعليمات لغة البرمجة عالية المستوى. البرنامج المكتوب بلغة برمجية عالية المستوى هو تنفيذ لخوارزمية ما؛ ولكن يمكن اعتباره أيضًا بمثابة تمثيل لمجموعة من المواصفات.

يسمح تعريف بريميرو (2020 Primiero) للتنفيذ بتقديم تعريف عام للصحة Correctness: ​​يعتبر نظام الحوسبة المادي صحيحًا إذا وفقط إذا تميَّز بالتنفيذ الصحيح في جميع مستويات التجريد. ومن ثم فإن صحة النظام والتنفيذ مقترنان في كل المستويات. الصحة الوظيفية هي خاصية للنظام الحسابي وتعني القدرات الوظيفية التي تتطلبها مواصفات هذا النظام. أما الصحة الإجرائية فتعني القدرات الوظيفية المقصودة بواسطة الخوارزميات المنفَّذة. وتعرَّف الصحة التشغيلية على أنها خاصية لنظام قادر على تشغيل البرنامج بشكل صحيح في بنيته. يمكن أيضًا تصنيف كل شكل من أشكال الصحة هذه من الناحية الكمية، اعتمادًا على مقدار الوظائف التي تستوفى.  يقصد بالنظام الحسابي الفعال وظيفيًا بذاك الذي يعمل بأقل عدد من الوظائف للوفاء بالمواصفات؛ أما النظام الأمثل وظيفيًا فهو النظام الذي يوفر القدر الأكبر من القدرات الوظيفية. وبالمثل، يحدد المؤلف النظم الحسابية الفعالة والمثلى إجرائيًا وتنفيذيًا.

5.4 الحساب الفيزيائي في الحاسب الآلي

وفقًا لهذا التعريف، ينتقل التنفيذ من مستوى إلى مستوى: تنفَّذ الخوارزميات المحددة لنظامٍ حسابي كإجراءات في اللغات الرسمية، إما كتعليمات بلغة عالية المستوى، أو كعمليات بلغة منخفضة المستوى. السؤال المهم هو: هل أي نظام، بخلاف المنتجات الاصطناعية الحسابية، ينفِّذ مثل هذه الإجراءات يمكن أن يطلق عليه مسمى نظام حسابي؟ بعبارة أخرى، إن السؤال عن طبيعة التنفيذ المادي يؤول إلى السؤال عن ماهية النظام الحسابي، فإذا كان أي نظام ينفذ خوارزمية ما مؤهلًا ليكون نظامًا حسابيًا، فيمكن توسيع فئة هذه النظم لتشمل النظم البيولوجية، كالدماغ أو الخلية؛ والنظم الفيزيائية، بما في ذلك الكون أو أي جزء منه؛ وفي النهاية إلى أي نظام على الإطلاق، وهي أطروحة تعرف باسم الحسابية الشاملة Pancomputationalism (للحصول على نظرة عامة شاملة حول هذا الموضوع، راجع Rapaport 2018).

يقصد بالنظام الحسابي، عادةً، أنه منتج اصطناعي ميكانيكي يتلقى بيانات الإدخال، فيعالجها بطريقة حسابية وفقًا لمجموعة من التعليمات، بعدها يعيد البيانات المعالجة كمخرجات. على سبيل المثال، ينص فون نيومان (1945 von Neumann، ص 1) على أن “نظام الحوسبة الأوتوماتيكي هو جهاز (غالبًا مركب) قادر على تنفيذ التعليمات لإجراء حسابات معقدة بدرجة كبيرة”. مثل هذا التعريف غير الرسمي، والمقبول، يترك بعض الأسئلة مفتوحة: هل يجب أن تكون النظم الحسابية آلات؟، وهل يتعين عليها معالجة البيانات خوارزميًا؟، وبالتالي، هل الحسابات يجب أن تستوفي مفهوم الاكتمال عند تورينج Turing-Complete أم لا؟

يقدم رابابورت (2018 Rapaport) توصيفًا أكثر وضوحًا للنظام الحسابي، إذ يعرِّفه بأنه “تنفيذ فيزيائي معقول لأي شيء يكافئ منطقيًا آلة تورينج الشاملة Universal Turing Machine”. بالمعنى الدقيق، لا تعتبر أجهزة الحاسب الآلي الشخصية تطبيقًا فيزيائيًّا لمفهوم آلة تورينج، ولكن من المعروف أن آلات التسجيل Register Machines تكافئ آلة تورينج. لتكون النظم أنظمةً حسابية، يجب أن يكون تنفيذها معقولًا، حيث إن آلات تورينج، خلافًا للآلات المادية، لديها إمكانية الوصول إلى مساحة ذاكرة غير محدودة بدون خطأ، تمامًا كالآلات المجردة. وفقًا لتعريف رابابورت (2018 Rapaport)، إن أي تنفيذ فيزيائي من هذا النوع هو بالتالي نظام حسابي، بما في ذلك النظم الطبيعية. يثير هذا سؤالاً: أي فئة من النظم الطبيعية قادرة على تنفيذ حساباتها بما يكافئ آلة تورينج؟ في هذا الصدد، اشتهر سيرلSearle بتقريره إن أي شيء يمكن أن يكون تنفيذًا مكافئًا لآلة تورينج، أو نموذجًا منطقيًّا مكافئًا لها (سيرل 1990). ترتكز حجته على حقيقة أن آلة تورينج ما هي إلا خاصية نحوية Syntactic Property، وأن الأمر كله يتعلق بمعالجة رموز الأصفار والآحاد. وفقًا لسيرل، فإن الخصائص النحوية ليست جوهرية في النظم الفيزيائية، ولكنها تعيَّن بواسطة الراصد. بعبارة أخرى، إن الحالة المادية لنظام ما ليست في جوهرها حالة حسابية: يجب أن يكون هناك راصد، أو مستخدم، يعيِّن لتلك الحالة دورًا حسابيًا. وعليه فإن أي نظام يمكن وصف سلوكه كمعالجة نحوية للأصفار والآحاد هو نظام حسابي.

يعترض هايز (1997 Hayes) على سيرل (1990 Searle) بأنه إذا كان كل شيء نظامًا حسابيًا، فإن الخاصية “نظام حسابي” ستصبح فارغة، كما لو أن جميع الموجودات تحوزها. بالأحرى، هناك موجودات يمكن اعتبارها كأنظمة حسابية، وموجودات أخرى ليست كذلك. فالنظم الحسابية هي تلك التي تكون فيها الأنماط المستلمة كمدخلات، والتي ستحفظ في الذاكرة قادرة على تغيير نفسها. بمعنى آخر، يشير هايز إلى حقيقة أن المدخلات المخزنة يمكن أن تكون بيانات وتعليمات، وأن التعليمات، عند تشغيلها، قادرة على تعديل قيمة بعض بيانات الإدخال. “إذا كان ورقة، فسيكون “ورقة سحرية” يمكن للكتابة عليها أن تتغير تلقائيًا، أو تظهر كتابة جديدة عليها” (Hayes 1997، ص 393). فالنظم القادرة على العمل كـورقة سحرية وحدها يمكن اعتبارها حسابية.

يقدم بيتشينيني (2007، 2008 Piccinini) مقاربة مختلفة في سياق تحليله الميكانيكي للحسابات الفيزيائية (Piccinini 2015؛ انظر أيضًا مدخل “الحساب في النظم الفيزيائية” في الموسوعة). فنظام الحوسبة الفيزيائي هو نظام يمكن تفسير سلوكياته ميكانيكيًا من خلال وصف آلية الحوسبة التي تؤدي إلى تلك السلوكيات. يمكن تحديد الآليات من خلال “الكيانات والأنشطة المنظمة بحيث تكون منتجة للتغييرات المنتظمة من البداية أو من مرحلة الإعداد حتى النهاية أو عند حالة الإنهاء” (Machamer et al. 22000؛ راجع مدخل “الآليات في العلوم” في الموسوعة). يمكن فهم الحسابات فيزيائيًّا على أنها تلك الآليات التي “تولِّد من سلاسل الإدخال سلاسلَ الإخراج وفقًا للقواعد العامة التي تنطبق على جميع سلاسل الإدخال وتعتمد على المدخلات (وأحيانًا الحالات الداخلية)” (Piccinini 2007، p. 108). من السهل تحديد شروط الإعداد والإنهاء للعمليات الحسابية. فأي نظام يمكن تفسيره من خلال توصيف آلية الحوسبة الأساسية له سيعتَبر نظامًا حسابيًا. التركيز على التفسير ساعد بيتشينيني على تجنب استنتاج سيرل الذي نصَّ أن أي نظام هو نظام حسابي: حتى لو أوَّل أحدهم، مبدئيًّا، مجموعة معينة من الموجودات والأنشطة كآليات حسابية، فوجود الحاجة إلى تفسير الظاهرة الملاحَظة كآلية حسابية وحدها كفيلة بتعريف النظام قيد الفحص بأنه نظامًا حسابيًّا.

6. التحقق في الحاسب الآلي

مرحلة التحقق هي أحد أهم مراحل عملية تطوير البرامج. تتضمن هذه المرحلة عمليةَ تقييم صحة النظام الحسابي بالنسبة للمواصفات المحددة أثناء تصميمه. في الأيام الأولى لصناعة الحاسب الآلي، تضمنت طرق التحقق والتأكد من الصحة العديد من تقنيات التصميم والبناء، راجع مثلًا (Arif et al. 2018). حاليًّا، يمكن تصنيف طرق تقييم الصحة، تقريبًا، إلى مجموعتين رئيسيتين: التحقق الرسمي Formal Verification والاختبار Testing. تستخدم في التحقق الرسمي (Monin and Hinchey 2003) الأدوات الرياضية لتأكد من صحة البرنامج؛ بينما تتطلب إجراءات الاختبار تشغيل البرنامج ورصد ما إذا كان يقوم بتنفيذ عملياته وفق المواصفات المحددة أم لا (Ammann and Offutt 2008). عمليًّا، في العديد من الحالات، يستخدم مزيج من كلتا الطريقتين (راجع Callahan et al.1996).

6.1 النماذج والنظريات

تتطلب طرق التحقق الرسمية تمثيلًا للبرنامج. في المبرهنات النظرية Theorem Proving (انظر van Leeuwen 1990)، تمثَّل البرامج على أساس النظم البديهية Axiomatic Systems وقواعد الاستدلال التي تمثل الشروط السابقة واللاحقة لانتقالات البرنامج. بعدها، يتم التأكد من صحة البرنامج من خلال اشتقاق الصيغ التي تعبر عن المواصفات من البديهيات. أما في فحص النموذج (Baier and Katoen 2008)، فالبرامج تمثَّل على أساس نظام حالة الانتقال State Transition System، ويتم إضفاء الطابع الرسمي على مواصفات خصائصه من خلال صيغ المنطق الزمني (Kröger and Merz 2008)، ويتم التحقق من صحة البرنامج بواسطة خوارزمية البحث “من العمق” Depth-First التي تتحقق مما إذا كانت هذه الصيغ تتضمن نظامًا لحالة الانتقال أم لا؟

يمكن فهم النظم البديهية وأنظمة حالة الانتقال المستخدمة لتقييم صحة البرنامج على أنها نظريات للمنتجات الممثلة التي تستخدم للتنبؤ بسلوكيات البرامج المستقبلية وتفسير هذه السلوكيات. يمكن مقارنة أنظمة حالة الانتقال المنهجية في فحص النموذج بالنماذج العلمية في العلوم التجريبية (Angius and Tamburrini 2011). على سبيل المثال، تتوافق هياكل كريبكي Kripke (انظر Clarke وآخرون 1999 الفصل 2) مع تعريف سبيس (1960 Suppes) للنماذج العلمية على أنها هياكل لنظرية المجموعات التي تنشئ علاقات تخطيط مناسبة مع نماذج البيانات المحصَّلة عن طريق التجارب من الهدف في النظام التجريبي (انظر أيضًا مدخل النماذج في العلوم في الموسوعة). غالبًا ما تسمى هياكل كريبكي وغيرها من أنظمة حالة الانتقال المستخدمة في طرق التحقق الأساسية بمواصفات النظام. وهي تختلف عن المواصفات العامة، وقد تسمى أيضًا بمواصفات الخصائص Property Specifications. يحدد الأخير بعض الخصائص السلوكية المطلوبة التي يجب على البرنامج، المزمع برمجته، تمثيلها، بينما يحدد الأول، من حيث المبدأ، جميع عمليات التنفيذ المحتملة لبرنامج مبرمج فعليًّا، مما يسمح بإجراء فحص خوارزمي لنتائج تشغيله (Clarke وآخرون 1999). من أجل تحقيق هذا الهدف، تعتبر مواصفات النظام هياكل تقديرية، فهي تفترض مجموعة من عمليات التنفيذ المحتملة لنظام حسابي مستهدف على أساس الشفرة المصدرية للبرنامج وحالات انتقالاته المسموح بها (Angius 2013b). في الواقع، بمجرد التحقق مما إذا كانت بعض صيغ المنطق الزمني تتضمن هيكل كريبكي النموذجي، يختبر البرنامج الممثل تجريبياً مقابل الخاصية السلوكية المقابلة للصيغة المحددة، وذلك من أجل تقييم ما إذا كانت فرضية النموذج هي تمثيل مناسب لهدف النظام الحسابي أم لا. وفقًا لذلك، تختلف مواصفات الخصائص ومواصفات النظام أيضًا في قصديَّتهما (Turner 2011): فالأولى هي متطلبات لبرنامج سوف يبرمج لاحقًا، والأخيرة هي أوصاف (افتراضية) لبرنامج مبرمج مسبقًا. يعد الطابع الوصفي والتقديري لأنظمة حالة الانتقال في فحص النموذج ميزة إضافية وأساسية تضع أنظمة حالة الانتقال على قدم المساواة مع النماذج العلمية.

6.2 الاختبار والتجارب في الحاسب الآلي

الاختبار هو العملية الأكثر “تجريبية” لإطلاق برنامج ما ومراقبة تشغيله بهدف تقييم توافقه مع مواصفات خصائصه المعتمدة. يستخدم هذا الأسلوب على نطاق واسع في عملية تطوير البرامج. ناقش الفلاسفة وعلماء الحاسب الآلي ذوو التفكير الفلسفي هذا الأسلوب في ضوء الأساليب المنهجية التقليدية للاكتشافات العلمية (Snelting 1998؛ Gagliardi 2007 ؛ Northover وآخرون 2008 ؛ Angius 2014) متسائلين عما إذا كان من الممكن اعتبار عملية اختبار البرامج على أنها تجربة علمية تهدف لتقييم صحة البرامج أم لا؟ (Schiaffonati and Verdicchio 2014، Schiaffonati 2015؛ Tedre 2015).

إن مقولة دايكسترا Dijkstra المعروفة “يمكن استخدام عملية اختبار البرنامج للتحقق من وجود الأخطاء، ولكن ليس التيقن من غيابها تمامًا” (Dijkstra 1970 ، ص 7) هي مقولة تعبر عن مبدأ بوبر (1959 Popper) الخاص بقابلية التفنيد falsifiability في علوم الحاسب الآلي (Snelting 1998). قد يؤدي اختبار برنامج ما مقابل مواصفات خصائصه المعتمدة، لفترة زمنية محددة، إلى ظهور بعض الأخطاء، ولكن إذا لم تظهر الأخطاء عند رصد البرنامج قيد التشغيل، فلا يمكن للمرء أن يستنتج أن البرنامج صحيح Correct؛ فقد يلاحظ الخطأ التشغيلي بعد التشغيل التالي مباشرة. والسبب هو أنه لا يمكن للمختبرين تشغيل البرنامج إلا من خلال عدد محدود من المدخلات المحتملة ولفترة زمنية محدودة فقط. وفقًا لذلك، لا يمكن ملاحظة جميع عمليات التشغيل المحتملة للبرنامج المراد اختباره تجريبيًا. لهذا السبب، فإن الهدف من عملية اختبار البرامج هو اكتشاف الأخطاء وليس ضمان عدم وجودها (Ammann and Offutt 2008، ص 11). البرنامج قابل للتفنيد إذ يمكن أن تكشف الاختبارات عن الأخطاء (Northover et al.2008). ومن ثم، بالنظر للنظام الحسابي ومواصفات خصائصه، فإن الاختبار يشبه تجربة علمية تحاول، من خلال مراقبة سلوكيات النظام، وتفنيد الفرضية القائلة بأن البرنامج صحيح فيما يتعلق بالمواصفات المعنية.

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

لهذا، من بين أسباب أخرى، يجب “توسيع” المفهوم التقليدي للتجربة العلمية من أجل تطبيقه على أنشطة اختبار البرامج (Schiaffonati 2015). التجارب النظرية، التي تميز معظم العلوم التجريبية، لا تجد لها نظيرًا في الممارسة الفعلية في علوم الحاسب الآلي. فإذا استبعدنا الحالات التي تجمع بين الاختبار والطرق الرسمية، فإن معظم التجارب التي يقوم بها مهندسو البرامج تعتبر استكشافية إلى حد ما، أي تهدف إلى استكشاف “مجال الاحتمالات المتعلقة بعمل المنتج وتفاعله مع البيئة في غياب نظرية أو خلفية نظرية ملائمة” (Schiaffonati 2015: 662). غالبًا ما يفتقر مختبرو البرامج للتحكم النظري في التجارب التي يجرونها؛ فاستكشاف سلوكيات النظام الحسابي الذي يتفاعل مع المستخدمين والبيئات يسمح للمختبرين بصياغة تعميمات نظرية على السلوكيات الملاحظة. تتميز التجارب الاستكشافية في علوم الحاسب الآلي أيضًا بحقيقة أن البرامج غالبًا ما يتم اختبارها في بيئة شبيهة بالواقع حيث يلعب المختبرون دور المستخدمين. بينما يعتبر ألا يشارك المختبرون في التجربة المنفَّذة واحدة من السمات الأساسية للتجارب النظرية.

نتيجة لذلك، رغم أن بعض أنشطة اختبار البرامج أقرب إلى الأنشطة التجريبية التي نجدها في العلوم التجريبية، إلا أن بعضها يحدد نوعًا جديدًا للتجربة التي تبيَّن أنها تنتمي إلى عملية تطوير البرامج. يمكن تمييز خمسة أنواع من التجارب في عملية تحديد وتنفيذ وتقييم النظم الحسابية (Tedre 2015):

  • تجارب الجدوى: Feasibility Experiments تجرى لتقييم أداء وظائف النظام التي حددها المستخدمون والأطراف المعنية.
  • تجارب تجريبية Trial Experiments: تجرى لتقييم قدرات معزولة للنظام تحت مجموعة محددة من الشروط الأولية؛
  • التجارب الميدانية Field Experiments: تجرى في بيئات واقعية وليست محاكية.
  • تجارب المقارنة Comparison Experiments: تختبر أنظمة متشابهة، تنشأ الوظيفة نفسها بطرق مختلفة، لتقييم أي نظام سيؤدي الوظيفة المطلوبة بشكل أفضل في كل من البيئات الواقعية وشبه الواقعية.
  • التجارب المنظمة Controlled Experiments: تستخدم لتقييم الفرضيات المعتمدة حول سلوكيات اختبار النظام الحسابي، وهي الوحيدة التي تتساوى مع التجارب العلمية القائمة على النظرية، حيث تجرى على أساس بعض الفرضيات النظرية قيد التقييم.

6.3 التفسير في علوم الحاسب الآلي

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

بذلت جهود كثيرة لدراسة التفسيرات في علوم الحاسب الآلي (Piccinini 2007؛ Piccinini and Craver 2011؛ Piccinini 2015؛ Angius and Tamburrini 2016) في مقابل النماذج المختلفة للتفسيرات في فلسفة العلوم. يمكن فهم التفسير الحسابي على أنه نوع محدد من التفسيرات الميكانيكية (Glennan 1996؛ Machamer et al.2000؛ Bechtel and Abrahamsen 2005)، بالقدر الذي يمكن فيه تحليل العمليات الحسابية كعمليات ميكانيكية (Piccinini 2007؛ 2015؛ انظر أيضًا مدخل “الحساب في النظم الفيزيائية” في الموسوعة).

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

لكل نوع من أنواع الأخطاء الحسابية (عاين الفقرة رقم 7.3) هناك تفسير ميكانيكي مقابل له في مستوى مجرد ما، مع الأخذ بعين الاعتبار المواصفات التي تَصف المستوى. في الواقع، لا تزال الأوصاف المجردة للآليات تزودنا بشرح ميكانيكي في شكل مخططات لآلات، يعرَّف بأنه “وصف مجرد مختصر لآلية يمكن ملؤه بأوصاف لمكونات وأنشطة معروفة” (Machamer et al.2000، ص 15). على سبيل المثال، لنفترض الحالة الشائعة جدًا حين يخطئ الجهاز في تشغيل برنامج يحتوي على أخطاء إملائية أو تركيبية. لن تستطيع الآلة تنفيذ المتطلبات الوظيفية المنصوص عليها في مواصفات البرنامج بشكل صحيح. ومع ذلك، ولأغراض تفسيرية، سيكون من المبالغ فيه تقديم تفسير لهذه الأخطاء على المستوى المجرد للأجهزة بتقديم وصف تفصيلي لمكونات الأجهزة وتنظيمها الوظيفي. في مثل هذه الحالة، قد يكون التفسير المرضي هو تبيان أن الكود المصدري للبرنامج لم يمثل تمثيلًا صحيحًا مواصفات البرنامج المعتمدة (Angius and Tamburrini 2016). من أجل شرح الخلل الحسابي ميكانيكيًّا، سيكفي تقديم وصف للبرنامج غير الصحيح دون بقية الآلة (Piccinini and Craver 2011). للتجريد قيمة ليست في تطوير البرامج والمواصفات وحسب، بل وأيضًا في تقديم تفسير لسلوكيات النظم الحسابية.

7. الصحة في علوم الحاسب الآلي

يَفترض كلّ أسلوب من أساليب التحقق التي نوقشت في القسم السابق فهمًا مختلفًا لصحة البرنامج. اصطلاحيًّا، تفهم الصحة على أنها علاقة عقد بين التجريد وتنفيذه، بحيث يجب إثبات أن التنفيذ يفي بالخصائص التي صاغها التجريد. بمجرد وصف النظم الحسابية من خلال أنطولوجيا المستويات، إذًا يجب إعادة صياغة مفهوم الصحة باعتبارها علاقة أي مستوى هيكلي بمستواه الوظيفي (Primiero، 2020). مع ذلك، ما يزال من الممكن اعتبار الصحة كعلاقة رياضية عند صياغتها بين المستويين المجرد والوظيفي؛ واعتبارها كعلاقة تجريبية عند صياغتها بين المستويين الوظيفي والتنفيذ. بالفعل، فقد دار سابقًا نقاش حول هذا التمييز في فلسفة علوم الحاسب الآلي (De Millo et al. 1979؛ Fetzer 1988).

7.1 الصحة الرياضية

تمكِّن طرق التحقق الرسمية تحليلًا مسبقًا لسلوكيات البرامج، دون الحاجة إلى مراقبة تنفيذها أو ملاحظة تشغيلها. فالمبرهنات النظرية Theorem Proving تمكِّن استنتاج سلوك والخصائص السلوكية المحتملة للبرنامج من خلال التمثيل البديهي الملائم. أما في حالة التحقق بواسطة النموذج، سيعرف المختَبِر مسبقًا الخصائص السلوكية المتوقع تلقيها عند تشغيل البرنامج، وذلك بإجراء بحث حسابي لصيغ صالحة من نماذج نظرية المجموعات لكل نموذج على حدة. استنتج هور (1969 Hoare) من هذه الاعتبارات إن عملية تطوير البرامج هو “علم دقيق”، لكونها تتميز، من الناحية المعرفية، ببراهين رياضية تمامًا كما في البراهين القياسية في ممارسات علم الرياضيات.

تساءل دي ميلو وآخرون (1979 De Millo et al.) حول أطروحة هور: البراهين الرياضية الصحيحة عادة ما تكون أنيقة (بساطة نحويًّا) وسهلة الفهم، مما يعني أن أي قارئ (خبير) يمكنه “رؤية” أن الاستنتاج انساب من المقدمات المنطقية (لمراجعة مفهوم الأناقة في مجال البرمجيات، انظر Hill 2018). أما ما يطلق عليها، غالبًا، بالبراهين الديكارتية (Hacking 2014) فليس لها نظير في برهنة صحة البرامج، التي عادةً ما تكون طويلةً ومعقدة، ويصعب فهمها ولا تفسر بالضرورة سبب استنتاجها من المقدمات المنطقية. ورغم أن العديد من البراهين الرياضية طويلة ومعقدة، إلا أنها من حيث المبدأ قابلة للتتبع، وذلك بفضل الليمات lemmas، التي وفرت تجريدًا وبناءً تحليليًّا للمفاهيم الجديدة يقود خطوة بخطوة إلى البيان المراد إثباته. وعلى النقيض، فبراهين الصحة لا تتضمن إنشاء مفاهيم جديدة، ولا تستخدم النهج التجميعي Modularity المستخدم عادة في البراهين الرياضية (Turner، 2018). لهذا لا يمكن اعتبار البراهين غير القابلة للمراقبة براهين رياضية (Wittgenstein 1956).

تتعلق الصعوبة النظرية الثانية بالنسبة لإثبات صحة برامج الحاسب الآلي بتعقيدها وتعقيد البرامج المراد التحقق منها. بالفعل، اعترف هور (1981 Hoare) إن التحقق من الصحة ممكنٌ من حيث المبدأ، إلا أنه من الناحية العملية يصعب تحقيقه. باستثناء الحالات البسيطة منه، إذ أن البرامج المعاصرة تبرمَج بواسطة الوحدات Modules، وعليها أن تفي بعدد كبير من المواصفات، وتطوَّر للتفاعل مع البرامج والنظم والمستخدمين الآخرين. البرامج المضمَّنة والتفاعلية هي أمثلة لهذه الحالة. من أجل التحقق من صحة هذه البرامج المعقدة، تجرى اختبارات الصحة تلقائيًا. ثم من ناحية أخرى، تنتقل مشكلة الصحة من البرنامج قيد الفحص إلى البرنامج الذي يقوم بعملية التحقق التلقائي كالمبرهن النظري Theorem Prover. ومن ناحية ثالثة، قد يفشل التحقق الذي يجرى بالعمليات المادية بسبب الأخطاء الميكانيكية في الآلة. في مقابل حجة الانتكاس اللانهائي هذه، يجادل كلاً من اركوداس وبرينجزجورد (2007 Arkoudas and Bringsjord) بأنه من الممكن الاستفادة من مدقق (تلقائي) يسهل التحقق منه لكونها، عادةً، برامج صغيرة نسبيًا.

في الآونة الأخيرة، أعطت الطرق الرسمية لتفحص الصحة المستندة إلى مزيج من التحليل المنطقي والإحصائي حافزًا جديدًا في هذا المجال من البحث: فقدرة منطق الفصل Separation logic (2002 Reynolds) على تقديم تمثيل للسلوك المنطقي للذاكرة المادية للأنظمة الحسابية، وإمكانية التدقيق في التوزيعات الاحتمالية للمدخلات كمصدر إحصائي للأخطاء، مكَّنت من إجراء فحص رسمي لصحة النظم التفاعلية الكبيرة، كمنصة فيسبوك Facebook (انظر أيضًا Pym et al. 2019).

7.2 الصحة المادية

اعترض فيتزر (1988 Fetzer) على ذلك، وحَصَرَ قدرة الاستدلال الاستنتاجي في ضمان صحة البرنامج بالنظر إلى مواصفاته، دون ضمان صحة النظام الحسابي ككل، وهذا يعني أيضًا عدم ضمان صحة التنفيذ المادي للبرنامج. حتى إن كان البرنامج صحيحًا فيما يتعلق بأي مستوى من مستوياته المجردة العليا (الخوارزميات والمواصفات والمتطلبات)، فإن تنفيذه ما يزال يمكن أن ينتهك واحدًا أو أكثر من المواصفات المبتغاة بسبب أي عطل مادي. مبدئيًّا، يمكننا التحقق رياضيًا من الصحة الرياضية، لكن التحقق من صحة تشغيل مستوى مجرد ما سيتطلب تقييمًا تجريبيًا. كما نوقش في الفقرة رقم 6.2، يمكن لاختبار البرامج، نظريًّا فقط، أن يتحقق من صحة النظام الحسابي، ولكن عمليًّا، من المحتمل أن يكون عدد عمليات التشغيل المسموح بها للأنظمة غير البسيطة Non-Trivial غير محدودة ولا يمكن التحقق منها بشكل شامل في فترة زمنية محدودة (أو معقولة) (Dijkstra 1974). معظم أساليب الاختبار الناجحة ترى الجمع بين التحقق الرسمي والاختبار هو السبيل إلى الوصول إلى مستوى مرضٍ من التحقق من صحة النظام.

هناك اعتراض آخر على الاحتمال النظري للصحة الرياضية، وهو أنه نظرًا لأن التحقق ينفذ بواسطة مبرهن نظري Theorem Prover، أي آلة فيزيائية، فإن المعرفة التي يكتسبها المرء عن النظم الحسابية ليست بديهية A-Priori، بل تجريبية (انظر Turner 2018 الفصل 25). ومع ذلك، يجادل برج (1988 Burge) بأنه ما يزال من الممكن اعتبار براهين الصحة الحسابية على أنها بديهية، فعلى الرغم من أن احتمالها يعتمد على التجربة الحسية، إلا أن تبريرها ليس كذلك، تمامًا كما هو الحال بالنسبة للمعرفة الاستدلالية A-Posteriori. فمعرفة أن اللون الأحمر هو لونٌ تعتبر معرفةٌ بديهية على الرغم من أنها تتطلب خبرة حسية باللون الأحمر؛ هذا لأن عبارة “الأحمر هو لون” هي عبارة صحيحة بشكل مستقل عن أي تجربة حسية. لمزيد من المناقشة حول طبيعة استخدام الحاسب الآلي في البراهين الرياضية، انظر (Hales 2008؛ Harrison 2008؛ Tymoczko 1979، 1980).

تختصر مشكلة الصحة في النهاية إلى السؤال عما يعنيه أن تفي آلة فيزيائية ما بالمتطلبات المجردة. وفقًا لفكرة التعيين البسيط Simple Mapping، يعد النظام الحسابي (ن) تطبيقًا صحيحًا للمواصفات (م) فقط إذا:

  1. كان يمكن إنشاء اقتران من حالات (ن) إلى حالات (م)، و
  2. لأي انتقال حالة ح1 -> ح2 في (ن) هناك انتقال حالة ح‘1 -> ح‘2 في (م) بحيث تعيَّن ح‘1 إلى ح1، و ح‘2 إلى ح2.

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

قادت فكرة الحسابية الشاملة إلى محاولة بعض المؤلفين تفسير التنفيذ الصحيح بطرق تقيد التفسيرات الممكنة. بالتحديد في الحالات التالية:

  1. يشير التفسير السببي إلى أن الشرط المادي The Material Conditional (إذا كان النظام في الحالة المادية ح1 …) يستبدل بشرط غير واقعي Counterfactual. (D.J Chalmers 1996؛ Copeland 1996)
  2. يجادل التفسير الدلالي Semanticبأن النظام الحسابي يجب أن يرتبط بالوصف الدلالي، مع تحديد ما يجب على النظام تحقيقه (Sprevak 2012). على سبيل المثال، يمكن للجهاز المادي أن يفسَّر على أنه بوابة “و” (AND) أو بوابة “أو” (OR) ولكن بدون تعريف للجهاز، فلا توجد هناك طريقة لتحديد ماهية الجهاز المادي.
  3. يتطلب التفسير النحوي Syntactic أن، وحدها، الحالات المادية التي يمكن تعريفها نحويًا يمكن أن اعتبارها حالات الحسابية. ما تبقى للتمعن هو كيفية تعريف الحالة النحوية (راجع Piccinini 2015، أو مدخل “الحساب في النظم الفيزيائية” في الموسوعة لإلقاء نظرة عامة على التفسير النحوي).
  4. يتمسك التفسير المعياري Normative (Turner 2012) ليس فقط بفكرة وجوب توافق العمليات الحسابية المجردة والمادية، بل وأيضًا أن للمواصفات المجردة سلطة معيارية على النظام. وفقًا لمثل هذا التفسير، فإن العمليات الحسابية هي عمليات فيزيائية تحدد وظيفتها بواسطة مواصفات مجردة. هذه العلاقة أقوى مما في التفسير الدلالي الذي يتطلب علاقة وصفية بسيطة، وكذلك مما في التفسير النحوي الذي يركز على الموضوع النحوي وتفسيره الدلالي.

7.3 الخلل الحسابي في الحاسب الآلي

من أعلاه، يترتب على ذلك أن صحة البرامج المنفذة لا تعني بالضرورة جودة النظام الحسابي. ميَّزَ تورينج (1950 Turing) بالفعل بين أخطاء الأداء وأخطاء الإنجاز. خطأ الأداء هو تنفيذ خاطئ غير قادر على تشغيل تعليمات بعض لغات البرمجة عالية المستوى، أما خطأ الإنجاز تتصف به الآلات المجردة الصحيحة التي تفشل في تنفيذ المهام المفترض انجازها. قد يحدث ذلك في الحالات التي يقوم فيها البرنامج بتمثيل، بشكل صحيح، بعض المواصفات التي لا تعبر عن متطلبات المستخدمين. في كلتا الحالتين، ما يزال من الممكن القول بأن الآلات التي تنفذ البرامج بشكل صحيح بها خلل حسابي.

وسع تمييز تورينج بين أخطاء الأداء وأخطاء الإنجاز إلى تصنيف كامل للأخطاء الحسابية (Fresco and Primiero 2013). وضع التصنيف على أساس مستويات التجريد المختلفة التي تعرِّف النظم الحسابية. وعليه، يمكن أن تكون الأخطاء:

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

تنشأ الأخطاء التنفيذية في مستوى التشغيل فقط، وهي تتوافق مع خطأ الأداء لدى تورينج (1950 Turing)، والذي يطلق عليها، أيضًا، بالأعطال التشغيلية. قد تنشأ الأخطاء المفاهيمية والمادية على أي مستوى من مستويات التجريد: من مستوى المقاصد حتى مستوى التنفيذ المادي. تؤدي الأخطاء المفاهيمية إلى حدوث الأخطاء Mistakes، بينما تؤدي الأخطاء المادية إلى الفشل Failures. على سبيل المثال، ينشأ الخطأ على مستوى المقاصد عندما تكون هناك مجموعة غير متسقة من المتطلبات، بينما على مستوى التنفيذ المادي قد يحدث بسبب تصميم مادي غير صالح (كما هو الحال في حالة الاختيار الخاطئ للبوابات المنطقية في روابط دوال الصواب Truth-Functional Connectives). قد تكون الأخطاء التي تحدث على مستوى المواصفات ناتجة عن تصميم غير مكتمل بالنسبة للمتطلبات الوظيفية المرغوبة، بينما يحدث الفشل على مستوى الخوارزمية في الحالات المتكررة التي يعثر فيها على خوارزمية لم تفِ بالمواصفات المطلوبة. بالإضافة إلى الأخطاء والفشل والأعطال التشغيلية، تعتبر الأخطاء الطباعية مصدرًا للأخطاء في الحسابات، وذلك على مستوى تعليمات لغة البرمجة عالية المستوى: قد تنشأ الأخطاء المفاهيمية أو المادية، على التوالي، بسبب خطئٍ نحوي أو دلالي. تظهر الأخطاء الطباعية المفاهيمية في جميع الحالات التي تنتهك فيها القواعد النحوية للغات البرمجة عالية المستوى؛ أما الأخطاء الطباعية المادية فتنطوي على انتهاك للقواعد الدلالية للغات البرمجة، مثلًا: حين يستخدام متغير قبل تهيئته Initialized.

يجب أن نميِّز بين الخلل الوظيفي وسوء الأداء في برامج النظم الحسابية (Floridi و Fresco و Primiero 2015). فالبرنامج يمكن أن يؤدي بشكل خاطئ (سوء أداء) دون أن يختل وظيفيًا. يمكننا أن نقول إن رمز البرنامج به خللٌ وظيفي إذا فشل تنفيذه المادي في تلبية المقاصد أو المواصفات. لا تنطبق الاختلالات الوظيفية إلا على الرموز Software Tokens المنفردة نظرًا لأن اختلال الرمز لا يسلك سلوك الرموز الأخرى من النمط نفسه بالنسبة للوظائف المنفذة. لهذا السبب، لا تنطبق الاختلالات الوظيفية على مستويي المقاصد والمواصفات. على العكس من ذلك، يمكن أن يحدث سوء الأداء في كلٍ من أنماط البرامج Software Types ورموزها، لأن الاختلالات الأدائية لا تعتمد على المقارنات بين الرموز من النمط نفسه، ولا على قدرتها على أداء بعض الوظائف. عادة ما يعتمد الخلل الأدائي في عمل الرموز على خلل وظيفي في بعض المكونات الأخرى، في حين أن الخلل في الأنماط غالبًا ما يكون بسبب التصميم السيئ. لا يمكن أن يحدث الخلل في رمز البرنامج، لأن جميع الرموز لنمط معين ستنفذ وظائف محددة بشكل موحد في مستويي المقاصد والمواصفات. وتنفذ هذه الوظائف في مستوى الخوارزميات قبل تنفيذها في مستوى التشغيل؛ في حالة التنفيذ الصحيح، ستتصرف جميع الرموز بشكل صحيح في مستوى التشغيل (بشرط عدم حدوث عطل تشغيلي). للسبب نفسه، لا يمكن لرموز البرامج أن تعمل بشكل خاطئ، لأنها تطبيقات للمقاصد وللمواصفات نفسها. يمكن لأنماط البرامج أن يكون بها خللٌ أدائي، فقط، في حالة سوء التصميم؛ أنماط البرامج التي تعاني من خلل في الأداء قادرة على أداء وظائفها بشكل صحيح، ولكنها قد تنتج أيضًا بعض الآثار الجانبية غير المرغوب فيها. لمعرفة تطبيق مفهوم العطل Malfunctioning في مسألة تصنيف البرامج الضارة Malware، راجع (Primiero et al. 2019).

8. الوضع المعرفي لـ علوم الحاسب الآلي

بين ستينيات وسبعينيات القرن الماضي، برز تخصص “علوم الحاسب الآلي” كفرع أكاديمي مستقل عن الرياضيات والفيزياء، وبرزت معه مشكلة تحديد وضعه المعرفي بسبب تأثره بالطرق الرياضية والتجريبية والهندسية (Tedre and Sutien 2008، Tedre 2011، Tedre 2015، Primiero 2020). ما يزال الجدل قائمًا حتى اليوم بشأن ما إذا كان يجب اعتبار مجمل علوم الحاسب الآلي كتخصص رياضي أو اعتبارها فرعًا من فروع الهندسة أو فرعًا من التخصصات العلمية.

8.1 علوم الحاسب كتخصص رياضي

يعتمد أي توصيف معرفي لعلوم الحاسب الآلي على الارتباطات الوجودية والمنهجية والمعرفية، أي على الافتراضات المتعلقة بطبيعة النظم الحسابية، والأساليب التي توجه عملية تطوير البرامج، ونوع المنطق بها، سواءً كان استنتاجيًا، أو استقرائيًا، أو مزيج من الاثنين (2007 Eden).

إن أصل التحليل الحسابي هو مفهوم رياضي مشتق بشكل ملاحظ من المنطق، مع تساؤل هيلبرت (Hilbert and Ackermann 1950) المتعلق بمشكلة القرار Entschiedungsproblem : هل يمكن لإجراء ميكانيكي أن يصدر حكمًا حول قابلية اثبات جملة منطقية اعتباطية؟ لمعالجة هذا التساؤل، مطلوب إيجاد نموذج دقيق لمفهوم غير رسمي يحدد ما معنى الطريقة الفعالة أو الميكانيكية في المنطق والرياضيات. هذه المسألة، أولاً وقبل كل شيء هي مسألة رياضية: علينا تحديد هذا المفهوم الرياضي غير الرسمي بدقة. يفترض مؤيدو وجهة النظر القائلة بأن علوم الحاسب الآلي ذات طبيعة رياضية أن برنامج الحاسب الآلي يمكن اعتباره تجسيدًا ماديًا لمثل هذا الكيان الرياضي وأنه يمكن للمرء أن يفكر في البرامج بشكل استنتاجي من خلال الأساليب النظرية الرسمية لعلوم الحاسب الآلي. كان دايكسترا (1974 Dijkstra) وهور (1986 Hoare) واضحين جدًا في اعتبار تعليمات البرامج على أنها جمل رياضية، واعتبار الدلالات الرسمية للغات البرمجة نظمًا بديهيةً (Hoare 1969). كما يمكن للدلالات الرسمية أن توفر وسائلَ إثبات صحتها، شريطة أن تقدم مواصفات البرنامج وتعليماته باللغة الرسمية نفسها. وفقًا لذلك، تكتسب المعرفة حول سلوكيات النظم الحسابية من خلال المنطق الاستنتاجي المتضمن في البراهين الرياضية للصحة. إن أساس هذا التفاؤل العقلاني (Eden 2007) حول ما يمكن معرفته عن النظم الحسابية هو بسبب كونها منتجات اصطناعية، أي أنظمة من صنع الإنسان، وعلى هذا النحو، يمكن للمرء أن يتنبأ بسلوكياتها على وجه اليقين (Knuth 1974).

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

8.2 علوم الحاسب كتخصص هندسي

في أواخر السبعينيات، تسبب العدد المتزايد من تطبيقات النظم الحسابية في السياقات اليومية، وما أعقب ذلك من ازدهار في طلبات السوق، في تغير اهتمام علماء الحاسب الآلي في الأوساط الأكاديمية وفي الصناعة: من التركيز على أساليب إثبات صحة البرامج إلى أساليب إدارة التعقيد وتقييم موثوقية تلك النظم (Wegner 1976). في الواقع، في النظم المتسمة بالتعقيد والمتضمنة في أنظمة أكبر والمتفاعلة مع المستخدمين، يعتبر التعبير رسميًا عن مواصفاتها وبنيتها ومدخلاتها أمر مستحيل عمليًا، لذا يصبح تقديم البراهين الرياضية على صحتها أمرًا غير ممكن في الغالب. دفعت أبحاث علوم الحاسب الآلي التطوير في اتجاه تقنيات الاختبار القادرة على توفير تقييم إحصائي للصحة، متعلق بتوزيعات الخطأ في كود البرنامج، غالبًا ما يسمى بالموثوقية (Littlewood وStrigini 2000).

تمشيًا مع هذا الفهم الهندسي لعلوم الحاسب الآلي، فإن الأطروحة تقر بأن موثوقية النظم الحسابية يمكن تقييمها بالطريقة نفسها التي تقيَّم بها الجسور في الهندسة المدنية، والطائرات في هندسة الطيران (DeMillo et al. 1979). تحديدًا، بينما تدرس العلوم التجريبية “ما هو موجود“، يركز علم الحاسب الآلي على “ما يمكن إيجاده“، أي كيفية إنتاج المنتج الاصطناعي، وبالتالي يجب الاعتراف بها على أنها “هندسة رياضيات” (Hartmanis 1981). وبالمثل، في حين أن الاستقصاءات العلمية معنية في اكتشاف القوانين المتعلقة بالظواهر الخاضعة للمراقبة، إلا أنه لا يمكن للمرء تحديد القوانين الملائمة في ممارسة علوم الحاسب الآلي، طالما أنها معنية بإنتاج الظواهر المتعلقة بالمنتجات الحسابية (Brooks 1996).

8.3 علوم الحاسب كتخصص علمي

كما نوقش في الفقرة رقم 6، نظرًا لأن أساليب اختبار البرامج وقياس الموثوقية معروفة، غالبًا، بعدم قدرتها على ضمان عدم وجود أخطاء في الكود المصدري (Dijkstra 1970)، وخاصة عند تقييم ما يسمى بأنظمة السلامة الحرجة (كأجهزة التحكم في الطائرات والصواريخ والمحطات النووية وما إلى ذلك)، يستخدم مزيج من الأساليب الرسمية والاختبارات التجريبية لتقييم الصحة والموثوقية. بناءً على ذلك، يمكن فهم علم الحاسب الآلي على أنه تخصص علمي، نظرًا لاستخدامه لكلا المنطقين الاحتماليين: الاستنتاجي والاستقرائي في فحص النظم الحسابية (Denning et al. 1981، 2005، 2007؛ Tichy 1998؛ Colburn 2000).

تعود الفرضية القائلة بأن علوم الحاسب الآلي، من وجهة نظر منهجية، مماثلة للعلوم التجريبية إلى رسالة نيويل وبيرليس وسيمون عام 1967 إلى مجتمع العلوم (Newell et al. 1967)، الرسالة التي سادت في ثمانينيات القرن الماضي (Wegner 1976). في محاضرة جائزة تورينج لعام 1975، دافع نيويل وسيمون عن فكرتهما:

"علم الحاسب الآلي هو تخصص تجريبي. كنا سنطلق عليه علمًا تجريبيًا، كعلم الفلك والاقتصاد والجيولوجيا، لكن بعض أشكاله الفريدة من الملاحظة والتجريب لا تتناسب مع الصورة النمطية الضيقة للطريقة التجريبية. ومع ذلك، فهي تجارب. كل آلة جديدة تبنى بمثابة تجربة. بالفعل، كل عملية بناء لآلة هي سؤال يطرح على الطبيعة؛ ونحن نتلقى إجابتها بواسطة ملاحظتنا للآلة حين تشغيلها، وعبر تحليلنا لها بكل وسائل التحليل والقياس المتاحة" (Newell and Simon 1975، p. 114).

منذ تلك المحاضرة، كان من الواضح أن علوم الحاسب الآلي يمكن فهمها على أنها علم تجريبي، ولكن من نوع خاص، وهذا مرتبط بطبيعة التجارب في الحوسبة. في الواقع، يتعلق الكثير من الجدل الحالي حول الحالة المعرفية لعلوم الحاسب الآلي بمسألة تحديد نوع العلم (Tedre 2011، Tedre 2015) ، وتحديد طبيعة التجارب في علوم الحاسب الآلي (Schiaffonati and Verdicchio 2014)، وكذلك تحديد طبيعة القوانين والنظريات في الحوسبة، إن وجدت (Hartmanis 1993 ؛ Rombach and Seelish 2008)، وأخيرًا، تحديد العلاقة المنهجية بين علوم الحاسب الآلي وهندسة البرامج (Gruner 2011).


المراجع

  • Abramsky, Samson & Guy McCusker, 1995, “Games and Full Abstraction for the Lazy λλ-Calculus”, in D. Kozen (ed.), Tenth Annual IEEEE Symposium on Logic in Computer Science, IEEE Computer Society Press, pp. 234–43. doi:10.1109/LICS.1995.523259
  • Abramsky, Samson, Pasquale Malacaria, & Radha Jagadeesan, 1994, “Full Abstraction for PCF”, in M. Hagiya & J.C. Mitchell (eds.), Theoretical Aspects of Computer Software: International Symposium TACS ‘94, Sendai, Japan, April 19–22, 1994, Springer-Verlag, pp. 1–15.
  • Abrial, Jean-Raymond, 1996, The B-Book: Assigning Programs to Meanings, Cambridge: Cambridge University Press.
  • Alama, Jesse, 2015, “The Lambda Calculus”, The Stanford Encyclopedia of Philosophy (Spring 2015 Edition), Edward N. Zalta (ed.), URL = <https://plato.stanford.edu/archives/ spr2015/entries/lambda-calculus/>.
  • Allen, Robert J., 1997, A Formal Approach to Software Architecture, Ph.D. Thesis, Computer Science, Carnegie Mellon University. Issued as CMU Technical Report CMU-CS-97-144. Allen 1997 available on line
  • Ammann, Paul & Jeff Offutt, 2008, Introduction to Software Testing, Cambridge: Cambridge University Press.
  • Angius, Nicola, 2013a, “Abstraction and Idealization in the Formal Verification of Software”, Minds and Machines, 23(2): 211–226. doi:10.1007/s11023-012-9289-8
  • –––, 2013b, “Model-Based Abductive Reasoning in Automated Software Testing”, Logic Journal of IGPL, 21(6): 931–942. doi:10.1093/jigpal/jzt006
  • –––, 2014, “The Problem of Justification of Empirical Hypotheses in Software Testing”, Philosophy & Technology, 27(3): 423–439. doi:10.1007/s13347-014-0159-6
  • Angius, N., & Primiero, G., 2018, “The logic of identity and copy for computational artefacts”, Journal of Logic and Computation, 28(6): 1293–1322.
  • Angius, Nicola & Guglielmo Tamburrini, 2011, “Scientific Theories of Computational Systems in Model Checking”, Minds and Machines, 21(2): 323–336. doi:10.1007/s11023-011-9231-5
  • –––, 2017, “Explaining engineered computing systems’ behaviour: the role of abstraction and idealization”, Philosophy & Technology, 30(2): 239–258.
  • Anscombe, G. E. M., 1963, Intention, second edition, Oxford: Blackwell.
  • Arkoudas, Konstantine & Selmer Bringsjord, 2007, “Computers, Justification, and Mathematical Knowledge”, Minds and Machines, 17(2): 185–202. doi:10.1007/s11023-007-9063-5
  • Arif, R. Mori, E., and Primiero, G, 2018, “Validity and Correctness before the OS: the case of LEOI and LEOII”, in Liesbeth de Mol, Giuseppe Primiero (eds.), Reflections on Programmings Systems – Historical and Philosophical Aspects, Philosophical Studies Series, Cham: Springer, pp. 15–47.
  • Ashenhurst, Robert L. (ed.), 1989, “Letters in the ACM Forum”, Communications of the ACM, 32(3): 287. doi:10.1145/62065.315925
  • Baier, A., 1970, “Act and Intent”, Journal of Philosophy, 67: 648–658.
  • Baier, Christel & Joost-Pieter Katoen, 2008, Principles of Model Checking, Cambridge, MA: The MIT Press.
  • Bass, Len, Paul C. Clements, & Rick Kazman, 2003 [1997], Software Architecture in Practice, second edition, Reading, MA: Addison-Wesley; first edition 1997; third edition, 2012.
  • Bechtel, William & Adele Abrahamsen, 2005, “Explanation: A Mechanist Alternative”, Studies in History and Philosophy of Science Part C: Studies in History and Philosophy of Biological and Biomedical Sciences, 36(2): 421–441. doi:10.1016/j.shpsc.2005.03.010
  • Boghossian, Paul A., 1989, “The Rule-following Considerations”, Mind, 98(392): 507–549. doi:10.1093/mind/XCVIII.392.507
  • Bourbaki, Nicolas, 1968, Theory of Sets, Ettore Majorana International Science Series, Paris: Hermann.
  • Bratman, M. E., 1987, Intention, Plans, and Practical Reason, Cambridge, MA: Harvard University Press.
  • Bridges, Douglas & Palmgren Erik, 2013, “Constructive Mathematics”, The Stanford Encyclopedia of Philosophy (Winter 2013 Edition), Edward N. Zalta (ed.), URL = <https://plato.stanford.edu/archives/ win2013/entries/mathematics-constructive/>.
  • Brooks, Frederick P. Jr., 1995, The Mythical Man Month: Essays on Software Engineering, Anniversary Edition, Reading, MA: Addison-Wesley.
  • –––, 1996, “The Computer Scientist as Toolsmith II”, Communications of the ACM, 39(3): 61–68. doi:10.1145/227234.227243
  • Burge, Tyler, 1998, “Computer Proof, Apriori Knowledge, and Other Minds”, Noûs, 32(S12): 1–37. doi:10.1111/0029-4624.32.s12.1
  • Bynum, Terrell Ward, 2008, “Milestones in the History of Information and Computer Ethics”, in Himma and Tavani 2008: 25–48. doi:10.1002/9780470281819.ch2
  • Callahan, John, Francis Schneider, & Steve Easterbrook, 1996, “Automated Software Testing Using Model-Checking”, in Proceeding Spin Workshop, J.C. Gregoire, G.J. Holzmann and D. Peled (eds.), New Brunswick, NJ: Rutgers University, pp. 118–127.
  • Cardelli, Luca & Peter Wegner, 1985, “On Understanding Types, Data Abstraction, and Polymorphism”, 17(4): 471–522. [Cardelli and Wegner 1985 available online]
  • Carnap, R., 1966, Philosophical foundations of physics (Vol. 966), New York: Basic Books.
  • Carrara, M., Gaio, S., and Soavi, M., 2014, “Artifact kinds, identity criteria, and logical adequacy”, in M. Franssen, P. Kroes, T. Reydon and P. E. Vermaas (eds.), Artefact Kinds: Ontology and The Human-made World, New York: Springer, pp. 85–101.
  • Chalmers, A. F., 1999, What is this thing called Science?, Maidenhead: Open University Press
  • Chalmers, David J., 1996, “Does a Rock Implement Every Finite-State Automaton?” Synthese, 108(3): 309–33. [D.J. Chalmers 1996 available online] doi:10.1007/BF00413692
  • Clarke, Edmund M. Jr., Orna Grumberg, & Doron A. Peled, 1999, Model Checking, Cambridge, MA: The MIT Press.
  • Colburn, Timothy R., 1999, “Software, Abstraction, and Ontology”, The Monist, 82(1): 3–19. doi:10.5840/monist19998215
  • –––, 2000, Philosophy and Computer Science, Armonk, NY: M.E. Sharp.
  • Colburn, T. R., Fetzer, J. H. , and Rankin T. L., 1993, Program Verification: Fundamental Issues in Computer Science, Dordrecht: Kluwer Academic Publishers.
  • Colburn, Timothy & Gary Shute, 2007, “Abstraction in Computer Science”, Minds and Machines, 17(2): 169–184. doi:10.1007/s11023-007-9061-7
  • Copeland, B. Jack, 1993, Artificial Intelligence: A Philosophical Introduction, San Francisco: John Wiley & Sons.
  • –––, 1996, “What is Computation?” Synthese, 108(3): 335–359. doi:10.1007/BF00413693
  • –––, 2015, “The Church-Turing Thesis”, The Stanford Encyclopedia of Philosophy (Summer 2015 Edition), Edward N. Zalta (ed.), URL = <https://plato.stanford.edu/archives/ sum2015/entries/church-turing/>.
  • Copeland, B. Jack & Oron Shagrir, 2007, “Physical Computation: How General are Gandy’s Principles for Mechanisms?” Minds and Machines, 17(2): 217–231. doi:10.1007/s11023-007-9058-2
  • –––, 2011, “Do Accelerating Turing Machines Compute the Uncomputable?” Minds and Machines, 21(2): 221–239. doi:10.1007/s11023-011-9238-y
  • Cummins, Robert, 1975, “Functional Analysis”, The Journal of Philosophy, 72(20): 741–765. doi:10.2307/2024640
  • Davidson, D., 1963, “Actions, Reasons, and Causes,” reprinted in Essays on Actions and Events, Oxford: Oxford University Press, 1980, pp. 3–20.
  • –––, 1978, “Intending”, reprinted in Essays on Actions and Events, Oxford: Oxford University Press, 1980, pp. 83–102.
  • De Millo, Richard A., Richard J. Lipton, & Alan J. Perlis, 1979, “Social Processes and Proofs of Theorems and Programs”, Communications of the ACM, 22(5): 271–281. doi:10.1145/359104.359106
  • Denning, Peter J., 2005, “Is Computer Science Science?”, Communications of the ACM, 48(4): 27–31. doi:10.1145/1053291.1053309
  • –––, 2007, “Computing is a Natural Science”, Communications of the ACM, 50(7): 13–18. doi:10.1145/1272516.1272529
  • Denning, Peter J., Edward A. Feigenbaum, Paul Gilmore, Anthony C. Hearn, Robert W. Ritchie, & Joseph F. Traub, 1981, “A Discipline in Crisis”, Communications of the ACM, 24(6): 370–374. doi:10.1145/358669.358682
  • Devlin, Keith, 1994, Mathematics: The Science of Patterns: The Search for Order in Life, Mind, and the Universe, New York: Henry Holt.
  • Dijkstra, Edsger W., 1970, Notes on Structured Programming, T.H.-Report 70-WSK-03, Mathematics Technological University Eindhoven, The Netherlands. [Dijkstra 1970 available online]
  • –––, 1974, “Programming as a Discipline of Mathematical Nature”, American Mathematical Monthly, 81(6): 608–612. [Dijkstra 1974 available online
  • Distributed Software Engineering, 1997, The Darwin Language, Department of Computing, Imperial College of Science, Technology and Medicine, London. [Darwin language 1997 available online]
  • Duhem, P., 1954, The Aim and Structure of Physical Theory, Princeton: Princeton University Press.
  • Duijf, H., Broersen, J., and Meyer, J. J. C., 2019, “Conflicting intentions: rectifying the consistency requirements”, Philosophical Studies, 176(4): 1097–1118.
  • Dummett, Michael A.E., 2006, Thought and Reality, Oxford: Oxford University Press.
  • Duncan, William, 2011, “Using Ontological Dependence to Distinguish between Hardware and Software”, Proceedings of the Society for the Study of Artificial Intelligence and Simulation of Behavior Conference: Computing and Philosophy, University of York, York, UK. [Duncan 2011 available online (zip file)]
  • –––, 2017, “Ontological Distinctions between Hardware and Software”, Applied Ontology, 12(1): 5–32.
  • Eden, Amnon H., 2007, “Three Paradigms of Computer Science”, Minds and Machines, 17(2): 135–167. doi:10.1007/s11023-007-9060-8
  • Egan, Frances, 1992, “Individualism, Computation, and Perceptual Content”, Mind, 101(403): 443–59. doi:10.1093/mind/101.403.443
  • Edgar, Stacey L., 2003 [1997], Morality and Machines: Perspectives on Computer Ethics, Sudbury, MA: Jones & Bartlett Learning.
  • Ferrero, L., 2017, “Intending, Acting, and Doing,” Philosophical Explorations, 20 (Supplement 2): 13–39.
  • Fernández, Maribel, 2004, Programming Languages and Operational Semantics: An Introduction, London: King’s College Publications.
  • Fetzer, James H., 1988, “Program Verification: The Very Idea”, Communications of the ACM, 31(9): 1048–1063. doi:10.1145/48529.48530
  • –––, 1990, Artificial Intelligence: Its Scope and Limits, Dordrecht: Springer Netherlands.
  • Feynman, Richard P., 1984–1986, Feynman Lectures on Computation, Cambridge, MA: Westview Press, 2000.
  • Flanagan, Mary, Daniel C. Howe, & Helen Nissenbaum, 2008, “Embodying Values in Technology: Theory and Practice”, in Information Technology and Moral Philosophy, Jeroen van den Hoven and John Weckert (eds.), Cambridge: Cambridge University Press, pp. 322–353.
  • Floridi, Luciano, 2008, “The Method of Levels of Abstraction”, Minds and Machines, 18(3): 303–329. doi:10.1007/s11023-008-9113-7
  • Floridi, Luciano, Nir Fresco, & Giuseppe Primiero, 2015, “On Malfunctioning Software”, Synthese, 192(4): 1199–1220. doi:10.1007/s11229-014-0610-3
  • Floyd, Robert W., 1979, “The Paradigms of Programming”, Communications of the ACM, 22(8): 455–460. doi:10.1145/1283920.1283934
  • Fowler, Martin, 2003, UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd edition, Reading, MA: Addison-Wesley.
  • Franssen, Maarten, Gert-Jan Lokhorst, & Ibio van de Poel, 2013, “Philosophy of Technology”, The Stanford Encyclopedia of Philosophy (Winter 2013 Edition), Edward N. Zalta (ed.), URL = <https://plato.stanford.edu/archives/win2013/entries/technology/>.
  • Frege, Gottlob, 1914, “Letter to Jourdain”, reprinted in Frege 1980: 78–80.
  • –––, 1980, Gottlob Frege: Philosophical and Mathematical Correspondence, G. Gabriel, H. Hermes, F. Kambartel, C. Thiel, and A. Veraart (eds.), Oxford: Blackwell Publishers.
  • Fresco, Nir & Giuseppe Primiero, 2013, “Miscomputation”, Philosophy & Technology, 26(3): 253–272. doi:10.1007/s13347-013-0112-0
  • Friedman, Batya & Helen Nissenbaum, 1996, “Bias in Computer Systems”, ACM Transactions on Information Systems (TOIS), 14(3): 330–347. doi:10.1145/230538.230561
  • Frigg, Roman & Stephan Hartmann, 2012, “Models in Science”, The Stanford Encyclopedia of Philosophy (Fall 2012 Edition), Edward N. Zalta (ed.), URL =<https://plato.stanford.edu/archives/ fall2012/entries/models-science/>.
  • Gagliardi, Francesco, 2007, “Epistemological Justification of Test Driven Development in Agile Processes”, Agile Processes in Software Engineering and Extreme Programming: Proceedings of the 8th International Conference, XP 2007, Como, Italy, June 18–22, 2007, Berlin: Springer Berlin Heidelberg, pp. 253–256. doi:10.1007/978-3-540-73101-6_48
  • Gamma, Erich, Richard Helm, Ralph Johnson, & John Vlissides, 1994, Design Patterns: Elements of Reusable Object-Oriented Software, Reading, MA: Addison-Wesley.
  • Glennan, Stuart S., 1996, “Mechanisms and the Nature of Causation”, Erkenntnis, 44(1): 49–71. doi:10.1007/BF00172853
  • Glüer, Kathrin & Åsa Wikforss, 2015, “The Normativity of Meaning and Content”, The Stanford Encyclopedia of Philosophy (Summer 2015 Edition), Edward N. Zalta (ed.), URL = <https://plato.stanford.edu/archives/sum2015/entries/meaning-normativity/>.
  • Goguen, Joseph A. & Rod M. Burstall, 1985, “Institutions: Abstract Model Theory for Computer Science”, Report CSLI-85-30, Center for the Study of Language and Information at Stanford University.
  • –––, 1992, “Institutions: Abstract Model Theory for Specification and Programming”, Journal of the ACM (JACM), 39(1): 95–146. doi:10.1145/147508.147524
  • Gordon, Michael J.C., 1979, The Denotational Description of Programming Languages, New York: Springer-Verlag.
  • Gotterbarn, Donald, 1991, “Computer Ethics: Responsibility Regained”, National Forum: The Phi Beta Kappa Journal, 71(3): 26–31.
  • –––, 2001, “Informatics and Professional Responsibility”, Science and Engineering Ethics, 7(2): 221–230. doi:10.1007/s11948-001-0043-5
  • Gotterbarn, Donald, Keith Miller, & Simon Rogerson, 1997, “Software Engineering Code of Ethics”, Information Society, 40(11): 110–118. doi:10.1145/265684.265699
  • Gotterbarn, Donald & Keith W. Miller, 2009, “The Public is the Priority: Making Decisions Using the Software Engineering Code of Ethics”, IEEE Computer, 42(6): 66–73. doi:10.1109/MC.2009.204
  • Gruner, Stefan, 2011, “Problems for a Philosophy of Software Engineering”, Minds and Machines, 21(2): 275–299. doi:10.1007/s11023-011-9234-2
  • Gunter, Carl A., 1992, Semantics of Programming Languages: Structures and Techniques, Cambridge, MA: MIT Press.
  • Gupta, Anil, 2014, “Definitions”, The Stanford Encyclopedia of Philosophy (Fall 2014 Edition), Edward N. Zalta (ed.), URL = <https://plato.stanford.edu/archives/ fall2014/entries/definitions/>.
  • Gurevich, Y., 2000, “Sequential Abstract-State Machines Capture Sequential Algorithms”, ACM Transactions on Computational Logic (TOCL), 1(1): 77-111.
  • –––, 2012, “What is an algorithm?”, in International conference on current trends in theory and practice of computer science, Heidelberg, Berlin: Springer, pp. 31–42.
  • Hacking, I., 2014, Why is there a Philosophy of Mathematics at all?, Cambridge: Cambridge University Press.
  • Hagar, Amit, 2007, “Quantum Algorithms: Philosophical Lessons”, Minds and Machines, 17(2): 233–247. doi:10.1007/s11023-007-9057-3
  • Hale, Bob, 1987, Abstract Objects, Oxford: Basil Blackwell.
  • Hales, Thomas C., 2008, “Formal Proof”, Notices of the American Mathematical Society, 55(11): 1370–1380.
  • Hankin, Chris, 2004, An Introduction to Lambda Calculi for Computer Scientists, London: King’s College Publications.
  • Harrison, John, 2008, “Formal Proof—Theory and Practice”, Notices of the American Mathematical Society, 55(11): 1395–1406.
  • Hartmanis, Juris, 1981, “Nature of Computer Science and Its Paradigms”, pp. 353–354 (in Section 1) of “Quo Vadimus: Computer Science in a Decade”, J.F. Traub (ed.), Communications of the ACM, 24(6): 351–369. doi:10.1145/358669.358677
  • –––, 1993, “Some Observations About the Nature of Computer Science”, in International Conference on Foundations of Software Technology and Theoretical Computer Science, Springer Berlin Heidelberg, pp. 1–12. doi:10.1007/3-540-57529-4_39
  • Hayes, P. J., 1997, “What is a Computer?”, The Monist, 80(3): 389–404.
  • Hempel, C. G., 1970, “On the ‘standard conception’ of scientific theories”, Minnesota Studies in the Philosophy of Science, 4: 142–163.
  • Henson, Martin C., 1987, Elements of Functional Programming, Oxford: Blackwell.
  • Hilbert, David, 1931, “The Grounding of Elementary Number Theory”, reprinted in P. Mancosu (ed.), 1998, From Brouwer to Hilbert: the Debate on the Foundations of Mathematics in the 1920s, New York: Oxford University Press, pp. 266–273.
  • Hilbert, David & Wilhelm Ackermann, 1928, Grundzüge Der Theoretischen Logik, translated as Principles of Mathematical Logic, Lewis M. Hammond, George G. Leckie, and F. Steinhardt (trans.), New York: Chelsea, 1950.
  • Hill, R.K., 2016, “What an algorithm is”, Philosophy & Technology, 29(1): 35–59.
  • –––, 2018, “Elegance in Software”, in Liesbeth de Mol, Giuseppe Primiero (eds.), Reflections on Programmings Systems – Historical and Philosophical Aspects (Philosophical Studies Series), Cham: Springer, pp. 273–286.
  • Hoare, C.A.R., 1969, “An Axiomatic Basis for Computer Programming”, Communications of the ACM, 12(10): 576–580. doi:10.1145/363235.363259
  • –––, 1973, “Notes on Data Structuring”, in O.J. Dahl, E.W. Dijkstra, and C.A.R. Hoare (eds.), Structured Programming, London: Academic Press, pp. 83–174.
  • –––, 1981, “The Emperor’s Old Clothes”, Communications of the ACM, 24(2): 75–83. doi:10.1145/1283920.1283936
  • –––, 1985, Communicating Sequential Processes, Englewood Cliffs, NJ: Prentice Hall. [Hoare 1985 available online]
  • –––, 1986, The Mathematics of Programming: An Inaugural Lecture Delivered Before the University of Oxford on Oct. 17, 1985, Oxford: Oxford University Press.
  • Hodges, Andrews, 2011, “Alan Turing”, The Stanford Encyclopedia of Philosophy (Summer 2011 Edition), Edward N. Zalta (ed.), URL = <https://plato.stanford.edu/archives/ sum2011/entries/turing/>.
  • Hodges, Wilfrid, 2013, “Model Theory”, The Stanford Encyclopedia of Philosophy (Fall 2013 Edition), Edward N. Zalta (ed.), forthcoming URL = <https://plato.stanford.edu/archives/ fall2013/entries/model-theory/>.
  • Hopcroft, John E. & Jeffrey D. Ullman, 1969, Formal Languages and their Relation to Automata, Reading, MA: Addison-Wesley.
  • Hughes, Justin, 1988, “The Philosophy of Intellectual Property”, Georgetown Law Journal, 77: 287.
  • Irmak, Nurbay, 2012, “Software is an Abstract Artifact”, Grazer Philosophische Studien, 86(1): 55–72.
  • Johnson, Christopher W., 2006, “What are Emergent Properties and How Do They Affect the Engineering of Complex Systems”, Reliability Engineering and System Safety, 91(12): 1475–1481. [Johnson 2006 available online]
  • Johnson-Laird, P. N., 1988, The Computer and the Mind: An Introduction to Cognitive Science, Cambridge, MA: Harvard University Press.
  • Jones, Cliff B., 1990 [1986], Systematic Software Development Using VDM, second edition, Englewood Cliffs, NJ: Prentice Hall. [Jones 1990 available online]
  • Kimppa, Kai, 2005, “Intellectual Property Rights in Software—Justifiable from a Liberalist Position? Free Software Foundation’s Position in Comparison to John Locke’s Concept of Property”, in R.A. Spinello & H.T. Tavani (eds.), Intellectual Property Rights in a Networked World: Theory and Practice, Hershey, PA: Idea, pp. 67–82.
  • Kinsella, N. Stephan, 2001, “Against Intellectual Property”, Journal of Libertarian Studies, 15(2): 1–53.
  • Kleene, S. C., 1967, Mathematical Logic, New York: Wiley.
  • Knuth, D. E., 1973, The Art of Computer Programming, second edition, Reading, MA: Addison-Wesley.
  • –––, 1974a, “Computer Programming as an Art”, Communications of the ACM, 17(12): 667–673. doi:10.1145/1283920.1283929
  • –––, 1974b, “Computer Science and Its Relation to Mathematics”, The American Mathematical Monthly, 81(4): 323–343.
  • –––, 1977, “Algorithms”, Scientifc American, 236(4): 63–80.
  • Kripke, Saul, 1982, Wittgenstein on Rules and Private Language, Cambridge, MA: Harvard University Press.
  • Kroes, Peter, 2010, “Engineering and the Dual Nature of Technical Artefacts”, Cambridge Journal of Economics, 34(1): 51–62. doi:10.1093/cje/bep019
  • –––, 2012, Technical Artefacts: Creations of Mind and Matter: A Philosophy of Engineering Design, Dordrecht: Springer.
  • Kroes, Peter & Anthonie Meijers, 2006, “The Dual Nature of Technical Artefacts”, Studies in History and Philosophy of Science, 37(1): 1–4. doi:10.1016/j.shpsa.2005.12.001
  • Kröger, Fred & Stephan Merz, 2008, Temporal Logics and State Systems, Berlin: Springer.
  • Ladd, John, 1988, “Computers and Moral Responsibility: a Framework for An Ethical Analysis”, in Carol C. Gould, (ed.), The Information Web: Ethical & Social Implications of Computer Networking, Boulder, CO: Westview Press, pp. 207–228.
  • Landin, P.J., 1964, “The Mechanical Evaluation of Expressions”, The Computer Journal, 6(4): 308–320. doi:10.1093/comjnl/6.4.308
  • Littlewood, Bev & Lorenzo Strigini, 2000, “Software Reliability and Dependability: a Roadmap”, ICSE ’00 Proceedings of the Conference on the Future of Software Engineering, pp. 175–188. doi:10.1145/336512.336551
  • Locke, John, 1690, The Second Treatise of Government. [Locke 1690 available online]
  • Loewenheim, Ulrich, 1989, “Legal Protection for Computer Programs in West Germany”, Berkeley Technology Law Journal, 4(2): 187–215. [Loewenheim 1989 available online] doi:10.15779/Z38Q67F
  • Long, Roderick T., 1995, “The Libertarian Case Against Intellectual Property Rights”, Formulations, Autumn, Free Nation Foundation.
  • Loui, Michael C. & Keith W. Miller, 2008, “Ethics and Professional Responsibility in Computing”, Wiley Encyclopedia of Computer Science and Engineering, Benjamin Wah (ed.), John Wiley & Sons. [Loui and Miller 2008 available online]
  • Lowe, E. J., 1998, The Possibility of Metaphysics: Substance, Identity, and Time, Oxford: Clarendon Press.
  • Luckham, David C., 1998, “Rapide: A Language and Toolset for Causal Event Modeling of Distributed System Architectures”, in Y. Masunaga, T. Katayama, and M. Tsukamoto (eds.), Worldwide Computing and its Applications, WWCA’98, Berlin: Springer, pp. 88–96. doi:10.1007/3-540-64216-1_42
  • Machamer, Peter K., Lindley Darden, & Carl F. Craver, 2000, “Thinking About Mechanisms”, Philosophy of Science, 67(1): 1–25. doi:10.1086/392759
  • Magee, Jeff, Naranker Dulay, Susan Eisenbach, & Jeff Kramer, 1995, “Specifying Distributed Software Architectures”, Proceedings of 5th European Software Engineering Conference (ESEC 95), Berlin: Springer-Verlag, pp. 137–153.
  • Markov, A., 1954, “Theory of algorithms”, Tr. Mat. Inst. Steklov 42, pp. 1–14. trans. by Edwin Hewitt in American Mathematical Society Translations, Series 2, Vol. 15 (1960).
  • Martin-Löf, Per, 1982, “Constructive Mathematics and Computer Programming”, in Logic, Methodology and Philosophy of Science (Volume VI: 1979), Amsterdam: North-Holland, pp. 153–175.
  • McGettrick, Andrew, 1980, The Definition of Programming Languages, Cambridge: Cambridge University Press.
  • McLaughlin, Peter, 2001, What Functions Explain: Functional Explanation and Self-Reproducing Systems, Cambridge: Cambridge University Press.
  • Meijers, A.W.M., 2001, “The Relational Ontology of Technical Artifacts”, in P.A. Kroes and A.W.M. Meijers (eds.), The Empirical Turn in the Philosophy of Technology, Amsterdam: Elsevier, pp. 81–96.
  • Mitchelmore, Michael & Paul White, 2004, “Abstraction in Mathematics and Mathematics Learning”, in M.J. Høines and A.B. Fuglestad (eds.), Proceedings of the 28th Conference of the International Group for the Psychology of Mathematics Education (Volume 3), Bergen: Programm Committee, pp. 329–336. [Mitchelmore and White 2004 available online]
  • Miller, Alexander & Crispin Wright (eds), 2002, Rule Following and Meaning, Montreal/Ithaca: McGill-Queen’s University Press.
  • Milne, Robert & Christopher Strachey, 1976, A Theory of Programming Language Semantics, London: Chapman and Hall.
  • Milner, R., 1971, “An algebraic definition of simulation between programs”, Technical Report, CS-205, pp. 481–489, Department of Computer Science, Stanford University.
  • Mitchell, John C., 2003, Concepts in Programming Languages, Cambridge: Cambridge University Press.
  • Monin, Jean François, 2003, Understanding Formal Methods, Michael G. Hinchey (ed.), London: Springer (this is Monin’s translation of his own Introduction aux Méthodes Formelles, Hermes, 1996, first edition; 2000, second edition), doi:10.1007/978-1-4471-0043-0
  • Mooers, Calvin N., 1975, “Computer Software and Copyright”, ACM Computing Surveys, 7(1): 45–72. doi:10.1145/356643.356647
  • Moor, James H., 1978, “Three Myths of Computer Science”, The British Journal for the Philosophy of Science, 29(3): 213–222.
  • Morgan, C., 1994, Programming From Specifications, Englewood Cliffs: Prentice Hall. [Morgan 1994 available online]
  • Moschovakis, Y. N., 2001, “What is an algorithm?”, in Mathematics Unlimited—2001 and Beyond, Heidelberg, Berlin: Springer, pp. 919–936.
  • Naur, P., 1985, “Programming as theory building”, Microprocessing and microprogramming, 15(5): 253–261.
  • Newell, A., and Simon, H. A., 1961, “Computer simulation of human thinking” Science, 134(3495): 2011–2017.
  • ––– 1972, Human Problem Solving, Englewood Cliffs, NJ: Prentice-Hall.
  • –––, 1976, “Computer Science as Empirical Inquiry: Symbols and Search”, Communications of the ACM, 19(3): 113–126. doi:10.1145/1283920.1283930
  • Newell, Allen, Alan J. Perlis, & Herbert A. Simon, 1967, “Computer Science”, Science, 157(3795): 1373–1374. doi:10.1126/science.157.3795.1373-b
  • Nissenbaum,Helen, 1998, “Values in the Design of Computer Systems”, Computers and Society, 28(1): 38–39.
  • Northover, Mandy, Derrick G. Kourie, Andrew Boake, Stefan Gruner, & Alan Northover, 2008, “Towards a Philosophy of Software Development: 40 Years After the Birth of Software Engineering”, Journal for General Philosophy of Science, 39(1): 85–113. doi:10.1007/s10838-008-9068-7
  • Pears, David Francis, 2006, Paradox and Platitude in Wittgenstein’s Philosophy, Oxford: Oxford University Press. doi:10.1093/acprof:oso/9780199247707.001.0001
  • Piccinini, Gualtiero, 2007, “Computing Mechanisms”, Philosophy of Science, 74(4): 501–526. doi:10.1086/522851
  • –––, 2008, “Computation without Representation”, Philosophical Studies, 137(2): 206–241. [Piccinini 2008 available online] doi:10.1007/s11098-005-5385-4
  • –––, 2008, “Computers”, Pacific Philosophical Quarterly, 89: 32–73.
  • –––, 2015, Physical Computation: A Mechanistic Account, Oxford: Oxford University Press. doi:10.1093/acprof:oso/9780199658855.001.0001
  • Piccinini, Gualtiero & Carl Craver, 2011, “Integrating Psychology and Neuroscience: Functional Analyses as Mechanism Sketches”, Synthese, 183(3): 283–311. doi:10.1007/s11229-011-9898-4
  • Popper, Karl R., 1959, The Logic of Scientific Discovery, London: Hutchinson.
  • Primiero, G., 2016, “Information in the philosophy of computer science”, in Floridi L. (ed.), The Routledge Handbook of Philosophy of Information, London: Routledge, pp. 90–106.
  • –––, 2020, On the Foundations of Computing. New York: Oxford University Press.
  • Primiero, G., D.F. Solheim & J.M. Spring, 2019 “On Malfunction, Mechanisms and Malware Classification”, Philos. Technol. 32: 339–362. https://doi.org/10.1007/s13347-018-0334-2
  • Pylyshyn, Z. W., 1984, Computation and Cognition: Towards a Foundation for Cognitive Science, Cambridge, MA: MIT Press.
  • Pym, D., J.M. Spring, & P. O’Hearn, 2019, “Why Separation Logic Works”, Philosophy & Technology, 32: 483–516.
  • Rapaport, William J., 1995, “Understanding Understanding: Syntactic Semantics and Computational Cognition”, in Tomberlin (ed.), Philosophical Perspectives, Vol. 9: AI, Connectionism, and Philosophical Psychology, Atascadero, CA: Ridgeview, pp. 49–88. [Rapaport 1995 available online] doi:10.2307/2214212
  • –––, 1999, “Implementation Is Semantic Interpretation”, The Monist, 82(1): 109–30. [Rapaport 1999 available online]
  • –––, 2005, “Implementation as Semantic Interpretation: Further Thoughts”, Journal of Experimental& Theoretical Artificial Intelligence, 17(4): 385–417. [Rapaport 2005 available online]
  • –––, 2012, “Semiotic systems, computers, and the mind: how cognition could be computing”, International Journal of Signs and Semiotic Systems, 2(1): 32–71
  • –––, 2018, “What is a Computer? A Survey”, Minds and Machines, 28(3): 385–426.
  • Reynolds, J.C., 2002, “Separation Logic: a logic for shared mutable data structures”, in Proceedings of the 17th Annual IEEE Symposium on Logic in Computer Science, IEEE, pp. 55–74.
  • Rombach, Dieter & Frank Seelisch, 2008, “Formalisms in Software Engineering: Myths Versus Empirical Facts”, in Balancing Agility and Formalism in Software Engineering, Springer Berlin Heidelberg, pp. 13–25. doi:10.1007/978-3-540-85279-7_2
  • Rosenberg, A., 2012, The Philosophy of Science, London: Routledge.
  • Ryle G., 1949 [2009], The Concept of Mind, Abingdon: Routledge
  • Schiaffonati, Viola, 2015, “Stretching the Traditional Notion of Experiment in Computing: Explorative Experiments”, Science and Engineering Ethics, 22(3): 1–19. doi:10.1007/s11948-015-9655-z
  • Schiaffonati, Viola & Mario Verdicchio, 2014, “Computing and Experiments”, Philosophy & Technology, 27(3): 359–376. doi:10.1007/s13347-013-0126-7
  • Searle, J. R., 1990, “Is the brain a digital computer?” Proceedings and Addresses of the American Philosophical Association, 64(3): 21–37.
  • Searle, John R., 1995, The Construction of Social Reality, New York: Free Press.
  • Setiya, K., “Intention”, The Stanford Encyclopedia of Philosophy (Fall 2018 Edition), Edward N. Zalta (ed.), URL = <https://plato.stanford.edu/archives/fall2018/entries/intention/>.
  • Shanker, S.G., 1987, “Wittgenstein versus Turing on the Nature of Church’s Thesis”, Notre Dame Journal of Formal Logic, 28(4): 615–649. [Shanker 1987 available online] doi:10.1305/ndjfl/1093637650
  • Shavell, Steven & Tanguy van Ypersele, 2001, “Rewards Versus Intellectual Property Rights”, Journal of Law and Economics, 44: 525–547
  • Skemp, Richard R., 1987, The Psychology of Learning Mathematics, Hillsdale, NJ: Lawrence Erlbaum Associates.
  • Smith, Brian Cantwell, 1985, “The Limits of Correctness in Computers”, ACM SIGCAS Computers and Society, 14–15(1–4): 18–26. doi:10.1145/379486.379512
  • Snelting, Gregor, 1998, “Paul Feyerabend and Software Technology”, Software Tools for Technology Transfer, 2(1): 1–5. doi:10.1007/s100090050013
  • Sommerville, Ian, 2016 [1982], Software Engineering, Reading, MA: Addison-Wesley; first edition, 1982.
  • Sprevak, M., 2010, “Computation, individuation, and the received view on representation”, Studies in History and Philosophy of Science, 41(3): 260–270.
  • –––, 2012, “Three Challenges to Chalmers on Computational Implementation”, Journal of Cognitive Science, 13(2): 107–143.
  • Stoy, Joseph E., 1977, Denotational Semantics: The Scott-Strachey Approach to Programming Language Semantics, Cambridge, MA: MIT Press.
  • Strachey, Christopher, 2000, “Fundamental Concepts in Programming Languages”, Higher-Order and Symbolic Computation, 13(1–2): 11–49. doi:10.1023/A:1010000313106
  • Suber, Peter, 1988, “What Is Software?” Journal of Speculative Philosophy, 2(2): 89–119. [Suber 1988 available online]
  • Summerville, I., 2012, Software Engineering, Reading, MA: Addison-Wesley; first edition, 1982.
  • Suppe, Frederick, 1989, The Semantic Conception of Theories and Scientific Realism, Chicago: University of Illinois Press.
  • Suppes, Patrick, 1960, “A Comparison of the Meaning and Uses of Models in Mathematics and the Empirical Sciences”, Synthese, 12(2): 287–301. doi:10.1007/BF00485107
  • –––, 1969, “Models of Data”, in Studies in the Methodology and Foundations of Science, Dordrecht: Springer Netherlands, pp. 24–35.
  • Technical Correspondence, Corporate, 1989, Communications of the ACM, 32(3): 374–381. Letters from James C. Pleasant, Lawrence Paulson/Avra Cohen/Michael Gordon, William Bevier/Michael Smith/William Young, Thomas Clune, Stephen Savitzky, James Fetzer. doi:10.1145/62065.315927
  • Tedre, Matti, 2011, “Computing as a Science: A Survey of Competing Viewpoints”, Minds and Machines, 21(3): 361–387. doi:10.1007/s11023-011-9240-4
  • –––, 2015, The Science of Computing: Shaping a Discipline, Boca Raton: CRC Press, Taylor and Francis Group.
  • Tedre, Matti & Ekki Sutinen, 2008, “Three Traditions of Computing: What Educators Should Know”, Computer Science Education, 18(3): 153–170. doi:10.1080/08993400802332332
  • Thagard, P., 1984, “Computer programs as psychological theories”, Mind, Language and Society, Vienna: Conceptus-Studien, pp. 77–84.
  • Thomasson, Amie, 2007, “Artifacts and Human Concepts”, in Eric Margolis and Stephen Laurence (eds.), Creations of the Mind: Essays on Artifacts and Their Representations, Oxford: Oxford University Press, pp. 52–73.
  • Thompson, Simon, 2011, Haskell: The Craft of Functional Programming, third edition, Reading, MA: Addison-Wesley; first edition, 1996.
  • Tichy, Walter F., 1998, “Should Computer Scientists Experiment More?”, IEEE Computer, 31(5): 32–40. doi:10.1109/2.675631
  • Turing, A.M., 1936, “On Computable Numbers, with an Application to the Entscheidungsproblem”, Proceedings of the London Mathematical Society (Series 2), 42: 230–65. doi:10.1112/plms/s2-42.1.230
  • –––, 1950, “Computing Machinery and Intelligence”, Mind, 59(236): 433–460. doi:10.1093/mind/LIX.236.433
  • Turner, Raymond, 2007, “Understanding Programming Languages”, Minds and Machines, 17(2): 203–216. doi:10.1007/s11023-007-9062-6
  • –––, 2009a, Computable Models, Berlin: Springer. doi:10.1007/978-1-84882-052-4
  • –––, 2009b, “The Meaning of Programming Languages”, APA Newsletters, 9(1): 2–7. (This APA Newsletter is available online; see the Other Internet Resources.)
  • –––, 2010, “Programming Languages as Mathematical Theories”, in J. Vallverdú (ed.), Thinking Machines and the Philosophy of Computer Science: Concepts and Principles, Hershey, PA: IGI Global, pp. 66–82.
  • –––, 2011, “Specification”, Minds and Machines, 21(2): 135–152. doi:10.1007/s11023-011-9239-x
  • –––, 2012, “Machines”, in H. Zenil (ed.), A Computable Universe: Understanding and Exploring Nature as Computation, London: World Scientific Publishing Company/Imperial College Press, pp. 63–76.
  • –––, 2014, “Programming Languages as Technical Artefacts”, Philosophy and Technology, 27(3): 377–397; first published online 2013. doi:10.1007/s13347–012–0098-z
  • –––, 2018, Computational artifacts: Towards a philosophy of computer science, Berlin Heidelberg: Springer.
  • Tymoczko, Thomas, 1979, “The Four Color Problem and Its Philosophical Significance”, The Journal of Philosophy, 76(2): 57–83. doi:10.2307/2025976
  • –––, 1980, “Computers, Proofs and Mathematicians: A Philosophical Investigation of the Four-Color Proof”, Mathematics Magazine, 53(3): 131–138.
  • Van Fraassen, Bas C., 1980, The Scientific Image, Oxford: Oxford University Press. doi:10.1093/0198244274.001.0001
  • –––, 1989, Laws and Symmetry, Oxford: Oxford University Press. doi:10.1093/0198248601.001.0001
  • Van Leeuwen, Jan (ed.), 1990, Handbook of Theoretical Computer Science. Volume B: Formal Models and Semantics, Amsterdam: Elsevier and Cambridge, MA: MIT Press.
  • Vardi, M., 2012, “What is an algorithm?”, Communications of the ACM, 55(3): 5. doi:10.1145/2093548.2093549
  • Vermaas, Pieter E. & Wybo Houkes, 2003, “Ascribing Functions to Technical Artifacts: A Challenge to Etiological Accounts of Function”, British Journal of the Philosophy of Science, 54: 261–289. [Vermaas and Houkes 2003 available online]
  • Vliet, Hans van, 2008, Software Engineering: Principles and Practice, 3rd edition, Hoboken, NJ: Wiley. (First edition, 1993)
  • von Neumann, J. (1945). “First draft report on the EDVAC”, IEEE Annals of the History of Computing, 15(4): 27–75.
  • Wang, Hao, 1974, From Mathematics to Philosophy, London: Routledge, Kegan & Paul.
  • Wegner, Peter, 1976, “Research Paradigms in Computer Science”, in Proceedings of the 2nd international Conference on Software Engineering, Los Alamitos, CA: IEEE Computer Society Press, pp. 322–330.
  • White, Graham, 2003, “The Philosophy of Computer Languages”, in Luciano Floridi (ed.), The Blackwell Guide to the Philosophy of Computing and Information, Malden: Wiley-Blackwell, pp. 318–326. doi:10.1111/b.9780631229193.2003.00020.x
  • Wiener, Norbert, 1948, Cybernetics: Control and Communication in the Animal and the Machine, New York: Wiley & Sons.
  • –––, 1964, God and Golem, Inc.: A Comment on Certain Points Where Cybernetics Impinges on Religion, Cambridge, MA: MIT press.
  • Wittgenstein, Ludwig, 1953 [2001], Philosophical Investigations, translated by G.E.M. Anscombe, 3rd Edition, Oxford: Blackwell Publishing.
  • –––, 1956 [1978], Remarks of the Foundations of Mathematics, G.H. von Wright, R. Rhees, and G.E.M. Anscombe (eds.), translated by G.E.M. Anscombe, revised edition, Oxford: Basil Blackwell.
  • –––, 1939 [1975], Wittgenstein’s Lectures on the Foundations of Mathematics, Cambridge 1939, C. Diamond (ed.), Cambridge: Cambridge University Press.
  • Woodcock, Jim & Jim Davies, 1996, Using Z: Specification, Refinement, and Proof, Englewood Cliffs, NJ: Prentice Hall.
  • Wright, Crispin 1983, Frege’s Conception of Numbers as Objects, Aberdeen: Aberdeen University Press.

أدوات أكاديمية

How to cite this entry.
Preview the PDF version of this entry at the Friends of the SEP Society.
Look up this entry topic at the Internet Philosophy Ontology Project (InPhO).
Enhanced bibliography for this entry at PhilPapers, with links to its database.

مصادر الإنترنت الأخرى


مداخل ذات صلة

artificial intelligence: logic and | Church-Turing Thesis | computability and complexity | computation: in physical systems | computational complexity theory | information | information: semantic conceptions of | intention | mathematics, philosophy of | recursive functions | technology, philosophy of | Turing machines