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

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

ttnl
2007-11-29 17:43 (ссылка)

Он написан на чистом C. Проекты такого размера и назначения просто нельзя писать на этом языке, C для этого предназначен. Собственно, именно авторы GIMP ответственны за появление двух самых чудовищных библиотек в истории свободного софта — Gtk и GLib. В оправдание гимпописателей можно сказать только то, что они вряд ли предполагали, насколько вырастет их дипломный проект.

К GTK+ существуют множество bindings, разработку можно вести на разных языках от java до питона.
На каком языке вы предлагаете писать графические библиотеки, если не на c? Можно представить SDL, переписанную на питоне. Скорость работы будет потрясающей.

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

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

SDL не является библиотекой для создания GUI, вообще-то. Это как раз способ "быстро и грязно" вывести графику на экран в ситуации, когда дорог каждый такт процессора — в играх, эмуляторах и т.д. Там и используется. За применение SDL для написания, скажем, морды к БД надо лишать доступа к компьютеру в судебном порядке.

Человеческое решение проблемы, которую решали авторы Gtk и GLib, называется Objective C. Чуть менее человеческое решение той же проблемы называется C++. И даже они применимы только там, где уже нужен очень сложный код, а нормальные языки, с автоматической сборкой мусора, интроспекцией и прочими минимально необходимыми для разработки программ с правильной архитектурой свойствами по соображениям эффективности использовать ещё нельзя. Позиционирование же Gtk и GLib как средства для создания приложений общего назначения, типа "альтернативы Qt" это вообще преступление.

Мы, собственно, можем наблюдать "злонравия достойные плоды". Код GIMP занимает больше ста мегабайт; контроль над ним безвозвратно потерян, на feature request'ы команда не реагирует (потому что не может), при каждой попытке исправить баг добавляется четыре новых.

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

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

	tiphareth 2007-11-29 18:38 (ссылка)
	На вкус и цвет товарищей нет. Со своей стороны, хочу посоветовать INTERCAL (Ответить) (Уровень выше) (Ветвь дискуссии)

	yushi 2007-11-29 21:24 (ссылка)
	Прикольно, действительно. На Brainfuck местами похоже (не сочти за наезд, язык действительно интересный). (Ответить) (Уровень выше) (Ветвь дискуссии)

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

Язык баснословный, в принципе.
Особенно 4 арифметические операции, Брайнфак это уже
эпигонство практически.

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

То есть для реализации практических задач (как минимум,
совместимости между дистрибутивами и беспроблемной
компилируемости из сорса) - годится только перл,
питон и си. Ну там, флекс, тк/тцл, руби, паскаль,
если нужно экзотичного. А окамлы строятся в колонну
и идут нахуй вместе с ос/2, би-осом и планом-найн.
Ибо экзотика, применимая только для хобби-проектов.

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

Такие дела
Миша

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

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

Вот, и опять нельзя не вспомнить Эрланг. К моему удивлению (я с детства интересуюсь экзотическими ЯП, и думал, что более или менее в них ориентируюсь), оказалось, что это практически мейнстрим (просто в далёкой от десктопов области — роботы, телеком; кстати, по той же причине — бешеная популярность вдали от десктопов — к списку беспроблемных языков стоило бы-таки добавить Аду), и всё, что нужно допиливать напильником, было допилено где-то к началу двухтысячных. На Эрланге написан ejabberd, который без звука ставится в любом популярном Linux-дистрибутиве, много всякой забавной мелочи, и такое ощущение, что "провинциальности" Схемы или Оберона он начисто лишён.

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

	tiphareth 2007-11-29 22:22 (ссылка)
	Ага. Я никогда с ним не работал, но допускаю вполне (Ответить) (Уровень выше)

	joppux 2007-11-30 02:13 (ссылка)
	> годится только перл, питон и си Фи, какой узколобый прагматизм! (Ответить) (Уровень выше)

ttnl
2007-11-29 19:34 (ссылка)

Человеческое решение проблемы, которую решали авторы Gtk и GLib, называется Objective C.

GLib-то тут при чем?

Человеческое решение проблемы, которую решали авторы Gtk и GLib, называется Objective C. Чуть менее человеческое решение той же проблемы называется C++. И даже они применимы только там, где уже нужен очень сложный код, а нормальные языки, с автоматической сборкой мусора, интроспекцией и прочими минимально необходимыми для разработки программ с правильной архитектурой свойствами по соображениям эффективности использовать ещё нельзя. Позиционирование же Gtk и GLib как средства для создания приложений общего назначения, типа "альтернативы Qt" это вообще преступление.

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

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

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

Что имеется ввиду?

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

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, напомню, практически прекратил развиваться именно из-за того, что в коде такого объёма, написанном на языке, по убожеству сопоставимом с ассемблером, никто не способен разобраться, просто физически (человек не может удержать в голове столько разноранговых сущностей). Никто, собственно, и не разбирается.

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

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