Բել լեզուն գրված է բելերենով։
1960 թվականին Ջոն Մաքքարթին նկարագրեց Lisp-ը՝ ծրագրավորման լեզվի նոր տեսակը։ Ես ասում եմ «նոր տեսակ», քանի որ Lisp-ը պարզապես նոր լեզու չէր, այլ լեզուների նկարագրության նոր եղանակ:
Lisp-ը սահմանելու համար նա սկսեց մի փոքրիկ դրույթներ, մի տեսակ աքսիոմներ, որոնք այնուհետև օգտագործեց թարգմանիչ գրել լեզվի համար:
Այն նպատակ չուներ նկարագրելու ծրագրավորման լեզու սովորական իմաստով. լեզու, որն օգտագործվում է համակարգչին ասելու, թե ինչ անել: 1960 թվականի իր աշխատության մեջ Լիսպը ընկալվում էր որպես Թյուրինգի մեքենային նման հաշվարկման պաշտոնական մոդել։ ՄակՔարթին չէր մտածում այն համակարգիչներում օգտագործելու մասին, քանի դեռ Սթիվ Ռասելը` նրա ասպիրանտը, չառաջարկեց դա:
Lisp-ը 1960-ին չուներ ծրագրավորման լեզուների համար ընդհանուր հատկանիշներ։ Օրինակ՝ թվեր, սխալներ կամ I/O չկային։ Այսպիսով, մարդիկ, ովքեր օգտագործում էին Lisp-ը որպես համակարգիչներ ծրագրավորելու համար օգտագործվող լեզուների հիմք, ստիպված էին իրենք ավելացնել այդ հնարավորությունները: Եվ նրանք դա արեցին՝ հրաժարվելով աքսիոմատիկ մոտեցումից։
Այսպիսով, Lisp-ի զարգացումն ընթացավ երկու, և թվացյալ միանգամայն անկախ, փուլերով՝ պաշտոնական փուլ, որը ներկայացվել է 1960թ.-ի հոդվածում, և իրականացման փուլ, որտեղ լեզուն հարմարեցվել և ընդլայնվել է համակարգիչների վրա գործարկվելու համար: Հիմնական աշխատանքը, եթե չափվում է իրականացված հնարավորությունների քանակով, տեղի է ունեցել իրականացման փուլում։ Common Lisp-ով թարգմանված 1960 թվականի Lisp-ը պարունակում է ընդամենը 53 տող: Այն անում է միայն այն, ինչ անհրաժեշտ է արտահայտությունները մեկնաբանելու համար։ Մնացած ամեն ինչ ավելացվել է իրականացման փուլում։
Իմ վարկածն այն է, որ, չնայած իր դժվարին պատմությանը, Լիսպը շահել է այն փաստից, որ նրա զարգացումը տեղի է ունեցել երկու փուլով. որ լեզուն սահմանելու սկզբնական վարժանքը՝ դրանում թարգմանիչը գրելով, Լիսպին տվել է իր լավագույն որակները։ Եվ եթե այո, ապա ինչո՞ւ ավելի հեռուն չգնալ:
Bel Հարցին պատասխանելու փորձ է արվում՝ իսկ եթե ֆորմալ փուլից վաղ փուլերում կատարման փուլ անցնելու փոխարեն այս անցումը հնարավորինս ուշ կատարվեր։ Եթե շարունակեք օգտագործել աքսիոմատիկ մոտեցումը, քանի դեռ չունեք ամբողջական ծրագրավորման լեզվին մոտ ինչ-որ բան, ի՞նչ աքսիոմներ կպահանջվեն ձեզ, և ինչպիսի՞ն կլինի ստացված լեզուն:
Ես ուզում եմ հասկանալ, թե ինչ է Բելը և ինչ չէ: Չնայած այն ունի շատ ավելի շատ առանձնահատկություններ, քան McCarthy-ի 1960 Lisp-ը, Bel-ը դեռևս արտադրանք է իր պաշտոնական փուլում: Ինչպես Lisp-ը, որը նկարագրված է 1960թ.-ի թղթում, դա այն լեզու չէ, որը կարող եք օգտագործել ծրագրավորման համար: Հիմնականում այն պատճառով, որ, ինչպես McCarthy's Lisp-ը, այն չի մտածում արդյունավետության մասին: Երբ ես ինչ-որ բան ավելացնում եմ Բելին, ես նկարագրում եմ հավելման իմաստը՝ չփորձելով ապահովել արդյունավետ իրականացում:
Ինչի համար? Ինչու՞ երկարաձգել պաշտոնական փուլը: Պատասխաններից մեկն է՝ տեսնել, թե ուր կարող է մեզ տանել աքսիոմատիկ մոտեցումը, որն ինքնին հետաքրքիր վարժություն է: Եթե համակարգիչները այնքան հզոր լինեին, որքան մենք կցանկանայինք, ինչպիսի՞ն կլինեին լեզուները:
Բայց ես նաև հավատում եմ, որ հնարավոր է գրել Bel-ի վրա հիմնված արդյունավետ իրականացում` ավելացնելով սահմանափակումներ: Եթե ցանկանում եք լեզու, որն ունի արտահայտչական ուժ, հստակություն և արդյունավետություն, գուցե արժե սկսել արտահայտչական ուժից և հստակությունից, այնուհետև ավելացնել սահմանափակումներ, այլ ոչ թե հակառակ ուղղությամբ գնալ:
Այսպիսով, եթե ցանկանում եք փորձել գրել Բելի վրա հիմնված իրականացում, առաջ գնացեք: Ես կլինեմ առաջին օգտատերերից մեկը։
Ի վերջո, ես որոշ բաներ վերարտադրեցի նախորդ բարբառներից: Կա՛մ նրանց դիզայներները ճիշտ են հասկացել, կա՛մ նախկինում օգտագործված բարբառների ազդեցության տակ լինելով՝ ես ճիշտ պատասխան չեմ տեսնում՝ ժամանակը ցույց կտա: Ես նաև փորձեցի շատ չշեղվել Լիսպի կոնվենցիաներից: Ինչը նշանակում է, որ եթե դուք տեսնում եք, որ հեռացում եք Lisp-ի կոնվենցիաներից, կարող է դրա համար պատճառ լինել:
.
Շնորհակալություն թարգմանության համար՝ Դենիս Միտրոպոլսկի
PS
Source: www.habr.com