tiphareth: лицензионное программное обеспечение для российских школ

(Читать комментарии) - (Добавить комментарий)

yushi
2007-11-29 21:21 (ссылка)

Имеется в виду, что работать со столь сложными структурами данных и столь высокоуровневыми абстракциями, как в GLib, с помощью настолько низкоуровневого языка, как plain С, мягко выражаясь, непродуктивно. На программиста ложится тупая и неблагодарная работа по ручному освобождению памяти, явному вызову sizeof(), бесконечным приведениям типов и т.д. При написании пользовательских приложений надо думать не об этом! Так можно писать ядра операционных систем и реализации языков. А при написании пользовательского приложения об всей этой байде должен заботиться интерпретатор/компилятор.

Есть такая штука, как gtkmm

Она накрылась. К тому же — см. ниже.

Используйте любой язык, поддерживаемый GTK+.

Я пробовал, вместе со Scheme и Python. Спасибо, больше не хочу. Врождённые уродства Gtk пролезают даже в Схему, противоестественное устройство самой библиотеки не лечится выбором языка.

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

Это распространённое заблуждение. Напомню, исследования показывают, что количество операторов, которое программист создаёт в единицу времени, постоянно и не зависит от языка программирования. Вот только в двести операторов на Лиспе влезает неслабая библиотека для работы с русской морфологией, а в двести операторов на plain C или ассемблере мало что сложнее "Hello, world!".

Язык определяет мышление. Разные языки обеспечивают разные уровни абстракции. Есть задачи, в рамках которых полезно думать о регистрах процессора и размере выделяемой памяти в байтах. Есть задачи, в рамках которых об этом думать вредно. Gtk и Glib предлагают средства для решения вторых в рамках языка, предназначенного исключительно для первых; поэтому Gtk и Glib следует отправить в топку.

(Ответить) (Уровень выше) (Ветвь дискуссии)

ttnl
2007-11-30 14:31 (ссылка)

Использование ООП языков для написания библиотек ещё отвратительней.
Любая C++ библиотека тянет за собой кучу ненужного мусора,
который тормозит приложение и ухудшает восприятие кода.
Невозможно разобраться, откуда происходит наследование, все эти виртуальные
функции, перегрузки, нагромождение шаблонов и прочих конструкций превращает программу в ребус, и большая часть разработки превращается в его разгадывание.
Ещё больший дебилизм разносить заголовочные и СPP-файлы в разные директории, и следующий из этого мартышкин труд по поиску выполняющейся функции среди прочих перегруженных: она описана в заголовочном файле или нет? Аргумент типа char * или он приводится к const char *?
А про наследующиеся конструкторы и говорить не хочется.
Даже сам дедушка Страусруп смеётся над ООП программистами.

Наглядный пример - kdelibs и qt. В ближайшее время выйдет новая версия KDE4. Все KDE программы к этому выпуску должны быть переписаны(!), потому что у библиотеки отсутствует обратная совместимость. А всё потому что наследуемость и прочие инкапсуляции.

Нынешних возможностей Gimp'а хватит ещё лет на 20, Gimp или фотошоп, на бумаге это будет выглядеть примерно одинаково. От графического интерфейса многого не надо, не нужны эти перделки и свистелки, избыток красочности. А нужна простота, удобство, функциональность и производительность. Для нормальных вещей, которые пишутся для простоты, удобства, функциональности и производительности (для людей, а не блондинков) используется язык C и библиотека GTK+.
А все остальные перделки идут в топку.

(Ответить) (Уровень выше) (Ветвь дискуссии)

yushi
2007-12-02 22:17 (ссылка)

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

То, что вы не видели хорошего кода на C++ — это повод вам посочувствовать, но не повод считать, что его не бывает.

Аргумент типа char * или он приводится к const char *?

Мелочь, но характерная, да. Ни один человек в здравом уме не будет использовать char* внутри кода на C++ иначе как для общения с операционной системой (разбор команднострочных аргументов и пр.). Функция на C++, принимающая аргумент типа char* (если это не функция конвертации null-terminated "строки" в какую-нибудь человеческую) по определению написана криворуким пионером.

Все KDE программы к этому выпуску должны быть переписаны(!), потому что у библиотеки отсутствует обратная совместимость.

Не вижу в этом ничего ужасного. В жизненном цикле программы (если это не студенческая поделка, забытая всеми, включая автора, сразу после создания) собственно "написание" требует ничтожной доли суммарных усилий программиста. После бурного и романтического, но короткого этапа создания кода начинается сопровождение программы — ликвидация багов, реализация feature request'ов, правка документации и т.д. Если переписывание с нуля (которое по готовой иерархии классов — мы ведь договорились, что речь не о пионерах, не способных, скажем, нарисовать UML-диаграмму, да? — занимает считанные недели, если не дни) способно резко упростить сопровождение (а при переходе с Qt3 на Qt4 это так — чего стоит один фреймворк Interview; в потроха KDE не залезал, но подозреваю, что там благотворных изменений не меньше), любой разумный разработчик перепишет код, не делая из этого трагедии. "Планируйте выбросить первую версию - вам все равно придется это сделать"©Брукс.

Нынешних возможностей Gimp'а хватит ещё
лет на 20, Gimp или фотошоп, на бумаге это
будет выглядеть примерно одинаково.

"Рыдалъ"©. Слова, скажем, "CMYK", "L*a*b", или (для разнообразия) "HDR", или "слои эффектов" вам о чём-нибудь говорят?

Для нормальных вещей… используется язык C и библиотека GTK+.

Забавно видеть это утверждение в треде, начавшимся с обсуждения GIMP'а. Оный GIMP, напомню, практически прекратил развиваться именно из-за того, что в коде такого объёма, написанном на языке, по убожеству сопоставимом с ассемблером, никто не способен разобраться, просто физически (человек не может удержать в голове столько разноранговых сущностей). Никто, собственно, и не разбирается.

(Ответить) (Уровень выше)

(Читать комментарии) -