الكاتب يتكلم عن إن معظم المناقشات حول البرمجة بتكون سطحية، وبتعتمد على إجابات جاهزة زي “It depends” أو محض خرائط ذهنية بدون عمق. الكاتب بيقول إن في نظريات أعمق في تصميم البرمجيات لسه ما استنتجناهاش كويس، وإنه ممكن نكتشفها بالتفكير المنطقي وعمل hypotheses ونختبرها في العالم الواقعي.
المحور الأساسي: حذف ملفات – Windows vs Unix
— Windows:
لو ملف مفتوح من process، السيستم هيمنعك تحذفه. لازم تقتل الprocess أو تقفل الملف. ساعات بتيأس وتعيد تشغيل الجهاز بس عشان تحذف ملف.
— Unix:
لو ملف مفتوح، تقدر تحذفه بسهولة. العمليات اللي ماسكة الملف بتقدر تقرأ وتكتب منه بعد الحذف، ولما تقفل النهاية، السيستم بينضف الملف. ما بيحصلكش error وانت بتحذفه.
لماذا نراجع نظرياتنا؟
في PyCon India 2024، James Powell استخدم مثال “كام برتقالة علشان نعمل كباية عصير؟” والرد كان “It depends on size”. المنطق هنا إن لازم نطلع بنظرية واضحة، مش بس إجابات فضفاضة. مثال عملي: استخدم positional arguments للبيانات (data arguments) وkeyword arguments للإعدادات (modal arguments)، وده بيسهّل القراءة والفهم.
الغوص أعمق: مقارنة Unix وWindows باستخدام تشبيه transactional systems
Unix سلوكها قريب للـ transactions في databases.
Windows زي RW locks اللي تمنع الحذف لو في read أو write شغال.
لكن الـ transactions نفسها مش بسيطة: فيها isolation levels مختلفة—Read Committed, Repeatable Read, Serializable—كل مستوى منه بيقدّم ضمانات مختلفة وفيه احتمالات لحدوث anomalies زي write skew أو read skew.
هل Unix أقرب للـ Serializable؟ لأ!
أول ما تجرب المستوى الأقوى (Serializable)، التتابعات اللي Unix بتسمح بيها ممكن تترفض، زي اللي حصل لما الموضوع حاول ينفذ فى Postgres—العملية فشلت بسبب عدم قابلية الـ serialization. Unix أقل ضمان من المستوى ده—أقرب لـ Read Committed أو حتى Read Uncommitted.
أمثلة حياتية بتبين المشكلة
IDEs أو build systems والـ hot reload اللي بتعتمد على الملفات ممكن تواجه أخطاء لو حد حذف ملفات في النص.
Git operations وسط شغل parallel ممكن تخرب الريبو وتحتاج تمسح lock files يدويًا. Git بيعتمد على locking مش database؛ لكن بعض الأدوات زي Fossil بتستخدم SQLite بالترانزاكشنات.
نظرية جزئية عن concurrent modifications
الكاتب بيقترح إطار تفكيري (partial theory):
تجنب concurrent modifications لما تقدر.
locks آمنة بس فيها احتمالات زيرو مثل deadlocks أو starvation.
transactions ممكن تحل المشكلة لكن بتكلف أكتر من ناحية runtime، وبترجع على قوة isolation level.
تطبيق النظرية على أنظمة الملفات
Windows ببساطة تمنع الحذف حتى النهاية، لكنها safe.
Unix بتدي bubble لكل process، وبالرغم من المرونة، إلا إنها ممكن تكون counter-intuitive وغير فكرتها واضحة للناس.
والأهم إن لازم التطبيقات اللي بتتعامل مع ملفات وتحتاج reliability تخطط إزاي تتعامل مع concurrent حالات على حسب حاجتها.
هل النظرية دي حقيقية وتقدر تتنبأ؟
لو النظرية صحيحة، لازم نلاقي تأكيد عملي كالتالي:
السيستمات تميل تنصح باستخدام storage خاص بدل الـ shared.
أنظمة الملفات الحديثة زى ZFS وFxFS داخليًا بتدعم transactions.
قواعد البيانات بتترقى في isolation levels—زي Aurora DSQL وSpanner وTigerBeetle إلخ.
الخلاصة
بدل النظريات السطحية، نحتاج نظريات تصميم برمجي فعلًا لديها substance—تنبؤية، قابلة للتعميم، وتوضح الحدود والقيود. والكاتب بيورينا إن التحليل العميق اللي عمله في مقال بحوالي 3000 كلمة أعظم من شرح بسيط أقل من 400 كلمة في كتاب Ousterhout، وده سبب قوي لتعمق أكتر في التفكير والتصميم البرمجي.