یہ ایک ترجمہ مضمون ہے۔ . لیکن اس سے پہلے ایک مختصر تعارف ہے۔ زومبی کیسے بنتے ہیں؟ ہر ایک نے اپنے آپ کو ایسی صورتحال میں پایا ہے جہاں وہ کسی دوست یا ساتھی کو اپنی سطح پر لانا چاہتے ہیں، لیکن یہ کام نہیں کرتا ہے۔ اس کے علاوہ، "یہ کام نہیں کرتا" آپ کے لئے اتنا نہیں ہے، لیکن اس کے لئے: پیمانے کے ایک طرف عام تنخواہ، کام، اور اسی طرح، اور دوسری طرف سوچنے کی ضرورت ہے. سوچنا ناگوار اور تکلیف دہ ہے۔ وہ جلدی سے ہار مان لیتا ہے اور اپنے دماغ کا استعمال کیے بغیر کوڈ لکھنا جاری رکھتا ہے۔ آپ کو احساس ہے کہ سیکھی ہوئی بے بسی کی رکاوٹ کو دور کرنے کے لیے کتنی محنت درکار ہوتی ہے، اور آپ ایسا نہیں کرتے۔ اس طرح زومبی بنتے ہیں جن کا علاج ممکن نظر آتا ہے لیکن ایسا لگتا ہے کہ ایسا کوئی نہیں کرے گا۔
جب میں نے دیکھا (ہاں، درسی کتابوں سے وہی دوست) اور رپورٹ نہیں دے رہا ہے بلکہ سوال و جواب کا سیشن ہے، میں تھوڑا محتاط تھا۔ صرف اس صورت میں، لیسلی ایک عالمی شہرت یافتہ سائنسدان ہے، جو تقسیم شدہ کمپیوٹنگ میں بنیادی کاموں کے مصنف ہیں، اور آپ اسے LaTeX - "Lamport TeX" کے حروف سے بھی جان سکتے ہیں۔ دوسرا تشویشناک عنصر اس کی ضرورت ہے: ہر آنے والے کو چاہیے کہ (مکمل طور پر مفت) اس کی چند رپورٹس پہلے سے سنیں، ان کے بارے میں کم از کم ایک سوال کے ساتھ آئیں، اور تب ہی آئیں۔ میں نے یہ دیکھنے کا فیصلہ کیا کہ لیمپورٹ وہاں کیا نشر کر رہا ہے - اور یہ بہت اچھا ہے! یہ بالکل وہی چیز ہے، زومبی کے علاج کے لیے ایک جادو لنک گولی۔ میں آپ کو متنبہ کرتا ہوں: متن ان لوگوں کو سنجیدگی سے جلا سکتا ہے جو انتہائی چست طریقہ کار کو پسند کرتے ہیں اور جو اپنی تحریر کی جانچ کرنا پسند نہیں کرتے ہیں۔
حبروکات کے بعد اصل میں سیمینار کا ترجمہ شروع ہوتا ہے۔ پڑھنے سے لطف اندوز!
آپ جو بھی کام کرتے ہیں، آپ کو ہمیشہ تین مراحل سے گزرنا پڑتا ہے:
- فیصلہ کریں کہ آپ کون سا مقصد حاصل کرنا چاہتے ہیں؛
- فیصلہ کریں کہ آپ اپنے مقصد کو کس طرح حاصل کریں گے۔
- اپنے مقصد تک پہنچیں.
یہ پروگرامنگ پر بھی لاگو ہوتا ہے۔ جب ہم کوڈ لکھتے ہیں، ہمیں ضرورت ہوتی ہے:
- فیصلہ کریں کہ پروگرام کو بالکل کیا کرنا چاہیے؛
- بالکل اس بات کا تعین کریں کہ اسے اپنا کام کیسے انجام دینا چاہئے؛
- مناسب کوڈ لکھیں.
آخری مرحلہ یقیناً بہت اہم ہے، لیکن میں آج اس پر بات نہیں کروں گا۔ اس کے بجائے، ہم پہلے دو پر بات کریں گے۔ ہر پروگرامر کام شروع کرنے سے پہلے انہیں انجام دیتا ہے۔ آپ لکھنے کے لیے نہیں بیٹھتے جب تک کہ آپ یہ فیصلہ نہ کر لیں کہ آپ کیا لکھ رہے ہیں: ایک براؤزر یا ڈیٹا بیس۔ مقصد کا ایک خاص خیال موجود ہونا چاہیے۔ اور آپ یقینی طور پر اس کے بارے میں سوچتے ہیں کہ پروگرام بالکل کیا کرے گا، اور اس امید کے ساتھ اسے بے ترتیبی سے نہ لکھیں کہ کوڈ خود ہی کسی نہ کسی طرح براؤزر میں بدل جائے گا۔
کوڈ کے بارے میں یہ پہلے سے سوچنا بالکل کیسے ہوتا ہے؟ ہمیں اس میں کتنی محنت کرنی چاہیے؟ یہ سب اس بات پر منحصر ہے کہ ہم کس قدر پیچیدہ مسئلے کو حل کر رہے ہیں۔ ہم کہتے ہیں کہ ہم ایک غلطی برداشت کرنے والا تقسیم شدہ نظام لکھنا چاہتے ہیں۔ اس صورت میں، ہمیں کوڈ پر بیٹھنے سے پہلے چیزوں کو احتیاط سے سوچنا چاہیے۔ کیا ہوگا اگر ہمیں صرف ایک عدد متغیر کو 1 سے بڑھانے کی ضرورت ہے؟ پہلی نظر میں، یہاں سب کچھ معمولی ہے اور کسی سوچ کی ضرورت نہیں ہے، لیکن پھر ہمیں یاد ہے کہ ایک بہاؤ ہوسکتا ہے. اس لیے، یہ سمجھنے کے لیے کہ کوئی مسئلہ سادہ ہے یا پیچیدہ، آپ کو پہلے سوچنے کی ضرورت ہے۔
اگر آپ کسی مسئلے کے ممکنہ حل کے بارے میں پہلے سے سوچتے ہیں، تو آپ غلطیوں سے بچ سکتے ہیں۔ لیکن اس کے لیے آپ کی سوچ کا واضح ہونا ضروری ہے۔ اس کو حاصل کرنے کے لیے، آپ کو اپنے خیالات لکھنے کی ضرورت ہے۔ مجھے ڈک گائنڈن کا اقتباس پسند ہے: "جب آپ لکھتے ہیں تو فطرت آپ کو دکھاتی ہے کہ آپ کی سوچ کتنی میلی ہے۔" اگر آپ نہیں لکھتے تو آپ صرف سوچتے ہیں کہ آپ سوچ رہے ہیں۔ اور آپ کو اپنے خیالات کو وضاحتی شکل میں لکھنے کی ضرورت ہے۔
نردجیکرن بہت سے کام انجام دیتے ہیں، خاص طور پر بڑے منصوبوں میں۔ لیکن میں ان میں سے صرف ایک کے بارے میں بات کروں گا: وہ واضح طور پر سوچنے میں ہماری مدد کرتے ہیں۔ واضح طور پر سوچنا بہت اہم اور کافی مشکل ہے، اس لیے ہمیں یہاں کسی بھی مدد کی ضرورت ہے۔ ہمیں وضاحتیں کس زبان میں لکھنی چاہئیں؟ عام طور پر، پروگرامرز کے لیے یہ ہمیشہ پہلا سوال ہوتا ہے: ہم کس زبان میں لکھیں گے؟ کوئی بھی درست جواب نہیں ہے: جو مسائل ہم حل کرتے ہیں وہ بہت متنوع ہیں۔ کچھ لوگوں کے لیے، TLA+ ایک وضاحتی زبان ہے جسے میں نے تیار کیا ہے۔ دوسروں کے لیے چینی استعمال کرنا زیادہ آسان ہے۔ یہ سب صورتحال پر منحصر ہے۔
زیادہ اہم سوال یہ ہے کہ: ہم واضح سوچ کیسے حاصل کر سکتے ہیں؟ جواب: ہمیں سائنسدانوں کی طرح سوچنا چاہیے۔ یہ سوچنے کا ایک طریقہ ہے جس نے پچھلے 500 سالوں میں اچھا کام کیا ہے۔ سائنس میں ہم حقیقت کے ریاضیاتی ماڈل بناتے ہیں۔ فلکیات شاید لفظ کے سخت معنوں میں پہلی سائنس تھی۔ فلکیات میں استعمال ہونے والے ریاضیاتی ماڈل میں، آسمانی اجسام کمیت، پوزیشن اور رفتار کے ساتھ پوائنٹس کے طور پر ظاہر ہوتے ہیں، حالانکہ حقیقت میں یہ پہاڑوں اور سمندروں، آبشاروں اور بہاؤ کے ساتھ انتہائی پیچیدہ اشیاء ہیں۔ یہ ماڈل، کسی دوسرے کی طرح، بعض مسائل کو حل کرنے کے لئے بنایا گیا تھا. اگر آپ کسی سیارے کو تلاش کرنا چاہتے ہیں تو دوربین کو کہاں اشارہ کرنا ہے اس کا تعین کرنے کے لئے یہ بہت اچھا ہے۔ لیکن اگر آپ اس سیارے پر موسم کی پیشین گوئی کرنا چاہتے ہیں تو یہ ماڈل کام نہیں کرے گا۔
ریاضی ہمیں ماڈل کی خصوصیات کا تعین کرنے کی اجازت دیتی ہے۔ اور سائنس بتاتی ہے کہ ان خصوصیات کا حقیقت سے کیا تعلق ہے۔ آئیے اپنی سائنس، کمپیوٹر سائنس کی بات کرتے ہیں۔ حقیقت جس کے ساتھ ہم کام کرتے ہیں وہ بہت سی مختلف اقسام کے کمپیوٹنگ سسٹمز ہیں: پروسیسرز، گیم کنسولز، کمپیوٹرز جو پروگرام چلاتے ہیں، وغیرہ۔ میں کمپیوٹر پر کسی پروگرام کو چلانے کے بارے میں بات کروں گا، لیکن بڑے پیمانے پر، یہ تمام نتائج کسی بھی کمپیوٹنگ سسٹم پر لاگو ہوتے ہیں۔ ہماری سائنس میں ہم بہت سے مختلف ماڈل استعمال کرتے ہیں: ٹورنگ مشین، جزوی طور پر ترتیب شدہ واقعات کے سیٹ، اور بہت سے دوسرے۔
پروگرام کیا ہے؟ یہ کوئی بھی کوڈ ہے جس پر خود غور کیا جاسکتا ہے۔ ہم کہتے ہیں کہ ہمیں براؤزر لکھنے کی ضرورت ہے۔ ہم تین کام انجام دیتے ہیں: پروگرام کی صارف کی پیشکش کو ڈیزائن کریں، پھر پروگرام کا اعلیٰ سطحی خاکہ لکھیں، اور آخر میں کوڈ لکھیں۔ جیسا کہ ہم کوڈ لکھتے ہیں، ہمیں احساس ہوتا ہے کہ ہمیں ٹیکسٹ فارمیٹر لکھنے کی ضرورت ہے۔ یہاں ایک بار پھر ہمیں تین مسائل حل کرنے کی ضرورت ہے: اس بات کا تعین کریں کہ یہ ٹول کون سا متن واپس آئے گا۔ فارمیٹنگ کے لیے الگورتھم کا انتخاب کریں؛ کوڈ لکھیں. اس کام کا اپنا ذیلی کام ہے: الفاظ میں صحیح طریقے سے ہائفن داخل کرنا۔ ہم اس ذیلی کام کو بھی تین مراحل میں حل کرتے ہیں - جیسا کہ ہم دیکھتے ہیں، وہ کئی سطحوں پر دہرائے جاتے ہیں۔
آئیے پہلے مرحلے پر گہری نظر ڈالیں: پروگرام کون سا مسئلہ حل کرتا ہے۔ یہاں ہم اکثر ایک پروگرام کو ایک فنکشن کے طور پر ماڈل کرتے ہیں جو کچھ ان پٹ لیتا ہے اور کچھ آؤٹ پٹ دیتا ہے۔ ریاضی میں، ایک فنکشن کو عام طور پر جوڑوں کے ترتیب شدہ سیٹ کے طور پر بیان کیا جاتا ہے۔ مثال کے طور پر، فطری نمبروں کے لیے اسکوائرنگ فنکشن کو سیٹ {<0,0>, <1,1>, <2,4>, <3,9>, …} کے طور پر بیان کیا گیا ہے۔ اس طرح کے فنکشن کی تعریف کا ڈومین ہر جوڑے کے پہلے عناصر کا مجموعہ ہے، یعنی قدرتی اعداد۔ کسی فنکشن کی وضاحت کرنے کے لیے، ہمیں اس کے ڈومین اور فارمولے کی وضاحت کرنے کی ضرورت ہے۔
لیکن ریاضی میں افعال پروگرامنگ زبانوں کے افعال کی طرح نہیں ہوتے ہیں۔ ریاضی بہت آسان ہے۔ چونکہ میرے پاس پیچیدہ مثالوں کے لیے وقت نہیں ہے، آئیے ایک سادہ پر غور کریں: C میں ایک فنکشن یا جاوا میں ایک جامد طریقہ جو دو عدد کے سب سے بڑے مشترک تقسیم کو لوٹاتا ہے۔ اس طریقہ کار کی وضاحت میں ہم لکھیں گے: calculates GCD(M,N) دلائل کے لیے M и Nجہاں GCD(M,N) - ایک فنکشن جس کا ڈومین انٹیجرز کے جوڑوں کا ایک سیٹ ہے، اور واپسی کی قیمت سب سے بڑا عدد ہے جسے تقسیم کیا جاتا ہے M и N. حقیقت اس ماڈل سے کیسے موازنہ کرتی ہے؟ ماڈل انٹیجرز کے ساتھ کام کرتا ہے، اور C یا جاوا میں ہمارے پاس 32 بٹ ہے۔ int. یہ ماڈل ہمیں یہ فیصلہ کرنے کی اجازت دیتا ہے کہ آیا الگورتھم درست ہے۔ GCD، لیکن یہ اوور فلو کی غلطیوں کو نہیں روکے گا۔ اس کے لیے زیادہ پیچیدہ ماڈل کی ضرورت ہوگی، جس کے لیے کوئی وقت نہیں ہے۔
آئیے ایک ماڈل کے طور پر فنکشن کی حدود کے بارے میں بات کرتے ہیں۔ کچھ پروگرام (جیسے آپریٹنگ سسٹم) بعض دلائل کے لیے صرف ایک خاص قدر واپس نہیں کرتے؛ وہ مسلسل چل سکتے ہیں۔ اس کے علاوہ، ماڈل کے طور پر فنکشن دوسرے مرحلے کے لیے ناقص طور پر موزوں ہے: مسئلہ کو حل کرنے کے طریقے کی منصوبہ بندی کرنا۔ Quicksort اور bubble sort ایک ہی فنکشن کی گنتی کرتے ہیں، لیکن وہ بالکل مختلف الگورتھم ہیں۔ لہذا، پروگرام کے مقصد کو حاصل کرنے کا طریقہ بیان کرنے کے لیے، میں ایک اور ماڈل استعمال کرتا ہوں، آئیے اسے معیاری طرز عمل کا ماڈل کہتے ہیں۔ پروگرام کو اس میں تمام درست رویوں کے ایک سیٹ کے طور پر پیش کیا گیا ہے، جن میں سے ہر ایک، بدلے میں، ریاستوں کا ایک سلسلہ ہے، اور ایک ریاست متغیرات کو اقدار کی تفویض ہے۔
آئیے دیکھتے ہیں کہ یوکلیڈین الگورتھم کا دوسرا مرحلہ کیسا نظر آئے گا۔ ہمیں حساب دینا ہوگا۔ 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 صرف ایک ابتدائی حالت ہے. اگلی ریاست کے ساتھ تعلق کو ایک فارمولے سے بیان کیا جاتا ہے جس میں اگلی ریاست کے متغیرات کو پرائم کے ساتھ لکھا جاتا ہے، اور موجودہ حالت کے متغیرات کو پرائم کے بغیر لکھا جاتا ہے۔ یوکلیڈین الگورتھم کے معاملے میں، ہم دو فارمولوں کے منقطع ہونے کا معاملہ کریں گے، جن میں سے ایک 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] اظہار کے دونوں حصے غلط ہوں گے، اس لیے اس کی اگلی حالت نہیں ہے۔ لہذا، ہمارے پاس دوسرے مرحلے کی مکمل وضاحت موجود ہے - جیسا کہ ہم دیکھتے ہیں، یہ بالکل عام ریاضی ہے، جیسا کہ انجینئرز اور سائنسدانوں کا، اور عجیب نہیں، جیسا کہ کمپیوٹر سائنس میں۔
ان دونوں فارمولوں کو دنیاوی منطق کے ایک فارمولے میں ملایا جا سکتا ہے۔ یہ خوبصورت اور وضاحت کرنے میں آسان ہے، لیکن اب اس کے لیے کوئی وقت نہیں ہے۔ ہمیں صرف زندگی کی ملکیت کے لیے دنیاوی منطق کی ضرورت ہو سکتی ہے، سلامتی کے لیے اس کی ضرورت نہیں ہے۔ مجھے دنیاوی منطق پسند نہیں ہے، یہ بالکل عام ریاضی نہیں ہے، لیکن زندہ دلی کے معاملے میں یہ ایک ضروری برائی ہے۔
ہر ایک قدر کے لیے Euclidean الگورتھم میں x и y منفرد اقدار ہیں x' и y'، جو اگلی ریاست کے ساتھ تعلق کو درست بناتا ہے۔ دوسرے لفظوں میں، Euclidean algorithm deterministic ہے۔ غیر متزلزل الگورتھم کو ماڈل کرنے کے لیے، موجودہ حالت میں مستقبل کی متعدد ممکنہ حالتیں ہونی چاہئیں، اور غیر بنیادی متغیر کی ہر قدر میں پرائمڈ متغیر کی متعدد قدریں ہونی چاہئیں تاکہ اگلی حالت سے تعلق درست ہو۔ ایسا کرنا مشکل نہیں ہے، لیکن میں اب مثالیں نہیں دوں گا۔
ورکنگ ٹول بنانے کے لیے، آپ کو رسمی ریاضی کی ضرورت ہے۔ تصریح کو رسمی کیسے بنایا جائے؟ ایسا کرنے کے لیے ہمیں ایک رسمی زبان کی ضرورت ہوگی، جیسے . اس زبان میں Euclidean الگورتھم کی تفصیلات اس طرح نظر آئیں گی:
مثلث کے ساتھ مساوی نشانی علامت کا مطلب یہ ہے کہ نشان کے بائیں طرف کی قیمت نشان کے دائیں طرف کی قدر کے برابر ہونے کا تعین کیا جاتا ہے۔ جوہر میں، ایک تصریح ایک تعریف ہے، ہمارے معاملے میں دو تعریفیں۔ TLA+ میں تصریح میں آپ کو ڈیکلریشنز اور کچھ نحو شامل کرنے کی ضرورت ہے، جیسا کہ اوپر کی سلائیڈ میں ہے۔ ASCII میں یہ اس طرح نظر آئے گا:
جیسا کہ آپ دیکھ سکتے ہیں، کچھ بھی پیچیدہ نہیں ہے. TLA+ پر تصریح کی تصدیق کی جا سکتی ہے، یعنی چھوٹے ماڈل میں تمام ممکنہ طرز عمل کو نظرانداز کرنا ممکن ہے۔ ہمارے معاملے میں، یہ ماڈل کچھ قدروں کا ہوگا۔ M и N. یہ ایک بہت ہی موثر اور آسان تصدیقی طریقہ ہے جو مکمل طور پر خودکار ہے۔ اس کے علاوہ، سچائی کے باضابطہ ثبوت لکھنا اور انہیں میکانکی طور پر چیک کرنا ممکن ہے، لیکن اس میں کافی وقت لگتا ہے، اس لیے تقریباً کوئی بھی ایسا نہیں کرتا ہے۔
TLA+ کا بنیادی نقصان یہ ہے کہ یہ ریاضی ہے، اور پروگرامرز اور کمپیوٹر سائنس دان ریاضی سے ڈرتے ہیں۔ پہلی نظر میں یہ ایک لطیفہ لگتا ہے، لیکن بدقسمتی سے، میں یہ بات پوری سنجیدگی سے کہہ رہا ہوں۔ میرا ایک ساتھی مجھے صرف یہ بتا رہا تھا کہ اس نے کئی ڈویلپرز کو TLA+ کی وضاحت کرنے کی کوشش کی۔ جیسے ہی فارمولے اسکرین پر نمودار ہوئے، ان کی آنکھیں فوراً ہی شیشہ بن گئیں۔ لہذا اگر TLA+ خوفناک ہے، تو آپ استعمال کر سکتے ہیں۔ ، کھلونا پروگرامنگ زبان کی ایک قسم ہے۔ PlusCal میں ایک اظہار کوئی بھی TLA+ اظہار ہوسکتا ہے، یعنی بنیادی طور پر کوئی بھی ریاضیاتی اظہار۔ مزید برآں، PlusCal میں غیر متعین الگورتھم کے لیے نحو موجود ہے۔ چونکہ PlusCal کوئی بھی TLA+ اظہار لکھ سکتا ہے، یہ کسی بھی حقیقی پروگرامنگ زبان سے نمایاں طور پر زیادہ اظہار خیال کرتا ہے۔ اس کے بعد، PlusCal کو پڑھنے میں آسان TLA+ تفصیلات میں مرتب کیا گیا ہے۔ یقیناً اس کا مطلب یہ نہیں ہے کہ پیچیدہ PlusCal تفصیلات 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۔
اگر میں پہلے ہی جانتا ہوں کہ کوڈ کو کیا کرنا چاہیے تو مجھے تصریح لکھنے کی ضرورت کیوں پیش آئی؟ اصل میں، میں نے صرف سوچا کہ میں اسے جانتا ہوں. اس کے علاوہ، تصریح کی جگہ کے ساتھ، کسی باہر والے کو یہ سمجھنے کے لیے کوڈ کو دیکھنے کی ضرورت نہیں ہے کہ یہ اصل میں کیا کرتا ہے۔ میرے پاس ایک اصول ہے: کوئی عام اصول نہیں ہونا چاہئے۔ یقیناً اس قاعدے میں ایک استثناء ہے، یہ واحد عام اصول ہے جس کی میں پیروی کرتا ہوں: کوڈ کیا کرتا ہے اس کی تفصیلات سے لوگوں کو وہ سب کچھ بتانا چاہیے جو انہیں اس کوڈ کا استعمال کرتے وقت جاننے کی ضرورت ہے۔
تو پروگرامرز کو سوچنے کے بارے میں بالکل کیا جاننے کی ضرورت ہے؟ شروع کرنے کے لیے، جیسا کہ سب کے لیے ہے: اگر آپ نہیں لکھتے ہیں، تو آپ کو ایسا لگتا ہے کہ آپ سوچ رہے ہیں۔ اس کے علاوہ، آپ کو کوڈ کرنے سے پہلے سوچنے کی ضرورت ہے، جس کا مطلب ہے کہ آپ کو کوڈ کرنے سے پہلے لکھنے کی ضرورت ہے۔ تصریح وہ ہے جو ہم کوڈنگ شروع کرنے سے پہلے لکھتے ہیں۔ کسی بھی کوڈ کے لیے ایک تصریح کی ضرورت ہوتی ہے جسے کوئی بھی استعمال یا تبدیل کر سکتا ہے۔ اور یہ "کوئی" اس کوڈ کے لکھے جانے کے ایک ماہ بعد اس کا مصنف بن سکتا ہے۔ بڑے پروگراموں اور سسٹمز کے لیے، کلاسز کے لیے، طریقوں کے لیے، اور بعض اوقات کسی ایک طریقہ کے پیچیدہ حصوں کے لیے بھی ایک تصریح کی ضرورت ہوتی ہے۔ آپ کو کوڈ کے بارے میں بالکل کیا لکھنا چاہئے؟ آپ کو یہ بیان کرنے کی ضرورت ہے کہ یہ کیا کرتا ہے، یعنی کوئی ایسی چیز جو اس کوڈ کو استعمال کرنے والے کسی کے لیے بھی کارآمد ہو۔ بعض اوقات یہ بتانا بھی ضروری ہو سکتا ہے کہ کوڈ اپنا مقصد کیسے حاصل کرتا ہے۔ اگر ہم الگورتھم کورس میں اس طریقہ سے گزرے تو ہم اسے الگورتھم کہتے ہیں۔ اگر یہ کچھ زیادہ مخصوص اور نیا ہے، تو ہم اسے اعلیٰ سطحی ڈیزائن کہتے ہیں۔ یہاں کوئی رسمی فرق نہیں ہے: دونوں پروگرام کے تجریدی ماڈل ہیں۔
آپ کو کوڈ کی تفصیلات کیسے لکھنی چاہئے؟ اہم بات: یہ خود کوڈ سے ایک سطح اونچا ہونا چاہئے۔ اسے ریاستوں اور طرز عمل کی وضاحت کرنی چاہیے۔ یہ اتنا ہی سخت ہونا چاہئے جتنا کام کی ضرورت ہے۔ اگر آپ کسی ٹاسک کو لاگو کرنے کے طریقہ کی وضاحت لکھ رہے ہیں، تو اسے pseudocode یا PlusCal کا استعمال کرتے ہوئے لکھا جا سکتا ہے۔ آپ کو رسمی وضاحتیں استعمال کرتے ہوئے وضاحتیں لکھنا سیکھنے کی ضرورت ہے۔ یہ آپ کو ضروری ہنر فراہم کرے گا جو غیر رسمی لوگوں میں بھی مدد کرے گا۔ آپ رسمی وضاحتیں لکھنا کیسے سیکھ سکتے ہیں؟ جب ہم نے پروگرام کرنا سیکھا تو ہم نے پروگرام لکھے اور پھر انہیں ڈیبگ کیا۔ یہاں ایک ہی چیز: آپ کو ایک تفصیلات لکھنے کی ضرورت ہے، اسے ماڈل چیکر سے چیک کریں، اور غلطیوں کو ٹھیک کریں۔ TLA+ کسی رسمی تصریح کے لیے بہترین زبان نہیں ہو سکتی، اور دوسری زبان آپ کی مخصوص ضروریات کے لیے زیادہ موزوں ہو سکتی ہے۔ TLA+ کے بارے میں سب سے بڑی بات یہ ہے کہ یہ ریاضی کی سوچ سکھانے کا بہت اچھا کام کرتا ہے۔
تفصیلات اور کوڈ کو کیسے جوڑیں؟ ایسے تبصرے استعمال کرنا جو ریاضیاتی تصورات اور ان کے نفاذ کو جوڑتے ہیں۔ اگر آپ گراف کے ساتھ کام کرتے ہیں، تو پروگرام کی سطح پر آپ کے پاس نوڈس کی صفیں اور لنکس کی صفیں ہوں گی۔ لہذا آپ کو یہ لکھنے کی ضرورت ہے کہ ان پروگرامنگ ڈھانچے کے ذریعہ گراف کو کس طرح لاگو کیا جاتا ہے۔
واضح رہے کہ مذکورہ بالا میں سے کوئی بھی خود کوڈ لکھنے کے عمل پر لاگو نہیں ہوتا ہے۔ جب آپ کوڈ لکھتے ہیں، یعنی تیسرا مرحلہ انجام دیتے ہیں، تو آپ کو پروگرام کے ذریعے سوچنے اور سوچنے کی بھی ضرورت ہوتی ہے۔ اگر کوئی ذیلی کام پیچیدہ یا واضح نہیں ہوتا ہے، تو آپ کو اس کے لیے تصریح لکھنی ہوگی۔ لیکن میں یہاں خود کوڈ کے بارے میں بات نہیں کر رہا ہوں۔ آپ کسی بھی پروگرامنگ زبان، کوئی طریقہ کار استعمال کر سکتے ہیں، یہ ان کے بارے میں نہیں ہے۔ نیز، مذکورہ بالا میں سے کوئی بھی آپ کے کوڈ کو جانچنے اور ڈیبگ کرنے کی ضرورت کو ختم نہیں کرتا ہے۔ یہاں تک کہ اگر خلاصہ ماڈل صحیح لکھا گیا ہے، تو اس کے نفاذ میں کیڑے ہوسکتے ہیں۔
وضاحتیں لکھنا کوڈنگ کے عمل میں ایک اضافی مرحلہ ہے۔ اس کی بدولت بہت سی غلطیاں کم محنت سے پکڑی جا سکتی ہیں - ہم یہ بات ایمیزون کے پروگرامرز کے تجربے سے جانتے ہیں۔ وضاحتوں کے ساتھ، پروگراموں کا معیار بلند ہو جاتا ہے۔ تو پھر ہم اکثر ان کے بغیر کیوں جاتے ہیں؟ کیونکہ لکھنا مشکل ہے۔ لیکن لکھنا مشکل ہے، کیونکہ اس کے لیے سوچنے کی ضرورت ہے، اور سوچنا بھی مشکل ہے۔ یہ دکھاوا کرنا ہمیشہ آسان ہوتا ہے کہ آپ سوچ رہے ہیں۔ یہاں دوڑنے کے ساتھ ایک مشابہت کھینچی جا سکتی ہے - آپ جتنا کم دوڑیں گے، اتنا ہی آہستہ۔ آپ کو اپنے پٹھوں کو تربیت دینے اور لکھنے کی مشق کرنے کی ضرورت ہے۔ یہ مشق لیتا ہے.
تصریح غلط ہو سکتی ہے۔ ہو سکتا ہے آپ سے کہیں غلطی ہوئی ہو، یا تقاضے بدل گئے ہوں، یا بہتری کی ضرورت ہو گی۔ کوئی بھی کوڈ جسے کوئی بھی استعمال کرتا ہے اسے تبدیل کرنا ہوگا، لہذا جلد یا بدیر تفصیلات پروگرام سے مماثل نہیں ہوں گی۔ مثالی طور پر، اس معاملے میں، آپ کو ایک نئی تفصیلات لکھنے اور کوڈ کو مکمل طور پر دوبارہ لکھنے کی ضرورت ہے۔ ہم اچھی طرح جانتے ہیں کہ ایسا کوئی نہیں کرتا۔ عملی طور پر، ہم کوڈ کو پیچ کرتے ہیں اور شاید تفصیلات کو اپ ڈیٹ کرتے ہیں۔ اگر یہ جلد یا بدیر ہونے کا پابند ہے تو پھر وضاحتیں کیوں لکھیں؟ سب سے پہلے، اس شخص کے لیے جو آپ کے کوڈ میں ترمیم کرے گا، تصریح میں موجود ہر اضافی لفظ کا وزن سونے میں ہو گا، اور یہ شخص آپ ہی ہو سکتا ہے۔ جب میں اپنے کوڈ میں ترمیم کرتا ہوں تو میں اکثر اپنے آپ کو کافی مخصوص نہ ہونے پر لات مارتا ہوں۔ اور میں کوڈ سے زیادہ وضاحتیں لکھتا ہوں۔ لہذا، جب آپ کوڈ میں ترمیم کرتے ہیں، تو تفصیلات کو ہمیشہ اپ ڈیٹ کرنے کی ضرورت ہوتی ہے۔ دوم، ہر ترمیم کے ساتھ کوڈ بدتر ہو جاتا ہے، اسے پڑھنا اور برقرار رکھنا مشکل ہو جاتا ہے۔ یہ اینٹروپی میں اضافہ ہے۔ لیکن اگر آپ کسی تصریح کے ساتھ شروع نہیں کرتے ہیں، تو آپ کی لکھی ہوئی ہر سطر ایک ترمیم ہوگی، اور کوڈ بہت بڑا اور شروع سے پڑھنا مشکل ہوگا۔
جیسا کہ کہا , کوئی جنگ کسی منصوبے کے مطابق نہیں جیتی گئی اور کوئی جنگ بغیر منصوبہ بندی کے نہیں جیتی گئی۔. اور وہ لڑائیوں کے بارے میں کچھ جانتا تھا۔ ایک رائے ہے کہ وضاحتیں لکھنا وقت کا ضیاع ہے۔ کبھی کبھی یہ سچ ہے، اور کام اتنا آسان ہے کہ اس کے ذریعے سوچنے کا کوئی فائدہ نہیں ہے. لیکن آپ کو ہمیشہ یاد رکھنا چاہیے کہ جب آپ کو وضاحتیں نہ لکھنے کا مشورہ دیا جاتا ہے، تو اس کا مطلب ہے کہ آپ کو سوچنے سے گریز کرنے کا مشورہ دیا جاتا ہے۔ اور آپ کو ہر بار اس کے بارے میں سوچنا چاہئے۔ کسی کام کے بارے میں سوچنا اس بات کی ضمانت نہیں دیتا کہ آپ غلطیاں نہیں کریں گے۔ جیسا کہ ہم جانتے ہیں، کسی نے جادو کی چھڑی ایجاد نہیں کی، اور پروگرامنگ ایک مشکل کام ہے۔ لیکن اگر آپ کام کے بارے میں نہیں سوچتے ہیں، تو آپ کو غلطیاں کرنے کی ضمانت دی جاتی ہے۔
آپ ایک خاص ویب سائٹ پر TLA+ اور PlusCal کے بارے میں مزید پڑھ سکتے ہیں، آپ وہاں میرے ہوم پیج سے جا سکتے ہیں۔ . یہ سب میرے لیے ہے، آپ کی توجہ کا شکریہ۔
یاد رہے کہ یہ ترجمہ ہے۔ جب آپ تبصرے لکھتے ہیں تو یاد رکھیں کہ مصنف انہیں نہیں پڑھے گا۔ اگر آپ واقعی مصنف کے ساتھ بات چیت کرنا چاہتے ہیں، تو وہ ہائیڈرا 2019 کانفرنس میں ہوں گے، جو 11-12 جولائی، 2019 کو سینٹ پیٹرزبرگ میں منعقد ہوگی۔ ٹکٹ خریدے جا سکتے ہیں۔ .
ماخذ: www.habr.com