Category: компьютеры

Category was added automatically. Read all entries about "компьютеры".

flow

Основания

Несколько лет назад я пробовал найти ответ на вопрос: какие абстракции наиболее удобны для представления компьютерных программ?

Есть различные парадигмы: функциональное программирование, объектно-ориентированное программирование, логическое программирование, etc - совершенно разные взгляды на мир. Вроде как в чём-то они взаимозаменимы, и описания в терминах одного подхода можно перевести на другой, но выглядит это обычно настолько многословно и отвратительно, что того не стоит. А унылые попытки обосновать полезность любой парадигмы обычно сводятся к "писать можно только на глиняных табличках, потому что сушёное говно мамонта рассыпается, а других вариантов мы не знаем", даже если это высказывается такими крутыми людьми как Эдсгер Дийкстра.

А ведь бывает и такой код, где нет ни функций, ни объектов, ни других стандартных компоновочных блоков - фрагменты на ассемблере, файлы конфигурации, различные DSL. Что остаётся, что делает программу программой? Эффекты.

Они всегда есть. Даже для pure functional вычислений необходим эффект вывода результата. Через эффекты можно описать любой существующий примитив: функции, замыкания, акторы, ... А затем свободно использовать, без необходимости "перевода на другую парадигму". В том числе, в сочетании с новыми, специально создаваемыми для задач предметной области, примитивами.

Таким образом, эффекты являются удобным основанием для построения программ и кирпичиков-для-программ (включая давно привычные).

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

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

Вики как антидокументация

Документация продукта, как правило, создаётся с двумя целями:
1. Поддержание образа продукта, способствующего продажам.
2. Создание у пользователя желаемого навыка работы с продуктом.

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

В свою очередь, системы вики (и википедия, как популярный пример) это наборы наблюдений, "лесом еду, лес пою".

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

Поэтому, замена документации на вики эквивалентна ситуации "ничего не документировано, но много гуглится". Что многое говорит о процессе разработки и специфическом качестве поддержки продукта.
flow

Клавиатурное

Помимо глаз (http://justy-tylor.livejournal.com/215618.html), у меня ещё один период адаптации моторики - к новой клавиатуре.

Три года провёл на Microsoft Natural Ergonomic 4000, сейчас сменил на Microsoft Sculpt Ergonomic Desktop.

Так получилось, что MS сейчас единственные производители эргономичных клавиатур для быдла массового рынка. Есть продукты у Maltron и Kinesis, но там застряли на самокопировании старых экзотических идей, практически не развиваясь.

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

В Natural Ergonomic большой проблемой была тяжёлая и неудобная кнопка пробела. В Sculpt Ergonomic вместо этого две лёгкие половинки, а все клавиши ноутбучные, островного типа, что здорово сокращает нагрузку на руки. Качество подставки для запястий чуть выше. Единственное ухудшение - верхний ряд (Esc, F1...) сделан мини-клавишами, из-за чего нажимать их менее удобно. Сочетая все плюсы и минусы - пока лучшая клавиатура на моей памяти.

Ложка дёгтя - мышь, которая поставляется в комплекте. Её форму придумал какой-то совсем ушибленный промдизайнер, в перерывах между созерцаниями лика Джонни Айва. Использовать нельзя. Если клавиатура из Sculpt Ergonomic это спасение от RSI, то мышка из того же комплекта будет калечить ваши руки в разы быстрее, чем любая обычная мышь. Можно оставить на столе в качестве высокотехнологичного груза на стопке мелких бумаг.
flow

Метафоры на продажу

Когда-то меня очень удивляло, что каждая среда с графическим интерфейсом пользователя непременно имеет в составе приложение Calculator.

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

Почему же пользовательские операционные системы и оболочки десятилетиями поставлялись с таким дурным и неудобным инструментом как настольный калькулятор? Потому что их создатели продавали вовсе не удобство и комфорт. Они продавали метафору рабочего стола на экране вашего компьютера. Метафору, которую исследователи Xerox PARC не смогли продать своему начальству, но продали Джобсу, а Джобс и Гейтс стали продавать широким массам. Да, некоторые компоненты в этой метафоре получались криво и неудобно, зато картинка "всего этого вау на одном виртуальном столе" очень способствовала продажам.

Кстати, схожее ощущение у меня от видео Брета Виктора. Многие визуализации из его выступлений можно получить более удобными и простыми методами. Но он продаёт ручную инфографику, что требует следования выбранной метафоре.
flow

Антинаучность в нашей жизни

Наука это компактное описание мира. Таблица Менделеева в противовес алхимии и "лучам Юпитера".

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

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

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

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

Так что, дорогие мои, компьютеры и IT-индустрия в целом глубоко антинаучны.
flow

Паттерны предметной области

Меня спросили про "что можно улучшить в языках?" в http://justy-tylor.livejournal.com/207131.html?thread=890395#t890395 Ответ есть там, но я решил раскрыть тему подробнее:

С кодом и алгоритмами в мире разработки программного обеспечения ситуация весьма пристойная. Generic programming есть повсеместно. Замыкания и pattern matching появились ещё в прошлом веке, а сейчас проникают и в популярные языки.

С данными всё однообразно-дерьмово последние несколько десятилетий. Нельзя напрямую применять паттерны предметной области. Когда надо описать вес для сущностей типа Q или их поведение для перехода из состояния F в состояние G, то самое очевидное решение записать это напрямую в типе:
type Q:
  physical_weight 2 kg
  transition F G:
    ... some code ...

Однако, существующие технологии требуют от разработчика ручной перекодировки паттернов предметной области в паттерны языка (классы, методы, ...) и дебильные паттерны-заплатки (вы вероятно помните тот старый сборник "Заплатки для Java" aka "Design Patterns"). Много синтаксического шума и пустых слов. И функциональщина не спасёт - там артефакты интеграции лишь чуть компактнее.

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

На этом месте расцветает всякая эзотерика в виде DSL (domain specific languages, языков предметной области), в которых предлагается условно-подходящий для предметной области набор конструкций, позволяющих сократить boilerplate. И тут же дохнет. Потому что программное обеспечение работает на пересечении разных предметных областей, и для отдельно взятого насоса приходится думать и про жизненный цикл, и про АСУТП, и про пользовательский интерфейс оператора.

То есть, требуется возможность применять паттерны разных предметных областей при описании сущностей и типов, а также в качестве first class patterns при распознавании сущностей через pattern matching. В то же время, код должен быть полноценным современным кодом, с замыканиями и общими алгоритмами. И только такое сочетание позволит создавать исполняемые спецификации вместо низкоуровневого кодирования на высокоуровневых языках.
flow

Мысли об интерфейсах

1. Об мышах.

Перетаскивание (drag and drop) в сегодняшних операционных системах сделано так:
press LMB (left mouse button) at source
release LMB at target
Что доставляет ощутимые неудобства в физических случаях вида "мышь задела задела об клавиатуру", а также, когда source и target не являются одновременно видимыми на одном экране.

В играх, для операций с предметами, обычно доступна другая модель:
click LMB at source
click LMB at target
Она более удобна и лишена перечисленных недостатков. Можно кликать на кнопках, закладках и линейках прокрутки, не теряя переносимого предмета. Однако, она неприменима в тех случаях, когда одиночный клик уже предназначен для выделения объекта, а в приложениях обычно так и есть.

Но при этом свободен hold, который вообще редко используется на десктопах, и можно сделать:
hold LMB at source
click LMB at target
Плюсы очевидны. Минусы: так можно делать в пределах приложения, но сторонние уже не исправить.

2. Об гридах.

Датагриды - один из двух наиболее сложных в разработке элементов GUI общего назначения. И самый ненавидимый разработчиками, за всё время своего существования в графическом виде. Гриды разрабатываются долго, с матюгами в адрес авторов интерфейсной платформы. Или покупаются и дорабатываются, с таким же количеством матюгов. Артефакты отрисовки, артефакты выделения, тормоза, проблемы синхронизации данных - всё это сопутствует.

Одна из причин - лапша событий. http://justy-tylor.livejournal.com/197912.html

А вот другая... стандартные контролы. Мы давно живём в двадцать первом веке, но Label и EditBox всё ещё разные контролы, это нормально для классических диалогов, но это совершенно ненормально для гридов, они от этого глючат и болеют. То есть, нормального грида не будет, пока не будет лёгкого виртуального Label с переключением в чуть более тяжёлый режим EditBox, поддержкой работы с разными undefined (не только NULL в базах, но и property grid + multiselect), а также аналогичных решений для других контролов.

Что само по себе достаточно затратный процесс. Ведь второй из наиболее сложных элементов общего назначения называется EditBox.
flow

Эволюция графики

Подборка графических демок от Nvidia и ATI, а также графических тестов сторонних производителей с начала двухтысячных. Лишь малая часть интересного "графона" за этот период, но развитие показывает.

Интересно, кто-нибудь кроме авторов обзоров видеокарт ещё замеряет попугаев в современных версиях 3DMark? :)


The Evolution Of Real Time PC Graphics


The Evolution Of Real Time PC Graphics - Part 2

Люди делают красоту. А теперь представьте, насколько криворукими приходится быть разработчикам браузеров и сайтов, чтобы на том же железе у вас тормозила какая-нибудь "форма ввода комментария".
flow

Версии

Реально существующая проблема: http://dtf.ru/blog/read.php?id=69122
Существует множество решений, которые помогут вам организовать работу с версиями 100500 маленьких текстов/исходников. Однако, для больших файлов всё иначе.

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

А уж идея "прогрессивных" авторов Git/Mercurial о том, что надо таскать за собой полный репозиторий в таком контексте выглядит совсем чудесато. Если это репозиторий типа "спецэффекты фильмы Tron 8", то на фирме не найдётся ни одного отдельного компьютера, куда может поместиться всё это добро с кластера.

Вспоминаю случай из тьмудалёких времён, когда дизайнеры попробовали засунуть исходники игровых роликов в VSS проекта (где прекрасно хранились уровни, сетки, текстуры, ...). Всё грохнулось, базу пришлось восстанавливать. Научили их хранить видео отдельно. Но техническая проблема осталась. И даже сейчас, когда повсеместно используются другие системы версий, эта ситуация никак не меняется.

Хорошая ниша для стартапа, кстати.
flow

Спустя годы

Семь лет назад я работал в геймдеве. И, когда дописывал что-то в редакторе игровых миров, пришла такая мысль: вот взять бы, унифицировать простейшие вещи, чтобы в каждом редакторе, и в 3DS Max, и в Maya, и в Motion Builder, и у нас... сочетание вот этого модификатора (Shift, Ctrl или Alt) и вот этой кнопки мыши соответствовало бы общей логике применения инструментов, общему алгоритму вращения вьюпорта над выделенной группой объектов, etc. Ну вот как привычные всем PageUp/PageDown, но в области редактирования и просмотра трёхмерных сцен.

А то ведь что - пишешь редактор, и думаешь, эти пользователи привыкли к 3DS Max, а эти к Maya, а вот те вообще только Photoshop и Illustrator знают, а ведь надо дать что-то удобное, но в то же время привычное, с возможностью применения готовых моторных навыков. И делается "как в максе", потому что пользователей с такими привычками у продукта больше. Остальные адаптируются.

Но сейчас мне кажется, что стандартизированный "UI для всех 3D-редакторов" сразу создал бы много проблем. Даже современный. А образца девяностых или восьмидесятых вообще оказался бы камнем на шее прогресса.

Посмотрите на Microsoft Excel, или на OpenOffice Calc, или на другой распространённый табличный процессор. Все они одна программа. Это абсолютно одинаковый уродский VisiCalc, идеология которого не менялась уже 30 лет.

Потому что легче впарить ещё один VisiCalc, чем продвинуть альтернативу в нише, где десятилетиями привыкали к однообразию.