մատեան անկապութեան

Սի

2024-09-29-25231950 – 2024-09-29

աղբիւր

#սի #ծրագրաւորում #էկրանահան #ահաւոր

բնօրինակ ծմակուտում(եւ մեկնաբանութիւննե՞ր)
սի ծրագրաւորում էկրանահան ահաւոր
2024-04-01-22769797 – 2024-04-01

սա եմ կարդում՝ ադայի չաթում եմ գտել՝ https://gautiersblog.blogspot.com/2024/03/benchmarking-generic-image-decoder-gid.html?m=1

փայթընի կոդը արտագրել են ադայով՝ 500 անգամ արագացել ա։ սա իհարկէ էդքան ադայի արագագործութեան մասին չի, ինչքան փայթընի դանդաղ լինելու։

բայց մտքովս ի՞նչ անցաւ։ դէ ես կարող ա լինէի էն մարդը որ շատ ա սիրում փայթըն ու ամէնն դրանով ա անում։

ու երեւի իմ սերունդը կապ ունի՝ ինձնից չի էդքան, մեր ժամանակ պասկալն էր մոդա, իսկ երբ պասկալով իսկապէս գրում ես, ոչ թէ պոլիտէքի առաջադրանքները, այլ իսկապէս մի կիրառելի բան քեզ համար, իր մոդուլներն ու ուժեղ տիպաւորմանը նէնց ես կպնում որ յետոյ երկար չես հասկանում ոնց ա որ սի֊ում օրինակ մինչ էսօր տէնց չի։

ու էսօր համալսարաններում երբ սիից ու սի փլասից են սկսում, դրանից յետոյ փայթընը շատ լաւն ա թւում ու ուզում ես ամէնն իրանով անել։

ու դա լաւ ընտրութիւն չի՝ մարդիկ կան կպնում են սիին՝ ասում են էֆեկտիւ ա իրանով, մարդիկ էլ կան, զգում են դրա խնդիրները ու կպնում են փայթընին։

բայց էդ լաւ ընտրութիւն չի՝ սիի ու փայթընի մէջ։

#փայթըն #պիտոն #սի #ծրագրաւորում #կրթութիւն #տեք #տէք #ադա

բնօրինակ ծմակուտում(եւ մեկնաբանութիւննե՞ր)
փայթըն պիտոն սի ծրագրաւորում կրթութիւն տեք տէք ադա
2022-09-29-14438575 – 2022-09-29

դիեգօն օբերոնի չաթում պատմեց այս դէպքի մասին՝ քսան տարի չէին նկատում որ փակագիծը սխալ տեղ են դրել, ու իմաստը փոխուել ա։

նա նշեց որ սա հնարաւոր ա հէնց սի֊ում։ ու մեր ծրագրաւազմի զգալի մասը սի֊ով ա գռուած։ աւելի ժամանակակից լեզուով, ու իհարկէ օբերոնով նման սխալ հնարաւոր չի։

#օբերոն #սի #վրիպակ #տեք #ծրագրաւորում #էկրանահան

բնօրինակ ծմակուտում(եւ մեկնաբանութիւննե՞ր)
օբերոն սի վրիպակ տեք ծրագրաւորում էկրանահան
2021-04-18-2492083 – 2021-04-18

այսօր դաշնեզերքի օգնութեամբ բացայայտեցի cppcast պոդքաստը։ լսեցի վերջին էպիզոդը՝ այն մասնաւորապէս ̶բ̶ո̶ր̶լ̶ա̶ն̶դ̶ի̶ էմբարկադերօյի c++ builder֊ի մասին էր։

հետաքրքիր ա որ
- այլեւս չեն զարգացնում իրենց c++ կազմարկիչը, անցել են clang֊ի։
սա շատ կարեւոր թեմա ա ինձ համար, նշանակում ա c++֊ն այնքան արագ տեմպերով ա զարգանում, որ նոյնիսկ այդ, բաւական լուրջ, բաւական, թւում ա թէ, փող ունեցող ընկերութիւնը, չի հասցնում իր կազմարկիչը զարգացնել։

սա կարող էր ոգեւորիչ լինել․ ահա՛, ազատ ծրագրակազմը յաղթում ա, ոչ մի առանձին ընկերութիւն չի կարող հասնել, զի համայնքը զօրաւոր ա, եւ մարդկութիւնը իր ամբողջ ռեսուրսներով կարողանում ա աւելին անել, քան առանձին ընկերութիւնը։

ու մասամբ երեւի այդպէս ա։

մտահոգիչ մասն այն ա, որ լեզուն այնքան ա բարդացել, որ չի լինում առանձին ընկերութեան համար այն իրականացնելն այլեւս իրատեսական չի։ մօտաւորապէս նման պատմութիւն ա դիտարկիչների հետ՝ html֊ն ա այնքան բարդացել, որ առանձին ընկերութիւն այն իրականացնել չի կարող։

եւ մեր բախտից ա (դէ իրականում նախկինում տարուած պայքարից) որ գուգլն ու էփլը այսօր ազատ ծրագրակազմ են ֆինանսաւորում, ու կայ chromium֊ը, եւ llvm֊ն ա ազատ։

բայց եթէ մթնոլորթը փոխուի, մի պահ ա գալու, երբ chromium֊ի շարժիչը գուգլը կարող ա եւ փակել։ իսկ եղած ազատը համայնքը չի կարողանայ զարգացնել այնպէս որ արագ զարգացող ստանդարտներին հասնի։ այդ պատճառով էլ եմ ես ոգեւորւում աւելի պարզ համակարգերից, ինչպիսին են gemini֊ն, եւ oberon֊ը։

c լեզուն էլ ա բաւական պարզ (առանց ընդլայնումների) որ մի հոգի նստի եւ մի քանի ամսում իրականացնի կազմարկիչ։

շարունակեմ այն մասին, ինչ եմ յիշում զրոյցից։
- հին կոմպիլեատորը դեռ տարածւում ա builder֊ի հետ, բայց առանձնապէս չի օգտագործւում, եւ հաւանաբար այն դիստրիբուտիւից հանելու են։ այսօր builder֊ի թիմը մասնաւորապէս զբաղուած ա նրանով, որ ինտեգրում ա builder֊ին սպեցիֆիկ c++ լեզուի ընդլայնումները clang֊ի մէջ, իսկ clang֊ի ներքին ինտերֆէյսները փոխւում են, ու հետեւաբար դա շարունակական պրոցես ա։
ի՞նչ ընդլայնումներ են դրանք։

դէ դա ես գիտէի, ու կարելի ա պատկերացնել՝

c++ builder֊ը օգտագործում ա բորլանդի object pascal֊ով գրուած vcl (եւ արդէն fmx) գրադարանները։ իսկ գրադարանները նախատեսուած են gui ծրագրեր գրելու համար։ այդ պատճառով object pascal֊ն ունի properties՝ յատկութիւններ, որ կլասի դաշտեր են։ բայց երբ դու վերագրում ես յատկութեանը, իրականում տակից կանչւում ա setter մեթոդ, իսկ երբ կարդում ես դրանից, իրականում տակից կանչւում ա getter (fread) մեթոդ։ դրանք պէտք ա սահմանես, եթէ հատկութիւն ես աւելացնում։ յատկութիւններ նաեւ ունի բորլանդի c++ լեզուի դիալեկտը։

վարողը հարցրեց, արդե՞օք ընկերութիւնը փորձել ա լեզուի ընդլայնումներն աւելացնել c++ ստանդարտի մէջ։ ինչ֊որ գործ այդ առումով արուել ա, ու հիւրը մի քանի c++ կոմիտէի թղթերի յղուեց։ բայց վերջին թուղթը որին յղուել էր փաստարկներ էր անում ինչու յատկութիւններ լեզուի մէջ բերելը վատ միտք ա՝ զի կարող են ոչ տեղին օգտագործուել (misuse), երբ պէտք չի (իբր դա c++֊ի համար ամենակարեւոր խնդիրն ա՝ իբր c++֊ում արդէն չկան հնարաւորութիւններ որ կարող ա սխալ կամ ոչ տեղին օգտագործուեն), եւ այլ փաստարկն այն էր, որ թափանցիկ չի, մարդիկ կարող ա չիմանան, որ դաշտ չի այն, ինչը դաշտ ա երեւում։ սա շատ լաւ փաստարկ ա, բայց կրկին՝ c++֊ն արդէն ունի բազմաթիւ հնարաւորութիւններ որ սինտակտիկ շաքար են։ բայց ես ինքս նոյն կարծիքի են՝ ինձ դուր չեն գալիս յատկութիւններ, եթէ դրանք սովորական դաշտի տեսք ունեն, ու սինտաքսից պարզ չի, որ հատկութիւն են, եւ ոչ թէ սովորական դաշտ։

այլ ընդլայնումը վերաբերում էր, իհարկէ, event֊ներին՝ օրինակ, կտոցը կոճակին event ա, որ կապուած ա յատուկ ֆունկցիայի հետ։ այդ համար borland֊ը նախագծել էր closure կոչուող լեզուի յատկութիւն։ տես նաեւ սա։

ի դէպ քիւթը այլ ձեւերով ա լուծում նոյն խնդիրները, իրենք ունեն սիգնալ եւ սլոտ հասկացութիւններ, բայց ձեռք չեն տալիս c++ կազմարկիչը, փոխարէնը գրել են մի գործիք՝ moc, որը իրենց, քիւթին սպեցիֆիկ սիփլասփլասը թարգմանում ա ստանդարտ սիփլասփլասի։

abi֊ի հետ են շատ գործ անում, եւ pascal֊ական տիպերի հետ համատեղելի լինելու։ գիտենք, որ դելֆիի պասկալն ունի cow strings, իմացայ որ ունի նաեւ ինչ֊որ տարադրամի տիպ, ու այդ տիպերին, բնական ա, իրենց c++֊ն էլ պէտք ա սատարի։

դելֆիի պասկալի ֆունկցիայի քոլերն ունեն register կոչուող calling convention, այդ համար էլ ա գործ արւում։ abi֊ն ջանում են մի ստաբիլ վարկածի մէջ չփոխել, ու եթէ abi֊ի փոփոխութիւններ են նախատեսւում, ապա դրանք արւում են մէյջըր ռելիզների ժամանակ։ այդ փոփոխութիւնները ոչ միայն կարող են վերաբերուել հէնց ֆունկցիաներ կանչելու ձեւին, այլեւ նրան ինչպէս են տուեալները պահւում յիշողութեան մէջ։
- նշեց որ c++ builder֊ն այլեւս չունի android֊ի համար յաւելուածներ գրելու հնարաւորութիւն, բայց դեռ ունի ios֊ի համար գրելու հնարաւորութիւն։ անդրոիդի «բեքենդը» (որովհետեւ լոկ բեքենդ չէր, ահագին ենթակառուցքուածքներ էին) հանել են այն պատճառով, որ պահանջարկ չկար։ կրկին, անդրոիդ դեւելոփմենթ էլ ա այնքան բարդ, որ պարզւում ա, ձեռնատու չի մի քանի (գուցէ մի հոգի էին պահում որ գործն անի) հոգու փող տալ, զի այդ փողը չեն հանի։
ու գուցէ ios դեւելոփմենթն աւելի պարզ բան ա՝ կպնում ես objective c գրադարաններին, պէտք չի jni անել, պէտք չի լիքը այլ բան։ կամ գուցէ իսկապէս այօս դեւելոփմենթի պահանջարկ ունեն։

վախեցայ որ դելֆիից էլ են հանել անդրոիդի մասը, ստուգեցի, ու կայքում կարծես թէ գրուած ա որ ունեն անդրոիդ դեռ։ չգիտեմ։
- որոշ չափով խօսուեց delphi֊ի մասին, զի builder֊ի delphi֊ի հետ սերտ կապեր ունի։ օրինակ, կարող ա ընդլայնել պասկալով գրած կլաս։ դէ բնական ա, զի կարող ա ուզես մի կոնտրոլի հիման վրայ մի այլ կոնտրոլ սարքել։ պատմեց, որ delphi֊ն կարողանում ա գեներացնել հեադեր նիշքեր որ իրենց c++ կազմարկիչը կը ճանաչի։ որ շատ հանգիստ լինկ են լինում pascal եւ c++ ծրագրերը։ ու որ աւելի բարդ ա պասկալից կպնել սիփլասական գրադարաններին, քան հակառակը, զի սիփլասփլասը կոնստրուկտներ ունի, որ պասկալը չունի։ իսկ այն կոնստրուկտները որ իրենց պասկալից պէտք էին՝ իրենք արդէն աւելացրել են իրենց սիփլասփլաս կազմարկչի մէջ, ու հետեւաբար պասկալ կոդ շատ հեշտ ա օգտագործել։
- նշեց մի քանի նախագիծ, բայց առանց անունների, որ գրուել են սիփլասփլաս բիլդերով։ ու ես հասկացայ որն են իրենց մեծ պատուիրատուները, օրինակ կան ծրագրեր որ սպասարկում են էլեկտրակայաններ, ու քանի որ կոդն ի սկզբանէ գրուած ա եղել բորլանդի բիլդերով, այսօր էլ էմբարկադերօն պէտք ա, որ սպասարկի պրոդուկտ, որը կառնեն այդ էլեկտրակայանի ծրագրակազմ նախագծողները։
- ես կարծում եմ որ իրենց գնային քաղաքականութիւնը խանգարում ա իրենց զարգանալ։ եւ այդ պատճառով էլ վարողը հարցրեց, արդեօք կան օփեն սորս դեւերի համար անվճար վերսիաներ։ պատասխանը՝ այո, բայց մի վերսիա հետ ընկած ա, աշխատում ենք թարմացնել։
- ովքե՞ր են օգտագործում բիլդեր — հիմնականում ուինդոուս դեւելոփերներ։
ինձ թւում ա, դա բորլանդի, եւ յետոյ էմբարկադերօյի ամենամեծ խնդիրներից ա, որ չեն կարողացել հասցէագրել (այսպէս կարելի՞ ա ասել), չեն կարողացել այնպէս անել որ ոչ ուինդոուս ծրագրաւորողները հետաքրքրուեն նախագծով։ իհարկէ, շատ բարդ ա մրցել լինուքսի աշխարհում, ուր մարդիկ սովոր են ազատ լուծումների, ու սիփլափփլաս մարդիկ սովոր են քիւթին, եւ շատերն իրենց վճարում են։ բայց կարելի էր մրցել, կարելի էր լուրջ փորձեր անել շուկայ մտնելու։ ու բնաւ անիրատեսական չէր մակօսի շուկայ մտնել, կարծում եմ շատ շատերը կը նախընտրէին բիլդեր էքսկոդին, բայց բիլդերի (ինչպէս եւ դելֆիի) այդիին, նախագծման միջավայրը աշխատում ա միայն ուինդոուսում։ ինձ թւում ա դա ամենակարեւոր խնդիրներից ա որ իրենք չլուծեցին, զի մակօս դեւը չի ուզի ուինդոուսում գրել մակօս ծրագրեր։

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

#ծրագրաւորում #ծրագրաւորման_լեզուներ #պասկալ #սիփլասփլաս #սի #բիլդեր #բորլանդ #էմբարկադերօ #նախագծում #ծրագրակազմ #հարցազրոյց #պոդքաստ #տտ #տեք #գործիք #գործիքներ

բնօրինակ ծմակուտում(եւ մեկնաբանութիւննե՞ր)
C ծրագրաւորում ծրագրաւորման_լեզուներ պասկալ սիփլասփլաս սի բիլդեր բորլանդ էմբարկադերօ նախագծում ծրագրակազմ հարցազրոյց պոդքաստ տտ տեք գործիք գործիքներ
2020-09-02-4499474 – 2020-09-02

հաւէս յօդուած ա սա շատ՝ https://www.joelonsoftware.com/2001/12/11/back-to-basics/

իսկ օբերոնում վիրտը որոշել ա հրաժարուել պասկալական տողերից, ու կիրառել զրօյով աւարտուող տողեր։

սակայն, էդ տողերով կարիք չկայ միշտ վազել չափն իմանալու համար։ առանձին դաշտ էլ պէտք չի օգտագործել ու յիշողութեան մէջ մի տեղ պահել չափսը՝ քոմփայլերը գիտի տողի երկարութիւնը։

ու քոմփայլ թայմ թեստ կարող ա անել։ դիցուք վերցնենք էս ելատեքստը՝
```
MODULE tst;
IMPORT Out;

VAR i: SHORTINT;
str: ARRAY 1024 OF CHAR;

BEGIN

FOR i := 0 TO LEN(str) DO
Out.Int(i, 0); Out.Ln
END;

END tst.
```
այն քոմփայլ չի լինի՝
```
[2020-09-02 16:00:20] $ voc -m tst.Mod 
tst.Mod  Compiling tst.

9:   FOR i := 0 TO LEN(str) DO
^
pos   102  err 113  incompatible assignment

Module compilation failed.
[2020-09-02 16:00:21] $
```
voc֊ը որ դէպի C ա թարգմանում սորսը, շատ լաւ ա պատկերելու համար։ եթէ մենք ունենք՝
```
str: ARRAY 16 OF CHAR;
```
ապա ելքային C կոդը կը լինի՝
```
static CHAR tst_str[16];
```
միայն դա։

իսկ
```
FOR i := 0 TO LEN(str) DO
```
կը թարգմանուի որպէս՝
```
tst_i = 0;
while (tst_i <= 16) {
```
Երբ մենք գրում ենք տողի հետ աշխատող ֆունկցիա, մենք կարող ենք չիմանալ փոխանցուող տողի երկարութիւնը՝
```
MODULE tst2;

PROCEDURE addStrs(VAR a, b: ARRAY OF CHAR);
BEGIN
(* do smth useful here *)
END addStrs;

PROCEDURE test*;
VAR
s0: ARRAY 32 OF CHAR;
s1: ARRAY 64 OF CHAR;
BEGIN
addStrs(s0, s1);
END test;

END tst2.
```
եւ ապա սի կոդը կը լինի՝
```
static void tst2_addStrs (CHAR *a, ADDRESS a__len, CHAR *b, ADDRESS b__len)
{
/* here we think we can do smth useful */
}

void tst2_test (void)
{
CHAR s0[32];
CHAR s1[64];
tst2_addStrs((void*)s0, 32, (void*)s1, 64);
}
```
այսինքն՝ ֆունկցիան ստանում ա նաեւ տողի երկարութիւնը։ ու եթէ անել LEN(a) անմիջապէս՝ առանց ոչ մի հաշուարկ՝ ստանում ես տողի երկարութիւնը։

ապա ինչպէ՞ս են աշխատում դինամիկ տողերը։
```
MODULE tst3;

PROCEDURE addStrs(VAR a, b: ARRAY OF CHAR);
BEGIN
(* do smth useful here *)
END addStrs;

PROCEDURE test*(i: INTEGER);
VAR
s: ARRAY 32 OF CHAR;
ps: POINTER TO ARRAY OF CHAR;
BEGIN
NEW(ps, i);
addStrs(s, ps^);
END test;

END tst3.
```
ունենք մի հատ ստատիկ տող՝ s ու մի հատ դինամիկ տողի ցուցիչ՝ ps։ ps֊ի չափսը կը ստանանք որպէս ֆունկցիայի արգումենտ՝ էս պահին մեզ անյայտ ա։

առաջին ֆունկցիան մնում ա անփոփոխ, երկրորդը թարգմանւում ա սէնց՝
```
static void tst3_addStrs (CHAR *a, ADDRESS a__len, CHAR *b, ADDRESS b__len)
{
/* do smth useful here */
}

void tst3_test (INT16 i)
{
CHAR s[32];
struct {
ADDRESS len[1];
CHAR data[1];
} *ps = NIL;
ps = __NEWARR(NIL, 1, 1, 1, 1, ((ADDRESS)(i)));
tst3_addStrs((void*)s, 32, (void*)ps->data, ps->len[0]);
}
```
_NEWARR֊ն արդէն մի քիչ բարդ ֆունկցիա ա, որը ռանթայմի մաս ա։ բայց ընդհանուր առմամբ պարզ ա ինչ ա անում՝ հիփ֊ի մէջ ալոքէյթ ա անելու տող, եւ մեր ստացած ցուցիչն արդէն struct֊ի ա, որն ունի data դաշտ եւ len դաշտ։

սա ռանթայմ տեղեկատւութիւն ա, ու այս դէպքում արդէն մեզ պէտք ա պահել առանձին դաշտ տողի երկարութեան համար։

ու տէնց։

#օբերոն #ծրագրաւորում #տող #տողեր #պասկալ #սի #վիշապ #իրականացում #կազմարկում #կոմպիլյատոր #կոմպիլեատոր #կազմարկիչ

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
օբերոն ծրագրաւորում տող տողեր պասկալ սի վիշապ իրականացում կազմարկում կոմպիլյատոր կոմպիլեատոր կազմարկիչ
2018-11-11-3345806 – 2018-11-11

First things first: printf is expecting a valid (i.e. non-NULL) pointer for its %s argument so passing it a NULL is officially undefined. It may print “(null)” or it may delete all files on your hard drive–either is correct behavior as far as ANSI is concerned (at least, that’s what Harbison and Steele tells me.)

https://stackoverflow.com/questions/11589342/what-is-the-behavior-of-printing-null-with-printfs-s-specifier/11589443#11589443

#ծրագրաւորում #ահաւոր_ա #սի

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
11589443 ծրագրաւորում ահաւոր_ա սի
2017-02-24-2447349 – 2017-02-24

գրիր քո լիսպը՝ լաւ գիրք առցանց՝ http://www.buildyourownlisp.com/ #ծրագրաւորում #լիսպ #սի #կոմպիլյատոր #գիրք

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
ծրագրաւորում լիսպ սի կոմպիլյատոր գիրք
2015-12-14-1781240 – 2015-12-14

c եւ c++ պատմութիւն՝ https://vimeo.com/132192250

http://pastebin.com/UAQaWuWG

#ծրագրաւորում #կոմպիլյատոր #սի #ծրագրաւորման_լեզուներ #լեզու

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
ծրագրաւորում կոմպիլյատոր սի ծրագրաւորման_լեզուներ լեզու
2015-12-14-1781204 – 2015-12-14

սպանիչ պատմութիւն է, ինչպէս մարդը գրել է սի կոմպիլյատոր քառասուն օրուայ մէջ՝ http://www.sigbus.info/how-i-wrote-a-self-hosting-c-compiler-in-40-days.html

#ծրագրաւորում #կոմպիլյատոր #սի #ծրագրաւորման_լեզուներ #լեզու

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
ծրագրաւորում կոմպիլյատոր սի ծրագրաւորման_լեզուներ լեզու
2014-04-05-703522 – 2014-04-05

Արմեն Բադալեանի զրոյցները Սի լեզուի մասին՝ https://github.com/armenbadal/notes-on-c

#ծրագրաւորում #սի #զրոյցներ #տտ #գիրք #դասընթաց ###

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
ծրագրաւորում սի զրոյցներ տտ գիրք դասընթաց
ասք Մոդուլյար համակարգերի գաղտնիքների մասին – 2010-12-19

«Մոդուլային համակարգերի գաղտնիքները» հոդվածի հեղինակն է Սերգեյ Գուբանովը։

«Մոդուլ» եւ «մոդուլյար լեզու» թերմերի բացատրությունների զանազանությունը ծնում է ավներջ վեճեր։ Ինչեր ասես, որ մոդուլ չեն անվանել, ինչ լեզու ասես, որ մոդուլյար չեն համարել։ Ոմանք մոդուլ անվանում են կլասսները, ոմանք ել համեմատում են մոդուլները օբյեկտների հետ։ Առհասարակ այնպիսի տպավորություն է ստեղծվում, որ այժմ մոդուլյար եւ կոմպոնենտային լինելը նորաձեւ ոճ է։ Տարբերակների զանազանության պատճառը բացատրությունների ձեւի մեջ է՝ ներքին ձեւի։ Ներքին է այն իմաստով, որ սահմանումը տրվում է որոշ ներքին հատկությունների հիման վրա (մոդուլը պարունակում է տվյալներ, կոդ, տիպեր, ապահովում է ինկապսուլյացիան, ունի ինտերֆեյս, եւ այլն)։ Մոդուլների ներքին էական հատկությունները առանձնացնելու բազմաթիվ եղանակներ կան, իսկ դա նշանակում է, որ գոյություն ունեն նաեւ մոդուլների սահմանման բազմաթիվ եղանակներ։ Ապագայում ներքին հատկությունների քանակը գուցե եւ ավելանա, հայտնվեն սահմանումների նոր ձեւեր․ այսինքն՝ վիճելու առիթ ավելի շատ կլինի ու դա կտանի փակուղու։ Ելքը ներքին սահմանման փոխարինումն է արտաքինով։

Արտաքին է այն իմաստով, որ սկզբից պետք է նկարագրել ինչ է «մոդուլյար համակարգը», իսկ «մոդուլի» հասկացությունը կհայտնվի ինքնաբերաբար, ավտոմատ կերպով, քանի որ մոդուլը մոդուլյար համակարգի բաղադրիչն է։ Մոդուլյար համակարգը առաջնային է, մոդուլը՝ երկրորդային։ Մոդուլն ինքը իրանով չէ, այլ համակարգի մոդուլ է։ Մոդուլյար լեզու հարկավոր է անվանել այն լեզուն, որը մոդուլյար համակարգեր նախագծելու համար հարմարեցված, օպտիմիզացված է։ Այսպիսով՝ մոդուլյար ծրագրավորման լեզուների իմաստը մոդուլյար համակարգերի նախագծումն է։

Ստորեւ բացահայտենք մոդուլյար համակարգերի իմաստը:

Մոդուլյար ծրագրավորման համակարգերը եկել են միաձույլ ծրագրերը փոխարինելու համար։ Մոդուլյար համակարգեր կիրառելու իմաստը (ի տարբերություն միակուռ ծրագրերի) դինամիկ ընդարձակվելու ունակությունն է։ Մոդուլյար համակարգը կարելի է դինամիկ ընդլայնել մի քանի ձեւով։ Օրինակ՝ դրա մեջ նոր մոդուլներ ավելացնելով կամ փոխարինելով դրա միջի հին մոդուլները նորերով , որոնք ունեն ավելի լայն հնարավորություններ կամ որեւէ այլ լավացումներ։ Ընդարձակվող մոդուլյար համակարգը երբեք ավարտված չէ, այն զարգացում է ապրում։ Որոշ մոդուլներ փոխարինվում են, որոշները դինամիկ ավելացվում։ Այսպիսի համակարգի կյանքը կարող է լինել ավելի երկար, քան նրա միջի կոմպոնենտների կյանքը (տես․ մարդը եւ բջիջները, թարգմանչի նկատողություն)։ Համակարգի օգտագործողը ինքն է որոշում ինչպես այն ընդարձակել։ Կատարյալ դեպքում գոյություն ունի համակարգի կոմպոնենտների շուկա, որտեղ տարբեր արտադրողներ առաջարկում են մոդուլների իրենց իրագործումները, որոնք եւ ձեռք է բերում համակարգի օգտագործողը։ Կոմպոնենտների շուկայի բացակայությունը կարող է խոչընդոտել միաձույլ համակարգերից մոդուլյար համակարգեր անցնելուն։ Սակայն, պահանջարկը ծնում է առաջարկ։

Դիտարկենք մոդուլյար, դինամիկ ընդլայնվող համակարգի կառուցվածքը։ Մոդուլների միջեւ փոխազդեցությունը իրագործվում է մոդուլի՝ այլ մոդուլներ ներմուծելու (import) ունակության շնորհիվ։ Այսպիսով՝ ներմուծող մոդուլը հանդիսանում է ներմուծվող մոդուլների կլիենտ։ Մոդուլների ներմուծման գրաֆը միշտ ացիկլիկ է։ Գրաֆի ացիկլիկ լինելը կապված է այն հանգամանքի հետ, որ մոդուլները հանդիսանում են բեռնման, կատարման եւ բեռնաթափման միավորներ, իսկ ցիկլիկ կախվածության դեպքում բեռնման եւ կատարման միավոր կլիներ ամբողջ ցիկլը․ այսինքն՝ այն ամբողջությամբ կլիներ մոդուլ (համակարգի կոմպոնենտ)։ Մոդուլյար համակարգը ենթադրում է կատարման միջավայր, որի հիմնական խնդիրներից է մոդուլների դինամիկ բեռնումը, ուշ կապը (late linking), կատարումը եւ բեռնաթափումը։ Այլ խնդիրը ամբողջականության կոնտրոլն է․ տիպերի դինամիկ բերումը, զանգվածների (array) ինդեքսների դինամիկ ստուգումը եւ այլն։ Դինամիկ բեռնաթափման հնարավորությունը անհրաժեշտ է հին մոդուլները նորերով փոխարինելու համար։ Ի դեպ մոդուլը չի կարելի բեռնաթափել մինչեւ բեռնաթափված չեն բոլոր նրա կլիենտները։ Դա ակներեւ է թվում, սակայն այդ մասին հաճախ մոռանում են։ Մոդուլների բեռնումը եւ բեռնաթափումը կարելի է համեմատել աղյուսներից աշտարակ հավաքելու հետ․ աշտարակը կարելի է քանդել միմիայն վերեւից, այլ դեպքում այն կփլվի։ Ակներեւ է նաեւ այն, որ մոդուլը կարելի է բեռնաթափել միմիայն հստակ (explicit) հրամանով, այլ ոչ թե ավտոմատ կերպ (օրինակ՝հիմնվելով կլիենտների բացակայության փաստի վրա․ այժմ կլիենտներ չկան, իսկ որոշ ժամանակ անց կլինեն, եւ մոդուլի վիճակը պիտի պահպանվի)։ Նոր մոդուլի ավելացումը կամ հին մոդուլի փոփոխությունը չպետք է բերի ամբողջական համակարգը ավիրելուն։ Քանի որ մոդուլները կարող են մատակարարվել տարբեր արտադրողների կողմից, ապա կատարման միջավայրը պիտի ստուգի մոդուլների համատեղելիությունը եւ խոչընդոտի անհամատեղելի մոդուլների բեռնմանը։ Համատեղելիությունը ստուգվում է մոդուլի ինտերֆեյսի անալիզի միջոցով։ Մոդուլը պարունակում է իր մեջ զանազան ծրագրային էություններ` կոնստանտներ, տիպեր, փոփոխականներ, ֆունկցիաներ։ Մոդուլի որոշ էություններ հասանելի են դառնում կլիենտների համար, այսինքն` արտահանվում են (export), իսկ մնացածները թաքցվում, այլ խոսքերով՝ ինկապսուլյացիա անում։ Ի դեպ այդպիսի ինկապսուլյացիայի ձեւը ամենահզորն է, քանի որ այն խախտելու միակ միջոցը մոդուլի բինար կոդի հետազոտությունը եւ դրա ոչ անվտանգ փոփոխությունն է։ Մոդուլի արտահանվող էությունների ամբողջությունը սահմանում է մոդուլի ինտերֆեյսը։ Դրա միջոցով էլ իրականացվում է կլիենտների հետ փոխազդեցությունը։ Եթե երկու մոդուլ (նույնիսկ տարբեր արտադրողների մոդուլներ) ունեն նույն ինտերֆեյսը, ապա դրանք երկուստեք փոխարինելի են։ Եթե երկու մոդուլներից մեկը ունի առաջինի համեմատ ընդլայնված ինտերֆեյս (այսինքն՝ նրա ինտերֆեյսը ճշգրիտ կրկնում է առաջին մոդուլի ինտերֆեյսը եւ դրան գումարած արտահանում է հավելյալ էություններ), ապա երկրորդ մոդուլը փոխադարձորեն փոխարինելի է առաջինի հետ։

Ինչպե՞ս է կատարման միջավայրը որոշում մոդուլների համատեղելի լինելը։ Ամենապարզ ձեւն է՝ դրոշմել ամեն մոդուլը իր տարբերակի համարով (լինի դա հստակ նշված տարբերակ, թե վերջին կոմպիլյացիայի ժամանակը)։ Հին մոդուլյար համակարգերը օգտագործում էին ժամանակային նշումների մեխանիզմը (timestamps)։ Բայց տարբերակի հստակ (explicit) նշելը գերադասելի է, որովհետեւ ավելի ուշ timestamp-ը հայտնում է միայն այն, որ տվյալ մոդուլը ավելի ուշ է հավաքվել (compiled), բայց չի ակնարկում որ մոդուլի ինտերֆեյսը լուրջ փոփոխությունների է ենթարկվել։ Սակայն մոդուլը որոշակի համարով դրոշմելու լուծումը նույնպես թերի է։ Ենթադրենք, նոր մոդուլը հնից տարբերվում է միայն նրանով, որ նրա մեջ փոխված է ինտերֆեյսի բավականին փոքր մասը։ Օրինակ՝ փոխվել է մի արտահանվող կոնստանտի արժեքը, իսկ մնացած ամենը մնացել է անփոփոխ։ Ապա այդ մոդուլը պետք է դրոշմվի որպես նոր տարբերակ։ Սակայն գոյություն ունեն այնպիսի կլիենտ մոդուլներ, որոնք օգտագործում են միայն ինտերֆեյսի անփոփոխ մնացած մասը։ Նոր դրոշմի պատճառով այդ մոդուլի բոլոր կլիենտ մոդուլները կճանաչվեն անվավեր, այսինքն՝ կատարման միջավայրը կհրաժարվի բեռնել (աշխատեցնել) դրանք փոփոխված մոդուլի հետ համատեղ։ Մոդուլների համատեղելիության ստուգման մեխանիզմը երբեմն անհիմն անգութ է, եւ կատարման միջավայրը կարող է անվավեր համարել բազմաթիվ մոդուլներ։ Բարեբախտաբար, գոյություն ունեն մոդուլների համատեղելիությունը հաստատելու այլ, ավելի գրագետ ձեւեր։ Հավաստիանալու գաղտնիքը նրանում է, որ մոդուլի յուրաքանչյուր արտահանվող (exported) էությանը (յուրաքանչյուր կոնստանտի, փոփոխականի, տիպի, ֆունկցիաի) կցվում է ուրույն նշան, մատնահետք (fingerprint), ավելի պարզ՝ checksum, որը հաշվարկված է այդ էության որոշակի կառուցվածքային ինվարիանտ հատկությունները ի նկատի ունենալով։ Այսպիսի «մանտնահետք» դրոշմեր ստանալը հեշտ խնդիր չէ, առավել եւս ընդարձակվող համակարգերի դեպքում։ Ավելի քան տաս տարի առաջ ETH-ում մատնահետք դրոշմեր հաշվելու թեմայով դոկտորական թեզ է պաշտպանվել (Regis Crelier «Separate Compilation and Module Extension», գիտական ղեկավարներն էին Նիկլաուս Վիրտն (Wirth) ու Հանսպետեր Մոսենբոքը (Mossenbock), Oberon-2 լեզվի համահեղինակները)։ Կատարման միջավայրում մոդուլների համատեղելիության կոնտրոլի բացակայությունը կարող է բերել անկանխատեսելի հետեւանքների։ Այսպես, օրինակ, MS Windows համակարգի կատարման միջավայրը (ըստ էության պարզապես բեռնիչը), որի մեջ dll ֆայլերը հանդիսանում են մոդուլներ, չի ստուգում այդ մոդուլների համատեղելիությունը։ Որպես հետեւանք գոյություն ունի տխրահռչակ dll hell հասկացությունը։

Մոդուլյար համակարգեր ստեղծելը սկզբունքայնորեն հնարավոր է ցանկացած ծրագրավորման լեզվի օգնությամբ։ Օրինակ՝ win32 dll մոդուլյար համակարգը կարող է իրագործվել զանազան լեզուներով։ Սակայն դժվար թե լինի գոնե մեկ լեզու, որը այդ իսկ նպատակին հարմարեցված է նախագծման պահին։ Համեմատենք մեկ dll մոդուլի ստեղծման թեթեւությունը (որը որպես կանոն շատ հեշտ է, քանի որ բոլոր հոգսերը տանում է նախագծման միջավայրը) մի քանի, կամ տասնյակ/հարյուրավոր դինամիկ բեռնվող եւ բեռնաթափվող dll մոդուլներ պարունակող համակարգի ստեղծման բարդության հետ։ LoadLibrary եւ GetProcAddress կանչերի վիթխարի քանակը հարմարավետ չես անվանի եւ դրանք կիրառող տեքնոլոգիան, կամ լեզուն, ոչ մի կերպ չես անվանի մոդուլյար համակարգեր ստեղծելու համար հարմարեցված լեզու։ Ընդ որում ստատիկ կապումը (static linking) ելք համարել չի լինի, որովհետեւ բեռնաթափել եւ փոխարինել ստատիկ կապված մոդուլը անհնար է։ Ինչպես ասված էր, բնական է մոդուլյար ծրագրավորման լեզուները սահմանել որպես մոդուլյար համակարգեր ստեղծելու համար հարմարավետ, հատուկ նախագծված, նախատեսված լեզուներ, դա է իրենց իմաստը։ Բայց ինչպես մենք քիչ առաջ համոզվեցինք, մոդուլյար համակարգերը, առհասարակ, կարելի է կերտել նաեւ այդ համար հատուկ չնախատեսված լեզուների օգնությամբ։ Հարցը միմիայն աշխատանքի ծախսն է։ Կարող է պարադոքսալ թվալ, բայց լինում է եւ հակառակը․ կան ծրագրավորման լեզուներ, որոնք, կարծես, հարմարավետ են ոչ միայն միաձույլ, այլ նաեւ մոդուլյար համակարգեր ստեղծելու համար։ Ես ի նկատի ունեմ Delphi-ն։ Թվում է, որ այնպիսի սինտակտիկ միավորները, ինչպիսին են՝ unit, interface, implementation, uses, մոդուլյար համակարգեր ստեղծելու համար շատ օգտակար են․ մոդուլներ կհանդիսանային յունիթները, ավելի ճիշտ դրանց կոմպիլյացիայի արդյունքը՝ dcu ֆայլերը (delphi compiled unit)։ Բայց, ցավոք, dcu ֆայլերը մոդուլներ չեն, դրանք «կիսաֆաբրիկատներ» են։ Չնայած նրան, որ մոդուլների բոլոր արտաքին սինտակտիկ հատկանիշները առկա են, նրանց անհնար է մոդուլյար համարել․ ներկա ժամանակ աշխարհում գոյություն չունի մոդուլյար համակարգ, որի ստեղծման համար այն հատուկ հարմարեցվի։ Տեսականորեն, եթե երբեւէ ստեղծվի հատուկ կատարման միջավայր, որն ունակ կլինի դինամիկ բեռնել եւ բեռնաթափել dcu ֆայլերը, ապա այնժամ հնարավոր կլինի Delphi-ն անվանել մոդուլյար, այսինքն՝ հատուկ հարմարեցված մոդուլյար ծրագրավորման համար։ Այս տրամաբանությունը կարող է թվալ անսպասելի, բայց այն հետեւում է այս գրառման սկզբում սահմանված մոդուլյար համակարգերի իմաստից։ Մոդուլյարության հատուկ սինտակտիկ հատկանիշները անշուշտ անհրաժեշտ են, սակայն դրանք բավական չեն, այսինքն ոչ մի պարադոքս իրականում չի դիտվում։

Չնայած նրան, որ լեզվի միջի հատուկ շարահյուսական (սինտակտիկ) հատկանիշները բավական չեն լեզուն մոդուլյար անվանելու համար, դրանք միեւնույն է անհրաժեշտ են։ Անհրաժեշտ են նրա համար, որ լեզուն հարմարեցված լինի մոդուլյար համակարգեր գրելու համար։ Մոդուլյար ծրագրավորման լեզվի շարահյուսության մեջ պիտի արտահայտված լինեն ամենաքիչը երեք հասկացություն՝ ինքը մոդուլը, մոդուլների ներմուծմանվ(import) միջոցները եւ ծրագրային էությունների արտահանման (export) միջոցները։ Մոդուլյար համակարգի ամբողջականության վերահսկումը հնարավորինս վաղ իրականացնելու համար անհրաժեշտ է անջատ (separate), այլ ոչ թե անկախ (independent) կոմպիլյացիա։ Ակնհայտ է, որ մոդուլը պիտի լինի կոմպիլյացիայի միավոր։ Այլ դեպքում ինչու՞մ է կայանում հարմարավետությունը։ Մոդուլի ներքին էությունները իրար ամուր կապված են։ Եթե կոմպիլիացիայի միավոր լինի մոդուլից փոքր մեծություն, ապա անջատ կոմպիլիացիան հաշվի առնելով՝ անհրաժեշտ կլինի հնարել որոշակի թաքցրած ինտերֆեյսներ այդ էությունների փոխազդեցությունների համար։ Ակներեւ է, որ դա ավելորդ բարդացում է, գուցե նույնիսկ՝ անվտանգության ճեղք (vulnerability), եւ դրա օգուտը պարզ չէ։

Ընդհանուր առմամբ, մոդուլյար համակարգերի ծրագրավորումը չի պահանջում օբյեկտային կողմնորոշված ծրագրավորման (ՕԿԾ) մոտեցում, իրավացի է եւ հակառակը։ Սակայն, այդ երկու մոտեցումների համաժամյա կիրառությունը բերել է նոր ծրագրավորման պարադիգմայի ստեղծմանը։ Բանն այն է, որ ՕԿԾ-ն, իր ամենատարածված բացատրությամբ, հիմնված է ժառանգողականության (inheritance) հասկացության վրա։ ՕԿԾ-ն եւ մոդուլարությունը միատեղ կիրառելու ընթացքում ծնվում է միջմոդուլյար ժառանգողականությունը, սակայն այն հանդիսանում է տարբեր արտադրողների մոդուլների փոխարինելիության խոչընդոտ։ Եթե տիպի մասը սահմանված է մեկ մոդուլի մեջ, իսկ մյուս մասը՝ այլ, ապա հիմնական տիպի նկարագրությունը պարունակող մոդուլը այլ արտադրողից նույնանման մոդուլով փոխարինելը բավականին մեծ խնդիր է․ իրականացման հնարավոր մանր տարբերությունների պատճառով։ 1995 թվին, պրոֆեսոր Կլեմենս Շիպերսկին (Clemens Szyperski) ֆորմալիզացրել է Կոմպոնենտային Կողմնորոշված Ծրագրավորման (ԿԿԾ) հիմունքները սահմանափակելով եւ ՕԿԾ-ն եւ մոդուլյար մոտեցումը դրանց չհակասող համատեղ գոյության համար («Component-Oriented Programming A Refined Variation on Object-Oriented Programming», The Oberon Tribune, Vol 1, No 2, December 1995)։ ԿԿԾ-ի իմաստը ընդարձակելի համակարգերի կառուցումն է՝ մոդուլների եւ ՕԿԾ-ի օգնությամբ։ Այսպիսով, ԿԿԾ-ն, Շիպերսկու կարծիքով, գտնվում է «<ՕԿԾ-ից դուրս» (Beyond Object Oriented Programming - թարգմանչի նկատողություն) (այսպես է կոչվում նրա արդեն երկու անգամ հրատարակված բեսթսելերը)։ ԿԿԾ-ի հիմքը հանդիսանում են․ պոլիմորֆիզմը, ուշ կապումը (late linking), իսկական ինկապսուլյացիան, կատարման միջավայրի կողմից իրականացվող անվտանգութան ամբողջական վերահսկումը։ Կատարման միջավայրը նաեւ պարտավոր է աղբ հավաքել։ Աղբ հավաքելը շքեղություն չէ բնավ, այլ անհրաժեշտություն․ այն կոմպոնենտային համակարգի ամբողջականության երաշխիքներից մեկն է (հիշենք, որ համակարգի կոմպոնենտները՝ մոդուլները, ստեղծվում են, առհասարակ, տարբեր արտադրողների կողմից)։ Այժմ, ուշադրություն դարձրեք այն հանգամանքին, որ «ժառանգողականության» հասկացությունը (այսինքն տիպի ընդլայնումը), որը այնքան տարածված է ժամանակակից ՕԿԾ լեզուներում, առհասարակ չի ընդգրկված ԿԿԾ-ի հիմքերի մեջ։ Դրա բացատրությունը տրիվիալ է։ Եթե տիպերի ընդլայնումը կիրառվում է մոդուլների մեջ, ապա դա սովորական ՕԿԾ է՝ այնտեղ ուրույն կանոններ են։ Իսկ եթե օգտագործվում է տիպերի միջմոդուլյար ընդլայնումը, ապա այն մոդուլները, որոնց միջեւ տիպերը կապված են ժառանգողականողականության հարաբերություններով, կապված են լինում ավելի պինդ, ավելի կարծր կերպ։ Բարդ է փոխարինել բազային տիպ պարունակող մոդուլը այլ արտադրողի մոդուլով, առանց անվավեր անելու կլիենտ մոդուլները, որտեղ այդ տիպը ընդլայնված է։ ԿԿԾ-ն խորհուրդ է տալիս կիրառել միջմոդուլյար ժառանգողականություն միմիայն աբստրակտ տիպերից՝ դա նպատակահարմար փոխզիջում է ՕԿԾ-ի եւ մոդուլյար համակարգերի միջեւ։ Սակայն ծրագրավորողը, իհարկե, իրավացի է ինքը որոշել, արդյո՞ք արժե կոնկրետ համակարգում օգտագործել տիպերի միջմոդուլյար ժառանգողականությունը առանց սահմանափակումների (դրանով իսկ կարծր կապելով մոդուլները իրար), թե այնուամենայնիվ, նախընտրել փոխարինելի, ընդարձակվող մոդուլներ՝ տարբեր արտադրողներից։ ԿԿԾ-ի սահմաններում, «կոմպոնենտ» բառը դառնում է թերմ։ Կոմպոնենտային համակարգը դա մոդուլյար համակարգի այն մասնավոր դեպքն է, որի մեջ կիրառվում է ՕԿԾ։ Քանի որ այժմ ՕԿԾ-ն օգտագործվում է ամենուր, ապա «մոդուլյար համակարգ» կամ «կոմպոնենտային համակարգ» հասկացությունների տարբերությունը գրեթե բացակայում է։ Մյուս կողմից, կոմպոնենտ բառը այժմ չափազանց ծանրաբեռնված է տարբեր իմաստներով, այդ իսկ պատճառով կարելի է գտնել կոմպոնենտոների այլ բացատրություններ։ Քանի որ այժմ դա «նորաձեւ» է, յուրաքանչյուրը այն բացատրում է իր ձեւով։ Օրինակ՝ Delphi-ում կան ուրույն, այսպես կոչված, «կոմպոնենտներ», որոնք բնավ ոչ մի առնչություն չունեն մոդուլյար համակարգերի հետ։ Այս գրառումը ավարտելով դիտարկենք ինչպիսի կոմպոնենտային համակարգեր կան այսօր։ Microsoft ընկերությունը իրականացրել է կոմպոնենտ համակարգի իր մտապատկերը՝ .Net պլատֆորման եւ այդ պլատֆորմայի համար կանոնիկ՝ C# ծրագրավորման լեզուն։ Անկեղծ ասած, .Net համակարգը առհասարակ չի հանդիսանում դինամիկ ընլայնվող մոդուլյար համակարգ, քանի որ նրա մեջ պարզապես բացակայում է մոդուլներ բեռնաթափելու հնարավորությունը։ .Net համակարգերը ավելի շատ նման են մոնոտոն աճող միաձույլ ծրագրերի, մասնակի, հաջորդաբար կոմպիլյացիայով ու բեռնմամբ ըստ անհրաժեշտության։ Իրականում, այս ամենը ավելի բարդ է, որովհետեւ .Net-ում տարբերություն կա կոմպիլիացիայի միավորի (dll կամ exe մոդուլ) եւ բեռնման միավորի միջեւ (assembly)։ Assembly-ն մի քանի մոդուլի տրամաբանական միացումն է մեկ ենթահամակարգում։ Assembly-ների, dll-ների եւ exe մոդուլների մեջ չխառնվելու և առանց ընդհանրությունը կորցնելու պարզության համար ենթադրենք, որ assembly-ն բաղկացած է մեկ մոդուլից, եւ դրանց մեջ ոչ մի տարբերություն չկա։ Մեկ assembly-ի մեջ մի քանի մոդուլի դեպքը սկզբունքորեն ոչ մի բան չի փոխում (բացի բարդացում ավելացնելուց), այդ պատճառով կխոսենք միայն մոդուլների մասին։ Այսպիսով՝ .Net կատարման միջավայրը մոդուլների համատեղելիության վերահսկման համար չի օգտվում վերը նշված մատնահետքերի (fingerprint) մեխանիզմով։ Դրա փոխարեն կիրառվում է մոդուլի տարբերակի համարը հստակ նշելու տեխնիկան։ Դա, իհարկե, ավելի լավ է, քան ոչինչը (ինչպես win32 dll դեպքում), բայց ստեղծում է իր խնդիրները։ Օրինակ՝ եթե .Net մոդուլը արտահանում է կոնստանտ, որը, միգուցե, ոչ ոք չի օգտագործում, ապա, այդ մոդուլի ինտերֆեյսը, այսինքն՝ կոնստանտի արժեքը փոխելով, պետք է փոխել նաեւ մոդուլի տարբերակի համարը՝ այսպիսով անվավեր հանելով բոլոր կլիենտ մոդուլները, նույնիսկ նրանք, որոնք այդ կոնստանտը չեն օգտագործել։ Սա արդեն «dll hell»-ի ճիշտ հակապատկերն է։ Եթե սովորական win32 dll բեռնիչը բոլոր մոդուլները համարում էր համատեղելի, ապա .Net-ի դեպքում բեռնիչը անհամատեղելի է համարում չափազանց շատ մոդուլներ․ ինտերֆեյսում նույնիսկ չնչին փոփոխություն կատարելիս անհրաժեշտ է փոխել ամբողջ մոդուլի տարբերակի համարը։ C# լեզվի մեջ, որը, թվում է թե իր տրամաբանությամբ պիտի հարմարեցված լիներ մոդուլյար համակարգերի ծրագրավորման համար, բացակայում է մոդուլի հասկացությունը շարահյուսական մակարդակի վրա․ ուրեմն, մոդուլի ներմուծման հասկացությունը նույնպես բացակայում է։ C# լեզվով գրված մոդուլի տեքստը կարդալիս անհնար է իմանալ․ ա) ինչպիսի մոդուլներ է այն ներմուծում։ բ) որ մոդուլի մեջ է սահմանված տեքստում օգտագործված այս կամ այն իդենտիֆիկատորը։ Կիրառվող namespace մեխանիզմը կապված չէ մոդուլների անունների հետ։ C#-ը «հին նմուշի» լեզու է, որը հարմար է միաձույլ ծրագրեր ծրագրավորելու համար, ու հարմարեցված չէ մոդուլյար համակարգեր ստեղծելու համար։ Գուցե արդար չէ այդքան խիստ լինել C#-ի հետ, քանի որ .Net-ը ավելի նման է քայլ առ քայլ աճող միակուռ համակարգի, քան դինամիկ ընդարձակվող մոդուլյար համակարգի։ Մեծ պրոեկտներ հարմարավետ ծրագրավորելու համար առաջարկվում է օգտվել ոչ թե լեզվի հնարավորություններից, այլ նախագծման միջավայրի գործիքներից։ Գոյություն ունեն կոմպոնենտային համակարգեր, ու կոմպոնենտային ծրագրավորման լեզուներ, որոնք գրեթե զուրկ են թերություններից։ Դա կարող է զարմանք առաջացնել, սակայն առաջին մոդուլյար համակարգերը հայտնվել են դեռ անցյալ դարի 70-ականների ավարտին։ Օրինակ՝ դա Lilith համակարգչի համար ստեղծված օպերացիոն համակարգն է, որը գրված է պրոֆեսոր Նիկլաուս Վիրտի (Niklaus Wirth) Modula-2 լեզվով։ Այնուհետեւ, նա ու Յուրգ Գութկնեխտը (Jurg Gutknecht) ստեղծել են Oberon օպերացիոն համակարգը նույն անվանմամբ՝ Oberon լեզվի օգնությամբ, որը արդեն կարելի է համարել կոմպոնենտային, չնայած այդ համակարգը ստեղծելու աշխատանքը սկսվել է դեռ 1985 թվին՝ կոմպոնենտային ծրագրավորման հիմունքները հռչակելուց 10 տարի առաջ։ Մեր օրերում, օրինակ, Windows-ի համար գոյություն ունի անվճար (եւ ազատ արտոնագրով - թարգմանչի նկատողություն) տարածվող, 1994թ ստեղծված շվեյցարական AG Oberon Microsystems, Inc արտադրության BlackBox Component Builder կոմպոնենտային միջավայրը։ Նիկլաուս Վիրտը տնօրենների խորհրդի կազմի մեջ է, իսկ հիմնադիրներից մեկը ԿԿԾ «գաղափարային հայր», պրոֆեսոր Կլեմենս Շիպերսկին է։ Ճիշտ է այժմ նա աշխատում է որպես software architect Microsoft Research-ում։ Ամենասկզբից BlackBox համակարգը անվանվում էր Oberon/F եւ նախագծվում էր Oberon-2 լեզվով MacOS եւ Windows համակարգերի համար։ Այնուհետեւ Oberon-2 լեզուն փոփոխված էր ԿԿԾ նորաձեւ գաղափարի համաձայն։ Նոր լեզուն ստացավ Կոմպոնենտ Պասկալ (Component Pascal) անունը (1997)․ դա Oberon-2-ի արդյունաբերական տարբերակն է։ 2004 թվին BlackBox-ը հայտարարվել է անվճար, (իսկ ծրագրի կոդը՝ ազատ - թարգմանչի նկատողություն)։ Կամավորները ստեղծում են BlackBox-ի տարբերակ Linux (GNU/Linux - թարգմանչի նկատողություն) համակարգի համար (արդեն կա ալֆա տարբերակը)։ Իսկ Oberon Microsystems-ը ներկա ժամանակ աշխատում է համակարգի նոր տարբերակի վրա։ BlackBox-ով ստեղծված է Ամազոն գետի վրա գտնվող աշխարհի ամենամեծ հիդրոէլեկտրոկայանի հսկման համակարգը։ Դրա համար ստեղծվել էր BlackBox-ի հատուկ տարբերակ 64 բիտանի Unix-ի համար։ Borland ընկերության պատվերով Oberon Microsystems ընկերությունը գրել է Java-ի JIT կոմպիլյատոր։ Բացի դրանից, Oberon Microsystems-ում Կոմպոնենտ Պասկալով գրված է Portos իրական ժամանակի օպերացիոն համակարգը (չշփոթել PortOs-ի հետ, որը լրիվ այլ համակարգ է)։ Այնուհետեւ Portos-ը վերանվանվեց JBed, իսկ Oberon Microsystems-ից առանձնացվեց Esmertec ընկերությունը։ JBed-ը ավելի շատ հայտնի է որպես իրական ժամանակի օպերացիոն համակարգ embedded սարքերի համար, որը գրված է java-ով։ Ի նկատի ունենալով Java-ի լայն տարածումը եւ Component Pascal-ի թույլ ճանաչվածությունը՝ պետք է խոստովանել, որ դա հաջող մարկետինգային քայլ է։ Ռուսաստանում վերջերս հայտնվել է ընկերություն, որը հայտարարել է որպես հիմնական արտադրամիջոց BlackBox Component Builder համակարգը օգտագործոլու մասին։ Գոյություն ունի «Ինֆորմատիկա 21» միջազգային պրոեկտ, որի նպատակներից մեկն է BlackBox համակարգի առաջխաղացումը դպրոցներ, բարոյապես հնացած Turbo Pascal-ի փոխարեն։ Եթե փորձել պատասխանել այն հարցին, թե որն է ավելի լավը՝ BlackBox-ը թե Java-ն, ապա պետք է հաշվի առնել, որ բարդությունը թերություն է, իսկ .Net-ն եւ Java-ն անհամեմատ ավելի բարդ են։ Իսկ բացի BlackBox-ից գոյույթուն ունեն մի շարք հետազոտական մոդուլյար համակարգեր։ Ուզում եմ շեշտել Aos BlueBottle օպերացիոն համակարգը (այժմ A2, թարգմանչի նկատողություն) որը անմիջապես «երկաթի» վրա ապրող ակտիվ օբյեկտների հիման վրա ստեղծված առաջին եւ միակ համակարգն է։ Այն ամբողջությամբ գրված է Active Oberon լեզվով։ Համակարգի կատարման միջավայրը իրականացված է անմիջապես «երկաթի» վրա։ Սակայն, դա արդեն այլ պատմություն է։ բնորինակը

ու տենց
դոթնեթ ծրագրավորման լեզուներ ծրագրաւորում կոմպոնենտային ծրագրավորում մոդուլա մոդուլներ Ջավա Սի վիրտ տեքնոլոգիաներ տեղեկատուական տեքնոլոգիաներ օբերոն օպերացիոն համակարգեր

erzahlung uber debuggen – 2010-11-18

Սա երրորդ մասն ա։

Ասենք սա ինձ թաչ ա անում՝



<blockquote style="border: 2px solid rgb(127, 195, 59); padding: 10pt; margin-left: 30pt; background-color: #a6df6d;">
  <p>
    try not to do things you don&#8217;t understand<br /> and if you are forced to do things you don&#8217;t understand, then at least, do not speak about things you don&#8217;t understand
  </p>

und so weiter

դեբագ ծրագրավորման լեզուներ ծրագրաւորում Սի վիրտ տեղեկատուական տեքնոլոգիաներ օբերոն

ասք տարբեր բաների մասին – 2010-10-20



[այստեղից][1]

ու հա, ՆՅ-ում ավելի լավ զբաղմունք չեմ գտնում քան բլոգեր կարդալ:
  
ֆոտոներ մի սպասեք, նենց ա որ ոգեւորված չեմ

ինչքան տարբեր տեղերում լինում եմ այնքան համոզվում եմ, որ իմ համար ավելի լավ տեղ չկա քան Երեւանը:

 _ու տենց_

 [1]: http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

Լինուս ծրագրավորման լեզուներ ծրագրաւորում Սի

ասք դոթնեթի անցնելու մասին – 2010-08-09

Մի ընկերություն կար, որը դեռ ութանասունականներից գրված լիքը սի/սիպլյս գրված լիքը սերվերային կոդ ուներ։ Ու կորպորածիվ նորաձևության ժամանակակից քահմհարումներից ելնելով որոշում է լրից դոթնեթով արտագրել։

Արտագրում արտագրում են, լիքը ռեսուրս են ծախսում։

Ու թողնում

Տեստերը ցույց տվեցին որ արագագործությունը անթույլատրելի նվազել է։

Ու ոչ մի ջասթ ին թայմ քոմփայլեր չի օգնել։

փաստորեն։

ու տենց
դոթնեթ միգրացիա ու տենց Սի
ասք ստանդարտներին հետևելու մասին – 2010-08-09

Ստանդարնտները լավ բան են։ Ինչ որ ստանդարտ պետք ա լինում։ Նույնիսկ ասենք շփման մեջ, միմյանց հասկանալու համար։ Կամ թերմերի մեջ, կրկին՝ հասկանալու համար։

Սակայն, երբ ստեղծում եք նորը ստանդարտին հետևելը, կամ համապատասխանելը հաճախ բերում է վատ որոշումներին, ու վատ դիզայնին։

Ասենք, երբ Ստրաուստրուպը C++ նախագծելուց փորձում էր պահպանել C-ի հետ համատեղելիությունը, դա բերեց ինչպես տգեղ լուծումների, այնպես էլ լեզվի չաղացմանը։

Ուինդոուս/Սոլարիս-ներում – պահպանել նախկին տարբերակների հետ համատեղելիությունը որոշումը բերեց գրադարանների չաղացմանը։

Ի տարբերություն, Վիրտը, նախագծելով Մոդուլան որոշեց չպահպանել պասկալի հետ համատեղելիությունը։ Փոխարենը, նա գրեց քոնվերթեր, պասկալից մոդուլա տրանսլացիա անելու համար։ Նույնպես նա վարվում էր և հետագայում, Մոդուլայից Օբերոն քոնվերթեր գրելով, քանի որ հասկանում էր՝ համատեղելիությունը պահպանելը կբերի տգեղ դիզայնի։

Բաց ԾԱ-ի աշխարհում համատեղելիություն պահպանելը իմաստ չունի։

Փոխվեց գրադարանը՝ փոխվում է ծրագիրը որը այն օգտագործում է։ Եթե ծրագրի հեղինակը հետաքրքրված չէ, դա անում է մեյնթեյները կամ յուրաքանչյուր մեկը ում այդ ծրագիրը պետք է։ Այսպիսով, բաց ԾԱ-ն չունենալով համատեղելիության շերտ՝ ավելի նիհար է։

Ինչպես ես արդեն գրել եմ, կարգինը՝ արտակարգ լինել չի կարող։

Այս պատճառով Պլան9-ը և Ինֆերնոն, որոնց դիզայնի մեջ, ի դեպ, անկերես է Օբերոնի ազդեցությունը, չեին կարող հետևել սովորական Յունիքս/Պոսիքս ստանդարտների։

Ու պարզ է որ նրանք լայն չեն կիրառվում այն պատճառով, որ ծրագրերի մեծ մասը գրված է տեքնոլոգիաներով, որոնք անհամատեղելի են Ինֆերնոի հետ։ Օրինակ, C-ով կոդ այնտեղ ափլիքեյշն լեվել չի օգտագործվում, դրա համար կա Լիմբո։

Սակայն, նոր դիզայն կարող է իրեն թույլ տալ կորմորացիա որը նախագծում է ու տարածում նոր համակարգ։

Ես Անդրոիդ-ի մասին եմ։

Գուգլը լինուքս միջուկի հիման վրա ստեղծել է «նոր» համակարգ, ձեռք է բերել նոր ջավա վիրտուալ մեքենա։

Դրայվերների խնդիր մոբայլ սարքերի համար չկա՝ միևնույն է լիքը նոր դրայվեր գրվել է։

Լինուքսից օգտագործվել է սքեդուլերը, թիսիփի սթեքը, և այլն։ Սի-ով ափլիքեյշն կոդ գրելն նախատեսված չեր։

Այսինքն, կարելի էր անել համակարգ, որտեղ կան դիզայնի նոր ընտրություններ, ինչպես ընդհանուր հասցեական տարածությունը։ Բայց էդպիսի բան արված չէ։ Ընդ որում Լինուքս միջուկի քաստոմիզացիայի վրա այնքան ռեսուրս է ծախսվել, որ այդ ուժերը անհրաժեշտ էր ծախսել Ինֆերնոն փրոդաքշն և մոբայլ սարքեր բերելով։

Որովհետև նոր է, արագագործ, ու գեղեցիկ։

ու տենց
անդրոիդ ԳՆՈՒ/Լինուքս ինֆերնո ծրագրավորման լեզուներ կարգին եւ արտակարգ մոբայլ նախագիծ պլան9 Սի օբերոն օպերացիոն համակարգեր

ասք հռոմեական թվերի մասին – 2010-08-07



[այստեղից][1]
  
Ռոբ Փայքի, որը այժմ Գոու-ի ֆյուրերն ա ամենահայտնի խոսքերից։

Ինձ շատ ուրախացրեց [այս փոսթը][2]․

<blockquote style="border: 2px solid rgb(127, 195, 59); padding: 10pt; margin-left: 30pt; background-color: #a6df6d;">
  <p>
    > Java is done right in concept.
  </p>
  
  <p>
    wtf?
  </p>
  
  <p>
    [ Let me start by saying I don&#8217;t speak for any of these guys,<br /> I can&#8217;t even get their OS to run a GUI.]
  </p>
  
  <p>
    Java is better than C++, but as others have mentioned that&#8217;s like saying<br /> toothache is better than herpes.
  </p>
  
  <p>
    It&#8217;s just C without pointer arithmetic. Leaving aside actual<br /> implementation bugs, it :
  </p>
  
  <p>
    * runs on less platforms than any other language I&#8217;ve ever used,<br /> * wimped out of having numeric types implemented as objects, then<br /> bolted on &#8216;containers&#8217; for them in 1.1<br /> *has changed its GUI twice and *still* doesn&#8217;t do it right,<br /> * it&#8217;s thread model is essential to its operation but differs widely<br /> between VMs even on the same platform<br /> * the same it true for its garbage collector.<br /> * The APIs are huge and inconsistent.<br /> * it *finally* &#8211; in 1.4 &#8211; has a regex API (which is unusably complex).<br /> * it&#8217;s native code bindings are absolutely the worst I&#8217;ve ever seen,<br /> even Perl does a better job
  </p>
  
  <p>
    And don&#8217;t forget m5 current personal favourite &#8211;<br /> its pointlessly restrictive type system.
  </p>
  
  <p>
    Type is stored in the *pointer*, not the object.<br /> So I have to hold the VMs hand each time I pass an argument.<br /> I&#8217;m not allowed to reuse a variable to<br /> point to an List and a Vector, even if I&#8217;m going to call a method<br /> with the same name on both.
  </p>
  
  <p>
    And then to really piss in my chips, 90% of the Collections API<br /> which lets me store these objects and actually *do* something with them<br /> only lets me pull them out as Object.
  </p>
  
  <p>
    I HAVE TO CAST THEM. So when I get an object &#8216;dynamically&#8217; &#8211; via RMI or<br /> out of a Vector or whatever, I have to know what it is in advance.<br /> The poor frigging object doesn&#8217;t know (no, don&#8217;t get me started on the<br /> abomination that is the reflection API, people are already starting to<br /> stare).
  </p>
  
  <p>
    And this is a dynamic language. KERR-RIST.
  </p>
  
  <p>
    None of this matters of course, because &#8220;it&#8217;s better than C++&#8221;.<br /> And IT managers think the Sun shines out of its ass.
  </p>
  
  <p>
    Java is the f*cking COBOL of the 90s and<br /> future generations of geeks are going to fly back from Mars to piss on<br /> our graves for inflicting it on them.
  </p>
  
  <p>
    > Unfortunately. I can do system programming and command-line<br /> > apps with Java.
  </p>
  
  <p>
    Sure. If you don&#8217;t mind a fifteen second delay while the VM drags itself<br /> up from the bottom of the sea each time you run a command line app.
  </p>
  
  <p>
    Or should that &#8216;.&#8217; be a &#8216;,&#8217; ?
  </p>

ու տենց

գոու ծրագրավորման լեզու ինֆերնո լիմբո ծրագրավորման լեզուներ ծրագրաւորում հետազօտութիւն պլան9 Ջավա Սի տեքնոլոգիաներ տեղեկատուական տեքնոլոգիաներ

ասք Լինուսի վերաբերմունքի մասին – 2010-07-26

http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

ու տենց
գիթ Լինուս ծրագրավորման լեզուներ Սի տեղեկատուական տեքնոլոգիաներ

ասք իմ հետ համաձայն լինելու մասին – 2010-07-26



[այստեղից][1]
  
[լրիվ տեքստը][2]

ինչի՞ ա տենց հայտարարում։ անկապ չեր ասի, երևի ուզում են [Գոու][3]-ն տարածել։

<blockquote style="border-left: 2px solid #FFCC00; padding: 10pt; margin-left: 30pt; background-color: #FFFCEC;">
  <p>
    &#8220;Go is an attempt to combine the safety and performance of statically typed languages with the convenience and fun of dynamically typed interpretative languages,&#8221; he said, before adding, &#8220;to the extent that it succeeds you&#8217;ll have to judge for yourself.&#8221;
  </p>

փաստորեն։

Սա էլ Պայքի 2000 թվի թուղթ ա։ Հետաքրքիր ա։

_ու տենց_

գուգլ ծրագրավորման լեզուներ ծրագրաւորում Ջավա Սի տեղեկատուական տեքնոլոգիաներ

ասք ձիետային նստացնելու մասին – 2010-06-02

[փաստորեն][1], թիմը թույլատրեց c++ կիրառությունը gcc կոդի մեջ։

Սակայն,



որոշված է կիրառել որոշակի անորոշ (դեռ) լեզվի ենթաբազմություն։
  
Հարց է առաջանում՝ ո՞վ է հետևելու որ կոդը գայդլայններին համապատասխանի։
  
Ամենալավ լուծումը՝ ավտոմոտացումն է։ Եթե ավտոմատացնել, ապա դա նույնն է ինչ
  
սահմանել մի ենթաբազմություն ու իրա անունը դնել ասենք c++&#8211; կամ &#8211;c++, ++c&#8211;
  
կամ +-c-+
  
Ու էդպիսի ստանդարտ անել դրանով իսկ լուծելով չաղության հարցը։
  
C-ի դեպքում՝ SafeC-ն նմանատիպ օրինակն է։
  
Ադաի դեպքում դա արվել է SPARK լեզվի միջոցով։
  
Այսպիսով, լեզուն ֆսյո-տակի մի տեսակ ակնկարկում ա որ նիհարել ա ուզում։
  
 _ու տենց _

 [1]: http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html

Ադա ջիսիսի Սի

ասք չգրագետ աշխատելու մասին – 2010-05-19

էս քոդվիժն սի քմփայլերը ինչ ախմախ բան դուրս եկավ։

նեսթդ քոմենթը ինչ էր որ չկարողացան անել։ էդ որպես մասնագետ եմ ասում, երեք տող բան էր ավելանալու որ կարողանա պարս անել։

ու տենց
աթմեգա ծրագրային ապահովում կոմպիլյատորներ ներդրված համակարգեր Սի տեքնոլոգիաներ տեղեկատուական տեքնոլոգիաներ
պատմություն սրճի հոտի մասին – 2010-02-27
```
 [այստեղից ][1]

 _ու տենց _

 [1]: http://www.stlport.org/resources/StepanovUSA.html
```
ծրագրավորման լեզուներ ծրագրաւորում Ջավա Սի տեքնոլոգիաներ տեղեկատուական տեքնոլոգիաներ

պատմություն դիզայնի մասին – 2010-02-10



[այստեղից][1]
  
 _ու տենց _

 [1]: http://groups.google.am/group/comp.lang.oberon/browse_thread/thread/ffe11b45037375e0/e8b65d37114d4931?hl=hy&ie=UTF-8&oe=utf-8&q=andreas+borchert+c+interfaces#e8b65d37114d4931

լիբսի ծրագրային ապահովում ծրագրաւորում Սի տեղեկատուական տեքնոլոգիաներ օբերոն

что это? – 2008-10-25

if (a=b) {

……….

}

Нет, не сравнение! Присваивание! И вот эту ошибку не могли заметить в течение двух недель, в одной фирме, где я работал 🙂

Потому, что немудрено ошибиться, и поставить на один знак равенства меньше.

Конечно, можно сказать, что нормальные люди так не пишут.

Но ведь пишут же!

Я это к чему? К тому, что такой синтакс, унаследованный в массе языков, часто оказывает медвежью услугу.

И сколько народа в мире так ошибалось? И как долго они искали свои баги? А все потому, что кто-то так сдизайнил язык.
ծրագրավորման լեզուներ ծրագրաւորում Սի տեղեկատուական տեքնոլոգիաներ
Правдивая история про красивый код на ц++ – 2008-10-25

В одной ныне прикрытой фирме работал программер, который очень любил ц++. И очень любил ООП.

И все писал классами. И свое текущее задание написал так, как ему нравилось: много классов, хороших и нужных.

Пришел к нему как-то проект манагер, и попросил показать работу за месяц. Проект манагер славился умом, и все его уважали. А проект, на который он пришел посмотреть, в ВС открывался несколько минут: классы, классы, классы…

Тогда проект манагер сделал то, что от него никто не ожидал. Нет, он не уволил программера.

Он удалил всю его работу, удерживая клавишу шифт 🙂 И наказал ему писать все заново, чтобы неповадно было

🙂
ծրագրային ապահովում ծրագրաւորում պատմութիւն Սի տեղեկատուական տեքնոլոգիաներ
fast and portable c compiler – 2007-04-25

tinycc – tcc

http://fabrice.bellard.free.fr/tcc/
կոմպիլյատորներ Սի