ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಕೋಡಿಂಗ್ಗಿಂತ ಹೆಚ್ಚು

ಇದು ಅನುವಾದ ಲೇಖನ ಸ್ಟ್ಯಾನ್‌ಫೋರ್ಡ್ ಸೆಮಿನಾರ್. ಆದರೆ ಅದಕ್ಕೂ ಮೊದಲು ಒಂದು ಸಣ್ಣ ಪರಿಚಯವಿದೆ. ಸೋಮಾರಿಗಳು ಹೇಗೆ ರೂಪುಗೊಳ್ಳುತ್ತಾರೆ? ಪ್ರತಿಯೊಬ್ಬರೂ ತಮ್ಮ ಸ್ನೇಹಿತ ಅಥವಾ ಸಹೋದ್ಯೋಗಿಯನ್ನು ತಮ್ಮ ಮಟ್ಟಕ್ಕೆ ತರಲು ಬಯಸುವ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ತಮ್ಮನ್ನು ತಾವು ಕಂಡುಕೊಂಡಿದ್ದಾರೆ, ಆದರೆ ಅದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಇದಲ್ಲದೆ, "ಇದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ" ನಿಮಗಾಗಿ ತುಂಬಾ ಅಲ್ಲ, ಆದರೆ ಅವನಿಗೆ: ಪ್ರಮಾಣದ ಒಂದು ಬದಿಯಲ್ಲಿ ಸಾಮಾನ್ಯ ಸಂಬಳ, ಕಾರ್ಯಗಳು ಮತ್ತು ಮುಂತಾದವುಗಳಿವೆ, ಮತ್ತು ಇನ್ನೊಂದೆಡೆ ಯೋಚಿಸುವ ಅವಶ್ಯಕತೆಯಿದೆ. ಆಲೋಚನೆಯು ಅಹಿತಕರ ಮತ್ತು ನೋವಿನಿಂದ ಕೂಡಿದೆ. ಅವನು ಬೇಗನೆ ಬಿಟ್ಟುಕೊಡುತ್ತಾನೆ ಮತ್ತು ತನ್ನ ಮೆದುಳನ್ನು ಬಳಸದೆ ಕೋಡ್ ಬರೆಯುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾನೆ. ಕಲಿತ ಅಸಹಾಯಕತೆಯ ತಡೆಗೋಡೆಯನ್ನು ಜಯಿಸಲು ಎಷ್ಟು ಪ್ರಯತ್ನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರಿತುಕೊಳ್ಳುತ್ತೀರಿ ಮತ್ತು ನೀವು ಅದನ್ನು ಸರಳವಾಗಿ ಮಾಡುವುದಿಲ್ಲ. ಸೋಮಾರಿಗಳು ಹೇಗೆ ರೂಪುಗೊಳ್ಳುತ್ತವೆ, ಅದನ್ನು ಗುಣಪಡಿಸಲು ಸಾಧ್ಯವಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಯಾರೂ ಇದನ್ನು ಮಾಡುವುದಿಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ.

ನಾನು ಅದನ್ನು ನೋಡಿದಾಗ ಲೆಸ್ಲಿ ಲ್ಯಾಂಪೋರ್ಟ್ (ಹೌದು, ಪಠ್ಯಪುಸ್ತಕಗಳಿಂದ ಅದೇ ಸ್ನೇಹಿತ) ರಷ್ಯಾಕ್ಕೆ ಬರುತ್ತದೆ ಮತ್ತು ವರದಿಯನ್ನು ನೀಡುತ್ತಿಲ್ಲ, ಆದರೆ ಪ್ರಶ್ನೋತ್ತರ ಅವಧಿ, ನಾನು ಸ್ವಲ್ಪ ಎಚ್ಚರದಿಂದಿದ್ದೆ. ಒಂದು ವೇಳೆ, ಲೆಸ್ಲಿ ವಿಶ್ವ-ಪ್ರಸಿದ್ಧ ವಿಜ್ಞಾನಿಯಾಗಿದ್ದು, ವಿತರಣಾ ಕಂಪ್ಯೂಟಿಂಗ್‌ನಲ್ಲಿ ಮೂಲ ಕೃತಿಗಳ ಲೇಖಕರಾಗಿದ್ದಾರೆ ಮತ್ತು ನೀವು ಅವರನ್ನು LaTeX - "ಲ್ಯಾಂಪ್‌ಪೋರ್ಟ್ ಟೆಕ್ಸ್" ನಲ್ಲಿ 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 ನಲ್ಲಿನ ಅಭಿವ್ಯಕ್ತಿಯು ಯಾವುದೇ TLA+ ಅಭಿವ್ಯಕ್ತಿಯಾಗಿರಬಹುದು, ಅಂದರೆ ಮೂಲಭೂತವಾಗಿ ಯಾವುದೇ ಗಣಿತದ ಅಭಿವ್ಯಕ್ತಿ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪ್ಲಸ್‌ಕಾಲ್ ನಿರ್ಣಾಯಕವಲ್ಲದ ಅಲ್ಗಾರಿದಮ್‌ಗಳಿಗೆ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ಹೊಂದಿದೆ. ಪ್ಲಸ್‌ಕಾಲ್ ಯಾವುದೇ TLA+ ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ಬರೆಯಬಹುದಾದ ಕಾರಣ, ಇದು ಯಾವುದೇ ನೈಜ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಿಂತ ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚು ಅಭಿವ್ಯಕ್ತವಾಗಿದೆ. ಮುಂದೆ, PlusCal ಅನ್ನು ಸುಲಭವಾಗಿ ಓದಲು TLA+ ವಿವರಣೆಯಾಗಿ ಸಂಕಲಿಸಲಾಗಿದೆ. ಸಂಕೀರ್ಣವಾದ ಪ್ಲಸ್‌ಕಾಲ್ ವಿವರಣೆಯು 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 ಸಮ್ಮೇಳನದಲ್ಲಿ ಇರುತ್ತಾರೆ. ಟಿಕೆಟ್ ಖರೀದಿಸಬಹುದು ಅಧಿಕೃತ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ.

ಮೂಲ: www.habr.com