مرحبا زملائي.
منذ وقت ليس ببعيد ، قمنا بطباعة
كتاب Odersky و Spoon و Wenners حول Scala 2.12. بعد كل شيء ، إلى Scala 3 لا يزال بعيدًا.
مؤلف مقال اليوم هو Adam Worski ، المؤسس المشارك لـ SoftwareMill ومطور Scala ذو خبرة. حصل على ملخص مثير للاهتمام لنقاط قوة لغة سكالا الحديثة ، والتي نلفت انتباهك إليها.
بعد
محاضرة عامة لمارتن أودرسكي حول ScalaDays ، حيث أوجز خطط Scala 3
ومحاضرة عامة كتبها John de Goes في مؤتمر Scalapeño حول مستقبل
Scala ، تستمر المناقشات الحية في
مجتمع Scala . بصرف النظر عن مناقشات هذه العروض التقديمية العامة ، يتم إجراء العديد من المناقشات على Twitter ، في مجتمعات Slack ، وكذلك على reddit (انظر ، على سبيل المثال ،
1 ،
2 ).
هذا هو السؤال!كل هذا مثير للاهتمام ومفيد للغاية للمتخصصين الذين يعملون بالفعل في النظام البيئي Scala. ومع ذلك ، فإن الكثير من الجدل يتعلق بمختلف العيوب الملموسة أو الفعلية للسكالا كلغة. يمكن لهذه اللحظات أن تخيف الناس "من الخارج" ، مما يجعلهم يسألون: "لماذا يجب علي استخدام Scala على الإطلاق؟" ، "ماذا لو كانت هذه طريق مسدود؟" ، "هل سيكرر Scala 3 نجاح Python 3؟" الخ. كما هو الحال في معظم المناقشات ، فإن النقاط الأضعف والأكثر عاطفية تجذب الانتباه ، وهذا النقاش ليس استثناءً.
لذلك دعونا
نعود خطوة إلى الوراء : لماذا تحتاج حتى سكالا؟ ما هي الأسباب التقنية والتجارية للعمل بهذه اللغة؟
مجال موضوع المشروعبادئ ذي بدء ، لغة سكالا جيدة بشكل خاص لمجالات معينة (ولكن ليس للجميع!). أهم أصول سكالا هو
مرونته في تحديد التجريد . تحت تصرفكم - عدد من "الطوب" البسيط لذلك ؛ أحيانًا لا يكون تعريف التجريد أكثر صعوبة من استخدام فئة وأساليب وتعابير لامدا. في بعض الأحيان يجب عليك استخدام معلمة ضمنية أو طريقة تمديد ؛ في حالات نادرة ، يبقى اللجوء إلى أوامر الماكرو فقط. ومع ذلك ،
هناك خيارات .
وبالتالي ، Scala مثالي لك إذا كنت بحاجة إلى
التنقل في منطقة موضوع معقدة . على سبيل المثال ، يمكننا التحدث عن البرمجة الموزعة أو التنافسية. التزامن صعب للغاية ، ولدى Scala عدد من المكتبات التي تبسط هذه المهمة من خلال بناء التجريد. هناك طريقتان رئيسيتان لهذا: الممثل ، الذي تم تنفيذه مع
Akka ، وبروح FP ، مقدم من
Monix /
cats-effect و
Scalaz /
ZIO (إذا كنت ترغب في قراءة المزيد حول مقارنة هذه الأدوات - لقد كتبت
سلسلة من المقالات حول هذا الموضوع )
ومع ذلك ، بالطبع ، يمكننا التحدث عن مجالات مواضيع أخرى. تمكننا إمكانات Scala أيضًا من الارتقاء بنمذجة تطبيقات الأعمال النموذجية إلى المستوى التالي. لكن في هذه الحالة نحن نتحدث عن تعقيد نظام مختلف. في حالة الأنظمة الموزعة ، نواجه تعقيدًا تقنيًا. عند برمجة منطق الأعمال في التطبيقات ، نحن نتحدث بالفعل عن تعقيد مجال الموضوع على هذا النحو. على سبيل المثال ، يشرح كتاب Debasish Ghosh "
نمذجة المجال الوظيفية والتفاعلية " كيفية الجمع بين DDD والبرمجة الوظيفية والتفاعلية.
صعوبة اللغةملاحظة: عند الحديث عن Scala ، يحب الجميع التأكيد على اتساع إمكانيات هذه اللغة ، مع التأكيد على أنه بسبب هذا التنوع ، فإن هذه اللغة معقدة للغاية. هذا ليس صحيحًا تمامًا.
كما ذكر أعلاه ، لدى Scala عدد من التركيبات الأساسية التي يمكن بناء التجريد منها. ومع ذلك ، يمكن
دمجها جميعًا مع بعضها البعض ، والتي تكتسب اللغة مثل هذه المرونة. تنقسم معظم المشاريع المبتكرة التي قد تصادفها إلى مزيج واحد أو آخر من أنواع الطلبات الأعلى ، والمعلمات الضمنية والكتابة الفرعية.
وبالتالي ، مع وجود عدد صغير نسبيًا من الميزات الأساسية (حجم قواعد Scala أبسط من Kotlin أو Java أو Swift!) - مما يسهل بدوره التعلم - خيارات الجمع أكثر بكثير.
هل الخيار عريض جدا؟ لا أعتقد ذلك. المبرمج ، كمحترف كفؤ ومسؤول ، هو أكثر من قادر على اختيار الخيار الأفضل لحل مشكلة معينة. لمزيد من المعلومات ، راجع مقالة "
Simple Scala Stack ".
جافا أفضل فقطهناك الكثير من الحديث الآن عن أن
Kotlin قد حل محل Scala على أنه "مثل Java ، فقط أفضل". لكنني أعتقد أن
سكالا ، وليس كوتلن ، هي التي لا تزال تستحق مثل هذا اللقب. هناك سببان رئيسيان لهذا:
أولا ،
الثبات في سكالا هو الأسمى . هذا يرجع إلى طبيعة سكالا على هذا النحو: كتابة التعليمات البرمجية عليه مريحة في المقام الأول بمساعدة البيانات الثابتة. تتضمن هذه البيانات ، على وجه الخصوص:
val (كوحدات من الفئة الأولى) ، وفئات
case ، ووظائف الترتيب الأعلى ، وما إلى ذلك. ولكن النقطة هي كيف يتم تصميم وكتابة مكتبة لغة سكالا القياسية ؛ جميع هياكل البيانات المستخدمة بشكل افتراضي ثابتة. بفضل الثبات ، يتم تبسيط عدد من الأشياء ، خاصة في عالم المنافسة العالية لدينا ، حيث تفوز هذه اللغات ، حيث يفضل الثبات.
ثانيًا ، يدعم Scala مُنشئي
الأنواع ، وأنواع الطلبات الأعلى ، وأنواع الفئات (المُعلن عنها ضمنيًا) ، والتي تبسط إلى حد كبير العمل مع أنواع التغليف / الحاويات ، على سبيل المثال ،
Promise أو
Future أو
Task . تسود هذه الأغلفة عند البرمجة بأسلوب غير متزامن أو تفاعلي ، ووجود تراكيب لغوية تبسط العمل ، على سبيل المثال ، مع قاعدة التعليمات البرمجية حيث يتم استخدام
Future بنشاط هو حجة أخرى لصالح Scala.
ما هي أنواع الفصول؟ دورها هو تقريبًا نفس دور أنماط التصميم في Java ، ومع ذلك ، فهي أكثر مرونة وسهولة في الاستخدام بمجرد إدراك معانيها. هناك بعض الأدلة الممتازة حول هذا ، مثل
1 ،
2 .
ماذا عن مصنعي النوع؟ هذه هي أنواع مثل
Future أو
Option ، وتعمل بمثابة "حاويات" أو "أغلفة" لأنواع أخرى. لذلك ، يمكن أن يكون لديك
Option[String] أو
Future[Int] . تسمح لك أنواع الطلبات الأعلى بكتابة تعليمات برمجية تلخص أي غلاف. انظر على سبيل المثال.
1 ،
2 .
فجأة تتساءل ، لماذا حتى تلجأ إلى
Future /
Task ؟ لا يقتصر الأمر على أن معظم الحسابات "التفاعلية" عالية الأداء مع الحد الأدنى من التأخير يتم إجراؤها باستخدام الإدخال / الإخراج غير المتزامن ، حيث يتم طلب هذه التصاميم فقط. هناك أسباب أخرى في هذا
النقاش حول reddit وفي مقالتي "
لماذا تهتم بأغلفة؟ "
يؤدي العمل في بيئة لا تتغير في الغالب ، بالإضافة إلى القدرة على التعامل مع بنيات مثل
Future أو
Promise أو
Task (وتجريدها!) بشكل جذري إلى تغيير التعليمات البرمجية الخاصة بك بشكل جذري. للوهلة الأولى ، قد لا يكون هذا واضحًا: إذا كانت لديك خبرة Java أو Ruby خلفك ، فلن تتمكن من إدراك هذه الجوانب من Scala على الفور. ولكن ، حتى من وجهة نظر تعليمية ، من المفيد فهم كيفية عمل النهج "الوظيفي" ، والأهم من ذلك ، لماذا يمكن أن يصبح
بديلاً جديرًا بالاهتمام .
بطبيعة الحال ، لكل من سكالا وكوتلن عدد من المزايا المشتركة على جافا ، على سبيل المثال:
- بناء جملة أكثر إحكاما
- كود أقل النمطية
- نظام أكثر ثراءً
- عدم وجود ثقل اللغة
وفي الوقت نفسه ، توفر كلتا اللغتين إمكانية الوصول إلى النظام البيئي للمكتبات وأطر عمل JVM.
كلما كان نظام النوع أكثر ثراءً (في Scala ، أصبح أكثر ثراءً من Kotlin ، وفي Kotlin - أكثر ثراءً من Java) ، كلما تم تنفيذ أعمال التحقق من قبل المترجم ، وليس من قبل الشخص. ولهذا السبب تم إنشاء أجهزة الكمبيوتر: للقيام بمهام متكررة مملة وروتينية. إن التحقق من إمكانية تطبيق الأنواع هو بالتأكيد إحدى هذه المهام.
في الوقت نفسه ، يعد نظام النوع الغني مفيدًا ليس فقط عند
كتابة التعليمات البرمجية ، ولكن أيضًا ، إلى حد كبير ، عند
قراءة التعليمات البرمجية . عندما يكون من السهل عليك التنقل في قاعدة التعليمات البرمجية ، لفهم ما تفعله ، علاوة على ذلك ، ليس من المخيف (أو ليس مخيفًا جدًا) إجراء
إعادة الهيكلة ، وهذا يميز اللغة بشكل إيجابي للغاية من الناحية الفنية والتطبيقية.
FP مقابل OOPسؤال آخر غالبًا ما يُثار في مثل هذه المناقشات هو ما إذا كانت لغة Scala يجب أن تستمر في التمسك بتوليف OOP و FP ، أم يجب أن تتطور على طول مسار وظيفي بحت. أنا
مؤيد للتوليف ، خاصة لأن FP و OOP ، في رأيي ، ليسا نهجين بديلين ، بل يكملان بعضهما البعض.
تقوم FP
بالبرمجة باستخدام الوظائف ، ولكن ليس أيًا منها ، ولكنها شفافة مرجعيًا (راجع هذه
الإجابة على reddit في سلسلة
رسائل سابقة ، حيث يتم شرح الشفافية المرجعية بشكل مثالي). في OOP ، يتم تنظيم التواصل مع الكائنات باستخدام "الرسائل" أو ، في مصطلحاتنا ، المكالمات بالطرق الافتراضية. لا يوجد سبب واحد لعدم تمكن هذين النهجين من التعايش ، وقد أثبت سكالا ذلك بالفعل!
في
تغريدة حول فضائل Scala ، يذكر John de Goes بعض ميزات OOP المفيدة في نهج وظيفي بحت ، على وجه الخصوص ،
وحدات الدرجة الأولى (التي يتم الحصول عليها عن طريق تأليف الكائنات) ،
وبناء الجملة (طرق الاستدعاء في الكائنات) ،
وفئات / أنواع
المثيلات كإنشاءات من الدرجة الأولى . كل هذه عناصر لمزيج ناجح من نموذجين. ربما بعض المزيد قاب قوسين أو أدنى؟
لم يكتمل مشروع "التوليف" بعد ، فهناك بالتأكيد مجال للنقاش هنا. أحد الجوانب غير المكتملة هو البنية المقترحة لطرق التمديد ، والتي يجب أن تحل محل التحويلات الضمنية الأكثر إرباكًا. آخر هو تحسين بنية فئات النوع ؛
من الواضح
أن الاقتراح الذي تم تقديمه منذ فترة غير واضح ولا يغطي بعض الاستخدامات الأكثر شيوعًا للموناد في سكالا. بعض الاقتراحات أفضل ، والبعض الآخر يحتاج إلى صقل ، ولكن من الجيد تلقيها وإجراء مناقشات بشأنها ؛ بفضلهم ، تعيش اللغة ، وفي النهاية ، يتم إصلاح أفضل حل فيها.
سكالا 3سكالا 3 سيصدر خلال عامين. سيظهر فيه عدد من الاحتمالات المثيرة للاهتمام ، على وجه الخصوص ، الأنواع غير الشفافة ، ومعلمات السمات ، ونهج جديد للخطأ ، وأنواع الاتحاد والتقاطع ، وأنواع الوظائف الضمنية - هذه ليست سوى أمثلة قليلة. بالطبع ، هناك قلق (مبرر) بشأن الهجرة.
من المعروف بالفعل أنه سيتم إدخال أداة خاصة
لترحيل التعليمات البرمجية تلقائيًا من Scala 2 إلى Scala 3 باستخدام
scalafix . نظرًا لأن Scala هي لغة مكتوبة بشكل ثابت ، يمكن حل هذه المهمة على نطاق واسع وهي أبسط بكثير ، على سبيل المثال ، في Python. ولكن ، بالطبع ، لا يوجد سحر هنا: حتى إذا كانت هذه الأداة توفر تغطية صحيحة بنسبة 99٪ للشفرة ، فإن 1٪ من الحالات الأكثر إشكالية ستظل باقية. نظرًا لأنه لا يمكنك الاعتماد على السحر ، سيلزم ترحيل هذه الأجزاء يدويًا.
هذه هي تكاليف العمل بلغة نشيطة: تحصل على أحدث الفرص ، لكن بعضها في الواقع ليس جيدًا جدًا ويجب تحسينه. ومع ذلك ، فإن التغييرات المقترحة ليست ثورية. لغة سكالا 3 تشبه إلى حد بعيد لغة سكالا 2 ، ولا يُتوقع حدوث تغييرات كبيرة في النموذج.
من المشجع أن فريق سكالا جاد بشأن الهجرة. في حين أن الترحيل المبكر بين الإصدارات القديمة من Scala (على سبيل المثال من 2.8 إلى 2.9) كان مرهقًا إلى حد كبير ، فقد كانت عمليات الترحيل الأخيرة أفضل بكثير. هناك ثلاثة أطراف رئيسية معنية: EPFL و
ScalaCenter و
Lightbend تعمل جميعها (غالبًا معًا) لتسهيل الهجرة. على سبيل المثال ، هناك أداة
MIMA متوافقة مع الثنائيات ، ويتم إنشاء العديد من المكتبات الجديدة باستمرار في المجتمع لضمان العمل المريح مع الإصدارات الجديدة من Scala.
أخيرًا ، يجب أن تضمن أداة TASTY التي لم تكتمل بعد (والتي لا يمكن تقييمها وفقًا لذلك) استخدام الملفات الثنائية من سكالا 2 إلى سكالا 3.
فلماذا تستخدم سكالا؟لذا ، ما هي أسباب التوقف عند سكالا ، إذا كنت تفكر في هذه اللغة من وجهة نظر تجارية؟ جميع المزايا التقنية المذكورة أعلاه مفيدة بشكل مباشر للأعمال التجارية. عندما تكون لديك لغة يمكنك من خلالها كتابة رمز معقد مع عدد أقل من الأخطاء ، فسيتم تزويدك بأقل قدر من التأخير من حيث المستخدمين والمرضى الراضين. إذا بدأت في كتابة تطبيقات تنافسية قوية ، غير قابلة للانزلاق عمليًا لـ Scala ، والتي يتم توفير أدوات خاصة لها في Scala ، فسوف يتحول ذلك إلى فائدة جدية لشركتك.
بالإضافة إلى ذلك ، لا تنسى
Spark ، المنصة الرائدة
لتحليل البيانات الموزعة . يتم استخدام Scala ليس فقط لتطبيق Spark على هذا النحو ، ولكن أيضًا لتحديد الحسابات نفسها. فيما يلي تجريد آخر موجه لعلم البيانات يخفي نموذجًا حسابيًا معقدًا.
الملخصبالطبع هناك مشاكل في سكالا ، لكن أين هم؟ سبب التفاؤل هو أن الكثير من الأشخاص الذين يستخدمون Scala يوميًا يعملون بنشاط على
تحسين الأدوات والمكتبات واللغة نفسها. يمكنني أن أفترض أنهم يواصلون العمل مع Scala على وجه التحديد لأنه ، مع جميع أوجه القصور المتاحة ، لا توجد لغة واحدة مناسبة تمامًا لمجال موضوعهم.
تسمح لك Scala بتطوير نمط البرمجة الخاص بك ، بغض النظر عن اللغة التي كنت تستخدمها: Java أو Ruby أو مجرد تجربة نفسك في البرمجة. لا يوجد نهج فريد من نوعه لسكالا. إما نهج عكا الأكثر
إلحاحًا ، أو نهج كاتس وسكالاز الأكثر
وظيفية .
هذا هو المكان الذي يمكن رؤية المشكلة فيه: هناك كسور في مجتمع سكالا تلتزم بنهج OOP / AF "التفاعلي" و "الاصطناعي" و AF النقي. ومع ذلك ، في الواقع هذه ميزة كبيرة. بسبب هذا التنوع ، تجري المناقشات ، ويتم التعبير عن العديد من الآراء المختلفة من وجهات نظر مختلفة. على هذا ، بدوره ، يمكنك أن تتعلم بشكل مثالي كيفية حل المشاكل غير القياسية وإثراء أدواتك الخاصة.
مهما كان المسار الذي تختاره في سكالا ، فسوف تحصل على الدعم من قبل مجتمع مثير للإعجاب من الزملاء المشاركين في تطوير المكتبات والأطر ؛ هؤلاء الأشخاص مستعدون دائمًا للمساعدة ومناقشة الأفكار الناشئة.