Сокращение разработчиков Qt в Брисбене

7 пунк - самый последний

http://habrahabr.ru/post/148818/

Тулкит это сменная насадка на клепатель гуёв и от него требуется лёгкая сборка и линковка, у кути они совсем не лёгкие.

Сборка самого Qt — классическое "./configure && make", причём обязательных зависимостей самый минимум, т.к. [почти] все нужные сторонние библиотеки лежат в архиве; сборка кутешной программы — «qmake && make». Куда проще-то?

Это тебе не Gtk+ с его десятком отдельно скачиваемых (с попутной проверкой номеров версий) зависимостей, которые надо ещё собрать и установить в правильном порядке. А для приложений сложней хелловорлдов придётся ещё потр@хаться с автотулзами или чем-нибудь подобным.

Ну и стабильность апи тоже нужна и без разницы, сишное оно или плюсовое.

Список поломок Qt-шного API при минорных обновлениях в студию!

Какие там есть аналоги для замены Qt-шных layouts и spacers?

Там есть т.н. anchors, но до кутешных лэйаутов им как до Марса на четвереньках.

А на чём же MS будет делать Skype для Linux??

А зачем MS делать Skype для Linux?

Процитировав анонимуса, возможно себя же, ты автоматически побеждаешь в споре. Какой няшный петушок :3

по делу снова нечего сказать? кудахтай дальше.

И это говорит мне тот, кто в качестве доказательства процитировал оригинальный вброс :}

А для приложений сложней хелловорлдов придётся ещё потр@хаться с автотулзами или чем-нибудь подобным.

CCFLAGS = `pkg-config --cflags --libs gtk+-3.0`

На WPF.

WPF и WinRT с XAML'ом.

А как быть со старым оборудованием с Win2k? Оно работает, свои функции выполняет. Qt вполне себе работает на win2k.

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

Часть работы и в современных веб-приложениях выполняется локально (всеми любимый JS), и потом сабмитится на сервер.

Ты для всех программ мейкфайлы вручную пишешь?

У Львове закрыли магазин ноклы. Вангую ноклокапец.

Не читали вторую часть поста? GTK интересен как раз тем, кому нужна сменная насадка.

Пробовал вместо GTK насадить на клепатель гуёв Qt, секс имеется, выглядит чуть красивее но потраченное время и неудобства наврят ли того стоят. Может потом станет попроще, но к тому времени скорее всего допилится альтернативный и более универсальный тулкит.

и великолепную документацию с примерами

На буржуйском.

Работает везде, даже на android и ios, причём соблюдает HIG платформы, располагая меню где следует и рисуя виджеты как следует.

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

Очень хорош для многопоточного программирования.

А плюсы очень хороши для многопоточного торможения при компиляции и какбэ намекают: вложи в железо пару кусков баксов, ощути нирвану.

Множество утилитных классов

И все плюсовые. Нет уж, спасибо, своих классов много и только больше становится.

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

Если надо что-то мелкое и нерассыпчатое на С/С++, то можно вкомпилить это статически в программу на другом языке.

На буржуйском.

Жесть! Мегааргумент! Ты как вообще программируешь то?

А плюсы очень хороши для многопоточного торможения при компиляции и какбэ намекают: вложи в железо пару кусков баксов, ощути нирвану.

А вот и паскальщики подтянулись)) А твои любимые мнговенно компилящиеся ЯП как бы намекают - вложи в железо ещё пару штук и твоя прога не будет тормозить.

сборка кутешной программы — «qmake && make». Куда проще-то?

Сборка вообще без make, одной коммандой вида «компилятор исходник пути_к_либам пара_опций».

Это тебе не Gtk+ с его десятком отдельно скачиваемых (с попутной проверкой номеров версий) зависимостей, которые надо ещё собрать и установить в правильном порядке.

Да, это веселуха, собирал для гимпа.

А для приложений сложней хелловорлдов придётся ещё потр@хаться с автотулзами или чем-нибудь подобным.

Иде должно обеспечивать прослойку между тулкитом и клепателем формочек.

Список поломок Qt-шного API при минорных обновлениях в студию!

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

сборка кутешной программы — «qmake && make». Куда проще-то?

Это при наличии .pro-файла. Который, конечно, можно сгенерировать, ага.

А проще - вот:

ghc --make $ProgramMainModuleName.hs

Жесть! Мегааргумент! Ты как вообще программируешь то?

Мы с компилятором отлично понимаем друг друга:) Консольное иде на буржуйском, у высокоуровнего отличный русский интерфейс, русскоязычной документации много, недостающую можно и перевести, в чём проблема то?

А твои любимые мнговенно компилящиеся ЯП как бы намекают - вложи в железо ещё пару штук и твоя прога не будет тормозить.

Логика у тебя не в порядке: если программа показывает хорошие результаты при компиляции и тестах на медленном железе, то с чего она будет тормозить на более быстром? А с учётом того, что нормальный язык не требуется разбавлять скриптотой, то получается что тормозят именно плюсы нафаршированные джаваскриптами и питонами с рубями.

Не забывай, что GTK развивают преимущественно люди, которые делают вот это.

Да ладно, нормальные нововведения :D Главное, чтобы они не додумались нововводить то, что в будущем может конфликтовать с пустотой.

Я бы не назвал изделие Торвальдса поделкой первокурсника. И это лишь один из множества примеров.

Ничего не случится с GTK даже если умрет RedHat, сообщество поддержит GTK

Да ну? А ничего, что это самое сообщество Gtk+ ныне почти в полном составе сидит на зарплате в RH? И если после такого Gtk+ вроде как выживет, то почему не выживет Qt, который находится в ведении Qt Foundation? Да, Nokia самый крупный контрибутор кода в Qt сейчас, но что это меняет в перспективе?

Логика у тебя не в порядке: если программа показывает хорошие результаты при компиляции

скорость компиляции хорошая, а скорость работы никуда. Думай, думай.

Си и Си++ да, долго компилятся, но потом проги летают.

На буржуйском.

А что, на Gtk+ третьей ветки в природе существует что-то на русском? О_о

Си и Си++ да, долго компилятся, но потом проги летают.

вылетают

obvious fix

Я так понял он про Lazaurus говорит. Но это не проблема, приводить в качестве аргумента отсутствие документиции на русском будет только красноглазый школьник.

вылетают

не без этого)) а на чём не вылетают? моя хотеть такой языка!!!

вася ты гонишь, это же виндосвосимь приложения. в браузерах они не работают понял да ...

Я так понял он про Lazaurus говорит. Но это не проблема, приводить в качестве аргумента отсутствие документиции на русском будет только красноглазый школьник.

Про документацию на русском всем всё понятно, но если он всё же вёл речь о Gtk+, то пассаж о буржуйском языке тянет на фейспалм фейспалма...

русскоязычной документации много

у Qt много русскоязычной документации на crossplatform.ru, и статьи на самых разных сайтах включая хабр. У тулкита, идущего с фрипаскалем, как и у других тулкитов, такого нет.

Логика у тебя не в порядке: если программа показывает хорошие результаты при компиляции и тестах на медленном железе, то с чего она будет тормозить на более быстром

Матчасть подучите. Ах да, ещё раскройте глаза и посмотрите на современное ПО: это в большинстве своём не вычислительные задачи, и потоки ему нужны вовсе не для более быстрых вычислений, а для отзыва на действия пользователя и события внутри программы, на серверах - отзыв на сетевые события. Вы не знаете, причём тут многопоточность? Матчасть!

А распараллеливание вычислительной задачи в любом языке легко делается.

Ну а насчёт скриптов - видимо паскалисты ещё просто не доросли со своими программами до необходимости их применения. Случаев, когда на C++ применяют скрипты, а паскалист мог бы без них обойтись, нет.

Пробовал вместо GTK насадить на клепатель гуёв Qt, секс имеется, выглядит чуть красивее но потраченное время и неудобства наврят ли того стоят.

Я говорил или нет, что GTK как раз и нужен тем, у кого своя система виджетов и нужно только общение с системой? Говорил. Я прекрасно знаю, что в таких случаях важен сишный API, не надо быть КО.

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

скорость компиляции хорошая, а скорость работы никуда. Думай, думай.

Спасибо, рассмешил, жги ещё.

Си и Си++ да, долго компилятся, но потом проги летают.

Особенно процесс плазма_десктоп летает, но он хотя бы работает а игры с десуры - 50/50.

А что, на Gtk+ третьей ветки в природе существует что-то на русском? О_о

Третья ветка пока не нужна а у второй документация нужна авторам биндинга к иде для формошлёпства.

Спасибо, рассмешил, жги ещё.

Твои аргументы?

У тулкита, идущего с фрипаскалем, как и у других тулкитов, такого нет.

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

Ах да, ещё раскройте глаза и посмотрите на современное ПО: это в большинстве своём не вычислительные задачи, и потоки ему нужны вовсе не для более быстрых вычислений, а для отзыва на действия пользователя и события внутри программы, на серверах - отзыв на сетевые события. Матчасть!

Вот именно, подучи матчасть. Лазарус и фрипаскаль развиваются по большей части усилиями клепателей морд к базам данных, поэтому с этим там всё в порядке. Скорость нужна пользователям десктопов которые не хотят обновлять железо каждые 2 года только для того чтобы окошки не тормозили и им на твоё «современное ПО» начхать.

А распараллеливание вычислительной задачи в любом языке легко делается.

Если задача простая.

Ну а насчёт скриптов - видимо паскалисты ещё просто не доросли со своими программами до необходимости их применения. Случаев, когда на C++ применяют скрипты, а паскалист мог бы без них обойтись, нет.

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

Твои аргументы?

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

Ну и хрен с ним. Все равно Qt5 и QML не торт.

подумать и вынести логику в скрипты для экономии часа на компиляцию.

4.2, никто не пишет скрипты ради экономии времени компиляции

Если задача простая.

свой же паскаль хаете

Скорость нужна пользователям десктопов которые не хотят обновлять железо каждые 2 года только для того чтобы окошки не тормозили и им на твоё «современное ПО» начхать.

У вас чтение на уровне ключевых слов? Если изложенное ниже будет для вас новостью, советую таки-подучить матчасть или хотя бы не реагировать так бурно на фразу «современные программы», приплетая сюда все личные проблемы.

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

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

Типичная среда вычленяет токены сразу, повторяя лексический разбор после каждого ввода символа и используя его для подсветки ключевых слов, чисел, операторов и т.д. Инкрементальная подсветка - отдельный разговор, не будем. Парсинг - более тяжёлая задача, даже жёстким урезанием меньше чем в 5-10 мс не уложится, а может и 50 выйти. Хитрят: после ввода символа вешают таймер на 150-200 мс, если введён ещё символ - таймер, естественно, обновится. Но рано или поздно программист перестанет печатать и задумается или переключается на что-то, тут-то и сработает парсинг и начнётся третий этап. Семантический анализ, проверки, семантическая подсветка идут в отдельном потоке с пониженным приоритетом, в основной поток идёт только результат. Кстати, outline, автодополнение и completion assistant тоже используют данные семантического анализа. Может занять полсекунды, и не ускорить никак - и так теоретические ограничения уже близко.

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

А ещё есть программы, которые действуют исходя из доступных ресурсов и потоки запускают при наличии свободных ресурсов. Пример - ядро линукс, как ни странно, и игры. Да, это не укладывается в головы многих программистов, но идеальная программа меняет своё поведение, учитывая свободные ресурсы и запоминая действия своего пользователя.

P.S. Вы сами признали, что freepascal используют для морд к базам данных, где об асинхронности уже подумали за программиста. Во многих областях сделать асинхронность за программиста не получается, программисту приходится самому делать это с учётом задачи средствами фреймворка. И тут на помощь приходит Qt. Так что же не так с Qt?

Все равно Qt5 и QML не торт.

Там хороший webkit обещали.

Ну и хрен с ним. Все равно Qt5 и QML не торт.

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

Нормальную скорость я наблюдаю

Это смотря для чего, если у тебя не затратное приложение, то и паскаль пойдёт. Просто, на мой взгляд, он как язык убожество. А многие мои приложения, которые я пишу по работе, переодически грузят проц под 100%, а тут твой паскаль просасывает полностью и с этим ты не поспоришь - ибо он тормоз от природы.

Как ты думаешь, если гимп или опенофис переписать на паскале или питоне, кто нибудь сможет ими пользоваться?))

а кому нужен ассемблер, тот может его использовать в процедурах

И да, ассемблер тут ни при чём.

Просто, на мой взгляд, он как язык убожество

Аналогичного мнения о плюсах.

А многие мои приложения, которые я пишу по работе, переодически грузят проц под 100%, а тут твой паскаль просасывает полностью и с этим ты не поспоришь - ибо он тормоз от природы.

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

Как ты думаешь, если гимп или опенофис переписать на паскале или питоне, кто нибудь сможет ими пользоваться?))

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

И да, ассемблер тут ни при чём.

Для оптимизации узких мест может пригодиться - кодек там какой напейсать, драйвер или рендер.

Для оптимизации узких мест может пригодиться - кодек там какой напейсать, драйвер или рендер.

Не стоит забывать про ia32/amd64/arm/mips/etc с кучей всяких опциональных расширений. Или пишем только для себя?

кинелерру для федоры за несколько лет так и не смогли собрать, вот такой твой язык тормоз

Не вижу связи.

4.2, никто не пишет скрипты ради экономии времени компиляции

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

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

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

Так что же не так с Qt?

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

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

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

Запросто

Ты жуткий троль))) А когда я в гимпе захочу наложить сложный эффект на 10Мпиксельную фотку, то буду ждать день))) Конечно время компиляции тут приоритет и юзер только о нём и думает)))

Не тупи)

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

Проблемы негров шерифа не волнуют.

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

Таких задач не очень много.

Ты жуткий троль))) А когда я в гимпе захочу наложить сложный эффект на 10Мпиксельную фотку, то буду ждать день))) Конечно время компиляции тут приоритет и юзер только о нём и думает)))

Ты вообще в курсе что многие сложные эффекты в гимпе написаны на скриптоте а сам гимп наполовину состоит из сторонних библиотек? Эти геглы, баблы, libpng, libjpg можно не только линковать динамически но и вкомпиливать статически в прогу на паскале, при этом медленнее они работать не станут. Быстрее могут - внутри бинарника используется единый менеджер памяти. Есть графический редактор на питоне, паскаль быстрее минимум на порядок, поэтому больших проблем не вижу. В конце концов, если захочется ООП и быстро, то всегда можно заюзать объекты вместо классов - они линкуются в памяти статически и работают быстрее, главное чтобы оперативки хватило. Быстрая компиляция облегчает тестирование что важно при отладке и в, случаях когда лень считать, быстрее проверить несколько вариантов.

Не тупи)

Тоже самое могу сказать и тебе.

Ты вообще в курсе что многие сложные эффекты в гимпе написаны на скриптоте

Скрипты в гимпе это интерфэйс к его внутренним Си-шным либам. Они дают тебе большую абстракцию и всё.

всегда можно заюзать объекты вместо классов

Поясни.

Есть графический редактор на питоне

Где 99% кода на Си, знаем ))) Тот же самый NumPy поковыряй для примера.

Я не понимаю, ты хочешь доказать, что скорость компиляции важнее скорости исполнения? Оглянись вокруг - 99,9% приложений написаны на Си и Си++. А ты говоришь, что ресурсоёмкие приложения редки )))

Если я пишу нересурсоёмкое сетевое приложение и написаить надо быстро, то возьму питон или перл, если нужна скорость работы то Си. Паскалю нет места в этом мире - не рыба, не мясо.

У него нет плюсов и гибкости скриптов и нет скорости Си.

Так на Qt. Qt то не исчезнет, если прекратить его финансирование. Просто его развитие станет менее динамичным.

всегда можно заюзать объекты вместо классов

Поясни.

Компилятор fpc поддерживает несколько диалектов паскаля, в одном проекте можно использовать несколько из них. Пишешь в начале исходника {$MODE FPC} - пишешь на фрипаскале, если {$MODE OBJFPC} то на объектпаскале, а если {$MODE DELPHI} то на дельфийском. На фрипаскале используются не классы а объекты, они пишутся чуток по другому и работают быстрее, естественно стандартными, классами из этого исходника уже не попользуешься, ими нужно пользоваться из исходника на другом паскале:)

Где 99% кода на Си, знаем )))

А ты думаешь в паскале нет ни одного 1% кода надёрганного при компиляции из системы? Много использовать нельзя, слишком глючный, но некоторое количество имеется.

Я не понимаю, ты хочешь доказать, что скорость компиляции важнее скорости исполнения?

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

Оглянись вокруг - 99,9% приложений написаны на Си и Си++. А ты говоришь, что ресурсоёмкие приложения редки )))

Вот прямо счас залезу в менюшку и запущу косынку с сапёром, ага. Когда вышел маздай 3.11, про него говорили что это солитёр весом в 30 метров, столько веса потребовалось чтобы запустить новую, ресурсоёмкую, версию приложения.

Если я пишу нересурсоёмкое сетевое приложение и написаить надо быстро, то возьму питон или перл, если нужна скорость работы то Си. Паскалю нет места в этом мире - не рыба, не мясо.

В _твоём_ мире, в другом он вполне успешно развивается и мелкософт туда не говнокодит.

У него нет плюсов

К окулисту сходи.

и гибкости скриптов

Сколько угодно - используй великое goto и ощути его силу!

и нет скорости Си.

Использовать побитовые сдвиги вместо умножения на 2 можно и там если заняться больше нечем. А с учётом того, сколько сил gcc тратит на парсинг и оптимизацию сишного страшилища, дальнейшие перспективы прироста скорости в тумане. В паскале же нормальный синтаксис который облегчает оптимизацию компилятора, что и происходит.

Не стоит забывать про ia32/amd64/arm/mips/etc с кучей всяких опциональных расширений. Или пишем только для себя?

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

кинелерру для федоры за несколько лет так и не смогли собрать, вот такой твой язык тормоз

Не вижу связи.

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