ਸਮਾਰਟ ਪ੍ਰੋਗਰਾਮਰਾਂ ਲਈ ਗੋ ਡਿਜ਼ਾਈਨ ਮਾੜਾ ਕਿਉਂ ਹੈ

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

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

ਗੋ ਸਿੱਖਣਾ ਬਹੁਤ ਆਸਾਨ ਹੈ, ਇੰਨਾ ਆਸਾਨ ਹੈ ਕਿ ਜਾਣ-ਪਛਾਣ ਮੈਨੂੰ ਇੱਕ ਸ਼ਾਮ ਲੈ ਗਈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਉਤਪਾਦਕ ਢੰਗ ਨਾਲ ਕੋਡ ਕਰ ਸਕਦਾ ਸੀ। ਮੈਂ ਗੋ ਸਿੱਖਣ ਲਈ ਵਰਤੀ ਗਈ ਕਿਤਾਬ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਗੋ ਵਿੱਚ ਪ੍ਰੋਗਰਾਮਿੰਗ ਦੀ ਜਾਣ-ਪਛਾਣ (ਅਨੁਵਾਦ), ਇਹ ਔਨਲਾਈਨ ਉਪਲਬਧ ਹੈ। ਕਿਤਾਬ, ਜਿਵੇਂ ਗੋ ਸਰੋਤ ਕੋਡ ਆਪਣੇ ਆਪ ਵਿੱਚ, ਪੜ੍ਹਨਾ ਆਸਾਨ ਹੈ, ਚੰਗੀਆਂ ਕੋਡ ਉਦਾਹਰਣਾਂ ਹਨ, ਅਤੇ ਇਸ ਵਿੱਚ ਲਗਭਗ 150 ਪੰਨੇ ਹਨ ਜੋ ਇੱਕ ਵਾਰ ਵਿੱਚ ਪੜ੍ਹੇ ਜਾ ਸਕਦੇ ਹਨ। ਇਹ ਸਾਦਗੀ ਪਹਿਲਾਂ ਤਾਜ਼ਗੀ ਦਿੰਦੀ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਤਕਨਾਲੋਜੀ ਨਾਲ ਭਰੀ ਇੱਕ ਪ੍ਰੋਗਰਾਮਿੰਗ ਸੰਸਾਰ ਵਿੱਚ. ਪਰ ਅੰਤ ਵਿੱਚ, ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਇਹ ਵਿਚਾਰ ਪੈਦਾ ਹੁੰਦਾ ਹੈ: "ਕੀ ਇਹ ਅਸਲ ਵਿੱਚ ਅਜਿਹਾ ਹੈ?"

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

ਤਾਂ ਇਸ ਨੂੰ ਇੰਨਾ ਸਰਲ ਕਿਉਂ ਬਣਾਇਆ ਗਿਆ? ਇੱਥੇ ਹਵਾਲੇ ਦੇ ਇੱਕ ਜੋੜੇ ਨੂੰ ਹਨ ਰੋਬ ਪਾਈਕ (ਲਗਭਗ: ਗੋ ਭਾਸ਼ਾ ਦੇ ਸਹਿ-ਰਚਨਾਕਾਰਾਂ ਵਿੱਚੋਂ ਇੱਕ):

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

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

ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਾਦਗੀ ਦੀਆਂ ਕਲਾਕ੍ਰਿਤੀਆਂ

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

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

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

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

package main

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

func main() {

    flag.Parse()
    flags := flag.Args()

    var text string
    var scanner *bufio.Scanner
    var err error

    if len(flags) > 0 {

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

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

        scanner = bufio.NewScanner(file)

    } else {
        scanner = bufio.NewScanner(os.Stdin)
    }

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

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

    fmt.Println(text)
}

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

ਇੱਥੇ, ਉਦਾਹਰਨ ਲਈ, ਵਿੱਚ ਉਸੇ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਹੈ D:

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);
    }
}

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

ਨਕਲ ਦਾ ਨਰਕ

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

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 int16Sum(list []int16) (uint64) {
    var result int16 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

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

func main() {

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

    fmt.Println(int8Sum(list8))
    fmt.Println(int16Sum(list16))
    fmt.Println(int32Sum(list32))
    fmt.Println(int64Sum(list64))
}

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

ਡੀ 'ਤੇ ਉਹੀ ਉਦਾਹਰਣ:

import std.stdio;
import std.algorithm;

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

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

ਸਧਾਰਨ ਕਿਸਮ ਦਾ ਸਿਸਟਮ ਬਾਈਪਾਸ

ਮੈਂ ਕਲਪਨਾ ਕਰਦਾ ਹਾਂ ਕਿ ਗੋ ਪ੍ਰੋਗਰਾਮਰ ਇਸ ਨੂੰ ਪੜ੍ਹਦੇ ਹੋਏ ਮੂੰਹ 'ਤੇ ਝੱਗ ਆਉਣਗੇ ਅਤੇ ਚੀਕ ਰਹੇ ਹੋਣਗੇ, "ਤੁਸੀਂ ਇਹ ਗਲਤ ਕਰ ਰਹੇ ਹੋ!" ਖੈਰ, ਇੱਕ ਆਮ ਫੰਕਸ਼ਨ ਅਤੇ ਕਿਸਮਾਂ ਬਣਾਉਣ ਦਾ ਇੱਕ ਹੋਰ ਤਰੀਕਾ ਹੈ, ਪਰ ਇਹ ਟਾਈਪ ਸਿਸਟਮ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤੋੜਦਾ ਹੈ!

ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਇੱਕ ਮੂਰਖ ਭਾਸ਼ਾ ਫਿਕਸ ਦੀ ਇਸ ਉਦਾਹਰਨ 'ਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੋ:

package main

import "fmt"
import "reflect"

func Reduce(in interface{}, memo interface{}, fn func(interface{}, interface{}) interface{}) interface{} {
    val := reflect.ValueOf(in)

    for i := 0; i < val.Len(); i++ {
        memo = fn(val.Index(i).Interface(), memo)
    }

    return memo
}

func main() {

    list := []int{1, 2, 3, 4, 5}

    result := Reduce(list, 0, func(val interface{}, memo interface{}) interface{} {
        return memo.(int) + val.(int)
    })

    fmt.Println(result)
}

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

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

ਮੈਂ ਇਸ ਬਕਵਾਸ ਦੀ ਬਜਾਏ ਡੀ ਟੈਂਪਲੇਟਸ ਲਵਾਂਗਾ. ਕੋਈ ਇਹ ਕਿਵੇਂ ਕਹਿ ਸਕਦਾ ਹੈ interface{} ਵਧੇਰੇ ਪੜ੍ਹਨਯੋਗ ਜਾਂ ਟਾਈਪ ਸੁਰੱਖਿਅਤ?

ਨਿਰਭਰਤਾ ਪ੍ਰਬੰਧਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ

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

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

ਸ਼ੀ ਤੋਂ ਸੱਭਿਆਚਾਰਕ ਸਮਾਨ

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

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

ਆਪਣੇ ਫਾਇਦੇ ਲਈ ਸਾਦਗੀ

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

ਇਹ ਸਮਾਰਟ ਪ੍ਰੋਗਰਾਮਰਾਂ ਲਈ ਬਹੁਤ ਹੀ ਜ਼ੁਬਾਨੀ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਅਤੇ ਮਾੜਾ ਹੈ।

Спасибо mersinvald ਸੰਪਾਦਨ ਲਈ

ਸਰੋਤ: www.habr.com