Category: it

Будущее программирование

Я тут сделал доклад в JetBrains (внутренний, сорян) про будущее IDE. И после доклада было много вопросов из серии “Но ведь будущее определенно за Х, а вы его даже не рассматриваете”. Отвечаю.

— Почему вы не делаете IDE для браузера?

Visual Studio Code Online
Visual Studio Code Online

Делать IDE в браузере особого смысла нет. Да, лет десять назад, на волне успеха Google Docs всем казалось, что сейчас вообще все переедет в веб: и фотошоп, и обработка музыки, и монтаж видео, даже игры пытались. И, разумеется, программирование. Оказалось (внезапно, да) что браузер это довольно неудобная и ограниченная фигня и сидеть в нем добровольно никто не хочет. То есть это и так было понятно, просто лет десять назад казалось, что щас гугл с майкрософтом напрягутся и подтянут веб до нужного уровня. Тогда думать так было нормально. Сегодня это уже наивно, потому что мы видим, что по факту никто ничего никуда не подтянул, наоборот, закручивают гайки и делают из веба платформу для документов. 

Ну и десять лет назад, может быть, кому-то и казалось, что веб это дивный новый мир, но сегодня уже совсем не так ясно, зачем вообще лезть в браузер? От попадания туда у приложений не возникает магически каких-то волшебных свойств, которые невозможно было бы организовать на десктопе. Наоборот, многие полезные свойства гарантированно теряются: шорткаты сильно ограничены, drag-n-drop, файлы, интеграция в систему, перформанс. Зачем, мистер Андерсон, зачем? Если будущее приложений (вообще любых, кстати) и лежит где-то, то точно не в браузере.

— Но ведь есть WebAssembly!

Естественно, в таких дискуссиях неизбежно всплывает веб-ассемблер. Что тоже мне не очень понятно: веб ассемблер это такой способ запустить C++ в браузере. Но тут мы приходим опять же к вопросу: а зачем вообще запускаться в браузере? Что там есть такого, чтобы сначала усложнять себе жизнь, а затем эти проблемы героически решать?

— Но ведь если IDE написать для браузера, ты сразу сможешь запуститься на любом устройстве?

Типа да, но то, что ты сможешь запустить, будет настолько ущербным, неудобным и бесполезным, что можно сразу распускать сотрудников и объявлять себя банкротом. Плюс это наивное представление бэкенд-разработчиков и линуксоидов, что главная проблема кросс-платформенной разработки — хоть как-то запуститься, а там разберемся.

Нет, ребята, запинать код — не такая уж и проблема. Проблема — это чтобы продукт выглядел уместно в той среде, где запускается. Чтобы вел себя адекватно. Чтобы интегрировался. Поэтому write once, run anywhere это довольно наивная утопия, посмотрите хотя бы на кошмар UI-библиотек на Java. Гораздо здравомысленнее выглядит подход Flutter, которые сразу говорят: под каждую платформу виджеты свои, пишите дважды. Да, это тяжеловато разработчикам, зато прекрасно для тех, кто будет приложением пользоваться. Оптимизировать разработку продукта под время/удобство разработчика вообще путь в никуда. А если писать UI-код под каждую платформу заново звучит страшновато, то посмотрите на разработчиков игр — они под каждую консоль просто всю игру заново пишут, иногда это даже разные команды. И ничего, живут как-то, игры выходят, оптимизируются под особенности железа, используют фичи платформы. Игроки довольны.

— Ноутбуки говно, будущее за планшетами, ультимативной мобильностью и работой из купе поезда Москва-Владивосток. А что, разве нет?

Да, раз в год в интернете очередной персонаж объявляет год отказа от ноутбуков и программирования на айпаде. Да, так можно сделать. Можно найти способ, придумать, извернуться. Вопрос только: зачем?

Да, когда вышел iPad, никто не понимал, зачем он нужен. Да что уж, тогда и про смартфон было не все понятно. Да, были мысли, что за iPad-ом будущее. Были мысли, что сейчас везде всунут тачскрин, каждый ноутбук станет трансформером, майкрософт вон вообще придумывало, как так извернуться, чтобы приложения работали сразу во всех условиях одинаково. 

Но время прошло. Айпаду уже почти 10 лет, и за это время стало понятно, что у каждого из устройств есть свой sweet spot. Для телефона это приложения, доступ к которым нужен на бегу. Для ноутбука — серьезная офисная работа. Для планшета — чтение и рисование? Так или иначе, у каждой задачи есть свой максимально удобный форм-фактор, максимально подходящий набор приложений, максимально подходящая обстановка. Скажем, для рисования это действительно экран с пером, а не ноутбук, не аудиоколонка и не телефон. Для прослушивания музыки — умная колонка, а айпад с ноутбуком будут overkill. А вот для программирования — десктоп с большим монитором, настоящей клавиатурой и мышкой/трекпадом. Все остальное — компромисс.

Да, можно программировать и на ноутбуке, почти ничего не потеряв. Можно программировать и на айпаде. Можно и на телефоне, наверное, и даже на часах. Вопрос же не в том, как может извернуться человек. А в том, что вот перед вами программист, решивший остаток своих дней посвятить созданию программ. Предположим, чисто гипотетически, что например IntelliJ IDEA УЖЕ существует для всех на свете возможных платформ, включая MiFit. Так вот, зачем, какая сила даже чисто теоретически может этого человека заставить выбрать устройством работы с кодом айпад, а не нормальную рабочую станцию? Даже при прочих равных. Ну не сможет он, бедняга, поехав в отпуск и оставив ноутбук на работе, поправить десять строчек кода. Сможет только (и будет) смотреть мультики с детьми. Настолько ли это большая проблема? Настолько ли частая? И та ли эта ситуация, вокруг которой мы должны строить будущее для всех остальных?

Спасибо, кстати, что хотя бы никто не спросил, почему мы ничего не планируем для VR-а.

— За чем же тогда будущее? На что ориентироваться?

(окей, это я уже сам себе вопрос задаю, хочется какой-то позитивный месседж в конце оставить)

Есть несколько универсальных констант, на которые можно ориентироваться всегда и никогда не прогадаешь. Это так же верно сейчас, как было 10 лет назад и как будет через 10 лет.

Во-первых, компьютеры никуда не денутся именно для программистов. Может быть, часть каких-то приложений будет постепенно уходить с них на другие форм-факторы (телефон, планшет, часы), но не IDE.

Кросс-платформенная разработка важна как минимум для трех главных платформ: macOS, Windows, Linux. Пользуясь случаем, хочу напомнить, что настоящий язык по-настоящему кросс-платформенной разработки — никакая не Java, и все еще не JavaScript и уж конечно не WebAssembly, а C++. Вот уж что-то, что действительно runs anywhere.

Скорость всегда будет одной из главных фич любой программы, и уж конечно IDE. Взлет Sublime Text, Atom и VS Code связан не с успехом JavaScript, а с тем, что ждать, пока запустится Visual Studio/XCode/Eclipse/IDEA нет ну никаких сил. Если хотите расширить доступность вашей IDE — надо не выпускать ее под iPad, а лучше снизить потребление памяти вдвое. Пользуясь случаем, напомню, что по части скорости обскакать Atom/VS Code все еще есть куда (с Sublime Text уже сложнее).

Наравне со скоростью всегда будет цениться хороший UX. Буквально, если вам нужно ворваться на рынок IDE — просто берете и делаете нормально. Тут как-то даже и конкуренции особой нет.

Вот, например, я потихоньку собираю скриншоты проблем в Idea и VS Code (для отдельного поста):

Пользуясь случаем, напомню, что количество фич ≠ хороший UX. Мало сделать правильные фичи, нужно еще удержаться и не делать неправильные/ненужные/бесполезные. Feature bloat — анти-фича, и это как раз та дыра, куда сейчас летит VS Code. У них слишком много рук и слишком много свободного времени, поэтому на запуске она уже выглядит как зведолет. А значит, это еще одна возможность обскакать лидера рынка.

В общем, если будете вдруг делать IDE — успехов!

pub mod fiasco

Лучший язык, в котором правильно сделаны модули (ну или неймспейсы) — Кложа. Один файл === один неймспейс. Неймспейс может называться только так, как называется файл, и никак иначе. И лежать он должен тоже ровно по пути пакета. То есть (ns me.tonsky.hello) может и должен лежать в me/tonsky/hello.clj и нигде иначе. Сначала меня это почему-то напрягло — эй! свободу ограничивают! а как же самовыражение??? Это при том что в остальном Кложа — довольно либеральный язык и позволяет любую другую дичь творить спокойно и вообще говоря это чуть ли не единственное место, где абстракция «как организовать свой проект на файловой системе» протекла в язык, который, вообще говоря, весь такой интерпретируемый, динамичный, код может есть с руки и про файлы ничего не знает.

Но потом я проникся и оценил, особенно когда в других языках поработал. Кайф в том, что это не позволяет разводить бардака. Потому что в жизни, даже если все люди хорошие, рукопожатные и намерения у всех без исключения самые добрые, если бардак физически что-то не мешает развести — его разведут. Ну вот Кложа мешает. Живите с этим. И живут! И как живут!

Тут-то судьба забросила меня в Балтийское море, на остров Котлин. У Котлина какой основополагающий принцип? Если где-то что-то запрещают, у нас разрешают! Все обиженные, обездоленные приходите к нам и творите что хотите. Этот же принцип применен и к файловой системе. В Джаве ведь как? Один файл == один класс. Какое расточительство! В Котлине один файл == сколько угодно классов, объектов, функций, констант и чего угодно еще. Более того, файл может объявлять объекты в пакете, в котором он даже не находится. То есть какой-нибудь src/main/kotlin/me/tonsky/hello.kt может спокойно объявлять package go.fuck.yourself; и никому за это ничего не будет!

Что же тут не так? Помимо самоочевидного бардака, становится довольно сложно понять, где что находится. Скажем, ищу я класс me.tonsky.Draggable. Смотрю в me/tonsky/ папку а там layout.kt, main.kt и scene.kt. Ну офигеть! Класс может быть в любом. То есть на самом деле это не один файл содержит множество объектов. Это один модуль размазан на несколько файлов с ничего не говорящими названиями. Разница тонкая, но существенная.

Вы, конечно, скажете: дисциплина, братан! Большие, важные классы рассовывай как в Джаве, по классу на файл. А всякую мелочевку и сопутствующий хлам клади там же рядом, чтобы файлов не плодить. Но это ведь еще хуже! Большие классы я как-нибудь уж запомню, а вот маленькие вещи хотелось бы как раз уметь находить как-то более предсказуемым способом.

Все это, конечно стимулирует продажу IDE от одноименной компании, но почувствуйте разницу! Язык, разработанный на деньги IDE вендора, и язык, который при разработке не предполагал, что у вас вообще будет какой-то редактор (а судя по форматированию классов в clojure.lang писал его Рич в блокноте и пропорциональным шрифтом).

А потом вскрывается еще одна беда — разные файлы-то, получается, срут в общее пространство имен! То есть если ты в oops.kt написал val default = 1, то у тебя вдруг перестал работать wtf.kt про который ты даже не слышал, просто потому что он тоже определил val default = 0 когда-то а в алфавите W идет после O. Никакой изоляции. Не будешь же, в самом деле, по папке с одним файлом заводить на каждый класс. Сомнительное, короче, удобство.

А потом я пришел в Раст. Его систему с модулями я настолько не понял, что специально сейчас сидел перечитывал. Итак:

Официальная документация объясняет как объявлять модули, в том числе вложенные, внутри одного файла. Объяснению посвящены четыре главы из пяти. Очень подробно и наглядно объясняется все, кроме того, зачем кому-то когда-то это может в принципе понадобиться. Естественно никто так не делает.

Раст, как и многие начинающие программисты, живет в заблуждении, что модули бывают вложенными. И что эта вложенность может быть зачем-то нужна, что модуль-родитель и модуль-ребенок связаны чем-то большим, чем общим префиксом имени.

Как следствие, Раст позволяет ссылаться на над/под-модули с помощью относительных путей. Я тоже думал, что это давно пройденный урок и уже все без исключения на планете знают, насколько это хреновая идея: относительные пути не ищутся, легко путаются, плохо рефакторятся, плохо копи-пастятся и вообще слишком хрупки и зависимы от контекста, чтобы экономия пары-тройки букв оправдывала их существование. Просто сразу нет.

Раст позволяет импортить как модули, так и отдельные типы. Причем синтаксис общий. Что создает еще больше путаницы. Модуль — это неймспейс, средство изоляции имен, не больше. Тип — это уже что-то полезное. Давайте уже как-то разделять.

Видимо, по старой доброй C-традиции, в Расте сделали include вместо import. То есть когда ты говоришь use module, ты не просто создаешь некий синтаксический псевдоним, действующий исключительно до конца файла для разрешения имен. Нет, ты буквально добавляешь все что было в module в текущий файл. Не сослался, а скопировал и вставил себе. Это плохо, потому что вместо понятной модели «есть штука, она одна и существует там, где написана, плюс есть способы сослаться на штуку, псевдонимы, они могут быть любыми» мы получаем «одна и та же штука, размноженная N раз в N местах». А я еще удивлялся, почему одни и те же функции и из std::, и из core:: торчат. Вот почему!

Ну и на вишенку, модуль определяется не в том файле, где он написан, а в его родителе! Скажем, если вы сделали govno.rs, и написали в нем код, вы потом идете в lib.rs и в нем уже пишете mod govno;. Или, если хотите, определить его публично, pub mod govno;. То есть понимаете, да? Если вам интересно, торчит ли govno.rs наружу, вы не можете зайти в него и посмотреть. Вам нужно сообразить, кто его родитель, найти в этом родителе (в произвольном достаточно месте) надпись mod govno; и там узнать, есть ли префикс pub у него. Если вы хотите создать какой-то достаточно глубокий модуль, скажем, kak::zhe::vse::zaebalo, вам нужно пойти и создать всех промежуточных родителей и в каждом написать ровно по одной строчке:

lib.rs:
pub mod kak;

kak.rs:
pub mod zhe;

kak/zhe.rs:
pub mod vse;

kak/zhe/vse.rs:
pub mod zaebalo;

kak/zhe/vse/zaebalo.rs:
<your code here> 

В каком-то смысле это все следствие относительности имен и «удобства» их использования. В каком-то — следствие концепции вложенности. Этот пример прекрасно ее иллюстрирует: слишком много возни, слишком много вопросов, а в чем профит не ясно. Скажем, если модуль kak будет публичным, zhe — нет, vse — тоже нет, и наконец zaebalo — публичным. Смогу я его в конце концов заимпортить? Если нет, то в чем смысл pub в pub mod zaebalo;? Если да, то в чем смысл того, что промежуточные модули — приватные? И сколько файлов мне придется посетить, чтобы вычислить, доступен ли zaebalo для импорта?

Короче. Я не очень понимаю, как тут можно запутаться, но опыт показывает что путаются все и постоянно. Модули — плоские. Пути — абсолютные. Один файл === один модуль. Все, что надо знать про модуль, написано в нем самом. Будете делать свой язык — смотрите не объебитесь.


С высоты-3

Пост вызвал некоторую дискуссию, в связи с чем я не перестаю удивляться, насколько людям кажется что мир устроен так как им хочется а не так как он устроен на самом деле. Многие живут мыслью что то что они (ну или я) пишу это не настоящая Кложа, а где-то там далеко есть настоящая, и если сильно припрет то взял type hints и поправил и так-то и пишут настоящие джедаи. У них все всегда сразу достигает JVM-уровня скорости потому что они сразу везде указывают примитивные лонги и вообще все специфицируют и раскладывают сразу оптимально. Ну или разложат если будет нужно.

Я тоже так думал и даже рекламировал этот троп когда-то. Многим показалось, что мы как-то не так написали программу и поэтому она весьма посредственно работала. Типа, был выбор, писать быстро и писать медленно, и мы выбрали медленно, но был еще вариант быстро и мы его не взяли и это наша ошибка. Не то что мы специально не взяли, мы может и не знали, но нормальные программисты на нашем месте бы увидели и взяли и все бы у них было хорошо.

Так вот. Я сам не то чтобы чужд оптимизациям и натягиванию ужа на ежа. Я потратил достаточно много времени, пытаясь делать разные вещи быстрее, чем они есть. Придумывал какие-то оптимизированные defrecords в DataScript. Менял функции на макросы для инлайнинга. Городил макро-DSL для работы с массивами. Писал макросы, которые эмитят сразу оптимальный JS. AOT-прекомпилял Кложу в классы для быстрого стартапа. Видел тоже разного: всякие библиотеки для быстрой математики, патченные исходники с отложенной инициализацией var-ов, фоновые «прогретые» JVM для быстрого старта. Даже мантра «держи репл всегда запущенным» в общем-то про то, как бороться со тормозами на старте Кложи. Про все это можно сказать одно: это очень изнурительно, и удовольствия в этом никакого нет, только сложность и постоянное разочарование.

И в какой-то момент меня отпустило и я стал относиться к этому гораздо проще: вот есть язык, он предлагает такой вот способ писать программы. У этого способа есть определенные преимущества, какие-то, может быть, недостатки, и определенная цена, в том числе по производительности, которую все осознавали когда делали язык или выбирали его себе. И вот это просто место, с которым надо смириться, зафиксировать, что да, это осознанное решение, мы платим цену, и платить ее. Не пытаться обмануть систему. Не пытаться делать из того, чем язык является, то, чем он не является. Это всегда выходит дороже, сложнее, бесконечно коряво, недоделанно и в конечном счете не стоит усилий. Если бы был нормальный способ не платить цену, ее бы никто не платил.

Но если уж ввязался, то просто делай как все — будет проще, приятнее и честнее. Если язык предлагает records, бери и используй records, а не городи свой хитрый макрос на deftypes. Если нужно позвать функцию — значит, нужно позвать функцию. Если компилятор при этом продалбывает arity в метаданных, чтож — значит, продалбывает, такова цена. Так устроен язык. Хорошо, если это просто по недосмотру и можно отправить патч в компилятор. Если нет, что ж. Все равно нормальный, обычный код, собранный из того, что дают, в конечном счете, на длинной дистанции, выигрывает именно своей простотой и нормальностью. Потому что локальные оптимизации всегда останутся локальными и будут только мешаться под ногами непредвиденным образом; чем дальше, тем больше.

Нет особой доблести в том, чтобы задачи, которые плохо решаются, например, в Кложе, решать именно на Кложе. Мы же взяли ее чтобы было приятно программировать, а не чтобы бороться с фундаментальным устройством языка и идиоматичным кодом. Не надо пытаться писать на Кложе как на Котлине, как не надо пытаться писать на Котлине как на Кложе. Если уж взял ООП язык, то пиши уже блин классы. Конечно, попробовав ЛИСП, хочется везде засунуть неполную, багнутую, наполовину реализованную его версию, но это обещает только унылый доморощенный цирк и бесконечные головняки, ничего больше.

Какая цель была у моего эксперимента с переписыванием, если мы даже не выжали по максимуму что можно было ни из Кложи, ни из Раста? А цель очень простая — оценить не какой-то там теоретически возможный предел, который тибетские монахи могут достигнуть на языке путем десятилетней медитации. А оценить какая получается программа в среднем, когда ее пишут обычные люди в обычные, отнюдь не бесконечные сроки, и когда им нужно балансировать фичи/качество/дедлайн, а не выдрачивать микроцикл до пикосекунд.

Как верно подметил древнегреческий поэт Архилох (да, я тоже только что его нагуглил и тоже только что офигел), в критической ситуации ты не вырастаешь до уровня своих ожиданий, а падаешь до уровня своей подготовки. Ваша программа не будет написана из тысячи выдроченных микроциклов, она будет написана из тысячи самых обычных, рядовых функций, на многие из которых никто даже второй раз никогда не посмотрит, не то что оптимизации начнет расставлять. Поэтому глупо жить мечтами, что если быстрый код в принципе, теоретически, как-то где-то можно написать, то он везде почему-то будет написан. Не будет. Потому что это неудобно, противоестественно, не нужно. Из «на Кложе можно писать быстро» не следует «код на Кложе будет быстрый». Не будет.

В этом и смысл выбора наиболее подходящего языка: нужные тебе качества получаются естественно, сами собой, без борьбы против системы. Отсюда:

[...] при разработке на Кложе удобно думать в математических понятиях (а хешмэп это пожалуй самая близкая к функции структура данных). При разработке на Расте это кажется прямо-таки немного противоестственным, и хочется уже взять плоский кусок памяти, и как-то там его расчерчивать.

Язык определяет мышление, best tool for the job, вот это все. Банально, но на конкретном примере оно всегда как-то доходчивее.

С высоты-2

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

Ну и что я сделал. Я пошел учить Rust. Не, ну интересно же, как компьютеры сегодня могут, если их правильно попросить.

Чтобы потренироваться я портировал на Раст наше решение из ICFPC. Причем портировал точь-в-точь: все те же структуры данных, те же алгоритмы, те же константы. Ну разве что не персистентные: там, где в Clojure update, в Rust у меня clone() и только потом push/insert, потому что в комплекте персистентные структуры не идут, да и так идиоматичнее. Важно: я не пытался что-то улучшить, срезать углы, реализовать покрасивее, нет: я написал ровно то, что мы и на Clojure написали. Ну, чтобы сравнение было честным.

Как только мой решатель начал что-то решать, я сразу же побежал сравнивать производительность. Rust ожидаемо вырывался вперед, но не на безумные цифры. Типа, вместо 4-5 секунд на задачу решал за три. Я даже собрался уже разоблачающий пост писать, что мол язык не важен, важны структуры данных и алгоритмы, в них весь перформанс, а не в том, на каком языке вы их записали. Потом, правда, коллеги подсказали, что я забыл снять с ручника, то есть запускал Rust в debug-билде. Ну и конечно, стоило поставить --release, как скорость выросла раз в двадцать. Впечатляет, да?

Самое печальное тут в том, что это все время на одну и ту же работу. Чистый оверхед. Программа на Clojure не выдает какой-то более умный или точный или качественный ответ. Она приходит к тому же финишу, только к ногам привязаны огромные 20-кратные гири. Раст на одном ядре обгоняет Кложу на двенадцати ядрах в 3,5 раза!

Можно было бы сказать «но это же низкоуровневый язык, как на нем можно что-то писать»? Писать было непривычно, потому что язык новый, но по ощущениям ничего особенно сложного, когда научишься. Приходится внимательно следить, что в каком порядке выделяется и кто куда что передает, но в нормальной программе оно обычно и так нормально разложено. Скажем так, Раст не дает тебе развести беспорядок там, где другие языки даже бы не обратили внимания. Да, это еще одна забота, но не ужас-ужас что прям программировать невозможно. Кода кстати сравнимо, 800-900 строк.

Зато 17 раз!!!

Исходник и голые цифры. Выводы делайте сами.


ICFPC 2019

В этот понедельник закончился трехдневный марафон под названием ICFPC. Это такое соревнование, где команды программистов со всего мира пытаются на время как можно лучше решить некую задачу. В этот раз – обход лабиринтов с разным доп. инвентарем. Условия можно прочитать здесь. Это как бы отчет, но на самом деле памятка самому себе на случай, если буду играть еще через год.

Мне очень понравилось. То есть я конечно устал как собака, но есть что-то приятное в том что этот опыт а) имеет конечную продолжительность, а не тянется годами, как основная работа. И б) можно полностью отдаться задаче, не думая о том зачем это все и что ты делаешь со своей жизнью. Такой вот повод упоенно фигачить на полной скорости какое-то время, чтобы ветер свистел в ушах. Ну и просто весело.

Очень любопытно посмотреть, чего ты стоишь. В голове-то ты мог много себе про себя нафантазировать, а тут вот объективная реальность, ладдер, и ты либо можешь компьютер заставить делать что ты хочешь, либо не можешь. Никаких «если бы», никаких «возможно, наверное, мне кажется». Мы довольно посредственно выступили (на момент закрытия 29 место из 142 участвовавших, в лучший свой момент были на пятом).

Исторический скриншот. Дальше мы сильно сдали
Исторический скриншот. Дальше мы сильно сдали

Участвовали втроем, я в первый раз. Как я понял, средний размер команды ~5 человек, не редкость и восемь встретить. Втроем у нас довольно хорошо делились области ответственности, было бы больше появился бы организационный оверхед (как мне кажется). Восемь человек я бы вообще офигел менеджить и вообще ничего бы не написал, наверное. С другой стороны, больше рук – можно попробовать больше подходов. Можно вложиться в инфрастуктуру. Наверное.

Задача достаточно нетривиальная, чтобы решить ее до конца было в принципе невозможно. Но и не супер-сложная, чтобы как-то ее решить можно было бы даже иногда и руками (ну, самые простые примеры). Как правило это значит перебор вариантов в каком-то NP-полном поле, соревнование эвристик.

Собери бонусы, закрась лабиринт
Собери бонусы, закрась лабиринт

Clojure, несмотря на все плюсы языка высокого уровня и быстрого iteration time, по ощущениям подошла довольно плохо. Потому что все упирается в перформанс. Можно сколько угодно рассуждать про «глобальные оптимизации против локальных», ненавидеть байтоебство, мыслить как стратег с высоты птичьего полета и гордиться тем, что не знаешь, как устроен компьютер, но это все и в императивных языках можно делать. Они же не отнимают способности мыслить и планировать. Да, механика записи мысли чуть более многословна, ну зато оно того стоит. Плюс за три дня вы разницы может и не заметите даже. А вот по перформансу заметите, еще как. Как ни крути, а команда, которая обсчитает за условное время X в два раза больше вариантов, чем ее конкурент, будет в топе выше. КАК НИ КРУТИ. Больше здесь строго лучше. Либо больше итераций, больше вариантов попробовать, либо решения будут более глубокими, а значит и очков принесут больше.

ICFPC это как раз такой случай, когда лучше чуть больше устать но получить программу которая будет нагружать процессор по делу, а не только мусор за юзером подбирать. К тому же, как ни странно, старые императивные языки может и не очень легко позволяют до энтерпрайзных масштабов раздувать программы, но что-что а бегать по массивам и мутировать структуры они похлеще функциональных могут. Ирония – соревнование приурочено к конференции по функциональному программированию, а побеждают в нем все стабильнее C++ и императивщина.

Выглядит красиво, жаль вся эта мощь обслуживает всякое говно вроде lazy sequences, primitive boxing, high-order functions вместо того, чтобы решать задачу
Выглядит красиво, жаль вся эта мощь обслуживает всякое говно вроде lazy sequences, primitive boxing, high-order functions вместо того, чтобы решать задачу

Сейчас я думаю, что даже если бы мы выбрали просто Java с unboxed примитивами и примитивными массивами, было бы качественно лучше. C++/OCaml/Rust может быть дали бы еще 1,5-2 раза прирост, но это уже не изменило бы ситуацию качественно. Но может и нет, цифры так, с потолка.

Про типизацию – да, было определенное количество багов, связанных с опечатками и лукапами не в тех структурах. Конечно типы бы от этого спасли. Но был и интересный момент, когда под конец соревнования понадобилось кардинально поменять интерфейс решателя задач, и вот тут отсутствие типов позволило мне зарефакторить решатель, оставив генератор (вторую большую часть программы) на старых структурах. В статически типизированном языке мне пришлось бы рефакторить всю программу целиком, что съело бы ценное время. Конечно, это просто забавный аргумент, курьез, я его привожу тут только потому, что все остальные традиционные скучные примеры традиционно указывают в обратную сторону.

Да, я думаю именно в этой ситуации—сверхинтенсивной коллаборации над одним маленьким сверхчасто редактируемым куском кода—типы бы больше помогли, чем мешали — их нужно немного, по сути это структуры даже просто, которые спасли бы от глупых опечаток. В более спокойной обстановке, без цейтнота, оба примера, и опечатки, и рефакторинг, не имели бы такого веса, когда есть и тесты, и время сделать все нормально.

Кстати, многие ошибки, которые все-таки у нас были, были связаны с подстановкой переменной того же типа, где никакая система типов бы никого не спасла. Ну оно и не удивительно, когда у тебя большая часть программы, процентов 90, гоняет инты направо и налево. Это же алгоритмы.

не с этого хакатона, но смысл такой же
не с этого хакатона, но смысл такой же

Очень важно оказалось докапываться до причин каждой странности. Удивительно, на самом деле, насколько программа может как-то работать и выдавать решения, имея локальные проблемы и ошибки в каких-то местах. Почти как нечто живое, выживающее. Пару багов мы поймали просто глазами, когда увидели, что бот иногда на пару ходов ведет себя странно, хотя и решает в итоге все задачи.

лабиринты, генерируемые нашим алгоритмом, имели хорошо узнаваемый вид
лабиринты, генерируемые нашим алгоритмом, имели хорошо узнаваемый вид

Очень важна базовая гигиена. Ну там код неиспользуемый удалять, переменные нормально называть, на функции разбивать нормально где нужно, не писать по два-три раза почти одно и то же, если уже написано. Казалось бы, тоже — хакатон, вы через три дня все это выкините, так ли это важно? Вот оказалось что да. Потому что там где в обычном проекте косяки может через полгода-год всплывут, здесь если ты что-то поленился, коллега уже через полчаса об это споткнется. Причем споткнется обязательно, потому что кода мало и все используют всё постоянно. Так что лучше пять минут потерять, но поправить самому, пока контекст у тебя в голове, чем заставить коллег тебя материть и тебя же дергать. Чисто по времени выгоднее. Несмотря на.

Пилу нужно точить. Как бы ни казалось, что три дня уж без удобств можно прожить, удобства все-таки решают. Мы очень страдали от отсутствия визуализатора. Организаторы предлагали готовый, но в браузере (на ScalaJS кстати), и это не оч удобно было (для каждого запуска нужно было накликать мышкой и выбрать два раза через диалог выбора файла два файла).

Визуализатор организаторов
Визуализатор организаторов
ух как же меня бесило выбирать эти файлы каждый раз!
ух как же меня бесило выбирать эти файлы каждый раз!

Самое большое, чего там не хватало — пошагового реплея, перемотки назад и вперед, ну и доп информацию тоже иногда хочется какую-то вывести. Как разбился лабиринт, что думает бот, такое. Я написал в какой-то момент простой визуализатор через println и clear screen, он даже мультики показывал типа, но хотелось бы чего-то более удобного и универсального.

То же самое касается проверок на ошибки, на тупизну, на то что задача в принципе дорешивается. Причем желательно чтобы это был код независимый от основной codebase — какое-то довольно продолжительное время мы отправляли задачи и не знали, что часть из них тупо не принималась организаторами, хотя мы думали, что все решили. Тесты, конечно, писать некогда. Но вот ассерты, ассерты помогают. Иногда как раз такие странные косяки ловить, когда вроде и все еще работает, но какое-то ожидание нарушено, и значит где-то что-то пошло не так, как ты думал.

Приходить надо было подготовленным. У ребят, например, из контура, была инфраструктура заготовлена: сервера, гоняющие задачи, сбор ответов, дашборд, сравнение. Мы этого, конечно, не знали, у нас в лучшем случае запустил программу на ноуте — в терминал вывалился результат. Пик инфраструктуры.

Очень пожалел, что не сделали систему сбора и записи всех прогонов, чтобы из всего массива запусков периодически выбирался бы лучший вариант. Ведь если на какой-то специфичной версии алгоритма какая-то специфичная карта особенно удачно решилась, нет причин не отправлять это решение, даже если алгоритм потом менялся десять раз. Ну и сравнивать эффективность решений наглядно было бы полезно (мы потом похожую штуку сделали, но решения надо было вручную в репозиторий коммитить, такое себе).

Вторая безусловно полезная штука, которой нам не хватало — центр координации, который бы следил, какие задачи где считаются, и раздавал работу. Так можно было бы и решать быстрее (запустил на всех ноутах, и задачи считаются разные, не пересекаются), и гипотез разных потестировать, и на дашборд красиво вывести. Ведь известно заранее, что будет N задач, у каждой есть вход и выход, инфраструктура под это довольно универсальная получается.

Как правильно распределять силы я пока не понял. Я выложился по максимуму в первый день (до 6 утра, на следующий встал в 11) чтобы как можно больше впихнуть в Lightning Round (первые 24 часа). В результате весь второй день был как в тумане и работалось как на автопилоте. В третий зашли нормально, я переписал алгоритм даже, но тоже было очень тяжело. Возможно, здоровый сон каждый день (ну ок, кроме последнего) суммарно дал бы больше эффективности за три дня, чем такое.

Перерыв на обед
Перерыв на обед

В целом мне кажется, мы выступили неплохо для первого раза, но в целом неудовлетворительно. По ощущением наших сил едва хватило, чтобы выкатить самый простой жадный алгоритм с самым простым lookahead и мы даже не преступили к стадии, когда тестировали бы разные гипотезы и прочие умные идеи бы пробовали. То есть просто боролись со сложностью задачи.

С высоты

Про Clojure и что я все сильнее про него ощущаю.

В каком-то смысле это продолжение моих размышлений, куда податься после Software Disenchantment, когда я понял, что надо что-то менять, но не понял, на что именно.

Да, Clojure это прекрасный, замечательный высокоуровневый/прикладной язык, лучший на свете. Прикладной в том смысле, что на нем хорошо писать программы, решающие конечную задачу – обслуживать, например, бизнес. Ну да, таких задач большинство. И ценности у них как раз вполне конкретные. Ясность коммуникации. Изоляция-локализация частей. Предсказуемость, надежность.

Во всем этом Clojure не просто блистает, она открывает следующий уровень. Иммутабельность снижает ошибки, функции хорошо композируются, мапы удобнее классов, и т.п. Да, Clojure позволяет двигаться безумно быстро. Скажем, загрузить файл, распарсить его, разложить аккуратно по нужным структуркам – это делается буквально за несколько строк. На таких скоростях не до абстракций — загрузчик, класс, конструктор, интерфейсы, методы... все это тупо не нужно, когда ты в одном инлайн выражении, даже имен никаких промежуточных не вводя, не то что классов, можешь столько работы проделать, сколько в Джаве обычно на целый maven-пакет размазывают.

Прикладные задачи нужно писать на настолько высокоуровневом языке, насколько позволяют требования по производительности. Ну вы все видели бум электрон-приложений. Если пишешь что-то типа сайта с тремя калеками-посетителями в день, или там мобильное приложение для листания фоточек, где все привыкли к latency и самое сложное что тебе предстоит это ну максимум побороть лайаут чтобы кнопки не распидарасило, то писать как-то по-другому, по-старому, было бы глупо. И это правильно, при прочих равных, писать надо на том, на чем писать приятно. А писать на Кложе приятно очень.

Но мир интереснее и разнообразнее, а писать такое все могут. Непонятно, как там выделяться, делать что-то значимое. Лучшее, что ты можешь на такой работе – взять что дают, максимально ясно все описать и максимально аккуратно все организовать. Такие себе цели. В смысле, достойные, но не так уж и сложно, каждый второй так может.

Хочется что-то более фундаментальное, что-то, чем будут пользоваться другие программисты, что-то, что хоть немного изменит ландшафт. Элементы инфраструктуры, базовые алгоритмы, структуры данных. Основы. И вот тут уже выбирать не приходится. Они должны быть настолько быстрыми, насколько это возможно. Оправданий делать наоборот быть не может. Никто не пойдет писать базу данных на JavaScript, потому что ей потом никто не будет пользоваться, с такой-то скоростью. Ну примерно как автомобили – если ты потребитель и купил машину, можешь ездить на ней как и когда хочешь, она может годами у тебя стоять без дела, можешь пользоваться ей неправильно, заправлять не тот бензин, всем пофиг. Но если ты делаешь эту машину, то будь добр выложись по полной – каждый узел, каждая деталь должны быть сделаны на пределах текущих возможностей и по качеству, и по производительности.

Никого не волнует, насколько инженеру хотелось бы и было бы удобнее печатать, скажет, фару на тридэ принтере из резины. Важен только результат. Большинство программистов вокруг нас пишут на прикладных языках высокого уровня – они просто ездят на машинах, они потребители. Но для того, чтобы они могли это делать, сами машины должны быть сделаны максимально хорошо.

И вот меня тянет как будто все больше в эту область. Инструментов, основ каких-то, значит. А трагедия в том, что моя любимая Clojure ну никак для этого не подходит, как бы мне этого ни хотелось. Чем дальше, тем больше понимаешь, что эта чудесная простота дается не бесплатно. Просто задачи были такие, что небесплатность была незаметна. Приглядишься бывает, с одной стороны hot loop из семи залуп, а с другой внутри вдруг вылазят какие-то промежуточные сиквенсы, какой-то там pointer chasing, primitive unboxing, вспыхивают на доли секунды замыкания просто чтобы что-то найти в трехэлементном массиве с помощью функции второго порядка, для того чтобы вернуть 2д точку выделяется на всякий случай целый Персистентный Вектор, для того что бы обновить пять полей в структуре у тебя создастся и тут же выбросится четыре промежуточных версии этой самой структуры, а вместо того чтобы посчитать что-то в цикле создастся целая ленивая последовательность, которая, фиг бы с ней, посчитается позже, просто сколько же оверхеда уйдет на то, что по сути могло быть простой итерацией с одной short переменной и оперировать вообще по константной памяти, еще и последовательно уложенной.

Вот кусок, написанный на идиоматичной Clojure:

(concat
 (mapv
    (fn [y] [from-x y])
    (range from-y (quot to-y 2)))
  (mapv
    (fn [y] [to-x y])
    (range (quot to-y 2) to-y)))

Тут тебе все: и ленивость (concat), и ФВП (mapv), и лямбды с замыканиями, и бесконечные ленивые последовательности (range). Вопросов нет, это действительно нормальные, часто используемые Clojure примитивы. Я даже не могу этот код назвать не-идиоматичным. Но. Просто представьте, сколько механизмов там крутится под капотом, чтобы вся эта красивая запись отработала. А ведь все что там по сути происходит это один очень простой цикл:

Point[] res = new Point[to_y - from_y];
for (int y = from_y; y < to_y; ++y)
  res[y - from_y] = Point(y < to-y / 2 ? from_x : to_x, y); 

Я не говорю что это лучше читается или еще что-то. Просто представьте, насколько более дружественен к компьютеру второй вариант. Насколько он прямее ложится на железо. Насколько он прозрачнее, ближе к сути. Неудобно, некрасиво, некомпозируемо, зато быстро. И честно. В каком-то смысле.

Когда мы говорим о разнице между условными C++/OCaml/Rust, Java и скажем Clojure (особенно средне-идеоматичной Clojure, с коллекциями там всякими), то эта разница может быть 1 к 2-3 к 100 например очень легко. Я помню, когда решал Project Euler и учил Clojure и OCaml, то Кложе-решения мне приходилось ждать какое-то ненулевое время (ну там задачи не шибко сложные, но все же). А OCaml успевал перекомпилять (!) программу, запустить, все обсчитать и выдать ответ за время, пока Java-машина с Clojure только стартовали.

Да, язык формирует образ мысли. Так или иначе, когда язык уже выбран, поиск решения – это вертеть в уме разные варианты имеющихся в нем кубиков, комбинировать, собирать решение из того, что язык предлагает. Можно мыслить на языке. Писать идиоматичный код. Но неплохо бы еще мыслить «на языке компьютера», т.е. представлять себе цену всех этих удобств. Выбирать неуклюжий reduce комбинации из ФВП и трединга. Вынести в record то, что лежало в мапе. Сделать loop, наконец. Иногда цикл это всего лишь цикл. И никак по-другому ты его не запишешь. И это нормально. Компьютер скажет спасибо.

Но это полдела. Если уж быть до конца честным, Clojure для perf-critical подходит из рук вон плохо. Даже Java подходит с очень большой натяжкой. То есть ее конечно можно разогнать, но зачем? Зачем героически бороться, чтобы в конечном итоге все равно, пусть немножко, но проиграть, потерять что-то? В итоге все упирается в то, что лучшее что я могу сейчас делать – учить Rust. А дальше-то что? Что на нем писать-то? Непонятно опять. Проблема.

Справа налево

Не хочу специально набрасывать, но вот вчера попалось на глаза и я прям прослезился.

Смотрю, что если в столбце справа путь «abc+что-то», то все нормально. Как только что-то пропадает, «abc+» превращается в «+abc». При том что в DOM мы отдаем совершенно точно «abc+». Одним текстовым блоком. Никаких там вам флексов, это уж точно. Как так? Что-то с глазами? Как такое вообще возможно? Кто вообще посмел раздербанить мою строку, да еще по каким-то дебильным правилам, и если подобное возможно, на какие гарантии в принципе можно рассчитывать? Начитавшись Лю Цысиня, я решил, что инопланетяне нарочно играются с моим мозгом с целью свести меня с ума.

В итоге расследование привело меня типовое решение со StackOverflow. Оказывается (!) веб-разработчикам в целом как-то лень бывает городить лишний вложенный div, и они придумали: а чего бы не заабюзить свойство direction для арабских языков? Только писать в него все равно латиницей. Гениально!

Ну да, текст начинает как бы выравниваться по правому краю. Есть правда нюансы. Цифры, разделенные пробелами, переворачиваются. Знаки препинания переезжают налево. Диапазоны показываются задом наперед, от большего к меньшему.

Проблема? Проблема. Блин че делать? Читаем: you need to wrap the contained elements in another element with direction: ltr rule to reverse the effect. Классическое «придумал себе проблему и героически ее решил». Ооок.

Да, это самый популярный ответ на то, как обрезать текст слева. Да, авторы с удовольствием принимают такой ответ.

Ну и веб он весь такой. Сделают что-то задом наперед, заабюзят супер-редкую фичу из даже не смежной области, как-то где-то в каких-то тепличных условиях один раз заработало и так и оставили, а на картину в целом смотреть не интересно. Может, даже на конференции про это расскажут. Не, а что, смекалочка же.

Что случилось с GUI-фреймворками?

Это третий пост в моем квесте по поиску GUI-фреймворка для десктопных приложений. Первый, второй.

Давайте немного сориентирую, что я ищу. Для многих «GUI-фреймворк» почти равно библиотека виджетов, чем больше тем лучше. Чтобы GUI собрать из кубиков лего минимальными силами. Меня это не очень возбуждает, потому что универсальных виджетов мало, а что-то более интересное надо делать под себя все равно. Поэтому для фреймворка важнее «уметь доделать свое», чем «побольше готового».

Также популярно мнение что GUI-фреймворк это look and feel, платформенно-зависимый или же просто не вырвиглазный. Типа это сложная часть, повторить лук платформы. Мне тоже пофиг. Дело в том, что сейчас самое идеальное время для GUI-фреймворка: все наигрались в игру «сделай look and feel как настоящий» и привыкли к веб-приложениям, где вообще каждый первый сайт разный. Плюс в моду вошел flat и минимализм, то есть виджеты рисовать дешево и просто, как никогда. А платформенный look and feel это иллюзия, все равно в каждом реальном приложении миллион случаев, которые не укладываются в стандартные checkbox/input/dropdown. И чем больше приложение, тем больше надо тюнить и дорисовывать самому. UI это не лего, его надо дизайнить и рисовать как целое, тогда будет гармонично.

Таким образом, от GUI фреймворка мне бы хотелось иметь базовые сложные вещи покрытыми (платформенно-зависимая обработка ввода, скроллинг, быстрый рендеринг, вывод шрифтов, dpi handling), какие-то базовые графические примитивы (прямоугольник там, линия, градиент, тенюшечки, svg) и возможность залезть под капот и все застайлить и запрогать как хочется.

Я НЕ ищу сокращения затрат на дизайнера за счет использования готовых компонент/дефолтного look and feel. Меня интересует возможность потратить много и долго, но сделать самому и хорошо, чем кое-как и из готового. Pixel-перфект и именно так, как мне нужно, а не так, как автор фреймворка сделал и сейчас уже хрен отковыряешь. Качественное вылизанное end-user приложение, а не дешево выглядящий массово производимый enterprise.

UPD: Ну и не надо учить меня программировать. Наверное навязывать там свой MVC или VDOM или что сейчас модное и свежее сильно не стоит. А то мода меняется, а фреймворк должен выжить.

То есть нужны идеально композируемые низкоуровневые примитивы без look and feel.

Чтобы не повторять ошибок истории, надо их знать. Я не знаю. Поэтому мне нужна ваша помощь: расскажите, что да как, коротко, доходчиво, грубо. Вопросы конечно кажутся философскими, но нужны именно конкретные инсайты. Ответ «WPF гААААвно» не нужен, он не конкретный и непонятно, в чем конкретно затык, а вот «в WPF нельзя было делать мультидокументные приложения, поэтому он сошел на нет» (например) очень хороший ответ.

Вопросы примерно такие:

— Почему у Java не получилось AWT?

— Зачем понадобился Swing? Что принципиально изменилось по сравнению с AWT? Я так понимаю AWT пилился на C++, а Swing на Java? И стало лень писать по версии под платформу?

— Почему Swing плохо работает? Это косяк реализации или какая-то принципиальная проблема? И в чем именно заключается это «плохо работает»? Тормозит? Разъезжается? Что?

— Что за история с JavaFX, зачем он был нужен, зачем начинать опять новый фреймворк, какую принципиальную инновацию по сравнению со Swing хотели привнести (неужели CSS?) и что не задалось? Почему ноль интереса? Все разочаровались?

— Есть ли какой-то принципиальный затык в реализации кросс-платформенных GUI? У веба вроде бы получается, почему больше ни у кого нет?

— Почему Windows переизобретает свой тулкит в каждой версии, а macOS живет на Cocoa десятилетиями?

— Какое положение занимает QT? Я так понимаю что он C++ и bloated, то есть нацелен больше на энтерпрайз?

— Flutter подход выглядит а) разумно и б) достаточно правдоподобно в) не как говно. То есть поднять свой GUI тулкит с нуля вполне можно и можно даже достаточно убедительно сэмулировать нативный look-and-feel. Почему ни у кого больше такое не получалось?

— Если брать не только кросс-платформенные GUI, то какие есть киллер-фичи, которых больше нигде нет? Что незаменимо и неповторимо?

— UPD 2: Я читаю, что в JavaFX вводится Scene Graph, а в Swing все на JPanel. При этом разница ускользает от меня. Чем принципиально отличаются подходы? (кроме названий классов)

— UPD 3: Я ничего не знаю про tcl/tk, но многие вспоминают его с теплом. Почему?

В общем, интересует история развития мысли и инсайты. Истории вроде «взяли ту же идею и понадеялись что сделаем лучше, а получилось то же самое» — не интересуют. Ну потому что а что вы ожидали? Истории «у фреймворка Х была вООООт такая амбиция (какая?), но он разбился о такую проблему (какую?)» — интересуют очень.

Если вы работали с GUI кроме веба, расскажите, что там у вас была за история?

Пациент умер, выносите

Opera Paper Products как-бы-шутка-но-не-такая уж и шутка
Opera Paper Products как-бы-шутка-но-не-такая уж и шутка

Я занимаюсь веб программированием 15 лет. Когда я начинал работать за деньги (компьютер у меня был и раньше, конечно), IE 6 был самым передовым и инновационным браузером, Firefox должен был вот-вот появиться, разработчики верили, что будущее за XHTML, до первого драфта HTML 5 и запуска StackOverflow оставалось 4 года, а до первого Chrome – пять лет. 

С вебом было связяно много неоправданных надежд, хайпа, завышенных ожиданий. Мы все ждали, когда же он вот все вообще поглотит, заменит, научится всему и вообще останется чуть ли не единственным инструментом, с которым будут работать вообще все. Сейчас ажиотаж спал и можно взглянуть трезво, что он такое есть и что он такое нет.

Получается вот как. Веб хорош для быстрого прототипирования, простого delivery, но масштаб его роста сильно ограничен. Грубо говоря, он подходит только для прототипов и игрушечных задач. Что-то вроде языка Basic, вроде и программы писать на нем можно, но всерьез его никто не берет. Веб, конечно, не пропадет, но в конечном счете займет место какого-нибудь там питона, на котором будут детей в MIT учить и ученые не слишком требовательные графики рисовать.

Почему? Качество. Все, сделанное на вебе, просто не доводится до какого-то сносного качества. Да, на вебе можно начать, и это будет быстрый старт. Но веб нельзя дожать до приемлимого состояния. От слова никак. Обязательно будет смешно, плохо и стыдно, а хорошо и быстро — никогда. Все веб-программисты на самом деле верят, что это они недостаточно стараются, но если было бы время, можно было бы сделать нормально. На этом самообмане вообще вся веб-индустрия держится. Но нет. Нельзя. Ни за какие деньги. Просто физически невозможно.

Ладно, простые статические страницы с текстом — ок, может быть. С адблоком и reader mode жить можно. Хотя и тут есть умельцы, которые умудряются сто слов отрендерить в страницу в 20 мегабайт, потому что технологии, инновации и disruption.

Что-то чуть сложнее — все, говно лезет из всех щелей. Веб-приложения? Интерфейсы? Сразу вешайтесь. Веб не создан для приложений и не развивается в эту сторону даже. Нет ни одного человека, который бы искренне любил веб-версию чего-либо и предпочитал ее нативной. Как только появляется альтернатива, даже иллюзия альтернативы, даже электрон-приложение, — всё, команда с крысами покинула корабль.

Сказать, что веб-приложение работает «нормально» можно только если очень, очень сильно смотреть на какой-то очень и очень частный случай сквозь пальцы, стиснутые настолько сильно, что они превращаются в фейспалм, и только если очень, очень верить в идею веба и хотеть это «нормально» увидеть. В определенных условиях на определенной мощности машине страничка может проскроллиться относительно плавно. В определенном месте экватора сайт может открыться условно быстро, а в определенное время конкретного дня в веб-консоли даже не будет ни одной ошибки.

Но если взять платформу в целом, без сверхподвигов и свехржертв, иллюзия пропадает. Если дать на нее посмотреть человеку, не укушенному веб-пропагандой, иллюзия пропадает. Как только приложение открывает кто-то, отличный от его собственного разработчика на гигабитном интернете и двенадцатиядерном аймаке про, иллюзия пропадает. Начинается бесконечный поток убогостей, шероховатостей, заусенцев, тормозов, проблем, ошибок, которые в принципе не устранить никаким образом. Даже если у разработчика есть внимание и желание возиться с такими глупостями, даже если приложить бесконенчые усилия — нет, оно не исправляется в принципе. Я знаю, я сам такой разработчик, и я пробовал много раз, и много раз обжигался. Хотя когда смотришь издалека, на бумаге, вроде все хорошо. Что может пойти не так? Да все что угодно. И не только может, но и пойдет, причем в самом неожиданном месте. Веб это такой аналог российского автопрома — издалека вроде тоже машина, вроде тоже ездит, че еще надо-то? Но, как мы все прекрасно знаем, есть нюанс.

Существует ли версия этой реальности, где веб вырастает во что-то более значимое? А как же WebAssembly?

А что WebAssebly? Эта чехарда имеет смысл только только для людей, которые думают, что компьютеров нигде кроме браузера не существует. Очнитесь, ребята, это еще один никому ненужный слой абстракции. Мы с радостью себя отбросили на N лет назад и теперь с радостью это преодолеваем. WebAssembly — это попытка запихнуть в веб то, что без веба прекрасно работало уже несколько десятков лет как — С++ приложения. Чтобы что? Я не знаю чтобы что. Чтобы условный Вася все равно качал себе Слак, завернутый в Электрон, зато теперь написаный на WebAssembly. Смотри, мам, он почти как нативный, даже иконочка есть! И почти не тормозит. Почти-почти. Еще раз — попробуйте выкинуть говно веб-пропаганды из головы и взглянуть на это трезво. В чем тут достижение-то?

Не то чтобы я НЕ хотел чтобы веб во что-то превратился. Я хотел, может, даже больше других. И был момент лет десять назад когда многие в это верили и был еще шанс. Просто пора зафиксировать (давно пора, я просто немножко тормоз, конечно) что веб это веб, не больше и не меньше. Все эти глюки, неровности, тормоза, неудобства, несовместимости, интервенции — это не временные мелкие неприятности, которые вот-вот разрешатся со следующим апдейтом Хрома. Это неотъемлемые свойства платформы, она такая сейчас и примерно такой же будет всегда. Надеяться уже в принципе не на что. И не то чтобы у меня было для вас что-то получше, или что я могу сказать, где будущее. Все что я могу сказать что оно точно не здесь.

усы2

Универсальная раскладка (скачать)

Выложил раскладку из предыдущего поста для Мака https://github.com/tonsky/Universal-Layout

Немного подвигал еще буквы и пунктуацию, теперь запятая, точка, восклицательный знак, вопрос, точка с запятой, двоеточие, двойная и одинарная кавычки — все на дефолтном слое (без шифта). Буквы Б, Х и Ю уехали со своих мест, но недалеко — не теряйте их.

Из фидбека к посту взял идею, что № не нужен и вместо него даже в русской раскладке лучше # (потому что хэштеги).

Также здесь включена «машинопись», т.е. цифры набираются с шифтом, а символы на цифрах — без шифта. Это жутко удобно, т.к., как показывает статистика, цифры набираются сильно реже. Тут пруфы. Я, собственно, с 2015 года так и сижу.

По Option (Alt) включается Типографская раскладка Бирмана, не пугайтесь. Это тоже очень хорошо зарекомендовавшая себя на практике штука, если привыкнуть — длинные тире, правильные «кавычки» и другая всячина набирается так же беспроблемно, как и обычный текст. Я разбавил её буквами Ё и Ъ, которые теперь тоже живут на Альте.

Картинка:

Будем считать это версией 1.0, жду звездочек на гитхабе, отзывов и советов.