પ્રોગ્રામિંગ કોડિંગ કરતાં વધુ છે

આ એક અનુવાદ લેખ છે સ્ટેનફોર્ડ સેમિનાર. પણ એ પહેલાં એક ટૂંકો પરિચય છે. ઝોમ્બિઓ કેવી રીતે રચાય છે? દરેક વ્યક્તિએ પોતાને એવી પરિસ્થિતિમાં શોધી કાઢ્યું છે કે જ્યાં તેઓ કોઈ મિત્ર અથવા સહકાર્યકરને તેમના સ્તર સુધી લાવવા માગે છે, પરંતુ તે કામ કરતું નથી. તદુપરાંત, "તે કામ કરતું નથી" તમારા માટે તેના માટે એટલું બધું નથી: સ્કેલની એક બાજુ સામાન્ય પગાર, કાર્યો અને તેથી વધુ છે, અને બીજી બાજુ વિચારવાની જરૂર છે. વિચારવું અપ્રિય અને પીડાદાયક છે. તે ઝડપથી હાર માની લે છે અને તેના મગજનો ઉપયોગ કર્યા વિના કોડ લખવાનું ચાલુ રાખે છે. તમે સમજો છો કે શીખેલી લાચારીના અવરોધને દૂર કરવા માટે કેટલી મહેનત કરવી પડે છે, અને તમે ફક્ત તે કરતા નથી. આ રીતે ઝોમ્બિઓ રચાય છે, જેનો ઇલાજ શક્ય લાગે છે, પરંતુ એવું લાગે છે કે કોઈ આ કરશે નહીં.

જ્યારે મેં તે જોયું લેસ્લી લેમપોર્ટ (હા, પાઠ્યપુસ્તકોમાંથી તે જ મિત્ર) રશિયા આવે છે અને રિપોર્ટ નથી આપી રહ્યો, પરંતુ સવાલ-જવાબનું સત્ર, હું થોડો સાવચેત હતો. માત્ર કિસ્સામાં, લેસ્લી એક વિશ્વ વિખ્યાત વૈજ્ઞાનિક છે, જે ડિસ્ટ્રિબ્યુટેડ કમ્પ્યુટિંગમાં મુખ્ય કાર્યોના લેખક છે, અને તમે તેમને 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. વાસ્તવિકતા આ મોડેલ સાથે કેવી રીતે તુલના કરે છે? મોડેલ પૂર્ણાંકો સાથે કાર્ય કરે છે, અને સી અથવા જાવામાં અમારી પાસે 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, એક પ્રકારની રમકડાની પ્રોગ્રામિંગ ભાષા છે. PlusCal માં અભિવ્યક્તિ કોઈપણ TLA+ અભિવ્યક્તિ હોઈ શકે છે, એટલે કે, મૂળભૂત રીતે કોઈપણ ગાણિતિક અભિવ્યક્તિ. વધુમાં, પ્લસકલ પાસે બિન-નિર્ધારિત અલ્ગોરિધમ્સ માટે સિન્ટેક્સ છે. કારણ કે 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.

જો મને પહેલેથી જ ખબર હોય કે કોડે શું કરવું જોઈએ તો મારે સ્પષ્ટીકરણ લખવાની જરૂર કેમ પડી? હકીકતમાં, મેં ફક્ત વિચાર્યું કે હું તેને જાણું છું. વધુમાં, એક સ્પષ્ટીકરણ સાથે, બહારના વ્યક્તિએ હવે કોડને સમજવાની જરૂર નથી કે તે બરાબર શું કરે છે. મારી પાસે એક નિયમ છે: ત્યાં કોઈ સામાન્ય નિયમો ન હોવા જોઈએ. અલબત્ત, આ નિયમમાં એક અપવાદ છે, આ એકમાત્ર સામાન્ય નિયમ છે જેને હું અનુસરું છું: કોડ શું કરે છે તેના સ્પષ્ટીકરણે લોકોને તે કોડનો ઉપયોગ કરતી વખતે જે જાણવાની જરૂર છે તે બધું જણાવવું જોઈએ.

તેથી પ્રોગ્રામરોને વિચારવા વિશે બરાબર શું જાણવાની જરૂર છે? શરૂઆતમાં, દરેક માટે સમાન: જો તમે લખતા નથી, તો તે ફક્ત તમને જ લાગે છે કે તમે વિચારી રહ્યા છો. ઉપરાંત, તમારે કોડ કરતા પહેલા વિચારવાની જરૂર છે, જેનો અર્થ છે કે તમે કોડ કરતા પહેલા તમારે લખવાની જરૂર છે. સ્પષ્ટીકરણ એ છે જે આપણે કોડિંગ શરૂ કરતા પહેલા લખીએ છીએ. કોઈપણ કોડ માટે સ્પષ્ટીકરણ જરૂરી છે જેનો ઉપયોગ કોઈપણ વ્યક્તિ કરી શકે છે અથવા બદલી શકે છે. અને આ "કોઈ" કોડ લખ્યાના એક મહિના પછી તેનો લેખક બની શકે છે. મોટા પ્રોગ્રામ્સ અને સિસ્ટમ્સ માટે, વર્ગો માટે, પદ્ધતિઓ માટે અને કેટલીકવાર એક પદ્ધતિના જટિલ વિભાગો માટે પણ સ્પષ્ટીકરણની જરૂર છે. તમારે કોડ વિશે બરાબર શું લખવું જોઈએ? તમારે તે શું કરે છે તેનું વર્ણન કરવાની જરૂર છે, એટલે કે, આ કોડનો ઉપયોગ કરનાર કોઈપણ માટે ઉપયોગી થઈ શકે તેવી કંઈક. કેટલીકવાર કોડ તેના ધ્યેયને બરાબર કેવી રીતે પ્રાપ્ત કરે છે તે સ્પષ્ટ કરવું પણ જરૂરી હોઈ શકે છે. જો આપણે એલ્ગોરિધમ કોર્સમાં આ પદ્ધતિમાંથી પસાર થઈએ, તો આપણે તેને અલ્ગોરિધમ કહીએ છીએ. જો તે કંઈક વધુ વિશિષ્ટ અને નવું હોય, તો અમે તેને ઉચ્ચ-સ્તરની ડિઝાઇન કહીએ છીએ. અહીં કોઈ ઔપચારિક તફાવત નથી: બંને પ્રોગ્રામના અમૂર્ત મોડલ છે.

તમારે કોડ સ્પષ્ટીકરણ કેવી રીતે લખવું જોઈએ? મુખ્ય વસ્તુ: તે કોડ કરતાં એક સ્તર ઊંચું હોવું જોઈએ. તે રાજ્યો અને વર્તનનું વર્ણન કરવું જોઈએ. તે કાર્ય માટે જરૂરી હોય તેટલું કડક હોવું જોઈએ. જો તમે કોઈ કાર્યને કેવી રીતે અમલમાં મૂકવું તેની સ્પષ્ટીકરણ લખી રહ્યાં છો, તો તે સ્યુડોકોડમાં અથવા PlusCal નો ઉપયોગ કરીને લખી શકાય છે. તમારે ઔપચારિક સ્પષ્ટીકરણોનો ઉપયોગ કરીને સ્પષ્ટીકરણો લખવાનું શીખવાની જરૂર છે. આ તમને જરૂરી કૌશલ્યો આપશે જે અનૌપચારિક બાબતોમાં પણ મદદ કરશે. તમે ઔપચારિક સ્પષ્ટીકરણો લખવાનું કેવી રીતે શીખી શકો? જ્યારે અમે પ્રોગ્રામ કરવાનું શીખ્યા, અમે પ્રોગ્રામ્સ લખ્યા અને પછી તેને ડીબગ કર્યા. અહીં તે જ વસ્તુ: તમારે સ્પષ્ટીકરણ લખવાની જરૂર છે, તેને મોડેલ તપાસનાર સાથે તપાસો અને ભૂલોને ઠીક કરો. TLA+ એ ઔપચારિક સ્પષ્ટીકરણ માટે શ્રેષ્ઠ ભાષા ન હોઈ શકે અને અન્ય ભાષા તમારી ચોક્કસ જરૂરિયાતો માટે વધુ સારી રીતે અનુકુળ હશે. TLA+ ની સૌથી મોટી વાત એ છે કે તે ગાણિતિક વિચારસરણી શીખવવાનું ઉત્તમ કામ કરે છે.

સ્પષ્ટીકરણ અને કોડને કેવી રીતે લિંક કરવું? ગાણિતિક ખ્યાલો અને તેમના અમલીકરણને જોડતી ટિપ્પણીઓનો ઉપયોગ કરવો. જો તમે આલેખ સાથે કામ કરો છો, તો પછી પ્રોગ્રામ સ્તરે તમારી પાસે નોડ્સની એરે અને લિંક્સની એરે હશે. તેથી તમારે લખવાની જરૂર છે કે આ પ્રોગ્રામિંગ સ્ટ્રક્ચર્સ દ્વારા ગ્રાફને બરાબર કેવી રીતે અમલમાં મૂકવામાં આવે છે.

એ નોંધવું જોઈએ કે ઉપરોક્તમાંથી કોઈ પણ કોડ લખવાની પ્રક્રિયાને લાગુ પડતું નથી. જ્યારે તમે કોડ લખો છો, એટલે કે, ત્રીજું પગલું કરો, તમારે પ્રોગ્રામ દ્વારા વિચારવાની અને વિચારવાની પણ જરૂર છે. જો સબટાસ્ક જટિલ અથવા સ્પષ્ટ ન હોય, તો તમારે તેના માટે સ્પષ્ટીકરણ લખવાની જરૂર છે. પરંતુ હું અહીં કોડ વિશે વાત કરી રહ્યો નથી. તમે કોઈપણ પ્રોગ્રામિંગ ભાષા, કોઈપણ પદ્ધતિનો ઉપયોગ કરી શકો છો, આ તેમના વિશે નથી. ઉપરાંત, ઉપરોક્તમાંથી કોઈ પણ તમારા કોડને ચકાસવાની અને ડીબગ કરવાની જરૂરિયાતને દૂર કરતું નથી. જો અમૂર્ત મોડેલ યોગ્ય રીતે લખાયેલ હોય તો પણ, તેના અમલીકરણમાં ભૂલો હોઈ શકે છે.

વિશિષ્ટતાઓ લખવી એ કોડિંગ પ્રક્રિયામાં એક વધારાનું પગલું છે. તેના માટે આભાર, ઘણી ભૂલો ઓછા પ્રયત્નો સાથે પકડી શકાય છે - અમે આ એમેઝોનના પ્રોગ્રામરોના અનુભવથી જાણીએ છીએ. વિશિષ્ટતાઓ સાથે, પ્રોગ્રામ્સની ગુણવત્તા વધુ બને છે. તો પછી શા માટે આપણે વારંવાર તેમના વિના જઈએ છીએ? કારણ કે લખવું મુશ્કેલ છે. પરંતુ લખવું મુશ્કેલ છે, કારણ કે આ માટે તમારે વિચારવાની જરૂર છે, અને વિચારવું પણ મુશ્કેલ છે. તમે વિચારી રહ્યાં છો તેવો ડોળ કરવો હંમેશા સરળ હોય છે. અહીં તમે દોડવા સાથે સમાનતા દોરી શકો છો - તમે જેટલું ઓછું દોડશો, તેટલું ધીમી દોડશો. તમારે તમારા સ્નાયુઓને તાલીમ આપવાની અને લેખનની પ્રેક્ટિસ કરવાની જરૂર છે. તે પ્રેક્ટિસ લે છે.

સ્પષ્ટીકરણ ખોટું હોઈ શકે છે. તમે ક્યાંક ભૂલ કરી હશે, અથવા જરૂરિયાતો બદલાઈ ગઈ હશે, અથવા સુધારણા કરવાની જરૂર પડી શકે છે. કોઈપણ કોડ કે જેનો કોઈપણ ઉપયોગ કરે છે તેને બદલવો પડશે, તેથી વહેલા કે પછી સ્પષ્ટીકરણ હવે પ્રોગ્રામ સાથે મેળ ખાશે નહીં. આદર્શ રીતે, આ કિસ્સામાં, તમારે એક નવું સ્પષ્ટીકરણ લખવાની અને કોડને સંપૂર્ણપણે ફરીથી લખવાની જરૂર છે. આપણે સારી રીતે જાણીએ છીએ કે આવું કોઈ કરતું નથી. વ્યવહારમાં, અમે કોડ પેચ કરીએ છીએ અને કદાચ સ્પષ્ટીકરણ અપડેટ કરીએ છીએ. જો આ વહેલા અથવા પછીથી થવાનું છે, તો પછી સ્પષ્ટીકરણો શા માટે લખો? સૌપ્રથમ, જે વ્યક્તિ તમારા કોડને સંપાદિત કરશે, તેના માટે સ્પષ્ટીકરણમાં દરેક વધારાના શબ્દનું વજન તેના સોનામાં મૂલ્યવાન હશે, અને આ વ્યક્તિ કદાચ તમે જ છો. જ્યારે હું મારો કોડ સંપાદિત કરું છું ત્યારે હું ઘણી વાર મારી જાતને પર્યાપ્ત ચોક્કસ ન હોવા માટે મારી જાતને લાત આપું છું. અને હું કોડ કરતાં વધુ સ્પષ્ટીકરણો લખું છું. તેથી, જ્યારે તમે કોડને સંપાદિત કરો છો, ત્યારે સ્પષ્ટીકરણને હંમેશા અપડેટ કરવાની જરૂર છે. બીજું, દરેક સંપાદન સાથે કોડ વધુ ખરાબ થાય છે, તેને વાંચવું અને જાળવવું વધુ મુશ્કેલ બને છે. આ એન્ટ્રોપીમાં વધારો છે. પરંતુ જો તમે સ્પષ્ટીકરણ સાથે પ્રારંભ ન કરો, તો પછી તમે લખો છો તે દરેક લાઇન એ સંપાદન હશે, અને કોડ શરૂઆતથી વાંચવા માટે ભારે અને મુશ્કેલ હશે.

તેમ જણાવ્યું હતું આઇઝનહોવર, કોઈ યુદ્ધ યોજના મુજબ જીત્યું ન હતું, અને કોઈ યુદ્ધ યોજના વિના જીત્યું ન હતું. અને તે યુદ્ધો વિશે કંઈક જાણતો હતો. એક અભિપ્રાય છે કે સ્પષ્ટીકરણો લખવા એ સમયનો બગાડ છે. કેટલીકવાર આ સાચું હોય છે, અને કાર્ય એટલું સરળ છે કે તેના વિશે વિચારવાનો કોઈ અર્થ નથી. પરંતુ તમારે હંમેશા યાદ રાખવું જોઈએ કે જ્યારે તમને સ્પષ્ટીકરણો ન લખવાની સલાહ આપવામાં આવે છે, તો તેનો અર્થ એ છે કે તમને વિચાર ન કરવાની સલાહ આપવામાં આવે છે. અને તમારે દર વખતે આ વિશે વિચારવું જોઈએ. કાર્ય વિશે વિચારવું એ ખાતરી આપતું નથી કે તમે ભૂલો નહીં કરો. જેમ આપણે જાણીએ છીએ, કોઈએ જાદુઈ લાકડીની શોધ કરી નથી, અને પ્રોગ્રામિંગ એ મુશ્કેલ કાર્ય છે. પરંતુ જો તમે કાર્ય દ્વારા વિચારતા નથી, તો તમે ભૂલો કરવાની ખાતરી આપી રહ્યાં છો.

તમે વિશેષ વેબસાઇટ પર TLA+ અને PlusCal વિશે વધુ વાંચી શકો છો, તમે મારા હોમ પેજ પરથી ત્યાં જઈ શકો છો લિંક. આ બધું મારા માટે છે, તમારા ધ્યાન બદલ આભાર.

કૃપા કરીને યાદ રાખો કે આ એક અનુવાદ છે. જ્યારે તમે ટિપ્પણીઓ લખો છો, ત્યારે યાદ રાખો કે લેખક તેમને વાંચશે નહીં. જો તમે ખરેખર લેખક સાથે ચેટ કરવા માંગતા હો, તો તે હાઈડ્રા 2019 કોન્ફરન્સમાં હશે, જે 11-12 જુલાઈ, 2019 ના રોજ સેન્ટ પીટર્સબર્ગમાં યોજાશે. ટિકિટ ખરીદી શકાય છે સત્તાવાર વેબસાઇટ પર.

સોર્સ: www.habr.com