لماذا Kotlin رائع، لكنك ستبقى مع جافا على أي حال

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

هل تعرف لومبوك على الرغم من ذلك؟ إذا كنت لا تحبها، أنصحك بشدة بتجربتها. إذا أعجبتك، فلديّ شيء لك فقط لتجربته. لغة جديدة بالكامل، والتي بمميزاتها تجعل لغة لومبوك عفا عليها الزمن. تُدعى كوتلن.

كوتلين؟ هل تقصد لغة الأندرويد؟

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

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

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

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

جافا مع خطوات إضافية

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

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

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

مجموع الفن(أ: Int، ب: Int): Int {
   إرجاع أ + ب
}

يمكن أن يكون جسم الدالة تعبيرًا (باستخدام علامة المساواة)

متعة المجموع (أ: Int، ب: Int) = أ + ب

إذا كانت عبارة إذا يمكن أن توفر نتيجة

val y = إذا (x = = 1) {
 "واحد"
 } وإلا إذا (س = = = 2) { {
 "اثنان"
 } أخرى { {
 "آخر"
 }

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

القيمة؟.الأسلوب() // التنفيذ إذا لم يكن فارغًا

حسناً، التخلص من إذا (القيمة = = فارغة)نقطة لك. ماذا لديك أيضاً؟

التحقق من المرح(القائمة: قائمة، البديل: منطقي) = عندما {
 القائمة هي قائمة مرتبطة <قائمة -> اطبع("مرتبطة")
 بديل -> طباعة("بديل")
 list.size > 50 -> طباعة("كبير")
 أخرى -> طباعة("أخرى")
 }

جميل، يمكن أن يكون مفيدًا لتجنب الحجب في حالة وجود حواجز أخرى، ولكن لا يزال يبدو وكأنه وسيلة للتحايل.

كائن مفرد الجسم المفرد: عداد() {
 متغير a = 14
 متعة الاختبار() = إذا (أ > 10) "أكثر" وإلا "أقل"
 }

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

var s: سلسلة = فارغ // لا يُترجم، نوع غير فارغ

انتظر... ماذا؟

خطأ المليار دولار

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

var s: سلسلة؟ = لاغية

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

لكنني قررت أن أتعمق في اللغة، أليس كذلك؟ لنفعلها بطريقتك يا سيد كوتلن. بدأت أبذل جهدًا للتخلص من أكبر عدد ممكن من المتغيرات والحقول والمعلمات القابلة للإلغاء. وخطوةً بخطوة، تعلمت استخدام ميزات اللغة التي سهلت التخلص من المراجع القابلة للإلغاء، مثل عامل النداء الآمن "?."، وعامل الفيس "?:"، والخصائص المفوضة، وطريقة "let"، وغيرها.

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

العودة

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

هل تعرف ذلك الشعور عندما تبدأ في تقدير شيء ما في اللحظة التي يختفي فيها؟ عندما لا تدرك مدى اعتمادك على شيء ما حتى لا يمكنك استخدامه بعد الآن؟ لقد كان هذا أفضل مثال على هذا الشعور الذي ربما اختبرته في حياتي.

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

كانت ميزة الأمان الفارغة بالطبع أكثر ما افتقدته. ولكنني فوجئت بعدد الأشياء الصغيرة التي أصبحت طبيعية بالنسبة لي: المعلمات المسماة، والخصائص بدلًا من المُحصِّلات والمُحدِّدات، و"==" كمعادل و"===" كمساواة مرجعية، و"هذا" المؤهلة، ودوال الامتداد، ومعلمة لامدا المفرد الضمنية، و"_" لمعلمات لامدا غير المستخدمة، وفئات البيانات، ودوال النطاق، ودوال كوتلين stdlib الأخرى، والمشغِّلات وغيرها. والطريقة التي يتناسب بها كل ذلك معًا بشكل جيد. بالمقارنة، شعرت جافا ... بدائية.

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

التحقق من الواقع

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

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

مدير المشروع نعم! سيتفهم بالتأكيد القيمة العظيمة التي ستجلبها Kotlin لفريقنا. العظمة التي ستأتي!
-لا
-انتظر، لماذا؟
-الفريق لا يعرفها
-سوف يتعلمون!
-لا يريدون التعلم.
-يمكنك صنعها!
-لا يحتاجون إلى التعلم.
-أعني، هذا صحيح، ولكن فكر في الاحتمالات!
-Yea, what about you think about the problems first.

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

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

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

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

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

لماذا هذا المقال إذن؟

لقد قضيت للتو وقتًا طويلاً في كتابة مقال يبدو أنه ليس له أي مغزى. لماذا أحاول تعلم اللغة، إذا كنت تقول أنه لا فائدة منها على أي حال؟

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

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

اقرأ المزيد:

أفضل أنواع المشاريع لجافا

3 تحديات مشتركة في تطوير منتجات البرمجيات للشركات الناشئة

الطريقة الصحيحة للعثور على أفضل مطوري جافا