Ответ на пост «"Программисты не умеют программировать"»

Очередной истеричный дурачок, который не разбирается в вопросе и которому программисты соли на хуй насыпали. Так еще и в топе коммент: «в чем он не прав?»

Если коротко, то во всем. А если подробнее, то смысл в том, что в мире существует просто ебейшее количество процессоров, графических чипов, wi-fi модулей, 3/4/5g модулей, дисплеев и камер. Теперь представим возможное количество их комбинаций. Представили? И к каждому компоненту идёт свой драйвер.

А если я скажу, что кроме железа есть еще 2 абсолютно разные операционных системы и у каждой системы есть по 5-10 ревизий, которые совершенно по разному могут взаимодействовать с этим железом и по разному отображать анимации и графические компоненты программы. Ведь у таких Васянов в жопу ужаленных явно не каждый год новый айфон, а какой нить сука meizu 2013 года, который при этом еще и не обновлялся, и вообще больше не выпускается, как и драйвера на него.

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

1. Написать 2 отдельных приложения на каждую операционку, плюс их различные версии. А если кто-то не в курсе, то пишутся они абсолютно на разных языках и используют разные технологии. То есть это зачастую не выполнимая задача для одного программиста, их уже нужно минимум два, а если приложение состоит не из двух кнопок, а это сложное банковское приложение, которое должно быть защищено, совершать nfc транзакции, взаимодействовать с геолокацией, поддерживать аутентификацию faceid, то программистов нужно штук 5 минимум, им нужно параллельно написать разные компоненты программы, чтобы она в конце не развалилась и нормально работала. Времени это займёт минимум год, а то и больше, включая многоуровневое тестирование всей этой пиздалы.

2. Взять 2 программистов и написать одно приложение на кроссплатформенном фреймворке, где от программистов будет требоваться только написание бизнес-логики и создание архитектуры одного приложения. А по времени это займет в 2 раза меньше. То есть затраты составят В ПЯТЬ! раз меньшую сумму и приложение будет готово в 2 раза быстрее. Более того, поддерживать одно приложение в дальнейшем гораздо проще, быстрее и дешевле.

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

Как думаете, какой из вариантов заказчика устроит больше?

Пиздеть - не мешки ворочать.

Вы смотрите срез комментариев. Показать все
193
Автор поста оценил этот комментарий

Ну, дружище, для описанного Вами частного случая можно написать приложение на С, следуя стандарту POSIX. Будет работать хоть в Linux хоть в Windows, и весить будет несколько десятков килобайт.

«Жырность» же современных приложений обусловлена тем что они в основном написаны на языках, преобразующих код в платформенно-независимый байткод/промежуточный код, и с добавлением фрэймворков для типичных задач, которые притаскивают с собой свои базовые сущности (включая ненужные под конкретную задачу) и еще пачку зависимостей…

Это упрощает создание приложений, но ценой неэффективного потребления ресурсов. Это непринципиально, потому что закон Мура сделал вычислительные ресурсы дешевле времени создателей ПО.

раскрыть ветку (39)
46
Автор поста оценил этот комментарий

А какой раздел POSIX описывает GUI API у айоси?

раскрыть ветку (1)
5
Автор поста оценил этот комментарий

Согласно апологетам чистой системной инженерии iOS и Apple есть первородное зло, а посему недостойно даже упоминания, паче написания под него (написано с MacBook Pro M1).

8
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

О, это конь, на котором я могу скакать долго, ибо люблю.

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

И индустрия в целом от этого очень сильно пострадала - чтобы выделить толковых инженеров ("сигнал") в шуме - теперь требуется прилагать непропорционально высокие усилия.

31
Автор поста оценил этот комментарий

Эм, нет, нельзя. Ваше приложение на C не будет работать на iphone и android, речь же не про десктоп. Кроме того, кто на телефонах пользуется консолью? А GUI на десктопе будет весить уже поболее. А если вы зададитесь целью написать такое приложение, которое будет работать на разных ОС ещё, то ещё больше. Хотя тут обычно проще веб-морду написать приложению, типа как uTorrent сделали.


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


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

раскрыть ветку (8)
3
Автор поста оценил этот комментарий

Вот как раз "в память грузится не все" - довольно спорно и сильно зависит от разаработчика

раскрыть ветку (1)
4
Автор поста оценил этот комментарий

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

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

1
Автор поста оценил этот комментарий

Android - вполне себе будет, бионик можно сказать POSIX-compliant.

Если же нужна 100% совместимость (compatibility) - достаточно использовать в качестве NDK CrystaX, и будет вот прям по канону, переносимость (portability) будет идеальная (ха-ха).

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


Вопрос "зачем"?

раскрыть ветку (2)
Автор поста оценил этот комментарий

Прикольно. Правда в этом ndk последний комитет 6 лет назад.


>Вопрос "зачем"?

Ну тут какое-то теоретизирование про малые размеры приложений, на практике незачем, да

раскрыть ветку (1)
Автор поста оценил этот комментарий

Дык.
Я вот в прошлом году смотрел наши расходы в разрезе "люди/железо" - при том что наши датацентры обрабатывают петабайты и петабайты (к середине 2025 мы должны перешагнуть экзабайт), и часть из них все еще в клауде - люди составляют ¾ расходов, и только четверть - это мощности.

Даже если превратить мегабайты [исполнимого кода] в килобайты - люди все равно перевешивают.

Автор поста оценил этот комментарий

Android libc имеет одну большую "несовметимость" - отсутствие pthread_cancel(), в остальном он [почти] полностью совместим - "забавности" известы и неплохо документированы.

раскрыть ветку (2)
Автор поста оценил этот комментарий

Ну я не настолько в теме. Так-то понятно, что там в основе Linux и какая-то совместимость должна быть.

А на Айфоне будет работать? А на разных архитектурах cpu у андроида? В C же машинный код, он не будет кроссплатформенным. А ещё можно ли такое приложение в стор выложить будет?

раскрыть ветку (1)
Автор поста оценил этот комментарий

Да, вполне себе - если взять хороший NDK, изначально написанный для кросс-платформенности, типа CrystaX (https://www.crystax.net/android/ndk/)

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

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

6
Автор поста оценил этот комментарий

Используя стандарт POSIX и С вы можете написать только системную/прикладную часть, а вот для UI придется что то городить.

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

Согласно хакерскому канону UI есть искушение от лукавого - разве только emacs-style "горячие кнопки", ну или на худой конец gawk/sed-like синтаксис (который после изучения действительно безумно удобен - проблема только в "кривой обучения" для него).

Для всяких клерков и юзеров - снизойдем до какого-нибудь raygui или ftxui для сторонников уж совсем purity.

Кстати, должен отметить, что SE purity и порицание middleware и библиотек, в том числе "жирных", мне не свойственно - я очень хорошо понимаю их пользу для прикладных задач, и насколько важна их развитая экосистема для любого языка - трагедия отмирания "Минск-2" разворачивалась вот прямо перед моими глазами.

3
Автор поста оценил этот комментарий

"следуя стандарту POSIX" - это вы с ваших интернетов прочитали?

раскрыть ветку (7)
Автор поста оценил этот комментарий

Нет, это как мы долгое время обеспечивали портируемость между HP-UX, AIX and Linux. Пока не написали свою ОС.

раскрыть ветку (6)
Автор поста оценил этот комментарий

Все 3 юникс совместимые насколько я знаю и серверные. Если упор на функционал а не на графический гуй это в принципе +/- реально малой кровью. Да и то всё равно неужели ньюансы не всплывали? Неужели все прям компилилось без напильника и с полпинка? Без выбора компилятора, версии, оптимизации? вот прям хоп и портировали? Ну если что то уровня calc то я поверю (и то могут быть ньюансы багов оптимизации).

раскрыть ветку (5)
Автор поста оценил этот комментарий

Да как-то не особо что-то вспоминается, кроме необходимости отказаться от нативных оптимизированных библиотек многопоточности.

А сс, make и прочее у всех потомков System V примерно одинаковое, вплоть до ключей и параметров.

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

раскрыть ветку (4)
Автор поста оценил этот комментарий

Ну я насколько знаю есть даже сейчас немало багов при портировании и оптимизации. Неужели не сталкивались ни разу? К примеру https://habr.com/ru/articles/131615/

Я сейчас маны и тех ссылки не найду - давненько было.

Ну с нативным согласен. Но тогда выходит несколько тормознуто если это сервер.

В любом случае был гемор - не настолько что бы хопа и все чики брики.

Да и подозреваю что середнячку (особенно свеженьким) будет крайне сложно.


А тут взял яву "нахаляву", ну или сейчас же докеры шмокеры всякие разные. Развернул, настроил и таскай туда сюда виртуалки или окружение (с сопутствующими глюками - тут плачуще-смеющийся смайлик)

раскрыть ветку (3)
1
Автор поста оценил этот комментарий

Да конечно было наверняка, я вспомнил только то что в памяти само выскочило. Еще помнится на HP-UX была какая-то багофича с освобождением памяти, она освобождалась, но назад в пул не поступала... Все уже не упомнишь.

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


И тут есть еще оговорка - мы не портировали постфактум, а изначально писали портируемое.

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


Сейчас в принципе нет необходимости в таких извращениях, захотел кластер - пошел в Azure/AWS etc., взял что надо, посчитал задачу, положил итоговый массив в S3, погасил. Да и мой лэптоп сейчас по мощности как пол-датацентра тех времен.

<старперское>Нет интриги... </старперское>

раскрыть ветку (2)
Автор поста оценил этот комментарий

"вездесущего gcc" - хех, именно там на ошибку я и натыкался. И ОЧЕНЬ ОЧЕНЬ ОЧЕНЬ долго искал ее в коде.

Ошибки утечки памяти были всегда и везде. Потом попроще стало как то. Но я давно уже не слежу.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Да, он местами написан сам черт ногу сломит. И структурирован "исторически".

ещё комментарии
Автор поста оценил этот комментарий

Вы про отладочную инфу забыли, которую сборщик по умолчанию пихает в бинарник, если не выключить.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Так это ж в не релизной версии а в debug билде. Было бы странно, если бы это из релиза не выключали.

Автор поста оценил этот комментарий

закон мура уже не работает)

раскрыть ветку (1)
Автор поста оценил этот комментарий

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

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку