في الحوسبة ، تسمح لغات البرمجة المرئية (VPLs) للمستخدمين بإنشاء برامج من خلال معالجة عناصر البرنامج بيانياً بدلاً من تحديدها في النص. ولكن حتى الآن ، لم تنجح البرمجة المرئية ، إلا في بعض المجالات المحدودة للغاية. في هذا الصدد ، يعتقد البعض أن لغات البرمجة النصية تخلط بين جوهر البرمجة ، ويقول بعض مستخدمي الإنترنت إن الأدوات التي تم تطويرها لدعم البرمجة ليست مهمة ، فأين المخرج من البرمجة المرئية؟
في هذا الصدد ، نشر كاتب هذا المقال ، إيفان دانيلوك ، مقالاً طويلاً يحلل أسباب فشل لغات البرمجة المرئية ، وناقش تطبيق وحلول لغة Go الناشئة في البرمجة المرئية.
المؤلف | إيفان دانيلوك
مترجم | الغضروف المفصلي ، رئيس التحرير | تو مين
مُنتجة | CSDN (المعرف: CSDNnews)
ما يلي هو الترجمة:
كنت أرغب في الوصول مباشرة إلى هذه النقطة والانتقال مباشرة إلى الموضوع ، لكنني شعرت أنه من الضروري إعطاء بعض المعلومات الأساسية أولاً.
كل ذلك لأنني أشعر أن كتابة التعليمات البرمجية النصية أمر محبط للغاية.
IDE والشعلة
هل تعرف ما هو الشيء المشترك بين محرري الشفرات والمشاعل؟
تاريخيًا ، اعتدنا على قراءة كود النص المصدر بأسلوب تنازلي ، ومن اليسار إلى اليمين ، بالطريقة نفسها التي نقرأ بها اللغة الغربية الطبيعية ، وفي نظام الكتابة الأفقي ، يمتد النص إلى الأسفل ، ويشكل النص العمودي ثم تخزينها في الملف.
من أجل قراءة التعليمات البرمجية النصية وتصفح البنية ، نحتاج إلى استخدام محرر كود - محرر نص مخصص مع إبراز بناء الجملة وتحليل كود متكامل. أنا أستخدم Vim ، وأحب مظهره المريح وواجهة وحدة التحكم ، لكن العديد من الأشخاص يفضلون محرر كود متقدم يركز على نقرات الماوس للتفاعل. في كلتا الحالتين ، نحتاج إلى تمرير النص والانتقال ذهابًا وإيابًا بين الملفات.
نحن معتادون على هذا النوع من العمل اليومي بحيث يصعب تخيل التصغير والنظر إليه من مسافة بعيدة. ولكن إذا نظرت إليها بهذه الطريقة حقًا ، ستجد نفسك جالسًا أمام جدار نصي وتستخدم هذه النافذة المنزلقة المسماة "المحرر" للتنقل حول الحائط ثم إحضار جزء صغير منه إلى الشاشة يمكنك التحقق من ذلك عن قرب.
نظرًا لأنه لا يمكنك رؤية رمز بخلاف الرمز على الشاشة ، فهذا يعني أن الحائط بأكمله في ظلام دامس.
لذلك ، تجلس وحيدًا في الظلام ، محاطًا بجدار به نص مشفر ، وتسلط الضوء على ذلك الجدار من خلال محرر الشفرة الخاص بك وتقرأ جزءًا صغيرًا منه. الآن ، تخيل وجود مشاعل أمامك بدلاً من شاشة متوهجة ، وستشعر أن المحرر مجرد مصباح عصري.
عند قراءة قاعدة بيانات جديدة ، فأنت مثل رجل عجوز في كهف مظلم ، تقرأ الكلمات أو اللوحات على الحائط من خلال المشاعل.
يجب أن أقول ، يا لها من طريقة قديمة. بالطبع ، لا حرج في التفاعل مع العالم كما فعل القدماء. ومع ذلك ، هناك الكثير من المشاكل هنا! نقضي 90 من وقتنا في قراءة الكود و 10 فقط في كتابة الكود ، ويصادف أن 90 هو الجزء الأقل تفضيلاً لدي.
تتطلب قراءة التعليمات البرمجية اهتمامًا جيدًا للغاية ، واهتمامًا شبه مثالي ، يتجاوز ذاكرة الشخص العادي ، ومملة للغاية. يخبرني حدسي أن هذا كله خطأ في النص. عندما أكون على وشك قراءة قاعدة بيانات جديدة أو لدي طلب سحب كبير ، فإن وجهي يشبه وجه الناسك.
حتى أن هناك بحثًا حول قراءة الكود من خلال أنظمة تتبع العين ، يؤكد أننا نقرأ الكود المصدري بطريقة مختلفة تمامًا عن النص القياسي. بدلاً من القراءة سطرًا بسطر ، نستخدم نمط المسح ، مثل التحديق في رمز غير مفهوم أو مجالات الاهتمام ، والقفز ذهابًا وإيابًا ، أثناء تخطي سطور معينة أو كتل كاملة من التعليمات البرمجية ، مثل هذا:
ماذا لو لم يكن النص هو أفضل شكل لعرض الكود؟
البرمجة المرئية
من الواضح أنني لست أول من يفكر في سلبيات تمثيل الكود في النص. لغات البرمجة المرئية هي مجال كامل ، حيث ظهرت مئات من هذه اللغات على مدار الستين عامًا الماضية.
يمكنك العثور على مواد وأدبيات معدة جيدًا من الإنترنت تقدم نظرة عامة وتاريخًا للغات البرمجة المرئية ، وهنا أقدم اثنين من الروابط المفضلة لدي:
- https://www.youtube.com/watch؟v=mdYfFDJCDHc
للتلخيص ، يمكن تقسيم هذه اللغات إلى فئتين رئيسيتين:
لغة البرمجة المرئية القائمة على الكتلة
في بيئة لغة البرمجة المرئية القائمة على الكتلة ، لا تحتاج إلى إدخال رمز نصي ، ولكن يمكنك سحب وإفلات الكتل المحددة مسبقًا في منطقة البرنامج النصي. لست بحاجة إلى الكتابة على الإطلاق ، فلديك واجهة مستخدم ملونة ، ويكاد يكون من المستحيل ارتكاب أخطاء نحوية.
ربما سمعت عن لغات مثل Scratch و MIT App Inventor و Google Blockly والمزيد. تستخدم هذه اللغات بشكل أساسي لتعليم الأطفال والمبرمجين المبتدئين أساسيات البرمجة ، وتستخدم على نطاق واسع في المدارس وبعض الأنشطة. أثبتت دراسات متعددة أن هذه اللغات لها تأثير إيجابي على الطلاب الذين يأخذون دورات في علوم الكمبيوتر. أيضًا ، في العديد من المشاريع المختلطة ، يمكنك أيضًا تحويل أمثلة التعليمات البرمجية البسيطة من اللغات السائدة مع تمثيلات نصية لحظر التمثيلات والعكس صحيح ، مما يساعد على الانتقال من الفئات المستندة إلى الكتلة إلى "البرمجة الحقيقية".
لكن يبدو أن استخدامها يقتصر على ذلك. أيضًا ، يقول الكثير من الناس إنها ليست برمجة مرئية على الإطلاق ، فقط استبدل إدخال لوحة المفاتيح بإدخال الماوس. أنا أتفق بشكل أساسي مع وجهة النظر هذه.
لغة البرمجة المرئية القائمة على التدفق
فئة أخرى من لغات البرمجة المرئية هي في الواقع مجموعة فرعية لما يسمى باللغات القائمة على التدفق ، والمعروفة أيضًا باسم لغات البرمجة القائمة على العقد. يستخدمون المخططات الانسيابية لتمثيل التغييرات في الحالة أو المنطق أو البيانات.
في بعض الأحيان ، تكون الفكرة وراء هذه اللغات هي أن منطق البرنامج يجب أن يتم تنفيذه بواسطة شخص على دراية بمجال المشكلة (مثل طبيب أو مهندس) ، ويجب أن يتم عمل ترجمة هذا المنطق إلى رمز بواسطة شخص آخر أو برنامج. هذا ليس من دون سبب.
يحاول العديد من الأشخاص إنشاء لغات البرمجة المرئية للأغراض العامة القائمة على التدفق ، مثل Raptor أو Flowgorithm أو Visual Logic أو DRAKON ، والتي تحظى بشعبية كبيرة في مجالات مثل البرمجة ثلاثية الأبعاد أو توليف الموسيقى أو معالجة الإشارات أو إنترنت الأشياء / أدوات تصميم الدوائر المدمجة . بعض الأدوات التي قد تكون على دراية بها (حتى استخدامها كل يوم) ، مثل محرر Unreal Engine ، أو Max / MSP ، أو Labview من National Instruments ، أو أدوات مثل Autodesk Dynamo. كثير من الناس يستخدمون هذه الأدوات بنشاط في الممارسة العملية ، لكنها لا تزال مجالات ضيقة للغاية وحلول متخصصة للغاية. من غير المحتمل أن تستخدم إحدى هذه الأدوات ، أو كتابة محرك تتبع الأشعة ، أو برنامج تشغيل النواة ، أو خادم GraphQL.
2.5 لغات البرمجة المرئية الأخرى
هناك أيضًا مجموعة من المنتجات الغريبة مثل Prograph أو Cables ، ومن الصعب تحديد الفئة التي تقع فيها. كانت Prograph ، التي تم تصميمها في الثمانينيات على سبيل المثال ، أول لغة مرئية حقًا موجهة للكائنات وقدمت بعض الأفكار المثيرة التي أحببتها حقًا ، لكنني فشلت عندما حاولت استخدامها من أجل الحنين إلى الماضي.
أيضا ، Pygmalion من السبعينيات مثيرة للاهتمام. لأنه يستخدم تقنية برمجة منسية: البرمجة التوضيحية. في الأساس ، أنت لا تكتب الخوارزميات عن طريق البرمجة ، بل توضحها للآلات ، رائع ، أليس كذلك؟ إلى حد ما ، لا يزال هذا المجال بحاجة إلى استكشاف.
لا توجد لغة برمجة مرئية سائدة؟
ومع ذلك ، لا توجد حاليًا لغة برمجة مرئية ذات أغراض عامة سائدة. يوضح كل مقياس أن بيئة لغة البرمجة الحديثة تهيمن عليها لغات البرمجة النصية بنسبة 100 ، دون استثناء.
لماذا يحدث هذا؟ يوجد مثل في اللغة الإنجليزية: "الصورة تساوي ألف كلمة" ، ويخبرنا حدسنا أن الكلمات ليست أفضل طريقة للتعبير عن كل شيء. كل هؤلاء الأشخاص الأذكياء الذين يعملون على لغات البرمجة المرئية يرون هذا بوضوح ، لكن يبدو أننا نفتقد ما هو ضروري لجعل البرمجة المرئية حقيقة واقعة.
لماذا فشلت لغات البرمجة المرئية؟
أثار هذا السؤال فضولي منذ زمن بعيد ، وباختصار ، جوابي هو: لا نعرف ما الذي نفعله. لا يوجد تفسير علمي مقبول بشكل عام لماهية البرمجة. نحن ببساطة نصمم لغات جديدة بطرق مختلفة ، سواء كانت مرئية أو نصية ، نريد التعبير عن أفكارنا بشكل أفضل.
لجعل الأمور أسوأ ، لدي شعور ينذر بالسوء أن مجتمع نظرية لغة البرمجة لا يهتم بالبرمجة المرئية. على الأقل لم أشاهد أبدًا بحثًا جادًا يدعو أخصائيًا نفسيًا أو عالمًا أعصابًا لإدخال ميزة جديدة أخرى في لغة البرمجة المرئية. ومع ذلك ، آمل أن أكون مخطئا.
لذلك ، نشعر جميعًا أننا بحاجة إلى البرمجة لتمثيل الأشياء المجردة ، ولكن ماذا يعني ذلك بالضبط؟ ما رأيك عندما تقرأ أو تكتب أو حتى تفكر في البرمجة؟ ما الأطر التي يمكننا استخدامها للتحقق من أداء اللغة المرئية وقياسه؟
نادرًا ما يتم طرح هذه الأنواع من الأسئلة ، ناهيك عن الإجابة عليها.
إذا حاولت الإجابة على هذه الأسئلة بنفسك ، فلا بد أن ينتهي بك الأمر في الفلسفة أو علم الأعصاب ، أو كليهما. منذ أن كنت دائمًا مهتمًا جدًا بكيفية عمل الدماغ ، أصبحت قراءة الكتب والأوراق حول الموضوعات المتعلقة بالدماغ هواية ، وأعتقد أنها تساعدني في رؤية هذه القضايا من منظور جديد. على الرغم من أن فهم علماء الأعصاب لعمل الدماغ لا يزال سطحيًا ، ولدي فقط فهم محدود لنتائجهم ، أود أن أشارك جانبين مهمين وأقل وضوحًا أعتقد أنهما أساس هذا الموضوع. على الأقل ، يلعب دورًا مهمًا في فهم هذه المقالة ، لأن أساساتي تقوم على هذين الجانبين.
المعرفة الأساسية للدماغ البشري
يتكون دماغ الإنسان من حوالي 9-10 مليار خلية عصبية تشكل 1 تريليون اتصال فيما بينها ، والدماغ البشري هو أكثر الأشياء تعقيدًا في النظام الشمسي ، لذلك لا يمكن تفسيره بسهولة.
يأتي وعينا وأفكارنا من جزء من الدماغ يسمى القشرة المخية الحديثة. يعرف معظم الناس الدماغ على أنه شيء على شكل جوز مع سطح مجعد ، ولكن قد تفاجأ عندما تعلم أنه في الواقع نسيج مسطح بسمك 5-6 مم. بعد زيادة سريعة في مساحة السطح ، تم ثنيه في الشكل الذي هو عليه اليوم من أجل استيعاب الجمجمة (التي كانت أكثر تكلفة من الناحية التطورية للنمو ، حيث كانت بحاجة لتتوافق مع نمو الحوض لاستيعاب عملية التكاثر).
هذا النسيج متجانس للغاية في التركيب ، مع نفس الطبقات الخمس من الخلايا العصبية عبر سطحه بالكامل ، منظمة من خلال أعمدة قشرية. تشير بعض النظريات إلى أن هذا العمود القشري هو "وحدة حسابية" في القشرة المخية الحديثة تؤدي مهمة رئيسية واحدة - تلقي كميات كبيرة من المدخلات واستخراج الأنماط منها وتعلم كيفية التنبؤ.
الوعي والفكر والتفكير على مستوى أعلى والوعي الذاتي هي مجرد منتجات ثانوية للنطاق الهائل والتعقيد لهذه المنظمات لاستخراج المخططات. نحن هنا نتحدث عن مقياس مكافئ لحجم المجرات في الكون المرئي.
وضع المكان والزمان
أولاً ، أريدك أن تنتبه إلى مفهوم الأنماط ذاته. هناك وضعان رئيسيان في الكون: المكان والزمان. يعني الفضاء أن يكون مرتبطًا بالمكان والزمان ليكونا مرتبطين بالوقت. على سبيل المثال ، هنا والآن. ينبع هذا الاختلاف من طبيعة كوننا ، وتعلم الدماغ المتطور معالجة النموذجين وفقًا لذلك.
على سبيل المثال ، الرؤية تتعامل بشكل رئيسي مع المعلومات المكانية ، القشرة البصرية ممتازة في استخراج عدد كبير من الأنماط الأكثر شيوعًا من المدخلات البصرية التي توفرها شبكية العين. لالتقاط العلاقة المكانية ، عليك الحصول على كل المدخلات "في الوقت المناسب" ، لا يمكنك النظر إلى الصورة بكسل واحد في كل مرة. عليك أن ترى جميع وحدات البكسل مرتبة في مساحة في نفس الوقت بالطريقة الصحيحة.
من ناحية أخرى، السمع مرتبط بشكل أساسي بالأنماط الزمنية ، لا يمكنك سماع جميع الملاحظات في نفس الوقت. لا يمكن توزيعها إلا على فترات مختلفة.
بالطبع ، تأخذ جميع مدخلاتنا الحسية في الاعتبار الأنماط المكانية والزمانية ، لكن الأمثلة المرئية والسمعية هي مثال جيد للفكرة الأساسية لطريقتين مختلفتين. يعالجها الدماغ بشكل مختلف تمامًا عند المستوى الأدنى ، لكن من المثير للاهتمام أنه يمكننا استخدام التمثيلات المكانية لتمثيل المعلومات الزمنية والعكس صحيح. في الواقع ، نحن نفعل ذلك كثيرًا. الملاحظات هي مثال جيد ، حيث نقوم بترميز الوقت بتمثيل مكاني. لاحظ أنه من أجل فهم هذا التمثيل ، عليك تدريب عقلك على فك رموز أوقات التعافي ، وهي مهمة صعبة معرفيًا - لا يمكن للجميع قراءة النوتة الموسيقية وتشغيل أغنية في رؤوسهم.
أريدك أن تتذكر هذا الاختلاف في المكان والزمان. سوف نستخدمه قريبا
الرسم البياني المعرفي
الشيء الثاني المهم الذي يجب أن تعرفه عن البرمجة هو أن كل المعارف يتم تخزينها بطريقة ما في القشرة المخية الحديثة الخاصة بك. هناك عدد لا يحصى من النظريات التي تحاول شرح كيفية تخزين ذلك ، لكنني أعتقد أننا بعيدون عن الإجابة الحقيقية. لكننا نعلم أنه مقابل كل مفهوم ، كل نقطة معرفة ، كل تجريد أو شيء لديك تحت تصرفك ، عندما ترى ، تسمع ، تفكر ، أو حتى تحلم ، تنطلق مجموعة من الخلايا العصبية.
على سبيل المثال ، قام مختبر Gallant Lab في جامعة كاليفورنيا في بيركلي بعمل ممتاز في تسجيل نشاط الدماغ عبر fMRI (التصوير بالرنين المغناطيسي الوظيفي) بينما استمع المشاركون إلى بث تلقائي مُصنَّف بتدفقات الكلام وربط نشاط الدماغ بالتسميات ، ثم تمت مطابقة WebGL تفاعلي تم إنشاء أطلس الدماغ ، والذي يمكنك تجربته عبر الإنترنت (https://gallantlab.org/huth2016/). في النهاية ، وجد أن الأشياء المتشابهة لغويًا تميل إلى التجمع في نفس الجزء من سطح القشرة المخية الحديثة.
لكننا نعلم بالفعل أن القشرة المخية الحديثة متجانسة ، مع عدم وجود خصوصية في الخلايا. عند تحديد وظيفة الخلية العصبية ، تحتاج إلى تحديد من وكيف يتصل. كل خلية عصبية (مجرد خلية خاصة يمكنها معالجة التيار الكهربائي) لها عمليات متفرعة تسمى العصبونات ، والتي بدورها تنقسم إلى عصبونات طويلة وقصيرة ، تسمى المحاور والتشعبات ، على التوالي. تحتوي الخلية العصبية القشرية النموذجية ، في المتوسط ، على أكثر من 7000 نيوريت ، والتي تشكل روابط مع الخلايا العصبية الأخرى. 5 طبقات * 1 تريليون خلية عصبية * 7 كيلو اتصال ، يمكنك حسابها ببطء.
تستمر هذه الروابط في النمو والتغيير والتجديد طوال حياتك ، وتشكيل روابط جديدة في كل مرة تتعلم فيها وتقوي الاتصال بين شيئين. تسمى هذه الوصلات بالشبكة العصبية ، ويسمى مجال علم الأعصاب بأكمله علم الوصلات العصبية. يعد فحص دماغ بشري حقيقي ، ورسم خرائط لجميع الاتصالات ، وإنشاء نموذج كمبيوتر مهمة صعبة للغاية ، ولكن هذا ما تسعى الوصلات جاهدة من أجله. تستخدم بعض الدراسات بيانات من مشروع Human Connectome Project (مشروع مدته 5 سنوات ممول من المعاهد الوطنية للصحة بدأ في عام 2009) وتتنبأ بذكاء السوائل (أو معدل الذكاء) من خلال تحليل اتصالات معينة في الرسم البياني للشبكة العصبية.
من فضلك فكر مليا.
لديك رسم بياني للمعرفة الجسدية في عقلك يمثل معتقداتك حول الواقع. من خلال الفيزياء ، على وجه الدقة ، الروابط المادية الفعلية في العالم الحقيقي ، على المستوى الجزيئي. هذا هو السبب في أنه من السهل تعلم شيء ما من البداية ، ولكن ليس من السهل إعادة تعلمه. لا يمكنك فقط حذف الاتصالات التي نمت. يجب عليك تطوير اتصال جديد أقوى من ذي قبل.
من المهم ملاحظة أنني لم أبسط ما ورد أعلاه عن قصد ، فالمعرفة نفسها بسيطة. آمل أن لا يغضب علماء الأعصاب الذين قرأوا هذا المقال لأنني اعتقدت أنني أفرط في التبسيط بشكل متعمد ، ومع ذلك ، أعتقد أنني تناولت الوظائف الأساسية للدماغ ، وسأقوم ببناء البرمجة المرئية على أعلى هذا الإطار.
ما هي البرمجة؟
بدأت تعلم البرمجة عندما كان عمري حوالي 6 أو 7 سنوات ، ويبدو جوهر البرمجة بسيطًا: أعطي تعليمات لجهاز الكمبيوتر. لكن على ما يبدو لم يعد هذا هو الحال بعد الآن. معظم البرامج الحديثة لا تتصل مباشرة بالأجهزة.
عندما يبدأ الناس في تعلم لغة برمجة جديدة ، فإنهم غالبًا ما يسألون ، "ما التمارين التي يجب أن أفعلها؟" وهذا يعني أنهم بحاجة إلى حل مشكلة في لغة البرمجة. إذا لم تكن هناك مشكلة لحلها ، فلا حاجة إلى البرمجة.
"المشكلة" هنا لا تعني "حدث شيء سيء" ، ولكن تعني أي شيء من العالم الحقيقي.
جوهر كتابة الكود هو التعمق في مجال المشكلة ، وفهم جوهرها ، وبناء نموذجها العقلي ، والتعبير عن جوهرها الداخلي من خلال لغة البرمجة.
كود وخريطة
بطريقة ما ، الكود هو خريطة ثانوية للواقع. النموذج العقلي للمشكلة هو المستوى الأول ، وخريطة النموذج العقلي للتمثيل هو المستوى الثاني.
أستخدم كلمة "خريطة" هنا لأنها تعبر عن خاصية مهمة للخريطة: نسخة مصغرة من الشيء الفعلي. الخرائط ليست مناطق ، وكل خريطة ليست مثالية. الخريطة المثالية بلا حدود لم تعد خريطة ، إنها المصفوفة في المصفوفة.
ومع ذلك ، فإن صعوبة الكود كخريطة هي أنه يجب أن يكون قابلاً للعكس. من خلال قراءة الكود ، يجب أن تكون قادرًا على استعادة نفس النموذج العقلي تمامًا مثل الحل. ما أقوله صحيح ، قراءة التعليمات البرمجية المكتوبة قبل شهر يجب أن تحفز نفس مجموعات الخلايا العصبية في عقلك التي تكونت عندما كتبت الرمز في ذلك الوقت!
التواصل الاجتماعي
لتعقيد الأمور ، يجب أن تكون العملية قابلة للعكس بالنسبة للأدمغة الأخرى أيضًا. هذه مهمة صعبة بشكل لا يمكن تصوره لأنه لا يمكنك الاعتماد فقط على نموذجك العقلي ، ولكن أيضًا مراعاة النماذج العقلية للعقول الأخرى. يجب عليك بناء نموذج عقلي للنماذج العقلية للمبرمجين الآخرين والتحقق من صحة خريطتك مقابلها ، ثم تحديد ما إذا كان هناك شيء واضح أو سيتلقى تعليقًا واسع النطاق. هذا هو المكان الذي يلعب فيه الجانب الاجتماعي للبرمجة.
البرمجة نشاط اجتماعي. روبرت سي مارتن
البرمجة هي عملية رسم خرائط خالصة ، ولغات البرمجة هي أدوات رسم الخرائط الأساسية. هيكل الكود الجيد مشابه جدًا لهيكل مجال المشكلة ، هل رأيت ظل قانون كونواي؟
هل شعرت يومًا أنه كلما رأيت أي مطلب جديد غير مرئي ، فأنت تدرك أن المطلب يتناسب بشكل جيد مع تصميم الكود مع تغيير بسيط فقط؟ إنه نوع من المبالغة ، لكني أستمتع حقًا بهذه اللحظة.
الشفرة الجيدة هي دائمًا خريطة جيدة ، خريطة ثانوية للخريطة الذهنية على مجال المشكلة.
رسامي الخرائط وجامعي
لكن ليس كل شخص رسام خرائط جيد.
في ورقة حجر المبرمجين منذ 20 عامًا (https://www.datapacrat.com/Opinion/Reciprocality/r0/index.html) ، يشرح المؤلفون سبب كون بعض المطورين أفضل من غيرهم ، وقدموا مفاهيم "التعيين" و "المجموعة". إنها ليست مفاهيم علمية ، لكنني أعتقد أن المؤلف على حق ، فقد كان لقراءة الورقة تأثير كبير عليّ في ذلك الوقت.
"رسام الخرائط" لديه خريطة ذهنية للعالم بأسره في رأسه ، نموذج للأشياء ذات الروابط والعلاقات الغنية بين الأشياء. إنهم يراجعون ويحسنون الخريطة الذهنية باستمرار ، وستتم إضافة أي معلومات جديدة إلى الخريطة في الموقع الصحيح.
هذه الخريطة تخلق معرفة منظمة ، يمكنهم حقًا فهم العالم ورؤية أسباب وتأثيرات الأشياء.
وعلى العكس من ذلك ، فإن "المُجمع" يقوم ببساطة بجمع المعرفة في الدماغ دون إجراء أي اتصالات. هم فقط يحفظون ويتعلمون الردود الصحيحة ميكانيكيا. بالنسبة لهم ، فهم العالم يعني تذكر أكبر قدر ممكن من المعرفة.
لا أشير غالبًا إلى هذه الورقة لأنها تقسم الناس إلى فئتين مختلفتين ، حيث يكون هواة الجمع مخطئين ، ويعتقد المؤلف أن الغالبية العظمى من الناس في العالم هم من هواة جمع التحف. كونك رسام خرائط لا يجعلك أفضل ، وكونك جامعًا لا يجعلك بالضرورة أسوأ. لكن الأهم من ذلك ، أننا رسامو خرائط وجامعو خرائط على حد سواء ، فقط نميل قليلاً بهذه الطريقة أو تلك. لكن المفهوم لا يزال يلخص ملاحظاتي وخبراتي الفعلية في أذهان الناس ، لذا فمن الجدير بالذكر.
كيفية فك شفرة خريطة الكود
عندما يتعلق الأمر بملاحظة الأفكار ، قد يعتقد الكثير من الناس أن التأمل الذاتي صعب ، لكنني دائمًا ما استمتعت بمراقبة أفكاري ، لذا فإن تحليل أفكاري أثناء الكتابة أو قراءة الكود ليس غريباً بالنسبة لي.
في مرحلة ما ، أدركت أن كل مشكلة أحلها مرتبطة بالزمكان. كل سؤال له أجزاء من الزمان والمكان. يعكس الجزء المكاني العلاقة بين الأشياء ، بينما يعكس الجزء الزمني كيفية تفاعلها في أوقات مختلفة.
الخطوة 1: العلاقات المكانية
في كل مرة أفتح فيها رمزًا غير مألوف ، فإن الخطوة الأولى هي إنشاء خريطة مكانية في رأسي تعكس معنى الرمز ، ومحاولة توصيل كل سطر من التعليمات البرمجية واسم الملف إلى عقلي بناءً على مجال المشكلة الذي يجب أن ينتمي إليه الرمز على الخرائط الذهنية الموجودة. الأهم من ذلك ، أن هذا كله يتعلق بالخرائط المكانية - كل ما أفعله هو العثور على الأشياء والتجريدات والعلاقات بينها ، والتحقق من صحة هذه الخريطة بالمعرفة التي لدي.
على سبيل المثال ، كنت أقرأ كود مكتبة HTTP. لدي خريطة ذهنية (غير كاملة) لبروتوكول HTTP ، لذلك يمكنني رؤية العميل / الخادم والطلب / الاستجابة وما إلى ذلك في الكود. عند قراءة الكود لأول مرة ، أحاول ربط كل جزء من الكود بهذه المعرفة ، ثم أنشئ خريطة مكانية للرمز ، ثم تحقق منها مقابل الخريطة الذهنية الحالية.
في هذه المرحلة ، تعتبر التسمية مهمة جدًا (يمكن القول إن التسمية هي أصعب مشكلة في علوم الكمبيوتر). لإجراء اتصالات بشكل فعال ، نحتاج إلى بعض المفردات الشائعة وبعض الرموز المعروفة - هذه نصوص في الوقت الحالي. في المستقبل ، يمكن أن تكون بأشكال أخرى ، مثل لغة الرموز التعبيرية الغنية بالنصوص ، أي شيء أكثر ملاءمة وسهولة في الاستخدام. لكن في الوقت الحالي من الواضح أنه نص فقط.
الخطوة 2: العلاقات الزمنية
بعد إنشاء هذه الروابط والعلاقات في رأسي ، سأقوم بالتوسع في البعد الزمني وأقرأ رمز الوظائف الفعلية لمحاولة اكتشاف كيفية تصرف هذه الكائنات في الوقت المناسب. من الواضح أن نص جسم الوظيفة يختلف عن باقي الكود ، لذا فإن ترتيب الأسطر مهم جدًا عند البحث عن معلومات التوقيت. سيتم بالتأكيد تنفيذ السطر الأول قبل السطر الثاني ، حتى نتمكن من إنشاء نمط سلوك زمني من كود الوظيفة. لهذا السبب يمكن أن يتسبب الانتقال إلى الخ في الحجج لأنها تكسر تدفق الوقت. لغة Go لها تأجيل مفيد للغاية ، على الرغم من أنها صعبة بعض الشيء من حيث تدفق الوقت ، إلا أنها تقوم بعمل جيد. لكن في الأساس ، قانون الجسم الوظيفي صحيح ، ونحن نبني منه الجزء الزمني من الخريطة الذهنية.
مرئي أم نصي؟
سواء كان تمثيلًا مرئيًا أو تمثيلًا نصيًا ، فقد فاتك بعض النقاط المهمة هنا. يحاول أي من التمثيلات التعبير عن كل من الزمان والمكان بطريقة مماثلة ، مما يضع عبئًا كبيرًا على الإدراك ولا يفعل شيئًا.
أعتقد أن هذا هو السبب الرئيسي لعدم حصول لغات البرمجة المرئية على الكثير من الاهتمام. التمثيل المرئي للجزء المكاني هو بالطبع معقول جدًا ، ففي النهاية ، هذا هو أفضل شكل لتمثيل الفضاء ، لكن الجزء الزمني أكثر ملاءمة للتمثيل في النص - على الرغم من أنه ليس الأفضل ، لا يزال النص لا مثيل له.
حتى لغات البرمجة المرئية تفشل في تسخير قوة التمثيل المرئي ، وغالبًا ما تركز فقط على الجوانب الرمزية البحتة ، معتقدين أن مجرد استبدال النص بأيقونات يمكن أن يحدث فرقًا كبيرًا. لكن أي شخص لديه خبرة في تصور البيانات يعرف أنه من السهل تشويش التصور عن طريق رسم أشياء غير ذات صلة لغويًا عن غير قصد معًا أو باستخدام ألوان لا معنى لها.
معظم لغات البرمجة المرئية التي رأيتها سيئة للغاية في العناصر المرئية. لا يجب أن ألوم أحداً على هذا ، إنها مهمة صعبة للغاية بعد كل شيء. على سبيل المثال ، مخطط Venn أدناه لا معنى له ، لكنه يتمتع "بمظهر" جميل جدًا لذا يبدو جذابًا للغاية.
اذهب اللغة
حان الوقت أخيرًا للتحدث عن لغة Go.
Go هي اللغة التي يمكنها رسم مثل هذه الخريطة بشكل صحيح.
يقبل عيوب الخريطة ويبسطها قدر الإمكان. في Go ، لا يمكنك تمثيل الشيء نفسه بطريقتين مختلفتين ، لذا فإن الرسم مهمة بسيطة جدًا - أي مفهوم يحتاج إلى تمثيل له طريقة دقيقة لتمثيله في الكود. من المتصور أن العملية العكسية ، أي قراءة الخريطة ، مريحة للغاية أيضًا. في Go ، لا يتعين عليك تخمين ما يعنيه جزء من التعليمات البرمجية أو ما يريد المؤلف القيام به.
لغة مثالية
يجب أن أذكر جوتفريد ليبنيز ، عالم الرياضيات والفيلسوف الألماني الذي اخترع الرموز الرياضية التي ما زلنا نستخدمها حتى اليوم.
كرست حياته كلها لشيء واحد: إيجاد اللغة المثالية. الكمال يعني:
لم ينجح ، لكنه اخترع النظام الثنائي. لا أعتقد أن القاعدة الثالثة ممكنة بالفعل ، ولكن على الأقل تبذل لغة Go جهدًا كبيرًا مع القاعدتين الأولى والثانية.
في رأيي ، يجب على مصممي أي لغة برمجة أن يهدفوا إلى تحقيق نفس الهدف. إذا كنت تقرأ هذه المقالة تصمم أي لغة برمجة ، فتأكد من مراعاة هذه القواعد القليلة عند تصميم لغة. اللغة هي أداة للرسم وليس للتعبير عن الفن.
رسم الخرائط المكانية والزمانية
حتى أن لغة Go تأخذ في الاعتبار التمييز بين الأنماط المكانية والزمانية. تستخدم لغة Go أنواعًا محددة للتعبير عن المساحة ووظائف أو طرق للتعبير عن الوقت. بالإضافة إلى ذلك ، يمكننا التعبير عن السلوك العام ، والذي سنناقشه لاحقًا. وفي تلك اللغات التي تستخدم الفصول الدراسية ، يمكن للفصل أن يعني كل شيء أو لا شيء - يمكن أن يكون عبارة عن بيانات أو سلوك أو كليهما أو لا شيء ، ولكن في معظم الحالات لا معنى له من التعقيد. يميز Go بوضوح بين الاثنين ويصبح من السهل جدًا فهم الكود!
رأيت شخصًا يقول هذا على Twitter: "يبدو الأمر وكأن هناك أنواعًا ووظائف فقط في Go." لا أعرف ما إذا كانت هذه العبارة إيجابية أم سلبية ، ولكن على الأقل ، هناك الوقت والمكان فقط ، وهو مثل الكون بأسره. لا تفرض لغة Go أي قيود على الكون.
CSP
إذا لم يكن ما سبق كافيًا لشرح المشكلة ، فلنلقِ نظرة على واحدة من أكثر الميزات الممتازة للغة Go - دعم التزامن المضمّن استنادًا إلى نظرية CSP (التواصل المتسلسل العمليات). ليس من المستغرب أن هذه الميزة سهلة الفهم للغاية. ظاهريًا ، CSP بسيط جدًا. لفهمه ، تحتاج فقط إلى فهم مفهومين: العملية والقناة (تسمى "goroutine" (انتقل بشكل روتيني) و "القناة" في لغة Go). يمكن ربط هذين المفهومين بالعالم الحقيقي بسهولة شديدة وبديهي للغاية للفهم!
أي شيء لا يتطلب تدخل بشري (أي شيء "في الخلفية") يمكن أن يكون غوروتين. يمكن تمثيل أي تفاعل (اتصال) مع goroutine كقناة. يمكننا أن نرى بشكل طبيعي أنماط التزامن في كل مكان:
- التحدث أمام الجمهور - انطلق
- يقوم Cashier بجمع الأموال من العميل ويضعها في ماكينة تسجيل المدفوعات النقدية - Fan-in
- إرسال واستقبال الرسائل القصيرة - مضاعفة الإرسال مع تحديد {}
- و أكثر من ذلك بكثير
قارن مع النماذج الأخرى مثل غير المتزامن / الانتظار ، المستقبل ، وما إلى ذلك ، سترى أنك بحاجة إلى إعادة كائن في المستقبل "يحل" في المستقبل - وهو أمر غير منطقي في العالم الحقيقي ، وبمجرد استخدام Go اكتشف كيف أن هذا النموذج غير طبيعي ، كل ذلك لأنه لا يمكن تعيينه بسهولة في النماذج العقلية.
اذهب كأداة رسم بياني
عندما أقرأ أي رمز Go تقريبًا ، يمكنني العثور بسرعة على إجابة لسؤالي - لماذا يوجد هذا الرمز؟ ماذا بالضبط يعني هذا؟ هل يهم؟ ماذا يريد المؤلف التعبير؟
لا تفهموني بشكل خاطئ ، بالطبع هناك الكثير من كود Go غير المكتوب بشكل جيد ، لكنه في الغالب بسبب النموذج العقلي الذي يمثله الكود ، وليس الرسم البياني نفسه.
لقد كنت أقوم بترميز Go بدوام كامل لأكثر من 6 سنوات وما زلت أحب اللغة بقدر ما فعلت عندما بدأت في استخدامها لأول مرة. Go يجعل البرمجة ممتعة حقًا.
ولكن ، بعد كل شيء ، فإن قراءة نصوص التعليمات البرمجية التي تستغرق 90 من الوقت أمر محبط للغاية ...
أفكار التصور
أخيرًا وصلنا إلى هذه النقطة ، أعتقد أن: "Go يجعل عملية الفهم المكاني بديهية جدًا ومناسبة جدًا لطريقة تفكير الدماغ". ربما ، يسمح لي أداؤها الحدسي بترك عملية الفهم للكمبيوتر؟ بعد كل شيء ، تعتبر أجهزة الكمبيوتر رائعة في معالجة أجزاء النص ، والأدمغة رائعة في استخراج الأنماط من البيانات ، لذلك ربما تدمج إحباط قراءة الكود مع البساطة والتصورات القوية التي أحبها في Go؟
لذلك ، بدأت بالتفكير في المفهوم الأساسي للتمثيلات الذهنية "التصور الزائف" المكاني. بعض المفاهيم الأساسية هي كما يلي:
شنطة
الحزمة في لغة Go هي وحدة منطقية مركزية مجردة. تمثل الحزم عادةً أجزاء كبيرة من التجريد ، وهناك اختلافات كبيرة بين الحزم. في Go ، معنى الدلائل ليس هو نفسه في معظم لغات البرمجة السائدة. تستخدم اللغات الأخرى الدلائل كمساحات أسماء ، وهي في الأساس طريقة للتعامل مع نظام الملفات ، ولا علاقة لها بالمجال المشكل. في Go ، كل دليل عبارة عن حزمة - وحدة منطقية. يعجبني هذا التنسيق حقًا لأنه من السهل إجراء اتصالات مكانية عالية المستوى بمجرد النظر إلى بنية الدليل.
الحزمة التي تحتوي على حزم فرعية (تسمى "وحدات Go" منذ Go 1.11) هي وحدة منطقية ، وأعتقد أنها مجموعة من العقد في الرسم البياني التي لها اتصالات بالحزم الفرعية. من السهل أن نسيء فهم أن الحزمة الفرعية لا تعني أنه يجب استخدامها بواسطة حزمة (تخيل حزمة قديمة قد تظل موجودة في نظام التحكم في الإصدار لسنوات بعد إعادة البناء ، لأن الكثير من الناس يعتقدون أنها لا تزال مفيدة) ) ، واضطررت إلى حل هذا التناقض أثناء قراءة الكود.
نوع خاص أو معين
الأنواع الخرسانية - معظمها هياكل - هي أهم أداة في Go ، وتستخدم لتمثيل كل شيء ، حقيقي أو لا شيء. على سبيل المثال ، "اللون" ، "الكوكب" ، "الحالة المزاجية" ، "الوقت" ، أي شيء يمكن أن تفكر فيه يمكن تجريده بشكل منفصل يمكن تمثيله كأنواع ملموسة في الكود. بكل بساطة.
لذلك اعتقدت أن بعض الناس قد يسألون "لماذا لا يمكنني إضافة أساليب لأنواع بدائية مثل السلاسل؟" ، وهو أمر لا طائل منه تمامًا. إذا كان عليك تعديل سلوك سلسلة ، فإنها لم تعد سلسلة ، ولا ينبغي أن تكون طريقة القيام بذلك عن طريق إضافة طرق جديدة إلى السلاسل ، ولكن عن طريق إنشاء أنواع جديدة (مثل سلسلة UUID من النوع) ، يجب أن يتوافق النوع احتياجاتك وتمثل UUIDs ، وليس السلاسل العامة.
لذلك ، أرى الأنواع أيضًا كعقد ، متصلة بالحزم التي تنتمي إليها. يمكن أن تحتوي الأنواع على حقول من أنواع أخرى ، وتأتي أنواع هذه الحقول من نفس الحزمة ، ويمكن أيضًا اعتبارها عقدًا مترابطة. لا يهمني ما إذا كان نوعًا ، أو مؤشرًا لنوع ، أو تضمين - فأنا أهتم فقط بالعلاقات. يعتبر التضمين مفهومًا مثيرًا للاهتمام بشكل خاص ، وهو مناسب بشكل خاص للحالات التي يتم فيها إخفاء هياكل وأساليب النوع (على سبيل المثال ، تنتمي هياكل وطرق الكتابة إلى حزم أخرى) ، لذا فإن الحديث البشري () أكثر منطقية من الكلام البشري. إذا كنت تستخدم الزخارف في نفس الحزمة ، فما زلت أفكر في Speak () كطريقة من النوع الفموي في الخريطة الذهنية ، وليس من النوع البشري ، لأنها مجرد مشكلة نحوية ، وليست مشكلة معرفية.
وظائف وطرق
باختصار ، الطريقة هي دالة يكون وسيطتها الأولى نوعًا ، لذا فإن الاثنين متشابهان جدًا في الواقع. ولكن من وجهة نظر منطقية ، فإن الطريقة دائمًا ما تكون نوعًا (في هذه الحالة يكون النوع هو المستقبل) ، وأرى أنها عقدة متصلة بالنوع. إذا كانت إحدى الطرق تستدعي طريقة أخرى ، فمن المحتمل أن تكون الطريقة الثانية أقرب إلى المتصل الخاص بها (خاصة إذا لم يكن هناك متصلين آخرين ، أو إذا كانت طريقة خاصة).
الشيء نفسه ينطبق على الوظائف - إذا كانت الوظائف تستدعي بعضها البعض ، فإنها تتصل ببعضها البعض ، وأعتقد أن حجم الوظيفة مهم (كلما زاد عدد سطور الوظيفة ، زادت العقد). لا أريد الخوض في هذا ، من الناحية النظرية ، يمكنك تحديد الأنواع (بما في ذلك الأنواع المجهولة) والإغلاق داخل الوظائف ، لكنني لا أفكر في ذلك ، ولا أريد التفكير في الأمر طوال الوقت عند تصفح الشفرة.
من المثير للاهتمام أنه يبدو أنه يشكل بشكل طبيعي ترتيبًا من الأعلى إلى الأسفل - الحزم دائمًا في الأعلى ، ثم الأنواع ووظائف الترتيب الأول ، ثم الطرق وكل شيء متداخل أو متسلسل. ربما يؤثر مفهوم الجاذبية في كل مكان على حدسنا ، لذلك حتى عند التعامل مع شيء مجرد تمامًا مثل الخريطة الذهنية.
واجهه المستخدم
تعد الواجهات مستقلة عن كتل التعليمات البرمجية الأخرى ، فهي تجرد السلوك ، لكنها لا تحدد كيفية تنفيذه. تلخص الواجهة الوظائف المشتركة بين الأشياء التي تبدو غير مرتبطة في نفس المشكلة.
نظرًا لأن الواجهة لا تحدد تنفيذًا ، فإنها تصبح أداة قوية للتعبير عن الواقع في التعليمات البرمجية! يمكن استخدام نفس النوع على نطاق واسع في سياقات مختلفة دون معرفة مسبقة بتنفيذ النوع. لا أستطيع أن أتخيل كيف سيكون الأمر إذا استمر استخدام اللغات حيث يجب على النوع أن يحدد الواجهات التي ينفذها ، وبعد استخدام Go ، من الصعب تصديق أن هناك العديد من اللغات تفعل ذلك.
في Go ، ليست هناك حاجة لإنشاء واجهة حتى يكون لديك نوعان على الأقل من التجريد ، فلا معنى للقيام بذلك. بالنسبة لي ، تشبه الواجهة سحابة حول عقدة نوع تقرب عقدتين من بعضهما البعض لتكوين مجموعة. تجعل الواجهات الخرائط المكانية أكثر مرونة لأن كل نوع يمكنه تنفيذ العديد من الواجهات المستخدمة في الكود ، وأنا مهتم أكثر بتمثيل ما تعنيه الواجهة ، وكيف تقوم الأنواع الأخرى بتنفيذها.
اسم
كما ذكرنا سابقًا ، فإن الأسماء مهمة جدًا في بناء الخريطة الذهنية ، والأسماء تنقل معاني كثيرة. حسب الاصطلاح ، عادةً ما تشير الأسماء الخاصة مثل NewFoo () إلى المُنشئين ، لذلك أعتقد أنها أقرب إلى عقدة النوع. زوج من الأسماء المرتبطين معنويًا ، مثل Start / Stop و Push / Pop هما أقرب ، ولهما نفس البادئة أو اللاحقة ، مثل LightTheme / DarkTheme و ServerTCP / ServerUDP.
هذه مجرد أمثلة قليلة على "القواعد". ليس لدي نظرة عامة كاملة ، ولكن يجب أن تحصل على فكرة عامة عما أفكر فيه.
نظرة عامة على الأداة
هذا ما أحاول القيام به - اقرأ كود Go وقم بتحليله ، ثم أنشئ خريطة ثلاثية الأبعاد للعلاقات المكانية لمفاهيم الكود الرئيسية ، أقرب ما يمكن إلى طريقة تفكير الدماغ. في الحالات التي لا يمكن فيها تقسيم الكود إلى عقد مرئية ، يتم عرض نص الوظيفة مباشرة بحيث يمكن قراءة النص والجزء العملي لبناء الخريطة. على أقل تقدير ، يسمح لي التصور ثلاثي الأبعاد برؤية العلاقات وهيكل الكود والكيانات والتجريدات التي يمثلها على الفور ، وما إلى ذلك. لا مزيد من التمرير ذو العيون الحمراء خلال نصف ساعة من التعليمات البرمجية ، فقط اترك الكمبيوتر يقوم بالعمل القذر ، وتبسيط رسم الخرائط الذهنية ، وإجراء الاتصالات ، وأكثر من ذلك.
يمكن تشغيله في متصفح والوصول إلى الخادم المحلي لقراءة نظام الملفات.
حاليًا أحقق 20 فقط من الوظائف المتوقعة. أثناء عملية التنفيذ ، واصلت البحث في ذهني ووجدت الكثير من الأشياء التي لم تكن واضحة ، ووضعتها جميعًا في قائمة المهام الخاصة بي. على سبيل المثال ، أدركت أنني بحاجة لعرض اتصالات مختلفة بمستويات تكبير مختلفة. عند النظر إلى النظرة العامة على الحزمة ، فأنا أهتم فقط بنوع واحد من الاتصال ، ولكن عند قراءة رمز الوظيفة ، لا أهتم بالأجزاء الأخرى ، ولكني أهتم أكثر بخصائص الاتصال الخارج من الوظيفة.
فيما يلي بعض المعاينات المبكرة (لحفظ حركة المرور ، تكون لقطات الشاشة صغيرة جدًا ومعدل عرض الإطارات منخفضًا):
1. الصفحة الرئيسية والحاوية / قائمة الحزمة stdlib:
2. تصفح حزمة Go الأكبر - github.com/divan/expvarmon:
3. تصور نفسك:
4. تصور تبعيات الحزمة. يتطلب استخدام النص للإضافة أيضًا سطرًا واحدًا فقط من الاستيراد ، سواء كانت حزمة صغيرة مثل اللوحة اليسرى ، أو عملاقًا من 200 ألف سطر من التعليمات البرمجية. يمكنك غريزيًا التفكير مليًا بالتخيل و "الشعور" على الفور بثقل خط الاستيراد هذا.
خوارزمية التخطيط
لقد استخدمت طريقة تخطيط القوة هنا ، وترتيب العقد في مساحة ثلاثية الأبعاد ، ثم حساب علاقة القوة بينهما بشكل متكرر حتى يصل النظام إلى حالة طاقة دنيا ثابتة. من المهم استخدام الطريقة المادية لأنها تتبع التخطيط البديهي.
ولكن من الجدير بالذكر أن معظم خوارزميات تخطيط القوة تسعى جاهدة لإنتاج رسومات أكثر جمالًا. لكن هدفي هو عكس ذلك تمامًا - أريد فقط إنتاج تنسيقات جميلة من أجل كود جيد ، وتنسيقات قبيحة للتعليمات البرمجية السيئة.
الأسباب بسيطة: أولاً ، الفكرة في رأسي هي هكذا ، أنا فقط أتبع أفكاري - الشفرة السيئة فوضوية في العقل (لهذا السبب يصعب فهم الكود المفرط التعقيد) ؛ ثانيًا ، أضع تصورًا لهذا الموقف عن قصد. بهذه الطريقة لا تحتاج إلى تعلم قواعد مثل "الذاكرة قصيرة المدى لا تستطيع تذكر أكثر من 7 أشياء ، لذا اجعل التجريدات صغيرة قدر الإمكان" ، فقط دع التخيل يعطي إحساسًا بديهيًا.
يبين
فيما يلي بعض التعليمات البسيطة.
التقدم الحالي
المشروع بالكامل عبارة عن تجربة في أوقات فراغي ، ولا يزال في بدايته ، وليس له حتى اسم (أسميه "codevis" داخليًا ، مما يعني تصور الكود). تعني التجربة أنه من الممكن تمامًا أن تفشل لعدة أسباب ، ولكن ما يهم هو ما تعلمته على طول الطريق. أنا أستخدم الكثير من الافتراضات الذاتية ، والعديد من الأفكار التي لم أشاركها أبدًا مع الآخرين ، لذلك قد يكون للآخرين آراء مختلفة تمامًا. لكن لا يهم إذا كانت هذه الأفكار تخصني فقط.
هدفي الآن هو تحويلها إلى حالة من التزويد الذاتي واستخدام الأداة لتحليل نفسي. سأقوم بتجربة كليهما - تحرير الكود مباشرة في المتصفح ، والتواصل مع محرر في نافذة أخرى عبر WebSocket.
إحدى الصعوبات الرئيسية التي واجهتها كانت البرمجة ثلاثية الأبعاد ، والتي ليس لدي أي خبرة بها على الإطلاق. إنه عام 2019 ، ولا يزال من الصعب العثور على طريقة لرسم نص بكفاءة أو بضعة آلاف من الأسطر من التعليمات البرمجية في مساحة ثلاثية الأبعاد دون الحاجة إلى استخدام وحدة المعالجة المركزية بشكل مكثف ، ولا توجد طريقة لتحسينها مع الحفاظ على الكود قابلاً للقراءة. علاوة على ذلك ، فقد قضيت الكثير من الوقت في الفيزياء ، مثل ضبط معاملات القوة بين العقد ، وما إلى ذلك. هذه مجرد تقنية سوداء. ما يذهلني هو أن أدمغتنا سيئة للغاية في التعامل مع المواقف المادية التي تختلف عن العالم الحقيقي - تغيير بسيط يمكن أن يفسد كل شيء ، بالإضافة إلى النظر في الرسوم البيانية الكبيرة والصغيرة ، يصبح الأمر أكثر تعقيدًا.
حتى في هذه المرحلة المبكرة الآن ، أنا سعيد جدًا بالنتائج. من الملهم جدًا العثور على مشروع وفتحه بأداة لمعرفة هيكله على الفور ، واستخدام مفتاح wsad لتصفح الكود ، تمامًا مثل لعب Quake. على الأقل ، أشعر أنني أسير في الاتجاه الصحيح.
لا يمكن أن تكون الأداة مفتوحة المصدر حتى الآن ، لكنها مجرد مسألة وقت من قبل - طالما أنني متأكد من أنها تستطيع التعامل مع الحالة الأساسية بثبات ، فستكون مفتوحة المصدر.
مستقبل
أفكر أيضًا في التخلص من النوافذ والشاشات تمامًا في المستقبل واستخدام تمثيلات الأكواد ثلاثية الأبعاد في بيئات الواقع المعزز. أعطاني العرض التوضيحي الأخير لفريق Hololens 2 الأمل في أنني لا أعتقد أن وقت قتل الشاشة بعيد جدًا (أي ، مع دقة عالية بما فيه الكفاية ، يمكنك حتى عرض أي شيء مباشرة على شبكية العين ، لذلك ليست هناك حاجة للفحص) ، وأسعار NReal المعلنة مؤخرًا تظهر أن السوق ينمو وأن أسعار أجهزة AR آخذة في الانخفاض.
أود أن أكون قادرًا على "الدخول إلى" الكود الذي أهتم به ، أو تقريبه يدويًا. من المؤسف أن البرمجة قيدتني وأنت على كرسي. لذلك ، قد تتمكن البرمجة المرئية من إجراء بعض التغييرات.
لخص
تمت صياغة مصطلح "أزمة البرمجيات" لأول مرة في أواخر الستينيات من القرن الماضي في مؤتمر الناتو الأول لمهندسي البرمجيات في جارمش. جعلت الزيادة السريعة في قوة الحوسبة من المستحيل كتابة البرامج في ذلك الوقت ، ولكن لم يتم اختراع طرق جديدة بعد.
الآن لدينا أزمة أخرى ، على ما أعتقد ، حيث يتجاوز حجم الشفرة بكثير قدرات الأدوات التي تتعامل معها. ومع ذلك ، فإن تعقيد المشكلة التي يتعين حلها لم يزداد كثيرًا - لعمل واجهة مع شريط جانبي وثلاثة أزرار بعيدًا عن مقارنته برمز مهام Apollo ، ولكن تعقيد اللغة وحزام الأدوات علي. نمت بعدة أوامر من حيث الحجم ولا تزال تنمو.
أعتقد أن سؤال الشعلة هذا يمكن أن يقدم الكثير من الأفكار. إذا كان بإمكان الأشخاص فقط رؤية الجزء الصغير من الكود الذي يضيئه المحرر ، فمن السهل إعطاء قدر كبير من الأهمية لتأثير الكود الخاص بهم على النتيجة الإجمالية للكود. إذا تمكنت من رؤية التغيير على الفور ، واستخدمت قوة الدماغ في الفضاء للتنقل في الشفرة ، فلن يكون من الطبيعي كتابة كود أبسط وأفضل تنظيمًا فحسب ، بل قد يغير أيضًا عادة فهم البرمجة ، من "استخدام الوضع" "للمجمع" ليصبح "رسم الخريطة" من "رسام الخرائط".
نحن نشكل الأدوات ، والأدوات تشكلنا.
الأصل: https://divan.dev/posts/visual_programming_go/
تمت ترجمة هذه المقالة بواسطة CSDN ، يرجى الإشارة إلى المصدر عند إعادة الطباعة.
