06 أغسطس 2025·7 دقيقة
جون باكوس وFORTRAN: اللغة التي جعلت البرمجيات قابلة للتوسع
قاد جون باكوس مشروع FORTRAN في آيبيإم، مثبتًا أن الشيفرة عالية المستوى يمكن أن تعمل بسرعة—مع زيادة الإنتاجية ومساعدة البرمجيات على التحول إلى صناعة حقيقية.
قاد جون باكوس مشروع FORTRAN في آيبيإم، مثبتًا أن الشيفرة عالية المستوى يمكن أن تعمل بسرعة—مع زيادة الإنتاجية ومساعدة البرمجيات على التحول إلى صناعة حقيقية.
في أوائل خمسينيات القرن العشرين، كانت الحواسيب نادرة ومكلفة وتستخدمها الحكومات والجامعات والشركات الكبرى. كانت قوية بالنسبة لوقتها—لكن برمجتها كانت بطيئة ومؤلمة. كُتبت العديد من البرامج مباشرةً بلغة الآلة أو التجميع، حيث كان يجب أن تتطابق كل تعليمات مع مجموعة عمليات صغيرة خاصة بالعتاد. قد يعني تغيير بسيط في صيغة إعادة كتابة أجزاء طويلة من الشيفرة، وقد يؤدي خطأ واحد إلى تعطل تشغيل كامل بعد ساعات من الانتظار.
كان جون باكوس مهندسًا في آيبيإم وقد رأى بالفعل كم من الوقت يُهدر في البرمجة منخفضة المستوى. قاد فريقًا صغيرًا لمحاولة شيء جذري: السماح للمبرمجين بكتابة تعليمات رياضية أقرب إلى طريقة تفكيرهم، وترك المجمّع يترجم ذلك إلى شيفرة آلة سريعة.
أصبح المشروع FORTRAN (اختصارًا لـ "Formula Translation"), واستهدف عملاء آيبيإم العلميّين—المتخصصين في الأعمال الرقمية، وليس حفظ السجلات الإدارية. الوعد كان واضحًا: اكتب شيفرة أقل، أخطأ أقل، ولا تزال تعمل بكفاءة على آلات مثل IBM 704.
في ذلك الوقت، كان كثير من المبرمجين يعتقدون أن اللغات عالية المستوى رفاهية. افترضوا أن أي شيء "شبيه بالإنجليزية" سيعمل أبطأ بكثير من التجميع المَدقوق يدويًا—أبطأ لدرجة أنه لا يبرر الراحة. مع كون الحواسيب مكلفة جدًا ووقت المعالجة محدودًا، لم يكن الأداء "شيئًا حسنًا فحسب"؛ كان هو الجوهر.
لذا لم يكن FORTRAN مجرد بنية جديدة؛ كان رهانًا على أن الأتمتة يمكن أن تضاهي مهارة الإنسان الخبير: أن يقدر المجمّع على إنتاج شيفرة كافية لكسب ثقة العلماء والمهندسين الذين يهتمون بكل دورة CPU.
قصة FORTRAN جزء منها اختراق تقني وجزء منها تحول ثقافي. سننظر لاحقًا إلى شكل البرمجة قبل اللغات عالية المستوى، كيف بنى فريق باكوس مجمّعًا يستطيع منافسة الشيفرة اليدوية، ولماذا غير ذلك اقتصاديات البرمجيات—مما وضع أنماطًا لا تزال الفرق الحديثة تعتمد عليها اليوم.
قبل FORTRAN، عادةً ما كانت "البرمجة" تعني كتابة تعليمات بلغة الحاسب نفسه—أو شيء ودود قليلًا.
تنفّذ الحواسيب المبكرة شيفرة الآلة: رموز عمليات رقمية وعناوين ذاكرة. لأن ذلك كان شبه مستحيل الإدارة على أي نطاق، استخدم المبرمجون لغة التجميع، التي استبدلت الكثير من الأرقام بقطع مختصرة. لكن التجميع كان لا يزال طبقة رقيقة فوق العتاد. لم تصف ماذا تريد حسابيًا—بل كنت توضح الكيف خطوة بخطوة، سجلًا سجلًا.
للحساب العلمي، قد يعني ذلك إدارة الحلقات وتخطيط الذاكرة والقيم الوسيطة يدويًا. حتى تغيير صغير في صيغة قد يتطلب إعادة كتابة أجزاء متعددة من البرنامج لأن كل شيء متصل عن طريق عناوين وقفزات.
كانت برمجة التجميع بطيئة وهشة. المشاكل الشائعة تضمنت:
لم يكن العلماء والمهندسون يجرون حسابًا واحدًا فقط—بل كانوا يكرّرون النماذج، يعيدون المحاكاة، ويستكشفون سيناريوهات "ماذا لو". عندما يعني كل تحديث أيامًا أو أسابيع من إعادة البرمجة والاختبار، تباطأ التجريب إلى حد كبير.
هنا ظهر نوع جديد من التكلفة بوضوح: زمن المبرمج. كانت العتاد مكلفًا، لكن الأشخاص الماهرين كذلك. بحلول منتصف الخمسينيات، لم يكن عنق الزجاجة دائمًا سرعة الآلة—بل الوقت الذي يحتاجه البشر لجعل الآلة تقوم بعمل مفيد بشكل موثوق.
لم يبدأ جون باكوس كمكتشف حتمي للحواسيب. بعد مسيرة مهنية مضطربة وقضاء وقت في الجيش الأميركي، وصل إلى آيبيإم في أوائل الخمسينيات، عندما كانت الحواسيب نادرة وبرمجتها غالبًا تتم يدويًا. تميّز باكوس بسرعة لشيئين: ضجر عملي من الأعمال المملة ومهارة في تنظيم جهود هندسية طموحة.
كان لدى آيبيإم مشكلة وفرصة في جهاز واحد: IBM 704. كان قويًا بالنسبة لوقته وصُمم بميزات مهمة للمهام الرقمية (مثل الحساب العائم). لكن العملاء التقنيين والعلميين كانوا يقضون وقتًا هائلًا في كتابة وتصحيح لغة التجميع. لو بقيت البرمجة بطيئة هكذا، حتى حاسوبًا رائعًا قد يبقى دون استخدام كامل.
كان رهان آيبيإم بسيطًا في البيان ومرهقًا في التنفيذ: جعل 704 أسهل في البرمجة دون التضحية بالسرعة.
قاد باكوس فريقًا اعتبر FORTRAN مشروعين لا ينفصلان: لغة يكتبها الناس، ومجمّع يترجمه إلى شيفرة آلة سريعة. وكان النصف الثاني هو الرهان الحقيقي. اعتقد كثير من الخبراء أن "البرمجة الآلية" ستكون دائمًا غير كفؤة بما يكفي لتحل محل التجميع المحسّن يدويًا.
لم تكن اللغة عالية المستوى مجرد "بناء جميل"؛ كانت تعني كتابة معادلات وحلقات وتعليمات منظمة أقرب إلى رياضيات المشكلة—ثم الوثوق بالمجمّع لإنتاج شيفرة منافسة لما يكتبه المبرمج الماهر يدويًا. تلك الثقة كانت ما تحاول آيبيإم وباكوس كسبه.
كان وعد FORTRAN جوهريًا لكنه ثوري: بدلًا من إخبار الآلة بكل خطوة صغيرة، يمكنك كتابة عبارات أقرب إلى الرياضيات التي تستخدمها.
يمكن للمهندس أن يكتب شيئًا مثل "احسب هذه الصيغة لعدة قيم" بدلًا من تهجي تسلسل التحميل والجمع والتخزين والقفز الذي يتطلبه التجميع. الأمل كان أن تصبح البرمجة أشبه بالتعبير عن فكرة—وأقل تشبه توصيل لوحة تحكم بالكلمات.
لم يكن FORTRAN يعمل مباشرة على الحاسوب. برنامج منفصل—المجمّع—ترجم شفرة FORTRAN المصدرية إلى تعليمات منخفضة المستوى يفهمها الجهاز.
يمكنك التفكير فيه كمترجم ماهر: تكتب بلغة يقرأها البشر؛ المجمّع يعيد صياغتها بلغة يمكن لـ IBM 704 تنفيذها.
سعى فريق باكوس لمزيج نادر:
كانت النقطة الأخيرة مهمة. لم يكن FORTRAN يحاول أن يكون كل شيء للجميع—كان مُصممًا لإنجاز الحسابات الحقيقية مع أخطاء أقل.
كانت الشكوك عنيفة. اعتقد كثير من المبرمجين أن الأداء يتطلب تحكمًا كاملاً، وأن "الترجمة الآلية" ستكون مضيعة. قلق آخرون بشأن التصحيح: إذا كان المجمّع هو من يولّد التعليمات النهائية، فكيف تعرف ماذا يفعل الجهاز فعليًا؟
كان المستخدمون الأوائل لـ FORTRAN هم المهندسون والعلماء—أشخاص لديهم معادلات لتشغيلها، ونماذج لاختبارها، ونتائج لإنتاجها. لم يكن الوعد لديهم ابتكارًا؛ كان توفيرًا في الوقت، أخطاء أقل، وبرامج يمكن مشاركتها وصيانتها من قِبل أكثر من نخبة خبراء التجميع.
لم يكن FORTRAN مجرد طريقة جديدة لكتابة البرامج—بل طالب بطريقة جديدة لترجمتها. سقط هذا العبء على المجمّع، ونجاحه كان سيقرر ما إذا كان FORTRAN ثورة أم هامشية.
فكّر في المجمّع كمترجم بارع في اجتماع فني. تتكلم بجمل عالية المستوى واضحة ("احسب هذه المعادلة، وكرّر لكل قيمة"), لكن الجمهور يفهم مفردات منخفضة الصرامة فقط. مترجم متوسط قد يترجم المعنى بشكل صحيح لكنه مت clunky—بطيء ومطوّل ومليء بالمراوغات. مترجم رائع يحافظ على المعنى والكفاءة، ويخرج شيئًا يمكن للجمهور التعامل معه فورًا.
كان FORTRAN بحاجة لذلك المترجم الرائع.
لم يختَرِ المبرمجون الأوائل FORTRAN من أجل الجمال أو الراحة. اختاروه فقط إن كان قادرًا على أن "يسدد إيجاره": ساعات كتابة أقل دون عقوبة في زمن التشغيل. على آلات مكلفة مثل IBM 704، الوقت الضائع في CPU كان نقودًا مهدرة—وفي الأعمال العلمية، الشيفرة البطيئة قد تعني وصول النتائج بعد فوات الأوان.
لذا المنتج الحقيقي لم يكن مواصفة اللغة؛ كان مخرجات المجمّع. إن كانت الشيفرة المجمّعة تعمل تقريبًا بسرعة التجميع اليدوي، يمكن للفرق تبرير الانتقال. إن لم تكن كذلك، لَتُهجَر FORTRAN مهما بدت لطيفة.
نقطة البيع في FORTRAN—كتابة الرياضيات كما هي—جعلت الترجمة صعبة. كان على المجمّع أن:
افترض كثير من المهندسين أن الشيفرة عالية المستوى بطبيعتها أبطأ. كان على فريق باكوس أن يُقنع بهذا العكس بالأدلة: برامج مجمّعة تنافس الشيفرة اليدوية من حيث السرعة والموثوقية. بدون مصداقية الأداء، لَبِطَلَ FORTRAN كأداة عمل حقيقية.
وعد FORTRAN الكبير لم يكن فقط أنه يسمح بكتابة شيفرة أسرع—بل أن الشيفرة المجمّعة قد تظل سريعة. هذا كان مهمًا لأن المستخدمين الأوائل لم يكونوا هواة؛ كانوا مهندسين وعلماء يقيسون القيمة بساعات الآلة والنتائج المسلمة.
التحسين يعني أن المجمّع يبذل عملًا إضافيًا حتى لا تضطر أنت. تكتب تعابير واضحة شبيهة بالرياضيات، والمجمّع يعيد كتابتها بهدوء إلى نسخة تستخدم تعليمات أقل، وصولات ذاكرة أقل، ووقت أقل على IBM 704.
الأهم أن الهدف لم يكن أن تكون "مبتكرًا"؛ بل أن تكون فعّالًا بشكل متوقع—لكي يثق الناس بأن الكتابة بـ FORTRAN لن تعاقبهم بشيفرة بطيئة.
طبق مجمّع FORTRAN تحسينات تتناسب مع الحدس اليومي:
لم تطلب أيًا من هذه من المبرمجين التفكير في توقيت التعليمات أو عناوين الذاكرة—ومع ذلك كانت هذه التفاصيل بالضبط ما كان يهم مبرمجي التجميع.
كان للتجميع حجة قوية: "أستطيع دومًا جعله أسرع يدويًا." افترض المتشككون أن اللغة عالية المستوى ستنتج شيفرة ضخمة ومهدرة.
عامل فريق باكوس هذا الشك كمتطلب للمنتج. لم يكن التحسين ميزة اختيارية؛ بل كان الدليل أن التجريد لا يعني الاستسلام للأداء.
عندما انتشر الكلام أن برامج FORTRAN قد تنافس التجميع اليدوي في السرعة للعديد من الأحمال الحقيقية، تسارع التبني. أصبح المجمّع زميلًا موثوقًا: اكتب النية بوضوح، ودع المجمّع يتولى التفاصيل، واحصل على نتائج تحترم العتاد.
لم يكن FORTRAN مجرد "أجمل" من التجميع. قدّم بعض الأفكار العملية التي تطابقت مباشرة مع عمل العلماء والمهندسين: كرّر حسابًا، أعد استخدام طريقة، وخزن الكثير من الأرقام بشكل متوقع.
البرامج العلمية مليئة بمهام "افعل هذا N مرة": جمع قياسات، التنقل عبر الزمن، التكرار نحو حل، أو تشغيل نفس المعادلة على كثير من نقاط البيانات. في التجميع، كان التكرار غالبًا يعني منطق قفز مكتوب يدويًا—سهل الخطأ وصعب القراءة لاحقًا.
جعلت حلقة DO في FORTRAN النية واضحة:
SUM = 0.0
DO 10 I = 1, 100
SUM = SUM + X(I)
10 CONTINUE
بدلًا من إدارة قفزات متعددة وعدّادات يدويًا، كان على المبرمجين تحديد النطاق والتركيز على الصيغة.
العمل الهندسي يكرر نفسه: حساب ضرب مصفوفات، تحويل وحدات، تقييم كثير الحدود، قراءة تنسيق بيانات قياسي. تتيح الروتينات الفرعية كتابة روتين موثوق واستدعاؤه من أماكن متعددة. هذا خفّض النسخ واللصق—وهو أحد أسرع الطرق لنشر الأخطاء.
بالمثل، شجعت الروتينات الفرعية تقسيم البرنامج الكبير إلى أجزاء أصغر يمكن مراجعتها واختبارها وتحسينها بشكل مستقل.
القياسات والمتجهات والجداول والشبكات والمحاور كلها مركزية للحوسبة العلمية. أعطت المصفوفات المبرمجين طريقة مباشرة لتمثيل هذه البُنى بدلًا من التعامل مع متغيرات منفصلة أو حساب عناوين الذاكرة يدويًا.
اعتمدت تحكمات التدفق في التجميع على الكثير من القفزات المشروطة وغير المشروطة. قد تكسر تسمية هدف خاطئة النتائج بهدوء. بتقديم بنى منظمة مثل الحلقات والروتينات الفرعية المسماة، خفّض FORTRAN الحاجة لمنطق القفز المتشابك—ما جعل البرامج أسهل تحققًا وأقل عرضة للتعطل أثناء التغيير.
لم يكن FORTRAN فكرة طريفة في المختبر—بل نجحت لأن الناس استخدمتها مرارًا لحل مشكلات مكلفة وحساسة للوقت. يمكن أن تُعجب بلغة (حتى تؤثر) دون أن تغير العمل اليومي. FORTRAN غيّرت العمل اليومي لأن الفرق وثقت به بما يكفي للمراهنة بجدول مواعيد وميزانيات حقيقية.
كان المتبنّون الأوائل مجموعات تعيش وتموت بالحوسبة: برامج الفضاء، مختبرات الفيزياء، جهود الطقس والمناخ، وأقسام الهندسة التي تقوم بحسابات هيكلية وكهربائية. لم تكن أمثلة صغيرة؛ كانت أحمال عمل حيث تحسن طفيف في الإنتاجية يعني المزيد من التجارب، مزيدًا من تكرارات التصميم، وأخطاء أقل مخبأة في التجميع المكتوب يدويًا.
ناسب FORTRAN جيدًا لأن ميزاته الأساسية طابقت شكل المشاكل: مصفوفات للمصفوفات والشبكات، حلقات للخطوات العددية المتكررة، وروتينات فرعية لتنظيم الشيفرة الثقيلة رياضيًا.
كانت برامج التجميع مرتبطة بقوة بآلات محددة ومكتوبة بأسلوب يصعب على الغرباء قراءته أو تعديله. لم يجعل FORTRAN الشيفرة قابلة للنقل سحرًا عبر كل الحواسيب، لكنه جعل البرامج أكثر قابلية للفهم. هذا جعل تداول الشيفرة داخل المؤسسة—ومع الوقت بين المؤسسات—عمليًا دون مطالبة المؤلف الأصلي ب"ترجمة" كل تفصيلة.
بمجرد أن أصبح بإمكان المبرمجين التعبير عن الحسابات على مستوى أعلى، بدأ إنشاء مكتبة من الروتينات الموثوقة يكون ذا معنى. صار بإمكان الفرق إعادة استخدام الطرق العددية وأنماط الإدخال/الإخراج والحسابات الخاصة بالمجال مع خوف أقل من أن تغييرًا واحدًا سيكسر كل شيء. هذا التحول—الشيفرة كأصل يستحق الصيانة وإعادة الاستخدام—ساعد على دفع البرمجة من حرفة فردية إلى عمل قابل للتكرار.
لم يجعل FORTRAN آلة واحدة أسهل للبرمجة فحسب؛ بل ساعد على ترسيخ مجموعة توقعات حول ما يجب أن تفعله لغات البرمجة—وما الذي يستطيع المجمّع فعله—في وقت كان كلاهما محل جدل.
درس رئيسي من نجاح FORTRAN هو أن تصميم اللغة وتصميم المجمّع لا ينفصلان. لم يشكك النقاد المبكرون فقط في الشيفرة الشبيهة بـ"الإنجليزية"؛ بل شككوا في قدرة المجمّع على ترجمتها إلى تعليمات آلة فعّالة. جواب فريق FORTRAN—الاستثمار بكثافة في البناء والتحسين—يتردد صداه في مشاريع لغات لاحقة.
يمكن رؤية هذا التفكير في الاعتقاد الطويل بأن تقنيات المجمّع الأفضل تفتح لغات أفضل: تجريدات أكثر أمانًا، بناء أوضح، وإنتاجية أعلى دون التضحية بالأداء. استعار الكثير من الأنظمة اللاحقة—من لغات علمية إلى لغات عامة—فكرة أن المجمّع مسؤول عن إنجاز العمل الشاق الذي كان يقوم به المبرمجون يدويًا.
ساعد FORTRAN على تطبيع فكرة أن المجمّع يجب أن يولد شيفرة منافسة، خصوصًا للأحمال العددية. بينما لم تطارد كل لغة لاحقة نفس أهداف الأداء، تغيّر التوقع الأساسي: "عالي المستوى" لا يجب أن يعني بطئًا.
غير ذلك، وجه البحث والممارسة في المجمّعات نحو تقنيات تحسين أصبحت موضوعات معيارية في بناء المجمّعات لعقود لاحقة.
كان FORTRAN المبكّر مرتبطًا بقوة بعتاد آيبيإم، ولم تكن القابلية للنقل النقطة الأساسية في البداية. لكن مع انتشار FORTRAN، أصبحت تكلفة إعادة كتابة الشيفرة العلمية واضحة. مع الوقت، تُنسب إلى FORTRAN كقوة رئيسية دفعت الصناعة نحو توحيد اللغات.
النتيجة لم تكن فورية ولا مثالية—لكنها أرست سابقة: اللغات التي تعيش بعد بائع أو جيل من الحواسيب تحتاج لتعريفات مستقرة، لا مجرد تطبيقات جيدة.
حل FORTRAN مشكلة موجعة—كتابة حسابات معقدة دون الغرق في التجميع—لكنه لم يجعل البرمجة "سهلة" بسحر. اكتشف المستخدمون الأوائل أن اللغة عالية المستوى قد تزيل مجموعة من المشاكل وتكشف عن أخرى.
جاءت سمعة FORTRAN للسرعة بتنازلات في كيفية كتابة الشيفرة وكيفية تفكير الناس بها.
مثال واضح: قد يقسم العالم حسابًا واضحًا إلى عدة خطوات أو يعيد ترتيب العبارات ببساطة لأنه يعمل أسرع هكذا. النتيجة قد تكون شيفرة تعمل جيدًا لكنها أصعب على زميل جديد أن يفهمها.
يُشاد بـ FORTRAN لمساعدته على نقل البرامج بين الحواسيب، لكن في البداية كانت "قابلة للنقل" مع نجم صغير. اختلفت الحواسيب في حجم الكلمة، أجهزة الإدخال/الإخراج، وسلوك الأعداد. أحيانًا احتفظت الفرق بنُسَخ منفصلة من نفس البرنامج لأنظمة مختلفة، أو أدرجت أجزاء خاصة بالعتاد عند الحاجة.
بُني FORTRAN للحوسبة العلمية، ليس لكل شيء. لم يوفّر أدوات قوية لتنظيم قواعد شيفرة ضخمة كما فعلت لغات لاحقة. ظل التصحيح بطيئًا ومحبِطًا أحيانًا، وأحيانًا أنتجت المجمّعات المبكرة رسائل خطأ غامضة شعرت الملّاك أنهم عادوا إلى التجميع—فقط بكلمات مختلفة.
أثارت FORTRAN جدالات ما زالت الفرق الحديثة تعرفها: هل يعطي المطورون الأولوية للسرعة القصوى، أم للشيفرة أوضح وتجريدات أعلى المستوى؟ أفضل جواب يعتمد على السياق—وكذلك الحال الآن.
أثبت FORTRAN أن التجريد قد يؤتي ثماره، لكنه علّم درسًا دائمًا: كل طبقة راحة لها حواف، وعلى الفرق أن تقرر أي تنازلات يمكنها تقبلها.
نجح FORTRAN لأنه اعتبر زمن المطور المورد النادر. لم يخترع باكوس وآيبيإم مجرد بنية أنيقة—بل برهنا أن الاستثمار في الأدوات يمكن أن يفتح فئات كاملة من البرمجيات.
رسالة FORTRAN كانت بسيطة: اكتب أسطرًا أقل، سلّم برامج صحيحة أكثر. تعيد الفرق الحديثة تكرار هذا الدرس باستمرار. أسبوع قضيه في بناء واجهة برمجة آمنة أو فصل وحدات أو سكريبت يوفّر سير عمل مؤتمت غالبًا ما يعيد قيمة أكبر من محاولة استنزاف 3% من حلقة ساخنة قد لا تكون مهمة.
شكّ الناس في FORTRAN لأن التجريد كان يبدو كالتخلي عن السيطرة. كسب المجمّع ثقة المستخدمين بتقديم أداء قريبًا من التجميع اليدوي.
النسخة الحديثة من ذلك هي الثقة في الأُطُر والبيئات المُدارة وخدمات السحابة—لكن تلك الثقة تُكسب، لا تُفترض. عندما يكسر التجريد، تعود الفرق إلى "الوضع اليدوي". العلاج نفسه كما في 1957: أداء قابل للقياس، سلوك شفاف، وأنماط فشل متوقعة.
لم يكن FORTRAN مجرد لغة—كان جهد مجمّع جعل البرمجة عالية المستوى قابلة للتطبيق على نطاق واسع. المعادلات المعاصرة هي:
هناك أيضًا فئة أحدث من الأدوات التي تردد رهان FORTRAN الأصلي: استخدام الأتمتة لنقل العمل من أيدي البشر إلى نظام شبيه بالمجمّع. منصات توليد الشيفرة مثل Koder.ai تدفع هذه الفكرة أبعد من ذلك بالسماح للفرق بوصف ما يريدونه في دردشة، ثم قيام نظام وكيل بتوليد وتكرار التطبيقات الفعلية (على سبيل المثال، React على الويب، Go + PostgreSQL في الخادم، وFlutter على الموبايل). في الممارسة، تهدف ميزات مثل وضع التخطيط، اللقطات، والتراجع إلى توفير نفس الشيء الذي كان على FORTRAN إثباته: نية أعلى مستوى دون فقدان التحكم التشغيلي.
الأدوات الجيدة لا تمنع الأخطاء فحسب؛ بل توسع الطموح. تتيح للفرق بناء أنظمة أكبر بفرق أصغر.
الأثر الدائم لباكوس هو الفكرة أن البرمجيات تتوسع عندما "النظام حول الشيفرة"—اللغة، المجمّع، والممارسات—يساعد الناس على العمل بشكل أسرع وأكثر ثقة. هذه لا تزال خارطة الطريق لفرق الهندسة الحديثة.
FORTRAN كان مهمًا لأنه قلّل التكلفة البشرية للبرمجة دون فرض عقوبة زمن تشغيل كبيرة.
المجمّع هو برنامج يترجم الشيفرة المصدرية التي يكتبها البشر إلى تعليمات منخفضة المستوى يمكن لآلة محددة تنفيذها.
في حالة FORTRAN، كان على المجمّع أن يقوم بعملين جيدًا:
لأن الاعتراض الرئيسي على اللغات عالية المستوى كان السرعة. لو كانت شيفرة FORTRAN المجمعة أبطأ بكثير من التجميع اليدوي، لم يكن بإمكان فرق العلم والهندسة تبرير الراحة.
اعتماد FORTRAN ارتبط بقدرة المجمّع على إنتاج شيفرة آلة قليلة الفارق عن الشيفرة اليدوية، وليس فقط شيفرة تعمل.
التعزيزات النموذجية شملت تحسينات عملية مثل:
كانت هذه بالضبط الحيل التي اعتمد عليها مبرمجو التجميع—لكنها أصبحت مؤتمتة.
FORTRAN جعل الأنماط العددية الأساسية سهلة التعبير:
DO للتكرار على نطاقات حسابية.\n- روتينات فرعية (Subroutines) لتجميع الحسابات القابلة لإعادة الاستخدام ومشاركة الشيفرة بين الفريق.\n- المصفوفات لتمثيل المتجهات والجداول والمصفوفات مباشرة.معًا، خفّضت هذه الميزات من "القفزات الغامضة" وحساب العناوين اليدوي—وهما مصدران شائعان للأخطاء في التجميع.
ليس فورًا، وليس بشكل كامل. FORTRAN المبكّر خفّض تكلفة إعادة كتابة الشيفرة البشرية وحسّن قابلية القراءة، لكن القابلية للنقل كانت محدودة بسبب:
مع الوقت، دفع الضغط لنقل الشيفرة العلمية بين الأجهزة إلى التوحيد القياسي.
غيّر الاقتصاديات:
بمعنى آخر، ساعد FORTRAN على تحويل البرمجة من حرفة لمرة واحدة إلى صناعة مبنية على أساليب قابلة للتكرار وبرمجيات قابلة لإعادة الاستخدام.
بعض المآخذ والتنازلات:
حلّت مشكلة رئيسية لكنها لم تخلُ من التعقيد.
الدرس الأساسي أن الاستثمار في الأدوات يفتح المجال للتوسع.
أفكار عملية:
نعم—لا تزال تُستخدم في الحوسبة العلمية والعددية، خصوصًا حيث توجد مكتبات ناضجة وقواعد شيفرة طويلة العمر.
نصائح لمن يريد تعلمها لأسباب تاريخية أو عملية: