SekraSoft (sekrasoft) wrote,
SekraSoft
sekrasoft

Компьютерная грамотность

Тонкий интерфейс


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


Реклама Apple Macintosh Portable, 1989

Ещё ссылки на 2 копии, а то видео, вставленное в оригинальный пост, удалили:


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

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

Эволюция от выживания к жизни


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

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

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

Что нового появилось в старых версиях компьютера (будем рассматривать программно-аппаратный комплекс)? Возможность хранить файлы! Командная строка как у хакеров вместо ввода с перфокарт! Цветной монитор! Доступ в Интернет! Проигрывание аудио без тормозов! Проигрывание видео без тормозов! Игры!

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

Что нового появилось в новых версиях компьютера? Более быстрый доступ к файлам. Более быстрый доступ в Интернет. Хранение файлов в Интернете. Проигрывание аудио из Интернета. Проигрывание видео из Интернета. Более быстрый доступ в Интернет. Поддержка более нового стандарта беспроводной связи, проводной связи, шины данных.

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

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

Мануалы не нужны


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

Уже сейчас гугление ответов на stackoverflow популярнее инструкций к библиотекам. Почему? Потому, что исключается лишняя абстракция.

Изучение библиотек не нужно


Как это работает?
  1. Имеется пространство задач (то, что должна уметь библиотека)
  2. Программист A находит базис X в пространстве задач и реализует его (создаёт модель задачи, проектирует программные интерфейсы
  3. Программист A описывает базис X словами (создаёт документацию по каждому классу/методу Xi
  4. У другого программиста B появляется задача Y = &Sigma ai Xi, причём ai неизвестны.
  5. Программист B подмечает, что библиотека X ему поможет (видно, что задачу как-то можно решить с помощью библиотеки X, т.к. она делает что-то подобное)
  6. Программист B изучает все Xi и находит координаты Y в базисе X (изучает документацию, понимает философию библиотеки и пишет программу)


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


Мой любимый пример: для получения элемента списка нужно линейное время, для получения всех элементов списка нужно линейное время. Но если не нарушать абстракцию и пользоваться for ... get(i), выйдет квадратичное время. В этом заключается слабость реальных абстракций. Пока ты не понял, что внутри, у тебя могут возникнуть проблемы с их использованием. Но если тебе пришлось заглянуть внутрь, то это какая-то неполноценная абстракция.

Переформулировка задачи не нужна


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

Часто программист, когда сталкивается с чем-то новым, вообще не знает, что ему нужно. Он идёт как бы напролом и неправильно группирует свои действия. Как программист, он разделяет свою задачу Y на Y1 и Y2, т.е. находит некоторый свой базис исходя из имеющегося опыта (который не работает в случае в новой библиотекой X) и спрашивает на форуме. Ему задачу раскладывают по басису X и отвечают:
Y1 = a X1 + b X2 + c X3
Y2 = -a X1 - b X2 + d X3
Оказывается, что проблема решается стандартными средствами, и решить её как целое легче, чем неправильно разложить на подзадачи и решать уже их. Меньше разложений по базису и смен координат.

К сожалению, сообщество стимулирует бездумное поведение и имитацию бурной деятельности. Приходит человек на форум, спрашивает, как сделать Y. Ему говорят, что это элементарно, и надо просто погуглить. Или что вопрос слишком общий, нужен поконкретнее. Он гуглит, ничего не находит, разделяет задачу на подзадачи, спрашивает про подзадачи, ему отвечают по каждой в подробностях, потом интересуются, зачем это. Человек говорит "для Y" и ему тут же сообщают "Да так бы и сказал, это (c+d) X3!" В дальнейшем человек приспосабливается и задаёт совершенно бесполезные конкретные "умные" вопросы.

И вопрос "я хочу реализовать Y" превращается в "я хочу понять X". Заметим, что задача из описания заказчика уже перетекла в какое-то её понимание руководителем отдела разработчиков, сформулирована в письменном виде, как-то понята и смоделирована конкретным программистом, который уже готов исказить этот поток информации ещё несколько раз, выразив своё понимание на языке программирования, который он знает как свой родной язык, либо перевести свои идеи с языка программирования в метаязык библиотеки.

Аналогично с примером с форумами, здесь архитектор может сделать неудачную модель задачи заказчика (наклонить базис куда попало) а программист – неправильно выразить её в терминах ЯП (создать ещё одну систему координат под другим углом). В итоге решение задачи будет гораздо более сложным, чем если бы заказчик сам написал программу.

Это ненужное искажение информации, ненужные затраты по изучению чёрт знает чего.
Гораздо удобнее, когда знаток библиотеки X сам разложит твою задачу по её базису. Он сделает это по определению оптимальнее тебя, т.к. он уже осознал X, а также не будет совершать лишних действий по изучению X, т.к. он уже осознал X. Это банальная окупаемость. Если мне нужно один раз доехать к другу в гости, я вызываю такси за 500 рублей. Если мне нужно ездить к нему раз в день в течение двух лет, я покупаю велосипед за 10000 рублей.

Кроме наличия экспертов, stackoverflow предоставляет нам базу реальных примеров. Автору библиотеки придумывать их - нестерпимая мука и занятие бесполезное. А вот сообщество может сформировать её довольно легко исходя из собственных потребностей!

Языки программирования не нужны


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

Заказчику нужно автоматизировать некоторую задачу. Ему не нужно, чтобы кто-то изучал библиотеку X и ЯП Z (это дорого и не всегда окупается), ему нужно автоматизировать свою задачу. Лишние прослойки вроде программиста, языков программирования, компьютеров и даже программ не нужны. Если бы заказчик мог купить решение задачи, он бы его уже купил и радовался, а не звал бы кого-то.

Проще метаинтерфейс – проще интерфейс


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

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

Тут ещё нужно вспомнить стремление человека к усложнению. Если людям дать волю, они придумают этикет, сарказм и годовые отчёты, чтобы заменить свободное общение на неповоротливую громоздкую машину намёков, домыслов и спецтерминов. Как минимум, разделение на "ты" и "вы" (имеющее более двух градаций в некоторых языках!) – только оверхед, который не обеспечивает никакой конкретики, вызывает обиды и засоряет память носителя языка.

К счастью, человек ленив, а потому стремится спихнуть свою работу кому-то другому. Сейчас поисковики находят конкретные существующие примеры кода, то есть, можно сказать, преобразуют словесное описание элементарных действий в код. В будущем они научатся преобразовывать более общие описания в код (станут искусственными программистами), и программист будет заниматься только отдельными частными моментами и, возможно, оптимизацией. Компиляторы и сейчас неплохо работают, но в будущем их объединят с искусственными программистами. Зная задачу целиком, компилятор сможет эффективно оптимизировать её. Поначалу программистами будут те, кто сможет сформулировать задачу, а затем, развив модули распознавания, программистов вычеркнут из цепочки.

Модульность для ограниченных или философия компиляции


Почему мы используем модульность? Потому, что это универсально, удобно? Потому, что можно заменить один модуль и не трогать всю систему?

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

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

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

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

Налицо схема преобразования задачи: от сырой общей сути (мысли заказчика, мысли разработчика) в некоторое модульное описание (ТЗ, модули программы) и от модульного описания к конкретному продукту. Чтобы модульность и абстрактность работала в полную силу и не тормозила, её нужно сломать и рассмотреть целиком сверху донизу! Модульность даёт удобное для человека промежуточное представление эффективной монолитности.

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

Люди не смогли сразу выполнить свои задачи, поэтому разделили их реализацию:
  1. Пользователь формально описывает задачу
  2. Разработчик создаёт программу
  3. Пользователь общается с программой
  4. Программа выдаёт результат

Причём на каждом уровне могут быть подуровни с искажением смысла и тратой ресурсов на межуровневое взаимодействие.

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

Планы на будущее


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

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

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

И если когда-либо в будущем мы встретим человека, который всё ещё читает мануалы, кликает по иконкам и работает с командной строкой, то будем точно знать, что это просто творческий человек. Может быть даже художник, которому запретили прибить себя к площади.
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments