18 ਦਸੰ 2025·8 ਮਿੰਟ
John McCarthy, Lisp ਅਤੇ ਸੰਕੇਤਕ AI ਡਿਜ਼ਾਈਨ ਦੀਆਂ ਜੜਾਂ
ਜਾਣੋ ਕਿ John McCarthy ਦੀ ਸੰਕੇਤਕ ਰਵਈਆ ਅਤੇ Lisp ਦੇ ਡਿਜ਼ਾਈਨ-ਖ਼ਿਆਲ—ਲਿਸਟਾਂ, ਰੀਕਰਸ਼ਨ ਅਤੇ ਗਾਰਬੇਜ ਕਲੈਕਸ਼ਨ—ਨੇ AI ਅਤੇ ਆਧੁਨਿਕ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ।
ਜਾਣੋ ਕਿ John McCarthy ਦੀ ਸੰਕੇਤਕ ਰਵਈਆ ਅਤੇ Lisp ਦੇ ਡਿਜ਼ਾਈਨ-ਖ਼ਿਆਲ—ਲਿਸਟਾਂ, ਰੀਕਰਸ਼ਨ ਅਤੇ ਗਾਰਬੇਜ ਕਲੈਕਸ਼ਨ—ਨੇ AI ਅਤੇ ਆਧੁਨਿਕ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ।
ਇਹ “ਪੁਰਾਣੇ AI” ਦਾ ਸੰਗ੍ਰਹਾਲੇ ਦਾ ਦੌਰਾ ਨਹੀਂ ਹੈ। ਇਹ ਕਿਸੇ ਵੀ ਉਸ ਵਿਅਕਤੀ ਲਈ ਪ੍ਰਯੋਗਿਕ ਇਤਿਹਾਸਕ ਪਾਠ ਹੈ ਜੋ ਸੌਫਟਵੇਅਰ ਬਣਾਉਂਦਾ ਹੈ—ਚਾਹੇ ਉਹ ਪ੍ਰੋਗ੍ਰਾਮਰ ਹੋਵੇ, ਟੈਕ ਲੀਡ ਹੋਵੇ ਜਾਂ ਪ੍ਰੋਡਕਟ ਬਿਲਡਰ—ਕਿਉਂਕਿ John McCarthy ਦੇ ਵਿਚਾਰਾਂ ਨੇ ਸਨੂਚਿਤ ਕੀਤਾ ਕਿ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਕਿਸ ਲਈ ਹੁੰਦੀਆਂ ਹਨ।
Lisp ਸਿਰਫ਼ ਇੱਕ ਨਵਾਂ ਸਿੰਟੈਕਸ ਨਹੀਂ ਸੀ। ਇਹ ਇੱਕ ਦਾਅ ਸੀ ਕਿ ਸਾਫਟਵੇਅਰ ਵਿਚਾਰਾਂ (ਸਿਰਫ਼ ਨੰਬਰ ਨਹੀਂ) ਨੂੰ ਪ੍ਰੋਸੈੱਸ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿ ਭਾਸ਼ਾ ਡਿਜ਼ਾਈਨ ਦੇ ਫੈਸਲੇ ਰਿਸਰਚ, ਉਤਪਾਦ итਰੇਸ਼ਨ ਅਤੇ ਪੂਰੇ ਟੂਲਿੰਗ ਪਰਿਸਰ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹਨ।
McCarthy ਦੀ ਵਿਰਾਸਤ ਨੂੰ ਕਿਸੇ ਇੱਕ ਸਵਾਲ ਵਜੋਂ ਪੜ੍ਹਨਾ ਇਸ ਤਰ੍ਹਾਂ ਹੈ ਜੋ ਅਜੇ ਵੀ ਅਹੰਕਾਰ ਰੱਖਦਾ ਹੈ: ਅਸੀਂ ਇਰਾਦੇ ਨੂੰ ਕਿੰਨੀ ਸਿੱਧੀ ਤਰ੍ਹਾਂ executable ਸਿਸਟਮ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਾਂ—ਬਿਨਾਂ ਬਾਇਲਰਪਲੇਟ, ਰੁਕਾਵਟ ਜਾਂ ਅਕਸਮਾਤੀ ਜਟਿਲਤਾ ਵਿੱਚ ਡੁੱਬੇ? ਇਹ ਸਵਾਲ Lisp ਦੇ REPL ਤੋਂ ਲੈ ਕੇ ਆਧੁਨਿਕ "ਚੈਟ-ਟੂ-ਐਪ" ਵਰਕਫਲੋ ਤੱਕ ਗੂੰਜਦਾ ਹੈ।
John McCarthy ਨੂੰ ਸਿਰਫ਼ AI ਦੇ ਖੇਤਰ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਦੇ ਯੋਗਦਾਨ ਲਈ ਹੀ ਯਾਦ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ—ਉਸ ਨੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕਿਸਮ ਦੇ AI 'ਤੇ ਜ਼ੋਰ ਦਿੱਤਾ: ਐਸੇ ਸਿਸਟਮ ਜੋ ਵिचਾਰਾਂ ਨੂੰ ਪ੍ਰੋਸੈੱਸ ਕਰ ਸਕਣ, ਸਿਰਫ਼ ਨਤੀਜੇ ਗਣਨਾ ਕਰਨ ਹੀ ਨਹੀਂ। 1950 ਦੇ ਦਹਾਕੇ ਵਿਚ, ਉਸ ਨੇ Dartmouth Summer Research Project ਦਾ ਆਯੋਜਨ ਕੀਤਾ (ਜਿੱਥੇ "artificial intelligence" ਸ਼ਬਦ ਸੁਝਾਇਆ ਗਿਆ) ਅਤੇ ਫਿਰ MIT ਅਤੇ Stanford 'ਚ AI ਕੰਮ ਨੂੰ ਰੂਪ ਦਿੱਤਾ। ਪਰ ਉਸ ਦਾ ਸਭ ਤੋਂ ਟਿਕਾਉ ਯੋਗਦਾਨ ਉਹ ਸਵਾਲ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਉਹ ਬਾਰ-ਬਾਰ ਪੁੱਛਦਾ ਰਿਹਾ: ਜੇ ਤਰਕਸ਼ੀਲਤਾ ਨੂੰ ਖੁਦ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਵਜੋਂ ਪ੍ਰਗਟ ਕੀਤਾ ਜਾ ਸਕੇ?
ਸ਼ੁਰੂਆਤੀ ਕਮਪਿਊਟਿੰਗ ਸਫਲਤਾਵਾਂ ਜ਼ਿਆਦਾ ਤਰ ਨੰਬਰਾਂ ਨਾਲ ਸਬੰਧਿਤ ਸਨ: ਗੋਲਾਬੰਦੀਆਂ, ਇੰਜੀਨੀਅਰਿੰਗ ਨਕਸ਼ੇ, ਅਪਟੀਮੀਜ਼ੇਸ਼ਨ, ਅਤੇ ਅੰਕੜੇ। ਇਹ ਸਮੱਸਿਆਵਾਂ ਅੰਕਗਣਿਤ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਫਿੱਟ ਹੋ ਜਾਂਦੀਆਂ।
McCarthy ਕੁਝ ਹੋਰ ਦੀ ਸੋਚ ਰੱਖਦਾ ਸੀ। ਮਨੁੱਖੀ ਤਰਕਸ਼ੀਲਤਾ ਅਕਸਰ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ: “ਜੇ”, “ਕਿਉਂ”, “ਕਿਸ ਨਾਲ ਸਬੰਧਤ ਹੈ”, “ ਕਿਸ ਪ੍ਰਕਾਰ ਦਾ ਹੈ”, ਅਤੇ “ਜਿਨ੍ਹਾਂ ਸ਼ਰਤਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ ਉਹ ਸਾਰੇ”—ਇਹ ਗੱਲਾਂ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਫਲੋਟਿੰਗ-ਪੌਇੰਟ ਮੁੱਲਾਂ ਵਜੋਂ ਨਹੀਂ ਆਉਂਦੀਆਂ।
McCarthy ਦਾ ਰਵਈਆ ਗਿਆਨ ਨੂੰ ਸੰਕੇਤ (ਨਾਂ, ਸੰਬੰਧ, ਵਰਗ) ਵਜੋਂ ਦੇਖਦਾ ਸੀ ਅਤੇ ਸੋਚ ਨੂੰ ਉਨ੍ਹਾਂ ਸੰਕੇਤਾਂ 'ਤੇ ਅਧਾਰਿਤ ਨਿਯਮ-ਅਧਾਰਿਤ ਤਬਦੀਲੀਆਂ ਵਜੋਂ ਲੈਂਦਾ ਸੀ।
ਉਚ-ਪੱਧਰੀ ਢੰਗ ਨਾਲ ਕਹਿਣ ਲਈ: ਨੰਬਰਵਾਦ "ਕਿੰਨਾ?" ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜਦਕਿ ਸੰਕੇਤਕ ਢੰਗ "ਇਹ ਕੀ ਹੈ?" ਅਤੇ "ਸਾਡੇ ਪਾਸ ਜਾਣਕਾਰੀ ਤੋਂ ਕੀ ਨਤੀਜਾ ਨਿਕਲਦਾ ਹੈ?" ਪੁੱਛਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਮੰਨ ਲਓ ਕਿ ਤਰਕਸ਼ੀਲਤਾ ਨੂੰ ਪ੍ਰੋਗਰਾਮਯੋਗ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਐਸੀ ਭਾਸ਼ਾ ਚਾਹੀਦੀ ਹੈ ਜੋ ਨਿਯਮ, ਤਰਕ-ਬਿਆਨ ਅਤੇ ਨੇਸਟ ਸਬੰਧਾਂ ਵਰਗੀਆਂ ਅਭਿਵਿੱਕਤੀਆਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਦਰਸਾ ਸਕੇ—ਅਤੇ ਫਿਰ ਉਹਨਾਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰ ਸਕੇ।
Lisp ਨੂੰ ਉਸੇ ਲਕਸ਼ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਕਠੋਰ ਪੂਰਵ-ਤੈਅ ਡੇਟਾ ਢਾਂਚਿਆਂ ਵਿੱਚ ਵਿਚਾਰਾਂ ਨੂੰ ਮਜ਼ਬੂਰ ਕਰਨ ਦੀ ਬਜਾਏ, Lisp ਨੇ ਕੋਡ ਅਤੇ ਗਿਆਨ ਨੂੰ ਇੱਕੋ ਜਿਹੇ ਆਕਾਰ ਵਿੱਚ ਦਰਸਾਉਣਾ ਸਹਜ ਬਣਾਇਆ। ਇਹ ਚੋਣ ਸਿਰਫ਼ ਅਕਾਦਮਿਕ ਅੰਦਾਜ਼ ਨਹੀਂ ਸੀ—ਇਹ ਇਕ ਸੋਚ ਨੂੰ ਵੇਰਵਾ ਕਰਨ ਅਤੇ ਇੱਕ ਕਾਰਜ ਨੂੰ ਚਲਾਉਣ ਦੇ ਦਰਮਿਆਨ ਇੱਕ ਵਿਹਾਰਕ ਪੁਲ ਸੀ, ਜੋ McCarthy ਚਾਹੁੰਦਾ ਸੀ ਕਿ AI ਪਾਰ ਕਰੇ।
ਜਦੋਂ McCarthy ਅਤੇ ਸ਼ੁਰੂਆਤੀ AI ਖੋਜਕਾਰ "symbolic" ਕਹਿੰਦੇ ਸਨ, ਉਹ ਹਨਰੀਅਲੀ ਗਣਿਤ ਦਾ ਨਹੀਂ ਕਹਿ ਰਹੇ ਸਨ। ਇੱਕ ਸੰਕੇਤ ਸਿਰਫ਼ ਇੱਕ ਅਰਥਪੂਰਕ ਲੇਬਲ ਹੈ: customer ਵਰਗਾ ਨਾਂ, hungry ਵਰਗਾ ਸ਼ਬਦ, ਜਾਂ IF ਅਤੇ THEN ਵਰਗੇ ਟੈਗ। ਸੰਕੇਤ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਉਹ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਵਿਚਾਰਾਂ (ਵਰਗ, ਸੰਬੰਧ, ਨਿਯਮ) ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ ਨਾ ਕਿ ਸਿਰਫ਼ ਕੱਚੇ ਨੰਬਰਾਂ ਨਾਲ।
ਇੱਕ ਸਾਦਾ ਤਰੀਕਾ ਸੋਚਣ ਦਾ: ਜੇ ਤੁਹਾਡੀ ਦੁਨਿਆ ਕਾਲਮ ਅਤੇ ਗਣਿਤ ਹੈ ਤਾਂ spreadsheet ਬਹੁਤ ਵਧੀਆ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਦੁਨੀਆਂ ਨਿਯਮਾਂ, ਵਰਗਾਂ, ਛੂਟਾਂ ਅਤੇ ਢਾਂਚੇ ਨਾਲ ਭਰੀ ਹੈ ਤਾਂ ਸੰਕੇਤਕ ਸਿਸਟਮ ਬਿਹਤਰ ਹਨ।
ਕਈ ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ, 42 ਅਤੇ "age" ਵਿੱਚ ਫ਼ਰਕ ਸਿਰਫ਼ ਡੇਟਾ ਟਾਈਪ ਨਹੀਂ—ਇਹ ਉਸ ਗੱਲ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ ਕਿ ਮੁੱਲ ਕੀ ਦਰਸਾਉਂਦਾ ਹੈ। ਇੱਕ ਸੰਕੇਤ ਤੁਹਾਨੂੰ ਕੁਝ ਐਸਾ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਤੁਲਨਾ, ਸਟੋਰ ਅਤੇ ਜੋੜ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਅਰਥ ਗੁਆਉਂਦੇ।
ਇਸ ਨਾਲ "Paris ਇੱਕ ਸ਼ਹਿਰ ਹੈ" ਜਾਂ "ਜੇ ਬੈਟਰੀ ਘੱਟ ਹੈ, ਤਾਂ ਚਾਰਜਰ ਲੱਭੋ" ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਦਰਸਾਉਣਾ ਕੁਦਰਤੀ ਬਣ ਜਾਂਦਾ ਹੈ।
ਸੰਕੇਤਾਂ ਨਾਲ ਕੁਝ ਵਰਗੇ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਢਾਂਚੇ ਦੀ ਲੋੜ ਹੈ। Lisp ਨੇ ਇੱਕ ਬਹੁਤ ਸਾਫ਼ ਢਾਂਚਾ ਪ੍ਰਸਿੱਧ ਕੀਤਾ: ਲਿਸਟ। ਇੱਕ ਲਿਸਟ ਸਿਰਫ਼ ਤੱਤਾਂ ਦਾ ਆਰਡਰਡ ਗਰੁੱਪ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਹ ਤੱਤ ਖ਼ੁਦ ਵੀ ਲਿਸਟ ਹੋ ਸਕਦੇ ਹਨ। ਇੱਕ ਹੀ ਵਿਚਾਰ ਨਾਲ ਤੁਸੀਂ ਵਾਕ, ਫਾਰਮ ਅਤੇ ਟਰੀ-ਆਕਾਰ ਦੀ ਗਿਆਨ ਦੀ ਪ੍ਰਤੀਨਿਧਤਾ ਕਰ ਸਕਦੇ ਹੋ।
ਇਹाँ ਇੱਕ ਛੋਟਾ ਸੋਚ-ਉਦਾਹਰਨ (Lisp-ਨੁਮਾਂ ਅੰਦਾਜ਼ ਵਿੱਚ):
(sentence (subject robot) (verb needs) (object power))
ਇਹ ਲਗਭਗ ਅੰਗਰੇਜ਼ੀ ਵਾਂਗ ਪੜ੍ਹਦਾ ਹੈ: ਇੱਕ ਵਾਕ ਜਿਸ ਦੇ ਵਿਚਕਾਰ subject, verb ਅਤੇ object ਹਨ। ਕਿਉਂਕਿ ਇਹ ਸੰਰਚਿਤ ਹੈ, ਇੱਕ ਪ੍ਰੋਗਰਾਮ (subject robot) ਨੂੰ ਚੁਣ ਸਕਦਾ ਹੈ ਜਾਂ (object power) ਨੂੰ ਕੁਝ ਹੋਰ ਨਾਲ ਬਦਲ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਜਾਣਕਾਰੀ ਸੰਕੇਤਕ ਢਾਂਚਿਆਂ ਵਿੱਚ ਆ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕਲਾਸਿਕ AI ਕਾਰਜ ਪਹੁੰਚਯੋਗ ਹੋ ਜਾਂਦੇ ਹਨ:
ਹੁਣ ਮੁੱਖ ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮ ਸਿਰਫ਼ ਗਣਨਾ ਨਹੀਂ ਕਰ ਰਿਹਾ—ਇਹ ਇੱਕ ਅਰਥਪੂਰਕ ਗਿਆਨ ਨੂੰ ਇਸ ਦੇ ਰੂਪ ਵਿੱਚ ਤਬਦੀਲ ਅਤੇ ਪਰਿਵਰਤਿਤ ਕਰ ਰਿਹਾ ਹੈ।
Lisp ਦੇ ਡਿਜ਼ਾਈਨ ਫੈਸਲੇ ਅਕਾਦਮੀਆ ਦੇ ਅੰਦਰ ਹੀ ਨਹੀਂ ਰਹੇ। ਉਨ੍ਹਾਂ ਨੇ ਇਹ ਪ੍ਰਭਾਵ ਛੱਡਿਆ ਕਿ ਲੋਕ ਕੀਤੇ ਟੂਲ ਕਿਵੇਂ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਕਿਵੇਂ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਵਿਚਾਰਾਂ ਦੀ ਬਪਤਿਸ਼ਮਾ ਕਰ ਸਕਦੇ ਹਨ:
ਇਹ ਲੱਛਣ ਅਕਸਰ ਉਸ ਲੋਕਾਂ ਲਈ ਐਕੋਸਿਸਟਮ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜਿੱਥੇ ਅਨੁਭਵ ਸਸਤਾ ਹੁੰਦਾ ਹੈ, ਪ੍ਰੋਟੋਟਾਈਪ ਤੇਜ਼ੀ ਨਾਲ ਉਤਪਾਦ ਬਣਦੇ ਹਨ, ਅਤੇ ਟੀਮਾਂ ਤਬਦੀਲੀਆਂ ਦੇ ਸਮੇਂ ਅਨੁਕੂਲ ਹੋ ਸਕਦੀਆਂ ਹਨ।
Lisp ਦੀ ਸ਼ੁਰੂਆਤ ਇੱਕ ਬਹੁਤ ਪ੍ਰਯੋਗਿਕ ਡਿਜ਼ਾਈਨ ਸਮੱਸਿਆ ਨਾਲ ਹੋਈ: ਤੁਹਾਡੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਸੰਕੇਤਾਂ ਨਾਲ ਉਹਨਾਂ ਹੀ ਤਰੀਕਿਆਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਣਾ ਜਿਵੇਂ ਉਹ ਨੰਬਰਾਂ ਨਾਲ ਕਰਦੇ ਹਨ।
McCarthy "ਇੱਕ ਬਿਹਤਰ ਕੈਲਕੁਲੇਟਰ" ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ। ਉਹ ਇੱਛਾ ਰੱਖਦਾ ਸੀ ਕਿ ਇੱਕ ਪ੍ਰਕਾਟ ਜਿਵੇਂ (is (parent Alice Bob)) ਨੂੰ (+ 2 3) ਦੀ ਤਰ੍ਹਾਂ ਆਸਾਨੀ ਨਾਲ ਸੰਭਾਲਿਆ, ਜਾਂਚਿਆ ਅਤੇ ਤਬਦੀਲ ਕੀਤਾ ਜਾ ਸਕੇ।
ਮੁੱਖ ਤਰਜੀਹ ਇਹ ਸੀ ਕਿ ਸੰਕੇਤਕ ਜਾਣਕਾਰੀ ਨੂੰ ਦਰਸਾਉਣਾ ਅਤੇ ਮਨਿਪੁਲੇਟ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇ। ਇਸ ਨੇ ਲਿਸਟਾਂ ਅਤੇ ਟ੍ਰੀ-ਤਰ੍ਹਾਂ ਦੀ ਸੰਰਚਨਾ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਨ ਦਿਤਾ, ਕਿਉਂਕਿ ਉਹ ਚੀਜ਼ਾਂ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ ਜਿਹਨਾਂ ਨੂੰ ਮਨੁੱਖ ਅਰਥ ਜਤਾਉਣ ਲਈ ਵਰਤਦੇ ਹਨ: ਵਾਕ, ਤਰਕ, ਨੇਸਟ ਵਰਗ, ਅਤੇ ਸੰਬੰਧ।
ਇੱਕ ਹੋਰ ਲਕਸ਼ ਸੀ ਭਾਸ਼ਾ ਦੇ ਮੁੱਖ ਹਿੱਸੇ ਨੂੰ ਛੋਟਾ ਅਤੇ ਸੰਗਤ ਰੱਖਣਾ। ਜਦੋਂ ਇੱਕ ਭਾਸ਼ਾ ਵਿੱਚ ਘੱਟ “ਖਾਸ ਮਾਮਲੇ” ਹੁੰਦੇ ਹਨ, ਤੁਸੀਂ ਨਿਯਮਾਂ ਯਾਦ ਕਰਨ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਗੁਜਾਰਦੇ ਹੋ ਅਤੇ ਆਇਡੀਆਜ਼ ਮਿਲਾ ਕੇ ਵੱਧ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ। Lisp ਨੇ ਕੁਝ ਹੀ ਮੁੱਖ ਇਲਾਕਿਆਂ 'ਤੇ ਭਰੋਸਾ ਕੀਤਾ ਜੋ ਵੱਡੇ ਅਭਿਆਸ ਬਣ ਸਕਦੇ ਸੀ।
ਇੱਕ ਮੁੱਖ ਅਹਸਾਸ ਇਹ ਸੀ ਕਿ ਪ੍ਰੋਗਰਾਮ ਅਤੇ ਡੇਟਾ ਇੱਕੋ ਜਿਹੇ ਢਾਂਚੇ ਸਾਂਝੇ ਕਰ ਸਕਦੇ ਹਨ। ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਜੇ ਤੁਹਾਡਾ ਡੇਟਾ ਇੱਕ ਨੇਸਟ ਲਿਸਟ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ ਵੀ ਇੱਕ ਨੇਸਟ ਲਿਸਟ ਹੋ ਸਕਦਾ ਹੈ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ:
Lisp ਨੇ ਇਹ ਦਿੱਖਾਰੀ ਕਿ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਇੱਕ-ਸਾਈਜ਼-ਸਭ ਲਈ ਨਹੀਂ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ। ਉਹ 특정 ਸਮੱਸਿਆ ਖੇਤਰ—ਜਿਵੇਂ ਤਰਕ, ਖੋਜ, ਅਤੇ ਗਿਆਨ ਪ੍ਰਤੀਨਿਧੀ—ਦੇ ਆਸਪਾਸ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਅਤੇ ਫਿਰ ਵੀ ਦਹਾਕਿਆਂ ਤੱਕ ਸਧਾਰਣ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ 'ਤੇ ਪ੍ਰਭਾਵ ਸਕਦਾ ਹੈ।
S-expressions (symbolic expressions ਲਈ ਛੋਟਾ ਨਾਮ) Lisp ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਹਨ: ਕੋਡ ਅਤੇ ਡੇਟਾ ਨੂੰ ਨੇਸਟ ਲਿਸਟਾਂ ਵਜੋਂ ਦਰਸਾਉਣ ਦਾ ਇੱਕ ਇਕਸਾਰ ਤਰੀਕਾ।
ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ, S-expression ਸਿਰਫ਼ ਆਈਟਮਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕੋਢੀਆਂ ਹਨ—ਕੁਝ ਆਈਟਮਾਂ ਐਟਮ ਹਨ (ਨਾਮ ਅਤੇ ਨੰਬਰ), ਕੁਝ ਆਈਟਮਾਂ ਖ਼ੁਦ ਲਿਸਟ ਹਨ। ਉਹ “ਲਿਸਟਾਂ ਦੇ ਅੰਦਰ ਲਿਸਟ” ਨਿਯਮ ਹੀ ਮੁੱਖ ਬਿੰਦੂ ਹੈ।
ਕਿਉਂਕਿ ਸੰਰਚਨਾ ਇਕਸਾਰ ਹੈ, Lisp ਪ੍ਰੋਗਰਾਮ ਆਰੰਭ ਤੋਂ ਹੀ ਇੱਕੋ ਹੀ ਬਲਾਕਾਂ ਤੋਂ ਬਣਦੇ ਹਨ। ਇੱਕ ਫੰਕਸ਼ਨ ਕਾਲ, ਇੱਕ ਕਨਫਿਗਰੇਸ਼ਨ-ਨੁਮਾ ਡੇਟਾ ਟੁੱਕੜਾ, ਅਤੇ ਪ੍ਰੋਗਰਾਮ ਸਟ੍ਰਕਚਰ ਦਾ ਟੁਕੜਾ—ਸਭ ਇੱਕ ਲਿਸਟ ਵਜੋਂ ਦਰਸਾਏ ਜਾ ਸਕਦੇ ਹਨ।
ਉਹ ਇਕਸਾਰਤਾ ਤੁਰੰਤ ਫਾਇਦਾ ਦਿੰਦੀ ਹੈ:
ਜੇ ਤੁਸੀਂ ਕਦੇ Lisp ਨਹੀਂ ਲਿਖਦੇ, ਇਹ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਡਿਜ਼ਾਈਨ ਸਬਕ ਹੈ: ਜਦੋਂ ਕੋਈ ਸਿਸਟਮ ਇੱਕ ਜਾਂ ਦੋ ਪੇਸ਼ਕਦਮ ਰੂਪਾਂ ਤੋਂ ਬਣਿਆ ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਘੱਟ ਸਮਾਂ ਏਜ ਕੇਸਾਂ ਨਾਲ ਲੜਦੇ ਹੋ ਅਤੇ ਵੱਧ ਸਮਾਂ ਨਵੇਂ ਚੀਜ਼ਾਂ ਬਣਾਉਣ 'ਚ ਲਗਾਉਂਦੇ ਹੋ।
S-expressions ਰਚਨਾ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਛੋਟੇ, ਪੜ੍ਹਨਯੋਗ ਹਿੱਸੇ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵੱਡੀਆਂ ਚੀਜ਼ਾਂ ਵਿੱਚ ਮਿਲਦੇ ਹਨ। ਜਦੋਂ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ "ਸਿਰਫ਼ ਨੇਸਟ ਲਿਸਟਾਂ" ਹੋਵੇ, ਆਈਡੀਆਜ਼ ਨੂੰ ਜੋੜਨਾ ਅਕਸਰ ਇੱਕ ਅਭਿਵਿੱਕਤੀ ਨੂੰ ਦੂਜੇ ਦੇ ਅੰਦਰ ਨੇਸਟ ਕਰਨ ਜਾਂ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਹਿੱਸਿਆਂ ਤੋਂ ਲਿਸਟ ਬਣਾਉਣ ਦੇ ਤੌਰ 'ਤੇ ਹੁੰਦਾ ਹੈ।
ਇਸ ਨਾਲ ਤੁਸੀਂ ਮੋਡੀਊਲਰ ਅੰਦਾਜ਼ ਵੱਲ ਧਕੇ ਜਾਦੇ ਹੋ: ਤੁਸੀਂ ਛੋਟੇ ਕਾਰਜ ਲਿਖਦੇ ਹੋ ਜੋ ਇੱਕ ਕੰਮ ਕਰਦੇ ਹਨ, ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਇਕੱਠੇ ਕਰਕੇ ਵੱਡੀ ਨੀਅਤ ਪ੍ਰਗਟ ਕਰਦੇ ਹੋ।
ਸਪਸ਼ਟ ਨੁਕਸਾਨ ਅਜਿਹੀ ਅਜੀਬਤਾ ਹੈ। ਨਵ ਆਏ ਵਿਅਕਤੀਆਂ ਲਈ, ਕੋਠੜੀਆਂ-ਭਰਿਆ ਸਿੰਟੈਕਸ ਅਜੀਬ ਲੱਗ ਸਕਦਾ ਹੈ।
ਪਰ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਇਹ ਨਿਰਣਯਕਤਾ ਹੈ: ਇੱਕ ਵਾਰੀ ਤੁਸੀਂ ਨੇਸਟਿੰਗ ਨਿਯਮ ਸਮਝ ਲੈਂਦੇ ਹੋ, ਤੁਸੀਂ ਪ੍ਰੋਗ੍ਰਾਮ ਦੀ ਸੰਰਚਨਾ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਵੇਖ ਸਕਦੇ ਹੋ—ਅਤੇ ਟੂਲ ਵੀ। ਉਹ ਸਾਫ਼ਗਿਆਈ Lisp ਦੇ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਫੈਲਾਉਣ ਦਾ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ।
ਰੀਕਰਸ਼ਨ ਨੂੰ ਇੱਕ ਰੋਜ਼ਮਰਰਾ ਉਦਾਹਰਨ ਨਾਲ ਸਮਝਣਾ ਆਸਾਨ ਹੈ: ਇੱਕ ਗੰਦਾ ਕਮਰਾ ਸਾਫ਼ ਕਰਨਾ, ਪਰ ਇਸਨੂੰ ਛੋਟੇ-ਛੋਟੇ "ਕਮਰੇ" ਵਿੱਚ ਵੰਡਕੇ। ਤੁਸੀਂ ਸਭ ਕੁਝ ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਹੱਲ ਨਹੀਂ ਕਰਦੇ। ਤੁਸੀਂ ਇੱਕ ਚੀਜ਼ ਚੁੱਕਦੇ ਹੋ, ਉਸਨੂੰ ਠੀਕ ਜਗ੍ਹਾ ਰੱਖਦੇ ਹੋ, ਫਿਰ ਬਾਕੀ 'ਤੇ ਉਹੀ ਕਦਮ ਦੁਹਰਾਉਂਦੇ ਹੋ। ਕਦਮ ਸਧਾਰਣ ਹਨ; ਸ਼ਕਤੀ ਉਹਨਾਂ ਨੂੰ ਦੁਹਰਾਉਣ ਵਿੱਚ ਹੈ ਜਦ ਤੱਕ ਕੁਝ ਬچہ ਨਹੀਂ ਰਹਿ ਜਾਂਦਾ।
Lisp ਇਸ ਵਿਚਾਰ ਦਾ ਜੋਰ ਇਸ ਲਈ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸ ਦਾ ਬਹੁਤ ਸਾਰਾ ਡੇਟਾ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਲਿਸਟਾਂ ਤੋਂ ਬਣਿਆ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਲਿਸਟ ਦਾ "ਪਹਿਲਾ ਤੱਤ" ਅਤੇ "ਬਾਕੀ" ਹੁੰਦੀ ਹੈ। ਉਹ ਆਕਾਰ ਰੀਕਰਸ਼ਨਲ ਸੋਚ ਲਈ ਬਹੁਤ موزੂ ਹੈ।
ਇੱਕ ਲਿਸਟ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਪਹਿਲੇ ਤੱਤ ਨੂੰ ਹੈਂਡਲ ਕਰਦੇ ਹੋ, ਫਿਰ ਉਸੇ ਲਾਜਿਕ ਨੂੰ ਬਾਕੀ 'ਤੇ ਲਗਾਉਂਦੇ ਹੋ। ਜਦੋਂ ਲਿਸਟ ਖਾਲੀ ਹੋ ਜਾਵੇ, ਤੁਸੀਂ ਰੁਕਦੇ ਹੋ—ਇਹ ਸਾਫ਼ "ਕੁਝ ਬਚਿਆ ਨਹੀਂ" ਪਲ ਹੀ ਰੀਕਰਸ਼ਨ ਨੂੰ ਸਮਝਦਾਰ ਬਣਾਉਂਦਾ ਹੈ।
ਮੰਨੋ ਤੁਹਾਨੂੰ ਨੰਬਰਾਂ ਦੀ ਇੱਕ ਲਿਸਟ ਦਾ ਜਮ੍ਹਾਂ ਚਾਹੀਦਾ ਹੈ।
ਇਨੀ ਗੱਲ। ਵਿਆਖਿਆ ਆਮ ਅੰਗਰੇਜ਼ੀ ਵਾਂਗ ਪੜ੍ਹਦੀ ਹੈ, ਅਤੇ ਪ੍ਰੋਗਰਾਮ ਦਾ ਢਾਂਚਾ ਵੀ ਇਸ ਵਿਚਾਰ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।
ਸੰਕੇਤਕ AI ਅਕਸਰ ਪ੍ਰਗਟਾਵਾਂ ਨੂੰ ਟਰੀ-ਤਰ੍ਹਾਂ ਦੀਆਂ ਸੰਰਚਨਾਵਾਂ ਵਜੋਂ ਦਰਸਾਉਂਦਾ ਹੈ (ਇੱਕ ਓਪਰੇਟਰ ਜਿਸਦੇ ਨਾਲ ਉਪ-ਅਭਿਵਿੱਕਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ)। ਰੀਕਰਸ਼ਨ ਉਸ ਟਰੀ 'ਤੇ "ਚੱਲਣ" ਦਾ ਕੁਦਰਤੀ ਤਰੀਕਾ ਹੈ: ਖੱਬੇ ਹਿੱਸੇ ਨੂੰ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਅੰਕਣ ਕਰੋ ਜਿਵੇਂ ਤੁਸੀਂ ਸੱਜੇ ਹਿੱਸੇ ਨੂੰ ਕਰਦੇ ਹੋ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਜਾਰੀ ਰੱਖੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ ਮੁੱਲ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੇ।
ਇਹ ਪੈਟਰਨਜ਼ ਬਾਅਦ ਵਿੱਚ ਫੰਕਸ਼ਨਲ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਰੂਪ ਦੇਣ ਵਿੱਚ ਮਦਦਗਾਰ ਸਾਬਤ ਹੋਏ: ਛੋਟੇ ਫੰਕਸ਼ਨ, ਸਾਫ਼ ਬੇਸ ਕੇਸ, ਅਤੇ ਐਸੀ ਡੇਟਾ ਤਬਦੀਲੀਆਂ ਜੋ ਸੋਚਣ ਵਿੱਚ ਆਸਾਨ ਹਨ। Lisp ਤੋਂ ਬਾਹਰ ਵੀ, "ਇੱਕ ਕਦਮ ਕਰੋ ਫਿਰ ਬਾਕੀ 'ਤੇ ਦੁਹਰਾਓ" ਦੀ ਆਦਤ ਸਾਫ਼ ਕੋਡ ਅਤੇ ਘੱਟ ਪਾਸੇ ਪ੍ਰਭਾਵ ਵਾਲੇ ਨਤੀਜੇ ਦਿੰਦੀ ਹੈ।
ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਗਰਾਮਰ ਅਕਸਰ ਮੈਮੋਰੀ ਨੂੰ ਹੱਥੋਂ-ਹੱਥ ਸੰਭਾਲਦੇ ਸਨ: ਜਗ੍ਹਾ ਅਲੋਕੇਟ ਕਰਨਾ, ਕਿਸਦੀ "ਮਾਲਕੀ" ਹੈ ਇਹ ਟ੍ਰੈਕ ਕਰਨਾ, ਅਤੇ ਠੀਕ ਸਮੇਂ ਤੇ ਉਸਨੂੰ ਮੁਕਤ ਕਰਨਾ ਯਾਦ ਰੱਖਣਾ। ਇਹ ਕੰਮ ਸਿਰਫ਼ ਵਿਕਾਸ ਨੂੰ ਧੀਮਾ ਨਹੀਂ ਕਰਦਾ—ਇਹ ਇੱਕ ਖ਼ਾਸ ਕਿਸਮ ਦੀਆਂ ਬੱਗਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਦੁਬਾਰਾ ਬਣਾਉਣ ਵਿੱਚ ਔਖੀਆਂ ਅਤੇ ਛੱਡਣ ਵਿੱਚ ਆਸਾਨ ਹਨ: ਲੀਕ ਜਿਹੜੀਆਂ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਘਟਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਡੈਂਗਲਿੰਗ ਪੌਇੰਟਰ ਜੋ ਅਸਲ ਗਲਤੀ ਤੋਂ ਬਹੁਤ ਬਾਅਦ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਕਰੈਸ਼ ਕਰ ਦਿੰਦੇ ਹਨ।
John McCarthy ਨੇ Lisp ਲਈ ਗਾਰਬੇਜ ਕਲੈਕਸ਼ਨ ਪੇਸ਼ ਕੀਤਾ ਤਾਂ ਜੋ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਬੁੱਕਕੀਪਿੰਗ ਦੀ ਥਾਂ ਅਰਥ 'ਤੇ ਧਿਆਨ ਦੇਣ ਦਿੱਤਾ ਜਾ ਸਕੇ।
ਉਹਦਾ ਉੱਚ-ਸਤਹੀ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ GC ਆਪਣੇ ਆਪ ਉਹ ਮੈਮੋਰੀ ਦੇ ਟੁਕੜੇ ਲੱਭ ਲੈਂਦਾ ਹੈ ਜੋ ਚੱਲ ਰਹੇ ਪ੍ਰੋਗਰਾਮ ਤੋਂ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਰਹੇ—ਉਹ ਮੁੱਲ ਜੋ ਹੁਣ ਕਦੇ ਵੀ ਵਰਤੇ ਨਹੀਂ ਜਾ ਸਕਦੇ—and ਉਨ੍ਹਾਂ ਦੀ ਥਾਂ ਵਾਪਸ ਲੈ ਲੈਂਦਾ ਹੈ।
"ਕੀ ਅਸੀਂ ਹਰ ਆਬਜੈਕਟ ਨੂੰ ਬਿਲਕੁਲ ਇਕ ਵਾਰੀ ਮੁਕਤ ਕੀਤਾ?" ਪੁੱਛਣ ਦੀ ਬਜਾਏ, GC ਸਵਾਲ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ: "ਕੀ ਇਹ ਆਬਜੈਕਟ ਅਜੇ ਵੀ ਪਹੁੰਚਯੋਗ ਹੈ?" ਜੇ ਨਹੀਂ, ਤਾਂ ਇਹ ਕੂੜਾ ਮਨਿਆ ਜਾਂਦਾ ਹੈ।
ਸੰਕੇਤਕ AI ਕੰਮ ਲਈ, Lisp ਪ੍ਰੋਗਰਾਮ ਅਕਸਰ ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀਆਂ ਲਿਸਟਾਂ, ਟ੍ਰੀਜ਼ ਅਤੇ ਮਧ੍ਯਵਰਤੀ ਨਤੀਜੇ ਬਣਾਉਂਦੇ ਹਨ। ਹੱਥੋਂ-ਹੱਥ ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਅਨੁਸ਼ੀਲਨ ਨੂੰ ਇੱਕ ਲਗਾਤਾਰ ਲੜੀਬੱਧ ਮੁਕਾਬਲੇ ਵਿੱਚ ਬਦਲ ਦੇਵੇਗਾ।
GC ਦੈਨੀਕ ਅਨੁਭਵ ਬਦਲ ਦਿੰਦਾ ਹੈ:
ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਇੱਕ ਭਾਸ਼ਾ ਫੀਚਰ ਇੱਕ ਟੀਮ ਗੁਣਾ-ਵੱਧਾ ਹੋ ਸਕਦੀ ਹੈ: ਰਹੱਸਮਈ ਤਰ੍ਹਾਂ ਡਾਟਾ ਕਰਪਸ਼ਨ ਠੀਕ ਕਰਨ ਵਿੱਚ ਘੱਟ ਘੰਟੇ ਲੱਗਦੇ ਹਨ ਤਾਂ ਵਿਕਾਸ ਵਾਸਤੇ ਵਧੇਰੇ ਸਮਾਂ ਮਿਲਦਾ ਹੈ।
McCarthy ਦੀ ਚੋਣ Lisp ਦੇ ਅੰਦਰ ਹੀ ਨਾ ਰਹੀ। ਬਹੁਤ ਸਾਰੇ ਬਾਅਦ ਵਾਲੇ ਸਿਸਟਮਾਂ ਨੇ GC (ਅਤੇ ਇਸ ਦੇ ਵੱਖ-ਵੱਖ ਰੂਪ) ਨੂੰ ਗ੍ਰਹਿਰਿਤ ਕੀਤਾ ਕਿਉਂਕਿ ਇਹ ਟਰੇਡ-ਆਫ ਅਕਸਰ ਆਪਣੇ ਆਪ ਨੂੰ ਵਾਪਸ ਕਰਦਾ ਹੈ: Java, C#, Python, JavaScript ਰਨਟਾਈਮ, ਅਤੇ Go ਸਭ ਗਾਰਬੇਜ ਕਲੈਕਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਹਨ ਤਾਂ ਜੋ ਵੱਡੇ ਪੱਧਰ ਦੇ ਵਿਕਾਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਤੇਜ਼ ਬਣਾਇਆ ਜਾ ਸਕੇ—ਭਾਵੇਂ ਪ੍ਰਦਰਸ਼ਨ ਇੱਕ ਪ੍ਰਾਥਮਿਕਤਾ ਹੋਵੇ।
Lisp ਵਿੱਚ, ਇੱਕ ਇਕਸਪ੍ਰੈਸ਼ਨ ਇੱਕ ਕੋਡ ਦਾ ਟੁਕੜਾ ਹੈ ਜੋ ਇੱਕ ਨਿਰੰਤਰ ਆਕਾਰ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੁੰਦਾ ਹੈ (ਅਕਸਰ ਇੱਕ ਲਿਸਟ)। ਇਵੈਲੂਏਸ਼ਨ ਸਿਰਫ਼ ਇਹ ਪ੍ਰਕਿਰਿਆ ਹੈ ਕਿ ਉਸ ਇਕਸਪ੍ਰੈਸ਼ਨ ਦਾ ਕੀ ਮਤਲਬ ਹੈ ਅਤੇ ਇਹ ਕੀ ਉਤਪੰਨ ਕਰਦਾ ਹੈ, ਇਹ ਨਿਰਣੀਤ ਕੀਤਾ ਜਾਵੇ।
ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਤੁਸੀਂ "ਇਨ੍ਹਾਂ ਨੰਬਰਾਂ ਨੂੰ ਜੋੜੋ" ਜਾਂ "ਇਸ ਫੰਕਸ਼ਨ ਨੂੰ ਇਹਨਾਂ ਇਨਪੁੱਟ ਨਾਲ ਕਾਲ ਕਰੋ" ਲਿਖਦੇ ਹੋ, ਤਾਂ ਇਵੈਲੂਏਟਰ ਇੱਕ ਛੋਟੀ ਸੋਚ-ਗਿਣਤੀ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਉਸ ਇਕਸਪ੍ਰੈਸ਼ਨ ਨੂੰ ਨਤੀਜੇ ਵਿੱਚ ਬਦਲ ਸਕੇ। ਇਸਨੂੰ ਭਾਸ਼ਾ ਦਾ ਨਿਰਣੇਯਕ (referee) ਸਮਝੋ: ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਅਗਲਾ ਕੀ ਕਰਨਾ ਹੈ, ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ, ਅਤੇ ਕਦੋਂ ਰੁਕਣਾ ਹੈ।
McCarthy ਦੀ ਕੁੰਜੀ ਚਾਲ ਸਿਰਫ਼ ਨਵਾਂ ਸਿੰਟੈਕਸ ਬਣਾਉਣਾ ਨਹੀਂ ਸੀ—ਇਸਨੇ "ਅਰਥ-ਇੰਜਣ" (evaluator) ਨੂੰ ਸੰਕੁਚਿਤ ਅਤੇ ਨਿਯਮਤ ਰੱਖਿਆ। ਜਦੋਂ ਇਵੈਲੂਏਟਰ ਕੁਝ ਸਾਫ਼ ਨਿਯਮਾਂ ਤੋਂ ਬਣਿਆ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਦੋ ਚੰਗੀਆਂ ਗੱਲਾਂ ਹੁੰਦੀਆਂ ਹਨ:
ਇਹ ਇਕਸਾਰਤਾ ਇੱਕ ਕਾਰਨ ਹੈ ਕਿ Lisp ਸੰਕੇਤਕ AI ਵਿਚ ਵਿਚਾਰਾਂ آزਮਾਉਣ ਲਈ ਇੱਕ ਖੇਡ ਦਾ ਮੈਦਾਨ ਬਣ ਗਿਆ: ਖੋਜਕਾਰ ਨਵੇਂ ਪ੍ਰਸਤੁਤੀਆਂ ਅਤੇ ਨਿਯੰਤਰਣ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਟੈਸਟ ਕਰ ਸਕਦੇ ਸਨ, ਬਿਨਾਂ ਕਿਸੇ ਕੰਪਾਇਲਰ ਟੀਮ ਦੀ ਉਡੀਕ ਕੀਤੇ।
Macros Lisp ਦਾ ਤਰੀਕਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਮੁੜ-ਉਪਯੋਗ ਕੋਡ ਦੀਆਂ ਰਚਨਾਵਾਂ ਨੂੰ ਆਟੋਮੇਟ ਕਰਨ ਦਿੰਦਾ ਹੈ, ਸਿਰਫ਼ ਮੁੱਲਾਂ ਨੂੰ ਨਹੀਂ। ਜਿੱਥੇ ਇੱਕ ਫੰਕਸ਼ਨ ਤੁਹਾਨੂੰ ਗਣਨਾਵਾਂ ਨੂੰ ਦੁਹਰਾਉਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ, ਇੱਕ macro ਤੁਹਾਨੂੰ "ਰਚਨਾਵਾਂ" ਨੂੰ ਦੁਹਰਾਉਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ—ਆਮ ਪੈਟਰਨ ਜਿਵੇਂ "X ਕਰੋ, ਪਰ ਇਸਨੂੰ ਲੌਗ ਵੀ ਕਰੋ" ਜਾਂ "ਨਿਯਮਾਂ ਲਈ ਇੱਕ ਛੋਟੀ DSL ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ"।
ਵਰਤੋਂਦਾ ਪ੍ਰਭਾਵ ਇਹ ਹੈ ਕਿ Lisp ਅੰਦਰ ਹੀ ਨਵੇਂ ਸੁਵਿਧਾਵਾਂ ਬਣ ਸਕਦੀਆਂ ਹਨ। ਕਈ ਆਧੁਨਿਕ ਟੂਲ ਇਸ ਵਿਚਾਰ ਦੀ ਅਨੁਕਰਣ ਕਰਦੇ ਹਨ—ਟੈਮਪਲੇਟ ਸਿਸਟਮ, ਕੋਡ ਜਨਰੇਟਰ, ਅਤੇ ਮੈਟਾ-ਪ੍ਰੋਗਰੈਮਿੰਗ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ—ਕਿਉਂਕਿ ਉਹੋ ਹੀ ਮਕਸਦ ਸੇਵਾ ਕਰਦੇ ਹਨ: ਤੇਜ਼ ਅਜ਼ਮਾਇਸ਼ ਅਤੇ ਸਾਫ਼ ਇਰਾਦਾ।
ਜੇ ਤੁਸੀਂ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇਹ ਮਨੋਭਾਵ ਰੋਜ਼ਮਰਰਾ ਵਿਕਾਸ ਵਰਕਫਲੋ 'ਤੇ ਕਿਵੇਂ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ, ਤਾਂ ਵੇਖੋ /blog/the-repl-and-fast-feedback-loops।
Lisp ਦੀ ਇੱਕ ਵੱਡੀ ਖਿੱਚ ਸਿਰਫ਼ ਭਾਸ਼ਾ ਨਹੀਂ ਸੀ—ਇਹ ਇਹ ਸੀ ਕਿ ਤੁਸੀਂ ਇਸਦੇ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹੋ। Lisp ਨੇ REPL: Read–Eval–Print Loop ਨੂੰ ਪ੍ਰਸਿੱਧ ਕੀਤਾ। ਆਮ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇਹ ਕੰਪਿਊਟਰ ਨਾਲ ਗੱਲ-ਬਾਤ ਵਾਂਗ ਹੈ। ਤੁਸੀਂ ਇਕ ਇਕਸਪ੍ਰੈਸ਼ਨ ਟਾਈਪ ਕਰਦੇ ਹੋ, ਸਿਸਟਮ ਉਸਨੂੰ ਤੁਰੰਤ ਚਲਾਉਂਦਾ ਹੈ, ਨਤੀਜਾ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਅਗਲੇ ਇਨਪੁੱਟ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ।
ਸੰਪੂਰਨ ਪ੍ਰੋਗਰਾਮ ਲਿਖਣ, ਕੰਪਾਇਲ ਕਰਨ, ਚਲਾਉਣ, ਅਤੇ ਫਿਰ ਟੁੱਟੀ ਹੋਈ ਗੱਲ ਖੋਜਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਵਿਚਾਰਾਂ ਨੂੰ ਇੱਕ-ਇਕ ਕਦਮ ਵਿੱਚ ਅਜ਼ਮਾ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਇੱਕ ਫੰਕਸ਼ਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਕੁਝ ਇਨਪੁੱਟ ਨਾਲ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ, ਸੋਧ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਮੁੜ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ—ਸਾਰੇ ਸਕਿੰਟਾਂ ਵਿੱਚ।
ਇਹ ਰਿਦਮ ਅਜ਼ਮਾਇਸ਼ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਸ਼ੁਰੂਆਤੀ AI ਕੰਮ ਲਈ ਬਹੁਤ ਮੱਤਵਪੂਰਨ ਸੀ ਜਿੱਥੇ ਅਕਸਰ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸਹੀ ਰਾਹ ਪਤਾ ਨਹੀਂ ਹੋਦਾ।
ਤੇਜ਼ ਫੀਡਬੈਕ "ਵੱਡੀਆਂ ਸ਼ਰਤਾਂ" ਨੂੰ "ਛੋਟੇ ਚੈੱਕ" ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਰਿਸਰਚ ਲਈ, ਇਹ ਪਰਿਕਲਪਨ들을 ਖੋਜਣਾ ਅਤੇ ਦਰਮਿਆਨੀ ਨਤੀਜਿਆਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਪ੍ਰੋਡਕਟ ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਲਈ, ਇਹ ਇਟਰੇਸ਼ਨ ਦੀ ਲਾਗਤ ਘਟਾਉਂਦਾ ਹੈ: ਤੁਸੀਂ ਅਸਲ ਡੇਟਾ ਨਾਲ ਵਿਹਾਰ ਸੱਚਚਾਈ ਦੀ ਜਾਂਚ ਜਲਦੀ ਕਰ ਸਕਦੇ ਹੋ, ਐਜ ਕੇਸ ਜਲਦੀ ਨੋਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਲੰਬੇ ਬਿਲਡ ਚੱਕਰਾਂ ਦਾ ਇੰਤਜ਼ਾਰ ਕੀਤੇ ਬਿਨਾਂ ਫੀਚਰ ਸਾਫ਼ ਕਰ ਸਕਦੇ ਹੋ।
ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਆਧੁਨਿਕ vibe-coding ਟੂਲ ਆਕਰਸ਼ਕ ਹਨ: ਉਹ ਮੂਲ ਰੂਪ ਵਿੱਚ ਇੱਕ ਜ਼ੋਰਦਾਰ ਫੀਡਬੈਕ-ਲੂਪ ਕੰਪ੍ਰੈਸ਼ਨ ਹਨ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਇੱਕ ਚੈਟ ਇੰਟਰਫੇਸ ਵਰਤਦਾ ਹੈ (ਇੱਕ ਏਜੰਟ-ਅਧਾਰਿਤ ਆਰਕੀਟੈਕਚਰ ਹੇਠਾਂ) ਤਾਂ ਜੋ ਉਤਪਾਦ ਇਰਾਦੇ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦੇ ਵੈਬ, ਬੈਕਐਂਡ, ਜਾਂ ਮੋਬਾਈਲ ਕੋਡ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜਾਵੇ—ਅਕਸਰ "ਪਰాక్ → ਸੋਧ → ਫਿਰ ਕੋਸ਼ਿਸ਼" ਲੂਪ ਨੂੰ REPL ਵਾਂਗ ਕਾਰਜਕਾਰੀ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ।
REPL ਦਾ ਵਿਚਾਰ ਅੱਜੋਂ ਇਹਥੇ ਮਿਲਦਾ ਹੈ:
ਵੱਖ-ਵੱਖ ਟੂਲ, ਇਕੋ ਸਿਧਾਂਤ: ਸੋਚਣ ਅਤੇ ਦੇਖਣ ਵਿੱਚ ਫਾਸਲਾ ਘਟਾਓ।
ਟਿਮਾਂ ਨੂੰ REPL-ਜਿਹੇ ਵਰਕਫਲੋ ਜ਼ਿਆਦਾ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ ਜਦੋ ਉਹ ਅਣ-ਨਿਸ਼ਚਿਤ ਲੋੜਾਂ ਦੀ ਖੋਜ ਕਰ ਰਹੇ ਹੁੰ—ਡੇਟਾ-ਭਾਰਤ ਫੀਚਰ ਤਿਆਰ ਕਰ ਰਹੇ ਹੁੰ, API ਡਿਜ਼ਾਈਨ ਕਰ ਰਹੇ ਹੁੰ ਜਾਂ ਨਾਜ਼ੁਕ ਲਾਜਿਕ ਡੀਬੱਗ ਕਰ ਰਹੇ ਹੁੰ। ਜੇ ਕੰਮ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣ ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ—ਉਪਭੋਗਤਾ, ਡੇਟਾ, ਜਾਂ ਏਜ ਕੇਸ ਬਾਰੇ—ਤਾਂ ਇੰਟਰਐਕਟਿਵ ਫੀਡਬੈਕ ਇੱਕ ਵਿਕਾਰਕ ਨਹੀਂ; ਇਹ ਇੱਕ ਗੁਣਾ-ਵੱਧਾਉਣ ਵਾਲਾ ਹੈ।
Lisp ਨੇ ਹਰ ਰੋਜ਼ ਦੀyntax ਨਹੀਂ "ਜਿੱਤਿਆ"। ਇਹ ਇਨ੍ਹਾਂ ਵਿਚਾਰਾਂ ਨੂੰ ਬੀਜ ਰੂਪ ਵਿੱਚ ਫੈਲ ਗਿਆ ਜੋ ਬਹੁਤ ਸਾਰੇ ਪਰਿਸਰਾਂ ਵਿੱਚ ਆਮ ਹੋ ਗਏ।
ਵੇਹਲੇ ਸਿਫਾਰਸ਼ਾਂ ਜੋ Lisp ਮੂਲ ਰੂਪ ਵਿੱਚ ਮਾਨਤਾ ਸੀ—ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਮੁੱਲ ਵਜੋਂ ਲੈਣਾ, ਉੱਚ-ਕ੍ਰਮ ਸਰਗਰਮੀਆਂ, ਅਤੇ ਛੋਟੇ ਹਿੱਸਿਆਂ ਦੁਆਰਾ ਪ੍ਰੋਗ੍ਰਾਮ ਬਣਾਉਣਾ—ਹੁਣ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਭਾਵੇਂ ਕੋਈ ਭਾਸ਼ਾ Lisp ਵਰਗੀ ਨਹੀਂ ਲੱਗਦੀ, ਉਹ map/filter-ਸਟਾਈਲ ਤਬਦੀਲੀਆਂ, ਅਿਮਿਊਟੇਬਲ ਡੇਟਾ ਆਦਤਾਂ, ਅਤੇ ਰੀਕਰਸਨਲ ਸੋਚ (ਆਮ ਤੌਰ 'ਤੇ ਇਟਰੇਟਰ ਜਾਂ folds ਰਾਹੀਂ) ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਹੈ।
ਮੁੱਖ ਬਦਲਾਅ ਮਨ ਦਾ ਹੈ: ਡੇਟਾ ਤਬਦੀਲੀਆਂ ਨੂੰ ਪਾਈਪਲਾਈਨਾਂ ਵਜੋਂ ਦੇਖੋ, ਅਤੇ ਵਰਤਾਰ ਨੂੰ ਕੁਝ ਇੰਝ ਮੰਨੋ ਜੋ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਘੁਮਾ-ਫਿਰਾ ਸਕਦੇ ਹੋ।
Lisp ਨੇ ਕੋਡ ਨੂੰ ਡੇਟਾ ਵਜੋਂ ਦਰਸਾਉਣਾ ਆਸਾਨ ਕੀਤਾ। ਇਹ ਮਨੋਭਾਵ ਅੱਜ ਵੀ ASTs (abstract syntax trees) ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ—ਕੰਪਾਇਲਰ, ਫਾਰਮੈਟਰ, ਲਿੰਟਰ, ਅਤੇ ਕੋਡ ਜਨਰੇਟਰ ਲਈ। ਜਦੋਂ ਤੁਸੀਂ AST ਨਾਲ ਕੰਮ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ "ਕੋਡ-ਅਜ਼-ਡੇਟਾ" ਦੇ ਇੱਕ ਕਜ਼ਿਨ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹੁੰ।
ਉਹੀ ਸੰਕੇਤਕ ਰਵਈਆ ਪ੍ਰਯੋਗਿਕ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ: ਕਨਫ਼ਿਗ ਫਾਰਮੈਟ, ਟੈਮਪਲੇਟਿੰਗ ਸਿਸਟਮ, ਅਤੇ ਬਿਲਡ ਪਾਈਪਲਾਈਨਾਂ—ਸਾਰੇ ਢਾਂਚੇ ਉოპਯੋਗ ਕਰਦੇ ਹਨ ਜੋ ਟੂਲ ਇੰਸਪੈਕਟ, ਤਬਦੀਲ ਅਤੇ ਵੈਧਤਾ ਕਰ ਸਕਦੇ ਹਨ।
ਆਧੁਨਿਕ Lisp-ਪਰਿਵਾਰ ਦੀਆਂ ਭਾਸ਼ਾਵਾਂ (ਵਿਆਪਕ ਮੇਨ: ਆਧੁਨਿਕ Lisps ਅਤੇ Lisp-ਪ੍ਰੇਰਿਤ ਟੂਲ) ਅੰਦਰੂਨੀ DSLs ਬਣਾਉਣ 'ਤੇ ਅਸਰ ਛੱਡਦੇ ਰਹੇ—ਪ੍ਰੀਖਿਆ, ਡਿਪਲੋਇਮੈਂਟ, ਡੇਟਾ-ਹੈਂਡਲਿੰਗ, ਜਾਂ UI ਲਈ ਛੋਟੀ ਮਿਨੀ-ਭਾਸ਼ਾਵਾਂ।
Lisp ਤੋਂ ਬਾਹਰ, macro-ਸਿਸਟਮ, ਮੈਟਾ-ਪ੍ਰੋਗਰੈਮਿੰਗ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਅਤੇ ਕੋਡ-ਜਨਰੇਸ਼ਨ ਫ੍ਰੇਮਵਰਕ ਇੱਕੋ ਨਤੀਜੇ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ: ਸਮੱਸਿਆ ਅਨੁਸਾਰ ਭਾਸ਼ਾ ਵਿਚ ਵਿਸ਼ੇਸ਼ਤਾ ਜੋੜੋ।
ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਨਤੀਜਾ: ਸਿੰਟੈਕਸ ਦੀਆਂ ਪਸੰਦਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਪਰ ਟਿਕਾਊ ਵਿਚਾਰ—ਸੰਕੇਤਕ ਸੰਰਚਨਾ, ਜੋੜ-ਯੋਗ ਫੰਕਸ਼ਨ, ਅਤੇ ਵਧਾਉਣਯੋਗਤਾ—ਕਈ ਦਹਾਕਿਆਂ ਅਤੇ ਕੋਡਬੇਸਾਂ 'ਚ ਕਿਰਾਇਆ ਪ੍ਰਦਾਨ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ।
ਲਿਸਪ ਇਕ ਪ੍ਰਤਿਛਵੀ ਨਾਲ ਜੁਝਦਾ ਹੈ ਜੋ "ਬ੍ਰਿਲਿਯੰਟ" ਤੋਂ ਲੈ ਕੇ "ਅਪੜ੍ਹਯੋਗ" ਤਕ ਛਲਕਦਾ ਹੈ, ਅਕਸਰ ਦੂਸਰੇ ਹੱਥ ਦੀਆਂ ਛਾਪਾਂ 'ਤੇ ਆਧਾਰਿਤ। ਸੱਚਾਈ ਵਧੇਰੇ ਆਮ ਹੈ: Lisp ਕੁਝ ਚੋਣਾਂ ਕਰਦਾ ਹੈ ਜੋ ਠੀਕ ਸੈਟਿੰਗ ਵਿੱਚ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹਨ ਅਤੇ ਹੋਰਾਂ ਵਿੱਚ ਕਠਨ।
ਨਵੀਆਂ ਲਈ, Lisp ਦਾ ਇਕਸਾਰ syntax ਪ੍ਰੋਗਰਾਮ ਦੇ "ਅੰਦਰ" ਨੂੰ ਵੇਖਣ ਜਿਹਾ ਲੱਗ ਸਕਦਾ ਹੈ, ਨਾ ਕਿ ਤੈਅ ਕੀਤੀ ਸਤਹ। ਇਹ ਅਸਲੀ ਤਕਲੀਫ਼ ਹੈ, ਖਾਸ ਕਰਕੇ ਜੇ ਤੁਸੀਂ ਉਹ ਭਾਸ਼ਾਵਾਂ ਦੇ ਆਲੀ-ਦੁਆਲੀ ਆਦਤਾਂ ਦੇ ਆਦਤ ਹੋ।
ਤਾਰੀਖਕ ਤੌਰ 'ਤੇ, ਪਰ, Lisp ਦੀ ਬਣਤਰ ਹੀ ਮੁਕੱਦਮਾ ਹੈ: ਕੋਡ ਅਤੇ ਡੇਟਾ ਇੱਕੋ ਆਕਾਰ ਵਿੱਚ ਹੁੰਦੇ ਹਨ, ਜੋ ਕੋਡ ਨੂੰ ਬਦਲਣ, ਪੈਦਾ ਕਰਨ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ। ਚੰਗੀ ਐਡੀਟਰ ਸਹਾਇਤਾ (ਇੰਡੈਂਟ, ਸਟ੍ਰਕਚਰਲ ਨੈਵੀਗੇਸ਼ਨ) ਨਾਲ Lisp ਕੋਡ ਆਮ ਤੌਰ 'ਤੇ ਆਕਾਰ ਦੁਆਰਾ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ ਨਾ ਕਿ ਕੋਠੜੀਆਂ ਦੀ ਗਿਣਤੀ ਦੁਆਰਾ।
ਇੱਕ ਆਮ ਧਾਰਨਾ ਇਹ ਹੈ ਕਿ Lisp ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਧੀਮਾ ਹੈ। ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ, ਕੁਝ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਨੇ ਨੀਚਲੇ-ਸਤਹ ਭਾਸ਼ਾਵਾਂ ਦੇ ਮੁਕਾਬਲੇ ਝੱਲਣ ਦਾ ਸੰਘਰਸ਼ ਕੀਤਾ, ਅਤੇ ਡਾਇਨੈਮਿਕ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਕੁਝ ਓਵਰਹੈੱਡ ਪੈਦਾ ਕਰਦੀਆਂ।
ਪਰ ਇਹ ਠੀਕ ਨਹੀਂ ਕਿ "Lisp" ਨੂੰ ਇੱਕੋ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰੋਫਾਈਲ ਵਜੋਂ ਵੇਖਿਆ ਜਾਵੇ। ਬਹੁਤ ਸਾਰੀਆਂ Lisp ਸਿਸਟਮਾਂ ਨੇ ਕੰਪਾਇਲੇਸ਼ਨ, ਟਾਈਪ ਘੋਸ਼ਣਾਂ, ਅਤੇ ਗੰਭੀਰ ਅਨੁਕੂਲਨ ਦਾ ਸਮਰਥਨ ਕੀਤਾ ਹੈ। ਵਧੇਰੇ ਲਾਜਵਾਬ ਫਰੇਮ ਵਰਗੀਆਂ ਗੱਲਾਂ ਇਹ ਹਨ: ਤੁਹਾਨੂੰ ਮੈਮੋਰੀ ਲੇਆਉਟ, ਪ੍ਰਡਿਕਟੇਬਲ ਲੇਟੈਂਸੀ, ਜਾਂ ਕੱਚੇ ਥਰੂਪੁੱਟ 'ਤੇ ਕਿੰਨਾ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੈ—ਅਤੇ ਕੀ ਤੁਹਾਡੀ Lisp ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਉਹ ਲਕਸ਼ਾਂ ਟਾਰਗੇਟ ਕਰਦੀ ਹੈ?
ਇਕ ਹੋਰ ਵਾਜਬ ਆਲੋਚਨਾ ਹੈ ਇਕੋਸਿਸਟਮ ਫਿੱਟ। Lisp ਡਾਇਲੈਕਟ ਅਤੇ ਡੋਮੇਨ 'ਤੇ ਨਿਰਭਰ ਕਰਕੇ, ਲਾਇਬ੍ਰੇਰੀਆਂ, ਟੂਲਿੰਗ, ਅਤੇ ਹਾਇਰਿੰਗ ਪੂਲ ਮਹਿੰਗੇ ਹੋ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬੇਚਣਾ ਹੋ ਅਤੇ ਵੱਡੀ ਟੀਮ ਚਾਹੀਦੀ ਹੋ ਤਾਂ ਇਹ ਭਾਸ਼ਾ ਸੁੰਦਰਤਾ ਤੋਂ ਵੱਧ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦਾ ਹੈ।
Lisp ਨੂੰ ਸਟੀਰੀਓਟਾਈਪਾਂ ਨਾਲ ਨਿਆਂ ਨਹੀਂ ਕੀਤਾ जाना ਚਾਹੀਦਾ; ਉਸਦੇ ਮੂਲ ਵਿਚਾਰਾਂ ਨੂੰ ਅਲੱਗ ਕਰਕੇ ਦੇਖੋ: ਇਕਸਾਰਤਾ, ਇੰਟਰਐਕਟਿਵ ਵਿਕਾਸ, ਅਤੇ macros ਵਰਗੇ ਟੂਲ ਡੋਮੇਨ-ਨਿਰਧਾਰਿਤ ਅਭਿਆਸ ਬਣਾਉਣ ਲਈ। ਜੇਕਰ ਤੁਸੀਂ ਕਦੇ Lisp ਸਿਸਟਮ ਨੂੰ ਸ਼ਿਪ ਨਹੀਂ ਵੀ ਕਰਦੇ, ਇਹ ਧਾਰਨਾਵਾਂ ਤੁਹਾਡੇ ਸੋਚਣ ਦੇ ਢੰਗ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਸਾਫ਼ ਬਣਾ ਸਕਦੀਆਂ ਹਨ।
McCarthy ਸਾਡੇ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਇਤਿਹਾਸਕ ਭਾਸ਼ਾ ਨਹੀਂ ਛੱਡ ਕੇ ਗਿਆ—ਉਸ ਨੇ ਕੁਝ ਆਦਤਾਂ ਦਿੱਤੀਆਂ ਹਨ ਜੋ ਅਜੇ ਵੀ ਸੌਫਟਵੇਅਰ ਨੂੰ ਬਦਲਣ, ਸਮਝਾਉਣ ਅਤੇ ਵਧਾਉਣ ਵਿੱਚ ਅਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਸੋਚੋ ਕਿ ਸਧਾਰਨ ਕੋਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਬਜਾਏ ਚਤੁਰ ਸਤਹਾਂ ਦੇ। ਇੱਕ ਛੋਟੇ, ਆਪਸ ਵਿੱਚ ਆਰਥ-ਸੰਗਤ ਨਿਰਮਾਣ-ਬਲਾਕ ਸਿੱਖਣ ਯੋਗ ਅਤੇ ਭੰਗ-ਹੁੰਦੀਆਂ ਗੱਲਾਂ ਘੱਟ ਕਰਦਾ ਹੈ।
ਡੇਟਾ ਸ਼ੇਪਾਂ ਨੂੰ ਇਕਸਾਰ ਰੱਖੋ। ਜਦੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਇੱਕੋ ਪ੍ਰਤੀਨਿਧੀ ਸਾਂਝਾ ਕਰਦੀਆਂ ਹਨ (ਜਿਵੇਂ ਲਿਸਟ/ਟ੍ਰੀ), ਟੂਲਿੰਗ ਸਧਾਰਣ ਹੋ ਜਾਂਦੀ ਹੈ: ਪ੍ਰਿੰਟਰ, ਡੀਬੱਗਰ, ਸਰਿਅਲਾਈਜ਼ਰ, ਅਤੇ ਟ੍ਰਾਂਸਫਾਰਮਰ ਦਾ ਦੁਬਾਰਾ-ਵਰਤੋਂ ਹੋ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਲਾਭਦਾਇਕ ਹੋ ਤਦ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਡੇਟਾ ਸਮਝੋ (ਅਤੇ ਡੇਟਾ ਨੂੰ ਪ੍ਰੋਗਰਾਮ)। ਜੇ ਤੁਸੀਂ ਸਟ੍ਰਕਚਰਾਂ ਦੀ ਜਾਂਚ ਅਤੇ ਤਬਦੀਲੀ ਕਰ ਸਕਦੇ ਹੋ, ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰ, ਮਾਈਗਰੇਸ਼ਨ, ਅਤੇ ਕੋਡ ਜਨਰੇਟਰ ਬਣਾ ਸਕਦੇ ਹੋ।
ਬੋਰਿੰਗ ਕੰਮ ਨੂੰ ਆਟੋਮੇਟ ਕਰੋ। ਗਾਰਬੇਜ ਕਲੈਕਸ਼ਨ ਇਸਦਾ ਕਲਾਸਿਕ ਉਦਾਹਰਨ ਹੈ, ਪਰ ਵਿਆਪਕ ਬਿੰਦੂ ਇਹ ਹੈ: ਉਹ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਰੋਕੇ।
ਫੀਡਬੈਕ ਲੂਪਾਂ ਲਈ ਅਪਟੀਮਾਈਜ਼ ਕਰੋ। ਇੰਟਰਐਕਟਿਵ ਇਵੈਲੂਏਸ਼ਨ (REPL-ਸਟਾਈਲ) ਛੋਟੇ ਪ੍ਰਯੋਗ, ਤੇਜ਼ ਵੈਰੀਫਿਕੇਸ਼ਨ, ਅਤੇ ਵਿਹਾਰ ਬਾਰੇ ਚੰਗੀ ਧਾਰਣਾ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਹੈ।
ਵਧਾਉਣ ਯੋਗਤਾ ਨੂੰ ਪਹਿਲ-ਕੁੱੜੇ ਲਕਸ਼ ਬਣਾਓ। Lisp macros ਇੱਕ ਉਤਰ ਹਨ; ਹੋਰ ਪਰਿਸਰਾਂ ਵਿੱਚ ਇਹ ਪਲੱਗਇਨ, ਟੈਮਪਲੇਟ, DSLs, ਜਾਂ ਕੰਪਾਇਲ-ਟਾਈਮ ਟ੍�
ਸੰਕੇਤਕ ਸੋਚ ਸਿੱਧਾ ਧਾਰਣਾਵਾਂ ਅਤੇ ਸੰਬੰਧਾਂ ਦੀ ਪ੍ਰਤੀਨਿਧਤਾ ਕਰਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ “customer”, “is-a”, “depends-on”, “if…then…”), ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਪ੍ਰਸਤੁਤੀਆਂ 'ਤੇ ਨਿਯਮ ਅਤੇ ਤਬਦੀਲੀਆਂ ਲਾਗੂ ਕਰਦੀ ਹੈ。
ਇਹ ਉਸ ਸਮੇਂ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਜਦੋਂ ਤੁਹਾਡਾ ਮੁੱਦਾ ਢਾਂਚਾ, ਛੂਟਾਂ ਅਤੇ ਅਰਥ ਨਾਲ ਭਰਿਆ ਹੋਵੇ (ਨਿਯਮ ਇੰਜਣ, ਯੋਜਨਾ ਬਣਾਉਣਾ, ਕੰਪਾਈਲਰ, ਸੰਰਚਨਾ, ਵਰਕਫਲੋ ਲਾਜਿਕ), ਸਿਰਫ਼ ਗਣਿਤ ਨਹੀਂ।
McCarthy ਨੇ ਇਹ ਵਿਚਾਰ ਅੱਗੇ ਵਧਾਇਆ ਕਿ ਤਰਕਸ਼ੀਲਤਾ (reasoning) ਨੂੰ ਪ੍ਰੋਗਰਾਮਾਂ ਵਜੋਂ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ—ਸਿਰਫ਼ ਗਣਨਾ ਨਹੀਂ。
ਇਹ ਦਰਸ਼ਨ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ:
ਲਿਸਟਾਂ "ਹਿੱਸਿਆਂ ਵਾਲੀ ਚੀਜ਼" ਦਰਸਾਉਣ ਦਾ ਇੱਕ ਨਿਯੂਨਤਮ ਅਤੇ ਲਚਕੀਲਾ ਤਰੀਕਾ ਹਨ। ਕਿਉਂਕਿ ਲਿਸਟ ਦੇ ਤੱਤ ਖ਼ੁਦ ਲਿਸਟ ਹੋ ਸਕਦੇ ਹਨ, ਤੁਸੀਂ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਟ్రీ-ਸੰਰਚਨਾਵਾਂ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦੇ ਹੋ。
ਇਸ ਨਾਲ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ:
S-expressions ਤੁਹਾਨੂੰ ਕੋਡ ਅਤੇ ਡੇਟਾ ਲਈ ਇੱਕ ਇਕਸਾਰ ਆਕਾਰ ਦਿੰਦੇ ਹਨ: ਨੇਸਟ ਕੀਤੀਆਂ ਲਿਸਟਾਂ。
ਇਹ ਇਕਸਾਰਤਾ ਸਿਸਟਮਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ ਕਿਉਂਕਿ:
Macro ਉਸ ਕੋਡ ਢਾਂਚੇ ਦੀ ਆਟੋਮੇਸ਼ਨ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਮੁੜ-ਮੁੜ ਲਿਖਦੇ ਹੋ—ਸਿਰਫ਼ ਮੁੱਲਾਂ ਦੀ ਨਹੀਂ, ਸਗੋਂ ਕੋਡ ਦੇ ਸੂਰਤ-ਆਕਾਰ ਦੀ۔
Macros ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ:
ਜੇ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਮੁੜ-ਵਰਤੀ ਲਾਜਿਕ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਇੱਕ ਫੰਕਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਬਿਹਤਰ ਚੋਣ ਹੈ।
ਗਾਰਬੇਜ ਕਲੈਕਸ਼ਨ (GC) ਆਪਣੀ ਨਜ਼ਰ ਵਿੱਚ ਅਣਪਹੁੰਚੇ ਓਬਜੈਕਟਾਂ ਨੂੰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਪਛਾਣ ਕੇ ਮੈਮੋਰੀ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦਾ ਹੈ—ਇਸ ਨਾਲ ਇੱਕ ਪੂਰੀ ਕਿਸਮ ਦੀਆਂ ਗਲਤੀਆਂ ਘੱਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ (ਡੈਂਗਲਿੰਗ ਪੌਇੰਟਰ, ਡਬਲ ਫ੍ਰੀ ਆਦਿ)।
ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਪ੍ਰੋਗਰਾਮ ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀਆਂ ਲਿਸਟਾਂ/ਟ੍ਰੀ/ਇੰਮਡੀਏਟ ਨਤੀਜਿਆਂ ਨੂੰ ਬਣਾਉਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਪ੍ਰੋਟੋਟਾਈਪ ਤੇ ਸੋਚ-ਵਿਚਾਰ ਬਿਨਾਂ ਮੈਮੋਰੀ-ਮਾਲਕੀ ਰਣਨੀਤੀ ਦੇ ਕਰ ਸਕਦੇ ਹੋ।
REPL "ਸੋਚੋ → ਕੋਸ਼ਿਸ਼ ਕਰੋ → ਦੇਖੋ" ਦੇ ਲੂਪ ਨੂੰ ਛੋਟਾ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਫੰਕਸ਼ਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਉਸਨੂੰ ਫੌਰਨ ਚਲਾਕੇ ਦੇਖ ਸਕਦੇ ਹੋ, ਸੋਧ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਮੁੜ ਚਲਾ ਸਕਦੇ ਹੋ।
ਇੱਕੋ ਫਾਇਦੇ ਨੂੰ ਗੈਰ-Lisp ਸਟੈਕ ਵਿੱਚ ਲੈਣ ਲਈ:
ਸਬੰਧਤ ਪਾਠ: /blog/the-repl-and-fast-feedback-loops
ਕਈ ਆਧੁਨਿਕ ਵਰਕਫ਼ਲੋ ਉਹੀ ਮੁੱਖ ਵਿਚਾਰ ਮੁੜ ਵਰਤਦੇ ਹਨ:
map/filter, ਰਚਨਾ)ਚਾਹੇ ਤੁਸੀਂ ਕਦੇ Lisp ਨਹੀਂ ਵਰਤਦੇ, ਤੁਸੀਂ ਸੰਭਵਤ: ਰੋਜ਼ਾਨਾ Lisp-ਵਿਰਾਸਤ ਵਾਲੀਆਂ ਆਦਤਾਂ ਵਰਤ ਰਹੇ ਹੋ।
ਅਮਲ ਵਿੱਚ ਕੁਝ ਵਪਾਰਕ ਟਰੇਡ-ਆਫ ਹਨ:
ਅਮਲਕਾਰੀ ਰਵਈਆ ਇਹ ਹੈ: ਛਪਾਈਆਂ ਤੋਂ ਬਿਨਾਂ ਮੂਲ ਵਿਚਾਰਾਂ ਦਾ ਮੁੱਲੰਕਣ ਕਰੋ—ਇਕਸਾਰਤਾ, ਇੰਟਰਐਕਸ਼ਨ, ਅਤੇ macros ਵਰਗੀਆਂ ਵਿਧੀਆਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਪਰਿਵੇਸ਼ਾਂ ਵਿੱਚ ਵੇਖੋ।
ਇਹ 10 ਮਿੰਟ ਦਾ ਅਭਿਆਸ ਕਰੋ:
ਆਪਣੇ ਸਟੈਕ ਵਿੱਚ Lisp ਦੇ ਵਿਚਾਰ ਲੈ ਆਉਣ ਲਈ: AST-ਜਿਹੇ ਪ੍ਰਤੀਨਿਧੀਆਂ ਬਣਾਓ, ਕੋਡ ਜਨਰੇਸ਼ਨ ਵਰਤੋਂ, ਅਤੇ ਡੇਟਾ-ਪਹਿਲੇ ਪਾਈਪਲਾਈਨ (parse → transform → evaluate) ਨੂੰ ਮਿਆਰੀਕਰੋ।