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

Пример ответа:

C#/Windows Forms — 100%
Java/SWT — 130%
Delphi/VCL — 90%
C++/Qt — 200%
C++/MFC — 900%

Или укажите трудоемкость изучения и использования отдельно.
Также интересны просто рассуждения на тему.

Здравствуйте, igna, Вы писали:

Поменял бы местами % первых двух пунктов. Причины две: менеджеры компоновки, а также б'ольшая популярность визуального программирования в .NET.

Здравствуйте, rsn81, Вы писали:

R>Поменял бы местами % первых двух пунктов. Причины две: менеджеры компоновки, а также б'ольшая популярность визуального программирования в .NET.

Там % с потолка, только для примера. И потом, мы правильно понимаем друг друга, если трудоемкость изучения и использования первого — 100%, а второго — 130%, то первое легче?

Здравствуйте, igna, Вы писали:

I>Там % с потолка, только для примера.
Данный вопрос слишком субъективен, потому цифры с потолка его уже не испортят.

I>И потом, мы правильно понимаем друг друга, если трудоемкость изучения и использования первого — 100%, а второго — 130%, то первое легче?
Ага, так у вас. Я же сказал, что считаю: все наоборот.

Здравствуйте, rsn81, Вы писали:

I>>И потом, мы правильно понимаем друг друга, если трудоемкость изучения и использования первого — 100%, а второго — 130%, то первое легче?
R>Ага, так у вас. Я же сказал, что считаю: все наоборот.

Не путай, если трудоемкость первого — 100 часов, а второго — 130, то первое безусловно легче.

Здравствуйте, igna, Вы писали:

I>Не путай, если трудоемкость первого — 100 часов, а второго — 130, то первое безусловно легче.
Вы сами с собой спорите?
Попробуйте читать повнимательнее.

Здравствуйте, igna, Вы писали:

Все ИМХО (по стобальной шкале, чем выше бал — тем сложнее) и со следующими предположениями:
1. Сравнение ведется с Win(16/32) API. Т.е. моя оценка была выставлена с одной стороны схожесть с Win32 API (общие подходы, сходные методы итд), а с другой — упрощение интерфейса по сравнению с WinAPI.
2. Все библиотеки идут в комплексе с RAD компонентами (указаны в колонке RAD). Т.к. я давно не писал без RAD
3. Все субъктивно

Название	RAD	Сложность (max=100)	Комментарии (все ИМХО)
C#/Windows Forms	Окно Form Visual Studio	50	Почти такая же как SWT. Но немного сложнее, и ИМХО некоторые вещи сделаны откровенно туповато. Хотя и на SWT и на Win Forms писал 3+ года, особых проблем, ради которых надо уходить от первой ко второй или на оборот я не выявил. Все примеры можно найти и на сайте MS, и на codeproject, и на GDN.
Java/SWT	SWT Designer	40	Самая простая из рассмотреных. В большенстве своем из-за того, что имеет множество примеров здесь + очень приличное средство RAD.
Delphi/VCL		не работал с этим
C++/Qt		не работал с этим
C++/MFC	Окно редактора диалога Visual C++	60	Большинство примеров/библиотек всегда бралось с двух ресурсов codeguru, а позже codeproject. ИМХО совсем не сложная, поэтому поставил 60, а не 70. Основной плюс, что после WIN API, почти ничего ненадо изучать. Основной минус — сейчас очень мало книг(раньше книг было на порядок больше) по этой библиотеке (поэтому поставил 60, а не 40), но это из-за того, что многие считают эту библиотеку устаревшей.

Только попробуйте поставить минус, я четыре раза написал ИМХО

Здравствуйте, rsn81, Вы писали:

R>Попробуйте читать повнимательнее.

Читаю:

I>>И потом, мы правильно понимаем друг друга, если трудоемкость изучения и использования первого — 100%, а второго — 130%, то первое легче?
R>Ага, так у вас. Я же сказал, что считаю: все наоборот.

Как именно наоборот, если трудоемкость изучения и использования первого — 100%, а второго — 130%, то второе легче?

Давай разберемся с этим недоразумением.

Здравствуйте, igna, Вы писали:

I>Как именно наоборот, если трудоемкость изучения и использования первого — 100%, а второго — 130%, то второе легче?
Нет, конечно — первое, ну боже ж ты мой...

I>Давай разберемся с этим недоразумением.
Ага, или не будем их себе придумывать.

Добавлю от себя имха:

Название : HTA (HTML Application).
RAD : ЛЮБОЙ HTML-редактор. (Visual Studio имеет очень неплохой встроенный)
Сложность (max=100) : 60 — на глаз (реально оценить трудно. С одной стороны — есть несколько подводных камней при хостинге MSHTML. С другой — создание интерфейса сильно упрощается поскольку книг по HTML-завались).
Комментарии (все ИМХО) : Для формошлёпок или программ где интерфейс должен быть красивым — очень даже неплохой вариант. Изначально дорог из-за вышеупомянутых подводных камней, но если проект большой и интерфейс в нём занимает большУю часть времени — окупает себе с лихвой. Дополнительный плюс — все интерфейсные задачи можно писАть на JavaScript (для любителей тонких извращений — на VBScript), что очень здОрово дополнительно ускоряет разработку. Из недостатков — принципиальная некросплатформенность, необходимость поддержки нескольких браузеров (обычно в требования ставят как минимум IE 5.01, с более предыдущими стараются не связываться).

PS. Это как бы не совсем библиотека, просто один из вариантов создания GUI.

Здравствуйте, rsn81, Вы писали:

R>Поменял бы местами % первых двух пунктов. Причины две: менеджеры компоновки, а также б'ольшая популярность визуального программирования в .NET.

"Большая популярность визуального программирования в .NET" является одной из причин того, что изучение и использование C#/Windows Forms более трудоемко по сравнению с изучением и использованием Java/SWT?

Здравствуйте, igna, Вы писали:

I>Какова сравнительная трудоемкость изучения и использования комбинаций языка программирования и GUI-библиотеки?

I>Пример ответа:

I>C#/Windows Forms — 100%
I>Java/SWT — 130%
I>Delphi/VCL — 90%
I>C++/Qt — 200%
I>C++/MFC — 900%

I>Или укажите трудоемкость изучения и использования отдельно.

ИМХО!!!

Library	Изучение	Использование
MFC	100%	100%
VCL	110%	70%
Swing	160%	50%
WinForms	120%	60%
WPF	200%	40%

Здравствуйте, igna, Вы писали:

I>"Большая популярность визуального программирования в .NET" является одной из причин того, что изучение и использование C#/Windows Forms более трудоемко по сравнению с изучением и использованием Java/SWT?
Да. А что, нашли противоречие?

1. Визуальное программирование — это зло, порождающее одноразовый ГИП, который очень неуклюж при условии относительно непростого ГИПа и частого изменения требований к нему. Нет, ну если речь про 2-3 формы, то конечно...
   
2. Под трудоемкостью стоит понимать трудозатраты на реализацию эквивалентного по сложности ГИПа, а не сравнение скорости и удобства накидывания 2-3 формочек в визуальном построителе.

Кстати, SWT напрямую используется редко, в основном популярны классы надстройки над SWT — JFace.

Здравствуйте, 0rc, Вы писали:

[]

изучение — 60
использование — очень легко

Предположу, что Qt — изучение 60, а использование порядка 20

Основная проблема в Qt — то, что его много, это может быть overwhelming

Спасибо. Кто-нибудь может добавить информацию про JFace?

Здравствуйте, igna, Вы писали:

I>Спасибо. Кто-нибудь может добавить информацию про JFace?
А что конкретно интересует?

Здравствуйте, igna, Вы писали:

I>Какова сравнительная трудоемкость изучения и использования комбинаций языка программирования и GUI-библиотеки?

I>Пример ответа:

I>C#/Windows Forms — 100%
I>Java/SWT — 130%
I>Delphi/VCL — 90%
I>C++/Qt — 200%
I>C++/MFC — 900%

I>Или укажите трудоемкость изучения и использования отдельно.
I>Также интересны просто рассуждения на тему.
wxWidgets — 40% от MFC (100%)
вообще, после MFC, все остальное изучается влет, или сразу становится понятным, т.е. можно сразу работать и по ходу дела вникать глубже

Здравствуйте, sc, Вы писали:

sc>вообще, после MFC, все остальное изучается влет

Это вряд ли. Нет, всякие VCL и WinForms конечно действительно затруднений не вызовут, а вот насчет Swing или WPF я бы не был так уверен.

Здравствуйте, igna, Вы писали:

I>Спасибо. Кто-нибудь может добавить информацию про JFace?

Снова ИМХО:

Название	RAD	Сложность (max=100)	Комментарии (все ИМХО)
JFace	SWT Designer/VE	55	JFace однозначно сложнее SWT, приблизительно как Windows Forms поэтому поставил выше 50. Из проблем: слишком абстрагированы компоненты для ежедневных практических задач, малое количество литературы (только на eclipse.org), обусловлено тем, что интерфейс JFace частенько меняется или значительно дополняется. Тем не менее использование JFace в крупных проектах считаю оправданым и выгодным.