تعلم البرمجة السريعة: هل هي جاهزة لوقت الذروة؟

أدى إطلاق Apple في يونيو الماضي لـ Swift ، وهي لغة برمجة جديدة لكتابة تطبيقات iOS ، إلى خلق قدر كبير من الضجة والإثارة في جميع أنحاء مجتمع مطوري iOS.

منذ إطلاقه ، كان العديد من مطوري iOS يكافحون مع مسألة ما إذا كان وكيف ومتى يتم الانتقال من Objective-C إلى Swift. ستكون الإجابة على هذا السؤال مختلفة بالطبع لكل فريق وكل مشروع.

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

لكن أولاً ، لنعد عقارب الساعة إلى الوراء قليلاً ...

قبل Swift: ستستخدم Objective-C ، وستعجبك ...

كان العام 2010. لم يكن عمر iPhone 3 سنوات بعد ، وكانت القدرة على كتابة تطبيقات أصلية له موجودة منذ حوالي عامين فقط. في الثامن من أبريل من ذلك العام ، أعلنت شركة Apple عن إصدار نظام تشغيل iPhone. تضمن نظام تشغيل iPhone (كان هذا قبل تغيير اسمه إلى iOS) ميزات جديدة محيرة مثل تعدد المهام ، والتبديل السريع بين التطبيقات ، وخدمات الخلفية. من المفهوم أن مطوري iPhone كانوا حريصين على الحصول على SDK الجديد والبدء في اللعب بكل هذه الميزات الجديدة المثيرة.

لكن iPhone OS 4 SDK احتوى على قنبلة غير متوقعة. هذه القنبلة لم تكن في البرنامج ، كانت في اتفاقية الاستخدام. باستخدام iPhone OS 4 SDK ، تم تحديث القسم 3.3.1 من اتفاقية المطور ليشمل اللغة المقلقة التالية:

يجب كتابة الطلبات في الأصل بلغة Objective-C و C و C ++ ... ولا يجوز إلا للشفرة المكتوبة بلغة C و C ++ و Objective-C تجميع وربط مباشرة مع واجهات برمجة التطبيقات الموثقة.
- القسم 3.3.1 من اتفاقية مطور iPhone OS 4 SDK

وغني عن القول ، أن هذا التقييد الجديد فاجأ العديد من المطورين. كان السبب الرسمي للتغيير ، الذي قدمه ستيف جوبز نفسه ، هو منع استخدام الأدوات عبر الأنظمة الأساسية مثل Flash CS5 الذي تم الإعلان عنه مؤخرًا. نُقل عن جوبز قوله إن "الطبقات الوسيطة بين النظام الأساسي والمطور تنتج في النهاية تطبيقات دون المستوى [كذا]". لكن حقيقة أن نهج Apple لمكافحة هذه "الطبقات المتوسطة" كان تقييد لغات البرمجة التي يمكن استخدامها لكتابة تطبيقات iPhone كشفت شيئًا أكثر عن تفكير Apple: يجب أن يكون Objective-C جيدًا بما يكفي لأي شخص.

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

في النهاية ، وتحت ضغط من مجتمع المطورين عمومًا ، ألغت Apple هذه التغييرات على القسم 3.3.1 من اتفاقية مطور SDK بعد خمسة أشهر فقط. ومع ذلك ، كانت الرسالة واضحة: إذا كنت تريد كتابة تطبيقات لجهاز iPhone ، فمن المحتمل أن تستخدم Objective-C.

... أو ربما لا. أدخل سويفت لغة iOS الجديدة.

تقدم سريعًا لمدة 4 سنوات من تلك الحادثة حتى يونيو 2014 عندما قدمت Apple للمطورين لغتها الجديدة ، Swift. إذا كانت الرسالة قبل 4 سنوات هي أن Apple كانت راضية تمامًا عن Objective-C ، فإن الرسالة التي أرسلتها مقدمة Swift كانت أن Apple مستعدة أخيرًا للاعتراف بالحقيقة. قد لا تكون Objective-C بالضرورة أفضل لغة لكتابة تطبيقات الأجهزة المحمولة.

لقد قيل الكثير حول كيف أن Swift هي لغة أكثر "حداثة" من Objective-C. إذا كنت مهتمًا بكيفية تعلم لغة برمجة Swift ، فقد ترغب في الاطلاع على دليل الانتقال من Objective-C إلى Swift.

ما يجب أن تلاحظه ، مع ذلك ، هو أن هناك اختلافين مهمين بين لغتي Objective-C و Swift:

1. Swift ليست مجموعة شاملة صارمة للغة C.
2. يتم كتابة Swift بشكل ثابت ، وليس كتابته ديناميكيًا.

عدم كونها مجموعة شاملة صارمة لـ C يعني أن Swift حرة في الاستفادة من التركيبات النحوية التي لن يُسمح بها بخلاف ذلك. هذا يجعل من الممكن ، على سبيل المثال ، تنفيذ عوامل تشغيل مخصصة في Swift.

تعني الكتابة الثابتة أن Swift يمكنها الاستفادة من العديد من التطورات الحديثة في أنظمة الكتابة التي ابتكرتها لغات مثل Haskell.

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

التوافق مع Objective-C

يشترك iOS في تراث مشترك مع OS X ، والذي بدوره يأخذ تاريخه من نظام التشغيل NeXTSTEP الذي تم إصداره لأول مرة في عام 1989. تمت كتابة NeXTSTEP في الأصل إلى حد كبير في Objective-C ، والعديد من المكتبات الأساسية في OS X و iOS تتبع جذورها جميعًا طريق العودة إلى هذه التطبيقات الأصلية. (بالمناسبة ، هذا هو المكان الذي تأتي منه بادئة "NS" في كل مكان الموجودة في الفئات الأساسية مثل NSString .) بينما يمكن أن توجد Swift نظريًا في غياب هذه المكتبات الأساسية ، فإن الحقيقة هي أن أي برامج Swift قد تكتبها في المستقبل القريب سيتعين عليك التفاعل مع Objective-C.

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

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

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

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

أسرع من Objective-C؟

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

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

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

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

المترجم

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

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

في أي وقت تسمع فيه أن المحلل اللغوي للغة في حالة تغير مستمر ، يجب أن يتوقف مؤقتًا. محلل اللغة هو قلب وروح لغة البرمجة. قبل أن يتم تطبيق أي دلالات لغوية لنقل المعنى إلى الكود ، فإن المحلل اللغوي هو الذي يحدد ما هو الكود الصالح وما هو غير صالح للبدء به. من المشجع ، إذن ، أن Apple وعدت بضمان مستوى معين من توافق وقت التشغيل لـ Swift. هذا لا يضمن بالضرورة ، مع ذلك ، أن كود Swift سيعمل دون إعادة تجميعه لكل إصدار جديد من Xcode و / أو iOS. كما أنه لا يضمن أنك لن تحتاج إلى إعادة كتابة أجزاء من كود Swift الخاص بك لتظل متوافقًا مع الإصدارات المستقبلية من Swift. ولكن مرة أخرى ، فإن التزام Apple بجعل هذه العملية غير مؤلمة قدر الإمكان هو على الأقل بعض العزاء الصغير.

تواصل اجتماعي

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

للأسف ، لا يتمتع مجتمع iOS / Objective-C بأفضل سمعة لكونه ودودًا ومرحبًا. هذا يتغير تدريجيًا ، والمصدر المفتوح يلعب بشكل متزايد دورًا أكثر أهمية في تطوير Objective-C. ومع ذلك ، في هذه المرحلة المبكرة ، من الصعب معرفة الشكل الذي سيبدو عليه مجتمع Swift للمضي قدمًا. هل ستتكون في الغالب من مطورين منعزلين يعملون فقط من خلال واجهات برمجة تطبيقات Apple الرسمية ومجموعاتهم الخاصة من التعليمات البرمجية؟ أم سيكون مجتمعًا حيويًا من المجموعات التي تشارك النصائح والحيل والمكتبات المفيدة؟

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

ومع ذلك ، فإن المطورين الذين يقفون وراء Swift هم ​​من نفس المطورين وراء مشروع LLVM طويل الأمد. LLVM ليس تشبيهًا مثاليًا ، لأنه بدأ الحياة في العراء كمشروع من جامعة إلينوي ، أوربانا شامبين. ولكن يُحسب للمطورين الأساسيين أن يظلوا منفتحين للغاية ويتفاعلون مع المجتمع ، حتى بعد انتقال معظمهم إلى العمل لدى Apple. من المعقول تمامًا توقع استمرار تطوير لغة Swift (في الغالب) في العلن ، على الرغم من أن التصحيحات والاقتراحات الخاصة بالميزات من المجتمع ستشق طريقها إلى اللغة أم لا.

هل يجب أن أتعلم Swift؟

لا توجد ، بالطبع ، إجابة "مقاس واحد يناسب الجميع" هنا. كما هو الحال دائمًا ، يتطلب اختيار الأداة المناسبة للوظيفة معرفة وثيقة بجميع تفاصيل المشروع المعني. بالتأكيد ، في هذا الوقت ، يظل Objective-C الخيار "الآمن" لتطوير iOS ، لكن Swift يستحق بالتأكيد النظر فيه.

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