المقال بيناقش مستقبل تصميم لغات البرمجة (Programming Language Design)، وتحديدًا اللغات المخصصة للمجال (Domain-Specific Languages أو DSLs)، في ظل وجود نماذج اللغة الكبيرة (LLMs). الفكرة الأساسية هي إن الـ DSLs تاريخيًا كانت أداة قوية جدًا لتقليل الكود المتكرر (boilerplate)، وفرض قواعد وثوابت خاصة بمجال معين (domain-specific invariants)، وتقليل العبء الذهني على المطورين عن طريق تصميم syntax و semantics مخصصة لمشكلة معينة. لكن حاليًا، وجود الـ LLMs بيهدد جدوى استخدامها.
التحدي التقني الأساسي: انحياز أداء الـ LLM للغات العامة
المشكلة الجوهرية هي إن الـ LLMs أداءها بيكون أعلى بكثير في توليد كود للغات البرمجة العامة (General-Purpose Languages أو GPLs) اللي ليها مصادر كتير زي Python و JavaScript، وده لأنها بتمثل جزء ضخم من بيانات التدريب بتاعتها. المقال بيستشهد بأبحاث بتوضح إن الأداء بينهار كل ما اللغة تكون متخصصة أو نادرة. الانهيار ده مضر جدًا للـ DSLs، اللي بطبيعتها تعتبر low-resource.
ده بيخلق تكلفة فرصة (opportunity cost) عالية جدًا لو أي فريق قرر يستخدم DSL. الفريق ده هيضطر يضحي بالمكاسب الإنتاجية الكبيرة اللي بتيجي من أدوات زي GitHub Copilot، لإن الأدوات دي مش فعالة مع الـ DSL المخصوص بتاعهم. الكاتب خايف إن ده يسبب "ركود" في مجال تصميم اللغات، والمطورين يلجأوا بشكل افتراضي للغات اللي الـ LLMs بتحبها زي Python لكل حاجة، وبكده نخسر قوة التعبير والضمانات (safety guarantees) اللي بتقدمها الـ DSLs المصممة كويس.
اتجاهات مستقبلية مقترحة لتصميم الـ DSLs
الكاتب بيقترح 3 اتجاهات تقنية ممكن تصميم اللغات يتطور من خلالها عشان يتعايش ويتعاون مع الـ LLMs بدل ما يختفي:
استخدام اللغات العامة (GPLs) كـ Intermediate Representation للـ DSLs: الاتجاه ده بيحل مشكلة أداء الـ LLM الضعيف مع الـ DSL syntax عن طريق تجنب التوليد المباشر. بدلًا من كده، بنطلب من الـ LLM يولد كود في جزء محدود من لغة عالية الموارد زي Python. بعدين، برنامج مكتوب يدويًا بيعمل "lift" أو "transpile" للكود ده من Python للـ DSL المستهدف. المقال بيشير لورقة بحثية استخدمت التكنيك ده بنجاح لتوليد logical invariants. السؤال البحثي هنا هو: هل ممكن عملية الترجمة دي من الـ GPL للـ DSL تبقى أوتوماتيكية؟ يمكن عن طريق عمل frameworks لتصميم الـ DSLs تقدر تولد وصف للـ semantics بتاعتها في لغة زي Python جنب الـ compiler بتاع الـ DSL نفسه.
الدمج بين الكود الرسمي (Formal) والمواصفات غير الرسمية (Informal) في DSLs هجينة: الاتجاه ده بيقترح تصميم DSLs تقدر تدمج بشكل طبيعي بين الكود والمواصفات المكتوبة باللغة العادية. الكاتب بيوصف طريقة شغله الشخصية: بيكتب خطة عامة في prompt، ويخلي الـ LLM يولد الـ "glue code" (الكود اللي بيربط الأجزاء ببعض)، وبعدين هو بيكتب بنفسه الوظائف الأساسية المعقدة. التحدي التقني هنا هو إزاي نعمل formalize للـ workflow ده جوه لغة برمجة. ده ممكن يشمل تصميم DSLs تقدر تعمل parse لخليط من الكود الرسمي والنص العادي، وممكن تستخدم الـ type system والـ static analysis بتوع الـ DSL نفسه عشان تولد مواصفات باللغة الطبيعية عن الأجزاء الرسمية، عشان الـ LLM يستخدمها كـ context.
تصميم لغات لعملية توليد كود مُحقَّق منه (Verified LLM Synthesis): هنا التركيز بيتحول من تصميم لغات للـ implementation إلى لغات للـ specification. بدل ما نطلب من الـ LLM يولد كود خام ممكن يكون فيه bugs، بنطلب منه يولد كود بلغة موجهة للتحقق (verification-oriented language) زي Dafny، ويكون معاه مواصفات رسمية (formal specifications) زي الـ pre/post-conditions والـ invariants. بعد كده، أداة التحقق (verifier) بتتأكد إن الكود المولَّد مطابق للمواصفات. ده بيخلي المطور يثق في الـ specification من غير ما يحتاج يراجع كل الكود اللي الـ LLM كتبه. الفرصة لتصميم اللغات هنا مزدوجة: (أ) دمج أدوات الـ specification في الـ DSLs الحالية، و(ب) تصميم لغات تحقق جديدة مخصصة عشان توصف الخصائص والقواعد الفريدة لمجالات معينة (زي أنظمة الحوار أو بروتوكولات الشبكات).
الخلاصة: المقال بيقول إن الـ LLMs رفعت سقف المتطلبات والمبررات لإنشاء أي DSL جديد. عشان تصميم اللغات يفضل موجود ومهم، لازم يتطور ويعتبر الـ LLMs جزء أساسي من بيئة التطوير، وده هيؤدي لظهور معماريات جديدة للـ transpilation، وواجهات هجينة بتدمج بين الرسمي وغير الرسمي، وتوليد كود يمكن التحقق من صحته.
المصدر: https://kirancodes.me/posts/log-lang-design-llms.html