06 ਅਗ 2025·8 ਮਿੰਟ
John Backus & FORTRAN: ਉਹ ਭਾਸ਼ਾ ਜਿਸਨੇ ਸੌਫਟਵੇਅਰ ਨੂੰ ਪੈਮਾਨੇ 'ਤੇ ਲਿਆ
John Backus ਨੇ IBM ਵਿੱਚ FORTRAN ਦੀ ਅਗਵਾਈ ਕੀਤੀ ਅਤੇ ਦਿਖਾਇਆ ਕਿ ਉੱਚ-ਸਤ੍ਹਾ ਕੋਡ ਫਿਰ ਵੀ ਤੇਜ਼ ਦੌੜ ਸਕਦਾ—ਇਸ ਨਾਲ ਉਤਪਾਦਕਤਾ ਵਧੀ ਅਤੇ ਸੌਫਟਵੇਅਰ ਇੱਕ ਅਸਲ ਉਦਯੋਗ ਬਣਿਆ।
John Backus ਨੇ IBM ਵਿੱਚ FORTRAN ਦੀ ਅਗਵਾਈ ਕੀਤੀ ਅਤੇ ਦਿਖਾਇਆ ਕਿ ਉੱਚ-ਸਤ੍ਹਾ ਕੋਡ ਫਿਰ ਵੀ ਤੇਜ਼ ਦੌੜ ਸਕਦਾ—ਇਸ ਨਾਲ ਉਤਪਾਦਕਤਾ ਵਧੀ ਅਤੇ ਸੌਫਟਵੇਅਰ ਇੱਕ ਅਸਲ ਉਦਯੋਗ ਬਣਿਆ।
1950 ਦੇ ਸ਼ੁਰੂਆਤੀ ਦਹਾਕੇ ਵਿੱਚ, ਕੰਪਿਊਟਰ ਕਮ ਹੀ ਮਿਲਦੇ ਸਨ, ਮਹਿੰਗੇ ਸਨ ਅਤੇ ਸਰਕਾਰਾਂ, ਯੂਨੀਵਰਸਿਟੀਆਂ ਅਤੇ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਵਰਗਿਆਂ ਲਈ ਰਹਿਤ ਸਨ। ਉਹ ਆਪਣੇ ਸਮੇਂ ਲਈ ਤਾਕਤਵਰ ਸਨ—ਪਰ ਉਨ੍ਹਾਂ 'ਤੇ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਕਰਨਾ ਬਹੁਤ ਹੀ ਧੀਮਾ ਸੀ। ਬਹੁਤੇ ਪ੍ਰੋਗਰਾਮ ਸਿੱਧੇ ਮਸ਼ੀਨ ਕੋਡ ਜਾਂ ਅਸੈਂਬਲੀ ਵਿੱਚ ਲਿਖੇ ਜਾਂਦੇ ਸਨ, ਜਿਸ ਵਿੱਚ ਹਰ ਹੁਕਮ ਹਾਰਡਵੇਅਰ ਦੇ ਛੋਟੇ-ਨੁਕਤਿਆਂ ਨਾਲ ਮਿਲਣਾ ਲਾਜ਼ਮੀ ਸੀ। ਕਦੇ ਕਦੇ ਇੱਕ ਛੋਟਾ ਫਾਰਮੂਲਾ ਬਦਲਣਾ ਮਤਲਬ ਲੰਮੇ ਕੋਡ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਹੁੰਦਾ ਸੀ, ਅਤੇ ਇੱਕ ਗਲਤੀ ਹੋਣ ਨਾਲ ਘੰਟਿਆਂ ਦੇ ਇੰਤਜ਼ਾਰ ਦੇ ਬਾਅਦ ਸਾਰੀ ਚਲਾਨ ਠੱਠੇਰੇ 'ਤੇ ਚੱਲ ਸਕਦੀ ਸੀ।
John Backus IBM ਵਿੱਚ ਇੱਕ ਇੰਜੀਨੀਅਰ ਸੀ ਜਿਸਨੇ ਨੀਵੀਂ ਸਤਰ ਦੀ ਕੋਡਿੰਗ 'ਤੇ ਬਰਬਾਦ ਹੋ ਰਹੇ ਸਮੇਂ ਨੂੰ ਦੇਖਿਆ। ਉਸਨੇ ਇੱਕ ਛੋਟੀ ਟੀਮ ਦੀ ਅਗਵਾਈ ਕੀਤੀ ਜੋ ਕੁਝ ਨਵਾਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਸੀ: ਪ੍ਰੋਗ੍ਰਾਮਰਾਂ ਨੂੰ ਗਣਿਤ-ਭਰਪੂਰ ਹੁਕਮ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਲਿਖਣ ਦਿਓ ਜਿਵੇਂ ਉਹ ਸਮੱਸਿਆ ਬਾਰੇ ਸੋਚਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਕੰਪਾਇਲਰ ਨੂੰ ਇਹ ਤਬਦੀਲ ਕਰਨ ਦਿਓ ਕਿ ਉਹ ਤੇਜ਼ ਮਸ਼ੀਨ ਕੋਡ ਬਣਾਏ।
ਪਰੋਜੈਕਟ FORTRAN ("Formula Translation") ਬਣ ਗਿਆ, ਖ਼ਾਸ ਤੌਰ 'ਤੇ IBM ਦੇ ਵਿਗਿਆਨਕ ਗਾਹਕਾਂ ਲਈ—ਉਹ ਲੋਕ ਜੋ ਗਣਿਤਕ ਕੰਮ ਕਰਨਗੇ। ਵਾਅਦਾ ਸਾਫ਼ ਸੀ: ਘੱਟ ਕੋਡ ਲਿਖੋ, ਘੱਟ ਬੱਗ ਆਉਣਗੇ, ਅਤੇ ਫਿਰ ਵੀ IBM 704 ਜਿਹੇ ਮਸ਼ੀਨਾਂ 'ਤੇ ਤੇਜ਼ ਚਲੋ।
ਉਸ ਸਮੇਂ, ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਗ੍ਰਾਮਰ ਮੰਨਦੇ ਸਨ ਕਿ ਉੱਚ-ਸਤ੍ਹਾ ਭਾਸ਼ਾਵਾਂ ਇੱਕ ਆਰਾਮ-ਕੁਦਰਤ ਹਨ। ਉਹ ਸੋਚਦੇ ਸਨ ਕਿ ਜੋ ਕੁਝ "ਇੰਗਲਿਸ਼-ਜਿਹਾ" ਹੋਵੇਗਾ ਉਹ ਹੱਥ ਨਾਲ ਲਿਖੀ ਅਸੈਂਬਲੀ ਨਾਲੋਂ ਕਾਫੀ ਧੀਮਾ ਚੱਲੇਗਾ—ਇੰਨਾ ਧੀਮਾ ਕਿ ਸੁਵਿਧਾ ਦਾ ਕੋਈ ਫਾਇਦਾ ਹੀ ਨਾ ਰਹੇ। ਕੰਪਿਊਟਰ ਮਹਿੰਗੇ ਸਨ ਅਤੇ ਕੰਪਿਊਟ ਸਮਾਂ ਕੰਟਰੋਲ ਕੀਤਾ ਜਾਂਦਾ ਸੀ, ਇਸ ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਨਿਰੰਤਰ ਮਹੱਤਵ ਰੱਖਦਾ ਸੀ।
ਇਸ ਲਈ FORTRAN ਸਿਰਫ਼ ਨਵਾਂ ਸਿੰਟੈਕਸ ਨਹੀਂ ਸੀ; ਇਹ ਇੱਕ ਪੇਸ਼ਕਸ਼ ਸੀ ਕਿ ਆਟੋਮੇਸ਼ਨ ਮਾਹਿਰ ਮਨੁੱਖੀ ਹੁਨਰ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰ ਸਕਦੀ ਹੈ: ਇੱਕ ਕੰਪਾਇਲਰ ਉਨ੍ਹਾਂ ਕੋਡਾਂ ਨੂੰ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਵਿਗਿਆਨੀ ਅਤੇ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਹਰ ਸਾਈਕਲ ਦੀ ਪਰਵਾਹ ਕਰਨ ਵਾਲਿਆਂ ਵੱਲੋਂ ਭਰੋਸੇਯੋਗ ਹੋਣ।
FORTRAN ਦੀ ਕਹਾਣੀ ਇੱਕ ਹਿੱਸਾ ਤਕਨੀਕੀ ਢੰਗ ਦਾ ਅਤੇ ਇੱਕ ਹਿੱਸਾ ਸਭਿਆਚਾਰਕ ਬਦਲਾਅ ਹੈ। ਅਸੀਂ ਵੇਖਾਂਗੇ ਕਿ ਉੱਚ-ਸਤ੍ਹਾ ਭਾਸ਼ਾਵਾਂ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਦਾ ਅਨੁਭਵ ਕਿਵੇਂ ਸੀ, Backus ਦੀ ਟੀਮ ਨੇ ਇੱਕ ਐਸਾ ਕੰਪਾਇਲਰ ਕਿਵੇਂ ਬਣਾਇਆ ਜੋ ਹੱਥ-ਲਿਖੀ ਕੋਡ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰ ਸਕਦਾ ਸੀ, ਅਤੇ ਇਸ ਕਾਮਯਾਬੀ ਨੇ ਸੌਫਟਵੇਅਰ ਦੀਆਂ ਆਰਥਿਕਤਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਬਦਲ ਦਿੱਤਾ—ਉਹ ਪੈਟਰਨ ਜੋ ਅਧੁਨਿਕ ਟੀਮਾਂ ਅਜੇ ਵੀ ਵਰਤਦੇ ਹਨ।
FORTRAN ਤੋਂ ਪਹਿਲਾਂ, "ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ" ਆਮ ਤੌਰ 'ਤੇ ਮਸ਼ੀਨ ਦੀ ਆਪਣੀ ਭਾਸ਼ਾ ਵਿੱਚ ਹੁੰਦੀ ਸੀ—ਜਾਂ ਉਸ ਤੋਂ ਥੋੜ੍ਹੀ ਹੀ ਦੋਸਤਾਨਾ ਕਿਸਮ ਦੀ।
ਪ੍ਰਾਰੰਭਿਕ ਕੰਪਿਊਟਰ ਮਸ਼ੀਨ ਕੋਡ ਚਲਾਉਂਦੇ ਸਨ: ਨਿਊਮਰਿਕ ਓਪਕੋਡ ਅਤੇ ਮੈਮੋਰੀ ਐਡਰੈੱਸ। ਕਿਉਂਕਿ ਇਹ ਲੰਮੇ ਸਮੇਂ ਲਈ ਸੰਭਾਲਣਾ ਮੁਸ਼ਕਲ ਸੀ, ਪ੍ਰੋਗ੍ਰਾਮਰ ਅਸੈਂਬਲੀ ਭਾਸ਼ਾ ਵਰਤਦੇ ਸਨ ਜੋ ਕਈ ਨੰਬਰਾਂ ਦੀ ਥਾਂ ਛੋਟੀ-ਛੋਟੀ ਮੋਨੀਕਾਂ ਦਿੰਦੀ ਸੀ। ਪਰ ਅਸੈਂਬਲੀ ਫਿਰ ਵੀ ਹਾਰਡਵੇਅਰ ਦੇ ਨਜ਼ਦੀਕੀ ਪਰਤ ਸੀ। ਤੁਸੀਂ ਗਣਿਤਕ ਟਰਮੀਨਲੋਜੀ ਵਿੱਚ ਕੀ ਚਾਹੁੰਦੇ ਹੋ ਇਹ ਨਹੀਂ ਦੱਸਦੇ—ਤੁਸੀਂ ਕਦਮ-ਦਰ-ਕਦਮ, ਰਜਿਸਟਰ-ਰਜਿਸਟਰ ਦੱਸਦੇ ਹੋ।
ਵਿਗਿਆਨਕ ਗਣਨਾ ਲਈ ਇਹ ਮਤਲਬ ਸੀ ਕਿ ਲੂਪਾਂ, ਮੈਮੋਰੀ ਲੇਆਊਟ ਅਤੇ ਅੰਤਰਿਮ ਮੁੱਲਾਂ ਨੂੰ ਮਨੁਸ਼ੀਅਤਰੀ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਣਾ ਪੈਂਦਾ ਸੀ। ਇੱਕ ਛੋਟਾ ਫਾਰਮੂਲਾ ਬਦਲਣਾ ਕਈ ਹਿੱਸਿਆਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਮੰਗਦਾ ਸੀ ਕਿਉਂਕਿ ਸਭ ਕੁਝ ਐਡਰੈੱਸਾਂ ਅਤੇ ਜੰਪਾਂ ਰਾਹੀਂ ਜੁੜਿਆ ਹੁੰਦਾ ਸੀ।
ਅਸੈਂਬਲੀ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਧੀਮੀ ਅਤੇ ਨਾਜੁਕ ਸੀ। ਆਮ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਸਨ:
ਵਿਗਿਆਨੀਆਂ ਅਤੇ ਇੰਜੀਨੀਅਰਾਂ ਸਿਰਫ਼ ਇੱਕ ਗਣਨਾ ਨਹੀਂ ਚਲਾਉਂਦੇ ਸਨ—ਉਹ ਮਾਡਲਾਂ ਨੂੰ ਸੁਧਾਰਦੇ, ਸਿਮੂਲੇਸ਼ਨ ਦੁਬਾਰਾ ਚਲਾਉਂਦੇ ਅਤੇ "ਕੀ ਹੋਵੇ ਜੇ" ਸਵਾਲਾਂ ਦੀ ਜਾਂਚ ਕਰਦੇ। ਜਦੋਂ ਹਰ ਅਪਡੇਟ ਦਿਨਾਂ ਜਾਂ ਹਫ਼ਤਿਆਂ ਦਾ ਮੰਗਦਾ, ਤਦ ਪ੍ਰਯੋਗਕਾਰੀ ਰੁਕ ਜਾਦਾ ਸੀ।
ਇੱਥੇ ਇੱਕ ਨਵਾਂ ਖ਼ਰਚ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ: ਪ੍ਰੋਗ੍ਰਾਮਰ ਦਾ ਸਮਾਂ। ਹਾਰਡਵੇਅਰ ਮਹਿੰਗਾ ਸੀ, ਪਰ ਹੁਨਰਮੰਦ ਲੋਕ ਵੀ ਮਹਿੰਗੇ ਸਨ। 1950 ਦੀਆਂ ਮੱਧਵਾਰੀਆਂ ਤੱਕ, ਬੋਤਲ-ਨੇੱਕ ਸਿਰਫ਼ ਮਸ਼ੀਨ ਦੀ ਗਤੀ ਨਹੀਂ ਰਹੀ—ਉਹ ਇਸ ਗੱਲ ਵਿੱਚ ਸੀ ਕਿ ਮਨੁੱਖਾਂ ਨੇ ਮਸ਼ੀਨ ਨੂੰ ਲਾਭਦਾਇਕ ਕੰਮ ਕਰਨ ਲਈ ਕਿੰਨਾ ਸਮਾਂ ਲਾਇਆ।
John Backus ਕਿਸੇ ਤਰ੍ਹਾਂ ਤੋਂ ਪਹਿਲਾਂ ਤੋਂ ਹੀ "ਕੰਪਿਊਟਰ ਪਾਇਓਨੀਅਰ" ਨਹੀਂ ਸੀ। ਇੱਕ ਬੇ-ਛੇਤੀ ਅਰੰਭਕ ਕਰੀਅਰ ਅਤੇ US Army ਦਾ ਸਮਾਂ ਬਿਤਾਉਣ ਤੋਂ ਬਾਅਦ, ਉਹ 1950 ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ IBM ਵਿੱਚ ਆਇਆ, ਜਦੋਂ ਕੰਪਿਊਟਰ ਹਾਲੇ ਵੀ ਵਿਰਲੇ ਸਨ ਅਤੇ ਜ਼ਿਆਦातर ਹੱਥ ਨਾਲ ਪ੍ਰੋਗ੍ਰਾਮ ਕੀਤੇ ਜਾਂਦੇ ਸਨ। Backus ਨੇ ਜਲਦੀ ਦੋ ਚੀਜ਼ਾਂ ਲਈ ਖਾਸ ਦਿਖਾਈ ਦਿੱਤੀ: ਨਿਰਸ ਕੰਮ ਨਾਲ ਅਲਸਪਣਾ, ਅਤੇ ਮਹਾਨ ਇੰਜੀਨੀਅਰਿੰਗ ਪ੍ਰਯਾਸਾਂ ਨੂੰ ਸੁਚੱਜਾ ਢੰਗ ਨਾਲ ਆਯੋਜਿਤ ਕਰਨ ਦੀ ਕਾਬਲियत।
IBM ਕੋਲ ਇੱਕ ਸਮੱਸਿਆ ਅਤੇ ਇੱਕ ਮੌਕਾ ਦੋਹਾਂ ਸੀ: IBM 704। ਇਹ ਆਪਣੇ ਸਮੇਂ ਲਈ ਤਾਕਤਵਰ ਸੀ ਅਤੇ ਗਣਿਤ-ਭਰਪੂਰ ਕੰਮਾਂ ਲਈ ਖਾਸ ਫੀਚਰ (ਜਿਵੇਂ ਫਲੋਟਿੰਗ-ਪੌਇੰਟ ਗਣਿਤ) ਰੱਖਦਾ ਸੀ। ਪਰ ਵਿਗਿਆਨਕ ਅਤੇ ਤਕਨੀਕੀ ਗਾਹਕ ਅਸੈਂਬਲੀ ਭਾਸ਼ਾ ਲਿਖਣ ਅਤੇ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਵੱਡਾ ਸਮਾਂ ਗੁਜ਼ਾਰ ਰਹੇ ਸਨ। ਜੇ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਇੰਨੀ ਹੀ ਧੀਮੀ ਰਹੀ, ਤਾਂ ਇਕ ਵਧੀਆ ਮਸ਼ੀਨ ਵੀ ਅਣਉਪਯੋਗ ਪਈ ਰਹਿਣੀ ਸੀ।
IBM ਦੀ ਸ਼ਰਤ ਸਧਾਰਣ ਪਰ ਜੋਖ਼ਿਮ ਭਰਿਆ ਸੀ: 704 ਨੂੰ ਬਿਨਾਂ ਗਤੀ ਗਵਾ ਕੇ ਆਸਾਨੀ ਨਾਲ ਪ੍ਰੋਗ੍ਰਾਮ ਬਣਾਉਣਾ।
Backus ਨੇ ਇੱਕ ਟੀਮ ਦੀ ਅਗਵਾਈ ਕੀਤੀ ਜੋ FORTRAN ਨੂੰ ਦੋ ਅਟੁੱਟ ਹਿੱਸਿਆਂ ਵਾਂਗ ਸਮਝਦੀ ਸੀ: ਇੱਕ ਭਾਸ਼ਾ ਜਿਸਨੂੰ ਲੋਕ ਲਿਖ ਸਕਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਕੰਪਾਇਲਰ ਜੋ ਉਸਨੂੰ ਤੇਜ਼ ਮਸ਼ੀਨ ਕੋਡ ਵਿੱਚ ਬਦਲ ਸਕਦਾ। ਦੂਜਾ ਹਿੱਸਾ ਅਸਲੀ ਦਾਅਵ ਸੀ। ਕਈ ਮਾਹਿਰ ਮੰਨਦੇ ਸਨ ਕਿ "ਆਟੋਮੈਟਿਕ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ" ਹਮੇਸ਼ਾਂ ਅਸੈਂਬਲੀ ਦੀ ਤਰ੍ਹਾਂ ਕੁਸ਼ਲ ਹੋਣ ਲਈ ਬੇਕਾਰ ਰਹੇਗੀ।
ਉੱਚ-ਸਤ੍ਹਾ ਭਾਸ਼ਾ ਸਿਰਫ਼ ਸੁੰਦਰ ਸਿੰਟੈਕਸ ਨਹੀਂ ਸੀ। ਇਸਦਾ ਮਤਲਬ ਸੀ ਕਿ ਤੁਸੀਂ ਫਾਰਮੂਲੇ, ਲੂਪ ਅਤੇ ਸਧਾਰਨ ਨਿਰਦੇਸ਼ ਐਸੇ ਤਰੀਕੇ ਨਾਲ ਲਿਖੋ ਜੋ ਸਮੱਸਿਆ ਦੇ ਗਣਿਤ ਅਤੇ ਤਰਕ ਨਾਲ ਨੇੜੇ ਹੋਣ—ਫਿਰ ਕੰਪਾਇਲਰ 'ਤੇ ਭਰੋਸਾ ਰੱਖੋ ਕਿ ਉਹ ਹੱਥ-ਲਿਖੀ ਕੋਡ ਦੇ ਨਿਕਟ ਸਥਾਨ ਦਾ ਕੋਡ ਬਣਾਏ। IBM ਅਤੇ Backus ਜੋ ਭਰੋਸਾ ਜਿੱਤਣਾ ਚਾਹੁੰਦੇ ਸਨ, ਉਹ ਇਹ ਸੀ।
FORTRAN ਦਾ ਮੁੱਖ ਵਾਅਦਾ ਸਧਾਰਣ ਪਰ ਵਿਪਰੀਤ ਸੀ: ਮਸ਼ੀਨ ਨੂੰ ਹਰ ਇਕ ਛੋਟੇ ਕਦਮ ਦੱਸਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਉਹਨਾਂ ਬਿਆਨ ਲਿਖ ਸਕਦੇ ਹੋ ਜੋ ਗਣਿਤ ਦੇ ਬਹੁਤ ਨੇੜੇ ਹੋਣ।
ਇੱਕ ਇੰਜੀਨੀਅਰ ਲਿਖ ਸਕਦਾ ਸੀ "ਇਸ ਸੁਤਰ ਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਵੈਲਯੂਆਂ ਲਈ ਗਣਨਾ ਕਰੋ", ਬਜਾਏ ਅਸੈਂਬਲੀ ਦੇ ਲੋਡ, ਐਡ, ਸਟੋਰ ਅਤੇ ਜੰਪ ਦੀ ਲੰਮੀ ਲੜੀ ਸਪੈਲ ਕਰਨ ਦੇ। ਉਮੀਦ ਇਹ ਸੀ ਕਿ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਵਿਚਾਰ ਬਿਆਨ ਕਰਨ ਵਰਗੀ ਹੋ ਜਾਵੇ—ਨਾਕਿ ਸ਼ਬਦਾਂ ਨਾਲ ਇੱਕ ਕੰਟਰੋਲ ਪੈਨਲ ਤਾਰਨ ਵਰਗੀ।
FORTRAN ਸਿੱਧਾ ਮਸ਼ੀਨ 'ਤੇ ਨਹੀਂ ਚਲਦਾ। ਇੱਕ ਵੱਖਰਾ ਪ੍ਰੋਗਰਾਮ—ਕੰਪਾਇਲਰ—FORTRAN ਸਰੋਤ ਕੋਡ ਨੂੰ ਮਸ਼ੀਨ ਦੀ ਨੀਵੇਂ-ਸਤ੍ਹਾ ਭਾਸ਼ਾ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ।
ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਕਾਬਲ ਅਨੁਵਾਦਕ ਵਾਂਗ ਸੋਚ ਸਕਦੇ ਹੋ: ਤੁਸੀਂ ਮਨੁੱਖੀ ਪੜ੍ਹਨਯੋਗ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਦੇ ਹੋ; ਕੰਪਾਇਲਰ ਉਸਨੂੰ ਮਸ਼ੀਨ ਲਈ ਐਸਾ ਭਾਸ਼ਾ ਬਣਾਦਿੰਦਾ ਹੈ ਜੋ ਤਤਕਾਲ ਕਾਰਜ ਕਰ ਸਕੇ।
Backus ਦੀ ਟੀਮ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਇੱਕ ਅਪਰਤਿਆਸ਼ਿਤ ਸੰਯੋਗ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਸੀ:
ਆਖਰੀ ਨੁਕਤਾ ਮਹੱਤਵਪੂਰਨ ਸੀ। FORTRAN ਹਰ ਕਿਸੇ ਲਈ ਨਹੀਂ ਬਣਾਈ ਗਈ—ਇਹ ਵਾਸਤਵਿਕ ਗਣਨਾਵਾਂ ਨੂੰ ਘੱਟ ਗਲਤੀਆਂ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਕਰਨ ਲਈ ਬਣਾਈ ਗਈ ਸੀ।
ਸੰਦੇਹ ਕੀਤਾ ਗਿਆ ਸੀ ਕਿ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਪੂਰਾ ਨਿਯੰਤਰਣ ਜ਼ਰੂਰੀ ਹੈ, ਅਤੇ "ਆਟੋਮੈਟਿਕ" ਤਬਦੀਲੀਆਂ ਅਕਸਰ ਬਰਬਾਦ ਕਰਨ ਵਾਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਹੋਰ ਲੋਕ ਡੀਬੱਗਿੰਗ ਲੈ ਕੇ ਘਬਰਾਏ—ਜੇ ਕੰਪਾਇਲਰ ਆਖਰੀ ਨਿਰਦੇਸ਼ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪਤਾ ਕਿਵੇਂ ਲਗਾਓਗੇ ਕਿ ਮਸ਼ੀਨ ਅੰਦੀਰੋਂ ਕੀ ਕਰ ਰਹੀ ਹੈ?
FORTRAN ਦੇ ਪਹਿਲੇ ਯੂਜ਼ਰ ਇੰਜੀਨੀਅਰ ਅਤੇ ਵਿਗਿਆਨੀ ਸਨ—ਜੋ ਸੁਤਰ ਚਲਾਉਣ, ਮਾਡਲ ਟੈਸਟ ਕਰਨ ਅਤੇ ਨਤੀਜੇ ਨਿਕਾਲਣ ਵਿੱਚ ਰੁਚੀ ਰਖਦੇ ਸਨ। ਉਨ੍ਹਾਂ ਲਈ ਵਾਅਦਾ ਨਵਿਆਂ ਬਾਰੇ ਨਹੀ ਸੀ; ਇਹ ਸਮਾਂ ਬਚਾਉਣਾ, ਘੱਟ ਟ੍ਰਾਂਸਕ੍ਰਿਪਸ਼ਨ ਗਲਤੀਆਂ, ਅਤੇ ਐਸਾ ਕੋਡ ਜੋ ਇੱਕ ਛੋਟੀ ਪਕੜ ਵਾਲੀ ਅਸੈਂਬਲੀ ਪਾਣੀ ਦੇ ਪੁਰਉ-ਪ੍ਰਸਾਦ ਤੋਂ ਬਚਾ ਸਕੇ।
FORTRAN ਸਿਰਫ਼ ਨਵਾਂ ਤਰੀਕਾ ਨਹੀਂ ਸੀ ਕੋਡ ਲਿਖਣ ਲਈ—ਇਸਨੇ ਤਬਦੀਲ ਕਰਨ ਦਾ ਨਵਾਂ ਤਰੀਕਾ ਮੰਗਿਆ। ਉਹ ਤਬਦੀਲੀ ਕੰਪਾਇਲਰ 'ਤੇ ਆਈ, ਅਤੇ ਇਸ ਦੀ ਕਾਮਯਾਬੀ ਤੈਅ ਕਰੇਗੀ ਕਿ FORTRAN ਇਨਕਲਾਬ ਬਣੇਗਾ ਜਾਂ ਭੁੱਲਾ-ਭਾਲੀ ਨੋਟ।
ਇਕ ਕੰਪਾਇਲਰ ਨੂੰ ਇੱਕ ਪ੍ਰੋਫੈਸ਼ਨਲ ਦਭਾਸ਼ੀਏ ਵਾਂਗ ਸੋਚੋ। ਤੁਸੀਂ ਸਪੱਸ਼ਟ, ਉੱਚ-ਸਤ੍ਹਾ ਵਾਕਾਂ ਵਿੱਚ ਗੱਲ ਕਰਦੇ ਹੋ ("ਇਸ ਸਮੀਕਰਨ ਦੀ ਗਣਨਾ ਕਰੋ, ਹਰ ਵੈਲਯੂ ਲਈ ਦੁਹਰਾਓ"), ਪਰ ਦਰਸ਼ਕ ਸਖ਼ਤ, ਨੀਵੀਂ-ਸਤ੍ਹਾ ਸ਼ਬਦਾਵਲੀ ਸਮਝਦਾ ਹੈ। ਇੱਕ ਔਸਤ ਅਨੁਵਾਦਕ ਤੁਹਾਡਾ ਅਰਥ ਠੀਕ ਤਰ੍ਹਾਂ ਬਿਆਨ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਢੀਲਾ, ਲੰਮਾ ਅਤੇ ਘੇਰਾਂਦਾਰ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਵਧੀਆ ਅਨੁਵਾਦਕ ਅਰਥ ਅਤੇ ਕੁਸ਼ਲਤਾ ਦੋਹਾਂ ਸੰਭਾਲਦਾ ਹੈ, ਤਾ ਕਿ ਦਰਸ਼ਕ ਤੁਰੰਤ ਕਾਰਵਾਈ ਕਰ ਸਕੇ।
FORTRAN ਨੂੰ ਉਸ ਵੱਡੇ ਅਨੁਵਾਦਕ ਦੀ ਲੋੜ ਸੀ।
ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਗ੍ਰਾਮਰ FORTRAN ਨੂੰ ਸੁੰਦਰਤਾ ਜਾਂ ਆਰਾਮ ਲਈ ਨਹੀਂ ਚੁਣ ਰਹੇ ਸਨ। ਉਹ ਇਸਨੂੰ ਇਸ ਲਈ ਚੁਣਦੇ ਸਨ ਕਿ ਇਹ ਘੱਟ ਘੰਟਿਆਂ ਵਿੱਚ ਕੰਮ ਮੁਹੱਈਆ ਕਰਵਾ ਸਕੇ ਬਿਨਾਂ ਰਨਟਾਈਮ ਸਜ਼ਾ ਦੇ। IBM 704 ਵਰਗੀਆਂ ਮਹਿੰਗੀਆਂ ਮਸ਼ੀਨਾਂ 'ਤੇ, ਬਰਬਾਦ CPU ਸਮਾਂ ਪਿਛਲੇ-ਪਿਛਲਾ ਪੈਸਾ ਸੀ—ਅਤੇ ਵਿਗਿਆਨਕ ਕੰਮ ਵਿੱਚ, ਧੀਮਾ ਕੋਡ ਨਤੀਜੇ ਦੇਣ ਵਿੱਚ ਦੇਰ ਕਰ ਸਕਦਾ ਸੀ।
ਇਸ ਲਈ ਅਸਲ ਉਤਪਾਦ ਭਾਸ਼ਾ ਸਪੈੱਕ ਨਹੀਂ ਸੀ; ਇਹ ਕੰਪਾਇਲਰ ਦੇ ਨਿਰੀਕਸ਼ਣ ਨਾਲ ਬਾਹਰ ਆਉਂਦਾ ਕੋਡ ਸੀ। ਜੇcompiled ਕੋਡ ਹੱਥ-ਲਿਖੀ ਅਸੈਂਬਲੀ ਦੇ ਨੇੜੇ ਚਲਦਾ, ਤਾਂ ਟੀਮਾਂ ਸਵਿੱਚ ਕਰ ਸਕਦੀਆਂ ਸਨ। ਨਹੀਂ ਤਾਂ, ਉਹ FORTRAN ਨੂੰ ਛੱਡ ਦੇਣਗੇ ਭਾਵੇਂ ਇਹ ਕਿੰਨੀ ਹੀ "ਸੁੰਦਰ" ਕਿਉਂ ਨਾ ਹੋਵੇ।
FORTRAN ਦਾ ਮੁੱਖ ਵਿਕਰੀ ਬਿੰਦੂ—ਗਣਿਤ ਨੂੰ ਗਣਿਤ ਵਰਗਾ ਲਿਖਣਾ—ਕੰਪਾਇਲ ਕਰਨ ਨੂੰ ਔਖਾ ਬਣਾਉਂਦਾ ਸੀ। ਕੰਪਾਇਲਰ ਨੂੰ ਇਹ ਕਰਨਾ ਪੈਂਦਾ ਸੀ:
ਕਈ ਇੰਜੀਨੀਅਰ ਮੰਨਦੇ ਸਨ ਕਿ ਉੱਚ-ਸਤ੍ਹਾ ਕੋਡ ਵੁਜੂਦਨਹਾਰ ਤੌਰ 'ਤੇ ਹਮੇਸ਼ਾਂ ਧੀਮਾ ਹੋਵੇਗਾ। Backus ਦੀ ਟੀਮ ਨੇ ਇਸ ਧਾਰਣਾ ਨੂੰ ਸਬੂਤ ਨਾਲ ਹਰਾਉਣਾ ਸੀ: compiled ਪ੍ਰੋਗਰਾਮ ਜੋ ਮੁਕਾਬਲੇਯੋਗ, ਭਰੋਸੇਯੋਗ ਅਤੇ ਪੇਸ਼ਗੀਨ ਹੋਣ। ਬਿਨਾਂ ਇਸ ਪ੍ਰਦਰਸ਼ਨ ਭਰੋਸੇ ਦੇ, FORTRAN ਇੱਕ ਅਕਾਦਮਿਕ ਸੁਵਿਧਾ ਹੀ ਰਹਿ ਜਾਂਦੀ।
FORTRAN ਦਾ ਵੱਡਾ ਵਾਅਦਾ ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਤੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੋਡ ਲਿਖ ਸਕਦਾ—ਬਲਕਿ ਇਹ ਸੀ ਕਿ compiled ਕੋਡ ਫਿਰ ਵੀ ਤੇਜ਼ ਚੱਲ ਸਕਦਾ। ਇਹ ਮਹੱਤਵਪੂਰਕ ਸੀ ਕਿਉਂਕਿ ਸ਼ੁਰੂਆਤੀ ਗ੍ਰਹਿਣਹਾਰ ਆਮ ਤੌਰ 'ਤੇ ਪੈਚਿਣੇ ਨਹੀਂ ਸਨ; ਉਹ ਵਿਗਿਆਨੀਆਂ ਅਤੇ ਇੰਜੀਨੀਅਰਾਂ ਸਨ ਜੋ ਮਸ਼ੀਨ ਘੰਟਿਆਂ ਅਤੇ ਨਤੀਜਿਆਂ 'ਤੇ ਮਾਪਦੇ ਸਨ।
ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਦਾ ਮਤਲਬ ਹੈ ਕੰਪਾਇਲਰ ਵੱਲੋਂ ਉਹ ਵਧੀਕ ਕੰਮ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਕਰ ਰਹੇ। ਤੁਸੀਂ ਸਪੱਸ਼ਟ, ਗਣਿਤ-ਜਿਹਾ ਬਿਆਨ ਲਿਖਦੇ ਹੋ, ਅਤੇ ਕੰਪਾਇਲਰ ਚੁਪਚਾਪ ਉਹਨਾਂ ਨੂੰ ਘੱਟ ਹੁਕਮਾਂ, ਘੱਟ ਮੈਮੋਰੀ ਪਹੁੰਚ ਅਤੇ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਚਲਣ ਵਾਲੇ ਰੂਪ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ।
ਹਾਸਲ ਕਰਨ ਦਾ ਲਕਸ਼ ਨਹੀਂ "ਚਤੁਰ" ਹੋਣਾ ਸੀ। ਲਕਸ਼ ਸੀ ਭਰੋਸੇਯੋਗ ਦਕਸ਼ਤਾ—ਤਾਂ ਜੋ ਲੋਕ ਯਕੀਨ ਕਰ ਸਕਣ ਕਿ FORTRAN ਵਿੱਚ ਲਿਖਣ ਨਾਲ ਉਨ੍ਹਾਂ ਨੂੰ ਧੀਮਾ ਕੋਡ ਮਿਲੇਗਾ।
FORTRAN ਕੰਪਾਇਲਰ ਨੇ ਉਹ ਸੁਧਾਰ ਲਗਾਏ ਜੋ ਦੈਨੀਕ ਸੂਝ-ਬੂਝ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਹਨ:
ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪ੍ਰੋਗ੍ਰਾਮਰ ਨੂੰ ਨਿਰਦੇਸ਼-ਸਮਾਂ ਜਾਂ ਐਡਰੈੱਸ ਦੇ ਬਾਰੇ ਨਹੀਂ ਸੋਚਣ ਦਿੰਦੀ—ਪਰ ਇਹੀ ਚੀਜ਼ਾਂ ਅਸੈਂਬਲੀ ਪ੍ਰੋਗ੍ਰਾਮਰਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀਆਂ ਸਨ।
ਅਸੈਂਬਲੀ ਦਾ ਮਜ਼ਬੂਤ ਦਲੀਲ ਸੀ: "ਮੈਂ ਹਮੇਸ਼ਾਂ ਹੱਥ ਨਾਲ ਇਸਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹਾਂ।" ਸ਼ੁਰੂਆਤੀ ਸਕੈਪਟਿਕਸ ਇਹ ਮੰਨਦਾ ਸੀ ਕਿ ਉੱਚ-ਸਤ੍ਹਾ ਭਾਸ਼ਾ ਲੰਬਾ ਅਤੇ ਬਰਬਾਦਕ ਹੋਵੇਗੀ।
Backus ਦੀ ਟੀਮ ਨੇ ਉਸ ਸਕੈਪਟਿਸਿਜ਼ਮ ਨੂੰ ਉਤਪਾਦ ਦੀ ਲੋੜ ਵਾਂਗ ਲਿਆ: ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਕੋਈ ਸੁਵਿਧਾ ਨਹੀਂ ਸੀ; ਇਹ ਇੱਕ ਪ੍ਰਮਾਣ ਸੀ ਕਿ abstraction ਦਾ ਮਤਲਬ ਪ੍ਰਦਰਸ਼ਨ ਛੱਡ ਦੇਣਾ ਨਹੀਂ।
ਜਦੋਂ ਸ਼ਬਦ ਫੈਲਿਆ ਕਿ FORTRAN ਪ੍ਰੋਗਰਾਮ ਕਈ ਹਕੀਕਤੀ ਵਰਕਲੋਡ ਲਈ ਹੱਥ-ਲਿਖੀ ਅਸੈਂਬਲੀ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰ ਸਕਦੇ ਨੇ, ਤਾਂ ਗ੍ਰਹਿਣਯੋਗਤਾ ਤੇਜ਼ ਹੋ ਗਈ। ਕੰਪਾਇਲਰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸਾਥੀ ਜਿਹਾ ਬਣ ਗਿਆ: ਨਿਰਦੇਸ਼ ਸਪੱਸ਼ਟ ਲਿਖੋ, ਕੰਪਾਇਲਰ ਵਿਸਥਾਰ ਸੰਭਾਲੇ, ਅਤੇ ਫਿਰ ਵੀ ਹਾਰਡਵੇਅਰ ਦੀ ਕਦਰ ਕੀਤੀ ਜਾਵੇ।
FORTRAN ਸਿਰਫ਼ "ਸੋਹਣਾ" ਨਹੀਂ ਸੀ—ਇਸਨੇ ਕੁਝ ਪ੍ਰਯੋਗਕਾਰੀ ਵਿਚਾਰ ਪੇਸ਼ ਕੀਤੇ ਜੋ ਵਿਗਿਆਨੀਆਂ ਅਤੇ ਇੰਜੀਨੀਅਰਾਂ ਦੇ ਰੋਜ਼ਾਨਾ ਕੰਮ ਨਾਲ ਮਿਲਦੇ ਸਨ: ਇੱਕ ਗਣਨਾ ਨੂੰ ਦੁਹਰਾਉਣਾ, ਇੱਕ ਤਰੀਕੇ ਨੂੰ ਮੁੜ-ਵਰਤੋਂ ਕਰਨਾ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਨੰਬਰਾਂ ਨੂੰ ਇੱਕ ਸੁਸਪੱਠ ਢਾਂਚੇ ਵਿੱਚ ਰੱਖਣਾ।
ਵਿਗਿਆਨਕ ਪ੍ਰੋਗ੍ਰਾਮ ਭਰਪੂਰ "ਇਹ N ਵਾਰੀ ਕਰੋ" ਵਾਲੇ ਕੰਮਾਂ ਨਾਲ ਭਰੇ ਹੁੰਦੇ ਹਨ: ਮਾਪਾਂ ਨੂੰ ਜੋੜਨਾ, ਸਮੇਂ ਦੀ ਕਦਮ-ਕਦਮ ਘੁੰਮਣਾ, ਇੱਕ ਹੱਲ ਵੱਲ ਇਤਰਾਟ ਕਰਨਾ, ਜਾਂ ਬਹੁਤ ਸਾਰੀਆਂ ਡੇਟਾ-ਪੌਇੰਟਾਂ 'ਤੇ ਇੱਕੋ ਹੀ ਸੁਤਰ ਲਾਗੂ ਕਰਨਾ। ਅਸੈਂਬਲੀ ਵਿੱਚ, ਦੁਹਰਾਈ ਅਕਸਰ ਹੱਥ-ਲਿਖੀ ਜੰਪ ਲોજਿਕ ਹੁੰਦੀ—ਗਲਤ ਹੋਣਾ ਆਸਾਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪੜ੍ਹਨ ਵਿੱਚ ਮੁਸ਼ਕਲ।
FORTRAN ਦਾ DO ਲੂਪ ਉਦੇਸ਼ ਨੂੰ ਸਪੱਸ਼ਟ ਬਣਾਂਦਾ:
SUM = 0.0
DO 10 I = 1, 100
SUM = SUM + X(I)
10 CONTINUE
ਅਗਰ ਤੁਸੀਂ ਇਕੱਠੇ ਕਈ ਜੰਪ ਅਤੇ ਕਾਊਂਟਰਾਂ ਨੂੰ ਹੱਥ-ਹੱਥ ਸੰਭਾਲਣ ਦੇ ਬਜਾਏ, ਤਦ ਤੁਸੀਂ ਰੇਂਜ ਦੱਸ ਕੇ ਸੁਤਰ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹੋ।
ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮ ਮੁੜ-ਮੁੜ ਵਾਪਰਦਾ ਹੈ: ਮੈਟ੍ਰਿਕਸ ਗੁਣਾਕ, ਯੂਨਿਟ ਰੂਪਾਂਤਰ, ਪਿਆਣੋਮੀਅਲ ਮੁੱਲ, ਮਿਆਰੀ ਡੇਟਾ ਫਾਰਮੈਟ ਪੜ੍ਹਨਾ। ਸਬਰੁਟੀਨ ਇੱਕ ਭਰੋਸੇਯੋਗ ਰੀਟੀਨ ਇਕਵਾਰ ਲਿਖ ਕੇ ਕਈ ਥਾਂ ਤੋਂ ਬੁਲਾਉਣ ਦਿੰਦੇ ਹਨ। ਇਹ ਕਾਪੀ-ਪੇਸਟ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਘਟਾਉਂਦਾ—ਜੋ ਅਕਸਰ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕੇ ਨਾਲ ਗਲਤੀਆਂ ਫੈਲਾਉਂਦਾ ਹੈ।
ਸਾਰਥਕ ਤੌਰ 'ਤੇ, ਸਬਰੁਟੀਨਾਂ ਵੱਡੇ ਪ੍ਰੋਗ੍ਰਾਮ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਣ ਦੀ ਪ੍ਰੇਰਣਾ ਦਿੰਦੀਆਂ ਹਨ ਜੋ ਲੋਕ ਵੇਖ ਸਕਦੇ, ਟੈਸਟ ਕਰ ਸਕਦੇ ਅਤੇ ਸੁਧਾਰ ਸਕਦੇ ਹਨ।
ਮਾਪ, ਵੇਕਟਰ, ਟੇਬਲ, ਗਰਿਡ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਵਿਗਿਆਨਕ ਕੰਪਿਊਟਿੰਗ ਦਾ ਕੇਂਦਰ ਹਨ। ਐਰੇਜ਼ ਪ੍ਰੋਗ੍ਰਾਮਰ ਨੂੰ ਉਹ ਢਾਂਚਾ ਸਿੱਧਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਨਾਕਿ ਕਈ ਵੱਖ-ਵੱਖ ਵੇਰੀਏਬਲਾਂ ਜਾਂ ਮੈਨੂਅਲ ਐਡਰੈੱਸ ਗਣਿਤ ਨਾਲ ਜੂਝਣਾ ਪੈਂਦਾ।
ਅਸੈਂਬਲੀ ਭਰਪੂਰ ਕੰਟਰੋਲ ਫਲੋ ਬਹੁਤ ਸਾਰੇ ਸ਼ਰਤੀਆਂ ਅਤੇ ਅਨਸ਼ਰਤ ਜੰਪਾਂ 'ਤੇ ਨਿਰਭਰ ਸੀ। ਇੱਕ ਗਲਤ ਲੇਬਲ ਨਤੀਜੇ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਸੀ। ਲੂਪਾਂ ਅਤੇ ਨਾਮਵਾਲੀਆਂ ਸਬਰੁਟੀਨਾਂ ਵਰਗੇ ਸੰਰਚਿਤ ਨਿਰਦੇਸ਼ ਦੇ ਕੇ, FORTRAN ਨੇ ਘੁੰਮਾਉ-ਭਰਿਆ ਜੰਪ ਲਾਜ਼ਮੀ ਘਟਾ ਦਿੱਤਾ—ਜੋ ਪ੍ਰੋਗ੍ਰਾਮਾਂ ਨੂੰ ਵਧੇਰੇ ਜਾਂਚਯੋਗ ਅਤੇ ਬਦਲਾਅ-ਸਹਿਣਸ਼ੀਲ ਬਣਾਉਂਦਾ ਹੈ।
FORTRAN ਸਿਰਫ਼ ਲੈਬ ਦਾ ਇੱਕ ਚਿੱਠਾ ਵਿਚਾਰ ਨਹੀਂ ਰਹਿ ਗਿਆ—ਇਹ ਵਿਆਪੀ ਤੌਰ 'ਤੇ ਕਾਮਯਾਬ ਹੋਇਆ ਕਿਉਂਕਿ ਇਹ ਉਹਨਾਂ ਲੋਕਾਂ ਵੱਲੋਂ ਵਰਤਿਆ ਗਿਆ ਜੋ ਮਹਿੰਗੇ, ਸਮੇਂ-ਸੰਵੇਦਨਸ਼ੀਲ مسئਲਿਆਂ ਨੂੰ ਹੱਲ ਕਰ ਰਹੇ ਸਨ। ਇੱਕ ਭਾਸ਼ਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦੀ ਹੈ (ਅਜੇ ਪ੍ਰਭਾਵਸ਼ালী) ਬਿਨਾਂ ਦੈਨੀਕ ਕੰਮ ਬਦਲੇ; FORTRAN ਨੇ ਦੈਨੀਕ ਕੰਮ ਬਦਲ ਦਿੱਤੇ ਕਿਉਂਕਿ ਟੀਮਾਂ ਨੇ ਇਸ 'ਤੇ ਅਸਲੀ ਸਮਾਂ ਅਤੇ ਬਜਟ ਨਿਵੇਸ਼ ਕਰਨ ਲਈ ਭਰੋਸਾ ਕੀਤਾ।
ਪਹਿਲੇ ਅਪਣਾਅਕਰਤਾ ਉਹ ਗਰੁੱਪ ਸਨ ਜੋ ਗਣਨਾ 'ਤੇ ਤਿਆਰ ਰਹਿੰਦੇ ਸਨ: ਏਅਰੋਸਪੇਸ ਪ੍ਰੋਗਰਾਮ, ਫਿਜ਼ਿਕਸ ਲੈਬ, ਮੌਸਮ ਅਤੇ ਜਲਵਾਇਆ ਵਿਗਿਆਨ, ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿਭਾਗ। ਇਹ ਟੋਏਟ ਉਦਾਹਰਣ ਨਹੀਂ ਸਨ। ਇਹ ਉਹ ਵਰਕਲੋਡ ਸਨ ਜਿੱਥੇ ਕੁਝ ਪ੍ਰਗਤੀ ਪ੍ਰੋਡਕਟੀਵਿਟੀ ਵਿੱਚ ਵਾਧਾ ਜ਼ਿਆਦਾ ਪ੍ਰਯੋਗਾਂ, ਵਧੇਰੇ ਡਿਜ਼ਾਈਨ ਚੱਕਰਾਂ ਅਤੇ ਹੱਥ-ਤੁੱਟ ਅਸੈਂਬਲੀ ਵਿੱਚ ਛੁਪੇ ਗਲਤੀਆਂ ਘਟਾਉਂਦਾ ਸੀ।
FORTRAN ਖਾਸ ਤੌਰ 'ਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਬੈਠੀ ਕਿਉਂਕਿ ਇਸ ਦੀਆਂ ਮੁਖ ਫੀਚਰਾਂ ਸਮੱਸਿਆਵਾਂ ਦੀ ਆਕਾਰ-ਰੂਪ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਸਨ: ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਗਰਿਡ ਲਈ ਐਰੇਜ਼, ਦੁਹਰਾਈ ਲਈ ਲੂਪ, ਅਤੇ ਗਣਿਤ-ਭਰਪੂਰ ਕੋਡ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਲਈ ਸਬਰੁਟੀਨ।
ਅਸੈਂਬਲੀ ਪ੍ਰੋਗ੍ਰਾਮ ਮਸ਼ੀਨ-ਖਾਸ ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੇ ਹੁੰਦੇ ਸਨ ਕਿ ਬਾਹਰੀ ਵਿਅਕਤੀ ਲਈ ਉਹ ਪੜ੍ਹਨ ਜਾਂ ਸੋਧਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਸੀ। FORTRAN ਨੇ ਜਾਦੂ-ਤਰੀਕੇ ਨਾਲ ਪੋਰਟੇਬਿਲਿਟੀ ਨਹੀਂ ਦਿੱਤੀ, ਪਰ ਇਸਨੂੰ ਸਮਝਣਾ ਆਸਾਨ ਕਰ ਦਿੱਤਾ। ਇਸ ਨਾਲ ਕੋਡ ਨੂੰ ਇੱਕ ਸੰਸਥਾ ਵਿੱਚ—ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸੰਸਥਾਵਾਂ ਵਿੱਚ—ਸਾਂਝਾ ਕਰਨਾ ਵਾਸਤਵ ਵਿੱਚ ਪ੍ਰਯੋਗਯੋਗ ਬਣ ਗਿਆ, ਬਿਨਾਂ ਹਰ ਵਾਰੀ ਮੂਲ ਲੇਖਕ ਨੂੰ ਹਰ ਵੇਰਵਾ "ਅਨੁਵਾਦ" ਕਰਨ ਦੀ ਲੋੜ ਪਈ।
ਜਦੋਂ ਪ੍ਰੋਗ੍ਰਾਮਰ ਉੱਚ-ਸਤ੍ਹਾ 'ਤੇ ਗਣਨਾਵਾਂ ਦਰਸਾ ਸਕਦੇ ਸਨ, ਤਾਂ ਭਰੋਸੇਯੋਗ ਰੁਟੀਨਾਂ ਦੀ ਲਾਇਬ੍ਰੇਰੀ ਰੱਖਣਾ ਤਰਕਸੰਗਤ ਹੋ ਗਿਆ। ਟੀਮਾਂ ਸੰਖਿਆਤਮਕ ਢੰਗ, ਇਨਪੁੱਟ/ਆਊਟਪੁੱਟ ਪੈਟਰਨ ਅਤੇ ਡੋਮੇਨ-ਖਾਸ ਗਣਨਾਵਾਂ ਨੂੰ ਘੱਟ ਡਰ ਨਾਲ ਦੁਹਰਾਉਣ ਲੱਗੀਆਂ। ਇਹ ਬਦਲਾਅ—ਕੋਡ ਨੂੰ ਇੱਕ ਸੰਪਤੀ ਵਜੋਂ ਦੇਖਣਾ ਜੋ ਰੱਖਿਆ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ—ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਇੱਕ ਇਕਲ-ਕਾਰੀ ਹੂੰਰ ਤੋਂ ਦੁਹਰਾਉਣਯੋਗ ਕੰਮ ਵੱਲ ਲੈ ਗਿਆ।
FORTRAN ਸਿਰਫ਼ ਇੱਕ ਮਸ਼ੀਨ ਲਈ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਆਸਾਨ ਨਹੀਂ ਬਣਾਈ। ਇਸਨੇ ਇਹ ਉਮੀਦ ਬਣਾ ਦਿੱਤੀ ਕਿ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਕੰਪਾਇਲਰ ਕੀ ਕਰ ਸਕਦੇ ਹਨ—ਉਹ ਵੀ ਇੱਕ ਐਸੇ ਸਮੇਂ ਵਿੱਚ ਜਦੋਂ ਇਹ ਦੋਹਾਂ ਵਿਚਾਰਾਂ ਹਾਲੇ ਵੀ ਵਿਵਾਦਿਤ ਸਨ।
FORTRAN ਦੀ ਕਾਮਯਾਬੀ ਤੋਂ ਮਿਲਣ ਵਾਲੀ ਇੱਕ ਮੁੱਖ ਸਿੱਖਿਆ ਇਹ ਸੀ ਕਿ ਭਾਸ਼ਾ ਡਿਜ਼ਾਈਨ ਅਤੇ ਕੰਪਾਇਲਰ ਡਿਜ਼ਾਈਨ ਅਟੱਲ ਹਨ। ਸ਼ੁਰੂਆਤੀ ਆਲੋਚਕਾਂ ਸਿਰਫ਼ "ਇੰਗਲਿਸ਼-ਜਿਹਾ" ਕੋਡ ਦੇ ਸੰਦੇਹ ਹੀ ਨਹੀਂ ਕਰ ਰਹੇ ਸਨ; ਉਹ ਇਸ ਤੇ ਵੀ ਸਕੰਦੇ ਸਨ ਕਿ ਕੰਪਾਇਲਰ ਇਸਨੂੰ ਤਰਕਸੰਗਤ ਮਸ਼ੀਨ ਨਿਰਦੇਸ਼ਾਂ ਵਿੱਚ ਬਦਲ ਸਕੇਗਾ। FORTRAN ਟੀਮ ਦਾ ਜਵਾਬ—ਕੰਪਾਇਲੇਸ਼ਨ ਅਤੇ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ 'ਤੇ ਭਾਰੀ ਨਿਵੇਸ਼—ਬਾਅਦ ਦੀਆਂ ਕਈ ਭਾਸ਼ਾਵੀ ਯੋਜਨਾਵਾਂ ਵਿੱਚ ਗੂੰਜਦਾ ਰਿਹਾ।
ਅੱਜ ਤੁਸੀਂ ਇਹ ਵਿਚਾਰ ਕਈ ਪ੍ਰਾਜੈਕਟਾਂ ਵਿਚ ਵੇਖਦੇ ਹੋ: ਵਧੀਆ ਕੰਪਾਇਲਰ ਤਕਨੀਕਾਂ ਬਿਹਤਰ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਅਨਲੌਕ ਕਰਦੀਆਂ ਹਨ: ਸੁਰੱਖਿਅਤ ਅਬਸਟਰੈਕਸ਼ਨ, ਸਪੱਸ਼ਟ ਸਿੰਟੈਕਸ ਅਤੇ ਉੱਚ ਉਤਪਾਦਕਤਾ ਬਿਨਾਂ ਪ੍ਰਦਰਸ਼ਨ ਛੱਡੇ।
FORTRAN ਨੇ ਇਹ ਨਾਰਮ ਕੀਤਾ ਕਿ ਕੰਪਾਇਲਰ ਨੂੰ ਮੁਕਾਬਲੇਯੋਗ ਕੋਡ ਉਤਪੰਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਸੰਖਿਆਤਮਕ ਵਰਕਲੋਡ ਲਈ। ਹਰ ਬਾਅਦ ਦੀ ਭਾਸ਼ਾ ਇਸੇ ਲਕਸ਼ ਨੂੰ ਨਹੀਂ ਲੈਂਦੀ, ਪਰ ਆਮ ਅਨੁਭਵ ਬਦਲ ਗਿਆ: ਉੱਚ-ਸਤ੍ਹਾ ਦਾ ਮਤਲਬ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਧੀਮਾ ਨਹੀਂ।
ਇਸ ਨਾਲ ਕੰਪਾਇਲਰ ਰਿਸਰਚ ਅਤੇ ਅਭਿਆਸ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਤਕਨੀਕਾਂ (ਲੂਪ ਵਿਸ਼ਲੇਸ਼ਣ, ਗਣਨਾਵਾਂ ਦਾ ਮੁੜ-ਬੰਨ੍ਹ, ਰਜਿਸਟਰ ਪ੍ਰਬੰਧਨ ਆਦਿ) ਵੱਲ ਸਫ਼ਰ ਕੀਤਾ ਜੋ ਅਗਲੇ ਦਹਾਕਿਆਂ ਵਿੱਚ ਕੰਪਾਇਲਰ ਬਣਾਉਣ ਦੇ ਮਿਆਰੀ ਵਿਸ਼ਿਆਂ ਬਣ ਗਏ।
ਸ਼ੁਰੂਆਤੀ FORTRAN IBM ਹਾਰਡਵੇਅਰ ਨਾਲ ਭੇੜਿਆ ਸੀ, ਅਤੇ ਤੁਰੰਤ ਪੋਰਟੇਬਿਲਿਟੀ ਮੁੱਖ ਵਿਕਰੀ-ਬਿੰਦੂ ਨਹੀਂ ਸੀ। ਪਰ ਜਿਵੇਂ-जਿਵੇਂ FORTRAN ਵੱਖ-ਵੱਖ ਸੰਸਥਾਵਾਂ ਅਤੇ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਫੈਲਿਆ, ਵਿਗਿਆਨਕ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਲਾਗਤ ਸਪੱਸ਼ਟ ਹੋ ਗਈ। ਸਮੇਂ ਦੇ ਨਾਲ, ਇਤਿਹਾਸਕ ਰੂਪ ਵਿੱਚ FORTRAN ਨੂੰ ਇੱਕ ਮੁੱਖ ਤਾਕਤ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜਿਸਨੇ ਉਦਯੋਗ ਨੂੰ ਭਾਸ਼ਾ-ਮਿਆਰ ਪੱਖ ਵੱਲ ਧੱਕਿਆ।
ਨਤੀਜਾ ਤੁਰੰਤ ਨਹੀਂ ਸੀ, ਅਤੇ ਪੂਰਾ ਨਾ ਵੀ, ਪਰ ਇਸਨੇ ਇੱਕ ਪ੍ਰੇਸੈਡੈਂਟ ਸੈੱਟ ਕੀਤਾ: ਜੇ ਕੋਈ ਭਾਸ਼ਾ ਇੱਕ ਸਿੰਗਲ ਵੈਂਡਰ ਜਾਂ ਮਸ਼ੀਨ ਜਨਰੇਸ਼ਨ ਤੋਂ ਵੱਧ ਜ਼ਿੰਦਾ ਰਹਿਣੀ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਇੱਕ ਸਥਿਰ ਪਰਿਭਾਸ਼ਾ ਚਾਹੀਦੀ ਹੈ, ਸਿਰਫ਼ ਚੰਗੇ ਇੰਪਲੀਮੇੰਟੇਸ਼ਨਾਂ ਦੀ ਨਹੀਂ।
FORTRAN ਨੇ ਇੱਕ ਦਰਦਨਾਕ ਸਮੱਸਿਆ ਹੱਲ ਕੀਤੀ—ਜਟਿਲ ਗਣਨਾਵਾਂ ਨੂੰ ਅਸੈਂਬਲੀ ਵਿੱਚ ਡੁੱਬਣ ਤੋਂ ਬਚਾ ਲਿਆ—ਪਰ ਇਸਨੇ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ "ਆਸਾਨ" ਨਹੀਂ ਕਰ ਦਿੱਤੀ। ਸ਼ੁਰੂਆਤੀ ਯੂਜ਼ਰਾਂ ਨੇ ਪਾਇਆ ਕਿ ਇੱਕ ਉੱਚ-ਸਤ੍ਹਾ ਭਾਸ਼ਾ ਇੱਕ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰ ਸਕਦੀ ਹੈ ਪਰ ਨਵੇਂ ਮੁੱਦੇ ਉਪਜ ਸਕਦੇ ਹਨ।
FORTRAN ਦੀ ਤੇਜ਼ੀ ਦੀ ਖਿਆਤੀ ਨਾਲ trade-offs ਸਨ। ਕੋਡ ਅਕਸਰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਲਿਖਿਆ ਜਾਂਦਾ ਸੀ ਜੋ ਕੰਪਾਇਲਰ ਅਪਟੀਮਾਈਜ਼ ਕਰ ਸਕਦਾ ਸੀ, ਨਾਂ ਕਿ ਸਭ ਤੋਂ ਪੜ੍ਹਨਯੋਗ ਤਰੀਕੇ ਨਾਲ।
ਇੱਕ ਉਦਾਹਰਣ: ਇੱਕ ਵਿਗਿਆਨੀ ਸਪਸ਼ਟ ਗਣਨਾ ਨੂੰ ਕਈ ਕਦਮਾਂ ਵਿੱਚ ਵੰਡ ਸਕਦਾ ਸੀ ਜਾਂ ਬਿਆਨ ਬਦਲ ਸਕਦਾ ਸੀ ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿ ਉਹ ਤੇਜ਼ ਚੱਲੇ। ਨਤੀਜੇ ਵਜੋਂ ਕੋਡ ਚੰਗਾ ਚੱਲਦਾ ਪਰ ਨਵੇਂ ਸਾਥੀ ਲਈ ਪੜ੍ਹਨ ਵਿੱਚ ਔਖਾ ਹੋ ਸਕਦਾ।
FORTRAN ਨੂੰ ਅਕਸਰ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਕੋਡ ਮੂਵ ਕਰਨ ਲਈ ਸਹਾਇਕ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਸ਼ੁਰੂਆਤ ਵਿੱਚ "ਪੋਰਟੇਬਿਲ" ਇੱਕ ਤਾਰ-ਚਿੰਨ੍ਹ ਨਾਲ ਸੀ। ਕੰਪਿਊਟਰਾਂ ਵਿੱਚ ਵੱਖਰਾ-ਵੱਖਰਾ ਵਰਡ ਸਾਈਜ਼, ਇਨਪੁੱਟ/ਆਊਟਪੁੱਟ ਡਿਵਾਈਸ ਅਤੇ ਨੰਬਰਾਂ ਦਾ ਵਿਵਹਾਰ ਹੁੰਦਾ ਸੀ। ਟੀਮਾਂ ਕਈ ਵਾਰੀ ਇੱਕੋ ਪ੍ਰੋਗ੍ਰਾਮ ਦੀ ਵੱਖ-ਵੱਖ ਸੰਸਕਰਣਾਂ ਰੱਖਦੀਆਂ ਜਾਂ ਮਸ਼ੀਨ-ਖਾਸ ਹਿੱਸੇ ਸ਼ਾਮਲ ਕਰਦੀਆਂ ਜਦੋਂ ਉਨ੍ਹਾਂ ਨੂੰ ਖਾਸ ਫੀਚਰ ਚਾਹੀਦੇ।
FORTRAN ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਵਿਗਿਆਨਕ ਕੰਪਿਊਟਿੰਗ ਲਈ ਬਣੀ ਸੀ, ਹਰ ਕੁਝ ਲਈ ਨਹੀਂ। ਇਸ ਨੇ ਵੱਡੇ ਕੋਡਬੇਸਾਂ ਨੂੰ ਸੰਚਾਲਿਤ ਕਰਨ ਦੇ ਮਜ਼ਬੂਤ ਟੂਲ ਅਜੇ ਨਾ ਦਿੱਤੇ ਜੋ ਬਾਅਦ ਦੀਆਂ ਭਾਸ਼ਾਵਾਂ ਦਿੰਦੀਆਂ। ਡੀਬੱਗਿੰਗ ਅਜੇ ਵੀ ਧੀਮੀ ਅਤੇ ਨਿਰਾਸ਼ਾਜਨਕ ਹੋ ਸਕਦੀ ਸੀ, ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਕੰਪਾਇਲਰ ਕਈ ਵਾਰੀ cryptic ਗਲਤੀ ਸੁਨੇਹੇ ਦਿੰਦੇ ਸਨ ਜੋ "ਫਿਰ ਤੋਂ ਅਸੈਂਬਲੀ" ਵਰਗੀ ਮਹਿਸੂਸ ਹੁੰਦੀ।
FORTRAN ਨੇ ਉਹ بحث ਚੁੱਕਿਆ ਜੋ ਅਧੁਨਿਕ ਟੀਮਾਂ ਅਜੇ ਵੀ ਕਰਦੀਆਂ ਹਨ: ਕੀ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਅਧਿਕਤਮ ਗਤੀ ਪ੍ਰਾਥਮਿਕਤਾ ਦینی ਚਾਹੀਦੀ ਹੈ, ਜਾਂ ਸਪੱਸ਼ਟ ਕੋਡ ਅਤੇ ਉੱਚ-ਸਤ੍ਹਾ ਅਬਸਟਰੈਕਸ਼ਨ? ਸਭ ਤੋਂ ਵਧੀਆ ਜਵਾਬ ਸੰਦਰਭ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਸੀ—ਅਤੇ ਅਜ ਵੀ ਕਰਦਾ ਹੈ।
FORTRAN ਨੇ ਸਾਬਤ ਕੀਤਾ ਕਿ ਅਬਸਟਰੈਕਸ਼ਨ ਲਾਭਕਾਰੀ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਵੀ ਸਿਖਾਇਆ ਕਿ ਹਰ ਸੁਵਿਧਾ ਦੀਆਂ ਸਰਹੱਦਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਉਹ ਕਿਹੜੇ trade-offs ਸਹੇ ਸਕਦੀਆਂ ਹਨ।
FORTRAN ਅ成功 ਇਸ ਲਈ ਸੀ ਕਿ ਇਸਨੇ ਡਿਵੈਲਪਰ ਸਮੇਂ ਨੂੰ ਹੀ ਦੁਰਲਭ ਸਰੋਤ ਮੰਨਿਆ। Backus ਅਤੇ IBM ਨੇ ਸਿਰਫ਼ ਸੋਹਣਾ ਸਿੰਟੈਕਸ ਨਹੀਂ ਬਣਾਇਆ—they proved that investing in tools can unlock whole new classes of software.
FORTRAN ਦਾ ਮੁੱਦਾ ਸਧਾਰਣ ਸੀ: ਘੱਟ ਰੇਖਾਵਾਂ ਲਿਖੋ, ਜ਼ਿਆਦਾ ਸਹੀ ਪ੍ਰੋਗਰਾਮ ਸ਼ਿਪ ਕਰੋ। ਆਧੁਨਿਕ ਟੀਮ ਇਹ ਗੱਲ ਵਾਰ-ਵਾਰ ਸਿੱਖਦੀਆਂ ਹਨ। ਇੱਕ ਹਫਤਾ ਜੋ ਤੁਸੀਂ ਇਕ ਸੁਰੱਖਿਅਤ API, ਸਪੱਸ਼ਟ ਮੋਡੀਊਲ ਬਾਉਂਡਰੀ, ਜਾਂ ਇੱਕ ਸਕ੍ਰਿਪਟ ਜੋ ਦਰਦੀ ਕੰਮ ਆਟੋਮੇਟ ਕਰਦਾ, ਨੂੰ ਬਣਾਉਣ ਵਿੱਚ ਲਾਂਦੇ ਹੋ, ਅਕਸਰ ਉਹ ਹੱਟ ਕੇ 3% ਕਿਸੇ ਹਾਰਟ-ਲੂਪ ਤੋਂ ਜ਼ਿਆਦਾ ਮੁੱਲ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ।
ਲੋਕ FORTRAN 'ਤੇ ਸੰਦੇਹ ਕਰਦੇ ਸਨ ਕਿਉਂਕਿ ਅਬਸਟਰੈਕਸ਼ਨ ਅਸਲ ਵਿੱਚ ਨਿਯੰਤਰਣ ਛੱਡਣ ਵਰਗੀ ਲੱਗਦੀ ਹੈ। ਕੰਪਾਇਲਰ ਨੇ ਇਹ ਭਰੋਸਾ ਜੀਤਿਆ ਕਿਉਂਕਿ ਇਸਨੇ ਹੱਥ-ਲਿਖੀ ਅਸੈਂਬਲੀ ਵਰਗੇ ਤੇਜ਼ ਨਤੀਜੇ ਦਿੱਤੇ।
ਆਧੁਨਿਕ ਸੰਸਰਪਣਾਂ 'ਚ ਇਹ ਭਰੋਸਾ ਫ੍ਰੇਮਵਰਕ, ਮੈਨੇਜਡ ਰਨਟਾਈਮ ਅਤੇ ਕਲਾਉਡ ਸੇਵਾਵਾਂ 'ਤੇ ਹੈ—ਪਰ ਇਹ ਭਰੋਸਾ ਕਮਾਇਆ ਜਾਂਦਾ ਹੈ, ਫਿਕਰ ਕੀਤਾ ਨਹੀਂ ਜਾਂਦਾ। ਜਦੋਂ ਕੋਈ ਅਬਸਟਰੈਕਸ਼ਨ ਫੇਲ ਹੁੰਦਾ, ਟੀਮਾਂ "ਮੈਨੂਅਲ ਮੋਡ" ਵਿੱਚ ਵਾਪਸ ਚਲੀ ਜਾਂਦੀਆਂ ਹਨ। ਇਲਾਜ ਉਹੀ ਹੈ ਜੋ 1957 ਵਿੱਚ ਸੀ: ਮਾਪ ਵਾਲੀ ਪ੍ਰਦਰਸ਼ਨ, ਪਾਰਦਰਸ਼ੀ ਵਰਤਾਰਾ, ਅਤੇ ਪੇਸ਼ਗੋਈ ਤਰੀਕੇ ਜਿਥੇ ਗਲਤੀ ਹੋ ਸਕਦੀ ਹੈ।
FORTRAN ਸਿਰਫ਼ ਇੱਕ ਭਾਸ਼ਾ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਕੰਪਾਇਲਰ ਉਝੇਜ਼ਨ ਵੀ ਸੀ ਜਿਸਨੇ ਉੱਚ-ਸਤ੍ਹਾ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਪੈਮਾਨੇ 'ਤੇ ਵਿਆਪਕ ਬਣਾ ਦਿੱਤਾ। ਅੱਜ ਦੇ ਸਮਾਨ ਵੱਲੋਂ:
ਇੱਕ ਨਵੀਂ ਸ਼੍ਰੇਣੀ ਵੀ ਹੈ ਜੋ ਅਸਲ FORTRAN ਦੀ ਸੱਦੀ ਦੁਹਰਾਉਂਦੀ ਹੈ: ਆਟੋਮੇਸ਼ਨ ਜੋ ਮਨੁੱਖੀ ਕੰਮ ਨੂੰ "ਕੰਪਾਇਲਰ-ਵਾਂਗ" ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਲੈਂਦਾ ਹੈ। ਚੈਟ ਰਾਹੀਂ ਟੀਮਾਂ ਨੂੰ ਜੋ ਕਿ ਉਹ ਚਾਹੁੰਦੇ ਹਨ ਦੱਸ ਕੇ, ਇਕ ਏਜੰਟ-ਅਧਾਰਤ ਪ੍ਰਣਾਲੀ ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਂਦੀ ਅਤੇ ਦੌਰਾਨ ਬਦਲਦੀ ਹੈ—ਇਸਦੀ ਉਦਾਹਰਣ ਵਜੋਂ Koder.ai ਵਰਗੇ vibe-coding ਪਲੇਟਫਾਰਮ ਹਨ। ਵਰਤੋਂ ਵਿੱਚ, ਯੋਜਨਾ ਮੋਡ, ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਉਹੀ ਗੱਲ ਦਿੰਦੇ ਹਨ ਜੋ FORTRAN ਨੇ ਸਾਬਤ ਕਰਨੀ ਸੀ: ਉੱਚ-ਸਤ੍ਹਾ ਮਨੋਰਥ, ਬਿਨਾਂ ਓਪਰੇਸ਼ਨਲ ਨਿਯੰਤਰਣ ਗਵਾਏ।
ਚੰਗੇ ਟੂਲ ਸਿਰਫ਼ ਬੱਗ ਨਹੀਂ ਰੋਕਦੇ; ਉਹ ਉਮੀਦ ਵਧਾਉਂਦੇ ਹਨ। ਉਹ ਟੀਮਾਂ ਨੂੰ ਛੋਟੀ ਟੀਮਾਂ ਨਾਲ ਵੱਡੇ ਸਿਸਟਮ ਬਣਾਉਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
Backus ਦਾ ਦਾਇਮੀ ਪ੍ਰਭਾਵ ਇਹ ਵਿਚਾਰ ਹੈ ਕਿ ਸੌਫਟਵੇਅਰ ਤਦੋਂ ਸਕੇਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ "ਕੋਡ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਪ੍ਰਣਾਲੀ"—ਭਾਸ਼ਾ, ਕੰਪਾਇਲਰ ਅਤੇ ਅਭਿਆਸ—ਲੋਕਾਂ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਕੰਮ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇ। ਇਹ ਅਜ ਵੀ ਆਧੁਨਿਕ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਲਈ ਖੇਡ-ਪੁਸਤਕ ਹੈ।
FORTRAN ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿਉਂਕਿ ਇਹ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਦੇ ਮਨੁੱਖੀ ਖਰਚੇ ਨੂੰ ਘਟਾਉਂਦਾ ਸੀ ਬਿਨਾਂ ਵੱਡੇ ਰਨਟਾਈਮ ਜਨਹਾਨੀ ਦੇ।
ਕੰਪਾਇਲਰ ਇੱਕ ਐਸਾ ਪ੍ਰੋਗਰਾਮ ਹੈ ਜੋ ਮਨੁੱਖ-ਲਿਖਿਆ ਸਰੋਤਕੋਡ ਲੈ ਕੇ ਉਸ ਮਸ਼ੀਨ ਦੀ ਨੀਵੀਂ-ਸਤ੍ਹਾ ਦੇ ਹੁਕਮਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਉਹ ਚੱਲੇਗੀ।
FORTRAN ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਕੰਪਾਇਲਰ ਨੂੰ ਦੋ ਕੰਮ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਨੇ ਪਏ:
ਮੁੱਖ ਆਰੋਪ ਸੀ ਕਿ ਉੱਚ-ਸਤ੍ਹਾ ਭਾਸ਼ਾਵਾਂ ਧੀਮੀ ਹੋਣਗੀਆਂ। ਜੇ compiled FORTRAN ਅਸੈਂਬਲੀ ਨਾਲੋਂ ਕਾਫੀ ਧੀਮਾ ਚੱਲਦਾ, ਤਾਂ ਵਿਗਿਆਨਕ ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਕੋਲ ਇਹ ਸੁਵਿਧਾ ਜਾਇਜ਼ ਨਹੀਂ ਰਹਿੰਦੀ।
FORTRAN ਦੀ ਗ੍ਰਹਿਣਯੋਗਤਾ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਸੀ ਕਿ ਕੰਪਾਇਲਰ ਹੋਣਯੋਗ ਮਸ਼ੀਨ ਕੋਡ ਪੈਦਾ ਕਰ ਸਕਦਾ ਸੀ ਜੋ ਮੁਕਾਬਲੇਯੋਗ ਹੋਵੇ—ਸਿਰਫ਼ “ਚੱਲਣ ਵਾਲਾ” ਨਹੀਂ।
ਆਮ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਣ ਵਾਲੀਆਂ ਸੋਧਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਸਨ:
ਇਹ ਉਹੀ ਤਰਕੀਬਾਂ ਸਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਅਸੈਂਬਲੀ ਪ੍ਰੋਗ੍ਰਾਮਰ ਨਿਰਭਰ ਕਰਦੇ ਸਨ—ਹੁਣ ਇਹ ਆਪਣੇ ਆਪ ਹੋ ਰਹੀਆਂ ਸਨ।
FORTRAN ਨੇ ਅਹੰਕਾਰਪੂਰਕ ਤਰੀਕੇ ਨਾਲ ਦੋ-ਤਿੰਨ ਆਮ ਪੈਟਰਨ ਸਹੂਲਤ ਬਣਾਏ:
DO ਲੂਪਾਂ ਨੇ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਗਣਨਾਵਾਂ ਨੂੰ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਦਰਸਾਉਣਾ ਆਸਾਨ ਕੀਤਾ।ਇਨ੍ਹਾਂ ਫੀਚਰਾਂ ਨੇ “ਰਹੱਸਮਈ ਜੰਪਾਂ” ਅਤੇ ਮੈਨੂਅਲ ਐਡਰੈੱਸ ਹਿਸਾਬ ਨੂੰ ਘਟਾ ਦਿੱਤਾ—ਅਕਸਰ ਅਸੈਂਬਲੀ ਵਿੱਚ ਆਮ ਬਗਾਂ ਦੇ ਸਰੋਤ।
ਤੁਰੰਤ ਨਹੀਂ, ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾ ਨਹੀਂ। ਸ਼ੁਰੂ ਵਿੱਚ FORTRAN ਨੇ ਮਨੁੱਖੀ ਦੁਹਰਾਈ ਘਟਾਈ ਅਤੇ ਪੜ੍ਹਨਯੋਗਤਾ ਬਹਾਲ ਕੀਤੀ, ਪਰ ਪੋਰਟੇਬਿਲਿਟੀ ਉੱਤੇ ਹਮੇਸ਼ਾ ਸੀਮਾ ਰਹੀ:
ਸਮੇਂ ਨਾਲ, ਵਿਗਿਆਨਕ ਕੋਡ ਨੂੰ ਮਸ਼ੀਨ ਤੋਂ ਮਸ਼ੀਨ ਲਿਜਾਣ ਦੀ ਲੋੜ ਨੇ ਭਾਸ਼ਾ-ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਦੀ ਦਿਸ਼ਾ ਦਿੱਤੀ।
ਇੱਕ ਵੱਡਾ ਬਦਲਾਅ ਇਹ ਸੀ ਕਿ ਪ੍ਰੋਗ੍ਰਾਮ ਲਿਖਣ ਦੀ ਲਾਗਤ ਘੱਟ ਹੋਣ ਨਾਲ ਟੀਮਾਂ ਵੱਡੀਆਂ, ਲੰਬੀਆਂ ਸਿਮੂਲੇਸ਼ਨ ਜਾਂ ਵਧੇਰੇ ਇਤਰਾਟਿਵ ਪ੍ਰੋਜੈਕਟ ਆਜ਼ਮਾਉਣ ਲੱਗੀਆਂ।
ਇਸ ਤਰ੍ਹਾਂ, FORTRAN ਨੇ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਇੱਕ ਇੱਕ-ਵਾਰੀ ਕਿਸਮ ਦੇ ਹُنਰ ਤੋਂ ਇੱਕ ਉਦਯੋਗ ਵਾਲੀ ਪ੍ਰਕ੍ਰਿਆ ਵੱਲ ਧੱਕਿਆ।
ਕਈ ਤਰ੍ਹਾਂ ਦੀਆਂ ਕਮੀਆਂ ਅਤੇ ਆਲੋਚਨਾਵਾਂ ਸਾਹਮਣੇ ਆਈਆਂ:
ਇਸ ਤਰ੍ਹਾਂ, FORTRAN ਨੇ ਇੱਕ ਵੱਡੀ ਬਨਟੇ ਲਈ ਰਾਹ ਖੋਲ੍ਹਿਆ ਪਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਟਾਈਆਂ ਨਹੀਂ।
ਮੁੱਖ ਸਿੱਖਿਆ ਇਹ ਹੈ ਕਿ ਟੂਲਿੰਗ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨਾ ਕੰਮ ਨੂੰ ਸਕੇਲ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਵਿਵਹਾਰਕ ਸਲਾਹ:
ਹਾਂ, FORTRAN ਅਜੇ ਵੀ ਵਿਗਿਆਨਕ ਅਤੇ ਸੰਖਿਆਤਮਕ ਕੰਪਿਊਟਿੰਗ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਸਥਾਨਾਂ 'ਤੇ ਜਿੱਥੇ ਪੱਕੀਆਂ, ਸਾਲਾਂ-ਪੁਰਾਣੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਚੈੱਕ ਕੀਤੇ ਹੋਏ ਕੋਡਬੇਸ ਮੌਜੂਦ ਹਨ।
ਸ਼ੁਰੂਆਤ ਲਈ ਸੁਝਾਅ: