കോഡിംഗിനേക്കാൾ കൂടുതലാണ് പ്രോഗ്രാമിംഗ്

ഈ ലേഖനം ഒരു വിവർത്തനമാണ് സ്റ്റാൻഫോർഡ് സെമിനാർ. എന്നാൽ അവൾക്ക് മുമ്പ് ഒരു ചെറിയ ആമുഖം. എങ്ങനെയാണ് സോമ്പികൾ രൂപപ്പെടുന്നത്? എല്ലാവരും ഒരു സുഹൃത്തിനെയോ സഹപ്രവർത്തകനെയോ അവരുടെ തലത്തിലേക്ക് ഉയർത്താൻ ആഗ്രഹിക്കുന്ന ഒരു സാഹചര്യത്തിലേക്ക് എത്തി, പക്ഷേ അത് പ്രവർത്തിക്കുന്നില്ല. “അത് പ്രവർത്തിക്കുന്നില്ല” എന്നത് അവനുമായി ഉള്ളതുപോലെ നിങ്ങളോടൊപ്പമല്ല: സ്കെയിലിന്റെ ഒരു വശത്ത് ഒരു സാധാരണ ശമ്പളം, ജോലികൾ തുടങ്ങിയവയാണ്, മറുവശത്ത്, ചിന്തിക്കേണ്ടതിന്റെ ആവശ്യകത. ചിന്തിക്കുന്നത് അസുഖകരവും വേദനാജനകവുമാണ്. അവൻ പെട്ടെന്ന് ഉപേക്ഷിക്കുകയും തലച്ചോറ് ഓണാക്കാതെ കോഡ് എഴുതുന്നത് തുടരുകയും ചെയ്യുന്നു. പഠിച്ച നിസ്സഹായതയുടെ തടസ്സം മറികടക്കാൻ എത്രമാത്രം പരിശ്രമിക്കണമെന്ന് നിങ്ങൾ സങ്കൽപ്പിക്കുക, നിങ്ങൾ അത് ചെയ്യുന്നില്ല. സോമ്പികൾ രൂപപ്പെടുന്നത് ഇങ്ങനെയാണ്, അത് സുഖപ്പെടുത്താൻ കഴിയുമെന്ന് തോന്നുന്നു, പക്ഷേ ആരും ഇത് ചെയ്യില്ലെന്ന് തോന്നുന്നു.

അത് കണ്ടപ്പോൾ ലെസ്ലി ലാംപോർട്ട് (അതെ, പാഠപുസ്തകങ്ങളിൽ നിന്നുള്ള അതേ സഖാവ്) റഷ്യയിലേക്ക് വരുന്നു കൂടാതെ ഒരു റിപ്പോർട്ട് ഉണ്ടാക്കുന്നില്ല, മറിച്ച് ഒരു ചോദ്യോത്തര സെഷനാണ്, ഞാൻ അൽപ്പം ശ്രദ്ധാലുവായിരുന്നു. ലെസ്ലി ഒരു ലോകപ്രശസ്ത ശാസ്ത്രജ്ഞനാണ്, വിതരണം ചെയ്ത കമ്പ്യൂട്ടിംഗിലെ അടിസ്ഥാന സൃഷ്ടികളുടെ രചയിതാവാണ്, കൂടാതെ നിങ്ങൾക്ക് LaTeX - "Lamport TeX" എന്ന വാക്കിലെ La അക്ഷരങ്ങളിലൂടെയും അദ്ദേഹത്തെ അറിയാൻ കഴിയും. ഭയപ്പെടുത്തുന്ന രണ്ടാമത്തെ ഘടകം അവന്റെ ആവശ്യകതയാണ്: വരുന്ന എല്ലാവരും (തികച്ചും സൗജന്യമായി) അവന്റെ രണ്ട് റിപ്പോർട്ടുകൾ മുൻകൂട്ടി കേൾക്കണം, അവയെക്കുറിച്ച് ഒരു ചോദ്യമെങ്കിലും കൊണ്ടുവരണം, അതിനുശേഷം മാത്രമേ വരൂ. ലാംപോർട്ട് എന്താണ് അവിടെ സംപ്രേക്ഷണം ചെയ്യുന്നതെന്ന് കാണാൻ ഞാൻ തീരുമാനിച്ചു - അത് മികച്ചതാണ്! സോമ്പികളെ സുഖപ്പെടുത്താനുള്ള മാന്ത്രിക ലിങ്ക്-പിൽ അത് തന്നെയാണ്. ഞാൻ നിങ്ങൾക്ക് മുന്നറിയിപ്പ് നൽകുന്നു: ടെക്‌സ്‌റ്റിൽ നിന്ന്, സൂപ്പർ-ഫ്‌ലെക്‌സിബിൾ മെത്തഡോളജികളെ ഇഷ്ടപ്പെടുന്നവർക്കും എഴുതിയത് പരീക്ഷിക്കാൻ ഇഷ്ടപ്പെടാത്തവർക്കും പ്രത്യേകിച്ച് കത്തിക്കാം.

ഹബ്രോകാറ്റിന് ശേഷം, വാസ്തവത്തിൽ, സെമിനാറിന്റെ വിവർത്തനം ആരംഭിക്കുന്നു. വായന ആസ്വദിക്കൂ!

നിങ്ങൾ ഏത് ജോലി ഏറ്റെടുത്താലും, നിങ്ങൾ എല്ലായ്പ്പോഴും മൂന്ന് ഘട്ടങ്ങളിലൂടെ കടന്നുപോകേണ്ടതുണ്ട്:

• നിങ്ങൾ എന്ത് ലക്ഷ്യം നേടണമെന്ന് തീരുമാനിക്കുക;
• നിങ്ങളുടെ ലക്ഷ്യം എങ്ങനെ കൈവരിക്കുമെന്ന് തീരുമാനിക്കുക;
• നിങ്ങളുടെ ലക്ഷ്യത്തിലേക്ക് വരൂ.

പ്രോഗ്രാമിംഗിനും ഇത് ബാധകമാണ്. ഞങ്ങൾ കോഡ് എഴുതുമ്പോൾ, നമുക്ക് ഇത് ആവശ്യമാണ്:

• പ്രോഗ്രാം എന്തുചെയ്യണമെന്ന് തീരുമാനിക്കുക;
• അതിന്റെ ചുമതല എങ്ങനെ നിർവഹിക്കണമെന്ന് നിർണ്ണയിക്കുക;
• അനുബന്ധ കോഡ് എഴുതുക.

അവസാന ഘട്ടം, തീർച്ചയായും, വളരെ പ്രധാനമാണ്, എന്നാൽ ഞാൻ ഇന്ന് അതിനെക്കുറിച്ച് സംസാരിക്കില്ല. പകരം, ഞങ്ങൾ ആദ്യത്തെ രണ്ടെണ്ണം ചർച്ച ചെയ്യും. ഓരോ പ്രോഗ്രാമറും പ്രവർത്തിക്കാൻ തുടങ്ങുന്നതിനുമുമ്പ് അവ നിർവഹിക്കുന്നു. നിങ്ങൾ എഴുതുന്നത് ബ്രൗസറോ ഡാറ്റാബേസോ എന്ന് തീരുമാനിച്ചിട്ടില്ലെങ്കിൽ നിങ്ങൾ എഴുതാൻ ഇരിക്കില്ല. ലക്ഷ്യത്തെക്കുറിച്ച് ഒരു നിശ്ചിത ആശയം ഉണ്ടായിരിക്കണം. പ്രോഗ്രാം കൃത്യമായി എന്തുചെയ്യുമെന്ന് നിങ്ങൾ തീർച്ചയായും ചിന്തിക്കുന്നു, കൂടാതെ കോഡ് എങ്ങനെയെങ്കിലും ഒരു ബ്രൗസറായി മാറുമെന്ന പ്രതീക്ഷയിൽ എങ്ങനെയെങ്കിലും എഴുതരുത്.

ഈ കോഡ് മുൻകൂട്ടി ചിന്തിക്കുന്നത് എങ്ങനെയാണ് കൃത്യമായി സംഭവിക്കുന്നത്? ഇതിനായി നാം എത്രമാത്രം പരിശ്രമിക്കണം? നമ്മൾ എത്ര സങ്കീർണ്ണമായ പ്രശ്നം പരിഹരിക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. ഒരു തെറ്റ്-സഹിഷ്ണുതയുള്ള വിതരണ സംവിധാനം എഴുതാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെന്ന് കരുതുക. ഈ സാഹചര്യത്തിൽ, കോഡ് ചെയ്യാൻ ഇരിക്കുന്നതിന് മുമ്പ് നമ്മൾ കാര്യങ്ങൾ ശ്രദ്ധാപൂർവ്വം ചിന്തിക്കണം. നമുക്ക് ഒരു പൂർണ്ണസംഖ്യ വേരിയബിളിനെ 1 കൊണ്ട് വർധിപ്പിക്കേണ്ടി വന്നാലോ? ഒറ്റനോട്ടത്തിൽ, ഇവിടെ എല്ലാം നിസ്സാരമാണ്, ഒരു ചിന്തയും ആവശ്യമില്ല, പക്ഷേ ഒരു ഓവർഫ്ലോ സംഭവിക്കാമെന്ന് ഞങ്ങൾ ഓർക്കുന്നു. അതിനാൽ, ഒരു പ്രശ്നം ലളിതമാണോ സങ്കീർണ്ണമാണോ എന്ന് മനസിലാക്കാൻ പോലും, നിങ്ങൾ ആദ്യം ചിന്തിക്കേണ്ടതുണ്ട്.

പ്രശ്നത്തിന് സാധ്യമായ പരിഹാരങ്ങളെക്കുറിച്ച് നിങ്ങൾ മുൻകൂട്ടി ചിന്തിക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് തെറ്റുകൾ ഒഴിവാക്കാനാകും. എന്നാൽ ഇതിന് നിങ്ങളുടെ ചിന്ത വ്യക്തമാകേണ്ടതുണ്ട്. ഇത് നേടുന്നതിന്, നിങ്ങളുടെ ചിന്തകൾ എഴുതേണ്ടതുണ്ട്. ഡിക്ക് ഗിൻഡൺ ഉദ്ധരണി എനിക്ക് വളരെ ഇഷ്ടമാണ്: "നിങ്ങൾ എഴുതുമ്പോൾ, നിങ്ങളുടെ ചിന്ത എത്രമാത്രം മന്ദഗതിയിലാണെന്ന് പ്രകൃതി നിങ്ങളെ കാണിക്കുന്നു." നിങ്ങൾ എഴുതുന്നില്ലെങ്കിൽ, നിങ്ങൾ ചിന്തിക്കുന്നുവെന്ന് മാത്രമേ നിങ്ങൾ കരുതൂ. കൂടാതെ നിങ്ങളുടെ ചിന്തകൾ സ്പെസിഫിക്കേഷനുകളുടെ രൂപത്തിൽ എഴുതേണ്ടതുണ്ട്.

സ്പെസിഫിക്കേഷനുകൾ പല പ്രവർത്തനങ്ങൾ ചെയ്യുന്നു, പ്രത്യേകിച്ച് വലിയ പദ്ധതികളിൽ. എന്നാൽ അവയിലൊന്നിനെക്കുറിച്ച് മാത്രമേ ഞാൻ സംസാരിക്കൂ: വ്യക്തമായി ചിന്തിക്കാൻ അവ നമ്മെ സഹായിക്കുന്നു. വ്യക്തമായി ചിന്തിക്കുന്നത് വളരെ പ്രധാനപ്പെട്ടതും വളരെ ബുദ്ധിമുട്ടുള്ളതുമാണ്, അതിനാൽ ഇവിടെ ഞങ്ങൾക്ക് എന്തെങ്കിലും സഹായം ആവശ്യമാണ്. ഏത് ഭാഷയിലാണ് നമ്മൾ സ്പെസിഫിക്കേഷനുകൾ എഴുതേണ്ടത്? പൊതുവേ, പ്രോഗ്രാമർമാർക്കുള്ള ആദ്യ ചോദ്യമാണിത്: ഏത് ഭാഷയിലാണ് ഞങ്ങൾ എഴുതുക. ഇതിന് കൃത്യമായ ഉത്തരം ഇല്ല: ഞങ്ങൾ പരിഹരിക്കുന്ന പ്രശ്നങ്ങൾ വളരെ വൈവിധ്യപൂർണ്ണമാണ്. ചിലർക്ക്, TLA+ എന്നത് ഞാൻ വികസിപ്പിച്ച ഒരു സ്പെസിഫിക്കേഷൻ ഭാഷയാണ്. മറ്റുള്ളവർക്ക്, ചൈനീസ് ഉപയോഗിക്കുന്നത് കൂടുതൽ സൗകര്യപ്രദമാണ്. എല്ലാം സാഹചര്യത്തെ ആശ്രയിച്ചിരിക്കുന്നു.

കൂടുതൽ പ്രധാനപ്പെട്ട മറ്റൊരു ചോദ്യം: വ്യക്തമായ ചിന്ത എങ്ങനെ നേടാം? ഉത്തരം: നമ്മൾ ശാസ്ത്രജ്ഞരെപ്പോലെ ചിന്തിക്കണം. കഴിഞ്ഞ 500 വർഷമായി സ്വയം തെളിയിച്ച ഒരു ചിന്താരീതിയാണിത്. ശാസ്ത്രത്തിൽ, ഞങ്ങൾ യാഥാർത്ഥ്യത്തിന്റെ ഗണിതശാസ്ത്ര മാതൃകകൾ നിർമ്മിക്കുന്നു. വാക്കിന്റെ കർശനമായ അർത്ഥത്തിൽ ജ്യോതിശാസ്ത്രം ഒരുപക്ഷേ ആദ്യത്തെ ശാസ്ത്രമായിരുന്നു. ജ്യോതിശാസ്ത്രത്തിൽ ഉപയോഗിക്കുന്ന ഗണിതശാസ്ത്ര മാതൃകയിൽ, ആകാശഗോളങ്ങൾ പിണ്ഡം, സ്ഥാനം, ആക്കം എന്നിവയുള്ള പോയിന്റുകളായി കാണപ്പെടുന്നു, വാസ്തവത്തിൽ അവ പർവതങ്ങളും സമുദ്രങ്ങളും, വേലിയേറ്റങ്ങളും വേലിയേറ്റങ്ങളും ഉള്ള വളരെ സങ്കീർണ്ണമായ വസ്തുക്കളാണ്. ഈ മാതൃക, മറ്റേതൊരു പോലെ, ചില പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ സൃഷ്ടിക്കപ്പെട്ടതാണ്. നിങ്ങൾക്ക് ഒരു ഗ്രഹം കണ്ടെത്തണമെങ്കിൽ നിങ്ങളുടെ ദൂരദർശിനി എവിടെ ചൂണ്ടിക്കാണിക്കണമെന്ന് കണ്ടെത്തുന്നതിന് ഇത് വളരെ നല്ലതാണ്. എന്നാൽ ഈ ഗ്രഹത്തിലെ കാലാവസ്ഥ പ്രവചിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഈ മോഡൽ പ്രവർത്തിക്കില്ല.

ഒരു മോഡലിന്റെ സവിശേഷതകൾ നിർണ്ണയിക്കാൻ ഗണിതശാസ്ത്രം നമ്മെ അനുവദിക്കുന്നു. ഈ ഗുണങ്ങൾ യാഥാർത്ഥ്യവുമായി എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്ന് ശാസ്ത്രം കാണിക്കുന്നു. നമുക്ക് നമ്മുടെ ശാസ്ത്രം, കമ്പ്യൂട്ടർ സയൻസ് എന്നിവയെക്കുറിച്ച് സംസാരിക്കാം. ഞങ്ങൾ പ്രവർത്തിക്കുന്ന യാഥാർത്ഥ്യം വിവിധ തരത്തിലുള്ള കമ്പ്യൂട്ടിംഗ് സിസ്റ്റങ്ങളാണ്: പ്രോസസ്സറുകൾ, ഗെയിം കൺസോളുകൾ, കമ്പ്യൂട്ടറുകൾ, എക്സിക്യൂട്ടിംഗ് പ്രോഗ്രാമുകൾ തുടങ്ങിയവ. ഒരു കമ്പ്യൂട്ടറിൽ ഒരു പ്രോഗ്രാം പ്രവർത്തിപ്പിക്കുന്നതിനെക്കുറിച്ച് ഞാൻ സംസാരിക്കും, എന്നാൽ വലിയതോതിൽ, ഈ നിഗമനങ്ങളെല്ലാം ഏത് കമ്പ്യൂട്ടിംഗ് സിസ്റ്റത്തിനും ബാധകമാണ്. ഞങ്ങളുടെ ശാസ്ത്രത്തിൽ, ഞങ്ങൾ നിരവധി വ്യത്യസ്ത മോഡലുകൾ ഉപയോഗിക്കുന്നു: ട്യൂറിംഗ് മെഷീൻ, ഭാഗികമായി ക്രമീകരിച്ച ഇവന്റുകൾ, കൂടാതെ മറ്റു പലതും.

എന്താണ് ഒരു പ്രോഗ്രാം? ഇത് സ്വതന്ത്രമായി പരിഗണിക്കാവുന്ന ഏതെങ്കിലും കോഡാണ്. നമുക്ക് ഒരു ബ്രൗസർ എഴുതണമെന്ന് കരുതുക. ഞങ്ങൾ മൂന്ന് ജോലികൾ ചെയ്യുന്നു: പ്രോഗ്രാമിന്റെ ഉപയോക്താവിന്റെ കാഴ്ച ഞങ്ങൾ രൂപകൽപ്പന ചെയ്യുന്നു, തുടർന്ന് പ്രോഗ്രാമിന്റെ ഉയർന്ന തലത്തിലുള്ള ഡയഗ്രം ഞങ്ങൾ എഴുതുന്നു, അവസാനം ഞങ്ങൾ കോഡ് എഴുതുന്നു. കോഡ് എഴുതുമ്പോൾ, ഒരു ടെക്സ്റ്റ് ഫോർമാറ്റർ എഴുതേണ്ടതുണ്ടെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുന്നു. ഇവിടെ നമുക്ക് വീണ്ടും മൂന്ന് പ്രശ്നങ്ങൾ പരിഹരിക്കേണ്ടതുണ്ട്: ഈ ടൂൾ എന്ത് ടെക്സ്റ്റ് തിരികെ നൽകുമെന്ന് നിർണ്ണയിക്കുക; ഫോർമാറ്റിംഗിനായി ഒരു അൽഗോരിതം തിരഞ്ഞെടുക്കുക; കോഡ് എഴുതുക. ഈ ടാസ്‌ക്കിന് അതിന്റേതായ ഉപടാസ്‌ക് ഉണ്ട്: വാക്കുകളിലേക്ക് ഒരു ഹൈഫൻ ശരിയായി തിരുകുക. ഞങ്ങൾ ഈ ഉപടാസ്‌ക് മൂന്ന് ഘട്ടങ്ങളിലൂടെ പരിഹരിക്കുകയും ചെയ്യുന്നു - നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, അവ പല തലങ്ങളിൽ ആവർത്തിക്കുന്നു.

ആദ്യ ഘട്ടം കൂടുതൽ വിശദമായി പരിഗണിക്കാം: പ്രോഗ്രാം എന്ത് പ്രശ്നം പരിഹരിക്കുന്നു. ഇവിടെ, ഞങ്ങൾ മിക്കപ്പോഴും ഒരു പ്രോഗ്രാമിനെ കുറച്ച് ഇൻപുട്ട് എടുക്കുകയും കുറച്ച് ഔട്ട്‌പുട്ട് ഉൽപ്പാദിപ്പിക്കുകയും ചെയ്യുന്ന ഒരു ഫംഗ്‌ഷനായി മാതൃകയാക്കുന്നു. ഗണിതശാസ്ത്രത്തിൽ, ഒരു ഫംഗ്‌ഷൻ സാധാരണയായി ജോഡികളുടെ ക്രമീകരിച്ച സെറ്റ് എന്നാണ് വിവരിക്കുന്നത്. ഉദാഹരണത്തിന്, സ്വാഭാവിക സംഖ്യകൾക്കുള്ള സ്ക്വയറിംഗ് ഫംഗ്‌ഷൻ സെറ്റ് {<0,0>, <1,1>, <2,4>, <3,9>, …} ആയി വിവരിക്കുന്നു. അത്തരമൊരു ഫംഗ്ഷന്റെ ഡൊമെയ്ൻ ഓരോ ജോഡിയുടെയും ആദ്യ ഘടകങ്ങളുടെ ഗണമാണ്, അതായത്, സ്വാഭാവിക സംഖ്യകൾ. ഒരു ഫംഗ്ഷൻ നിർവചിക്കുന്നതിന്, അതിന്റെ വ്യാപ്തിയും ഫോർമുലയും വ്യക്തമാക്കേണ്ടതുണ്ട്.

എന്നാൽ ഗണിതത്തിലെ ഫംഗ്‌ഷനുകൾ പ്രോഗ്രാമിംഗ് ഭാഷകളിലെ ഫംഗ്‌ഷനുകൾക്ക് തുല്യമല്ല. കണക്ക് വളരെ എളുപ്പമാണ്. സങ്കീർണ്ണമായ ഉദാഹരണങ്ങൾക്കായി എനിക്ക് സമയമില്ലാത്തതിനാൽ, നമുക്ക് ലളിതമായ ഒന്ന് പരിഗണിക്കാം: സിയിലെ ഒരു ഫംഗ്ഷൻ അല്ലെങ്കിൽ രണ്ട് പൂർണ്ണസംഖ്യകളുടെ ഏറ്റവും വലിയ പൊതു വിഭജനം നൽകുന്ന ജാവയിലെ ഒരു സ്റ്റാറ്റിക് രീതി. ഈ രീതിയുടെ സ്പെസിഫിക്കേഷനിൽ, നമ്മൾ എഴുതും: കണക്കുകൂട്ടുന്നു GCD(M,N) വാദങ്ങൾക്കായി M и Nഎവിടെ GCD(M,N) - പൂർണ്ണസംഖ്യകളുടെ ജോഡികളുടെ ഗണമാണ് ഡൊമെയ്‌നുള്ള ഒരു ഫംഗ്‌ഷൻ, റിട്ടേൺ മൂല്യം ഇവയാൽ ഹരിക്കാവുന്ന ഏറ്റവും വലിയ പൂർണ്ണസംഖ്യയാണ് M и N. ഈ മാതൃക യാഥാർത്ഥ്യവുമായി എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നു? മോഡൽ പൂർണ്ണസംഖ്യകളിൽ പ്രവർത്തിക്കുന്നു, സിയിലോ ജാവയിലോ നമുക്ക് 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+ നിങ്ങളെ ഭയപ്പെടുത്തുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് ഉപയോഗിക്കാം പ്ലസ്കാൽ, ഇതൊരു കളിപ്പാട്ട പ്രോഗ്രാമിംഗ് ഭാഷയാണ്. PlusCal-ലെ ഒരു പദപ്രയോഗം ഏതെങ്കിലും TLA+ എക്സ്പ്രഷൻ ആകാം, അതായത്, വലിയതോതിൽ, ഏത് ഗണിത പദപ്രയോഗവും. കൂടാതെ, പ്ലസ്കാലിന് നോൺ-ഡിറ്റർമിനിസ്റ്റിക് അൽഗോരിതങ്ങൾക്കുള്ള ഒരു വാക്യഘടനയുണ്ട്. PlusCal-ന് ഏത് TLA+ എക്‌സ്‌പ്രഷനും എഴുതാൻ കഴിയുന്നതിനാൽ, ഏതൊരു യഥാർത്ഥ പ്രോഗ്രാമിംഗ് ഭാഷയേക്കാളും പ്ലസ്കാൽ വളരെ പ്രകടമാണ്. അടുത്തതായി, എളുപ്പത്തിൽ വായിക്കാവുന്ന TLA+ സ്പെസിഫിക്കേഷനിലേക്ക് PlusCal സമാഹരിച്ചിരിക്കുന്നു. തീർച്ചയായും, സങ്കീർണ്ണമായ പ്ലസ്കാൽ സ്പെസിഫിക്കേഷൻ TLA +-ൽ ലളിതമായ ഒന്നായി മാറുമെന്ന് ഇതിനർത്ഥമില്ല - അവ തമ്മിലുള്ള കത്തിടപാടുകൾ വ്യക്തമാണ്, അധിക സങ്കീർണ്ണതയൊന്നും ഉണ്ടാകില്ല. അവസാനമായി, ഈ സ്പെസിഫിക്കേഷൻ TLA+ ടൂളുകൾ വഴി പരിശോധിക്കാവുന്നതാണ്. മൊത്തത്തിൽ, പ്ലസ്‌കാൽ ഗണിത ഭയത്തെ മറികടക്കാൻ സഹായിക്കും കൂടാതെ പ്രോഗ്രാമർമാർക്കും കമ്പ്യൂട്ടർ ശാസ്ത്രജ്ഞർക്കും പോലും മനസ്സിലാക്കാൻ എളുപ്പമാണ്. മുൻകാലങ്ങളിൽ, ഞാൻ അതിൽ അൽഗോരിതം പ്രസിദ്ധീകരിച്ചു (ഏകദേശം 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 കോൺഫറൻസിൽ പങ്കെടുക്കും. ടിക്കറ്റുകൾ വാങ്ങാം the ദ്യോഗിക വെബ്‌സൈറ്റിൽ.

അവലംബം: www.habr.com