Flutter/React Native это принципиально не лечит, и не должен лечить, и не маскирует. Это не то, что можно замаскировать высокоуровневой библиотекой, это то, что надо было делать по единному стандарту с корня.
Справедливости ради, пользователи не ищут ваше приложение по имени пакета
Господин, вы считаете что иметь единый идентификатор для всего зоопарка платформ - это не справедливо и неудобно для пользователя? Если будет единый идентификатор - это рай для всех. Да, пользователю обычно всё равно (но я бы хотел только по ид=названию найти приложение во всех сторах), но единообразие идентификаторов важно не только для поиска, но и для управления продуктом. Эти строки живут в ссылках стора, интеграциях и документах, и со временем превращаются в “паспорт” приложения:
юридические/комплаенс-документы, договоры, реестры и просто корпоративная отчётность, где удобнее иметь один канонический идентификатор продукта, а не зоопарк строк.
в ссылке Google Play реально светится package name через параметр id=..., и в B2B-переписке/презентациях это часто видно.
Android App Links требуют assetlinks.json и там завязка на пакет/подпись, поэтому согласованность домена и ID снижает шанс ошибок, а на iOS в apple-app-site-association ключ appID строится как TeamID + bundleID. И да, в CI/CD (тот же fastlane) вы постоянно оперируете bundle identifier как общей переменной проекта, так что единообразие реально экономит время. CI/CD: В скриптах сборки (Fastlane, GitHub Actions) вы оперируете одной переменной APP_ID, а не пишете «лапшу» из условий if ios then ... else ....
Группировка статистики и логика валидации клиентов на сервере упрощается в разы, когда у вас один ключ продукта, а не таблица маппинга разных ID.
И еще полно случаев, где это удобно.
В итоге: даже юзеру не всё равно, от удобного юзер не откажется, но разработчику и бизнесу единый ID экономит часы на настройку, деньги на юристов и нервы на поддержку легаси.
1) музыка изначально создавалась и выкладывалась на платформах ради продажи.
2) украсть и сделать общедоступным не равно опенсорс
Пираты существовали всегда, грабили жёстко и лишь единицы из них делились награбленным с простым народом.
А мне нравится покупать за пару долларов любимые песни, т к и мне приятно, и автору песни спасибо и платформе, которая организовала такой простой, доступный и легальный способ приобрести песню - спасибо.
Терминалов никто не боится, gui используют потому что это и удобно, и красиво, и быстро.
Gui даёт несравненно богатое представление информации в отличие от терминала, ни один 3д проектировщик и ни один видеомонтажер не будет выводить свою работу в терминал, потому что это глупо.
А вот программистам и представлять не надо, в здесь все ровно так и происходит - программу вы можете запустить только целиком.
Совсем нет. Тестирование появилось одновременно с программированием, а сейчас тестирование очень развито, все части программы можно протестировать до запуска целиком.
Главная проблема - у вас нет гарантии, что вы действительно правильно понимаете, как все работает
Это скорее про заказчика, а не про исполнителя в классическом программировании для бизнеса: исполнитель понимает, а заказчик - не факт. А в вайбкодинге исполнитель - ЛЛМ, ЛЛМ - "понимает", а вот вайбкодер - не факт.
а из непонятного - почему вы не поменяете свой арсенал знаний и инструментов, которые держат вас в таких рамках, если видите эти рамки?
Да, верно, это во-первых, одна из лучших статей, во-вторых - самая недооцененная. Автору огромная благодарность и плюс в карму. Пишите, пишите еще, хорошо получилось, именно такое хочется читать!
location – GLint, остальные флоты. Что по-вашему происходит в rust/dart – отдельный тип для красного цвета, отдельный для зеленого?
речь была не о «семантических типах цвета», а о позиционной небезопасности immediate-mode API с однотипными аргументами:
Ни в Rust, ни в Dart никто не вводит отдельные типы Red, Green, Blue для raw OpenGL.
Происходит одно из двух:
Тонкий unsafe binding (как gl-rs):
unsafe { gl::Uniform4f(location, r, g, b, a); }
→ никакой дополнительной type safety нет.
Safe wrapper уровня движка:
set_uniform(location, Color { r, g, b, a });
или
shader.setColor(Color(r, g, b, a));
И вот здесь типизация появляется не на уровне ABI, а на уровне API-дизайна.
Синхронный вызов, который синхронно только сохраняет команду в очередь.
согласен, сам вызов не блокирует GPU напрямую. Под «синхронностью» я имел в виду runtime-валидацию и работу драйвера в момент draw-call, а не буквальное ожидание выполнения на GPU.
Шейдеры вообще можно один раз на старте приложения скомпилировать. То, что конкретная реализация динамически собирает шейдеры, чтобы заинлайнить параметры виджета не относится к тому, что шейдер нельзя скомпилировать заранее, а к тому, что исходного кода шейдера заранее не существует в конкретной реализации skia.
Про шейдеры: да, их можно компилировать заранее, и проблема не в невозможности как таковой, а в отсутствии надёжного и переносимого механизма предкомпиляции и кэширования на разных драйверах. Здесь вы правы.
Да, можно, по дефолту сейчас Impeller, и именно под него команда Flutter оптимизирует стек. А в задачах примерно так:
Impeller:
Лучше для типичных Flutter-приложений:
бизнес-UI,
сложные layout’ы,
анимации,
скроллы.
Предсказуемый frame time.
Меньше «внезапных» лагов.
Skia:
В некоторых нишевых кейсах реально быстрее:
кастомная 2D-графика,
нетипичные эффекты,
плотная работа с canvas.
Но требует аккуратной настройки и понимания
То есть сейчас это не «Impeller всегда быстрее», а: Impeller выигрывает по UX-стабильности, Skia иногда по сырой пропускной способности. В последних версиях Flutter Impeller — основной рендерер по умолчанию, но Skia жива и применима и доступна по флагу при желании, ее хотели убрать, но оставили и правильно сделали. На мой взгляд, надо оставить оба рендера + Skia тоже подтянулась.
Да, всё верно, правильные части написаны при помощи LLM, а не правильные мной самим (мясная природа галюцинаций), на то я и человек, проверяю заблуждения и если это действительно мои заблуждения - признаю и исправляю. Поэтому и предложил обсудить в комментариях. В течении суток всё проанализирую. А за исправления всех благодарю!
я бы сказал, речь даже не о качестве, есть еще один момент, который я не упомянул - зависит от того какое приложение вы делаете, в некоторых редких случаях лучше по производительности подходит именно skia, но по своей структуре "для бизнес приложух" импеллер лучше и выигрывает
Из какого года вообще статья? Из 2022? Потому, что если смотреть на позиции сегодняшнего дня, то можно практически быть уверенными, что Google "прикопала" проект своего модема
С этим не соглашусь, для пользователей пикселей всё актуально, а андроид до этого года испытывали на пикселях
У меня вин 11 стоит на нетбуке времен 7 или XP, стандартный обход TPM, все родные драйвера, которые написаны то ли под XP, толи под 7 работают отлично на 11.
На этот же нетбук до 11 хотел поставить убунту 20, вот тогда кулер пищал убого и ноут грелся. Нетбук - Acer, но на новых Acer есть случаи, когда драйвера вин 11 не работают на 10, это политика производителя.
Вы правы, технически Mesa — это userspace-реализация, а в ядре живет только DRM/KMS подсистема. Я объединил их в скобках для упрощения, чтобы показать отличие от архитектуры Zircon, где управление железом (то, что делает DRM) вынесено из ядра в userspace (драйвер Magma). Спасибо за уточнение, это важное различие.
Во вторых, шерлотанов в науке, именно в той самой, которая не альтернативная - ничуть не меньше, чем в альтернативной.
А в-третьих, на словах ответственность может взять на себя кто угодно, возможно вы сталкивались с альтернативщиками, а я работал в сфере научных сотрудников и врачей. Они берут ответственность не на себя а на "то что в данный момент известно науке и медицине" и если от какого-то препарата вы получите побочку - расскажите ка кто берет на себя материальную ответственность за побочки? Переливание ответственности из пустого в порожнее - не решит проблему шерлотанства.
Вопрос всегда будет упираться в честность и компетентность данного человека, а не в то, занимается он реальной наукой или альтернативной.
Ваше мнение об астрологии основано на тех случаях, когда астрологией занимались тупые люди. Тупые люди испоганят что угодно, по крайней мере мы видим во что превращается наука.
Я хочу сказать, что не следует вешать ярлыки на астрологию, Таро, нумерологию и т д. Т к эти учения довольно хороши в своей предметной области и, в принципе сами учения не виноваты в том, что некоторые идиоты в попытке заполучить всё счастье вселенной искажают всё и вся.
Сны - это кладезь. Кто-то в них видит периодическую таблицу хим элементов, а кто-то свои страхи.
В целом, плюсую каждый ваш комментарий, вайбкодинг ошибочно связывают с каким-то лодырем, который сказал ллм "захуячъ мне щас приложуху" и срубил бабла. Если подойти к вопросу с тщательным планированием и заданием архитектуры проекта - ошибки ллм стремятся к нулю, а скорость разработки растет на порядки. Посыл автора статьи мне в этом смысле тоже не понятен. Раньше, до ллм, по ролику на ютубе мог установить вордпресс любой, кто умеет хотя бы смотреть ютуб или гуглить. Вайб кодинг - это не про то "как никто сделал всё на гпт", а скорее про то, как умный человек ускорил свою самореализацию и совсем необязательно, чтобы он был программистом, достаточно иметь четкий и правильный план, а не дрочить пол жизни на ньюансы типа "почему 1 плюс 1 не равно 2".
Flutter/React Native это принципиально не лечит, и не должен лечить, и не маскирует. Это не то, что можно замаскировать высокоуровневой библиотекой, это то, что надо было делать по единному стандарту с корня.
Господин, вы считаете что иметь единый идентификатор для всего зоопарка платформ - это не справедливо и неудобно для пользователя? Если будет единый идентификатор - это рай для всех. Да, пользователю обычно всё равно (но я бы хотел только по ид=названию найти приложение во всех сторах), но единообразие идентификаторов важно не только для поиска, но и для управления продуктом. Эти строки живут в ссылках стора, интеграциях и документах, и со временем превращаются в “паспорт” приложения:
юридические/комплаенс-документы, договоры, реестры и просто корпоративная отчётность, где удобнее иметь один канонический идентификатор продукта, а не зоопарк строк.
в ссылке Google Play реально светится package name через параметр id=..., и в B2B-переписке/презентациях это часто видно.
Android App Links требуют assetlinks.json и там завязка на пакет/подпись, поэтому согласованность домена и ID снижает шанс ошибок, а на iOS в apple-app-site-association ключ appID строится как TeamID + bundleID. И да, в CI/CD (тот же fastlane) вы постоянно оперируете bundle identifier как общей переменной проекта, так что единообразие реально экономит время.
CI/CD: В скриптах сборки (Fastlane, GitHub Actions) вы оперируете одной переменной APP_ID, а не пишете «лапшу» из условий if ios then ... else ....
Группировка статистики и логика валидации клиентов на сервере упрощается в разы, когда у вас один ключ продукта, а не таблица маппинга разных ID.
И еще полно случаев, где это удобно.
В итоге: даже юзеру не всё равно, от удобного юзер не откажется, но разработчику и бизнесу единый ID экономит часы на настройку, деньги на юристов и нервы на поддержку легаси.
Причем здесь капитализм?
1) музыка изначально создавалась и выкладывалась на платформах ради продажи.
2) украсть и сделать общедоступным не равно опенсорс
Пираты существовали всегда, грабили жёстко и лишь единицы из них делились награбленным с простым народом.
А мне нравится покупать за пару долларов любимые песни, т к и мне приятно, и автору песни спасибо и платформе, которая организовала такой простой, доступный и легальный способ приобрести песню - спасибо.
Терминалов никто не боится, gui используют потому что это и удобно, и красиво, и быстро.
Gui даёт несравненно богатое представление информации в отличие от терминала, ни один 3д проектировщик и ни один видеомонтажер не будет выводить свою работу в терминал, потому что это глупо.
Совсем нет. Тестирование появилось одновременно с программированием, а сейчас тестирование очень развито, все части программы можно протестировать до запуска целиком.
Это скорее про заказчика, а не про исполнителя в классическом программировании для бизнеса: исполнитель понимает, а заказчик - не факт. А в вайбкодинге исполнитель - ЛЛМ, ЛЛМ - "понимает", а вот вайбкодер - не факт.
а из непонятного - почему вы не поменяете свой арсенал знаний и инструментов, которые держат вас в таких рамках, если видите эти рамки?
Да, верно, это во-первых, одна из лучших статей, во-вторых - самая недооцененная. Автору огромная благодарность и плюс в карму. Пишите, пишите еще, хорошо получилось, именно такое хочется читать!
речь была не о «семантических типах цвета», а о позиционной небезопасности immediate-mode API с однотипными аргументами:
Ни в Rust, ни в Dart никто не вводит отдельные типы
Red,Green,Blueдля raw OpenGL.Происходит одно из двух:
Тонкий unsafe binding (как
gl-rs):→ никакой дополнительной type safety нет.
Safe wrapper уровня движка:
или
И вот здесь типизация появляется не на уровне ABI, а на уровне API-дизайна.
согласен, сам вызов не блокирует GPU напрямую. Под «синхронностью» я имел в виду runtime-валидацию и работу драйвера в момент draw-call, а не буквальное ожидание выполнения на GPU.
Про шейдеры: да, их можно компилировать заранее, и проблема не в невозможности как таковой, а в отсутствии надёжного и переносимого механизма предкомпиляции и кэширования на разных драйверах. Здесь вы правы.
Да, можно, по дефолту сейчас Impeller, и именно под него команда Flutter оптимизирует стек. А в задачах примерно так:
Impeller:
Лучше для типичных Flutter-приложений:
бизнес-UI,
сложные layout’ы,
анимации,
скроллы.
Предсказуемый frame time.
Меньше «внезапных» лагов.
Skia:
В некоторых нишевых кейсах реально быстрее:
кастомная 2D-графика,
нетипичные эффекты,
плотная работа с canvas.
Но требует аккуратной настройки и понимания
То есть сейчас это не «Impeller всегда быстрее», а: Impeller выигрывает по UX-стабильности, Skia иногда по сырой пропускной способности. В последних версиях Flutter Impeller — основной рендерер по умолчанию, но Skia жива и применима и доступна по флагу при желании, ее хотели убрать, но оставили и правильно сделали. На мой взгляд, надо оставить оба рендера + Skia тоже подтянулась.
Да, всё верно, правильные части написаны при помощи LLM, а не правильные мной самим (мясная природа галюцинаций), на то я и человек, проверяю заблуждения и если это действительно мои заблуждения - признаю и исправляю. Поэтому и предложил обсудить в комментариях. В течении суток всё проанализирую. А за исправления всех благодарю!
я бы сказал, речь даже не о качестве, есть еще один момент, который я не упомянул - зависит от того какое приложение вы делаете, в некоторых редких случаях лучше по производительности подходит именно skia, но по своей структуре "для бизнес приложух" импеллер лучше и выигрывает
Да, это опечатка, имелось ввиду 12
С этим не соглашусь, для пользователей пикселей всё актуально, а андроид до этого года испытывали на пикселях
Благодарю!
У меня вин 11 стоит на нетбуке времен 7 или XP, стандартный обход TPM, все родные драйвера, которые написаны то ли под XP, толи под 7 работают отлично на 11.
На этот же нетбук до 11 хотел поставить убунту 20, вот тогда кулер пищал убого и ноут грелся. Нетбук - Acer, но на новых Acer есть случаи, когда драйвера вин 11 не работают на 10, это политика производителя.
Политика и технологии - не одно и тоже.
Вы правы, технически Mesa — это userspace-реализация, а в ядре живет только DRM/KMS подсистема. Я объединил их в скобках для упрощения, чтобы показать отличие от архитектуры Zircon, где управление железом (то, что делает DRM) вынесено из ядра в userspace (драйвер Magma). Спасибо за уточнение, это важное различие.
Чтобы понять человек от он
Тогда он ёбнется при запуске
Во-первых, бизнес и наука - разные понятия.
Во вторых, шерлотанов в науке, именно в той самой, которая не альтернативная - ничуть не меньше, чем в альтернативной.
А в-третьих, на словах ответственность может взять на себя кто угодно, возможно вы сталкивались с альтернативщиками, а я работал в сфере научных сотрудников и врачей. Они берут ответственность не на себя а на "то что в данный момент известно науке и медицине" и если от какого-то препарата вы получите побочку - расскажите ка кто берет на себя материальную ответственность за побочки? Переливание ответственности из пустого в порожнее - не решит проблему шерлотанства.
Вопрос всегда будет упираться в честность и компетентность данного человека, а не в то, занимается он реальной наукой или альтернативной.
Ваше мнение об астрологии основано на тех случаях, когда астрологией занимались тупые люди. Тупые люди испоганят что угодно, по крайней мере мы видим во что превращается наука.
Я хочу сказать, что не следует вешать ярлыки на астрологию, Таро, нумерологию и т д. Т к эти учения довольно хороши в своей предметной области и, в принципе сами учения не виноваты в том, что некоторые идиоты в попытке заполучить всё счастье вселенной искажают всё и вся.
Сны - это кладезь. Кто-то в них видит периодическую таблицу хим элементов, а кто-то свои страхи.
Т е по вашему мнению основатель психоанализа Зигмунд Фрейд (Толкование сновидений является его самым большим трудом) не смог бы освоить компьютер?
Обычно стереотипное мышление ограничивает самого мыслящего стереотипами.
В целом, плюсую каждый ваш комментарий, вайбкодинг ошибочно связывают с каким-то лодырем, который сказал ллм "захуячъ мне щас приложуху" и срубил бабла. Если подойти к вопросу с тщательным планированием и заданием архитектуры проекта - ошибки ллм стремятся к нулю, а скорость разработки растет на порядки. Посыл автора статьи мне в этом смысле тоже не понятен. Раньше, до ллм, по ролику на ютубе мог установить вордпресс любой, кто умеет хотя бы смотреть ютуб или гуглить.
Вайб кодинг - это не про то "как никто сделал всё на гпт", а скорее про то, как умный человек ускорил свою самореализацию и совсем необязательно, чтобы он был программистом, достаточно иметь четкий и правильный план, а не дрочить пол жизни на ньюансы типа "почему 1 плюс 1 не равно 2".