مرحبا يا هبر!
أوجه انتباهكم إلى ترجمة لمقال "
النماذج الثلاثة " لروبرت مارتن مارتن (العم بوب).
على مدار الأربعين عامًا الماضية ، زادت تقنيات الأجهزة من القدرة الحاسوبية لأجهزتنا بأكثر من عشرين طلبًا من حيث الحجم. نلعب الآن Angry Birds على هواتفنا ، التي تتمتع بقدرة معالجة حاسوب عملاق مبرد الفريون في السبعينيات من القرن الماضي.
ولكن على مدار الأربعين سنة الماضية ، لم تتغير تكنولوجيا البرمجيات كثيرًا. في النهاية ، ما زلنا نستخدم مشغلي if ، بينما الحلقات ، ومشغلي المهام الذين استخدمناهم مرة أخرى في الستينيات. إذا أخذت مبرمجًا منذ عام 1960 وجلبته إلى هنا حتى يتمكن من الجلوس على جهاز الكمبيوتر المحمول الخاص بي واكتب رمزًا ، فسيستغرق الأمر 24 ساعة للتعافي من الصدمة ، لكن يمكنه كتابة هذا الرمز. المبادئ لم تتغير كثيرا.
في عملية كتابة البرامج ، تغيرت ثلاثة أشياء. أنا لا أتحدث عن الأجهزة ، وليس عن سرعة الكمبيوتر ، وليس عن الأدوات الرائعة التي لدينا. أعني الكود نفسه. لقد تغيرت ثلاثة أشياء في الكود. يمكنك الاتصال بهم نماذج. وقد تم اكتشافهم جميعًا منذ أكثر من عقد مضى منذ أكثر من 40 عامًا.
* 1968 -
البرمجة الإنشائية . كتب
Edsger Dijkstra مقالته: "عن مخاطر مشغل Go To" وعدد من المستندات والمقالات الأخرى التي تقترح التخلي عن نهج Go To الجامح ، واستبداله بأدوات مثل if / then / else ، وأثناء الحلقات.
* 1966 -
البرمجة الشيئية .
أولي يوهان دال وكريستن نيوجور ، الذين يدرسون لغة
الغول ، "اكتشفوا" الأشياء
وخلقوا أول لغة موجهة للكائنات ، سيمولا 67. على الرغم من أن هذا الإنجاز له العديد من الفرص ، إلا أنه لم يجلب أي ميزات جديدة إلى نظامنا. بالإضافة إلى ذلك ، أزال واحدة. بعد كل شيء ، مع ظهور تعدد الأشكال ، اختفت الحاجة إلى مؤشرات إلى الوظائف ، لكنها اختفت بالفعل.
* 1957 -
البرمجة الوظيفية .
جون مكارثي يخلق لغة ليسب ، أول لغة وظيفية. اعتمد ليسب على
حساب التفاضل والتكامل لامدا التي أنشأتها كنيسة ألونزو في 30s. على الرغم من وجود العديد من احتمالات البرمجة الوظيفية ، إلا أن هناك قيودًا كبيرة واحدة في جميع البرامج الوظيفية. انهم لا يستخدمون المهمة.
ثلاثة نماذج. ثلاثة قيود. البرمجة الهيكلية تحدد قواعد نقل التحكم المباشر. البرمجة الموجهة للكائنات تقدم قواعد للنقل غير المباشر للسيطرة. تقدم البرمجة الوظيفية قيودًا على الواجب. كل هذه النماذج قد اتخذت بعيدا شيئا. لم يضف أي منهم أي ميزات جديدة. كل واحد منهم زاد المتطلبات وقلص الفرص.
هل يمكننا إنشاء نموذج آخر؟ هل هناك أي شيء آخر يمكن إزالته؟
على مدار 40 عامًا ، لم يكن هناك نموذج جديد ، لذلك ربما تكون هذه علامة جيدة على أنه لا يوجد شيء يمكن البحث عنه.
يجب أن نستخدم كل هذه النماذج ، أو يمكن أن نختار؟
مع مرور الوقت ، قررنا تنفيذها. تم تقديم أول برمجة منظمة بفضل إلغاء مبدأ Go To (كما أوصى Dijkstra في مقالته). تم تنفيذ OOP بنجاح عن طريق استبدال المؤشرات بالوظائف بلغاتنا الحديثة باستخدام تعدد الأشكال (مثل Java و C # و Ruby). لذلك ، على الأقل بالنسبة لهذين ، فإن الإجابة على هذا السؤال هي أننا يجب أن نستخدمها. تم استبعاد جميع الخيارات الأخرى أو على الأقل محدودة للغاية.
ولكن ماذا عن البرمجة الوظيفية؟ هل يجب أن نستخدم اللغات التي ليس لديها مشغل مهمة؟ ربما نعم! نكتب بالفعل الكود الذي يجب أن يعمل بشكل جيد على العديد من النوى ، وتتضاعف هذه النوى مثل الأرانب. جهاز الكمبيوتر المحمول لديه 4 النوى. على الأرجح سيكون لدي رقم 8. على الأرجح. رقم 8. بعد 16. كيف ستكتب رمزًا موثوقًا به مع 4096 معالجًا يناضلون من أجل الحق في الوصول إلى الحافلة؟
بالكاد يمكننا الحصول على اثنين من مؤشرات الترابط المتوازية للعمل ، ناهيك عن المعالجات 2 ^ n.
لماذا تعد البرمجة الوظيفية جزءًا مهمًا من حل هذه المشكلة؟ لأن مثل هذه البرامج لا تستخدم المهمة ، مما يعني أنها ليس لها آثار جانبية ، وبالتالي ، ليس لديها مشاكل مرتبطة بالتحديث - على الأقل هذه هي النظرية.
سنتحدث أكثر عن البرمجة الوظيفية في المدونات المستقبلية. ما أدهشني في النماذج الثلاثة المذكورة أعلاه هو تواريخها. إنها قديمة ، أقدم مني تقريبًا. ومنذ أن بلغت السادسة عشر من العمر ، قبل 42 عامًا ، لم يكن هناك من جديد.