> Код в qTox написан целой командой людей, которые пытаются подогнать его под
> один стандартный вид, поэтому он отлично читаем, так что ваши замечания
> неуместны в данном случае, вообще.Пожалуй соглашусь. И все же uTox мне чисто по человечески милее, сорян. Мелкая, аккуратная прога, где авторы занимались чем-то еще кроме экономии своего времени - это хорошо. Единственный аналог который я могу представить себе - миранда разве что. Но оно, увы, виндовое. Однако у меня оно в свое время весило раза в два меньше апэкашки на 20 мег, а умело раз в 30 больше - с дюжину протоколов и архинавернутый кастомизабельный гуй.
> Этим страдают такие клиенты как Antox, Trifa и многие другие, которые были
> написаны без какого либо планирования и рефакторинга.
Да этим вообще каждый второй проект на плюсах страдает. Я не спорю что бывают мощные плюсовики с головой на плечах, даже знаю таких - и даже могу вдуплить в их код. Потому что они заботились об этом и знали когда пора уже угомониться с абстракциями. Но понять кто перед тобой в си++ довольно сложно. А если еще размахивают QMLями - провоцирует вебмакакинг, программы в результате получаются стремные. Тяжелые, рапидно накорябаные, отделить кондовый проект с качественными плюсовиками от рапидчиков трудно. Я думаю что нокия и дигия оказали мощным плюсовикам с кутями медвежью услугу этим самым, теперь хрен поймешь где по сути вебманки а где плюсовики.
> Чушь полнейшая. Ещё как страдают,
На сях сложные абстракции неудобно наворачивать. Хоть при сильном желании и можно, как гномеры какие. Но таки discouraged на уровня ЯП :P.
> только в C проектах эти абстракции выглядят иначе и ещё более громоздкими,
> потому что в языке недостаточно фич, чтобы написать код максимально компактно,
Это провоцирует упрощение абстракций. Что хорошо и правильно с точки зрения въезда в чужой код, и отсутствия оверинжинерии. А то я видал тут код на плюсах - автырь завел с дюжину типов стрингов, на разные оказии. Удачи что-то поменять в ЭТОМ :). Для этого придется стать наполовину тем чокнутым прогером и вгрузить половину его башки. Итог печальный - это был рефактор, автырь отфакапил проект. Когда он задолбался, не осталось никого, кто мог и хотел бы менять этот код, а откатывать на версию эн летней давности тоже не айс по другим причинам. В итоге все кто от этого зависел - влипли.
> поэтому код в uTox нечитаем абсолютно и выглядит как каша, ну и ещё потому
> что общее качество кода низкое.
У некоторых плюсовиков специфичные представления о качестве кода и абстракциях, имхо.
> Чистый C собирается быстро, только потому что в нем
> нету фич, а не потому что на C лучше C++.
Ну так логично: навернули фичи -> получите тормоза. А когда в результате этими абстракциями начинают глушить везде, оптом, оно еще и работает не сильно лучше софта на электроне потом.
> у Qt строгая политика, что мажорные весрии ПОЛНОСТЬЮ совместимы
Как же они полностью совместимы, если часть программ в результате не получилось перетащить простым перекомпилом? Майнтайнерам тоже не больно охота два кути содержать, было бы все именно так, 4-й куть выкинули бы.
> и это переходы между версиями происходят раз в 5 лет.
Увы, это все где-то в теории. А на практике у меня в системе болтается две кути. Вот зачем бы мне их две, почти одинаковых? :) При этом половина софта еще и RAM не может реюзать по либам.
> отличии от GTK, где каждое новое API абсолютно несовместимо со старым.
Гномеры в последнее время вообще с катушек слетели, спору нет.
> Ну, во-первых, Qt опенсоурснут, а во-вторых, сравнивать Qt с электроном - это
> настоящий маразм. У них даже принцип работы другой, причем абсолютно.
Что у электрона что у QML примерно одни и те же (анти)паттерны и целевые аудитории - рапидчина. Просто электрон сделал это суровее и довел до абсолюта. Плюсы вообще нафиг, памятью рулить не то что не надо, но и нельзя, ну и рантайма не 20 мегов а поболее.
> Все что электрон уделал за период своего сущетвования - это здравый смысл.
Я бы очень хотел с этим согласиться, но продвигаемые QML (анти)паттерны на электроне смотрятся еще логичнее и уместнее :P
> Каждое мелкое приложение - веб-браузер с нативной отрисовкой гуя. В данном случае
> вы правы про "этсамое".
На андроиде с либами как я понимаю не очень - и кутевая прога принесет "всего" пару десятков мегов либ. И так каждая прога. По сравнению с электроном это, конечно, апгрейд, но общая идея не так уж и отличается, особенно с QML и всем таким.
> Я откуда знаю? Может быть софт в репозиториях годами не обновляется, либо
> разработчики решили, что у них нет причин (лень) обновляться на Qt 5?
> В моей системе софта на Qt4 вообще уже нет.
У меня система обычный дебиан. Можно убунту, если хочется. И таки они прилагали усилия чтобы уйти с куть4 на 5, но увы - теория от практики тем и отличается, что в теории полностью совместимы, на практике пришлось две версии либ оставить. И я как-то не готов выпилить XFLR5 допустим, только за то что он на 4-м куте. А на что его такой заменять? :D
> Qt очень быстро стартует, просто проги на нем делают много поворотов, но Qt тут не при чем.
На самом деле - зависит от программ еще. В ряде дистров куть более-менее модуляризовали. Однако мощная либа провоцирует юзеж всего и вся на каждый пшик, поэтому иной раз даже тривиальные программы прут огроменные зависимости. И стартуют соответственно. И если запуск мощного када цать секунд я еще понимаю, то от мессенджера мне хочется все же не того :)
> По вашему, быстрая разработка - это обязательно плохое API?
По моему, быстрая разработка, это:
- Низкое качество кода. Внимание к деталям идет к дьяволу, и это вылезает на ВСЕХ уровнях.
- Низкое качество софта в целом - если гнали как на пожар, тестировать и тем более багфиксить не было частью плана. Это нудно, канительно и не эпично от слова вообще.
- Грабли с архитектурой, майнтенансом и прочими глупостями. Если гнать на пожар, зачем тратить время на продумывание архитектуры и тем более заботиться проблеами окружающих?!
- Проблемы с безопасностью. За програмера подумает компилер и/или рантайм. Мозг включать не надо! В результате попадаются фееричные приколы, типа eval() на входных данных в битмесадже. Гм, сишник так еще ухитриться должен.
> Существование хорошего API и быстрой разработки на нем вместе не рассматривается.
Хорошее апи != хорошая программа. А если в результате либа начинает провоцировать разработку стремной рапидчины, наверное, это уже не очень хорошая либа. Даже если апи и неплохое, качество софта в результате сливается.
