ప్రోగ్రామింగ్ అనేది కోడింగ్ కంటే ఎక్కువ

ప్రోగ్రామింగ్ అనేది కోడింగ్ కంటే ఎక్కువ

ఈ వ్యాసం అనువాదం స్టాన్‌ఫోర్డ్ సెమినార్. కానీ ఆమె ముందు ఒక చిన్న పరిచయం. జాంబీస్ ఎలా ఏర్పడతాయి? ప్రతి ఒక్కరూ తమ స్నేహితుడిని లేదా సహోద్యోగిని తమ స్థాయికి లాగాలని కోరుకునే పరిస్థితికి వచ్చారు, కానీ అది పని చేయదు. మరియు అతనితో "ఇది పని చేయదు" అని మీతో అంతగా లేదు: స్కేల్ యొక్క ఒక వైపు సాధారణ జీతం, పనులు మరియు మొదలైనవి, మరియు మరొకదానిపై ఆలోచించాల్సిన అవసరం ఉంది. ఆలోచించడం అసహ్యకరమైనది మరియు బాధాకరమైనది. అతను త్వరగా వదులుకుంటాడు మరియు అతని మెదడును ఆన్ చేయకుండా కోడ్ రాయడం కొనసాగిస్తాడు. నేర్చుకున్న నిస్సహాయత యొక్క అడ్డంకిని అధిగమించడానికి ఎంత ప్రయత్నం అవసరమో మీరు ఊహించుకుంటారు మరియు మీరు దీన్ని చేయరు. ఈ విధంగా జాంబీస్ ఏర్పడతాయి, ఇది నయం చేయగలదని అనిపిస్తుంది, కానీ ఎవరూ దీన్ని చేయరని అనిపిస్తుంది.

అది చూసినప్పుడు లెస్లీ లాంపోర్ట్ (అవును, పాఠ్యపుస్తకాల నుండి అదే కామ్రేడ్) రష్యాకు వస్తుంది మరియు నివేదికను రూపొందించలేదు, కానీ ప్రశ్నోత్తరాల సెషన్, నేను కొంచెం జాగ్రత్తగా ఉన్నాను. ఒకవేళ, లెస్లీ ప్రపంచ ప్రఖ్యాత శాస్త్రవేత్త, పంపిణీ చేయబడిన కంప్యూటింగ్‌లో ప్రాథమిక రచనల రచయిత, మరియు మీరు అతన్ని LaTeX - “Lamport TeX” అనే పదంలోని La అక్షరాల ద్వారా కూడా తెలుసుకోవచ్చు. రెండవ భయంకరమైన అంశం అతని అవసరం: వచ్చిన ప్రతి ఒక్కరూ తప్పనిసరిగా (ఖచ్చితంగా ఉచితంగా) అతని రెండు నివేదికలను ముందుగానే వినాలి, వాటిపై కనీసం ఒక ప్రశ్నతో ముందుకు రావాలి, ఆపై మాత్రమే రావాలి. లాంపోర్ట్ అక్కడ ఏమి ప్రసారం చేస్తుందో చూడాలని నేను నిర్ణయించుకున్నాను - మరియు ఇది చాలా బాగుంది! ఇది ఖచ్చితంగా అదే విషయం, జాంబీస్‌ను నయం చేయడానికి మ్యాజిక్ లింక్-పిల్. నేను మిమ్మల్ని హెచ్చరిస్తున్నాను: టెక్స్ట్ నుండి, సూపర్-ఫ్లెక్సిబుల్ మెథడాలజీల ప్రేమికులు మరియు వ్రాసిన వాటిని పరీక్షించడానికి ఇష్టపడని వారు ముఖ్యంగా కాలిపోవచ్చు.

habrokat తర్వాత, నిజానికి, సెమినార్ యొక్క అనువాదం ప్రారంభమవుతుంది. చదివి ఆనందించండి!

మీరు ఏ పనిని చేపట్టినా, మీరు ఎల్లప్పుడూ మూడు దశలను అనుసరించాలి:

  • మీరు ఏ లక్ష్యాన్ని సాధించాలనుకుంటున్నారో నిర్ణయించుకోండి;
  • మీరు మీ లక్ష్యాన్ని ఎలా సాధించాలో నిర్ణయించుకోండి;
  • మీ లక్ష్యానికి రండి.

ఇది ప్రోగ్రామింగ్‌కు కూడా వర్తిస్తుంది. మేము కోడ్ వ్రాసేటప్పుడు, మనకు ఇది అవసరం:

  • కార్యక్రమం ఏమి చేయాలో నిర్ణయించండి;
  • దాని పనిని ఎలా నిర్వహించాలో నిర్ణయించండి;
  • సంబంధిత కోడ్ వ్రాయండి.

చివరి దశ, వాస్తవానికి, చాలా ముఖ్యమైనది, కానీ నేను ఈ రోజు దాని గురించి మాట్లాడను. బదులుగా, మేము మొదటి రెండింటిని చర్చిస్తాము. ప్రతి ప్రోగ్రామర్ పనిని ప్రారంభించే ముందు వాటిని నిర్వహిస్తారు. మీరు బ్రౌజర్ లేదా డేటాబేస్ వ్రాస్తున్నారా అని మీరు నిర్ణయించుకుంటే తప్ప మీరు వ్రాయడానికి కూర్చోరు. లక్ష్యం గురించి ఒక నిర్దిష్ట ఆలోచన ఉండాలి. మరియు ప్రోగ్రామ్ ఖచ్చితంగా ఏమి చేస్తుందో మీరు ఖచ్చితంగా ఆలోచిస్తారు మరియు కోడ్ ఏదో ఒకవిధంగా బ్రౌజర్‌గా మారుతుందనే ఆశతో ఏదో ఒకవిధంగా వ్రాయవద్దు.

ఈ కోడ్ ముందస్తు ఆలోచన ఎలా జరుగుతుంది? దీని కోసం మనం ఎంత ప్రయత్నం చేయాలి? మనం ఎంత క్లిష్టంగా ఉన్న సమస్యను పరిష్కరిస్తున్నాం అనే దానిపై ఆధారపడి ఉంటుంది. మనం తప్పు-తట్టుకునే పంపిణీ వ్యవస్థను వ్రాయాలనుకుంటున్నాము. ఈ సందర్భంలో, మనం కోడ్‌కి కూర్చునే ముందు విషయాలను జాగ్రత్తగా ఆలోచించాలి. మనం పూర్ణాంకం వేరియబుల్‌ని 1తో పెంచవలసి వస్తే? మొదటి చూపులో, ప్రతిదీ ఇక్కడ చిన్నవిషయం, మరియు ఆలోచన అవసరం లేదు, కానీ అప్పుడు మేము ఓవర్ఫ్లో సంభవించవచ్చు అని గుర్తుంచుకోవాలి. అందువల్ల, సమస్య సరళమైనదా లేదా సంక్లిష్టమైనదా అని అర్థం చేసుకోవడానికి, మీరు మొదట ఆలోచించాలి.

మీరు ముందుగానే సమస్యకు సాధ్యమైన పరిష్కారాల గురించి ఆలోచిస్తే, మీరు తప్పులను నివారించవచ్చు. అయితే దీనికి మీ ఆలోచన స్పష్టంగా ఉండాలి. దీన్ని సాధించడానికి, మీరు మీ ఆలోచనలను వ్రాయాలి. డిక్ గిండన్ కోట్ నాకు చాలా ఇష్టం: "మీరు వ్రాసినప్పుడు, మీ ఆలోచన ఎంత అలసత్వంగా ఉందో ప్రకృతి మీకు చూపుతుంది." మీరు వ్రాయకపోతే, మీరు ఆలోచిస్తున్నట్లు మాత్రమే మీరు భావిస్తారు. మరియు మీరు మీ ఆలోచనలను స్పెసిఫికేషన్ల రూపంలో వ్రాయాలి.

స్పెసిఫికేషన్లు అనేక విధులను నిర్వహిస్తాయి, ముఖ్యంగా పెద్ద ప్రాజెక్ట్‌లలో. కానీ నేను వాటిలో ఒకదాని గురించి మాత్రమే మాట్లాడతాను: అవి స్పష్టంగా ఆలోచించడంలో మాకు సహాయపడతాయి. స్పష్టంగా ఆలోచించడం చాలా ముఖ్యం మరియు చాలా కష్టం, కాబట్టి ఇక్కడ మనకు ఏదైనా సహాయం కావాలి. స్పెసిఫికేషన్లను మనం ఏ భాషలో రాయాలి? సాధారణంగా, ప్రోగ్రామర్‌లకు ఇది ఎల్లప్పుడూ మొదటి ప్రశ్న: మనం ఏ భాషలో వ్రాస్తాము. దీనికి సరైన సమాధానం ఎవరూ లేరు: మేము పరిష్కరిస్తున్న సమస్యలు చాలా వైవిధ్యమైనవి. కొందరికి, TLA+ అనేది నేను డెవలప్ చేసిన స్పెసిఫికేషన్ లాంగ్వేజ్. ఇతరులకు, చైనీస్ ఉపయోగించడం మరింత సౌకర్యవంతంగా ఉంటుంది. ప్రతిదీ పరిస్థితిపై ఆధారపడి ఉంటుంది.

మరింత ముఖ్యమైనది మరొక ప్రశ్న: స్పష్టమైన ఆలోచనను ఎలా సాధించాలి? సమాధానం: మనం శాస్త్రవేత్తలలా ఆలోచించాలి. ఇది గత 500 సంవత్సరాలలో నిరూపించబడిన ఆలోచనా విధానం. విజ్ఞాన శాస్త్రంలో, మేము వాస్తవికత యొక్క గణిత నమూనాలను నిర్మిస్తాము. ఖగోళ శాస్త్రం బహుశా పదం యొక్క ఖచ్చితమైన అర్థంలో మొదటి శాస్త్రం. ఖగోళ శాస్త్రంలో ఉపయోగించే గణిత నమూనాలో, ఖగోళ వస్తువులు ద్రవ్యరాశి, స్థానం మరియు మొమెంటంతో బిందువులుగా కనిపిస్తాయి, అయితే వాస్తవానికి అవి పర్వతాలు మరియు మహాసముద్రాలు, అలలు మరియు ఆటుపోట్లతో చాలా క్లిష్టమైన వస్తువులు. ఈ మోడల్, ఏదైనా ఇతర మాదిరిగానే, కొన్ని సమస్యలను పరిష్కరించడానికి సృష్టించబడింది. మీరు గ్రహాన్ని కనుగొనవలసి వస్తే టెలిస్కోప్‌ను ఎక్కడ సూచించాలో నిర్ణయించడానికి ఇది చాలా బాగుంది. కానీ మీరు ఈ గ్రహం మీద వాతావరణాన్ని అంచనా వేయాలనుకుంటే, ఈ మోడల్ పని చేయదు.

గణితం మోడల్ యొక్క లక్షణాలను గుర్తించడానికి అనుమతిస్తుంది. మరియు ఈ లక్షణాలు వాస్తవికతతో ఎలా సంబంధం కలిగి ఉన్నాయో సైన్స్ చూపిస్తుంది. మన సైన్స్, కంప్యూటర్ సైన్స్ గురించి మాట్లాడుకుందాం. మేము పని చేసే వాస్తవికత వివిధ రకాలైన కంప్యూటింగ్ సిస్టమ్‌లు: ప్రాసెసర్‌లు, గేమ్ కన్సోల్‌లు, కంప్యూటర్లు, ప్రోగ్రామ్‌లను అమలు చేయడం మొదలైనవి. నేను కంప్యూటర్‌లో ప్రోగ్రామ్‌ను అమలు చేయడం గురించి మాట్లాడతాను, కానీ పెద్దగా, ఈ ముగింపులన్నీ ఏదైనా కంప్యూటింగ్ సిస్టమ్‌కు వర్తిస్తాయి. మా సైన్స్‌లో, మేము అనేక విభిన్న నమూనాలను ఉపయోగిస్తాము: ట్యూరింగ్ మెషిన్, పాక్షికంగా ఆర్డర్ చేసిన ఈవెంట్‌ల సెట్‌లు మరియు అనేక ఇతరాలు.

కార్యక్రమం అంటే ఏమిటి? ఇది స్వతంత్రంగా పరిగణించబడే ఏదైనా కోడ్. మనం బ్రౌజర్‌ని వ్రాయాలి అనుకుందాం. మేము మూడు పనులను చేస్తాము: మేము ప్రోగ్రామ్ యొక్క వినియోగదారు వీక్షణను డిజైన్ చేస్తాము, ఆపై మేము ప్రోగ్రామ్ యొక్క ఉన్నత-స్థాయి రేఖాచిత్రాన్ని వ్రాస్తాము మరియు చివరకు మేము కోడ్‌ను వ్రాస్తాము. మేము కోడ్‌ను వ్రాసేటప్పుడు, మనం టెక్స్ట్ ఫార్మాటర్‌ను వ్రాయవలసి ఉంటుందని మేము గ్రహిస్తాము. ఇక్కడ మనం మళ్లీ మూడు సమస్యలను పరిష్కరించాలి: ఈ సాధనం ఏ వచనాన్ని తిరిగి ఇస్తుందో నిర్ణయించండి; ఫార్మాటింగ్ కోసం ఒక అల్గోరిథం ఎంచుకోండి; కోడ్ వ్రాయండి. ఈ టాస్క్‌కి దాని స్వంత సబ్‌టాస్క్ ఉంది: పదాలలోకి హైఫన్‌ను సరిగ్గా చొప్పించండి. మేము ఈ ఉప పనిని మూడు దశల్లో కూడా పరిష్కరిస్తాము - మీరు చూడగలిగినట్లుగా, అవి అనేక స్థాయిలలో పునరావృతమవుతాయి.

మొదటి దశను మరింత వివరంగా పరిశీలిద్దాం: ప్రోగ్రామ్ ఏ సమస్యను పరిష్కరిస్తుంది. ఇక్కడ, మేము చాలా తరచుగా ప్రోగ్రామ్‌ను కొంత ఇన్‌పుట్ తీసుకొని కొంత అవుట్‌పుట్ ఉత్పత్తి చేసే ఫంక్షన్‌గా మోడల్ చేస్తాము. గణితశాస్త్రంలో, ఒక ఫంక్షన్ సాధారణంగా క్రమబద్ధమైన జతల సెట్‌గా వర్ణించబడుతుంది. ఉదాహరణకు, సహజ సంఖ్యల కోసం స్క్వేర్ ఫంక్షన్ {<0,0>, <1,1>, <2,4>, <3,9>, …} సెట్‌గా వివరించబడింది. అటువంటి ఫంక్షన్ యొక్క డొమైన్ ప్రతి జత యొక్క మొదటి మూలకాల సమితి, అంటే సహజ సంఖ్యలు. ఫంక్షన్‌ని నిర్వచించడానికి, మేము దాని పరిధిని మరియు సూత్రాన్ని పేర్కొనాలి.

కానీ గణితంలో ఫంక్షన్లు ప్రోగ్రామింగ్ భాషలలోని ఫంక్షన్ల వలె ఉండవు. గణితం చాలా సులభం. సంక్లిష్ట ఉదాహరణల కోసం నాకు సమయం లేదు కాబట్టి, ఒక సాధారణమైనదాన్ని పరిశీలిద్దాం: Cలోని ఒక ఫంక్షన్ లేదా రెండు పూర్ణాంకాల యొక్క గొప్ప సాధారణ భాగహారాన్ని అందించే జావాలోని స్టాటిక్ పద్ధతి. ఈ పద్ధతి యొక్క వివరణలో, మేము వ్రాస్తాము: లెక్కిస్తుంది GCD(M,N) వాదనల కోసం M и Nపేరు GCD(M,N) - డొమైన్ పూర్ణాంకాల జతల సమితి, మరియు రిటర్న్ విలువ ద్వారా విభజించబడే అతిపెద్ద పూర్ణాంకం M и N. ఈ మోడల్ రియాలిటీకి ఎలా సంబంధం కలిగి ఉంటుంది? మోడల్ పూర్ణాంకాలపై పనిచేస్తుంది, అయితే C లేదా జావాలో మనకు 32-బిట్ ఉంటుంది 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 ఒక ప్రారంభ స్థితి మాత్రమే ఉంది. తదుపరి స్థితితో సంబంధం సూత్రం ద్వారా వివరించబడింది, దీనిలో తదుపరి స్థితి యొక్క వేరియబుల్స్ ప్రైమ్‌తో వ్రాయబడతాయి మరియు ప్రస్తుత స్థితి యొక్క వేరియబుల్స్ ప్రైమ్ లేకుండా వ్రాయబడతాయి. యూక్లిడ్ యొక్క అల్గోరిథం విషయంలో, మేము రెండు సూత్రాల విభజనతో వ్యవహరిస్తాము, వాటిలో ఒకటి 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] వ్యక్తీకరణ యొక్క రెండు భాగాలు తప్పుగా ఉంటాయి, కాబట్టి దీనికి తదుపరి స్థితి లేదు. కాబట్టి, మేము రెండవ దశ యొక్క పూర్తి వివరణను కలిగి ఉన్నాము - మీరు చూడగలిగినట్లుగా, ఇది ఇంజనీర్లు మరియు శాస్త్రవేత్తల వలె చాలా సాధారణ గణితం, మరియు కంప్యూటర్ సైన్స్లో వలె వింత కాదు.

ఈ రెండు సూత్రాలను తాత్కాలిక తర్కం యొక్క ఒక ఫార్ములాగా కలపవచ్చు. ఆమె సొగసైనది మరియు వివరించడానికి సులభం, కానీ ఇప్పుడు ఆమెకు సమయం లేదు. జీవనోపాధి కోసం మాత్రమే మనకు తాత్కాలిక తర్కం అవసరం కావచ్చు, భద్రత కోసం ఇది అవసరం లేదు. నాకు టెంపోరల్ లాజిక్ అంటే ఇష్టం లేదు, ఇది చాలా మామూలు గణితం కాదు, కానీ జీవనోపాధి విషయంలో ఇది తప్పనిసరి చెడు.

యూక్లిడ్ యొక్క అల్గోరిథంలో, ప్రతి విలువకు x и y ప్రత్యేక విలువలను కలిగి ఉంటాయి x' и y', ఇది తదుపరి రాష్ట్రంతో సంబంధాన్ని నిజం చేస్తుంది. మరో మాటలో చెప్పాలంటే, యూక్లిడ్ యొక్క అల్గోరిథం నిర్ణయాత్మకమైనది. నాన్-డిటర్మినిస్టిక్ అల్గారిథమ్‌ని మోడల్ చేయడానికి, ప్రస్తుత స్థితికి బహుళ సాధ్యమయ్యే భవిష్యత్ స్థితులను కలిగి ఉండాలి మరియు ప్రతి అన్‌ప్రైమ్డ్ వేరియబుల్ వాల్యూ బహుళ ప్రైమ్డ్ వేరియబుల్ విలువలను కలిగి ఉంటుంది, అంటే తదుపరి స్థితికి సంబంధించిన సంబంధం నిజం. దీన్ని చేయడం చాలా సులభం, కానీ నేను ఇప్పుడు ఉదాహరణలు ఇవ్వను.

పని సాధనం చేయడానికి, మీకు అధికారిక గణితం అవసరం. వివరణను అధికారికంగా ఎలా చేయాలి? దీన్ని చేయడానికి, మనకు అధికారిక భాష అవసరం, ఉదాహరణకు, TLA+. యూక్లిడ్ అల్గోరిథం యొక్క వివరణ ఈ భాషలో ఇలా ఉంటుంది:

ప్రోగ్రామింగ్ అనేది కోడింగ్ కంటే ఎక్కువ

త్రిభుజంతో సమానమైన సంకేతం అంటే గుర్తుకు ఎడమవైపు ఉన్న విలువ గుర్తుకు కుడివైపున ఉన్న విలువకు సమానంగా నిర్వచించబడింది. సారాంశంలో, స్పెసిఫికేషన్ అనేది ఒక నిర్వచనం, మా విషయంలో రెండు నిర్వచనాలు. TLA+లోని స్పెసిఫికేషన్‌కు, మీరు పై స్లయిడ్‌లో ఉన్నట్లుగా డిక్లరేషన్‌లు మరియు కొన్ని వాక్యనిర్మాణాలను జోడించాలి. ASCIIలో ఇది ఇలా ఉంటుంది:

ప్రోగ్రామింగ్ అనేది కోడింగ్ కంటే ఎక్కువ

మీరు గమనిస్తే, సంక్లిష్టంగా ఏమీ లేదు. TLA+ కోసం స్పెసిఫికేషన్‌ను పరీక్షించవచ్చు, అంటే ఒక చిన్న మోడల్‌లో సాధ్యమయ్యే అన్ని ప్రవర్తనలను దాటవేయండి. మా విషయంలో, ఈ మోడల్ నిర్దిష్ట విలువలను కలిగి ఉంటుంది M и N. ఇది పూర్తిగా స్వయంచాలకంగా ఉండే చాలా సమర్థవంతమైన మరియు సరళమైన ధృవీకరణ పద్ధతి. అధికారిక సత్య రుజువులను వ్రాయడం మరియు వాటిని యాంత్రికంగా తనిఖీ చేయడం కూడా సాధ్యమే, కానీ దీనికి చాలా సమయం పడుతుంది, కాబట్టి దాదాపు ఎవరూ దీన్ని చేయరు.

TLA+ యొక్క ప్రధాన ప్రతికూలత ఏమిటంటే ఇది గణితం, మరియు ప్రోగ్రామర్లు మరియు కంప్యూటర్ శాస్త్రవేత్తలు గణితానికి భయపడతారు. మొదటి చూపులో, ఇది ఒక జోక్ లాగా అనిపిస్తుంది, కానీ, దురదృష్టవశాత్తు, నా ఉద్దేశ్యం చాలా తీవ్రంగా ఉంది. నా సహోద్యోగి చాలా మంది డెవలపర్‌లకు TLA+ని ఎలా వివరించడానికి ప్రయత్నించారో నాకు చెబుతున్నాడు. తెరపై ఫార్ములాలు కనిపించిన వెంటనే, అవి వెంటనే గాజు కళ్ళుగా మారాయి. కాబట్టి TLA+ మిమ్మల్ని భయపెడితే, మీరు ఉపయోగించవచ్చు ప్లస్కాల్, ఇది ఒక రకమైన బొమ్మ ప్రోగ్రామింగ్ భాష. ప్లస్‌కాల్‌లోని వ్యక్తీకరణ ఏదైనా TLA+ వ్యక్తీకరణ కావచ్చు, అంటే పెద్దగా, ఏదైనా గణిత వ్యక్తీకరణ. అదనంగా, ప్లస్‌కాల్ నాన్-డిటర్మినిస్టిక్ అల్గారిథమ్‌ల కోసం సింటాక్స్‌ను కలిగి ఉంది. ప్లస్‌కాల్ ఏదైనా TLA+ వ్యక్తీకరణను వ్రాయగలదు కాబట్టి, ప్లస్‌కాల్ ఏదైనా నిజమైన ప్రోగ్రామింగ్ భాష కంటే చాలా వ్యక్తీకరణగా ఉంటుంది. తర్వాత, ప్లస్‌కాల్ సులభంగా చదవగలిగే 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

ఒక వ్యాఖ్యను జోడించండి