27 ਜੂਨ 2025·8 ਮਿੰਟ
ਐਲਨ ਕੇ ਦੇ ਵੱਡੇ ਵਿਚਾਰ: Smalltalk, GUIs ਅਤੇ ਸਾਫਟਵੇਅਰ ਸਿਸਟਮ
जानੋ ਕਿ ਐਲਨ ਕੇ ਦੇ ਮੁੱਖ ਵਿਚਾਰ—Smalltalk ਅਤੇ ਸ਼ੁਰੂਆਤੀ GUI—ਕਿਵੇਂ ਅੱਜ ਸਾਫਟਵੇਅਰ ਨੂੰ ਆਪਸ 'ਚ ਇੰਟਰਐਕਟ ਕਰਨ ਵਾਲੀਆਂ ਵਸਤਾਂ ਵਜੋਂ ਦੇਖਣ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
जानੋ ਕਿ ਐਲਨ ਕੇ ਦੇ ਮੁੱਖ ਵਿਚਾਰ—Smalltalk ਅਤੇ ਸ਼ੁਰੂਆਤੀ GUI—ਕਿਵੇਂ ਅੱਜ ਸਾਫਟਵੇਅਰ ਨੂੰ ਆਪਸ 'ਚ ਇੰਟਰਐਕਟ ਕਰਨ ਵਾਲੀਆਂ ਵਸਤਾਂ ਵਜੋਂ ਦੇਖਣ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
ਐਲਨ ਕੇ ਸਿਰਫ਼ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਇਤਿਹਾਸ ਦਾ ਨਾਂ ਨਹੀਂ ਹੈ। ਕੰਪਿਊਟਰਾਂ ਬਾਰੇ ਬਹੁਤ ਸਾਰੀਆਂ ਆਮ ਮਨੁੱਖੀ ਸੋਚਾਂ—"ਵਿੰਡੋ" ਕੀ ਹੁੰਦਾ ਹੈ, ਸਾਫਟਵੇਅਰ ਇੰਟਰਐਕਟਿਵ ਕਿਉਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕਾਰਜਾਂ ਨੂੰ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਹਿੱਸਿਆਂ ਤੋਂ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ—ਇਨ੍ਹਾਂ ਵਿਚਾਰਾਂ ਨੂੰ ਉਸਨੇ ਅੱਗੇ ਵਧਾਇਆ (ਅਕਸਰ Xerox PARC ਦੀ ਟੀਮਾਂ ਨਾਲ)।
ਇਹ ਪੋਸਟ ਤੱਥਾਂ ਦੀ ਪੁੜਾਈ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਕੋਡ ਆਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਅਤੇ ਨਾਂ ਹੀ ਕੋਈ ਅਜਿਹੇ ਵਿਸਥਾਰਿਤ ਤਕਨੀਕੀ ਵੇਰਵੇ ਮਿਲਣਗੇ। ਸਾਡਾ ਧਿਆਨ ਕੁਝ ਮਨੋਦਸ਼ਾਵਾਂ (mental models) ਤੇ ਹੈ ਜੋ ਅੱਜ ਵੀ ਸੰਦਾਂ ਅਤੇ ਪ੍ਰੋਡਕਟਾਂ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ: ਸਾਫਟਵੇਅਰ ਨੂੰ ਕਿਵੇਂ ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਸੁਧਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਿੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਪਹਿਲਾ, Smalltalk: ਸਿਰਫ਼ ਇੱਕ ਭਾਸ਼ਾ ਨਹੀਂ, ਬਲਕਿ ਪੂਰਾ ਵਰਕਿੰਗ ਮਾਹੌਲ ਜੋ ਖੋਜ ਅਤੇ ਸਿੱਖਣ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ।
ਦੂਜਾ, GUIs (ਗ੍ਰਾਫਿਕਲ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ): ਵਿੰਡੋ, ਆਈਕਨ, ਮੈਨੂਜ਼—ਇੰਟਰਐਕਟਿਵ ਸਾਫਟਵੇਅਰ ਜੋ ਤੁਸੀਂ ਸਿੱਧਾ ਮੈਨਿਪੁਲੇਟ ਕਰ ਸਕਦੇ ਹੋ।
ਤੀਜਾ, ਸਿਸਟਮ ਸੋਚ: ਸਾਫਟਵੇਅਰ ਨੂੰ ਇਕੱਠੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਹਿੱਸਿਆਂ ਦੇ ਤੌਰ 'ਤੇ ਵੇਖਣਾ, ਨਾ ਕਿ ਕੇਵਲ ਫਾਈਲਾਂ ਦੇ ਢੇਰ ਵਜੋਂ।
ਇਹ ਪੋਸਟ ਕੇ ਨੂੰ ਇੱਕ ਇਕੱਲੇ ਜੀਨੀਅਸ ਵਜੋਂ ਨਹੀਂ ਦੇਵੇਗੀ, ਅਤੇ ਨਾ ਇਹ ਦਾਅਵਾ ਕਰੇਗੀ ਕਿ ਕੋਈ ਇੱਕ “ਸਹੀ” ਪੈਰਾਡਾਇਮ ਸਭ ਚੀਜ਼ਾਂ ٺੀਕ ਕਰ ਦਿੰਦਾ ਹੈ। ਕੁਝ ਵਿਚਾਰ ਬਹੁਤ ਕਾਮਯਾਬ ਰਹੇ, ਕੁਝ ਗਲਤ ਸਮਝੇ ਗਏ, ਅਤੇ ਕੁਝ ਵਿਆਪਕ ਨਹੀਂ ਹੋ ਸਕੇ।
ਮਕਸਦ ਪ੍ਰਯੋਗਿਕ ਹੈ: ਆਖਿਰ ਤੱਕ, ਤੁਸੀਂ ਆਧੁਨਿਕ ਐਪਸ ਅਤੇ ਕੋਡਬੇਸਾਂ ਨੂੰ ਇਸ ਗੱਲ ਨਾਲ ਦੇਖ ਸਕੋਗੇ ਕਿ ਉਹ ਇਸ ਤਰ੍ਹਾਂ ਮਹਿਸੂਸ ਕਿਉਂ ਹੁੰਦੇ ਹਨ—ਅਤੇ ਤੁਹਾਡੇ ਅਗਲੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਤੁਸੀਂ ਕੀ ਉਧਾਰ ਲੈ ਸਕਦੇ ਹੋ।
ਐਲਨ ਕੇ ਇੱਕ ਐਸੇ ਕੰਪਿਊਟਿੰਗ ਸੱਭਿਆਚਾਰ ਵਿੱਚ ਦਾਖਲ ਹੋਇਆ ਜੋ ਸ਼ਕਤੀਸ਼ਾਲੀ, ਮਹਿੰਗਾ ਅਤੇ ਆਮ ਲੋਕਾਂ ਦੀ ਦਲਚਸਪੀ ਤੋਂ ਜ਼ਿਆਦਾ ਅਣਗੌਲ ਸੀ। ਕੰਪਿਊਟਰਾਂ ਨੂੰ ਸ਼ੇਅਰ ਕੀਤੀ ਢਾਂਚੇ ਵਜੋਂ ਦੇਖਿਆ ਜਾਂਦਾ ਸੀ: ਸਮਾਂ ਬੁੱਕ ਕਰਨਾ, ਕੰਮ ਪੇਸ਼ ਕਰਨਾ, ਅਤੇ ਨਤੀਜੇ ਦੀ ਉਡੀਕ ਕਰਨੀ। ਇਸ ਮਾਡਲ ਨੇ ਸਭ ਕੁਝ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ—ਪ੍ਰੋਗਰਾਮਾਂ ਦਾ ਰੂਪ, ਉਪਭੋਗਤਾ ਕੌਣ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ “ਸਫਲਤਾ” ਦਾ ਮাপক।
ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ, ਕੰਪਿਊਟਿੰਗ ਦਾ ਮਤਲਬ ਸੀ ਕੰਮ ਮਸ਼ੀਨ ਨੂੰ ਦੇਣਾ (ਕਈ ਵਾਰ ਕਾਰਡਾਂ ਜਾਂ ਕਤਾਰਵਾਰ ਟਰਮੀਨਲ ਰਾਹੀਂ) ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਨਤੀਜਾ ਲੈਣਾ। ਜੇ ਕੁਝ ਗਲਤ ਹੋਇਆ, ਤਾਂ ਤੁਸੀਂ ਖੋਜ ਨਹੀਂ ਕਰਦੇ—ਫਿਰੋਂ ਜੋੜ ਕੇ ਭੇਜਦੇ ਅਤੇ ਉਡੀਕ ਕਰਦੇ। ਖੋਜ ਧੀਮੀ ਸੀ, ਅਤੇ ਕੰਪਿਊਟਰ ਇੱਕ ਦੂਰੀ ਦੀ ਸੇਵਾ ਵਜੋਂ ਮਹਿਸੂਸ ਹੁੰਦਾ ਸੀ, ਨਾ ਕਿ ਇੱਕ ਐਜੰਸੀ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਸੋਚ ਸਕੋ।
ਕੇ ਦਾ ਟੀਚਾ ਸਿਰਫ਼ "ਛੋਟੇ ਕੰਪਿਊਟਰ" ਨਹੀਂ ਸੀ। ਇਹ ਇੱਕ ਵੱਖਰੇ ਰਿਸ਼ਤੇ ਦੀ ਗੱਲ ਸੀ: ਇਕ ਐਸਾ ਕੰਪਿਊਟਰ ਜੋ ਨਿੱਜੀ ਮੀਡਿਆ ਹੋਵੇ—ਸਿੱਖਣ, ਲਿਖਣ, ਅਨੁਕਰਨ ਕਰਨ, ਖਿੱਚਣ ਅਤੇ ਵਿਚਾਰ ਬਣਾਉਣ ਲਈ—ਖਾਸ ਕਰਕੇ ਬੱਚਿਆਂ ਅਤੇ ਗੈਰ-ਵਿਸ਼ੇਸ਼ਜ्ञਾਂ ਲਈ। ਇਸ ਲਈ ਤੁਰੰਤ ਪ੍ਰਭਾਵ ਦੀ ਲੋੜ ਸੀ। ਤੁਹਾਨੂੰ ਵੇਖਣਾ ਚਾਹੀਦਾ ਸੀ ਕਿ ਤੁਹਾਡੇ ਕਰਮ ਦਾ ਨਤੀਜਾ ਕੀ ਹੁੰਦਾ ਹੈ, ਜਲਦੀ ਸੋਧ ਕਰਨ ਦੀ ਯੋਗਤਾ ਹੋਵੇ, ਅਤੇ ਰਚਨਾਤਮਕ ਧਾਰਾ ਬਰਕਰਾਰ ਰਹੇ।
ਇਸ ਤਰ੍ਹਾਂ ਦਾ ਬਦਲਾਵ ਲਿਆਂਦਾ ਜਾਣ ਲਈ, ਤੁਹਾਨੂੰ ਹਾਰਡਵੇਅਰ, ਸਾਫਟਵੇਅਰ ਅਤੇ ਇੰਟਰਐਕਸ਼ਨ ਡਿਜ਼ાઇન ਇਕੱਠੇ ਅਜ਼ਮਾਉਣ ਦੀ ਜ਼ਗ੍ਹਾ ਚਾਹੀਦੀ ਸੀ। ਰਿਸਰਚ ਲੈਬ ਜਿਵੇਂ Xerox PARC ਲੰਮੇ ਦਾਅਵਿਆਂ ਨੂੰ ਫੰਡ ਕਰਦੇ: ਨਵੇਂ ਡਿਸਪਲੇਅ, ਨਵੇਂ ਇਨਪੁੱਟ ਡਿਵਾਈਸ, ਨਵੇਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਮਾਡਲ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਸੰਗਠਿਤ ਅਨੁਭਵ ਵਿੱਚ ਪੈਕ ਕਰਨ ਦੇ ਤਰੀਕੇ। ਲક્ષ्य ਕੋਈ ਫੀਚਰ ਸ਼ਿਪ ਕਰਨਾ ਨਹੀਂ ਸੀ—ਲక్ష्य ਨਵਾਂ ਤਰੀਕਾ ਖੋਜਣਾ ਸੀ ਕਿ ਕੰਪਿਊਟਰ ਕਿਵੇਂ ਵਰਤੇ ਜਾਣ।
ਜੇ ਕੰਪਿਊਟਰ ਸਿੱਖਣ ਅਤੇ ਬਣਾਉਣ ਦੀ ਮਸ਼ੀਨ ਹੋਣੀ ਸੀ, ਤਾਂ ਯੂਜ਼ਰਬਿਲਟੀ ਪਿੱਛੋਂ ਆਉਂਦੀ ਚੀਜ਼ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਇੰਟਰਫੇਸ ਨੂੰ ਖੋਜ, ਫੀਡਬੈਕ, ਅਤੇ ਸਮਝਣ ਯੋਗ ਕ੍ਰਿਆਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਸੀ। ਇਹ ਧੁੰਨ ਕੇ ਨੂੰ ਉਨ੍ਹਾਂ ਪ੍ਰਣਾਲੀਆਂ ਵੱਲ ਧਕੇਲਿਆ ਜਿੱਥੇ ਇੰਟਰਐਕਸ਼ਨ ਦੀ "ਅਹਿਸਾਸ"—ਜਦ ਤੁਸੀਂ ਕਲਿੱਕ ਕਰੋ, ਸੰਪਾਦਨ ਕਰੋ, ਜਾਂ ਖੋਜ ਕਰੋ—ਉਸੇ ਢਾਂਚੇ ਨਾਲ ਕਸਕੇ ਜੁੜੀ ਹੋਈ ਹੋਵੇ ਜੋ ਸਾਫਟਵੇਅਰ ਦੀ ਬਣਤਰ ਹੈ।
ਐਲਨ ਕੇ ਨੇ ‘‘ਦਫ਼ਤਰ ਦਾ ਕੰਮ ਤੇਜ਼ ਕਰਨ'' ਤੋਂ ਸ਼ੁਰੂਆਤ ਨਹੀਂ ਕੀਤੀ। ਉਹ ਇੱਕ ਵੱਖਰਾ ਸਵਾਲ ਪੁੱਛਦਾ ਸੀ: ਕਿਵੇਂ ਇੱਕ ਬੱਚਾ ਇੱਕ ਨੋਟਬੁੱਕ ਵਾਂਗ ਕੰਪਿਟਰ ਲੈ ਕੇ ਵਿਚਾਰ ਖੋਜ, ਚੀਜ਼ਾਂ ਬਣਾਉਣਾ, ਅਤੇ ਕਰਕੇ ਸਿੱਖ ਸਕਦਾ ਹੈ? ਇਹ ਵਿਚਾਰ Dynabook ਬਣ ਗਿਆ—ਇੱਕ ਉੱਤਰੀ ਨਿਕਾਸ (north star) ਜਿਹੜਾ ਨਿਰਧਾਰਕ ਪ੍ਰੋਡਕਟ ਸਪੈੱਕ ਨਹੀਂ ਸਗੋਂ ਦਿੱਸ਼ਾ ਦਿੰਦਾ ਸੀ।
Dynabook ਨੂੰ ਹਲਕਾ, ਬੈਟਰੀ-ਚਲਿਤ ਅਤੇ ਹਮੇਸ਼ਾਂ ਉਪਲਬਧ ਸੋਚਿਆ ਗਿਆ ਸੀ। ਪਰ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸ਼ਬਦ "ਪੋਰਟੇਬਲ" ਨਹੀਂ ਸੀ। ਉਹ "ਨਿੱਜੀ" ਸੀ। ਇਹ ਕੰਪਿਊਟਰ ਉਸਦੇ ਉਪਭੋਗਤਾ ਦਾ ਵੱਜੋਂ ਮੁਕਾਬਲਾ ਕਰਦਾ—ਇੱਕ ਨੋਟਬੁੱਕ ਜਾਂ ਸਾਜ਼ ਵਾਂਗ—ਕੋਈ ਚੀਜ਼ ਜਿੱਦੀ ਤੁਸੀਂ ਸਮੇਂ ਨਾਲ-ਨਾਲ ਆਕਾਰ ਦਿੰਦੇ ਹੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਚਲਾਉਂਦੇ ਹੋ।
ਉਤਨਾ ਹੀ ਜ਼ਰੂਰੀ: ਇਹ ਸਿੱਖਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ। ਕੇ ਦਾ ਟੀਚਾ ਗੁਪਤ ਮੀਨੂਜ਼ ਦੇ ਪਿੱਛੇ ਕੰਪਿਊਟਿੰਗ ਨੂੰ ਛੁਪਾਉਣ ਦਾ ਨਹੀਂ ਸੀ; ਇਹ ਲੋਕਾਂ ਨੂੰ ਹੌਲੇ-ਹੌਲੇ ਲੇਖਕ ਬਣਨ ਦੇ ਯੋਗ ਬਣਾਉਣਾ ਸੀ, ਸਿਰਫ਼ ਖਪਤਕਾਰ ਨਹੀਂ।
Dynabook ਦੇ "killer apps" ਪੜ੍ਹਨਾ, ਲਿਖਣਾ, ਖਿੱਚਣਾ, ਸੰਗੀਤ ਬਣਾਉਣਾ, ਵਿਗਿਆਨ ਪ੍ਰਯੋਗ ਸਿਮੂਲੇਟ ਕਰਨਾ, ਅਤੇ ਇੰਟਰਐਕਟਿਵ ਕਹਾਣੀਆਂ ਤਿਆਰ ਕਰਨਾ ਸਨ। ਇਸ ਨੇ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਇੱਕ ਲਿਟਰੇਸੀ ਵਜੋਂ ਦੇਖਿਆ—ਵਿਚਾਰ ਪ੍ਰਗਟ ਕਰਨ ਦਾ ਇਕ ਢੰਗ—ਨਾ ਕਿ ਇੱਕ ਮਾਹਿਰਾਂ ਲਈ ਰੀਜ਼ਰਵਡ ਤਕਨੀਕ।
ਇਸ ਫੋਕਸ ਨਾਲ ਇਹ ਨਿਰਧਾਰਤ ਹੋ ਜਾਂਦਾ ਕਿ "ਚੰਗਾ ਸਾਫਟਵੇਅਰ" ਕੀ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਸਿੱਖਣ ਵਾਲਾ ਸੰਦ ਟਿੰਕਰਿੰਗ ਨੂੰ ਨਿਮੰਤਰਦਾ ਕਰੇ, ਤੇਜ਼ ਫੀਡਬੈਕ ਦੇਵੇ, ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਏ।
ਇੱਥੇ Smalltalk ਅਤੇ ਪਹਿਲੇ GUI ਫਿਟ ਹੋਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਲੋਕਾਂ ਨੂੰ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਿੱਧੀ ਮੈਨਿਪੁਲੇਸ਼ਨ, ਤੁਰੰਤ ਨਤੀਜੇ, ਅਤੇ ਐਸਾ ਮਾਹੌਲ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਪਰੈਕਟੀਸ ਕਰਨਾ ਕੁਦਰਤੀ ਲੱਗੇ। Smalltalk ਦਾ ਲਾਈਵ, ਇੰਟਰਐਕਟਿਵ ਸਿਸਟਮ ਅਤੇ GUI ਦੇ ਦ੍ਰਿਸ਼ਤੀਗੋਚਰ ਰੂਪ ਇਸੇ ਲਕਸ਼ ਫਲ ਦਾ ਸਮਰਥਨ ਕਰਦੇ: ਵਿਚਾਰ ਅਤੇ ਕਾਰਗਰ ਕਲਾ ਦੇ ਵਿਚਕਾਰ ਦੀ ਦੂਰੀ ਘਟਾਓ।
Dynabook "ਟੈਬਲੇਟ ਦੀ ਭਵਿੱਖਬਾਣੀ" ਨਹੀਂ ਸੀ। ਇਹ ਕੰਪਿਊਟਿੰਗ ਨਾਲ ਨਵੇਂ ਰਿਸ਼ਤੇ ਦੀ ਪੇਸ਼ਕਸ਼ ਸੀ: ਸੋਚ ਅਤੇ ਰਚਨਾ ਲਈ ਇੱਕ ਮੀਡੀਆ। ਕਈ ਉਪਕਰਣ ਇਸ ਨੂੰ ਨਜ਼ਦੀਕ ਅਨੁਭਵ ਦੇ ਸਕਦੇ ਹਨ, ਪਰ ਵਿਜ਼ਨ ਉਪਭੋਗਤਾ ਨੂੰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਬਣਾਉਣ ਬਾਰੇ ਸੀ—ਖ਼ਾਸਕਰ ਸਿੱਖਣ ਵਾਲਿਆਂ ਬਾਰੇ—ਨਾਹ ਕਿ ਕਿਸੇ ਖਾਸ ਸਕ੍ਰੀਨ ਆਕਾਰ ਜਾਂ ਹਾਰਡਵੇਅਰ ਡਿਜ਼ਾਈਨ ਬਾਰੇ।
ਲੋਕ ਜਦੋਂ "Smalltalk" ਸੁਣਦੇ ਹਨ, ਉਹ ਅਕਸਰ ਇੱਕ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਸੋਚਦੇ ਹਨ। ਕੇ ਦੀ ਟੀਮ ਨੇ ਇਸਨੂੰ ਵੱਡਾ ਵੇਖਿਆ: ਇੱਕ ਪੂਰਾ ਵਰਕਿੰਗ ਸਿਸਟਮ ਜਿੱਥੇ ਭਾਸ਼ਾ, ਟੂਲ ਅਤੇ ਯੂਜ਼ਰ ਅਨੁਭਵ ਇਕੱਠੇ ਡਿਜ਼ਾਇਨ ਕੀਤੇ ਗਏ।
ਸਿਧੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, Smalltalk ਇੱਕ ਐਸਾ ਸਿਸਟਮ ਹੈ ਜਿੱਥੇ ਹਰ ਚੀਜ਼ ਇੱਕ ਆਬਜੈਕਟ ਹੈ। ਸਕ੍ਰੀਨ ਉੱਤੇ ਖਿੜਕੀਆਂ, ਤੁਹਾਡਾ ਲਿਖਿਆ ਟੈਕਸਟ, ਬਟਨ, ਅੰਕ—ਹਰ ਇਕ ਆਬਜੈਕਟ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਕੁਝ ਕਰਵਾਉਣ ਲਈ ਪੁੱਛ ਸਕਦੇ ਹੋ।
Smalltalk ਸਿੱਖਣ-ਕਰ ਕੇ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਕੋਡ ਲਿਖ ਕੇ ਕਮਪਾਇਲ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਚਲਦੇ ਸਿਸਟਮ ਵਿੱਚ ਆਬਜੈਕਟਾਂ ਨੂੰ ਇੰਸਪੈਕਟ ਕਰ ਸਕਦੇ ਹੋ, ਉਹਨਾਂ ਦੀ ਮੌਜੂਦਗੀ ਦੇਖ ਸਕਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ, ਅਤੇ ਤੁਰੰਤ ਨਵਾਂ ਵਿਚਾਰ ਆਜ਼ਮਾ ਸਕਦੇ ਹੋ।
ਇਹ ਜਿਊਂਦਗੀ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿਉਂਕਿ ਇਸਨੇ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਖੋਜ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ। ਤੁਸੀਂ ਸਿਰਫ਼ ਫਾਈਲਾਂ ਤਿਆਰ ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਚੱਲ ਰਹੀ ਦੁਨੀਆਂ ਨੂੰ ਆਕਾਰ ਦੇ ਰਹੇ ਹੋ। ਇਹ ਜਿਗਿਆਸਾ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ: "ਇਹ ਚੀਜ਼ ਕੀ ਹੈ?" "ਇਸ ਵਿੱਚ ਕੀ ਹੈ?" "ਜੇ ਮੈਂ ਇਸਨੂੰ ਥੋੜ੍ਹਾ ਬਦਲਾਂ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?"
Smalltalk ਦੇ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲ ਵੱਖ-ਵੱਖ ਐਡ-ਅੌਨ ਨਹੀਂ ਸਨ। ਬ੍ਰაუნਜ਼ਰ, ਇੰਸਪੈਕਟਰ, ਡੀਬੱਗਰ ਅਤੇ ਐਡੀਟਰ ਉਸੇ ਆਬਜੈਕਟ-ਅਧਾਰਿਤ ਬ੍ਰਹਿਮੰਡ ਦਾ ਹਿੱਸਾ ਸਨ। ਟੂਲ ਸਿਸਟਮ ਦਿੱਲੋਂ ਸਮਝਦੇ ਸਨ ਕਿਉਂਕਿ ਉਹ ਵੀ انہੀ ਮੀਡਿਯਮ ਵਿੱਚ ਬਣੇ ਸਨ।
ਇਹ ਘਣੇ ਏਕਤਾ ਨੇ "ਸਾਫਟਵੇਅਰ 'ਤੇ ਕੰਮ ਕਰਨਾ" ਦਾ ਅਨੁਭਵ ਬਦਲ ਦਿੱਤਾ: ਦੂਰੀ ਵਾਲੇ ਸੋర్స్ ਕੋਡ ਦਾ ਪਰਬੰਧ ਕਰਨ ਵਾਲੇ ਕੰਮ ਵੱਜੋਂ ਨਹੀਂ, ਬਲਕਿ ਤੁਸੀਂ ਜਿਨ੍ਹਾਂ ਸਿਸਟਮ ਨੂੰ ਬਣਾ ਰਹੇ ਹੋ, ਉਸ ਨਾਲ ਸਿੱਧਾ ਇਨਟਰਐਕਟ ਕਰਨ ਵਰਗਾ।
ਇੱਕ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਖੋਲ੍ਹ ਕੇ ਉਸਦੀ ਸੋਧ ਕਰਨ ਦੀ ਸੋਚ ਕਰੋ—ਫਾਰਮੇਟਿੰਗ ਤੁਰੰਤ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਤੁਸੀਂ ਖੋਜ, ਦੁਬara ਰਵੋ, ਅਤੇ bina "ਬਣਾਉਣ" ਦੇ ਬਦਲਾਅ ਦੇਖਦੇ ਹੋ। Smalltalk ਨੇ ਪ੍ਰੋਗਰਾਮਾਂ ਲਈ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਤੁਰੰਤਤਾ ਦਾ ਲਕਸ਼ ਦਿੱਤਾ: ਤੁਸੀਂ ਚੱਲ ਰਹੀ ਚੀਜ਼ ਨੂੰ ਸੋਧਦੇ ਹੋ, ਤੁਰੰਤ ਨਤੀਜਾ ਵੇਖਦੇ ਹੋ, ਅਤੇ ਅੱਗੇ ਵਧਦੇ ਹੋ।
ਕੇ ਦਾ ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਮਨੋਦਸ਼ਾ "ਕਲਾਸਾਂ ਅਤੇ ਵਿਰਾਸਤ" ਨਹੀਂ ਸੀ। ਇਹ ਇਹ ਵਿਚਾਰ ਸੀ ਕਿ ਇੱਕ ਆਬਜੈਕਟ ਇੱਕ ਛੋਟਾ, ਸੁਤੰਤਰ ਕੰਪਿਊਟਰ ਹੈ: ਇਸਦੇ ਕੋਲ ਆਪਣਾ ਸਟੇਟ (ਹੁਣ ਜੋ ਇਹ ਜਾਣਦਾ ਹੈ) ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਕੁਝ ਕਹੋਗੇ ਤਾਂ ਇਹ ਕਿਵੇਂ ਜਵਾਬ ਦੇਵੇਗਾ।
ਹਰ ਆਬਜੈਕਟ ਕੋਲ ਸੋਚੋ:
ਇਹ ਫਰੇਮਿੰਗ ਪ੍ਰਯੋਗਿਕ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡੇ ਧਿਆਨ ਨੂੰ "ਡਾਟਾ ਕਿੱਥੇ ਸਟੋਰ ਹੈ?" ਤੋਂ ਬਦਲ ਕੇ "ਇਸਦੀ ਜਵਾਬਦੇਹੀ ਕੌਣ ਹੈ?" ਵੱਲ ਕਰਦੀ ਹੈ।
ਆਕਸਰ ਗਲਤੀ ਇਹ ਹੁੰਦੀ ਹੈ ਕਿ ਆਬਜੈਕਟਾਂ ਨੂੰ ਸਿਰਫ਼ ਸੁਧਰੇ ਹੋਏ ਡਾਟਾ ਰਿਕਾਰਡ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ: ਫੀਲਡਾਂ ਦਾ ਇੱਕ ਗੁੱਛਾ ਅਤੇ ਕੁਝ ਸਹਾਇਕ ਫੰਕਸ਼ਨ। ਇਸ ਨਜ਼ਰੀਏ ਵਿੱਚ ਹੋਰ ਹਿੱਸੇ ਆਸਾਨੀ ਨਾਲ ਅੰਦਰ ਦੇਖ ਕੇ ਅੰਦਰੂਨੀ ਹਿੱਸਿਆਂ ਨੂੰ ਬਦਲ ਦੇਂਦੇ ਹਨ।
ਕੇ ਦਾ ਨਜ਼ਰੀਆ ਜ਼ਿਆਦਾ ਕਰੀਬ ਹੈ ਐਕਟਰ ਵਾਲੇ ਮਾਨਸਿਕ ਮਾਡਲ ਨਾਲ। ਤੁਸੀਂ ਇੱਕ ਆਬਜੈਕਟ ਵਿੱਚ ਨਹੀਂ ਘੁਸਦੇ ਅਤੇ ਇਸਦੇ ਦਰਾਜ਼ਾਂ ਨੂੰ ਦੁਬਾਰਾ ਤਰਤੀਬ ਨਹੀਂ ਦਿੰਦੇ। ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਬੇਨਤੀ ਭੇਜਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਆਪਣੀ ਸਟੇਟ ਦਾ ਪ੍ਰਬੰਧ ਕਰਨ ਦਿੰਦੇ ਹੋ। ਇਹ ਵੱਖਰਾ ਅਫ਼ਸਰ ਹੈ।
ਸੁਨੇਹਾ-ਪਾਸਿੰਗ ਸਿਧਾ ਸਾਦਾ ਹੈ: ਬੇਨਤੀ/ਜਵਾਬ।
ਕੈਫੇ ਦਾ ਜ਼ਿਕਰ ਕਰੋ: ਤੁਸੀਂ ਰਸੋਈ ਵਿੱਚ ਦਾਖਲ ਹੋ ਕੇ ਆਪਣਾ ਰੋਟੀ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਤੁਸੀਂ ਆਰਡਰ ਦਿੰਦੇ ਹੋ ("ਮੈਨੂੰ ਸੈਂਡਵਿਚ ਬਣਾਓ"), ਅਤੇ ਤੁਹਾਨੂੰ ਨਤੀਜਾ ਮਿਲਦਾ ਹੈ ("ਇਥੇ ਤੁਹਾਡਾ ਸੈਂਡਵਿਚ" ਜਾਂ "ਰੋਟੀ ਖਤਮ ਹੈ")। ਕੈਫੇ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਮੰਗ ਪੂਰੀ ਕਰਨੀ ਹੈ।
ਸਾਫਟवेयर ਆਬਜੈਕਟ ਵੀ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ: ਤੁਸੀਂ ਸੁਨੇਹਾ ਭੇਜਦੇ ਹੋ ("ਕੁੱਲ ਗਿਣੋ", "ਸੇਵ ਕਰੋ", "ਆਪਣਾ ਰੈਂਡਰ ਕਰੋ"), ਅਤੇ ਆਬਜੈਕਟ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
ਜਦੋਂ ਸਿਸਟਮ ਦੇ ਹੋਰ ਹਿੱਸੇ ਸਿਰਫ਼ ਸੁਨੇਹਿਆਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਕਿਸੇ ਆਬਜੈਕਟ ਦੀ ਅੰਦਰੂਨੀ ਕਾਰਗੁਜ਼ਾਰੀ ਬਦਲ ਸਕਦੇ ਹੋ—ਅਲਗੋਰਿਦਮ ਬਦਲੋ, ਸਟੋਰੇਜ ਬਦਲੋ, ਕੈਸ਼ਿੰਗ ਸ਼ਾਮਲ ਕਰੋ—ਬਿਨਾਂ ਹਰ ਥਾਂ 'ਤੇ ਰੀ-ਰਾਈਟ ਕਰਵਾਏ।
ਇਸੇ ਤਰੀਕੇ ਨਾਲ ਸਿਸਟਮ ਬਿਨਾਂ ਸਭ ਕੁਝ ਟੁੱਟੇ ਵਧ ਸਕਦੇ ਹਨ: ਸਰਹੱਦਾਂ 'ਤੇ ਸਥਿਰ ਸਮਝੌਤੇ, ਹਿੱਸਿਆਂ ਦੇ ਅੰਦਰ ਵੱਧ ਆਜ਼ਾਦੀ।
ਲੋਕ ਅਕਸਰ "object-oriented programming" ਨੂੰ "ਕਲਾਸਾਂ ਵਰਤਣਾ" ਸਮਝ ਲੈਂਦੇ ਹਨ। ਇਹ ਸਮਝਦਾਰ ਹੈ—ਜ਼ਿਆਦਾਤਰ ਭਾਸ਼ਾਵਾਂ OOP ਨੂੰ ਕਲਾਸਾਂ ਅਤੇ ਵਿਰਾਸਤ ਰਾਹੀਂ ਸਿਖਾਉਂਦੀਆਂ ਹਨ। ਪਰ ਕੇ ਦੀ ਪਹਿਲੀ ਤਰਜੀਹ ਵੱਖਰੀ ਸੀ: ਗੱਲਬਾਤ ਕਰਨ ਵਾਲੇ ਹਿੱਸਿਆਂ ਦੀ ਸੋਚ ਕਰੋ।
ਇੱਕ class ਨਕਸ਼ਾ ਹੁੰਦੀ ਹੈ: ਇਹ ਵੇਖਾਉਂਦੀ ਹੈ ਕਿ ਕੋਈ ਚੀਜ਼ ਕੀ ਜਾਣਦੀ ਹੈ ਅਤੇ ਕੀ ਕਰ ਸਕਦੀ ਹੈ।
ਇੱਕ instance (ਜਾਂ ਆਬਜੈਕਟ) ਉਸ ਨਕਸ਼ੇ ਤੋਂ ਬਣੀ ਹੋਈ ਇੱਕ ਮੁਕਰਰ ਚੀਜ਼ ਹੁੰਦੀ ਹੈ—ਤੁਹਾਡੀ ਵਿਸ਼ੇਸ਼ ਇਕਾਈ।
ਇੱਕ method ਉਹ ਕਾਰਵਾਈ ਹੈ ਜੋ ਆਬਜੈਕਟ ਮੰਗ 'ਤੇ ਕਰ ਸਕਦਾ ਹੈ।
State ਆਬਜੈਕਟ ਦਾ ਮੌਜੂਦਾ ਡੇਟਾ ਹੈ: ਜੋ ਇਹ ਹੁਣ ਯਾਦ ਰੱਖਦਾ ਹੈ ਅਤੇ ਜੋ ਬਦਲ ਸਕਦਾ ਹੈ।
Smalltalk ਨੇ ਇਕ ਇਕਸਾਰ ਆਬਜੈਕਟ ਮਾਡਲ ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਕੀਤਾ: ਹਰ ਚੀਜ਼ ਇੱਕ ਆਬਜੈਕਟ, ਅਤੇ ਤੁਸੀਂ ਆਬਜੈਕਟਾਂ ਨਾਲ ਇੱਕ ਸੰਗਤ ਤਰੀਕੇ ਨਾਲ ਇੰਟਰਐਕਟ ਕਰਦੇ ਹੋ। ਇਸਨੇ ਮੇਸੇਜ-ਪਾਸਿੰਗ ਨੂੰ ਵੀ ਉਭਾਰਿਆ—ਤੁਸੀਂ ਦੂਜੇ ਆਬਜੈਕਟ ਦੀ ਅੰਦਰੂਨੀ ਹਾਲਤ ਵਿੱਚ ਝਾਂਕ ਕੇ ਕੰਟਰੋਲ ਨਹੀਂ ਕਰਦੇ; ਤੁਸੀਂ ਸੁਨੇਹਾ ਭੇਜਦੇ ਹੋ ਅਤੇ ਆਬਜੈਕਟ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਕਰਨਾ ਹੈ।
ਇਹ ਸ਼ੈਲੀ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਲੇਟ ਬਾਈਂਡਿੰਗ ਨਾਲ ਮਿਲਦੀ ਹੈ (ਰਨ-ਟਾਈਮ 'ਤੇ ਇਹ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਸ METHOD ਨੇ ਸੁਨੇਹੇ ਨੂੰ ਹੈਂਡਲ ਕਰਨਾ ਹੈ)। ਪ੍ਰਯੋਗਿਕ ਫਾਇਦਾ ਲਚਕੀਲਾਪਣ ਹੈ: ਤੁਸੀਂ ਬਿਹੇਵਿਯਰ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕਾਲਰ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੇ।
ਇੱਕ ਉਪਯੋਗ ਨਿਯਮ: ਇੰਟਰਐਕਸ਼ਨਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਡਿਜ਼ਾਇਨ ਕਰੋ। ਪੁੱਛੋ "ਕਿਹੜੇ ਸੁਨੇਹੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ?" ਅਤੇ "ਇਹ ਰਾਜ ਕਿਸ ਨੇ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ?" ਜੇ ਆਬਜੈਕਟ ਤੁਲनीयਤਾ ਨਾਲ ਸਹਿਯੋਗੀ ਹਨ, ਤਾਂ ਕਲਾਸ ਢਾਂਚਾ ਆਮ ਤੌਰ 'ਤੇ ਆਸਾਨ ਅਤੇ ਬਦਲਾਅ-ਮਿਤ੍ਰ ਬਣ ਜਾਂਦਾ ਹੈ—ਇਕ ਪ੍ਰਕਾਰ ਦਾ ਸਾਈਡ ਇਫੈਕਟ।
ਗ੍ਰਾਫਿਕਲ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ (GUI) ਨੇ "ਸਾਫਟਵੇਅਰ ਵਰਤਣਾ" ਦਾ ਅਨਭਵ ਬਦਲ ਦਿੱਤਾ। ਹੁਣ ਤੁਸੀਂ ਕਮਾਂਡ ਯਾਦ ਰੱਖਣ ਦੀ ਥਾਂ ਚੀਜ਼ਾਂ ਵੇਖ ਕੇ ਚੁਣ ਸਕਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਹਿਲਾ ਸਕਦੇ ਹੋ, ਖੋਲ ਸਕਦੇ ਹੋ, ਅਤੇ ਤੁਰੰਤ ਨਤੀਜੇ ਦੇਖ ਸਕਦੇ ਹੋ। ਵਿੰਡੋਜ਼, ਮੈਨੂਜ਼, ਕੰਟਰੋਲ—ਇਹ ਸਾਰੇ ਇਸ ਗੱਲ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਇੰਟਰਫੇਸ ਖੋਜ ਰਾਹੀਂ ਸਿੱਖਣਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਉਹ "ਚੀਜ਼ੀਅਤ" (thing-ness) ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਆਬਜੈਕਟ ਮਾਡਲ ਨਾਲ ਮਿਲਦੀ ਹੈ। ਇੱਕ ਵਧੀਆ ਡਿਜ਼ਾਈਨ ਵਾਲੇ GUI ਵਿੱਚ, ਲਗਭਗ ਹਰ ਜੋ ਤੁਸੀਂ ਵੇਖਦੇ ਅਤੇ ਇੰਟਰਐਕਟ ਕਰਦੇ ਹੋ, ਉਸਨੂੰ ਇੱਕ ਆਬਜੈਕਟ ਦੇ ਰੂਪ ਵਿੱਚ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ:
ਇਹ ਸਿਰਫ਼ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਦੀ ਸੁਵਿਧਾ ਨਹੀਂ; ਇਹ ਇੱਕ ਸੰਕਲਪਕ ਪੁਲ ਹੈ। ਉਪਭੋਗਤਾ ਚੀਜ਼ਾਂ ਨੂੰ ਆਬਜੈਕਟਾਂ ਵੱਜੋਂ ਸੋਚਦਾ ਹੈ ("ਇਸ ਵਿੰਡੋ ਨੂੰ ਹਿਲਾਓ", "ਉਸ ਬਟਨ ਨੂੰ ਕਲਿੱਕ ਕਰੋ"), ਅਤੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਆਬਜੈਕਟਾਂ ਤੋਂ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਜੋ ਐਸਾ ਕਰ ਸਕਦੇ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ ਕਲਿੱਕ, ਲਿਖੋ ਜਾਂ ਡਰੈਗ ਕਰੋ, ਸਿਸਟਮ ਇੱਕ ਇਵੇਂਟ ਬਣਾਉਂਦਾ ਹੈ। ਆਬਜੈਕਟ-ਉਪਰ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਵਿੱਚ, ਇਕ ਇਵੇਂਟ ਮੁਢਲਾ ਰੂਪ ਵਿੱਚ ਇੱਕ ਆਬਜੈਕਟ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਸੁਨੇਹਾ ਹੁੰਦਾ ਹੈ:
ਫਿਰ ਆਬਜੈਕਟ ਹੋਰ ਆਬਜੈਕਟਾਂ ਨੂੰ ਸੁਨੇਹੇ ਅੱਗੇ ਭੇਜ ਸਕਦੇ ਹਨ ("ਦਸਤਾਵੇਜ਼ ਨੂੰ ਸੇਵ ਕਰਨ ਨੂੰ ਕਹੋ", "ਵਿੰਡੋ ਨੂੰ ਦੁਬਾਰਾ ਖਿੱਚਣ ਲਈ ਕਹੋ"), ਜੋ ਇੱਕ ਬਹੁਤ-ਹਥਿਆਰ ਦਿਉਂਦੇ ਹੋਏ ਸਮਝਦਾਰ ਇੰਟਰਐਕਸ਼ਨ ਚੇਨ ਬਣਾਉਂਦੇ ਹਨ।
ਕਿਉਂਕਿ UI ਸਥਾਇੀ ਆਬਜੈਕਟਾਂ ਨਾਲ ਬਣਿਆ ਹੁੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਦਿੱਖ ਸਪਸ਼ਟ ਹੈ, ਇਹ ਇੱਕ ਵਰਕਸਪੇਸ ਵਿਚ ਪ੍ਰਵਿਸ਼ ਕਰਨ ਵਰਗਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਇੱਕ-ਵਾਰੀ ਕਮਾਂਡ ਚਲਾਉਣ ਵਰਗਾ। ਤੁਸੀਂ ਵਿੰਡੋਜ਼ ਛੱਡ ਕੇ ਰੱਖ ਸਕਦੇ ਹੋ, ਟੂਲਾਂ ਨੂੰ ਚੀਲ-ਚੀਲ ਕੇ ਰੱਖ ਸਕਦੇ ਹੋ, ਦਸਤਾਵੇਜ਼ 'ਤੇ ਵਾਪਸ ਆ ਸਕਦੇ ਹੋ, ਅਤੇ ਜਿੱਥੇ ਛੱਡਿਆ ਸੀ ਉਸੇ ਥਾਂ ਤੋਂ ਕੰਮ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹੋ। GUI ਇੱਕ ਸੰਗਠਿਤ ਮਾਹੌਲ ਬਣ ਜਾਂਦਾ ਹੈ—ਜਿੱਥੇ ਕਾਰਵਾਈਆਂ ਉਹਨਾਂ ਆਬਜੈਕਟਾਂ ਦਰਮਿਆਨ ਗੱਲਬਾਤ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ।
Smalltalk ਦੇ ਸਭ ਤੋਂ ਵਿਲੱਖਣ ਵਿਚਾਰਾਂ ਵਿੱਚੋਂ ਇੱਕ syntax ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਸੀ—ਇਹ ਸੀ image। ਇਕ ਪ੍ਰੋਗਰਾਮ ਨੂੰ "ਸੋర్స్ ਕੋਡ ਜੋ ਕੰਪਾਈਲ ਹੋ ਕੇ ਐਪ ਬਣਦਾ ਹੈ" ਵਜੋਂ ਸੋਚਣ ਦੀ ਬਜਾਏ, Smalltalk ਨੇ ਸਿਸਟਮ ਨੂੰ ਚੱਲਦੀ ਦੁਨੀਆਂ ਬਣਾ ਦਿੰਦਾ: ਤੁਸੀਂ ਸਾਰੀ ਚੱਲ ਰਹੀ ਵਾਤਾਵਰਣ ਨੂੰ ਸੇਵ ਕਰ ਸਕਦੇ ਹੋ।
ਇਕ image-ਆਧਾਰਿਤ ਸਿਸਟਮ ਇੱਕ ਫਿਲਮ ਰੁਕਣ ਵਾਂਗ ਹੈ: ਤੁਸੀਂ ਸਿਰਫ਼ ਸਕ੍ਰਿਪਟ ਨਹੀਂ, ਬਲਕਿ ਉਸ ਫਰੇਮ, ਸੈਟ, ਅਤੇ ਹਰ ਅਦਾਕਾਰ ਦੀ ਪੋਜ਼ ਸੇਵ ਕਰ ਰਹੇ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ ਰੀਜੰਮ ਕਰੋਗੇ, ਤੁਸੀਂ ਓਥੇ ਵਾਪਸ ਆਓਗੇ ਜਿੱਥੇ ਤੁਸੀਂ ਛੱਡਿਆ ਸੀ—ਟੂਲ ਖੁੱਲ੍ਹੇ, ਆਬਜੈਕਟ ਮੌਜੂਦ, ਅਤੇ ਤੁਹਾਡੇ ਬਦਲਾਅ ਪਹਿਲਾਂ ਹੀ ਚੱਲ ਰਹੇ।
ਇਹ ਘਣੇ ਫੀਡਬੈਕ ਲੂਪਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ। ਤੁਸੀਂ ਵਿਹਾਰ ਬਦਲ ਸਕਦੇ ਹੋ, ਤੁਰੰਤ ਅਜ਼ਮਾ ਸਕਦੇ ਹੋ, ਨਤੀਜਾ ਦੇਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਸੁਧਾਰ ਕਰ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ "ਬਣਾਓ, ਮੁੜ ਚਲਾਓ, ਡਾਟਾ ਲੋਡ ਕਰੋ, ਸੈੱਟਿੰਗ 'ਤੇ ਵਾਪਸ ਜਾਓ" ਦੇ ਮਾਨਸਿਕ ਰੀਸੈਟ ਦੇ।
ਇਹੀ ਨੀਤੀ ਆਧੁਨਿਕ "vibe-coding" ਵਰਕਫ਼ਲੋਜ਼ ਵਿੱਚ ਵੀ ਦਿੱਸੀ ਜਾ ਸਕਦੀ ਹੈ: ਜਦੋਂ ਤੁਸੀਂ ਬਦਲਾਅ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਵਿਆਖਿਆ ਕਰ ਸਕਦੇ ਹੋ, ਇਸਨੂੰ ਤੁਰੰਤ ਦੇਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਦੁਹਰਾਅ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਿਸਟਮ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਦੇ ਹੋ ਅਤੇ ਗਤੀ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋ। ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਇਸ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਵਰਤਦੇ ਹਨ—ਐਪ-ਬਿਲਡਿੰਗ ਨੂੰ કોਨ્વਰਸੇਸ਼ਨਲ ਲੂਪ ਵਿੱਚ ਬਦਲਦੇ ਹਨ—ਯੋਜਨਾ ਬਣਾਉ, ਸੋਧ, ਪ੍ਰੀਵਿਊ—ਇਸ ਦੌਰਾਨ ਅਸਲ ਕੋਡ ਜੋ ਤੁਸੀਂ ਨਿਕਾਸ ਕਰ ਸਕਦੇ ਹੋ ਥਿਆਰ ਹੁੰਦਾ ਹੈ।
ਅੱਜ ਲੋਕ ਪ੍ਰਸੰਸਾ ਕਰਦੇ ਕਈ ਫੀਚਰਾਂ ਵਿੱਚ image-ਵਿੱਚਾਰ ਦੇ ਅਸਰ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ:
ਇਹ Smalltalk image ਦੇ ਸਮਾਨ ਨਹੀਂ ਹਨ, ਪਰ ਉਨ੍ਹਾਂ ਦਾ ਉਦੇਸ਼ ਇੱਕੋ ਹੈ: ਵਿਚਾਰ ਅਤੇ ਨਤੀਜੇ ਵਿਚਕਾਰ ਦੂਰੀ ਘਟਾਉਣਾ।
ਪੂਰੇ ਚੱਲ ਰਹੇ ਜਹਾਨ ਨੂੰ ਸੇਵ ਕਰਨਾ ਮੁਸ਼ਕਲ ਸਵਾਲ ਖੜੇ ਕਰਦਾ ਹੈ। ਜੇ "ਸੱਚਾਈ" ਇੱਕ ਮਿਊਟੇਬਲ ਸਟੇਟ ਵਿੱਚ ਰਹਿ ਜਾਵੇ, ਤਾਂ ਦੁਹਰਾਅ ਔਖਾ ਹੋ ਸਕਦਾ ਹੈ। ਡਿਪਲੋਇਮੈਂਟ ਜਟਿਲ ਹੋ ਸਕਦੀ ਹੈ: ਇੱਕ image ਭੇਜਣਾ ਐਪ, ਡੇਟਾ ਅਤੇ ਵਾਤਾਵਰਨ ਦੇ ਵਿਚਕਾਰ ਲਕੀਰ ਧੁੰਦਲੀ ਕਰ ਸਕਦਾ ਹੈ। ਬੱਗਸ ਅਜਿਹੇ ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਕਿਸੇ ਖਾਸ ਕ੍ਰਮ ਅਨੁਸਾਰ ਹੀ ਉਤਪੰਨ ਹੁੰਦੇ ਹਨ।
Smalltalk ਨੇ ਇਹ ਸ਼ਰਤ ਮਨ ਲਈ ਕਿ ਤੇਜ਼ ਸਿੱਖਣ ਅਤੇ ਇੱਟਰੇਸ਼ਨ ਉਹਨਾਂ ਜਟਿਲਤਾਵਾਂ ਦੇ ਲਾਇਕ ਹਨ—ਅਤੇ ਇਹ ਸੋਚ ਅੱਜ ਵੀ ਬਹੁਤ ਟੀਮਾਂ ਦੀ developer experience ਰੂਪ-ਰੇਖਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ।
ਜਦੋਂ ਐਲਨ ਕੇ ਸਾਫਟਵੇਅਰ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਸੀ, ਉਹ ਇਸਨੂੰ ਇੱਕ ਕੋਡ ਦੇ ਢੇਰ ਵਜੋਂ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਸਿਸਟਮ ਵਜੋਂ ਦੇਖਦਾ ਸੀ: ਸਮੇਂ ਦੇ ਨਾਲ ਪ੍ਰਭਾਵ ਪੈਦਾ ਕਰਨ ਲਈ ਕਈ ਹਿੱਸੇ ਇਕੱਠੇ ਕੰਮ ਕਰਦੇ।
ਕੋਈ ਵੀ ਸਿਸਟਮ ਕਿਸੇ ਇਕ ਇਕਾਈ ਨਾਲ ਨਹੀਂ ਪਰਿਭਾਸ਼ਤ ਹੁੰਦਾ। ਇਹ ਉਹਨਾਂ ਰਿਸ਼ਤਿਆਂ ਨਾਲ ਪਰਿਭਾਸ਼ਤ ਹੁੰਦਾ ਹੈ—ਕੌਣ ਕਿਸ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ, ਉਹ ਕੀ ਮੰਗ ਸਕਦਾ/ਸਕਦੀ ਹੈ, ਅਤੇ ਇਹ ਗੱਲਬਾਤ ਜਦੋਂ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ ਤਾਂ ਕੀ ਨਤੀਜਾ ਨਿਕਲਦਾ ਹੈ।
ਕੁਝ ਸਧਾਰਣ ਕੰਪੋਨੈਂਟ ਦੁਹਰਾਉਂ ਅਤੇ ਫੀਡਬੈਕ ਸ਼ਾਮਲ ਹੋਣ 'ਤੇ ਜਟਿਲ ਵਿਹਾਰ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਇੱਕ ਟਾਈਮਰ, ਇੱਕ ਮਾਡਲ ਜੋ ਸਟੇਟ ਅਪਡੇਟ ਕਰਦਾ, ਅਤੇ ਇੱਕ UI ਜੋ ਦੁਬਾਰਾ ਰੈਂਡਰ ਕਰਦਾ—ਇਹ ਸਧਾਰਣ ਹਿੱਸੇ ਮਿਲ ਕੇ ਐਨੀਮੇਸ਼ਨ, undo/redo, autosave, alerts, ਅਤੇ "ਇਹ ਹੁਣ ਕਿਉਂ ਬਦਲੀ?" ਵਰਗੀਆਂ ਘਟਨਾਵਾਂ ਬਣਾਉਂਦੇ ਹਨ।
ਇਸ ਲਈ ਸਿਸਟਮ-ਵਿਚਾਰ ਪ੍ਰਯੋਗਿਕ ਹੈ: ਇਹ ਤੁਹਾਨੂੰ ਲੂਪਾਂ ("ਜਦੋਂ A ਬਦਲੇ, B ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦਾ, ਜੋ C ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦਾ...") ਅਤੇ ਸਮੇਂ ("10 ਮਿੰਟ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ?") ਨੂੰ ਦੇਖਣ ਲਈ ਉਤਸ਼ਾਹਿੰਤ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇਕ-ਵਾਰ ਫੰਕਸ਼ਨ ਕਾਲਾਂ।
ਇਕ ਸਿਸਟਮ ਵਿੱਚ, ਇੰਟਰਫੇਸਾਂ ਦੀ ਮਹੱਤਤਾ ਅੰਦਰੂਨੀ ਇੰਪਲਿਮੈਂਟੇਸ਼ਨ ਨਾਲੋਂ ਵੱਧ ਹੁੰਦੀ ਹੈ। ਜੇ ਇੱਕ ਹਿੱਸਾ ਦੂਜੇ ਨਾਲ ਸਿਰਫ਼ ਸਾਫ਼ ਸੁਨੇਹਿਆਂ ("count increment ਕਰੋ", "render ਕਰੋ", "event record ਕਰੋ") ਰਾਹੀਂ ਗੱਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਤਰੀਕਿਆਂ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਹਰ ਥਾਂ ਕੋਡ ਬਦਲਣ ਦੀ ਲੋੜ ਹੋਏ।
ਇਹ ਕੇ ਦੀ ਮੇਸੇਜ-ਪਾਸਿੰਗ ਉੱਤੇ ਜ਼ੋਰ ਨਾਲ ਮਿਲਦਾ ਹੈ: ਤੁਸੀਂ ਹੋਰ ਹਿੱਸਿਆਂ ਨੂੰ ਸਿੱਧਾ ਕਾਬੂ ਨਹੀਂ ਕਰਦੇ; ਤੁਸੀਂ ਪੁڇਦੇ ਹੋ, ਉਹ ਜਵਾਬ ਦਿੰਦੇ ਹਨ।
ਤਿੰਨ ਆਬਜੈਕਟ ਸੋਚੋ:
ਸਮਾਂ-ਜਲ:
clicked ਭੇਜਦਾ ਹੈ।increment ਭੇਜਦਾ ਹੈ।changed(newValue) ਭੇਜਦਾ ਹੈ।changed ਨੂੰ ਸੁਣਕੇ ਦੁਬਾਰਾ ਰੈਂਡਰ ਕਰਦਾ ਹੈ।record("increment", newValue) ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।ਕਿਸੇ ਹਿੱਸੇ ਨੂੰ ਦੂਜੇ ਦੀ ਅੰਦਰੂਨੀ ਹਾਲਤ ਦੇਖਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਵਿਹਾਰ ਗੱਲਬਾਤ ਤੋਂ ਉਭਰਦਾ ਹੈ।
ਐਲਨ ਕੇ ਨੇ ਇੱਕ ਸਧਾਰਨ ਵਿਚਾਰ ਰੱਖਿਆ ਜੋ ਅਜੇ ਵੀ ਕਈ ਵਾਰ ਅਜੀਬ ਲੱਗਦਾ ਹੈ: ਸਾਫਟਵੇਅਰ ਨੂੰ ਸਿਰਫ਼ ਤਾਕਤਵਰ ਬਣਾਉਣ ਦੀ ਥਾਂ ਅਸਾਨ ਸਿੱਖਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। "ਚਤੁਰ" ਡਿਜ਼ਾਇਨ ਅਕਸਰ ਬਣਾਉਣ ਵਾਲੇ ਦੀ ਸਹੂਲਤ ਲਈ ਹੁੰਦਾ ਹੈ—ਛੋਟੇ ਰਸਤੇ, ਲੁਕਾਏ ਗਏ ਟ੍ਰਿਕ, ਘਣੇ ਅਬਸਟਰੇਕਸ਼ਨ—ਜੋ ਆਮ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਰੀਤੀਆਂ ਯਾਦ ਕਰਨ 'ਤੇ ਛੱਡ ਦਿੰਦਾ ਹੈ।
ਕੇ ਸਧਾਰਤਾ 'ਤੇ ਧਿਆਨ ਰੱਖਦਾ ਸੀ ਕਿਉਂਕਿ ਇਹ ਪੈਮਾਣੇ 'ਤੇ ਕੰਮ ਕਰਦੀ: ਇਕ ਸੁਝਾਅ ਜੋ ਇੱਕ ਸ਼ੁਰੂਆਤੀ आसानी ਨਾਲ ਸਮਝ ਸਕਦਾ ਹੈ, ਉਹ ਟੀਮਾਂ ਦੁਆਰਾ ਸਿਖਾਇਆ, ਸਾਂਝਾ, ਅਤੇ ਵਧਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਕਈ ਸਾਫਟਵੇਅਰ ਉਪਭੋਗਤਾਂ ਨੂੰ ਓਪਰੇਟਰ ਵਜੋਂ ਦੇਖਦਾ ਹੈ: ਸਹੀ ਬਟਨ ਦਬਾਓ, ਨਤੀਜਾ ਲਵੋ। ਕੇ ਦਾ ਲਕਸ਼ ਇਨ੍ਹਾਂ ਤੋਂ ਕਾਫੀ ਵੱਖਰਾ ਸੀ—ਇੱਕ ਸੋਚਣ ਵਾਲਾ ਟੂਲ, ਜੋ ਖੋਜ, ਟ੍ਰਾਇਲ-ਐਂਡ-ਏਰਰ ਨੂੰ ਨਿਮੰਤਰਤ ਕਰੇ, ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਮਾਨਸਿਕ ਮਾਡਲ ਬਣਾਉਣ ਦੇ ਯੋਗ ਬਣਾਏ।
ਇਸ ਕਰਕੇ ਉਹ ਇੰਟਰਐਕਟਿਵ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਵਧੀਕ ਮਹੱਤਵ ਦੇਂਦਾ ਸੀ ਜਿੱਥੇ ਤੁਸੀਂ ਜੋ ਹੋ ਰਿਹਾ ਹੈ ਉਹ ਤੁਰੰਤ ਦਿਖਾਈ ਦੇਂਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਉਸ ਅਨੁਸਾਰ ਸੋਧ ਕਰ ਸਕਦੇ ਹੋ। ਜਦੋਂ ਸਿਸਟਮ ਤੁਰੰਤ ਅਤੇ ਮਾਇਨੇਦਾਰ ਜਵਾਬ ਦਿੰਦਾ, ਸਿੱਖਣਾ ਵਰਤੋਣ da ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਕੇ ਅਕਸਰ ਸਿੱਖਣ—ਕਈ ਵਾਰ ਬੱਚਿਆਂ ਨੂੰ ਉਪਭੋਗਤਾ ਮੰਨ ਕੇ—ਨੂੰ ਇੱਕ ਕੇਥਾ ਫੋਰਸਿੰਗ ਫੰਕਸ਼ਨ ਵਜੋਂ ਵਰਤਦਾ ਸੀ। ਜੇ ਕੋਈ ਸੰਕਲਪ ਸਿੱਧਾ ਤੌਰ 'ਤੇ ਮੈਨਿਪੁਲੇਟ ਕੀਤਾ ਜਾ ਸਕੇ, ਇੰਸਪੈਕਟ ਕੀਤਾ ਜਾ ਸਕੇ, ਅਤੇ ਬਿਨਾਂ ਹਵਾਲਾ-ਦਿੱਤੀ ਸਮਝਾਏ ਸਮਝਾਇਆ ਜਾ ਸਕੇ, ਤਾਂ ਉਹ ਸਭ ਲਈ ਕੰਮ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧ ਜਾਂਦੀ ਹੈ।
ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ "ਕੇਵਲ ਬੱਚਿਆਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ"। ਬਲਕਿ ਇਹ ਹੈ ਕਿ ਸਿੱਖਣਯੋਗਤਾ ਨੂੰ ਇੱਕ ਗੁਣ-ਟੈਸਟ ਵਜੋਂ ਵਰਤੋ: ਕੀ ਸਿਸਟਮ ਆਪਣੀ ਤਰਕ ਨੂੰ ਖੁਦ ਦਿਖਾ ਸਕਦਾ ਹੈ?
ਸਿੱਖਣਯੋਗਤਾ ਇੱਕ ਉਤਪਾਦ ਫੀਚਰ ਹੈ। ਤੁਸੀਂ ਇਹਨੂੰ ਅਜੇਹੇ ਤਰੀਕਿਆਂ ਨਾਲ ਡਿਜ਼ਾਇਨ ਕਰ ਸਕਦੇ ਹੋ:
ਇਸਦਾ ਨਤੀਜਾ ਸਿਰਫ਼ ਖੁਸ਼ ਸ਼ੁਰੂਆਤੀ ਨਹੀਂ—ਇਹ ਤੇਜ਼ onboarding, ਘੱਟ ਸਪੋਰਟ ਟਿਕਟ, ਅਤੇ ਐਸਾ ਉਤਪਾਦ ਹੈ ਜੋ ਲੋਕ ਭਰੋਸੇ ਨਾਲ ਵਧਾ ਸਕਦੇ ਹਨ—ਉਹੀ "ਉਪਭੋਗਤਾ ਏਜੰਸੀ" ਜੋ ਕੇ ਚਾਹੁੰਦਾ ਸੀ।
ਕੇ ਦਾ ਕੰਮ ਹਰੇਕ ਚੀਜ਼ ਨਹੀ ਬਣਾਵੀ, ਪਰ ਉਸਨੇ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਦੀ ਸੋਚ 'ਤੇ ਪ੍ਰਭਾਵ ਛੱਡਿਆ—ਖ਼ਾਸ ਕਰਕੇ ਉਹ ਸਾਫਟਵੇਅਰ ਜੋ ਮਨੁੱਖਾਂ ਲਈ ਬਣੇ ਹਨ।
ਆਧੁਨਿਕ ਅਭਿਆਸ ਵਿੱਚ ਕਈ ਗੱਲਾਂ Smalltalk ਅਤੇ Xerox PARC ਦੀ ਸਭਿਆਚਾਰਿਕ ਸੋਚ ਤੋਂ ਆਈਆਂ ਹਨ:
ਕੁਝ ਅਸਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸਿੱਧਾ ਨਹੀਂ ਜਾਰੀ ਰਹੀਆਂ:
ਜੇ ਤੁਸੀਂ ਝੱਲ ਕੇ ਵੇਖੋ, ਅਸਲ ਵਿੱਚ ਬਹੁਤ-ਸਾਰੇ ਵਿਹਾਰ ਮੇਸੇਜ-ਪਾਸਿੰਗ ਨਾਲ ਗੂੰਜ਼ਦੇ ਹਨ: ਕੰਪੋਨੈਂਟ-ਆਧਾਰਤ UIs (React/Vue), ਇਵੇਂਟ-ਚਲਿਤ ਐਪਸ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਮਾਈਕਰੋਸਰਵਿਸ HTTP ਜਾਂ ਕਿਊਜ਼ 'ਤੇ ਗੱਲ ਕਰ ਰਹੇ ਹਨ। ਇਹ ਇਕੋ ਚੀਜ਼ ਨਹੀਂ ਪਰ ਕੇ ਦਾ ਮੁੱਖ ਵਿਚਾਰ (ਇੰਟਰਐਕਟ ਕਰਨ ਵਾਲੇ ਹਿੱਸੇ) ਆਧੁਨਿਕ ਸੀੰਦਰ ਵਿੱਚ ਵਖ-ਵੱਖ ਢੰਗ ਨਾਲ ਦੁਬਾਰਾ ਸਮਝਿਆ ਜਾ ਰਿਹਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਤਿਹਾਸ ਤੋਂ ਅਮਲੀ ਅਭਿਆਸ ਵੱਲ ਇੱਕ ਪ੍ਰਾਇਕਟਿਕਲ ਪਲ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਪੋਸਟ ਦੇ ਅੰਤਲੇ ਹਿੱਸੇ ਦੀ ਚੈੱਕਲਿਸਟ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਵਰਤੋਂਯੋਗ ਡਿਜ਼ਾਈਨ ਅਭਿਆਸ ਦੇਵੇਗੀ।
ਕੇ ਦਾ ਕੰਮ ਦਰਸ਼ਨੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਬਹੁਤ ਪ੍ਰਯੋਗਿਕ ਆਦਤਾਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ। ਤੁਹਾਨੂੰ Smalltalk ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ—ਤੁਹਾਨੂੰ ਕੇ-ਸਟਾਈਲ ਸੋਚ ਨੂੰ ਅਪਨਾਉਣ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਵਧਣ ਦੇ ਬਾਅਦ ਵੀ ਸਮਝਣਯੋਗ ਸਾਫਟਵੇਅਰ ਤਿਆਰ ਕਰ ਸਕੋ।
ਜਦੋਂ ਤੁਸੀਂ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੋ (ਜਾਂ ਰੀਫੈਕਟਰ ਕਰ ਰਹੇ ਹੋ), ਸਿਸਟਮ ਨੂੰ ਇਕੱਠੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਰੋਲਾਂ ਦੇ ਤੌਰ 'ਤੇ ਦਰਜ ਕਰੋ:
ਇਸ ਨਾਲ ਤੁਹਾਡੀ ਧਿਆਨ ਰਿਸਪੌਂਸਬਿਲਿਟੀਆਂ 'ਤੇ ਰਹੀ, ਨਾ ਕਿ ਕੇਵਲ "ਕਲਾਸਾਂ ਬਣਾਉਣ" ਦੀ।
ਡੇਟਾਬੇਸ ਟੇਬਲਾਂ ਜਾਂ ਕਲਾਸ ਹਾਇਰਾਰਕੀਜ਼ 'ਤੇ ਵਾਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਸੁਨੇਹਿਆਂ ਨੂੰ ਵੇਰਵਾ ਕਰੋ—ਇੱਕ ਹਿੱਸਾ ਦੂਜੇ ਨੂੰ ਕੀ ਪੂਛੇਗਾ।
ਇੱਕ ਲਾਭਦਾਇਕ ਅਭਿਆਸ: ਇੱਕ ਯੂਜ਼ਰ ਐਕਸ਼ਨ ਲਈ ਇੱਕ ਛੋਟੀ "ਗੱਲਬਾਤ" ਲਿਖੋ:
ਇਸ ਤੋਂ ਬਾਅਦ ਹੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਇਹ ਰੋਲ ਕਿਵੇਂ ਇੰਪਲੀਮੈਂਟ ਕਰਨੇ (ਕਲਾਸ, ਮਾਡਿਊਲ, ਸਰਵਿਸ) ਹਨ। ਇਹ ਕੇ ਦੇ ਮੇਸੇਜ-ਪਾਸਿੰਗ ਬਾਰੇ ਜ਼ੋਰ ਨਾਲ ਮਿਲਦਾ-ਜੁਲਦਾ ਹੈ: ਵਿਹਾਰ ਪਹਿਲਾਂ, ਢਾਂਚਾ ਬਾਅਦ ਵਿੱਚ।
ਕੇ ਲਾਈਵ ਸਿਸਟਮਾਂ ਦੀ ਪਰਵਾਨਗੀ ਕਰਦਾ ਸੀ ਜਿੱਥੇ ਤੁਸੀਂ ਬਦਲਾਅ ਤੇਜ਼ੀ ਨਾਲ ਵੇਖ ਸਕਦੇ ਹੋ। ਅਧੁਨਿਕ ਟੀਮ ਵਿੱਚ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ ਹੈ:
ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਕੀ ਬਦਲਿਆ—ਜਾਂ ਕੀ ਇਹ ਫਾਇਦਾ ਲਿਆ—ਤਾਂ ਤੁਸੀਂ ਅੰਧੇ ਵਿੱਚ ਉੱਡ ਰਹੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਚੈਟ-ਚਲਿਤ ਵਰਕਫਲੋ ਵਰਤ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ Koder.ai), ਏਕੋ ਹੀ ਸਲਾਹ ਲਾਗੂ ਹੁੰਦੀ ਹੈ: ਪ੍ਰਪੰਸ਼ ਅਤੇ ਜਨਰੇਟ ਕੀਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਦੁਹਰਾਓ, ਪਰ ਹੱਦਾਂ ਸਪਸ਼ਟ ਰੱਖੋ, ਅਤੇ snapshots/rollback ਅਤੇ ਸੋਰਸ ਕੋਡ ਨਿ ਸਰਟ ਜਿਹੜੇ ਸਿਸਟਮ ਨੂੰ ਸਮਝਣਯੋਗ ਬਣਾਉਂਦੇ ਹਨ ਵਰਤੋ।
ਜੇ ਇਹ ਸੈਕਸ਼ਨ ਤੁਹਾਨੂੰ ਛੂਹਿਆ:
ਇਹ ਵਿFਯੇ nostalgia ਤੋਂ ਵੱਧ ਤੁਹਾਡੀ ਚੋਣ-ਸਮੀਖਿਆ ਬਣਾਉਣ ਲਈ ਹਨ: ਐਸਾ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣਾ ਜੋ ਸਿੱਖਣਯੋਗ, ਅਨੁਕੂਲ, ਅਤੇ ਸਿਸਟਮ ਵਜੋਂ ਸੰਗਠਿਤ ਰਹੇ।
ਐਲਨ ਕੇ ਨੇ ਕੰਪਿਊਟਿੰਗ ਨਾਲ ਇੱਕ ਵੱਖਰਾ ਰਿਸ਼ਤਾ ਮਾਨਿਆ: ਕਤਾਰਵਾਰ batch ਕੰਮ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਇੰਟਰਐਕਟਿਵ ਨਿੱਜੀ ਮੀਡਿਆ ਜੋ ਸਿੱਖਣ ਅਤੇ ਬਣਾਉਣ ਲਈ ਹੋਵੇ।
ਇਹ ਸੋਚ ਉਹ ਉਮੀਦਾਂ ਸਿਰਜਦੀ ਹੈ ਜੋ ਅਸੀਂ ਹੁਣ ਸਧਾਰਨ ਮੰਨਦੇ ਹਾਂ — ਤੁਰੰਤ ਫੀਡਬੈਕ, ਮੈਨਿਪੁਲੇਸ਼ਨ ਯੋਗ ਇੰਟਰਫੇਸ, ਅਤੇ ਐਸਾ ਸਾਫਟਵੇਅਰ ਜੋ ਤੁਸੀਂ ਵਰਤਣ ਸਮੇਂ ਖੋਜ ਅਤੇ ਸੋਧ ਸਕਦੇ ਹੋ।
Dynabook ਇੱਕ ਦੂਰਦਰਸ਼ੀ ਧਾਰਨਾ ਸੀ: ਬਿਹਤਰ ਤੌਰ 'ਤੇ ਨਿੱਜੀ ਅਤੇ ਪੋਰਟੇਬਲ ਕੰਪਿਊਟਰ ਜੋ ਮੁੱਖ ਤੌਰ ਤੇ ਸਿੱਖਣ ਅਤੇ ਰਚਨਾਤਮਕਤਾ ਲਈ ਬਣਾਇਆ ਗਿਆ। (ਪੜ੍ਹਨਾ, ਲਿਖਣਾ, ਖਿੱਚਨਾ, ਸਿਮੂਲੇਸ਼ਨ ਆਦਿ)
ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਉਨ੍ਹਾਂ ਨੇ ਕਿਹਾ “ਉਹ ਨੇ ਟੈਬਲੇਟ ਭਵਿੱਖ ਵਿੱਚ ਦੇਖੇ।” ਬਜਾਏ, ਉਹ ਇਸ ਗੱਲ ਦੀ ਪਰਿਭਾਸ਼ਾ ਦਿੱਤੀ ਕਿ ਸਸ਼ਕਤ ਕਰਨ ਵਾਲੀ ਕੰਪਿਊਟਿੰਗ ਕਿਸ ਤਰ੍ਹਾਂ ਮਹਿਸੂਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਉਪਭੋਗਤਾ ਲੇਖਕ ਹੋਣ, ਸਿਰਫ਼ ਓਪਰੇਟਰ ਨਹੀਂ।
Smalltalk ਵਿੱਚ ਭਾਸ਼ਾ, ਟੂਲ ਅਤੇ UI ਇੱਕ ਬਹੁਤ ਹੀ ਮਿਲੀ-ਝੁਲੀ ਢਾਂਚੇ ਦਾ ਹਿੱਸਾ ਸਨ।
ਅਮਲ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਚਲਦਿਆਂ-ਫਿਰਦਿਆਂ ਆਬਜੈਕਟਾਂ ਨੂੰ ਨਿਰੀਖਣ ਕਰ ਸਕਦੇ ਹੋ, ਵਿਹਾਰ ਬਦਲ ਸਕਦੇ ਹੋ, ਇੰਟਰਐਕਟਿਵ ਤਰਤੀਬ ਨਾਲ ਡੀਬੱਗ ਕਰ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ ਵਾਰ-ਵਾਰ ਬਿਲਡ ਅਤੇ ਰੀਸਟਾਰਟ ਕਰਨ ਦੀ ਲੋੜ ਦੇ।
ਕੇ ਦਾ ਮੂਲ ਵਿਚਾਰ "ਕਲਾਸਾਂ ਅਤੇ ਵਿਰਾਸਤ" ਨਹੀਂ ਸੀ, ਬਲਕਿ ਆਬਜੈਕਟ ਲੈ ਕੇ ਖੁਦਮੁਖਤਿਆਰ ਏਜੰਟ ਜੋ ਇਕ ਦੂਜੇ ਨਾਲ ਸੁਨੇਹੇ ਭੇਜਦੇ ਹਨ।
ਡਿਜ਼ਾਇਨ ਤੌਰ 'ਤੇ, ਇਹ ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ ਹੱਦਾਂ ਦੇਣ ਤੇ ਧਿਆਨ ਦਿੱਤਾ ਕਰਦਾ ਹੈ: کالਰ ਇਹ ਜਾਣਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਆਬਜੈਕਟ ਕਿਹੜੇ ਸੁਨੇਹੇ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਇਸ ਦੀ ਅੰਦਰਲੀ ਡਾਟਾ-ਸੰਰਚਨਾ ਨੂੰ।
ਅਕਸਰ ਲੋਕ OOP ਨੂੰ ਇਕ ਕਿਸਮ ਦੀ ਟੈਕਸੋਨੋਮੀ ਸਮਝ ਲੈਂਦੇ ਹਨ: ਬੇਸ਼ੁਮਾਰ ਕਲਾਸਾਂ, ਡੂੰਘੀ ਓਅਰਕਲਿਡ ਵਿਰਾਸਤ ਅਤੇ ਸਾਂਝੀ ਮਿਊਟੇਬਲ ਡਾਟਾ।
ਕੇ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਵਧੀਆ ਨਿਯਮ:
GUI-software ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ ਜਿਵੇਂ ਤੁਸੀਂ ਚੀਜ਼ਾਂ ਨੂੰ ਸਿੱਧਾ ਮੈਨਿਪੁਲੇਟ ਕਰ ਰਹੇ ਹੋ (ਵਿੰਡੋ, ਬਟਨ, ਆਈਕਨ)।
ਇਹ ਆਬਜੈਕਟ ਮਾਡਲ ਨਾਲ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਮਿਲਦਾ ਹੈ—ਹਰ UI ਐਲਿਮੈਂਟ ਕੋਲ ਰਾਜ (state) ਅਤੇ ਵਿਹਾਰ (behavior) ਹੁੰਦਾ ਹੈ।
ਯੂਜ਼ਰ ਏਕਸ਼ਨ (ਕਲਿੱਕ, ਡ੍ਰੈਗ, ਕੀਸਟ੍ਰੋਕ) ਦਰਅਸਲ ਆਬਜੈਕਟਾਂ ਨੂੰ ਭੇਜੇ ਗਏ ਸੁਨੇਹੇ ਹੁੰਦੇ ਹਨ, ਜੋ ਸਿਸਟਮ ਨੂੰ ਆਗੇ ਵਧਾਉਂਦੇ ਹਨ।
Smalltalk ਦੀ image ਸੋਚ ਇਹ ਸੀ ਕਿ ਸਿਸਟਮ ਇੱਕ ਚਲਦੀ ਦੁਨੀਆ ਹੈ: ਤੁਸੀਂ ਪੂਰੇ ਚਲਦੇ ਵਾਤਾਵਰਣ—ਮੇਮੋਰੀ ਵਿੱਚ ਆਬਜੈਕਟ, ਖੁੱਲ੍ਹੇ ਟੂਲ, UI ਸਟੇਟ—ਨੂੰ ਸੇਵ ਕਰ ਸਕਦੇ ਹੋ।
ਫਾਇਦੇ:
ਟਰੇਡਅਫ:
ਸਿਸਟਮ ਵਿਚਾਰ (systems thinking) ਸਮੇਂ ਦੇ ਨਾਲ ਵਰਤੋਂ ਵਾਲੇ ਰਿਵਾਜਾਂ ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ: ਫੀਡਬੈਕ ਲੂਪ, ਕੈਸਕੇਡ ਪ੍ਰਭਾਵ ਅਤੇ ਕੌਣ ਕਿਸ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ।
ਅਮਲ ਵਿਚ, ਇਹ ਸਪਸ਼ਟ ਇੰਟਰਫੇਸ (ਸੁਨੇਹੇ) ਵਾਲੀਆਂ ਡਿਜ਼ਾਈਨਾਂ ਵੱਲ ਧਕੇਲਦਾ ਹੈ ਅਤੇ ਛੁਪੇ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਘੱਟ ਕਰਦਾ ਹੈ—ਰਿਸ਼ਤੇ ਅਤੇ ਗੱਲਬਾਤ ਮੁੱਖ ਹਨ, ਨਾਂ ਕਿ ਕੇਵਲ ਇਕੱਲੀਆਂ ਫੰਕਸ਼ਨ ਕਾਲਾਂ।
ਤੁਸੀਂ Smalltalk ਵਰਤਣੀ ਲੋੜ ਨਹੀਂ—ਤੱਤਾਂ ਨੂੰ ਸਮਝਣ ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਸਾਫ਼ ਰੱਖਣ ਲਈ ਕੁਝ ਆਮ ਅਭ્યાસ ਲਾਗੂ ਕਰੋ:
ਆਧੁਨਿਕ ਟੂਲਾਂ ਕਈ ਵਾਰ Kay ਦੀਆਂ ਮਨਸੂਬਾਬੰਦੀਆਂ ਨਾਲ ਗੂੰਜਦੇ ਹਨ, ਭਾਵੇਂ ਉਹ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕੀਤੇ ਗਏ ਹੋਣ:
ਇਹਨੂੰ Smalltalk ਦੀਆਂ ਇਕਸੈਕਟ ਵਿਧੀਆਂ ਨਹੀਂ ਮੰਨਣਾ ਚਾਹੀਦਾ, ਪਰ ਉਦੇਸ਼ ਇੱਕੋ ਹੈ: ਬਦਲਾਅ ਅਤੇ ਸਿੱਖਣ ਸਸਤੇ ਅਤੇ ਤੇਜ਼ ਬਣਾਉਣਾ।