دا مقاله ژباړه ده . مګر د هغې لږ پیژندنه مخکې. زومبی څنګه جوړیږي؟ هرڅوک داسې وضعیت ته رسیدلی چیرې چې دوی غواړي یو ملګری یا همکار د دوی کچې ته ورسوي، مګر دا کار نه کوي. او دا ستاسو سره دومره نده لکه د هغه سره چې "دا کار نه کوي": د پیمانې له یوې خوا عادي معاش ، دندې او داسې نور دي ، او له بلې خوا د فکر کولو اړتیا. فکر کول ناخوښ او دردناک دي. هغه په چټکۍ سره تسلیمیږي او د کوډ لیکلو ته دوام ورکوي پرته لدې چې خپل مغز فعال کړي. تاسو تصور کوئ چې د زده کړې بې وسۍ خنډ لرې کولو لپاره څومره هڅې کیږي، او تاسو یوازې دا نه کوئ. دا څنګه زومبی رامینځته کیږي ، کوم چې داسې بریښي ، درملنه کیدی شي ، مګر داسې بریښي چې هیڅوک به یې ونه کړي.
کله چې ما ولیدل (هو، د درسي کتابونو څخه ورته ملګری) او راپور نه جوړوي، مګر د پوښتنې او ځواب غونډه، زه یو څه محتاط وم. یوازې په دې حالت کې، لیسلي د نړۍ مشهور ساینس پوه دی، په ویشل شوي کمپیوټر کې د بنسټیزو کارونو لیکوال دی، او تاسو کولی شئ هغه د LaTeX - "Lamport TeX" په کلمه کې د La تورو په واسطه وپیژنئ. دوهم خطرناک عامل د هغه غوښتنه ده: هرڅوک چې راځي (بلکل وړیا) باید خپل یو څو راپورونه مخکې له مخکې واوري، لږ تر لږه یوه پوښتنه ورسره وکړي، او یوازې بیا راشي. ما پریکړه وکړه چې وګورم چې لامپورټ هلته څه خپروي - او دا خورا ښه دی! دا واقعیا هغه شی دی ، د زومبی درملنې لپاره د جادو لینک ګولۍ. زه تاسو ته خبرداری درکوم: له متن څخه ، د عالي انعطاف وړ میتودونو مینه وال او هغه څوک چې د لیکل شوي ازموینې ازموینه نه خوښوي د پام وړ سوځیدلی شي.
د حبروکات وروسته، په حقیقت کې، د سیمینار ژباړه پیل کیږي. له لوستلو خوند واخلئ!
هر هغه کار چې تاسو یې کوئ، تاسو باید تل د دریو مرحلو څخه تیر شئ:
- پریکړه وکړئ چې تاسو کوم هدف ترلاسه کول غواړئ؛
- پریکړه وکړئ چې تاسو به څنګه خپل هدف ترلاسه کړئ؛
- خپل هدف ته ورسیږئ.
دا د پروګرام کولو لپاره هم تطبیق کیږي. کله چې موږ کوډ لیکو، موږ اړتیا لرو:
- پریکړه وکړئ چې برنامه باید څه وکړي؛
- دا معلومه کړئ چې څنګه باید خپله دنده ترسره کړي؛
- ورته کوډ ولیکئ.
وروستی ګام، البته، خورا مهم دی، مګر زه به نن ورځ په دې اړه خبرې ونه کړم. پرځای یې، موږ به په لومړیو دوو بحث وکړو. هر پروګرامر د کار پیل کولو دمخه دوی ترسره کوي. تاسو د لیکلو لپاره ناست نه یاست تر هغه چې تاسو پریکړه نه وي کړې چې ایا تاسو براوزر یا ډیټابیس لیکئ. د هدف یو مشخص نظر باید موجود وي. او تاسو حتما فکر کوئ چې واقعیا برنامه به څه وکړي ، او په دې هیله مه لیکئ چې کوډ به یو څه په براوزر بدل شي.
د دې کوډ دمخه فکر څنګه واقع کیږي؟ په دې برخه کې باید څومره هڅې وکړو؟ دا ټول پدې پورې اړه لري چې موږ څومره پیچلې ستونزه حل کوو. فرض کړئ چې موږ د غلطۍ زغملو ویشل شوي سیسټم لیکل غواړو. پدې حالت کې، موږ باید مخکې له دې چې کوډ ته کښینو شیان په دقت سره فکر وکړو. څه که موږ یوازې د 1 لخوا د عدد متغیر زیاتولو ته اړتیا لرو؟ په لومړي نظر کې، دلته هرڅه کوچني دي، او هیڅ فکر ته اړتیا نشته، مګر بیا موږ په یاد لرو چې یو ډیر جریان واقع کیدی شي. له همدې امله، حتی د دې لپاره چې پوه شي چې ستونزه ساده ده یا پیچلې، تاسو باید لومړی فکر وکړئ.
که تاسو مخکې له مخکې د ستونزې د ممکنه حل په اړه فکر کوئ، تاسو کولی شئ د غلطیو څخه مخنیوی وکړئ. مګر دا اړتیا لري چې ستاسو فکر روښانه وي. د دې ترلاسه کولو لپاره، تاسو اړتیا لرئ خپل فکرونه ولیکئ. زه واقعیا د ډیک ګینډن وینا خوښوم: "کله چې تاسو لیکئ ، طبیعت تاسو ته ښیې چې ستاسو فکر څومره خراب دی." که تاسو نه لیکئ، تاسو یوازې فکر کوئ چې تاسو فکر کوئ. او تاسو اړتیا لرئ خپل فکرونه د توضیحاتو په بڼه ولیکئ.
مشخصات ډیری دندې ترسره کوي ، په ځانګړي توګه په لویو پروژو کې. مګر زه به یوازې د دوی په اړه وغږیږم: دوی موږ سره په روښانه توګه فکر کولو کې مرسته کوي. په روښانه توګه فکر کول خورا مهم او خورا ستونزمن دي، نو دلته موږ هر ډول مرستې ته اړتیا لرو. په کومه ژبه باید مشخصات ولیکو؟ په عموم کې، دا تل د پروګرام کونکو لپاره لومړۍ پوښتنه ده: موږ به په کومه ژبه کې لیکو. د دې لپاره هیڅ یو سم ځواب نشته: هغه ستونزې چې موږ یې حل کوو خورا متفاوت دي. د ځینو لپاره، TLA + د ځانګړتیا ژبه ده چې ما وده کړې. د نورو لپاره، دا د چینایي کارولو لپاره خورا اسانه دی. هر څه په وضعیت پورې اړه لري.
بله مهمه پوښتنه دا ده: څنګه روښانه فکر ترلاسه کړو؟ ځواب: موږ باید د ساینس پوهانو په څیر فکر وکړو. دا د فکر کولو یوه لاره ده چې په تیرو 500 کلونو کې یې ځان ثابت کړی دی. په ساینس کې، موږ د واقعیت ریاضياتي ماډلونه جوړوو. ستورپوهنه شاید د کلمې په سخت مفهوم کې لومړی ساینس و. په ستورپوهنه کې کارول شوي ریاضياتي ماډل کې، آسماني اجسام د ډله ایز، موقعیت او سرعت سره د نقطو په توګه ښکاري، که څه هم په حقیقت کې دا خورا پیچلي شیان دي چې د غرونو او بحرونو، لندونو او لندونو سره دي. دا ماډل، د نورو په څیر، د ځینو ستونزو د حل لپاره رامینځته شوی. دا د ټاکلو لپاره خورا ښه دی چې د ټیلسکوپ چیرته په نښه کړئ که تاسو اړتیا لرئ سیارې ومومئ. مګر که تاسو غواړئ د دې سیارې هوا وړاندوینه وکړئ، دا ماډل به کار ونکړي.
ریاضي موږ ته اجازه راکوي چې د ماډل ځانګړتیاوې وټاکو. او ساینس ښیې چې دا ملکیتونه څنګه له واقعیت سره تړاو لري. راځئ چې زموږ د ساینس، کمپیوټر ساینس په اړه خبرې وکړو. هغه حقیقت چې موږ ورسره کار کوو د مختلفو ډولونو کمپیوټري سیسټمونه دي: پروسیسرونه، د لوبې کنسولونه، کمپیوټرونه، د پروګرامونو اجرا کول، او داسې نور. زه به په کمپیوټر کې د برنامه چلولو په اړه وغږیږم ، مګر په لویه کچه دا ټولې پایلې په هر کمپیوټري سیسټم کې پلي کیږي. زموږ په ساینس کې، موږ ډیری بیلابیل ماډلونه کاروو: د تورینګ ماشین، د پیښو جزوی ترتیب شوي سیټونه، او ډیری نور.
یو پروګرام څه شی دی؟ دا کوم کوډ دی چې په خپلواکه توګه په پام کې نیول کیدی شي. فرض کړئ چې موږ یو براوزر لیکلو ته اړتیا لرو. موږ درې دندې ترسره کوو: موږ د برنامه کارونکي لید ډیزاین کوو ، بیا موږ د برنامه لوړې کچې ډیاګرام لیکو ، او په پای کې موږ کوډ لیکو. لکه څنګه چې موږ کوډ لیکو، موږ پوهیږو چې موږ د متن بڼه لیکلو ته اړتیا لرو. دلته موږ بیا د دریو ستونزو حل کولو ته اړتیا لرو: دا معلومه کړئ چې دا وسیله به کوم متن بیرته راولي؛ د فارمیټ کولو لپاره الګوریتم غوره کړئ؛ کوډ ولیکئ. دا دنده خپل فرعي دنده لري: په سمه توګه په کلمو کې هایفین داخل کړئ. موږ دا فرعي ټاسک هم په دریو مرحلو کې حل کوو - لکه څنګه چې تاسو لیدلی شئ ، دوی په ډیری کچو تکرار شوي.
راځئ چې لومړی ګام په ډیر تفصیل سره په پام کې ونیسو: کومه ستونزه چې برنامه حل کوي. دلته، موږ ډیری وختونه یو پروګرام د فنکشن په توګه ماډل کوو چې یو څه ان پټ اخلي او یو څه محصول تولیدوي. په ریاضیاتو کې، یو فعالیت معمولا د ترتیب شوي جوړه جوړه په توګه تشریح کیږي. د مثال په توګه، د طبیعي شمیرو لپاره د مربع کولو فعالیت د سیټ په توګه بیان شوی دی {<0,0>, <1,1>, <2,4>, <3,9>, …}. د داسې فعالیت ډومین د هرې جوړې د لومړي عناصرو سیټ دی، دا طبیعي شمیرې دي. د یو فنکشن تعریف کولو لپاره، موږ باید د هغې ساحه او فورمول مشخص کړو.
مګر په ریاضیاتو کې دندې د پروګرامینګ ژبو افعالاتو په څیر ندي. ریاضی خورا اسانه دی. څرنګه چې زه د پیچلو مثالونو لپاره وخت نلرم، راځئ چې یو ساده په پام کې ونیسو: په C کې یو فنکشن یا په جاوا کې یو جامد میتود چې د دوو عددونو ترټولو لوی عام ویش بیرته راولي. د دې طریقې په توضیح کې، موږ به ولیکئ: محاسبه GCD(M,N) د دلیلونو لپاره M и Nچیرته GCD(M,N) - یو فنکشن چې ډومین یې د عددونو جوړه جوړه ده، او د بیرته ستنیدو ارزښت ترټولو لوی عدد دی چې د ویشلو وړ دی M и N. دا ماډل د واقعیت سره څنګه تړاو لري؟ ماډل په انټیجرونو کار کوي، پداسې حال کې چې په C یا جاوا کې موږ 32-bit لرو int. دا ماډل موږ ته اجازه راکوي چې پریکړه وکړو چې آیا الګوریتم سم دی GCD، مګر دا به د ډیریدو غلطیو مخه ونه نیسي. دا به ډیر پیچلي ماډل ته اړتیا ولري، د کوم لپاره چې هیڅ وخت شتون نلري.
راځئ چې د ماډل په توګه د فعالیت محدودیتونو په اړه وغږیږو. ځینې پروګرامونه (لکه عملیاتي سیسټمونه) یوازې د ځانګړو دلیلونو لپاره یو ټاکلی ارزښت بیرته نه راوړي، دوی کولی شي په دوامداره توګه پرمخ بوځي. برسېره پردې، د ماډل په توګه فعالیت د دویم ګام لپاره مناسب نه دی: د ستونزې حل کولو څرنګوالي پالن کول. ګړندي ترتیب او بلبل ترتیب ورته فعالیت محاسبه کوي ، مګر دا په بشپړ ډول مختلف الګوریتمونه دي. له همدې امله، د دې تشریح کولو لپاره چې د پروګرام هدف څنګه ترلاسه کیږي، زه یو بل ماډل کاروم، راځئ چې دا د معیاري چلند ماډل ووایو. په دې کې برنامه د ټولو اجازه وړ چلندونو سیټ په توګه ښودل کیږي ، چې هر یو یې په بدل کې د دولتونو ترتیب دی ، او دولت متغیرونو ته د ارزښتونو دنده ده.
راځئ وګورو چې د Euclid الګوریتم لپاره دوهم ګام به څه ډول ښکاري. موږ باید حساب وکړو 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 نوی ارزښت ترلاسه کوو. په دوهم حالت کې، موږ برعکس کوو.
راځئ چې بیرته د Euclid الګوریتم ته لاړ شو. راځئ چې بیا دا فرض کړو 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'، کوم چې د راتلونکي دولت سره اړیکه ریښتیني کوي. په بل عبارت، د یوکلید الګوریتم ټاکونکی دی. د غیر متضاد الګوریتم ماډل کولو لپاره، اوسنی حالت باید ډیری احتمالي راتلونکي حالتونه ولري، او دا چې هر یو بې بنسټه متغیر ارزښت څو اصلي متغیر ارزښتونه لري لکه د راتلونکي حالت سره تړاو لري. دا کار کول اسانه دي، مګر زه به اوس مثالونه نه ورکوم.
د کار کولو وسیله جوړولو لپاره، تاسو رسمي ریاضي ته اړتیا لرئ. څنګه مشخصات رسمي کړئ؟ د دې کولو لپاره، موږ رسمي ژبې ته اړتیا لرو، د بیلګې په توګه، . د یوکلیډ الګوریتم مشخصات به په دې ژبه کې داسې ښکاري:
د مثلث سره د مساوي نښه نښه پدې معنی ده چې د نښو کیڼ اړخ ته ارزښت د نښه ښي اړخ ته د ارزښت سره مساوي تعریف شوی. په اصل کې، مشخصات یو تعریف دی، زموږ په قضیه کې دوه تعریفونه. په TLA+ کې مشخصاتو ته، تاسو اړتیا لرئ اعالمیه او ځینې نحو اضافه کړئ، لکه څنګه چې پورته سلایډ کې. په ASCII کې دا به داسې ښکاري:
لکه څنګه چې تاسو لیدلی شئ، هیڅ شی پیچلي ندي. د TLA + لپاره توضیحات ازمول کیدی شي ، د بیلګې په توګه په کوچني ماډل کې ټول ممکنه چلندونه پریږدئ. زموږ په قضیه کې، دا ماډل به ځینې ارزښتونه وي M и N. دا یو خورا اغیزمن او ساده تایید میتود دی چې په بشپړ ډول اتومات دی. دا هم ممکنه ده چې رسمي ریښتیني ثبوتونه ولیکئ او په میخانیکي ډول یې چیک کړئ، مګر دا ډیر وخت نیسي، نو نږدې هیڅوک دا کار نه کوي.
د TLA + اصلي زیان دا دی چې دا ریاضی دی، او پروګرامونکي او کمپیوټر ساینس پوهان د ریاضی څخه ویره لري. په لومړي نظر کې، دا د ټوکې په څیر ښکاري، مګر، له بده مرغه، زه دا په ټول جدي توګه معنی لرم. زما همکار یوازې ما ته ویل چې څنګه یې هڅه وکړه څو څو پراختیا کونکو ته TLA + تشریح کړي. هرڅومره ژر چې فورمولونه په سکرین کې راښکاره شول ، دوی سمدلاسه د سترګو شیشې شوې. نو که TLA + تاسو ویروي، تاسو یې کارولی شئ دا د لوبو پروګرام کولو ژبه ده. په PlusCal کې څرګندونه کیدی شي هر ډول TLA + بیان وي، دا په لویه کچه، هر ډول ریاضيیک بیان دی. برسېره پردې، PlusCal د غیر متمرکز الګوریتمونو لپاره ترکیب لري. ځکه چې PlusCal کولی شي هر ډول TLA + بیان ولیکي، PlusCal د هرې ریښتینې برنامې ژبې په پرتله خورا څرګند دی. بیا، PlusCal په اسانۍ سره د لوستلو وړ TLA + مشخصاتو کې ترتیب شوی. البته دا پدې معنی ندي چې د پلسکال پیچلي توضیحات به په TLA + کې په ساده ډول بدل شي - یوازې د دوی ترمینځ اړیکه څرګنده ده ، هیڅ اضافي پیچلتیا به شتون ونلري. په نهایت کې ، دا توضیحات د TLA + وسیلو لخوا تایید کیدی شي. په ټوله کې، PlusCal کولی شي د ریاضی فوبیا له منځه وړلو کې مرسته وکړي او حتی د پروګرام کونکو او کمپیوټر ساینس پوهانو لپاره پوهیدل اسانه دي. په تیرو کې، ما د یو څه وخت لپاره (شاوخوا 10 کاله) په اړه الګوریتم خپور کړ.
شاید یو څوک اعتراض وکړي چې TLA + او PlusCal ریاضي دي، او ریاضي یوازې په اختراع شویو مثالونو کار کوي. په عمل کې، تاسو د ډولونو، طرزالعملونو، شیانو او داسې نورو سره ریښتینې ژبې ته اړتیا لرئ. دا غلط دی. دلته هغه څه دي چې کریس نیوکومب، چې په ایمیزون کې کار کاوه، لیکي: "موږ په لسو لویو پروژو کې TLA + کارولي دي، او په هره قضیه کې، د دې کارولو په پراختیا کې د پام وړ بدلون راوستی دی ځکه چې موږ د تولید له پیل څخه مخکې خطرناکه کیګونه نیولي وو، او ځکه چې دا موږ ته هغه بصیرت او باور راکړ چې موږ ورته اړتیا درلوده. پرته له دې چې د برنامه ریښتیا اغیزه وکړي د تیري کونکي فعالیت اصلاح کول". تاسو ډیری وختونه اوریدلی شئ چې د رسمي میتودونو په کارولو سره، موږ غیر موثر کوډ ترلاسه کوو - په عمل کې، هرڅه په سمه توګه مخالف دي. سربیره پردې، داسې نظر شتون لري چې مدیران نشي کولی د رسمي میتودونو اړتیا باندې قانع شي، حتی که پروګرام کونکي د دوی په ګټورتوب قانع وي. او نیوکومب لیکي: "منیجر اوس د TLA + لپاره مشخصات لیکلو لپاره سخت فشار راوړي، او په ځانګړې توګه د دې لپاره وخت تخصیص کوي". نو کله چې مدیران وګوري چې TLA + کار کوي، دوی خوښ دي چې دا ومني. کریس نیوکومب دا شاوخوا شپږ میاشتې مخکې (اکتوبر 2014) لیکلی و، مګر اوس، تر هغه چې زه پوهیږم، TLA + په 14 پروژو کې کارول کیږي، نه په 10. بله بیلګه د XBox 360 ډیزاین کې دی. یو انټرن چارلس تاکر ته راغلی او د حافظې سیسټم لپاره توضیحات لیکلي. د دې ځانګړتیاو څخه مننه، یو بګ وموندل شو چې بل ډول به یې پام نه وي، او د دې له امله هر XBox 360 به د څلورو ساعتونو کارولو وروسته خراب شي. د IBM انجینرانو تایید کړه چې د دوی ازموینې به دا بګ ونه موندل شي.
تاسو کولی شئ په انټرنیټ کې د TLA + په اړه نور ولولئ، مګر اوس راځئ چې د غیر رسمي مشخصاتو په اړه وغږیږو. موږ په ندرت سره باید داسې برنامې ولرو چې لږترلږه عام تقسیم کونکي او ورته ورته حساب کړي. ډیری وختونه موږ پروګرامونه لیکو لکه د ښکلي چاپګر وسیله چې ما د TLA + لپاره لیکلي. د ساده پروسس کولو وروسته، د TLA + کوډ به داسې ښکاري:
مګر په پورتني مثال کې، کاروونکي ډیری احتمال غوښتل چې یووالی او مساوي نښې سره سمون ولري. نو سمه بڼه به داسې ښکاري:
راځئ چې یو بل مثال په پام کې ونیسو:
دلته، برعکس، په سرچینه کې د مساوي، اضافه، او ضرب نښو سمون تصادفي و، نو ساده پروسس کول کافي دي. په عموم کې، د سم فارمیټ کولو لپاره هیڅ دقیق ریاضياتي تعریف شتون نلري، ځکه چې "سمه" پدې حالت کې معنی لري "هغه څه چې کاروونکي یې غواړي"، او دا په ریاضياتي توګه نشي ټاکل کیدی.
داسې ښکاري چې که موږ د حقیقت تعریف ونه لرو، نو بیا توضیحات بې ګټې دي. خو داسې نه ده. یوازې د دې لپاره چې موږ نه پوهیږو چې برنامه باید څه وکړي پدې معنی ندي چې موږ اړتیا نلرو فکر وکړو چې دا څنګه کار کوي - برعکس ، موږ باید پدې کې لا ډیرې هڅې وکړو. مشخصات دلته په ځانګړې توګه مهم دي. د جوړښت شوي چاپ لپاره د غوره برنامه ټاکل ناممکن دي ، مګر دا پدې معنی ندي چې موږ باید دا په کلکه ونه ونیسو ، او د شعور د جریان په توګه د کوډ لیکل ښه شی ندي. په پای کې، ما د تعریفونو سره د شپږو قواعدو توضیحات ولیکل د تبصرو په بڼه په جاوا فایل کې. دلته د قواعدو څخه یو مثال دی: a left-comment token is LeftComment aligned with its covering token. دا قاعده په ریاضي انګلیسي کې لیکل شوې ده، ایا موږ ووایو: LeftComment aligned, left-comment и covering token - د تعریف سره شرایط. دا څنګه ریاضي پوهان ریاضي تشریح کوي: دوی د شرایطو تعریفونه لیکي او د دوی پر بنسټ قواعد. د داسې مشخصاتو ګټه دا ده چې شپږ قواعد د 850 کوډ لینونو په پرتله د پوهیدو او ډیبګ کولو لپاره خورا اسانه دي. زه باید ووایم چې د دې قواعدو لیکل اسانه ندي ، د دوی د ډیبګ کولو لپاره خورا ډیر وخت نیولی. په ځانګړې توګه د دې هدف لپاره، ما یو کوډ لیکلی چې راپور ورکړی چې کوم قاعده کارول شوې وه. د دې حقیقت څخه مننه چې ما دا شپږ قواعد په څو مثالونو کې ازمول ، ما د کوډ 850 لینونو ډیبګ کولو ته اړتیا نه درلوده ، او کیګونه موندل خورا اسانه و. جاوا د دې لپاره عالي وسیلې لري. که ما یوازې کوډ لیکلی وای ، نو دا به ما ډیر وخت نیولی و ، او فارمیټ به د ضعیف کیفیت درلود.
ولې رسمي مشخصات ونه کارول شي؟ له یوې خوا، سم اجرا کول دلته خورا مهم ندي. ساختماني چاپونه د دې لپاره پابند دي چې هیڅوک خوښ نه کړي، نو زه اړتیا نه لرم چې دا په ټولو عجیبو حالاتو کې سم کار وکړي. حتی ډیر مهم حقیقت دا دی چې زه کافي وسایل نه لرم. د TLA + ماډل چیکر دلته بې ګټې دی، نو زه باید په لاسي ډول مثالونه ولیکم.
پورته مشخصات د ټولو ځانګړتیاو لپاره عام ځانګړتیاوې لري. دا د کوډ په پرتله لوړه کچه ده. دا په هره ژبه کې پلي کیدی شي. د لیکلو لپاره هر ډول وسایل یا میتودونه بې ګټې دي. د برنامه کولو هیڅ کورس به تاسو سره د دې توضیحاتو لیکلو کې مرسته ونه کړي. او هیڅ داسې وسیلې شتون نلري چې دا توضیحات غیر ضروري کړي ، پرته لدې چې تاسو په TLA + کې د جوړښت شوي چاپ برنامې لیکلو لپاره په ځانګړي ډول ژبه لیکئ. په نهایت کې ، دا توضیحات په دقیق ډول پدې اړه څه نه وايي چې موږ به کوډ څنګه لیکو ، دا یوازې دا څرګندوي چې دا کوډ څه کوي. موږ توضیحات لیکو ترڅو موږ سره د ستونزې په اړه فکر کولو کې مرسته وکړي مخکې لدې چې موږ د کوډ په اړه فکر پیل کړو.
مګر دا ځانګړتیاوې هم لري چې دا د نورو ځانګړتیاو څخه توپیر کوي. 95٪ نور مشخصات د پام وړ لنډ او ساده دي:
برسېره پردې، دا مشخصات د قواعدو یوه ټولګه ده. د یوې قاعدې په توګه، دا د ضعیف ځانګړتیا نښه ده. د یو لړ مقرراتو د پایلو پوهیدل خورا ستونزمن دي، له همدې امله ما باید د دوی په ډیبګ کولو کې ډیر وخت تیر کړ. په هرصورت، پدې حالت کې، زه نشم کولی غوره لاره ومومم.
دا د پروګرامونو په اړه یو څو کلمې ویلو ارزښت لري چې په دوامداره توګه پرمخ ځي. د یوې قاعدې په توګه، دوی په موازي توګه کار کوي، د بیلګې په توګه، عملیاتي سیسټمونه یا ویشل شوي سیسټمونه. ډیر لږ خلک کولی شي دوی په ذهني یا کاغذ باندې پوه کړي، او زه د دوی څخه نه یم، که څه هم ما یو ځل دا توان درلود. له همدې امله، موږ وسایلو ته اړتیا لرو چې زموږ کار وګوري - د بیلګې په توګه، TLA + یا PlusCal.
ولې د توضیحاتو لیکلو ته اړتیا وه که زه دمخه پوهیدم چې واقعیا کوډ باید څه وکړي؟ په حقیقت کې، ما یوازې فکر کاوه چې زه پوهیږم. سربیره پردې ، د توضیحاتو سره ، یو بهرنی نور اړتیا نلري کوډ ته ننوځي ترڅو پوه شي چې هغه واقعیا څه کوي. زه یو قاعده لرم: هیڅ عمومي قواعد شتون نلري. په دې قاعده کې یو استثنا شتون لري، البته، دا یوازینی عمومي قاعده ده چې زه یې تعقیبوم: د هغه څه مشخصات چې کوډ یې کوي باید خلکو ته هر هغه څه ووایي چې دوی ورته اړتیا لري د کوډ کارولو په وخت کې پوه شي.
نو په ریښتیا څه پروګرام کونکي باید د فکر کولو په اړه پوه شي؟ د پیل لپاره، د هرچا په څیر: که تاسو نه لیکئ، نو دا یوازې تاسو ته ښکاري چې تاسو فکر کوئ. همچنان ، تاسو اړتیا لرئ د کوډ کولو دمخه فکر وکړئ ، پدې معنی چې تاسو اړتیا لرئ د کوډ کولو دمخه ولیکئ. مشخصات هغه څه دي چې موږ یې د کوډ کولو پیل کولو دمخه لیکو. د هر کوډ لپاره مشخصاتو ته اړتیا ده چې د هرچا لخوا کارول یا ترمیم کیدی شي. او دا "څوک" ممکن د دې لیکلو یوه میاشت وروسته پخپله د کوډ لیکوال وي. د لویو پروګرامونو او سیسټمونو لپاره، د ټولګیو لپاره، د میتودونو لپاره، او ځینې وختونه حتی د یو واحد میتود پیچلو برخو لپاره مشخصاتو ته اړتیا ده. په ریښتیا باید د کوډ په اړه څه ولیکل شي؟ تاسو اړتیا لرئ تشریح کړئ چې دا څه کوي، دا د دې کوډ کارولو هر چا لپاره څه ګټور کیدی شي. ځینې وختونه ممکن دا هم اړین وي چې مشخص کړئ چې کوډ څنګه خپل هدف سرته رسوي. که موږ د الګوریتم په جریان کې له دې میتود څخه تیر شو ، نو موږ ورته الګوریتم وایو. که دا یو څه ډیر ځانګړی او نوی وي، نو موږ ورته د لوړې کچې ډیزاین وایو. دلته هیڅ رسمي توپیر شتون نلري: دواړه د برنامه خلاص ماډل دي.
تاسو باید د کوډ مشخصات څنګه ولیکئ؟ اصلي شی: دا باید د کوډ په پرتله یوه کچه لوړه وي. دا باید دولتونه او چلندونه تشریح کړي. دا باید هغومره سخت وي څومره چې دنده ورته اړتیا لري. که تاسو د دې لپاره توضیحات ولیکئ چې څنګه یو کار پلي کیږي ، تاسو کولی شئ دا په سیډوکوډ یا پلس کیل کې ولیکئ. تاسو اړتیا لرئ چې په رسمي مشخصاتو کې د مشخصاتو لیکلو څرنګوالي زده کړئ. دا به تاسو ته اړین مهارتونه درکړي چې تاسو سره به په غیر رسمي توګه هم مرسته وکړي. تاسو د رسمي مشخصاتو لیکل څنګه زده کوئ؟ کله چې موږ برنامه زده کړه، موږ پروګرامونه لیکلي او بیا یې ډیبګ کړل. دا دلته ورته دی: مشخصات ولیکئ، د ماډل چیکر سره یې وګورئ، او کیګونه حل کړئ. TLA + ممکن د رسمي توضیحاتو لپاره غوره ژبه نه وي، او بله ژبه ممکن ستاسو د ځانګړو اړتیاو لپاره غوره وي. د TLA + ګټه دا ده چې دا د ریاضیاتو فکر خورا ښه تدریس کوي.
څنګه مشخصات او کوډ لینک کړئ؟ د نظرونو په مرسته چې د ریاضيکي مفکورې او د دوی پلي کولو سره اړیکه لري. که تاسو د ګرافونو سره کار کوئ، نو د پروګرام په کچه به تاسو د نوډونو سرې او د لینکونو سرې ولرئ. له همدې امله ، تاسو اړتیا لرئ دقیقا ولیکئ چې ګراف د دې برنامې جوړښتونو لخوا پلي کیږي.
دا باید په یاد ولرئ چې د پورته څخه هیڅ یو د کوډ لیکلو اصلي پروسې باندې نه پلي کیږي. کله چې تاسو کوډ ولیکئ، دا دی، تاسو دریم ګام ترسره کوئ، تاسو هم د پروګرام له لارې فکر او فکر کولو ته اړتیا لرئ. که یو فرعي ټاسک پیچلي یا غیر څرګند وي ، نو تاسو اړتیا لرئ د دې لپاره توضیحات ولیکئ. مګر زه دلته پخپله د کوډ په اړه خبرې نه کوم. تاسو کولی شئ د پروګرام کولو کومه ژبه وکاروئ، کوم میتودولوژي، دا د دوی په اړه ندي. همچنان ، له پورته څخه هیڅ یو د کوډ ازموینې او ډیبګ اړتیا له مینځه وړي. حتی که لنډیز موډل په سمه توګه لیکل شوی وي، ممکن د هغې په پلي کولو کې ستونزې شتون ولري.
د مشخصاتو لیکل د کوډ کولو پروسې کې یو اضافي ګام دی. د دې څخه مننه، ډیری غلطی د لږې هڅې سره نیول کیدی شي - موږ دا د ایمیزون څخه د پروګرام کونکو تجربو څخه پوهیږو. د ځانګړتیاوو سره، د برنامو کیفیت لوړیږي. نو بیا ولې موږ ډیری وختونه له دوی پرته ځو؟ ځکه لیکل سخت دي. او لیکل ستونزمن دي، ځکه چې د دې لپاره تاسو فکر کولو ته اړتیا لرئ، او فکر کول هم ستونزمن دي. دا تل اسانه ده چې د هغه څه نمایش وکړئ چې تاسو فکر کوئ. دلته تاسو کولی شئ د چلولو سره مشابهت جوړ کړئ - څومره چې تاسو لږ منډه کوئ، هومره ورو ورو. تاسو اړتیا لرئ خپل عضلات وروزئ او د لیکلو تمرین وکړئ. تمرین ته اړتیا لري.
توضیحات ممکن غلط وي. تاسو ممکن په کوم ځای کې تېروتنه کړې وي، یا اړتیاوې بدل شوي وي، یا ممکن یو ښه والی ته اړتیا وي. هر کوډ چې هرڅوک یې کاروي باید بدل شي، نو ژر یا وروسته مشخصات به نور د برنامه سره سمون ونلري. په عین حال کې، پدې حالت کې، تاسو اړتیا لرئ یو نوی توضیحات ولیکئ او په بشپړ ډول کوډ بیا ولیکئ. موږ ښه پوهیږو چې هیڅوک دا کار نه کوي. په عمل کې، موږ کوډ پیچ کوو او احتمالي توضیحات تازه کوو. که دا ژر یا وروسته پیښ شي ، نو بیا ولې مشخصات په بشپړ ډول ولیکئ؟ لومړی، د هغه چا لپاره چې ستاسو کوډ ایډیټ کوي، په مشخصاتو کې هره اضافي کلمه به د سرو زرو وزن ولري، او دا سړی ممکن تاسو پخپله وي. زه ډیری وختونه خپل ځان ته د کافي توضیحاتو ترلاسه کولو له امله بخښنه کوم کله چې زه خپل کوډ ترمیم کوم. او زه د کوډ په پرتله ډیر مشخصات لیکم. له همدې امله، کله چې تاسو کوډ ایډیټ کړئ، مشخصات تل باید تازه شي. دوهم، د هرې بیاکتنې سره، کوډ خرابیږي، دا د لوستلو او ساتلو لپاره خورا ستونزمن کیږي. دا د انټروپي زیاتوالی دی. مګر که تاسو د یوې اندازې سره پیل نه کړئ، نو هره کرښه چې تاسو یې لیکئ سمون به وي، او کوډ به د پیل څخه لوستل ستونزمن او ستونزمن وي.
لکه څنګه چې وویل , هیڅ جګړه د پلان له مخې نه ده ګټل شوې، او هیڅ جګړه د پلان پرته نه ده ګټل شوې. او هغه د جنګونو په اړه یو یا دوه شیان پوهیدل. داسې نظر شتون لري چې د ځانګړتیاوو لیکل د وخت ضایع کول دي. ځینې وختونه دا ریښتیا وي، او دنده دومره ساده ده چې د هغې له لارې فکر کولو لپاره هیڅ شی شتون نلري. مګر تاسو باید تل په یاد ولرئ کله چې تاسو ته ویل کیږي چې مشخصات مه لیکئ ، تاسو ته ویل کیږي چې فکر مه کوئ. او تاسو باید هر وخت د هغې په اړه فکر وکړئ. د دندې په اړه فکر کول تضمین نه کوي چې تاسو به غلطي ونه کړئ. لکه څنګه چې موږ پوهیږو، هیڅوک د جادو ویښت اختراع نه کوي، او پروګرام کول یو ستونزمن کار دی. مګر که تاسو د ستونزې له لارې فکر نه کوئ، تاسو تضمین یاست چې غلطي وکړئ.
تاسو کولی شئ د TLA + او PlusCal په اړه نور په ځانګړي ویب پاڼه کې ولولئ، تاسو کولی شئ هلته زما د کور پاڼې څخه لاړ شئ . دا ټول زما لپاره دي، ستاسو د پاملرنې لپاره مننه.
مهرباني وکړئ په یاد ولرئ چې دا یوه ژباړه ده. کله چې تاسو نظرونه لیکئ، په یاد ولرئ چې لیکوال به یې نه لولي. که تاسو رښتیا غواړئ له لیکوال سره خبرې وکړئ، نو هغه به د هایډرا 2019 په کنفرانس کې وي، چې د جولای په 11-12، 2019 کې به په سینټ پیټرزبورګ کې ترسره شي. ټکټونه اخیستل کیدی شي .
سرچینه: www.habr.com