غابرييلا موريرا، الرئيس التنفيذي لشركة Quint في Informal Systems – سلسلة المقابلات

غابرييلا موريرا، الرئيس التنفيذي لشركة Quint في Informal Systems، هي مهندسة بحثية متخصصة في لغات البرمجة والأساليب الرسمية، مع التركيز القوي على بناء أدوات تجعل التحقق الرسمي للنظم أكثر سهولة للمهندسين. وهي تقود تطوير Quint، وهي لغة مواصفات قابلة للتنفيذ आधुनية تقوم على TLA+، حيث تواصل الحفاظ على تطوير اللغة وأداتها. وتشمل عملها التحقق الرسمي، والتحليل الثابت، وأدوات المطورين، وقد ساهمت أيضًا في الأكاديمية من خلال تعليم الأساليب الرسمية، مما يعكس مزيجًا من الهندسة العملية والعمق النظري.

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

العودة إلى البداية، ما الذي أثار اهتمامك لأول مرة بالبرمجة، وكيف وجدت طريقك في النهاية إلى الأساليب الرسمية والنظم الموزعة؟

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

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

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

لقد بنيت مسيرتك المهنية حول الأساليب الرسمية ولغات البرمجة، من عملك المبكر على أدوات قائمة على المنطق الزمني للactions (TLA+) إلى قيادة تطوير Quint في Informal Systems. ما هو ما دفعك إلى التركيز على جعل التحقق الرسمي أكثر سهولة، وكيف ساهمت رؤيتك في تصميم Quint؟

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

لم تكن Quint في الأصل مخططًا لها كمنتج. بنيناها من الضرورة في Informal Systems. كنا نكتب مواصفات TLA+ للنظم التي نحتاج إلى الثقة فيها أكثر مما كنا نفعل، ولكنها لم تتوسع أبعد من مجموعة صغيرة من الأشخاص لأن البنية الجملية كانت مخيفة جدًا مع الكثير من الرموز الرياضية، وأدواتها لم تتوافق مع توقعات الناس الأساسية. كنا نريك زملائنا وشركائنا الخارجيين: “انظروا إلى هذا الشيء الرائع الذي فعلته”، لكنهم لم يتمكنوا من قراءته، ولم يكن لديهم وقت للتعلم أداة جديدة.

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

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

للمقابلة مع القراء الذين لا يعرفونها، كيف ستشرح ما هي Quint ولماذا كانت هناك حاجة إلى لغة مواصفات جديدة إلى جانب الأدوات الحالية مثل TLA+؟

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

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

كان TLA+ دائمًا قادرًا على القيام بذلك. تجعل Quint ذلك عمليًا للمهندسين الذين ليسوا بالفعل خبراء في المنطق الزمني.

Quint مصممة لجسر الفجوة بين الأساليب الرسمية والهندسة البرمجية اليومية. ما كانت أكبر الحواجز في سهولة الاستخدام التي حاولت إزالتها مقارنة بالمناهج التقليدية؟

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

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

كان أكبر نقطة ألم لي مع بنية TLA+ هي كيفية خلطي شchetes العادية والشchetes العكسية، ويجب كتابة تلك الشchetes كثيرًا. أحب بنية Quint أفضل، ولكن ما يجعل من المستحيل العودة بالنسبة لي هو كل الأدوات.

واحدة من نقاط قوة Quint هي khảية نمذجة واختبار النظم الموزعة قبل النشر. كيف يتغير هذا الطريقة التي يجب على المهندسين التفكير في بناء أنظمة مثل البلوكشين أو البنية التحتية في الوقت الفعلي؟

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

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

Quint تبني على أسس TLA+، التي يتم استخدامها على نطاق واسع لوصف النظم الموزعة. كيف توازنت بين الحفاظ على الصرامة النظرية وجعل اللغة أكثر ودية للمطورين؟

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

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

قبل أن أتعلم عن وجود TLA+، كنت أعمل في أبحاث في أنظمة النوع، مما يعني أن محقق النوع في Quint كان على الأرجح مكوني المفضل للكتابة. أتذكر شرب قهوة Paçoca-النكهة في أشهري الأولى في Informal Systems أثناء استعراض ورقة نظام نوع ما، وفكرت “حياتي رائعة”.

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

كما عملت على التحليل الثابت وأنظمة النوع. كيف أثرت تلك الخبرات في التحقق من النوع في Quint وأداتها وتجربة المطور بشكل عام؟

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

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

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

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

كنت أكثر تحفيزًا لتعليمهم كيف يمكن للأساليب الرسمية وتصميم النظام正式ًا مساعدتنا في التفكير في الحلول والاكتشاف الحالات الحدية، بدلاً من جعلهم يعتقدون أنهم يجب أن يتحققوا正式ًا من كل برنامج يكتبونه. كان мой مشروع النهائي عبارة عن إعداد لعبة RPG على الطاولة حيث يجب أن تؤخذ في الاعتبار أوامر مختلفة يمكن للاعبين اتخاذها وإعدادات مختلفة، محاولة لتقليد صعوباتنا في النظم الموزعة قدر الإمكان. نجحت في أن تكون صعبة بما يكفي لدرجة أنهم كانوا بحاجة إلى استخدام الأدوات للعثور على الحالات الحدية وتحسين حلولهم لتهديد الوحوش في النهاية. آمل أن يذكروني عندما يواجهون موقفًا مشابهًا في العمل يومًا ما. بعضهم فعل ذلك بالفعل.

هناك اهتمام متزايد بدمج الذكاء الاصطناعي مع تطوير البرمجيات. هل ترى دورًا للذكاء الاصطناعي في مساعدة المطورين على كتابة أو التحقق أو حتى توليد مواصفات رسمية باستخدام أدوات مثل Quint؟

دورًا كبيرًا، وهو يحدث بالفعل. علوم الكمبيوتر أكبر من كتابة الرمز، وفتح الذكاء الاصطناعي بابًا لطرق جديدة تمامًا لاستخدام الأساليب الرسمية. LLMs جيدة في كتابة مواصفات Quint من وصفات لغة طبيعية لنظام ورمز موجود. تحتوي عدة Quint LLM على وكلاء Claude Code يأخذون وصفًا إنجليزيًا لبروتوكول وينتجون مواصفة Quint يمكن تشغيلها والتحقق منها على الفور.

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

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

متطلعًا إلى الأمام، ما الذي يجب أن يحدث لتحويل الأساليب الرسمية من اعتماد محايد إلى جزء قياسي من دورة حياة تطوير البرمجيات؟

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

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

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