التاريخ والأشياء الصغيرة

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

وأقوى سلاح في هذه الرحلة هو التاريخ. وهكذا تجدني أقضي الساعات في القراءة عن لغات البرمجة القديمة منذ الستينات وما بعدها.

Algol - Icon -  CLU - Simula - Self - Forth - Logo - CleanSheet - ObjectVision

..بحثاً عن فكرة عبقرية لكن مفقودة.

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

وفي أيام معركة الجمال في الثورة، ابتكر الثوار - وحدهم - طرقاً حربية مشابهة لما كان يفعله الرومان. حائط بشري يمسك دروع طويلة ويزحف بها... Testudo formation

وحين فكرت في تعريب العلوم كنت آخذ "غطسات" في كتب العلوم الرياضية والطبية أيام الحضارة الإسلامية القديمة، لأرى كيف كان يبدو "العلم باللغة العربية"، وإن كان يمكن أن يكون العلم العربي الجديد امتداداً لما سبق وليس علماً مختلفاً تماماً.

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

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

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

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

حاجات مطلوبة عشان تفكر

قبل أن تفكر، تحتاج أن تعرف كيف ترى، وكيف تسأل أسئلة، وكيف تصف.

كيف ترى

أنت لا ترى بعينيك فقط. أنت ترى بعقلك. هذه نقطة بالغة الأهمية. العالم من وجهة نظرك غير العالم من وجهة نظري، وهما يختلفان عن العالم من وجهة نظر القطة في الشارع؛ مع أنه - مادياً - هو نفس العالم.

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

والمفاهيم التي تعرفها هي أعين جديدة ترى بها. في رحلتي في علم لغات البرمجة تعلمت فكرة الـcontinuation. منذ ذلك الوقت وأنا أراه في كل مكان: في أشياء برمجية سابقة، في الحياة عموماً، في أفكار تكنولوجية غير برمجية. شيء شبيه بذلك حين قرأت عن الـmonads.

ونظرية Piaget في التطور المعرفي للأطفال! النظرية تتحدث عن الـconstructivism، منذ أن قرأت عنها وأنا أنظر في كل شيء فأراها..

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

(ليست هذه التدوينة عن نظرية Piaget، تذكر: نحن في جزء "كيف ترى"، أتحدث عن كيف تغير الأفكار في عقلك من نظرتك للعالم. منذ عرفت النظرية وأنا أنظر لكل المجالات الأخرى نظرة بنائية).

وكيف تسأل أسئلة؟

Computers are useless. They can only give you answers.
-- Pablo Picasso

يكاد يكون علم الفلسفة مبني على فكرة "كيف تسأل أسئلة جيدة". المشكلة أن معظم الأذكياء الذين أراهم يهتمون بالأجوبة فقط. الامتحانات؟ المسابقات؟ الinterview؟ إجابة إجابة إجابة! والظريف أنه في كثير من الأحيان يكون اختيار الأسئلة سيء أصلاً...

"إنتاج أفريقيا هو (أ) 8% (ب) 9% (ج) 11% (د) 13% من إنتاج الحديد العالمي".

"What is the difference between x++ and ++x"

"لما بترجع البيت بتعلق هدومك والا بترميها" (هذا سؤال حقيقي أخذته في interview)

هي دي الأسئلة؟؟؟

كان هناك قديماً خمس مسلّمات للهندسة منذ أيام إقليدس، وكان كثير من العلماء الرياضيين يعتبرون المسلّمة الخامسة زائدة (أي يمكن إثباتها من الأربعة السابقين لها، وبالتالي لا داع لاعتبارها مسلّمة بل هي نظرية عادية). وقد حاول العلماء لمئات السنين، علماء الحضارة اليونانية ثم الإسلامية ثم الأوروبية، أن يأتوا بذلك الإثبات ولم يقدروا.

ثم جاء كارل فريدريك جاوس في 1817 وسأل نفسه: ماذا يحدث لو افترضت أن المسلّمة الخامسة ليست بالضرورة صحيحة؟ والتفكير في هذا الأمر دفع بسؤال آخر: ماذا لو اخترعت "هندسة" جديدة بالأربع مسلّمات + خامسة مختلفة عن المعتاد؟

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

أبواب جديدة من العلم، جاءت من السؤال المناسب..

فلنسأل...

• هناك موضة هذه الأيام عند البعض (للأسف) أن يكون حكم الدولة كإدارة شركة..ماذا لو جربنا العكس: أن تدار الشركات بطريقة ديموقراطية كأنها دولة؟
• لماذا يبدو شكل الحروف هكذا: د ، م ، ع ، ف...الخ ؟
• طفلك الذي يحكي لك حكاية تبدو غريبة وعشوائية..ما تسلسل الأفكار الذي جاء بهذه الحكاية؟
• هل يمكن اختراع آلة لطبخ المكرونة؟
• هل نحتاج لكمبيوتر لكي نبرمج؟

وكيف تصف

العلم الحديث مبني على التجربة. كيف تسجل ملاحظات تلك التجربة؟

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

وكيف تصف المجتمع حين تريد تغييراً سياسياً؟ وكيف تصف مشروعك للآخرين؟ وكيف تصف المشكلة التي تريد أن تحلها؟

وكيف يكون شكل برامجنا لو تخلينا عن فكرة "البرنامج في ملفات نحررها بمحرر نصي"؟ وما البدائل لوصف المطلوب من البرنامج؟

كيف تصف الألوان لشخص أعمى؟ وكيف تصف الروائح في فيلم رسوم متحركة؟ وكيف تصف ملمس معين في صورة؟

ملمس في صورة؟ قرأت في طفولتي مقالاً عن قصر الحمراء بغرناطة، يقول أن الزخارف متنوعة ومصنوعة بطريقة كأن العين "تتحسسها"..انظر للصورة واحكم بنفسك:

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

كيف تصف، هذا مهم.

البرمجة، وقوالب الطوب، والحلم المختفي

لماذا أحب الكمبيوتر؟ في الثمانينات وانا في المدرسة رأيت برنامجاً للرسم يعمل على الكمبيوتر المنزلي. لا اعرف نوع الجهاز تحديداً لكن اعتقد أنه BBC Micro. كانت الأجهزة في تلك الفترة متقاربة على أي حال.

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

لقد كانت لحظة فارقة في حياتي. انا اعتبر نفسي إنساناً مبدعاً لكني كسول؛ والآن هناك آلة تقوم بالعمل الممل وتترك لي العمل الإبداعي! هذا يغير أشياء كثيرة. ولهذا أحببت الكمبيوتر.

هل تعرف ما هي إمكانات جهاز BBC Micro؟ إن سرعته هي 2 ميجاهرتز (وليس جيجا). الذاكرة من 32 كيلوبايت، والمعالج 8 بت.

ثم ننظر لهذا النظام (Sketchpad) وهو موضوع رسالة الدكتوراة للباحث Ivan Sutherland في الستينات.

النظام ليس فقط مبهر بالنسبة للفترة التي ظهر فيها، إنه مبهر حتى الآن! الشيء الذي يهمني في هذا المثال هو انه يستغل إمكانات الكمبيوتر الحسابية ليقوم بكثير من العمل بدلاً من الإنسان: هل تريد هذه الخطوط متوازية؟ هل تريدها متعامدة؟ هل تريد هذه النقاط على استقامة واحدة؟ فقط اطلب هذا من الحاسوب!

ثم ننظر إلى برامجنا الحديثة: برنامج Word مثلاً، فنجده انه يشبه في أساسه آلة كاتبة الكترونية. إنه يسمح لك بتنسيق كلامك، نعم، وبتعديله بعد كتابته، وبإدراج جداول ورسومات بيانية بل وأفلام فيديو، لكنه الهدف الأساسي..الكتابة؛ هذا متروك لك!

• لو كنت تؤلف قصة فعليك أن تتابع أنت حالة كل شخصية وموقفها.
• لو كنت تكتب مقالاً فمسؤوليتك تنظيم أفكارك.
• لو كنت تكتب كتاباً فعليك مسؤوليات كثيرة؛ غالباً ما ستسجل في ورقة جانبية الفكرة العامة لكل فصل، والمصادر الخاصة بكل فصل، والأفكار التي أنت متأكد منها مقابل ما ينبغي مراجعته...الخ...الخ...
• لو كنت تكتب documentation فعليك مسؤوليات أكثر.
• لو كنت تكتب شعراً فعليك مراعاة الأوزان بنفسك.

طب إيه لزمة الكمبيوتر بقى؟؟؟؟

ننظر أيضاً لبرامج الرسم؛ سأركز على البرامج 2D حالياً: برنامج مثل Inkscape يسمح بعمل تدرجات للألوان، ويسمح باستخدام منحنيات بيزييه، ويسمح بأن تكون الخطوط مثل قلم حبر أو رصاص أو فرشاة. ويسمح بعمل أشكال ثلاثية الأبعاد. لكنه لا يساعدني أن أرسم!

مشاكلي في الرسم تشبه الآتي:

- لقد رسمت يداً تمسك بسيف، أي الخطوط أمسحها لكي اجعل الأصابع التي أمام السيف تظهر، والتي وراء السيف لا تظهر؟

- أريد أن اصمم الشكل (شخص، حصان، سيارة) من مكونات هندسية أساسية (متوازي مستطيلات، شكل كروي) ثم احولها تدريجياً للشيء المطلوب رسمه.

- أريد أن أضبط تعبيرات الوجه.

- أريد أن اسجل نسب الجسم الخاصة بشخص (نسبة الرأس للبدن للسيقان..) لكي يكون الشخص بنفس النسب كلما رسمته.

- أريد ان ارسم قصص مصورة بدون تكرار للعمل.

لماذا لا تساعدني أيها الحاسوب؟؟

ثم ننظر للبرمجة. لماذا لا يساعدني الكمبيوتر؟ إنه يعطيني محرراً أكتب فيه، ثم يسكت! على الأقل أدوات مثل Eclipse هي خطوة في الاتجاه الصحيح. هب أنني غيرت عدد الـparameters في دالة. يقوم Eclipse وقتها بتنبيهي إلى كل أماكن استدعاء الدالة لكي اضيف فيها الـparameter الإضافي. ولو كانت الدالة معرفة في class، فهو يقوم بتنبيهي لكل فصيلة فرعية تعيد تعريف الدالة لكي أغيرها أيضاً..

هكذا يكون الكمبيوتر الشاطر: يقوم بكل عمليات البحث والمطابقة - تلك العمليات المملة - لكي لا احتاج أنا الإنسان أن اقوم بها.

(الظريف ان بعض المبرمجين يتباهون بعدم احتياجهم لمثل هذه الأدوات.)

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

---

إن أجهزة الكمبيوتر الموجودة في الثمانينات كانت إمكاناتها لا تذكر مقارنةً بالأجهزة الحديثة، لكن البرامج القديمة، كثيراً ما أشعر انها كانت "ألذ" بكثير. لقد تغيرت نظرة المبرمجين للعلاقة بين الكمبيوتر وصاحبه؛ قديماً كان هناك تركيز كبير على فكرة "الكمبيوتر يقوم بالأشياء المملة لكي يقوم الإنسان بالأجزاء المهمة"، الآن يبدو وكأن الشخص هو خادم الكمبيوتر وليس العكس: تحديث الويندوز، الكشف عن الفيروسات، تركيب SVN/IDE/JVM/Maven....الخ قبل أن تبدأ البرمجة.

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

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

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

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

تجربة: لغة برمجة غير مألوفة سهلة التعلم

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

لكن ماذا لو لم يهمني ذلك؟ لو اردت عمل لغة جديدة للاطفال، بالعربية، ويمكنني ان اضحي بمشابهة اللغات الاخرى مقابل سهولة الاستخدام؟

حسناً..اولا سيكون امر التخصيص في صورة ->، بدلا من علامة =، لتحديد اتجاه ذهاب البيانات. أيضاً سيتم تبديل الاتجاهات

س -> ص معناها "ضع س في ص".

ايضاً لن يكون هناك امر اقرأ ولا اطبع، لكن سيكون هناك كائنات Objects تعبر عن الشاشة، لوحة المفاتيح،...الخ

"مرحبا" -> الشاشة
المفاتيح -> س
الماوس ->(س1، ص1)
الماوس ->(س2، ص2)
ارسم.خط (س1،ص1)-(س2،ص2)

هل لاحظت (س1،ص1)؟ هذا لأن اللغة ستدعم تجميعات من القيم tuples. بالمناسبة هكذا تكون عملية التبديل مثلاً سهلة جداً:
(أ، ب) -> (ب، أ)

"خلي أ تبقى ب، وب تبقى أ"

لو أردت ان تكون اللغة object oriented جداً فيمكنني اصلا ان ارسل قيماً كما اريد للشاشة وما شابه..

خ = خط(100، 100، 200، 200)
د = دائرة(100، 100، 75)
خ -> الشاشة
د -> الشاشة

هذه الطريقة تجعل امور معينة سهلة جداً..ماذا لو اردت برنامج يرسم خطوطا باستمرار؟

كرر:
خط(الماوس، الماوس) -> الشاشة
تابع

حسناً....كفانا لعباً بالمعامل ->، ماذا نفعل أيضا؟؟

تعال نصنع طريقة بسيطة لعمل الدوال:

مجموع(أ، ب) = أ + ب.

وطريقة لتعريف الاجراءات:

حرك(أ، بداية، نهاية) =
ارسم(أ، بداية)
انتظر(30)
ارسم(أ، نهاية).

تبدو اللغة نوعاً ما مثل لغة prolog..أليس كذلك؟

مادمنا قد بدأنا في هذا المشوار، تعال نكمل بأن نضيف طريقة مبسطة لتعريف البيانات.

نوع شخص(اسم، سن، عنوان).

شخص(اسم: "حمدي"، سن: 12، عنوان: "الجيزة") -> ح
اسم ح -> الشاشة

ماذا عن الOOP؟ سوف نعرف كل الmethods كأنها رسائل للانواع المختلفة بكلمة في اللغة اسمها معنى

معنى شخص(أ، ب، ج) -> الشاشة =
("هذا شخص اسمه "، أ، "وسنه "، ب) -> الشاشة.

هذه هي الطريقة التي مكنتني من تعريف كيف ارسم خطاً بأن ارسله للشاشة مثلاً في الامثلة السابقة. لاحظ انني عرفت method بين نوع كامل من البيانات (شخص) وبين كائن object واحد هو الشاشة...يمكن في اللغة المزج بحرية بين classes وobjects..مثلما يمكنني في الحياة الطبيعية ان اقول هذا الكلب يجري حين يرى القطط، فأكون عرفت تصرف كائن معين بفصيلة من الكائنات.

هل هذه اللغة ابسط فعلاً أم هي فقط ازالت بعض الصعوبات ووضعت مكانها صعوبات جديدة؟ ماذا عن سطر مثل خط(الماوس، الماوس) -> الشاشة هل هة مفهوم؟ وهل هذه طريقة جيدة للبرمجة اصلاً؟

يحتاج الامر لتجربة. ما رأيك أن تنفذ انت هذه اللغة وتجرب على اطفال؟

نسيت شيئاً...ماذا اسميها؟ من الصعب عليّ أن أفكر في مشروع بدون اسم جيد له..ماذا عن "سهم"؟ بديهي اكثر مما ينبغي؟ سأبقيها هكذا حتى العثور على اسم افضل. أو سمّه انت لو ستنفذه :)

Almost all programming is metaprogramming

Any sufficiently large program involves metaprogramming, whether the program's author meant it or not. By so I mean it:

• Creates a 'program' in some specialized encoding, or 'language'
• Writes an interpreter for that language
• During runtime, creates a new program in the newly created language and executes it.

Or in other words, a sufficiently advanced data structure is indistinguishable from code.

Let's think of this in terms of real-world (and some not so real-world) examples:

1- Think of implementing a word processor; you have a specialized 'language' to describe paragraphs, lines, formatting, and so on and one or more 'interpreters' to take the program and render it to the screen or print it. Sometimes the language is very real, like for example Postscript.

2- Also, parser combinators: You are essentially creating a program out of lambdas or objects. Consider the parsing primitives to be like instructions of a virtual machine, and the resulting parser as an AST that knits those instructions together. Running the parser is passing the instructions calls to the VM.

3- Similarly, the reason a Turing machine is so powerful is because it has an infinite tape that can be freely accessed. If you study TM programs you'd find a lot of them generating intermediate data on the tape and then traversing this intermediate data using fixed circuitry in its transition diagram; so in other words interpreting it.

All of this seems rather obvious, and somewhat too philosophical. What practical benefit do we get out of this? I think if we realize that our programming is mostly about creating and executing more specialized programs; we'd start thinking about tooling support for our specialized programs..

Whether we're programming with C, Java or your favorite functional language, you probably have debugging, refactoring, and other support for the first level program; the (e.g Java code itself) the higher level program, however, is neglected as mere 'data'. So you'd be working on a lower abstraction level.

There's ongoing research about tooling support for domain specific languages and making it easy to integrate them with the host language's debugger...etc. I suggest going to the next level: make it easy to treat any data structure as a DSL..

That would probably require the host language to take homoiconism very seriously: If it's an OOP language the program itself would be composed of object literals. ML-like languages would have their code be composed of calls to data constructors. Prolog-like languages would have the program be a set of program facts. And so on. Basically, if the tools in the IDE work on code they should work similarly on anything else.

After all this is done, imagine again working on our word processor: We could step over the rendering of each paragraph, then step into a given line to troubleshoot a bug. Tracing the running of a parser created from combinators would be on a rule-by-rule basis. The 'safe delete' refactoring could have a lot in common with the language's garbage collector. An error would make the IDE stop and show which piece of input caused the problem instead of the troubled code in the main program.

Or maybe I'm wrong. Maybe no one came with the idea because there's some obvious flaw in this reasoning. Or that the idea is vaguely defined and falls apart if studied in detail..I don't know!

Concept: The Whisper programming language

I'm thinking up of a new programming language, heavily derived from Smalltalk and called 'Whisper'. This is an outline of my current thoughts -- I don't know when or if I'd actually implement the language.

Syntax

Like Smalltalk, almost everything is a message send. There are two kinds of message send in Whisper: binary operators and keyword messages. Binary operators follow the usual Smalltalk tradition:

12 + 8 * 2 -- returns 40

Keyword messages follow syntax like this:

myWindow : drawCircleAt(100, 100) withRadius(50)

Some notes:

• A colon after the object indicates the start of a message send
• A keyword can have zero, one or more values acting as positional arguments
• Normal C-like positional arguments are a special case of this syntax
• The syntax is heavily inspired by the Grace educational programming language, itself inspired - again- by Smalltalk

We have the traditional ST blocks:

myFunc = { x, y | x + y }

When sending a keyword message, and a block is the only argument between parenthesis, the parens can be omitted like so

(x > 5) ifTrue { out : print("yes") } else { out : print("no") }

IDE & Image

As an experiment, the main IDE for Whisper would be completely browser-based with IDE logic running from a web server. Local applications can be written that access local files...etc but the application's UI would still be browser based.

Another, for me much harder experiment is to make everything persistent all the time on an Sqlite database: All program state changes would be by writing to slots in objects, even function activation records or global variables (an idea taken from Self and others), and all slot writes would be trapped and written in the DB.

This would have a very high performance cost, so a lot of design thought should be put into this; by thinking about how to use memory for cache, possibly marking special object as transient, or some other clever method. I'm sure the Lispers, Smalltalkers, Selfers...etc have probably already "killed this problem from research", as the Arabic saying goes, and that I could find an ideal solution in some paper published in 1989..we'll see!

Gradual typing

Fields, method arguments and return values can have optional type declarations, this would allow the JIT compiler to better optimize things and (more importantly for me) allow autocomplete to work. It would also make refactoring safer, for example renaming a method would change the identifiers in all known calls to that method.

This should not change the dynamic nature of the language: The IDE and program are still 'live' and programs are still assembled piecemeal without an edit/compile cycle. There will be situations when calling a method with wrong argument types throws a runtime exception instead of a compiler error, and that's fine for me.

Other goodies

Since I'm now in the dreaming phase and not serious work phase, let's steal some ideas from Lisp, while we're at it:

The first is multiple dispatch. I think this will be useful in certain types of applications like compilers, allow us to think about libraries in new ways (I can imagine a GUI library inspired by the 'lenses' concept from MIT's Haystack project) and allows niceties like the return of traditional syntax:

if(x > 5) do { out: print("yes") } else { out: print("no") }

We can almost fool users into thinking it's Java or C#!

Also, since the syntax is nicely minimal, we could think about adding some metaprogramming...

Since Smalltalk tries to make as much of the program be represented as objects, we can do the same with the program syntax tree itself; and have the AST of each method be a public property of that method.

This would allow us to write code in our own DSL inside a method, code which looks like gibberish to the interpreter but useful for us, since we can write procedures to read the tree from the method and process it in whatever way we like. Possibly layer Common Lisp-style macros on top of this feature.

---

Looks like a nice language, right? I wish it were already available so that I didn't have to develop it :(

بين عبقرينو وروبرت كوخ

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

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

‫هناك نوعين إذًا أميّز بينهما: الباحث الذي يهدف أساسا لفهم شيء عن الكون الذي نعيش فيه، والمخترع الذي يستفيد من العلم‬.

‫ربما يحتاج عبقرينو أن يكتشف نظرية علمية جديدة ليتمكن من تنفيذ اختراعه، لكن ليست وظيفته اكتشاف النظريات العلمية‬.‫وربما يحتاج روبرت كوخ لتطوير جهاز جديد ليتمكن من مواصلة أبحاثه، لكن ليست وظيفته تطوير الأجهزة‬. كل منهما يعتبر دور الآخر مكمل لدوره.

‫كنت فيما مضى أظن أنني أريد أن أكون روبرت كوخ. أرى نفسي في نقطة مستقبلية كعالم computer science أكتشف نظريات جديدة،

‫لكني في الواقع أريد أن أكون عبقرينو‬.

أريد أن أستخرج الكنوز المدفونة في الأبحاث العلمية وأصنع بها أشياء مبهرة. أريد - في مرحلة ما من عمري- أن أصمم أشياء لم يكن يُتخيّل أنها تصنع. أريد أن أرى تصميماتي وهي تعمل على أرض الواقع.

هل معنى ذلك أنني لا أريد أن أكتشف أية نظرية علمية؟ ربما يحدث أن أكتشف شيئا أو أطوّر شيئا (لو بلغت ذلك المستوى...لو!). المسألة ليست عِناداً!

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

هل سأبلغ ذلك المستوى؟ هل سيتحقق ما أرغب؟ لا أعلم!