أردت منذ زمن طويل أن أكتب نصًا مشابهًا ، لكن يدي لم تصل. ولكن بعد الاجتماع الصيفي للجنة توحيد C ++ التي انتهت وعوى زيادة تعقيد اللغة ، كان علي أن أجد الوقت وأصلح أفكاري حول هذا الموضوع.

سيكون هناك الكثير من النص ، لذلك أولئك الذين لا يأسفون على وقتهم ، أدعوكم للنظر تحت القطة.

لغة البرمجة هي منتج تقني ، ولكنها ليست بهذه البساطة

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

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

مثال آخر قريب من المطورين هو تطور محركات الأقراص الصلبة. من الوحوش الضخمة للأوقات المركزية والكمبيوتر المصغر ، إلى الطرز الصغيرة مقاس 3.5 "و 2.5" بوصة ، ثم إلى SSDs M.2 وتهيئتها مباشرة إلى لوحة eMMC.

نفس الشيء مع الأقراص المرنة ، والتي وصلت إلى 3.5 "، ثم اختفت كفئة تحت ضغط محركات أقراص فلاش USB.

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

يعلن مؤلفو الكتاب أن الأحداث في جميع هذه الحالات تتطور وفقًا للسيناريو نفسه:

• أولاً ، هناك حاجة إلى منتج يحل مشكلة معينة. دعنا نقول قرص مغناطيسي مرن.
• نظرًا لأن جميع الحلول المتنافسة في المرحلة الأولية (والتي ، من حيث المبدأ ، قليلة) تعتمد على نفس التقنيات ، فإن السوق مقسم بين أكثر أو أقل من المنتجات المماثلة ؛
• تبدأ الشركات المصنعة للمنتجات الناجحة في التنافس مع بعضها البعض ، وفي هذه المنافسة ، تصل منتجاتها إلى نسبة جودة السعر الأكثر ملائمة. والأهم من ذلك ، في حين أن المنتجات الحالية تتسق قدر الإمكان مع وجهات النظر حول كيفية معالجة المهام التي تهدف هذه المنتجات إلى معالجتها. بمعنى تقريبي ، يعلم الجميع أن الأقراص المرنة 8 "ممتازة لنقل المعلومات من كمبيوتر صغير إلى آخر باستخدام الأقراص المرنة. ولا يمكن لأي شخص آخر تخيل طريقة أخرى في الاتجاه السائد ؛
• في مكان ما على الهامش ، استنادًا إلى بعض الاكتشافات / المواد / التقنيات الجديدة ، يظهر منتج جديد أدنى بكثير من المنتجات الحالية من جميع النواحي تقريبًا. عموما أكثر تكلفة. كقاعدة عامة ، لا يمكن مقارنتها في القدرات / القدرات. لكنه يتمتع بجودة مهمة للغاية: يمكن استخدامه حيثما يكون من المستحيل أو الصعب تطبيق الحلول الرئيسية. على سبيل المثال ، لا يمكنك توصيل محرك أقراص بحجم 8 بوصات بالكمبيوتر الشخصي ، لكن مالكي أجهزة الكمبيوتر الشخصية لا يهتمون بحمل الأقراص المرنة بحجم 8 بوصات. انها ليست عملية فقط. في حين أن القرص المرن 5.25 "مناسب تمامًا لنفسه. ولا تهتم بتكلفة كيلوبايت 5.25" كان القرص المرن أصلاً أغلى من 8. "لم يكن هناك أي خيار آخر ؛
• تم تشكيل سوق جديد حول المنتج الجديد ، والذي لم يكن في البداية مثيرًا للاهتمام على الإطلاق لمصنعي المنتجات السائدة. ولكن نظرًا لأنه كان سوقًا جديدًا ، توافد عليه لاعبون جدد ، مما خلق منافسة جدية لبعضهم البعض. وسرعان ما تحولت هذه المنافسة التكنولوجيا الهامشية وغير الفعالة إلى فعالة للغاية. الذي لم يعد هامشيًا ، لأنه بمجرد تجاوز المنتجات الرئيسية السائدة من حيث مجملها ، سرعان ما حل محله في مكانه الخاص. وبصورة تقريبية ، إذا كان هناك مئات الآلاف من محركات الأقراص "5.25" وملايين الأقراص المرنة 5.25 "حولها ، فما هي الفائدة من التمسك بأجهزة 8 الأكثر هامشية في الوقت الحالي؟

لغات البرمجة كمنتجات تكنولوجية

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

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

ومع ذلك ، دخلت Java إلى "السوق" من منظور مختلف تمامًا ، من خلال مكان لا يمكن لأحد أن يعمل فيه حقًا: عبر الإنترنت وتطبيقات المتصفح (كان كل شيء أكثر تعقيدًا بعض الشيء ولا يزال هناك سوق لتطبيقات JavaCard و STK ، لكننا لن نترك في البراري). كان الإنترنت موضوعًا ساخنًا للغاية ، ومن ثم لم يكن هناك أي شيء للقيام بالمواقع / الصفحات الديناميكية (ظهرت JavaScript بعد إعلان Java). ولأنه لم يكن هناك شيء يمكن استخدامه إلى جانب Java ، فقد بدأ استخدام Java. حسنًا ، إذن ، مع تطورها والتغلب على أمراض الطفولة ، دخلت Java إلى مناطق أخرى ، مزاحمة التقنيات الأخرى من هناك. رغم أنها في نفس سطح المكتب ، لم تستطع أن تعض نفسها قطعة مهمة من الكعكة.

بالكاد يمكن أن تثير لغة Go اهتمام أي شخص بالمنافذ التقليدية التي عاش فيها بالفعل C و C ++ و Java و C # و Python و Ruby. لكن تطوير منتجات الإنترنت قد أنتج مكانة متخصصة أخرى - خدمات مريحة. للتطوير الذي كانت Java فيه مبالغة ، C ++ معقدة للغاية وخطيرة ، Python / Ruby وديناميات أخرى بطيئة للغاية. والآن أصبحت واحدة من أكثر اللغات تعاسةً في المصطلحات التعبيرية للغات المطورة في القرن الحادي والعشرين تقريبًا رصاصة فضية لهذا المكانة التطبيقية. من أين ، ربما ، سوف ينتشر في مكان آخر مع مرور الوقت (وهو ما لن أفاجأ منه شخصيا ، بالنظر إلى المستوى العام لمؤهلات جيل الشباب من المطورين).

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

لذلك ، يبدو أن دورة حياة المنتج التكنولوجي الموصوفة في معضلة المبتكر يجب أن تمتد أيضًا إلى لغات البرمجة.

ولكن ليس كل شيء بسيط للغاية مع لغات البرمجة

في مخطط تغلغل المنتجات التكنولوجية الجديدة في السوق الموصوفة في معضلة Innovator ، فإن أحد أهم الأسباب التي تجعل المستخدمين ينتقلون من المنتجات الرئيسية السائدة إلى المنتجات الجديدة إما ببساطة تخفيض كبير في تكلفة الملكية أو اقتناء الفرص المتاحة مسبقًا + انخفاض في تكلفة الملكية.

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

لكن هناك مؤشران مهمان يرتبطان بالانتقال من منتج إلى آخر - وهما تكلفة / تعقيد الانتقال نفسه ، وكذلك السرعة التي يمكنك من خلالها الانتقال إلى منتج جديد. يمكن تقدير هذه المؤشرات بالمال. وإذا كانت فائدة الانتقال إلى منتج جديد موجودة ، فسيتم الانتقال. ربما ليس بسرعة ، ولكن نفذت.

وهنا اتضح أن تكلفة التبديل من لغة برمجة إلى أخرى أعلى بكثير من حالة التبديل من كمبيوتر صغير إلى كمبيوتر شخصي ، من 8 "أقراص مرنة إلى 5.25" أو من HDD إلى SSD. منذ تغيير لغة البرمجة عادة ما تكون إعادة كتابة كاملة لمنتج البرنامج. في كثير من الأحيان من نقطة الصفر.

وماذا تعني إعادة الكتابة؟ راتب فريق جديد من المبرمجين ، والذي سيحتاج إلى تكرار الوظيفة المتوفرة بالفعل في المنتج. وحتى إذا سمحت لك PL الجديدة بتخفيض حجم الفريق إلى النصف ، فسيظل هذا يعني تكاليف كبيرة. إذا تم إنفاق 10 ملايين دولار على تطوير الإصدار القديم من المنتج ، فستحتاج إعادة الكتابة إلى 5 ملايين دولار على الأقل.

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

اتضح الآن أنك بحاجة إلى البدء في استثمار الكثير من المال من أجل الحصول على نسخة من شيء كان يعمل لفترة طويلة وجلب الأموال الآن.

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

لذلك ، عند إعادة الكتابة ، تزداد النفقات: عليك كتابة نسخة جديدة في نفس الوقت وتطوير النسخة القديمة.

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

ويبدو لي أن أحد أسوأ أحلام مالكي منتجات البرمجيات في كوبول هو إعادة كتابة المنتج في Java أو C #؛)

وعامل مهم آخر: تطوير تكنولوجيا المعلومات نفسها

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

IMHO ، لقد تغيرت الأمور بشكل أساسي في السبعينيات ، ومنذ الثمانينات شهدنا ظهور أسلحة نووية ، والتي تستند بالفعل إلى كل من الخبرة العملية للماضي ونتائج الدراسات النظرية. بالنسبة لي ، فإن ثمانينيات القرن العشرين (وربما أواخر السبعينيات) هي بداية عصر لغات البرمجة التي تهدف إلى تصنيع البرمجيات على نطاق صناعي. لأنه هنا نرى Modula-2 ، SmallTalk ، Ada ، C ++ ، Eiffel ، امتدادات الكائنات من Pascal ، Objective-C ، Perl.

لذلك ، سأنتقل أكثر مما ظهر بالضبط في عصر الأسلحة النووية الصناعية.

بالمناسبة

بعد سرد اللغات التي ظهرت في الثمانينيات ، تذكرت عن PL التي طورها Niklaus Wirth: أول Pascal ، ثم Modula / Modula-2 ، ثم Oberon.

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

لكن هذه اللغات نفسها تُظهر أيضًا مدى أهمية أن يظل مستخدمي YaP ضمن إطار اللغة التي تم اختيارها من قبل. كان الانتقال من باسكال إلى Modula-2. ولكن بأي حال ضخمة. وعلى الرغم من حقيقة أن Modula-2 كان يستخدم أكثر أو أقل نشاطًا ، إلا أنه لم يصبح شائعًا مثل ورثة Pascal ، وخاصة دلفي. ولم يكن هناك انتقال ملحوظ إلى أوبيرون على الإطلاق ، بقدر ما أتذكر.

لا يمكن استبدال لغة البرمجة الشائعة. وماذا عن ذلك؟

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

لغات البرمجة الناجحة مصيرها الاستمرار في استخدامها لسنوات. وعلى الأرجح أن تتطور.

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

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

من حيث المبدأ ، تحدث Bjarn Straustrup عن هذا منذ وقت طويل. وحتى ما كنت أشاهده بنفسي منذ ما يقرب من ثلاثين عامًا يؤكد كلام ستراستروب. لنفترض أن Java الحديثة تختلف بالفعل عن Java 1.0 لعام 1995. توضح لغة C # تطوراً أكثر إثارة للإعجاب من استنساخ ناجح لجافا الأولى إلى اللغة السائدة الأكثر تعبيراً المناسبة للاستخدام من قبل المبرمجين الهندوس (بغض النظر عن جنسيتهم).

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

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

هل هو سيء للغاية؟

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

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

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

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

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

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

في الواقع ، نفس الشيء مع لغات البرمجة.

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

الحديث عن المهام

, (.. , , , .., ..), , .

. , .. , . , , . , , , . , , , .

, , Go, Python, Ruby PHP, , , , . , , , , . .

, , , , . , 25 GUI , . , 25 .

, , , . , / , , .

, , , , , C++, Scala Haskell. , , . , , Go C.

. . , , : , , . , - C++, . .., -, C++ . , -, C++ , , .

في المجموع

, ? :

• -, . , , , « », 1960-1970- , . , . , . ( ). - X, , X . , C. , . . , — . ;
• -, , 40 , . , , . , .. , , ;
• -, . - Ruby/Python, - Go, - Java. - Rust-, C++, Scala Haskell-. , . - , « », . .

, , - : , - . - . , ( , , ). , - , , : , , -. ;)