Судьба Qt

> А количество пробелов как человеческий глаз считает, с точки зрения эргономики? :)

на уровне рефлекса.
сам попробуй - вот тебе примеры на яве
http://jqueryjs.googlecode.com/files/jquery-1.3.2.min.js (это без отступов)
http://jqueryjs.googlecode.com/files/jquery-1.3.2.js (с отступами)

> Поскольку Кути_не_нужно

Аха, а гуй на чем писать ? на стремном GTK ? QT как раз замечательно дополняет плюсы. А фраза "Не надо ++ везде пихать" == "Не все могут их Осилить".

> пистон и пр., это, право, несерьезно

я вижу, ты серьёзный парень

Кто там выдавливает на C++ в тёмных углах и стеновых нишах?

> вот тебе примеры на яве http://jqueryjs.googlecode.com/files/jquery-1.3.2.min.js (это без отступов) http://jqueryjs.googlecode.com/files/jquery-1.3.2.js (с отступами)

ужос какой... 40К символов в строке убили

QtD, по-моему, это самый разумный вариант

> QtD, по-моему, это самый разумный вариант

Он был основан на QTJambi, если я правильно помню, который умер. Поэтому не думаю что и QtD проживет очень долго.

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

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

При этом вы не можете назвать альтернативу, замену так сказать, этому язык. Безотносительно Qt. В принципе нет языка, который смог бы заменить C++.

Так что хватит нести чепуху.

Прям уже и умер. Его передают сообществу.

> Так уж получилось, что C++ умирает. Вернее не умирает, а его постепенно выдавливают из всех ниш, которые он занимал или мог бы занимать

Пишите на тех языках коими выдавливают(!) С++. Это же очевидно ;)

//wbr Капитан Очевидность

PS: Как узнаете, какие языки выдавливают С++ -- сообщите. Посмеямся всем ЛОРом :)

> Как узнаете, какие языки выдавливают С++ -- сообщите.

Ява и C# - в Ынтерпрайзе, куча всего от Питона до Хаскеля - в свободном софте.

> Посмеямся всем ЛОРом :)

Не всем.

> Ява и C# - в Ынтерпрайзе,

два монструоза

> куча всего от Питона до Хаскеля - в свободном софте.

переносимость на нуле

>> Ява и C# - в Ынтерпрайзе,

> два монструоза

Это уже второй вопрос.

>> куча всего от Питона до Хаскеля - в свободном софте.

> переносимость на нуле

У Питона нормальная переносимость. У Хаскеля и прочих - не особо, но на практике переносимость и не нужна. All the world is x86. Ну еще amd64, но с переносимочтью туда - всё в порядке.

Разаработчиков на приплюснутых постигнем моя участь :)

> У Питона нормальная переносимост

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

Да и вообще писать вещи типа Qt на Python - маразм (благо никому такое в голову не приходило). Другое дело через привязку работать

> All the world is x86. Ну еще amd64, но с переносимочтью туда - всё в порядке.

Весьма скудный у вас внутренний мир однако. Windowz only вестимо? :)

wbr: Капитан Очевидность, какбе намекает на arm(!)?

>> All the world is x86. Ну еще amd64, но с переносимочтью туда - всё в порядке.

> Весьма скудный у вас внутренний мир однако.

Не у меня и не внутренний.

> Капитан Очевидность, какбе намекает на arm(!)?

Передай Капитану, что как минимум Питон и Моно там работают.

> У Питона нормальная переносимость. У Хаскеля и прочих - не особо, но на практике переносимость и не нужна. All the world is x86. Ну еще amd64, но с переносимочтью туда - всё в порядке.

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

> Производительность

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

>> на практике переносимость и не нужна. All the world is x86. Ну еще amd64, но с переносимочтью туда - всё в порядке.

> не всегда не нужна

Не всегда, но обычно.

> ту же программу на питоне можно без проблем запустить на симбиане или винмобайл

Даже если она использует, скажем, Gtk или Qt? Или Postgres, да хоть SQLite?

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

Вы питоновские приложения под gtk юзали? Это же такой тормоз, что хоть вешайся.

> Даже если она использует, скажем, Gtk или Qt? Или Postgres, да хоть SQLite?

> http://www.sqlite.org/mostdeployed.html:

Now let's consider where SQLite is used:
...
20 million Symbian smartphones shipped in Q3 2007 [5] Newer versions of the SymbianOS have SQLite built in. It is unclear exactly how many Symbian phones actually contain SQLite, so we will use a single quarter's sales as a lower bound.

> Вы питоновские приложения под gtk юзали? Это же такой тормоз, что хоть вешайся.

Криво написать на чём угодно можно. Если ты на скрипке играть не умеешь, то причём тут Страдивари?

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

>Вы питоновские приложения под gtk юзали? Это же такой тормоз, что хоть вешайся.

Давай сравним приложения аналогичного класса - deluge (Питон) и linuxdcpp (C++).

Худей, сейчас пост!

>>другие еще не устраивают

>Все-все?

Он просто стесняется сказать что ему нужен язык с музыкальным названием C#

> Вы питоновские приложения под gtk юзали? Это же такой тормоз, что хоть вешайся.

юзал и юзаю(gajim,deluge,exaile) и сам написал не одно. отлично всё работает

> Он просто стесняется сказать что ему нужен язык с музыкальным названием C#

Ха, для моно оказывается тоже биндинги были, но вот беда, использовали они также QTJambi :) Похоже не так прекращение поддержки QTJambi не будет таким безболезненным, как представляли себе лоровцы в недавнем треде.

>Похоже не так прекращение поддержки QTJambi не будет таким безболезненным, как представляли себе лоровцы в недавнем треде.

Безболезненность зависит от надобности сего коммьюнити. Чем меньше народу оно нужно, тем больше он будет страдать.

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

> compose (*) (12.03.2009 10:09:15)

compose - новый авторитетный аналитик ЛОРа.

Не удержался и решил покормить трололо.

> Так уж получилось, что C++ умирает.

Он ещё на твоих похоронах станцует.

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

Никлоус Вирт и Джеймс Гослинг покусали тебя ночью в самых нескромных местах?

Вообще, очень толсто. Но для подъёма настроения годится.

> Пока она не сдохнет, не сдохнет и C++, ибо востребован.

Ну отчего же? Всегда есть небольшой шанс прорваться на рынок в этих областях у D и Objective-C

>Ну отчего же? Всегда есть небольшой шанс прорваться на рынок в этих областях у D и Objective-C

Ага, openmorrowind идет семимильными шагами :)

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=gpp&am...
А говорят ещё, что плюсы тормозные. Или это просто gcc тормозной? (:

>А говорят ещё, что плюсы тормозные.

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

В том треде где Торвальдс нелицеприятно высказался о С++ ниже по треду были обозначены конкретные проблемы: например как избавиться от неэффективной ООП - абстракции которая всеми соплями размазана по проекту. Вот это реальная задача а не перформансная писькомерка.

> все равно весь код у вменяемого программиста будет в .cpp файлах и заинлайнен соответственно не будет.

С этой точки зрения разработчики Qt вменяемые, у них в хедерах есть реализация только того, что действительно должно быть заинлайнено или параметризованно (вроде контейнеров). И обычно очень все через pimpl делается и сами хедеры довольно чистые получаются.

А вот что на счет разработчиков библиотек в boost, который header-only чуть менее чем полностью? Типа современный C++ такой, они там невменяемые что ли? :)

>Ой, да не смешите, игры большая ниша.

Ты видать совершено в мире не разбираешься.

>И сколько живут? Неделю? Месяц?

Я в фоллаут уже 10 лет играю.

> А вот что на счет разработчиков библиотек в boost, который header-only чуть менее чем полностью? Типа современный C++ такой, они там невменяемые что ли? :)

Boost разрабатывают с прицелом на максимальную универсальность и расширяемость, там что ни библиотека - чуть менее, чем полностью состоит из разного рода контейнеров. Сложно представить какой ужосЪ получится, если к примеру spirit переписать без использования шаблонов. В таких случаях - либо шаблоны в которых чёрт ногу сломит и распухание кода, либо ДИЧАЙШАЯ потеря производительности.

И вообще, всё это уже обсуждалось неоднократно. Последний раз - в новости про Qt 4.5. =)

Qt уже сдохло :) просто пока никто не заметил.

P.S.: То что C++ сдох, полностью согласен.

> В таких случаях - либо шаблоны в которых чёрт ногу сломит и распухание кода, либо ДИЧАЙШАЯ потеря производительности.

Чушь. Выбор другой - либо писАть на условно-понятном шаблонном извращении (Spirit), которое транслируется обычным компилятором и является частью обычной программы, либо писАть на настоящем DSL, для которого нужно написать специальный компилятор (от yacc до ANTLR). Никакой дикой потери скорости не будет.

>А вот что на счет разработчиков библиотек в boost, который header-only чуть менее чем полностью? Типа современный C++ такой, они там невменяемые что ли? :)

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