اكتب نظام الأسئلة الشائعة

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



دعونا نفهم مرة واحدة وإلى الأبد الأسباب التي تسبب الارتباك عند الحديث عن أنظمة الكتابة.

الكتابة الديناميكية ونقص الكتابة

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

• في المجمع ، النوع الوحيد هو سلسلة من البتات.
• في حساب التفاضل والتكامل لامدا ، والنوع الوحيد هو وظيفة.

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

تسمى اللغات التي لا تحد من نطاق قيم المتغيرات لغات غير نمطية: ليس لديهم أنواع ، أو ، ما هو الشيء نفسه ، لديهم نوع عالمي واحد فقط يحتوي على جميع القيم.
_{نوع الأنظمة ، لوكا كارديلي}

تحتوي لغات البرمجة على ميزة واحدة مثيرة للاهتمام تسمح لك بتقسيم عالمها تقريبًا إلى مجموعتين:

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

_{"أنظمة الكتابة للغات البرمجة" ، بنجامين بيرس}

الكتابة الديناميكية والساكنة

نظام الكتابة الديناميكي هو نظام يتم فيه فحص الأنواع ديناميكيًا (أثناء تنفيذ البرنامج). نظام الكتابة الثابتة هو نظام يتم فيه فحص الأنواع بشكل ثابت (أثناء الترجمة أو الترجمة الشفوية).

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

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

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

من المستحسن اعتبار نظام النوع الثابت بمثابة أنواع يتم فحصها بشكل ثابت. يشبه نظام الكتابة الديناميكي الأنواع التي يتم فحصها ديناميكيًا.

هل يعني استخدام الأنواع الثابتة معرفة الأنواع في وقت الترجمة؟

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

 let x = "test"; 

اتضح أن المحلل اللغوي يعرف أن "test" عبارة عن سلسلة. هل هذا يجعل جافا سكريبت لغة مكتوبة ثابتة؟ لا ، ليس كذلك.

الكتابة التدريجية

نظام الكتابة التدريجية هو نظام كتابة ثابت يتيح لك تخطي اختبارات النوع لبعض أجزاء البرنامج. على سبيل المثال ، في TypeScript ، يتم تطبيق ذلك باستخدام any أو @ts-ignore .

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

أنظمة موثوقة وغير موثوقة

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

إذا كنت ترغب في العمل مع أنظمة كتابة موثوقة ، فقم بإلقاء نظرة على لغات البرمجة لعائلة ML ، والتي تستخدم نظام الكتابة Hindley-Milner.

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

يسمى نظام الكتابة الذي لا يرفض البرنامج الصحيح مطلقًا.

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

كتابة ضعيفة وقوية

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

يمكن تسمية هذه اللغات ، من الناحية المجازية ، باللغات ذات التدقيق الضعيف في الكتابة (أو اللغات المكتوبة بشكل ضعيف ، كما يطلق عليها عادة في المنشورات المختلفة). استخدام التدقيق الضعيف في اللغة يعني أن بعض العمليات غير الآمنة يتم اكتشافها بشكل ثابت ، والبعض الآخر لا يتم اكتشافها. يختلف "ضعف" اختبارات النوع بلغات هذه الفئة اختلافًا كبيرًا.
_{نوع الأنظمة ، لوكا كارديلي}

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

مصطلحات "الكتابة القوية" و "الكتابة الضعيفة" غامضة للغاية. فيما يلي بعض الأمثلة على استخدامها:

• في بعض الأحيان ، يُفهم أن "الكتابة القوية" تعني "الكتابة الساكنة". ليس من الصعب إجراء مثل هذا "الاستبدال" ، ولكن من الأفضل ، عند الحديث عن الكتابة الثابتة ، أن نسميها ببساطة "ثابتة". الحقيقة هي أن معظم المبرمجين يفهمون هذا المصطلح بوضوح.
• في بعض الأحيان ، عندما يقولون "الكتابة القوية" ، فإنها تعني "عدم وجود تحويل ضمني للنوع". على سبيل المثال ، في JavaScript ، يمكنك استخدام تعبيرات مثل "a" - 1 . هذا يمكن أن يسمى نموذج "الكتابة الضعيفة". لكن جميع اللغات تقريبًا تمنح المبرمج بعض الفرص لتحويل النوع الضمني ، على سبيل المثال ، يدعم التحويل التلقائي للأعداد الصحيحة إلى أرقام الفاصلة العائمة بتعبيرات مثل 1 - 1.1 . في الممارسة العملية ، يميز معظم المهنيين الذين يستخدمون مصطلح "الكتابة القوية" بهذه الطريقة بين تحويلات الكتابة "المقبولة" و "غير المقبولة". ولكن لا يوجد حد مقبول بشكل عام بين تحويلات هذا النوع. "مقبولية" و "عدم مقبولية" التحولات هو تقييم شخصي ، وهذا يتوقف على رأي شخص معين.
• في بعض الأحيان تسمى اللغات ذات "الكتابة القوية" تلك اللغات التي يستحيل فيها التحايل على قواعد نظام الكتابة الموجود فيها.
• في بعض الأحيان ، تعني عبارة "الكتابة القوية" وجود نظام للكتابة يتيح لك العمل بأمان مع الذاكرة. تعد لغة C مثالًا بارزًا للغة غير الآمنة بالذاكرة. على سبيل المثال ، إذا كانت xs عبارة عن صفيف من أربعة أرقام ، فسيقوم C باعتماد رمز يستخدم xs[5] مثل xs[5] أو xs[1000] دون أي مشاكل. سوف يسمحون لك بالوصول إلى الذاكرة الموجودة بعد العناوين المخصصة لتخزين محتويات صفيف xs .

_{الأنواع ، غاري برنارد}

هل تحتاج اللغات المكتوبة الثابتة إلى تعريفات الكتابة؟

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

 const x = "test"; 

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

 const add = (x, y) => x / y //            ^        [1]   . add(1, "2") 

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

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

هل TypeScript هي لغة غير آمنة لأن الشفرة المكتوبة فيها يتم تحويلها إلى شفرة JavaScript؟

TypeScript هي لغة غير سليمة. لذلك ، يمكن أن يتحول الرمز المكتوب عليه إلى تطبيقات غير آمنة. ولكن هذا لا علاقة له بما يجمع.

تقوم معظم برامج التحويل البرمجي لسطح المكتب بتحويل البرامج إلى شيء يشبه لغة التجميع. والتجميع هو لغة أقل أمانًا من JS.

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

على سبيل المثال ، تلعب دور "آليات الدفاع" هذه في شركة Elm دور " الموانئ ". في TS ، يمكنك استخدام شيء مثل io-ts لهذا الغرض.

تخلق "آلية الحماية" المقابلة جسرًا بين أنظمة النوع الثابت والديناميكي.

هنا مثال مبسط:

 const makeSureIsNumber = (x: any) => {  const result = parseFloat(x);  if (isNaN(result)) {    throw Error("Not a number");  }  return result; } const read = (input: any) => {  try {    const n = makeSureIsNumber(input);    //     n, ,      //              // makeSureIsNumber "" , n    } catch (e) { } } 

هل صحيح أن الأنواع مطلوبة فقط للمترجمين؟

الأنواع هي مجرد الاختراق المطلوب لإعطاء تلميحات إلى المحول البرمجي.
_{وات ميرتنز}

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

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

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

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

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

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


"المنزلق"

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

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

النتائج

النظر في أي برنامج مكتوب بلغة البرمجة المكتوبة. يمكننا مراقبة الأنواع. أليس كذلك؟ ولكن البرنامج يجمع في رموز الجهاز. في هذه الرموز ، يتم التعبير عن نفس الشيء كما في البرنامج الأصلي (على الرغم من أنه من الصعب على الشخص قراءة التوضيحات الآلية للبرامج). من وجهة نظر الكمبيوتر ، لا توجد أنواع. لا يرى سوى تسلسل البتات - مجموعات من الأصفار وتلك (الخلايا "الميتة" و "الحية"). توجد أنواع للأشخاص ، وليس للسيارات.

أعزائي القراء! ما نوع النظام الذي يمكن أن تعتبره مثاليًا لتطوير الويب؟