Про побутову оману

Кожному іноді доводиться роздумувати над тим, що ж відбувається в ІТ, як воно буде далі розвиватися, і як потім з цим жити. Хотілося б відповісти на статтю «Думки про ідеальну мову програмування».

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

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

А про всякі картиночки типу цієї мало хто згадує, а якщо і згадують, то думають про них тільки погане. Тому що справедливе обурення. Тому що обурення. Бо як це так, хіба можна викидати з мови фічі, хіба можна відмовитися від foreach? І взагалі, що це за розвиток такий, якщо фічі зникають? Сумісність втрачається. Позначте @ Deprecated як @ Deprecated.

З іншого боку, виникають питання. Чи всі читали величезний language reference своєї улюбленої мови від кірки до кірки? А якщо читали, то скільки відсотків запам'ятали? Чи так потрібно мати стопіцот видів циклів? Чи дійсно потрібно кожне улюблене натовпу бібліотечне рішення впроваджувати в мову?

Володіння ідеальним виконавцем і практична відсутність співпромату (про порядок складності тільки на співбесідах згадують) призвело софтверну індустрію до стану, в якому магістральним перебігом у міркуваннях є експансія. А якщо точніше, не експансія, а експлозія. Боротьба зі складністю завдань складністю інструментів, за допомогою яких ці завдання вирішуються. Звичайно, багато хто від цього виграє. Зарплати зростають. Що ще потрібно?

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

Звичайно, у всьому цьому можна знайти позитивні прагнення, які за фактом залишаються такими ж віртуальними, якими вони постають перед компілятором.

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

А в іншому, все як завжди, індустрія ІТ йде слідом за бізнес-тенденціями, реалізуючи автентичні засоби вирішення проблем бізнесу методом суслика просто тому, що бізнесу потрібен мінімально значущий продукт. Поступово це призводить до того, що і сам ІТ-бізнес стає мінімально значущим. Коли і де компанії виривалися в лідери, тому що витратили 80% ресурсів проекту на архітектуру, а 20% ресурсів на розробку? Вже смішно, чи не так?

Цікаво, що і коли має відбутися у світі, щоб експлозія зупинилася? Можливо, колапс економіки? Не можна такого бажати, це смерть і страждання багатьох людей, буде вже не до ІТ. Може, метеорит? Гарний, придатний засіб проти гегемонів. Але ми ж у 21-му столітті, розумні освічені люди. Прагнемо наукового і формального мислення. Може, треба бажати еволюційного стрибка людського виду? Але це довго, а комп'ютери здатні виконати помилковий код за наносекунди. Скільки разів вони його виконають, перш ніж свідомість людини алгоритмічного підвищиться на 1%? Скільки ще раз впадуть супутники і заглухнуть двигуни Боїнга після виходу за межі сишного масиву?

А ви в курсі, що ПЗ для супутників пишуть на Модулі? На тій самій, з 80-х, яку Ніклаус Вірт створив, просто відсікаючи все зайве. Хлопці з Excelsior Jet досі підтримують свій XDS, значить це комусь треба. Отже, супутники, які не прощають помилок, заохочують Модулу?

А що можна протиставити тим, хто не заохочує? Нічого. Треба шукати ніші, бігати по норах, як ссавці в пізню епоху динозаврів. У динозаврів домінування, і нікому вже немає діла до ваших алгоритмів і циклів Дейкстри. Ну і що, що мозок (два мозки) розміром з горіх, адже все працює. Процеси йдуть, контракти укладаються. І не те щоб сильно хотілося контрактів. Хочеться, звичайно, примус голодом для всіх однаковий.

Ніхто не примушує до Оберона. Особливо в школах. Особливо в початкових класах. Не потрібно вчити Оберону з початкових класів. І школярі з алгоритмічним мисленням не потрібні. І проста мова не потрібна. І мільйони готових алгоритмістів не потрібні. А кому вони потрібні, за копійки-то? А як інакше, за що тут багато платити, адже просто все, таке я і сам зроблю. Де там моя книжечка «Програмування для непрограмістів»? Ще навчимо на свою голову розуміти алгоритми і дамо просту мову, так вони ж всі без нас почнуть програмувати. Не дуже райдужно. А потім не захочуть писати на Java. Скажуть, неякісно зроблено, провали в концепціях бачити почнуть. Зайві фічі критикувати. Недобре це. Як кажуть, після вивчення Оберона, вивчення будь-якої іншої мови це вивчення її (іншої мови) недоліків.

Як же так, мова проста, компілятор ще простіше. І операційна система виходить проста.

І інтерфейс користувача простий. А сторінка проекту взагалі проста. Все це досить просто, по-спартанськи. І хустка FPGA така ж. Прості речі не привертають уваги.

І ця стаття ніяк не є закликом взяти і пересісти на Оберон. Як казав Ніклаус Вірт:

Багато людей належать до стилів і мов програмування як до релігійних конфесій: якщо ви належите до однієї з них, то не можете належати до іншої. Але це помилкова аналогія, і вона свідомо підтримується з причин комерційного порядку.

А після того, як ви закриєте цей непоказний текст, якому явно не вистачає виразної і серйозної аргументації, і взагалі, що курив автор, почитайте цю статтю, вона про простоту: issuu.com/xcelljournal/docs/xcell_journal_issue_91/30?e