هل حقا هاسكل هي لغة العباقرة والأوساط الأكاديمية؟

سبق لي أن ناقشت مع مؤسس شركة إسرائيلية ناشئة تطوير قاعدة بيانات تستند إلى GPU مع التركيز على السرعة. تضمنت مجموعة العمل Haskell و C ++ ، من بين آخرين ، والمؤسس كان يشكو من صعوبة إيجاد مبرمجين أكفاء. الذي كان جزءًا من السبب الذي دفع به إلى موسكو.

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

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

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

ومع ذلك ، أخبرني شخصان عن تجاربهما ، الموضحة أدناه.

دينيس ميرزوف ( نولان ) : عندما كنت في الكلية ، عرضوا عليّ أن أقوم بدورة دراسية على كورسيرا في هاسكل للحصول على رصيد إضافي. ثم كان لدينا أيضا دورة البرمجة الوظيفية التي شملت هاسكل. لقد كتبت واحدة من أوراق الفصل الدراسي ، بالإضافة إلى ورقة التخرج ، على GHC. ثم وجدت وظيفة كمبرمج هاسكل.

كان ولا يزال صعبا. عندما تبدأ في تعلم Haskell ، عليك أن تضع الكثير من المفاهيم الجديدة في ذهنك. يشبه تعلم الكود من البداية من جديد.

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

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

لا تكون البرامج التعليمية سهلة الاستخدام للغاية ، على الرغم من أن خلفياتها الأساسية تمنع ظهور مفاهيم جديدة.

يوري Syrovetskiy ( cblp ) : أصعب شيء هو تعلم هاسكل كلغتك الثانية ، عندما ذكريات من تعلم الأولى لا تزال حية ،

ما هو حسكل الجيد والسيئ؟

Doctor_Ryner : إنه موجز وأنيق ومرن. لا عجب أن نصف المكتبات الموجودة على EDSL (أو على الأقل تشعر بها).

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

جون دو : كتابة صارمة وقوية (حتى فاشي).

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

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

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

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

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

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

Doctor_Ryner : إذا امتثلت ، فربما تكون سريعة جدًا.

دينيس ميرزوف : من حيث الأداء ، فإنه يشبه Java ، ولكن ليس بنفس سرعة C.

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

Doctor_Ryner : تحتوي مكتبة Prelude القياسية على الكثير من الوظائف السيئة مثل القراءة ، الرأس ، readFile ، والتي يمكنها التخلص من استثناء وتعطيل التطبيق بدلاً من العودة ربما. لذلك لا بد لي من استخدام البدائل أو كتابة بلدي.

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

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

ما هي المشاريع التي يناسبها هاسكل؟

YS : بالنسبة إلى المهام المعقدة المتعلقة بالأمان والتمويل ، حيث تكون الأخطاء باهظة الثمن.

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

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

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

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

هل هي فكرة جيدة أن تبدأ مسيرتك التطويرية مع هاسكل؟

IS : ربما لا ، لأن الغالبية العظمى من قواعد الكود التي يجب على المطور التعامل معها غير مكتوب عليها.

جون دو : فكرة سيئة! ستكون اللغات غير متعددة اللغات - والتي تمثل كل شيء تقريبًا في التطبيقات الصناعية - صدمة لك.

DS : غالبًا ما يتعلم الناس الرياضيات أولاً ، ويتحولون إلى البرمجة لاحقًا. من الناحية النظرية ، يجب أن يكون تعلم اللغة التي تتطلب الكثير من مفاهيم الرياضيات (أنواع البيانات الجبرية ، والوظائف البحتة) أسهل من اللغات الإلزامية. أعتقد أنها فكرة جيدة.

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

YS : من الأفضل أن تبدأ ببضع لغات مختلفة اختلافًا جذريًا ، على سبيل المثال C و Haskell و Smalltalk ، بأي ترتيب. لا توجد لغة واحدة يمكن أن تعطيك فهم كامل للمشهد.

هاسكل هي لغة قديمة. هل هو جيد أم سيء؟

YS : تم تطوير اللغة بشكل نشط للغاية ، ولا تسحب وزن التوافق للخلف من أجلها.

John Doe : لقد تم توحيده في عام 1998 ، لكنك لن تلاحظ: حتى يومنا هذا ، كل 6 أشهر تقريبًا هناك إصدار مترجم جديد يمكن أن يحطم التوافق مع الإصدارات السابقة.

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

كثيرا ما يقال إن هاسكل هي واحدة من أصعب اللغات التي يجب تعلمها. هل هو حقا؟

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

جون دو : لقد استغرق الأمر مني شهرين من الكتب المدرسية قبل النوم والأدلة والبرامج التعليمية لمجرد الحصول على مشروعي الأول. الأفكار ، بمجرد أن تم تجميعها أخيرًا ، عملت فورًا تحت حمولة كاملة (متوسط ​​6 كيلو بايت في الثانية ، مع 15k قمم) لمدة نصف عام دون أي تغييرات على الإطلاق.

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

هو : كل ​​شيء قريب. من بين اللغات الرئيسية ، أعتبر لغة C ++ هي الأصعب. لغات إثبات النظرية (مثل Agda أو Coq) أصعب من Haskell من الناحية النظرية. هاسكل ليست لغة صعبة ، لكن الأمر يتطلب بعض الوقت لتعلم نمطها ومكتباتها (القياسية والثالثة).

هل تعقيده مبرر؟

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

Doctor_Ryner : يتيح لك التعقيد في هاسكل في كثير من الأحيان تقديم حلول قصيرة ومرنة ونموذجية.

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

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

غالبًا ما يقال إن هاسكل ليست لغة للمطورين ، ولكن للرياضيين. هل هذا هو السبب في أنها ليست التيار؟

دي إس : إنها تعرض الفكرة الرئيسية للمطورين الرئيسيين في هاسكل - "تجنب النجاح بأي ثمن". لا يعني "تجنب النجاح" ، ولكن "تجنب مكلفته للغاية من النجاح".

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

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

YS : فقط الأشخاص الذين لا يعرفون أي شيء عن ذلك يقولون ذلك. يستخدم Haskell كثيرًا في تطوير "العالم الحقيقي" ، وربما تجد أمثلة في محرك البحث المفضل لديك. على وجه الخصوص ، نحن في Kaspersky Labs سعداء جدًا بـ Haskell ولن نتاجر به لأي شيء آخر.

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

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

ما الذي تقارن به هاسكل؟

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

DS : أعرف C ، C ++ ، Java و Haskell. C ++ أمر مرعب ولا يمكن مقارنته بأي شيء. C هو عظيم للتنمية على مستوى منخفض. في جميع التطبيقات الأخرى كنت أفضل Haskell.

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

Doctor_Ryner : أقارن مع C #. جوجل فقط "كيف نفعل ربما في C # و Haskell". من الغريب أن تكون هذه اللغة الوظيفية الصارمة مثل هاسكل أكثر مرونة وحرية. لكن في الواقع ، هم الأضداد القطبية.

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

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

ما رأيك في مجتمع هاسكل؟

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

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

تتعلم دائمًا شيئًا لم تفكر فيه من قبل.

يقال إن مطوري هاسكل ممتلئين بأنفسهم. هل هذا صحيح؟

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

جون دو : لا شيء من هذا القبيل.

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

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

لماذا لغات FP متخصصة؟

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

هو : حسنا ، مفاهيم FP تنزف ببطء طريقهم إلى لغات أخرى ...

Doctor_Ryner : المبادئ الأساسية لـ FP ولغاتها واسعة الانتشار بالفعل. حتى Sharp لديها Linq وبعض المكتبات الأخرى المشابهة. لكن من المحتمل أن يكون للغات الوظيفية البحتة الكثير من المفاهيم الجديدة لتكون شعبية.

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