ਕਿਵੇਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਆਪਣੇ ਯੁੱਗ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ

ਭਾਸ਼ਾਵਾਂ ਕਿਉਂ ਇਸ ਤਰ੍ਹਾਂ ਦੇਖਣੀਆਂ ਜਾਂਦੀਆਂ ਹਨ

ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਸਿਧੀਆਂ “ਵਧੀਆ” ਜਾਂ “ਖ਼ਰਾਬ” ਵਰਜਨ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਉਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਲਈ ਡਿਜ਼ਾਇਨ ਜਵਾਬ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਉਸ ਖਾਸ ਸਮੇਂ ਕੰਪਿਊਟਿੰਗ ਵਿੱਚ ਹੱਲ ਕਰਨੀ ਲੋੜੀਂਦੀਆਂ ਸਨ।

“ਭਾਸ਼ਾ ਡਿਜ਼ਾਇਨ” ਵਿੱਚ ਅਸਲ ਚੀਜ਼ ਕੀ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ

ਜਦੋਂ ਅਸੀਂ ਭਾਸ਼ਾ ਡਿਜ਼ਾਇਨ ਦੀ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ सिरਫ਼ ਕੋਡ ਦੀ ਦਿਖਾਵਟ ਬਾਰੇ ਨਹੀਂ ਗੱਲ ਕਰ ਰਹੇ। ਇੱਕ ਭਾਸ਼ਾ ਫੈਸਲਿਆਂ ਦਾ ਇੱਕ ਪੈਕੇਜ ਹੁੰਦੀ ਹੈ ਜਿਵੇਂ:

• ਸਿੰਟੈਕਸ: ਵਿਚਾਰ ਪ੍ਰਗਟ ਕਰਨ ਦਾ ਤਰੀਕਾ (ਕੀ ਵਰਡ, ਪੁੰਚੂਏਸ਼ਨ, ਪੜ੍ਹਨਯੋਗਤਾ)
• ਟਾਈਪਸ: ਕੀ ਮੂਲਾਂ ਨੂੰ ਕਿਸੇ ਕਿਸਮ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ (ਅਤੇ ਭਾਸ਼ਾ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿੰਨੀ ਕੜੀ ਜਾਂਚਦੀ ਹੈ)
• ਮੇਮੋਰੀ ਮਾਡਲ: ਮੇਮੋਰੀ ਦੀ ਜੋ ਸੁਧੀ ਹੈ, ਕਿਸ ਨੇ ਮੇਮੋਰੀ ਮੈਨੇਜ ਕਰਨੀ ਹੈ ਅਤੇ ਕੀ ਸੁਰੱਖਿਆ ਗਾਰੰਟੀਜ਼ ਹਨ
• ਐਕਜ਼ਿਕਯੂਸ਼ਨ ਮਾਡਲ: ਕੈਂਪਾਈਲ ਜਾਂ ਇੰਟਰਪ੍ਰਾਈਟ, ਰਨਟਾਈਮ ਵਿਹਾਰ, ਪ੍ਰਦਰਸ਼ਨ-ਸਬੰਧੀ ਤਿਆਗ
• ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ + ਟੂਲਿੰਗ: ਪੈਕੇਜ, ਬਿਲਡ ਸਿਸਟਮ, ਡੀਬੱਗਰ, ਫਾਰਮੈਟਰ ਅਤੇ ਟੀਮਾਂ ਸੋਫਟਵੇਅਰ ਕਿਵੇਂ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ

ਇਹ ਫੈਸਲੇ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਯੁੱਗ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦੇ ਆਸਪਾਸ ਗ੍ਰੁੱਪ ਹੋ ਜਾਂਦੇ ਹਨ: ਸੀਮਿਤ ਹਾਰਡਵੇਅਰ, ਮਹਿੰਗਾ ਕੰਪਿਊਟ ਸਮਾਂ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਫੀਚਰਾਂ ਦੀ ਘਾਟ, ਜਾਂ (ਬਾਅਦ ਵਿੱਚ) ਵੱਡੀਆਂ ਟੀਮਾਂ, ਗਲੋਬਲ ਨੈਟਵਰਕ ਅਤੇ ਸੁਰੱਖਿਆ ਖ਼ਤਰਿਆਂ ਦੀ ਉਭਾਰ।

ਮੁੱਖ ਵਿਚਾਰ

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

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

ਅੱਜ ਟੂਲ ਚੁਣਦੇ ਸਮੇਂ ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ

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

ਜਲਦੀ ਵਾਲੀਆਂ ਕੰਪਿਊਟਿੰਗ ਸੀਮਾਵਾਂ ਜਿਨ੍ਹਾਂ ਨੇ ਸਭ ਕੁਝ ਰੂਪ ਦਿੱਤਾ

ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਸ਼ੈਲੀ ਤੋਂ ਘੱਟ ਤੇ ਫ਼ਿਜ਼ਿਕਸ ਅਤੇ ਬਜਟ ਤੋਂ ਵੱਧ ਪ੍ਰਭਾਵਿਤ ਹੋਈਆਂ। ਮਸ਼ੀਨਾਂ ਕੋਲ ਘੱਟ ਮੇਮੋਰੀ ਹੁੰਦੀ ਸੀ, ਸਟੋਰੇਜ ਕਮੀ ਸੀ, ਅਤੇ CPUs ਆਧੁਨਿਕ ਮਿਆਰਿਆਂ ਦੇ ਮੁਕਾਬਲੇ ਧੀਮੇ ਸਨ। ਇਸ ਨੇ ਲਗਾਤਾਰ ਤਿਆਗ ਮਜ਼ਹਬ ਕੀਤੇ: ਹਰ ਇਕ ਵਾਧੂ ਫੀਚਰ, ਹਰ ਲੰਮਾ ਨਿਰਦੇਸ਼ ਅਤੇ ਹਰ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਦੀ ਲਾਗਤ ਆਸਲ ਵਿੱਚ ਮਹਿਸੂਸ ਹੁੰਦੀ ਸੀ।

ਛੋਟੀ ਮੇਮੋਰੀ, ਮਹਿੰਗੇ ਸਾਈਕਲ

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

ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਲੰਮੇ ਫੀਡਬੈਕ ਲੂਪ

ਕਈ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਗਰਾਮ ਬੈਚਾਂ ਵਿੱਚ ਚਲਾਏ ਜਾਂਦੇ ਸਨ। ਤੁਸੀਂ ਇੱਕ ਜ਼ਾਬ ਤਿਆਰ ਕਰਦੇ (ਅਕਸਰ ਪੰਚ ਕਾਰਡ ਰਾਹੀਂ), ਇਸਨੂੰ ਸਮਰ্পਿਤ ਕਰਦੇ ਅਤੇ ਇੰਤਜ਼ਾਰ ਕਰਦੇ। ਜੇ ਕੁਝ ਗਲਤ ਹੋਇਆ, ਤਾਂ ਤੁਸੀਂ ਬਹੁਤ ਦੇਰ ਬਾਦ ਹੀ ਪਤਾ ਲਗਦਾ—ਜਦੋਂ ਜਾਬ ਮੁਕੰਮਲ ਜਾਂ ਫੇਲ ਹੋ ਜਾਂਦਾ।

ਉਹ ਲੰਬਾ ਫੀਡਬੈਕ ਚੱਕਰ ਇਹ ਬਦਲ ਦਿੰਦਾ ਕਿ ਕੀ ਮਹੱਤਵਪੂਰਨ ਸੀ:

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

ਕਿਉਂ ਪੜ੍ਹਨਯੋਗਤਾ ਅਤੇ ਐਰਰ ਮੈਸੇਜ ਪ੍ਰਾਥਮਿਕਤਾ ਨਹੀਂ ਸਨ

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

ਵਿਗਿਆਨ ਅਤੇ ਗਣਿਤ ਨੇ ਸ਼ੁਰੂਆਤੀ ਫੀਚਰਾਂ ਚਲਾਏ

ਸ਼ੁਰੂਆਤੀ ਕੰਪਿਊਟਿੰਗ ਦੀ ਬਹੁਤ ਮੰਗ ਵਿਗਿਆਨਕ ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮ ਤੋਂ ਆਈ: ਗਣਨਾ, ਸਿਮੂਲੇਸ਼ਨ ਅਤੇ ਨੰਮੀਰੀਕਲ ਵਿਧੀਆਂ। ਇਸੀ ਲਈ ਸ਼ੁਰੂਆਤੀ ਭਾਸ਼ਾਵਾਂ ਦੇ ਫੀਚਰ ਅਕਸਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਅਖ਼ਤੀਅਤ, ਐਰੇ ਅਤੇ ਫਾਰਮੂਲਾ ਪ੍ਰਗਟਾਵੇ 'ਤੇ ਕੇਂਦਰਿਤ ਸਨ—ਜੋ ਹਾਰਡਵੇਅਰ ਨਾਲ ਅਤੇ ਵਿਗਿਆਨੀਆਂ ਦੇ ਕਾਗਜ਼ 'ਤੇ ਕੰਮ ਕਰਨ ਦੇ ਢੰਗ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮਿਲਦੇ।

FORTRAN, COBOL ਅਤੇ ਖਾਸ ਕੰਮਾਂ ਲਈ ਬਣੀ ਭਾਸ਼ਾਵਾਂ

ਕੁਝ ਸ਼ੁਰੂਆਤੀ ਭਾਸ਼ਾਵਾਂ ਸਭ-ਉਦੇਸ਼ੀ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦੀਆਂ ਸਨ। ਉਹ ਇੱਕ ਤੰਗ ਸਮੱਸਿਆ ਵਰਗੀ ਕੰਮ ਨੂੰ ਬਹੁਤ ਚੰਗੀ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਨ ਲਈ ਬਣਾਈਆਂ ਗਈਆਂ—ਕਿਉਂਕਿ ਕੰਪਿਊਟਰ ਮਹਿੰਗੇ ਸਨ, ਸਮਾਂ ਘੱਟ ਸੀ, ਅਤੇ "ਹਰ ਚੀਜ਼ ਲਈ ਠੀਕ" ਆਮ ਤੌਰ 'ਤੇ "ਕਿਸੇ ਚੀਜ਼ ਵਿੱਚ ਬੇਹਤਰੀਨ" ਨਹੀਂ ਹੁੰਦਾ।

FORTRAN: ਨੰਬਰੀ ਕੰਮ, ਗਤੀ ਅਤੇ ਵਿਗਿਆਨੀ ਦਾ ਕੰਮ

FORTRAN (FORmula TRANslation) ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ ਵਿਗਿਆਨਕ ਕੰਪਿਊਟਿੰਗ ਲਈ ਬਣਾਈ ਗਈ ਸੀ। ਇਸ ਦਾ ਮੁੱਖ ਵਾਅਦਾ ਪ੍ਰੈਕਟਿਕਲ ਸੀ: ਵਿਗਿਆਨੀਆਂ ਨੂੰ ਹੱਥੋਂ-ਹੱਥ اسمبلی ਲਿਖਣ ਤੋਂ ਬਿਨਾਂ ਗਣਿਤ-ਭਾਰੀ ਪ੍ਰੋਗਰਾਮ ਲਿਖਣ ਦੇਣਾ।

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

COBOL: ਕਾਰੋਬਾਰੀ ਰਿਕਾਰਡ, ਪੜ੍ਹਨਯੋਗਤਾ ਅਤੇ ਰਿਪੋਰਟਿੰਗ

COBOL ਵੱਖਰੇ ਖੇਤਰ ਲਈ ਤਿਆਰ ਕੀਤੀ ਗਈ ਸੀ: ਸਰਕਾਰਾਂ, ਬੈਂਕਾਂ, ਇਨਸ਼ორੈਂਸ, ਪੇਰੋਲ ਅਤੇ ਇਨਵੈਂਟਰੀ—ਇਹ "ਰਿਕਾਰਡ ਅਤੇ ਰਿਪੋਰਟ" ਵਾਲੇ ਕੰਮ ਹਨ। ਇਹਨਾਂ ਵਿੱਚ-ਸਧਾਰਨ ਡੇਟਾ, ਨਿਰਧਾਰਤ ਵਰਕਫਲੋ ਅਤੇ ਬਹੁਤ ਸਾਰੀ ਆਡਿਟਿੰਗ ਹੁੰਦੀ ਹੈ।

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

"ਡੋਮੇਨ ਦੇ ਨੇੜੇ" ਹੋਣ ਦਾ ਅਰਥ ਕੀ ਹੈ

ਦੋਹਾਂ ਭਾਸ਼ਾਵਾਂ ਇੱਕ ਡਿਜ਼ਾਇਨ ਸਿਧਾਂਤ ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਜੋ ਅਜੇ ਵੀ ਮਾਇਨੇ ਰੱਖਦਾ: ਭਾਸ਼ਾ ਦੀ ਸ਼ਬਦਾਵਲੀ ਕੰਮ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੋਵੇ।

FORTRAN ਗਣਿਤ ਅਤੇ ਗਣਨਾ ਵਿਚ ਗੱਲ ਕਰਦੀ ਹੈ। COBOL ਰਿਕਾਰਡ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿਚ ਗੱਲ ਕਰਦੀ ਹੈ। ਉਨ੍ਹਾਂ ਦੀ ਲੋਕਪ੍ਰਿਯਤਾ ਉਸ ਸਮੇਂ ਦੀਆਂ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ: ਪ੍ਰਯੋਗਾਤਮਕ ਅਜ਼ਮਾ-ਪੜਤਾਲ ਨਹੀਂ, ਪਰ ਅਸਲ ਵਰਕਲੋਡਜ਼ ਨੂੰ ਪ੍ਰਭਾਵੀ ਤਰੀਕੇ ਨਾਲ ਮੁਕੰਮਲ ਕਰਨਾ—ਚਾਹੇ ਉਹ ਜ਼ਿਆਦਾ ਤੇਜ਼ ਨੰਬਰੀ ਗਣਨਾ ਹੋਵੇ ਜਾਂ ਵਪਾਰਕ ਡੇਟਾ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਦੀ ਸਪਸ਼ਟ ਹੇਠਾਂਦਾਰੀਆਂ।

ਸਿਸਟਮ ਯੁੱਗ: ਪੋਰਟੇਬਿਲਟੀ ਅਤੇ ਕੰਟਰੋਲ (C, Unix)

1960s ਦੇ ਅਖੀਰ ਅਤੇ 1970s ਵਿੱਚ, ਕੰਪਿਊਟਰ ਸਸਤੇ ਅਤੇ ਆਮ ਹੋ ਰਹੇ ਸਨ—ਪਰ ਫਿਰ ਵੀ ਇੱਕ-ਦੂਜੇ ਤੋਂ ਕਾਫ਼ੀ ਵੱਖਰੇ ਸਨ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਮਸ਼ੀਨ ਲਈ ਸੋਫਟਵੇਅਰ ਲਿਖਦੇ, ਤਾਂ ਉਸ ਨੂੰ ਦੂਜੇ 'ਤੇ ਪੋਰਟ ਕਰਨ ਲਈ ਅਕਸਰ ਵੱਡੇ ਹਿੱਸਿਆਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪੈਂਦਾ।

اسمبلی ਦਾ ਦਰਦ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਉੱਪਰ ਲੈ ਗਿਆ

ਕਾਫੀ ਮਹੱਤਵਪੂਰਕ ਸਾਫਟਵੇਅਰ اسمبلی ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਸੀ, ਜਿਸ ਨਾਲ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਕੰਟਰੋਲ ਮਿਲਦਾ ਸੀ, ਪਰ ਇਸਦਾ ਬਹੁਤ ਮਹਿੰਗਾ ਕੀਮਤ ਸੀ: ਹਰ CPU ਦਾ ਆਪਣਾ ਨਿਰਦੇਸ਼ ਸੈੱਟ ਹੋਦਾ, ਕੋਡ ਪੜ੍ਹਨ ਲਈ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਅਤੇ ਛੋਟੇ ਬਦਲਾਅ ਵੀ ਕਈ ਦਿਨ ਦੇ ਧਿਆਨ ਵਾਲੇ ਸੰਪਾਦਨਾਂ 'ਚ ਬਦਲ ਸਕਦੇ। ਉਸ ਦਰਦ ਨੇ ਇੱਕ ਐਸੀ ਭਾਸ਼ਾ ਦੀ ਮੰਗ ਪੈਦਾ ਕੀਤੀ ਜੋ ਹਾਲੇ ਵੀ "ਮੀਟਲ ਦੇ ਨੇੜੇ" ਮਹਿਸੂਸ ਹੋਵੇ, ਪਰ ਤੁਹਾਨੂੰ ਇੱਕ ਪ੍ਰੋਸੈਸਰ 'ਤੇ ਫਸਾ ਨਾ ਕਰੇ।

C ਦਾ ਮੁੱਖ ਮਕਸਦ: ਪੋਰਟੇਬਲ ਸਿਸਟਮ ਕੋਡ

C ਇੱਕ ਪ੍ਰਯੋਗਕ ਸਹਿਮਤੀ ਵਜੋਂ ਉਭਰੀ। ਇਹ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਤੇ ਟੂਲ—ਖ਼ਾਸ ਕਰਕੇ Unix—ਲਿਖਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤੀ ਗਈ ਸੀ, ਪਰ ਹਦ ਤੱਕ ਹਰ ਹਾਰਡਵੇਅਰ 'ਤੇ ਕੰਪਾਈਲ ਹੋ ਸਕਦੀ। C ਨੇ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਦਿੱਤਾ:

• ਇੱਕ ਸਧਾਰਨ, ਛੋਟੇ ਫੀਚਰ ਸੈੱਟ ਜੋ ਕਈ ਮਸ਼ੀਨਾਂ 'ਤੇ ਕੰਪਾਈਲ ਕੀਤਾ ਜਾ ਸਕਦਾ
• ਪੌਇੰਟਰਾਂ ਰਾਹੀਂ ਸਿੱਧਾ ਮੇਮੋਰੀ ਤੱਕ ਐਕਸਸ
• ਹਰੇਕ ਵਿਸਥਾਰ ਲਈ ਮੁੜ اسمبلی 'ਤੇ ਵਾਪਸ ਨਾ ਜਾਣ ਦਾ ਸਮਰੱਥ

Unix ਨੂੰ C ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਣਾ ਇੱਕ ਪ੍ਰਸਿੱਧ ਸਬੂਤ ਹੈ: ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨਵੇਂ ਹਾਰਡਵੇਅਰ 'ਤੇ ਜ਼ਿਆਦਾ ਆਸਾਨੀ ਨਾਲ ਚੱਲ ਸਕਦਾ ਸੀ ਬਜਾਏ ਅਸੈਂਬਲੀ-ਕੇਵਲ ਸਿਸਟਮ ਦੇ।

ਕਿਉਂ ਮੈਨੂਅਲ ਮੇਮੋਰੀ ਮੈਨੇਜਮੈਂਟ ਠੀਕ ਸੀ

C ਆਪ ਤੋਂ ਉਮੀਦ ਕਰਦਾ ਸੀ ਕਿ ਤੁਸੀਂ ਮੇਮੋਰੀ ਮੈਨੇਜ ਕਰੋ (ਇਸਨੂੰ allocate ਕਰੋ, free ਕਰੋ, ਗਲਤੀਆਂ ਤੋਂ ਬਚੋ)। ਇਹ ਹੁਣ ਖ਼ਤਰਨਾਕ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਉਸ ਯੁੱਗ ਦੀਆਂ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਸੀ। ਮਸ਼ੀਨਾਂ ਕੋਲ ਸੀਮਿਤ ਸਰੋਤ ਸਨ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਭਰੋਸੇਯੋਗ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਲੋੜ ਸੀ, ਅਤੇ ਪ੍ਰੋਗਰਾਮਰ ਅਕਸਰ ਹਾਰਡਵੇਅਰ ਦੇ ਨੇੜੇ ਕੰਮ ਕਰਦੇ—ਕਈ ਵਾਰ ਉਹ ਅਜੇ ਵੀ ਉਹ ਮੁਹੰਦੀ ਮੈਮੋਰੀ ਲੇਆਉਟ ਜਾਣਦੇ ਸਨ।

ਦਾਇਮੀ ਤਿਆਗ

C ਨੇ ਗਤੀ ਅਤੇ ਕੰਟਰੋਲ ਲਈ ਅਪਟੀਮਾਈਜ਼ ਕੀਤਾ, ਅਤੇ ਇਹ ਨਤੀਜੇ ਦਿੱਤੇ। ਕੀਮਤ ਸੀ ਸੁਰੱਖਿਆ ਅਤੇ ਆਸਾਨੀ: ਬਫਰ ਓਵਰਫਲੋ, ਕਰੈਸ਼ ਅਤੇ ਸੁਬਤਲ ਬੱਗ ਆਮ ਖ਼ਤਰੇ ਬਣ ਗਏ। ਉਸ ਯੁੱਗ ਵਿੱਚ ਇਹ ਖ਼ਤਰੇ ਅਕਸਰ ਪੋਰਟੇਬਿਲਟੀ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਇੱਕ ਸਵੀਕਾਰ ਯੋਗ ਲਾਗਤ ਮੰਨੀ ਜਾਂਦੀ ਸੀ।

ਵੱਡੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਰੱਖ-ਰਖਾਅਯੋਗ ਬਣਾਉਣਾ: ਸੰਰਚਨਾ ਅਤੇ ਟਾਈਪ

ਜਿਵੇਂ ਜਿਵੇਂ ਪ੍ਰੋਗਰਾਮ ਛੋਟੇ, ਇਕ-ਉਦੇਸ਼ੀ ਯੂਟਿਲਿਟੀਆਂ ਤੋਂ ਲੈ ਕੇ ਐਸੇ ਉਤਪਾਦ ਬਣ ਗਏ ਜਿਹੜੇ ਵਪਾਰ ਚਲਾਉਂਦੇ, ਇੱਕ ਨਵੀਂ ਸਮੱਸਿਆ ਉਭਰੀ: ਸਿਰਫ਼ "ਕੀ ਇਸ ਨੂੰ ਚਲਾ ਸਕਦੇ ਹਾਂ?" ਨਹੀਂ, ਬਲਕਿ "ਕੀ ਅਸੀਂ ਇਸਨੂੰ ਸਾਲਾਂ ਤੱਕ ਚਲਦੇ ਰੱਖ ਸਕਦੇ ਹਾਂ?" ਪਹਿਲੇ ਕੋਡ ਅਕਸਰ patching ਅਤੇ goto ਨਾਲ ਵਿਕसित ਹੁੰਦੇ, ਜਿਸ ਨਾਲ "ਸਪੈਗੇਟੀ ਕੋਡ" ਬਣ ਜਾਂਦਾ—ਪੜ੍ਹਨ, ਟੈਸਟ ਜਾਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ।

ਸੰਰਚਿਤ ਪ੍ਰੋਗਰਾਮਿੰਗ ਕੀ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਸੀ

ਸੰਰਚਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਇੱਕ ਸਾਦਾ ਵਿਚਾਰ ਮੁਹੱਈਆ ਕਰਵਾਉਂਦੀ ਸੀ: ਕੋਡ ਦਾ ਇੱਕ ਸਾਫ਼ ਆਕਾਰ ਹੋਣਾ ਚਾਹੀਦਾ। ਬਦਲੇ ਵਿਚਾਰਾਂ ਨੂੰ arbitrary ਲਾਈਨਾਂ 'ਤੇ ਛਾਲ ਮਾਰਣ ਦੀ ਬਜਾਏ, ਡਿਵੈਲਪਰਾਂ ਨੇ ਸੋਚ-ਸਮਝ ਕੇ ਨਿਰਧਾਰਤ ਬਣਾਉਟੀ ਇਕਾਈਆਂ ਵਰਤੀਆਂ—if/else, while, for, ਅਤੇ switch—ਤਾਂ ਜੋ ਕੰਟਰੋਲ ਫਲੋ ਪੇਸ਼ਗੀ ਹੋਵੇ।

ਇਹ ਪੇਸ਼ਗੋਈ ਮਹੱਤਵਪੂਰਕ ਸੀ ਕਿਉਂਕਿ ਡੀਬੱਗਿੰਗ ਜ਼ਿਆਦਤਰ "ਐਕਜ਼ਿਕਿਊਸ਼ਨ ਇਥੇ ਕਿਵੇਂ ਆਈ?" ਦਾ ਜਵਾਬ ਦੇਣ ਬਾਰੇ ਹੈ। ਜਦੋਂ ਫਲੋ ਸਾਫ਼ ਬਣਾਇਆ ਜਾਂਦਾ, ਤਾਂ ਕਮੀਆਂ ਘੱਟ ਛੁਪਦੀਆਂ ਹਨ।

ਟੀਮਾਂ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਕੋਡਬੇਸ ਦਾ ਉਭਾਰ

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

ਭਾਸ਼ਾਵਾਂ ਨੇ ਉਹਨਾਂ ਰੀਤੀ-ਰਿਵਾਜਾਂ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਕੇ ਜਵਾਬ ਦਿੱਤਾ ਜੋ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਯਾਦ ਧਾਰਣ ਤੋਂ ਬਾਹਰ ਸਕੇ: ਇਕਸਾਰ ਫੰਕਸ਼ਨ ਸੀਮਾਵਾਂ, ਸਾਫ਼ ਵੈਰੀਏਬਲ ਲਾਈਫਟਾਈਮ, ਅਤੇ ਕੋਡ ਨੂੰ ਵੱਖ-ਵੱਖ ਫਾਇਲਾਂ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਠੰਢੇ ਤਰੀਕੇ ਨਾਲ ਆਯੋਜਿਤ ਕਰਨ ਦੇ ਤਰੀਕੇ।

ਕਿਉਂ ਟਾਈਪ, ਮੋਡੀਊਲ ਅਤੇ ਸਕੋਪ ਦੀ ਕਿਸਮ ਮਹੱਤਵਪੂਰਨ ਹੋਈ

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

ਮੋਡੀਊਲ ਅਤੇ ਸਕੋਪ ਨੇ ਬਦਲਾਅ ਦੇ ਬਲਾਸਟ ਰੇਡੀਅਸ ਨੂੰ ਘਟਾਇਆ। ਵੇਰਵੇ ਗੋਪਨੀਯ ਰੱਖ ਕੇ ਅਤੇ ਸਿਰਫ਼ ਸਥਿਰ ਇੰਟਰਫੇਸ ਪ੍ਰਦਾਨ ਕਰਕੇ, ਟੀਮਾਂ ਇੰਟਰਨਲਾਂ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਪੂਰੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੇ।

ਕੰਪੋਜ਼ੀਸ਼ਨ ਨੂੰ ਸਮਰਥਨ ਦੇਣ ਵਾਲੇ ਡਿਜ਼ਾਇਨ ਚਲਾਂ

ਆਮ ਸੁਧਾਰਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਸੀ:

• ਛੋਟੇ, ਚੰਗੇ-ਨਾਂ ਵਾਲੇ ਫੰਕਸ਼ਨ ਜੋ ਇੱਕ ਕੰਮ ਕਰਦੇ
• ਲੈਕਸਿਕਲ ਸਕੋਪਿੰਗ ਤਾਂ ਜੋ ਵੈਰੀਏਬਲਾਂ ਦੇ ਦਰਮਿਆਨ ਗਲਤ ਇੰਟਰੈਕਸ਼ਨ ਨਾ ਹੋਣ
• ਚੰਗੀਆਂ ਕੰਪੋਜ਼ੀਸ਼ਨ ਪੈਟਰਨਜ਼ (ਫੰਕਸ਼ਨ/ਡੇਟਾ ਨੂੰ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਪਾਸ ਕਰਨਾ, ਗਲੋਬਲ ਸਟੇਟ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ)

ਇਹ ਸਭ ਬਦਲਾਅ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਅਜਿਹੇ ਕੋਡ ਵੱਲ ਘੁਮਾਉਂਦੇ ਜੋ ਪੜ੍ਹਨ, ਸਮੀਖਿਆ ਕਰਨ ਅਤੇ ਬੇਫ਼ਿਕਰ ਤਰੀਕੇ ਨਾਲ ਤਬਦੀਲ ਕਰਨ ਲਈ ਆਸਾਨ ਹੋਵੇ।

ਆਬਜੈਕਟ ਅਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼: OOP ਕਿਉਂ ਮੈਨਸਟ੍ਰੀਮ ਬਣੀ

ਆਬਜੈਕਟ-ਓਰੀਏਂਟਡ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ (OOP) ਇਸ ਲਈ "ਜਿੱਤ ਨਹੀਂ ਗਈ" ਕਿ ਇਹ ਇੱਕੱਲੀ ਚੰਗੀ ਵਿਚਾਰ ਸੀ—ਇਹ ਇਸ ਲਈ ਲਗਭਗ ਰਾਜ਼ੀ ਹੋ ਗਈ ਕਿ ਇਹ ਉਸ ਕੰਮ ਨਾਲ ਮਿਲਦੀ ਸੀ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀਆਂ ਸਨ: ਲੰਬੇ ਸਮੇਂ ਵਾਲਾ ਕਾਰੋਬਾਰੀ ਸੌਫਟਵੇਅਰ ਜੋ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਸੰਭਾਲਦੇ ਹਨ।

OOP ਦਾ ਵਾਅਦਾ ਕੀ ਸੀ

OOP ਇੱਕ ਸੁਥਰੀ ਕਹਾਣੀ ਦਿੰਦਾ ਸੀ ਜਟਿਲਤਾ ਲਈ: ਪ੍ਰੋਗਰਾਮ ਨੂੰ "ਆਬਜੈਕਟਾਂ" ਦੇ ਸੈੱਟ ਵਜੋਂ ਦਰਸਾਉ, ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਸਪਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।

ਐਨਕੈਪਸੁਲੇਸ਼ਨ (ਆੰਦਰੂਨੀ ਵੇਰਵਿਆਂ ਨੂੰ ਲੁਕਾਉਣਾ) ਅਕਸਰ ਗਲਤ ਤਰ੍ਹਾਂ ਟੁੱਟਣ ਤੋਂ ਰੋਕਣ ਦਾ ਪ੍ਰਾਇੋਗਿਕ ਤਰੀਕਾ ਲੱਗਿਆ। ਇਨਹੈਰੀਟੈਂਸ ਅਤੇ ਪੋਲਿਮਾਰਫ਼ਿਜ਼ਮ ਰੀਯੂਜ਼ ਦਾ ਵਾਅਦਾ ਕਰਦੇ: ਇੱਕ ਆਮ ਵਰਜਨ ਇਕ ਵਾਰੀ ਲਿਖੋ, ਬਾਦ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਬਣਾਓ, ਅਤੇ ਵੱਖ-ਵੱਖ ਇੰਪਲਿਮੈਂਟੇਸ਼ਨਾਂ ਨੂੰ ਇੱਕੋ ਇੰਟਰਫੇਸ ਵਿੱਚ ਪਲੱਗ ਕਰੋ।

GUI ਅਤੇ ਕਾਰੋਬਾਰਕ ਐਪਸ ਨੇ ਇਸਨੂੰ ਤੇਜ਼ ਕੀਤਾ

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

ਇਸੇ ਸਮੇਂ, ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਿਸਟਮ ਬੈਂਕਿੰਗ, ਇਨਸ਼ੋਰੈਂਸ, ਇਨਵੈਂਟਰੀ ਅਤੇ HR ਵਰਗੇ ਡੋਮੇਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਵਿਕਸਿਤ ਹੋਏ। ਇਹਾਂ ਮੁਹਾਂਗਾ-ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਕੋਡਬੇਸਾਂ ਨੂੰ ਪਹਿਲਾ ਮੰਤਵ ਹੋਣ ਕਰਕੇ ਢਾਂਚੇ, ਟੀਮ-ਸਹਿਯੋਗ ਅਤੇ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਵਿਕਾਸ ਦੀ ਕੀਮਤ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ। OOP ਨੇ ਇਕ ਸੰਗਠਨਾਤਮਕ ਲੋੜ ਨੂੰ ਫਿੱਟ ਕੀਤਾ: ਕੰਮ ਨੂੰ ਵਿਭਾਜਿਤ ਕਰੋ, ਵੱਖਰੀਆਂ ਟੀਮਾਂ ਨੂੰ ਮਾਲਕੀ ਹੱਕ ਦਿਓ, ਸੀਮਾਵਾਂ ਲੱਗੂ ਕਰੋ ਅਤੇ ਫੀਚਰ ਜੋੜਨ ਦੇ ਤਰੀਕੇ ਨੂੰ ਮਿਆਰ ਬਨਾਓ।

ਜਿੱਥੇ ਇਹ ਫਾਇਦਾ ਕਰਦਾ—ਅਤੇ ਜਿੱਥੇ ਇਹ ਉਲਝਾਉਂਦਾ

OOP ਉਤਮ ਹੈ ਜਦੋਂ ਇਹ ਸਥਿਰ ਸੀਮਾਵਾਂ ਅਤੇ ਰੀਯੂਜ਼ੇਬਲ ਕੰਪੋਨੈਂਟ ਬਣਾਉਂਦਾ। ਇਹ ਤਕਲੀਫ਼ਦਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਡਿਵੈਲਪਰ ਹਰ ਚੀਜ਼ ਨੂੰ ਓਵਰ-ਮਾਡਲ ਕਰਦੇ ਹਨ, ਡੀਪ ਕਲਾਸ ਹਾਇਰਾਰਕੀਜ਼ ਬਣ ਜਾਂਦੀਆਂ, "ਗਾਡ ਆਬਜੈਕਟ" ਬਣ ਜਾਂਦੇ ਜਾਂ ਪੈਟਰਨਸ ਮੁੱਖ ਤੌਰ 'ਤੇ ਫੈਸ਼ਨ ਕਾਰਨ ਵਰਤੇ ਜਾਂਦੇ। ਬਹੁਤ ਸਾਰੇ ਲੇਅਰਾਂ ਇੱਕ ਸਧਾਰਨ ਬਦਲਾਅ ਨੂੰ ਵੀ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਕਠਨ ਬਣਾ ਸਕਦੇ ਹਨ।

ਦਾਇਮੀ ਪ੍ਰਭਾਵ

ਇਹਨਾਂ ਭਾਸ਼ਾਵਾਂ ਨੇ ਪ੍ਰਭਾਵ ਛੱਡਿਆ: ਅਜੇ ਵੀ ਬਹੁਤੀਆਂ ਭਾਸ਼ਾਵਾਂ ਜੋ "ਸ਼ੁੱਧ OOP" ਨਹੀਂ ਹਨ, OOP ਦੀਆਂ ਸੁਵਿਧਾਵਾਂ ਨੂੰ ਆਪਣਾਇਆ—ਕਲਾਸ-ਨਮੂਨੇ, ਇੰਟਰਫੇਸ, ਐਕਸੈੱਸ ਮੋਡੀਫਾਇਰ ਅਤੇ ਡਿਜ਼ਾਇਨ ਪੈਟਰਨਸ। ਆਧੁਨਿਕ ਮੈਨਸਟ੍ਰੀਮ ਸਿੰਟੈਕਸ ਦਾ ਬਹੁਤ ਹਿੱਸਾ ਇਸ ਯੁੱਗ ਦੇ ਧਿਆਨ ਨਾਲ ਮਿਲਦਾ ਹੈ ਜਿਸ ਨੇ ਵੱਡੀਆਂ ਟੀਮਾਂ ਨੂੰ ਵੱਡੇ ਕੋਡਬੇਸਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਆਯੋਜਿਤ ਕਰਨ 'ਤੇ ਕੇਂਦਰ ਕੀਤਾ।

Java ਦਾ ਯੁੱਗ: ਪੋਰਟੇਬਿਲਟੀ, ਸੁਰੱਖਿਆ ਅਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਕੇਲ

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

JVM ਨੇ ਕੀ ਹੱਲ ਕੀਤਾ: ਮੈਨੇਜਡ ਰਨਟਾਈਮ ਨਾਲ ਪੋਰਟੇਬਿਲਟੀ

Java ਕਿਸੇ ਖਾਸ ਮਸ਼ੀਨ ਦੇ ਨਿਰਦੇਸ਼ਾਂ ਦਰਜੇ ਤੌਰ 'ਤੇ ਕੰਪਾਈਲ ਕਰਨ ਦੀ ਥਾਂ, ਬਾਈਟਕੋਡ ਤਿਆਰ ਕਰਦੀ ਜੋ Java Virtual Machine (JVM) 'ਤੇ ਚੱਲਦੀ ਹੈ। ਇਹ JVM ਕਾਰੋਬਾਰਾਂ ਲਈ "ਸਟੈਂਡਰਡ ਲੇਅਰ" ਬਣ ਗਿਆ: ਉਹੀ ਐਪਲੀਕੇਸ਼ਨ ਆਰਟੀਫੈਕਟ ਭੇਜੋ ਅਤੇ Windows, Linux ਜਾਂ ਵੱਡੇ Unix ਬਾਕਸਾਂ 'ਤੇ ਘੱਟ-ਬਦਲਾਅ ਨਾਲ ਚਲਾਓ।

ਇਹ "ਇੱਕ ਵਾਰੀ ਲਿਖੋ, ਕਈ ਥਾਵਾਂ ਚਲਾਓ" ਦਾ ਮੁੱਖ ਅਸੂਲ ਹੈ: ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਪਲੇਟਫਾਰਮ-ਖ਼ਾਸ ਕੁਇਰਕ ਨਾ ਹੋਣ, ਪਰ ਯਥਾਰਥਿਕ ਤਰੀਕੇ ਨਾਲ ਕਈ ਵਾਤਾਵਰਣਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨ ਦੀ ਲਾਗਤ ਅਤੇ ਖ਼ਤਰਾ ਘਟਾਉਂਦੀ ਹੈ।

ਉਤਪਾਦਕਤਾ ਦੇ ਸੁਰੱਖਿਆ ਡਿਫਾਲਟ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਫੇਲ੍ਹ ਘਟਾਉਂਦੇ

Java ਨੇ ਸੁਰੱਖਿਆ ਨੂੰ ਇੱਕ ਮੁੱਖ ਫੀਚਰ ਬਣਾਇਆ:

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

ਇਹ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਹਕੀਕਤ ਨਾਲ ਕਿਵੇਂ ਫਿੱਟ ਸੀ

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

ਤਿਆਗ: ਓਵਰਹੈਡ, ਟਿਊਨਿੰਗ, ਜਟਿਲਤਾ

Java ਦੇ ਫਾਇਦੇ ਮੁਫ਼ਤ ਨਹੀਂ। ਮੈਨੇਜਡ ਰਨਟਾਈਮ ਸਟਾਰਟਅੱਪ ਟਾਈਮ ਅਤੇ ਮੇਮੋਰੀ ਓਵਰਹੈਡ ਵਧਾਉਂਦਾ ਹੈ, ਅਤੇ ਗਾਰਬੇਜ ਕਲੇਕਸ਼ਨ ਨੂੰ ਸੇਟ ਕਰਨ ਨਾ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਲੇਟੇਂਸੀ ਵਾਧੇ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਸਮੇਂ ਨਾਲ, ਇਕੋਸਿਸਟਮ ਵਿੱਚ ਜਟਿਲਤਾ ਇਕੱਠੀ ਹੋ ਗਈ—ਫਰੇਮਵਰਕ ਹੋਸਟਿੰਗ, কনਫਿਗਰੇਸ਼ਨ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਮਾਡਲਾਂ ਨੇ ਵਿਸ਼ੇਸ਼ ਗਿਆਨ ਦੀ ਲੋੜ ਪੈਦਾ ਕੀਤੀ।

ਫਿਰ ਵੀ, ਕਈ ਸੰਗਠਨਾਂ ਲਈ ਇਹ ਸੌਦਾ ਕਾਬਿਲ-ਏ-ਕ਼ਬੂਲ ਸੀ: ਘੱਟ-ਲੈਵਲ ਫੇਲ੍ਹ, ਆਸਾਨ ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਡਿਪਲੋਇਮੈਂਟ ਅਤੇ ਇੱਕ ਸਾਂਝਾ ਰਨਟਾਈਮ ਜੋ ਕਾਰੋਬਾਰ ਅਤੇ ਕੋਡਬੇਸ ਦੀ ਵਾਧੂ ਦੇ ਨਾਲ ਸਕੇਲ ਕਰ ਸਕਦਾ।

ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਉਤਪਾਦਕਤਾ 'ਤੇ ਜ਼ੋਰ

1990s ਦੇ ਆਖਿਰ ਅਤੇ 2000s 'ਚ, ਕਈ ਟੀਮਾਂ ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨਹੀਂ ਲਿਖ ਰਹੀਆਂ ਸਨ—ਉਹ ਡੇਟਾਬੇਸ ਜੁੜਦੇ, ਵੈੱਬਸਾਈਟ ਬਣਾਉਂਦੇ ਅਤੇ ਅੰਦਰੂਨੀ ਵਰਕਫਲੋ ਆਟੋਮੇਟ ਕਰ ਰਹੀਆਂ ਸਨ। ਬੋਟਲਨੇਕ ਰੌ-ਸਪੀਡ ਨਹੀਂ ਰਹਿ ਗਈ; ਇਹ ਹੁਣ ਡਿਵੈਲਪਰ ਟਾਈਮ ਬਣ ਗਿਆ। ਤੇਜ਼ ਫੀਡਬੈਕ ਅਤੇ ਛੋਟੇ ਰਿਲੀਜ਼ ਚੱਕਰਾਂ ਨੇ "ਇਸਨੂੰ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹਾਂ?" ਨੂੰ ਪਹਿਲੀ ਪ੍ਰਾਥਮਿਕਤਾ ਬਣਾਇਆ।

ਤੇਜ਼ ਇਟਰੈਸ਼ਨ ਕਿਉਂ ਪਹਿਲਾਂ ਆ ਗਿਆ

ਵੈੱਬ ਐਪ ਦਿਨਾਂ ਵਿੱਚ ਵਿਕਸਿਤ ਹੁੰਦੇ। ਕਾਰੋਬਾਰ ਨਵੇਂ ਪੇਜ, ਨਵੇਂ ਰਿਪੋਰਟ, ਨਵੇਂ ਇੰਟਿਗਰੇਸ਼ਨ ਅਤੇ ਛੋਟੇ ਫਿਕਸ ਚਾਹੁੰਦੇ, ਬਿਨਾਂ ਪੂਰੇ ਕੰਪਾਈਲ–ਲਿੰਕ–ਡਿਪਲੋਇ ਪਾਈਪਲਾਈਨ ਦੇ। ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾਵਾਂ ਉਸ ਲਯ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ: ਫਾਇਲ ਸੋਧੋ, ਚਲਾਓ, ਨਤੀਜਾ ਵੇਖੋ।

ਇਸ ਨੇ ਇਹ ਵੀ ਬਦਲਿਆ ਕਿ ਕੌਣ ਸੌਫਟਵੇਅਰ ਬਣਾਉਂ ਸਕਦਾ। ਸਿਸਟਮ ਐਡਮਿਨਿਸਟਰੇਟਰ, ਵਿਸ਼ਲੇਸ਼ਕ ਅਤੇ ਛੋਟੀ ਟੀਮਾਂ ਉਪਯੋਗੀ ਟੂਲ ਸ਼ਿਪ ਕਰ ਸਕਦੀਆਂ ਬਿਨਾਂ ਗਹਿਰੀ ਮੇਮੋਰੀ ਮੈਨੇਜਮੈਂਟ ਜਾਂ ਬਿਲਡ ਸਿਸਟਮ ਦੀ ਸਮਝ ਦੇ।

ਡਾਇਨਾਮਿਕ ਟਾਈਪਿੰਗ ਅਤੇ "ਬੈਟਰੀਜ਼-ਇਨਕਲੂਡਿਡ" ਇਕੋਸਿਸਟਮ

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

• ਟੈਕਸਟ ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਫਾਇਲ ਹੈਂਡਲਿੰਗ
• HTTP, ਈਮੇਲ ਅਤੇ ਬੁਨਿਆਦੀ ਨੈਟਵਰਕਿੰਗ
• ਡੇਟਾਬੇਸ ਐਕਸੈਸ ਅਤੇ ਡੇਟਾ ਫਾਰਮੈਟ (CSV, JSON, XML)

ਉਹ "ਬੈਟਰੀਜ਼-ਇਨਕਲੂਡਿਡ" 접근 ਅਨੁਭਵ ਨੂੰ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਦਾ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਦਾ ਅਰਜਨਿਕ ਤੌਰ 'ਤੇ ਵਧਣਾ ਇੱਕ ਅਸਾਨ ਰਾਹ ਬਣਾਉਂਦਾ।

Python, Ruby, ਅਤੇ PHP ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਜਵਾਬ ਵਜੋਂ

Python ਆਟੋਮੇਸ਼ਨ ਅਤੇ ਜਨਰਲ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਲਈ ਇੱਕ ਵਿਚਕਾਰਲਾ ਵਿਕਲਪ ਬਣ ਗਿਆ, Ruby ਨੇ ਵੈੱਬ ਵਿਕਾਸ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ (ਖ਼ਾਸ ਕਰਕੇ ਫਰੇਮਵਰਕਾਂ ਰਾਹੀਂ), ਅਤੇ PHP ਸ਼ੁਰੂਆਤੀ ਸਰਵਰ-ਸਾਈਡ ਵੈੱਬ 'ਤੇ ਹावी ਹੋ ਗਿਆ ਕਿਉਂਕਿ ਇਸਨੂੰ ਸਧਾਰਨ ਤਰੀਕੇ ਨਾਲ ਸਿੱਧਾ ਪੇਜਾਂ ਵਿੱਚ ਐਮਬੈੱਡ ਕੀਤਾ ਅਤੇ ਕਿਤੇ ਵੀ ਡਿਪਲੋਇ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ।

ਤਿਆਗ: ਗਤੀ, ਰਨਟਾਈਮ ਐਰਰ ਅਤੇ ਸਕੇਲਿੰਗ ਅਭਿਆਸ

ਉਹੀ ਫੀਚਰ ਜੋ ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਉਤਪਾਦਕ ਬਣਾਉਂਦੇ ਸਨ, ਉਹਨਾਂ ਨੇ ਵੀ ਲਾਗਤ ਪੈਦਾ ਕੀਤੀ:

• ਕੰਪਾਈਲਡ ਭਾਸ਼ਾਵਾਂ ਨਾਲੋਂ ਧੀਮਾ ਐਗਜ਼ਿਕ੍ਯੂਸ਼ਨ
• ਜ਼ਿਆਦਾ ਰਨਟਾਈਮ ਤੇ ਖੋਜੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ
• ਸਕੇਲਿੰਗ ਲਈ ਨਿਯਮ-ਵਤੀ: ਟੈਸਟਿੰਗ, ਕੋਡ ਰਿਵਿਊ, ਲਿੰਟਰ ਅਤੇ ਰੀਤੀਆਂ

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

JavaScript ਅਤੇ ਬ੍ਰਾਉਜ਼ਰ-ਚਲਿਤ ਸੌਫਟਵੇਅਰ ਬੂਮ

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

ਅਜਿਹਾ ਪਲੇਟਫਾਰਮ ਜਿਸ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਲੱਗ

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

"ਹਰ ਥਾਂ" ਨੇ "ਪਰਫੈਕਟ" ਨੂੰ ਮਾਤ ਦਿੱਤੀ

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

ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਇਵੈਂਟ-ਚਲਿਤ

ਬ੍ਰਾਉਜ਼ਰ ਨੈਚਰਲੀ ਰੀਐਕਟਿਵ ਹੈ: ਯੂਜ਼ਰ ਕਲਿੱਕ ਕਰਦੇ ਹਨ, ਪੇਜ਼ ਸਕ੍ਰੋਲ ਹੁੰਦੇ ਹਨ, ਰਿਕਵੇਸਟਸ ਜਦੋਂ ਵੀ ਵਾਪਸ ਆਉਂਦੇ ਹਨ। JavaScript ਦਾ ਇਵੈਂਟ-ਡ੍ਰਿਵਨ ਅੰਦਾਜ਼ (ਕਾਲਬੈਕ, ਘਟਨਾਵਾਂ, ਪ੍ਰਾਮਿਸ) ਉਸ ਹਕੀਕਤ ਨੂੰ ਦਰਸਾਉਂਦਾ। ਸਾਧਾਰਣ ਸਟਾਰਟ-ਟੂ-ਫਿਨਿਸ਼ ਪ੍ਰੋਗਰਾਮ ਦੀ ਥਾਂ, ਵੈੱਬ ਕੋਡ ਦਾ ਵੱਡਾ ਹਿੱਸਾ "ਕਿਸੇ ਚੀਜ਼ ਲਈ ਉਡੀਕ ਕਰੋ, ਫਿਰ ਜਵਾਬ ਦਿਓ" ਪੈਟਰਨ ਤੇ ਚਲਦਾ—ਜੋ UI ਅਤੇ ਨੈਟਵਰਕ ਕੰਮ ਲਈ ਫ਼ਿੱਟ ਬੈਠਦਾ ਹੈ।

ਲੰਬੇ ਸਮੇਂ ਦੇ ਪ੍ਰਭਾਵ: ਇਕੋਸਿਸਟਮ ਅਤੇ ਕੰਪੈਟਬਿਲਿਟੀ

ਕਾਮਯਾਬੀ ਨੇ ਇੱਕ ਗ੍ਰੈਵੀਟੀ ਵੇਲ ਬਣਾਈ। ਫਰੇਮਵਰਕ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦਾ ਵੱਡਾ ਇਕੋਸਿਸਟਮ ਬਣ ਗਿਆ, ਅਤੇ ਬਿਲਡ ਪાઈਪਲਾਈਨ ਇੱਕ ਉਤਪਾਦ ਵਰਗੀ ਸ਼੍ਰੇਣੀ ਬਣ ਗਈ: ਟਰਾਂਸਪਾਈਲਰ, ਬੰਡਲਰ, ਮਿਨੀਫਾਇਰ ਅਤੇ ਪੈਕੇਜ ਮੈਨੇਜਰ। ਇਕੋ ਸਮੇਂ, ਵੈੱਬ ਦੀ ਵਾਅਦਾ ਕੀਤੀ ਪਿਛੋਕੜ-ਕੰਪੈਟਬਿਲਿਟੀ ਨੇ ਅਰਥ ਦਿੱਤਾ ਕਿ ਪੁਰਾਣੇ ਫੈਸਲੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਟਿਕੇ ਰਹਿੰਦੇ—ਇਸ ਲਈ ਆਧੁਨਿਕ JavaScript ਅਕਸਰ ਪਿਛਲੇ ਸੀਮਾਵਾਂ ਦੇ ਨਾਲ ਜੀਊਂਦੇ ਹੋਏ ਨਵੇਂ ਟੂਲਾਂ ਦੀ ਇਕ ਪਰਤ ਵਰਗੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ।

concurrency ਅਤੇ ਮਲਟੀ ਕੋਰ ਹਕੀਕਤ

ਲੰਮੇ ਸਮੇਂ ਤੱਕ, ਤੇਜ਼ ਕੰਪਿਊਟਰ ਦਾ ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ ਬਿਨਾ ਕਿਸੇ ਬਦਲਾਅ ਦੇ ਤੇਜ਼ ਚੱਲੇਗਾ। ਇਹ ਠੇਕਾ ਟੁੱਟ ਗਿਆ ਜਦੋਂ ਚਿੱਪਾਂ ਨੇ heat ਅਤੇ power ਸੀਮਾਵਾਂ ਹੋਣ ਕਾਰਨ ਘੰਟੀਆਂ ਬਦਲਣ ਦੀ ਬਜਾਏ ਕੋਰ ਵਧਾਏ। ਹੁਣ, ਵੱਧ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਅਕਸਰ ਇੱਕੋ ਸਮੇਂ ਇਕ ਤੋਂ ਵੱਧ ਕੰਮ ਕਰਨੇ ਲੋੜੀਂਦੇ ਹਨ।

ਮਲਟੀਕੋਰ ਨੇ concurrency ਅਨਿਵਾਰ્ય ਕਿਉਂ ਬਣਾ ਦਿੱਤਾ

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

ਭਾਸ਼ਾਵਾਂ ਨੇ ਕੀ ਜੋੜਿਆ ਹੈ ਮਦਦ ਲਈ

ਸ਼ੁਰੂਆਤੀ concurrency OS ਥ੍ਰੇਡਸ ਅਤੇ ਲੌਕਾਂ 'ਤੇ ਨਿਰਭਰ ਸੀ। ਕਈ ਭਾਸ਼ਾਵਾਂ ਨੇ ਇਹ ਸਿੱਧਾ ਸਾਹਮਣੇ ਰੱਖਿਆ, ਜੋ ਕੰਮ ਕੀਤਾ—ਪਰ ਆਮ ਡਿਵੈਲਪਰਾਂ ਉੱਤੇ ਜਟਿਲਤਾ ਧੱਕੀ।

ਨਵੇਂ ਡਿਜ਼ਾਈਨ ਆਮ ਪੈਟਰਨਜ਼ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ:

• ਸੇਫ਼ ਪ੍ਰਿਮਿਟਿਵਸ ਨਾਲ ਥ੍ਰੇਡਸ: ਬਿਹਤਰ mutexes, thread pools ਅਤੇ ਸਪਸ਼ਟ ਮੇਮੋਰੀ ਮਾਡਲ
• async/await: ਇੱਕ ਤਰੀਕਾ ਜੋ ਨਾਨ-ਬਲੌਕਿੰਗ ਕੋਡ ਨੂੰ ਅਜੇ ਵੀ ਇੱਕ ਸਧਾਰਨ ਕਦਮ-ਦਰ-ਕਦਮ ਲਾਜ਼ਮੀ ਲਿਖਤ ਵਾਂਗ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਂਦਾ
• ਚੈਨਲ ਅਤੇ ਮੈਸੇਜ ਪਾਸਿੰਗ: "ਦਾਖਲਾ-ਰੇਖਾ ਸਾਂਝਾ ਕਰਕੇ ਗੱਲ-ਬਾਤ" (CSP-ਸਟਾਈਲ) ਸਾਂਝੇ ਸਟੇਟ ਬੱਗ ਨੂੰ ਘਟਾਉਂਦੇ

ਸਰਵਰ ਅਤੇ ਵੰਡੇ ਹੋਏ ਸਿਸਟਮ ਨੇ ਡਿਫਾਲਟ ਚੀਜ਼ਾਂ ਬਦਲੇ

ਜਿਵੇਂ ਸੌਫਟਵੇਅਰ ਸਦੀਵ-ਚੱਲਣ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ ਵੱਲ ਵਧਿਆ, "ਸਧਾਰਨ" ਪ੍ਰੋਗਰਾਮ ਇੱਕ ਸਰਵਰ ਬਣ ਗਿਆ ਜੋ ਹਜ਼ਾਰਾਂ ਇਕੱਠੀਆਂ ਬੇਨਤੀਆਂ ਸੰਭਾਲਦਾ। ਭਾਸ਼ਾਵਾਂ ਨੇ I/O-ਭਾਰਕ ਵਰਕਲੋਡ, ਕੈਂਸਲੇਸ਼ਨ/ਟਾਈਮਆਉਟਸ ਅਤੇ ਲੋਡ ਹੇਠਾਂ ਪੇਸ਼ਗੀ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਓਪਟਿਮਾਈਜ਼ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ।

ਜਿਹੜੀਆਂ ਖ਼ਤਰਨਾਕੀਆਂ ਭਾਸ਼ਾਵਾਂ ਰੋਕਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀਆਂ ਹਨ

Concurrency ਵਿੱਚ ਨਾਕਾਮੀਆਂ ਅਕਸਰ ਦੁਰਲਭ ਅਤੇ ਦੁਬਾਰਾ ਬਣਾਉਣ ਲਈ ਮੁਸ਼ਕਲ ਹੁੰਦੀਆਂ ਹਨ। ਭਾਸ਼ਾ ਡਿਜ਼ਾਇਨ increasingly ਮਨੁੱਖਾਂ ਨੂੰ ਰੋਕਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ:

• ਰੇਸ ਕਂਡੀਸ਼ਨ (ਦੋ ਟਾਸਕ ਇੱਕੋ ਸਮੇਂ ਇੱਕੋ ਡੇਟਾ ਨੂੰ ਅਣਪੱਖੀ ਢੰਗ ਨਾਲ ਅਪਡੇਟ ਕਰਦੇ)
• ਡੀਡਲਾਕਸ (ਟਾਸਕ ਇਕ ਦੂਜੇ ਦੀ ਉਡੀਕ ਵਿੱਚ ਲਗਾਤਾਰ ਰਹਿ ਜਾਂਦੇ)
• ਸਟਾਰਵੇਸ਼ਨ (ਕੁਝ ਕੰਮ ਨੂੰ ਕਦੇ CPU ਨਹੀਂ ਮਿਲਦਾ)

ਵੱਡਾ ਬਦਲਾਅ: concurrency ਹੁਣ ਇੱਕ ਉन्नਤ ਵਿਸ਼ਾ ਨਾ ਰਹਿ ਕੇ ਇੱਕ ਬੇਸਲਾਈਨ ਉਮੀਦ ਬਣ ਚੁੱਕੀ ਹੈ।

ਆਧੁਨਿਕ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ: ਸੁਰੱਖਿਆ, ਸਾਦਗੀ ਅਤੇ ਟੂਲਿੰਗ (Go, Rust)

2010s ਦੇ ਦੌਰ ਵਿੱਚ, ਕਈ ਟੀਮਾਂ ਨੂੰ ਐਲਗੋਰੀਦਮ 'ਚ ਅਭਿਆਸ ਕਰਨ ਨਾਲ ਮਹੱਤਵਪੂਰਨ ਮੁਸ਼ਕਿਲ ਨਹੀਂ ਸੀ—ਉਹ ਸੇਵਾਵਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ, ਸਥਿਰ ਅਤੇ ਅਸਾਨੀ ਨਾਲ ਬਦਲਣਯੋਗ ਰੱਖਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਮਹਿਸੂਸ ਕਰ ਰਹੀਆਂ ਸਨ। ਦੋ ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਸਾਹਮਣੇ ਆਈਆਂ: ਮੇਮੋਰੀ ਗਲਤੀਆਂ ਕਾਰਨ ਸੁਰੱਖਿਆ ਬੱਗ ਅਤੇ ਬਹੁ-ਪੱਤਰ ਜਾਂ ਅਸਮਰਥ ਸਟੈਕਾਂ ਕਾਰਨ ਇੰਜੀਨੀਰਿੰਗ ਘਰੜਾ।

ਉਹ ਬੱਗਾਂ ਜੋ ਮੁੜ-ਮੁੜ ਆਉਂਦੀਆਂ ਹਨ ਉਹਨਾਂ ਦੀ ਠੀਕ ਕਰਨਾ

ਉੱਚ-ਸਗਰੀ ਬਚਤ ਡੇਂਜਰ ਭਾਗ ਬਹੁਤ ਵਾਰੀ ਮੇਮੋਰੀ ਸੇਫਟੀ ਮੁੱਦਿਆਂ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ: ਬਫਰ ਓਵਰਫਲੋ, use-after-free ਅਤੇ ਸੁਬਤਲ ਅਣਿਧਾਰਿਤ ਵਿਹਾਰ ਜੋ ਕੇਵਲ ਕੁਝ ਸੰਰਚਨਾਵਾਂ ਜਾਂ ਮਸ਼ੀਨਾਂ 'ਤੇ ਹੀ ਪ੍ਰਗਟ ਹੁੰਦੇ। ਆਧੁਨਿਕ ਭਾਸ਼ਾ ਡਿਜ਼ਾਇਨ increasingly ਐਨ੍ਹਾ ਗਲਤੀਆਂ ਨੂੰ ਅਸਵੀਕਾਰਯੋਗ "ਫੁਟ-ਗਨ" ਮੰਨਦਾ ਨਹੀਂ।

Rust ਇਸਦਾ ਸਭ ਤੋਂ ਸਾਫ਼ ਜਵਾਬ ਹੈ। ਇਸਦੇ ownership ਅਤੇ borrowing ਨਿਯਮ ਮੁੱਢਲੀ ਸਖ਼ਤ ਕੰਪਾਈਲ-ਟਾਈਮ ਜਾਂਚ ਹਨ: ਤੁਸੀਂ ਐਸਾ ਕੋਡ ਲਿਖਦੇ ਜੋ ਇਹ ਚੈੱਕ ਪੂਰਾ ਕਰੇ, ਅਤੇ ਬਦਲੇ ਵਿੱਚ ਤੁਹਾਨੂੰ ਗਾਰੰਟੀਜ਼ ਮਿਲਦੀਆਂ—ਮੇਮੋਰੀ ਸੇਫਟੀ ਬਿਨਾ ਗਾਰਬੇਜ ਕਲੇਕਸ਼ਨ ਦੇ। ਇਹ Rust ਨੂੰ ਉਹਨਾਂ ਸਿਸਟਮ ਕੋਡ ਲਈ ਆਕਰਸ਼ਕ ਬਨਾਉਂਦਾ ਜਿਸ ਨੇ ਇਤਿਹਾਸ ਵਿੱਚ C/C++ ਰੱਖੇ—ਨੈੱਟਵਰਕ ਸਰਵਿਸ, ਐਮਬੇਡਡ ਕੰਪੋਨੈਂਟ, ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਲਾਇਬ੍ਰੇਰੀਆਂ—ਜਿਥੇ ਸੁਰੱਖਿਆ ਅਤੇ ਗਤੀ ਦੋਹਾਂ ਮੈੱਤਵਪੂਰਨ ਹਨ।

ਸਾਦਗੀ ਅਤੇ ਸੇਵਾਵਾਂ ਨੂੰ ਡਿਫਾਲਟ ਕਰਕੇ

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

Go ਦੀ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਬਿਲਟ-ਇਨ concurrency ਪ੍ਰਿਮਿਟਿਵਸ (goroutines, channels) ਸਿੱਧਾ ਸੇਵਾ ਵਿਕਾਸ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਤੇਜ਼ ਕੰਪਾਇਲਰ ਅਤੇ ਸਿੱਧਾ ਡਿਪੈਂਡੇنسي ਕਹਾਣੀ ਦੈਣੇ-ਦਿਨੇ ਕੰਮ ਵਿੱਚ ਰਕਾਉਟ ਘਟਾਉਂਦੇ ਹਨ।

ਡਿਵੈਲਪਰ ਅਨੁਭਵ ਹੁਣ ਇੱਕ ਫੀਚਰ ਬਣ ਚੁੱਕਾ ਹੈ

ਟੂਲਿੰਗ "ਵਿਕਲਪਿਕ ਐਕਸਟ੍ਰਾ" ਤੋਂ ਭਾਅ-ਭੂਮਿਕਾ ਵਿੱਚ ਆ ਗਈ। Go ਨੇ ਇਹ ਵਿਚਾਰ gofmt ਨਾਲ ਨਾਰਮਲ ਕੀਤਾ ਅਤੇ ਇੱਕ ਸਖਤ ਸਾਂਝੀ ਫਾਰਮੈਟਿੰਗ ਸੱਭਿਆਚਾਰ ਨੂੰ ਪ੍ਰਚਲਿਤ ਕੀਤਾ। Rust ਨੇ rustfmt, clippy ਅਤੇ ਇੱਕ ਬਹੁਤ ਜ਼ੋਰਦਾਰ ਬਿਲਡ ਟੂਲ (cargo) ਦੇ ਨਾਲ ਇਹ ਪੈਟਰਨ ਅਪਣਾਇਆ।

ਅੱਜ ਦੇ "ਅਬ-ਕਾਨਟੀਨਿਊਸ ਸ਼ਿਪ" ਵਾਤਾਵਰਣ ਵਿੱਚ, ਇਹ ਟੂਲਿੰਗ ਕਹਾਣੀ ਕੰਪਾਇਲਰ ਅਤੇ ਲਿੰਟਰਾਂ ਤੋਂ ਉਪਰ ਵੀ ਹੋ ਗਈ—ਜਿਵੇਂ ਯੋਜਨਾ ਬਣਾਉਣ, ਸਕੈਫੋਲਡਿੰਗ ਅਤੇ ਤੇਜ਼ ਇਟਰੈਸ਼ਨ ਲੂਜ਼। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਇਸ ਬਦਲਾਅ ਦਾ ਇੱਕ ਉਦਾਹਰਨ ਹਨ: ਇਹ ਟੀਮਾਂ ਨੂੰ ਚੈਟ-ਚਲਿਤ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਦਿੰਦੇ—ਫਿਰ ਸੋರ್ಸ ਕੋਡ ਨਿਰਯਾਤ ਕਰਨ, ਡਿਪਲੋਇ ਕਰਨ ਅਤੇ ਸਨੈਪਸ਼ਾਟ ਨਾਲ ਰੋਲਬੈਕ ਕਰਨ ਦੀ ਸਹੂਲਤ ਦਿੰਦੇ। ਇਹ ਉਸੇ ਇਤਿਹਾਸਕ ਪੈਟਰਨ ਦੀ ਹੋਰ ਇਕ ਉਦਾਹਰਨ ਹੈ: ਉਹ ਟੂਲ ਜੋ ਸਭ ਤੋਂ ਤੇਜ਼ ਫੈਲਦੇ ਹਨ ਉਹ ਹਨ ਜੋ ਉਸ ਯੁੱਗ ਦੇ ਆਮ ਕੰਮ ਨੂੰ ਸਸਤਾ ਅਤੇ ਘੱਟ ਗਲਤੀ-ਪ੍ਰਵਣ ਬਣਾਉਂਦੇ।

ਜਦੋਂ ਫਾਰਮੇਟਰ, ਲਿੰਟਰ ਅਤੇ ਬਿਲਡ ਸਿਸਟਮ ਪਹਿਲੀ-ਕਲਾਸ ਹੁੰਦੇ, ਟੀਮਾਂ ਸ਼ੈਲੀ 'ਤੇ ਦੀਲਚਸਪੀ ਘੱਟ ਅਤੇ ਭਰੋਸੇਯੋਗ ਸੌਫਟਵੇਅਰ ਸ਼ਿਪ ਕਰਨ 'ਤੇ ਵਧੇਰੇ ਸਮਾਂ ਲਗਾਉਂਦੀਆਂ ਹਨ।

ਅੱਜ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਭਵਿੱਖ ਦੀਆਂ ਭਾਸ਼ਾਵਾਂ ਬਾਰੇ ਕੀ ਸੁਝਾਉਂਦੀਆਂ ਹਨ

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

AI, ਡੇਟਾ ਕੰਮ ਅਤੇ ਇਕੋਸਿਸਟਮ ਦੀ ਤਾਕਤ

ਅੱਜ ਦੀ ਭਾਸ਼ਾ ਪ੍ਰਸਿੱਧੀ ਦਾ ਇੱਕ ਵੱਡਾ ਚਲਕ ਹੈ ਕਿ ਕੰਮ ਕਿੱਥੇ ਹੈ: ਡੇਟਾ ਪਾਈਪਲਾਈਨ, ਵਿਸ਼ਲੇਸ਼ਣ, 머신 ਲਰਨਿੰਗ ਅਤੇ ਆਟੋਮੇਸ਼ਨ। ਇਸੀ ਲਈ Python ਵਧਦਾ ਜਾ ਰਿਹਾ ਹੈ—ਸਿਰਫ਼ ਸੁੰਦਰ ਸਿੰਟੈਕਸ ਲਈ ਨਹੀਂ, ਬਲਕਿ ਇਸਦੇ ਇਕੋਸਿਸਟਮ ਲਈ: NumPy/Pandas ਡੇਟਾ ਲਈ, PyTorch/TensorFlow ML ਲਈ, ਨੋਟਬੁੱਕਸ ਖੋਜ ਲਈ, ਅਤੇ ਇੱਕ ਵੱਡਾ ਕਮਿਉਨਿਟੀ ਜੋ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਬਿਲਡਿੰਗ ਬਲਾਕ ਬਣਾਉਂਦੀ ਹੈ।

SQL ਇਸੇ ਪ੍ਰਭਾਵ ਦਾ ਇੱਕ ਸ਼ਾਂਤ ਉਦਾਹਰਨ ਹੈ। ਇਹ ਫੈਸ਼ਨਬੁੱਧ ਨਹੀਂ, ਪਰ ਕਾਰੋਬਾਰੀ ਡੇਟਾ ਲਈ ਡਿਫ਼ਾਲਟ ਇੰਟਰਫੇਸ ਹੈ—ਡਿਕਲੇਰੇਟਿਵ ਕਵੇਰੀਜ਼, ਪੇਸ਼ਗੀ ਓਪਟੀਮਾਈਜ਼ਰ ਅਤੇ ਟੂਲਾਂ/ਵੇਂਡਰਾਂ ਵਿੱਚ ਵਿਸ਼ਾਲ ਅਨੁਕੂਲਤਾ। ਨਵੀਂ ਭਾਸ਼ਾਵਾਂ ਅਕਸਰ SQL ਨੂੰ ਜੋੜ ਦਿੰਦੀਆਂ ਹਨ ਨਾ ਕਿ ਇਸਨੂੰ ਬਦਲਦੀਆਂ।

ਇਸਦੇ ਨਾਲ-ਨਾਲ, ਪ੍ਰਦਰਸ਼ਨ-ਭਾਰੀ AI GPU-ਅਧਿਕਤਮ ਟੂਲਿੰਗ ਨੂੰ ਅੱਗੇ ਵਧਾ ਰਿਹਾ ਹੈ। ਅਸੀਂ vectorization, batching ਅਤੇ ਹਾਰਡਵੇਅਰ אַਕਸੈਲਰੇਸ਼ਨ 'ਤੇ ਪਹਿਲ-ਕਲਾਸ ਧਿਆਨ ਦੇਖ ਰਹੇ ਹਾਂ—ਚਾਹੇ ਉਹ CUDA ਇਕੋਸਿਸਟਮ, MLIR ਅਤੇ ਕੰਪਾਇਲਰ ਸਟੈਕ ਹੋਣ ਜਾਂ ਉਹ ਭਾਸ਼ਾਵਾਂ ਜੋ ਇਨ੍ਹਾਂ ਰਨਟਾਈਮਸ ਨਾਲ ਬਾਈਂਡ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ।

ਭਵਿੱਖ ਦੀਆਂ ਭਾਸ਼ਾ ਡਿਜ਼ਾਈਨਾਂ ਨੂੰ ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਰੂਪ ਦੇ ਸਕਦੀਆਂ ਹਨ

ਕਈ ਦਬਾਅ "ਅਗਲੇ ਯੁੱਗ" ਦੀਆਂ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਅਪਡੇਟਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਰੱਖਦੇ ਹਨ:

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

ਪ੍ਰਯੋਗਿਕ ਨਤੀਜਾ

ਜਦੋਂ ਤੁਸੀਂ ਭਾਸ਼ਾ ਚੁਣ ਰਹੇ ਹੋ, ਆਪਣੇ ਸੀਮਾਵਾਂ ਨਾਲ ਮੇਲ ਖਾਓ: ਟੀਮ ਦਾ ਅਨੁਭਵ, ਭਰਤੀ ਪੂਲ, ਉਹ ਲਾਇਬ੍ਰੇਰੀਆਂ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਨਿਰਭਰ ਹੋਵੋਗੇ, ਡਿਪਲੋਇਮੈਂਟ ਟਾਰਗੇਟਸ ਅਤੇ ਰਿਲਾਇਬਿਲਟੀ ਦੀ ਲੋੜ। "ਚੰਗੀ" ਭਾਸ਼ਾ ਅਕਸਰ ਉਹ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਆਮ ਕੰਮਾਂ ਨੂੰ ਨਿਰਾਸ਼ਾਨਕ(almost boring) ਤੇ ਬਦਲ ਦੇਵੇ—ਅਤੇ ਤੁਸੀਂ ਵੀ ਅਸਾਨੀ ਨਾਲ ਗਲਤੀਆਂ ਨੂੰ ਰੋਕ ਸਕੋ ਅਤੇ ਪਤਾ ਲਾ ਸਕੋ।

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