ਲੇਖ ਪਹਿਲਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਇੱਕ ਦੇ ਜਵਾਬ ਵਜੋਂ ਲਿਖਿਆ ਗਿਆ ਸੀ antipodean ਲੇਖ.

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

ਕਮਜ਼ੋਰ ਪ੍ਰੋਗਰਾਮਰਾਂ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ?

ਕਮਜ਼ੋਰ ਲੋਕ ਸਮੱਸਿਆਵਾਂ ਦੀ ਗੱਲ ਕਰਦੇ ਹਨ। ਵਿਚਾਰਾਂ ਅਤੇ ਸੁਪਨਿਆਂ ਬਾਰੇ ਮਜ਼ਬੂਤ ​​ਗੱਲਬਾਤ...

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

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

ਤਾਂ ਇਸ ਨੂੰ ਇੰਨਾ ਸਰਲ ਕਿਉਂ ਬਣਾਇਆ ਗਿਆ? ਇੱਥੇ ਰੋਬ ਪਾਈਕ ਦੇ ਕੁਝ ਹਵਾਲੇ ਹਨ:

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

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

ਬੁੱਧੀਮਾਨ ਸ਼ਬਦ, ਕੀ ਉਹ ਨਹੀਂ ਹਨ?

ਸਾਦਗੀ ਦੀਆਂ ਕਲਾਕ੍ਰਿਤੀਆਂ

ਸਾਦਗੀ ਸੁੰਦਰਤਾ ਲਈ ਜ਼ਰੂਰੀ ਸ਼ਰਤ ਹੈ। ਲੇਵ ਟਾਲਸਟਾਏ.

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

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

ਬਹੁਤ ਭਾਵਪੂਰਤ ਨਹੀਂ

ਕਲਾ ਉਸ ਵੇਲੇ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕਰਦੀ ਜਦੋਂ ਇਸ ਦੀ ਆਜ਼ਾਦੀ ਨੂੰ ਸੀਮਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸ਼ੁੱਧਤਾ ਉਸਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨਹੀਂ ਹੈ।

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

ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਕੰਸੋਲ ਉਪਯੋਗਤਾ ਜੋ stdin ਪੜ੍ਹਦੀ ਹੈ ਜਾਂ ਕਮਾਂਡ ਲਾਈਨ ਆਰਗੂਮੈਂਟਸ ਤੋਂ ਇੱਕ ਫਾਈਲ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗੀ:

package main

import (
    "bufio"
    "flag"
    "fmt"
    "log"
    "os"
)

func main() {

    flag.Parse()

    scanner := newScanner(flag.Args())

    var text string
    for scanner.Scan() {
        text += scanner.Text()
    }

    if err := scanner.Err(); err != nil {
        log.Fatal(err)
    }

    fmt.Println(text)
}

func newScanner(flags []string) *bufio.Scanner {
    if len(flags) == 0 {
        return bufio.NewScanner(os.Stdin)
    }

    file, err := os.Open(flags[0])

    if err != nil {
        log.Fatal(err)
    }

    return bufio.NewScanner(file)
}

ਡੀ ਵਿੱਚ ਉਸੇ ਸਮੱਸਿਆ ਦਾ ਹੱਲ, ਹਾਲਾਂਕਿ ਇਹ ਕੁਝ ਛੋਟਾ ਲੱਗਦਾ ਹੈ, ਪੜ੍ਹਨਾ ਆਸਾਨ ਨਹੀਂ ਹੈ

import std.stdio, std.array, std.conv;

void main(string[] args)
{
    try
    {
        auto source = args.length > 1 ? File(args[1], "r") : stdin;
        auto text   = source.byLine.join.to!(string);

        writeln(text);
    }
    catch (Exception ex)
    {
        writeln(ex.msg);
    }
}

ਨਕਲ ਦਾ ਨਰਕ

ਮਨੁੱਖ ਆਪਣੇ ਅੰਦਰ ਨਰਕ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। ਮਾਰਟਿਨ ਲੂਥਰ.

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

package main

import "fmt"

func int64Sum(list []int64) (uint64) {
    var result int64 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func int32Sum(list []int32) (uint64) {
    var result int32 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func main() {

    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(int32Sum(list32))
    fmt.Println(int64Sum(list64))
}

ਭਾਸ਼ਾ ਕੋਲ ਅਜਿਹੀਆਂ ਰਚਨਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਕਾਫੀ ਸਾਧਨ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਆਮ ਪ੍ਰੋਗਰਾਮਿੰਗ ਠੀਕ ਹੋਵੇਗੀ।

package main

import "fmt"

func Eval32(list []int32, fn func(a, b int32)int32) int32 {
    var res int32
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int32Add(a, b int32) int32 {
    return a + b
}

func int32Sub(a, b int32) int32 {
    return a + b
}

func Eval64(list []int64, fn func(a, b int64)int64) int64 {
    var res int64
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int64Add(a, b int64) int64 {
    return a + b
}

func int64Sub(a, b int64) int64 {
    return a - b
}

func main() {

    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(Eval32(list32, int32Add))
    fmt.Println(Eval64(list64, int64Add))
    fmt.Println(Eval64(list64, int64Sub))
}

ਅਤੇ, ਹਾਲਾਂਕਿ ਸਾਡਾ ਕੋਡ ਪਿਛਲੇ ਕੇਸ ਨਾਲੋਂ ਕੁਝ ਲੰਬਾ ਨਿਕਲਿਆ, ਇਹ ਆਮ ਹੋ ਗਿਆ ਹੈ। ਇਸ ਲਈ, ਸਾਡੇ ਲਈ ਗਣਿਤ ਦੀਆਂ ਸਾਰੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਮੁਸ਼ਕਲ ਨਹੀਂ ਹੋਵੇਗਾ।

ਬਹੁਤ ਸਾਰੇ ਕਹਿਣਗੇ ਕਿ D ਵਿੱਚ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਕਾਫ਼ੀ ਛੋਟਾ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਉਹ ਸਹੀ ਹੋਣਗੇ।

import std.stdio;
import std.algorithm;

void main(string[] args)
{
    [1, 2, 3, 4, 5].reduce!((a, b) => a + b).writeln;
}

ਹਾਲਾਂਕਿ, ਇਹ ਸਿਰਫ ਛੋਟਾ ਹੈ, ਪਰ ਜ਼ਿਆਦਾ ਸਹੀ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਡੀ ਲਾਗੂ ਕਰਨਾ ਗਲਤੀ ਨਾਲ ਨਜਿੱਠਣ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਣਡਿੱਠ ਕਰਦਾ ਹੈ।

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

ਸਾਂਭ-ਸੰਭਾਲ, ਵਿਸਤਾਰਯੋਗਤਾ ਅਤੇ ਪੜ੍ਹਨਯੋਗਤਾ ਦੇ ਸੰਦਰਭ ਵਿੱਚ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਗੋ ਭਾਸ਼ਾ ਜਿੱਤ ਜਾਂਦੀ ਹੈ, ਹਾਲਾਂਕਿ ਇਹ ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ ਹਾਰ ਜਾਂਦੀ ਹੈ।

ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ ਆਮ ਪ੍ਰੋਗਰਾਮਿੰਗ ਸਾਨੂੰ ਨਿਰਵਿਘਨ ਲਾਭ ਦਿੰਦੀ ਹੈ। ਇਹ ਕ੍ਰਮਬੱਧ ਪੈਕੇਜ ਦੁਆਰਾ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਇਸ ਲਈ, ਕਿਸੇ ਵੀ ਸੂਚੀ ਨੂੰ ਕ੍ਰਮਬੱਧ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਸਿਰਫ਼ sort.Interface ਇੰਟਰਫੇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ.

import "sort"

type Names []string

func (ns Names) Len() int {
    return len(ns)
}

func (ns Names) Less(i, j int) bool {
    return ns[i] < ns[j]
}

func (ns Names) Swap(i, j int) {
    ns[i], ns[j] = ns[j], ns[i]
}

func main() {
    names := Names{"London", "Berlin", "Rim"}
    sort.Sort(names)
}

ਜੇਕਰ ਤੁਸੀਂ ਕੋਈ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਲੈਂਦੇ ਹੋ ਅਤੇ grep “interface{}” -R ਕਮਾਂਡ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੇਖੋਗੇ ਕਿ ਕਿੰਨੀ ਵਾਰ ਉਲਝਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਨੇੜੇ-ਤੇੜੇ ਦੇ ਕਾਮਰੇਡ ਤੁਰੰਤ ਕਹਿਣਗੇ ਕਿ ਇਹ ਸਭ ਕੁਝ ਆਮ ਲੋਕਾਂ ਦੀ ਘਾਟ ਕਾਰਨ ਹੋਇਆ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਹਮੇਸ਼ਾ ਅਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ. ਆਉ DELPHI ਨੂੰ ਇੱਕ ਉਦਾਹਰਨ ਵਜੋਂ ਲੈਂਦੇ ਹਾਂ। ਇਹਨਾਂ ਸਮਾਨ ਜੈਨਰਿਕਾਂ ਦੀ ਮੌਜੂਦਗੀ ਦੇ ਬਾਵਜੂਦ, ਇਸ ਵਿੱਚ ਆਰਬਿਟਰੇਰੀ ਡੇਟਾ ਕਿਸਮਾਂ ਦੇ ਨਾਲ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਵੇਰੀਐਂਟ ਕਿਸਮ ਸ਼ਾਮਲ ਹੈ। ਗੋ ਭਾਸ਼ਾ ਵੀ ਅਜਿਹਾ ਹੀ ਕਰਦੀ ਹੈ।

ਤੋਪ ਤੋਂ ਚਿੜੀਆਂ ਤੱਕ

ਅਤੇ ਸਟਰੇਟਜੈਕੇਟ ਨੂੰ ਪਾਗਲਪਨ ਦੇ ਆਕਾਰ ਦੇ ਅਨੁਕੂਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਸਟੈਨਿਸਲਾਵ ਲੈਕ.

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

ਰੌਬ ਪਾਈਕ ਸਾਨੂੰ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ:

ਇਹ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸੰਦ ਹੈ ਜੋ ਸਾਵਧਾਨੀ ਨਾਲ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਸ ਤੋਂ ਪਰਹੇਜ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਸਖ਼ਤੀ ਨਾਲ ਜ਼ਰੂਰੀ ਨਾ ਹੋਵੇ।

ਵਿਕੀਪੀਡੀਆ ਸਾਨੂੰ ਹੇਠਾਂ ਦੱਸਦਾ ਹੈ:

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

ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਪਵੇਗਾ. ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਇਹ ਹੈ:

• ਪ੍ਰੋਗਰਾਮ ਲਿਖਣ ਵਿੱਚ ਮੁਸ਼ਕਲ
• ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਚਲਾਉਣ ਦੀ ਗਤੀ

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

ਸ਼ੀ ਤੋਂ ਸੱਭਿਆਚਾਰਕ ਸਮਾਨ? ਨਹੀਂ, ਕਈ ਭਾਸ਼ਾਵਾਂ ਤੋਂ!

ਕਿਸਮਤ ਦੇ ਨਾਲ-ਨਾਲ ਵਾਰਸਾਂ ਦੇ ਕਰਜ਼ੇ ਵੀ ਛੱਡੇ ਜਾਂਦੇ ਹਨ।

ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਮੰਨਦੇ ਹਨ ਕਿ ਭਾਸ਼ਾ ਪੂਰੀ ਤਰ੍ਹਾਂ C ਵਿਰਾਸਤ 'ਤੇ ਅਧਾਰਤ ਹੈ, ਅਜਿਹਾ ਨਹੀਂ ਹੈ। ਭਾਸ਼ਾ ਵਧੀਆ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਦੇ ਕਈ ਪਹਿਲੂਆਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ।

ਸੰਟੈਕਸ

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

ਅਰਥ ਵਿਗਿਆਨ

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

ਡੈਲੀਗੇਸ਼ਨ ਵਿਧੀ ਦੁਆਰਾ ਲਾਗੂ ਕਰਨ ਦੀ ਕਾਰਵਾਈ DELPHI ਭਾਸ਼ਾ ਤੋਂ ਉਧਾਰ ਲਈ ਗਈ ਸੀ।

ਸੰਗ੍ਰਹਿ

ਇਹ ਬਿਨਾਂ ਕਾਰਨ ਨਹੀਂ ਹੈ ਕਿ ਇੱਕ ਮਜ਼ਾਕ ਹੈ: ਗੋ ਨੂੰ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਸੀ ਜਦੋਂ ਇੱਕ C ਪ੍ਰੋਗਰਾਮ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾ ਰਿਹਾ ਸੀ। ਭਾਸ਼ਾ ਦੀ ਇੱਕ ਖੂਬੀ ਇਸ ਦਾ ਅਤਿ-ਤੇਜ਼ ਸੰਕਲਨ ਹੈ। ਇਹ ਵਿਚਾਰ DELPHI ਭਾਸ਼ਾ ਤੋਂ ਲਿਆ ਗਿਆ ਸੀ। ਹਰੇਕ ਗੋ ਪੈਕੇਜ ਇੱਕ DELPHI ਮੋਡੀਊਲ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਇਹ ਪੈਕੇਜ ਸਿਰਫ਼ ਲੋੜ ਪੈਣ 'ਤੇ ਹੀ ਮੁੜ ਕੰਪਾਇਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਇਸ ਲਈ, ਅਗਲੇ ਸੰਪਾਦਨ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਨੂੰ ਪੂਰੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਕੰਪਾਇਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਸਿਰਫ਼ ਬਦਲੇ ਹੋਏ ਪੈਕੇਜਾਂ ਅਤੇ ਪੈਕੇਜਾਂ ਨੂੰ ਦੁਬਾਰਾ ਕੰਪਾਈਲ ਕਰੋ ਜੋ ਇਹਨਾਂ ਬਦਲੇ ਹੋਏ ਪੈਕੇਜਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ (ਅਤੇ ਫਿਰ ਵੀ, ਤਾਂ ਹੀ, ਜੇਕਰ ਪੈਕੇਜ ਇੰਟਰਫੇਸ ਬਦਲ ਗਏ ਹਨ)।

ਉੱਚ-ਪੱਧਰੀ ਉਸਾਰੀਆਂ

ਭਾਸ਼ਾ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਉੱਚ-ਪੱਧਰੀ ਨਿਰਮਾਣ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਜੋ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ C ਵਰਗੀਆਂ ਨੀਵੇਂ-ਪੱਧਰੀ ਭਾਸ਼ਾਵਾਂ ਨਾਲ ਸਬੰਧਤ ਨਹੀਂ ਹਨ।

• ਸਤਰ
• ਹੈਸ਼ ਟੇਬਲ
• ਟੁਕੜੇ
• ਡਕ ਟਾਈਪਿੰਗ ਨੂੰ RUBY ਵਰਗੀਆਂ ਭਾਸ਼ਾਵਾਂ ਤੋਂ ਉਧਾਰ ਲਿਆ ਜਾਂਦਾ ਹੈ (ਜੋ ਬਦਕਿਸਮਤੀ ਨਾਲ, ਬਹੁਤ ਸਾਰੇ ਇਸਦੀ ਪੂਰੀ ਸਮਰੱਥਾ ਨੂੰ ਸਮਝਦੇ ਜਾਂ ਵਰਤਦੇ ਨਹੀਂ ਹਨ)।

ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ

ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਵੱਖਰੇ ਲੇਖ ਦਾ ਹੱਕਦਾਰ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ C++ ਵਰਗੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ, ਨਿਯੰਤਰਣ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡਿਵੈਲਪਰ ਲਈ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ DELPHI ਵਰਗੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ, ਇੱਕ ਹਵਾਲਾ ਗਿਣਤੀ ਮਾਡਲ ਵਰਤਿਆ ਗਿਆ ਸੀ। ਇਸ ਪਹੁੰਚ ਦੇ ਨਾਲ, ਚੱਕਰੀ ਸੰਦਰਭਾਂ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੱਤੀ ਗਈ ਸੀ, ਕਿਉਂਕਿ ਅਨਾਥ ਕਲੱਸਟਰ ਬਣਾਏ ਗਏ ਸਨ, ਫਿਰ ਗੋ ਨੇ ਅਜਿਹੇ ਕਲੱਸਟਰਾਂ (ਜਿਵੇਂ C#) ਦੀ ਬਿਲਟ-ਇਨ ਖੋਜ ਕੀਤੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ ਵਾਲਾ ਸਭ ਤੋਂ ਵੱਧ ਮੌਜੂਦਾ ਜਾਣੇ-ਪਛਾਣੇ ਲਾਗੂਕਰਨਾਂ ਨਾਲੋਂ ਵਧੇਰੇ ਕੁਸ਼ਲ ਹੈ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਸਾਰੇ ਰੀਅਲ-ਟਾਈਮ ਕੰਮਾਂ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਭਾਸ਼ਾ ਖੁਦ ਹੀ ਸਥਿਤੀਆਂ ਨੂੰ ਪਛਾਣਦੀ ਹੈ ਜਦੋਂ ਇੱਕ ਵੇਰੀਏਬਲ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਇੱਕ ਮੁੱਲ ਸਟੈਕ 'ਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਮੈਮੋਰੀ ਮੈਨੇਜਰ 'ਤੇ ਲੋਡ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰੋਗਰਾਮ ਦੀ ਗਤੀ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ।

ਸਮਰੂਪਤਾ ਅਤੇ ਸਮਰੂਪਤਾ

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

ਵਾਧੂ ਲਾਭ

ਜੇਕਰ ਇਹ ਲਾਭਦਾਇਕ ਹੈ, ਤਾਂ ਹਰ ਕੋਈ ਨਿਰਸਵਾਰਥ ਹੋ ਜਾਵੇਗਾ।

ਭਾਸ਼ਾ ਸਾਨੂੰ ਬਹੁਤ ਸਾਰੇ ਬਿਨਾਂ ਸ਼ੱਕ ਲਾਭ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ:

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

ਭਾਈਚਾਰਕ ਲਾਭ ਲਈ ਸਾਦਗੀ

ਇਸਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਣਾ ਆਸਾਨ ਹੈ, ਸਰਲ ਬਣਾਉਣਾ ਔਖਾ ਹੈ।

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

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

ਸਿੱਟਾ

ਦਿਮਾਗ ਦੇ ਵੱਡੇ ਆਕਾਰ ਨੇ ਕਦੇ ਵੀ ਕਿਸੇ ਹਾਥੀ ਨੂੰ ਨੋਬਲ ਪੁਰਸਕਾਰ ਜੇਤੂ ਨਹੀਂ ਬਣਾਇਆ ਹੈ।

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

ਸਰੋਤ: www.habr.com