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

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

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

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

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

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

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

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

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

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

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

Прочитал. Я не программист и и у меня вопрос к ТС вот за этот абзац

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

За вот это всё отвечает ОС и прграмма прежде всего с ней взаимодействует.

Где-то, на мой взгляд, логика нарушена.

раскрыть ветку (68)
245
Автор поста оценил этот комментарий
Логика нарушена в том месте, где автор начал утверждать, что в каждое приложение нужно "засунуть" драйвера для сотен разных устройств. Автор не знает, что это забота операционной системы.
Короче, поумничать хотел, но...
раскрыть ветку (41)
61
Автор поста оценил этот комментарий
Автор, наверное, программировал только в ДОСе, будучи ещё судентотой, ну и в НИИ каком-то, а сейчас уже давно сединами на пикабу светит, сидя на пенсии. Вот в ДОСе - там, да, не написал сам драйвер для чего-то из сотен и тысяч видюх, звуковух, жойстегов, и прочая, и прочая - значит, что этого самого у тебя нет и не будет. А в современных системах, где драйверами заведует сама система, а погромист может вообще не знать ничего об оборудовании, общаясь с ним через абстракции, предоставляемые тоже системой, ныть о том, что размер приложения надо раздувать ради включения в него всего зоопарка драйверов - это бред сивой кобылы в солнечный полдень. В конце концов, сегодня интернет есть у всех. Нужен тебе ебейший, охереть насколько лучше системного, драйвер - ну подгрузи ты этот один драйвер из интернета, никто и не заметит. Ещё в древней 95 винде (да и в 3.х тоже, а, может и раньше), она же маздай, дрова по одному с дискет и сидюков ставили, лол. А этому кренделю сразу весь интернет, видимо, в свое охуеть какое важное приложение всунуть надо. И, к сожалению, не треснет. (
раскрыть ветку (10)
10
Автор поста оценил этот комментарий
Категорически с вами согласен. ☝️
7
Автор поста оценил этот комментарий

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

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

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

О да. Прописывать путь к дровам на СД в автоекзеке и конфиг сус, что б привод заработал и ты смог винду переустановить. Ну или 3 флопика на копии выделять потому что слетали постоянно)))

раскрыть ветку (3)
Автор поста оценил этот комментарий
Конкретно драйвер на CD состоял из двух частей - собственно драйвера, он прописывался в 'config.sys' (для каждого привода он мог быть свой, но потом привода стали более-менее стандартные, и драйвер почти всегда выдавал, что он 'oak') и программный интерфейс к нему - он загружался (и, сцуко, отжирал чуть обыкновенной памяти даже через 'loadhigh') через 'autoexec.bat', в последних версиях ДОСа и, ЕМНИП, с мадзайками шел комплектно и назывался 'mscdex.exe'... Я уже лет, что бы не ошибиться, 15 точно, а, может, и все 20, не ставил и не настраивал ДОС, тем более маздайку. Вот и нахрена я это до сих пор помню?
раскрыть ветку (2)
Автор поста оценил этот комментарий
Конец 90-х был))) Это потом уже, когда жестак стал 20 гигов, а не 2,5, я тупо дистрибутив винды хранил. 98 у нас край три месяца жила.
раскрыть ветку (1)
1
Автор поста оценил этот комментарий
Помню, помню. У меня на первом компе, который мне купили, был хард на целых 1.27 Гб, что по тем временам было намного больше, чем простые 1.2 и, тем более, 1.1. потом у меня был комп с хардом на 80 Гб от сигейта, он, зараза, через пару лет сдох. Вот обидно было, там вместе с ним помер фидошный архив, ну и некоторое количество всякого, тогда очень важного и нужного файла. ) С тех пор сигейта недолюбливаю и не покупаю, потому что обиделся. )) Последний покупал WD давно уже. )
4
Автор поста оценил этот комментарий

А что если все программисты этого не знают и реально пихают в каждую программу/приложение кучу драйверов развудвая тем самым объем приложения?

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

Просто ТС пиздобол уровня BolgenOS

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

Как пища для размышления - есть Google Camera . И работает она только в основном на гугловских пикселях и с некоторыми модификациями еще на малой части телефонов.
Казалось бы, в чем проблема, если программа взаимодействует только с ОС ?

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

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

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

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

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

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

2
Автор поста оценил этот комментарий
Комментарий удален. Причина: данный аккаунт был удалён
3
Автор поста оценил этот комментарий

Да весь пост хуета беспросветная. Кроссплатформенная разработка очень не популярна. Особенно в больших компаниях. Я только в ЖП Морган видел вакансии под Реакт Нейтив. Про 5 разрабов на банковское приложение поржал еще сильнее. В местах, где я работал, пока компания была условно небольшая, было по 15 человек на каждую мобильную платформу. А как только пошли деньги, так сразу стало по 100 айосников и андроидщиков. Ага, это на одно приложение на двух платформах.

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

Кроссплатформенная разработка очень не популярна.

Иногда лучше жевать, чем говорить.

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

Ну, посмотрите вакансии на айос разработчиков, потом на андроид разрабов, а потом поищите вакансии на «мобильщиков». Их очень и очень немного.


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


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

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

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

У нас, например, бэк должен был работать и на windows-серверах и на unix, и писала его одна команда.

Что касается мобильщиков - насколько я знаю там да, обычно разделяют разработку под andorid и под iOS. Хотя кое-где и объединяют. Зависит от масштабов проекта.

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

Если речь о числе именно разработчиков, то это 40+ команд без бэкенда. Я могу поверить в такие цифры на примере одного не самого крупного государственного банка. КПД разработки при этом катастрофически низкий, фонд оплаты труда только на мобильные приложения исчисляется сотнями миллионов рублей в месяц. Разработчиков при этом можно добавлять до бесконечности, ни скорость разработки, ни качество продукта не улучшатся. Но банки, особенно государственные, могут себе позволить неограниченный бюджет. Компании для которых программные продукты основной вид заработка деньги считают, и там с оптимизацией процесса все сильно лучше.

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

Я работал в частном финтехе, сейчас там уже я думаю по 120 мобильных разрабов на платформу, но приложений уже по факту 3. Но над главным работает, наверное, 3/4. Фичевых команд без бекенда там не было - в банке все же все завязано на данные. И работы было дохренища, лишних людей не было. Над инфрой (это команда платформы и дизайн системы) ну человек 6-8 работало. Что тут под КПД понимать не понятно. Фичи достаточно быстро выпускались. Намного быстрее, чем в бигтехе.

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

За вот это всё отвечает ОС и прграмма прежде всего с ней взаимодействует.

Вот только в разных ОСях разное АПИ.

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

раскрыть ветку (1)
Автор поста оценил этот комментарий
Большинство популярных и востребованных опен-соурсных библиотек перенесли подо всё: OpenSSL, ffmpeg, ...
ещё комментарии
Автор поста оценил этот комментарий

не обращайте внимания на логику, этот текст не для вас

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