منذ بعض الوقت ، قام مبتكر لغة برمجة لوا ، روبرتو إيروساليمشي ، بزيارة مكتبنا في موسكو. سألناه بعض الأسئلة التي أعددناها بمشاركة مستخدمي Habr.com أيضًا. وأخيرًا ، نود أن نشارك نسخة النص الكامل لهذه المقابلة.
- لنبدأ مع بعض المسائل الفلسفية. تخيل ، إذا قمت بإعادة إنشاء لوا من نقطة الصفر ، ما هي الأشياء الثلاثة التي ستغيرها في لوا؟- واو! هذا سؤال صعب. هناك الكثير من التاريخ المضمن في إنشاء وتطوير اللغة. لم يكن مثل قرار كبير دفعة واحدة. هناك بعض الأسف ، والتي أتيحت لي فرصة لتصحيح العديد منها على مر السنين. يشكو الناس من ذلك طوال الوقت بسبب التوافق. لقد فعلنا ذلك عدة مرات. أنا أفكر فقط في الأشياء الصغيرة.
- العالمية افتراضيا؟ هل تعتقد أن هذا هو الطريق؟- ربما. ولكن من الصعب للغاية بالنسبة للغات ديناميكية. ربما يكون الحل هو عدم وجود افتراضات على الإطلاق ، ولكن سيكون من الصعب استخدام المتغيرات بعد ذلك.
على سبيل المثال ، يجب أن تعلن بطريقة أو بأخرى جميع المكتبات القياسية. تريد خطًا واحدًا ،
print(sin(x)) ، ثم يتعين عليك الإعلان عن "print" وأيضًا إعلان "sin". لذلك من الغريب أن يكون لدينا تصريحات لهذا النوع من النصوص القصيرة جدًا.
أي شيء أكبر يجب ألا يكون له أي افتراضات ، على ما أعتقد. المحلي افتراضيًا ليس هو الحل ، فهو غير موجود. إنه مخصص فقط للمهام وليس للاستخدام. شيء نخصصه ، ثم نستخدمه ثم نخصصه ، وهناك بعض الأخطاء - الغموض التام.
ربما لا يكون الوضع الافتراضي عالميًا مثاليًا ، ولكن بالتأكيد لا يعد الحل الافتراضي محليًا. أعتقد أن هناك نوعًا من الإعلانات ، وربما إعلانًا اختياريًا ... كان لدينا هذا الاقتراح عدة مرات - نوع من الإعلان العالمي. لكن في النهاية ، أعتقد أن المشكلة تكمن في أن يبدأ الناس في طلب المزيد والمزيد ونحن نستسلم.
(بسخرية) نعم ، سنطرح إعلانًا عالميًا - أضف ذلك وذاك ، أخرج ذلك ، وفي النهاية نفهم أن الاستنتاج النهائي لن يرضي معظم الناس ولن نضع جميع الخيارات التي يريدها الجميع ، لذلك نحن لا نضع أي شيء. في النهاية ، وضع صارم هو حل وسط معقول.
هناك هذه المشكلة: غالبًا ما نستخدم حقولًا داخل الوحدات النمطية على سبيل المثال ، عندئذٍ لديك نفس المشكلات مرة أخرى. إنها مجرد حالة واحدة محددة للغاية من الأخطاء التي يجب أن يتضمنها الحل العام. لذلك أعتقد أنه إذا كنت تريد ذلك حقًا ، فيجب عليك استخدام لغة مطبوعة بشكل ثابت.
- العالمية افتراضيا هو أيضا لطيفة لملفات التكوين الصغيرة.- نعم ، بالضبط ، للبرامج النصية الصغيرة وهلم جرا.
- لا المفاضلات هنا؟- لا ، هناك دائما مفاضلات. هناك مفاضلة بين البرامج النصية الصغيرة والبرامج الحقيقية أو شيء من هذا القبيل.
- لذلك ، نحن نعود إلى السؤال الكبير الأول: ثلاثة أشياء يمكنك تغييرها إذا كانت لديك الفرصة. كما أراها ، أنت سعيد تمامًا بما لدينا الآن ، هل هذا صحيح؟- حسنًا ، إنه ليس تغييرًا كبيرًا ، لكنه لا يزال ... ديوننا المعدومة التي أصبحت تغييرًا كبيرًا هي جداول في الصفر. إنه شيء أشعر بالأسف حقًا. فعلت هذا النوع من التنفيذ ، نوع من الاختراق ... هل رأيت ما فعلت؟ لقد أرسلت نسخة من لوا منذ حوالي ستة أشهر أو قبل عام والتي كان لها صفرا في الجداول.
- لا شيء القيم؟- بالضبط. أعتقد أنه تم استدعاء nils في الجداول - ما يسمى null. لقد فعلنا بعض الاختراق في قواعد اللغة لجعلها متوافقة إلى حد ما.
- لماذا هو مطلوب؟- أنا مقتنع حقًا أن هذه مشكلة كاملة من الثقوب ... أعتقد أن معظم مشاكل الصفائف في المصفوفات ستختفي ، إذا أمكننا الحصول عليها [جداول في الجداول] ... لأن المشكلة الدقيقة ليست مشكلة في المصفوفات. يقول الناس أنه لا يمكن أن يكون لدينا صفائف في الصفائف ، لذلك يجب فصل الصفائف عن الجداول. لكن المشكلة الحقيقية هي أنه لا يمكن أن يكون لدينا صفائح في الجداول! لذا فإن المشكلة تكمن في الجداول ، وليس الطريقة التي نمثل بها المصفوفات. إذا استطعنا الحصول على صفائف في الجداول ، فسنكون صفائف في صفائف دون أي شيء آخر. لذا فإن هذا شيء يؤسفني حقًا ، ولا يفهم الكثير من الأشخاص كيف ستتغير الأمور إذا سمحت Lua بعدم وجود أسماء في الجداول.
- هل لي أن أحكي لك قصة عن تارانتول؟ لدينا بالفعل تطبيقنا الخاص بـ null ، والذي هو CDATA إلى مؤشر null. نستخدمها عندما تكون الفجوات في الذاكرة مطلوبة. لملء الحجج الموضعية عندما نجري مكالمات عن بُعد وما إلى ذلك. لكننا نعاني منه عادة لأن CDATA يتم تحويله دائمًا إلى "صواب". لذا فإن الصفوف في المصفوفات سوف تحل الكثير من مشاكلنا.- نعم اعلم. هذا هو بالضبط وجهة نظري - هذا من شأنه أن يحل الكثير من المشاكل لكثير من الناس ، ولكن هناك مشكلة كبيرة من التوافق. ليست لدينا الطاقة اللازمة لإصدار إصدار غير متوافق تمامًا ، ثم كسر المجتمع ولدينا وثائق مختلفة لـ Lua 5 و Lua 6 ، إلخ. ولكن ربما في يوم من الأيام سنصدرها. لكنه تغيير كبير حقا. أعتقد أنه كان ينبغي أن يكون الأمر كذلك منذ البداية - إذا كان الأمر كذلك ، فسيكون تغييرًا تافهًا في اللغة ، باستثناء التوافق. انه يكسر الكثير من البرامج ، بطرق خفية جدا.
- ما هي الجوانب السلبية باستثناء التوافق؟- إلى جانب التوافق ، الجانب السلبي هو أننا سنحتاج إلى عمليتين جديدتين ، وظيفتين جديدتين. مثل "حذف المفتاح" ، لأن تعيين nil لن يحذف المفتاح ، لذلك سيكون لدينا نوع من العمليات البدائية لحذف المفتاح وإزالته بالفعل من الجدول. و "اختبار" للتحقق من المكان بالضبط للتمييز بين لا شيء وغياب. لذلك نحن بحاجة إلى وظيفتين بدائية.
- هل قمت بتحليل تأثير هذا على تطبيقات حقيقية؟- نعم ، أصدرنا نسخة من لوا مع ذلك. وكما قلت ، فإنه يكسر الكود بعدة طرق خفية. هناك أشخاص يقومون بـ table.insert (f (x)) - استدعاء دالة. وهو عن قصد ، حسب التصميم أنه عندما لا ترغب إحدى الوظائف في إدراج أي شيء ، فإنها تُرجع إلى الصفر. لذا بدلاً من التحقق المنفصل "هل أريد أن أدرج؟" ، ثم اتصل بجدول. أدخل ، وأعلم أنه إذا كان لا شيء ، فلن يتم إدراجه. نظرًا لأن كل شيء في كل لغة ، يصبح الخلل ميزة ، ويستخدم الناس هذه الميزة - ولكن إذا قمت بتغييرها ، يمكنك كسر الرمز.
- ماذا عن نوع جديد باطل؟ مثل لا شيء ، ولكن باطل؟- أوه لا ، هذا كابوس. أنت فقط تؤجل المشكلة ، إذا وضعت مشكلة أخرى ، فأنت بحاجة إلى مشكلة أخرى وآخر. هذا ليس هو الحل. المشكلة الرئيسية - حسناً ، ليست رئيسية ، ولكن إحدى المشاكل - هي أن لا شيء قد ترسخت بالفعل في كثير من الأماكن باللغة. على سبيل المثال ، مثال نموذجي للغاية. نقول: يجب تجنب الصفوف في المصفوفات والثقوب. ولكن بعد ذلك ، لدينا وظائف تعيد صفرًا وشيءًا بعد الصفر ، لذلك نحصل على رمز خطأ. لذا فإن هذا البناء في حد ذاته يفترض ما يمثله لا شيء ... على سبيل المثال ، إذا كنت أرغب في عمل قائمة بإرجاع هذه الوظيفة ، فقط لالتقاط كل هذه العوائد.
- لهذا السبب لديك اختراق لهذا. :)- تمامًا ، ولكن لا يتعين عليك استخدام الاختراقات في [المشكلة] البدائية والواضحة. لكن الطريقة التي تم بها بناء المكتبات ... فكرت في ذلك من قبل - ربما ينبغي أن تعيد المكتبات خطأ كاذبة بدلاً من لا شيء - لكنها حل نصف طهي ، فهي لا تحل سوى جزء صغير من المشكلة. المشكلة الحقيقية ، كما قلت ، هي أنه ينبغي أن يكون لدينا جداول في الجداول. إذا لم يكن الأمر كذلك ، فربما لا ينبغي لنا استخدام نيلز بشكل متكرر مثلما نفعل الآن. كل شيء كيندا فوضوي. لذلك ، إذا قمت بإنشاء فراغ ، فستظل هذه الدالات لا تحتوي على شيء ، وستظل لدينا هذه المشكلة ما لم ننشئ نوعًا جديدًا وستعيد الدالات فراغًا بدلاً من الصفر.
- يمكن استخدام الفراغ لإخبار صراحة أن المفتاح يجب أن يبقى في جدول - مفتاح ذو قيمة باطلة. ولا يمكن أن يتصرف كما كان من قبل.- نعم ، هذا ما أقصده. يجب أن ترجع جميع الوظائف في المكتبات باطلة أو لا شيء.
- لا يزال بإمكانهم العودة لا شيء ، لماذا لا؟- لأننا لا نزال نواجه مشكلة أنه لا يمكنك التقاط بعض الوظائف.
- ولكن لن يكون هناك مفتاح أول ، فقط مفتاح ثانٍ.- لا ، لن يكون هناك مفتاح ثانٍ ، لأن العد سيكون خاطئًا وسيكون لديك ثقب في الصفيف.
- نعم ، هل تقول أنك بحاجة إلى metamethod كاذبة؟- نعم. حلمي شيء كهذا:
{f(x)}يجب عليك التقاط جميع عائدات الدالة
f(x) . وبعد ذلك يمكنني أن أفعل
%x أو
#x ،
#x عدد مرات إرجاع الوظيفة. هذا ما يجب أن تفعله لغة معقولة. لذا فإن إنشاء فراغ لن يحل ذلك ، إلا إذا كان لدينا قاعدة قوية للغاية وهي أن الوظائف يجب ألا تُرجع أبدًا ، ولكن لماذا نحتاج إلى عدم وجود؟ ربما يجب علينا تجنب ذلك.
- روبرتو ، هل سيكون هناك دعم تحليل ثابت أقوى بكثير لوا؟ مثل "لوا تحقق على المنشطات." وأنا أعلم أنه لن يحل جميع المشاكل ، بالطبع. أنت تقول أن هذه ميزة لـ 6.0 ، إن وجدت ، أليس كذلك؟ لذا ، إذا كان في 5.x سيكون هناك أداة تحليل ثابتة قوية - إذا تم استثمار ساعات العمل وسنوات العمل - هل ستساعد حقًا؟- لا ، أعتقد أن أداة تحليل ثابتة قوية حقًا تسمى ... type system! إذا كنت تريد أداة قوية حقًا ، فيجب عليك استخدام لغة مطبوعة بشكل ثابت ، أو شيء مثل Haskell أو حتى شيء مع أنواع تابعة. ثم سيكون لديك أدوات تحليل قوية حقا.
- ولكن بعد ذلك لم يكن لديك لوا.- بالضبط ، لوا هو ل ...
- غير دقيق؟ لقد استمتعت حقا صورتك الزرافة على أنواع ثابتة وديناميكية.- نعم ، الشريحة الأخيرة.
الشريحة الأخيرة من حديث روبرتو إيروساليمشي "لماذا (ولماذا) لوا؟"
في لوا في مؤتمر موسكو 2019- بالنسبة للسؤال التالي الذي تم إعداده ، دعنا نعود إلى تلك الصورة. إذا كنت على صواب ، فإن موقفك هو أن Lua هي أداة صغيرة لطيفة مفيدة لحل المهام غير الكبيرة جدًا.- لا ، أعتقد أنه يمكنك القيام ببعض المهام الكبيرة ، ولكن ليس من خلال التحليل الثابت. أنا أؤمن بشدة بالاختبارات. بالمناسبة ، أنا لا أتفق معك على التغطية ، برأيك هو أننا لا يجب أن نلاحق التغطية ... أقصد ، أنا أوافق تمامًا على أن التغطية لا تتضمن اختبارًا كاملاً ، لكن عدم التغطية يعني اختبارًا بنسبة صفر في المئة. لذلك تحدثت عن غرفة اختبار - كنت هناك في ستوكهولم. لذلك بدأت تجربتي مع [بعض] الأخطاء - هذا أغرب شيء - أحدها كان مشهورًا ، والآخر غير مشهور تمامًا. إنه شيء مقطوع بالكامل في ملف رأس من Microsoft و C و C ++. لذلك أنا أبحث في الويب ولا أحد يهتم به أو حتى لاحظته.
على سبيل المثال ، هناك دالة رياضية ،
modf () ، حيث يجب عليك تمرير مؤشر إلى مزدوج لأنه يُرجع زوجي. نترجم الجزء الصحيح من الرقم أو الجزء الكسري. لذلك هذا جزء من مكتبة قياسية لفترة طويلة الآن. ثم جاء C 99 ، وتحتاج هذه الوظيفة للعوامات. كما احتفظ ملف الرأس من Microsoft بهذه الوظيفة وأعلن عن وظيفة أخرى ماكرو. لذلك حصلت على هذا واحد في نوع يلقي. لذلك يلقي المضاعف على التعويم ، حسناً ، ثم يلقي المؤشر للمضاعفة لتطفو المؤشر!
- هناك خطأ ما في هذه الصورة.- هذا ملف رأس من Visual C ++ و Visual C 2007. أعني ، إذا قمت بالاتصال بهذه الوظيفة مرة واحدة ، مع أي معلمات ، والتحقق من النتائج - سيكون من الخطأ ما لم تكن صفرية. خلاف ذلك ، فإن أي قيمة أخرى ستكون خاطئة. لن تستخدم هذه الوظيفة أبدًا. تغطية الصفر. ثم هناك الكثير من المناقشات حول الاختبار ... أعني ، ما عليك سوى استدعاء دالة مرة واحدة ، والتحقق من النتائج! لذلك هناك ، لقد كان هناك لفترة طويلة ، لسنوات عديدة لا أحد يهتم. واحد مشهور جدا كان في أبل.
شيء من هذا القبيل "
if… what… goto… ok " ، كان شيء من هذا القبيل. شخص ما وضع بيان آخر هنا. ثم كل شيء كان على ما يرام. وكان هناك الكثير من المناقشات التي يجب أن تكون لديك القواعد ، ويجب أن تكون الأقواس إلزامية في طريقتك ، وما إلى ذلك ، إلخ. لا أحد يذكر أن هناك الكثير من ifs هنا. لم يتم إعدامه ...
- هناك أيضًا مشكلة أمنية بقدر ما أتذكر.- نعم بالضبط. لأنهم كانوا فقط اختبار الحالات المعتمدة. لم يختبروا أي شيء ، لأنه سيتم اعتماد كل شيء. هذا يعني أنه لا توجد حالة اختبار واحدة في تطبيق الأمان تتحقق مما إذا كان يرفض بعض الاتصال أو أيًا كان يجب أن يرفضه. لذا يناقش الجميع ويقولون إنه يجب أن يكون لديهم أقواس ... يجب أن يكون لديهم اختبارات ، الحد الأدنى من الاختبارات! لأن أحداً لم يختبر ذلك ، فهذا ما أعنيه بالتغطية. إنه أمر لا يصدق كيف لا يقوم الناس بإجراء الاختبارات الأساسية. لأنهم إذا كانوا يقومون بجميع الاختبارات الأساسية ، فمن الطبيعي أن يكون ذلك بمثابة كابوس للقيام بكل التغطية وتنفيذ جميع الخطوط ، إلخ. يهمل الناس حتى الاختبارات الأساسية ، لذلك التغطية على الأقل حول الحد الأدنى. إنها وسيلة لجذب الانتباه إلى بعض أجزاء البرنامج التي نسيتها. إنه نوع من الدليل حول كيفية تحسين اختباراتك قليلاً.
- ما هو اختبار التغطية في Tarantool؟ 83٪! روبرتو ، ما هو اختبار التغطية لوا؟- حوالي 99.6. كم عدد سطور الكود لديك؟ مليون ومئات الآلاف؟ هذه أعداد ضخمة. واحد بالمائة من مئات الآلاف هو ألف سطر من التعليمات البرمجية التي لم يتم اختبارها مطلقًا. أنت لم تنفذ ذلك على الإطلاق. لا يختبر المستخدمون أي شيء.
- إذن هناك 17٪ من ميزات Tarantool غير المستخدمة حاليًا؟- لست متأكدًا مما إذا كنت ترغب في فك ارتباط كل شيء بالعودة إلى ما كنا عليه ... أعتقد أن إحدى مشكلات اللغات الديناميكية (واللغات الثابتة لهذه المسألة) هي أن الأشخاص لا يختبرون الأشياء. حتى إذا كان لديك لغة ثابتة ، إلا إذا كان لديك شيء ما - ليس حتى مثل Haskell ، ولكن Coq ، - بعض أنظمة الإثبات ، يمكنك تغيير ذلك لذلك أو ذاك. لا يمكن لأداة التحليل الثابت التقاط هذه الأخطاء ، لذلك تحتاج إلى اختبارات. وإذا كان لديك الاختبارات ، يمكنك اكتشاف المشاكل العالمية ، وإعادة تسمية الأخطاء الإملائية ، إلخ. كل هذه الأنواع من الأخطاء. يجب إجراء هذه الاختبارات على أي حال ، ربما يكون من الصعب في بعض الأحيان تصحيحها ، وأحيانًا لا يكون ذلك - يعتمد على اللغة ونوع الخطأ. لكن المشكلة هي أنه لا توجد أداة تحليل ثابتة يمكن أن تسمح لك بتجنب الاختبارات. من ناحية أخرى ، لا تثبت الاختبارات أبدًا عدم وجود خطأ ، لكنني أشعر بأمان أكبر بعد كل الاختبارات.
- لدينا سؤال حول اختبار وحدات لوا. كمطور ، أريد اختبار بعض الوظائف المحلية التي يمكن استخدامها لاحقًا. والسؤال هو: نريد أن نحصل على تغطية تبلغ حوالي 99 بالمائة ، ولكن بالنسبة إلى واجهة برمجة التطبيقات التي تنتجها هذه الوحدة ، يكون عدد الحالات الوظيفية التي يجب أن تنتجها أقل بكثير من الوظيفة التي تدعمها داخليًا.- لماذا هذا ، آسف؟
- هناك بعض الوظائف التي لا يمكن الوصول إليها عن طريق الواجهة العامة.- إذا كانت هناك وظيفة لا يمكن الوصول إليها من خلال الواجهة العامة ، فلا ينبغي أن تكون هناك ، فقط قم بمسحها. محو هذا الرمز.
- فقط قتله؟- نعم ، في بعض الأحيان أفعل ذلك في لوا. كان هناك بعض التغطية بالرمز ، ولم أستطع الوصول إلى هناك أو هناك أو هناك ، لذلك اعتقدت أنه كان مستحيلًا وأزلت الشفرة فقط. هذا ليس شائعًا ، ولكنه حدث أكثر من مرة. كان من المستحيل حدوث تلك الحالات ، لقد وضعت تأكيدًا للتعليق على سبب عدم حدوث ذلك. إذا لم تتمكن من الوصول إلى وظائفك من واجهة برمجة التطبيقات العامة ، فلن يكون هناك. يجب أن نرمز إلى واجهة برمجة التطبيقات العامة بإدخال غير صحيح ، وهذا ضروري للاختبارات.
- إزالة الكود ، الإزالة جيدة ، إنها تقلل التعقيد. انخفاض التعقيد يزيد من الصيانة والثبات. يبقيه بسيط.- نعم ، كان البرمجة المتطرفة هذه القاعدة. إذا لم يكن في اختبار ، فهو غير موجود.
- ما هي اللغات التي ألهمتك عندما أنشأت Lua؟ أي النماذج أو التخصصات الوظيفية أو أجزاء من هذه اللغات أعجبك؟- لقد صممت لوا لغرض محدد للغاية ، لم يكن مشروعًا أكاديميًا. لهذا السبب عندما تسألني إذا كنت سأقوم بإنشائه مرة أخرى ، أقول أن هناك الكثير من الأشياء التاريخية في اللغة. لم أبدأ بـ "اسمح لي بإنشاء اللغة التي أريدها أو أرغب في استخدامها أو ما يحتاجه الجميع وما إلى ذلك. مشكلتي هي أن "هذا البرنامج هنا يحتاج إلى لغة تهيئة للجيولوجيين والمهندسين ، وأحتاج إلى إنشاء بعض اللغات الصغيرة التي يمكنهم استخدامها مع واجهة سهلة. لهذا السبب كانت واجهة برمجة التطبيقات دائمًا جزءًا لا يتجزأ من اللغة ، لأنه من الأسهل دمجها. كان هذا هو الهدف. ما كان لدي في خلفيتي ، هو الكثير من اللغات المختلفة في ذلك الوقت ... حوالي عشرة. إذا كنت تريد كل الخلفية ...
- كنت مهتمًا باللغات التي تريد تضمينها في لوا.- كنت أتلقى أشياء من العديد من اللغات المختلفة ، أيا كانت المشكلة التي واجهتها. كان الإلهام الأكبر هو لغة Modula بناء الجملة ، ولكن خلاف ذلك ، من الصعب القول لأن هناك العديد من اللغات. جاءت بعض الأشياء من AWK ، وكان مصدر إلهام آخر صغير. بالطبع ، Scheme و Lisp ... كنت دائماً مفتونًا بـ Lisp منذ أن بدأت البرمجة.
- وما زال لا يوجد وحدات ماكرو في لوا!- نعم ، هناك اختلاف كبير في بناء الجملة. أعتقد أن فورتران كانت اللغة الأولى ... لا ، كانت أول لغة تعلمتها هي التجميع ، ثم جاءت فورتران. لقد درست ، ولكن لم تستخدم CLU. فعلت الكثير من البرمجة مع Smalltalk ، SNOBOL. لقد درست أيضًا ، لكن لم أستخدم Icon أبدًا ، إنه مثير جدًا أيضًا. جاء الكثير من Pascal و C. في الوقت الذي قمت فيه بإنشاء Lua ، كان C ++ معقدًا جدًا بالنسبة لي - وكان ذلك قبل القوالب ، إلخ. كان عام 1991 ، وفي عام 1993 بدأت لوا.
- سقط الاتحاد السوفيتي وبدأت إنشاء لوا. :) هل كنت تشعر بالملل من الفواصل المنقوطة والكائنات عندما بدأت العمل على لوا؟ أتوقع أن يكون لدى Lua بناء جملة مشابه لـ C ، لأنه مدمج في C. لكن ...- نعم ، أعتقد أنه سبب وجيه لعدم وجود بناء جملة مماثل - لذلك لا تخلط بينهما ، فهذه لغتان مختلفتان.
إنه شيء مضحك حقًا وهو مرتبط بالإجابة التي لم تسمح لي [في المؤتمر] بإدخالها على صفائف تبدأ من 1. كانت إجابتي طويلة جدًا.
عندما بدأنا Lua ، كان العالم مختلفًا ، ولم يكن كل شيء يشبه C. لم يكن Java و JavaScript موجودين ، وكان Python في مهده وكان له إصدار أقل من 1.0. لذلك لم يكن هناك هذا الشيء عندما يُفترض أن تكون جميع اللغات شبيهة بـ C. كان C مجرد واحد من العديد من بناء الجملة حولها.
وكانت المصفوفات هي نفسها بالضبط. إنه أمر مضحك للغاية أن معظم الناس لا يدركون ذلك. هناك أشياء جيدة حول المصفوفات ذات الأساس الصفري وكذلك المصفوفات ذات الأساس الواحد.
والحقيقة هي أن معظم اللغات الشائعة اليوم تعتمد على الصفر بسبب C. لقد كانت مستوحاة من النوع C. والشيء المضحك هو أن لغة C لا تحتوي على فهرسة. لذلك لا يمكنك القول أن فهارس C صفائف من الصفر ، لأنه لا توجد عملية فهرسة. يحتوي C على مؤشر حسابي ، لذا فإن الصفر في C ليس مؤشرًا ، بل هو إزاحة. وكإزاحة ، يجب أن تكون صفرية - ليس لأنها تتمتع بخصائص رياضية أفضل أو لأنها أكثر طبيعية ، أياً كان.
وجميع اللغات التي نسخت لغة C ، لديها فهارس وليس لديها حساب مؤشر. جافا ، جافا سكريبت ، إلخ ، إلخ - لا يوجد لدى أي منهم مؤشر حسابي. لذلك قاموا فقط بنسخ الصفر ، لكنها عملية مختلفة تمامًا. وضعوا الصفر دون سبب على الإطلاق - إنها مثل عبادة الشحن.
- أنت تقول أنه من المنطقي إذا كانت لديك لغة مضمّنة في لغة C لجعلها مع بناء جملة تشبه لغة C. ولكن إذا كانت لديك لغة مضمّنة في لغة C ، فأفترض أن لديك مبرمجين من لغة C يريدون أن يكون الرمز بلغة C وليس لغة أخرى ، والتي تبدو مثل لغة C ، لكن ليس لغة C. لذلك ، لم يكن من المفترض أن يستخدم المستخدمون Lua لغة C يوميا؟ لماذا؟- من يستخدم C كل يوم؟
- مبرمجو النظام.- بالضبط. هذه هي المشكلة ، الكثير من الناس يستخدمون C ، لكن لا ينبغي السماح لهم باستخدامها. يجب أن يتم اعتماد المبرمجين لاستخدام C. لماذا البرنامج معطل جدًا؟ كل هؤلاء الخارقة تغزو العالم ، كل تلك المشاكل الأمنية. نصفهم على الأقل بسبب C. من الصعب حقًا البرمجة في C.
- لكن لوا في C.- نعم ، وهكذا تعلمنا مدى صعوبة البرمجة في C. لديك تدفقات مؤقتة ، لديك تدفقات عددية صحيحة تؤدي إلى حدوث تجاوزات في المخزن المؤقت ... فقط احصل على برنامج C واحد يمكنك التأكد من أنه لا يوجد خطأ في الحساب إذا وضع الأشخاص أي رقم في أي مكان ويتم فحص كل شيء. ثم مرة أخرى ، مشكلات قابلية النقل الحقيقية - ربما في بعض الأحيان في وحدة المعالجة المركزية واحدة تعمل ، ولكن بعد ذلك يحصل على وحدة المعالجة المركزية الأخرى ... إنه مجنون.
على سبيل المثال ، في الآونة الأخيرة واجهتنا مشكلة. كيف تعرف أن برنامج C الخاص بك لا يؤدي إلى تجاوز سعة المكدس؟ أقصد عمق المكدس ، وليس تجاوز سعة المكدس لأنك غزت ... كم عدد المكالمات التي لديك الحق في القيام بها في برنامج C؟
- يعتمد على حجم المكدس.- بالضبط. ما المعيار يقول عن ذلك؟ إذا قمت بالرمز في C ثم قمت بهذه الوظيفة التي تستدعي هذه الوظيفة التي تستدعي هذه الوظيفة ... كم عدد المكالمات يمكنك القيام به؟
- 16 الف؟- قد أكون مخطئا ، لكنني أعتقد أن المعيار لا يقول شيئًا عن ذلك.
- أعتقد أنه لا يوجد شيء في المعيار لأنه يعتمد بشكل كبير على الحجم.- بالطبع ، يعتمد على حجم كل وظيفة. قد تكون المصفوفات تلقائية ضخمة في إطار الوظيفة ... لذا فإن المعيار لا يقول شيئًا ولا توجد طريقة للتحقق مما إذا كانت المكالمة ستكون صالحة أم لا. لذلك قد تواجهك مشكلة واحدة إذا كان لديك ثلاث مكالمات من الخطوات ، فقد تتعطل وتظل برنامج C صالحًا. صحيح وفقًا للمعايير - رغم أنه غير صحيح لأنه يتعطل. لذلك من الصعب للغاية البرمجة في C ، لأن هناك الكثير ... مثال جيد آخر: ما هي النتيجة عندما تطرح مؤشرين؟ لا أحد هنا يعمل مع C؟
- لا ، لذلك لا استجوابهم. لكن C ++ يدعم أنواع مختلفة.- لا ، C ++ لديه نفس المشكلة.
- ما هو نوع الإعلان؟ ptrdiff_t ؟- بالضبط ،
ptrdiff_t هو نوع موقعة. لذلك عادةً ، إذا كان لديك ذاكرة قياسية بحجم كلمتك وقمت بطرح مؤشرين في هذه المساحة ، لا يمكنك تمثيل جميع الأحجام في النوع الموقّع. لذا ، ماذا يقول المعيار عن ذلك؟
عندما تطرح مؤشرين ، إذا كان الجواب يناسب فرق المؤشر ، فهذه هي الإجابة. خلاف ذلك ، لديك سلوك غير محدد. وكيف يمكنك معرفة ما إذا كان يناسب؟ أنت لا تفعل ذلك. لذلك كلما قمت بطرح مؤشرين ، عادةً ما تعلم أن هذا غير قياسي ، إذا كنت تشير إلى أي شيء أكبر من 2 بايت على الأقل ، فإن الحجم الأكبر سيكون نصف حجم الذاكرة ، لذلك كل شيء على ما يرام.
لذلك ، لا تواجه مشكلة إلا إذا كنت تشير إلى وحدات البايت أو الأحرف. ولكن عند القيام بذلك ، لديك مشكلة حقيقية ، لا يمكنك القيام بحساب المؤشر دون القلق من أن لديك سلسلة أكبر من نصف الذاكرة. ثم لا يمكنني حساب الحجم والتخزين في نوع فرق المؤشر لأنه خطأ.
هذا ما أقصده عن وجود برنامج آمن C أو C ++ آمن حقًا.
- هل فكرت في تنفيذ لوا بلغة مختلفة؟ تغييره من C إلى شيء آخر؟- عندما بدأنا ، فكرت في لغة C ++ ، لكن كما قلت ، تخلت عن استخدامها بسبب التعقيد - لا أستطيع تعلم اللغة بأكملها. يجب أن يكون من المفيد الحصول على بعض العناصر من C ++ ولكن ... حتى اليوم لا أرى أي لغة من شأنها أن تفعل.
- هل يمكن ان توضح لماذا؟- لأنه ليس لدي أي بدائل. لا أستطيع إلا أن أشرح لماذا ضد اللغات الأخرى. أنا لا أقول أن C مثالي أو جيد ، لكنه الأفضل. لشرح السبب ، أحتاج لمقارنته باللغات الأخرى.
- ماذا عن JVM؟- أوه ، JVM. هيا ، لا يتناسب مع نصف الأجهزة ... قابلية الحمل هي السبب الرئيسي ، ولكن الأداء أيضًا. في JVM أفضل قليلاً من .NET ، لكنه ليس مختلفًا. الكثير من الأشياء التي لا يمكننا القيام بها مع JVM. لا يمكنك التحكم في أداة تجميع مجمعي البيانات المهملة على سبيل المثال. يجب عليك استخدام أداة تجميع مجمعي البيانات المهملة JVM لأنه لا يمكن أن يكون لديك أداة تجميع مجمعي بيانات غير مقبولة يتم تنفيذها أعلى JVM. JVM هو أيضا مستهلك ضخم للذاكرة. عندما يبدأ أي برنامج Java في الترحيب ، فإنه يشبه 10 ميغابايت أو نحو ذلك. إمكانية النقل ليست مشكلة لأنه لم يتم نقله ، ولكن لأنه لا يمكن نقله.
- ماذا عن تعديلات JVM مثل Mobile JVM؟- هذا ليس JVM ، هذه مزحة. يشبه الإصدار الصغير من Java ، وليس جافا.
- ماذا عن اللغات الساكنة الأخرى مثل Go أو Oberon؟ يمكن أن تكون الأساس لوا إذا قمت بإنشائه اليوم؟- أوبرون ... قد يكون ، ذلك يعتمد ... اذهب ، مرة أخرى ، بها أداة تجميع لجمع القمامة ولديها وقت تشغيل كبير جدًا بالنسبة لـ Lua. سيكون خيار Oberon خيارًا ، لكن لدى Oberon بعض الأشياء الغريبة جدًا ، مثلك لا يوجد بها ثوابت ، إذا كنت أتذكر بشكل صحيح. نعم ، أعتقد أنهم أزالوا const من Pascal إلى Oberon. كان لدي كتاب عن أوبيرون وأحب أوبيرون. كان
نظامها لا يصدق ، إنه حقًا شيء.
أتذكر أنه في عام 1994 شاهدت مظاهرة لأوبرون وسيلف. هل تعرف النفس إنها لغة ديناميكية مثيرة للاهتمام مع برنامج jit-compilers وما إلى ذلك ... لقد رأيت هذه العروض التجريبية كل أسبوع على حدة ، وكان Self ذكيًا للغاية ، فقد استخدموا بعض التقنيات من الرسوم الكرتونية لإخفاء بطء العمليات. لأنه عندما فتحت شيئًا ما ، كان الأمر يشبه "woop!" - أولاً يقلل قليلاً ، ثم يتوسع مع بعض التأثيرات. تم تنفيذه بشكل جيد ، هذه التقنيات التي استخدموها لمحاكاة الحركة ...
ثم بعد أسبوع شاهدنا عرضًا تجريبيًا لـ Oberon ، كان يعمل على مثل الأجهزة 1/10 الخاصة بـ Self - كان هناك هذه الآلة الصغيرة القديمة جدًا. في أوبيرون تنقر ثم تزدهر ، كل شيء يعمل على الفور ، كان النظام بأكمله خفيفًا جدًا.
ولكن بالنسبة لي هو أضيق الحدود ، فقد أزالوا الثوابت وأنواع مختلفة.
- هاسكل؟- أنا لا أعرف هاسكل أو كيفية تنفيذ لوا في هاسكل.
- وما هو موقفك من لغات مثل بايثون أو آر أو جوليا كأساس للتطبيقات المستقبلية للوا؟- أعتقد أن كل واحد من هذه له استخداماته.
يبدو R جيدًا للإحصائيات. إنه مجال محدد للغاية ، يقوم به أشخاص في المنطقة ، لذلك فهذه قوة.
بيثون لطيفة ، لكني عانيت من مشاكل شخصية معها. اعتقدت أنني ذكرت ذلك في حديثي أو المقابلة. هذا الشيء حول عدم معرفة اللغة بأكملها أو عدم استخدامها ، والمغالطة الفرعية.
نستخدم بيثون في دوراتنا ، نعلم البرمجة الأساسية - مجرد جزء صغير ، حلقات وأعداد صحيحة. كان الجميع سعداء ، ثم قالوا إنه سيكون من الجيد أن يكون لدينا بعض التطبيقات الرسومية ، لذلك كنا بحاجة إلى مكتبة رسومية. وجميع المكتبات الرسومية تقريبًا ، تحصل على واجهة برمجة التطبيقات ... لكنني لا أعرف Python بما فيه الكفاية ، هذه مواد متقدمة جدًا. لديه وهم أنه سهل ولدي كل هذه المكتبات لكل شيء ، لكنه إما سهل أو لديك كل شيء.
لذلك عند البدء في استخدام اللغة ، ثم تبدأ: أوه ، يجب أن أتعلم OOP ، والميراث ، وأي شيء آخر. كل مكتبة واحدة. يبدو أن المؤلفين يفخرون باستخدام ميزات لغة أكثر تقدماً في واجهة برمجة التطبيقات الخاصة بهم لإظهار أنني لا أعرف ماذا. المكالمات الوظيفية ، الأنواع القياسية ، إلخ. لديك هذا الكائن ، ثم إذا كنت تريد شيئًا آخر ، فعليك إنشاء كائن آخر ...
حتى مطابقة النمط ، يمكنك القيام ببعض الأشياء البسيطة ، ولكن عادةً ما تكون مطابقة النمط القياسية ليست شيئًا تقوم به. تقوم بإجراء المطابقة ، ويعيد الكائن نتيجة ما ، ثم تقوم باستدعاء الأساليب على نتيجة ذلك الكائن للحصول على النتيجة الحقيقية للمطابقة. في بعض الأحيان ، هناك طريقة أبسط للاستخدام ولكنها ليست واضحة ، فهي ليست الطريقة التي يستخدمها معظم الناس.
مثال آخر: كنت أدرس دورة تدريبية حول مطابقة الأنماط وأردت استخدام بناء جملة Perl-like ، ولم أتمكن من استخدام Lua بسبب بناء جملة مختلف تمامًا. لذا ظننت أن بيثون ستكون المثال المثالي. لكن في Python هناك بعض الوظائف المباشرة لبعض الأشياء الأساسية ، لكن لأي شيء أكثر تعقيدًا ، عليك أن تعرف الأشياء والأساليب وما إلى ذلك. أردت فقط أن أفعل شيئًا وأن أحصل على النتيجة.
- ماذا انتهيت باستخدام؟- استخدمت بايثون وشرحت لهم. لكن حتى Perl أبسط بكثير ، فأنت تقوم بالمباراة وكانت النتائج $ 1 ، $ 2 ، $ 3 ، الأمر أسهل بكثير ، لكن ليس لدي الشجاعة لاستخدام Perl ، لذلك ...
- كنت أستخدم بيثون لمدة عامين قبل أن ألاحظ وجود ديكورات. (سؤال ياروسلاف ديننيكوف من فريق تارانتول)- نعم ، وعندما تريد استخدام مكتبة ، فعليك أن تتعلم هذه الأشياء وأنك لا تفهم API وما إلى ذلك. يعطي Python وهم أنه سهل ولكنه معقد للغاية.
... وجوليا ، لا أعرف الكثير عن جوليا ، لكنه ذكرني بـ LuaJIT بمعنى أنه يبدو أحيانًا فخر المستخدم. يمكنك الحصول على نتائج جيدة للغاية ولكن عليك أن تفهم حقًا ما يحدث. ليس الأمر كما لو أنك تكتب الكود وتحصل على نتائج جيدة. لا ، تكتب الكود وأحيانًا تكون النتائج جيدة وأحيانًا تكون رهيبة. وعندما تكون النتائج رهيبة ، يكون لديك الكثير من الأدوات الجيدة التي تُظهر لك اللغة الوسيطة التي تم إنشاؤها ذات مرة ، وتقوم بفحصها ثم تتصفح كل رمز التجميع هذا تقريبًا. ثم أدركت: أوه ، إنه ليس تحسين ذلك بسبب ذلك. هذه هي مشكلة المبرمجين ، فهم يحبون الألعاب وأحيانًا يحبون الأشياء لأنها صعبة وليست سهلة.
لا أعرف الكثير عن جوليا ، لكنني رأيت حديثًا عنها. والرجل الذي يتحدث ، كان هو الشخص الذي لديه وجهة النظر هذه: شاهد كم هو لطيف ، لقد كتبنا هذا البرنامج وهو مثالي. لا أتذكر الكثير ، شيء عن مصفوفة الضرب أعتقد. وبعد ذلك تكون العوامات مثالية ، ثم تكون الزوجي مثالية ، ثم يضعون [أرقام] معقدة ... وكانت مأساة. مثل مائة مرة أبطأ.
(ساخرًا) "انظر إلى أي مدى هو لطيف ، لدينا هذه الأداة ، ويمكننا رؤية التجميع بالكامل [قائمة] ، ثم تذهب وتغير ذلك وذاك وذاك. انظر مدى كفاءة هذا. نعم ، أرى ، يمكنني البرنامج في التجمع مباشرة.
لكن ذلك كان مجرد حديث واحد. لقد درست القليل من البحث ولدي بعض خبرة المستخدم مع بيثون للأشياء الصغيرة.
- ما رأيك في إرلانج؟- Erlang هي لغة مضحكة. لديها بعض الاستخدامات الجيدة حقا ، والتسامح مع الخطأ مثير للاهتمام حقا. لكنهم يزعمون أنها لغة وظيفية والفكرة الكاملة للغة الوظيفية هي أنه ليس لديك حالة.
و Erlang لديه حالة خفية ضخمة في الرسائل التي يتم إرسالها ولم يتم تلقيها بعد. لذلك كل عملية صغيرة تعمل بكامل طاقتها ولكن البرنامج نفسه غير وظيفي تمامًا.
إنها فوضى البيانات المخفية التي هي أسوأ بكثير من المتغيرات العالمية لأنه إذا كانت متغيرات عمومية ، فإنك ستطبعها. الرسائل التي هي الحالة الحقيقية للنظام الخاص بك. في كل لحظة ، ما هي حالة النظام؟ هناك كل هذه الرسائل المرسلة هنا وهناك. انها غير وظيفية تماما ، على الإطلاق.
- إذن إرلانج يكذب حول كونه وظيفيًا وبيثون يكذب حول كونه بسيط. ماذا يكذب لوا؟- لوا تكمن قليلا عن كونها صغيرة. لا تزال أصغر من معظم اللغات الأخرى ، ولكن إذا كنت تريد لغة صغيرة حقًا ، فستكون لغة Lua أكبر مما تريد.
- ما هي لغة صغيرة بعد ذلك؟- الرابعة ، أنا أحب الرابع.
- هل هناك مساحة لإصدار أصغر من لوا؟- ربما ، لكنه صعب. أنا أحب الجداول ولكن الجداول ليست صغيرة جدا. إذا كنت ترغب في تمثيل الأشياء الصغيرة ، فإن الفكرة بأكملها وراء الجداول لن تناسبك. سيكون بناء جملة لوا ، كنا نسميها لوا لكنها ليست لوا.
سيكون تماما مثل الطبعة جافا الصغيرة. أنت تسميها جافا ولكن هل لديها خيوط متعددة؟ لا ، لا. هل لديها انعكاس؟ لا ، لا. فلماذا استخدامها؟ يحتوي على بناء جملة من Java ، وهو نفس نظام النوع لكنه ليس جافا على الإطلاق. إنها لغة مختلفة يسهل تعلمها إذا كنت تعرف Java ولكنها ليست Java.
إذا كنت ترغب في إنشاء لغة صغيرة تشبه Lua لكن Lua بدون جداول ليست ... ربما يجب أن تضطر إلى إعلان الجداول ، مثل FFI لتكون صغيراً.
- هل هناك أي تعديلات أصغر من لوا؟- ربما ، أنا لا أعرف.
- هل لوا جاهزة للبرمجة الوظيفية الخالصة؟ يمكنك أن تفعل ذلك مع لوا؟- بالطبع يمكنك ذلك. انها ليست فعالة بشكل خاص ولكن فقط هاسكل هو حقا فعالة لذلك. إذا بدأت في استخدام monads وأشياء من هذا القبيل ، وإنشاء وظائف جديدة ، وإنشاء وظائف ، إلخ ... يمكنك القيام بذلك باستخدام Lua ، فهي تعمل بشكل معقول ، لكنك تحتاج إلى تقنيات تنفيذ مختلفة عن اللغات الطبيعية المعتادة للقيام بشيء فعال حقًا.
— Actually, there is a library for functional programming in Lua.— Yes, it's reasonable and usable, if you do really need performance; you can do a lot of stuff with it. I love functional stuff and I do it all the time.
— My question is more about the garbage collector, because we only have only mutable objects and we have to use them efficiently. Will Lua be good for that?— I think a new incarnation of garbage collector will help a lot, but again…
— Young die young? The one that seems to work with young objects?— Exactly, yes. But as I said even with the standard garbage collector we don't have optimal performance but it can be reasonable. More often you don't even need that performance for most actions unless you are writing servers and having big operations.
— What functional programming tasks do you perform in Lua?— A simple example. My book, I'm writing my own format and I have a formatter that transforms that in LaTex or DocBook. It's completely functional, it has a big pattern matching… It's slightly inspired by LaTex but much more uniformed. There's @ symbol instead of backslash, a name of a macro and one single argument in curly brackets. So I have gsub that recognizes this kind of stuff and then it calls a function, the function does something and returns something. It's all functional, just functions on top of functions on top of functions, and the final function gives a big result.
— Why don't you program with LaTeX?— Plain LaTeX? First, it's too tricky for a lot of stuff and so difficult. I have several things that I don't know how to do in LaTex. For example, I want to put a piece of inline code inside a text. Then there is a slash verb, standard stuff. But slash verb gives fixed space. And the space between stuff is never right. All real spaces are variable, it depends on how the line is adjusted, so it expands in some spaces and compacts in others depending on a lot of stuff. And those spaces are fixed, so sometimes they look too large, sometimes too small. It also depends on what you put in code.
— But you still render your own format to LaTeX?— Yes, but with a lot of preprocessing. I write my own verb but then it changes and becomes not a verb but a lot of stuff. For example, when I write 3+1 I write a very small space here. In verb, if I don't put any space here, it shrinks, and if I do, it's too large. So I do the preprocessing, inserting a variable space. It's very small but can be a little larger if it needs to adjust. But if I put 'and' after 1 then I put a larger space. This function here does all that. This is a small example but there are other things…
— Do you have a source?— I do have the source, it is in the
git . The program's called
2html . The current version only generates HTML… Sorry, that's a kind of a mess. I created it for a book but also another one for the manual. The one in the git is for the manual. But the other one is more complicated and not public, I can't make it public. But the main problem is that TeX is not there. It's almost impossible to process TeX files without TeX itself.
— Is it not machine-readable?— Yes, it's not machine-readable. I mean, it is readable because TeX reads it. It's so hard to test, so many strange rules etc. So this is much more uniformed and as I said I generate DocBook format, sometimes I need it. That started when I had this contract for a book.
— So you use 2html to generate DocBook?— Yes, it generates DocBook directly.
— Ok, thank you very much for the interview!
If you have any more questions, you can ask them in the
Lua Mailing List . See you soon!