Журнал Витуса

Как ни странно, нет. И там, и там желателен низкий порог вхождения.

From:

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

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

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

From:

Для инструмента - порог вхождения заканчивается, когда им можно пользоваться (пусть неэффективно). Для vim, помнится, он для меня по ощущениям кончился, когда я научился редактировать и сохранять файл. Остальное уже за порогом.

Для игры порог вхождения - понять задачи и освоить интерфейс.

По последнему абзацу: когда я пишу скрипты для vim - я работаю или играю? :-)

From:

Вынес бы ты это отдельным постом. В текущем дискуссию никто не отловит.

From:

Для инструмента - порог вхождения заканчивается, когда им можно пользоваться (пусть неэффективно). Для vim, помнится, он для меня по ощущениям кончился, когда я научился редактировать и сохранять файл. Остальное уже за порогом.
Вот это по-моему неправильный подход. Идеологически. На практике, конечно, без него не обойтись, всегда бывает что задачу решать надо срочно, и лучше решить её неэффективно используя приспособленный для неё инструмент, чем решать совсем неподходящим, но знакомым инструментом. Но стремиться надо к тому, что если уж перед тобой стоят задачи, которые решаются данным инструментом, то инструмент надо освоить так, чтобы пользоваться им эффективно.
По последнему абзацу: когда я пишу скрипты для vim - я работаю или играю? :-)
Зависит от того, что это за скрипты, и зачем они тебе.

Если я пишу себе в .vimrc автокоманду, которая при создании нового HTML-файла автоматически врисовывает туда некий темплейт, то я работаю.
Я решаю (в общем виде, на метауровне) внешнюю по отношению к vim-у задачу "создание html-файлов". Дотачиваю инструмент, чтобы в дальнейшем при решении этой задачи использовать его более эффективно.

Если

slobin пишет себе скрипт, который в status line фазу Луны показывает, то он играет. Потому что на самом деле непрерывное знание фазы Луны ему нафиг не нужно.

Игра с инструментом на самом деле - не совсем бесполезное дело. Это достаточно эффективный способ этот инструмент освоить. Но из этого ни разу не следует, что инструмент надо затачивать в первую очередь под это.

From:

>Но вот GUI этой нишей не является.

Витус, покажы всё-таки хоть один не-ООП GUI тулкит. Если найдёшь — объясни, почему им никто не пользуется.

From:

ramendik

Мегакорпорация, в которой я работаю, уже несколько лет не продаёт ни компьютеры, используемые дома, ни, насколько я знаю, детали к ним. В пользовательской области, если судить по тому что она производит, ей скорее выгодно развитие масштабных онлайновых сервисов - вот для них она как раз продаёт и аппаратуру, и ПО. (Дисклеймер: это мой личный вывод). Кстати, с Линуксом у оной корпорации отличные отношения, не только на уровне пиара, но и на уровне внедрения внутри (и вроде бы и contributions, но я не в курсе, это совсем другой отдел).

Правда, "гигабайты и гигагерцы" были действительно выгодны компании, на которую я работал ранее, с 2003 по 2008. Вот только с тобой мы на эту же тему спорили явственно до 2003 :)

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

Заметим, что реально Gnome и KDE, как среды, я ни для себя, ни для семьи не использую. Зато многие программы, разработанные на их библиотеках - ещё как.

From:

Кстати, с Линуксом у оной корпорации отличные отношения, не только на уровне пиара, но и на уровне внедрения внутри (и вроде бы и contributions, но я не в курсе, это совсем другой отдел).
Угу, все мы знаем, сколько эта корпорация вкладывалась в проект GNOME.
И я не вижу у себя морального права требовать от них учиться программировать, посколько в их профессиональной области я сам понимаю не лучше.
А я вижу. И академик Ершов - видел, когда выдвигал лозунг "программирование - вторая грамотность".

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

Где-то до начала 80-х IT развивалась именно в сторону упрощения этого подхода. Потом пошло развитие в противоположную сторону. Собственно об этом - противостоянии подхода "программа = высказывание того, чего ты хочешь добиться" vs "программа это изделие, сделанное профессионалом" я писал в статье о вреде дружественных интерфейсов.

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

Оптимальность для пользователя достигается только тогда, когда пользователь может сам решать, что он делает сам, а что - делает за него компьютер.

Заметим, что реально Gnome и KDE, как среды, я ни для себя, ни для семьи не использую. Зато многие программы, разработанные на их библиотеках - ещё как.
Ну так других-то нет. Я тоже вынужден использовать всякие evince.

From:

Витус, ИМХО, подход, без которого нельзя обойтись на практике, не может быть неправильным. На самом деле, конечно, порог вхождения и кривая обучения вещи разные.

From:

ramendik

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

А большинство - интерактивные. "Пообщаться с таким-то". "Написать и оформить текст".

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

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

From:

Кстати, это тожэ свойство ООП в применении GUI: разработчики библиотек практически всегда используют ООД на полную катушку, в то жэ время как пользователи чаще всего — нет
Это свойство не только GUI. Посмотри, к примеру на перловый модуль DBI - то же самое.

Беда в том, что разработчики библиотек далеко не всегда заботятся о том, чтобы пользователь мого не связываться с ООП.

From:

В принципе - можно. Технология распознавания образов достаточно развита, чтобы можно было попытаться. Беда в том, что при текущем положении дел силы программистов уходят не на решение вот таких вот, практически интересных задачек, а на то, чтобы бороться с GUI.

From:

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

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

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

From:

strannick.blogspot.com (from livejournal.com)

Ммм... Я бы не сказал. Насколько я знаю и в фотошопе, и в гимпе инструментом "выделение переднего плана" занимаются не те люди, которые пишут сам редактор. А из GUI там только диалоговое окно.

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

Это я к тому, что быстрее обвести руками, чем пытаться "сказать ему, что надо, чтобы сам обвёл". Более того, это зачастую относится не только к компьютерам. :)

Т.е. есть область задач, где использование скриптов нецелесообразно.

From:

strannick.blogspot.com (from livejournal.com)

Либо просто выбранный пример не совсем удачен.

From:

>Как вывести в окошко текст, подвергнутый
>какому-нибудь аффинному преобразованию. Пользуясь
>базовым иксовым API.

Есть два варианта. Первый: Получить соответствующим образом отмасштабированный шрифт. Матрица преобразования (точнее, левый верхний квадрант этой матрицы, без третьей строки и третьего столбца. Они считаются равными 0/0/1 и 0/0/1) задаётся вместо параметра POINTSIZE в имени шрифта, в квадратных скобках, перечислением значений через пробел.

Т.е. что-то вроде '-microsoft-verdana-medium-r-*-*-*-[12 4 4 12]-*-*-*-*-koi8-r'. Затем следует открыть оригинальный шрифт через XLoadQueryFont ('-microsoft-verdana-medium-r-*-*-*-120-*-*-*-*-koi8-r'), получить его размеры из CharInfo, и выводить по сиволу, пропуская его оригинальный размер через это жэ афинное преобразование.

Другой вариант — сначала вывести строку в Pixmap как обычно, затем через XIE создать PhotoFlo (xieCreatePhotoflo), добавить в него через xieFloImportDrawable этот pixmap, поворот через xieFloGeometry (не забыв в sample_tech поставить xieValGeomAntialias), вывод в окно через xieFloExportDrawable, затем запустить это на выполнение через XieExecutePhotoflo. Кстати, практически вся мутота выполняется один раз, в последёющие — только выводишь строку в Pixmap и поворачиваешь его через XieExecutePhotoflo.

From:

duke-igthorn.livejournal.com

> задаётся вместо параметра POINTSIZE в имени шрифта, в квадратных скобках, перечислением значений через пробел.
О как. И что - это реально поддерживается хоргом?

Спасибо за объяснение, узнал что-то новое... Но проблема визивига от этого, конечно, никуда не девается...

From:

Ну да, визифиг трудно заставить использовать системные шрифты. Офигенное открытие, блин. Только вообще не ясно, при чём тут оно.

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

From:

>О как. И что - это реально поддерживается хоргом?

Ну да, это ещё не отломали. Как ни странно. xfontsel -pattern вполне покажэт.

From:

duke-igthorn.livejournal.com

> Только вообще не ясно, при чём тут оно.
Насколько я понимаю, при том что авторы библиотек рендеринга хотят независимости от того, куда рендерить.

> тащить потребный ему X-сервер с собой
А еще можно было DPS развивать. Но не прижилось..

Но Вы все-таки ответьте - почему хорговская команда всяко продвигает клиентский рендеринг? Они тоже спеков не читали?

From:

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

А такжэ что рендэрить и для чего рендэрить. В общем, они бы хотели написать такую сферическую библиотеку рендэринга в воздухе, типа HAL — чтобы она что-то делалала, но при этом ничего полезного. Верю.

>Но Вы все-таки ответьте - почему хорговская команда
>всяко продвигает клиентский рендеринг? Они тоже спеков не читали?

Ну, во-первых, хорговской команде в цэлом по-моему пофиг. Во-вторых, продвигает скорее не хорговская команда, а гткшная/гномовская. Собственно, для этого грёбанного антиальясинга(анафема!) в gtk(анафема!) в своё время сделали libXft, а к нему потом под него написали Xrender(анафема!).

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

From:

Кстати, иксы ужэ очень давно GL. Более давно, чем всякие Xrenderы.

From:

DPS он, во-первых, всё-таки крив как биндинг, а во-второых, PostScript тяжэловат как система отображэния. В том числе, боюсь, и по современным временам тяжэловат. Хотя кто знает, возможно, заняться стоит именно этим.

From: