Програмчлалын хэлний дизайны талаархи таван асуулт

Програмчлалын хэлний дизайны талаархи таван асуулт

Удирдах философи

1. Хүмүүст зориулсан програмчлалын хэл

Програмчлалын хэл нь хүмүүс компьютертэй хэрхэн харьцаж байгааг хэлдэг. Компьютер хоёрдмол утгагүй ямар ч хэлээр ярихдаа баяртай байх болно. Бид өндөр түвшний хэлтэй болсон шалтгаан нь хүмүүс машины хэлийг зохицуулж чадахгүй байгаатай холбоотой. Програмчлалын хэлний гол зорилго нь бидний ядуу, эмзэг хүний ​​тархийг хэт олон нарийн ширийн зүйлд дарагдахаас урьдчилан сэргийлэх явдал юм.

Архитекторууд дизайны зарим асуудал бусдаасаа илүү энгийн байдаг гэдгийг мэддэг. Хамгийн тодорхой бөгөөд хийсвэр дизайны асуудлуудын зарим нь гүүрний дизайн юм. Энэ тохиолдолд таны ажил бол шаардлагатай зайг аль болох бага материалаар туулах явдал юм. Спектрийн нөгөө төгсгөлд сандлын дизайн байдаг. Сандал зохион бүтээгчид хүмүүсийн өгзөгний талаар бодож цагийг өнгөрөөх хэрэгтэй.

Програм хангамжийн хөгжүүлэлт нь ижил төстэй ялгаатай байдаг. Сүлжээгээр дамжуулан өгөгдөл дамжуулах алгоритмыг зохион бүтээх нь гүүрийг зохион бүтээх шиг сайхан хийсвэр асуудал юм. Програмчлалын хэлийг зохион бүтээх нь сандал зохион бүтээхтэй адил юм: та хүний ​​сул талыг даван туулах хэрэгтэй.

Бидний ихэнх нь үүнийг ойлгоход хэцүү байдаг. Математикийн гоёмсог системийг зохион бүтээх нь бидний ихэнхэд хүний ​​сул талыг хайхрамжгүй хандахаас хамаагүй илүү сонирхолтой санагддаг. Математик дэгжин байдлын үүрэг бол зарим түвшний дэгжин байдал нь хөтөлбөрийг ойлгоход хялбар болгодог. Гэхдээ энэ бүхэн дэгжин байдлын тухай биш юм.

Хэл нь хүний ​​сул тал дээр зохицсон байх ёстой гэж хэлэхэд би хэлийг муу програмистуудад зориулагдсан байх ёстой гэсэн үг биш юм. Бодит байдал дээр та хамгийн сайн програмистуудад зориулсан программ хангамжийг зохион бүтээх хэрэгтэй, гэхдээ хамгийн сайн програмистуудад ч гэсэн хязгаар байдаг. Бүх хувьсагчийг "х" үсгээр тэмдэглэсэн бүхэл тоон дэвсгэрттэй хэлээр программчлах нь хэнд ч таалагдахгүй байх гэж бодож байна.

2. Өөртөө болон найз нөхөддөө зориулж дизайн хий

Хэрэв та програмчлалын хэлнүүдийн түүхийг харвал ихэнх шилдэг хэлүүдийг өөрсдийн зохиогчид ашиглахаар, хамгийн муу хэлийг бусад хүмүүст ашиглахаар бүтээжээ.

Хэл нь бусад хүмүүст зориулагдсан бол энэ нь үргэлж тодорхой бүлэг хүмүүс байдаг: хүмүүс хэлийг бүтээгчид шиг ухаалаг байдаггүй. Ингэж л чи өөртэйгөө харьцах хэлтэй болдог. Кобол бол хамгийн тод жишээ боловч ихэнх хэлүүд энэ сүнсээр шингэсэн байдаг.

Хэлний өндөр түвшинтэй ямар ч хамаагүй. C нь нэлээд доогуур түвшин боловч үүнийг зохиогчид нь ашиглахын тулд бүтээсэн тул хакерууд үүнд дуртай байдаг.

Муу програмистуудад зориулсан хэл зохиох аргумент нь сайнаас илүү муу програмистууд олон байдаг. Магадгүй энэ нь тийм байх. Гэхдээ энэ цөөн тооны сайн програмистууд пропорциональ бусаар илүү олон программ хангамж бичдэг.

Миний асуулт бол шилдэг хакеруудын сэтгэлийг татахуйц хэлийг хэрхэн бүтээх вэ? Энэ асуулт нь сайн програмчлалын хэлийг хэрхэн бүтээх вэ гэсэн асуулттай яг адилхан юм шиг санагдаж байна, гэхдээ тийм биш байсан ч гэсэн энэ нь ядаж сонирхолтой асуулт юм.

3. Програмистад аль болох их хяналтыг өг

Олон хэл (ялангуяа бусад хүмүүст зориулагдсан) нь асрагч шиг ажилладаг: тэд танд ашиггүй гэж бодож байгаа зүйлээсээ сэрэмжлүүлэхийг хичээдэг. Би эсрэг байр суурьтай байна: програмистад аль болох их хяналтыг өг.

Би анх Лиспийг сурахад хамгийн их таалагдсан зүйл бол бид эн тэнцүүхэн ярьдаг байсан. Тэр үед миний сурсан бусад хэлүүдэд нэг хэл байсан, тэр хэл дээрх миний программ ч байсан, тэд тусдаа байсан. Гэхдээ Lisp дээр миний бичсэн функцууд болон макронууд нь тухайн хэлийг бичсэнтэй ижил байсан. Хэрэв би хүсвэл хэлийг өөрөө дахин бичиж болно. Энэ нь нээлттэй эхийн програм хангамжтай адил сонирхол татсан.

4. Товчхон бол авьяасын эгч юм

Товчхон байдлыг дутуу үнэлж, бүр дорд үздэг. Харин хакеруудын зүрх сэтгэлийг ажиглавал тэд товчхонд үнэхээр дуртай гэдгийг харах болно. Хакерууд, жишээ нь, APL-д хэдхэн мөр кодын тусламжтайгаар гайхалтай зүйлсийг хийж чадах тухай сайхан ярьж байхыг та хэдэн удаа сонссон бэ? Үнэхээр ухаалаг хүмүүс үүнд анхаарлаа хандуулах дуртай гэж бодож байна.

Хөтөлбөрийг богиносгосон бараг бүх зүйл сайн зүйл гэдэгт би итгэдэг. Номын сангийн олон функц байх ёстой, далд байж болох бүх зүйл ийм байх ёстой; синтакс илүү товч байх ёстой; аж ахуйн нэгжийн нэр хүртэл богино байх ёстой.

Зөвхөн хөтөлбөрүүд богино байх ёсгүй. Гарын авлага нь бас богино байх ёстой. Гарын авлагын сайн хэсэг нь тайлбар, татгалзал, сэрэмжлүүлэг, онцгой тохиолдлуудаар дүүрэн байдаг. Хэрэв та гарын авлагыг богиносгох шаардлагатай бол хамгийн сайн сонголт бол маш их тайлбар шаарддаг хэлийг засах явдал юм.

5. Хакердах гэж юу болохыг таних

Олон хүмүүс хакердах нь математик, ядаж шинжлэх ухаантай төстэй байхыг хүсдэг. Миний бодлоор хакердах нь архитектуртай адил юм. Архитектур гэдэг нь физикийн тухай бөгөөд архитектор нь нурж унахгүй барилгын зураг төслийг гаргах шаардлагатай байдаг ч архитектор хүний ​​жинхэнэ зорилго бол статикийн чиглэлээр нээлт хийх биш харин агуу барилга бүтээх явдал юм.

Хакеруудын дуртай зүйл бол гайхалтай програм бүтээх явдал юм. Тэр ажил нь шинжлэх ухааны нийтлэлийн ердийн оюуны мөнгөн тэмдэгт рүү амархан хөрвүүлэгдэхгүй ч гэсэн гайхалтай хөтөлбөр бичих нь гайхамшигтай зүйл гэдгийг бид ядаж өөрсдийн бодлоор санаж байх ёстой гэж би бодож байна. Оюуны үүднээс авч үзвэл, програмистуудад таалагдах хэлийг зохион бүтээх нь таны нийтлэлийг нийтэлж болох санааг агуулсан аймшигтай хэлийг зохион бүтээхтэй адил чухал юм.

Нээлттэй асуудлууд

1. Томоохон номын сангуудыг хэрхэн зохион байгуулах вэ?

Номын сангууд програмчлалын хэлний чухал хэсэг болж байна. Тэд маш том болж, аюултай байж болно. Хэрэв номын сангаас өөрт хэрэгтэй зүйлээ хийх функцийг олоход өөрөө бичихээс илүү хугацаа шаардагдах юм бол бүх код нь таны гарын авлагыг зузаан болгохоос өөр юу ч хийхгүй. (Симболын гарын авлагууд үүний нэг жишээ байсан.) Тиймээс бид номын сангийн зохион байгуулалтын асуудлыг шийдэх хэрэгтэй болно. Хамгийн тохиромжтой нь программист номын сангийн аль функц тохиромжтой болохыг тааж чадахаар тэдгээрийг зохион бүтээ.

2. Хүмүүс угтвар синтаксаас үнэхээр айдаг уу?

Хэдэн жил бодсон ч хариултыг нь мэдэхгүй байгаа гэдэг утгаараа нээлттэй асуудал. Математикт ашиглахаас бусад тохиолдолд угтвар синтакс нь надад байгалийн юм шиг санагддаг. Гэхдээ энэ нь Лиспийн олонд таалагдахгүй байгаагийн ихэнх нь үл мэдэгдэх синтакстай холбоотой байж болох юм... Бид энэ талаар ямар нэгэн зүйл хийх ёстой эсэх, хэрэв үнэн бол өөр асуудал юм.

3. Серверийн програм хангамжид юу хэрэгтэй вэ?

Программууд сервер дээр байрлаж, вэб хөтчөөр дамжуулан тантай харилцдаг гэсэн утгаараа ойрын хорин жилд бичигдэх ихэнх программууд вэб программ байх болно гэж би бодож байна. Ийм програм бичихийн тулд бидэнд шинэ зүйл хэрэгтэй.

Тэдгээрийн нэг нь серверийн програмуудыг гаргах шинэ аргыг дэмжих явдал юм. Ширээний програм хангамж гэх мэт жилд нэг юмуу хоёр том хувилбар гаргахын оронд серверийн программ хангамжийг хэд хэдэн жижиг өөрчлөлтөөр гаргах болно. Та өдөрт таваас арван хувилбар гаргаж магадгүй. Мөн хүн бүр хамгийн сүүлийн үеийн хувилбартай байх болно.

Та арчлахад хялбар байхын тулд программуудыг хэрхэн зохиохыг мэдэх үү? Серверийн програм хангамжийг өөрчлөх боломжтой байхаар зохион бүтээсэн байх ёстой. Та үүнийг амархан өөрчлөх чадвартай байх ёстой, эсвэл ядаж бага зэргийн өөрчлөлт нь юу гэсэн үг, юу чухал болохыг мэддэг байх ёстой.

Серверийн програм хангамжид хэрэгтэй байж болох өөр нэг зүйл бол гэнэтийн хүргэлтийн тасралтгүй байдал юм. Вэб программ дээр та иймэрхүү зүйлийг ашиглаж болно CPSвэб сессийн харьяалалгүй ертөнцөд ердийн журмын үр нөлөөг авах. Хэрэв функц нь хэтэрхий үнэтэй биш бол тасралтгүй нийлүүлэлттэй байх нь үнэ цэнэтэй юм.

4. Ямар шинэ хийсвэрлэлүүдийг нээх хэрэгтэй вэ?

Энэ найдвар хэр үндэслэлтэй болохыг би сайн мэдэхгүй байна, гэхдээ би хувьдаа шинэ хийсвэрлэлийг олж мэдэхийг үнэхээр хүсч байна - нэгдүгээр зэрэглэлийн функцууд эсвэл рекурсууд эсвэл ядаж анхдагч параметрүүд шиг утга учиртай байж болох зүйл. Магадгүй энэ бол боломжгүй мөрөөдөл юм. Ийм зүйлийг ихэнхдээ олж илрүүлдэггүй. Гэхдээ би итгэл найдвараа алддаггүй.

Бага зэрэг мэддэг нууцууд

1. Та хүссэн хэлээ ашиглаж болно

Өмнө нь програм үүсгэх нь ширээний програм хангамжийг бий болгох гэсэн үг юм. Мөн ширээний программ хангамжид үйлдлийн системтэй ижил хэлээр програм бичих тал дээр ихээхэн гажуудал байдаг. Тиймээс арван жилийн өмнө ерөнхийдөө программ хангамж бичнэ гэдэг нь Си хэл дээр программ хангамж бичих гэсэн үг юм. Эцэст нь уламжлал бий болсон: программыг ер бусын хэлээр бичиж болохгүй. Мөн энэ уламжлал маш удаан хөгжсөн тул менежерүүд, венчур капиталистууд гэх мэт техникийн бус хүмүүс ч үүнийг сурсан.

Серверийн програм хангамж нь энэ загварыг бүрэн устгадаг. Серверийн програм хангамжийн тусламжтайгаар та хүссэн хэлээ ашиглаж болно. Үүнийг бараг хэн ч ойлгохгүй байна (ялангуяа менежерүүд болон венчур капиталистууд). Гэхдээ зарим хакерууд үүнийг ойлгодог тул бид Perl, Python зэрэг инди хэлний талаар сонсдог. Perl болон Python-ийн талаар бид сонсдоггүй, учир нь хүмүүс Windows программ бичихдээ ашигладаг.

Энэ нь програмчлалын хэлний дизайн сонирхогч бидэнд юу гэсэн үг вэ гэвэл бидний ажилд боломжит үзэгчид бий.

2. Хурд нь профайлаас гардаг

Хэл хөгжүүлэгчид, эсвэл ядаж хэл хэрэгжүүлэгчид хурдан код үүсгэдэг хөрвүүлэгч бичих дуртай. Гэхдээ энэ нь хэлийг хэрэглэгчдэд хурдан болгодог зүйл биш гэж би бодож байна. Хурд хэдхэн саад бэрхшээлээс шалтгаална гэж Кнут эрт дээр үеэс тэмдэглэсэн байдаг. Хөтөлбөрийг хурдасгах гэж оролдсон хэн бүхэн хаана гацаа байгааг тааж чадахгүй гэдгийг мэддэг. Профайтер бол хариулт юм.

Хэл хөгжүүлэгчид буруу асуудлыг шийдэж байна. Хэрэглэгчид хурдан ажиллуулахын тулд жишиг шинжилгээ хийх шаардлагагүй. Тэдэнд програмынхаа аль хэсгийг дахин бичих шаардлагатайг харуулах хэл хэрэгтэй. Энэ үед практикт хурд хэрэгтэй. Тиймээс хэл хэрэгжүүлэгчид хөрвүүлэгчийг оновчтой болгоход зарцуулсан цагныхаа талыг зарцуулж, сайн профайл бичихэд зарцуулсан нь дээр байх.

3. Таны хэлийг хөгжүүлэх програм хэрэгтэй

Энэ нь эцсийн үнэн биш байж болох ч хамгийн сайн хэлүүд нь ашигласан програмынхаа хамт хөгжсөн бололтой. С-г системийн програмчлал хэрэгтэй хүмүүс бичсэн. Лисп нь зарим талаараа бэлгэдлийн ялгах зорилгоор бүтээгдсэн бөгөөд Маккарти эхлэхийг маш их хүсч байсан тул 1960 онд анхны Lisp цаасан дээр ялгах программ бичиж эхэлсэн.

Хэрэв таны програм зарим шинэ асуудлыг шийдэж байвал энэ нь ялангуяа сайн хэрэг юм. Энэ нь таны хэлийг програмистуудын хүссэн шинэ боломжуудтай болгоход түлхэц өгдөг. Би хувьдаа серверийн программуудад тохиромжтой хэл бичих сонирхолтой байна.

[Хэлэлцүүлгийн үеэр Гай Стил мөн энэ санааг хэлээд, хэрэв таны хэл эмхэтгэгч бичихэд зориулагдаагүй л бол програм нь таны хэлэнд зориулж хөрвүүлэгч бичихээс бүрдэх ёсгүй гэж нэмж хэлэв.]

4. Хэл нь нэг удаагийн программ бичихэд тохиромжтой байх ёстой.

Нэг удаагийн хөтөлбөр гэж юу болохыг та мэднэ: энэ нь танд хязгаарлагдмал асуудлыг хурдан шийдвэрлэх шаардлагатай үед тохиолддог. Хэрэв та эргэн тойрноо харвал нэг удаагийн хөтөлбөрөөр эхэлсэн олон ноцтой хөтөлбөрүүдийг олж харах болно гэдэгт би итгэж байна. Ихэнх хөтөлбөрүүд нэг удаагийн хөтөлбөрөөр эхэлсэн бол би гайхахгүй. Тиймээс, хэрэв та ерөнхийдөө програм хангамж бичихэд тохиромжтой хэлийг бий болгохыг хүсч байвал энэ нь нэг удаагийн програм бичихэд тохиромжтой байх ёстой, учир нь энэ нь олон програмын эхний шат юм.

5. Синтакс нь утга зүйтэй холбоотой

Синтакс, семантик хоёр тэс өөр зүйл гэж уламжлал ёсоор үздэг. Энэ нь цочирдом сонсогдож магадгүй ч тийм биш юм. Таны хөтөлбөрт хүрэхийг хүсч буй зүйл нь үүнийг хэрхэн илэрхийлж байгаатай холбоотой гэж би бодож байна.

Би саяхан Роберт Морристай ярилцсан бөгөөд тэрээр операторын хэт ачаалал нь infix синтакс бүхий хэлийг ялахад маш том давуу тал гэдгийг тэмдэглэв. Угтвар синтакс бүхий хэлнүүдэд таны тодорхойлсон аливаа функц нь үнэндээ оператор юм. Хэрэв та өөрийн үүсгэсэн шинэ төрлийн дугаар нэмэхийг хүсвэл түүнийг нэмэхийн тулд шинэ функцийг тодорхойлж болно. Хэрэв та үүнийг infix синтакстай хэлээр хийвэл хэт ачаалалтай оператор ашиглах, функцийг дуудах хоёрын хооронд маш том ялгаа байгааг харах болно.

Цаг хугацаа өнгөрөхөд буцаж ирдэг санаанууд

1. Шинэ програмчлалын хэлүүд

1970-аад оныг эргэн харахад шинэ програмчлалын хэлийг хөгжүүлэх нь моод болжээ. Одоо бол тийм биш. Гэхдээ серверийн программ хангамж нь шинэ хэл үүсгэх моодыг дахин авчирна гэдэгт би итгэж байна. Серверийн программ хангамжийн тусламжтайгаар та хүссэн хэлээ ашиглаж болно, тиймээс хэн нэгэн нь бусдаас илүү сайн хэлийг бий болговол үүнийг ашиглахаар шийдэх хүмүүс байх болно.

2. Цаг хуваалцах

Энэ санааг Ричард Келси гаргасан бөгөөд түүний цаг нь дахин ирсэн бөгөөд би үүнийг бүрэн дэмжиж байна. Миний таамаглаж байгаагаар (мөн Майкрософт ч гэсэн) олон тооны компьютерууд ширээний компьютерээс алсын сервер рүү шилжих болно. Өөрөөр хэлбэл, цаг хуваалцах нь эргээд ирсэн. Үүнд хэлний түвшинд дэмжлэг хэрэгтэй байх гэж бодож байна. Жишээлбэл, Ричард, Жонатан Ривз нар 48-р схемд үйл явцын хуваарийг хэрэгжүүлэхийн тулд маш их ажил хийсэн.

3. Үр ашиг

Саяхан компьютерууд аль хэдийн хангалттай хурдан болсон мэт санагдсан. Бид байт кодын тухай улам бүр сонсож байгаа бөгөөд энэ нь ядаж миний хувьд бидэнд тодорхой хэмжээний эрх мэдэл байгаа гэсэн үг. Гэхдээ серверийн програм хангамжийн хувьд бидэнд байхгүй гэж би бодож байна. Програм хангамжийг ажиллуулж байгаа серверүүдийн төлбөрийг хэн нэгэн төлөх ёстой бөгөөд нэг машинд сервер дэмжиж чадах хэрэглэгчдийн тоо нь тэдний хөрөнгийн зардлын хуваагч болно.

Наад зах нь тооцооллын хүндрэлд үр ашиг чухал байх болно гэж би бодож байна. Энэ нь ялангуяа серверийн программууд ийм үйлдлүүдийг маш ихээр гүйцэтгэдэг учир оролт/гаралтын ажиллагаанд чухал ач холбогдолтой.

Эцсийн эцэст байт код нь хариулт биш байж магадгүй юм. Sun, Microsoft хоёр яг одоо байт кодын талбарт толгойгоо гашилгаж байгаа бололтой. Гэхдээ байт код нь өөрөө сайн санаа учраас биш харин байт код нь процесст өөрийгөө оруулахад тохиромжтой газар учраас үүнийг хийдэг. Энэ бүх тулаан үл анзаарагдах болно. Энэ нь инээдтэй байх болно.

Урхи ба урхи

1. Үйлчлүүлэгчид

Энэ бол зүгээр л таамаг төдий боловч зөвхөн сервер талын програмууд л ашиг тусаа өгөх болно. Хүн бүр үйлчлүүлэгчтэй болно гэсэн таамаглалаар ажилладаг программ хангамжийг зохион бүтээх нь хүн бүр шударга байх болно гэсэн таамаглал дээр үндэслэн нийгмийг зохион бүтээхтэй адил юм. Энэ нь мэдээж тохиромжтой байх болно, гэхдээ энэ нь хэзээ ч болохгүй гэж бодох хэрэгтэй.

Вэб-дэвхжүүлсэн төхөөрөмжүүдийн тоо хурдацтай нэмэгдэх болно гэж би бодож байна, тэд үндсэн html болон маягтуудыг дэмжих болно гэж бид үзэж болно. Та утсан дээрээ хөтөчтэй юу? Таны PalmPilot утастай болох уу? Таны Blackberry илүү том дэлгэцтэй болох уу? Та тоглоомчингоороо интернетэд холбогдох боломжтой юу? Таны цагнаас? Би мэдэхгүй. Бүх зүйл сервер дээр байх болно гэж мөрийцсөн бол би үүнийг мэдэх шаардлагагүй болно. Бүх тархи сервер дээр байх нь илүү найдвартай. .

2. Объект хандалтат програмчлал

Энэ бол маргаантай мэдэгдэл гэдгийг би ойлгож байгаа ч OOP нь тийм ч чухал биш гэж би бодож байна. Энэ нь цонхны систем, симуляци, CAD систем гэх мэт тодорхой өгөгдлийн бүтэц шаардлагатай тодорхой програмуудад тохиромжтой парадигм гэж би бодож байна. Гэхдээ яагаад бүх хөтөлбөрт тохирсон байх ёстойг би ойлгохгүй байна.

Миний бодлоор том компаниудын хүмүүс OOP-д дуртай байдаг, учир нь энэ нь ажил мэт харагдах олон зүйлийг бий болгодог. Байгалийн жамаар бүхэл тоонуудын жагсаалт гэж дүрсэлж болох зүйлийг одоо бүх төрлийн шат, бужигнаан, бужигнаантай анги болгон төлөөлж болно.

OOP-ийн бас нэг сонирхол татахуйц онцлог нь аргууд нь танд нэгдүгээр зэрэглэлийн функцүүдийн зарим нөлөөг өгдөг. Гэхдээ энэ нь Lisp програмистуудын хувьд мэдээ биш юм. Жинхэнэ нэгдүгээр зэрэглэлийн функцтэй бол бүх зүйлийг анги, арга барилд оруулахын оронд тухайн даалгаварт тохирсон ямар ч байдлаар ашиглаж болно.

Хэлний дизайны хувьд энэ нь юу гэсэн үг вэ гэвэл та үүнд OOP-г хэт гүнзгий оруулах ёсгүй гэж би бодож байна. Магадгүй хариулт нь илүү ерөнхий, суурь зүйлсийг санал болгож, хүмүүст аливаа объектын системийг номын сан болгон зохион бүтээх боломжийг олгох явдал юм.

3. Хорооны зураг төсөл

Хэрэв таны хэлийг хороо зохион бүтээсэн бол та зөвхөн хүн бүрийн мэддэг шалтгаанаар биш, урхинд орсон байна. Хороонууд бөөгнөрөл, үл нийцэх хэлний загвар гаргах хандлагатай байдгийг бүгд мэднэ. Гэхдээ эрсдэлд ордоггүй нь хамгийн том аюул гэж би боддог. Нэг хүн хариуцаж байгаа бол хороо хэзээ ч зөвшөөрөхгүй эрсдэлийг үүрдэг.

Сайн хэл бүтээхийн тулд эрсдэл хийх шаардлагатай юу? Олон хүмүүс хэлний загвар нь уламжлалт мэргэн ухаанд ойр байх ёстой гэж сэжиглэж магадгүй юм. Тийм биш гэдэгт итгэлтэй байна. Хүмүүсийн хийдэг бүх зүйлд шагнал нь эрсдэлтэй пропорциональ байдаг. Тэгвэл яагаад хэлний дизайн өөр байх ёстой гэж?

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх