Какие альтернативные методы пользовательского ввода должны быть приняты в программировании? - PullRequest
5 голосов
/ 14 января 2009

Программирование особенно отличается, например, от обработки текста из-за большого количества специальных символов и т. Д., Которые необходимо ввести.

Из текущего множества новых методов пользовательского интерфейса, которые подходят для программирования и почему?

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

Редактировать: Когда я указал методы пользовательского интерфейса, я оставил его открытым как для использования с существующим аппаратным обеспечением (мышь / клавиатура), так и для некоторых других вещей, таких как мультитач, распознавание жестов, дополненная реальность (см. HitLabNz, где приведены некоторые отличные Примеры). Меня интересует, как мы можем применить их к программированию.

Ответы [ 7 ]

4 голосов
/ 14 января 2009

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

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

Методы общения

  • Речь
  • Язык тела
  • Жесты
  • Мимика
  • Язык жестов
  • Живопись / Рисунок
  • циферблаты, кнопки, ползунки, указатель, перетаскивание (графический интерфейс)

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

Методы построения функциональных вещей

  • шестерни / пружины и другая механика
  • складывание / раскрой / склеивание бумаги
  • соединительные шнуры
  • электронные схемы
  • петли, шарикоподшипники, колеса
  • фонтаны клапанов и труб
  • Архимедов машины: шкивы, рычаги, винты
  • Lego

Еще один способ указать вычисление по определению.

Методы определения - Ограничения - Категоризация - Теория множеств - Свойства - симптомы - логические таблицы - Правила - Железные дороги (как на железнодорожных схемах)

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

проблемы с текущими языками

  • Интерфейс скрыт

  • API скрыты

  • Побочные эффекты - огромная причина ошибок. Любая часть программы может влиять на любую другую часть.

  • Рефакторинг. Иногда вы обнаруживаете, что повторяете себя, поэтому вам нужен простой способ выделить повторение в макрос, или функцию, или какую-то другую метафору. Это в основном делается вручную (или полуавтоматически в Java) с помощью огромных усилий по обработке текста. Есть ли новая метафора, которая бы выглядела так глупо?

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

  • компиляторы строго наказывают программиста за малейшую ошибку.

  • Переменным не хватает ощущения времени. Нет способа запросить историю всех значений, для которых переменная была установлена ​​в прошлом. Другими словами, можем ли мы иметь язык программирования, на котором мы можем «перематывать» прогресс нашей программы? Тот факт, что переменная может изменяться, часто на неожиданные значения, является еще одним источником ошибок. Это другая половина проблемы побочных эффектов

  • большинство языков программирования имеют довольно крутой курс обучения

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

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

  • Думайте за пределами экрана компьютера, люди. Возможно, клавиатура является наиболее эффективным интерфейсом для ввода сложных отношений и символов. Уверены ли вы? Есть больше альтернатив, чем просто мышь, сенсорный экран или планшет. Миллионы способов взаимодействия с компьютером. Мы все остановились на одном или двух довольно простых способах.

2 голосов
/ 14 января 2009

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

Большая часть пользовательского интерфейса направлена ​​на создание лучших инструментов. Например, вы можете просто использовать простой текстовый редактор для программирования или иметь полноценные IDE, такие как Visual Studio или Eclipse. Помимо этого, существуют инструменты визуализации и дизайна, такие как Rational Rose. Эти инструменты предлагают дополнительные способы изучения и / или изменения базового кода.

1 голос
/ 14 января 2009

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

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

Возможно, методы AR-визуализации могли бы помочь программистам и аналитикам увидеть и манипулировать большей картиной структуры или процессов кода, но, честно говоря, многое можно было бы сделать с помощью гораздо более традиционных методов и элементов управления пользовательского интерфейса, таких как таблицы, формы и меню, что еще предстоит сделать это в мире кодирования. Поздний язык программирования Gupta / Centura использовал древовидный элемент управления, чтобы упростить просмотр больших структур кода. Intellisense - это правильная идея для создания кода, но можно сделать больше, чтобы предоставить разработчику инструменты для понимания и анализа кода в больших масштабах. Исходный код Роди Грина в базе данных - хорошее начало (http://mindprod.com/project/scid.html),, позволяющее разработчику интеллектуально запрашивать кодовую базу. Еще лучше был бы программный пользовательский интерфейс, который налагает анализ на разработчика, ясно давая понять, что Разработчик должен учитывать для данной разработки программы.

1 голос
/ 14 января 2009

Я думаю, что очень важно иметь текстовое представление того, что вы программируете, даже если вы используете нетекстовый (например, графический, распознавание речи, прямой нейронный интерфейс) метод ввода.

Программа - это что-то вроде рецепта: «чтобы достичь этого, пройдите эти шаги». Текстовое представление является записью этого рецепта. Если вам нужен рецепт для создания рецепта («щелкните это меню, используйте это диалоговое окно ...»), и текстовое взаимодействие невозможно, вы теряете связь с тем, что производите.

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

По вопросу графического программирования: я могу гораздо быстрее набрать слово «для», чем нарисовать что-то вроде треугольника с помощью мыши. Это так, даже если этот рисунок «облегчен», позволяя мне получить этот треугольник из некоторого меню. При программировании вы используете сотни разных символов; как они могут быть организованы для доступа без ввода? Хех, я знаю, как насчет сочетаний клавиш ... подождите ...

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

0 голосов
/ 14 января 2009

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

0 голосов
/ 14 января 2009

Было несколько попыток сделать это.

APL, которая использовала выбор специальных символов для представления каждой операции. Это все еще существует в форме языка "J", который - подождите его - заменил все символы двух- или трехбуквенными комбинациями символов ASCII.

IBM Age Age около 1998 года. Имела графическую среду IDE, где вы делали такие вещи, как перетаскивание значков «сокетов» в рабочее пространство и присоединение их к значкам «потоков». Он только что сгенерировал C ++, и после первоначального g-whiz большинство программистов нашли опцию «text view» и продолжили ее.

Suns Fortress - все еще текстовая, но она позволяет использовать символы юникода, такие как √, в качестве операторов. Большинство опубликованных примеров программ, похоже, придерживаются набора символов ASCII.

Здесь есть две проблемы.

Текст очень хороший! Люди могли рисовать довольно хорошие картинки на протяжении тысячелетий, но 99% книг, продаваемых Amazon, содержат только простой текст. Вероятно, для этого есть веская причина.

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

0 голосов
/ 14 января 2009

Что ж, вся цель какого-то символического сценария на самом деле сводится к разработке на основе графического интерфейса, с которой Visual Studio медленно заигрывает, но до нас еще много лет.

Создание какого-либо символа, представляющего цикл FOR, не ускорит разработку. Если вы хотите писать код быстрее, просто используйте drag'n'drop кодовые блоки, которые уже поддерживаются любой приличной IDE.

...