ਜਾਣੋ ਕਿ Grace Hopper ਨੇ ਕੰਪਾਇਲਰਾਂ ਦੀ ਖੋਜ ਕਿਵੇਂ ਮੁੱਖ ਭੂਮਿਕਾ ਨਿਭਾਈ, ਪੜ੍ਹਨਯੋਗ ਕੋਡ ਲਈ ਦਬਾਅ ਕਿਉਂ ਕੀਤਾ, ਅਤੇ COBOL ਵਰਗੀਆਂ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਆਕਾਰ ਦਿੱਤਾ—ਜਿਸ ਨਾਲ ਸਾਫਟਵੇਅਰ ਲਿਖਣ ਅਤੇ ਰੱਖਣ ਦਾ ਢੰਗ ਹੀ ਬਦਲ ਗਿਆ।
ਅਧਿਕਤਰ ਲੋਕ ਕੋਡ ਇਸ ਉਮੀਦ ਨਾਲ ਲਿਖਦੇ ਹਨ ਕਿ ਉਹ ਪੜ੍ਹਨਯੋਗ, ਮੁੜ-ਉਪਯੋਗ ਯੋਗ ਅਤੇ ਕਾਫੀ ਪੋਰਟੇਬਲ ਹੋਵੇਗਾ। ਅਸੀਂ ਵਰਿਆਬਲਾਂ ਨੂੰ ਨਾਮ ਦਿੰਦੇ ਹਾਂ, ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਮੰਨ ਲੈਂਦੇ ਹਾਂ ਕਿ ਸਾਡਾ ਪ੍ਰੋਗਰਾਮ ਅਜਿਹੀਆਂ ਮਸ਼ੀਨਾਂ 'ਤੇ ਚੱਲੇਗਾ ਜੋ ਅਸੀਂ ਕਦੇ ਦੇਖੀ ਹੀ ਨਹੀਂ। ਇਹ ਉਮੀਦ ਕਿਸੇ ਸੰਕਟ ਦੇ ਨਤੀਜੇ ਨਹੀਂ ਹੈ। ਇਹ ਮਨੁੱਖ ਅਤੇ ਕੰਪਿਊਟਰ ਵਿਚਕਾਰ ਕੰਮ ਵੰਡਣ ਦੇ ਤਰੀਕੇ ਵਿਚ ਇੱਕ ਵੱਡੇ ਬਦਲਾਵ ਦਾ ਨਤੀਜਾ ਹੈ—ਅਤੇ ਕੰਪਾਇਲਰ ਉਸ ਦੌਲਤ ਦਾ ਪੁਲ ਹਨ।
ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਗ੍ਰਾਮਰ ਉਹ “ਟਾਈਪਿੰਗ ਕੋਡ” ਨਹੀਂ ਕਰ ਰਹੇ ਸਨ ਜਿਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਹੁਣ ਸੋਚਦੇ ਹਾਂ। ਉਹ ਮਸ਼ੀਨਾਂ ਨੂੰ ਇਸ ਲੈਵਲ 'ਤੇ ਸੰਭਾਲ ਰਹੇ ਸਨ ਜੋ ਇੰਨੀ ਵਿਸਥਾਰਵਾਦੀ ਅਤੇ ਨਾਜ਼ੁਕ ਸੀ ਕਿ ਹਰ ਨਿਰਦੇਸ਼ ਇੱਕ ਹੱਥ-ਕਮਾਈ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦਾ ਸੀ। ਮੁੱਖ ਸਵਾਲ ਇਹ ਹੈ:
ਕਿਵੇਂ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਹਾਰਡਵੇਅਰ-ਅਧਾਰਤ ਕਲਾ ਤੋਂ ਮਨੁੱਖ-ਕੇਂਦਰਿਤ ਅਭਿਆਸ ਵੱਲ ਟਰਾਂਸਫਰ ਹੋਈ ਜਿਸ ਨੂੰ ਟੀਮ ਸਮੇਂ ਦੇ ਨਾਲ ਰੱਖ ਸਕਣ?
Grace Hopper ਇਸ ਬਦਲਾਵ ਵਿੱਚ ਕੇਂਦਰੀ ਹੈ ਕਿਉਂਕਿ ਉਹ ਆਪਣੇ ਸਮੇਂ ਲਈ ਇੱਕ ਰੈਡੀਕਲ ਵਿਚਾਰ ਨੂੰ ਅੱਗੇ ਲਿਆਈ: ਕੰਪਿਊਟਰ ਨੂੰ ਤਰਜਮਾ ਕਰਨ ਦਾ ਕੰਮ ਜ਼ਿਆਦਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਲੋਕਾਂ ਨੂੰ ਇਕੋ ਮਸ਼ੀਨ ਲਈ ਲੰਬੇ, ਗਲਤੀ-ਪੂਰਨ ਸਿੱਕੜੇ ਲਿਖਣ ਦੀ ਬਜਾਏ, Hopper ਨੇ ਸ਼ੁਰੂਆਤੀ ਕੰਪਾਇਲਰ ਕੰਮ ਲਈ ਰਾਹ ਖੋਲ੍ਹਿਆ—ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਸਿਸਟਮ ਜਿਹੜੇ ਮਨੁੱਖ-ਮਿੱਤਰ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਉਸ ਨੀਵੇਂ-ਪੱਧਰ ਦੇ ਕਦਮਾਂ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਜੋ ਮਸ਼ੀਨ ਅਸਲ ਵਿੱਚ ਚਲਾਉਂਦੀ ਹੈ।
ਉਸ ਦਾ ਕੰਮ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ “ਤਰਜਮਾ” ਕੋਈ ਆਇਫ਼-ਆਈ ਲਕਜ਼ਰੀ ਨਹੀਂ ਸੀ—ਇਹ ਉਤਪਾਦਕਤਾ ਵਿੱਚ ਇੱਕ ਬ੍ਰੇਕਥਰੂ ਸੀ। ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੇ ਇਰਾਦੇ ਨੂੰ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਵਿਅਕਤ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ:
ਅਸੀਂ ਵੇਖਾਂਗੇ ਕਿ ਕੰਪਾਇਲਰਾਂ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਕਿਵੇਂ ਲੱਗਦੀ ਸੀ, ਇੱਕ ਕੰਪਾਇਲਰ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ (ਬਿਨਾਂ ਜਾਰਗਨ ਦੇ), ਅਤੇ Hopper ਦੇ A-0 ਕੰਮ ਅਤੇ COBOL ਦੇ ਉਭਾਰ ਨੇ ਕਿਵੇਂ ਸਾਫਟਵੇਅਰ ਨੂੰ ਪੜ੍ਹਨਯੋਗ, ਮਿਆਰੀ ਭਾਸ਼ਾਵਾਂ ਵੱਲ ਧਕੇਲਿਆ। ਰਾਹ ਵਿੱਚ, ਤੁਸੀਂ ਉਹ ਪ੍ਰਯੋਗਿਕ ਨਤੀਜੇ ਵੇਖੋਗੇ ਜੋ ਅਜੇ ਵੀ ਆਧੁਨਿਕ ਵਿਕਾਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ: ਪੋਰਟੇਬਿਲਟੀ, ਟੀਮਵਰਕ, ਲੰਬੇ ਸਮੇਂ ਦੀ ਮੁਰੰਮਤ, ਅਤੇ ਦੈਨੰਦਿਨ ਧਾਰਨਾ ਕਿ ਕੋਡ ਮਨੁੱਖਾਂ ਦੁਆਰਾ ਸਮਝਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ—ਸਿਰਫ ਮਸ਼ੀਨਾਂ ਲਈ ਨਹੀ।
ਜੇ ਤੁਸੀਂ ਕਦੇ ਕਿਸੇ ਸਾਫ਼ ਐਰਰ ਸੁਨੇਹੇ, ਪੋਰਟੇਬਲ ਕੋਡ, ਜਾਂ ਐਸੀ ਭਾਸ਼ਾ ਦਾ ਲਾਭ ਉਠਾਇਆ ਹੈ ਜੋ ਨਿਰਦੇਸ਼ਾਂ ਵਾਂਗ ਪੜ੍ਹਨ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤੀ ਗਈ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਸ ਦੁਨੀਆਂ ਵਿੱਚ ਰਹਿ ਰਹੇ ਹੋ ਜੋ Hopper ਨੇ ਬਣਾਈ।
Grace Hopper ਨੇ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ “ਅਸਾਨ” ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਕੀਤਾ ਸੀ। ਉਸ ਨੇ ਉਥੇ ਸ਼ੁਰੂ ਕੀਤਾ ਜਿੱਥੇ ਸ਼ੁਰੂਆਤੀ ਕੰਪਿਊਟਿੰਗ ਨੇ ਮੰਗ ਕੀਤੀ ਸੀ: ਮਸ਼ੀਨ ਦੀਆਂ ਸੀਮਾਵਾਂ ਤੋਂ। ਗਣਿਤ ਵਿਦਿਆਰਥੀ ਹੋਣ ਦੇ ਨਾਤੇ, ਉਹ World War II ਦੌਰਾਨ U.S. Navy ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੋਈ ਅਤੇ Harvard Mark I 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਨਿਯੁਕਤ ਹੋਈ—ਇੱਕ ਪਹਿਲੀ ਵੱਡੀ-ਪੱਧਰੀ electromechanical ਕੰਪਿਊਟਰਾਂ ਵਿੱਚੋਂ ਇੱਕ।
Mark I ਕੋਈ ਲੈਪਟਾਪ ਨਹੀਂ ਸੀ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਗਲਤੀ ਹੋਣ 'ਤੇ ਰੀਬੂਟ ਕਰ ਸਕਦੇ; ਇਹ ਇੱਕ ਕਮਰੇ-ਅੰਦਰਲਾ ਸਰੋਤ ਸੀ ਜੋ ਇੱਕ ਟੀਮ ਦੁਆਰਾ ਸਾਝਾ ਕੀਤਾ ਜਾਂਦਾ ਸੀ, ਸੰਭਾਲ-ਸਮੇਂ ਦੇ ਅਨੁਸਾਰ ਸ਼ਡਿਊਲ ਕੀਤਾ ਜਾਂਦਾ ਸੀ, ਅਤੇ ਮਹੰਗੇ ਲੈਬ ਉਪਕਰਣ ਵਰਗਾ ਵਰਤਿਆ ਜਾਂਦਾ ਸੀ।
ਕੰਪਾਇਲਰਾਂ ਤੋਂ ਪਹਿਲਾਂ, ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਉਸ ਕੰਟਰੋਲ ਪੈਨਲ ਨੂੰ ਵਾਇਰ ਕਰਨ ਦੇ ਨੇੜੇ ਸੀ ਬਜਾਏ ਇਸਦੇ ਕਿ ਅਸੀਂ ਹੁਣ ਜਾਣੇ ਵਾਲੇ ਕੋਡ ਲਿਖੀਏ। ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਹਾਰਡਵੇਅਰ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਅਨੁਕੂਲ ਹੋਣਾ ਪੈਂਦਾ ਸੀ, ਅਕਸਰ ਨੰਬਰਾਂ ਦੇ ਕੋਡ ਜਾਂ ਬਹੁਤ ਹੀ ਨੀਵਲੇ-ਪੱਧਰ ਦੇ ਆਪਰੇਸ਼ਨਾਂ ਵਜੋਂ। ਜੇ ਤੁਸੀਂ ਮਸ਼ੀਨ ਨੂੰ ਜੋੜਨਾ, ਤੁਲਨਾ ਕਰਨੀ, ਜਾਂ ਮੁੱਲ ਹਿਲਾਉਣਾ ਚਾਹੁੰਦੇ ਸੀ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਮਸ਼ੀਨ ਦੀ ਆਪਣੀ ਭਾਸ਼ਾ—ਕਦਮ-ਬਦ-ਕਦਮ—ਵਿੱਚ ਵਿਅਕਤ ਕਰਦੇ ਸੀ।
ਉਹ ਕੰਮ:
ਸ਼ੁਰੂਆਤੀ ਕੰਪਿਊਟਰ ਘੱਟ ਮਿਲਦੇ ਸਨ, ਅਤੇ "ਕੰਪਿਊਟਰ ਟਾਈਮ" ਇੱਕ ਬਜਟ ਆਈਟਮ ਸੀ। ਤੁਸੀਂ ਆਰਾਮ ਨਾਲ ਇੱਕ ਪ੍ਰੋਗ੍ਰਾਮ ਨੂੰ ਦਸ ਵਾਰੀ ਨਹੀਂ ਚਲਾ ਸਕਦੇ ਸਨ ਕਿ ਵੇਖੋ ਕੀ ਹੁੰਦਾ ਹੈ। ਟੀਮਾਂ ਧਿਆਨ ਨਾਲ ਤਿਆਰੀ ਕਰਦੀਆਂ, ਦੋ-ਤਿੰਨ ਵਾਰ ਚੈੱਕ ਕਰਦੀਆਂ, ਫਿਰ ਰਨ ਲਈ ਉੱਲਾਂਗਦੀਆਂ। ਹਰ ਖਰਚ ਹੋਇਆ ਮਿੰਟ ਜੋ ਬੇਕਾਰ ਗਲਤੀਆਂ ਤੇ ਗੁਜ਼ਰਿਆ ਉਹ ਅਸਲ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਲਈ ਖ਼ਰਚ ਕੀਤਾ ਨਹੀਂ ਗਿਆ।
ਇਸ ਦਬਾਅ ਨੇ Hopper ਦੇ ਸੋਚਣ ਨੂੰ ਰੂਪ ਦਿੱਤਾ: ਜੇ ਮਨੁੱਖ ਮਸ਼ੀਨ ਦੀ ਭਾਸ਼ਾ ਬੋਲਣ ਵਿੱਚ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲਾ ਰਹੇ ਹਨ ਨ ਕਿ ਕੰਮ ਹੱਲ ਕਰਨ ਵਿੱਚ, ਤਾਂ ਬੋਤਲ-ਨੈਕ ਸਿਰਫ ਹਾਰਡਵੇਅਰ ਹੀ ਨਹੀਂ—ਉਹ ਤਰੀਕਾ ਸੀ।
ਕੰਪਾਇਲਰਾਂ ਤੋਂ ਪਹਿਲਾਂ, ਪ੍ਰੋਗ੍ਰਾਮਰ ਮਸ਼ੀਨਾਂ ਦੀ ਆਪਣੀ "ਦੇਸੀ" ਭਾਸ਼ਾ ਵਿੱਚ ਗੱਲ ਕਰਦੇ ਸਨ।
ਮਸ਼ੀਨ ਕੋਡ 0s ਅਤੇ 1s ਦੀ ਇੱਕ ਸਟਰੀਮ ਹੈ ਜੋ ਪ੍ਰੋਸੈਸਰ ਸਿੱਧਾ ਚਲਾਉਂਦਾ ਹੈ। ਹਰ ਪੈਟਰਨ ਮਤਲਬ ਰੱਖਦਾ ਹੈ—ਜਿਵੇਂ "ਇਹ ਦੋ ਨੰਬਰ ਜੋੜੋ," "ਇਸ ਮੁੱਲ ਨੂੰ ਹਿਲਾਓ," ਜਾਂ "ਹੋਰ ਕਦਮ 'ਤੇ ਜਾਓ"। ਇਹ ਬਹੁਤ ਹੀ ਸटीਕ ਹੈ—ਪਰ ਮਨੁੱਖਾਂ ਲਈ ਪੜ੍ਹਨ, ਲਿਖਣ ਅਤੇ ਡੀਬੱਗ ਕਰਨ ਲਈ ਬਹੁਤ ਹੀ ਔਖਾ।
Assembly language ਮਸ਼ੀਨ ਕੋਡ ਨਾਲ ਨਿਕਨੇਮ ਜੋੜਦਾ ਹੈ। ਕੱਚੇ ਬਿੱਟਾਂ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਛੋਟੇ ਸ਼ਬਦ ਲਿਖਦੇ ਹੋ ਜਿਵੇਂ LOAD, ADD, ਜਾਂ JUMP, ਨਾਲ ਹੀ ਮੈਮੋਰੀ ਐਡਰੈੱਸ। ਫਿਰ ਇਕ assembler ਇਨ੍ਹਾਂ ਸ਼ਬਦਾਂ ਨੂੰ ਉਸ ਖ਼ਾਸ ਮਸ਼ੀਨ ਲਈ ਸਹੀ 0s ਅਤੇ 1s ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ ਹੈ।
ਐਸੈਂਬਲੀ ਮਸ਼ੀਨ ਕੋਡੋਂ ਬਹੁਤਰੇ ਆਸਾਨ ਸੀ, ਪਰ ਇਸ ਨੇ ਫਿਰ ਵੀ ਲੋਕਾਂ ਨੂੰ ਹਾਰਡਵੇਅਰ ਦੀ ਸੋਚ ਕਰਨ 'ਤੇ ਮਜਬੂਰ ਕੀਤਾ: ਰਜਿਸਟਰ, ਮੈਮੋਰੀ ਸਥਾਨ, ਅਤੇ ਆਪਰੇਸ਼ਨਾਂ ਦਾ ਸਹੀ ਕ੍ਰਮ।
ਸ਼ੁਰੂਆਤੀ ਕੰਪਿਊਟਰ ਅਦਲ-ਬਦਲ ਨਹੀਂ ਸੀ। ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ ਦੀਆਂ ਇੰਸਟਰਕਸ਼ਨ ਸੈਟ, ਮੈਮੋਰੀ ਲੇਆਉਟ ਅਤੇ ਨੰਬਰ ਪ੍ਰਤਿਨਿਧਤਾ ਦੇ ਤਰੀਕੇ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ ਸਨ। ਇੱਕ ਪ੍ਰੋਗ੍ਰਾਮ ਜੋ ਇੱਕ ਪ੍ਰੋਸੈਸਰ ਲਈ ਲਿਖਿਆ ਗਿਆ ਸੀ ਉਹ ਦੂਜੇ 'ਤੇ ਚੱਲ ਹੀ ਨਹੀਂ ਸਕਦਾ ਸੀ।
ਸਾਫਟਵੇਅਰ ਇੱਕ "ਰੇਸਪੀ" ਦੀ ਬਜਾਏ ਇੱਕ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਬਣੀ ਕੁੰਜੀ ਵਰਗਾ ਸੀ ਜੋ ਇੱਕ ਹੀ ਲਾਕ ਲਈ ਬਣੀ ਹੋਵੇ।
ਕਿਉਂਕਿ ਪ੍ਰੋਗ੍ਰਾਮ ਨੀਵੀ-ਪੱਧਰ ਦੇ ਕਦਮਾਂ ਤੋਂ ਬਣੇ ਹੋਏ ਸਨ, ਇੱਕ "ਸਾਦਾ" ਬੇਨਤੀ—ਜਿਵੇਂ ਇੱਕ ਨਵਾਂ ਰਿਪੋਰਟ ਕਾਲਮ ਜੋੜਨਾ, ਫ਼ਾਈਲ ਫਾਰਮੈਟ ਬਦਲਣਾ, ਜਾਂ ਗਣਨਾ ਦੇ ਗੋਲਿੰਗ ਤਰੀਕੇ ਨੂੰ ਠੀਕ ਕਰਨਾ—ਸੰਪੂਰਨ ਪ੍ਰੋਗ੍ਰਾਮ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਸੀ।
ਜੇ ਨਵੀਂ ਫੀਚਰ ਲਈ ਜ਼ਿਆਦਾ ਨਿਰਦੇਸ਼ ਲੋੜੇ ਹੁੰਦੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਮੈਮੋਰੀ ਐਡਰੈੱਸ ਦੁਬਾਰਾ ਰੱਖਣੇ ਪੈਂਦੇ, ਜੰਪ ਟਾਰਗੇਟ ਅਪਡੇਟ ਕਰਨੇ ਪੈਂਦੇ, ਅਤੇ ਹਰ ਥਾਂ ਜਿਸਨੇ ਪੁਰਾਣੀ ਲੇਆਉਟ ਨੂੰ ਮੰਨਿਆ ਸੀ ਉਹਨਾਂ ਨੂੰ ਜਾਂਚਨਾ ਪੈਂਦਾ। ਮਸ਼ੀਨ ਦਾ ਸਮਾਂ ਕੀਮਤੀ ਸੀ, ਪਰ ਮਨੁੱਖੀ ਸਮਾਂ ਅਸਲ ਰੋਕ ਸੀ—ਅਤੇ ਇਹ ਉਹਨਾਂ ਵਿਸਥਾਰਾਂ 'ਤੇ ਬਰਬਾਦ ਹੋ ਰਿਹਾ ਸੀ ਜੋ ਕਾਰੋਬਾਰੀ ਸਮੱਸਿਆ ਨਾਲ ਘੱਟ ਹੀ ਜੁੜੇ ਸਨ।
ਸ਼ੁਰੂਆਤੀ ਕੰਪਿਊਟਰ ਤਾਕਤਵਰ ਸਨ ਪਰ ਦਰਦਨਾਕ ਤੌਰ 'ਤੇ ਸ਼ਬਦੀ। ਉਹ ਸਿਰਫ ਉਹੀ ਨਿਰਦੇਸ਼ ਮੰਨਦੇ ਸਨ ਜੋ ਹਾਰਡਵੇਅਰ ਸਮਝਦਾ ਸੀ। ਇਸ ਦਾ ਮਤਲਬ ਸੀ ਕਿ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਅਕਸਰ ਮਸ਼ੀਨ ਨੂੰ ਇੱਕ-ਕਦਮ-ਬਾਅਦ-ਇੱਕ-ਕਦਮ ਲਿਖਣ ਵਾਂਗ ਸੀ।
ਇੱਕ ਕੰਪਾਇਲਰ ਕੰਮ ਦੇ ਨਮੂਨੇ ਨੂੰ ਉਲਟ ਦਿੱਤਾ: ਲੋਕ "ਮਸ਼ੀਨ ਬੋਲਣ" ਦੀ ਬਜਾਏ ਇੱਕ ਜ਼ਿਆਦਾ ਮਨੁੱਖ-ਮਿੱਤਰ ਰੂਪ ਵਿੱਚ ਨਿਰਦੇਸ਼ ਲਿਖ ਸਕਦੇ ਹਨ—ਅਤੇ ਸੌਫਟਵੇਅਰ ਤਰਜਮਾ ਕਰਨ ਦਾ ਕੰਮ ਸੰਭਾਲਦਾ ਹੈ। ਅਮਲੀ ਰੂਪ ਵਿੱਚ ਇਹ ਇਕ ਐਸਾ ਪ੍ਰੋਗ੍ਰਾਮ ਹੈ ਜੋ ਪ੍ਰੋਗ੍ਰਾਮ ਬਨਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਕੰਪਾਇਲ ਕਰਨਾ ਉਹ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜਿਸ ਵਿੱਚ ਮਨੁੱਖ ਪੜ੍ਹ ਸਕਣ ਅਤੇ ਲਿਖ ਸਕਣ ਵਾਲੇ ਕੋਡ ਨੂੰ ਉਸ ਨੀਵੇਂ-ਪੱਧਰ ਦੇ ਨਿਰਦੇਸ਼ਾਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ ਜੋ ਕੰਪਿਊਟਰ ਚਲਾ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸੋਚ ਸਕਦੇ ਹੋ: ਇੱਕ ਰੈਸੀਪੀ ਨੂੰ ਇਕ ਰਸੋਈ ਰੋਬੋਟ ਲਈ ਬਿਲਕੁਲ ਸਹੀ ਬਟਨ-ਦਬਾਅ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ।
ਉੱਚ-ਸਤਹ 'ਤੇ, ਇੱਕ ਕੰਪਾਇਲਰ ਆਮ ਤੌਰ 'ਤੇ:
ਜਾਦੂ ਇਹ ਨਹੀਂ ਕਿ ਕੰਪਿਊਟਰ ਹੁਣ “ਅੰਗਰੇਜ਼ੀ” ਸਮਝਦਾ ਹੈ। ਜਾਦੂ ਇਹ ਹੈ ਕਿ ਕੰਪਾਇਲਰ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਇਕਸਾਰਤਾ ਨਾਲ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਮਿਹਨਤੀ ਅਤੇ ਗਲਤੀ-ਪ੍ਰਵਣ ਤੌਰ 'ਤੇ ਤਬਦੀਲ ਕਰ ਦਿੰਦਾ ਹੈ।
ਲੋਕ ਅਕਸਰ ਕੰਪਾਇਲਰਾਂ ਅਤੇ ਇੰਟਰਪ੍ਰੀਟਰਾਂ ਨੂੰ ਗਲਤ ਸਮਝਦੇ ਹਨ ਕਿਉਂਕਿ ਦੋਹਾਂ ਮਨੁੱਖ-ਮਿੱਤਰ ਕੋਡ ਨੂੰ ਚਲਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ।
ਸਰਲ ਤਰੀਕੇ ਨਾਲ ਵੱਖ ਕਰਨਾ:
ਦੋਹਾਂ ਬਾਹਰੋਂ ਮਿਲਦੇ-ਜੁਲਦੇ ਲੱਗ ਸਕਦੇ ਹਨ ("ਮੈਂ ਕੋਡ ਲਿਖਦਾ ਹਾਂ ਅਤੇ ਇਹ ਚਲਦਾ ਹੈ"), ਪਰ ਵਰਕਫਲੋਅ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਟਰੇਡ-ਅਫ਼ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। Hopper ਦੀ ਕਹਾਣੀ ਲਈ ਮੁਖ ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਕੰਪਾਇਲਸ਼ਨ ਨੇ "ਕੋਡ ਲਿਖਣਾ" ਨੂੰ ਹਾਰਡਵੇਅਰ ਵਿਸ਼ੇਸ਼ ਵੇਰਵੇ ਬਾਰੇ ਘੱਟ ਅਤੇ ਇਰਾਦਾ ਵਿਅਕਤ ਕਰਨ ਬਾਰੇ ਜ਼ਿਆਦਾ ਬਣਾਇਆ।
Grace Hopper ਦਾ A-0 ਸਿਸਟਮ (ਅਕਸਰ 1952 ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ) ਸਭ ਤੋਂ ਪਹਿਲੇ "ਕੰਪਾਇਲਰ-ਜਿਹੇ" ਔਜ਼ਾਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ—ਹਾਲਾਂਕਿ ਇਹ ਆਧੁਨਿਕ ਕੰਪਾਇਲਰਾਂ ਵਾਂਗ ਪੂਰੀ ਮਨੁੱਖ-ਪੜ੍ਹਨਯੋਗ ਭਾਸ਼ਾ ਨੂੰ ਮਸ਼ੀਨ ਕੋਡ ਵਿੱਚ ਤਬਦੀਲ ਨਹੀਂ ਕਰਦਾ ਸੀ।
ਹੱਥ 'ਤੇ ਹਰੇਕ ਨਿਰਦੇਸ਼ ਲਿਖਣ ਦੀ ਬਜਾਏ, ਇੱਕ ਪ੍ਰੋਗ੍ਰਾਮਰ ਉਹਨਾਂ ਰੂਟੀਨਾਂ ਨੂੰ ਇੱਕ ਆਈਡੀ ਨਾਲ ਸੰਦਰਭਿਤ ਕਰ ਸਕਦਾ ਸੀ ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਬਣੀਆਂ ਹੋਵਨ। A-0 ਫਿਰ:
ਇਸ ਤਰ੍ਹਾਂ ਪ੍ਰੋਗ੍ਰਾਮਰ ਕੁਝ ਅੰਗਰੇਜ਼ੀ-ਨੁਮਾ ਕੋਡ ਲਿਖਕੇ ਮਸ਼ੀਨ ਨੂੰ ਸਮਝਵਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ; ਉਹ ਸਿਰਫ਼ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ, ਗਲਤੀ-ਪ੍ਰਵਣ ਐਸੈਂਬਲੀ ਕੰਮ ਨੂੰ ਆਟੋਮੇਟ ਕਰਵਾਉ ਰਿਹਾ ਸੀ: ਜਾਣੇ-ਪਹਚਾਣੇ ਬਿਲਡਿੰਗ ਬਲਾਕ ਚੁਣਨਾ ਅਤੇ ਜੋੜਨਾ।
A-0 ਇੱਕ ਤਾਕਤਵਰ ਵਿਚਾਰ 'ਤੇ ਨਿਰਭਰ ਸੀ: ਸਬਰੁਟੀਨ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕਿਸੇ ਕੰਮ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਇੱਕ ਟੈਸਟ ਕੀਤਾ ਹੋਇਆ ਰੂਟੀਨ ਹੈ—ਇਨਪੁੱਟ/ਆਉਟਪੁੱਟ, ਗਣਿਤੀ ਕਾਰਵਾਈ, ਜਾਂ ਡਾਟਾ ਮੁਵਮੈਂਟ—ਤਾਂ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਉਸਨੂੰ ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖਣਾ ਚਾਹੁੰਦੇ।
ਇਸਨੇ ਦੋ ਵੱਡੇ ਤਰੀਕਿਆਂ ਨਾਲ ਰੋਜ਼ਾਨਾ ਕੰਮ ਬਦਲ ਦਿੱਤਾ:
A-0 ਦਾ ਡੂੰਘਾ ਪ੍ਰਭਾਵ ਸਿਰਫ ਤਕਨੀਕੀ ਨਹੀਂ ਸੀ—ਇਹ ਸੱਭਿਆਚਾਰਕ ਵੀ ਸੀ। ਇਸਨੇ ਸੁਝਾਇਆ ਕਿ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਉਸ ਗੱਲ ਬਾਰੇ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਉਸਦਾ ਵਰਣਨ ਕਰਨ ਬਾਰੇ—ਭਰੋਸੇਯੋਗ ਹਿੱਸਿਆਂ ਤੋਂ ਇਕਠਾ ਕਰਵਾਉਣਾ ਅਤੇ টੂਲ ਨੂੰ ਮਕੈਨਿਕਲ ਕੰਮ ਕਰਨ ਦੇਣਾ।
ਉਹ ਰਵੱਈਆ—ਲਾਇਬ੍ਰੇਰੀਆਂ ਰੀਯੂਜ਼ ਕਰੋ, ਰੂਟੀਨਾਂ ਸਟੈਂਡਰਡ ਕਰੋ, ਅਤੇ ਤਰਜਮਾ ਆਟੋਮੇਟ ਕਰੋ—ਕੰਪਾਇਲਰਾਂ, ਮਿਆਰੀ ਭਾਸ਼ਾਵਾਂ, ਅਤੇ ਆਧੁਨਿਕ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ ਅਭਿਆਸਾਂ ਲਈ ਨੀਂਹ ਬਣ ਗਿਆ।
ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਗ੍ਰਾਮਰਾਂ ਨੇ ਨਾ ਸਿਰਫ ਮਸ਼ੀਨਾਂ ਨਾਲ ਲੜਾਈ ਕੀਤੀ—ਉਹ ਇੱਕ-ਦੂਜੇ ਦੀ ਸੋਚ ਨਾਲ ਵੀ ਲੜਦੇ ਸਨ ਕਿ "ਅਸਲ" ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਕੀ ਹੈ। ਬਹੁਤ੍ਹਾਂ ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਗੰਭੀਰ ਕੰਮ ਉਸੇ ਇਨਸਟਰਕਸ਼ਨ ਨੂੰ ਨਜ਼ਦੀਕੀ ਰੂਪ ਵਿੱਚ ਲਿਖਣਾ ਸੀ ਜੋ ਹਾਰਡਵੇਅਰ ਵਰਗਾ ਦਿਖਾਈ ਦੇਣ; ਜੋ ਵੀ plain-language ਵਰਗਾ ਦਿਖਦਾ ਉਹ ਸ਼ੱਕ ਦਾ ਵਿਸ਼ਾ ਸੀ।
Grace Hopper ਦਾ ਦਲੀਲ ਸੀ ਕਿ ਕੰਪਿਊਟਰ ਲੋਕਾਂ ਦੀ ਸੇਵਾ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਮਨੁੱਖ ਦੀ ਸੇਵਾ ਨਹੀਂ। ਪੜ੍ਹਨਯੋਗ ਨੋਟੇਸ਼ਨ—ਜੋ ਕਾਰੋਬਾਰੀ ਟਰਮਾਂ ਦੇ ਨੇੜੇ ਹੁੰਦੀ—ਦਾ ਉਸ ਦਾ ਧੱਕਾ ਝੱਲਮਲਾਅਲਿਆ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਮੂਲ ਵਿਸ਼ਵਾਸ ਨੂੰ ਚੁਣੌਤੀ ਦਿੰਦਾ ਸੀ: ਕਿ ਦੱਖਲਦਾਰੀ ਲਈ ਮਨੁੱਖਾਂ ਨੂੰ ਮਸ਼ੀਨ-ਆਕਾਰ ਦੇ ਕਦਮ-ਚਿੰਤਨ ਕਰਨੇ ਪੈਂਦੇ।
ਸੰਦੇਹਵਾਦੀਆਂ ਨੂੰ ਡਰ ਸੀ ਕਿ ਅੰਗਰੇਜ਼ੀ-ਨੁਮਾ ਹੁਕਮ ਅਸਪਸ਼ਟ ਹੋ ਸਕਦੇ ਹਨ, ਮਹੱਤਵਪੂਰਨ ਵੇਰਵੇ ਛੁਪਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਲਾਪਰਵਾਹ ਸੋਚ ਨੂੰ ਉਤਪੰਨ ਕਰ ਸਕਦੇ ਹਨ। Hopper ਦਾ ਵਿਰੋਧੀ ਤਰਕ ਪ੍ਰਯੋਗਿਕ ਸੀ: ਜਿਆਦਾ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਸਮਾਂ ਟਾਈਪ ਕਰਨ 'ਤੇ ਨਹੀਂ ਲੱਗਦਾ—ਉਹ ਪੜ੍ਹਨ ਉਤੇ ਲੱਗਦਾ ਹੈ।
ਪੜ੍ਹਨਯੋਗ ਕੋਡ ਇਸ ਬਾਰੇ ਨਹੀਂ ਕਿ ਪ੍ਰੋਗ੍ਰਾਮ "ਸੌਖੇ" ਹਨ; ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਉਹ ਜ਼ਿੰਦਾ ਰਹਿ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਕੋਡ ਇਰਾਦਾ ਸੰਚਾਰ ਕਰਦਾ ਹੈ, ਟੀਮਾਂ ਬਦਲਾਅ ਤੇਜ਼ੀ ਨਾਲ ਸਮੀਖਿਆ ਕਰ ਸਕਦੀਆਂ, ਨਵੀਆਂ ਲੋਕਾਂ ਨੂੰ ਘੱਟ ਗਲਤੀਆਂ ਨਾਲ onboard ਕੀਤਾ ਜਾ ਸਕਦਾ, ਅਤੇ ਮੁੱਦਿਆਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਡਾਇਗਨੋਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਕਿ ਹਰ ਫੈਸਲੇ ਦੀ ਪੁਰਾਣੀ ਰੀਅਜ਼ਨਿੰਗ ਨੂੰ ਰਿਵਰਸ-ਇੰਜੀਨੀਅਰ ਕਰਨ ਦੀ ਲੋੜ ਨੋਹੁੰਦੀ।
ਇਹ ਹੋਰ ਵੀ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਸਾਫਟਵੇਅਰ ਸਾਲਾਂ ਤੱਕ ਜੀਵਿਤ ਰਹਿੰਦਾ ਹੈ। ਕੋਡ ਦਾ ਮਨੁੱਖ-ਮਿੱਤਰ ਬਨਾਉਣ, ਨਾਮਕਰਨ ਅਤੇ ਸੰਗਠਨ ਬਦਲਾਅ ਦੀ ਲਾਗਤ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ—ਅਕਸਰ ਉਹੀ ਲਾਗਤ ਸਭ ਤੋਂ ਵੱਡੀ ਹੁੰਦੀ ਹੈ।
Hopper ਦੀ ਪਹੁੰਚ ਦੀਆਂ ਹੱਦਾਂ ਸਨ। ਸ਼ੁਰੂਆਤੀ ਕੰਪਾਇਲਰ ਤੇ ਟੂਲਿੰਗ ਅਪਰਿਪੱਕਵ ਸੀ, ਅਤੇ ਉੱਚ-ਪੱਧਰੀ ਕੋਡ ਹੱਥ ਨਾਲ-ਟਿਊਨ ਕੀਤੇ ਐਸੈਂਬਲੀ ਦੇ ਮੁਕਾਬਲੇ ਧੀਮਾ ਜਾਂ ਵੱਡਾ ਹੋ ਸਕਦਾ ਸੀ। ਡੀਬੱਗਿੰਗ ਵੀ ਅਪਰੋਖੀ ਲਗ ਸਕਦੀ ਸੀ: ਤ੍ਰੁੱਟੀਆਂ ਅਕਸਰ ਕੰਪਾਇਲਡ ਆਉਟਪੁੱਟ ਵਿੱਚ ਦਿਸਦੀਆਂ ਸਨ ਬਜਾਏ ਸਰੋਤ ਟੈਕਸਟ ਵਿੱਚ।
ਫਿਰ ਵੀ, ਲੰਬੇ ਸਮੇਂ ਦਾ ਨਤੀਜਾ ਸਾਫ਼ ਸੀ: ਪੜ੍ਹਨਯੋਗ ਸਰੋਤ ਕੋਡ ਨੇ ਵੱਡੇ ਸਿਸਟਮ ਬਣਾਉਣਾ ਸੰਭਵ ਕੀਤਾ ਜਿਸ 'ਤੇ ਵੱਧ ਲੋਕ ਕੰਮ ਕਰ ਸਕਦੇ ਸਨ—ਅਤੇ ਉਹ ਸਿਸਟਮ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਤੋਂ ਬਦਲਕੇ ਵੀ ਕੰਮ ਕਰਦੇ ਰਹੇ।
COBOL (Common Business-Oriented Language) ਇੱਕ ਸਧਾਰਨ ਲਕੜੀ ਲਈ ਬਣਾਈ ਗਈ ਸੀ: ਕਾਰੋਬਾਰੀ ਲੋਕਾਂ ਲਈ ਪ੍ਰੋਗ੍ਰਾਮ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਣ, ਨਾ ਕਿ ਕੇਵਲ ਉਹਨਾਂ ਲਈ ਜੋ ਮਸ਼ੀਨਾਂ ਨੂੰ ਵਾਇਰ ਕਰਦੇ ਸਨ। Grace Hopper ਨੇ ਇਸ ਵਿਚਾਰ ਨੂੰ ਜ਼ੋਰ ਨਾਲ ਅੱਗੇ ਧੱਕਿਆ—ਜੇ ਕੋਡ ਸਾਲਾਂ ਤੱਕ ਜੀਉਣਾ ਸੀ, ਟੀਮਾਂ ਵਿਚ ਲਿਫਟ ਹੋਣਾ ਸੀ, ਅਤੇ ਸਟਾਫ਼ ਬਦਲਣਾ ਸੀ, ਤਾਂ ਉਹ ਸਮਝਣਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ।
COBOL ਕਾਰੋਬਾਰੀ ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ (ਪੇਰੋਲ, ਇਨਵੈਂਟਰੀ, ਬਿਲਿੰਗ) ਲਈ ਬਣਾਈ ਗਈ ਸੀ, ਜਿੱਥੇ ਡਾਟਾ ਦੀ "ਢਾਂਚਾ" ਹੀ ਗਣਿਤ ਨਾਲ ਬਰਾਬਰ ਮਹੱਤਵ ਰੱਖਦੀ ਹੈ। ਇਸੀ ਲਈ COBOL ਰਿਕਾਰਡ, ਫੀਲਡ ਅਤੇ ਇਹ ਦਿੱਸਾਉਣਾ ਉੱਤੇ ਜ਼ਿਆਦਾ ਜੋਰ ਦਿੰਦੀ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮ ਕੀ ਕਰ ਰਿਹਾ ਹੈ।
ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਉਸਦੀ ਮਹੱਤਾ਼ਵਕਾਂक्षा ਸਪਸ਼ਟਤਾ ਸੀ। COBOL ਨੇ ਅੰਗਰੇਜ਼ੀ-ਨੁਮਾ ਸੰਰਚਨਾ ਨੂੰ ਅਪਣਾਇਆ ਤਾਂ ਜੋ ਕੋਈ ਵੀ ਜਿਸਨੇ ਪ੍ਰੋਗਰਾਮ ਉਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀ ਉਹ ਇरਾਦਾ ਫੌਰਾਂ ਸਮਝ ਸਕੇ। ਇਹ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ "ਸੌਖਾ" ਬਣਾਉਣ ਲਈ ਨਹੀਂ ਸੀ—ਇਹ ਲੇਜੀਬਲ ਤੇ ਰੱਖ-ਰਖਾਅਯੋਗ ਬਣਾਉਣ ਲਈ ਸੀ ਜਿੱਥੇ ਕਾਰੋਬਾਰੀ ਸਿਸਟਮਾਂ ਵਿੱਚ ਗਲਤੀਆਂ ਦੀ ਕੀਮਤ ਵੱਡੀ ਹੋ ਸਕਦੀ ਹੈ।
COBOL ਦੀ ਅਸਲੀ ਅਗਿਆਨਤਾ ਸਿਰਫ਼ ਉਸਦੀ ਸਕੱਸਣੀ ਨਹੀਂ ਸੀ—ਇਹ ਮਿਆਰੀਕਰਨ ਵੱਲ ਵਧਣ ਸੀ।
ਇਕ निर्माता ਜਾਂ ਕੰਪਨੀ ਦੀ ਪ੍ਰਾਈਵੇਟ ਭਾਸ਼ਾ ਦੀ ਬਜਾਏ, COBOL ਕਮੇਟੀਆਂ ਅਤੇ ਰਸਮੀ ਵਿਸ਼ੇਸ਼ੀकरणਾਂ ਦੁਆਰਾ ਗਠਿਤ ਹੋਇਆ। ਇਹ ਪ੍ਰਕਿਰਿਆ ਧੀਮੀ ਤੇ ਰਾਜਨੀਤਿਕ ਹੋ ਸਕਦੀ ਸੀ, ਪਰ ਇਸ ਨਾਲ ਇੱਕ ਸਾਂਝਾ ਟੀਚਾ ਬਣਿਆ ਜਿਸਨੂੰ ਕਈ ਵੇਂਡਰ ਅਪਨਾਉਂਦੇ।
ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਸਦਾ ਮਤਲਬ ਸੀ ਕਿ ਸੰਸਥਾਵਾਂ COBOL ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨ 'ਤੇ ਜ਼ਿਆਦਾ ਭਰੋਸਾ ਕਰ ਸਕਦੀਆਂ: ਟਰੇਨਿੰਗ ਮਟੀਰੀਅਲ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਲਾਗੂ ਰਹਿੰਦੇ, ਭਰਤੀ ਆਸਾਨ ਹੋ ਗਈ, ਅਤੇ ਕੋਡ ਦਾ ਹਾਰਡਵੇਅਰ ਬਦਲਣ 'ਤੇ ਜੀਵੰਤ ਰਹਿਣ ਦਾ ਮੌਕਾ ਵਧ ਗਿਆ।
ਮਿਆਰੀਕਰਨ ਨੇ ਉਮੀਦਾਂ ਨੂੰ ਵੀ ਬਦਲ ਦਿੱਤਾ। ਭਾਸ਼ਾਵਾਂ ਹੁਣ ਸਿਰਫ਼ ਉਹ ਟੂਲ ਨਹੀਂ ਰਹੀਆਂ ਜੋ ਤੁਹਾਨੂੰ "ਮਸ਼ੀਨ ਨਾਲ ਆਉਂਦੇ"—ਉਹ ਲੋਕਾਂ ਲਈ ਲਿਖਣ ਦੇ ਨਿਯਮ ਬਣ ਗਈਆਂ ਅਤੇ ਕੰਪਾਇਲਰਾਂ ਲਈ ਤਰਜਮਾ ਦੇ ਨਿਯਮ।
COBOL ਦੀਆਂ ਮਜ਼ਬੂਤੀਆਂ ਸਮਝਾਉਣ ਵਿੱਚ ਆਸਾਨ ਹਨ: ਇਹ ਵਿਆਖਿਆਪੂਰਨ ਹੈ, ਇਸਦੇ ਡਾਟਾ ਸਟ੍ਰੱਕਚਰ ਕੇਂਦਰੀ ਹਨ, ਅਤੇ ਇਹ ਲੰਮੀ ਅਵਧੀ ਵਾਲੇ ਕਾਰੋਬਾਰੀ ਸਿਸਟਮਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਉਹ ਲੰਬੀ ਉਮਰ ਇਕ ਹਾਦਸਾ ਨਹੀਂ—ਇਹ ਉਹ ਡਿਜ਼ਾਇਨ ਚੋਣਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ ਸਪਸ਼ਟਤਾ ਅਤੇ ਸਥਿਰਤਾ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ।
ਆਲੋਚਨਾ ਵੀ ਸੱਚੀ ਹੈ। COBOL verbose ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਇਸਦੀ ਪੜ੍ਹਨਯੋਗਤਾ ਆਧੁਨਿਕ ਭਾਸ਼ਾਵਾਂ ਦੇ ਮੁਕਾਬਲੇ ਕਠੋਰ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ। ਪਰ verbose ਹੋਣਾ ਅਕਸਰ ਮਕਸਦ ਸੀ: ਕੋਡ ਆਪਣਾ ਕੰਮ ਖੁੱਲ ਕੇ ਦਿਖਾਉਂਦਾ ਹੈ, ਜੋ ਆਡਿਟਿੰਗ, ਰੱਖ-ਰਖਾਅ, ਅਤੇ ਹੈਂਡ-ਓਫ਼ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
COBOL ਇੱਕ ਮੋੜ ਬਿੰਦੂ ਨਿਸ਼ਾਨਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਨਿੱਜੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੇ ਛੋਟੇ ਰਸਤੇ ਤੋਂ ਬਾਹਰ ਆ ਕੇ ਸਟੈਂਡਰਡ-ਚਲਿਤ ਇਨਫ੍ਰਾਸਟਰੱਕਚਰ ਵਾਂਗ ਬਦਲੀਆਂ—ਸਾਂਝੀਆਂ, ਸਿੱਖਣਯੋਗ ਅਤੇ ਲੰਮੇ ਸਮੇਂ ਲਈ ਬਣੀਆਂ।
ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਗ੍ਰਾਮ ਅਕਸਰ ਇੱਕ ਖ਼ਾਸ ਮਸ਼ੀਨ ਨਾਲ ਵਿਆਹੇ ਹੋਏ ਹੁੰਦੇ। ਜੇ ਤੁਸੀਂ ਕੰਪਿਊਟਰ ਬਦਲਦੇ, ਤੁਸੀਂ ਫਾਇਲਾਂ ਹੀ ਨਹੀਂ ਹਿਲਾਉਂਦੇ—ਕਈ ਵਾਰੀ ਤੁਹਾਨੂੰ ਪ੍ਰੋਗ੍ਰਾਮ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪੈਂਦਾ ਸੀ, ਕਿਉਂਕਿ ਨਿਰਦੇਸ਼ ਅਤੇ ਰਿਵਾਜ਼ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ। ਇਸਨੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਨਾਜ਼ੁਕ ਅਤੇ ਮਹਿੰਗਾ ਬਣਾ ਦitta, ਅਤੇ ਨਵੇਂ ਹਾਰਡਵੇਅਰ ਦੇ ਗ੍ਰਹਿਣ ਨੂੰ ਧੀਮਾ ਕਰ ਦਿੱਤਾ।
ਕੰਪਾਇਲਰਾਂ ਨੇ ਇਕ ਤਾਕਤਵਰ ਵੰਡ ਪੇਸ਼ ਕੀਤੀ: ਤੁਸੀਂ ਉੱਚ-ਪੱਧਰੀ ਭਾਸ਼ਾ ਵਿੱਚ ਆਪਣਾ ਪ੍ਰੋਗਰਾਮ ਲਿਖਦੇ ਹੋ, ਅਤੇ ਕੰਪਾਇਲਰ ਉਸਨੂੰ ਕਿਸੇ ਖ਼ਾਸ ਕੰਪਿਊਟਰ ਦੀ ਦੇਸੀ ਨਿਰਦੇਸ਼ਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ ਹੈ।
ਇਹੀ ਪੋਰਟੇਬਿਲਟੀ ਦਾ ਮਤਲਬ ਹੈ: ਉਹੀ ਸਰੋਤ ਕੋਡ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ ਲਈ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ—ਜੇਕਰ ਹਰ ਟਾਰਗੇਟ ਲਈ ਇਕ ਉਚਿਤ ਕੰਪਾਇਲਰ ਹੋਵੇ (ਅਤੇ ਤੁਸੀਂ ਮਸ਼ੀਨ-ਖਾਸ ਅਨੁਮਾਨਾਂ ਤੋਂ ਬਚੋ)। ਇਸ ਤਰ੍ਹਾਂ ਸੰਸਥਾਵਾਂ ਆਪਣੇ ਪੇਰੋਲ ਸਿਸਟਮ ਨੂੰ ਹਰ ਨਵੇਂ ਕੰਪਿਊਟਰ ਲਈ ਮੁੜ-ਲਿਖਣ ਦੀ ਬਜਾਏ ਸਿਰਫ਼ ਰੀਕੰਪਾਇਲ ਕਰ ਸਕਦੀਆਂ।
ਇਹ ਬਦਲਾਅ ਹਾਰਡਵੇਅਰ ਸੁਧਾਰ ਦੀ ਆਰਥਿਕੀ ਨੂੰ ਬਦਲ ਦਿੱਤਾ। ਨਿਰਮਾਤਾ ਤੇਜ਼ ਜਾਂ ਜ਼ਿਆਦਾ ਸਮਰਥ ਮਸ਼ੀਨਾਂ ਜਾਰੀ ਕਰ ਸਕਦੇ ਸਨ, ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਸਾਲਾਂ ਦੀ ਸਾਫਟਵੇਅਰ ਨਿਵੇਸ਼ ਨੂੰ ਫੇਕਣ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹੀ।
ਕੰਪਾਇਲਰ ਇੱਕ ਕਿਸਮ ਦਾ "ਅਡੈਪਟਰ ਲੇਅਰ" ਬਣ ਗਏ: ਤੁਸੀਂ ਸਥਿਰ ਕਾਰੋਬਾਰੀ ਲੋੜਾਂ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੇ ਤਕਨਾਲੋਜੀ ਦਰਮਿਆਨ ਇਕ ਡਿਲ ਨੇੜੀ ਬਣਾਉਂਦੇ ਹੋ। ਕੁਝ ਬਦਲਾਅ ਫਿਰ ਵੀ ਅਪਡੇਟ ਮੰਗਦੇ—ਖ਼ਾਸ ਕਰ ਕੇ ਇਨਪੁੱਟ/ਆਉਟਪੁੱਟ ਦੇ ਆਲੇ-ਦੁਆਲੇ—ਪਰ ਮੂਲ ਵਿਚਾਰ ਹੁਣ ਇੱਕ ਨਿਰਦੇਸ਼ ਸੈੱਟ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਿਹਾ।
ਜਦੋਂ ਭਾਸ਼ਾ ਮਿਆਰਬੱਧ ਹੁੰਦੀ ਹੈ ਤਾਂ ਪੋਰਟੇਬਿਲਟੀ ਹੋਰ ਜ਼ਿਆਦਾ ਹੋ ਜਾਦੀ ਹੈ। ਮਿਆਰੀ ਨਿਯਮਾਂ ਦਾ ਅਰਥ ਇਹ ਹੈ ਕਿ ਇਕ ਕੰਪਾਇਲਰ ਲਈ ਲਿਖਿਆ ਕੋਡ ਦੂਜੇ ਕੰਪਾਇਲਰ 'ਤੇ ਵੀ ਸੰਭਵ ਤੌਰ 'ਤੇ ਕੰਪਾਇਲ ਹੋ ਜਾਏਗਾ, ਜਿਸ ਨਾਲ ਵੇਂਡਰ-ਲੌਕ-ਇਨ ਘਟਦਾ ਅਤੇ ਕੋਡ ਸਾਂਝਾ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ।
ਇਹ ਵਿਰਾਸਤ ਅੱਜ ਹਰ ਥਾਂ ਮਿਲਦੀ ਹੈ:
Grace Hopper ਦਾ ਮਨੁੱਖ-ਮਿੱਤਰ, ਵਿਆਪਕ ਉਪਯੋਗਯੋਗ ਕੋਡ ਵੱਲ ਧੱਕਾ ਸਿਰਫ਼ ਸੁਵਿਧਾ ਬਾਰੇ ਨਹੀਂ ਸੀ। ਇਸਨੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਇਕ ਪੋਰਟੇਬਲ ਸੰਪਤੀ ਬਣਾਇਆ ਜੋ ਹਾਰਡਵੇਅਰ ਜਨਰੇਸ਼ਨਾਂ ਨੂੰ ਪਾਰ ਕਰ ਸਕਦੀ ਸੀ।
ਕੰਪਾਇਲਰਾਂ ਨੇ ਸਿਰਫ਼ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਤੇਜ਼ ਨਹੀਂ ਕੀਤਾ—ਉਹਨਾਂ ਨੇ ਇਹ ਵੀ ਤੈਅ ਕੀਤਾ ਕਿ ਸਾਫਟਵੇਅਰ ਟੀਮਾਂ ਕਿਵੇਂ ਆਯੋਜਿਤ ਹੋਣ। ਜਦੋਂ ਕੋਡ ਉੱਚ-ਪੱਧਰੀ ਸ਼ਰਤਾਂ ਵਿੱਚ ਲਿਖਿਆ ਜਾ ਸਕਦਾ (ਕਾਰੋਬਾਰੀ ਨਿਯਮਾਂ ਦੇ ਨੇੜੇ), ਵੱਖ-ਵੱਖ ਲੋਕ ਅਸਾਨੀ ਨਾਲ ਯੋਗਦਾਨ ਪਾ ਸਕਦੇ ਸਨ।
ਸਰਲ ਪ੍ਰੋਜੇਕਟ ਪਹਿਲਾਂ ਐਨਾਲਿਸਟ (ਕੰਮ ਕੀ ਵਰਣਨਾ ਕਰਦੇ), ਪ੍ਰੋਗ੍ਰਾਮਰ (ਉਹਨਾਂ ਨੂੰ ਕੋਡ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦੇ), ਅਤੇ ਓਪਰੇਟਰ (ਜੋ ਨੌਕਰੀਆਂ ਚਲਾਂਦੇ ਅਤੇ ਮਸ਼ੀਨ ਟਾਈਮ ਮੈਨੇਜ ਕਰਦੇ) ਵਾਂਗ ਵੰਡ ਹੋਏ ਹੁੰਦੇ ਸਨ। ਕੰਪਾਇਲਰਾਂ ਨਾਲ, ਐਨਾਲਿਸਟ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਵਰਕਫ਼ਲੋਅ ਨੂੰ ਜ਼ਿਆਦਾ ਬਣਤਰਬੱਧ ਢੰਗ ਨਾਲ ਵਰਣਨ ਕਰ ਸਕਦੇ ਸਨ, ਜਦ ਕਿ ਪ੍ਰੋਗ੍ਰਾਮਰਾਂ ਨੂੰ ਹੱਥ-ਅਸੈਂਬਲ ਕਰਨ 'ਤੇ ਘੱਟ ਸਮਾਂ ਲੱਗਦਾ ਅਤੇ ਉਹ ਤਰਕ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ 'ਤੇ ਜ਼ਿਆਦਾ ਧਿਆਨ ਦੇ ਸਕਦੇ।
ਨਤੀਜਾ ਸੀ ਇੱਕ ਸਾਫ਼ ਹੈਂਡ-ਆਫ਼: ਜ਼ਰੂਰਤਾਂ → ਪੜ੍ਹਨਯੋਗ ਸਰੋਤ ਕੋਡ → ਕੰਪਾਇਲਡ ਪ੍ਰੋਗਰਾਮ। ਇਸ ਨੇ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਕੁਝ ਵਿਸ਼ੇਸ਼ ਲੋਕਾਂ 'ਤੇ ਘੱਟ ਨਿਰਭਰ ਬਣਾਇਆ ਜੋ ਇੱਕ ਮਸ਼ੀਨ ਦੀਆਂ ਤਨਖ਼ਾਹੀਆਂ ਜਾਣਦੇ ਸਨ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਸਾਫਟਵੇਅਰ ਹਫ਼ਤਿਆਂ ਦੀ ਬਜਾਏ ਸਾਲਾਂ ਲਈ ਜੀਉਣ ਲੱਗਿਆ, ਰੱਖ-ਰਖਾਅ ਮੁੱਖ ਲਾਗਤ ਬਣ ਗਿਆ। ਫਿਕਸ, ਅਪਡੇਟ, ਅਤੇ ਛੋਟੇ ਨੀਤੀ-ਬਦਲਾਅ ਜੁੜੇ ਰਹਿੰਦੇ। ਪੜ੍ਹਨਯੋਗ ਸਰੋਤ ਕੋਡ ਨੇ ਇਹ ਸਹਾਇਕ ਬਣਾਇਆ: ਕੋਈ ਨਵਾਂ ਵਿਅਕਤੀ ਸੈਂਕੜੇ ਨੀਵੇਂ-ਪੱਧਰ ਕਦਮਾਂ ਨੂੰ ਡੀਕੋਡ ਕੀਤੇ ਬਿਨਾਂ ਇਰਾਦਾ ਸਮਝ ਸਕਦਾ।
ਕੰਪਾਇਲਰ ਇਸ ਨੂੰ ਸਹਾਰਾ ਦਿੱਤਾ ਕਿ ਉਹ ਨਾਂ-ਨਾਮ, ਮੁੜ-ਉਪਯੋਗ ਰੂਟੀਨ ਅਤੇ ਸਪਸ਼ਟ ਕੰਟਰੋਲ ਫਲੋ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਨ। ਜਦੋਂ ਕੋਡ ਆਪਣਾ ਭਾਵ ਵਿਆਖਿਆ ਕਰਦਾ, ਰੱਖ-ਰਖਾਅ ਖੋਜ-ਪੂਰਵਕ ਨਾ ਹੋ ਕੇ ਸੰਚਾਲਨਯੋਗ ਬਣ ਜਾਂਦਾ।
ਸਪਸ਼ਟ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਨੇ ਟੈਸਟਿੰਗ ਅਤੇ ਡੀਬੱਗਿੰਗ ਨੂੰ ਵੀ ਸੁਧਾਰਿਆ। ਇੱਕ ਗਲਤ ਮਸ਼ੀਨ-ਨਿਰਦੇਸ਼ ਨੂੰ ਲੱਭਣ ਦੀ ਥਾਂ, ਟੀਮਾਂ ਇਕ ਫੀਚਰ ਬਾਰੇ ਸੋਚ ਸਕਦੀਆਂ—("ਇਹ ਗਣਨਾ ਰੀਫੰਡ ਲਈ ਗਲਤ ਹੈ")—ਅਤੇ ਮੁੱਦੇ ਨੂੰ ਇੱਕ ਮੌਡੀਊਲ ਜਾਂ ਫੰਕਸ਼ਨ ਤੱਕ ਸੀਮਤ ਕਰ ਸਕਦੀਆਂ।
ਹਾਲਾਂਕਿ ਸ਼ੁਰੂਆਤੀ ਦਿਨਾਂ ਵਿੱਚ ਕੰਪਾਇਲਰਾਂ ਤੋਂ ਮਿਲਣ ਵਾਲੀਆਂ ਗਲਤੀ ਸੁਨੇਹੀਆਂ ਕਈ ਵਾਰੀ cryptic ਹੁੰਦੀਆਂ, ਪਰ ਉਹ ਇੱਕ ਕੀਮਤੀ ਅਨੁਸ਼ਾਸਨ ਨੂੰ ਪੇਸ਼ ਕਰਦੀਆਂ: ਸਰੋਤ ਕੋਡ ਨੂੰ ਵਿਵਸਥਿਤ ਰੱਖੋ, ਬਿਹੇਵਿਅਰ ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਵੈਰੀਫਾਇ ਕਰੋ, ਅਤੇ ਜਿੱਥੇ ਮਤਲਬ ਹੈ ਉਥੇ ਬਦਲਾਅ ਕਰੋ—ਨਾ ਕਿ ਅਜਿਹੇ ਥਾਂ 'ਤੇ ਜਿੱਥੇ ਹਾਰਡਵੇਅਰ ਬਿੱਟ ਰੱਖੇ ਹੋਏ ਸਨ।
ਕੰਪਾਇਲਰ ਮਨੁੱਖ-ਮਿੱਤਰ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਮਸ਼ੀਨ-ਮਿੱਤਰ ਇਕਾਈਆਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦੇ ਹਨ। ਇਸ ਬਦਲਾਅ ਨੇ ਸੌਖਾ ਲਿਖਣਾ ਤੇਜ਼ ਕੀਤਾ ਅਤੇ ਸਾਂਝਾ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਇਆ—ਪਰ ਇਸ ਨਾਲ ਕੁਝ ਮਿਥ ਵੀ ਜਨਮ ਲਏ ਜੋ ਅਜੇ ਵੀ ਲੋਕਾਂ ਦੀਆਂ ਗੱਲਾਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ।
ਇੱਕ ਕੰਪਾਇਲਰ ਜ਼ਿਆਦਾਤਰ ਇਹ ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਕੋਡ ਭਾਸ਼ਾ ਦੇ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸਨੂੰ ਤਬਦੀਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਲੋਜਿਕ ਗਲਤ ਹੈ, ਤਾਂ ਕੰਪਾਇਲਰ ਅਕਸਰ ਖ਼ੁਸ਼ੀ-ਖ਼ੁਸ਼ੀ ਇੱਕ ਵੈਧ ਪ੍ਰੋਗ੍ਰਾਮ ਪੈਦਾ ਕਰੇਗਾ ਜੋ ਗਲਤ ਨਤੀਜਾ ਦੇਵੇਗਾ।
ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਪੇਰੋਲ ਗਣਨਾ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਕੰਪਾਇਲ ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਫਿਰ ਵੀ ਗਲਤ ਰਕਮ ਭੁਗਤਾਨ ਕਰ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਫਾਰਮੂਲਾ ਗਲਤ ਹੈ, ਕੋਈ ਐਜ-ਕੇਸ ਗੁਆਚ ਗਿਆ, ਜਾਂ ਟਾਈਮ-ਜ਼ੋਨ ਅਨੁਮਾਨ ਗਲਤ ਹਨ।
ਉੱਚ-ਪੱਧਰੀ ਭਾਸ਼ਾਵਾਂ ਕੁੱਝ ਕਿਸਮ ਦੀਆਂ ਗਲਤੀਆਂ ਘਟਾਉਂਦੀਆਂ ਹਨ—ਜਿਵੇਂ CPU ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਗਲਤ ਮਿਲਾਉਣਾ ਜਾਂ ਹੱਥ ਨਾਲ ਬੁਨਿਆਦੀ ਯਾਦ-ਪ੍ਰਬੰਧਨ—ਪਰ ਉਹ ਬੱਗ ਨੂੰ ਖ਼ਤਮ ਨਹੀਂ ਕਰਦੀਆਂ। ਤੁਸੀਂ ਫਿਰ ਵੀ:
ਪੜ੍ਹਨਯੋਗਤਾ ਵੱਡਾ ਫਾਇਦਾ ਹੈ, ਪਰ ਪੜ੍ਹਨਯੋਗਤਾ = ਸਹੀਤਾ ਨਹੀਂ।
ਕੋਡ ਬਹੁਤ ਸੋਹਣਾ ਨਾਮੀ ਅਤੇ ਸੁਥਰਾ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਅਸੁਰੱਖਿਅਤ (ਉਦਾਹਰਨ ਲਈ, ਯੂਜ਼ਰ ਇਨਪੁੱਟ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ), ਢੀਲਾ (ਚਲਾਨਾਂ ਵਿੱਚ ਬੇਹਿਸਾਬ ਡਾਟਾਬੇਸ ਕਾਲਾਂ), ਜਾਂ ਨਾਜ਼ੁਕ (ਛੁਪੇ ਨਿਰਭਰਤਾ) ਹੋ ਸਕਦਾ ਹੈ।
ਸਹੀ ਸੋਚ ਇਹ ਹੈ: ਪੜ੍ਹਨਯੋਗ ਕੋਡ ਮੁੱਦਿਆਂ ਨੂੰ ਲੱਭਣਾ ਅਤੇ ਠੀਕ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਗਾਰੰਟੀ ਨਹੀਂ ਕਿ ਕੋਈ ਮੁੱਦਾ ਨਹੀਂ ਹੋਵੇਗਾ।
ਕੰਪਾਇਲਰ ਟੂਲ ਹਨ, ਬੱਚਿਆਂ ਵਾਲੇ ਨਹੀਂ। ਭਰੋਸੇਯੋਗਤਾ ਅਜੇ ਵੀ ਲੋਕਾਂ ਦੇ ਕੰਮ ਕਰਨ ਦੇ ਢੰਗ ਤੋਂ ਆਉਂਦੀ ਹੈ:
Grace Hopper ਨੇ ਉਹ ਕੋਡ ਦੀ ਮੰਗ ਕੀਤੀ ਜੋ ਮਨੁੱਖ ਸਮਝ ਸਕਣ। ਸਭ ਤੋਂ ਚੰਗੀ ਅਗਲੀ ਕਦਮ ਉਹੀ ਹੈ: ਪੜ੍ਹਨਯੋਗਤਾ ਨੂੰ ਅਨੁਸ਼ਾਸਨਾਤਮਕ ਅਭਿਆਸਾਂ ਨਾਲ ਜੋੜੋ ਤਾਂ ਕਿ "ਸੌਖਾ" ਲਾਪਰਵਾਹੀ ਵਿੱਚ ਨਾ ਬਦਲ ਜਾਵੇ।
Hopper ਦਾ ਮੂਲ ਦਾਅ ਸਧਾਰਨ ਸੀ: ਜੇ ਅਸੀਂ ਕੰਮ ਨੂੰ ਉਹ ਰੂਪ ਦਿੰਦੇ ਹਾਂ ਜੋ ਲੋਕ ਸਮਝਦੇ ਹਨ, ਤਾਂ ਕੰਪਿਊਟਰ ਤਰਜਮਾ ਕਰਨ ਦਾ ਕੰਮ ਕਰੇ। ਇਹ ਵਿਚਾਰ ਲਗਭਗ ਹਰ ਆਧੁਨਿਕ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਅਨੁਭਵ ਵਿੱਚ ਬੁਨਿਆਦੀ ਰੂਪ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੈ—Python ਜਾਂ JavaScript ਲਿਖਣ ਤੋਂ ਲੈ ਕੇ ਉਦਯੋਗਿਕ ਕੰਪਾਇਲਰ ਟੂਲਚੇਨ ਦੇ ਨਾਲ ਐਪ ਤਿਆਰ ਕਰਨ ਤੱਕ।
ਅੱਜ, ਇੱਕ "ਕੰਪਾਇਲਰ" ਅਕਸਰ ਇੱਕ ਇਕੱਲਾ ਪ੍ਰੋਗ੍ਰਾਮ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਇੱਕ ਪਾਈਪਲਾਈਨ ਹੁੰਦੀ ਹੈ: ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਪਾਰਸ ਕਰਨਾ, ਚੈੱਕ ਕਰਨਾ, ਬਦਲਣਾ, ਅਪਟੀਮਾਈਜ਼ ਕਰਨਾ, ਅਤੇ ਕੁਝ ਰਨਯੋਗ ਨਿਕਾਸ ਤਿਆਰ ਕਰਨਾ (ਮਸ਼ੀਨ ਕੋਡ, ਬਾਇਟਕੋਡ, ਜਾਂ ਇਕ ਅਪਟੀਮਾਈਜ਼ਡ ਬੰਡਲ)। ਤੁਹਾਂ ਜੋ Go, Rust, Swift, ਜਾਂ C# ਵਿੱਚ ਲਿਖਦੇ ਹੋ, ਤੁਸੀਂ Hopper ਦੀ ਉਸੀ ਵਾਅਦੇ ਦਾ ਲਾਭ ਉਠਾ ਰਹੇ ਹੋ: ਮਨੁੱਖੀ ਮਿਹਨਤ ਘਟਾਉ, ਇਰਾਦਾ ਸਾਫ਼ ਰੱਖੋ, ਅਤੇ ਮਸ਼ੀਨ ਨੂੰ ਦੁਹਰਾਉਣ ਵਾਲਾ ਕੰਮ ਕਰਨ ਦਿਓ।
ਇਸੇ ਕਾਰਨ ਆਧੁਨਿਕ ਵਿਕਾਸ ਵਧੇਰੇ-ਉੱਚ ਪੱਧਰ ਦੇ ਇੰਟਰਫੇਸਾਂ ਵੱਲ ਵਧਦਾ ਰਹਿੰਦਾ ਹੈ ਜੋ ਅਜੇ ਵੀ ਹਕੀਕਤੀ, ਡਿਪਲੋਇਬਲ ਸਿਸਟਮ ਬਣਾ ਦਿੰਦੇ ਹਨ। ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚ, ਉਦਾਹਰਨ ਲਈ, Koder.ai, ਤੁਸੀਂ ਜੋ ਚਾਹੁੰਦੇ ਹੋ ਇੱਕ ਚੈਟ ਇੰਟਰਫੇਸ ਵਿੱਚ ਵੇਰਣ ਕਰਦੇ ਹੋ ਅਤੇ ਏਜੰਟ-ਅਧਾਰਤ ਵਰਕਫਲੋ ਇੱਕ ਐਪ (ਵੈੱਬ, ਬੈਕਐਂਡ ਜਾਂ ਮੋਬਾਈਲ) ਜਨਰੇਟ ਅਤੇ ਸੁਧਾਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦਕਿ ਨਿਰਯਾਤਯੋਗ ਸਰੋਤ ਕੋਡ ਵੀ ਤਿਆਰ ਹੁੰਦਾ ਹੈ। ਬਹੁਤ Hopper-ਵਾਂਗ ਤਰੀਕੇ ਨਾਲ, ਮਕਸਦ ਉਹੀ ਹੈ: ਝੰਝਟ ਭਰੇ ਤਰਜਮੇ ਤੋਂ ਇਰਾਦੇ ਵੱਲ ਧੱਕਾ ਦੇਣਾ, ਸਮੀਖਿਆਯੋਗ ਨਿਕਾਸ ਅਤੇ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ।
ਆਧੁਨਿਕ ਕੰਪਾਇਲਰ ਸਿਰਫ਼ ਤਰਜਮਾ ਨਹੀਂ ਕਰਦੇ—ਉਹ ਸਿਖਾਉਂਦੇ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਐਰਰ ਸੁਨੇਹਾ ਵੇਖਦੇ ਹੋ ਜੋ ਸਹੀ ਲਾਈਨ ਨੂੰ ਨਿਸ਼ਾਨਾ ਦਿੰਦਾ ਅਤੇ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ, ਉਹ ਮਨੁੱਖੀ-ਕੇਂਦਰਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਦੀ ਵਿਰਾਸਤ ਹੈ—ਮਸ਼ੀਨਾਂ ਦੀ ਰੀਤ ਨਹੀਂ।
ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਇਕ ਹੋਰ ਸ਼ਾਂਤ ਜਿੱਤ ਹੈ: ਕੰਪਾਇਲਰ ਕਿਸੇ ਕੋਡ ਨੂੰ ਤੇਜ਼ ਜਾਂ ਛੋਟਾ ਬਣਾ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਹਰ ਨਿਰਦੇਸ਼ ਨੂੰ ਹੱਥ ਨਾਲ ਟਿਊਨ ਕਰਨ ਦੇ।
ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ (ਅਕਸਰ ਕੰਪਾਇਲਰਾਂ ਵਿੱਚ ਜਾਂ ਉਨ੍ਹਾਂ ਦੇ ਨਾਲ ਜੋੜਕੇ) ਮੁੜ-ਤ੍ਰੁੱਟੀਆਂ ਜਿਵੇਂ ਟਾਈਪ ਮੇਲ ਨਹੀਂ ਹੋਣਾ, ਅਣਪਹੁੰਚ ਕੋਡ, ਸੰਭਵ ਨੱਲ ਐਰਰ—ਇਹ ਸਭ ਕੁਝ ਗਾਹਕਾਂ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਪਕੜ ਲੈਂਦੇ ਹਨ।
ਸਭ ਕੁਝ ਮਿਲ ਕੇ ਤੇਜ਼ ਵਿਕਾਸ ਚੱਕਰ ਬਣਦੇ ਹਨ: ਤੁਸੀਂ ਸਾਫ਼ ਕੋਡ ਲਿਖਦੇ ਹੋ, ਟੂਲ ਜਲਦੀ ਗਲਤੀਆਂ ਫ਼ੜਦੇ ਹਨ, ਅਤੇ ਬਿਲਡ ਵੱਖ-ਵੱਖ ਮਾਹੌਲਾਂ 'ਚ ਭਰੋਸੇਯੋਗ ਨਿਕਾਸ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਕਦੇ "ਕੰਪਾਇਲਰ" ਸ਼ਬਦ ਨਹੀਂ ਕਹਿੰਦੇ, ਤੁਸੀਂ ਉਹ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਹਾਡੀ IDE ਇਕ ਬੱਗ ਨੂੰ ਅੰਡਰਲਾਈਨ ਕਰਦੀ ਹੈ, ਆਪਣੇ CI ਬਿਲਡ ਸਹੀ ਨਿਰਦੇਸ਼ ਦੇ ਕੇ ਫੇਲ ਹੁੰਦੇ ਵੇਲੇ, ਜਾਂ ਟੂਲਚੇਨ ਅਪਡੀਟ ਤੋਂ ਬਾਅਦ ਰਿਲੀਜ਼ ਤੇਜ਼ ਚਲਦੀ ਹੈ।
ਇਹ Hopper ਦਾ ਵਿਜ਼ਨ ਹੈ ਜੋ ਰੋਜ਼ਾਨਾ ਅਭਿਆਸ ਵਿਚ ਗੂੰਜਦਾ ਹੈ।
Grace Hopper ਦਾ ਕੰਪਾਇਲਰ ਕੰਮ ਸਿਰਫ਼ ਕੰਪਿਊਟਰਾਂ ਨੂੰ ਆਸਾਨ ਨਹੀਂ ਬਣਾਇਆ—ਇਸਨੇ ਇਹ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ ਕਿ ਸਾਫਟਵੇਅਰ ਕੀ ਹੋ ਸਕਦਾ ਹੈ। ਕੰਪਾਇਲਰਾਂ ਤੋਂ ਪਹਿਲਾਂ, ਹਰ ਸੁਧਾਰ ਨੀਵੇਂ-ਪੱਧਰ ਦੀ ਮਿਹਨਤ 'ਤੇ ਨਿਰਭਰ ਸੀ। ਕੰਪਾਇਲਰਾਂ ਤੋਂ ਬਾਅਦ, ਮਨੁੱਖੀ ਸਮੇਂ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਵਿਚਾਰਾਂ, ਨਿਯਮਾਂ ਅਤੇ ਵਿਵਹਾਰ 'ਤੇ ਜਾ ਸਕਿਆ—ਨ ਕਿ ਇੱਕ-ਨਿਰਦੇਸ਼-ਇੱਕ-ਨਿਰਦੇਸ਼ ਤਰਜਮੇ 'ਤੇ।
ਦੋ ਬਦਲਾਅ ਨੇ ਫਰਕ ਬਣਾਇਆ:
ਇਹ ਫਾਇਦੇ ਇਕ ਦੂਜੇ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੇ ਸਨ। ਜਦੋਂ ਕੋਡ ਪੜ੍ਹਨਯੋਗ ਹੁੰਦਾ, ਉਸਨੂੰ ਸੁਧਾਰਨਾ ਆਸਾਨ ਹੁੰਦਾ। ਜਦੋਂ ਤਰਜਮਾ ਆਟੋਮੈਟਿਕ ਹੁੰਦਾ, ਟੀਮਾਂ ਰੀਫੈਕਟਰ ਕਰਨ ਅਤੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਜਿਵੇਂ ਜ਼ਰੂਰਤ ਹੋਵੇ ਅਨੁਕੂਲ ਕਰਨ ਲਾਇਕ ਹੁੰਦੇ। ਇਸ ਲਈ ਕੰਪਾਇਲਰ ਇੱਕ ਵਾਰੀ ਦੀ ਚਾਲ ਨਹੀਂ ਸੀ—ਉਹ ਆਧੁਨਿਕ ਭਾਸ਼ਾਵਾਂ, ਟੂਲਿੰਗ ਅਤੇ ਸਹਿਯੋਗ ਦੀ ਬੁਨਿਆਦ ਬਣ ਗਏ।
ਇੱਕ ਕੰਪਾਇਲਰ "ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨਰਮ" ਬਣਾਉਣ ਬਾਰੇ ਨਹੀਂ ਹੈ—ਇਹ ਹੋਰ ਕਿ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਸਕੇਲਯੋਗ ਬਣਾਉਣਾ ਹੈ। ਇਹ ਇੱਕ ਵਿਅਕਤੀ ਦੇ ਇਰਾਦੇ ਨੂੰ ਦੂਰ ਤਕ ਲਿਜਾਉਂਦਾ ਹੈ: ਵੱਡੇ ਪ੍ਰੋਜੈਕਟਾਂ, ਵੱਡੀਆਂ ਟੀਮਾਂ, ਲੰਬੇ ਸਮੇਂ ਅਤੇ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ ਤੱਕ।
ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਵਿੱਚ ਕੱਲ੍ਹ ਕੋਈ ਨਵਾਂ ਜੁੜੇ, ਤੁਸੀਂ ਕਿਹੜਾ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਉਹ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਮਝ ਲਵੇ—ਵਧੀਆ ਨਾਮ, ਸਾਫ਼ ਸਤਰ ਚਾਂਚ, ਜਾਂ ਇਕ ਛੋਟੀ ਟਿੱਪਣੀ ਜੋ "ਕਿਉਂ" ਦਰਸਾਉਂਦੀ ਹੈ?
Grace Hopper ਨੇ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਹਾਰਡਵੇਅਰ-ਨਿਰਧਾਰਤ ਨਿਰਦੇਸ਼ਾਂ ਤੋਂ ਮਨੁੱਖ-ਕੇਂਦਰਿਤ ਸਰੋਤ ਕੋਡ ਵੱਲ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ। ਉਨ੍ਹਾਂ ਨੇ ਸ਼ੁਰੂਆਤੀ ਕੰਪਾਇਲਰ-ਵਾਂਗ ਸਿਸਟਮਾਂ ਨੂੰ ਅੱਗੇ ਵੱਧਾਇਆ ਅਤੇ ਦਿਖਾਇਆ ਕਿ ਟੂਲ ਇਰਾਦੇ ਨੂੰ ਮਸ਼ੀਨ-ਕਦਮਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਸਕਦੇ ਹਨ—ਇਸ ਨਾਲ ਸਾਫਟਵੇਅਰ ਤੇਜ਼ੀ ਨਾਲ ਲਿਖਿਆ ਜਾਂਦਾ, ਸਾਂਝਾ ਕੀਤਾ ਜਾਂਦਾ ਅਤੇ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ।
ਕੰਪਾਇਲਰਾਂ ਦੇ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਪ੍ਰੋਗ੍ਰਾਮ ਆਮ ਤੌਰ 'ਤੇ ਮਸ਼ੀਨ ਕੋਡ ਜਾਂ ਬਹੁਤ ਨੀਵੇਂ-ਪੱਧਰ ਦੇ ਨਿਰਦੇਸ਼ ਹੁੰਦੇ ਸਨ ਜੋ ਕਿਸੇ ਇਕ ਖ਼ਾਸ ਕੰਪਿਊਟਰ ਲਈ ਬਣਾਏ ਜਾਂਦੇ ਸਨ। ਕੰਮ ਮੈਨੂਅਲ, ਲੰਮੇ ਸਮੇਂ ਵਾਲਾ ਅਤੇ ਬਦਲਾਅ ਲਈ ਨਾਜ਼ੁਕ ਸੀ; ਇੱਕ ਛੋਟਾ ਫੀਚਰ ਵੀ ਵਿਆਪਕ ਦੁਬਾਰਾ-ਲਿਖਾਈ ਲਿਆ ਸਕਦਾ ਸੀ ਕਿਉਂਕਿ ਐਡਰੈੱਸ, ਜੰਪ ਅਤੇ ਮੈਮੋਰੀ ਲੇਆਉਟ ਹਰ ਹਾਰਡਵੇਅਰ ਨਾਲ ਟੰਡ-ਬਾਧੇ ਹੋਏ ਸਨ।
ਮਸ਼ੀਨ ਕੋਡ ਉਹ ਰਾਵ ਬਿੱਟ ਪੈਟਰਨ ਹਨ (0s ਅਤੇ 1s) ਜਿਨ੍ਹਾਂ ਨੂੰ CPU ਸਿੱਧਾ ਅਮਲ ਕਰਦਾ ਹੈ। Assembly readable ਨਿਕਨੇਮ ਵਰਤਦਾ ਹੈ, ਪਰ ਇਹ ਵੀ ਇੱਕ ਖ਼ਾਸ ਮਸ਼ੀਨ ਦੀ ਇੰਸਟਰਕਸ਼ਨ ਸੈਟ ਨਾਲ ਜੋੜਿਆ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਰਜਿਸਟਰਾਂ, ਐਡਰੈੱਸ ਅਤੇ ਨਿਰਦੇਸ਼ਾਂ ਦੇ ਸਹੀ ਕ੍ਰਮ ਬਾਰੇ ਸੋਚਣ 'ਤੇ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।
ਕੰਪਾਇਲਰ ਮਨੁੱਖ-ਲਿਖੇ ਸਰੋਤ ਕੋਡ ਨੂੰ ਇੱਕ ਨੀਵੇਂ-ਪੱਧਰ ਦੇ ਰੂਪ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਜੋ ਕੰਪਿਊਟਰ ਚਲਾ ਸਕਦਾ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ ਇਕ ਐਕਜ਼ਿਕਿਊਟੇਬਲ)। ਇਹ ਕੋਡ ਨੂੰ ਭਾਸ਼ਾ ਦੇ ਨਿਯਮਾਂ ਲਈ ਵੀ ਚੈੱਕ ਕਰਦਾ ਹੈ ਅਤੇ ਨਿਕਾਸ ਨੂੰ ਅਪਟੀਮਾਈਜ਼ ਵੀ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਮਨੁੱਖੀ ਤੌਰ 'ਤੇ ਦੁਹਰਾਇਆ ਜਾਣ ਵਾਲਾ ਤੇ ਗਲਤੀ-ਪੂਰਨ ਤਰਜਮਾ ਘਟਦਾ ਹੈ।
ਸਧਾਰਨ ਢੰਗ ਨਾਲ ਇੱਕ ਕੰਪਾਇਲਰ ਅਕਸਰ ਸਮੂਹ-ਤੌਰ 'ਤੇ पूरे ਪ੍ਰोगਰਾਮ ਜਾਂ ਵੱਡੇ ਹਿੱਸਿਆਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਤਬਦੀਲ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਚਲਣਯੋਗ ਨਿਕਾਸ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਇਕ ਇੰਟਰਪ੍ਰੀਟਰ ਤਾਂਫ-ਤੁਰੰਤ ਕਦਮ-ਦਰ-ਕਦਮ ਕੋਡ ਨੂੰ ਅਨੁਵਾਦ ਅਤੇ ਅਮਲ ਕਰਦਾ ਹੈ। ਅਜੇਕਾ ਆਧੁਨਿਕ ਪ੍ਰਣਾਲੀਆਂ ਦੋਹਾਂ ਪਹਲੂਆਂ ਨੂੰ ਮਿਲਾ ਕੇ ਵਰਤਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਵੱਖਰਾ ਵਰਕਫਲੋਅ ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।
A-0 ਨੇ ਪ੍ਰੋਗ੍ਰਾਮਰਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਬਣਾਈਆਂ ਰੂਟੀਨਾਂ ਨੂੰ ਇੱਕ ਆਈਡੈਂਟੀਫਾਇਰ ਨਾਲ ਸੰਦਰਭਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੱਤੀ; ਫਿਰ ਇਹ ਸਹੀ ਮਸ਼ੀਨ-ਕੋਡ ਬਲਾਕ ਲੱਭ ਕੇ ਉਨ੍ਹਾਂ ਨੂੰ ਜੋੜ ਕੇ ਇੱਕ ਪੂਰਾ ਐਕਜ਼ਿਕਿਊਟੇਬਲ ਤਿਆਰ ਕਰਦਾ (ਜਿਸ ਨੂੰ ਅਸੀਂ ਹੁਣ linking ਕਹਿ ਸਕਦੇ ਹਾਂ)। ਇਹ ਅਜੇ ਉਸ ਸਮੇਂ ਦਾ ਕੋਈ ਅੰਗਰੇਜ਼ੀ-ਨੁਮਾ ਭਾਸ਼ਾ ਕੰਪਾਇਲ ਕਰਨ ਵਰਗਾ ਨਹੀਂ ਸੀ, ਪਰ ਉਸਨੇ ਦਿਖਾਇਆ ਕਿ ਆਟੋਮੇਸ਼ਨ ਅਤੇ ਰੀਯੂਜ਼ ਦੁਆਰਾ ਹੱਥ-ਕੰਮ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਰੀਯੂਜ਼ ਕਰਨਯੋਗ ਸਬਰੁਟੀਨਾਂ ਦੇ ਉਪਯੋਗ ਨਾਲ ਤੁਸੀਂ ਇੱਕ ਹੀ ਤਰਕ ਨੂੰ ਹਰ ਵਾਰ ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖਦੇ। ਇਸ ਨਾਲ ਤੇਜ਼ੀ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਵਧਦੀ ਹੈ:
COBOL ਦਾ ਮਕਸਦ ਕਾਰੋਬਾਰੀ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਲੰਮੇ ਸਮੇਂ ਲਈ ਸਥਿਰ ਬਣਾਉਣਾ ਸੀ; ਇਸਨੇ ਰਿਕਾਰਡਾਂ, ਫ਼ੀਲਡਾਂ ਅਤੇ ਸਾਫ਼ ਵੇਰਵੇ 'ਤੇ ਵਜ਼ਨ ਦਿੱਤਾ। ਵੱਡਾ ਫਰਕ ਸੰਕਲਪਕ ਸੀ: standardization. ਕਮੇਟੀਆਂ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਅਪੇਖਾਵਾਂ ਨੇ ਇਕ ਸ਼ੇਅਰ ਕੀਤੀ ਹੋਈ ਨਿਸ਼ਾਨੀ ਬਣਾਈ, ਜਿਸਦੇ ਤਹਿਤ ਵੱਖ-ਵੱਖ ਵੇਂਡਰ ਉਸਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦੇ ਸਨ—ਇਸ ਨਾਲ vendor-lock-in ਘਟਿਆ ਅਤੇ ਕੋਡ/ਕੌਸ਼ਲ ਹੋਰ ਪੋਰਟੇਬਲ ਹੋ ਗਏ।
ਪੋਰਟੇਬਿਲਟੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕੋ ਸਰੋਤ ਕੋਡ ਨੂੰ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ ਲਈ ਕੱਪਾਇਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜੇਕਰ ਹਰ ਟਾਰਗੇਟ ਲਈ ਉਚਿਤ ਕੰਪਾਇਲਰ ਮੌਜੂਦ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਮਸ਼ੀਨ-ਵਿਸ਼ੇਸ਼ ਅਨੁਮਾਨ ਨਾ ਕਰੋ। ਇਹ ਸੰਸਥਾਵਾਂ ਨੂੰ ਆਪਣੀ ਸੌਫਟਵੇਅਰ ਨਿਵੇਸ਼ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਹਾਰਡਵੇਅਰ ਅਪਗਰੇਡ ਕਰਦੀਆਂ ਹਨ।
ਕੰਪਾਇਲਰ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਭਾਸ਼ਾ ਦੇ ਨਿਯਮਾਂ ਦੇ ਅਨੁਸਾਰ ਚਲਾਉਣ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ, ਪਰ ਇਹ ਸਹੀਤਾ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੇ। ਅਸਲ ਤਰੀਕੇ:
