# LiveJournal Published articles for LiveJournal. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Почему JetBrains не напишет легковесную IDE DevFeed: [Почему JetBrains не напишет легковесную IDE]() Original publisher: [Read original article]() Published: 2020-05-23T15:16:18Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [ide](), [jetbrains](), [Sublime Text](), [Android Studio](), [Vim](), [vs-code](), [Java](), [Syntax Highlighting]() Tags: [android-studio](), [ide](), [idea](), [java](), [jetbrains](), [livejournal](), [syntax-highlighting](), [tag-5e1c061eda96](), [tag-c40b78a8c8a6](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2](), [vim](), [vs-code]() ### AI overview The author argues that a lightweight IDE cannot exist because IDE features such as navigation, refactoring, debugging, and run configurations must understand the entire project. Build systems, frameworks, and integrations make that project-wide understanding inherently complex. The discussion draws on the author's experience with JetBrains IDEs, Java tooling, and Android Studio, while noting a personal preference for lightweight editors. ### Source excerpt Еще в 2011 я публично отказался от ИДЕ и так с тех пор и живу: TextMate, Vim, Sublime, LightTable, VS Code, снова Sublime. И вот год назад я устроился в JetBrains. Нет, мое отношение не поменялось: я все еще считаю, что в ИДЕ программировать не надо. У меня на столе усердно копится папочка Annoying IDE(A), а Джаву и Котлин я все так же пишу в Sublime Text. Поменялось вот что. Раньше я думал, что IDE это такие цитадели зла, что их специально делают сложными и неудобными, ну или не специально, а просто сил не хватает сделать аккуратными и легковесными. Могли бы, да не смогли. Сейчас, посмотрев на Idea, и на Java-тулинг, и на Android Studio, я понимаю, что это принципиальное противоречие: в самой идее IDE заложена сложность, кривость и неудобство. Легковесная IDE не может существовать, потому что мир вокруг сложен. Давайте подумаем, что ИДЕ нам дает. Syntax highlighting, Go to definition, Find usages, Show hierarchy, Structural rename, и допустим Run configurations, то есть возможность все это как-то запускать (в том числе и под дебаггером). Все это сами по себе вполне легковесные функции, так-то. Легко представить их чисто интерфейсно в, скажем, в Vim или VS Code, ничего принципиально сложного или развесистого они в себе не несут. Так в чем же проблема? Проблема в том, что чтобы они работали, нужно вот прям все-все знать о проекте в целом. Язык программирования, допустим, маленький и фиксированный, с ним просто. Поэтому Syntax highlighting, для которого дальше одного файла смотреть не нужно, есть в самых легковесных редакторах. А вот как проект настроен и как билдится, вот тут-то адок и начинается. Миллионы билд-систем, некоторые из которых императивные и тюринг-полные, два миллионна фреймворков, миллион в квадрате интеграций, все это кривое, косое, уникальное, как блядь снежинка, общается друг с другом не пойми как, пишет файлы, теряет файлы, не видит очевидного, лезет куда не нужно, зависит друг от друга, ломается и занимается при этом довольно тривиальными вещами, ## Why Software Becomes Larger and Slower Despite Hardware Gains DevFeed: [Why Software Becomes Larger and Slower Despite Hardware Gains]() Original publisher: [Read original article]() Published: 2020-03-20T10:48:53Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [Software](), [coding](), [Hardware]() Tags: [hardware](), [i](), [livejournal](), [software](), [tag-5e1c061eda96](), [tag-c40b78a8c8a6](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2]() ### AI overview The article examines why software applications have become larger and slower despite major improvements in hardware. It argues that software growth often results from continuously adding code instead of improving, rewriting, replacing, or removing existing code, while noting that the causes of application complexity are not always obvious. ### Source excerpt Евгений Трифонов накатал ответку на мой старый Software Disenchantment! На что у меня есть несколько замечаний, по мелочам и по существу. Готов поверить, что Word в 2020-м запускается медленнее, чем консольный редактор vi в 1983-м Интересное искажение восприятия, в котором все консольное считается ультра-быстрым, а все гуевое по-умолчанию медленным. Word очень неплохо оптимизирован на startup time как раз. Вот видео посовременнее, вот из 2010 (на железе 2010!). Как и веб-страница facebook. Несмотря на раздутость по функциям обоих. А те же vim/emacs, обвешанные плагинами, могут вполне себе долго запускаться. Или вот, например, command-line prompts, которые рисуются до 1000мс после КАЖДОЙ команды. Да, приложения за 10 лет выросли в разы. Но объём места за то же время вырос в СОТНИ раз. То есть жить стало в десятки раз лучше. Ну вот к этому-то и был мой основной вопрос. Мы получили выигрыш в 100 раз за счет hardware. К hardware вопросов нет. Но потеряли 10 раз в software. И хотя в сумме мы вроде как в выигрыше, к software вопросы остались! В чем причина? Неужели это обязательно? Хорошо что жить стало в десятки раз лучше, но могло бы ведь и в сотни? Так почему не стало? Мы точно знаем что могло, потому что старые приложения сохранились и работают -- быстро, четко, компактно на современном железе. Зачем делать хуже, если мы уже знали, как делать лучше? Моя цель здесь -- не раскритиковать конкретный пост, а показать общий подход: мы часто заявляем "приложения разбухли/затормозили без веских причин", не до конца понимая эти причины. У меня кстати вопросы к размеру приложений пропали после того, как фейсбук переписал мессенжер. То есть раньше я думал, там действительно что-то неладно, что такие толстые приложения получаются. Типа, фотку олега тинькоффа в 4k забыли удалить. Или статически влинковали Oracle DB, причем сразу четыре разные версии. Но нет, это банально количество кода. Переписанный с нуля текстовый чатик начинается с 360 000 строк кода в фейсбуке. Это все обычные ## Jetpack Compose and the Limits of Declarative UI Terminology DevFeed: [Jetpack Compose and the Limits of Declarative UI Terminology]() Original publisher: [Read original article]() Published: 2020-02-04T00:29:37Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [Jetpack Compose](), [Compose](), [Flutter](), [React](), [SwiftUI]() Tags: [compose](), [flutter](), [jetpack-compose](), [livejournal](), [react](), [swiftui](), [tag-5e1c061eda96](), [tag-c40b78a8c8a6](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2](), [ui]() ### AI overview The article introduces Jetpack Compose as Google's new Android UI framework and compares it with Flutter, SwiftUI, and React. It argues that calling these frameworks declarative is qualified because they describe UI in code while still relying on imperative mechanisms, mutable state, and procedures. ### Source excerpt Познакомился с Jetpack Compose. Это такой новый фреймворк "декларативного" UI для Андроида от Гугла. Потому что Гуглу, как обычно, мало одного нового "декларативного" фреймворка для Андроида (Flutter), и они решили делать сразу несколько. А чтобы ни кто не путался, делают их максимально похожими. Серьезно, авторы за ланчем обмениваются идеями и добавляют в оба. Почему "декларативный" в кавычках? "Декларативные" UI-фреймворки -- это новая волна, начатая Реактом и продолженная Flutter, SwiftUI, и вот теперь Jetpack Compose. Декларативные они в очень пост-ироничном смысле: упор в них как раз делается на описание UI в коде. А код, даже чисто функциональный, никак не может быть декларативным. Иерархия примерно такая: Декларативный. Чистый функциональный. Императивный. Понятно, что все эти фреймворки по уши сидят в императивности. Вот SQL декларативный. Prolog декларативный. Блин, даже XML/HTML/templates декларативные! А в том, чтобы позвать функцию, получить результат и обработать его, подергав попутно удобно подложенные глобальные процедуры, ничего декларативного нет. Но XML из моды вышел, А СЛОВО КРАСИВОЕ, чего слову пропадать? Так вот, "декларативные" фреймворки, как их называют, содержат что-то вроде VDOM, а точнее концепцию top-down rerendering. Это когда твоя функция должна посчитать, как в текущий момент UI должен выглядеть, полностью с нуля (сгенерить VDOM), а задача фреймворка -- привести UI в соответствие с этим представленим путем минимальных модификаций. В противовес старой ООП-UI модели, где эта задача ложилась на программиста и он неизбежно ныл и косячил. Раньше: panel1.close(); new panel2().open(), сейчас fun Window() = if (x) new panel1() else new panel2(); rerender(Window()); Мутабельный граф внутри все равно есть, только ходит с ним общаться сам фреймворк, ну, потому что код довольно однообразный был все равно. Декларативность тут в том смысле, что фреймворк только описывает, как ему хотелось бы видеть UI, а не создает его самостоятельно. Ну натянуто, кон ## SwiftUI: впечатления iOS-разработчика о реактивном UI-фреймворке и его синтаксисе DevFeed: [SwiftUI: впечатления iOS-разработчика о реактивном UI-фреймворке и его синтаксисе]() Original publisher: [Read original article]() Published: 2020-01-18T15:36:57Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [SwiftUI](), [iOS](), [ui]() Tags: [foreach](), [ios](), [livejournal](), [padding](), [swiftui](), [tag-5e1c061eda96](), [tag-c40b78a8c8a6](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2](), [ui](), [view]() ### AI overview An experienced iOS developer shares impressions of SwiftUI after using it for roughly six months and releasing two production applications. The article praises its reactive, data-driven UI model and previews while criticizing its syntax, element-count limitation, opaque types, and inconsistent modifier and container design. ### Source excerpt Если вдруг вы еще не знаете, примерно полгода назад Эппл анонсировало новый UI фреймворк -- SwiftUI. Событие очень серьезное, и как iOS разработчик со стажем я тут же переключился на него -- сначала попробовать, а потом уже и выпускать production приложения. Спустя полгода и два заапрувленных релиза, хочу поделиться с вами мыслями о SwiftUI. Во-первых, то, что Эппл выпустило нормальный реактивный data-driven UI фреймворк, заслуживает исключительно всяческих похвал. Правильный тренд, правильный подход, _почти_ интерактивное превью, все вовремя и к месту. Нам, iOS-программистам, чего-то такого сильно не хватало. Во-вторых (и тут уже о сомнительном), количество синтаксического сахара, которым они там обмазываются, вызывает, скажем так, удивление. Им пришлось серьезно расширить язык, чтобы вместо условно VStack( Image(uiImage: image), Text(title), Text(subtitle) ) можно было писать VStack { Image(uiImage: image) Text(title) Text(subtitle) } На что только люди не пойдут чтобы избежать споров о том где ставить запятую! Работает это благодаря вот такому вот прекрасному интерфейсу: То есть не только не очень понятно зачем так усложнять себе жизнь, но еще и больше 10 элементов не засунешь. Может быть создатели руководствовались правилом 7±2 и решили, что пользователи айфона не смогут всерьез осознать более 10 одновременных элеметов на экране. То что в этом интерфейсе пропилена специальная дырка для if напрягает если честно еще больше: Не самим фактом дырки, а вопросом, где же собственно дырки под все остальное? (на самом деле, если хочется больше 10 элементов, есть целый специальный компонент -- ForEach, который -- уберите детей от экрана! -- принимает список) (этот курьез и необходимость вводить opaque types заставляет задуматься, насколько сильно нам вообще нужна статическая типизация и какой ценой. Конечно, сторонники статической типизации скажут, что это просто типизация неправильная, вот была бы правильная и проблем бы не было -- что, в общем-то, универсальный аргумент, удобн ## How Abstraction and Lost Expertise Contribute to Unreliable Software DevFeed: [How Abstraction and Lost Expertise Contribute to Unreliable Software]() Original publisher: [Read original article]() Published: 2019-12-27T16:58:06Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [Software](), [Docker](), [Electron](), [macOS]() Tags: [docker](), [electron](), [livejournal](), [macos](), [software](), [tag-5e1c061eda96](), [tag-c40b78a8c8a6](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2](), [technology]() ### AI overview This opinion piece argues that software expertise is lost when new systems build on older technologies without understanding or reproducing their foundations. It cites Docker and Electron as examples of abstraction that can hide complexity, then uses bugs in an application running on macOS Catalina to illustrate the resulting reliability problems. ### Source excerpt Есть такой очень важный доклад Jonathan Blow - Preventing the Collapse of Civilization. Смотреть прям обязательно. Это такой Software Disenchantment только с анализом причин и выводом. Так вот, в нем утверждается что современные программисты, стоя на плечах гигантов, утратили способность писать фундаментальные вещи и вообще простой, быстрый, надежный софт. Good times create weak men: Ну а логика очень проста: предыдущее поколение сделало X, следующее пишет Y на X и ему не очень нужно и вообще не интересно, как X внутри устроено и как сделать такое же с нуля. Повторить N раз. При этом тревогу никто не бьет: всем кажется, если мы умели делать X, а научились делать Y, то теперь мы умеем делать и X, и Y. Что не совсем верно, потому что знания (экспертиза!) сами по себе вообще говоря не передаются (это одна из самых важных и новых для меня мыслей доклада), а необходимости практиковать X нет, соответственно он благополучно забывается. Docker и Electron -- самые популярные технологии сегодняшнего дня. Обе не про что-то новое или фундаментальное, а про то, чтобы тихонько спрятать сложность под ковер, понять, разобраться или изменить которую у нашего поколения уже не получается. И все бы хорошо, но лестница абстракции выросла уже настолько, что ошибки и дыры в сумме дают весьма существенный, заметный и неприятный результат. У нас сейчас есть на порядки более быстрые компьютеры, которые работают хуже, медленнее и ненадежнее, такой вот парадокс. Решение? Разобрать все, начать потихоньку уменьшать, заменять и переделывать, а экспертизы-то нет! Все это немножко отдает дедовским ворчанием, и вообще как-то не ощущалось без хороших наглядных примеров. Пока я не набрел на annoying.technology, клон нашего grumpy.website. Ребята не побоялись поставить себе macOS Catalina, и вот где, оказывается, цирк! Переключение чатов тормозит: https://annoying.technology/posts/e500c236b5e2853a/ Вместо следующего трека показывается через-один-следующий https://annoying.technology/posts/ee91b37183818d ## Cloud IDEs and Browsers Are Independent Design Choices DevFeed: [Cloud IDEs and Browsers Are Independent Design Choices]() Original publisher: [Read original article]() Published: 2019-12-27T13:01:01Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [ide](), [Atom](), [vs-code](), [jupyter](), [JavaScript]() Tags: [ide](), [javascript](), [livejournal](), [tag-5e1c061eda96](), [tag-c40b78a8c8a6](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2](), [vs-code]() ### AI overview The author argues that a cloud-based IDE does not have to run in a browser. They distinguish native and browser-based clients from local and cloud-hosted computation, and contend that native thin clients can use cloud resources without browser constraints. ### Source excerpt Интересно, что хоть я в своем предыдущем посте явно и написал, что работа в облаке и работа в браузере -- две совершенно перпендикулярных оси, я все равно получил пару комментариев от людей, которым кажется, что ЕСЛИ ты хочешь чтобы IDE работала в облаке, НЕОБХОДИМО, чтобы она работала в браузере. если у тебя браузер лишь отвечает за фронт, то ресуркоёмкие вещи (индексация всякая, подсказочки, рефакторинг, компеляция) можно отдать серваку (по-моему пока ms додумались до language server, не?). Не секрет, что многие считают идею очень прожорливой, поэтому мне кажется это было бы отличным выходом запихнуть иде в браузер где все сложные и ресурсоемкие операции выполнются на сервере, а тебе предоставляется только окошко терминал. Поэтому я на всякий случай повторю еще раз: Можно сделать локальную, прожорливую ИДЕ нативно. Классика: IDEA, Eclipse, Visual Studio. Подход прост и понятен всем. Можно сделать облачную ИДЕ в браузере: Cloud9, Jupyter. Это то, что считалось будущим программирования, но пока стало очень нишевой штукой. Но это НЕ единственный возможный вариант. Можно сделать локальную, прожорливую ИДЕ в браузере. Это то, что сделали VS Code и Atom. Не очень понятно, что они от этого выиграли, кроме того, что попали в волну, когда всем показалось, что будущее за JavaScript. Можно сделать облачную ИДЕ с нативным приложением. Примеров ИДЕ пока нет, но самому подходу сто лет, называется тонкий клиент, отлично себя зарекомендовал. Никто не мешает отгружать вычисления, ворочать облачными ресурсами и делать все остальное, НЕ будучи засунутым в браузер. Еще раз: браузер это довольно странная, во многом ограниченная и компромиссная платформа, которая дает leverage простым веб-страницам, но стоит начать делать что-то чуть более сложное (да, приложения, причем ЛЮБЫЕ приложения, даже самые элементарные), как она тут же начинает путаться под ногами и мешать. Ну серьезно, подумайте, вот начали вы облачную ИДЕ делать, чем браузер вам поможет? HTTP-клиентом? Серьезно, там больше Н ## Why the author argues that browser-based IDEs are not the future DevFeed: [Why the author argues that browser-based IDEs are not the future]() Original publisher: [Read original article]() Published: 2019-11-29T15:25:04Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [ide](), [jetbrains](), [WebAssembly](), [Code]() Tags: [code](), [ide](), [jetbrains](), [livejournal](), [tag-5e1c061eda96](), [tag-c40b78a8c8a6](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2](), [webassembly]() ### AI overview In a JetBrains talk, the author argues that browser-based IDEs offer limited benefits and sacrifice desktop capabilities such as shortcuts, drag-and-drop, file access, system integration, and performance. The article also questions whether WebAssembly and cross-device execution justify the trade-offs. ### Source excerpt Я тут сделал доклад в JetBrains (внутренний, сорян) про будущее IDE. И после доклада было много вопросов из серии "Но ведь будущее определенно за Х, а вы его даже не рассматриваете". Отвечаю. -- Почему вы не делаете IDE для браузера? Visual Studio Code Online Делать IDE в браузере особого смысла нет. Да, лет десять назад, на волне успеха Google Docs всем казалось, что сейчас вообще все переедет в веб: и фотошоп, и обработка музыки, и монтаж видео, даже игры пытались. И, разумеется, программирование. Оказалось (внезапно, да) что браузер это довольно неудобная и ограниченная фигня и сидеть в нем добровольно никто не хочет. То есть это и так было понятно, просто лет десять назад казалось, что щас гугл с майкрософтом напрягутся и подтянут веб до нужного уровня. Тогда думать так было нормально. Сегодня это уже наивно, потому что мы видим, что по факту никто ничего никуда не подтянул, наоборот, закручивают гайки и делают из веба платформу для документов. Ну и десять лет назад, может быть, кому-то и казалось, что веб это дивный новый мир, но сегодня уже совсем не так ясно, зачем вообще лезть в браузер? От попадания туда у приложений не возникает магически каких-то волшебных свойств, которые невозможно было бы организовать на десктопе. Наоборот, многие полезные свойства гарантированно теряются: шорткаты сильно ограничены, drag-n-drop, файлы, интеграция в систему, перформанс. Зачем, мистер Андерсон, зачем? Если будущее приложений (вообще любых, кстати) и лежит где-то, то точно не в браузере. -- Но ведь есть WebAssembly! Естественно, в таких дискуссиях неизбежно всплывает веб-ассемблер. Что тоже мне не очень понятно: веб ассемблер это такой способ запустить C++ в браузере. Но тут мы приходим опять же к вопросу: а зачем вообще запускаться в браузере? Что там есть такого, чтобы сначала усложнять себе жизнь, а затем эти проблемы героически решать? -- Но ведь если IDE написать для браузера, ты сразу сможешь запуститься на любом устройстве? Типа да, но то, что ты сможешь запустить, б ## Kotlin's Flexible File Organization Can Make Code Harder to Find DevFeed: [Kotlin's Flexible File Organization Can Make Code Harder to Find]() Original publisher: [Read original article]() Published: 2019-09-11T15:05:52Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [Kotlin]() Tags: [kotlin](), [livejournal](), [tag-5e1c061eda96](), [tag-c40b78a8c8a6](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2]() ### AI overview The article argues that Kotlin's flexible file and package declarations can make code organization confusing. It contrasts Kotlin with Clojure's strict one-file-per-namespace model and Java's one-file-per-class convention. ### Source excerpt Лучший язык, в котором правильно сделаны модули (ну или неймспейсы) -- Кложа. Один файл === один неймспейс. Неймспейс может называться только так, как называется файл, и никак иначе. И лежать он должен тоже ровно по пути пакета. То есть (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. Ну офигеть! Класс мож ## Comparing Rust and Clojure Performance with the Same Solver DevFeed: [Comparing Rust and Clojure Performance with the Same Solver]() Original publisher: [Read original article]() Published: 2019-07-08T14:25:55Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [Rust](), [Clojure]() Tags: [clojure](), [livejournal](), [rust](), [tag-5e1c061eda96](), [tag-c40b78a8c8a6](), [tag-cb5ff012b3f0](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2]() ### AI overview The author ports an ICFPC solver from Clojure to Rust while keeping the data structures, algorithms, and constants essentially the same, then compares performance. The Rust version is substantially faster, especially in a release build, while requiring careful attention to ownership and allocation. ### Source excerpt В предыдущем посте я разочаровывался в Clojure, а точнее в тех задачах, которые хочу на ней решать. С языком-то все нормально, он ровно то, за что себя выдает. Просто до какого-то момента и для каких-то задач на это удобно закрывать глаза, ну а мне уже не удобно. Ну и что я сделал. Я пошел учить Rust. Не, ну интересно же, как компьютеры сегодня могут, если их правильно попросить. Чтобы потренироваться я портировал на Раст наше решение из ICFPC. Причем портировал точь-в-точь: все те же структуры данных, те же алгоритмы, те же константы. Ну разве что не персистентные: там, где в Clojure update, в Rust у меня clone() и только потом push/insert, потому что в комплекте персистентные структуры не идут, да и так идиоматичнее. Важно: я не пытался что-то улучшить, срезать углы, реализовать покрасивее, нет: я написал ровно то, что мы и на Clojure написали. Ну, чтобы сравнение было честным. Как только мой решатель начал что-то решать, я сразу же побежал сравнивать производительность. Rust ожидаемо вырывался вперед, но не на безумные цифры. Типа, вместо 4-5 секунд на задачу решал за три. Я даже собрался уже разоблачающий пост писать, что мол язык не важен, важны структуры данных и алгоритмы, в них весь перформанс, а не в том, на каком языке вы их записали. Потом, правда, коллеги подсказали, что я забыл снять с ручника, то есть запускал Rust в debug-билде. Ну и конечно, стоило поставить --release, как скорость выросла раз в двадцать. Впечатляет, да? Самое печальное тут в том, что это все время на одну и ту же работу. Чистый оверхед. Программа на Clojure не выдает какой-то более умный или точный или качественный ответ. Она приходит к тому же финишу, только к ногам привязаны огромные 20-кратные гири. Раст на одном ядре обгоняет Кложу на двенадцати ядрах в 3,5 раза! Можно было бы сказать "но это же низкоуровневый язык, как на нем можно что-то писать"? Писать было непривычно, потому что язык новый, но по ощущениям ничего особенно сложного, когда научишься. Приходится внимательно сле ## ICFPC 2019 DevFeed: [ICFPC 2019]() Original publisher: [Read original article]() Published: 2019-06-27T11:03:26Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [Clojure](), [iteration]() Tags: [clojure](), [iteration](), [livejournal](), [tag-5e1c061eda96](), [tag-c40b78a8c8a6](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2]() ### AI overview A personal report on participating in ICFPC 2019, a three-day programming competition involving maze-solving with additional equipment. The author describes the team's 29th-place finish among 142 teams, team size considerations, and the perceived performance limitations of Clojure for this challenge. ### Source excerpt В этот понедельник закончился трехдневный марафон под названием ICFPC. Это такое соревнование, где команды программистов со всего мира пытаются на время как можно лучше решить некую задачу. В этот раз - обход лабиринтов с разным доп. инвентарем. Условия можно прочитать здесь. Это как бы отчет, но на самом деле памятка самому себе на случай, если буду играть еще через год. Мне очень понравилось. То есть я конечно устал как собака, но есть что-то приятное в том что этот опыт а) имеет конечную продолжительность, а не тянется годами, как основная работа. И б) можно полностью отдаться задаче, не думая о том зачем это все и что ты делаешь со своей жизнью. Такой вот повод упоенно фигачить на полной скорости какое-то время, чтобы ветер свистел в ушах. Ну и просто весело. Очень любопытно посмотреть, чего ты стоишь. В голове-то ты мог много себе про себя нафантазировать, а тут вот объективная реальность, ладдер, и ты либо можешь компьютер заставить делать что ты хочешь, либо не можешь. Никаких "если бы", никаких "возможно, наверное, мне кажется". Мы довольно посредственно выступили (на момент закрытия 29 место из 142 участвовавших, в лучший свой момент были на пятом). Исторический скриншот. Дальше мы сильно сдали Участвовали втроем, я в первый раз. Как я понял, средний размер команды ~5 человек, не редкость и восемь встретить. Втроем у нас довольно хорошо делились области ответственности, было бы больше появился бы организационный оверхед (как мне кажется). Восемь человек я бы вообще офигел менеджить и вообще ничего бы не написал, наверное. С другой стороны, больше рук - можно попробовать больше подходов. Можно вложиться в инфрастуктуру. Наверное. Задача достаточно нетривиальная, чтобы решить ее до конца было в принципе невозможно. Но и не супер-сложная, чтобы как-то ее решить можно было бы даже иногда и руками (ну, самые простые примеры). Как правило это значит перебор вариантов в каком-то NP-полном поле, соревнование эвристик. Собери бонусы, закрась лабиринт Clojure, несмот ## How CSS direction: rtl Can Reverse Latin Text and Punctuation DevFeed: [How CSS direction: rtl Can Reverse Latin Text and Punctuation]() Original publisher: [Read original article]() Published: 2019-05-29T14:39:10Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [Document Object Model (DOM)](), [Stack Overflow]() Tags: [livejournal](), [stackoverflow](), [tag-5e1c061eda96](), [tag-c40b78a8c8a6](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2]() ### AI overview The article examines how applying the CSS direction property for Arabic text to Latin content can reverse text order and affect numbers, punctuation, and ranges in unexpected ways. It describes a workaround that wraps the affected elements with direction: ltr. ### Source excerpt Не хочу специально набрасывать, но вот вчера попалось на глаза и я прям прослезился. Смотрю, что если в столбце справа путь "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-фреймворками? DevFeed: [Что случилось с GUI-фреймворками?]() Original publisher: [Read original article]() Published: 2019-04-12T21:46:29Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [GUI](), [ui](), [SVG]() Tags: [flat](), [gui](), [livejournal](), [mvc](), [svg](), [tag-5e1c061eda96](), [tag-c40b78a8c8a6](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2](), [ui]() ### AI overview The author discusses what a desktop GUI framework should provide, arguing that customizable low-level primitives and core capabilities such as input handling, scrolling, rendering, font output, and DPI handling are more valuable than large collections of ready-made widgets or platform-specific look and feel. The article expresses a preference for designing polished interfaces directly and cautions against imposing patterns such as MVC or VDOM. ### Source excerpt Это третий пост в моем квесте по поиску 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 приложение, а не дешево выгляд ## A critical view of the web's limits for serious applications DevFeed: [A critical view of the web's limits for serious applications]() Original publisher: [Read original article]() Published: 2019-04-05T10:59:21Z Content type: opinion Language: ru Sources: [Tonsky Стой под стрелой]() Topics: [Web Development](), [modern web development](), [веб-приложения]() Tags: [livejournal](), [tag-0323c1c6735a](), [tag-5e1c061eda96](), [tag-7bc388df28ed](), [tag-c40b78a8c8a6](), [tag-cdf241ba4036](), [tag-d16a2c26554f](), [tag-e3028c5e0ab2](), [tag-e75d8ba74bc8]() ### AI overview The author reflects on 15 years of web programming and argues that the web is useful for rapid prototyping and simple delivery but has limited potential for demanding applications. The article attributes this mainly to perceived quality problems and argues that web applications and interfaces are generally inferior to native alternatives. ### Source excerpt Opera Paper Products как-бы-шутка-но-не-такая уж и шутка Я занимаюсь веб программированием 15 лет. Когда я начинал работать за деньги (компьютер у меня был и раньше, конечно), IE 6 был самым передовым и инновационным браузером, Firefox должен был вот-вот появиться, разработчики верили, что будущее за XHTML, до первого драфта HTML 5 и запуска StackOverflow оставалось 4 года, а до первого Chrome - пять лет. С вебом было связяно много неоправданных надежд, хайпа, завышенных ожиданий. Мы все ждали, когда же он вот все вообще поглотит, заменит, научится всему и вообще останется чуть ли не единственным инструментом, с которым будут работать вообще все. Сейчас ажиотаж спал и можно взглянуть трезво, что он такое есть и что он такое нет. Получается вот как. Веб хорош для быстрого прототипирования, простого delivery, но масштаб его роста сильно ограничен. Грубо говоря, он подходит только для прототипов и игрушечных задач. Что-то вроде языка Basic, вроде и программы писать на нем можно, но всерьез его никто не берет. Веб, конечно, не пропадет, но в конечном счете займет место какого-нибудь там питона, на котором будут детей в MIT учить и ученые не слишком требовательные графики рисовать. Почему? Качество. Все, сделанное на вебе, просто не доводится до какого-то сносного качества. Да, на вебе можно начать, и это будет быстрый старт. Но веб нельзя дожать до приемлимого состояния. От слова никак. Обязательно будет смешно, плохо и стыдно, а хорошо и быстро -- никогда. Все веб-программисты на самом деле верят, что это они недостаточно стараются, но если было бы время, можно было бы сделать нормально. На этом самообмане вообще вся веб-индустрия держится. Но нет. Нельзя. Ни за какие деньги. Просто физически невозможно. Ладно, простые статические страницы с текстом -- ок, может быть. С адблоком и reader mode жить можно. Хотя и тут есть умельцы, которые умудряются сто слов отрендерить в страницу в 20 мегабайт, потому что технологии, инновации и disruption. Что-то чуть сложнее -- все, говн