MUMPS (المعروف أيضاً بـM) يُشغّل Epic. يُشغّل VistA. يُشغّل أجزاء ضخمة من منظومة الرعاية الصحية العالمية التي تتعامل معها دون أن تعلم. يبلغ الستين هذا العام، عنده بنية كودية تُحرج Perl في أسوأ أيامه، وهو — بفارق كبير — أسرع مخزن قيمة هرمي مفتاحي لمسته في حياتي العملية. في كل مرة أذكر MUMPS في اجتماع، يضحك أحدهم — ثم يكتشف أننا كنا جادّين.
ما هو MUMPS فعلاً
MUMPS شيئان في آنٍ واحد:
- لغة برمجة، صُمّمت في 1966، مع إعلانات متغيّرات ضمنية، أوامر من حرف واحد، ونموذج تحكّم بالتدفّق يسبق البرمجة المنظّمة. قراءة كود MUMPS بارد تجربة بحدّ ذاتها.
- قاعدة بيانات هرمية، قابلة للتوجيه كـ
^globalName(subscript1, subscript2, …)، ثابتة افتراضياً. الكتابة إلى global هي كتابة قرص. قراءتها هي قراءة قرص. اللغة وقاعدة البيانات ملحومتان معاً؛ لا “ORM” لأن البرنامج يكتب إلى بنية البيانات مباشرةً.
النتيجة هي نظام حيث برنامج MUMPS مكتوب جيداً يستطيع تنفيذ آلاف العمليات في الثانية على معالج فردي من التسعينيات دون أن يتعرّق. محرّك التخزين فعّال بشكل مضحك لأنه كُتب بأيدي أناس كانوا يعتبرون 64 كيلوبايت RAM رفاهية وصمّموا وفق ذلك.
لماذا ما زال يُشحَن في 2026
السؤال الواضح: لماذا يستخدمه أحد ما زال؟ بعض الأسباب التي لا يكتب عنها أحد مدوّنات:
- موثوقية وحشية. نموذج التخزين العالمي هو تعاملي ومقاوم للأعطال. أنظمة MUMPS التي تعمل منذ 30 عاماً دون حادثة فقدان بيانات ليست نادرة؛ إنها النمط المعتاد.
- تواجد الكود والبيانات هو سلاح أداء. المعماريات ثلاثية الطبقات الحديثة تدفع تكلفة جولة في كل وصول لقاعدة البيانات. MUMPS لا تدفع شيئاً — بنية البيانات قابلة للتوجيه من سطر الكود المنفَّذ. للأحمال العالية في القراءات والكتابات الصغيرة (مثل: جلب الصيدلية، وصول الملف الطبي للمريض، كتابة نتائج المختبر)، ما زالت تتفوّق على معظم الأشياء في قياسات العالم الحقيقي.
- تكلفة الترحيل مرعبة. codebase Epic تراكم على مدى 40 عاماً. إعادة الكتابة الكاملة ليست مشروع 18 شهراً؛ إنها مشروع عقود متعدّدة. السؤال الاستراتيجي الصحيح ليس “متى نستبدله؟” بل “ماذا نبني بجانبه؟“
ما تعلّمته من العمل قريباً منه
في HAKEEM، قابلنا مكوّنات VistA/MUMPS لأن تكنولوجيا المعلومات الصحية العامة في الأردن كانت قد تبنّت أجزاء من المنظومة الصحية مفتوحة المصدر للـVA. في AFAQ، تكاملنا مع أنظمة صيدلة كانت طبقة بياناتها MUMPS-adjacent. لا أدّعي كوني خبيراً في MUMPS — ربما كتبتُ بضعة آلاف سطر منه على مدى تلك السنوات. ما أدّعيه أن تلك الآلاف من السطور علّمتني عن تصميم قواعد البيانات أكثر من كثير من عمل RDBMS الحديث الذي فعلته بعدها.
تحديداً:
- تصميم المفاتيح المتدرّجة يهمّ أكثر مما تعتقد. اختيار التسلسل الهرمي الصحيح للمفاتيح هو مكافئ MUMPS لتصميم المخطّط. أخطئه وقراءاتك تمسح كثيراً. أصبه وتحصل على وصول O(1) لبالضبط البايتات التي تريد.
- نموذج التكلفة مرئي في الكود.
SET ^patient(id, "name")=valueهو عملية قرص. لا يمكنك إخفاء ذلك وراء ORM. هذا يجعلك تفكّر في وصول البيانات على مستوى تشجّعك اللغات الحديثة على تجاهله. - أقفال global ميزة، لا خلل. نموذج القفل في MUMPS بدائي، مما يعني أنك تستطيع التفكير فيه. القفل الموزّع الحديث متطوّر، مما يعني أنك لا تستطيع.
نسخة 2026 من هذا
لو كنت أبدأ نظام رعاية صحية تعاملياً جديداً خضراء في 2026، هل سأختار MUMPS؟ لا. سأستخدم Postgres مع تصميم مخطّط دقيق وحدود تعاملية صريحة، وسأعيش حياة أسعد.
لكنني أيضاً سأرفض السخرية من codebases ما زالت تشغّل MUMPS في الإنتاج. إنها أجزاء حاملة في أنظمة مستشفيات تُبقي الناس أحياء. المهندسون الذين يُشرفون عليها ذوو مهارة غير متناسبة بطرق لا يتعرّف عليها مهندسو الويب الحديثون: يفهمون تكاليف التخزين على مستوى البايت، يستطيعون التفكير في invariants عمرها عقود، ولديهم علاقة مع بيانات الإنتاج لم يكن عندها مهندسو FAANG منذ 20 عاماً.
الاقتباس الجوهري
إن ضحك أحد من فريقك على codebase MUMPS، فهو يُخبرك شيئاً عن نفسه، لا عن codebase. اسأله إن كان آخر rewrite جديد له كان في الإنتاج 30 عاماً. إن كان الجواب “لا”، فالضحك سابق لأوانه.
الكود الأقدم الذي ما زال يُشغّل الإنتاج هو دائماً تقريباً الكود الأقل استحقاقاً للسخرية.