Covid-19-ის პანდემიის დასაწყისში ნიუ-ჯერსის გუბერნატორმა უჩვეულო რამ აღიარა: მას COBOL-ის დეველოპერები ამოეწურა. შტატის უმუშევრობის დაზღვევის სისტემები 60 წლის წინანდელ პროგრამირების ენაზე იყო დაწერილი და ასობით ათასი განაცხადის დასამუშავებლად განახლებას საჭიროებდა. პრობლემა ის იყო, რომ შტატის თანამშრომლებიდან ცოტამ თუ იცოდა ამის გაკეთება. კრიზისი გასცდა ნიუ-ჯერსის საზღვრებს, რომელიც მხოლოდ ერთ-ერთი იყო იმ მრავალ შტატს შორის, რომელიც ამ მოუქნელ სისტემებზე იყო დამოკიდებული. ერთი უხეში გათვლით, 2020 წელს COBOL-ის არაეფექტურობამ აშშ-ის მშპ-ს 105 მილიარდი დოლარი დააკარგვინა.
ალბათ იფიქრებთ, რომ ამის შემდეგ ნიუ-ჯერსიმ თავისი სისტემა ჩაანაცვლა — და რომ Covid-ი COBOL-ის ბოლო ამოსუნთქვა იყო. მთლად ასე არაა. შტატის უმუშევრობის ახალ სისტემას მრავალი გაუმჯობესება მოჰყვა, მაგრამ backend-ზე ის მაინც ამ უძველეს ენაზე მომუშავე მეინფრეიმით (mainframe) ფუნქციონირებდა.
COBOL (Common Business-Oriented Language) ისტორიაში ყველაზე ფართოდ დანერგილი კომპიუტერული ენაა. 2000 წლისთვის დაწერილი 300 მილიარდი ხაზი კოდიდან 80 პროცენტი COBOL-ზე იყო შექმნილი. ის კვლავ ფართოდ გამოიყენება და მხარს უჭერს უამრავ სამთავრობო სისტემას, როგორიცაა სატრანსპორტო საშუალებების ჩანაწერები და უმუშევრობის დაზღვევა; ნებისმიერ მოცემულ დღეს, მას შეუძლია დაახლოებით 3 ტრილიონი დოლარის ღირებულების ფინანსური ტრანზაქციების დამუშავება. მე COBOL-ს ციფრული აზბესტის ერთგვარ სახეობად მივიჩნევ, რომელიც ოდესღაც თითქმის ყველგან იყო და ახლა მისი ამოღება წარმოუდგენლად, სახიფათოდ რთულია.
COBOL პირველად 1959 წელს შეიმუშავა კომიტეტმა, რომელიც აშშ-ის კომპიუტერული ინდუსტრიის უმეტესობას (მათ შორის გრეის ჰოპერს) მოიცავდა. იგი ითხოვდა „ავტომატური ციფრული კომპიუტერებისთვის საერთო ბიზნეს ენის სპეციფიკაციებს“, რათა გადაეჭრა მზარდი პრობლემა: პროგრამირების ხარჯები. პროგრამები კონკრეტული მანქანებისთვის ინდივიდუალურად იწერებოდა და თუ მათი სხვა სისტემაზე გაშვება გსურდათ, ეს კოდის თითქმის მთლიანად თავიდან დაწერას ნიშნავდა. კომიტეტმა თავდაცვის დეპარტამენტს (Department of Defense) მიმართა, რომელმაც პროექტს დიდი მხარდაჭერა გამოუცხადა.
COBOL-ის დიზაინი მას სხვა ენებისგან განასხვავებდა როგორც მაშინ, ისე ახლა. ის უნდა დაწერილიყო მარტივი ინგლისურით, რათა ნებისმიერს, არაპროგრამისტებსაც კი, შესძლებოდათ მისი გამოყენება; სიმბოლური მათემატიკური აღნიშვნები მხოლოდ ხანგრძლივი დებატების შემდეგ დაემატა. COBOL-ის უმეტესი ვერსიები ასობით სიტყვის გამოყენების საშუალებას იძლევა (Java მხოლოდ 68-ს უშვებს), მათ შორის „is“, „then“ და „to“, რათა წერის პროცესი გამარტივდეს. ზოგიერთები იმასაც ამბობდნენ, რომ COBOL-ის მიზანი კომპიუტერული პროგრამისტების ჩანაცვლება იყო, რომლებსაც 1960-იან წლებში ბევრ კომპანიაში განსაკუთრებული სტატუსი ჰქონდათ. ისინი ისეთი ტექნოლოგიის ოსტატები იყვნენ, რომლის გაგებაც ადამიანების უმეტესობას უჭირდა. COBOL-ის დიზაინერები ასევე იმედოვნებდნენ, რომ ის საკუთარ დოკუმენტაციას თავად შექმნიდა, რაც დეველოპერებს დროს დაუზოგავდა და გრძელვადიან პერსპექტივაში მის შენარჩუნებას გაამარტივებდა.
მაგრამ რას ნიშნავდა წაკითხვადობა? პროგრამები არც წიგნებია და არც სტატიები; ისინი ინსტრუქციების პირობითი ნაკრებებია. მიუხედავად იმისა, რომ COBOL-ს შეეძლო ერთი ხაზი კოდის სირთულე ყველასთვის გასაგებ ფორმაში მოექცია, ეს უპირატესობა ქრებოდა პროგრამებში, რომლებიც ათასობით ხაზს მოიცავდა. გარდა ამისა, COBOL-ში დანერგილი იყო ლოგიკის ისეთი ნაწილი, რომელიც მოგვიანებით საძულველი გახდა: GO TO ფუნქცია, უპირობო განშტოების მექანიზმი, რომელიც პროგრამის ერთი ნაწილიდან მეორეში გადაგისროდათ. შედეგი იყო ე.წ. „სპაგეტის კოდი“ (spaghetti code), როგორც დეველოპერები უწოდებენ მას, რამაც თვით-დოკუმენტირების იდეა აზრს მოკლებული გახადა.
ბევრ კომპიუტერულ მეცნიერს COBOL-თან დაკავშირებით თავიდანვე პრობლემები ჰქონდა. ედსგერ დეიკსტრას ის ძალიან სძულდა და ამბობდა: „COBOL-ის გამოყენება ანადგურებს გონებას; ამიტომ მისი სწავლება კრიმინალურ დანაშაულად უნდა ჩაითვალოს.“ დეიკსტრას ასევე სძულდა GO TO ფუნქცია და ამტკიცებდა, რომ ის პროგრამებს თითქმის გაუგებარს ხდიდა. არსებობდა გარკვეული სნობიზმიც: COBOL-ს ხშირად ზემოდან უყურებდნენ, როგორც წმინდა უტილიტარულ ენას, რომელიც მოსაწყენი პრობლემების გადასაჭრელად იყო შექმნილი.
ჯინ სამეტმა, ერთ-ერთმა თავდაპირველმა დიზაინერმა, ეს სხვაგვარად დაინახა — ენას უბრალოდ რთული ამოცანა ჰქონდა დაკისრებული: ისეთი რთული სისტემების მართვა, როგორიცაა სოციალური დაცვა. კარგი COBOL ნამდვილად თვით-დოკუმენტირებადი იყო, მაგრამ ბევრი რამ კონკრეტულ პროგრამისტზე იყო დამოკიდებული. როგორც მათემატიკოსმა ფრედ გრუენბერგერმა თქვა: „COBOL, ოსტატის ხელში, ულამაზესი და ძალიან ძლიერი ინსტრუმენტია. COBOL, სადღაც დაბალი კვალიფიკაციის კლერკის ხელში კი — საშინელი ქაოსი.“
რა თქმა უნდა, არცერთ ამ ფაქტორს არ შეუფერხებია COBOL-ის ფართო გავრცელება. ის ფაქტი, რომ თავდაცვის დეპარტამენტმა მას უპირატესობა მიანიჭა და შეკვეთილი მანქანების უმეტესობაში COBOL კომპილატორები მოითხოვა, ნამდვილად დაეხმარა პროცესს. ცივი ომის პიკზე არცერთ კომპიუტერის მწარმოებელს არ სურდა ფედერალური კონტრაქტების ხელიდან გაშვება. საბოლოოდ, COBOL-მა ორ ყველაზე მნიშვნელოვან მიზანს მიაღწია: ის მართლაც დამოუკიდებელი იყო მანქანისგან და სწრაფად ვრცელდებოდა. მისმა ფიქსირებულ-წერტილოვანმა და არა მცურავ-წერტილოვანმა არითმეტიკამ COBOL იდეალური გახადა ფინანსური აპლიკაციებისთვის, რის გამოც ის ფინანსურ სექტორში ყველგან გვხვდება.
თუმცა, როგორც ნიუ-ჯერსიმ 2020 წელს ისწავლა, COBOL-ის თანამედროვე ეპოქისთვის განახლება რეალურ გამოწვევებს წარმოშობს. სამეტმა აღიარა ადრეული დიზაინის მთავარი შეცდომა: „პარამეტრიზაციის“ არარსებობა. პროგრამის სხვადასხვა ნაწილი მოდულებად იყო დაყოფილი, მაგრამ მათ არ შეეძლოთ მონაცემების ერთმანეთისთვის გადაცემა, ამიტომ ყველაფერი უნდა გაეზიარებინათ, რაც ნიშნავდა, რომ ერთ ადგილას ცვლილებამ შესაძლოა მთელ პროგრამაზე მოახდინოს გავლენა. ან მილიონობით დოლარი ერთ წამში გააქროს. ან ადამიანების სოციალური დახმარების გადახდები შეაჩეროს.
დღესდღეობით, კომპანიები, როგორიცაა IBM, ცდილობენ გაყიდონ COBOL-ის კონვერტაციის ხელსაწყოები, რომლებიც გენერაციული AI-ით არის აღჭურვილი. მაგრამ ჩვენ შეიძლება მახეში აღმოვჩნდეთ. COBOL-ის, ვთქვათ, Java-ში უბრალოდ კონვერტაცია ქმნის „JOBOL-ს“, დამაბნეველ ნაზავს, რომელიც ბაძავს COBOL-ის სტრუქტურას, მაგრამ არ გააჩნია მისი წაკითხვადობა. მე ამ AI ინსტრუმენტების უმეტესობაში დარწმუნებული არ ვარ. ისევე როგორც COBOL-ის შემთხვევაში, ისინი გვპირდებიან გამარტივებულ ეფექტურობას, რომლის გაკეთებაც ყველას შეუძლია. და ყველამ კარგად დავინახეთ, თუ რით დასრულდა ეს.
წყარო: wired.com
