هي مضمون ترجمو آهي . پر هن کان اڳ جو ٿورو تعارف. زومبي ڪيئن ٺهيل آهن؟ هرڪو هڪ اهڙي صورتحال ۾ اچي ويو جتي اهي هڪ دوست يا ساٿي کي پنهنجي سطح تائين ڇڪڻ چاهين ٿا، پر اهو ڪم نٿو ڪري. ۽ اهو توهان سان ايترو گهڻو نه آهي جيترو هن سان ته ”اهو ڪم نٿو ڪري“: پيماني جي هڪ پاسي هڪ عام تنخواه آهي، ڪم، وغيره، ۽ ٻئي طرف، سوچڻ جي ضرورت آهي. سوچڻ اڻ وڻندڙ ۽ دردناڪ آهي. هو جلدي ڇڏي ٿو ۽ ڪوڊ لکڻ جاري رکي ٿو بغير پنهنجي دماغ کي ڦيرائڻ جي. توهان تصور ڪيو ته سکيا جي بيوسيءَ جي رڪاوٽ کي دور ڪرڻ لاءِ ڪيتري ڪوشش ڪرڻي پوندي آهي، ۽ توهان اهو نه ڪندا آهيو. اهو ڪيئن زومبي ٺاهي رهيا آهن، جيڪو لڳي ٿو، علاج ڪري سگهجي ٿو، پر اهو لڳي ٿو ته ڪو به اهو نه ڪندو.
جڏهن مون اهو ڏٺو (ها، درسي ڪتابن مان ساڳيو ڪامريڊ) ۽ رپورٽ نه ٺاهي، پر هڪ سوال ۽ جواب سيشن، مان ٿورڙو هوشيار هو. صرف ان صورت ۾، ليسلي هڪ دنيا جي مشهور سائنسدان آهي، جيڪو ورهايل ڪمپيوٽنگ ۾ بنيادي ڪم جو مصنف آهي، ۽ توهان هن کي لفظ LaTeX - "Lamport TeX" ۾ La اکرن ذريعي پڻ سڃاڻي سگهو ٿا. ٻيو خوفناڪ عنصر هن جي گهرج آهي: هرڪو جيڪو اچي ٿو (بلڪل مفت) هن جون ٻه رپورٽون اڳ ۾ ٻڌي، انهن تي گهٽ ۾ گهٽ هڪ سوال کڻي اچن، ۽ پوءِ ئي اچي. مون اهو ڏسڻ جو فيصلو ڪيو ته ڇا لامپورٽ اتي نشر ڪري رهيو هو - ۽ اهو عظيم آهي! اها بلڪل اها ئي شيءِ آهي، جادوءَ جي ڪڙي واري گولي زومبي کي علاج ڪرڻ لاءِ. مان توهان کي ڊيڄاريان ٿو: متن مان، سپر لچڪدار طريقن سان پيار ڪندڙ ۽ جيڪي جيڪي لکندا آهن انهن کي جانچڻ پسند نه ڪندا آهن خاص طور تي ساڙي سگهن ٿا.
حبروڪات کان پوء، حقيقت ۾، سيمينار جو ترجمو شروع ٿئي ٿو. پڙهڻ جو مزو وٺو!
جيڪو به ڪم توهان کڻو، توهان کي هميشه ٽن مرحلن ذريعي وڃڻ جي ضرورت آهي:
- فيصلو ڪريو ته توهان ڪهڙو مقصد حاصل ڪرڻ چاهيو ٿا؛
- فيصلو ڪريو ته توهان پنهنجي مقصد کي ڪيئن حاصل ڪندا؛
- پنهنجي مقصد تي اچو.
اهو پڻ پروگرامنگ تي لاڳو ٿئي ٿو. جڏهن اسان ڪوڊ لکندا آهيون، اسان کي گهرجي:
- فيصلو ڪيو ته پروگرام ڇا ڪرڻ گهرجي؛
- اهو طئي ڪيو ته اهو ڪيئن ڪم ڪرڻ گهرجي؛
- لاڳاپيل ڪوڊ لکو.
آخري قدم، يقينا، تمام ضروري آهي، پر مان اڄ ان بابت نه ڳالهائيندس. ان جي بدران، اسان پهرين ٻن تي بحث ڪنداسين. هر پروگرامر انهن کي ڪم ڪرڻ کان اڳ انجام ڏئي ٿو. توهان لکڻ لاءِ نه ويهندا جيستائين توهان فيصلو نه ڪيو ته توهان برائوزر يا ڊيٽابيس لکي رهيا آهيو. مقصد جو هڪ خاص خيال موجود هجڻ گهرجي. ۽ توهان ضرور سوچيو ته پروگرام ڇا ڪندو، ۽ ڪنهن به طرح نه لکو اميد ۾ ته ڪوڊ ڪنهن نه ڪنهن طرح برائوزر ۾ تبديل ٿي ويندو.
اهو ڪوڊ اڳي سوچڻ ڪيئن ٿيندو؟ اسان کي ان ۾ ڪيتري ڪوشش ڪرڻ گهرجي؟ اهو سڀ ان تي منحصر آهي ته اسان ڪيترو پيچيده مسئلو حل ڪري رهيا آهيون. فرض ڪريو اسان لکڻ چاهيون ٿا نقص برداشت ڪندڙ ورهايل نظام. انهي حالت ۾، اسان کي احتياط سان سوچڻ گهرجي ته اسان ڪوڊ تي ويهڻ کان اڳ. ڇا جيڪڏهن اسان کي صرف هڪ انٽيجر متغير کي 1 وڌائڻ جي ضرورت آهي؟ پهرين نظر ۾، هتي هر شيء معمولي آهي، ۽ ڪنهن به سوچ جي ضرورت ناهي، پر پوء اسان کي ياد آهي ته هڪ اوور فلو ٿي سگهي ٿو. تنهن ڪري، اهو سمجهڻ لاء ته ڇا مسئلو سادو آهي يا پيچيده، توهان کي پهريان سوچڻ جي ضرورت آهي.
جيڪڏهن توهان اڳ ۾ ئي مسئلي جي ممڪن حل جي باري ۾ سوچيو، توهان غلطين کان پاسو ڪري سگهو ٿا. پر اهو ضروري آهي ته توهان جي سوچ واضح هجي. هن کي حاصل ڪرڻ لاء، توهان کي پنهنجي خيالن کي لکڻ جي ضرورت آهي. مون کي ڊڪ گائنڊن جو اقتباس پسند آهي: ”جڏهن توهان لکندا آهيو، فطرت توهان کي ڏيکاريندي آهي ته توهان جي سوچ ڪيتري نه ٻرندڙ آهي. جيڪڏهن توهان نه لکندا آهيو، توهان صرف اهو سوچيو ته توهان سوچيو ٿا. ۽ توهان کي پنهنجي خيالن کي وضاحتن جي صورت ۾ لکڻ جي ضرورت آهي.
وضاحتون ڪيترن ئي ڪمن کي انجام ڏين ٿيون، خاص طور تي وڏي منصوبن ۾. پر مان صرف انهن مان هڪ بابت ڳالهائيندس: اهي اسان کي واضح طور تي سوچڻ ۾ مدد ڪن ٿيون. واضح طور تي سوچڻ تمام ضروري آهي ۽ ڪافي ڏکيو آهي، تنهنڪري هتي اسان کي ڪنهن به مدد جي ضرورت آهي. اسان کي ڪهڙي ٻولي ۾ وضاحتون لکڻ گهرجن؟ عام طور تي، اهو هميشه پروگرامرز لاء پهريون سوال آهي: اسان ڪهڙي ٻولي ۾ لکنداسين. ان جو ڪو به صحيح جواب نه آهي: اسان جيڪي مسئلا حل ڪري رهيا آهيون اهي تمام متنوع آهن. ڪجهه لاءِ، TLA + هڪ وضاحتي ٻولي آهي جيڪا مون ترقي ڪئي. ٻين لاء، اهو چيني استعمال ڪرڻ لاء وڌيڪ آسان آهي. هر شي صورتحال تي منحصر آهي.
وڌيڪ اهم هڪ ٻيو سوال آهي: واضح سوچ ڪيئن حاصل ڪجي؟ جواب: اسان کي سائنسدانن وانگر سوچڻ گهرجي. اهو سوچڻ جو هڪ طريقو آهي جيڪو پاڻ کي گذريل 500 سالن ۾ ثابت ڪيو آهي. سائنس ۾، اسان حقيقت جي رياضياتي ماڊل ٺاهيندا آهيون. Astronomy لفظ جي سخت معنى ۾ شايد پهرين سائنس هئي. فلڪيات ۾ استعمال ٿيندڙ رياضياتي ماڊل ۾، آسماني جسم ماس، پوزيشن ۽ رفتار سان پوائنٽن جي طور تي ظاهر ٿيندا آهن، جيتوڻيڪ حقيقت ۾ اهي جبلن ۽ سمنڊن، لھرن ۽ لھرن سان گڏ انتهائي پيچيده شيون آھن. هي ماڊل، ڪنهن ٻئي وانگر، ڪجهه مسئلن کي حل ڪرڻ لاء ٺهيل هو. اهو طئي ڪرڻ لاءِ وڏو آهي ته جيڪڏهن توهان کي سيارو ڳولڻ جي ضرورت آهي ته دوربين کي ڪٿي اشارو ڪيو وڃي. پر جيڪڏهن توهان هن ڌرتي تي موسم جي اڳڪٿي ڪرڻ چاهيو ٿا، ته هي ماڊل ڪم نه ڪندو.
رياضي اسان کي هڪ ماڊل جي ملڪيت جو تعين ڪرڻ جي اجازت ڏئي ٿو. ۽ سائنس ڏيکاري ٿي ته اهي خاصيتون حقيقت سان ڪيئن تعلق رکن ٿيون. اچو ته اسان جي سائنس، ڪمپيوٽر سائنس جي باري ۾ ڳالهايون. حقيقت جنهن سان اسان ڪم ڪريون ٿا مختلف قسم جا ڪمپيوٽنگ سسٽم آهن: پروسيسرز، گيم ڪنسولز، ڪمپيوٽرز، ايگزيڪيوٽو پروگرام، وغيره. مان ڪمپيوٽر تي پروگرام هلائڻ جي باري ۾ ڳالهائيندس، پر وڏي پيماني تي، اهي سڀئي نتيجا ڪنهن به ڪمپيوٽنگ سسٽم تي لاڳو ٿين ٿا. اسان جي سائنس ۾، اسان ڪيترائي مختلف ماڊل استعمال ڪندا آهيون: ٽريننگ مشين، جزوي طور تي ترتيب ڏنل واقعن جا سيٽ، ۽ ٻيا ڪيترائي.
هڪ پروگرام ڇا آهي؟ هي ڪو به ڪوڊ آهي جنهن کي آزاد سمجهي سگهجي ٿو. فرض ڪريو اسان کي برائوزر لکڻو پوندو. اسان ٽن ڪمن کي انجام ڏيون ٿا: اسان پروگرام جي صارف جي نظر کي ترتيب ڏيون ٿا، پوء اسان پروگرام جو اعلي سطحي ڊراگرام لکون ٿا، ۽ آخر ۾ اسان ڪوڊ لکون ٿا. جيئن اسان ڪوڊ لکون ٿا، اسان محسوس ڪيو ته اسان کي لکڻ جي ضرورت آهي ٽيڪسٽ فارميٽ. هتي اسان کي ٻيهر ٽن مسئلن کي حل ڪرڻ جي ضرورت آهي: اهو طئي ڪيو ته هي اوزار ڪهڙو متن واپس ڪندو. فارميٽ ڪرڻ لاء هڪ الگورتھم چونڊيو؛ ڪوڊ لکڻ. ھن ڪم جو پنھنجو ذيلي ڪم آھي: صحيح طرح لفظن ۾ ھائيفن داخل ڪريو. اسان هن ذيلي ڪم کي ٽن مرحلن ۾ پڻ حل ڪريون ٿا - جيئن توهان ڏسي سگهو ٿا، اهي ڪيترن ئي سطحن تي ورجائي رهيا آهن.
اچو ته پهرين قدم تي وڌيڪ تفصيل سان غور ڪريو: پروگرام ڪهڙي مسئلي کي حل ڪري ٿو. هتي، اسان اڪثر ڪري هڪ پروگرام کي هڪ فنڪشن جي طور تي ماڊل ڪندا آهيون جيڪو ڪجهه انپٽ وٺندو آهي ۽ ڪجهه پيداوار پيدا ڪري ٿو. رياضي ۾، هڪ فنڪشن عام طور تي جوڑوں جي ترتيب ڏنل سيٽ طور بيان ڪيو ويندو آهي. مثال طور، قدرتي انگن لاء اسڪوائرنگ فنڪشن کي سيٽ طور بيان ڪيو ويو آهي {<0,0>, <1,1>, <2,4>, <3,9>, …}. اهڙي فنڪشن جو ڊومين هر جوڙي جي پهرين عناصر جو سيٽ آهي، اهو آهي، قدرتي انگ. ھڪڙي فنڪشن کي بيان ڪرڻ لاء، اسان کي ان جي دائري ۽ فارمولا کي بيان ڪرڻ جي ضرورت آھي.
پر رياضي ۾ فعل ساڳيا نه آهن جيئن پروگرامنگ ٻولين ۾ افعال. رياضي تمام آسان آهي. جيئن ته مون وٽ پيچيده مثالن لاءِ وقت نه آهي، اچو ته هڪ سادي نموني تي غور ڪريون: C ۾ هڪ فنڪشن يا جاوا ۾ هڪ جامد طريقو جيڪو ٻن عددن جو سڀ کان وڏو عام تقسيم ڪندڙ ڏي ٿو. هن طريقي جي وضاحت ۾، اسين لکنداسين: حساب GCD(M,N) دليلن لاءِ M и Nڪٿي GCD(M,N) - هڪ فنڪشن جنهن جو ڊومين آهي انٽيجرز جي جوڑوں جو سيٽ، ۽ واپسي جي قيمت سڀ کان وڏي عدد آهي جيڪا ورهائي سگهجي ٿي M и N. هي ماڊل حقيقت سان ڪيئن تعلق رکي ٿو؟ ماڊل انٽيجرز تي هلندي آهي، جڏهن ته سي يا جاوا ۾ اسان وٽ 32-bit آهي int. هي ماڊل اسان کي اهو فيصلو ڪرڻ جي اجازت ڏئي ٿو ته ڇا الورورٿم صحيح آهي GCD، پر اهو اوور فلو غلطين کي نه روڪيندو. اهو هڪ وڌيڪ پيچيده ماڊل جي ضرورت آهي، جنهن لاء ڪو وقت نه آهي.
اچو ته ماڊل جي طور تي فنڪشن جي حدن بابت ڳالهايون. ڪجهه پروگرامن (جهڙوڪ آپريٽنگ سسٽم) صرف ڪجهه دليلن لاءِ هڪ خاص قدر واپس نه ٿا ڪن، اهي مسلسل هلائي سگهن ٿا. ان کان علاوه، هڪ ماڊل جي حيثيت سان فنڪشن ٻئي قدم لاء مناسب نه آهي: منصوبي کي ڪيئن حل ڪرڻ جو مسئلو. تڪڙي ترتيب ۽ بلبل جي ترتيب ساڳئي فنڪشن کي گڏ ڪن ٿا، پر اهي مڪمل طور تي مختلف الگورتھم آهن. تنهن ڪري، بيان ڪرڻ لاءِ ته پروگرام جو مقصد ڪيئن حاصل ٿئي ٿو، مان هڪ مختلف ماڊل استعمال ڪريان ٿو، اچو ته ان کي معياري رويي جو نمونو چئون. ان ۾ پروگرام سڀني جائز رويي جي سيٽ جي طور تي پيش ڪيو ويو آهي، جن مان هر هڪ، موڙ ۾، رياستن جو هڪ سلسلو آهي، ۽ رياست متغيرن جي قدرن جي تفويض آهي.
اچو ته ڏسون ته اڪيليڊ الگورٿم جو ٻيو مرحلو ڪهڙو نظر ايندو. اسان کي حساب ڪرڻو پوندو GCD(M, N). اسان شروعات ڪريون ٿا M ڪيئن x۽ N ڪيئن y، پوءِ بار بار انهن ننڍڙن متغيرن کي وڏن مان گھٽايو جيستائين اهي برابر نه ٿين. مثال طور، جيڪڏهن M = 12۽ N = 18اسان هيٺ ڏنل رويي کي بيان ڪري سگهون ٿا:
[x = 12, y = 18] → [x = 12, y = 6] → [x = 6, y = 6]
۽ جيڪڏهن M = 0 и N = 0؟ صفر سڀني انگن سان ورهائي سگهجي ٿو، تنهنڪري هن معاملي ۾ ڪو به وڏو تقسيم نه آهي. هن صورتحال ۾، اسان کي پهرين قدم ڏانهن واپس وڃڻ جي ضرورت آهي ۽ پڇو: ڇا اسان کي واقعي جي ضرورت آهي GCD غير مثبت نمبرن لاءِ؟ جيڪڏهن اهو ضروري ناهي، ته توهان کي صرف وضاحتن کي تبديل ڪرڻ جي ضرورت آهي.
هتي اسان کي پيداوار جي باري ۾ هڪ ننڍڙو تڪرار ڪرڻ گهرجي. اهو عام طور تي ماپي ويندي آهي ڪوڊ جي لائنن جي تعداد ۾ هر ڏينهن لکيل. پر توھان جو ڪم گھڻو وڌيڪ ڪارائتو آھي جيڪڏھن توھان ھڪڙي مخصوص تعداد مان نجات حاصل ڪري سگھوٿا، ڇاڪاڻتہ توھان وٽ ڪيڙن لاءِ گھٽ گنجائش آھي. ۽ ڪوڊ مان نجات حاصل ڪرڻ جو آسان طريقو پهرين قدم تي آهي. اهو مڪمل طور تي ممڪن آهي ته توهان کي صرف انهن سڀني گھنٽي ۽ سيٽن جي ضرورت ناهي جيڪي توهان لاڳو ڪرڻ جي ڪوشش ڪري رهيا آهيو. هڪ پروگرام کي آسان ڪرڻ ۽ وقت بچائڻ جو تيز ترين طريقو اهو آهي ته اهي شيون نه ڪن جيڪي نه ٿيڻ گهرجن. ٻيو مرحلو ٻيو سڀ کان وڌيڪ وقت بچائڻ جي صلاحيت آهي. جيڪڏهن توهان پيداواري صلاحيت کي لکن جي لحاظ کان ماپيندا آهيو، ته پوءِ سوچيو ته هڪ ڪم ڪيئن پورو ڪجي گهٽ پيداوار، ڇاڪاڻ ته توهان گهٽ ڪوڊ سان ساڳيو مسئلو حل ڪري سگهو ٿا. مان هتي درست انگ اکر نه ٿو ڏئي سگهان، ڇاڪاڻ ته مون وٽ قطارن جو تعداد ڳڻڻ جو ڪو طريقو ناهي جيڪو مون نه لکيو آهي ان حقيقت جي ڪري ته مون وضاحت تي وقت گذاريو آهي، يعني پهرين ۽ ٻئي مرحلن تي. ۽ تجربو به هتي قائم نه ٿو ڪري سگهجي، ڇاڪاڻ ته تجربي ۾ اسان کي پهريون مرحلو مڪمل ڪرڻ جو حق ناهي، ڪم اڳ ۾ ئي مقرر ٿيل آهي.
غير رسمي وضاحتن ۾ ڪيترن ئي مشڪلاتن کي نظر انداز ڪرڻ آسان آهي. ڪمن لاءِ سخت وضاحتون لکڻ ۾ ڪا به ڏکيائي ناهي، مان ان تي بحث نه ڪندس. ان جي بدران، اسان معياري رويي لاء مضبوط وضاحتون لکڻ بابت ڳالهائينداسين. اتي ھڪڙو نظريو آھي جيڪو چوي ٿو ته رويي جو ڪو سيٽ بيان ڪري سگھجي ٿو حفاظتي ملڪيت استعمال ڪندي (حفاظت) ۽ بقا جا خاصيتون (زندگي). سيڪيورٽي جو مطلب آهي ته ڪجھ به خراب نه ٿيندو، پروگرام غلط جواب نه ڏيندو. بقا جو مطلب آهي ته جلد يا دير سان ڪجهه سٺو ٿيندو، يعني پروگرام جلد يا دير سان صحيح جواب ڏيندو. ضابطي جي طور تي، سيڪيورٽي هڪ وڌيڪ اهم اشارو آهي، غلطيون اڪثر هتي ٿينديون آهن. تنهن ڪري، وقت بچائڻ لاء، مان بقا جي باري ۾ نه ڳالهائيندس، جيتوڻيڪ اهو، يقينا، پڻ اهم آهي.
اسان حفاظت حاصل ڪريون ٿا تجويز ڪندي، پهريون، ممڪن ابتدائي رياستن جو سيٽ. ۽ ٻيو، هر رياست لاءِ هر ممڪن ايندڙ رياستن سان لاڳاپا. اچو ته سائنسدانن وانگر ڪم ڪريون ۽ رياستن کي رياضياتي طور بيان ڪريون. شروعاتي رياستن جو سيٽ هڪ فارمولا جي ذريعي بيان ڪيو ويو آهي، مثال طور، ايڪليڊ الگورتھم جي صورت ۾: (x = M) ∧ (y = N). ڪجهه قدرن لاءِ M и N صرف هڪ ابتدائي حالت آهي. ايندڙ رياست سان لاڳاپو هڪ فارمولا ذريعي بيان ڪيو ويو آهي جنهن ۾ ايندڙ رياست جا متغير هڪ پرائم سان لکيا ويندا آهن، ۽ موجوده رياست جا متغير بغير ڪنهن پرائم سان لکيل آهن. Euclid جي الگورتھم جي صورت ۾، اسان ٻن فارمولن جي جدا ٿيڻ سان معاملو ڪنداسين، جن مان ھڪڙي ۾ x سڀ کان وڏو قدر آهي، ۽ سيڪنڊ ۾ - y:
پهرين صورت ۾، y جي نئين قيمت y جي پوئين قيمت جي برابر آهي، ۽ اسان x جي نئين قيمت حاصل ڪندا آهيون وڏي هڪ کان ننڍي متغير کي ختم ڪندي. ٻي صورت ۾، اسان ان جي ابتڙ ڪندا آهيون.
اچو ته يڪليڊ جي الگورتھم ڏانھن واپس وڃو. اچو ته ٻيهر اهو فرض ڪريون M = 12, N = 18. هي هڪ واحد ابتدائي حالت بيان ڪري ٿو، (x = 12) ∧ (y = 18). اسان وري انهن قدرن کي مٿي ڏنل فارمولا ۾ پلگ ان ڪريون ٿا ۽ حاصل ڪريو:
هتي صرف ممڪن حل آهي: x' = 18 - 12 ∧ y' = 12۽ اسان اهو رويو حاصل ڪريون ٿا: [x = 12, y = 18]. اهڙي طرح، اسان سڀني رياستن کي اسان جي رويي ۾ بيان ڪري سگهون ٿا: [x = 12, y = 18] → [x = 12, y = 6] → [x = 6, y = 6].
آخري حالت ۾ [x = 6, y = 6] اظهار جا ٻئي حصا غلط هوندا، تنهنڪري ان جي ڪا ٻي حالت ناهي. تنهن ڪري، اسان وٽ ٻئي قدم جي مڪمل وضاحت آهي - جيئن توهان ڏسي سگهو ٿا، هي ڪافي عام رياضي آهي، جهڙوڪ انجنيئرن ۽ سائنسدانن ۾، ۽ عجيب نه آهي، جهڙوڪ ڪمپيوٽر سائنس ۾.
انهن ٻن فارمولين کي عارضي منطق جي هڪ فارمولا ۾ گڏ ڪري سگهجي ٿو. هوء خوبصورت ۽ وضاحت ڪرڻ آسان آهي، پر هاڻي هن لاء ڪو وقت ناهي. اسان کي عارضي منطق جي ضرورت ٿي سگھي ٿي صرف معيشت جي ملڪيت لاءِ، اها حفاظت جي ضرورت ناهي. مون کي عارضي منطق پسند ناهي، اها ڪا عام رياضي نه آهي، پر زندگي جي حالت ۾ اها هڪ لازمي برائي آهي.
Euclid جي الگورتھم ۾، هر قيمت لاء x и y منفرد قدر آهن x' и y'، جيڪي ايندڙ رياست سان تعلق کي درست ڪن ٿا. ٻين لفظن ۾، Euclid جو الگورتھم تعيناتي آھي. هڪ غير مقرراتي الگورٿم کي ماڊل ڪرڻ لاءِ، موجوده رياست کي مستقبل جي ڪيترن ئي ممڪن رياستن جي ضرورت آهي، ۽ اهو ته هر هڪ غير پرائمڊ متغير قدر ۾ هڪ کان وڌيڪ بنيادي متغير قدر آهن جيئن ته ايندڙ رياست سان تعلق صحيح آهي. اهو ڪرڻ آسان آهي، پر مان هاڻي مثال نه ڏيندس.
ڪم ڪندڙ اوزار ٺاهڻ لاء، توهان کي رسمي رياضي جي ضرورت آهي. وضاحت کي ڪيئن رسمي بڻايو وڃي؟ هن کي ڪرڻ لاء، اسان کي هڪ رسمي ٻولي جي ضرورت آهي، مثال طور، . Euclid algorithm جي وضاحت هن ٻولي ۾ هن طرح نظر ايندي:
ٽڪنڊي سان هڪ برابر نشاني جي علامت جو مطلب اهو آهي ته نشاني جي کاٻي پاسي جي قيمت نشاني جي ساڄي پاسي جي قيمت جي برابر هجڻ جي وضاحت ڪئي وئي آهي. ذات ۾، وضاحت هڪ تعريف آهي، اسان جي صورت ۾ ٻه معنائون. TLA+ ۾ وضاحت ڪرڻ لاءِ، توھان کي بيان ۽ ڪجھ نحو شامل ڪرڻ جي ضرورت آھي، جيئن مٿي ڏنل سلائڊ ۾. ASCII ۾ اهو هن طرح نظر ايندو:
جئين توهان ڏسي سگهو ٿا، ڪجھ به پيچيده ناهي. TLA + جي وضاحت کي جانچي سگھجي ٿو، يعني ھڪڙي ننڍڙي نموني ۾ سڀني ممڪن رويي کي نظرانداز ڪريو. اسان جي صورت ۾، هن نموني ڪجهه قدر ٿي ويندي M и N. هي هڪ تمام ڪارائتو ۽ سادو تصديق جو طريقو آهي جيڪو مڪمل طور تي خودڪار آهي. اهو پڻ ممڪن آهي ته رسمي سچائي ثبوت لکڻ ۽ انهن کي مشيني طور تي چيڪ ڪريو، پر اهو گهڻو وقت وٺندو آهي، تنهنڪري تقريبا ڪو به اهو نٿو ڪري.
TLA + جو بنيادي نقصان اهو آهي ته اهو رياضي آهي، ۽ پروگرامر ۽ ڪمپيوٽر سائنسدان رياضي کان ڊڄندا آهن. پهرين نظر ۾، هي آواز هڪ مذاق وانگر آهي، پر، بدقسمتي سان، منهنجو مطلب اهو آهي ته تمام سنجيده ۾. منهنجو ساٿي صرف مون کي ٻڌائي رهيو هو ته هن ڪيئن TLA + ڪيترن ئي ڊولپرز کي وضاحت ڪرڻ جي ڪوشش ڪئي. جيئن ئي فارمولا اسڪرين تي ظاهر ٿيا، اهي فوري طور تي شيشي جون اکيون بڻجي ويون. تنهن ڪري جيڪڏهن TLA + توهان کي خوفزده ڪري، توهان استعمال ڪري سگهو ٿا ، اها هڪ قسم جي رانديڪن جي پروگرامنگ ٻولي آهي. PlusCal ۾ هڪ اظهار ڪنهن به TLA+ اظهار ٿي سگهي ٿو، اهو آهي، وڏي ۽ وڏي، ڪنهن به رياضياتي اظهار. ان کان علاوه، PlusCal غير مقرراتي الگورتھم لاء ھڪڙو نحو آھي. ڇاڪاڻ ته PlusCal ڪنهن به TLA + اظهار کي لکي سگهي ٿو، PlusCal ڪنهن به حقيقي پروگرامنگ ٻولي کان وڌيڪ اظهار ڪندڙ آهي. اڳيون، PlusCal هڪ آسان پڙهڻ واري TLA + وضاحتن ۾ مرتب ڪيو ويو آهي. هن جو مطلب اهو نه آهي، يقينا، ته پيچيده پلس ڪل جي وضاحت TLA + تي هڪ سادي ۾ تبديل ٿي ويندي - صرف انهن جي وچ ۾ رابطي واضح آهي، اتي ڪا اضافي پيچيدگي نه هوندي. آخرڪار، هن وضاحت جي تصديق ڪري سگهجي ٿي TLA + اوزار. مجموعي طور تي، PlusCal رياضي فوبيا کي ختم ڪرڻ ۾ مدد ڪري سگهي ٿو ۽ پروگرامرز ۽ ڪمپيوٽر سائنسدانن لاء پڻ سمجهڻ آسان آهي. ماضي ۾، مون ان تي ڪجهه وقت (اٽڪل 10 سال) لاء الگورتھم شايع ڪيو.
شايد ڪو اعتراض ڪندو ته TLA + ۽ PlusCal رياضيات آهن، ۽ رياضي صرف ايجاد ڪيل مثالن تي ڪم ڪري ٿي. عملي طور تي، توهان کي هڪ حقيقي ٻولي جي ضرورت آهي قسمن، طريقيڪار، شيون، وغيره سان. هي غلط آهي. هتي اهو آهي جيڪو ڪرس نيوڪومب، جيڪو Amazon تي ڪم ڪيو، لکي ٿو: "اسان TLA + ڏهن وڏن منصوبن تي استعمال ڪيو آهي، ۽ هر صورت ۾، ان جي استعمال سان ترقي ۾ هڪ اهم فرق آيو آهي ڇاڪاڻ ته اسان پيداوار کي مارڻ کان اڳ خطرناڪ ڪيچ کي پڪڙڻ جي قابل هئاسين، ۽ ڇاڪاڻ ته اهو اسان کي بصيرت ۽ اعتماد ڏنو جنهن جي اسان کي ضرورت هئي. پروگرام جي سچائي کي متاثر ڪرڻ کان سواءِ جارحانه ڪارڪردگي بهتر بڻائڻ“. توهان اڪثر ٻڌي سگهو ٿا ته جڏهن رسمي طريقا استعمال ڪندي، اسان کي غير موثر ڪوڊ ملي ٿو - عملي طور تي، هر شيء بلڪل سامهون آهي. ان کان علاوه، اتي هڪ راء آهي ته مينيجرز کي رسمي طريقن جي ضرورت تي قائل نه ٿو ڪري سگهجي، جيتوڻيڪ پروگرامر انهن جي فائدي جي قائل آهن. ۽ Newcomb لکي ٿو: "منيجر هاڻي سخت زور ڏئي رهيا آهن TLA + لاءِ وضاحتون لکڻ لاءِ، ۽ خاص طور تي ان لاءِ وقت مختص ڪريو". تنهن ڪري جڏهن مينيجر ڏسندا آهن ته TLA + ڪم ڪري رهيو آهي، اهي ان کي قبول ڪرڻ ۾ خوش آهن. Chris Newcomb اهو اٽڪل ڇهه مهينا اڳ لکيو هو (آڪٽوبر 2014)، پر هاڻي، جيتري قدر مون کي خبر آهي، TLA+ 14 منصوبن ۾ استعمال ٿئي ٿو، 10 نه. ٻيو مثال XBox 360 جي ڊيزائن ۾ آهي. هڪ انٽر چارلس ٿاڪر وٽ آيو ۽ ميموري سسٽم لاء تفصيل لکيو. ھن وضاحت جي مھرباني، ھڪڙو بگ مليو جيڪو ٻي صورت ۾ نظر نه ايندو، ۽ جنھن جي ڪري ھر XBox 360 چار ڪلاڪن جي استعمال کان پوء خراب ٿي ويندو. IBM انجنيئرن تصديق ڪئي ته سندن ٽيسٽن ۾ اهو بگ نه مليو هوندو.
توهان انٽرنيٽ تي TLA + بابت وڌيڪ پڙهي سگهو ٿا، پر هاڻي اچو ته غير رسمي وضاحتن بابت ڳالهايون. اسان کي گهٽ ۾ گهٽ پروگرام لکڻا پوندا آهن جيڪي حساب ڪن ٿا گهٽ ۾ گهٽ عام تقسيم ڪندڙ ۽ جهڙو. گهڻو ڪري اسان پروگرام لکندا آهيون جهڙوڪ خوبصورت-پرنٽر ٽول جيڪو مون TLA+ لاءِ لکيو هو. آسان ترين پروسيسنگ کان پوء، TLA + ڪوڊ هن طرح نظر ايندو:
پر مٿين مثال ۾، صارف گهڻو ڪري چاهي ٿو ته ڪنجوڪشن ۽ برابر نشانيون ترتيب ڏنل هجن. تنهنڪري صحيح فارميٽنگ هن طرح وڌيڪ نظر ايندي:
اچو ته هڪ ٻيو مثال غور ڪريو.
هتي، ان جي برعڪس، ماخذ ۾ برابر، اضافي، ۽ ضرب جي نشانين جي ترتيب بي ترتيب هئي، تنهنڪري آسان پروسيسنگ ڪافي آهي. عام طور تي، صحيح فارميٽنگ جي ڪا به صحيح رياضياتي وصف نه آهي، ڇاڪاڻ ته هن معاملي ۾ "صحيح" جو مطلب آهي "جيڪو صارف چاهي ٿو"، ۽ اهو رياضياتي طور تي طئي نٿو ڪري سگهجي.
اهو لڳي ٿو ته جيڪڏهن اسان وٽ سچ جي تعريف نه آهي، پوء وضاحت بيڪار آهي. پر اهو ناهي. صرف ان ڪري جو اسان کي خبر ناهي ته هڪ پروگرام ڇا ڪرڻ گهرجي، ان جو مطلب اهو ناهي ته اسان کي اهو سوچڻ جي ضرورت ناهي ته اهو ڪيئن ڪم ڪري ٿو- ان جي برعڪس، اسان کي ان ۾ اڃا به وڌيڪ ڪوششون ڪرڻ گهرجن. وضاحت خاص طور تي هتي اهم آهي. ترتيب ڏنل ڇپائيءَ لاءِ مناسب پروگرام جو تعين ڪرڻ ناممڪن آهي، پر ان جو مطلب اهو نه آهي ته اسان کي ان کي هرگز نه وٺڻ گهرجي، ۽ شعور جي وهڪري طور ڪوڊ لکڻ ڪا سٺي ڳالهه ناهي. آخر ۾، مون ڇهن قاعدن جي وضاحت سان وضاحت ڪئي تبصرن جي صورت ۾ java فائل ۾. هتي ضابطن مان هڪ جو هڪ مثال آهي: a left-comment token is LeftComment aligned with its covering token. هي قاعدو ان ۾ لکيل آهي، ڇا اسين چئون، رياضياتي انگريزي: LeftComment aligned, left-comment и covering token - اصطلاحن سان وصف. هن ريت رياضي دان رياضي کي بيان ڪن ٿا: اهي اصطلاحن جي وصف لکن ٿا ۽ انهن جي بنياد تي، ضابطا. اهڙي وضاحت جو فائدو اهو آهي ته ڇهه ضابطا سمجھڻ ۽ ڊيبگ ڪرڻ لاءِ 850 لائنن جي ڪوڊ کان وڌيڪ آسان آهن. مون کي ضرور چوڻ گهرجي ته اهي قاعدا لکڻ آسان نه هئا، انهن کي ڊيب ڪرڻ لاء ڪافي وقت ورتو. خاص طور تي هن مقصد لاء، مون هڪ ڪوڊ لکيو جنهن ۾ ٻڌايو ويو آهي ته ڪهڙو قاعدو استعمال ڪيو ويو آهي. انهي حقيقت جي مهرباني ته مون انهن ڇهن قاعدن کي ڪيترن ئي مثالن تي آزمايو، مون کي ڪوڊ جي 850 لائنن کي ڊيبگ ڪرڻ جي ضرورت نه هئي، ۽ ڪيچ ڳولڻ بلڪل آسان ٿي ويا. جاوا وٽ ان لاءِ بهترين اوزار آهن. جيڪڏهن مان صرف ڪوڊ لکان ها، ته اهو مون کي گهڻو وقت وٺي ها، ۽ فارميٽنگ خراب معيار جي هجي ها.
باضابطه وضاحت ڇو نه ٿي سگهي؟ هڪ پاسي، صحيح عمل هتي تمام ضروري ناهي. ساختي پرنٽ آئوٽ ڪنهن کي به خوش نه ڪرڻ لاءِ پابند هوندا آهن، تنهنڪري مون کي ان کي حاصل ڪرڻ جي ضرورت نه هئي ته سڀني غير معمولي حالتن ۾ صحيح ڪم ڪري. اڃا به وڌيڪ اهم حقيقت اها آهي ته مون وٽ مناسب اوزار نه هئا. TLA + ماڊل چيڪ ڪندڙ هتي بيڪار آهي، تنهنڪري مون کي دستي طور مثال لکڻو پوندو.
مٿين وضاحتن ۾ خاصيتون آهن جيڪي سڀني وضاحتن لاءِ عام آهن. اهو ڪوڊ کان اعلي سطحي آهي. اهو ڪنهن به ٻوليء ۾ لاڳو ڪري سگهجي ٿو. ان کي لکڻ لاءِ ڪي به اوزار يا طريقا بيڪار آهن. ڪو به پروگرامنگ ڪورس توهان کي هن وضاحت لکڻ ۾ مدد نه ڪندو. ۽ اهڙا اوزار نه آهن جيڪي هن وضاحت کي غير ضروري بڻائي سگهن، جيستائين، يقينا، توهان هڪ ٻولي لکي رهيا آهيو خاص طور تي TLA + ۾ منظم پرنٽ پروگرام لکڻ لاءِ. آخرڪار، هي تفصيل ڪجھ به نه ٿو چوي ته اسان ڪوڊ ڪيئن لکنداسين، اهو صرف ٻڌائي ٿو ته هي ڪوڊ ڇا ڪندو آهي. اسان ڪوڊ بابت سوچڻ شروع ڪرڻ کان اڳ اسان کي مسئلي جي ذريعي سوچڻ ۾ مدد ڏيڻ لاء وضاحتون لکندا آهيون.
پر ھن وضاحت ۾ پڻ خاصيتون آھن جيڪي ان کي ٻين وضاحتن کان ڌار ڪن ٿيون. 95٪ ٻين چشمي جا خاص طور تي ننڍا ۽ آسان آهن:
وڌيڪ، هي وضاحت ضابطن جو هڪ سيٽ آهي. ضابطي جي طور تي، هي غريب وضاحت جي نشاني آهي. قاعدن جي ھڪڙي سيٽ جي نتيجن کي سمجھڻ ڪافي ڏکيو آھي، جنھن ڪري مون کي انھن کي ڊيبگ ڪرڻ ۾ گھڻو وقت گذارڻو پيو. بهرحال، هن معاملي ۾، مون کي بهتر رستو نه ڳولي سگهي.
اهو پروگرامن جي باري ۾ چند لفظ چوڻ جي قابل آهي جيڪي مسلسل هلن ٿا. ضابطي جي طور تي، اهي متوازي ۾ ڪم ڪن ٿا، مثال طور، آپريٽنگ سسٽم يا ورهايل سسٽم. تمام ٿورا ماڻهو انهن کي ذهني طور تي يا ڪاغذ تي سمجهي سگهن ٿا، ۽ مان انهن مان نه آهيان، جيتوڻيڪ مان هڪ ڀيرو اهو ڪرڻ جي قابل هو. تنهن ڪري، اسان کي اوزارن جي ضرورت آهي جيڪي اسان جي ڪم جي جانچ ڪندا - مثال طور، TLA + يا PlusCal.
اها وضاحت ڇو ضروري هئي جيڪڏهن مون کي اڳ ۾ ئي خبر هئي ته ڪوڊ کي ڇا ڪرڻ گهرجي؟ حقيقت ۾، مون سوچيو ته مون کي خبر آهي. اضافي طور تي، هڪ وضاحت سان، هڪ ٻاهرين کي هاڻي ڪوڊ ۾ وڃڻ جي ضرورت ناهي ته هو ڇا ڪري ٿو. مون وٽ هڪ قاعدو آهي: ڪو به عام قاعدو نه هجڻ گهرجي. هن قاعدي ۾ هڪ استثنا آهي، يقينا، اهو صرف هڪ عام اصول آهي جنهن جي آئون پيروي ڪريان ٿو: ڪوڊ جيڪو ڪري ٿو ان جي وضاحت ماڻهن کي هر شي کي ٻڌائڻ گهرجي انهن کي ڄاڻڻ جي ضرورت آهي جڏهن ڪوڊ استعمال ڪندي.
پوء ڇا واقعي پروگرامرز کي سوچڻ بابت ڄاڻڻ جي ضرورت آهي؟ شروعاتن لاءِ، ساڳيءَ طرح ٻين سڀني وانگر: جيڪڏهن توهان نٿا لکو، ته اهو صرف توهان کي لڳي ٿو ته توهان سوچيو ٿا. انهي سان گڏ، توهان کي ڪوڊ ڪرڻ کان پهريان سوچڻ جي ضرورت آهي، جنهن جو مطلب آهي ته توهان کي ڪوڊ ڪرڻ کان پهريان لکڻ جي ضرورت آهي. وضاحت اها آهي جيڪا اسان ڪوڊنگ شروع ڪرڻ کان پهريان لکندا آهيون. ڪنهن به ڪوڊ لاءِ هڪ وضاحت گهربل آهي جيڪا هر ڪنهن طرفان استعمال يا تبديل ڪري سگهجي ٿي. ۽ اهو "ڪو" شايد ڪوڊ جو ليکڪ پاڻ هڪ مهيني کان پوء لکيو ويو آهي. وڏي پروگرامن ۽ سسٽم لاءِ، ڪلاسن لاءِ، طريقن لاءِ، ۽ ڪڏهن ڪڏهن هڪ طريقي جي پيچيده حصن لاءِ به هڪ وضاحت جي ضرورت هوندي آهي. ڪوڊ بابت ڇا لکڻ گهرجي؟ توهان کي اهو بيان ڪرڻ جي ضرورت آهي ته اهو ڇا ڪري ٿو، اهو آهي، جيڪو هن ڪوڊ استعمال ڪندي ڪنهن به شخص لاء ڪارائتو ٿي سگهي ٿو. ڪڏهن ڪڏهن اهو به ضروري ٿي سگهي ٿو ته وضاحت ڪجي ته ڪوڊ ڪيئن پنهنجو مقصد پورو ڪري ٿو. جيڪڏهن اسان هن طريقي سان الورورٿم جي دور ۾ ويا آهيون، ته پوء اسان ان کي هڪ الگورتھم سڏين ٿا. جيڪڏهن اهو ڪجهه وڌيڪ خاص ۽ نئون آهي، ته پوء اسان ان کي اعلي سطحي ڊيزائن سڏين ٿا. هتي ڪو به رسمي فرق ناهي: ٻئي هڪ پروگرام جو هڪ خلاصو ماڊل آهن.
توهان کي هڪ ڪوڊ وضاحت ڪيئن لکڻ گهرجي؟ مکيه شيء: ان کي ڪوڊ پاڻ کان هڪ سطح اعلي هجڻ گهرجي. اهو رياستن ۽ رويي کي بيان ڪرڻ گهرجي. اهو سخت هجڻ گهرجي جيئن ڪم جي ضرورت آهي. جيڪڏهن توهان هڪ وضاحت لکي رهيا آهيو ته هڪ ڪم کي ڪيئن لاڳو ڪيو وڃي، توهان ان کي pseudocode يا PlusCal سان لکي سگهو ٿا. توهان کي سکڻ جي ضرورت آهي ته ڪيئن لکجي وضاحتن تي رسمي وضاحتن تي. هي توهان کي لازمي صلاحيتون ڏيندو جيڪي توهان جي مدد ڪنديون غير رسمي سان گڏ. رسمي وضاحتون لکڻ ڪيئن سکندا؟ جڏهن اسان پروگرام ڪرڻ سکيو، اسان پروگرام لکيا ۽ پوء انهن کي ڊيبگ ڪيو. اهو هتي ساڳيو آهي: وضاحت لکو، ان کي ماڊل چيڪ ڪندڙ سان چيڪ ڪريو، ۽ ڪيچ کي درست ڪريو. TLA+ ٿي سگھي ٿي بھترين ٻولي رسمي وضاحت لاءِ، ۽ ٻي ٻولي توھان جي مخصوص ضرورتن لاءِ بھتر ٿي سگھي ٿي. TLA + جو فائدو اهو آهي ته اهو رياضياتي سوچ کي تمام سٺو سيکاريندو آهي.
وضاحت ۽ ڪوڊ ڪيئن ڳنڍجي؟ تبصرن جي مدد سان جيڪي ڳنڍيندا آهن رياضياتي تصورات ۽ انهن تي عمل درآمد. جيڪڏهن توهان گراف سان ڪم ڪريو ٿا، ته پوءِ پروگرام جي سطح تي توهان وٽ نوڊس جا صفا ۽ لنڪ جون صفون هونديون. تنهن ڪري، توهان کي لکڻ جي ضرورت آهي ته ڪيئن گراف انهن پروگرامنگ ڍانچي پاران لاڳو ڪيو ويو آهي.
اهو ياد رکڻ گهرجي ته مٿين مان ڪو به ڪوڊ لکڻ جي حقيقي عمل تي لاڳو نٿو ٿئي. جڏهن توهان ڪوڊ لکندا آهيو، اهو آهي، توهان ٽيون قدم انجام ڏيو ٿا، توهان کي پروگرام ذريعي سوچڻ ۽ سوچڻ جي ضرورت آهي. جيڪڏهن هڪ ذيلي ٽاسڪ پيچيده يا غير واضح طور تي ظاهر ٿئي ٿو، توهان کي ان لاء هڪ وضاحت لکڻ جي ضرورت آهي. پر مان هتي ڪوڊ بابت نه ڳالهائي رهيو آهيان. توهان ڪنهن به پروگرامنگ ٻولي استعمال ڪري سگهو ٿا، ڪنهن به طريقي سان، اهو انهن جي باري ۾ ناهي. انهي سان گڏ، مٿين مان ڪو به ڪوڊ ٽيسٽ ۽ ڊيبگ ڪرڻ جي ضرورت کي ختم نٿو ڪري. جيتوڻيڪ خلاصو ماڊل صحيح طور تي لکيو ويو آهي، اتي ان جي عمل ۾ ڪيگ هوندا.
لکڻ جي وضاحت ڪوڊنگ جي عمل ۾ هڪ اضافي قدم آهي. ان جي مهرباني، گهٽ ڪوشش سان ڪيتريون ئي غلطيون پڪڙي سگهجن ٿيون - اسان اهو ڄاڻون ٿا Amazon کان پروگرامرز جي تجربن مان. وضاحتن سان، پروگرامن جو معيار اعلي ٿي ويندو آهي. پوء ڇو، پوء، اسين اڪثر ڪري انهن کان سواء وڃون ٿا؟ ڇاڪاڻ ته لکڻ مشڪل آهي. ۽ لکڻ ڏکيو آهي، ڇو ته ان لاءِ سوچڻ جي ضرورت آهي، ۽ سوچڻ به مشڪل آهي. اهو هميشه آسان آهي انهي کي ظاهر ڪرڻ جيڪو توهان سوچيو ٿا. هتي توهان ڊوڙڻ سان هڪ تشبيهه ٺاهي سگهو ٿا - توهان جيترو گهٽ ڊوڙندا اوترو سست. توهان کي پنهنجي عضلات کي تربيت ڏيڻ ۽ لکڻ جي مشق ڪرڻ جي ضرورت آهي. مشق جي ضرورت آهي.
وضاحت غلط ٿي سگھي ٿي. ٿي سگھي ٿو توھان ڪنھن جاءِ تي ڪا غلطي ڪئي ھجي، يا ضرورتون بدلجي ويون ھجن، يا ڪنھن سڌاري جي ضرورت ٿي سگھي ٿي. ڪو به ڪوڊ جيڪو هر ڪنهن کي استعمال ڪندو آهي ان کي تبديل ڪرڻو پوندو، تنهنڪري جلدي يا بعد ۾ وضاحت هاڻي پروگرام سان نه ملندي. مثالي طور، هن حالت ۾، توهان کي هڪ نئين وضاحت لکڻ جي ضرورت آهي ۽ مڪمل طور تي ڪوڊ ٻيهر لکڻو پوندو. اسان چڱي ريت ڄاڻون ٿا ته ڪو به اهو نه ڪندو. عملي طور تي، اسان ڪوڊ پيچ ڪيو ۽ ممڪن طور تي تفصيل کي اپڊيٽ ڪيو. جيڪڏهن اهو جلد يا دير سان ٿيڻو آهي، ته پوءِ وضاحتون ڇو لکجي؟ پهرين، ان شخص لاءِ جيڪو توهان جي ڪوڊ کي ايڊٽ ڪندو، تفصيل ۾ هر اضافي لفظ ان جي وزن ۾ سون جي برابر هوندو، ۽ اهو شخص شايد توهان پاڻ ئي هجي. مان اڪثر ڪري پاڻ کي ڪافي وضاحت حاصل نه ڪرڻ لاءِ ماتم ڪندو آهيان جڏهن مان پنهنجو ڪوڊ ايڊٽ ڪري رهيو آهيان. ۽ مان ڪوڊ کان وڌيڪ وضاحتون لکندو آهيان. تنهن ڪري، جڏهن توهان ڪوڊ ۾ ترميم ڪريو ٿا، وضاحتن کي هميشه اپڊيٽ ڪرڻ جي ضرورت آهي. ٻيو، هر نظر ثاني سان، ڪوڊ خراب ٿي ويندو آهي، اهو وڌيڪ ۽ وڌيڪ پڙهڻ ۽ برقرار رکڻ ڏکيو ٿيندو. هي اينٽروپي ۾ اضافو آهي. پر جيڪڏهن توهان ڪنهن مخصوص انداز سان شروع نه ڪيو، ته پوءِ توهان جي لکندڙ هر لڪير ۾ ترميم ٿيندي، ۽ ڪوڊ شروع کان پڙهڻ لاءِ اڻ وڻندڙ ۽ مشڪل هوندو.
جيئن چيو , ڪا به جنگ منصوبابنديءَ سان نه کٽي وئي، ۽ ڪا به جنگ بغير رٿابنديءَ جي نه کٽي وئي. ۽ هو جنگين جي باري ۾ هڪ يا ٻه شيء ڄاڻي ٿو. هڪ راءِ آهي ته وضاحتون لکڻ وقت جو ضايع آهي. ڪڏهن ڪڏهن اهو سچ آهي، ۽ ڪم ايترو سادو آهي ته ان جي ذريعي سوچڻ لاء ڪجھ به ناهي. پر توهان کي هميشه ياد رکڻ گهرجي ته جڏهن توهان کي چيو ويندو آهي ته وضاحتون نه لکو، توهان کي چيو وڃي ٿو ته نه سوچيو. ۽ توهان کي هر وقت سوچڻ گهرجي. ڪم جي ذريعي سوچڻ جي ضمانت نه آهي ته توهان غلطي نه ڪندا. جيئن ته اسان ڄاڻون ٿا، ڪنهن به جادو جي ڇنڊ ڇاڻ نه ڪئي، ۽ پروگرامنگ هڪ ڏکيو ڪم آهي. پر جيڪڏهن توهان مسئلي جي ذريعي نه سوچيو، توهان کي غلطي ڪرڻ جي ضمانت ڏني وئي آهي.
توهان هڪ خاص ويب سائيٽ تي TLA + ۽ PlusCal بابت وڌيڪ پڙهي سگهو ٿا، توهان اتي وڃي سگهو ٿا منهنجي هوم پيج تان . اهو سڀ ڪجهه مون لاءِ آهي، توهان جي توجه جي مهرباني.
مهرباني ڪري نوٽ ڪريو ته هي ترجمو آهي. جڏهن توهان رايا لکندا آهيو، ياد رکو ته ليکڪ انهن کي نه پڙهي سگهندو. جيڪڏهن توهان واقعي ليکڪ سان ڳالهائڻ چاهيو ٿا، ته پوء هو هائڊرا 2019 ڪانفرنس ۾ هوندو، جيڪو 11-12 جولاء، 2019 سينٽ پيٽرسبرگ ۾ منعقد ٿيندو. ٽڪيٽون خريد ڪري سگھجن ٿيون .
جو ذريعو: www.habr.com