Ինչու է Go-ն վատ ոչ խելացի ծրագրավորողների համար

Հոդվածը գրվել է որպես պատասխան ավելի վաղ հրապարակված հոդվածի հակապոդեական հոդված.

Ինչու է Go-ն վատ ոչ խելացի ծրագրավորողների համար

Վերջին երկու և ավելի տարիների ընթացքում ես օգտագործել եմ Go-ն՝ մշակված վճարային համակարգով մասնագիտացված RADIUS սերվերի ներդրման համար: Ճանապարհին ես սովորում եմ հենց լեզվի բարդությունները: Ծրագրերն իրենք շատ պարզ են և այս հոդվածի նպատակը չեն, սակայն Go-ի օգտագործման փորձն ինքնին արժանի է մի քանի խոսքի՝ ի պաշտպանություն դրա: Go-ն դառնում է ավելի ու ավելի հիմնական լեզու լուրջ, մասշտաբային կոդի համար: Լեզուն ստեղծվել է Google-ի կողմից, որտեղ այն ակտիվորեն օգտագործվում է։ Ներքևի գիծ, ​​ես անկեղծորեն կարծում եմ, որ Go լեզվի դիզայնը վատ է ոչ խելացի ծրագրավորողների համար:

Նախատեսված է թույլ ծրագրավորողների համար?

Թույլերը խոսում են խնդիրների մասին. Ուժեղ խոսում են գաղափարների և երազանքների մասին...

Go-ն շատ հեշտ է սովորել, այնքան հեշտ, որ կարող եք կարդալ կոդը՝ գործնականում առանց ուսուցման: Լեզվի այս առանձնահատկությունն օգտագործվում է բազմաթիվ համաշխարհային ընկերություններում, երբ կոդը ընթերցվում է ոչ հիմնական մասնագետների հետ միասին (մենեջեր, հաճախորդներ և այլն): Սա շատ հարմար է այնպիսի մեթոդոլոգիաների համար, ինչպիսին է Design Driven Development-ը:
Նույնիսկ սկսնակ ծրագրավորողները սկսում են բավականին պատշաճ կոդ արտադրել մեկ կամ երկու շաբաթ անց: Գիրքը, որից ես սովորել եմ, «Go Programming» է (Մարկ Սամերֆիլդ): Գիրքը շատ լավն է, շոշափում է լեզվի բազմաթիվ նրբերանգներ։ Անտեղի բարդ լեզուներից հետո, ինչպիսիք են Java-ն, PHP-ն, մոգության բացակայությունը թարմացնում է: Բայց վաղ թե ուշ, շատ սահմանափակ ծրագրավորողներ ունեն նոր ոլորտում հին մեթոդներ օգտագործելու գաղափարը: Արդյո՞ք սա իսկապես անհրաժեշտ է:

Ռոբ Պայքը (լեզվի հիմնական գաղափարախոսը) ստեղծել է Go լեզուն՝ որպես արդյունաբերական լեզու, որը հեշտ է հասկանալի և արդյունավետ օգտագործելու համար։ Լեզուն նախատեսված է մեծ թիմերում առավելագույն արտադրողականության համար, և դրանում կասկած չկա: Շատ սկսնակ ծրագրավորողներ բողոքում են, որ կան բազմաթիվ առանձնահատկություններ, որոնք բացակայում են: Պարզության այս ցանկությունը լեզվի դիզայներների գիտակցված որոշումն էր, և որպեսզի լիովին հասկանանք, թե ինչու էր դա անհրաժեշտ, մենք պետք է հասկանանք մշակողների մոտիվացիան և ինչի էին նրանք փորձում հասնել Go-ում:

Ուրեմն ինչու՞ էր այն այդքան պարզ: Ահա մի քանի մեջբերում Ռոբ Պայքից.

Այստեղ առանցքային կետն այն է, որ մեր ծրագրավորողները հետազոտողներ չեն: Նրանք, որպես կանոն, բավականին երիտասարդ են, սովորելուց հետո գալիս են մեզ մոտ, երևի Java են սովորել, կամ C/C++ կամ Python։ Նրանք չեն կարողանում հասկանալ հիանալի լեզու, բայց միևնույն ժամանակ մենք ցանկանում ենք, որ նրանք ստեղծեն լավ ծրագրեր: Այդ իսկ պատճառով լեզուն պետք է հեշտ հասկանալի և սովորել։

Նա պետք է ծանոթ լինի, կոպիտ ասած նման լինի Ք. Google-ում աշխատող ծրագրավորողները իրենց կարիերան սկսում են վաղ և հիմնականում ծանոթ են ընթացակարգային լեզուներին, մասնավորապես C ընտանիքին: Նոր ծրագրավորման լեզվի արագ արտադրողականության պահանջը նշանակում է, որ լեզուն չպետք է չափազանց արմատական ​​լինի:

Չէ՞ որ իմաստուն խոսքեր են։

Պարզության արտեֆակտներ

Պարզությունը գեղեցկության համար անհրաժեշտ պայման է։ Լև Տոլստոյ.

Պարզ պահելը ցանկացած դիզայնի ամենակարևոր նպատակներից մեկն է: Ինչպես գիտեք, կատարյալ նախագիծը այն նախագիծը չէ, որտեղ ավելացնելու ոչինչ չկա, այլ այն, որից հեռացնելու բան չկա: Շատերը կարծում են, որ բարդ խնդիրներ լուծելու (կամ նույնիսկ արտահայտելու) համար անհրաժեշտ է բարդ գործիք: Այնուամենայնիվ, դա այդպես չէ: Օրինակ վերցնենք PERL լեզուն։ Լեզվի գաղափարախոսները կարծում էին, որ ծրագրավորողը պետք է ունենա առնվազն երեք տարբեր ճանապարհ մեկ խնդիր լուծելու համար: Գո լեզվի գաղափարախոսները գնացին այլ ճանապարհով, նրանք որոշեցին, որ նպատակին հասնելու համար բավական է մի ճանապարհ, բայց իսկապես լավը։ Այս մոտեցումը լուրջ հիմք ունի. միակ ճանապարհն ավելի հեշտ է սովորել և ավելի դժվար մոռանալ:

Շատ միգրանտներ դժգոհում են, որ լեզուն էլեգանտ աբստրակցիաներ չի պարունակում։ Այո, դա ճիշտ է, բայց սա լեզվի հիմնական առավելություններից մեկն է։ Լեզուն պարունակում է նվազագույն մոգություն, ուստի ծրագիրը կարդալու համար խորը գիտելիքներ չեն պահանջվում: Ինչ վերաբերում է օրենսգրքի բազմակողմանիությանը, սա ամենևին էլ խնդիր չէ։ Լավ գրված Golang ծրագիրը կարդում է ուղղահայաց՝ քիչ կամ առանց կառուցվածքի: Բացի այդ, ծրագրի ընթերցման արագությունը առնվազն մեծության կարգով ավելի մեծ է, քան այն գրելու արագությունը: Եթե ​​կարծում եք, որ բոլոր ծածկագրերն ունեն միատեսակ ձևաչափում (կատարվում է ներկառուցված gofmt հրամանի միջոցով), ապա մի քանի լրացուցիչ տող կարդալն ամենևին էլ խնդիր չէ։

Ոչ շատ արտահայտիչ

Արվեստը չի հանդուրժում, երբ իր ազատությունը կաշկանդված է։ Ճշգրտությունը նրա պարտականությունը չէ:

Պարզության ցանկության պատճառով Գոյին զուրկ են կոնստրուկցիաներ, որոնք այլ լեզուներով ընկալվում են որպես բնական մի բան իրենց սովոր մարդկանց կողմից: Սկզբում դա կարող է ինչ-որ չափով անհարմար լինել, բայց հետո նկատում եք, որ ծրագիրը շատ ավելի հեշտ է և միանշանակ կարդալը:

Օրինակ, վահանակի օգտակար ծրագիրը, որը կարդում է stdin կամ ֆայլ հրամանի տողի փաստարկներից, նման կլինի.

package main

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

func main() {

    flag.Parse()

    scanner := newScanner(flag.Args())

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

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

    fmt.Println(text)
}

func newScanner(flags []string) *bufio.Scanner {
    if len(flags) == 0 {
        return bufio.NewScanner(os.Stdin)
    }

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

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

    return bufio.NewScanner(file)
}

Նույն խնդրի լուծումը 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);
    }
}

Պատճենահանման դժոխք

Մարդն իր մեջ կրում է դժոխք: Մարտին Լյութեր.

Սկսնակները անընդհատ դժգոհում են Go-ից՝ ջեներիկայի բացակայության առումով։ Այս խնդիրը լուծելու համար նրանցից շատերը օգտագործում են կոդերի ուղղակի պատճենում։ Օրինակ, ամբողջ թվերի ցուցակի ամփոփման գործառույթը, նման հավանական մասնագետները կարծում են, որ ֆունկցիոնալությունը չի կարող իրականացվել այլ կերպ, քան տվյալների յուրաքանչյուր տեսակի պարզ պատճենահանման միջոցով:

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 main() {

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

    fmt.Println(int32Sum(list32))
    fmt.Println(int64Sum(list64))
}

Լեզուն ունի բավարար միջոցներ նման կառուցումներ իրականացնելու համար։ Օրինակ, ընդհանուր ծրագրավորումը լավ կլիներ:

package main

import "fmt"

func Eval32(list []int32, fn func(a, b int32)int32) int32 {
    var res int32
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int32Add(a, b int32) int32 {
    return a + b
}

func int32Sub(a, b int32) int32 {
    return a + b
}

func Eval64(list []int64, fn func(a, b int64)int64) int64 {
    var res int64
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int64Add(a, b int64) int64 {
    return a + b
}

func int64Sub(a, b int64) int64 {
    return a - b
}

func main() {

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

    fmt.Println(Eval32(list32, int32Add))
    fmt.Println(Eval64(list64, int64Add))
    fmt.Println(Eval64(list64, int64Sub))
}

Եվ, թեև մեր օրենսգիրքը որոշ չափով երկար է ստացվել, քան նախորդ դեպքը, այն ընդհանրացվել է։ Ուստի մեզ համար դժվար չի լինի իրականացնել բոլոր թվաբանական գործողությունները։

Շատերը կասեն, որ D-ով ծրագիրը զգալիորեն ավելի կարճ է թվում, և նրանք ճիշտ կլինեն։

import std.stdio;
import std.algorithm;

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

Այնուամենայնիվ, դա միայն ավելի կարճ է, բայց ոչ ավելի ճիշտ, քանի որ D-ի իրականացումն ամբողջությամբ անտեսում է սխալների հետ աշխատելու խնդիրը:

Իրական կյանքում, քանի որ տրամաբանության բարդությունը մեծանում է, այդ բացն արագորեն նվազում է: Բացը նույնիսկ ավելի արագ է փակվում, երբ անհրաժեշտ է կատարել այնպիսի գործողություն, որը հնարավոր չէ կատարել ստանդարտ լեզվով օպերատորների միջոցով:

Պահպանելիության, ընդարձակելիության և ընթեռնելիության առումով, իմ կարծիքով, Go լեզուն հաղթում է, թեև պարտվում է խոսակցականության մեջ։

Ընդհանրացված ծրագրավորումը որոշ դեպքերում մեզ անհերքելի առավելություններ է տալիս: Սա հստակ ցույց է տալիս տեսակավորման փաթեթը: Այսպիսով, ցանկացած ցուցակը տեսակավորելու համար մենք պարզապես պետք է իրականացնենք sort.Interface ինտերֆեյսը:

import "sort"

type Names []string

func (ns Names) Len() int {
    return len(ns)
}

func (ns Names) Less(i, j int) bool {
    return ns[i] < ns[j]
}

func (ns Names) Swap(i, j int) {
    ns[i], ns[j] = ns[j], ns[i]
}

func main() {
    names := Names{"London", "Berlin", "Rim"}
    sort.Sort(names)
}

Եթե ​​վերցնեք որևէ բաց կոդով նախագիծ և գործարկեք grep “interface{}” -R հրամանը, կտեսնեք, թե որքան հաճախ են օգտագործվում շփոթեցնող միջերեսները: Մոտ մտերիմ ընկերները անմիջապես կասեն, որ այս ամենը պայմանավորված է գեներիկայի բացակայությամբ։ Այնուամենայնիվ, դա միշտ չէ, որ այդպես է: Որպես օրինակ վերցնենք DELPHI-ն: Չնայած այս նույն գեներիիկների առկայությանը, այն պարունակում է հատուկ VARIANT տեսակ՝ կամայական տվյալների տեսակներով գործողությունների համար: Go լեզուն նույնն է անում:

Թնդանոթից մինչև ճնճղուկներ

Իսկ զսպաշապիկը պետք է համապատասխանի խելագարության չափին։ Ստանիսլավ Լեկ.

Շատ էքստրեմալ երկրպագուներ կարող են պնդել, որ Go-ն ունի գեներիկայի ստեղծման մեկ այլ մեխանիզմ՝ արտացոլումը։ Եվ նրանք ճիշտ կլինեն... բայց միայն հազվադեպ դեպքերում։

Ռոբ Փայքը զգուշացնում է մեզ.

Սա հզոր գործիք է, որը պետք է օգտագործվի զգուշությամբ: Այն պետք է խուսափել, եթե խիստ անհրաժեշտ չէ:

Վիքիպեդիան մեզ ասում է հետևյալը.

Արտացոլումը վերաբերում է գործընթացին, որի ընթացքում ծրագիրը կարող է վերահսկել և փոփոխել իր կառուցվածքը և վարքագիծը կատարման ընթացքում: Արտացոլման հիմքում ընկած ծրագրավորման պարադիգմը կոչվում է ռեֆլեկտիվ ծրագրավորում: Սա մետածրագրավորման տեսակ է։

Այնուամենայնիվ, ինչպես գիտեք, ամեն ինչի համար պետք է վճարել։ Այս դեպքում դա հետևյալն է.

  • ծրագրեր գրելու դժվարություն
  • ծրագրի կատարման արագությունը

Հետեւաբար, արտացոլումը պետք է օգտագործվի զգուշությամբ, ինչպես խոշոր տրամաչափի զենքը: Արտացոլման չմտածված օգտագործումը հանգեցնում է անընթեռնելի ծրագրերի, մշտական ​​սխալների և ցածր արագության: Պարզապես սնոբ ծրագրավորողի համար կարող է ցուցադրել իր կոդը այլ, ավելի պրագմատիկ և համեստ գործընկերների առաջ:

Մշակութային ուղեբեռ Սիի՞ց։ Ոչ, մի շարք լեզուներից։

Հարստության հետ ժառանգներին մնում են նաեւ պարտքեր։

Չնայած այն հանգամանքին, որ շատերը կարծում են, որ լեզուն ամբողջությամբ հիմնված է C ժառանգության վրա, դա այդպես չէ: Լեզուն ներառում է լավագույն ծրագրավորման լեզուների բազմաթիվ ասպեկտներ:

շարահյուսություն

Նախ և առաջ քերականական կառուցվածքների շարահյուսությունը հիմնված է C լեզվի շարահյուսության վրա։ Այնուամենայնիվ, ԴԵԼՖԻ լեզուն նույնպես զգալի ազդեցություն ունեցավ։ Այսպիսով, մենք տեսնում ենք, որ ավելորդ փակագծերը, որոնք մեծապես նվազեցնում են ծրագրի ընթեռնելիությունը, ամբողջությամբ հանվել են։ Լեզուն պարունակում է նաև «:=» օպերատորը, որը բնորոշ է DELPHI լեզվին: Փաթեթների հայեցակարգը փոխառված է այնպիսի լեզուներից, ինչպիսին է ADA-ն: Չօգտագործված սուբյեկտների հայտարարագիրը փոխառված է PROLOG լեզվից:

Իմաստաբանություն

Փաթեթները հիմնված էին DELPHI լեզվի իմաստաբանության վրա: Յուրաքանչյուր փաթեթ ներառում է տվյալներ և ծածկագիր և պարունակում է մասնավոր և պետական ​​մարմիններ: Սա թույլ է տալիս նվազագույնի հասցնել փաթեթի ինտերֆեյսը:

Պատվիրակության մեթոդով իրականացումը վերցված է DELPHI լեզվից:

Կազմում

Առանց պատճառի չէ, որ կա կատակ. Go-ն մշակվել է այն ժամանակ, երբ C ծրագիր էր կազմվում: Լեզվի ուժեղ կողմերից մեկը նրա գերարագ կոմպիլյացիան է։ Գաղափարը փոխառված է DELPHI լեզվից։ Յուրաքանչյուր Go փաթեթ համապատասխանում է DELPHI մոդուլին: Այս փաթեթները վերակազմավորվում են միայն այն դեպքում, երբ իսկապես անհրաժեշտ է: Հետևաբար, հաջորդ խմբագրումից հետո ձեզ հարկավոր չէ ամբողջ ծրագիրը կազմել, այլ վերակազմավորել միայն փոխված փաթեթներն ու փաթեթները, որոնք կախված են այս փոփոխված փաթեթներից (և նույնիսկ այն դեպքում, եթե փաթեթի միջերեսները փոխվել են):

Բարձր մակարդակի կոնստրուկցիաներ

Լեզուն պարունակում է բազմաթիվ տարբեր բարձր մակարդակի կառուցվածքներ, որոնք ոչ մի կերպ կապված չեն ցածր մակարդակի լեզուների հետ, ինչպիսին է C-ն:

  • Ստրերներ
  • Հեշ սեղաններ
  • Շերտեր
  • Duck մուտքագրումը փոխառված է այնպիսի լեզուներից, ինչպիսին RUBY-ն է (որը, ցավոք, շատերը չեն հասկանում կամ օգտագործում են իր ողջ ներուժը):

Հիշողության կառավարում

Հիշողության կառավարումն ընդհանրապես արժանի է առանձին հոդվածի: Եթե ​​C++-ի նման լեզուներում կառավարումն ամբողջությամբ թողնված է մշակողին, ապա ավելի ուշ DELPHI-ի նման լեզուներում օգտագործվել է հղումների հաշվման մոդել: Այս մոտեցմամբ ցիկլային հղումները թույլ չեն տրվել, քանի որ ձևավորվել են որբ կլաստերներ, այնուհետև Go-ն ունի ներկառուցված նման կլաստերների հայտնաբերում (ինչպես C#): Բացի այդ, աղբահավաքն ավելի արդյունավետ է, քան ներկայումս հայտնի իրականացումները և արդեն կարող է օգտագործվել իրական ժամանակում բազմաթիվ առաջադրանքների համար: Լեզուն ինքնին ճանաչում է իրավիճակներ, երբ փոփոխականը պահելու արժեք կարող է հատկացվել փաթեթի վրա: Սա նվազեցնում է հիշողության կառավարչի բեռը և մեծացնում ծրագրի արագությունը:

Concurrency եւ Concurrency

Լեզվի զուգահեռությունն ու մրցունակությունը գովասանքից վեր են։ Ոչ մի ցածր մակարդակի լեզու չի կարող նույնիսկ հեռակա կարգով մրցել Go-ի հետ: Արդարության համար հարկ է նշել, որ մոդելը չի ​​հորինվել լեզվի հեղինակների կողմից, այլ պարզապես փոխառվել է հին բարի ADA լեզվից: Լեզուն ի վիճակի է մշակել միլիոնավոր զուգահեռ կապեր՝ օգտագործելով բոլոր պրոցեսորները՝ միաժամանակ ունենալով մեծության ավելի քիչ բարդ խնդիրներ փակուղիներով և ռասայական պայմաններով, որոնք բնորոշ են բազմաշերտ կոդի համար:

Լրացուցիչ առավելություններ

Եթե ​​շահավետ լինի, բոլորը կդառնան անշահախնդիր։

Լեզուն մեզ տալիս է նաև մի շարք անկասկած առավելություններ.

  • Նախագիծը կառուցելուց հետո մեկ գործարկվող ֆայլը մեծապես հեշտացնում է հավելվածների տեղակայումը:
  • Ստատիկ մուտքագրումը և տիպի եզրակացությունը կարող են զգալիորեն նվազեցնել ձեր կոդի սխալների քանակը, նույնիսկ առանց թեստեր գրելու: Ես գիտեմ որոշ ծրագրավորողների, ովքեր ընդհանրապես առանց թեստեր գրելու անում են ու նրանց կոդի որակը էապես չի տուժում։
  • Շատ պարզ խաչաձև կոմպիլյացիան և ստանդարտ գրադարանի գերազանց շարժունակությունը, ինչը մեծապես հեշտացնում է միջպլատֆորմային հավելվածների զարգացումը:
  • RE2 կանոնավոր արտահայտությունները անվտանգ են թելի համար և ունեն կանխատեսելի կատարման ժամանակներ:
  • Հզոր ստանդարտ գրադարան, որը թույլ է տալիս նախագծերի մեծ մասին անել առանց երրորդ կողմի շրջանակների:
  • Լեզուն բավականաչափ հզոր է, որպեսզի կենտրոնանա խնդրի վրա, այլ ոչ թե ինչպես լուծել այն, բայց բավական ցածր մակարդակի վրա, որպեսզի խնդիրը հնարավոր լինի արդյունավետ լուծել:
  • Go eco համակարգն արդեն պարունակում է մշակված գործիքներ բոլոր առիթների համար՝ թեստեր, փաստաթղթեր, փաթեթների կառավարում, հզոր լինտերներ, կոդերի ստեղծում, մրցավազքի պայմանների դետեկտոր և այլն:
  • Go տարբերակը 1.11-ը ներկայացրեց ներկառուցված իմաստային կախվածության կառավարում, որը կառուցված է հայտնի VCS հոստինգի վրա: Բոլոր գործիքները, որոնք կազմում են Go էկոհամակարգը, օգտագործում են այս ծառայությունները՝ դրանցից կոդի ներբեռնման, ստեղծման և տեղադրման համար մեկ հարվածով: Եվ դա հիանալի է: 1.11 տարբերակի հայտնվելով փաթեթի տարբերակների հետ կապված խնդիրը նույնպես ամբողջությամբ լուծվեց։
  • Քանի որ լեզվի հիմնական գաղափարը կախարդանքը նվազեցնելն է, լեզուն խրախուսում է ծրագրավորողներին բացահայտորեն լուծել սխալները: Եվ սա ճիշտ է, քանի որ հակառակ դեպքում այն ​​պարզապես կմոռանա սխալների հետ վարվելու մասին: Մեկ այլ բան այն է, որ մշակողների մեծամասնությունը միտումնավոր անտեսում է սխալների հետ կապված խնդիրները՝ նախընտրելով դրանք մշակելու փոխարեն պարզապես սխալը վերև փոխանցել:
  • Լեզուն չի իրականացնում դասական OOP մեթոդաբանությունը, քանի որ իր մաքուր ձևով Go-ում վիրտուալություն չկա: Այնուամենայնիվ, դա խնդիր չէ միջերեսների օգտագործման ժամանակ: OOP-ի բացակայությունը զգալիորեն նվազեցնում է սկսնակների մուտքի խոչընդոտը:

Պարզություն համայնքի շահի համար

Դա հեշտ է բարդացնելը, դժվար է պարզեցնել:

Go-ն ստեղծվել է պարզ լինելու համար, և այն հաջողվում է հասնել այդ նպատակին: Այն գրվել է խելացի ծրագրավորողների համար, ովքեր հասկանում են թիմային աշխատանքի առավելությունները և հոգնել են Enterprise մակարդակի լեզուների անսահման փոփոխականությունից: Ունենալով իր զինանոցում շարահյուսական կառուցվածքների համեմատաբար փոքր հավաքածու, այն գործնականում չի ենթարկվում փոփոխությունների ժամանակի ընթացքում, ուստի մշակողները շատ ժամանակ են ազատել զարգացման համար, այլ ոչ թե լեզվական նորարարությունները անվերջ ուսումնասիրելու համար:

Ընկերությունները ստանում են նաև մի շարք առավելություններ՝ մուտքի ցածր արգելքը թույլ է տալիս արագ մասնագետ գտնել, իսկ լեզվի անփոփոխությունը թույլ է տալիս օգտագործել նույն կոդը նույնիսկ 10 տարի անց։

Ամփոփում

Ուղեղի մեծ չափը երբեք ոչ մի փղի չի դարձրել Նոբելյան մրցանակի դափնեկիր:

Այն ծրագրավորողների համար, ում անձնական էգոն գերադասում է թիմային ոգուց, ինչպես նաև տեսաբանների համար, ովքեր սիրում են ակադեմիական մարտահրավերները և անվերջ «ինքնակատարելագործումը», լեզուն իսկապես վատ է, քանի որ այն ընդհանուր նշանակության արհեստավոր լեզու է, որը թույլ չի տալիս ստանալ գեղագիտական ​​հաճույք ձեր աշխատանքի արդյունքից և պրոֆեսիոնալ դրսևորեք ձեզ գործընկերների առջև (պայմանով, որ մենք ինտելեկտը չափում ենք այս չափանիշներով, և ոչ թե IQ-ով): Ինչպես կյանքում ամեն ինչ, դա անձնական առաջնահերթությունների հարց է։ Ինչպես բոլոր արժեքավոր նորարարությունները, լեզուն արդեն երկար ճանապարհ է անցել համընդհանուր ժխտումից մինչև զանգվածային ընդունում: Լեզուն հնարամիտ է իր պարզությամբ, և, ինչպես գիտեք, ամեն ինչ հնարամիտ պարզ է:

Source: www.habr.com

Добавить комментарий