Про старі технології
На фоні шуму навколо вірусу сплила тут цікава айтішна тема: виявляється в штатах у держустановах, зокрема в тих, що працюють з системами для обліку і нарахування допомоги безробітнім, дуже популярна мова програмування COBOL, створена 60+ років тому, яку давно не вивчають у вузах, відповідно й середній вік розробника на ній 55 років.
Зараз, в зв’язку з напливом безробітних, ті системи не справляються, а для їх супроводу не вистачає людей, бо розробників знайти дуже тяжко.
Бачив багато айтішників почали жартувати на цю тему, бо здається ніби технологія така древня, що там археологічними розкопками треба займатися та скелети оживляти.
Але чи дійсно все так погано, і старі технології - то щось таке, до чого не можна дотикатись, бо сам інфікуєшся та скелетом станеш?
Коротко про історію COBOL я згадував в своєму пості в телеграм-каналі від 8 березня цього року. Цю мову створили щоб замінити сотні інших мов, які вже використовувалися в 1950-х в США. Вона цікава тим, що її синтаксис наближений до англійської мови, у тому числі й завдяки словарному запасу - понад 300 зарезервованих слів. Для порівняння - сучасні мови програмування зазвичай мають кілька десятків таких слів. Лідер лаконічності - мова Go, що має всього-навсього 25 ключових слів.
Незважаючи на таку багатослівність, COBOL як мова програмування не виглядає чимось надприроднім - особисто мені вистачило кілька хвилин щоб проглянути на вікіпедії опис і бути в змозі читати код якихось нескладних прикладів, розуміючи при цьому кожну конструкцію. Дуже сподобалася ось ця стаття про елегантність COBOL - раджу прочитати її, висновки автора в кінці мені вельми імпонують.
То власне, чи дійсно це так страшно, що мова розроблена аж в 1959, і це прямо такий динозавр з яким не можна зв’язуватися? Насправді виглядає все зовсім не так погано. По-перше, COBOL продовжує підтримуватися і розвиватися. Скажімо ООП в ній з’явилося в 2002 році, а останній стандарт мови випущений у 2014. Звісно, з того часу минуло шість років, але навіть у найпопулярнішої мови на сьогодні JS була пауза в 10 років між випуском версій стандарту. По-друге, COBOL дійсно елегантна мова, і той факт, що на ній написано величезну купу коду саме цим і пояснюється, якби на ній розробникам не подобалося писати, то давно вже знайшли б заміну.
До речі, якщо говорити про найпопулярнішу зараз у світі мову - JavaScript, то в її основу покладений діалект мови Lisp, що вийшла у 1958 році - за рік до появи COBOL. То хто тут справжній динозавр? :)
Продовжимо тему - чи дійсно в сучасних нових мовах з’являються по-справжньому нові речі, яких не існувало десять чи двадцять років тому? Я вас здивую, бо відповідь - ні, по-справжньому нові не з’являються. Бо фундаментальні теоретичні основи програмування були закладені ще до появи комп’ютерів у тому вигляді як ми їх знаємо, а подальша еволюція лише будувала більш високорівневі абстракції поверх цього фундаменту. Мабуть найбільшою інновацією останніх десятиліть була поява об’єктно-орієнтованого програмування у кінці 1970-х, і в масові мови програмування воно пробиралося ще років десять-п’ятнадцять з моменту появи в лабораторіях вчених. А от цікаво, що така річ, як збірник сміття була винайдена у 1959 році - одночасно з появою COBOL. Знаючи про це, залишається лише з посміхом згадувати, як Sun запускала Java у 1995 році, називаючи підтримку ООП та автоматичне керування пам’яттю як найбільш ключові особливості нової мови.
Цікаво, що загальний напрямок, в якому намагають розвивати програмування - це його спрощення для розробників, зокрема в тому щоб писати лаконічніший код. Але викидати щось з існуючих мов дуже складно, бо це відразу ламає все написане раніше. Тому конструкції для спрощення додають в існуючі мови, часто породжуючи якихось монстрів.
Наприклад, мова C++ утворилася як розширення мови C за рахунок додавання до неї ООП. Але утворився такий собі Франкенштейн, що навіть Алан Кей, винахідник ООП, у 1996 році сказав: “я винайшов термін “об’єктно-орієнтований”, але не мав на увазі C++”.
Проте створювати мови з нуля ще проблематичніше, бо їх треба розкрутити. Ну от, наприклад, мова програмування D створена як альтернатива C++ без необхідності зворотної сумісності із C. Мова красива, елегантна і недоліків C++ позбавлена. Однак має свій фатальний недолік - на ній ніхто не програмує, бо в мовах для програмування, точно також, як і в мовах для спілкування людей, дуже сильними є традиції.
То типовий розвиток мов програмування виглядає таким чином: якщо існує якась поширена мова, що відповідає своєму часу, то її автори стараються “осучаснювати” її, додаючи нові можливості, що є в трендах сучасного програмування. Зазвичай, ці нові можливості не є по-справжньому чимось проривним і у більшості випадків зводяться до синтаксичного цукру, коли для якихось типових задач у мові з’являється можливість писати більш компактний і виразний код, ніж раніше. Проте бувають речі і проривні, крім згаданого ООП можна ще назвати автоматичне керування пам’яттю - іноді такі речі складно додати в існуючі мови, і варто робити нові, але вони будуть конкурувати з тими мовами, на яких розробники звикли писати, і в цій конкуренції новачкам доводится дуже непросто.
Проте поступово нове перемагає старе. Зазвичай це трапляється тоді, коли стара мова чи фреймворк вже не відповідають сучасним трендам, а способи їх осучаснити лише призводять до складнощів у їх вивченні. Цікавим прикладом в цьому плані є Java - вона більш ніж вдвічі молодша за COBOL, однак відстає від сучасних тенденцій і її поступово витісняє значно більш хайпова мова Kotlin, що працює на тій же платформі JVM
Нерідко історія рухається по кругу. Наприклад, модний наразі фронтенд-фреймворк React мав два способи створювати компоненти - за допомогою класів та за допомогою функцій. Перший варіант був основний протягом тривалого часу, а другого радили уникати. Проте з часом рекомендації змінилися на протилежні, і віднедавна, з появою React Hooks на перше місце виходять саме функціональні компоненти.
Цікаво, що ця тенденція стосується всього ООП - спочатку його поява і підтримка мовами програмування сприймалася як беззастережне благо, але потім, з часом від нього почали відходити, і сучасним трендом є функціональний підхід, який часто вступає в протиріччя з ООП.
То повертаємося до теми - як бачимо, не так важливий рік появи технології, як те, чи вона продовжує розвиватися, є на неї вакансії, і як добре готові платити за роботу. Проривні новації в програмуванні за останні роки можна перелічити на пальцях однієї руки, а тому не слід думати, що більш старі технології поступаються сучасним настільки сильно, наскільки кінна повозка гірша за Теслу. Більшість концепцій будуть абсолютно тими ж самими - функції, змінні, цикли, масиви і т.д. і т.п. Як правило, відмінності у синтаксисі та загальних підходах до роботи. І часто найгірше, з чим доводиться мати справу - це неякісний код, з поганими архітектурними рішеннями, купою милиць і тому подібне. Але це, насправді, від мови не залежить, а від рівня розробників, які її використовували.
Якщо ти справжній розробник, тобі по великому рахунку не має бути різниці, на чому саме програмувати - важливо, щоб платили добре, задоволення від процесу було і перспективи теж. Часто найбільші проблеми у старих технологій з останнім пунктом, однак ніщо не заважає насправді на роботі працювати з одним стеком, а вільний час робити якісь пет проджекти чи контриб’ютити в опенсорс на іншому.
Як правило, проблема зі старими технологіями в іншому. Мені особисто часто доводилося міняти стек з одного на інший, і кожна така зміна йшла на користь. Проте я бачив людей, які застрягають в якомусь стеку, і це навіть не так важливо, сучасний він чи ні, проблема в тому, що ти навмисно обмежуєш себе вузькими рамками, і не хочеш побачити той світ, що є навколо. Наприклад, часто бекендщики уникають взяти і по-справжньому вивчити JS, сподіваючись що їм він ніколи не знадобиться, шукають якісь альтернативи, щоб і мову нову не вивчати, і на фронтенді щось корисне робити.
От зараз дотнетчики в захваті від Blazor, за допомогою якого Microsoft обіцяє в черговий раз, що їм не доведеться вивчати JS. Минулого разу то був Silverlight, на якому я сам сидів до того моменту, поки його взяли і не прикрили. Але навіть якщо Blazor і буде успішним, то за весь час розвитку фронтенду вийшла така купа різних бібліотек, туторіалів та інших матеріалів, що він навряд чи порівняється навіть з незначною частиною того неосяжного всесвіту, що є у JavaScript. І обмежуючи себе у вивченні JS ти прирікаєш себе сидіти в тих межах, які намалювали тобі розробники твого поточного стеку технологій.
То справжній інженер - це не той, хто опанував якусь одну технологію, без різниці - стару чи нову. А той хто відкритий до інших світів, не замикається на одному якомусь стеку і постійно вчиться новому, навіть якщо воно з минулого. Якщо спробувати згадати мови програмування, на яких програмував, то це Асемблер, бейсік (QBasic та VBasic), паскаль (Turbo/Borland/Delphi), C#, JS, TypeScript, Java, Python, C/C++, FoxPro, bash і навіть на Prolog - і це згадав лише те, чим займався більш-менш серйозно. В основному лише те, за що платили мені, і не включав фреймворки чи те, що мовами програмування не називають, типу HTML/CSS чи SQL. То якби мені персонально запропонували якийсь ну прям дуже цікавий варіант з COBOL, то я б серйозно про це подумав, а насміх не піднімав би точно.
PS. Для тих, хто не знає - я проводжу унікальний курс ScriptJedi42 в онлайн-форматі, де протягом сорока двох днів практики ми вивчаємо весь сучасний JavaScript як мову програмування. Курс проводжу я особисто і переглядаю кожен рядок коду, який пишуть його учасники, даю свої рекомендації до того, як його робити найкращим чином, застосовуючи сучасні практики. Групи стартують раз в кілька місяців, але якщо зареєструватися заздалегідь, то відразу надається доступ до всіх завдань і матеріалів, можна почати готуватися до старту найближчої групи у власному темпі. Випускники курсу показують високі результати, раджу познайомитися з відгуками на сайті.