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.)
#ծրագրաւորում #ահաւոր_ա #սի
գրիր քո լիսպը՝ լաւ գիրք առցանց՝ http://www.buildyourownlisp.com/ #ծրագրաւորում #լիսպ #սի #կոմպիլյատոր #գիրք
c եւ c++ պատմութիւն՝ https://vimeo.com/132192250
#ծրագրաւորում #կոմպիլյատոր #սի #ծրագրաւորման_լեզուներ #լեզու
սպանիչ պատմութիւն է, ինչպէս մարդը գրել է սի կոմպիլյատոր քառասուն օրուայ մէջ՝ http://www.sigbus.info/how-i-wrote-a-self-hosting-c-compiler-in-40-days.html
#ծրագրաւորում #կոմպիլյատոր #սի #ծրագրաւորման_լեզուներ #լեզու
Արմեն Բադալեանի զրոյցները Սի լեզուի մասին՝ https://github.com/armenbadal/notes-on-c
#ծրագրաւորում #սի #զրոյցներ #տտ #գիրք #դասընթաց ###
«Մոդուլային համակարգերի գաղտնիքները» հոդվածի հեղինակն է Սերգեյ Գուբանովը։
«Մոդուլ» եւ «մոդուլյար լեզու» թերմերի բացատրությունների զանազանությունը ծնում է ավներջ վեճեր։ Ինչեր ասես, որ մոդուլ չեն անվանել, ինչ լեզու ասես, որ մոդուլյար չեն համարել։ Ոմանք մոդուլ անվանում են կլասսները, ոմանք ել համեմատում են մոդուլները օբյեկտների հետ։ Առհասարակ այնպիսի տպավորություն է ստեղծվում, որ այժմ մոդուլյար եւ կոմպոնենտային լինելը նորաձեւ ոճ է։ Տարբերակների զանազանության պատճառը բացատրությունների ձեւի մեջ է՝ ներքին ձեւի։ Ներքին է այն իմաստով, որ սահմանումը տրվում է որոշ ներքին հատկությունների հիման վրա (մոդուլը պարունակում է տվյալներ, կոդ, տիպեր, ապահովում է ինկապսուլյացիան, ունի ինտերֆեյս, եւ այլն)։ Մոդուլների ներքին էական հատկությունները առանձնացնելու բազմաթիվ եղանակներ կան, իսկ դա նշանակում է, որ գոյություն ունեն նաեւ մոդուլների սահմանման բազմաթիվ եղանակներ։ Ապագայում ներքին հատկությունների քանակը գուցե եւ ավելանա, հայտնվեն սահմանումների նոր ձեւեր․ այսինքն՝ վիճելու առիթ ավելի շատ կլինի ու դա կտանի փակուղու։ Ելքը ներքին սահմանման փոխարինումն է արտաքինով։
Արտաքին է այն իմաստով, որ սկզբից պետք է նկարագրել ինչ է «մոդուլյար համակարգը», իսկ «մոդուլի» հասկացությունը կհայտնվի ինքնաբերաբար, ավտոմատ կերպով, քանի որ մոդուլը մոդուլյար համակարգի բաղադրիչն է։ Մոդուլյար համակարգը առաջնային է, մոդուլը՝ երկրորդային։ Մոդուլն ինքը իրանով չէ, այլ համակարգի մոդուլ է։ Մոդուլյար լեզու հարկավոր է անվանել այն լեզուն, որը մոդուլյար համակարգեր նախագծելու համար հարմարեցված, օպտիմիզացված է։ Այսպիսով՝ մոդուլյար ծրագրավորման լեզուների իմաստը մոդուլյար համակարգերի նախագծումն է։
Ստորեւ բացահայտենք մոդուլյար համակարգերի իմաստը:
Մոդուլյար ծրագրավորման համակարգերը եկել են միաձույլ ծրագրերը փոխարինելու համար։ Մոդուլյար համակարգեր կիրառելու իմաստը (ի տարբերություն միակուռ ծրագրերի) դինամիկ ընդարձակվելու ունակությունն է։ Մոդուլյար համակարգը կարելի է դինամիկ ընդլայնել մի քանի ձեւով։ Օրինակ՝ դրա մեջ նոր մոդուլներ ավելացնելով կամ փոխարինելով դրա միջի հին մոդուլները նորերով , որոնք ունեն ավելի լայն հնարավորություններ կամ որեւէ այլ լավացումներ։ Ընդարձակվող մոդուլյար համակարգը երբեք ավարտված չէ, այն զարգացում է ապրում։ Որոշ մոդուլներ փոխարինվում են, որոշները դինամիկ ավելացվում։ Այսպիսի համակարգի կյանքը կարող է լինել ավելի երկար, քան նրա միջի կոմպոնենտների կյանքը (տես․ մարդը եւ բջիջները, թարգմանչի նկատողություն)։ Համակարգի օգտագործողը ինքն է որոշում ինչպես այն ընդարձակել։ Կատարյալ դեպքում գոյություն ունի համակարգի կոմպոնենտների շուկա, որտեղ տարբեր արտադրողներ առաջարկում են մոդուլների իրենց իրագործումները, որոնք եւ ձեռք է բերում համակարգի օգտագործողը։ Կոմպոնենտների շուկայի բացակայությունը կարող է խոչընդոտել միաձույլ համակարգերից մոդուլյար համակարգեր անցնելուն։ Սակայն, պահանջարկը ծնում է առաջարկ։
Դիտարկենք մոդուլյար, դինամիկ ընդլայնվող համակարգի կառուցվածքը։ Մոդուլների միջեւ փոխազդեցությունը իրագործվում է մոդուլի՝ այլ մոդուլներ ներմուծելու (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 լեզվով։ Համակարգի կատարման միջավայրը իրականացված է անմիջապես «երկաթի» վրա։ Սակայն, դա արդեն այլ պատմություն է։ բնորինակը
ու տենց
Սա երրորդ մասն ա։
Ասենք սա ինձ թաչ ա անում՝
well, of course, if the world was ideal I would gladly recommend learn the basic concepts properly and then do programming with Oberon. But I’m fully aware that the world is not that simple. Programmers nowadays are faced with very difficult task and they cannot afford to build system from scratch. They have to use many tools that exist already and interface their new programs with them, and that’s where the problem is. This interface is not even properly and fully specified. Any many work comes with that. It is quite well known that if 5% percent going to programming is much, the rest is going to debugging. And that’s precular, it’s not science, not even engineering, it’s just trying.
try not to do things you don’t understand
and if you are forced to do things you don’t understand, then at least, do not speak about things you don’t understand
und so weiter