ਸਿੱਖੋ ਕਿ ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਤੇਜ਼ feedback, ਸਧਾਰਣ workflow ਅਤੇ ਵਿਆਪਕ ਲਾਇਬ੍ਰੇਰੀਆਂ ਰਾਹੀਂ ਸਾਫਟਵੇਅਰ ਤਿਆਰ ਕਰਨ ਨੂੰ ਕਿਵੇਂ ਤੇਜ਼ ਕਰਦੀਆਂ ਹਨ—ਅਤੇ ਟੀਮਾਂ performance tradeoffs ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੀਆਂ ਹਨ।
"ਵਿਆਖਿਆਤ" ਭਾਸ਼ਾ ਉਹ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਕਿਸੇ ਹੋਰ ਪ੍ਰੋਗ੍ਰਾਮ — ਇੱਕ runtime, interpreter ਜਾਂ VM — ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਰੰਤ ਸੋਰਸ ਕੋਡ (ਜਿਵੇਂ Python ਜਾਂ JavaScript) ਲਿਖਦੇ ਹੋ, ਅਤੇ ਇੱਕ runtime ਉਸ ਨੂੰ ਪੜ੍ਹ ਕੇ ਪ੍ਰੋਗ੍ਰਾਮ ਚਲਾਉਂਦਾ ਹੈ।
runtime ਨੂੰ ਤੁਸੀਂ ਇੱਕ ਅਨੁਵਾਦਕ ਅਤੇ ਕੋਆਰਡੀਨੇਟਰ ਵਜੋਂ ਸੋਚੋ:
ਇਹੀ ਤਰੀਕੇ ਨਾਲ ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਨਾਲ ਕੰਮ ਕਰਨਾ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ: ਇਕ ਫਾਇਲ ਬਦਲੋ, ਦੁਬਾਰਾ ਚਲਾਓ ਅਤੇ ਤੁਰੰਤ ਨਤੀਜਾ ਵੇਖੋ।
ਕੰਪਾਇਲ ਕੀਤੀ ਭਾਸ਼ਾ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਅੱਗੇ ਤੋਂ ਮਸ਼ੀਨ-ਦਿਸ਼ਾ ਨਿਰਦੇਸ਼ਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਨਤੀਜਾ ਇੱਕ ਬਾਈਨਰੀ ਹੁੰਦਾ ਹੈ ਜਿਸਨੂੰ OS ਸਿੱਧਾ ਚਲਾ ਸਕਦਾ ਹੈ।
ਇਸ ਨਾਲ runtime ਦੀ ਰਫ਼ਤਾਰ ਵਧ ਸਕਦੀ ਹੈ, ਪਰ workflow ਵਿੱਚ ਕੁਝ ਹੋਰ ਕਦਮ ਵੀ ਆ ਜਾਂਦੇ ਹਨ (build configure ਕਰਨਾ, compilation ਦੀ ਉਡੀਕ, platform-specific ਨਿਕਾਸ) — ਜੋ ਹਮੇਸ਼ਾਂ ਦਰਦਨਾਕ ਨਹੀਂ ਹੁੰਦੇ ਪਰ ਫਿਰ ਵੀ ਕਦਮ ਹਨ।
Interpreted vs. compiled ਦਾ ਮਤਲਬ "Slow vs. Fast" ਨਹੀਂ ਹੈ; ਇਹ ਜ਼ਿਆਦਾ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:
ਕਈ ਲੋਕਪ੍ਰਿਯ "ਵਿਆਖਿਆਤ" ਭਾਸ਼ਾਵਾਂ ਲਾਈਨ-ਬਾਈ-ਲਾਈਨ ਚਲਾਉਣ ਵਾਲੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਪਹਿਲਾਂ ਬਾਈਟਕੋਡ ਵਿੱਚ compile ਹੋ ਸਕਦੀਆਂ ਹਨ, ਇੱਕ VM ਵਿੱਚ ਚਲਦੀਆਂ ਹਨ ਅਤੇ ਗਰਮ ਕੋਡ ਰਾਹੀਂ ਤੇਜ਼ ਕਰਨ ਲਈ JIT ਵਰਤ ਸਕਦੀਆਂ ਹਨ।
ਉਦਾਹਰਣ ਵਜੋਂ, ਆਧੁਨਿਕ JavaScript runtimes ਅਤੇ ਕੁਝ Python implementations interpretation ਅਤੇ compilation ਤਕਨੀਕਾਂ ਨੂੰ ਮਿਲਾਉਂਦੇ ਹਨ।
ਮਕਸਦ ਇਹ ਸਮਝਾਉਣਾ ਹੈ ਕਿ runtime-driven ਡਿਜ਼ਾਈਨ ਅਕਸਰ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਡਿਵੈਲਪਰ ਦੀ ਰਫ਼ਤਾਰ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ—ਤੇਜ਼ iteration, ਆਸਾਨ experimentation ਅਤੇ ਜਲਦੀ delivery—ਹਾਲਾਂਕਿ ਕੱਚੀ ਰਫ਼ਤਾਰ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਧਿਆਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਕਿ ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਇੱਕ ਲਾਈਨ ਬਦਲ ਕੇ ਤੁਰੰਤ ਨਤੀਜਾ ਵੇਖ ਸਕਦੇ ਹੋ। ਆਮ ਤੌਰ 'ਤੇ ਕੋਈ ਲੰਬਾ compile step ਨਹੀਂ, ਕੋਈ build pipeline ਦੀ ਉਡੀਕ ਨਹੀਂ, ਅਤੇ ਨਤੀਜੇ ਦੇਖਣ ਲਈ ਵੱਖ-ਵੱਖ ਆਰਟੀਫੈਕਟ ਨਾਲ ਖੇਡਣ ਦੀ ਲੋੜ ਨਹੀਂ।
ਇਹ tight edit–run–see loop ਵਿਕਾਸ ਨੂੰ ਛੋਟੇ, ਘੱਟ-ਖਤਰੇ ਵਾਲੇ ਕਦਮਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਬਹੁਤ ਸਾਰੇ interpreted ecosystem interactive ਕੰਮ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੇ ਹਨ। REPL (Read–Eval–Print Loop) ਜਾਂ interactive shell ਤੁਹਾਨੂੰ ਇੱਕ expression type ਕਰਨ, ਚਲਾਉਣ ਅਤੇ ਤੁਰੰਤ ਉੱਤਰ ਲੈਣ ਦਿੰਦੀਆਂ ਹਨ। ਇਹ ਕੇਵਲ ਸੁਵਿਧਾ ਨਹੀਂ—ਇਹ ਇੱਕ workflow ਹੈ।
ਤੁਸੀਂ:
ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਆਪਣੇ ਵਿਚਾਰ ਨੂੰ ਸਕਿੰਟਾਂ ਵਿੱਚ ਵੈਰੀਫਾਈ ਕਰ ਲੈਂਦੇ ਹੋ।
ਇਸੇ ਤਰ੍ਹਾਂ ਦਾ tight loop ਹੀ ਚੈਟ-ਡਰਾਈਵਨ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਜ਼ ਦੇ ਪ੍ਰਚਲਨ ਦਾ ਕਾਰਨ ਹੈ: ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai ਤੁਹਾਨੂੰ conversational interface ਰਾਹੀਂ ਐਪ ਵਰਤਕਾਰਤਾ ਤੇ iterate ਕਰਨ ਦਿੰਦਾ ਹੈ (ਫਿਰ ਜਦੋਂ ਚਾਹੀਦਾ ਹੈ ਤਾਂ source code export ਕਰਨ ਦੀ ਸਹੂਲਤ)। ਇਹ ਵਧੀਆ REPL ਦੇ ਨਿਯਮੇ ਹੀ ਹਨ: ਇੱਕ ਵਿਚਾਰ ਅਤੇ ਕੰਮ ਕਰਨ ਵਾਲੀ ਤਬਦੀਲੀ ਵਿਚਕਾਰ ਦੀ ਦੂਰੀ ਘਟਾਓ।
ਤੇਜ਼ feedback loops ਗਲਤ ਹੋਣ ਦੀ ਕੀਮਤ ਘਟਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਕੋਈ ਤਬਦੀਲੀ ਕੁਝ ਤੋੜਦੀ ਹੈ, ਤੁਸੀਂ ਉਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪਤਾ ਲਗਾ ਲੈਂਦੇ ਹੋ—ਅਕਸਰ ਉਦੋਂ ਹੀ ਜਦੋਂ ਮਾਮਲੇ ਦਾ ਸੰਦਰਭ ਤਾਜ਼ਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਖ਼ਾਸ ਕਰਕੇ ਸ਼ੁਰੂਆਤੀ ਅਵਸਥਾਵਾਂ ਵਿੱਚ ਕੀਮਤੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ requirements ਬਦਲ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਇਸੇ ਰਫ਼ਤਾਰ ਨਾਲ ਡੀਬੱਗਿੰਗ ਵੀ ਤੇਜ਼ ਹੋ ਜਾਂਦੀ ਹੈ: ਇੱਕ print ਜੋੜੋ, ਦੁਬਾਰਾ ਚਲਾਓ, ਆਉਟਪੁੱਟ ਇੰਸਪੈਕਟ ਕਰੋ। ਬਦਲਦੀਆਂ approaches ਨੂੰ ਆਜ਼ਮਾਉਣਾ ਰੋਟੀਨ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ edits ਅਤੇ results ਵਿਚਕਾਰ ਦੀ ਦੇਰੀ ਘੱਟ ਹੁੰਦੀ ਹੈ, momentum ਵੱਧਦਾ ਹੈ। ਡਿਵੈਲਪਰਜ਼ ਜ਼ਿਆਦਾ ਸਮਾਂ ਫ਼ੈਸਲੇ ਕਰਨ ਵਿੱਚ ਲਾਂਦੇ ਹਨ ਅਤੇ ਘੱਟ ਸਮਾਂ ਉਡੀਕ ਵਿੱਚ ਗੁਜ਼ਾਰਦੇ ਹਨ।
ਕੱਚੀ ਰਫ਼ਤਾਰ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਬਹੁਤ ਸਾਰਿਆਂ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਵੱਡੀ ਰੁਕਾਵਟ iteration speed ਹੁੰਦੀ ਹੈ। ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਉਸ workflow ਨੂੰ optimize ਕਰਦੀਆਂ ਹਨ, ਜੋ ਅਕਸਰ ਸਿੱਧਾ ਤੇਜ਼ ਡਿਲਿਵਰੀ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਅਕਸਰ "ਤੇਜ਼" ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ ਪਹਿਲਾਂ ਹੀ, ਕਿਉਂਕਿ ਉਹ ਤੁਹਾਨੂੰ ਘੱਟ scaffolding ਲਿਖਣ ਲਈ ਕਹਿੰਦੀਆਂ ਹਨ। ਘੱਟ required declarations, configuration files ਅਤੇ build steps ਨਾਲ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਸਮਾਂ ਵਿਚਾਰ ਪ੍ਰਗਟ ਕਰਨ ਵਿੱਚ ਲਗਾਉਂਦੇ ਹੋ, ਨਾ ਕਿ toolchain ਨੂੰ ਸੰਤੁਸ਼ਟ ਕਰਨ ਵਿੱਚ।
ਇੱਕ ਆਮ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਕੁਝ ਕਦਮਾਂ ਵਿੱਚ ਹੀ ਕੁਝ ਵਰਤੀਯੋਗ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
Python ਵਿੱਚ ਫਾਇਲ ਪੜ੍ਹ ਕੇ ਲਾਈਨਾਂ ਗਿਣਨ ਲਈ:
with open("data.txt") as f:
count = sum(1 for _ in f)
JavaScript ਵਿੱਚ, ਇੱਕ ਸੂਚੀ ਨੂੰ ਬਦਲਣਾ ਇਸੇ ਤਰ੍ਹਾਂ ਸਿੱਧਾ ਹੈ:
const names = users.map(u => u.name).filter(Boolean);
ਤੁਹਾਨੂੰ ਤਾਇਨਾਂ/ਕਲਾਸਾਂ/ਗੇਟਰ-ਸੈਟਰ ਲਿਖਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਪੈਂਦੀ ਸਿਰਫ਼ ਡੇਟਾ ਮੂਵ ਕਰਨ ਲਈ। ਇਹ "ਘੱਟ ceremony" ਸ਼ੁਰੂਆਤੀ ਵਿਕਾਸ ਦੌਰਾਨ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ requirements ਬਦਲ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਤੁਸੀਂ ਅਜੇ ਵੀ ਪਤਾ ਲਗਾ ਰਹੇ ਹੋ ਕਿ ਪ੍ਰੋਗਰਾਮ ਕੀ ਕਰੇ।
ਘੱਟ ਕੋਡ ਆਪਣੇ ਆਪ ਵਿੱਚ ਬਿਹਤਰ ਨਹੀਂ ਹੁੰਦਾ—ਪਰ ਘੱਟ moving parts ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ ਥਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਗਲਤੀਆਂ ਆ ਸਕਦੀਆਂ ਹਨ:
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਨਿਯਮ ਇੱਕ ਸਾਫ ਫੰਕਸ਼ਨ ਵਿੱਚ ਪ੍ਰਗਟ ਕਰ ਸਕਦੇ ਹੋ, ਤਦੋਂ ਉਹ review, test ਅਤੇ ਮਿਟਾਉਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਪ੍ਰਭਾਵਸ਼ালী syntax ਆਮ ਤੌਰ 'ਤੇ scan ਕਰਨ ਲਈ ਆਸਾਨ ਹੁੰਦੀ ਹੈ: indentation-ਆਧਾਰਤ ਬਲਾਕ, ਸਪਸ਼ਟ ਡੇਟਾ ਸਟ੍ਰੱਕਚਰ (list, dict/object), ਅਤੇ ਇੱਕ standard library ਜੋ ਆਮ ਕੰਮਾਂ ਲਈ ਬਣੀ ਹੋਵੇ। ਇਸ ਦਾ ਫ਼ਾਇਦਾ collaboration ਵਿੱਚ ਮਿਲਦਾ ਹੈ।
ਨਵਾਂ ਸਾਥੀ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ Python script ਜਾਂ ਛੋਟੀ Node service ਨੂੰ جلدੀ ਸਮਝ ਲੈਂਦਾ ਹੈ ਕਿਉਂਕਿ ਕੋਡ ਇਰਾਦਾ ਵਾਂਗ ਪੜ੍ਹਦਾ ਹੈ। ਤੇਜ਼ onboarding ਦਾ ਮਤਲਬ ਘੱਟ "tribal knowledge" ਮੀਟਿੰਗਾਂ ਅਤੇ ਵੱਧ ਵਿਸ਼ਵਾਸਯੋਗ ਤਬਦੀਲੀਆਂ—ਖ਼ਾਸ ਕਰਕੇ ਉਹ ਹਿੱਸੇ ਜਿਹੜੇ ਹਫ਼ਤਾਵਾਰ ਤੌਰ 'ਤੇ ਵਿਕਸਤ ਹੁੰਦੇ ਹਨ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਛੋਟੀ ਰਫ਼ਤਾਰ ਦੀਆਂ ਬਚਤਾਂ ਲਈ ਜ਼ੋਰ ਲਾਉਣਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਸਪਸ਼ਟ ਕੋਡ ਬਾਅਦ ਵਿੱਚ optimize ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਕੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ। ਪਹਿਲਾਂ ਰਿਲੀਜ਼ ਕਰੋ, ਅਸਲ bottlenecks measure ਕਰੋ, ਫਿਰ ਉਹਨਾਂ 5% ਨੂੰ ਸੁਧਾਰੋ—ਨਾਲ ਹੀ ਸਭ ਕੁਝ ਪਹਿਲਾਂ ਤੋਂ optimize ਕਰਕੇ ਵਿਕਾਸ ਨੂੰ ਸੁਸਤ ਨਾ ਕਰੋ।
ਡਾਇਨੈਮਿਕ ਟਾਈਪਿੰਗ ਦਾ ਸਿੱਧਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਹਰ ਵੈਲਿਊ ਦੀ ਸਹੀ "ਆਕਾਰ" ਪਹਿਲਾਂ ਹੀ بيان ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਂਦੀ। ਤੁਸੀਂ ਪਹਿਲਾਂ ਬਿਹੀਵੀਅਰ ਲਿਖ ਸਕਦੇ ਹੋ—ਇਨਪੁੱਟ ਪੜ੍ਹੋ, ਤਬਦੀਲ ਕਰੋ, ਆਉਟਪੁੱਟ ਲਓ—ਅਤੇ runtime ਦੌਰਾਨ ਰਨਟਾਈਮ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਹਰ ਵੈਲਿਊ ਕੀ ਹੈ।
ਸ਼ੁਰੂਆਤੀ ਵਿਕਾਸ ਵਿੱਚ momentum महੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ: ਇੱਕ ਪਤਲਾ end-to-end ਸਲਾਇਸ ਕੰਮ ਕਰਦਾ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਕੁਝ ਅਸਲ ਵੇਖ ਸਕਦੇ ਹੋ।
ਡਾਇਨੈਮਿਕ ਟਾਈਪਿੰਗ ਨਾਲ, ਤੁਸੀਂ ਅਕਸਰ interface definitions, generic type parameters ਜਾਂ ਬਾਰ-ਬਾਰ conversions ਨੂੰ ਛੱਡ ਸਕਦੇ ਹੋ ਜੋ compiler ਨੂੰ ਖੁਸ਼ ਕਰਨ ਲਈ ਲਿਖਣੇ ਪੈਂਦੇ। ਇਸ ਨਾਲ ਫਾਇਲਾਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ, declarations ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ "ਟੇਬਲ ਸੈੱਟ ਕਰਨ" ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਲੰਘਦਾ ਹੈ।
ਇਸੇ ਕਾਰਨ Python ਅਤੇ JavaScript prototypes, internal tools ਅਤੇ ਨਵੀਆਂ product features ਲਈ ਲੋਕਪ੍ਰਿਯ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਸਿੱਖ ਰਹੇ ਹੋ ਕਿ product ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ data model ਹਫ਼ਤੇ-ਦਰ-ਹਫ਼ਤਾ (ਕਈ ਵਾਰੀ ਰੋਜ਼ਾਨਾ) ਬਦਲ ਸਕਦੀ ਹੈ। ਡਾਇਨੈਮਿਕ ਟਾਈਪਿੰਗ ਇਸ ਤਬਦੀਲੀ ਨੂੰ ਸਸਤਾ ਬਣਾ ਦਿੰਦੀ ਹੈ:
ਇਹ ਲਚਕੀਲਾਪਣ iteration ਨੂੰ ਤੇਜ਼ ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਪਤਾ ਲਗਾ ਰਹੇ ਹੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਚਾਹੀਦਾ ਹੈ।
ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਕੁਝ errors runtime ਤੇ ਹੀ ਦਿੱਖਾਈ ਦਿੰਦੇ ਹਨ। ਇੱਕ property name ਦੀ ਟਾਈਪੋ, ਅਨਅਪੇਖਿਤ null, ਜਾਂ ਗਲਤ ਕਿਸਮ ਦਾ object ਪਾਸ ਹੋਣਾ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਉਹ ਲਾਈਨ ਚਲਾਈ ਜਾਂਦੀ ਹੈ—ਸ਼ਾਇਦ production ਵਿੱਚ ਵੀ।
ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਹੌਲਕੇ guardrails ਲਾਉਂਦੀਆਂ ਹਨ:
ਇਨ੍ਹਾਂ ਨੂੰ ਇਕੱਠਾ ਵਰਤ ਕੇ, ਸ਼ੁਰੂਆਤੀ ਲਚਕੀਲਾਪਣ ਬਰਕਰਾਰ ਰਹਿੰਦੀ ਹੈ ਪਰ runtime 'ਤੇ ਆਉਣ ਵਾਲੀ ਗਲਤੀਆਂ ਘੱਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਇੱਕ ਵੱਡਾ ਕਾਰਣ ਕਿ ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ "ਤੇਜ਼" ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ ਇਹ ਹੈ ਕਿ ਉਹ ਇੱਕ ਵਰਗ ਦਾ ਕੰਮ ਚੁੱਪ-ਚਾਪ ਸੰਭਾਲ ਲੈਂਦੀਆਂ ਹਨ ਜਿਸਨੂੰ ਹੋਰथाṁ ਤੁਸੀਂ ਸੋਚ ਕੇ ਬਣਾਉਣਾ ਪੈਂਦਾ: ਮੈਮੋਰੀ ਮੈਨੇਜਮੈਂਟ।
Python ਅਤੇ JavaScript ਵਰਗੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ objects (strings, lists, dictionaries, DOM nodes) ਬਣਾਉਂਦੇ ਹੋ ਬਿਨਾਂ ਇਹ ਸੋਚਣ ਦੇ ਕਿ ਉਹ ਕਿਸ memory ਵਿੱਚ ਰਹਿਣਗੇ ਜਾਂ ਕਦੋਂ ਹਟਾਏ ਜਾਣਗੇ। runtime ਇਸਨੂੰ ਟਰੈਕ ਕਰਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਕੋਈ object reachable ਨਹੀਂ ਰਹਿੰਦਾ ਤਾਂ ਮਹੱਤਵਪੂਰਨ ਮੈਮੋਰੀ ਵਾਪਸ ਲੈ ਲੈਂਦਾ ਹੈ।
ਇਹ ਆਮ ਤੌਰ 'ਤੇ garbage collection (GC) ਰਾਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਕਸਰ ਹੋਰ ਤਕਨੀਕਾਂ ਨਾਲ ਮਿਲ ਕੇ (ਜਿਵੇਂ Python ਦਾ reference counting)।
ਪ੍ਰਾਇਕਟਿਕ ਪ੍ਰਭਾਵ ਇਹ ਹੈ ਕਿ "allocate" ਅਤੇ "free" ਤੁਹਾਡੇ normal workflow ਦਾ ਹਿੱਸਾ ਨਹੀਂ ਰਹਿੰਦੇ। ਤੁਸੀਂ ਮਾਡਲਿੰਗ ਤੇ shipping behavior ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹੋ, ਨਾ ਕਿ lifetimes ਸੰਭਾਲਣ ਤੇ।
ਮੈਨੂਅਲ ਮੈਮੋਰੀ ਚਿੰਤਾਵਾਂ ਛੇਤੀ ਕੰਮ ਨੂੰ ਬੰਦ ਕਰ ਸਕਦੀਆਂ ਹਨ:
ਆਟੋਮੈਟਿਕ ਮੈਮੋਰੀ ਮੈਨੇਜਮੈਂਟ ਨਾਲ ਤੁਸੀਂ ਆਜ਼ਾਦੀ ਨਾਲ iterate ਕਰ ਸਕਦੇ ਹੋ। prototypes production ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਪਹਿਲਾਂ memory strategy ਮੁੜ ਲਿਖੇ।
GC ਮੁਫ਼ਤ ਨਹੀਂ। runtime ਵਧੀਕ bookkeeping ਕਰਦਾ ਹੈ, ਅਤੇ collection cycles ਕੁਝ runtime overhead ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਕੁਝ ਵਰਕਲੋਡ ਵਿੱਚ GC pauses (ਛੋਟੇ stop-the-world ਪਲ) ਵੀ ਪੈਦਾ ਹੋ ਸਕਦੇ ਹਨ, ਜੋ latency-sensitive ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਮਹਿਸੂਸ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਜਦੋਂ performance ਮਾਹਤਵ ਰੱਖਦੀ ਹੈ, ਤੁਸੀਂ ਭਾਸ਼ਾ ਨਹੀਂ ਛੱਡਦੇ—ਤੁਸੀਂ ਉਸ ਨੂੰ ਮਾਰਗਦਰਸ਼ਿਤ ਕਰਦੇ ਹੋ:
ਇਹ ਮੂਲ ਟਰੇਡ-ਆਫ ਹੈ: runtime ਹੋਰ ਭਾਰ ਸੰਭਾਲਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕੋ—ਫਿਰ ਜਦੋਂ ਲੋੜ ਹੋਵੇ optimize ਕਰੋ।
ਇੱਕ ਕਾਰਣ ਕਿ ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਕਈ ਵਾਰੀ ਜ਼ੀਰੋ ਤੋਂ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰ ਰਹੇ। ਤੁਸੀਂ ਮੌਜੂਦਾ ਕੰਮ ਕਰ ਰਹੇ building blocks ਨੂੰ ਜੋੜ ਰਹੇ ਹੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਟੈਸਟ ਕੀਤੇ ਹੋਏ ਹਨ ਅਤੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਸਮਝੇ ਜਾਂਦੇ ਹਨ।
ਕਈ ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ standard libraries ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਆਮ ਕੰਮਾਂ ਲਈ ਮੌਜੂਦ ਮੋਡੀਊਲ ਮੁਹੱਈਆ ਕਰਦੇ ਹਨ। ਇਹ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ setup time ਅਸਲ ਸਮਾਂ ਹੁੰਦੀ ਹੈ।
ਉਦਾਹਰਨ ਵਜੋਂ Python ਵਿੱਚ json, datetime, ਫਾਇਲ ਹੈਂਡਲਿੰਗ, compression, ਅਤੇ simple web servers ਦੇ ਮੋਡੀਊਲ ਹੁੰਦੇ ਹਨ। JavaScript runtimes Node.js ਵਿੱਚ JSON, networking, filesystem ਨਾਲ ਕੰਮ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਜਦੋਂ ਆਮ ਲੋੜਾਂ ਆਊਟ-ਆਫ-ਥੇ-ਬਾਕਸ ਹੱਲ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ early prototypes ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਦੇ ਹਨ—ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਕਿਸੇ ਤੀਜੇ-ਪੱਖੀ ਲਾਇਬ੍ਰੇਰੀ 'ਤੇ ਲੰਮੀ ਚਰਚਾ ਕਰਨ ਦੀ ਲੋੜ ਘਟਦੀ ਹੈ।
Ecosystems ਜਿਵੇਂ pip (Python) ਅਤੇ npm (JavaScript) dependency installation ਨੂੰ ਸਧਾਰਨ ਬਣਾਉਂਦੇ ਹਨ:
ਇਹ ਤੇਜ਼ੀ ਘੱਟ-ਘੱਟ ਸਮਾਂ ਵਿੱਚ compounds ਹੁੰਦੀ ਹੈ। OAuth ਚਾਹੀਦਾ? DB driver? CSV parsing? ਅਕਸਰ ਤੁਸੀਂ ਇੱਕੋ ਦਿਨ ਵਿੱਚ ਉਹ ਜੋੜ ਸਕਦੇ ਹੋ।
Frameworks ਆਮ ਕੰਮ (web apps, APIs, data workflows, automation scripts) ਲਈ conventions ਦਿੰਦੇ ਹਨ ਤਾਂ ਜੋ ਤੁਸੀਂ plumbing ਨਹੀਂ ਦੁਹਰਾਉਂਦੇ।
ਇੱਕ web framework routing, request parsing, validation, authentication patterns ਅਤੇ admin tooling ਘੱਟ ਕੋਡ ਨਾਲ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਡੇਟਾ/ਸਕ੍ਰਿਪਟਿੰਗ ਵਿੱਚ mature ecosystem ready-made connectors, plotting ਅਤੇ notebooks ਦਿੰਦੇ ਹਨ—ਜਿਸ ਨਾਲ exploration ਅਤੇ iteration ਕਾਫ਼ੀ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ।
ਓਹੀ ਸਹولت ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਵਾਪਸੀ ਕਰ ਸਕਦੀ ਹੈ ਜੇ ਹਰ ਨਵੀਂ ਫੀਚਰ ਇੱਕ ਨਵੀਂ ਲਾਇਬ੍ਰੇਰੀ ਖਿੱਚ ਲਿਆਉਂਦਾ ਹੈ।
versions tidy ਰੱਖਣ ਲਈ dependencies ਨੂੰ pin ਕਰੋ, transitive packages ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਅਤੇ update schedule ਬਣਾਓ। ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਜੇ dependency critical ਹੈ, ਤਾਂ ਇਸਨੂੰ ਆਪਣੀ product ਦੀ ਤਰ੍ਹਾਂ treat ਕਰੋ—use, test ਅਤੇ document ਕਰੋ ਕਿਉਂ ਇਹ ਉੱਥੇ ਹੈ (ਦੇਖੋ /blog/dependency-hygiene)।
ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ "loud" ਅਤੇ ਜਾਣਕਾਰੀ-ਪੂਰਕ ਤਰੀਕੇ ਨਾਲ fail ਹੁੰਦੀਆਂ ਹਨ। ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਪਸ਼ਟ error message ਅਤੇ stack trace ਮਿਲਦਾ ਹੈ—ਇੱਕ ਪਠ-ਪਾਰਟ ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ functions ਕਾਲ ਹੋਈਆਂ ਅਤੇ ਸਮੱਸਿਆ ਕਿੱਥੇ ਆਈ।
Python ਵਿੱਚ traceback ਸਪਸ਼ਟ ਫਾਈਲ ਅਤੇ ਲਾਈਨ ਦਿਖਾਉਂਦਾ ਹੈ। JavaScript runtimes ਵਿੱਚ console errors ਅਕਸਰ line/column info ਅਤੇ call stack ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਇਹ ਪ੍ਰਿਸੀਜ਼ਨ “ਇਹ ਕਿਉਂ ਟੁੱਟਿਆ?” ਨੂੰ “ਇਸ ਲਾਈਨ ਨੂੰ ਠੀਕ ਕਰੋ” ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ, ਜੋ ਘੰਟਿਆਂ ਬਚਾਉਂਦਾ ਹੈ।
ਅਕਸਰ interpreted ecosystems fast diagnosis ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਭਾਰੀ setup ਨਹੀਂ ਮੰਗਦੇ:
ਡਿਲਿਵਰੀ ਸਮਾਂ ਸਿਰਫ feature ਲਿਖਣਾ ਨਹੀਂ—ਇਹ ਅਚਾਨਕੀਆਂ ਲੱਭਣਾ ਅਤੇ ਠੀਕ ਕਰਨ ਵੀ ਹੈ। ਵਧੀਆ diagnostics ਵਾਂਝਾ-ਫਿਰ ਘਟਾਉਂਦੇ ਹਨ: ਘੱਟ prints, ਘੱਟ "ਸ਼ਾਇਦ ਇਹ ਹੋ ਰਿਹਾ ਹੈ" ਦੇ experiments, ਅਤੇ ਘੱਟ full rebuild cycles।
ਕੁਝ ਆਦਤਾਂ ਡੀਬੱਗਿੰਗ ਬਹੁਤ ਤੇਜ਼ ਕਰ ਦਿੰਦੀਆਂ ਹਨ:
request_id, user_id, duration_ms) ਤਾਂ ਕਿ ਤੁਸੀਂ filter ਅਤੇ correlate ਕਰ ਸਕੋਇਹ ਅਭਿਆਸ production issues ਨੂੰ reproduce ਕਰਨ ਅਤੇ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ fix ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਚਮਕਦੀਆਂ ਹਨ ਜਿੱਥੇ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਘੁੰਮਣਾ ਪੈਂਦਾ ਹੈ। ਜੇ ਮਸ਼ੀਨ ਉੱਤੇ ਸਹੀ runtime ਹੈ (ਜਿਵੇਂ Python ਜਾਂ Node.js), ਤਾਂ ਉਹੀ source code ਆਮ ਤੌਰ 'ਤੇ macOS, Windows ਅਤੇ Linux 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ।
ਇਹ portability ਇੱਕ development multiplier ਹੈ: ਤੁਸੀਂ laptop 'ਤੇ prototype ਕਰ ਸਕਦੇ ਹੋ, CI runner 'ਤੇ ਚਲਾ ਸਕਦੇ ਹੋ ਅਤੇ bina core logic rewrite ਕੀਤੇ production 'ਤੇ deploy ਕਰ ਸਕਦੇ ਹੋ।
ਨੁਕਤਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਹਰ OS ਲਈ compile ਨਾ ਕਰਕੇ ਇੱਕ runtime ਵਰਜ਼ਨ 'ਤੇ standardize ਕਰ ਲੈਂਦੇ ਹੋ ਅਤੇ runtime platform differences ਨੂੰ smooth ਕਰ ਦਿੰਦਾ ਹੈ।
ਤੱਥਿਕ ਰੀਤਾਂ:
ਬਹੁਤ ਸਾਰਾ ਅਸਲ ਕੰਮ integration ਹੁੰਦਾ ਹੈ: API ਤੋਂ ਡੇਟਾ ਲਿਆਉਣਾ, ਉਸ ਨੂੰ transform ਕਰਨਾ, DB ਵਿੱਚ ਲਿਖਣਾ, Slack ਨੂੰ notify ਕਰਨਾ ਅਤੇ dashboard update ਕਰਨਾ। ਇਨ੍ਹਾਂ ਲਈ interpreted ਭਾਸ਼ਾਵਾਂ ਲੋਕਪ੍ਰਿਯ ਹਨ ਕਿਉਂਕਿ ਉਹ ਲਿਖਣ ਵਿੱਚ ਤੇਜ਼ ਹਨ, standard libraries ਵਧੀਆ ਹਨ ਅਤੇ services ਲਈ mature SDKs ਉਪਲਬਧ ਹਨ।
ਇਸ ਕਰਕੇ ਉਹ ਛੋਟੇ adapters ਲਈ ਉੱਤਮ ਹਨ ਜੋ systems ਨੂੰ ਬਿਨਾਂ ਵੱਡੇ overhead ਦੇ ਜੋੜ ਰੱਖਦੇ ਹਨ।
startup overhead ਘੱਟ ਅਤੇ editing ਤੇਜ਼ ਹੋਣ ਕਰਕੇ, ਇਹ ਭਾਸ਼ਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ automation ਲਈ default ਹੁੰਦੀਆਂ ਹਨ:
ਇਹ tasks ਅਕਸਰ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ, ਇਸ ਲਈ “easy to modify” ਅਕਸਰ “max speed” ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ।
portability ਸਭ ਤੋਂ ਵਧੀਆ ਤਦ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ runtime ਅਤੇ dependencies ਨੂੰ control ਕਰੋ। ਆਮ ਅਭਿਆਸਾਂ ਵਿੱਚ virtual environments (Python), lockfiles (pip/poetry, npm) ਅਤੇ containerization ਸ਼ਾਮਲ ਹਨ।
ਟਰੇਡਆਫ: ਤੁਹਾਨੂੰ runtime upgrades manage ਕਰਨੇ ਪੈਣਗੇ ਅਤੇ dependency trees ਨੂੰ ਸਾਫ਼ ਰੱਖਣਾ ਪਵੇਗਾ, ਨਹੀਂ ਤਾਂ "works on my machine" ਮੁੜ ਆ ਸਕਦਾ ਹੈ।
ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਅਕਸਰ ਉਸ ਵੇਲੇ "ਤੇਜ਼" ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਤਿਆਰ ਕਰ ਰਹੇ ਹੋ—ਪਰ ਤਿਆਰ ਕੀਤੇ ਪ੍ਰੋਗਰਾਮ ਦੀ ਚਲਾਉਣ ਦੀ ਰਫ਼ਤਾਰ compiled ਭਾਸ਼ਾ ਦੇ ਬਰਾਬਰ ਨਾਹ ਹੋ ਸਕਦੀ। ਇਹ ਸੁਸਤਾਈ ਇੱਕ ਵੱਡੀ ਚੀਜ਼ ਨਹੀਂ ਹੁੰਦੀ; ਇਹ ਲੱਖਾਂ (ਅਥਵਾ ਅਰਬਾਂ) operations 'ਤੇ ਛੋਟੇ-ਛੋਟੇ ਲਾਗਤਾਂ ਦੇ ਜੋੜ ਨਾਲ ਹੁੰਦੀ ਹੈ।
ਕੰਪਾਇਲ ਕੀਤੀ ਪ੍ਰੋਗਰਾਮ ਅੱਗੇ ਹੀ ਕਈ ਵੇਰਿਆਂ ਦਾ ਫੈਸਲਾ ਕਰ ਸਕਦੀ ਹੈ। ਵਿਆਖਿਆਤ runtimes ਇਹ ਵੇਰਿਆਂ ਨੂੰ ਚਲਦੇ ਸਮੇਂ ਹੀ ਨਿਰਣੀ ਕਰਦੇ ਹਨ।
ਦੋ ਆਮ overhead ਸਰੋਤ ਹਨ:
ਹਰ ਚੈੱਕ ਛੋਟਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਇਹ ਲੱਖਾਂ ਵਾਰੀ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਇਹ ਭਾਰੀ ਹੋ ਜਾਂਦਾ ਹੈ।
ਪੇਰਫਰਮੈਂਸ ਸਿਰਫ਼ "ਕੋਡ ਕਿੰਨੀ ਤੇਜ਼ ਚੱਲਦਾ ਹੈ" ਦੀ ਗੱਲ ਨਹੀਂ। ਕੁਝ ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ startup time ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ runtime load, files parse ਅਤੇ modules import ਕਰਨ ਵਿੱਚ ਸਮਾਂ ਲੱਗਦਾ ਹੈ।
ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੈ:
ਇੱਕ ਵੈਬ ਸਰਵਰ ਜੋ ਦਿਨਾਂ-ਹਫ਼ਤਿਆਂ ਤੱਕ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ, ਉਸ ਲਈ startup time ਅਕਸਰ ਘੱਟ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ।
ਅਕਸਰ ਐਪਸ ਆਪਣਾ ਜ਼ਿਆਦਾ ਸਮਾਂ wait ਕਰਦੇ ਹੋਏ ਬਤੀਤ ਕਰਦੇ ਹਨ, ਨਾਕਿ ਕਠੋਰ ਗਣਨਾ ਕਰਦੇ ਹੋਏ।
ਇਸ ਲਈ ਇੱਕ Python ਜਾਂ JavaScript ਸਰਵਿਸ ਜੋ ਮੁੱਖਤੌਰ 'ਤੇ APIs ਅਤੇ DBs ਨਾਲ ਗੱਲ ਕਰਦੀ ਹੈ, production ਵਿੱਚ ਬਹੁਤ ਠੀਕ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਇਕ ਤੰਗ ਗਣਤਕ ਲੂਪ struggle ਕਰ ਸਕਦਾ ਹੈ।
ਵਿਆਖਿਆਤ-ਭਾਸ਼ਾ ਦੀ performance ਬਹੁਤ ਹੱਦ ਤੱਕ workload ਅਤੇ ਡਿਜ਼ਾਈਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਇੱਕ ਸਾਫ਼ ਆਰਕੀਟੈਕਚਰ, ਵਧੀਆ batching, ਅਤੇ ਸਮਾਰਟ caching ਕਿਸੇ ਵੀ ਭਾਸ਼ਾ ਵਿੱਚ ਖਰਾਬ ਡਿਜ਼ਾਈਨ ਨੂੰ ਹਰਾਇਆ ਸਕਦੀ ਹੈ।
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ "ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ slow ਹਨ", ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਹੌਟਸਪੌਟਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ—ਉਹ ਥਾਂ ਜਿੱਥੇ ਛੋਟੇ ਓਵਰਹੈਡ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ।
ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਅਕਸਰ ਸੰਸਾਰਕ ਤੌਰ 'ਤੇ "slow" ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਅਸਲ ਐਪਸ ਆਪਣਾ ਜ਼ਿਆਦਾ ਸਮਾਂ language overhead ਵਿੱਚ ਨਹੀਂ ਬਿਤਾਂਦੇ। ਜਦੋਂ speed bottleneck ਬਣਦੀ ਹੈ, ਤਾਂ ਇਹ ecosystem practical ਤਰੀਕੇ ਮੁਹੱਈਆ ਕਰਦੇ ਹਨ ਜੋ gap ਨੂੰ ਬਿਨਾਂ ਉਹ ਤੇਜ਼ iteration ਛੱਡੇ ਪੂਰਾ ਕਰ ਦਿੰਦੇ ਹਨ।
ਆਧੁਨਿਕ JavaScript ਜਿੰਨੀ ਤੇਜ਼ ਹੈ, ਉਸ ਵੱਡੇ ਹਿੱਸੇ ਦਾ ਕਾਰਨ engines ਵਿੱਚ ਮੌਜੂਦ JIT compiler ਹੈ।
ਰਨਟਾਈਮ ਵੇਖਦਾ ਹੈ ਕਿ ਕੋਡ ਕਿਹੜਾ ਵਾਰ-ਵਾਰ ਚਲ ਰਿਹਾ ਹੈ ("hot" code), ਫਿਰ ਉਸਦੇ ਭਾਗਾਂ ਨੂੰ ਮਸ਼ੀਨ ਕੋਡ ਵਿੱਚ compile ਕਰਦਾ ਹੈ ਅਤੇ ਅਬਜ਼ਰਵਡ types ਅਤੇ ਵਰਤੋਂ ਅਧਾਰ 'ਤੇ optimize ਕਰਦਾ ਹੈ।
ਹਰ ਵਿਆਖਿਆਤ ਭਾਸ਼ਾ JIT ਤੇ ਇਕੋ ਜਹੀ ਨੀਤੀ ਨਹੀਂ ਵਰਤਦੀ, ਪਰ ਨਮੂਨਾ ਇੱਕੋ ਹੈ: ਪਹਿਲਾਂ ਚਲਾਓ, ਜਾਨੋ ਕਿ ਕੀ ਮਹੱਤਵ ਹੈ, ਫਿਰ ਦੋਹਰਾਏ ਜਾਣ ਵਾਲੇ ਹਿੱਸਿਆਂ ਨੂੰ optimize ਕਰੋ।
ਕਿਸੇ ਵੀ rewrite ਤੋਂ ਪਹਿਲਾਂ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਬਦਲਾਵਾਂ ਨਾਲ ਚੰਗੇ ਨਤੀਜੇ ਲੱਭਦੇ ਹਨ:
ਜੇ profiling ਦਿਖਾਵੇ ਕਿ ਕੋਈ ਛੋਟਾ ਹਿੱਸਾ runtime ਨੂੰ dominate ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਅਲੱਗ ਕਰੋ:
ਸਭ ਤੋਂ ਵੱਡਾ productivity ਖ਼ਤਰਾ ਹੈ "optimizing vibes"। profile ਕਰੋ, ਫਿਰ ਠੀਕ ਕਰੋ ਅਤੇ ਫਿਰ verify ਕਰੋ। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ readability ਘਟਾ ਕੇ ਗਲਤ ਚੀਜ਼ ਨੂੰ ਹੀ accelerate ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਵਿਆਖਿਆਤ ਭਾਸ਼ਾ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਇੱਕ ਰUNTIME (Interpreter ਜਾਂ VM) ਦੁਆਰਾ ਚਲਾਉਂਦੀ ਹੈ ਜੋ ਪ੍ਰੋਗ੍ਰਾਮ ਨੂੰ ਪੜ੍ਹ ਕੇ ਰਨਟਾਈਮ ਦੌਰਾਨ ਇੱਕਸ਼ਟ ਹੁਕਮਾਂ ਨੂੰ ਅਮਲ ਵਿੱਚ ਲਿਆਉਂਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਕੋਈ ਨেটਿਵ ਐਕਜ਼ਿਕਿਊਟੇਬਲ ਨਹੀਂ ਬਣਾਉਂਦੇ; ਬਦਲੇ ਵਿੱਚ ਤੁਰੰਤ ਸੋਰਸ/ਬਾਈਟਕੋਡ ਨੂੰ ਰਨਟਾਈਮ ਦੇ ਰਾਹੀਂ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ।
ਰUNTIME ਤੁਹਾਡੀ ਪਿੱਠ-ਪਿੱਛੇ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਕਰਦਾ ਹੈ:
ਇਹ ਸਹਾਇਤਾ ਸੈਟਅਪ ਅਤੇ “ceremony” ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਆਮ ਤੌਰ ਤੇ ਵਿਕਾਸ ਨੂੰ ਤੇਜ਼ ਕਰਦੀ ਹੈ।
ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਛੇਤੀ-ਛੇਤੀ ਸਕ੍ਰਿਪਟ ਲਾਈਨ-ਬਾਈ-ਲਾਈਨ ਚਲਦੀਆਂ ਹੋਣ। ਬਹੁਤ ਸਾਰੀਆਂ “ਵਿਆਖਿਆਤ” ਭਾਸ਼ਾਵਾਂ ਅਸਲ ਵਿੱਚ ਹਾਈਬ੍ਰਿਡ ਹੁੰਦੀਆਂ ਹਨ:
ਸੋ “ਵਿਆਖਿਆਤ” ਅਕਸਰ ਵਰਕਫਲੋ ਅਤੇ ਰਨਟਾਈਮ ਮਾਡਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਸਖਤ ਤੌਰ 'ਤੇ ਲਾਈਨ-ਬਾਈ-ਲਾਈਨ ਅਮਲ।
ਕੰਪਾਇਲ ਕੀਤੀ ਭਾਸ਼ਾ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡਾ ਕੋਡ ਪਹਿਲਾਂ ਹੀ ਮਸ਼ੀਨ ਕੋਡ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ, ਜੋ ਰਨ-ਟਾਈਮ ਲਈ ਤੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ। ਵਿਆਖਿਆਤ ਵਰਕਫਲੋ ਆਮ ਤੌਰ 'ਤੇ ਰਨਟਾਈਮ 'ਤੇ ਕੁਝ ਕੰਮ ਛੱਡ ਦਿੰਦੇ ਹਨ ਤਾਂ ਜੋ ਸੰਪਾਦਨ/ਟੈਸਟ ਚੱਕਰ ਤੇਜ਼ ਰਹਿ ਸਕੇ:
ਕਿਹੜਾ ਚੰਗਾ ਹੈ ਇਹ ਤੁਹਾਡੇ ਲੋਡ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਕਿ ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਸ਼ੁਰੂਆਤੀ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਲਾਈਨ ਬਦਲਦੇ ਹੀ ਨਤੀਜੇ ਲੱਭ ਸਕਦੇ ਹੋ। ਆਮ ਤੌਰ 'ਤੇ ਕੋਈ ਲੰਬਾ ਕਾਂਪਾਇਲ-ਸਟੈਪ ਨਹੀਂ ਹੁੰਦਾ, ਨਾ ਹੀ ਵੱਡੀ ਬਿਲਡ ਪਾਈਪਲਾਈਨ। ਇਹ ਘੱਟ-ਖਤਰੇ ਵਾਲੀਆਂ ਛੋਟੀਆਂ ਤਬਦੀਲੀਆਂ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਅਕਸਰ ਇਹ ਚੱਕਰ ਇਹਨਾਂ ਗੱਲਾਂ ਲਈ ਵਧੀਆ ਹੈ:
ਇਹ ਤੁਹਾਡੇ ਵਿਚਾਰ ਨੂੰ ਸਕੰਡੀ ਮਿੰਟਾਂ ਵਿੱਚ ਮਨਜ਼ੂਰ ਕਰਨਾ ਆਸਾਨ ਕਰ ਦਿੰਦਾ ਹੈ।
ਇੱਕੋ ਹੀ ਕਾਰਨ ਹੈ ਕਿ ਚੈਟ-ਚਲਿਤ ਸਕੀਆਂ (ਜਿਵੇਂ Koder.ai) ਸ਼ੁਰੂਆਤੀ ਬਿਲਡਾਂ ਲਈ ਇਹ workflow ਤੇਜ਼ ਕਰਨਗੀਆਂ—ਇਸੇ ਤਰ੍ਹਾਂ ਜਿਵੇਂ ਇੱਕ ਵਧੀਆ REPL: ਵਿਚਾਰ ਤੋਂ ਕੰਮ ਕਰਨ ਵਾਲੀ ਤਬਦੀਲੀ ਤੱਕ ਫਾਸਲਾ ਘਟਾਉਣਾ।
REPL ਇਕ ਇੰਟਰੈਕਟਿਵ ਸ਼ੈੱਲ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਕੁਝ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ:
ਇਹ “ਮੈਂ ਸੋਚਦਾ/ਸੋਚਦੀ ਹਾਂ ਕਿ ਇਹ ਕਿਵੇਂ ਚਲੇਗਾ” ਨੂੰ ਸਕਿੰਟਾਂ ਵਾਲੀ ਜਾਂਚ ਬਣਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਲੰਬਾ ਐਡੀਟ/ਬਿਲਡ/ਰਨ ਚੱਕਰ।
ਡਾਇਨੈਮਿਕ ਟਾਈਪਿੰਗ ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਹਰ ਵੈਲਿਊ ਦੀ ਸਖਤ ਰੂਪ-ਰੇਖਾ ਪਹਿਲਾਂ ਨਹੀਂ ਲਿਖਣੀ ਪੈਂਦੀ। ਸ਼ੁਰੂਆਤੀ ਵਿਕਾਸ ਵਿੱਚ ਇਹ ਤੇਜ਼ੀ ਲਿਆਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਬਿਨਾਂ ਵੱਡੀ ਬੋਰਲਰਪ ਲਿਖੇ ਕਾਰਜ ਲਿਖ ਸਕਦੇ ਹੋ।
ਸੁਰੱਖਿਆ ਲਈ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਹਲਕੇ ਗਾਰਡਰੇਲ ਲਗਾਉਂਦੀਆਂ ਹਨ:
ਇਨ੍ਹਾਂ ਨਾਲ ਤੁਹਾਡੀ ਤੇਜ਼ੀ ਬਣੀ ਰਹਿੰਦੀ ਹੈ ਪਰ runtime ਅਣਪਛਾਤੇ ਸਪੈਲਿੰਗ/ਟਾਈਪ ਗਲਤੀਆਂ ਵਾਲੀ ਖ਼ਤਰੇ ਘੱਟ ਹੁੰਦੇ ਹਨ।
Automatic memory management (garbage collection, reference counting ਆਦਿ) ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਆਮ ਤੌਰ 'ਤੇ allocate/free ਦੇ ਮਾਮਲਿਆਂ ਨਾਲ ਹਰ ਵਾਰ ਨਹੀਂ ਜੂਝਣਾ ਪੈਂਦਾ। ਇਹ prototypes ਅਤੇ refactors ਨੂੰ ਘੱਟ ਜੋਖਮ ਵਾਲਾ ਬਣਾਉਂਦਾ ਹੈ।
ਖਿਆਲ ਰੱਖਣ ਵਾਲੀਆਂ ਗੱਲਾਂ:
ਜਦੋਂ ਲੋੜ ਪੈਂਦੀ ਹੈ ਤਾਂ:
ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਪੈਕੇਜ ਮੈਨੇਜਰ ਤੁਹਾਡੇ ਲਈ ਬਹੁਤ ਸਮਾਂ ਬਚਾਉਂਦੇ ਹਨ:
pip/npmਮੁੱਖ ਜੋਖਮ dependency sprawl ਹੈ। ਪ੍ਰਾਕਟਿਸ: ਵਰਜ਼ਨ पिन ਕਰੋ, transitive deps ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਅਤੇ ਜੇ ਕੋਈ dependency critical ਹੈ ਤਾਂ ਉਹਨੂੰ сво產品 ਵਾਂਗ ਰੱਖੋ। (ਦੇਖੋ /blog/dependency-hygiene)
ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਫੇਲ ਹੋਣ 'ਤੇ ਸਾਫ ਸੂਚਨਾ ਦਿੰਦੀਆਂ ਹਨ: error messages ਅਤੇ stack trace ਜੋ ਵਾਰ-ਵਾਰ ਕਿਸੇ ਫੰਕਸ਼ਨ/ਲਾਈਨ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ। ਇਸ ਨਾਲ “ਇਹ ਕਿਉਂ ਖਰਾਬ ਹੈ?” ਦੀ ਬਜਾਏ “ਇਸ ਲਾਈਨ ਨੂੰ ਠੀਕ ਕਰੋ” ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ।
ਹੋਰ ਟੂਲਸ ਜੋ flow ਵਿਚ ਰਹਿਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ:
ਇਹ ਸਭ diagnosis ਤੇਜ਼ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਡਿਲਿਵਰੀ ਸਮਾਂ ਘਟਦਾ ਹੈ।
ਹੋਰ ਸਧਾਰਨ ਅਭਿਆਸ ਜੋ ਡਿਬੱਗਿੰਗ ਤੇਜ਼ ਕਰਦੇ ਹਨ:
request_id, user_id, duration_ms)ਇਨ੍ਹਾਂ ਨਾਲ production issues ਦੀ reproduction ਅਤੇ fix ਤੇਜ਼ ਹੋ ਜਾਂਦੀ ਹੈ।
ਜੇ ਮਸ਼ੀਨ ਤੇ ਰਨਟਾਈਮ ਹੋਵੇ ਤਾਂ ਇੱਕੋ ਹੀ source ਆਮ ਤੌਰ 'ਤੇ macOS, Windows ਅਤੇ Linux 'ਤੇ ਚੱਲ ਸਕਦੀ ਹੈ। ਇਹ portability development ਨੂੰ ਤੇਜ਼ ਕਰਦੀ ਹੈ: laptop ਤੇ prototype, CI 'ਤੇ same command, ਫਿਰ production 'ਤੇ deploy।
ਅਮਲਿਕ ਰੀਤਾਂ:
ਇਸਦੇ ਨਾਲ packaging/containerization ਵਰਗੀਆਂ ਵਿਧੀਆਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਜੋ “works on my machine” ਸਮੱਸਿਆ ਘਟੇ।
ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਛੋਟੇ-ਛੋਟੇ ਓਵਰਹੈਡ ਕਰਕੇ ਕੁੱਲ ਰਫ਼ਤਾਰ 'ਚ ਪਿੱਛੇ ਰਹਿ ਸਕਦੀਆਂ ਹਨ:
ਕੁਝ ਹੋਰ ਪ੍ਰਭਾਵ:
ਪਰ ਜੇ ਕੰਮ ਜ਼ਿਆਦातर I/O-bound ਹੈ (DB, HTTP), ਤਾਂ ਰੁਕਾਵਟ ਆਮ ਤੌਰ 'ਤੇ ਭਰੀ ਗਣਨਾ ਨਾਲੋਂ ਘੱਟ ਹੁੰਦੀ ਹੈ।
ਜਦੋਂ ਚਾਹੀਦਾ ਹੈ, ਇਨ экਸੋਸਿਸਟਮਾਂ ਕੋਲ ਕਈ ਪ੍ਰਯੋਗਸ਼ੀਲ ਤਰੀਕੇ ਹੁੰਦੇ ਹਨ ਜਿਹਨਾਂ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ gap ਪੂਰੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ:
ਹਮੇਸ਼ਾਂ ਪਹਿਲਾਂ profile ਕਰੋ, ਫਿਰ optimize — ਨਾ ਕਿ ਬਿਨਾਂ ਮਾਪੇ ਥਿਆਰੀਕ ਤੌਰ 'ਤੇ ਤਬਦੀਲੀਆਂ ਕਰੋ।
ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਤੇਜ਼ ਤਰੱਕੀ ਲਈ optimize ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਫੈਸਲਾ ਕਰਨ ਲਈ ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ:
ਜਿੱਥੇ ਤੇਜ਼ੀ ਅਤੇ ਬਦਲਾਅ ਮਹੱਤਵਪੂਰਨ ਹਨ (APIs, automation, prototypes, internal tools), ਵਿਆਖਿਆਤ ਭਾਸ਼ਾਵਾਂ ਬਹੁਤ ਚੰਗੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਜਿੱਥੇ predictable high-volume latency ਜਾਂ ਭਾਰੀ compute ਚਾਹੀਦਾ ਹੈ, ਉੱਥੇ compiled options ਜਾਂ hybrid approaches ਸੋਚੋ।
ਹਾਂ — ਤੁਸੀਂ ਇੱਕ ਭਾਸ਼ਾ 'ਚ ਸ਼ੁਰੂ ਕਰਕੇ ਬਾਅਦ ਵਿੱਚ hot paths ਨੂੰ ਤੇਜ਼ ਹਿੱਸਿਆਂ ਵੱਲ ਲੈ ਜਾ ਸਕਦੇ ਹੋ:
ਮੁਢਲੇ ਨਿਯਮ: ਪਹਿਲਾਂ learning speed ਨੂੰ optimize ਕਰੋ, ਫਿਰ ਉਹੀ ਜਗ੍ਹਾ optimize ਕਰੋ ਜਿੱਥੇ ਬਦਲਾਅ ਦਾ ਫਾਇਦਾ ਚਿੱਟਾ ਹੈ।
ਇਕ REPL ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਕੰਮਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ:
ਇਹ ਤੁਸੀਂ ਸੋਚਦੇ ਸਮੇਂ ਨੂੰ ਤੁਰੰਤ ਪਰਖਣ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।