فلسفة يونكس

مكإلوري: ربع قرن من يونكس

روابط خارجية

من جهة ثانية، دوجلاس مكإلوري، لخص فلسفة يونكس، عندما كان رئيسا لمختبرات بيل ومشاركا في تطوير «انابيب يونكس» بالآتي:

تجنب المخرجات غير الضرورية

• كتابة برامج تفشل بطريقة يسهل تشخيصها (معرفة سبب الخطأ)
• توفير وقت المبرمج أهم من توفير وقت الجهاز
• كتابة برامج مجردة تُنشئ الكود بدلاً من كتابة الكود يدوياً
• عمل نموذج أولي للبرنامج قبل إصداره

إفعل شيئاً واحداً وأتقنه

ومن ناحية أخرى، كما ذكر ماكلروي، وهو مبدأ مقبول عمومًا في مجتمع يونكس، يُفترض دائمًا أن تتبع برامج يونكس مفهوم "اِفْعَلْ شَيْئًا وَاحِدًا وَأَتْقِنْهُ" (Do One Thing And Do It Well - DOTADIW). توجد مصادر محدودة للاختصار DOTADIW على الإنترنت، لكن يُناقَش هذا المفهوم بإسهاب خلال تطوير وتعبئة أنظمة التشغيل الجديدة، خاصةً في مجتمع لينكس.

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

أساسيات فلسفة يونكس – بواسطة Catb.org

فلسفة يونكس: مقدمة موجزة – (LINFO)

لماذا لا تزال فلسفة يونكس مهمة

المنشأ

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

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

• وقد لخصها لاحقًا بيتر إتش. سالوس في "ربع قرن من يونكس" عام ١٩٩٤م في الآتي:
• اكتب برامج تقوم بمهمة واحدة وتؤديها على أكمل وجه.
• اكتب برامج تعمل معًا.
• اكتب برامج للتعامل مع تدفقات النصوص، لأنها واجهة عالمية.

من جانب آخر، تتمثل فلسفة يونكس كما وثقها دوغلاس ماكلروي في مجلة بيل سيستم التقنية عام ١٩٧٨ في الآتي:

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

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

من جانب آخر، في ورقة يونكس الخاصة بهما عام ١٩٧٤م، اقتبس ريتشي وثومبسون اعتبارات التصميم التالية:

• اجعل كتابة البرامج واختبارها وتشغيلها أمرًا سهلًا.
• الاستخدام التفاعلي بدلًا من المعالجة التدفقية.
• توفير وأناقة التصميم بسبب قيود الحجم ("الخلاص من خلال المعاناة").
• نظام مكتفٍ ذاتيًا: تتم صيانة جميع برمجيات يونكس تحت يونكس.
• الأجزاء

تصميم البرامج في بيئة يونكس

ومن جهة أخرى، في أكتوبر عام ١٩٨٤، نشر كل من برايان كيرنيغان وروب بايك ورقة بحثية بعنوان "تصميم البرامج في بيئة يونكس". في هذه الورقة، انتقدوا التراكم المتزايد لخيارات وميزات البرامج الموجودة في بعض أنظمة يونكس الحديثة مثل 4.2BSD و System V، وشرحوا فلسفة يونكس لأدوات البرمجيات، حيث تؤدي كل أداة وظيفة عامة واحدة:

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

كتابة برامج صغيرة

• كتابة برامج شفافة (واضحة العمل)
• كتابة برامج قوية (متحملة للأخطاء)
• جعل البيانات معقدة عند الحاجة، وليس البرنامج
• البناء على المعرفة المتوقعة للمستعملين المحتملين

ملاحظات بايك حول البرمجة بلغة C

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

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

القاعدة السادسة: لا توجد قاعدة سادسة.

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

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

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

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

ومن ناحية أخرى، تُكرر القاعدتان 1 و 2 المبدأ الشهير لدونالد إي. كنوث: "التحسين المُبكر هو أصل كل شر". صاغ كين تومبسون القاعدتين 3 و 4 على أنهما "استعمل القوة الغاشمة عند الشك"؛ هذه القواعد هي أمثلة على مبدأ KISS (اجعلها بسيطة، أيها الغبي). القاعدة 5 مأخوذة من فريد بروكس، الذي ذكرها في كتاب "أسطورة الشهر-الرجل" وغالبًا ما تُصاغ على أنها "اكتب كودًا غبيًا يستعمل بيانات ذكية". القاعدة 6 مأخوذة من مسرحية بروس من مونتي بايثون فلاينج سيركس (الحلقة 22).

كتابة برامج مرنة ومفتوحة

جعل البرنامج والبروتوكولات قابلة للتوسيع.

قواعد يونكس السبعة عشر لإريك ريموند

وفي السياق ذاته، في كتابه "فن برمجة يونكس" الذي نُشر لأول مرة عام ٢٠٠٣، لخص إريك إس. ريموند (المدافع عن المصادر المفتوحة والمبرمج) فلسفة يونكس بمبدأ "اجعلها بسيطة، يا غبي". وقدم سلسلة من قواعد التصميم:

• بناء برامج نمطية (وحدات منفصلة)
• كتابة برامج قابلة للقراءة (سهلة الفهم)
• استخدام التركيب (تجميع البرامج الصغيرة لإنشاء برامج أكبر)
• فصل الآليات عن السياسات (فصل طريقة العمل عن القرارات)
• كتابة برامج بسيطة

بيئة برمجة يونكس

من جانب آخر، وكتب المؤلفان كذلك أن هدفهما من هذا الكتاب هو "نقل فلسفة برمجة يونكس".

علاوةً على ذلك، في مقدمتهما لكتابهما الصادر عام ١٩٨٤ بعنوان "بيئة برمجة يونكس"، قدم كل من برايان كيرنيغان وروب بايك، وهما من مختبرات بل، وصفًا موجزًا لتصميم وفلسفة يونكس:

مايك جانكارس: فلسفة يونكس

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

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

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

• المبادئ الأساسية التسعة التي يرى أهميتها هي:
• البساطة جمال.
• اجعل كل برنامج يقوم بمهمة واحدة على أكمل وجه.
• أنشئ نموذجًا أوليًا في أقرب وقت ممكن.
• اختر قابلية النقل على الكفاءة.
• خزّن البيانات في ملفات نصية بسيطة.
• استعمل قوة البرمجيات لصالحك.
• استعمل نصوص واجهة سطر الأوامر لزيادة القوة وقابلية النقل.
• تجنب واجهات المستعمل الاحتكارية.
• اجعل كل برنامج مُرشِّحًا (filter).
• مبدأ "الأسوأ أفضل"

في هذا الإطار، في عام ١٩٩٤، نشر مايك جانكارس، العضو في فريق هندسة يونكس في شركة ديجيتال إكوبمينت كوربوريشن (UEG)، كتاب "فلسفة يونكس" بناءً على تجربته في تطوير نظام (Ultrix) في شركة DEC في الثمانينيات ومناقشاته مع زملائه. وهو كذلك عضو في فريق تطوير نظام النوافذ X ومؤلف مدير نوافذ Ultrix (uwm).