էսօր խօսում էինք, յիշատակեցի oncd ու nsa ռիփորթները, ահա էստեղ յղումները թողնեմ, որ լինեն, միւս անգամ հեշտ գտնեմ՝
երկրորդ թուղթը յիշատակում ա #պասկալ ֊ը։ այդ պատճառով embarcadero֊ն հրապարակեց այս յօդուածը՝ արդե՞օք պասկալը ապահով լեզու ա։
#ծրագրաւորման_լեզու #ծրագրաւորման_լեզուներ #ծրագրաւորում #տէք #ապահովութիւն #տէքնոլոգիա #տէքնոլոգիաներ #տեխնոլոգիաներ #լեզու #անվտանգութիւն
հա, ինչն ազատ ա, կարողանում ենք օգտագործել։ բայց արդե՞օք ուզում ենք, եթէ lowtech չի։
օրինակ, անդրոիդը աւտորիտար պրոդուկտ ա, կայսերական՝ խոշոր ընկերութեան պրոդուկտ ա, նախագծուած ա ոչ թէ օգտուողի, այլ բիզնէսի համար՝ օրինակ կարելի ա արգելել յաւելուածին էկրանահան անել։
մի տեղ գուցէ պատմել եմ, որ չկարողացանք թարումեանի տառատեսակները contribute անել անդրոիդի մէջ, զի մի տարի իրանց բզելուց եւ տշուելուց յետոյ պատասխանեցին որ third party փաթչ չեն վերցնի։ յետոյ իրենք աւելացրին հայերէն, ու շատ աւելի վատը, քան թարումեանը նկարել էր։
իսկ lowtech֊ը՝ վերնակուլար, տարօրինակ ա։
իսկ ո՞րը lowtech չի։
մենք հակուած ենք դիտարկել սի լեզուն որպէս lowtech, որովհետեւ իրա սինտաքսը մեծ չի, երկաթին մօտ ա՝ կարելի ա արդիւնաւէտ կատարուող կոդ գրել, քոմփայլեր գրելը տեսականօրէն շատ բարդ չի, ու ինտերնետում տարբեր նախագծեր կան, որ սուղ ժամանակում սի քոմփայլեր իրականացրել են։
բայց մոռանում ենք որ սի կոդի զգալի մասը, եթէ ոչ մեծ մասը՝ օգտագործում ա gcc֊ի ընդլայնումները։ ու լինուքս միջուկն էլ։ որովհետեւ էս կամ էն ընկերութեանը պէտք էր, փաթչ են արել, gcc֊ն ընդունել ա, առհասարակ կապիտալը սիրում ա նոր ու շատ ֆիչըրներ, իսկ երբ դրանք աւելանում են՝ սկսում են օգտագործուել։ էստեղ էական ա կապիտալի/կորպորացիայի ազդեցութիւնը gcc֊ի վրայ։
էսպէս քոմփայլերը ստացւում ա բարդ, իսկ այն օգտագործելով գրուած կոդը՝ ոչ տեղափոխելի։
եւ լինուսը բողոքում էր ու ասում էր որ կը հրաժարուէր gcc֊ից եթէ կարողանար։
իրականում սրանից բխում ա մտահոգիչ բան՝ լինուքս միջուկը ինքը lowtech չի՝ շատ լաւ ա աշխատում, շատ ֆիչըրներ ունի, ու lowtech չի։ ունի շատ կորպորատիւ ներդրում, ու պահանջում ա ոչ lowtech քոմփայլեր։ երեւի էսօր իւնիքսներից ամենա lowtech֊ը netbsd֊ն են ու openbsd֊ն։ ու դէ minix֊ը։ բայց էլի, netbsd֊ն ոնց որ դեռ gcc֊ի վրայ ա, openbsd֊ն անցաւ llvm֊ի, իսկ minix֊ն ի սկզբանէ շինում էին թանենբաումի amsterdam compiler kit֊ով, բայց վաղուց անցան llvm֊ի, որը էլի թոյլ ա տալիս օգտագործել լիքը ֆիչըրներ ու մեծ կախուածութիւն ա ստեղծում։
ինձ թւում ա, tcc֊ն ա lowtech։ ու ուրախ եմ որ voc֊ը tcc֊ի հետ աշխատում ա։
կայ gm2 (gnu modula-2) նախագիծ՝ տեսականօրէն modula-2 քոմփայլերը կարող ա ինքն իրան շինել մի քսան վայրկեանում նոյնիսկ շատ հին երկաթի վրայ։ բայց քանի որ gm2֊ը ինտեգրուած ա gcc֊ի հետ, gcc ծառի մաս ա (որը նաեւ ոգեւորում ա, մի կողմից պաշտօնական ա դարձնում լեզուն) նշանակում ա, որ այն քոմփայլ անելու համար պէտք ա նախ քոմփայլ անել gcc֊ն՝ գուցէ մի երեք ժամ, ու յետոյ նոր մի քսան վայրկեան մոդուլա֊2 ֊ի ֆրոնտէնդը։ հետեւաբար gm2֊ը lowtech չի, բայց ինչ֊որ մի այլ modula-2 քոմփայլեր, օրինակ mocka֊ն՝ երեւի ա։
փայթընը նոյնպէս lowtech չի։ կարելի ա հեշտ սկսել, անշուշտ, բայց շատ կորպորատիւ ներդրումներ ունի։ շատ կուզէի ասել որ go֊ն ա lowtech, զի լեզուն ինքը փոքր ա, քոմփայլերն ինքը առանց գրադարանների շինւում ա մի քանի րոպէում։ բայց կրկին՝ կորպորատիւ ներդրումներ, փաթեթների առատութիւն՝ արդե՞օք այն lowtech ա։
freepascal֊ը երեւի lowtech ա։ չնայած լեզուն կորպորատիւ նախագծման արդիւնք ա (ու դրանից լիքը ոչ հետեւողական բաներ), բայց համեմատ էսօրուայ լեզուների նոյնիսկ փոքր ա դիտւում։ առաւել եւս որ կարելի ա սահմանել ստանդարտ՝ օրինակ turbo pascal֊ինը, որը ընդհանուր առմամբ ամէն ինչի համար բաւական ա։ շատ էլ ա։
freepascal֊ը գրեթէ չունի կորպորատիւ ազդեցութիւն, ու իրա հետեւում ոչ թէ կապիտալ ա, այլ կոմպետենտ ու նուիրուած համայնք։ այնպէս որ երեւի lowtech ա, ու երեւի վերնակուլար ա։ օրինակ, երբ delphi֊ում հնարաւոր դարձաւ ամէնուր փոփոխական յայտարարել, freepascal֊ում դա քննարկուեց ու համայնքը որոշեց որ էդ լաւ չի ու պէտք չի։
c#֊ը հաստատ վերնակուլար չի՝ էդքան մեծացած լեզու ա ու էդքան բարդ շերտեր ա պահանջում։
lisp֊ը (բայց ոչ ansi common lisp֊ը) lowtech ա, վերնակուլար ա։
կրկին՝ ստանդարտիզացուած, յղկուած տէքը մեզ մօտ աւտորիտար ա ու կայսերական։
gemini֊ն՝ մարդու մասշտաբի զբօսնելի կամ հեծանուելի տէք ա։
ոչ ստանդարտ տէքը՝ ոչ ֆէյսբուքի կամ նոյնիսկ մաստոդոնի պէս՝ տարօրինակ ա։ իսկ տարօրինակը հարցեր ա առաջացնում, եւ պատահական չի որ աւտորիտար վարչակարգը փորձում ա պատսպարել, թաքցնել տարօրինակը, որ մարդկանց մտքերում անպէտք հարցեր չառաջանան։
#ազատութիւն #ծրագրաւորման_լեզուներ #ծրագրաւորում #վերնակուլար
գուցէ գիտէք, որ borland֊ը որ ստեղծել էր delphi֊ն, փորձեց object pascal֊ում եղած ֆիչըրները բերել c++։ ու բորլանդի c++֊ը տարբերւում ա սովորական c++֊ից նրանով, որ ունի այսպէս կոչուած closure֊ներ, կամ անոնիմ մեթոդներ։
իրականում, եթէ գալիս ես օբերոնից՝ ոչ մի տարօրինակ բան չկայ, շատ նորմալ ֆունկցիոնալ ա։
ահա օրինակ՝
type
TNotifyEvent = procedure(Sender: TObject) of object;
TButton = class
private
FOnClick: TNotifyEvent;
public
procedure Click;
property OnClick: TNotifyEvent read FOnClick write FOnClick;
end;
procedure TButton.Click;
begin
if Assigned(FOnClick) then
FOnClick(Self);
end;
procedure MyButtonClick(Sender: TObject);
begin
WriteLn('Button clicked!');
end;
procedure SomeEntryPoint;
var
Button: TButton;
begin
Button := TButton.Create;
Button.OnClick := @MyButtonClick;
Button.Click; // Outputs: Button clicked!
Button.Free;
end;
TNotifyEvent֊ը ֆունկցիայի, պրոցեդուրայի տիպ ա։ յետոյ այդ տիպի պրոցեդուրա ա կարելի ստեղծել։
Sender: Tobject ֊ը մեզ պէտք ա, որ իմանանք ով ա այդ event֊ը ուղարկել։ ինչի՞ ա ինքը TObject տիպի՝ որովհետեւ դա կլասսերի ծառի արմատն ա՝ ամէնը դրանից են ժառանգած, այսինքն՝ ամէնը կարելի ա դրան վերագրել։
օրինակ, կարելի ա էսպէս իմանալ թէ ով ա՝
if Sender is TButton then // Check if the sender is a button
begin
if TButton(Sender).Name = 'Button1' then
ShowMessage('Button 1 was clicked!')
else if TButton(Sender).Name = 'Button2' then
ShowMessage('Button 2 was clicked!');
end
else
begin
ShowMessage('Something else triggered this event!');
end;
տեսէք լրիւ օբերոնի runtime check անող IS ֊ն ա։
Button(Sender).Name ֊ը թոյլ ա տալիս կարդալ էդ կոնկրէտ կոճակի անունը։ օրինակ, կարող ես կոճակի անունը դնել Button1, իսկ կարող ես օրինակ՝ processButton։
Button֊ը իրականում ցուցիչ ա յիշողութեան մի տեղի, որ դատարկ ա։
TButton.Create֊ը լցնում ա էդ տեղը, ստեղծում ա յիշողութեան մէջ դաշտերը, կլասը, ու վերադարձնում ա էդ պատրաստուած յիշողութեանը ցուցիչ։
Button.OnClick֊ին կարողանում ենք վերագրել MyButtonClick ֆունկցիայի հասցէն։
այդ OnClick֊ը pascal֊ի property ա, որը կայ իմ իմանալով միայն այլ անդրեաս հայլսբերգի լեզուի՝ c#֊ի մէջ։
դրանից յետոյ Button.Click֊ը դա ա կանչելու։
շատ օբերոնական ա, չէ՞։ (:
ո՞նց ա դա արւում borland֊ի c++ դիալեկտով՝
#include <vcl.h>
#pragma hdrstop
class TButton
{
private:
typedef void __fastcall (__closure *TNotifyEvent)(TObject *Sender);
TNotifyEvent FOnClick;
public:
void __fastcall Click()
{
if (FOnClick)
FOnClick(this);
}
void __fastcall setOnClick(TNotifyEvent value)
{
FOnClick = value;
}
TNotifyEvent __fastcall getOnClick()
{
return FOnClick;
}
__property TNotifyEvent OnClick = {read=getOnClick, write=setOnClick};
};
void __fastcall MyButtonClick(TObject *Sender)
{
ShowMessage("Button clicked!");
}
int main()
{
TButton *Button = new TButton;
Button->OnClick = MyButtonClick;
Button->Click(); // Outputs: Button clicked!
delete Button;
return 0;
}
նախ, ահագին ոչ ընթերնելի ա, ինձ թւում ա։
յետոյ, դէ մասնաւորապէս որովհետեւ fastcall֊ը նշանակում ա որ պասկալի ֆունկցիա ա կանչելու, զի ամբողջ գրադարանը (vcl֊ը կամ fmx֊ը) պասկալով ա գրուած։
closure֊ը borland֊ի լուծումն ա որ մեթոդ փոյնթերն իմանայ this֊ի մասին։ ոնց pascal֊ում ա հնարաւոր։
property֊ով են փորձում դէ property իրականացնել։
հետաքրքիր ա, որ qt֊ն էլ ստանդարտ c++ չի՝ իրենք փաստացի նոր լեզու են ստեղծել, ու իրենց մօտ կայ moc (meta object compiler) որը յետոյ բերում ա qt֊ի կոդը ստանդարտ c++֊ի։ ու իրենք ունեն ինչ֊որ slot֊եր ու signal֊ներ որ էլի էմուլացնում են նոյն բանը՝ property֊ներ ու event֊ներ։
gtk֊ում ստանդարտ c ա, ու դա աւելի ա դուրս գալիս։
ի դէպ՝
https://norayr.am/weblog/2021/04/18/2492083/ — այն մասին ա որ embarcadero֊ն այլեւս չի կարողանում իր c++ քոմփայլերը շարունակել, զի c++ ստանդարտն էնքան արագ ա շարժւում, որ չեն ձգում։ ու հիմա փաստացի մէյնթէյն են անում llvm֊ի փաթչեր։ llvm֊ի արտօնագիրն էլ թոյլ ա տալիս որ դա անեն։ աւաղ։ (:
https://norayr.am/weblog/2021/04/19/2530704/
#ծրագրաւորում #ծրագրաւորման_լեզուներ #տէք #պասկալ #օբերոն #pascal #oberon
https://www.youtube.com/watch?v=0yXwnk8Cr0c
պարզւում ա, նիւ եօրքի մետրօյի կառավարումը կատարւում էր պասկալով գրուած ծրագրով։ մինչեւ չփոխեցին ադայի։
իսկ գիտէ՞ք քանի տող կոդ օրը պիտի գրի ապահով ծրագրի հեղինակը։ կիմանաք էս տեսանիւթից։
#պասկալ #ադա #ծրագրաւորում #տէք #ծրագրաւորման_լեզուներ #պատմութիւն
>In the specific case of the ISO-2022-CN-EXT conversion, the buf array has a fixed size of 6 bytes. The problem is that the size of the converted character stored in buf might exceed the USHORT-aligned boundary. When this occurs, it can overwrite the nearby memory, causing potential crashes or unexpected behavior.
կրկին նոյն սիական խնդիր՝ դուրս ա գալիս զանգուածի սահմանից։
#անվտանգութիւն #ծրագրաւորման_լեզուներ #ծրագրաւորում
ժամանակ առ ժամանակ rust սիրող ակտիւ համայնքը բարձրացնում ա՝ ամէնը սի֊ից ռասթով արտագրելու հարցը։
freebsd-hackers ցանկում մի քանի օր առաջ յայտնուած շղթայից մի գրառում՝
https://lists.freebsd.org/archives/freebsd-hackers/2024-January/002849.html
openbsd-misc ցանկից այլ գրառում՝
https://marc.info/?l=openbsd-misc&m=151233345723889&w=2
այն յղւում ա այս զրոյցին։
ըստ որում՝ ես կողմ եմ ամէնը սի֊ից արտագրելուն։ բայց երեւի ռասթը ամենալաւ տարբերակը չի։
#անվտանգութիւն #ծրագրաւորման_լեզուներ #ծրագրաւորում #քննարկում #մէջբերում
ասում եմ՝ բա ի՞նչ էք սովորում, ասում ա՝ «վիժուալ բէյսիկ», յետոյ «սի շարպ» ու «ժաւել»։
ասում եմ՝ ժաւելը ո՞րն ա, ջաւա՞ն թէ՞ ջս֊ը։
ասում ա՝ ջաւան։ ջս֊ը՝ ժաւելսպիրտն ա։
#զրոյց #ծրագրաւորման_լեզուներ #ուսում #ծրագրաւորում
ծրագրաւորման աշարհն խանգարուածութեան եւ մոլորութեան մէջ է։ շատ չի առաջընթացը հաշուողական գիտութեան սկզբունքները հասկանալու հարցում։ չնայած բարդացուած լեզուների գոյութեանը, ծրագրաւորողների մեծ մասը դեռեւս աշխատում են ութական, տասնվեցական, կամ այլ խորհրդաւոր տուեալների հետ, jump֊երով ու condition code֊երով, եւ այլ քաոս տարածող ձեւերով, անհանգստանում են լոկ մէկ միտ այստեղ եւ լոկ մի շրջան այնտեղ խնայելու մասին, բայց որպէս կանոն չեն կարող անգամ մի փենիով գրազ գալ թէ իրենց ծրագիրը կը կատարի խոստումները թէ ոչ։
#ծրագրաւորում #գիտութիւն #ծրագրաւորման_լեզուներ #վիրտ #մէջբերում #յուսալիութիւն #1968
ես շատ եմ նշել որ գօ֊ն՝ մէյնսթրիմի մէջ ինձ համար ամենալաւ լեզուն ու գործիքն ա։
բայց ես մէյնսթրիմի մէջ չեմ։ ու կարող եմ գօ֊ն նաեւ քննադատել։
ամենավատ բաներից ա՝ փաթեթային կառավարումը։ նախ՝ չի հաշւում ու ներկայացնում մեզ թէ ինչ կախուածութիւններ ա պատրաստւում բերել։
երկրորդը՝ ահա, էկրանահանի մէջ երեւում ա որ կախուածութիւնների զգալի մասը՝ գիտ֊ի ռեպօների որոշակի պիտակներ են։ իսկ գիտը բնաւ «immutable» չի։ ու էս պիտակով եղածը կարելի ա փոխել։
ու դու չգիտես թէ ինչ կոդ ես շինում։ ո՞նց վստահ լինես որ չարամիտ կոդ չես շինում։
ու տէնց։
#էկրանահան #գօ #փաթեթային_կառավարիչ #ծրագրաւորման_լեզուներ #անվտանգութիւն #ծրագրաւորում
ես հէնց նոր ֆիքսեցի մի բագ իմ ֆրիլանսում, իմ արաց վրիպակ։
իրանք ունէին երկու ֆունկցիա՝ մէկը MqttOut որը վերցնում էր string ու մէկը MqttOut որը վերցնում ա json։
ֆունկցիայի անունը նոյնն ա։
սկզբից պահանջւում էր տող ուղարկել։ յետոյ պահանջը փոխուեց ու պէտք եղաւ ուղարկել ջսոններ։
ու ես ունէի երկու ֆունկցիա, որ տող էին ուղարկում Mqtt֊ով։
յետոյ պէտք եկաւ փոխել՝ ես ստեղծեմ ջսօն, ու էդ ջսօնն ուղարկեմ։
յետոյ լիքը դեբագներից եւ անքուն գիշերներից յետոյ յոգնած էի, ու երբ սկսեցի ջսոն ուղարկել, մի ֆունկցիայի մէջ ջսոնը սարքեցի, ուղարկեցի։
միւս ֆունկցիայի մէջ ջսոնը սարքեցի, բայց ուղարկեցի էլի տողը, չնկատեցի որ ջսոնի փոխարէն տող ա դեռ ուղարկւում։
իսկ որոշ ժամանակ անց երրորդ ֆունկցիան աւելացրի, քոփի փէյսթ եմ արել երկրորդից, փոխել եմ ջսոն սարքելու մասը։
հետեւաբար կրկին տող ա ուղարկւում փոխարէնը ջսոն ուղարկուի։
էդքան դեբիլ սխալ չէի անի, եթէ ունենայի MqttOutStr ու MqttOutJson տարբեր անուններով ֆունկցիաներ։
իսկ ես դրանք կունենայի եթէ պասկալը թոյլ չտար function overloading։
եւ կրկին՝ ես սիրում եմ երբ լեզուն չի թողնում, ոչ թէ երբ ունի հնարաւորութիւն։ ես սիրում եմ երբ չունի հնարաւորութիւն։ զի հնարաւորութիւնը՝ նաեւ սխալ անելու հնարաւորութիւն ա։
#ծրագրաւորում #ծրագրաւորման_լեզուներ #մօտեցում
ես հասկացայ, ada֊ն, չնայած ալգոլ֊պասկալի աւանդոյթների մէջ ա, ինչով ինձ դուր չի գալիս։ հա, չաղ ա, բայց փոխարէնը բաւական հետեւողական ա։ միշտ չէ, բայց բաւական։ հա, համայնք ունի, հա, շատ կոդ կայ գրուած, հա, ուժեղ մէջք ունի, կորպորացիաներն ու պն֊ն…
այ այստեղ հասնելիս ես զգում եմ, որ ուզում եմ հեռու մնալ նախագծերից, որ հզօր աջակիցներ ունեն։ զի ինձ զզուելի ա լոկ արդէն հզօր աջակից ունենալու պատճառով ուրախանալը։
ու այո, արդե՞օք դա մեզ պէտք ա։
մի բան էլ մինիմալիզմի մասին։ էսօր եւս մի անգամ մտածեցի, ինչքան կարեւոր են պիտակները՝ ֆայլային համակարգում։ զգացի, զի երբ փնտրում եմ ինչ֊որ բան, կամ գնում եմ էն պանակ, ուր պիտի լինի, ու անում եմ ls | grep ինչ֊որ բան կամ անում եմ find . | grep ինչ֊որ բան որը պիտի որ անուան մէջ լինէր։
ու իրականում ես անում եմ յայց, խնդրելով էս կամ էն պիտակը։ որն ինձ մօտ անուան մէջ ա։ էն ա ինչի՞ համար պանակներ, եթէ կարող են լինել պիտակներ։ գիրք պիտակը, նկար պիտակը լրիւ բաւական ա։ ըստ որում դրանք կարելի ա եւ աւտոմատ աւելացնել՝ ըստ ֆայլի ֆորմատի։
#մինիմալիզմ #թուանշային_մինիմալիզմ #ծրագրաւորման_լեզուներ #պիտակ #պիտակներ #ֆայլային_համակարգ #նախագծում #դիզայն #ծրագրաւորում
էհ։
https://words.filippo.io/dispatches/openssl-punycode/
heartbleed֊ը այն պատճառով էր, որ սի֊ում կայ խնդիր՝ կարող ես զանգուածի յիշողութեան սահմաններից դուրս կարդալ։
իսկ այս խնդիրը հակառակն ա, զի սի֊ում կարող ես բուֆերի սահմաններից դուրս գրել։
ահա, անվտանգութեան եւ այլ սխալները շատ յաճախ իմպեմենտացիայի տեքնոլոգիայից են, օրինակ՝ լեզուից։
եւ հակառակը՝ ուզո՞ւմ էք անվտանգութիւն՝ գրէք յուսալի լեզուներով՝ ada, go, modula-2, modula-3, oberon, pascal, rust։
ու տէնց։
#ծրագրաւորում #տեք #ծրագրաւորման_լեզուներ #անվտանգութիւն #կրիպտօ #ցանց #համացանց
ուրեմն էսպիսի ծրագիր կայ՝ flickcurl — շատ գործ ա արուած, շատ հետաքրքիր նախագիծ ա։
c֊ով ազատ ու լրիւ իմպլեմենտացիա ա flickr֊ի api֊ի։
ամէն ինչ կարող ես անել։ եւ փնտրել, եւ վերբեռնել եւ պիտակել, եւ աւելացնել ալբոմի մէջ։
վերջն ա։
միայն մի խնդիր ունի՝ չի աշխատում։ (:
ես յիշում եմ, դեռ շատ տարիներ առաջ այն փորձել էի, ու պայթում էր։
պայթում էր, ասում էր՝ free(): double free detected in tcache 2։
այսօր էլ ա նոյն ձեւ պայթում։
ոնց որ քաղաքապետարանից հող ուզես, յետոյ վերադարձնես, զի չես օգտագործում, յետոյ խառնուես ու էլի վերադարձնես։ ու քաղաքը պայթի։ ա չէ, քաղաքը չի պայթում, բայց դու ես պայթում։ քո այլ հողերով յանդերձ։
ու մարդիկ չեն իմանում c֊ն ինչ հին ու ահաւորն ա։ ես դեռ չեմ ասում որ անկանխատեսելի վարքագիծ կարող ա ունենալ ծրագիրդ։ ըստ ստանդարտի։
պարզապէս հմուտ ծրագրաւորողները գիտեն՝ սէնց բաներ գրել չի կարելի, զի յետոյ չգիտես ինչ ա լինելու։
բայց c֊ն մէկ ա ունի այդ «լատիներէնի» հմայքը, այն դիւթում եւ կախարդում ա, ձգում ա մարդկանց։
չէ՞ որ իրանով են գրել unix֊ը։ ախր այլ բան չունէին՝ դրանով են գրել։ հազիւ էլ դրանով են գրել, թէ չէ մինչ էդ մեքենայական կոդով էին գրում։ algol֊ն ունէին, բայց դա էլ կեանքից հեռու մարդիկ էին ստեղծում։ կեանքին մօտ այն բերեցին հետագայ թարմացումներով, եւ տարբեր ուղղութիւններ վերցնելով՝ ժան իշբիան ու նիկլաուս վիրտը։ (գուցէ կարելի ա նաեւ նշել լուկա կարդելիի, գրեգ նելսոնի եւ այլ հաւէս մարդկանցով օլիվետտիի ու դեքի թիմը)։
իհարկէ, յետոյ եկած լեզուների դիզայնի կորպորացիաների ստեղծագործական փորձերը, չնայած c֊ի շատ խնդիրներ լուծել են, բայց գուցէ եւ աւելի ահաւոր հրէշներ են ստեղծել։
(էսքան ասում եմ, բայց ես կը նախընտրեմ c֊ով ծրագրաւորող աշխատել, քան շատ ու շատ լեզուներով։ չնայած ահաւոր, ահաւոր ա։)։
ու էդ flickcurl֊ի հեղինակը չէր կարողանում խնդիրը լուծել տարիներ շարունակ։ իսկապէս բարդ ա շատ բան ֆիքսելը։ գուցէ էդքան կամք կամ ժամանակ չի տրամադրել, բայց՝ բարդ ա։ աւելի լաւ ա էդ խնդիրը ստեղծելու հնարաւորութիւն չունենալ ի սկզբանէ։
ինչեւէ։
ի դէպ, էս գիշեր կարողացայ այդ խնդիրը շրջանցել, տառապելով git֊ի master֊ի ելատեքստի վրայ։ ինձ դա պէտք ա որ մատեանից սինք անեմ նկարները ֆլիքր։ նախկինում այլ ծրագրով էի անում, որը չէր կարողանում պիտակել, օրինակ։ միայն վերբեռնում էր։
#տեք #ծրագրաւորում #արհեստ #արուեստ #ծրագրաւորման_լեզուներ #գրադարան #լատիներէն #իւնիքս #պատմութիւն #անկապ
gcc 12֊ի նորութիւնները, ադայի աջակցութիւնը՝
https://gcc.gnu.org/gcc-12/changes.html#ada
շատ հաճելի ու հիացնող ա ա սա՝
>Greatly expanded code covered by contracts. Thanks to this work, there are now several Ada standard libraries fully proven in SPARK which means they have no runtime nor logical errors. They are mostly numeric and string handling libraries.
լաւ չեմ հասկանում SPARK֊ը, բայց ոնց որ վերջն ա իսկապէս։
#ադա #ծրագրաւորման_լեզուներ #թարմացում #լեզու
#համակարգիչ #ծրագրաւորման_լեզուներ #համակարգչութիւն #ռետրոհամակարգչութիւն #կարգիչ #ֆորթ #սպեկտրում #ծրագրաւորում #էկրանահան #պատմութիւն
օօծ֊ի գինն ու առաւելութիւնները (costs and benefits of oop) լոյս ա տեսել որպէս առանձին թուղթ, ու այս գրքի 12֊րդ գլուխն ա, 215 էջում։
թուղթը բարդ ա ճարել, գիրքը ես առել եմ։ ռուսալեզու լսարանն արտօնեալ էր՝ վոլոգդայի համալսարանը, ուր սուերդլովն ա աշխատում, թարգմանում եւ հրապարակում էր շատ օբերոնին վերաբերող թղթեր, եւ կայ նաեւ այս յօդուածի ռուսերէն թարգմանութիւնը։
#օբերոն #օօծ #ծրագրաւորման_լեզուներ #ծրագրաւորում #թուղթ #գիրք
հէհ, նոր ձեւի յարձակում՝
https://github.com/nickboucher/trojan-source
#անվտանգութիւն #տեք #ծրագրաւորման_լեզուներ #ծրագրաւորում
librsvg֊ն այլեւս (վաղուց) գրոած ա rust֊ով։
իսկ դրանից կախուած ա gtk աշխարհի ու գնօմի լիքը ծրագիր։
եւ առհասարակ՝ svg ուզում ես որ ծրագրերդ ճանաչեն՝ ես ուզում եմ։
հետեւաբար՝ պէտք ա rust ունենամ։ ու դա սարսափելի չի բնաւ, rust֊ն էլ վատ լեզու չի, բայց խնդիրն այն ա որ յաճախ ա թարմանում, ու ամէն անգամ երբ համակարգս թարմացնում եմ՝ հիմա ստիպուած եմ rust շինել։ դա շատ հաւէս չի, մանաւանդ փայնբուքի վրայ։
gcc֊ն էդքան արագ արագ չի թարմանում, ու ամէն անգամ նոր gcc չես հաւաքում։
ու տէնց։
#ծրագրաւորման_լեզուներ #փայնբուք #ջենթու #առօրեայ #անկապ #չգիտեմ
մարդիկ SPARK֊ի կոդն էին թիրախաւորում, բայց արդիւնքում գտան խնդիր RISC-V ISA֊ի մէջ։
#ծրագրաւորում #տեք #ապահովութիւն #ծրագրաւորման_լեզուներ #ադա #սպարկ
84 թուի «բայթ» հանդէսում կար յօդուած ֆորթի մասին, նաեւ հէնց վիտի եւ գուտքնեխտի տեքստերը՝ մոդուլա-2֊ի մասին։
#էկրանահան #հանդէս #համակարգիչ #կարգիչ #ծրագրաւորում #ծրագրաւորման_լեզուներ #ֆորթ #մոդուլա #մոդուլա-2 #ամսագիր #բայթ #1984 #պատմութիւն
այստեղ գրեմ որ չմոռանամ։ վերջերս մէկն ասում էր որ մի նախագիծ չի ուզում սի֊ով գրի, զի տողերի հետ բարդ ա աշխատել, գօ֊ի փաթեթների կառավարումը չի սիրում, իսկ պասկալով կանէր, բայց սովորել ա արդէն որ ուր ուզես ինչ ուզես յայտարարում ես, իսկ պասկալը պահանջում ա որ դա լինի ֆունկցիայի վերեւում յատուկ տեղում։
ես էլ ասացի որ այդպէս սիրում եմ, բայց դելֆի պասկալում հիմա իր ուզածով ա։ ու որ ֆպց֊ի դեւերը որոշեցին այդ փոփոխութիւնը չիրականացնել։
նա յղուներ ուզեց, ես փնտրեցի որ նախկինում կարդացածս գտնեմ՝
https://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html — սա դելֆիի մասին։
սա էլ՝ https://forum.lazarus.freepascal.org/index.php?topic=43172.0 — ֆրիպասկալի համայնքի քննարկումը։
սա գրեցի որ #պասկալ պիտակով ապագայում հեշտ գտնեմ։
#դելֆի #ծրագրաւորման_լեզուներ #ծրագրաւորում
յղում @{https://xn–69aa8bzb.xn–y9a3aq/users/spectrum}֊ից՝
https://www.youtube.com/watch?v=mRwHZTNGdoY
#տեք #ծրագրաւորում #ծրագրաւորման_լեզուներ #տտ #պատմութիւն
այսօր դաշնեզերքի օգնութեամբ բացայայտեցի cppcast պոդքաստը։ լսեցի վերջին էպիզոդը՝ այն մասնաւորապէս ̶բ̶ո̶ր̶լ̶ա̶ն̶դ̶ի̶ էմբարկադերօյի c++ builder֊ի մասին էր։
հետաքրքիր ա որ
սա շատ կարեւոր թեմա ա ինձ համար, նշանակում ա c++֊ն այնքան արագ տեմպերով ա զարգանում, որ նոյնիսկ այդ, բաւական լուրջ, բաւական, թւում ա թէ, փող ունեցող ընկերութիւնը, չի հասցնում իր կազմարկիչը զարգացնել։
սա կարող էր ոգեւորիչ լինել․ ահա՛, ազատ ծրագրակազմը յաղթում ա, ոչ մի առանձին ընկերութիւն չի կարող հասնել, զի համայնքը զօրաւոր ա, եւ մարդկութիւնը իր ամբողջ ռեսուրսներով կարողանում ա աւելին անել, քան առանձին ընկերութիւնը։
ու մասամբ երեւի այդպէս ա։
մտահոգիչ մասն այն ա, որ լեզուն այնքան ա բարդացել, որ չի լինում առանձին ընկերութեան համար այն իրականացնելն այլեւս իրատեսական չի։ մօտաւորապէս նման պատմութիւն ա դիտարկիչների հետ՝ html֊ն ա այնքան բարդացել, որ առանձին ընկերութիւն այն իրականացնել չի կարող։
եւ մեր բախտից ա (դէ իրականում նախկինում տարուած պայքարից) որ գուգլն ու էփլը այսօր ազատ ծրագրակազմ են ֆինանսաւորում, ու կայ chromium֊ը, եւ llvm֊ն ա ազատ։
բայց եթէ մթնոլորթը փոխուի, մի պահ ա գալու, երբ chromium֊ի շարժիչը գուգլը կարող ա եւ փակել։ իսկ եղած ազատը համայնքը չի կարողանայ զարգացնել այնպէս որ արագ զարգացող ստանդարտներին հասնի։ այդ պատճառով էլ եմ ես ոգեւորւում աւելի պարզ համակարգերից, ինչպիսին են gemini֊ն, եւ oberon֊ը։
c լեզուն էլ ա բաւական պարզ (առանց ընդլայնումների) որ մի հոգի նստի եւ մի քանի ամսում իրականացնի կազմարկիչ։
շարունակեմ այն մասին, ինչ եմ յիշում զրոյցից։
ի՞նչ ընդլայնումներ են դրանք։
դէ դա ես գիտէի, ու կարելի ա պատկերացնել՝
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֊ի փոփոխութիւններ են նախատեսւում, ապա դրանք արւում են մէյջըր ռելիզների ժամանակ։ այդ փոփոխութիւնները ոչ միայն կարող են վերաբերուել հէնց ֆունկցիաներ կանչելու ձեւին, այլեւ նրան ինչպէս են տուեալները պահւում յիշողութեան մէջ։
ու գուցէ ios դեւելոփմենթն աւելի պարզ բան ա՝ կպնում ես objective c գրադարաններին, պէտք չի jni անել, պէտք չի լիքը այլ բան։ կամ գուցէ իսկապէս այօս դեւելոփմենթի պահանջարկ ունեն։
վախեցայ որ դելֆիից էլ են հանել անդրոիդի մասը, ստուգեցի, ու կայքում կարծես թէ գրուած ա որ ունեն անդրոիդ դեռ։ չգիտեմ։
որոշ չափով խօսուեց delphi֊ի մասին, զի builder֊ի delphi֊ի հետ սերտ կապեր ունի։ օրինակ, կարող ա ընդլայնել պասկալով գրած կլաս։ դէ բնական ա, զի կարող ա ուզես մի կոնտրոլի հիման վրայ մի այլ կոնտրոլ սարքել։ պատմեց, որ delphi֊ն կարողանում ա գեներացնել հեադեր նիշքեր որ իրենց c++ կազմարկիչը կը ճանաչի։ որ շատ հանգիստ լինկ են լինում pascal եւ c++ ծրագրերը։ ու որ աւելի բարդ ա պասկալից կպնել սիփլասական գրադարաններին, քան հակառակը, զի սիփլասփլասը կոնստրուկտներ ունի, որ պասկալը չունի։ իսկ այն կոնստրուկտները որ իրենց պասկալից պէտք էին՝ իրենք արդէն աւելացրել են իրենց սիփլասփլաս կազմարկչի մէջ, ու հետեւաբար պասկալ կոդ շատ հեշտ ա օգտագործել։
նշեց մի քանի նախագիծ, բայց առանց անունների, որ գրուել են սիփլասփլաս բիլդերով։ ու ես հասկացայ որն են իրենց մեծ պատուիրատուները, օրինակ կան ծրագրեր որ սպասարկում են էլեկտրակայաններ, ու քանի որ կոդն ի սկզբանէ գրուած ա եղել բորլանդի բիլդերով, այսօր էլ էմբարկադերօն պէտք ա, որ սպասարկի պրոդուկտ, որը կառնեն այդ էլեկտրակայանի ծրագրակազմ նախագծողները։
ես կարծում եմ որ իրենց գնային քաղաքականութիւնը խանգարում ա իրենց զարգանալ։ եւ այդ պատճառով էլ վարողը հարցրեց, արդեօք կան օփեն սորս դեւերի համար անվճար վերսիաներ։ պատասխանը՝ այո, բայց մի վերսիա հետ ընկած ա, աշխատում ենք թարմացնել։
ովքե՞ր են օգտագործում բիլդեր — հիմնականում ուինդոուս դեւելոփերներ։
ինձ թւում ա, դա բորլանդի, եւ յետոյ էմբարկադերօյի ամենամեծ խնդիրներից ա, որ չեն կարողացել հասցէագրել (այսպէս կարելի՞ ա ասել), չեն կարողացել այնպէս անել որ ոչ ուինդոուս ծրագրաւորողները հետաքրքրուեն նախագծով։ իհարկէ, շատ բարդ ա մրցել լինուքսի աշխարհում, ուր մարդիկ սովոր են ազատ լուծումների, ու սիփլափփլաս մարդիկ սովոր են քիւթին, եւ շատերն իրենց վճարում են։ բայց կարելի էր մրցել, կարելի էր լուրջ փորձեր անել շուկայ մտնելու։ ու բնաւ անիրատեսական չէր մակօսի շուկայ մտնել, կարծում եմ շատ շատերը կը նախընտրէին բիլդեր էքսկոդին, բայց բիլդերի (ինչպէս եւ դելֆիի) այդիին, նախագծման միջավայրը աշխատում ա միայն ուինդոուսում։ ինձ թւում ա դա ամենակարեւոր խնդիրներից ա որ իրենք չլուծեցին, զի մակօս դեւը չի ուզի ուինդոուսում գրել մակօս ծրագրեր։
ընդհանուր առմամբ զարմացած եմ, ինչքան անտեղեակ էր վարողը, որ սիփլասփլաս աշխարհից ա, բիլդերից։ ու դա այն մասին ա, ինչքան ա բիլդերը, որ բաւական լաւ նախագիծ ա, ու ոգեշնչուած ա դելֆիից, չգնահատուած, ինչպէս եւ ինքը դելֆին։
#ծրագրաւորում #ծրագրաւորման_լեզուներ #պասկալ #սիփլասփլաս #սի #բիլդեր #բորլանդ #էմբարկադերօ #նախագծում #ծրագրակազմ #հարցազրոյց #պոդքաստ #տտ #տեք #գործիք #գործիքներ
վաչագանը չափել ա տարբեր ծրագրաւորման լեզուների կոմպիլեատորների սարքած կոդի, ու ինտերպրետատորների արագագործութիւնը կոնկրետ խնդիրներում։
եւ ահա ինչ ա ստացել՝
փաստօրէն, voc֊ը համեմատելի ա c/c++/go֊ի հետ cpu usage֊ի առումով, եւ ամենաքիչ յիշողութիւնն ա վերցնում նոյն խնդիրները լուծելիս։
ու նա դեռ ծանօթ չի օբերոնի հետ, ու գուցէ օպտիմալ կոդ չի գրել, չեմ նայել։
նաեւ ուզում եմ պասկալ (fpc)֊ն էլ աւելացնել, տեսնենք ոնց ա իրան պահում։
#ծրագրաւորում #իրականացում #ծրագրաւորման_լեզուներ #արագագործութիւն #արդիւնաւէտութիւն #տեքնոլոգիաներ #տտ #տեք
շատ երկար ա rust֊ը քոմփայլ լինում մի թրեդով, իսկ ֆֆ֊ի թարմացումը իր հետ ռասթի թարմացում ա պահանջում։
մի թրեդով եմ անում որ ուրիշ գործեր անեմ կողքից, ու կարգիչը շատ չտանջուի։
ու մտածում եմ՝ էսա ֆֆ֊ն չլինի, ի՞նչ եմ անելու։
գտնելու եմ ինչ֊որ շատ թեթեւ բան՝ midori֊ի պէս, ու դէ այն կայքերի մեծ մասը չի բացի, դէ ես էլ չեմ մտնի էդ կայքերը։
երեւի տէնց։
առհասարակ, դա վատ մօտեցում չի։
ես ջս չեմ սիրում, ու ատում եմ երբ տաքանում են կարգիչները, ֆաներն են պտտում, ինչ ա թէ վեբ էջ են բացել։ ահաւոր հզօր կարգիչներ ունենք՝ ու վատնում են իրենց հզօրութիւնը էդ ձեւ ինտերպրետացուող կոդի վրայ։ էնպէս չի որ դանդաղ են կամ դանդաղում են։ վատ ա ամէնը։ ահաւոր։
ու տէնց։
#ոստայն #սարդոստայն #համացանց #ծրագրաւորման_լեզուներ #ծրագրաւորում #տեքնոլոգիաներ #կարիգչ #դիտարկիչ #զննիչ #ֆայրֆոքս #ինտերնետ
շատ լաւ թել ա՝ https://softwareengineering.stackexchange.com/questions/246762/is-there-a-real-advantage-to-dynamic-languages
#ծրագրաւորում #մօտեցում #ծրագրաւորման_լեզուներ #տեքնոլոգիա
շատ կարեւոր քննարկում՝
https://github.com/modula3/cm3/issues/42
ես աջակցում եմ հարց բարձրացնողին։ գուցէ ինձ պէտք ա ինիցիալիզացնել զանգուածը այլ թուերով, ինչի՞ համար ժամանակ ծախսել ու զրօներ գրել դրա մէջ։
ու նախագծողները դեբիլ չէին, որ յատուկ նշել են, թէ ինչ պատահի կարող ա լինել, որ կազմարկիչը չպէտք ա ինիցիալիզացնի։
#մոդուլա #մոդուլա֊3 #ծրագրաւորում #ծրագրաւորման_լեզուներ #նախագծում
օբերոնի եւ մոդուլայի թրենդերի մասին՝ http://norayr.arnet.am/weblog/թրենդային
#օբերոն #մոդուլա-2 #մոդուլա #ծրագրաւորում #ծրագրաւորման_լեզուներ
Վերջերս դրա վառ օրինակն է հանդիսացել Ադա֊ն։ Եթէ Ադա֊ն պէտք է ունենայ ստանդարտ, աւելի լաւ է որ այդ ստանդարտը լինի աներկբայ։ Առնուազն երկու նախաձեռնութիւն եղաւ․ երկուսի արդնիւնք էր մօտ 600 էջ կազմող ֆորմալ տեքստ, այսինքն անգամներ շատ, քան անհրաժեշտ է համոզուելու համար, որ երկու թուղթն էլ սահմանում են նոյն լեզուն։ Այդ երկու փաստաթղթերի ակնյայտ անկառավարելիութեան պատճառն երկու խմբից ոչ մէկն էլ չէ, ոչ էլ այն ֆորմալ ձեւն է, որ իրենք կիրառել են, այլ ինքը լեզուն․ արդեօք չներկայացնելով ֆորմալ ձեւակերպում, լեզուի նախագծողները կարող են թաքցնել, որ առաջարկում են անկառավարելի հրէշ։ Այն, որ Ադա֊ն կը թեթեւացնի ծրագրաւորման խնդիրները եւ կաւելացնի մեր ջանքերի արդիւնաւէտութիւնը՝ այն հեքիաթներից է, որոնց հաւատալու համար պէտք է ունենալ զինուորական կրթութիւն։
գիտական ֆանտաստիկան եւ գիտական իրականութիւնը յօդուածից, Էդսգեր Վիբե Դեյքստրա։
#ադա #ծրագրաւորման_լեզուներ #դեյքստրա #յօդուած #քաղուածք #մէջբերում #ծրագրաւորում #կրթութիւն #հեքիաթ
ինչ հետաքրքիր է։ հասքելի եւ պասկալի հանդէպ հետաքրքրութիւնը աճում եւ նուազում է ուսումնական սեմեստրերի պարբերութիւններով։ (:
համոզուել ինքնուրոյն։
#էկրանահան #ծրագրաւորման_լեզուներ #ադա #պասկալ #հասքել #ծրագրաւորում
c եւ c++ պատմութիւն՝ https://vimeo.com/132192250
#ծրագրաւորում #կոմպիլյատոր #սի #ծրագրաւորման_լեզուներ #լեզու
սպանիչ պատմութիւն է, ինչպէս մարդը գրել է սի կոմպիլյատոր քառասուն օրուայ մէջ՝ http://www.sigbus.info/how-i-wrote-a-self-hosting-c-compiler-in-40-days.html
#ծրագրաւորում #կոմպիլյատոր #սի #ծրագրաւորման_լեզուներ #լեզու
գոու֊ն ընչդէմ ռասթ֊ի ընդդէմ սուիֆթ֊ի՝ https://grigio.org/go-vs-node-vs-rust-vs-swift/
#հետազօտութիւն #ծրագրաւորում #կոմպիլյատոր #թեստ #ծրագրաւորման_լեզուներ #գոու #ռասթ #սուիֆթ
ինչպէս է մայքրոսոֆթը խաղից հանել ոչ իր կոմպիլյատորները՝
մենք շատ նպատակաուղղուած էինք որպէսզի մեր Delphi եւ C++ կոմպիլյատորներով ստանանք WinRT֊ի համար կոդ։ Այս պահին խնդիրն այն է, որ այն ՕՀ API֊ները, որ անհրաժեշտ են քո լեզուի RTL֊ն իրականացնելու համար թոյլատրուած չեն։ Գիտէք, ասենք RtlUnwind֊ը բացառութիւնների մշակման կամ VirtualAlloc֊ն յիշողութեան կառաւարման համար… Այդ եւ նման ֆունկցիաներին դիմելը աւտոմատ որակազրկում է ձեր ծրագիրը․ այն չի կարող լինել «պաշտօնական» WinRT ծրագիր եւ տեղակայւել մայքրոսոֆթի խանութից։
աղբիւր (անգլերէն)
երբ նման բաներ եմ կարդում, զգում եմ, ինչքան չեմ ուզում գործ ունենալ այդ փակ էկոհամակարգերի հետ, ու ինչ հաւէս է ծրագիր գրել ազատ միջավայրերում՝ ազատ հարթակների համար։
#ծրագրաւորում #մայքրոսոֆթ #կոմպիլյատորներ #ծրագրաւորման_լեզուներ #մրցակցութիւն
ահա, Վիրտի PICL լեզուի կոմպիլյատորը, որ նախատեսուած է PI16F84 միկրոկոնտրոլերներ ծրագրաւորելու համար, կարողացայ տեղափոխել Լինուքս, աշխատեցնել, եւ կոմպիլյացիա անել մի քանի թեստ։
#կոմպիլյատոր #էկրանահան #ծրագրաւորում #լինուքս #երկաթ #ծրագրաւորման_լեզուներ #միկրոկոնտրոլեր
Իրենք գրում են ֆունկցիոնալ ծրագրեր վճռականօրէն ոչ ֆունկցիոնալ խնդիրների լուծման համար, կիրառելով մոնադ կոչուող հնարք, որը ես չեմ բացատրի, ու մէկ է ոչ մէկ չի հասկանում, բայց կարեւորն այն է, որ շատ խելացի ծրագրաւորողի ձեռքերում, ֆունկցիոնալ ծրագրաւորումը «կարող է» օգտագործուել շատ աւելի տեղերում, քան կարող ես միամտօրէն ենթադրել։
Ու ահա թէ որն է իրական խնդիրը։ Սա աշխատում է սկզբից, յետոյ շարունակում է աշխատել մինչեւ հանկարծակի չաշխատի։ Ու այս կոմունիզմը ֆունկցիոնալիզմը տարածւում է գաղափարախօսութիւնը մինչեւ ձեր երկիրը կոդը ծանրաբեռնուած է պարտքերով եւ ոչ մէկ չի կարող հանել ձեզ այս վիճակից, քանի որ դուք ունէք զանազան մոնադներ եւ ոչ մէկ չի հասկանում դրանք։
#ծրագրաւորում #ֆունկցիոնալ_ծրագրաւորում #իմպերատիւ_ծրագրաւորում #մոնադներ #ծրագրեր #ծրագրաւորման_լեզուներ #նախագծում #էփլ #սուիֆթ #դիզայն #արուեստ