ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਡਿਜ਼ਾਈਨ ਬਾਰੇ ਪੰਜ ਸਵਾਲ

ਮਾਰਗਦਰਸ਼ਕ ਦਰਸ਼ਨ

1. ਲੋਕਾਂ ਲਈ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ

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

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

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

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

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

2. ਆਪਣੇ ਅਤੇ ਆਪਣੇ ਦੋਸਤਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ

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

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

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

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

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

3. ਪ੍ਰੋਗਰਾਮਰ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਕੰਟਰੋਲ ਦਿਓ

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

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

4. ਬ੍ਰੇਵਿਟੀ ਪ੍ਰਤਿਭਾ ਦੀ ਭੈਣ ਹੈ

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

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

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

5. ਪਛਾਣੋ ਕਿ ਹੈਕਿੰਗ ਕੀ ਹੈ

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

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

ਮੁੱਦੇ ਖੋਲ੍ਹੋ

1. ਵੱਡੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਕਿਵੇਂ ਸੰਗਠਿਤ ਕਰਨਾ ਹੈ?

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

2. ਕੀ ਲੋਕ ਅਗੇਤਰ ਸੰਟੈਕਸ ਤੋਂ ਸੱਚਮੁੱਚ ਡਰਦੇ ਹਨ?

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

3. ਤੁਹਾਨੂੰ ਸਰਵਰ ਸੌਫਟਵੇਅਰ ਲਈ ਕੀ ਚਾਹੀਦਾ ਹੈ?

ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਅਗਲੇ ਵੀਹ ਸਾਲਾਂ ਵਿੱਚ ਲਿਖੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਜ਼ਿਆਦਾਤਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਹੋਣਗੀਆਂ, ਇਸ ਅਰਥ ਵਿੱਚ ਕਿ ਪ੍ਰੋਗਰਾਮ ਇੱਕ ਸਰਵਰ 'ਤੇ ਰਹਿਣਗੇ ਅਤੇ ਇੱਕ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰ ਰਾਹੀਂ ਤੁਹਾਡੇ ਨਾਲ ਸੰਚਾਰ ਕਰਨਗੇ। ਅਤੇ ਅਜਿਹੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲਿਖਣ ਲਈ ਸਾਨੂੰ ਨਵੀਆਂ ਚੀਜ਼ਾਂ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.

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

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

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

4. ਕਿਹੜੇ ਨਵੇਂ ਐਬਸਟਰੈਕਸ਼ਨਾਂ ਦੀ ਖੋਜ ਕੀਤੀ ਜਾਣੀ ਬਾਕੀ ਹੈ?

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

ਬਹੁਤ ਘੱਟ ਜਾਣੇ ਭੇਦ

1. ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਭਾਸ਼ਾ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ

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

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

ਸਾਡੇ ਲਈ ਇਸਦਾ ਕੀ ਅਰਥ ਹੈ, ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲੇ ਲੋਕ, ਕਿ ਸਾਡੇ ਕੰਮ ਲਈ ਇੱਕ ਸੰਭਾਵੀ ਦਰਸ਼ਕ ਹੈ।

2. ਸਪੀਡ ਪ੍ਰੋਫਾਈਲਰਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ

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

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

3. ਤੁਹਾਨੂੰ ਇੱਕ ਐਪ ਦੀ ਲੋੜ ਹੈ ਜੋ ਤੁਹਾਡੀ ਭਾਸ਼ਾ ਨੂੰ ਵਿਕਸਿਤ ਕਰੇ

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

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

[ਗੱਲਬਾਤ ਦੌਰਾਨ, ਗਾਈ ਸਟੀਲ ਨੇ ਇਹ ਗੱਲ ਵੀ ਕੀਤੀ, ਇਹ ਜੋੜਦੇ ਹੋਏ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਤੁਹਾਡੀ ਭਾਸ਼ਾ ਲਈ ਕੰਪਾਈਲਰ ਲਿਖਣਾ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ, ਜਦੋਂ ਤੱਕ ਤੁਹਾਡੀ ਭਾਸ਼ਾ ਕੰਪਾਈਲਰ ਲਿਖਣ ਲਈ ਤਿਆਰ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।]

4. ਭਾਸ਼ਾ ਇੱਕ-ਵਾਰ ਪ੍ਰੋਗਰਾਮ ਲਿਖਣ ਲਈ ਢੁਕਵੀਂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

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

5. ਸੰਟੈਕਸ ਅਰਥ ਵਿਗਿਆਨ ਨਾਲ ਸਬੰਧਤ ਹੈ

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

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

ਉਹ ਵਿਚਾਰ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਵਾਪਸ ਆਉਂਦੇ ਹਨ

1. ਨਵੀਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ

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

2. ਸਮਾਂ ਸਾਂਝਾ ਕਰਨਾ

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

3. ਕੁਸ਼ਲਤਾ

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

ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਕੁਸ਼ਲਤਾ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ, ਘੱਟੋ ਘੱਟ ਕੰਪਿਊਟਿੰਗ ਰੁਕਾਵਟਾਂ ਵਿੱਚ. ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ I/O ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ਸਰਵਰ ਐਪਲੀਕੇਸ਼ਨ ਬਹੁਤ ਸਾਰੇ ਅਜਿਹੇ ਓਪਰੇਸ਼ਨ ਕਰਦੇ ਹਨ।

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

ਫੰਦੇ ਅਤੇ ਫੰਦੇ

1. ਗਾਹਕ

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

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

2. ਆਬਜੈਕਟ-ਅਧਾਰਿਤ ਪ੍ਰੋਗਰਾਮਿੰਗ

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

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

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

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

3. ਕਮੇਟੀ ਦੁਆਰਾ ਡਿਜ਼ਾਈਨ

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

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

ਸਰੋਤ: www.habr.com