ਪ੍ਰੋਗਰਾਮਿੰਗ ਕੋਡਿੰਗ ਤੋਂ ਵੱਧ ਹੈ

ਇਹ ਲੇਖ ਇੱਕ ਅਨੁਵਾਦ ਹੈ ਸਟੈਨਫੋਰਡ ਸੈਮੀਨਾਰ. ਪਰ ਉਸਦੀ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਜਾਣ-ਪਛਾਣ ਤੋਂ ਪਹਿਲਾਂ. ਜ਼ੋਂਬੀਜ਼ ਕਿਵੇਂ ਬਣਦੇ ਹਨ? ਹਰ ਕੋਈ ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਆ ਗਿਆ ਜਿੱਥੇ ਉਹ ਕਿਸੇ ਦੋਸਤ ਜਾਂ ਸਹਿਕਰਮੀ ਨੂੰ ਆਪਣੇ ਪੱਧਰ ਤੱਕ ਖਿੱਚਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਪਰ ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ. ਅਤੇ ਇਹ ਤੁਹਾਡੇ ਨਾਲ ਇੰਨਾ ਜ਼ਿਆਦਾ ਨਹੀਂ ਹੈ ਜਿੰਨਾ ਉਸਦੇ ਨਾਲ "ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ": ਪੈਮਾਨੇ ਦੇ ਇੱਕ ਪਾਸੇ ਇੱਕ ਆਮ ਤਨਖਾਹ, ਕੰਮ, ਅਤੇ ਹੋਰ, ਅਤੇ ਦੂਜੇ ਪਾਸੇ, ਸੋਚਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਸੋਚਣਾ ਕੋਝਾ ਅਤੇ ਦੁਖਦਾਈ ਹੈ। ਉਹ ਜਲਦੀ ਹਾਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਆਪਣੇ ਦਿਮਾਗ ਨੂੰ ਚਾਲੂ ਕੀਤੇ ਬਿਨਾਂ ਕੋਡ ਲਿਖਣਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ। ਤੁਸੀਂ ਕਲਪਨਾ ਕਰੋ ਕਿ ਸਿੱਖੀ ਬੇਬਸੀ ਦੀ ਰੁਕਾਵਟ ਨੂੰ ਦੂਰ ਕਰਨ ਲਈ ਕਿੰਨੀ ਮਿਹਨਤ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦੇ. ਇਸ ਤਰ੍ਹਾਂ ਜ਼ੋਂਬੀਜ਼ ਬਣਦੇ ਹਨ, ਜੋ ਲੱਗਦਾ ਹੈ, ਠੀਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਕੋਈ ਵੀ ਅਜਿਹਾ ਨਹੀਂ ਕਰੇਗਾ.

ਜਦੋਂ ਮੈਂ ਦੇਖਿਆ ਲੈਸਲੀ ਲੈਮਪੋਰਟ (ਹਾਂ, ਪਾਠ ਪੁਸਤਕਾਂ ਵਿੱਚੋਂ ਉਹੀ ਕਾਮਰੇਡ) ਰੂਸ ਨੂੰ ਆ ਅਤੇ ਇੱਕ ਰਿਪੋਰਟ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਪਰ ਇੱਕ ਸਵਾਲ-ਜਵਾਬ ਸੈਸ਼ਨ, ਮੈਂ ਥੋੜਾ ਸਾਵਧਾਨ ਸੀ। ਸਿਰਫ਼ ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਲੈਸਲੀ ਇੱਕ ਵਿਸ਼ਵ-ਪ੍ਰਸਿੱਧ ਵਿਗਿਆਨੀ ਹੈ, ਜੋ ਕਿ ਵਿਤਰਿਤ ਕੰਪਿਊਟਿੰਗ ਵਿੱਚ ਬੁਨਿਆਦੀ ਕੰਮਾਂ ਦਾ ਲੇਖਕ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਉਸਨੂੰ LaTeX - "Lamport TeX" ਵਿੱਚ La ਅੱਖਰਾਂ ਦੁਆਰਾ ਵੀ ਜਾਣ ਸਕਦੇ ਹੋ। ਦੂਜਾ ਚਿੰਤਾਜਨਕ ਕਾਰਕ ਉਸਦੀ ਜ਼ਰੂਰਤ ਹੈ: ਹਰ ਕੋਈ ਜੋ ਆਉਂਦਾ ਹੈ (ਬਿਲਕੁਲ ਮੁਫਤ) ਉਸ ਦੀਆਂ ਕੁਝ ਰਿਪੋਰਟਾਂ ਪਹਿਲਾਂ ਤੋਂ ਸੁਣਨਾ ਚਾਹੀਦਾ ਹੈ, ਉਹਨਾਂ 'ਤੇ ਘੱਟੋ ਘੱਟ ਇੱਕ ਪ੍ਰਸ਼ਨ ਲੈ ਕੇ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਤਦ ਹੀ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਮੈਂ ਇਹ ਦੇਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਲੈਮਪੋਰਟ ਉੱਥੇ ਕੀ ਪ੍ਰਸਾਰਿਤ ਕਰ ਰਿਹਾ ਸੀ - ਅਤੇ ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੈ! ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਚੀਜ਼ ਹੈ, ਜੋਮਬੀਜ਼ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਜਾਦੂ ਦੀ ਲਿੰਕ-ਗੋਲੀ। ਮੈਂ ਤੁਹਾਨੂੰ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹਾਂ: ਟੈਕਸਟ ਤੋਂ, ਸੁਪਰ-ਲਚਕਦਾਰ ਵਿਧੀਆਂ ਦੇ ਪ੍ਰੇਮੀ ਅਤੇ ਜੋ ਲਿਖਿਆ ਗਿਆ ਹੈ ਉਸ ਦੀ ਜਾਂਚ ਕਰਨਾ ਪਸੰਦ ਨਹੀਂ ਕਰਦੇ ਉਹ ਖਾਸ ਤੌਰ 'ਤੇ ਸਾੜ ਸਕਦੇ ਹਨ.

habrokat ਦੇ ਬਾਅਦ, ਅਸਲ ਵਿੱਚ, ਸੈਮੀਨਾਰ ਦਾ ਅਨੁਵਾਦ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ. ਪੜ੍ਹਨ ਦਾ ਆਨੰਦ ਮਾਣੋ!

ਤੁਸੀਂ ਜੋ ਵੀ ਕੰਮ ਕਰਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾ ਤਿੰਨ ਕਦਮਾਂ ਵਿੱਚੋਂ ਲੰਘਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:

• ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਟੀਚਾ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ;
• ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਆਪਣਾ ਟੀਚਾ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰੋਗੇ;
• ਆਪਣੇ ਟੀਚੇ ਤੇ ਆਓ.

ਇਹ ਪ੍ਰੋਗਰਾਮਿੰਗ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਅਸੀਂ ਕੋਡ ਲਿਖਦੇ ਹਾਂ, ਸਾਨੂੰ ਇਹ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:

• ਫੈਸਲਾ ਕਰੋ ਕਿ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ;
• ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਇਸਨੂੰ ਆਪਣਾ ਕੰਮ ਕਿਵੇਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ;
• ਅਨੁਸਾਰੀ ਕੋਡ ਲਿਖੋ।

ਆਖਰੀ ਕਦਮ, ਬੇਸ਼ੱਕ, ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਪਰ ਮੈਂ ਅੱਜ ਇਸ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰਾਂਗਾ. ਇਸ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਪਹਿਲੇ ਦੋ ਬਾਰੇ ਚਰਚਾ ਕਰਾਂਗੇ। ਹਰ ਪ੍ਰੋਗਰਾਮਰ ਕੰਮ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਉਦੋਂ ਤੱਕ ਲਿਖਣ ਲਈ ਨਹੀਂ ਬੈਠਦੇ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇਹ ਫੈਸਲਾ ਨਹੀਂ ਕਰ ਲੈਂਦੇ ਕਿ ਤੁਸੀਂ ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਜਾਂ ਡੇਟਾਬੇਸ ਲਿਖ ਰਹੇ ਹੋ। ਟੀਚੇ ਦਾ ਇੱਕ ਖਾਸ ਵਿਚਾਰ ਮੌਜੂਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਅਤੇ ਤੁਸੀਂ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਸੋਚਦੇ ਹੋ ਕਿ ਪ੍ਰੋਗਰਾਮ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰੇਗਾ, ਅਤੇ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਸ ਉਮੀਦ ਵਿੱਚ ਨਾ ਲਿਖੋ ਕਿ ਕੋਡ ਕਿਸੇ ਤਰ੍ਹਾਂ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਬਦਲ ਜਾਵੇਗਾ.

ਇਹ ਕੋਡ ਪੂਰਵ-ਸੋਚ ਬਿਲਕੁਲ ਕਿਵੇਂ ਵਾਪਰਦਾ ਹੈ? ਸਾਨੂੰ ਇਸ ਵਿੱਚ ਕਿੰਨੀ ਮਿਹਨਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ? ਇਹ ਸਭ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਕਿੰਨੀ ਗੁੰਝਲਦਾਰ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰ ਰਹੇ ਹਾਂ। ਮੰਨ ਲਓ ਕਿ ਅਸੀਂ ਇੱਕ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਵੰਡ ਪ੍ਰਣਾਲੀ ਲਿਖਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਾਨੂੰ ਕੋਡ ਕਰਨ ਲਈ ਬੈਠਣ ਤੋਂ ਪਹਿਲਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਧਿਆਨ ਨਾਲ ਸੋਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਦੋਂ ਕੀ ਜੇ ਸਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਪੂਰਨ ਅੰਕ ਵੇਰੀਏਬਲ ਨੂੰ 1 ਨਾਲ ਵਧਾਉਣ ਦੀ ਲੋੜ ਹੈ? ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਇੱਥੇ ਸਭ ਕੁਝ ਮਾਮੂਲੀ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਵਿਚਾਰ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਪਰ ਫਿਰ ਸਾਨੂੰ ਯਾਦ ਹੈ ਕਿ ਇੱਕ ਓਵਰਫਲੋ ਹੋ ਸਕਦਾ ਹੈ. ਇਸ ਲਈ, ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਕੀ ਕੋਈ ਸਮੱਸਿਆ ਸਧਾਰਨ ਹੈ ਜਾਂ ਗੁੰਝਲਦਾਰ, ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਸੋਚਣ ਦੀ ਲੋੜ ਹੈ।

ਜੇ ਤੁਸੀਂ ਸਮੱਸਿਆ ਦੇ ਸੰਭਵ ਹੱਲਾਂ ਬਾਰੇ ਪਹਿਲਾਂ ਹੀ ਸੋਚਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਗਲਤੀਆਂ ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ। ਪਰ ਇਸ ਲਈ ਤੁਹਾਡੀ ਸੋਚ ਸਪੱਸ਼ਟ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਆਪਣੇ ਵਿਚਾਰ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ. ਮੈਨੂੰ ਸੱਚਮੁੱਚ ਡਿਕ ਗਿੰਡਨ ਦਾ ਹਵਾਲਾ ਪਸੰਦ ਹੈ: "ਜਦੋਂ ਤੁਸੀਂ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਕੁਦਰਤ ਤੁਹਾਨੂੰ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਤੁਹਾਡੀ ਸੋਚ ਕਿੰਨੀ ਢਿੱਲੀ ਹੈ।" ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਲਿਖਦੇ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ ਸੋਚਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਸੋਚ ਰਹੇ ਹੋ. ਅਤੇ ਤੁਹਾਨੂੰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਆਪਣੇ ਵਿਚਾਰ ਲਿਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.

ਨਿਰਧਾਰਨ ਬਹੁਤ ਸਾਰੇ ਕਾਰਜ ਕਰਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ। ਪਰ ਮੈਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ ਇੱਕ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ: ਉਹ ਸਾਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸੋਚਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸੋਚਣਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਅਤੇ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਹੈ, ਇਸ ਲਈ ਇੱਥੇ ਸਾਨੂੰ ਕਿਸੇ ਮਦਦ ਦੀ ਲੋੜ ਹੈ। ਸਾਨੂੰ ਕਿਹੜੀ ਭਾਸ਼ਾ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਿਖਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ? ਆਮ ਤੌਰ 'ਤੇ, ਪ੍ਰੋਗਰਾਮਰਾਂ ਲਈ ਇਹ ਹਮੇਸ਼ਾ ਪਹਿਲਾ ਸਵਾਲ ਹੁੰਦਾ ਹੈ: ਅਸੀਂ ਕਿਹੜੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਾਂਗੇ। ਇਸ ਦਾ ਕੋਈ ਵੀ ਸਹੀ ਜਵਾਬ ਨਹੀਂ ਹੈ: ਜਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਅਸੀਂ ਹੱਲ ਕਰ ਰਹੇ ਹਾਂ ਉਹ ਬਹੁਤ ਭਿੰਨ ਹਨ। ਕੁਝ ਲਈ, TLA+ ਇੱਕ ਨਿਰਧਾਰਨ ਭਾਸ਼ਾ ਹੈ ਜੋ ਮੈਂ ਵਿਕਸਤ ਕੀਤੀ ਹੈ। ਦੂਜਿਆਂ ਲਈ, ਚੀਨੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਹੈ। ਸਭ ਕੁਝ ਸਥਿਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ.

ਇੱਕ ਹੋਰ ਸਵਾਲ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਸਪਸ਼ਟ ਸੋਚ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਵੇ? ਜਵਾਬ: ਸਾਨੂੰ ਵਿਗਿਆਨੀਆਂ ਵਾਂਗ ਸੋਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਸੋਚਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ ਜੋ ਪਿਛਲੇ 500 ਸਾਲਾਂ ਵਿੱਚ ਆਪਣੇ ਆਪ ਨੂੰ ਸਾਬਤ ਕਰ ਚੁੱਕਾ ਹੈ। ਵਿਗਿਆਨ ਵਿੱਚ, ਅਸੀਂ ਅਸਲੀਅਤ ਦੇ ਗਣਿਤਿਕ ਮਾਡਲ ਬਣਾਉਂਦੇ ਹਾਂ। ਖਗੋਲ-ਵਿਗਿਆਨ ਸ਼ਾਇਦ ਸ਼ਬਦ ਦੇ ਸਖ਼ਤ ਅਰਥਾਂ ਵਿਚ ਪਹਿਲਾ ਵਿਗਿਆਨ ਸੀ। ਖਗੋਲ-ਵਿਗਿਆਨ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਗਣਿਤਿਕ ਮਾਡਲ ਵਿੱਚ, ਆਕਾਸ਼ੀ ਪਦਾਰਥ ਪੁੰਜ, ਸਥਿਤੀ ਅਤੇ ਗਤੀ ਵਾਲੇ ਬਿੰਦੂਆਂ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਹਾਲਾਂਕਿ ਅਸਲ ਵਿੱਚ ਇਹ ਪਹਾੜਾਂ ਅਤੇ ਸਮੁੰਦਰਾਂ, ਲਹਿਰਾਂ ਅਤੇ ਲਹਿਰਾਂ ਦੇ ਨਾਲ ਬਹੁਤ ਹੀ ਗੁੰਝਲਦਾਰ ਵਸਤੂਆਂ ਹਨ। ਇਹ ਮਾਡਲ, ਕਿਸੇ ਹੋਰ ਵਾਂਗ, ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ. ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਨ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹੈ ਕਿ ਜੇਕਰ ਤੁਹਾਨੂੰ ਕੋਈ ਗ੍ਰਹਿ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਦੂਰਬੀਨ ਨੂੰ ਕਿੱਥੇ ਇਸ਼ਾਰਾ ਕਰਨਾ ਹੈ। ਪਰ ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਗ੍ਰਹਿ 'ਤੇ ਮੌਸਮ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਮਾਡਲ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ।

ਗਣਿਤ ਸਾਨੂੰ ਇੱਕ ਮਾਡਲ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਅਤੇ ਵਿਗਿਆਨ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਸਲੀਅਤ ਨਾਲ ਕਿਵੇਂ ਸਬੰਧਤ ਹਨ। ਸਾਡੇ ਵਿਗਿਆਨ ਦੀ ਗੱਲ ਕਰੀਏ, ਕੰਪਿਊਟਰ ਵਿਗਿਆਨ ਦੀ। ਅਸਲੀਅਤ ਜਿਸ ਨਾਲ ਅਸੀਂ ਕੰਮ ਕਰਦੇ ਹਾਂ ਉਹ ਹੈ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਕੰਪਿਊਟਿੰਗ ਸਿਸਟਮ: ਪ੍ਰੋਸੈਸਰ, ਗੇਮ ਕੰਸੋਲ, ਕੰਪਿਊਟਰ, ਐਗਜ਼ੀਕਿਊਟਿੰਗ ਪ੍ਰੋਗਰਾਮ, ਆਦਿ। ਮੈਂ ਕੰਪਿਊਟਰ 'ਤੇ ਪ੍ਰੋਗਰਾਮ ਚਲਾਉਣ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਸਾਰੇ ਸਿੱਟੇ ਕਿਸੇ ਵੀ ਕੰਪਿਊਟਿੰਗ ਸਿਸਟਮ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। ਸਾਡੇ ਵਿਗਿਆਨ ਵਿੱਚ, ਅਸੀਂ ਬਹੁਤ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਮਾਡਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ: ਟਿਊਰਿੰਗ ਮਸ਼ੀਨ, ਘਟਨਾਵਾਂ ਦੇ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਆਰਡਰ ਕੀਤੇ ਸੈੱਟ, ਅਤੇ ਕਈ ਹੋਰ।

ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਕੀ ਹੈ? ਇਹ ਕੋਈ ਵੀ ਕੋਡ ਹੈ ਜਿਸਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਵਿਚਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਮੰਨ ਲਓ ਕਿ ਸਾਨੂੰ ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ। ਅਸੀਂ ਤਿੰਨ ਕੰਮ ਕਰਦੇ ਹਾਂ: ਅਸੀਂ ਪ੍ਰੋਗਰਾਮ ਦੇ ਉਪਭੋਗਤਾ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹਾਂ, ਫਿਰ ਅਸੀਂ ਪ੍ਰੋਗਰਾਮ ਦਾ ਉੱਚ-ਪੱਧਰੀ ਚਿੱਤਰ ਲਿਖਦੇ ਹਾਂ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਅਸੀਂ ਕੋਡ ਲਿਖਦੇ ਹਾਂ। ਜਿਵੇਂ ਹੀ ਅਸੀਂ ਕੋਡ ਲਿਖਦੇ ਹਾਂ, ਸਾਨੂੰ ਅਹਿਸਾਸ ਹੁੰਦਾ ਹੈ ਕਿ ਸਾਨੂੰ ਇੱਕ ਟੈਕਸਟ ਫਾਰਮੈਟਰ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ। ਇੱਥੇ ਸਾਨੂੰ ਤਿੰਨ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ: ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਇਹ ਸੰਦ ਕਿਹੜਾ ਟੈਕਸਟ ਵਾਪਸ ਕਰੇਗਾ; ਫਾਰਮੈਟਿੰਗ ਲਈ ਇੱਕ ਐਲਗੋਰਿਦਮ ਚੁਣੋ; ਕੋਡ ਲਿਖੋ. ਇਸ ਕਾਰਜ ਦਾ ਆਪਣਾ ਉਪ-ਕਾਰਜ ਹੈ: ਸ਼ਬਦਾਂ ਵਿੱਚ ਸਹੀ ਢੰਗ ਨਾਲ ਇੱਕ ਹਾਈਫਨ ਸ਼ਾਮਲ ਕਰੋ। ਅਸੀਂ ਇਸ ਸਬਟਾਸਕ ਨੂੰ ਤਿੰਨ ਪੜਾਵਾਂ ਵਿੱਚ ਵੀ ਹੱਲ ਕਰਦੇ ਹਾਂ - ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਉਹ ਕਈ ਪੱਧਰਾਂ 'ਤੇ ਦੁਹਰਾਉਂਦੇ ਹਨ।

ਆਉ ਪਹਿਲੇ ਪੜਾਅ 'ਤੇ ਵਧੇਰੇ ਵਿਸਥਾਰ ਨਾਲ ਵਿਚਾਰ ਕਰੀਏ: ਪ੍ਰੋਗਰਾਮ ਕਿਹੜੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ. ਇੱਥੇ, ਅਸੀਂ ਅਕਸਰ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਇੱਕ ਫੰਕਸ਼ਨ ਵਜੋਂ ਮਾਡਲ ਕਰਦੇ ਹਾਂ ਜੋ ਕੁਝ ਇਨਪੁਟ ਲੈਂਦਾ ਹੈ ਅਤੇ ਕੁਝ ਆਉਟਪੁੱਟ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਗਣਿਤ ਵਿੱਚ, ਇੱਕ ਫੰਕਸ਼ਨ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਜੋੜਿਆਂ ਦੇ ਇੱਕ ਕ੍ਰਮਬੱਧ ਸਮੂਹ ਵਜੋਂ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਕੁਦਰਤੀ ਸੰਖਿਆਵਾਂ ਲਈ ਵਰਗ ਫੰਕਸ਼ਨ ਨੂੰ ਸੈੱਟ {<0,0>, <1,1>, <2,4>, <3,9>, …} ਵਜੋਂ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਅਜਿਹੇ ਫੰਕਸ਼ਨ ਦਾ ਡੋਮੇਨ ਹਰੇਕ ਜੋੜੇ ਦੇ ਪਹਿਲੇ ਤੱਤਾਂ ਦਾ ਸੈੱਟ ਹੁੰਦਾ ਹੈ, ਯਾਨੀ ਕੁਦਰਤੀ ਸੰਖਿਆਵਾਂ। ਕਿਸੇ ਫੰਕਸ਼ਨ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਇਸਦੇ ਦਾਇਰੇ ਅਤੇ ਫਾਰਮੂਲੇ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਪਰ ਗਣਿਤ ਵਿੱਚ ਫੰਕਸ਼ਨ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਫੰਕਸ਼ਨਾਂ ਵਾਂਗ ਨਹੀਂ ਹੁੰਦੇ। ਗਣਿਤ ਬਹੁਤ ਸੌਖਾ ਹੈ. ਕਿਉਂਕਿ ਮੇਰੇ ਕੋਲ ਗੁੰਝਲਦਾਰ ਉਦਾਹਰਨਾਂ ਲਈ ਸਮਾਂ ਨਹੀਂ ਹੈ, ਆਓ ਇੱਕ ਸਧਾਰਨ ਇੱਕ 'ਤੇ ਵਿਚਾਰ ਕਰੀਏ: C ਵਿੱਚ ਇੱਕ ਫੰਕਸ਼ਨ ਜਾਂ Java ਵਿੱਚ ਇੱਕ ਸਥਿਰ ਵਿਧੀ ਜੋ ਦੋ ਪੂਰਨ ਅੰਕਾਂ ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਸਾਂਝਾ ਭਾਜਕ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਇਸ ਵਿਧੀ ਦੇ ਨਿਰਧਾਰਨ ਵਿੱਚ, ਅਸੀਂ ਲਿਖਾਂਗੇ: ਗਣਨਾ ਕਰਦਾ ਹੈ GCD(M,N) ਦਲੀਲਾਂ ਲਈ M и Nਕਿੱਥੇ GCD(M,N) - ਇੱਕ ਫੰਕਸ਼ਨ ਜਿਸਦਾ ਡੋਮੇਨ ਪੂਰਨ ਅੰਕਾਂ ਦੇ ਜੋੜਿਆਂ ਦਾ ਸੈੱਟ ਹੈ, ਅਤੇ ਵਾਪਸੀ ਮੁੱਲ ਸਭ ਤੋਂ ਵੱਡਾ ਪੂਰਨ ਅੰਕ ਹੈ ਜੋ ਇਸ ਦੁਆਰਾ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ M и N. ਇਹ ਮਾਡਲ ਅਸਲੀਅਤ ਨਾਲ ਕਿਵੇਂ ਸੰਬੰਧਿਤ ਹੈ? ਮਾਡਲ ਪੂਰਨ ਅੰਕਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ C ਜਾਂ Java ਵਿੱਚ ਸਾਡੇ ਕੋਲ 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+ ਸਮੀਕਰਨ ਲਿਖ ਸਕਦਾ ਹੈ, PlusCal ਕਿਸੇ ਵੀ ਅਸਲ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਭਾਵਪੂਰਤ ਹੈ। ਅੱਗੇ, PlusCal ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਪੜ੍ਹਨਯੋਗ TLA+ ਨਿਰਧਾਰਨ ਵਿੱਚ ਕੰਪਾਇਲ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ, ਬੇਸ਼ੱਕ, ਗੁੰਝਲਦਾਰ ਪਲੱਸਕਲ ਨਿਰਧਾਰਨ TLA + 'ਤੇ ਇੱਕ ਸਧਾਰਨ ਵਿੱਚ ਬਦਲ ਜਾਵੇਗਾ - ਬਸ ਉਹਨਾਂ ਵਿਚਕਾਰ ਪੱਤਰ ਵਿਹਾਰ ਸਪੱਸ਼ਟ ਹੈ, ਕੋਈ ਵਾਧੂ ਗੁੰਝਲਤਾ ਨਹੀਂ ਹੋਵੇਗੀ। ਅੰਤ ਵਿੱਚ, ਇਸ ਨਿਰਧਾਰਨ ਨੂੰ TLA+ ਟੂਲਸ ਦੁਆਰਾ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਕੁੱਲ ਮਿਲਾ ਕੇ, PlusCal ਗਣਿਤ ਦੇ ਫੋਬੀਆ ਨੂੰ ਦੂਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਪ੍ਰੋਗਰਾਮਰਾਂ ਅਤੇ ਕੰਪਿਊਟਰ ਵਿਗਿਆਨੀਆਂ ਲਈ ਵੀ ਸਮਝਣਾ ਆਸਾਨ ਹੈ। ਅਤੀਤ ਵਿੱਚ, ਮੈਂ ਇਸ 'ਤੇ ਕੁਝ ਸਮੇਂ (ਲਗਭਗ 10 ਸਾਲ) ਲਈ ਐਲਗੋਰਿਦਮ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ.

ਸ਼ਾਇਦ ਕੋਈ ਇਤਰਾਜ਼ ਕਰੇਗਾ ਕਿ TLA + ਅਤੇ PlusCal ਗਣਿਤ ਹਨ, ਅਤੇ ਗਣਿਤ ਸਿਰਫ ਖੋਜੀਆਂ ਉਦਾਹਰਣਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਭਿਆਸ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਕਿਸਮਾਂ, ਪ੍ਰਕਿਰਿਆਵਾਂ, ਵਸਤੂਆਂ ਅਤੇ ਹੋਰਾਂ ਨਾਲ ਇੱਕ ਅਸਲੀ ਭਾਸ਼ਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਗਲਤ ਹੈ। ਇੱਥੇ ਕ੍ਰਿਸ ਨਿਊਕੌਂਬ, ਜੋ ਐਮਾਜ਼ਾਨ 'ਤੇ ਕੰਮ ਕਰਦਾ ਸੀ, ਲਿਖਦਾ ਹੈ: "ਅਸੀਂ ਦਸ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟਾਂ 'ਤੇ TLA+ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ, ਅਤੇ ਹਰੇਕ ਮਾਮਲੇ ਵਿੱਚ, ਇਸਦੀ ਵਰਤੋਂ ਨਾਲ ਵਿਕਾਸ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਫਰਕ ਆਇਆ ਹੈ ਕਿਉਂਕਿ ਅਸੀਂ ਉਤਪਾਦਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਖਤਰਨਾਕ ਬੱਗ ਫੜਨ ਦੇ ਯੋਗ ਸੀ, ਅਤੇ ਕਿਉਂਕਿ ਇਸਨੇ ਸਾਨੂੰ ਸੂਝ ਅਤੇ ਵਿਸ਼ਵਾਸ ਦਿੱਤਾ ਹੈ ਜਿਸਦੀ ਸਾਨੂੰ ਲੋੜ ਸੀ। ਪ੍ਰੋਗਰਾਮ ਦੀ ਸੱਚਾਈ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤੇ ਬਿਨਾਂ ਹਮਲਾਵਰ ਪ੍ਰਦਰਸ਼ਨ ਅਨੁਕੂਲਤਾ ਬਣਾਓ". ਤੁਸੀਂ ਅਕਸਰ ਸੁਣ ਸਕਦੇ ਹੋ ਕਿ ਰਸਮੀ ਢੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਸਾਨੂੰ ਅਕੁਸ਼ਲ ਕੋਡ ਮਿਲਦਾ ਹੈ - ਅਭਿਆਸ ਵਿੱਚ, ਸਭ ਕੁਝ ਬਿਲਕੁਲ ਉਲਟ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇੱਕ ਰਾਏ ਹੈ ਕਿ ਪ੍ਰਬੰਧਕ ਰਸਮੀ ਤਰੀਕਿਆਂ ਦੀ ਜ਼ਰੂਰਤ ਬਾਰੇ ਯਕੀਨ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਭਾਵੇਂ ਪ੍ਰੋਗਰਾਮਰ ਉਹਨਾਂ ਦੀ ਉਪਯੋਗਤਾ ਬਾਰੇ ਯਕੀਨ ਰੱਖਦੇ ਹੋਣ। ਅਤੇ ਨਿਊਕੌਂਬ ਲਿਖਦਾ ਹੈ: "ਪ੍ਰਬੰਧਕ ਹੁਣ TLA + ਲਈ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਿਖਣ ਲਈ ਸਖ਼ਤ ਜ਼ੋਰ ਦੇ ਰਹੇ ਹਨ, ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਇਸਦੇ ਲਈ ਸਮਾਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ". ਇਸ ਲਈ ਜਦੋਂ ਪ੍ਰਬੰਧਕ ਦੇਖਦੇ ਹਨ ਕਿ TLA+ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਉਹ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਵਿੱਚ ਖੁਸ਼ ਹੁੰਦੇ ਹਨ। ਕ੍ਰਿਸ ਨਿਊਕੌਂਬ ਨੇ ਇਹ ਲਗਭਗ ਛੇ ਮਹੀਨੇ ਪਹਿਲਾਂ (ਅਕਤੂਬਰ 2014) ਲਿਖਿਆ ਸੀ, ਪਰ ਹੁਣ, ਜਿੱਥੋਂ ਤੱਕ ਮੈਨੂੰ ਪਤਾ ਹੈ, TLA+ ਦੀ ਵਰਤੋਂ 14 ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਨਾ ਕਿ 10 ਵਿੱਚ। ਇੱਕ ਹੋਰ ਉਦਾਹਰਣ XBox 360 ਦੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਹੈ। ਇੱਕ ਇੰਟਰਨ ਚਾਰਲਸ ਥੈਕਰ ਕੋਲ ਆਇਆ ਅਤੇ ਮੈਮੋਰੀ ਸਿਸਟਮ ਲਈ ਨਿਰਧਾਰਨ ਲਿਖਿਆ. ਇਸ ਨਿਰਧਾਰਨ ਲਈ ਧੰਨਵਾਦ, ਇੱਕ ਬੱਗ ਪਾਇਆ ਗਿਆ ਜੋ ਕਿ ਨਹੀਂ ਤਾਂ ਕਿਸੇ ਦਾ ਧਿਆਨ ਨਹੀਂ ਜਾਵੇਗਾ, ਅਤੇ ਜਿਸ ਕਾਰਨ ਹਰ XBox 360 ਚਾਰ ਘੰਟਿਆਂ ਦੀ ਵਰਤੋਂ ਤੋਂ ਬਾਅਦ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਵੇਗਾ। IBM ਇੰਜੀਨੀਅਰਾਂ ਨੇ ਪੁਸ਼ਟੀ ਕੀਤੀ ਕਿ ਉਨ੍ਹਾਂ ਦੇ ਟੈਸਟਾਂ ਵਿੱਚ ਇਹ ਬੱਗ ਨਹੀਂ ਮਿਲਿਆ ਹੋਵੇਗਾ।

ਤੁਸੀਂ ਇੰਟਰਨੈਟ 'ਤੇ TLA + ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਪਰ ਆਓ ਹੁਣ ਗੈਰ-ਰਸਮੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਾਰੇ ਗੱਲ ਕਰੀਏ। ਸਾਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਸਾਂਝੇ ਭਾਜਕ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਘੱਟ ਹੀ ਲਿਖਣਾ ਪੈਂਦਾ ਹੈ। ਬਹੁਤ ਜ਼ਿਆਦਾ ਅਕਸਰ ਅਸੀਂ ਪ੍ਰੋਗਰਾਮ ਲਿਖਦੇ ਹਾਂ ਜਿਵੇਂ ਕਿ ਪ੍ਰੀਟੀ-ਪ੍ਰਿੰਟਰ ਟੂਲ ਜੋ ਮੈਂ TLA+ ਲਈ ਲਿਖਿਆ ਸੀ। ਸਰਲ ਪ੍ਰੋਸੈਸਿੰਗ ਤੋਂ ਬਾਅਦ, TLA + ਕੋਡ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:

ਪਰ ਉਪਰੋਕਤ ਉਦਾਹਰਨ ਵਿੱਚ, ਉਪਭੋਗਤਾ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਸੰਜੋਗ ਅਤੇ ਬਰਾਬਰ ਚਿੰਨ੍ਹਾਂ ਨੂੰ ਇਕਸਾਰ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ। ਇਸ ਲਈ ਸਹੀ ਫਾਰਮੈਟਿੰਗ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗੀ:

ਆਓ ਇੱਕ ਹੋਰ ਉਦਾਹਰਣ ਤੇ ਵਿਚਾਰ ਕਰੀਏ:

ਇੱਥੇ, ਇਸਦੇ ਉਲਟ, ਸਰੋਤ ਵਿੱਚ ਬਰਾਬਰ, ਜੋੜ ਅਤੇ ਗੁਣਾ ਚਿੰਨ੍ਹਾਂ ਦੀ ਇਕਸਾਰਤਾ ਬੇਤਰਤੀਬ ਸੀ, ਇਸਲਈ ਸਰਲ ਪ੍ਰਕਿਰਿਆ ਕਾਫ਼ੀ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਸਹੀ ਫਾਰਮੈਟਿੰਗ ਦੀ ਕੋਈ ਸਹੀ ਗਣਿਤਿਕ ਪਰਿਭਾਸ਼ਾ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇਸ ਮਾਮਲੇ ਵਿੱਚ "ਸਹੀ" ਦਾ ਮਤਲਬ ਹੈ "ਉਪਭੋਗਤਾ ਕੀ ਚਾਹੁੰਦਾ ਹੈ", ਅਤੇ ਇਹ ਗਣਿਤਿਕ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਸੱਚ ਦੀ ਪਰਿਭਾਸ਼ਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਨਿਰਧਾਰਨ ਬੇਕਾਰ ਹੈ। ਪਰ ਅਜਿਹਾ ਨਹੀਂ ਹੈ। ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿ ਅਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਸਾਨੂੰ ਇਸ ਬਾਰੇ ਸੋਚਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ - ਇਸਦੇ ਉਲਟ, ਸਾਨੂੰ ਇਸ ਵਿੱਚ ਹੋਰ ਵੀ ਜ਼ਿਆਦਾ ਮਿਹਨਤ ਕਰਨੀ ਪਵੇਗੀ। ਵਿਸ਼ੇਸ਼ਤਾ ਇੱਥੇ ਖਾਸ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੈ. ਢਾਂਚਾਗਤ ਪ੍ਰਿੰਟਿੰਗ ਲਈ ਅਨੁਕੂਲ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਅਸੰਭਵ ਹੈ, ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਸਾਨੂੰ ਇਸਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਚੇਤਨਾ ਦੀ ਇੱਕ ਧਾਰਾ ਵਜੋਂ ਕੋਡ ਲਿਖਣਾ ਇੱਕ ਚੰਗੀ ਗੱਲ ਨਹੀਂ ਹੈ. ਅੰਤ ਵਿੱਚ, ਮੈਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਦੇ ਨਾਲ ਛੇ ਨਿਯਮਾਂ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਲਿਖੀ ਟਿੱਪਣੀ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ java ਫਾਇਲ ਵਿੱਚ. ਇੱਥੇ ਨਿਯਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ: a left-comment token is LeftComment aligned with its covering token. ਇਹ ਨਿਯਮ ਗਣਿਤ ਦੀ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ: LeftComment aligned, left-comment и covering token - ਪਰਿਭਾਸ਼ਾਵਾਂ ਵਾਲੇ ਸ਼ਬਦ। ਇਸ ਤਰ੍ਹਾਂ ਗਣਿਤ-ਸ਼ਾਸਤਰੀ ਗਣਿਤ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ: ਉਹ ਸ਼ਰਤਾਂ ਦੀ ਪਰਿਭਾਸ਼ਾ ਲਿਖਦੇ ਹਨ ਅਤੇ, ਉਹਨਾਂ ਦੇ ਅਧਾਰ ਤੇ, ਨਿਯਮ। ਅਜਿਹੇ ਨਿਰਧਾਰਨ ਦਾ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਕੋਡ ਦੀਆਂ 850 ਲਾਈਨਾਂ ਨਾਲੋਂ ਛੇ ਨਿਯਮਾਂ ਨੂੰ ਸਮਝਣਾ ਅਤੇ ਡੀਬੱਗ ਕਰਨਾ ਬਹੁਤ ਸੌਖਾ ਹੈ। ਮੈਨੂੰ ਇਹ ਕਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹਨਾਂ ਨਿਯਮਾਂ ਨੂੰ ਲਿਖਣਾ ਆਸਾਨ ਨਹੀਂ ਸੀ, ਇਹਨਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਕਾਫ਼ੀ ਸਮਾਂ ਲੱਗਿਆ। ਖਾਸ ਤੌਰ 'ਤੇ ਇਸ ਉਦੇਸ਼ ਲਈ, ਮੈਂ ਇੱਕ ਕੋਡ ਲਿਖਿਆ ਜਿਸ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਕਿ ਕਿਹੜਾ ਨਿਯਮ ਵਰਤਿਆ ਗਿਆ ਸੀ। ਇਸ ਤੱਥ ਦਾ ਧੰਨਵਾਦ ਕਿ ਮੈਂ ਇਹਨਾਂ ਛੇ ਨਿਯਮਾਂ ਦੀ ਕਈ ਉਦਾਹਰਣਾਂ 'ਤੇ ਜਾਂਚ ਕੀਤੀ, ਮੈਨੂੰ ਕੋਡ ਦੀਆਂ 850 ਲਾਈਨਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਸੀ, ਅਤੇ ਬੱਗ ਲੱਭਣਾ ਕਾਫ਼ੀ ਆਸਾਨ ਹੋ ਗਿਆ। Java ਕੋਲ ਇਸਦੇ ਲਈ ਵਧੀਆ ਟੂਲ ਹਨ। ਜੇਕਰ ਮੈਂ ਹੁਣੇ ਹੀ ਕੋਡ ਲਿਖਿਆ ਹੁੰਦਾ, ਤਾਂ ਇਹ ਮੈਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲਵੇਗਾ, ਅਤੇ ਫਾਰਮੈਟਿੰਗ ਮਾੜੀ ਗੁਣਵੱਤਾ ਵਾਲੀ ਹੋਣੀ ਸੀ।

ਇੱਕ ਰਸਮੀ ਨਿਰਧਾਰਨ ਕਿਉਂ ਨਹੀਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਸੀ? ਇਕ ਪਾਸੇ, ਸਹੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਇੱਥੇ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ. ਢਾਂਚਾਗਤ ਪ੍ਰਿੰਟਆਊਟ ਕਿਸੇ ਨੂੰ ਵੀ ਖੁਸ਼ ਨਹੀਂ ਕਰਨ ਲਈ ਪਾਬੰਦ ਹਨ, ਇਸਲਈ ਮੈਨੂੰ ਸਾਰੀਆਂ ਅਜੀਬ ਸਥਿਤੀਆਂ ਵਿੱਚ ਇਸ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਇਸ ਤੋਂ ਵੀ ਮਹੱਤਵਪੂਰਨ ਤੱਥ ਇਹ ਹੈ ਕਿ ਮੇਰੇ ਕੋਲ ਲੋੜੀਂਦੇ ਔਜ਼ਾਰ ਨਹੀਂ ਸਨ। TLA+ ਮਾਡਲ ਚੈਕਰ ਇੱਥੇ ਬੇਕਾਰ ਹੈ, ਇਸ ਲਈ ਮੈਨੂੰ ਦਸਤੀ ਉਦਾਹਰਨਾਂ ਲਿਖਣੀਆਂ ਪੈਣਗੀਆਂ।

ਉਪਰੋਕਤ ਨਿਰਧਾਰਨ ਵਿੱਚ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ ਆਮ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ. ਇਹ ਕੋਡ ਨਾਲੋਂ ਉੱਚਾ ਪੱਧਰ ਹੈ। ਇਸਨੂੰ ਕਿਸੇ ਵੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਨੂੰ ਲਿਖਣ ਲਈ ਕੋਈ ਵੀ ਸਾਧਨ ਜਾਂ ਢੰਗ ਬੇਕਾਰ ਹਨ। ਕੋਈ ਵੀ ਪ੍ਰੋਗਰਾਮਿੰਗ ਕੋਰਸ ਤੁਹਾਨੂੰ ਇਸ ਵਿਵਰਣ ਨੂੰ ਲਿਖਣ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ। ਅਤੇ ਇੱਥੇ ਕੋਈ ਵੀ ਸਾਧਨ ਨਹੀਂ ਹਨ ਜੋ ਇਸ ਨਿਰਧਾਰਨ ਨੂੰ ਬੇਲੋੜਾ ਬਣਾ ਸਕਦੇ ਹਨ, ਜਦੋਂ ਤੱਕ, ਬੇਸ਼ਕ, ਤੁਸੀਂ TLA+ ਵਿੱਚ ਢਾਂਚਾਗਤ ਪ੍ਰਿੰਟ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਲਿਖਣ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਭਾਸ਼ਾ ਨਹੀਂ ਲਿਖ ਰਹੇ ਹੋ। ਅੰਤ ਵਿੱਚ, ਇਹ ਨਿਰਧਾਰਨ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਅਸੀਂ ਕੋਡ ਨੂੰ ਕਿਵੇਂ ਲਿਖਾਂਗੇ, ਇਹ ਸਿਰਫ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਕੋਡ ਕੀ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਕੋਡ ਬਾਰੇ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਮੱਸਿਆ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕਰਨ ਲਈ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਲਿਖਦੇ ਹਾਂ।

ਪਰ ਇਸ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਵਿੱਚ ਅਜਿਹੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵੀ ਹਨ ਜੋ ਇਸਨੂੰ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਤੋਂ ਵੱਖ ਕਰਦੀਆਂ ਹਨ। 95% ਹੋਰ ਚਸ਼ਮੇ ਕਾਫ਼ੀ ਛੋਟੇ ਅਤੇ ਸਰਲ ਹਨ:

ਅੱਗੇ, ਇਹ ਨਿਰਧਾਰਨ ਨਿਯਮਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਇਹ ਮਾੜੀ ਨਿਰਧਾਰਨ ਦੀ ਨਿਸ਼ਾਨੀ ਹੈ. ਨਿਯਮਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਸਮਝਣਾ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਹੈ, ਜਿਸ ਕਾਰਨ ਮੈਨੂੰ ਉਹਨਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਸਮਾਂ ਬਿਤਾਉਣਾ ਪਿਆ। ਹਾਲਾਂਕਿ, ਇਸ ਮਾਮਲੇ ਵਿੱਚ, ਮੈਂ ਇੱਕ ਵਧੀਆ ਤਰੀਕਾ ਨਹੀਂ ਲੱਭ ਸਕਿਆ.

ਇਹ ਉਹਨਾਂ ਪ੍ਰੋਗਰਾਮਾਂ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ ਕਹਿਣ ਦੇ ਯੋਗ ਹੈ ਜੋ ਨਿਰੰਤਰ ਚੱਲਦੇ ਹਨ. ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਉਹ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਜਾਂ ਵਿਤਰਿਤ ਸਿਸਟਮ. ਬਹੁਤ ਘੱਟ ਲੋਕ ਉਨ੍ਹਾਂ ਨੂੰ ਮਾਨਸਿਕ ਤੌਰ 'ਤੇ ਜਾਂ ਕਾਗਜ਼ 'ਤੇ ਸਮਝ ਸਕਦੇ ਹਨ, ਅਤੇ ਮੈਂ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਹੀਂ ਹਾਂ, ਹਾਲਾਂਕਿ ਮੈਂ ਇੱਕ ਵਾਰ ਅਜਿਹਾ ਕਰਨ ਦੇ ਯੋਗ ਸੀ. ਇਸ ਲਈ, ਸਾਨੂੰ ਅਜਿਹੇ ਸਾਧਨਾਂ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਜੋ ਸਾਡੇ ਕੰਮ ਦੀ ਜਾਂਚ ਕਰਨਗੇ - ਉਦਾਹਰਨ ਲਈ, TLA + ਜਾਂ PlusCal.

ਜੇ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦਾ ਸੀ ਕਿ ਕੋਡ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਇੱਕ ਨਿਰਧਾਰਨ ਲਿਖਣਾ ਕਿਉਂ ਜ਼ਰੂਰੀ ਸੀ? ਵਾਸਤਵ ਵਿੱਚ, ਮੈਂ ਸੋਚਿਆ ਕਿ ਮੈਂ ਇਸਨੂੰ ਜਾਣਦਾ ਹਾਂ. ਇਸਦੇ ਇਲਾਵਾ, ਇੱਕ ਨਿਰਧਾਰਨ ਦੇ ਨਾਲ, ਇੱਕ ਬਾਹਰੀ ਵਿਅਕਤੀ ਨੂੰ ਇਹ ਸਮਝਣ ਲਈ ਕੋਡ ਵਿੱਚ ਆਉਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ। ਮੇਰੇ ਕੋਲ ਇੱਕ ਨਿਯਮ ਹੈ: ਕੋਈ ਆਮ ਨਿਯਮ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ। ਇਸ ਨਿਯਮ ਦਾ ਇੱਕ ਅਪਵਾਦ ਹੈ, ਬੇਸ਼ੱਕ, ਇਹ ਇੱਕੋ ਇੱਕ ਆਮ ਨਿਯਮ ਹੈ ਜਿਸਦੀ ਮੈਂ ਪਾਲਣਾ ਕਰਦਾ ਹਾਂ: ਕੋਡ ਕੀ ਕਰਦਾ ਹੈ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਲੋਕਾਂ ਨੂੰ ਉਹ ਸਭ ਕੁਝ ਦੱਸਦੀ ਹੈ ਜੋ ਉਹਨਾਂ ਨੂੰ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਜਾਣਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਤਾਂ ਫਿਰ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਸੋਚਣ ਬਾਰੇ ਕੀ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ? ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲਿਆਂ ਲਈ, ਹਰ ਕਿਸੇ ਵਾਂਗ ਹੀ: ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਲਿਖਦੇ, ਤਾਂ ਇਹ ਤੁਹਾਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸੋਚ ਰਹੇ ਹੋ. ਨਾਲ ਹੀ, ਤੁਹਾਨੂੰ ਕੋਡ ਤੋਂ ਪਹਿਲਾਂ ਸੋਚਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕੋਡ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਨਿਰਧਾਰਨ ਉਹ ਹੈ ਜੋ ਅਸੀਂ ਕੋਡਿੰਗ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖਦੇ ਹਾਂ। ਕਿਸੇ ਵੀ ਕੋਡ ਲਈ ਇੱਕ ਨਿਰਧਾਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਕਿਸੇ ਦੁਆਰਾ ਵਰਤੀ ਜਾਂ ਸੋਧੀ ਜਾ ਸਕਦੀ ਹੈ। ਅਤੇ ਇਹ "ਕੋਈ" ਇਸ ਦੇ ਲਿਖੇ ਜਾਣ ਤੋਂ ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ ਕੋਡ ਦਾ ਲੇਖਕ ਹੋ ਸਕਦਾ ਹੈ। ਵੱਡੇ ਪ੍ਰੋਗਰਾਮਾਂ ਅਤੇ ਪ੍ਰਣਾਲੀਆਂ ਲਈ, ਕਲਾਸਾਂ ਲਈ, ਵਿਧੀਆਂ ਲਈ, ਅਤੇ ਕਦੇ-ਕਦੇ ਇੱਕ ਵਿਧੀ ਦੇ ਗੁੰਝਲਦਾਰ ਭਾਗਾਂ ਲਈ ਇੱਕ ਨਿਰਧਾਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਕੋਡ ਬਾਰੇ ਬਿਲਕੁਲ ਕੀ ਲਿਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ? ਤੁਹਾਨੂੰ ਇਹ ਵਰਣਨ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਇਹ ਕੀ ਕਰਦਾ ਹੈ, ਯਾਨੀ, ਇਸ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਲਈ ਕੀ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ। ਕਈ ਵਾਰੀ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨਾ ਵੀ ਜ਼ਰੂਰੀ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਕੋਡ ਆਪਣਾ ਉਦੇਸ਼ ਕਿਵੇਂ ਪੂਰਾ ਕਰਦਾ ਹੈ। ਜੇ ਅਸੀਂ ਐਲਗੋਰਿਦਮ ਦੇ ਕੋਰਸ ਵਿੱਚ ਇਸ ਵਿਧੀ ਵਿੱਚੋਂ ਲੰਘੇ, ਤਾਂ ਅਸੀਂ ਇਸਨੂੰ ਐਲਗੋਰਿਦਮ ਕਹਿੰਦੇ ਹਾਂ। ਜੇ ਇਹ ਕੁਝ ਹੋਰ ਖਾਸ ਅਤੇ ਨਵਾਂ ਹੈ, ਤਾਂ ਅਸੀਂ ਇਸਨੂੰ ਉੱਚ-ਪੱਧਰੀ ਡਿਜ਼ਾਈਨ ਕਹਿੰਦੇ ਹਾਂ. ਇੱਥੇ ਕੋਈ ਰਸਮੀ ਅੰਤਰ ਨਹੀਂ ਹੈ: ਦੋਵੇਂ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਦਾ ਇੱਕ ਸੰਖੇਪ ਮਾਡਲ ਹਨ।

ਤੁਹਾਨੂੰ ਇੱਕ ਕੋਡ ਨਿਰਧਾਰਨ ਕਿਵੇਂ ਲਿਖਣਾ ਚਾਹੀਦਾ ਹੈ? ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ: ਇਹ ਕੋਡ ਤੋਂ ਇੱਕ ਪੱਧਰ ਉੱਚਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਹ ਰਾਜਾਂ ਅਤੇ ਵਿਹਾਰਾਂ ਦਾ ਵਰਣਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਓਨਾ ਹੀ ਸਖ਼ਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿੰਨਾ ਕੰਮ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਕਾਰਜ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਲਿਖ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਸੂਡੋਕੋਡ ਜਾਂ ਪਲੱਸਕਲ ਨਾਲ ਲਿਖ ਸਕਦੇ ਹੋ। ਤੁਹਾਨੂੰ ਰਸਮੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਲਿਖਣਾ ਹੈ ਇਹ ਸਿੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਇਹ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੇ ਹੁਨਰ ਪ੍ਰਦਾਨ ਕਰੇਗਾ ਜੋ ਗੈਰ-ਰਸਮੀ ਲੋਕਾਂ ਵਿੱਚ ਵੀ ਤੁਹਾਡੀ ਮਦਦ ਕਰੇਗਾ। ਤੁਸੀਂ ਰਸਮੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਿਖਣਾ ਕਿਵੇਂ ਸਿੱਖਦੇ ਹੋ? ਜਦੋਂ ਅਸੀਂ ਪ੍ਰੋਗਰਾਮ ਕਰਨਾ ਸਿੱਖਿਆ, ਅਸੀਂ ਪ੍ਰੋਗਰਾਮ ਲਿਖੇ ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਡੀਬੱਗ ਕੀਤਾ। ਇੱਥੇ ਵੀ ਇਹੀ ਹੈ: ਸਪੈੱਕ ਲਿਖੋ, ਮਾਡਲ ਚੈਕਰ ਨਾਲ ਇਸ ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਬੱਗ ਠੀਕ ਕਰੋ। TLA+ ਇੱਕ ਰਸਮੀ ਨਿਰਧਾਰਨ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਭਾਸ਼ਾ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਅਤੇ ਤੁਹਾਡੀਆਂ ਖਾਸ ਲੋੜਾਂ ਲਈ ਕੋਈ ਹੋਰ ਭਾਸ਼ਾ ਬਿਹਤਰ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ। TLA+ ਦਾ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਇਹ ਗਣਿਤ ਦੀ ਸੋਚ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਿਖਾਉਂਦਾ ਹੈ।

ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਅਤੇ ਕੋਡ ਨੂੰ ਕਿਵੇਂ ਲਿੰਕ ਕਰਨਾ ਹੈ? ਟਿੱਪਣੀਆਂ ਦੀ ਮਦਦ ਨਾਲ ਜੋ ਗਣਿਤ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਲਾਗੂਕਰਨ ਨੂੰ ਜੋੜਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਗ੍ਰਾਫਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹੋ, ਤਾਂ ਪ੍ਰੋਗਰਾਮ ਪੱਧਰ 'ਤੇ ਤੁਹਾਡੇ ਕੋਲ ਨੋਡਾਂ ਦੀਆਂ ਐਰੇ ਅਤੇ ਲਿੰਕਾਂ ਦੀਆਂ ਐਰੇ ਹੋਣਗੇ. ਇਸ ਲਈ, ਤੁਹਾਨੂੰ ਇਹ ਲਿਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਇਹਨਾਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਢਾਂਚੇ ਦੁਆਰਾ ਗ੍ਰਾਫ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ.

ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਪਰੋਕਤ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕੋਡ ਲਿਖਣ ਦੀ ਅਸਲ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ। ਜਦੋਂ ਤੁਸੀਂ ਕੋਡ ਲਿਖਦੇ ਹੋ, ਯਾਨੀ ਤੁਸੀਂ ਤੀਜਾ ਪੜਾਅ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਪ੍ਰੋਗਰਾਮ ਦੁਆਰਾ ਸੋਚਣ ਅਤੇ ਸੋਚਣ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਕੋਈ ਉਪ-ਕਾਰਜ ਗੁੰਝਲਦਾਰ ਜਾਂ ਗੈਰ-ਸਪੱਸ਼ਟ ਸਾਬਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸਦੇ ਲਈ ਇੱਕ ਨਿਰਧਾਰਨ ਲਿਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਪਰ ਮੈਂ ਇੱਥੇ ਖੁਦ ਕੋਡ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹਾਂ. ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ, ਕਿਸੇ ਵੀ ਕਾਰਜਪ੍ਰਣਾਲੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਇਹ ਉਹਨਾਂ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਨਾਲ ਹੀ, ਉਪਰੋਕਤ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕੋਡ ਦੀ ਜਾਂਚ ਅਤੇ ਡੀਬੱਗ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਭਾਵੇਂ ਐਬਸਟਰੈਕਟ ਮਾਡਲ ਸਹੀ ਢੰਗ ਨਾਲ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਇਸਦੇ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਬੱਗ ਹੋ ਸਕਦੇ ਹਨ।

ਵਿਵਰਣ ਲਿਖਣਾ ਕੋਡਿੰਗ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਇੱਕ ਵਾਧੂ ਕਦਮ ਹੈ। ਇਸਦਾ ਧੰਨਵਾਦ, ਬਹੁਤ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਘੱਟ ਮਿਹਨਤ ਨਾਲ ਫੜਿਆ ਜਾ ਸਕਦਾ ਹੈ - ਅਸੀਂ ਐਮਾਜ਼ਾਨ ਦੇ ਪ੍ਰੋਗਰਾਮਰਾਂ ਦੇ ਤਜ਼ਰਬੇ ਤੋਂ ਇਹ ਜਾਣਦੇ ਹਾਂ. ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ, ਪ੍ਰੋਗਰਾਮਾਂ ਦੀ ਗੁਣਵੱਤਾ ਉੱਚੀ ਹੋ ਜਾਂਦੀ ਹੈ. ਤਾਂ ਫਿਰ, ਅਸੀਂ ਅਕਸਰ ਉਨ੍ਹਾਂ ਤੋਂ ਬਿਨਾਂ ਕਿਉਂ ਜਾਂਦੇ ਹਾਂ? ਕਿਉਂਕਿ ਲਿਖਣਾ ਔਖਾ ਹੈ। ਅਤੇ ਲਿਖਣਾ ਔਖਾ ਹੈ, ਕਿਉਂਕਿ ਇਸਦੇ ਲਈ ਤੁਹਾਨੂੰ ਸੋਚਣ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਸੋਚਣਾ ਵੀ ਔਖਾ ਹੈ। ਤੁਸੀਂ ਜੋ ਸੋਚਦੇ ਹੋ ਉਸ ਦਾ ਦਿਖਾਵਾ ਕਰਨਾ ਹਮੇਸ਼ਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਇੱਥੇ ਤੁਸੀਂ ਦੌੜਨ ਦੇ ਨਾਲ ਇੱਕ ਸਮਾਨਤਾ ਬਣਾ ਸਕਦੇ ਹੋ - ਜਿੰਨਾ ਘੱਟ ਤੁਸੀਂ ਦੌੜਦੇ ਹੋ, ਓਨੀ ਹੌਲੀ ਤੁਸੀਂ ਦੌੜਦੇ ਹੋ। ਤੁਹਾਨੂੰ ਆਪਣੀਆਂ ਮਾਸਪੇਸ਼ੀਆਂ ਨੂੰ ਸਿਖਲਾਈ ਦੇਣ ਅਤੇ ਲਿਖਣ ਦਾ ਅਭਿਆਸ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਭਿਆਸ ਦੀ ਲੋੜ ਹੈ।

ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਤੇ ਗਲਤੀ ਕੀਤੀ ਹੋਵੇ, ਜਾਂ ਲੋੜਾਂ ਬਦਲ ਗਈਆਂ ਹੋਣ, ਜਾਂ ਸੁਧਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਕੋਈ ਵੀ ਕੋਡ ਜੋ ਕੋਈ ਵੀ ਵਰਤਦਾ ਹੈ, ਨੂੰ ਬਦਲਣਾ ਪੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਨਿਰਧਾਰਨ ਪ੍ਰੋਗਰਾਮ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਇਸ ਕੇਸ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਇੱਕ ਨਵਾਂ ਨਿਰਧਾਰਨ ਲਿਖਣ ਅਤੇ ਕੋਡ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ। ਅਸੀਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਅਜਿਹਾ ਕੋਈ ਨਹੀਂ ਕਰਦਾ। ਅਭਿਆਸ ਵਿੱਚ, ਅਸੀਂ ਕੋਡ ਨੂੰ ਪੈਚ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸੰਭਵ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਨ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹਾਂ। ਜੇ ਇਹ ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਵਾਪਰਨਾ ਹੈ, ਤਾਂ ਫਿਰ ਵਿਸ਼ੇਸ਼ਤਾ ਕਿਉਂ ਲਿਖੋ? ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਉਸ ਵਿਅਕਤੀ ਲਈ ਜੋ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰੇਗਾ, ਨਿਰਧਾਰਨ ਵਿੱਚ ਹਰੇਕ ਵਾਧੂ ਸ਼ਬਦ ਦਾ ਸੋਨੇ ਵਿੱਚ ਭਾਰ ਹੋਵੇਗਾ, ਅਤੇ ਇਹ ਵਿਅਕਤੀ ਤੁਸੀਂ ਖੁਦ ਹੋ ਸਕਦੇ ਹੋ। ਜਦੋਂ ਮੈਂ ਆਪਣੇ ਕੋਡ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹਾਂ ਤਾਂ ਮੈਂ ਕਾਫ਼ੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਪ੍ਰਾਪਤ ਨਾ ਕਰਨ ਲਈ ਅਕਸਰ ਆਪਣੇ ਆਪ ਨੂੰ ਪਰੇਸ਼ਾਨ ਕਰਦਾ ਹਾਂ। ਅਤੇ ਮੈਂ ਕੋਡ ਨਾਲੋਂ ਵਧੇਰੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਿਖਦਾ ਹਾਂ. ਇਸ ਲਈ, ਜਦੋਂ ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਨਿਰਧਾਰਨ ਨੂੰ ਹਮੇਸ਼ਾ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਦੂਜਾ, ਹਰੇਕ ਸੰਸ਼ੋਧਨ ਦੇ ਨਾਲ, ਕੋਡ ਵਿਗੜਦਾ ਜਾਂਦਾ ਹੈ, ਇਸਨੂੰ ਪੜ੍ਹਨਾ ਅਤੇ ਸੰਭਾਲਣਾ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ. ਇਹ ਐਨਟ੍ਰੋਪੀ ਵਿੱਚ ਵਾਧਾ ਹੈ। ਪਰ ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਦੁਆਰਾ ਲਿਖਣ ਵਾਲੀ ਹਰ ਲਾਈਨ ਇੱਕ ਸੰਪਾਦਨ ਹੋਵੇਗੀ, ਅਤੇ ਕੋਡ ਸ਼ੁਰੂ ਤੋਂ ਪੜ੍ਹਨਾ ਔਖਾ ਅਤੇ ਔਖਾ ਹੋਵੇਗਾ।

ਜਿਵੇਂ ਕਿਹਾ ਆਈਜ਼ਨਹਾਵਰ, ਯੋਜਨਾ ਦੁਆਰਾ ਕੋਈ ਲੜਾਈ ਨਹੀਂ ਜਿੱਤੀ ਗਈ ਸੀ, ਅਤੇ ਬਿਨਾਂ ਯੋਜਨਾ ਦੇ ਕੋਈ ਲੜਾਈ ਨਹੀਂ ਜਿੱਤੀ ਗਈ ਸੀ. ਅਤੇ ਉਹ ਲੜਾਈਆਂ ਬਾਰੇ ਇੱਕ ਜਾਂ ਦੋ ਗੱਲਾਂ ਜਾਣਦਾ ਸੀ। ਇੱਕ ਰਾਏ ਹੈ ਕਿ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਿਖਣਾ ਸਮੇਂ ਦੀ ਬਰਬਾਦੀ ਹੈ. ਕਈ ਵਾਰ ਇਹ ਸੱਚ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕੰਮ ਇੰਨਾ ਸੌਖਾ ਹੁੰਦਾ ਹੈ ਕਿ ਇਸ ਦੁਆਰਾ ਸੋਚਣ ਲਈ ਕੁਝ ਵੀ ਨਹੀਂ ਹੁੰਦਾ. ਪਰ ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾ ਯਾਦ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਜਦੋਂ ਤੁਹਾਨੂੰ ਵਿਵਰਣ ਨਾ ਲਿਖਣ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਨਾ ਸੋਚਣ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਤੁਹਾਨੂੰ ਹਰ ਵਾਰ ਇਸ ਬਾਰੇ ਸੋਚਣਾ ਚਾਹੀਦਾ ਹੈ. ਕੰਮ ਬਾਰੇ ਸੋਚਣਾ ਇਹ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਗਲਤੀਆਂ ਨਹੀਂ ਕਰੋਗੇ. ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ, ਕਿਸੇ ਨੇ ਵੀ ਜਾਦੂ ਦੀ ਛੜੀ ਦੀ ਖੋਜ ਨਹੀਂ ਕੀਤੀ, ਅਤੇ ਪ੍ਰੋਗਰਾਮਿੰਗ ਇੱਕ ਮੁਸ਼ਕਲ ਕੰਮ ਹੈ. ਪਰ ਜੇ ਤੁਸੀਂ ਸਮੱਸਿਆ ਬਾਰੇ ਨਹੀਂ ਸੋਚਦੇ, ਤਾਂ ਤੁਸੀਂ ਗਲਤੀਆਂ ਕਰਨ ਦੀ ਗਾਰੰਟੀ ਦਿੰਦੇ ਹੋ।

ਤੁਸੀਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਵੈਬਸਾਈਟ 'ਤੇ TLA + ਅਤੇ PlusCal ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਤੁਸੀਂ ਮੇਰੇ ਹੋਮ ਪੇਜ ਤੋਂ ਉੱਥੇ ਜਾ ਸਕਦੇ ਹੋ ਲਿੰਕ. ਇਹ ਸਭ ਮੇਰੇ ਲਈ ਹੈ, ਤੁਹਾਡੇ ਧਿਆਨ ਲਈ ਧੰਨਵਾਦ.

ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਇਹ ਇੱਕ ਅਨੁਵਾਦ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਟਿੱਪਣੀਆਂ ਲਿਖਦੇ ਹੋ, ਯਾਦ ਰੱਖੋ ਕਿ ਲੇਖਕ ਉਨ੍ਹਾਂ ਨੂੰ ਨਹੀਂ ਪੜ੍ਹੇਗਾ। ਜੇਕਰ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਲੇਖਕ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਉਹ ਹਾਈਡਰਾ 2019 ਕਾਨਫਰੰਸ ਵਿੱਚ ਹੋਵੇਗਾ, ਜੋ ਸੇਂਟ ਪੀਟਰਸਬਰਗ ਵਿੱਚ ਜੁਲਾਈ 11-12, 2019 ਨੂੰ ਆਯੋਜਿਤ ਕੀਤਾ ਜਾਵੇਗਾ। ਟਿਕਟਾਂ ਖਰੀਦੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ ਸਰਕਾਰੀ ਵੈਬਸਾਈਟ 'ਤੇ.

ਸਰੋਤ: www.habr.com