Про вибір мови програмування

Чесно кажучи, питання про вибір мови програмування переді мною не стояло ніколи, інакше кажучи, вибір мови програмування для мене завжди був очевидним. Я ніколи не брав участь у холіварах типу C++ vs. Java, настільки популярні наприкінці 90-х у тому самому Новософті. Справді, коли на ти на власній шкурі бачиш збільшення продуктивності в рази, будь-які суперечки стають безглуздими.

Та й взагалі, як я зауважив, у подібних суперечках беруть участь лише люди, які побували лише на одному боці предмета даної суперечки, що, можливо, і непогано, коли йдеться про одностатеві шлюби, але зовсім непрофесійно (можливо звідси випливає фейл усіх спроб створити неформальні тусовки програмістів у форматі алко-холівар – професіоналів у такому форматі зібрати не вдасться).

Ну так ось, питання про вибір мови програмування, мене мучить останній тиждень, і вперше за 20 років моєї професійної діяльності (та дітлахи, я вже 20 ебаних років заробляю на життя програмуванням, і тільки програмуванням). Чому ж зараз? Відповідь лежить у одному слові – Scala.

Звичайно про Scala я почув не минулого тижня, в 2008 році ми в конторі почали відчувати що Java вже не торт (все природно пізнається в порівнянні) і почали замислюватися про мову програмування якою ми зможемо в'їхати в наступне десятиліття, власне питання стратегічне, і безпосередньо пов'язані з майбутнім компанії. Тоді ж 2008-го ми купили ще не закінчену першу книжку Odersky, в електронному вигляді, і відразу знайшли Fantom…

The Rise of Fantom

Fantom був і є охуенно. Продукт діяльності Brian & Andy Frank (я не втомлююсь захоплюватися цими хлопцями) потрапляє в ту ж нішу, що і Groovy, Ceylon, і Kotlin, але з усього перерахованого я однозначно голосую за Fantom. І в менеє для цього чіткі аргументи (які виходять за рамки цієї посади). Власне Fantom однозначно завоював моє серце 5 років тому, і ми навіть зробили IDE для Fantom (насамперед для власних потреб), припускаючи, що він буде основною мовою розробки в компанії років на 10 вперед.

Тут я зовсім не унікальний і як мені здається JetBrains рівно з тих же причин зробив Kotlin, чуваки з itemis - Xtend, Guidewire - Gosu, та Brian (SkyFoundry) - Fantom. Вони хочуть бути продуктивнішими, і для цього їм потрібна мова програмування, яка дозволить їм бути продуктивнішою. Всі ці мови на мою думку лежать в одній ніші, і дійсно дозволяють бути рази так в 2-3 продуктивнішим ніж при програмуванні на Java (це моя суб'єктивна оцінка), на чому я питання про мову програмування закрив. Ми будемо писати на Fantom, та добре.

Ах так, я забув сказати про Scala. У тому ж, не так далекому 2008, злегка охуев від побіжного прочитання незакінченої книги Одерського, я зрозумів що команду здатну писати на Scala ми не зберемо, і неважливо в якій точці світу ми їх збиратимемо. Точніше ми безумовно знайдемо програмістів здатних *користуватися* Scala, що і відбувається зараз у багатьох хіпстер-стартапах, що сприймають Scala як якусь підсолоджену версію Java і не бачачи далі синтаксичного цукру, але дякувати Богу, ми не належимо до цього типу "програмістів".

Мова, як і бібліотека, фреймворк, технологія, інструмент і т.д. має збільшувати вашу продуктивність. Користування Scala а-ля Java – зменшує вашу продуктивність бо тулзи – гавно, екосистема – квола, компілятор – повільний, тощо, тощо. У нас роки йдуть на те, щоб зібрати команду гідних програмістів, здатних писати на Java, зібрати команду гідних, і здатнихписати на Scala, займе десятиліття – область пошуку звужується.

Взагалі моя думка про Scala була на той час досить скептичною. Мова, як мені здавалося, вийшла з академічного середовища, і де, як мені здавалося, було більше ресерчу на тему системи типів, ніж реального життя, відразу отримав мінус у пацанську книжку, порівняно з мовою, створеною практикуючими інженерами-програмістами, які чудово розуміють, що й навіщо їм треба, намагаючись вирішити цілком зрозумілі практичні проблеми.

Таким чином Fantom, та тільки Fantom. Тим більше, що ми швиденько побрали Fantom Runtime з Eclipse Equinox (OSGi), навчилися писати Eclipse plugins виключно на ньому, на ньому ж почали робити Eclipse-based IDE, що зробило Fantom чудовою мовою і для поточної частини бізнесу, який приносить гроші. Крім того, особисто познайомилися зі творцями мови, і переконалися, що в разі чого ми можемо впливати на її реалізацію і майбутнє.

Майбутнє уявлялося безхмарним і світлим, і це світло називалося Fantom…

Scala Strikes Back

З висоти пташиного польоту ці мови у мене потрапляють у ту ж нішу, що й JVM-based Groovy, Fantom, Kotlin та інші, але тільки народжені не літати, а плавати. Що, за великим рахунком, не змінює їх класу. Якщо хочете можете вважати Ruby і Python - дельфінами, а JVM-based речі - приматами (макаками, горилами, і орангутангами) ... ну і ще є глузування природи типу JRuby і Jython - це дельфіни, що ніби повзають.

І ось на тлі всього цього тваринного різноманіття – вона. Якби я мала пухлину, я б назвав її Scala. Маленька виразка на небі, яка зажила б, якщо нескінченно не торкатися її мовою. Сука… щось я відійшов від теми… Так от, я вважаю Scala – поточною вершиною еволюції мов програмування в моменті(Звичайно зазирнувши зараз набагато далі лекцій Одерського), і з цим треба щось робити. Власне питання стоїть дуже просто: чи варто писати наші наступні речі найпотужнішою мовою програмування, створеною на даний момент, чи не варто. Відповідь на це просте питання далеко не проста.

Мене у цьому питанні не хвилює будь-яка другорядна хрень, типу рівня розвитку екосистеми, наявність кадрів, підтримка індустрією тощо. Мене цікавить чи варто ставити на Scala за інших рівних.

Також мені не цікаво популярне сьогодні заперечення про те, що зараз можна писати будь-якою мовою і мультимовні проекти скоріше норма ніж виняток, це я знаю не гірше за вас, але так само я знаю наскільки непродуктивно зносити, наприклад Fantom з Gosu, або Scala c JRuby, незважаючи на те, що вони JVM-based. Саме все що вони мають загальне-це JVM-класи, і всі зносини обмежено цим рівнем. Іншими словами, це приблизно те, що ми мали 20 років тому, лінкуючись з об'єктними файлами писаними на паскалі, фортані, різноманітних сях і плюсах. Рівень "інтеграції" приблизно той же.

Спіраль історії

Всім відомо, що історія рухається спіраллю. Оскільки я – старий, я застав більшу частину попереднього витка спіралі, витка розвитку професійних мов загального призначення, що компилуються, та їх еволюцію від структурно-орієнтованих до об'єктно-орієнтованих. Знову ж таки з висоти пташиного польоту, та й з позицій практикуючого інженера, мені нецікава будь-яка академічна хуета типу Haskell і т.п. Індустрія попередньому витку трималася на C і C++, що має викликати сумнівів. Є ще проміжна, успішна ланка – Objective C (хоча я б не сказав, що індустрія трималася на ньому :)), згадати цю проміжну ланку дуже важливо.

Таким чином ми маємонаступну еволюцію попереднього циклу (ще раз: я розглядаю лише переможців у харчовому ланцюжку, безумовних альфа-самців у своєму ареалі проживання):

С (процедурно-орієнтований) -> Objective C (з елементами ГО) -> C++ (об'єктно-орієнтований по вуха)

Цікаві лише три ці мови. Я свідомо не вмикаю сюди Smalltalk, наприклад. Smalltalk – був початком наступного витка історії, основна відмінність поточного витка від попереднього (C/C++) – це Managed Runtime та складання сміття.

Таким чином, розвиток на попередньому витку був від C до C++, від процедурно-орієнтованої мови, до об'єктно-орієнтованої (і в той же час все ще процедурно-орієнтованої), як до вершини еволюції на попередньому витку. Що цікаво на цьому шляху з'явилися, і успішно зайняли свою нішу досить непогані проміжні варіанти типу Objective C (який, до речі, деяка школота та хіпстер-програмісти, помилково вважають вершиною розвитку людської ЯП думки, але їх я тут не буду засмучувати).

Тепер до поточного витка. Поточний виток розвитку мов програмування – просто копія попереднього. Місце С у поточному витку займає Java (ну і C#, щоб не образити .NET-людей, хоча для мене це не має ніякого значення – це як сперечатися про відмінності PowerPC та Intel у минулому – цікаво, але безглуздо).

Як я вже казав, поточний виток фундаментально відрізняється від попереднього наявністю managed runtime, та іншою стартовою парадигмою. Якщо попередній виток починався з простої процедурно-орієнтованої мови C і завершився дуже складною об'єктно-орієнтованою мовою C++, то цей виток почався простою об'єктно-орієнтованою мовою Java. Зауважте, набагато простіше ніж вершина розвитку попереднього витка (С++), і рухається цей виток, що вже очевидно,у бік шалено складної мови функціонального програмування Scala (яка в той же час об'єктно-орієнтована, як і C++ залишилася процедурно-орієнтованою). Під час руху з'являються проміжні мови з елементами функціонального програмування, типу вже названих Groovy, Fantom, Kotlin, тощо.

Дивлячись на все це блядство, я не маю жодних сумнівів, що Scala буде вершиною розвитку мов програмування на цьому витку, і займе те саме місце, що й C++ займав у попередньому. Усі проміжні речі займуть нішу Objective C. Java вже свою нішу зайняла.

Що цікаво, я поки не бачу мов, які позначили б початок наступного витка, як свого часу Smalltalk, але точно знаю, що він буде простіше ніж Scala (так само простий як С і Java), але поява його супроводжуватиме якийсь фундаментальний зсув , як і managed runtime. Нещодавно піднімаючи цю тему в конторі @_komaz сказав що можливо це буде distributed (з чим із задоволенням погоджуся, чи якась фундаментальна підтримка паралельних обчислень)…

Повертаючись до "хворого питання"

Я ніби не дарма озвучив вище всі ці думки, оскільки проводячи аналогії питання у виборі мови зараз для мене коштує ще простіше (я ніби переніс його в минуле, і не сумніваюся в циклічності історії): на що поставити? На Objective C чи C++? На Fantom чи Scala?

Відповідь не така очевидна як може здатися. Очевидно наступне: на C зроблена херова хмара величезних проектів (питання продуктивності не розглядаємо). На Java не менша хмара величезних проектів. Роблячи ставку на Java ви точно не помилитеся. Роблячи ставку на "проміжні" мови ви теж не помилитеся - вони як правило не змінюють парадигми і привносять лише корисні елементи. Ви можете злегка постраждати через слабкуекосистеми, але з іншого боку мати хороший стусан продуктивності. Загалом мені варіант зробити основною мовою в конторі щось із Groovy, Fantom або Kotlin – здається розумним ходом і безризиковим варіантом (принаймні я не побачив таких ризиків за останні 4 роки).

Думка зробити основною мовою Scala мене одночасно збуджує і лякає (наскільки можна збуджуватися і лякатися в моєму віці). Це як на початку 90-х сказати: “пацани, тепер ми писатимемо все на C++”. Звичайно, якби мені таке сказали на початку 90-х, я обоссал би стіни окропом, і сказав “круто”, пишемо. Але зараз – страшно.

C++ та великі проекти

На жаль, я не маю досвіду роботи у великому плюсовому проекті. Не його і в моїх знайомих (так на знижку), з якими я міг би поговорити. Вірніше, він є у купи моїх знайомих, але мені цей досвід нецікавий і не релевантний. Як правило вони або не стояли біля витоків проекту і не займалися питаннями комунікації між розробниками, питаннями пов'язаними зі сторонніми бібліотеками, і т.д., або допилювали ці проекти на останніх стадіях (передсмертна реанімація).

Тобто. мені соромно, але я не знаю, наскільки С++ поганий або хороший як основна мова в конторі. Він безумовно хороший для маленької (що спілкується на одній хвилі команди) та індивідуалів. Оскільки в кожній команді з'являється “свій” С++, кожен проект набуває певних індивідуальних рис. Java позбавлена ​​цієї властивості, як і C (якщо ви, звичайно, не робите бізнес на макропідставах). Користуючись Scala у мене немає сумнівів, кожна команда винаходитиме свій Scala-діалект, що позначиться болем у дупі.

Власне я чекаю на весь той же список проблем, який видно в C++ проектах, і йдеться навіть не про внутрішні проблеми, а про зносини із зовнішнім світом (згадайтескільки ви бачили реалізацій рядків у плюсових проектах? Роблячи ставку на Scala я чекатиму чогось подібного, але трохи на іншому рівні абстракції)

На завершення можна глянути на список проектів написаних на C++ від дідуся Страуструпа – не такий вже й вражаючий список, принаймні я впевнений, що аналогічний список С-проектів був би на порядок довшим.