سويفت الوظيفية

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



دانييل بوبوف: مرحباً بالجميع. اليوم ، ضيفنا هو Evgeny Elchev من كراسنويارسك المشمسة. يوجين ، قل لي ماذا تفعل وكيف وصلت إلى البرمجة الوظيفية؟

يفغيني الشيف: مرحباً بالجميع. أنا مطور نظام iOS في Redmadrobot ، مثل أي شخص آخر ، أرسم الأزرار ، وأحيانًا أكتب منطق الأعمال.

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

دانييل بوبوف: إذن ، فإن الأحاديين قد ذهبوا بالفعل.

يفغيني الشيف: بالفعل صعب؟

دانييل بوبوف: حاولت أن أذهب بنفس الطريقة ، لكنني فتحت المقالة ، ورأيت عبارة "الكاري" ، "monad" وأغلقتها على الفور ، معتقدًا أنني لم أكن مستحقًا بعد. هل لدي فرصة؟

يفغيني الشيف: بالطبع. قد لا تعرف هذا على الإطلاق.

بكلمات بسيطة عن الوظيفية

دانييل بوبوف: دعنا نعطي تعريفًا بسيطًا لأولئك الذين لم يسمعوا أبدًا بنموذج وظيفي.

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

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

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

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

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

عند إنشاء اللغات ، بدأت تضيع الوظائف الأساسية ، وظهرت ميزات إضافية: lambdas ، وظائف عالية المستوى ، monads ، monoids.

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

إذا نظرت عن كثب ، فإن العديد من الأشياء التي نستخدمها في OOP تنعكس في نهج وظيفي. هناك فئات في OPP التي تضم مجموعة من الحقول. في FP ، يمكن القيام بذلك أيضًا باستخدام فئات الكتابة. كما يحب Vitaly Bragilevsky أن يقول : "إذا نظرت إلى الكمبيوتر اللوحي حيث تنتقل البيانات عبر الخطوط وأعمدة الوظائف ، ثم يسير FI على طول الأعمدة ، OOP يسير على طول الخطوط". هذا كل شيء.

دانييل بوبوف: ما علاقة FI بنماذج أخرى؟ هل يمكنني الكتابة وظيفيا في OOP؟ كيف تخلط النماذج ، وهل يعقل؟

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

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

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

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

نهج النهج الوظيفي في سويفت

أليكسي كودريافتسيف: كم يمكن أن يسمى سويفت لغة وظيفية؟

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

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

Evgeny Elchev: نعم ، في نظام iOS ، لن يتبع المترجم هذا. كل شيء على ضميرنا بالكامل: أثناء الكتابة ، سيكون الأمر كذلك.

أليكسي كودريافتسيف: أنت تقول إن هناك الكثير من الحالات في تطبيقات iOS ، لكن أين وماذا تفعل بها إذا كتبت بأسلوب وظيفي؟

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

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

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

دانييل بوبوف: تعتبر معظم اللغات الحديثة نماذج متعددة والعديد من الميزات الوظيفية. على سبيل المثال ، يوجد في Java تعليق توضيحي خاص للواجهة @FunctionalInterface ، والذي يلزم المطور بتحديد طريقة واحدة فقط في الواجهة ، بحيث يتم استخدام هذه الواجهة في شكل lambdas في التعليمات البرمجية بالكامل. عندما تضيف طريقة ثانية أو تحذف طريقة موجودة ، سيبدأ المحول البرمجي أقسم أنه لم يعد واجهة وظيفية. هل لدى سويفت ، بخلاف منصة iOS ، هذه الميزات الوظيفية؟

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

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

ليس لدينا أي محاضرين أو محاضرين. لا يمكن حتى كتابتها. من المفترض أن تساعد الميزات الجديدة في Swift 5.1 في القيام بذلك ، لكنني حاولت كتابة هذا الرمز ، وسقط xCode.

من حيث المبدأ ، في Swift ، إذا كنت ترغب في ذلك ، فمن السهل أن تفعل كل شيء بنفسك. يوجد بالفعل monad اختياري خارج الصندوق (في Haskell - ربما). لديها خريطة وخريطة مسطحة لبناء حساب خطي.

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

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

لماذا يحتاج الناشط إلى الوظيفية؟

دانييل بوبوف: كيف يكون النهج الوظيفي مفيدًا لتطوير الهاتف المحمول؟ هل هناك أي مشاكل يحلها؟

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

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

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

بعد النموذج الوظيفي ، يمكنك الحصول على مصدر إضافي للإلهام.

دانييل بوبوف: إذا بدأت في كتابة مثل هذه الطبقات الثابتة في لغة OOP وباستخدام طرق غير قابلة للتغيير ، هل يمكنني أن أقول أنني أكتب وظيفيًا؟

يفغيني الشيف: نعم ، بينما تبدأ في رؤية الايجابيات. أصبح من الأسهل اختبار الأساليب بسبب عدم وجود حالة عالمية ، ومن السهل إنشاء سلسلة من العمليات الحسابية من الأساليب.

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

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

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

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

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

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

يفغيني الشيف: أنت على حق. و Unix-way تدور حوله ، و Rx هو مزيج من فكرة الربط والتفاعل. في FP ، نربط مصدر الحدث وفي سلسلة الحساب نغيره ، ونربط النتيجة بالحالة النهائية.

دانييل بوبوف: هل اللغات متعددة النماذج جيدة على الإطلاق ، ما مدى ملاءمة ومفيدة ، بحيث يمكن للغة أن تفعل هذا وذاك؟

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

عندما يكون من الممكن اختيار أداة أكثر ملاءمة لمهمة محددة - فهذا أمر رائع.

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

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

حول مناد جام

أليكسي كودريافتسيف: عودة إلى الوظيفية ، ما هو الأحادي؟

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

تخيل المربع الذي تكمن فيه الفراولة ، وهناك جهاز يسمح لك بصنع مربى الفراولة ، لكن لا يمكنك وضع مربع من الفراولة فيه ، تحتاج إلى سكبه. Monads - هذا هو الشيء الذي يسمح لك بوضع مربع في الجهاز.

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

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

Evgeny Elchev: الجمال هو أنه ليس عليك الصعود إلى الصندوق. يمكنك رمي مربع.

وظيفة للنخبة؟

دانييل بوبوف: هناك رأي مفاده أنه لا يمكن ممارسة البرمجة الوظيفية دون الحصول على درجة الدكتوراه في الرياضيات. هل هذا صحيح؟

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

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

يفغيني الشيف: لا على الإطلاق. إذا لم تكن مهووسًا ولن تكتب نظامًا بيئيًا ضخمًا به مصممون ، فيمكنك استخدام نفس النمط المطابق.

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

من أين تبدأ؟

دانييل بوبوف: ما الذي يجب على المبتدئين قراءته لفهم البرمجة الوظيفية؟

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

دانييل بوبوف : أصعب شيء هو كسر النموذج في رأسك.

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

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

إذا كان الخوف الأساسي من الوظيفية قد مر ، فقم بإلقاء نظرة على تقرير فيتالي براجيلفسكي من AppsConf في الربيع. ومع ذلك ، في موسم خريف AppsConf ، سنتطرق إلى موضوعات لا تقل إثارة للاهتمام - يتطلع مجتمع iOS إلى تقرير مقدم من Daniil Goncharov حول الهندسة العكسية Bluetooth ، وسيناقش مطورو Android مع Alexander Smirnov الأساليب الحالية لبناء الرسوم المتحركة