قام أحد المبرمجين العرب بإنشاء لغة برمجة جديدة تسمى إبداع. إنشاء لغات برمجة عربية جديدة هو أمر مرحب به، وقد قلت ذلك كثيراً على مدونتي. مصمم اللغة يفترض أن لغته هي أفضل لغة عربية حالياً، ولكي يفعل ذلك قام بمقارنتها بباقي اللغات العربية الموجودة، ومنها بالطبع كلمات، وبالطبع كانت كلمات خاسرة في مقارنته :)
يقول المؤلف:
(وهو كما ترى كرم من المؤلف؛ إن كلمات بالنسبة له هي أفضل ما في "فترة ما قبل ظهور إبداع" التي يتحدث كأنها بداية عصرٍ جديد من البرمجة)
من حق أي إنسان أن ينتقد كلمات (أنا شخصياً أنتقدها كثيراً) لكن المشكلة أنه قد قدم نقداً عشوائياً غريباً، وقد قرأت نقده هذا سابقاً ولم أردّ، لكن الوضع صار يمكن أن يؤثر على كلمات: إن هذا المبرمج سوف يقوم بتسويق لغته في كل مكان، ومع كل مرة يروج فيها لها سوف يأتي ذكر المقارنة بكلمات (وهو يقدم لها نقداً مطولاً في التوثيق الرسمي للغة)، وإني أخشى أن يصدقه الناس في كلامه ويعرضون عن تجربة لغة كلمات بسبب الانتقادات الغريبة التي يوجهها.
وأخشى أن يظن الناس أن لغته هي ما يمثل حالة لغات البرمجة العربية حالياً (وبالتالي يظنون أنه حال سيء)، مما يؤثر على انتشار فكرة لغات البرمجة العربية عموماً.
ما علينا، هيا نرد على انتقاداته. أريد أولاً أن أنبه لشيء، هو أن كلمات ليست اللغة الوحيدة التي تم انتقادها بهذا الشكل من قبل مصمم "إبداع"، بل إنه قد قدم نفس المعاملة للغات مثل سي شارب أو بايثون أو جافا أو...أو...، وفي الواقع حظ كلمات كان أفضل من كل هؤلاء. أنظر مثلاً كيف يتكلم عن خاصية interfaces الموجودة في لغات مثل جافا أو سي شارب:
وهكذا نجده يتحدث عن إمكانيات مثل struct, union, pointer, delegate في لغات ++C ,و #C وجافا وكلها في نظره خدعة أو فقاعة أو تفاهة أو مناورة تسويقية، ويبدو أن الكاتب يخلط بين عدم معرفته لأسباب وجود الإمكانية وبين عدم ضرورة وجودها أصلاً.
مرة أخرى: ما علينا. هيا نرى نقده للغة كلمات إذاً...
يقول الكاتب:
هي من اللغات ذات التنويع المتغير ،dynamically typed و هذا النوع لا يصلح لكتابة البرامج التي تحتا ج إلي سرعات فائقة في التنفيذ، و كذلك ُيساعد في الوقوع فللي أخطاء التكويد المنطقية لأن اللغة لا تقيد المتغير بنوع بيانات معيَن.
بدايةً الكاتب يمزج بين العيوب والأذواق - هناك لغات كثيرة جداً ناجحة وفي نفس الوقت dynamically typed مثل لغة Python أو JavaScript. هذا ليس "عيباً" في كلمات إلا بقدر ما هو عيب في بايثون: أنها لا تلائم احتياجات معينة أو أنواع معينة من التطبيقات وليس عيباً مطلقاً.
عموماً أنا أنوي على المدى الطويل تقديم static type checking في لغة كلمات. لماذا لم أصنعه حالياً؟ لأن الـtype systems صعبة!
إضافة الـgenerics ليست أمراً سهلاً، وكذلك الـtype variance. وهناك أخطاء في هذه الأمور وقع فيها مصممو لغة الجافا نفسها ولابد من التعامل مع هذه الأشياء بحذر.
(طبعاً هي أمور لا تؤرق كاتب لغة إبداع لأنه قدم type system بسيطة جداً في لغته).
ثم يقول:
اللغة تحتوي علي مكونين في غاية التشابه هما: الإجراء، الدالة. و كان يجب ألا تضم اللغة مكونين متشابهين كهذين علي الإطلاق؛ حيث أن هذا لا داعي له منطقياً، بل و يسبب تشابهُّما الشديد إلي البلبلة عند المبتدئين.
يا لثقته! أنظر كيف يستخدم كلمات قوية مثل "على الإطلاق"، "لا داعي منطقياً"، بينما هو مرة أخرى لا يقدم سوى رأياً شخصياً. هل جاء بمبتدئين وعلمهم البرمجة بكلمات، ثم رأى البلبلة؟ هل أجرى هذه التجارب بمعايير علمية؟ لقد جعلتُ الإجراءات بهذه الطريقة كمحاولة مني لتسهيل تعلم اللغة بإعطاء أسماء مختلفة لمفاهيم مختلفة؛ لكني لم أدّع "هكذا" أن هذا هو المنطقي، بل قلت أنها تجربة وأن تدريب الأطفال وملاحظتهم هو الذي سيخبرنا بالنتيجة.
ثم يقول:
اللغة تحتوي علي مكوني: المصفوفات arrays، القواميس dicts. و كان بالإمكان ضم هذين المكونين في مكونٍ واحد، و هذا سيسهل علي المبتدئين كثيراً لأنه يضم المكونات المتشابهة التكوين و الوظيفة في مكونٍ واحدٍ أشمل
هل من عيوب اللغة أنها لم تفعل ما "كان بالإمكان"؟ هناك أشياء كثيرة ممكنة، ومصمم اللغة يختار ما ينفذه منها. عموماً معظم اللغات تفصل بين الإمكانيتين ماعدا بعض اللغات مثل Lua توحّد بينهما كما يريد. ولو نظرت للأمر من ناحية algorithmic complexity أو من ناحية الـperformance بشكل عام لوجدت مميزات للفصل بينهما.
ثم يقول (قمت بتجميع بعض العيوب لتسريع الأمر):
الدوال و الإجراءات في كلمات ضعيفة البنية؛ فهي تعيد خرجاً واحداً فقط، ولا يمكن إعطاء قيمٍ ابتدائيةٍ لمدخلات الدالة أو الإجراء.
..الفصائل في كلمات ثرثارة؛ فلكي تُعَّرِّف محتويات فصيلةٍ ما فيجب عليك كتابة كلامٍ كثير.
كلمات مصنوعة لتعليم الأطفال البرمجة، لذلك قمت بتبسيط الsemantics والsyntax، وتكرار بعض التركيبات لتذكير المبرمج بفائدتها. مرة أخرى مسألة آراء شخصية، ومسألة ملاءمة الأداة للهدف.
تحتوي كلمات علي أوامر "علامة" و "اذهب إلى"، و اللذين يكافئان "Goto"
وما المشكلة؟ لو تحدثت عن الناحية التعليمية فمصمم لغة SmallBasic من مايكروسوفت يدافع عن goto (المصدر هنا)، ومن الناحية الاحترافية فهذا الأمر مستخدم أحياناً في Linux Kernel.
تعبير الحلقات التكرارية ضعيفٌ للغاية، حيث لا يتيح تغيير مقدار الخطوة في العملية إلا بقيمة زيادةٍ مقدارها 1 (و قد نبه م. محمد سامي إلي أنه ينوي تدارك هذه الجزئية في الإصدارات القادمة بإذن الله عز و جل)
أتمنى أن يحدث الكاتب معلوماته، لأن هذه الإمكانية قد تم تداركها بالفعل منذ أشهر.
المكتبة حتي الآن مبنيةٌ داخل المفسر نفسه، و ليست قائمةً بذاتها و ليست مكتوبةً بلغة كلمات نفسها بل بلغة الـ++C مع مكتبة الـQT. لا يوجد مترجمٌ قويٌ للغة حتي الآن، و كل ما يوجد هو مفسرٌ يتيح لنا استخدام بعض مكونات مكتبة الـQT،
ما المشكلة في كون اللغة مفسرة لا مترجمة؟ هناك لغات من أنجح اللغات في العالم ومفسرة. أما فكرة أنه لا يمكن سوى استخدام مكونات Qt فهو أيضاً غير صحيح (ربما تكون معلومات الكاتب قديمة). كلمات يوجد بها إمكانية FFI التي تتيح استدعاء إجراءات مكتوبة بالسي من مكتبات DLL. وهنا نراها تنادي دوالاً من مكتبات لينكس ومن مكتبات Win32 API.
الشيء الوحيد الذي ينقص هو إمكانية تنفيذ برامج كلمات بدون الحاجة إلى بيئة تطوير كلمات، وهو أيضاً شيء قد أضفته لكنه لا يعمل حالياً بسبب بعض الأخطاء، وأتمنى أن يأتي الدور لإكماله. [تحديث: ثم إعادة تشغيل خاصية عمل الملفات التنفيذية في كلمات منذ إصدارة يناير 2013]
لا يمكن كتابة أوامرٍ بلغة التجميع assembly في برنامج كلمات
إني أتعجب من بعض الأشياء التي يراها صاحب النقد عيوباً. بحسب علمي لا توجد لغات بها هذه الإمكانية إلا لغات قليلة جداً مثل Delphi, C ولغة التجميع نفسها. ولكن انتظر! إن صاحب المقال يذكر سبب افتراضه أن هذا عيباً:
...و هذا يجعلها غير قادرةٍ علي: إنتاج مكتبتها باستخدامها هي نفسها.
كلام خطأ؛ راجع إمكانية FFI
....إنتاج برامجٍ تعمل علي المتحكمات الميكروئية microcontrollers
في تلك الحالة استخدم سي أو لغة التجميع
...كتابة البرمجيات الأخري التي نحتاج فيها إلي التعامل مع الذاكرة مباشرةً، مثل، أنظمة التشغيل، المترجمات compilers، المفسرات interpreters.
عجيب أن يأتي هذا من مبرمج يرفض فكرة الـpointers. عموماً يمكن كتابة مترجمات، مفسرات، بلغات خالية من إمكانية لغة التجميع، مثلاً مترجم لغة سي شارب هو نفسه مكتوب بالسي شارب، ومترجم الجافا مكتوب بالجافا، وهناك مترجمات ومفسرات كثيرة مكتوبة بالبايثون.
أيضاً هناك نظم تشغيل مكتوبة بالجافا والسي شارب. كيف تصرف كاتبوها؟ غالباً ينظرون إلى ما يحتاج للكتابة بلغة التجميع ويضعونه في مكتبة خارجة ثم يقومون باستدعائه من البرنامج الأصلي.
اللغة لم تستقر في تصميمها بعد، و لم توضع لها خطةٌ توضح حجمها النهائي المتوقع حتي الآن، ونحن نري بالفعل أن اللغة يزيد حجمها يوماً بعد يوم.
هناك نوع من "خارطة الطريق" قد كتبته لكلمات (وهو هنا لمن يريد الاطلاع عليه)، لكني أشعر أن الكاتب لديه حساسية من موضوع ازدياد حجم اللغات. حتى أنه يعيب على لغة سي شارب أن حجمها يزداد في كل إصدارة.
هناك بالفعل من يريد أن يحافظ على لغته صغيرة وminimalist وأنا أتفهم مزايا هذا الموضوع (مثلا لغة Google Go تفعل هذا)، لكن يبدو أن الكاتب يرى النمو والتطور عيباً شاملاً في أي لغة.
اللغات مثل سي شارب تتطور لأن عالم البرمجة يتغير: سي شارب صار فيها إمكانيات functional programming حين بدأ نجم البرمجة المتوازية يعلو، وإمكانية Linq ظهرت لتسهيل التعامل مع البيانات المتنوعة في البرامج الكبيرة (ولأسباب أخرى)، وإمكانية generators ظهرت لتبسط أشياءً كانت من قبل معقدة، وإمكانية async/await ظهرت مرة أخرى من أجل البرمجة المتوازية.
سي شارب لغة معقدة لأنها مصنوعة لحل مشاكل معقدة.هل كان يمكن أن تكون أبسط؟ ربما. لكن لا نستطيع أن نقول أن تطورها المستمر هو عيب خطير فيها لابد أن يتوقف.
الوحدات في كلمات تتيح لنا إنشاء إجراءاتٍ و دوالٍ حرة (أي لا يلزم أن تكون مكتوبةً في فصيلةٍ ما)، و هو ما يجعلنا نعاني من مساوئ نموذج البرمجة الإجرائية في المشاريع الكبيرة، و هذه الصفة تناقض مبدأ الأمن الذي نريده في لغة البرمجة القوية.
يبدو أن الكاتب قد غير رأيه في هذا الموضوع لأن هذه الإمكانية (بحسب ما فهمت) موجوده في لغته أيضاً، لكنه لم يحذف هذا الجزء من نقد كلمات وأرجو أن يحدّث ما كتب.
الوصول إلي مكونات الفصيلة غير مُوَحَّد الشكل، فنحن نصل إلي المتغير الداخلي للكائن عن طريق كتابة اسمه ثم كتابة اسم الكائن بعده، أما الإجراءات و الدوال فيجب أن يكتب اسم الكائن أولاً، ثم نتبعه بعلامة : ثم اسم الإجراء أو الدالة.
الكاتب يتحدث عن إمكانية أن أقول
س = سيارة جديد
لون سقف س = "أزرق"
ويريد بدلاً من ذلك أن تكون:
س_سقف_لون = "أزرق"
...وذلك لكي يكون هناك توافق بين field access و method call.
أنا اخترت أن تكون الكود طبيعية أكثر وأشبه باللغة العادية.
ليس فيها تعبيرٌ لمعالجة الاستثناءات exception handling.
هذه الإمكانية مؤجلة حتى أجد طريقة لصنعها بشكل أفضل (وليس مجرد محاكاه لما يحدث في لغات موجودة)، لأني أرى شكلها الحالي معقداً.
لا تحتوي علي مكونٍ هامٍ للغاية هو التعدادات enumerations
ماشي. ولا لغات كثيرة أخرى.
لا تحتوي علي فكرة ال ) delegatingالموجود في لغات مثل الل#.(C
ممم...كلمات حالياً (في أحدث إصداراتها) بها فكرة first class functions وهي مشابهة في الأهداف لما صنعت من أجله فكرة delegates. ربما يمكن الآن في كلمات إضافة الـdelegates في مكتبة.
نلاحظ أن الكاتب قد رفض فكرة الـdelegates كما هي في سي شارب ولم يضفها إلى لغته، لكنه قال أن لديه إمكانية أخرى في لغته هي ما يسميه "الإجراء الحر" تعوض النقص.
لست متأكداً أنني قد فهمت مقصده، لكن الإجراءات الحرة لا تقوم بدور الdelegates!
الكاتب يركز على جزء أن الـdelegate تسمح باستدعاء أكثر من إجراء مرة واحدة؛ لكن ليس هذا الاستخدام الأساسي لها: الاستخدام الأساسي هو فكرة تخزين إجراء في متغير أو تمريره لإجراء آخر. هل يمكن صنع هذا في لغة إبداع؟ لا أعتقد.
كما قلت، توجد في لغة إبداع بعض الأفكار الجيدة، وربما تتطور مع الوقت وتصير لغة قوية، لأ أريد أن يكون مقالي هذا دافعاً للكاتب (أو لأي مبرمج عربي آخر) أن يترك المحاولة لعمل لغات برمجة عربية.
لكني لا أحب أسلوبه في تحطيم اللغات الأخرى بدون خلفية علمية وايضاً بدون معرفة لأسباب القرارات المتخذة في كل لغة. ولا أحب الثقة الغريبة في أسلوبه حيث كل كلامه "منطقي" أو "بالتأكيد" بينما الأمر لا يخرج عن الآراء الشخصية.
وقد ابتعدت شخصياً عن الهجوم على أية لغة برمجة عربية أخرى مفضلاً أن أجعل كلمات تتحدث عن نفسها، ولكن هذا المقال هو حالة خاصة. هذا نقد غير منصف للغة كلمات يوزع رسمياً مع لغة برمجة عربية أخرى!
وعموما اشعر بالضيق من كتابة هذا المقال..ومازلت أفكر هل أبقي عليه أم أخفيه من المدونة..
يقول المؤلف:
بداية: ُتعد لغة كلمات أرقي لغات البرمجة العربية في فترة ما قبل ظهور إبداع علي الطلق، فلها الميزات التالية...
(وهو كما ترى كرم من المؤلف؛ إن كلمات بالنسبة له هي أفضل ما في "فترة ما قبل ظهور إبداع" التي يتحدث كأنها بداية عصرٍ جديد من البرمجة)
من حق أي إنسان أن ينتقد كلمات (أنا شخصياً أنتقدها كثيراً) لكن المشكلة أنه قد قدم نقداً عشوائياً غريباً، وقد قرأت نقده هذا سابقاً ولم أردّ، لكن الوضع صار يمكن أن يؤثر على كلمات: إن هذا المبرمج سوف يقوم بتسويق لغته في كل مكان، ومع كل مرة يروج فيها لها سوف يأتي ذكر المقارنة بكلمات (وهو يقدم لها نقداً مطولاً في التوثيق الرسمي للغة)، وإني أخشى أن يصدقه الناس في كلامه ويعرضون عن تجربة لغة كلمات بسبب الانتقادات الغريبة التي يوجهها.
وأخشى أن يظن الناس أن لغته هي ما يمثل حالة لغات البرمجة العربية حالياً (وبالتالي يظنون أنه حال سيء)، مما يؤثر على انتشار فكرة لغات البرمجة العربية عموماً.
ما علينا، هيا نرد على انتقاداته. أريد أولاً أن أنبه لشيء، هو أن كلمات ليست اللغة الوحيدة التي تم انتقادها بهذا الشكل من قبل مصمم "إبداع"، بل إنه قد قدم نفس المعاملة للغات مثل سي شارب أو بايثون أو جافا أو...أو...، وفي الواقع حظ كلمات كان أفضل من كل هؤلاء. أنظر مثلاً كيف يتكلم عن خاصية interfaces الموجودة في لغات مثل جافا أو سي شارب:
...إذاً يتَضح لنا أن هذه الميزة ما هى إلا فقاعة فارغة ُتقال و لا حقيقة لها، و السبب الوحيد لقولها هو دعم السبب الحقيقى لاستخدام الواجهات، و جعل الأسباب كثيرة تملأ ناظرى القارئ لتقِنعه بيسر بأهميتها، فى حين أنه ليس هناك سبب حقيقى َيستحق النظر إلا واحداً أو اثنين على الأكثر...
وهكذا نجده يتحدث عن إمكانيات مثل struct, union, pointer, delegate في لغات ++C ,و #C وجافا وكلها في نظره خدعة أو فقاعة أو تفاهة أو مناورة تسويقية، ويبدو أن الكاتب يخلط بين عدم معرفته لأسباب وجود الإمكانية وبين عدم ضرورة وجودها أصلاً.
مرة أخرى: ما علينا. هيا نرى نقده للغة كلمات إذاً...
يقول الكاتب:
هي من اللغات ذات التنويع المتغير ،dynamically typed و هذا النوع لا يصلح لكتابة البرامج التي تحتا ج إلي سرعات فائقة في التنفيذ، و كذلك ُيساعد في الوقوع فللي أخطاء التكويد المنطقية لأن اللغة لا تقيد المتغير بنوع بيانات معيَن.
بدايةً الكاتب يمزج بين العيوب والأذواق - هناك لغات كثيرة جداً ناجحة وفي نفس الوقت dynamically typed مثل لغة Python أو JavaScript. هذا ليس "عيباً" في كلمات إلا بقدر ما هو عيب في بايثون: أنها لا تلائم احتياجات معينة أو أنواع معينة من التطبيقات وليس عيباً مطلقاً.
عموماً أنا أنوي على المدى الطويل تقديم static type checking في لغة كلمات. لماذا لم أصنعه حالياً؟ لأن الـtype systems صعبة!
إضافة الـgenerics ليست أمراً سهلاً، وكذلك الـtype variance. وهناك أخطاء في هذه الأمور وقع فيها مصممو لغة الجافا نفسها ولابد من التعامل مع هذه الأشياء بحذر.
(طبعاً هي أمور لا تؤرق كاتب لغة إبداع لأنه قدم type system بسيطة جداً في لغته).
ثم يقول:
اللغة تحتوي علي مكونين في غاية التشابه هما: الإجراء، الدالة. و كان يجب ألا تضم اللغة مكونين متشابهين كهذين علي الإطلاق؛ حيث أن هذا لا داعي له منطقياً، بل و يسبب تشابهُّما الشديد إلي البلبلة عند المبتدئين.
يا لثقته! أنظر كيف يستخدم كلمات قوية مثل "على الإطلاق"، "لا داعي منطقياً"، بينما هو مرة أخرى لا يقدم سوى رأياً شخصياً. هل جاء بمبتدئين وعلمهم البرمجة بكلمات، ثم رأى البلبلة؟ هل أجرى هذه التجارب بمعايير علمية؟ لقد جعلتُ الإجراءات بهذه الطريقة كمحاولة مني لتسهيل تعلم اللغة بإعطاء أسماء مختلفة لمفاهيم مختلفة؛ لكني لم أدّع "هكذا" أن هذا هو المنطقي، بل قلت أنها تجربة وأن تدريب الأطفال وملاحظتهم هو الذي سيخبرنا بالنتيجة.
ثم يقول:
اللغة تحتوي علي مكوني: المصفوفات arrays، القواميس dicts. و كان بالإمكان ضم هذين المكونين في مكونٍ واحد، و هذا سيسهل علي المبتدئين كثيراً لأنه يضم المكونات المتشابهة التكوين و الوظيفة في مكونٍ واحدٍ أشمل
هل من عيوب اللغة أنها لم تفعل ما "كان بالإمكان"؟ هناك أشياء كثيرة ممكنة، ومصمم اللغة يختار ما ينفذه منها. عموماً معظم اللغات تفصل بين الإمكانيتين ماعدا بعض اللغات مثل Lua توحّد بينهما كما يريد. ولو نظرت للأمر من ناحية algorithmic complexity أو من ناحية الـperformance بشكل عام لوجدت مميزات للفصل بينهما.
ثم يقول (قمت بتجميع بعض العيوب لتسريع الأمر):
الدوال و الإجراءات في كلمات ضعيفة البنية؛ فهي تعيد خرجاً واحداً فقط، ولا يمكن إعطاء قيمٍ ابتدائيةٍ لمدخلات الدالة أو الإجراء.
..الفصائل في كلمات ثرثارة؛ فلكي تُعَّرِّف محتويات فصيلةٍ ما فيجب عليك كتابة كلامٍ كثير.
كلمات مصنوعة لتعليم الأطفال البرمجة، لذلك قمت بتبسيط الsemantics والsyntax، وتكرار بعض التركيبات لتذكير المبرمج بفائدتها. مرة أخرى مسألة آراء شخصية، ومسألة ملاءمة الأداة للهدف.
تحتوي كلمات علي أوامر "علامة" و "اذهب إلى"، و اللذين يكافئان "Goto"
وما المشكلة؟ لو تحدثت عن الناحية التعليمية فمصمم لغة SmallBasic من مايكروسوفت يدافع عن goto (المصدر هنا)، ومن الناحية الاحترافية فهذا الأمر مستخدم أحياناً في Linux Kernel.
تعبير الحلقات التكرارية ضعيفٌ للغاية، حيث لا يتيح تغيير مقدار الخطوة في العملية إلا بقيمة زيادةٍ مقدارها 1 (و قد نبه م. محمد سامي إلي أنه ينوي تدارك هذه الجزئية في الإصدارات القادمة بإذن الله عز و جل)
أتمنى أن يحدث الكاتب معلوماته، لأن هذه الإمكانية قد تم تداركها بالفعل منذ أشهر.
المكتبة حتي الآن مبنيةٌ داخل المفسر نفسه، و ليست قائمةً بذاتها و ليست مكتوبةً بلغة كلمات نفسها بل بلغة الـ++C مع مكتبة الـQT. لا يوجد مترجمٌ قويٌ للغة حتي الآن، و كل ما يوجد هو مفسرٌ يتيح لنا استخدام بعض مكونات مكتبة الـQT،
ما المشكلة في كون اللغة مفسرة لا مترجمة؟ هناك لغات من أنجح اللغات في العالم ومفسرة. أما فكرة أنه لا يمكن سوى استخدام مكونات Qt فهو أيضاً غير صحيح (ربما تكون معلومات الكاتب قديمة). كلمات يوجد بها إمكانية FFI التي تتيح استدعاء إجراءات مكتوبة بالسي من مكتبات DLL. وهنا نراها تنادي دوالاً من مكتبات لينكس ومن مكتبات Win32 API.
الشيء الوحيد الذي ينقص هو إمكانية تنفيذ برامج كلمات بدون الحاجة إلى بيئة تطوير كلمات، وهو أيضاً شيء قد أضفته لكنه لا يعمل حالياً بسبب بعض الأخطاء، وأتمنى أن يأتي الدور لإكماله. [تحديث: ثم إعادة تشغيل خاصية عمل الملفات التنفيذية في كلمات منذ إصدارة يناير 2013]
لا يمكن كتابة أوامرٍ بلغة التجميع assembly في برنامج كلمات
إني أتعجب من بعض الأشياء التي يراها صاحب النقد عيوباً. بحسب علمي لا توجد لغات بها هذه الإمكانية إلا لغات قليلة جداً مثل Delphi, C ولغة التجميع نفسها. ولكن انتظر! إن صاحب المقال يذكر سبب افتراضه أن هذا عيباً:
...و هذا يجعلها غير قادرةٍ علي: إنتاج مكتبتها باستخدامها هي نفسها.
كلام خطأ؛ راجع إمكانية FFI
....إنتاج برامجٍ تعمل علي المتحكمات الميكروئية microcontrollers
في تلك الحالة استخدم سي أو لغة التجميع
...كتابة البرمجيات الأخري التي نحتاج فيها إلي التعامل مع الذاكرة مباشرةً، مثل، أنظمة التشغيل، المترجمات compilers، المفسرات interpreters.
عجيب أن يأتي هذا من مبرمج يرفض فكرة الـpointers. عموماً يمكن كتابة مترجمات، مفسرات، بلغات خالية من إمكانية لغة التجميع، مثلاً مترجم لغة سي شارب هو نفسه مكتوب بالسي شارب، ومترجم الجافا مكتوب بالجافا، وهناك مترجمات ومفسرات كثيرة مكتوبة بالبايثون.
أيضاً هناك نظم تشغيل مكتوبة بالجافا والسي شارب. كيف تصرف كاتبوها؟ غالباً ينظرون إلى ما يحتاج للكتابة بلغة التجميع ويضعونه في مكتبة خارجة ثم يقومون باستدعائه من البرنامج الأصلي.
اللغة لم تستقر في تصميمها بعد، و لم توضع لها خطةٌ توضح حجمها النهائي المتوقع حتي الآن، ونحن نري بالفعل أن اللغة يزيد حجمها يوماً بعد يوم.
هناك نوع من "خارطة الطريق" قد كتبته لكلمات (وهو هنا لمن يريد الاطلاع عليه)، لكني أشعر أن الكاتب لديه حساسية من موضوع ازدياد حجم اللغات. حتى أنه يعيب على لغة سي شارب أن حجمها يزداد في كل إصدارة.
هناك بالفعل من يريد أن يحافظ على لغته صغيرة وminimalist وأنا أتفهم مزايا هذا الموضوع (مثلا لغة Google Go تفعل هذا)، لكن يبدو أن الكاتب يرى النمو والتطور عيباً شاملاً في أي لغة.
اللغات مثل سي شارب تتطور لأن عالم البرمجة يتغير: سي شارب صار فيها إمكانيات functional programming حين بدأ نجم البرمجة المتوازية يعلو، وإمكانية Linq ظهرت لتسهيل التعامل مع البيانات المتنوعة في البرامج الكبيرة (ولأسباب أخرى)، وإمكانية generators ظهرت لتبسط أشياءً كانت من قبل معقدة، وإمكانية async/await ظهرت مرة أخرى من أجل البرمجة المتوازية.
سي شارب لغة معقدة لأنها مصنوعة لحل مشاكل معقدة.هل كان يمكن أن تكون أبسط؟ ربما. لكن لا نستطيع أن نقول أن تطورها المستمر هو عيب خطير فيها لابد أن يتوقف.
الوحدات في كلمات تتيح لنا إنشاء إجراءاتٍ و دوالٍ حرة (أي لا يلزم أن تكون مكتوبةً في فصيلةٍ ما)، و هو ما يجعلنا نعاني من مساوئ نموذج البرمجة الإجرائية في المشاريع الكبيرة، و هذه الصفة تناقض مبدأ الأمن الذي نريده في لغة البرمجة القوية.
يبدو أن الكاتب قد غير رأيه في هذا الموضوع لأن هذه الإمكانية (بحسب ما فهمت) موجوده في لغته أيضاً، لكنه لم يحذف هذا الجزء من نقد كلمات وأرجو أن يحدّث ما كتب.
الوصول إلي مكونات الفصيلة غير مُوَحَّد الشكل، فنحن نصل إلي المتغير الداخلي للكائن عن طريق كتابة اسمه ثم كتابة اسم الكائن بعده، أما الإجراءات و الدوال فيجب أن يكتب اسم الكائن أولاً، ثم نتبعه بعلامة : ثم اسم الإجراء أو الدالة.
الكاتب يتحدث عن إمكانية أن أقول
س = سيارة جديد
لون سقف س = "أزرق"
ويريد بدلاً من ذلك أن تكون:
س_سقف_لون = "أزرق"
...وذلك لكي يكون هناك توافق بين field access و method call.
أنا اخترت أن تكون الكود طبيعية أكثر وأشبه باللغة العادية.
ليس فيها تعبيرٌ لمعالجة الاستثناءات exception handling.
هذه الإمكانية مؤجلة حتى أجد طريقة لصنعها بشكل أفضل (وليس مجرد محاكاه لما يحدث في لغات موجودة)، لأني أرى شكلها الحالي معقداً.
لا تحتوي علي مكونٍ هامٍ للغاية هو التعدادات enumerations
ماشي. ولا لغات كثيرة أخرى.
لا تحتوي علي فكرة ال ) delegatingالموجود في لغات مثل الل#.(C
ممم...كلمات حالياً (في أحدث إصداراتها) بها فكرة first class functions وهي مشابهة في الأهداف لما صنعت من أجله فكرة delegates. ربما يمكن الآن في كلمات إضافة الـdelegates في مكتبة.
نلاحظ أن الكاتب قد رفض فكرة الـdelegates كما هي في سي شارب ولم يضفها إلى لغته، لكنه قال أن لديه إمكانية أخرى في لغته هي ما يسميه "الإجراء الحر" تعوض النقص.
لست متأكداً أنني قد فهمت مقصده، لكن الإجراءات الحرة لا تقوم بدور الdelegates!
الكاتب يركز على جزء أن الـdelegate تسمح باستدعاء أكثر من إجراء مرة واحدة؛ لكن ليس هذا الاستخدام الأساسي لها: الاستخدام الأساسي هو فكرة تخزين إجراء في متغير أو تمريره لإجراء آخر. هل يمكن صنع هذا في لغة إبداع؟ لا أعتقد.
وأخيراً
كما قلت، توجد في لغة إبداع بعض الأفكار الجيدة، وربما تتطور مع الوقت وتصير لغة قوية، لأ أريد أن يكون مقالي هذا دافعاً للكاتب (أو لأي مبرمج عربي آخر) أن يترك المحاولة لعمل لغات برمجة عربية.
لكني لا أحب أسلوبه في تحطيم اللغات الأخرى بدون خلفية علمية وايضاً بدون معرفة لأسباب القرارات المتخذة في كل لغة. ولا أحب الثقة الغريبة في أسلوبه حيث كل كلامه "منطقي" أو "بالتأكيد" بينما الأمر لا يخرج عن الآراء الشخصية.
وقد ابتعدت شخصياً عن الهجوم على أية لغة برمجة عربية أخرى مفضلاً أن أجعل كلمات تتحدث عن نفسها، ولكن هذا المقال هو حالة خاصة. هذا نقد غير منصف للغة كلمات يوزع رسمياً مع لغة برمجة عربية أخرى!
وعموما اشعر بالضيق من كتابة هذا المقال..ومازلت أفكر هل أبقي عليه أم أخفيه من المدونة..
هناك 3 تعليقات:
السلام عليكم
أنا بالطبع "أحد المبرمجين العرب" :)
بالنسبة للمعلومات القديمة: بالفعل هناك معلوماتٌ اعتمدتُ عليها في نقدي للغة كلمات و وجدتُ بعد ذلك أنها تغيرت، و لكن ألا تتفق معي أنه من المستحيل علي فردٍ واحدٍ أن يُتابِع لغاتٍ كثيرةٍ جداً ليري ما تغير في فترةٍ لا تتعدي الأشهر انقضت بين بدايته في تأليف الكتاب و الإنتهاء منه ؟
بالطبع يلزمني في الإصدارات القادمة أن أغير نقدي بما يتناسب مع الوضع الجديد، لكن الإعذار بحدود القدرة البشرية هو الأصل.
بخصوص رؤيتي لإبداع علي انها بداية عصرٍ جديدٍ من البرمجة فهذا يشبه أن تلوم أخاك علي أنه يري أولاده أفضل الأطفال في الدنيا، و في النهاية الامر يُرَد إلي الدليل و البرهان مع بقاء الآراء الشخصية ذات اعتبار. انظر مثلاً إلي كرهي للغة الـC و انظر إلي حب لينوس تورفالدز لها، و انظر إلي فشلي عمل أي شيءٍ مفيدٍ باستخدامها و انظر إلي قدرة لينوس إلي عمل أي شيءٍ بها، أنا هنا لا أقارن بيني و بين لينوس من حيث الكفاءة؛ فأنا أعلم أنه أعلم مني بمراحل فوقها مراحل، لكني فقط أُوضِّح مبدأ أن ما يروقك قد لا يروقني و من حقي نقده و تقديم أسباب كرهي له، و ما أحبه و أراه الأفضل قد يكون الأفضل لي بالفعل، و لكنه قد لايكون كذلك بالنسبة لك (تحدثتُ سابقاً عن نشأة لينوس و تقبلتُ كثيراً من آرائه الغريبة للغاية مثل كرهه للـdebuggers لأنني أومن بقاعدة التناسب).
أنت تري أن نقدي عشوائي و غريب: بالطبع قد يكون هذا صحيحاً، و نقدك للنقد قد أري فيه الكثير من العشوائية و الغرابة في الرد و هذا أيضاً من حقي.
حدة نقدي لإمكانياتٍ مشهورةٍ في لغات أخري قد يكون أقل من حدة نقد المبرمجين الكبار لها، لو نظرت لما يقوله خبراء الـeiffel عن الوراثة المتعددة و دفاعهم عنها لوجدتهم ينقدون الواجهات interfaces بضراوة و بسخرية، بل و يمتد الأمر لاتهام من اعتمد عليها في لغته إلي أنه قليل الإمكانيات و لذلك لجأ لهذا البديل الفقير، فالأمر عادي و مرده إلي اختلاف وجهات النظر.
كما أنني حينما انتقدتُ الواجهات قدمتُ في إبداع الوراثةَ المتعددة، و بالتالي لم يكن الأمر نظرياً فقط، بل نقدتُ ما لا يعجبني و قدمتُ البديل المناسب له، يمكنك بالطبع نقد هذا البديل و لكن لِمَ تمنعني من نقدي لما لا أحب ؟
ثم انظر لنقد ( Brian Kernighan) في الورقة العلمية المُسمَّاة (Why Pascal Is Not My Favorite Programming Language) للغة الـpascal، بوجهة نظرك الحالية فيجب تمزيقه إرباً لأنه هكذا يُورِد انتقاداتٍ أكثر غرابةً بكثيرٍ جداً من التي أُورِدُها أنا نفسي !
أما عدم معرفتي لأسباب وجود تلك الإمكانيات التي رفضتُها في لغات البرمجة: فقد أوردتُ في كل فصلٍ يتحدث عن مُكوِّنٍ تم رفضه ما وجدتُه من الأسباب التي تُساق لتفسير وجود هذا المُكوِّن، و رددتُ عليها واحداً تلو الآخر، و لولا أني لم أحب ان يصير الكتاب من آلاف الصفحات لربما أطنبتُ و زدت الأشعار أبياتاً، و لكني تعمدتُ الإختصار الشديد و الحديث علي قدر الحاجة اعتماداً علي وجود إبداع نفسها لتفسر البدائل التي أراها لما لا أقبله.
هل التنويع المتغير dynamically typing عيبٌ أم ذوق ؟
كل ذوقٍ قد يُعد عيباً، و كل ذوقٍ قد يُعَد ميزة، و الأمر في النهاية للهدف الذي يضعه الناقد نُصْب عينيه: فهل ينقد اللغة علي أساس أنه يحب اللغات عالية المستوي عامة الأغراض، أم ينقدها علي أساس أنه يحب اللغات التعليمية، و بطبيعة الحال فإن نقدي كان من النوع الأول، و هذا واضحٌ تماماً من مباديء التصميم التي (علي عكس العادة) وضعتها مراراً و تكراراً إما مُختصَرة أو تفصيلية.
أنت تري أن نظام الأنواع في إبداع بسيطٌ جداً: نعم بالفعل، و قد شرحتُ أنه بهذا يمزج بين ميزات التنويع المتغير و ميزات التنويع الثابت. كما أن له ميزاتٍ أخري كتبتها باختصار في نهاية كتاب الرسالة.
في بعض الانتقادات قلتَ أنها وُجدَت في كلمات لملاءمة الهدف و لأنها تعليمية: إذاً لماذا القول بأنني أنقد بعشوائية ؟
مسألة (اذهب إلي) و (علامة) نختلف فيها جداً؛ فأنا أتبني الرأي القائل بأنه من الخطأ جداً وجود هذه المكونات في لغات البرمجة عالية المستوي (بالتالي أستثني لغات التجميع).
الاعتماد علي الـFFI ينسف فكرة شمولية اللغة في نظري؛ فأنا أحلم باللغة القادرة علي إيصالي إلي كل الأماكن (أو معظمها) بحيث لا احتاج لرقعٍ من لغاتٍ أخري.
وجهة نظري ان عدم السماح باكواد التجميع يؤدي إلي عدم القدرة علي بناء مكتبة اللغة بها نفسها يقوم علي رؤية أن اللغة التي تبني مكتبتها بنفسها لا تحتاج لاستدعاء مكتبات لغاتٍ أخري، أُقرُّ انه قد يكون في هذا تعسفاً كبيراً لأنه يهضم الـFFI الكثير من حقها (و انا أعلم مدي الحاجة إليها بطبيعة الحال)، و لكنه يرجع (مرةً أخري) لرأيي في مسألة الشمولية، بالمناسبة: إبداع فيها القدرة علي استخدام لغات التجميع داخلياً بشكلٍ آمنٍ سلس فيما يُسمَّي بـ(الإجراءات المُخصَّصة)، و يمزج بين الإمكانيات عالية المستوي و الإمكانيات الدنيا، و بالتالي يمكن بها كتابة مكتبتها الخاصة بدون استخدام مكتباتٍ مُساندِة (الأمر فيه تفصيلٌ كثير و سيأتي وقته حينما أبني هذه الإمكانية في المُفسِّر بإذن الله تعالي).
إمكانية البرمجة بالنمط الإجرائي توجد في إبداع في حدود الملف الرئيس فقط و المبرمج بها مُجبَرٌ علي استخدام النمط الكائني الصُّرف في بناء المكتبة (باستخدام ملفات الباقات)، و هكذا للا يملك فيالبرامج الكبيرة ان يبني مكتبته علي أساسٍ إجرائي، بينما في البرامج الصغيرة ذات الملف الواحد يمكنه فعل هذا، اما في كلمات فهي توجد في الملفات كلها.
الفرق بين الإجراءات الحرة في إبداع و الـfirst class functions (لا أعرف ترجمةً جيدةً لها) يرجع للاختلاف بين نموذجي التنويع: الثابت و المتغير، يكاد يكون من المستحيل أن تدمج إمكانية الـfirst class functions في لغة تنويعٍ ثابتٍ بدون أن تلجأ لحيلٍ تجعل اللغة كطلاسم السحرة (أو هكذا اظن، لو كان لديك فكرةٌ لمثل هذا الدمج بشكلٍ جيدٍ فسأكون بحقٍ سعيداً جداً بوضعها في إبداع).
الثقة ستبقي بالتأكيد؛ فقد قلتُ في جزء (روح الإبداع) ما نصه:
و فى هذه القضايا قد أُخالِف الكثيرين من أبرز أهل الإختصاص فى آرائهم و قَناعاتهم، و ليس الأمر أننى من مُحبَّى التفرُّد و الغَرابة الذين يفعلون ما يفعلون من أجل لفت الأنظار فقط، بل إننى فَعلتُ ما فَعلتُ عن قناعةٍ حقيقيةٍ وَلَّدها فِىَّ تأملٌ كبيرٌ فى العلم البرمجى و ما أُحِب له أن يصير إليه، و كذا ما آخذه على الواقع الحالى من مَآخِذٍ من الأفضل أن تُزال، و ما أراه فيه من حَسناتٍ حبَّذا لو تُقَوَّى و تُزاد.
و مَرَدُّ الأمر فى النهاية إلى القَناعات الذهنية الذاتية، و ليس هذا المجال من المجالات التى يُمكِننا فيها القول بالخطأ المَحْض و الصواب المَحْض، بل الأمر هنا هو الإجتهاد البشرى الذى يُصِيب صاحبه و يُخطِئ، و ليس لأحدٍ تحجيم آراء أحدٍ أو منعها أو تقييد الحرية فى التَّفَوُّه بها و نَشْرِها ما دام الأمر أولاً و آخِراً جهداً بشرياً خالصاً قابلاً للنقد و الدحض.
فلا يجب لي أن أكرر الأمر نفسه كلما ذكرتُ رأياً من آرائي ما دمتُ قد نوَّهتُ إلي هذا في بداية الأمر، و يكون من مسؤولية القاريء التنبه لهذا.
في النهاية فقد حَسَّنتُ أسلوبي بالفعل منذ آخر تنبيهٍ وُجِّه إليَّ، و الله تعالي يعلم هذا، و قارن بين النسخ القديمة للمقالات قبل تنقيحها علي مدونتي الشخصية و بين شكلها في كتاب الرسالة و ستري أنني وجدتُ الأسلوب بالفعل بحاجةٍ إلي كثيرٍ من التعديل حتي لا يُفهم أنه منهجٌ تصادمي، بينما كان مجرد غفلةٍ تحتاج للتنبيه ليس إلا.
كما أنني ألاحظ لمزاً واضحاً لي في كل فترةٍ بقلة العلم و الحاجة للاستزادة منه، كما أنك لمزتَ إبداع نفسها بأن مستوي لغات البرمجة العربية لو كان نفس مستواها لأصبح سيئاً: ألا يُعتبَر هذا منهجاً تصادمياً للغاية ؟
علي فكرة: أتمني ان تستمر في مثل هذه المقالات الناقدة و المدافِعة، فمن أهداف مشروع (البرمجة بإبداع) صناعة مثل هذه الأجواء العلمية الحامية؛ فهل يمكن لمجتمعٍ لا تُنتقد فيه الآراء العلمية أن يكون حياً بالفعل !
بعيداً عن كل هذا: التعليق علي مدونتك حربٌ ضروس ! كدتُ أموت من الشيخوخة و أنا أُدخِل التعليقات و أكتب تحديات الكابتشا التي أمقتها :)
إرسال تعليق