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

• الجولانج والغوروتين ؛
• جافا سكريبت وقابلية تطبيقه على المشاريع الجادة ؛
• جافا و Project Loom ؛
• برمجة الأولمبياد على Kotlin ؛
• كيفية تعلم البرمجة بشكل صحيح ؛
• وأشياء أخرى مثيرة.

Kotlin - أحسنت!

مرحبًا أولاً ، بضع كلمات عن نفسك. هل كنت تفعل Kotlin لفترة طويلة؟

لدي تاريخ طويل مع Kotlin. في عام 2010 ، بدأ Kotlin كمشروع في JetBrains ، حيث لم أكن أعمل في ذلك الوقت. لكن ماكس شافيروف (كان منخرطًا في Kotlin وكان أحد المبادرين لهذه الحركة داخل JetBrains) دعاني لأصبح خبيرًا خارجيًا وألقي نظرة على التصميم والتعليق. في البداية ، تم تصميم اللغة لحل مشاكلها ، لأن JetBrains لديها قاعدة كبيرة خاصة بها من كود Java ، مع وجود مشاكل مفهومة موجودة باستمرار في الرمز ، وأردت أن أجعل اللغة لنفسي من أجل كتابة التعليمات البرمجية الخاصة بي أكثر متعة وفعالية ، مع عدد أقل من الأخطاء. فقط قم بالتحديث. وبطبيعة الحال ، نما هذا بسرعة إلى فكرة أنه نظرًا لأن لدينا مثل هذه المشاكل ، فهذا يعني أن الآخرين لديهم مثل هذه المشاكل ، وكانوا بحاجة إلى تأكيد من الآخرين أنهم يسيرون في الطريق الصحيح.

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

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

في ذلك الوقت (2012-2013) ، كان Kotlin مشهدًا حزينًا من وجهة نظر الضبط ، لأن كل شيء تباطأ هناك. منذ ذلك الحين ، قام الفريق بعمل عظيم. انضممت إلى الفريق قبل عامين ، مباشرة بعد إصدار 1.0 وقبل أن تتعرف Google رسميًا على اللغة. كفريق ، تناولت جميع أنواع التزامن والتشكيلات ، ببساطة لأنه اتضح أن لدي الخبرة المناسبة ، عملت كثيرًا في مختلف أنظمة المؤسسات الكبيرة المختلفة في DevExperts ، وهناك الكثير من التزامن والتواصل. لذلك ، تخيلت جيدًا مناطق المشاكل - ما الذي يجب إصلاحه وما يؤذي الناس. هذا وقع بشكل جيد على احتياجات Kotlin ، لأنه لا يؤلمنا فقط. يؤلم الجميع. حتى JVM بدأ مشروع Loom ، والذي ، كما هو ، يشير إلى أنه يؤذي الجميع. ما زلت أتعامل مع مكتبات Kotlin ، وينصب تركيزنا الرئيسي على جميع أنواع التطبيقات المتصلة وعدم التزامن.

أي أنك تعمل بشكل أساسي في المكتبات ، وليس مترجمًا ، وهذا كل شيء؟

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

اتضح ، إذا ذهبت إلى YouTrack ، فقم بالفلترة من قبلك ، يمكنك العثور على الكثير من الأشياء المثيرة للاهتمام.

نعم ، يمكنك العثور على مجموعة من جميع أنواع المهام ، لأنني أصادف شيئًا باستمرار.

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

رأيت عرضا ، الفكرة واضحة. يحتاج الجميع إلى coroutines والبرمجة غير المتزامنة. على سبيل المثال ، في الماضي في JPoint ، أخبر الرجال من Alibaba كيف قاموا باختراق JVM وأفسدوا نقطة الاتصال ، فقط دحرجوا في رقعة لم يكتبوها ، ولكن بعض الرجال قبلهم. ورأوا لاحقا تحت أنفسهم. تقرير رائع. أوصي به بشدة.

هل توصي بفعل هذا؟

لذلك فمن الضروري القيام به في الشركات. كل مؤسسة كبيرة ، فوق حجم معين ، عندما يبدأ عدة آلاف من الأشخاص في العمل من أجلك (وبالنسبة لشخص أقل) ، حافظ على اختراق OpenJDK. وبالطبع ، إذا كانت لديك حالات مستخدم مهمة للأعمال ، فلماذا لا تخترق شيئًا ما لنفسك ، فلا أرى أي مشكلة كبيرة في ذلك. ليس هذا ما أوصي به ، ولكن يجب علي ذلك. إذا لم تكن هناك مؤشرات ترابط خفيفة في HotSpot ، فماذا أفعل؟ هذا ، في الواقع ، يشير إلى أن الناس بحاجة إلى ما هو ناضج. والتعليقات التي نحصل عليها على coroutines تقول أيضًا نعم ، لقد فات الأوان ، يحتاج الناس إلى تيارات خفيفة الوزن ، يحتاج الناس إلى عربة yuzkeys لتيارات خفيفة الوزن. لقد طال انتظار دعمهم بطريقة ما في JDK ، وبهذا المعنى لا أشك في أنه عندما يأتي Loom إلى الإنتاج عاجلاً أم آجلاً ، فإنه سيكون في الطلب. هناك أناس بحاجة إليها. هناك أناس حتى من أجل هذا التصحيح HotSpot.

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

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

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

ولكن هناك مثل هذا الاختراق الماكر: عندما تعود إلى الأداء ، فإنهم لا ينسخونه كله ، ولكن فقط الأعلى.

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

ورمز جوش أيضا؟

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

يُطرح علينا السؤال باستمرار: "ما هو الأسرع؟ ما هو مناسب؟ كيف تفعل ذلك في coroutines؟ " نحن في coroutines لا اختراق القرص المشترك. هدفنا هو أن يعمل هذا تحت JVM العادي. ويعمل Android أيضًا. هناك فن خاص بها ، والذي لا يعرف شيئًا عن coroutines. وبالتالي ، بطبيعة الحال ، يجب علينا إنشاء وحدات بايت مع الأقلام ، والتي تفعل شيئًا مشابهًا جدًا لنسخ المكدس الذي يفعله Loom ، فقط نقوم بذلك في الرمز البايت. نحن نأخذها عندما يكون الوقت متأخرًا بالفعل. خذ كومة ، استرخ ونسخها إلى الورك. نحن لسنا في وقت تشغيل من شأنه أن يفعل ذلك بالنسبة لنا ، لقد أنشأنا رمزًا ثانويًا يفعل ذلك. يحافظ ويعيد حالة coroutine. نظرًا لأننا لا نقوم بوقت التشغيل ، بالطبع ، لدينا المزيد من النفقات العامة من هذا. في وقت التشغيل ، يمكنك القيام بكل شيء بشكل أسرع. من ناحية أخرى ، إذا كنت تستخدم coroutines للبرمجة غير المتزامنة ، فأنت بحاجة إلى النوم ، إذا تركت انتظار رد من خدمة ما ، وإرسال طلب إلى خدمة ما يعد مكلفًا للغاية بحيث لا يزعج الحمل الكلي على نسخ المكدس أي شخص على الإطلاق - سواء كانت بطيئة أو سريعة ، لا يهم على الإطلاق. نعم ، إذا كنت تستخدمه خصيصًا للبرمجة غير المتزامنة. على coroutines في Kotlin ، يتم قياسه بشكل ملحوظ ، كما هو موضح في النموذج الأولي Project Loom.

فرق آخر هو أنه نظرًا لأننا في Kotlin مجبرون على القيام بذلك في البايت كود ، فلدينا مثل هذا التأثير الجانبي المثير للاهتمام. من ناحية ، يبدو أنه غير ناجح ، ومن ناحية أخرى ، على العكس. وتتكون مما يلي: من المستحيل الموت الرحيم لوظيفة اعتباطية. أنت بحاجة إلى وظائف يمكن أن تنام ، وتعلق إشارة مع المعدِّل - لاحظ صراحة أن الوظيفة قد تتوقف مؤقتًا وتنتظر شيئًا طويلاً. من ناحية ، لا تحتاج إلى هذا في Loom ، لأن وقت التشغيل يمكن أن ينام أي شيء. حل Alibaba هو نفسه - يمكنك أخذ مكدس من أي خيط. أو في Go - يمكن قفل كل شيء هناك ، يمكن أن ينام أي رمز. حشو gorutin وتفعل ذلك. من ناحية ، يشبه هذا النهج إلى حد كبير البرمجة بالخيوط. يبدو الأمر كما لو كنت تقوم بالبرمجة كما كان من قبل ، فقط الآن تسمى الخيوط بالألياف وأصبحت رخيصة جدًا. إذا نظرت بعناية إلى عرض Loom نفسه ، فقد اتضح أن الألياف والخيوط لا تزال أشياء مختلفة. كيفية التأكد من أن الكود القديم المكتوب بخيوط قد انتهى تمامًا من العلبة الموجودة على الألياف - هذا ليس واضحًا ، وما الذي سينجحون فيه - لا أحد يعرف. تبدأ المشاكل من هناك: ما يجب فعله مع حالات الجمود ، وما يجب القيام به مع التعليمات البرمجية التي تم تحسينها لمواقع سلسلة المحادثات ، ومرة ​​أخرى تقوم بعض التجزئة أو معرف سلسلة الرسائل ببعض تحسينات الأداء. وتواجه Go نفس المشكلة - عندما لا يتم الكشف عن معرفات الأجهزة ، فإن كتابة نوع من خوارزمية عالية الأداء تصبح غير تافهة.

ولكن في Kotlin ليس هذا؟

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

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

ومن ناحية أخرى ، فإننا نجعل شخصًا يفكر بشكل صريح في واجهة برمجة التطبيقات الخاصة به ، ويقول: هنا أكتب وظيفة في Kotlin مع coroutines. إذا نظرت سابقًا إلى طريقة ما في الرمز الخاص بي ، فاحصل على ما هو غير واضح ، فهذه الطريقة تعمل بسرعة وتعود فورًا أو تذهب إلى الإنترنت ويمكن أن تعمل لمدة ساعة - يمكنني فقط قراءة الوثائق وفهم مدى سرعة عملها. أو ربما يعمل بسرعة الآن ، وغدًا سيأتي المبرمج Vasya Pupkin ويجعله يتصل بالإنترنت الآن. مع Kotlin Coroutines ، نقدم آلية مضمونة اللغة مع معدل تعليق . عندما أعمل مع coroutines بنفسي ، أنظر إلى بعض الوظائف ، إذا لم أشاهد معدّل التوقف المرحلي ، فهذا يعني أنه يعمل بسرعة ، ويفعل كل شيء محليًا. يوجد مُعدِّل مُعلق ، مما يعني أن هذه الوظيفة غير متزامنة إلى حد ما ، وسوف تستمر في الشبكة لفترة طويلة. ويساعد ذلك على إنشاء واجهة برمجة تطبيقات للتوثيق الذاتي حتى نتمكن من رؤية ما ينتظرنا على الفور. هذا يساعد على تجنب الأخطاء الغبية على الفور عندما نسيت في مكان ما وفي مكان ما في الرمز الذي دعوت إليه بشيء طويل دون الشك فيه.

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

ولكن هناك بعض الأشياء التي يصعب حظرها ، على سبيل المثال ، نوعًا من ملف IO للشبكة.

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

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

أعتقد كم هي آمنة. هل يمكن لشخص كسر تجمع سلسلة رسائل أو اقتحام بيانات شخص آخر؟

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

لقد تعلمت من طلاب Kotlin ما هو السؤال المثير للاهتمام الذي يمكنك طرحه. استسلموا وقالوا إنك ماكر للغاية وتتجنب بمرونة أسئلتهم.

من أي أسئلة؟

على سبيل المثال ، نجا سؤال واحد من شخصين: لماذا لا توجد أنواع خام في Kotlin؟ لا أدوية جنيسة.

لأنه يمكنك دائمًا كتابة علامة النجمة.

وهل ستكون متوافقة مع Java؟

نعم

بمعنى ، لديك نوع من طريقة جافا تتطلب شيئًا بدون عام. قائمة ، على سبيل المثال.

إذا كان هناك مثل هذا الأسلوب جافا بدون عام ، يمكنك تمرير أي قائمة هناك. يمكنك نقل القائمة بعلامة النجمة ، يمكنك بسلسلة. سيتيح لك Kotlin نقل أي لعبة إلى طريقة Java. raw List, platform type, , , List . raw type, , Java , . Java, , , , , , raw type. , — , . , — . — , , raw types. , migration story.

platform type ?

flexible. nullable-. , String. , String nullable String — . , String — nullable -nullable. Kotlin , , . String, nullable String. , - Java, .

?

, , , , . Flexible , dynamic. Flexible — , Java, String, nullable String, int.

- - , .

, , . . read only mutable. List MutableList. Java List, , Java- , , - List MutableList. , Java. , Java - , . , , . , , , List, , , MutableList, List . List, String, .

- , ? - ?

, . , . It just works. Java . nullability- , , nullable . , . , , , . , , , , - . , -. - JavaFx, - , JavaFx Java, , . , - , . . , , .

, .

بالطبع. , . Kotlin Native. : , seamless C- , , - .

, Native ?

, , Kotlin JavaScript, - - . «Write once, run anywhere», , . : , Common Kotlin Portable Kotlin, , . , - - , , . , , - . , .

JVM , Java, JS , JS, Native . , , , , . - JS, . -. - : double, String. JVM- 0 «0.0», JS . . JS , , — ? , . , , JS- . , -. , . - — , , — . , , , , JVM, JS, Native — , , - . .

?

نعم , , .

, …

, . , . Loom . - JVM. , .

, , Java?

, . . — . , . , - . , for ( i in 0..10 ) , for (int i = first . , , . . , .

- ?

, … , . . JVM JS.

Node.js?

! . , JS-. , , JS- . , . , - — , JS-, - — . , . .

« ». , ?

بالطبع. , , . JVM , Java, . JVM . legacy, enterprise, . , , . , JVM. , — , . , . , — JVM « ». . API , . , . , . , , . , , .

TechTrain « ?» . . , .

JS , Kotlin Java?

Java . «Kotlin in Action», , Java-. , Java- , , Kotlin-. , «by design». , Java- . . JPoint , Kotlin . , . , 60-70% Java. Java, , - . Java .

- — , , -. as-is. , , . Kotlin , , «», «». , «» — . while — . 100500 . لكن لماذا؟ , Java-. - , « Kotlin», , .

, . . , , . , .

, -, ?

, . . Java- . Android- — , . . , . — .

- , ?

, . , , . , , . — , , . Kotlin . , . - , , , . : , . C++, Java, Python. . Java - , Java, . , , puiblic static void main… -, . Java, , . ?

Kotlin : , , Python, . C++ , C++ . , , . , . , , . Kotlin — . — Python. . . , . , . . — , , , , — . , .

, — ?

, . must have. , — . . , . — . , , , .

?

… , , . . JS- — . — . JS, , . - JS, type checkers, Flow TypeScript. - JS . Python. - DSL, . Django , . , . , , , . . Django, , CRUD-. , - — . -, - , , . . . Kotlin, , Java, . core belief Kotlin, .

, - , Kotlin ?

بالطبع! , , - CRUD-. : , , — , . -, — , . , TypeScript Flow — JS.

Kotlin , Kotlin JS TypeScript , . TS Kotlin/JS, , TS , JS-, . Kotlin/JS , . , .

, — double…

, . , , .

- .

.

?

أحمل الأولمبياد :-) وأنا شخصيا أشارك ، ولكن نادرا.

أرى فقط أن Java متاحة في الألعاب الأولمبية أحيانًا كإحدى اللغات الرئيسية.

الآن هو متاح دائما تقريبا. ظهرت منذ حوالي خمسة عشر عامًا. Java و C ++ هما لغتان قياسيتان تدعمهما جميعًا ، ثم اختلافات ، اعتمادًا على المنافسة.

هل من الصعب الفوز في جافا ، هل هناك أي نفقات خفية؟

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

نعم ، هناك منافسات شديدة حيث جافا صعبة. لكن المسابقات العادية (شعبية ، مدعومة من قبل أهل الخير) - يحاولون القيام بالمهام والبيئة بطريقة تجعل جافا والإيجابيات لها فرص متساوية. والأسباب واضحة: على الرغم من أن جافا لا تنمو في التعليم ، إلا أنها لا تنقص كثيرًا في أي مكان. في مكان ما ، رفضت بعض الجامعات تعلم Java وتحولت إلى Python - وبسبب هذا ، بما في ذلك ، تعلمت الآن العديد من المسابقات Python. هذه لغة ثالثة مستقرة مدعومة. المسابقات هي في الأساس طالب. هناك مسابقات احترافية ، وتقوم الشركات الكبيرة بشيء مثل كأس Hacker على Facebook ، حيث يمكن للجميع المشاركة ، ولكن لا يزال الموضوع الرئيسي في البرمجة الرياضية هو المدرسة والطالب. في سنوات المدرسة والطالب ، سوف يؤدي الناس باستمرار ويتدربون. ولكن بعد التخرج ، وبعد الذهاب إلى العمل - سيواصل عدد قليل جدًا من الأشخاص المشاركة. لذلك ، يتم تحديد اختيار اللغات من خلال ما يتم استخدامه في التعليم. إذا قاموا بتعليم الإيجابيات و Java و python ، فسيكونون في المسابقات. بالنسبة للعديد من المبرمجين ، Java هي اللغة الأولى ، على التوالي ، تحاول جميع المسابقات دعم Java. من أجل المنافسة لتعلم C ++ - لعبة. إنه لبرمجة النظام ، والبرمجة منخفضة المستوى ، لا تحتاج إلى وجود مليون مبرمج C ++ ، فهذا لا معنى له على الإطلاق.

كيف تحب فكرة إضافة Kotlin إلى قائمة اللغات القياسية؟

حسنًا ، في الواقع ، نحن نشجع هذه الفكرة بنشاط. هناك ICPC ، الذي يقام سنويًا ، ويجمع مئات الآلاف من المشاركين حول العالم ، ويذهب أكثر من مائة فريق إلى النهائيات. في ICPC ، يتم دعم Kotlin. الآن هناك قائمة باللغات: C / C ++ و Java و Python و Kotlin. ولكن في الوقت الحالي ، بالطبع ، لا أحد يكتب عليها حقًا ، لسبب هذه المشكلة: الاختراق في التعليم في مرحلة مبكرة جدًا. في مسابقات الطلاب ، يتم استخدام تلك اللغات التي يتم تدريسها للطلاب.

هل يتم تعليم Kotlin بالفعل في مكان ما؟

تدرس في مكان ما بالضبط. على سبيل المثال ، في بوليتكنيك سانت بطرسبرغ. لكننا في مرحلة مبكرة للغاية ، في "الخطوة 0" من هذه العملية.

لا توجد عيوب قاتلة؟

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

المكافأة ، على سبيل المثال ، هي أن الشخص الذي يتركها سيكون أكثر تكيفًا مع الواقع.

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

أليس كذلك معنا؟

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

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

لأنك ستكسب الكثير من المال باستخدام الميزات الرائعة لهذه التكنولوجيا.

بالطبع لا! في Kotlin ، من المرجح أن تحصل على المزيد من المتعة.

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

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

هذا أمر ممل للغاية بطريقة ما ، إن لم يكن رهيبًا.

هذه هي حقيقة الحياة ، للأسف. مهما كانت فظيعة. وهؤلاء الناس بالطبع لا يهتمون. Kotlin ، وليس Kotlin.

بقدر ما أفهم ، يعمل الكثير من الناس في JetBrains لأنهم يحبون العمل.

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

إن وقتنا يقترب من نهايته ببطء ، لذا فإن السؤال هو: هل يمكنك تمرير شيء لقرائنا في حبري؟ أي كلمات فراق ، بعض الوحي؟

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

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

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

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