Qt - рыба или удочка?

[Igors]

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

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

файломанагера сталкиваешься с тем, что в Qt просто нет - виртуальная ФС, драйвы, миметипы, асинхронные файловые операции.

Даже стандартные классы itemview фреймворка оставляют желать лучшего - QTreeView умирает на 10000 строк (что фиксится парой строк в сорцах Qt), тейбл вью умирает чуть позже, но зато умирает насовсем. Приходится переписывать вьюхи. Делегаты тоже можно сильно оптимизировать (а тк сорцы поправить нельзя, приходится писать свои). Где тут рыба, если на каждом шагу грабли?

Не думаю что это встретит на форуме большее понимание/интерес чем мои "сложные" задачи 

[andrew.k]

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

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

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

[ufna]

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

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

То, что в Qt - хорошая документация - это нормально. Не нормально, когда ее нет в публичном продукте и приходится копаться по чужому коду чтобы понять как и что работает - это просто неуважение к остальным. Причем здесь это? Умение разбираться в чужом коде ровным счетом ничего не говорит о том, что из себя представляете вы. Скажем так, это значит что вы просто знаете как удалять зуб через задницу.

[Igors]

ufna, почему так сложно сказать напр "да, я этим просто пользуюсь, и мне по большому счету все равно как оно устроено - делало бы что от него требуется. Да, здесь я просто типа юзер, ну мне хватает др забот". Что в этом стыдного? Так делают все (и я тоже) c'est la vie

Почему надо извиваться, рассказывать о глобальном прогрессе и политической обстановке, подчеркивать исключительную значимость повара и в конце-концов свалиться в аргументы типа "а ты че, такой умный?" 

[asvil]

Qt годится только для написания _простейшей_ графической оболочки, которые использовались сто лет назад. Одна из первых причин это конечно же с++, private методы и т.д.
Qt не займет нишу явы и не имеет возможностей тесной интеграции с другими тулкитами, соответственно весь интерпрайз с сотнями нефти для нее закрыт.
Qt тяжеловесна относительно efl, поэтому на embedded системах предпочитают efl, android. Последний тоже конечно тяжеловесен, но и пиар у него лучше.
Qt нет смысла использовать в больших проектах, потому что, есть microsoft, которая предоставляет наиболее _мощный_ фундамент по сравнимым ценам, да и людей в поддержке, там тупо больше.
Qt нет смысла использовать в каких то экспериментальных программах (ну там например расчет координат небесных тел, или анализатор-преобразователь кобольных программ), так как эти программы опять таки делаются в пять раз быстрее в windows.
И да, в целом, кроссплатформенность это миф. Почему все в него верят? Потому что не считают деньги. Вот, например, кроссплатформенность при развитии программы - это диверсификация. Типа если микрософт обанкротиться, то у нас есть линукс и мы на него соскочим и деньги у нас останутся. Но все же знают, что вероятность такого ничтожно мала. Значит диверсификация неоправдана, и линукс не является конкурентом виндовс на десктопе.

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

В целом, Qt можно закапывать. Ну или учавствовать в агонии.

[asvil]

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

Не не пользуюсь, не удовлетворяет потребностям.

[_OLEGator_]

to Филоненко Михаил
Если вам не понятно, как можно использовать возможности Qt - не надо троллить, что за неуважение к чужой работе.

[Bepec]

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

И в конечном счёте - закапывать можно всё, включая и вас. И крышечкой сверху тук тук тук

[ufna]

ufna, почему так сложно сказать напр "да, я этим просто пользуюсь, и мне по большому счету все равно как оно устроено - делало бы что от него требуется. Да, здесь я просто типа юзер, ну мне хватает др забот". Что в этом стыдного? Так делают все (и я тоже) c'est la vie

Почему надо извиваться, рассказывать о глобальном прогрессе и политической обстановке, подчеркивать исключительную значимость повара и в конце-концов свалиться в аргументы типа "а ты че, такой умный?" 

Igors, есть два момента.
1. мне не все равно как оно устроено. было бы все равно, юзал бы я Qt? Есть другие языки и другие замечательные библиотеки для разных систем, задач и т.п.
2. "просто типа юзер" очень размывчато в данном плане. Если брать "типа юзер" - то все мы в любом случае на любом уровне "типа юзеры", потому это как бы очевидно и из разряда "мы дышим воздухом". Кому-то стыдно признаться что он дышит воздухом? Не думаю. Так и здесь. "типа юзер" - никто и не опровергал. Те, кто делают Qt, тоже "типа юзеры". В первую очередь юзеры PС или Mac.

Тема изначально болтология, ибо не содержит четких якорей. Здесь нечего измерять и нечего сравнивать. Нет системы, в первую очередь - логической. Поэтому о чем тут говорить то? Децл поиздеваться над топик-стартером из-за его наивного заброса с подменой понятий?

[Bepec]

Постебаться

[Alex Custov]

Qt годится только для написания _простейшей_ графической оболочки, которые использовались сто лет назад.

Я пытался понять что это значит, но так и не понял.   KDE со всем его функционалом подходит под понятие "_простейшей_ графической оболочки"? Если нет, то что подходит?

[Bepec]

Любая функционирующая сейчас программа

[Igors]

Qt годится только для написания ..

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

Спасибо

[asvil]

Простые решения это текстовый редактор (но не такой как емакс), гуя для настройки конфигов, рендеринг картинок.

Про кутю:
При работе с графической частью библиотеки, мне были необходимы не совсем тривиальные возможности (ну т.е. переопределить стандартное поведение виждета, нарисовать галочку в неожиданном месте и т.д.), на это уходило неоправданно много времени. Сравнению с dom/jquery в этом плане прошло не в пользу кути.

Про с++ и си:
ну я думаю для всех не секрет, что интеграция сишных библиотек лучше проходит с другим языками, платформами, чем у ++. Это дает существенную фору, когда например, индустрия почему-то поперлась использовать ruby, и разработчики всяких быстрых полезных сишных библиотек оказываются нужными и в этих скриптовых средах.
Одной из причин этому является то, что в сишечке простой процедурный подход, а в с++ жестко прибитый ООП. Ну да еще ABI.
Наиболее выигрышным в плане интеграции везде и всюду оказывается objectve-c (+cocoa), который реализует ООП смолтолка (а он там динамический: всякие определения методов на лету, обработки сообщения несуществующему методу и т.п.), но интеграция с данным ООП проходит через простые сишные функции.

Вобщем для c/objective-c проще пишуться обертки для других языков.

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

А ну и программисты на с++ дешевые.

Что изучить:

Изучать с++ или кути не совсем корректное слово. Это всего лишь инструменты, надо просто запомнить циклы, ветвления, ООП и API от кути. Даже стандарты хаскелей и лиспов это всего лишь базы данных. Изучать можно новые принципы построения программ, или неизученные ранее физические явления (но это уже не о компьютерах).

Для определения глобальной перспективы изучайте экономику, маркетинг. Это необязательно делать в ВУЗе, необязательно 5 лет. Например, смотрите, есть проблема старения населения

http://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BC%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D1%81%D1%82%D0%B0%D1%80%D0%B5%D0%BD%D0%B8%D0%B5

У стариков есть себережения, капиталы, они в результате инстинкта самосохранения будут тратить эти деньги на здоровье: спорт, лекарства (витамины и т.д.). Значит будет расти спрос на химиобиологические исследования для создания лекарств. Значит лабораториям нужны будут программы моделирования химиобиологических процессов.

Какой язык для моделирования таких процессов удобен? На мой взгляд common lisp.

garbage collector, функции высших порядков, CLOS (хитрое ООП), repl, интеграция с си (cffi), лексические и специальные переменные, связывания (позволяют любую функцию (кромезамыкания) сделать потокобезопасной), система исключений (с возможностью перезапуска кода), макросы (не путать с сишными).

[Alex Custov]

Филоненко Михаил, вы что курите, мне интересно? Хотя в конце всплыл common lisp, чему тут удивляться. Взять те же проекты распределённых вычислений, типа Protein Folding из Стэнфорда, пишут его совсем не на lispe. Почему? Представьте себе, даже без использования GC, функций высшего порядка, и, о ужас, без лямбд!

При работе с графической частью библиотеки, мне были необходимы не совсем тривиальные возможности (ну т.е. переопределить стандартное поведение виждета, нарисовать галочку в неожиданном месте и т.д.), на это уходило неоправданно много времени.

Например, поточнее?