ਜਾਣੋ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ Niklaus Wirth ਦੀਆਂ Pascal ਅਤੇ Modula ਭਾਸ਼ਾਵਾਂ ਦੀ ਸਾਦਗੀ ਅਤੇ ਸਿੱਖਣ-ਪਹਿਲਾਂ ਡਿਜ਼ਾਈਨ ਨੇ ਪਠਨਯੋਗਤਾ, ਮੋਡੀਊਲਰਤਾ ਅਤੇ ਆਧੁਨਿਕ ਸੌਫਟਵੇਅਰ ਅਮਲਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ।
Niklaus Wirth ਇੱਕ ਸਵਿੱਟਜ਼ਰਲੈਂਡ ਦੇ ਕੰਪਿਊਟਰ ਵਿਗਿਆਨੀ ਸੀ ਜੋ ਚਮਕਦਾਰ ਫੀਚਰਾਂ ਨਾਲ ਘੱਟ, ਅਤੇ ਇਸ ਗੱਲ ਨਾਲ ਵੱਧ ਫਿਕਰ ਰੱਖਦਾ ਸੀ ਕਿ ਪ੍ਰੋਗ੍ਰਾਮਰ ਕੋਡ ਵਿੱਚ ਸਪਸ਼ਟ ਸੋਚ ਸਕਣ. ਉਸ ਨੇ Pascal ਅਤੇ ਬਾਅਦ ਵਿੱਚ Modula-2 ਵਰਗੀ ਭਾਸ਼ਾਵਾਂ ਇਹੋ ਜਿਹਾ ਉਦੇਸ਼ ਰੱਖ ਕੇ ਡਿਜ਼ਾਇਨ ਕੀਤੀਆਂ: ਪ੍ਰੋਗਰਾਮ ਲਿਖਣ ਦਾ “ਠੀਕ” ਤਰੀਕਾ ਸਿੱਖਣਾ ਆਸਾਨ, ਪੜ੍ਹਨ ਯੋਗ ਬਣਾਉਣਾ, ਅਤੇ ਗੁਪਤ ਤਰੀਕੇ ਨਾਲ ਗਲਤ ਕਰਨ ਨੂੰ ਔਖਾ ਕਰਨਾ।
ਇਹ ਕੇਂਦਰ ਅਜੇ ਵੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਸੌਫਟਵੇਅਰ ਅਮਲਿਆਂ ਦੀਆਂ ਨੁਕਸਾਨਾਂ ਸ਼ਕਤੀ ਦੀ ਘਾਟ ਕਾਰਨ ਨਹੀਂ—ਉਹ ਗੁੰਝਲਦਾਰਤਾ, ਅਸਪਸ਼ਟ ਇਰਾਦਾ, ਅਤੇ ਐਸੇ ਕੋਡ ਕਾਰਨ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਸੋਚਣ ਲਈ ਔਖੇ ਹੁੰਦੇ ਹਨ। Wirth ਦੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਢਾਂਚਾ, ਸਪਸ਼ਟਤਾ, ਅਤੇ ਅਨੁਸ਼ਾਸਿਤ ਵਿਭਾਜਨ ਵੱਲ ਧੱਕਣ ਲਈ ਬਣੀਆਂ ਸਨ। ਇਹ ਆਦਤੇ ਅੱਜ ਹਰ ਥਾਂ ਦਿੱਸਦੀਆਂ ਹਨ: ਕੋਡ ਰਿਵਿਊਜ਼ ਵਿੱਚ, ਮੋਡੀਊਲਾਂ ਵਜੋਂ ਸਿਸਟਮਾਂ ਡਿਜ਼ਾਇਨ ਕਰਨ ਵਿੱਚ, ਅਤੇ ਸਾਡੀ ਤੇਜ਼ੀ ਨਾਲ ਨਾਲ ਸਹੀਤ ਅਤੇ ਰੱਖ-ਰਖਾ ਦੀ ਕਦਰ ਕਰਨ ਵਿੱਚ।
Pascal ਅਤੇ Modula ਸਭ ਕੁਝ ਸਭਨਾਂ ਲਈ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੀਆਂ ਸਨ। ਇਨ੍ਹਾਂ ਨੂੰ ਇਰਾਦਾਤਮਕ ਤੌਰ ਤੇ ਸੀਮਿਤ ਰੱਖਿਆ ਗਿਆ ਸੀ ਤਾਂ ਜੋ ਸਿੱਖਣ ਵਾਲਿਆਂ ਨੂੰ ਇਹ ਅਭਿਆਸ ਹੋਵੇ:\n\n- ਸਪਸ਼ਟ ਕੰਟਰੋਲ ਫਲੋ (ਸੰਰਚਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ) ਲਿਖਣਾ\n- ਗਲਤੀਆਂ ਪਹਿਲਾਂ ਫੜਨ ਲਈ ਮਜ਼ਬੂਤ ਟਾਈਪਿੰਗ ਦੀ ਵਰਤੋਂ\n- ਕੋਡ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਠਹਿਰਾਉਣਾ ਕਿ ਬਾਅਦ ਵਿੱਚ ਕੋਈ ਹੋਰ ਵੀ ਸਮਝ ਸਕੇ
ਕਿਉਂਕਿ ਇਹ ਭਾਸ਼ਾਵਾਂ ਸਰਗਰਮ ਤੌਰ 'ਤੇ ਸਿੱਖਿਆ ਵਿੱਚ ਵਰਤੀਆਂ ਗਈਆਂ, ਇਹ ਪੀੜ੍ਹੀਆਂ ਦੇ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ। ਨਤੀਜਾ ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਲੋਕ ਸਿਰਫ਼ “Pascal ਆਉਂਦਾ ਸੀ,” ਪਰ ਇਹ ਸੀ ਕਿ ਲੋਕ ਉਮੀਦ ਕਰਨ ਲੱਗੇ ਕਿ ਕੰਪਾਇਲਰ ਸਹਾਇਤਾ ਕਰੇ, ਟਾਈਪਾਂ ਦਾ ਅਰਥ ਹੋਵੇ, ਅਤੇ ਪ੍ਰੋਗਰਾਮ ਜ਼ਾਰੇ ਨੀਤੀ ਨਾਲ ਪੜ੍ਹਨਯੋਗ ਹੋਣ — ਪਰੰਪਰਾ ਨਾਲ ਨਹੀਂ।
Pascal ਤੋਂ ਪਹਿਲਾਂ, ਬਹੁਤ ਸਾਰੇ ਵਿਦਿਆਰਥੀਆਂ ਨੇ ਉਹਨਾਂ ਭਾਸ਼ਾਵਾਂ ਰਾਹੀਂ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਸਿੱਖੀ ਜੋ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਪੜ੍ਹਨ ਵਿੱਚ ਅਤੇ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਵਿੱਚ ਮੁਸ਼ਕਿਲ ਬਣਾਉਂਦੀਆਂ ਸਨ। ਕੋਡ ਅਕਸਰ ਗਲੋਬਲ ਸਟੇਟ, ਅਸਪਸ਼ਟ ਰਿਵਾਜ਼, ਅਤੇ ਅਣਅਨੁਮਾਨਿਤ ਕੰਟਰੋਲ ਫਲੋ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਸੀ। ਸ਼ੁਰੂਆਤੀ ਲੋਕ “ਚਲਾਉਣਾ ਸਿੱਖ ਲੈnde” ਸਨ ਬਿਨਾਂ ਇਹ ਸਮਝੇ ਕਿ ਇਹ ਕਿਵੇਂ ਜਾਂ ਕਿਉਂ ਟੁੱਟਦਾ ਹੈ।
ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਗੁੰਝਲਦਾਰ ਲਾਜਿਕ ਲਿਖਣਾ ਕਿੰਨਾ ਆਸਾਨ ਸੀ। ਜਦੋਂ ਕਿਸੇ ਪ੍ਰੋਗ੍ਰਾਮ ਦਾ ਐਗਜ਼ਿਕਿਊਸ਼ਨ ਅਣਉਮੀਦ ਤਰੀਕੇ ਨਾਲ ਕੂਦਦਾ ਫਿਰਦਾ ਹੈ, ਤਾਂ ਪ੍ਰੋਗ੍ਰਾਮਰ ਕਦਮ-ਦਰ-ਕਦਮ ਸੋਚਨਾ ਛੱਡ ਕੇ ਸਮੱਸਿਆਵਾਂ ਦੀ ਪੈਚਿੰਗ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਸਿੱਖਣ ਵਾਲਿਆਂ ਨੂੰ ਨਹੀ ਨਿਰਾਸ ਕਰਦਾ; ਇਹ ਟੀਮਾਂ ਲਈ ਮੈਂਟੇਨੈਂਸ ਮਹਿੰਗਾ ਕਰ ਦਿੰਦਾ ਹੈ।
Pascal ਸੰਰਚਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਸਹਾਰੇ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ: ਸਪਸ਼ਟ, ਨੇਸਟੇਬਲ ਬਲਾਕਾਂ (sequence, selection, repetition) 'ਤੇ ਨਿਰਭਰ, ਨਾ ਕਿ ਅਦ-ਹੌਕ ਛੱਲਾਂ 'ਤੇ। ਲਕਸ਼ ਇਸ ਦਾ ਸੀ ਕਿ ਕੋਡ ਮਨੁੱਖਾਂ ਵੱਲੋਂ ਸਮਾਧਾਨ ਵਿਆਖਿਆ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨੂੰ ਦਰਸਾਏ।
Wirth ਨੇ ਪਠਨਯੋਗਤਾ ਨੂੰ ਡਿਜ਼ਾਈਨ ਲਕਸ਼ ਬਣਾਇਆ, ਬਾਅਦ ਦੀ ਚੀਜ਼ ਨਹੀਂ। Pascal ਉਨ੍ਹਾਂ ਬਿੰਦੂਆਂ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਸੀ:\n\n- ਸਪਸ਼ਟ ਢਾਂਚਾ (begin/end ਬਲਾਕ)\n- ਮਾਣਵ-ਯੋਗ ਡੇਟਾ ਪਰਿਭਾਸ਼ਾਵਾਂ (ਟਾਈਪ ਅਤੇ ਰਿਕਾਰਡ)\n- ਅਨੁਮਾਨਕ ਕੰਟਰੋਲ ਫਲੋ (if, while, for ਵਰਗੇ ਸਪਸ਼ਟ ਲੂਪ ਅਤੇ ਸ਼ਰਤਾਂ)
ਇਸਦਾ ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਵਿਦਿਆਰਥੀ ਪੜ੍ਹ ਕੇ ਸਿੱਖ ਸਕਦੇ ਸਨ, ਸਿਰਫ਼ ਟ੍ਰਾਇਲ-ਏਂਡ-ਏਰਰ ਤੋਂ ਨਹੀਂ। ਇਸ ਨਾਲ ਅਧਿਆਪਕ ਸਮਝ ਨੂੰ ਗ੍ਰੇਡ ਕਰ ਸਕਦੇ ਸਨ, ਨਾ ਕਿ ਕੇਵਲ ਆਉਟਪੁੱਟ।
ਯੂਨੀਵਰਸਿਟੀਆਂ ਅਤੇ ਟੈਕਸਟਬੁੱਕਾਂ ਨੇ ਇਹ ਵਿਚਾਰ ਫੈਲਾਏ। Pascal ਇੱਕ ਕੋਰਸ ਵਿੱਚ ਸਿਖਾਉਣ ਲਈ ਛੋਟਾ ਕਾਫੀ ਸੀ, ਸਪੱਸ਼ਟ ਪਾਠਕ੍ਰਮ ਵਿੱਚ ਫਿੱਟ ਹੋ ਜਾਂਦਾ ਸੀ, ਅਤੇ ਅਨੁਸ਼ਾਸਿਤ ਅਭਿਆਸਾਂ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਸੀ। ਜਿਵੇਂ ਹੀ ਕਲਾਸਰੂਮਾਂ ਵਿਚ ਅਪਣਾਇਆ ਗਿਆ, ਇਹ ਇਕ ਪੀੜ੍ਹੀ ਦੀ ਉਮੀਦਾਂ ਨੂੰ ਰੂਪ ਦਿੱਤਾ: ਪ੍ਰੋਗਰਾਮ ਕਿਸੇ ਹੋਰ ਵਿਅਕਤੀ ਦੁਆਰਾ ਸਮਝਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ — ਅਤੇ ਭਾਸ਼ਾ ਡਿਜ਼ਾਇਨ ਇਸ ਨਤੀਜੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਹੈ।
Pascal ਛੋਟਾ “ਯਾਦਿ” ਇਸ ਲਈ ਨਹੀਂ ਸੀ ਕਿ ਐਸਾ ਮੌਕਿਆਂ ਨਾਲ ਹੋ ਗਿਆ। Wirth ਨੇ ਇਸਨੂੰ ਚੰਗੀਆਂ ਆਦਤਾਂ ਨੂੰ ਆਸਾਨ ਅਤੇ ਮੰਦ ਆਦਤਾਂ ਨੂੰ ਔਖਾ ਬਣਾਉਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ। ਬਹੁਤ ਸਾਰੇ ਤਰੀਕੇ ਦਿਖਾਉਣ ਦੀ ਥਾਂ, Pascal ਤੁਹਾਨੂੰ ਇੱਕ ਸਪਸ਼ਟ, ਪੜ੍ਹਨਯੋਗ ਰਸਤੇ ਵੱਲ ਧੱਕਦਾ — ਜਿਸਦਾ ਲਾਭ ਸ਼ੁਰੂਆਤੀ ਵਿਦਿਆਰਥੀਆਂ ਲਈ ਵੀ ਤੇ ਟੀਮਾਂ ਲਈ ਵੀ ਹੈ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਕੋਡ ਸਮਝਦਾਰ ਰੱਖਣਾ ਚਾਹੁੰਦੀਆਂ ਹਨ।
Pascal ਦੀ ਸਿੰਟੈਕਸ ਕੰਪੈਕਟ ਅਤੇ ਪੇਸ਼ਗੋਈ ਵਾਲੀ ਰਹਿੰਦੀ ਹੈ। ਭਾਸ਼ਾ ਇੱਕ ਸੀਮਿਤ ਸੈੱਟ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ — ਬਲਾਕ, procedures/functions ਅਤੇ ਕੁਝ ਮੁੱਖ ਬਿਆਨ — 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਕਿ ਤੁਸੀਂ ਵਿਸ਼ੇਸ਼ ਮਾਮਲਿਆਂ ਨੂੰ ਯਾਦ ਕਰਨ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਗੁਜ਼ਾਰੋ ਅਤੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਢਾਂਚਾ ਸਿੱਖਣ 'ਤੇ ਜ਼ਿਆਦਾ ਵਕਤ ਲਗਾਓ।
ਇਹ ਇਕਸਾਰਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜਦੋਂ ਇੱਕ ਭਾਸ਼ਾ ਕੋਡ ਘੋਸ਼ਿਤ ਕਰਨ, ਢਾਂਚਾ ਕਰਨ ਅਤੇ ਸਕੋਪ ਦੇਣ ਦਾ ਇੱਕ ਸਪਸ਼ਟ ਤਰੀਕਾ ਦਿੰਦੀ ਹੈ, ਪਠਕ ਅਕਸਰ ਅਣਪਰਿਚਿਤ ਕੋਡ ਦਾ ਅਰਥ ਨਿਕਾਲ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਓਹਲੇ ਨਿਯਮਾਂ ਦੀ ਖੋਜ ਕੀਤੇ।
Pascal ਸਪਸ਼ਟ ਢਾਂਚਾ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ: ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਦਾ ਸਪਸ਼ਟ ਸ਼ੁਰੂ ਅਤੇ ਅੰਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਦਰਮਿਆਨੀ ਹਿੱਸੇ ਨਾਮਿਤ ਹੁੰਦੇ ਹਨ। ਮਜ਼ਬੂਤ ਡਿਫੌਲਟ (ਜਿਵੇਂ ਸਪਸ਼ਟ ਵੈਰੀਏਬਲ ਘੋਸ਼ਣ) ਤੁਹਾਨੂੰ ਇਹ ਸੋਚਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ ਕਿ ਕਿਸ ਚੀਜ਼ ਦੀ ਉਪਸਥਿਤੀ ਹੈ ਅਤੇ ਉਸਦੀ ਕਿਸਮ ਕੀ ਹੈ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਉਸ ਨੂੰ ਵਰਤੋਂ ਕਰੋ।
ਇਸ ਨਾਲ ਉਹ “ਅਚਾਨਕ ਕਾਰਵਾਈ” ਘੱਟ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਮੁੱਲ ਸੁਚੱਜੇ ਤਰੀਕੇ ਨਾਲ ਉਪਸਥਿਤ ਹੋ ਜਾਂਦੇ ਹਨ ਜਾਂ ਚੁਪਕੇ ਤੌਰ ਤੇ ਕਿਸਮ ਬਦਲ ਜਾਂਦੀ ਹੈ—ਐਸੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਗਤੀ ਨੂੰ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਬਾਅਦ ਵਿੱਚ ਭੁਲੇਖੇ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ।
Pascal ਸਪਸ਼ਟ ਕੰਟਰੋਲ ਸੜਕਾਂ ਨੂੰ ਮਹੱਤਵ ਦਿੰਦਾ—if, while, ਅਤੇ for—ਅਤੇ ਉਮੀਦ ਰੱਖਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਲਾਜਿਕ ਨੂੰ ਸਿੱਧਾ ਪ੍ਰਗਟ ਕਰੋ। ਤੁਸੀਂ ਇੱਕ ਰੂਟੀਨ ਨੂੰ ਉੱਪਰ-ਤੋਂ-ਥੱਲੇ ਪੜ੍ਹ ਕੇ ਸਮਝ ਸਕਦੇ ਹੋ ਕਿ ਕਿਹੜੇ ਰਸਤੇ ਗੁਜ਼ਰਨਗੇ, ਜੋ ਸੰਰਚਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਸਹਾਰਦਾ ਅਤੇ ਡਿਬੱਗਿੰਗ ਨੂੰ ਪ੍ਰਣਾਲੀਬੱਧ ਬਣਾਉਂਦਾ ਹੈ।
Pascal ਵਿੱਚ ਟਾਈਪ ਸਜਾਵਟ ਨਹੀਂ ਹਨ; ਉਹ ਗਲਤੀਆਂ ਰੋਕਣ ਲਈ ਇੱਕ ਸਾਧਨ ਹਨ। ਡੇਟਾ ਦੀ ਸ਼ਕਲ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਕੇ, ਭਾਸ਼ਾ ਮਿਸਮੇਚ ਨੂੰ ਪਹਿਲਾਂ ਫੜਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਅਤੇ ਸਖਤ ਅੰਦਾਜ਼-ਵਿਰੇਵਾਲੀ ਅੰਦੋਲਨ ਨੂੰ ਇਨਾਮ ਦਿੰਦੀ: ਆਪਣੇ ਡੇਟਾ ਨੂੰ ਧਿਆਨ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਅਤੇ ਫਿਰ ਕੰਪਾਇਲਰ ਨੂੰ ਉਸ ਠੇਕੇ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਿਓ।
Pascal ਇਸ ਲਈ "ਸਿੱਖਿਆ-ਮੁਖ" ਨਹੀਂ ਹੈ ਕਿ ਉਹ ਹਕੀਕਤ ਨੂੰ ਛੁਪਾਉਂਦਾ ਹੈ। ਇਹ ਇਸ ਲਈ ਸਿੱਖਿਆ-ਮੁਖ ਹੈ ਕਿਉਂਕਿ ਭਾਸ਼ਾ ਤੁਹਾਨੂੰ ਉਹ ਆਦਤਾਂ ਵੱਲ ਧੱਕਦੀ ਹੈ ਜੋ ਪਹਿਲੀ ਕਲਾਸ ਦੇ ਕੋਰਸ ਤੋਂ ਬਾਅਦ भी ਲਾਭਦਾਇਕ ਰਹਿੰਦੀਆਂ ਹਨ: ਸਪਸ਼ਟ ਢਾਂਚਾ, ਜ਼ਿੰਮੇਵਾਰ ਨਾਮ-ਕਰਨ, ਅਤੇ ਐਸਾ ਕੋਡ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਮੁਖਖਰਕੇ ਵੀ ਵਿਆਖਿਆ ਕਰ ਸਕੋ।
Pascal ਵਿੱਚ ਬਲਾਕ (begin ... end) ਅਤੇ ਨੇਸਟਿਡ ਸਕੋਪ ਪ੍ਰੋਗ੍ਰਾਮ ਢਾਂਚਾ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ। ਵਿਦਿਆਰਥੀ ਜਲਦੀ ਇਹ ਸਿੱਖ ਲੈਂਦੇ ਹਨ ਕਿ ਕਿੱਥੇ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਘੋਸ਼ਣਾ ਕੀਤੀ ਗਈ ਹੈ, ਉਹ ਮਹੱਤਵ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਕਿ ਵੈਰੀਏਬਲਾਂ ਨੂੰ ਗਲੋਬਲ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ—ਝੱਟ-ਫਟ। ਇਹ ਸਹੀ ਮਾਨਸਿਕ ਮਾਡਲ ਬਣਾਉਂਦਾ: ਇੱਕ ਪ੍ਰੋਸੀਜਰ ਆਪਣਾ ਲੋਕਲ ਡੇਟਾ ਮਾਲਕ ਹੈ, ਅਤੇ ਬਾਕੀ ਪ੍ਰੋਗਰਾਮ ਉਸ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਨਿਰਭਰ ਨਹੀਂ ਕਰ ਸਕਦਾ।
Pascal ਕੰਮ ਨੂੰ ਪ੍ਰੋਸੀਜਰਾਂ ਅਤੇ ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਵੰਡਣ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਸਪਸ਼ਟ ਪੈਰਾਮੀਟਰਾਂ ਨਾਲ ਇਸ ਨੂੰ ਅਮਲ ਵਿੱਚ ਲਿਆਉਂਦਾ ਹੈ। ਇਹ ਕੁਦਰਤੀ ਤੌਰ ਤੇ ਇਹ ਸਿਖਾਉਂਦਾ ਹੈ:\n\n- “ਇਹ ਕਦਮ ਕੀ ਕਰਦਾ ਹੈ” ਨੂੰ “ਸੰਪੂਰਨ ਪ੍ਰੋਗਰਾਮ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ” ਤੋਂ ਵੱਖਰਾ ਕੀਤਾ ਜਾਵੇ\n- ਛੋਟੇ, ਟੈਸਟਯੋਗ ਤਰਕ ਯੂਨਿਟ\n- ਇਨਪੁੱਟ, ਪ੍ਰੋਸੈਸਿੰਗ, ਅਤੇ ਆਉਟਪੁੱਟ ਵਿਚ ਸਾਫ਼ ਹੱਦਬੰਧੀ
ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਡਿਫਾਲਟ ਦ੍ਰਿਸ਼ਟੀ ਬਣ ਜਾਂਦੀ ਹੈ: ਜੇ ਕੁਝ ਵਿਆਖਿਆ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਿਲ ਹੋਵੇ, ਤਾਂ ਉਸਨੂੰ ਕੱਢ ਦਿਓ।
Pascal ਦੀ ਟਾਈਪ ਚੈਕਿੰਗ ਅਸਪਸ਼ਟਤਾ ਘਟਾਉਂਦੀ ਹੈ। ਅਸੰਗਤ ਮੁੱਲਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਔਖਾ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਆਸਾਨ। ਵਿਦਿਆਰਥੀਆਂ ਲਈ ਤੁਰੰਤ ਫਾਇਦਾ ਇਹ ਹੈ: ਘੱਟ ਓਢੇ ਬੱਗਸ ਜੋ ਅਣਚਾਹੀ ਤਬਦੀਲੀਆਂ ਜਾਂ ਢੀਲੇ ਅਨੁਮਾਨਾਂ ਕਾਰਨ ਹੁੰਦੇ ਹਨ।
Pascal ਦੀਆਂ ਪੜ੍ਹਨਯੋਗ ਘੋਸ਼ਣਾਵਾਂ ਇਰਾਦਾ ਅਗਾਂਹ ਰੱਖਦੀਆਂ ਹਨ: ਨਾਮ, ਟਾਈਪ, ਅਤੇ ਇੰਟਰਫੇਸ ਜਲਦੀ ਹੀ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੇ ਹਨ। ਰੋਜ਼ਮਰਾ ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿੱਚ, ਇਹ ਉਹੀ ਵਪਾਰ-ਵਿਜ਼ਣ ਹੈ ਜੋ ਟੀਮਾਂ ਅਜੇ ਵੀ ਕਰਦੀਆਂ ਹਨ—ਥੋੜ੍ਹਾ ਵੱਧ ਸਮਾਂ ਡੇਟਾ ਨੂੰ ਸਾਫ਼ ਕਰਕੇ ਬੀਤੇ ਪੜ੍ਹਨ ਅਤੇ ਤਬਦੀਲ ਕਰਨ ਵਾਲੇ ਘੰਟਿਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣਾ।
Wirth ਕੰਪਾਇਲਰ ਨੂੰ ਇੱਕ ਲੁਕਵੇਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵੇਰਵਾ ਨਹੀਂ ਮੰਨਦਾ ਸੀ। Pascal ਅਤੇ Modula-2 ਲਈ, ਕੰਪਾਇਲਰ ਸਿੱਖਣ ਵਾਲੇ ਮਾਹੌਲ ਦਾ ਕੇਂਦਰੀ ਹਿੱਸਾ ਸੀ: ਉਹ ਨਿਯਮ ਲਗਾਉਂਦਾ, ਗਲਤੀਆਂ ਵਿਆਖਿਆ ਕਰਦਾ, ਅਤੇ ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ ਟ੍ਰਾਇਲ-ਐਂਡ-ਏਰਰ ਬਦਲੇ ਸਪਸ਼ਟ ਢੰਗ ਨਾਲ ਸੋਚਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦਾ।
ਇੱਕ ਸਿੱਖਿਆ-ਮੁਖ ਕੰਪਾਇਲਰ ਸਿਰਫ਼ ਗਲਤ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਰੱਦ ਨਹੀਂ ਕਰਦਾ; ਉਹ ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ ਚੰਗੀਆਂ ਆਦਤਾਂ ਵੱਲ ਧੱਕਦਾ ਹੈ:\n\n- ਮਜ਼ਬੂਤ ਟਾਈਪਿੰਗ ਅਣਿਸ਼ਚਿਤ ਇਰਾਦੇ ਨੂੰ ਸਪਸ਼ਟ ਘੋਸ਼ਣਾਵਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦੀ ਹੈ।\n- ਸੰਰਚਿਤ ਕੰਟਰੋਲ ਫਲੋ ਅਣਪਹੁੰਚਯੋਗ ਕੋਡ ਜਾਂ ਖਰਾਬ ਬਲਾਕਾਂ ਨੂੰ ਫਲੈਗ ਕਰ ਸਕਦਾ ਹੈ।\n- ਸਪਸ਼ਟ ਸਕੋਪਿੰਗ ਨਿਯਮ ਨਾਂ-ਟਕਰਾਅ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ “ਇਹ ਵੈਰੀਏਬਲ ਕਿੱਥੋਂ ਆਇਆ?” ਦਾ ਸਵਾਲ ਤੇਜ਼ੀ ਨਾਲ ਉੱਤਰਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਇਹ ਫੀਡਬੈਕ ਲੂਪ ਕਲਾਸਰੂਮ ਵਿੱਚ ਮੁੱਖ ਹੈ: ਵਿਦਿਆਰਥੀ ਡਾਇਗਨੋਸਟਿਕਸ ਨੂੰ ਪੜ੍ਹਨਾ ਸਿੱਖਦੇ ਅਤੇ ਕਦਮ-ਦਰ-ਕਦਮ ਆਪਣੀ ਸੋਚ ਨੂੰ ਸੁਧਾਰਦੇ ਹਨ, ਨਾ ਕਿ ਰਨਟਾਈਮ ਰਹੱਸਾਂ ਦੀ ਡੀਬੱਗਿੰਗ ਕਰਦੇ।
Wirth ਨੇ ਕੰਪਾਇਲਰ ਨਿਰਮਾਣ ਨੂੰ ਵੀ ਸਿੱਖਿਆਰਥੀ ਅਭਿਆਸ ਵਜੋਂ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ। ਇੱਕ ਛੋਟੀ, ਵਧੀਆ-ਨਿਰਧਾਰਿਤ ਭਾਸ਼ਾ ਨਾਲ ਵਿਦਿਆਰਥੀਆਂ ਲਈ ਇੱਕ ਵਰਕਿੰਗ ਕੰਪਾਇਲਰ (ਜਾਂ ਉਸਦੇ ਭਾਗ) ਕੋਰਸ ਦੇ ਅੰਦਰ ਬਣਾਉਣਾ ਵਿਚਾਰਧਾਰਾ ਵਿੱਚ ਆ ਰਿਹਾ ਸੀ। ਇਸ ਨਾਲ ਲੋਕ ਭਾਸ਼ਾ ਨੂੰ ਜਾਦੂ ਵਜੋਂ ਦੇਖਣਾ ਛੱਡ ਕੇ ਇੱਕ ਸੋਚ-ਵਿਚਾਰ-ਕੀਤੇ ਫੈਸਲਿਆਂ ਦੇ ਸੈੱਟ ਵਜੋਂ ਦੇਖਣ ਲੱਗਦੇ।
ਸਾਦੀ ਭਾਸ਼ਾਵਾਂ ਸਧਾਰਨ ਕੰਪਾਇਲਰਾਂ ਨੂੰ ਯਾਦਗਾਰ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਸਧਾਰਨ ਕੰਪਾਇਲਰ ਆਮ ਤੌਰ ਤੇ ਤੇਜ਼ ਕੰਪਾਇਲ ਕਰਦੇ, ਭਰੋਸੇਯੋਗ ਚਲਦੇ, ਅਤੇ ਸਮਝਣਯੋਗ ਐਰਰ ਸੁਨੇਹੇ ਦੇਂਦੇ—ਇਹ ਸਭ ਜ਼ਰੂਰੀ ਹਨ ਜਦੋਂ ਵਿਦਿਆਰਥੀ ਲਗਾਤਾਰ ਇਟਰੇਟ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ। ਸੀਮਾਵਾਂ ਸਿਰਫ਼ ਰੋਕ ਨਹੀਂ ਹਨ; ਉਹ ਨਾਮਾਤਰ ਧਿਆਨ ਨੂੰ ਡਿਕੰਪੋਜ਼ੀਸ਼ਨ, ਨਾਮਕਰਨ, ਅਤੇ ਸਹੀਤ ਵੱਲ ਸਾਂਭਦੀਆਂ ਹਨ।
ਆਧੁਨਿਕ IDE, linter, ਅਤੇ continuous integration ਪਾਈਪਲਾਈਨ ਉਹੀ ਵਿਚਾਰਕ ਧਾਰਾ ਵਧਾਉਂਦੇ ਹਨ: ਤੇਜ਼, ਆਟੋਮੇਟਿਕ ਫੀਡਬੈਕ ਜੋ ਸਿੱਖਾਉਂਦਾ ਅਤੇ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਅੱਜ ਦੇ ਟੂਲ ਹੋ ਸਕਦੇ ਹਨ ਜ਼ਿਆਦਾ ਸੁਧਰੇ ਹੋਏ ਲੱਗਣ, ਪਰ ਮੁੱਖ ਪੈਟਰਨ—ਛੋਟਾ ਲੂਪ, ਸਪਸ਼ਟ ਡਾਇਗਨੋਸਟਿਕਸ, ਅਤੇ ਨਿਯਮ ਜੋ ਆਦਤਾਂ ਰਚਦੇ ਹਨ—ਉਹੀ ਹਨ ਜਿਸਨੂੰ Wirth ਨੇ ਨਾਰਮਲ ਕੀਤਾ।
Pascal ਹਰ ਕਿਸੇ ਲਈ ਸਭ ਕੁਝ ਹੋਣ ਲਈ ਨਹੀਂ ਸੀ। ਅਮਲ ਵਿੱਚ, ਇਸ ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਮੂਲ੍ਯਤਾ ਉਹਨਾਂ ਸਥਾਨਾਂ 'ਤੇ ਆਈ ਜਿੱਥੇ ਲਕਸ਼ ਸਾਫ਼ ਪ੍ਰੋਗਰਾਮ ਢਾਂਚਾ ਸਿੱਖਣਾ ਅਤੇ ਤਰਕੀਬਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਦਰਸਾਉਣਾ ਸੀ—ਬਿਨਾਂ ਨੀਵੀਂ-ਪੱਧਰੀ ਵੇਰਵਿਆਂ 'ਤੇ ਧਿਆਨ ਭਟਕਾਉਣ ਦੇ।
Pascal ਉਸ ਵੇਲੇ ਚਮਕਦਾਰ ਤੌਰ 'ਤੇ ਚੰਗਾ ਸੀ ਜਦੋਂ ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਇੱਕ ਸੋਚੀ-ਸਮਝੀ ਯੋਜਨਾ ਵਾਂਗ ਪੜ੍ਹਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਇਸਦਾ ਜ਼ੋਰ ਸੰਰਚਿਤ ਕੰਟਰੋਲ ਫਲੋ ਅਤੇ ਸਪਸ਼ਟ ਟਾਈਪਾਂ 'ਤੇ ਇਹ ਪ੍ਰੇਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸੋਚੋ ਕਿ ਡੇਟਾ ਕੀ ਹੈ, ਉਹ ਕਿਸ ਤਰ੍ਹਾਂ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਕਿੱਥੇ ਬਦਲਣਾ ਮਨਜ਼ੂਰ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ ਮਜ਼ਬੂਤ ਉਪਯੋਗ-ਕੇਸ ਸਮੇਤ:\n\n- ਪ੍ਰੋਗਰਾਮਿੰਗ ਦੀਆਂ ਮੁੱਢਲੀ ਸਿਧਾਂਤਾਂ (ਵੈਰੀਏਬਲ, ਕੰਟਰੋਲ ਫਲੋ, ਪ੍ਰੋਸੀਜਰ/ਫੰਕਸ਼ਨ) ਸਿੱਖਾਉਣਾ\n- ਅਲਗੋਰਿਥਮ ਲਿਖਣਾ ਅਤੇ ਚਰਚਾ ਕਰਨ ਲਈ ਸੰਪੂਰਨ ਤਰੀਕੇ ਨਾਲ ਟਰੇਸ ਕਰਨਯੋਗ ਰੂਪ ਵਿੱਚ\n- ਛੋਟੇ ਤੋਂ ਦਰਮਿਆਨੇ ਪ੍ਰੋਗ੍ਰਾਮ ਬਣਾਉਣਾ ਜਿੱਥੇ ਸਫਾਈ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ
ਜਦੋਂ ਪ੍ਰਾਜੈਕਟ ਵੱਡੇ ਹੋ ਗਏ, ਲੋਕ ਅਕਸਰ ਭਾਸ਼ਾ ਅਤੇ ਇਸਦੇ ਮਿਆਰੀ ਟੂਲਿੰਗ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਛੁਹਣ ਲੱਗਦੇ ਸਨ। ਪ੍ਰਣਾਲੀ-ਜੁੜੀ ਕੰਮਾਂ ਅਤੇ ਹਾਰਡਵੇਅਰ-ਨੇੜੇ ਕੰਮਾਂ ਲਈ ਵਰਤੀ ਜਾਣ ਵਾਲੀਆਂ ਭਾਸ਼ਾਵਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰਨ 'ਤੇ, Pascal ਕੁਝ ਹੱਦ ਤੱਕ ਸੀਮਿਤ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਸੀ।
ਆਮ ਤਕਲੀਫਾਂ:\n\n- ਸਟੈਂਡਰਡ Pascal ਵਿੱਚ ਲੋਅ-ਲੈਵਲ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਸੀਮਾ (ਜੋ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਲਈ ਲੋੜੀਂਦੀ)\n- ਬਹੁਤ ਵੱਡੇ ਪ੍ਰੋਗਰਾਮ ਬਣਾਉਂਦੇ ਸਮੇਂ friction\n- “ਸੁਰੱਖਿਅਤ ਕੰਮ” ਕਰਨ ਤੇ ਕਈ ਵਾਰੀ ਵੱਧ ਕਾਰਵਾਈ ਲੱਗਣੀ
Pascal ਦੇ ਵਿਆਪਕ ਵਰਤੋਂ ਕਾਰਨ, ਕਈ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਨੇ ਇਸਦੀ ਵਿਆਖਿਆ ਨੂੰ ਵੱਖ-ਵੱਖ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਵਧਾਇਆ—ਅਕਸਰ ਬਿਹਤਰ ਟੂਲਿੰਗ, ਤੇਜ਼ ਕੰਪਾਈਲੇਸ਼ਨ, ਜਾਂ ਵਾਧੂ ਭਾਸ਼ਾਈ ਫੀਚਰਾਂ ਲਈ। ਉਦਾਹਰਣਾਂ ਵਿੱਚ UCSD Pascal, Turbo Pascal, ਅਤੇ ਬਾਅਦ ਵਿੱਚ Object Pascal ਸ਼ਾਮਿਲ ਹਨ। ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕਿਹੜਾ ਡਾਇਲੈਕਟ “ਜਿੱਤਿਆ” — ਇੰਤਹਾ ਤੱਕ ਘੱਟ ਮਾਇਨੇ ਰੱਖਦੀ; ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਨੇ Pascal ਦੀ ਸਪੱਠਤਾ ਅਤੇ ਹੋਰ ਪ੍ਰਯੋਗਿਕ ਤਾਕਤ ਦੋਵਾਂ ਚਾਹੀਦੀ।
ਸਾਦਗੀ ਇੱਕ ਡਿਜ਼ਾਈਨ ਚੋਣ ਹੈ: ਇਹ ਕਰਨ ਦੇ ਤਰੀਕਿਆਂ ਦੀ ਗਿਣਤੀ ਘਟਾਉਂਦੀ ਹੈ। ਇਹ ਸਿੱਖਣ ਅਤੇ ਕੋਡ ਰਿਵਿਊ ਲਈ ਵਧੀਆ ਹੈ—ਪਰ ਜਦੋਂ ਤੀਚਾਂ ਫੈਲ ਜਾਂਦੀਆਂ ਹਨ (ਸਿਸਟਮ ਇੰਟਿਗ੍ਰੇਸ਼ਨ, concurrency, ਬੜੇ ਕੋਡਬੇਸ), ਤਬ ਘੱਟ ਨਿਰਮਾਣ-ਹੈਚਟਸ ਟੀਮਾਂ ਨੂੰ ਇਕਸਾਰੇ ਵਾਧੂ-ਵਿਕਲਪਾਂ ਜਾਂ ਵੱਖਰੀ ਭਾਸ਼ਾ ਵੱਲ ਧੱਕ ਸਕਦੇ ਹਨ।
Pascal ਸਿੱਖਾਉਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ: ਇਸ ਨੇ ਸਪਸ਼ਟ ਕੰਟਰੋਲ ਫਲੋ, ਮਜ਼ਬੂਤ ਟਾਈਪ, ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਕੀਤਾ। ਪਰ ਜਦੋਂ ਉਹੀ ਵਿਦਿਆਰਥੀ ਅਸਲੀ ਟੂਲ—ਐਡੀਟਰ, ਕੰਪਾਇਲਰ, ਓਐਸ ਕੰਪੋਨੈਂਟ—ਬਣਾਉਣ ਲੱਗੇ, ਤਾਂ “ਸਿੱਖਣ ਵਾਲੀ ਭਾਸ਼ਾ” ਦੀਆਂ ਸੀਮਾਵਾਂ ਸਾਹਮਣੇ ਆਈਆਂ। ਵੱਡੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ "ਇੱਕ ਵੱਡੇ ਪ੍ਰੋਗਰਾਮ ਨਾਲ ਪ੍ਰੋਸੀਜਰਾਂ" ਤੋਂ ਵੱਧ ਸਪਸ਼ਤ ਢਾਂਚੇ ਦੀ ਲੋੜ ਸੀ, ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਕੰਮ ਵੰਡਣ ਲਈ ਇੱਕ ਤਰੀਕਾ ਚਾਹੀਦਾ ਸੀ ਕਿ ਇਕ ਦੂਜੇ 'ਤੇ ਨਾਹ ਚਲਕੇ।
Wirth ਦੀ ਗਤੀ Pascal ਤੋਂ Modula ਤੱਕ ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਉਸਨੇ ਸਾਦਗੀ ਨੂੰ ਰੱਦ ਕੀਤਾ; ਉਹ ਇਸਨੂੰ ਪ੍ਰਾਜੈਕਟ ਵੱਧਣ ਤੇ ਬਰਕਰਾਰ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਸੀ। ਲਕਸ਼ ਬਦਲਿਆ: “ਕਿਸੇ ਨੂੰ ਪ੍ਰੋਗਰਾਮ ਸਿੱਖਾਉਣਾ” ਤੋਂ “ਲੋਕਾਂ ਨੂੰ ਸਿਸਟਮ ਬਿਨਾਂ ਗੁੰਝਲ ਤੋਂ ਬਣਾ ਸਕਣ” ਵਿੱਚ।
Modula ਦੀ ਮੁੱਖ ਵਿਚਾਰਧਾਰਾ ਮੋਡੀਊਲ ਹੈ: ਇੱਕ ਨਾਮਿਤ ਇਕਾਈ ਜੋ ਸੰਬੰਧਤ ਡੇਟਾ ਅਤੇ ਆਪਰੇਸ਼ਨਾਂ ਨੂੰ ਗਰੁੱਪ ਕਰਦੀ ਹੈ। ਪਰੰਪਰਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋਣ ਦੀ ਥਾਂ, ਭਾਸ਼ਾ ਉਸ ਆਯੋਜਨਾ ਨੂੰ ਸਿਧਾ ਸਹਿਯੋਗ ਦਿੰਦੀ।
ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਢਾਂਚਾ ਪ੍ਰੋਗਰਾਮ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ, ਨਾ ਕਿ ਕੇਵਲ ਦਸਤਾਵੇਜ਼ੀ। ਪੜ੍ਹਨ ਵਾਲਾ ਸਿਸਟਮ ਨੂੰ ਕੰਪੋਨੈਂਟਾਂ ਦੇ ਇੱਕ ਗਰੁੱਪ ਵਜੋਂ ਸਮਝ ਸਕਦਾ ਹੈ—ਹਰ ਇਕ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਸਪਸ਼ਟ—ਨਕਲ ਕੀਤੇ ਹੋਏ ਫਰਮਾਂ ਦੀ ਲੰਬੀ ਸੂਚੀ ਵਾਂਗ ਨਹੀਂ।
Modula ਇੰਟਰਨਫੇਸ ਅਤੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਦਰਮਿਆਨ ਵੱਖਰਾ ਕਰਦਾ ਹੈ। ਸਿੱਖਣ ਵਾਲਿਆਂ ਲਈ ਇਹ ਇੱਕ ਮਜ਼ਬੂਤ ਆਦਤ ਸਿਖਾਉਂਦਾ: ਕਿਸੇ ਕੰਪੋਨੈਂਟ ਨੂੰ ਉਸਦੇ ਕਾਨਟ੍ਰੈਕਟ ਰਾਹੀਂ ਵਰਤੋ, ਨਾਂ ਕਿ ਉਸਦੀ ਅੰਦਰੂਨੀ ਬਣਤਰ ਨੂੰ ਛੇੜੋ।
ਵੱਡੇ ਕੋਡਬੇਸ ਲਈ ਇਹ ਤਬਦੀਲੀ ਦਾ ਸਹਾਰਾ ਬਣਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਮੋਡੀਊਲ ਦੀ ਅੰਦਰੂਨੀ ਚੀਜ਼ਾਂ ਸੁਧਾਰ ਸਕਦੇ ਹੋ—ਪ੍ਰਦਰਸ਼ਨ, ਡੇਟਾ ਸਟ੍ਰਕਚਰ, ਸੁਰੱਖਿਆ ਜਾਂਚ—ਬਿਨਾਂ ਹਰ ਥਾਂ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਲੋੜ ਪਏ।
ਜਦੋਂ ਮੋਡੀਊਲ ਹੱਦਾਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ, ਸਹਿਯੋਗ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਟੀਮਾਂ ਇੰਟਰਫੇਸ ਤੇ ਸਹਿਮਤ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪੈਰਲੇਲ ਕੰਮ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਛੋਟੀਆਂ ਇਕਾਈਆਂ ਵਿੱਚ ਬਦਲਾਵਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਗੈਰ-ਮਣਾਹੀ ਤੌਰ 'ਤੇ ਕੁਨੈਕਸ਼ਨ ਘੱਟ ਹੋ ਜਾਂਦੇ ਹਨ। ਅਮਲ ਵਿੱਚ, ਇਹ Wirth ਦੇ ਮੁਢਲੀ ਆਦਰਸ਼—ਸਪਸ਼ਟਤਾ, ਅਨੁਸ਼ਾਸਨ, ਅਤੇ ਮਕਸਦ-ਭਰੀ ਸਾਦਗੀ—ਕਲਾਸਰੂਮ ਤੋਂ ਗੰਭੀਰ ਸਿਸਟਮਾਂ ਤੱਕ ਸਕੇਲ ਹੋ ਜਾਂਦੇ ਹਨ।
Pascal ਨੇ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਦੇ ਅੰਦਰ ਸਪਸ਼ਟਤਾ ਸਿਖਾਈ। Modula-2 ਨੇ ਅਗਲਾ ਪਾਠ ਜੋੜਿਆ: ਪ੍ਰੋਗਰਾਮ ਦੇ ਹਿੱਸਿਆਂ ਦੇ ਵਿਚਕਾਰ ਸਪਸ਼ਟਤਾ। Wirth ਦਾ ਬੇਟ ਸਾਦਾ ਸੀ—ਬਹੁਤ ਸਾਰੇ ਸੌਫਟਵੇਅਰ ਸਮੱਸਿਆਵਾਂ ਹੋਰ ਨਹੀਂ ਸੁਝਾਉਂਦੀਆਂ; ਬਲਕਿ ਕੋਡ ਨੂੰ ਐਸਾ ਰੂਪ ਦੇ ਕੇ ਹੱਲ ਹੋਦੀਆਂ ਹਨ ਕਿ ਲੋਕ ਇਸ 'ਤੇ ਲੰਬे ਸਮੇਂ ਤੱਕ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰ ਸਕਣ।
ਇੱਕ ਮੋਡੀਊਲ ਇੱਕ ਨਾਮਿਤ ਡੱਬਾ ਹੈ ਜੋ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਕੰਮ—ਜਿਵੇਂ “ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਪੜ੍ਹਨਾ” ਜਾਂ “ਪ੍ਰਿੰਟਰ ਨਾਲ ਗੱਲਬਾਤ”—ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਂਦਾ ਹੈ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮ ਦੇ ਹੋਰ ਹਿੱਸਿਆਂ ਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਮੋਡੀਊਲ ਇਹ ਕੰਮ ਕਿਵੇਂ ਕਰਦਾ ਹੈ; ਉਹ ਸਿਰਫ਼ ਜਾਣਦੇ ਹਨ ਕਿ ਉਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ।
Modula-2 ਜਨਤਕ ਸਤਹ ਅਤੇ ਨਿੱਜੀ ਅੰਦਰੂਨੀ ਰਚਨਾ ਵਿਚਕਾਰ ਅਲੱਗ-ਅਲੱਗਤਾ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ। ਇਹ “ਛੁਪਾਉਣ” ਗੁਪਤਤਾ ਨਹੀ ਹੈ; ਇਹ ਸੁਰੱਖਿਆ ਹੈ। ਜਦੋਂ ਅੰਦਰੂਨੀ ਡੇਟਾ ਓਪਰੇਸ਼ਨ ਨਿੱਜੀ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਹੋਰ ਕੋਡ ਉਸ ਨੂੰ ਹੈਰਾਨ ਕਰਨ-ਯੋਗ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਛੇੜ ਸਕਦਾ, ਜਿਸ ਨਾਲ ਅਣਚਾਹੀਆਂ ਬੱਗਸ ਘਟਦੀਆਂ ਹਨ।
Modula-2 ਦੀ ਡਿਫਿਨੀਸ਼ਨ ਮੋਡੀਊਲਾਂ ਕਾਨਟ੍ਰੈਕਟ ਵਾਂਗ ਕੰਮ ਕਰਦੀਆਂ ਹਨ: ਉਹ ਉਹ ਪ੍ਰੋਸੀਜਰ ਅਤੇ ਟਾਈਪ گਿਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਮੋਡੀਊਲ ਦੇਣ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਉਹ ਕਾਨਟ੍ਰੈਕਟ ਸਥਿਰ ਰੱਖਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖ ਸਕਦੇ ਹੋ—ਉਸਨੂੰ optimize, ਸਧਾਰਨ, ਜਾਂ bugfix—ਬਿਨਾਂ ਹਰ ਥਾਂ ਤਬਦੀਲ ਕਰਨ ਦੀ ਲੋੜ ਪਏ। ਇਹ ਰੀਫੈਕਟਰਿੰਗ ਲਈ ਗਾਰਡਰੇਲਸ ਵਾਂਗ ਹੈ।
ਜੇ ਤੁਸੀਂ Go ਵਿੱਚ packages, Rust ਵਿੱਚ crates, C# ਵਿੱਚ namespaces, ਜਾਂ Python ਵਿੱਚ libraries ਵਰਤੇ ਹਨ, ਤਦ ਤੁਸੀਂ ਉਹੀ ਮੋਡੀਊਲਰ ਸੋਚ ਮਹਿਸੂਸ ਕੀਤੀ ਹੋਏਗੀ: ਸਪਸ਼ਟ ਹੱਦਾਂ, exported APIs, ਅਤੇ ਅੰਦਰੂਨੀ ਚੀਜ਼ਾਂ ਨੂੰ ਰੋਕਨਾ।
ਕਈ ਵਿਕਾਸਕਾਰਾਂ ਨੇ ਢਾਂਚਾ ਕੇਵਲ ਵੱਡੇ ਕੋਡਬੇਸ ਨਾਲ ਲੜਾਈ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੀ ਸਿੱਖਿਆ। Modula-2 ਦਾ ਦਲੀਲ ਇਹ ਹੈ: ਹੱਦਾਂ ਪਹਿਲਾਂ ਸਿੱਖਾਓ, ਨਾ ਕਿ ਬਾਅਦ ਵਿੱਚ—ਤਾਂ ਕਿ “ਇਹ ਕੋਡ ਕਿਥੇ ਰਹੇ?” ਸਵਾਲ ਬਚਾਓ ਮਿਸ਼ਨ ਨਾ ਬਣੇ।
Concurrency ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ “ਸਾਦੀ ਭਾਸ਼ਾਵਾਂ” ਅਕਸਰ ਫੀਚਰਾਂ ਨਾਲ ਭਰ ਦਿਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ: ਫ਼ਿਲਸੂਦ, ਲਾਕ, ਐਟਾਮਿਕ, ਮੈਮੋਰੀ ਮਾਡਲ ਅਤੇ ਕਈ ਐੱਜ ਕੇਸ। Wirth ਦਾ ਹਲ ਵਿਰੋਧੀ ਸੀ—ਛੋਟੇ, ਸਪਸ਼ਟ ਮਕੈਨਿਜ਼ਮ ਦਿੰਦੇ ਹੋਏ ਸਮੰਨਵਯ ਮਨਾਉਣਾ ਜੋ ਹਰ ਪ੍ਰੋਗਰਾਮ ਨੂੰ synchronization ਪਜ਼ਲ ਵਿਚ ਨਹੀਂ ਬਦਲਦਾ।
Modula-2 ਇੱਕ ਅਚਛਾ ਉਦਾਹਰਨ ਹੈ। ਪ੍ਰੀ-ਐਂਟਰਪਟਿਵ ਥ੍ਰੈੱਡਜ਼ 'ਤੇ ਭਾਰ ਨਾ ਪਾ ਕੇ, ਇਸ ਨੇ coroutines ਪੇਸ਼ ਕੀਤੇ: ਕੰਮਾਂ ਨੂੰ ਕੋਆਪਰੇਟਿਵ ਤਰੀਕੇ ਨਾਲ ਸਾਂਭਣ ਦਾ ਇਕ ਤਰੀਕਾ ਜਿੱਥੇ ਨਿਯੰਤਰਣ ਜਾਣ-ਪਛਾਣ ਨਾਲ ਬਦਲਦਾ ਹੈ। ਮਕਸਦ ਕੱਚੀ ਪੈਰਲੇਲ ਗਤੀ ਨਹੀਂ; ਇਹ ਸਪਸ਼ਟਤਾ ਹੈ। ਤੁਸੀਂ “ਦੋ ਗਤਿਵਿਧੀਆਂ” ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਅੱਗੇ ਵਧਦੇ ਵੇਖਾ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਪਹਿਲੀ ਪਾਠ ਦੇ ਤਾਈਮਿੰਗ ਹੰਗਾਮਿਆਂ ਦੇ।
ਇਸਦੇ ਨਾਲ-ਨਾਲ Wirth ਦੇ ਮੁਰੰਮਤਕ ਸੰਦ concurrency ਕੋਡ ਵਿੱਚ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਮਜ਼ਬੂਤ ਟਾਈਪਿੰਗ, ਸਪਸ਼ਟ ਇੰਟਰਫੇਸ, ਅਤੇ ਮੋਡੀਊਲਰ ਬਾਊਂਡਰੀਆਂ। ਇਹ ਲੋਹ-ਲੋਹ ਹਾਲਾਤਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਰੋਕਦੇ, ਪਰ ਬਹੁਤ ਸਾਰਾ ਅਣਚਾਹਾ ਪੇਚੀਦਾ ਰੋਕ ਦਿੰਦੇ ਹਨ—ਜਿਵੇਂ ਗਲਤ ਡੇਟਾ ਫੈਰਾਂ ਨੂੰ ਤਰਲ ਰਾਹੀਂ ਭੇਜਣਾ ਜਾਂ ਅੰਦਰੂਨੀ ਸਟੇਟ ਦਾ ਰਿਸਾਵ।
ਜਦੋਂ concurrency ਨੂੰ "ਨਿਯਮਾਂ ਵਾਲੀ ਸਮਨਵਯਤਾ" ਵਜੋਂ ਸਿੱਖਾਇਆ ਜਾਂਦਾ ਹੈ (ਨ ਕਿ “ਲਾਕ ਬਣਾ ਕੇ ਜਦ ਤਕ ਸਹੀ ਨਾ ਲੱਗੇ”), ਵਿਦਿਆਰਥੀ ਉਹ ਆਦਤਾਂ ਸਿੱਖਦੇ ਹਨ ਜੋ ਅਸਲੀ ਸਿਸਟਮਾਂ ਵਿੱਚ ਵੀ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ: ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨਿਰਧਾਰਿਤ ਕਰੋ, ਸਟੇਟ ਅਲੱਗ ਰੱਖੋ, ਅਤੇ ਇੰਟਰੈਕਸ਼ਨ ਸਪਸ਼ਟ ਬਣਾਓ। ਇਹ ਮਨੋਭਾਵ ਆਉਣ ਵਾਲੀਆਂ ਬਿਹਤਰ ਅਮਲਾਂ—structured concurrency, actor-style messaging, ਅਤੇ “ਜਿਸਾਂ ਨੂੰ ਤੁਸੀਂ ਮੋਡੀਫਾਈ ਕਰਦੇ ਹੋ ਉਹ ਤੁਹਾਡਾ ਹੋਵੇ”—ਦੇ ਲਈ ਤਿਆਰ ਕਰਦਾ ਹੈ।
ਦੁਹਰਾਉਂਦਾ ਰੂਪ ਇਹ ਹੈ: ਘੱਟ ਪ੍ਰਿਮਿਟਿਵ, ਵਿਵਹਾਰ ਸਪਸ਼ਟ, ਅਤੇ ਡਿਜ਼ਾਈਨ ਜੋ ਗਲਤ ਸਥਿਤੀਆਂ ਨੂੰ ਦਰਸਾਉਣਾ ਔਖਾ ਕਰਦਾ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿੱਚ ਇਹ ਘੱਟ heisenbugs, ਆਸਾਨ ਡਿਬੱਗਿੰਗ, ਅਤੇ ਸਮਝਣਯੋਗ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ—ਕਿਉਂਕਿ ਕੋਡ ਸੋਚੇ-ਸਮਝੇ ਤਰੀਕੇ ਨਾਲ ਲਿਖਿਆ ਗਿਆ ਸੀ, ਨਾ ਕਿ ਕੇਵਲ ਚਲਾਉਣ ਲਈ।
Wirth ਦੀਆਂ ਭਾਸ਼ਾਵਾਂ ਸਿਰਫ਼ “ਪੜ੍ਹਨ ਯੋਗ” ਨਹੀਂ ਸਨ। ਉਨ੍ਹਾਂ ਨੇ ਪਠਨਯੋਗਤਾ, ਢਾਂਚਾ, ਅਤੇ ਸਹੀਤਾ ਨੂੰ ਇੰਜੀਨੀਅਰਿੰਗ ਦੀਆਂ ਬਾਂਧਣਾਂ ਵਜੋਂ ਦੇਖਿਆ—ਉਹੋ ਜਿਹੇ ਜਿਵੇਂ ਪ੍ਰਦਰਸ਼ਨ ਬਜਟ ਜਾਂ ਸੁਰੱਖਿਆ ਮੰਗਾਂ। ਇਹ ਬਾਂਧਣ ਰੋਜ਼ਮਰਾ ਦੇ ਤਰੀਕੇ ਵਿੱਚ ਉਭਰਦੀਆਂ ਹਨ ਜਿਥੇ ਆਧੁਨਿਕ ਟੀਮਾਂ ਸੌਫਟਵੇਅਰ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਕਈ ਟੀਮਾਂ ਹੁਣ ਪਠਨਯੋਗਤਾ ਨੂੰ ਆਪਣੀ ਵਰਕਫ਼ਲੋ ਵਿੱਚ ਸੰਕੋਚਿਤ ਕਰਦੀਆਂ ਹਨ: ਸਟਾਈਲ ਗਾਈਡ, linter, ਅਤੇ “ਇਸਨੂੰ ਬੋਰੀੰਗ ਬਣਾਓ” ਨਿਯਮ। ਇਹ ਮਨੋਭਾਵ Pascal/Modula ਦੇ ਲਕਸ਼ ਨਾਲ ਮਿਲਦਾ ਹੈ — ਡਿਫਾਲਟ ਕੋਡ ਸਮਝਣਯੋਗ ਬਣਾਉਣਾ। ਅਮਲ ਵਿੱਚ, ਇਹ ਸਪਸ਼ਟ ਕੰਟਰੋਲ ਫਲੋ, ਛੋਟੇ ਫੰਕਸ਼ਨ, ਅਤੇ ਨਾਂ ਐਸਾ ਰੱਖਣਾ ਹੈ ਜੋ ਇਰਾਦਾ ਦਰਸਾਏ—ਤਾਂ ਕਿ ਬਦਲਾਅ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਮੀਖਿਆ ਕੀਤੇ ਜਾ ਸਕਣ।
ਮਜ਼ਬੂਤ ਟਾਈਪਿੰਗ ਸਿਰਫ਼ ਗਲਤੀਆਂ ਰੋਕਣ ਲਈ ਨਹੀਂ; ਇਹ ਕੰਪਾਇਲਰ ਰਾਹੀਂ ਜਾਂਚਯੋਗ ਦਸਤਾਵੇਜ਼ੀ ਵੀ ਹੈ। ਆਧੁਨਿਕ ਸਟੈਟਿਕ ਟਾਈਪਡ ਇਕੋਸਿਸਟਮ (ਅਤੇ TypeScript ਵਰਗੀਆਂ typed ਲੇਅਰਾਂ) ਉੱਘੇ ਵਿਚਾਰਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ: ਟਾਈਪ ਦੱਸਦੇ ਹਨ ਕਿ ਕੋਈ ਫੰਕਸ਼ਨ ਕੀ ਉਮੀਦ ਕਰਦਾ ਅਤੇ ਵਾਅਦਾ ਕਰਦਾ ਹੈ। ਕੋਡ ਰਿਵਿਊਅਰ ਅਕਸਰ ਟਾਈਪਾਂ ਨੂੰ API ਕਾਂਟਰੈਕਟ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਵੇਖਦੇ ਹਨ—ਤਕ ਕਿ ਗਲਤ ਧਾਰਨਾਵਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਬੱਗ ਤੋਂ ਪਹਿਲਾਂ ਫੜੀਆਂ ਜਾ ਸਕਣ।
Wirth ਦਾ ਜ਼ੋਰ ਸਪੱਠ, ਪਰਸਪਰ ਵਰਗ ਫੀਚਰਾਂ 'ਤੇ ਅਨੁਕੂਲਤਾ ਅੱਜ ਦੀ “ਚਲਾਕੀ ਘਟਾਓ” ਸਭਿਆਚਾਰ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਜਿਹੜੀਆਂ ਟੀਮਾਂ metaprogramming ਘੱਟ ਵਰਤਦੀਆਂ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਜਨਰਲ ਅਭਿਕਲਪਨ ਤੋਂ ਦੂਰ ਰਹਿੰਦੀਆਂ, ਅਤੇ ਡੀਪੈਂਡੈਂਸੀ ਸਾਫ ਰੱਖਦੀਆਂ ਹਨ, ਉਹ ਸਾਦਗੀ ਨੂੰ ਇੱਕ ਰਣਨੀਤੀ ਵਜੋਂ ਅਪਣਾਉਂਦੀਆਂ ਹਨ: ਘੱਟ ਐੱਡਜ ਕੇਸ, ਘੱਟ ਅਚਾਨਕ ਇੰਟਰੈਕਸ਼ਨ, ਅਤੇ ਨਵੇਂ ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਤੇਜ਼ ਓਨਬੋਰਡਿੰਗ।
ਆਧੁਨਿਕ ਮੋਡੀਊਲਰ ਡਿਜ਼ਾਈਨ—ਪੈਕੇਜ, ਸਰਵਿਸ, ਅਤੇ ਠੀਕ-ਪਰਿਭਾਸ਼ਿਤ ਇੰਟਰਫੇਸ—Modula ਦੀ ਇਸ ਜ਼ੋਰ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ: ਸਪਸ਼ਟ ਹੱਦਾਂ ਅਤੇ ਸਥਿਰ_public APIs ਟੀਮਾਂ ਨੂੰ ਇੰਟਰਨਲ ਬਦਲਣ ਬਿਨਾਂ ਸਿਸਟਮ ਭੰਗ ਕੀਤੇ ਬਿਨਾਂ ਵਿਕਸਤ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ। ਇਹ ਬਦਲਾਅ ਨੂੰ ਸੰਭਾਲਣ ਦਾ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਹੈ, ਡਰ ਦੇ ਨਾਲ ਨਹੀਂ।
ਚੰਗੀਆਂ ਸਮੀਖਿਆਂ ਵਿੱਚ ਅਕਸਰ Wirth-ਵਾਂਗ ਸਵਾਲ ਆਉਂਦੇ ਹਨ: “ਕੀ ਇਹ ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ ਹੈ?”, “ਕੀ ਟਾਈਪ ਸਿਸਟਮ ਇਸ ਇਨਵੈਰੀਅਂਟ ਨੂੰ ਵੇਖਾ ਸਕਦਾ ਹੈ?”, “ਕੀ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਵੱਖਰੀਆਂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ?”, “ਕੀ ਇਹ ਹੱਦ ਭਵਿੱਖੀ ਬਦਲਾਅ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀ?” ਇਹ ਭਾਸ਼ਾਈ ਸਿਧਾਂਤ ਰੋਜ਼ਾਨਾ ਇੰਜੀਨੀਅਰਿੰਗ ਆਦਤਾਂ ਬਣ ਗਏ ਹਨ।
“ਪ੍ਰਭਾਵ” ਬਾਰੇ ਗੱਲ ਕਰਨ ਸਮੇਂ ਧੁੰਦਲੀ ਹੋ ਸਕਦੀ ਹੈ। Pascal ਅਤੇ Modula-2 ਹਰ ਥਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਭਾਸ਼ਾ ਬਣ ਕੇ ਨਹੀਂ ਜਿੱਤੇ। ਉਹਨਾਂ ਦਾ ਪ੍ਰਭਾਵ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਇੱਕ ਵਿਚਾਰਾਂ ਦੇ ਸੈਟ ਵਜੋਂ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ—ਸਪਸ਼ਟਤਾ, ਢਾਂਚਾ, ਅਤੇ ਟੂਲ-ਸਹਾਇਤ ਅਨੁਸ਼ਾਸਨ—ਜਿਹਨਾਂ ਨੂੰ ਹੋਰਾਂ ਨੇ ਲਿਆ, ਅਨੁਕੂਲ ਕੀਤਾ, ਅਤੇ ਕਈ ਵਾਰੀ ਨਰਮ ਕੀਤਾ।
ਬਹੁਤ ਸਾਰੇ ਵਿਕਾਸਕਾਰਾਂ ਲਈ, Pascal ਉਹਨਾਂ ਦੀ ਪਹਿਲੀ ਗੰਭੀਰ ਭਾਸ਼ਾ ਸੀ। ਇਹ ਧਿਆਨ ਯੋਗ ਸੀ। ਇਹ ਆਦਤਾਂ ਨੂੰ ਪੱਕਾ ਕਰਦਾ ਸੀ:\n\n- ਪ੍ਰੋਗਰਾਮ ਟੌਪ-ਡਾਊਨ, ਛੋਟੇ ਪ੍ਰੋਸੀਜਰ ਵਿੱਚ ਲਿਖੋ\n- ਸਪਸ਼ਟ ਟਾਈਪ ਅਤੇ ਮਾਣਵ-ਯੋਗ ਡੇਟਾ ਪਰਿਭਾਸ਼ਾਵਾਂ ਵਰਤੋ\n- ਪਠਨਯੋਗਤਾ ਨੂੰ ਸਹੀਤਾ ਦਾ ਹਿੱਸਾ ਸਮਝੋ, ਸਰਹੱਦੀ ਜ਼ਰੀਏ ਨਹੀਂ
ਇਹ ਵਿਦਿਆਰਥੀ ਜਦੋਂ C, C++, Java, ਜਾਂ Python 'ਤੇ ਗਏ ਤਾਂ ਭਾਵਨਾ ਆਮ ਤੌਰ 'ਤੇ ਬਚੀ ਰਹੀ: “ਪ੍ਰੋਗਰਾਮ ਇੱਕ ਮੁਢਲੇ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਹਿੱਸਿਆਂ ਦਾ ਸੈੱਟ ਹੁੰਦਾ ਹੈ।”
Modula-2 ਨੇ ਇੱਕ ਅਜਿਹਾ ਵੱਖਰਾਪਨ ਦਿੱਖਾਇਆ ਜੋ ਅੱਜ ਆਮ ਲੱਗਦਾ ਹੈ: ਇੰਟਰਫੇਸ ਨੂੰ ਅਲੱਗ ਕਰਨਾ ਅਤੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨੂੰ ਲੁਕਾਉਣਾ। ਤੁਸੀਂ ਇਸ ਵਿਚਾਰ ਦੇ ਹੇਠਾਂ ਕਈ ਸੰਬੰਧੀ ਧਾਰਾਵਾਂ ਦੇਖੋਗੇ—headers vs source, modules vs packages, public APIs vs private internals। ਵਿਸਥਾਰ ਵਿੱਚ ਫਰਕ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਲਕਸ਼ ਇੱਕੋ ਹੈ: ਦਰਮਿਆਨੀ ਨਿਰਭਰਤਾਵਾਂ ਸਪਸ਼ਟ ਬਣਾਓ ਅਤੇ ਇੱਕ ਵੱਡੇ ਸਿਸਟਮ ਨੂੰ ਸਮਝਣਯੋਗ ਰੱਖੋ।
Wirth ਦੀਆਂ ਬਾਅਦੀ ਭਾਸ਼ਾਵਾਂ (ਜਿਵੇਂ Oberon) ਨੇ ਇਹ ਧਾਰਾ ਜਾਰੀ ਰੱਖਿਆ: ਸਤਹ ਨੂੰ ਘਟਾਓ, ਨਿਯਮਾਂ ਨੂੰ ਇਕਸਾਰ ਰੱਖੋ, ਅਤੇ ਕੰਪਾਇਲਰ ਨੂੰ ਕੋਡ ਗੁਣਵੱਤਾ ਬਣਾਈ ਰੱਖਣ ਵਿੱਚ ਸਾਥੀ ਬਣਾਓ। ਹਰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਫੀਚਰ ਨਹੀਂ ਫੈਲਿਆ, ਪਰ ਛੋਟੇ, ਸੁਚਾਰੇ ਡਿਜ਼ਾਇਨਾਂ ਲਈ ਪਸੰਦ ਜਾਰੀ ਰਹੀ ਅਤੇ ਅਧਿਆਪਕਾਂ ਤੇ ਭਾਸ਼ਾ ਡਿਜ਼ਾਇਨਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ।
Pascal/Modula ਦਾ ਪ੍ਰਭਾਵ ਸਿੰਟੈਕਸ ਦੀ ਨਕਲ ਕਰਨ ਦੇ ਬਜਾਏ ਕੁਝ ਉਮੀਦਾਂ ਨੂੰ ਆਮ ਕਰਨ ਵਿੱਚ ਹੈ: ਸਿੱਖਣ ਵਾਲੀ ਸਹਾਇਤਾ ਵਜੋਂ ਮਜ਼ਬੂਤ ਟਾਈਪਿੰਗ, ਚਲਾਕ ਤਰੀਕਿਆਂ ਦੀ ਥਾਂ ਸੰਰਚਿਤ ਕੰਟਰੋਲ ਫਲੋ, ਅਤੇ ਮੋਡੀਊਲਰ ਡਿਜ਼ਾਈਨ complexity ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ। ਇਹ ਉਮੀਦਾਂ ਮੈਨਸਟਰੀਮ ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਸਭਿਆਚਾਰ ਦਾ ਹਿੱਸਾ ਬਣ ਗਈਆਂ—ਅਜੇ ਵੀ ਭਿਨਨ ਇਕੋਸਿਸਟਮ ਹੋਣ ਦੇ ਬਾਵਜੂਦ।
Wirth ਦਾ ਟਿਕਾਊ ਪਾਠ ਇਹ ਨਹੀਂ ਹੈ ਕਿ “ਫਿਰੋਂ Pascal ਵਰਤੋਂ।” ਇਹ ਕਿ ਇੱਕ ਸਿਸਟਮ ਅਸਾਨ ਬਣ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਉਸਦੇ ਮੁੱਖ ਵਿਚਾਰ ਥੋੜ੍ਹੇ, ਇਕਸਾਰ, ਅਤੇ ਟੂਲਿੰਗ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤੇ ਜਾਣ।
ਜੇ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਇਕੋ ਕੰਮ ਕਰਨ ਦੇ ਕਈ ਤਰੀਕੇ ਹਨ, ਤਦਾ ਤੁਹਾਨੂੰ ਓਨਬੋਰਡਿੰਗ ਸਮਾਂ, ਰਿਵਿਊ ਵਿਚ ਵਿਚਾਰ ਵਿਵਾਦ, ਅਤੇ ਨਾਜੁਕ ਬੱਗਸ ਦਾ ਭੁਗਤਾਨ ਕਰਨਾ ਪੈਂਦਾ। ਇੱਕ “ਛੋਟਾ ਕੋਰ” ਉਹ ਸਮੇਂ ਵਧੀਆ ਹੈ ਜਦੋਂ:\n\n- ਤੁਹਾਡੇ ਕੋਲ ਕਈ ਯੋਗਦਾਨਕਾਰ ਹਨ (ਜਾਂ ਤੇਜ਼ ਬਦਲਾਅ ਵਾਲੀ ਟੀਮ)\n- ਤੁਸੀਂ ਅਜਿਹੇ ਫਾਊਂਡੇਸ਼ਨਲ ਸਰਵਿਸ ਦਾ ਨਿਰਮਾਣ ਕਰ ਰਹੇ ਹੋ ਜਿਸ 'ਤੇ ਹੋਰ ਭਰੋਸਾ ਕਰਦੇ ਹਨ\n- ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਵਾਰ-ਵਾਰੀਆਂ ਖ਼ਤਰਿਆਂ ਨੂੰ ਦੇਖ ਰਹੇ ਹੋ ਜੋ ਅਸੰਤੁਲਿਤ ਪੈਟਰਨਾਂ ਤੋਂ ਆ ਰਹੇ ਹਨ
ਅਮਲ ਵਿੱਚ, ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪੈਟਰਨਾਂ (error handling, logging, configuration, concurrency primitives) 'ਤੇ ਸਥਿਰ ਰਹੋ ਅਤੇ ਆਮ ਕੰਮਾਂ ਲਈ “ਇੱਕ ਸਪਸ਼ਟ ਤਰੀਕਾ” ਬਾਰੇ ਸਪਸ਼ਟ ਰਹੋ।
Pascal ਅਤੇ Modula ਨੇ ਇਹ ਦਿਖਾਇਆ ਕਿ ਕੰਪਾਇਲਰ ਇੱਕ ਸਾਥੀ ਹੋ ਸਕਦਾ ਹੈ। ਆਧੁਨਿਕ ਸਮਕਾਲੀ ਬਰਾਬਰਾਂ:\n\n- ਆਪਣੇ ਡੋਮੇਨ ਟਾਈਪ ਮਜ਼ਬੂਤ ਕਰੋ: UserId ਵਰਗੀਆਂ ਵੱਖ-ਵੱਖ ਟਾਈਪਾਂ ਨੂੰ ਵਰਤੋ strings ਦੀ ਥਾਂ।\n- ਮੋਡੀਊਲਾਂ ਨੂੰ ਸਪਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕਰੋ: APIs ਛੋਟੇ ਰੱਖੋ, ਅੰਦਰੂਨੀ ਗੁਪਤ ਰੱਖੋ, ਅਤੇ “utility” ਮੋਡੀਊਲਾਂ ਤੋਂ ਬਚੋ ਜੋ dumping grounds ਬਣ ਜਾਂਦੀਆਂ ਹਨ।\n- ਗਲਤ ਸਥਿਤੀਆਂ ਨੂੰ ਦਰਸਾਉਣਾ ਔਖਾ ਬਣਾਓ: enums, sealed unions, non-nullable fields, ਅਤੇ validated constructors ਵਰਤੋ।
ਚੰਗੀ ਇੰਜੀਨੀਅਰਿੰਗ ਸਭਿਆਚਾਰ ਕਈ ਵਾਰ ਦੁਹਰਾਈ ਅਤੇ ਉਦਾਹਰਣਾਂ ਰਾਹੀਂ ਸਿਖਾਉਂਦੀ ਹੈ:\n\n- ਸਟਾਈਲ ਗਾਈਡ ਜੋ ਕਿਉਂ ਨੂੰ ਵੀ ਵੇਖਾਉਂਦਾ ਹੈ, ਨਹੀਂ ਸਿਰਫ਼ ਕੀ।\n- ਕੋਡ ਰਿਵਿਊ ਜੋ canonical pattern ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦੇ ਹਨ (“Module X ਵਾਂਗ ਕਰੋ”).\n- ਛੋਟੇ ਰੈਫਰੈਂਸ ਪ੍ਰੋਜੈਕਟ ਅਤੇ ਟੈਂਪਲੇਟ ਜੋ ਤੁਹਾਡੇ ਪREFERRED ਢਾਂਚੇ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ।
ਭਾਵੇਂ ਤੁਸੀਂ ਚੈਟ-ਪਹਿਲਾਂ ਵਰਕਫ਼ਲੋ ਰਾਹੀਂ ਸੌਫਟਵੇਅਰ ਬਣਾਉਂਦੇ ਹੋ, Wirth ਦੇ ਸਿਧਾਂਤ ਲਾਗੂ ਹੁੰਦੇ ਹਨ: ਆਉਟਪੁੱਟ ਪੜ੍ਹਨਯੋਗ, ਮੋਡੀਊਲਰ, ਅਤੇ ਸਤਯਾਪਿਤ ਹੋਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਣ ਲਈ, Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ (ਇੱਕ vibe-coding ਮਾਹੌਲ ਜੋ ਚੈਟ ਤੋਂ ਪੂਰੇ ਵੈੱਬ, ਬੈਕਐਂਡ, ਅਤੇ ਮੋਬਾਇਲ ਐਪ ਜਨਰੇਟ ਕਰਦਾ ਹੈ) ਬਹੁਤ ਹੱਦ ਤੱਕ ਉਹੀ “ਸਿੱਖਣਯੋਗ ਕੋਰ” ਧਾਰਨਾ ਵਰਤਦਾ ਹੈ: ਪਲੈਨਿੰਗ ਮੋਡ ਇਰਾਦਾ ਸਪਸ਼ਟ ਕਰਨ ਲਈ, ਜਨਰੇਟ ਕੀਤੇ ਕੋਡ ਵਿੱਚ ਸਪਸ਼ਟ ਮੋਡੀਊਲ ਬਾਉਂਡਰੀਆਂ, ਅਤੇ ਤੇਜ਼ ਫੀਡਬੈਕ ਲੂਪ।
ਕੁਝ ਤਰੀਕੇ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ LLM ਸਹਾਇਤ ਨਾਲ ਡਿਵੈਲਪਮੈਂਟ ਕਰਦੇ ਸਮੇਂ Wirth-ਵਾਂਗ ਅਨੁਸ਼ਾਸਨ ਰੱਖ ਸਕਦੇ ਹੋ:\n\n- ਇੱਕ ਛੋਟਾ “ਇੰਟਰਫੇਸ-ਪਹਿਲਾਂ” ਪ੍ਰੰਪਟ ਵਰਤੋ: ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ APIs, ਟਾਈਪ, ਅਤੇ ਮੋਡੀਊਲ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।\n- ਛੋਟੇ ਇਟਰੇਸ਼ਨ ਨੂੰ ਤਰਜੀਹ ਦਿਓ—snapshots ਅਤੇ rollback ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਬਦਲਾਵਾਂ ਨੂੰ ਇੱਕ ਸੰਗਠਿਤ ਕੋਡ ਰਿਵਿਊ ਵਾਂਗ ਜाँच ਸਕੋ।\n- ਨਿਰਯਾਤ/ਡਿਪਲੌਇਮੈਂਟ ਲਾਜ਼ੀਮੀ ਖਪਤ ਯਕੀਨੀ ਬਣਾਓ: ਸੋਰਸ ਨਿਰਯਾਤ ਕਰਨ ਅਤੇ ਕਸਟਮ ਡੋਮੇਨ ਨਾਲ ਹੋਸਟ ਕਰਨ ਦੀ ਯੋਗਤਾ generated code ਨੂੰ ਇੱਕ maintainable codebase ਵਾਂਗ ਰੱਖਦੀ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਇੱਕ-ਵਾਰੀ ਆଇਟਮ।
ਜੇ ਤੁਸੀਂ ਹੋਰ ਪ੍ਰਯੋਗਿਕ ਮਾਰਗਦਰਸ਼ਨ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ /blog/programming-best-practices ਦੇਖੋ। ਜੇ ਤੁਸੀਂ conventions ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਾਲੇ ਟੂਲਿੰਗ (linters, CI checks, review automation) ਦੀ ਤੁਲਨਾ ਕਰ ਰਹੇ ਹੋ ਤਾਂ /pricing ਨਾਲ ਚੋਣਾਂ ਦੇ ਧਾਂਚੇ ਬਾਰੇ ਸੋਚ ਸਕਦੇ ਹੋ।
Wirth ਨੇ ਸਪੱਸ਼ਟਤਾ ਅਤੇ ਅਨੁਸ਼ਾਸਨਤ ਢਾਂਚੇ ਲਈ ਅਰਥਪੂਰਨ ਡਿਜ਼ਾਇਨ ਕੀਤਾ — ਨਾ ਕਿ ਵੱਧ ਤੋਂ ਵੱਧ ਫੀਚਰ। ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਘਣਭੀੜ ਅਤੇ ਅਸਪਸ਼ਟ ਇਰਾਦੇ ਕਾਰਨ ਹੋਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਵੱਧ ਆਮ ਹਨ, ਨਾ ਕਿ ਭਾਸ਼ਾ ਦੀ ਘਾਟ।
Structured programming ਤੁਹਾਨੂੰ sequence, selection, ਅਤੇ repetition (ਸਪੱਸ਼ਟ ਬਲਾਕ, ਲੂਪ ਅਤੇ ਸ਼ਰਤੀ ਵਿਵਹਾਰ) ਵੱਲ ਧੱਕਦਾ ਹੈ, ਨਾ ਕਿ ਬੇਤਰਤੀਬ ਛੱਲਾਂ ਵੱਲ। ਪਰੈਕਟਿਕਲ ਤੌਰ ਤੇ, ਇਸ ਨਾਲ ਕੋਡ ਟ੍ਰੇਸ, ਰਿਵਿਊ ਅਤੇ ਡਿਬੱਗ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਰੂਟੀਨ ਨੂੰ ਉੱਪਰ-ਤੋਂ-ਥੱਲੇ ਪੜ੍ਹ ਕੇ ਸੰਭਾਵਿਤ ਐਗਜ਼ਿਕਿਊਸ਼ਨ ਪਾਥ ਸਮਝ ਸਕਦੇ ਹੋ।
ਮਜ਼ਬੂਤ ਟਾਈਪਿੰਗ ਡੇਟਾ ਦੀਆਂ ਸ਼ਕਲਾਂ ਅਤੇ ਧਾਰਨਾਵਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਅਤੇ ਕੰਪਾਇਲਰ-ਚੈੱਕਯੋਗ ਬਣਾਉਂਦੀ ਹੈ। ਅੱਜ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ:
UserId ਬਨਾਮ string)Pascal ਦਾ ਬਲਾਕ ਸਟ੍ਰੱਕਚਰ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਜਗ੍ਹਾ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਵੈਰੀਏਬਲ ਉਸੇ ਥਾਂ ਰਹਿੰਦੇ ਜਿਥੇ ਉਹ ਘੋਸ਼ਿਤ ਕੀਤੇ ਗਏ ਹਨ, ਅਤੇ ਲੋਕਲ ਡੇਟਾ ਲੋਕਲ ਹੀ ਰਹਿੰਦੀ ਹੈ। ਪ੍ਰਯੋਗਕ ਤੌਰ ਤੇ ਇਹ ਮਤਲਬ ਹੈ ਗਲੋਬਲ ਸਟੇਟ ਘੱਟ ਰੱਖੋ ਅਤੇ ਮਿਊਟੇਬਲ ਡੇਟਾ ਨੂੰ ਸਭ ਤੋਂ ਛੋਟੇ ਜ਼ਿੰਮੇਵਾਰ ਯੂਨਿਟ ਵਿੱਚ ਰੱਖੋ—ਇਸ ਨਾਲ ਲੁਕਵੀਂ ਡੀਪੈੰਡेंसीਆਂ ਅਤੇ ਸਾਈਡ-ਇਫੈਕਟ ਘਟਦੇ ਹਨ।
Pascal ਨੇ explicit parameters ਵਾਲੀਆਂ procedures/functions ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ, ਜਿਸ ਨਾਲ ਕੰਮ ਨੂੰ ਛੋਟੇ, ਸਮਝਣਯੋਗ ਯੂਨਿਟਾਂ ਵਿੱਚ ਵੰਡਣਾ ਸਿਖਾਇਆ ਜਾਂਦਾ ਹੈ। ਪ੍ਰੈਕਟਿਕਲ ਨਿਯਮ:
ਸਿੱਖਿਆ-ਮੁਖ ਕੰਪਾਇਲਰ ਕਿਸੇ ਗਲਤ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਸਿਰਫ਼ ਰੱਦ ਨਹੀਂ ਕਰਦਾ—ਉਹ ਸਿੱਖਣ ਵਾਲਿਆਂ ਨੂੰ ਚੰਗੀ ਆਦਤਾਂ ਵੱਲ ਧੱਕਦਾ ਹੈ:
ਅਜਿਹੇ ਕੰਪਾਇਲਰ-ਬਜਾਰੀਆਂ ਦੀ ਤੇਜ਼ ਫੀਡਬੈਕ ਲੂਪ ਕਲਾਸਰੂਮ ਵਿੱਚ ਬਹੁਤ ਕੀਮਤੀ ਹੈ।
Modula-2 ਨੇ modules ਨੂੰ ਪਹਿਲੇ ਦਰਜੇ ਦੀ ਇਕਾਈ ਬਣਾ ਕੇ ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਦਿੱਤਾ: ਇੱਕ ਕੰਪੋਨੈਂਟ ਸੰਬੰਧਤ ਡੇਟਾ ਅਤੇ ਆਪਰੇਸ਼ਨਾਂ ਨੂੰ ਇੱਕਠੇ ਰੱਖਦਾ ਹੈ ਅਤੇ ਇੱਕ ਛੋਟਾ ਜਨਤਕ ਇੰਟਰਫੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਪ੍ਰਯੋਗਕ ਫ਼ਾਇਦਾ ਇਹ ਹੈ ਕਿ ਇੰਟਰਫੇਸ ਸਥਿਰ ਰਹਿਣ 'ਤੇ ਅੰਦਰੂਨੀ ਇੰਪਲਿਮੈਂਟੇਸ਼ਨ ਬਦਲੀ ਜਾ ਸਕਦੀ ਹੈ ਬਿਨਾ ਦੂਜਿਆਂ ਨੂੰ ਤਬਦੀਲ ਕਰਨ ਦੀ ਲੋੜ ਪਏ।
ਇਹ ਸਿਧਾਂਤ theoretical ਹੀ ਨਹੀਂ: interface vs implementation ਇਸ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:
Pascal ਦੀ ਸਪੱਠਤਾ ਨਾਲ ਲਾਗੂ ਕਰਨ ਵਾਲੀਆਂ ਸੁਵਿਧਾਵਾਂ ਨੂੰ ਰੱਖਦੇ ਹੋਏ ਵੱਖ-ਵੱਖ ਟੂਲਿੰਗ ਅਤੇ ਫੀਚਰਾਂ ਸ਼ਾਮਲ ਕਰਨ ਲਈ UCSD, Turbo, Object Pascal ਵਰਗੀਆਂ ਡਾਇਲੈਕਟਸ ਉਭਰੀਆਂ। ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਟੀਮਾਂ ਅਕਸਰ ਸਪੱਠ ਕੋਰ + ਚੁਣੀ ਹੋਈ ਵਿਕਲਪਿਕਤਾਵਾਂ ਚਾਹੁੰਦੇ ਹਨ—ਸੀਮਤ ਪਰ ਬਿਆਨਤmak escape hatches।
ਪ੍ਰਯੋਗਿਕ ਨੁਕਤੇ:
ਹੋਰ ਪ੍ਰਯੋਗੀ ਨਿਰਦੇਸ਼ਾਂ ਲਈ /blog/programming-best-practices ਦੇਖੋ। ਜੇ ਤੁਸੀਂ টੂਲਿੰਗ ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰ ਰਹੇ ਹੋ ਤਾਂ /pricing ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ।