الانتباه
تلقى الإصدار الأولي من هذا المنشور استجابة كبيرة على رديت في شكل أكثر من 300 تعليق. بعد ذلك ، قررت إضافة تحديث صغير إليها للإجابة على بعض الانتقادات من الكثيرين الذين تلقوا.
لغة البرمجة المرئية هي تلك التي تسمح للمبرمج بإنشاء برامج من خلال معالجة عناصر الرسوم بدلاً من كتابة أوامر النص. ومن الأمثلة الشهيرة
Scratch ، وهي لغة برمجة بصرية موطنها معهد ماساتشوستس للتكنولوجيا تستخدم لتعليم الأطفال. مزاياه هي أنه يجعل البرمجة أكثر سهولة للمبتدئين وغير المبرمجين.
في التسعينات ، كانت هناك حركة شائعة جدًا لإدخال البرمجة المرئية في بيئة الشركات باستخدام ما يسمى أدوات
CASE ، حيث يمكن تعريف أنظمة الشركات باستخدام
UML وإنشاء [كودهم] دون الحاجة لجذب مطوري البرمجيات المدربين. ويرجع ذلك إلى مفهوم "التعميم الدائري" ، حيث يمكن تصميم النظام بصريًا ، وسيتم إنشاء رمز البرنامج من النماذج الناتجة ، ويمكن إرجاع أي تغييرات في التعليمات البرمجية إلى النموذج. للأسف ، لم تكن هذه الأدوات قادرة على الوفاء بمهمتها ، ومعظم التجارب [على تنفيذها] تم التخلي عنها حاليًا إلى حد كبير.
وبالتالي ، لم تكتسب البرمجة المرئية شعبية ، باستثناء بعض المناطق المحدودة للغاية. هذا الموقف يرجع إلى حد كبير إلى المفاهيم الخاطئة التالية حول البرمجة:
- تخلط لغات البرمجة النصية بين ما هو في الأساس عملية بسيطة.
- يلعب التجريد والفصل ( فك الارتباط ، تقليل التوصيلية ) دورًا هامشيًا صغيرًا في البرمجة.
- الأدوات التي تم تصميمها للمساعدة في البرمجة ليست مهمة.
يصر التصور الخاطئ الأول على أن تطوير البرمجيات له عتبة عالية للدخول ، لأن لغات البرمجة النصية تعقد الطبيعة الحقيقية للبرمجة. شعبية Scratch بين المعلمين الأكاديميين تلعب مع هذا المفهوم الخاطئ. تكمن الفكرة في أن البرمجة بسيطة للغاية ، وإذا استطعنا تقديمها فقط بتنسيق رسومي واضح ، فسيؤدي ذلك إلى تقليل منحنى التعلم والجهد العقلي المطلوب لإنشاء رمز البرنامج وقراءته بشكل كبير.
أفترض أن هذا المفهوم الخاطئ ينبع من عدم القدرة على قراءة برنامج نموذجي مكتوب بلغة البرمجة النصية القياسية وتخيل كيفية تحويله إلى عناصر رسومية من مكعبات وسهام. إذا كنت لا تزال تتخيل هذا ، فسوف يتضح على الفور أن سطرًا واحدًا من الشفرة غالباً ما يتطابق مع عدة "كتل". نظرًا لوجود أبسط برنامج في وجود مئات أو سطرين من التعليمات البرمجية ليس بالأمر غير العادي ، فسيتحول الرمز الخاص به إلى مئات أو حتى آلاف العناصر الرسومية. ستكون محاولة تحليل هذه الصورة المعقدة عقلياً أكثر صعوبة من مجرد قراءة نص البرنامج المكافئ.
يتمثل الحل لمعظم لغات البرمجة المرئية في جعل "الكتل" أكثر تعقيدًا بحيث يكون كل عنصر مرئي مكافئًا لمجموعة كبيرة من التعليمات البرمجية النصية. الأدوات البصرية لسير العمل هي حجر عثرة فوري.
المشكلة هي أنه لا يزال يتعين تحديد الرمز في مكان ما. لذلك ، تتحول عملية الترميز [على العناصر المرئية الكبيرة] إلى "خصائص مربع حوار البرمجة". لا تمثل العناصر المرئية نفسها سوى أعلى مستوى لحركة البرنامج أثناء التنفيذ ، ويتم معظم العمل الآن في شفرة نصية قياسية مخفية في "مكعبات" مرئية. نتيجة لذلك ، اتخذنا أسوأ ما في العالمين وحصلنا على برمجة نصية لا تدعمها الأدوات الحديثة.
تكون مربعات حوار الخصائص عادةً بيئات تطوير غير قياسية وتفرض اختيارًا محددًا للغة ، وعادة ما تكون لغة برمجة من نوع ما. لا يمكن إنشاء العناصر المرئية الأساسية نفسها إلا بواسطة مبرمجين متمرسين ، ويمكن فهمها تمامًا فقط من خلال قراءة التعليمات البرمجية الأساسية الخاصة بهم ، وبالتالي تضيع هنا معظم الفوائد المزعومة للعرض المرئي.
يوجد عدم تطابق بين "الكود" المرئي والرمز النصي (
مجموعة من الصعوبات المفاهيمية والتقنية ) ، ويتعين على المبرمج التنقل بين الواجهة بينهما ، وغالبًا ما يبذل جهدًا أكبر في تحسين أداة البرمجة الرسومية نفسها بدلاً من حل المهمة الأولية [كتابة البرنامج].
والآن نصل إلى الاعتقاد الخاطئ الثاني بأن التجريد وإلغاء الإبطال يلعبان دورًا صغيرًا في البرمجة. تعتمد البرمجة المرئية على افتراض أن معظم البرامج عبارة عن تسلسل إجرائي بسيط ، يشبه إلى حد ما مخطط انسيابي. وكقاعدة عامة ، يعتقد معظم المبرمجين المبتدئين أن البرنامج يعمل على هذا النحو.
ومع ذلك ، بمجرد أن يصبح البرنامج أكثر من مجرد مثال تافه ، فإن تعقيده سيتغلب على المبرمج المبتدئ قريبًا. يجد المبتدئين أنه من الصعب للغاية التحدث عن قاعدة كبيرة للكود الإجرائي وغالبًا ما يتعثرون في محاولات لإنشاء برامج كبيرة الحجم مستقرة وفعالة. كان الابتكار الرئيسي في لغات البرمجة هو محاولة السيطرة على التعقيد ، عادةً من خلال التجريد ، التغليف ، وخفض التوصيلية. تعد كافة أنظمة الإنشاءات ولغات البرمجة الموجهة للكائنات والوظيفية مجرد محاولة للسيطرة على تعقيد هذه اللغات.
سيقوم معظم المبرمجين المحترفين بتجريد وفك الشفرة باستمرار. في الواقع ، فإن الفرق بين الشفرة الجيدة والسيئة هو في الأساس كم تمكن المبرمج من القيام بذلك. نادراً ما تمتلك أدوات البرمجة المرئية آليات فعالة لمثل هذه الأشياء ؛ ونتيجة لذلك ، فإن المطور "المرئي" محاصر في القدرات المتاحة ، أي ما يعادل BASIC في السبعينيات.
الاعتقاد الخاطئ الأخير هو أنه يمكن للمبرمجين المرئيين الاستغناء عن جميع أدوات دعم البرمجة التي تم تطويرها على مدار عقود. ألق نظرة على التطور الطويل لمحرري الأكواد و IDEs. على سبيل المثال ، يدعم Visual Studio أداة intellisense فعالة تتيح لك الاطلاع على الآلاف من واجهات برمجة التطبيقات المتوفرة في مكتبة الفئة الأساسية وحدها. عدم وجود تحكم جيد في الإصدار هو عيب رئيسي آخر في معظم أدوات البرمجة المرئية.
حتى إذا قاموا بحفظ تخطيطهم بتنسيق نصي ، فإن "الفوارق" ليس لها أي معنى أو لا تقريبًا. من الصعب جدًا إلقاء "اللوم" (للعثور على الالتزام والمسؤول عن تغيير سطر معين) في كتلة كبيرة من XML أو JSON. الأشياء التي لا معنى لها للتنفيذ الوظيفي للبرنامج ، مثل موضع وحجم العناصر الرسومية ، تؤدي دائمًا إلى تغييرات في البيانات الأولية ، مما يجعل الفرق أكثر صعوبة في التحليل.
لقد تعلمت لغات البرمجة النصية فصل الكتل الهيكلية للتعليمات البرمجية في ملفات مصدر منفصلة ، لذلك من السهل دمج التغيير في جزء واحد من نظام مع تغيير في جزء آخر. عادةً ما تحفظ الأدوات المرئية النتيجة وفقًا لمبدأ "رسم تخطيطي واحد لكل ملف" ، مما يعني أن الدمج يصبح مشكلة ، بل وأكثر صعوبة إذا كان المعنى الدلالي لـ "فرق" يصعب تحليله.
تحديثربما كنت مخطئًا عندما التقطت لقطة شاشة سكراتش واستخدمتها كمثال أولي في فقرتي الأولى. أنا لست مدرسًا وليس لدي رأي خاص حول فعالية Scratch كأداة تعليمية. يقول الكثير من الناس أنه مفيد للغاية في تدريس البرمجة ، خاصة للأطفال. كل ما يساعد الناس على الدخول في عالم البرمجة الرائع والمثير يجب أن يكون موضع ثناء فقط. في الحقيقة لم أكن أنوي انتقاد Scratch على وجه التحديد الآن ، هذا مجرد مثال على نظام البرمجة المرئية ، والذي ، كما بدا لي ، كان ينبغي أن يسمع معظم القراء على الأقل.
مثال عداد آخر تم توفيره من قبل Reddit كان أدوات البنية الثابتة مثل مصممي واجهة المستخدم أو مصممي مخطط قاعدة البيانات أو مصممي الفصل. أوافق على أنها يمكن أن تكون مفيدة للغاية. أي شيء يساعد على تصور بنية البيانات أو بنية مقياس البرنامج هو مكافأة. لكنها ليست كافية أبدا. يتضح هذا من خلال الفشل الكامل للأدوات في التسعينيات ، مثل Power Builder ، والتي كانت تستند إلى تصورات رسومية لإنشاء بيئة تطوير دون الحاجة إلى التعامل مع الكود.
عن المؤلف:
الملاحظات والأفكار بصوت عال والتعلم في مرأى من الناس وسوء الفهم والأخطاء والآراء غير المخففة. أنا مايك هادلو ، مطور وعظ. أعيش بالقرب من برايتون على الساحل الجنوبي لإنجلترا.
تم دعم الترجمة بواسطة شركة EDISON Software ، وهي شركة محترفة لتطوير البرمجيات واختبارها .