Здравствуйте, nekocoder, Вы писали:
N>Здравствуйте, white_znake, Вы писали:
_>>Тут вопрос в другом: а сколько будет жить сама ОС Windows и MS? У тебя как бы посыл в том, что Windows будет жить вечно, как и сама MS... Однако это может быть не так.
N>Мне не надо вечно, мне надо лет 10-15 :) N>Как мне кажется, в ближайшем будущем Windows ничего не угрожает. Какую-то часть рынка вероятно отъедят планшеты на iOS/Android, но небольшую.
И тут бац... какая-нибудь новомодная ОСь от гугла для компов и ноутов в том числе, вначале хомячки переходят, а потом и корпорации. И это может случиться и ранее 10-15 лет
Re[15]: Перспектива старых технологий (MFC, COM, ...) десктоп
Здравствуйте, Skorodum, Вы писали:
C>>Ой, ну вот не надо. Ninja — это низкоуровневая замена Make, его можно использовать прямо с CMake. GN — поделка аналогичная CMake (так как у CMake есть фатальный недостаток). S>Ну так про то и речь, что даже как генератор Makefile CMake не является стандартом.
В С++ нет стандартов сборки, но CMake де-факто ближе всего к нему.
C>>QBS — местечковое гуано. S>Не читал, но осуждаю (С) Не ожидал от тебя такого
Ага.
S>Вообще-то это универсальное средство сборки, которое изначально проектировалось для сборки любых сложных проектов. Это первое средство сборки с которым приятно работать, где видно что разработчики думали.
bash — тоже универсальное средство сборки. Как и POSIX make. И что?
C>>CMake сейчас используется в крупнейших проектах. И любая система постройки для крупного проекта будет сложной. S>Между сложной и уродливой, состоящей из костылей, есть большая разница для повседневной работы.
Все крупные системы состоят из костылей разной степени сложности. Я пока не видел ни одной полностью красивой системы сборки, которая выживает встречу с проектом на десяток миллионов строк кода.
C>>Язык у CMake уродливый, но свою задачу оно решает. S>Ну вот поэтому стандартом он не будет. Решать-то можно и Makefile'ами.
Не на уровне CMake.
C>>Как на QBS найти и подключить OpenCL? Ой, никак. Ручками пилить. S>Написать модули, которые будут искать библиотеки не проблема, только на практике смысла в этом большого нет: в реальном мире слишком много частных случаев и пути прописать руками обычно куда проще и быстрее.
Да-да. Это называется "ленивое программирование" — его фанаты Лиспа любят. Т.е. заявляем, что что-то можно легко сделать и не делаем.
S>QBS находит Qt и компиляторы, это не проблема.
Ну вот покажи как он найдёт OpenCL. В примерах же должно быть!!!!111111!!!
C>>Ну ладно с OpenCL. А как насчёт банального Boost? Ой, тоже никак. Пилите, Шура, гирю. S>Так в вашем CMake точно также! Из коробки работают только самые простые примеры Попробуйте на винде подключить boost собрынный MSVC и MinGW https://cmake.org/cmake/help/v3.8/module/FindBoost.html — в стандартной поставке уже давно.
Здравствуйте, Skorodum, Вы писали:
S>>>Не читал, но осуждаю (С) Не ожидал от тебя такого C>>Ага. S>Ну так о чем разговаривать
Ну так а зачем читать-то? Очевидно, что чисто местечковая поделка. Банального Boost'а там нет даже.
К остальным пунктам претензий нет?
Sapienti sat!
Re[2]: Перспектива старых технологий (MFC, COM, ...) десктопной Window разработк
Здравствуйте, RonWilson, Вы писали:
RW>сколько лет пишу и для linux, и для woe — но я не окошечник, поэтому позицию выражу так — библиотеки это крайне слабый аргумент на вкусную зарплату, вот совсем никак, они меняются как перчатки. Там где старый код, сколько видел нигде не используется mfc и прочие обертки, делают свою или напрямую пишут на winapi, тот же MS судя по исходникам даже во время популярности mfc его не использовал, у них свой framework для офиса к примеру, системные утили и окошковые приложения написаны только пользуясь winapi.
Приложения от M$ написаны на WPF (и уже не первый год).
Так как WinApi — такой же вчерашний день, как MFC.
И для WinApi, и для MFC — недостаток один: приходится писать много не очевидного (с точки зрения пользовательской задачи) кода.
RW>Денег дебавляет чтобы было вкусно именно умение быстро переключаться между задачами заказчика т.е. сегодня пишешь плагин для хрома, к примеру, а завтра интегрируешь продукт компании с Active Directory, ну и знание предметной области хоть немного.
Как в каких компаниях. Где-то так, где-то иначе.
Знание предметной области — также нужно, но без фанатизма. Предметного эксперта девелопер софта всё-равно не заменит.
RW>Вывод: я бы даже гроша ломаного на mfc не поставил
На сегодня эта технология действительно применяется редко где.
Лет двадцать назад — была очень популярна.
Re[2]: Перспектива старых технологий (MFC, COM, ...) десктопной
Здравствуйте, BurningInside, Вы писали:
BI>Вопрос филосовский. С одной стороны очень мало сделал. С другой стороны поставил себя как незаменимый и вытребовал нормальное рабочее место, соотвественно программы качественные у него, международный уровень.
У меня лично есть немалые сомнения насчёт выделенного.
BI>А делай он на чём-нибудь более простом в плане разработки, уж давно бы нашли ему замену в виде студента, способного скомпилировать приложение, не зависающее на запуске. А потом на его месте будет другой студент и так далее. Работодатель же не соображает, что программа если запустилась — это не значит, что она работает.
a) Пока труд этого человека устраивает Заказчика/Работодателя — он будет там трудиться.
b) Программа может запускаться и работать. Это не отменяет понятия ТЕХНИЧЕСКИЙ ДОЛГ: https://habr.com/post/119490 https://dev.by/news/o-tehnicheskom-dolge-v-softvernyh-proektah
c) Современные студенты (которые хоть что-то соображают и умеют) — в основном амбициозны и достаточно требовательны в своих запросах.
Посему — совсем НЕ ФАКТ, что пойдут работать в подобное место.
Re[4]: Перспектива старых технологий (MFC, COM, ...) десктопной Window разработк
Здравствуйте, white_znake, Вы писали:
_>И тут бац... какая-нибудь новомодная ОСь от гугла для компов и ноутов в том числе, вначале хомячки переходят, а потом и корпорации. И это может случиться и ранее 10-15 лет
без софта корпорации не перейдут. все эти siemens nxы, разного рода sapы и прочие ансисы — такое на новомодную ось если и перейдет, то в течении очень длительного срока и без всяких бац.
Re[15]: Перспектива старых технологий (MFC, COM, ...) десктоп
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, Cyberax, Вы писали:
C>>QBS — местечковое гуано. S>Не читал, но осуждаю (С) Не ожидал от тебя такого S>Вообще-то это универсальное средство сборки, которое изначально проектировалось для сборки любых сложных проектов. Это первое средство сборки с которым приятно работать, где видно что разработчики думали.
Здесь стоить заметить что команда Qt отказалась от продолжения
разработки Qbs в пользу улучшения поддержки CMake.
Re[4]: Перспектива старых технологий (MFC, COM, ...) десктоп
Здравствуйте, Osaka, Вы писали:
O>Даже если только автоматизировать в общем виде свои повторяющиеся задачи, за несколько лет "фреймворк" сам собой образуется.
Часто подобные Задачи устаревают и оказываются невостребованные, хотя ещё несколько лет назад они казались повторяющимися и незыблемыми
O>Вне зависимости, какая технология взята за основу. И заказы будут перетекать к той группе "разработчиков на МФЦ", у которой наработанные надстройки мощнее, и точнее подходят под задачи, и как следствие Окна делаются быстрее.
Вангую, что будут перетекать в группу с Qt, или даже WPF, либо ASP.NET MVC.
Здравствуйте, Zhendos, Вы писали:
Z>Здесь стоить заметить что команда Qt отказалась от продолжения Z>разработки Qbs в пользу улучшения поддержки CMake.
Это не совсем верное утверждение по двум причинам:
1. Это довольно большая компания и решения там принимает не "команда разработчиков", а менеджмент, часто по маркетинговым/политичиским причинам (source: был у них в штаб-квартире пару недель назад). Ну и в общедоступной переписке
много чего есть по этому вопросу. В обсуждаемом случае решение в пользу CMake продавливал мантейнер QtCore который вообще в Intel работает.
2. Решение "не в пользу улучшения поддержки СMake", а в пользу СMake в качестве системы сборки для Qt6.
3. Все признали, что технически qbs лучше CMake, но CMake доступнее (out of the box everywhere) и знакомее для пользователей.
Re[2]: Перспектива старых технологий (MFC, COM, ...) десктопной
Здравствуйте, BurningInside, Вы писали:
BI>Вопрос филосовский. С одной стороны очень мало сделал. С другой стороны поставил себя как незаменимый и вытребовал нормальное рабочее место, соотвественно программы качественные у него, международный уровень. А делай он на чём-нибудь более простом в плане разработки, уж давно бы нашли ему замену в виде студента, способного скомпилировать приложение, не зависающее на запуске. А потом на его месте будет другой студент и так далее. Работодатель же не соображает, что программа если запустилась — это не значит, что она работает.
У меня программа на простом средстве разработки занимает миллион строк уже. 15 лет разработки. какой нафиг студент?
Re[17]: Перспектива старых технологий (MFC, COM, ...) десктоп
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, Zhendos, Вы писали:
Z>>Здесь стоить заметить что команда Qt отказалась от продолжения Z>>разработки Qbs в пользу улучшения поддержки CMake. S>Это не совсем верное утверждение по двум причинам: S>1. Это довольно большая компания и решения там принимает не "команда разработчиков", а менеджмент, часто по маркетинговым/политичиским причинам (source: был у них в штаб-квартире пару недель назад). Ну и в общедоступной переписке
много чего есть по этому вопросу. В обсуждаемом случае решение в пользу CMake продавливал мантейнер QtCore который вообще в Intel работает.
Похоже на передергивание карт, этот сотрудник Intel имеет власть принимать решения единолично,
или все-таки у него была поддержка среди остальной команды?
S>2. Решение "не в пользу улучшения поддержки СMake", а в пользу СMake в качестве системы сборки для Qt6.
Это же еще более крутой поворот? У них же в дереве исходников куча примеров и тестов, которые по сути обычные
Qt программы, и собирая все это с помощью CMake, они по сути будут кучу проблем исправлять и делать доступным
остальным пользователям CMake, например кроссплатформенную поддержку precompiled headers, которую никак не интегрируют в CMake.
S>3. Все признали, что технически qbs лучше CMake, но CMake доступнее (out of the box everywhere) и знакомее для пользователей.
Так ведь не важно что она технически совершеннее (что кстати не факт,
ведь у нее нет большой пользовательской базы, возможно при столкновении с реальностью
в нее пришлось бы во многих местах воткнуть костыли),
важно что хоть иногда принимаются верные по совокупности фактов решения.
Ведь новую систему нужно протестировать в куче мест, написать ее поддержку для IDE,
написать документацию, долго и упорно заниматься пиаром, убедить пользователей выкинуть
код написанной для старой и написать код для новой и т.д. и т.п.,
и вот тогда встает вопрос а нужно ли более совершенная система или лучше старую улучшить?
И иногда NIH синдром все-таки пересиливают, что несомненно радует.
Re[18]: Перспектива старых технологий (MFC, COM, ...) десктоп
Здравствуйте, Zhendos, Вы писали:
Z>Похоже на передергивание карт, этот сотрудник Intel имеет власть принимать решения единолично, Z>или все-таки у него была поддержка среди остальной команды?
Welcome to the real world. Вес мнения разных людей очень разный, большинство никто вообще не спрашивал.
S>>2. Решение "не в пользу улучшения поддержки СMake", а в пользу СMake в качестве системы сборки для Qt6. Z>Это же еще более крутой поворот?
Нет. Они не будут заниматься разработкой CMake за пределами поддержки в QtCreator.
Z>У них же в дереве исходников куча примеров и тестов, которые по сути обычные Z>Qt программы, и собирая все это с помощью CMake, они по сути будут кучу проблем исправлять и делать доступным Z>остальным пользователям CMake, например кроссплатформенную поддержку precompiled headers, которую никак не интегрируют в CMake.
Они выбрали CMake именно чтобы не заниматься решением таких проблем самим.
S>>3. Все признали, что технически qbs лучше CMake, но CMake доступнее (out of the box everywhere) и знакомее для пользователей. Z>Так ведь не важно что она технически совершеннее (что кстати не факт,
Факт. Вы же сами говорите что в CMake нет таких банальных вещей как кроссплатформенная поддержка PCH.
Z>ведь у нее нет большой пользовательской базы, возможно при столкновении с реальностью Z>в нее пришлось бы во многих местах воткнуть костыли),
Qbs уже давно вышел из бета стадии. Если интересно, то по приведенным выше ссылкам есть описания промышленного использования qbs (команды 40+ разработчиков).
Самое главное, что он точно может собирать саму Qt.
Z>Ведь новую систему нужно протестировать в куче мест, написать ее поддержку для IDE,
QtCreator поддерживает qbs уже давно. Причем эта поддержака по определению лучше чем CMake, т.к. CMake всего лишь генератор.
Z>написать документацию
Есть. Не идеальная, но явно лучше чем у CMake, т.к. многие вещи куда очевиднее.
Z>долго и упорно заниматься пиаром
А вот этого они не делали
Z>убедить пользователей выкинуть код написанной для старой и написать код для новой и т.д. и т.п.,
Никто не меняет систему сборки просто так если все более-менее работает. Это актуально только для новых проектов или активно развивающихся/меняющихся проектов.
Z>и вот тогда встает вопрос а нужно ли более совершенная система или лучше старую улучшить?
Вопрос не корректный. Система нужна и она уже есть. Вопрос только стоит ли на нее переходить или нет. Универсального ответа на этот вопрос конечно же нет.
Здравствуйте, Denwer, Вы писали:
D> То выбирая Qt тебе не придется рассказывать заказчику что каждое новое сложное окно в MFC пишется по 2 дня, а то и больше.
Зато придётся предъявить ему счёт за лицензию и убедить его оплатить
AG>Часто подобные Задачи устаревают и оказываются невостребованные, хотя ещё несколько лет назад они казались повторяющимися и незыблемыми
Если взять какую-нибудь зрелую разработку на тему создания типовых окон, например редактор метаданных + конструктор форм в 1с (абстрагируемся от неудачных сторон, вроде птичьего языка "для неграмотных") — что в ней за 30 лет оказалось зыблемым? Совершенствуется, обеспечивая преемственность старых наработок. А не как у микрософта, каждые несколько лет новая банда перегораживает доступ к кормушке, выгоняет предыдущую группу, и выкидывайте все свои вложения в старую технологию — начинайте с 0 изучать новую, и переписывайте все свои наработки под неё. O>>Вне зависимости, какая технология взята за основу. И заказы будут перетекать к той группе "разработчиков на МФЦ", у которой наработанные надстройки мощнее, и точнее подходят под задачи, и как следствие Окна делаются быстрее. AG>Вангую, что будут перетекать в группу с Qt, или даже WPF, либо ASP.NET MVC.
Инструмент определяет не 100% успеха. Разве сплочённая группа опытных инженеров с мфц, написавших себе автоматизацию своих повторяющихся операций, не переработает банду живущих 1 днём обезьян с WPF?
Re[15]: Перспектива старых технологий (MFC, COM, ...) десктоп
aik>>А, ну я так и думал Не, если это не дварф, то вот конкретно для ядра лучше уж cscope, потому что его прям его же makefile собирает на основе моего конфига, т.е. нет ненужных архитектур и прочего ненужного. Z>Эээ... Вы читали что я написал? Мой вариант как раз будет учитывать только файлы которые компилируется,
Так и cscope это же делает, и для ядра оно собирается без допусилий.
Z>и там естественно не будет: >> т.е. нет ненужных архитектур и прочего ненужного
Это только часть проблемы, файлы же компилируются не целиком — спасибо препроцессору. Всё, что не использует полученные бинари, по определению инвалидское. Студийный дебагер умеет внутри многострочных дефайнов ходить, вот это тема.
Re[19]: Перспектива старых технологий (MFC, COM, ...) десктоп
Здравствуйте, Skorodum, Вы писали:
Z>>Так ведь не важно что она технически совершеннее (что кстати не факт, S>Факт. Вы же сами говорите что в CMake нет таких банальных вещей как кроссплатформенная поддержка PCH.
Фактически, это единственное в CMake, чего нет из коробки (руками PCH делается без проблем).
S>Qbs уже давно вышел из бета стадии. Если интересно, то по приведенным выше ссылкам есть описания промышленного использования qbs (команды 40+ разработчиков). S>Самое главное, что он точно может собирать саму Qt.
Можно крупные проекты на QBS? Уровня Calligra и Krita.
Z>>Ведь новую систему нужно протестировать в куче мест, написать ее поддержку для IDE, S>QtCreator поддерживает qbs уже давно. Причем эта поддержака по определению лучше чем CMake, т.к. CMake всего лишь генератор.
Не лучше. CLion не поддерживает QBS вообще, например. XCode тоже.
Тогда как CMake прекрасно генерирует для них проекты.
Z>>написать документацию S>Есть. Не идеальная, но явно лучше чем у CMake, т.к. многие вещи куда очевиднее.
Так как подключить Boost и OpenCL?
Z>>и вот тогда встает вопрос а нужно ли более совершенная система или лучше старую улучшить? S>Вопрос не корректный. Система нужна и она уже есть. Вопрос только стоит ли на нее переходить или нет. Универсального ответа на этот вопрос конечно же нет.
Я пока что не вижу никаких причин использовать сырую местечковую QBS.
Sapienti sat!
Re[6]: Перспектива старых технологий (MFC, COM, ...) десктоп
Здравствуйте, Osaka, Вы писали:
AG>>Часто подобные Задачи устаревают и оказываются невостребованные, хотя ещё несколько лет назад они казались повторяющимися и незыблемыми O>Если взять какую-нибудь зрелую разработку на тему создания типовых окон, например редактор метаданных + конструктор форм в 1с (абстрагируемся от неудачных сторон, вроде птичьего языка "для неграмотных") — что в ней за 30 лет оказалось зыблемым?
Переход от 7 к 8 версии.
O>Инструмент определяет не 100% успеха. Разве сплочённая группа опытных инженеров с мфц, написавших себе автоматизацию своих повторяющихся операций, не переработает банду живущих 1 днём обезьян с WPF?
Не переработает. Оверхед от MFC такой, что производительность часто будет на порядок отличаться. В сторону WPF.
Sapienti sat!
Re: Перспектива старых технологий (MFC, COM, ...) десктопной Window разработки
Насчёт замечания о продуктах микрософта:
Какими бы они ни были костыльными и увечными, они всё-таки в топ-е по популярности среди массового потребителя. С этим как бы и не поспоришь.
AG>>Вангую, что будут перетекать в группу с Qt, или даже WPF, либо ASP.NET MVC. O>Инструмент определяет не 100% успеха. Разве сплочённая группа опытных инженеров с мфц, написавших себе автоматизацию своих повторяющихся операций, не переработает банду живущих 1 днём обезьян с WPF?
+100500
Даже не спорю я, что группа опытных дядек с MFC окажется намного круче — как в плане теоретической подготовки, так и в плане практики.
Вот только группа вчерашних школьниц с WPF окажется дешевле.
Бизнес, с большой вероятностью, выберет второе
Да, я с сожалением признаю, что с точки зрения бизнеса окажется рациональнее — выбрать второе
Тем более, что по производительности труда они вполне могут оказаться примерно одинаковыми:
у первой группы тяжести разработки на MFC будут компенсироваться опытом разработчиков;
у второй — нехватка опыта будет компенсироваться более совершенной (и простой в применении) технологией.
Попробуйте на винде подключить boost собрынный MSVC и MinGW 
