القوائم المترابطة المتضمنة (Intrusive linked lists)

القوائم المتصلة المتداخلة (Intrusive linked lists) هي نوع من القوائم المتصلة التي تكون فيها روابط الربط مُضمَّنةً داخل البنية نفسها التي يجري ربطها.

في التنفيذ المعتاد للقائمة المترابطة، تحتوي عقدة القائمة على مؤشر بيانات يشير إلى البيانات المترابطة، ومؤشر "التالي" (next pointer) يشير إلى العقدة التالية في القائمة.

في تنفيذ القائمة المتصلة المتداخلة (intrusive linked list)، تحتوي عقدة القائمة على مؤشر يشير إلى العقدة التالية، ولكنها لا تحتوي على مؤشر للبيانات؛ وذلك لأن القائمة تكون مضمّنةً داخل الكائن المرتبط نفسه.

تكون عقدة القائمة (list node) مضمّنة داخل الكائن الذي يحتويها.
تشير عقدة القائمة هذه إلى عقدة قائمة أخرى مضمّنة في الكائن المرتبط (linked object).
يتم حساب العنوان الأساسي للكائن المرتبط عن طريق طرح قيمة الإزاحة (offset) الخاصة بعضو القائمة من عنوان الذاكرة الخاص بكائن القائمة المرتبطة.
بعد كل هذه العمليات الحسابية على المؤشرات، ربما تتساءل: لماذا قد يلجأ أي شخص عاقل إلى استخدام قائمة مرتبطة "متداخلة" (intrusive linked list) بدلاً من القائمة المرتبطة العادية؟
لماذا نستخدم القوائم المرتبطة المتداخلة؟
هناك سببان رئيسيان لتفضيل القوائم المتداخلة على القوائم المرتبطة غير المتداخلة (non-intrusive):

• عدد أقل من عمليات تخصيص الذاكرة.
• انخفاض معدل "اضطراب الذاكرة المخبئية" (cache thrashing).

في القوائم المرتبطة غير المتداخلة، يتطلب إنشاء كائن جديد وإضافته إلى القائمة عمليتي تخصيص للذاكرة: واحدة للكائن نفسه، وأخرى لعقدة القائمة. أما في القوائم المتداخلة، فأنت بحاجة فقط لتخصيص كائن واحد (نظراً لأن عقدة القائمة تكون مضمّنة داخل الكائن). وهذا يعني عدداً أقل من الأخطاء التي يجب التعامل معها، حيث تنخفض إلى النصف الحالات التي قد تفشل فيها عملية تخصيص الذاكرة.
كما تعاني القوائم المرتبطة المتداخلة بشكل أقل من مشكلة اضطراب الذاكرة المخبئية؛ فالتنقل عبر عقدة قائمة غير متداخلة يتطلب الوصول إلى محتوى العقدة (dereferencing) ثم الوصول إلى بيانات القائمة، بينما تتطلب القوائم المتداخلة الوصول فقط إلى عقدة القائمة التالية.
قبل استعراض كيفية إدارة العمليات (processes) باستخدام القوائم المرتبطة في نظام Linux، يجب عليك فهم القوائم المرتبطة المزدوجة (doubly linked lists) والقوائم المرتبطة الدائرية (circular linked lists).

المزيد في المزقع هنا

حسناً، سأبني محرر النصوص الخاص بي!

لقد لاقت عبارة "لم يعودوا يصنعون برامج مثل Sublime Text" صدىً واسعاً لدى الكثيرين؛ فمعظم البرمجيات هذه الأيام رديئة المستوى. وهذا دفعني للتفكير: أنا أيضاً أجيد صنع برمجيات رديئة!

لماذا لا أقوم ببناء محرر نصوص خاص بي؟
يعتمد محرر VS Code على Monaco Editor، وهو عبارة عن كابوس من تداخل عناصر `<div>` بشكل فوضوي. لقد تأخرت في الانضمام إلى ركب مستخدمي VS Code لأن جهاز Mac الخاص بي (بمعالج Intel) كان بطيئاً للغاية لسنوات، وقد حُلت هذه المشكلة عندما اشتريت جهازاً بمعالج Apple Silicon. وإذا كان هذا هو المعيار السائد، فهذا يعني أن لدي مجالاً واسعاً لارتكاب الأخطاء.
Canvas
تعتمد تجربتي الأولى على عرض كل شيء داخل عنصر `<canvas>`.
معدل الإطارات (FPS): 55
قد لا تلاحظ ذلك، لكن المعالج (CPU) يبذل جهداً كبيراً لعرض تلك الصورة بمعدل يتراوح بين 60 و120 إطاراً في الثانية. وتُعد قلة التفاعل مشكلة واضحة بالنسبة لمحرر نصوص.
أعددت قائمة بالميزات "الحد الأدنى القابل للتطبيق" (MVP) وقمت بتنفيذها:
النقر لتحديد موقع مؤشر النص
استخدام مفاتيح الأسهم لتحريك المؤشر
تمييز السطر الحالي
الكتابة لإدخال النص
رسوم متحركة جذابة للمؤشر
العرض التوضيحي التالي تفاعلي؛ جرب النقر والكتابة.
معدل الإطارات (FPS): 55
قبل أن تنتقدني بشأن اختصارات Vim: اصمت، فلدّي مشكلات أكثر إلحاحاً. لا يوفر لي عنصر Canvas أي ميزات جاهزة؛ ومن بين الميزات المرغوبة التي أفتقدها:
تحديد النص
سجل التراجع والإعادة (Undo/Redo)
لصق نصوص متعددة الأسطر
التمرير عند تجاوز المحتوى للمساحة المتاحة (Overflow scrolling)
تُعد هذه النقطة الأخيرة بالغة الأهمية؛ فالحياة أقصر من أن أقضيها في برمجة أشرطة تمرير مرنة (elastic scrollbars) مخصصة. لذا قررت اللجوء لحيلة برمجية واستخدام خاصية التمرير الأصلية للمتصفح على عنصر مخفي: حيث يتم ضبط حجم عنصر `<div>` ليتطابق مع أبعاد النص في الـ Canvas، ويُستخدم موضع التمرير لحساب إزاحة العرض (render offsets) داخل الـ Canvas.

الموقع الرئيسي

البرمجة فن

عندما بدأتُ البرمجة، كان يومي بأكمله يتمحور حول التطوير؛ أستيقظ، وأكتب الكود، ثم أخلد للنوم. هكذا كان حالي يوماً تلو الآخر. كانت دائرتي الاجتماعية بأكملها تتألف من أشخاص يمارسون البرمجة أيضاً، وكنت أدرس أطر العمل (frameworks) والمكتبات البرمجية ولغات برمجة متنوعة.
لقد دخلت مجال التطوير لأنني كنت مفتوناً بفكرة أنني أستطيع إنشاء برامج جديدة بمجرد كتابة الكود. كان كل ما علي فعله هو تعلم البرمجة لأتمكن من بناء أي شيء؛ فإذا تعلمت PHP، أمكنني بناء تطبيقات للجانب الخلفي (back-end)، وإذا تعلمت HTML وCSS، أمكنني بناء مواقع إلكترونية.
كان بإمكاني اختيار ما أريد إنشاءه، وتعلم التقنيات اللازمة لذلك، ثم البدء في البناء. تفتح بيئة التطوير المتكاملة (IDE)، وتنشئ مشروعاً جديداً، وتبنيه من الصفر. تختار الأنماط والمكتبات وأطر العمل، وتقرأ التوثيق الفني وتغوص في الكود المصدري. تندمج في العملية لدرجة أنك لا تشعر بمرور الأيام بسرعة. ومع مرور الوقت، تطور أسلوبك الخاص في البرمجة.
لقد كتبت الكود واستمتعت بذلك، لكنه لم يكن نوع العمل الذي أردت القيام به لبقية حياتي. كنت أفضل عملية "الابتكار" أو إنشاء شيء جديد على عملية كتابة الكود بحد ذاتها. أحببت البدء من الصفر -بمجرد فكرة- لإنشاء منتج يستخدمه الناس فعلياً؛ ولهذا السبب عملت حصرياً في الشركات الناشئة ولم أعمل قط في الشركات الكبرى.
لطالما حلمت بالتقدم في مساري المهني -لأصبح قائد فريق أو مديراً، أو أتولى دوراً لا يتضمن كتابة الكود. وكلما توفر شخص آخر لكتابة الكود، كنت أنتقل من البرمجة إلى المهام الإدارية. لم يكن يهمّني ما إذا كنت أكتب الكود بنفسي أو أوكله للآخرين.
ورغم أنني دخلت مجال التطوير بدافع الاهتمام بابتكار الأشياء، إلا أنني لاحقاً أصبحت أمارسه لمجرد الحصول على مقابل مادي؛ فقد كان الأمر بالنسبة لي مجرد وظيفة. وحتى عندما كنت أكتب الكود في وقت فراغي، كنت أستخدم ذلك النهج لبناء شركاتي الناشئة الخاصة التي خططت لجني المال منها. لقد كانت كتابة الكود وجني المال أمرين لا ينفصلان؛ ومع مرور الوقت، أصبح الدخل الناتج عن المشاريع هو المحور الأساسي، بدلاً من مجرد الرغبة في إنشاء المشاريع. ولكن هناك نوع آخر من الأشخاص؛ إنهم المبرمجون الحقيقيون الذين يكتبون الأكواد البرمجية بغض النظر عن العائد المادي. فهم يكتبون الكود لمجرد أنهم لا يستطيعون التوقف عن ذلك، ولا يكترثون لحجم المال الذي قد يجنونه منه؛ إذ قد يعملون على مشاريع مفتوحة المصدر لن تدرّ عليهم أي دخل على الإطلاق.
إنهم يستمتعون بكتابة الكود، وحل تحديات التطوير، والتصميم، واستنباط المنطق البرمجي، وإصلاح الأخطاء، وفهم النظام بأكمله؛ فهم يستمتعون بالعملية ذاتها، ولن يتنازلوا أبداً عن هذا الدور لصالح وكلاء الذكاء الاصطناعي.

أنا أحب تأسيس الشركات الناشئة، وهم يحبون كتابة الكود. بالنسبة لي، يُعد بناء المشاريع وسيلةً لكسب المال، أما بالنسبة لهم، فالبرمجة فنّ.
لهذا السبب، فإن كل ما أطرحه من حجج حول دور الذكاء الاصطناعي في مساعدتي على بناء المشاريع لا يعني شيئاً لهؤلاء الفنانين الحقيقيين؛ فهم ليسوا بحاجة إلى الذكاء الاصطناعي لمساعدتهم في أي شيء.

المزيد

Bitap: خوارزميتي المفضلة لمطابقة السلاسل النصية

تتمثل إحدى المسائل الكلاسيكية في العثور على أول ظهور لنمط (Pattern) معين، ولنرمز له بـ P، داخل سلسلة نصية (String)، ولنرمز لها بـ T. وتوجد خوارزميات كلاسيكية متنوعة لحل هذه المسألة بكفاءة، مثل خوارزميات "بوير-مور" (Boyer-Moore) و"كنوث-موريس-برات" (Knuth-Morris-Pratt) و"تو-واي" (Two-Way). أود في هذا المقال استعراض خوارزمية أقل شهرة، وهي خوارزمية "بيتاب" (Bitap) -أو ما يُعرف بـ "شيفت-آند" (Shift-And)- التي تعمل بكفاءة عندما يكون النمط P قصيراً نسبياً (أي أن طوله يقل عن عرض "كلمة الآلة" أو machine word). ورغم ما لهذه الخوارزمية من قيود، إلا أنني أفضلها كثيراً؛ فهي بسيطة الفهم والتطبيق، وتتمتع بكفاءة عالية نسبياً عند التعامل مع السلاسل النصية القصيرة، كما أنها توظف العمليات المنطقية على مستوى البتات (bit operations) بأسلوب أنيق ومميز.
ولإثبات أن هذه الخوارزمية تتسم بالبساطة المفاهيمية المذكورة، سأحاول استنباطها تدريجياً، بدءاً من أبسط خوارزميات مطابقة السلاسل النصية وأكثرها بدائية.
تحويل الخوارزمية البسيطة (الساذجة) إلى خوارزمية تدفق (Streaming)
لنفرض الآن قيداً إضافياً يدفعنا لتعديل الخوارزمية قليلاً: بدلاً من الحصول على جميع محارف النص $T$ دفعة واحدة، لنفترض أنها تُقدَّم الآن على شكل تدفق بيانات، بحيث يصل محرف واحد في كل مرة (ربما يكون النص $T$ طويلاً جداً ولا نرغب في تحميل كامل محتوياته في الذاكرة دفعة واحدة).
الخوارزمية البسيطة المذكورة أعلاه لا تعمل بنظام التدفق؛ فهي تحتاج إلى قراءة ما يصل إلى $m = \text{len}(P)$ من المحارف المتقدمة (أي التي تلي الموقع الحالي) في النص $T$ لاكتشاف مطابقة للنمط $P$. فكيف يمكننا تكييفها بحيث تجري تمريرة واحدة فقط عبر البيانات؟
بعد قليل من التفكير، نتوصل إلى الصيغة التالية المعدلة من خوارزمية البحث الشامل (brute-force). بدلاً من محاولة اكتشاف وجود النمط $P$ فوراً عن طريق القراءة المسبقة في النص $T$ بدءاً من كل موقع $i=0, \dots$، يمكننا الاحتفاظ بمجموعة من المطابقات "قيد التنفيذ" أثناء مسح النص $T$. من الناحية المفاهيمية، تتكون المطابقة قيد التنفيذ من بادئة (prefix) النمط $P$ التي طُوبقت بالفعل قبل الموقع الحالي، بالإضافة إلى اللاحقة (suffix) المتبقية التي لم تُطابق بعد. وعند قراءة محرف جديد $c$ في النص $T$، نقوم بتقديم المطابقات التي تنتظر هذا المحرف $c$، ونلغي (أو ننهي) بقية المطابقات. وإذا وصلت أي من المطابقات النشطة إلى نهاية النمط $P$، نكون قد أتممنا المهمة.

المزيد

سحابة في زجاجة: جعل الاستضافة الذاتية متاحة للجميع

موقع Cloud in a Bottle هو مشروع مفتوح المصدر (مُرخّص بنظام AGPL-3.0) يُقدّم نظام تشغيل مبسط لسحابتك الشخصية (Personal Cloud).
الهدف الرئيسي منه هو تمكينك من استضافة تطبيقاتك وبياناتك بنفسك بسهولة دون الحاجة للرابط المباشر أو التعقيدات التقنية، وهو بمثابة متجر تطبيقات خاص بك يُدار بنقرة واحدة على خوادم أو أجهزة تملكها وتحتكُم بها.
أهم الميزات والخصائص
كتالوج تطبيقات جاهز: يحتوي على تطبيقات مفتوحة المصدر مشهورة ومجهزة للتثبيت بنقرة واحدة مثل:
Nextcloud: لتخزين الملفات والمزامنة والتقويمات.
Jellyfin: لتشغيل البث المباشر للأفلام، الموسيقى، والوسائط.
VaultWarden: لإدارة كلمة المرور (بديل Bitwarden).
Pi-hole: لحظر الإعلانات والبرمجيات الخبيثة على مستوى الشبكة.
SearXNG: محرك بحث محلي يحافظ على الخصوصية.
Open WebUI: واجهة تشبه ChatGPT للتعامل مع الذكاء الاصطناعي المحلي.
استضافة تطبيقاتك الخاصة: أي برنامج يعتمد على تقنية الحاويات (Docker Containers) أو مشروع قمت ببرمجته، يمكنك رفعه وربطه بسهولة عبر حساب GitHub الخاص بك ليتم تشغيله وإعطاؤه عنوان ويب خاضع للتحكم.
الخصوصية والأمان: تعمل جميع التطبيقات داخل بيئات معزولة (Security Sandboxes) برصيد أدنى من الصلاحيات.
ملكية البيانات: يتم حفظ جميع بيانات التطبيقات في مجلد واحد على قرص خادمك، مما يسهل عملية النسخ الاحتياطي (Backup) ونقل البيانات دون قيود أو احتكار من الشركات (No Lock-in).
خيارات الاستضافة والتسغيل
على أجهزتك الشخصية (مجاناً): تشغيل النظام على جهاز كمبيوتر قديم، أو كمبيوتر محمول، أو Raspberry Pi.
على خادم افتراضي خاص (BYO VPS): استئجار خادم خاص بك من أي شركة مثل (Hetzner, DigitalOcean, Linode) وتثبيت النظام عليه.
خدمة مُدارة بالكامل (مدفوعة): الاشتراك عبر مطوري المشروع (Imbue) للحصول على خادم جاهز مع عنوان IP ونطاق (Domain) جاهز (تبدأ من 5$ شهرياً).
كيف تستفيد منه؟
الاستغناء عن الخدمات السحابية المدفوعة: يمكنك استبدال Google Drive أو OneDrive باستخدام Nextcloud، واستبدال Spotify/Netflix باستخدام Jellyfin أو Navidrome، واستبدال 1Password بـ VaultWarden.
إطلاق وتجربة مشروعاتك الشخصية: إذا كنت مبرمجاً أو تطور تطبيقات باستمرار، يتيح لك الموقع نشر تطبيقاتك وتجربتها على نطاق خاص (my-app.your-domain.com) بسهولة.
حماية الخصوصية: حظر الإعلانات والتتبع على كافة أجهزة منزلك عبر تشغيل Pi-hole وتصفح الإنترنت بأمان عبر SearXNG.
تشغيل نماذج الذكاء الاصطناعي محلياً: الاستفادة من Open WebUI لتشغيل نماذج ذكاء اصطناعي دون إرسال بياناتك لشركات خارجية.

المزيد

بعض الأفكار حول مسألة "نافييه-ستوكس" (إحدى مسائل جائزة الألفية)

يتناول هذا الموضوع نتيجةً مبهرةً توصلت إليها شركة OpenAI؛ إذ استخدمت الشركة نموذجاً غير مُعلن عنه لتقديم حل لمسألة "الوجود والسلاسة" (existence and smoothness) الخاصة بمعادلات "نافييه-ستوكس"، وهي واحدة من "مسائل جائزة الألفية" السبع التي رُصدت لها جائزة قدرها مليون دولار منذ 24 مايو 2000.
غير أن هذا الاكتشاف قد طغت عليه بعض الاتهامات بممارسات غير نزيهة وجهها تريستان باكماستر، أستاذ الرياضيات في جامعة نيويورك، الذي كان يتعاون في مسائل ذات صلة مع ليفنت ألبوج، وهو عالم رياضيات بارع يعمل حالياً لدى شركة Anthropic.
تزامنت شكوى تريستان مع نشرٍ متسرع لنتائجهما الخاصة؛ ويمكن الاطلاع على ملف PDF يوضح تفاصيل ما حدث هنا. وباختصار شديد: عمل تريستان وليفنت على المسألة لما يقرب من عام، مستخدمين بشكل مكثف نموذجي Claude وCodex (وتحديداً نسخة GPT-5.6 Sol)، حتى حققا اختراقاً بحثياً في 15 أغسطس. وفي خضم تداول الشائعات في الأوساط الرياضية، وصل إلى مسامع تريستان وليفنت أن OpenAI قد علمت بأن Anthropic نجحت في حل "مسألة كبرى عالقة"؛ فتواصلا مع OpenAI ليعلما أن لديها فريقاً يعمل على مسألة ذات صلة وبنهج مشابه. وعلى حد تعبير تريستان:
سألتُ عن موعد إرسالهم لأول "أمر توجيهي" (prompt)؛ وهو سؤال لم تُجب عليه OpenAI بشكل مباشر لفترة من الوقت. وفي النهاية، تم الاتفاق على أنه أُرسل خلال الأيام القليلة الماضية، وذلك بعد أن وصلت معلومات حول عملنا إلى OpenAI.
سألتُ عما إذا كان النموذج قد تدرب على جلساتنا في نظام Codex —حيث كنا نضع جميع مسوداتنا الخاصة بالمشروع بأكمله— أو ما إذا كان بإمكانه الوصول إليها. فأُخبرتُ بأن النموذج لا يطّلع على بيانات المستخدمين. عاودتُ السؤال بشأن التدريب، لكنني لم أحصل على إجابة.
ازداد الأمر تعقيداً بعد ذلك؛ إذ عرض فريق OpenAI الانتظار حتى ينشر "تريستان" (Tristan) نتائجه، أو أن يقوم هو بكتابة ورقة بحثية حول ما توصلوا إليه، لكنهم أوضحوا بجلاء أن "ليفنت" (Levent) لن يُدعى للمشاركة كمؤلف مشارك نظراً للعلاقة التنافسية بين OpenAI والجهة التي يعمل لديها "ليفنت".
وإليكم كيف وصفت OpenAI عملها:
في يوم الثلاثاء، الأول من سبتمبر، سمعنا شائعات تفيد بحل مسألتين من "مسائل جائزة الألفية" (Millennium Prize problems). واستلهاماً من هذه الشائعات ومن القفزة النوعية في أداء نموذجنا الداخلي، أطلقنا مبادرة لتقييم أدائه على جميع مسائل جائزة الألفية المفتوحة، بالإضافة إلى بضع مسائل أخرى ذات أهمية بالغة. [...]
توصلت الوكلاء (الأنظمة الذكية) إلى الحل يوم السبت، الخامس من سبتمبر، أي بعد حوالي 88 ساعة من إطلاق الدفعة الأولى منها. واستغرقت عملية الصياغة الرسمية والتحقق (باستخدام لغة Lean) 17 ساعة إضافية عبر نموذج GPT-6 Astra.
وعبر جميع المسائل التي جرت محاولة حلها، أرسلت هذه الوكلاء 4.9 مليون رسالة واستهلكت حوالي 300 مليار "رمز" (token) من المخرجات. وفي سياق حل مسألة "نافييه-ستوكس" (Navier–Stokes)، أرسلت الوكلاء 2.7 مليون رسالة واستهلكت ما يقرب من 130 مليار رمز من المخرجات.
(نحن لا نعرف هيكل التكلفة الخاص بالنموذج الداخلي الذي استخدموه، ولكن 300 مليار رمز من المخرجات -وفقاً لأسعار واجهة برمجة التطبيقات العامة لنموذج GPT-6 Astra- كانت ستكلف 15 مليون دولار).

المزيد

Huzzah ! طريقة تجريبية جديدة للبرمجة باستخدام الذكاء الاصطناعي

إذا كنت مهندس برمجيات مثلي، فستكون الأشهر الأولى من عام ٢٠٢٦ رائعة. فجأةً، أصبحت برامج البرمجة الذكية متطورة لدرجة أننا لم نعد بحاجة لكتابة الأكواد يدويًا. لكن إن كنت مثلي، فستواجه بعد فترةٍ ما طريقًا مسدودًا. انتهت فترة الحماس الأولي، وتلاشى الشعور بالجدة. لم يعد هناك أي شعور بالرضا.الآن شهر أغسطس، وأشعر بإرهاق شديد. بصراحة، سئمتُ من كتابة نصوص طويلة باللغة الإنجليزية لوصف كل تغيير أريده في قاعدة بياناتي البرمجية. مع ذلك، لا أريد العودة إلى كتابة كل الأكواد يدويًا. كان هناك ملل حقيقي في هذه الممارسة، وأفضّل تجنّبها... لبقية حياتي.
ومع ذلك، أشعر أنني بحاجة إلى فهم أفضل وتحكّم أكبر في ما يفعله الكود الخاص بي. أريد أن أعرف أن برمجياتي عالية الجودة وموثوقة. أريد أن أشعر بالرضا عن نفسي كمتخصص. لذا أحاول إيجاد طريقة لتحقيق التوازن بين الأمرين.
مشكلتي مع برامج البرمجة الآلية تكمن في:
عدم وجود سجل موثوق لنوايا المستخدم. تُهمل التوجيهات، وقد يكون الكود مُولّدًا بواسطة الذكاء الاصطناعي أو لا. لقد فقدنا السلطة المركزية التي تُعبّر عما يريده المستخدم من الآلة، وأعتقد أنه من المهم التعامل مع هذه الحقيقة.
تُعدّ محادثات الذكاء الاصطناعي تعليماتٍ إلزامية، خطوة بخطوة، تصف التغييرات التي تُجرى على التطبيق، وليس التطبيق نفسه. هذا يعني أن التعليمات غالبًا ما تُكرّر، وبالتالي تستهلك موارد النظام، مرات عديدة خلال عملية التطوير. وهذا غير فعّال.
يوجد جزء كبير من اللغة الطبيعية لأسباب اجتماعية، وليس معلوماتية. الجملة العادية نادرة في المعلومات الحقيقية. الكتابة بهذه الطريقة، للآلة، مُرهقة.
لمعالجة هذه المشاكل، أقوم ببناء مُحرّر تجريبي. أُسمّيه "هوزّا"، وهو يُقدّم نموذجًا بديلًا للعمل مع نماذج اللغة.
مع برامج البرمجة الآلية، تكون التوجيهات (أ) طويلة، (ب) إلزامية، و(ج) مؤقتة. مع Huzzah، تكون التعليمات البرمجية (أ) شبه رمزية، (ب) تصريحية، و(ج) مستمرة.
سيكون الأمر أسهل إذا عرضتُها لك.